Steps to reproduce:
-Create a quote with 2 lines (same product - different lead time).
-When a partial delivery is made (e.g., 5 of 10), Odoo places the operation related to the remaining undelivered quantity (5), on the last line in the Operations list.
-When the next delivery is made, Odoo deducts the quantity from the first operation in the list instead of from the line whose deadline is closest.
Current Behaviour :
Odoo assign button assign quantity to the first move line in the list.
Behaviour After the PR:
Odoo assign button assign quantity to a move line based on the priority, the closest deadline and the id.
opw-2657048
closesodoo/odoo#82062
X-original-commit: 430f4f2ca1cebaea62415ee72bf4369684abbfaa
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Signed-off-by: Damhaut Florian (flda) <flda@odoo.com>
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 stock convention on location name is always to name the destination
`location_dest_id`. It was not the
case on the stock rule model
Task: 2648449
Part-of: odoo/odoo#80434
Clean the code for onchange method with putaway rule applied, merge
them into one onchange method.
Task-2614519
closesodoo/odoo#80519
X-original-commit: 5f562895c4d2f9beac7e0458fcee493b0141f1af
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Signed-off-by: Yuchen Huang (yhu) <yhu@odoo.com>
How to reproduce:
- Create a product tracked by lot;
- Create two receipts for this product;
- Use the same lot name in the two receipts;
- Try to validate the two receipts in the same time
=> `ValidationError` will trigger in the `_check_unique_lot`
constrain of the production lot.
task-2646107
X-original-commit: cf018e9f215336ef19e0a517d4e116f0da26850e
Part-of: odoo/odoo#78189
In a lot of test class, we use `setUp` instead of
`setUpClass`. `setUp` is execute for each test method and `setUpClass`
will be execute only once by Class (and use savepoint + rollback).
Then change setUp into setUpClass reduce the time to make all tests
and avoid to repeat this error for the future.
closesodoo/odoo#78082
Related: odoo/enterprise#21563
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.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>
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>
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
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>
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
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>
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>
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>
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>
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
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>
Before this commit, when a backorder is created, it was automatically
reserved. It is no more the case. Now user have to reserve it manually.
The reason is, when a user doesn't delivery all expected quantities, it
could be because there is no enough quantity in stock, or the user
doesn't want to delivery all. In these cases, it doesn't make sense to
reserved it directly.
task-2181611
- Install MRP and Purchase
- Configure the rule 'Stock → YourCompany: Production (MTO)' with:
Supply Method: Take From Stock, if unavailable, Trigger Another Rule
- Create a product AB with route 'Manufacture'
- Create products A & B with routes 'Buy' and 'Replenish on Order
(MTO)', set a supplier
- Create a BOM for AB with:
Product A: 2.0 Units
Product B: 3.0 Units
- Create a MO for 1.0 Unit of AB, 'Mark as Todo'
No RFQ is created for A & B while there is no stock available and a
supplier is set.
This is because the 'MTSO' logic is located in `_run_pull`, which is
never called in this use case since no procurement is created.
We need to apply the same logic in `_adjust_procure_method`, which is
called at MO confirmation.
opw-2189694
opw-2194739
X-original-commit: 9ae3b3e8d2694f5560913682824fd10e60de14a4
Remove the "manual" system alert and replace it by a date field, `delay_alert_date`.
This field is computed in the method `_delay_alert_check` when we write on the date of a stock move.
The method `_delay_alert_check` look to the next stock move and to the previous know to
check if they will be late or not.
If a stock move will be late because of one of the previous stock move, `delay_alert_date`
will contains the minimal date that the stock move should have. Otherwise, `delay_alert_date`
will be False.
Task #1970595
Co-authored-by: sle <sle@odoo.com>
followup of rev [0]
If these wizards are called on multiple pickings, display the list of
the pickings that could be impacted and allow to select which one should
be impacted.
We also adapt the sanity checks at the start of `button_validte` in
order to specify the concerned pickings if needed. We do not enable the
multi behavior for batch at the moment, so it's only enabled for the
validate multi in the list view.
[0] 6ab4b0d496
task-2069646
closesodoo/odoo#41497
X-original-commit: ff276c6484b138982f185ec9c832f2dbf25baaef
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Issue: create an immediate transfer, add a move and a done quantity, the
picking is in waiting state instead of ready.
Due to rev[0], the moves added in an immediate transfer have an initial
demand. After auto-confirming them, their state were 'confirmed' and not
'assigned'.
Solution: we force the state to assigned
[0] 8303b1a69eclosesodoo/odoo#39492
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Before this patch, move added in a planned transfer once it is ready are
directly marked as assigned and the reservation is disabled on them.
People found it hard to understand why the check availability button did
not appear, plus the push rules were not applied.
Now we chose to use the autoconfirm mechanism on the added move and we
don't reserve them, so the check availability button reappear.
task-2081844
`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>
This reverts commit 3431d7b1cd.
Due to recent changes in the orm, editing a draft move crashes. We
revert this commit while we find a proper fix.
closesodoo/odoo#37752
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
on a picking, move_ids_without_package is a subset of move_lines.
The inverse function on move_ids_without_package only work well when we
add a move.
This commit improves the inverse function to take deletion into account
closesodoo/odoo#36558
Signed-off-by: Simon Lejeune (sle) <sle@openerp.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
This branch is the combination of several optimizations in the ORM:
* store field values once in the cache: the cache reflects more
faithfully the database, only fields that explicitly depend on the
context have an extra indirection in the cache;
* delay recomputations by default: use method `recompute` to explicitly
flush out pending recomputations;
* delay updates in method `write`: updates are stored in a data
structure that can be flushed efficiently to the database with method
`flush` (which also flush out recomputations);
* make method `modified` take advantage of inverse fields to inverse
dependencies;
* filter records by evaluating a domain on records in Python;
* a computed field with `readonly=False` behaves like a normal field
with an onchange method;
* computed fields are computed in superuser mode by default.
Work done by Toufik Ben Jaa, Raphael Collet, Denis Ledoux and Fabien
Pinckaers.
closesodoo/odoo#35659
Signed-off-by: Denis Ledoux <beledouxdenis@users.noreply.github.com>
Removes the "Assign Owner" button from picking form view. Now, the stock
move lines owner is set when the picking is validated (if the owner
field is set of course).
The stock move line field owner_id is also hidden for incoming pickings.
Task #1860575closesodoo/odoo#34986
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Error due to other module (e.g. purchase_stock, mrp) that will
define their own rules in order to merge or not moves together.
Usecase:
- Install purchase_stock
- Create a product MTO + buy with a vendor
- Create a SO of 1 unit
- On the PO receive 2 units
- On the delivery deliver 2 units
It will create an empty delivery and put the entire move in
a back order.
First issue the extra move is created as a MTO if it's copied from an
MTO move. So il will trigger all the pull rule. We won't it because it's
an extra quantity and the rules should be only trigger by the original
document (SO/MO).
Also an extra move in a picking do the hypothesis that the original move and
the extra move will always be merged together. But in the previous
usecase, the module purchase add the condition that 'created_purchase_line_id'
and 'purchase_line_id' should be the same in order to merge move.
'created_purchase_line_id' is also copy=False, so the move and the
extra move will not be merged. create_extra_move only returns the extra
move and _action_done only process the moves returned by _create_extra_move.
It result by an original move not merged and not processed by _action_done,
it will be automaticaly set in a back order and the extra move is
processed.
In order to fix it, check if the move and the original move will be
merged. If not, returns both moves.
opw-2008113
Close#34005closesodoo/odoo#34411
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Change the use of Inventory Adjustment, notable changes are:
- Removed filter field: When user creates a new inventory
adjustment, he can set one or multiple locations and/or products.
An inventory adjustment will worry only about defined
locations/products, but if neither product or location was set,
it'll manage all stock.
- Inventory Adjustment Lines have their own view instead of be
listed on the Inventory Adjustment form view.
Inventory adjustment lines have new color legend:
- Red: The quantity is outdated.
- Blue: There is difference between the on hand quantity and the
counted quantity.
New inventory lines created by the user are written in bold.
- User can't modify already existing inventory lines, except for the
counted quantity.
- When an inventory line is outdated, the user has the possibility
to select and update it, that'll recompute the on hand quantity.
- When an inventory adjustment is validated, it will take in account
only the difference between the theoretical quantity ('On Hand
Quantity') and the counted quantity to adjust the quants.
- When an inventory adjustment is canceled, it will keep its
inventory lines and won't regenerate them when re-started.
- When an Inventory Adjustment generates Account Moves, user can now
find them in a stat button in the Inventory Adjustment form view.
Also, made some changes in demo data to match new requirement.
Task #1935921
The goal is to be coherent with the user property.
Actually, company_id and company_ids on the environment are no fields.
Calling env.company_id returns a browse record, not an id.
Florian Damhaut