Closed andre-m-dev closed 4 weeks ago
Thanks for describing the issue!
Just to make sure I understand: are you saying that one of the IBAN codes that faker generates could also fall into the category of a QR-IBAN in case it matches a bank's QR-IID?
Is there a way to tell them apart (IBAN vs QR-IBAN)? Is there a list of QR-IIDs somewhere? And for your application, why would it matter if the generated code is IBAN or QR-IBAN - are they used in different situations?
Maybe this could be an addition to the documentation. It feels more like a feature request to me than a bug, but I need a bit more context.
I accidentally selected a bug issue instead of open issue, sorry for that.
Just to make sure I understand: are you saying that one of the IBAN codes that faker generates could also fall into the category of a QR-IBAN in case it matches a bank's QR-IID?
Exactly
Is there a way to tell them apart (IBAN vs QR-IBAN)? Is there a list of QR-IIDs somewhere?
The QR-IBAN contains the QR-IID (bank identification) in positions 5-9, using a number range from 30000 through 31999.
And for your application, why would it matter if the generated code is IBAN or QR-IBAN - are they used in different situations?
Because a valid QR reference is required for a transfer to a QR-IBAN
Thanks for providing more context, @andre-m-dev is a QR-IBAN not a valid one? Maybe documenting that the generator might return a QR-IBAN is enough to let users know from now on. I am not sure we'd want to restrict the generator to exclude them 🤔
@stefannibrasil the generated IBANs are valid, only unstable tests could occur. I had tried to find a way to mark this in locales/en/bank.yml in an uncomplicated way. I would not want to prevent the generation itself.
I solved the "problem" in our factory as follows
def generate_swiss_non_qr_iban
loop do
iban = Faker::Bank.iban(country_code: 'CH')
return iban unless iban[4..8].to_i.between?(30_000, 31_999)
end
end
It's not the prettiest solution, but it protects against randomness
Honestly, I don't use faker in my tests, especially if the test data is part of the business logic of the app but if you're okay with handling random values in your tests, this works. Could you add a note about this case in the docs for this generator?
Perhaps an issue is too much at this point. Everything works as intended. Sorry for the disturbance.
No problem at all. It's good to know about this. If you're open for it, adding a note in the docs about this could help others 👍
Describe the bug
It's not really a technical problem, but you can run into problems in your tests. In Switzerland there are 2 types of IBANs. Normal and QR-IBAN.
How does the QR-IBAN differ from the IBAN? Instead of the regular IBAN, the client's bank assigns them a QR-IBAN for the credit account. This is required to identify the beneficiary account. The only difference between the QR-IBAN and the IBAN is a different institution identification (IID), the QR-IID. Each legally independent financial institution participating in the procedure is assigned at least one QR-IID. The QR-IID of UBS Switzerland AG is 30005.
https://www.ubs.com/ch/en/corporates/payment-solutions/payments/payment-slips/faq.html
There is therefore the possibility of unreliable tests if such a QR-IBAN is generated by chance.
To Reproduce
Faker::VERSION => "3.4.2"
Additional context
I don't have a quick solution for this either, as the structure of locales/en/bank.yml does not provide an option for this.