Green Paper - Preparer Extensions

Uit Logius SBR Wiki
Ga naar: navigatie, zoeken
Versie : 1.2
Status : Definitief
Datum : 17 juli 2017


Wijzigingsbeheer:

Versie
1.1 Private Extensies vervangen voor Preparer extensions
1.1 Figuur 1 aangepast
1.2 Update n.a.v. pilot / Akkoord SBR Beraad d.d. 6 Juli 2017


Inhoud

Inleiding

Aanleiding

Dit document is onderdeel van het traject om een generieke methode te realiseren voor het insturen van verantwoordingsrapportages met preparer extensions (voorheen: private extensies). Van een preparer extension is sprake wanneer een opsteller in haar XBRL instance document concepten, definities of relaties toepast en/of wijzigt die niet door uitvragende partij beschikbaar zijn gesteld in het betreffende entrypoint. Veelal zal een preparer extension bestaan uit nieuwe concepten welke door een opsteller wordt aangemaakt en toegevoegd aan een instance document. Het kan echter ook voorkomen dat een opsteller gebruik maakt van concepten uit andere (door de betreffende uitvragende partij) toegestane schema’s en alleen deze concepten toevoegt aan het instance document.

De preparer extensions bieden rechtspersonen de mogelijkheid om via SBR aanvullende informatie te verstrekken in de jaarverantwoording. De eerste use-case voor deze situatie betreft de verplichte deponering van financiële jaarverantwoordingen bij het Handelsregister van de Kamer van Koophandel (KvK). Om de aanlevering van de jaarverantwoording met preparer extensions mogelijk te maken, dienen aangepaste gegevensarchitecturen, procesconfiguratie(s) en services te worden herzien en waar nodig geïmplementeerd ten behoeve van de aanleverpoort en de systemen van de Kamer van Koophandel.

De Taskforce Preparer Extensions (hierna: Taskforce) is opgezet om het ontwerp rondom preparer extensions te ontwikkelen en de implementatie hiervan te begeleiden. De Taskforce bestaat uit vertegenwoordigers van accountantskantoren, softwareontwikkelaars, beroepsorganisaties, uitvragende partijen en Logius. De Taskforce heeft als doelstelling om een generieke methodiek voor preparer extensions te realiseren, zodat de beschreven architecturen, configuraties en services in meerdere informatieketens toegepast kan worden.

Doel van dit document

Dit document dient als basis voor de consultatie van het ontwerp voor preparer extensions binnen de verschillende SBR gremia. Dit document licht het ontwerp toe met betrekking tot gegevens, processen en techniek voor het deponeren van de verantwoording met preparer extensions via SBR. Hierbij wordt ook aangegeven op basis van welke afwegingen de Taskforce tot dit ontwerp is gekomen. Aan de hand van dit document kunnen SBR gremia hun opmerkingen kenbaar maken, waarna een definitief ontwerp zal worden vastgesteld.

Scope

De preparer extensions methodiek is ontwikkeld binnen het kader van de Nederlandse wet- en regelgeving. In dit kader vormt de toepassing voor jaarverantwoordingen naar de KvK de eerste use-case, waarbij het uitgangspunt is alle ontwerpaspecten zo generiek te benaderen.

Definities

In dit document worden de volgende definities aangehouden:

Preparer extension: Van een preparer extension is sprake wanneer een opsteller in haar XBRL instance document concepten, definities of relaties toepast en/of wijzigt die niet door uitvragende partij beschikbaar zijn gesteld in het betreffende taxonomie-entrypoint.

SBR taxonomie: Een SBR taxonomie is een taxonomie die voldoet aan de NTA en eigendom is van een SBR partner.

Leeswijzer

Hoofdstuk 2 geeft een overzicht van de uitgangspunten voor het ontwerp. In hoofdstuk 3 zijn de gemaakte keuzes rondom de gegevensarchitectuur toegelicht. In hoofdstuk 4 is een overzicht gegeven van de nieuwe services welke benodigd zijn om de preparer extensions te kunnen valideren. Tot slot is in bijlage A een overzicht gegeven van de processen in Digipoort voor de verwerking van een preparer extension voor de KvK. In bijlage C zijn alle Nederlandse Taxonomie Architectuur Preparer Extensions (NTA-PE) regels gegeven.

Uitgangspunten

De Taskforce heeft verschillende uitgangspunten gehanteerd bij het opstellen van het ontwerp voor het insturen van verantwoordingsrapportages met preparer extensions via SBR.

Het eerste uitgangspunt is specifiek voor de Kamer van Koophandel use-case van toepassing:

Uitgangspunt 1 : Rekening houden met publicatie in het Handelsregister

De jaarverantwoording dient (uiteindelijk) gepubliceerd te kunnen worden in het Handelsregister van de KvK. Hiervoor is het noodzakelijk dat er naast het XBRL–formaat een voor mensen leesbare versie van de jaarrekening in het handelsregister beschikbaar is ("De via SBR gedeponeerde jaarrekening moet voor derden leesbaar zijn." Memorie van Toelichting wetswijziging 'Deponering van bescheiden in het handelsregister langs elektronische weg', vergaderstuk 34 262 nr. 3, Tweede Kamer vergaderjaar 2014-2015). Het ontwerp voor de toepassing van preparer extensions dient hier rekening mee te houden.

Naast het specifieke uitgangspunt zijn er een aantal generieke uitgangspunten voor het ontwerp preparer extensions.

Uitgangspunt 2 : Ontwerp preparer extension methodiek heeft betrekking op een SBR taxonomie

Het uitgangspunt is dat binnen een informatieketen een uitvragende partij aanwezig is die via een SBR taxonomie haar informatie-uitvraag kenbaar maakt. Deze uitvragende partij kan haar aanleveraars de mogelijkheid geven om aanvullende begrippen – die niet in het entrypoint van de uitvragende partij zijn opgenomen – toe te passen in hun XBRL instance document (de rapportage).

Uitgangspunt 3 : Naleven van relevante wet- en regelgeving

Dit uitgangspunt heeft betrekking op de inhoud van de verantwoordingsrapportage vanuit de wet- en regelgeving. Datgene wat nu vanuit de wet- en regelgeving mogelijk en toegestaan is op papier moet ook mogelijk zijn met SBR.

Uitgangspunt 4 : Gebruik maken van de bestaande SBR architectuur

De huidige architectuurkeuzes van SBR zijn leidend voor de inrichting van de informatieketen voor het insturen van jaarverantwoordingen met preparer extensions. Er moet voldaan worden aan de Nederlandse Taxonomie Architectuur (NTA) en de Nederlandse Processen Architectuur (NPA).

Uitgangspunt 5 : Focus op vergelijkbaarheid van jaarverantwoordingen

Er dient zoveel mogelijk gebruik gemaakt te worden van reeds bestaande begrippen uit de onderliggende SBR-taxonomie om de vergelijkbaarheid van de jaarverantwoordingen te bevorderen. Uitvragende partijen dienen entrypoints zodanig op te stellen dat de toepassing van een preparer extension niet nodig is voor een groot deel van de rapporterende partijen. Indien ketenpartijen constateren dat specifieke gegevenselementen veelvuldig worden gebruikt door rapporterende partijen, dienen de ketenpartijen deze elementen op te nemen binnen de bestaande verantwoordingsrapportages.

Uitgangspunt 6 : Compatibiliteit met SBR-verklaringen

De SBR-verklaringenmethodiek moet verantwoordingen met preparer extensions kunnen ondersteunen. Het ontwerp van de preparer extensions architectuur dient hiertegen geëvalueerd te worden.

Uitgangspunt 7 : Zoveel mogelijk voldoen aan de NTA

De architectuurregels voor preparer extensions (NTA-PE) worden opgesteld in lijn met de reguliere Nederlandse Taxonomie Architectuur (NTA). Hierbij wordt alleen afgeweken van de bestaande NTA regels als dit noodzakelijk is.

Uitgangspunt 8 : Ervaringen van andere landen in acht nemen De ervaringen uit de Verenigde Staten en het Verenigd Koninkrijk dienen in acht genomen te worden bij het ontwerp van preparer extensions in Nederland. Hierbij dienen de problemen die deze landen ervaren waar mogelijk te worden voorkomen.

  • Een belangrijk karakteristiek van de situatie in de Verenigde Staten is dat de vrijheid om eigen begrippen te definiëren vaker gebruikt wordt door de beursgenoteerde ondernemingen dan noodzakelijk is, de begrippen zijn in dat geval al opgenomen in de US-GAAP taxonomie. De SEC geeft aan dat het belangrijkste leerpunt voor hen is om voldoende en uitvoerbare beheersmaatregelen te nemen waarmee de bovenstaande situatie voorkomen kan worden.
  • In het Verenigd Koninkrijk hoeft voor de informatie waarvoor geen concept beschikbaar is alleen als reguliere tekst opgenomen te worden in het Inline XBRL bestand. Deze tekst kan dus niet geautomatiseerd verwerkt worden. Dit is een bewuste keuze omdat de uitvragende partijen hier uitsluitend interesse hebben in de informatie die in gestructureerde vorm beschikbaar komt. de niet-gestructureerde informatie is eenvoudiger om te rapporteren, maar tegelijkertijd is de (her)bruikbaarheid van deze informatie ook laag.


Gegevens

Invulling gegevensarchitectuur

In Figuur 1 is de gegevensarchitectuur voor preparer extensions weergegeven. Een rapporterende partij verwijst in het XBRL instance document door middel van een schemaRef naar een nieuw, door hem zelf aangemaakt, preparer extension entrypoint. Dit preparer extension entrypoint importeert een bestaand SBR entrypoint en verwijst naar nieuwe preparer extension presentation en definition linkbases. In de linkbases zijn relaties opgenomen die onder meer verwijzen naar de nieuw aangemaakte elementen, in het bijzonder concepten, domeinen, domeinleden, abstracte presentatie items, data types en tuples. Deze elementen worden in het preparer extension entrypoint schema aangemaakt. Wanneer elementen zijn ingemaakt in het preparer extension entrypoint schema, verwijst dit schema ook naar één of meer label linkbases.

Horizontal alignment=center

Figuur 1: Gegevensarchitectuur preparer extensions

Overwegingen gegevensarchitectuur

De invulling van de gegevensarchitectuur is door de Taskforce op basis van de volgende onderwerpen tot stand gekomen:

  1. Wijze van hergebruik van een bestaande taxonomie
  2. Wijze van definiëren van begrippen in de preparer extension
  3. Wijze van aanroepen van de preparer extension vanuit het instance document
  4. Wijze van invulling van het preparer extension entrypoint
  5. Wijze van toepassing van de preparer extension linkbases (relaties)
  6. Wijze van toepassing van de preparer extension table linkbase
  7. Wijze van invulling van de preparer extension linkbases (relaties)
  8. Wijze van invulling van de preparer extension schema of schema’s
  9. Wijze van invulling van de preparer extension label linkbases
  10. Wijze van invulling van de preparer extension reference linkbases


1. Wijze van hergebruik van een bestaande taxonomie
Het is van belang om een keuze te maken voor de wijze van hergebruik van een taxonomie. Hiervoor zijn grofweg twee mogelijkheden te onderkennen:

  1. Rapporteurs ontwikkelen zelf een nieuwe – losstaande – taxonomie, waarbij de bestaande elementen uit de jaarverslaggevingstaxonomie worden hergebruikt, aangevuld met zelf gedefinieerde begrippen.
  2. Rapporteurs hergebruiken een bestaand SBR entrypoint, waardoor niet alleen de elementen, maar ook de verschillende relaties (zowel presentatie als definitie relaties) tussen elementen worden hergebruikt.

Overweging Taskforce: Het is wenselijk om zoveel als mogelijk te hergebruiken, aangezien de preparer extension een uitbreiding moet zijn op een bestaand SBR entrypoint. Het moet mogelijk zijn om bepaalde relaties uit te zetten en om nieuwe relaties toe te voegen, maar het gaat de Taskforce te ver om rapporteurs te dwingen om een gehele taxonomie te maken indien slechts één concept toegevoegd hoeft te worden. De keuze van de taskforce is: optie twee.

2. Wijze van definiëren van begrippen in de preparer extension
Het definiëren van begrippen in een preparer extension kan op verschillende technische manieren gerealiseerd worden. De mogelijkheden zijn als volgt:

  1. Het definiëren van een nieuw element door middel van het element toe te voegen in een schema en er een (standaard) label aan toe te voegen dat het semantische begrip uitdrukt.
  2. Het definiëren van een nieuw element door middel van het element toe te voegen in een schema en verschillende labels toe te voegen die zowel het semantische begrip uitdrukt als een inhoudelijke definitie geeft van dit semantische begrip.
  3. Het definiëren van een nieuw element door middel van het element toe te voegen in een schema en er verschillende labels die zowel het semantische begrip uitdrukken als een inhoudelijke definitie geven van dit begrip, aangevuld met het opnemen van een of meer semantische relaties (direct of indirect) tussen het nieuwe element en een element uit de jaarverslaggeving taxonomie door de toepassing van een zogenaamde general-special definition link.

Overweging Taskforce: Op basis van ervaringen van andere landen is gebleken dat optie 1 en 2 niet voldoende zijn om de semantiek voldoende bruikbaar te definiëren. In de Verenigde Staten is het aanmaken van nieuwe concepten niet aan voorwaarden verbonden, hierdoor kunnen nieuwe concepten aangemaakt worden zonder dat de semantische betekenis duidelijk is. De keuze van de taskforce is: Optie 3. Dit is volgens de Taskforce de beste manier om begrippen te definiëren in een preparer extension. Deze optie zorgt ervoor dat via een gestructureerde relatie altijd een semantische betekenis meekrijgt zodat concepten geautomatiseerd verwerkt kunnen worden.

3. Wijze van aanroepen van de preparer extension vanuit het instance document
Er zijn verschillende mogelijkheden om de preparer extension aan te roepen vanuit het instance document, namelijk:

  1. Door middel van een schemaRef dat naar een nieuw preparer extension entrypoint verwijst, waarbij dit entrypoint vervolgens een bestaand SBR entrypoint importeert.
  2. Door middel van enkele linkbaseRefs naar linkbases die deel uitmaken van de preparer extension.
  3. Door middel van twee schemaRefs: één naar een bestaand SBR entrypoint en één naar een nieuw preparer extension entrypoint.

Overweging Taskforce: Het is wenselijk om zoveel als mogelijk aan te sluiten bij internationale praktijken, waardoor de keuze van de taskforce is: optie 1 . Daarnaast wordt optie 3 (twee schemaRefs) niet ondersteund door alle softwarepartijen en wordt optie 2 (linkbaseRef) in de praktijk nergens toegepast als methodiek voor preparer extensions.

4.Wijze van invulling van het preparer extension entrypoint
Het preparer extension entrypoint kan op verschillende manieren worden toegepast. Het entrypoint zal altijd moeten verwijzen naar een SBR entrypoint door middel van een import. De verdere invulling van het preparer extension entrypoint kan op twee manieren geschieden:

  1. Het preparer extension entrypoint bevat zowel de linkbaseRefs naar de presentation en definition linkbases van de preparer extension als de nieuwe elementen die door middel van de preparer extension zijn gedefinieerd.
  2. Het preparer extension entrypoint bevat uitsluitend de linkbaseRefs naar de presentation en definition linkbases van de preparer extension. Deze linkbases refereren op hun beurt weer door naar één of meer preparer extension schema(’s) waarin de nieuwe elementen zijn gedefinieerd.

Overweging Taskforce: Het is wenselijk om nieuwe elementen niet in een entrypoint op te nemen, maar in één of meerdere aparte schema’s (de keuze voor één of meerdere schema’s wordt in punt 8 besproken). Dit sluit het beste aan bij de bestaande NTA regels. Hierdoor viel de keuze van de taskforce in eerste instantie op optie twee. Tijdens de begin 2017 uitgevoerde pilot voor preparer extension is gebleken dat optie 1 door bestaande XBRL tools wordt ondersteunt, terwijl dit niet het geval is voor optie 2. Op basis van de uitkomsten van de uitgevoerde pilot met preparer extensions is de Taskforce van mening dat optie 1 de betere keuze is.

5. Wijze van toepassing van de preparer extension linkbases (relaties)
De preparer extension linkbases die relaties bevatten zijn de presentation en definition linkbases. In de toekomst komen hier naar verwachting ook formula linkbases bij. Het vraagstuk is hoe deze preparer extension linkbases toegepast dienen te worden. Hiervoor zijn twee opties:

  1. Alle verschillende soorten linkbases in één bestand plaatsen. Hierdoor worden de presentation, definition en formula linkbase samengevoegd in één bestand.
  2. Elk type linkbase in een apart bestand opnemen. Hierdoor zullen er aparte bestanden zijn voor de presentation, definition en formula linkbase.

Overweging Taskforce: Het is wenselijk om aan te sluiten bij de huidige NTA regels waarbij elk type linkbase in een apart bestand is opgenomen. De keuze van de taskforce is optie 2.

6. Wijze van toepassing van de preparer extension table linkbase
Bij de NT 12 zullen table linkbases meegeleverd worden welke gebruikt moeten worden voor het presenteren van een rapportage. Het vraagstuk is hoe de table linkbases toegepast dienen te worden in de preparer extensions. Hiervoor zijn twee opties:

  1. Een rapporterende partij de mogelijkheid geven om de tables aan te kunnen passen door middel van het opnemen van de table linkbase in de preparer extension.
  2. Geen mogelijkheid bieden tot het aanpassen van de tabellen Het ontwerp van de table linkbase dient in de NT dusdanig te zijn ontworpen dat de table linkbase automatisch uitgebreid wordt indien de presentation of definition linkbase aangepast wordt.

Overweging Taskforce: De table linkbases welke meegeleverd zullen worden bij de NT 12, worden gevoed door middel van presentation linkbases en definition linkbases. Hierdoor zal de tabel ook automatisch aangepast worden indien de presentation of definition linkbase aangepast wordt. Het aanmaken van nieuwe table linkbases wordt derhalve niet toegestaan. De Taskforce heeft daardoor een sterke voorkeur voor optie 2.

7. Wijze van invulling van de preparer extension linkbases (relaties)
Binnen presentation en definition linkbases worden zogenaamde Extended Link Roles (ELR’s) gebruikt om verschillende onderdelen van een rapportage technisch van elkaar te (onder)scheiden. In de NT wordt in het kader van herbruikbaarheid voor elke ELR een apart fysiek bestand opgenomen. Binnen een preparer extension kan dit op twee manieren ingevuld worden:

  1. Een apart bestand opnemen voor elke ELR die door de preparer extension geraakt wordt. Dit betekent dat indien er vijf ELR’s geraakt worden door de preparer extension deze alle vijf in vijf verschillende presentation linkbase bestanden en vijf verschillende definition linkbase bestanden worden opgenomen.
  2. Een bestand per type linkbase opnemen voor alle ELR’s die door de preparer extension geraakt worden. Dit zou betekenen dat indien er vijf ELR’s geraakt worden door de preparer extension deze alle vijf in één presentation linkbase bestand en in één definition linkbase bestand worden opgenomen.

Overweging Taskforce: In het kader van overzichtelijkheid is het wenselijk om niet een onevenredig aantal presentation en definition linkbase bestanden op te nemen in de preparer extension. Daarnaast speelt herbruikbaarheid van een preparer extension geen rol, zoals bij de NT. De keuze van de taskforce is : optie 2.

8. Wijze van invulling van de preparer extension schema of schema’s
Nieuwe elementen dienen in een of meerdere schema’s gedefinieerd te worden. In de NT wordt in het kader van herbruikbaarheid voor elk type element een apart fysiek bestand gehanteerd. Binnen een preparer extension kan dit op twee manieren ingevuld worden:

  1. Elementen worden per type in een apart schema gedefinieerd. Dit houdt in dat er meerdere preparer extension schema’s gedefinieerd worden, namelijk voor concepten, abstracte presentatie items, datatypes, tuples en domeinen en domeinleden.
  2. Alle elementen kunnen in één schema gedefinieerd worden in de preparer extension. Dit houdt in dat zowel nieuwe concepten, abstracte presentatie items, datatypes, tuples en domeinen en domeinleden in hetzelfde schema gedefinieerd worden.

Overweging Taskforce: In het kader van overzichtelijkheid is het wenselijk om niet een onevenredig aantal schemabestanden aan te maken. Daarnaast speelt herbruikbaarheid van een preparer extension geen rol, zoals bij de NT. Bovendien heeft het de voorkeur om niet een grote hoeveelheid bestanden te hoeven meeleveren bij een preparer extension, om mogelijke problemen tijdens de aanlevering te voorkomen. De keuze van de taskforce is: optie 2.

9. Wijze van invulling van de preparer extension label linkbases
Voor elk in de preparer extension gedefinieerd element dient altijd een standaard label en een documentation label opgesteld te worden. Voor de invulling van deze labels zijn twee opties te onderkennen:

  1. Bij elk element dient minimaal een Nederlandstalig label en een label in de taal van het instance document meegeleverd te worden.
  2. Bij elk element dient minimaal een label in de taal van het instance document meegeleverd te worden.

Overweging Taskforce: Het is volgens de Taskforce vooral van belang dat een label in de taal van het instance document meegeleverd wordt, aangezien dit de taal is waarin de rapportage zal worden bekeken. De keuze van de taskforce is: optie 2.

Daarnaast is de vraag in het kader van de invulling van de label linkbase hoe omgegaan dient te worden met de verschillende talen van de labels. Dienen deze in aparte of in hetzelfde linkbase bestand opgenomen te worden.

Overweging Taskforce: In lijn met de NTA is de Taskforce van mening dat labels in verschillende talen in verschillende bestanden moeten worden opgenomen.

Een aanvullend vraagstuk in het kader van de invulling van de label linkbase is hoe omgegaan dient te worden met de toepassing van andere labelrollen, zoals bijvoorbeeld terseLabel, verboseLabel of totalLabel. In de NT is vanuit het perspectief van hergebruik voor elke labelrol een aparte linkbase opgenomen. Voor de toepassing in preparer extensions zijn twee mogelijkheden te onderkennen:

  1. Per type label dient een apart bestand per taal opgenomen te worden
  2. De verschillende type labels kunnen per taal in hetzelfde bestand opgenomen worden.

Overweging Taskforce: De Taskforce is van mening dat de toegevoegde waarde om deze labelrollen in verschillende bestanden op te nemen beperkt is. De keuze van de taskforce is: optie 2.

10. Wijze van invulling van de preparer extension reference linkbases
Indien nieuwe concepten aangemaakt worden in de preparer extension, moet er een mogelijkheid zijn om daar een referentie aan te verbinden. Voor de invulling van de referenties zijn twee opties te onderkennen:

  1. Een referentie verplicht stellen voor elk nieuw item dat wordt aangemaakt.
  2. Een referentie optioneel maken voor de nieuw aangemaakte items.

Overweging Taskforce: De taskforce heeft besloten om de invulling van de reference linkbase niet verplicht te stellen, aangezien een reference niet altijd van toepassing zal zijn op een nieuw gedefinieerd element. Indien er een verwijzing kan plaatsvinden, wordt er aanbevolen om deze referentie op te nemen. De keuze van de taskforce is: optie 2. Daarnaast is de vraag in het kader van de invulling van de reference linkbase hoe omgegaan dient te worden met de verschillende soorten referenties welke meegegeven kunnen worden. Dienen deze in aparte of in hetzelfde linkbase bestand opgenomen te worden?

Overweging Taskforce: De Taskforce is van mening om de invulling van linkbases zoveel als mogelijk hetzelfde te houden. Zodoende is de voorkeur van de Taskforce om dit in hetzelfde bestand op te nemen.

Processen & Techniek

Indien preparer extensions aangeleverd worden, dienen deze geautomatiseerd verwerkt te kunnen worden. Hiervoor zijn twee nieuwe i-services benodigd ten opzichte van een aanlevering zonder preparer extensions. De inrichting van de processen als geheel is uitgewerkt in bijlage A.

Nieuwe i-services

De Taskforce vindt het belangrijk dat het aanleverproces i-services bevat voor de controle op de XBRL validiteit van de extensie taxonomie en naleving van de architectuurregels voor preparer extensions. Hiervoor zijn een tweetal nieuwe i-services gedefinieerd:

1. XBRL Taxonomie Validatie Service
De door de aanleverende partij ingestuurde taxonomie dient XBRL valide te zijn. Hiervoor is de XBRL Taxonomie Validatie Service ontwikkeld. Deze service valideert de extensie taxonomie door de extensie taxonomie inclusief bijbehorende linkbases in te laden in een XBRL processor en de taxonomie te toetsen ten opzichte van de relevante XBRL specificaties. In Figuur 3 is een nadere uitwerking opgenomen van deze i-service.

Horizontal alignment=center

Figuur 2: XBRL Taxonomie Validatie Service

2. Architectuur Controle Service
Een aangeleverde taxonomie dient ook te voldoen aan de architectuurregels voor preparer extensions, ook wel de Nederlandse Taxonomie Architectuur voor Preparer extensions (of NTA-PE) genoemd. De nieuwe Architectuur Controle Service controleert of de extensie taxonomie inclusief linkbases voldoen aan de architectuurregels voor preparer extensions. Deze regels zijn opgenomen in bijlage C. In Figuur 4 is een nadere uitwerking opgenomen van deze i-service.

Horizontal alignment=center

Figuur 3: Architectuur Controle Service

Bijlage A - Aanleveren van een jaarverantwoording met preparer extensions

In deze bijlage wordt de inrichting in de aanleverpoort besproken welke van toepassing is indien er een jaarverantwoording met preparer extension wordt gedeponeerd. Deze uitleg is specifiek gemaakt voor een aanlevering zonder SBR-verklaring. Voor de aanlevering met SBR-verklaring gelden dezelfde nieuwe processen als in de aanlevering zonder SBR-verklaring. Omdat de SBR-verklaring zelf geen onderdeel is van de preparer extension oplossing zijn deze specifieke processen niet verder uitgewerkt.

Invulling i-proces zonder SBR-verklaring

Het i-proces voor de aanlevering en verwerking van een instance document in combinatie met een preparer extension is weergegeven in Figuur 4 (in Bijlage B is een grote versie van deze figuur opgenomen). Als uitgangspunt voor de invulling van de processen en techniek inrichting is gekozen voor de standaard SBR i-procesconfiguratie voor het aanleveren van verantwoordingsrapportages. Deze i-procesconfiguratie zal worden uitgebreid met specifieke nieuwe services ten behoeve van aanvullende controles in het kader van preparer extensions.

Horizontal alignment=center

Figuur 4: Toekomstige aanleverproces voor het deponeren van de jaarrekening met preparer extensions zonder SBR-verklaring.

De verschillende i-services in het bovenstaande i-proces worden hieronder kort besproken:

Aanleverservice

De aanleverservice stelt vast of het verantwoord is een aangeleverd bericht te accepteren. De aanleverservice voert hiertoe de eerste essentiële controles uit, waarbij onder andere wordt gecontroleerd of het organisatie gebonden certificaat dat gebruikt is bij de aanlevering valide is. Ook wordt het aantal bijlagen van het bericht vastgesteld en wordt gecontroleerd of dit aantal voldoet aan het maximaal toegestane aantal bijlagen. Naast de controlefunctie heeft de aanleverservice tevens de taak om de aangeleverde berichten zeker te stellen. Deze service dient aangepast te worden zodat er meer bijlages bijgevoegd mogen worden.

Controle Consistentie Bijlage Service

Wanneer het bericht de aanleverservice succesvol heeft doorlopen, controleert de Controle Consistentie Bijlage Service of het bericht de berichtinhoud en de benodigde bijlagen bevat en dat deze overeenkomen met de gespecificeerde set van berichtinhoud en bijlagen. Berichtinhoud:

  • Jaarverantwoording instance document (.xbrl)

Bijlagen:

  • XBRL extensie entrypoint schema (.xsd)
  • Label linkbase(s) (.xml)
  • Presentation linkbase (.xml)
  • Definition linkbase (.xml)
  • Reference linkbase (.xml)
  • Formula linkbase (.xml)

XBRL Taxonomie Validatie Service

Na de consistentie bijlage service wordt de preparer extension taxonomie als eerste gevalideerd op de naleving van de XBRL specificaties in de XBRL Taxonomie Validatie Service. Tot op heden werden uitsluitend XBRL instance documenten gevalideerd ten opzichte van de relevante XBRL specificaties en taxonomie. Deze services maakt het mogelijk om dus ook een aangeleverde taxonomie te valideren. Meer details over deze nieuwe service is opgenomen in hoofdstuk 4.1.

Architectuur Controle Service

Wanneer een preparer extension taxonomie valide XBRL blijkt te zijn wordt de preparer extension taxonomie gecontroleerd op naleving van de architectuurregels voor preparer extensions (NTA-PE). Deze validaties vinden plaats in de Architectuur Controle Service. Meer details over deze nieuwe service is opgenomen in hoofdstuk 4.1.

XBRL Instance Validatie Service

Wanneer de extensie taxonomie inclusief haar linkbases voldoen aan de architectuurregels voor preparer extensions (NTA-PE), komt het instance document terecht bij de XBRL Instance Validatie Service. Deze service toetst het XBRL instance document ten opzichte van de relevante XBRL specificaties en de (extensie)taxonomie. Deze validatie vindt plaats door de instance te toetsen tegen de (extensie)taxonomie met de XBRL processor binnen de XBRL Instance Validatie Service. Deze service dient aangepast te worden zodat ook tegen de dynamische extensietaxonomie gevalideerd kan worden.

Afleverservice

Wanneer het bericht alle hiervoor beschreven controles heeft doorlopen komt het bericht tot slot terecht bij de afleverservice. De afleverservice ebMS 2.0 voor Overheden versie 1.2 levert de berichten af aan de uitvragende partij (KvK). Alleen valide berichten worden verstuurd. De afleverservice betreft het koppelvlak tussen de aanleverpoort en de uitvragende partij. Door het gebruik van ebMS wordt het op betrouwbare wijze hoogfrequent versturen van grote aantallen berichten gefaciliteerd.

Statusupdate Service

Nadat het bericht is afgeleverd bij de uitvragende partij houdt de Statusupdate Service ebMS 2.0 voor Overheden versie 1.2 de status van het bericht bij. Het doel van de Statusupdate Service is dat de aanleverende partijen geïnformeerd kunnen worden over de status van hun aanlevering. Deze service eindigt met de status dat een aangeleverd bericht door de uitvragende partij daadwerkelijk geaccepteerd is.


Bijlage B – I-proces voor het aanleveren van een jaarverantwoording met preparer extensions

Horizontal alignment=center

Vergroting van Figuur 2: Aanleverproces voor de deponering van jaarverantwoordingen met preparer extensions zonder SBR-verklaring.

Bijlage C – Architectuur regels voor preparer extensions

(Zie Excel bestand)

Persoonlijke instellingen
Naamruimten

Varianten
Handelingen
Navigatie
SBR Wiki's
Nederlandse Taxonomie en Architectuur
Processen en middelen
Body of Knowledge
Hulpmiddelen