In automated-AVCO configuration, buying a kit at a higher price than its
cost can create inconsistencies in the accounting.
To reproduce the issue:
(Need account_accountant. Use demo data)
1. Create a product category PC:
- Costing Method: AVCO
- Inventory Valuation: Automated
- Set up the Price Difference Account PDA
2. Create 3 products P_kit, P_compo01, P_compo02
- Type: Storable
- Category: PC
- P_compo01:
- Cost: 10
- P_compo02:
- Cost: 20
3. Create a bill of materials:
- Product: P_kit
- Type: Kit
- Components:
- 1 x P_compo01
- 1 x P_compo02
4. On P_kit's form, "Compute Price from BoM":
- The cost should be $30
5. Create a purchase order PO with one line:
- Product: P_kit
- Quantity: 1
- Unit Price: 100
6. Confirm PO and process the receipt
7. Create and Post the bill
Error: There is an error in the journal items of the bill: the value for
PDA is $85
When posting the bill, for each account move line, the module computes
the stock valuation of the associated product and the price difference.
To do so, it sums the valuation of all related outgoing stock moves and
divides by the quantity to get the value per unit, then it compares with
the unit price used on the PO's line. Here is the issue: in case of a
kit, there is one outgoing move per component while the PO's line is
linked to the kit itself.
Therefore, in the above case, it uses the outgoing moves of P_compo01
and P_compo02, adds up their value ($10 + $20 = $30) and then divides by
the total quantity (one P_compo01 and one P_compo02, thus $30 / 2 =
$15). This is the reason why it considers that the unit value of P_kit
equals $15. Then, since the unit price on the PO's line is $100, it gets
a price difference value equal to $85.
When comparing the unit value of the kit and its unit price, the unit
value should not be divided by the quantity of components ($30 should
not be divided by 2). Moreover, when buying such a kit at $100, the
surplus ($70) should be distributed among each component. However, it is
difficult to define a rule to correctly weight this distribution.
Therefore, this surplus will be considered as a price difference.
OPW-2566546
closesodoo/odoo#82463
X-original-commit: 20888055d4271bf3cf9e7bc3d42150a1f72e4495
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
In a lot of test class, we use `setUp` instead of
`setUpClass`. `setUp` is execute for each test method and `setUpClass`
will be execute only once by Class (and use savepoint + rollback).
Then change setUp into setUpClass reduce the time to make all tests
and avoid to repeat this error for the future.
closesodoo/odoo#78082
Related: odoo/enterprise#21563
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
Steps to reproduce the bug:
- Create a BOM kit for “product K” with:
- 2 * “product A”
- 1 * “product B”
- Create a PO for 1 unit of “product K” > confirm
- A receipt delivery with 2 units of “product A” and 1 unit of B will be created
- Modify the ordered Qty to 2 units of “Product K”
Problem:
The receipt delivery will not be updated correctly (4 units of product A and 3 of product B)
because the `"_prepare_stock_moves"` function computed the previous quantity wrong based on the moves quantities
since the moves are for products A and B, not product F.(do not take into account the products in kit)
Solution:
For kit products, do not calculate from the `"stock.move"`, calculate the difference between the quantity before and after the change
opw-2645719
closesodoo/odoo#77838
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
This commit removes the action_confirm from the run_manufacture to do it
only after all the orderpoints have been processed.
In case a production, created in run_manufacture, triggers procurements
for one of its component. And those procurements have the same
parameters than another one still not run because after the manufacture
one in the queue. This new procurement will replenish its quantity plus
the other procurement's one.
That means too much quantity will be replenished.
closesodoo/odoo#77026
X-original-commit: a7bb9f1ac392c00be5bdd133fc5c73b9803c8b4b
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
followup of rev [0]
If these wizards are called on multiple pickings, display the list of
the pickings that could be impacted and allow to select which one should
be impacted.
We also adapt the sanity checks at the start of `button_validte` in
order to specify the concerned pickings if needed. We do not enable the
multi behavior for batch at the moment, so it's only enabled for the
validate multi in the list view.
[0] 6ab4b0d496
task-2069646
closesodoo/odoo#41497
X-original-commit: ff276c6484b138982f185ec9c832f2dbf25baaef
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
The code that generate the return lines is moved inside
an onchange. The purpose is to allow an inherit that will
modify the picking_id of the wizard. It should trigger the
new return lines without a call to default_get.
task_id 1909413
This commit generalize the method made for computing the quantity delivered in a sale order
in order to be used for the quantity received for a kit in a purchase order.
TaskID: 1929518
Adrien Widart