Versierapporten

Met behulp van de database is het mogelijk de wijzigingen bij te houden per oplevering.

Werkwijze

De versierapporten moeten worden opgesplitst per domein, dit o.a. omdat de financiering per domein wordt geregeld. Om deze rapporten zuiver te houden en niet te verwateren met hergebruikte objecten uit andere domeinen is het van belang om een strikte werkwijze er op na te houden.

De verschillende domeinen (SBR, KvK, Belastingdienst, BZK en OCW) worden allemaal apart aangeleverd ter controle.

Op het moment dat de validatie heeft gedraaid en de aanlevering is opgeslagen in de database is het tijd het versierapport te draaien. Dit moet je in elk geval doen voordat de volgende aanlevering wordt ingelezen.

SBR heeft geen entrypoints en kan geen eigen rapport draaien

NT16 naar NT17

alfa

Een voorbeeld ter illustratie. De complete NT16 is opgeslagen in de database en begin 2022 is de oplevering van de NT17 begonnen. Als eerste komt de SBR (alfa) taxonomie binnen, die kan alleen met XWand worden gevalideerd, want zoals gemeld er bestaat geen entrypoint voor deze taxonomie.

Al gauw komt de KVK met de alfa release, en die kunnen we in de toolkit valideren en opslaan in de database. Als je zo ver wilt gaan dat je van elke oplevering een versierapport wilt maken, dan is het nu tijd op die op te starten. Je kiest als run_id 'KVK', en je vergelijkt de NT17_alfa met de NT16. Er komen nu drie type rapport uit; 1. Een volledig rapport van de hele NT17_alfa ten opzichte van de NT16 2. Een domeinrapport, in dit geval de KVK 3. Een aantal entrypointrapporten

Het volledige rapport zal over-rapporteren op verwijderde objecten, dat is begrijpelijk, want er is pas een oplevering ingelezen in de NT17_alfa terwijl de NT16 compleet is. Dit euvel lost zich met het inlezen van de overige opleveringen vanzelf op.

Het domeinrapport zou direct al moeten kloppen, er van uit gaande dat het gehele domein in een oplevering plaatsvind, de belastingdienst wijkt hier van af, en zal zodoende ook op het domeinrapport teveel verwijderde objecten zien, totdat de gehele belastingdienst taxonomie is ingelezen.

Het laatste rapport klopt direct, met de aantekening dat het niet domeingefilterd is. (Dus nieuwe KVK objecten verschijnen op OCW entrypointraporten als die worden gevonden via een OCW entrypoint.)

Vervolgens komt bijv. de belastingdienst (BD) met haar taxonomie NT17 de alfa versie. Ook die valideer je en sla je op in de database. Vervolgens start je weer een versierapport, nu voor de BD NT16 naar NT17_alfa. Dit doe je zo voor alle opleveringen die komen, en telkens draai je daarna het versierapport met het juiste run_id, dat overeenkomt met het aangeleverde domein.

beta

Onderwijl begint ook de oplevering van de beta-versie. Ook nu komt SBR eerst, gevolgd door de KVK. De procedure is nagenoeg identiek, je valideert en slaat op in de database en draait een versierapport voor KVK NT16 NT17_beta. En elke volgende oplevering herhaal je dit weer met het correcte run_id.

Je kan nu, als daar behoeft aan is ook een rapport draaien tussen de NT17_alfa en de NT17_beta. Voor de registratie van de objecten is dat niet nodig, maar het geeft wel een beeld welke aanpassingen er doorgevoerd zijn naar aanleiding van het eventuele commentaar op de alfa versie.

Elke levering wordt vervolgens weer gevalideerd en opgeslagen en je draait telkens een versierapport [^1]

definitief

Ook nu volg je dezelfde procedure als bij de alfa-versie. En ook nu kan je extra rapporten draaien door de definitieve versie met zowel de alfa als de beta te vergelijken. Dit is wederom niet noodzakelijk voor correcte NT16-NT17 rapporten.

[^1] Het idee is om ook deze stap te integreren in de toolkit, zodanig dat na validatie en opslaan in de db ook het versierapport in vergelijking met de laatste definitieve versie wordt gemaakt.