Thursday, July 16, 2026
9 changes · saas-19.3
Enhancements to existing features
Payment initiation data now includes additional payer and creditor information such as names, VAT numbers, and addresses. This helps Powens process online payments with richer transaction details and may improve compatibility with its requirements.
Original PR description
Powens requires more information that what is already provided in the payment initiation payload. This commit adds payer/creditor name and VAT. task-5977148
Resolved issues and error corrections
Indian GST reports now better match legal reporting requirements for imports. Import of services is no longer shown in GSTR-2B, and GSTR-3B import reporting has been aligned with the latest section changes for goods and services.
Original PR description
As per the law, import of services is not required to be shown in GSTR-2B. Therefore, the related report lines are removed in this commit. Additionally, GSTR-3B reporting is now handled according to the updated section changes for import of goods and services. task-6330737 Forward-Port-Of: odoo/enterprise#124316 Forward-Port-Of: odoo/enterprise#121925
This fixes an issue where attendee emails could show an outdated event start date after a multi-day event was rescheduled. Event registrations now refresh their stored date information when the event dates change, helping prevent incorrect details from being sent to attendees.
Original PR description
Steps to reproduce: ------------------------------------------------ 1. Install Event module 2. Create a multi day event 3. Create one attendee for the event 4. Change the event dates 5. Go to…
Steps to reproduce: ------------------------------------------------ 1. Install Event module 2. Create a multi day event 3. Create one attendee for the event 4. Change the event dates 5. Go to attendee and Click on Send by Email Observation: ------------------------------------------------ The event start date displayed in the email body is not updated after the event dates are modified. Issue: ------------------------------------------------ In `saas-18.2`, `event_begin_date` and `event_end_date` were simple related fields that automatically updated when their source fields changed. https://github.com/odoo/odoo/blob/saas-18.2/addons/event/models/event_registration.py#L57-L58 However, in `saas-18.3`, slots were introduced and these fields were converted to computed fields https://github.com/odoo/odoo/pull/205945/changes/e2bf8a89d6a50bd40f4673bef38176465f83ba0f * `event_begin_date` is made stored for cohort view grouping * However, the base compute method only depends on `event_id` and `event_slot_id` https://github.com/odoo/odoo/blob/ac37b479321dbe9dbf864e833900e043b1cc70df/addons/event/models/event_registration.py#L177-L180 * When you change `event.date_begin` or `event.date_end`, the registration records don't recompute because the dependency is on the `event_id`, not on the related date fields (`event_id.date_begin`, `event_id.date_end`) * Non-stored computed fields recalculate on-the-fly when accessed, so `event_end_date` appeared to work * Stored computed fields only recalculate when their explicit dependencies change Solution: ------------------------------------------------ * Corrected the dependencies of `_compute_event_begin_date` to recompute value on changing the date of the event opw-6284576 Forward-Port-Of: odoo/enterprise#120184
This fixes several details in Hong Kong IRD payroll reports so the reported tax year matches the employee's start or leaving date. It also ensures a required explanation is included when an employee leaving reason is marked as 'Other', helping submissions meet IRD certification requirements.
Original PR description
As we now have complete support for IRD reports (in master), we started to try to get our system certified by the IRD.
A first submission highlighted a few issues that we are now fixing.
From 19.0:
- In IR56F, the RTN_ASS_YR should be the tax year in which the employee left the company. E.g. after april, the next year.
- In the same report, if the code for the cessation reason is 5 (other), the reason MUST be provided.
From 19.2:
- Same change has to be done when setting RTN_ASS_YR for IR56G
- A same change has to also be done for IR56E, based on the date the employee joined the company.
task-6332150
Forward-Port-Of: odoo/enterprise#124256
Forward-Port-Of: odoo/enterprise#121877VoIP call recordings made from Apple mobile devices could previously be saved as silent audio. The recording quality setting has been adjusted so these recordings capture sound correctly, helping users reliably review calls.
Original PR description
Before this commit, recording a VoIP phone call from an Apple mobile device generated a silent audio file. This issue happened because the configured 8000 `audioBitsPerSecond` value was too low. Apple mobile browsers strictly respect this value, while other browsers ignore it and default to a higher bitrate to 128000. Increasing `audioBitsPerSecond` to 32000 on WebKit browsers fixes the issue on Apple mobile devices. How to reproduce: - Set up a DIDWW user. - Enable call recording. - Make a call. - Open the call and play the recording. opw-6046534 Forward-Port-Of: odoo/enterprise#117885
Chilean Point of Sale receipts with official SII barcodes now print correctly again. This prevents checkout staff from encountering a crash when validating and printing orders for companies using Chilean electronic invoicing.
Original PR description
Steps to reproduce: - Have a Chilean company with DTE configured (a resolution number/date and a signed boleta/factura, so the order's move has an SII barcode) - Open a PoS session, pay an order and validate it Issue: The receipt fails to render and printing crashes with: `TypeError: ctx.image.l10n_cl_sii_barcode_image.to_base64 is not a function` Cause: Commit 0b50021bdae adapted this template as part of the BinaryValue migration (odoo/odoo#244421), calling `to_base64()` on the barcode image. However `l10n_cl_sii_barcode_image` is a computed `fields.Char` that already holds a base64 string (`_pdf417_barcode` returns `b64encode(...).decode()`), not a Binary, so it is never wrapped in a `BinaryValue`. Moreover, this template is also rendered client-side by the PoS QWeb engine, where the value loaded from the server is a plain string with no `to_base64` method either. opw-6389718
Belgian blackbox POS devices are now locked only after the first signed order, instead of when the POS is merely opened. This prevents businesses from accidentally tying a device to a POS before any sale is made, while also improving cost center handling and clearer blackbox error messages.
Original PR description
- `log_device` registered the device as soon as a blackbox POS was opened, so a device was locked before making any sale. Register it only once the config has at least one signed order, and add unit tests covering both branches. - correctly `trim()` cost center - display details inside syntax error & invalid input blackbox error popups
This fix prevents the Belgian payroll app from failing during installation when some setup data is not loaded yet. Businesses can now install or update the app on populated databases without encountering this blocking error.
Original PR description
Currently during the installation process the compute is called before the data of the module is loaded. The compute uses a env.ref that searches for an external id that will only exist later on. this creates a traceback in populated databases, since the compute will be processed, and the app won't be installed. Here we cannot overwrite the auto_init since the field is not stored The only option left was to adapt the comupte to not throw a traceback in case the fields are not found, and instead proceed with the compute/installation opw-6340800 Forward-Port-Of: odoo/enterprise#123744
Fixes an issue where German point-of-sale receipts could fail to download or print when Fiskaly certification data was present. This helps shops using German fiscal certification reliably access receipts from the backend.
Original PR description
With fiskaly in production, when printing the pos receipt, it crashes because the tss values dictionnary is not correctly interacted with. To reproduce: install l10n_de_pos_cert create a DE shop activate fiskaly and the tss in the settings of the POS create an order in the POS and pay it go to the backend, open the pos order and download the receipt it will crash To reproduce without production credentials, you can not activate fiskaly and the tss but still create and pay the pos order. Then, you can change the pos.config to add the l10n_de_fiskaly_tss_id and change the pos.order to add the l10n_de_fiskaly_time_start. Then download the receipt. opw-6356628 Fixes https://github.com/odoo/enterprise/pull/115676 Forward-Port-Of: odoo/enterprise#123473