Daily updates from Odoo
Saturday, March 14, 2026
11 changes · 19.0
Resolved issues and error corrections
This update resolves a problem where work orders weren't correctly tracking component consumption. The previous changes introduced unintended consequences, so we've reverted them. Additionally, a test has been updated to ensure this issue is properly addressed moving forward.
Original PR description
Commit [1] has been merged with another commit OC side. However, the latter has impacted some other use cases. This is the reason why we need to revert both. The current commit also improves a test in `test_consume_component.py` to cover the case that has been broken [1] 75febe5a72f091a9940b27c7a59a31f3fe3c407a opw-5939156
This update resolves a technical issue related to XML files used for processing payments in Sweden (SEPA). The change ensures the correct XML format is used, specifically switching from `<BIC>` to `<BICFI>` nodes, which is required by Swedish banking standards. This ensures seamless payment processing for our Swedish customers.
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 resolves an issue where scanning packaging barcodes didn't correctly link to associated lots, leading to incorrect inventory tracking. The fix ensures that packaging barcodes accurately identify and link to the correct lots during scanning, improving inventory accuracy and usability.
Original PR description
When scaning a lot after a packaging, the lot won't recognize the packaging and will not work properly ### Steps to reproduce: * In the settings enable packagings * Create a storable product P with…
When scaning a lot after a packaging, the lot won't recognize the packaging and will not work properly ### Steps to reproduce: * In the settings enable packagings * Create a storable product P with Units as uom, a barcode and tracked by lots * Create new lots with barcode for Product P * Inventory > Configuration > Product > Units & Packagings * Click on pack of 6 > Packaging Barcodes > New * Create one for your product with a different barcode * Go to barcode > Operations > eg. internal transfer > New * Scan packaging barcode * Scan one of the lots -> Issue, the lot create a new line, and will not find the packaging ### Observation: When scanning a barcode, it will first try to find a match with existing lines, In our case, it will find a match with the line of the packaging, but since the line is considered as "completed" since there was no expected quantity since we create a new picking: https://github.com/odoo/enterprise/blob/13d815457d47846d5391c9a2dc1ed244ef64b6c4/stock_barcode/static/src/models/barcode_picking_model.js#L1497-L1501 It will erase the line, to avoid to overfill a completed line: https://github.com/odoo/enterprise/blob/13d815457d47846d5391c9a2dc1ed244ef64b6c4/stock_barcode/static/src/models/barcode_model.js#L1459-L1460 and since, it decided to ignore that line, it will not find another lines, and will create a new one : https://github.com/odoo/enterprise/blob/13d815457d47846d5391c9a2dc1ed244ef64b6c4/stock_barcode/static/src/models/barcode_model.js#L1535 Additional Issues ----------------- Issue 1 : When scaning a packaging, lot1, packaging, lot2, all the packagings will be linked to the first lot, which doesn't allow us to scan multiple lots. Issue 2 : When having sublines with different uoms, it will add the quantity without considering the differences in uoms ### Steps to reproduce: * In the settings enable packagings * Create a storable product P with Units as uom, a barcode and tracked by lots * Create new lots with barcode for Product P * Inventory > Configuration > Product > Units & Packagings * Click on pack of 6 > Packaging Barcodes > New * Create one for your product with a different barcode * Create a packaging 2 with barcode for product A * Go to barcode > Operations > eg. internal transfer > New * Scan packaging 1 barcode * Scan one of the lot 1 * Scan packaging 1 * Scan lot 2 -> Issue 1, the packaging 2 will be link to lot 1, it won't be possible to link any packaging to another lot. * Scan packaging 2 -> Issue 2, it create a subline (excpeted), but the sum that appear on the main grouped line is wrong, it doesn't considere the difference in uoms ### Observation: Issue one : When scanning a barcode, it will first try to find a match with existing lines, since the uom is the same it will not be erased by the full line check https://github.com/odoo/enterprise/blob/13d815457d47846d5391c9a2dc1ed244ef64b6c4/stock_barcode/static/src/models/barcode_model.js#L1456-L1460 and since, it found a line, it will just add it's self to the line Issue Two: When creating the group lines it will first calculate the sum of all the quantities: https://github.com/odoo/enterprise/blob/8774388a7b1b2ca2c08c752026ac1a20dbc10347/stock_barcode/static/src/models/barcode_model.js#L248-L254 And after inside of groupSublines it will choose the main line and it's uom and use the previous sum for the total quantity: https://github.com/odoo/enterprise/blob/8774388a7b1b2ca2c08c752026ac1a20dbc10347/stock_barcode/static/src/models/barcode_picking_model.js#L1456-L1461 opw-5189492 opw-5408372 Forward-Port-Of: odoo/enterprise#108214 Forward-Port-Of: odoo/enterprise#98701
This update corrects a warning message appearing when adjusting the B1 field in French tax reports. The issue stemmed from an unnecessary reference to 'box_B1' within the report's calculations. This change ensures the report functions correctly without displaying misleading warnings, improving the user experience for French accounting users.
Original PR description
Steps to reproduce: 1- Install Accounting and l10n_fr and switch to French company 2- Go to [Settings > Accounting] and make sure fiscal localization is set to France 3. Go to [Accounting > Reporting > Tax return] and change the Report to Tax Report (FR) 4. Make an adjustment to the B1 field Description of issue: Warning message displayed where the text does not mention B1 Expected behavior: No warning message should be displayed when editing B1 Why this happens: 'box_B1' is used in the the expression total comparison when it should not be opw-5960001 Forward-Port-Of: odoo/enterprise#110169
This update ensures Odoo complies with new NACHA rules regarding payment descriptions. Starting March 2026, all payroll payments must include "PAYROLL" in the Company Entry Description field. This change is necessary to avoid potential payment processing issues and maintain compliance with financial regulations.
Original PR description
Starting March 20, 2026, NACHA requires the Company Entry Description field to contain "PAYROLL" for paying wages, salaries, or compensation [1]. [1] https://www.nacha.org/rules/risk-management-topics-company-entry-descriptions task-5981941 Forward-Port-Of: odoo/enterprise#109460
This update prevents an infinite loop in the claim status polling process for credit notes (DTE 61). The system was incorrectly attempting to retrieve claim information for credit notes via a SII endpoint that doesn't support them, leading to unnecessary and continuous polling. By restricting the polling to only invoices, the issue is resolved and performance is improved.
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 fixes an issue where barcode-created manufacturing orders incorrectly used product UoMs instead of the specified BoM UoMs. Now, the system accurately reflects the BoM's quantities when creating stock moves within barcode-based MRP processes, ensuring accurate inventory tracking. This resolves a previous error that could lead to incorrect production quantities.
Original PR description
Previous behaviour: * Traceback if MO created with a BoM whose lines have UoMs that don't correspond to those of the products, then UoM setting disabled and MO viewed in the barcode app. * BoM line UoMs ignored in favour of product UoMs when creating MO in the barcode app. New behaviour: * No traceback. * Stock moves in MOs properly created with the corresponding BoM line UoMs. Task ID: [4674196](https://www.odoo.com/odoo/my-tasks/4674196) Forward-Port-Of: odoo/enterprise#110393 Forward-Port-Of: odoo/enterprise#90408
This update removes a redundant check for local network connectivity when opening cashboxes via IoT. Since stable IoT boxes are now reachable through a websocket, this check was unnecessary and causing potential delays. This change streamlines the cashbox opening process.
Original PR description
Stable IoT Boxes can be reached using websocket, so it doesn't make sense to check the connectivity on local network before sending the "open cashbox" action. We then removed this check. Forward-Port-Of: odoo/enterprise#110188 Forward-Port-Of: odoo/enterprise#107397
This update ensures that Danish SEPA payments are correctly formatted with the necessary FIK reference information. The change refactors the XML generation process to handle country-specific reference formats, making the system more robust and compliant with Danish regulations. This prevents errors and ensures accurate payment processing.
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 resolves conflicts in how transactions are managed for the German POS system (l10n_de_pos_cert) when using the API. Specifically, it ensures that only transactions tied to a single terminal are cancelled, preventing issues with shared POS sessions. The update also handles errors more gracefully, recovering from conflicts and ensuring data consistency.
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#109996This update resolves an issue preventing the POS system from correctly accessing fiscal data information. By loading a key field, the system now functions as intended, ensuring accurate reporting and compliance. This change enhances the overall reliability of the Point of Sale module.
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