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.
According to the routes set on the products of the raw materials, a
procurement may have to be created for the consumed lines of the MO.
A route may also be set on a product category. Before this patch, we
only look for procurement rules for the routes defined on the products
and on its category, ignoring the inherited route of the parent category.
Fortunetaly, we have a computed field on the product model returning
all the routes from the current category, so we use this one in the
search for procurement rules.
A test has been added to show the failure.
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.
Before this patch, the inventory was automatically posted when you click
on "done" on the last planned work order. This behavior was preventing
the user from correcting, for example, the consumed quantity on the raw
materials move on the manufacturing order if it was different from the
theoretical quantity. Note that finishing anyone but the last work order
still let you edit the consumed quantity. Same with changing the lot.
Now you have to click on "mark as done" on the manufacturing order to
post the inventory. Note that this is the same behavior when working
without work order (produce > mark as done will post).
We adapt the tests to reflect this change.
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).
- Preserved explicit 3rd-party copyright notices
- Explicit boilerplate should not be necessary - copyright law applies
automatically in all countries thanks to Berne Convention + WTO rules,
and a reference to the applicable license is clear enough.
A squashed merge is required as the conversion of the apiculture branch from
bzr to git was not correctly done. The git history contains irrelevant blobs
and commits. This branch brings a lot of changes and fixes, too many to list
exhaustively.
- New orm api, objects are now used instead of ids
- Environements to encapsulates cr uid context while maintaining backward compatibility
- Field compute attribute is a new object oriented way to define function fields
- Shared browse record cache
- New onchange protocol
- Optional copy flag on fields
- Documentation update
- Dead code cleanup
- Lots of fixes
Josse Colpaert