Friday, September 4, 2026
7 changes · 17.0
Resolved issues and error corrections
French branch companies can now activate electronic invoicing without triggering an error when participating in the pilot phase. The fix ensures the system correctly uses the parent company's accounting setup for branches, preventing setup interruptions.
Original PR description
Steps to reproduce: - Create a French parent company and a branch. - Activate Electronic Invoicing (PDP) for the parent company. - Switch to the branch while keeping both the parent company and the…
Steps to reproduce:
- Create a French parent company and a branch.
- Activate Electronic Invoicing (PDP) for the parent company.
- Switch to the branch while keeping both the parent company and the branch selected in the company switcher.
- Go to Settings → French Localization → Activate Electronic Invoicing.
- Activate Electronic Invoicing (PDP) for the branch.
- Select the Participate in the pilot phase checkbox and try to save settings.
Observed behavior:
- A traceback occurs with the error: psycopg2.errors.SyntaxError: syntax error at or near ")" on IN () in the SQL query inside _force_update_l10n_fr_f10_moves.
Cause:
- _force_update_l10n_fr_f10_moves searches for receivable/payable accounts using company_ids IN companies.ids.
- A branch company has no accounts assigned directly to it — accounts belong to the parent company — so the search returns an empty list.
- Passing an empty tuple to IN %(account_ids)s generates IN (), which is invalid PostgreSQL syntax.
Fix:
- Replace ('company_ids', 'in', companies.ids) with ('company_ids', 'parent_of', companies.ids) in the account search inside _force_update_l10n_fr_f10_moves.
- This ensures that accounts owned by a parent company are correctly found when the given companies are branches, since branch companies inherit their parent's chart of accounts.
Backport of PR #277232
opw-6535263Manufacturing Order overviews now calculate costs correctly even when related work orders have no employee assigned. This helps teams rely on accurate production cost summaries without needing extra employee data on every work order.
Original PR description
Description of the issue/feature this PR addresses: Resolves an issue where Manufacturing Order (MO) summary calculations produced incorrect totals when associated Work Orders had no assigned employee. Current behavior before PR: <img width="2419" height="802" alt="mo-wo-employee-fix-before" src="https://github.com/user-attachments/assets/9a0d64b4-2ca3-4732-9ac7-39673e0ae319" /> Short-circuiting the logic when a work order has no associated employee causes an error in the overview's cost calculation. Behavior after PR: <img width="2389" height="641" alt="mo-wo-employee-fix-after" src="https://github.com/user-attachments/assets/f2b67e84-c149-4d05-be30-f834e62e0882" /> By updating it to no longer short-circuit it now correctly calculates the cost of the manufacturing order. opw-6464637
Restored or copied databases with neutralization enabled are now neutralized before background jobs can detect and run on them. This prevents automated tasks from accidentally executing during a short setup window, reducing the risk of unintended emails, actions, or integrations from copied databases.
Original PR description
Before this commit: If you restore a backup or duplicate a database via /web/database/manager with "Neutralize" enabled, the cron workers had a small window between the creation of the Registry and the neutralization of the database where they could try to execute crons. Since neutralize_database does not require a full registry to run (it only does raw SQL operations), we can run it before the Registry creation (which has the effect, among other things, of making the cron workers aware of the new database). opw-6517819
This update refreshes the spreadsheet component and fixes an issue where users could not reliably scroll to the last cell. It improves spreadsheet navigation and reduces friction for users working with larger sheets.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/c25210dded [REL] 17.0.107 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/bea9f018be [FIX] viewport: scroll to the last cell [Task: 6103620](https://www.odoo.com/odoo/2328/tasks/6103620) Co-authored-by: Florian Damhaut (flda) <flda@odoo.com> Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com> Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com> Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com> Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com> Co-authored-by: Ronak Mukeshbhai Bharadiya (rmbh) <rmbh@odoo.com> Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com> Co-authored-by: Rémi Rahir (rar) <rar@odoo.com> Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com> Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com> Co-authored-by: Marceline Thomas (matho) <matho@odoo.com>
The Luxembourg balance sheet now places two investment-related accounts in the correct report categories. This helps companies produce accurate statutory financial reports and avoid misclassification of own shares versus other investments.
Original PR description
Currently, the Luxembourg Balance Sheet incorrectly maps accounts `502000` and `503000` under the `III. Investments` section. **Steps to reproduce:** - Install the `l10n_lu_reports` module and switch…
Currently, the Luxembourg Balance Sheet incorrectly maps accounts `502000` and `503000` under the `III. Investments` section. **Steps to reproduce:** - Install the `l10n_lu_reports` module and switch to the `LU Company`. - Navigate to Accounting > Accounting > Journal Entries and create and post two journal entries: - One with account `502000 Own shares or own corporate units`. - Another with account `503000 Shares in undertakings with which...`. - Navigate to Reporting > Balance Sheet and check the `III. Investments` section. **Observation:** - `502000 (Own shares...)` is wrongly added under `3. Other investments`. - `503000 (Shares in undertakings...)` is wrongly added under `2. Own shares`. In the generated XML report: - `502000 (Own shares...)` balance is added inside `<NumericField id="195">`. - `503000 (Shares in undertakings...)` balance is added inside `<NumericField id="209">`. **Expected behavior:** According to the Luxembourg documentation mapping tables [1], - Account `502000 (Own shares...)` should be mapped to `<NumericField id="209">`. - Account `503000 (Shares in undertakings...)` should be mapped to `<NumericField id="195">`. **Root Cause:** At [2], the `account_codes_formula` values are incorrectly assigned: account code `503` is mapped under `2. Own shares`, while account code `502` is mapped under `3. Other investments`. This reverses the expected mapping of the two accounts in the Balance Sheet report. [1]: https://ecdf.b2g.etat.lu/ecdf/pcnMappingTables [2]: https://github.com/odoo/enterprise/blob/29c186827f0171292f1243e0deb8fe040c027a89/l10n_lu_reports/data/account_financial_html_report_bs.xml#L335-L348 opw-6275340
The Turkish e-Ledger export now fills line numbers automatically and keeps them continuous across monthly filings within the same fiscal period. This helps ensure reports meet GIB expectations and prevents manual renumbering or inconsistent numbering between monthly and annual exports.
Original PR description
Before: the `LineNumber` column of the e-Ledger CSV was always empty, left to be filled after the export. Since the ledger is filed monthly, whatever filled it restarted at 1 every month, while GİB expects the numbering to start once, at the beginning of the fiscal period, and to run unbroken until its end. Now: the column is written by the export. An export starting after the first day of the fiscal period is offset by the number of rows that period already counts, so February continues where January stopped, and a full-year export numbers the same rows identically. The lines are also read in ascending date order. They were sorted by the default order of `account.move.line`, the most recent first, so the first row of the file was the last entry of the period and could not be numbered 1. This reverses `EntryNumberCounter` as well, which now counts from the oldest entry. task-6424730
This fix ensures serial numbers chosen for subcontracted components are carried over when production is split into multiple steps. It prevents receipt validation errors and helps users complete subcontracting purchases without manual corrections or blocked inventory flows.
Original PR description
1. Install `mrp_subcontracting_purchase`. 2. Create a storable product 'demo prod' with tracking set to serial and route `Buy` 3. Create another storable product 'demo comp' with tracking serial and…
1. Install `mrp_subcontracting_purchase`. 2. Create a storable product 'demo prod' with tracking set to serial and route `Buy` 3. Create another storable product 'demo comp' with tracking serial and route, `Resupply Subcontractor on Order.` 4. Create a subcontracting BoM for 'demo prod', add demo comp as a component and assign a subcontractor. 5. Create a Purchase Order for the subcontractor with 2 units of `demo prod`. 6. Confirm the PO and go to the resupply transfer. 7. Select 2 serial numbers for 'demo comp' and validate the transfer. 8. Go to the source receipt and click Record Components. 9. Enter quantity 1 and choose one serial number, then click Continue. 10. For the remaining quantity, choose the second serial number and click Record Components again. 11. Try to validate the picking. Observation: - Not able to validate picking, there is an error as below: Invalidate Operation, 'You must enter a serial number for each line of demo comp' Issue: - While selecting quantity, producing one by one, a new subcontracted production is created for the remaining quantity, and the newly created production's stock move line does not have a serial number, which should be selected. According to the resupply record - Note, for the first subcontract production, you will be able to see the Lot/serial number in the stock move line, for the next production Lot/serial number is empty. Also, it's not a required field to notify the customer that he had to fill in the value. - Once 'Record Components' is clicked, we don't change it. Unfortunately, Picking is not valid. Solution: - Set the serial number for new production while creating. opw-4873363, 4817865, 4893405 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr