Bevar prosjekt- og avdelingsreferanser fra SAF-T
En dimensjonskode trenger riktig type. Samme verdi kan bety forskjellige ting i prosjekt- og avdelingsregistre.
SAF-T har analyseopplysninger som kan beskrive dimensjoner, for eksempel prosjekt og avdeling. AnalysisType identifiserer dimensjonstypen, mens AnalysisID identifiserer verdien i typen. Bevar begge opplysningene når data overføres.
En kode som «42» er ikke nødvendigvis globalt unik. Den kan finnes både som prosjekt og avdeling. En mottaker som bare lagrer verdien uten type, kan koble kostnaden til feil rapportgrunnlag.
To perspektiver på samme post
| Dimensjonstype i eksemplet | Verdi | Postens beløp | Tolkning |
|---|---|---|---|
| PROJ | P-42 | 6 000 | Prosjektperspektiv |
| AVD | A-10 | 6 000 | Avdelingsperspektiv |
Kodene er lokale testverdier, ikke offisielle dimensjonskoder. Beløpet beskriver samme post fra to perspektiver og skal ikke summeres til 12 000 kroner som om det var to nye posteringer.
Undersøk eksport og mottak hver for seg
Kontroller om kilden faktisk eksporterer dimensjonsreferansene, og om nødvendige registeropplysninger følger med. Undersøk deretter om mottakeren leser dem, bare lagrer råfilen eller bruker dem i rapportering. Dette er forskjellige nivåer av støtte.
Et lesbart felt i XML er ikke bevis på at prosjektøkonomien blir bevart etter import. Lag en prøve med én kjent prosjektpost og sammenlign rapporten før og etter. Bevar hvilken mapping av dimensjonstyper og -verdier som ble brukt.
Vurder fordelinger og historiske verdier
Hvis en post er fordelt mellom flere dimensjonsverdier, må det fremgå hvordan beløp eller fordeling uttrykkes i kilden. En mottaker som forventer én prosjektverdi per linje, kan ha behov for en avgrenset tilpasning. Ikke gjem dette som en generell «dimensjonsstøtte».
Inaktive prosjekter kan fortsatt være nødvendige for historiske poster. Kontroller at registeruttrekket ikke bare inneholder aktive verdier dersom historikken skal kunne forklares.
Ved overgang til en annen datamodell kan noen opplysninger måtte bevares i et separat arkiv. Dette er en begrensning som skal være kjent før overtakelse, ikke en opplysning som oppdages etter at gammelt system er stengt.
Utvid den syntetiske dimensjonsprøven med samme kodeverdi i to ulike dimensjonstyper. Mottakeren skal kunne skille prosjekt 42 fra avdeling 42 uten å bruke navnelikhet som nøkkel. Det viser om både type og verdi blir bevart i den faktiske mappingen.
Godkjenn overføringen per dimensjonstype og bruksformål. En løsning kan bevare prosjekt som råreferanse uten å kunne vise prosjektregnskap, eller bruke avdeling i rapportering uten å lese historiske inaktive verdier. Disse begrensningene bør få egne statuser. En samlet erklæring om «dimensjoner overført» gir for lite informasjon til å avgjøre om virksomhetens avtalte rapportbehov er dekket.
Kilder
Se informasjon fra konto til dimensjon og avsluttede prosjekter.
Les også Prosjektkoder over tid: når samme kode får en ny betydning.