Dat is leuk ja die BigMod.
Ik zat me nog af te vragen of er moet worden gecheckt op de structuur van de string.
Bijvoorbeeld eerste 2 karakters is land en daarna 2 karakters getal.
En is Ord(AnsiChar(Char)) goed? Of beter Ord(Char).
Dat is leuk ja die BigMod.
Ik zat me nog af te vragen of er moet worden gecheckt op de structuur van de string.
Bijvoorbeeld eerste 2 karakters is land en daarna 2 karakters getal.
En is Ord(AnsiChar(Char)) goed? Of beter Ord(Char).
Last edited by Anoniem; 24-Oct-12 at 22:55.
Ik heb in mijn versie de volgende checks:
- Minimaal 5 tekens, maximaal 34 tekens,
- Eerste 2 tekens zijn letters,
- Volgende 2 tekens zijn cijfers,
- De 'modulo 97' check.
Daarnaast zou je nog land-specifieke checks kunnen doen:
- NL heeft altijd 4 letters voor de bankcode, die volgens mij ook altijd overeenkomen met de eerste 4 letters van de BIC code (niet officieel)
- Rekeningnummer in NL, achter de bankcode, is altijd 10 cijfers (vaste lengte).
- Code begint uiteraard met NL.
Voor Duitsland heb je soortgelijke regels. Daar is het rekeningnummer ook 10 cijfers, maar is de bankcode 8 cijfers.
De vraag is alleen of je dat soort checks allemaal uit wilt voeren. Het belangrijkste van de check is dat het moet voorkomen dat je een typefout maakt. Dat lukt met die modulo al aardig. De rest is leuk voor extra, maar niet echt nodig, denk ik. Zelfs als voldoet het aan al deze checks, dan garandeert dat nog geen geldig rekeningnummer.
1+1=b
Bedankt, mijn versie wordt dus de kortste:
delphi Code:
IbanOk := CheckIBAN(Nr);
Maar even een stapje terug: waarom zou je een IBAN controleren? Als je rekeningnummer en bank vraagt kun je IBAN zelf genereren en hoef je hem ook niet te controleren... toch?
Marcel
Je kunt 'm zelf genereren, maar je moet dan wel weten hoe. Bij betalingen (zeker wanneer je een betalingsbestandje aanlevert) moet je niet alleen de IBAN, maar ook de BIC meesturen. Uit die BIC en het bankrekeningnummer kun je in Nederland volgens mij het IBAN genereren omdat de Bankcode (toevallig?) overeenkomt.
Maar dat werkt niet overal, in Duitsland is het bank-deel in het IBAN een getal dat een regio beschrijft, terwijl het bankdeel in de BIC-code ook daar een 4-letterige afkorting van de banknaam is.
Hoe dan ook, het is wel een mogelijkheid om je database langs te lopen en zoveel mogelijk IBANs op deze manier in te vullen. Dat scheelt een hoop handwerk.
1+1=b
Zelf genereren? Kun jij ieder rek. nr. converteren naar IBAN, Marcel?
Kan dat niet dan? Je hebt er wel de nodige info voor nodig, met alleen een rekeningnummer kom je er inderdaad niet.
http://nl.ibancalculator.com/
Aparte site trouwens:
Wist ook niet dat "verificeren" een woord was (hoofdmenu van die site)Garantie:
Als u voor een overboeking teveel moet betalen omdat deze IBAN calculator door een softwarefout een fout IBAN heeft berekend, betalen wij tot 25 EUR aan u (zie details)
Last edited by Lodewijk; 25-Oct-12 at 10:29.
Ik dacht dat je je op z'n minst wel had ingelezen, Eric
Hier een pagina over het onderwerp op WikiPedia en deze link gebruikte ik gisteren als leidraad.
Beide beschrijven hoe een IBAN is opgebouwd, hoe je een omzetting kan doen en een conrole.
Greetz,
Peter.
TMemoryLeak.Create(Nil);
Ik verwacht niet dat elke consument zijn IBAN uit het hoofd weet. Je zou op een webshop het IBAN kunnen vragen, maar je zou ook een rekening nummer en bank kunnen vragen. Dan kun je daar zelf een IBAN van maken, dat lijkt me een stuk gebruiksvriendelijker.
Maar let wel op als je ook buitenlandse bezoekers verwacht, dan weet je niet alle banken tenslotte en kunnen de regels afwijken.
Marcel
Daarvoor is discriminatie in het leven geroepen: je binnenlandse bezoekers geef je het gemak van rekeningnummer en bank invullen, buitenlandse gasten moeten verplicht hun IBAN invullen. Op de nieuwe betaalpassen van o.a. ING staat het rekeningnummer al een tijdje als IBAN vermeld.
Klopt: zo'n IBAN check controleert alleen of het nummer zelf klopt, net als bij de Elf-proef;
het geeft geen garanties over het bestaan van een bank, nummer of land.
Uiteraard kun je wel een (kleine?) lookup-table maken, waarmee je dieper kunt testen op de
geldigheid van een ingegeven IBAN, maar kijken of een bepaalde rekening bestaat kan alleen
door in de database van de doelbank te kijken
TMemoryLeak.Create(Nil);
In mijn ogen is de invoering van IBAN een flinke stap achteruit. In het verleden was het genoeg om het rekeningnummer te kennen, nu moet je ook nog weten welke bank dat rekeningnummer loopt. Rekeningnummers waren nu juist 'bankonafhankelijk' geworden en Equens deed de routing van betalingen naar de juist bank. Maar omdat belgie, frankrijk en andere landen achterliepen, moeten wij ook maar weer een stap terug doen.
Tja, je vermindert het risico ermee dat je per ongeluk geld overmaakt naar de verkeerde rekening. Banken zouden in ieder geval de naam van de rekeninghouder moeten controleren, maar doen dat niet altijd. Dat zal ook niet altijd gaan, omdat daar makkelijk een schrijffout of ander verschil in sluipt (J.Jansen, Jansen, Janssen of Jan Jansen), waardoor dat vaak handwerk is. Of IBAN nodig is als je ook al de BIC-code gebruikt weet ik niet, maar in ieder geval zorgt een combinatie van die twee voor een verkleind risico op fouten door de verbeterde mogelijkheden op automatische controle.
Als consument heb je er denk ik nauwelijks last van. Rekeningnummers leer je doorgaans niet uit je hoofd. Betalingen gaan vaak digitaal. Als je al een rekeningnummer moet intoetsen, dan kun je dat vaak ergens van kopiëren.
Bij bedrijven is het ook een kwestie van eenmalig invoeren en de rest gaan vanzelf. Natuurlijk moet er dan wat aangepast worden aan de software, maar daar verdienen wij ons brood mee, toch?
1+1=b
Broodjes voor IT-ers gaat het zeker opleveren. Verder zit ik als consument niet te wachten op 18 letters en cijfers in te tikken ipv 9-10.
Dat hoef je ook niet, want als het goed is staat alles al in je adresboek van je betalingsprogramma
Delphi is great. Lazarus is more powerfull
There are currently 1 users browsing this thread. (0 members and 1 guests)
Bookmarks