Within a multi-national enterprise there will always be many different fiscal calendars. Each country has its own local government tax reporting obligations that is driven by local laws. When these laws change, so does the corresponding fiscal calendar in every registered company.
At a minimum, the posted transaction data for last year and all future years will need to re-align the fiscal year and probably incorporate a shortened fiscal year in the cutover solution. This can happen when:
- A company is bought that has different reporting practices;
- A country like Italy moves the fiscal year end from 5th April to 31st December.
There will always be a need to do local fiscal reports (Balance Sheet, Profit and Loss, Cash Flow, etc). Multi-national enterprises require these fiscal reports in group currency using a single fiscal calendar. The single group fiscal calendar will be fundamentally different from all the local fiscal calendars in its definition of a fiscal period and annual alignment.
Unique Fiscal Calendar Definitions
When you take a step back and look at all the individual countries Fiscal time dimension requirements you will notice a pattern of redundancy. There will be a limited number of unique configurations that represent aspects of the fiscal time dimension across the entire multi-national corporation:
- Size of a fiscal period (week, month, etc);
- First and last period alignment to the gregorian calendar;
- Offset of fiscal year to gregorian calendar year;
- Shortened fiscal years to change annual alignment;
- Number of special periods;
- Language of the master data text.
It would be tempting to distil the data warehouse modeling down to only the few unique configurations for the fiscal time dimension in the BI reporting system. On the surface this is a good idea because it reduces the complexity of the data when being consumed in reports. On the other hand it makes support and reconciliation a little more confusing when working with the general reporting user community. Basically you are shifting the Effort Debt to later.
“paying the Effort Debt later will
cost you more in the long run”
In the beginning all will be well. It is easy enough for everyone to quickly learn that in their local ECC system they use Fiscal Variant ‘Z1’ and in the BI reporting system they use Fiscal Variant ‘Z7’. Ok. Now what happens when there is a corporate re-structure, acquisition or legislation change. All the posted transaction data is no longer using that exact unique configuration of the fiscal time dimension. [Uh, Oh]
Acknowledge the Effort Debt
The amount of configuration effort going into the ECC system to accommodate the new configuration is more than enough but now you have a mountain of changes to do in the BI system as well. The Effort Debt has finally caught up with you:
- Selection filters in InfoPackages and DTP;
- Hard coded fiscal variant values in ABAP;
- InfoProvider specific properties;
- SPO partitions;
- BEx query restrictions;
- APD and OpenHub extractors;
- Selection variable personalisation;
- Training documents;
- Change management announcements;
- Reporting user habits;
- Re-transporting everything that was touched;
- Regression testing of everything that was touched;
- Interference with current projects;
- Interference with BAU quick fixes.
These last four should make it very clear where the bulk of the Effort Debt is accumulated.
Talk to your BI Technical Team lead and ask: “Is the Development and Production systems in synch enough for you to feel comfortable to re-transport at least 35% of the entire DataModel; probably 85% of the fiscal DataModel itself? Covering significant parts of the ETL and reporting that involve a change to the Fiscal Variant value used?”.
Talk to your UAT Team Lead and ask: “Do you have all the necessary test scripts available and are they up to date to do a quick regression test across all the finance reports that involve a change to the Fiscal Variant used?”.
Talk to each of your BI Project Managers and ask: “Do you have the necessary budget to delay for 3-6 weeks while we implement the new corporation/re-structure into all the existing ETL and reports?”.
Talk to your BAU Team Lead and ask: “Is it ok if we block the TMS system from being able to do emergency quick fixes to production reports?”. Clearly this is not a realistic question because the answer 99% of the time is a straight ‘No, BAU emergency fixes must always be able to occur’.
Build for an Adaptable Future
Imagine you are being seconded to a new team that has to deal with the answers to the above questions. ‘No Action’ is not an option because the corporate sale or legislation is going to happen and the government tax office must have its reports on time.
What seemed like a good idea, to combine the fiscal time dimension configurations down to the minimum required for simplified reporting; does in fact just transfer the Effort Debt to become someone else’s problem later. Paying the Effort Debt later officially reduces the life expectancy of the entire data warehouse solution.
Do yourself a favour and be kind to those who follow you. Keep the original Fiscal Variant definition aligned to the source system for local reporting and reconciliation. Go to the effort of introducing a new fiscal time dimension specifically aligned to group consolidated financial reporting. Don’t let the technical question of ‘How to implement a second fiscal time dimension for group reporting?’ stop you from building a better DataModel in the beginning.
What are the official Fiscal Calendars used in my enterprise?