Het proces van ZPM registratie tot aan een debet / credit bestaat uit drie stappen en start iedere nacht om 00:00 uur.
USER/REFLEX - Bepalen declaratieregels
Eerst worden vanuit de registraties (agenda-afspraken, verblijfsdagen etc.) de prestaties en bijbehorende gegevens (behandelaar, regiebehandelaar, verwijzer, diagnose, zorgvraagtypering, zorglabels etc.) afgeleid.
Op deze declaratieregels wordt al een eerste controle uitgevoerd, waarbij regels die nooit declarabel kunnen worden niet aangeboden worden aan de declaratiemodule. Denk hierbij aan afspraken waarbij de behandelaar minder dan 5 min aanwezig is geweest of waarbij nog geen zorgverzekeraar is gevuld. Zie hiervoor ook de kwaliteitscontroles. De resultaten van deze job zijn te vinden in de tabellen zorgdata_zpm_ggz en zorgdata_zpm_fz
USER/REFLEX- Versturen declaratieregels
Vervolgens wordt een vergelijking gemaakt tussen de declaratieregels die al zijn verstuurd en de in zorgdata afgeleide declaratieregels. Wanneer hier een verschil tussen zit wordt er een gewijzigde versie van de declaratieregel opgestuurd of wordt deze leeg opgestuurd. Wanneer de inhoud leeg is betekent dit dat deze regel verwijderd mag worden. De resultaten hiervan zijn te vinden in de tabel declaration_rows_zpm
Billing - Bepalen debets & credits
Vervolgens verwerkt de declaratiemodule deze binnengekomen declaratieregels. Hierbij wordt gekeken naar de huidige status in de declaratiemodule en worden afhankelijk daarvan debets of credits aangemaakt. Daarnaast wordt iedere declaratieregel gecontroleerd tegen (financieringsspecifieke) controles. Wanneer een regel niet voldoet aan één van deze controles zal deze niet te declareren zijn (uitval) of zal een waarschuwing worden getoond.
Regels uit de verschillende stappen zijn aan elkaar te verbinden door het UUID van de declaratieregel te gebruiken. Dit UUID is in de tabellen zorgdata_zpm_ggz, zorgdata_zpm_fz en declaration_rows_zpm voorzien van verbindingsstreepjes. In Billing wordt het UUID niet gescheiden door verbindingsstreepjese en wordt deze in hoofdletters weergegeven.
Let op: het UUID uit de zorgdata tabellen en declaration rows is in het billing schema te vinden als ‘id’ in de tabel incoming_rows. De eventuele debets en credits die hieruit komen (één afgeleide UUID kan namelijk meerdere declaratieregels bevatten), en die liggen opgeslagen in de tabel declaration_rows, hebben hun eigen id. Het UUID uit de incoming_rows tabel is hier echter wel aan gelinkt.
Voor het overgrote deel van de registraties is de nachtjob nodig om wijzigingen in de declaratieregels door te voeren. Wijzigingen die direct na registratie doorgevoerd worden zijn:
Wijzigingen aan de cliënt waaronder BSN, SKN, geboortedatum en naam cliënt.
Naam van de organisatie
Naam van de behandelaar
Indien na een nachtjob de wijzigingen nog steeds niet doorkomen dient geanalyseerd te worden waardoor dit komt. Hiervoor kan een Topdesk melding worden ingediend.
Iedere nacht wordt gecontroleerd of de declaratieregels die vanuit de zorgdata komen ook daadwerkelijk in Billing zijn aanbeland. Indien dit niet het geval is worden deze gegevens nog nagestuurd en ontvangt de ontwikkelaar hiervan een signalering in de monitoring. Op die manier is geborgd dat mocht er wat fout gaan in het synchronisatieproces tussen de afleiding en de declaratiemodule alle gegevens alsnog doorkomen.
Om gebruik te maken van planning = realisatie moet dit op twee plekken ingericht worden.
Agenda instelling
Ga naar USER Alta en vervolgens de tegels Inrichting → Agenda → Agenda default instellingen. Helemaal onderaan de lijst staat ZPM ‘Planning = realisatie’. Zodra deze aan staat maakt de agenda gebruik van de functionaliteit rondom planning = realisatie.
Credit mechanisme declaratiemodule
Omdat bij het gebruik van planning = realisatie een wijzigende begintijd ook reden is voor een credit moet de declaratiemodule ook weten of hier gebruik van wordt gemaakt. Standaard gaat de declaratiemodule uit van het gebruik van planning = realisatie. Als dit moet worden aangepast, kan dit door de consultant worden ingericht.
Controleer de status van de zorgdata job. Deze scriptjes zijn hier te vinden.
In versie 9.12 wordt hiervoor een scherm opgeleverd waarmee dit is in te zien. Tot die tijd kan een consultant dit controleren.
Status | Beschrijving |
|---|---|
| De declaratieregel is ingelezen vanaf Kafka, maar is nog niet verwerkt. Deze regel wordt vanzelf opgepakt om te verwerken. |
| De declaratieregel is opgepakt voor verwerking en eventuele debets en credits zijn aangemaakt, bijgewerkt of verwijderd. |
| De declaratieregel is opgepakt, maar bij de verwerking is iets fout gegaan. Dit komt meestal doordat er technisch een fout in zit of dat er verplichte informatie mist. We proberen deze fouten tot een minimum te beperken, maar door de grote hoeveelheid gegevens komen er regelmatig rijen op deze status. Dit wordt met de versie wel minder, maar zal nog even tijd in beslag nemen voordat het helemaal weg is. Voor nu is de regel: krijg je deze status dan is er wat fout en moet er actie worden ondernomen. |
| Wanneer een wijziging binnenkomt voor een declaratieregel die op dit moment op een factuur staat die nog niet is goedgekeurd of afgekeurd dan wordt deze regel tijdelijk even in de wacht gezet. Zodra er wel goed- of afkeur is, of de regel wordt van een concept factuur afgehaald dan wordt deze weer vrijgegeven. |
| Zodra de regel vrijgegeven kan worden vanaf de status komt deze op de status . Daarna wordt de regel vanzelf opgepakt om opnieuw te verwerken. |
Het komt soms voor dat als er veel declaratieregels te verwerken zijn een regel niet in de wachtrij belandt en daardoor niet wordt opgepakt. Wanneer langere tijd het aantal regels met de status op hetzelfde aantal blijft hangen is het eerst zaak te controleren of er iets mis is met de module. Controleer dan of er niets mis is met de BILLING module en met de ActiveMQ. Als daar niks aan mankeert en het gaat om relatief lage aantallen rijen dan kunnen deze naar de status gezet worden.
De consultant kan hiervoor een script uitvoeren.
Indien regels op de status blijven hangen is er technisch iets mis en zal deze situatie onderzocht moeten worden. Dien dan een Topdesk melding in.
Het kan even duren voordat er weer gestart wordt met het verwerken van declaratieregels met de status . Je kunt zien wanneer er weer gestart wordt door onderstaande SQL uit te voeren. Kijk dan naar de job met de naam ‘ProcessIncomingRowJob’. De ‘LOCK_UNTIL’ geeft aan wanneer de eerstvolgende keer de job draait. ‘LOCKED_AT’ geeft aan wanneer de job voor het laatste gedraaid heeft.
Let op: tel wel 2 uur bij de tijden op die hier weergegeven staan.
select * from billing.shedlock;Voer onderstaand script uit en kijk in de kolom status_exception.
select * from billing.incoming_rows i where i.status = 'IMPORT_FAILED' order by i.received desc;Op dit moment zijn de meest bekende uitvalredenen degene in onderstaande tabel.
Reden | Oplossing |
|---|---|
declarantCode: must not be null | Er ontbreekt op het zorgtraject van de cliënt een AGB-code. Voeg deze toe aan het zorgtraject. |
caregivers[0].type: must not be null | Doet zich voor bij verblijfsdagen. Is op te lossen door op het zorgtraject van de cliënt een AGB-code toe te voegen. |
could not execute statement; SQL [n/a]; constraint [BILLING.FK_ZPMD_DERO] | Er gaat iets fout bij het verwijderen van een declaratieregel. |
AGB-code declarant
Uzovi code betaler
BSN
SKN
Prestatiecodelijst
Prestatiecode
Hoofdprestatie waaraan de toeslag gekoppeld is
Startdatum prestatie
Starttijd prestatie (alleen bij gebruik planning = realisatie)
Aantal
Tarief
Berekend bedrag
Declaratiebedrag
Zorglabel (APK code)
AGB-code behandelaar, hoofdbehandelaar, of hoofdaannemer
Naam van behandelaar (alleen wanneer er geen AGB-code of specificatie is)
Specificatie van behandelaar (alleen wanneer er geen AGB-code is)
Beroep van behandelaar (alleen wanneer er geen AGB-code of specificatie is)
Privacycode
Diagnose codelijst
Diagnosecode (zowel ZVT als DSM)
Zorgtrajectnummer
Zorgtraject startdatum
Contractnummer
Plaatsingsbesluitnummer
Startdatum forensische zorgtitel
Einddatum forensische zorgtitel
Wanneer een declaratieregel is afgekeurd kan deze op twee manieren weer selecteerbaar gemaakt worden:
Door ervoor te zorgen dat de reden van afkeur wordt opgelost in de registraties. Wanneer de declaratieregel opnieuw (nadat de job 's nachts is uitgevoerd) wordt aangeboden wordt de status van de regel omgezet van naar of afhankelijk of deze wijziging voldoet aan de kwaliteitscontroles.
Indien de declaratieregel onterecht is afgekeurd kan deze via het menu aan het eind van de regel (drie puntjes) via de knop ‘Gereed plaatsen’ handmatig weer op de status worden geplaatst. Let op dat de declaratieregel dan exact hetzelfde wordt ingediend bij de betaler als de afgekeurde variant. Deze wordt alleen ingediend onder een ander referentienummer.
Hiervoor zijn twee mogelijkheden:
Vink een deel van de declaratieregels uit. Zolang deze niet aangevinkt staan gaan ze niet mee in de declaratie.
Zorg dat de declaratieregels niet zichtbaar zijn door gebruik te maken van de filters. Wil je bijvoorbeeld alleen regels declareren van één bepaalde cliënt dan filter je eerst op deze cliënt. Als je vervolgens op de knop klikt om facturen aan te maken wordt alleen een factuur aangemaakt voor deze cliënt. Alleen wat dus zichtbaar is op je scherm EN aangevinkt staat wordt meegenomen in het aanmaken van een factuur.
De beste methode is om gebruik te maken van filters in het scherm. Hierbij kan gebruik gemaakt worden van twee filters:
Er kan gefilterd worden op de status . Dit zorgt ervoor dat alle declaratieregels op het scherm komen die nog niet gedeclareerd worden en een uitvalreden hebben.
Om verder in te zoomen op de redenen van uitval kan hiervoor nog een apart filter worden ingesteld. In dat geval verschijnen alleen die regels die aan een bepaalde uitvalreden voldoen.
Eventueel kan geholpen worden door de consultant een SQL te laten draaien en de uitval te exporteren naar Excel.
Overzicht uitvalreden
select e.message, count(*) from billing.errors e group by e.message order by count(*) desc;Overzicht uitval per cliënt
select c.registration_number as Clientnummer
, d.id as ID
, d.performance_code Prestatiecode
, d.performance_start_date Startdatum
, TO_CHAR (d.performance_start_time, 'HH24:MI:SS') Starttijd
, e.message_code Retourcode
, e.message Uitvalreden
from billing.errors e
join billing.declaration_rows d
on e.declaration_row_id = d.id
join billing.clients c on
d.client_id = c.id
where d.status in ('NEW', 'DROPOUT', 'INVOICED', 'REJECTED_UNDER_REVIEW', 'VALIDATION_ERROR');Op de pagina met kwaliteitscontroles is te zien welke controles er allemaal worden uitgevoerd. Deze pagina wordt continu bijgewerkt en de controles worden ook nog steeds scherper. Raadpleeg deze pagina dus regelmatig voor een overzicht van de meest actuele controles.
Wanneer een conceptfactuur wordt verwijderd worden alle declaratieregels eerst opnieuw gecontroleerd tegen de kwaliteitscontroles. Het kan even duren voordat na het verwijderen van een factuur de regels dus weer te zien zijn om te selecteren. Wanneer er nog onverwerkte wijzigingen vanuit de afleiding zijn (incoming_rows tabel regel met status ) moeten deze ook eerst opnieuw verwerkt worden. Alleen op deze manier krijgt de medewerker financiële administratie weer de meest actuele status van de regel te zien.
Er zijn meerdere redenen waarom een declaratieregel niet aangevinkt kan worden bij het maken van selecties:
Het betreft een regel met uitval die eerst opgelost moet worden voordat de declaratieregel opgenomen kan worden in een factuur.
De declaratieregel betreft een toeslag en de hoofdprestatie is reeds onderdeel van een factuur en nog niet goedgekeurd. Toeslagen en hoofdprestaties mogen alleen samen in dezelfde factuur zitten OF de toeslag mag onderdeel uitmaken van een latere factuur en de hoofdprestatie is al goedgekeurd.
De hoofdprestatie is niet aangevinkt, waardoor de toeslag ook niet is aan te vinken. Zie de uitleg bij punt 2.
De declaratieregel is afgekeurd door de betaler en er is nog geen wijziging op geweest of de regel is nog niet handmatig vrijgegeven door de medewerker financiële administratie.
Een declaratieregel heeft altijd één van de statussen uit onderstaande tabel.
Status | Beschrijving |
|---|---|
Gereed | De declaratieregel kan geselecteerd worden om onderdeel te worden van een factuur en bevat geen uitvalredenen. |
Uitval | De declaratieregel kan niet geselecteerd worden omdat er uitvalredenen zijn waardoor de regel niet opgenomen kan worden in een factuur. Deze dienen eerst opgelost te worden voordat dit wel mogelijk is. |
Onderdeel van factuur | De declaratieregel maakt onderdeel uit van een factuur waar nog geen antwoord op is ontvangen. |
Goedgekeurd | De declaratieregel is door de betaler goedgekeurd. |
Deels goedgekeurd | De declaratieregel is door de betaler goedgekeurd, maar met een lager bedrag dan waarmee deze is ingediend. |
Afgekeurd | De declaratieregel is door de betaler afgekeurd voor het volledige bedrag. |
Afgekeurd (ter beoordeling) | Wanneer de declaratieregel is afgekeurd wordt een kopie gemaakt van deze regel die vervolgens weer te selecteren is. In dat geval staat de afgekeurde declaratieregel ‘ter beoordeling’. |
Validatiefout | De regel is bij het aanmaken van een factuur tegen een validatiefout aangelopen. Vervolgens is deze declaratieregel van de betreffende factuur verwijderd. |
In principe is er qua technische werking geen verschil tussen parkeren en uitsluiten, anders dan dat het een ander ‘label’ krijgt op de achtergrond.
Parkeren wordt vaak gebruikt door zorgaanbieders voor regels die tijdelijk niet mee moeten in de declaratie en waar eerst nader onderzoek naar gedaan moet worden.
Uitsluiten wordt gebruikt voor declaratieregels die in de toekomst nooit meer mee moeten in de declaratie.
In overleg met de werkgroep facturatie zijn voor zowel parkeren als uitsluiten verschillende redenen opgesteld waarom de declaratieregel geparkeerd of uitgesloten moet worden. Er zit een verschil in deze lijst tussen parkeren en uitsluiten.
In dit geval wordt het zoeken of deze regel terecht niet terugkomt in het overzicht of dat hier ergens iets fout gaat. De consultant kan hiervoor een stappenplan volgen of u kunt een Topdesk melding indienen.
De consultant kan bij deze zoektocht ondersteunen of hiervoor kan een Topdesk melding worden ingediend.
Na het selecteren van de declaratieregels en het klikken op de knop ‘Aanmaken facturen’ worden er op de achtergrond drie processen in gang gezet:
De declaratieregels worden per betaler gegroepeerd
Voor iedere betaler in de factuur wordt dus één factuur aangemaakt. Hiervan wordt afgeweken indien het een papieren factuur betreft en de betaler is een organisatie. In dat geval wordt er, in lijn met de landelijke eisen, één factuur aangemaakt per cliënt voor de betreffende organisatie.
Het XML declaratiebericht wordt aangemaakt
Na het aanmaken van de facturen wordt het XML bericht samengesteld. Dit proces kan enige tijd duren indien het een grote factuur betreft. Dit komt doordat voor iedere declaratieregel alle gegevens meegestuurd moeten worden, waardoor een niet gezipte XML vaak 100-den mb’s in beslag neemt.
Het XML declaratiebericht wordt gecontroleerd tegen de bedrijfsregels
Na aanmaken van het XML declaratiebericht wordt deze gecontroleerd tegen alle actuele bedrijfsregels die hiervoor gelden. Alleen wanneer de XML aan al deze vereisten voldoet kan deze opgenomen worden in het berichtenverkeer met Vecozo.
Status | Betekenis |
|---|---|
Wordt gevalideerd | De factuur is al aangemaakt, maar het XML declaratiebericht wordt nog aangemaakt en gecontroleerd. |
Te verzenden | De factuur en het XML declaratiebericht zijn succesvol aangemaakt. Uit de controles zijn geen fouten naar voren gekomen. De factuur kan verzonden worden naar de betaler. |
Fout bij aanmaken | Bij het aanmaken van de factuur is technisch iets fout gegaan. Neem contact op met Avinty. |
Validatiefouten | De factuur en het XML declaratie zijn succesvol aangemaakt, maar uit de controles zijn fouten naar voren gekomen. Vaak betreffen het hier technische fouten die niet door een eindgebruiker op te lossen zijn. Neem bij twijfel contact op met Avinty. |
Wachten op verzenden | De factuur is in de wachtrij gezet om te versturen, maar is nog niet opgepakt. |
Wordt verzonden | De factuur is aangeboden bij Vecozo, maar we hebben nog geen terugkoppeling ontvangen of deze succesvol is afgeleverd bij de betaler. |
Wacht op antwoord | De factuur is succesvol afgeleverd bij de betaler en wacht op een retour. |
Fout bij verzenden | Bij het verzenden van de factuur naar Vecozo is iets fout gegaan. Afhankelijk van de fout kan geprobeerd worden het bericht opnieuw te verzenden. |
Goedgekeurd | Het retourbericht is succesvol ontvangen en verwerkt. Alle ingediende declaratieregels zijn goedgekeurd. De factuur krijgt een goedgekeurd status als het declaratiebedrag overeen komt met het toegekende bedrag. |
Deels goedgekeurd | Het retourbericht is succesvol ontvangen en verwerkt. Tenminste één van de declaratieregels is afgekeurd. Hierdoor is niet het hele declaratiebedrag toegekend. |
Afgekeurd | Het retourbericht is succesvol ontvangen en verwerkt. Alle declaratieregels zijn afgekeurd. Het toegekend bedrag in het retourbericht is 0 euro. |
Afgekeurd door Vecozo | Bij het verzenden van het bericht blijkt dat deze niet aan de vereisten van Vecozo voldoet. Neem contact op met de softwareleverancier. |
Fout bij verwerken retourbericht | Bij het verwerken van het retourbericht voor deze factuur is iets fout gegaan. Neem contact op met de softwareleverancier. |
Indien een groot aantal declaratieregels is geselecteerd kan het even duren voordat alle regels gegroepeerd zijn per betaler en alle facturen zijn aangemaakt. Het scherm met de facturen ververst zich automatisch wanneer nieuwe facturen zijn aangemaakt of wanneer de XML declaratieberichten zijn aangemaakt en gecontroleerd.
De ZPM declaratiestandaard heeft het declareren per financiële periode losgelaten en staat het toe om voor meerdere financiële periodes declaratiegegevens op te nemen in één declaratiebericht. Dat is ook hoe de declaratiemodule het doet, zijn er declaratieregels voor meerdere financiële periodes dan worden deze voor dezelfde betaler in één declaratiebericht opgenomen.
Indien je graag een factuur wilt per betaler per periode dan is het zaak om ervoor te zorgen dat de ‘periode vanaf’ en ‘periode t/m’ bij het maken van een selectie gelijk zijn aan elkaar.
Wanneer een declaratieregel wordt afgekeurd wordt hiervan een kopie gemaakt. Voordat de regel terug wordt geplaatst wordt deze eerst gecontroleerd tegen de op dat moment geldende kwaliteitscontroles. Als deze controles zijn afgerond is de declaratieregel weer zichtbaar in de selectie, al kan deze niet aangevinkt worden.
Hoe groter de factuur is hoe langer het zal duren voordat deze klaar is met het aanmaken hiervan. Omdat bij iedere declaratieregel alle gegevens mee moeten in de factuur kan een bestand voordat deze gezipt is soms 100-den mb’s bedragen. Het kan echter voorkomen dat het zo lang duurt, omdat het billing SCS uit z’n geheugen loopt. Dit dient dan ook eerst gecontroleerd te worden door de consultant.
Een validatiefout ontstaat bij het aanmaken van een declaratiebericht en fungeert als een vangnet voor het kwaliteitscontrole framework. In principe zou er bij het aanmaken van een declaratiebericht dus geen validatiefout meer moeten verschijnen. Als dit wel het geval is, kan getracht worden uit de melding op te maken wat er aangepast dient te worden. Helaas is dit vaak een technische melding. Bij twijfel kan een Topdesk melding worden ingediend.
Om declaratieberichten te versturen en retourberichten te kunnen ontvangen is het belangrijk dat het Vecozo certificaat ingericht staat. Hetzelfde certificaat als momenteel in USER Forms gebruikt wordt moet ook ingericht worden voor de nieuwe declaratiemodule. Deze configuratie kan in USER Alta via onderstaande stappen:
Ga naar de tegel Inrichting → Externe koppelingen → Vecozo certificaten
Kies voor ‘upload’ en selecteer de juiste keystore met het Vecozo certificaat. Vergeet niet het juiste wachtwoord in te voeren en om de datums in te voeren wanneer dit certificaat geldig is. Sla het certificaat nu eerst op.
Voeg hierna aan het certificaat de AGB-codes toe van de eigen organiastie waarop dit certificaat betrekking heeft. Vaak heeft een organisatie maar één certificaat en kunnen alle AGB-codes waarmee gedeclareerd moet worden toegevoegd worden aan dit certificaat. Sommige organisaties willen liever met meerdere certificaten werken en dat is op deze manier mogelijk gemaakt.
Het certificaat moet op twee plekken ingericht worden omdat we op dit moment in een transitiefase zijn wat betreft de koppelingen. Uiteindelijk zullen alle koppelingen gebruik maken van de nieuwe plek van inrichten. Voordat dit echter zover is zullen eerst alle financieringsstromen en regieberichten nog gemigreerd worden vanuit USER Forms.
Het proces van versturen van een declaratiebericht bestaat uit de volgende stappen:
De factuur wordt in de wachtrij gezet om te versturen. De factuur krijgt nu de status ‘Wachten op verzenden’.
De factuur is opgepakt en wordt op dit moment verzonden. De factuur krijgt nu de status ‘Wordt verzonden’.
Van Vecozo wordt een bericht ontvangen dat de factuur goed is ontvangen en wordt doorgezet aan de betaler. In dat geval krijgt de factuur de status ‘Wacht op antwoord’.
Zodra er in het verstuurproces iets fout gaat krijgt de factuur de status ‘Fout bij verzenden’.
Het proces van het ophalen van retourberichten bestaat uit de volgende stappen:
Voor iedere AGB-code waar nog geen antwoordberichten op zijn verkregen wordt een verzoek uitgezet bij Vecozo om de retourberichten op te halen.
Hierna worden de retourberichten één voor één opgehaald bij Vecozo en klaargezet om te verwerken.
Hierna worden de berichten één voor één verwerkt. Indien de verwerking goed gaat krijgt de factuur de status ‘goedgekeurd’, ‘afgekeurd’ of ‘gedeeltelijk goedgekeurd’.
Gaat er iets fout in het proces van verwerken van de facturen (stap 3) dan krijgt de factuur de status ‘Fout bij verwerken retourbericht’.
Indien de factuur de status ‘Fout bij verzenden’ krijgt kan dit opgelost worden door in de module eerst nogmaals op de knop ‘Opnieuw verzenden’ te klikken. Indien de fout zich dan nog voordoet kan het beste contact gezocht worden met Avinty via een Topdesk melding.
Gebruik hiervoor het berichtenportaal van Vecozo. Let op dat ZPM declaratieberichten en retourberichten alleen verschijnen onder het kopje declareren 2.0!
Indien er geen retourberichten binnenkomen in de declaratiemodule is het eerst zaak om te kijken of er ook berichten klaar staan om te ontvangen. Dit kan door te kijken in het berichtenportaal van Vecozo onder declareren 2.0. Indien hier berichten klaar staan druk dan eerst in de declaratiemodule nogmaals op de knop ‘Ophalen retourberichten’. Indien de berichten dan nog niet verschijnen kan dit aan twee zaken liggen:
De retourberichten worden helemaal niet opgehaald vanaf Vecozo.
De retourberichten worden niet goed verwerkt. Dit kan bekeken worden door onderstaande SQL uit te voeren en om in de kolom ‘status_exception’ te kijken wat er precies mis gaat bij het verwerken.
select * from billing.incoming_response_messages i where i.status = 'IMPORT_FAILED'Indien deze melding wordt gegeven bij een factuur gaat er technisch iets fout bij het verwerken van het retourbericht. Dit zal nagekeken moeten worden door Avinty en hiervoor dient dan ook een Topdesk melding ingediend te worden.
Meestal gebeurt dit doordat het afleverbericht bij Vecozo niet ingelezen kan worden in USER. Deze kan eventueel handmatig opnieuw verwerkt worden. Hiervoor kunt u contact zoeken met Avinty Support.
Deze afkeur ontstaat doordat sommige volgnummers nog niet goed werden uitgedeeld bij geen gebruik van planning = realisatie en bij de OV0010 prestatie bij gebruik van planning = realisatie. Een oplossing en herstelscript hiervoor is opgeleverd in 9.11.13 en 9.12.3.
Wanneer u na installatie toch nog retouren binnen krijgt met deze retourcode moet hiervoor een script gedraaid worden om dit te herstellen. Hiervoor kunt u contact opnemen met Avinty support.
De informatie uit de retourberichten worden als volgt ingelezen: 1. Het TotaalDeclaratiebedragInclbtw (bedrag in verstuurde factuur) en 2. TotaalToegekendBedragInclbtwFinancieel (goedgekeurde bedrag) met de bijbehorende debit-credit code. Daaruit wordt de status van de factuur bepaald: FAQ | Secundair proces | Wat betekenen de verschillende statussen van een factuur?
De aantallen van de onderliggende prestaties in het retourbericht worden ook ingelezen. De meegestuurde retourcode is daarbij niet leidend voor goed of afgekeurde prestatie maar het toegekende bedrag en type prestatie. Van de afgekeurde prestaties wordt een intern factuur aangemaakt.
Journaalposten worden op twee momenten aangemaakt:
Nadat de factuur defintief is gemaakt en wordt verzonden naar Vecozo.
Nadat van de betaler antwoord is ontvangen en hieruit blijkt dat één of meerdere declaratieregels zijn afgekeurd. In dat geval wordt er een interne factuur aangemaakt met daarin de tegenboekingen.
Wanneer de journaalposten niet zijn aangemaakt, is het zaak om eerst te kijken of er wel een bericht met journaalposten verstuurd is vanuit de declaratiemodule. In de payload van het bericht kan vervolgens gezocht worden naar het invoceNumber om te kijken of voor de betreffende factuur een journaalpostenbericht is verstuurd. Indien dat niet het geval is, is bij de verwerking van het retourbericht iets fout gegaan.
Wanneer voor de factuur wel een journaalpostenbericht is, kan het zijn dat deze niet goed verwerkt kon worden. Dit is te zien aan de status van het bericht die dan op status komt te staan. Waarom iets fout is gegaan is terug te vinden in de kolom ‘exception’. Vaak betreft dit het niet ingericht zijn van grootboeken en/of kostenplaatsen.
select * from kafka_incoming_messages k order by k.kaim_received desc;Wanneer het probleem is opgelost kan een consultant er voor zorgdragen dat de niet verwerkte journaalposten alsnog verwrkt kunnen worden.
De data uit de declaratiemodule ligt opgeslagen in het ‘billing’ schema. Er kan toegang verkregen worden tot deze gegevens door hier een verzoek voor in te dienen via een Topdesk melding. Met de verkregen inloggegevens kunnen vervolgens de tabellen uitgelezen worden.
Tabelnaam | Informatie |
|---|---|
incoming_rows | Bevat alle afgeleide regels vanuit het bronsysteem. Deze worden uiteindelijk verwerkt tot één of meer debets en credits. |
declaration_rows | Bevat alle debets en credits die voortkomen uit één afgeleide regel uit de incoming_rows tabel. Afhankelijk van de situatie kan één afgeleide regel dus meerdere debets en credits hebben. |
caregivers | Bevat alle behandelaren behorende bij de declaratieregel. De rollen zijn als volgt: 01 = behandelaar |
diagnoses | Bevat de diagnoses behorende bij de declaratieregel. |
errors | Bevat alle foutmeldingen behorende bij een declaratieregel of een factuur. |
exclusions | Bevat informatie of er een geparkeerd of uitgesloten moet worden. |
exclusion_declaration_rows | Bevat welke declaratieregels er zijn uitgesloten. |
zpm_apk_data | Bevat de zorglabels behorende bij een declaratieregel |
zpm_declaration_data | Bevat aanvullende gegevens bij de declaratieregel die specifiek voor ZPM zijn. |
clients | Bevat de cliënten vanuit het Kafka topic. Het veld |
configuration | Bevat specifieke inrichting voor de klant. |
declaration_periods | Bevat de inrichting voor de declaratieperiodes vanuit het Kafka topic. |
employees | Bevat alle medewerkers vanuit het Kafka topic. |
financing_flows | Bevat de financieringstypen die op dit moment worden ondersteund. |
incoming_response_messages | Bevat de retourberichten die zijn opgehaald vanuit Vecozo |
invoices | Bevat de aangemaakte facturen. |
invoice_number_formats | Bevat de inrichting voor de factuurnummers. |
lower_thresholds | Bevat de ingerichte ondergrens. |
messages | Bevat alle aangemaakte declaratieberichten en ontvangen retourberichten |
organizations | Bevat alle organisaties / instanties die zijn ingelezen vanaf Kafka. |
shedlock | Bevat informatie ove wanneer de jobs hebben gedraaid / opnieuw draaien. |
Alle tabellen in het Billing schema worden gelogd en kunnen gebruikt worden om eventuele problemen te achterhalen. De logtabellen hebben dezelfde naam als de inhoudelijke tabellen en worden gevold door _aud. Bij het analyseren is het handig om eerst te sorteren op de kolom ‘rev’. Degene met het laagste nummer is de eerste revisie en die me het hoogste nummer de laatste.