Daily updates from Odoo
Saturday, July 25, 2026
31 changes
2 changes
Enhancements to existing features
Peruvian electronic invoicing now reflects SUNAT's updated debit note reason requirements effective August 1, 2026. The change adds the new “Penalties” reason and renames an existing reason to “Other concepts,” helping businesses stay compliant when issuing debit notes in Peru.
Original PR description
Purpose: SUNAT has issued new validation rules and database updates for EDI. The changes are mandatory and is effective starting August 1, 2026. To stay compliant, the debit note reasons need to be updated when creating a debit note in Peru. A new code 13 with label "Penalties" is added to the list of reasons. Code 03 reason need its label to be updated to "Other concepts." Task [link](https://www.odoo.com/odoo/project.task/6312025) task-6312025 Forward-Port-Of: odoo/enterprise#122320
Resolved issues and error corrections
The WinBooks import now avoids combining supplier and customer contact details when their VAT numbers are explicitly different. This prevents incorrect data merging that could cause Belgian VAT validation errors and block the import process.
Original PR description
When importing a WinBooks zip, contacts sharing the same number might fail VAT validation if distinct contact data is merged incorrectly. Steps to reproduce: - Create a database with the Belgian…
When importing a WinBooks zip, contacts sharing the same number might fail VAT validation if distinct contact data is merged incorrectly. Steps to reproduce: - Create a database with the Belgian localization installed - Install the account_winbooks_import module - Navigate to Accounting > Configuration > Settings > Initial Setup > Import - Import the WinBooks zip Issue: The import fails with the following error: The VAT number [AAAAAA] for partner [BBBBBB] does not seem to be valid. Note: the expected format is BExxxxxxx. Analysis: In WinBooks, contacts can be of type Supplier or Customer, and it is possible for a supplier and a customer to share the same number. During the import, the system will merge contacts if found with the same number. In the specific case, the VAT number from one contact without country is combined with the country information from another contact, resulting in a VAT validation error. This change prevents the merger of partner data if their VAT numbers are explicitly different. opw-6251772 Forward-Port-Of: odoo/enterprise#119579
2 changes
Enhancements to existing features
The Peru electronic invoicing module now reflects SUNAT's updated debit note reason requirements effective August 1, 2026. Businesses can select the new "Penalties" reason and will see the revised "Other concepts" label, helping keep debit note creation compliant with Peruvian tax rules.
Original PR description
Purpose: SUNAT has issued new validation rules and database updates for EDI. The changes are mandatory and is effective starting August 1, 2026. To stay compliant, the debit note reasons need to be updated when creating a debit note in Peru. A new code 13 with label "Penalties" is added to the list of reasons. Code 03 reason need its label to be updated to "Other concepts." Task [link](https://www.odoo.com/odoo/project.task/6312025) task-6312025 Forward-Port-Of: odoo/enterprise#122320
Resolved issues and error corrections
WinBooks imports now keep contacts separate when they have the same number but explicitly different VAT numbers. This prevents customer and supplier details from being combined incorrectly, avoiding VAT validation errors that could block an import.
Original PR description
When importing a WinBooks zip, contacts sharing the same number might fail VAT validation if distinct contact data is merged incorrectly. Steps to reproduce: - Create a database with the Belgian…
When importing a WinBooks zip, contacts sharing the same number might fail VAT validation if distinct contact data is merged incorrectly. Steps to reproduce: - Create a database with the Belgian localization installed - Install the account_winbooks_import module - Navigate to Accounting > Configuration > Settings > Initial Setup > Import - Import the WinBooks zip Issue: The import fails with the following error: The VAT number [AAAAAA] for partner [BBBBBB] does not seem to be valid. Note: the expected format is BExxxxxxx. Analysis: In WinBooks, contacts can be of type Supplier or Customer, and it is possible for a supplier and a customer to share the same number. During the import, the system will merge contacts if found with the same number. In the specific case, the VAT number from one contact without country is combined with the country information from another contact, resulting in a VAT validation error. This change prevents the merger of partner data if their VAT numbers are explicitly different. opw-6251772 Forward-Port-Of: odoo/enterprise#119579
10 changes
Enhancements to existing features
The timesheet Timeline view now lists assistant suggestions in true chronological order instead of sorting them by title. It also shows each suggestion's start time, making it easier for users to review and enter work in the order it happened.
The Peruvian electronic invoicing module now reflects SUNAT’s upcoming mandatory debit note reason updates effective August 1, 2026. Users creating debit notes in Peru will see the new “Penalties” reason and the updated “Other concepts” label, helping businesses remain compliant.
Original PR description
Purpose: SUNAT has issued new validation rules and database updates for EDI. The changes are mandatory and is effective starting August 1, 2026. To stay compliant, the debit note reasons need to be updated when creating a debit note in Peru. A new code 13 with label "Penalties" is added to the list of reasons. Code 03 reason need its label to be updated to "Other concepts." Task [link](https://www.odoo.com/odoo/project.task/6312025) task-6312025 Forward-Port-Of: odoo/enterprise#122320
Resolved issues and error corrections
This fixes balance receipt printing for SIX payment terminals after a prior change caused the receipt template to load incorrectly. Businesses using these terminals can generate balance receipts again once the POS IoT SIX module is upgraded.
Original PR description
odoo/enterprise#104683 broke the balance receipt for six terminals trying to load an html template in a template name param. We fix this by extracting the template in its own file. Note: clients will have to upgrade the module in order to make the template available. task-6391500
Chile-specific electronic document imports now correctly create separate vendor bills when one XML file contains multiple documents. This prevents the first bill from incorrectly receiving all invoice lines and references, avoiding total mismatches and accounting errors.
Original PR description
When importing an EnvioDTE XML containing several DTEs (journal upload or incoming DTE mail server), one vendor bill is created per DTE, but the first bill receives the invoice lines and references…
When importing an EnvioDTE XML containing several DTEs (journal upload or incoming DTE mail server), one vendor bill is created per DTE, but the first bill receives the invoice lines and references of ALL the DTEs in the file, causing the total amount mismatch.
Cause: `_split_xml_into_new_attachments()` creates new attachments for the documents beyond the first one but leaves the original `file_data['xml_tree']` untouched; the decoder must scope itself to the first document (as l10n_it_edi and l10n_es_edi_facturae do), which `_l10n_cl_import_dte()` never did.
e.g. l10n_es_edi_facturae:633:
```python
# Only decode the first invoice of the Factura-e file.
tree = tree.xpath('//Invoice')[0]
```
Fix: scope the tree to the first DTE node before filling the bill. Kept behind a `len > 1` guard so files with a bare <DTE> root (matched by `xpath('//ns0:DTE')` but not by `findall('.//ns0:DTE')`) keep working.
Introduced in: https://github.com/odoo/enterprise/pull/75327.
opw-6378954
Forward-Port-Of: odoo/enterprise#124691Subscription products now show discounted recurring prices correctly on shop product tiles. This prevents customers from seeing discounts calculated from the one-time sale price instead of the selected subscription plan price.
Original PR description
Steps to reproduce: =================== 1. Create a subscription product, allow one-time sale, sale price 5 2. Add a recurring price 10/month 3. On the pricelist, add an advanced rule: -10% for the…
Steps to reproduce: =================== 1. Create a subscription product, allow one-time sale, sale price 5 2. Add a recurring price 10/month 3. On the pricelist, add an advanced rule: -10% for the monthly plan 4. Open the shop page and look at the product tile Cause: ======= On the /shop page, the subscription price displayed on a product tile is computed by `_get_sales_prices`. The cart has no plan selected yet at that point, so `request.cart.plan_id.id` is empty and was passed as `plan_id` to `_compute_price`. In `product.pricelist.item._compute_base_price`, the recurring base price is only looked up when a `plan_id` is given: if rule_base == 'list_price' and product.recurring_invoice and plan_id: ... # find the recurring rule -> base = recurring price With `plan_id` empty, that branch is skipped and the percentage rule falls back on the product's one-time `list_price` instead of the recurring price. Example: one-time price 5, recurring price 10/month, pricelist rule -10% on the monthly plan. => Tile showed 4.5/month (5 * 0.9) instead of 9/month (10 * 0.9). Solution: ========= The chosen pricing already targets a plan, so pass `pricing.plan_id.id` to `_compute_price`, matching what the product page does in `_get_additionnal_combination_info`. opw-6307398 Forward-Port-Of: odoo/enterprise#120872
Applying an Engineering Change Order could fail when documents were copied to a product because the system linked to the wrong type of internal record. This fix ensures copied documents keep the correct attachment reference, helping manufacturing teams apply approved changes without interruption.
Original PR description
When applying an ECO, `action_apply` copies each ECO document onto the product template and fills `origin_attachment_id` with `attach.id`. That field is a many2one to `ir.attachment`, but `attach` is a `product.document`. Steps to reproduce: - Create an `mrp.eco` record and start a new revision - Upload a document on the ECO, note its product.document id - Make sure no ir.attachment exists with that same id - Move the ECO to its final stage and hit "Apply Changes" - Observe the error The very same change was already applied on master by 3a39186f883, but was never backported. opw-6387343 Forward-Port-Of: odoo/enterprise#124950
Electronic invoices sent from Colombian branch companies now use the parent company name in the required DIAN XML field. This prevents DIAN from rejecting or failing to match invoices because branch names are not recognized against the company tax ID.
Original PR description
The correct behavior should be to use the original company name in this specific XML tag For the DIAN, branch names will not be recognized as related to the NIT. So, when sending electronic invoices from a branch, the XML should use the name of the parent company of that branch. Ticket [link](https://www.odoo.com/odoo/project.task/6074280) opw-6074280 Forward-Port-Of: odoo/enterprise#115494
Belgian EC Sales List XML and PDF exports now use the foreign VAT number set on the fiscal position when a company files for Belgium from another country. This helps businesses submit compliant tax reports and avoids showing the wrong domestic VAT number in official documents.
Original PR description
### Issue before this commit: When a company generates an EC Sales List for a foreign country (e.g., a Luxembourgish company running a Belgian report), the exported XML and PDF files incorrectly…
### Issue before this commit: When a company generates an EC Sales List for a foreign country (e.g., a Luxembourgish company running a Belgian report), the exported XML and PDF files incorrectly display the company's primary domestic VAT number instead of the foreign VAT number defined in the fiscal position in the tag DeclarantReference. ### Steps to reproduce the issue: 1. Download Accounting and l10n_lu 2. Switch to LU company 3. Go to Fiscal Positions in settings and create the Belgian position (insert country as Belgium and Foreign Tax ID as BE0477472701) 4. A pop up will appear saying: Click to create the taxes for this country. so click there to create the taxes 5. Go to Invoices and create a new invoice and be sure that: 1. be sure the customer has a VAT number in their profile 2. in tab Other Info the Fiscal Position is set to Belgium 3. the tax applied is 0% EU S (BE) 4. date of invoice is in June 6. Open the tax return in 1 July 7. Open EC Sales List June 2026 (BE) and mark as reviewed all the lines 8. Click on Validate 9. Open the XML and PDF file created and see that the tag DeclarantReference is wrong because it reports the data of LU company instead of BE company ### Cause of the issue: The `export_to_xml_sales_report` method relied on legacy code (company.partner_id.vat) to fetch the VAT number. It failed to use the centralized `get_vat_for_export(options)` method, thereby completely bypassing the foreign VAT logic correctly implemented in other tax reports. ### Reason to introduce the fix: To ensure tax compliance by appling the correct VAT number from the foreign fiscal position. opw-6170447 Forward-Port-Of: odoo/enterprise#125210 Forward-Port-Of: odoo/enterprise#124698
This fix ensures Brazilian customer tax settings are fully sent to Avalara, even when some values are empty or set to false. It prevents invoices from receiving the wrong CFOP tax classification, helping keep Brazilian electronic invoicing and tax reporting accurate.
Original PR description
## Steps to reproduce: 1. Install `l10n_br`, `l10n_br_avatax`, and `l10n_br_edi_fiscal_reform`. 2. Ensure that Demo mode is activated if not on Runbot. 3. Navigate to Contacts, then click into "BR…
## Steps to reproduce:
1. Install `l10n_br`, `l10n_br_avatax`, and `l10n_br_edi_fiscal_reform`.
2. Ensure that Demo mode is activated if not on Runbot.
3. Navigate to Contacts, then click into "BR Company Customer Estimated Profit".
4. Duplicate this contact, then set the following fields:
1. Tax Regime set to individual
2. ICMS Taxpayer Type set to Non-Taxpayer
5. Swtich to the BR Company and go to Accounting / Configuration / Settings.
6. Set up a Sandbox Avalara account and enable logging payload responses.
7. Navigate to Accounting > Customers > Invoices.
8. Create an invoice with:
1. Customer set to the copy created earlier.
2. Operation Type set to Sale of Goods
3. Document Type set to 55
4. Payment Method Brazil set to Money
5. Presence set to Present
6. One sales order line with:
1. Regular Consumable Product
2. quantity set to 1
3. price set to 100.0
9. Confirm the invoice.
10. Navigate back to Accounting > Configuration > Settings to view the response from Avalara. The customer will have the CFOP 6102 instead of CFOP 6108.
Explanation:
PR #97845 introduced `_l10n_br_deep_clean_dict()` to remove falsy values and empty dictionaries from the payload we send to Avalara. This fix was applied as broadly as possible to prevent excessive if statements.
However, if the falsy values in taxSettings of the customer are not communicated, Avalara will assign the customer to an incorrect CFOP.
opw-6085964
Forward-Port-Of: odoo/enterprise#120783This fixes Uruguay e-Ticket credit notes for original tickets with a total of 0.00 by keeping a required reference amount in the electronic document. It prevents valid zero-value credit notes from being rejected by DGI and avoids related processing errors for document types without that field.
Original PR description
Problem: When generating an e-Ticket Credit Note for an original e-Ticket with a total amount of 0.00, the XML cleanup mechanism removes reference fields whose value is 0.00. As a result, the credit note is rejected by DGI with: "CODE 31: En línea de Referencia 1 si NO IndGlobal = 1 deben existir TpoDocRef, Serie, NroCFERef, MntCFERef, TpoMonedaRef." Solution: Ensure that MntCFERef is sent even if the value is 0.00. opw-6378783 Forward-Port-Of: odoo/enterprise#124377 Forward-Port-Of: odoo/enterprise#124354
2 changes
Enhancements to existing features
The Peru electronic invoicing module updates debit note reason options to match SUNAT rules effective August 1, 2026. Businesses can now select the new “Penalties” reason and will see the revised “Other concepts” label, helping keep debit note issuance compliant.
Original PR description
Purpose: SUNAT has issued new validation rules and database updates for EDI. The changes are mandatory and is effective starting August 1, 2026. To stay compliant, the debit note reasons need to be updated when creating a debit note in Peru. A new code 13 with label "Penalties" is added to the list of reasons. Code 03 reason need its label to be updated to "Other concepts." Task [link](https://www.odoo.com/odoo/project.task/6312025) task-6312025 Forward-Port-Of: odoo/enterprise#122320
Resolved issues and error corrections
WinBooks imports now avoid incorrectly combining customer and supplier contact details when they share the same number but have different VAT numbers. This prevents valid import files from failing due to a VAT validation error caused by mismatched contact data.
Original PR description
When importing a WinBooks zip, contacts sharing the same number might fail VAT validation if distinct contact data is merged incorrectly. Steps to reproduce: - Create a database with the Belgian…
When importing a WinBooks zip, contacts sharing the same number might fail VAT validation if distinct contact data is merged incorrectly. Steps to reproduce: - Create a database with the Belgian localization installed - Install the account_winbooks_import module - Navigate to Accounting > Configuration > Settings > Initial Setup > Import - Import the WinBooks zip Issue: The import fails with the following error: The VAT number [AAAAAA] for partner [BBBBBB] does not seem to be valid. Note: the expected format is BExxxxxxx. Analysis: In WinBooks, contacts can be of type Supplier or Customer, and it is possible for a supplier and a customer to share the same number. During the import, the system will merge contacts if found with the same number. In the specific case, the VAT number from one contact without country is combined with the country information from another contact, resulting in a VAT validation error. This change prevents the merger of partner data if their VAT numbers are explicitly different. opw-6251772 Forward-Port-Of: odoo/enterprise#119579
4 changes
Enhancements to existing features
The Peru electronic invoicing module updates the available debit note reasons to match SUNAT rules effective August 1, 2026. Businesses can select the new “Penalties” reason and use the updated “Other concepts” label, helping debit notes remain compliant with local requirements.
Original PR description
Purpose: SUNAT has issued new validation rules and database updates for EDI. The changes are mandatory and is effective starting August 1, 2026. To stay compliant, the debit note reasons need to be updated when creating a debit note in Peru. A new code 13 with label "Penalties" is added to the list of reasons. Code 03 reason need its label to be updated to "Other concepts." Task [link](https://www.odoo.com/odoo/project.task/6312025) task-6312025 Forward-Port-Of: odoo/enterprise#122320
Resolved issues and error corrections
This update fixes Swedish ISO 20022 payment files so they match Swedbank's required identification format and bank scheme settings. It helps prevent payment file rejections when companies submit Swedish bank transfers, and also prepares Swedish payment files for upcoming structured address requirements.
Original PR description
Fix some issues with the iso20022 XML file for Sweden:
1. Swedbank doesn't allow the us of `CUST` value in the `SchmeNm`
node but force the `BANK` value.
2. Currently, we use the same Id in both `InitgPty` & `Dbtr`, which
looks to be wrong with Swedbank. The format for Swedbank is
`06{company_registry}B001`.
opw-5395736
Forward-Port-Of: odoo/enterprise#125328
Forward-Port-Of: odoo/enterprise#122119WinBooks imports now keep supplier and customer contact data separate when their VAT numbers are different, even if they share the same contact number. This prevents imports from failing because details from two distinct contacts were incorrectly combined.
Original PR description
When importing a WinBooks zip, contacts sharing the same number might fail VAT validation if distinct contact data is merged incorrectly. Steps to reproduce: - Create a database with the Belgian…
When importing a WinBooks zip, contacts sharing the same number might fail VAT validation if distinct contact data is merged incorrectly. Steps to reproduce: - Create a database with the Belgian localization installed - Install the account_winbooks_import module - Navigate to Accounting > Configuration > Settings > Initial Setup > Import - Import the WinBooks zip Issue: The import fails with the following error: The VAT number [AAAAAA] for partner [BBBBBB] does not seem to be valid. Note: the expected format is BExxxxxxx. Analysis: In WinBooks, contacts can be of type Supplier or Customer, and it is possible for a supplier and a customer to share the same number. During the import, the system will merge contacts if found with the same number. In the specific case, the VAT number from one contact without country is combined with the country information from another contact, resulting in a VAT validation error. This change prevents the merger of partner data if their VAT numbers are explicitly different. opw-6251772 Forward-Port-Of: odoo/enterprise#119579
Spanish VAT record book exports now include relevant accounting entries created outside standard invoices and bills, such as Point of Sale session closures. This ensures VAT reporting is more complete and helps businesses meet Spanish tax reporting obligations accurately.
Original PR description
Currently, the Spanish VAT record books (Libros Registro de IVA) only include move types associated with invoices and bills. However, miscellaneous entries (type 'entry'), such as those generated by the Point of Sale session closures or manual liquidations, also carry tax obligations and must be reflected in these reports. Steps to reproduce: - Open a POS Session - Create an order, pay and close session - Go to Accouting > Reporting > Tax report - Select Generic Tax report - Print "VAT record Books" Issue: Only invoices and bills are visible in the excel file, and not the entry generated from point of sale. However, movements that are not related to invoices should be included in the VAT books. opw-5862529 Forward-Port-Of: odoo/enterprise#125443 Forward-Port-Of: odoo/enterprise#113681
2 changes
Enhancements to existing features
The Peru EDI localization now reflects SUNAT's updated debit note reason requirements effective August 1, 2026. Businesses issuing debit notes in Peru will see the new “Penalties” reason and the updated “Other concepts” label, helping keep electronic invoicing compliant.
Original PR description
Purpose: SUNAT has issued new validation rules and database updates for EDI. The changes are mandatory and is effective starting August 1, 2026. To stay compliant, the debit note reasons need to be updated when creating a debit note in Peru. A new code 13 with label "Penalties" is added to the list of reasons. Code 03 reason need its label to be updated to "Other concepts." Task [link](https://www.odoo.com/odoo/project.task/6312025) task-6312025 Forward-Port-Of: odoo/enterprise#122320
Resolved issues and error corrections
The WinBooks import now avoids incorrectly combining contact records that share the same number but have different VAT details. This prevents valid imports from failing due to mismatched VAT and country information, especially when supplier and customer records overlap.
Original PR description
When importing a WinBooks zip, contacts sharing the same number might fail VAT validation if distinct contact data is merged incorrectly. Steps to reproduce: - Create a database with the Belgian…
When importing a WinBooks zip, contacts sharing the same number might fail VAT validation if distinct contact data is merged incorrectly. Steps to reproduce: - Create a database with the Belgian localization installed - Install the account_winbooks_import module - Navigate to Accounting > Configuration > Settings > Initial Setup > Import - Import the WinBooks zip Issue: The import fails with the following error: The VAT number [AAAAAA] for partner [BBBBBB] does not seem to be valid. Note: the expected format is BExxxxxxx. Analysis: In WinBooks, contacts can be of type Supplier or Customer, and it is possible for a supplier and a customer to share the same number. During the import, the system will merge contacts if found with the same number. In the specific case, the VAT number from one contact without country is combined with the country information from another contact, resulting in a VAT validation error. This change prevents the merger of partner data if their VAT numbers are explicitly different. opw-6251772 Forward-Port-Of: odoo/enterprise#119579
2 changes
Enhancements to existing features
Odoo Enterprise now uses the newer Material Symbols icon style across many screens, replacing older icon formats. This makes the interface more consistent and keeps icon selection tools aligned with the current design system.
Original PR description
[IMP] *: apply new icon implementation globally --- This commit is a follow-up to odoo/odoo#273606. It applies the new icon implementation across the entire codebase, replacing almost all legacy icon…
[IMP] *: apply new icon implementation globally
---
This commit is a follow-up to odoo/odoo#273606.
It applies the new icon implementation across the entire codebase,
replacing almost all legacy icon usages.
Previous patterns such as `class="oi oi-fw oi-arrow-left"` or
`class="fa fa-fw fa-arrow-left"` are migrated to the new format
using `class="oi oi-fw"` with the data-icon attribute (e.g.,
`data-icon="west"`), ensuring consistency with the Material
Symbols-based system.
Community PR: odoo/odoo#256840
task-5901783
---
[IMP] web_{enterprise, studio}: adapt icon selector for Material Symbols
---
With the switch to Material Symbols as the icon set, the app/menu icon
pickers and the various places that render web icons no longer rely on
Font Awesome classes. The FontAwesomeIconSelector component is renamed to
the StudioIconSelector and now sources its choices from the html_editor
MediaDialog icon selector (via initFonts) instead of the removed
getFontAwesomeIcons util. Icons are rendered with the `oi` class and a
`data-icon` attribute holding the Material Symbols name rather than a
composed class string, and the st full icon
name (no more stripping the `fa ` prefix).
Templates and components across web_enterprise (home menu, navbar) and
web_studio (icon creator, editor button box
dialog) are updated accordingly, the icon_selector asset is added to the
Studio minimal bundle, and the reusted to use
Material Symbols names.
task-5901783Resolved issues and error corrections
The WinBooks import now avoids merging contact details when contacts with the same number have clearly different VAT numbers. This prevents valid imports from failing because supplier and customer information was incorrectly combined.
Original PR description
When importing a WinBooks zip, contacts sharing the same number might fail VAT validation if distinct contact data is merged incorrectly. Steps to reproduce: - Create a database with the Belgian…
When importing a WinBooks zip, contacts sharing the same number might fail VAT validation if distinct contact data is merged incorrectly. Steps to reproduce: - Create a database with the Belgian localization installed - Install the account_winbooks_import module - Navigate to Accounting > Configuration > Settings > Initial Setup > Import - Import the WinBooks zip Issue: The import fails with the following error: The VAT number [AAAAAA] for partner [BBBBBB] does not seem to be valid. Note: the expected format is BExxxxxxx. Analysis: In WinBooks, contacts can be of type Supplier or Customer, and it is possible for a supplier and a customer to share the same number. During the import, the system will merge contacts if found with the same number. In the specific case, the VAT number from one contact without country is combined with the country information from another contact, resulting in a VAT validation error. This change prevents the merger of partner data if their VAT numbers are explicitly different. opw-6251772 Forward-Port-Of: odoo/enterprise#119579
3 changes
Enhancements to existing features
Peruvian electronic invoicing debit note reasons were updated to match new SUNAT requirements effective August 1, 2026. The change adds a new “Penalties” reason and renames an existing reason to “Other concepts,” helping businesses stay compliant when issuing debit notes.
Original PR description
Purpose: SUNAT has issued new validation rules and database updates for EDI. The changes are mandatory and is effective starting August 1, 2026. To stay compliant, the debit note reasons need to be updated when creating a debit note in Peru. A new code 13 with label "Penalties" is added to the list of reasons. Code 03 reason need its label to be updated to "Other concepts." Task [link](https://www.odoo.com/odoo/project.task/6312025) task-6312025 Forward-Port-Of: odoo/enterprise#122320
Resolved issues and error corrections
WinBooks imports now avoid combining supplier and customer contact details when their VAT numbers are explicitly different. This prevents valid import files from failing due to mismatched contact data, reducing manual cleanup for Belgian accounting imports.
Original PR description
When importing a WinBooks zip, contacts sharing the same number might fail VAT validation if distinct contact data is merged incorrectly. Steps to reproduce: - Create a database with the Belgian…
When importing a WinBooks zip, contacts sharing the same number might fail VAT validation if distinct contact data is merged incorrectly. Steps to reproduce: - Create a database with the Belgian localization installed - Install the account_winbooks_import module - Navigate to Accounting > Configuration > Settings > Initial Setup > Import - Import the WinBooks zip Issue: The import fails with the following error: The VAT number [AAAAAA] for partner [BBBBBB] does not seem to be valid. Note: the expected format is BExxxxxxx. Analysis: In WinBooks, contacts can be of type Supplier or Customer, and it is possible for a supplier and a customer to share the same number. During the import, the system will merge contacts if found with the same number. In the specific case, the VAT number from one contact without country is combined with the country information from another contact, resulting in a VAT validation error. This change prevents the merger of partner data if their VAT numbers are explicitly different. opw-6251772 Forward-Port-Of: odoo/enterprise#119579
Swedish ISO 20022 payment files now use bank-required identification values for Swedbank, reducing the risk of rejected payments. The update also prepares Swedish payment files for upcoming structured address requirements from November 2026.
Original PR description
Fix some issues with the iso20022 XML file for Sweden:
1. Swedbank doesn't allow the us of `CUST` value in the `SchmeNm`
node but force the `BANK` value.
2. Currently, we use the same Id in both `InitgPty` & `Dbtr`, which
looks to be wrong with Swedbank. The format for Swedbank is
`06{company_registry}B001`.
opw-5395736
Forward-Port-Of: odoo/enterprise#125328
Forward-Port-Of: odoo/enterprise#1221193 changes
Enhancements to existing features
The Peru electronic invoicing module updates the available debit note reasons to match new SUNAT requirements effective August 1, 2026. Users creating Peruvian debit notes will see the revised “Other concepts” label and a new “Penalties” reason, helping keep filings compliant.
Original PR description
Purpose: SUNAT has issued new validation rules and database updates for EDI. The changes are mandatory and is effective starting August 1, 2026. To stay compliant, the debit note reasons need to be updated when creating a debit note in Peru. A new code 13 with label "Penalties" is added to the list of reasons. Code 03 reason need its label to be updated to "Other concepts." Task [link](https://www.odoo.com/odoo/project.task/6312025) task-6312025 Forward-Port-Of: odoo/enterprise#122320
Resolved issues and error corrections
This fix prevents Mexican electronic invoice status checks from being repeatedly triggered in a loop, reducing unnecessary processing and keeping scheduled checks under control. It also prioritizes older customer invoices and limits vendor bill checks to the relevant period, helping important documents get reviewed before their deadline.
Original PR description
While trying to fix the SAT cron, we did not think it through it could cause infinite cron triggering. Indeed, the write_date is updated on every record that is handled. Fix is manyfold: - Avoid…
While trying to fix the SAT cron, we did not think it through it could cause infinite cron triggering. Indeed, the write_date is updated on every record that is handled. Fix is manyfold: - Avoid re-processing what we already check within the last 4 hours/12 hours depending on the type of the document. - The domain takes the *static* create date instead of the write_date to make sure we don't endless re-process the same record and that the window of 7/60 days applies. - Limit the Vendor Bill to be checked only during 7 days after their creation. - Use the create_date in the order of the search to ensure we process older records first, before their time-window closes. - Process the Vendor Bills last, this ensure Customer Invoices will be processed in priority in case we are not able to process everything within the last 4/12 hours. This is still imperfect and a little fragile, we will find a better solution in master, most likely by adding a dedicated field to keep track of the last SAT check. See https://github.com/odoo/enterprise/pull/123213 See https://github.com/odoo/enterprise/pull/103272 task-none
WinBooks imports now keep supplier and customer contact details separate when their VAT numbers differ, even if they share the same contact number. This prevents imports from failing due to mismatched VAT and country information being combined incorrectly.
Original PR description
When importing a WinBooks zip, contacts sharing the same number might fail VAT validation if distinct contact data is merged incorrectly. Steps to reproduce: - Create a database with the Belgian…
When importing a WinBooks zip, contacts sharing the same number might fail VAT validation if distinct contact data is merged incorrectly. Steps to reproduce: - Create a database with the Belgian localization installed - Install the account_winbooks_import module - Navigate to Accounting > Configuration > Settings > Initial Setup > Import - Import the WinBooks zip Issue: The import fails with the following error: The VAT number [AAAAAA] for partner [BBBBBB] does not seem to be valid. Note: the expected format is BExxxxxxx. Analysis: In WinBooks, contacts can be of type Supplier or Customer, and it is possible for a supplier and a customer to share the same number. During the import, the system will merge contacts if found with the same number. In the specific case, the VAT number from one contact without country is combined with the country information from another contact, resulting in a VAT validation error. This change prevents the merger of partner data if their VAT numbers are explicitly different. opw-6251772 Forward-Port-Of: odoo/enterprise#119579
1 change
Enhancements to existing features
Peru electronic invoicing now includes SUNAT’s updated debit note reason list ahead of the mandatory August 2026 rules. Businesses can select the new “Penalties” reason and will see the revised “Other concepts” label, helping keep local debit notes compliant.
Original PR description
Purpose: SUNAT has issued new validation rules and database updates for EDI. The changes are mandatory and is effective starting August 1, 2026. To stay compliant, the debit note reasons need to be updated when creating a debit note in Peru. A new code 13 with label "Penalties" is added to the list of reasons. Code 03 reason need its label to be updated to "Other concepts." Task [link](https://www.odoo.com/odoo/project.task/6312025) task-6312025