Goal:
* Simplified modifiers to only have one way to define modifiers;
* Remove states attributes on python field;
* Use python expression in view `required`, `readonly`, `invisible`;
* More accurate validation of xml views.
This commit change the syntax to python expression. The next commit
will update/convert all xml views.
Before this commit:
* the `required`, `readonly` and `invisible` attributes can only have
values of `True`, `False`, 1, 0 or a python expression to use the
context;
* the `attrs` attribute define a dict. The key of this dict was
`required`, `readonly` and `invisible` and the values are the domain or
a string representing a domain to be evaluate as python expression.
This python expressions was evaluate by the javascript with view fields
and other contextual values as: context, uid, parent, active_id,
active_ids, active_model, allowed_company_ids, current_company_id.
* the `states` attribute in the view was a comma separated list of the
state. This list was combined with the `invisible` attribute;
* the `invisible` attribute on python field is used as default value;
* the `states` attribute on python field was dictionnary with state as
key and list of tuple. This structure was combined with `readonly` view
attribute.
* After combining, the resulting domains of the different attributes
`required`, `readonly` and `invisible` are evaluated with the values of
the fields. The `invisible` attributes is splitted into two use:
`invisible` and `column_invisible`.
After this commit:
* The attributes `required`, `readonly`, `invisible` and
`column_invisible` define python expression. This python expressions
are evaluate by the javascript with view fields and other contextual
values as: context, uid, parent, active_id, active_ids, active_model,
allowed_company_ids, current_company_id.
The domains can contains contextual value and will be evaluate by the
javascript.
```xml
<field name="field_a" readonly="not context.get('show_a')" attrs="{'readonly': [('field_b', '!=', False), ('field_c', '=', parent.c)]}"/>
<field name="field_b" states="draft"/>
```
will be replaced by
```xml
<field name="field_a" readonly="not context.get('show_a') or field_b and field_c == parent.c"/>
<field name="field_b" invisible="state != 'draft'"/>
```
Some inherited views will be modified differently in order to maintain
the previous behavior:
```xml
<field name="field_a" readonly="not context.get('show_a')" attrs="{'invisible': [('field_b', '!=', False)]}">
```
```xml
<field name="field_a" position="attributes">
<attribute name="attrs">{'readonly': [('field_c', '=', False)], 'invisible': [('field_d', '!=', '3')]}<attribute>
</field>
```
will be replaced by
```xml
<field name="field_a" readonly="not context.get('show_a')" invisible="field_b">
```
```xml
<field name="field_a" position="attributes">
<attribute name="readonly" add="(not field_c)" separator=" or "/>
<attribute name="invisible">field_d != 3<attribute>
</field>
```
Validation:
A stricter control is made on the level of the attributes (modifiers)
and the fields necessary for these. The use of the previous attributes
'attr' and 'states' triggers an error (these no longer exist after the
application of the migration script)
task-2495504
Part-of: odoo/odoo#104741
Prerequisites -->
1) Login with a user with just Inventory/User access rights
2) Product A with purchase policy set to `on ordered quantities`
3) Product category of A set to `AVCO` costing method
Steps -->
1) Create+confirm a PO with product A and create and confirm vendor bill
2) Switch to Inventory/User user
3) Try to validate picking
4) Access right error
This occurs due to the fact that `Inventory/User` does not have access to s`tock.valuation.layer` or `account.move.line`.
Solution -->
Add sudo to the lines where accesses to SVL and invoice lines are made.
opw-3357028
closesodoo/odoo#130929
X-original-commit: 8d2a77d1bdbe8f865d8f7177801786617e10058f
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
Following #127245
It happens because `_should_bypass_reservation` has been removed in 15.0
and only exist on the `stock.move` object and not the `stock.move.line`
anymore
opw-3336131
closesodoo/odoo#129076
X-original-commit: 7e917e8713e246811531f9d7c90395242e544057
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
When a RR updates the qty of a POL, the qty to order of that RR will
be incorrect
To reproduce the issue:
1. Create a product
- Storable
- With a vendor
2. Create a RR:
- Min 0
- Max 0
- Factor 1
3. Confirm a delivery with 1 x P
- It should create a PO
4. Confirm a second delivery with 1 x P
- The POL of the PO should be updated
5. Open the Replenishment page
Error: The qty to order of the product is 1 while it should be 0
`qty_to_order` is a computed field and one of the `depends` is the POL
related to the product. This explains why, after step 3, everything
is ok: the compute is triggered (because of the new POL) and the qty
to order becomes 0. However, step 4, the POL qty is updated -> it
does not concern any `depends` -> the compute is not triggered,
hence the error
OPW-3292297
closesodoo/odoo#128279
X-original-commit: 80521431601323c1eb7c85cafbf08e8ae0adbdd6
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Adrien Widart (awt) <awt@odoo.com>
layer.account_move_id may not be defined on 'manual' valuation.
Use layer.create_date instead which is equal to layer.account_move_id.date.
# HOW TO REPRODUCE:
- Create a product P, storable in AVCO !! MANUAL !!
- Set 'Control Policy' under Purchase to 'Ordered Quantity'
- Create a PO for 10 units of P with for $1 each.
- Create Vendor Bill -> Confirm
- Receive 5 unit of P: Create backorder
- Validate backorder
==>> Traceback
OPW-3383833
closesodoo/odoo#127218
X-original-commit: b1351ee348207283dcdf7118440b31c03f0d0b4b
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>
To reproduce:
1. Create a storable product with ordered quantities policy for purchase and with a category set as FIFO automated
2. Create a purchase order in a different currency and set quantities for partial deliveries
3. Create a partial delivery
4. Fully invoice the purchase order
5. Create the delivery of the complementary units
6. Check the stock valuation layer
The valuation of backorder is wrong.
The value on valuation layer is in company's currency, while the value
on invoice line is in the PO's currency. When create valuation line for
backorder, we didn't convert them to same currency.
opw-3300266
closesodoo/odoo#125206
X-original-commit: c2de679fcba7f153201dde5b3aa989eb3f329910
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: Yuchen Huang (yhu) <yhu@odoo.com>
With this commit:
========================
- Added a new field `forecasted_qty` in replenishment to display the
forecasted qty based on a selected warehouse in the wizard
- Changed the `route_ids`(m2m) field to `route_id`(m2o) so that
we can apply a specific route for the
replenishment instead of the product's default routes
- Reduced the width of all the fields
- Remove the time from the scheduled date and make the unit field not editable.
- Can see vendor information with info icon field when buy is selected
- Hide the Dropship route from the Route
TaskId : 2579425
closesodoo/odoo#96948
Related: odoo/upgrade#3796
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>
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>
After the modification of the credit note wizard the option 'cancel' is not available anymore.
Since there was no test for 'modify' and the 'refund' option was already tested, the tests are modified so that it now tests 'modify' option
task id: 3244377
Part-of: odoo/odoo#117961
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
After uninstalling the stock module on a database which also has the purchase
(and purchase_stock) module installed, the qty_received_method is removed for
purchase order lines handling the reception of the products through the stock
module (qty_received_method = 'stock_moves'). Because of this, a recompute
is triggered on the qty_received, setting it to zero.
This leaves the purchase order in an invalid state (the received quantity did
not change through the uninstallation of the stock module), additionally the
problem cannot be corrected, since the receiving method is not set to manual.
Functionally, the uninstallation shouldn't update the purchase orders, instead
they should be decoupled from the associated stock moves. To this end, an
ondelete handler is added for the stock_moves selection option.
Steps to reproduce:
- Install Purchases app
- Install Inventory app
- Create a purchase order with purchase lines and quantity > 0
- Confirm the purchase order
- Click on receive products
- Click on validate
- Uninstall Inventory app
- Check that the purchase order lines have the received field set to zero and
it is not editable
opw-3006951
closesodoo/odoo#121549
X-original-commit: cedd0603a24aa0c0e6716c2e0f49e89c870eae04
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: De Caluwé Tom (tdc) <tdc@odoo.com>
Co-authored-by: Pedro Manuel Calheiros Lima de Sousa (peso) <peso@odoo.com>
Currently, automatically PO is generated in that PO buyer field is empty.
So in this commit, we added buyer field in partner form view, when rfq is
generated automatically and vendor has a specific buyer then at creation
of rfq, the PO buyer field will be set according to that.
TaskID - 3151213
closesodoo/odoo#113709
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Steps to reproduce the bug:
- Create a storable product “P1”
- Create a purchase order with 3 unit of “P1”
- Confirm the PO and receive the delivery
- Go to inventory > operation > Inventory Adjustments
- Select the “quant” of “P1”:
- quantity = 3
- inventory_quantity = 0
- Click on “Apply”
- Apply the wizard
Problem:
The quantity is updated to 0
When the `_apply_inventory` function is called, a move is created and
validated to ensure that the quantity matches its corresponding
`inventory_quantity`:
https://github.com/odoo/odoo/blob/15.0/addons/stock/models/stock_quant.py#L606-L611
`inventory_diff_quantity` is equal to -3 in this case, since it's the
result of computing `inventory_quantity` - `quantity`, which is (0 - 3).
Since we add a minus sign to `inventory_diff_quantity`, the final result
becomes `3`.
Afterward, we call the `_update_available_quantity` function with a
minus sign as well, so the value becomes -3:
https://github.com/odoo/odoo/blob/e1cea2640fc064a56b0dba4f79e6b8a91a48b4fc/addons/stock/models/stock_move_line.py#L307
As a result, when we add `quant.quantity`, which is 3, the final result
becomes 0 (3 - 3):
https://github.com/odoo/odoo/blob/9d34c72b2c7bc187c5aac771e9e8cbddd7ead5f2/addons/stock/models/stock_quant.py#L635
Solution:
If no inventory_quantity set, ignore the apply of inventory for this
quant.
opw-3268542
closesodoo/odoo#119867
X-original-commit: 4bedeb514652f5f4a9fd8fa0914d07c8ccba3952
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
Steps to reproduce the bug:
- Create a Storable Product “P1”:
- Route: buy
- Reorder Rules: Min 5, Max 0
- Set up a user with only Inventory / User Access Rights
- Using INV User, create a Delivery Order (Delivery 1) so the amount
of Product On Hand is below the Reorder Rule Minimum
--> this will genreate a PO created by Odoo bot
- Using the same INV User, create a new Delivery Order (Delivery 2)
so that the amount purchased on the PO will need to be changed
Problem:
This is done by the user who created the need and not Odoo bot and
as the INV User does not have Access Rights to edit Purchase Order
Lines, an Access Error is triggered.
opw-3255007
closesodoo/odoo#119866
X-original-commit: 32c48924e5045b2cad4f6fda2f0222be0683c22a
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
Steps to reproduce:
1-create a weight unit 'jm' bigger than reference
ratio 2.47541 rounding 0.001
2-create a stored product uom:'jm' / purchase_uom: 'kg'
3-set valuation method to automated (fifo)
4-create a replenishement for 200 (jm)
5-confirm and recieve the products
6-valuation for that stock move is null
Bug:
computations in the stock module are done with rounding method (half-up)
when computing the unit price the recieved quantity is computed with up
rounding which leads to a mismatch
Fix:
applied the same rounding method on all the Steps
opw-3213997
closesodoo/odoo#118251
X-original-commit: c305942958c73414def47ebd299227999841c6ed
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Walid Hanniche (waha) <waha@odoo.com>
Current behaviour:
If you have a confirmed SO, with a `sale.order.line` that has a
`product_packaging_id`, and you write a new `product_packaging_id`,
the "Delivery Order" has 2 lines, 1 move with the old qty and the old
packaging, and another line with the difference of qty and the new packaging.
Same behaviour is present on purchase side.
Expected behaviour:
If you have multiple `stock.move.line` from the same `sale.order.line`,
they should be able to merge, when you changed the `product_packaging_id`.
Ex: If you edit an SOL from 1 pack of 10 to 1 pack of 20, we should have
1 move line with qty 20 in packs of 20, instead of 2 lines, one with qty 10
in packs of 10, and another line with qty 10 in packs of 20.
Same behaviour is expected on purchase side.
Steps to reproduce:
- Install Sales and Inventory
- Activate "Product Packaging" in Settings
- Create a new product with 2 types of packaging
- PackOf10 with quantity of 10
- PackOf20 with quantity of 20
- Create a SO with a new line that product, quantity 10
- Confirm the SO
- Edit the SOL with 1 pack of 20 (`product_uom_qty`=20)
- The "Delivery Order" has 2 lines, instead of 1 with the new packaging
Reason for the problem:
When saving the SO/PO, a new `procurement` is created which will create
a new `stock.move.line` with the new packaging. This will prevent the
lines to merge correctly, because they have different packaging.
Fix:
When writing the `product_packaging_id` on a `sale.order.line`/`purchase.order.line`,
we directly write the package on the `stock.move.line`,
before any `procurements` are created, so the generate move lines
can correctly be merged.
Affected versions:
- 15.0
- saas-15.2
- saas-15.3
- 16.0
- master
opw-3002612
closesodoo/odoo#114866
X-original-commit: 87ed4b2f6c9c36202a1a4f3de143f638cf38d047
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Piryns Victor (pivi) <pivi@odoo.com>
Allow to perform multiple reconciliation at once in order to:
- ...batch the creation of records as much as possible.
Creating an account.partial.reconcile force the orm to search for amls in order to invalidate the reconciliation fields like amount_residual/amount_residual_currency.
- ...reduce the number of flush inside the orm and batch the compute.
Each call to reconcile is looking for the payment's state of invoices before/after the reconciliation.
This step is costly because this will flush all the reconciliation data and then call the computes to get the fresh value of payment_state.
- ...modify more easily the way the lines are matched together.
Before this commit, the lines were split into two batches sorted by some criteria including the currency: debit and credit.
Then, we were matching them together sequentially.
Now, we make the same things except we do that first for each batch of amls sharing the same currency in order to reduce the number of cross-currencies reconciliation.
- ...allow the orm to prefetch all the partials in the reconciliation chain all at once.
The full reconcile needs to be creating on the full reconciliation graph starting on the current amls so we need to travel the matched_debit_ids/matched_credit_ids in order to find all the involved amls.
Fetching all this data at once is also reducing the number of queries made by the orm.
Let's take an example:
Suppose 10 amls: a1, a2, ..., a10
Suppose 10 amls: b1, b2, ..., b10
You want to reconcile respectively a1 with b1, ... , a10 with b10.
Before this commit, each reconciliation was done as follow:
- Check the payment_state of invoice (on 2 amls)
- Create a partial reconcile (single record)
- Create a full reconcile (single record)
- Compute the reconciliation data to compute payment_state (on 2 amls)
All of that, 10 times sequentially.
With the new '_reconcile_plan' method, we are able to give a list of recordset [a1 + b1, ..., a10 + b10]:
- Check the payment_state of invoice (on 20 amls)
- Create a partial reconcile (10 records)
- Create a full reconcile (10 records)
- Compute the reconciliation data to compute payment_state (on 20 amls)
For a reconciliation using 2000 records (a1, ..., a1000 & b1, ..., b1000), the time to reconcile it was about +-34 seconds. Now, it's about +- 3 seconds.
closesodoo/odoo#113680
Related: odoo/enterprise#37543
Signed-off-by: Brice Bartoletti (bib) <bib@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>
To reproduce the issue:
1. In Settings:
- Days to Purchase: 10
2. Create two products P01, P02:
- Storable
- With the same seller
- Delivery Lead Time: 1.0
3. On replenishment page, create a new line:
- Product: P01
- Min Qty: 1.0
4. Order once
- a RfQ is created and the order deadline is in ten days
5. Time travel to the next day
6. Repeat steps 3-4 with P02
Error: a second RfQ has been generated. However, as the first one is
still in draft state, the POL of P02 should be added to that first RfQ
When processing the orderpoint of P02, at some point, we try to find
an existing RfQ with its order deadline equal to `today + 10 days`.
Since we are the next day (step 5), the order deadline of the first
RfQ is `today + 9 days`, so we don't find it.
OPW-3047931
closesodoo/odoo#113982
X-original-commit: 8bf7f9038915be520488b2602c20929ca115a033
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
Steps to reproduce the bug:
- Enable “Storage location” option
- Create a storable product “P1”
- Create a putaway rule:
- When in: WH/Stock
- Store to: WH/Stock/shelf1
- product: P1
- Go to operation types -> “Receipts orders”
- Enable “Show Detailed operations” and
“Pre-fill detailed operations”
- Create a purchase order:
- Add 2unit of “P1”
- Confirm the PO
- Go to the receipt:
- the destination location is correctly set “WH/stock/shelf1”
- set the qty done to 1
- validate the delivery and create a back order
Problem:
The destination location is “WH/Stock” instead of “WH/stock/shelf1”
because the ```_apply_putaway_strategy``` function is not called on
the ```stock.move.line``` when there is no package
opw-3162934
closesodoo/odoo#112400
X-original-commit: b4c83ab2b202702e096c775ae73f4646ba93eae4
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
Refactoring of report_stock_forecasted to owl
Since it wasn't really a report (no print action),
it changed from a report to a client action.
Task: 2885757
See Upgrade : odoo/upgrade#3926
See Enterprise : odoo/enterprise#32116closesodoo/odoo#101247
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Have a product P configured with:
* Product Type: Storable Product
* Product category:
* costing method: standard
* Inventory Valuation Automated
* Price Difference Account: "500000 Cost of Goods Sold"
* Cost $100
Activate Multicurrency:
* USD main currency, CZK foreign currency
* On CZK set the rates
* date1, Unit per USD: 30
* date2, Unit per USD: 25 (date2 > date1)
* date3, Unit per USD: 26 (date3 > date2)
Create a purchase order:
* Date: date2
* Currency: CZK
* Order line:
* Product P
* Quantity 10
* Unit price 3000
Confirm, receive product on date2 (svl needs to be in date2)
Create the vendor bill with:
* Bill date: date 1
* Accounting date: date 3
Confirm the bill
Issue
Check the bill journal items. Price difference account is debited with 4000 czk.
This amount is not correct.
The valuation layer price unit is 100$
At the receipt date the price unit should be 2500czk
The price unit difference 3000-2500 = 500czk
Price difference 500*10 = 5000czk
The issue occur because the price difference unit is converted at bill
accounting date, resulting in 4000czk
opw-3063809
closesodoo/odoo#111199
X-original-commit: bbc0b003f6ff08a50196e07b66083ee7e8896150
Signed-off-by: William Henrotin (whe) <whe@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:
- Setup product (
cost 10$
Storeable Product
Standard Price Accounting
automated valuation
add account for price difference
)
- Purchase product in foreign currency (set a different price)
- Receive the product
- Create and validate Bill
Bug:
The reception JE is for the cost amount set on the product ($10)
debit and credit value are correct but the amount in currency
is wrong (purchase cost)
After creating the bill the Journal items are not correctly matched
since reconciliation is done on currency amount in the case fo foreign
currency transaction
Fix:
Set the correct amount (cost configured on product page)
in currency amount if costing method is standard
opw-2822366
closesodoo/odoo#110628
X-original-commit: 9f5025d99ec490eb2a45b9dbf1a8a43e8fc3162b
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Walid Hanniche (waha) <waha@odoo.com>
Steps to reproduce:
. Change the decimal accuracy of the product price to 6
. Create a storable product and set the Vendor Tax
. Create a purchase order with that item.
. Set the unit price to have 6 decimal places. E.g: 9.406250
. Change the demand quantities to 10
. Confirm the purchase order.
. Edit the purchase order and change the demand quantities to 7 (<10)
. When you save, a new return order will be created
Bug:
Merging the two stock moves fail because the unit price is different
and the unit price is different because in the case of taxes we recompute
the unit price from untaxed amount which is rounded using the currency price_precision
Fix:
removed the unit_price from the keys used in matching which require an
exact equality and added a comparaison on the lowest precision
opw-3011342
closesodoo/odoo#110206
X-original-commit: f9ee1a22eb94e7ffcefd0023fc89150f8de73006
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Walid Hanniche (waha) <waha@odoo.com>
The vendor delay report only works with basic use cases. Here are
the issues:
- For each SM, we sum up the done qty of all SMLs without
considering the UoMs
- When grouping several lines (for instance, by partner and product),
we sum up the quantities of each line but their UoM can be different
- When grouping several lines, we sum the `qty_total` which are the
quantity of the related POL. This is an issue: suppose a POL with
a quantity Q and suppose there are two SM (backorder), if we group
by product, we will have a total quantity of 2Q, which is
incorrect (and so will be the delivery rate)
To reproduce the issues: See the tests added by this commit.
Note: the last test (`test_vendor_delay_report_without_backorder`)
was not failing before this commit. It is added to simply improve
the tests
OPW-3065065
closesodoo/odoo#109471
X-original-commit: c2e351534b9627b6844effba9943b09d4b0b93f3
Signed-off-by: Arnold Moyaux (arm) <arm@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 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>
Gorash