Validate_Finance_IBAN (was: Re: [PEAR-DEV] Mod 10 for Payment package?)

On 17 Sep 2003 at 11:49, Piotr Klaban wrote: [...] > I do not know if my patch should be included as is to the Validate > package. I have implemented the functions for validating: > > issn() ISSN (International Standard Serial Number) > ismn() ISMN (International Standard Music Number) > ean8() EAN/UCC-8 number > ean13() EAN/UCC-13 number > ean14() EAN/UCC-14 number > ucc12() UCC-12 (U.P.C.) ID number > sscc() SSCC (Serial Shipping Container Code) > iban() IBAN (International Bank Account Number) For sure these sound interesting. I'll discuss this with Pierre and will come back to you. Let's speak a bit more about the iban-part ... > Some private functions: _mult_weights, _get_control_number, > _check_control_number. > > And there are some (Polish only) functions in the Validate/PL.php > (nip, bank_branch, pesel, regon, iban). > > All the functions are described in the API docs. > > And regarding the IBAN: > ----------------------- > For most purposes validating control functions would suffice, > but it is much better to have Validate_Finance_IBAN that > returns specific error (e.g. IBAN_COUNTRY_INVALID). Agreed. The Validate::iban is just there for "ease of use". This was an essential part that Pierre asked us to have implemented. So if you just need a quick valid / invalid this one is for you. But surely if you implement further checks in your application (and bother about correct error-messages) you should use Validate_Finance_IBAN directly. > And the reasons why I wrote Validate_PL::iban(): > - it validates ok IBAN number without country code (no PL) Well, I don't see the need for this. Without "PL" this is no valid IBAN. And if this problem occurs for your special implementation (e.g. in a form where people from Poland are supposed to enter their IBAN without the PL) you can easily add the "PL" to the string right before sending it through the validation-function. As said, without PL it's *not* a valid IBAN according to the rules. And I'm stricly against putting this into Validate for the above mentioned reasons. > - it validates bank branch control digit (in the middle of > the IBAN). It uses then Validate::iban() for validating > the main two control digits. Do you have official docs about this? I wanted to add bank-code- checking for Germany myself and I sure further checks for other countries should be added as well. But please let's stick to "official docs" so we will never classify an IBAN as invalid although it is valid. If you have information about the polish IBANs please send me the docs via private email and I'll be happy to integrate special checks for PL - no problem. About the problem with German bank-codes / bank-account-numbers: I've had a conversation with a representative from the Federal German Bank (hope I got the title right). They told me that it's possible to validate the bank-codes against a list which is published every 3 month. I plan to add this feature at some point in the future using a general separate bank-code-check-function for Germany since this also makes sense. And when validating a German IBAN this function will be used to validate the bank-code-checks. But for the bank-account-numbers there is a problem: According to the bank-code-number-list a certain algorithm for the bank-account- numbers has to be chosen (per bank-code). This would mean that several algos have to be implemented (and I plan on doing this). But when a bank-account-numer is "invalid" in the sense of the algorithm here in Germany this doesn't mean that the account-number is really invalid. The Federal German Bank told me that in the past (many years ago) banks have issued bank-account-numbers that don't follow a certain algo. These are quite few numbers - but they still exist and won't be changed / cleared in a reasonable time. So you could send the input back to the user with a warning ("maybe your bank-account- numer is invalid - please recheck") but you *must* accept it if the user says that his number is okay even though it is not recognized by the algo. Maybe algo-checks work for *all* bank-account-numbers in some other country. So I intend to introduce a 3-way-logic in this case. An also may return valid, invalid and "maybe-invalid". > Than global Validate::iban() would not be needed any more > if Validate_Finance_IBAN could be used, but Validate_PL::iban() > would be nice to preserve. See above. And then Validate_PL::iban is no longer needed. This makes no sense in my eyes because it just adds another not needed function. IBAN is an international standard - and we should stick to that standard with one (!) API-interface. It's possible to add further country-specific checks in Validate_Finance_IBAN easily based on the country-code in the IBAN itself. When I want to check a certain given IBAN I don't want to bother if it's a PL one or something else. The country is indicated in the IBAN itself - and that's it! Regards Stefan