HRK2EUR – Necessary updates for data and application layers

Croatia is replacing the national currency Kuna with Euro from the 1st of January 2023 at midnight. All Croatian IT systems and applications that store and calculate amounts in Kuna will have to ensure end-users ability to view the amounts in both currencies, Kuna and Euro, in parallel. This feature needs to be implemented six months before the deadline (1.1.2023.) and must remain active at least twelve months after the deadline. We wrote about this in one of the previous articles. But this is not the only change.  

Since design, development and maintenance of enterprise IT systems are our core businesses, right after the announcement of replacing Kuna with Euro, we organized a special task force to help our clients in the transition to the new currency. Our analysis showed the systems updates will be necessary for both data and application layers, so we’ll observe these two perspectives closely.    

Opportunity to modernize a “few” applications

Application layers will most likely need major updates in organizations and businesses that rely on internally or externally developed custom information systems. These systems probably don’t support multiple base currencies and/or conversion of existing financial data to a new currency. The chances are that organizations using “Off the shelf” business system software (Oracle ERP, SAP, etc.) already have some functionalities within the software solution that enable the switch of base currencies in the system. 

Since CROZ specializes in the development of custom-made software as well as integration, here are examples of two use cases we easily identified. 

Currency information in internal data structures

One of our customers has an existing custom-made system with implicitly defined currency in both internal and external (public API) data structures. For example, total charges are shown as integer numbers, but information that this number shows charges in HRK is implicit. In this case, the customer decided to introduce currency information in internal data structures while public API will remain unchanged. The cutover date for moving all financial values to Euro will be implicit.  

This way, most of the migration complexity will be handled internally within the system without significant impact on the customer. Since the exchange rate will be fixed, the customer will be able to introduce the necessary dual currency display in the system.  

For internal data structures, the customer decided to go through with a more complex solution that will extend data structures with support for multiple currencies. This is predominantly required to facilitate easy comparison between data from the HRK era with data from the new EUR era. 

Presentation layer solution or not?

Other customers chose the presentation layer solution to comply with dual currency display regulation. They will do a clean cutover to Euro since the 1st of January is a convenient date to do so from a business point of view. 

We also have customers who have application systems with business logic dependence on currency type. These applications have special rules for both EUR and HRK. There is a need for complete analysis and change of application logic. Our experience showed lots of applications have at least a portion of their logic tied explicitly to HRK and will need to be updated.  

From a technological standpoint, many systems that will change may be developed on obsolete and no longer supported technological platforms. Usually, these systems also support the core business capabilities and produce ever-increasing technical debt in an organization. We recommend using this disruptive period of HRK to EUR migration to enable future initiatives to pay off this debt.  

We suggested few options two years ago when this regulatory change wasn’t a hot topic, so maybe this could be a last “subtle” call to strangle few beasts.

Data change introduces quality and consistency

From the customers’ perspective, the introduction of the euro shouldn’t affect existing habits and without the need for additional training or the introduction of new software solutions. 

The introduction of a new currency and implementation is visible to the end-user on the presentation layer of various application solutions (web applications, customized software solutions, mobile applications, etc.). If during the analysis of the euro introduction into circulation and the collection of preconditions for implementation we descend to the data layer of software solutions, we come to situations that open new questions for us.

For example, was it necessary to customize the data layer by adding new attributes? Or how to process the data entered so far for the amounts in HRK? There is no single answer, so the method of implementation relies on a business requirement. 

In transactional systems, modifications are possible only at the presentation layer without changes to the data model. Here, we identified shortcomings where the display of data and calculations is burdened with the logic of recalculation and verification for each retrieval. Additionally, the user must be aware of the cut-over – the date of transition to a new currency, which will be forgotten over the years. For example, does anyone remember the date of the introduction of the OIB*? 

The need of historical data

Knowing that, organizations are increasingly relying on data for business analysis and business intelligence purposes. Data quality and consistency are necessary for the new currency implementation, the data layer changes, and the new attributes which describe the amounts. This way, records with values ​​before and after the introduction of the euro are separated. Still, we have to solve the challenge of comparing data in analyses. The solution we came up with is adding new attributes and recalculating the historical amount of data at a fixed exchange rate that will be defined before entering the eurozone. 

Also, in addition to business analysis, data is stored and prepared for a series of regulatory reports in which the legislator clearly states the method of data delivery, the currency, and the period. 

This change, in which the data structure is adapted and the data is updated, has advantages in analytical BI systems, data warehouses and other systems that need historical data. This process is demanding from the preparation perspective, new columns and initial data recalculation, and adjustment of the presentation layer (applications, reports, data exchanges). 

Takes longer than expected!

In the analysis, we concluded that the preparation time of the transaction system does not correlate with the changes in the data warehouses. Adjusting the data warehouse requires much more time because it integrates data from multiple source systems, recalculates data, and does the initial conversion.  

We can conclude that now is the last minute to start with the necessary activities to match the changes from data and application perspectives. We’ll be happy to share more of our team’s experience that is already participating in these types of projects to accelerate your HRK2EUR challenging journey. Don’t forget, drivers for a positive change can be different and regulatory compliance doesn’t necessarily have to be another “boring” burden, yet an opportunity to improve significantly. 

*OIB was introduced on January 1, 2009.