Friday, May 23, 2025
13 changes · 17.0
Enhancements to existing features
This update improves how Malaysian e-invoicing handles empty responses from the online service. Users will now receive clearer, more helpful error messages when the service returns specific issues, making problems easier to understand and resolve.
Original PR description
Odoo part of the IAP PR. Add some more error codes that will be sent by the IAP server, in order to provide more useful errors for the users. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Resolved issues and error corrections
This fix prevents errors when an employee leave accrual is configured to carry over on the last day of a month such as February or April. The system now calculates the actual last day for the selected month and year, so leave allocations can be created reliably.
Original PR description
Steps to Reproduce: ----------------- 1) Create an Accrual - Set carryover_date to other - Set carryover_month to April. - Set carryover_day to Last Day. 2) Add an Accrual Rule to the accrual. 3)…
Steps to Reproduce: ----------------- 1) Create an Accrual - Set carryover_date to other - Set carryover_month to April. - Set carryover_day to Last Day. 2) Add an Accrual Rule to the accrual. 3) Create a Leave Allocation - Set allocation_type to Accrual. - Assign the Employee. - Define the Validity Period (date_from, date_to). **Issue:** ------------------- On accrual creation when the user selects the "last day" option for carryover_day, we are currently assigning the 31st as the day Hardcoding the 31st as the `carryover_day` can lead to errors when the `_get_carryover_date` method is triggered. For example, this causes failures in months with fewer days (e.g., February or April). **Fix:** ----------- evaluate the correct carryover_day based on the selected month & year when the value is set to last day, before using it to prepare the final date. This ensures that the last day of each month is accurately determined and applied. **Traceback:** ------------ ValueError: day is out of range for month **OPW:** 4792938 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Miscellaneous changes
When trying to send a vendor bill that uses a tax with l10n_es_type 'sujeto_agricultura' with TicketBAI using the agency bizkaia, we are faced with an error code. This is due to the amount of these taxes being different than what is allowed (10.5% and 12%). The two 'sujeto_agricultura' taxes are actually part of a special regime and should be exempted when sent [reference](https://sede.agenciatributaria.gob.es/Sede/iva/regimenes-tributacion-iva/regimen-especial-agricultura-ganaderia-pesca.htm
Original PR description
When trying to send a vendor bill that uses a tax with l10n_es_type 'sujeto_agricultura' with TicketBAI using the agency bizkaia, we are faced with an error code. This is due to the amount of these taxes being different than what is allowed (10.5% and 12%). The two 'sujeto_agricultura' taxes are actually part of a special regime and should be exempted when sent [reference](https://sede.agenciatributaria.gob.es/Sede/iva/regimenes-tributacion-iva/regimen-especial-agricultura-ganaderia-pesca.html) This PR adapts the data sent to Bizkaia, in a similar manner as https://github.com/odoo/odoo/pull/196017 did for SII, by setting `ClaveRegimenIvaOpTrascendencia` to `02` and `TipoFactura` to `06` if we have a 'sujeto_agricultura' tax. [reference](https://sede.agenciatributaria.gob.es/static_files/Sede/Procedimiento_ayuda/G417/FicherosSuministros/V_1_1/Validaciones_ErroresSII_v1.1.pdf) opw-4781267 Forward-Port-Of: odoo/odoo#210141
Fixed an issue where failed or deleted WhatsApp messages could show the default green status icon after deletion or data expiry. The message list now uses clearer color coding so users can better understand whether a WhatsApp message was sent, pending, failed, cancelled, or no longer available.
Original PR description
The failed WhatsApp message icon turns green after 15 days or once the message is deleted. PROBLEM: WhatsApp messages are deleted after 15 days, leading to data loss and causing the default green icon to be displayed. SOLUTION: Introduced `getWhatsappStatusClass` to display appropriate icons based on the message state: - Green icon for `sent`, `delivered`, `read`, and `received` states. - Orange icon for the `outgoing` state. - Red icon for the `error` and `cancel` states. - Grey icon for the `undefined` state (i.e., deleted WhatsApp message). Also introduced was `getWhatsappStatusTitle`, which returns the correct title based on the message state. Task-4481123
Before fix, when a user manually added a narration (e.g. terms and conditions) on an invoice, changing the journal or other dependent fields (partner) would trigger a recompute of the narration field, which cleared the user-provided content. Steps to reproduce: ---- 1. Create a customer invoice. 2. Add custom narration (terms and conditions). 3. Change the journal or partner. → The narration field is reset and the manually-entered content is lost. After this commit: ---- The compute
Original PR description
Before fix, when a user manually added a narration (e.g. terms and conditions) on an invoice, changing the journal or other dependent fields (partner) would trigger a recompute of the narration field, which cleared the user-provided content. Steps to reproduce: ---- 1. Create a customer invoice. 2. Add custom narration (terms and conditions). 3. Change the journal or partner. → The narration field is reset and the manually-entered content is lost. After this commit: ---- The compute method for the narration field checks if narration already exists and preserves it, preventing loss of user input. ---- opw-4757119 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#210852
Previously the `state name` of partner is validating, but as per government API json schema `state tin number` is required. After this commit: - The validation now checks the state tin number instead of the state name, ensuring it is a valid and min 1 and max-2 digit number. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#204495
Original PR description
Previously the `state name` of partner is validating, but as per government API json schema `state tin number` is required. After this commit: - The validation now checks the state tin number instead of the state name, ensuring it is a valid and min 1 and max-2 digit number. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#204495
Note: This is backport of #207157 This pr should wait a little to see the impact of 207157 on odoosh and others external cis before merging. Fixes build error #182074 Forward-Port-Of: odoo/odoo#207893
Original PR description
Note: This is backport of #207157 This pr should wait a little to see the impact of 207157 on odoosh and others external cis before merging. Fixes build error #182074 Forward-Port-Of: odoo/odoo#207893
This commit updates the legacy dhl connector module title and description in the base POT file. Enterprise PR: odoo/enterprise#73908 Task-3759205 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#187409
Original PR description
This commit updates the legacy dhl connector module title and description in the base POT file. Enterprise PR: odoo/enterprise#73908 Task-3759205 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#187409
Account 461411, set by default on the sales taxes in LU localization does not need to be reconcilable as only payables and receivables defined in tax groups have to be opw-4749885 Forward-Port-Of: odoo/odoo#210613
Original PR description
Account 461411, set by default on the sales taxes in LU localization does not need to be reconcilable as only payables and receivables defined in tax groups have to be opw-4749885 Forward-Port-Of: odoo/odoo#210613
PR #64267 implemented a reconnection mechanism, but it is only triggered when the WebSocket close event is fired. In practice, we noticed that the WebSocket would sometimes silently lose connection. When this happens, one should just send data through the WebSocket to refresh it. This commit enables SIP.js keep-alive feature, hopefully reducing the number of disconnections, or at least preventing them to go unnoticed. Forward-Port-Of: odoo/enterprise#86213
Original PR description
PR #64267 implemented a reconnection mechanism, but it is only triggered when the WebSocket close event is fired. In practice, we noticed that the WebSocket would sometimes silently lose connection. When this happens, one should just send data through the WebSocket to refresh it. This commit enables SIP.js keep-alive feature, hopefully reducing the number of disconnections, or at least preventing them to go unnoticed. Forward-Port-Of: odoo/enterprise#86213
The informational messages linked to the sending of the tax report through SBR were using Markup elements without actually using Markup. Also the VAT formatting used for the payload is now more robust (clients may use points or other characters in it). Forward-Port-Of: odoo/enterprise#73922
Original PR description
The informational messages linked to the sending of the tax report through SBR were using Markup elements without actually using Markup. Also the VAT formatting used for the payload is now more robust (clients may use points or other characters in it). Forward-Port-Of: odoo/enterprise#73922
Changed translations to use the legal term used in Mexico. This is done because "Cada dos semanas" and "Quincenal" don't have exactly the same meaning
Original PR description
Changed translations to use the legal term used in Mexico. This is done because "Cada dos semanas" and "Quincenal" don't have exactly the same meaning
This new module should replace the existing implementation for DHL integration which uses XML and is no longer recommended by DHL: https://developer.dhl.com/dhl-express-xml-developer-portal-sunset. The new integration uses ["MyDHL API](https://developer.dhl.com/api-reference/dhl-express-mydhl-ap)" which is based on REST. Community PR: odoo/odoo#187409 Task-3759205 Forward-Port-Of: odoo/enterprise#73908
Original PR description
This new module should replace the existing implementation for DHL integration which uses XML and is no longer recommended by DHL: https://developer.dhl.com/dhl-express-xml-developer-portal-sunset. The new integration uses ["MyDHL API](https://developer.dhl.com/api-reference/dhl-express-mydhl-ap)" which is based on REST. Community PR: odoo/odoo#187409 Task-3759205 Forward-Port-Of: odoo/enterprise#73908