Hvordan fastlægger en Eligibility Engine vilkår og grænser?

En Eligibility Engine kontrollerer vilkårene for brug af EWA, når medarbejderen sender en anmodning. Den skaber ikke optjent løn; den modtager det beregnede resultat og anvender profilstatus, virksomhedspolitik, brugsgrænser og kontrolbetingelser for at afgøre, om anmodningen kan fortsætte og i hvilket omfang.

Hvilket spørgsmål besvarer Eligibility Engine?

To spørgsmål i EWA bliver let blandet sammen:

1. Hvor meget løn har medarbejderen optjent fra godkendt arbejde?
2. Er personen på nuværende tidspunkt berettiget til at bruge tjenesten, og hvor meget må vedkommende modtage?

Det første spørgsmål hører til Earned Wage Engine. Det andet hører til Eligibility Engine.

Adskillelsen forhindrer systemet i at forveksle værdi, som allerede er skabt gennem arbejde, med tilladelse til at bruge en finansiel funktion.

En medarbejder kan have godkendte arbejdsdage uden at have opfyldt profilkravene. Omvendt kan profilen være komplet, selv om der endnu ikke er tilstrækkelig kvalificeret optjent løn.

Seks grupper af vilkår, som normalt skal kontrolleres

En god Eligibility Engine organiserer vilkårene i grupper med klar forretningsmæssig betydning.

Kontrolgruppe	Spørgsmål	Datakilde
Medarbejderstatus	Er profilen aktiv og inden for det gældende omfang?	HRM/ERP
Arbejde og optjent løn	Er der skabt kvalificeret optjent løn?	Earned Wage Engine
Virksomhedspolitik	Er politikken aktiveret for arbejdsstedet?	Policy/configuration
Identitet og konto	Er modtagerprofilen verificeret?	Identity/account
Brugsgrænser	Er den aktuelle anmodning inden for det tilladte omfang?	Policy + transaction ledger
Systemstatus	Kræver en betingelse stop eller tilbageholdelse?	Transaction/monitoring

Hvert vilkår skal have en tydelig datakilde og ejer.

Hvis en regel bygger på data uden en sandhedskilde, er det vanskeligt at forklare, hvorfor en medarbejder blev afvist eller begrænset.

En grænse er et resultat af politikken, ikke optjent løn

I EWA bør en ”grænse” ikke forstås som et særskilt beløb, der tildeles medarbejderen på forhånd.

Earned Wage Engine fastlægger først den allerede optjente løn.

Eligibility Engine kan derefter anvende regler, der indsnævrer det tilladte brugsomfang, men den bør ikke skabe en værdi, som er højere end den kvalificerede optjente løn.

Forholdet kan udtrykkes således:

Brugbar værdi ≤ Kvalificeret optjent løn, som allerede er skabt

For Nhan Kiets adgang til optjent løn er grundberegningen:

Disponibelt beløb = (godkendte arbejdsdage × dagssats) − allerede modtaget i perioden − virksomhedens fastsatte reserve.

Andre brugsvilkår vurderes derefter.

Hvorfor kontrollere igen på anmodningstidspunktet?

En status som ”berettiget” i appen kan allerede være forældet.

Fra medarbejderen åbner skærmen, til anmodningen bekræftes, kan følgende ske:

• en arbejdsregistrering ændres;
• en anden transaktion gennemføres;
• medarbejderstatus ændres;
• kontoen er ikke længere gyldig;
• politikken går over til en ny version;
• en tidligere transaktion afventer stadig.

Serveren skal derfor vurdere berettigelsen igen, når anmodningen oprettes.

Brugerfladen bør kun vise oplysninger; den endelige beslutning skal bygge på de nyeste serverdata.

Hvordan adskiller Eligibility Engine sig fra Earned Wage Engine?

Lag	Hovedspørgsmål	Centrale data
Earned Wage Engine	Hvor meget optjent løn er der skabt?	Arbejde, sats, modtaget beløb, reserve
Eligibility Engine	Må personen bruge tjenesten nu, og i hvilket omfang?	Profil, politik, grænser, konto
Payment Orchestration	Hvordan behandles en gyldig anmodning som transaktion?	Transaktions-id, status, bank

Adskillelsen giver hvert af de tre lag et klart ansvar.

Hvis arbejdsdata ændres, genberegner Earned Wage Engine. Hvis politikken ændres, vurderer Eligibility Engine igen. Hvis banknetværket får timeout, håndterer Payment Orchestration transaktionsstatussen.

Politikker skal have versioner og ikrafttrædelsesdatoer

En almindelig designfejl er kun at gemme den ”nuværende politik”.

Efter nogle måneder kan virksomheden have svært ved at forklare, hvorfor en tidligere transaktion var tilladt, mens en lignende transaktion på et andet tidspunkt ikke var.

Hvert regelsæt bør indeholde:

• versionskode;
• dato og tidspunkt for ikrafttræden;
• anvendelsesområde;
• opretter;
• godkender;
• begrundelse for ændringen;
• aktiv/inaktiv-status.

Når en anmodning vurderes, bør systemet gemme et spor af den anvendte politikversion.

Hvornår skal Eligibility Engine stoppe?

Hvis vigtige data ikke er tilstrækkeligt sikre, bør motoren ikke automatisk give adgang.

Eksempler:

• status for en tidligere transaktion er uklar;
• arbejdsdata fra kilden er modstridende;
• modtagerkontoen er ugyldig;
• profilen er ikke længere aktiv;
• den relevante politikversion kan ikke bestemmes;
• et kildesystem svarer ikke på en verificerbar måde.

I disse situationer er den sikre løsning at tilbageholde anmodningen til kontrol i stedet for at antage, at alt er gyldigt.

Det er det samme fail-closed-princip, som bruges i systemer, der behandler penge.

Årsagskoder er lige så vigtige som resultatet

Eligibility Engine bør ikke kun returnere:

• true;
• false;
• et tal.

Den bør returnere strukturerede årsager, for eksempel:

• ingen godkendte arbejdsdage;
• profil ikke verificeret;
• funktionen ikke aktiveret af kunden;
• anmodningen overstiger det tilladte omfang;
• en transaktion afventer;
• kontoen skal verificeres igen.

Årsagskoder hjælper med at:

• forklare resultatet i brugerfladen;
• støtte opslag og undersøgelser;
• klassificere fejl i driften;
• måle statistik;
• revidere beslutninger.

Følsomme tekniske detaljer behøver ikke at blive vist, men brugeren skal vide, hvad næste skridt er.

Hvordan bør virksomheden styre Eligibility Engine?

Eligibility Engine bør behandles som en eksekverbar politik, ikke blot som et stykke kode.

Hver vigtig regel bør have:

• en forretningsansvarlig;
• en datakilde;
• en ikrafttrædelsesdato;
• en begrundelse;
• et anvendelsesområde;
• en metode til undtagelseshåndtering;
• en ændringshistorik.

Produkt- og lønteams skal være enige om grænsen mellem optjent løn og den del, der må bruges.

Driftsteamet skal vide, hvorfor en anmodning blev tilbageholdt.

Supportteamet skal have tilstrækkeligt klare årsagskoder til at forklare resultatet uden adgang til følsom teknisk konfiguration.

KPI'er, der bør følges

Mulige målinger omfatter:

• berettigelsesprocent;
• tilbageholdelsesprocent på grund af manglende godkendt arbejde;
• tilbageholdelsesprocent på grund af profil eller konto;
• anmodninger blokeret af en afventende transaktion;
• antal politikændringer;
• klager over berettigelse;
• andel af beslutninger med komplette årsagskoder;
• undtagelser, der kræver manuel behandling.

KPI'er bør ikke optimeres mod ”at tillade så mange transaktioner som muligt”. Målet er korrekte vilkår, forklarlighed og ensartethed.

Konklusion

Eligibility Engine hjælper EWA med at adskille allerede skabt optjent løn fra retten til at bruge tjenesten på et bestemt tidspunkt. En god motor revurderer vilkårene ved anmodningen, bruger versionsstyrede politikker, returnerer tydelige årsagskoder og stopper, når vigtige data er usikre. Dermed kan virksomheden ændre politik og samtidig bevare lønintegritet og forklarlighed for medarbejderen.

Forfatter: Do Huy Le — Tổng Giám Đốc, Nhan Kiet Manpower Supply Co., Ltd.

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