Forklaring: Sådan arbejder DataLøn-integrationen
Denne side forklarer, hvordan DataLøn-integrationen arbejder. Den er tænkt til den, der skal fejlsøge eller forstå, hvorfor systemet gør, som det gør – ikke som en opskrift. Fremgangsmåderne står i vejledningerne.
Én vej, med vilje
INNOMATE HR sender data til DataLøn. DataLøn sender ikke noget tilbage.
Det er et bevidst valg. HR ejer medarbejderens stamdata: navn, adresse, CPR-nummer og bankkonto. Lønsystemet ejer lønnen. Ved at lade den ene side være kilden slipper I for at skulle afgøre, hvilken af to forskellige adresser der er den rigtige.
Konsekvensen er til at tage og føle på: en rettelse, der laves i DataLøn på et af de synkroniserede felter, bliver overskrevet ved næste kørsel. Retter man i INNOMATE HR, holder rettelsen.
Den eneste undtagelse er medarbejderens id i DataLøn, som skrives tilbage til ansættelsen. Det er ikke data om medarbejderen – det er en henvisning, så næste kørsel kan finde den samme post igen.
Kun det, der er ændret
Integrationen kører med få minutters mellemrum og sender kun de personer, der er ændret siden sidst. Det holder belastningen nede på begge sider, men det har to følger, som er værd at kende:
- En ændring, du laver, når integrationen ikke kører – om natten – bliver sendt næste morgen.
- En datafejl på en person, ingen rører ved, bliver hverken gentaget eller lukket. Den står, som den stod, indtil nogen ændrer noget på personen.
Den anden er den, der overrasker. Fejlene på integrationssiden er ikke en liste over problemer, der lige er opstået – de er en liste over problemer, der var der, sidst systemet kiggede.
Sådan genfindes den rigtige medarbejder
Hver gang en person skal sendes, skal integrationen finde den tilsvarende post i DataLøn. Den prøver i denne rækkefølge:
- Det gemte id. Er personen sendt før, kender integrationen medarbejderens id i DataLøn og bruger det direkte. Det er det normale tilfælde.
- CPR-nummeret. Kendes id'et ikke, gennemgår integrationen lønfirmaets medarbejdere og kladder og matcher på CPR-nummer.
- Opret. Findes personen ikke, oprettes en ny kladde.
Derfor er CPR-nummeret vigtigt, selvom det ikke er påkrævet. Uden det findes der ingen reserveløsning, hvis id'et går tabt – for eksempel hvis svaret på en oprettelse forsvandt undervejs. Så bliver personen oprettet en gang til, og de to poster kan ikke kobles automatisk.
Når et CPR-nummer peger to steder hen
CPR-nummeret er ikke en garanti for én medarbejder:
- Flere DataLøn-poster med samme CPR-nummer. En aktiv post vinder over en fratrådt – det er en helt almindelig genansættelse. Er de ellers ens, vælges den samme hver gang, så resultatet er forudsigeligt. Er valget reelt tvivlsomt, får du en advarsel med det valgte id.
- To personer i INNOMATE HR med samme CPR-nummer. Den ene bindes til DataLøn-posten. Den anden springes over med en fejl frem for at skrive hen over den førstes data. Fejlen rapporteres, første gang det sker – men ikke nødvendigvis hver gang derefter, fordi den, der allerede har fundet sin post, holder op med at slå op. Så en dublet, du får besked om én gang, skal håndteres, selvom beskeden ikke kommer igen.
Flet dubletter i INNOMATE HR, og ryd dubletter i DataLøn. Se Vejledning: Find dubletter.
Nye medarbejdere oprettes som kladder
En ny medarbejder oprettes som en kladde i DataLøn, ikke som en færdig medarbejder. Kladden indeholder det, INNOMATE HR kender – navn, CPR-nummer, adresse, e-mail og bankoplysninger.
Grunden er, at en medarbejder ikke kan oprettes færdig uden løndata, og dem har HR ikke. Lønmedarbejderen aktiverer kladden i DataLøn og udfylder resten. Det giver samtidig lønmedarbejderen en kontrol, inden en ny person kommer på lønningslisten.
Indtil kladden er aktiveret, kan en fratrædelse ikke gennemføres – DataLøn har ingen fratrædelse på en kladde. Integrationen holder fast i fratrædelsen og forsøger igen, indtil kladden er aktiv.
Et felt, der ikke kan sendes, koster ikke resten
DataLøn afviser hele opdateringen, hvis blot ét felt er uden for de tilladte grænser. Derfor kontrollerer integrationen felterne, før den sender:
- Et felt uden for grænserne udelades, og du får en advarsel med feltets navn. Resten af opdateringen går igennem.
- Værdier afkortes aldrig. En adresse, der klippes af ved 32 tegn, er en forkert adresse, som ingen opdager. En manglende adresse er blot forældet – og den kommer med en advarsel.
- Adressens fire felter sendes samlet. Ellers ville DataLøn kunne ende med den nye by og det gamle vejnavn efter en flytning.
- Registreringsnummeret udfyldes med foranstillede nuller, fordi et registreringsnummer altid er fire cifre og derfor kun kan læses på én måde. Kontonummeret udfyldes ikke, fordi der ikke findes én rigtig læsning – og fordi en udfyldning ville lave et ufuldstændigt kontonummer om til et, der ser gyldigt ud.
Når DataLøn alligevel afviser
Bliver en opdatering afvist af DataLøn, lægger integrationen den ene person til side i stedet for at prøve igen i det uendelige. Resten af medarbejderne synkroniseres videre.
Personen bliver liggende, indtil vedkommende ændres i INNOMATE HR. Så bliver posten sendt igen, og lykkes det, lukker datafejlen sig selv. Der er ingen kø at tømme og ingen karantæneliste at vedligeholde.
Prisen er, at en fejl, der ligger sådan, ikke bliver ved med at melde sig. Forekomster og Sidst rapporteret står stille, så en fejl, der ikke har rørt sig i en uge, kan lige så godt være aktiv som løst. Datoen fortæller, hvornår problemet sidst blev set – ikke hvornår det holdt op.
Ændringer, der venter
Nogle ændringer kan ikke sendes med det samme – for eksempel til et lønfirma, hvis forbindelse er afbrudt, eller en fratrædelse på en kladde, der endnu ikke er aktiveret. De lægges i kø og forsøges igen med voksende mellemrum.
Efter 30 dage opgives en ændring med en datafejl. Den er ikke tabt: næste fulde kørsel, eller næste gang personen ændres, sender den igen.
Hvorfor fejlene står på integrationssiden
Fejlene fra DataLøn lander i INNOMATE HR i stedet for i en periodisk e-mail. En mail er et øjebliksbillede, ingen kan markere som håndteret, og den samme fejl fylder indbakken hver dag, indtil nogen retter den.
På integrationssiden kan I i stedet kvittere, ignorere og genåbne, og fejlen tælles op frem for at blive oprettet forfra. Til gengæld skal nogen huske at kigge på siden.
Fejlene lukker sig selv, når en senere kørsel har gennemgået hele personen uden at støde på problemet. Kan en kørsel ikke nå at gennemgå hele personen, tilføjer den, hvad den fandt, og lukker ikke noget. Det er den forsigtige vej: det er bedre at se en fejl for meget end at få lukket en, der stadig er der.