Currently there is a selection field 'account_type' on the
account.analytic.account model with 2 values : Active or Archived
Let's use an active field instead and add a Archive stat button on the
form. That way, we can remove all the domain ('account_type','=','normal')
which are implicit with the generic active field behavior
For that, we needed to inverse the processing of the moves of the production order (first consumed, then produced
instead of the opposite) as that way we know the price to put on the produced moves based on what was consumed before.
If the fixed quantity was higher than the produced quantity, the quantity of the
manufacturing order was used for the byproducts instead of the one specified on
the BoM.
This bug was due to the computation of the subfactor (`_get_subproduct_factor`
in mrp, because I love the modularity) that was computing remaining quantity,
only considering the variable quantities cases.
In fixed quantity, the MO quantity being lower than the byproduct quantity, it
was never fully produced.
Corrected the test to correctly check the quantities and handle the usecase with
an higher quantity in fixed byproduct.
Added a field subproduct_id on the stock.move object that allows to easily find
the attributes of the mrp.subproduct item without making hacky (and probably
wrong in case of more than one byproduct) search to find it back.
Closes#8031
A Phantom BoM can have service products which can create tasks.
Somehow the code did not use the _need_procurement function that was there before
to check if it needs to create a task.
This additional administration group was formerly used to hide
the configuration menuitems for the common users.
Being manager should be enough to access these items
When printing a BOM structure using a variant,
the specifications of the variant were not
displayed in the BOM Structure lines,
making it different than what can be found
in the BOM structure form, and therefore
making it impossible to know which variant
has to be used for this BOM structure
from the report.
opw-670448
When printing the production order, the name
of the product did not include the variant
specifications, making it different then what
is displayed on the production order form,
and preventing to know which variant was produced
for this production order.
opw-670448
Before the fix:
Create a product with a BoM type kit(composed with 5 products) and price=120
Select real price costing method for the product and each component
Select perpetual inventory valuation for the product and each component
Create a PO with the product
Receive the products
When checking the journal of entries, 5 entries have been created with an
amount of 120.
After the fix:
When checking the journal of entries, 5 entries will be created with an
amount equal of the standard price of each component of the kit.
opw:670239
It was like that for the date field, which is taken into account for the forecast quantity,
but in the view the scheduled date field is shown. We put the scheduled date equal to the date.
That way it is clear to the user when the products are foreseen to be consumed.
Christophe Simonis