The infamous 1st January 2023 has come and gone. Croatia, as an equal EU member, officially became a member of the monetary union. Prices of energy products, utilities, everyday groceries have increased, fallen, remained the same; some were justified, some certainly not, but it is what it is. We are now part of this new world and there is no going back.
And while we are all getting used to this new life, the ‘new old’ currency, or the new normal, as some people called the recent period related to some other things that I will not be mentioning now, I would like to give a brief developer's description of how I saw all this in a small part (what was done, what could have been done additionally) as a direct participant in the entire conversion within a financial institution in which the EUR was an enormous project.
In my last blog, I wrote about hardcoding and its problems when it comes to one such project, so in part I would like to now take a look at how it went, how it is now, and what problems remained with the change of the ‘domestic’ currency.
When all is said and done, I have to say that the effort paid off and the whole conversion went great. There were some minor post-production problems and certain setbacks that remained to be solved, but nothing worth mentioning. All in a day's work, I'd say. In this short blog, I would like to focus specifically on what was left for me and what I believe could have been resolved differently in the period before the conversion itself.
Take, for example, the various lists and reports generated on a daily, weekly, or monthly basis. A large number of them were made at a time when a change of domestic currency was not considered, so when the moment came to change one domestic currency to another, we arrived at a problem where we specifically had a fixed date of transition (in our case, 1st January 2023), and the reporting system was arranged to work in a date after the New Year for the period before the New Year (new, corrected versions of the program were transferred) and if this is not done well, we get a kind of hybrid of everything, where we have, as is the case here, mixed euro and kuna.
If we just look at this small example, we see where the patch was made, so select returns after the New Year (in the corrected version of the program) everything that does not include the secondary currency, in our case 191, and that is OK for us. But if we spin the same for data before the New Year, we will not get correct results because we need kuna there, and we will not get it with this method.
c_dom_curr CONSTANT VARCHAR2(3) := mat_data.return_currency('dom_curr'); -- 978
c_sec_curr CONSTANT VARCHAR2(3) := mat_data.revert_currency ('sec_curr'); -- 191
i_date DATE := to_date('31.12.2022','dd.mm.yyyy');
Select p.account,
s.balance,
CASE
WHEN NVL(s.AMOUNT_DEBT_CURR,0) = 0 THEN 0
WHEN p.CURRENCY_ID = c_dom_curr THEN s.AMOUNT_DEBT_CURR
ELSE ROUND(return_amount_exchange rate,2)
END AMOUNT_DEBT_DOM
from traffic p, balances s
Where p.account = s.account
And p.date_accounting between trunc(i_date,'MM') and i_date
And p.currency != c_sec_curr;
But if we write it so as to distinguish the currency from its dependency on the date, we will get the result we need and we simply no longer depend on when a currency was active, when it was not, and for what date we do the processing and reports.
c_dom_curr CONSTANT VARCHAR2(3) := mat_data.return_currency('dom_curr'); -- 978
c_sec_curr CONSTANT VARCHAR2(3) := mat_data.revert_currency ('sec_curr'); -- 191
i_date DATE := to_date('31.12.2022','dd.mm.yyyy');
Select p.account,
s.balance,
CASE
WHEN NVL(s.AMOUNT_DEBT_CURR,0) = 0 THEN 0
WHEN p.CURRENCY_ID = c_dom_curr THEN s.AMOUNT_DEBT_CURR
ELSE ROUND(return_amount_exchange rate,2)
END AMOUNT_DEBT_DOM
from traffic p, balances s
Where p.account = s.account
And p.date_accounting between trunc(i_date,'MM') and i_date
And s.currency_id = Case When s.date_accounting <= date Then c_sec_curr
Else c_dom_curr
End;
Now, you could say that hindsight is 20/20, because when the program was initially running and the patches were made, maybe this situation could not have been predicted. But this brief example shows how mistakes can easily be made even on seemingly small things and you can create unnecessary additional jobs for yourselves that can end up costing a lot more than it would have originally cost if the situation had been viewed from ‘out of the box’, if the situation was viewed from several angles and a thing wasn't done just to do it.
I must admit that such small examples and similar ones are always a reminder of a saying that I consider to be quite good and accurate in the work I do.
A good developer, in my humble opinion, is not one who works every day just to work. A good developer is one who does something and forgets that they did it because they no longer need to change and update one and the same code every day. Do what you have to do with quality and move on to the next job / project because patches, one-time scripts, and other things will never do you any good in the long run.
