Versjoner kontomapping når kontoplanen endres
Bevar gyldighetsperioder og endringsbegrunnelser slik at historiske rapporter kan gjenskapes med riktig kontomapping.
Kontomapping endrer seg når kilden får nye kontoer, målplanen endres eller virksomheten vedtar et nytt rapportskille. En ny mapping skal ha en tydelig gyldighet, ikke overskrive forklaringen på tidligere overføringer.
Versjonering er først og fremst en beslutningsrutine. Definer hvilken kontoplan, hvilket selskap og hvilken periode hver utgave gjelder. Bevar også endringer som bare retter en feil, fordi de kan påvirke tidligere kontroller og rapporter.
En endring som flytter resultatlinjer
Syntetisk eksempel:
| Mappingutgave | Gyldig for | Kildekonto K-Tjeneste | Rapportvirkning |
|---|---|---|---|
| V1 | Januar–juni | M-Drift | Samlet driftskostnad |
| V2 | Juli og senere | M-IT | Egen IT-kategori |
Anta at kilden har 20 000 kroner i første halvår og 15 000 i andre. Med perioderiktig kobling blir M-Drift 20 000 og M-IT 15 000. Brukes V2 på hele året, vises 35 000 i IT-kategorien. Totalen er lik, men historisk presentasjon er endret.
Avklar om den nye definisjonen skal gjelde fremover eller også brukes til omarbeidede sammenligningstall. Dette er to forskjellige beslutninger som bør merkes i rapportgrunnlaget.
Hva hver utgave bør inneholde
Lagre kildens konto-ID, målkonto, eventuell dimensjon eller underregister, beslutningsdato, gyldig periode og begrunnelse. Bruk en stabil utgave-ID. Filnavn som «mapping-endelig-ny» fungerer dårlig når flere versjoner blir liggende i samme mappe.
En endringsoversikt bør vise tilføyd, fjernet eller endret kobling og hvilke saldoer som påvirkes. Prøv både et tidligere datasett og et datasett fra den nye perioden før utgaven tas i bruk.
- Kontroller at ingen konto mister mål utilsiktet.
- Sammenlign kategoriresultat før og etter endringen.
- Skill kildeendring fra målendring.
- Bevar hvem som godkjente gyldigheten.
Godkjenn når den nye mappingen gir avtalt resultat og den gamle fortsatt kan forklares. Stopp dersom dere ikke vet hvilke tidligere importer som brukte utgaven som nå erstattes.
Denne artikkelen gjelder forvaltning av mappingreglene. Dokumentasjon av den nøyaktige konfigurasjonen som faktisk ble brukt i en bestemt import, krever i tillegg en kobling mellom kjøring og utgave. En beslutningslogg alene beviser ikke utført konfigurasjon.
Sammenligningstesten bør bruke samme kildedata på begge utgaver, slik at dere isolerer mappingendringen. Hvis både eksport og mapping endres samtidig, blir virkningen vanskeligere å forklare. Bevar derfor et fast prøvedatasett og oppgi hvilken versjon det gjelder. Etter godkjent endring bør en ny konto i kilden fortsatt varsles som et avklaringspunkt. En gammel godkjenning dekker ikke automatisk alle senere kontoer eller nye registerkoblinger.
Se mappingversjonen i importsporet og beslutningslogg.