Invulinstructies

Een retourbestand wordt gestuurd als ontvangstbevestiging van een heenbestand en bevat eventueel afgekeurde berichten (clienten) die niet voldoen aan de iStandaard. Een retourbestand wordt als volgt opgebouwd:

Header:

• In de header wordt de BerichtCode gevuld met de berichtcode van het betreffende retourbericht.
• De elementen Afzender en Ontvanger worden ongewijzigd overgenomen van de header van het heenbestand.
• De header wordt aangevuld met identificerende gegevens van het retourbestand (IdentificatieRetour en DagtekeningRetour).
• Alle berichtklassen, inclusief de header, worden uitgebreid met een berichtklasse RetourCodes. Daarbinnen kunnen één of meer retourcodes, horend bij de betreffende berichtklasse, worden opgenomen.

De volgende situaties kunnen zich voordoen:

1. Alle heenberichten in een bestand zijn goedgekeurd: Het retourbestand bevat alleen een header. Er worden geen retourcodes opgenomen.
2. Het aangeleverde bestand bevat één of meer berichten die inhoudelijk onjuist zijn: Het retourbestand bevat een header en de client of clienten die afgekeurd worden, inclusief alle berichtklassen behorend bij die client(en). Alle informatie over een client wordt ongewijzigd overgenomen.
   2a. Bij iedere berichtklasse wordt met retourcode(s) aangegeven wat er fout is.
   2b. Berichtklassen die niet beoordeeld zijn, bijv. omdat in een bovenliggende berichtklasse een fout geconstateerd is, krijgen retourcode 0233 (Berichtklasse is niet beoordeeld).
   2c. Berichtklassen waarin geen fouten zijn geconstateerd krijgen retourcode 0200 (Geen opmerking over deze berichtklasse).
3. Indien het heenbestand technisch onjuist is, bijvoorbeeld indien het niet valideert tegen het XSD, kan in de Header een retourcode 0001 (Bericht is technisch onjuist) worden meegegeven. Alle onderliggende berichtklassen krijgen in dat geval retourcode 0233 (Berichtklasse is niet beoordeeld).
4. Indien de ontvanger geen retourbericht kan maken, bijvoorbeeld omdat het bestand onleesbaar is, neemt de ontvanger buiten het berichtenverkeer om contact op met de verzender van het heenbericht.

De verstrekker kan op de volgende manieren de correspondentie beheren:

• Als voor de budgethouder OntvangtCorrespondentie gevuld is met 1 (Ja) en er wordt geen adres meegestuurd dan ontvangt de budgethouder correspondentie op het BRP-adres;
• Als voor de budgethouder OntvangtCorrespondentie gevuld is met 1 (Ja) en er wordt een adres meegestuurd dan ontvangt de budgethouder correspondentie op het meegestuurde adres;
• Als voor de budgethouder OntvangtCorrespondentie gevuld is met 2 (Nee) dan ontvangt de budgethouder geen correspondentie;
• Als voor de vertegenwoordiger OntvangtCorrespondentie gevuld is met 1 (Ja) en er wordt geen adres meegestuurd dan ontvangt de vertegenwoordiger correspondentie op het BRP-adres of op het KvK-adres;
• Als voor de vertegenwoordiger OntvangtCorrespondentie gevuld is met 1 (Ja) en er wordt een adres meegestuurd dan ontvangt de vertegenwoordiger correspondentie op het meegestuurde adres;
• Als voor de vertegenwoordiger OntvangtCorrespondentie gevuld is met 2 (Nee) dan ontvangt de vertegenwoordiger geen correspondentie.

De verstrekker vult bij het element Afgiftedatum in het toekenningsbericht de datum in waarop het budget, behorend bij de beschikking, is toegekend.

Het komt voor, dat meerdere verstrekkers voor dezelfde budgethouder toekenningsberichten sturen; denk bijvoorbeeld aan de situatie waarbij een budgethouder is overgegaan van de Wlz naar de Wmo.
Wanneer dit het geval is, zal de SVB het toekenningsbericht met de meest recente Afgiftedatum als leidend zien.
In het geval dat meerdere toekenningsberichten van verschillende verstrekkers voor dezelfde budgethouder, gelijke Afgiftedatum hebben, dan zal het laatst verwerkte bericht leidend zijn.

Scenario: Vorige verstrekker corrigeert budget, zonder datum afgifte aan te passen

Bij een correctie van een eerder toekenningsbericht, bijvoorbeeld na een bestedingsconflict die optrad omdat het beëindigd pgb een lager budgetbedrag had dan al was uitgegeven, kan de corrigerende verstrekker zorgen dat eventuele vertegenwoordigers van een nieuwe verstrekker NIET vervangen worden. Dit kan simpelweg door de Afgiftedatum van deze correctie gelijk te laten zijn aan die van het te corrigeren toekenningsbericht.

Gegeven gemeente “A” stuurt op 1 november 2024 een toekenningsbericht aan het PGB-Portaal

En het PGB-Portaal heeft dit bericht verwerkt op 1 november 2024

Stel in het voorjaar 2025 verhuist de budgethouder naar gemeente “B”
En gemeente “A” beëindigd het budget voor budgethouder met bsn 345678901
En gemeente “B” voor de periode 1 mei 2025 tot en met 31 december een PGB verstrekt aan de budgethouder met bsn 345678901
Als gemeente “A” op 29 april 2025 een toekenningsbericht aan het PGB-Portaal stuurt

En het PGB Portaal heeft dit bericht verwerkt op 29 april 2025
Dan kan vertegenwoordiger met bsn 765432109 per 29 april 2025 zaken regel in het PGB-Portaal voor budgethouder met bsn 345678901

Als gemeente “B” op 30 april 2025 een toekenningsbericht aan het PGB-Portaal stuurt

En het PGB Portaal heeft dit bericht verwerkt op 30 april 2025
Dan kan vertegenwoordiger met bsn 765432109 per 30 april 2025 geen zaken meer regelen in het PGB-Portaal voor budgethouder met bsn 345678901
Maar kan vertegenwoordiger met bsn 654321098 per 30 april 2025 zaken regelen in het PGB-Portaal voor budgethouder met bsn 345678901

Stel over de periode januari tot en met april 2025 is reeds € 4.200 besteed
En het PGB-Portaal stuurt een budget afsluitbericht met reden budget afsluiting “Bestedingsconflict”
En de gemeente “A” corrigeert dit

Als gemeente “A” op 2 mei 2025 een toekenningsbericht aan het PGB-Portaal stuurt

En het PGB Portaal heeft dit bericht verwerkt op 2 mei 2025
Dan kan vertegenwoordiger met bsn 765432109 per 30 april 2025 geen zaken meer regelen in het PGB-Portaal voor budgethouder met bsn 345678901
Maar kan vertegenwoordiger met bsn 654321098 per 30 april 2025 zaken regelen in het PGB-Portaal voor budgethouder met bsn 345678901