Wednesday, September 2, 2026
13 changes · 18.0
Enhancements to existing features
Luxembourg payroll settings have been updated to reflect 2026 legal and tax parameter changes. This helps ensure payroll calculations use the latest retirement, accident insurance, employer mutuality, minimum wage, and tax credit values.
Original PR description
Update the retirement fund contribution rate (8% -> 8.5%, pension reform), the accident insurance rate (0.7% -> 0.65%), the mutuality of employers class rates, the minimal social pay following the June 2026 index bracket, and the CI-CO2 tax credit amounts (CIS/CIP) for tax year 2026.
Ecuadorian electronic invoices and delivery guides can now include the RUC of the third-party billing software provider, as required by SRI regulations. Users can enter this value in Invoicing settings, and it will be automatically sent electronically and shown on printed documents.
Original PR description
Purpose: SRI Resolution requires taxpayers using 3rd-party billing software in Ecuador to report the software provider's RUC on all electronic documents and printed representations (RIDE). A new system parameter is introduced and displayed in Invoicing > Setting > Ecuadorian Localization > Electronic Invoicing, so users can add their software provider's RUC. This value will be automatically sent to the EDI and displayed on the report. task-6432810 Forward-Port-Of: odoo/enterprise#129456
Resolved issues and error corrections
French point-of-sale sales that encounter missing e-invoicing data now download a regular invoice instead of an incorrect pro-forma document. This keeps checkout moving while avoiding confusion for customers and staff; no external e-invoicing submission is made when required data is missing.
Original PR description
## Steps to reproduce: - Create a customer with France E-Invoicing (UBL2.1) as eInvoice format in a French company - Go to the PoS, select that partner - Make a sale and ask for an invoice - The…
## Steps to reproduce: - Create a customer with France E-Invoicing (UBL2.1) as eInvoice format in a French company - Go to the PoS, select that partner - Make a sale and ask for an invoice - The downloaded invoice will be a pro-forma invoice ## Why the fix: The pro-forma should not be used here, it is because it is used as a fallback when we get an error while trying to print the invoice. https://github.com/odoo/odoo/blob/4a508586970e44367bbdbbb3cbe88ffb5a1eadb7/addons/account/models/account_move.py#L6187-L6204 As we get an error while trying to send the data with this setup, it goes to the fallback and prints a pro-forma invoice, even though this should not be the case, a regular invoice would do. This happens because when an error is found, we do not populate invoice_pdf_report_id, so it goes to the fallback. We now check if there are any errors in the order, and if there are and the customer requests an ubl_21_fr invoice, we just print the invoice as it is, without going to the pro-forma fallback, as this is not the intended flow. With this fix, we now have the same flow as we do in the sales module, that allows the sale even if the customer has missing data. It will just print the invoice and allow the sale but won't send anything to external entities. opw-6428369
This fixes a crash that could occur when generating electronic invoice files in Odoo Community without the Enterprise accounting add-on installed. The change safely checks whether deferred billing date fields are available before using them, improving reliability for Community users.
Original PR description
The fields `deferred_start_date` and `deferred_end_date` are created by the enterprise addon `account_accountant`, so not having it installed, this crashes with:
```
File "/opt/odoo/auto/addons/account_edi_ubl_cii/models/account_edi_cii.py", line 684, in <listcomp>
billing_start_dates += [move_line.deferred_start_date for move_line in invoice.invoice_line_ids if move_line.deferred_start_date]
AttributeError: 'account.move.line' object has no attribute 'deferred_start_date'
```
This PR protects the access to these fields checking first if they exist.
Bug introduced in the refactoring in #261572.
@Tecnativa TT64359The Helpdesk SLA Status Analysis report now calculates Hours Open from ticket creation to closure, matching the Ticket Analysis report. This gives managers consistent and accurate visibility into how long tickets stayed open, rather than confusing it with time to assignment.
Original PR description
1. Open Helpdesk > Tickets and create a ticket on the team "Customer Care", assigned to yourself 2. More than an hour later, move it to the "Solved" stage to close it 3. Open Helpdesk > Reporting > Ticket Analysis, switch to the pivot view and pick the "Hours Open" measure -> the ticket holds the hour it stayed open 4. Open Helpdesk > Reporting > SLA Status Analysis and pick the "Hours Open" measure as well -> the ticket holds nothing, as it was assigned as soon as it was created odoo/enterprise#47454 added the "Hours Open" measure of the ticket analysis to the SLA status analysis, but computes it up to the assignment date instead of the closing date. The measure therefore holds the hours until the ticket was assigned, which the report already offers as "Working Hours to Assign". With this commit, both reports count the hours from the creation of the ticket to its closing.
Creating multiple helpdesk teams with website forms enabled no longer creates duplicate Help menu entries on the website. The system now reuses the existing Help menu for the same website and only removes it when no team still needs it, keeping website navigation clean and consistent.
Original PR description
Currently on creating new helpdesk team everytime a new website menu is created. ### **Steps to Reproduce:** 1) Install website_helpdesk 2) Navigate to `Helpdesk>Configuration>Helpdesk Team`. 3)…
Currently on creating new helpdesk team everytime a new website menu is created. ### **Steps to Reproduce:** 1) Install website_helpdesk 2) Navigate to `Helpdesk>Configuration>Helpdesk Team`. 3) Create 2 helpdesk team with `Website Form` option enable. 4) Navigate to Website. ### **Observed Behavior:** Two Help menus are created. ### **Expected Behavior:** Multiple menus should not be created. ### **Root Cause:** The menu creation logic relies on the following [condition](https://github.com/odoo/enterprise/blob/b66097122ba3a758734ac6fb2b26579c35cb72c2/website_helpdesk/models/helpdesk.py#L111-L112) `team_count_by_website` is built from `_read_group(..., ['website_id'], ...)`, which keys its result by the `website_id` *recordset*, not its id. Looking it up with `team_count_by_website.get(website.id, 0)` therefore always misses and falls back to `0`, so `team_count <= 1` is always `True` regardless of how many teams already exist for that website. The only thing left guarding menu creation is `any(team.website_menu_id for team in teams)`, which only looks at the teams in the current create/write call, not every team on that website. So saving a second team in a separate call always creates another menu. ### Fix: Make the website menu a resource shared by every team with the website form enabled on a given website, instead of "owned" by whichever team created it: - Before creating a new menu, look up other teams (active or archived) that already point to a menu, matched through the `website_menu_id` relation between teams rather than a hardcoded `/helpdesk` URL, so a customized menu URL doesn't cause a duplicate to be created. Reuse that menu when found. - Only delete a menu once no team (active or archived) still references it, checked before removing a team's own reference. **opw-6303846**
Point of Sale prices now correctly include product variant extra charges when using a pricelist that is based on another pricelist. This prevents undercharging at checkout when discounts or derived pricelists are applied to products with paid variants.
Original PR description
## Steps to reproduce: - Create a product, with never variant, the variant has an extra price of 100 - Make Pricelist 1, just leave it as default - Make Pricelist 2, make it a discount, based on Pricelist 1, for all products - Go to the PoS, click on the created product - Change the pricelist to Pricelist 2 -> the price does not take the extra price into account ## Why the fix: When we have a pricelist based on another pricelist, we recursively calculate the price on the base pricelist. Before this commit, in the recursive call, we gave 0 as the extra price. We now give the extra price in the recursive function call. opw-6500086
This fixes analytic plan applicability so company-specific invoice rules no longer override the default setting in areas like Work Centers or Employees. Users will see the expected analytic distribution requirement, preventing misleading mandatory fields outside the intended accounting context.
Original PR description
### Issue: When an analytic plan has applicability lines with a company filter, the applicability is incorrectly applied on views that do not define a `business_domain`, such as Work Centers or…
### Issue: When an analytic plan has applicability lines with a company filter, the applicability is incorrectly applied on views that do not define a `business_domain`, such as Work Centers or Employee views For example, if a plan has: - Default Applicability: Unavailable - A line with Domain: Invoice, Company: My Company, Applicability: Mandatory Opening the analytic distribution on a Work Center shows `Mandatory` instead of the default `Unavailable` ### Cause: In commit https://github.com/odoo/odoo/commit/ffcf2ee1a3185ef73db93bfd95625844506692c5 `_get_score` was updated to return `0.5` when the applicability line's company matches the caller's company, even when no `business_domain` is provided In `_get_applicability`, the loop selects the first rule whose score exceeds the current minimum, which starts at `0`: https://github.com/odoo/odoo/blob/710e056e5171af2ab72d7d7793da3518f12faf5e/addons/analytic/models/analytic_plan.py#L255-L264 A score of `0.5` is enough to win over the default applicability, so a company-only match on a domain-specific rule incorrectly overrides the default when no `business_domain` is passed ### Steps to reproduce: - Install `mrp` and `accountant` with demo data - Enable Analytic Accounting in Settings - Open the Internal analytic plan and edit its applicability line: -- Remove the account prefix -- Default Applicability: Unavailable -- Domain: Invoice, Company: My Company (SF), Applicability: Mandatory - Go to Manufacturing > Configuration > Work Centers - Open any work center and click on Analytic Distribution Before the fix, Internal is shown as Mandatory instead of Unavailable Removing the company from the applicability line confirms the issue opw-6404884
This fix prevents the Polish bank verification module from recalculating existing payments during installation. It helps large databases install or update the module without crashing, improving reliability for businesses with many payment records.
Original PR description
account.payment model computes every record l10n_pl_verification_id at module installation (l10n_pl_bank_verification), causing crash in case of db with a large number of records wrong method name correction: _auto_init instead of init and call super after creating the db column see odoo/odoo#282504
This fixes a crash when exporting Factur-X invoices in Odoo Community where certain Enterprise-only accounting date fields are not available. It restores compatibility for Community users and prevents related localization test failures from blocking work.
Original PR description
`_cii_get_billing_specified_period_node` reads `deferred_start_date` and `deferred_end_date` directly, but those fields only exist when the enterprise accounting app is installed. Exporting Factur-X…
`_cii_get_billing_specified_period_node` reads `deferred_start_date` and `deferred_end_date` directly, but those fields only exist when the enterprise accounting app is installed. Exporting Factur-X on Community raises:
```
AttributeError: 'account.move.line' object has no attribute 'deferred_start_date'
```
This currently breaks the CI of OCA/l10n-spain on 18.0: every pull request errors in the `l10n_es_facturae_face` and `l10n_es_pos_sii` tests.
Introduced in 9fc11bbc9 (`[REF] account_edi_ubl_cii, *: refactoring of the export of factur-x`), which rewrote this code into the new `account_edi_cii.py`. The code it replaced did guard the fields, as the rest of the module still does:
- [`account_edi_xml_cii_facturx.py:209`](https://github.com/odoo/odoo/blob/167e83374756c4c38bc46eb96763dfbd8cb8de6f/addons/account_edi_ubl_cii/models/account_edi_xml_cii_facturx.py#L209) -> `line._fields.get('deferred_start_date')`
- [`account_edi_ubl.py:1277`](https://github.com/odoo/odoo/blob/167e83374756c4c38bc46eb96763dfbd8cb8de6f/addons/account_edi_ubl_cii/models/account_edi_ubl.py#L1277) -> `base_line.get('deferred_start_date')`
Same guard applied here.This fixes how financial reports count grouped records when preparing report data. It helps ensure report figures are accurate and avoids misleading totals in accounting reports.
Original PR description
… in SQL query
Fixed an issue in the demo payment provider where refunds after a manually captured payment could remain stuck as only authorized. This prevents blocked refund flows and incorrect negative authorized amounts during demo payment testing.
Original PR description
Issue: --- When using manual capture, you can refund the transaction but it will be only authorized, and you'll then be blocked with a negative authorized amount and the impossibility to refund it. This seems to be specific to demo payment provider. Steps: 1- Enable manual capture on demo provider. 2- Buy a product from shop and checkout and pay. 3- Capture the payment in backend. Then click on post process. 4- Try refund. opw-6413515 Forward-Port-Of: odoo/odoo#282315
This fixes an issue where selecting a website theme during setup did not update key design elements like the header and footer. Businesses using the website configurator should now see their chosen theme applied reliably when building or refreshing a site.
Original PR description
--- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#283174