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>
When we use the `|` (or) version of this rule the ORM generates two
sub-queries when checking the company. This causes sub-optimal and in
some cases really bad planning for the queries and thus PG takes hours
to complete them.
Example (formatted):
```sql
SELECT "mrp_routing_workcenter".id
FROM "mrp_routing_workcenter"
LEFT JOIN "mrp_bom" AS "mrp_routing_workcenter__bom_id"
ON "mrp_routing_workcenter"."bom_id" = "mrp_routing_workcenter__bom_id"."id"
WHERE "mrp_routing_workcenter"."workcenter_id" in (1)
AND ( ("mrp_routing_workcenter"."bom_id" in (
SELECT "mrp_bom".id
FROM "mrp_bom"
WHERE ("mrp_bom"."company_id" in (1))
)
)
OR ("mrp_routing_workcenter"."bom_id" in (
SELECT "mrp_bom".id
FROM "mrp_bom"
WHERE "mrp_bom"."company_id" IS NULL
)
)
)
ORDER BY "mrp_routing_workcenter__bom_id"."sequence",
"mrp_routing_workcenter__bom_id"."id",
"mrp_routing_workcenter"."sequence",
"mrp_routing_workcenter"."id"
```
If we use the single term version the generated query has only one
sub-query:
```sql
SELECT "mrp_routing_workcenter".id
FROM "mrp_routing_workcenter"
LEFT JOIN "mrp_bom" AS "mrp_routing_workcenter__bom_id"
ON "mrp_routing_workcenter"."bom_id" = "mrp_routing_workcenter__bom_id"."id"
WHERE "mrp_routing_workcenter"."workcenter_id" in (1)
AND ( ("mrp_routing_workcenter"."bom_id" in (
SELECT "mrp_bom".id
FROM "mrp_bom"
WHERE (("mrp_bom"."company_id" in (1))
OR ("mrp_bom"."company_id" IS NULL))
)
)
)
ORDER BY "mrp_routing_workcenter__bom_id"."sequence",
"mrp_routing_workcenter__bom_id"."id",
"mrp_routing_workcenter"."sequence",
"mrp_routing_workcenter"."id"
```
In this version PG is able to produce a better query plan resulting in
better execution times.
Also, the `company_id` field is required on some models, so the "= False" comparison is useless.
closesodoo/odoo#159123
X-original-commit: 1b5c41f36801fb886ec591f29dba42787d698526
Related: odoo/enterprise#59378
Signed-off-by: Christophe Simonis (chs) <chs@odoo.com>
Co-authored-by: Christophe Simonis <chs@odoo.com>
- Create PO
- Confirm, delivery and create bill
- Confirm and create reverse move via "Add credit note" (Full Refund)
- Open portal view of the PO
Issue: The credit note payment status display `Waiting Payment` badge
instead of `Paid`
opw-3806514
closesodoo/odoo#158556
X-original-commit: 66d08a484dae64f559a78ccee18b4a79f9e4e70e
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Andrea Grazioso (agr) <agr@odoo.com>
Before this commit, it happens that the taxes display on the pdf were wrap,
specially when the description in the pdf were too long. This commit will add a
text-nowrap on the taxes when the len of the taxes is shorter than 10 characters
closesodoo/odoo#158774
Task: 3754824
X-original-commit: 95d0bd1794418ac8bdb4464c54304d3dcd0cb523
Signed-off-by: Florian Gilbert (flg) <flg@odoo.com>
Signed-off-by: Maximilien La Barre (malb) <malb@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>
Issue: Currently if we have taxes for our Purchase no matter if we set
the tax to inactive or we archive it, we will have access to it on the
purchase_order_line.
Steps to reproduce:
- Install Purchase
- Create a new Tax and set it to inactive.
- Now create a new RfQ and in the lines add any product.
- Try to change the tax for this product.
Solution: since we need this weird behavior for the cases where the tax
was applied to a RfQ and afterwards this tax was archived for example,
we should implement the needed domain to the view so we cannot access
to apply it anymore after inactive but it will still be visible where it
was applied beforehand.
opw-3776871
closesodoo/odoo#158077
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
*: crm, digest, hr_expense, im_livechat, mrp, purchase, sale_management,
website
The images in the digest email are updated to have the look of the new
"Milk" Ui. We want to keep names unique, as they target different
versions. That way we can keep a v15 oriented gif for people using tips
in v15 for example.
The mobile phone image is hosted on odoo.com.
task-3338467
X-original-commit: odoo/odoo@3711d2b61b
Part-of: odoo/odoo#158351
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>
*account,hr_expense,purchase,repair,sale,spreadsheet_dashboard_*,web
In Chile, "Untaxed Amount" has its own special term that isn't used in
Spain/LATAM spanish: ~~"Total neto"~~ "Monto neto" [Chilean customer
changed what term should be once fw-port was at v17]. Therefore
everywhere that it appears (in a .pot file), we ensure that the es_CL
localization uses this term.
Also untranslated terms from the es_CL.po files that were edited have
been removed since they add no benefit and make it harder to read the
file (we expect to only add terms to the file, not translate every
term for Chile).
opw-3670297
closesodoo/odoo#154473
X-original-commit: d1d4d30ef402ce835cba892459fdceadfc9944e1
Related: odoo/enterprise#56853
Signed-off-by: Louis Wicket (wil) <wil@odoo.com>
Signed-off-by: Tiffany Chang (tic) <tic@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>
Product template "property_account_expense_id" and "property_account_creditor_price_difference" fields must stay editable in cases even if not "can be puchased".
Since it being readonly is trivial, better leave it writeable instead of implementing cross module readonly logic.
closesodoo/odoo#150601
Task: 3695677
Signed-off-by: Florian Gilbert (flg) <flg@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>
For a first iteration, Russian translations were done using DeepL using
1 large .pot file of all the standard modules to translate (e.g. no
localizations, no test modules, etc). Unfortunately for some reason
doing a msgmerge with the existing ru.po files didn't seem to work, so
old "Translators" metadata at top of files were lost (maybe they will be
re-added during next Transifex sync?)
Part-of: odoo/odoo#152285
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>
When a user only has access to a branch of a company, they should be able
to access their parent's products, taxes, accounts, and journals
The current behavior however prevents that because of how the domain was
set on those field's view domain by checking the company_id in the view
This commit aims to fix that by removing the company domain limitation.
The fields have already considered the parent company by default via
check_company in python so no further changes are needed.
Additionally, for bank/cash journals, a company should be able to access
both their parent's and their children's journal and make transaction
in it.
Task-id: 3551305
Part-of: odoo/odoo#151562
This commit fixes some layout issues from the portal redesign.
The aims of this commit is to :
1) fix some issues with the column layout, mainly in the quotation section.
2) fix some spacing issues by using the right classes and better units.
3) fix the typescale and the information architecture with the right
heading tag.
4) fix some layout issues within the column layout and fixing unconsistent
layouts shared between different items.
5) fix an issue about the first information of the sidebar often
being hidden when scrolling, due to the sticky position of the sidebar
task-3651084
Part-of: odoo/odoo#147496
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>
Steps to reproduce:
- Install Accounting, Sales & Purchase
- Go to "Settings / Users & Companies / Companies"
- Create a branch company (e.g. Branch Company) for a company (e.g. YourCompany)
- Switch to Branch Company
- Go to Sales (or Purchase)
- Create a SO (or PO)
- Add a SO line (or PO line) and try to select a tax
=> Taxes from the parent company are not available in Sales and Purchase
as they are in Accounting
opw-3604981
opw-3636972
closesodoo/odoo#146384
X-original-commit: ddc653758c2dd6af74e21f5fbd07ab679ffb3e73
Signed-off-by: Anh Thao Pham (pta) <pta@odoo.com>
Steps to reproduce:
- Decimal Accuracy for Product Price > 4 digits
- Purchase a product using a price (1.2345 in my example)
- Go to Purchase > Reporting
- Enable the List View
- Add the field Average Cost (price_average)
- This displays as just two decimals
Note:
can be edited with studio but you can just add the field "price_average"
to the "purchase_report_view_tree" view xml
Fix:
round using product price Accuracy
opw-3560792
closesodoo/odoo#145667
X-original-commit: d5a3430cecb673a06057673d0671228449fa3f60
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Walid Hanniche (waha) <waha@odoo.com>
Odoo Translation Bot