Daily updates from Odoo
Monday, May 11, 2026
16 changes · 17.0
Resolved issues and error corrections
This update fixes a potential crash during bank statement imports by ensuring the correct journal is selected based on currency and IBAN. The system now validates and automatically finds the appropriate journal, preventing errors and improving data accuracy for users importing financial statements.
Original PR description
Behavior before: The import flow could crash with an "Expected singleton" error if multiple journals shared an IBAN. Additionally, the system blindly accepted the current context ('self') as the…
Behavior before:
The import flow could crash with an "Expected singleton" error if multiple
journals shared an IBAN. Additionally, the system blindly accepted the
current context ('self') as the target journal, even if its currency or
bank account mismatched the statement, often leading to avoidable
UserErrors.
Behavior after:
The system now validates 'self' against the statement's currency and IBAN
before assignment. If a mismatch is found, it automatically searches for
the correct journal. The search is now restricted by currency and includes
a limit=1 to prevent crashes and ensure accurate selection.
Root Cause:
In _find_additional_data(), 'journal = self' was assigned without validation.
Furthermore, the fallback search lacked a record limit and currency matching
logic, allowing multiple records to be returned when duplicates or
multi-currency setups existed.
Fix:
- Added validation for the initial 'self' candidate (currency and IBAN match).
- Refined the search domain to include currency matching (journal or
company fallback).
- Added limit=1 to the search to guarantee a singleton recordset.
opw-5462037This update corrects a reporting issue where planned hours weren't correctly excluded on public holiday days. The fix ensures that only public holidays related to the employee's company are considered when generating timesheet forecasts, improving reporting accuracy and preventing over-allocation of time.
Original PR description
## Steps to reproduce: - Install project_timesheet_forecast module - Create a public holiday in one company - In another company create a planning slot for an employee that overlaps with the holiday - Go to Timesheets/Planning analysis report - Notice the report is not showing planned hours for the employee on the day of the public holiday ## Cause: When filtering the resource_calendar_leaves we don't check for the company so any public holiday in any company will be taken into account even if it doesn't affect the employee ## Fix: Exclude holidays that has different company than the planning slot opw-5027070
This update resolves a validation error that occurred when creating intercompany invoices between companies using different tax regions. The fix ensures accurate tax calculations by correctly applying and recomputing taxes based on the intended fiscal position, preventing incorrect error messages. This improves the reliability of intercompany transactions.
Original PR description
**Steps to reproduce:** * Install the *Accounting* module. * Install localisation modules for two different regions: * *Belgium* (**l10n_be**) * *Luxembourg* (**l10n_lu**) * Configure two companies,…
**Steps to reproduce:** * Install the *Accounting* module. * Install localisation modules for two different regions: * *Belgium* (**l10n_be**) * *Luxembourg* (**l10n_lu**) * Configure two companies, each assigned to one of the above regions. * Create fiscal positions: * In the Belgium company, create a fiscal position for Luxembourg. * In the Luxembourg company, create a fiscal position for Belgium. * Go to *Accounting > Configuration > Settings*. Enable *Inter-Company Transactions*. Enable synchronization of *Vendor Bills and Invoices* for both companies. * Create an invoice in the Luxembourg company. Select a partner belonging to the Belgium company. Add a product with applicable taxes. **Observed behavior:** * A validation error is raised: 'This entry contains taxes that are not compatible with your fiscal position. Please check the country set in the fiscal position and in your tax configuration.' **Cause:** * During intercompany bill creation, a foreign fiscal position is applied before recomputing taxes. * If no mapped foreign taxes exist, the system keeps domestic purchase taxes. * This leads to a mismatch between taxes and fiscal position, triggering the validation error. **Fix:** * Add a safeguard in *_inter_company_create_invoices()*. * After *_inter_company_sync_invoice_line_taxes()* recomputes taxes, *_inter_company_has_incompatible_fiscal_position_taxes()* checks whether the fiscal position is incompatible. * If incompatible, the fiscal position is removed and taxes are recomputed without it. opw-6103671
This update resolves a duplication issue where the contract type ID was appearing twice in the HR offer form view for the Belgian localization. The code was corrected to ensure consistent contract type definitions across modules, preventing errors and improving data accuracy. This change is specific to version 17 and will be addressed in a separate PR after that.
Original PR description
[IMP] hr_contract_salary: fix contract_type_id definition The definitions of the contract_type_id in hr_contract_salary_offer and l10n_be_hr_contract_salary/hr_contract_salary_offer should be same I converted the definition of contract_type_id in the base module to the Belgium one. Also, the contract_type_id was inserted to the view in Belgium one as well, I deleted that part to prevent double appearance. This task is only for v.17, after this version I will open a new PR to handle them. Do not forward the task after v.17 (only for v.17) task - 6101717
This update fixes an issue where discount lines in Czech VAT reports (vies) were incorrectly calculated. The previous system applied an absolute value function, leading to inflated report totals. The fix now correctly handles negative discount amounts, ensuring accurate VAT reporting for Czech companies.
Original PR description
Step to reproduce: - install l10n_cz_reports_2025 and switch to cz company - create a invoice, with cz company ( as partner), of 100. - when adding products, add "Transaction code" (optional fields) to "Goods" - Add discount line, set to -10, add "Transaction code" in this line too. - confirm it Observation: - invoice is 90$ - open vies summary report for this year - value turn out to 110 Cause: - commit [1](https://github.com/odoo/enterprise/commit/892268c44b1bbc838a9f03ef36a079bfff625ca6) converts every balance to +ve and only negate it, in case of refund - in case of discount lines, price is -ve, ABS() turn it to +ve and value comes out to be wrong Fix: - instead of applying ABS() directly, we flip the signs only for out_* moves, in short when a account is credited, its balance is < 0 then we flip its sign opw- 5979262
This update resolves an issue where Swedish financial data files were not importing correctly due to encoding differences. The fix ensures that account names with special characters (like 'Ö') are accurately imported, preventing data loss and ensuring correct financial reporting for Swedish customers. This improves data integrity and accuracy.
Original PR description
Issue: Non-ASCII charatcter from sie file were lost on import. Steps to reproduce: - in a Swedish company - import the SIE4 exemple file from sie website: https://sie.se/wp-content/uploads/2024/01/SIE4-Exempelfil-Sample-file-1.zip Current behavior: - The account 1090 is imported as "vriga imm anl tillg" instead of "Övriga imm anl tillg" Expected behavior: - The account 1090 is imported as "Övriga imm anl tillg" Cause: CP437 uses 8 bits to represent data. Ö is \x99. However, file was imported using either UTF-8 or ISO-8859-1, where Ö is \xC396 and \x99 doesn't link to anything. This commit update the test file as it was save in cp437 but read as UTF-8. opw-6167408
This update ensures that down payment invoices generated for Mexican EDI (MX EDI) compliance correctly classify clave_unidad and clave_prod_serv as sales transactions, aligning with regulatory requirements. This change, previously implemented in 18.0 and 19.0, is now backported to version 17.0 to maintain accurate reporting and compliance.
Original PR description
When creating down payment invoices for mx edi, clave_unidad and clave_prod_serv (cfdi_line_values) should be considered as sale (ACT - activity and 84111506 code for invoicing services) according to the authorities. This already works for 18.0 and 19.0. Backporting solution for 17.0 task id [6173559](https://www.odoo.com/odoo/project/49/tasks/6173559)
This update corrects a problem where POS invoices created in timezones ahead of Riyadh (like Dubai) would incorrectly set the invoice date, leading to errors. By ensuring the invoice date is always aligned with Riyadh time during POS invoice generation, this fix prevents invoice creation failures for Saudi Arabian businesses and their staff.
Original PR description
Before: - POS orders created by users in timezones ahead of Riyadh (e.g. Dubai, UTC+4) produced an `invoice_date` based on the user's local date, which could be a day ahead of Riyadh. - This caused `_get_normalized_l10n_sa_confirmation_datetime` to raise a UserError blocking POS invoice creation. After: - Overrides `_prepare_invoice_vals` on pos.order to convert date_order (UTC) to Asia/Riyadh and clamp to today's Riyadh date before passing to ZATCA validation. - This override applies only during POS invoice generation, where date_order is the source of truth instead of a manually set invoice_date. Impact: - Fixes UserError on POS invoice creation for SA companies with staff operating in timezones ahead of Riyadh. taskID-6043167
This update fixes a technical issue where Google Calendar attendees with matching email aliases were being silently removed from Odoo events. This meant events would show up with incorrect attendee counts. The change ensures all attendees, even those using aliases, are properly synchronized, maintaining accurate event information.
Original PR description
When a Google attendee's email matches a configured mail alias, the attendee is silently lost during sync — the corresponding partner is excluded from the lookup result, and the event lands in Odoo with one fewer attendee than Google shows. opw-6086240
This update fixes a discrepancy in UBL/CII e-invoice exports caused by rounding differences. The change ensures that line totals accurately match the overall document total, preventing validation failures and ensuring compliance with invoicing standards. It addresses a technical issue related to how the system calculates and distributes rounding errors.
Original PR description
The sum of individual line extension amounts in UBL/CII exports can sometimes differ from the total expected amount due to cumulative rounding differences. Steps to reproduce: - Configure rounding to…
The sum of individual line extension amounts in UBL/CII exports can sometimes differ from the total expected amount due to cumulative rounding differences. Steps to reproduce: - Configure rounding to Round Globally - Have a Belgium company setup - Have a customer with Peppol enabled - Create an invoice with many lines where each line amount have multiple decimals before rounding (product price precision raised to 4, fixed tax with 4 decimals) - Confirm the invoice Issue: Discrepancy between line totals and the document total in the XML, leading to validation failure `[BR-CO-10]-Sum of Invoice line net amount (BT-106) = Σ Invoice line net amount (BT-131)` Analysis: When generating e-invoice, we calculate the total line extension amount from unrounded line amounts, after adding the fixed taxes https://github.com/odoo/odoo/blob/b71b51ce8e78970104c97f599b533bdcf36484c0/addons/account_edi_ubl_cii/models/account_edi_xml_ubl_20.py#L396-L411 However, the sum of line rounded values may not equal the rounded sum of the raw values. This change tracks the expected rounded sum and compares it to the actual accumulated sum. If a delta exists, it is distributed across the lines to ensure the XML is consistent. Minimalistic backport of d66c299cf7fb781bbba6850d0ca17831aed0475d opw-5871638 Forward-Port-Of: odoo/odoo#251155
This update resolves an issue where the stock return wizard incorrectly unreserved items when a product line was left at a zero quantity or a partial quantity. The fix ensures that only the actual returned quantity is unreserved, preventing over-unreserving and improving the accuracy of stock tracking. This change impacts the handling of partial returns.
Original PR description
Steps to reproduce
1. Configure a 2-step delivery (PICK -> OUT).
2. Confirm and reserve a delivery for multiple products, validate the PICK.
3. Open the return wizard on the validated PICK, OUT moves are now reserved.
4. Leave a product line at qty 0 (instead of deleting it), or reduce a line to a partial quantity (e.g. 1 of 8), then click Return.
Issue
`_create_returns()` iterated over every wizard line via `self.product_return_moves.mapped('move_id')` and called `_do_unreserve()` on the chained OUT move unconditionally, without checking whether that line was actually being returned:
https://github.com/odoo/odoo/blob/2fde70e450a36a258bdb67dcb0bd6646b60a26ff/addons/stock/wizard/stock_picking_return.py#L130-L131
A line left at qty 0 caused its OUT move to be fully unreserved even though nothing was being sent back. A partial return (e.g. 1 of 8) also unreserved all 8 units.
opw-6175293This update resolves issues with the UBL invoice export process when early payment discounts are applied. Specifically, it corrects errors related to incorrect tax subtotal calculations and VAT category assignments, ensuring proper compliance with PEPPOL standards. This prevents validation failures during UBL generation.
Original PR description
…d tax subtotal **STEP TO REPRODUCE** 1. Create an invoice with an early payment discount (payment terms) with an invoice line with a 0% tax. 2. Generate the ubl for the invoice by sending it to…
…d tax subtotal **STEP TO REPRODUCE** 1. Create an invoice with an early payment discount (payment terms) with an invoice line with a 0% tax. 2. Generate the ubl for the invoice by sending it to peppol. 3. Validate the generated ubl, you'll get the following errors: [BR-E-08]-In a VAT breakdown (BG-23) where the VAT category code (BT-118) is "Exempt from VAT" the VAT category taxable amount (BT-116) shall equal the sum of Invoice line net amounts (BT-131) minus the sum of Document level allowance amounts (BT-92) plus the sum of Document level charge amounts (BT-99) where the VAT category codes (BT-151, BT-95, BT-102) are "Exempt from VAT". [BR-S-01]-An Invoice that contains an Invoice line (BG-25), a Document level allowance (BG-20) or a Document level charge (BG-21) where the VAT category code (BT-151, BT-95 or BT-102) is "Standard rated" shall contain in the VAT breakdown (BG-23) at least one VAT category code (BT-118) equal with "Standard rated". [BR-S-06]-In a Document level allowance (BG-20) where the Document level allowance VAT category code (BT-95) is "Standard rated" the Document level allowance VAT rate (BT-96) shall be greater than zero. **CAUSE** - When there is a epd, we append a new tax subtotal. Which means we end up with multiples tax subtotal for the tax category E. We do the same for emptying taxes. The fix add a step that merges all the tax subtotal of the same tax category into one. - When there is a epd, the allowance is generated with with a tax cargory S even with the tax percentage is 0. It should be E for 0% tax. opw-6075910
This update resolves a visual bug where the status bar displayed duplicate information for sub-tasks. The fix ensures that the status bar accurately reflects the task's project association, improving the user experience and data consistency. It corrects a conflict in how the system handles project assignments within sub-tasks.
Original PR description
Steps: - Create a task inside any project. - Create a sub-task under that parent task. - Open the sub-task and remove the project (clear the project field). - Look at the status bar at the top of the form view. Issue: - The status bar is displayed twice (both the Project stages and Personal stages - are visible simultaneously). Cause: - When the project field is cleared from a sub-task in the UI, conflicting visibility rules or residual stage data can cause the status bar widget to render twice. Fix: - To resolve this, an `onchange` event is added to the `project_id` field. If the user removes the project from a sub-task, the system now instantly falls back to the parent task's project and sets `display_in_project = False`. This syncs the frontend UI with the intended backend behavior, preventing the interface from entering the broken state and removing the duplicate status bars. task-6033970
This update fixes a visual issue in the project Kanban view where custom colors weren't being applied to task statuses. The fix ensures that task statuses (identified by backend IDs) are correctly mapped to their designated colors, improving the user experience and visual clarity of the Kanban board.
Original PR description
### The Issue: The frontend Kanban view enforces a strict 12-color limit using a modulo 12 mathematical rule (which calculates the remainder after dividing by 12). When the frontend receives our high backend IDs (20-24), it runs this modulo math (e.g., 23 % 12) to force them into the allowed limit, converting them into the remainders: IDs 8, 9, 10, 11 and 0. Because stylesheet was still searching for the original high numbers (20-24) instead of these modulo results, the custom colors were completely ignored by the browser. ### The Fix: Updated the stylesheet to target the actual modulo-computed classes (.oe_kanban_color_8 through 11 and 0). Mapped these classes to their correct variables (-success, -info, -warning, -danger, -primary) and fixed the left border styling so the colors render properly. task-6064106
This update resolves a confusing user experience where discount codes wouldn't apply after being discarded. Now, users can successfully re-apply discarded codes without creating new reward lines, ensuring a smoother and more intuitive process for applying loyalty discounts. This improves the overall customer experience.
Original PR description
Issue: --- ### Steps to reproduce: 1- Create a `Discount Code` program. 2- In SO, use `Coupon Code` wizard and use the code. 3- After available rewards are shown, discard the wizard. 4- Re-apply the code. Validation Error: The promo code is already applied. As the reward is not applied, this is functionally confusing. At this point We can see the reward only inside the rewards wizard view. If we allow re-apply the code in case no reward line is created for the `rule.program_id`, we can still see the reward by re-applying the same code, without any side effects. opw-6164198
This update resolves an issue where the customer address field in the Point of Sale (POS) for Peru (PE) was not correctly populated, leading to inaccurate shipping address information. The fix ensures the required 'city' field is properly set during customer creation, preventing errors when processing orders and shipments.
Original PR description
Steps to reproduce: ------------------- * Install l10n_pe_pos * Switch to PE company * Create a pos * Enable shipping later for that pos * Open the pos * Make an order * Create a new customer inside the pos, fill in all information * Go to pay the order * Select the ship later option * valdiate > Popup, incorrect address for shipping Why the fix: ------------ The field city_id is a list containing the id of the city and the name string. For the PE loca we were only setting the city_id field when creating a customer and not city. Which is the required field when checking addresses. opw-6070005