LV-WOZ Diensten Conformiteitstoets en Externe testomgeving

LV-WOZ Diensten Conformiteitstoets en Externe testomgeving Versie 1.2 19 juni 2013

© Gouw informatie technologie bv 2013

Pagina 1 van 25

Versiebeheer Versie 0.1

Datum 16 mei 2012

Korte beschrijving aanpassing Creatie document, T.b.v. bespreking overleg 16 mei 2012

0.2

5 juni 2012

Verwerking opmerkingen (beoogde) meetestende leveranciers Geotax en PinkRoccade Toegevoegd: -

DigiKoppeling hoofdstuk

-

Integrale opname besluiten Driehoekoverleg

0.3

6 juni 2012

Versie voor het Klankbordgroepoverleg 15 juni

0.4

1 juli 2012

Versie zoals bedoeld in het PvA (zie acceptatiecriterium-2) Gecombineerd document voor Conformiteitstoets en Aansluittoets

0.5

1 oktober 2012

Aanvulling besluitenlijst met nieuwe besluiten Wijzigingen als gevolg van functionele test van CT functionaliteit

0.9

1 december 2012

Wijzigingen als gevolg van evaluatieoverleg met meetestende leveranciers en Waarderingskamer op 27 november Wijzigingen als gevolg van andere wijze van vergelijking synchronisatieberichten

1.0

20 december 2012

Eindversie naar aanleiding van acceptatietest Conformiteitstoets Fase 1. Als eindproduct voor de Ministerie van Financiën, Waarderingskamer en Kadaster.

1.1

6 mei 2013

Wijzigingen als gevolg van acceptatietest Conformiteitstoets Fase 2. Opname van OIN’s t.b.v. gemeentecode in scenario7 (herindeling).

1.1.1.

30 mei 2013

Lengte OIN t.b.v. gemeentecode in scenario7 gecorrigeerd van 16 pos. naar 20 pos.

1.2

19 juni 2013

Opname van requirements voor de werking van het StUFTestPlatform van KING.


Pagina 2 van 25

Inhoudsopgave 1 Doelstelling en uitgangspunten.......................................................................... 4 1.1 Doelstelling ............................................................................................... 4 1.2 Uitgangspunten ......................................................................................... 4 2 Diensten CTO/ETO en procesgang CT ................................................................. 6 2.1 Diensten CTO en ETO voor toetsen en testen ................................................. 6 2.2 Proces conformiteitstoets door leverancier of zelfbouwende gemeente ............... 7 2.3 Lijst gemeentecode per leverancier voor CTO en ETO .................................... 10 2.4 Proces hertoets bij gewijzigde WOZ-applicatie.............................................. 12 3 Digikoppeling................................................................................................ 13 3.1 Inleiding ................................................................................................. 13 3.2 Wat is Digikoppeling ? .............................................................................. 13 3.3 Aanwijzingen voor de softwareleveranciers en zelfbouwende gemeenten ......... 14 4 Besluiten driehoekoverleg StUF-WOZ 3.12 ........................................................ 16 5 Changemanagement conformiteitstoets ............................................................ 20 6 Foutcodes LV-WOZ ........................................................................................ 21 7 Contactinformatie en url’s............................................................................... 22 8 Bijlagen ....................................................................................................... 23 9 Wijzigingen beheerfase .................................................................................. 25 9.1 Wijziging 17 juni 2013 StUF-Testplatform .................................................... 25


Pagina 3 van 25

1 Doelstelling en uitgangspunten 1.1

Doelstelling

De gemeenten zijn bronhouders voor de Basisregistratie WOZ. Hiervoor moet een geautomatiseerde WOZ-applicatie worden gevoerd. Deze WOZ-applicaties voeden de Landelijke Voorziening WOZ (LV-WOZ), die gegevens verstrekt aan afnemers. De gemeenten kopen een WOZ-applicatie bij een leverancier of zij ontwikkelen deze zelf. Aan de kwaliteit van de gegevens worden hoge eisen gesteld. Daarom worden er – naast andere maatregelen – op de WOZ-applicaties twee ICT-kwaliteitscontroles uitgevoerd:  1. Conformiteitstoets door leverancier: toets van het volledige berichtenverkeer tussen de WOZ-applicatievan een leverancier of zelfbouwende gemeente en de LV-WOZ. 2. Aansluittoets door bronhouder: toets van de werking van het berichtenverkeer tussen een WOZ-applicatie in de infrastructuur van bronhouder en de LV-WOZ; toets van de kwaliteit van de WOZ-gegevens van de bronhouder op basis van criteria van de Waarderingskamer. Deze ICT-kwaliteitscontroles moeten ondermeer waarborgen dat gegevens in de WOZ-applicatie en de LV-WOZ gelijk blijven. Hiermee kunnen afnemers beschikken over betrouwbare gegevens. De conformiteitstoets wordt uitgevoerd met fictieve data, de aansluittoets met de echte gegevens van de bronhouder (volledige bestand). Voor de conformiteitstoets levert GouwIT de vereiste functionaliteit productierijp voor 18 januari 2013. Het testen van deze benodigde functionaliteit heeft plaatsgevonden in de periode oktober t/m november 2012. Het testen is gebeurd met actieve medewerking van: - PinkRoccade Local Government - Geotax - TOG - GouwIT Centric is betrokken geweest in het testtraject en de eindevaluatie op 27 november. Dit document fungeert tevens als basis voor de functionele acceptatie van de functionaliteit van de conformiteitstoets omgeving van de LV-WOZ (CTO). Het doel van dit document is hiermee: 1. Informatieverschaffing aan de softwareleveranciers en zelfbouwende gemeenten zodat door hen de nodige voorbereidingen kunnen worden getroffen voor een succesvolle conformiteitstoets. 2. Formele deliverable aan de opdrachtgever. De Waarderingskamer moet met dit document in staat zijn om als functionele beheerder van de LV-WOZ de taak als toetser en toezichthouder ter hand te nemen. Overal waar in dit document de term leverancier wordt genoemd, dient gelezen te worden als leverancier / zelfbouwende gemeente.

1.2

Uitgangspunten

1. Ten einde de aansluiting van leveranciers op de Landelijke Voorziening te vergemakkelijken hergebruikt de Conformiteitstoets de functionaliteit van het huidige StUF Testplatform van KING. 2. De toets richt zich primair op de conformiteit wat betreft het koppelvlak tussen de LV-WOZ en de bronhouder WOZ-applicatie inclusief de daarbij horende eisen uit het WOZsectormodel (zie www.waarderingskamer.nl onder Basisregistratie WOZ).


Pagina 4 van 25

3. Vergelijking soll-ist voor het afgeven van conformiteit aan de leverancier gaat plaatsvinden: 1. op berichtniveau voor de kennisgevingberichten. 2. op databaseniveau voor de synchronisatieberichten. In dit document wordt verder gesproken over deze twee soorten conformiteit middels CTKenn en CT-Sync 4. Er wordt getoetst door de Waarderingskamer of de WOZ-applicatie borgt dat de uitgaande berichten in de richting van de LV WOZ correct zijn ten aanzien van het werken met gebeurtenissen, formele historie en materiële historie conform de eisen van het RSGB (zie paragraaf 2.4.2. van https://new.kinggemeenten.nl/sites/default/files/bibliotheek/4690/RSG%20Basisgegevens %202.01%20%20deel%20I%20(in%20gebruik).pdf Let op: het gaat hier niet om het HOE maar het OF. Dat betekent: de goede gebeurtenissen moeten er uit komen en er moeten historische synchronisatieberichten uitkomen met correcte formele en materiële historie gegevens als tijdstip registratie en begin- en einddatum. 5. Er wordt niet getoetst of de WOZ-applicatie voldoet aan gemeentelijke eisen of aansluiting op gemeentelijke processen. 6. De WOZ-applicatie dient alle gebeurtenissen te ondersteunen gedefinieerd in de Catalogus WOZ-gegevens voor afnemers versie 1.6. 7. Alleen WOZ-applicaties die de conformiteittoets met goed gevolg hebben doorlopen, mogen bronhouders gebruiken voor de aansluittoets- en de productieomgeving van de LV-WOZ, respectievelijk ATO en PRD dienst.


Pagina 5 van 25

2 Diensten CTO/ETO en procesgang CT 2.1

Diensten CTO en ETO voor toetsen en testen

Het LV-WOZ systeem stelt twee hoofddiensten beschikbaar aan leveranciers: Dienst CTO = Conformiteitstoets omgeving Dienst ETO = Externe (vrije) test omgeving Binnen deze twee hoofddiensten zijn voor leveranciers beschikbaar de volgende diensten: CTO: webapplicatie individuele bevraging via MijnKadaster rapportage conformiteit t.b.v. CT-sync via MijnKadaster rapportage conformiteit t.b.v. CT-kenn via StufTestPlatform van KING (STP) ETO:

webapplicatie individuele bevraging via MijnKadaster webservice individuele synchrone bevraging rapportages

Hieronder volgen de specifieke kenmerken van de verschillende diensten: CTO:

voor uitvoering van (oefen)conformiteitstoets met vaste testscenario’s van Waarderingskamer (zie LV-WOZ sectie van www.waarderingskamer.nl) met persistentie eenmalige aanmelding bij [email protected] autorisatie door Kadaster, doorlooptijd is maximaal vijf werkdagen herhaling van toets naar behoefte zonder vooraf aanvraag bij kadaster bij herhaling dient eerst “geleegd” te worden middels dienstbericht in de StUF-WOZ berichtenstandaard alle communicatie voor (formele) toetsing verloopt altijd tussen Kadaster en de leverancier iedere leverancier heeft een fictieve gemeentecode toegedeeld gekregen

ETO:

voor ketentesten door leveranciers en (zelfbouwende) bronhouders met eigen testgegevens met persistentie grootte gegevensset wordt beperkt tot incidenteel 1.000 WOZ-objecten eenmalige aanmelding bij Kadaster, tegelijkertijd met CTO dienst aanvraag autorisatie door Kadaster, tegelijkertijd met CTO dienst aanvraag herhaling naar behoefte zonder vooraf aanvraag bij kadaster bij herhaling dient eerst geleegd te worden middels een specifiek dienstbericht in de StUF-WOZ berichtenstandaard iedere leverancier heeft een fictieve gemeentecode toegedeeld gekregen (identiek aan gemeentecode t.b.v. CTO)

Bovenstaande houdt dat de leverancier dient te beschikken over een STP-abonnement “Ad hoc testen + Scenariotesten “ (zie http://stuftestplatform.nl) De autorisatie die leveranciers maximaal mogen verkrijgen op de LV-WOZ is formeel vastgelegd in een autorisatiematrix. Deze is in te zien bij de Waarderingskamer op aanvraag. Leveranciers dienen zich voor iedere dienst afzonderlijk te laten autoriseren bij het Kadaster met het daarvoor beschikbaar gestelde formulier Aanmeldingformulier voor de beschikbare CTO diensten en ETO diensten (zie bijlage A). Bij aanmelding krijgt de leverancier een account voor de betreffende CTO en ETO diensten.


Pagina 6 van 25

Een belangrijke randvoorwaarde voor succesvolle aanmelding door de leverancier is dat de leverancier beschikt over een PKI-O en de benodigde CPA’s. Zie hierover verder in document in Hoofdstuk over Digikoppeling en de bijlage B. Na succesvolle aanmelding en aansluiting van de leverancier op de CTO en ETO dienst zal het Kadaster de leverancier en de Waarderingskamer hiervan inlichten. Tevens wordt van de leverancier bij aanmelding verwacht dat deze het convenant met KING en convenant Sectormodel met de Waarderingskamer heeft ondertekend: https://new.kinggemeenten.nl/document/convenant-betreffende-king-mantel-en-addendum-nupbouwstenen http://www.waarderingskamer.nl/default.aspx?sec=newsitem&id=841.

2.2

Proces conformiteitstoets door leverancier of zelfbouwende gemeente

Het testproces van de CT vindt plaats in de voorgeschreven volgorde en geheel zelfstandig door de leverancier (self-service): 1. Sturen van dienstbericht (opschonen van de database) door leverancier naar CT dienst LVWOZ 2. Uitvoeren van testscenario’s in het WOZ-systeem en sturen van de kennisgevingberichten naar CT dienst van LV-WOZ 3. Sturen van synchronisatieberichten voor de gehele inhoud van de database van de leverancier na het uitvoeren van de testscenario’s. 4. Ophalen testrapportage in StufTestPlatform met eventueel de verschillen tussen kennisgevingberichten van leverancier en referentieberichten van de Waarderingskamer 5. Ophalen testrapportage in MijnKadaster; deze rapportage toont eventuele verschillen tussen de database opgebouwd middels de kennisgevingberichten en de database opgebouwd middels de synchronisatieberichten. 6. Besluit formele conformiteit door Waarderingskamer De volgorde van de gehele toets (eerst dienstbericht om op te schonen, kennisgevingberichten en dan synchronisatieberichten) gaat ervan uit dat: - de WOZ-applicatie geen enkel WOZ-object bevat voordat begonnen wordt met versturen van de kennisgevingberichten; - de WOZ-applicatie de ingevoerde testgegevens persisteert (vastlegt in de eigen database) zodat er voor alle opgevoerde objecten synchronisatieberichten kunnen worden gestuurd; op deze wijze wordt de initiële vulling als het ware gesimuleerd doordat de gehele gemeentelijke database met synchronisatieberichten wordt geleverd aan de LV WOZ; - de WOZ-applicatie voor alle opgevoerde WOZ-objecten synchronisatieberichten kan verzenden voor een verantwoordelijke bronhouder; - de WOZ-applicatie zichzelf kan opschonen zodat – bij eventueel falen van de test – opnieuw begonnen kan worden; het ligt voor de hand dat bij succesvol verwerken van het dienstbericht door de LV-WOZ bij stap 1 de WOZ-applicatie ook zichzelf opschoont. De leverancier kan na autorisatie voor de CT dienst vrijelijk de conformiteitstoets oefenen zo vaak als gewenst. De leverancier meldt zich bij het Kadaster met de benodigde twee testverslagen zodra na eigen toetsing van het systeem, de verwachting bestaat dat de conformiteitstoets met goed gevolg kan worden afgerond. Het Kadaster zorgt voor doorzending van de testverslagen van de Waarderingskamer. De Waarderingskamer kan besluiten om alsnog bij een (her)uitvoering van de formele toets op locatie bij de leverancier aanwezig te zijn om te verifiëren of aan de uitgangspunten wordt voldaan. Bij het opstellen van de testscenario’s heeft de Waarderingskamer gebruik gemaakt van inbreng die door de bouwer van de LV-WOZ en de diverse leveranciers is geleverd. Hieronder is iedere processtap verder toegelicht.


Pagina 7 van 25

1. Test van dienstbericht t.b.v. Aansluitproces: Voor de Aansluittoets heeft de LV-WOZ de beschikking over de functionaliteit om via een specifiek dienstbericht een aansluittoets geheel geautomatiseerd te laten herhalen zonder tussenkomst van de beheerder van de LV-WOZ. Het dienstbericht vanuit de WOZ-bronhouder applicatie naar de LVWOZ zorgt voor complete opschoning van de WOZ-gegevens van de desbetreffende gemeente(code). Het dienstbericht zal alleen in de Conformiteitstoets (CTO), Aansluittoets (ATO) en Externe Testomgeving (ETO) geaccepteerd worden als geldig bericht. In Productieomgeving zal het aanbieden van dit dienstbericht leiden tot een foutmelding. In de CT wordt daarom getoetst of de leverancier op correcte wijze het dienstbericht verzendt. Tevens is het dienstbericht nodig om een CT opnieuw te oefenen en om de onderliggende database op te schonen van de – aan de leverancier – gekoppelde gemeentecode (zie verder in dit document voor de gekoppelde gemeentecode). Dit is ook de reden waarom er gestart dient te worden met versturen van dit dienstbericht. Dit is puur een procedurele afspraak en wordt niet gecontroleerd door de LV-WOZ. Zie voor de definitie van het dienstbericht de map Aansluitproces in de xsd-schema’s van StUFWOZ 3.12 op LV-WOZ sectie van de Waarderingskamer website. 2. Test van kennisgevingberichten: De leverancier moet alle berichten aan de LV WOZ leveren die behoren bij de standaard testscenario's. Met dit gedeelte van de toets wordt beoordeeld of het gebeurtenisgeoriënteerde werken correct is geïmplementeerd in het systeem. De output van het systeem moet overeen komen met vooraf gespecificeerde referentieberichten. Zie voorbeelden van deze referentieberichten de LV-WOZ sectie van de Waarderingskamer website onder Conformiteitstoets. Bij de conformiteitstoets worden in beginsel alle typen kennisgevingen getest. De toets bestaat eruit dat de leverancier in de te testen applicatie op basis van diverse scenario's "mutaties" aanbrengt in de het gemeentelijke bronbestand. Conform de gedefinieerde gebeurtenissen moeten deze mutaties leiden tot gebeurtenisgeoriënteerde kennisgevingen naar de LV-WOZ. De toetsing van de gebeurtenis georiënteerde kennisgevingen bestaat uit de volgende aspecten: - alle aangeleverde berichten moeten voldoen aan de schema validatie; - alle verwachte berichten moeten ook worden verzonden (volledigheid van de berichten); - de volgorde van de berichten moet overeenkomen met de in de scenario's aangegeven tijdlijn; - de inhoud van de berichten moeten overeen komen met de opgegeven scenario's. De door de leverancier aangeboden kennisgevingberichten worden door LV-WOZ gecontroleerd op xsd niveau en doorgestuurd naar het StufTestPlatform. Het STP beoordeelt volledig automatisch of alle kennisgevingberichten gelijk zijn de referentieberichten. Een bericht wordt afgekeurd indien het niet voldoet aan het xsd of als het niet voldoet aan het referentiebericht in het STP; hierbij wordt rekening gehouden met gegevens die mogen afwijken (zie onder bij punt 2). Indien het kennisgevingbericht voldoet aan de schema validatie en de aanvullende controles in de LV-WOZ, wordt het bericht verwerkt door de LV-WOZ en worden de gegevens opgeslagen in een separate LV-WOZ database alleen bedoeld voor kennisgevingberichten. Wanneer er sprake is van een afwijking van het referentiebericht moet de Waarderingskamer de mogelijkheid hebben te zeggen dat deze afwijking "geaccepteerd" is. Maar bij een geaccepteerde afwijking moet de Waarderingskamer kunnen beoordelen of synchronisatie volledig overeenkomt met de kennisgevingen. Daarom zullen ook kennisgevingen met een afwijking ten opzichte van de referentieberichten verwerkt moeten kunnen worden in de LV-WOZ. Vier specifieke zaken dienen nog opgemerkt te worden: 1. Alvorens de test te starten dient de leverancier in het StufTestPlatform (STP) een zogenaamd scenario token op te halen (een uniek gegenereerd nummer wat de test identificeert binnen het STP). Dit token dient in ieder kennisgeving en synchronisatiebericht opgenomen te worden. De wijze waarop dit dient te gebeuren is opgenomen in handleiding van StUF-TestPlatform (zie www.stuftestplatform.nl). 2. In de testreferentie gegevens is er zeer beperkt van variabele gegevens per leverancier. Iedere leverancier werkt in beginsel met exact dezelfde testgegevens (dus zelfde personen, percelen, adressen, bedrijven, etc.) maar met een eigen gemeentecode. Hiertoe zal de


Pagina 8 van 25

leverancier een gemeentecode toegewezen krijgen. Er dient dus exact gebruikt gemaakt te worden van de gegevens zoals deze in de scenario’s zijn benoemd (dus exacte straatnaam en exacte WOZ-waarde hanteren). Enkele uitzonderingen zijn toegestaan. Deze uitgezonderde gegevens zijn in de testscenario’s aangegeven middels een *, dat wil zeggen dat het gegeven bijvoorbeeld een door het systeem gegenereerd nummer mag zijn, wanneer systeem uitsluitend op deze wijze werkt. 3. Benodigde invoer van gegevens die uit andere basisregistraties komen (bijvoorbeeld GBA) moeten gesimuleerd worden als de bronhouderapplicatie zelf niet in staat is om deze handmatig op te voeren. Het – via de achterdeur – opvoeren van basisgegevens anders dan via een reguliere functionaliteit binnen het systeem, is aanleiding tot non-conformiteit. Indien de leverancier de procesapplicaties zelf in huis heeft om deze basisgegevens op te voeren dan bij voorkeur deze applicaties inzetten bij de conformiteitstoets en anders het bericht uit de basisregistratie simuleren. Dit geldt bijvoorbeeld ook indien de WOZapplicatie het nummer van het aanslagbiljetnr niet zelf bepaalt maar uit een ander systeem ontvangt! De leverancier is hierin geheel vrij. Kortom: gebruik tijdens de CT de reguliere functionaliteit binnen de eigen WOZ-applicatie om de benodigde percelen, BAG-objecten, personen, bedrijven op te voeren en te muteren. 4. Wanneer een leverancier een melding krijgt dat de aangeleverde kennisgevingen niet volledig overeenkomen met de referentieberichten, terwijl de leverancier van mening is dat de aangeleverde kennisgevingen goed aansluiten op de inhoudelijke specificatie van de scenario's, dan mag een leverancier aan de Waarderingskamer vragen of deze afwijking "geaccordeerd" kan worden. 3. Ophalen testrapportage in StufTestPlatform (STP): Door het aanbieden van de kennisgevingberichten die de leverancier verstuurt als gevolg van het uitvoeren van de testscenario’s in het eigen WOZ-systeem, zal het StufTestPlatform automatisch een vergelijking doen met de referentieberichten van de Waarderingskamer. Ieder (niet geoorloofd) verschil zal kunnen leiden tot een nonconformiteit. Dit is voor de leverancier zichtbaar te maken middels een testrapportage. De leverancier kan deze testrapportage ophalen door in te loggen met het eigen account op STP. De testrapportage is te herkennen aan het scenario-token zoals eerder door de leverancier is opgehaald uit STP. De testrapportage uit STP dient per email naar Kadaster verstuurd te worden zodra de leverancier een formele toetsing door de Waarderingskamer wil ondergaan. 4. Test van synchronisatieberichten. Het vierde deel betreft de werking van de synchronisatieberichten. Synchronisatieberichten spelen een belangrijke rol bij het aansluiten van gemeenten. Bij het uitvoeren van de conformiteitstoets moet het te testen systeem ook de synchronisatieberichten leveren die behoren bij de gespecificeerde scenario's. Deze synchronisatieberichten omvatten niet alleen de eindsituatie die in de registratie ontstaat na uitvoering van het gehele scenario, maar ook alle historie die immers ook in de LV WOZ bewaard moet worden. De toetsing van de historische synchronisatieberichten bestaat uit de volgende aspecten: - alle aangeleverde berichten moeten voldoen aan de schema validatie; - er moet sprake zijn van een consistente materiële historie (geldigheidsperioden aansluitend); - de database die wordt opgebouwd met behulp van de synchronisatieberichten moet exact overeenkomen met de database die ontstaat na verwerking van de kennisgevingen. Indien het synchronisatiebericht aan de schema validatie voldoet en het bericht wordt verwerkt door de LV-WOZ, worden de gegevens uit het synchronisatiebericht opgeslagen in een separate LVWOZ database alleen bedoeld voor synchronisatieberichten. 5. Ophalen testrapportage in MijnKadaster: Door het aanbieden van de synchronisatieberichten die de leverancier verstuurt na het uitvoeren van alle (!) testscenario’s, zullen alle WOZ-object gegevens in de synchronisatieberichten in de CT database worden verwerkt en opgeslagen. De leverancier kan door in te loggen met het eigen account op MijnKadaster een testrapportage genereren en ophalen. Deze testrapportage toont – na opgave van de juiste fictieve gemeentecode


Pagina 9 van 25

– alle verschillen die er zijn tussen de database waarin alle kennisgevingberichten zijn verwerkt en de database waarin de synchronisatieberichten zijn verwerkt. Ieder (niet geoorloofd) verschil zal kunnen leiden tot een non-conformiteit. Dit testverslag uit MijnKadaster dient per email naar het Kadaster verstuurd te worden zodra de leverancier een formele toetsing door de Waarderingskamer wil ondergaan. 6. Besluit formele conformiteit door Waarderingskamer: Er is afgesproken dat bij de beoordeling van de conformiteit ook altijd nog een inhoudelijke beoordeling door de Waarderingskamer plaats vindt. Wanneer alle aangeleverde berichten (rekening houdend met bovengenoemde uitzonderingen) overeenkomen met de referentieberichten zal deze inhoudelijke beoordeling beperkt zijn. Wanneer er andere verschillen zijn, zullen deze beoordeeld worden en waar nodig besproken worden met de betrokken leverancier (en eventueel andere partijen). Ook dan is het mogelijk dat het systeem "conform" verklaard wordt. De Waarderingskamer zal zelf in contact treden met de leverancier bij onduidelijkheden. De Waarderingskamer informeert het Kadaster bij positief resultaat binnen vier werkdagen na ontvangst van beide testrapportages over het definitieve resultaat van de formele toets. Het Kadaster communiceert dit door naar de leverancier middels email. Bij een positief besluit wordt tevens een conformiteitverklaring afgegeven door vermelding op de Waarderingskamer-website, zodat bronhouders en Kadaster hiervan op de hoogte kunnen zijn. Tevens zal de conformiteit worden gemeld aan de Softwarecatalogus van KING ten behoeve van het overzicht van "StUF-WOZ 3.12 conforme applicaties". De verklaring op de website en de email aan de leverancier luidt : De applicatie van met versienummer heeft op de conformiteitstoets voor het koppelvlak Landelijke Voorziening WOZ (LV WOZ) met goed gevolg afgerond. Vanaf genoemde datum mag deze applicatie worden gebruikt voor het aanleveren van gegevens aan de LV WOZ. Bij een negatief resultaat zal de Waarderingskamer hierover niets vermelden op de website, de leverancier inhoudelijke feedback geven en verzoeken om een spoedige hertoets. De leverancier kan hertoets uitvoeren op een moment naar eigen keuze.

2.3

Lijst gemeentecode per leverancier voor CTO en ETO

Iedere leverancier is – als “bronhouder” een fictieve gemeentecode toebedeeld. Voorzover de genoemde leverancier ook een BAG systeem heeft, zal deze gemeentecode hetzelfde zijn bij de WOZ. Daar waar een leverancier meerdere systemen conform wil laten verklaren dient bij de CT dezelfde gemeentecode gebruikt te worden. Tegelijkertijd toetsen van meerdere systemen door dezelfde leverancier is dus niet mogelijk en leidt tot problemen voor de leverancier. Zelfbouwende gemeenten gebruiken de eigen gemeentecode. OIN Leverancier Leverancier

Gemeentecode leverancier als bronhouder

GeoTax

5100

GouwIT

5300


Overnemen uit PKI-o certificaat leverancier Overnemen uit PKI-o certificaat leverancier

Nieuwe gemeentecode t.b.v. scenario7

5110

Fictieve OIN behorende bij Gemeentecode t.b.v. scenario7 (10 x 9 + 6 X 0 + gemeentecode t.b.v. scenario7) 99999999990000005110

5310

99999999990000005310

Pagina 10 van 25

Centric

5400

PinkRoccade

5500

Procura

5800

TOG

5900

Waarderingskamer

6000

Amsterdam

0363

Den Haag

0518

Overnemen uit PKI-o certificaat leverancier Overnemen uit PKI-o certificaat leverancier Overnemen uit PKI-o certificaat leverancier Overnemen uit PKI-o certificaat leverancier Overnemen uit PKI-o certificaat Waarderingskamer Overnemen uit PKI-o certificaat Amsterdam Overnemen uit PKI-o certificaat Den Haag

5410

99999999990000005410

5510

99999999990000005510

5810

99999999990000005810

5910

99999999990000005910

6010

99999999990000006010

99999999990000006011 6011 99999999990000006012 6012

Aangezien bij testscenario7 een object dient te wisselen van bronhouder (als gevolg van grenswijziging van gemeente en waterschapsgebied), is ook voorgeschreven welke gemeentecode de nieuwe verantwoordelijke bronhouder wordt bij het uitvoeren van de testscenario’s in het WOZsysteem van de leverancier. LET OP-1: het wisselen van verantwoordelijk bronhouder bij scenario-7 heeft tot gevolg dat bij het versturen van synchronisatieberichten dit object niet meegestuurd dient te worden. Er mogen dan immers alleen objecten gestuurd te worden waarvan de leverancier ook de actuele bronhouder is. Dit houdt in dat er een geoorloofd verschil moet (!) optreden tussen de database opgebouwd middels kennisgevingberichten en de database opgebouwd middels synchronisatieberichten. LET OP-2: bij het dienstbericht in stap 1 van de toets (opschonen database) dient altijd een gemeentecode meegegeven te worden. Aangezien er een object wisselt van verantwoordelijk bronhouder dient de leverancier twee maal een dienstbericht op te sturen. Dus Geotax zal bij de start van een CT zowel gemeentecode 5100 als 5110 dienen op te schonen. LET OP-3: Binnen de conformiteitstoets en externe testomgeving wordt er niet gecontroleerd op het feit dat de leverancier alleen de gekoppelde gemeentecodes mag opschonen; de Waarderingskamer heeft het vertrouwen dat leveranciers hier goed mee weten om te gaan. LET OP-4: Om een leegDatabase bericht te kunnen sturen, is er een naast de CPA voor de eigen gemeentecode ook een tweede (!) CPA nodig behorende bij deze gemeentecode van scenario7. Deze tweede CPA dient gemaakt te worden door de leverancier met de bijbehorende fictieve (!) OIN; deze OIN is NIET door Logius uitgedeeld, en dient ook uitsluitend gebruikt worden voor de Conformiteitstoets van de LV WOZ. Deze tweede CPA dient de leverancier bij aanmelding bij het Kadaster mee te leveren. Het Kadaster zal voor een leverancier dan twee klanten gaan opvoeren: eerste klant voor de leverancier zelf, en tweede klant voor de gemeentecode t.b.v. scenario7. LET OP-5: De gekoppelde gemeentecodes dienen ook gebruikt te worden in de ETO dienst. In de ETO kunnen leveranciers geheel eigen WOZ-objecten opvoeren tot een maximum van (incidenteel) 1000 stuks. Dit is een procedurele afspraak. De LV-WOZ software controleert hier niet op. Ook hier heeft de Waarderingskamer het vertrouwen dat de leveranciers hier goed mee weten om te gaan.


Pagina 11 van 25

2.4

Proces hertoets bij gewijzigde WOZ-applicatie

Indien de leverancier een nieuwe versie uitbrengt van de WOZ applicatie kan sprake zijn van een koppelvlakwijziging. Als dat het geval is dan zal de leverancier voor deze versie opnieuw conformiteit dienen te halen. Zie hiervoor 2.2. Als er geen sprake is van een koppelvlakwijziging zal de Waarderingskamer een quick scan doen van de releasenotes van deze nieuwe versie. De releasenotes moeten expliciet ingaan op mogelijke veranderingen in het koppelvlak en met welk koppelvlak de versie werkt. Indien in een versie van een WOZ applicatie alleen fouten zijn hersteld, dan zal er veelal geen nieuwe conformiteitstoets nodig zijn. De Waarderingskamer kan besluiten dat er een nieuwe conformiteitstoets moet plaatsvinden o.a. bij (verwachte) problemen in de communicatie met de LV-WOZ of in de betrouwbaarheid van de gegevens. Minor releases / patches met uitsluitend (!) kleine aanpassingen gericht op herstel van fouten behoeven geen hertoets. Dit dient in de release notes van de WOZ-applicatie expliciet opgenomen te worden zodat bronhouders hiervan op de hoogte zijn. De Waarderingskamer wordt niet op de hoogte te worden gesteld van minor releases / patches. Aanmelding: De leverancier zendt tijdig (tenminste vijf dagen voordat een gemeente een release gaat gebruiken) de releasenotes naar het Kadaster. Kadaster zorgt voor mobilisering van de Waarderingskamer. Toetsing: De Waarderingskamer toetst binnen vier werkdagen de releasenotes en beoordeelt of het koppelvlak niet is gewijzigd. Indien dit wel het geval is moet een nieuwe conformiteitstoets worden uitgevoerd, voordat deze release gebruikt mag worden voor aanleveren van berichten aan de LV WOZ. Verklaring: De Waarderingskamer informeert het Kadaster over het resultaat van de toetsing. Als de toetsing positief is, wordt binnen vier werkdagen na afronding een verklaring toetsing releasenotes afgegeven door een email vanuit Kadaster aan de leverancier en vermelding op de website van de Waarderingskamer. Indien toetsing niet positief is, dan geeft het Kadaster dit door aan de leverancier en wijzigt de bestaande vermelding op Waarderingskamer website niet. De afgegeven verklaring voor de desbetreffende vorige versie blijft gewoon staan. De verklaring in de email aan de leverancier en op de website van de Waarderingskamer luidt: brengt per een release uit van de met als versienummer . Deze release heeft naar verwachting geen gevolgen voor het koppelvlak met de LV WOZ. De eerder afgegeven verklaring van conformiteit voor versie blijft geldig.


Pagina 12 van 25

3 Digikoppeling 3.1

Inleiding

Het koppelvlak met de LV-WOZ maakt voor alle LV-WOZ diensten gebruik van de overheidsstandaard Digikoppeling. Leveranciers zullen voor het uitvoeren van de conformiteitstoets over een eigen Digikoppeling (ebMS) adaptor dienen te beschikken. Dit hoofdstuk is bedoeld als startpunt/informatiebron voor de leveranciers. Er kunnen geen rechten worden ontleend aan de informatie in dit hoofdstuk.

3.2

Wat is Digikoppeling ?

Deze paragraaf is ontleend aan de thans uitgevoerde impactanalyse DigiKoppeling door KING. Digikoppeling bestaat uit een set standaarden voor elektronisch berichtenverkeer tussen overheidsorganisaties en in het bijzonder basisregistraties. Als overheidsorganisaties deze standaarden implementeren in hun eigen software, kunnen zij eenvoudig digitaal berichten uitwisselen met collega-overheidsorganisaties. De standaarden zijn eind 2007 goedgekeurd door het College Standaardisatie en zijn inmiddels al bij veel organisaties in gebruik. Digikoppeling onderkent twee hoofdvormen van berichtenverkeer:  Bevragingen (WUS); een vraag waar direct een reactie op wordt verwacht. Hierbij is snelheid van afleveren belangrijk. Als een service niet beschikbaar is, dan hoeft de vraag niet opnieuw worden aangeboden.  Meldingen (ebMS); men levert een bericht en pas (veel) later komt eventueel een reactie terug. In dat geval is snelheid van afleveren minder belangrijk. Als een partij even niet beschikbaar is om het bericht aan te nemen, dan is het juist wel gewenst dat het bericht nogmaals wordt aangeboden. Het betreft hier dus feitelijk berichtuitwisseling met gegarandeerde berichtlevering. NB. Meldingen worden vooral gebruikt om informatie tussen systemen uit te wisselen. Om de uitwisseling van elektronische berichten op basis van Digikoppeling veilig te laten verlopen wordt gebruik gemaakt van PKI Overheidscertificaten met een OIN (Overheid Identificatie Nummer). Een en ander kan als volgt worden weergegeven:

Figuur 1 - Schematische weergave Digikoppeling Voor verdere toelichting op Digikoppeling wordt verwezen naar documentatie op de Logius website1 danwel naar de toelichting op de NORA op de site van de elektronische overheid2. Digikoppeling is een belangrijk onderdeel van het stelsel van Basisregistraties. Samen met Digilevering , Digimelding en de Stelselcatalogus, vormen zij de stelselvoorzieningen Basisregistraties.

1

http://www.logius.nl/producten/gegevensuitwisseling/digikoppeling/

2

http://www.e-overheid.nl/


Pagina 13 van 25

LV-WOZ en Digikoppeling implementatie Uitgangspunt is dat de koppeling zal worden gerealiseerd op basis van Digikoppeling ebMS. (Bevragen op basis van Digikoppeling WUS). Ook de uitvoering van de conformiteitstoets en de aansluittoets verloopt via digikoppeling.

3.3

Aanwijzingen voor de softwareleveranciers en zelfbouwende gemeenten

Voor het toepassen van de Digikoppeling Koppelvlakstandaard ebMS zijn CPA contracten nodig. Met het Digikoppeling CPA Creatie programma wordt een CPA of CPA-template gemaakt op basis van een Digikoppeling-ebMS Servicespecificatie en een Digikoppeling-ebMS Consumerspecificatie. Zie verder https://www.cpa.serviceregister.overheid.nl CPA staat voor Collaboration Protocol Agreement. Een CPA is een formeel xml-document om de gebruikte functionele en technische eigenschappen van de ebMS-protocolkarakteristieken vast te


Pagina 14 van 25

leggen. Het is dus een formele beschrijving voor het vastleggen van de gegevensuitwisseling. Zie detail informatie: http://www.logius.nl/producten/gegevensuitwisseling/digipoort/koppelvlakken/ebms-20-vooroverheden/ Alle LV-WOZ services zijn gepubliceerd op https://serviceregister.overheid.nl. Via Logius kan de toegang tot dit register worden aangevraagd. Hiermee verkrijgt de leverancier tevens een eigen OIN (op basis van het Handelsregisternr) ten behoeve van testdoeleinden. Bij de implementatie van Digikoppeling tbv LV-WOZ zijn de volgende profielen van belang: 1. Digikoppeling 2.0 2W-be- S (2 weg SSL best effort met signing) voor WUS 2. Digikoppeling 2.0 2W-rm-S (2 weg SSL reliable messaging met signing) voor ebms Er zijn -

out-of-the-box oplossingen op de markt voor DigiKoppeling aansluitingen: OpenTunnel van JNet, zie www.jnet.nl Enable-U, zie www.enable-u.nl GemNet, zie www.gemnet.nl

Zie stappenplan aanmelden DigiKoppeling Logius: http://www.logius.nl/producten/gegevensuitwisseling/digikoppeling/


Pagina 15 van 25

4 Besluiten driehoekoverleg StUF-WOZ 3.12 Aangezien StUF-WOZ 3.12 een jonge standaard is, zijn er bij de uitwerking van de LV WOZ enkele aandachtspunten voor toepassing van StUF-WOZ 03.12 beschreven. Nr 1

2

Onderwerp Maximaal aantal antwoorden bij synchroon vraag/antwoord Berichtsoorten te gebruiken bij initiële vulling.

Besluit In 1 antwoord worden maximaal 25 stuks terug gestuurd.

Gebruik van 100% synchronisatieberichten actief vanuit de bronhouder. Na initiële vulling kan bronhouder nog steeds actief (zonder verzoek om synchronisatie van uit de LV-WOZ) een synchronisatiebericht sturen. Uitgangspunt bij synchronisatieberichten is dat bronhouder geen historie vanaf 2009 weggooit. Bij gebruik synchronisatieberichten steeds eerst subjecten, dan sluimerende WOZ-objecten, dan reguliere WOZ-objecten en dan waardes; geen controle op deze volgorde maar wel de afgesproken werkwijze. Geen losse mutaties mogelijk van platgeslagen gegevens. Dus hernoemen van woonplaats levert net zoveel mutaties op als er objecten zijn. Waarderingskamer stelt nader vast welke eisen gelden bij aansluiting van een bronhouder. De inhoudelijke eisen gelden alleen voor actuele situatie en niet voor de historie van een object.

3

Platgeslagen entiteiten

4

Controles door LV-WOZ op aangeleverde actuele en historische gegevens

6

Correcties in historie

7

Noodzakelijkheid aanvulling sofinr

8

Historie van gerelateerde gegevens

9

Historie van InOnderzoek

10

Beheer StUF-WOZ package op waarderingskamer.nl en kinggemeenten.nl/gemma

Met de gedefinieerde dienstberichten (gebeurtenissen) kunnen mutaties (en correcties) worden aangebracht in de actuele gegevens. Correctie kan ook betekenen een verschuiving van de ingangsdatum. Correcties in het verleden zijn inderdaad niet toegestaan. Dat gaan we dan ook niet toestaan. Voor correcties in historische gegevens is synchronisatie de enige weg. We gaan wanneer de LV WOZ volledig gevuld draait wel monitoren of dit veel voorkomt en of deze synchronisatie problemen oplevert voor afnemers. Nu is binnen de Stuf-WOZ bestanden de combinatie SoFi-nummer / aanvulling SoFi-nummer de unieke sleutel. Binnen de LV WOZ bestaat die unieke sleutel uit: inp.bsn, anp.identificatie, inn.nnpId, ann.identificatie of vestigingsNummer. Zodra de LV WOZ helemaal draait wordt uitsluitend met deze sleutel gewerkt. Zolang er nog Stuf-WOZ bestanden worden gemaakt is ook de sleutel SoFi-nummer / aanvulling SoFi-nummer nog relevant. Wanneer we stoppen met StufWOZ bestanden, gooien we aanvulling SoFi-nummer weg. SoFi-nummer blijft als "inhoudelijk attribuut" bestaan. Van gerelateerde gegevens uit bijvoorbeeld de GBA of het Handelsregister in de WOZ helemaal geen historie wordt bijgehouden. Dus bij synchronisatie van gegevens worden bij subjectgegevens alleen de actuele stand geleverd. StUF3 ondersteunt volledige materiële en formele historie en uit de specificaties moet blijken voor welke attributen materiële en/of formele historie van toepassing is. Dit betekent dat wanneer bijvoorbeeld het kenmerk gebruikscode van 1 oktober 2013 tot 1 december 2013 in onderzoek heeft gestaan dat bij een synchronisatie (inclusief historie) op 1 april 2014 deze periode met status "in onderzoek" ook wordt geleverd, ook wanneer het onderzoek niet heeft geleid tot een mutatie van de gebruikscode. Omdat StUF3 ook formele historie ondersteunt, worden in de synchronisatie (inclusief historie) ook tijdvak correcties volledig meegenomen, dus ook: op 1 november 2013 is geregistreerd dat de gebruikscode vanaf 13 oktober 2013 de waarde 12 heeft. Op 1 december 2013 is geregistreerd dat de gebruikscode al vanaf 1 december 2012 de waarde 12 heeft. De Waarderingskamer is uitsluitend verantwoordelijk voor het package StUFWOZ zoals gepubliceerd op de eigen site en niet voor packages die door andere partijen ooit zijn gepubliceerd.

11

Controles op geometrie WOZ-object

Er zijn, anders dan schemavalidatie, geen controles voorzien op geometrie. Het toevoegen van geometrie aan bestaande objecten kan altijd later met


Pagina 16 van 25

12

Tussentijdse wijzigingen belanghebbende/relatie perceel

13

Zoeken in archief

behulp van "MKEN" gebeurtenissen. Ook tussentijdse wijzigingen van belanghebbenden moeten geleverd worden, analoog aan de huidige wijze van levering van Stuf-WOZ bestanden. Hierbij moet je ook iedere wijziging op 20-record, 30, 40 etc niveau leveren ongeacht of deze wijziging een nieuwe beschikking of een statuswijziging van de beschikking ten gevolg heeft. Er is en zal geen functionaliteit komen in het Kadaster archief om specifiek op (bijv) WOZ-objectnr te zoeken. Het kadaster archief kan op gegevens als datum bericht of bronhouder worden gerubriceerd. Bij het testen van de LV-WOZ (CT of AT toets) zal naar verwachting wel vaker het archief ingezien moeten worden. Kadaster (Business) biedt een werkproces wat zij doen voor de Waarderingskamer indien berichten zoek raken of indien de rechtmatigheid in het geding is. Als er gezocht moet worden in het achief dan kan de Waarderingskamer aankloppen bij het Kadaster ([email protected]) met gegevens waarnaar gezocht moet worden: - bronhouder - tijdsperiode - eventueel gedetailleerdere info.

14

Aanvulling sofinr

Huidige werkwijze blijft specifiek voor Aanvulling SoFi-nummer gehandhaafd bij fusies en herindelingen van gemeente, dwz: hernummeren verplicht (zie ook 7). Opnemen bij beschrijving van aanvullende controle van aanvulling sofinr.

15

Massale mutaties en StufWOZ bestanden, bijvoorbeeld bij woonplaatswijzigingen of conversies van bronhoudersystemen.

Zowel bij massale wijzigingen BINNEN hetzelfde bronsysteem als massale wijzigingen die gepaard gaan met conversie van ene naar andere bronhoudersysteem dienen deze wijzigingen op reguliere wijze naar de LVWOZ gestuurd te worden. (Mis)gebruik van synchronisatieberichten moet ontmoedigd worden.

16

Doorlevering van synchronisatieberichten aan DigiLevering

18

inOnderzoek

19

Is apart (StUF) Bv01 bevestiging bericht nodig naast een ebMS bevestiging bij juiste ontvangst asynchrone kennisgevingberichten van de bronhouder

We gaan ervan uit dat het complete synchronisatiebericht naar DigiLevering wordt gestuurd. We mogen niet verwachten dat DigiLevering hierbij filtert op actueel/historie bij de doorlevering aan de afnemers. Een afnemer ontvangt dus het gehele synchronisatiebericht zoals gestuurd door de bronhouder. Een afnemer moet er dan zelf voor kiezen om de formele/materiële historie eruit te filteren en hiermee zelf niet meer copy-conform te zijn. inOnderzoek is een regulier gegeven, geen metagegeven, dus wijziging van inOnderzoek leidt tot nieuw tijdvak. Voor inOnderzoek is materiële historie gedefinieerd. Besluit: Het blijft bij de ebMS bevestiging en geen aparte Bv0x bericht retour.

20

Gebruik van certificaten en koppelen van berichten aan bronhouder

Dit zijn allemaal afzonderlijke berichten. De Grote Berichtenstandaard wordt alleen toegepast bij het bevragen van de LV-WOZ en niet bij het aanleveren van bronhouder aan de LV-WOZ.

Advies is om het bronhouderwerkproces zodanig in te richten dat: 1.

Tussentijdse, nieuwe mutaties op hetzelfde WOZ-object (gedurende tijd dat het asynschrone kennisgevingbericht onderweg is naar verwerking in de LV-WOZ) niet geblokkeerd hoeven te worden in de bronhouderapplicatie.

2.

Eventuele latere door de LV-WOZ geretourneerde foutmeldingen bij het verwerken van het asynschrone kennisgevingbericht op hetzelfde WOZ-object procesmatig op te pikken door de bronhouderapplicatie.

Alle berichten die worden uitgewisseld met de LV WOZ worden verzonden/ ontvangen via digikoppeling. Bij het gebruik van digikoppeling wordt gebruik gemaakt van PKI-O certificaten om verzender/ontvanger te kunnen identificeren. Gemeenten (bronhouders) wisselen in toenemende mate informatie uit via een intermediair (bijvoorbeeld een samenwerkingsverband of een ingehuurde dienstverlener). Voor de gegevenslevering door een dergelijk samenwerkingsverband aan de LV WOZ, gebruikt het samenwerkingsverband een eigen certificaat. Op basis van dit "digikoppeling certificaat" kan dus niet


Pagina 17 van 25

altijd worden vastgesteld wie de bronhouder is. Voor het kunnen uitwisselen van kennisgevingen tussen bronhouder (samenwerkingsverband) en LV WOZ via digikoppeling moeten CPA's worden vastgelegd in het digikoppelingsserviceregister. De CPA is opgezet volgens het ebms 2.0 Digikoppeling profiel osb-rm. Dit houdt in dat de berichten verstuurd worden met een betrouwbaar profiel. Het partyId (OIN) in de CPA en ebMS bericht identificeert de bronhouder. Deze OIN (partyID) in de EbMS header moet daarbij ook steeds dezelfde identificatie zijn als in het StUF bericht wordt genoemd als StUF:zender. Het TLS certificaat waarmee de beveiligde HTTPS sessie wordt opgezet identificeert de zender. De zender mag dus ook een andere partij zijn dan de bronhouder, bijvoorbeeld een samenwerkingsverband. De zender wordt herkend aan de hand van de OIN van deze partij in het certificaat. Omdat het OIN van de bronhouder als partyID vastligt in de CPA moet een samenwerkingsverband voor elke bronhouder waarvoor gegevens worden aangeleverd afzonderlijk een CPA vastleggen in het register. De identiteit en autorisaties van zowel afzender als bronhouder worden meegenomen in de verwerkingsstappen binnen de LV-WOZ. De aanleverende partij wordt herkend op basis van het OverheidsIdentificatienummer (OIN) of Handelsregisternummer (HRN). Dit OIN of HRN van de zender wordt gekoppeld aan de OIN van de bronhouder, waarmee meteen in de LV-WOZ ook de gemeentecode bekend is. Op basis van deze gemeentecode wordt door de LV-WOZ gecontroleerd of het WOZ object gemuteerd mag worden door deze bronhouder.

23

Onduidelijkheid toekomstmutaties

24

Volgorde van berichten voor subjecten

25

Dienstbericht specificatie om te legen Ondersteuning eHerkenning

26

27 29

Vervallen Vergelijking documentnr in CT

30

Tijdstipregistratie

31

Foutmelding vanuit LV-WOZ als gevolg van volgorde problemen


Voor Vraagberichten wordt ook één certificaat gebruikt, maar is opnemen van de CPA’s van de bronhouders niet aan de orde. Hier is enkel sprake van het autoriseren en authenticeren van de zender (vrager) zelf op transportlaag niveau. WOZ-sectormodel gaat een ontwerpbeslissing LV-WOZ bevatten die : omschrijft wat een toekomstmutatie is in de context van StUF-WOZ dat toekomstmutaties niet worden geaccepteerd door LV-WOZ Zie verder het aangepaste WOZ-sectormodel (hoofdstuk Ontwerpbeslissingen LV-WOZ) WOZ-sectormodel gaat een ontwerpbeslissing LV-WOZ bevatten die omschrijft in welke volgorde berichten van subjecten gestuurd dienen te worden naar de LV-WOZ Zie verder het aangepaste WOZ-sectormodel (hoofdstuk Ontwerpbeslissingen LV-WOZ). Het dienstbericht om bij een aansluittoets de LV-WOZ database te legen, gaat onderdeel uitmaken van de berichtencatalogus van de Waarderingskamer. Vooralsnog geen ondersteuning door LV-WOZ van eHerkenning. De afspraak is gemaakt met de leveranciers om de eerstkomende twee jaar geen stelselwijzigingen door te voeren in de LV-WOZ functionaliteit. Brondocumentid hoort een volledig unieke aanduiding te zijn per bronhouder. Voor de hand ligt dat dit door systeem gegenereerd wordt / gaat worden. Besluit is dat documentnr een door het WOZ-systeem gegenereerd nummer mag zijn. Tijdstipregistratie dient gevuld te worden met datum en tijd op het moment dat de registratie in het WOZ systeem wordt gedaan. Dus niet een ander moment zoals het maken van het bericht in het WOZ-systeem (die veel later kan liggen). Dit dicteert overigens de StUF3 standaard. Indien de tijd tussen twee opeenvolgende berichten dusdanig lang was dat de LV-WOZ tot afkeuring is overgegaan (bijvoorbeeld opvoeren WOZ-object die nodig is voor verwerken nieuwe beschikking), zal het bronsysteem een keuze hebben om het betrokken WOZ-object via een synchronisatiebericht te laten synchroniseren met de LV-WOZ OF door alsnog de afgekeurde berichten in juiste volgorde aan te leveren. Leveranciers en Waarderingskamer hebben allen de voorkeur uitgesproken voor de laatste optie. Dit geeft namelijk voor

Pagina 18 van 25

34

datumEindeSynchronisatie

35

StUF070 en Stuf058 foutbericht bij synchronisatieberichten

36

Nieuw testscenario formele historie opbouw

37

Zoeken via BAG-relaties


de afnemer de meeste duidelijkheid doordat er gebeurtenis georiënteerd geleverd blijft worden. Bij synchronisatieberichten wordt de afnemer belast met uitzoekwerk/overlast. Voor het WOZ-systeem (en wellicht ook de WOZbeheerder van de gemeente) kan dit wel extra logica/werk betekenen. Bij toevoegen van een subject – als medebelanghebbende – dient een datumEindeSynchronisatie ingevuld te zijn met de waarde 1-1-<jaar beschikking>+1. Er is namelijk geen mogelijkheid om een medebelanghebbende af te melden. datumEindeSynchronisatie verplicht toevoegen aan msub bericht. StUF070 bij asynchroon berichtenverkeer ook mogelijk maken: Er is geen aanpassing nodig in StUF3 standaard. WK doet wijzigingsvoorstel aan community voor aanpassing StUF3standaard. WK vult foutcodelijst voor StUF-WOZ aan met specifieke foutcodes voor asynchroon berichtenverkeer. Indien StUF3 wel aangepast is in de toekomst, dan vervallen de specifieke foutcodes in de LV-WOZ foutcodes lijst. Een nieuw scenario9 is inmiddels opgenomen in nieuwe testscenarioset van 30 november. Dit scenario is bedoeld voor de juiste opbouw van formele historie. Zie website WK. isVerbondenMet en heeftPand zijn inmiddels toegevoegd aan StUF-WOZ xsd om met name in de webapplicatie van LV-WOZ zoeken via BAG-relaties mogelijk te maken

Pagina 19 van 25

5 Changemanagement conformiteitstoets Uitgangspunten bij changemanagement van de conformiteitstoets zijn: 1. De functionaliteit van de conformiteitstoets is gekoppeld aan de volgende standaarden die voor de wijze van communicatie tussen bronhouders, LV-WOZ en afnemers van belang zijn: a. Een versie van de LV-WOZ, startend met 1.0 b. Een versie van CT-scenario’s, startend met 1.0 c. Een versie van de Catalogus WOZ-gegevens voor afnemers versie, startend met versie 1.6 d. Een versie van het WOZ-sectormodel, startend met 3.12. e. Een versie van StUF-WOZ, startend met 3.12. f. Een versie van StUF, startend met 3.01 g. Een versie van StUF-BG, startend met 3.10 h. Een versie van GML, startend met versie 3.1 i. Een versie van Stuf-WOZ (bestanden), startend met versie 4 2. De bedoeling is dat bij iedere versie van de LV-WOZ (x.x.x) het bovenstaande rijtje opnieuw wordt gecommuniceerd, zodat volstrekt helder is welke versies van de standaarden worden ondersteund. 3. Leveranciers worden met de ETO dienst in staat gesteld om zich voor te bereiden op een nieuw LV-WOZ koppelvlak. De ETO dienst zal twee maanden eerder dan de CTO, ATO en PRD dienst worden voorzien van de nieuwe LV-WOZ release. Dit is echter niet verplicht, de ETO is immers een vrije/vrijblijvende testomgeving.


Pagina 20 van 25

6 Foutcodes LV-WOZ Leverancier (maar ook bronhouders) kunnen op diverse niveaus foutcodes geretourneerd krijgen: 1. ebMS niveau (Digikoppeling) 2. xsd niveau (StUF-WOZ 3.12) 3. LV-WOZ niveau Foutcodes ebMS niveau Deze foutcodes zijn gedocumenteerd op: http://www.jnet.nl/nl/opentunnel/documentatie http://www.jnet.nl/contents/uploads/opentunnel/4_10.ot-errorcodes.pdf Foutcodes xsd en LV-WOZ niveau Deze foutcodes zijn gedocumenteerd op: http://www.waarderingskamer.nl/documents/lv%20woz%20controles%20en%20foutcodes.pdf De hierin vermelde foutcodes zijn resultaat van de gedefinieerde controles die op 15 juni 2012 zijn gepubliceerd via het Klankbordgroepoverleg WOZ-berichtenverkeer. Sindsdien zijn hier geen wijzigingen meer op gekomen sindsdien.


Pagina 21 van 25

7 Contactinformatie en url’s Waarderingskamer Contact Waarderingskamer Waarderingskamer LV-WOZ sectie

: :

[email protected] www.waarderingskamer.nl (Home > Basisregistratie WOZ > LV-WOZ)

Kadaster KCC Klanten Contact Centrum Kadaster

:

[email protected] of 088 1834300 www.kadaster.nl/woz

LV-WOZ CTO en ETO diensten URL CTO - aansluiting URL ETO - aansluiting URL ETO - individuele synchrone bevraging MijnKadaster

: : : :

service30.kadaster.nl/lv-woz-cto/ebms/ service30.kadaster.nl/lv-woz-eto/ebms/

StufTestPlatform (STP)

:

www.stuftestplatform.nl Inclusief handleiding voor het gebruik van een executietoken in STP en aanmaken van de LV-WOZ conformiteitstoetsrapportage

Zelftestende gemeenten

:

Gemeente Amsterdam Dhr. Joep van Gessel Afdeling dienst belastingen Postbus 23475 1100 DZ Amsterdam Zuidoost Telefoon: 020 6524340 Email: [email protected]

service30.kadaster.nl/lv-woz-eto/wus/ https://mijn.kadaster.nl

Gemeente Den Haag Dhr. Hindrik Jongeling Gemeentelijke belastingdienst Postbus 19924 2500 CX ’s-Gravenhage Telefoon: 070-3533840 Email: [email protected]


Pagina 22 van 25

8 Bijlagen A. Web-aanmeldingformulier voor de beschikbare LV-WOZ CTO en ETO dienst aan Kadaster, zie op www.kadaster.nl/woz : https://www.kadaster.nl/web/formulier/WOZ-formulieren/Aanmelding-conformiteitstoetsLV-WOZ.htm

B. Aansluiten op LV-WOZ via Digikoppeling als ondersteuning voor de uitvoering van de Conformiteitstoets voor leveranciers en zelfbouwende gemeenten.


Pagina 23 van 25


Pagina 24 van 25

9 Wijzigingen beheerfase 9.1

Wijziging 17 juni 2013 StUF-Testplatform

Wijziging van de werking van het StUF-Testplatform naar aanleiding van Topdesk melding 1305 285 (leverancier TOG) en het hierop volgend overleg met de Waarderingskamer, GouwIT en JNet op 17 juni. Requirement 1 Een stp-scenarioregel wordt door STP altijd beoordeeld op goed (=conform) of fout (=niet conform), waarbij een fout NIET leidt tot een retour Fo01 foutmelding maar tot een waarschuwing in het STP verslag; een waarschuwing uit zich als een ! in het STP verslag. Requirement 2 Bij een waarschuwing stuurt STP het bericht door naar LV WOZ om daar geprocessed en na controle opgeslagen te worden. In de LV WOZ kan uiteraard alsnog het bericht als gevolg van de aanvullende lv woz controles leiden tot een Fo01 melding, bijvoorbeeld: WOZ-object bestaat niet. Requirement 3 De in STP ingestelde StUF3 - testregels kunnen nog wel leiden tot een Fo01 meldingen en daarmee wordt het bericht NIET aan LV WOZ doorgegeven en krijgt de leverancier een kruisje (=niet conform) in het STP verslag. Samenvatting 1 of meer kruisjes leiden automatisch zonder enige discussie tot non-conformiteit en bij 1 of meer waarschuwingen kan de leverancier verder met de scenario's, maar zal de WK alsnog achteraf beoordelen op basis van het STP verslag of er sprake is van conformiteit of non-conformiteit.


Pagina 25 van 25

LV-WOZ Diensten Conformiteitstoets en Externe testomgeving

Recommend Documents