`_action_done` could unlink a quant. This happens when moving a product from a
location to another one and makes null the quantity of this product in one of
theses locations. In this case, we unlink the quant because it is now useless
and could be confusing on reports based on quants.
The unwanted side effect is that unlinking a record will invalidate the cache. In
some pathologic cases, like making an inventory adjustment of 600 products
and reseting their quantity back to 0, the time of the operation is around 15
minutes. With this patch that tries to work carefully with the cache invalidation,
the same operations takes around 15 secondes.
This commit do not unlink quant anymore, instead it use a 'garbage
collector' on quants without quantity. The garbage collector is trigger
on the scheduler and when the user open the inventory view.
A new exception has been added to detect inconsistent reports. However, many are not structured as expected. Thus, the change consists mainly of checking only when the print has to be separated in part to attach it to the respective documents.
We now take the page tag instead of the article, because the article tag is in the layout, so to separate the file, the t-call had to be inside the t-foreach (for the separation) and so possibly read the assets several times. Since all templates have the first tag (in the t-foreach) tag page, the choice is more sensible.
The javascripts files used in readonly were taken out of the editing assets.
A turn was made but not activated, it works locally, but on the runbot, an error is triggered when generating assets after choosing the settings.
In the detailed operations view and in an immediate transfer:
- add a line
- select a random lot_id
- select a random product_id
- validate
The system won't raise while the combination of product_id/lot_id may
not make sense. We add a constraint to solve this isse.
Closes#25766
opw-1868453
Usecase to reproduce:
- Create a receipt for 1 dozen.
- Mark as todo
- Unlock and update initial demand to 3 dozen.
The reserved quantity on move line is 36 dozen.
It happens because reserved_availability and product_qty are
compare. However reserved_availability is in move UoM and product_qty
is in move's product UoM.
This commit clean the code in order to compare field that use the same
UoM.
Close#26504
- Create a product A tracked by S/N
- Get some stock of A
- Create a SO and sell 1 unit of A, confirm
- Go to the picking, validate
An error message forces the user to manually encode the 'Done'
quantities.
This step is not necessary, since the user will still get a message
notifying him that the reserved quantities will be used as done
quantities.
opw-1873180
Currently MRP do not handle multi locations for components. In order to
be able to use both feature at the same time, we could:
- Improve mrp in order to handle multiple stock.move.line for a
componenet stock.move
- Add a rule that allow to bring all the good from multiple location to
a single location. (was already possible but it requires some
configuration)
This commit introduce a checkbox on the warehouse in order to
automatically configure all the routes/rules/locations/picking_types,...
necessary to bring all the components to a single location before
running the manufacturing order.
Technically it also refactor some stock_warehouse.py methods in order to
easily override the picking_type, rules and routes creation.
Thank to Hetashree Chauhan <hch@odoo.com> for his help.
task_id: 27785
From this commit onwards, Date fields will return datetime.date objects and Datetime fields will return datetime.datetime objects, this implies a number of things that are clearly explained both in the ORM API for master.
This commit also introduces a number of helper functions for dates and datetimes that are exposed in tools.date_utils and fields.Date[time], explained in the documentation as well.
Task-ID: 47189
The default resupply feature can be configured by going on the route and activating
it for the warehouse. This field is therefore useless and this commit remove it.
The field 'resupply warehouses' is reworded an hidden when there is only one active warehouse
PR:22085
TASK:38933
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.
Usability improvement:
- Common view for push and pull rules
- Add an help text in order to describe the rule
- Rules menu
- Warehouse checked by default on route created by a warehouse
- Lower the MTO route sequence in order to take it first.
- Tooltip cleaning
Technical improvement:
The purpose of this task was also to merge stock.location.path(push rule) and
procrement.rule. Those two model were design to execute the same task
but in a different direction. Thus it contains duplicate code.
Task ID 1852969.
PURPOSE
=======
1. Unified product demo data
2. Less demo: one per use case
3. Demo data for all models
Specification
=============
1. Refactor all the brol in the demo data
2. Adapt the tests to make them green, as some products are
renamed, removed, created in python instead of as demo data
...
The method 'action_done' on inventory adjustment became private and the
action launched from the view is now 'action_validate', so we adapt
those tests to use the new function.
TASK-30921
When you have some product tracked in an inventory adjustment, the
lot/serial number is not required, so when you confirm an inventory
adjustment with product tracked for which you didn't provide serial/lot
number you get a warning to inform you.
TASK-30921
Usecase to reproduce:
- Update quantity in stock with a product inside a package
- Reserve a picking with this package.
- Go on the package form view and unpack it.
The package does not exist anymore on the quant, the reserved move line
still having the package as source package.
When the user try to unreserve the move lines, it will try to unrerserve
a quant with this package that does not exist anymore and then return
the error message 'can not unreserve more than you have in stock'.
This commit removes the source package on move lines that contain the
unpacked pack.
This commit block users to change the location usage (or set it as scrap
location) if there are moves starting from this location.
This commit ensure the stock management will remain consitent.
Task id : 1844684
This commit block users to change unit of measure factor. if there are
reserved move on product using this UoM. This will allow the quantities
to be correctly unreserved when the stock move will be confirmed.
Task id : 1844684
Use case to reproduce:
- Create a production warehouse that manufacture and a supply warehouse that deliver your product (manufacture and supply dist. WH checked on prod WH.)
- Create a product with a BoM and resupply, MTO and manufacture checked on its routes.
- Modify the resupply pull rule that go from prod/WH to transit location
from MTS to propagate
- Create a Quotation and confirm it.
The user error 'no procurement rule found' is raise.
It happens because the move from customer to Prod/WH are correctly
created but the rule manufacture is not found. It couldn't be find
due to a wrong warehouse on the stock.move. The pull rule use the
supply warehouse instead the warehouse that they serve when they
generate the stock move value.
This commit remove the propagate_warehouse_id on the second rule between
the stock location and the transit location.
- Create a product with -4.0 Units in stock
- Set the Buy and MTO routes, assign a vendor
- Create a SO for 25 Units
- A PO of 25 Units is created => validate and receive products
- Check availability on the picking linked to the SO
Nothing is reserved, while 21 Units could be reserved.
opw-1850688
Co-authored-by: Nicolas Martinelli <nim@odoo.com>
As for consumables stock levels are not that important,
it should be ok to scrap a consumable at all times,
even if the stock becomes negative.
Tests were added to check what happens with a consumable/stockable
product if stays positive/goes negative.
Arnold Moyaux