UnemploymentBenefitsAccountService (2023-2)

Servicen udstiller metoder til at oprette og opdatere tællere som beskriver borgers indplacering.

Create- og Updatemetoderne i servicen er kun tilgængelig for a-kasser. Get-metoden er også tilgængelig for bl.a. jobcentre.

Forretningsregler

Adgang til servicen

Generelt valideres der for, at a-kasserne kun må inddatere for egne aktuelle medlemmer og at borgeren ikke er død. I særlige tilfælde kan der opdateres tællere for et tidligere medlem, der ikke er overgået til medlemskab af en anden a-kasse. Tidligere a-kasse kan kalde createmetoden i op til 3 år efter medlemsafgang.

Hvis et medlems tidligere a-kasse indberetter tæller oplysninger efter overgang til en ny a-kasse, gemmes disse oplysninger ikke i DFDG, men sendes alene som WSRM-besked til den nye a-kasse. Se nærmere under beskrivelsen af GetBenefitsAccountFromFormerUnemploymentFund (beskrevet under metoden CreateBenefitsAccount). 

Tidligere a-kasse kan kalde GetUnemploymentBenefitsAccountInfo-metoden op til 120 dage efter medlemsafgang.

Timetal

Timetal kan indrapporteres med 2 decimaler, hvor decimaler angiver hundrededele. Fx vil 7,40 timer svare til 7 timer og 24 minutter.

Update-metoderne

For update-metoderne valideres der for om borger har en dagpengetællerindplacering.

A-kasser kan ikke kalde Update-metoderne for tidligere medlemmer aht. at alle parter skal være enige om datagrundlaget for det indberettede. Dette er også gældende, hvis borgeren ikke længere er medlem af en A-kasse.

Create (nyinplacering) eller Update ved opdatering af de enkelte tællere?

Generelt

Ved opdatering af de enkelte tællere (efter den første Create) kan a-kassen i medlemsperioden vælge, om efterfølgende indberetninger af opdatering af de enkelte tællere sker vha. Update-metoderne eller som ét samlet servicekald med indberetning af alle aktuelle tæller-værdier via Create-metoden. Friheden er af hensyn til den enkelte a-kasses implementering.

Hvis Create-metoden anvendes er det vigtigt, at alle aktuelle tællerværdier indberettes ved hvert kald af Create-metoden, da tidligere indberettede tællerværdier blankes af DFDG, hvis et tæller-element er udeladt i Create-metoden.

Samtidig opdatering af 2 til flere dagpengetællere

Ønsker man, som A-kasse, en samtidig opdatering af to eller flere dagpengetællere, såsom referenceperiode (ReferentialPeriod), sats (BenefitsRate) m.fl., kan man kalde CreateBenefitsAccount. I denne situation skal man først hente borgerens aktuelle dagpengetællere fra DFDG, hvis man ikke allerede har disse oplysninger til rådighed. Herefter laves et nyt Request og kald til CreateBenefitsAccount med det fulde billede af borgerens ”nye” dagpengetællere. Det værende sig det fulde billede af borgerens dagpengetællere inklusiv de opdateringer, som ønskes registreret i DFDG.

Opdatering af 1 enkeltstående dagpengetæller

Ønsker man, som A-kasse, kun at opdatere én enkeltstående dagpengetæller, såsom referenceperiode (ReferentialPeriod), sats (BenefitsRate) m.fl., kan man kalde Update metoden til den dagpengetæller, som ønskes opdateret, eksempelvis UpdateReferentialPeriode, UpdateBenefitsRate m.fl.

Update metoderne opdaterer kun den dagpengetæller, som man kalder ind med og rører dermed ikke andre dagpengetællere, som er registreret på borgeren.

Hver enkelt kald af Update-metode sender en WSRM besked indeholdende alle borgerens i DFDG registrerede dagpengetællere. 

Der henstilles til ikke at kalde Update metoderne hvis der ikke er ændringer til den enkelte dagpengetæller, da dette vil medføre ny registrering i DFDG (med de samme værdier) samt udsendelse af en WSRM besked indeholdende alle borgerens i DFDG registrerede dagpengetællere.

Samtidig opdatering af 2 til flere dagpengetællere i modsætning til opdatering af 1 enkeltstående dagpengetæller

I forbindelse med opdateringer til dagpengetællere skal man som A-kasse overveje sine kaldemønstre mod DFDG.

Det er blandt andet ikke nødvendig at opdatere de enkelte dagpengetællere med Update metoder, hvis værdier i tællerene ikke er ændret.

Gennemtænkt servicebrug i dagsrytmen

Det er et problem hvis servicen kaldes meget hyppigt. Der henstilles derfor til kun at kalde når der er opdateringer på forretningsmæssige data (ikke metadata såsom RegisterInformationTime og CalculationDate).

Hent om muligt data fra eksterne registre inden sagsbehandling, så man ved indberetning af opdateringer efter endt sagsbehandling har et så komplet billede som muligt.

Minimumsfrekvens for opdatering - selv om der kun er ændrede metadata

En opdateringsfrekvens på mindst 1 gang om måneden er formålstjenlig - selv hvis der ikke er ændringer til andet end metadata.

Påkrævede dagpengetællere

Forretningmæssigt er følgende tællere påkrævede for at have et validt dagpengetællersæt:

Indplacering (BenefitsGrading), 
Udløb af dagpengeret (BenefitsExpiry), 
Referenceperiode (Referential Period),
Genindplaceringskonto (RegradingAccount), 
Forbrug (Consumption)
Karenstæller (QualifyingHours)

Derudover så skal alle tællere der tidligere er indberettede, medtages i et create-kald medmindre der er tale om en nyindplacering (som indikeres med newgrading).

Eksempel - forlængelser

Ved fx forlængelser (og forlængelser i forlænget dagpengeperiode) har a-kassen kunstnerisk frihed mellem Create (med angivelse af at der er tale om den forlængede dp.periode) eller Update af de relevante tællere, der berøres af forlængelse af forlængelsesperioden. Friheden er af hensyn til den enkelte a-kasses implementering.
Hvis Update-metoderne anvendes skal følgende tællere opdateres: - Referenceperiode (hvis udløbsmåned er ændret siden sidste indberetning) - Forbrug (hvis forbrug er ændret siden sidste indberetning) - Udløb af dp.ret (hvis dato ændret siden sidste indberetning) - Beskæftigelseskonto - Genindplacerinskonto

Medlemmet skifter A-kasse eller melder sig ud af A-kassen

Hvis en borger ikke er medlem af en A-kasse, kan borgerens tidligere A-kasse fortsat indrapportere opdaterede tællere til DFDG. Dette kræver dog en fuld indplacering af hensyn til, at alle parter er enige om datagrundlaget for det indberettede.

Den tidligere a-kasses indrapporteringer af de enkelte tællere vil i DFDG være de gældende, indtil den nye a-kasse har opdateret tællerne i DFDG. For et medlem, der skifter a-kasse, kan personens tællere i DFDG derfor være opgjort og beregnet af én eller flere a-kasser.

Skæringsdato for skift imellem a-kasser

Ejerskabet af en borger skifter til ny a-kasse straks når MT modtages.

Brug af fiktive datoer hvor dato ikke kendes

Som udgangspunkt skal man undlade at indberette data hvis man ikke har korrekte forretningsdata. Det kan også være relevant at undlade at indberette en hel tæller, når man ikke har komplette forretningsmæssige data til tælleren. 

Eksempel: Ingen timer på Beskæftigelseskontoen (EmploymentAccount), hvorved der ikke meningsfuldt kan angives en ExpectedObsoleteDate. I dette tilfælde undlader a-kassen at medsende hele tælleren. 

Fiktiv dato for Genindplaceringskonto (RegradingAccount)

 - hvor der ikke er nogen timer (RegradingHours) at beregne ud fra. Da sættes HoursCompletionDeadlineDate til indberetningsdato + 3 år (som er den nærmeste tilnærmelse der kan laves til kommende timers forfaldsdato).

WSRM beskeden GetUnemploymentBenefitsAccount (Version3)

Udsendelsesregler ift. jobcentre

Gældende ved både indplacering og ved opdatering af en enkelt tæller er, at WSRM beskeden GetUnemploymentBenefitsAccountVersion3 fremsendes til den indberettende A-kasse. Samtidig vil det kun være for enkelte kontaktgrupper og klientkategorier, at WSRM beskeden genereres til borgerens jobcenter. Herunder er reglerne for, hvornår dette er tilfældet:

1. KG 1 for personer, der er tilmeldt
2. KG 8 (Uden ydelse) for:
   1. Dimittender (tilmeldekategori 5), eller
   2. Uden ydelse (tilmeldekategori 3)
3. KG 25 (sygedagpengemodtagere fra ledighed) for personer der umiddelbart før overgang til KG 25 var i KG 1 og tilmeldte.
4. KG 24 (sygedagpengemodtagere fra beskæftigelse) (nyt fra 2017-2 ift. den tidligere besked GetUnemploymentBenefitsRightsVersion1)

WSRM beskeden udsendes ikke, når borgeren ikke er medlem af en A-kasse, og det er seneste foregående A-kasse, der indrapporterer opdaterede tællere.

Ud fra WSRM beskeden er det muligt at få status. Samtidig er det muligt at se, hvilke tællere, der er ændret i seneste inddatering ved at se på CalculationDate for de enkelte tællere.

Udsendelsesregler ift. a-kasser

Se forretningssiden for WsrmMessageService.

Tæller-indberetning i driftsituationen fra august 2017 og frem (jf. epic 727.18)

I tabellen nedenfor fremgår, hvornår de enkelte tællere forventes indberettet i driftsituationen, dvs, fra august 2017 og frem.

Anm.:

- Alle tællere: Der kan på baggrund af konkret sagsbehandling ske ændringer af alle tællere og tællere, der påvirkes af denne sagsbehandling indberettes, når de nye værdier er opgjort.

Noter:

*: Uge 26/2017 problematik (Danske A-kasser bidrager med beskrivelser)

**: Hvis en afgørelse ændres/annulleres efter en regulering kan DFDG få (hvis a-kasserne indberetter det) en ny afgørelsesdato vedr. et givet karensperiodenr., men vi vil i DFDG ikke kunne se, at den oprindelige afgørelse er ændret.

***: Indberetning har ikke retsvirkning ift. selvhentere – skal sagsbehandles i a-kassen først.

Spørgsmål /svar om brugen af servicen

Tællermatrice

2023_03_10_Tæller matrice.xlsx

Metoder

Rettigheder til at kalde metoderne

Jobcentre, kommuner og anden aktør

A-kasser

CreateBenefitsAccount 

En borgers dagpengetæller oprettes ved at kalde CreateBenefitsAccount med angivelse af alle de påkrævede dagpengetællere samt de optionelle dagpengetællere, som A-kassen ønsker registreret. CreateBenefitsAccount kaldes altid med det fulde billede af en borgers dagpengetællere, som de ønskes registreret i DFDG.

Kald til CreateBenefitsAccount medfører at der sendes WSRM beskeden GetUnemploymentBenefitsAccount fra WsrmMessageService 

Det er kun borgerens aktuelle A-kasse, som kan oprette en indplacering og opdatere tællere i DFDG. Dog kan de tidligere A-kasser, som borgeren har været medlem af de seneste 3 år kalde CreateBenefitsAccount, hvilket resulterer i, at WSRM beskeden GetBenefitsAccountFromFormerUnemploymentFund indeholdende indberetningen sendes til borgerens aktuelle A-kasse. DFDG gemmer ikke indberetningen og det vil være op til borgerens aktuelle A-kasse at behandle oplysninger, som modtages fra den tidligere A-kasse.

Hvis borger ikke er overgået til en ny a-kasse kan seneste foregående a-kasse inddatere i DFDG. Hvis en tidligere a-kasse end seneste foregående har behov for at inddatere data er det som udgangspunkt nuværende a-kasse der får WSRM og koordinerer. Igen: hvis der ikke er en nuværende a-kasse, må seneste a-kasse som borger har været medlem i overtage opgaven, illustereret i følgende grafik: 

Begrænsninger i brug af sats-typer, RateBasisType

Id 6, 7 og 9 i RateBasisTypeIdentifier må kun anvendes, hvis indplaceringsdato i ordinær dagpengeperiode er før 1. maj 2023. Fejlkode: 9458 - "RateBasis id 6,7 & 9 is only valid if GradingDate for ordinær dagpengeperiode < 2023-05-01"

Begrænsninger i brug af indplaceringsgrundlag, BenefitsGradingBasisType

Id 2, 7, 11, 14, 16-21 og 23 i BenefitsGradingBasisTypeIdentifier må kun anvendes, hvis indplaceringsdato i ordinær dagpengeperiode er før 1. maj 2023. Fejlkode 9459 - "The BenefitsGradingBasis Id is only valid if GradingDate for ordinær dagpengeperiode < 2023-05-01"

Opmærksomhedspunkter ved indberetning fra tidligere a-kasse

Såvel de 6 obligatoriske tællere, som tidligere indberettede tællere skal udfyldes i et create-kald med opdatering fra tidligere a-kasse. Hvis der er tale om en nyindplacering (hvilket vil være sjældent ved rettelser fra tidligere a-kasse) kan tidligere indberettede tællere undlades, idet NewGrading sættes til TRUE.

CorrectionComment og CorrectionStartDate må ikke udfyldes, når tidligere a-kasse indberetter (fejlkode 4575 - You are not authorized to execute the operation).

Mulighed for nulstilling af tællere

Mulighed for at nulstille ikke-påkrævede tællere i forbindelse med nyinplacering

A-kassen kan kun levere null eller tomt input på tællere, som tidligere har været udfyldt, hvis der er tale om en nyindplacering (og feltet NewGrading er sat til TRUE). Dette er dog kun muligt for tællere som ikke er påkrævede for at have dagpengetællere, se oversigt nedenfor.

Mulighed for at korrigere eller nulstille 1 eller sågar alle tællere med CorrectionComment

Nuværende a-kasse kan sætte CorrectionComment og CorrectionStartDateTime og dermed indikere at der er tale om fuld korrektur af tidligere input. 

Hvis 1 af de 6 påkrævede tællere overskrives med blank, fjernes det samlede tællersæt og borgeren har ikke dagpengetællere før der er indberettet en indplacering!

Det er kun meningen at nulstilling med CorrectionComment skal bruges i kritiske og akutte situationer hvor tællerne er groft misvisende og a-kassen på grund af datatab og systemfejl ikke har mulighed for at opdatere til et korrekt tællersæt.

Det er kun aktuel a-kasse, der kan anvende CorrectionComment i disse kritiske situationer. Hvis tidligere a-kasse udfylder CorrectionComment og CorrectionStartDateTime kastes fejl 4575 - You are not authorized to execute the operation.

Hvis a-kassen sender tomt datasæt på en tæller som tidligere har været udfyldt, skal det enten være i en nyindplaceringssituation (som beskrevet ovenfor) eller a-kassen skal angive at det er korrektur (med CorrectionComment og CorrectionStartDateTime).

I modsat fald vil DFDG - for at undgå utilsigtet blankning af tællere - melde tilbage med fejlkoden 9318 - " CorrectionComment and CorrectionStartDateTime must always both be set when correcting previous input".

Af hensyn til, som kritisk akut korrigerende handling, at kunne blanke alle tællere, er alle tællere optionelle i WSDL.

Påkrævede tællere med grønt og stjerne

Udover tællerne med grønt og stjerne er alle tællere som tidligere har været udfyldt påkrævede, medmindre der er tale om nyindplacering (som angives med Newgrading)

BenefitsGrading

Normalt vil OffsetHours i BenefitsGrading være max 3848 timer.

Personer indplaceret før før uge 26 2010 kan via reglerne om forlængelse af dagpengeperiodens referenceperiode (særligt forlængelsesgrunden ”pasning af alvorligt sygt eller handicappet barn i eget hjem”) dog have mere end 3.848 timer i OffsetHours. I cornercases kan et medlem have har en resterende dagpengeperiode på op til 3 år, 11 måneder og 3 uger. Derfor sættes [ændres jf. Manuscript 127617] max occurs til 2 x 3848 timer = 7696 timer. I princippet vil kan situationen i  worst case gælde frem til og med udgangen af uge 25 i 2030.

GradingDate

GradingDate indikerer indplaceringsdatoen, og har direkte sammenknytning med BenefitsPeriodForm som indikerer om GradingDate er inplaceringsdato for ordinær dagpengeperiode eller forlænget dagpengeperiode.

SupplementalBenefitsAccount - feltet StartWeekOrdinarySupplementalBenefits

Der kunne før 2019-1 ikke indberettes startuge for retten til supplerende dagpenge, hvis denne ligger før uge 01/2000 (200001). Startugen kan efter de materielle regler imidlertid ligge så tidligt som uge 01/1989. Hvis startugen ligger før år 2000 indberettes før release 2019-1 i stedet uge 01/2000 (200001).

Efter release 2019-1 kan der indberettes startuge tilbage til uge 01/1989 (198901).

GetUnemploymentBenefitsAccountInfo

Denne metode giver mulighed for at hente de tællere for dagpengeforbrug, indplaceringsdato, referenceperiode m.v. som a-kasserne opgør og indrapporterer for alle a-kassemedlemmer, der forbruger af deres dagpengeret, dvs. a-kassemedlemmer der 

• modtager ydelsen a-dagpenge
• er ansat med løntilskud
• modtager feriedagpenge
• forbruger af retten a-dagpenge under modtagelsen af sygedagpenge.

(Den er flyttet til UnemploymentBenefitsAccountService fra PersonStatusService hvor den tidligere har ligget som en collection i forbindelse med 2018-2 releasen)

Metoden kan kaldes af a-kasser, STAR, jobcentre, kommuner, anden aktør og Udbetaling Danmark.

Beskæftigelseskontoen er gjort til et ikke-påkrævet felt, men DFDG laver indtil 2018-3 fortsat default beskæftigelseskonto af hensyn til at kunne overholde kontrakten i PersonStatusService.

Hvis DisplayCounters ikke er sat modsvarer det TRUE, altså at tællerne gerne må vises. Hele formålet med DisplayCounters er at a-kassen kan trække i en nødbremse. Det er derfor kun når dette sker, og DisplayCounters er sat til FALSE at der skal ske en afblænding / ikke-visning.

UpdateBenefitsRate

Denne metode opdaterer en dagpengesats (BenefitsRate) uden at tage stilling til øvrige tællere.

UpdateConsumption

Denne metode opdaterer en indberetning om forbrug af dagpengeretstimer (Consumption).

UpdateGraduateHighRateConsumption

Denne metode opdaterer en indberetning om forbrug af dagepengetimeforbrug og resttimer med høj dagpengesats for dimittender.

Ny metode fra version 3 af servicen.

UpdateEmploymentBonusConsumption

Denne metode opdaterer en indberetning om forbrug af dagepengetimeforbrug og resttimer med høj sats dagpengesats for personer med beskæftigelsestillæg.

Ny metode fra version 3 af servicen.

UpdateBenefitsExpiry

Metode som gør at man kan opdatere information om faktisk eller forventet udløb af dagpengeretten (BenefitsExpiryType), samt ændre fra at det er forventet til at det er faktisk udløb af dagpenge der er tale om.

UpdateEmploymentAccount

Metode som gør at man kan opdatere genindplaceringskontoen (EmploymentAccount)

UpdateReferentialPeriod

Denne metode opdaterer en referenceperiode (ReferentialPeriod). Denne opdateres i forbindelse med hentning af indkomstkald eller anden dokumentation for indkomst ved hver udbetaling. 

UpdateRegradingAccount

Metode som gør at man kan opdatere genindplaceringskontoen. Opdatering sker i forbindelse med hentning af indkomstkald f. eks. efter hver udbetaling ved behandling af lønsedler, tro- og loveerklæringer m.v. og på forespørgsel. 

UpdateShorteningReport

Metode som gør, at man kan indberette kontroldata om afkortning af dagpengeperiode (kontroldata vedrørende den store karens).

UpdateSupplementalBenefitsAccount

Denne metode opdaterer en borgers supplerende dagpengekonto. Forbrug af supplerende dagpenge opdateres ved alle udbetalinger/reguleringer.

Genoptjeningsgrundlag (ReobtainBasis) indberettes som danner grundlag for såvel forlængelse som genoptjening af en fuld periode med ret til supplerende dagpenge når a-kassen har konstateret at der er forbrugt mindst 22 uger (indenfor en periode på 104 uger). 

Grundlaget indlægges med henblik på at give borger overblik over, og valgmulighed imellem, forlængelse eller genoptjening. Derfor skal der kun indlægges for indeværende periode, og først når der er grund til at begynde at tænke på forlængelse.

Når fuld genoptjent ret til supplerende dagpenge opnås skal dette grundlag ikke indberettes. Der skal heller ikke indberettes om dette når der forlænges på grundlag af selvstændig virksomhed (fordi dette grundlag ikke kan være bidragende til en genoptjening af fuld supplerende dagpengeretsperiode), 

Feltet StartWeekOrdinarySupplementalBenefits

Der kan ikke indberettes startuge for retten til supplerende dagpenge, hvis denne ligger før uge 01/2000 (200001).

Startugen kan efter de materielle regler imidlertid ligge så tidligt som uge 01/1989. Hvis startugen ligger før år 2000 indberettes i stedet uge 01/2000 (200001).

Indikation af forbrugte uger/måneder

A-kassen indberetter det optjeningsgrundlag som på indberetningstidspunktet er gyldigt. Det vil for supplerende dagpengetæller normalt være for de sidste 12 måneder, dog kan der være medtaget optjeningsgrundlag som er ældre, da optjeningsgrundlag som ved en opgørelse i a-kassen er godkendt, ikke kan fratages borger igen.

Når a-kassen forbruger uger eller måneder på en aktiveret forlængelse, fremgår dette ved at det forbrugte ikke længere indberettes som optjeningsgrundlag.

Eksempel: Borger har tilstrækkeligt med timer i uge 11,13,15,16 og 17 og disse er indberettede i ReobtainBasis collectionen 1/6 (med ReobtainBasisTypeIdentifier=1 og formodentlig i 3 eller 4 collections/objekter).

Ved indberetning 1/7 er der truffet afgørelse om at bruge 4 uger på en 4 ugers forlængelse. Der angives så ReobtainSupplementalBenefits = 2 (forlænget suppl. dp ret) og ReobtainedRightWeeks = 4, og nu kun 1 collection med ReobtainBasis på uge 17.

UpdateQualifyingHours

Metode som gør, at man kan indberette opdateringer om karensdage.

UpdateQualifyingHoursReport

Metode som gør, at man kan indberette opdateringer af afholdt karens (kontroldata vedrørende den lille karens).

SetCounterDisplay 

Ny metode i v2 af servicen. Metoden anvendes af medlemmets aktuelle a-kasse til at blokere for tæller-visning på Jobnet, hvis der er indberettet fejlbehæftede tæller-værdier og a-kassen ikke umiddelbart kan indberette korrekte, aktuelle tæller-værdier.

Målet med dette er, at a-kassen som nødløsning kan blænde af for tællervisningen i en kortvarig periode for det enkelte medlem.

Det forventes at den a-kasse, som blokerer for tællervisning ved at sætte DisplayCounters = FALSE, selv sørger for at genoprette tællervisningen, når der er indberettet korrekte tællerværdier. Genopretning af tællervisning sker ved at sætte DisplayCounters = TRUE.

Default i DFDG er indstillingen for det enkelte medlem, at tællervisning slået til, indtil en a-kasse måtte indberette DisplayCounters = FALSE.

En a-kasse som modtager henvendelse fra et medlem, hvis tællervisning er blokeret, om at han vil skifte a-kasse, bør nøje overveje om borgerens dagpengetællere er i en tilstand, så det er overkommeligt at overtage borgeren som medlem fra den foregående a-kasse.

Hvis det nye a-kasse overtager et medlem, hvor den tidligere a-kasse har sat DisplayCounters = FALSE, skal det nye a-kasse være opmærksom på, at indberette DisplayCounters = TRUE, når tællerværdierne igen kan vises for det nye medlem.

Det indgår i output for metoden GetUnemploymentBenefitsAccountInfo, om tæller-værdierne er markeret som fejlbehæftede (elementet DisplayCounters vil i sådanne tilfælde være false). Dermed kan a-kasser og KSS se, om a-kassen har markeret tællerværdier som fejlbehæftede, men ikke hvilke tællere, der indeholder fejlbehæftede værdier. Og dermed kan en ny a-kasse ifm. medlemsoverflytning også se, om den tidligere a-kasse har indrapporteret, at tæller-værdi(er) er fejlbehæftede.

DisplayCounters feltet indgår i WSRM-besked GetUnemploymentBenefitsAccountVersion3, men der sendes ikke WSRM når SetCounterDisplay kaldes.

Hvis et medlems tidligere a-kasse opdaterer tællere efter medlemmets overgang til en ny a-kasse, indgår det også i WSRM-beskeden GetBenefitsAccountFromFormerUnemploymentFundVersion3, som den nye a-kasse modtager, hvis DisplayCounters aktuelt er sat False.

Ud over at blokere for tæller-visning på Jobnet, fortæller ”flaget” dermed også både a-kasse og jobcentre m.fl., om man skal være varsom med at anvende tællerværdierne (indtil flaget ikke længere er false). Og hvis fx jobcentret fx skal bruge dagpengesatsen eller forventet tidspunkt for ophør af dp.ret kan de (manuelt) kontakte a-kassen for at høre, om disse er blandt de fejlbehæftede oplysninger.