ImprovedHighlight of Weekly #005

PAY by square QR codes on Slovak invoices

Slovak invoices can carry the PAY by square QR code, which Slovak banking apps read, instead of the EPC SEPA code most of them ignore.

Versions20.0
ModulesSlovak - Accounting l10n_sk
AppLocalizations

Pull requests and commits

BranchPull requestCommit
20.0odoo/odoo#283549 ↗53a9fadd18 ↗

Commit message

[IMP] l10n_sk: PAY by square invoicing QR code

PAY by square is the payment QR-code standard of the Slovak Banking
Association. It is printed on virtually every Slovak invoice and is read
by every Slovak banking application: the customer scans it and the
payment form comes up pre-filled with the IBAN, amount, currency,
beneficiary and variable symbol.

Slovak customers currently get the EPC SEPA Credit Transfer QR-code
instead, which most Slovak banking applications do not recognise.

This commit registers a 'sk_qr' QR-code method on res.partner.bank that
builds the PAY by square sequence: the tab-separated data model of table
15 of specification 1.1.0, prefixed with its CRC-32, compressed with raw
LZMA1 and encoded in base32hex. Everything is computed offline with the
standard library, so no service is called and no dependency is added.

The method is only eligible for a bank account located in Slovakia, held
in EUR on an IBAN, and it is sequenced ahead of the SEPA QR-code so that
Slovak accounts get the code their banks actually read, while every
other account keeps the method it has today.

The Slovak variable symbol, which is what Slovak banks reconcile
incoming payments on, is derived from the digits of the payment
reference. The payment due date, which the generic QR-code generation
signature does not carry, is forwarded by account.move through the
context; it is an optional field of the data model, so it is left empty
for the callers that build a code without an invoice.

Since the fields are joined on a tab, a tab in the payment reference or
in the beneficiary name would shift every field after it and produce a
code that checksums correctly but decodes to the wrong payment, so those
two values have their tabs replaced by a space.

The encoder is asserted against the data models and codes published as
test vectors by the `pay-by-square` package, an independent
implementation of the specification, and a second test decodes a
generated code back into the payment data model.

My stack

Pick the versions and apps you run. Weekly digests, this week's table and All changes then show only what concerns you. Saved in this browser.

Versions
Apps
Modules