Thursday, March 26, 2026
12 changes · 18.0
Enhancements to existing features
This update allows users to manually upload CL EDI invoices through a new system, streamlining invoice processing. The system now also automatically extracts specific fuel taxes from these invoices, improving accuracy and reducing manual data entry. This enhancement supports compliance with Chilean regulations.
Original PR description
- Adding the functionality of manually uploading CL EDI documents through fetchmail_server functions. Unrecognized documents are parsed as vendor bills. - Adjusting fetchmail_server behavior to read specific fuel taxes from vendor bills. Can be extended for other taxes. task-4259393
This update enhances budget reporting by automatically including asset accounts (current, non-current, and fixed) in budget tracking. Previously, budget reports only considered expense accounts. This change provides a more complete view of financial performance and allows for better asset management within the Odoo Enterprise system.
Original PR description
Expand the scope of budget tracking to include asset accounts. Modified the account filtering logic so that when a budget type is set to "Expenses" or "Both", the query includes 'asset_current', 'asset_non_current', and 'asset_fixed' account types. task-5994048
Resolved issues and error corrections
This update corrects a calculation error in payslips for employees using the UAE Monthly pay structure, specifically related to paid leave. The fix ensures accurate hourly wage calculations by preventing data from previous payslips from being incorrectly included in the current calculation. This improves payroll accuracy for UAE-based employees.
Original PR description
### Steps to reproduce: - Install the l10n_ae_hr_payroll module. - Configure at least two employees, who'll use the UAE Monthly pay structure. - On at least one of the employees, set the work entry…
### Steps to reproduce: - Install the l10n_ae_hr_payroll module. - Configure at least two employees, who'll use the UAE Monthly pay structure. - On at least one of the employees, set the work entry source to attendance. - Register a paid leave time off entry, for the employee whose work entry source is set to attendance. - Compute a payslip batch using the UAE Monthly pay structure. - Go to the payslip of the employee with the work entry source set to attendance and compute the sheet again. - The 'Paid Leave' salary rule results, will change given that the computation of the field l10n_ae_hourly_wage is different when the computation is done for batches and individually. ### Cause: In 'Paid Leave' rule we use l10n_ae_hourly_wage to compute its result and while computing this field we use self.worked_days_line_ids instead of record inside the loop. This leads to an issue when self has more than one payslip it will take into account all the worked days for each payslip for different employees ### Fix: We use record instead of self to avoid taking other payslips into consideration while computing the hourly wage. opw-5979631
This update resolves an issue preventing SBR tax reports from being submitted due to incorrect date formatting and overly long consultant descriptions. The commit restores the original date format and limits the consultant description to the abbreviation, ensuring compliance with validation requirements and successful report submission.
Original PR description
Description of the issue this commit addresses: During the tax return flow for the SBR development[^1], we discovered that the date format for the "DateTimeCreation" node had been wrongly readjusted and that the "ProfessionalAssociationForTaxServiceProvidersName" content could be too long due to showing the entire description. Those two issue cause the file to be rejected and make submission impossible. [^1]: https://www.odoo.com/odoo/967/tasks/6034675 --- Desired behavior after this commit is merged: This commit reintroduces the old DateTimeCreation format which is the only one that passes the tests done on the xbrl validation service[^2] and replaces the ProfessionalAssociationForTaxServiceProvidersName's value for the abreviation of the order instead of the entire description. [^2]: https://aansluiten.procesinfrastructuur.nl/site/validaties-digipoort/xbrl-validatie --- task-none Forward-Port-Of: odoo/enterprise#111923 Forward-Port-Of: odoo/enterprise#111817
This update corrects a previous issue where negative partner totals were incorrectly hidden and failed to account for sales transactions in Spanish tax reports. Now, all partner totals (positive or negative) are accurately displayed, and insurance operations are correctly categorized and reported from both sales and purchase journals.
Original PR description
Before this PR: - Partners were only shown if their total was positive and above 3,005.06 €. Negative totals were hidden, even if they were lower than -3,005.06 €. - Insurance operations only took Purchase journal amounts into account. Amounts from Sales journals were ignored, and there was no distinction between the two types of operations. After this PR: - The report now uses the absolute value of the total. Partners with amounts exceeding 3,005.06 €, whether positive or negative, are now shown correctly. - Insurance operations are now divided into two distinct sections: Sales and Purchases. Amounts from both Sales and Purchase journals are now correctly taken into account and reported in their respective sections. task-5214023 Forward-Port-Of: odoo/enterprise#100413
This update ensures Odoo correctly processes PEPPOL BIS3 invoices (SE-R-005) according to international standards. The fix adds the necessary rule to the system's helpers, addressing a previous omission and improving compliance with regulatory requirements. This change is part of ongoing efforts to support international trade and financial transactions.
Original PR description
After this commit 9cb237d, the rule was added, but from 18.0 and upper the old helps has been deprecated and removed on saas~18.4. With this commit, we add the rule also to the new helpers. OPW-5881918 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves issues preventing invoices with early payment discounts (EPD) from correctly generating Peppol XML files. Specifically, it corrects errors related to tax categorization and allowance amounts, ensuring compliance with Peppol standards and successful submission of invoices.
Original PR description
Steps to reproduce: - Create a payment term with a 1% early discount and Reduced Tax Always (applied upon invoice) - Add an invoice line with 0% taxes and try to submit it to Peppol - Check the XML…
Steps to reproduce: - Create a payment term with a 1% early discount and Reduced Tax Always (applied upon invoice) - Add an invoice line with 0% taxes and try to submit it to Peppol - Check the XML and you will see two errors (https://peppol-ap.test.odoo.com/filevalidator/validate): [BR-E-01]-An Invoice that contains an Invoice line (BG-25), a Document level allowance (BG-20) or a Document level charge (BG-21) where the VAT category code (BT-151, BT-95 or BT-102) is "Exempt from VAT" shall contain exactly one VAT breakdown (BG-23) with the VAT category code (BT-118) equal to "Exempt from VAT". [BR-E-08]-In a VAT breakdown (BG-23) where the VAT category code (BT-118) is "Exempt from VAT" the VAT category taxable amount (BT-116) shall equal the sum of Invoice line net amounts (BT-131) minus the sum of Document level allowance amounts (BT-92) plus the sum of Document level charge amounts (BT-99) where the VAT category codes (BT-151, BT-95, BT-102) are "Exempt from VAT". When generating an invoice with an EPD (early payment discount), three lines are generated: the base line, a positive EPD line, and a negative EPD line. Only the base line and the positive EPD line have associated tax data. What causes these errors is the fact that, in the Peppol XML, there are two TaxSubtotal nodes with the TaxCategory E (Exempt from tax). This happens because the negative EPD line is not concatenated with the base line and the positive EPD line. The concatenation is done in the method _ubl_add_tax_totals_nodes. The negative epd was not merged because it had a different tax exemption reason: Articles 226 items 11 to 15 Directive 2006/112/EN instead of Exempt from tax This commit also fix another issue related to the AllowanceTotalAmount: If the allowance was [0.0] (and not [] which happens in case like the one above) the node was not added to the xml which resulted in the following error: Sum of allowances on document level (BT-107) = Σ Document level allowance amount (BT-92). opw-5896348 --- 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 invoices with 0% taxes incorrectly displayed "Not subject to VAT" in XML reports. It now accurately reflects zero-rated, exempt, and zero-rated export taxes, ensuring compliance with Saudi regulations and preventing misleading VAT data. This improves data accuracy and reduces potential compliance risks.
Original PR description
Issue: - The field `l10n_sa_exemption_reason_code` was not mapped for zero-rated, zero-rated export, and exempt taxes. - As a result, invoices using 0% taxes incorrectly showed "Not subject to VAT" in the XML, which misrepresented the actual nature of the supply. Imp: - Added new zero-rated and exempt taxes with proper ZATCA/UN CEFACT codes. - Kept legacy 0% taxes unchanged for backward compatibility. - Added Invoice Legal notes to make exemption reason visible in pdf also. - Improved error spacing and removed redundant comma text. Impact: - Ensures full compliance with ZATCA XML standards. - Prevents misleading VAT data representation. Backport of https://github.com/odoo/odoo/pull/234096 taskID-5494997 Forward-Port-Of: odoo/odoo#244656
This update ensures that customers cannot successfully pay for quotations through the portal or payment links if the quotation includes expired promotions. This prevents incorrect payments and maintains accurate sales records, improving the overall customer experience. The change addresses a potential issue where expired promotions could lead to payment processing errors.
Original PR description
Paying for a quotation in the portal should fail if a quotation contains expired promotions. This also applies to payment links. opw-5150616
This update corrects a problem where changes to country names in the `l10n_pe` or `l10n_ec` modules (e.g., renaming 'Peru' to 'PERÚ') caused module upgrades to fail. The fix replaces country names with stable, unique identifiers (XMLIDs) to ensure reliable data resolution during upgrades.
Original PR description
### Steps to reproduce ------------------ - Install `l10n_pe` or `l10n_ec` module. - Go to *Settings → Countries* and rename the country (e.g. "Peru" → "PERÚ", "Ecuador" → "ECUADOR"). - Upgrade the…
### Steps to reproduce
------------------
- Install `l10n_pe` or `l10n_ec` module.
- Go to *Settings → Countries* and rename the country (e.g. "Peru" → "PERÚ",
"Ecuador" → "ECUADOR").
- Upgrade the module.
### Issue
-----
The files `l10n_pe/data/res.bank.csv` and `l10n_ec/data/res.bank.csv`
reference countries using their names (e.g. "Peru", "Ecuador").
During module upgrade, the CSV import resolves many2one relations using
the country name. If the country name has been modified by the user,
the lookup fails and the module upgrade crashes with:
```python3
2026-03-06 23:48:11,112 27 CRITICAL db_3950261 odoo.service.server: Failed to initialize database `db_3950261`.
Traceback (most recent call last):
File "/home/odoo/src/odoo/19.0/odoo/service/server.py", line 1510, in preload_registries
registry = Registry.new(dbname, update_module=update_module, install_modules=config['init'], upgrade_modules=config['update'], reinit_modules=config['reinit'])
File "/home/odoo/src/odoo/19.0/odoo/tools/func.py", line 88, in locked
return func(inst, *args, **kwargs)
File "/home/odoo/src/odoo/19.0/odoo/orm/registry.py", line 199, in new
load_modules(
File "/home/odoo/src/odoo/19.0/odoo/modules/loading.py", line 456, in load_modules
load_module_graph(
File "/home/odoo/src/odoo/19.0/odoo/modules/loading.py", line 216, in load_module_graph
load_data(env, idref, mode, kind='data', package=package)
File "/home/odoo/src/odoo/19.0/odoo/modules/loading.py", line 59, in load_data
convert_file(env, package.name, filename, idref, mode, noupdate=kind == 'demo')
File "/home/odoo/src/odoo/19.0/odoo/tools/convert.py", line 689, in convert_file
convert_csv_import(env, module, pathname, fp.read(), idref, mode, noupdate)
File "/home/odoo/src/odoo/19.0/odoo/tools/convert.py", line 754, in convert_csv_import
raise Exception(env._(
Exception: Module loading l10n_pe failed: file l10n_pe/data/res.bank.csv could not be processed:
No matching record found for name 'Peru' in field 'Country'
No matching record found for name 'Peru' in field 'Country'
No matching record found for name 'Peru' in field 'Country'
No matching record found for name 'Peru' in field 'Country'
No matching record found for name 'Peru' in field 'Country'
No matching record found for name 'Peru' in field 'Country'
No matching record found for name 'Peru' in field 'Country'
No matching record found for name 'Peru' in field 'Country'
No matching record found for name 'Peru' in field 'Country'
No matching record found for name 'Peru' in field 'Country'
No matching record found for name 'Peru' in field 'Country'
No matching record found for name 'Peru' in field 'Country'
No matching record found for name 'Peru' in field 'Country'
No matching record found for name 'Peru' in field 'Country'
No matching record found for name 'Peru' in field 'Country'
No matching record found for name 'Peru' in field 'Country'
No matching record found for name 'Peru' in field 'Country'
No matching record found for name 'Peru' in field 'Country'
select id,name,code from res_country where code='PE'
+-----+----------------------------------------------------------------------+------+
| id | name | code |
|-----+----------------------------------------------------------------------+------|
| 173 | {"de_DE": "Peru", "en_US": "PERÚ", "es_ES": "PERÚ", "es_PE": "Perú"} | PE |
+-----+----------------------------------------------------------------------+------+
```
### Root Cause
----------
Using translatable/display names in CSV data is not reliable, as these
values can be customized or translated.
### Fix
---
Replace country name references with stable XMLIDs:
- `base.pe` for Peru
- `base.ec` for Ecuador
Using XMLIDs ensures consistent resolution regardless of name changes
or translations.
opw-6015302
upg-3950261
tbg-2492
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#254096This update resolves a bug that caused errors when creating payments linked to expenses paid by a 'Branch' company. The fix ensures the payment journal entry correctly uses the 'Branch' company, preventing conflicts with the parent company's accounting. This improves the accuracy of expense reporting and payment processing for Branch operations.
Original PR description
**Steps to reproduce:** - Install Accounting and Expenses - Create a Branch company (e.g. Branch) - In company selector, select both Branch (as main) and its parent - In Bank journal settings, make…
**Steps to reproduce:** - Install Accounting and Expenses - Create a Branch company (e.g. Branch) - In company selector, select both Branch (as main) and its parent - In Bank journal settings, make sure that there is an outstanding payment account for "Manual Payment" - Create an employee in Branch - Create an expense: * Category: [any] (e.g. [EXP_GEN] Expenses) * Total: [anything] (e.g. 100.00) * Employee: [the created employee] * Paid By: company * Company: Branch - Create Report - Submit to Manager - Approve **Issue:** A UserError is raised because it tries to create a payment in Branch linked to a journal entry in the parent company. **Cause:** The payment is initialized with the company of the expense but not the related journal entry. **(A similar issue happens with an expense paid by the employee when generating the bill upon approval of the expense sheet)** opw-6007859 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update ensures that customer invoices can be properly updated by regenerating the XML file during import. Previously, reusing the original imported XML caused issues when invoices were modified. This change guarantees accurate invoice XML generation for customer invoices, improving data integrity.
Original PR description
Problem --------- Currently, when importing a move, `ubl_cii_xml_file` gets set with said XML. This XML is then re-used during the export rather that regenerate a new XML each time. This is fine for customer bills as those are not meant to be modified. This is not the case of customer invoices. Client may import an invoice XML and later update that invoice. In such a case, we want to regenerate the XML and not reuse the imported version. Solution --------- Only set `ubl_cii_xml_file` for purchase move during the import. no-task --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr