Thursday, January 29, 2026
6 changes · saas-18.2
Resolved issues and error corrections
This update fixes errors in the SAF-T export process for Romanian companies when partner information (country or name) is missing. The fix ensures accurate registration number generation and prevents report errors, improving compliance for our Romanian clients. It addresses issues related to incomplete partner data.
Original PR description
Fix SAF-T export errors when partners have no country or name. For Romanian companies, the RegistrationNumber should be generated as “04 + partner ID” for customers not subject to VAT and with unknown CNP, without including the country code. Steps to reproduce country issue: - Configure a Romanian company with l10n_ro_saft installed - Create a contact without a country - Create and validate an invoice for this contact - Export the SAF-T file from the General Ledger report You you will get a TypeError because you cant concatenate Bool and String. Steps to reproduce name issue: - Create a main contact - Add a child contact without a name - Change the child type to “Company” - Create and validate an invoice - Export the SAF-T file from the General Ledger report This prevents KeyError when printing the first 70 characters of the partner name in the report. opw-5499918 Forward-Port-Of: odoo/enterprise#105406 Forward-Port-Of: odoo/enterprise#105020
This update fixes an issue where the barcode scanning process wasn't creating enough quality checks for products tracked by lot. The change ensures that quality checks are automatically generated when using the ‘Put-In-Pack’ feature, guaranteeing accurate quality control for lot-based inventory.
Original PR description
**Steps to reproduce:** * Install the `stock_barcode`, `quality_control` modules. * Go to *Inventory > Configuration > Settings* and enable **Packages**. * Create a product with **By Lot** tracking…
**Steps to reproduce:** * Install the `stock_barcode`, `quality_control` modules. * Go to *Inventory > Configuration > Settings* and enable **Packages**. * Create a product with **By Lot** tracking enabled and set a barcode reference. * Create a quality control point for this product with following configuration: * Operation: *Receipts* * Control per: *Quantity* * Control Frequency: *All* * Product: the previously created lot-tracked product. * Create a receipt for this product with a quantity of 6 and `mark as todo`. * Open the *Barcode* app and process the receipt. * Scan the product barcode. * Scan some quantity of the product with lot *LOT01* and put those units into a package(Put-In-Pack). * Scan the remaining quantity with lot *LOT02* and put those units into a different package(Put-In-Pack). * Click on **Quality Checks**. **Observed behavior:** * Only one quality check is created, even though the receipt contains two different lots that should each generate a quality check. **Cause:** * In `_inverse_qty_done`, move lines are marked as *picked* when `qty_done` is equal to quantity(Demand). * During the `write` operation, quality checks are created only for move lines that are not picked, which prevents creating a quality check for each lot. * Relevant code: https://github.com/odoo/enterprise/blob/464dc0c65548f3f440b293b534616743ddd5e130/quality_control/models/stock_move_line.py#L39 https://github.com/odoo/enterprise/blob/464dc0c65548f3f440b293b534616743ddd5e130/stock_barcode/models/stock_move_line.py#L67-L71 **Fix:** * Ensure that quality check points are generated correctly when validating products through the Barcode app using the Put in Pack option. --- opw-5405221 Forward-Port-Of: odoo/enterprise#102714
This update resolves an issue where Odoo payments using Swedbank's Bankgiro accounts were being rejected. The fix adds a required field, 'RfdDocAmt,' to the payment XML, ensuring compliance with Swedbank's banking requirements and allowing successful payment processing.
Original PR description
**PROBLEM** Swedbank requires the RfdDocAmt Element for Bankgiro account. [documentation](https://internetbank.swedbank.se/ConditionsEarchive/download?bankid=1111&id=WEBDOC-PRODE211415244). Payment batches generated by Odoo don't contains this fields, meaning they are refused by the bank. **REPRO STEPS** We can't reproduce the error the client have because it would require a valid bankgiro account. To generate the payment batch xml you have to: 1. Install l10n_se. 2. Create a vendor bank account of type bankgiro. 3. Create a vendor payment with this vendor bank account. 4. Create a batch payment and validate it. 5. There should be a xml in the chatter, you can look at it to see there is no RfdDocAmt element. opw-5427505 Forward-Port-Of: odoo/enterprise#104777
This update corrects a technical issue preventing invoices from successfully validating with DIAN, Colombia’s tax authority. The fix involves updating a specific tag format within invoices to match DIAN’s requirements, ensuring accurate and compliant invoice submissions. This resolves a validation error that was impacting Colombian businesses using the l10n_co_dian module.
Original PR description
Problem: When validating invoices with DIAN, an error is received. Cause: Incorrect tags are being used in the invoices. These tags are checked when invoices are validated with DIAN. Solution: Use the correct tags in the invoices. schemeName should be used instead of scheme_name. Steps to reproduce: - Install l10n_co_dian module - Choose a Colombian company - Activate DIAN service in Settings - Create an invoice and send it while making sure the DIAN checkbox is ticked - Download the generated zip file and uncompress - Open the XML file and check for scheme_name. It should be replaced by schemeName. opw-5829958 Forward-Port-Of: odoo/enterprise#105659
This update fixes an issue where move quantities were incorrectly displayed after exiting the barcode MRP operation. The change ensures that quantities are accurately reflected when re-entering the operation, preventing discrepancies in production tracking. This improves the reliability of the manufacturing process.
Original PR description
**Issue** When leaving the barcode MRP operation, `post_barcode_process()` may incorrectly update the move quantities. **Steps to reproduce** - Create a product with a BOM using a component with qty…
**Issue** When leaving the barcode MRP operation, `post_barcode_process()` may incorrectly update the move quantities. **Steps to reproduce** - Create a product with a BOM using a component with qty 6. - Create an MO producing qty 1. - Open the Barcode app > Manufacturing > open the MO (remove “MO Ready” filter if needed). - Click “+1”. - Edit the component qty from 6 to 3. - Exit the operation. - Re-enter the operation. -> The component shows 3/3 instead of 3/3 and 0/3. **Cause** On exit, `_onExit`: https://github.com/odoo/enterprise/blob/776848dc4e29d07a027847fde46a59f84dd35f56/stock_barcode/static/src/models/barcode_picking_model.js#L1489 calls `post_barcode_process()`, which triggers `split_uncompleted_moves`: https://github.com/odoo/enterprise/blob/776848dc4e29d07a027847fde46a59f84dd35f56/stock_barcode/models/stock_move.py#L16 correctly creating a `stock.move.line` with qty 3. However, `_truncate_overreserved_moves`: https://github.com/odoo/enterprise/blob/776848dc4e29d07a027847fde46a59f84dd35f56/stock_barcode/models/stock_move.py#L40 then reduces the move quantity to `max_reserved_qty = 3` and unreserves the remaining 3 units: https://github.com/odoo/enterprise/blob/776848dc4e29d07a027847fde46a59f84dd35f56/stock_barcode/models/stock_move.py#L49 This happens because the newly created move line is initialized with `reserved_uom_qty = 0`: https://github.com/odoo/enterprise/blob/776848dc4e29d07a027847fde46a59f84dd35f56/stock_barcode/static/src/models/barcode_picking_model.js#L1256 leading to `max_reserved_qty = quantity_done = 3 < move.quantity = 6`, while `move.product_uom_qty` is still 6. opw-5166763 Forward-Port-Of: odoo/enterprise#100314
This update resolves an issue where customer claims weren't being processed correctly when a customer shared a VAT number with a related invoice contact (like a child invoice). The fix ensures the system accurately identifies the correct partner based on VAT number, preventing missed account move updates and ensuring claim processing accuracy.
Original PR description
When we process new customer claims, we need to search for the corresponding account moves in order to update their `l10n_cl_dte_acceptation_status`. Currently, we only expect 1 partner per VAT number when searching for a partner to match with the account move. However, this is not always true. For instance, a child invoice contact will share the same VAT number than the parent partner. This can lead to the selection of the wrong partner in the search domain and consequently, the account move not being found. Related ticket: opw-5257481 Forward-Port-Of: odoo/enterprise#103366