The production_id on the stock move line is a helper field for work
orders and you can not assume it is always set correctly.  As
non-tracked stock moves create the stock move lines themselves it is not
set.

So, for logging notes, we check the 2 production order fields through
the moves.

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.

We initially only ran action_explode on manufactured move, but it should
be for done for classic move to make it work in classic deliveries
(confirming a move for a kit should cancel the originl move and add new
moves for the kit's components).

The user could be able to add a move in an existing MO
as a correction (thus only in edit mode).

In order to do it we use the existing system of move
by overiding the default_get and set the state directly to
'done'.

We apply a lock/unlock mode for the mo as was done for the picking.
In locked mode, the user can do all the regular things, but not change
the quantities done given by the work order or produce wizard.
In unlocked mode, only allowed by the mrp manager, the user can change
those quantities.

We opted to remove the 4 lines and just use a check box to indicate
there are lots behind a line.

For the finished products tab, we opted to show the move lines instead
of the moves as this way, you don't need to click further.  If nothing
has been produced yet, a message indicates to produce something first.

try to make it work actually.

When you are processing a MO or WO, you can set two times the same serial
number for the same product.

To avoid this behavior, we created a onchange on the stock move line to
warn the user when he enter two times the same SN. We also create a
constraint on stock move line to avoid having two times same SN in a
picking.

The rationale for the need of a merge move mechanism is that, with the new default view,
having multiple stock move for the same products is confusing. The idea is that if a move
is confirmed in a picking already having a move with the same characteristics, we update
the existing move and unlink the new one. That’s why it’s done at the end of `_action_confirm`.

In some cases, merging moves is unwanted (backordered moves for examples). Therefore, we chose
to add a kwarg to `_action_confirm` in order do control the mechanism.

also, remove now useless api.multi and dummy methods here and there

This removes the procurement.order model. To fufill their needs SO, PO, MO and
stock moves now call the _run method of the relevant procurement.group.

This mecanism is now only used for stockable product, tasks now uses their own
independent mecanism.

The _run method will check all the applicable rules and create directly the
needed model to fufill the need.

The modules stock, purchase, mrp, extends the _run method to implement their
specific strategy relevant for the rule type they define.

If an exception happens the message will be logged as a mail messsage on the
source model, for example, if a sales order cannot be fufilled the salesperson
will now see directly the reason.

OLD commit messages:
[WIP] procurement: removing procurement.order in stock, sale, purchase, sale_stock. WIP
fixup! [WIP] procurement: removing procurement.order in stock, sale, purchase, sale_stock. WIP
[IMP] Basic tests
[FIX] test not necessary anymore
[FIX] remove unnecessary print statement
[FIX] unnecessary test + why passing warehouse worked before?
[IMP] purchase: one move by purchase order line
[FIX] purchase: correct inventory tests and pass move_dest_ids among procurements
[FIX] because of bad cherry-pick merge
[IMP] make mrp pass by adding move_dest_ids there too
[IMP] tests of sale_mrp, no need for cancelpropagation then
[IMP] better to consistently use recordsets also for one2many
[FIX] purchase_requisition
[FIX] Exceptions should trigger errors, which should be caught in the tests
[FIX] sale_mrp: remove usage of procurement.order and use sale order name instead of sol
[FIX] stock_dropshipping: add sale_line_id on purchase_line_id
[FIX] Remove pdb
[IMP] add stock_dropshipping files
[IMP] stock: search carrier through sale line instead of procurement group
[IMP] add procrule test and preision needed when updating sol
[FIX] sale_order_dates + [IMP] procurement exceptions by scheduler
[FIX] No need to return task
[IMP] move file as name changes and add corrections
[FIX] Continue Run Schedulers wizard fix
[FIX] name issues of takss
[FIX] updating sale order line, but there is still a problem with the recompute

Adding the step to do when the user want to delete the MO.

Also remo `_check_entire_pack` logic, as all moves run it
on their picking it's useless to use it on picking himself.

Closes #17007

When you have push rules on move having a 'production_id', the
'production_id' is copied on the generated moves. So it generate a
traceback when we check the tracking method of 'product_id' on
produce_move.

This issue is caused because we get multiple produce_move instead of
one.

To fix this issue, we don't copy the production_id anymore on moves
generated by push rules.

- Create 3 products (A, B & C) with tracking set to 'serial'
- Create a BOM: A consumes 1 unit of B and C
- Create a MO for A, create the lot A1 for the finished product
- Create another MO for A, use the existing lot A1 for the finished
  product
- Try to mark the MO as done => you get an error
- In the finished products tab, change manually the lot, for example by
  creating A2
- Mark the MO as done
- Open the Upstream Traceability => under the MO, there is nothing, the
  traceability is lost.

The `check_finished_move_lots` method takes care of setting the
`lot_produced_id` on the `move_raw_ids`. However, when changing manually
the finished product lot, this modification is not propagated.
Therefore, when posting the inventory (`post_inventory`), the line:
```
move_raw.move_lot_ids.filtered(lambda x: x.lot_produced_id.id == lot)...
```
doesn't return any lot. Consequently, `consumed_quant_ids` is empty, and
the traceability is lost.

opw-724944

Complement of commit 85132f68

opw-727679

The constraint should only check for move lots with a lot number already
filled in. Indeed, in case we use work orders, we can potentially create
move lots without S/N, and fill in the S/N later.

opw-727679

- Create a product with unique SN, create a BOM for this product
- Create a MO to produce 2 units
- Produce the first unit, create a lot number
- Produce the second unit, use the previously created lot number

Nothing prevents the user to do this. However, the user won't be able to
set the MO as "Done", but it is better to prevent the issue as soon as
possible.

opw-724944

- Create Product A with a BOM which depends on a product with tracking
  "By Unique Serial Number" (Product B).
- Create a MO for Product A
- In the "Register lots" wizard, add two lines for "Product B", with the
  same serial number.

Nothing prevents the user to do it, even when the inventory is posted.

opw-709888

As picking types aren't always used in a picking context, and picking
aren't really meanigful for a lot of people, we rename this concept as
"operation type" in views and in the planner.

In a MO, change a product in "Consumed Materials" by clicking on "Search
more...". It crashes.

Clicking on "Search more..." triggers the onchange since it empties the
line. Since there is no product on the line anymore, it crashes.

opw-705644

To avoid unnecessary recomputations.

This reverts commit 37169c20.

The field `quantity_available` can be computed in two different ways:
- equal to `product_uom_qty`
- equal to `reserved_availability`

However, `product_uom_qty` is in the UoM of the move, while
`reserved_availability` is in the UoM of the product.

We convert into the UoM of the move, because `quantity_available` is
supposed to be in the same UoM than `product_uom_qty` ("To Consume").

opw-704775

We store quantity available to avoid numerical inconsistencies. For
exemple, with a rounding of 1e-6:
- `product_uom_qty` = 0.058824 (stored)
- `quantity_available` = 0.058823999999994 (not stored)

The dependencies of the field are fixed from v10.0.

opw-704775

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.

Closes #14854

Before, when we consumed 3 instead of 1 in a production order, it
gave a traceback.  It was because it created moves
with negative quantities.  So, something was wrong with
the quantity_done/product_uom_qty set when creating the extra moves

When creating an extra move because of the procurement,
but you still need to split afterwards (e.g. procurement 10, production order 12, you do 11),
then you should have a difference between quantity_done and product_uom_qty
in the extra move and not try to change it on the original.
That way, we make sure we pass the correct quantities.

[FIX] mrp: when posting inventory in mo, don't allow to pass stock.move.lots with quantity done > 0, but without lot

It is good to have this check, otherwise
it risks taking whatever lot or creating
a piece without lot if you would by accident
say you did so many quantities but no lot was given.

When you produce or consume more than foreseen in a production order,
the system creates extra moves.  Before, in case of tracking, it did this without
transferring the stock.move.lots resulting in a wrong stock.  That is why now,
when we split moves, we also split the stock.move.lots

For the finished move, it is also important to split between the quantities
of the original procurement and what is extra as the extra might use a push rule e.g.

As you open the lots in a raw material move in a production order,
you should not see the temporary stock move lots from the work order.
Also the quantity_done should not take into account those.  They will
when they press 'Done' on the workorder.

When posting inventory, the temporary stock move lots on the workorder,
should be transferred to the split move.

For splitting and unreserving, some optimizations are done.

product_uom._compute_quantity is an ensure one multi method taking a browse
record as second paramter. It replaces _compute_qty and _compute_qty_obj
to have a single and standard computation method.

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).

MRP module is migrated to the new API. It excludes mrp models that will change
quit a lot during the new MRP conversion. Actually most of the code is not
migrated, but at least side models and their methods are already migrated.
This should lessen the diff when writing the new MRP.

Split files and move them according to the new API guidelines. Containing

 - mrp splitted into its main models and files
 - stock code moved into its own models and files
 - various renaming