This commit rename product_uom_qty into reserved_uom_qty and product_qty
into reserved_qty on stock move line to stop mistake them with the stock
move quantities fields.
Task: 2648449
Part-of: odoo/odoo#80434
The packages reservations are not correctly done in case of a backorder
To reproduce the issue:
(Use demo data)
1. In Settings, enable:
- Delivery Packages
- Multi-Step Routes
2. Edit the warehouse:
- Outgoing Shipments: 2 steps
3. In Operations Types > Delivery Order, enable:
- Show Detailed Operations
- Move Entire Packages
4. Create a Pick P:
- 1 x [DESK0004] Desk
- 1 x Large Cabinet
5. Put each product in a separate pack
6. Validate P
7. Create a Delivery Order (Planned Transfer):
- 1 x [DESK0004] Desk
- 1 x Large Cabinet
8. Mark as TODO, Check Availability
9. In Detailed Operations, mark one of the packs as Done
10. Validate the DO, Create a backorder
Error: The not-yet-done pack is still on the delivery order and its
status is "Reserved". This line shouldn't be present anymore. Moreover,
the backorder has a line for this pack, its state is "Draft" (instead of
"Reserved") and the state of the BO is Ready.
When creating the backorder, the packages levels of the not-yet-done
moves are transferred to the new picking (i.e., the backorder) However,
these moves does not have a package level defined (due to
9d758fa2e1). Therefore, when checking the
packs:
https://github.com/odoo/odoo/blob/e7450bee8f018a5334d9628235824f2fc6f32cec/addons/stock/models/stock_picking.py#L822-L832
`package_level_ids` is empty, so a new `stock.package_level` is created
(instead of using the one of the initial delivery order). And
`move_lines_to_pack` is empty too, so the new `stock.package_level`
won't have any move lines and its state will be "Draft"
We should rather transfer the package levels of the moves' lines.
OPW-2659176
closes#77509closesodoo/odoo#80072
X-original-commit: 4fd5cd6f940575090021dedd2159d050b594dd69
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
Co-authored-by: Adrien Widart <awt@odoo.com>
Co-authored-by: Florent de Labarre <florent.mirieu@gmail.com>
Since return moves are linked to their original move, it's easy to
manage reservation in those case. We just don't bypass the reservation
when it comes from a reservation outside our stock in order to manage
the computation on linked moves and reserve pieces that were not yet
return.
Also add a return picking type for 2 reasons:
- Allow to select existing lot.
- Display reserved move line for an incoming picking.
Note that this picking type is just a default configuration and could be
modify by the user without any issue.
closesodoo/odoo#64384
Related: odoo/enterprise#20605
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
A stock move with 0 qty in initial demand is considered as 'ready'. But
those stock moves should be excluded of the picking state computation to
not false the readiness of the picking, especially if the delivery
policy is set to 'direct'.
opw-2611018
closesodoo/odoo#75589
X-original-commit: bc7198961583562243b393bd8cd009c5e7220ad0
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
Signed-off-by: Achraf <abz-odoo@users.noreply.github.com>
Currently stock moves are auto-assigned (i.e. reserve free stock) both
when the scheduler is run and when a corresponding stock move that can
assign a move is completed. This strictness was causing issues for
prioritization of moves to assign, for example a picking with a
scheduled_date far in the future could automatically reserve all stock
if it was created before another picking that an immediate
scheduled_date. To ease this, an extra setting has been added to
stock.picking.type to let users choose how reservations should occur for
moves assigned to that picking_type (or picking with that picking_type):
1. 'at_confirm' = automatically when:
- stock is available when the move's associated picking/MO is
confirmed,
- when new stock becomes available,
- when the scheduler is triggered (+ stock available).
2. 'manual' = user must always manually click "Check Availability"
button (scheduler will no longer reserve).
3. 'by_date' = automatically when within the move's reservation_date
and:
- stock is available when the move's associated picking/MO is
confirmed,
- new stock becomes available when move is already confirmed, or
- the scheduler is run (+ stock is available).
'by_date' has an extra option of # days before the move's scheduled
date that affects the move.reservation_date.
Task: 2359317
Upgrade PR: odoo/upgrade#1868
ENT PR: odoo/enterprise#15050
Behavior prior to this commit:
In the following scenario:
- order of 10 widgets
- delivery using an entire package of 15 widgets (by adding the package
under the "Packages" list and checking the "Done" checkbox)
The delivery, when validated, does not update the delivered quantity on
the sales order, and generates a warning about not shipping enough
product. We expect instead the sales order to be updated with the
actual quantity that was shipped (i.e., 15), and a warning about
shipping too many products.
Additionally, when adding the package, the picking reverts to a "Draft"
state and we have to click "Mark as Todo" again.
Behavior after the commit:
When adding one (or more) entire package in the packages list, and
marking them as Done, their entire quantity will be marked as Delivered
on the Sales Order, and no warning about not shipping enough product
will be shown. Of note, if the package also contains products that are
not on the SO, they will be marked as shipped as well (in that case the
picking will indeed revert to draft since we will have added a new
product). However they will not be automatically added to the SO.
Technical details:
When adding a package under the picking it needs to, eventually, reflect
on a stock move. Prior to the commit, the system would add a new stock
move. This had 2 problems:
- the generated move did not carry back to the SO,
- it would flip the picking back to draft (under certain circumstances
it was possible to circumvent that and have a package level, and a move
line, that was not tied to a stock move and thus would automatically
reattach itself when the picking was validated, and sort of work, but
it was more of a happy accident and relying on the steps being followed
in a very precise order).
With this commit, we do not generate the stock move as soon as the
package is added. Instead, that is done when the picking is marked as
done, either by relating it to an existing stock move, or by generating
a new one at this time.
opw-2367893
closesodoo/odoo#62112
X-original-commit: 173bfe6764a554d601d2c7edac2a4c79e2faaa83
Signed-off-by: Nicolas Galler <ngaller@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>
Change the default rouning digits of all UoMs to be two, also change the
decimal.precision of UoM to be two. Adapt all the tests.
Also to avoid hardcoded digits in `should_consume_qty` widget.
PR #56000
X-original-commit: 460ec0402a2352a5b179d81935f7230f6bc97cb7
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
Write is overridden on reserved move lines to make sure the quants are
correctly updated. It is divided in two parts: if you update the reserved
quantity and if you update a characteristic. If somehow both are updated
in the same call (which doesn't happen in the standard interface), then
the quants are unreserved two times, which is wrong.
This issue showcased by [0] and on databases where the reserved
quantities are made editable by customization.
We grouped the two update in one, such as the TODO indicated us since a
long, long time.
We removed `result_packaged_id` from the trigger because it should not
impact the reservation whatsoever.
We needed to remove a tricky logic in the stock move's backordering part
but it was fishy anyway.
[0] eac8c06e2233
closesodoo/odoo#53928
X-original-commit: 507101434f9221f2cfa6de66e1952676fff322fd
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
0. Create 2 Products A & B
1. Open Inventory > Configuration > Settings and flag the following
checkboxes:
Delivery Packages
Product Packagings
Storage Locations
Multi-Step Routes
2. Go to Inventory > Configuration > Warehouses and open YourCompany WH
3. Set 'Incoming shipments' to 'Receive goods in input and then stock
(2 steps)'
4. Go to Inventory > Configuration > Operations types.
5. For 'YourCompany: Delivery Orders' and 'YourCompany: Internal
Transfers”, flag the following checkboxes:
Show Detailed Operations
Move Entire Packages
6. Go to Inventory > Configuration > Locations and open 'WH/Stock'
7. Edit and create a new 'Put Away Strategy' called 'Stock'
8. Add a new rule:
Product A, with Location 'WH/Stock/Shelf 1'
Product B, with Location 'WH/Stock/Shelf 2'
9. Go to Inventory > Operations > Transfers to create a new picking.
10. Select 'YourCompany: Receipts' as 'Operation Type'
11. Under Operations, add a new line with product A and an 'Initial
demand' of 20
12. Save and 'Mark as to do'
13. Enter in edit mode and under 'Detailed Operations', set a quantity
of 11.0 on 'Done' and click on 'Put in Pack'
=> A new pack is created
14. Repeat 13 with a quantity of 9 to create a new pack
15. Save and click on 'Validate'
16. An existing 'Internal Transfers' with the two created Packages
having following properties:
From: 'WH/Input
To: 'WH/Stock/Shelf 1'
At this point, the behavior is expected.
17. Cancel the picking created
18. Create a new picking:
Operation type: 'YourCompany: Internal Transfers'
Source Location: 'WH/Input'
Destination location: 'WH/Stock'
19. Under Operations, add two new lines using the packages os step 16.
20. Save and 'Mark As To Do'. The two packages have the following
properties:
From: 'WH/Input
To: 'WH/Stock'
We can see a difference in behavior. The picking created from a 'Pull'
mechanism applies the putaway strategy to the package, while the picking
created from the 'Push' mechanism doesn't apply it.
We make the behavior consistent. Moreover, in case the package contains
products having different destination locations, the destination of the
picking is kept.
opw-2146583
task-2148494
closesodoo/odoo#45549
X-original-commit: 705bdaa4ae5251b05bc2bbba02f2ca561ca00bbc
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Co-authored-by: Nicolas Martinelli <nim@odoo.com>
- Create a move line from stock to shelf1 with PACK1
- Create a move line from stock to shelf2 with PACK1
- Validate
It should be be blocked. The contents of a package should all
be in the same location since the pack itself is in a location.
It's due to commit 78d6f46 that fix a rounding error.
However it should check for quants that have quantity since they
represents the package content.
closesodoo/odoo#42134
X-original-commit: 78fba949790f2b1ecd3ba1bf60fb34c30d17769e
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
`action_done`on pickings should be a private method,
and called only trough the picking validation process.
task-1938108
closesodoo/odoo#39174
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
rev[0] added the possibility to put in pack without setting any done
quantity on move lines but when the reserved move lines are hidden
(thanks to rev[1]) it got confused on which move lines to work on.
[0] e03c1a836f
[1] ffd5d5a097closesodoo/odoo#36832
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
When validating a picking from location A to B, location A's quant.quantity
may be updated to a quantity != 0 with _update_available_quantity.
This is because the quant value is written as quantity - float_round(quantity).
As a result, the consistency check would find two existing quants, and raise.
Therefore the picking cannot be validated.
opw 2040091
closesodoo/odoo#35913
Signed-off-by: Nans Lefebvre (len) <len@odoo.com>
Ensure proper domains are applied and enforced on relation fields thanks
to the `check_company` attributes.
product.template
- make responsible a property field in order to ensure proper next activities when a product
is used between multiple companies
stock.putaway.rule
- added a company_id field
stock.move.line
- company_id is not related anymore since a move line can exist without a move until its validation
stock.package_level
- added a company_id field
stock.picking.type
- company_id is now required
stock.production.lot
- added a company_id field, adapted the constraint accordingly
stock.quant
- check the consistency only in inventory mode
stock.quant.package
- company_id is now empty if the package is empty
stock.picking
- company_id is now related to the one of its picking type
Added some tests.
Moved stock_traceability in the `report` directory.
Removed useless /tests/tours/route.js.
task-1985992
before on runbot:
odoo.addons.stock.tests.test_move tested in 31.79s, 63166 queries
odoo.addons.stock.tests.test_move2 tested in 33.69s, 68046 queries
odoo.addons.stock.tests.test_quant tested in 8.48s, 15351 queries
odoo.addons.stock.tests.test_stock_flow tested in 16.99s, 31506 queries
amounting to 90 seconds on a build page
after om runbot:
odoo.addons.stock.tests.test_move tested in 12.41s, 24197 queries
odoo.addons.stock.tests.test_move2 tested in 13.55s, 24254 queries
odoo.addons.stock.tests.test_stock_flow tested in 9.74s, 15795 queries
amounting to 37 seconds on a build page
Use savepoint case instead of transaction case.
We took the opportunity to rename the master data more appropriately,
which results now in a bigger diff in TestMove and TestQuant. In
TestQuant, the master data creation had to be moved in the setUpClass
too.
We removed test_shipment as test_backorder_1-4 in tet_move_2 covers the
same parts of the code.
Some tests had to be adapted because they relied on the buggy behavior:
this was particularly the case when they tried to write on readonly
related fields.
closesodoo/odoo#32460
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
When the move lines in a move are all linked to a package level,
we don't want to see the move anymore. We cannot keep only a domain on
moves their-selves as it depends on the move lines linked to it.
So we use a compute field to filter the moves to show, and the inverse
function just appends the new/modified moves to the move_lines.
TASK-ID: 1865671
Accessing one2many items by their index seems to produce issue regarding the order. This commit fix the potential issue in the test by summing the two quant quantity instead of comparing them one by one.
closesodoo/odoo#27627
Purpose : during a transfer, if some move lines have different
destination locations and the user click on 'put in pack' button, an
warning is triggered. This message, saying : 'You cannot put in the same
pack move lines having different destination location', is replaced by a
wizard allowing the user to choose a unique destination location. This
location will be set as location_dest_id on all transfer's stock move
lines. After that, the wizard calls again the _put_in_pack() method
where all the logic remains the same.
Task : 1872345
When a package level is confirmed and is set to done, if you try to
reserve it after, it won't have the correct location of the reservation
because there are still move lines (forced) with the wrong location.
We added a model to work easily with packages, using the quant packages
was not a good solution to move entire package and plan package moves,
because we always had to give the picking in context, and create some
move lines, so it was only possible when state was assigned (when move
lines exists)
So we created a model package level, linked to picking, move and move
lines allowing to easily plan package transfer and put in pack.
Moves UoM models, test and data to a new addon in
order to be able to use uom without product.
A simple example is be to be able to use UoM for
timesheets.
This commit only move code, and adapt xml ids
without chaging any feature or functionnal
behavior.
Note: 'product' module now depends on new
'uom' module.
William Henrotin