Financial Analytics – Uitleg structuur GL Accounts

Inleiding

Binnen de BI Applications module Financial Analytics bestaat er een mechanisme om in het grootboek op een flexibele wijze de grootboekrekeningen en daarbij behorende boekingen met boekingssleutels (segmenten genaamd) te gebruiken voor rapportage- en analysedoeleinden.

Voor iedereen die nieuw begint met BI Applications is het altijd een lastig te doorgronden onderwerp. Dit document tracht hierin helderheid te verschaffen.

In dit document gaat vooral de aandacht uit naar de boekingen van het grootboek (tabel W_GL_OTHER_F), maar hetzelfde principe geldt ook voor het budget (tabel W_ACCT_BUDGET_F), de balans (W_GL_BALANCE_F)  en sub-administraties (W_GL_COGS_F en W_GL_REVN_F). Eigenlijk alle feittabellen die GL Accounts gebruiken.

Toelichting functionaliteit

Binnen de BI Applications module Financial Analytics bestaat er een mechanisme om in het grootboek op een flexibele wijze de grootboekrekeningen en daarbij behorende boekingen met boekingssleutels (segmenten genaamd) te gebruiken voor rapportage- en analysedoeleinden.

Voorbeelden van segmenten zijn: Projecten, Kostenplaatsen, Dagboek.

Het grote voordeel van de introductie van segmenten is de mogelijkheid om op in totaal 30 boekingssleutels te kunnen rapporteren, zonder dat er direct nieuw maatwerk toegevoegd moet worden aan de gegevensmodellen voor het grootboek (GL).

Daarnaast is het ook mogelijk om voor alle 30 segmenten boomstructuren te tonen (hiërarchieën), waarvan de inhoud afkomstig is uit het bronsysteem. Dit betekent dus dat er zonder aanpassingen in BI Applications, diverse boomstructuren opgebouwd worden. Per segment is het mogelijk om een boomstructuur op te bouwen tot 20 niveaus diep.

Voorbeelden van hiërarchieën voor de reeds genoemde segmenten zijn:

  • Programma’s voor projecten
  • Secties en afdelingen voor kostenplaats
  • Etc.

Standaard zijn er al 10 segmenten compleet uitgewerkt binnen BI Applications (ETL en OBIEE). De segment types die in de “out of the box” BI Applications aanwezig zijn, zijn de volgende:

De volgende segmenten zijn momenteel in uitgewerkt:

  • Segment 1: Fund, met interne code 1010703
  • Segment 2: Program, met interne code 1010705
  • Segment 3: Project, met interne code 1010707
  • Segment 4: Object Class, met interne code 1010708
  • Segment 5: Operations Company, met interne code 1002470
  • Segment 6 : Fiscal Year, met interne code 1010702
  • Segment 7: SGL Account, met interne code 1010709
  • Segment 8 t/m 10: Operations Company, met interne code 1002470

Voor diverse bronnen is het toewijzen van segmenten configureerbaar voor de ETL; binnen OBIEE moeten hard gecodeerde filters binnen het Business Model worden gewijzigd.

Een grootboekrekening is met de constructie van segmenten niet meer uniek. Het is de combinatie van grootboekrekening met alle boekingssleutels die uniek moet zijn.

Alle zaken uit dit document die meer details geven, hebben betrekking op de drie-eenheid ‘GL Account’, ‘GL Segment’ en ‘Hierarchy’.

Toelichting techniek

Het volgende gegevensmodel ligt ten grondslag aan de grootboekrekeningen en segmenten.

Samenhang feit en dimensies GL Account, GL Segment en Hierarchie (voor 1e  segment)

In technische termen is er sprake van een “snow-flake” schema.

Binnen het business model van OBIEE wordt dit gegevensmodel op een andere wijze weergegeven. Dit gebeurt op een dusdanige manier dat de boekingen in het grootboek (W_GL_OTHER_F) aan zowel segmenten als aan grootboekrekeningen te koppelen zijn. Dus feitelijk resulteert dit in het volgende dimensionele model:

Samenhang feit en dimensies GL Account, GL Segment inclusief Hierarche (voor 1e  segment)

De fysieke tabellen W_GL_SEGMENT_D en W_HIERARCHY_D zijn samengevoegd in de dimensie “GL Segment” in het Business Model.

Voorbeelden van vulling van de tabellen

Aan de hand van enkele voorbeelden wordt aangegeven hoe bepaalde tabellen gevuld worden en hoe ze onderling samenhangen.

Inhoud van de bijbehorende rij(en) in de W_GL_ACCOUNT_D tabel. Er zijn veel kolommen weggelaten om het overzicht te bewaren.

Voor account segments 1 en 2 zijn de waarden getoond, zodat het verband met de GL_SEGMENTS tabel kan worden gelegd.

  • Bij de Account Segment Attributes komen de volgende codes voor van de segment typen: 1010703 voor segment 1 en 1010705 voor segment 2.
  • 1 GL Account kan meerdere keren voorkomen. Per gebruikte combinatie van segmenten moet een GL Account uniek zijn. Dit zie je terug in de INTEGRATION_ID, maar deze kolom staat niet ingevuld in bovenstaande tabel.
  • Bij elk segment moet een waarde ingevuld zijn. Dat is de reden waarom bijvoorbeeld “0000 – Default Program” bij rij 2 voor segment 2 op deze manier is ingevuld.
  • Inhoud van de bijbehorende rijen in de W_GL_SEGMENT_D tabel. In deze tabel staan in basis de unieke segmenten met hun betekenis.
  • De rijen die hier getoond worden hebben betrekking op dezelfde drie rijen waarvoor ook de hiërarchie wordt opgebouwd.

In de onderstaande tabel zijn de hiërarchieën uitgewerkt voor:

  • Segment 10110-MY
  • Segment 2 0000
  • Segment 2 0001
  • Niveau 1 is het topniveau, niveau 20 het laagste niveau. De code voor niveau 20 moet dus uniek zijn, samen met de HIER_CODE en HIERARCHY_ID.
  • De HIERARCHY_ID kan worden gebruikt om meerdere boomstructuren op te bouwen voor dezelfde knooppunten / bladeren. Bijvoorbeeld afdelingen vanuit HR of financieel perspectief.
  • De boom wordt altijd opgevuld van laag naar hoog. Indien er geen hoger niveau meer is qua vulling, dan wordt alles aangevuld met de waarde van het niveau waar nog wel een waarde beschikbaar is. In dit voorbeeld is er slechts 1 niveau ingevuld.

Samenhang tussen tabellen

De basisgegevens voor elke grootboekrekening staan in W_GL_ACCOUNT_D. Voor een bepaalde grootboekrekening kunnen verschillende grootboeksleutels (segmenten) worden opgegeven.

Dit wordt vastgelegd in de W_GL_SEGMENT_D tabel. Per segment wordt zowel een type (Natural account, Project, etc.) als waarde vastgelegd. Voor elk segment kan weer een hiërarchie worden opgebouwd, dat gebeurt in de W_HIERARCHY_D tabel.

Normaal gesproken wordt binnen BI Applications altijd op basis van ROW_WIDs een join gelegd tussen tabellen. Voor de 3-eenheid van GL Account, GL Segment en Hierarchie is dat niet het geval.

Van W_HIERARCHY_D naar W_GL_SEGMENT_D

hierarchy.HIER20_CODE = segment.SEGMENT_VAL_CODE

AND hierarchy.HIER_CODE = segment.SEGMENT_LOV_ID

Van W_GL_SEGMENT_D naar W_GL_ACCOUNT_D

segment.SEGMENT_LOV_ID = account.ACCOUNT_SEG2_ATTRIB

AND segment.SEGMENT_VAL_CODE = account.ACCOUNT_SEG2_CODE

NB: Join conditie is SQL code weergegeven. Dit geldt in dit voorbeeld voor segment 2.

Gebruik binnen OBIEE

Binnen OBIEE is er per segment een alias in de fysieke laag, en een logical table in de business model en presentatie laag.

Bij de logical table sources zijn filters opgenomen, die corresponderen met de out-of-the-box segment codes (1010703, 1010705).

Feitelijk is het niet veel meer dan dit.

Reacties zijn gesloten.