Wednesday, December 31, 2025
7 changes · saas-18.3
New functionality added to Odoo
This update adds the ability to generate e-invoices in Croatia, specifically for the MojEracun system. It utilizes a new proxy client to handle communication with the eRacun network and incorporates Croatian-specific data elements for compliance. Tests include XSD validation to ensure invoice accuracy.
Original PR description
Adding e-invoice generation base functionality for Croatia. Implemented as an extension of account_edi_ubl_cii, similar to other localisations using such documents. Adding proxy client for MojEracun sevice provider to send invoiced on the eRacun network. Proxy user is entirely separate from the standard Odoo IAP EDI proxy implementation. Adding UBL 2.1 compliant node `cac:SellerContact` to existing node `cac:AccountingSupplierParty` to be used in Croatian e-invoice XLM generation with the new method chain. XSD validation included in the tests on the client side as there is no corresponding Odoo IAP proxy. task-4925745 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#241691 Forward-Port-Of: odoo/odoo#230757
Resolved issues and error corrections
This update fixes an issue where combo line prices were incorrectly set to 'automatic' after order creation. The change ensures combo line price types remain as originally intended, preventing conflicts with price updates and maintaining accurate pricing for combo sales. This improves the reliability of point-of-sale transactions.
Original PR description
After commit https://github.com/odoo/odoo/commit/69057e41fb4cd800d23401ead8ae11bf7cba7c64, the price type of combo lines was changed to 'automatic' when creating the combo line. This caused the set pricelist logic to update the price of combo lines with automatic price type, which conflicts with the intended behavior. This commit ensures that the price type of combo lines is preserved as original in cases where we want to update the price, and only set to automatic in cases like loading a sale order or refunding an order. opw-5240429 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#239748 Forward-Port-Of: odoo/odoo#234575
This update resolves an issue where Odoo invoices with discounts generated through Nemhandel would fail validation. The change ensures that discounts are correctly accounted for in invoice calculations, allowing invoices with discounts to be successfully sent to customers via Nemhandel. This improves the functionality of the Nemhandel integration.
Original PR description
Before this fix, all the OIOUBL invoices with a discount generated by Odoo would fail the schematron validation, meaning they can't be sent to the customer through Nemhandel. The schematron enforces that the discount is taken into account at the PriceAmount, to keep the rules on lineExtensionAmount working. Also changes the import to understand that it's a discount. opw-5379474 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#241614
This update resolves an issue where large .docx files weren't being correctly identified with their proper file type (like .docx) when using the `python-magic` library. Previously, the system incorrectly guessed 'application/zip' for these files. This change increases the data sent to the file type guesser, ensuring accurate identification and proper handling of large documents.
Original PR description
### Description of the issue/feature this PR addresses: The current number of bytes (1024) sent to the mimetype guesser function is not enough for a correct guess on big .docx files (maybe other open…
### Description of the issue/feature this PR addresses: The current number of bytes (1024) sent to the mimetype guesser function is not enough for a correct guess on big .docx files (maybe other open office files too) whenever `python-magic` is installed. If `python-magic` is not installed, it falls back to a [simpler implementation (by odoo)](https://github.com/odoo/odoo/pull/233266/files#diff-706296f6593337a9ff88c0e33e0e090eec75f63a22f9825dd31833ba17922840R145) that actually works correctly. But in odoo.SH it seems that `python-magic` is always installed and in that case, it returns the mimetype "application/zip" for big .docx files. The issue is not reproducible in runbot, so I'm assuming `python-magic` is not present in that environment. I've tested it with double the amount of bytes and it seems to work correctly. Please check the [following ticket](https://www.odoo.com/odoo/project.task/5125592) for more details. ### Current behavior before PR: <img width="1141" height="674" alt="image" src="https://github.com/user-attachments/assets/a3d28757-c55a-4b0f-9ee5-042777943635" /> ### Desired behavior after PR is merged: The uploaded file's mimetype is correctly identified for big (>40mb) open office files. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#239045 Forward-Port-Of: odoo/odoo#233266
This update corrects a restriction imposed by Mexican tax authorities (SAT) on the ‘CuentaPredial’ field in our software. The change ensures Odoo correctly handles the required format for this field, aligning with current SAT regulations. This is necessary for accurate tax reporting and compliance in Mexico.
Original PR description
SAT has declared the restriction [0-9a-zA-Z]{1,150} for CuentaPredial node
Specification: https://www.sat.gob.mx/sitio_internet/cfd/4/cfdv40.xsd
Forward-Port-Of: odoo/enterprise#102981This update resolves an issue where users couldn't answer incoming calls when opening modals like email or SMS wizards. The fix adjusts the software's layering to ensure the softphone is always visible and clickable when a call is active. This improves the user experience by allowing immediate call handling.
Original PR description
If you get a call when opening any modal/composer like email/sms wizard, you won't be able to pick up the call as the softphone is not clickable. This is because the z-index of the softphone is less than the modal. This commit fixes that issue by making the softphone above modals only if there is a pending call. [Task-4018118](https://www.odoo.com/odoo/project.task/4018118)
This update resolves an issue where delivery validation would fail after splitting a stock move line within a delivery order. Now, the system correctly recognizes that the new move line is associated with the original picked move, allowing validation to proceed smoothly. This ensures accurate order processing and prevents unnecessary backorder warnings.
Original PR description
Scenario: * create a delivery with quantity 3 and mark as TODO * mark the stock move as picked * open the "Details" popup and split the stock move line into quantities 1 and 2, e.g. by adding a new…
Scenario: * create a delivery with quantity 3 and mark as TODO * mark the stock move as picked * open the "Details" popup and split the stock move line into quantities 1 and 2, e.g. by adding a new package or a new lot * exit the popup and try to validate the delivery Behavior before this commit: * the stock move in the delivery form remains picked * validation shows a backorder popup, warning of missing quantity Reason: the newly created stock move line is not picked, but this information is not displayed anywhere, so users are not aware of the cause of this issue After this commit: * the stock move is no longer picked after a new move line is added * users can click the "Picked" checkbox in the delivery form manually, which marks all stock move lines as picked as well * after this action, delivery validation proceeds without backorders opw-5345579 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#239089