Saturday, August 22, 2026
14 changes · 19.0
New functionality added to Odoo
This pull request introduces the foundation for an AI-assisted invoice processing flow that can scan invoices, extract details, validate them, and prepare draft vendor bills. It also adds supporting deployment, Docker, and development workflow setup needed to run and maintain the service.
Original PR description
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
Polish companies can now prepare a dedicated VAT-UE report instead of relying on the generic EC Sales List. The report covers relevant EU sales, purchases, services, triangular transactions, and supports the official XML export required for filing.
Original PR description
Description of the issue this commit addresses: Polish companies only have the generic EC Sales List without purchase transactions or an XML export matching the official VAT-UE structure. --- Desired behavior after this commit is merged: This commit adds a Polish VAT-UE report covering intra-Community supplies, acquisitions, services, triangular transactions, and the official XML export. --- task-6368808 Forward-Port-Of: odoo/enterprise#127083
Enhancements to existing features
Adds a dedicated screen for French PDP e-reporting moves so users can review key e-reporting details separately from the standard accounting move view. This improves visibility for compliance-related information while keeping the main accounting view unchanged.
Original PR description
This commit will add a new view for the ereporting moves to be able to see some specific info without touching the base move view. task-6274213 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#270101
Resolved issues and error corrections
This fixes a crash when work-hour values close to the next hour were converted into clock times. The change makes time calculations more reliable for computed or aggregated hour values, especially near hour and day boundaries.
Original PR description
### Bug `odoo.tools.date_utils.float_to_time` builds the minutes with a rounding step: ```python return time(int(integral), int(float_round(60 * fractional, precision_digits=0)), 0) ``` When the…
### Bug
`odoo.tools.date_utils.float_to_time` builds the minutes with a rounding step:
```python
return time(int(integral), int(float_round(60 * fractional, precision_digits=0)), 0)
```
When the fractional part of the hour is high enough, `round(60 * fractional)`
rounds up to a full **60**, and `time(hour, 60)` is invalid:
```python
>>> float_to_time(16.9959)
ValueError: minute must be in 0..59, not 60
>>> float_to_time(8.999)
ValueError: minute must be in 0..59, not 60
```
Any hours value whose fractional part is ≥ ~0.9917 hits this — which happens
easily with computed/aggregated work-hour floats.
### Fix
Carry the rounded-up minute into the hour, and return `time.max` when that carry
reaches the end of the day (mirroring the existing `hours == 24.0` case):
```python
if minute == 60:
hour += 1
minute = 0
if hour >= 24:
return time.max
```
`float_to_time(16.9959)` now returns `time(17, 0)`, `float_to_time(23.9959)`
returns `time.max`, and regular values are unchanged.
Adds `TestFloatToTime` in `test_date_utils.py` covering the carry, the
end-of-day carry, and regular values.Documentation and clarification updates
This pull request records Waqas Ahmed's signed Contributor License Agreement. It supports the legal requirements for accepting future contributions and has no direct impact on product features or users.
Original PR description
Contributor License Agreement for Waqas Ahmed I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update improves internal tests that validate scheduled marketing automation work, helping ensure campaigns process consistently over time. It also corrects how configuration settings are referenced in these tests, reducing the risk of false failures or missed issues before release.
This update makes the Turkish Nilvera localization explicitly include a required e-invoicing component. It prevents installation and testing failures in environments where automatic module installation is skipped, improving reliability without changing business workflows.
Original PR description
The view 'res.partner.property.form.inherit.ubl.tr' references external ID 'account_edi_ubl_cii.view_partner_property_form' but module 'account_edi_ubl_cii' is only available because of auto_install-links in the module graph. This causes an error when auto_install is skipped on runbot. The error is fixed since saas-19.2(https://github.com/odoo/odoo/pull/248034) where the view is moved but no backport for saas-19.1 and earlier has been made. Adding the explicit dependency is valid because 'account_edi_ubl_cii' is indirectly installed at the same time. This is the effect chain: 1. 'l10n_tr_nilvera_einvoice' is auto_install'ed after 'l10n_tr_nilvera' installs 2. 'l10n_tr_nilvera_einvoice' has explicit dependency on 'account_edi_ubl_cii'. Forward-Port-Of: odoo/odoo#282475
This fix updates how image palette handling is referenced so it works with the Pillow version included in Ubuntu Jammy as well as newer versions. It helps keep automated image-related tests reliable across supported environments without changing user-facing behavior.
Original PR description
`Image.Palette.ADAPTIVE` is not available in the Pillow version provided by Ubuntu Jammy, causing the animated GIF test to fail. Use `Image.ADAPTIVE` instead, which is compatible with both older and newer Pillow versions. 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#282223
This fix ensures invoice tax calculations correctly include the amount of an earlier tax when it changes the base for a following tax. It helps keep displayed tax details and totals accurate for invoices using chained or base-affecting taxes.
Original PR description
**Steps to reproduce:** - Create a tax that affects the base of the subsequent ones - Create an invoice with this tax and another one on the same line **Issue:** In "_aggregate_base_line_tax_details", the tax amount from the first tax should be included in the following values of the second tax: - raw_total_excluded - raw_total_excluded_currency - target_total_excluded - target_total_excluded_currency - total_excluded - total_excluded_currency But it is not. opw-6235909 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#283556 Forward-Port-Of: odoo/odoo#279335
Odoo now more accurately identifies the right contact when multiple companies or partners use the same email address but different display names. This prevents emails sent from templates from appearing to come from the wrong company, improving clarity and trust in customer communications.
Original PR description
### Issue: When multiple partners share the same email address, `_mail_find_partner_from_emails` may resolve to the wrong partner when the input is a formatted email like "`Name <email>`" This…
### Issue:
When multiple partners share the same email address, `_mail_find_partner_from_emails` may resolve to the wrong partner when the input is a formatted email like "`Name <email>`"
This affects use cases like email templates using `{{object.company_id.email_formatted}}` as sender, where the wrong company partner could be selected
### Cause:
The lookup in `done_partners` only matched on `email_normalized`, which cannot distinguish partners sharing the same email but with different names
The `email_formatted` field carries both name and email, allowing an exact match when the input is a formatted email
### Steps to reproduce:
- Install `account`
- Create an Email Template (Applies to: account.move, From: {{object.company_id.email_formatted}})
- Create a second company B with the same email as the default (e.g. info@yourcompany.com)
- In Settings (logged in as company B), set a Fiscal Position (e.g. US Taxable)
- Create an Invoice on company B
- In the chatter, click Send message, click the expand arrows button, use the three dots menu to select the template
- Send and check the Sender in the chatter
Before the fix, the sender resolves to the default company even though the invoice belongs to company B
opw-6260992
Forward-Port-Of: odoo/odoo#282966
Forward-Port-Of: odoo/odoo#269509Tax return submission no longer gets blocked by incomplete account settings on tax groups that have not been used in any transactions. This lets businesses close taxes without fixing irrelevant tax group configurations.
Original PR description
…ax closing Steps to reproduce: - Remove the tax payable and receivable accounts of a tax group for which no move exists. - Open the tax returns view, set the opening date and submit the tax return -> Odoo prevents going further because the tax group configuration isn't fully done, but it's useless to ensure that for tax groups that aren't used.
This fix ensures Brazilian point-of-sale tax adjustment entries use the correct sales tax when matching tax codes. It prevents accounting entries from becoming unbalanced when similar sales and purchase taxes exist, improving reliability of fiscal records.
Original PR description
The chart template gives the same Avatax code and price_include_override to the sale and the purchase tax, and creates both in the same transaction. Without an explicit type_tax_use the lookup used to return either of them at random, and picking the purchase one left the entry unbalanced. The purchase taxes got their Avatax code in 18.4+. https://github.com/odoo/enterprise/pull/101072 runbot-945969 Forward-Port-Of: odoo/enterprise#128476
German DATEV exports now correctly handle bank reconciliations involving a payer currency, bank currency, and company currency. The change splits these settlements through the DATEV clearing account so each exported line uses only one foreign currency, preventing incorrect or unsupported export data.
Original PR description
Issue: - DATEV does not support multiple foreign currencies on a single journal line. - This can occur when reconciling a bank transaction where: - the payer uses one currency (C1), - the bank…
Issue: - DATEV does not support multiple foreign currencies on a single journal line. - This can occur when reconciling a bank transaction where: - the payer uses one currency (C1), - the bank journal is held in another currency (C2), - the company uses a third currency (C3). - The existing export logic could not represent the bank liquidity and foreign AR/AP currencies separately in such cases. Fix: - Detect 3-currency cases from bank statement transactions and their liquidity line. - Use the DATEV clearing account (1360 SKR03 / 1460 SKR04) to split the transaction into two logical legs: - Bank → Clearing (bank journal currency) - AR/AP → Clearing (payer currency) - Emit the liquidity leg only once when multiple foreign AR/AP lines are reconciled against the same bank transaction. - Keep regular 1- and 2-currency transactions on the existing export path. Impact: - Correctly represents 3-currency bank settlements in DATEV. - Keeps each exported line in a single foreign currency. - Leaves manual entries and payment transactions outside this specific handling, as the scenario is specific to the bank liquidity line. taskID-5457547 Forward-Port-Of: odoo/enterprise#128576 Forward-Port-Of: odoo/enterprise#109010
This fix ensures Peruvian electronic invoices calculate taxable amounts consistently with line totals, avoiding rejection by the local electronic invoicing service. It also accounts for taxes that affect later tax calculations, improving accuracy for affected invoices such as down payments.
Original PR description
**Steps to reproduce:** - Install Accounting, Sales and l10n_pe_edi - Switch to a Peruvian company (e.g. PE Company) - Create a SO: * Customer: [a Peruvian customer] * Order Lines: | Product |…
**Steps to reproduce:**
- Install Accounting, Sales and l10n_pe_edi
- Switch to a Peruvian company (e.g. PE Company)
- Create a SO:
* Customer: [a Peruvian customer]
* Order Lines:
| Product | Quantity | Unit Price | Taxes |
| ------- | -------- | ---------- | ------- |
| any | 3.00 | 123.50 | VAT 18% |
| any | 2.00 | 27.544216 | 0% Ina |
| any | 1.00 | 43.490867 | 0% Exo |
- Confirm the SO
- Create a 40% down payment
- Confirm the down payment
- Process it to sent it to Peru UBL 2.1
**Issue:**
The following error message is returned by the OSE:
`3272|La base imponible a nivel de línea difiere de lainformación consignada en el comprobante - Detalle: xxx.xxx.xxx ticket : 20260000000000221633458 error: Error en la Linea Nro. :1. : 3272 (nodo: "cac:TaxSubtotal/cbc:TaxableAmount" valor: "148.20")`
**Cause:**
In the XML, one line has 148.19 for "cbc:LineExtensionAmount", but 148.20 for "cac:TaxSubtotal/cbc:TaxableAmount".
The issue is coming from the fact that "base_amount_currency" is used instead of "total_excluded_currency" for the computation of "cac:TaxSubtotal/cbc:TaxableAmount".
**Issue 2:**
When a tax is impacting the base amount of a following tax, its tax amount is not taken into account in "total_excluded_currency".
opw-6235909
Forward-Port-Of: odoo/enterprise#128602
Forward-Port-Of: odoo/enterprise#122310