Daily updates from Odoo
Sunday, March 15, 2026
15 changes · master
New functionality added to Odoo
This update adds support for fetching currency rates directly from the National Bank of Georgia (NBG). This is required to comply with Georgian tax regulations, ensuring all transactions are accurately translated into the local currency (GEL) using official exchange rates.
Original PR description
This commit adds the National Bank of Georgia (NBG) as a supported service provider for automatic currency rate updates. Purpose: To comply with the Georgian Tax Code (Article 73), taxable transactions must be translated into the national currency (GEL) using the official exchange rate defined by the NBG for the transaction day. Functionality: -Enables fetching official exchange rates directly from NBG. -Automatically handles rates defined for different quantities (e.g, rates quoted per 100 units instead of 1 unit). task-5894623 Forward-Port-Of: odoo/enterprise#107375
This update enhances Odoo's Chile (l10n_cl_edi) module to handle a specific requirement in Chilean accounting. Suppliers can now declare 'Non-Billable Amount' on vendor bills, and this commit ensures that Odoo correctly reads and incorporates this amount when importing bills or fetching them via email, creating accurate invoices.
Original PR description
[IMP] l10n_cl_edi: Non-billable amount in vendor bill In Chile suppliers can declare Non-Billable Amount in the XML This commit add the feature to read the Non-Billable Amount when fetching vendor bills via mail or importing manually, and create the corresponding invoice line. task-5878586
Enhancements to existing features
This update enhances the clarity of statement lines by adding colored bubbles to dropdowns. These bubbles highlight related move lines with identical amounts (currency or amount), making it easier to quickly identify and reconcile transactions. This improves the user experience and reduces the potential for errors.
Original PR description
This will add a new colored bubble on the dropdown of a statement line when there is a move line that has the same amount currency or amount. task-5493859 Forward-Port-Of: odoo/enterprise#104896
Resolved issues and error corrections
This update fixes a technical issue related to XML files used for processing payments in Sweden (SEPA). Specifically, the XML format has been corrected to align with the required `<BICFI>` node, ensuring proper communication with financial institutions. This ensures accurate and compliant payment processing in the Swedish market.
Original PR description
In Sweden, pain.001.001.09 XML files should use `<BICFI>` node, not `<BIC>`. This commit fix an XML test file to use BICFI. runbot-241221 Forward-Port-Of: odoo/enterprise#109930
This update ensures Odoo invoices sent to AFIP (ARCA) comply with their requirements for numeric fields like price and quantity. By limiting precision to 3 decimal places, we prevent invoice rejections and maintain accurate accounting data. This change aligns with AFIP's specifications and ensures consistent rounding across all monetary amounts.
Original PR description
… request ARCA requires numeric fields such as unit price and quantity to have a maximum of 12 integer digits and 6 decimal places. If these fields are sent with more than 6 decimals, AFIP rejects…
… request ARCA requires numeric fields such as unit price and quantity to have a maximum of 12 integer digits and 6 decimal places. If these fields are sent with more than 6 decimals, AFIP rejects the invoice with errors like: `Code 1814: Campo Cmp.Items.Pro_precio_uni invalido. El valor debe tener 12 enteros y 6 decimales como máximo.` To ensure compliance, values are formatted before sending the request to ARCA. **Precision rationale** ARCA WS documentation mentions 4 decimal places, while the WS error message itself refers to 6 decimals, and in practice the service accepts up to 6 decimals without rejection. In this implementation, we intentionally use 2 decimal places. The reason is consistency with the rest of the monetary amounts in the invoice: line totals, invoice total, taxes, and related amounts are all rounded to 2 decimals, even in cases where the documentation allows higher precision (e.g., 3 decimals). Before the changes in rounding precision, the stable version already rounded values according to line rounding. In real-world accounting scenarios, the vast majority of use cases operate with 2 decimal places. Keeping this behavior ensures consistency across calculations and avoids discrepancies caused by mixed rounding strategies. For a stable release, this was considered the safest and most predictable option, even though the WS technically allows higher precision. Stable version changes are covered in the following commits: https://github.com/odoo/odoo/pull/243987/changes/8a21ec45f9d72a7c80d9c1f8398fe01e298ae775 https://github.com/odoo/odoo/pull/246347/changes/79ceeed707ef274f19a04e741f6cb8ac60c44321 <img width="780" height="435" alt="image" src="https://github.com/user-attachments/assets/9f25a0e8-b9d2-4ad2-bbcf-e988c7f8a4c9" /> [WSFEX - Manual de desarrollador](https://www.afip.gob.ar/ws/WSFEX/WSFEX-Manualparaeldesarrollador.pdf) Forward-Port-Of: odoo/enterprise#110218 Forward-Port-Of: odoo/enterprise#106509
This update ensures that the country associated with a phone number in the softphone interface always matches the number's normalized format (+1, etc.). Previously, the system incorrectly used the selected country flag as a fallback, leading to inconsistencies. A new test has been added to verify this fix.
Original PR description
When parsing a keypad number, we were formatting the phone number with a fallback country (from the currently selected flag) but still resolving the returned country/flag from the pre-format parsing context (see [1]). This could lead to inconsistencies where the number is normalized as +1... while the UI country remains the previously selected one (e.g. Belgium). This commit recomputes country information from the formatted number before returning countryId/storeData, so the softphone flag matches the normalized phone number. Also adds a controller regression test covering this behavior. [1]: https://github.com/odoo/enterprise/commit/708aea78760392207f9148c31c67212dacaf3294 task-5995387 Forward-Port-Of: odoo/enterprise#110479 Forward-Port-Of: odoo/enterprise#109365
This update ensures that Danish SEPA payments are correctly formatted with the required FIK reference, resolving an issue where the payment XML was missing this crucial detail. The changes also improve the system's ability to handle country-specific structured references, making it more robust and future-proof.
Original PR description
Issue: - A related PR introduced Danish FIK payment references on customer invoices. - The generated SEPA payment XML did not include this reference, resulting in missing structured communication for Danish payments. IMP: - Extended the SEPA payment XML generation to include the Danish FIK reference when present. - Refactored the structured reference XML builder to use lxml elements instead of string-based XML construction, ensuring proper escaping of structured references. Impact: - Ensures compliant Danish SEPA payments with correct FIK references. - Makes SEPA XML generation future-proof for country-specific structured references containing non-numeric characters. Related PR: https://github.com/odoo/odoo/pull/240829 Task: 5401553 Forward-Port-Of: odoo/enterprise#102612
This update corrects a naming inconsistency within the HR payroll module. The template's name was previously set to a subdirectory, which has now been simplified to align with standard Odoo module naming conventions. This ensures better organization and clarity within the system.
Original PR description
Currently in hr_payroll, the template name is set as l10n_be_hr_payroll.DropdownSelectionBadge. Generally, it should follow the module name. Therefore, in this commit, I replaced l10n_be_hr_payroll with hr_payroll Forward-Port-Of: odoo/enterprise#110243
This update resolves a technical issue that caused export errors when working with worksheet templates in Odoo Enterprise. The fix removes outdated code references that were triggering errors related to missing data fields, ensuring consistent and reliable exports for this feature.
Original PR description
Before this commit when exporting records from the `worksheet.template` model , it raises a traceback regarding the `model_id`, `action_id` which are not present on the `worksheet.template` anymore* In this commit we are updating the export logic by removing the custom logic for the `worksheet.template` model. *https://github.com/odoo/enterprise/pull/104754 Forward-Port-Of: odoo/enterprise#110079
This update resolves an issue preventing users from correctly setting up Amazon accounts when using multiple companies within Odoo Enterprise. The fix allows access to all company data during the onboarding process, ensuring compatibility with connected Amazon accounts. This improves the user experience and avoids errors related to company mismatches.
Original PR description
The onboarding return route is a website route with access restricted to the website company only. This causes an error when the company doesn't match the Amazon account being connected. This commit allows users to access all their companies during Amazon account setup to avoid this mismatch error. opw-5944078 Forward-Port-Of: odoo/enterprise#110081 Forward-Port-Of: odoo/enterprise#109590
This update fixes an issue where equity reports were incorrectly using historical currency rates for certain accounts. The code was adjusted to ensure the correct rate type ('current') is applied, resulting in more accurate financial reporting. This ensures the integrity of equity-related financial data.
Original PR description
Due to the order of the CASE statement, `equity_unaffected` accounts used 'historical' rate_type Change the order of the CASE statement. no-task Forward-Port-Of: odoo/enterprise#110112
This update prevents an infinite loop in the claim status polling process for credit notes (DTE 61). The fix restricts the polling domain to only invoices, addressing a technical issue where the system incorrectly processed credit notes through the SII endpoint. This ensures efficient claim status updates.
Original PR description
Claimed credit notes (DTE 61) were being polled indefinitely by the _l10n_cl_ask_claim_status cron. The SII endpoint listarEventosHistDoc does not support DTE 61 and always returns codResp 3 "Tipo de…
Claimed credit notes (DTE 61) were being polled indefinitely by the _l10n_cl_ask_claim_status cron. The SII endpoint listarEventosHistDoc does not support DTE 61 and always returns codResp 3 "Tipo de documento no corresponde". Since the response never contains event data, l10n_cl_claim is never set, the record permanently matches the cron domain, and polling repeats every 4 hours forever. Root cause: the cron domain included out_refund move types, but the SII endpoint used to fetch claim events does not support credit note document types. There is no point querying the SII for claim details on credit notes through this endpoint. Fix: restrict the cron domain to out_invoice only Before: claimed credit notes matched the cron domain, _get_dte_claim was called on every run, SII returned codResp 3, l10n_cl_claim stayed False, record never exited the domain. After: credit notes are excluded from the cron domain entirely and are never polled, stopping the infinite loop. opw-5933833 Forward-Port-Of: odoo/enterprise#109995
This update resolves an issue where the fiscal data module wasn't properly loaded in the point-of-sale system. By adding the necessary field, this change ensures the module is available for use in the point-of-sale interface, improving functionality and data accessibility.
Original PR description
Before this commit, the field iface_fiscal_data_module was not loaded in the pos_self_data, which caused it to be unavailable in the js side of the pos. This commit adds the field to the list of loaded fields, making it available for use in the js code. opw-6034196 Forward-Port-Of: odoo/enterprise#110519
This update resolves conflicts in how transactions are managed for the German POS system (l10n_de_pos_cert), particularly when using the API. It ensures that transactions are correctly cancelled or finished, preventing errors and improving data accuracy. This change focuses on stability and reliability of the POS process.
Original PR description
Changes:
- cancelActiveTransactions: use the TSS-scoped endpoint
/tss/{tss_id}/tx and filter results by client_id so only orphaned
transactions from this terminal are cancelled, never those from
other POS sessions sharing the same TSS
- transactionCall: on non-retryable errors (400 revision conflict or
terminal state mismatch), call _handleTransactionStateConflict which
GETs the actual transaction state and recovers:
- Cancelling already CANCELLED → silent success
- Finishing already FINISHED → return existing tx data
- Finishing a CANCELLED tx → create a fresh transaction and finish it
- handleFiskalyCancellation: correctly reset transactionState to
inactive on the uiState after cancellation
opw-5972708
Forward-Port-Of: odoo/enterprise#110400
Forward-Port-Of: odoo/enterprise#109996This update removes a confusing zoom feature from the scatter plot chart in the Enterprise edition. This change aligns with upcoming functionality that will allow users to manually adjust axis ranges. This simplifies the chart experience and prepares for more granular control.
Original PR description
## Task Description This PR aims to remove the zoomable feature for the scatter plot, as it's kind of non-sense to be able to zoom on an axis and not on the other for this type of chart. Moreover, we will soon be able to manually set the min/max of each axis manually (in master). ## Related Task - Task: 5388389 Forward-Port-Of: odoo/enterprise#106189