1. add packaging to PO lines
2. packaging on PO/SO lines can be propagate to MO
3. add package type to packaging
4. on picking types, we can choose to only reserve full packaging. That
means if you want 1 pallet(100 units) and you have 50 units in stock. It
won't be reserved.
5. suggest suitable packaging for PO/SO/MO line according to the product
qty
Task-2357259
PR #68654
UPG PR odoo/upgrade#2444
Before this commit, when quants where automatically unlinked, all empty
quants were took.
Now, quants with a defined `user_id` will not be unlinked because they
can legitimately be to 0 and we should wait inventory was processed
before empty quants were unlinked (as once the inventory is processed,
the `user_id` on quant is removed).
closesodoo/odoo#70275
X-original-commit: 7c5143e95ef1fcceafe5e331c3e8649e08666ae7
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Signed-off-by: Steve Van Essche <svs-odoo@users.noreply.github.com>
The attributes field.depends and field.depends_context are problematic
for sharing fields across registries, because they depend on the model's
registry class, which may vary from one registry to another. In order
to make computed fields shareable, we have to move those values away
from fields.
For the same reason, field.recursive should not be inferred, because its
value may depend on the registry, although it is generally not the case.
Moreover, the flag recursive=True is set on a field when field triggers
are determined (on the registry). A compute method may be called before
the flag is set (if no update has been done yet), and that can lead to
incorrect computations.
This happened in test TestUsers2.test_reified_groups in module 'base'.
The user groups view was apparently determined without the flag being
set, and the view depends on the recursive field 'trans_implied_ids',
which was not correctly computed.
We thus force developers to be explicit about recursive computed fields.
The code now logs a warning when the flag is not set up properly.
add the name of argument, if not precision_digits is used.
closesodoo/odoo#70242
X-original-commit: 2e7dfec50e9104adf8efbc64e0342359dc8947a7
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
- Create SO with deliverable product, confirm
- Change delivery Address on SO and on Transfer
- Inventory > Stock moves (debug mode)
- Group by > Picking and Destination address
The address shows is the original and not the updated one.
opw-2429018
closesodoo/odoo#67407
X-original-commit: c813655074b3b83bdf9345ef12399b0b96feaf71
Signed-off-by: agr-odoo <agr-odoo@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
Currently, delivery packaging and product packaging share the same
model product.packaging. In this commit, we make delivery packaging
a new model stock.package.type. The code is also moved to stock
instead of delivery for compatibility reasons.
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>
To avoid multiple search of the get_warehouse for the same location
and extra SQL request (it happens a lot for complicate flow, e.g.
mrp_mps, replenishment report).
Translate it into a standard compute to use the cache of
the ORM for no-store compute field (`warehouse_id`) and put
some depends to be always correct (even if `warehouse_id` shouldn't
change in the same request).
task-2439019
This commit is a revert of revert 561b3461a0
and 97ba860fd38c530d3f3678f676754862afad0f11.
Previously we split moves when no picking, now we consider it
unnecessary.
Task 2446915
COM PR #66583
ENT PR odoo/enterprise#16554
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
Allow unit of measure ratio change when there are no product currently reserved
or in stock using this unit of measure.
opw-2455914
closesodoo/odoo#67827
X-original-commit: d78238843ea8933b62d340d1b231a12e94bbf957
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Signed-off-by: Jean-François Aubert <ajf-odoo@users.noreply.github.com>
Before this commit, when delivered qty. for a product tracked by serial
numbers and then create a returns for this product, as the move is
linked to its original returned move, when the detailed operations will
be displayed, it will hide `lot_name` field and display the `lot_id`.
The issue is it will still show the "Assign Serial Numbers" feature.
As this feature is for the creation of new SN only (not for assign
existing ones), it should be hidden in this case because it will lead to
attempt to create already existing.
How to reproduce:
- Create a product tracked by serial numbers;
- Add at least two qty. on hand for this product and create as many
serial numbers, following by numbers (ex.: sn01, sn02, sn03, ...);
- Make a delivery for at least two of this product and proceed it;
- When it's done, make a return for this delivery;
- Open the delivery's return and display the detailed operations, then
use the "Assign Serial Numbers" to try to reassign the delivery SN.
--> First, we will not see the SN on the move line (as `lot_id` is
visible but `lot_name` is invisible).
--> Second, you can't mark as done the return as it will try to create
the SN but they already exist.
To fix the issue, we can simply hide this feature when we hide the
`lot_name` field.
task-2474919
opw-2455971
closesodoo/odoo#68249
X-original-commit: fab1f31f70376d5477e67d153e2fa3c0f6477397
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
Signed-off-by: Steve Van Essche <svs-odoo@users.noreply.github.com>
Currently we automatically check reordering rules when a product cannot be
completely reserved, which allows to have a replenishment document for the
product without needing to run scheduler. This is unwanted for some users.
In this commit, we allow to disable this by adding a parameter to
ir.config_parameter. To disable it, set a parameter with name
"stock.no_auto_scheduler".
opw 2458507
closesodoo/odoo#68283
X-original-commit: 7ec5bae11ad89514a33db35810f4763e7631125f
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
When you want to validate a picking with a lot of products, the system notifies "You have not recorded done quantities yet, by clicking on apply Odoo will process all the quantities."
Nice and easy, except when you were not able to process all the quantities.
In that case you have to update all but the few lines manually.
Also added to batch pickings
task-2158092
closesodoo/odoo#58487
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
In this commit -
1) Added new field propagate_carrier_id in stock.rule and propgate
carrier in PICK PACK and SHIP if it is ticked.
2) Allow to print Label at any stage of PICK PACK and SHIP after
validation of picking from chatter.
Task-2363484
closesodoo/odoo#62851
Related: odoo/enterprise#15148
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
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>
If some RR is archived and where the a forecasted demand on the
warehouse location, it Replenishement will crash will due to the
SQL constraint. It happens because the archived RR aren't take in
account in `_get_orderpoint_action` and the method will try to
create a orderpoint with same product + location which
lead to trigger the SQL constraint `product_location_check`.
Also avoid filtered in for loop to improve performance and use the
read_group instead.
task-2439019
closesodoo/odoo#67936
X-original-commit: 6737feef848dc47120cf3d2cca84e033e869c985
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Signed-off-by: Rémy Voet <ryv-odoo@users.noreply.github.com>
The replenishement creation currently calculates the quantity to order
using a default multiple quantity of 1. In case of manufacturing route,
we want to calculate the multiple quantity according to the quantity
produced in the BoMs.
closesodoo/odoo#62766
Signed-off-by: Rémy Voet <ryv-odoo@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>
- Have a storable product with 3140.0 quantity on hand
- Make a sale order for 3106.40, confirm and validate delivery
- Reserved quantity will be 3106.40
- Make another sale order for 33.60, confirm and go to delivery
- Reserved quantity will be 33.59 because of a rounding issue when
calculating the available quantity
opw-2449732
closesodoo/odoo#66635
X-original-commit: bb411a2f125a09713eb749b6884308a8c2f15f36
Signed-off-by: agr-odoo <agr-odoo@users.noreply.github.com>
Do a transfer in two steps with several move lines (e.g.: Vendors => Input => Stock).
In the first picking, set quantity = 0 on a single line. Transfer it and say 'No backorder'.
In the second picking, set all quantities (you have two move lines confirmed and one canceled). Validate the
transfer. The backorder wizard is launched. It should not.
closesodoo/odoo#66680
X-original-commit: 79d834f2c2ec167831fe0986afb728207a467d67
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Commit e5ab8cf9623bc436f43706926bc6ee596c549244 missed a use case.
Steps to reproduce:
- Activiate "Packages" setting in Inventory
- Configure an operation type to "Move Entire Packages"
- Create a "Planned Transfer" picking with that operation type and add a
package to be moved
- Turn off "Move Entire Packages" and try set the destination
package of the move line to nothing (False).
Expected result:
Move line has no destination package + package level is deleted as
expected.
Another bug will still exist due to the design of package_level where if
in addition to the above use case, if a different package is used instead
of deleting it and "Move Entire Packages" is reactived => final package
shown in the Detailed Operations will show all move lines as being part
of the same package even though they are not. Data appears to be correct
in the database otherwise and a reasonable fix doesn't seem feasible for
now so we leave this bug as is.
Related to Task: 2418907
closesodoo/odoo#66638Fixes: odoo/odoo#66542Fixes: odoo/odoo#66517
X-original-commit: a73505ddafe9ce6f4f3e9896494900d419a815bd
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Currently we always auto-reserve products for moves when other incoming
picking makes the product available. This is unwanted for some users.
In this commit, we allow to disable this by add a parameter to
ir.config_parameter. To disable it, set a parameter with name
"stock.picking_no_auto_reserve".
PR #66373closesodoo/odoo#66436
X-original-commit: 04424cddf1e28a52fd7df3ad954d2d484b52972e
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Add a warning to explain that create a second
warehouse will activate the multi-location automatically.
task-2439909
X-original-commit: 4964a9482b8b195f5b629ea5c91f7d7bfcce2163
When we create a second warehouse on a company, the
multi-warehouse and the multi-location is automatically
activated. But a user can desactivate manually the multi-location
which leads to a misconfiguration (no sense to have multi-warehouse
without multi-location)
Add a UserError to avoid this case.
task-2439909
X-original-commit: e3549ae8eefe9bc3029ea7f50eed479d113b4687
Currently a package level is created and has the newly created package
assigned to it when "Put In Pack" is used. Unfortunately if a move line
has its result_package_id changed after having a package assigned via
the Put In Pack, then the package level's package_id isn't correctly
updated. This leads to incorrect data in the db. This incorrect data
doesn't affect much since result_package_id from an entire package move
cannot be changed in any views, but it does mean that the created
package associated with the package level can never be deleted even if
it's never used.
Steps to reproduce:
1. active (delivery) packages in settings
2. create a picking and create some done values
3. use "Put In Pack" to put done move lines into a package
4. change the newly created Destination Package to another package
5. Go to Packages and try to delete the package created by Put In Pack
Expected result: able to delete the package
Actual result: Server error that package is still required by Stock
Package Level.
This is a short term fix. In the long run it would be better to fix the
package_level logic so it isn't unnecessarily assigned to moves/move
lines and/or updates in a cleaner way.
Task ID: 2418907
closesodoo/odoo#66406
X-original-commit: e5ab8cf9623bc436f43706926bc6ee596c549244
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Small improvements to the Product Moves (move line) report:
- added 3 new filters: Last 12 Months, Last 3 Months, and Last 30 Days
(default Last 12 Months)
- added standard Date filter (i.e. by quarter, month, year)
- updated the Stock Moves stat button in product [template] view to
display # incoming/outgoing moves within the past 12 months
Task: 2371067
COM PR: odoo/odoo#63598
Signed-off-by: Steve Van Essche <svs-odoo@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>
When checking the replenishments, it sometimes creates a new reordering
rule for a product while another already exists.
To reproduce the error:
(Need purchase,sale_management)
1. Create a product P
- Must be storable
- In Purchase tab, add a vendor
2. Create a reordering rule for P
- Trigger: Manual
- Min: 0
- Max: 0
3. Create+Confirm a SO with P
4. Go to Inventory > Operations > Replenishment
5. On P-product's line, click on "Order Once"
6. Confirm the generated RfQ
7. Repeat 3-4
Error: There are now two lines for P-product. A second reordering rule
has been automatically created but the first one does already the job.
OPW-2431780
closesodoo/odoo#65142
X-original-commit: a9d5bd2ebb28a9bf0aa8d4adb0992582e85c54fc
Signed-off-by: Adrien Widart <adwid@users.noreply.github.com>
Modifying product attributes involves discarding product variants via
the method _unlink_or_archive(), which tries to delete variants, and
archive the ones for which the deletion fails. This process is very
slow when most product variants must be archived. Instead, we filter
out the variants that must be archived anyway (like the ones used in
sales or stock), in order to avoid the variants that cannot be deleted.
On a product with ~200 variants, the time goes from more than 15 minutes
(the request times out) to around 5 seconds!
opw-2440417
closesodoo/odoo#65027
X-original-commit: 63b2f85079404eafac918a74c95e27051539c133
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Avoid to filter in a loop and use a read_group instead to group by
product-warehouse outside.
Also remove costly useless code.
Performance gain
----------------
On a large database (120K stock move, 5k product) where
+- 700 manual orderpoints will be create during the open of the
replenishement report:
Before:
16.14 +- 0.16 sec of python. (SQL time is +- 14 sec)
After:
1.33 +- 0.91 sec of python. (SQL time ==)
task-2390516
X-original-commit: 569b45d5cb139825690a90189b7a360f3fa89815
`o.location_id.id == g['location_id']` =>
`Comparing apples and oranges: stock.location(243,) == (219 ...`
replace by the correct code and avoid warning.
task-2390516
X-original-commit: 461a3e737c4ffe048b738dd09f83571602324257
Replace union of RecordSet by union of OrderedSet to reduce the
complexity and improve the scalability. It can be a bottleneck to
huge number of move to assign.
task-2390516
X-original-commit: e89105144a34ee73981db383ac0625dcaf63b27b
yhu-odoo