XBRL Dimensions, een uitleg Auteur: Roland Hommes
XBRL Dimensions – Wat is dat? XBRL Dimensions (in goed Nederlands: dimensies, maar de specificatie heet Dimensions dus dat is de term die gebruikt wordt) is een specificatie die bovenop de bestaande XBRL 2.1 specificatie gebruikt kan worden. Het stelt de taxonomie bouwer in staat om multi dimensionale tabellen (zgn. hypercubes) te definiëren in zijn XBRL taxonomie waardoor het mogelijk wordt individuele cellen in een tabel aan en uit te zetten in de vragenlijst die de rapporteur moet vullen. Er zijn diverse methoden waarop een (overheids) instantie zijn vragen in elektronische vorm kan presenteren. De meest gebruikte zijn: meerdere formulieren, hoofdstukken met paragrafen (nesting) en tabellen. De eerste twee manieren zijn in de XBRL 2.1 specificatie opgelost door verschillende schema’s te maken, of te werken met linkRoles in een enkel schema, en door middel van nesting met behulp van abstract elementen in de presentatie linkbase. De tabelvorm is niet eenvoudig weer te geven met alleen de 2.1 specificatie. Men kan opteren om een tuple (xsd:complexType) in te richten als de tabel en een enkele as in een concept vorm te geven met behulp van een enumeratie lijst, maar dit heeft als nadeel dat er op geen enkele manier afgedwongen kan worden welke combinatie van enumeratie waarde met de andere concepten ingevuld mag worden en welke niet. In 2004 bevonden de centrale banken in Europa, verenigd in CEBS, zich in dezelfde positie. Men gebruikt voor de rapportage van handels banken aan de centrale banken bijna alleen (complexe) tabellen in Microsoft Excel, waarin door met kleuren te werken aangegeven wordt welke velden wel en niet ingevuld mogen worden. Deze systematiek is in XBRL vorm gegeven door de Dimensions Specificatie, opgesteld door XBRL International. XBRL Dimensions - Sleutelonderdelen De specificatie bedient zich van een eigen terminologie die ontleent is aan data warehouse software: Hypercubes Is de term die de tabel (of kubus) vertegenwoordigd. Dimensions Is de term die de assen van de tabel vertegenwoordigd. Domains Is de term van een logische verzameling begrippen waarop gerapporteerd moet worden. Domain members Zijn de leden waarop gerapporteerd moet worden, maar die als abstract in de taxonomie terecht komen. Ze komen terug in de instance in het segment of scenario deel en geven daarmee de dimensie vorm op het te rapporteren element. Ze vormen de regels of kolommen in een tabel. Primaries Zijn de individuele gegevens die gerapporteerd moeten worden. Ze vormen vaak de regels of kolommen van een tabel maar soms alleen de cellen. arcRoles Er zijn diverse onderscheidende arcRoles aangemaakt om de verbinding tussen Hypercube, Dimension, Domain, Domain-member en Primary te maken. De sleutel binnen XBRL om de tabel werkend te krijgen is extensief gebruik van de Xlink standaard. Door een hypercube (tabel) te voorzien van dimensions (assen) en deze assen te op te delen in domains met members (regels en kolommen), kan het geheel aan te rapporteren elementen (primaries) gekoppeld worden. Het is duidelijk dat dit tot een wirwar van koppelingen leidt. Normaliter wordt in XBRL de nesting tot een minimum beperkt. Eigenlijk wordt veel betekenis in de naam van een concept gestopt zoals het volgende IFRS voorbeeld laat zien: Ifrs-gp_AccumulatedAllowanceForUncollectibleMinimumLeasePaymentsReceivableNonCurrent. In deze conceptnaam kunnen gemakkelijk diverse herhalende onderdelen van een taxonomie herkend worden. Deze zijn nu dus in de naam gemodelleerd maar ze hadden ook anders gemodelleerd kunnen worden. Eén van die manieren is om de gegevens in een tabel te modelleren. Voorbeelden Voorbeeld 1; Een tabel met een enkele dimensie: Verkoop Kosten Declarant 750 500
Winst 250
Provisie 50
Partner Company Holding
490 340 670
315 230 450
175 110 220
35 0 100
Verkoop gerelateerde getallen per aangever in EUR (x 1000), voor het jaar 2007.
Voorbeeld 2; Een tabel met twee dimensies: Current Declarant 100 Partner 350 Company 250 Holding 45
Previous 500 90 90 0
Next 125 X X 425
Verkopen per aangever/periode in EUR (x 1000), over het jaar 2007.
Voorbeeld 3; Een tabel met drie dimensies: Aangever Periode Declarant Current Previous Next Partner Current Previous Next Company Current Previous Next Holding Current Previous Next
Verkoop 100 500 125 350 90 X 250 90 X 45 0 425
Kosten 125 125 125 125 90 X 130 100 X 150 0 150
Winst -25 375 0 225 0 X 120 -10 X -105 0 275
Provisie 0 50 0 35 0 X 0 0 X 0 0 90
Verkoop gerelateerde getallen per aangever/periode in EUR (x 1000), over het jaar 2007.
In alle voorbeelden is er één hypercube, de tabel zelf. De dimensions zijn: de aangevers en de perioden. De domains zijn: aangeverrollen, perioden. De domain-members zijn: de individuele aangeverrollen en de individuele periodenamen. De primaries zijn: verkoop, winst, kosten en provisie. Opmerkingen: In voorbeeld twee wordt eigenlijk vals gespeeld, er wordt ingezoomd op de verkoopopbrengsten, de kosten en andere getallen worden niet meer meegenomen. Het staat de opsteller van de taxonomie vrij om de dimensies op de assen om te draaien, dit heeft geen gevolg voor de communicatie. Er wordt in de voorbeelden een verhouding van 1:1 tussen dimensie en domein gelegd. Die is er in werkelijkheid niet altijd. De rapporteur kan bv. kiezen om een ISO landencode lijst uit te breiden met ‘bezet palestijns gebied’ en ‘Sri Lanka’. Aangezien alleen de ISO organisatie de codelijst kan uitbreiden moet de taxonomie bouwer een tweede domein maken met deze ‘uitzonderingen’ en zijn domein samen met het ISO domein in de dimensie hangen. Voor de rapporteur lijkt het dan alsof er 1 lijst is. De cellen met een donkergrijs kruisje hebben een speciale betekenis; de organisatie die de cijfers opvraagt staat niet toe dat hier een waarde ingevuld wordt. XBRL Dimensions – Het maken van een tabel in een taxonomie Bij het volgen van de hieronder beschreven stappen wordt van de taxonomie bouwer verwacht dat hij de te structuren gegevens als een soort tabel als in de voorbeelden hierboven, in zijn hoofd heeft. 1) Maak de primaries. Dit zijn gewone concepten waarop door de rapporteur waarden moeten worden vermeld. De ‘best practice’ regels stellen dat deze concepten in een schema opgenomen zijn waarvan de naam begint met ‘p-‘. De p staat voor primary. Het is zaak tuples te vermijden en op te passen met abstracts en betekenissen in de conceptnaam te stoppen die later als domain-members in de tabel weer terug komen. De parent van alle primaries moet een abstract element zijn. 2) Maak de hypercube. De hypercube is een speciaal abstract concept. Door de referentie van het concept naar de substitutionGroup xbrldt:hypercubeItem wordt deze speciale betekenis
3)
4)
5)
6)
kenbaar gemaakt. De ‘best practice’ regels stellen dat deze concepten in een schema opgenomen zijn waarvan de naam begint met ‘t-‘. De t staat voor template. Hierop is af te dingen dat dit schema voor twee doeleinden gebruikt wordt; het koppelen van de hypercube aan de primaries en het definiëren van de hypercubes zelf. Maak de dimensie aan. De dimensie is een speciaal abstract concept. Door de referentie van het concept naar de substitutionGroup xbrldt:dimensionItem wordt deze speciale betekenis kenbaar gemaakt. De ‘best practice’ regels stellen dat deze concepten in het schema opgenomen zijn waarvan de naam begint met ‘t-‘. Maak het domein met zijn leden aan. Dit zijn allen normale abstracte concepten. Een nesting van de concepten is toegestaan. De structuur wordt zowel in de presentatie- als definitie link base vorm gegeven. In de laatste is dat met de speciale arcRole ‘domain-member’. De reden voor deze kopie is dat er vanuit de koppeling primary-hypercube verwezen kan worden met behulp van een speciaal attribuut (xbrldt:targetRole) naar de opbouw van de domeinen, die opbouw moet zich dan in de definitie linkbase bevinden. De ‘best practice’ regels stellen dat deze concepten in een schema opgenomen zijn waarvan de naam begint met ‘d-‘. De d staat voor domein. Aan het template schema wordt ook een definitie linkbase aangelegd waarin de primaries aan de hypercube gekoppeld worden (via de arcRole ‘all’) en waarin de hypercube naar dimensie (arcRole hypercube-dimension) en dimensie naar domein (arcRole dimension-domain) en domein naar leden (arcRole domain-member) vastgelegd worden. Omdat de koppeling hypercube-primary in een andere linkRole vastligt dan de hypercube zelf is opgebouwd moeten deze twee naar elkaar verwijzen. Dit gaat door het attribuut xbrldt:targetRole in de hypercube-primary arc op te nemen. Het aangeven van cellen die niet ingevuld mogen worden gaat op dezelfde manier als het aangeven van cellen die wel ingevuld mogen worden. Door een andere arcRole (notAll) toe te kennen moeten deze cellen ‘verboden’ worden. Eis hierbij is dat de dimensie, domein en leden waarvoor de uitzondering geldt dezelfde namen hebben als bij de ‘all’ arcRole.
Met deze stappen wordt een simpele dimensionele taxonomie opgezet. Het laatste probleem is dat de instance zich nu nog nergens van bewust is. Hiervoor wordt gebruik gemaakt van een speciaal attribuut xbrldt:contextElement. Door dit op te nemen in de arc hypercube-primary met een waarde ‘scenario’ (of segment), kan de instance linken aan de dimensie en domein leden. XBRL Dimensions – Gevolgen voor rapporteurs In een standaard XBRL instance die alleen op de 2.1 specificatie geënt is, bevat de instance veel concepten die veelal op het hoogste niveau opgenomen zijn. Met de introductie van Dimensions in de taxonomie worden veel concepten omgezet naar abstract domain-members, hier kan dus niet direct een waarde op gerapporteerd worden. Deze abstract domain-members komen terug als onderdeel van het scenario (of segment) element. Aangezien deze elementen in de context vervat zijn, verschuift de afname van het aantal concepten naar een toename in het aantal contexten. In de contexten staan echter nog meer elementen (entitity, period), vanzelfsprekend ligt er een hard verband tussen de inhoud van de entity en period ten opzichte van de domain-members in de scenario en segment elementen. Er is helaas geen XBRL controle vanuit de taxonomie mogelijk op de consistentie tussen entity, period, scenario en segment. Deze controle moet in de FRIS beschreven worden en extern gecontroleerd. Voor rapporteurs die een mapping gemaakt hebben vanuit XBRL concepten naar hun eigen begrippen is met de introductie van Dimensions een noodzaak ontstaan deze mapping te herzien. Indien de elementen scenario en segment voorheen niet gebruikt worden is dat nu wel het geval waardoor een complexer conversiepad ontstaat. Een groot aantal concepten zal vervallen zijn en verplaatst naar de domain-members, dit moet in de mapping terug komen. Voorbeeld: <xbrli:scenario> <xbrldi:explicitMember dimension="d-iso:CountryDimension">d-iso:NL In het bovenstaande voorbeeld is de ISO landcode, die voorheen een concept was, omgezet naar een domain. De concepten die de landencode als dimensie kennen zullen nu gaan verwijzen naar de context waar o.m. dit stukje scenario in beschreven staat. XBRL Dimensions - Stekeligheden
In de 2.1 specificatie is het concept linkRole geïntroduceerd om binnen linkbases groepen van gegevens te onderscheiden. Met de invoering van Dimensions is daar een veel groter belang aan toegekend. De linkRole zorgt voor de scheiding van de hiërarchie in domain-members over dimensies heen. Uitleg: als een parent-child arc in een hypercubes wordt gedefinieerd, en in een tweede hypercube wordt eveneens gebruikt gemaakt van de parent dan krijgt deze tweede hypercube automatisch eveneens de child genest onder de parent. Om dit te voorkomen moeten de beide hypercubes in verschillende linkRoles gedefinieerd worden. Het toekennen van verplichtingen aan elementen kan in de 2.1 specificatie op verschillende wijzen. Er kan een xsd:minOccurs attribuut aan een concept worden toegekend. Dit is niet context gevoelig maar kan wel afdwingen dat het element in de instance opgevoerd wordt. Een andere mogelijkheid is de definitie link requires-element die middels een verbandscontrole een element, ook niet context gevoelig, verplicht kan stellen in de instance. Omdat Dimensions zwaar leunt op de structuur met contexten werken beide methoden hierbij niet. Er is geen vervangende methode beschikbaar. Het laten herhalen van concepten wordt in de 2.1 specificatie opgelost door een tuple te benoemen die het attribuut xsd:maxOccurs gebruikt. Aangezien in Dimensions geen tuple gebruikt kan worden (de domain-members kunnen alleen abstract items zijn, en de primaries moeten een item zijn), is deze optie niet te gebruiken. Ook hiervoor is geen alternatief voor handen. Een verplichte keuze wordt in de 2.1 specificatie vorm gegeven door het attribuut xsd:choice in een tuple. Aangezien de tuple niet toegestaan is, is ook de xsd:choice niet langer voor handen. XBRL Dimensions – Naar een hoger niveau Tot nu toe is deze introductie geschreven voor de ‘simpele’ vorm van Dimensions, de explicit variant. Maar er is ook een typed variant. Deze vorm maakt het mogelijk dat domeinen waarbij het niet praktisch is om de domeinleden uit te schrijven (bv. alle personeelsleden van een groot bedrijf), door de rapporteur te laten invoeren bij het maken van de instance. Hiertoe wordt een speciaal concept opgenomen in de dimensie. Er is dan wel een domein maar er is slechts één lid, het concept dat de string of het nummer gaat bevatten dat de unieke sleutel tot het domein vormt. Het is mogelijk per hypercube te beslissen of de taxonomie opsteller alle primaries benoemt die in voorzien mogen worden in het domein, of dat het aantal primaries vrij laat, zolang ze maar in de taxonomie voorkomen. In het laatste geval stelt hij de hypercube ‘open’ door een speciaal attribuut op de arc van hypercube naar primaries mee te geven, xbrldt:closed. Dit kan de waarde true/false bevatten. Het gevolg van het openzetten van een hypercube is dat het de controlemogelijkheden op de instance aanzienlijk inperkt. Gebruikers van XBRL wordt aangemoedigd onderdelen van andere taxonomiën te gebruiken. Dit wordt gedaan door een extensie taxonomie te ontwikkelen die de taxonomie van een ander importeert en hierop voortborduurt. Bij dimensionele taxonomiën wordt in dit geval het template schema geïmporteerd. Er is echter geen technische beperking om het primary of domain schema te importeren en zo een eigen template schema naast dat van de originele maker te zetten. Er is geen methode in XBRL die dergelijk gebruik voorkomt. In de nabije toekomst zal er een formule linkbase specificatie aan XBRL worden toegevoegd om business rules op de instance los te laten. De huidige structuur van concepten met tuples en extended links met daarbij de context informatie maakt het al een hele uitdaging om goede formules te kunnen maken. De Dimensions specificatie zal er zeker niet voor zorgen dat het gemakkelijker wordt om deze business rules vorm te geven. Over de auteur; Roland Hommes is medewerker van de Belastingdienst als lid van het team metadata administratie welke verantwoordelijk is voor de Belastingdienst taxonomie, een belangrijk deel van de NTP taxonomie. Hij heeft een eigen consultancy bedrijf in communicatie standaarden in welke hoedanigheid hij verantwoordelijk is voor de taxonomie en FinRep extensies van de Nederlandsche Bank. Hij speelt een belangrijke rol in het vaststellen van de XBRL architectuur voor het NTP en is een actief lid van verschillende XBRL International werkgroepen.
Bijlage: XML syntax Voorbeeld concept definitie van hypercube, dimensie, domein en leden: <xsd:element abstract="true" id="sands_HcCorporationTaxHypercube" name="HcCorporationTaxHypercube" nillable="true" substitutionGroup="xbrldt:hypercubeItem" type="xbrli:stringItemType" xbrli:periodType="instant"/> <xsd:element abstract="true" id="sands_ScenarioDimension" name="ScenarioDimension" substitutionGroup="xbrldt:dimensionItem" type="xbrli:stringItemType" xbrli:periodType="instant"/> <xsd:element abstract="true" id="sands_PeriodDomain" name="PeriodDomain" nillable="true" substitutionGroup="xbrli:item" type="xbrli:stringItemType" xbrli:periodType="instant"/> <xsd:element abstract="true" id="sands_Current" name="Current" nillable="true" substitutionGroup="xbrli:item" type="xbrli:stringItemType" xbrli:periodType="instant"/> <xsd:element abstract="true" id="sands_Previous" name="Previous" nillable="true" substitutionGroup="xbrli:item" type="xbrli:stringItemType" xbrli:periodType="instant"/> <xsd:element abstract="true" id="sands_Next" name="Next" nillable="true" substitutionGroup="xbrli:item" type="xbrli:stringItemType" xbrli:periodType="instant"/>
Voorbeeld van de definition linkbase om de hypercube gestalte te geven:
Voorbeeld van een hypercube om velden te verbieden:
Voorbeeld van de koppeling van de hypercube aan de primaries:
In het laatste voorbeeld wordt aangegeven dat de parent primary (ConditionsTaxReturn) gekoppeld wordt aan twee Hypercubes: HcCorporationTaxHypercube en HcExcludeNextHypercube. Met de eerste cube worden alle domein leden toegestaan (arcRole all) en met de tweede cube wordt het ‘next’ domein lid weer uitgezet (arcRole notAll). Duidelijk is ook dat beide cubes in een aparte linkrole zitten (zie targetRole), waar ze hun opbouw uit moeten halen.
