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>
This commit aims at removing unuseful help message to:
1/ reduce translators work, to focus on more useful translations
2/ not sending unuseful information in load_views
3/ reduce help message to useful messages, so that we can mark
fields having a tooltip in the future UI.
4/ some cleanup of existing messages too
The main use cases:
- REMOVED: help redundant with the field name, providing no extra info
- MOVED TO COMMENT: technical help messages, that should not be in UX
closesodoo/odoo#97279
Signed-off-by: Fabien Pinckaers <fp@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>
Current behavior:
When returning a delivery that had a quanity lower than 1
the inventory valuation showed a value of 0 for the return
Steps to reproduce:
- Create a product that use "m" (meters) as UoM
- Change the configuration of the product Category
and set Costing method to FIFO and Inventory valuation to Automated
- Create a SO for this product with a quantity of 0.15
- Validate the order and validate the delivery with full quantity
- Now click on return and make a return for the delivery
- Validate the return and go in the inventory valuation
- Show the inventory valuation for the created product
- The return has a value of 0 when it should have the same value
as the delivery
opw-2880153
closesodoo/odoo#94827
X-original-commit: 9bc3d5ebef234aa1d77f1d467746837a5cadc037
Signed-off-by: Adrien Widart <awt@odoo.com>
Signed-off-by: Anh Thao PHAM <pta@odoo.com>
Steps to reproduce:
- Define the decimal accuracy for the "Product Price" to 5
- Create a product with "cost = 0.00875"
- On-hand product = 10'000
- Change the cost to "0.00975"
Issue:
In Inventory valuation, for the product you will have two layers valued at:
- 87.5
- 12.5
Instead of:
- 87.5
- 10
Cause:
We round with currency precision
Solution:
Use the "Product Price" decimal precision as it is the case when we define a "standard_price"
https://github.com/odoo/odoo/blob/4c7ef5673b8fc28bf7fe2bc36fe2450987f15a28/addons/product/models/product.py#L110-L112
opw-2724975
closesodoo/odoo#93257
X-original-commit: deb26bb1182682a5071287ae313064801d080607
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Yolann Sabaux (yosa) <yosa@odoo.com>
When using multiwarehouse, you can have moves that will be valuated on location A
and then moved to location B. In that case, the forecasted report of Location B
will have discrepancy because the move from A to B will not be valuated (internal move)
and the initial valuated stock valuation layer will still be linked to location A.
I change the way we retrieve the quantity using stock quants linked instead of
the svl.quantity linked to the selected location.
opw-2715253
closesodoo/odoo#93032
X-original-commit: a8a130e5b10aab3cb9eeedbf627b9a195cf7a253
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
If a picking is owned by the company and if the user receives a FIFO
product, a SVL will be created without any journal entry
To reproduce the issue:
(Need account_accountant)
1. In Settings, enable "Consignment"
2. Create a product category PC:
- Costing Method: FIFO
- Inventory Valuation: Automated
3. Create a product P:
- Type: Storable
- Category: PC
- Cost: 1
4. Create and validate a receipt:
- Owner: <The company of the picking>
- With: 1 x P
5. Open the generated SVL
Error: There isn't any journal entry associated with the SVL
When validating the picking, a method filters the SML that will be
considered during the SVL creation process. This method filters out the
SML that has an owner and if this owner is not the company:
https://github.com/odoo/odoo/blob/f8e2f2a4836d23fe507cad3bd5cac92d41ca91a3/addons/stock_account/models/stock_move.py#L69-L70
However, the filter in the journal entries creation is not that accurate
and does not correspond to its comment line:
https://github.com/odoo/odoo/blob/f8e2f2a4836d23fe507cad3bd5cac92d41ca91a3/addons/stock_account/models/stock_move.py#L475-L476
OPW-2859144
closesodoo/odoo#92716
X-original-commit: 13d4963d10e14c0295a1c7abeefd52b070cd4a58
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
Step to reproduce:
Install purchase, stock and accounting
Create a product in a database with USA localization.
Create a new product category and select the manual valuation option.
Purchase the item, receive the item and create the Vendor bill
Current Behavior
On the journal entries you will see that the stock interim accounts
are impacted (the accounts uase for an automated stock valuation)
Expected Behavior
The used account is expenses
Explanation:
The problem comes from the fact that we don't reset/set these accounts
when changing the property valuation of a product category.
opw-2746384
closesodoo/odoo#91811
X-original-commit: 2cb9c7afb2d9e096f0c8e1ada2908b720b6e5ade
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Signed-off-by: Fockedey Martin (mafo) <mafo@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>
The SVL of in/out moves may be different because of rounding
To reproduce the issue:
(Need purchase,sale_management,stock)
1. In Settings, enable "Multi-Currencies"
2. Edit the USD currency:
- Rounding factor: 1.0
3. Create a product category PC:
- Costing Method: FIFO
4. Create a product P:
- Type: Storable
- Category: PC
5. Create a purchase order PO with one line:
- Product: P
- Quantity: 0.5
- Unit Price: 3.0
- Taxes: None
6. Confirm the PO and receive P
7. Create a sale order SO with 0.5 x P
8. Confirm the SO and deliver P
9. Inventory > Reporting > Inventory Valuation
Error: The quantity of P is zero but its total value is 0.50$
When receiving P, a SVL is created but does not round the value. So, we
have 0.5 x P in stock with a value equal to $1.50
Then, when deliver the product, the FIFO process is executed and create
a second SVL. However, this time the value is rounded:
https://github.com/odoo/odoo/blob/2e4fdcb84ba6375bb51fe71355168cebe2d922a0/addons/stock_account/models/product.py#L290
Therefore, the SVL of the out move has a value equal to $2. This
explains why, when checking the inventory valuation, the value is $-0.50
OPW-2724864
closesodoo/odoo#90251
X-original-commit: 306f3be81192eef504927e30483856669b36b047
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
Canceled and draft entries are the same color as posted entries. They should be in a different color (grey/blue) in order to be distinguished from other invoices/bills.
Amount Due, a.k.a. amount_residual(_signed), is not 0 for draft and canceled entries. It should be 0 since they haven't been posted yet.
A few tests have to be adapted to reflect this change in spec.
Task=2801521
closesodoo/odoo#88295
X-original-commit: 498a4a52b5fbc5466d8d0652db10563ccba55032
Related: odoo/upgrade#3435
Signed-off-by: Laurent Smet <las@odoo.com>
Steps to reproduce:
Decimal Accuracy - Product Price = 2
- create a product `alc 50%` with BOM (10 unites = 1 unit Water [cost=0.14]; 1 unit Alc [cost=0.08])
- Set `quantity on hands` = 10,000
- Trigger `Compute Price from BoM`
-> In Reporting > Inventory Valuation; click on the layer; in Other Info: You will see "Product value manually modified (from 0.0 to 0.022000000000000002)"
=> It can cause computing mistakes as we changed the costs
Cause:
The value is calculated as the difference between the New Price (cost) and and the current Product Standard Price (cost).
But, on one hand the Product Standard Price is rounded to the number of digits defined in the Decimal Accuracy for the Product Price.
On the other hand, the New Price is used as is with no rounding.
If we add an extra step and modify the cost of the Water to 0.45 and trigger again the `Compute Price from BoM` we will have:
"Product value manually modified (from 0.02 to 0.053000000000000005)"
Solution:
Use for the New Price the same rounding precision as we use for the Standard Price.
Example:
Product Price/unit
--------------------------
Water 0.14
Alc. 100% 0.08
BoM: Alc. 50%
Product Quantity Needed
--------------------------
Water 0.1
Alc. 100% 0.1
Cost/unit of Alc. 50%: 0.022 => 0.02 (standard_price is rounded)
Set Quantity on Hand: 10,000
Stock Valuation: 200 = 10,000 * 0.02
=> The standard_price is rounded to the second digit when intialized
Product Price/unit
--------------------------
Water 0.45
Alc. 100% 0.08
BoM: Alc. 50%
Product Quantity Needed
--------------------------
Water 0.1
Alc. 100% 0.1
Cost/unit of Alc. 50%: 0.053
Set Quantity on Hand: 10,000
Stock Valuation WITHOUT FIX: 530 = 200 (first layer) + 330 (second layer) = 0.02 * 10,000 + (0.053-0.02) * 10,000
Stock Valuation WITH FIX: 500 = 200 (first layer) + 300 (second layer) = 0.02 * 10,000 + (0.05-0.02) * 10,000
=> Without fix, the value is computed with the rounded standard_price and the not rounded new_price.
=> With fix, the new_price is rounded the same way as the standard_price
opw-2724975
closesodoo/odoo#88616
X-original-commit: 2d6f4213af7464c5fe737e2e9265454cf9711020
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: yosa-odoo <yosa@odoo.com>
How to reproduce:
1- Create Product Category "PC" AVCO|FIFO Automated.
2- Create Storable Product "P" with product category PC and unit cost to 1.
3- Create SO with 10 units of P.
4- Create PO with 10 units of P and unit cost of 2.
Delivery of the SO should now have 2 IV layers, with one being "Revaluation of XXX (negative inventory)"
Global IV of P should be 0 qty, 0 value.
5- Return the delivery order of SO.
6- Open valuation of the return
Error: The value is 0, should be 20
In `_get_price_unit`, `price_unit` is taken on the last svl of the origin_returned_move_id, in our case it's the revaluation layer.
`_get_price_unit` now take all svls of origin_returned_move_id into account.
OPW-2784033
closesodoo/odoo#88177
X-original-commit: bfd1a06b054dcc115f7fb0937db98812f4a6d5dc
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Signed-off-by: DavidFesquet <dafr@odoo.com>
In case you applied inventory in batch the system would create a lot of useless
stock moves and stock move lines.
closesodoo/odoo#87771
X-original-commit: 07f18f62db490608b316cc9482f228252ed8fc63
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Wolfgang Taferner <w.taferner@wtioit.at>
Expected Behaviour
When updating the cost of a product with a negative quantity and then
making an inventory adjustment, the final value should be corrected according
to the current cost of the product
Observed Behaviour
In the case we had a negative quantity when changing the cost, the compensation
layer will be ignored when doing an inventory adjustment afterward, leading to
an incorrect total value in the inventory valuation
Reproducibility
This bug can be reproduced following these steps:
- Create Storable product with costing method = AVCO Automated, Update cost to 100$
- Sell 10 units of this product (Inventory valuation at -1000 $ for -10 units)
- Update cost of the product to 10 $ (Inventory valuation at -100 $ for -10 units)
- Create an inventory adjustment to set the quantity of the product to 0.
==> Inventory valuation is a 900 $ for 0 unit of our product
Related Issues/PR
- opw-2635692
closesodoo/odoo#86389
X-original-commit: 673a6b69e335b29d011b7c5743c3fe101445a5e1
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Hendrickx Anthony (anhe) <anhe@odoo.com>
This commit modifies most of the usages of read_group and uses
_read_group instead. _read_group doesn't join automatically on the
many2one fields when no order_by is specified, making it more performant
when the "name" of the many2one is not relevant, which is the case for
most back-end cases
closesodoo/odoo#84908
Task-id: 2479334
Related: odoo/enterprise#24877
Signed-off-by: Raphael Collet <rco@odoo.com>
To reproduce the issue:
(Need purchase,sale_management)
1. Create a product category PC:
- Costing Method: FIFO
2. Create a product P
- Type: Storable
- Category: PC
3. Create a PO with 1 x P @ 10 + Receive P
4. Create a PO with 1 x P @ 0 + Receive P
5. Create a SO with 1 x P + Deliver P
6. Create a SO with 1 x P + Deliver P
7. Process a return for sold P at step 6
8. Open the valuation of the return
Error: The value is 10, should be 0
In `_get_price_unit`, `price_unit` is defined with the correct value
(i.e., `0`), but the if-condition of the `return` is not respected, so
another value is used
OPW-2735502
closesodoo/odoo#84649
X-original-commit: 3ad98f7da027829c563fb9ebc86e8299721743db
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
While calling `_stock_account_prepare_anglo_saxon_out_lines_vals`, the line
`credit_expense_account = accounts['expense'] or self.journal_id.default_account_id`
can cause a 'Expected singleton' error. During upgrades from v13 and earlier,
the value used for `accounts['expense']` is always `None`.
If the recordset in `self` contains more than one record, the error will happen.
By replacing `self` with the iteration object `move`, this error is averted.
The error happened during an upgrade from v13. Since the value assigned to
`accounts['expense']` doesn't exist in that version, it goes to
`self.journal_id.default_account_id` to grab it.
If `self` has more than one record, the error happens.
Traceback:
```
Traceback (most recent call last):
File "/home/odoo/src/odoo/14.0/odoo/service/server.py", line 1199, in preload_registries
registry = Registry.new(dbname, update_module=update_module)
File "/home/odoo/src/odoo/14.0/odoo/modules/registry.py", line 89, in new
odoo.modules.load_modules(registry._db, force_demo, status, update_module)
File "/home/odoo/src/odoo/14.0/odoo/modules/loading.py", line 475, in load_modules
migrations.migrate_module(package, 'end')
File "/home/odoo/src/odoo/14.0/odoo/modules/migration.py", line 180, in migrate_module
migrate(self.cr, installed_version)
File "/tmp/tmpae3wx5o6/migrations/account/saas~13.4.1.1/end-09-payment-refactoring.py", line 618, in migrate
util.iter_browse(env["account.move"].with_context(**ctx), ids, chunk_size=1024).action_post()
File "/tmp/tmpae3wx5o6/migrations/util/orm.py", line 197, in caller
return [getattr(chnk, attr)(*args, **kwargs) for chnk in chain(it, self._end())]
File "/tmp/tmpae3wx5o6/migrations/util/orm.py", line 197, in <listcomp>
return [getattr(chnk, attr)(*args, **kwargs) for chnk in chain(it, self._end())]
File "/home/odoo/src/odoo/14.0/addons/sale/models/account_move.py", line 14, in action_post
res = super(AccountMove, self).action_post()
File "/home/odoo/src/odoo/14.0/addons/account/models/account_move.py", line 2715, in action_post
self._post(soft=False)
File "/home/odoo/src/enterprise/14.0/l10n_mx_edi_landing/models/account_move.py", line 26, in _post
return super()._post(soft)
File "/home/odoo/src/enterprise/14.0/l10n_mx_edi/models/account_move.py", line 456, in _post
return super()._post(soft=soft)
File "/home/odoo/src/odoo/14.0/addons/sale/models/account_invoice.py", line 75, in _post
posted = super()._post(soft)
File "/home/odoo/src/odoo/14.0/addons/purchase_stock/models/account_invoice.py", line 171, in _post
return super()._post(soft)
File "/home/odoo/src/enterprise/14.0/account_reports/models/account_activity.py", line 75, in _post
return super()._post(soft)
File "/home/odoo/src/odoo/14.0/addons/stock_account/models/account_move.py", line 49, in _post
self.env['account.move.line'].create(self._stock_account_prepare_anglo_saxon_out_lines_vals())
File "/home/odoo/src/odoo/14.0/addons/stock_account/models/account_move.py", line 158, in _stock_account_prepare_anglo_saxon_out_lines_vals
'account_id': credit_expense_account.id,
File "/home/odoo/src/odoo/14.0/odoo/fields.py", line 3821, in __get__
raise ValueError("Expected singleton: %s" % record)
ValueError: Expected singleton: account.account(1383, 38, 30)
```
closesodoo/odoo#84129
X-original-commit: acda26fd71eac3c6bac1ad81886cd8885bc69c5a
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
The aim of this commit is to set partner on anglosaxon
aml in order to help our client in their stock
reconciliation process in case it hasn't been done automatically.
Before this commit:
anglosaxon line were created without partner
After this commit:
A partner is set when anglosaxon line are created
closesodoo/odoo#84547
Ticket: 2692308
Community-pr: https://github.com/odoo/odoo/pull/84468
X-original-commit: abfe37fcea5b20f77799d9331d4d011530880669
Signed-off-by: William André (wan) <wan@odoo.com>
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>
The possible index names have been renamed "btree", "btree_not_null"
(instead of "not null") and "trigram" (instead of "gin").
Task 2742526
Part-of: odoo/odoo#83274
Three supported types:
- btree (default for index=True)
- btree not null (when >90% of the data are null)
- gin trigram search (for char fields)
Review of indexes on all objects.
closesodoo/odoo#83015
Signed-off-by: Fabien Pinckaers <fp@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 reversing an invoice that contains some anglo-saxo AML, the new
anglo-saxo AML should have the same unit price than the original one
To reproduce the issue:
(Need account_accountant,purchase)
1. Create a product category PC:
- Costing Method: AVCO
- Inventory Valuation: Automated
2. Create a product P:
- Type: Storable
- Product Category: PC
3. Create a purchase order PO01 with 2 x P for $10
4. Confirm PO01 and process the receipt
5. Create and Post an invoice INV01 with 2 x P
- As listed in the journal items, the anglo-saxo lines have been
generated with a value of $20
6. Create a purchase order PO02 with 2 x P for $20
- The cost of P becomes $15
7. Confirm PO02 and process the receipt
8. Add a credit note to INV01:
- Credit Method: Partial Refund
9. Set the quantity of P to 1
10. Post the new invoice INV02
Error: The anglo-saxo lines are listed in the journal items, which is
correct, but their value is $15 (the new cost of P) while it should be
$10
When reversing an invoice with the "partial refund" method, the
anglo-saxo lines are generated via the regular flow (as if it were a
"standard" invoice). Therefore, when getting the unit price of the line,
it uses the product's standard price. In such situation, it should use
the unit price of the original line.
OPW-2646926
OPW-2628215
X-original-commit: 87f7e78340dfe553923b2b65f61de06d5778cfbd
Part-of: odoo/odoo#82978
Steps to reproduce:
Have a 0% Tax
Make an invoice with it
Open tax report
The 0% tax is not present in the report because there is no tax lines generated for them because the resulting balance is zero.
Since the tax details is making a mapping between tax lines and base lines and the tax report is using them to compute the report, the tax report is not able to compute the tax base amount for such taxes.
Explanation:
Until now, the tax line with a zero amount wasn't generated because considered as noisy journal items.
Now we must be able to groupby on the base tax account on the tax report, we are forced to use the tax details.
Injecting dynamically the 0% tax on the tax details sub-queries is really complicated and leads to a huge performance drop.
For that reason, we start to generate the tax lines for 0% tax even the balance is zero.
However, since there is nothing creating the missing lines in the past, it should be fixed case by case if needed.
opw-2711432
closesodoo/odoo#82971
X-original-commit: 65b5ec4ad65f798b1d647978b5b42a49e760139a
Signed-off-by: Olivier Colson <oco@odoo.com>
Signed-off-by: Laurent Smet <las@odoo.com>
Before this commit it is technically possible for "return_picking_line" to be a recordset instead of a record.
By taking the first element ([0]) we're sure it is always a record instead of a recordset to work with.
closesodoo/odoo#82578
X-original-commit: 705e60a9531fe0b042fd32a5dfc934bede15558c
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Steps to reproduce the bug:
- Connect as Admin
- install stock_account
- Go to inventory > Product Variants > choose any product > click on the FORECAST button
- Traceback
Problem:
docs['product_templates'] can be False, so we can't use it to check the user's group: https://github.com/odoo/odoo/blob/15.0/addons/stock/report/report_stock_forecasted.py#L98
Opw-2728473
closesodoo/odoo#82352
X-original-commit: 227a639b34fc5121d135346a158ab17486a53d40
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
2 issues:
- When going to the report forecast the value of the stock is computed.
However the stock user should not be able to access the valuations
- Since an access error is return the graph view is not instanciate and
the javascript code try to amend an empty result to the DOM. It results
with a traceback on top of 403 page
closesodoo/odoo#82074
X-original-commit: dbc6b1999ad478d0fdb5774624fd50ca4018be22
Related: odoo/enterprise#23185
Signed-off-by: Arnold Moyaux <arm@odoo.com>
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>
This commit rename product_uom_qty into reserved_uom_qty and product_qty
into reserved_qty on stock move line to stop mistake them with the stock
move quantities fields.
Task: 2648449
Part-of: odoo/odoo#80434
When using AVCO and subcontracting without any additional cost, the
valuation of the finished product is incorrect
To reproduce the issue:
1. Create a Product Category PC:
- Costing Method: AVCO
2. Create two products P_compo and P_finished:
- Both:
- Type: Storable
- Category: PC
- P_compo:
- Cost: 10
- Routes: Resupply Subcontractor
3. Update P_compo's quantity: 2
4. Create a Bill of Materials BO:
- Product: P_finished
- Type: Subcontracting
- Subcontractor: a partner P
- Component: 1 x P_compo
5. In Inventory, create a planned Receipt R:
- From: P
- Operations: 1 x P_finished
6. Mark R as To Do
7. Process the delivery of P_compo
8. Validate R
9. Repeat steps 5-8
10. Open the Inventory Valuation
Error: There are two valuation lines for P_finished: one line has a
value of $10, which is correct (this is the cost of the component).
However, the value of the second line is $20, it should be $10 too.
Here are a part of the values used to generate the related MO:
https://github.com/odoo/odoo/blob/2d12fb8fb94c0f2acade7222cfedbec34114a8e9/addons/mrp_subcontracting_account/models/stock_picking.py#L21-L25
In the above case, an extra cost is defined on the MO and is based on
the unit price of the subcontracted SM. However, `_get_price_unit` will
return an incorrect value:
https://github.com/odoo/odoo/blob/251be6b943ea8c3f274bb0863d0af3f7c6b8d10d/addons/stock_account/models/stock_move.py#L39
After step 8, the standard price of P_finished is $10. Also, in the
above case, there isn't any subcontracting cost, so there isn't any unit
price defined on the SM. Therefore, `_get_price_unit` returns the
standard price of P_finished ($10). As a result, when computing the
value of the finished stock move:
https://github.com/odoo/odoo/blob/4fc2ec31861d4602357f130066ec3507b96d8dc8/addons/mrp_account/models/mrp_production.py#L39-L42
It uses the extra cost of the MO + the component cost. This explains
where the $20 come from.
OPW-2641339
closesodoo/odoo#80889
X-original-commit: 0567536f8b66c71f6860041926542f88026793b1
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
On Fifo costing method, the 'value' field of a stock quant was computed using quantity_svl and value_svl of the product_id.
However the method 'with_company()' wasn't used for quantity_svl, resulting in an incorrect 'value' field of stock.quant
This commit add the use of 'with_company()' method to get quantity_svl.
OPW-2652211
closesodoo/odoo#79844
X-original-commit: 0a7709611fbbc983fc5db5dd36ab7716e543bc0f
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
The active field of stock_valuation_layer is related to product_id.active.
Adding auto_join = True avoids bloating search/read_group queries in
expression.parse().
closesodoo/odoo#69207
X-original-commit: 2526c640969f462c18ab8a3da7aa0a4e8ed871f8
Signed-off-by: Raphael Collet (rco) <rco@openerp.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>
- update MO list status colors: draft = blue, in progress = yellow +
make the WO status colors match (waiting = blue, in progress = yellow)
and make draft MO lines all blue (to follow current design standard)
- cleanup Activity in tree view (no label in tree + "Next Activity" in
column selection dropdown)
- make units of analytic accounting for WO = hours
- make quantity for move_raw_ids products (i.e. components for MOs)
always have positive analytic_account_line.unit_amount (i.e. when
changing a done move's quantity + changing a quantity twice made this
value negative)
- make "Copy Operations" on BOM open the list view in "current" instead
of "new" due to lack of hook to prevent form view (i.e. open BoM in
current view) changing when clicking on lines in the new window's
operations (also ends up being a better UX anyways since being able to
view the operations form view is desired).
Task: 2648460
X-original-commit: 65a2d478197f5b856212225319500ca61b161809
Part-of: odoo/odoo#77897
- Create a product with Category configured with:
* Costing Method: First In First Out (FIFO)
* Inventory Valuation: Automated
- Create a PO to buy 1 unit and receive the product
- Create a SO to sell 1 unit and deliver the product
- Return the product
- Re-deliver the product
- Create invoice for SO but don't post it
- Connect with an user with "Accounting: Accountant" rights only
- Post the invoice
An access error will be triggered when trying to access stock valuation layer.
opw-2623376
closesodoo/odoo#76289
X-original-commit: cc76e76ef2d1cc5a16778bd9440911fd6ec73c9b
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Signed-off-by: Anh Thao PHAM <kitan191@users.noreply.github.com>
william-andre