Bevar statusendringer fra opprettet til bokført betaling
Siste status er nyttig for oppfølging, men historikken forklarer hvordan betalingen kom dit.
En betaling kan gå gjennom flere stadier: opprettet oppdrag, sendt fil, teknisk mottak, godkjenning, bankbokføring og eventuell retur. Hver status må vise hvem som satte den og hva den bekrefter. En siste verdi som «betalt» er utilstrekkelig dersom grunnlaget bare var en sendekvittering.
Bevar hendelser med oppdragsidentitet, tid, kilde og relevante referanser. Siste status kan beregnes for visning, men bør ikke erstatte historikken. En senere retur kan endre oppfølgingen uten å gjøre den tidligere bokføringen usann.
Et oppdrag med forsinket godkjenning
Syntetisk eksempel med lokale statusnavn, ikke en bestemt banks kodeliste.
| Tid | Hendelse | Kontrollbetydning |
|---|---|---|
| Mandag 09:00 | Oppdrag på 3 000 NOK opprettet | Betaling planlagt |
| Mandag 09:05 | Fil mottatt teknisk | Ikke bevis på belastning |
| Tirsdag 10:00 | Godkjenning registrert | Videre behandling mulig |
| Tirsdag senere | −3 000 bokført i bank | Kontantbevegelse kan avstemmes |
| Onsdag | Retur +3 000 | Kravet må følges opp igjen |
Å overskrive hele forløpet med «retur» mister forklaringen på bankens to bevegelser. Å la status stå som «betalt» ignorerer den nye hendelsen.
Kontroller meldingenes rekkefølge
Integrasjoner kan motta hendelser forsinket eller flere ganger. Registreringstid er derfor ikke alltid hendelsestid. En gammel status som kommer sist, skal ikke automatisk overstyre en nyere bankbekreftet hendelse.
Definer hvilke hendelser som gir hvilken lokal status, og hvordan motstrid håndteres. Banken og betalingsformidleren kan ha forskjellige modeller. DNBs veiledning beskriver blant annet at mottatte filer fortsatt kan vente på godkjenning.
- Skill filstatus fra status for enkeltoppdrag.
- Bevar råkode og lokal tolkning separat.
- Test dupliserte og forsinkede hendelser.
- Knytt bokført status til bankgrunnlag.
- Registrer retur som ny hendelse med forbindelse til originalen.
Godkjenningskriterier
Historikken skal forklare dagens oppfølgingsbehov og alle faktiske bankbevegelser. En ukjent eller motstridende status bør gi en synlig avklaringssak. Ikke bruk en stille standard som setter oppdraget til vellykket.
Teknisk støtte for en meldingsfamilie beviser ikke at alle statusforløp er implementert. Be systemleverandøren vise testresultat for akkurat godkjenning, avvisning, bokføring og retur som virksomheten trenger.
Les avvisning og retur og hendelsestid.
Lag en prøve der onsdagens returmelding mottas før en forsinket tirsdagsmelding om bokføring. Historikken skal fortsatt vise at begge hendelser fant sted, og dagens oppfølging skal ta hensyn til returen. En regel som bare velger sist mottatte melding, vil gi feil nåstatus i dette tilfellet.