Hvilke data er nødvendige for at integrere adgang til optjent løn med tidsregistrering, løn og ERP?

Hvilke data er nødvendige for at integrere adgang til optjent løn med tidsregistrering, løn og ERP?

For at integrere adgang til optjent løn med tidsregistrering, løn og ERP, skal virksomheder have mindst fem datagrupper: medarbejderoplysninger, godkendte timer, lønperioder og regler, justeringer eller fradrag, og tidlige lønudbetalinger. Alt skal bruge en ensartet medarbejderkode, have status, opdateringstidspunkt, dataversion og sporingslog. En god arkitektur skal ikke kun overføre data hurtigt, men også forhindre dobbeltbetalinger, håndtere sene dataændringer og afstemme hver transaktion.

> Bemærk: Artiklen præsenterer en referencearkitektur for et system til adgang til optjent løn (Earned Wage Access). Feltnavne, statusser, godkendelsesflow og faktiske bogføringsmetoder skal bekræftes af Nhan Kiet og virksomheden under integrationsundersøgelsen.

> Ordforklaring: Adgang til optjent løn (modtagelse af løn for udført arbejde) · HRIS/HRM (Human Resource Information System) · ERP (Enterprise Resource Planning) · løn (payroll) · API (Application Programming Interface) · batch (batch-behandling) · SFTP (Secure File Transfer Protocol) · idempotency (duplikatbeskyttelse: gentagne anmodninger skaber kun ét resultat) · UAT (User Acceptance Testing) · go-live (driftsstart) · rollback (tilbageførsel) · webhook/callback (automatisk notifikation mellem systemer) · token (erstatningskode for originale data) · data dictionary (datadictionary) · system of record (primær datakilde) · retry (gentagelse) · timeout (tidsbegrænsning).

Hvorfor skal adgang til optjent løn forbindes med både tidsregistrering, løn og ERP?

Adgang til optjent løn skal besvare tre spørgsmål, før en medarbejder kan modtage penge:

1. Arbejder denne person og er de en del af programmet?

2. Hvor meget kvalificeret løn har de optjent indtil nu?

3. Efter tidligere transaktioner og nødvendige tilbageholdelser, hvor meget kan de stadig modtage?

HR-systemer bekræfter normalt identitet og ansættelsesstatus. Tidsregistreringssystemer registrerer arbejdstimer. Lønsystemer kender lønregler, lønperioder og justeringer. ERP eller regnskabssystemer håndterer registrering, afstemning og afregning. Betalingssystemer leverer den endelige betalingsstatus.

Hvis der kun er forbindelse til én kilde, kan adgang til optjent løn se medarbejderen, men ikke de godkendte timer; eller se timerne, men ikke om lønperioden er lukket; eller at pengene er overført, men lønsystemet har ikke modtaget transaktionen til afstemning. Derfor er det vigtigste ikke bare at "forbinde API'en", men at etablere en konsistent datakæde fra udført arbejde til afregnet transaktion.

1. Overordnet dataarkitektur

En referencearkitektur kan organiseres som følger:

flowchart TD
    A["HRIS: medarbejdere"] --> D["Integrationslag"]
    B["Tidsregistrering: godkendte timer"] --> D
    C["Løn: lønperioder og regler"] --> D
    D --> E["EWA grænseberegner"]
    E --> F["EWA applikation"]
    F --> G["Betalingssystem"]
    G --> H["Afstemning af løn, ERP og regnskab"]
    H --> E

Hvert datadomæne bør have en primær datakilde (system of record). HRIS, løn og EWA bør ikke ændre en attribut på tre forskellige måder.

2. Minimumsliste over medarbejderdata

Det er ikke nødvendigt at synkronisere hele medarbejderdatabasen bare fordi "det kan være nødvendigt". Den passende tilgang er at indsamle og overføre præcis de data, der er nødvendige for det identificerede formål.

Fuldstændige kontonumre bør kun eksistere i det domæne, der faktisk har brug for dem til betaling, og bør være korrekt autoriseret og beskyttet. Testmiljøer bør bruge falske eller skjulte data, ikke kopiere produktionsdata.

3. Tidsregistreringsdata og godkendelsesstatus

Adgang til optjent løn bør ikke kun modtage et "månedligt total". Systemet har brug for tilstrækkelig information til at vide, hvilke data der er bekræftet, og hvilke der stadig kan ændres.

De nødvendige felter inkluderer:

• employee_id: ensartet medarbejderkode;

• work_date: arbejdsdato;

• shift_id: skiftkode, hvis virksomheden administrerer efter skift;

• regularhours, overtimehours: almindelige arbejdstimer og overarbejdstimer;

• attendance_status: tilstedeværende, på orlov, fraværende eller tilsvarende status;

• approval_status: afventer godkendelse, godkendt, afvist, justeret eller låst;

• approvedby, approvedat: godkendt af og tidspunkt, hvis politikken kræver det;

• sourceupdatedat, record_version: tidspunkt og version af posten;

• source_system: systemet, der genererede dataene.

Hvorfor er "godkendt" status vigtig?

Et enkelt swipe af et adgangskort er ikke nødvendigvis en gyldig arbejdstime. Medarbejdere kan glemme at tjekke ud, registrere forkerte skift eller foretage ændringer efter godkendelse. Virksomheder skal klart definere, hvilken status der tæller med i grænsen for adgang til optjent løn (se Hvad er godkendte timer?).

Eksempel på en illustrativ post:

{
  "employee_id": "EMP-000123",
  "work_date": "2026-08-18",
  "shift_id": "SHIFT-A",
  "regular_hours": 8,
  "overtime_hours": 0,
  "approval_status": "APPROVED",
  "source_updated_at": "2026-08-19T02:15:30Z",
  "record_version": 3
}

Dette er kun et sikkert dataeksempel til illustration, ikke en officiel API-specifikation for adgang til optjent løn.

4. Løndata og justeringer

Løndata hjælper med at konvertere "godkendte timer" til "kvalificeret lønbeløb". Datasættet inkluderer typisk:

• lønperiode-id payperiodid og start- og slutdatoer;

• løngruppe og løncyklus;

• lønberegningsgrundlag eller nødvendige satser for den aftalte formel;

• indkomstkode earning_code;

• relevante justeringer, tilbageholdelser eller fradrag;

• dato for afslutning af timer og tidspunkt for lønlukning;

• lønperiodestatus: åben, under behandling, låst eller afregnet;

• valuta og afrundingsregler;

• anvendt formel/politikversion.

Ikke alle elementer på lønsedlen tæller med i grænsen for adgang til optjent løn. Grundløn, tillæg, overarbejde, bonusser eller provisioner har forskellige grader af sikkerhed og godkendelsestidspunkter. Virksomheder skal oprette en regelmatrix, der klart angiver, hvilke elementer der tæller med, fra hvilken status og med hvilke begrænsninger.

Hvilke kolonner bør regelmatrixen have?

De faktiske værdier i denne tabel skal bekræftes af virksomheden og implementeringsenheden. Det er ikke hensigtsmæssigt at gætte ud fra indkomstnavne.

5. Data om tidlige lønudbetalinger

Hver anmodning om tidlig lønudbetaling skal være en uafhængigt sporbar transaktion.

En reference transaktionslivscyklus inkluderer: CREATED → VALIDATING → PROCESSING → SUCCEEDED eller FAILED. Hvis betalingsresultatet ikke er bestemt, bør transaktionen være i status UNKNOWN eller tilsvarende til undersøgelse; det bør ikke automatisk antages som mislykket og derefter overføres igen. Systemet skal også have status for tilbagebetaling og afstemning, når det er relevant.

6. Skal man vælge API, batch-filer eller manuel synkronisering?

Der er ikke én metode, der passer til alle virksomheder. Det kan være nødvendigt at kombinere flere metoder afhængigt af modenheden af hvert system.

Hvis der bruges HTTP API, kan virksomheden beskrive integrationskontrakten med OpenAPI Specification for at blive enige om endpoint, datastruktur og respons. OpenAPI er en standard til beskrivelse af HTTP API'er; det er en nyttig teknisk mulighed, men ikke en betingelse for at implementere adgang til optjent løn.

7. Identifikation og duplikatbeskyttelse

Forkert identifikation er en af de farligste risici. E-mails, telefonnumre eller kontonumre kan ændre sig, så de er ikke egnede som primære medarbejdernøgler.

Anbefalinger:

• brug en uforanderlig employee_id inden for en virksomhed;

• kombiner med employerid eller legalentity_id, hvis platformen betjener flere enheder;

• genbrug ikke koder fra tidligere ansatte til nye medarbejdere;

• oprethold en kortlægningsoversigt, når HRIS og løn bruger forskellige kodesæt;

• registrer ikrafttrædelsesdatoer for ændringer i løngrupper, enheder og ansættelsesstatus;

• kontroller duplikater efter forretningsnøgler, ikke kun efter ens indhold.

Med batch-filer bør hver fil have en batch-kode, oprettelsestidspunkt, samlet antal poster og checksum. Med API bør hver transaktionsanmodning have en idempotency_key.

8. Idempotency og afstemning: to forskellige beskyttelseslag

Idempotency sikrer, at en anmodning, der sendes flere gange, kun skaber ét forretningsresultat. For eksempel, hvis en applikation oplever timeout efter at have sendt en betalingsordre. Når den sendes igen med samme idempotency_key, skal systemet returnere den gamle transaktion eller dens status, i stedet for at oprette endnu en betaling.

Afstemning kontrollerer, om systemerne registrerer en transaktion ens (forbundet med adgang til optjent løn-processen fra tidsregistrering til afstemning). En passende model er en trevejsafstemning:

1. transaktion i EWA-platformen;

2. resultat fra bank eller betalingsenhed;

3. data fra løn/ERP eller godkendte afregningsoplysninger.

Afstemningsrapporter bør mindst angive:

• fuldt matchende transaktioner;

• findes i EWA, men mangler betalingsresultat;

• har betalingsresultat, men mangler i løn/ERP;

• forskelle i beløb, gebyrer, modtager eller lønperiode;

• tilbagebetalingstransaktioner, der ikke er opdateret;

• duplikatposter eller forkert opdateringsrækkefølge.

Hver forskel skal have en ansvarlig person, behandlingsstatus og bevis for lukning.

9. Fejlhåndtering, retry og advarsler

Ikke alle fejl bør automatisk forsøges igen.

Alle anmodninger bør have en correlation_id til systemomfattende sporing. Advarsler skal indeholde transaktionskode, fejltype, tidspunkt, kildesystem og næste trin, men ikke inkludere adgangskoder, API-nøgler eller fulde følsomme data i loggen.

10. Eksempel på API-anmodning

{
  "idempotency_key": "ewa-demo-20260818-0001",
  "employee_id": "EMP-000123",
  "pay_period_id": "2026-08",
  "requested_amount": 1000000,
  "currency": "VND",
  "source_data_version": "attendance-v18_payroll-v6",
  "requested_at": "2026-08-18T09:20:00+07:00"
}

Svaret bør angive, om anmodningen er accepteret, afvist eller kræver yderligere behandling; samtidig returnere transactionid, status, årsagskode og correlationid. Det bør ikke returnere fulde kontodata eller unødvendige oplysninger.

API-specifikationen bør klart angive:

• godkendelses- og autorisationsmetoder;

• API-version og ændringspolitik;

• dato- og tidsformat, tidszone og valuta;

• præcision af beløb og afrundingsregler;

• fejlkodekatalog;

• timeout og retry-politik;

• signatur/verifikation af callback eller webhook;

• belastningsgrænser;

• idempotency-regler;

• lognings- og statusopbevaringstid.

11. Sikkerhed og databeskyttelse fra designfasen

Medarbejderdata, løn, modtagerkonti og transaktionshistorik har høj følsomhed. Integrationsdesign bør inkludere:

• rollebaseret adgangskontrol og princippet om mindst privilegium;

• kryptering af data under transmission og opbevaring;

• centraliseret hemmelighedsstyring, undgå adgangsnøgler i kildekode eller log;

• adskillelse af udviklings-, test- og produktionsmiljøer;

• simulerede eller skjulte testdata;

• adgangs- og konfigurationsændringslog;

• opbevaringsperioder, sletningsprocedurer og databehandlingsanmodninger;

• leverandørvurdering og datadelingens omfang;

• beredskabsplaner, hændelsesmeddelelser og undersøgelsesprocedurer.

I Vietnam skal design og drift gennemgås af juridiske afdelinger i henhold til Lov om beskyttelse af persondata nr. 91/2025/QH15 og Dekret 356/2025/NĐ-CP, begge gældende fra 1. januar 2026. Elektroniske dokumenter, beskeder og beviser skal også overvejes inden for rammerne af Lov om elektroniske transaktioner 2023 og relevante sektorspecifikke regler.

12. UAT-tjekliste før go-live

UAT bør ikke kun kontrollere "modtagelse af fil" eller "API returnerer 200" (inkluder i 90-dages pilotplan for adgang til optjent løn). Det er nødvendigt at teste alle forretningsscenarier og driftsfejl.

Medarbejdere og deltagelsesbetingelser

• [ ] Medarbejdere, der arbejder og er kvalificerede.

• [ ] Nye medarbejdere, der endnu ikke er trådt i kraft.

• [ ] Medarbejdere på orlov eller fratrådt.

• [ ] Medarbejdere, der skifter juridisk enhed, løngruppe eller medarbejderkode.

• [ ] Ændring af modtagerkonto i henhold til korrekt verifikationsproces.

Tidsregistrering og grænser

• [ ] Timer, der afventer godkendelse, tæller ikke, hvis politikken kræver godkendte timer.

• [ ] Godkendte timer ændrer grænsen korrekt.

• [ ] Timer, der ændres eller tilbagekaldes efter godkendelse, beregnes korrekt igen.

• [ ] Gamle data, der ankommer efter nye data, overskriver ikke forkert version.

• [ ] Afslutningsdatoer, tidszoner og nattevagter håndteres korrekt.

Transaktioner og betalinger

• [ ] Gentagne anmodninger med samme idempotency_key skaber ikke to transaktioner.

• [ ] Utilstrækkelig grænse returnerer præcis årsag.

• [ ] Betalingssystem-timeout og uklare resultater forårsager ikke dobbeltbetaling.

• [ ] Mislykkede transaktioner, tilbagebetalinger og statusændringer opdateres korrekt.

• [ ] Grænser før og efter transaktioner stemmer overens med transaktionsbogen.

Batch-filer og API

• [ ] Duplikatfiler, forkert rækkefølge og duplikatposter opdages.

• [ ] Nogle fejlposter påvirker ikke allerede behandlede poster.

• [ ] API-autentificering udløbet, manglende tilladelser og overskredne belastningsgrænser returnerer korrekte fejl.

• [ ] Falske eller forkert signerede callbacks afvises.

• [ ] Retry overholder begrænsninger og bevarer duplikatbeskyttelsesnøgle.

Løn, ERP og afstemning

• [ ] Åbne, låste og afregnede lønperioder håndteres korrekt.

• [ ] EWA-transaktioner inkluderes i lønperiodeafstemning i henhold til godkendt proces.

• [ ] Tre kilder EWA – betaling – løn/ERP stemmer overens i beløb og status.

• [ ] Forskelle skaber advarsler og har en behandlingsproces indtil lukning.

• [ ] Rapporter kan spores fra bogføring til transaktioner og kildedata.

Sikkerhed og drift

• [ ] Uautoriserede personer kan ikke se eller ændre data.

• [ ] Log indeholder ikke hemmeligheder eller fulde følsomme data.

• [ ] Adgangsnøgler kan roteres uden langvarige afbrydelser.

• [ ] Der er personale på vagt, advarselskanaler og hændelseshåndteringsprocedurer.

• [ ] Der er en rollback-plan, hvis go-live oplever alvorlige fejl.

13. Teknisk dokumentation, der skal aftales før implementering

Et minimumssæt af integrationsdokumentation bør indeholde:

1. arkitekturdiagram og ansvarsgrænser;

2. datadictionary for hvert felt;

3. kortlægningsoversigt for medarbejderkoder, lønperioder, enheder og indkomstkoder;

4. API-specifikation eller filspecifikation;

5. status- og fejlkodekatalog;

6. godkendte grænseberegningsregler;

7. duplikatbeskyttelses-, retry- og sene datahåndteringsregler;

8. afstemningsflow og forskelsrapporteringsskabelon;

9. autorisationsmatrix og sikkerhedskrav;

10. UAT-, cutover-, rollback- og supportplan efter go-live.

Parterne bør også udføre datakontraktstest. Når et system ændrer feltnavne, datatyper, statuskataloger eller forretningsbetydning, skal pipeline advare før ændringer forårsager forkerte grænser uden for produktionsmiljøet.
14. Oplysninger, som Nhân Kiệt skal supplere, inden den officielle version offentliggøres

For at sikre, at artiklen afspejler Lương Ngàys faktiske kapacitet korrekt, skal Product/IT-teamet bekræfte følgende:

• de tidsregistreringssystemer, lønsystemer (Payroll) eller ERP-systemer, der aktuelt understøttes;

• de eksisterende integrationsmetoder: API, SFTP, eksempelfiler eller andre metoder;

• synkroniseringsintervaller og de faktiske serviceniveauforpligtelser;

• en liste over endpoints, datafelter, statusser og fejlkoder, som må offentliggøres;

• de autentificeringsmekanismer, Idempotency, Webhooks og afstemningsmekanismer, der anvendes;

• behandlingsflowet for transaktioner med uklar status, mislykkede transaktioner og tilbagebetalinger;

• reglerne for beregning af beløbsgrænser og de lønkomponenter, der er berettigede;

• eksempler på tekniske rapporter, hvor personoplysninger er fjernet;

• ansvarsområderne for Nhân Kiệt, virksomheden og betalingspartneren;

• kontaktpunktet for modtagelse af integrationsdokumentation og support til UAT.

Navne på partnere, behandlingstider, SLA'er eller tekniske funktioner bør ikke offentliggøres, før de er blevet bekræftet skriftligt.
Ofte stillede spørgsmål

Er det obligatorisk at integrere adgang til optjent løn i realtid?

Nej. Virksomheder kan bruge API i næsten realtid, batch-filer efter tidsplan eller kontrollerede manuelle processer i pilotfasen. Frekvensen skal passe til grænseberegningsmetoden, dataændringshastigheden og driftskapaciteten af kildesystemerne.

Er tidsregistreringsdata alene nok til at beregne grænsen for adgang til optjent løn?

Normalt ikke. Der kræves yderligere medarbejderstatus, lønperioder, lønberegningsregler, relevante justeringer og EWA-transaktionshistorik. Registrerede timer skal også have en klar godkendelsesstatus.

Hvorfor skal der bruges samme medarbejderkode?

En ensartet identifikation hjælper med at undgå at tildele timer, løn eller transaktioner fra én person til en anden. Hvis systemerne bruger forskellige koder, skal virksomheden have en kontrolleret kortlægningsoversigt med ikrafttrædelsesdatoer.

Er idempotency det samme som kontrol af duplikattransaktioner?

De er relaterede, men ikke helt det samme. Idempotency sikrer, at gentagne anmodninger ikke skaber nye forretningsresultater. Duplikatkontrol kan også bruge andre forretningsnøgler til at opdage to forskellige anmodninger, der i virkeligheden er én transaktion.

Skal man gensende en betalingsordre straks efter timeout?

Nej, man bør ikke gensende en ny betalingsordre, før resultatet af den gamle er bestemt. Systemet skal holde status som ukendt, forespørge efter referencenummeret og kun fortsætte i henhold til den fastlagte proces for at undgå dobbeltbetaling.

Hvem har ansvaret for afstemning af adgang til optjent løn?

Ansvaret skal defineres i driftsmatricen. Normalt vil det involvere EWA-driftsenheden, løn, regnskab/finans, IT og betalingspartneren. Hver type forskel skal have en specifik ansvarlig.

Konklusion

Integration af adgang til optjent løn er ikke bare at trække en tidsregistreringsfil og beregne en procentdel. Et pålideligt system kræver medarbejderdata, godkendte timer, lønregler og transaktioner, der er forbundet med en ensartet identifikation; samtidig med at det har dataversioner, idempotency, betalingsstatus, afstemning og fejlhåndteringsprocedurer.

Hvis din virksomhed overvejer at forbinde adgang til optjent løn med eksisterende tidsregistrerings-, løn- eller ERP-systemer, bør du forberede et systemdiagram, en datadictionary uden personlige data og de forretningsscenarier, der skal understøttes, og derefter udforske adgang til optjent løn for virksomheder for at diskutere teknisk integrationsdokumentation og passende pilotomfang.

Kilder

• OpenAPI Initiative – OpenAPI Specification

• OpenAPI Specification på GitHub

• Lov om beskyttelse af persondata nr. 91/2025/QH15

• Dekret 356/2025/NĐ-CP vejledning til Lov om beskyttelse af persondata

• Lov om elektroniske transaktioner nr. 20/2023/QH15

---

Forfatter: Ngô Nhã Kỳ — Redaktør , Nhan Kiet Manpower Supply Co., Ltd.

Rådgivning om adgang til optjent løn for virksomheder: Hotline 0937.022.655 · Email info@nhankiet.vn · Adgang til optjent løn for virksomheder