Oppsummering - behandling av ulike situasjoner

 

Persondatafil og infotypefil, statustransaksjoner + RAPPORTERINGSDATO:

     Tar med alle felter som er utfylt på alle infotyper man har valgt.

     For hver infotype er det kontroll på at infotypepost og felter er gyldig på rapporteringsdato.

     Framtidige poster blir ikke med (ikke gyldig på rapporteringsdato).

     Historiske poster blir ikke med (ikke gyldig på rapporteringsdato).

     Tar ikke med registrering av fratredelse tilbake i tid (personen blir ikke sluttmeldt).

 

Persondatafil og infotypefil, statustransaksjoner + PERIODE:

     I utgangpunktet samme funksjonalitet som ved rapporteringsdato = I dag.

     For personer med en framtidig post på en infotype legges den framtidige posten ut i stedet for posten som er gyldig pr. i dag.

     Ved en framtidig post på flere infotyper legges den framtidige posten ut i stedet for posten som er gyldig pr. i dag. Hver infotype behandles separat slik at noen infotyper vil legges ut pr. i dag mens for andre infotyper legges det ut framtidig poster med ulik ikrafttredelsesdato (BEGDA). Feltkombinasjonen på fila kan derfor bli ulogisk. Dette kan delvis unngås ved å ta ut ikrafttredelsesdato for hver enkelt infotype.

     Ved flere framtidige poster på en eller flere infotyper for samme person legges posten med ikratftredelsesdato (BEGDA) lengst fram i tid ut. Hver infotype behandles separat slik at noen infotyper vil leges ut pr. i dag mens for andre infotyper legges det ut framtidig poster med ulik ikrafttredelsesdato (BEGDA). Feltkombinasjonen på fila kan derfor bli ulogisk. Dette kan delvis unngås ved å ta ut ikrafttredelsesdato for hver enkelt infotype.

     Tar ikke med registrering av fratredelse tilbake i tid (bli ikke sluttmeldt).

 

PERSONDATAFIL, endringstransaksjoner + rapporteringsdato:

     Tar med poster lagret på siden forrige fil (normalt i går) som er gyldige på rapporteringsdato.

     Tar ikke med poster lagret på siden sist fil med ikrafttredelse fram i tid fordi posten ikke er gyldig på rapporteringsdato.

     Tar ikke med poster lagret på siden sist fil med tildato tilbake i tid. Posten var gyldig i går, men manglet tildato / hadde tildato fram i tid. Posten har tildato i dag, men er ikke lenger gyldig.

 

INFOTYPEFIL, endringstransaksjoner + rapporteringsdato:

     Tar med infotypeposter lagret på siden forrige fil (normalt i går) som er gyldige på rapporteringsdato.

     Tar ikke med poster lagret på siden forrige fil med ikrafttredelse fram i tid fordi posten ikke er gyldig på rapporteringsdato.

     Tar ikke med poster lagret på siden sist fil med tildato tilbake i tid. Posten var gyldig i går, men manglet tildato / hadde tildato fram i tid. Posten har tildato i dag, men er ikke lenger gyldig.

     Det legges ut flere transaksjoner på samme person når flere av postene som er endret siden forrige fil oppfyller kriteriene ovenfor.

 

PERSONDATAFIL, endringstransaksjoner + periode:

     Tar med infotypeposter lagret på siden forrige fil som er gyldige på referansedato. 

     Alle felter på fila som hentes fra infotypeposter som er endret legges ut. Felter fra infotypeposter som IKKE er endret legges ikke ut (er tomme) med unntak av IT0001..

     Ved flere endringer på samme infotype på samme person legges kun den infotypeposten med ikrafttredelsesdato lengst fram i tid ut på fila. Øvrige endringer på de samme infotypene, registrert på samme dag blir aldri lagt ut.

     Det skapes lett ulogiske poster fordi ulike infotyper på fila kan ha ulik ikraft­tredelsesdato.

     Endringer tilbake i tid blir med så sant posten fortsatt er gyldig på rapporteringsdato og det ikke samtidig finnes en framtidig post som det er lagret på samme dato.

     Fratredelse tilbake i tid legges ut som en ny post på IT0000 med historisk ikrafttredelsesdato. På denne transaksjonen er ansettelsesstatus for personen endret fra aktiv til passiv og fratredelsesdato er fylt ut.

 

INFOTYPEFIL, endringstransaksjoner + periode:

     Tar med alle infotypeposter lagret på siden forrige fil som er gyldige i dag, uavhengig av ikrafttredelsesdato.

     Det skapes ikke ulogiske poster ettersom hver fil kun inneholder en infotype.

 

For begge filtyper og begge transaksjonstyper og alle periodevalg:

     Transaksjoner som slettes i SAP blir ikke lagt ut på fila og får heller ikke noen form for merking. Her er man avhengig av at mottakende system klarer å identifisere at en post faller bort.