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>
Steps to reproduce the bug:
- log in as admin
- Go to users, edit Michel Admin
- Add “Manage Multiple stock Locations” permission
- Create a purchase order:
- Add any storable product
- confirm PO
- Receive product
Problem:
The "Deliver To" field is misaligned, and the following fields are off
by 1 column as well. Because the “reminder” field is made invisible when
`effective_date` is not false but its label is still visible, so an
empty place is still present in the view
Solution:
If the “reminder” field is invisible, its label should also be hidden
opw-3097481
closesodoo/odoo#107995
X-original-commit: d02d5f93619445f6f29536442378c9bd1f72454a
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Djamel Touati (otd) <otd@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
documentation link for drop shipping feature is missing as the documentation tag was added along with the field rather than the settings tag.
closesodoo/odoo#107192
Signed-off-by: Tiffany Chang <tic@odoo.com>
When confirming a bill with a price diff, if the UoM of the bill
line is not the default UoM of the product, the values will be incorrect
To reproduce the issue:
(Need account_accountant)
1. In Settings, enable 'Units of Measure'
2. Create a product category PC:
- Costing Method: FIFO
- Inventory Valuation: Automated
3. Create a product P
- Type: Storable
- Category: PC
4. Create and confirm a PO with
- 1 Dozen x P at $50
5. Process the receipt R01
6. Create and process the return RT01 of R01
7. Create and process the return RT02 of RT01
8. Create the bill related to PO
9. Set the bill line price to $60
10. Confirm
11. Open the valuation of P
Error: a stock valuation layer has been created because of the price
diff, which is correct, however the value is not the good one: $670
instead of $10 ($60 - $50)
When confirming the bill, we check if there is a price difference.
To do so, we compare the price unit of the bill line with the one of
the incoming layer:
https://github.com/odoo/odoo/blob/d3d41c7679f9068a7b986925b15d0d7670233bfc/addons/stock_account/models/account_move.py#L304
But, currently, the price unit of the bill line is based on the UoM
of the line while the price unit of the layer is based on the
default UoM of the product. We need to convert the PU of the bill line
OPW-3081449
OPW-3062433
OPW-3075917
OPW-3048587
OPW-3078429
OPW-3075627
closesodoo/odoo#107145
X-original-commit: a1906f0b5e22f03937389d47e6ce5a650f9269e6
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
When confirming a bill, if its currency is not the one of the
company, and if there is a price diff, the value of the generated
SVL will be incorrect
To reproduce the issue:
(Need account_accountant)
1. Edit the currency of EUR:
- Rate: 2.0
2. Create a product category PC:
- Costing Method: FIFO
- Inventory Valuation: Automated
3. Create a product P
- Type: Storable
- Category: PC
4. Create and confirm a PO with
- 1 x P at $50
5. Process the receipt R01
6. Create and process the return RT01 of R01
7. Create and process the return RT02 of RT01
8. Create the bill related to PO
9. Edit the bill:
- Currency: EUR
- Price unit: 120
10. Confirm
11. Open the valuation of P
Error: a stock valuation layer has been created because of the price
diff, which is correct, however the value is not the good one: $70
instead of $10 ($60 - $50)
When confirming the bill, we check if there is a price difference.
To do so, we compare the price unit of the bill line with the one of
the incoming layer:
https://github.com/odoo/odoo/blob/d3d41c7679f9068a7b986925b15d0d7670233bfc/addons/stock_account/models/account_move.py#L304
But, currently, the price unit of the bill line is based on currency
of the account move wile the price unit of the layer is based in the
currency of the company.
Related to OPW-3040171
X-original-commit: 86ca91c3684fe5ea5dac1326278b5d4cce0cecda
Part-of: odoo/odoo#107145
When confirming a bill with a price diff, if the user received, returned
and received again the products, some unexpected valuation layers will
be generated
To reproduce the issue:
(Need account_accountant, sale_management)
1. Create a product category PC:
- Costing Method: FIFO
- Inventory Valuation: Automated
2. Create a product P
- Type: Storable
- Category: PC
3. Create and confirm a PO with
- 3 x P at $50
4. Process the receipt R01
5. Create and process the return RT01 of R01
6. Create and process the return RT02 of RT01
7. Create and confirm a SO with
- 1 X P
8. Process the delivery
9. Create the bill related to PO
10. Set the bill line unit price to $60
11. Confirm
12. Open the valuation of P
Error: There are two lines for the price difference, there should be
one line only. Moreover, the value is incorrect: 30 instead of 10 (i.e.
we should generate the price diff layer for the quantities in
stock only)
When confirming the bill, we check if we have to generate some
additional SVL (in case of price diff)
https://github.com/odoo/odoo/blob/d3d41c7679f9068a7b986925b15d0d7670233bfc/addons/stock_account/models/account_move.py#L288-L305
But, we get all ingoing SVL and process them, we don't consider that the
quantity of a SVL might actually be returned and should be ignored.
This is the reason why a SVL is created for the first receipt. This
also explains why the value is incorrect (we use the quantity of the
SVL instead of its remaining quantity)
OPW-3040171
X-original-commit: 18912b05239e6fc5dab26ec4c930f9080882d127
Part-of: odoo/odoo#107145
The aim of this commit is to simplify and standardize the settings archs.
To do this, a small DSL exclusively for the settings was created. This
new DSL introduces 3 tags: `app`, `block` and `setting`.
The `app` tag is used to declare the application on the settings view.
It creates an entry with its logo on the sidebar of the view. It also
acts as delimiter when searching.
```xml
<app string="CRM" name="crm">
...
</app>
```
- `string` : The "display" name of the application.
- `name` : The technical name of the application (the name of the module).
- `logo` *optional* : The relative path to the logo. If not set, the
logo is created using the `name` parameter :
`/{name}/static/description/icon.png`.
The `block` tag is used to declare a group of settings. This group can
have a title and a description/help.
```xml
<block title="Title of group Bar">
...
</block>
```
- `title` *optional* : The title of the block of settings (the old h2),
you can perform research on its text.
- `help` *optional* : The description/help of the block of settings
(the old h3), you can perform research on its text.
The `setting` tag is used to declare the setting itself. The first field
in the setting is used as the main field (optional). This field is
placed on the left panel (if it's a boolean field) or on the top of the
right panel (otherwise). The field is also used to create the setting
label if a `string` is not defined. The `setting` tag can also contain
more elements (e.g. html), all of these elements are rendered in the
right panel.
```xml
<setting string="this is bar">
<field name="bar"/>
...More elements
</setting>
```
- `type` *optional* : By default, a setting is visually separated on two
panels (left and right), and is used to edit a given field. By
defining `type='header'`, a special kind of setting is rendered
instead. This setting is used to modify the scope of the other
settings. For example, on the website application, this setting
is used to indicate to which website the other settings apply.
The header setting is visually represented as a yellow banner on
the top of the screen.
- `string` *optional* : The text used as label of the setting. If it's
not defined, the first field is used as label.
- `title` *optional* : The text used as tooltip.
- `help` *optional* : The help/description of the setting. This text is
displayed just below the setting label (with classname
`text-muted`).
- `company_dependent` *optional* : If this attribute is set to "1" an
icon is displayed next to the setting label to explicit that
this setting is company-specific.
- `documentation` *optional* : If this attribute is set, an icon is
added next to the setting label, this icon is a link to the
documentation. Note that you can use relative or absolute path.
The relative path is relative to
`https://www.odoo.com/documentation/server_version`, so it's not
necessary to hard-code the server version on the arch anymore.
closesodoo/odoo#106425
Task-id: 3081367
Related: odoo/enterprise#34337
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Co-authored-by: "Michael Mattiello (mcm)" <mcm@odoo.com>
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>
With this commit datetime of stock move are correctly converted with the current timezone.
closesodoo/odoo#106886
X-original-commit: 242da76b2763d5add36da6e23d4b1f7e640c72aa
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Before this commit:
1. Create PO with quantity 10, confirm (creates receipt-1)
2. Receive 2 quantities on first receipt (receipt-1), backorder (receipt-1 is 'done', creates receipt-2)
3. Receive 3 quantities on second receipt (receipt-2), backorder (receipt-2 is 'done', creates receipt-3)
4. Change quantity to 5 in PO
5. An exception is created on all receipts (1, 2 and 3)
In the scenario above, receipt-1 and receipt-2 are partial receipts that are set to 'done'.
It is not necessary to create an exception in these receipts when the quantity is changed to less than originally expected in the PO.
Since the system checks that the new quantity has to be equal or greater than the received quantities, the already received quantities cannot be impacted.
After this commit:
The exception is only propagated to the receipts that are not done.
e.g. in the example above, an exception appears only in receipt-3.
task-2648209
resolves#76297closesodoo/odoo#106633
X-original-commit: d6fad232c3dd4a4f7cd54bd255b75314d54ed065
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
First correction: replace call to `read_group` to `_read_group` in order
to avoid useless joints on table product_template and ir_translation
when the grouping key is a Many2One.
Second correction: add an index on workorder's `state` field. The
get_conflicted_workorder_ids() method search for ready workorders that
are in conflict relate to their planning. The state value is searched to
many times to not index it
closesodoo/odoo#106582
Task: 2852423
X-original-commit: b5019eec76845316e554f2dd11a6d8bbf6fea433
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
When returning a dropshipped and subcontracted product to the supplier
location, the received quantity of the PO line will be incorrect
To reproduce the issue:
1. Create two storable products P_compo, P_Finished
2. Create a BoM:
- Product: P_finished
- Type: Subcontracting
- Subcontractors: a subcontractor S
- Components: 1 x P_compo
3. Create and confirm a PO:
- Vendor: S
- Deliver To: Dropship
- Drop Ship Address: a partner P
- Products: 1 x P_finished
4. Validate the receipt
5. Create a return with 1 x P_finished:
- Update SO/PO quantities: True
- Return Location: Partner Locations/Vendors
6. Validate the return
7. Go back to the PO
Error: The qty received is 2, it should be 0
There is currently no code to handle the return of a dropshipped product
OPW-3030895
closesodoo/odoo#105863
X-original-commit: 0a03678889d46dfc39922c0df965c06457f28d79
Signed-off-by: Adrien Widart <awt@odoo.com>
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Steps to reproduce the bug:
- Create a Kit product "Kit 1":
- Add a BOM with a component “C1”
- Add a sales description
- Create another kit product without a sales description "Kit 2":
- Add a BOM with a component "C2"
- Make sure you have a qty of “C1” and "C2"
- Create a SO:
- Add "Kit 1" and "Kit 2"
- Add any other storable product
- Confirm the SO
- Go to the delivery → validate it
- Print the delivery slip
Problem:
The report doesn’t contain the kit product.
Because in the report, the `stock.move.line` are filtered by checking
the name of their move if it has the same name as the product in
the bill of material, but like the `stock.move` has the name
('description') of the `sale.order.line` instead of the product name,
the lines are filtered and not displayed:
https://github.com/odoo/odoo/blob/14.0/addons/mrp/report/report_deliveryslip.xml#L9
The behavior is the same for purchase orders
opw-2960467
closesodoo/odoo#105158
X-original-commit: be25cea0d882bb03a4873821fdb788a0890ba49a
Signed-off-by: Tiffany Chang <tic@odoo.com>
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
Reading only 'id' with `search_read` is equivalent to use `search` but
complexify the result usage. Fix all these bad usages.
Part-of: odoo/odoo#104838
Co-authored-by: Julien Castiaux <juc@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>
Before this commit, when the quantity of a PO line is changed, its unit
price is recomputed, which means it will be set to 0 if there is no
compatible vendor price for the selected partner/product.
It can be annoying because if the price unit was set manually by the
user, this info is lost.
To avoid that, we don't recompute the unit price if the PO line matches
the following conditions:
- The PO line has already a price unit;
- There is actually no vendor price list for the partner (in such case,
we prefer to avoid to stick to a price who doesn't match that list);
- The UoM wasn't changed, because if the UoM was changed, the price
should obviously recomputed (the price unit for 1 unit is not the same
than for 1 dozen).
How to reproduce:
- Install Stock and Purchase modules;
- In purchase settings, enable "Purchase Agreements";
- Create a product and in its vendor price list (in "Purchase" tab), add
a price for Partner A (e.g. 10$);
- Create a PO for Partner B, add a PO line for the created product and
set the `price_unit` higher than the created vendor price (e.g. 15$);
- Confirm the order and go in the "Alternatives" tab;
- Click on "Create Alternative" and select Partner A as the vendor;
- Click on "Compare Product Lines" and choose the line for Partner A;
- Go back in the first created PO (with Partner B as vendor)
-> the PO line's quantity is to 0, which is good, but its unit price
is also set to 0 which is annoying.
Additionnaly, in `_get_stock_move_price_unit`, `float_round` the value
just before it was returned because previously, the rouding was done
before the multiplication by the UoM's factor which can cause some
rounding issue if the rouding is not done after that.
closesodoo/odoo#104206
X-original-commit: f5a24b10cb3a4cf32c6c185df65f3099c8da3ff1
Signed-off-by: Tiffany Chang <tic@odoo.com>
Signed-off-by: Steve Van Essche <svs@odoo.com>
Simplify the tooltips for 'Security Lead Time for Purchase'
and 'Days to Purchase' in the 'Advanced Scheduling' part
of Inventory configuration.
Task : 2985735
closesodoo/odoo#102933
X-original-commit: cdeccd85d96a4be383d271d7219749541c1ee686
Signed-off-by: Arnold Moyaux (arm) <arm@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>
# How to reproduce:
- Delete external ID "purchase_stock.route_warehouse0_buy"
- Try to create a Product
"purchase_stock.route_warehouse0_buy" was meant to be optional. We can only get the id after checking that it exist.
OPW-2972494
closesodoo/odoo#102872
X-original-commit: 1b7b4cdbee07c325753c1b9362414e8309ef8718
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: DavidFesquet <dafr@odoo.com>
When creating a Purchase Order with multi-step reception, the pickings
created by the push rules won't get confirmed as they should be (like in
the sales multi-step flow).
This creates issues further down with auto-batch as created pickings
don't get auto-batched even if the picking type is set to do it.
Task-2971346
X-original-commit: dc517bbe7ffbae8a8774f705c9431dce45c461ba
Part-of: odoo/odoo#102382
A user can not buy a subcontracted product and directly deliver it
(dropship) to another subcontractor. Moreover, in such situation, the
received quantity is not correctly computed.
To reproduce the issue:
(Enable debug mode)
1. In Settings, enable "Storage Locations"
2. Create three products:
- P1:
- Storable
- With a vendor V1
- P2:
- Storable
- With a vendor V2
- P3:
- Consumable
3. Edit V1:
- Customer Location: Physical Locations/Subcontracting Location
4. Create two BoMs:
- Product: P1
- Type: Subcontracting
- Subcontractors: V1
- Components: 1 x P2
- Product: P2
- Type: Subcontracting
- Subcontractors: V2
- Components: 1 x P3
5. Create a PO:
- Vendor: V2
- Deliver To: Dropship
- Drop Ship Address: V1
- Products: 1 x P2
6. Confirm the PO
Error: a Validation Error is raised at `mrp.production` creation because
of a missing field (`picking_type_id`).
In some cases, when getting the values to create the MO, the basic
`_prepare_subcontract_mo_vals` does not return any `picking_type_id`.
That's the reason why an override has been added in
`/mrp_subcontracting_dropshipping` (see [1] for more details). Thanks to
this override, if the usage of the destination location is `customer`,
we know that we are in a "dropship" situation and we manually define the
`picking_type_id`:
https://github.com/odoo/odoo/blob/d73e70f22e47e81e59aff0c9f578aff260447256/addons/mrp_subcontracting_dropshipping/models/stock_picking.py#L15-L17
However, in the above case, the subcontracted stock move starts from a
subcontracted location and also goes to a subcontracted location
(because of step 3). As a result, the if-condition is not respected and
the `picking_type_id` is not defined.
Once this issue is solved, there is a second one: suppose the PO
confirmed. The user validates the transfer. New error: the received
quantity on the PO is not updated. This is because of an incorrect
condition in `/purchase_stock._compute_qty_received`:
https://github.com/odoo/odoo/blob/d0537e32e5aa4b0fe2ad674ab3ec7c42ae1a12f9/addons/purchase_stock/models/purchase.py#L306-L315
Added by [2] and modified by [3], this condition checks that:
- the destination location usage is `internal` (correct, this is a
subcontracting location)
- the source location usage is not `supplier` (correct, this is a
subcontracting location, so it is `internal`)
- the destination location is not part of the warehouse children (here
is the issue: the SM does not have any warehouse, so it gives a false
positive)
So, because of the incorrect third condition, the condition is
respected. And because `to_refund` is `False` (which is correct), we
don't do anything. That's the reason why the received quantity is not
updated.
[1] d73e70f22e47e81e59aff0c9f578aff260447256
[2] e6a1e240f1
[3] fd22fe221026e353aac7414348b029ae7e290b2f
OPW-2922546
closesodoo/odoo#102224
X-original-commit: a51b4158b964a11fa371a9eb8c877c9ec395f412
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: Adrien Widart <awt@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>
The goal of this commit is to get rid of the analytic tags as they were confusing, serving tag purposes as well as distribution on analytic accounts.
Everywhere analytic tags were used as a distribution have been replaced with a new widget that will dispatch distribution on analytic accounts. If there was an analytic account field next to the tags, it has been included in the distribution.
Analytic tags that were used simply as information tags have been removed.
To fill the new widget, there are now 2 kind of rules that will help fill and prefill it.
The first are applicability: previous groups have been removed, and have by replaced by plans. Each account is required to have a plan. These plans define when they are available in the widget: a default applicability per plan and applicability lines that can specify rules following the context of the widget.
The second one are distribution models, that will replace previous default rules but follow the same principles. The accounts (and so the plans) that will be given by the distribution model can override the applicability rules from before.
closesodoo/odoo#98914
Related: odoo/upgrade#3885
Related: odoo/enterprise#30743
Signed-off-by: William André (wan) <wan@odoo.com>
Co-authored-by: Habib (ayh) <ayh@odoo.com>
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>
In some buisness case when the invoice is done before the receipt, the
`stock.valuation.layer` price unit will be taken on the invoice rather
than the `purchase.order.line`
Part-of: odoo/odoo#99411
Be able to define a cost share on kit's components. The purpose, define
a cost repartition closer to the reality.
If the cost share is not define, it will split by the number of lines.
Part-of: odoo/odoo#99411
Invoice a different amount than on the purchase order will not
use the price difference account anymore. Instead it will create
a layer with the difference. It means the stock valuation will be
base on real quantity invoiced rather than the purchase order.
Since the price different account does not exists:
- Invoice correction is only done on `account.move.line` linked to a
`purchase.order.line`. It means that additional lines won't be
corrected and will debit the stock_input instead (that should be empty
manually)
Part-of: odoo/odoo#99411
When using the auto-batch feature for receipt, when creating a purchase,
it wouldn't batch pickings that matched the group-by conditions.
The issue is that the _create_picking() called when validating a
Purchase Order creates the picking, then creates its moves and then
validates them. Doing it this way avoids the trigger for the auto-batch
feature located in picking's action_confirm().
By calling action_confirm() on the created picking, we force the trigger
of the auto-batch, while not confirming the moves a second time since
their state isn't 'draft' anymore.
opw-2961618
closesodoo/odoo#99466
X-original-commit: 7d091ba995d13fa8f692827b33aad0982c2a65fa
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: Quentin Wolfs (quwo) <quwo@odoo.com>
By observing the slowest queries in our servers, we find some indexes
to add (and verify the pertinence of each) :
- Add a index on `sale_id` of `stock_picking` because, it has a one2many inverse highly used.
- Add a index on `product_id` of `purchase_order_line` because, it has a one2many inverse in purchase_stock and there are some search with it (in `_compute_purchased_product_qty`).
- Add a index on `product_id` of `sale_order_line` to improve the `sale.report` view and it is also called by `_compute_sales_count`.
- Add a index `btree_not_null` on `created_purchase_line_id` of `stock.move` because its one2many inverse `move_dest_ids` is highly used.
- `key` on `ir_ui_view`: Backport of https://github.com/odoo/odoo/pull/97478closesodoo/odoo#99130
X-original-commit: da55c8d88b846d9d1841712b6bd96799e2768a5b
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Signed-off-by: Rémy Voet <ryv@odoo.com>
Minor UX updates to forecast report:
- add missing space (between # and unit + before |) also removed
superfluous uoms (only need it at the end now that an equation is
displayed)
- move On Hand Value to under product link (+ variants if they exist)
and make it a link to the valuation report of the product(s) in
question
- add link from Quantity on Hand to the locations (i.e. inventory/quants)
report for the relevant product(s). Note that product template was
added to Search in order to support default searching due to
forecasting report structure
- redo the top right forecast values to be On Hand + Incoming - Outgoing
= Forecasted so we provide more explicit and transparent values.
Additionally, these values are made to not display decimal digits if
all of those digits are 0. Note that forecasted values in table are
untouched (i.e. Forecasted Inventory = Forecasted is unchanged and
Forecasted with Pending still shows in table)
Also did some t-esc => t-out replacement and other small cleanup since
templates were already being edited.
"forecasted report" part of b2b task: 2882539
Part-of: odoo/odoo#97109
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>
This commit aims at removing unuseful help message to:
1/ reduce translators work, to focus on more useful translations
2/ not sending unuseful information in load_views
3/ reduce help message to useful messages, so that we can mark
fields having a tooltip in the future UI.
4/ some cleanup of existing messages too
The main use cases:
- REMOVED: help redundant with the field name, providing no extra info
- MOVED TO COMMENT: technical help messages, that should not be in UX
closesodoo/odoo#97279
Signed-off-by: Fabien Pinckaers <fp@odoo.com>
On the commit 69dcdd4, the order='create_date desc'
was removed and the way of getting the MO for the notification changed. Now, the context is used, it should be written_after instead of written_date.
(The MO created is correct, only the notification is wrong)
OPW-2877457
closesodoo/odoo#96856
X-original-commit: b80287b265a4c01babedcbb58459c35d36a48066
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Task: 2856281
- Remove user_type_id, account.account.type model, internal_type
- Add account_type that is a simple selection field
- Move internal_group and include_initial_balance to account.account
- Because of these changes, type_control_ids on account.journal is also removed
closesodoo/odoo#93212
Related: odoo/documentation#2223
Related: odoo/upgrade#3595
Related: odoo/enterprise#28205
Signed-off-by: Cedric Snauwaert <csn@odoo.com>
The default order of the picking moves generated from a purchase order should be the same order as the purchase order lines.
Steps to reproduce:
- Create a purchase order with several purchase lines.
- Change the order of the purchase lines.
- Confirm the purchase order.
=> The moves of the picking don't maintain same order as set before.
closesodoo/odoo#95582
X-original-commit: c18b2ce767dd5a5b4dbe766b849b56243dffb723
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
In the web client, in a real use case, it's not possible
to write on fields which are invisible,
as it's not possible to write on fields which are readonly.
This is a first step in the goal to change the behavior
of the `groups=` attribute in the back-end views,
to remove them for the view instead of making them invisible.
This is mainly to reduce the diff of the revision that will introduce
the mentioned above behavior change.
As nodes with `groups=` will be removed from the view
when the user doesn't have the group, it's no longer possible
to set a value on a field having a `groups=` the user doesn't have
in the `Form` test class, as the field will no longer be at all in the
view.
However, these unit tests shouldn't have been able to set values
on invisible fields in the first place.
This revision therefore aims to correct the unit tests setting value
on fields which were invisible because the user executing the
test was not part of the required group(s) for these fields
to be visible in the view.
closesodoo/odoo#94337
Related: odoo/enterprise#28936
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
Arnold Moyaux