The linked PR: https://github.com/odoo/odoo/pull/155157/files
Added a default props 'productType' for ProductCatalogOrderLines, the value of this prop wasn't loaded by the backend correctly
resulting in a traceback when in debug mode and trying to open the catalog from sale/fsm
and another traceback when trying to open the catalog from the purchase form
This PR loads the type of the product into the dictionnary corretly
closesodoo/odoo#161541
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
The sale_stock module patches the ProductCatalogKanbanRecord updateQuantity method
to prevent the quantity to go under the delivered quantity of the product
The issue is that we are also using the ProductCatalogKanbanRecord in the industry_fsm_stock module
in which the services product added to the sale order are considered by default but we would like to be
able to dimish their quantity in the catalog (in case of a missclick for exemple)
Since the service product can't be considered delivered in sale modules, the condition in updateQuantity
shouldn't change anything
Task-3689939
closesodoo/odoo#155157
Related: odoo/enterprise#55455
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Currently, when creating a purchase order, if the product has multiple vendor lines (with the vendor selected on the PO), the product description uses information from all the vendor lines; instead of using information from the vendor line that is used for the price.
Steps to reproduce:
-------------------
* Go to the **Purchase** App
* Go to **Products**
* Select any product
* Select the **Purchase** tab
* Add `Vendor Product Name` and `Vendor Product Code` in additional line fields
* Add two vendor lines
* Line 1:
`Vendor`: Vendor1
`Vendor Product Name`: P1
`Vendor Product Code`: A
`Price`: 1
* Line 2: <br>
`Vendor`: Vendor 1
`Vendor Product Name`: P1 bis
`Vendor Product Code`: B
`Price`: 5
* Select **Orders** > **Request for quotation**
* Create a new quotation
* Select Vendor 1, add the product for which we just added the two vendor lines
> **Observation**: The description of the product shows information from both vendor lines added.
Why the fix:
------------
This behavior was introduced when `name_get` was removed to use `dispay_name` instead.
* https://github.com/odoo/odoo/pull/122085/commits/a8b15c7ab5e2d850d0551a6eb4213bb20a30b210
When adding a product to the purchase order, the onchange on `product_id` is called. The onchange calls the function `_product_id_change`, which itself calls `_get_product_purchase_description`.
https://github.com/odoo/odoo/blob/7e9b9494a8d6c4bb8b3800cc0e25fcd3596db75d/addons/purchase/models/purchase.py#L1224https://github.com/odoo/odoo/blob/7e9b9494a8d6c4bb8b3800cc0e25fcd3596db75d/addons/purchase/models/purchase.py#L1401-L1407
The line `name = product_lang.display_name` calls the function `_compute_display_name`.
* We do have a parnter_id in the context as we have selected a vendor on the purchase order.
https://github.com/odoo/odoo/blob/7e9b9494a8d6c4bb8b3800cc0e25fcd3596db75d/addons/product/models/product_product.py#L434
* We don't have a supplierinfo in the context yet but we have multiple supplierinfo with the same partner_id.
https://github.com/odoo/odoo/blob/7e9b9494a8d6c4bb8b3800cc0e25fcd3596db75d/addons/product/models/product_product.py#L466-L467
Here we thus have 2 sellers.
* Ultimately, the display name joins the different display names computer for each seller.
https://github.com/odoo/odoo/blob/7e9b9494a8d6c4bb8b3800cc0e25fcd3596db75d/addons/product/models/product_product.py#L473-L483
Coming back to the line `self.name = self._get_product_purchase_description(product_lang)`, we now have the name of the purchase order line set as the concatenation of display names from the supplierinfo, i.e `'[A] P1, [B] P1 bis'`.
Once the onchange is called, the function `_compute_price_unit_and_date_planned_and_name` is being called.
https://github.com/odoo/odoo/blob/7e9b9494a8d6c4bb8b3800cc0e25fcd3596db75d/addons/purchase/models/purchase.py#L1295
In the current state, we do not meet the if condition. Indeed, the line has a name (`'[A] P1, [B] P1 bis'`) but it isn't in the default_names (`['[A] P1', '[B] P1 bis']`). It somehow corresponds to a setting where the name of the purchase order line was setup by the user.
With this current fix, the call to `_product_id_change` will set the name of the line with the product information from the company; and not the partner. We also need to add this name to the `default_names` in `_compute_price_unit_and_date_planned_and_name` so that the description get recomputed with regards to the seller, if any.
opw-3802182
closesodoo/odoo#160778
X-original-commit: 6974f5303badbc5f5db104270f9492c12a52f220
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: Sarah Bellefroid (sbel) <sbel@odoo.com>
Deleting a partner may take a long time because odoo has to check an
entire table to find few records or no records at all that reference the
partner and set it to null.
So we are adding an index btree not null to speed up the deletion of
partners.
closesodoo/odoo#160184
Task-id: 3759406
Related: odoo/enterprise#59932
Signed-off-by: Pierre Masereel (pim) <pim@odoo.com>
Steps to reproduce:
- Create pricelist with an end date in the past for a stored product
- Click on manual replenishement
- The created PO will have a price of 0
Bug:
if no valid pricelist is found unit price is set to 0
product standard price is a better fallback
opw-3692985
closesodoo/odoo#158650
X-original-commit: ed106e70f908deda819007fc68feaa44074c0472
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Walid Hanniche (waha) <waha@odoo.com>
This change allows for locked purchase orders to be matched with OCR
closesodoo/odoo#157569
Task: 3798080
X-original-commit: 59fe446aee1ee6d634aa286adc261a3c7f547d14
Signed-off-by: Louis Baudoux (lba) <lba@odoo.com>
Signed-off-by: Joris Makauskis (jmak) <jmak@odoo.com>
Currently, when adding a product to a quotation with the catalog, no warning message will appear when adding a poduct that has a warning or blocking message.
Steps to reproduce:
-------------------
* Go to **Sales** app -> Configuration -> Settings
* Enable **Sale Warnings**
* Go to **Products** -> Products
* Create a new product
* Under **Sales** tab:
* For warning, select either warning or blocking message
* Write a message
* Go to **Orders** -> Quotations
* Create a new quotation
* Select the **Catalog** to add products
* Add the newly created product
Why the fix:
------------
The first version of this fix was a python exclusive change. It was a bit hacky; it was raising an error when the product had a blocking warning and sending a message on the bus when the product had a non-blocking warning.
The second version was changing the return value of `_update_order_line_info` to return the price and the warning if any. The warning was shown inside JS with `_updateQuantity`. This change was not good for a stable verion as it was changing the signature of a public method.
This fix automatically changes the data that is loaded to the catalog. It adds the warning message if any and changes the `readOnly` field accordingly.
Warning/blocking messages will be automatically displayed in the catalog, on the product informations. Products with blocking messages will me marked as readonly to avoid being able to add the product to the sale order (this is the original behavior for blocking messages).
Regarding the field `readOnly` and ẁarning`:
* We can't write `res[product.id]['readOnly'] = product.sale_line_warn == "block"' because readOnly is set to True by default if the sale order is cancelled and doing this would overide that value later. See:
https://github.com/odoo/odoo/blob/21c25a7ccd0ba2d6574ddbcfbcf50dbbc03a1e6c/addons/product/models/product_catalog_mixin.py#L97-L99
* We're also sending the warning only if there is one because of this:
```python
<span t-elif="props.readOnly" class="my-2 pt-3 border-top" t-out="props.warning">
You can't edit this product in the catalog.
</span>
```
Because in the case where readOnly is True for another reason than the product having a blocking warning, the initial message will be displyed.
Since the module purchase also uses the warning on products, this fix is extended to include it.
opw-3631511
closesodoo/odoo#149155
Signed-off-by: Valentin Chevalier <vcr@odoo.com>
Co-authored-by: Valentin Chevalier <vcr@odoo.com>
Steps to reproduce:
- Install Accounting and Purchase
- Create a PO with Purchase Representative different from current user
(e.g. Marc Demo)
1) - Mark the product as received
- Create a bill from PO
2) - Go to Accounting
- Create a bill
- Select the PO in Auto-Complete field
- Save the bill
Issue:
The Purchase Representative of the PO is set as Salesperson (hidden field) of the bill.
He should not.
In the second case, by adding the purchase representative as Salesperson of the bill,
he is also added as a follower of the bill and he receives a notification about being
assigned to the bill.
opw-3677713
closesodoo/odoo#154669
X-original-commit: 07cf6c0e320cd719ea5b6531c2c84f55d8627722
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
Signed-off-by: Anh Thao Pham (pta) <pta@odoo.com>
Steps to reproduce:
- Create a new purchase tax and archive it
- Create a new PO
Bug:
the archived tax is still sugested on the PO Line
Fix:
apply same logic as for sales
opw-3701429
closesodoo/odoo#153156
X-original-commit: 79e0c4383fe72b5d04af8a81b57a65044a91d273
Signed-off-by: Quentin Wolfs (quwo) <quwo@odoo.com>
Signed-off-by: Walid Hanniche (waha) <waha@odoo.com>
There are a lot of places in the codebase where insuficcient access to a
company blocks a normal flow and raises AccessError. While this should
normally never happen with the protections from company domain check,
the new multi company branch/parent relationships suffers the most of
this behavior; because a children company sometimes requires an
information from their parent's field (e.g. currency_id)
The correct behavior to do here is to let the children get the required
data just for processing the flow in the compute (behind the scenes).
Even though the children should normally have no access to read/write it
on screen, the backend process should be able to run smoothly without
blocking any flow.
Granting a few temporary sudo() is necessary to ensure the flow runs as
expected on some places.
closesodoo/odoo#151562
Task-id: 3551305
Related: odoo/enterprise#55345
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
Signed-off-by: Yosua Nicolaus (yoni) <yoni@odoo.com>
Steps to reproduce:
- Create a PO with a tax
- Confirm PO and bill it
- Deactivate tax
Issue:
Tax is shown on bill but not on PO
Solution:
Make sure that we display tax even if inactive.
opw-3631087
closesodoo/odoo#148778
X-original-commit: 4e424750eccff168c3cbb1a3f8411b35905717f3
Signed-off-by: Adrien Widart (awt) <awt@odoo.com>
Signed-off-by: Mattis Megevand (mmeg) <mmeg@odoo.com>
Steps to reproduce:
- Install Purchase and Inventory apps
- Go to General Settings > Purchase > Invoicing > Bill Control
- Choose "Ordered quantities" and Save
- Go to Purchase app > Products > Products
- Create a New product
- Set the product type to "Storable product"
- Go to "Purchase" tab > Control Policy
- Notice how the control policy is "On received quantities" although we set it up to be "On Ordered quantities"
Discussion:
- I added a compute method to manage the default **purchase method** value based on the res.config.setting **Bill Control**.
- I kept the behavior of setting the `purchase_method` to **receive** when the product type is **service** based on [task-2897867](https://www.odoo.com/web#id=2897867&cids=1&menu_id=4720&action=4043&model=project.task&view_type=form) which is associated with the commit **479a38466751e7bc31b26e5635b9735b37dde81f** and [PR](https://github.com/odoo/odoo/pull/96548)
opw-3552786
closesodoo/odoo#148585
X-original-commit: b0ea838364f63d25ca79211d8be5cbf332b6bf70
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Ali Hassan Youssef (alhy) <alhy@odoo.com>
Currently, when replenishing a product using a supplier that has a discount, the purchase order created didn't take the discount into account. It was set to zero.
Fix in `purchase` module, test in `purchase_stock` module.
Steps to reproduce:
-------------------
* Go to ´Inventory´ > ´Products´
* Select any product
* Configure the product:
* - Product type: storable
* - Enable ´can be purchased´
* - Under the ´Purchase´ tab, add a vendor with a discount price
* - Save
* Select ´Replenish´
* Select the vendor previously added
* Confirm
* Check the PO created
Why the fix:
------------
After debugging, I discovered that
```python
po_line_values.append(self.env['purchase.order.line']._prepare_purchase_order_line_from_procurement(
procurement.product_id, procurement.product_qty,
procurement.product_uom, procurement.company_id,
procurement.values, po))
```
in `/home/odoo/odoo/addons/purchase_stock/models/stock_rule.py` would loose the discount value.
Discount can be found in `procurement.values.supplier.discount`.
Further investigation revealed that function `_prepare_purchase_order_line(self, product_id, product_qty, product_uom, company_id, supplier, po)` in `/home/odoo/odoo/addons/purchase/models/purchase_order_line.py` would not make use of the discount value.
In this function, we use the discount value from the seller instead of the supplier as the seller is computed in order to use the smallest discounted_price.
opw-3640396
closesodoo/odoo#147555
Signed-off-by: Tiffany Chang (tic) <tic@odoo.com>
Steps to reproduce the issue:
- Have two companies in your database.
- Create a partner:
- Set "receipt_reminder_email" to True for Company 1.
- Set "receipt_reminder_email" to False for Company 2.
- Create a Purchase Order with Company 2.
Problem:
The field "receipt_reminder_email" is a related field, so its value
is False. However, if you switch the current company to "Company 1"
while keeping the Purchase Order in Company 2, the
"receipt_reminder_email" is updated to True.
Solution:
The field should be computed instead. the readonly for this field in not
neccessary anymore so the inverse is not mandoatory.
opw-3593577
closesodoo/odoo#147648
X-original-commit: 2211e08f69eed7af9be20f178f659f6a71fb6ac4
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
Steps to reproduce:
- Activate debug mode
- Install `Purchase` module
- Set user timezone to `Europe/Brussels`
- Create a purchase order and add an order line
- Set `Receipt Date` to any date in the future with time 01:00:00
- Confirm the purchase order
- Click on "Confirm Receipt Date" button
- Check message in the chatter
Issue:
The receipt date is the day before the one set in the purchase order.
(Same issue when sending reminder by mail)
Cause:
`date_planned` is stored in UTC in the database and used as it is in
the message.
Solution:
Convert `date_planned` to the order timezone before sending the
message.
opw-3503928
closesodoo/odoo#147525
X-original-commit: 7407cf441ae271aa6a4e67c351a5d5ca8de30b08
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Nasreddin Boulif (bon) <bon@odoo.com>
The issue:
having 2 invoices/quotations/purchase orders with different customer, each customer has a different language, the 'Unaxed amount' string will get translated into the first language of the first invoice partner.
The fix:
recompute the total when the lang context change
opw-3569173
closesodoo/odoo#146311
X-original-commit: d48a09738bdde4050bc75f82480ff47ddeb8b553
Signed-off-by: Habib Ayob (ayh) <ayh@odoo.com>
Signed-off-by: William André (wan) <wan@odoo.com>
Following #133759 - The code will fail if the purchase_order has NO
date.
This is because
max(
po.date_order.date_order and po.date_order.date(),
fields.Date.today()
)
will try to compare False with a date, resulting in:
closesodoo/odoo#140006
Typeerror: '>' not supported between instances of 'datetime.date' and 'bool'
X-original-commit: 0831f6d0f2763e1ca8966c9a0b6c3186a847e733
Signed-off-by: Tiffany Chang (tic) <tic@odoo.com>
When selecting a purchase order on a vendor bill,
the payment_reference is replaced even it was
manually filled.
Steps:
- Create and confirm a PO
- Create a vendor bill, set the bill ref and
the payment reference (different than bill ref)
- Select PO as purchase_vendor_bill_id
-> payment_reference is replaced by bill ref value
With this commit, we keep the payment_reference
as it is if not empty.
opw-3549673
closesodoo/odoo#141853
X-original-commit: 77a0449938dafdd234ecd5bf469ef3800336ba27
Signed-off-by: Laurent Smet (las) <las@odoo.com>
Signed-off-by: Guillaume Vanleynseele (guva) <guva@odoo.com>
Problem
---------
The compute_is_used function currently parses through a huge amount of
data using the _read_group ORM function. Which causes some performance
issues in large databases.
Objective
---------
Improve performance of the said function.
Solution
---------
Instead of reading the data on whole tables (ex.account_move_line), we
read the relation table between the modules and the taxes. This is done
using SQL queries with the EXISTS statement.
Furthermore, the code logic is modified so that if all the taxes for
which we compute `is_used` have been found, we don't look further in
other modules since doing this cannot add an new relevant information
and actually slows down the computation.
closesodoo/odoo#139497
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
Versions:
---------
- 16.0+
Steps to reproduce:
-------------------
1. install stock & purchase;
2. in Inventory settings, enable product packaging;
3. create a packaging for a product;
4. assign the packaging to the current company;
5. switch to a different company;
6. create a purchase order with the product.
Issue:
------
The packaging that gets selected automatically shouldn't be accessible
to the current company (and isn't in the drop-down). Trying to save
the form will return an access error.
Similar issues arise in `sale`.
Cause:
------
726179af78 and
ccdd113260 updated product packaging
onchange methods to computed methods, changing the environment these
fields exist to a `sudo` one. As a consequence, it includes records that
are normally inaccessible.
Solution:
---------
Use the follwing filter before calling `_find_suitable_packaging`:
```python
lambda p: p.product_id.company_id <= p.company_id <= line.company_id
```
- if `p.product_id.company_id` is set, `p.company_id` has to be set too;
- else `p.company_id` has to be `False` or equal to `line.company_id`.
opw-3457782
closesodoo/odoo#140025
X-original-commit: 05f6e91cd9babd8d65e2526a17439a7d81c65fc9
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Levi Siuzdak <sile@odoo.com>
Add two computed fields, `price_discounted` on `product.supplierinfo`
and `price_unit_discounted` on `purchase.order.line`, to get more
precise price.
For the vendor pricelist, it's useful to get the actual lower price (a
vendor price can be lower than another one but the result can be
different if the discount is take in account).
For the purchase order line, it's useful to get the right price in the
products catalog.
task-3373589
closesodoo/odoo#135502
Related: odoo/upgrade#5223
Related: odoo/enterprise#48375
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
This commit makes two major things:
1. Move the product catalog from `sale` to `product`.
It moves the product catalog's code from `sale` to `product` module in
order to be able to use it in other modules.
A mixin, `product.catalog.mixin`, was created for to make other models
catalog compatible.
2. It enables the product's catalog in `purchase`.
In `purchase`, the catalog differs a little bit from `sale`:
- If Unit of Measure is enable, the UoM for each product will appear in
the catalog;
- If the product purchase's UoM or the purchase order line's UoM is
different than the default product's UoM, the former one will be
displayed (in bold so the user can know it's the UoM to refer);
- When opening the product's catalog from a purchase order, the products
will be filtered by the PO's vendor;
- Some data from the vendor list will be used if appliant: the minimum
quantity and the price;
- If there is at least one product's packaging, a button will be
displayed to increase the qty by the packaging's one. If a packaging
is set on the purchase order line, this one will be used.
task-3373589
Part-of: odoo/odoo#135502
Separates the file `model/purchase.py` into two files:
- `model/purchase_order.py`
- `model/purchase_order_line.py`
Since every model should have their own file, `purchase.order` and
`purchase.order.line` have it now.
Part-of: odoo/odoo#135502
The rational is:
Currently we have 2 columns. One for reservation, the other
for quantity picked.
However in real time, either you follow the reservation and everything
goes well. Otherwise you pick something else. In the case where you
pick somewhere else than reserved, you would like to modify the
reservation to have something similar and free the quantity you
didn't pick and expect the system to not suggest the ones you took.
In other hand, we always want to have the reserve quantity similar to
the done.
On top, having two columns could be confusing for the end user.
The cons:
-The qty_done column could be use during the picking, to
remember if something has been pick or still to pick.
- For some flow (put in pack), it's easier to write a part of the quantity to pack
and still want to reserve the full amount of product.
We goes back and choose a ligther interface over complex feature.
Changes:
Qty done and reserved qty are merged into a single column.
A new checkbox on the move exists to mark it as picked or not
Since the reservation always follow the quantity, it's now possible
to have more reserved quantity than stock. However the system will
never propose it and the inventory showing reserved > quantity should
be a warning.
The system should never modify a move that has been picked. We don't
want to overide the user action.
Regression:
Not able to pick a single stock.move.line
closesodoo/odoo#137864
Related: odoo/enterprise#48709
Related: odoo/upgrade#5310
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Fixes a large number of cases where strings are translated then
formatted, instead of letting `_()` do the formatting internally,
which allows it to recover from incorrect translations (missing,
broken, or extra placeholders).
Also
- removes translation markers entirely when there's nothing to
translate e.g. `_("%s - %s")` is not useful
- fixes a few messes which lead to only partial translatability
(DRY is generally a bad idea when translations are involved, even
more so when you don't make the variable part translatable)
- fixes a few nearby issues noticed at the same time
- replaces a few `"%s"` by `%r`, which should automatically quote
strings relatively appropriately
- fixes translated strings which use `\` to escape a newline (in order
to fill-paragraph): `\` escapes only the newline, if the
continuation string is indented this results in a bunch of spaces
ending in the string to translate, which is pretty garbage for the
translator, using implicit concatenation works much better
Note: some of the updates revert f-string parameters to %, because
babel (2.9) apparently has trouble with f-strings and blows up trying
to extract them.
Not in scope:
Helping translators fix translatable strings e.g. any translation
string with more than one placeholder probably should use keyword
placeholders
- Provides more context / data to the translator to make sense of the
sentence.
- Allows reordering the translated terms, which can be necessary
depending on the sentence and language.
closesodoo/odoo#139314
Related: odoo/enterprise#49311
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Problem
---------
All fields in the tax definition are currently modifiable even after the
tax has been used. This raises some issues in tax reports and make
investigations difficult when things go wrong in tax report.
Objective
---------
Once an account tax has been used:
- Some fields in the account tax should not be modifiable anymore to
avoid tax report issues;
- Other fields should be logged when modified to ease debugging and
investigations.
Solution
---------
1. Add a logger to the tax form to track the modification of some fields
2. Track whether the task is being used in transactions or not. This is
done thanks to a compute field. In order to be flexible, the compute
function uses a hook function that other modules can override to easily
add transactions to computation of the field.
3. Make the fields that should not be modified anymore readonly when the
tax is being used.
4. In order to track the repartition line values, a tracked computed
field that stores the relevant value in a string is used.
Task-3450002
Part-of: odoo/odoo#130403
Several reports don't include product packing info on them. This is
useful for customers to see that what they bought matches what they
expected and for pickers who need to know which product packaging they
should be selecting from stock. Reports this was added to are:
- Sales orders,
- purchase orders (including RFQs),
- picking operations,
- delivery slips.
Note that we purposely exclude backordered moves since they weren't
deemed to be necessary at the time this feature was created.
Also includes light refactoring to remove repeated code for conversion
of product qty to packaging qty and to make it easier to do this
conversion in the future (i.e. can pass product.packaging without
original record that it was assigned to)
Task id 2927379
closesodoo/odoo#96858
Signed-off-by: Steve Van Essche <svs@odoo.com>
To reproduce
============
- create a purchase order and confirm it
- create a Bill, set its Bill date and Accounting date to different dates
to today
- save it, then choose the created PO in autocomplete field
the Accounting day will be changed to today
Problem
=======
when calling the autocomplete, some values will be updated on the record,
where `move_type` is one of them, and updating this field will trigger the
compute of accounting date.
Solution
========
if the value of `move_type` on the record is the same as the one of the update,
it should not be taken into account which will avoid uneeded recompute.
opw-3381530
closesodoo/odoo#136559
X-original-commit: 6abcac2025522e5e023d51c02f14c49044658b70
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Abdelouahab Laaroussi (abla) <abla@odoo.com>
If the currency_id and cost_currency_id is different for a product, the cost in the purchase order is wrong. The purchase order should use cost_currency_id instead of currency_id.
Steps to reproduce on runbot:
-Set the currency of main company as Dollars (USD).
-Choose in runbot the company "My Belgian Company" as its currency is Euro.
- Add the currency rate of today between EUR and USD
- Take a product and edit the cost to 100 EUR - as the cost field is linked with the currency of the company
make sure on the tab purchase there is no information - so the vendor pricelist is not present.
- Go inside the purchase module and start a request for a quotation
leave the currency as EUR
- Select the product to purchase
Current Behavior:
The unit price will be (100*currency rate). If you do the same but take the currency as USD the product unit price on the purchase order line will be 100
Expected Behavior:
The unit price should have been 100 Euros. And when dollar is chosen as currency, the exchange should have been applied.
OPW-3460551
closesodoo/odoo#136298
X-original-commit: f9c66ff20f2e7d8d35b9bc775486bb62abd4c367
Signed-off-by: Tiffany Chang (tic) <tic@odoo.com>
Signed-off-by: Hamza Islam (hisl) <hisl@odoo.com>
In this commit
==============
- Added the discount fields to the vendor pricelist and PO line models,
making them optional and hidden.
- Implemented automatic filling of the discount field on the PO line when
the unit price is sourced from the vendor pricelist.
- Implemented a mechanism to automatically populate the discount field on the
PO line when the unit price is fetched from the vendor pricelist.
- Modified the pricing logic to ensure the discount is applied to the
tax-excluded price.
- PO confirmation process to check if a pricelist already
exists for the vendor. If not, a new pricelist line is created, including the
discount if it is present.
task - 3380306
closesodoo/odoo#126804
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Only duplicate emails used to be checked when sending a mass mail.
However it is possible (e.g. using templates) to send a mass mail
to the same person containing different information.
The existing functions to allow models to specify emails
processed in the past by some other means are kept.
A new check is added in the processing that checks the full contents
of the message, subject and attachment ids.
The strings are not hashed as most situations are:
- Sending the exact same mail to everyone
-> Only need to check against one message
-> Same complexity as hashing
- Sending all different emails
-> Checking inequality of str is usually very fast
For attachments, as we cannot compare them easily.
They are ignored for the purpose of equating emails
whenever there are the same number of attachments
in the email values as there are on the composer.
This is because each email should receive its own copy
of the composer attachments. If they have a different
number of attachments, they were generated dynamically
through reports and we assume they are all different.
We can thus remove the 'document based' information
as it is implicitly infered from this check.
-------------------------
Test utils are also updated for two purposes:
1. Add optional body and attachment_name discriminents
assertMailMail assumed all emails could at least be
differentiated by subject. Our test breaks that
assumption, so we use body and attachment to find the
best-fitting email based on the data passed in.
2. Check email_formatted on recipients
When using assertMailMailWEmails, we first find the
email using the non-formatted email of the recipient.
This does not match assertSentMail which checks against
the raw email_to value, which would often be formatted.
Task-2826811
closesodoo/odoo#99541
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Commit 72a17bafba6e7 force the PO `date_order` to be >= at ` today() to
ensure the select_seller method take the right seller price. This
introduces an error in the MPS module that may need to create PO in the
past.
Instead, this commit patch the call to `_select_seller` to take at least
`today()`
closesodoo/odoo#134217
Opw: 3167094
X-original-commit: a9cbd2a2ae2e21f1ba14379aecd908c44497b8ab
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
These changes are made as a result of simplifying attrs and 'states' in
views. However, they should have remained in a separate commit. When
applying the script making the xml changes (used later for the migration
script), the script checked the definition of the python fields in order
to convert the information into a python expression. Therefore, this
commit is not applied when the script is applied to xml changes.
During this attribute deletion pre-existing errors were found. Part of
the code was using the boolean values of 'states' and another part of
the code was not. The behavior could therefore be different (in cases
where readonly on the field had the same value as the ballan in
'states').
Following the deletion of 'states' and without the application of the
view migration, the js tests (tower) were no longer functional. Tests
using the Form view suffered the same effect. There are few tests that
had to be adapted, including two tests in business accounting (updated
by the accounting team). A test for column_invisible did not work. Test
checking if the test system triggers an error if we try to write on an
invisible field. It turns out that Form was testing on the value of
invisible but not taking into account if the column was invisible. The
test system fix is applied separately because there were a lot of tests
that were incorrect.
Part-of: odoo/odoo#104741
The _xmlid_lookup cache contains the id of the ir.model.data with is
unused, making cache pupulation and usage more complex than needed.
Removing this id in prevision of the next commit
Part-of: odoo/odoo#129029
Allow sharing records between company
* accounts
* taxes
* fiscal positions
* products
* ...and some related models
These records can be read and used in children companies.
This can be used to
* have different branding for different businesses
* allow more complex security rules
* consolidate branches differently
* manage different tax reports with different tax ids in the same
country
task-3371677
closesodoo/odoo#125642
Related: odoo/enterprise#43215
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
Receiving a kit's component will fail in AVCO + multi-uom
To reproduce:
1. Create a product category PC
- Costing Method: AVCO
2. Create two products P_compo, P_kit
- P_kit:
- In Units
- P_compo:
- In L
- Storable
- Category PC
3. Create a BoM
- Product: P_kit
- Type: Kit
- Components: 1 x P_compo
4. Create and confirm a PO with 1 x P_kit
5. Process the receipt
Error: When validating the receipt, a user error is displayed: "The
unit of measure L defined on the order line doesn't belong to the
same category [...]"
When processing the SM, we create the in-SVL. To do so, at some
point, we need the unit price of the SM, and here is where the error
comes from:
https://github.com/odoo/odoo/blob/708c3d063482e365e49a04f633c83e90e6fa4356/addons/purchase_stock/models/stock_move.py#L39
`self.product_id` is P_component, but `line.product_id` is P_kit,
hence the error with the UoM1
And there will be some similar errors with the `if` block, L40 (we
compare some SM quantities and some POL quantities: we are mixing
components and kit)
For now, in case of a kit, we will always use the `else` block (i.e.,
the unit price of the POL). This will be improved in master
OPW-3357685
closesodoo/odoo#128386
X-original-commit: 3a81eb79cad7f25843315e39da421efa2c34aaf1
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Adrien Widart (awt) <awt@odoo.com>
Before the fix, when trying to autocomplete a bill with a PO using India localization, the invoice lines would not get the same currency as the autocompleted PO.
This is because with India localization, the journal_id gets updated at the same time of the currency_id, which recomputes and erases the currency set just before.
I propose to update the currency at the end to avoid all sort of recomputation it could be subject to.
opw-3374634
closesodoo/odoo#127657
X-original-commit: 7f37e523cffbe3d7d98fd7457b30e2fb93f453d5
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Benjamin Boullé (bebo) <bebo@odoo.com>
The previous commit introduced an optimization to reduce the number of
queries and fields fetched when we call `name_search`. But it works much
better when the dependencies of `display_name` contain field names used
in the calculation (on the same record/model).
Then, to improve the performance and the cache coherency, add `depends`
and `depends_context` depending on the custom `_compute_display_name`.
Add only the first level of dependencies (never traverse relational
field) because only these have a positive impact on the previous
optimization and the cost is very low (see `modified`).
About `depends_context`, we don't include `lang` because (when `_` is
used by example) it is unlikely to get the same display_name in the same
request with two different lang.
closesodoo/odoo#122085
Related: odoo/documentation#4639
Related: odoo/enterprise#42599
Related: odoo/upgrade#4780
Signed-off-by: Raphael Collet <rco@odoo.com>
Rationale
=========
Since v8, the `display_name` field is present on all models. By default,
`display_name` uses `name_get` which has pretty much the same purpose
(return record name used by the web client). Gradually, many (backend)
developers (and the ORM: https://github.com/odoo/odoo/commit/6da1c3ac4c036eac289597602976538e243cb939)
started using `display_name` (more convenient than
`record.name_get()[0][1]`) but it still had the `name_get` override.
It becomes more complex than necessary and poeple start to misunderstand
the two (and sometimes override both, leading to inconstiencies between
`display_name`/`name_get`).
To simplify the ORM and the API, we decided to keep only one of them,
the `display_name` field:
- It is much more convenient from a backend point of view
(`record.name_get()[0][1]` vs `record.display_name`)
- It is cached during the same transaction (and invalidated if
its dependencies change)
- It can be overridden like any other compute field (override
`_compute_display_name` with any extra dependencies)
- `name_get` is replaced by `read(['display_name'])`
(API perceptive), which can actually be more efficient
(if `display_name`'s depends are correct, the ORM will only fetch the
fields it needs instead of every prefetchable field)
Changes
=======
- Deprecates `name_get` for the v17 and based the method on
`display_name` (the opposite of before)
- Converts all usage of `name_get`
- Overrides of `name_get` are now overrides of `_compute_display_name`
- For `res.partner`, rename the field store `display_name` into
`complete_name` because `display_name` context-dependent and it makes
no sense to have a compute store that is context-dependent.
- Previously, it was possible to return multiple names for the same
record with `name_get`, but it was tricky and most of the usage of
this `name_get` didn't take this into account. The only example of
this is the `name_get` of `product.product`
(now use `", ".join(<names>)`).
Part-of: odoo/odoo#122085
when the user removes the company_id and add a line in the purchase order
then the issue is generated.
Steps to reproduce:
- Create a new purchase order.
- Remove the company_id in the Purchase order.
- Now add a line in PO. Select a product with the consumable product type.
- Traceback will be generated.
Applying these changes will resolve this issue.
Sentry-4215579151
closesodoo/odoo#124035
X-original-commit: 75edec6f73b70c4b9b86ad67bc838f468c2574b7
Signed-off-by: Tiffany Chang <tic@odoo.com>
AssertionError: convert amount from unknown date
The problem occurred when removing the default value of 'Order Deadline' and
selecting a product before saving the record.
After applying this commit will fix this issue.
sentry-4175826548
closesodoo/odoo#123224
X-original-commit: 0314edf028acf7365804028f0f3ef6123b6ae321
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Failing use case: While having purchase_stock installed, create and confirm a request for quotation, received some products but no bill for it. Now select the PO is the list, click on 'Action > Accrued Expense Entry'. Make sure the wizard will effectively create an accrued expense entry (it should be the case if you have some product received and not billed).
Upon confirmation of the wizard, the system will recompute the received quantity on the original PO, logging notes that pollutes, confuses and spams its followers.
The reason is that we use a new record to compute the difference between the received and billed quantities at a given date in the past, and even if track_qty_received is called on a newid, it will find back the original PO where doing line.order_id.
The solution is to check in the context if we're in such use case before logging, because we know that calling the accrued expense entry wizard aims not to change the received quantity in any wase
closesodoo/odoo#122720
X-original-commit: b31f1ad789e92c84f85654b67e6730e413f0e06b
Signed-off-by: Florian Gilbert (flg) <flg@odoo.com>
qty_received_method is not recomputed if the product type change, and can lead to issues on existing purchases when trying to generate a Vendor Bill.
# HOW TO REPRODUCE:
- Create product P, type: Service, Control Policy: 'On Received Qty'
- Create PO for 1 unit of P (do not confirm)
- Update type of P to Storable
- Confirm PO, Receive Products
=> Qty Received is 0, not able to generate Bill
closesodoo/odoo#122409
X-original-commit: fcc1e8e325e6d9f4782b2f82769e1200b7b9a0c3
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Fesquet David (dafr) <dafr@odoo.com>
Steps to reproduce:
1. Create a bill from document,
2. Fill in PO in auto complete, confirm, check the bills list.
3. The source document is not populated in the list.
What is the current behavior that you observe?
The source document is in the log, but does not show up in the dashboard.
What would be your expected behavior in this case?
The PO should show up in the source document in the list
OPW-3284992
closesodoo/odoo#122280
X-original-commit: e3289decaf95034f0ebba307350d3913a604eb8d
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Bastien (bvdn)