Saturday, May 30, 2026
2 changes · 19.0
Resolved issues and error corrections
This update fixes a critical issue where mobile self-order receipts weren't being signed, leading to lost orders. Now, receipts are automatically signed on the server-side when a mobile customer completes their payment, ensuring accurate order tracking and receipt generation. The confirmation process for kiosk orders remains unchanged.
Original PR description
Mobile self-order clients never land on the confirmation page, so their orders were never sent to the blackbox fiscal data module and receipts were printed unsigned. Fix this by: - Overriding `getSelfOrderToPrint` to push the order to the blackbox if it has no signature yet, called when the payment notification arrives. - Restricting `beforePrintOrder` in the confirmation page to kiosk mode only, since mobile orders are now signed via `getSelfOrderToPrint`. task-id: 6172108 community PR: https://github.com/odoo/odoo/pull/263238
This update fixes an issue where partner names with '&' characters were incorrectly formatted during SEPA export, leading to bank rejections. The change ensures '&' is preserved in human-readable fields like partner names and addresses, aligning with banking standards and preventing export failures.
Original PR description
Problem: The previous fix (replacing '&' with '+' in _replace_characters_SEPA) was applied globally, affecting both reference/identifier fields and human-readable fields such as <Nm> (partner name)…
Problem:
The previous fix (replacing '&' with '+' in _replace_characters_SEPA) was applied globally, affecting both reference/identifier fields and human-readable fields such as <Nm> (partner name) and address lines.
As a result, a partner named "test & test GMBH" was exported as:
<Nm>test + test GMBH</Nm>
instead of the expected:
<Nm>test & test GMBH</Nm>
This caused bank file rejections because '&' is the correct XML encoding of '&' and is accepted by banks in human-readable fields.
Root cause:
ISO 20022 / EPC217-08 distinguishes two categories of data elements:
- Reference/identifier fields (InstrId, Ustrd, etc.): must use the restricted basic Latin character set — '&' is not allowed and must be replaced with '+'.
- Human-readable fields (Nm, AdrLine, etc.): may contain the extended Latin character set — '&' is valid and must be preserved so lxml can XML-escape it to '&' in the output.
Fix:
Revert the global '&' → '+' replacement in _replace_characters_SEPA so that '&' is preserved for name/address fields. The replacement of '&' with '+' for reference/identifier fields is already handled explicitly at the call sites in _get_CdtTrfTxInf (InstrId, Ustrd) via .replace('&', '+') before sanitize_communication is called.
ref commit : https://github.com/odoo/enterprise/pull/110809/changes/9e698e4ac9fdf66189ff6712f90a144560a1b484
documentation https://www.europeanpaymentscouncil.eu/sites/default/files/KB/files/EPC217-08%20Draft%20Best%20Practices%20SEPA%20Requirements%20for%20Character%20Set%20v1.1.pdf:
Forward-Port-Of: odoo/enterprise#118511
Forward-Port-Of: odoo/enterprise#115409