Euro Introduction From the Perspective of a Developer

As we all already know, or we have heard something about it, from January 1, 2023 Croatia is joining euro area, the Croatian kuna goes into oblivion and the famous euro comes to us as a 'new' means of payment. And now it may not sound like something big since, frankly, a lot of us have been using the euro for a long time in various conversions, payments and other financial combinations, so the introduction of the euro was probably only a matter of time.

Many of us are already calculating and recalculating how much their 'new' salary will be, dual display of prices in stores is already mandatory in order to get used to what is coming, and just like a large number of other developers working in financial institutions, I've also been working on the conversion for months and struggling with processing, displaying and other things that until now were part of the 'world of kuna'.

One of those struggles, so to speak, is hardcoding, so I will base this short text on what it means to hardcode something and how good or bad it is when a project like this comes up, a project that requires going through the entire database and switching everything from one operation mode to another, in our case from kuna to euro.

Let's just take one example from the sea of programs in one bank where a bunch of codes were written just to finish something faster, in such a way that '191' is set for the kuna currency as a value and not as a parameter. The programs for overdue interest in their modules have this value, for accrued interest have its own, for various account inquiries its own, etc., and now we have come to the point that all should be changed to euro, i.e., '978' and, what is even more important, when after changing everything, you need to check its functionality, you need to go through a huge amount of code that requires to be corrected and adapted to the new 'EUR' system.

For example, if we take one module, let it be a package in which we need to set the currency '191' in various places in different queries or controls in the code itself:

Select  *  from Accounts
Where currency = ' 191 '
----------
IF i_currency  ! =  ' 191 '  THEN
    i_ASSET_CLASS  : =  'Foreign exchange' ;
ELSE
    I_ASSET_CLASS  : =  'Kuna' ;
END IF;
----------
data.account  : =  acount.account_id
data.rn  : =  client.rn
data.currency  : = ' 191 '

1_balance  : =  return_balance (data.account,  data.rn,   data.currency) ;

And now we have way too many such modules on different instances with different users, meaning that we have to change, control, test and check it in a large number of places. If everything had been set as a parameter at the start, the change would be necessary only in one place, namely in the parameter table.

We have a code table with all important fields, in our case for a bank, so we will have a table called BANK, and the fields inside the table are sort code, pin, and one of the fields also important for this story, domestic currency:

bank. domestic_currency   : =   ' 191 ' ;

Let's put together a function that will return that field to us, e.g., return_domestic_cur. In that case in our module where we had the currency '191' in n places, we simply define the global variable g_domestic and fill it with our function, so each change of the domestic currency is then controlled by changing the field in the parameter table, and not, as is the case now, by going through each module and manually changing and correcting everything in n number of places.

g_domestic  varchar2 (3)  : = return_domestic_cur ;
Select  *  from Accounts
Where currency = 'g_domestic
----------
IF i_currency  ! =  ' 191 '  THEN
    i_ASSET_CLASS  : =  g_domestic ;
ELSE
    I_ASSET_CLASS  : =  g_domestic ;
END IF;
----------
data.account  : =  acount.account_id
data.rn  : =  client.rn
data.currency  : = 'g_domestic

1_balance  : =  return_balance (data.account,  data.rn,   data.currency) ;

As we could see from this one short example, conversion to EUR in the developer world can be quite simple and very complex and complicated at the same time. On the one hand, the solution itself is essentially quite simple, and on the other hand, it is complicated because the same solution now needs to be integrated into a large number of modules.

Since I have learned in my long career many things the 'hard' way (you do something one way and then later you have more work to correct it than you would have if you had done it right at the start) I will take the opportunity to state, as a reminder to myself and everyone engaged in this work, that in situations like this we should use parameterization and parameter tables wherever possible and as much as possible.

In the end, I would just like to say that I hope that you could get an impression of the size of this project from this small example, because dehardcoding is only a part of a much bigger story called the introduction of the euro (imagining and writing all the scenarios, creating new modules, a lot of testing, etc.) and that from a developer's perspective I sincerely believe that the whole story will be completed on time and with success.