costs_hour field no longer exists
Some modules in a different repository (let say enterprise), may be still using
it but it is not its place here.
For stability reasons, we keep the computation if an external module adds the
missing field anyway
Fixes#16269Closes#20899
Use the field `time_cycle` for cost computation, which takes into
account the routing configuration (fixed time of computed based on
previous operations).
- Create a work center with a capacity of 1, an efficiency factor of
100% and a cost per hour of 40$
- Create a routing with two operations: one with a fixed duration of
30:00 minutes (OP1) and another with a duration computed on real time
but with a default of 30:00 minutes (OP2)
- Create a component with UOM "m" and a cost of 10$
- Create a finished product with an associated BoM
- The BoM has a first line with 0.8m of component in the OP1 and a
second line with 0.4m of component in the OP2
- Activate the Compute from BoM option on the finished product
- The proposed cost is 32$
Expected cost: 52$
(30 minutes @40$/hour + 30 minutes @40$/hour + 1,2m @10$/m)
We divide the WC cost by the number of operations, which does not make
sense.
opw-741032
The price suggested thanks to the "Compute from BoM" button only takes
into account the price of the products listed in the BoM lines.
In v9, there was a "Recursive" option that provided the possibility to
compute the prices of all products implied in the BoM, recursively. This
option has been removed since it was leading to a "black box" behavior
that was unclear to the users.
However, limiting the price computation to the BoM lines only is too
restrictive since it doesn't even take into account the phantom BoMs.
By using the `explode` method, we have access to:
- all products not manufactured
- all products manufactured which are not kits (phantom BoM)
It means that the cost of manufactured products (not kits) should still
be computed before the product itself.
opw-697866
When a product template UoM is different from its BoM UoM, the price
suggested thanks to the "Compute from BoM" is incorrect, since it doesn't
apply the conversion rate between the product template UoM and the BoM UoM.
This is because we try to fetch the product UoM through the BoM. However,
if the BoM is not specific to a product.product, the field bom.product_id
is empty.
product_uom._compute_price() is now an ensure_one multi methods, taking
a browse record as second unit. This helps simplifying and unifying the
various calls and price computation methods.
Nicolas Martinelli