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.
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.
| Branch | Pull request | Commit |
|---|---|---|
| 20.0 | odoo/odoo#283549 ↗ | 53a9fadd18 ↗ |
[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.