Currently the standard price for products with FIFO as cost_method, show
the price of the next product to go out. It could be confusing on the
report page because the standard price * quantity is different than the
stock value. Another issue, is the margin, they are only computed on the
last piece even if we sell multiple ones.
For example:
MOVE IN 5 units @ 10$
MOVE IN 5 units @ 20$
If we do an order for 10 units at 30$ each we will have a margin of
200$ (30$ - 10$)*10. And the report page will be 10*10$ --> 150$.
The purpose of this task is to have always a report correct. For the
margin it will not be always true because it's depending the number of
pieces that we sell. In the above example:
- if we sell 9 units, the margin will be better with this patch
135$/130$ with this commit and 90$/130$ without
- but if we sell 6 units it will be closer to reality with the old patch.
90$/70$ and without 60$/70$
It has other implications: the inventory adjustement and edition of
moves will now takes the AVCO values and not the next to go out.
With the upper example if we add 10 units following an inventory
adjustement (10 * `standard_price`):
- With this commit: 150$
- Current behavior: 100$
Globally it will be closer to reality for products with a price having
a lot of variance and it won't change for the other.
Task-2918885
closesodoo/odoo#108468
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
In this commit, we will convert all the customisations of the list view
consist in adding an always present button in the control panel that
performs an action/calls a model's method.
To do this, we will use the new display="always" parameter applicable
to buttons in the header of list views. This allows us to define a
button that is always visible in a list view.
closesodoo/odoo#106519
Taskid: 3082303
Related: odoo/enterprise#34387
Related: odoo/documentation#3044
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
In some cases, when billing a received quantity that is already
delivered, the account move lines of Stock Interim (Received) will
not be reconciled
To reproduce the issue:
(Need account_accountant, sale_management)
1. Create a product category PC:
- Costing Method: FIFO
- Inventory Valuation: Automated
2. Create a product P
- Type: Storable
- Category: PC
3. Create and confirm a PO with
- 5 x P at $50
4. Process the receipt R
5. Create and confirm a SO with
- 5 X P
6. Process the delivery
7. Create and post partial bill B01 related to PO:
- 1 x P @ $60
8. Accounting > Accounting > Journal Items
- Group By: Account
- Note: There are three lines in Stock Interim (Receipt):
- [AML01] Debit: 0, Credit: 250 (receipt R)
- [AML02] Debit: 60, Credit: 0 (bill B01)
- [AML03] Debit: 0, Credit: 10 (price diff from B01 because
quantity already delivered)
There is a partial reconcile between AML01 and AML02, AML03 is
not part of this partial reconciliation
9. Create and post partial bill B02 related to PO:
- 4 x P @ $60
10. Accounting > Accounting > Journal Items
- Group By: Account
Error: The lines of account 'Stock Interim (Received)' are not
reconciled while it should
When confirming B01, we try to reconcile AML01, AML02, AML03. In the
reconciliation process, we first sort the AMLs and try to create a
partial reconciliation:
https://github.com/odoo/odoo/blob/01cb7e960f912c4758d30c04653b599937785799/addons/account/models/account_move_line.py#L2282-L2293
Because of the sorting, here is the order of the AMLs:
- [AML01] Debit: 0, Credit: 250
- [AML03] Debit: 0, Credit: 10
- [AML02] Debit: 60, Credit: 0
In `_create_reconciliation_partials`, we consume the AMLs in that
specific order. So, it first uses one credit line and a debit one:
https://github.com/odoo/odoo/blob/01cb7e960f912c4758d30c04653b599937785799/addons/account/models/account_move_line.py#L1863-L1872
(i.e. AML01 and AML02) and creates a partial reconciliation for
theses AMLs. It gives a temporary credit line of 190, but there is
no more debit lines, so the partial reconciliation is stopped (this
explains the note at step 8)
Later on, while posting B02, we try again to reconcile the lines of
Stock Interim (Received)
https://github.com/odoo/odoo/blob/493020b9317a439c0a61a34f37cc92b6779ef633/addons/stock_account/models/account_move.py#L249
At that point, we have three AMLs:
- [AML01] Debit: 0, Credit: 250 (same as above)
- [AML04] Debit: 0, Credit: 40 (price diff from B02)
- [AML05] Debit: 240, Credit: 0 (B02)
Back in the reconciliation progress, we try to get all involved AMLs:
https://github.com/odoo/odoo/blob/01cb7e960f912c4758d30c04653b599937785799/addons/account/models/account_move_line.py#L2284-L2287
It will be used later for the full reconciliation. To get the
involved ones, we recursively get the AMLs implied in the partial
reconciliation of AML01, AML04, AML05:
https://github.com/odoo/odoo/blob/01cb7e960f912c4758d30c04653b599937785799/addons/account/models/account_move_line.py#L2481-L2489
Therefore, because of the first partial reconciliation explained above,
we will find AML02 but not AML03. This is the reason why the full
reconciliation will not happen.
Working on the assumption that the note of step 8 is not a bug (i.e.,
AML03 is not expected to be part of the first partial reconciliation),
we need to provide as much AML as we can when calling the
reconciliation process.
OPW-3040171
closesodoo/odoo#107908
X-original-commit: 3050e23f94c865f9938863f191076f761b80fedb
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
Usecase to reproduce:
- Set stock valuation as perpetual
- Create a PO with a different currency than the company
- Validate the receipt on create the invoice
- Set a discount on the invoice and validate it
The amount currency is not set on the account.move.line created by the
valuation layer. It could prevent the reconciliation to succeed since
it would be base on invoice currency.
It happens because the amount currency is created from the difference
between layer price converted to invoice currency and the invoice line
`price_unit`. However `price_unit` is missing the discount. So this pr
add extra computation to get the gross price unit discount applied.
closesodoo/odoo#107256
X-original-commit: 493020b9317a439c0a61a34f37cc92b6779ef633
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
If you try to get show_reset_to_draft_button for more than one account.move, it can raise.
closesodoo/odoo#107169
X-original-commit: a5b985e8449a1e858c3fb9a0a90a6d203e16f739
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
When confirming a bill with a price diff, if the UoM of the bill
line is not the default UoM of the product, the values will be incorrect
To reproduce the issue:
(Need account_accountant)
1. In Settings, enable 'Units of Measure'
2. Create a product category PC:
- Costing Method: FIFO
- Inventory Valuation: Automated
3. Create a product P
- Type: Storable
- Category: PC
4. Create and confirm a PO with
- 1 Dozen x P at $50
5. Process the receipt R01
6. Create and process the return RT01 of R01
7. Create and process the return RT02 of RT01
8. Create the bill related to PO
9. Set the bill line price to $60
10. Confirm
11. Open the valuation of P
Error: a stock valuation layer has been created because of the price
diff, which is correct, however the value is not the good one: $670
instead of $10 ($60 - $50)
When confirming the bill, we check if there is a price difference.
To do so, we compare the price unit of the bill line with the one of
the incoming layer:
https://github.com/odoo/odoo/blob/d3d41c7679f9068a7b986925b15d0d7670233bfc/addons/stock_account/models/account_move.py#L304
But, currently, the price unit of the bill line is based on the UoM
of the line while the price unit of the layer is based on the
default UoM of the product. We need to convert the PU of the bill line
OPW-3081449
OPW-3062433
OPW-3075917
OPW-3048587
OPW-3078429
OPW-3075627
closesodoo/odoo#107145
X-original-commit: a1906f0b5e22f03937389d47e6ce5a650f9269e6
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
When confirming a bill, if its currency is not the one of the
company, and if there is a price diff, the value of the generated
SVL will be incorrect
To reproduce the issue:
(Need account_accountant)
1. Edit the currency of EUR:
- Rate: 2.0
2. Create a product category PC:
- Costing Method: FIFO
- Inventory Valuation: Automated
3. Create a product P
- Type: Storable
- Category: PC
4. Create and confirm a PO with
- 1 x P at $50
5. Process the receipt R01
6. Create and process the return RT01 of R01
7. Create and process the return RT02 of RT01
8. Create the bill related to PO
9. Edit the bill:
- Currency: EUR
- Price unit: 120
10. Confirm
11. Open the valuation of P
Error: a stock valuation layer has been created because of the price
diff, which is correct, however the value is not the good one: $70
instead of $10 ($60 - $50)
When confirming the bill, we check if there is a price difference.
To do so, we compare the price unit of the bill line with the one of
the incoming layer:
https://github.com/odoo/odoo/blob/d3d41c7679f9068a7b986925b15d0d7670233bfc/addons/stock_account/models/account_move.py#L304
But, currently, the price unit of the bill line is based on currency
of the account move wile the price unit of the layer is based in the
currency of the company.
Related to OPW-3040171
X-original-commit: 86ca91c3684fe5ea5dac1326278b5d4cce0cecda
Part-of: odoo/odoo#107145
When confirming a bill with a price diff, if the user received, returned
and received again the products, some unexpected valuation layers will
be generated
To reproduce the issue:
(Need account_accountant, sale_management)
1. Create a product category PC:
- Costing Method: FIFO
- Inventory Valuation: Automated
2. Create a product P
- Type: Storable
- Category: PC
3. Create and confirm a PO with
- 3 x P at $50
4. Process the receipt R01
5. Create and process the return RT01 of R01
6. Create and process the return RT02 of RT01
7. Create and confirm a SO with
- 1 X P
8. Process the delivery
9. Create the bill related to PO
10. Set the bill line unit price to $60
11. Confirm
12. Open the valuation of P
Error: There are two lines for the price difference, there should be
one line only. Moreover, the value is incorrect: 30 instead of 10 (i.e.
we should generate the price diff layer for the quantities in
stock only)
When confirming the bill, we check if we have to generate some
additional SVL (in case of price diff)
https://github.com/odoo/odoo/blob/d3d41c7679f9068a7b986925b15d0d7670233bfc/addons/stock_account/models/account_move.py#L288-L305
But, we get all ingoing SVL and process them, we don't consider that the
quantity of a SVL might actually be returned and should be ignored.
This is the reason why a SVL is created for the first receipt. This
also explains why the value is incorrect (we use the quantity of the
SVL instead of its remaining quantity)
OPW-3040171
X-original-commit: 18912b05239e6fc5dab26ec4c930f9080882d127
Part-of: odoo/odoo#107145
1) forward-port of this PR: https://github.com/odoo/odoo/pull/97000
commit: c9209664ce3a4b10142bba4da6afb912afc983c2
2) use btree_not_null instead of simple btree for space optimisation
closesodoo/odoo#106484
X-original-commit: b743e736f764fd7d6e232d2c8eaf6b2e314c5f31
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
Since e4988b70ab, the record openned from the stock valuation layer
list view will depend on the stock move parent's document. If, the move
has a picking_id set, the record will be the stock picking.
This implies in some cases (a stock move linked to a picking or a
manufacturing order) we cannot access the stock valuation form view and
thus the accounting entries are not reachable from there.
This commit adds a button in the list view to open the layer form view.
closesodoo/odoo#106398
X-original-commit: d5162f814f4d1181e2063f788b7933ce84a32b7c
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
The valuation field of the product_id is company-dependent.
If the user validate the picking in multi-company context with his current company != picking company, then the checks may fail, and the account move can not be created.
closesodoo/odoo#105476
X-original-commit: c29c668d694ef8d675116d42393e496636072d13
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: David <dafr@odoo.com>
In python we can use the default value in dict get method instead of "if else" statement,this will make the code more pythonic.
closesodoo/odoo#105104
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Before this commit, if a user creates a bill from a PO and confirms it.
A stock valuation layer is created. if the user sets the bill to drafts and changes
the product price. a new layer corrects the difference. if the user does
it again, the new layer ignores the previous correction layers, resulting in
wrong valuation.
This commit hides the 'Reset to Draft' button when there are correction layers
found.
closesodoo/odoo#103347
X-original-commit: d3d41c7679f9068a7b986925b15d0d7670233bfc
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Increase code readabilty by replacing "if else" by ternary expression recommanded by python in this uses cases
closesodoo/odoo#104293
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Steps to reproduce the bug:
- Create a Storable product “P1”:
- UOM: unit
- Update the qty to 100
- Create an out transfert:
- Product: P1
- Qty: 2
- UOM: dozens
- Validate the transfert
- Click on the valuation button
- an SVL is created with Qty: 24 → 2 pack of 12
- Go back to the picking:
- Unlock it
- change the done qty from 2 to 3
- Lock the picking
Problem:
The quantity on the new SVL is not converted to the default UoM set on
the product.
In the write function of `stock.move.line` we calculate the difference
between the old and the new qty (3 - 2), then, the
`_create_correction_svl` is called:
https://github.com/odoo/odoo/blob/15.0/addons/stock_account/models/stock_move_line.py#L45-L48
without converting the diff qty into the product uom,
The `_create_out_svl` function is called with the `forced_quantity`
parameter:
https://github.com/odoo/odoo/blob/15.0/addons/stock_account/models/stock_move_line.py#L66
As it is a forced quantity, it will not convert it:
https://github.com/odoo/odoo/blob/14.0/addons/stock_account/models/stock_move.py#L188
Solution:
Convert diff qty in the `_create_correction_svl`, to avoid converting it
in every function it may call
opw-3041279
closesodoo/odoo#104371
X-original-commit: 30aaa668c46f899ed05dee2b6d2f810aa1e6e2e4
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
The goal of this commit is to get rid of the analytic tags as they were confusing, serving tag purposes as well as distribution on analytic accounts.
Everywhere analytic tags were used as a distribution have been replaced with a new widget that will dispatch distribution on analytic accounts. If there was an analytic account field next to the tags, it has been included in the distribution.
Analytic tags that were used simply as information tags have been removed.
To fill the new widget, there are now 2 kind of rules that will help fill and prefill it.
The first are applicability: previous groups have been removed, and have by replaced by plans. Each account is required to have a plan. These plans define when they are available in the widget: a default applicability per plan and applicability lines that can specify rules following the context of the widget.
The second one are distribution models, that will replace previous default rules but follow the same principles. The accounts (and so the plans) that will be given by the distribution model can override the applicability rules from before.
closesodoo/odoo#98914
Related: odoo/upgrade#3885
Related: odoo/enterprise#30743
Signed-off-by: William André (wan) <wan@odoo.com>
Co-authored-by: Habib (ayh) <ayh@odoo.com>
In some buisness case when the invoice is done before the receipt, the
`stock.valuation.layer` price unit will be taken on the invoice rather
than the `purchase.order.line`
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
Quick win in standard price. First check if we are in standard before
computing the price unit. If not do the standard process.
Part-of: odoo/odoo#99411
The move line form view is too technical for the average user so instead we
can to auto-magically open the reference document instead (picking or MO
only for now).
We do the same with stock valuation layers as well, but this feature
will not be available until its custom JS is converted to OWL
"product moves" part of b2b task: 2882539
closesodoo/odoo#97109
Related: odoo/enterprise#29974
Related: odoo/upgrade#3819
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Adds a new reporting view for [storable] product.product to allow for
easier analysis by product (rather than by quant which is location
specific).
This includes:
- adding 3 new fields for products:
- avg_cost = total svl value / total qty
- total_value = avg_cost / on hand
- company_currency_id = self.env.company.currency_id (i.e. the
currently selected company) for which currency symbol to display in
the view
- IMPORTANT NOTE:
- these variables (and some of the existing ones) do NOT support
multi-company aggregations due these values being used to calcuate
future svls which should be company specific. Larger refactoring
would be needed to ensure correct calc in both cases. Larger issue
occurs in stock.report which uses these variables in combination
with variables that do take into account multi-company records.
- A customized `SearchPanel` so that a warehouse context can be applied
to the view, rather than a filter. (viewable only when more than 1
warehouse)
"stock report" part of b2b task: 2882539
Part-of: odoo/odoo#97109
Note this is specific to the view shown when clicking on
"Reporting > Valuation", but this uses the same 'stock.quantity.history'
wizard and related custom js as "Configuration > Locations > Current Stock"
Minor UX updates to valuation report:
- don't default groupby product
- add filters incoming and outgoing (same logic as stock.move filters)
- replace "Inventory at Date" with "Valuation at Date" where appropriate
(but leave location current stock view untouched)
- create separate view for the valuation report so remaining qty/value
are displayed, but all other svl viewing actions (including the
"Valuation at Date") will remain showing the original qty/value to
support deeper analysis
- don't sum unit_cost when groupby is applied in list view since the
value won't make sense
- add "reference" to svl which is = to stock.move.reference
"valuation" part of b2b task: 2882539
Part-of: odoo/odoo#97109
The purpose is to easily identify useful layers needed in an audit.
This way we could create a filter and only see layers that still have
quantity to deliver
Supports task: 2882539
Part-of: odoo/odoo#97109
Inventory report has been updated to have:
- better applicability: report renamed to "Locations" and is only
visible w/Locations, Consignment, or debug mode active
- improved UX: list view rearranged, buttons added, grouping removed,
sums added to bottom of list
- improved quant "Value": instead of the accounting value, this is now
the average unit cost (i.e. sum(valuation layer values)/sum(valuation
layer quantities) per product x on hand qty (of quant).
- single click load for products
- search based on Warehouse option (including storing
location.warehouse_id to avoid overly complex search function)
- always show "Location" column in this view even if multi-locations is
not active
"inventory report" part of b2b task: 2882539
Upgrade PR: odoo/upgrade#3819
Part-of: odoo/odoo#97109
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>
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>
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>
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>
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>
Arnold Moyaux