Daily updates from Odoo
Friday, July 24, 2026
25 changes · 18.0
New functionality added to Odoo
Adds a new certified FedEx delivery module to support FedEx certification requirements and updated API behavior. This helps businesses use FedEx shipping in Odoo with changes aligned to FedEx guidelines and room for future FedEx options without database restructuring.
Original PR description
For the certification process of FedEx there were some changes needed in the delivery_fedex_rest module. This modules made those changes according to the FedEx guidelines. Task-id: 6164275
Enhancements to existing features
After this advisory: https://services.gst.gov.in/services/advisoryandreleases/read/661 It has become mandatory to pass `shipToGSTIN`, i.e. GST number of the ship-to partner during the generation of the e-waybill for `Bill-to-Ship-to` (type-2) and `Combination` (type-4) transaction types. task-6236778 Forward-Port-Of: odoo/odoo#266397
Original PR description
After this advisory: https://services.gst.gov.in/services/advisoryandreleases/read/661 It has become mandatory to pass `shipToGSTIN`, i.e. GST number of the ship-to partner during the generation of the e-waybill for `Bill-to-Ship-to` (type-2) and `Combination` (type-4) transaction types. task-6236778 Forward-Port-Of: odoo/odoo#266397
Resolved issues and error corrections
This fixes incorrect balance amounts shown in Mexican electronic payment documents when payments, credit notes, and exchange rate differences were reconciled together. The change keeps reconciliations in the right chronological order so fully paid invoices are reported accurately for compliance and customer records.
Original PR description
### Issue: Attributes of DoctoRelacionado node in the XML display an incorrect value because the exchange rate difference entry distorts the calculation, even though the invoice was fully settled. https://drive.google.com/file/d/1ntQny0o8bkkfYtY5ZNBK0Yq7Rq0I-yfz/view ### Fix: Sorting partials by "not exchange_move_id" first broke the chronological order whenever the invoice/payment partial itself carried an exchange difference (e.g. a foreign currency payment settled at another rate). This made the residual-chain algorithm consume the credit note's "other_residual" on the wrong payment, so ImpSaldoAnt/ImpPagado/ ImpSaldoInsoluto in the payment CFDI's DoctoRelacionado stayed wrong even though the invoice was fully paid. Populate the exchange move mapping in a separate first pass and sort the partials purely by date/id, so credit notes are always deducted from the correct payment. task-id:[6363092](https://www.odoo.com/odoo/project/49/tasks/6363092)
Fixed an issue where Avalara-related fields could be hidden when creating or editing Canadian contacts under a US company setup. This ensures users can correctly enter Avalara codes and exemption details for supported countries.
Original PR description
**Steps to reproduce:**
- Install Accounting and account_avatax
- Use a US company (by default)
- Create a contact with Canada as country
**Issue:**
In "Sales & Purchase" tab, all the fields from avatax module are not displayed (i.e. "Avalara Code", "Avalara Partner Code", "Avalara Exemption").
**Cause:**
The `invisible` property of those fields is using `fiscal_country_codes` char field.
If no company is set on the record, `fiscal_country_codes` will contain the country code of the selected companies in addition to the country code of the record.
In this case, the value of `fiscal_country_codes` will be `US,CA` string, which triggers `fiscal_country_codes not in ('US', 'CA')` invisible condition.
opw-6328395Fixed an error that could appear when opening the Scrap action from a new manufacturing operation in the Barcode app. This improves reliability for warehouse and manufacturing users, including cases involving consignment stock scans.
Original PR description
Versions -------- - 18.0+ Steps ----- 1. Open Barcode app; 2. click Operations; 3. click MANUFACTURING 4. click New; 5. click cogwheel on top right; 6. click Scrap. Issue ----- Traceback: > Error: Record stock.location with id=undefined doesn't exist in the cache Cause ----- When setting up the default context for the scrap menu, it it assumes `this.record` is not empty. Solution -------- Make `cache.getRecord` not raise an error when a location isn't found. Use optional chaining for other parts of the context that rely on a `record` being present. Also fixes a related issue introduced by 4b457fe, where the same traceback would be thrown on opening a new MO and scanning a product whilst consignment is enabled. opw-6397774
Spanish VAT record book exports now include taxable accounting entries that are not tied to standard invoices or bills, such as entries created when closing Point of Sale sessions. This helps businesses produce more complete VAT records and avoid missing reportable sales activity in Excel exports.
Original PR description
Currently, the Spanish VAT record books (Libros Registro de IVA) only include move types associated with invoices and bills. However, miscellaneous entries (type 'entry'), such as those generated by the Point of Sale session closures or manual liquidations, also carry tax obligations and must be reflected in these reports. Steps to reproduce: - Open a POS Session - Create an order, pay and close session - Go to Accouting > Reporting > Tax report - Select Generic Tax report - Print "VAT record Books" Issue: Only invoices and bills are visible in the excel file, and not the entry generated from point of sale. However, movements that are not related to invoices should be included in the VAT books. opw-5862529 Forward-Port-Of: odoo/enterprise#113681
The Mexican electronic invoicing process now avoids reprocessing recently updated invoices, preventing repeated background job loops. This improves reliability and reduces unnecessary system workload when checking invoice status with SAT.
Original PR description
Fixing the SAT cron in https://github.com/odoo/enterprise/pull/123213 we did not think it through it could cause infinite cron triggering. The write_date is updated on every record that is handled, so we can just not handle the invoices that have been updated in the last 4 hours, so when the cron is retriggered, it will not handle the same thing again. We can also use the notify_progress instead of just retriggering.
**Description of the issue/feature this PR addresses:** [FIX] website_sale: preserve parent company link on address update When a portal user linked to a company (B2B) edits their address during website checkout, the backend partner form subsequently loses the visual link to their parent company and incorrectly displays a "Create company" button instead. This occurs because the checkout form submits the company name as a raw text string (`company_name`). This string gets passed in t
Original PR description
**Description of the issue/feature this PR addresses:** [FIX] website_sale: preserve parent company link on address update When a portal user linked to a company (B2B) edits their address during…
**Description of the issue/feature this PR addresses:**
[FIX] website_sale: preserve parent company link on address update
When a portal user linked to a company (B2B) edits their address during
website checkout, the backend partner form subsequently loses the visual
link to their parent company and incorrectly displays a "Create company"
button instead.
This occurs because the checkout form submits the company name as a raw
text string (`company_name`). This string gets passed in the payload and
is written to the contact's record. In the backend `res.partner` form
view, the presence of data in the `company_name` field triggers UI
modifiers that hide the `parent_id` relational field and switch to the
B2C company creation flow.
This commit resolves the issue by conditionally removing `company_name`
from the payload if the user already has a `parent_id`. This ensures the
raw text is safely ignored for B2B users, keeping the backend UI intact
while preserving the expected behavior for unlinked B2C users.
opw-6374326
**Steps to Reproduce:**
- Contacts > New
- Set type to “Company”, any name, any Tax ID
- (On same page) > Contacts & Addresses > Add
- Set type to “Contact”, set any name/email
- Access the previously created (individual) contact > settings/gear icon > grant portal access > Grant Access
- Access the (individual) contact user form > settings/gear icon > Change Password > (any)
- Log in as portal user > add item to cart > checkout > Modify address and save
- Access the created (individual) contact again
- Observe “Create company” button despite partner_id being set. In addition, the company name is shown correctly, but no link appears
**Current behavior before PR:**
- When a portal user linked to a company edits their address during website checkout, the backend partner form stores the company_name field and hides the link to the parent company while displaying a "Create company" button
**Desired behavior after PR is merged:**
- Portal users linked to a company should be able to edit their address without losing UI links to the parent company in the partner form### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/6a6cc73650 [REL] 18.0.76 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/5832d8abe3 [FIX] HeaderVisibility: fix `getNextVisibleCellPosition` getter [Task: 6340589](https://www.odoo.com/odoo/2328/tasks/6340589) https://github.com/odoo/o-spreadsheet/commit/c93ad33981 [FIX] edition: do not change edition if not editing [Task: 6340589](https://www.odoo.com/odoo/2328/tasks/
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/6a6cc73650 [REL] 18.0.76 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)…
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/6a6cc73650 [REL] 18.0.76 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/5832d8abe3 [FIX] HeaderVisibility: fix `getNextVisibleCellPosition` getter [Task: 6340589](https://www.odoo.com/odoo/2328/tasks/6340589) https://github.com/odoo/o-spreadsheet/commit/c93ad33981 [FIX] edition: do not change edition if not editing [Task: 6340589](https://www.odoo.com/odoo/2328/tasks/6340589) Co-authored-by: Florian Damhaut (flda) <flda@odoo.com> Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com> Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com> Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com> Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com> Co-authored-by: Ronak Mukeshbhai Bharadiya (rmbh) <rmbh@odoo.com> Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com> Co-authored-by: Rémi Rahir (rar) <rar@odoo.com> Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com> Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com> Co-authored-by: Marceline Thomas (matho) <matho@odoo.com>
Version: -------- - 18.0+ Steps to reproduce: ------------------- - Install `stock` module - Configure a multi-company environment with a `Main Company` and a `Secondary Company` - Go to the setting enable Lots & Serial Numbers and switch into `Secondary Company` - Create a warehouse for the Secondary Company - In the Secondary Company, create a lot-tracked storable product - Create and validate a delivery for that product - Open the Traceability Report - Print the report Is
Original PR description
Version: -------- - 18.0+ Steps to reproduce: ------------------- - Install `stock` module - Configure a multi-company environment with a `Main Company` and a `Secondary Company` - Go to the setting…
Version:
--------
- 18.0+
Steps to reproduce:
-------------------
- Install `stock` module
- Configure a multi-company environment with a `Main Company`
and a `Secondary Company`
- Go to the setting enable Lots & Serial Numbers and switch into
`Secondary Company`
- Create a warehouse for the Secondary Company
- In the Secondary Company, create a lot-tracked storable product
- Create and validate a delivery for that product
- Open the Traceability Report
- Print the report
Issue:
------
The report header always displays the Main Company, even though the
traceability report belongs entirely to the Secondary Company.
Cause:
------
https://github.com/odoo/odoo/blob/2d54db3ac0b6d807e580315e2633f3e2b10a700c/addons/stock/static/src/client_actions/stock_traceability_report_backend.xml#L9
Clicking Print calls onClickPrint(), which builds the PDF URL and
downloads it with download() (a plain XMLHttpRequest POST), landing on
the `type='http'` route `/stock/<output_format>/<report_name>`
https://github.com/odoo/odoo/blob/3bd6b10c3f9ad8d93062b6b46490500edb8c9697/addons/stock/static/src/client_actions/stock_traceability_report_backend.js#L125-L134
That controller calls stock.traceability.report.get_pdf() without ever setting
`company_id` in the rendering context.
https://github.com/odoo/odoo/blob/3bd6b10c3f9ad8d93062b6b46490500edb8c9697/addons/stock/controllers/main.py#L23
Inside `get_pdf()`, the report header is rendered by passing an `rcontext`
dict to `web.internal_layout`.
That template resolves the company to display using the following priority:
https://github.com/odoo/odoo/blob/3bd6b10c3f9ad8d93062b6b46490500edb8c9697/addons/web/views/report_templates.xml#L805-L816
1. `company_id` — an explicit company record in the render context
2. `o.company_id` — the company of the document object `o`
3. `res_company` — the fallback, injected by `_render_template()` as
`self.env.company`
Because `get_pdf()` never sets `company_id` or `o` in `rcontext`, the
template always falls through to `res_company`.
https://github.com/odoo/odoo/blob/3bd6b10c3f9ad8d93062b6b46490500edb8c9697/odoo/addons/base/models/ir_actions_report.py#L770
This is populated by `ir.actions.report._render_template()`
as `self.env.company`, which resolves to the first company in
the user's `allowed_company_ids` list — typically the main company
regardless of which company owns the lot,
picking, or stock moves being printed.
As a result, the report content belongs to the secondary company while the
header always shows the main company.
Fix:
----
Resolve the company from the record on which the traceability report is
opened (using `active_model` and `active_id`) and pass it explicitly as
`company_id` when rendering the report.
`web.internal_layout` already gives precedence to an explicit
`company_id` over the default `res_company`, ensuring the report header
always displays the company that owns the traced record.
When the record has no company set, the header falls back to
`res_company`. Since the print request is a raw `type='http'` download
that never receives the company switcher's context, `user.context`
(holding `allowed_company_ids`) is now forwarded in the download POST
and merged into the environment by the controller - as done in
`web/controllers/report.py` - so the fallback resolves to the currently
active company instead of the user's default one.
<details>
<summary>Click here to see the results:</summary>
<p><strong>Before:</strong></p>
<div class="image-row">
<img src="https://github.com/user-attachments/assets/7e3a5d65-9114-4bce-9139-a88cff7c261f" />
</div>
<p><strong>After:</strong></p>
<div class="image-row">
<img src="https://github.com/user-attachments/assets/0a105f80-b6ae-400d-a787-fb8706d5f519" />
</div>
</details>
---
opw-6345446
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prCurrentyl the unsupported models will be checked like the following ```sql ia.res_model NOT IN ARRAY['model1', 'model2'] ``` This causes a syntax error. Use `ANY` to avoid the issue ```sql ia.res_model != ANY(ARRAY['model1', 'model2']) ``` Reproduce in Odoo shell ```python from odoo.tools import SQL query = SQL(""" SELECT ia.id FROM ir_attachment ia WHERE ia.res_model NOT IN %(unsupported_models)s LIMIT 1; """, unsupported_models=self.env['ir.atta
Original PR description
Currentyl the unsupported models will be checked like the following
```sql
ia.res_model NOT IN ARRAY['model1', 'model2']
```
This causes a syntax error. Use `ANY` to avoid the issue
```sql
ia.res_model != ANY(ARRAY['model1', 'model2'])
```
Reproduce in Odoo shell
```python
from odoo.tools import SQL
query = SQL("""
SELECT ia.id
FROM ir_attachment ia
WHERE ia.res_model NOT IN %(unsupported_models)s
LIMIT 1;
""",
unsupported_models=self.env['ir.attachment']._get_cloud_storage_unsupported_models(),
)
```
opw-6404861Issue: Compare to lot and serial number package are not multi company. It means that the package don't pass from a company to the other. So when a company deliver to another. The delivery will create a quant with the package. However the receipt in the other company will create a new quant without package (or a new package). It means that the quants are never reconcile and it could become difficult to understand what remains in intercompany location and what are artifact from past movements.
Original PR description
Issue: Compare to lot and serial number package are not multi company. It means that the package don't pass from a company to the other. So when a company deliver to another. The delivery will create a quant with the package. However the receipt in the other company will create a new quant without package (or a new package). It means that the quants are never reconcile and it could become difficult to understand what remains in intercompany location and what are artifact from past movements. In order to fix it, we introduce a new system parameter to directly unpack after the delivery. This way the receipt is always without source package and will automatically decrease the quant. opw-6376983
**STEP TO REPRODUCE** 1. Install l10n_fr_pdp and select the french company. 2. Go on a contact form, under invoicing, select 'by Approved Platform' for invoice sending. 3. Click on the eInvoice format selection, and notice the format 'France E-invoicing (UBL 2.1)' is not there. Note: with other invoice sending values, it shows up. **CAUSE** In the `_get_ubl_cii_formats_info()` override in `l10n_fr_pdp`, we declare the ubl_21_fr format as not being usable with the peppol invoice sending me
Original PR description
**STEP TO REPRODUCE** 1. Install l10n_fr_pdp and select the french company. 2. Go on a contact form, under invoicing, select 'by Approved Platform' for invoice sending. 3. Click on the eInvoice format selection, and notice the format 'France E-invoicing (UBL 2.1)' is not there. Note: with other invoice sending values, it shows up. **CAUSE** In the `_get_ubl_cii_formats_info()` override in `l10n_fr_pdp`, we declare the ubl_21_fr format as not being usable with the peppol invoice sending method. However, the Approved Platform invoice sending (used to send ubl_21_fr) *is* the peppol invoice sending method in disguise. (we reused the peppol invoice sending method because pdp and peppol are very similar). opw-6387796
Currently, sending a simplified invoice (`TD07`) to the Italian Tax Agency fails when an invoice line contains multiple taxes. **Steps to reproduce:** - Install the `l10n_it_edi_withholding` module and switch to an IT Company. - Create a new customer and set only the country to Italy and the Tax ID. - Create a new invoice for that customer. - Add a line with `22%` and `4% INPS` taxes. - Go to the `Electronic Invoicing` tab, set the `Document Type` to `TD07 - Simplified invoice`, and c
Original PR description
Currently, sending a simplified invoice (`TD07`) to the Italian Tax Agency fails when an invoice line contains multiple taxes. **Steps to reproduce:** - Install the `l10n_it_edi_withholding` module…
Currently, sending a simplified invoice (`TD07`) to the Italian Tax Agency fails when an invoice line contains multiple taxes. **Steps to reproduce:** - Install the `l10n_it_edi_withholding` module and switch to an IT Company. - Create a new customer and set only the country to Italy and the Tax ID. - Create a new invoice for that customer. - Add a line with `22%` and `4% INPS` taxes. - Go to the `Electronic Invoicing` tab, set the `Document Type` to `TD07 - Simplified invoice`, and confirm the invoice. - Try to `Send To Tax Agency`. **Error:** `Node: <Natura t-if="line.tax_ids.l10n_it_exempt_reason" t-out="line.tax_ids.l10n_it_exempt_reason"/>` `ValueError: Expected singleton: account.tax(102, 3)` **Root Cause:** At [1], the code accesses `line.tax_ids.l10n_it_exempt_reason`, but when an invoice contains multiple taxes, causing an error. **Fix:** This commit prevents the error and ensures the user can send a simplified invoice by applying a fix similar to [2]. [1]: https://github.com/odoo/odoo/blob/230483ffd7d8674cd6bf98a4ffb6591f755422e0/addons/l10n_it_edi/data/invoice_it_simplified_template.xml#L14 [2]: https://github.com/odoo/odoo/blob/230483ffd7d8674cd6bf98a4ffb6591f755422e0/addons/l10n_it_edi/data/invoice_it_template.xml#L28-L181 Ticket [link](https://www.odoo.com/odoo/project.task/6354138) Ticket [link](https://www.odoo.com/odoo/project.task/6379377) opw-6354138 opw-6379377 Forward-Port-Of: odoo/odoo#273823
Description of the issue/feature this PR addresses: A cash rounding line resolves its company-dependent profit/loss account against the active company instead of the invoice's own company, which breaks multi-company invoicing whenever the invoice's company differs from the active one. Current behavior before PR: - Enable Multi-Companies in the settings. - Create a second company (Company B). - Open Accounting > Configuration > Cash Roundings. - Create a cash rounding with strategy "Add a
Original PR description
Description of the issue/feature this PR addresses: A cash rounding line resolves its company-dependent profit/loss account against the active company instead of the invoice's own company, which…
Description of the issue/feature this PR addresses: A cash rounding line resolves its company-dependent profit/loss account against the active company instead of the invoice's own company, which breaks multi-company invoicing whenever the invoice's company differs from the active one. Current behavior before PR: - Enable Multi-Companies in the settings. - Create a second company (Company B). - Open Accounting > Configuration > Cash Roundings. - Create a cash rounding with strategy "Add a rounding line" and precision 1.00. - Make Company A the active company in the company switcher. - Set the cash rounding's profit and loss accounts to Company A accounts. - Switch the active company to Company B. - Set the cash rounding's profit and loss accounts to Company B accounts. - Make Company A the active company again, keeping both companies active. - Create a customer invoice for Company B. - Add one invoice line whose total is not a multiple of the rounding precision. - Set the invoice's cash rounding to the one above. > Adding the rounding line raises a cross-company UserError: the company-dependent account is resolved against Company A while the invoice belongs to Company B. Desired behavior after PR is merged: The rounding line resolves the company-dependent profit/loss account against the invoice's own company, so the rounding line always uses that company's account and no cross-company error is raised. Covered by the added test TestAccountMoveCashRoundingMultiCompany. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Helpers for the enterprise PR opw-5862529 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#270624
Original PR description
Helpers for the enterprise PR opw-5862529 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#270624
The amount in words split the total with int(decimal * 100), which truncates. 3989.33 is held in binary as 3989.3299..., so the kuruş/cents came out one short (32 instead of 33). The written amount then disagreed with the numeric total on the same invoice and Nilvera rejects it. Round to the currency precision and round the subunit instead. Task-6383690 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: ---
Original PR description
The amount in words split the total with int(decimal * 100), which truncates. 3989.33 is held in binary as 3989.3299..., so the kuruş/cents came out one short (32 instead of 33). The written amount then disagreed with the numeric total on the same invoice and Nilvera rejects it. Round to the currency precision and round the subunit instead. Task-6383690 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#277180
Steps to reproduce: ------------------- 1. Install sale_timesheet. 2. Create a service product with: - Invoicing Policy: Prepaid/Fixed Price - Create on Order: Project & Task 3. Create a sales order with this product. 4. Open the generated project > dashboard and verify that "To Invoice" shows $1. 5. Create a project update and observe that "To Invoice" also shows $1. 6. Return to the sales order, create and post the invoice. 7. Open the project dashboard again and verify that "T
Original PR description
Steps to reproduce: ------------------- 1. Install sale_timesheet. 2. Create a service product with: - Invoicing Policy: Prepaid/Fixed Price - Create on Order: Project & Task 3. Create a sales order…
Steps to reproduce: ------------------- 1. Install sale_timesheet. 2. Create a service product with: - Invoicing Policy: Prepaid/Fixed Price - Create on Order: Project & Task 3. Create a sales order with this product. 4. Open the generated project > dashboard and verify that "To Invoice" shows $1. 5. Create a project update and observe that "To Invoice" also shows $1. 6. Return to the sales order, create and post the invoice. 7. Open the project dashboard again and verify that "To Invoice" is now $0. 8. Create another project update. Issue: ------ The project update margin still displays $1 under "To Invoice" even though the sales order has already been fully invoiced. Cause: ------ The project update template displays the aggregated profitability totals (`profitability['total']['revenues']` and `profitability['total']['costs']`) instead of the dedicated `to_bill_to_invoice` and `billed_invoiced` values, causing stale "to invoice" amounts to persist after invoicing. Solution: --------- Use the `to_bill_to_invoice` and `billed_invoiced` values when rendering the project update profitability report. opw-6323869 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Currently, the property value is not displayed on the Kanban card, even when the `Display in Cards` option is enabled. This PR ensures that if `Display in Cards` option is enabled for a property, its value is displayed on the corresponding equipment Kanban card. **Steps to reproduce:** - Install the Maintenance module. - Open `Equipment`. - Open an existing equipment record or create a new one and save it. - Click the actions (gear) menu from the equipment form view. - Select `Add Prop
Original PR description
Currently, the property value is not displayed on the Kanban card, even when the `Display in Cards` option is enabled. This PR ensures that if `Display in Cards` option is enabled for a property, its value is displayed on the corresponding equipment Kanban card. **Steps to reproduce:** - Install the Maintenance module. - Open `Equipment`. - Open an existing equipment record or create a new one and save it. - Click the actions (gear) menu from the equipment form view. - Select `Add Properties`. - Add a property and enable the `Display in Cards` option. Open the Kanban view. **Expected behavior:** The property value should be displayed on the Kanban card when the `Display in Cards` option is enabled. Issue: [#277479](https://github.com/odoo/odoo/issues/277479)
Steps to reproduce: - set the "Product Price" decimal precision to 3 - create two products with a price of 42.609 and a 15% excluded tax - create an automatic promotion granting a 20.4% discount on these specific products - in the PoS, sell both products: the reward line shows -20.00 and the order total 78.00 - pay 100.00 in cash and validate The synced order total becomes 78.01 while the customer paid 78.00. The discount reward line is created in the frontend with an unrounded price
Original PR description
Steps to reproduce: - set the "Product Price" decimal precision to 3 - create two products with a price of 42.609 and a 15% excluded tax - create an automatic promotion granting a 20.4% discount on…
Steps to reproduce: - set the "Product Price" decimal precision to 3 - create two products with a price of 42.609 and a 15% excluded tax - create an automatic promotion granting a 20.4% discount on these specific products - in the PoS, sell both products: the reward line shows -20.00 and the order total 78.00 - pay 100.00 in cash and validate The synced order total becomes 78.01 while the customer paid 78.00. The discount reward line is created in the frontend with an unrounded price unit: -(85.22 * 20.4%) = -17.384879999999995. The frontend computes taxes on the price unit rounded to the "Product Price" precision (see `get_unit_price()`): -17.385 -> -17.39 - 2.61 = -20.00 tax included, hence the 78.00 total displayed and paid. However, the raw value is what is sent to the server and stored as-is (`pos.order.line.price_unit` is declared with `digits=0`). Whenever the backend recomputes the amounts from the lines - e.g. when a cash change makes `_process_payment_lines()` call `_compute_prices()` - the taxes are computed on the raw value: -17.38 - 2.61 = -19.99, and the order total drifts to 78.01. Round the reward line price unit to the "Product Price" precision when creating it, as `_getRewardLineValuesProduct()` already does, so the stored value is the one the frontend computed its totals with. opw-6322031 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Steps to reproduce ================== 1. Configure a delivery method with free shipping above a threshold 2. Add a product to the cart above that threshold, select the delivery method and leave the cart unfinished 3. Lower the product price below the threshold 4. Recover the cart and confirm the order from /shop/checkout => The product prices are refreshed, but shipping stays free although the new total is below the threshold. Root cause ========== Since [1], nothing re-rates th
Original PR description
Steps to reproduce ================== 1. Configure a delivery method with free shipping above a threshold 2. Add a product to the cart above that threshold, select the delivery method and leave the…
Steps to reproduce ================== 1. Configure a delivery method with free shipping above a threshold 2. Add a product to the cart above that threshold, select the delivery method and leave the cart unfinished 3. Lower the product price below the threshold 4. Recover the cart and confirm the order from /shop/checkout => The product prices are refreshed, but shipping stays free although the new total is below the threshold. Root cause ========== Since [1], nothing re-rates the carrier after /shop/confirm_order refreshes the cart prices: the delivery method is selected before the confirmation. In 17.0, the payment page auto-clicked the selected carrier on load, which re-rated the shipping cost and masked the issue. Fix === Re-rate the selected delivery method in `shop_confirm_order` after the prices have been recomputed, as `_cart_update` already does. [1]: https://github.com/odoo/odoo/commit/8e2b6cede55b51f7ccdbe7601aa7e6035fd6f9fe opw-6383849 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
In Discuss, clicking a livechat chatbot member from the member list can lead to a traceback because the avatar card is opened with member.persona.userId, while chatbot operators can be partner-only records with no related user. This happens when the bot member is not filtered out as is_bot, notably in the chatbot script test flow where the channel has no livechat_channel_id. We cannot simply block on a missing member.persona.userId: the user relation may exist but not be fetched yet. In
Original PR description
In Discuss, clicking a livechat chatbot member from the member list can lead to a traceback because the avatar card is opened with member.persona.userId, while chatbot operators can be partner-only records with no related user. This happens when the bot member is not filtered out as is_bot, notably in the chatbot script test flow where the channel has no livechat_channel_id. We cannot simply block on a missing member.persona.userId: the user relation may exist but not be fetched yet. In the is commit we resolve the partner through mail.store.getPartner() before opening the avatar card, so valid users are fetched lazily and true partner-only records are ignored. task-4642940
Taxes with SAF-T code 21 and 22 are not correct and needed modification where they should be set to 0% because: - The foreign supplier invoices without Norwegian VAT, so the invoice total shouldn't increase - You must still self-assess 25% VAT and report it - The 25% is booked as both output and input VAT simultaneously → net cash effect = 0 - Only the basis amount is reported in the VAT return (import boxes) task-6254727
Original PR description
Taxes with SAF-T code 21 and 22 are not correct and needed modification where they should be set to 0% because: - The foreign supplier invoices without Norwegian VAT, so the invoice total shouldn't increase - You must still self-assess 25% VAT and report it - The 25% is booked as both output and input VAT simultaneously → net cash effect = 0 - Only the basis amount is reported in the VAT return (import boxes) task-6254727
In commit 611ed3c430026d5fbeac0e565c379ae57a2a30bc `NOT IN ...` was converted to `!= ANY(...) but it should have been `!= ALL(...). task-None
Original PR description
In commit 611ed3c430026d5fbeac0e565c379ae57a2a30bc `NOT IN ...` was converted to `!= ANY(...) but it should have been `!= ALL(...). task-None
Miscellaneous changes
_stock_account_anglo_saxon_reconcile_valuation() scans a whole invoice on every call and only reconciles at the end, but _validate_accounting_entries() calls it once per product. The invoice is therefore re-scanned as many times as there are products. This can lead to performance issues when the invoices contain thousands of lines. Steps to reproduce: - use anglo-saxon accounting with automated inventory valuation - confirm a sale order holding a few thousand distinct products -
Original PR description
_stock_account_anglo_saxon_reconcile_valuation() scans a whole invoice on every call and only reconciles at the end, but _validate_accounting_entries() calls it once per product. The invoice is…
_stock_account_anglo_saxon_reconcile_valuation() scans a whole invoice on every call and only reconciles at the end, but _validate_accounting_entries() calls it once per product. The invoice is therefore re-scanned as many times as there are products. This can lead to performance issues when the invoices contain thousands of lines. Steps to reproduce: - use anglo-saxon accounting with automated inventory valuation - confirm a sale order holding a few thousand distinct products - invoice it, then validate its delivery => performance issue Group the products by their related invoices and reconcile each group in one call. Delivering 20 products against a 5000 line invoice goes from 63s to 9.7s. On the reported customer database a delivery of 197 products, against an invoice grouping 27 orders and carrying 17822 journal items, goes from 369s to 16s. Benchmark: | Invoice Lines | Before | After | |--------------:|-------:|------:| | 100 | 1.9s | 0.7s | | 1 000 | 13.0s | 2.0s | | 5 000 | 63.3s | 9.7s | opw-6388781 Forward-Port-Of: odoo/odoo#277114