Daily updates from Odoo
Thursday, December 4, 2025
40 changes
5 changes
Resolved issues and error corrections
This update corrects errors in how tax unit reporting is handled, particularly for OSS reports. It ensures that companies within a shared tax unit are correctly consolidated, and tax returns are always generated using the appropriate main company. This improves the accuracy and reliability of financial reporting.
Original PR description
This PR delivers multiple fixes to ensure consistent and accurate behavior when working with tax units across OSS and standard tax return reports: [FIX] l10n_eu_oss_reports: Correct Tax Unit…
This PR delivers multiple fixes to ensure consistent and accurate behavior when working with tax units across OSS and standard tax return reports: [FIX] l10n_eu_oss_reports: Correct Tax Unit Detection for OSS Reports OSS reports lack a country, causing _get_available_tax_units to return no results. As a consequence, only the environment's main company was considered. This fix ensures that when multiple companies belong to the same tax unit, their OSS reports are correctly consolidated under that shared unit. [FIX] account_reports: Link Tax Unit Returns to the Main Company When generating domestic tax returns for a company that is part of a tax unit, the main company of the unit should be used since it is responsible for filing. This update ensures tax return generation is always aligned with the appropriate main company. [FIX] account_reports: Enforce Main Company When Generating Report Options get_options previously relied on the order of companies within a tax unit, assuming the first entry was the main company. Because this order is not guaranteed, the call is now explicitly scoped using with_company to ensure the main company is always used when preparing report options. Forward-Port-Of: odoo/enterprise#99715
This update resolves an issue where pressing the TAB key while adding notes to sale order lines would clear and remove the entered text instead of saving it. The fix ensures that users can now correctly add and save notes within the sale order line interface, improving data accuracy and usability.
Original PR description
## Versions 18.0 > saas-18.4 Fixed in 19.0 thanks to bc6592a8514d6557037868a0f42265070fa02263 introducing the `parseLabel` method: https://github.com/odoo-dev/odoo/blob/19e03df5d9546d3948c2a184a6f26db7ba3aec71/addons/account/static/src/components/product_label_section_and_note_field/product_label_section_and_note_field.js#L47-L51 ## Issue When adding a section or a note line in the sale order lines list view, pressing TAB key caused the line to be cleared and removed instead of being saved. ## Steps to reproduce - Open an invoice or create one for any customer: - Click either on "Add a section" or "Add a note"; - Write something down; - Press the TAB key. ## Fix Handle the field with the appropriate `useInputField` hook. opw-4967733 Forward-Port-Of: odoo/odoo#237375 Forward-Port-Of: odoo/odoo#230644
This update resolves an issue where promotion rewards automatically added to cart lines couldn't be removed. The fix ensures the correct context is passed to the removal process, now allowing users to successfully remove promotion rewards from their shopping carts. This improves the user experience and prevents unwanted promotions from remaining in orders.
Original PR description
Steps: - Add a loyalty program of type promotion - Program trigger should be Automatic - Go to Shop > Add a product that triggers the reward of promotion - Try to remove the promotion added from the cart lines Issue: - Remove does not work for the automatically applied promotion reward Cause: - Context is not properly passed to the unlink method that removes the cart line of the promotion reward. - Since the unlink method is not receiving context properly, removal is bypassed Fix: - Instead of adding context in `self`, adding it directly in the `order_line` context fixes the issue. task-5076061 Forward-Port-Of: odoo/odoo#226789
This update fixes a reporting issue by ensuring the NIF (tax identification number) is now included in the BOE export for model 347, as required by Spanish tax regulations. Previously, the system only included VAT, but this change ensures accurate reporting to the Agencia Tributaria, aligning with specific documentation requirements.
Original PR description
[FIX] l10n_es_reports: include NIF in boe export for model 347 The NIF must be included in the BOE export for modelo 347 https://sede.agenciatributaria.gob.es/static_files/Sede/Disenyo_registro/DR_300_399/archivos/347.pdf pages 3 & 12. Before this commit, we read the vat but if it doesn't start with 'ES' we return an empty string because we based on TIN. Now we'll read the vat (without 'ES' if it starts with it). The user is responsible to fill a correct number in the vat field of the company. opw-5207241 Forward-Port-Of: odoo/enterprise#100489
This update resolves a crash that occurred when saving website forms that used property fields. The issue stemmed from incorrect handling of property field types, specifically when whitelisting fields. The fix ensures property fields are correctly processed, improving website form stability and functionality.
Original PR description
[FIX] website, website_crm: fix crash on save if property field in form --- __Before commit:__ 1. Go to CRM app 2. Open a lead 3. Add a new property field by clicking on the cogwheel at the top left…
[FIX] website, website_crm: fix crash on save if property field in form
---
__Before commit:__
1. Go to CRM app
2. Open a lead
3. Add a new property field by clicking on the cogwheel at the top left
and then *Edit Properties*
4. Open the website builder
5. Drag a new form
- Set *Action* to *Create an Opportunity*
- Set *Sales Team* to *Sales*
6. Add a new field and set *Type* to the newly created property field
7. Save
=> Traceback:
`ValueError: Unable to whitelist field(s) ['xxxx'] for model 'crm.lead'`
__Cause:__
We are trying to whitelist a property field which is not an actual field
to the `crm.lead` model but rather a property of one of the `crm.team`.
__Fix:__
Filter the property fields to whitelist.
---
[FIX] html_builder: make builder_list work with non-integer ids
---
__Before commit:__
1. Go to CRM app
2. Open a lead
3. Click on the cogwheel at the top left and then on *Edit Properties*
- Set *Field Type* to *Selection*
- Add two values
4. Open the website builder
5. Drag a new form
- Set *Action* to *Create an Opportunity*
- Set *Sales Team* to *Sales*
6. Add a new field and set *Type* as the newly created property field
7. Click on *Add New Radio*
=> There are still items to add although there are already all included.
8. Click on an item
=> Two tracebacks appear:
- `TypeError: Cannot use 'in' operator to search for '_id' in null`
- `TypeError: Cannot read properties of null (reading 'id')`
__Cause:__
When adding item to the selection, the id is casted to `Number` although
it can be a string if the field type is a property.
__Fix:__
When comparing two ids, cast both side of the comparison to strings to
make sure a match can always be found.
task-52485266 changes
Resolved issues and error corrections
This update fixes an issue where scanning a lot multiple times during barcode picking would incorrectly create a backorder. The change ensures that quantity updates are applied correctly to the relevant lines, preventing unnecessary backorders and improving order fulfillment accuracy. This resolves a bug related to how the system processes lot scans.
Original PR description
**Steps to reproduce:** - create a product tracked by lot - create a lot with a quantity of 2 - create a new sale order - add two sale order lines, both for a quantity of 1 of the product - confirm -…
**Steps to reproduce:** - create a product tracked by lot - create a lot with a quantity of 2 - create a new sale order - add two sale order lines, both for a quantity of 1 of the product - confirm - open the picking in barcode - scan the stock location - scan the lot - scan the lot another time - validate **Current behavior:** a backorder is created **Expected behavior:** No back order should be created **Cause of the issue:** After scanning the lot for the first time we have the following situation: two lines : - one with a quantity of 1, qty_done of 1 and reserved_uom_qty of 1 - one with a quantity of 1, qty_done of 0 and reserved_uom_qty of 1 both lined grouped in a parent line with quantity of 1 qty_done of 1 and reserved_uom_qty of 2 All of this is correct. when scanning the lot for the second time: _findLine iterates through the lines to select the right line to use. _findLine calls _lineIsNotComplete on the first line to check if it's complete (this first line is complete). https://github.com/odoo/enterprise/blob/58d55868750b827a9d5ebd8b4ab2cc23c4445eca/stock_barcode/static/src/models/barcode_model.js#L1684 But _lineIsNotComplete will actually do the check on the parent line (which is not complete), so the return value will be true. https://github.com/odoo/enterprise/blob/58d55868750b827a9d5ebd8b4ab2cc23c4445eca/stock_barcode/static/src/models/barcode_picking_model.js#L1338 As a consequence, the quantity will be added in the first line and we will have a qty_done of 2 in the first line and a qty_done of 0 in the second line. Which will lead to the creation of a back order opw Forward-Port-Of: odoo/enterprise#100626 Forward-Port-Of: odoo/enterprise#99774
This update resolves an issue in the German localization (l10n_de) module where changing a product's cost in a multi-company environment would trigger tax access errors. The problem stemmed from fetching taxes in a privileged (sudo) environment, leading to incorrect data. This fix, implemented in Odoo 19.0, corrects this by removing the privileged environment, ensuring accurate tax calculations.
Original PR description
from v18.0 to v18.4, in a multi-company environment, when a product with no income/expense account had its cost changed, all the taxes for other companies were being fetched which caused access errors when trying to view it after a manual save. This happens because the fetch is happening in a sudo environment because the stock valuation layer was being created as sudo, so all taxes were being fetched and probably because of cache pollution they were not being filtered properly, this is not happening in v19.0 because the stock valuation layer was removed, so everything is being called in a normal user environment, refer to this commit-08b62a4 task-5117882 Forward-Port-Of: odoo/odoo#236931
This update resolves a problem where email templates were being incorrectly parsed, leading to errors. The fix ensures that all HTML elements, except for void elements, are properly closed, improving the reliability of email content generation. This prevents template rendering issues when sending emails.
Original PR description
**Step to Reproduce:** - install Subscription (with demo data) - try to edit `Subscription: Payment Reminder` email template **Observation:** - Traceback for faulty template **Cause** For outgoing…
**Step to Reproduce:**
- install Subscription (with demo data)
- try to edit `Subscription: Payment Reminder` email template
**Observation:**
- Traceback for faulty template
**Cause**
For outgoing mails, we are using output_method = 'xml' when normalizing html content
https://github.com/odoo/odoo/blob/cb5176df98490ef04c0aac481f010bd2ac2f2424/odoo/orm/fields_textual.py#L580-L587
when this content is parsed using DOMParser in browser,
https://github.com/odoo/odoo/blob/cb5176df98490ef04c0aac481f010bd2ac2f2424/addons/html_editor/static/src/html_migrations/html_upgrade_manager.js#L61-L63
we might get different result.
For a very basic template like this:
```
<div>
<t t-if="ctx.get('error')">
<pre t-out="ctx['error'] or ''" />.
</t>
<t t-else="">
<span>some text</span>
</t>
</div>
```
when parsed using Domparser(), return a faulty template:
```
<div>
<t t-if="ctx.get('error')">
<pre t-out="ctx['error'] or ''">.
<t t-else="">
<span>some text</span>
</t>
</pre>
</t>
</div>
```
Issue roots because of use of self-closing tags, which are valid for xml but not for html
**Fix:**
- we forcefully replace all self-closing tags(which are not void elements) with a closing tag.
- see list of void elements https://developer.mozilla.org/en-US/docs/Glossary/Void_element
opw-5234345
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis update resolves an issue where promotion rewards automatically added to shopping carts couldn't be removed. The fix ensures that removing a promotion reward from a cart line now functions correctly, improving the user experience and preventing unwanted rewards from remaining in orders. This change was made to address a bug impacting order management.
Original PR description
Steps: - Add a loyalty program of type promotion - Program trigger should be Automatic - Go to Shop > Add a product that triggers the reward of promotion - Try to remove the promotion added from the cart lines Issue: - Remove does not work for the automatically applied promotion reward Cause: - Context is not properly passed to the unlink method that removes the cart line of the promotion reward. - Since the unlink method is not receiving context properly, removal is bypassed Fix: - Instead of adding context in `self`, adding it directly in the `order_line` context fixes the issue. task-5076061 Forward-Port-Of: odoo/odoo#226789
This update resolves an issue where the Point of Sale app for Mexican companies was incorrectly flagging an error when the 'Invoice to Public' setting was set to 'Yes' for customers without a country or zip code. The fix ensures this setting is properly updated, preventing the error and allowing users to correctly generate public invoices as required by Mexican regulations.
Original PR description
In the POS of a Mexican company, when requesting an invoice, the user is asked to set the invoice to public or not. If the customer does not have a recognized ZIP code or country, setting the invoice…
In the POS of a Mexican company, when requesting an invoice, the user is asked to set the invoice to public or not. If the customer does not have a recognized ZIP code or country, setting the invoice to public **should not** raise an error, but it does. This is because the `l10n_mx_edi_cfdi_to_public` field is not correctly updated in the ORM, which leads to the UserError below being triggered, as `l10n_mx_edi_cfdi_to_public` is always set to `False` if it's not updated by its `_compute` method.
https://github.com/odoo/enterprise/blob/dd89c2c72039c9910cc0a303bca332f4103c08f6/l10n_mx_edi/models/account_move_send.py#L54-L55
The said field is not properly updated because it is a compute field.
Such fields are not transferred to the ORM because of the two following
conditions from the POS: [[1](https://github.com/odoo/odoo/blob/5c2280d089f248dff67df980bee1ce6a4156f2c9/addons/point_of_sale/static/src/app/models/related_models.js#L205-L206), [2](https://github.com/odoo/odoo/blob/5c2280d089f248dff67df980bee1ce6a4156f2c9/addons/point_of_sale/static/src/app/models/related_models.js#L895-L896)]
To minimize behavioral changes, the required field (`l10n_mx_edi_cfdi_to_public`) is simply added at the end of the serialization process.
Once this field is correctly shared with the ORM, the UserError is not longer raised when the *Invoice to Public* field is set to "Yes" in the POS.
Steps to reproduce the initial error:
1. Install the following app and module:
- Point of Sale (`point_of_sale`)
- Mexican Localization for the Point of Sale (`l10n_mx_edi_pos`)
2. Set the company to a Mexican one (e.g., *ESCUELA KEMPER URGATE*)
3. Open the POS app
4. Open a register
5. Select a product and click *Add*
6. Click *Payment*
7. Set the Customer to a new customer with only a name (no Country/ZIP Code)
- Click "Cash" to set the Remaining to 0
8. Toggle the *Invoice* button, set the *Invoice to Public* to *"Yes"* and click *Ok*
9. Click *Validate*.
10. An error *"Invalid Operation, CFDI not set to Public"* appears.
opw-5171035
Forward-Port-Of: odoo/enterprise#101162
Forward-Port-Of: odoo/enterprise#99871This update resolves an error that occurred when creating time off requests. Specifically, the system would fail if a start date was removed and then the employee was changed. The fix ensures the system only checks for past dates when a start date is provided, preventing the error.
Original PR description
Currently, an error occurs when creating a time off request for an employee. Steps to Reproduce: - Install the `hr_holiday` module. - Go to `Management > Time Off`. - Create a `new time off` and…
Currently, an error occurs when creating a time off request for an employee. Steps to Reproduce: - Install the `hr_holiday` module. - Go to `Management > Time Off`. - Create a `new time off` and `remove the start date`. - Now `change the employee`. `AttributeError: 'bool' object has no attribute 'date'` This error occurs when creating a time off request for an employee. If the start date is removed and then the employee is changed, the compute method [1] runs to determine whether the time off can be approved and to update the states [2]. During this process, the system checks whether the time off date is in the past, and since the start date is missing, it results in the error [3]. This commit ensures that the system only checks whether the time off is in the past when a start date is provided. [1]- https://github.com/odoo/odoo/blob/aa53689d3c593a8a41479c51edc2b01e3c284f96/addons/hr_holidays/models/hr_leave.py#L594-L597 [2]- https://github.com/odoo/odoo/blob/aa53689d3c593a8a41479c51edc2b01e3c284f96/addons/hr_holidays/models/hr_leave.py#L1279 [3]- https://github.com/odoo/odoo/blob/aa53689d3c593a8a41479c51edc2b01e3c284f96/addons/hr_holidays/models/hr_leave.py#L1237 No Task ID --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
3 changes
Resolved issues and error corrections
This update ensures the NIF (tax identification number) is now included in the BOE export for model 347 reports, as required by Spanish tax regulations. Previously, the system only included VAT, but this change corrects that to align with specific reporting requirements outlined in official documentation. Users are responsible for accurately entering the NIF in the company's VAT field.
Original PR description
[FIX] l10n_es_reports: include NIF in boe export for model 347 The NIF must be included in the BOE export for modelo 347 https://sede.agenciatributaria.gob.es/static_files/Sede/Disenyo_registro/DR_300_399/archivos/347.pdf pages 3 & 12. Before this commit, we read the vat but if it doesn't start with 'ES' we return an empty string because we based on TIN. Now we'll read the vat (without 'ES' if it starts with it). The user is responsible to fill a correct number in the vat field of the company. opw-5207241 Forward-Port-Of: odoo/enterprise#100489
This update resolves an issue where users couldn't assign analytic distributions to batch payments during bank reconciliation, leading to validation errors. The fix removes a restriction that was preventing edits to these payments, now allowing users to correctly apply analytics for improved financial reporting and tracking. This ensures accurate reconciliation processes.
Original PR description
**Issue** Users were unable to set analytic distributions on batch payments via the bank reconciliation widget. This limitation could lead to validation errors. **Steps to Reproduce** 1. Create two customer payments 2. Group them into a batch and validate it 3. Open the bank reconciliation widget 4. Create a bank statement line 5. Navigate to the batch payment tab and click on the batch payment 6. Attempt to click on the batch payment line **Root Cause** The method handleLineClicked was overridden in a way that prevented the call to the parent implementation when the flag was 'new_batch', disabling interactivity for these lines. **Fix** The restrictive override of handleLineClicked was removed. All fields in the Manual Operations tab are made read-only, except for analytic distributions, as this is the only field users should be allowed to edit in this context. Opw-4757131 Forward-Port-Of: odoo/enterprise#89858
This update fixes an issue where the VAT summary report for Argentinian invoices was incorrectly calculating totals when multiple IIBB taxes were applied. The fix ensures that VAT amounts are counted accurately, matching the totals displayed in the accounting form. This improves the reliability of financial reporting for Argentinian customers.
Original PR description
**Issue** When using a VAT tax marked as price included, together with multiple IIBB taxes on the same invoice, the VAT summary report displays an incorrect total. Specifically, the VAT amount is…
**Issue** When using a VAT tax marked as price included, together with multiple IIBB taxes on the same invoice, the VAT summary report displays an incorrect total. Specifically, the VAT amount is counted multiple times, once for each IIBB tax, leading to an inflated total. **Steps to Reproduce** 1. Install the Accounting app and the Argentinian localization (l10n_ar) 2. Set the 21% VAT Purchase tax as Included in Price 3. Create a vendor bill applying the 21% VAT tax and at least two IIBB taxes 4. Open the VAT summary report for that bill Expected Behaviour: The total in the VAT summary should match the total shown in the accounting form view, with each tax counted only once. **Root Cause** The VAT summary report in the Argentinian localization relies on an SQL query to aggregate tax information for each `account.move`. The query joins `account_move_line` with `account_tax`, `account_tax_group`, and the many-to-many relation table `account_move_line_account_tax_rel`. Each `account_move_line` related to a VAT tax line (via `tax_line_id`) is joined with the `account_move_line_account_tax_rel` table. If that base line is related to multiple IIBB taxes, the join multiplies the VAT line once per IIBB tax since multiple matching rows exist. **Fix** The solution separates the logic for computing tax lines and base lines into two distinct subqueries. Each is aggregated independently to prevent duplication caused by one-to-many and many-to-many joins. The results are then joined using the unique `account_move_line.id`, ensuring each tax amount is counted exactly once in the final totals. opw-4776861 Forward-Port-Of: odoo/enterprise#97951 Forward-Port-Of: odoo/enterprise#85873
7 changes
Resolved issues and error corrections
This update fixes an issue preventing correct XML generation for Colombian e-invoices related to the 'INC Bolsas' plastic bags tax. The changes add a dedicated tax flow and ensure accurate reporting of this tax in the invoice XML, resolving DIAN validation errors and enabling successful invoice submissions.
Original PR description
Before PR: -The plastic bags tax (INC Bolsas) was not handled by a specific flow. -This resulted in incorrect XML generation for Colombian e-invoices, leading to validation errors from the DIAN. After PR: -Dedicated logic flow has been added to correctly handle the INC Bolsas tax. -Generated XML now correctly reports this tax in a separate `TaxTotal` block. -It populates the `BaseUnitMeasure` and `PerUnitAmount` fields with the fixed tax rate per bag. Impact: -Colombian e-invoices that include plastic bags tax are now generated correctly. -Ensures compliance with DIAN's specific requirements for this nominal tax. -Prevents validation errors and allows for successful submission of invoices containing this tax. task-5086926 Forward-Port-Of: odoo/enterprise#100391 Forward-Port-Of: odoo/enterprise#95311
This update fixes an issue where the IoT printer was still being used when both an IoT and ePos printer were set up. Now, the system automatically prioritizes the ePos printer, ensuring the correct printer is selected for the user's workflow. This improves the user experience and prevents errors.
Original PR description
When setting an IoT printer and an ePos printer, a message is displayed to inform the user the ePos printer will be used. However, this is not the case and the IoT printer is still loaded. We now avoid loading if there already is a printer. Forward-Port-Of: odoo/enterprise#101130
This update corrects issues in tax reporting for businesses using multiple companies within a shared tax unit. It ensures that OSS reports and domestic tax returns are correctly linked to the appropriate main company, resolving inconsistencies and improving data accuracy. This enhances compliance and reporting reliability.
Original PR description
This PR delivers multiple fixes to ensure consistent and accurate behavior when working with tax units across OSS and standard tax return reports: [FIX] l10n_eu_oss_reports: Correct Tax Unit…
This PR delivers multiple fixes to ensure consistent and accurate behavior when working with tax units across OSS and standard tax return reports: [FIX] l10n_eu_oss_reports: Correct Tax Unit Detection for OSS Reports OSS reports lack a country, causing _get_available_tax_units to return no results. As a consequence, only the environment's main company was considered. This fix ensures that when multiple companies belong to the same tax unit, their OSS reports are correctly consolidated under that shared unit. [FIX] account_reports: Link Tax Unit Returns to the Main Company When generating domestic tax returns for a company that is part of a tax unit, the main company of the unit should be used since it is responsible for filing. This update ensures tax return generation is always aligned with the appropriate main company. [FIX] account_reports: Enforce Main Company When Generating Report Options get_options previously relied on the order of companies within a tax unit, assuming the first entry was the main company. Because this order is not guaranteed, the call is now explicitly scoped using with_company to ensure the main company is always used when preparing report options. Forward-Port-Of: odoo/enterprise#99715
This update fixes a previous issue where the AI agent's transcription summaries weren't displayed in the user's preferred language. Now, the agent automatically generates summaries in the language selected for the transcription, ensuring a more natural and user-friendly experience. This change also applies to date formatting within the summaries.
Original PR description
This commit introduces a change that makes the agent produce a summary in the selected language from the transcription tab. It injects a specific prompt using the `currentLanguage` of the transcription the component. Instructing the LLM to generate in the proper language. Forward-Port-Of: odoo/enterprise#101075
This update enhances the bank reconciliation widget to accurately display early payment discounts (EPD) when batch payments are used, particularly with invoices linked to payments. It now correctly handles EPD calculations and displays the discount amount alongside the payment, ensuring accurate reconciliation and reporting of early payment benefits.
Original PR description
In the bank reconciliation widget, it is now possible to have batch payments containing payments linked to only invoice_ids. Such batch payment, once mounted in the widget, should reflect the invoice or move amounts of its payments, and not only the payments amount. In the case of a payment-invoice combo that's elligible for an early payment discount, the early payment discount should also be displayed in the widget. Example: Invoice of 1000$ with possible EPD of 2%. A payment (with no move) is done (paid in the "early" period) for 980$. The payment is then put into a batch payment. Once in the bank rec widget, when mounting the 980$ batch payment to a statement line of 980$, the widget should display it as a batch payment line of 1000$ and add another 20$ Early payment Discount line. task-4681366 Forward-Port-Of: odoo/enterprise#100533 Forward-Port-Of: odoo/enterprise#83077
This update enhances the performance of our reports by streamlining how cached data is handled. The team removed a technical detail that was causing issues with report caching, now managed entirely on the client-side. This results in faster report loading times and a smoother user experience.
Original PR description
This commit is needed by PR https://github.com/odoo/enterprise/pull/96946, which introduces a cache for rpc calls executed by the reports, like the one we use for views. When setting an option filter to value A, then switching to B and finally coming back to A, we'd expect the cache to work, and basically reload the original value computed for A instantly. It did not work because of the loading_call_number key, which was always set with a different value in the options dict. We now entirely remove the loading_call_number from the options, and don't pass it to the server at all. Instead, everything is handled js-side, with function parameters. In the meantime, we address some potential async issues in the reports' js code, essentially by reordering some lines or assigning return values to variables before calling await.
This update fixes a reporting issue by ensuring the NIF (tax identification number) is included in the BOE export for model 347 reports in Spain. This aligns with Spanish tax regulations (specifically pages 3 & 12 of document 347) and improves the accuracy of tax reporting data. Users are responsible for providing a correct VAT number.
Original PR description
[FIX] l10n_es_reports: include NIF in boe export for model 347 The NIF must be included in the BOE export for modelo 347 https://sede.agenciatributaria.gob.es/static_files/Sede/Disenyo_registro/DR_300_399/archivos/347.pdf pages 3 & 12. Before this commit, we read the vat but if it doesn't start with 'ES' we return an empty string because we based on TIN. Now we'll read the vat (without 'ES' if it starts with it). The user is responsible to fill a correct number in the vat field of the company. opw-5207241 Forward-Port-Of: odoo/enterprise#100489
7 changes
Resolved issues and error corrections
This update fixes an issue where Colombian e-invoices were failing validation due to incorrect tax reporting for plastic bags (INC Bolsas). The changes add specific logic to generate the correct XML format, ensuring compliance with DIAN requirements and allowing invoices with this tax to be successfully submitted.
Original PR description
Before PR: -The plastic bags tax (INC Bolsas) was not handled by a specific flow. -This resulted in incorrect XML generation for Colombian e-invoices, leading to validation errors from the DIAN. After PR: -Dedicated logic flow has been added to correctly handle the INC Bolsas tax. -Generated XML now correctly reports this tax in a separate `TaxTotal` block. -It populates the `BaseUnitMeasure` and `PerUnitAmount` fields with the fixed tax rate per bag. Impact: -Colombian e-invoices that include plastic bags tax are now generated correctly. -Ensures compliance with DIAN's specific requirements for this nominal tax. -Prevents validation errors and allows for successful submission of invoices containing this tax. task-5086926 Forward-Port-Of: odoo/enterprise#100391 Forward-Port-Of: odoo/enterprise#95311
This update fixes inconsistencies in how tax unit reports are generated, particularly for OSS reports. It ensures that multiple companies within a tax unit are correctly consolidated, and that tax returns are always linked to the appropriate main company, leading to more accurate financial reporting.
Original PR description
This PR delivers multiple fixes to ensure consistent and accurate behavior when working with tax units across OSS and standard tax return reports: [FIX] l10n_eu_oss_reports: Correct Tax Unit…
This PR delivers multiple fixes to ensure consistent and accurate behavior when working with tax units across OSS and standard tax return reports: [FIX] l10n_eu_oss_reports: Correct Tax Unit Detection for OSS Reports OSS reports lack a country, causing _get_available_tax_units to return no results. As a consequence, only the environment's main company was considered. This fix ensures that when multiple companies belong to the same tax unit, their OSS reports are correctly consolidated under that shared unit. [FIX] account_reports: Link Tax Unit Returns to the Main Company When generating domestic tax returns for a company that is part of a tax unit, the main company of the unit should be used since it is responsible for filing. This update ensures tax return generation is always aligned with the appropriate main company. [FIX] account_reports: Enforce Main Company When Generating Report Options get_options previously relied on the order of companies within a tax unit, assuming the first entry was the main company. Because this order is not guaranteed, the call is now explicitly scoped using with_company to ensure the main company is always used when preparing report options. Forward-Port-Of: odoo/enterprise#99715
This update restores automatic follower copying from parent sales orders to subscription renewals and upsells, aligning with expected business processes. Previously, this feature was removed for all users, but now it's specifically enabled for subscription-related orders. This ensures consistent tracking of customer relationships across the sales cycle.
Original PR description
In Odoo 18.2 (Task 4655022), automatic follower addition was removed for all users and limited to internal users. However, for subscriptions, it is logical to automatically copy followers from the parent sale order to renewal and upsell orders. This commit restores that behavior for subscription renewals and upsells while keeping the restriction for other record types. task - 5002181 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
An issue was preventing users from uploading attachments during e-learning reviews. This update resolves a bug that occurred after a specific code change, ensuring attachments are properly transmitted with the necessary access tokens. This improves the e-learning review process and prevents upload failures.
Original PR description
Bug === Since bf759408dd63b3d6004d588251acb7bcbd2e2dee when we upload an attachment with portal in a review in e-learning, an error is raised. Task-4687269
This update fixes an issue where cart notifications were incorrectly showing prices without tax, even when 'Tax Included' pricing was enabled. The fix ensures that notifications accurately reflect the total price, including taxes, for products with tax-included settings. This improves the customer experience and ensures accurate pricing information.
Original PR description
**Steps to reproduce:** * Install the **website_sale** module with demo data. * Go to *Website → Settings → eCommerce* and select **Tax Included**. * Create a product with specific **tax_ids** and…
**Steps to reproduce:** * Install the **website_sale** module with demo data. * Go to *Website → Settings → eCommerce* and select **Tax Included**. * Create a product with specific **tax_ids** and publish it on the website. * Navigate to *Website → Shop*, open the created product page. * Click **Add to Cart** to trigger the cart notification popup. * Observe the price displayed in the top-corner notification. **Observed behavior:** * The notification displays the **list price without tax**, even though *Tax Included* pricing is enabled. **Cause:** * The notification computes the price as *list_price × quantity* without checking whether taxes should be included or excluded. * Issue occur from this [commit](https://github.com/odoo/odoo/pull/184320/commits/04b7dc893039087e0f764e242c21076ce249bebf) **Fix:** * Add logic to detect whether prices should be shown tax-included or tax-excluded and assign the correct computed amount accordingly. --- opw-5350375 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update corrects a previous issue where an IoT printer was still loaded when both an IoT and ePos printer were set up. The system now automatically prioritizes the ePos printer, ensuring the correct printer is used as intended. This improves the user experience and prevents errors in order processing.
Original PR description
When setting an IoT printer and an ePos printer, a message is displayed to inform the user the ePos printer will be used. However, this is not the case and the IoT printer is still loaded. We now avoid loading if there already is a printer. Forward-Port-Of: odoo/enterprise#101130
This update resolves an issue where duplicate and incorrect account rules were being created during transfer record setup. By simplifying the rule creation process, the system now accurately assigns account IDs, improving data reliability and reducing potential errors in account transfers.
Original PR description
## Steps to reproduce: 1. Create a new transfer record 2. Add more than one account to the Accounts field or add a rule with condition on Account or remove account from an Account condition with multiple accounts set ... (various other actions when adding/removing accounts) ## Before: Redundant and incorrect rules are created and an incorrect value is assigned for account_ids due to the faulty sync between the two. ## After: Removing the onchange mechanism that creates the rule with condition on Account whenever an account is added to the Accounts field, this information is redundant for the user. Also removing the onchange mechanism of the reverse (adding accounts to the Accounts field when a rule with condition on Account is added) as it cannot account for nested rules and any/all conditions. opw - 5160635
9 changes
Resolved issues and error corrections
This update fixes an issue where failed quality checks didn't correctly move stock items to designated failure locations. The fix now triggers a wizard allowing users to confirm the failure and select the correct location, ensuring accurate tracking of quality issues within the stock management system. This improves data integrity and streamlines the process of handling defective products.
Original PR description
## Issue: When you use the Smart button `Quality Checks` on a `stock.move` to validate QC, marking a test as Fail doesn't move the `stock.move` to the failing location even if the QC is now failed…
## Issue: When you use the Smart button `Quality Checks` on a `stock.move` to validate QC, marking a test as Fail doesn't move the `stock.move` to the failing location even if the QC is now failed This affects all quantity-based checks (Measure or Pass/Fail) ## Cause: The `do_fail()` method marks the check as failed but does not call `_move_line_to_failure_location()`, so the move line stays in the original location ## Fix: Trigger the failure wizard when failing a QC via the buttons This allows the user to confirm the failure and select the appropriate failing location if multiple are configured ## Steps to reproduce: - Enable Storage Locations in Settings - Create a Product and a Quality Point (Product: Quality, Operations: Receipt, Control per: Quantity, Type: Measure, Tolerance: 0.0 to 1.0, Failure Locations: WH/Failure) - Create a New Receipt for the Product and Mark as Todo - Open 'Quality Checks' via the Smart button, select the QC, enter a measure value above the tolerance (e.g., 2.0), and click Measure. - The QC should be marked as failed - Before the fix, the details of the line in the Receipt doesn't change to the failing location You can also do the same flow with a QP of type Pass/Fail and the Fail button opw-4920391
This update fixes a bug that prevented homeworking locations from appearing in the month view calendar. The change ensures that locations are correctly displayed and interactable, mirroring the functionality in week and day views, improving the user experience for scheduling remote work. It also addresses an issue with grouped icons for similar locations.
Original PR description
Description of the issue/feature this PR addresses: After a refactor, the month view no longer displayed homeworking locations as in previous versions. This PR fixes the issue and adapts the…
Description of the issue/feature this PR addresses: After a refactor, the month view no longer displayed homeworking locations as in previous versions. This PR fixes the issue and adapts the component using the updated version of the FullCalendar library. Also fixes a small issue of when different locations with same icons are grouped together when they shouldn't Current behavior before PR: All days in the calendar month view displayed the 'Set location' button, regardless of whether a location record existed for the day or not. Locations of a different type sharing the same icon (Office, Building 1...): <img width="262" height="135" alt="before" src="https://github.com/user-attachments/assets/51745152-5f90-4917-9627-07aa0959eb3d" /> Desired behavior after PR is merged: Locations are shown in the month view, and can be interacted with in the same way as in the week/day views, both for single and multicalendar: <img width="1230" height="504" alt="multicalendar" src="https://github.com/user-attachments/assets/34108f57-2c25-400e-9fbe-106e2233c677" /> <img width="1232" height="382" alt="singlecalendar" src="https://github.com/user-attachments/assets/f4a0cf32-636f-49ce-a4cc-e53a9ac45643" /> Locations of a different type sharing the same icon: <img width="256" height="132" alt="after" src="https://github.com/user-attachments/assets/643dd304-aeeb-48ec-abef-755e3eb5fdf0" /> --- Task ID: 5215931
This update resolves an error that occurred when creating time off allocations with hourly schedules, specifically when all attendance entries had start and end dates. The fix prevents a division-by-zero error, ensuring time off allocations are created correctly. This addresses a technical issue related to how the system calculates hours for time off.
Original PR description
_ ## Short functional explanation of the error When creating a time off allocation with a time off type expressed in hours, and having start/end dates for every attendance in the corresponding…
_ ## Short functional explanation of the error When creating a time off allocation with a time off type expressed in hours, and having start/end dates for every attendance in the corresponding calendar, an error is raised. ## Reproduction Steps 1. Go to Employees and click on the Configuration tab > Working Schedules. 2. Click on a schedule and click on the button next to Work Entry Type to show the Starting date. 3. Set a starting date for each entry. 4. Go to Time Off. Click on the Configuration tab > Time Off Types. 5. Click on a time off and next to the Take Time Off in, select Hours. 6. Click on the Management tab > Allocations. Click on New. 7. Select an employee that has the schedule you updated earlier. ## Expected behavior The allocation is created. ## Unexpected Behavior A traceback occurs: ``` ZeroDivisionError: float division by zero ``` ## Origin of the issue When setting a start or/and an end date to an attendance, this attendance won't be taken into account for global attendances anymore. This leads to an erroneous computation of hours_per_day, leading to a few issues; one of them is related to time off allocation: When setting a time off with a time off type expressed in hours, if every single attendance in the calendar has a start/end date, there will be no global attendance hours left, leading to a division by 0: https://github.com/odoo/odoo/blob/8097b674a23858ed7692a0b30ca74419b8f890f7/addons/hr_holidays/models/hr_leave_allocation.py#L262 After discussion, we decided that this fix would only fix a symptom, and not the problem itself. _ opw-5340056 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue where adding a product with duplicate attribute values to a sales order would cause a system error. The fix ensures correct handling of product variants with multiple attribute selections, preventing crashes and improving order creation stability. This impacts users creating and managing sales orders.
Original PR description
## Versions 18.0 to saas-18.3 Fixed by 7b56a6afda919f3c09d08eb1256416e0a2b4b1d9 introducing a new logic with…
## Versions
18.0 to saas-18.3
Fixed by 7b56a6afda919f3c09d08eb1256416e0a2b4b1d9 introducing a new logic with https://github.com/odoo/odoo/blob/26f9cab34a8cd594192d9e2a844494196b9ca5b6/addons/sale/controllers/product_configurator.py#L329
## Issue
Duplicating an attribute on a product leads to a traceback when adding the product to a SO.
## Steps to reproduce
*Ensure variants are activated in the settings*
- Create a new test product:
- Attributes & Variants (on 2 distinct lines):
- "Brand": 1;
- "Brand": 2 & 3.
- Create a new SO:
- Add the test product.
## Cause
The product has 2 attribute lines referring to the same attribute. As both attribute lines point to the same attribute, `ptals.attribute_id.read()` returns only one value for two ptals. The `zip()` call therefore drops the extra ptal, producing an incomplete mapping. When the configurator later tries to access this missing ptal entry, it crashes https://github.com/odoo/odoo/blob/369ca1e5a154235e80b9ea6af7b3f10442c0939f/addons/sale/controllers/product_configurator.py#L321.
opw-5373672This update fixes an issue where Express Checkout with Stripe wasn't automatically applying the correct tax based on the customer's address. Now, the system correctly identifies and applies the fiscal position, eliminating the need for a page reload to see accurate pricing and taxes for users utilizing this payment method. This ensures consistent and accurate tax calculations for eCommerce transactions.
Original PR description
## Issue: When a fiscal position should apply based on the address provided during Express Checkout, it was not applied automatically The correct fiscal position only appeared after reloading the checkout page This issue affects public users using the eCommerce with Stripe Express Checkout ## Cause: The fiscal position was correctly determined during the `availableCarriers` computation, but it was not propagated to the payment request itself As a result, prices and taxes were only updated after a full page reload ## Steps to reproduce: - Configure Stripe with Express Checkout (e.g., Google Pay) - Create a fiscal position with automatic detection (Country = US, Tax mapping: 15% → 0%) - Create a product using the 15% tax - Go to the website shop and add the product to the cart - Use Express Checkout with a US address - Observe that the fiscal position is not applied unless the page is reloaded opw-5018238 Forward-Port-Of: odoo/odoo#236832
This update ensures the NIF (tax identification number) is now included in the BOE export for model 347 reports, as required by Spanish tax regulations. The system now correctly extracts the VAT number (without the 'ES' prefix) and relies on user-provided NIF data for accurate reporting. Users are responsible for providing a valid NIF number.
Original PR description
[FIX] l10n_es_reports: include NIF in boe export for model 347 The NIF must be included in the BOE export for modelo 347 https://sede.agenciatributaria.gob.es/static_files/Sede/Disenyo_registro/DR_300_399/archivos/347.pdf pages 3 & 12. Before this commit, we read the vat but if it doesn't start with 'ES' we return an empty string because we based on TIN. Now we'll read the vat (without 'ES' if it starts with it). The user is responsible to fill a correct number in the vat field of the company. opw-5207241 Forward-Port-Of: odoo/enterprise#100489
This update resolves an issue where a custom override in the l10n_dk_nemhandel module was causing compatibility problems with other Odoo localizations. The change now ensures that the Danish-specific logic is applied only for Danish partners, maintaining the standard Peppol flow for other regions. This prevents disruptions to the core Peppol integration.
Original PR description
Before: - The l10n_dk_nemhandel override of _check_document_type_support replaced the generic Peppol logic and did not accept process_type, causing errors when other localizations relied on the base method. After: - Aligned the method and applied the DK-specific logic only for Danish partners, falling back to the generic Peppol behavior otherwise. Impact: - Prevents unintended overrides towards standard Peppol flow.
This update ensures that bills received through the PEPPOL network are automatically posted to the accounting system, even when auto-post functionality is enabled for the partner. Previously, these bills remained in a draft state, requiring manual processing. This change streamlines the accounting workflow for PEPPOL transactions.
Original PR description
Currently, even if a partner has auto-post bills enabled, the incoming bills stay in the draft state. This change addresses that issue. Task-5373302 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue where the keyboard unexpectedly opened on mobile date/datetime fields, causing a poor user experience. The change now prevents the keyboard from appearing and hides the cursor, resulting in a smoother and more intuitive date selection on mobile devices.
Original PR description
Before this commit:
- The cursor was shown inside the date/datetime input field on mobile,
which triggered the keyboard unnecessarily and degraded the user
experience.
Steps to reproduce:
1. Add a form snippet.
2. Add a Date/Datetime field.
3. Click on the Date field.
- The virtual keyboard appears and the datepicker popover may be
clipped or partially hidden.
After this commit:
- The virtual keyboard is now prevented from opening on date/datetime
inputs, and the text cursor within these fields is also hidden.
task-[4745714](https://www.odoo.com/odoo/project/974/tasks/4745714)
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#2120533 changes
Resolved issues and error corrections
This update introduces a command-line option to prevent Odoo from automatically installing modules during upgrades. This addresses a complex issue where outdated databases can cause upgrade failures and business logic problems. The new feature provides greater control over the upgrade process.
Original PR description
In some case, a database can be in a state where some auto install module are not installed - when the user uninstall a module - when module was added in stable and a database was created before the…
In some case, a database can be in a state where some auto install module are not installed - when the user uninstall a module - when module was added in stable and a database was created before the addition. It can lead to issues where an upgrade fails or some business logic does not work as expected because of the missing modules. This is not easy to reproduce and to test, even if uninstalling such module should in theory work and be tested. This pr proposes to add a flag "--skip-auto-install" to the config to be able to disable all auto install of modules. It is open to discussion to change this to a config option, with or without a module list **Initial solution (alternative to avoid a config)** --dev skipautoinstall **Current solutions** (command line param) --skip-auto-install **Maybe in the future but unlikely** (more flexible) --skip-auto-install=all --skip-auto-install=web_enterprise,iap (krma suggestions) --skip-auto-install=* --skip-auto-install=web_*,iap Those two last one could be more flexible but the use case are limited and can be done another way with an explicit -i, maybe no worth the additional complexity (mainly since we need to filter in two different places) Note that this pr uses **get** on the config just in case the config is monkey patched somewhere to make it more robust.
This update increases the time allowed for sending log data from the IoT box to the database, resolving previous issues that caused frequent errors. The change extends the timeout to 10 seconds and adjusts the log sending frequency to 12 seconds, ensuring more reliable data transmission and reducing disruptions.
Original PR description
Currently the request to send logs to the db from the iot box is at 0.5s timeout. This leads to many exceptions and failed requests. This commit sets the timeout for such requests to 10s (previously 0 5s) and the frequency of sending logs to every 12s (previously 0.5s)
This update resolves a bug where the aged receivable report wasn't displaying invoices correctly when the invoice due date was removed. The fix ensures consistent data retrieval by aligning the report's query with the invoice data, preventing inaccurate report results. This improves the reliability of financial reporting.
Original PR description
step to reproduce: - create a invoice and confirm it - remove due date from it and save it - ensure the confirmed invoice do not payment term or due date - open aged receivable report - open this…
step to reproduce: - create a invoice and confirm it - remove due date from it and save it - ensure the confirmed invoice do not payment term or due date - open aged receivable report - open this entry <img width="1599" height="238" alt="image" src="https://github.com/user-attachments/assets/010f97f4-0d50-4e5a-9366-ae67d17e2bb7" /> Observation: - on clicking the entry, when redirected to list view, there are `0` records. Issue: - The query which is used to display data on report uses `COALESCE(account_move_line.date_maturity, account_move_line.date)` https://github.com/odoo/enterprise/blob/ffc329e4ff2bd6512164ecd4206210fd5c9264b9/account_reports/models/account_aged_partner_balance.py#L222-L226 - while the method `_build_domain_from_period` uses only `date_maturity` in domain redirecting to list view - This creates inconsistencies between two. https://github.com/odoo/enterprise/blob/ffc329e4ff2bd6512164ecd4206210fd5c9264b9/account_reports/models/account_aged_partner_balance.py#L383-L394 opw-5237298