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

On 18 Sep 2003 at 9:01, Piotr Klaban wrote: > On Wed, Sep 17, 2003 at 12:15:43PM +0200, Stefan Neufeind wrote: > > > - 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. > > Maybe I tell that another way - I like the Validate_Finance_IBAN > idea with several error messages; I do not want my patch to be > included into validate AS IS. You can do anything you want with that. > I've just implemented some validate functions, and wanted to share it > with the others. If it would be discarded, changed, moved - it is ok > to me. I am not personally attached to Validate*::iban() and I see no > problem in discarding Validate::iban() (especialy if there is other > IBAN method already implemented). That was a basic requirement when the Finance-part was introduced. Pierre asked me to implement an easy way to access iban-validation (without build an object for this purpose but being able to use a simple true / false out-of-the-box). This is also needed for the Validate::multiple-part(). > > > - 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 > > According to description of "IBAN per country": > http://www.ecbs.org/tr201country.htm > 1. Polish IBAN is derived from domestic account number (called NRB) > and in this document there is bank-branch check digit algorithm > given. In fact since 2004-01-01 each Polish bank account number has > to be in IBAN form without PL in the beggining. You mean Poland completely changed their account numbers to all fit the IBAN scheme? That's great news! But when you want to validate such a number you could just add "PL" to the String before Validation (in your app) - or am I wrong? No need for Validate_PL::iban or something like this, right? > 2. Germany has complicated domestic account number (because IMHO > german bank system is old and solid, while Polish banks were > splitted from the National Bank of Poland after year 1989). Are there any information about the official account numbers, bank codes etc. for Poland? E.g. which characters they may contain, if they follow certain algorithms (not just the IBAN-level-checksums but maybe other algos also for each account number)? > > 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. > > OK. Then http://www.ecbs.org/tr201country.htm -> Poland > part, would > suffice. But I do not know if checking domestic bank numbers should be > part of the Validate_Finance_IBAN? Maybe there should be separate > Validate_Finance_BankAccountNo to not pollute IBAN number check with > domestic rules (sometimes complicated). Agreed. For Germany I even wanted to separate the bank-account-check from the IBAN-part since here you can also have the "account number" separated from the bank-code (these are two fields in many forms). Does the same apply for Poland? Would you be able to have e.g. the bank-code separated from the account? Agreed that the "advanced" account-number-validations (which go further than e.g. checking the allowed characters in a bank-account- number) should be separated but that those separated functionality could still be used inside the IBAN-validation-part. There are various ways I could think of to achieve this separation. How about: Validate_Finance_PL_bankcode and Validate_Finance_PL_bankaccount And we could have a separate file Validate_Finance_PL? Another way of doing this would be: Validate_PL_Finance_bankcode but maybe we should tie the Finance-part together in one place, right? What do you (especially Piotr and Pierre) think about this? > > 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 > > There is a similar list released by the Polish Natinal bank, but > the Validate_PL::bank_branch() function simply checks control digit. > If there is a need for validating agains a internet-available list, I > can write a PL driver for that (similarly to Services_ExchangeRates). I guess we should clarify naming and implementation for this also on a generic way ... My intention was to have a look at the ExchangeRates-implementation (with caching and all that) and implement something generic for these checks regarding bankcodes etc. But currently it seems I would find the time for the next at least 2 weeks. Piotr, could you maybe have a look at how a good implementation for this could be done? But please keep in mind the following things: - Maybe downloading the updated bankcode-file would take a bit longer. So you need to be able to start a download (and processing) of a new version of the bankcode-list but still use the current list to process the client's request (and not leave him waiting for 2 minutes or so). Background: Here in Germany the files can get as large as 8MB or so - and if their server is a bit overloaded or the data rate is small you might run into problems. - You can't assume that you can load the whole datafile into memory at once. We need some other ways to read-and-parse the files. As said here in Germany the files can be 8MB or larger. This is because they also contain various additional information about the banks etc. - Maybe think of a way to download the file, extract all necessary details to a new file-format and delete the downloaded file ... but still keep it's date to be able to use "Last-Modified"-caching. This way we wouldn't need to store 8MB or more for each country and wouldn't need to load those plain-text-files everytime they are needed. What I have in mind could also be separate lists where one just contains the bankcodes with no additional information on the banks (for fast bankcode-lookups) and other files may also contain details about bank, city, algorithms used for bank-accounts etc. > > 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". > > In Poland there are rigid rules - each bank account has to have > control number right after the bank number. And Bank number is a fixed > part of the account number. Okay, nice to hear that Poland is no problem in this regard. But the 3-way-logic-problems may occur for other countries as well - so we have to keep this in mind during conception. > > 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! > > OK. But developer that would use Validate_Finance_IBAN would need to > add 'PL' or 'DE' every time. And that should be clearly stated in the > docs, because e.g. in Poland there is never PL prefix used in internal > account transfers. The situation you are talking about seems to be specific to poland - since they use "IBAN-like" numbers also for their domestic numbering. This is not the case in Germany e.g. So if you "convert" domestic numbers to international numbers you would simply have to add PL for Poland. Maybe everybody dealing with such numbers knows about this in Poland? It's something Poland-specific, right? Where could such information be integrated, what do you propose? Stefan