During configure journals and to set property stock journal
from stock account , will try to create
xmlid to existing records to avoid duplicate journal codes.
but there are some existing code journal for inventory valuation
already exists. so if already journal with `STJ` and with same
company exist then will avoid to create new journal of same code.
```
psycopg2.errors.UniqueViolation: duplicate key value violates unique constraint "account_journal_code_company_uniq"
DETAIL: Key (company_id, code)=(1, STJ) already exists.
```
closesodoo/odoo#128639
X-original-commit: 6d6a6530bc43f289f8a811347e0ddd7053b5651c
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>
before this commit, reference field is not added
in the search view of the stock valuation, which
contains the information like picking name, and
users need to use custom filters to filter
using this field.
after this commit, the reference field will be
added to the search view, and end users can
easily search using this field without using
custom filters.
closesodoo/odoo#121472
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Currently, only stable releases see their translations updated. This has
resulted in master accumulating outdated stuff for years, which can be
confusing for users testing master on runbot.
This one-shot commit resynchronizes master translations based on the
content from 16.0 and removes empty PO files (i.e. no longer containing
translations).
closesodoo/odoo#121629
Related: odoo/enterprise#41171
Signed-off-by: Martin Trigaux (mat) <mat@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>
Description of the issue/feature this PR addresses:
simplification of the credit note wizard
Current behavior before commit:
First users select reverse option (3 radio buttons):
1) refund
2) cancel
3) modify
The reverse action is triggered when the users clicks on the "reverse" button
After commit:
radio button are removed. There is now two buttons that trigger directly the reverse action with the desired option (refund or modify, cancel is not available anymore)
Also, for refund, posting the draft reverse move will also reconcile with reversed move.
task id: 3244377
closesodoo/odoo#117961
Related: odoo/enterprise#40919
Related: odoo/upgrade#4667
Signed-off-by: John Laterre (jol) <jol@odoo.com>
This commit changes the process flow of stock pickings. A new picking will
always be created in immediate transfer mode and 'ready' state. From
their, it can be validated directly or 'reset to draft'. This second action
switch the immediate mode to planned mode and reset the state as draft.
From their the classical workflow is processed
confirm -> (assigned ->) validated
Task: 3256447
Part-of: odoo/odoo#117513
This commit adapts the directional icons to improve the usability and
maintain consistency with the ui icons library.
task-2818586
Part-of: odoo/odoo#116641
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
If there are no default taxes on product or account, or
predictive guess, there should be no default taxes on a new aml.
So the `account_sale_tax_id` (and `account_purchase_tax_id`)
field only concern new products (as specified in the tooltip
of the field).
In Argentina, there is a constraint so all lines should have
a tax. So, we need to add default tax on their demo products.
We also add it to the products in account demo to have taxes
by default on demo invoices for all localizations.
task-3045026
Part-of: odoo/odoo#115222
_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
Have a product with sales tax and automated inventory valuation
In Settings, set "Quick encoding" to 'Customer Invoices'
Create an invoice with the product, save, edit tax amount
Confirm invoice
Issue: tax amount will be reset to the default
This occurs because the account move line create will trigger a
recomputation of the tax values but this will overwrite manually
input from user.
opw-3163314
closesodoo/odoo#117409
X-original-commit: 8b3317e8363c506f9b641904fd6f686de0ad15c1
Signed-off-by: William André (wan) <wan@odoo.com>
Co-authored-by: william-andre <wan@odoo.com>
They dates from < 2027 and are quite outdated. Favour the nl
translation instead.
n_BE is not on Transifex so it was not possible to correct bad
translations.
closesodoo/odoo#115845
X-original-commit: d04c8b7e484db8306d858c891a7a2b11885fdcd9
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
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>
The type fields of actions already defaults to
the model name in the base model definition.
Therefore, specifying `ir.actions.server`, `ir.actions.act_window`
& so on as type is useless (and adds noise since it's the same as
the action model).
closesodoo/odoo#114539
Related: odoo/enterprise#37855
Signed-off-by: Julien Castiaux (juc) <juc@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
- The `picking_type_id` field in the pickings form view is not openable;
- Display the `description` field (optional) in the SVL list view;
- Add the `expiration_date` field (optional) in the quant list views;
- Add a description text for the landed cost;
- Renames field `requisition_id`: "Purchase Agreement" > "Blanket Order"
- In Inventory Adjustment, hides the "Apply All" button is at least one
record is selected;
- In `product_expiry`, renames two views to stick to the XML's coding
guidelines: https://www.odoo.com/documentation/16.0/contributing/development/coding_guidelines.html#xml-ids-and-naming
- For the replenishment:
- Places the field `product_id` as the first option when the user
writes something in the searchbar;
- Renames `route_id`: "Preferred Route" > "Route";
- Renames the button "Automate Orders" into "Automate";
- Set the `route_id` field as "optional=hide" until `mrp_purchase` is
installed (in this case, it will be set as "optional=show") because
in this case, there is at least two routes (Buy and Manufacturing).
task-3076044
Part-of: odoo/odoo#109511
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>
Atul Patel