Odoo Changelog — 2026-05-18

Monday, May 18, 2026

9 changes · 19.0

New Features(1)

New functionality added to Odoo

[ADD] l10n_be_pos_blackbox: Belgian POS fiscal data module v2

Enterprise19.0l10n_be_pos_blackboxMEDIUM

This update implements the required Belgian fiscal reporting specifications for certified POS restaurant systems, ensuring compliance with FPS Finance regulations. It manages communication with the blackbox device, automatically generates fiscal receipts, and provides robust error handling for accurate transaction recording. The module includes features for training mode, debugging, and handling network outages to maintain data integrity.

Original PR description

Implement the Belgian Registered Cash Register (Caisse Enregistreuse Certifiée) v2 specification as required by FPS Finance for certified POS restaurant systems.

The implementation is split into a core module and five bridge modules:

l10n_be_pos_blackbox (main module):
- FDM (Fiscal Data Module) communication layer that signs every fiscal
  event by sending a structured message to the blackbox device and
  receiving a hash + VSC counter in return.
  M110 (sale), M111 (refund), M112 (partial refund), M121 (order),
  M122 (cost-centre change), M123 (pre-bill), M130 (money in/out),
  M131 (drawer open), M140/M141 (work in/out), M150 (invoice),
  M160 (copy), M180/M181 (X/Z turnover report), M182/M183 (user X/Z
  report), UC230 (sale correction).
  M160 (copy), M180/M181 (X/Z turnover report), M182/M183 (user X/Z
  report), UC230 (sale correction).
- Input generator that encodes all line-level fiscal data (PLU hash,
  VAT groups, price rounding, grouping IDs) according to the spec.
- Fiscal receipt template (XML) that renders the blackbox hash,
  VSC counter, POS system identifier, and event sequence number on
  every printed receipt.
- X/Z daily report views with fiscal totals per VAT category.
- Training-mode support: activates the FDM training flag so the
  device does not count test transactions.
- Inspect popup (debug) for examining raw FDM messages.
- Error/warning popup system with traceback messages from the device.
- LocalStorage queue to replay pending mutations after a network
  outage.
- pos_config / pos_session overrides: enforce blackbox constraints
  (only EUR, no rounding, mandatory restaurant mode, etc.),
  manage device pairing, and accumulate per-session fiscal counters.
- Extensive unit-test suite: >6 000 lines covering the input
  generator's grouping-ID logic, price-consistency rules, and every
  mutation type against golden JSON fixtures.
- Browser tour tests (oracle + regression tours).

l10n_be_pos_blackbox_hr:
- Clock-in / clock-out flows for employees trigger M140/M141 work
  in/out mutations; employee INSZ/NISS number is required and stored
  on hr.employee; pos_session accumulates per-employee work records.

l10n_be_pos_blackbox_loyalty:
- Gift-card and discount reward lines are mapped to the correct MPV
  fiscal codes (UC260/UC261); loyalty products are flagged so the
  input generator can calculate their contribution to the signed
  total correctly.

l10n_be_pos_blackbox_self_order:
- Intercepts self-order confirmation on kiosk screens to sign the
  order with the FDM before the confirmation page is shown; adds a
  controller to expose the required blackbox data to the kiosk
  frontend.

l10n_be_pos_blackbox_settle_due:
- Handles the "settle due" payment flow: products used to represent
  deferred payments are flagged and treated as zero-VAT lines in the
  signed message.

l10n_be_pos_blackbox_urban_piper:
- Patches the Urban Piper ticket-screen and pos_store so that online
  orders routed through Urban Piper are also signed before finalisation.

task-id: 5864870

community PR: https://github.com/odoo/odoo/pull/229692

#Belgium#POS#Fiscal Reporting#Compliance

Improvements(1)

Enhancements to existing features

[IMP] sale_account_accountant: directly reconcile the invoice

PR #108546

Enterprise19.0saleaccountMEDIUM

This update streamlines the process of reconciling invoices from sale orders. By automatically passing a context key, the system now directly reconciles invoices created from sale orders, reducing manual effort and improving accuracy. This enhancement simplifies invoice management and ensures consistent record-keeping.

Original PR description

This commit will allow to automatically reconcile the invoice create from the sale order by passing a context key that will be used in the create_invoices function.

task-5502964

#invoice#sale order#reconciliation

Bug Fixes(7)

Resolved issues and error corrections

[FIX] hr_appraisal: Fix my team filter

PR #117209

Enterprise19.0hr_appraisalMEDIUM

This update corrects a bug where managers weren't seeing all their direct reports in the 'My Team' filter within the HR appraisal module. The fix utilizes a more accurate method for determining hierarchical relationships, ensuring managers correctly see all subordinates. This improves the usability and accuracy of the appraisal process.

Original PR description

Before this commit:
If A is a manager of B and B is a manager of C,
A cannot see C under My Team filter.

Fix: Use is_subordinate.

task-6204754

#HR#Appraisal#Hierarchy

[FIX] l10n_{ca,ec,eg,pk,sa}_reports: filter tax on tax return entries

PR #116813

Enterprise19.0accountl10n_ca_reportsl10n_ec_reportsl10n_eg_reportsl10n_ke_reportsl10n_pk_reportsl10n_sa_reportsMEDIUM

This update fixes an issue where tax return entries incorrectly included taxes from multiple regions (like British Columbia) instead of filtering for the specific tax return type (e.g., Manitoba PST). The change ensures that tax return entries accurately reflect the taxes owed based on the return type, improving the accuracy of VAT reporting across Canada, Ecuador, Egypt, Pakistan, Saudi Arabia, and Kenya.

Original PR description

Issue:
Validating a tax return creates an entry with all the tax aml from the company instead of filtering them according to the tax return type.

Steps to reproduce:
- In a company in Canada
- Invoice a Customer from British Columbia in the previous month (A)
- Confirm
- Go to tax report -> Return
- Review and Validate tax return for "Manitoba PST Return (CA)" for month A
- Click on the 3 dots -> View Entry

Current Behavior:
- Entry has lines for PST in British-Columbia and GST taxes

Expected behavior:
- Entry has lines for PST in Manitoba only

Cause:
https://github.com/odoo/enterprise/pull/98158 introduces method `_get_vat_closing_entry_additional_domain` in the wrong class.


opw-6065838

Forward-Port-Of: odoo/enterprise#116366

#tax#VAT#reporting#accounting

[FIX] pos_blackbox_be: correct price on feedback screen

PR #104468

Enterprise19.0posMEDIUM

This update fixes a problem where the POS feedback screen displayed incorrect order totals. The change ensures that order prices are calculated and displayed accurately, even when requests are delayed. It also prevents the POS from finalizing orders with errors, improving the overall transaction process.

Original PR description

We now call manually `setOrderPrices` on order validation to ensure `amount_total` is set on the order before displaying the feedback screen which depends on it.

The issue is that requests to the FdM delay the call to this method, making the PoS display `0` as the amount is `undefined` in the meantime.

We also ensure the PoS doesn't finalize the validation if an error occurs.

see odoo/odoo#244298

#POS#Pricing#Order Validation

[FIX] delivery_fedex_rest: send reference to stock transfer

PR #116870

Enterprise19.0delivery_fedex_restMEDIUM

This update corrects a bug where Fedex delivery labels were missing a crucial 'REF' field, which is required by the shipping carrier. The fix ensures that this field is populated correctly, preventing delivery issues and improving label accuracy. This ensures proper integration with the Fedex shipping system.

Original PR description

Issue ----- `REF` field of Fedex labels is missing. Steps to reproduce ----- - Setup Fedex - Create a product (set weight) - Create a delivery for the product - Set carrier as Fedex - Validate…

Issue
-----
`REF` field of Fedex labels is missing.

Steps to reproduce
-----
- Setup Fedex
- Create a product (set weight)
- Create a delivery for the product
	- Set carrier as Fedex
- Validate delivery
- Opend the label

> REF field is empty

Cause
-----
When filling the `CustomerReferences`, we only specify the SO

https://github.com/odoo/enterprise/blob/aae680f5b86fa87193ba6616e8431eed985b2ee7/delivery_fedex_rest/models/fedex_request.py#L309-L313

The `REF` field is populated using `CUSTOMER_REFERENCE` references, which is not present in this case.

Excerpt of the API DOC
-----
```
"CustomerReference": {
	"type": "object",
	"properties": {
		"customerReferenceType": {
			"type": "string",
			"description": [...],
			"example": "DEPARTMENT_NUMBER",
			"enum": [
				"CUSTOMER_REFERENCE",
				"DEPARTMENT_NUMBER",
				"INVOICE_NUMBER",
				"P_O_NUMBER",
				"INTRACOUNTRY_REGULATORY_REFERENCE",
				"RMA_ASSOCIATION"
			]
		},
		"value": {
			"type": "string",
			"description": [...],
			"example": "3686"
		}
	}
},
```

[...] replaces long description strings, refer to API for full documentation.

Result after fix
-----
<img width="477" height="738" alt="image" src="https://github.com/user-attachments/assets/0d3a0786-5b7d-41cc-8548-2dc7b0f379ab" />

-----
Ticket:
opw-6101620

#delivery#fedex#shipping#label

[FIX] pos_platform_order: cancel order kitchen ticket printing issue

PR #114171

Enterprise19.0pos_platform_orderMEDIUM

This update resolves an issue where kitchen tickets were incorrectly printed after a platform order was cancelled, regardless of where the cancellation occurred (Odoo PoS or provider platform). Now, cancelled platform orders will no longer trigger kitchen ticket printing, improving order accuracy and reducing unnecessary printouts.

Original PR description

This fixes platform orders should not send to kitchen printer when the platform orders being cancelled.

Currently accepting platform orders will not send to kitchen printer. However when cancelling platform orders on either provider platform, or within Odoo PoS. It will print a kitchen ticket of customer note.

task-6071740

#POS#Orders#Printing#Cancellation

[FIX] l10n_mx_edi: allow out_refund to be PPD

PR #115470

Enterprise19.0l10n_mx_ediMEDIUM

This update resolves a restriction in the l10n_mx_edi module that prevented credit notes (out-refunds) from utilizing Payment Policies (PPD) as required by the Mexican SAT portal. The change allows credit notes to correctly reflect payment policies, ensuring compliance with Mexican tax regulations. This improves the functionality for businesses using the module for Mexican e-invoicing.

Original PR description

Currently, credit notes cannot be PPD (payment_policy), however, SAT portal allows it.

**STEP TO REPRODUCE**
1. Install the l10n_mx_edi module.
2. Create an invoice with PPD (either changing it or through payment terms).
3. After send CFDI, generate a credit note and try to set PPD

**FIX**

Allow move_type = 'out_refund' to be PPD.

Task-6049654

Forward-Port-Of: odoo/enterprise#114886

#mexico#edi#credit note#tax compliance

[FIX] documents_project: extend template undo with documents folder management

PR #117303

Enterprise19.0documents_projectMEDIUM

This update resolves a bug where undoing a template conversion left the project's documents folder in an inconsistent state, preventing users from creating new templates from the same project. The fix ensures the original documents folder is properly restored and cleaned up during the undo process, improving template management functionality.

Original PR description

Steps to Reproduce:
---
1. Create a project with documents.
2. Convert it into a template.
3. Click on "Undo".
4. Try to convert the project into a template again.

Issue:
---
After undoing the template conversion, the project's original documents folder
remained archived while the template's documents folder stayed active. This
inconsistent state prevented subsequent template creation from the same project.

Current behaviour:
---
A UserError is raised: "You cannot duplicate document(s) in the Trash."

Expected behaviour:
---
Undoing template conversion should properly restore original project's
documents folder and clean up template's documents folder.

Fix:
---
- Archive original project's documents folder during template creation
- Implement documents folder unarchival during undo operations

task-4916027

Forward-Port-Of: odoo/enterprise#91595

#templates#documents#project management

Implement the Belgian Registered Cash Register (Caisse Enregistreuse Certifiée) v2 specification as required by FPS Finance for certified POS restaurant systems. The implementation is split into a core module and five bridge modules: l10n_be_pos_blackbox (main module): - FDM (Fiscal Data Module) communication layer that signs every fiscal event by sending a structured message to the blackbox device and receiving a hash + VSC counter in return. M110 (sale), M111 (refund), M112 (partial refund), M121 (order), M122 (cost-centre change), M123 (pre-bill), M130 (money in/out), M131 (drawer open), M140/M141 (work in/out), M150 (invoice), M160 (copy), M180/M181 (X/Z turnover report), M182/M183 (user X/Z report), UC230 (sale correction). M160 (copy), M180/M181 (X/Z turnover report), M182/M183 (user X/Z report), UC230 (sale correction). - Input generator that encodes all line-level fiscal data (PLU hash, VAT groups, price rounding, grouping IDs) according to the spec. - Fiscal receipt template (XML) that renders the blackbox hash, VSC counter, POS system identifier, and event sequence number on every printed receipt. - X/Z daily report views with fiscal totals per VAT category. - Training-mode support: activates the FDM training flag so the device does not count test transactions. - Inspect popup (debug) for examining raw FDM messages. - Error/warning popup system with traceback messages from the device. - LocalStorage queue to replay pending mutations after a network outage. - pos_config / pos_session overrides: enforce blackbox constraints (only EUR, no rounding, mandatory restaurant mode, etc.), manage device pairing, and accumulate per-session fiscal counters. - Extensive unit-test suite: >6 000 lines covering the input generator's grouping-ID logic, price-consistency rules, and every mutation type against golden JSON fixtures. - Browser tour tests (oracle + regression tours). l10n_be_pos_blackbox_hr: - Clock-in / clock-out flows for employees trigger M140/M141 work in/out mutations; employee INSZ/NISS number is required and stored on hr.employee; pos_session accumulates per-employee work records. l10n_be_pos_blackbox_loyalty: - Gift-card and discount reward lines are mapped to the correct MPV fiscal codes (UC260/UC261); loyalty products are flagged so the input generator can calculate their contribution to the signed total correctly. l10n_be_pos_blackbox_self_order: - Intercepts self-order confirmation on kiosk screens to sign the order with the FDM before the confirmation page is shown; adds a controller to expose the required blackbox data to the kiosk frontend. l10n_be_pos_blackbox_settle_due: - Handles the "settle due" payment flow: products used to represent deferred payments are flagged and treated as zero-VAT lines in the signed message. l10n_be_pos_blackbox_urban_piper: - Patches the Urban Piper ticket-screen and pos_store so that online orders routed through Urban Piper are also signed before finalisation. task-id: 5864870 community PR: https://github.com/odoo/odoo/pull/229692

Issue: Validating a tax return creates an entry with all the tax aml from the company instead of filtering them according to the tax return type. Steps to reproduce: - In a company in Canada - Invoice a Customer from British Columbia in the previous month (A) - Confirm - Go to tax report -> Return - Review and Validate tax return for "Manitoba PST Return (CA)" for month A - Click on the 3 dots -> View Entry Current Behavior: - Entry has lines for PST in British-Columbia and GST taxes Expected behavior: - Entry has lines for PST in Manitoba only Cause: https://github.com/odoo/enterprise/pull/98158 introduces method `_get_vat_closing_entry_additional_domain` in the wrong class. opw-6065838 Forward-Port-Of: odoo/enterprise#116366

We now call manually `setOrderPrices` on order validation to ensure `amount_total` is set on the order before displaying the feedback screen which depends on it. The issue is that requests to the FdM delay the call to this method, making the PoS display `0` as the amount is `undefined` in the meantime. We also ensure the PoS doesn't finalize the validation if an error occurs. see odoo/odoo#244298

Issue ----- `REF` field of Fedex labels is missing. Steps to reproduce ----- - Setup Fedex - Create a product (set weight) - Create a delivery for the product - Set carrier as Fedex - Validate delivery - Opend the label > REF field is empty Cause ----- When filling the `CustomerReferences`, we only specify the SO https://github.com/odoo/enterprise/blob/aae680f5b86fa87193ba6616e8431eed985b2ee7/delivery_fedex_rest/models/fedex_request.py#L309-L313 The `REF` field is populated using `CUSTOMER_REFERENCE` references, which is not present in this case. Excerpt of the API DOC ----- ``` "CustomerReference": { "type": "object", "properties": { "customerReferenceType": { "type": "string", "description": [...], "example": "DEPARTMENT_NUMBER", "enum": [ "CUSTOMER_REFERENCE", "DEPARTMENT_NUMBER", "INVOICE_NUMBER", "P_O_NUMBER", "INTRACOUNTRY_REGULATORY_REFERENCE", "RMA_ASSOCIATION" ] }, "value": { "type": "string", "description": [...], "example": "3686" } } }, ``` [...] replaces long description strings, refer to API for full documentation. Result after fix ----- <img width="477" height="738" alt="image" src="https://github.com/user-attachments/assets/0d3a0786-5b7d-41cc-8548-2dc7b0f379ab" /> ----- Ticket: opw-6101620

This fixes platform orders should not send to kitchen printer when the platform orders being cancelled. Currently accepting platform orders will not send to kitchen printer. However when cancelling platform orders on either provider platform, or within Odoo PoS. It will print a kitchen ticket of customer note. task-6071740

Currently, credit notes cannot be PPD (payment_policy), however, SAT portal allows it. **STEP TO REPRODUCE** 1. Install the l10n_mx_edi module. 2. Create an invoice with PPD (either changing it or through payment terms). 3. After send CFDI, generate a credit note and try to set PPD **FIX** Allow move_type = 'out_refund' to be PPD. Task-6049654 Forward-Port-Of: odoo/enterprise#114886

Steps to Reproduce: --- 1. Create a project with documents. 2. Convert it into a template. 3. Click on "Undo". 4. Try to convert the project into a template again. Issue: --- After undoing the template conversion, the project's original documents folder remained archived while the template's documents folder stayed active. This inconsistent state prevented subsequent template creation from the same project. Current behaviour: --- A UserError is raised: "You cannot duplicate document(s) in the Trash." Expected behaviour: --- Undoing template conversion should properly restore original project's documents folder and clean up template's documents folder. Fix: --- - Archive original project's documents folder during template creation - Implement documents folder unarchival during undo operations task-4916027 Forward-Port-Of: odoo/enterprise#91595