Vurder om en feltendring bryter eksisterende mottakere
En endring kan bryte behandlingen selv om den nye filen fortsatt kan leses og valideres.
Et økonomigrensesnitt har flere kontrakter samtidig: filen skal kunne leses, feltene skal kunne tolkes, og arbeidsprosessen skal gi riktig resultat. En bruddvurdering må derfor gå lenger enn spørsmålet om parseren krasjer.
Start med å beskrive hva som endres og hvilke mottakere som bruker opplysningen. Ikke vurder et nytt felt isolert fra feltene som beregnes fra det. En endret prisbasismengde kan for eksempel påvirke linjesummen selv om prisfeltet er uendret.
Eksempel: en valutaopplysning blir eksplisitt
En gammel eksport har bare amount, og kontrakten sier at alle beløp er NOK. Den nye eksporten får currency, men avsenderen begynner samtidig å levere beløp i EUR. En gammel mottaker ignorerer det nye feltet og summerer alle beløp som kroner.
| Kontrollnivå | Observasjon | Konsekvens |
|---|---|---|
| Lesing | Filen kan åpnes | Ingen teknisk stopp |
| Struktur | Nytt valgfritt felt tillates | Validatoren godtar filen |
| Betydning | Beløpet er ikke lenger alltid NOK | Gammel beregning blir feil |
| Prosess | Oppfølging bruker feil verdi | Feil betalingskrav eller rapport |
Endringen er et betydningsbrudd for den gamle mottakeren. Den kan ikke klassifiseres som et harmløst felttillegg bare fordi strukturtesten passerer.
Lag en konsekvenskjede
For hver endring skal dere kunne følge kjeden fra kildefelt til mottakerfelt, beregning og rapport. Registrer mottakere som trenger tilpasning, og hvilke leveranser som kan fortsette uendret. Dersom ingen vet hvem som bruker feltet, er dette et kartleggingsavvik, ikke bevis på at endringen er trygg.
Prøv både gammel mottaker med ny leveranse og ny mottaker med gammel leveranse. Det første undersøker fremoverkompatibilitet; det andre undersøker om historikk og eksisterende avsendere fortsatt kan håndteres. Resultatene kan være forskjellige.
Beslutningsgrunnlaget bør inneholde
- En før- og etterbeskrivelse av struktur og betydning.
- Minst ett eksempel som viser forskjellen i faktisk behandling.
- Liste over berørte mottakere og ansvarlige roller.
- Testresultater for normalposter og grensetilfeller.
- Plan for varsling, overgang og eventuell konvertering.
Et ukjent mottakersystem skal ikke automatisk registreres som kompatibelt. Bruk status «ikke prøvd» og beskriv hva som mangler. Det gjør det mulig å innføre endringen kontrollert uten å gi en bredere garanti enn dokumentasjonen støtter.
Les versjonspolicyen og testvektorene.