Oracle BI en Fiscale Periodes: Hoe Ga Je Om met Datums en Tijdsvormen?

Oracle BI – Overpeinzingen (7) – Cadran publiceert een reeks artikelen met inzichten over Oracle Business Intelligence in combinatie met Oracle JD Edwards. Elk artikel biedt inzichten die helpen bij beslissingen rondom de implementatie en toepassing van deze systemen. Eerdere artikelen bespraken het sterschema, feiten, dimensies en hun onderlinge samenhang. Dit artikel gaat in op de ontwikkelcyclus en de groei naar volwassenhOracle BI (in de cloud of op locatie geïnstalleerd) kent krachtige functies voor het weergeven van data in de tijd. Voorbeelden hiervan zijn:

  • Vergelijk vorige periodes (Ago)
  • Gemiddelden over meerdere periode berekenen (PeriodRolling)
  •  De huidige maand vergelijken met het lopende jaar (ToDate)

In mijn vorige blog even iets in de week leggen kwam al naar voren dat er enkele valkuilen kunnen zijn. Een kalender met een vaste structuur en hiërarchie werkt meestal goed. Zo kan een datum gemakkelijk worden opgerold naar de bijbehorende maand, kwartaal of jaar. De datum- en tijdsfuncties van Oracle BI sluiten hier perfect bij aan.

Fiscale Periodes

Financiële administraties van bedrijven werken echter niet per definitie via de kalenderstructuur, maar gebruiken (mogelijk niet op de kalender aansluitende) fiscale periodes. Hierin kunnen we drie varianten onderscheiden:

  1. De fiscale periodes van een bedrijf kunnen synchroon lopen met de kalendermaanden: er zijn dan twaalf periodes, die telkens beginnen op de eerste en eindigen op de laatste dag van de maand.
  2. Soms hanteert een organisatie een gebroken boekjaar. Zo begint het fiscale jaar in Japan vaak op 1 april. Als de fiscale periodes nog steeds hele kalendermaanden beslaan, zijn er geen grote aanpassingen nodig; we hoeven alleen rekening te houden met het feit dat fiscale periode 3 overeenkomt met kalendermaand 6. De tijdsstructuur kan dan eenvoudig worden afgestemd op de kalender.
  3. Een andere situatie ontstaat wanneer een bedrijf 13 fiscale periodes van 4 weken gebruikt, waardoor de periodes niet netjes aansluiten op de kalendermaanden. Als het einde van de fiscale periode bijvoorbeeld niet samenvalt met het einde van de maand, maar met de laatste werkdag, ontstaan er grotere uitdagingen.

In de eerste twee gevallen sluiten de fiscale en kalenderstructuur grotendeels op elkaar aan, hoewel schrikkeljaren wel voor afwijkingen kunnen zorgen

Uitdagingen bij Oracle BI

Het laatste scenario, waarin de periodes niet overeenkomen met kalendermaanden, vormt een uitdaging voor de standaardfunctionaliteit van Oracle BI. De tijdsstructuur van Oracle BI is namelijk ontworpen om periodes consistent uit te rollen naar onderliggende data. Zo werkt de functie Ago door een bepaalde periode uit te klappen naar bijbehorende datums, zodat dezelfde reeks datums uit een vorig jaar kan worden geselecteerd. Als fiscale periodes in verschillende jaren niet op dezelfde datum eindigen, kan de functie YearAgo geen vergelijkbare data leveren.

Bij een recente implementatie van Oracle BI kwam ik deze situatie tegen. De klant wilde natuurlijk graag een oplossing die werkt—en die is er:

Oplossing: werken met transacties op dagniveau

Voor gegevens zoals journaalposten en logistieke transacties is werken met datums meestal prima. Elke transactie kan worden gekoppeld aan een specifieke datum, die eenvoudig vergeleken kan worden met dezelfde datum vorig jaar. De fiscale structuur kan vervolgens weer worden samengevoegd tot de bijbehorende periode en het fiscale jaar. Voor balanstabellen, zoals JD Edwards General Balance en Fixed Asset Balance, die alleen de einddatum van een fiscale periode kennen, zijn er echter extra stappen nodig.

Alternatief voor de datum/tijd-functies van Oracle BI

Hoewel het lastig kan zijn om de geavanceerde datumfuncties van Oracle BI los te laten, biedt dit een stabielere oplossing. Voor specifieke situaties is het mogelijk om bijvoorbeeld de middelste dag van de fiscale periode te gebruiken. Maar bij 13 periodes van 4 weken blijkt dit vaak niet voldoende.

Een robuuste oplossing

Een effectieve aanpak is om de periodetabel van Cadran (FQ09PER™) uit te breiden met een kolom voor het fiscale jaar en de fiscale periode. Met een SQL-script worden per kalenderdatum de juiste waarden ingesteld, gebaseerd op de fiscal-date-opzet van JD Edwards. Hierdoor kan eenvoudig gefilterd worden op het huidige jaar, de huidige periode en dezelfde periode in het voorgaande jaar. De Ago-functie is dan niet nodig. Voor verlies- en winstrekeningen en diverse balansoverzichten werkt dit vlekkeloos, met uitstekende prestaties doordat de database deze functies afhandelt via SQL.

Schrikkeljaren in BI – een extra uitdaging 

Schrikkeljaren kunnen BI-analyses lastiger maken. Denk aan de datum 29 februari die komt alleen in schrikkeljaren voor en maakt vergelijkingen met andere jaren lastig. De functie YearAgo kan bijvoorbeeld niets tonen voor 29 februari, omdat die datum er het jaar ervoor niet was. Hierdoor heeft een schrikkeljaar 366 dagen in plaats van 365, wat kan betekenen dat er meer dagen zijn gewerkt of omzet is gedraaid. Voor een eerlijke vergelijking zouden we de gegevens uit een schrikkeljaar moeten aanpassen, bijvoorbeeld door ze te corrigeren met de factor 365/366.

In JD Edwards tabellen zoals Sales Forecasting (F3460) en tabellen die afhankelijk zijn van Fiscal Date Patterns (F0008) kan het nodig zijn om 29 februari te vervangen door 28 februari, zodat er consistente vergelijkingen mogelijk zijn tussen jaren.

Een praktische aanpak

Een manier om met schrikkeljaren om te gaan is door de tijdsfuncties van Oracle BI te vermijden. Traditioneel zou je bijvoorbeeld een filter gebruiken (zoals YearNr= YEAR(CURRENT_DATE). Een veelgebruikte methode is een kolom voor de huidige omzet en een kolom voor de omzet van vorig jaar, waarbij de Ago-functie de omzet op jaarbasis vergelijkt. Het werkt echter vaak net zo goed om te filteren op huidige omzet en omzet van vorig jaar via column filters, waarbij je handmatig instelt dat de eerste kolom dit jaar selecteert en de tweede vorig jaar. Door hier een filter voor februari aan toe te voegen, werkt deze vergelijking ook in schrikkeljaren.

Een alternatieve oplossing is om de datumtabellen uit te breiden met een kolom vorig jaar,  die de datum van vorig jaar bevat. Zo kan de waarde 28 februari 2015 bijvoorbeeld dienen als een vergelijkingsdatum voor zowel 28 als 29 februari 2016. Hoewel dit een kleine vertekening kan geven, omdat één dag van 2015 vergeleken wordt met twee dagen in 2016, kan het een praktische oplossing voor consistente vergelijkingen zonder de YearAgo-functie. Door een extra kolom toe te voegen met de bijbehorende datum van vorig jaar (bijvoorbeeld Julian Data Previous Year) kunnen vergelijkingen worden gemaakt zonder de speciale logica voor schrikkeljaren. Dit kan zelfs prestatievoordelen bieden.

Een simplistische oplossing

Een andere, maar minder ideale aanpak, is om 29 februari gewoon uit te sluiten door een filter te gebruiken. Dit werkt voor generieke vergelijkingen zoals omzet per maand per productgroep, maar de datum negeren kan voor afwijkingen zorgen, vooral op financieel vlak.

Conclusie

Een perfecte oplossing is er helaas niet: er blijft altijd sprake van en compromis. De meest consistente methode is vaak om op periodes zoals yearToDate te focussen, waarbij je bijvoorbeeld de periode van 1 januari tot vandaag vergelijkt met dezelfde periode vorig jaar. Zo vermij je grote afwijkingen tot aan het einde van het jaar. In de praktijk maken we over een jaar gezien vaker correcties, zoals voor feestdagen, die elk jaar anders vallen. Schrikkeljaren vormen hierin slechts één van de vele variabelen.

Profit & Loss van februari 2017 in Oracle BI met data uit JD Edwards. AmountPY slaat dus op februari 2016 (zijnde de schrikkelmaand).sch naar voorspellend en van operationeel naar strategisch.

Jelle Huisman managing partner

Jelle Huisman

Managing Partner