When validating a picking of an entire package (e.g. internal transfer)
that has an associated owner, we are looking for a quant matching
stricly all criteria, including the owner. However, the owner is not
filled in on the move lines and is only inherited from the picking item.
As we do not find the existing quant, we are creating a new one, and
we logically have the error message "You cannot move the same package
content more than once in the same transfer or split the same package
into two location."
To allow all transfers of packages, we should add the owner of the quant
when creating the move lines when setting the package level as done.
closesodoo/odoo#61697
X-original-commit: 2ac8dec4967c50ddaf4b4d0260d32f6f1afe979e
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Signed-off-by: Alex Tuyls <alt-odoo@users.noreply.github.com>
In the case of none of the conditions is fulfilled, the stock page level
will have not a state. This will raise an error when it's open.
opw-2375250
closesodoo/odoo#61664
X-original-commit: e5b8015d66e1d3d81148a5663a9c934d4baf6c78
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
The picking_type_id of a stock move can differ of the related picking:
- Create and save a draft transfer with a stock move
- Change the picking_type_id and save
- The picking_type of moves won't be the same than the one on the stock
picking.
Fix force the picking_type_id of moves_lines in the
picking `onchange_picking_type` method. Same issue can appear in multi
company situation, fix it too.
task-2372196
closesodoo/odoo#61574
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
In multi company (company A and B),
- Select the company A as main one, and select B too.
- Create a picking type and change the company to B.
- Don't select any warehouse.
- We can't save, because the company ir.sequence is
set to A instead of B.
Fix by apply the company_id of the picking type.
task-2372196
- Fix the issue of the added test.
- Also batch the `push_apply` + `_action_confirm` by doing confirm
in BFS instead of DFS. Improve a lot the performance when
the _action_confirm is on batch.
closesodoo/odoo#61567
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Usecase to reproduce:
- Rule from WH/A -> WH/B as automatique no step added
- Rule from WH/B -> WH/C as transfer created
Do a move that goes to WH/A and confirm it. It's destination location
is correctly set to WH/B but the internal transfer from WH/B to WH/C
is not created.
It's due to the avoid loop location that returns always true due to
code removed in commit 1d36fb428fclosesodoo/odoo#61488
X-original-commit: b2a07e4d08beff360ac1e6c95d240a15b1081855
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Previously, the field `package_use` was in `stock_barcode_picking_batch`
as this field is only used by the picking batchs in barcode.
But to avoid some overrides and so make the code simplier, it is now
declared in `stock`.
However, this field will not be visible in the package form view until
`stock_barcode_picking_batch` is installed.
closesodoo/odoo#59925
Related: odoo/upgrade#1855
Related: odoo/enterprise#14043
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
When using reusable package in chained transfers, indicates the package
should not be propagated for the next moves `result_package_id`.
This change has no effect by itself, but it's used in enterprise by
https://github.com/odoo/enterprise/pull/13146/commits/611b2c0b188ab9906eb21feab087a1794bd2d015 when Picking Batch is enabled
and barcode app is installed.
task-2333834
X-original-commit: 6677f501d5a1717af8da08a7e235d87aeb85f862
Usecase to reproduce:
- 10 company having 10 000 moves in state 'confirmed', 'partially_available'
- Run scheduler manually (without cron)
It will takes a huge amount of time.
It happens because the run scheduler wizard will call run_scheduler
as sudo for each company (passing company as arg).
run_scheduler will try to assign move that could be reserved. However
the domain in order to search move do not include the company_id and
search for every company.
Following upper usecase:
Instead of running action_assign 10 times on 10 000 moves, it will
run action_assign 10 times on 100 000 moves.
Databases with multi companies and having a lot of stock will have a
scheduler speedup from this patch.
Thanks "Rémy Voet <ryv@odoo.com>" for finding this issue.
opw-2328707
closesodoo/odoo#61183
X-original-commit: a21f9876b5b9d01380d03d638deb48cd091f26e7
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Behavior prior to this commit:
In a multi-lingual setup, when entering a SO for a customer set in
a non-default language with a product that has translation in both
languages and is set up to replenish on order, the description in the
generated RFQ is duplicated, for example: "Product test Test Product in Dutch"
The problem stems from the fact that the description on the generated
stock move is set to the translated name of the product. When
generating the PO, the stock move class removes the product name to
avoid duplicating the description, but it uses the non-translated name
in the comparison.
Behavior after this commit:
The description on the RFQ line is included only once (using the default
language for the database)
opw-2368562
closesodoo/odoo#61138
X-original-commit: d013f8641ae2ed8c12d30ba5650c8e6ff2f1d5fd
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Create 3 items:
* FP
** manufactured from SFP
** reordering rule
** manufacture lead time 2 days
* SFP
** manufactured from CP
** reordering rule
** manufacture lead time 2 days
* CP
** buy from vendor
** reordering rule
** manufacture lead time 2 days
Create a sales quotation:
* Product: FP
* Delivery Date: +7 days from now
Save and confirm
Run scheduler.
No Manufacturing process will be started.
This occur because the reordering rule (orderpoint) check the
quantity needed at the current date + lead days, while the move
are being planned for the delivery date specified by
the user in the SO.
Moreover the quantities that depends on datetime.now() are not recomputed
so each scheduler run is failing to schedule new orders
opw-2366925
closesodoo/odoo#60993
X-original-commit: 06eaf867ec7cac15a5cd9c972321f6f5d3c194bf
Signed-off-by: agr-odoo <agr-odoo@users.noreply.github.com>
Purchase
- When a RFQ is in "To Approve" stage, on the printed pdf, keep "Request for Quotation" as a title
- "Send Reminder" action should open the composer when triggered manually.
Inventory
- In tree view of transfer, set date_done optional = hide
- In (mobile) picking view, replace button text with 'add a product'
- fix Vendor Group by in Replenishment report
- Warning message when changing product tracking from untracked to tracked
MRP
- Reporting > Manufacturing Orders : change measure for total quantity grouped by scheduled date = month and by product
- Reporting > Work Orders : change measure for Duration per unit grouped by workcenter and by product & add unit (minutes)
- Reporting > Overall equipment effectiveness : group by loss reason added to the current group by workcenter
closesodoo/odoo#57036
Related: odoo/enterprise#12926
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
This commit updates the description_picking on stock moves once the
picking type is changed. This is needed to merge stock moves at
confirmation. The description_picking field chosen on the merged move is
the 'minimum one'. Empty string will always be chosen that way, so we
lose the information.
closesodoo/odoo#60762
X-original-commit: a3dad0f892b5394124763ceb13305fca745c95b9
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
- Create companies A & B
- Create a Dropship route for B
- Create a product P with route 'Dropship'
- Set the website under company A
- As a portal user, buy the product P on the website
- Do the payment
The SO is confirmed but the Dropship route for B is used despite the
fact that the website is under company A.
This happens because `_search_rule` is called as superuser: therefore,
routes from all companies are retrieved.
To prevent this, we add the company in the domain.
opw-2349094
closesodoo/odoo#60482
X-original-commit: 31a54b5e859ead7972cdccc956518e14038476ba
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
In the compute of forecasted information of `stock.move`,
instead of using the warehouse of the picking type, use
the warehouse of the source location (if there is).
X-original-commit: ffd447f734e7688a1954d428bfe14c8edfd4ada1
This commit adds a constraint on model stock.warehouse.orderpoint
(reordering rule) to ensure two orderpoint are not set on the same
product and on the same location. This is an issue as the replenishment
will be done multiple times in case of duplicated rules.
Task : 1939567
closesodoo/odoo#47909
Related: odoo/upgrade#1814
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
Steps to reproduce:
* In Inventory, activate multiple warehouses and storage locations, multi-step routes, Delivery packages
* On the main warehouse, activate 3 steps delivery
* Create a stockable product A
* Update quantity on hand: 100 units in a package PACK1 in Stock/Shelf 1
* Create a new Pick transfer with one move: 120 product A
* Set the transfer as todo and check availability: a move line for the 100 units from PACK1 is created
* Edit the move line: set a destination location, **change the result package to PACK2** and set a qty_done
* On product A, update the quantity on hand: add a *new* package PACK3 of 20 in Stock/Shelf 1
* On the transfer, click on check availability
Current behavior:
* A new move line is created for the 20 units from PACK3 to PACK3: ok
* The move line edited before for the 100 units has its result package **reset to PACK1**
Expected behavior:
* A new move line is created for the 20 units from PACK3 to PACK3: ok
* The move line edited before for the 100 units has its result package kept to **PACK2 as edited by the user** who decided to open the package already
Short analysis:
At the end of `StockMove._action_assign()`, the method `StockPicking._check_entire_pack()` is called. For each package moved by a move line, this method checks if the package is entirely moved (sum of quants == sum of move lines). The check is done by `StockPicking._check_move_lines_map_quant_package`. When the sums match, the package level of the move lines is created or updated. When it happens, it writes the package in the `result_package_id` of the related lines.
It should not change the result_package_id if it was already set.
Thinking further, maybe it should not consider lines with a `qty_done` in `_check_move_lines_map_quant_package`: users already picked these lines, if they decided to empty or change the `result_package_id`, a new check of availability for the remaining quantities should not change these lines.
opw-2346608
Fixes#58491closesodoo/odoo#60025
X-original-commit: db262912eb716aed1c42be8a9d59c25bdfa400e0
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Consider move uom different from serial product uom
to set up move lines with product uom
closesodoo/odoo#59986
X-original-commit: ee966998fa986936a0407676bb4d54f61c7fce1f
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
Activate Delivery Packages option in the settings, and check "Move
Entire Packages".
Create a product, and update the quantity on hand (e.g. product X with 5
quantity in package Y in location shelf 1)
Then,create an internal transfer (e.g. package Y from shelf 1 to shelf
2), check a first time the 'done' box and save.
Finally, edit, uncheck and check again the 'done' box in the same
operation and save.
You will see (tracking message in the chatter) that the initial quantity
is wrongly updated (doubled apparently).
After saving, the 'done' box will be unchecked and the transfer cannot
be validated with the following error message :
"You cannot move the same package content more than once in the same
transfer or split the same package into two location."
This occur because on uncheck and recheck done checkbox the quantity is
added again to the related move.
opw-2350335
closesodoo/odoo#59494
X-original-commit: 2dbb8ef133bb49356ff1f7dacb2be8e7ed934697
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Signed-off-by: agr-odoo <agr-odoo@users.noreply.github.com>
Hides the `picking_type_id` field when creating a new transfer if it is
set by default.
As this field is automatically set when coming from a list of a specific
transfer type or when asking to create directly a specific transfer type
this field is superfluous in these cases.
task-2328830
X-original-commit: c26ec70c61f51e6dc30c460c1b60f0d9ff3286a8
Quant search domain was missing a '|', this made it so locations with
non-zero quants in it could still be archived. Also added a missing
space in warning message when there are multiple locations because it's
better that way.
Discovered during task: 2336455
closesodoo/odoo#59154
X-original-commit: 340dac3b2928da292c6b74971e77816304b263ab
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Currently the help of stock_inventory.date includes:
"If the inventory adjustment is validated, date at which the inventory
adjustment has been validated."
But for some reason this isn't the case. This commit makes it so we now
update the `date` when the inventory is validated. Since no one
previously complained about this, we only apply it to newly validated
inventories and leave existing ones as is. Note this change makes the
`accounting_date` help accurate (i.e generated account moves already
use the date when the inventory is validated when no accounting date
set, so before this fix the dates won't match).
Discovered during task: 2336455
closesodoo/odoo#59143
X-original-commit: 1da012147fa49045bb1dff25eb304364d47e0271
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
And other reported English mistakes in source string
Courtesy of Transifex translators
And remove leftover from gengo
closesodoo/odoo#59022
X-original-commit: 26efc84c5cac47a2cc83d7b084f8b71528fec6c7
Related: odoo/enterprise#13781
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Like was done in 8d62eacfff for the
picking model, we remove the `components_availability`
and `components_availability_state` which
can leads to performance issue in case there are a lot of
productions/stock move. Replace by the old reservation_state field.
A performance quantification is required to reintroduced
these fields in views (task-2348553).
Also a fix is done in the stock_picking computation
of `products_availability` and `products_availability_state`
(same nature than these in `mrp.production`).
closesodoo/odoo#58856
X-original-commit: 0a19921e3a50faa8175e973a1edb49100826a9d9
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Signed-off-by: Rémy Voet <ryv-odoo@users.noreply.github.com>
In case of multi-warehouse, the forecast button won't
take in account the related warehouse and redirect to the
forecast report of first warehouse of the company.
To ease the understand of the forecast report redirect
with the right warehouse in the context.
closesodoo/odoo#58837
X-original-commit: 53468d71b913211b38f4856f2bdb62594ee24ea8
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Signed-off-by: Rémy Voet <ryv-odoo@users.noreply.github.com>
This allows to restrict the reservation of a move to a specific lot, location, pack or owner
and for instance implement back the restrict_lot_id feature, among others
closesodoo/odoo#58786
X-original-commit: 8459c9dae1a83b7f1d827ee40991778c9bb9d9cd
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
This commit change the _split method to return new move values instead
of create it and confirm it.
This allow multi creation and multi confirmation when every move of the
recordset are split
Task : 2076873
closesodoo/odoo#58594
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
- On `stock.picking`, remove unused `rate_picking_late` and
`rate_picking_backorders` and change the compute accordly
- On `stock.warehouse`, remove unused field warehouse_count and
remove show_resupply which can by replace by
the groups="group_stock_multi_warehouses" since
7bf064fcc160fb3f91d58e64d45e8a981865dc41
Before 9920f20e4c, the `
`_compute_product_qty` (`stock.move`) used the context to choose
the rounding method. It was remove (always used 'HALF-UP')
and replace by a comment. The rouding method used by the context was
used only on the `_split` method with always 'HALF-UP'.
Then remove rouding_method of context and remove the obselete comments.
task-2041971
Remove the json_forecast of the sale order line,
it was a duplicate of information with the qty_at_date_widget.
But improve this one:
- Use the forecasted move information in case of confirmed SO.
- Change the icon (i) to chart.
- Link to the forcasted change to target new forcasted report
(Unfortunately we loose the feature to see components product forcasted
of a kit)
- Change information print in the popover in case of confirmed SO.
Also refactor the json_forcasted of `stock.move` into multiple fields
to avoid to dump/loads for other model who needed the forcasted data.
task-2324039
closesodoo/odoo#56425closesodoo/odoo#57526
Related: odoo/enterprise#13063
Related: odoo/enterprise#13160
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
date_deadline of the stock move has been reviewed:
- Now, it represents the datetime when the operation must
be done to be in time for the uppest document (SO/PO/MO/RR).
- At the creation of stock move the date_deadline is computed in
the same way than the sheduled date expected that it is not include
security days (inverse the logic for PO).
- When we update the delivery date (or lead time) of SO (or PO).
The deadline of related stock move is updated and the delta is propagate
between origin and dest moves.
task-2324039
Before this commit, the labels for the field `virtual_available` of
product.product and product.template were different.
Unify both labels
closesodoo/odoo#45560
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
In inventory report, when groupby setted and no data, the create button
will open a new form instead of create a new line. Since now our form
view is not editable, no record can be created.
In this commit, add a new editable form view to solve it.
Task 2310494
PR #55910closesodoo/odoo#57344
X-original-commit: 4a4e60c65049082855414941642dadce8b413475
Related: odoo/enterprise#13067
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Steps to reproduce:
- Create a product P with route 'Resupply subcontractor on an order'
- Let's consider a BOM for P with type 'Subcontracting'
- Create a PO with subcontractor set on that product and process with Qty > 1,
- Validate a receipt with partial Qty and no backorder
Bug:
An error was raised because no production_id was set when trying to create a mrp.product.produce
When function _action_done is called with cancel_backorder = True, the function _action_cancel is called on the new_move
with no backorder and it called the function _action_cancel defined on model stock.move in module mrp_subcontracting
This function called _action_cancel on the mrp.production record MP
And finally this function called action_cancel on model stock.move on all finish_moves and raw_moves of MP
This line unlink MP of finish_moves and raw_moves
move.move_dest_ids.write({'move_orig_ids': [(3, move.id, 0)]})
That's why production_id was not set
PS: In this way, we don't cancel a MO when it is still used by other moves.
opw:2322278
closesodoo/odoo#57346
X-original-commit: e4d22d390c8aa8edf757e36704a9e04b2b89f115
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Orderpoint qtys were not updating when an already saved stock.move has
its demand updated. This was leading to new orderpoints being created
when there is already an existing one. This commit fixes this bug by
adding the missing dependency.
Steps to reproduce:
- Create a product
- Create a delivery with the product > Mark As Todo
- Go to replenishment report (product should be added)
- Go back to same delivery > unlock > increase the existing move line
demand amount
- Return to replenishment report.
product now has 2 orderpoints instead of just 1.
Additionally this commit fixes a column mislabeling in the "Reordering
Rules" tree so that it now matches the "Replenishment" tree
closesodoo/odoo#57355
Task: 2327726
X-original-commit: 1429a7d3029fff1c6cac8fbe98b00eb931d43604
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
This commit does 3 things:
1. When 'action_confirm' is triggered in a manufacturing order, any
'move_raw_ids' (components) that are unable to be fully reserved
when `action_assign` is triggered will be checked for an automatic
reordering rule (RR). If a rule exists it will be auto-triggered.
This includes subcontractor manufacturing orders. Relevant test
updated to match this.
2. When a MO is completed, auto check if there are corresponding
confirmed stock moves that can be populated by the completed products
and trigger their 'action_assign' to reserve the completed products.
3. If a new move line is added to an already confirmed MO, then do same
auto-RR check/trigger. (note will occur for pickings without extra
code since `stock_picking.action_confirm` is triggered again in this
case.)
This reuses similar logic as odoo/odoo#52433 from task 2244230.
Originally this was done in the `action_assign`, but has been moved to
`action_confirm` so as to imitate the now archived MTO process with RR.
Overlapping logic has been moved into stock_move for easier reusability.
Note that this now means editing existing moves' `product_uom_qty` (i.e.
Demand) will not have a flow to auto-trigger their RR.
Subcontracting test updated to match + new mrp test added for this new
feature.
closesodoo/odoo#57334
Task: 2322496
X-original-commit: 2688cd1bae489b1dec8862f4de727ac20514844c
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
PURPOSE
Clean code. Be more performance oriented.
SPECIFICATIONS
Improvements applied in this commit
* not all() --> any(not) for earlier returns;
* all([generator]) --> all(generator) to avoid unnecessary list casting.
This code construct is better managed by all;
This commit will probably not have a big performance effect on standard
production databases. However each performance and cleaning improvement
is welcomed.
LINKS
Task ID-2328619
closesodoo/odoo#56810
X-original-commit: 1cc6bb1231401ea7f501d2f5b5e9641ec8734850
Related: odoo/enterprise#12802
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
The printed status should not be kept when duplicating a picking.
opw-2320680
closesodoo/odoo#56449
X-original-commit: 6938e5bf106f95149bce50fac7ed3291bd1da812
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
- Go to Inventory > Master Data > Products and create a Product with Tracking "By Lot"
- Go to Inventory > Configuration > Operation Types
- Edit Receipts:
* Activate "Show Detailed Operations"
* Activate "Create New Lots/Serial Numbers"
* Deactivate "Use Existing Lots/Serial Numbers"
- Go to Inventory > Overview and open Receipts
- Create a Receipt operation
In the Detailed Operations tab, if a Product tracked by lot is added,
an existing lot can be selected although it is disabled in Operation configuration.
Once saved, the selected lot disappears.
"Lot/Serial Number" column is replaced by "Lot/Serial Number Name" column.
A lot name can be entered manually. (It will create the lot at the validation)
But after validation, the lot associated to the Product is the existing lot
that has been selected during the operation creation, not the one that should
have been created from the lot name entered manually.
opw-2323093
closesodoo/odoo#56448
X-original-commit: 75add3d1496ee64d5278bc4250ac41dc4349d460
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
This commit sets up the logic and adds the button for "Put in Pack"
action that already exists in stock.picking. Reuse/extension of logic
from stock.picking reused where possible, including extension of pack
wizard to handle products with different destination.
Note that logic to handle "Delivery Packaging" wizard when "Delivery
Methods" is active was purposely not extended to work correctly in batch
pickings due to complexity of adding in a new module just to handle
conflicting carrier_ids across pickings in the same batch. It is
expected that this use case will not occur except in case of user error.
Additionally, stock.picking implementation of 'put_in_pack' method has
been renamed to 'action_put_in_pack' to have consistent naming (and
support enterprise level code).
Part of "1. Improve Batch Pickings" specification of overall barcode
improvements task.
Task: 1884520
Enterprise PR: odoo/enterprise#12086Closes: odoo/odoo#55096
alt-odoo