Velg en versjonspolicy for økonomidatakontrakter
En versjonspolicy skal gjøre det mulig å vite hvilken tolkning som gjelder for en bestemt leveranse.
Et versjonsnummer hjelper bare dersom endringen bak nummeret er dokumentert. En mottaker kan lese samme kolonneoppsett som før og likevel beregne feil hvis «beløp» har skiftet betydning fra fakturatotal til restbeløp. Versjoner både strukturen og betydningen av økonomidata.
Virksomheten kan velge en lokal policy, for eksempel hovedversjon for brudd og underversjon for kompatible tillegg. Det er en arbeidsavtale, ikke en offentlig regel for hvordan alle regnskapsformater skal nummereres. Offentlige formater har sine egne utgaver og endringsregler.
Vurder tre ulike endringer
| Endring | Risiko hos mottakeren | Lokal beslutning i eksemplet |
|---|---|---|
| Nytt valgfritt tekstfelt | Mottakeren kan avvise ukjente felt | Test toleranse før kompatibilitet erklæres |
| Obligatorisk kundenøkkel | Gamle filer mangler nøkkelen | Ny hovedversjon eller avtalt overgang |
| Samme beløpsfelt, ny betydning | Feil beregning uten teknisk feilmelding | Behandle som betydningsbrudd |
Et valgfritt tillegg er altså ikke automatisk ufarlig. En CSV-leser som forventer et bestemt antall kolonner, kan feile. En streng XML-validator kan avvise et nytt element. Kompatibilitet må måles mot de mottakerne dere faktisk har.
En praktisk overgang fra 1.2 til 2.0
Anta at versjon 1.2 bruker fakturanummer som nøkkel, mens 2.0 bruker stabil kilde-ID. Dere skal kunne levere begge versjoner i en avgrenset periode. Avsenderen må vite hvilken mottaker som fortsatt trenger 1.2, og mottakeren må kunne identifisere versjonen uten å gjette fra filinnholdet.
Lag en oversikt med mottaker, støttet versjon, prøvedato og dato for planlagt avvikling. Bevar eksempelfiler for begge versjoner. En versjon som er avsluttet for nye leveranser, kan fortsatt være nødvendig for å lese historiske arkiver.
Dette bør stå i policyen
- Hvordan versjonen identifiseres i filen eller leveransemanifestet.
- Hvilke struktur- og betydningsendringer som utløser ny hovedversjon.
- Hvordan varsel, testperiode og avvikling avtales.
- Hvilke historiske versjoner leseren må kunne tolke.
- Hvor endringsloggen og testresultatene finnes.
Unngå løfter om evig bakoverkompatibilitet uten en vedlikeholdsplan. Det kan være bedre å tilby en dokumentert konvertering for gamle filer, så lenge originalfilen bevares og transformasjonen kan forklares.
Når et format som SAF-T endres, må dere følge formatforvalterens dokumentasjon. En intern policy kan ikke forlenge en offentlig formats gyldighet.
Les bruddvurderingen og testen av bakoverkompatibilitet.