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 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>
(Received)
In auto-avco, if a user delivers a products before billing its
receipt, the account Stock Interim (Received) will be unbalanced
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
- 1 x P at $50
4. Process the receipt R
5. Create and confirm a SO with
- 1 X P
6. Process the delivery
7. Create the bill B related to PO
8. Set the bill line unit price to $60
9. Confirm
10. Accounting > Accounting > Journal Items
- Group By: Account
Error: The account 'Stock Interim (Received)' is not balanced
(Debit: 60, Credit: 50)
The account entries are:
- Credit 50 related to R
- Debit 60 related to B
There isn't any line for the price difference. Since [1], we don't
generate any price difference layer for the already-delivered
quantities. Before this commit, a layer was generated and posted on
account-side:
https://github.com/odoo/odoo/blob/a5b985e8449a1e858c3fb9a0a90a6d203e16f739/addons/stock_account/models/account_move.py#L68-L69
But, as explained in [1], we should generate the price diff layers
only for the remaining quantities, otherwise it would lead to some
errors on both stock and account side. That being said, we still
have something to do with the price diff related to the out
quantities. This is what this commit is about. In such case, we
generate some journal entries:
- we credit the account 'Stock Interim (Received)' with the price
diff (the account is then balanced)
- we debit the account 'Expenses'
To do so, we:
- Bring back the method
`_stock_account_prepare_anglo_saxon_in_lines_vals` from [2]
- Fix that method because both fields `analytic_account_id` and
`analytic_tag_ids` do not exist anymore [3]
- Update it so it behaves as described above
Note 01: in the steps, we have removed the case 'Receive, Return and
Receive again'. Such a flow breaks the whole accounting and would
not work with some other features. Therefore, we consider such a
flow as invalid (the user could rather create a new purchase order
to receive the quantities again)
Note 02: This behaviour is not supposed to work with the kits. This
commit prevents the lines to be posted in such situation. Suppose
the flow is in a "standard" order (PO, Bill, SO), we also do not
create layers for the price difference:
[1] 18912b05239e6fc5dab26ec4c930f9080882d127
[2] 35d6c58f86
[3] odoo/enterprise@a1eaf200d0
OPW-3040171
OPW-3071238
X-original-commit: 84733fb89faffe2480def97f076633056e16572f
Part-of: odoo/odoo#107908
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
A commit [1] has recently be added to fix an issue. It actually fixes
another issue too:
1. Create a product P
- Storable
- With one packaging PK for 10 x P
2. Create and confirm a PO
- Order Lines:
- 10 x P with PK
3. On the PO, decrease the quantity of P to 8
Without [1], a return is created for the difference. With [1], the
existing picking is correctly updated.
This commit adds a test to protect the use case.
[1] 20fa7c6f0f5c9cdfae2519ea8d0ff849d7fa3b9e
OPW-3027110
closesodoo/odoo#107045
X-original-commit: ccf771d19c5d7b7021c8d0411e11a3f7e9907899
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
The tests in the purchase_stock module include some tests that make sure or
depend on the fact that the price_unit from the generated move lines equals the
price_unit from the purchase order line from which they were created.
However, the price_unit in the move lines exclude taxes (at least those that
have an account set, it uses the total_void computed from the purchase order
line). This means some tests will fail if an installed localization defines
taxes that are included in the price.
The problem is resolved by explicitly creating the test product used in those
tests without supplier taxes.
opw-3033340
closesodoo/odoo#104825
X-original-commit: 70f7e2d70d04df989d3ff8039d3bae7ebdb73a6b
Signed-off-by: Adrien Widart <awt@odoo.com>
Signed-off-by: De Caluwé Tom (tdc) <tdc@odoo.com>
Using patcher.start() can easily lead to incorrect cleanup.
-> after a copy paste, patcher is working, but stop is forgotten
-> stop is present, but won't be called if something fails during the
test
This commit add an utility `start(patcher)` to always have the add
cleanup.
Using a standard way to start the patcher with an automated addCleanup
should prevent this kind of mistake. This is why this commit also
replaces all valid patch.start() (followed immediately by a addCleanup)
closesodoo/odoo#102873
X-original-commit: 7d5a193d86316965a0908c65cfacfb607dc3f3ad
Related: odoo/enterprise#32618
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
Chances are that Journal Entries are coming from previous migration and they
could trigger the creation of CABA Journal Entries even when the company at
stake is a non Cash Basis Company.
closesodoo/odoo#98954
X-original-commit: fcad4dbdbd65775b75aa94049da06bd0b07295d8
Related: odoo/enterprise#30763
Signed-off-by: Laurent Smet <las@odoo.com>
Website: the context install_filename='dummy' is used to prevent
arch_updated from becoming True while updating translations of
ir_ui_view.arch_db (if arch_update becomes True, test_inherit_specific
fails)
Fuzzy search for jsonb translated fields has been adapted in the case of
website. It may require some refactoring later.
If `_merge_moves_fields` is called with a recordset of several SM, and
if there are more than one `self.picking_id`, the method will trigger a
`ValueError` (Expected singleton)
OPW-2861605
closesodoo/odoo#100087
X-original-commit: d3924054437cb2add044f51a3c03346a67f24674
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
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
Current behavior:
In the PoS if you use 2 differents payment methods (cash and customer
account), and that the cash amount given by the client require you to
give some money back, the amount due on the customer account would be
incorrect on the invoice.
Steps to reproduce:
- Start a PoS session
- Add the 750$ desk to the order
- Go in the payment screen
- Add customer account with 300$
- Add cash with 460$
- Click on invoice
- The invoice show that the client need to pay 290$ which is not
correct
Before the fix calling `_prepare_reconciliation_partials()`
with the sorted lines we had 2 credit lines (750€ and 10€)
and 1 debit line (460€).
Debit lines | Credit lines
460€ | 750€
| 10€
The function would reconcile the 2 first lines and stop after that
because the only debit line was fully reconciled
After the fix we have this
Debit lines | Credit lines
460€ | 10€
| 750€
After reconciling the 2 first lines we have this
Debit lines | Credit lines
450€ | 750€
And after reconciling the 2 last lines we have the correct amount left
to pay by the customer (300€)
opw-2857064
closesodoo/odoo#98828
X-original-commit: 1201123e272012b7b5ab65eebfd12a911ecc6c1a
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Engels Robin (roen) <roen@odoo.com>
2-steps receipt. A reordering rule created a picking from Input to Stock
and a purchase order to fulfill the need from Input. The user now
decreases the quantity of the purchase order and then confirms it: an
unexpected picking is created.
To reproduce the issue:
1. In Settings, enable "Multi-Step Routes"
2. Edit the warehouse:
- Incoming Shipments: 2 steps
3. Create a product P:
- Type: Storable
- With a vendor
- Routes: Buy
4. Add a reordering rule to P:
- Min = Max = 0
5. Create and confirm a planned delivery order with 5 x P
6. Run the scheduler, it should create:
- An internal transfer IT (Input -> Stock) with one stock move SM
- A purchase order PO
7. Edit PO:
- 4 x P (instead of 5)
8. Confirm PO
9. List all transfers related to P
Error: There is a transfer from Stock to Input with 1 x P. It should not
exist and its stock move should be merged with SM
As explained, when running the scheduler, a stock move from Input to
Stock is created. Let SM01 be that stock move.
When confirming the PO, two stock moves SM02 and SM03 are created, both
from Vendors to Input. The first one has a quantity equal to 5 and the
second one to -1. When confirming these stock moves, we apply the 'push
rules'
https://github.com/odoo/odoo/blob/0183298293192538a801f52262c047ea34a1b76a/addons/stock/models/stock_move.py#L1233
Since SM02 already has one `move_dest_ids` (i.e., SM01), we skip it.
However, we can apply a push rule on SM03. It creates an new stock move
SM04 with -1 x P from Input to Stock:
https://github.com/odoo/odoo/blob/7e8a038e3a08e32a9a32ac66ef0dc67800af95cb/addons/stock/models/stock_rule.py#L192-L196
And, as shown in the above code, we then define this new SM04 as a
`move_dest_ids` of SM03. So, at that point, here is the situation:
| Name | Qty | From | To | Dest |
|------|-----|---------|-------|------|
| SM01 | 5 | Input | Stock | / |
| SM02 | 5 | Vendors | Input | SM01 |
| SM03 | -1 | Vendors | Input | SM04 |
| SM04 | -1 | Input | Stock | / |
Back to the confirmation of SM2 and SM3, we eventually try to confirm
the moves created from push rules (i.e., SM04):
https://github.com/odoo/odoo/blob/0183298293192538a801f52262c047ea34a1b76a/addons/stock/models/stock_move.py#L1268-L1269
As shown, we don't define any `merge_into`. During the confirmation of
SM04, we try to assign it to a picking. However, because of its negative
qty, we skip it:
https://github.com/odoo/odoo/blob/0183298293192538a801f52262c047ea34a1b76a/addons/stock/models/stock_move.py#L1077-L1081
Then, still in the confirmation of SM04, we try to merge it with some
other SMs. Because there isn't any `merge_into`, we try to find some
candidates:
https://github.com/odoo/odoo/blob/0183298293192538a801f52262c047ea34a1b76a/addons/stock/models/stock_move.py#L839-L840
And because SM04 does not have any picking, we don't find any candidate:
https://github.com/odoo/odoo/blob/0183298293192538a801f52262c047ea34a1b76a/addons/stock/models/stock_move.py#L826-L828
As a result, we don't merge it and we will create the unexpected
picking.
=> In such situation (when confirming a negative push move), we should
suggest some candidates.
Last but not least: suppose the above issue as fixed and reproduce the
same steps, but this time the product P has a description. Again, when
confirming the PO, the same unexpected picking will be created.
When running the scheduler, SM01 is created and its field
`description_picking` is defined thanks to the description of P:
https://github.com/odoo/odoo/blob/f11d9c3ea08fc98e62459602d9bce004e83898db/addons/stock/models/product.py#L237-L243
However, when creating SM03, we use the name of the purchase line (i.e.,
the product's name) as description because, in our case, the product
does not have any `description_pickingin`:
https://github.com/odoo/odoo/blob/c18b2ce767dd5a5b4dbe766b849b56243dffb723/addons/purchase_stock/models/purchase.py#L523
And, as shown before, SM04 is partially a copy of SM03: it has the same
`description_picking`. As a result, SM01 and SM04 doesn't have the same
value for that field and we can not merge them.
OPW-2861605
closesodoo/odoo#97599
X-original-commit: 43ca47cdfec696b847f716984f76df16de7b97b7
Signed-off-by: Tiffany Chang <tic@odoo.com>
Signed-off-by: Adrien Widart <awt@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>
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>
In module mail, invalidating 'message_ids' on a mail thread also
invalidates its inverse field 'res_id' on messages. If you haven't
flushed it before, your cache will be inconsistent, as shown by the test
/mail:TestMailgateway.test_message_process_bounce_records_channel.
In module purchase_stock, add depends on report.stock.quantity. This
ensures that when the model is queried after changes in other models,
the data on which the SQL view depends is flushed to the database before
querying that model's table.
closesodoo/odoo#66938
Related: odoo/enterprise#16722
Signed-off-by: Raphael Collet <rco@odoo.com>
Co-authored-by: Vincent Schippefilt <vsc@odoo.com>
Updating the scheduled date of a delivery doesn't update the quantity to
order of an orderpoint
To reproduce the issue:
(Need purchase)
1. Create a storable product P with a seller
2. Create and confirm a planned delivery D with 1 x P
3. Open the replenishment page
- There should be a line for P (Forecast: -1, To Order: 1)
4. Edit D and postpone the scheduled date
5. Go back to replenishment page
Error: The line is still present, its forecast qty is correct (0) but
the quantity to order is still 1 (instead of 0)
`qty_to_order` is a stored field, so when loading the replenishment
page, its compute method is not called. Moreover, even though
`qty_to_order` depends on `qty_forecast` and the compute method of
`qty_forecast` is called, it still won't trigger the compute:
when setting the value of `qty_forecast` from its compute method, it
will lead to:
https://github.com/odoo/odoo/blob/b54f78de307543efcea934206806f361eaac811a/odoo/fields.py#L1106-L1109
So, as shown and explained, we bypass the `write` of `BaseModel` and
skip the business logic and the recomputations
The compute of `qty_to_order` should actually be triggered earlier: when
we edit the scheduled date (step 4). That's the reason why this commit
adds a dependency to the compute of `qty_forecast`: it makes more sense
and becomes an implicit dependency of `qty_to_order` -> update the
scheduled date will trigger the compute of `qty_to_order`
OPW-2868167
closesodoo/odoo#94400
X-original-commit: 791b68fc02cbc4dc5b376e5fc5d37e725f88d0dc
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
1. Activate anglo saxon accounting
2. Create product with automated inventory valuation and standard pricing
3. Set decimal accuracy to 6
4. Set product cost price to 0,01719
5. Create PO for 30.000 items -> price = 0,01782 -> total = 534,6
6. Receive goods -> stock journal entry = 515,7 (based on the cost, ok)
7. Create vendor bill
Price difference is incorrect if you have a tax rate in the vendor bill
`price_unit_val_dif` will be rounded to 0.02
Multiplied by a great quantity the result will be wrong (84.30)
Without using the tax rate the price difference amount is the expected one
This commit partially revert 643d91ef5ebfb29fde142294ced82c470d42c136
to improve the original fix.
opw-2849074
closesodoo/odoo#94346
X-original-commit: 315a18f12f9d67284bbd8b027ca652db17aae9d2
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: Grazioso Andrea (agr) <agr@odoo.com>
Instead of having to repeatedly manually call `onchange_quantity` at
different points in the code, it is better to have it be computed
instead.
- Logic is left unchanged,
- onchange calls from other methods are removed, and
- tests are adjusted to properly handle compute. I.e. remove
'date_planned': datetime.today().strftime(DEFAULT_SERVER_DATETIME_FORMAT)
from when PO lines are created since this sometimes resulted in
inconsistent date_planned values for PO line and the PO date_order
(by 1 sec), which could lead to inconsistently created 'date_deadline'
values for stock_moves' created by PO line qty changes. Issue
previously didn't exist because onchange was not always called.
Part of Task: 2695116 (to avoid adding more onchange calls for new
feature)
Part-of: odoo/odoo#87656
Since https://github.com/odoo/odoo/pull/86682, when a user opens
the replenishment view, the Days to Purchase are not taken into
consideration when calculating the forecast of a product.
This was due to the fact that the Days to Purchase are now taken from the
orderpoint and not from the company settings. This is fixed by taking
the company setting if no value from the orderpoint is sent to the
method.
closesodoo/odoo#93252
Task-id: 2871408
X-original-commit: ac1df1949e4523aff65543f1381300fc7de3b4e4
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: npi-odoo <npi@odoo.com>
This commit contains the following:
1) Added sudo to product record when adding supplier info during PO confirm, so that
supplier info is created regardless of who is confirming the PO.
2) the test test_multicompany_partner_bank was removed since it was creating two
res partner banks with the same partner and setting company_id to two seperate companies
while currently the company_id is related to the company partner thus this can no longer
happen.
3) test_message_qty_already_received was changed to not set the company_id explicitly as
it caused unexpected cache miss in the runbot.
task : 2764771
Part-of: odoo/odoo#91640
- Add the concept of 'Days to Prepare MO' in mrp, similar to 'Days to
Purchase' but defined at the product level. Both concepts are merged into
Days to Order at the orderpoint level, taking the value of Days to Purchase
for orderpoints with a buy route and Days to Prepare MO for orderpoint with a
manufacturing route.
- Add the concept of 'Visibility Days' on orderpoints. The idea is to
avoid to create through reordering rules multiple small orders for the
same product on a small time frame but rather to order directly a bigger
quantity. When Visibility Days are defined, the quantity of the orders
created by a RR is not the quantity forecasted at Today + Lead times
(quantity that triggered the order according to the RR), but the
quantity forecasted at Today + Lead Times + Visibility days.
The Visibility Days are different for purchase and manufacturing.
Changing the route of the orderpoint will change its value. They
can be defined at the company level and further fine-tuned on the
orderpoint. In case of change of the parameters at the company level,
only orderpoints without a specific value of Visibility Days will
be changed.
- Alignement between Manufacturing and Purchase Security Lead Time
(previously the Manufacturing Security Lead time didn't impact the
procurement date, instead the manufacturing time was made longer).
closesodoo/odoo#86682
Task-id: 2738838
Pr: https://github.com/odoo/odoo/pull/86682
Related: odoo/upgrade#3415
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Steps to reproduce the bug:
- Create a storable product “P1”:
- Standard price: 20$
- Add vendor in the Purchase tab:
- name: Azure Interior
- min qty: 10
- price: $15
- Create a PO:
- Vendor: "Azure Interior"
- Product line: “P1”
Automatically, the Quantity field will automatically get populated as 10 Units
and price:$15 as per the pricelist
- Confirm the PO
A picking will be created containing a stock_move with a price of $15 and a QTY of 10
- Edit the Quantity to 9 Units and save the PO
The price will be updated to $20 on the PO line, but not in the `stock.move`
Problem:
When we update the qty in the PO line, a new move with a quantity of “-1” and
a price of “$20” will be created.
Then, it will be merged with the initial move, but since they are not identical in the price,
we can't merge them, so a new picking is created:
https://github.com/odoo/odoo/blob/dda9700d8236091626cbd78efc0ca4116e1e1acd/addons/stock/models/stock_move.py#L869-L881
Solution:
when the price is updated in a PO line, the price of its linked `stock.move` must also be updated
opw-2825160
closesodoo/odoo#92208
X-original-commit: c8d74a1cb4bfed8226e52e0bc6f243b4e483fc98
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
In a 2-steps configuration, trigger a reordering rule with the vendor
defined will raise an error
To reproduce the issue:
1. In Settings, enable "Multi-Step Routes"
2. Edit the existing warehouse:
- Incoming Shipments: 2 steps
3. Create a product P:
- Type: Storable
- Add a vendor V
- Routes: Buy
4. Create a reordering rule R for P:
- Trigger: Manual
- Min = Max = 1
5. Open the Replenishment page and edit R:
- Preferred Route: Buy
- Vendor: V
6. Trigger the orderpoint
Error: An Odoo Server Error is displayed "AttributeError:
'product.supplierinfo' object has no attribute 'name'"
When triggering the orderpoint, it leads to
https://github.com/odoo/odoo/blob/c75a1a8ac9eef6c7d7c95b7bbbb22d919b952e26/addons/purchase_stock/models/stock_rule.py#L331
However, since [1], the `name` of a `product.supplierinfo` has been
renamed to `partner_id`
[1] f3fe2d50d9
OPW-2780562
closesodoo/odoo#90597
X-original-commit: bda8b0e610f7ec9b0bcb76de3bb52fb6049f62ff
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
Have a purchase tax with cash basis payment enabled
Have a product with said tax
Create a bill with the product, save and confirm
Register a payment
Check CABA entries
There should be 4 entries, but only 2 have been generated
opw-2782561
closesodoo/odoo#89101
X-original-commit: d8d255ec68ab4f220da51fb2be7292dcc74d5783
Signed-off-by: Olivier Colson <oco@odoo.com>
Signed-off-by: Grazioso Andrea (agr) <agr@odoo.com>
Co-authored-by: oco-odoo <oco@odoo.com>
If the user triggers several orderpoints one by one, some purchase order
lines may be merged while they shouldn't.
To reproduce the issue:
1. In Settings, enable "Storage Locations"
2. Create a product P:
- Type: Storable
- With a vendor V
- Route: Buy
3. Add two reordering rules to P:
- Min=Max=1 at WH/Stock
- Min=Max=2 at WH/Stock/Shelf 1
4. Inventory > Operations > Replenishment, trigger the orderpoints of P
(one by one)
5. Open the generated PO
Error: There is only one line with 3 x P, there should be two lines (1 x
P + 2 x P, one for each orderpoint). If the user confirms the PO and
receives the products, the destination location will be Stock or Shelf 1
(depending on the last orderpoint triggered)
Running the orderpoint leads to `_run_buy`, where we try to find an
existing PO line so we can update it (else we will create a new one):
https://github.com/odoo/odoo/blob/5b34adb51eda978aa9ef1a434ab77257d73b9594/addons/purchase_stock/models/stock_rule.py#L122-L129
Here is the issue: the filter in `_find_candidate` contains an `or True`
that makes a whole condition useless.
Considering [1], the condition on `move_dest_ids` is only relevant when
an orderpoint is defined. Therefore, we can remove the `or True` and
improve the condition
[1] 63fffa0bee
OPW-2720868
closesodoo/odoo#88959
X-original-commit: 0802d4c61d7b47f0b32a36c5bb0ec49a0f425043
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
Steps to reproduce:
• Create Record: Product Category
- Costing Method: Average
- Inventory Valuation: Automated
- Specify a price difference account (may create new account).
- Ensure Stock Interim (Received) account is reconcilable.
• Create Record: Product
- Product Type: Storable
- Cost Price: 1.01
- Product Category: New Product Category
• Create bill with this product, for a quantity of 10.5
-> The is price difference of 0.1
Issue comes from this commit 286ea6b681e9ba77357f91b546052449f6342f20
which doesn't round if there is a discount.
With this commit we isolate the latter case in order to keep the
price unit rounded if there is no discount.
closesodoo/odoo#88734
X-original-commit: 643d91ef5ebfb29fde142294ced82c470d42c136
Signed-off-by: Florian Gilbert <flg@odoo.com>
* Previously, when reconciling journal items in multi-currencies, the exchange difference entry was created only on the full reconciliation. It will now be created directly at each partial to ensure the ratio between amount_residual_currency and amount_residual is always kept identical.
* Also when reconciling two lines, one with a foreign currency and one expressed in company currency, the reconciliation is now made based on the foreign currency.
==== RATIONALE ====
This patch allows to fix the following use cases (among others)
1) When everything is expressed in foreign currency, the reconciliation is made in that currency:
Suppose EUR is the foreign currency and USD is the company currency. Reconciling:
L1: 120 EUR 60 USD (rate 2:1)
L2: 240 EUR 80 USD (rate 3:1)
..leads to a partial of 120 EUR and min(80, 60) = 60 USD
After the reconciliation, L1 is fully matched but L2 is still open with 120 EUR but only 20 USD.
This is the first problem is the current reconciliation because L2 is supposed to have a rate 3:1 so the residual amount should be 120 / 3 = 40 USD.
Since the rate is no longer consistent on L2, the user will probably close the reconciliation by using another line in EUR or will close manually the reconciliation with 20 USD but without any additional exchange difference journal items explaining where this unconsistency comes from.
2) When the current lines are mixing multiple currencies, the reconciliation is made using the company's currency.
In some countries like Mexico, Ethiopia or Costa Rica, the customer is free to pay an invoice using the company's currency instead of the foreign one.
So, suppose USD is the foreign currency and MXN is the company currency.
The invoice is expressed by:
L1: 120 USD 60 MXN (rate 2:1)
If the customer is paying at a date in which the rate is 3:1, he is free to pay
either L2: 120 USD 40 MXN (rate 3:1), either L2: 40 MXN.
In the second case, he is expecting the invoice to be fully paid because its paiement is equivalent to 120 USD at the payment date.
In Odoo, the second case led to an open balance of 20 MXN and the invoice was not completely paid.
Even this situation could be easily fixed by a manual write-off, this makes the Mexican payment EDI very complicated to fullfil correctly because the government is expecting a complete matching between the invoice and the payment.
When the customer is paying multiple invoices or the invoices are paid using multiple payments, the currently generated mexican EDI file in Odoo was wrong.
==== REFERENCES ====
Original idea suggested by hbto@vauxoo.com. Thanks for the contribution and patience of the many persons having, at some point, helped on that.
github issue: https://github.com/odoo/odoo/issues/37469closesodoo/odoo#84201
Task: 2669371
Related: odoo/enterprise#24268
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
When a PO is in the "To Approve" state, it disappears from the
forecasted report
To reproduce the issue:
1. In Settings, enable "Purchase Order Approval" with a minimum amount
equal to 0
2. Create a storable product P
3. With Marc Demo:
- Create a PO with 50 x P
- Consult the forecasted report of P: there are 50 x P "Forecasted +
Pending"
- Confirm the PO (its state becomes "To Approve")
- Consult the forecasted report of P
Error: The 50 x P disappeared: 0 On Hand, 0 Forecasted, 0 Forecasted +
Pending. We should still see 50 Forecasted + Pending
OPW-2774586
closesodoo/odoo#86476
X-original-commit: c66fc2f3bfd069642fc9ed61ff322a136974a65c
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
Usecase to reproduce:
- Create product 1 with supplier `Vendor` and a delay of 3 days
- Create product 2 with supplier `Vendor` and a delay of 4 days
- Create two procurements with a need for stock at 01-01-2022 (warehouse
1 step)
- Run procurement for product 1
- Run procurement for product 2
The PO contains the two product but the order date is for 3 days before
and not 4. Also the line for product 2 is planned for the 02-01-2022
It happens because the delivery date is computed base on the purchase
order date and the supplier but the procurement is totaly ignore
X-original-commit: aec7fcdb693729f432ae2341c00ef317b65fbcbc
Part-of: odoo/odoo#83430
Suppose a product with several suppliers, all with the same partner. On
the purchase order, the product description will always be based on the
last supplier
To reproduce the issue:
1. Create a vendor V
2. Create a product P:
- Type: Storable
- In Purchase, add a line L01:
- Vendor: V
- Vendor Product Name: Name01
- Vendor Product Code: C01
- Quantity: 1
- Price: 10
- In Purchase, add a second line L02:
- Vendor: V
- Vendor Product Name: Name02
- Vendor Product Code: C02
- Quantity: 20
- Price: 2
- Once P is saved, ensure the lines order in the purchase tab:
- L01
- L02
3. Add a reordering rule on P:
- Min: 1
4. Run the scheduler
5. Open the generated PO
Error: The description is incorrect ("[C02] Name02" instead of "[C01]
Name01")
When computing the display name of the product,
https://github.com/odoo/odoo/blob/7691567286869ca65e63fc79c2cee11e1f415fcb/odoo/models.py#L1728-L1730
`name_get` returns a tuples list: `[(37, '[C01] Name01'), (37, '[C02]
Name02')]` where `37` is the product identifier. This list is then
converted into a dictionary and here is the issue: it will use the last
tuple to define the value for key `37`, i.e. "[C02] Name02". Therefore,
`name_get` should return the correct name, and only this one.
Another issue could be highlighted: when the user changes the quantity
of the purchase order line, if another supplier info is selected, the
description won't be updated (for the same reason as above)
OPW-2702616
closesodoo/odoo#82321
X-original-commit: a42608214f2e9ef3f5e59b4b54cd7f72a6019e06
Signed-off-by: Tiffany Chang <tic@odoo.com>
Signed-off-by: Adrien Widart <awt@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
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
Testing purchase order creation assumes the whole test is done the same
day. The assert could failed if the test is run right before midnight
and end the day after.
This commit ensure the time is frozen during all the tests about
purchase order creation.
closesodoo/odoo#80264
X-original-commit: 438e47cdc87fc0f13c61a1ede29a190120dea117
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Remove the Purchase Security Lead Time from the computing of the
purchase order's picking deadline to better reflect that the shipment is
actually meant to arrive earlier than date + security lead time.
Also makes sure that receipts and subsequent pickings (multi-step
reception) are planned the earliest possible, not taking the purchase
security lead time into account.
Task-2656397
Part-of: odoo/odoo#79523
Expected behavior : The log note sent when received quantity is updated should take into account the quantity already received.
Current behavior : The log note sent doesn't take into account the quantity already received for a 'stock_moves'. So it always displays `Received Quantity: 0.0 -> quantity in stock` instead of `Received Quantity: quantity already received -> quantity in stock`
Steps to reproduce the error :
- Create a RFQ with few units of a Storable Product (e.g. 5 units)
- Partially validate the receipt and create a backorder (e.g. 3 units)
- Validate the backorder (e.g. 2 units)
Log notes should be :
`Received Quantity: 0.0 -> 3.0`
`Received Quantity: 3.0 -> 5.0`
But are :
`Received Quantity: 0.0 -> 3.0`
`Received Quantity: 0.0 -> 5.0`
The value is always equal to 0.0 because `qty_received_method == 'stock_moves'` so `line.qty_received` is overridden by 0.0 in parent `_compute_qty_received` even though its value is already set to 0.0 (default) or to the quantity already received
opw-2600221
opw-2613116
closesodoo/odoo#78858
X-original-commit: 0c8ea86fb8d706af139cd2d412d01487e5899df6
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
In a lot of test class, we use `setUp` instead of
`setUpClass`. `setUp` is execute for each test method and `setUpClass`
will be execute only once by Class (and use savepoint + rollback).
Then change setUp into setUpClass reduce the time to make all tests
and avoid to repeat this error for the future.
closesodoo/odoo#78082
Related: odoo/enterprise#21563
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
Arnold Moyaux