Odoo Changelog — 2026-05-29

Friday, May 29, 2026

6 changes · 19.0

New Features(2)

New functionality added to Odoo

[IMP] l10n_vn_reports: add VAS general ledger report S03b-DN

Enterprise19.0accountl10n_vn_reportsMEDIUM

This update adds a new report to comply with Vietnamese Accounting Standards (VAS). It ensures the General Ledger accurately reflects counterpart accounts and balances, a key requirement for Vietnamese businesses. A custom SQL query and post-processor are used to handle complex transaction types and maintain report accuracy.

Original PR description

Vietnamese Accounting Standards (VAS) require businesses to generate their General Ledger following a specific format known as Form S03b-DN. A key compliance requirement of this report is the explicit display of the counterpart account for every transaction line, as well as maintaining strictly separated debit and credit balances.

To achieve the counterpart mapping, a custom report handler and custom engine are introduced. Because standard journal entries do not strictly bind individual debit and credit lines together, a specialized SQL query was implemented. This query classifies moves by type (1-to-1, 1-to-many, many-to-many, sale/purchase) and uses proportional splitting and label matching to accurately determine the counterpart account for each line. A post-processor is also included to handle uncategorized lines where 1-to-1 matching isn't possible, ensuring the report remains balanced and transparent.

task-6092253

#accounting#vietnam#vas#reporting

[IMP] pos_pricer: add more field to be sent

PR #118757

Enterprise19.0pos_pricerMEDIUM

This update expands the data sent to Pricer, including price before taxes, tax names, supplier product codes, and units of measure. This allows for more accurate pricing calculations and supports key business scenarios when using the Pricer integration. The update also ensures Pricer tags are automatically updated when related product information changes.

Original PR description

We are currently missing some fields which must be sent to Pricer for some basic use-case scenarios
This PR adds
- Price before taxes
- Taxes name (ex: 21%)
- Supplier product code
- Supplier reference
- Units of measure of the product

The PR also triggers the update of the pricer tags when the models indirectly related to Pricer are modified (taxes name / supplier reference / supplier product code)
+ cleans up the code a bit

task-4506260

Forward-Port-Of: odoo/enterprise#93330
Forward-Port-Of: odoo/enterprise#78009

#pricing#pricer#pos

Bug Fixes(4)

Resolved issues and error corrections

[FIX] account_accountant: postponement dates

PR #114866

Enterprise19.0accountantMEDIUM

This update fixes an issue where selecting the start date first would incorrectly set both the start and end dates for deferred accounting periods. Previously, selecting the end date first resulted in dates appearing in reverse order. This change ensures the system correctly handles date selection for postponement periods, improving data accuracy and reducing potential errors.

Original PR description

The issue is when selecting deferred dates, if the start date is selected first, the system will set both the start and end dates. However, when selecting the end date first, the period appears backwards example ( 2026 - 2025 ).

task: 6140024

#accounting#deferred dates#period

[FIX] pos* : handle split orders correctly in preparation display

PR #104554

Enterprise19.0pos_enterprisepos_restaurant_preparation_displayMEDIUM

This update fixes an issue where split orders sent to the preparation display incorrectly canceled existing items. The change prevents line cancellations and ensures that split orders create new preparation cards with accurate quantities, maintaining the integrity of the initial order and preventing quantity aggregation errors. This improves the reliability of the preparation display process.

Original PR description

*= pos_restaurant_preparation_display, pos_enterprise

Steps to Reproduce
==================
- Create an order with Product A ×2 and Product B ×2
- Send the order to the preparation display
- Split the order and pay for one unit of each product
- On the remaining order, add another product
- Send the order to the preparation display 
- The preparation display incorrectly cancels previously sent products

Fix
===
- Prevent cancellation of existing preparation order lines
- Avoid duplication of preparation lines when split orders are sent to the kitchen

Covered Scenario
================
1. Send an order with Coca-Cola ×2, Minute Maid ×2, Water ×1 to the kitchen.
2. Split 1 qty of each product into a new order, increase split quantities, and send it.
3. Increase quantities on the original order and send it again.

Expected Behavior
=================
- Initial preparation order remains unchanged (no line cancellations)
- Split order creates a new preparation card with only unsend split quantities
- Original order creates a new preparation card with only newly added quantities
- No preparation line incorrectly aggregates quantities across orders

Task-5355899

Related Comm. PR: https://github.com/odoo/odoo/pull/244195

#pos#order splitting#preparation display

[PERF] l10n_se_sie: prevent OOM crashes on SIE 4 report

PR #118449

Enterprise19.0accountMEDIUM

This update resolves a critical issue where the Swedish SIE 4 report export would crash due to excessive memory usage. By optimizing the database query and using efficient data processing techniques, the export now handles large datasets quickly and reliably, significantly improving performance.

Original PR description

### Description of the issue/feature this PR addresses: Prevent Out of Memory (OOM) crashes and drastically improve execution speed when generating the Swedish SIE4 verification export for massive…

### Description of the issue/feature this PR addresses:
Prevent Out of Memory (OOM) crashes and drastically improve execution speed when generating the Swedish SIE4 verification export for massive datasets.

### Current behavior before PR:
When exporting a large volume of journal entries (e.g., 190,000+ account moves), the `_export_l10n_se_sie4_verification` method relies on iterating through heavy ORM recordsets and accessing relational child fields (move.line_ids) inside a loop. This triggers a severe N+1 query problem, maxing out server RAM and causing an OOM crash.

### Desired behavior after PR is merged:
The method now utilizes a hybrid data extraction approach:
- The ORM is used strictly to safely evaluate domains (multi-company rules, dates, states) and fetch a lightweight list of valid move_ids.
- A single SQL query with JOIN statements fetches all parent moves, child lines, and account codes in exactly one database query.
- itertools.groupby chunks the flat, lightweight dictionary results back into their respective journal entries.
The export now handles massive datasets in seconds with minimal memory overhead, while remaining perfectly secure.

### Benchmark:

For Memory:
| # Input Data | Before PR | After PR |
| -------- | -------- | -------- |
| ~190,000 moves | MemoryError | 407MB|
| ~200,000 moves | 1.8GB | 174.8 MB|

For Speed:
| # Input Data | Before PR | After PR |
| -------- | -------- | -------- |
| ~190,000 moves | MemoryError | 5.10s |
| ~200,000 moves | 1m29s| 5.3s|

### Reference:
opw-6067999

Forward-Port-Of: odoo/enterprise#117577
Forward-Port-Of: odoo/enterprise#113227

#performance#SIE4#reporting

[FIX] appointment: show all months on punctual with future start

PR #117283

Enterprise19.0appointmentMEDIUM

This update resolves an issue where appointment scheduling displayed 'no slots available' for future-starting appointments. The fix accurately calculates the displayed month based on the appointment's start date, ensuring correct slot availability is shown in the calendar. This improves the user experience for scheduling appointments that begin in a later month.

Original PR description

The "show only 1 month at a time" optimization computes the navigated month as datetime.now() + month_id, so the controller passes that (month, year) tuple to _get_appointment_slots:…

The "show only 1 month at a time" optimization computes the navigated month as datetime.now() + month_id, so the controller passes that (month, year) tuple to _get_appointment_slots:

https://github.com/odoo/enterprise/blob/57ec37b74a60c7e879a8afa66df5ab22a92c5bcd/appointment/models/appointment_type.py#L833

For a punctual appointment whose Allow Bookings range starts in a future month, the first displayed month is start_datetime.month, so the (month, year) tuple doesn't match the month the visitor is looking at. The model fills an empty month and the recovery loop refills the first displayed month (where slots actually live):

https://github.com/odoo/enterprise/blob/57ec37b74a60c7e879a8afa66df5ab22a92c5bcd/appointment/models/appointment_type.py#L973-L988

The calendar the visitor just navigated to comes back empty.

Compute the navigation base from start_datetime when it lies in the future and keep datetime.now() otherwise. month_id is added on top of that base so it always matches the displayed month index.

Introduced by https://github.com/odoo/enterprise/commit/664857dd2c4ae2bc0dde8f44cb94136659ed2fe2

Steps to reproduce:
1. Open the Appointments app
2. Open an appointment type and set Schedule to Weekly and Allow Bookings to On specific dates with a range starting in a future month (for example 1 September to 31 December)
3. Save and click the Preview button in the header
4. Pick a staff member to reach the calendar
5. Click the right arrow to navigate to the next month

=> the next month shows "Sorry, we have no more slots available for this month"

opw-6206293

#appointments#scheduling#availability

Vietnamese Accounting Standards (VAS) require businesses to generate their General Ledger following a specific format known as Form S03b-DN. A key compliance requirement of this report is the explicit display of the counterpart account for every transaction line, as well as maintaining strictly separated debit and credit balances. To achieve the counterpart mapping, a custom report handler and custom engine are introduced. Because standard journal entries do not strictly bind individual debit and credit lines together, a specialized SQL query was implemented. This query classifies moves by type (1-to-1, 1-to-many, many-to-many, sale/purchase) and uses proportional splitting and label matching to accurately determine the counterpart account for each line. A post-processor is also included to handle uncategorized lines where 1-to-1 matching isn't possible, ensuring the report remains balanced and transparent. task-6092253

We are currently missing some fields which must be sent to Pricer for some basic use-case scenarios This PR adds - Price before taxes - Taxes name (ex: 21%) - Supplier product code - Supplier reference - Units of measure of the product The PR also triggers the update of the pricer tags when the models indirectly related to Pricer are modified (taxes name / supplier reference / supplier product code) + cleans up the code a bit task-4506260 Forward-Port-Of: odoo/enterprise#93330 Forward-Port-Of: odoo/enterprise#78009

The issue is when selecting deferred dates, if the start date is selected first, the system will set both the start and end dates. However, when selecting the end date first, the period appears backwards example ( 2026 - 2025 ). task: 6140024

*= pos_restaurant_preparation_display, pos_enterprise Steps to Reproduce ================== - Create an order with Product A ×2 and Product B ×2 - Send the order to the preparation display - Split the order and pay for one unit of each product - On the remaining order, add another product - Send the order to the preparation display - The preparation display incorrectly cancels previously sent products Fix === - Prevent cancellation of existing preparation order lines - Avoid duplication of preparation lines when split orders are sent to the kitchen Covered Scenario ================ 1. Send an order with Coca-Cola ×2, Minute Maid ×2, Water ×1 to the kitchen. 2. Split 1 qty of each product into a new order, increase split quantities, and send it. 3. Increase quantities on the original order and send it again. Expected Behavior ================= - Initial preparation order remains unchanged (no line cancellations) - Split order creates a new preparation card with only unsend split quantities - Original order creates a new preparation card with only newly added quantities - No preparation line incorrectly aggregates quantities across orders Task-5355899 Related Comm. PR: https://github.com/odoo/odoo/pull/244195

### Description of the issue/feature this PR addresses: Prevent Out of Memory (OOM) crashes and drastically improve execution speed when generating the Swedish SIE4 verification export for massive datasets. ### Current behavior before PR: When exporting a large volume of journal entries (e.g., 190,000+ account moves), the `_export_l10n_se_sie4_verification` method relies on iterating through heavy ORM recordsets and accessing relational child fields (move.line_ids) inside a loop. This triggers a severe N+1 query problem, maxing out server RAM and causing an OOM crash. ### Desired behavior after PR is merged: The method now utilizes a hybrid data extraction approach: - The ORM is used strictly to safely evaluate domains (multi-company rules, dates, states) and fetch a lightweight list of valid move_ids. - A single SQL query with JOIN statements fetches all parent moves, child lines, and account codes in exactly one database query. - itertools.groupby chunks the flat, lightweight dictionary results back into their respective journal entries. The export now handles massive datasets in seconds with minimal memory overhead, while remaining perfectly secure. ### Benchmark: For Memory: | # Input Data | Before PR | After PR | | -------- | -------- | -------- | | ~190,000 moves | MemoryError | 407MB| | ~200,000 moves | 1.8GB | 174.8 MB| For Speed: | # Input Data | Before PR | After PR | | -------- | -------- | -------- | | ~190,000 moves | MemoryError | 5.10s | | ~200,000 moves | 1m29s| 5.3s| ### Reference: opw-6067999 Forward-Port-Of: odoo/enterprise#117577 Forward-Port-Of: odoo/enterprise#113227

The "show only 1 month at a time" optimization computes the navigated month as datetime.now() + month_id, so the controller passes that (month, year) tuple to _get_appointment_slots: https://github.com/odoo/enterprise/blob/57ec37b74a60c7e879a8afa66df5ab22a92c5bcd/appointment/models/appointment_type.py#L833 For a punctual appointment whose Allow Bookings range starts in a future month, the first displayed month is start_datetime.month, so the (month, year) tuple doesn't match the month the visitor is looking at. The model fills an empty month and the recovery loop refills the first displayed month (where slots actually live): https://github.com/odoo/enterprise/blob/57ec37b74a60c7e879a8afa66df5ab22a92c5bcd/appointment/models/appointment_type.py#L973-L988 The calendar the visitor just navigated to comes back empty. Compute the navigation base from start_datetime when it lies in the future and keep datetime.now() otherwise. month_id is added on top of that base so it always matches the displayed month index. Introduced by https://github.com/odoo/enterprise/commit/664857dd2c4ae2bc0dde8f44cb94136659ed2fe2 Steps to reproduce: 1. Open the Appointments app 2. Open an appointment type and set Schedule to Weekly and Allow Bookings to On specific dates with a range starting in a future month (for example 1 September to 31 December) 3. Save and click the Preview button in the header 4. Pick a staff member to reach the calendar 5. Click the right arrow to navigate to the next month => the next month shows "Sorry, we have no more slots available for this month" opw-6206293