Valg av rapporteringsdato og -periode

Vi skiller mellom rapporteringsdato og kjøredato. Kjøredato er normalt identisk med rapporteringsdato, men ikke alltid. Rapporteringsdato er den dato dataene skal kontrolleres mot, f.eks. om 2 uker eller om 4 uker. Kjøredato er den dato rapporten er produsert.

Statustransaksjoner krever rapporteringsdato

Ved generering av statustransaksjoner på en konkret dato er det kontroll på at alle felter på filen er gyldige på den dato som er valgt, eksempelvis «I dag» eller «Om to uker». Det er ikke mulig å rapportere på en dato tilbake i tid.

Dersom en slik datokontroll ikke er der er det ikke gitt at alle felter på filen er gyldige på en og samme dato og da kan informasjonen på filen bli ulogisk.

Endringstransaksjoner krever periode

Ved generering av endringstransaksjoner er det kontroll på om det er lagret på infotypeposten siden i går (egentlig siden dato for siste vellykkede fil).

Endringer må legges ut på første fil. Seinere vil posten ikke være endret siden sist fil og vil bli lagt ut. Det er derfor mot sin hensikt å kontrolleres gyldighet på endringstransaksjoner. Endringstransaksjoner må tas ut for periode, gyldig «Fra i dag» (og i all framtid).

Når man ber om endringer fjernes kontrollen på om personen er aktiv og om posten er gyldig. Dette for å få med registrering av sluttdato på en infotypepost etter at dato er passert (lager historisk post).  Dersom det hadde vært kontroll på om personen var aktiv og at posten var gyldig ville registrering av en tildato tilbake i tid aldri blitt lagt ut. Dette er spesielt viktig ved registrering av fratredelse og slutt på fravær/permisjon tilbake i tid.

Når registrering av ny post, f.eks på infotypene 0001, 0002, 0006 og 0008 blir den gamle posten automatisk avgrenset. Ved slik automatisk avgrensing oppdateres ikke feltet sist endret dato på den gamle posten. Slike endringer vil derfor ikke bli lagt ut.

Anbefalt periodevalg

Endringstransaksjoner på persondatafil

Årsaken til at man normalt ikke tar ut endringstransaksjoner på en persondatafil er at man kun får 1 post pr. ansatt.

Ved flere framtidige poster på samme infotype på samme person vil systemet kun ta med posten med ikratftredelsesdato (BEGDA) lengst fram i tid. En persondatafil tar med flere infotyper og postene som er endret på de ulike infotypene kan ha ulik BEGDA.

En endringstransaksjon på en persondatafil som altså tar med poster med ulik BEGDA kan derfor bli ulogisk og er ikke alltid egnet for direkte oppdatering, men den kan være egnet for å identifisere at en endring vil skje.  

Ved oppstart kan man likevel anta at sist registrerte post vil være den posten som er gyldig på oppstartsdato. Det er eventuelt viktig at informasjonen overskrives av statustransaksjoner på oppstartsdato slik at man blir helt sikkert på at info ved oppstart blir korrekt.

Dersom en kunde i tillegg til en daglig persondatafil med statustransaksjoner også ønsker melding om framtidige hendelser, kan det være hensiktsmessig å ta ut en egen persondatafil med endringstransaksjoner med det formål å vise visse framtidige hendelser. Mottaker må selv filtrere bort uønsket informasjonen. Andre måter å identifisere framtidige endringer på er å ta ut to statusfiler, en pr. dagens dato og en fil en eller to uker fram i tid. Begge filene vil da inneholde logiske transaksjoner. Man kan også ta ut endringer på IT0302 for på denne måten å identifisere hva som vil skje når, men man får da ikke med detaljene i hva som vil skje.

Eksempel 1:

En bruker registrerer saksgang for start permisjon og for slutt permisjon på samme dag.

•     Endringstransaksjon på persondatafilen.
Kun den ene saksgangen fra IT0000 tas med og systemet velger den posten med ikrafttredelsesdato (BEGDA) lengst fram i tid. Kun saksgang for slutt permisjons blir med på fila. Saksgang for start permisjon vil aldri bli lagt ut som endring.

•     Statustransaksjon på persondatafil pr dags dato.
Systemet velger den infotypeposten som er gyldig på rapporteringsdato. Saksgangen for start permisjon blir med på første fraværsdag. Saksgang for slutt permisjon blir med første arbeidsdag etter at permisjonen er slutt. 

•     Statustransaksjon på persondatafil 2 uker fram i tid.
Systemet velger den infotypeposten som er gyldig på rapporteringsdato. Saksgangen for start permisjon blir med når det er 2 uker igjen til oppstart. Ved registrering mindre enn to uker før permisjonsstart blir endringen med på førest fil. Tilsvarende for permisjonsslutt.

•     Endringstransaksjon på IT0032.
Både saksgang for start og saksgang for slutt permisjon blir med på første fil. Begge saksgangene har riktig dato, men man ser ikke hvilke andre endringer som foretas i samme saksgang.

Tilsvarende, det samme skjer dersom man på samme dag registrer saksgang for start fungering og saksgang for slutt fungering.

Eksempel 2:

Det besluttes intern omorganisering og registreres overgang til ny org.enhet med ikrafttredelsesdato 1. april. Samme dag registrerer endring av dellønnsprosent fra 17. april.

•     Endringstransaksjon på persondatafila.
Systemet velger den infotypepost med seineste ikrafttredelsesdato. For IT0000 velges saksgang for endring av dellønnsprosent fra 17. april. Samtidig vil den ta med seg endringen av org.enhet fra IT0001. Men denne endringen skjedde 1. april. Transaksjonen gjenspeiler ikke registrerte data.

•     Statustransaksjon på persondatafil pr. dags dato.
Systemet velger den infotypeposten som er gyldig på rapporteringsdato. Ved registrering i mars blir ingen av saksgangene med. På fila 1. april får man med saksgang for endring av org.enhet. Denne saksgangen vil også komme med på statusfila og med riktig ikrafttredelsesdato ved registrering i perioden 1.-17. april. Saksaksgang for endring av dellønnsprosent legges ut på fila 17. april. Ved registrering av begge deler på en dato etter 17. april vil kun endring av dellønnsprosent komme med.

•     Statustransaksjon på persondatafil 2 uker fram i tid.
Systemet velger den infotypeposten som er gyldig på rapporteringsdato. Ved registrering i mars blir saksgang for endring av org.enhet fra 1. april med den 17. mars. Ved registrering seinere enn 17. mars vil den komme med på første fil. Saksaksgang for endring av dellønnsprosent pr. 17. april legges ut på fila 3. april. Ved registrering av begge deler på en dato etter 17 april vil kun endring av dellønnsprosent komme med.

•     Endringstransaksjon på IT0032.
Begge saksganger blir med på første fil. Begge saksgangene har riktig dato, men man ser ikke hvilke endringer som er gjort på den enkelte infotype.

Eksempel 3:

Lokale lønnsforhandlinger fra 1 august registreres 2.12. Den ansatte har i tillegg endret fra deltid til full stilling fra 10 oktober.

•     Endringstransaksjon på persondatafila.
Systemet registrer endring på IT0008 den 2.12., men tar den posten med BEGDA lengst fram i tid. Det betyr at lønnslønnsendring fra 10.10 legges ut, riktignok med ny lønn. Lokale forhandlinger fra 1.8 vil ikke fli lagt ut på endringsfila.

•     Statustransaksjon på persondatafil pr. dags dato.
Systemet velger den infotypeposten som er gyldig på rapporteringsdato. Fra 10.10. eller fra eventuell seinere registrering av endring av stillingsprosent legger programmet ut ny saksgang for endring av stillingsprosent med ny prosent og gammel sats, men lønna justeres i henhold til 100 %. Fra 2.12 legger den ut ny prosent og ny sats i kombinasjon med siste saksgang på IT0000 som er endring av stillingsprosent. Saksgang for lokale forhandlinger fra 1.8. vil heller ikke her bli lagt ut.

•     Statustransaksjon på persondatafil 2 uker fram i tid.
Systemet velger den infotypeposten som er gyldig på rapporteringsdato. Fra 26.9. eller fra eventuell seinere registrering legger programmet ut saksaksgang for endring av dellønnsprosent fra 10.10. med ny prosent og gammel sats, men lønna justeres i henhold til 100 %. Fra 2.12 legger den ut ny prosent og ny sats i kombinasjon med siste saksgang på IT0000 som er endring av stillingsprosent. Saksgang for lokale forhandlinger fra 1.8. vil heller ikke her bli lagt ut.

•     Endringstransaksjon på IT0032.
Begge saksganger blir med på første fil etter registrering. Begge saksgangene har riktig dato, men man ser ikke hvilke endringer som er gjort på den enkelte infotype.

Statustransaksjoner på infotypefil

Ved overføring av infotyper som endres ofte, f.eks. fravær vil det være hensiktsmessig å hente endringer daglig. Fila vil inneholde registreringer både framover og bakover i tid, også reint historiske poster.

Ved oppstart vil det altså være fornuftig å ta med en statusfil for å få med lange permisjoner og annet fravær som gjelder på oppstartsdato.

Ingen filtrering i SAP ved generering av fil

Masterdata legges ut på fil slik de er registrert i SAP. Data bearbeides ikke og det filtreres i utgangpunktet ikke på noen måte. Det finnes likevel noen få unntak.

•     Kontroll på at personen er aktiv i SAP. Kun aktive personer tas med på fila. Det betyr for statustransaksjoner at rapporteringsdato må ligge etter tiltredelsesdato og før fratredelsesdato.

•     Kontroll på aktiv post. Kun aktive poster legges ut. Det betyr av rapporteringsdato må være lik eller seinere enn postens ikrafttredelsesdato (BEGDA) og før posten sluttdato (ENDDA).

•     Ved bestilling av endringsfil fjernes både kontrollen på at personen er aktiv og kontrollen på at posten er aktiv.

•     Det er mulig å ekskludere eksterne fra fila. I så tilfelle ekskluderes medarbeidergruppene (MUG) 8, 9, X og L.

•     IT9001 behandles spesielt og her det er mulig å selektere på om infotypen er utfylt eller ikke.

Det gis ikke «beskjed» om poster som slettes i SAP etter overføring. De kan likevel bli korrigert i noen tilfeller (når gjeldende post i SAP blir forlenget). Dette gjelder begge filtyper og begge transaksjonstyper.