The rational is:
Currently we have 2 columns. One for reservation, the other
for quantity picked.
However in real time, either you follow the reservation and everything
goes well. Otherwise you pick something else. In the case where you
pick somewhere else than reserved, you would like to modify the
reservation to have something similar and free the quantity you
didn't pick and expect the system to not suggest the ones you took.
In other hand, we always want to have the reserve quantity similar to
the done.
On top, having two columns could be confusing for the end user.
The cons:
-The qty_done column could be use during the picking, to
remember if something has been pick or still to pick.
- For some flow (put in pack), it's easier to write a part of the quantity to pack
and still want to reserve the full amount of product.
We goes back and choose a ligther interface over complex feature.
Changes:
Qty done and reserved qty are merged into a single column.
A new checkbox on the move exists to mark it as picked or not
Since the reservation always follow the quantity, it's now possible
to have more reserved quantity than stock. However the system will
never propose it and the inventory showing reserved > quantity should
be a warning.
The system should never modify a move that has been picked. We don't
want to overide the user action.
Regression:
Not able to pick a single stock.move.line
closesodoo/odoo#137864
Related: odoo/enterprise#48709
Related: odoo/upgrade#5310
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Fixes a large number of cases where strings are translated then
formatted, instead of letting `_()` do the formatting internally,
which allows it to recover from incorrect translations (missing,
broken, or extra placeholders).
Also
- removes translation markers entirely when there's nothing to
translate e.g. `_("%s - %s")` is not useful
- fixes a few messes which lead to only partial translatability
(DRY is generally a bad idea when translations are involved, even
more so when you don't make the variable part translatable)
- fixes a few nearby issues noticed at the same time
- replaces a few `"%s"` by `%r`, which should automatically quote
strings relatively appropriately
- fixes translated strings which use `\` to escape a newline (in order
to fill-paragraph): `\` escapes only the newline, if the
continuation string is indented this results in a bunch of spaces
ending in the string to translate, which is pretty garbage for the
translator, using implicit concatenation works much better
Note: some of the updates revert f-string parameters to %, because
babel (2.9) apparently has trouble with f-strings and blows up trying
to extract them.
Not in scope:
Helping translators fix translatable strings e.g. any translation
string with more than one placeholder probably should use keyword
placeholders
- Provides more context / data to the translator to make sense of the
sentence.
- Allows reordering the translated terms, which can be necessary
depending on the sentence and language.
closesodoo/odoo#139314
Related: odoo/enterprise#49311
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Steps to reproduce:
- Enable a second currency (e.g. EUR)
- Create a product P with a supplier using EUR as currency
- Create a MO with this product P as component and confirm it
- Open the Overview
Issue:
In the MO Cost column, the cost will be displayed in the company
currency but without converting its value.
Task-3251506
Part-of: odoo/odoo#114536
Have the "MO Cost" column mean the expected costs following *this*
Manufacturing Order.
Rename "Product Cost" into "Real Cost" and have it represent what where
the actual registred costs for this MO.
This allows for a quick comparison against what was expected and what it
really cost.
Part of task-3251506
Part-of: odoo/odoo#114536
As the content of the replenishments in the MO Overview is computed
through the forecast report data, as soon as a product is in stock,
the line about it disappears, since it is no longer linked to a
reception (PO/MO) in the forecast report.
But for MTO strong links, it makes sense to keep trace of what was used
to manufacture the products. So we inject the data back as if it was
regular forecast lines.
Part of task-3251506
Part-of: odoo/odoo#114536
Currently when showing a BoM Overview, the stock_availability
is computed for each bom's component. This means that there will
be one read_group on report.stock.quantity by component. As this
is a postgresql View, querying it too often can degrade the overall
performances.
This commit tries to improve on that by computing the stock_availability
of all components without bom at the same level at the same time. Let's say
there is a BoM with 4 components, none of which has a bill of materials
of their own. Before this commit there would have been 4 read_groups, one
by component. Now there will only be 1 read_group.
Example speedup: customer database with 7M stock.moves,
7M stock.move.lines. BoM Overview with 33 nodes in the component
Tree: 3min30s -> 1min30s
X-original-commit: 8fa7a11bf41152a06537144c20d04921d3643272
Part-of: odoo/odoo#139067
How to reproduce:
- Create Product 'Kit': storable, avco
- Create Product 'CMP': storable, avco
- Create BoM => type: kit | product: 'Kit' | Components: 3 units of 'CMP'
- Create mock currency (or update existing one), with a rate of 'Unit per USD' = 100
- Create purchase order in Mock Currency for 1 unit of 'Kit', with a unit price of 3,000.00 MOC
- Confirm Purchase Order and receive products
=> Go to the created valuation layer: Unit price for CMP is $1.000,00 instead of $10.00
OPW-3453703
closesodoo/odoo#137183
X-original-commit: ca05e3993fd0d8bd2b7333a9be15dc042f95fe6e
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: David Fesquet (dafr) <dafr@odoo.com>
Steps to reproduce the bug:
- Create a storable product “P1” with BoM:
- Component C1:
- Quantity: 2
- supplier:
- add any vendor, min quantity: 3
- Create a MO to produce 1 unit
- Click on the manufacture overview
Problem:
A user error is triggered:
`“The unit of measure Units defined on the order line doesn't belong
to the same category as the unit of measure False defined on the
product. Please correct the unit of measure defined on the order line
or on the product, they should belong to the same category.”`
The _compute_quantity function is called with supplier.product_uom even
though no supplier with the requested quantity is available.
opw-3495770
closesodoo/odoo#136340
X-original-commit: 17e5323e292a7b29ee6d30711cf3f083e05dd008
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
Steps to reproduce:
- Create Storable Product "Super Test" with Cost of $1.
- Create Storable Product "Pack of Super Test" with Cost of $10.
- Create a Kit BoM that produces 1 "Pack of Super Test" from 10 "Super Test".
- Ensure product category on both products is set to Automated FIFO Inventory Valuation.
- Create a PO for 20 "Pack of Super Test" and confirm.
- Process the Delivery and look at inventory valuation.
- See that "Super Test" has moved quantity at 200 with Unit Value of 10 each (taken from kit product!).
Bug:
cost isn't split on the qty of the bom line
Fix:
take product quantities of the bom into consideration
opw-3453703
closesodoo/odoo#134909
X-original-commit: 8e516dccac4ced7e48adfabe756a899784bac9ca
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Walid Hanniche (waha) <waha@odoo.com>
Steps to reproduce the bug:
- Assume the current date is August 1, 2023.
- Go to general settings:
- set purchase security lead time: 20 days
- set manufacturing security lead time: 25 days
- Create a storable product “P1”
- Routes: Manufacture + buy
- Manufacture lead time: 1 day
- Create an order point:
- preferred route: Manufacture
- Quantity to order: 5
- Click on “Order once”
Problem:
A manufacturing order is created, but the "Scheduled Date" is incorrect.
Instead of being set to August 1, 2023, it shows August 7th.
The issue occurs because initially, we calculate the `Lead days date`
as follows:
Today's date (August 1st) + manufacturing security lead time (25)
+ Manufacturing Lead Time (1) = August 27th.
However, we use the purchase security lead time (20) instead of the
manufacturing so 27 - 20 = August 7th
To determine the exact date, we call the function
`_get_date_with_security_lead_days`. In which we try to get the
appropriate rule to use. However, in this case, the preferred route
of the orderpoint is not passed as a parameter to the function.
Therefore, we use the first rule of the first route ("buy"), and we end
up using its security lead time.
opw-3439546
closesodoo/odoo#130932
X-original-commit: 5726c8882ae92eca3adfe19500c109ef8bae38a2
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
In the commit [1], the patch has been refactored to support the
native keyword `super`. The current commit just adapts the codebase
to that change.
task 3410198
[1]: 19ea1ac08043e22a811630968e44715cc3bfc495
Part-of: odoo/odoo#125716
Receiving a kit's component will fail in AVCO + multi-uom
To reproduce:
1. Create a product category PC
- Costing Method: AVCO
2. Create two products P_compo, P_kit
- P_kit:
- In Units
- P_compo:
- In L
- Storable
- Category PC
3. Create a BoM
- Product: P_kit
- Type: Kit
- Components: 1 x P_compo
4. Create and confirm a PO with 1 x P_kit
5. Process the receipt
Error: When validating the receipt, a user error is displayed: "The
unit of measure L defined on the order line doesn't belong to the
same category [...]"
When processing the SM, we create the in-SVL. To do so, at some
point, we need the unit price of the SM, and here is where the error
comes from:
https://github.com/odoo/odoo/blob/708c3d063482e365e49a04f633c83e90e6fa4356/addons/purchase_stock/models/stock_move.py#L39
`self.product_id` is P_component, but `line.product_id` is P_kit,
hence the error with the UoM1
And there will be some similar errors with the `if` block, L40 (we
compare some SM quantities and some POL quantities: we are mixing
components and kit)
For now, in case of a kit, we will always use the `else` block (i.e.,
the unit price of the POL). This will be improved in master
OPW-3357685
closesodoo/odoo#128386
X-original-commit: 3a81eb79cad7f25843315e39da421efa2c34aaf1
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Adrien Widart (awt) <awt@odoo.com>
Activated the route in demo data of Table Top, Table Leg and Wood Panel so that
bom overview and MO overview can yield better demo results.
task id: 3357025
closesodoo/odoo#124278
Related: odoo/enterprise#42169
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Currently, only stable releases see their translations updated. This has
resulted in master accumulating outdated stuff for years, which can be
confusing for users testing master on runbot.
This one-shot commit resynchronizes master translations based on the
content from 16.0 and removes empty PO files (i.e. no longer containing
translations).
closesodoo/odoo#121629
Related: odoo/enterprise#41171
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
When calculate Days to Prepare Manufacturing Order, we didn't take into
account Days to Purchase and Security Lead times for Purchaseing of the
company. In this commmit, if the (sub-)bom has company_id set, these two
days will added to the calculation.
Task-3078049
X-original-commit: bf59aedad649dec350f091bb074d3ef1e51d5fcb
Part-of: odoo/odoo#121813
A traceback occurs when merging two MOs when 2 step manufacturing is
enabled.
The issue was introduced in odoo/odoo#106411closesodoo/odoo#120707
Taskid: 3299549
X-original-commit: 242f0f224d8941bca689e20e37c5bca3bba51afe
Signed-off-by: Tiffany Chang <tic@odoo.com>
Steps to reproduce the bug:
- Install purchase, then mrp (in this order)
- Create a storable product “P1”
- route: buy
- Add a supplier
- Add a BoM
- Create a delivery for the product “P1”
- A need is created
- Go to inventory > operation > replenishment
Problem:
An orderpoint is created with the preferred route: Manufacture instead
of buy
As the "Purchase" module was installed first, the override of
the `_set_default_route_id` function will be triggered first, the 'buy'
route will be set in the created order point because the product has a
supplier. Then, the function in the MRP module will be triggered and
since the product has a BoM, the 'buy' route will be replaced by
"Manufacture".
opw-3228971
closesodoo/odoo#119172
X-original-commit: 227d038efbadf25e3a7be7cceedd9159b71162a3
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
While the cost of a line related to an RFQ was saved, it was not used in
the displayed costs.
Also, it used the wrong cost (don't need to factor in taxes), not did it
factor the quantity used in the cost.
Fixes as well the MO Cost for partially in-stock products.
Part of task-3217757
Part-of: odoo/odoo#118023
Instead of always using the `date_planned` of the PO to compute the
estimated/expected receipt date of a purchase order in the MO Overview,
instead use the `scheduled_date` of the related picking when it's
possible (i.e. when the PO is confirmed).
Part of task-3217757
Part-of: odoo/odoo#118023
The MO Overview would display the wrong uom in the replenishments lines
of the MO Overview. Since the data was pulled from the forecast report
(which displays it in the product's uom), it could not coincide with the
ones used in the MO.
Part-of: odoo/odoo#118023
The changes done to properly use the uom done in the `mrp` module were
not reflected in the `purchase_mrp` module, raising a traceback when the
purchase module was installed.
Part of task-3217757
Part-of: odoo/odoo#118023
Adds in a new report that allows the user to monitor the entire
production of a product, including the resupply of the components (i.e.
subassemblies, purchases, ...) in a single view.
Task-3059467
Part-of: odoo/odoo#113394
- The `picking_type_id` field in the pickings form view is not openable;
- Display the `description` field (optional) in the SVL list view;
- Add the `expiration_date` field (optional) in the quant list views;
- Add a description text for the landed cost;
- Renames field `requisition_id`: "Purchase Agreement" > "Blanket Order"
- In Inventory Adjustment, hides the "Apply All" button is at least one
record is selected;
- In `product_expiry`, renames two views to stick to the XML's coding
guidelines: https://www.odoo.com/documentation/16.0/contributing/development/coding_guidelines.html#xml-ids-and-naming
- For the replenishment:
- Places the field `product_id` as the first option when the user
writes something in the searchbar;
- Renames `route_id`: "Preferred Route" > "Route";
- Renames the button "Automate Orders" into "Automate";
- Set the `route_id` field as "optional=hide" until `mrp_purchase` is
installed (in this case, it will be set as "optional=show") because
in this case, there is at least two routes (Buy and Manufacturing).
task-3076044
Part-of: odoo/odoo#109511
Usecase to reproduce:
- Set the warehouse as 3 steps receipt
- Put a security delay of 3 days for purchase
- Set a product with a vendor and 1 days as LT
- Replenish with the orderpoint
You expect to have a schedule date for tomorrow that contains all the
product needed in the incoming 4 days.
Currenly the internal transfer from QC -> Stock is for tomorrow (ok).
The transfer from Inpur -> QC is plan for 2 days in the past. (not ok)
The PO date is plan for 5 days in the past. (not ok)
It happens because the system check at each `stock.rule` application if
purchase is part of the route. If it's then it applies the security lead
time. It's a mistake because we should apply it only the first time.
To fix it we directly set it when the orderpoint run and not during
`stock.move` creation.
However for MTO it's not that easy. We don't want to deliver too
early the customer. So we keep applying the delay during the
`stock.move` creation but only when it goes under the warehouse stock
location.
X-original-commit: 97f52bd40d97109a7983549d252476959ddceada
Part-of: odoo/odoo#112325
before this commit, in BoM form view, it was allowing to select BoM product as the BoM line product , as the constrains decorator was missing in this inherited function. typo in field name
after this commit, it is not allowed to add BoM product as BoM line product, as it will show the UserError. instead of bom_lines bom_line_ids used
closesodoo/odoo#111416
X-original-commit: 6e68005b27613ce84fe54d6d2f9273aa3ccfd662
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Problem case :
- Create a product with MTO and Buy route activated.
- Create a Sale Order containing this product.
- Confirm the Sale Order, this will generate a Purchase Order for this
product.
- Go to Alternatives -> Create Alternative -> Select another vendor &
select "Copy products".
The alternative PO won't be linked to the Sale Order, as this link is
done through the relation `created_purchase_line_id` <-> `move_dest_ids`
respectively on the `stock.move` and the `purchase.order.line`.
The only way to enable multiple Purchase Order to be linked to a single
move is to extend the number of `created_purchase_line_id` linked to a
move, hence changing it to a Many2Many relation.
Then, when an alternative PO is created, we link the original PO lines
`move_dest_ids` to the newly created PO lines, which correctly links the
SO and the alternative PO.
closesodoo/odoo#106411
Related: odoo/upgrade#4116
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
In multi-steps receipt, when running a procurement, using "Buy" as
preferred route does not always work because the route is not
correctly configured
To reproduce the issue:
1. In Settings, enable "Multi-Step Routes"
2. Edit the warehouse:
- Incoming: 2 steps
3. Create a product P:
- Type: Storable
- Vendors: a vendor V
- Routes:
- Manufacture
- Buy
4. Update on hand quantity:
- -1 at WH/Stock
5. Open the Replenishment page
- There should be a line with 1 x P
6. Set the Preferred route to "Buy"
7. Order Once
Error: a user error is displayed "There is no Bill of Material of
type manufacture [...] Please define a Bill [...]". This is
incorrect, it should generate a PO
The problem is simple: the Buy route is composed of one rule:
- Action: Buy
- Source Location: /
- Destination Location: WH/Input
But, when running the procurement, we first look for a rule to
fulfill the need at WH/Stock. We prioritize the rules of the
preferred route, but as explained above, the route does not contain
such a rule. Therefore, we use the other routes of the product:
https://github.com/odoo/odoo/blob/ba3bb9b701a382c4052ddb57392baeee32625937/addons/stock/models/stock_rule.py#L461-L466
And, because of step 3, it then finds the manufacture rule. This is
the reason why it tries to create a MO and why an error is raised
because of the missing BoM
OPW-3006960
closesodoo/odoo#109302
X-original-commit: 40a20d995d8613d3c82b7a2d62cde80eaad85bad
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
The current behaviour does not filter the cancelled moves when
evaluating if the product of the purchase order line is a kit.
This causes that, in cases where you have a cancelled wrong receipt
where the product was being received as a kit, if a new receipt is
created without receiving as a kit Odoo will always expect it as a kit.
After the fix, the cancelled moves will not be considered, as this is what
should be expected from cancelled operations.
closesodoo/odoo#107144
X-original-commit: 9659683d1f09c49a3ba3df8770eb7256660d0033
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Be able to define a cost share on kit's components. The purpose, define
a cost repartition closer to the reality.
If the cost share is not define, it will split by the number of lines.
Part-of: odoo/odoo#99411
Invoice a different amount than on the purchase order will not
use the price difference account anymore. Instead it will create
a layer with the difference. It means the stock valuation will be
base on real quantity invoiced rather than the purchase order.
Since the price different account does not exists:
- Invoice correction is only done on `account.move.line` linked to a
`purchase.order.line`. It means that additional lines won't be
corrected and will debit the stock_input instead (that should be empty
manually)
Part-of: odoo/odoo#99411
Add support for "buy" route recognition in the BoM overview report, as
well as calculating receipt delay for this kind of route
Task-2628323
Part-of: odoo/odoo#93194
Task: 2856281
- Remove user_type_id, account.account.type model, internal_type
- Add account_type that is a simple selection field
- Move internal_group and include_initial_balance to account.account
- Because of these changes, type_control_ids on account.journal is also removed
closesodoo/odoo#93212
Related: odoo/documentation#2223
Related: odoo/upgrade#3595
Related: odoo/enterprise#28205
Signed-off-by: Cedric Snauwaert <csn@odoo.com>
Steps to reproduce the bug:
- Install mrp and purchase
- Create a new user “U1” > give him only the “purchase” user access
- Log in as “U1”
- Go to purchase app > create a new PO
- Try to select any product
Problem:
A user error is triggered because we check if the product has a BOM
but since the user does not have access to MRP, an error is raised
opw-2885982
closesodoo/odoo#94489
X-original-commit: de359c0470fba1d5e9dfee416abe46661e35cce6
Signed-off-by: Adrien Widart <awt@odoo.com>
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
- Add the concept of 'Days to Prepare MO' in mrp, similar to 'Days to
Purchase' but defined at the product level. Both concepts are merged into
Days to Order at the orderpoint level, taking the value of Days to Purchase
for orderpoints with a buy route and Days to Prepare MO for orderpoint with a
manufacturing route.
- Add the concept of 'Visibility Days' on orderpoints. The idea is to
avoid to create through reordering rules multiple small orders for the
same product on a small time frame but rather to order directly a bigger
quantity. When Visibility Days are defined, the quantity of the orders
created by a RR is not the quantity forecasted at Today + Lead times
(quantity that triggered the order according to the RR), but the
quantity forecasted at Today + Lead Times + Visibility days.
The Visibility Days are different for purchase and manufacturing.
Changing the route of the orderpoint will change its value. They
can be defined at the company level and further fine-tuned on the
orderpoint. In case of change of the parameters at the company level,
only orderpoints without a specific value of Visibility Days will
be changed.
- Alignement between Manufacturing and Purchase Security Lead Time
(previously the Manufacturing Security Lead time didn't impact the
procurement date, instead the manufacturing time was made longer).
closesodoo/odoo#86682
Task-id: 2738838
Pr: https://github.com/odoo/odoo/pull/86682
Related: odoo/upgrade#3415
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
When changing the structure of a kit, it lead to undesirable behaviors
on Odoo
Issue 01:
1. Create 3 products P_kit, P_compo01, P_compo02
- Type: Storable
- Category: PC
2. Create a bill of materials:
- Product: P_kit
- Type: Kit
- Components:
- 1 x P_compo01
3. Create a purchase order PO with 2 x P_kit
4. Confirm PO and process the receipt
5. Edit the bill of materials of P_kit:
- Add 1 x P_compo02 in components
6. Return 1 x P_compo01
7. Go back to the PO
Error: The received quantity is 0 while it should be 1.0
When processing the return, the received quantity is recomputed, which
lead to:
https://github.com/odoo/odoo/blob/59fcb31f5a0b8136dae26b70ca0087f9b5cf3d24/addons/purchase_mrp/models/purchase_mrp.py#L29
However, since in the mean time the user added a new line in the BoM,
`_compute_kit_quantities` doesn't find any associated SM
(`bom_line_moves` is empty in [3]) and thus returns 0.
Issue 02:
(Need account_accountant. Use demo data)
1. Create a product category PC:
- Costing Method: AVCO
- Inventory Valuation: Automated
- Set up the Price Difference Account
2. Create 3 products P_kit, P_compo01, P_compo02
- Type: Storable
- Category: PC
3. Create a bill of materials:
- Product: P_kit
- Type: Kit
- Components:
- 1 x P_compo01
4. Create a purchase order PO with 1 x P_kit
5. Confirm PO and process the receipt
6. Edit the bill of materials of P_kit:
- Add 1 x P_compo02 in components
7. Create and Post the bill
Error: an Odoo Error is raised "ZeroDivisionError: float division by
zero"
While confirming the bill, some anglo saxo lines are generated. To do
so, the valuation of the kit is computed: [1]. In the above case, it
will lead to [2]. However, since in the mean time the user added a new
line in the BoM, `_compute_kit_quantities` doesn't find any associated
SM (`bom_line_moves` is empty in [3]) and thus returns 0. Back to [1],
the quantity is used to divide the total price -> it will raise an error
if this quantity is zero
Suggestion:
Such situations should not happen: once a product is used at least once,
it should not become a kit nor have a new structure (if it was already a
kit). Otherwise, `_compute_kit_quantities` will not correctly work since
it is not possible to take the BoM changes into consideration.
[1]
https://github.com/odoo/odoo/blob/abfe37fcea5b20f77799d9331d4d011530880669/addons/purchase_stock/models/account_invoice.py#L72-L74
[2]
https://github.com/odoo/odoo/blob/75191404788ab83645ee35b779991ea6fcdfa406/addons/purchase_mrp/models/stock_move.py#L19
[3]
https://github.com/odoo/odoo/blob/7d1af314320547ab5e37c1d97cad22992c98565b/addons/mrp/models/stock_move.py#L275-L294
OPW-2780855
closesodoo/odoo#86821
X-original-commit: 33fa43f795798276fa9d29dd0810289cbb1a2a9c
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
Fine tuning of commit 6acfb2e
It correctly merge the purchase.order in case of direct link and
avoid to relaunch the procurement.
It also correctly set the created_production_id if the demand come
from a SO
closesodoo/odoo#85301
X-original-commit: 9b6fa6c3db55daa3533c0d5cb13da7c98fc3e936
Signed-off-by: Arnold Moyaux <arm@odoo.com>
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>
stdout:
stderr:
13:41:03.985365 git.c:344 trace: built-in: git cherry-pick 20858c2a8805d9ec08edb98b090badf6c73fc342
error: Cherry-picking is not possible because you have unmerged files.
hint: Fix them up in the work tree, and then use 'git add/rm <file>'
hint: as appropriate to mark resolution and make a commit.
fatal: cherry-pick failed
----------
status:
closesodoo/odoo#79933
Signed-off-by: William Henrotin (whe) <whe@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>
Louis (wil)