Usecase to reproduce:
- Create a MO for 5 final units
- Reserve all the components
- Produce 3 units
- Post Inventory (debug mode)
- Edit/Unlock
- Edit a line to consume to an arbitrary amount of quantity
- Change the product qty and set it to 3.
At this point, the reserved quantity and the quantity to consume
still the same than intialy even if the final quantity was updated.
- Mark as done
Then a move is marked as done withtout quantity done and still have
reserved quantity.
It happens because the _update_raw_move function do nothing if the
new quantity to consume is equals to 0.
The arguments returns in _update_raw_move still exists for override
but are not used by the chang_prod_qty method. It's not possible to
cancel the move and then find its parents in order to log the activity.
opw-2023653
closesodoo/odoo#34471
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Having 4 products and 3 BoMs:
BoM 1:
product = Finished
quantity = 100 units
- Semi-Finished 10 units
BoM 2:
product = Semi-Finished
quantity = 10 units
- Assembly 10 units
BoM 3:
product = Assembly
quantity = 10 units
- Raw Material 10 units (product.product 5$/unit)
Before this commit, the price for 100 units of Finished product was
500$, which is wrong. The price was calculated using 100 units of
Semi-Finished product and not 10 units as it should be.
Now, the price is 50$
opw-1973347
closesodoo/odoo#33115
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
Test was relying on qty_to_consume getting saved when the produce form
is saved, a behaviour of the SSF which diverged from the actual
client.
After fixing the SSF to behave more in-line with the actual
client (don't save o2m sub-fields unless they're flagged as
force_save) the test is now visibly broken.
Fix it so qty_done is properly updated during wizard configuration /
edition instead of updating the in-database object directly.
closesodoo/odoo#32047
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Before this commit, when a product goes from manufacturing order to
location having putaway strategy, if this product is tracked, the
putaway strategy don't apply.
opw-1948514
closesodoo/odoo#31808
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
On the BoM structure report the price on line with a
child BoM is inchoerent. Also the sum of all lines in
the report is not always equals to the total of the parent
line.
For the first issue, it happens due to commit 17b6256955
that use the number of operation cycle as quantity.
The second issue happens because sometimes the rounding is not done
at the smallest level and thus the rounding of the sum is different than
the sum of the rouding.
When retrieving the BOM lines in `_get_bom_lines`, we check the product
attribute values to know if the BOM line should be taken into account or
not. However, we do not do such a check when we retrieve the price in
`_get_price`.
It can lead to an inconsistency between the sub-lines displayed and the
total price.
We need to apply the same filtering logic when getting the price.
opw-1932437
closesodoo/odoo#30917
Usecase to reproduce(or any other way to lower initial demand on move):
- Build a MO with 5 products to do
- Produce 3
- Update the quantity on the mo to 3
-> All the consumed quantity on move lines is dropped.
It happens because lowering the initial demand on a move
will call unlink on its move lines. (increase it will
update the move's state and reassign if it comes from a supplier)
Instead of dropping and reassign the move in order to change
the reservation, it is possible to directly write the new
reserved quantity on the move lines and that will update the
reservation on qaunt directly. Also we don't want move lines
without reserved quantity and quantity done thus we drop them.
closesodoo/odoo#29941
This reverts commit d78b6f5e25.
This constraint is considered too harsh. It was applied to circumvent
inconsistencies when a bom is modified while being used in a
manufacturing order and the user chose to update the quantity to
produce. The current code will look at the existing move if no
intermaddite post of inventory was done else look at the new bom.
A code to re-construct the original BoM from the stock moves isn't easy
to write to handle all cases, one particularly complicated is the
deletion of bom lines of the same product.
We also considered to block the update qty button if the bom is modified
after the create date of the MO, but if we have to read all the bom
lines of all the sub bom in a computed field it may be slow on large
databases.
We thus chose to remove the constraint and think of a better approach in
a future version.
task 1891407
closesodoo/odoo#28155
Usecase to reproduce
- Enable multi locations, multi routes
- Check mrp 3 steps on warehouse
- Create a MO
Raw moves are duplicated. It happens due to commit aeb038747f
The purpose of the commit was to split the rules from SAM to stock.
The pull rule should be in manufacture route and the push rule on the
warehouse. However the push rule was not correctly copied and created a
push rule from prod to sam instead of sam to stock.
Fixes#27962closesodoo/odoo#27965
`_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.
When modifying a BoM that is used in a MO not done, raise a blocking
warning to avoid inconsistenties at production.
Proudly pair programmed with pim <pim@odoo.com>.
Some mrp tests has been adapted to not raise the new error. They used
demo data while they should created inside the test.
This commit is related to task id : 1855566
For example: I want to consume a component A if the product is grey OR yellow.
Currently,the component A will be consumed if the product is grey AND yellow. But this variant never exists as grey and yellow are values for the same attribute. So if the values are for the same attribute, odoo should check for a product that is GREY OR YELLOW (and not GREY AND YELLOW).
TASK-ID: 1865604
Currently if the user want to apply the stock after manufacturing push
rule, he has to select manufacture rule on the product. That could be
easily forget by people not used to rule and route.
In order to avoid the push rule will be applied on warehouse. That means
the user don't have to select the route on the product and it will apply
depending the warehouse.
The pull rule stay on the manufacture in order to avoid confict with
reception route/rule.
Restore and adapt test added from rev[1] and lost during the forward
port because the code was changed at [2].
Note that the original bug is fixed because we now have a produce line
by move line, so we can set the quantity done correctly acrosse the
reservation.
[1] f0028bc837
[2] 2678eba0be
PURPOSE
=======
Make the traceability report available in more use cases.
SPECIFICATIONS
==============
1. Traceability Button on Manufacturing Orders
There should always be a traceability report available on the MO,
no matter if the finished product is tracked or not.
Example 1 : finished product is not tracked
but the components are tracked
Example 2 : finished product is not tracked (qty>0)) but
the components are tracked
Example 3 : no products are tracked
Task id: 1861928
- Create a BOM for Product P with the following component:
Product C, 5.0 units
- Make some stock for C:
2 units in location 1
3 units in location 2
- Create a MO for P, reserve.
When trying to produce an error arise:
> Cannot set the done quantity from this stock move, work directly with
> the move lines.
If the user tries to unlock the MO in order to set the done quantity on
the move lines, the same error will arise when trying to produce.
In the specific scope of the production, we set the quantity done on the
move line instead of directly on the move, to avoid this limitation.
opw-1871241
Co-authored-by: Arnold Moyaux <arm@odoo.com>
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
Finished product moves from a MO where created without warehouse_id.
It implies that push rule based on warehouse where not trigger on those
moves confirmation.
This commit adds warehouse_id on unbuild/production's finished/raw
moves. It also add a test for this behavior.
Task ID - 1865574
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
New test :
- Create a MO with a finish product tracked by SN with a dozen as
quantity
- Click on produce button in order to open the produce produce wizard
The quantity to do is 1 dozen although the tracking is by serial number
Task #55494.
Refactor resource calendar and resource mixin:
- add a required timezone field on models 'resource.calendar' and 'resource.resource';
- resource calendar attendances are now computed in the timezone of the resource
or the calendar;
- improve API of 'resource.calendar' and 'resource.mixin';
- avoid other modules from using the implementation methods of 'resource.calendar';
- refactor implementation of 'resource.calendar' to make it more efficient.
Moves UoM models, test and data to a new addon in
order to be able to use uom without product.
A simple example is be to be able to use UoM for
timesheets.
This commit only move code, and adapt xml ids
without chaging any feature or functionnal
behavior.
Note: 'product' module now depends on new
'uom' module.
It happens due to workcenter working hours,
the workcenter is not active during the weekend thus
the productivity loss are not counted in the oee.
This commit removes 2 days to the test date if it is
during the weekend.
Usecase to reproduce:
- Set a product with the same lot in different locations
- Create a MO that will uses theses products and that require more than one location
- Produce it.
-> Traceback Expected singleton: stock.move.line
It happens because product produce only expect one move line
by lot. Howeever it could exist more than one move line if the
product for a specific lot are shared among multiple under location.
This commit try to fill the move line with the correct quantity
one by one and add the extra in a new move line.
Use case to reproduce:
- Create a MO with a product tracked and a qty to produce greater than 1.
- The Bom should also use a routing with at least 2 operations.
- On the first workorder only produce 1 unit and record the production
- Go to the next workorder -> The final lot is not set.
It happens because the lot for the next workorder is only set if the
total quanity for the mo was produced.
This commit fixes the bug by removing the code for the workorder lot
assignation outside the wrong condition. This commit also update the
test test_00b_workorder_process that allows us to find the above bug.
You start with an MO with a quantity of 2 with routing and we
produce just 1. At least one of the components is tracked by lots.
When we update the MO to a quantity of 1 again, the temporary
stock.move.lots continued to exist which led to processing a the consume
d move of e.g. 1 piece with 2 pieces of the quants processed when
posting inventory.
A test is added in order to avoid this case
opw-767526 and opw-772786
When producing a finished product with a lot, also the raw materials
without lot tracking should split the move lines to at least know the
quantities consumed for every lot produced. This way, the traceability
report will not confuse the user.
Use case to reproduce:
- Create a product with a BOM needing one component tracked by SN
- Create a MO for this product with 2 to produce
- Produce 1
- Produce the other -> 2 lines and a wrong lot proposed
This happens when the quantity to consume is equal to 0
or if the qty_done on a move_line is equal to the reserved
quantity.
This commit change the condition after the float_compare in
order to take into account the equal comparison.
Since the function in order to generate a MO is usefull
for mrp test. It could be great if we could use it in
every test.
This commit also add 3 arguments in order to modify the
quantity needed for each product.
Before, in case of non-tracked components, when everything foreseen had
already been consumed, it would not add the theoretical quantity on
producing through the produce wizard. This makes little sense as the
behaviour of the wizard is not the same anymore for all cases and this
can only confuse the user.
This revision changes the BOM and routing of what was previously a
"computer desk". The aim is to provide a complete example which can be
used to showcase what can be accomplished with the new tablet view.
Arnold Moyaux