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.
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.
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 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.
Before, when you would put a quantity in a BoM line that was not rounded
to its UoM (e.g. use 0.3 piece with rounding 1.0) it would not round this
quantity in the MO also (when exploding the BoM), and the user could also
enter a not rounded quantity himself for the quantity produced or
consumed.
The moves were split with the exact quantities, but the moves were validated
taking into account rounded quantities. This resulted in either moving 2
pieces instead of 1 (entering 0.7 or 1 piece) or raising an error telling
you can not process moves with 0 quantity (0.3 piece).
As product_efficiency and product_rounding was removed from the BoM/BoM
line in v10, if the rounding is correctly handled, the feature could work
like in v9, by e.g. putting 1.03 in the bom line (97% efficiency) and
rounding up when exploding the BoM (e.g. producing 10 pieces would put
it to 11).
When "producing", we round the produced qty to the product uom (it does
not make sense to produce 1.32 if your uom rounding is 1.0). The user
might now change the produced quantity, that's why we round-up when
validating the move: indeed, if the user slightly increase the produced
value (below the uom unit), it actually means he produced more.
This way, instead of not rounding anything and doing rounding behind the
scenes, leading to errors, we round everything and the user sees the
result directly.
When posting inventory during a manufacturing order,
all raw material and finished product moves are used,
also those done from a previous post inventory.
This is no problem for the moving of quants because
a filtering is done in the move_validate method,
but it is a problem for the price calculation in
mrp_account and for linking the consumed/produced_quant_ids
of the quants of the raw and finished moves.
Before this fix, it would calculate already consumed materials
a second time in the price of the finished products and would
link quants produced with previously consumed quants (and vice versa)
when doing a second post inventory.
We add a test to show the issue.
Before, when the routing of a production order was empty (no operations),
it got into an inconsistent state (you click on "plan" and nothing happens).
Empty routings were used before to do subcontracting or 2-steps inventeory
(we did not set any operations on the routing but we set a location).
Here, we change the related routing field on the production order into a
calculated field which becomes empty when the routing has no operations.
This way, the "produce" button is displayed (as for production orders
without routing) and working/
This is a temporary patch to workaround the issuein a stable release.
In master, we might remove the location on routing and place it on the
workcenters and put a constraint that does not allow an empty routing.
When (re)generating the stock.move.lots in the workorder,
it should use the unit_factor on the move like everywhere else.
This makes sure we do well with the explosion of phantom boms too.
It is also important that if there is no operation_id given
explicitly in the "consumed in operation" on the bom line,
that it still generates the necessary stock.move.lots in the last work order.
Also, in the work order it is better to set the quantities done already.
That way we don't forget to consume them.
This commit contains the core of the new MRP. It contains a whole refactoring
of the MRP application, with improved and new features, written in new API.
Among other here are the main manufacturing workflow improvements :
- Picking type not only for pickings but also for manufacturing orders
- Properties replaced by picking type
- BoM can only be produced with its routing (no other)
- Either produce without routing with only production orders, or produce with
routing
- By default, there is an order in the work orders (serially), but you can
override it to be able to work in parallel
- Time clocking on work orders and block time on work centers with reporting
on OEE, performance, losses, ...
- Real-time adaptation of timings on operations
- Lots/serial numbers can be inputted like in the pickings on manufacturing
orders. It is also possible to input them in the work orders.
- Material availability independent of production order state (possibility to
start production when only part of it is there)
- Work sheets on work orders
- Put messages on work orders to make your workers pay attention to something
- Full traceability link to see for each produced piece of stock, the
consumed pieces, ...
- Separate scrap object (a scrap is not done based on an original move
anymore)
- Separate unbuild system (if you want to unbuild into its original
components)
Thanks to all people that helped during this development, notably but not
limited to Chirag A Dodiya (cod@odoo.com), Gaurav Panchal (gan@odoo.com),
Jignesh Rathod (jir@odoo.com), Mansi Trivedi (mtr@odoo.com), Pariket Trivedi
(ptr@odoo.com).
Pratima Gupta