Usecase:
- Product A 10 units in stock
- Do a planned transfer of 7 units to customer
- Reserve
- Do an rpc or execute code to call copy on the stock.move.line
It will result with 2 sml that have 14 units reserve and 7 units
reserved on stock.quant
It's the same result if you create twice the stock.move.line without
updating the stock.quant at the same time. However in stable we
try to only use _update_reserved_quantity on stock.move or some
override in create/write method for 'done' stock.move.line in unlock
cases.
So we never use the copy in stable and define the basic behavior as
'we don't copy the reservation' could prevent some usecase where
the update on the stock.quant is forgotten after.
closesodoo/odoo#74489
X-original-commit: e5041ee1d9b5036cab55f4332977aeb818a3b1e1
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Some changes in the delivery slip layout:
- For delivered products, replaces the Quantity column by two other
columns: Ordered and Delivered;
- Shows the non-delivered products even when the delivery is done and
haven't any backorder.
task-2373833
closesodoo/odoo#61366
Signed-off-by: Rémy Voet <ryv-odoo@users.noreply.github.com>
1. Add product category in inventory report.
2. Default quantity when creating a transfer switched to 1 instead of 0.
3. Remove the reorganize lines step in purchase tour (there is only 1
line).
closesodoo/odoo#69483
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
General improvements of the new Inventory Adjustment mechanism, among which:
From the Inventory Adjustment page
- A new inventory_quantity_set Boolean field is used to hide the Counted Quantity when not set instead of showing 0.
- Possibile to set 0 as a Counted Quantity directly (not using the set button).
- Allows to provide a name for the Inventory Adjustment when using the Apply button at the top of the tree view. This name is applied on the corresponding stock moves.
- Add warnings when trying to Apply/Set on multiple records when some records are not set/already set.
- Highlight lines when there is a mismatch between Quantity / Counted Quantity / Difference. If the user still tries to Apply, shows the option to either keep the current Difference or the current Counted Quantity for all records.
- Set the user when directly inserting a Counted Quantity (before only when using the Set button)
- Add the possibility to import records.
- Add "To Apply" filter.
- Add a 'Reset' button at the top of the tree view for multiple records.
From the Update Quantity page of a product
- Remove the "Updated on Hand Quantity" and can directly change "On Hand" quantity
- Pre-fill a default location (Last used location for tracked products or default destination location in single WH environment)
From the Inventory Report
- Remove the "Updated on Hand Quantity" and can directly change "On Hand" quantity
closesodoo/odoo#71199
Task-id: 2495664
Pr-community: 71199
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
On a delivery, when changing the initial demand of a stock move, if its
value was 0 and becomes > 0, its state will be 'Partially Available' but
the reserved quantity will still be 0.
To reproduce the error:
1. Create 2 products P01, P02
- Product Type: Storable
- Qty On Hand: 1
2. Create + Confirm a SO with 1xP01 and 1xP02
3. Open SO's delivery
4. Unlock, set P01's initial demand to 0, Save, Lock
5. Unreserve, Check Availability
6. Unlock, set P01's initial demand to 1, Save
7. Click on PO1 line
Error: The stock move state is "Partially Available", but the initial
demand is 1 and the reserved quantity is 0. It should be "Waiting
Availability"
On step 5, since the wanted quantity of P01 is 0, the state of the stock
move becomes "Available". Then, when increasing the requested quantity,
the state automatically becomes "Partially Available" because the module
does not consider the case where the state is "Available" with a
reserved quantity equal to 0.
OPW-2488580
closesodoo/odoo#71445
X-original-commit: 05b6dfa0b1e4daf46d569c2e0a330b35e6437f8d
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Signed-off-by: Adrien Widart <adwid@users.noreply.github.com>
Usecase to reproduce:
- create a product with 0 stock
- Sale order 500 units
- a RFQ is created for 500 units
- in replenishments, you have 0 units to order, OK
- RFQ --> confirm PO
- in replenishments, now the quantity to order is 500
--> should still be 0, it leads to confusions
It happens because the replenish action check the missing
quantity for today. It result by -500 units since the delivery
is planned for the next day (default supplier lead days = 1).
But since the orderpoint exist, the quantity forecasted is
already computed correctly with the right lead time.
But the action will remove the 500 missing today from the
quantity forecasted (The idea is to add the missing quantity on
the main location. e.g. I have
-10 units in WH/Stock/Shelf1
-20 units in WH/Stock
The orderpoint will only look for its own location -> 20 to reorder
The replenishment report look by warehouse and not by location -> 30
missing. So 30 missing + 20 incomming -> 10 to add (by default on
WH/Stock)
The fix is to add a step when a product is missing then compute its
virtual available with lead days (to avoid missing confirmed moves
during the lead time).
opw-2456978
closesodoo/odoo#69527
X-original-commit: f939c7b2c4143d685c25d155a164d63070d36ed2
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Fix the access for stock user to stock.quant.
Since the inventory adjustement feature has been moved on
the stock.quant. The user should be able to write on them to
make their count. However we kept that a stock user can't validate
an inventory nor modify quantities on product
closesodoo/odoo#69006
X-original-commit: 6b8d40ec494dfbcaaef0da438692c76d0088f671
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
This commit removes stock.inventory(.line) and moves its general
functionality into stock.quant. Some features are lost during this
switch as well.
Feature Additions:
- New single list view for inventory adjustments (no more multiple
inventory adjustment records to keep track of!)
- Improved cyclic counts (annual inventory day setting) + next inventory
dates are immediately viewable in view (vs auto-generated inventories
based only on location)
- Specific quants (i.e. counts) can be assigned to users for more
flexibility (vs only able to restrict by location + product
combinations)
- Counts can be requested (i.e. bulk assigned to user/for a specific
inventory date)
Feature Removals:
- Can no longer look at previous inventory adjustments linked to a
specific record. Each quant has a history button to show inventory
related moves. [relevant account moves are also now harder to see via
stock as well]
Other changes:
- Bulk of changes were for demo/test
- Some changes were done to ensure "Update Quantity"/"Inventory Report"
views still mainly function the same as before with the exception of a
new column added to support updating quant quantities in these views.
Task: 2440026
ENT PR: odoo/enterprise#17329
Upgrade PR: odoo/upgrade#2326closesodoo/odoo#68409
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
We introduced new Smart Putaway Rules.
Locations now can have a storage category, on each storage category,
we can specify the amount of products/packages(with certian package
type) that can be stored in the location.
On putaway rules, we can also set a storage category. Now when apply a
putaway rule, we will find a suitable child location of the out
location according to quantity/weight setting on the storage category.
Task 2341820
PR #63516
ENT PR odoo/enterprise#15363
UPG PR odoo/upgrade#2040
Let's say we have location A, B, and C. A is the parent of B, B is the
parent of C. And we have a putaway rule to move product from A to B. Now
receive product at C, because currently when we can't find a putaway
rule at one location, we will loop to check its parent locations. So the
puteaway rule A -> B will be found, and product received at C will in
the end be stored at B.
After this commit, we don't check the parent locations when we can't
find a putaway rule.
Task 2341820
PR #63516
ENT PR odoo/enterprise#15363
UPG PR odoo/upgrade#2040
This method is useless and it bypass the computation of some fields
(qty_available, virtual_available, incoming_qty, outgoing_qty). Then
this method is not cache-friendly, and we should use `read` instead.
task-2439019
closesodoo/odoo#66621
Related: odoo/enterprise#16584
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Currently the non-reserved moves in the availability report are sorted
by priority, date, id (same as reserved moves). This commit makes it so
non-reserved moves are now sorted by reservation_date first + the
previous ones (i.e. different sorting logic from the reserved moves).
The idea is to make it easier to reserve moves according to the set
reservation_method logic. Unfortunately there isn't an easy way to split
the sorting logic and we need to search for some overlapping moves
ordered in a different way.
closesodoo/odoo#65730
Task: 2418907
Related: odoo/upgrade#2143
Signed-off-by: Rémy Voet <ryv-odoo@users.noreply.github.com>
This commit adds 2 small feature additions to reservation logic:
1. Add another # days parameter for reserve "before scheduled date"
option for priority moves (i.e. so they can be marked for reservation
earlier)
2. Add Reserve button in the forecast report
It also cleans up some auto-reserving logic:
- 'at confirm' now has a reservation_date = day of confirmation:
- removes need to check `reservation_method` when doing automated
_action_assign (i.e. in scheduler + completed incoming move).
- allows ordering by reservation_date during automated _action_assign
for more consistent and logical reservations.
Task: 2418907
Upgrade PR: odoo/upgrade#2143
In simple search by qty_available we use optimized method. Before this commit
that method didn't work when product doesn't have stock moves and domain
includes zero qty, e.g. ``[('qty_available', '>=', 0)]``, ``[('qty_available',
'=', 0)]``, etc
The problem comes from https://github.com/odoo/odoo/pull/66652closesodoo/odoo#68042
X-original-commit: 629ce193e4725919c1aeede000517564f0e8adf1
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Signed-off-by: Ivan Yelizariev // IEL <yelizariev@users.noreply.github.com>
The run_push() method may change the location_dest_id of the stock move
but not the associated stock move line. That can produce a
de-synchronisation between stock move and stock quants as those are
updated by the stock move lines.
This commit ensures the location_dest_id of the stock move is also set
on the move lines in run_push()
opw : 2427301
closesodoo/odoo#67460
X-original-commit: 7dafde71c0591be74f9d433976243342b1b3e635
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
Add and improve onchange warnings when a duplicate SN is used in
following cases: inventory, picking (any type), manufacturing, scrap,
and "Update Quantity" (i.e. directly edit quants from product form).
Improvement includes:
- include location where the existing SN is
- auto-correct source location when appropriate (e.g. trying to scrap a
SN in the wrong location)
The goal of this is to prevent but not restrict duplicate SNs so users
can have some flexibility (especially if a dupe SN occurs because of an
error such as doing pick-pack-ship out of order.)
closesodoo/odoo#61287
Task: 1924758
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Replenishment is great to replace MTO but misses the direct link between SO and PO (smart buttons on both SO and PO to link to the corresponding PO and SO).
The info is actually there in the forecasted report but it is not accessible directly from the PO and in the case of the SO does not highlight the corresponding line of the SO.
This adds a graph icon in the PO, MO and receipt form to directly access the forecasted report (it already exists for SO and delivery).
The information linked to the SO/PO/MO/receipt/delivery is also sent to the forecasted report to highlight the corresponding line.
Note that in the case of the SO, the information needs to go first through the qty_at_date widget (which contains the link to the forecast report).
The graph icon for the PO, receipts and MO turns red when the forecasted quantity at expected date is negative. This is done using the new 'forecasted_issue' field.
closesodoo/odoo#62264
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
When a new warehouse is created, the receipts of the purchase orders done in
this new warehouse have different behavior than the ones from the inital
warehouse. With the new warehouse the 'Detailed Operations' tab of the
receipt is visible but not the button next to 'Done' in the 'Operations' tab.
Since no elements are inside the 'Detailed Operations', it requires a manual
entry of all elements for every receipt with backorder.
This aligns the behavior of new warehouses with the inital one, not
showing the 'Detailed Operations' tab in the receipts but allowing to use
the button of the 'Operations' tab.
closesodoo/odoo#65501
X-original-commit: 126102b5b4cd9aa32fb3eb9a763d73e4056d3462
Signed-off-by: Rémy Voet <ryv-odoo@users.noreply.github.com>
Signed-off-by: npi-odoo <npi-odoo@users.noreply.github.com>
In order to have always a picking_type_id on a stock move (and
consistent with his parent model), make it compute store.
Then clean the call of picking_type_id without change the behavior
(/!\ `move.picking_id.picking_type_id != move.picking_type_id` because
of mrp). Fix some test where the location(_dest) was unset in moves.
Also:
- Clean the mess in the create of `stock.picking` about that
and add a onchange to keep location(_dest) consistent with moves.
- The move `description_picking` is set when the `picking_type_id`
change, not only at the create method.
task-2373638
Behavior prior to this commit:
If I have a pre-existing order (confirmed, but without available
product) on a product with an MTO route, and I now place a new order on
that product then confirm the generated PO, in the forecast report the
quantities from the PO will be shown as being applied to the
pre-existing order first.
For example:
- create a product with an MTO route (set a vendor)
- create a SO (SO1) for 5 units of that product and confirm it. Verify that
a PO (PO1) was generated. Cancel the PO.
- create a new SO (SO2) for 10 units of the product and confirm it. Confirm
the PO (PO2) that is generated.
- run the forecast report. It should show:
| Replenishment | Quantity | Used By |
|------------------------------------|
| PO | 10 | SO2 |
| Not available | -5 | SO1 |
But instead it shows:
| Replenishment | Quantity | Used By |
|------------------------------------|
| PO | 5 | SO1 |
| PO | 5 | SO2 |
| Not available | -5 | SO2 |
When the product is received for PO, the quantity received is correctly
applied to SO2, not SO1.
Behavior after this commit:
- when generating the forecast report, we have to tie each outgoing
shipment with 0 or more incoming shipment. After this commit, the
computation will be made without considering candidate incoming
shipments that are linked (via `move_dest_ids`) to a different
outgoing shipment.
- for receipts that are not tied to another move (move_dest_ids is
empty), there is no change of behavior
- for receipts that are "over-delivering", for example if there was a
generated PO for 10 units but they manually increased it to 15 to cover
both SO, there is no change of behavior: it will still show as
replenishing both SO.
Note:
- in a multi step environment the report does not correctly allocate
quantities once some steps of the order are processed (the quantity
will be shown as coming from stock, but in fact not all steps have been
processed), this is accepted as a known limitation to prevent making
too much of a performance hit for the MTO case (this behavior is the
same as what was present before the commit)
opw-2412137
closesodoo/odoo#63529
X-original-commit: 95435c056236438c61688855748b3afac57416a2
Signed-off-by: Nicolas Galler <ngaller@users.noreply.github.com>
- Set the Delivery in 2 steps in the warehouse
- Create a 'wave' route:
- Sequence: 5
- Apply on Product Categories
- Rules:
- Action: Pull From
- Operation Type: San Francisco: Pick
- Source Location: WH/Stock/Chairs
- Destination Location: WH/Output
- Supply Method: Take From Stock
- Propagation of Procurement Group: Fixed
- Fixed Procurement Group: Chairs
- Create a 'Chairs' product category, apply the wave route
- Create a 'Chair' product:
- Category: Chairs
- Storable
- Make some stock in WH/Stock/Chairs
- Create a SO for 1 Unit of Chair, confirm
=> a picking from WH/Stock/Chairs to WH/Output is created
- Create a SO for 2 Units of Chair, confirm
=> the 2 units are added to the previous picking
However, the 2 stock moves are not merged.
It happens because `date_deadline` prevents the grouping.
opw-2390630
closesodoo/odoo#62983
X-original-commit: c4505b704489db7ef47dd9a201def536a99d03f3
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.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 the fix:
- when adding a filter on "Quantity < 0" (or > 0) on the forecast
inventory report the quantity reported becomes incorrect: for example if
there is a restock on Tuesday and a shipment on Friday that drives the
forecasted quantity into a negative, the forecasted inventory report
instead reports a negative quantity on Monday.
- the problem occurs because the view the report is based on is built
using positive and negative entries that are supposed to cancel each
other when accounting for stock items (quant). This way the quantity is
reported as 0 before the quant is moved in the inventory (there is a
positive entry for the quant, and a negative entry for the move up to
the move effective date). But when a filter on quantity is placed the
"cancelling" entries are not loaded and the report ends up with just the
negative value
Behavior after the fix:
- the quantities are reported as expected: with a negative on Friday,
and 0 on the days before
- to achieve this the view was modified to perform the grouping of
forecast entries inside of the view. This way we have one row per
product / day / state and we don't risk selecting only part of the
report.
- as the view is only read in aggregate there will not be any visible
changes to its consumers
opw-2379098
closesodoo/odoo#62574
X-original-commit: c16d4b5e7b9181c2c792f595a117de10510d45be
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Signed-off-by: Nicolas Galler <ngaller@users.noreply.github.com>
Add a new feature to automatically create/update/delete an inventory by
company for products with conflicting serial numbers. The goal
of this is to help track inventory discrepencies and prevent duplicate
serial numbers across different locations.
This follows the same logic as the negative qty count auto-inventory
feature where a dupe SN inventory will be auto-generated / auto-updated
/ auto-deleted when the "Inventory Adjustment" button is pushed and when
the scheduler is run. Note that -1 quantity of an already in use SN
counts as a duplication of a SN.
Note: a new many2many field `lot_ids` was added to inventory to more
easily track which conflicting SNs to do the inventory on.
Task: 2336455
ENT PR: odoo/enterprise#14667
Upgrade PR: odoo/upgrade#1839
Add a new feature to automatically create/update an inventory per
warehouse specific to products with negative qty in any of its
locations. The goal of this is to help track inventory discrepencies
and prevent appearance of being out of stock when there is still stock
left. This is done by having the inventories update/create whenever
the "Inventory Adjustments" menuitem is clicked. Since we don't know
when a product's stock becomes non-negative, we always re-write all the
neg products to existing draft neg inventories and remove any
pre-existing draft inventories that haven't been updated since they no
longer have any neg qty products anymore.
Scheduler will also trigger this recalculation in hopes that it will
reduce having a large number of inventories to create when the inventory
menuitem isn't opened very often.
Note: a flag `is_conflict_inventory` was added to avoid conflicts with
manually generated inventories.
Task: 2336455
ENT PR: odoo/enterprise#14667
Upgrade PR: odoo/upgrade#1839
Add a new feature to allow automated (as part of scheduler) generation
of inventory adjustments based on user set value for how often they should
be done for 'internal' and 'transit' locations.
- When is the inventory created?
When cyclic frequency is set to a non-zero value, the next date an
inventory should be automatically generated for a location is based on
whether or not a previous inventory for that location was completed.
If an inventory is overdue based on the previous inventory date, one
will be scheduled for tomorrow. If no previous inventory date exists,
schedule the next one based on today's date. A new inventory will be
created by the scheduler if there is not an existing in progress
inventory for the location (to avoid a conflict).
- What about descendant locations?
Descendent locations will not have an inventory created if their
ancestor is supposed to have a cyclic inventory done at the same time.
Note this includes when that ancestory already has an in progress
inventory and isn't having a new one created.
- What about cleaning out of date cyclic inventories?
This automation will also delete existing draft inventories that include
this location (created before the day the scheduler is run) or any of
its descendants (i.e. inventories with only that descendant location
selected to avoid deleting obviously manually created inventories).
Task: 2336455
Upgrade PR: odoo/upgrade#1839
One can set a Unit of Measure precision rounding more
precise than the overall Decimal Accuracy. This can trigger the error
'It is not possible to unreserve more products', as there will be
inconsistencies on reserved quantities due to decimal roundings.
We add 2 warnings on Units of Measure and Decimal Accuracy.
Therefore, users are warned when their UOM/decimal changes can
cause inconsistencies in quants reservation.
Also, we want to prevent the issue at the root by ensuring that both the move
and the quant have the same reserved quantity.
The contrary can happen e.g. when a product is defined in Liters (rounding .001)
but used in an operation in ml (rounding .01, so e.g. 187.5ml).
The conversions between the 2 UOM can cause the differences of reservations.
In _prepare_move_line_vals we make sure uom_quantity_back_to_product_uom
is not more precise than the overall Decimal Accuracy. That way, if
the reserved quantity changes between UOM conversions, the move line created
is in the quant/product UOM, and we do not have move line's reserved quantity >
quantity in stock.
We do the same for _update_reserved_quantity (stock.move), when updating
a move line.
In _update_move_lines, because of UOM conversions, new_quantity_done
can differ from ml.product_uom_qty, which triggers the creation of an extra
move line, leading to reserved quantity > quantity in stock. To prevent
that, we compare the reserved quantities in the product UOM.
opw 2206902 (Example 1)
opw 2171541
opw 2221227
opw 2233937
opw 2198775
and many more
closesodoo/odoo#62279
X-original-commit: 478a42beb5876171afeab7df27fa69548edbf849
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
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>
In this commit, creating SM from SML if trasfer is immediate. Due
to which following issues are getting resolve -
For immediate trasfer -
1) Unable to cancel the picking in draft state and SML is created
by view directly (No SM).
2) Unable to see button Put in pack.
3) Picking remains in state draft instead of ready.
task-2275833
closesodoo/odoo#61887
X-original-commit: f933c15794ec733be51d879de2410302d9804121
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
- 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>
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>
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>
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>
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
Mainly transifex issues but also some errors found through 'grep' checks.
Fix typos and obscure english strings in xml contents, fields strings/helps, some docstrings, ...
ensuring correct translations base (and fallback when translations isn't available).
closesodoo/odoo#57276
X-original-commit: 4214f05d454bca2b60fda3a288d529c098e84f77
Related: odoo/enterprise#13053
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Values for "context" and "data" key were injected into the action
dictionnary by report_action to be used by the /report controller
later
Courtesy of William Henrotin (whe) for the test
X-original-commit: 4d43a301fd10cfeb498d9bf6b614779e26e12d16
PURPOSE
Lessen use of mail-specific calls and variables
SPECIFICATIONS
Use mail_new_test_user tool in tests, lessening use of mail-specific context
keys in tests.
LINKS
Task ID-2326281 (context keys use cleaning)
PR odoo/odoo#56631
PR odoo/enterprise#12707
X-original-commit: 910559c092dc7dfa00b91339a5423e16cd4668e1
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
Allow to add serial numbers as tags on the move in production order and
stock picking. The purpose is to earn time for database with
only tracking installed.
Also when only create_lots is checked on picking type. New lots
could select existing lot and an onchange trigger a warning if
it's used.
closesodoo/odoo#55883
Task: 2280985
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
- The deadline of MO generated via procurements is calculated differently.
Now, it doesn't take anymore in account the manufacturing_lead
of the company (Security Lead Time of MO). The computation of planned date remains unchanged.
- The date_expected fields was duplicated with the date fields
except when the move was done. Merge both fields.
The only information lost is: we can't know what was the
scheduled date before processing move (`state` == done).
Indeed, the date becomes the actual move processing datetime.
- The `date` in `stock.picking` field contained the time of
(purchase) order `date_order` (`purchase.order`).
This field is was wrongly used in the kanban view where we
expected to see date_planned instead. Also, the `_order` used
this date instead of date_planned too.
- The `delay_alert` is activate independently of stock rules.
Then it is now activate in all case.
- Remove the auto-reschedulting process of stock move via
the stock rule (`propagate_date` and `propagate_date_minimum_delta`).
Replace it by a automatic deadline date (`date_deadline`) propagation.
The deadline is the promise done to/by vendor/client (SO/PO)
then it is a readonly fields on picking/move and MO.
- Now the Scheduled date (`date`) of stock move is never propagate
and it is only related to the Scheduled date of
related document (MO or picking).
- Now when a move is created from procurement (sale),
`date_planned` = `date_deadline` - `security_lead`.
- The `delivery_date` of sale is no editable after confirmation
and propagate as the deadline to related stock move linked to order_line
- Adapt filter and decoration of MO and picking.
- Because we are the client in case of purchase (PO), the promise of vendor
can be not respected. Then we add the lead security to the deadline
(inverse the sale order logic) of PO picking (promise reciept date
+ security lead) to match with the replenishment.
task-2246665
Adds the Replenishment Report, a printable report on product variants
and product templates. This report displays all draft and planned moves.
It has also the purpose to be overridden to handle purchase and sale
lines, and product's consumptions/productions of manufacturing orders.
Documents listed in the report can be accessed by clicking on their name.
task-2058495
Co-authored-by: sle-odoo <sle@odoo.com>
1) Create a stockable product > Add some quantities on hand
2) Edit this product > set it as a consumable or service
3) Create an inventory adjustment on all products
Error will raise "Something went wrong! You can only adjust storable products.
This occur because when switching product type the available quantity
was not cleared, so it will get in the next inventory, but only storable
products can have inventory. So the product should to have no
quantity left before switching type
opw-2300478
closesodoo/odoo#55062
X-original-commit: be17e31307070498ba9ac7dc594443730caa7404
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: agr-odoo <agr-odoo@users.noreply.github.com>
1. When reservation can't be done for some products, we automatically
evaluate their reordering rules and create the corresponding
replenishment document.
2. When receiving products in stock, automatically check if some stock
moves are available and assign them.
Task 2244230
PR #52433
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Arnold Moyaux