Odoo Changelog — 2026-07-13

Monday, July 13, 2026

6 changes · saas-18.4

Bug Fixes(6)

Resolved issues and error corrections

[FIX] delivery_sendcloud: accept dot in address numbers

Enterprisesaas-18.4delivery_sendcloud

Delivery labels sent through Sendcloud now keep full house numbers that include a dot, such as 12.345. This prevents incorrect address data on shipping labels and helps avoid delivery issues for affected customers.

Original PR description

Issue
-----
Labels have unexpected format when the delivery address has a dot (`.`) in the number.

Steps to reproduce
-----
- Set up Sendcloud (carrier shouldn't matter)
	- Enable logs
- Create a customer (with valid address, phone and email)
	- Address must contain a dot, eg Grand Place 12.345
- Deliver a product to the customer
	- Add sendcloud as delivery method
- Go to the logs
	- Open the "sendcloud request parcels" log

> house_number is 12

Cause
-----
The `house_number` field is populated using `_get_house_number`, where the regex used to extract the number from the address line does not accept the `.` character.

https://github.com/odoo/enterprise/blob/f93882555864a1f0a2a3e3863780096c78923bfa/delivery_sendcloud/models/sendcloud_service.py#L323

-----
Ticket:
opw-6295904

Forward-Port-Of: odoo/enterprise#123266

#sendcloud#delivery#shipping-labels#addresses

[FIX] sign: correct email display in signature certificate logs

PR #123996

Enterprisesaas-18.4sign

Signing certificates for recruitment offers now show the applicant's actual email address instead of a generic placeholder. This helps HR teams keep accurate signed offer records and avoids confusion when reviewing certificates.

Original PR description

similar to https://github.com/odoo/enterprise/pull/120566/changes/b5b6589c9c91980e41d025ae74082af63907debc When generating an offer from the recruitment application and signing it, the applicant's…

similar to https://github.com/odoo/enterprise/pull/120566/changes/b5b6589c9c91980e41d025ae74082af63907debc

When generating an offer from the recruitment application and signing it, the applicant's email address is incorrectly displayed.

### **Steps to Reproduce:**
1) Install sign, recruitment, hr_contract_salary
2) Create an new application and add basic detail like name and email as
   (path and path@test.com)
3) Generate offer and sign with all the required signer. 
4) Open the application form view and open the certificate.

### **Observed Behavior:**
Email is not set correctly in the generated certificate (appearing as john@example.com).

### **Expected Behavior:**
The email of the applicant should be correctly set(e.g as path@test.com)

### **Root Cause:**
When the applicant signs the document, their email is explicitly set to `False` at [1]. This is done because the applicant is not linked to any user yet. Later, when generating the certificate, the system attempts to display the user's partner email at [2], which is `False`, causing the default fallback value (`john@example.com`) to be printed.

[1]- https://github.com/odoo/enterprise/blob/49226f4109c7d7bb48340949951e70f4245d0e5b/hr_contract_salary/controllers/main.py#L53-L54

[2]- https://github.com/odoo/enterprise/blob/49226f4109c7d7bb48340949951e70f4245d0e5b/sign/report/sign_log_reports.xml#L59

### **Fix:**
Use `signer_email` instead of the partner's email to ensure the correct email is displayed on the certificate every time.

**opw-6280170**

Forward-Port-Of: odoo/enterprise#123901
Forward-Port-Of: odoo/enterprise#123767

#recruitment#signature#certificate#email

[FIX] l10n_ca_payment_cpa005: populate Item Trace Number with payment id

PR #123885

Enterprisesaas-18.4l10n_ca_payment_cpa005MEDIUM

Canadian EFT export files now use each payment's own ID as the Item Trace Number instead of filling it with zeros. This helps ensure payment files meet CPA-005 requirements and reduces the risk of rejected Canadian bank payment batches.

Original PR description

According to CPA-005 standards on the Item Trace Number:
"The data elements (b), (c) and (d) each must be greater than zero or the TRANSACTION WILL BE REJECTED" (page 36).
https://www.payments.ca/sites/default/files/standard005eng.pdf

Steps to reproduce:
1. Install the module l10n_ca_payment_cpa005
2. Go into "CA Company"
3. In the configuration for "CA Company", add something to the fields "Short Name used in Canadian EFT" and "Company ID" i.e. "CCC"
4. Set all the fields in the "Canadian EFT/CPA Configuration" section of the bank journal
5. Set the bank record on the bank journal. Set the field "Financial Institution ID Number" field of the "Account Number" record of the bank journal to any numerical sequence
6. Create a bank account on "Azure Interior" and make sure to check the field to trust the bank account that you created (otherwise there will be an error)
7. Create two payments with the vendor of "Azure Interior" using the payment method of "Canadian EFT"
8. Create a batch payment for both payments created
9. Validate the batch payment and the export file should show up in the chatter
10. Note that in the export file, the Item Trace Number for each payment is set to be all zeros, whereas it should be a nonzero identification sequence

Solution:
Set the Item Trace Number to be the payment's id

opw-6323432

Forward-Port-Of: odoo/enterprise#123707
Forward-Port-Of: odoo/enterprise#123633

#canadian-eft#payments#compliance

[FIX] l10n_be_hr_payroll_fleet: remove unexisting group

PR #123238

Enterprisesaas-18.4l10n_be_hr_payroll_fleet

This fix removes a reference to an employee access group that does not exist in the Belgian payroll fleet module. It helps prevent configuration errors and keeps payroll-related fleet fields aligned with valid access settings.

Original PR description

The group hr_group_user does not exist and shouldn't be linked to these fields.

task-6369268

#payroll#fleet#belgium#access

[FIX] l10n_cl_edi_exports: fix export information table column shift

PR #122924

Enterprisesaas-18.4l10n_cl_edi_exports

Chilean export invoice PDFs now keep customs information in the correct columns even when origin or destination ports are not provided. This prevents package quantities and other export details from appearing under the wrong headings, improving document accuracy for customers and customs use.

Original PR description

### Issue: On Chilean export invoices, the customs information table may display data in the wrong columns When `Origin Port` or `Destination Port` is not set, the corresponding `td` is omitted by…

### Issue:
On Chilean export invoices, the customs information table may display data in the wrong columns

When `Origin Port` or `Destination Port` is not set, the corresponding `td` is omitted by QWeb, causing the remaining columns to shift left

This results in `Qty of Packages` appearing under `Origin Port` or `Destination Port` in the printed document

### Cause:
`l10n_cl_port_origin_id` and `l10n_cl_port_destination_id` have no default value and are optional fields
`t-out` on a falsy value omits the `td` entirely in QWeb, breaking the column alignment

Adding `or ''` ensures an empty `td` is always rendered, preserving the table structure regardless of whether the fields are set

### Steps to reproduce:
- Install `l10n_cl_edi_exports` and switch to CL Company
- Create an Invoice (any customer, any line)
- In the gear menu, select Print > Invoice PDF copy (Chile)

Before the fix, `Qty of Packages` appears under `Origin Port` when neither port field is set

opw-6304670

Forward-Port-Of: odoo/enterprise#121923

#Chile#export invoices#PDF#customs

[FIX] l10n_es_reports: ignore negative component taxes in VAT books

PR #124013

Enterprisesaas-18.4l10n_es_reportsMEDIUM

Spanish VAT books now show the correct tax amounts for bills using EU taxes that include a negative component. This prevents valid taxes from appearing as zero, improving the accuracy of VAT reporting for Spanish companies.

Original PR description

Problem:
In the Spanish VAT books, taxes with negative component (like 21% EU G) always show their amounts as zero.

Steps to reproduce:
1. Install the l10n_es_reports module and select the Spanish company
2. Create a vendor bill with a vendor from another EU country and add a product
3. Make sure the tax applied to the product has a negative component (like 21% EU G)
4. Confirm the bill
5. Go to Accounting > Reporting > Tax Return
6. Generate the VAT books from the action menu and check the tax amounts
7. Notice how the tax amount is zero, even though the tax was applied to the bill

Cause:
When calculating the tax amounts, the negative component cancels out the positive component, leading to the amount always showing as zero in the VAT books.

opw-6169766

Forward-Port-Of: odoo/enterprise#123738

#Spanish VAT#tax reporting#vendor bills

Issue ----- Labels have unexpected format when the delivery address has a dot (`.`) in the number. Steps to reproduce ----- - Set up Sendcloud (carrier shouldn't matter) - Enable logs - Create a customer (with valid address, phone and email) - Address must contain a dot, eg Grand Place 12.345 - Deliver a product to the customer - Add sendcloud as delivery method - Go to the logs - Open the "sendcloud request parcels" log > house_number is 12 Cause ----- The `house_number` field is populated using `_get_house_number`, where the regex used to extract the number from the address line does not accept the `.` character. https://github.com/odoo/enterprise/blob/f93882555864a1f0a2a3e3863780096c78923bfa/delivery_sendcloud/models/sendcloud_service.py#L323 ----- Ticket: opw-6295904 Forward-Port-Of: odoo/enterprise#123266

similar to https://github.com/odoo/enterprise/pull/120566/changes/b5b6589c9c91980e41d025ae74082af63907debc When generating an offer from the recruitment application and signing it, the applicant's email address is incorrectly displayed. ### **Steps to Reproduce:** 1) Install sign, recruitment, hr_contract_salary 2) Create an new application and add basic detail like name and email as (path and path@test.com) 3) Generate offer and sign with all the required signer. 4) Open the application form view and open the certificate. ### **Observed Behavior:** Email is not set correctly in the generated certificate (appearing as john@example.com). ### **Expected Behavior:** The email of the applicant should be correctly set(e.g as path@test.com) ### **Root Cause:** When the applicant signs the document, their email is explicitly set to `False` at [1]. This is done because the applicant is not linked to any user yet. Later, when generating the certificate, the system attempts to display the user's partner email at [2], which is `False`, causing the default fallback value (`john@example.com`) to be printed. [1]- https://github.com/odoo/enterprise/blob/49226f4109c7d7bb48340949951e70f4245d0e5b/hr_contract_salary/controllers/main.py#L53-L54 [2]- https://github.com/odoo/enterprise/blob/49226f4109c7d7bb48340949951e70f4245d0e5b/sign/report/sign_log_reports.xml#L59 ### **Fix:** Use `signer_email` instead of the partner's email to ensure the correct email is displayed on the certificate every time. **opw-6280170** Forward-Port-Of: odoo/enterprise#123901 Forward-Port-Of: odoo/enterprise#123767

Issue: The Item Trace Number according to CPA-005 standard should be a nonzero sequence that serves as unique reference ID for payments. Currently, Odoo sets the Item Trace Number of all payments as a zero-filled sequence According to CPA-005 standards on the Item Trace Number: "The data elements (b), (c) and (d) each must be greater than zero or the TRANSACTION WILL BE REJECTED" (page 36). https://www.payments.ca/sites/default/files/standard005eng.pdf Steps to reproduce: 1. Install the module l10n_ca_payment_cpa005 2. Go into "CA Company" 3. In the configuration for "CA Company", add something to the fields "Short Name used in Canadian EFT" and "Company ID" i.e. "CCC" 4. Set all the fields in the "Canadian EFT/CPA Configuration" section of the bank journal 5. Set the bank record on the bank journal. Set the field "Financial Institution ID Number" field of the "Account Number" record of the bank journal to any numerical sequence 6. Create a bank account on "Azure Interior" and make sure to check the field to trust the bank account that you created (otherwise there will be an error) 7. Create two payments with the vendor of "Azure Interior" using the payment method of "Canadian EFT" 8. Create a batch payment for both payments created 9. Validate the batch payment and the export file should show up in the chatter 10. Note that in the export file, the Item Trace Number for each payment is set to be all zeros, whereas it should be a nonzero identification sequence Solution: Set the Item Trace Number to be the payment's id opw-6323432 Forward-Port-Of: odoo/enterprise#123707 Forward-Port-Of: odoo/enterprise#123633

### Issue: On Chilean export invoices, the customs information table may display data in the wrong columns When `Origin Port` or `Destination Port` is not set, the corresponding `td` is omitted by QWeb, causing the remaining columns to shift left This results in `Qty of Packages` appearing under `Origin Port` or `Destination Port` in the printed document ### Cause: `l10n_cl_port_origin_id` and `l10n_cl_port_destination_id` have no default value and are optional fields `t-out` on a falsy value omits the `td` entirely in QWeb, breaking the column alignment Adding `or ''` ensures an empty `td` is always rendered, preserving the table structure regardless of whether the fields are set ### Steps to reproduce: - Install `l10n_cl_edi_exports` and switch to CL Company - Create an Invoice (any customer, any line) - In the gear menu, select Print > Invoice PDF copy (Chile) Before the fix, `Qty of Packages` appears under `Origin Port` when neither port field is set opw-6304670 Forward-Port-Of: odoo/enterprise#121923

Problem: In the Spanish VAT books, taxes with negative component (like 21% EU G) always show their amounts as zero. Steps to reproduce: 1. Install the l10n_es_reports module and select the Spanish company 2. Create a vendor bill with a vendor from another EU country and add a product 3. Make sure the tax applied to the product has a negative component (like 21% EU G) 4. Confirm the bill 5. Go to Accounting > Reporting > Tax Return 6. Generate the VAT books from the action menu and check the tax amounts 7. Notice how the tax amount is zero, even though the tax was applied to the bill Cause: When calculating the tax amounts, the negative component cancels out the positive component, leading to the amount always showing as zero in the VAT books. opw-6169766 Forward-Port-Of: odoo/enterprise#123738