search

swico / www.swiss-qr-invoice.org

Website for Swiss QR Invoice organization.
https://www.swiss-qr-invoice.org
11 stars 1 forks source link

Visualisation of "manual entry possible" vs. "payment is not processed" #4

Open Arthur26 opened 4 years ago

Arthur26 commented 4 years ago

Your validator is a very useful tool for developers. It delivers valuable information, especially in "edge-cases" where the specification is not clear enough.

One of my concerns is the clear decision, when to reject a qr-bill (because of a formal error) and when to allow manual entry within an m-banking solution. The specification "Processing rules for QR-bills" contains a table with this information, but it is not always 100% clear and bullet proof when to reject and when to allow manual entry (for example, if parts of the untimate debtor address are missing). I already hear the customers saying: "Why is this QR-Bill accepted by bank A and but rejected by bank B?"

To solve that possible discrepancy, I would appreciate if the validor stated a clear validation result wheter:

Then, there will be a clear answer to the question if bank A or bank B should adjust its implementation.

Is it somehow possible to add this additional validation result?

epsitec commented 4 years ago

Hi @Arthur26 thank you for your kind words. Our validator's main concern is the Swico-defined additional structured payment information. As such, I don't feel we should step on the feet of SIX, which should provide such guidance. I will, however, forward your very valid concerns to SIX, in the hope that they will see the interest in providing better guidance.

epsitec commented 4 years ago

@Arthur26 here is the reply from SIX, as I got it:

In der SIX Processing Rules kann man in der Tabelle die eindeutigen Statuten (z.B. payment is not processed, manual entry possible later) überprüfen, die dem unter Punkt 2 beschriebenen Antrag entsprechen

https://www.paymentstandards.ch/dam/downloads/processing-rules-en.pdf

See § 5.6 page 20 and page 21.

I do not feel that it is the role of the Swico validator to go in such a deep level of validation, even if it would indeed be nice for the developer and for the technically-literate user. It would make the validation process more complex, as we'd also have to do the OCR, not just the QR-code decoding in order to try and identify cases such as "Amount is present in the Swiss QR Code but not in the visible part".

Arthur26 commented 4 years ago

The idea here ist not to use OCR and verify the validity of the whole payment slip. It should only validate the data of the Swiss QR Code and show the result whether an m-banking solution should reject, or accept the code (or let the user complete the data structure). I'm thinking of situations when the address type of "PayableBy" is missing, but the adress is filled.

But I agree that this might be out of your scope.