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>
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 `_stock_account_prepare_anglo_saxon_in_lines_vals` method, we
loop the moves' invoice lines but we called `filtered` on it to remove
ineligible lines.
That said, we have a conditional `continue` at the beginning of the loop
precisely for the same reason, which is redundant.
As it's better to filter out inside a loop instead of call `filtered`
(one loop instead of two), this commit removes the call to `filtered`.
closesodoo/odoo#94456
X-original-commit: a0a90fb20410d663d4615e7a055fce18c868116b
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: Steve Van Essche <svs@odoo.com>
1. Activate anglo saxon accounting
2. Create product with automated inventory valuation and standard pricing
3. Set decimal accuracy to 6
4. Set product cost price to 0,01719
5. Create PO for 30.000 items -> price = 0,01782 -> total = 534,6
6. Receive goods -> stock journal entry = 515,7 (based on the cost, ok)
7. Create vendor bill
Price difference is incorrect if you have a tax rate in the vendor bill
`price_unit_val_dif` will be rounded to 0.02
Multiplied by a great quantity the result will be wrong (84.30)
Without using the tax rate the price difference amount is the expected one
This commit partially revert 643d91ef5ebfb29fde142294ced82c470d42c136
to improve the original fix.
opw-2849074
closesodoo/odoo#94346
X-original-commit: 315a18f12f9d67284bbd8b027ca652db17aae9d2
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: Grazioso Andrea (agr) <agr@odoo.com>
This commit adds a search restriction on _compute_qty_received_method which will prevent the received method field from recomputing on orders that have already been finished.
This method is only called on the installation of this module and is used to update order lines of consumable products to use the standard computation of stock moves. In cases where purchase orders were completed ahead of this module's installation, this method effectively undoes all received quantities and resets them to zero. In orders that were already confirmed and billed, this displays the order lines with zero received quantities and no way to functionally change it.
opw-2854810
closesodoo/odoo#94325
X-original-commit: 849a561ebb26e7dca9018c6f81b8492ef21d7a7a
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
When purchase is returned, the product may move to internal location first. If
option `Update quantities on SO/PO` is active, it does decrease the qty.
However, when the option is disabled, it increase the qty instead of doing
nothing.
Fix it by making a proper if-else block structure
STEPS:
- Create a PO, confirm it and receive the product
- On the transfer, make a return to a location that is not a child of your warehouse (PhysicalLocations/W/...), for instance, choose the location Physical Locations/Subcontracting Location
- Untick the "Update quantities on SO/PO" (visible in debug), and validate the return transfer
- Check your initial PO
BEFORE: the received quantities have been updated, even if we asked not to do it
AFTER: the received quantities is not changed
opw-2858390
closesodoo/odoo#93471
X-original-commit: eb16b4ece9766d4fea85d88ad72e25e8ada209ac
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: Ivan Elizaryev (iel) <iel@odoo.com>
Since https://github.com/odoo/odoo/pull/86682, when a user opens
the replenishment view, the Days to Purchase are not taken into
consideration when calculating the forecast of a product.
This was due to the fact that the Days to Purchase are now taken from the
orderpoint and not from the company settings. This is fixed by taking
the company setting if no value from the orderpoint is sent to the
method.
closesodoo/odoo#93252
Task-id: 2871408
X-original-commit: ac1df1949e4523aff65543f1381300fc7de3b4e4
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: npi-odoo <npi@odoo.com>
- Add the concept of 'Days to Prepare MO' in mrp, similar to 'Days to
Purchase' but defined at the product level. Both concepts are merged into
Days to Order at the orderpoint level, taking the value of Days to Purchase
for orderpoints with a buy route and Days to Prepare MO for orderpoint with a
manufacturing route.
- Add the concept of 'Visibility Days' on orderpoints. The idea is to
avoid to create through reordering rules multiple small orders for the
same product on a small time frame but rather to order directly a bigger
quantity. When Visibility Days are defined, the quantity of the orders
created by a RR is not the quantity forecasted at Today + Lead times
(quantity that triggered the order according to the RR), but the
quantity forecasted at Today + Lead Times + Visibility days.
The Visibility Days are different for purchase and manufacturing.
Changing the route of the orderpoint will change its value. They
can be defined at the company level and further fine-tuned on the
orderpoint. In case of change of the parameters at the company level,
only orderpoints without a specific value of Visibility Days will
be changed.
- Alignement between Manufacturing and Purchase Security Lead Time
(previously the Manufacturing Security Lead time didn't impact the
procurement date, instead the manufacturing time was made longer).
closesodoo/odoo#86682
Task-id: 2738838
Pr: https://github.com/odoo/odoo/pull/86682
Related: odoo/upgrade#3415
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
following commit 55398263f9297ab2709e4c4c2a9c6c3ee7f59c8a
Introduce a new param to fix a notification issue. However
we could use the context instead of a new parameter in order
to avoid breaking the customisation.
Linked to PR #88303 discussion
closesodoo/odoo#92353
X-original-commit: 69dcdd410adcefe29bfa4fecd2e7c50fe3465b19
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Steps to reproduce the bug:
- Create a storable product “P1”:
- Standard price: 20$
- Add vendor in the Purchase tab:
- name: Azure Interior
- min qty: 10
- price: $15
- Create a PO:
- Vendor: "Azure Interior"
- Product line: “P1”
Automatically, the Quantity field will automatically get populated as 10 Units
and price:$15 as per the pricelist
- Confirm the PO
A picking will be created containing a stock_move with a price of $15 and a QTY of 10
- Edit the Quantity to 9 Units and save the PO
The price will be updated to $20 on the PO line, but not in the `stock.move`
Problem:
When we update the qty in the PO line, a new move with a quantity of “-1” and
a price of “$20” will be created.
Then, it will be merged with the initial move, but since they are not identical in the price,
we can't merge them, so a new picking is created:
https://github.com/odoo/odoo/blob/dda9700d8236091626cbd78efc0ca4116e1e1acd/addons/stock/models/stock_move.py#L869-L881
Solution:
when the price is updated in a PO line, the price of its linked `stock.move` must also be updated
opw-2825160
closesodoo/odoo#92208
X-original-commit: c8d74a1cb4bfed8226e52e0bc6f243b4e483fc98
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
When clicking order now on a replenishment line (orderpoint) for a manufacture or WH resupply route, it will sometimes show a notification for a purchase order that was created earlier instead of the correct one.
closesodoo/odoo#91404
X-original-commit: 9ca9bcc51fa289ddb0548f81a795755d196e31ca
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Signed-off-by: Tiffany Chang <tic@odoo.com>
In a 2-steps configuration, trigger a reordering rule with the vendor
defined will raise an error
To reproduce the issue:
1. In Settings, enable "Multi-Step Routes"
2. Edit the existing warehouse:
- Incoming Shipments: 2 steps
3. Create a product P:
- Type: Storable
- Add a vendor V
- Routes: Buy
4. Create a reordering rule R for P:
- Trigger: Manual
- Min = Max = 1
5. Open the Replenishment page and edit R:
- Preferred Route: Buy
- Vendor: V
6. Trigger the orderpoint
Error: An Odoo Server Error is displayed "AttributeError:
'product.supplierinfo' object has no attribute 'name'"
When triggering the orderpoint, it leads to
https://github.com/odoo/odoo/blob/c75a1a8ac9eef6c7d7c95b7bbbb22d919b952e26/addons/purchase_stock/models/stock_rule.py#L331
However, since [1], the `name` of a `product.supplierinfo` has been
renamed to `partner_id`
[1] f3fe2d50d9
OPW-2780562
closesodoo/odoo#90597
X-original-commit: bda8b0e610f7ec9b0bcb76de3bb52fb6049f62ff
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
When the user cancels a SO, if there is an associated PO, there won't be
any activity logged on the PO about the SO cancellation.
To reproduce the issue:
1. Unarchive the MTO route
2. Create a product P:
- Type: Storable
- Routes: MTO & Buy
- Add a vendor V
3. Create and confirm a SO with 1 x P
- Note: a PO is generated
4. Cancel the SO
5. Open the PO
Error: There isn't any information about the cancellation of the SO. An
activity should be added to the PO.
Since [1], if the PO is a draft, we no longer log an activity when the
quantity of the related SO is reduced:
https://github.com/odoo/odoo/blob/3bd9b7a77a1e0e05ea479945d5cd8085f6981feb/addons/purchase_stock/models/stock.py#L103-L105
However, when cancelling a SO, we call the activity logger:
https://github.com/odoo/odoo/blob/846ad1f978fe36db892a9902bb4657c2079d1756/addons/sale_stock/models/sale_order.py#L184-L189
So, since the PO is not yet confirmed, we ignore it and do not log any
activity
[1] bda3225c6cc27bb2c2933eda3cc68c6f9708daf3
OPW-2820242
closesodoo/odoo#90553
X-original-commit: de485a39c9ee88aa31f9330a468ad31cc05842bc
Signed-off-by: Steve Van Essche <svs@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
In a multi-company environment, creating a product template will always
try to assign it's route to `route_warehouse0_buy` but this throws an
error if the current company is not the one of the route
Steps to reproduce:
1. Install Inventory and Purchase
2. Go to Settings > Inventory > Warehouse and enable Multi-Step Routes
3. Open Inventory and go to Configuration > Warehouse Management >
Routes
4. Open the 'Buy' route, assign it to one of the company for example 'My
Company (San Fransisco)' and save
5. Go to Products and select an other company for example 'My Company
(Chicago)'
6. Click on `CREATE`
7. An error is thrown, preventing the user from creating new products
Problem:
Function `_get_buy_route` always fetched the same route but this route's
company might have been changed so an error is thrown when trying to
access it from the other company
Solution:
Check if we have access to `route_warehouse0_buy` before using it.
opw-2805154
closesodoo/odoo#90093
X-original-commit: 1a733ae0bfd9f1cb1e90a2cab80af290560c6f12
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Signed-off-by: Guillaume Merlin (megu) <megu@odoo.com>
If the user triggers several orderpoints one by one, some purchase order
lines may be merged while they shouldn't.
To reproduce the issue:
1. In Settings, enable "Storage Locations"
2. Create a product P:
- Type: Storable
- With a vendor V
- Route: Buy
3. Add two reordering rules to P:
- Min=Max=1 at WH/Stock
- Min=Max=2 at WH/Stock/Shelf 1
4. Inventory > Operations > Replenishment, trigger the orderpoints of P
(one by one)
5. Open the generated PO
Error: There is only one line with 3 x P, there should be two lines (1 x
P + 2 x P, one for each orderpoint). If the user confirms the PO and
receives the products, the destination location will be Stock or Shelf 1
(depending on the last orderpoint triggered)
Running the orderpoint leads to `_run_buy`, where we try to find an
existing PO line so we can update it (else we will create a new one):
https://github.com/odoo/odoo/blob/5b34adb51eda978aa9ef1a434ab77257d73b9594/addons/purchase_stock/models/stock_rule.py#L122-L129
Here is the issue: the filter in `_find_candidate` contains an `or True`
that makes a whole condition useless.
Considering [1], the condition on `move_dest_ids` is only relevant when
an orderpoint is defined. Therefore, we can remove the `or True` and
improve the condition
[1] 63fffa0bee
OPW-2720868
closesodoo/odoo#88959
X-original-commit: 0802d4c61d7b47f0b32a36c5bb0ec49a0f425043
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
Steps to reproduce:
• Create Record: Product Category
- Costing Method: Average
- Inventory Valuation: Automated
- Specify a price difference account (may create new account).
- Ensure Stock Interim (Received) account is reconcilable.
• Create Record: Product
- Product Type: Storable
- Cost Price: 1.01
- Product Category: New Product Category
• Create bill with this product, for a quantity of 10.5
-> The is price difference of 0.1
Issue comes from this commit 286ea6b681e9ba77357f91b546052449f6342f20
which doesn't round if there is a discount.
With this commit we isolate the latter case in order to keep the
price unit rounded if there is no discount.
closesodoo/odoo#88734
X-original-commit: 643d91ef5ebfb29fde142294ced82c470d42c136
Signed-off-by: Florian Gilbert <flg@odoo.com>
Add a reception/delivery status on sale orders and purchase orders.
The idea is to have an indication in list view about the situation
of pickings linked to the SO/PO.
Inside the document itself, the quantity delivered decoration are
designed to indicate if everything is correctly deliver or if
it still something to do. (red if the delivery/receipt is late and
incomplete)
Task-2381757
closesodoo/odoo#63356
Signed-off-by: Arnold Moyaux <arm@odoo.com>
There were inconsistencies in the calls to `_render`.
* the view context could contain information that misled developers.
Indeed, the context and value of the view are not supposed to be found
in the rendering. Thus by calling `ir.qweb` with the name of the
template, we ensure that there is no unwanted information and in
addition the cache key is that of the name of the template which saves
a query.
* the context used for rendering was modified by a method on
`ir.ui.view`, except this is not information used by this model. There
is now a `_prepare_environment` method residing on `ir.qweb`. This
method allows to modify the value dictionary as well as the context in
which the rendering will be done. This preparation of the data as well
as my security check is done only once per rendering. This also saves
some queries
* Freeze options for rendering were inconsistent. It could be that
options on which rendering depends were not part of the cache key. Thus,
depending on the user who generated the generation of the rendering
function, there was or was not information in the template. For example
for automatic branding. This is no longer possible, because it is the
context that is used. The options serving as a cache key are only
recorded for information (for the profiling system for example). A
simplification of the `ir.qweb.field` models could be made.
The report rendering and call `ir.qweb` instead of `ir.ui.view`.
Part-of: odoo/odoo#85110
In `account.move` `_stock_account_prepare_anglo_saxon_in_lines_vals`,
the `partner_id` is set two times, following those PR:
- odoo/odoo#75038
- odoo/odoo#84468closesodoo/odoo#86154
X-original-commit: 3db2db30a22b0da968c1c739d53dec40a4cabed8
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Steve Van Essche <svs@odoo.com>
Changes made in #78199 would remove the Purchase Security Lead Time from
any orderpoint as long as the 'purchase_stock' module was installed,
whether the orderpoint was related to purchase or not.
Task-2721378
closesodoo/odoo#85594
X-original-commit: 3bd9b7a77a1e0e05ea479945d5cd8085f6981feb
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Signed-off-by: Quentin Wolfs (quwo) <quwo@odoo.com>
The aim of this commit is to set partner on anglosaxon
aml in order to help our client in their stock
reconciliation process in case it hasn't been done automatically.
Before this commit:
anglosaxon line were created without partner
After this commit:
A partner is set when anglosaxon line are created
closesodoo/odoo#84547
Ticket: 2692308
Community-pr: https://github.com/odoo/odoo/pull/84468
X-original-commit: abfe37fcea5b20f77799d9331d4d011530880669
Signed-off-by: William André (wan) <wan@odoo.com>
Usecase to reproduce:
- Create product 1 with supplier `Vendor` and a delay of 3 days
- Create product 2 with supplier `Vendor` and a delay of 4 days
- Create two procurements with a need for stock at 01-01-2022 (warehouse
1 step)
- Run procurement for product 1
- Run procurement for product 2
The PO contains the two product but the order date is for 3 days before
and not 4. Also the line for product 2 is planned for the 02-01-2022
It happens because the delivery date is computed base on the purchase
order date and the supplier but the procurement is totaly ignore
X-original-commit: aec7fcdb693729f432ae2341c00ef317b65fbcbc
Part-of: odoo/odoo#83430
The possible index names have been renamed "btree", "btree_not_null"
(instead of "not null") and "trigram" (instead of "gin").
Task 2742526
Part-of: odoo/odoo#83274
Three supported types:
- btree (default for index=True)
- btree not null (when >90% of the data are null)
- gin trigram search (for char fields)
Review of indexes on all objects.
closesodoo/odoo#83015
Signed-off-by: Fabien Pinckaers <fp@odoo.com>
You are blocked with an access error when you try to replenish a product with `”Buy”` route if you don't have the settings rights,
because the code tries to read a system parameter.
Solution:
To avoid this error, we need to read it as superuser.
opw-2725702
closesodoo/odoo#82814
X-original-commit: dff238959f46708b68cda4b03f8f6981f7245ee7
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
In automated-AVCO configuration, buying a kit at a higher price than its
cost can create inconsistencies in the accounting.
To reproduce the issue:
(Need account_accountant. Use demo data)
1. Create a product category PC:
- Costing Method: AVCO
- Inventory Valuation: Automated
- Set up the Price Difference Account PDA
2. Create 3 products P_kit, P_compo01, P_compo02
- Type: Storable
- Category: PC
- P_compo01:
- Cost: 10
- P_compo02:
- Cost: 20
3. Create a bill of materials:
- Product: P_kit
- Type: Kit
- Components:
- 1 x P_compo01
- 1 x P_compo02
4. On P_kit's form, "Compute Price from BoM":
- The cost should be $30
5. Create a purchase order PO with one line:
- Product: P_kit
- Quantity: 1
- Unit Price: 100
6. Confirm PO and process the receipt
7. Create and Post the bill
Error: There is an error in the journal items of the bill: the value for
PDA is $85
When posting the bill, for each account move line, the module computes
the stock valuation of the associated product and the price difference.
To do so, it sums the valuation of all related outgoing stock moves and
divides by the quantity to get the value per unit, then it compares with
the unit price used on the PO's line. Here is the issue: in case of a
kit, there is one outgoing move per component while the PO's line is
linked to the kit itself.
Therefore, in the above case, it uses the outgoing moves of P_compo01
and P_compo02, adds up their value ($10 + $20 = $30) and then divides by
the total quantity (one P_compo01 and one P_compo02, thus $30 / 2 =
$15). This is the reason why it considers that the unit value of P_kit
equals $15. Then, since the unit price on the PO's line is $100, it gets
a price difference value equal to $85.
When comparing the unit value of the kit and its unit price, the unit
value should not be divided by the quantity of components ($30 should
not be divided by 2). Moreover, when buying such a kit at $100, the
surplus ($70) should be distributed among each component. However, it is
difficult to define a rule to correctly weight this distribution.
Therefore, this surplus will be considered as a price difference.
OPW-2566546
closesodoo/odoo#82463
X-original-commit: 20888055d4271bf3cf9e7bc3d42150a1f72e4495
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
The stock convention on location name is always to name the destination
`location_dest_id`. It was not the
case on the stock rule model
Task: 2648449
Part-of: odoo/odoo#80434
The constrains on orderpoint location being related to the warehouse view
location was too restrictive especially in a complex subcontracting flow
with dropship.
This commit change the constrains to only be triggered if the two
location to be compared have both a warehouse.
closesodoo/odoo#79593
X-original-commit: 871cd6ad2d986ee1c28804aeeee63a001156154a
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Remove the Purchase Security Lead Time from the computing of the
purchase order's picking deadline to better reflect that the shipment is
actually meant to arrive earlier than date + security lead time.
Also makes sure that receipts and subsequent pickings (multi-step
reception) are planned the earliest possible, not taking the purchase
security lead time into account.
Task-2656397
Part-of: odoo/odoo#79523
Expected behavior : The log note sent when received quantity is updated should take into account the quantity already received.
Current behavior : The log note sent doesn't take into account the quantity already received for a 'stock_moves'. So it always displays `Received Quantity: 0.0 -> quantity in stock` instead of `Received Quantity: quantity already received -> quantity in stock`
Steps to reproduce the error :
- Create a RFQ with few units of a Storable Product (e.g. 5 units)
- Partially validate the receipt and create a backorder (e.g. 3 units)
- Validate the backorder (e.g. 2 units)
Log notes should be :
`Received Quantity: 0.0 -> 3.0`
`Received Quantity: 3.0 -> 5.0`
But are :
`Received Quantity: 0.0 -> 3.0`
`Received Quantity: 0.0 -> 5.0`
The value is always equal to 0.0 because `qty_received_method == 'stock_moves'` so `line.qty_received` is overridden by 0.0 in parent `_compute_qty_received` even though its value is already set to 0.0 (default) or to the quantity already received
opw-2600221
opw-2613116
closesodoo/odoo#78858
X-original-commit: 0c8ea86fb8d706af139cd2d412d01487e5899df6
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Allow the quantity decrease of Sale Order line of a MTO product.
When increasing de quantities, the related pickings, RFQ / PO are
increased as well, but it wasn't the case if decreasing the quantity.
It should allow the cascade of the decrease in the related pickings as
it would work for the increase. Also modifies a related Purchase Order
if it wasn't yet validated (and thus still a RFQ).
merge_moves was modified so it would allow the merge of negative moves
with positive ones, while trying to "deplete" as much quantity as
possible for each mergeable move.
But negative moves don't always have all required properties to be
compared to the positive ones (some keys might be missing, such as
'created_production_id'). That means we will merge strictly the positive
moves at first as it was done before. But then we try to merge them "less
strictly", using less keys to compare.
Let's say we have those moves (and all other relevant keys matches) :
- move_1 : {qty : 5, created_production_id: 1}
- move_2 : {qty : 3, created_production_id: 2}
- move_3 : {qty : -6, created_production_id: False}
move_1 and move_2 cannot be merged as they don't share the same
created_production_id. But to merge move_3, we'll need to merge it into
move_1 and move_2. It will then deplete move_1 and decrease move_2.
Which will leave us with :
- move_1 : {qty : 0, created_production_id: 1}
- move_2 : {qty : 2, created_production_id: 2}
move_3 will be unliked as its purpose is done.
Task-2513592
Part-of: odoo/odoo#78070
Steps to reproduce the bug:
- Create a BOM kit for “product K” with:
- 2 * “product A”
- 1 * “product B”
- Create a PO for 1 unit of “product K” > confirm
- A receipt delivery with 2 units of “product A” and 1 unit of B will be created
- Modify the ordered Qty to 2 units of “Product K”
Problem:
The receipt delivery will not be updated correctly (4 units of product A and 3 of product B)
because the `"_prepare_stock_moves"` function computed the previous quantity wrong based on the moves quantities
since the moves are for products A and B, not product F.(do not take into account the products in kit)
Solution:
For kit products, do not calculate from the `"stock.move"`, calculate the difference between the quantity before and after the change
opw-2645719
closesodoo/odoo#77838
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Instead of using sort + groupby of itertools (which group only
consecutive), use only the groupby of odoo.tools which
decrease the complexity of the code and avoid unmatched keys
between sort keys and groupby keys
task-2648449
Part-of: odoo/odoo#76761
The combination of a RR and a supplier that has a minimum quantity and a
lead time leads to incorrect results
To reproduce the issue:
1. Create a product P:
- Type: Storable
2. Add a reordering rule for P (min: 10, max: 50)
3. Add a vendor to P
- Quantity: 1
- Price: 1
- Delivery Lead Time: 7
4. Run the scheduler
5. Open the generated PO
Error: The order deadline is <today minus 7 days> instead of today. The
receipt date is today instead of <today plus 7 days>
When computing the quantity to order, the method needs the value of
`qty_forecast` (L254 in [1]) The computation of `qty_forecast` leads to
the computation of `lead_days_date`. To do so, it gets the lead days of
the associated stock rule `_get_lead_days`. In this method, a seller is
selected: [2] However, none of the parameter is defined: [3]
In the above case, the seller has a minimum quantity of 1. Therefore,
since this information is not given in [2], the vendor is not selected
and his lead time is therefore not taken into account. So,
`lead_days_date` will be equal to 0 and won't be recomputed. As a
result, the planned delivery date is today. Then, the quantity to order
is computed (L260 in [1]), so later, the module is able to select the
correct seller. However, this one has a lead time of 7 days -> the
generated PO will have the planned date to today and the order deadline
to <today minus 7 days>
Once an orderpoint has its quantity to order defined, its lead time
should be recomputed because it may be different depending to the
selected seller (and thus we should take this quantity into account when
searching for a seller)
[1]
https://github.com/odoo/odoo/blob/59ac8d891de6e20604494d6cfc6fc357a88d226c/addons/stock/models/stock_orderpoint.py#L254-L260
[2]
https://github.com/odoo/odoo/blob/1b03087524080f1a9751b1561cd8891466e72367/addons/purchase_stock/models/stock_rule.py#L153
[3]
https://github.com/odoo/odoo/blob/045c6ad3353bb0849d3f93d3488d8dcd8b8975b0/addons/product/models/product.py#L602
OPW-2614798
closesodoo/odoo#77110
X-original-commit: f2eb1dca99d16d70613c2f724d4b73f273a49ae7
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Signed-off-by: Adrien Widart <adwid@users.noreply.github.com>
The check added in 643e093a4bc9d46973705831697036b56a89b143 was too
strict in case a purchase order was created from an orderpoint
triggering multiple rules. The orderpoint's location could be below
another warehouse that the first rule's location and thus raising the
error.
closesodoo/odoo#77079
X-original-commit: df1f90673fc06f3d535833229d8af3ef6a51dd61
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
Because the "Replenishment" can unlink a lot (thousand of
`stock.warehouse.orderpoint`).
and psql needs to check every Many2one `orderpoint_id` constraint
and without index it takes too much time.
opw-2637321
closesodoo/odoo#76116
X-original-commit: 864d90a064f093bd6ba24d8464ee491a443a320e
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
Signed-off-by: Rémy Voet <ryv-odoo@users.noreply.github.com>
Rounding in purchase order is 'UP' which is causing issue when doing
receipt in a different uom than the purchase. Rounding should be
'HALF-UP'
Added test in purchase and sales to ensure this issue is detected in the
future.
closesodoo/odoo#76006
X-original-commit: 9d3d1949d20834c92449c989299ac8e67f26d05d
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
Divide "Delivery"/"Incoming Shipment" smart button of "Sale"/"Purchase"
order form between normal "Delivery"/"Incoming Shipment" and a
"dropship" picking.
Also clean a little bit technically
task-2486811
Part-of: odoo/odoo#75041
Add a new module to add smart buttons between a subcontracting purchase
order and the ressuply component delivery.
task-2486811
Part-of: odoo/odoo#75041
This allows to solve the following use case:
* we are in March
* a SO created during January shows currently a delivered quantity (timesheet on service or delivered goods on storable products): timesheets/pickings were done in February
* creating the accrued entry for January 31 should display accordingly an amount of 0 by default since everything was done in February
Invoices invoice_dates are also taken into account:
* day 0 : delivered 10
* day 2 : 5 invoiced
* accrued entries for 10 if accrual date = day 1, accrued entries for 5 if accrual date = day 3,
followup of task 2255642
closesodoo/odoo#75886
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
clementmbr