Odoo Changelog — 2026-02-25

Wednesday, February 25, 2026

6 changes · 17.0

Bug Fixes(6)

Resolved issues and error corrections

[FIX] account_reports: Correct account selection for branch companies in Ledger Excel export.

Enterprise17.0accountMedium

This update resolves an issue where the General Ledger Excel export was blank when generating reports from branch companies. The fix ensures that all relevant financial data, including accounts and journal entries, are correctly included in the exported file, providing accurate reporting for branch operations.

Original PR description

Behavior before:
When exporting the General Ledger to Excel from a branch company, the generated file was empty.

Behavior after:
The General Ledger Excel export now correctly includes all relevant data for branch companies.

Root cause:
The SQL query used to retrieve accounts did not properly account for multi-company hierarchies. In a branch setup, the chart of accounts is typically defined on the parent company, while the journal entries (account_move_line) belong to the branch company. As a result, conditions such as aml.company_id = account.company_id or account.company_id IN company_ids returned no records, leading to an empty export.

Steps to reproduce:

1. Create a branch company.

2. Create invoices in the branch company using accounts from the parent company.

3. Open the General Ledger report and export it to Excel.

4. The exported file is empty.

OPW: 5901758

#reporting#branch#ledger#export

[FIX] account_reports: fix blank General Ledger XLSX for branches

PR #107894

Enterprise17.0accountMedium

This update resolves an issue where the General Ledger XLSX export for branch companies was blank. The fix ensures that branch companies correctly display their transactions in the XLSX file by properly considering the parent company hierarchy and transaction company IDs. This improves reporting accuracy for branch financial data.

Original PR description

**Steps to reproduce:**
* Install **Accounting** module.
* Create a **branch company** with a parent company.
* Create and post an invoice for the branch.
* Go to **Accounting → Reporting → Profit & Loss**.
* Switch to the **branch company**.
* Click an report line **⋮ → General Ledger**.
* Click **Download XLSX**.

**Observed behavior:**
* The exported XLSX file is **blank**.
* The report displays correctly in the UI, but the XLSX export shows no accounts.

**Cause:**
* `_get_accounts_with_move_lines` filtered accounts with `account.company_id IN company_ids`, while accounts are defined on the **parent company** and shared with branches via `check_company_domain_parent_of`. When only a branch is selected, no accounts match.
* The AML existence check used `aml.company_id = account.company_id`, but AMLs are recorded with the **branch's company_id**, not the parent’s, so the join never matches branch transactions.
* Additionally, `export_to_xlsx` passed the raw `options` to `_get_accounts_with_move_lines` instead of the regenerated `report_options`, leading to an inconsistent company context.

**Fix:**
* Search accounts using the **parent hierarchy**.
* Still filter move lines by the selected branch company.
* Branches now see parent accounts with only their own transactions in the XLSX export.

opw-5902062

[FIX] l10n_sa: fix timezone issue ZATCA

PR #249445

Core17.0l10n_sa_ediMedium

This update resolves a problem where ZATCA invoices were being sent with an incorrect issue date due to timezone differences. The fix ensures the invoice date is accurately formatted for ZATCA submission, preventing a common error and improving invoice processing for Saudi Arabia. This change addresses a technical issue related to ZATCA compliance.

Original PR description

When sending an invoice to ZATCA between 21:00 and 23:59 UTC, the following ZATCA error appears:

[400] BR-KSA-04: The document issue date (BT-2) must be less than or equal to the current date.

This is caused by the field l10n_sa_confirmation_datetime in _post of l10n_sa/account_move, which combines the date and the time in UTC.

In _export_invoice_vals, we reconvert this field to UTC+3 (Asia/Riyadh).

Example:
Current time UTC+3: 2026-02-19 02:45:00
Stored as UTC: 2026-02-18 23:45:00
(Before the fix) Sent to ZATCA as UTC+3: 2026-02-20 02:45:00 (in the future)
(After the fix) Sent to ZATCA as UTC+3: 2026-02-19 02:45:00

opw-5450479




---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

#ZATCA#Saudi Arabia#invoice#timezone

[FIX] account_reports: Export branch amls with parent accounts

PR #108532

Enterprise17.0accountMedium

This update fixes a limitation in the General Ledger export by ensuring that branch accounts linked to parent company accounts are now included. Previously, the system excluded these lines, leading to incomplete reporting. This change improves the accuracy of financial reports for branch operations.

Original PR description

The PR #103329 explicitly excludes `account.move.lines` with accounts that do not match their company. However, branches can use the accounts of their parent company, and thus these lines should be reported in a General Ledger export.

[opw-5499234](https://www.odoo.com/odoo/unassigned-tasks/5499234)

#reporting#accounting#branch

[FIX] account_reports: add initial balance for GL csv export

PR #108344

Enterprise17.0accountMedium

This update fixes a bug in the General Ledger CSV export by adding an initial balance line, ensuring accurate reporting. It also corrects rounding logic to properly handle currency conversions, improving the reliability of financial data exports. This ensures consistent and accurate financial reporting.

Original PR description

1) 8dfe4c06106029f3f8039afc863bcacf7057106f added a csv export ledger for the general ledger, but it doesn't handle the initial balance. The fix is to call `_get_initial_balance_values` in the export method, as the query doesn't compute the initial balance lines.

2) Also changing the rounding logic, as currently the currency used is always the company currency, but for `amount_currency` it should use `currency_id`.

task-5734354

#reporting#finance#csv#export

[FIX] stock_barcode: prevent double quantities on click of back navigation

PR #103130

Enterprise17.0stockMedium

This update resolves an issue where rapidly clicking the 'Back' button during barcode internal transfer creation resulted in duplicate quantities being added to the transfer. The fix ensures that the quantity is saved correctly, preventing data inconsistencies and improving the accuracy of inventory tracking.

Original PR description

**Steps to reproduce:** * Install `stock` module. * Go to the > Settings*, enable *Packages* and *Storage Locations*(warehouse). * Create a storable product and set *Tracking Inventory* to **By…

**Observed behavior:**
* The internal transfer is created with *double quantities*
compared to what was added in the barcode interface.

**Cause:**
* When clicking the *Back* button, the following flow is triggered:
`exit()` → `beforeQuit()` → `save()`.
https://github.com/odoo/enterprise/blob/07ede9bda567d94da27da79b945e2189fa5aca6e/stock_barcode/static/src/components/main.js#L406-L414

https://github.com/odoo/enterprise/blob/07ede9bda567d94da27da79b945e2189fa5aca6e/stock_barcode/static/src/models/barcode_model.js#L473-L475

https://github.com/odoo/enterprise/blob/07ede9bda567d94da27da79b945e2189fa5aca6e/stock_barcode/static/src/models/barcode_picking_model.js#L828-L832

https://github.com/odoo/enterprise/blob/07ede9bda567d94da27da79b945e2189fa5aca6e/stock_barcode/static/src/models/barcode_model.js#L477-L483
* If the button is clicked multiple times rapidly, `exit()` is called
again before the previous `save()` RPC completes.
* This results in multiple `save()` calls being executed, causing
duplicated quantities on the picking.

reference - https://github.com/odoo/enterprise/pull/103999/changes/b791239c154deb6a25f85d65ebc72e3ac53b6c74

**Fix:**

* Prevent rapidly clicking the Back button multiple times
does not multiply quantities.

---
opw-5375899

Behavior before: When exporting the General Ledger to Excel from a branch company, the generated file was empty. Behavior after: The General Ledger Excel export now correctly includes all relevant data for branch companies. Root cause: The SQL query used to retrieve accounts did not properly account for multi-company hierarchies. In a branch setup, the chart of accounts is typically defined on the parent company, while the journal entries (account_move_line) belong to the branch company. As a result, conditions such as aml.company_id = account.company_id or account.company_id IN company_ids returned no records, leading to an empty export. Steps to reproduce: 1. Create a branch company. 2. Create invoices in the branch company using accounts from the parent company. 3. Open the General Ledger report and export it to Excel. 4. The exported file is empty. OPW: 5901758

**Steps to reproduce:** * Install **Accounting** module. * Create a **branch company** with a parent company. * Create and post an invoice for the branch. * Go to **Accounting → Reporting → Profit & Loss**. * Switch to the **branch company**. * Click an report line **⋮ → General Ledger**. * Click **Download XLSX**. **Observed behavior:** * The exported XLSX file is **blank**. * The report displays correctly in the UI, but the XLSX export shows no accounts. **Cause:** * `_get_accounts_with_move_lines` filtered accounts with `account.company_id IN company_ids`, while accounts are defined on the **parent company** and shared with branches via `check_company_domain_parent_of`. When only a branch is selected, no accounts match. * The AML existence check used `aml.company_id = account.company_id`, but AMLs are recorded with the **branch's company_id**, not the parent’s, so the join never matches branch transactions. * Additionally, `export_to_xlsx` passed the raw `options` to `_get_accounts_with_move_lines` instead of the regenerated `report_options`, leading to an inconsistent company context. **Fix:** * Search accounts using the **parent hierarchy**. * Still filter move lines by the selected branch company. * Branches now see parent accounts with only their own transactions in the XLSX export. opw-5902062

When sending an invoice to ZATCA between 21:00 and 23:59 UTC, the following ZATCA error appears: [400] BR-KSA-04: The document issue date (BT-2) must be less than or equal to the current date. This is caused by the field l10n_sa_confirmation_datetime in _post of l10n_sa/account_move, which combines the date and the time in UTC. In _export_invoice_vals, we reconvert this field to UTC+3 (Asia/Riyadh). Example: Current time UTC+3: 2026-02-19 02:45:00 Stored as UTC: 2026-02-18 23:45:00 (Before the fix) Sent to ZATCA as UTC+3: 2026-02-20 02:45:00 (in the future) (After the fix) Sent to ZATCA as UTC+3: 2026-02-19 02:45:00 opw-5450479 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

The PR #103329 explicitly excludes `account.move.lines` with accounts that do not match their company. However, branches can use the accounts of their parent company, and thus these lines should be reported in a General Ledger export. [opw-5499234](https://www.odoo.com/odoo/unassigned-tasks/5499234)

1) 8dfe4c06106029f3f8039afc863bcacf7057106f added a csv export ledger for the general ledger, but it doesn't handle the initial balance. The fix is to call `_get_initial_balance_values` in the export method, as the query doesn't compute the initial balance lines. 2) Also changing the rounding logic, as currently the currency used is always the company currency, but for `amount_currency` it should use `currency_id`. task-5734354

**Steps to reproduce:** * Install `stock` module. * Go to the > Settings*, enable *Packages* and *Storage Locations*(warehouse). * Create a storable product and set *Tracking Inventory* to **By Quantity** and set some *barcode* * Update the on-hand quantity for the product and assign it to one packages. * Open *Barcode > Operations > Internal Transfer* and create a new transfer. * Click the *gear icon* in the top-right corner to open the barcode scanning flow. * manually enter the created product barcode and apply it. * Click the **Back** button multiple times in quick succession. * Go to the backend and open the created internal transfer. **Observed behavior:** * The internal transfer is created with *double quantities* compared to what was added in the barcode interface. **Cause:** * When clicking the *Back* button, the following flow is triggered: `exit()` → `beforeQuit()` → `save()`. https://github.com/odoo/enterprise/blob/07ede9bda567d94da27da79b945e2189fa5aca6e/stock_barcode/static/src/components/main.js#L406-L414 https://github.com/odoo/enterprise/blob/07ede9bda567d94da27da79b945e2189fa5aca6e/stock_barcode/static/src/models/barcode_model.js#L473-L475 https://github.com/odoo/enterprise/blob/07ede9bda567d94da27da79b945e2189fa5aca6e/stock_barcode/static/src/models/barcode_picking_model.js#L828-L832 https://github.com/odoo/enterprise/blob/07ede9bda567d94da27da79b945e2189fa5aca6e/stock_barcode/static/src/models/barcode_model.js#L477-L483 * If the button is clicked multiple times rapidly, `exit()` is called again before the previous `save()` RPC completes. * This results in multiple `save()` calls being executed, causing duplicated quantities on the picking. reference - https://github.com/odoo/enterprise/pull/103999/changes/b791239c154deb6a25f85d65ebc72e3ac53b6c74 **Fix:** * Prevent rapidly clicking the Back button multiple times does not multiply quantities. --- opw-5375899