(c) Copyright 1999-2003 SDGN / Viafox, All rights reserved

Dit artikel is gepubliceerd in SDGN-Magazine nr. 52. De onderstaande, originele, tekst wijkt in gunstige zin iets af van het gepubliceerde artikel omdat een reactie van het ministerie van financiën niet op tijd voor het magazine was en omdat de voetnoten in het artikel ten onrechte als eye-catchers werden gebruikt.

Zonder grote problemen het Euro-tijdperk in door inzet van de Multi-Currency variant

Copyright Viafox

Nu eens geen technisch artikel met veel broncode, maar een stevige lap tekst boordevol begrippen en argumenten die spelen bij de conversie van guldens naar euro’s. Neem er even rustig de tijd voor, laat het allemaal tot je doordringen, worstel met de materie, duik onder en kom boven. Wellicht ga je dan toch nog zonder grote problemen het Euro-tijdperk in.

Inleiding

Applicaties en gegevensbestanden die bedragen bewerken c.q. bevatten zijn in te delen in een van de onderstaande categorieën:

·         Multi-Currency systemen

·         Single-Currency systemen

·         Non-Currency systemen

Een Multi-Currency systeem ondersteunt invoer, opslag en uitvoer van meerdere munteenheden (ook wel valuta’s[1] genoemd). Voor Single-Currency  geldt dat er sprake is van invoer, opslag en uitvoer van slechts één munteenheid. Het begrip Non-Currency doet vermoeden dat er in dat geval sprake is van een applicatie/gegevensbestand zonder bedragen, maar het begrip blijkt te worden gebruikt als bedragen ‘abstract’ worden behandeld en dientengevolge ook niet echt in de appli­catie en het gegevensbestand bij naam en toenaam van de munteenheid worden benoemd.

Andere veel voorkomende termen zijn ‘Mono-Currency’, welke een synoniem is van de term Single-Currency, en ‘Dual Currency’, welke in feite een specifiek geval van Multi-Currency beschrijft.

Voor veel applicaties en gegevensbestanden geldt dat ze als Non-Currency systeem kunnen worden aangemerkt. Ze zijn veelal te vinden bij bedrijven die hun kernactiviteiten binnen de landsgrenzen houden. PR-mensen hanteren ook wel de term ‘guldenbedrijf’, waarmee ze dan impliciet aangeven dat je van hen niet hoeft te verwachten dat er ook in andere valuta’s gehandeld kan worden.

Voor banken en multinationals geldt dat hun systemen in meerderheid Multi-Currency zijn, in het verleden die kant op gedicteerd door de aard van hun core-busi­ness: geldhandel of internationale handel.

Van de Nederlandse banken is bekend dat zij reeds vergevorderd zijn met hun conversie naar de Euro, en de implementatie ervan lijkt bij hen enigszins mee te vallen.[2] Dat strookt goed met mijn ge­voel; Conversie zou bij een Multi-Currency systeem simpeler moeten zijn. Veel meer dan het toevoe­gen van een valutacode aan de valutacodetabel kan het toch niet inhouden?! De praktijk is vast weer­barstiger dan de theorie, maar in essentie is het waar: Een Multi-Currency systeem is makkelijker aan te passen aan de invoering van de Euro dan een Single/Non-Currency systeem.

De afgelopen drie jaren ben ik op freelance-basis werkzaam geweest bij een grote verzekeringsmaatschappij. Deze maatschappij (hoewel onderdeel van een internationale organisatie) profileert zich als guldenbedrijf en dat strookt ook met de structuur van de gegevensbestanden. Non-Currency kenmerkt de gegevens zowel op het mainframe als op het LAN. Multi-Currency is bij de eerste technische sessies over de Euro wel even ter sprake gekomen. Het algemeen bevinden was toen als het ware dat ‘we dat vooral niet moeten willen, want je weet niet waar je aan begint!’. Non-Currency systemen ombouwen naar Multi-Currency werd wellicht be­schouwd als een klus die rigoureuze aanpassingen in het ontwerp, de gegevensstructuur en de pro­grammacode zou vereisen; Een onbegonnen klus. Einde discussie, ander onderwerp.

“We gaan eenmalig converteren”

De taak leek dus duidelijk: We gaan converteren. De bedragen moeten gewoon op zeker moment eenmalig omgerekend worden en daarna gaan we vrolijk verder, maar nu met Euro-bedragen.

Naarmate er meer over werd nagedacht, stuitten de ‘experts’ op meer en meer praktische bezwaren van zo’n aanpak.

Eenmalig converteren behelst dat een applicatie tijdelijk wordt stilgelegd, althans voor de gebruikersgroep, en dat in die fase alle bedragen in alle gegevensbestanden eenmalig met behulp van bestandsconvertors worden omgewerkt naar euro’s. Waarna de gebruikers dan weer vrolijk kunnen doorwerken.

Maar veelal is een applicatie nauw verweven met andere systemen binnen het bedrijf. Die andere systemen leveren cijfers die moeten corresponderen met bepaalde cijfers uit de applicatie. De applicatie behoort dus al snel tot een cluster. Voor eenmalig converteren geldt dat het dan niet meer slechts op de applicatie sec slaat, maar op de cluster, of misschien zelfs wel op de algehele verzameling applicaties en bestanden van het bedrijf.[3] In dat laatste geval spreken we van een Big Bang scenario.

In algemene zin zijn diverse bezwaren tegen vooral een Big Bang ingebracht.

Laten we veronderstellen dat de applicaties in de loop van de tijd min of meer rustig zijn voorbereid op de conversie, dan omvat de Big Bang alleen de conversie van de gegevensbestanden; In korte tijd (bijvoorbeeld een weekend) moet een groep IT-experts dan met de beschikbare computers de conversie in één keer perfect regelen. Een fall-back procedure is eigenlijk geen echte optie, of zal in elk geval als een ‘nederlaag’ worden ervaren. De deadline is hard en meedogenloos. De minste geringste fout kan al de betekenis van een showstopper hebben, dat wil zeggen dat de gehele conversie dan wel moèt worden uitgesteld, ook al vanwege de onderlinge samenhang tussen de gegevensverzamelingen en processen. Dit scenario roept bij menig expert negatieve onderbuikgevoelens op.

Maar ook converteren per cluster kent diverse bezwaren. In een scenario waar met clusters wordt gewerkt, zal erg veel tijd ‘verloren’ gaan aan het bepalen van de clusters, aan het plegen van overleg met degenen die de aanpalende systemen moeten aanpassen, het wachten op anderen die eerst essentiële precondities moeten realiseren en het verrichten van complexe tests waarbij meerdere systemen in de cluster betrokken zijn[4]. Zeker bij grote bedrijven zal men bevinden dat er toch geregeld gegevensuitwisseling is tussen applicaties die in verschillende clusters zijn onderverdeeld.[5] Omdat clusters per definitie niet gelijktijdig ‘om’ gaan, zullen er vele interface-convertors nodig zijn; dat zijn programmaatjes die uitgevoerde gegevens converteren naar het formaat dat het invoerende programma wenst. Op zich is dat niet onoverkomelijk, ware het niet dat hier het GEG-probleem om de hoek komt kijken, misschien van alle problemen wel het vervelendste probleem.

Stel dat de door applicatie A beheerde gegevens al geconverteerd zijn (van G naar E) en dat deze applicatie gegevens moet doorsluizen naar applicatie B welke nog niet euro-gereed is, dan moet de interface-convertor de bedragen terugconverteren naar G. Door het afronden zal het resulterende bedrag soms niet meer gelijk zijn aan het oorspronkelijke bedrag. De overheid verbiedt zulks, of in elk geval wenst deze dat er dan wordt ‘afgerond in het voordeel van de klant’. Populaire gedachte bij menigeen is dan dat maar te doen, maar bij nader inzien blijkt zo’n handelswijze niet de ideale oplossing omdat de afrondingsverschillen ook tot schending van de gegevensintegriteit leiden, welke door die douceurtjes (van laten we zeggen 1-5 cent)  niet bepaald minder ernstig wordt.

Er zijn meer nadelen van eenmalige conversie (en dus ook van Big Bang). Zo zal het moeilijk zijn andersoortig onderhoud te verrichten aan een applicatie tussen het moment van voorbereiden op de conversie en de daadwerkelijke conversie. Het bedrijf zal meer moeite hebben in te spelen op problematiek die specifiek is voor de duale periode, de periode vanaf 1 januari 2002 dat het de mensen toegestaan is te betalen in zowel guldens als euro’s. En het bedrijf zal in de pre-duale periode misschien wel met euro-achtige produkten kunnen komen, maar in de interne administratie zal zo’n euro-achtig produkt dan toch weer in guldens moeten worden genoteerd. Ook het inspelen op externe factoren zal moeilijk blijken. Denk aan de politiek, acties van concurrenten, maatschappelijke spanningen en economische ontwikkelingen.[6]

De brainstorm-sessie

De vele praktische bezwaren van de eenmalige conversie stemden de experts van het bedrijf waar ik werkte niet vrolijk. Uiteindelijk werd er door hen van lieverlee een brainstorm-sessie georganiseerd. Een van de daar geponeerde ideeën ging onder de naam ‘dubbele currency’, niet te verwarren met de term Dual-Currency. De variant houdt in dat het guldenbedrag wordt verhoogd met het equivalente eurobedrag en aldus wordt opgeslagen. Het blijkt technisch mogelijk te zijn uit de opgeslagen waarde (die waarlijk non-currency lijkt) met behulp van een algoritme zowel het gulden- als het eurobedrag weer af te leiden.

Dit zette mij op het spoor van het toevoegen van een rubriek muntindicatie.[7] Bij elkaar horende gegevens staan bij elkaar in een record. Zo’n record bevat mogelijk alle gegevens over bijvoorbeeld een polis. Maar het kan ook zo zijn dat elk record een mutatie op bijvoor­beeld een polis beschrijft. In dat geval zal de polis een groep records omvatten. Die records hoeven dan niet bij elkaar in de buurt te staan, maar ieder record zal toch waarschijnlijk wel het polisnummer als gegeven in een rubriek bevatten. Voor elke rubriek geldt dat deze voldoende ‘ruim’ moet zijn om het gegeven dat erin opgeslagen moet worden te kunnen herbergen. Zo zal de tekst “ABC” een rubriek van minimaal drie posities opeisen. Precies hetzelfde geldt voor bedragen. Een consequentie van de ‘dubbele currency’ variant is dat de gereserveerde ruimte voor de rubriek met één positie moet worden uitgebreid, gezien de waarde van de Euro: 2,20371. In een record treffen we mogelijk meerdere be­drag­rubrieken aan. Bij een bestandsstructuuraanpassing zullen dientengevolge meerder rubrieken moeten worden aangepast. Mijn gedachte was: Waarom zou je niet gewoon volstaan met het toevoe­gen van één rubriek van één positie, waarin je informatie opslaat over de aard van de bedragen in dat record? Deze rubriek (muntindicatie) maakt het vervolgens onnodig om het eurobedrag op te tellen bij het guldenbedrag. Meer zelfs, van dubbele currency ga je in een klap naar multi-currency! Via een omweg was Multi-Currency weer in beeld gekomen. Maar nu betrof het een rudimentaire vorm, welke mogelijk geen rigoureuze aanpassingen in het ontwerp, de gegevensstructuur en de programmacode vereist.

Problemen en mogelijkheden bij de Multi-Currency variant

De vraag was nu: Stel dat we op record-niveau de valuta van de erin voorkomende bedragen kunnen achterhalen, welke problemen hebben we dan niet meer, en welke problemen hebben we dan juist wel? Maar de vraag kon ook anders gesteld worden: Welke mogelijkheden hebben we dan niet meer, en welke juist wel?

Er kwamen diverse gedachten bij me op, welke soms elkaar gedeeltelijk overlappen, maar hieronder ieder toch apart genoemd worden.

1.        De eerste gedachte die bij me opkwam was dat de reeds aanwezige guldenbedragen dan juist niet initieel hoeven te worden geconverteerd! Ook opent het de mogelijkheid aan de invoerzijde zonder conversiemechanisme zowel gulden- als eurobedragen te accepteren, zolang het maar binnen het record om een enkele munteenheid gaat! En zelfs andere munteenheden en omrekenkoersen zouden er door ondersteund kunnen worden. Dit lijken mij allemaal voordelen.

2.        De tweede gedachte was dat aan de invoerzijde, maar vooral ook aan de uitvoerzijde (tezamen ook wel presentatielaag genoemd) de mogelijkheid moet/kan worden geschapen te kiezen voor in­voer c.q. uitvoer in gulden òf euro. Dit kan worden gezien als een nadeel (denk aan implementatiekosten), maar net zo goed als een voordeel. Het bedrijf kan dan reeds vanaf het moment dat de relevante applicaties ‘om’ zijn, de klant zelf de keuze tussen euro en gulden laten. Idem kan het bedrijf dan zelf bepalen tot welk moment het een klant toestaat in gulden te communiceren. Commercieel is er opeens van alles mogelijk wat zonder Multi-Currency niet kan.

3.        De derde gedachte was dat je bij toepassing van deze variant er niet onderuit komt zekere aan­passingen in het ontwerp en de programmacode aan te brengen omdat de aard van de bedragen voortaan per record kan en zal verschillen. Een nadeel vanuit het oogpunt van degenen die moe­ten letten op de kosten en het afbreukrisico. Maar tegelijkertijd: Die aanpassingen zouden weleens erg kunnen meevallen. In de Non-Currency situatie gaat het ontwerp en de programmacode (van een applicatie) ervan uit dat alle rubrieken in alle records eenzelfde munteenheid betreffen. In de Multi-Currency situatie is dit uitgangspunt onwaar. De implicatie is dat elk  proces dat bedragen ‘ophaalt’ uit rubrieken daarbij voortaan een gebruiksconvertor moet hanteren. Een gebruikscon­vertor is een kleine routine die een bedrag omrekent, hier op grond van de muntindicatie, ten be­hoeve van het actuele gebruik. Het geconverteerde bedrag wordt dus niet opgeslagen in de ru­briek. Bij vervolgberekeningen is zo’n convertor niet nodig. Het gaat er dus om dat in de program­macode van applicaties de plekken worden gelokaliseerd waar bedragen initieel worden opge­haald en dat op die plekken de gebruiksconvertors worden aangebracht. De vraag was of dit een doenlijke klus is. Mijn eigen onderzoek viel positief uit: Het bleek zeer doenlijk. Daarbij moet ik stellen dat ik in een PC-omgeving werk met FoxPro. Hoe het ligt bij mainframe-applicaties, Delphi, Clipper, Visual Objects en andere omgevingen moet door anderen uitgezocht worden.

4.        Een vierde gedachte was dat zulke gebruiksconvertors kunnen zorgen voor een gigantische tot geringe achteruitgang van de ‘performance’. Een nadeel. Bij mijn eigen tests bleek dat erg mee te vallen.[8]

5.        Een vijfde gedachte was dat recht-toe-recht-aan ‘bladeren’ door de records, veelal buiten een applicatie om, de last van het omrekenen bij de ‘bladeraar’ zal leggen. Een nadeel.

6.        De zesde gedachte was dat er geen interface-convertors (convertors tussen applicaties) meer nodig zijn. Een voordeel. In de kern van de zaak zit ‘m de pijn van de euroconversie namelijk bij de gegevensoverdracht. Want zolang een onderhoudsteam zich beperkt tot conversie van de applicatie waarvoor dit onder­houdsteam ‘verantwoordelijk’ wordt gehouden, is er, wat het onderhoudsteam betreft, niet veel aan de hand. Het begint pas echt ‘au’ te doen op het moment dat zo’n applicatie gegevens aan een andere applicatie moet leveren en die applicatie nog niet euro-gereed is; we krijgen dan te maken met het kwalijke GEG-probleem. En zoals een onderhoudsteam zich binnen het bedrijf qua blikveld zou kunnen beperken tot het aanpakken van de eigen applicatie, zo zou het bedrijf zich ook qua blikveld kunnen beperken tot het aanpakken van de eigen applicaties. En zoals een onderhoudsteam opeens ‘au’ voelt dra het moet interacteren met applicaties van anderen, zo zal het bedrijf opeens ‘au’ voelen dra het door de ‘buitenwereld’ gedwongen wordt bepaalde invoer te accepteren en bepaalde uitvoer te leveren. Toepassing van de Multi-Currency variant biedt hier wellicht uitkomst! De klant zegt het maar. Voor applicaties binnen het bedrijf geldt dat deze elkaar de gegevens rauw (ongeconverteerd) sturen, maar dan inclusief de muntindicatie. De ontvangende applicatie hoeft de gegevens ook slechts op te slaan zoals deze aangeleverd werden. Klaar.

7.        De zevende gedachte is dat fysieke conversie op record-niveau pas nodig is op het moment dat minstens een van de bedragen erin een mutatie naar euro moèt ondergaan. Zo’n situatie doet zich bijvoorbeeld voor als een klant een polis wil omzetten van gulden naar euro. In dat geval dienen alle bij deze polis betrokken records te worden opgezocht teneinde ieder een recordconversie[9] te laten ondergaan. Alle bedragen in het record worden omgerekend en fysiek vastgelegd in de ru­brieken. De muntindicatie wordt uiteraard eveneens bijgewerkt. Deze recordconversie zal boven­dien moeten plaatsvinden vòòrdat de mutatie wordt doorgevoerd. Vanuit het oogpunt van de bud­getbewaker lijkt dit een nadeel. Daar staat tegenover dat conversie geen groot beslag legt op de ‘resources’, juist omdat het steeds om kleine hoeveelheden gaat en heel geleidelijk geschiedt in de loop van de tijd.

Overige noties

De Multi-Currency variant heeft de potentie om bedrijfsbreed te worden ingezet en werkt dan ook veruit het best. Het zou kunnen zijn dat incidenteel een ander conversieprincipe handiger blijkt te zijn. De Multi-Currency variant hoeft daarmee niet strijdig te zijn.

Wanneer we praten over de Multi-Currency variant moeten we verschil maken tussen conversie en conversie. Hierboven is er al aan gerefereerd, hier wordt het nogmaals expliciet door mij genoemd, omdat er zo snel verwarring kan ontstaan als het onderscheid niet steeds duidelijk gemaakt wordt. Er is, wat we momenteel noemen, bestandsconversie (waaronder begrepen recordconversie) en er is gebruiksconversie. Die laatste vorm wordt slechts gebruikt voor rapportage e.d. en leidt niet tot fysieke wijzigingen in het bestand. Voor bestandsconversie geldt dat deze bij dit model in principe alleen hoeft plaats te vinden op record-niveau dra een bedrag in zo’n record voortaan in euro moet.

De Multi-Currency variant opent de mogelijkheid in een bepaald stadium resterende guldenposten geforceerd over te zetten naar euro. Het gaat dan bijvoorbeeld om polissen die niet op aangeven van de klant al omgezet zijn naar euro, maar wel naar euro om moeten omdat het bedrijf dat als beleid hanteert. Zo’n scenario zal zich mogelijkerwijze afspelen in de post-duale periode, de periode dat bedrijven niet langer met guldenbedragen hoeven te werken, c.q. te presenteren. Overigens doet zo’n conversie eigenlijk afbreuk aan het principe van multi currency.

Geforceerde bestandsconversie mag zeker niet plaatsvinden zolang bepaalde rapporten, overzichten, e.d. die ervan afhankelijk zijn nog in guldens moeten. Uitgangspunt moet steeds zijn: Hoe vermijd ik GEG?

Er bestaat een zekere ideale volgorde waarin applicaties en gegevensbestanden Multi-Currency wor­den gemaakt. Hiervoor is de enigszins kunstmatige driedeling invoerlaag, uitvoerlaag en middenlaag nodig. De invoerlaag omvat de applicaties en gegevensbestanden die sterk met de invoer verwant zijn. Denk aan importbestanden en invoerschermen. Idem is de uitvoerlaag verwant met uitvoer, zoals facturen en rapporten. In de middenlaag vinden we applicaties en gegevensbestanden die enerzijds gevoed worden uit de invoerlaag of meer ‘intern’ bepaald worden, en anderzijds gegevens doorspelen aan de uitvoerlaag. Idealiter pakt men eerst de middenlaag aan, vervolgens de invoerlaag en als laatste de uitvoerlaag. Deze aanpak impliceert dat redelijk vroeg reeds invoer in euro’s kan worden geaccepteerd. Zolang aan de uitvoerzijde het werk nog niet af is, zal uitvoer in guldens moeten worden gedaan. De klant zal ervan op de hoogte moeten zijn dat in die overgangsfase afrondingsverschillen zullen ontstaan ten gevolge van het terugconverteren. Rapportage zal een informatief karakter moeten krijgen. Rechten zijn er niet aan te ontlenen. In die bouwfase zal invoer in euro’s dus hooguit een ser­vice kunnen zijn en zal de klant het nadeel van terugconverteren moeten accepteren.

Overig onderhoud aan applicaties kan in principe gewoon doorgang vinden.

Het testen van programmacode-aanpassingen is veel simpeler dan het testen van een massale be­standsconversie! Het belang van dit punt wordt al snel onderschat.

Gebruiksconvertors hoeven niet in de post-duale periode te worden verwijderd. Sterker zelfs, ze blij­ven van essentieel belang als marketeers op zeker moment besluiten van het Multi-Currency aspect welbewust gebruik te gaan maken. Dat lijkt een non-argument in een tijd dat in Europa allerlei munteenheden worden afgeschaft, maar toch...

Er kan onderscheid worden gemaakt tussen horizontale processen en verticale processen. Of een proces horizontaal is of juist verticaal is afhankelijk van de ‘positie’ die je kiest. Als voorbeeld nemen we een proces dat alle records van een polis gebruikt, bijvoorbeeld om de polisgegevens op het scherm te tonen. Dat is veelal een verticaal proces als we positie kiezen op record-niveau, maar het is een horizontaal proces als we positie kiezen op polis-niveau. Bij een verticaal proces is er dus sprake van grensoverschrijding, bij een horizontaal proces juist niet. Voor een horizontaal proces geldt dat dit proces geen gebruiksconvertors behoeft op voorwaarde dat alle bedragen binnen dat niveau dezelfde munteenheid betreffen! Voor een verticaal proces geldt dat geen gebruiksconvertors nodig zijn als alle bedragen ook over de grenzen heen dezelfde munteenheid betreffen! Die laatste situatie is veel moei­lijker te realiseren en moet in extenso zelfs juist worden voorkomen. We zullen de gebruiksconvertors dus zeker bij de verticale processen moeten gaan aanbrengen. Bij de horizontale processen wordt nu vaak niet gerept over de munteenheid. Dat is niet langer adekwaat, dus zal ook daar een (kleine) aanpassing in het functioneel ontwerp en de programmacode moeten worden aangebracht.

Bij de Multi-Currency variant is er niet langer, of in elk geval veel minder, sprake van het GEG-pro­bleem. Er blijft echter sprake van afrondingsverschillen ten gevolge van GE, de conversie van gulden naar euro. Over die afronding wil ik het volgende zeggen. De overheid lijkt te willen dat een euro-totaalbedrag de conversie is van het originele gulden-totaalbedrag. Dus als je een kassabon hebt, dan mag op de euro-kassabon het totaalbedrag niet zomaar een sommering van de in euro vermelde detailbedragen zijn. Nee, het moet de converse zijn van het originele gulden-totaal. Wanneer we conversie op deze wijze moeten gaan implementeren, betekent het een ondermijning van vele algoritmes in de applica­ties. Daarmee is de gegevens-integriteit van de bedrijfsadministratie in het geding. Die integriteit kan alleen maar worden gewaarborgd door te eisen dat totaalbedragen worden gebaseerd op de de­tailbedragen, conform het originele algoritme! Bovendien stel ik nadrukkelijk dat elk geconverteerd tussenbedrag (al of niet getoond) eenzelfde aantal decimalen moet bevatten als het originele tussenbe­drag! Dit probleem staat redelijk los van de Multi-Currency variant, maar wordt hier toch genoemd om­dat niet voldoen aan deze eisen roet in het eten kan gooien en sommigen wellicht zou kunnen verlei­den tot het geven van de schuld aan de variant als er inderdaad gegevensvervuiling ontstaat.[10]

Het volgende hangt met het bovenstaande samen: De overheid staat een afrondingsverschil van één eurocent toe. Dat is geen probleem voor bedragen die al in centen werden uitgedrukt. De eis kan echter niet worden ingewilligd voor bedragen die in hele guldens, of zelfs in duizendjes, worden uitge­drukt. Bij zulke bedragen gaat het in feite om de expliciete of stilzwijgende afspraak dat er in gul­dens/duizendjes wordt gecommuniceerd. Dat principe moet worden bewaakt, op straffe van, ook hier weer, gegevensvervuiling en dus bedreiging van de integriteit van de administratie. Consequentie is dat de overheid bij hele-euro overzichten (rapportage, facturen, etc.) een afrondingsverschil van één euro zal moeten tolereren en bij duizendjes-overzichten zelfs een afrondingsverschil van duizend euro! Wanneer dit onacceptabel worden bevonden (door de overheid of misschien zelfs wel door het bedrijf zelf), dan zal iedere applicatie waar dit probleem speelt moeten worden herzien vanaf het niveau van het functioneel ontwerp! Er wordt dan immers een nieuwe afspraak over de mate van afronding gemaakt. Veelal zal dit neerkomen op uitbreiding van het aantal decimalen in de gegevensbestanden en aanpassing van de algoritmes, zodat deze van die extra decimalen gebruik maken. Uiteraard heeft dat dan ook gevolgen voor de presentatielaag; Extra decimalen impliceren extra kolommen en daarom zal de lay-out veelal fiks herzien moeten worden, zeker als er al ruimtegebrek was op scherm of papier. Al met al per applicatie een fikse aanpassing.[11]

Een apart te noemen complicatie vormen de '1 gulden' bedragen in rubrieken zonder decimalen. Daar waar in een bedragveld de waarde 1 of -1 staat, zal na een ordinaire conversie van het veld de waarde 0 staan, juist omdat er wordt afgerond op integers. Ik noem dit een underflow situatie: Er is sprake van een bedrag, maar het formaat van het veld is te 'grof' om de waarde op te slaan waardoor het bedrag niet langer te detecteren is. Dat leidt tot een complicatie als er in de functionele ontwerpen en/of de programmatuur wordt gesteld dat een nulwaarde iets anders betekent dan een niet-nulwaarde.

Tijdens experimenten stuitte ik op een verschijnsel dat mijn argwaan tegen het ordinair converteren nog verder deed toenemen. Soms wil je blanco waarden (in FoxPro aangeduid met .NULL.) uitsluiten van een query. Na een ordinaire conversie zal een lege numerieke rubriek echter niet langer ‘blanco’ zijn, maar 0. Daardoor zal het gebeuren dat zulke rubrieken opeens toch in de query een rol gaan spelen. In voorbeeld A gaat het goed, in voorbeeld B opeens niet meer. Aan het probleem is wat te doen door zulke blanco waarden reeds vooraf uit te sluiten en niet achteraf. Voorbeeld C laat dat zien. (De functie isblank() wordt door FoxPro niet ondersteund in een Select-SQL statement.)

 

* Voorbeeld A

select ;

   insp, ;

   amount ;

   from dvd_insp

*

set filter to not isblank( amount )

 

*  Voorbeeld B

select ;

   insp, 

   ConvCurrency( amount, valutacode ) as amount ;

   from dvd_insp

*

set filter to not isblank( amount )

 

*  Voorbeeld C

*  Veld MARK is een hulpveld voor de programmeur.

select dvd_insp

replace all mark with iif( isblank( amount ), ‘-‘, ‘+’ )

select ;

   insp, ;

   ConvCurrency( amount, valutacode ) as amount ;

   from dvd_insp ;

   where mark = ‘+’

Het GEG-probleem nader bekeken

Velen blijken enige moeite te hebben met het nadenken over de vele complicaties van het GEG-probleem. Hieronder probeer ik een schrijfwijze te introduceren die bij dat (gezamenlijk) nadenken kan helpen.

Uitgangspunt moet steeds zijn: Hoe vermijd ik GEG? Bijgedachte is dan dat GE toegestaan is, als­mede GE(G) waarbij de haken dan aanduiden dat de uitvoer (in gulden) een service betreft waaraan geen rechten ontleend kunnen worden.

Uit het volgende schema blijkt dat in de pre-duale fase de invoer en uitvoer in gulden zijn, dat in de duale fase klanten mogen komen met gulden of euro, maar het bedrijf alleen presenteren wil in euro. In de post-duale fase is het bedrijf dan helemaal euro, dus ook bij de in­voer.

 

 

Pre-duaal

Duaal

Post-duaal

Invoer

G

G/E

E

Uitvoer

G

E

E

 

Als de Multi-Currency variant slim wordt uitgevoerd, kan er meer dan vorenstaande worden gereali­seerd. In het volgende schema staat steeds tussen haakjes aangegeven wat dan ook mogelijk is, maar dan bij wijze van service. 'Service' omdat er geen rechten aan kunnen worden ontleend. De vierkante haken geven aan dat deze service in de loop van de periode beschikbaar komt, de ronde haken geven aan dat de service in de gehele periode geboden kan worden.

 

Pre-duaal

Duaal

Post-duaal

Invoer

G/[E]

G/E

E/(G)

Uitvoer

G/[E]

E/(G)

E/(G)

 

Deze schematisering staat meer geavanceerde schetsen toe. In onderstaand schema is ook plaats ingeruimd voor de opslagvorm en de invloed van tabellen met grensbedragen e.d.

 

 

Pre-duaal

Duaal

Post-duaal

Invoer

G/[E]

G/E

E/(G)

Opslag

g/[e]

g/e

e/(g)

Tabellen

g/[e]

e/(g)

e/(g)

Uitvoer

G/[E]

E/(G)

E/(G)

 

De ‘flow’ van een bedrag kan dan ook op een andere manier inzichtelijk worden gemaakt. Enige voor­beelden staan hieronder.

Gg [e][E]           [E]g g[E]            Gg e(G)          EeeE

De eerste lettersequentie kan als volgt worden gelezen: Er is invoer in guldens, de opslag is in gul­dens en er is uitvoer in euro’s waarbij gebruik wordt gemaakt van in euro’s gestelde tabellen. Verder blijkt er uit dat het service-uitvoer betreft die in de loop van de periode beschikbaar komt of is gekomen, namelijk zodra de tabellen en uitvoerprogramma’s er voor zijn/waren aangepast.

 


[1] Eén valuta, twee valuta’s.

[2] Dit artikel werd bij de redactie ingeleverd op 4 januari, de eerste dag dat de beurzen in Euro’s handelden. Volgens de media waren er nog niet of nauwelijks problemen gerezen. Maar uit eigen bron weet ik dat bij een kleine bank de conversie was mislukt en er snel teruggegrepen moest worden op de originele data.

[3] Eigenlijk is het een macroprobleem waarbij alle inwoners en bedrijven van de EMU betrokken zijn.

[4] Laat ik geregeld bezoek van dhr. Murphy hier maar niet noemen, want die zal bij elk scenario wel langskomen.

[5] Zou men hoe dan ook zoiets willen voorkomen, dan blijkt men al snel één cluster te definiëren en daarmee het Big Bang scenario van stal te halen.

[6] Wie durft te beweren dat de euro er over 10 jaar nog steeds is?! Commentatoren wijzen in de media geregeld op het merkwaardige, smalle draagvlak dat de euro eigenlijk heeft. Zij zien Europa niet snel één natie worden, gezien de grote verscheidenheid aan culturen en talen, en denken dat daarmee de euro een solide basis mist.

[7] Gegevens staan in gegevensbestanden in rubrieken, ofwel velden. In dit kader zijn dat synoniemen. De term ‘rubriek’ zal hier verder gebruikt worden.

[8] Sterker zelfs, ik kon geen achteruitgang in de performance meten. Hiermee wil ik niet beweren dat het een non-issue is. Ik verwacht in de nodige gevallen wel degelijk een verslechterde performance.

[9] Recordconversie is een speciale vorm van bestandsconversie: Er wordt een record van een bestand geconverteerd.

[10] Via de website van het Euro-Platform (http://www.euro.nl) heb ik een aantal weken geleden reeds via e-mail opheldering hierover gevraagd. Echt op de valreep, vlak voor de deadline, kwam er dan toch nog een reactie per e-mail van een medewerker van de Eurosite:

“Veel bedrijven hebben te maken met sommaties van bedragen, bijvoorbeeld bij factureren. In de optelreeks kan, bij omzetting van gulden naar euro en v.v. een fout ontstaan. De som van de omgerekende bedragen is dan ongelijk aan het omgerekende totaal van de oorspronkelijke bedragen. Dit is geen probleem wanneer een bedrijf de factuur volledig in euro opstelt (dus het totaalbedrag in euro). Er ontstaat een probleem wanneer een bedrijf ter gewenning de volledige factuur wil weergeven in twee valuta’s. De optelsom van de afgeronde eurobedragen is dan ongelijk aan de optelsom van de guldensbedragen. Het is belangrijk dat het eindbedrag (dat betaald of geboekt moet worden) in elk geval juist wordt omgezet in euro c.q. gulden. Dit heeft voorrang boven de juistheid van de optelsom in euro c.q. gulden. Het op een factuur door elkaar gebruiken van guldens en euro's is niet toegestaan. Voor meer informatie zie: pag.11 van de nota omrekening en afronding. Deze is te bestellen (e-mail of Eurolijn 0800 -1521) of te downloaden van de Eurosite (www.euro.nl: Servicebalie, downloads). Wij raden u hiernaast aan het document ‘Preparing financial information systems for the euro’ van de Europese Commissie van de Eurosite te downloaden.”

[11] Uit onderstaande reacties van het ministerie van financien blijkt dat rapportage die in hele guldens (of bijvoorbeeld duizendtallen) was, ook in de nieuwe situatie in die hele munteenheden (dan dus euro’s) mag worden verricht. Dat is dus gunstig!

Woordvoerder: “Als men in interne rapportages gewoon is gebruik te maken van hele getallen is er niets veranderd wat dat zou verbieden.”

Ik: Dank voor uw, naar mijn idee gunstige, reactie. Toch nog een restvraag. U spreekt over 'interne' rapportages. Mag ik aannemen dat het principe ook geldt voor anderssoortige rapportage of zelfs desnoods nota's, facturen, e.d. waar met de andere partij expliciet of impliciet is afgesproken dat er afgerond wordt op hele guldens of misschien zelfs duizend gulden?

Woordvoerder: “Als dit is overeengekomen tussen beide partijen … zijn er geen bezwaren.”

Home