Wijzigingsdocument RGT Fase 2

Wijzigingsdocument RGT Fase 2

Inhoudsopgave 1. Inleiding... 3 1.1. Algemeen... 3 1.2. Versiebeheer... 3 2. Functionele Wijzigingen... 5 2.1. Algemeen... 5 2.2. APK Gebrekenlijst (Datastructuur)... 5 2.3. APK Processen (Berichtenverkeer)... 6 2.4. Cusum-klassen (Berichtenverkeer)... 6 3. APK Gebreken - Tabeldefinitie en XMLmode... 7 3.1. Impact Structuur Gebrekentabel... 7 3.1.1. Wijzigingen... 7 3.2. Impact APK-Processen... 7 3.2.1. Wijzigingen... 7 3.2.2. Layout... 7 4. APK - Processen en XMLmode... 10 4.1. Impact XMLmode wsapk... 10 4.1.1. Wijzigingen... 10 4.1.2. Layout berichten... 10 5. Cusum-klassen - Processen en XMLmode... 11 5.1. Impact XMLmode wsapk... 11 5.1.1. Wijzigingen... 11 5.1.2. Layout OpvragenKIgegevens... 11 5.1.3. Layout OpvragenKMgegevens... 12 5.1.4. Layout WijzigenKMgegevens... 13 5.2. Impact XMLmode wslp... 14 5.2.1. Wijzigingen... 14 5.2.2. Layout Opvragenkeurmeestergegevens... 1514 5.2.3. Layout WijzigenKMgegevens... 16 6. XMLmode Opschoning APK/LPG/TA... 18 6.1. Impact XMLmode wsapk... 18 6.2. Impact XMLmode wslp... 18 6.3. Impact XMLmode wsta... 18 7. Testen via Acceptatieomgevingen... 19 7.1. Tijdlijn en Planning... 19 7.2. Testuitvoering... 19 7.2.1. Testomgeving... 19 7.2.2. Authenticatie... 19 7.2.3. Testset... 20 7.2.4. Testuitvoering... 20 7.2.5. Testbevindingen... 20 Wijzigingsdocument RGT Fase 2 v1_1.doc 2/20

1. Inleiding 1.1. Algemeen Dit document is bestemd voor leveranciers van Dealer Management Systemen die via XMLmode van VWE RDW-dienstverlening afnemen. Beschreven zijn de gevolgen van wijzigingen in de VWE Diensten die optreden naar aanleiding van een tweetal overheidsmaatregelen: Aanpassing en uitbreiding van de APK-gebrekentabel Vervallen van de Cusum-klassen van Keuringsinstanties en Keurmeesters Daarnaast beschrijft dit document een opschoonslag : de buiten-dienststelling van oude versies van berichten, die niet langer ondersteund worden in de processen APK, LPG en Tachograaf na de wijzigingen van 01-01-2017 en 01-04-2017. De indeling van het document is als volgt: Hoofdstuk 2 Functionele beschrijving van de wijzigingen. Hoofdstuk 3 Beschrijving van de aanpassingen in de betrokken tabellen en webservices in XMLmode voor de APK Gebrekenlijst Hoofdstuk 4 Beschrijving van de aanpassingen in de betrokken webservices in XMLmode voor de APK-processen Afmelden Goedkeuringen, Afkeuringen en Opvragen Goedkeuring en Afkeuring. Hoofdstuk 5 Beschrijving van aanpassingen in de betrokken webservices in XMLmode voor de Cusum-klassen Hoofdstuk 6 Beschrijving van opschoning van buiten-gebruikgestelde versies van webservices/methoden Hoofdstuk 7 Aanwijzingen voor het testen van de aanpassingen in onze Acceptatie-omgevingen. Hebt u vragen, dan kunt u die stellen aan Eric Gouw, eric.gouw@vwe.nl. 1.2. Versiebeheer Versie Datum Wijzigingen Auteur 1.0 15-01-2017 Eerste versie Eric Gouw 1.1 xx-02-2017 Enkele correcties in de voorbeeldberichten Nadere aanvulling STATUS-CUSUM-ST Pinpasnummers Keurmeesters gewijzigd Eric Gouw Toelichting Versiebeheer Versie 1.0 In deze versie zijn de wijzigingen opgenomen die de RDW per 01-04-2017 doorvoert in de Gebrekentabel van APK in het kader van het Risicogestuurd Toezicht (RGT) Fase 2. Daarnaast worden in deze versie worden de aanpassingen beschreven die in de APK-processen nodig zijn voor het toepassen van de nieuwe Gebreken en Gebrekenstructuur Tenslotte geeft deze versie de wijzigingen die in de berichten worden aangebracht n.a.v. het vervallen van de Cusum-klassen. Versie 1.1 In deze versie zijn enkele correcties in de voorbeeldberichten opgenomen: Niet-gebruikte tag CKMBevoegdheid verwijderd Deze tag is vanuit het genereren van het voorbeeldbericht ten onrechte meegekomen. STATUS-CUSUM-ST De indicator geeft voor een Keuringsinstantie PER ERKENNING aan of deze zich in de Gevarenzone bevindt. Wijzigingsdocument RGT Fase 2 v1_1.doc 3/20

De Pinpasnummers bij de beschikbare Keurmeesters zijn gewijzigd Wijzigingsdocument RGT Fase 2 v1_1.doc 4/20

2. Functionele Wijzigingen 2.1. Algemeen De RDW vindt dat het huidige toezicht onvoldoende Risico Gestuurd is en dat het toezicht op de uitgevoerde APK keuring (steekproef) meer gericht moet zijn op de minder presterende Keuringsinstanties (KI s) en Keurmeesters (KM s). Hiervoor is in 2015 fase 1 opgestart en afgerond. Fase 2 borduurt hier op verder en vraagt aanpassingen waardoor de CUSUM-klassen verdwijnen, KI s en KM s gelijk worden afgehandeld (uniformiteit) en andere afhandeling van sanctieaanbevelingen plaats vindt, een informatievoorziening wordt gerealiseerd m.b.t. gevarenzones aan KI en KM en een herindeling van de gradaties met bijbehorende gebreken wordt doorgevoerd. De volgende zaken worden gerealiseerd: Geen bonus bij geconstateerde missers Cusum-systeem KI en KM gelijk Heropzet gebreken- en misserlijsten (rekening houdend met Europese regelgeving) Missergradaties worden herzien Missers verdeeld over 5 gradaties (verdere verfijning) Aangescherpte verhouding bonus malus Cusum-klassen komen te vervallen Bonus bij afkeurmelding blijft bestaan Van bovenstaande onderwerpen hebben er twee impact voor de procesverlopen, te weten het vervallen van Cusum-klassen voor zowel de KI als de KM en de verder verfijning van de Gebrekenlijst. 2.2. APK Gebrekenlijst (Datastructuur) De APK Gebrekenlijst ondergaat een uitbreiding en een verandering in structuur. De nieuwe opzet kent 4 niveaus, waarbij het uiteindelijk geconstateerde Gebrek op het laagste niveau is vastgelegd. De niveaus daarboven geven een indeling in categorieën/groepen aan. Elk niveau wordt geïdentificeerd met een Niveau-id en een Omschrijving. Overigens is die Omschrijving niet in alle gevallen door de RDW ingevuld. In dat geval is de omschrijving leeg. Op het niveau van de Gebreken is de Omschrijving wel altijd aanwezig. Voorbeelden: Niveau Niveau-id Gebrekcode Omschrijving 0 F Motor en Brandstofsysteem 1 F0 Brandstofsystemen 2 F01 <leeg> 3 F0101 076 Brandstofleidingen gescheurd 3 F0102 077 Brandstoflekkage 0 K Reminrichting 1 K0 Toestand reminrichting 2 K01 Algemene Toestand 3 K0101 277 Borging remonderdelen ontbreekt 3 K0103 278 Hoofdcilinder zit los Deze gelaagdheid wordt in de structuur van de Gebrekentabel verwerkt, waardoor processen die op de Gebrekentabel toegrijpen aangepast moeten worden. Het ophalen van de Gebrekenlijst wordt volledig aangepast aan de nieuwe opzet. De communicatie binnen het Keuringsproces verloopt, net als in de huidige opzet, middels de Gebrekcode / het Gebrek-id. Die blijft 3 posities, maar heeft (zoals hierboven in het voorbeeld opgenomen) een doorlopende nummering gekregen. Wijzigingsdocument RGT Fase 2 v1_1.doc 5/20

2.3. APK Processen (Berichtenverkeer) Omdat de Gebrekentabel gewijzigd wordt, zijn ook aanpassingen in het Berichtenverkeer nodig. De procedure om de Gebrekenlijst op te halen wordt volledig vervangen. Voor het overige zijn weinig aanpassingen nodig. Immers: De berichten die betrokken zijn bij APK Afmeldingen (zowel Goed- als Afkeuringen) worden niet gewijzigd, omdat het Gebrek-id qua definitie niet gewijzigd wordt (blijft 3 posities alfanumeriek) en ook de Categorieën (Afkeurpunt/Reparatiepunt/Reparatieadviespunt/Opmerking) ongewijzigd blijven. De berichten die betrokken zijn bij APK Opvragingen (zowel Goed- als Afkeuringen) en Opvragen Technische gegevens worden niet gewijzigd. De uitbreiding van de Gebrek-omschrijving van 60 naar 75 posities past binnen de huidige definitie. Het kan natuurlijk wel zijn dat u uw schermen, formulieren en documenten op de nieuwe lengte moet aanpassen. Aan het procesverloop zelf (afmelden, wel/geen steekproef, opvragen etc.) verandert ook niets. NB: Het oude Gebrek O06 is nu 010 Beoordelen Keuringsaspect niet mogelijk. Bij dit Gebrek is een Toelichting verplicht. In het berichtenverkeer wordt die verplichting niet afgedwongen, omdat bij de overige Gebrek-id de toelichting niet veplicht is. Leeglaten resulteert in een foutmelding van de RDW. 2.4. Cusum-klassen (Berichtenverkeer) Omdat per 01-04-2017 de Cusum-klassen voor zowel Keuringsinstanties en Keurmeesters vervallen, moeten de bijbehorende gegevens uit de betreffende berichten verwijderd worden. Dat betekent dat ALLE processen waarin deze gegevens voorkwamen, gewijzigd zijn. In enkele gevallen is er voor deze aanpassing samenloop met berichten die in het kader van de aanpassing van de APK Gebrekenlijst doorgevoerd wordt. Omdat het Cusum-systeem wel in stand blijft, verandert er blijft het attribuut CUSUMSTAND niets aanin berichten die deze stand ophalen of als uitvoer mee teruggeven gehandhaafd. Uitsluitend bij de erkenningen waarvoor het Cusum-systeem van toepassing wordt dit attribuut meegeven in het antwoordbericht. Er wordt een nieuw attribuut toegevoegd aan het proces Raadplegen Actuele Gegevens Keuringsinstantie: STATUS-CUSUM-ST. Dit attribuut wordt meegegeven indien de Keuringsinstantie waarvan de gegevens worden geraadpleegd zich in de Gevarenzone bevindt. In dit geval is het attribuut vgevuld met G. Is het attribuut niet aanwezig in het antwoordbericht, dan is de Keuringsinstantie in de veilige zone. NB: het attribuut is PER ERKENNING aan-/afwezig. De RDW stelt de EIS dat deze informatie PRO-ACTIEF aan de Keuringsinstantie getoond wordt. De bedoeling is extra zorgvuldigheid bij de Keuringsinstanties te bevorderen. De precieze invulling van deze eis wordt niet voorgeschreven, maar het ligt voor de hand deze waarschuwing te tonen op ALLE afmeldschermen die kunnen leiden tot missers/strafpunten. Ons advies is de waarde op te halen zodra de gebruiker het betreffende Afmeldscherm benadert. Uiteraard dient de waarde ook getoond te worden op raadpleegschermen van de KI-gegevens. NB: de Cusum-klasse vervalt ook voor de Keurmeesters. Deze worden door de RDW rechtstreeks geinformeerd als ze de Gevarenzone bereiken. Er is/komt daarom geen vergelijkbaar attribuut in de berichten OpvragenKMgegevens. Wijzigingsdocument RGT Fase 2 v1_1.doc 6/20

3. APK Gebreken - Tabeldefinitie en XMLmode 3.1. Impact Structuur Gebrekentabel 3.1.1. Wijzigingen De tabel APK Gebreken wordt opgezet in een structuur met 4 niveaus. Niveau 0 t/m 2 geven een indeling in categorieën en subcategorieën. Op niveau 3 is het Gebrek zelf ondergebracht De niveaus worden gekenmerkt door een letter met een volgnummer. Op het niveau van het Gebrek is de Gebrekcode het identificerende element dat gebruikt wordt voor de communicatie met de RDW. Bij elk gebrek wordt aangegeven op welke voertuigtypen het van toepassing kan zijn. 3.2. Impact APK-Processen 3.2.1. Wijzigingen Het bericht Opvragengebreken wordt aangepast aan de nieuwe gelaagde structuur. Wijzigingen layout In het opvraagbericht is een veld <datumopvraging> toegevoegd In het antwoordbericht is de volledige structuur van de gebrekentabel gelaagd opgenomen In het Antwoordbericht worden alle Gebreken die op het op het moment van de <datumopvraging> actief zijn (<datumingang> <= <datumopvraging> <= <datumexpiratie>) uitgeleverd. Het bericht kent een gelaagde structuur, waarin de niveaus van de Gebrekentabel worden weergegeven. Als extra s worden de volgende attributen meegeleverd: Artikelnr Het artikelnummer uit de Keuringseisen APK dat van toepassing is op het gebrek. Datumingang Datumexpiratie CodeRDW De samengestelde code, waar de gekoppelde categorieën uit afgeleid kunnen worden. De eerste drie karakters bevatten de categorie-aanduidingen voor de eerste drie niveaus, met daarna een volgnummer voor het gebrek (bijv. F0101) Isvoor. Aanduiding van toepasselijkheid voor voertuigtypen middels een aantal booleans Nieuwe validaties In het Opvraagbericht is het veld <datumopvraging> verplicht. Versionering Het proces Opvragengebreken krijgt een nieuwe versie, OpvragengebrekenV2. Na 01-04-2017 is alleen V2 nog in gebruik. 3.2.2. Layout Opvraagbericht: <opvragengebrekenv2 xmlns="http://www.xmlmode.net/apk/"> <xml_in_opvragengebreken> <client> <authenticatie> <reseller> <klantnummer>string</klantnummer> <inlognaam>string</inlognaam> <wachtwoord>string</wachtwoord> Wijzigingsdocument RGT Fase 2 v1_1.doc 7/20

Wijzigingsdocument RGT Fase 2 v1_1.doc 8/20 </reseller> <eindgebruiker> <klantnummer>string</klantnummer> <inlognaam>string</inlognaam> <wachtwoord>string</wachtwoord> <easykeycode>string</easykeycode> </eindgebruiker> </authenticatie> <sessie> <sessionkey>string</sessionkey> </sessie> <referentie> <info>string</info> </referentie> </client> <gebrekengegevens> <datumopvraging>datetime</datumopvraging> </gebrekengegevens> </xml_in_opvragengebreken> </opvragengebrekenv2> Antwoordbericht: <opvragengebrekenv2response xmlns="http://www.xmlmode.net/apk/"> <xml_out_opvragengebreken> <client> <authenticatie> <reseller> <klantnummer>string</klantnummer> <inlognaam>string</inlognaam> <wachtwoord>string</wachtwoord> </reseller> <eindgebruiker> <klantnummer>string</klantnummer> <inlognaam>string</inlognaam> <wachtwoord>string</wachtwoord> <easykeycode>string</easykeycode> </eindgebruiker> </authenticatie> <sessie> <sessionkey>string</sessionkey> </sessie> <referentie> <info>string</info> </referentie> </client> <loginresult> <code>short</code> <melding>string</melding> </loginresult> <nieuwsberichten> <nieuwsbericht> <kop>string</kop> <bericht>string</bericht> </nieuwsbericht> </nieuwsberichten> <opvragengebrekenresult> <transactieok>boolean</transactieok> <foutomschrijving>string</foutomschrijving> </opvragengebrekenresult> <gebrekenlijst> <niveau0items> <niveau0item> <coderdw>string</coderdw> <omschrijving>string</omschrijving> <niveau1items> <niveau1item> <coderdw>string</coderdw> <omschrijving>string</omschrijving> <niveau2items> <niveau2item> <coderdw>string</coderdw> <omschrijving>string</omschrijving> <gebreken> <gebrek>

<code>string</code> <coderdw>string</coderdw> <omschrijving>string</omschrijving> <soort>string</soort> <artikelnr>string</artikelnr> <isvooraanhanger>boolean</isvooraanhanger> <isvoorbedrijfsvoertuig>boolean</isvoorbedrijfsvoertuig> <isvoordriewieligvoertuig>boolean</isvoordriewieligvoertuig> <isvoorlandbosbouwvoertuig>boolean</isvoorlandbosbouwvoertuig> <isvoorpersonenauto>boolean</isvoorpersonenauto> <datumingang>datetime</datumingang> <datumexpiratie>datetime</datumexpiratie> </gebrek> </gebreken> </niveau2item> </niveau2items> </niveau1item> </niveau1items> </niveau0item> </niveau0items> </gebrekenlijst> </xml_out_opvragengebreken> </opvragengebrekenv2response> Wijzigingsdocument RGT Fase 2 v1_1.doc 9/20

4. APK - Processen en XMLmode 4.1. Impact XMLmode wsapk 4.1.1. Wijzigingen Aangezien de communicatie nu ook via een identificerend kenmerk van 3 posities verloopt, is hierin geen wijziging aangebracht. 4.1.2. Layout berichten De berichtlayout wordt niet gewijzigd. De actuele berichten blijven in stand. Wijzigingsdocument RGT Fase 2 v1_1.doc 10/20

5. Cusum-klassen - Processen en XMLmode 5.1. Impact XMLmode wsapk 5.1.1. Wijzigingen Wijzigingen layout Alle berichten waarin de <kwaliteitsklasse> voorkomt voor Keuringsinstantie of Keurmeester worden gewijzigd: het betreffende attribuut wordt verwijderd. Het betreft de volgende berichten: OpvragenKIgegevens OpvragenKMgegevens WijzigenKMgegevens In het bericht OpvragenKIgegevens wordt een tag <statuscusumstand> aan het responsebericht toegevoegd. De tag is alleen aanwezig bij erkenningen die een cusum-systeem kennen (m.n. APK Licht en APK Zwaar) en een Keuringsinstantie zich qua cusumstand in de Gevarenzone bevindt. In dat geval is het veld gevuld met een G. Nieuwe validaties N.v.t. Versionering De nieuwe methoden krijgen een opvolgende versienummer: o OpvragenkigegevensV2 o OpvragenkmgegevensV2 o WijzigenkmgegevensV2 Binnen de methoden is alleen bij het response-gedeelte het nieuwe versienummer opgenomen, omdat alleen in dat gedeelte een wijziging is aangebracht. 5.1.2. Layout OpvragenKIgegevens OUD: OpvragenkigegevensResponse <kwaliteitsklasse>string</kwaliteitsklasse> wordt verwijderd. <opvragenkigegevensresponse xmlns="http://www.xmlmode.net/apk/"> <xml_out_opvragenkigegevens> <kibevoegdheden> <status>string</status> <kwaliteitsklasse>string</kwaliteitsklasse> <status>string</status> <kwaliteitsklasse>string</kwaliteitsklasse> </kibevoegdheden> <opvragenkigegevensresponse> <xml_out_opvragenkigegevens> Wijzigingsdocument RGT Fase 2 v1_1.doc 11/20

NIEUW: OpvragenkigegevensV2Response <opvragenkigegevensv2response xmlns="http://www.xmlmode.net/apk/"> <xml_out_opvragenkigegevens> <kibevoegdheden> <status>string</status> <status>string</status> <statuscusumstand>string</statuscusumstand> </kibevoegdheden> <opvragenkigegevensv2response> <xml_out_opvragenkigegevens> 5.1.3. Layout OpvragenKMgegevens OUD: OpvragenkmgegevensResponse <kwaliteitsklasse>string</kwaliteitsklasse> wordt verwijderd. <opvragenkmgegevensresponse xmlns="http://www.xmlmode.net/apk/"> <xml_out_opvragenkmgegevens> <kmbevoegdheden> <CKMBevoegdheid /> <kwaliteitsklasse>string</kwaliteitsklasse> <CKMBevoegdheid /> <kwaliteitsklasse>string</kwaliteitsklasse> </kmbevoegdheden> <opvragenkmgegevensresponse> Wijzigingsdocument RGT Fase 2 v1_1.doc 12/20

<xml_out_opvragenkmgegevens> NIEUW: OpvragenkmgegevensV2Response <opvragenkmgegevensv2response xmlns="http://www.xmlmode.net/apk/"> <xml_out_opvragenkmgegevens> <kmbevoegdheden> <CKMBevoegdheid /> <CKMBevoegdheid /> </kmbevoegdheden> <opvragenkmgegevensv2response> <xml_out_opvragenkmgegevens> 5.1.4. Layout WijzigenKMgegevens OUD: WijzigenkmgegevensResponse <kwaliteitsklasse>string</kwaliteitsklasse> wordt verwijderd. <wijzigenkmgegevensresponse xmlns="http://www.xmlmode.net/apk/"> <xml_out_wijzigenkmgegevens> <kmbevoegdheden> <CKMBevoegdheid /> <kwaliteitsklasse>string</kwaliteitsklasse> <CKMBevoegdheid /> Wijzigingsdocument RGT Fase 2 v1_1.doc 13/20

<kwaliteitsklasse>string</kwaliteitsklasse> </kmbevoegdheden> </xml_out_wijzigenkmgegevens> </wijzigenkmgegevensresponse> NIEUW: WijzigenkmgegevensV2Response <wijzigenkmgegevensv2response xmlns="http://www.xmlmode.net/apk/"> <xml_out_wijzigenkmgegevens> <kmbevoegdheden> <CKMBevoegdheid /> <CKMBevoegdheid /> </kmbevoegdheden> </xml_out_wijzigenkmgegevens> </wijzigenkmgegevensv2response> 5.2. Impact XMLmode wslp 5.2.1. Wijzigingen Wijzigingen layout Alle berichten waarin de <kwaliteitsklasse> voorkomt voor Keuringsinstantie of Keurmeester worden gewijzigd: het betreffende attribuut wordt verwijderd. Het betreft de volgende berichten: OpvragenKMgegevens WijzigenKMgegevens Nieuwe validaties N.v.t. Versionering De nieuwe methoden krijgen een opvolgende versienummer: o OpvragenkmgegevensV2 Wijzigingsdocument RGT Fase 2 v1_1.doc 14/20

o WijzigenkmgegevensV2 Binnen de methoden is alleen bij het response-gedeelte het nieuwe versienummer opgenomen, omdat alleen in dat gedeelte een wijziging is aangebracht. 5.2.2. Layout Opvragenkeurmeestergegevens OUD: OpvragenkeurmeestergegevensResponse <kwaliteitsklasse>string</kwaliteitsklasse> wordt verwijderd. <opvragenkeurmeestergegevensresponse xmlns="http://www.xmlmode.net/lp/"> <xml_out_opvragenkeurmeestergegevens> <keurmeesterbevoegdheden> <Bevoegdheid> <Keurmeesterbevoegdheid> <kwaliteitsklasse>string</kwaliteitsklasse> </Keurmeesterbevoegdheid> <Keurmeesterbevoegdheid> <kwaliteitsklasse>string</kwaliteitsklasse> </Keurmeesterbevoegdheid> </Bevoegdheid> </xml_in_opvragenkeurmeestergegevens> </opvragenkeurmeestergegevens> NIEUW: OpvragenkeurmeestergegevensV2Response <opvragenkeurmeestergegevensv2response xmlns="http://www.xmlmode.net/lp/"> <xml_out_opvragenkeurmeestergegevens> <keurmeesterbevoegdheden> <Bevoegdheid> <Keurmeesterbevoegdheid> </Keurmeesterbevoegdheid> <Keurmeesterbevoegdheid> Wijzigingsdocument RGT Fase 2 v1_1.doc 15/20

</Keurmeesterbevoegdheid> </Bevoegdheid> </xml_in_opvragenkeurmeestergegevens> </opvragenkeurmeestergegevensv2response> 5.2.3. Layout WijzigenKMgegevens OUD: WijzigenkeurmeestergegevensResponse <kwaliteitsklasse>string</kwaliteitsklasse> wordt verwijderd. <wijzigenkeurmeestergegevensresponse xmlns="http://www.xmlmode.net/lp/"> <xml_out_wijzigenkeurmeestergegevens> <keurmeesterbevoegdheden> <Bevoegdheid> <Keurmeesterbevoegdheid> <kwaliteitsklasse>string</kwaliteitsklasse> </Keurmeesterbevoegdheid> <Keurmeesterbevoegdheid> <kwaliteitsklasse>string</kwaliteitsklasse> </Keurmeesterbevoegdheid> </Bevoegdheid> </keurmeesterbevoegdheden> </xml_out_wijzigenkeurmeestergegevens> </wijzigenkeurmeestergegevensresponse> NIEUW: WijzigenkeurmeestergegevensV2Response <wijzigenkeurmeestergegevensv2response xmlns="http://www.xmlmode.net/lp/"> <xml_out_wijzigenkeurmeestergegevens> <keurmeesterbevoegdheden> <Bevoegdheid> <Keurmeesterbevoegdheid> Wijzigingsdocument RGT Fase 2 v1_1.doc 16/20

</Keurmeesterbevoegdheid> <Keurmeesterbevoegdheid> </Keurmeesterbevoegdheid> </Bevoegdheid> </keurmeesterbevoegdheden> </xml_out_wijzigenkeurmeestergegevens> </wijzigenkeurmeestergegevensv2response> Wijzigingsdocument RGT Fase 2 v1_1.doc 17/20

6. XMLmode Opschoning APK/LPG/TA Met de wijzigingen voor VeTACH en EKI-2016 per 01-01-2017 en RGT Fase 2 per 01-04-2017 is een aantal berichtversies niet meer actueel. Deze berichten worden niet alleen buiten werking gesteld, maar de bijbehorende end points worden ook fysiek verwijderd. Aanroepen van deze versies levert per 01-04-2017 een foutmelding op. 6.1. Impact XMLmode wsapk De volgende berichtversies worden per 01-04-2017 buiten bedrijf gesteld: OpvragenGebreken OpvragenRdwV3 OpvragenRdwV4 OpvragenV3 OpvragenV4 SteekproefGezienV3 VersturenV3 VersturenV4 6.2. Impact XMLmode wslp De volgende berichtversies worden per 01-04-2017 buiten bedrijf gesteld: OpvragenV3 VersturenV3 OpvragenKMgegevens WijzigenKMgegevens 6.3. Impact XMLmode wsta De volgende berichtversies worden per 01-04-2017 buiten bedrijf gesteld: OpvragenV2 SteekproefGezienV2 VersturenV2 Wijzigingsdocument RGT Fase 2 v1_1.doc 18/20

7. Testen via Acceptatieomgevingen Wijzigingen kunt u testen via onze Acceptatieomgevingen. 7.1. Tijdlijn en Planning VWE zorgt ervoor dat uiterlijk 1 februari 2017 de wsdl van de aangepaste berichten beschikbaar is op acceptatie-xmlmode.vwe.nl en dat: uiterlijk 1 februari 2017 de Gebrekenlijst kan worden opgehaald uiterlijk 15 februari 2017 de overige functionaliteit getest kan worden. Uiteraard ontvangt u bericht als de informatie of de testmogelijkheden eerder beschikbaar komen. Alvorens u gaat testen, verzoeken we u contact op te nemen met ons als u gereed bent om te testen. We kunnen dan de volgende zaken controleren/afstemmen: Controle van KI-nummer in de testomgeving Controle van het geldig zijn van het gebruikte RDW-certificaat Afstemming van de Testset Afstemming van de Testperiode t.b.v. monitoring 7.2. Testuitvoering 7.2.1. Testomgeving Testen van de aanpassingen verlopen via de volgende urls: acceptatie-xmlmode.vwe.nl voor testen met Certificaat acceptatie-xmlmode-easy.vwe.nl voor testen met Certificaat of met Easykey NB: In de definitie van de berichten in de voorgaande hoofdstukken is de Productie-url opgenomen. Vergeet niet deze aan te passen als u gaat testen! Indien u van plan bent te testen MET Certificaat, dan verdient het aanbevelen tijdig met een Raadplegen Voertuiggegevens te testen of uw Certificaat nog geaccepteerd wordt c.q. niet verlopen is. Tevens dient u er rekening mee te houden dat uw uw Productiecertificaat NIET op onze Acceptatietestomgeving kunt gebruiken. 7.2.2. Authenticatie Om succesvol te kunnen testen, dient u de volgende informatie in het authenticatieblok van de berichten op te nemen: <authenticatie> <reseller> <klantnummer>999999999</klantnummer> <inlognaam>xxxxxxxxxxxxx</inlognaam> <wachtwoord>xxxxxxxxxxx</wachtwoord> </reseller> <eindgebruiker> <klantnummer>99999999</klantnummer> <inlognaam>xxxxxxxxxxxxxx</inlognaam> <wachtwoord>xxxxxxxxxx</wachtwoord> <easykeycode></easykeycode> </eindgebruiker> </authenticatie> NB-1:dien u test MET Certificaat, dan dient u de tag <easykeycode> leeg te laten. Wijzigingsdocument RGT Fase 2 v1_1.doc 19/20

7.2.3. Testset Voor het testen tegen de Acceptatie-omgeving van VWE en RDW moeten de volgende nummers worden gebruikt: Keuringsinstantie: Keuringsinstantienummer QQ71G83 Keurmeesters: Keurmeesternummer 123456 Pinpasnummer DFL98W Keurmeesternummer 100202 Pinpasnummer AHQS71 Voertuigen: Kentekens: huidige set gebruiken tot nadere afstemming De RDW heeft in de Acceptatietestomgeving een aantal testvoertuigen opgenomen en daarbij testgevallen en testdata gedefinieerd. Testen moeten worden uitgevoerd met gegevens die zowel in de Acceptatie-omgeving van VWE en RDW bekend zijn. Als de gegevens niet matchen, dan kunnen testen (met uitzondering van een aantal foutpaden). NB: Als een groot aantal partijen tegelijk wil testen, dan hebben we de mogelijkheid om de Acceptatieomgeving in demo-mode te zetten. Dat betekent dat van een vooraf gedefinieerde set kentekens een vast retourbericht teruggestuurd wordt. Bv.:APK-afmelding van 01-FGH-8 levert altijd een steekproef op Omdat deze testmodus niet afhankelijk is van RDW-communicatie, kan hiermee eenvoudiger parallel getest worden en kunnen werking en juistheid van berichtenstructuur gevalideerd wordt. Dat geeft ons de tijd om waar nodig onze testinrichting in overleg met de RDW te verbeteren. 7.2.4. Testuitvoering Voor de opvragingen van APK-goedkeuringen en afkeuringen geldt in principe dat u zelf een APK moet afmelden om de opvraging te kunnen doen. Omdat meerdere partijen met hetzelfde KI-nr testen, kan het voorkomen dat u ook andere voertuigen kunt opvragen. Ook op andere punten dient u bedacht te zijn op samenloop. De testdatabase van RDW wordt dagelijks gereset. De reset gebeurt s nachts en zorgt ervoor dat aan het begin van de dag de uitgangssituatie weer beschikbaar is. Houd u daar rekening mee met het plannen van uw tests. Zowel in de zin van het afronden van tests, alswel bij het bereiken van een gewenste eindsituatie. U moet dan een dag wachten voordat u een kenteken opnieuw kunt gebruiken. 7.2.5. Testbevindingen In principe hebben wij de berichtdefinities van de RDW een-op-een overgenomen. Foutmeldingen en waarschuwingen die wij van de RDW terugkrijgen, sturen wij ook een-op-een door naar de test user. Het is van belang om onderscheid te maken tussen meldingen die van onze server komen en die van de RDW. Houd u er rekening mee dat wij niet altijd direct inzicht hebben in oorzaak van de fout als die bij de RDW en dat we enige tijd nodig hebben om, waar nodig in overleg met de RDW, zaken te analyseren. Wijzigingsdocument RGT Fase 2 v1_1.doc 20/20