Steps to reproduce the bug:
- Create a storable product “P1”:
- route: MTO + manufacture
- uom: unit
- BOM:
- qty: 1 dozen
- component: 12 units of “C1”
- Create a SO:
- Product: 12 unit of “p1”
- uom: unit
- Confirm the SO
Problem:
The UOM set on the product is used instead of the BOM UoM on the created
manufacturing order.
wrong MO:
- 12 unit of "P1"
expcted MO:
- 1 dozen of "P1"
opw-3048190
closesodoo/odoo#106351
X-original-commit: 8c5fb8b71538462422c8f166b772b5e316ecd6b5
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
This commit fixes premature usage of `purchase_price` field on
sale.order.line model, before its definition in sale_margin module.
Since this test requires both sale_mrp and sale_stock_margin to pass,
this commit adds an auto-install bridge module that solely address this
issue.
Steps to reproduce:
- Install sale_mrp module
- Run tests (at least .test_kit_cost_calculation)
Problem:
Traceback:
AttributeError: 'sale.order.line' object has no attribute 'purchase_price'
See #100126closes#104891closesodoo/odoo#105458
X-original-commit: ac921c88909110deefa9b91be104244bda12458f
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
Co-authored-by: Thibault Libioulle <thibault.libioulle@aerospacelab.be>
Steps to reproduce the bug:
- Create a Kit product "Kit 1":
- Add a BOM with a component “C1”
- Add a sales description
- Create another kit product without a sales description "Kit 2":
- Add a BOM with a component "C2"
- Make sure you have a qty of “C1” and "C2"
- Create a SO:
- Add "Kit 1" and "Kit 2"
- Add any other storable product
- Confirm the SO
- Go to the delivery → validate it
- Print the delivery slip
Problem:
The report doesn’t contain the kit product.
Because in the report, the `stock.move.line` are filtered by checking
the name of their move if it has the same name as the product in
the bill of material, but like the `stock.move` has the name
('description') of the `sale.order.line` instead of the product name,
the lines are filtered and not displayed:
https://github.com/odoo/odoo/blob/14.0/addons/mrp/report/report_deliveryslip.xml#L9
The behavior is the same for purchase orders
opw-2960467
closesodoo/odoo#105158
X-original-commit: be25cea0d882bb03a4873821fdb788a0890ba49a
Signed-off-by: Tiffany Chang <tic@odoo.com>
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
The new lines should contain the current balance, and the account of the
last 2 lines if it is the same.
* The computation of the balance was reading on `debit` and `credit`,
leading to a cycle in the compute method. It is useless to try to read
those fields because of `_inverse_debit_credit`
* The computation of the account was simply forgotten during the
refactoring
Also move a constraint from `write` in a more rigorous `api.constrains`,
which revealed a bug for to find the account of payment terms of receipts.
Followup of d8d47f9ff8
task-2956509
closesodoo/odoo#101994
X-original-commit: f04f83b42bb1fbcacbb6bf92a2156ff2be1bf1b1
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: William André (wan) <wan@odoo.com>
Consider this case:
Template A has 2 variants: KIT and NOKIT
KIT has a total cost of 100, NOKIT costs 50
When selling NOKIT, the current code will select the bom of KIT
to calculate the price_unit of NOKIT, which means that when
reconciling the aml of the invoice (amount = 100) with the aml of
the cogs move (amount = 50), it will be partial due to the difference
in amount. This alse messes with the balance sheet report.
This fix ensures that only boms directly related to the product
or for the generic template are selected.
opw-2918080
closesodoo/odoo#98676
X-original-commit: 8ce71352886442f3a75999fe39856f82651314e5
Signed-off-by: Steve Van Essche <svs@odoo.com>
Steps to reproduce the bug:
- Create a storable product “B1”:
- Costing Method: average
- With BOM:
- BOM Type: Kit
- Components:
- 3 units of “C1” (cost c1 = $2)
- Go to the “B1” product form:
- Click on “Compute Price from BOM”
- Cost = 3 * $2 = $6
- Create a storable product A1:
- Costing Method: average
- BOM
- BOM Type: Kit
- Components:
- 2 units of B1
- Go to the “A1” product form:
- Click on “Compute Price from BOM”
So: 1 unit of A1 → 2 units of B1 → 3 units of C1
- Cost = (2 * 3 * $2) = $12
- Create a SO:
- Add 1 unit of “A1”
- save
- cost(`purchase_price`) = $12
- Confirm the SO
- The cost is recomputed and becomes = $6
Problem:
When the SO is created and the product “A1” is added, the cost is
retrieved from the product: https://github.com/odoo/odoo/blob/14.0/addons/sale_margin/models/sale_order.py#L27
But when the SO is confirmed, a picking is created, therefore the
cost is recomputed: https://github.com/odoo/odoo/blob/14.0/addons/sale_stock_margin/models/sale_order_line.py#L18
So The `_compute_average_price` function is called, in which a loop is
made for each move related to the `sale.order.line`, but the
`bom_line.product_qty` is used for each component (in this case the qty
necessary of the product `C1 ` to make a single unit of `B1`, but this
is not multiplied by the number of units needed to be used in the
parent's bom_line
opw-2971248
closesodoo/odoo#101012
X-original-commit: 9ec7aa9b89bc929af15473d0cc29084fd831cf94
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
TLDR:
* invoices are implemented using computed methods instead of onchange
* the synchronization only happens when switching tabs in the Form view
to improve perfs.
_______________________________________________________________________
The whole engine of the synchronization of Invoices to the Journal
Entries has been refactored
* by using computed fields instead of onchange functions
* by synchronizing only from invoice to journal entry in `create` and
`write`
* by saving when switching tabs on the Invoice form, to synchronize
before showing the values
This comes with numerous advantages:
* no need to call the onchange methods manually
* no need to use the Form emulator to build invoices (i.e. EDI, OCR,
intercompany, ...)
* the performance for invoices with many lines improves drastically, going
from 2 minutes to 4 seconds to create an invoice with 500 lines
* the model is more declarative, we can now see how the values are computed
instead of having the values being copied from various places.
* remove the hack in `onchange` that disabled the recursivity of it,
which was unexpected and needed to be managed manually in all the
onchange methods
This means that:
* Some fields need to be exclusively computed on journal entries values
or invoice values, more specifically the Tax Summary widget.
It is now
- computed from entry lines, when opening the view
- computed from invoice lines when changing those, because the tax lines
will need to be recomputed anyways, erasing previously set values
- set with an inverse function when saving; after the sync has been done
* Some possible operations previously possible have been dropped.
(i.e. look at the removed test test_in_invoice_line_onchange_accounting_fields_1)
This is because such a behavior was undefined (how is changing the balance going
to affect the unit price? How is the amount currency going to affect it?)
_______________________________________________________________________
Implementation Details
----------------------
The "dynamic lines", meaning the payment terms and the tax lines are now
only created in the `create` and `write` functions.
In order to reduce code duplication, it has been implemented using
context managers used in both `account.move` and `account.move.line`
These context managers help comparing the values before/after, acting
like a local `onchange`, but getting benefit from the dirty flags from
the `compute` dependences.
This is relying on computed fields on the move (`needed_terms`) and on
the lines (`compute_all_tax`) which contain the values needed for the
related move.
Depending on the needed values and the existing values (`term_key` and
`tax_key`, respectively) the context manager will determine what needs
to be created/updated/deleted.
Some related changes are to produce a `dict` instead of a `str` for the
`tax_totals` (previously `tax_totals_json`) fields, by simplicity to
reduce the complexity of IO, and simplicity of debugging, because the
logic of the field needed to change (cannot be computed at the same time
anymore since it needed the lines to be synced)
By simplicity, and also because it makes more sense, some boolean fields
have been merged into `display_type`:
* `is_rounding_line`
* `exclude_from_invoice_tab`
* `is_anglo_saxon_line`
The `price_unit`, `quantity` and other "invoice fields" are now not set
anymore on lines that are not product lines since it didn't make any
sense to have it.
Performances
------------
You have to keep in mind that a simple `create` didn't compute a lot of
fields, for instance not taxes were set, no payment terms,...
Now it does.
```python
import random
from timeit import timeit
from odoo import Command
domain = [('company_id', 'in', (False, self.env.company.id))]
products = self.env['product.product'].search(domain).ids
partners = self.env['res.partner'].search(domain).ids
taxes = self.env['account.tax'].search(domain).ids
def create(nmove, nline):
self.env['account.move'].create([
{
'move_type': 'out_invoice',
'partner_id': random.choice(partners),
'invoice_line_ids': [
Command.create({
'name': f'line{i}',
'product_id': random.choice(products),
'tax_ids': [Command.set([random.choice(taxes)])],
})
for i in range(nline)
]
}
for j in range(nmove)
])
# After | Before
print(timeit("create(1, 1)", globals=globals(), number=1)) # 0.11 | 0.09
print(timeit("create(100, 1)", globals=globals(), number=1)) # 2.76 | 2.50
print(timeit("create(500, 1)", globals=globals(), number=1)) # 14.56 | 12.34
print(timeit("create(1, 100)", globals=globals(), number=1)) # 1.03 | 5.52
print(timeit("create(1, 500)", globals=globals(), number=1)) # 3.99 | 125.02
print(timeit("create(50, 50)", globals=globals(), number=1)) # 19.44 | 79.55
```
Another metric that can be used is running the test suite with
`--test-tags=/account` (only `account` installed)
* before: 404s, 267127 queries (366 tests)
* after: 318s, 232125 queries (362 tests)
Why this commit title?
----------------------
Someone told me that this was the perfect way of naming your commits.
c04065abd8
task-2711317
closesodoo/odoo#96134
Related: odoo/upgrade#3715
Related: odoo/enterprise#29758
Signed-off-by: Laurent Smet <las@odoo.com>
The render API was confusing as mixing the access to the report and
the rendering env.
The ambiguity was present for code such as
`report.sudo()._render(record_ids)` where it was not clear if the
`sudo()` is needed to access to `report` or to `record_ids`. For low
priviledge users (such as portal or public), it was common to use
`report.with_user(SUPERUSER_ID)._render(record_ids)`.
This PR changes the render methods signature to be `api.model`. The
`report_ref` can be:
- ir.actions.report external id
- ir.actions.report id
- ir.actions.report recod
- `report_name` value
This will allow to call the report methods with any user and no longer
need to use `with_user(1)` to render reports as public user.
Task-id 2670865
closesodoo/odoo#91341
Related: odoo/upgrade#3650
Related: odoo/enterprise#27323
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
When a delivered product was owned by an external partner, we should not
generate any COGS line
OPW-2884211
closesodoo/odoo#96882
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
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>
In the web client, in a real use case, it's not possible
to write on fields which are invisible,
as it's not possible to write on fields which are readonly.
This is a first step in the goal to change the behavior
of the `groups=` attribute in the back-end views,
to remove them for the view instead of making them invisible.
This is mainly to reduce the diff of the revision that will introduce
the mentioned above behavior change.
As nodes with `groups=` will be removed from the view
when the user doesn't have the group, it's no longer possible
to set a value on a field having a `groups=` the user doesn't have
in the `Form` test class, as the field will no longer be at all in the
view.
However, these unit tests shouldn't have been able to set values
on invisible fields in the first place.
This revision therefore aims to correct the unit tests setting value
on fields which were invisible because the user executing the
test was not part of the required group(s) for these fields
to be visible in the view.
closesodoo/odoo#94337
Related: odoo/enterprise#28936
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
* Use div name/id instead of dummy classes for xpath references
* Use clear variable name (picking instead of i in the t-foreach)
* Use t-elif/t-else when useful to reduce python evaluations of
exclusive boolean values
* clean xml indentation
closesodoo/odoo#94704
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
The test is incorrect because a search is made on all product variants
instead of getting only the previously-created product variants
The SO action_cancel function returns a wizard that is not processed,
so the so was never canceled. we should call the private function
instead
closesodoo/odoo#94742
X-original-commit: c4e6562e669881047802f25866f3c2c19bf2394a
Signed-off-by: Adrien Widart <awt@odoo.com>
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
When selling a kit with a dropshipped component, the delivered quantity
will be incorrect
To reproduce the issue:
1. Create 3 consumable products P01, P02, P_kit:
- P02:
- Add a seller S
- Enable the dropship route
2. Create a bill of materials:
- Product: P_kit
- Type: Kit
- Components:
- 1 x P01
- 1 x P02
3. Create and confirm a sale order SO with 1 x P_kit
4. Confirm the generated purchase order (with vendor S)
5. Process the two pickings of SO
6. Go back to SO
Error: The delivered quantity of P_kit is 0 instead of 1
When computing the delivered quantity, because the `dropship` flag is
not set, we don't reach the revelant code:
https://github.com/odoo/odoo/blob/3db136f19480b31ca3f60a77c0c7354161bedde0/addons/sale_mrp/models/sale_mrp.py#L37-L44
OPW-2870893
closesodoo/odoo#94364
X-original-commit: fff6edad8cfb45b9a622bceefa4b83f620d7fe86
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
Remove most values uselessly specified because giving the same value as
the default one (see _DEFAULT_MANIFEST in odoo/modules/module.py)
* auto_install is Falsy by default
* author is Odoo SA by default
* summary & description are empty strings by default
* application is False by default
* test, demo, depends and data are empty lists by default
This will reduce noise/inconsistencies between manifests specifications,
simplify analysis of manifests content, ...
closesodoo/odoo#90209
Related: odoo/enterprise#26807
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Current behavior:
When 2 steps delivery and product packing is activated, and have 2 kit products that have common components.
If you create a sale order with those 2 kits and pack them in the first step of the delivery. And in the second delivery step mark the pack as done the done quantity in the package
are not correct.
Before this fix, all the products quantities from different kits were on the same stock move line and the other lines were ignored,
this result in lines with too much products and lines with no product. When validating this
incorrect transfer an unnecessary backorder was created and the sale order lines were not correctly marked as delivered.
Steps to reproduce:
- Activate 2 steps delivery and product packing.
- Create Kit A with Component A and Component B
- Create Kit B with Component A and Component B
- Create a SO with 1 Kit A and 1 Kit B
- Confirm the SO
- Go in the first step of the delivery and put everything in a pack
- Go in the second step of the delivery and set the pack as done
- Go in the package details : The first component A has 1 reserved and 2 done, same for component B
opw-2754106
closesodoo/odoo#90033
X-original-commit: b81f70babc774eff2e04d2f7854d75ec7273a757
Signed-off-by: Engels Robin (roen) <roen@odoo.com>
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Current behavior:
When using 2 steps delivery and selling a kit product, not all
moves had bom_line_id set. So if you go in the transfers you
couldn't always see the "Kit" column in the operations.
Steps to reproduce:
- Activate 2 steps delivery
- Create a Kit with 2 products
- Create a quotation with kit and confirm it
- Go in the delivery
- In WH/Pick you can't see Kit column
- In WH/Out you can see the Kit column
opw-2796974
closesodoo/odoo#89371
X-original-commit: 88c3c3f49393af08e4070c0d2f5cccbec9096c1f
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Engels Robin (roen) <roen@odoo.com>
When invoicing a tracked product, the lots/SN delivered (or the related
quantities) are not always the correct ones displayed on the printed
invoice
To reproduce the issues:
1. In Settings, enable "Display Lots & Serial Numbers on Invoices"
2. Create a product P:
- Storable
- Tracked by lot
3. Update its quantity > 5 with lot L
Use case 01:
4. Create and confirm a SO with 5 x P
5. Process the delivery
6. Create an invoice
7. Edit the invoice line:
- Quantity: 1
8. Post and print the invoice
Error: The quantity related to lot L is 5, it should be 1
Use case 02:
4. Edit P:
- Invoicing Policy: Ordered quantities
5. Create and confirm a SO with 1 x P
6. Create and post the invoice
7. Process the delivery
8. Print the invoice
Error: There isn't any information about delivered lot L
Use case 03:
4. Create and confirm a SO with 3 x P
5. Deliver 1 x P (with backorder)
6. Invoice 1 x P + Post the invoice (-> INV01)
7. Deliver 2 x P
8. Reset, post INV01 again and print it
Error: The quantity related to L is 3, it should be 1. Moreover, if the
user then invoices the 2 others P, posts and prints this second invoice,
it won't contain any information about L
OPW-2730270
closes#81444closesodoo/odoo#89088
X-original-commit: 3598c0c8cda813efa1aebc17f041e4c0a1a29f06
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
Co-authored-by: Adrien Widart <awt@odoo.com>
Co-authored-by: Florent de Labarre <florent.mirieu@gmail.com>
On a SO, the delivered quantity of a dropshipped kit is incorrect in
case of a return
To reproduce the issue:
1. Activate Dropshipping
2. Create 3 products: KIT AB, A, B:
- All have the Dropship route and a supplier set
3. Create a BOM of type kit: KIT AB is composed of A & B
4. Create a SO for 1 unit of KIT AB, validate
5. Validate the created PO
6. Deliver the products
7. Create a return for these products
- Error: On the SO, the delivered quantity is 0 but the return is
not validated yet. This quantity should still be 1
8. Validate the return
- Error: On the SO, the delivered quantity is now 1, it should be 0
The 'all or nothing' policy should correctly consider the returns: all
moves (to customer) must be done and the returns must be delivered back
to the customer
OPW-2759250
closesodoo/odoo#87596
X-original-commit: f259d10db577bbf1b11fffd028e678b38d5f402d
Signed-off-by: Tiffany Chang <tic@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
Current behavior:
When using a product kit that have a product kit in his BoM some move line where merging when they shouldn't.
Because of this the delivered count wasn't correctly updated in any sale order using this product
Steps to reproduce:
- Create product B to manufacture with a BoM (type Kit) using component A and component B
- Create product A to manufacture with a BoM (type Kit) using product B and component A
- Create a sale order with product A
- Confirm the sale order and validate the delivery
- The delivered count of product A on the sale order stays at 0
opw-2777810
closesodoo/odoo#87000
X-original-commit: 0e6480811e2144a1034f1347a816a0bd052c4516
Signed-off-by: Tiffany Chang <tic@odoo.com>
Signed-off-by: Engels Robin (roen) <roen@odoo.com>
To reproduce the issue:
1. Storable product with MTO and manufacture route
2. On your warehouse set 3 steps manufacture
3. Create and Confirm a SO for this product
Error: The smart button linking the Manufacturing order does not appear
on the MO.
Problem was introduced by [1] and fixed by [2,3]. Moreover, [1] wasn't
deployed on versions >14.0 so there was no need for [2] on these
versions ([3] has been merged on all versions). However, [1] have
recently been deployed on next versions ([4]) so we need to FW [2] too
without disturbing the improvements from [3].
[1] 7ab0ac3e56949e5015bb2dcfd2af34b56dee92c8
[2] 96b56ea350c283d824468c591d42e4aeeada0d69
[3] 475e6b3cb027b3127b8e46fd8c9f90abc35162d7
[4] 7d7976a61d0af41ebb4df2e24ba222f6570f689c
OPW-2778883
closesodoo/odoo#85676
X-original-commit: 8ce61133af600ffec4c43033e64c2460366856ce
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Co-authored-by: Arnold Moyaux <arm@odoo.com>
Co-authored-by: Grazioso Andrea (agr) <agr@odoo.com>
Co-authored-by: Adrien Widart <awt@odoo.com>
* Remove old unused parameters
* Move `backend_url` logic from qweb to python
* add comments, clean and simplify some code/logic related to portal
page of sale orders
Part-of: odoo/odoo#84644
Steps to reproduce the bug:
- Go to Settings > Technical > Decimal Accuracy
- Change Unit of Measure to 4 digits
- Go to Inventory report or Valuation report
Bug:
The decimal accuracy in Valuation report for quantity or reserved quantity was in two digits instead of four digits
The decimal accuracy in Inventory report for qty_at_date was in two digits instead of four digits
PS: In stock move report or stock move line report, the decimal accuracy of quantity fields are in four digits
By default digits of Product Unit of Measure is 3, that's why some test had to be modified
opw:2410981
closesodoo/odoo#82989
X-original-commit: 0cf5c4e8241c46724defc0ea7e0d2c881ec2eeab
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Arnold Moyaux <arm@odoo.com>
In order to provide more transparency, we display any MOs linked to a
SOs via MTO linkage. This includes linkages made via reception report.
Part of Task: 2662730
closesodoo/odoo#79627
Signed-off-by: Arnold Moyaux <arm@odoo.com>
odoo/odoo/pull#79015 fixed some linkages for SO <-> MO, but removed the
linkage for backorders. This made a strange case where a (backorder) MO
could display a SO as being linked to it, but not the other way around.
Discovered during Task: 2662730
Part-of: odoo/odoo#79627
When returning a kit, the margin of the related SO decreases
To reproduce the issue:
(Need sale_management)
1. In Settings, enable "Margins"
2. Create a Product Category PC:
- Costing Method: FIFO
3. Create two products P_kit, P_compo:
- Both:
- Type: Storable
- Category: PC
- P_compo:
- Cost: 10
4. Update P_compo quantity: 1
5. Create a BoM:
- Product: P_kit
- Type: Kit
- Components: 1 x P_compo
6. Update P_kit's cost
7. Create and confirm a SO with 1 x P_kit, unit price = $100
- Note that the margin is correct: $90
8. Process the related picking
9. Create a return R
10. Go back to the SO
Error: the margin is now $80
When computing the cost of the kit, the move linked to R are considered.
Therefore, the cost becomes $20 and thus the margin becomes $80
OPW-2679473
closesodoo/odoo#83008
X-original-commit: 2f34669f9dc3c9abfcbb13198f90f37405ffc258
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
When reversing an invoice linked to a sale order, the value of the new
anglo saxon AML should be based on the value of the returned product
To reproduce the issue:
(Need account_accountant,purchase)
1. Create a product category PC:
- Costing Method: FIFO
- Inventory Valuation: Automated
2. Create a product P:
- Type: Storable
- Product Category: PC
3. For C in [10, 20, 30]:
- Create a purchase order with 1 x P at cost C
- Receive P
4. Create a SO with 3 x P
5. Deliver the products one by one
6. Create and Post the invoice INV linked to SO
7. Return the second delivery
8. Add a credit note to INV01:
- Credit Method: Partial Refund
9. Set the quantity to 1
10. Post the new invoice INV02
Error: The anglo saxon lines are listed in the journal items, which is
correct, but their value is $30 while it should be $20 (i.e., the value
of the returned product)
When delivering the last product, its standard price is updated with the
new value ($30):
https://github.com/odoo/odoo/blob/6b96ed418cb626678f4fa5baec25a903d7a74eda/addons/stock_account/models/product.py#L305-L307
Later on, when posting the credit note, the module gets the anglo saxon
unit price (`_stock_account_get_anglo_saxon_price_unit`). However, it
does not consider that the current account move line is reversing
another one. In the reversing process, the computation of the invoiced
quantity should be based on the invoices lines that are reversing too.
Moreover, when computing the average unit price of the returned product,
the module should use the stock moves that are returning the product.
In the use case, because of the two issued noted above,
`_compute_average_price` does not find any stock valuation layer to
compute the average unit price and uses the fallback, i.e. the standard
price of the product:
https://github.com/odoo/odoo/blob/6b96ed418cb626678f4fa5baec25a903d7a74eda/addons/stock_account/models/product.py#L652-L656
That's the reason why, in the above case, the value is $30 instead of
$20.
Note: a similar use case can be reproduced with a kit
OPW-2646926
OPW-2628215
closesodoo/odoo#82978
X-original-commit: 524d0d5e8817e1c7bcc99204c4cbb90fcfb6074c
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
When a kit is exploded to `stock.move` the quantity is rounded half-up
for every move. But during the invoice. The quantity to invoice on
kit is rounded up so it could result in differences between the
inventory valuation and the cost of the product
closesodoo/odoo#81778
X-original-commit: 1a56d6646d44861cea238ae67d2a7becb36c01b3
Signed-off-by: Tiffany Chang <tic@odoo.com>
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Fix for task 2620026.
_get_bom_component_qty function is only referred to once in the whole odoo app,
which is on addons/sale_mrp/models/account_move.py#22.
The result returned from this function is used as a multiplier to quantity
to convert into the expected UoM. However, the quantity being referred to on
_stock_account_get_anglo_saxon_price_unit (qty_invoiced, qty_to_invoice), are
already converted into the SO Line's product's default UoM. In this function,
it however tries to convert 1 from SO Line's UoM to BoM's UOM.
With this, if Product UoM=x, SO Line UoM=y, BOM UoM=x, in the function _stock_account_get_anglo_saxon_price_unit,
the quantities will be multiplied by the same factor twice, resulting to the incorrect computation of price_unit to follow.
X-original-commit: d7c2f59dc6e769bd6e8c0e53fe1e4f9df16bbe52
Part-of: odoo/odoo#81778
The aim of this commit is to make the cogs generation multi-company
safe.
2 bugs are fixed in this forwardport commit:
- The product.valuation on the line wasn't evaluated in a company safe
way.
- cogs method weren't company safe either
Before this commit:
- When posting an invoice from company B with both company A and B
selected and A being selected as "main", the cost from company A could
be selected instead of cost from company A to create the anglosaxon
lines.
- If company B's product isn't in real time valuation, cogs aren't even
created.
After this commit:
Whatever the selected companies are, the cost selected will always be from
the company that created the invoice.
closes odoo/odoo#81492
Task: #2686104 and #2713607
X-original-commit: e34caf0ec33a3001bb6343e02d34a6edb5a9f609
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: Brice Bartoletti <bib@odoo.com>
When selling a storable kits, the consumable components should be
ignored in account lines
To reproduce the issue:
(Need account_accountant,sale_management,mrp)
1. Create a product category PC:
- Costing Method: FIFO
- Inventory Valuation: Automated
2. Create 3 products P_kit, P_compo01, P_compo02
- P_kit:
- Type: Storable
- Category: PC
- P_compo01
- Type: Storable
- Category: PC
- Cost: 5
- P_compo02:
- Type: Consumable
- Category: PC
- Cost: 6
3. Update P_compo02's on hand qty: 1
4. Create a bill of materials:
- Product: P_kit
- Type: Kit
- Components:
- 1 x P_compo01
- 1 x P_compo02
5. Create & Confirm a sale order SO with 1 x P_kit
6. Process the related delivery
7. Create & Post the related invoice
Error: The journal items of the invoice are incorrect, the value of
Expenses and Stock Interim (Delivered) are $11 instead of $5. The
consumable components should be excluded from this value
OPW-2604084
closesodoo/odoo#81015
X-original-commit: 5de451008552ef9b9c675b34178482d81ff42b89
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
The stock convention on location name is always to name the destination
`location_dest_id`. It was not the
case on the stock rule model
Task: 2648449
Part-of: odoo/odoo#80434
Steps to reproduce the bug:
- Install sale_management and sale_mrp
- Create a product with BOM, which is a KIT and add any product in BOM line
- Create a SO for the product > Confirm
- Validate the delivery
- Cancel the SO > Set to Quotation > Reconfirm
Problem:
A new delivery order is generated while the ordered quantity = delivered quantity
This is because `_get_qty_procurement` wrongly computed the product quantity based on the moves quantities in the kit case.
opw-2647856
closesodoo/odoo#79560
X-original-commit: 1f6f7dc82cede9a9038178d70fc7c53f685c5748
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
Suppose an automated AVCO product category. When confirming an invoice,
if the associated product was a kit and if its BoM has changed during
the process, a traceback can occur.
To reproduce the issue:
(Need sale_management)
1. Create a product category PC:
- Costing Method: AVCO
- Inventory Valuation: Automated
2. Create 3 products P1, P2, P3:
- Product Type: Storable
- Category: PC
3. Update P3's quantity > 0
4. Create two bills of materials:
- BOM01:
- Product: P1
- BoM Type: Kit
- Components: 1 x P2
- BOM02:
- Product: P2
- BoM Type: Kit
- Components: 1 x P3
5. Create a sale order SO with 1 x P1
6. Confirm SO and process the delivery
7. Edit BOM02:
- BoM Type: Manufacture
8. On SO, create the invoice INV
9. Confirm INV
Error: an Odoo Server Error is displayed with a traceback: "[...] in
_compute_average_price, bom_line_data = bom_lines[bom_line] [...]
KeyError: mrp.bom.line(19,)"
On step 7, when changing the BoM type, a new BoM line is created.
Therefore, in `_compute_average_price`, the BoM associated to the move
(i.e., `bom_line`) is not one of the lines in `bom_lines` (i.e., the new
BoM lines). There is already a check in case the line has been deleted,
but not if it has been changed.
OPW-2610685
closesodoo/odoo#78917closesodoo/odoo#79293
X-original-commit: 3ae0b781bcb5c2840f848bc63b9f3f9e1b2812cb
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
Issue: When returning a product sold that is only made of kits and
validating the return, the delivered quantities of the sales order was
set back to the full amount delivered
Steps to reproduce :
1) Install MRP and Sales
2) Create a BoM Kit for a new product [Nested Kit] that has one or
more consumable or storable product as component
3) Create a BoM Kit for a new product [Main Kit] that has
[Nested Kit] as component
4) Create a SO for [Main Kit], confirm, validate delivery
5) Check SO, 1 product is delivered (correct)
6) Go back to the Delivery, create a return for the delivery
(don't validate)
7) Check SO, 0 product is delivered (correct)
8) Now validate the return for the delivery
-> Check SO, 1 product is delivered (bug)
Why is that a bug:
Since the Main Kit was returned, the delivered should be 0 and not
the full amount initially delivered. It was set back to 1 because we
didn't look at the type of picking, when computing the quantity
delivered, the fall back considered that if all the moves were done,
everything was delivered, but it is the opposite when returning
opw-2542337
closesodoo/odoo#78915
X-original-commit: 206c9c8da4d8001525a540561174326e49d1188d
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Touati Djamel (otd)