Invulinstructie

In het berichtenverkeer bestaat de mogelijkheid om eerder verstuurde berichtklassen te corrigeren of te verwijderen.

Om aan te geven dat een berichtklasse dient te worden gecorrigeerd, wordt StatusAanlevering van de betreffende berichtklasse gevuld met de waarde 2 (gewijzigde aanlevering). De te wijzigen berichtklasse wordt geidentificeerd door de (logische) sleutel van de klasse.
Een wijziging die (met StatusAanlevering 2) wordt doorgegeven overschrijft in zijn geheel de laatst verzonden aanlevering. Voor een client kan pas een volgende wijziging voor dezelfde aanlevering verstuurd worden, zodra het retourbericht ontvangen is van de eerdere wijziging.

Om aan te geven dat een aanlevering dient te worden verwijderd, wordt StatusAanlevering van de betreffende berichtklasse gevuld met de waarde 3 (verwijderen aanlevering). De te verwijderen aanlevering wordt geidentificeerd door de (logische) sleutel van de berichtklasse. De waarde van de niet-sleutelelementen uit de te verwijderen berichtklasse zijn niet relevant voor de verwijdering. Het is dan ook niet van belang of deze worden overgenomen uit het originele bericht.
Het resultaat van een verwijdering die (met StatusAanlevering 3) wordt doorgeven, is dat alle aanleveringen met die logische sleutel komen te vervallen, ongeacht de waarde van StatusAanlevering van deze eerdere aanleveringen.

Een retourbericht wordt gestuurd om de zender te informeren over de beoordeling (technisch/inhoudelijk) van het heenbericht. Voor ieder heenbericht wordt slechts 1 retourbericht gestuurd (1-op-1). De ontvanger stuurt altijd een retourbericht naar de verzender.
Deze invulinstructie heeft betrekking op alle retourberichten.

Een retourbericht wordt als volgt opgebouwd:

Een retourbericht bevat altijd een Header.

• In de Header wordt BerichtCode gevuld met de berichtcode van het betreffende retourbericht.
• Overige elementen, inclusief Afzender en Ontvanger, worden ongewijzigd overgenomen van de header van het heenbericht.
• De Header wordt aangevuld met identificerende gegevens van het retourbericht (IdentificatieRetour en DagtekeningRetour) en kan worden aangevuld met het versienummer van de XSLT’s die gebruikt zijn om het bericht te controleren. Dit laatste is verplicht indien afkeur plaatsvindt op basis van de XSLT’s.

Wat na de Header volgt is afhankelijk van of en op welk controleniveau fouten zijn geconstateerd:

Er zijn geen fouten geconstateerd: #

Wanneer geen fouten geconstateerd zijn, is het heenbericht volledig goedgekeurd. Het retourbericht bevat in dat geval alleen een Header, zonder retourcodes.

Controleniveau 1: Er zijn fouten geconstateerd bij XSD-validatie #

Indien het bericht niet valideert tegen het XSD krijgt de afzender een foutmelding. Er wordt geen retourbericht verzonden.

Controleniveau 2: Er zijn fouten geconstateerd bij XSLT-validatie #

Voor alle regels die binnen een bericht gecontroleerd kunnen worden, maar die niet via het XSD gevalideerd kunnen worden, zijn XSLT’s beschikbaar die gebruikt kunnen worden om de controles uit te voeren. Wanneer een bericht een fout oplevert bij een controle op één van deze regels wordt alleen de Header retour gestuurd met de algemene retourcode 0001 (Bericht is afgekeurd om technische redenen).
Wanneer de ter beschikking gestelde XSLT’s gebruikt zijn, moet bovendien het versienummer van de XSLT’s worden meegegeven.

Controleniveau 3 of 4: Er zijn fouten geconstateerd op berichtoverstijgende controles of controles tegen een externe bron #

Indien er een fout geconstateerd is in de Header, bevat het retourbericht alleen de Header met daarbij de retourcode van de regel op basis waarvan de fout geconstateerd is.
Indien in één of meer berichtklassen over een Client fouten zijn geconstateerd, worden alle berichtklassen van die Client ongewijzigd overgenomen in het retourbericht. Bij iedere berichtklasse wordt telkens met een retourcode aangegeven wat de status is:

• Geen fouten geconstateerd in deze berichtklasse: retourcode 0200
• Deze berichtklasse is niet gecontroleerd: retourcode 0233
• Er is een fout geconstateerd in deze berichtklasse: de retourcode van de regel op basis waarvan de fout geconstateerd is.

Bijvoorbeeld: Het CAK ontvangt een eigenbijdragebericht beschermd wonen met daarin een PeriodeEigenBijdrageBw met StatusAanlevering 3 (verwijderen aanlevering), maar heeft niet eerder een Eigenbijdragebericht beschermd wonen met hetzelfde BwStartNummer en StatusAanlevering 1 (eerste aanlevering) ontvangen. Het bericht wordt dan afgekeurd op basis van TR103.

In het retourbericht worden in deze situatie de volgende retourcodes gevuld:

• Header: Retourcode 0200 (Geen opmerkingen over deze berichtklasse)
• Client: Retourcode 0200 (Geen opmerkingen over deze berichtklasse)
• PeriodeEigenBijdrageBw: Retourcode 9103 (Het bericht kan niet verwerkt worden omdat geen eerder bericht ontvangen is)

Welke retourcode gevuld moet worden, wordt bepaald door controle op basis waarvan het bericht wordt afgekeurd. Deze controles zijn beschreven als technisch te controleren regels die op verschillende niveaus gecontroleerd worden. Bij iedere technisch te controleren regel is aangegeven op welk controleniveau deze gecontroleerd wordt. Indien van toepassing is ook aangegeven welke retourcode gebruikt moet worden in het retourbericht indien op basis van de regel een heenbericht wordt afgekeurd.
Deze invulinstructie heeft betrekking op alle retourberichten.

Een ontvangen heenbericht wordt op vier niveaus gecontroleerd:

Controleniveau 1: berichtformaat (XSD) #

Het bericht wordt gevalideerd tegen het XSD.

Indien het bericht niet valideert, krijgt de afzender een foutmelding. Er wordt geen retourbericht verzonden. Regels op dit controleniveau hebben daarom geen retourcode.

Controleniveau 2: berichtinhoud (XSLT) #

Het bericht wordt gecontroleerd tegen alle regels (technische regels, condities en constraints) die binnen het bericht zelf te controleren zijn. Voor deze regels zijn XSLT’s beschikbaar die gebruikt kunnen worden om de controles uit te voeren.

Deze regels hebben een algemene retourcode (0001) die gevuld wordt in het retourbericht.

Wanneer fouten worden geconstateerd bevat het retourbericht alleen de Header met retourcode 0001 (Bericht is technisch onjuist). Wanneer de ter beschikking gestelde XSLT’s gebruikt zijn, moet bovendien het versienummer van de XSLT’s worden meegegeven.

Controleniveau 3: berichtoverstijgend #

Het bericht wordt gecontroleerd op alle technische regels die berichtoverstijgend zijn. Dat wil zeggen dat de informatie in het heenbericht gecontroleerd wordt ten opzichte van informatie in één of meer eerder ontvangen domeinspecifieke berichten.

Deze regels hebben een eigen retourcode die gevuld wordt in het retourbericht bij de berichtklasse waarin de fout geconstateerd is. Indien een fout geconstateert is, leidt dit tot volledige afkeur van het bericht.

Controleniveau 4: externe bron #

Het bericht wordt gecontroleerd op alle technische regels waarvoor informatie nodig is die geen onderdeel is van het iStandaarden berichtenverkeer. Dit betreft bijvoorbeeld:

• Systeemdatum van de verzender/ontvanger;
• Een externe codelijst zoals de AGB-codelijst of de gemeentelijke indeling van CBS;
• Bilaterale afspraken tussen ketenpartijen, zoals contractafspraken die opgenomen zijn in een regel binnen de iStandaarden.

Deze regels hebben een eigen retourcode die gevuld wordt in het retourbericht bij de berichtklasse waarin de fout geconstateerd is. Indien een fout geconstateert is, leidt dit tot volledige afkeur van het bericht.

Bij de initiele aanlevering van een eigenbijdragebericht mag de startdatum maximaal de wettelijke termijn voor oplegging eigen bijdrage in het verleden liggen.

In het uitvoeringsbesluit Wmo 2015 wordt de periode waarover de client eigen bijdrage verschuldigd is wettelijk beperkt.
Het CAK kan hierdoor maximaal eigen bijdrage opleggen aan de client voor deze wettelijk beperkte periode. Voor de aanmelding van een periode eigen bijdrage wordt een gelijke beperking aangehouden.

Bij de gewijzigde aanlevering van een eigenbijdragebericht mag een gewijzigde startdatum en/of gewijzigde stopdatum maximaal de wettelijke termijn voor herziening eigen bijdrage in het verleden liggen.

In het uitvoeringsbesluit Wmo 2015 wordt de periode waarover de client eigen bijdrage verschuldigd is of waarover de client restitutie van de eigen bijdrage kan ontvangen, bij een herziening wettelijk beperkt.Het CAK kan hierdoor een oplegging maximaal over deze wettelijk beperkte periode herzien. Voor wijzigen van periode eigen bijdrage wordt een gelijke beperking aangehouden.