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>
In module mail, invalidating 'message_ids' on a mail thread also
invalidates its inverse field 'res_id' on messages. If you haven't
flushed it before, your cache will be inconsistent, as shown by the test
/mail:TestMailgateway.test_message_process_bounce_records_channel.
In module purchase_stock, add depends on report.stock.quantity. This
ensures that when the model is queried after changes in other models,
the data on which the SQL view depends is flushed to the database before
querying that model's table.
closesodoo/odoo#66938
Related: odoo/enterprise#16722
Signed-off-by: Raphael Collet <rco@odoo.com>
Co-authored-by: Vincent Schippefilt <vsc@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>
Updating the scheduled date of a delivery doesn't update the quantity to
order of an orderpoint
To reproduce the issue:
(Need purchase)
1. Create a storable product P with a seller
2. Create and confirm a planned delivery D with 1 x P
3. Open the replenishment page
- There should be a line for P (Forecast: -1, To Order: 1)
4. Edit D and postpone the scheduled date
5. Go back to replenishment page
Error: The line is still present, its forecast qty is correct (0) but
the quantity to order is still 1 (instead of 0)
`qty_to_order` is a stored field, so when loading the replenishment
page, its compute method is not called. Moreover, even though
`qty_to_order` depends on `qty_forecast` and the compute method of
`qty_forecast` is called, it still won't trigger the compute:
when setting the value of `qty_forecast` from its compute method, it
will lead to:
https://github.com/odoo/odoo/blob/b54f78de307543efcea934206806f361eaac811a/odoo/fields.py#L1106-L1109
So, as shown and explained, we bypass the `write` of `BaseModel` and
skip the business logic and the recomputations
The compute of `qty_to_order` should actually be triggered earlier: when
we edit the scheduled date (step 4). That's the reason why this commit
adds a dependency to the compute of `qty_forecast`: it makes more sense
and becomes an implicit dependency of `qty_to_order` -> update the
scheduled date will trigger the compute of `qty_to_order`
OPW-2868167
closesodoo/odoo#94400
X-original-commit: 791b68fc02cbc4dc5b376e5fc5d37e725f88d0dc
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Adrien Widart <awt@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>
Instead of having to repeatedly manually call `onchange_quantity` at
different points in the code, it is better to have it be computed
instead.
- Logic is left unchanged,
- onchange calls from other methods are removed, and
- tests are adjusted to properly handle compute. I.e. remove
'date_planned': datetime.today().strftime(DEFAULT_SERVER_DATETIME_FORMAT)
from when PO lines are created since this sometimes resulted in
inconsistent date_planned values for PO line and the PO date_order
(by 1 sec), which could lead to inconsistently created 'date_deadline'
values for stock_moves' created by PO line qty changes. Issue
previously didn't exist because onchange was not always called.
Part of Task: 2695116 (to avoid adding more onchange calls for new
feature)
Part-of: odoo/odoo#87656
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>
This commit contains the following:
1) Added sudo to product record when adding supplier info during PO confirm, so that
supplier info is created regardless of who is confirming the PO.
2) the test test_multicompany_partner_bank was removed since it was creating two
res partner banks with the same partner and setting company_id to two seperate companies
while currently the company_id is related to the company partner thus this can no longer
happen.
3) test_message_qty_already_received was changed to not set the company_id explicitly as
it caused unexpected cache miss in the runbot.
task : 2764771
Part-of: odoo/odoo#91640
- 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>
Remove most values uselessly specified because giving the same value as
the default one (see _DEFAULT_MANIFEST in odoo/modules/module.py)
* auto_install is Falsy by default
* author is Odoo SA by default
* summary & description are empty strings by default
* application is False by default
* test, demo, depends and data are empty lists by default
This will reduce noise/inconsistencies between manifests specifications,
simplify analysis of manifests content, ...
closesodoo/odoo#90209
Related: odoo/enterprise#26807
Signed-off-by: Victor Feyens (vfe) <vfe@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>
Have a purchase tax with cash basis payment enabled
Have a product with said tax
Create a bill with the product, save and confirm
Register a payment
Check CABA entries
There should be 4 entries, but only 2 have been generated
opw-2782561
closesodoo/odoo#89101
X-original-commit: d8d255ec68ab4f220da51fb2be7292dcc74d5783
Signed-off-by: Olivier Colson <oco@odoo.com>
Signed-off-by: Grazioso Andrea (agr) <agr@odoo.com>
Co-authored-by: oco-odoo <oco@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>
* Previously, when reconciling journal items in multi-currencies, the exchange difference entry was created only on the full reconciliation. It will now be created directly at each partial to ensure the ratio between amount_residual_currency and amount_residual is always kept identical.
* Also when reconciling two lines, one with a foreign currency and one expressed in company currency, the reconciliation is now made based on the foreign currency.
==== RATIONALE ====
This patch allows to fix the following use cases (among others)
1) When everything is expressed in foreign currency, the reconciliation is made in that currency:
Suppose EUR is the foreign currency and USD is the company currency. Reconciling:
L1: 120 EUR 60 USD (rate 2:1)
L2: 240 EUR 80 USD (rate 3:1)
..leads to a partial of 120 EUR and min(80, 60) = 60 USD
After the reconciliation, L1 is fully matched but L2 is still open with 120 EUR but only 20 USD.
This is the first problem is the current reconciliation because L2 is supposed to have a rate 3:1 so the residual amount should be 120 / 3 = 40 USD.
Since the rate is no longer consistent on L2, the user will probably close the reconciliation by using another line in EUR or will close manually the reconciliation with 20 USD but without any additional exchange difference journal items explaining where this unconsistency comes from.
2) When the current lines are mixing multiple currencies, the reconciliation is made using the company's currency.
In some countries like Mexico, Ethiopia or Costa Rica, the customer is free to pay an invoice using the company's currency instead of the foreign one.
So, suppose USD is the foreign currency and MXN is the company currency.
The invoice is expressed by:
L1: 120 USD 60 MXN (rate 2:1)
If the customer is paying at a date in which the rate is 3:1, he is free to pay
either L2: 120 USD 40 MXN (rate 3:1), either L2: 40 MXN.
In the second case, he is expecting the invoice to be fully paid because its paiement is equivalent to 120 USD at the payment date.
In Odoo, the second case led to an open balance of 20 MXN and the invoice was not completely paid.
Even this situation could be easily fixed by a manual write-off, this makes the Mexican payment EDI very complicated to fullfil correctly because the government is expecting a complete matching between the invoice and the payment.
When the customer is paying multiple invoices or the invoices are paid using multiple payments, the currently generated mexican EDI file in Odoo was wrong.
==== REFERENCES ====
Original idea suggested by hbto@vauxoo.com. Thanks for the contribution and patience of the many persons having, at some point, helped on that.
github issue: https://github.com/odoo/odoo/issues/37469closesodoo/odoo#84201
Task: 2669371
Related: odoo/enterprise#24268
Signed-off-by: Quentin De Paoli <qdp@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
When a PO is in the "To Approve" state, it disappears from the
forecasted report
To reproduce the issue:
1. In Settings, enable "Purchase Order Approval" with a minimum amount
equal to 0
2. Create a storable product P
3. With Marc Demo:
- Create a PO with 50 x P
- Consult the forecasted report of P: there are 50 x P "Forecasted +
Pending"
- Confirm the PO (its state becomes "To Approve")
- Consult the forecasted report of P
Error: The 50 x P disappeared: 0 On Hand, 0 Forecasted, 0 Forecasted +
Pending. We should still see 50 Forecasted + Pending
OPW-2774586
closesodoo/odoo#86476
X-original-commit: c66fc2f3bfd069642fc9ed61ff322a136974a65c
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
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>
To reproduce the issue:
1. In Settings, enable "Units of Measure"
2. Create a product P:
- Type: Storable
- Unit of Measure: Units
- Purchase UoM: Dozens
3. Create a PO with 1 (Dozens) x P
4. Open the Forecasted Report of P
Error: The value of "Requests for quotation" is 144, it should be 12.
The quantity has been converted twice.
OPW-2744195
closesodoo/odoo#84091
X-original-commit: 524a1c597fd409a488bb6af37aca8248727691c1
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Adrien Widart <awt@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>
clementmbr