Tuesday, September 2, 2025
6 changes · saas-18.2
Resolved issues and error corrections
This fix prevents Spain VeriFactu processing from failing when a company has no NIF or VAT number set. It makes invoice reporting checks more robust, reducing unexpected interruptions for affected Spanish localization users.
Original PR description
Replaced `['NIF']` with `.get('NIF')` to avoid a `KeyError` when the company does not have a NIF.
When the VAT value is not set on the company and the `_send_as_batch_check` method is executed, the system raises an error from [1].
This PR updates the code to use `.get('NIF')` instead of direct access, making it more robust.
[1]: https://github.com/odoo/odoo/blob/dff2423ac320fdb97d6bf1f106dc84be1d71cac2/addons/l10n_es_edi_verifactu/models/verifactu_document.py#L1165
**sentry-6829500308**
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#224982Online point-of-sale payments now send order dates in the expected UTC timezone. This prevents mismatches caused by local timezone conversion, helping ensure orders are recorded with the correct date and time.
Original PR description
In 2a5f1ab, we formatted the `order_date` with `toFormat(...)`, however, that transforms the date into local, while the backend expects it to be in UTC. In this commit, we set the date tz back to UTC before formatting it. opw-4942697 Forward-Port-Of: odoo/odoo#224085
This update corrects the Spanish Canary Islands tax configuration to use the field name expected in Odoo 18. It helps ensure those taxes load and behave properly during setup or updates.
Original PR description
Description of the issue/feature this PR addresses: In version 18 of Canary Islands taxes, the “price_include” field no longer exists. It is now called “price_include_override.” 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#223996
This fix makes Indonesian e-Faktur Coretax product codes easier to find when users search or select them on product templates. Users can now search by code, description, or the displayed label, reducing confusion and data entry friction.
Original PR description
Description of the issue/feature this PR addresses: Because `l10n_id_efaktur_coretax.product.code` model does not have a `name` field and does not use` _rec_name`, search record in m2o field or…
Description of the issue/feature this PR addresses: Because `l10n_id_efaktur_coretax.product.code` model does not have a `name` field and does not use` _rec_name`, search record in m2o field or searchview is difficult and not normal. so this uses `_rec_name = "code"` for fixing in searchview, and overrides `_name_search()` to be able to search using field `code` or `description` or like `name_get()` string Current behavior before PR: <img width="821" height="353" alt="Before fixing coretax product code search 1" src="https://github.com/user-attachments/assets/12ca3248-0bea-4ef3-bb04-116d63520517" /> <img width="832" height="432" alt="Before fixing coretax product code search 2" src="https://github.com/user-attachments/assets/ced291b7-c4c6-42e7-a453-7a1f18945637" /> <img width="988" height="568" alt="Before fixing coretax product code search 3" src="https://github.com/user-attachments/assets/bbac4ae1-a31d-49bd-b520-a68a1a945e78" /> Desired behavior after PR is merged: <img width="438" height="314" alt="After fixing coretax product code search 1" src="https://github.com/user-attachments/assets/4469bb5b-0830-49af-af1c-f05b81dcb10c" /> <img width="467" height="331" alt="After fixing coretax product code search 2" src="https://github.com/user-attachments/assets/5528db34-e279-4d2d-98f0-644f7a618ead" /> <img width="991" height="619" alt="After fixing coretax product code search 3" src="https://github.com/user-attachments/assets/fec53a0c-ab29-46c5-b366-46653b51d7e4" /> --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#222588 Forward-Port-Of: odoo/odoo#221858
This update corrects a failing mobile test in the Point of Sale area. It helps keep automated quality checks reliable so future Point of Sale changes can be validated with more confidence.
Original PR description
The mobile test was failing due to an issue. opw-5059482 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The PLM dashboard now counts only engineering change approvals that are actually waiting for the current user. This prevents inflated or misleading dashboard numbers when the user was only a past approver or another person still needs to approve.
Original PR description
The dashboard of PLM displays for each ECO type the number of validations pending in general, and the validations waiting for me specifically. The latter has been incorrectly computed for quite some time, as it computes how many ECOs exists where I am an approver and an approval is waiting - but there is no guarantee that the waiting approval is one of mine; it might be that I am a past approver of the ECO and that another approval (waiting for somebody else than me) exists, or that two approval are required on the same stage (one by me, one by somebody else) and I already approved. This commit switches the computation around by looking for pending approvals waiting for me, and then get the number of (non-archived) ECOs bound to them. Forward-Port-Of: odoo/enterprise#92609 Forward-Port-Of: odoo/enterprise#92348