In https://github.com/odoo/odoo/pull/110737, I didn't consider that
compute could be called on NewId record with `_origin`. Some compute
methods are badly refactored with the new signature of `_read_group`.
We use recordsets returning from `_read_group` to assign field value to
`self`. But if `self` contains `NewId` with `origin`, these records
don't represent `self`, it contains real record instead of the one with
NewId + origin. Then the assignations are done on records not in `self`
which may lead to generate traceback or write to other records during
an onchange.
Fix multiple compute to work correctly with NewId (origin set) record.
X-original-commit: bd22d0a5c479a72cdaf799309387e41ce692bb29
Part-of: odoo/odoo#132261
There will be some access errors if an accountman tries to post an
invoice
To reproduce the issue:
1. Create a product category FIFO-AUTO
2. Receive a product of that category at $10
3. Sale, deliver and create the invoice for that product
4. Create a user with basic access to account app only
5. Switch into that user
6. Confirm the invoice
Error: An error access is raised, he can not post the invoice
In the invoice posting process, we try to read some other models
(pos order, SVL, and so on) but the user has not any access to them
OPW-3302458
closesodoo/odoo#130301
X-original-commit: fbd8c96d0ea097a23fc1e283721f8219fe7ebcd0
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: Adrien Widart (awt) <awt@odoo.com>
Allow sharing records between company
* accounts
* taxes
* fiscal positions
* products
* ...and some related models
These records can be read and used in children companies.
This can be used to
* have different branding for different businesses
* allow more complex security rules
* consolidate branches differently
* manage different tax reports with different tax ids in the same
country
task-3371677
closesodoo/odoo#125642
Related: odoo/enterprise#43215
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
Before this commit:
When returning a transfer in AVCO/FIFO, the return's value is not always
the same as the original delivery. The unit cost for the return was
rounded, which introduced rounding errors.
After this commit:
When returning a transfer in AVCO/FIFO, the return's unit cost is not
rounded, allowing the correct value to be set.
Steps to reproduce:
1. Create a product and change its category costing method to AVCO
2. Purchase the product qty: 1 price: 13.13
3. Purchase the product qty: 1 price: 12.20
4. Sell the 2 product and deliver it
5. Create a return for the delivery
6. The value on the delivery is 25.33, but 25.34 on the return
opw-3358531
closesodoo/odoo#129025
X-original-commit: 5043b4b5099dc395234c1d5d8422b8fa7f1d94c8
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Fixes the formatted string to add the correct reference
in case of no picking. e.g. mrp correction
To Fix:
without parenthesis around the expression, the first value is
considered as the value instead of evaluating the complete expression.
**Results in:**
`Correction of False (modification of past move)`
closesodoo/odoo#128619
X-original-commit: 81fd11fe70357f638434bab44705c91008efb25f
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Steps to reproduce the bug:
- Create a storable product “P1” with BoM:
- Component: "C1", cost: $100
- Create a Manufacturing Order to produce 1 unit of "P1":
- Set any analytic account
- Confirm and validate the MO
- An analytic account line is created for $100 of C1.
- Change the quantity of the component to 0.
- Try to save
Problem:
A traceback is triggered, because the `amount` and `unit_amount`
variables are used without assignment.
Solution:
Assign “0” value to both variable in the beginning of the function,
therefore the analytic account line will be deleted.
opw-3257240
closesodoo/odoo#128495
X-original-commit: 513e3dea2c838bb6f805c567069ea39406c6634e
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
To reproduce:
1. Create a Sales Order for a product whose product category is set to
FIFO and automated. Use route "dropship".
2. Confirm the PO created.
3. Deliver the products (DS transfer)
5. Return, for example, 1 unit of product
6. Return the return
This is a continuation of commit f9a1c1d7bb8234eb96c48dddae9930a419bfb696
If the origin of the move is a dropshipped_returned, then the error describe in the mentioned commit will still happen.
opw-3283436
closesodoo/odoo#127403
X-original-commit: b7a91e3682aad7ecc1a4a8a42b2d6368573ba906
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: David Fesquet (dafr) <dafr@odoo.com>
If a bill has a price difference with the PO, and if the user
refunds it, it will create some errors in the inventory valuation and
the accounting entries
To reproduce the issue:
(Need account_accountant)
1. Create a product category PC
- Costing method: FIFO
- Inventory valuation: Automated
2. Create a product P
- Type: Storable
- Category: PC
3. Confirm a PO with 1 x P at $10
4. Receive P
5. Bill it at $15
- It should create a price diff SVL, see inventory valuation
6. Refund
Errors: The inventory valuation is not impacted, it is still valued
at $15. Because of the refund, it should be $10 (i.e., the price
difference should be cancelled). Then, suppose the user creates a
new bill at $20, it won't do anything (the stock valuation will not
be impacted).
Long story short: the price difference feature, which is supposed to
impact inventory valuation/account entries, does not work if there
is a (partial/full) refund in the flow.
Now, let's think about a more complicated use case:
- Receive 12 products in several times
- Bill in several times (with different quantities than the receipts)
It could give something like (where `x` are products):
```
SVL01 SVL02 SVL03
/---------------\/---------\/------------------\
x x x x x x x x x x x x
\-----------/\-----/\--/\---------------/\------/
B01 B02 B03 B04 B05
('B' means Bill)
```
We observe that
- a bill could impact several layers
- a layers could be impacted by several bills
And here is the issue: currently in the code, we don't have a relevant
link between layers, account move lines and the quantity that links
both. The only thing we have is a link between the price difference SVL
and the account move line that has generated that SVL (see field
`account_move_line_id` on `stock.valuation.layer`). But this is
clearly not enough and is really problematic: if I refund BILL04, how
should it impact SVL02 ? Then, what if I return a part of the third
delivery before refunding BILL04 ? What if I deliver a part of the
received products before refunding several bills ? What if I refund
B02, B05, then I bill 4 products ?
-> You get the idea: we definitly need a clear link between account
move lines and stock valuation layers and that link has to give a
quantity.
Moreover, it is difficult to create an order between bills. We have
their name, their ID, but the posted time is actually a date. So, if
we mix reset & repost, a draft bill and a draft partial refund, and
so on, and if this mix happens the same day, it is very difficult to
define a clear order. But, considering the above schema, we see that
the order does matter (switch BILL02 and BILL03, the remaining
values of SVL01 and SVL02 will not be the same)
-> So, we also need a way to order the links between account move lines
and stock valuation layers.
Now, about the solution.
First, a **disclaimer**: We are in stable, we are limited by the stable
policy, and we can't let the above use cases unresolved. So, we took
some decisions to fix them and to repesct all the constraints we had.
**This is clearly a (big) patch, it should be considered as such and
will be replaced by a cleaner/better solution on master as soon as
possible**.
About the link between SVL and AML, we had the possibility to create
a new model in a new module. But this would have decreased the
impact of the fix deployment, would have created some
complications for support (different behaviours depending on whether
the module is installed or not) and would have make testing more
complicated (again, different behaviours depending on whether the
module is installed or not).
This is the reason why we decided to "replay the receipts and the
bills". That way, we know which layer is impacted by which invoices,
and vice versa. And, to set the order between all of them:
- For the layers, we use their `create_date`
- For the bills, we use a hack: each time an account move is posted,
because its state is tracked, a tracking value is posted on the
chatter, and this tracking value has a `create_date` (remind the
constraints explained above and the disclaimer...)
OPW-3217215
closesodoo/odoo#126536
X-original-commit: b5e0e1057b81f7333e73ef06e88e8943709119cc
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: Adrien Widart (awt) <awt@odoo.com>
Improve the returns process by adding the following improvements:
- Removal of the 'return' operations type. Returns of deliveries now
become receipts.
- Update of the `stock_picking_return` wizard by removing the onchange
on picking_id.
- Show returns in the sale portal, with a new 'return label' PDF report
- Enable returns for multi-step receipts on purchases
Community PR: https://github.com/odoo/odoo/pull/118568
Enterprise PR: https://github.com/odoo/enterprise/pull/39761closesodoo/odoo#118568
Task: 3081370
Related: odoo/upgrade#4660
Related: odoo/enterprise#39761
Signed-off-by: Tiffany Chang <tic@odoo.com>
The index is being added because when processing a large PoS session, the method consume_specific_qty is called a large number of times if the product categories are set to automatic valuations. This method has the line:
tmp_value += qty_taken_on_candidate * ((candidate.value + sum(candidate.stock_valuation_layer_ids.mapped('value'))) / candidate.quantity)
This line, when running upwards of 20,000 times, can cause large performance issues, due to the stock_valuation_layer_ids being a related field on stock_valuation_layer_id.
This causes a doubling of the number of sql queries which causes slowdowns in performance. Adding this index drastically improves the performance of the queries generated by this line of code.
opw-3295560
closesodoo/odoo#126207
X-original-commit: 6f491e34d9355d1e45599fd0c881d7d721ea7d73
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
After creating a sales order for a product with cost 0, automatic
inventory valuation and AVCO, and validating the delivery, no account
move is created for the stock move. If an invoice is then created from
the sales order, it will create 0 amount COGS lines. Automatic
reconciliation of the invoice with the corresponding stock account move
will fail because no such entry exists, resulting in unreconciled lines
remaining in the invoices.
This issue can be prevented by either creating a 0 amount journal entry
for the stock move, or preventing the creation of the 0 amount COGS
lines on the invoice. Not creating unnecessary COGS lines is preferable
and this was also the solution used for the same problem with purchase
order invoices: https://github.com/odoo/odoo/pull/106785 .
So this fix does the same for sales order invoices.
opw-3000320
closesodoo/odoo#125185
X-original-commit: 999451e6ea0b2b1591a3644725b5313c6e062b39
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
Signed-off-by: Merel Geens <mege@odoo.com>
To reproduce:
1. Create a Sales Order for a product whose product category is set to
FIFO and automated. Use route "dropship".
2. Confirm the PO created.
3. Deliver the products (DS transfer)
4. Create the customer invoice
5. Return, for example, 1 unit of product
6. Add a credit note to the invoice for that 1 unit returned (reset to
draft then change qty and post)
Issues:
The value on the valuation layers of the returned picking is 0, posted
entries for COGS and stock interim (delivered) account for credit note
is also 0.
Since #85751, When create valuation layer for return, we take all svls
of origin_returned_move_id into account to calculate the price unit.
However, then dropshiping, 2 svls are created for the original move, and
the sum of them is 0 since there is no impact of the stock when
dropshiping. So when return, the price unit will be calculated as 0.
To fix, when calculate price unit for return of dropshiping, we only
take non-negative svls into account. Note that we use non-negative ones
instead of positive ones because when subcontract dropshiping,
additional negative svls will be added for the cost of the components.
opw-3283436
closesodoo/odoo#124856
X-original-commit: 1c6c163f72301cab29c2f26021bb1ae6fb20dc7f
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: Yuchen Huang (yhu) <yhu@odoo.com>
Attribute Error: 'frozendict' object has no attribute 'default_product_id'
traceback that occurs in stock/stock_quant: action_inventory_at_date
was caught by a sentry.
steps to produce:-
- Install inventory module
- Select any product from the menu item/reporting/stock
- Click replenish button & from that replenish wizard, select the product again
- Then click the forecasted stat button and in forecast click the On Hand button
- Then click Inventory At Date.
At this moment you find a traceback.
Because default_product_id is not getting from the context in inventory.
Applying these changes will resolve this issue.
sentry:-4148733813
closesodoo/odoo#122741
X-original-commit: ca58b13d63702ac2ec8d74b855b90058bf18eb7b
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Usecase to reproduce:
- Set the currencies as 1€ = 2$ ($ as company currency)
- Create a PO for a product in AVCO auto with a price of 100€
- Do the receipt
- Change the rate as 1€ = 4$
- Bill the PO
Expected behavior:
- One correction account.move.line for the 200$ and the stock
interim receipt account reconciled.
Current behavior:
- An aml from the price difference with the 200$
- Another from the currency exchange also for 200$
- The line from the price diff is not reconcile
`_stock_account_anglo_saxon_reconcile_valuation` should never reconcile
account.move.line from a price difference correction without the context
key no_exchange_difference because the currency correction is already
handle in the correction layer.
closesodoo/odoo#120158
X-original-commit: b8bbd7e2a3f8f9e119b11314bcebfadb2ba75eda
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
AttributeError "account.move.line" object has no attribute "purchase_line_id"
occurs in `stock_account` when we confirm vendor BILL or REFUND with product
costing method "first in first out" or "average cost".
With the recent reflacted changes in commit[1], the `purchase_line_id`
field is used and it belongs to `purchase`, but it is not installed and does
not depend, so it causes an error.
The above issue is solved by removing some code in commit[1] from
`stock_account` and adding it to `purchase_stock`.
committ[1] - https://github.com/odoo/odoo/pull/99411/commits/e9ce88a9372843abef7cf8fc94c4dbe5f16c5fa3#diff-e6134a1a5a13058e35f86426a96db0acac44553fa3b0ca26716390f7b19fc96cR318
sentry-3975529425
closesodoo/odoo#121070
X-original-commit: 23ba3c6684e388bcfe317e7ab9f4c9008622e2b4
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: Ansari Mahamadasif (maan) <maan@odoo.com>
account
1. We introduced a new Production Cost account that can be set on
locations with Production type. When products move into/out of a
production location. The account entry will be post on this account
instead of previous Stock in/out account.
2. On the accounting setting page, we can now set the default values for
all stock accounts. Users can also disable automatically accounting for
stock there.
Task-3046333
closesodoo/odoo#113973
Related: odoo/enterprise#37653
Signed-off-by: Tiffany Chang <tic@odoo.com>
Adds the storage of the product's `categ_id` in the stock valuation
layer as it is a prerequisite for being able to use a groupby in the
tree view.
Part of task-3218314
Part-of: odoo/odoo#119381
_should_be_valued should always return a bool.
Currently, when it's False, it returns False. However, when it's True, it returns self.company_id.
After this fix, it returns True instead of self.company_id.
closesodoo/odoo#120182
X-original-commit: 44430635936dd33b291d9d8514cef9b0013507e5
Signed-off-by: Tiffany Chang <tic@odoo.com>
If the category of a product is using manual stock valuation, when changing the product on an invoice line,
the account should not be set to the `property_stock_account_input_categ_id`. It should be the case only if
we use automatic/real-time stock valuation.
opw-3226536
closesodoo/odoo#119717
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
Signed-off-by: Ricardo Gomes Rodrigues (rigr) <rigr@odoo.com>
To reproduce the issue:
1. create a product category with inventory valuation set as Manual
2. create a landed cost product using above category
3. enable anglo saxon accounting in accounting settings
4. create a vendor bill with this product and click save
Error: An error is displayed because of a missing account
When creating the AML, `_compute_account_id` tries to find the
appropriate account. However, for a landed cost, it always use the
the stock accounts, even if they are not defined. We should rather
recycle `/stock_account._compute_account_id` which already handle
such a situation.
OPW-3251714
closesodoo/odoo#119564
X-original-commit: 9416be3cbe630ed693a0285f203e1de9f45acc7a
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
When a product category valuation is set to `real_time`, we use the
stock accounts. However, in the code, to know which account we
should use, we do: "use stock accounts if defined, else use basic
ones" (the best should be "use stock accounts if `real_time`" but
this refactoring task will be done in master). So, here, we need to
ensure that stock accounts are not defined when the valuation is manual.
This is the case when installing `stock_account` module: the
valuations will be set to manual, so we need to force the stock
accounts to `False`. Same when creating a new company, we also need to
ensure that the stock accounts are not defined. This explains the
changes in `_post_load_data`
About changes in `_check_valuation_accouts`, the explanation is in
the method body: the defined values directly depends on the value of
`property_valuation`
Note about test modification: for the tests in `stock_landed_costs`
module, we set the categ to auto so the stock accounts are defined.
Otherwise, when validating the landed costs, it will lead to an error
https://github.com/odoo/odoo/blob/9cd316f038dc95051814ede9474f8f15f7d165df/addons/stock_landed_costs/models/stock_landed_cost.py#L396-L397
OPW-2746384
X-original-commit: 2780c37cfdb8560ac7c725fd27f4fe272f1d3072
Part-of: odoo/odoo#119564
Behaviour before commit:
If the location is a production or inventory location, you can set an
account_id for the valuation. Once this account_id is set, it will still
be there if you change the type of location to a view location for
example. This may
not be the right account_id given the new type of location.
Behaviour after commit:
Check if the location is of a specific type, if it's not inventory or
production, it will take the default valuation account id from the
product category. Otherwise it will take the one set on the location.
OPW-3269584
closesodoo/odoo#119344
X-original-commit: 3f0ea5d0fa5a96eb78e4637781698121434ee069
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
The new backend version of read_group can simplify the
current overrides of read_group. Do it for each of them and
avoid making extra search (done with __domain) when it is possible.
Part-of: odoo/odoo#110737
To reproduce the issue:
1. Create a product:
- Type: Storable
- Category:
- Costing Method: AVCO
2. IN 2 @ 4.63/u
3. IN 5 @ 3.04/u
4. OUT 0.1
5. Repeat step 4 70 time in total, so that the final quantity is 0
6. Open the inventory valuation of the product
Error: the total value is $-0.04 instead of $0.
The compensation of rounding issue is stuck by a check that ensure we don't erase a valuation error.
However, this check can never succeed with small quantities, here is the mathematical proof:
°Current check: rounding_error <= qty * curr_rounding / 2
With:
1) rounding_error >= curr_rounding
2) 0 < qty < 2
3) v1 = rounding_error / curr_rounding
4) v2 = qty / 2
We can be sure that:
5) v1 >= 1 because of 1)
6) v2 < 1 because of 2)
7) v1 > v2 because of 5) and 6)
° rounding_error <= qty * curr_rounding / 2
° rounding_error * curr_rounding <= qty * curr_rounding / 2 * curr_rounding
° rounding_error / curr_rounding <= qty / 2
° v1 <= v2
==>> This contradict 7), hence this check can never be True for qty < 2
To fix this issue, we change the check to:
° rounding_error <= qty * curr_rounding / 2 OR rounding_error <= curr_rounding
Where the 1st part doesn't change, but the second one is true when rounding_error == curr_rounding
closesodoo/odoo#115668
X-original-commit: 7825e0e474bdfedc741a20af0e1ee0ffba9a25fc
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: David <dafr@odoo.com>
## To reproduce:
=> Import 5 units of P1 at $5
=> Import 2 units of P1 at $2
----> Current valuation: Qty 7, Value $37, Std Price $5.29 (rounded)
=> Change standard Price to 7
----> Current valuation: Qty 7, Value $48.97, Std Price $7
## Solution:
To compute the value delta, we don't use the current standard_price (which may be rounded), but the current value_svl.
OPW-3233260
closesodoo/odoo#115574
X-original-commit: 07ad8744a37a3e8d5a665a452f050e0dfacc6917
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: David <dafr@odoo.com>
Kit were not reconcile because the `_stock_account_anglo_saxon_reconcile_valuation`
method try to match `account.move.line` and `stock.move` base on the
product field. However in kit case, the moves are exploded in mutliple
moves containing the kit's components. Due to that the matching is not
made.
To fix this issue we use the `purchase.order.line` that is share between
the `stock.move` and `account.move.line` to retrieve them.
closesodoo/odoo#114987
X-original-commit: f594c837c8a347abb48015d4e9bb0d5109228539
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
-Create 3 products with different costing methods: AVCO, FIFO, Standard
-Create a PO for the 3 items (same quantity and unit price in every line)
-Receive
-Create Vendor Bill
-Check Journal items.
You will notice that the AVCO product is marked as partially matched. Please keep
in mind that this only happens when the 3 costings are used and the unit price
is the same.
It happes because `_get_all_related_aml` returns all the
`account.move.line` for the journal entry and invoice.
But not only for the current product. So if they share the same
price unit then it could reconcile lines for different products.
X-original-commit: 23ccf2c1bde84f03aaaedb206e37a35de701da5e
Part-of: odoo/odoo#114987
Usecase to reproduce:
-2 products setup as Periodic valuation
- Create a PO to buy both products
- Receipt and create the bill
- Modify the price unit on both invoice line to create correction layers
The label on the journal items have the same label relative to only one
of the products. It should keep the same label than before the
confirmation.
closesodoo/odoo#114792
X-original-commit: 226ae25b5f93164f14c1e68ed8bc2ea8a48b4e27
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
First issue: post a credit note
Steps to reproduce:
- enable anglo-saxon accounting and storno
- create a storable product with sale price = 50 and cost = 30
- set costing method FIFO and automated inventory valuation on product category
- create a credit note using this product
- post credit note
Error:
There was a problem with the following move(s):
- Move with id 18
The debit and credit should be negative and only one can be set
Second issue: return a product
In anglo-saxon accounting, returning a product means creating a reverse move.
Reverse move in storno should have a negative debit/credit.
opw-3110934
closesodoo/odoo#114671
X-original-commit: f24a87b1d0bb3a18ef1d2d4cd23fb34bf29d4bfb
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
To reproduce the issue:
1. Create a product:
- Type: Storable
- Category:
- Costing Method: AVCO
2. IN 1000 @ 0.17
3. IN 800 @ 0.23
4. OUT 1000
5. OUT 800
6. Open the inventory valuation of the product
Error: the total value is $-6.00, it should be zero
Once all products received, the standard price is $0.20. Its value
has been rounded because the real value is
`(1000 * .17 + 800 * .23) / 1800 = 0,196666667`
The standard price will create a difference when using the products,
because:
`(1800 * .20 = 360) != (1000 * .17 + 800 * .23 = 354)`
That's the reason why a feature tries to compensate such rounding
errors. So, step 4, when preparing the values of the out-SVL, we
check if there is a rounding error, and we find a difference of $6,
which is correct. However, the difference is above the treshold, so
we will not consider it as a rounding error:
https://github.com/odoo/odoo/blob/3ff51daa93a1d670b8f67f79418d4dd48e94875f/addons/stock_account/models/product.py#L197-L200
Here is the issue: the threshold is based on the outgoing quantity
(1000) while the value difference is based on the whole quantity
(1800). This difference should also be proportional to the outgoing
quantity.
Note: The fix will still not work with a small quantity. The only and
best solution is to change the type of the SVL unit cost into a
float.
OPW-3101374
X-original-commit: 35d8b4c2a223970520961bf8bfc574bb309af090
Part-of: odoo/odoo#114525
Co-authored-by: Adrien Widart (awt) <awt@odoo.com>
Steps to reproduce:
- create two storable products (Great Product - Super Product) - automated avco
- create rfq with the two products - confirm -receive products
- create Bill - set qty of one Great Product to 0 -> save
- create bill for the Great Product - confirm
Issue:
User Error You can only reconcile posted entries
Cause:
`_get_all_related_aml()` fetches all aml related to the `stock_moves` with the product in the bill we want to post.
It retrieves the aml of the bill in which we have put the product quantity to 0 but that it is still in draft.
And we try to reconcile this draft move_line in
https://github.com/odoo/odoo/blob/d0fdc38385f5f259da259d21e9137494e6d7c17d/addons/account/models/account_move_line.py#L2308
Solution:
filter the `product_account_moves(_lines)` so we don't take into account moves that are still in draft
opw-3180209
closesodoo/odoo#114328
X-original-commit: b1a74a1841c05e4e37643e17f6b97dfff11555cd
Signed-off-by: Adrien Widart <awt@odoo.com>
Rewrite the whole chart template mechanism, removing the templates
stored in the database. The new format will mainly use CSV.
Speed up install time
---------------------
* About half of the time of installing a localization for the first time is
taken by creating the template records. This new in code format gets
completely rid of this.
* Creating the template records could often not be done in batch because
of parent/children relations.
* The instanciation of the accounts on the company has been entirely
reworked too, by
- optimizing the order of creation of records to avoid UPDATE queries
- using precomputed fields to avoid UPDATE queries
- updating the translation in batch
- deactivating logging in the chatter
- avoiding access rights checks by checking the rights at the start
Overall, when installing a chart template for the first time, it is 4
times faster because half of the time spent on saving the template in
the database is not done at all anymore, and the instanciation on the
company is more than twice as fast.
Reduce technical debt
---------------------
There is no need to synchronize the templates with the real records
anymore. No need to use hooks to copy the data from one to the other.
It is easier to change a template in a stable version, which can often
be necessary due to legal reasons (i.e. a change of tax rates, reporting
tags,...)
Two modules have been removed:
* `l10n_generic_coa`: since there is nothing left datawise in this
module, it can be integrated in `account` for free. It is just code
and CSV.
* `l10n_multilang`: the fields that this module modified to be
translatable are now always translatable:
- there was an issue when updating modules that deleted all the
translations because the fields were not translatable at some point
during the loading of the registry, then they because translatable
again but lost all translations because of the column type change.
- most devs are not able to understand all the languages needed for
all the localization available. Therefore, english has been added in
the sources in most localization to understand better issues while
debugging.
- no need to call post init hooks anymore, doing the sync with the
templates.
- more: see "Translations" section
Because most of the data is now in CSV, it is also easier for product
owners to edit, audit, modify files themselves, removing one layer
during trivial development processes when only data should be changed.
More flexibility for declaration
--------------------------------
The data declaration can now be done easily in python or CSV.
A nice feature is that you can declare everything at once, even for some
more complex chart of accounts:
* if you have to set default taxes on accounts, would need to
- declare the accounts because accounts are required on the taxes
- declare the taxes
- declare the taxes to put on the accounts
This would lead to scatter information in multiple files. Now,
everything can be declared in the same place and the loading of the
chart of accounts will do the 3 steps automatically.
* if you have a relation of child/parent, you would first need to
declare the parents then the children, and the loading would not be
efficient because done one by one. Now, everything is done in batch
automatically without having to think about it.
It is also easier to update fields on records where there was no field
for that on the templates, like
* setting a restriction for journals on accounts
* setting specific values on the company
* modifying journals and linking them easily by using the xml_id instead
of having to compute it manually
Translations
------------
Some countries have multiple languages (i.e. Belgium uses officially
French, Dutch and German, and the CoA also has an official English
version) and we must support the languages in all these countries.
All these translations are known, and hard coded without using out
translation platform (Transifex). We also like to have the English
version (even if an official one doesn't exist) so that support can be
done more easily in databases using chart templates in other languages
(especially using a non roman alphabet).
Because the translations were not on Transifex for these records, it was
really hard to maintain: the translation templates (`.pot` files) were
not easy to extract as the automatic export would give values mixing
both the CoA and the menuitmes, the fields' strings,... But we don't
want to translate the CoA as we already know the value.
Managing the translations in the `.po` files was also annoying:
- it is easy to forget that the translations need an update too
- it requires a special editor, special terminal commands that everyone
is not familiar with
- it is easy to make mistakes in the source string
The new format is the following: `field@en_US` where `field` is the
translatable field (usually `name`) and `en_US` is the locale code.
This allows to have the whole declaration on one line, everything in one
file. It also makes the process easier when debugging: instead of
searching for the translation in the `.po` files, it directly appears
next to the configuration of the account/tax/... .
Update of the code
------------------
The code can be updated using this script
https://github.com/william-andre/transform_coa
Forward ports can be managed too by stashing/resetting/checkout the new
modules or the changes in the modules updated in the same PR.
task-2687567
Part-of: odoo/odoo#110016
Speedup writing a new inventory valuation method ('manual' or 'real_time')
on a product category with lots of associated products.
The first optimization is in product._compute_value_svl. By
browsing the read_group result's product_ids and computing
the products quantities in batch, getting a product's
qty_available in the for loop becomes much faster as the value
is already in the cache.
The second optimization is in
account_move._compute_invoice_payment_term_id. Currently there
is no explicit value set to move.invoice_payment_term_id if both
if conditions fail. This produces a side-effect
when precomputing the field's value to be used in a create call.
Since there is no value in cache for some, possibly all records being
created, the compute method will be called multiple times, once
for each record whose invoice_payment_term_id = False. This is because
in models._add_precomputed_values, the precomputed values are retrieved
one record at a time in the for record, vals in zip(records, vals_list_todo)
loop. This is fine because upon CacheMiss the record_ids will be expanded
by the _prefetch_ids. But since in the case of both if conditions failure
no value is actually set in the field_cache for the invoice_payment_term_id
field, the compute method will need to be called once by record,
even if self has been expanded. Setting an explicit default value to
invoice_payment_term_id in the compute method fixes this issue.
opw-3146826
closesodoo/odoo#112360
X-original-commit: d67d86d00d5dbf5fc75420ff6df67495b35e0eb0
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
Signed-off-by: Van Delft Aurélien (avd) <avd@odoo.com>
Usecase to reproduce:
- Set product as FIFO and a cost of 10$
- Sell 5 units
- Modify the cost method to average
We expect the value of the stock to remain -50$.
However it went to -150$
It happens because the change of cost method is not supported
with negative quantity of stock. It's not really a huge bug because
it will be reconcile to the real value in the next in and when the
stock will be positive again but at least it gives a proper valuation
of the inventory.
opw-3100717
closesodoo/odoo#112133
X-original-commit: 3993cbeb00f0a61c76151e116a4c90dae112c067
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Steps to reproduce the bug:
- Create a product category “Fifo”:
- set the costing method to Fifo
- Create a storable product “P1”:
- category: All (costing method = standard)
- Update the qty to 10 units
- Go to inventory → Product variant → “P1”
- Change the category from “All” to “Fifo”
- Go to inventory → Reporting → stock valuation
- Add “reaming_qty” field in the list view
Problem:
The empty_stock layer (the layer created to empty the product) has `remaining_qty` of -10 instead of 0 whereas we change from standard to Fifo
The write method of `product.product` is triggered, leading to Product Variant having another category than Product Template when the write method of `product.template` is triggered
opw-3138061
closesodoo/odoo#111911
X-original-commit: f6f5d4a27af5bad42c3c6c11ce681be631f43248
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
To reproduce the issue:
1. On [Settings]>[Users & Companies]>[Users] add a user with:
- admin rights to purchase and accounting, user right to inventory
- admin rights to all three
2. Go to [Purchase], create a RFQ and click Create Bill
3. On the top right corner left of Receipt, Vendor Bills will be shown
4. It is only viewed by user with admin rights to all three apps
Request: Allow Inventory users to view vendor bills as in pre-versions
Applicable versions: 16.0 up to master
opw-3135682
closesodoo/odoo#111564
X-original-commit: bee4d91d030e305ba8c44704a38c4fd8d614997b
Signed-off-by: Adrien Widart <awt@odoo.com>
Signed-off-by: Lee, Hansun (hale) <hale@odoo.com>
Steps to reproduce:
- Increase decimal accuracy of product price (eg: to 4)
- Create a product with fifo automated valuation and price of 280.8475
- Confirm a sale order of that product and Confirm stock picking
- Create a return on the stock picking
Bug:
rounding error on the stock valuation
Fix:
do not round unit price on currency rounding
opw-2988071
closesodoo/odoo#110112
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
To reproduce the issue:
(Need account_accountant,purchase)
1. Setup a product P
- Storable
- Invoicing Policy: Delivered
- Category:
- FIFO + Auto
2. Process a PO with 1 x P at $10
3. Process a PO with 1 x P at $15
4. Create and confirm a SO with 2 x P
5. Process the delivery one by one (backorder)
6. Create one invoice for each delivery
- The COGS of the first one are equal to $10
- The COGS of the first one are equal to $15
7. Reset and repost the first invoice
Error: The COGS are equal to $15 instead of $10
Steps 5: it creates 2 out-SVL (1x$10 and 1x$15). Step 7, we try to get
the anglo saxo price unit. It leads to `_compute_average_price` with
the invoiced qty (1) and the qty to invoice (also 1). In this method,
we iterate on each out-SVL, we first skip the invoiced quantity and
then consume the quantity to invoice. Here is the issue: we will
skip the SVL we should use and keep the one already used. As there
isn't any link between an AML and the SVL it used, we need a new
approach.
OPW-3062069
closesodoo/odoo#110783
X-original-commit: 17438d5befcd6e9f1fc2ec2a54dfcebbc846d251
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
Issues:
1) When the inventory valuation is Manual the stock accounts field of the
product category should be empty and they should be set when the
inventory valuation is Automated.
2) For the moment at installation all the categories have the Manual default
value and the comapy account default values for the stock accounts (not
respecting condition 1)
Solutions:
For issue 1 we add checks on the write and create functions of the product
category model so that after creation/modification the instance respect the
condition
For issue 2 we add at the end of the post_hook script some code to set an
empty stock account property for every product category.
opw-2746384
closesodoo/odoo#110715
X-original-commit: aa744f1172012d3d74c12bb73e06265d6e64c6e1
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Steps to reproduce the bug:
- Create a storable product “P1”:
- Go to product category → set the inventory valuation to
“Automated”
- Create a BoM:
- Add a component with the cost set to 10$
- Add an analytic account
- Create a MO to produce one unit of “P1”:
- Confirm the MO:
- an analytic account line is created with the amount of $10
- Mark as done the MO:
- The amount is updated to $0
Problem:
In the case where the inventory valuation is set to “automated” we use
the analytical distribution since this commit:
https://github.com/odoo/odoo/blob/7e3403068fc3fbc40182b3cfeb80e97a9300e8ff/addons/account/models/account_move_line.py#L2326
but in the case of MO it shouldn't use it
Solution:
If we are in MO, ignore the type of inventory valuation
opw-3081877
opw-3086626
closesodoo/odoo#110478
X-original-commit: af7be17b71fc72d15149c4baabadeacdcf77cc99
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
*:purchase_stock,stock_account
To reproduce the issue:
1. In Settings, enable 'Multi-Step Routes'
2. Create a product category PC:
- Method: FIFO
- Valuation: Auto
3. Create two products P_compo, P_finished
- Both:
- Type: Storable
- Category: PC
- With a positive cost
- P_finished:
- Vendors: a new vendor V
4. Create and confirm a SO with one order line:
- Product: P_finished
- Route: Dropship
5. Confirm the PO and process the dropship
6. Accounting > Accounting > Miscellaneous > Journal Items
Error: There are a lot of lines and most are incorrect
When marking the dropship SM as done, we check how we should
value it:
https://github.com/odoo/odoo/blob/18450973eaf3ca048cdcd2046a8cba5f5c0f98b0/addons/stock_account/models/stock_move.py#L244-L252
Here is one issue: `_is_dropshipped` returns `True`, which is
correct because the source is the subcontractor location and the
destination a customer:
https://github.com/odoo/odoo/blob/8276a9b51b7c5fc0ae6dd557ae88a9c31f1d1962/addons/mrp_subcontracting_dropshipping/models/stock_move.py#L14-L20
However, `_is_out` will return `True` too. To get this value, we
check if the source and destination locations have to be valued:
https://github.com/odoo/odoo/blob/18450973eaf3ca048cdcd2046a8cba5f5c0f98b0/addons/stock_account/models/stock_move.py#L99-L100
Again, since the source location is the subcontractor one (which is
an internal one) and the destination location is the customer one,
we will consider that we have to value this SM. As a result, we will
apply `_create_out_svl` and `_create_dropshipped_svl` on the same SM
(this explains some incorrect AMLs are generated).
Then, there is another issue. In `_create_dropshipped_svl`, we
create an in-SVL and an out-SVL for P_finished. However, when
processing the MO, an in-SVL will also be generated for P_finished.
The issue comes from `_create_dropshipped_svl`: it creates an in-SVL
but the source location is not outside from the company, so it
should not create the incoming layer.
Finally, when creating the SVL in `_create_dropshipped_svl`, we use
the unit price of the SM to define the value of the SVL. This is an
issue: suppose the unit price of the POL is $10 and the costs of
P_compo is $1, the unit price of the SM is then $10 (and so does the
value of the SVL) but the actual value of the delivered P_finished
is $11. Howver, when calling `_action_done` on a SM, we first
process it and only then we will process the MO:
https://github.com/odoo/odoo/blob/829369d3ca0530f1aad0599fbb1598810a928cc3/addons/mrp_subcontracting/models/stock_picking.py#L33-L36
So, in `_create_dropshipped_svl`, we can't know the actual cost of
P_finished. This is the reason why we have to create a compensation
layer once the MO is processed (i.e. in the override from
`mrp_subcontracting_dropshipping`)
Similar issues will happen if we return the
dropshipped/subcontracted product.
OPW-3078499
closesodoo/odoo#110390
X-original-commit: 200aac56771fd1ef759f73b277a6808d96ee5f31
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
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>
Rémy Voet (ryv)