CustomerID length

[Franco2911]

Hello, Thank you so much for this very poweful library and easy to use :)

It seems that the CustomerID will not change with the new QRCode bill. We have some IDs with length between 4 and 12 digits.

For oldest BVR, we used 14 digits for IDs and 12 for reference + 1 modulo 10 check digit. Like this in your code.

Maybe you can change this if you don't have other informations about the IDs max length.

$completeReferenceNumber = str_pad($this->getCustomerIdentificationNumber(), 14, '0', STR_PAD_RIGHT); $completeReferenceNumber .= str_pad($this->getReferenceNumber(), 12, '0', STR_PAD_LEFT); $completeReferenceNumber .= $this->modulo10($completeReferenceNumber);

If you need to implement an Output with FPDF, I can send you a QRFooter for this purpose. Thank you for help and let me know if you want to implement an FPDF output in your library.

Best regards

[sprain]

Based on my understanding, this reference number works like it currently does on BESR-Einzahlungsscheine where the customer identification number always consists of exactly 6 characters.

See page 21 of this documentation from UBS (PDF). There is its mentioned as 6 positions (13-18) for client identification.

But I have to admit that I am not 100% sure if all the rules of the current BESR reference number will also apply for the qr bill. If you have any official documents at hand which show otherwise, I am very happy to get to know about it.

[sprain]

If you need to implement an Output with FPDF, I can send you a QRFooter for this purpose. Thank you for help and let me know if you want to implement an FPDF output in your library.

An FPDF output module next to the HtmlOutput would definitely be a good enhancement for this library. You are welcome to create a pull request for such an implementation.

[Franco2911]

Hello, Thank you for your answere, you are right, the reference will stay exactly the same as now. But every bank works differently as you already know.

This is my ClientID and it stays the same for QRBill : 9451802 (string 7) for Raiffeisen bank.

And for Postfinance there is no ClientID the reference looks like 000000000xxxx.

I made my reference with Epsitec Cresus documentation, you can show it here

I dont use the bill and reminder digits and use 14 digits for ClientId. They used 11.

As I know all actual ClientId stays the same for QRBill. Unfortunatly there are no documentation about this reference.

[Franco2911]

If you need to implement an Output with FPDF, I can send you a QRFooter for this purpose. Thank you for help and let me know if you want to implement an FPDF output in your library.

An FPDF output module next to the HtmlOutput would definitely be a good enhancement for this library. You are welcome to create a pull request for such an implementation.

I will prepare the file, actualy is only for my application. let me 5 days and I send it to you.

[sprain]

This is my ClientID and it stays the same for QRBill : 9451802 (string 7) for Raiffeisen bank.

You are right. I did some more research and there is actually this page from Raiffeisen bank where it states that the number can indeed have a variable length. I will need to look into this and figure out more about how it works in these cases.

• https://www.raiffeisen.ch/rch/de/firmenkunden/liquiditaet-und-zahlungsverkehr/debitoren/oranger-einzahlungsschein.html
• https://www.raiffeisen.ch/rch/fr/clients-entreprises/trafic-paiements-et-liquidites/debiteurs/bulletin-de-versement-orange.html

[kohlerdominik]

I was also investigating on the format of the ISR-Number and found this document: https://www.paymentstandards.ch/dam/downloads/drehbuch-rechnung-steller-empfaenger-en.pdf

On Page12 - Chapter 4.1, it states:

The ISR reference can (but does not have to) continue to be used 1:1 as a QR reference. In this case, it is necessary to use the QR-IBAN. Proprietary account numbers (e.g. post account number) may no longer be used, but must also be printed in the QR-IBAN format.The ISR participation number is no longer mandatory. However, to avoid erroneous pro-cessing, it is recommended to transfer ISR references 1:1 as QR references (if any) in the paral-lel phase of ISR and QR-bill.

For us, we want to use this format: 21 00000 00000 ##### ##### ####C, where # represents our document-id and C the check digit, which i understand to be perfectly fine with the new QRbill with QR-IBAN and QR-reference.

However, for your use-case, you should probably check the other 4.x chapers, as they seem to represent other known types.

The document is also available in German and French.

[Franco2911]

For us, we want to use this format: 21 00000 00000 ##### ##### ####C, where # represents our document-id and C the check digit, which i understand to be perfectly fine with the new QRbill with QR-IBAN and QR-reference.

The format you want to use seems good with my understanding of this reference. The other tink is to be compatible with oldest bills to be abble to print them with QRCode instead of actual BVR. (if needed) I think, the best way is to validate 11/12 digits for ClientID and 14/15 for documents ID and check

[sprain]

I think, the best way is to validate 11/12 digits for ClientID and 14/15 for documents ID and check

This would not work for people who are using the full range of there internal reference number, which can be up to 20 characters in combination with the wide-spread 6-character client identification number.

[Franco2911]

It is very difficult to choose one or other validation for this purpose because every financial institute have theire own rules and some software developper other rules. The only think we are sure about; is that we have customers with ClientID with 0 to 9 digits at the moment. 0 only for PostFinance customers. A good choice could be to use a validation between 0 to 11 for ClientID and 27 - ClientID result to validate the documentID sequence. With that you are comptatible with every kind of use.

[kohlerdominik]

TL;DR

Based on my findings stated below, I suggest the implementation to leave as-is. For custom implementations, Developers should create their own flavor of QrPaymentReferenceGenerator.

---

I'm not very familiar with how the reference number was used old school.But I was able to check with two big swiss ERP solution where i have access to, and they do:

BE SRBE0 00000 DDDDD 0RRRR RRRRc
BESRBE = BESR (6)
DDDDD = Debtor (5)
RRRRRRRR = Invoice Number (8)

and

## YY##T TLLLL L000c
YY = Year (2)
TT = Type of service (2)
LLLLL = AutoIncrement index (5)

So the only thing I learn from this is, that in total with above discussion, there's no clear pattern. I think, 6 digit BESR is shared across all Orange Payment Slips (because it was required), while everything else is depending on the institute and customers need. And as stated in above document, Chapter 4.1, BESR is no longer required with QR-IBAN, as the new QR-IBAN must contain all information about the creditor.

ISR participant number is dropped -> client gets QR-IBAN

I think one important note on this is (found in Chapter 4 introduction):

An ISR participation contract is necessary for the use of the ISR procedure.

So people like us, just starting into electronic billing, might not want to and not have to make this contract to use QR bill. Therefore, we also do not have an ISR participation contract and might prefer to set 00 0000 for this reason.

[sdespont]

@kohlerdominik Just for the record, here is a basic explanation of how ISR payments works and why CustomerId exists.

With an ISR payment, all the money is almost (see *) always transiting through PostFinance. So, every banking institute or (regional ones) of every banks (Credit Suisse, UBS, Raiffeisen, ...) have a PostFinance account represented by the number 3 of the picture in the reference below.

Therefore, the PostFinance banking account of a bank (Raiffeisen for example) is like a bucket and is receiving all the money of every payments. So, it's a mess. To dispatch correctly the amount, the bank is using the customer ID of the reference number. So, all the clients of the bank must have a customer ID (which is not their banking account). To obtain this customer ID, an ISR request must be done to the bank. The customer ID is by convention the first numbers of the reference number. Usually 4 to 6, but Raiffeisen is using up to 9 numbers today, and some programs lets up to 11 numbers.

All clients with a banking account in PostFinance institute doesn't need to dispatch money because the money is already received in the target banking account. It is why they don't need to have a customer ID and it is set to 00000...

The last part of the reference number is used by the emitter of the ISR to match the expected payments and amounts received.

• In case of the payments are done at the desk or by the e-banking of a bank for an account in this bank, the money is not transiting by PostFinance.

Ref : https://www.raiffeisen.ch/talent-menthue/fr/clients-entreprises/trafic-paiements-et-liquidites/debiteurs/bulletin-de-versement-orange.html

[sdespont]

A good choice could be to use a validation between 0 to 11 for ClientID and 27 - ClientID result to validate the documentID sequence. With that you are comptatible with every kind of use.

Like @Franco2911 said, I think it is the a good choice.

[Franco2911]

BE SRBE0 00000 DDDDD 0RRRR RRRRc BESRBE = BESR (6) DDDDD = Debtor (5) RRRRRRRR = Invoice Number (8)

You're right, and it is why some software developper used to generate the reference using the unused 0 00000 to validate CustomerID on 11 or 12 digits.

[Franco2911]

Chapter 4.1, BESR is no longer required with QR-IBAN, as the new QR-IBAN must contain all information about the creditor.

ISR participant number is dropped -> client gets QR-IBAN

If I understand this, you're wrong the BESR is the actual account number like xx-xxxxxx-x and it will be replaced by the QRIban but the customerID will stay the same as today with 0 to almost 11 digits on depending institute.

When you ask for an ISR participation contract you will receive an account number until june 2020 after you receive a QRIban and your customerID except from Postfinance.

All explanation from @sdespont are also right

[sprain]

Thanks for all the explanations!

I created a pull request. Let me know what you think. https://github.com/sprain/php-swiss-qr-bill/pull/37

[geekdevs]

Based on my findings stated below, I suggest the implementation to leave as-is. For custom implementations, Developers should create their own flavor of QrPaymentReferenceGenerator.

If only there was no "final" keyword on that class. I don't understand why many library developers like that keyword so much - I had many times needing to copy-paste bunch of code just to override one small piece of code because of "final" restriction.

[sprain]

@geekdevs What would be your use case here to extend the class? The comment you quote is outdated and a change was actually made.

[geekdevs]

Sure, I know that variable length is implemented. But what I needed for my use case is customerID of 12 characters. I cannot tweak that easily, so had to fork just to change 1 digit.

[sprain]

This is interesting. Which bank issues 12-digit customer ids? If this is a thing, it would be good if QrPaymentReferenceGenerator would be adjusted accordingly in this library.

[geekdevs]

Thanks, this I still need to double check with the client to make sure ID is actually valid (it was on BKB bank). But technically I don't see why would you want to limit parts of it beyond just limiting to 27 characters for the whole reference as there seems to be no specification regarding this.

[sprain]

I don't see why would you want to limit parts of it beyond just limiting to 27 characters for the whole reference as there seems to be no specification regarding this.

This is indeed the question we need to find the answer to: is there a specification and was does it say? It will likely be worth an issue by itself.