NL2014517A - Werkwijze voor het genereren van een vragenlijst. - Google Patents

Abstract

De onderhavige uitvinding betreft een werkwijze en overeenkomstig programma op een informatiedrager en een computer, van het genereren van een vragenlijst uit een set voorschriften voor een te produceren document, welke voorschriften zijn gedefinieerd in een computertaal en zijn gedefinieerd in een met een computer leesbaar bestand. De werkwijze omvat: - het verschaffen van een eerste database met een configuratie op basis van concepten van de computertaal; - het doorlopen van het bestand en het in de eerste database verwerken van de voorschriften; - het verschaffen van een tweede database met een configuratie op basis van aspecten van de vragenlijst; en - het converteren van in de eerste database verwerkte voorschriften naar de aspecten van de vragenlijst en het in de tweede database verwerken van de geconverteerde voorschriften; - het interpreteren van geconverteerde voorschriften; en -het vertalen daarvan naar vragen voor de vragenlijst. De databases kunnen bij voorkeur relationele databases zijn.

Description

WERKWIJZE VOOR HET GENEREREN VAN EEN VRAGENLIJST

De onderhavige publicatie betreft een werkwijze, een daarop gebaseerd computerprogramma op een informatiedrager en een daarmee geladen computer. Voorschriften voor te genereren documenten, zoals verslagen, rapporten en belastingaangiftes zijn veelal gedocumenteerd in handleidingen en/of in met een computer leesbare bestanden, zoals XBRL bestanden. XBRL bestanden kunnen bestanden zijn, omvattende gecombineerde XML- en XSD-bestanden met een XBRL entrypoint om een begin aan te duiden van de samenhang.

Bij wijze van voorbeeld is hierin vaak verwezen naar fiscale taxonomie op basis van belastingregels, doch de onderhavige openbaarmaking is hiertoe geenszins beperkt, en andere voorschriften in bestanden voor te produceren documenten in het algemeen kunnen eveneens onderwerp zijn van de onderhavige openbaarmaking.

Het is in het gebied van het geautomatiseerd verzamelen van informatie van een gebruiker genoegzaam bekend, dat voorschriften kunnen veranderen, worden uitgebreid of ingekort.

Het was bekend om eenmalig en handmatig voorschriften te vertalen naar vragen van de vragenlijst. Echter, bij veranderingen of aanpassingen met betrekking tot de voorschriften met betrekking tot de te genereren documenten, werd de vakman geconfronteerd met een behoefte om de veranderde voorschriften van voren af aan te beginnen, en/of de aanpassingen en/of veranderingen weer handmatig terug te vertalen naar aanpassingen in de vragenlijst, zowel met betrekking tot de samenhang tussen de vragen, de sequentie van het doorlopen daarvan, en/of de inhoud daarvan, of met betrekking tot andere aspecten.

Het handmatig creëren van geheel nieuwe vragenlijsten is tijdrovend en goeddeels dubbel werk, als het aantal veranderingen en/of aanpassingen ten opzichte van een eerdere versie gering is. Het handmatig back-engineeren van aanpassingen in de vragenlijst is tijdrovend en foutgevoelig, aangezien door een vertaalslag van vragen naar te genereren document moet worden gewerkt naar aanpassingen in de lijst vragen. Überhaupt is zelfs het voor een eerste keer handmatig genereren van een vragenlijst tijdrovend en foutgevoelig. De facto kost het evenveel tijd, moeite inspanning en kosten om een vragenlijst voor een eerste keer te genereren, of om die aan te passen in het licht van veranderingen, uitbreidingen, inkortingen of andere, bij voorbeeld inhoudelijke wijzigingen, en wordt zelfs het voor een eerste keer extraheren van een vragenlijst op basis van de voorschriften ervaren als veel te tijdrovend en foutgevoelig, om op termijn levensvatbaar te kunnen zijn.

Een groot deel van de complexiteit van het bouwen van fiscale applicaties is het voldoen aan de volledige wet- en regelgeving die door de overheid wordt opgelegd. De opgelegde regels vergen zowel het implementeren van nieuwe aangiftesoorten, alsmede het actualiseren van reeds geïmplementeerde aangiftesoorten naar nieuwe j aren en in die nieuwe j aren te implementeren nieuwe of veranderde voorschriften, waarnaar ook wel wordt gerefereerd als fiscale taxonomie.

Er wordt groot technisch en commercieel belang gezien als het mogelijk wordt gemaakt dat het aanmaken en actualiseren van aangiftetypes ten minste grotendeels kan worden geautomatiseerd, bijvoorbeeld door gebruik te maken van door de overheid aangeleverde aangiftespecificaties, bijvoorbeeld fiscale taxonomie in met een computer inleesbare vorm zoals XBRL, hetgeen tegenwoordig een standaard lijkt te zijn.

De Nederlandse en veel buitenlandse fiscale taxonomieën bevatten normaal gesproken alle aangifteposten die voor Belastingdienst relevant zijn bij het insturen van aangifte van verschillende soorten. Dit houdt onder anderen in: teksten, verwijzing naar wetteksten en toegestane waardes.

De Nederlandse fiscale taxonomie is, net als veel buitenlandse fiscale taxonomieën, een verzameling van zogenaamde XML- en XSD-bestanden. Met de onderhavige openbaarmaking is een applicatie beoogd, bij voorbeeld een webapplicatie, met een grafische gebruikersinterface, om een gebruiker in staat te stellen aangiftes te doen. Hiertoe betreft de onderhavige openbaarmaking: een werkwijze van het genereren van een vragenlijst uit een set voorschriften voor een te produceren document uit een groep documenten, ten minste omvattende een verslag, een rapport en een belastingaangifte, welke voorschriften zijn gedefinieerd in een computertaal en zijn gedefinieerd in een met een computer leesbaar bestand uit een groep tenminste omvattende een XBRL bestand met fiscale taxonomie, welke werkwijze omvat: - het verschaffen van een eerste database met een configuratie op basis van concepten van de computertaal; - het doorlopen van het bestand en het in de eerste database verwerken van de voorschriften; - het verschaffen van een tweede database met een configuratie op basis van aspecten van de vragenlijst; en - het converteren van in de eerste database verwerkte voorschriften naar de aspecten van de vragenlijst en het in de tweede database verwerken van de geconverteerde voorschriften; - het interpreteren van geconverteerde voorschriften uit de tweede database; en - het vertalen van de geconverteerde voorschriften naar vragen voor de vragenlijst.

Deze opeenvolging van stappen maakt zowel initiële aanmaak van de vragen lijst om tot het gewenste document te kunnen komen, als aanpassingen, verandering, uitbreiding of inkorten daarvan in hoge mate te automatiseren, in tegenstelling tot de handmatigheid van de stand der techniek.

De onderhavige openbaarmaking kent, binnen het aldus gedefinieerde kader van de kern van de ontwikkeling, vele geprefereerde uitvoeringsvormen, waarvan er enkele aan bod komen in de gedetailleerde beschrijving hieronder, verwijzend naar de bij gevoegde tekening, en/of welke zijn gedefinieerd in ten minste één afhankelijke conclusie van de bijgevoegde set conclusies.

De eerste en/of tweede databases kunnen er één zijn uit de groep welke omvat een relationele database, een object database, een NOSQL database.

In een mogelijke uitvoeringsvorm kan de werkwijze de eigenschap vertonen dat het verschaffen van een eerste relationele database met een configuratie op basis van concepten van de computertaal omvat: het in of op een SQL server aanmaken van de eerste relationele database. In een dusdanige uitvoeringsvorm kan de werkwijze verder de eigenschap vertonen dat het in of op de SQL server aanmaken van de eerste relationele database omvat: het aanmaken van op basis van de in de computertaal bekende concepten aanmaken van kolommen en constraints daarvan in de eerste relationele database.

In een mogelijke alternatieve of aanvullende uitvoeringsvorm kan de werkwijze de eigenschap vertonen dat het doorlopen van het bestand en het in de eerste relationele database verwerken van de voorschriften omvat: het met een .NET console applicatie analyseren van de voorschriften in het bestand en het verwerken daarvan omvat het gestructureerd invoeren daarvan in de eerste relationele database. In een dusdanige uitvoeringsvorm kan de werkwijze verder de eigenschap vertonen dat het bestand een combinatie omvat van XML- en XSD-bestanden, met een XBRL entrypoint, welke een startpunt definieert voor het doorlopen van in het gecombineerde bestand gedefinieerde entiteiten, en waarbij het verwerken van de voorschriften omvat: het analyseren van de entiteiten en het daaruit destilleren van de voorschriften en het invoeren daarvan in kolommen en constraints daarvan in de eerste relationele database.

In een mogelijke alternatieve of aanvullende uitvoeringsvorm kan de werkwijze de eigenschap vertonen dat het verschaffen van een tweede relationele database met een configuratie op basis van aspecten van de vragenlijst omvat: het inrichten van de tweede database op basis van functionele eisen van ten minste één van de vragenlijst en het te genereren document.

In een mogelijke alternatieve of aanvullende uitvoeringsvorm kan de werkwijze de eigenschap vertonen dat het interpreteren van geconverteerde voorschriften uit de tweede relationele database en het vertalen van de geconverteerde voorschriften naar vragen voor de vragenlijst omvat: het toepassen van een .NET console applicatie op de geconverteerde voorschriften uit de tweede database, voor het genereren van de vragen voor de vragenlijst.

In een mogelijke alternatieve of aanvullende uitvoeringsvorm kan de werkwijze de eigenschap vertonen van het verwerken van de gegenereerde vragenlijst in een vragendatabase, en het aan een gebruiker presenteren van een opeenvolging van een selectie van vragen uit de vragendatabase, en het bepalen van ten minste één van de opeenvolging en de selectie van vragen op basis van ten minste één van een vooraf bepaalde prioriteit en antwoorden van de gebruiker.

In een mogelijke alternatieve of aanvullende uitvoeringsvorm kan de werkwijze de eigenschap vertonen van het interactief doorlopen van de vragen van de vragenlijst met een gebruiker, het innemen van input van de gebruiker, en het selecteren van achtereenvolgens te stellen vragen uit de vragen van de vragenlijst, en het genereren van het document op basis van daadwerkelijk doorlopen vragen van de vragenlijst en van de in reactie daarop door de gebruiker ingegeven informatie.

In een uitvoeringsvorm met een mate van interactiviteit kan de werkwijze verder omvatten: het genereren en exporteren van het document in een op voorhand bepaalde, met een computer leesbare taal uit een groep omvattende ten minste XBRL, met op doorlopen vragen uit de vragenlijst gebaseerde informatie van de gebruiker in een structuur in overeenstemming met de set voorschriften voor het te produceren document in de computertaal en in het oorspronkelijke, en met de computer leesbaar bestand.

Zoals reeds opgemerkt, betreft de onderhavige openbaarmaking tevens een informatiedrager met daarop opgeslagen een programma, dat, wanneer dat is geladen op een computer, is ingericht voor het genereren van de vragenlijst met de werkwijze waarnaar hiervoor is verwezen, of een computer, welke, wanneer daarop dat progamma is geladen, is geconfigureerd voor het genereren van de vragenlijst met de werkwijze waarnaar hiervoor is verwezen.

Hieronder zullen specifieke uitvoeringsvoorbeelden worden beschreven aan de hand van de bijgevoegde tekening, waarin gelijke of gelijksoortige elementen, componenten, functionele blokken en dergelijke kunnen zijn aangeduid met dezelfde referentienummer is, waarbij dient opgemerkt dat de onderhavige openbaarmaking op geen enkele wijze tot specifieke aspecten van de hiernavolgende beschrijving of de bijgevoegde tekening is beperkt en slechts kan worden beperkt op basis van specifiek gedefinieerde eigenschappen in de onafhankelijke conclusies van de bijgevoegde set conclusies en daarbij ook equivalenten of alternatieven van dergelijke specifiek gedefinieerde eigenschappen omvat. In de tekening toont: figuur 1 een schematisch aanzicht van een hybride representatie van de werkwijze en een systeem volgens de onderhavige openbaarmaking; en figuur 2 in combinatie met figuur 3 een schematisch aanzicht van op database techniek gebaseerde aspecten van de onderhavige openbaarmaking.

In figuur 1 is een schematische en hybride uitvoeringsvorm 1 getoond van een systeem onder toepassing van de werkwijze, beiden volgens de onderhavige openbaarmaking.

In de uitvoeringsvorm is gebaseerd op een XBRL bestand 2 met een XML deel 3 en een XSD deel 4. Het XML deel 3 en een XSD deel 4 kunnen afzonderlijke bestanden zijn, die gecombineerd kunnen worden aangemerkt als het XBRL bestand 2.

Het XBRL bestand 2 kan een van een aantal entrypoints 5, 6 bevatten, als startpunt voor lezen en of bewerken en/of verwerken. Het XBRL bestand 2 is te analyseren, mogelijkerwijs beginnend vanaf tenminste een van de entrypoints 5,6, hetgeen schematisch is aangeduid met de analyse lus 7.

Uit het XBRL bestand 2 is informatie te destilleren met betrekking tot structuur een configuratie, welke met schematische pijl 8 is in te brengen in een eerste database 9 om de eerste database 9 te prepareren voor het hierin opnemen van informatie uit het XBRL bestand 2, via pijl 10.

Een tweede database 11 is op soortgelijke wijze te prepareren op basis van structuur of configuratie informatie, die afkomstig is uit een vragenlijst 12 en/of een te genereren document 13 via pijl 16 en aan vragenlijst 12 en/of te genereren document 13 te stellen eisen of voorschriften.

De tweede database 11 wordt gevuld met voorschriften uit de eerste database 9, na conversie daarvan in of met behulp van convertor 14. Aldus geconverteerde voorschriften worden ingevoerd in de tweede database 11 via pijl 15. Aldus wordt aan de voorschriften uit de eerste database 9 een met de vragenlijst 12 of het te genereren document 13 samenhangende structuur of configuratie gegeven.

De aldus geconverteerde voorschriften worden via een interpretatie 17 en een vertaler 18 via pijl 19 gestuurd naar vragenlijst 12. De geconverteerde voorschriften uit de tweede database 11 worden aldus na interpretatie en vertaling via pijl 19 gevoerd naar de vragenlijst met een inherente of samenhangende structuur, die het mogelijk maakt om de vragen in de vragenlijst op een gestructureerde wijze te doorlopen, of selecties te maken uit de vragen in de vragenlijst 12 op basis van de structuur en/of configuratie daarvan en mogelijk zelfs op basis van door een gebruiker ingevoerde informatie als antwoord op de vragen uit de vragenlijst 12.

Voor de interactie met een gebruiker kan een invoer 20 zijn verbonden via dubbele pijl 21 met een besturing 22. De invoer 20 kan een beeldscherm omvatten, waar op vragen uit de vragenlijst 12 aan een gebruiker kenbaar worden gemaakt. De gebruiker kan de invoer 20 in ieder geval gebruiken om de gevraagde informatie aan de in figuur 1 getoonde uitvoeringsvorm 1 te verschaffen.

Selectie van vragen uit vragenlijst 12 staat onder de besturing van de besturing 22 via dubbele pijl 23, en tenminste door een gebruiker via invoer 20 verschafte informatie als reactie op de vragen uit de vragenlijst 12 wordt door die besturing 22 ingevoerd in een document 13, waarvan het genereren doel is van de onderhavige openbaarmaking, in het bijzonder als het gaat om de door de gebruiker te verschaffen informatie als reactie op de gestelde vragen uit de vragenlijst 12.

Aldus is het met de uitvoeringsvorm 1 volgens de onderhavige openbaarmaking mogelijk om vanuit een met een computer leesbaar bestand 2 een vragenlijst 12 te produceren en tevens eventueel een te genereren document 13 op te leveren, onder inachtneming van de in het met een computer leesbare bestand 2 gedefinieerde voorschriften hieraan.

Hieronder zal nader worden ingegaan op aspecten en eigenschappen, elementen, componenten en functionaliteiten van specifieke delen van de uitvoeringsvorm 1, onder verwijzing naar figuren 1, 2 en 3 gezamenlijk.

Hieraan voorafgaand wordt nog verder opgemerkt, dat een aantal te nemen tussenstappen moeten worden gezet om de vragenlijst 12 en/of het te produceren bestand 13 te kunnen genereren: 1. In Microsoft SQL Server wordt een relationele database 9, aangemaakt die wordt ingericht naar de concepten bekend in de taal XBRL van bestand 2. Dit wordt gedaan door eerst in de database 9 de benodigde tabellen en bij voorkeur alle voorzienbare benodigde tabellen met bijbehorende kolommen en hun constraints toe te voegen. Dit kan mogelijkerwijs een handmatig proces zijn, aangezien de daartoe vereiste handelingen mogelijkerwijs voorkennis vergen van de daadwerkelijke inhoud van de voorschriften. 2. De Fiscale taxonomie in met computer leesbaar bestand 2 wordt door een .NET console application zogenaamd ‘discovered’ naar deze relationele database 9: de informatie in deze XML bestanden 3 en XSD bestanden 4 wordt relationeel opgeslagen in database 9. Voor het “discoveren” van voorschriften of andere aspecten in een met computer leesbaar bestand 2 zijn in de techniek allerhande mogelijkheden beschikbaar, waarmee de vakman in het technische gebied uitermate goed bekend wordt geacht en verdere beschrijving van een dergelijk discover-proces wordt hier achterwege gelaten. De applicatie gaat in dit geval vanuit het ten minste ene XBRL entrypoint 5, 6 langs alle entiteiten in bestand 2 en slaat de relevante gegevens op. 3. Vervolgens wordt in SQL Server tweede relationele database 11 aangemaakt, ingericht naar de functionele eisen van de vragenlijst en/of het uiteindelijk te produceren document 13 (pijl 16). 4. Ten slotte wordt door een .NET console application een proces gestart die de relevante relationele fiscale taxonomiegegevens interpreteert in interpretator 17 en vertaalt in vertaler 18 van geconverteerde fiscale taxonomie uit de eerste database 9 naar de vragenlijst 12. De vragenlijst 12 kan op zichzelf een verdere database zijn. Voor het interpreteren en vertalen van de geconverteerde voorschriften of andere aspecten uit eerste database 9 zijn in de techniek allerhande mogelijkheden beschikbaar, waarmee de vakman in het technische gebied uitermate goed bekend wordt geacht en verdere beschrijving van een dergelijk interpretatie-en-vertaal-proces wordt hier achterwege gelaten.

Na stap 4 is er een primitieve vorm van een aangiftestappenplan met een opeenvolging van aan de gebruiker te stellen vragen in en/of uit de vragenlijst 12 ontstaan, waar enige gebruiksvriendelijkheid aan toe te voegen valt, maar welke in essentie al wel kan dienen als basis voor het definitieve stappenplan, met de garantie dat alle benodigde gegevens in ieder geval worden uitgevraagd van een gebruiker, wanneer vragen uit de vragenlijst 12 worden doorlopen. Omdat het stappenplan is opgebouwd vanuit de voorschriften in bestand 2, te weten bij voorbeeld de Nederlandse of andere buitenlandse Fiscale taxonomie, kan ook direct de daadwerkelijke aangifte (‘instance’) worden gegenereerd als mogelijke uitvoeringsvorm van het te genereren document. Hiervoor kan mogelijkerwijs een speciale XBRL-generator worden ontwikkeld, welke uit de door een gebruiker via invoer 20 ingevoerde informatie in staat is om een XBRL bestand te genereren, dat aan te merken is als te genereren document 13 in figuur 1. Voor een dergelijke XBRL-generator zijn in de techniek allerhande mogelijkheden beschikbaar, waarmee de vakman in het technische gebied uitermate goed bekend wordt geacht en verdere beschrijving van een dergelijke XBRL generator wordt hier achterwege gelaten

Bij het actualiseren van bestaande aangiftetypes wordt grotendeels dezelfde werkwijze gehanteerd, met het verschil dat een vergelijking wordt gemaakt tussen het bestaande stappenplan en de primitieve vorm van het nieuwe stappenplan en op basis hiervan de verschillen worden weggewerkt. Daartoe kan een bestaande vragenlijst 12 (eventueel in een aanvullende database) worden bewaard, om verschillen tussen een bewaarde en een nieuw te genereren vragenlijst 12 te kunnen analyseren, hetgeen proefondervindelijk kan gebeuren of middels een geautomatiseerde comperator.

Hierbij volgt een gedetailleerde omschrijving van de te nemen stappen om een nieuwe aangiftesoort en de benodigde instance te genereren.

Voor het aanmaken van de relationele discovery- of eerste database 9 ten behoeve van fiscale taxonomiegegevens, wordt eerst in Microsoft SQL Server en relationele database gemaakt met alle tabellen die nodig zijn om de fiscale taxonomiegegevens in op te slaan.

Om de fiscale taxonomie te verdisconteren is verder een analyse uitgevoerd om de juiste entiteiten met hun eigenschappen te identificeren en hiervoor de juiste tabellen met kolommen aan te maken. Zie voor een lijst van deze entiteiten met hun eigenschappen figuur 2. Voor verdere aangiftesoorten van dezelfde fiscale taxonomieversie kan deze indeling worden hergebruikt. Ieder jaar worden nieuwe versies van fiscale taxonomieën uitgebracht, hiervoor wordt een korte heranalyse gedaan om te ontdekken of een wijziging nodig is op deze database 9.

Het discoveren van de Nederlandse Fiscale taxonomie naar de Discovery database: de Nederlandse Fiscale taxonomie bestaat uit een verzameling van XML- en XSD-bestanden. Deze bestanden bevatten verwijzingen naar elkaar met behulp van zogenaamde XLINK’s, vergelijkbaar met hoe links werken in het HTML-protocol. Het oorsprongdocument van bestand 2, waar vanuit een hele aangiftesoort kan worden uitgelezen, wordt de entrypoint 5, 6 genoemd.

Met een .NET console application is deze entrypoint en al haar vervolgdocumenten te benaderen en te interpreteren. Dit wordt een discovery genoemd en de applicatie de Discovery Application. Aan het einde van het discoveryproces is de Discovery of eerste relationele database 9 ingevuld met alle fiscale taxonomiegegevens.

Voor het proces van discovery op zichzelf zijn vele tools beschikbaar en/of mogelijk, waarmee een discovery kan worden uitgevoerd. Echter, in het kader van de onderhavige openbaarmaking is het noodzakelijk om de gegevens na het discoveren te kunnen manipuleren om zo tot een eerste versie van een stappenplan te komen. Dit moet een herhaalbaar proces zijn om zo bij ieder aangiftetype en jaar dit op eenzelfde manier uit te kunnen voeren.

Voor het aanmaken van de relationele Items- of tweede database 11, dient een databaseschema, waar alle gegevens passen die nodig zijn om een stappenplan te presenteren en een instance genereren. De entiteiten van deze database zijn te zijn in figuur 3. Deze database en haar kolommen worden aangemaakt in Microsoft SQL Server. Desnoods is deze voorbereiding handmatig te verwezenlijken, maar geautomatiseerde executie heeft voorkeur.

Vervolgens volgt het omzetten van fiscale taxonomiegegevens naar de Items of tweede database 11. Hiertoe dient een applicatie, die een vertaalslag maakt van de fiscale taxonomiegegevens naar de items. Deze gebruikt de fiscale taxonomiegegevens uit de fiscale taxonomiedatabase, laadt deze in het geheugen en voert na enkele bewerkingen gegevens in, in de items of tweede database 11. Dit gaat als volgt:

Open de root Presentation abstract (een abstract is een niet-functionele groepering van andere Presentations, bijv. ‘Inkomsten uit werk en woning’), dus de Presentation met slechts children en geen parents/siblings.

Haal de children op van deze Presentation, door naar de ToID te kijken.

Voor iedere child, doe het volgende: o Als het een abstract betreft, voer dan deze stap opnieuw uit (recursief dus) o Als het een tuple betreft (een functionele groepering van andere Presentations, bijv. ‘Inkomsten eigen woning’):

Maak een tuple item aan in de items database

Bouw het eerste deel van het zgn. XBRL-pad op basis van de conceptnaam van de tuple

Haal alle children (dus child Presentations) op

Als het een tuple is, voer dan deze stap opnieuw uit (recursief dus)

Als het een abstract is, voer dan de abstract-stap uit

Anders, maak een item aan in de items database, neem hierin het opgebouwde XBRL-pad mee

Haal nu de tuple conceptnaam weer uit het XBRL-pad o Anders, maak een item aan in de items database, neem hierin het opgebouwde XBRL-pad mee

Bij het aanmaken van het item in de items of tweede database 11 wordt met het volgende rekening gehouden:

Voor het bepalen van het type van item, wordt gekeken naar het type van het Concept wat aan de Presentation is gekoppeld. Zo resulteert bijv. een ‘nl-types:monetaryNoDecimalsItemType’ in een ‘amount’ in Fiscaal Gemak.

Labels worden omgezet naar de teksten die gebruikt worden bij presentatie van de items References worden omgezet naar de teksten die gebruikt worden als uitleg van de items

Concept Types worden omgezet naar de toegestane waardes voor items. Bijvoorbeeld : Enumeration Types worden omgezet naar selectielijstjes, van MonetaryTypes wordt een type item gemaakt waar alleen bedragen mogen worden ingevoerd.

Hypercubes en Dimensions worden gebruikt om te kijken voor welke partij (bijv. declarant of partner) een post moet worden uitgevraagd.

Tevens wordt het XBRL-pad ingesteld op basis van hoe diep het item in de laag van Presentations zit. Als dus het item in een tuple zit, wordt het XBRL-pad: conceptnaam van tuple / conceptnaam van child Presentation.

Na deze stap is er sprake van een basaal stappenplan die verder kan worden verfijnd naar een gebruiksvriendelijk stappenplan.

Het verzamelen van daadwerkelijke aangiftegegevens om te verwerken in een aangifte of te genereren document 13 is aanzienlijk meer dan slechts een controle / verificatie van gegevens die zijn ingevoerd door een gebruiker, omdat, hoewel gebruikersinput inderdaad wordt inderdaad gevalideerd, de gebruikersinput ook wordt geïnterpreteerd en verwerkt in de belastingberekening.

Een verder onderdeel van de uitvoeringsvorm in figuur 1 is de besturing 22 of “engine”, die van het stappenplan een User Interface (UI) genereert, gebruikers-input valideert en berekeningen uitvoert.

Het stappenplan bestaat in vereenvoudigde zin uit groepen, sheets, specificaties en items. De besturing 22 of engine genereert van de groepen en sheets pagina’s waar de items als vraag of uitkomst op worden gegenereerd. De specificaties worden hier als pop-up met items tussen door gegenereerd.

Tijdens het doorlopen van het stappenplan word de door de gebruiker ingegeven informatie hierin verwerkt. Door middel van uit de fiscale taxonomie in het stappenplan opgenomen consistentie regels wordt door de besturing 22 of engine bepaalde vragen zichtbaar of juist onzichtbaar gemaakt op basis van al ingevoerde informatie van de gebruiker. Tevens worden er sub- en totaal tellingen berekend en wordt gekeken of bepaalde velden wel of niet zichtbaar moeten worden. Hieronder staan de belangrijkste componenten van de werking van de besturing als engine opgesomd:

Default Values: voor ieder item kan worden vastgelegd, wat de standaardwaarde is. Bijv. bij het jaarruimtejaar is dit het aangiftejaar.

DerivedValues: voor ieder item met de eigenschap calculated kan een derived value worden opgenomen. Hierdoor wordt door een set van variabelen, bijv. waardes van andere items in combinatie met fiscale regelgeving, bepaald wat de waarde van het item is. Het item IncomeTaxOwed heeft bijvoorbeeld een derived value waarin onder andere de waarde van het item IncomeBoxl wordt meegenomen, wat op haar beurt ook weer een derived value is, en waar uiteindelijk dus het te betalen bedrag aan belasting uit komt.

ErrorConditions: voor ieder item kan een error condition worden vastgelegd, hierbij wordt op basis van een set van variabelen bepaald of een item een foute waarde bevat. Bijvoorbeeld: totaal activa moet gelijk zijn aan totaal passiva.

GroupVisibleConditions: voor iedere groep kan worden vastgelegd of deze zichtbaar is. De groep verdeling is bijvoorbeeld alleen zichtbaar als er samen aangifte wordt gedaan en er te verdelen posten zijn.

OptionVisibleCondtions: voor meerkeuze-items kan voor iedere keuze een conditie worden gespecificeerd, bijv. energie-investeringsaftrek mag alleen worden gekozen als er geen sprake is van medegerechtigdheid

SheetErrorConditions: net als items, kunnen ook sheets een fout bevatten. Als bijv. op de sheet ‘Eigen woning’ overlappende hoofdverblijven zijn ingevuld, wordt hier een fout gegenereerd.

SheetVisibleConditions: bepaald of een bepaalde sheet wel of niet zichtbaar is. VisibleConditions: vele items zijn alleen in bepaalde gevallen zichtbaar, dat kan hier worden aangegeven.

Bij het openen van een aangifte of het navigeren door een aangifte wordt een refresh uitgevoerd. Dit gaat als volgt: haal alle groepen op die in deze aangifte zitten en pas de refresh toe op deze groep:

Check voor welke partijen deze groep van toepassing is (declarant en/of partner) en voer het volgende uit voor iedere partij

Check of de groep zichtbaar is (m.b.v. GroupVisibleConditions)

Check of de groep compleet ingevuld is

Haal alle sheets op die in de groep zitten en pas de refresh toe op de sheet: o Check voor welke partijen deze groep van toepassing is en voer het volgende uit voor iedere partij o Check of de sheet zichtbaar is (m.b.v. SheetVisibleConditions) o Check of de sheet een fout bevat (m.b.v. SheetErrorConditions) o Check of de sheet compleet ingevuld is o Haal alle items op die op de sheet staan en pas refresh toe op het item:

Check voor welke partijen de sheet van toepassing is.

Check of het item zichtbaar is (m.b.v. VisibleConditions)

Check of het item een berekende waarde heeft (m.b.v. DerivedValues)

Check of het item onzichtbare keuzes heeft (m.b.v.

OptionV isibleCondtions)

Check of het item een foute waarde bevat (ErrorConditions)

Check of het item een standaardwaarde bevat (DefaultValue)

Haal evt. alle sub-items op die bij dit item horen en voer bovenstaande uit voor deze sub-items.

Door middel van uit de fiscale taxonomie in het stappenplan opgenomen validatie regels wordt de ingevoerde informatie van de gebruiker direct gevalideerd en in de vorm van bijvoorbeeld meldingen naar de gebruiker terug gekoppeld.

Wanneer het stappenplan volledig is doorlopen kan er met de gebruikersinformatie en het uit de fiscale taxonomie gekomen stappen plan eenvoudig een XBRL instance gecreëerd worden door de besturing 22 of engine. Ontstane voordelen hierin zijn dat er geen conversie van data, aangifte gegevens nodig is tussen invoer hiervan door de gebruiker en verzending naar een afnemer, zoals de fiscus.

Voor het omzetten van aangiftegegevens naar een XBRL instance dient, nadat het stappenplan is ingevuld door de gebruiker, uiteraard de aangifte als uitvoeringsvorm van een te genereren document volgens de onderhavige openbaarmaking te worden ingezonden naar de Belastingdienst. Dit gaat in de vorm van een XBRL instance. De Nederlandse Fiscale taxonomie instructies ook instructies / voorschriften voor het opstellen van deze instance, en de wijze waarop deze moet zijn gestructureerd en geconfigureerd. Omdat het stappenplan is opgebouwd vanuit deze fiscale taxonomie, is alle benodigde logica voor het opstellen van de instance reeds beschikbaar. Het is mogelijk om een XBRL generator te maken, die deze logica kan interpreteren en op deze manier de instance kan genereren.

Voor een update van een gegenereerd aangiftestappenplan naar nieuwe j aren, omdat potentieel ieder j aar de wetgeving kan worden aangepast waaraan moet worden geconformeerd en bovendien er fiscale taxonomie wijzigingen kunnen optreden, is volgens de onderhavige openbaarmaking een gestructureerde manier mogelijk, waarmee de aangiftestappen kunnen worden geüpdatet. Hierbij kan als volgt te werk worden gegaan.

Allereerst worden alle posten van het stappenplan van het huidige jaar gekopieerd met het nieuwe jaar. Vervolgens passen we op geautomatiseerde wijze het versioningdocument toe wat wordt aangeleverd door de fiscus. Het versioningsdocument bevat alle wijzigingen die moeten worden uitgevoerd om het stappenplan geschikt te maken om een instance te kunnen genereren voor de nieuwe fiscale taxonomie versie die geldt voor het nieuwe jaar. Het is verder mogelijk om een applicatie in te zetten, waarmee dit versioningsdocument kan worden geïnterpreteerd en welke hiermee de wijzigingen uitvoert.

Voor het overige kan het updaten handmatig moeten gebeuren, immers moeten nieuwe en vervallen wetten worden nagelopen om te kijken wat de impact is op de aangifte. Er wordt echter wel een manier gehanteerd om zeker te weten dat alle wijzigingen zijn geïmplementeerd. Dit gaat als volgt: 1. Voer een discovery uit op de entrypoint van de nieuw te implementeren aangifte naar de eerste relationele discovery database 9. 2. Zet de relationele discoverydatabase 9 om naar een items of tweede database 11, hieruit volgt weer een nieuw basaal stappenplan. 3. Draai een vergelijking tussen het stappenplan volgend uit stap 2 en het gekopieerde stappenplan van het vorige j aar.

Door bovenstaande stappen te hanteren worden alle verschillen geïdentificeerd tussen het nieuwe en het oude jaar op fiscale taxonomiegebied, voor zowel nieuwe, vervallen en gewijzigde wetgeving.

Na kennisneming van de voorgaande gedetailleerde beschrijving van de ontwikkelingen volgens de onderhavige openbaarmaking, zullen zich vele aanvullende en alternatieve vormgevingen en uitvoeringsvormen, alsmede functionaliteiten en mogelijkheden aan de vakman opdringen, met inbegrip van aanvullingen en alternatieven voor eigenschappen welke zijn gedefinieerd in de bijgevoegde onafhankelijke conclusies, waarbij al deze aanvullende en alternatieve vormgevingen uitvoeringsvormen, alsmede functionaliteiten en mogelijkheden dienen te worden beschouwd als gelegen binnen de beschermingsomvang van de bijgevoegde conclusies en in het bijzonder de beschermingsomvang volgens de bijgevoegde onafhankelijke conclusies.

Claims (13)

1. Werkwijze van het genereren van een vragenlijst uit een set voorschriften voor een te produceren document uit een groep documenten, ten minste omvattende een verslag, een rapport en een belastingaangifte, welke voorschriften zijn gedefinieerd in een computertaal en zijn gedefinieerd in een met een computer leesbaar bestand uit een groep tenminste omvattende een XBRL bestand met fiscale taxonomie, welke werkwijze omvat: - het verschaffen van een eerste database met een configuratie op basis van concepten van de computertaal; - het doorlopen van het bestand en het in de eerste database verwerken van de voorschriften; - het verschaffen van een tweede database met een configuratie op basis van aspecten van de vragenlijst; en - het converteren van in de eerste database verwerkte voorschriften naar de aspecten van de vragenlijst en het in de tweede database verwerken van de geconverteerde voorschriften; - het interpreteren van geconverteerde voorschriften uit de tweede database; en - het vertalen van de geconverteerde voorschriften naar vragen voor de vragenlijst.

2. De werkwijze volgens conclusie 1, waarbij de database er één is uit een groep, welke omvat: een relationele database, een object database, een NOSQL database.

3. De werkwijze volgens conclusie 1 of 2, waarbij het verschaffen van een eerste database met een configuratie op basis van concepten van de computertaal omvat: het in of op een SQL server aanmaken van de eerste database.

4. De werkwijze volgens conclusie 3, waarbij het in of op de SQL server aanmaken van de eerste database omvat: het aanmaken van op basis van de in de computertaal bekende concepten aanmaken van kolommen en constraints daarvan in de eerste database.

5. De werkwijze volgens conclusie 1, 2, 3 of 4, waarbij het doorlopen van het bestand en het in de eerste database verwerken van de voorschriften omvat: het met een .NET console applicatie analyseren van de voorschriften in het bestand en het verwerken daarvan omvat het gestructureerd invoeren daarvan in de eerste database.

6. De werkwijze volgens conclusie 5, waarbij het bestand een combinatie omvat van XML-en XSD-bestanden, met een XBRL entrypoint, welke een startpunt definieert voor het doorlopen van in het gecombineerde bestand gedefinieerde entiteiten, en waarbij het verwerken van de voorschriften omvat: het analyseren van de entiteiten en het daaruit destilleren van de voorschriften en het invoeren daarvan in kolommen en constraints daarvan in de eerste database.

7. De werkwijze volgens ten minste één van de voorgaande conclusies, waarbij het verschaffen van een database met een configuratie op basis van aspecten van de vragenlijst omvat: het inrichten van de tweede database op basis van functionele eisen van ten minste één van de vragenlijst en het te genereren document.

8. De werkwijze volgens ten minste één van de voorgaande conclusies, waarbij het interpreteren van geconverteerde voorschriften uit de tweede database en het vertalen van de geconverteerde voorschriften naar vragen voor de vragenlijst omvat: het toepassen van een .NET console applicatie op de geconverteerde voorschriften uit de tweede database, voor het genereren van de vragen voor de vragenlijst.

9. De werkwijze volgens ten minste één van de voorgaande conclusies, verder omvattende het verwerken van de gegenereerde vragenlijst in een vragendatabase, en het aan een gebruiker presenteren van een opeenvolging van een selectie van vragen uit de vragendatabase, en het bepalen van ten minste één van de opeenvolging en de selectie van vragen op basis van ten minste één van een vooraf bepaalde prioriteit en antwoorden van de gebruiker.

10. De werkwijze volgens ten minste één van de voorgaande conclusies, verder omvattende het interactief doorlopen van de vragen van de vragenlijst met een gebruiker, het innemen van input van de gebruiker, en het selecteren van achtereenvolgens te stellen vragen uit de vragen van de vragenlijst, en het genereren van het document op basis van daadwerkelijk doorlopen vragen van de vragenlijst en van de in reactie daarop door de gebruiker ingegeven informatie.

11. De werkwijze volgens conclusie 9 of 10, verder omvattende het genereren en exporteren van het document in een op voorhand bepaalde, met een computer leesbare taal uit een groep omvattende ten minste XBRL, met op doorlopen vragen uit de vragenlijst gebaseerde informatie van de gebruiker in een structuur in overeenstemming met de set voorschriften voor het te produceren document in de computertaal en in het oorspronkelijke, en met de computer leesbaar bestand.

12. Een informatiedrager met daarop opgeslagen een programma, dat, wanneer dat is geladen op een computer, is ingericht voor het genereren van de vragenlijst met de werkwijze volgens ten minste één van de voorgaande conclusies.

13. Een computer, welke, wanneer daarop het progamma volgens de voorgaande conclusie is geladen, is geconfigureerd voor het genereren van de vragenlijst met de werkwijze volgens ten minste één van de voorgaande conclusies 1-10.