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.
| Table of Contents |
|---|
Særligt om den "døde periode" pga. lov nr. 274 af 26. marts 2020, lov nr. 473 af 22. april 2020 og lov nr. 960 af 26. juni 2020
Indholdet i denne boks vedrører hvilke konsekvenser lov nr. 274 af 26. marts 2020 og lov nr. 473 af 22. april 2020 har for a-kassens indberetning af oplysninger om dagpengeforbrug m.v. til FLEUR og til dagpengetællerne. Med de to lovændringer vil perioden fra og med den 1. marts 2020 til og med den 30. juni 2020 ikke tælle med i den lediges dagpengeanciennitet.
Det er i den forbindelse afgørende, at indberetningerne er retvisende af hensyn til anvendelsen af oplysningerne til visning for medlemmerne, den administrative anvendelse af oplysningerne, tilsyn, digital medlemsoverflytning og den statistiske opfølgning.
Det vil sige, at der ikke må indberettes fiktive oplysninger om fx
- indplaceringer
- forbrug af dagpenge
- referenceperiode og udløb af dagpengeret
- karens
- m.v.
Alle indberetninger skal endvidere fortsat opfylde de tekniske valideringer, der er på de forskellige webservicesnitflader.
Indberetningerne forudsættes som udgangspunkt at være retvisende og tilpasset lov nr. 274 af 26. marts 2020, lov nr. 473 af 22. april 2020 og lov nr. 960 af 26. juni 2020 senest ved udgangen af august 2020.
Om de enkelte indberetninger af dagpengeudbetalinger m.v. til dagpengetællerne skal herudover bemærkes følgende:
Dagpengetællere – timer med forbrug af dagpenge
Dagpenge forbrug indberettes til dagpengetællerne (via UnemploymentBenefitsAccountService.CreateBenefitsAccount eller UnemploymentBenefitsAccountService.UpdateConsumption) med antal forbrugte dagpengetimer og antal resterende dagpengetimer.
Ved indberetningen af dagpengetællere skal dagpengetimer for månederne marts, april, maj, juni, juli og august 2020 ikke indgå i forbrugte dagpengetimer (HoursConsumed) eller i a-kassens beregning af antal resterende dagpengetimer (HoursRemaining).
Det vil sige, at forbrugstælleren skal opgøres, så udbetalte timer for marts, april, maj, juni, juli og august 2020 kun indgår med 0.
Som forbrug kan i henhold til de almindelige valideringer alene indberettes et tal mellem 0 og 3848, dvs. at der ikke kan indberettes negative tal.
Dagpengetællere – referenceperiode og forventet / faktisk udløb af retten til dagpenge
Ved indberetningen af
- referenceperioden (via UnemploymentBenefitsAccountService.CreateBene-fitsAccount eller UnemploymentBenefitsAccountService.UpdateReferentialPeriod) og
- forventet og faktisk udløb af retten til dagpenge (via UnemploymentBenefitsAc-countService.CreateBenefitsAccount eller UnemploymentBenefitsAccountService.UpdateBenefitsExpiry)
skal a-kassen tage højde for, at dagpenge for månederne marts, april, maj, juni, juli og august 2020 ikke indgår i forbrug af retten til dagpenge.
Hvis referenceperioden udløber 1. marts 2020 eller senere, forlænges referenceperioden i referenceperiodetælleren med de 6 måneder. Dvs. at der skal indberettes en ny referenceperiode slutdato for alle indplacerede medlemmer.
Faktisk og forventet udløb forventes derefter automatisk at være rigtige, hvis for-bruget og deraf udledte resttimer og referenceperioden er opgjort rigtigt, da det er de parametre, der indgår i beregningen af faktisk og forventet udløb.
For medlemmer, hvor der allerede er registreret faktisk udløb 1. marts 2020 eller senere forventes, at a-kassen opdaterer tælleren, når forbruget i marts 2020 er nulstillet og beregningen af forventet udløb derfor giver en ændret dato.
EksempelEt medlem havde efter februar 2020 udbetalingen 70 timer i resttimer og stod der-for med et forventet udløb den 13. marts 2020. Hvis systemet ved marts-udbetalingen udbetaler de resterende 70 timer og a-kassen vælger at udbetale de manglende marts-timer manuelt uden om systemet, så vil systemet efter hidtidige regler registrere faktisk udløb den 13. marts 2020. Når systemet er opdateret til ikke at medregne marts-forbruget, forventes det at tælleren ændres til igen at vise forventet udløb.
Dagpengetællere – karens
Karens indberettes til dagpengetællerne (via UnemploymentBenefitsAccountService.CreateBenefitsAccount eller UnemploymentBenefitsAccountService.Up-dateQualifyingHours). Der indberettes bl.a.
- karensperiodenummer
- antal løntimer i perioden
- antal timer, der mangler i indeværende karensperioden, for at undgå karens
- start- og slutdato på indeværende karensperiode
Ved indberetningen af løntimer (EmploymentHours) indgår også timer indberettet til indkomstregisteret i perioden fra og med den 1. marts 2020 til og med den 31. august 2020. Disse timer indgår derfor også i a-kassens beregning af manglende timer (QualifyingHoursMissing), der indberettes.
Start- og slutdato på perioden tilpasses ved indberetningen således, at marts, april, maj, juni, juli og august er døde perioder, der ikke kan udløse en karens. Det vil sige, at 4-månedersperioden i karensreglen er suspenderet i perioden fra og med 1. marts 2020 til og med 31. august 2020. Det betyder, at der i perioden ikke er nogen, der kan få en karens. Forbruget af 4-månedersperioden ”lever” op igen efter perioden udløb. Løntimer indberettet i perioden medregnes til opgørelsen af de 148 / 97 løntimer for fuldtids- hhv. deltidsforsikrede.
Den ændring, der skal ske, er derfor, at slutdatoen for indeværende karensperiode skal tillægges 6 måneder.
Eksempel
Hvis indeværende karensperiode har slutmåned i maj, forlænges karensperioden med 6 måneder, så karensslutmåneden bliver november – den forlængede slutmåned indberettes.
Dagpengetællere – antal uger med forbrug af supplerende dagpenge
Antal uger med forbrug af retten til supplerende dagpenge indberettes til dagpenge-tællerne (via UnemploymentBenefitsAccountService.CreateBenefitsAccount eller UnemploymentBenefitsAccountService.UpdateSupplementalBenefitsAccount) an-tal uger, hvor der er forbrugt supplerende dagpenge.
Uger i marts, april, maj, juni, juli og august med arbejdstimer er ikke supplerende uger og skal derfor ikke i a-kassesystemet markeres som supplerende uger.
Hvis der er arbejdstimer og udbetalt dagpenge for samme uge for én eller flere af ugerne 9 til 35 2020, skal ugerne derfor ikke medtælles ved indberetning til dagpengetællerne (WeeksConsumed) af forbrug af retten til supplerende dagpenge.
WeeksConsumed er en optælling af uger, der forbruger indenfor 104 uger. Da ingen uger kan forbruge af retten til supplerende dagpenge i perioden uge 9 til 35, kan det indberettede forbrug kun være enten uændret eller faldende (på grund af forældelse af de tidligst forbrugte uger).
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.
Sikkerhedsattributter
Servicen er omlagt til de nye sikkerhedsattributter i 2021-1 - og vil derfor fremgår kaste fejlkode 4575 "You are not authorized", hvis servicen kaldes af en aftagertype, der ikke har rettighed til at kalde den pågældende servicemetode. Der kan evt. tidligere være kastet en mere aftagertype-specifik fejlkode i denne situation.
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.
Er det få af borgerens dagpengetællere (2 – 3 stk.), som skal opdateres, kan man kalde de enkelte Update metoder. Dette vil dog, som beskrevet ovenfor medføre flere WSRM beskeder indeholdende alle borgerens i DFDG registrerede dagpengetællere.
Er det flere af borgerens dagpengetællere (mere end 3 stk.), som skal opdateres, så vil det være korrekt, at kalde CreateBenefitsAccount med det fulde billede af borgerens ”nye” dagpengetællere. Det værende sig det fulde billede af borgerens nuværende dagpengetællere inklusiv de opdateringer, som ønskes registreret i DFDG. Kender man ikke borgerens nuværende fulde billede af dagpengetællere, kan man hente det fra DFDG og herefter kalde CreateBenefitsAccount med billedet inklusiv de ønskede opdateringer. Dette medfører kun 1 WSRM besked indeholdende alle borgerens i DFDG registrerede dagpengetællere.
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:
- KG 1 for personer, der er tilmeldt
- KG 8 (Uden ydelse) for:
- Dimittender (tilmeldekategori 5), eller
- Uden ydelse (tilmeldekategori 3)
- KG 25 (sygedagpengemodtagere fra ledighed) for personer der umiddelbart før overgang til KG 25 var i KG 1 og tilmeldte.
- 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.
Tæller
Driftssituationen
august 2017 og frem
Ved dagpengekørsel
(ca. 2-3 dage før sidste bankdag i måned x)
Kontrol
(ca. den 12. i måned x+1)
Regulering
(når som helst)
Ved modtagelse og behandling af WSRM fra DFDG
Genindplacering
(når som helst)
Helt ny-indplacerede
(når som helst)
Indplaceringsdato
Rettelser (ved ændringer pga. nye oplysninger)
(udgangspunkt er at dato er indberettet ved konvertering eller ved ny- eller genindplacering)
-
-
-
Ja
Helt nyledige indberettes løbende
Referenceperiode
Hvis ændret pga. nye oplysninger
(udgangspunkt er at dato er indberettet ved konvertering eller ved ny- eller genindplacering)
Ved sygedagpenge, barsel samt §§ 42 og 120 i serviceloven, der kan forlænge referenceperiode
-
-
Ja
Ja
Dagpengesats
Hvis ændret pga. nye oplysninger (fx forsørger status eller i aktivering/alder)
(udgangspunkt er at satsen erForretningsregler
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:
- KG 1 for personer, der er tilmeldt
- KG 8 (Uden ydelse) for:
- Dimittender (tilmeldekategori 5), eller
- Uden ydelse (tilmeldekategori 3)
- KG 25 (sygedagpengemodtagere fra ledighed) for personer der umiddelbart før overgang til KG 25 var i KG 1 og tilmeldte.
- 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.
Tæller | Driftssituationen august 2017 og frem | ||||||
Ved dagpengekørsel (ca. 2-3 dage før sidste bankdag i måned x) | Kontrol (ca. den 12. i måned x+1) | Regulering (når som helst) | Ved modtagelse og behandling af WSRM fra DFDG | Genindplacering (når som helst) | Helt ny-indplacerede (når som helst) | Øvrige opgørelser og indberetninger | |
Indplaceringsdato | Rettelser (ved ændringer pga. nye oplysninger) (udgangspunkt er at dato er indberettet ved konvertering eller ved ny- eller genindplacering) | - | - | - | Ja | Helt nyledige indberettes løbende | |
Referenceperiode | Hvis ændret pga. nye oplysninger (udgangspunkt er at dato er indberettet ved konvertering eller ved ny- eller genindplacering) | Ved sygedagpenge, barsel samt §§ 42 og 120 i serviceloven, der kan forlænge referenceperiode | - | - | Ja | Ja | |
Dagpengesats | Hvis ændret pga. nye oplysninger (fx forsørger status eller i aktivering/alder) (udgangspunkt er at satsen er indberettet ved konvertering eller ved ny- eller genindplacering) | Efter kontrollen: Dimittender og værnepligtige (genberegning) – formentlig efter konkret vejledning af medlemmet | - | Ved ændring ift. forsørger, aktivering/alder under 25 år og deltagelse i uddannelsesløft | Ja | Ja | Ved satsregulering ved årsskifte (indberettes med samme årsag som forudgående korrekte satsindberetning) (indberetning kan ske sammen med øvrige tællere ultimo måneden, hvor tællere i øvrigt indberettes) |
Forbrug af ret til dagpenge | Ja | - | Ja | - | - | ||
Forventet udløb af ret til dagpenge | Ja | Ja (hvis referenceperiode ændret af betydning ved kontrollen) | Ja | - | Ja (sammen med genindplacering) | Ja | Ved gentilmelding som jobsøgende efter ikke at have modtaget dagpenge i en periode |
Faktisk udløb af ret til dagpenge | Ja, hvis endeligt udløbet | Ja, hvis endeligt udløbet | Ja, hvis endeligt udløbet | - | - | - | |
Beskæftigelseskonto*** | - | Ja (timer indberettet i foregående måned) | - | - | Ja | Ja | |
Timer til genoptjening af retten til dagpenge (herefter genindplaceringskonto) | - | Ja | - | - | Kan forekomme | Kan forekomme | |
Forbrug af supplerende dagpenge | Ja | - | Ja Når tæller opdateres – ikke nødvendigvis først ved beløbsregulering | - | - | Kan forekomme | |
Karenstæller | Ja | Nej, evt. ændringer sker ifm. regulering | Ja | - | Ja (starter forfra, tæller nulstilles) | Ja (starter forfra, tæller nulstilles) | |
Afholdt karens Indberettes tidligst i ultimo oktober 2017 | Ja, når der trækkes beløb ved udbetaling | - | Ja, hvis der annulleres en pålagt karens ** | - | Kan forekomme (evt. skyldig karens indberettes først som afholdt karens, når beløbet trækkes) | Forekommer sjældent (evt. skyldig karens indberettes først som afholdt karens, når beløbet trækkes) | |
Afkortning af dagpengeperiode | Ja (hvis truffet afgørelse) | Ja fx ved forbrug af sygedagpenge eller ansættelse i løntilskudsjob (hvis truffet afgørelse) | Ja (hvis truffet afgørelse) | - | Ja (hvis truffet afgørelse fordi der er timer at afkorte i) | Ja (hvis truffet afgørelse, hvis der skyldes en afkortning) | |
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
| Emne / felt | Spørgsmål | Svar | Foranlediget af | Dato |
|---|---|---|---|---|
RegisterinformationTime (svar 1/RT) | Vi har et spørgsmål angående feltet RegisterinformationTime fra UnemploymentBenefitsAccountService v. 1 service. Beskrivelsen af feltet er:
| Det bekræftes | FB 99118 | 10.04.2017 |
RegisterinformationTime (svar 2/RT) | Såfremt den seneste dato, da information blev opdateret fra enten eIndkomst eller DFDG, var fra DFDG. Vil det så stadig være korrekt at bruge denne dato til RegisterinformationTime feltet i tællerne, som er beregnet på baggrund af data fra eIndkomst registeret, f.eks. en sats? Eller er der en slags mapping mellem hver tæller og systemet (eIndkomst eller DFDG), hvorfra den seneste informations opdateringsdato bør tages fra? | Det første – det vil stadig være korrekt at bruge dato fra seneste opslag til DFDG eller eIndkomst registeret, som er anvendt ved opgørelsen af den pågældende tæller. | FB 99118 | 28.04.2017 |
RegisterinformationTime (svar 3/RT) | Hvad menes nøjagtigt med Tidspunkt for indhentelse af registeroplysninger? Refererer det til en dato, hvor data faktisk blev hentet og gemt i vores system? Hvad med de tilfælde, hvor vi rekvirerer data f.eks. fra eIndkomst, men hvor der ikke er data, og der returneres et ”tomt” svar uden indkomstdata – skal det behandles, som at der er en ny dato? Eller skal den tidligere dato, hvor vi har hentet data med indhold, være den der gælder? | Det refererer til en dato, hvor data faktisk blev hentet og gemt i jeres system. I tilfælde, hvor I rekvirerer data f.eks. fra eIndkomst, men hvor der ikke er data, og der returneres et ”tomt” svar uden indkomstdata – skal dette behandles som en ny dato (fordi i har haft succes med at hente et resultat om end det er tomt). | FB 99118 | 28.04.2017 |
RegisterinformationTime (svar 4/RT) | Hvad gør vi, når vores forespørgsel efter data returnerer en fejl? Tæller datoen så, eller skal vi se bort fra den? | Se bort fra denne. | FB 99118 | 28.04.2017 |
| Hvad skal hentes i DFDG - og med hvilke services | Når det kun gælder eIndkomst, synes sagen at være mere klar – vi henter lønindkomst oplysninger, og for RegisterinformationTime bruger vi seneste dato, hvor vi har hentet eller opdateret lønoplysninger for det enkelte. For DFDG skal vi så hente alle oplysninger på et medlem eller har I en liste over udvalgte services, som bør kaldes? |
| FB 99118 | 28.04.2017 |
| Korrektion af fejl-indberetninger | I epic 727.1 står under 4.1.6, at man ved opdagelse af fejl ruller tilbage ved at sende foregående korrekt datasæt til DFDG. Men hvad gør man, hvis der ikke er noget foregående datasæt? Fx vi har ved en fejl fået indberettet på forkert medlem, eller det indberettede medlem får aldrig en udbetaling og vil gerne have slette de tællerdata der vises? | Vi forventer ikke, at der opstår sådanne situationer, men hvis det skulle ske: A-kassen (eller deres leverandør) må oprette en FB-sag til Systemforvaltningen – og så må vi scripte os ud af det i DFDG-regi. | 01.05.2017 | |
RegisterinformationTime (svar 5/RT) (flere eksempler) | Vi har lidt flere situationer, vi gerne vil have en tydelig afklaring af, jeg har for nemheds skyld kun angivet dato: Eksempel 1: Så er RegisterinformationTime den 28-04-2017 Vi opdaterer en tæller f.eks. en sats på baggrund af et kald til eIndkomst fra den 29-04-2017 Så er RegisterinformationTime den 28-04-2017 eller den 29-04-2017? | Jeg læser eksemplet sådan, at der er spurgt bredt i DFDG efter fx både fravær, løntilskudsperioder m.v., men seneste opdatering indeholder alene nye data for a-kassen i form af en personlig jobformidler. Enig i, at RegisterinformationTime i denne situation er den 28-04-2017 (for nemheds skyld er her kun angivet dato), hvis tælleropgørelsen sker den inden kaldet til indkomstregisteret. Hvis opgørelsen af tæller sker efter kaldet til indkomstregisteret er RegisterinformationTime i denne situation er den 29-04-2017. | FB 99118 | 02.05.2017 |
Eksempel 2: Så er RegisterinformationTime den 28-04-2017 Der hentes info fra eIndkomst registeret den 29-04-2017, men der er ingen nye data. Så er RegisterinformationTime den 29-04-2017 | RegisterinformationTime er i denne situation den 28-04-2017 (for nemheds skyld er her kun angivet dato), hvis tælleropgørelsen sker den inden kaldet til indkomstregisteret. Hvis opgørelsen af tæller sker efter kaldet til indkomstregisteret er RegisterinformationTime i denne situation er den 29-04-2017. | FB 99118 | 02.05.2017 | |
Eksempel 3: Så er RegisterinformationTime den 28-04-2017 Der hentes info fra eIndkomst registeret den 29-04-2017, men der er ingen data. Så er RegisterinformationTime den 29-04-2017 | Enig i, at RegisterinformationTime i denne situation er den 28-04-2017 (for nemheds skyld er her kun angivet dato), hvis tælleropgørelsen sker den inden kaldet til indkomstregisteret. | FB 99118 | 02.05.2017 | |
Eksempel 4: Så er RegisterinformationTime den 28-04-2017 Der hentes info fra eIndkomst registeret den 29-04-2017, men kaldet fejler. Så er RegisterinformationTime den 28-04-2017 | Enig i, at RegisterinformationTime i denne situation er den 28-04-2017 | FB 99118 | 02.05.2017 | |
Eksempel 5: Så er RegisterinformationTime den 28-04-2017 Vi opdaterer en tæller f.eks. en sats på baggrund af et kald til eIndkomst fra den 27-04-2017 Så er RegisterinformationTime den 27-04-2017 eller den 28-04-2017? | RegisterinformationTime er i denne situation er den 28-04-2017. | FB 99118 | 02.05.2017 | |
| Karens | I Epic727.1 er beskrevet om indberetning af karens: Opdateres ved udløbet af hver karensperiode og når den pålagte karens trækkes. Det er ingen problem at indberette tællere når karensperioden udløber. Det er en udfordring at indberette afvikling af pålagt karens, hvis medlemmet afvikler 2 eller flere karens i samme udbetaling. Der kan f.eks. være optjent 1 karens umiddelbart før et medlem starter en ansættelse med løntilskud, og medlemmet kan optjene en eller flere karens i perioden hvor der er ansætelse med løntilskud. Ved første efterfølgende udbetaling trækkes medlemmet mere end en karens. Det er kun muligt at indberette en forekomst af afviklet karens - og der kan kun vises en forekomst til jobnet. Skal A-kassen kun indberette den seneste Karens = Højeste karensperiodenummer + tilhørende beløb? | I disse formentlig få situationer indberettes det højeste karensperiodenr., der trækkes karensbeløb for, og det samlede karensbeløb for de karensperioder, der trækkes karensbeløb for i karensperioden med det højeste nr. | FB 99882 | 03.05.2017 |
| Dagpengesatser | Er RatePerMonth og RatePerHour obligatoriske, og hvad gør vi hvis der fx udelukkende er udbetalt feriedagpenge? Det er forvirrende med "MinExclusive: 0" og "minExclusive value="0"", men "GreaterThanZereo" og "mindsteværdi: 0,01". | Satsfelterne RatePerMonth og RatePerHour er obligatoriske med et positivt beløb fordi der her forventes de satser som vil ligge til grundlag for udbetaling når der sker udbetaling. Hvis der ikke er dagpengeret, og derfor ikke kendes en sats, kan hele feltgruppen udelades. MinExclusive er en xml-teknisk term som betyder at der skal være en plus-værdi. | FB 99909 | 04.05.2017 |
1. Hvilken sats? Vi ønsker derfor oplyst om satsen skal indberettes som eller
| A-kassen skal indberette den aktuelle sats, herunder ved satsregulering pr. 1. januar. | Mail fra a-kasse 10.01.2018 | 10.01.2018 | |
| 2. Decimaler? 2. Der har tidligere været drøftelse om, at satsen altid skulle indberettes med 2 decimaler, men disse altid skulle udgøre ,00. Dette kan jeg ikke længere finde i epics er gældende og for moder naturligvis, at satsen skal indberettes med de præcise decimaler. | Sats skal indberettes med 2 decimaler i ws-snitfladen.
| Mail fra a-kasse 10.01.2018 | 10.01.2018 | |
| Forbrug af supplerende dagpenge | Ved udvikling af Fælles Tællere om supplerende dagpenge kan vi i kogebogen se at det er muligt at medlemmet får udbetalt mere end 30 uger supplerende dagpenge. Samtidig viser eksembel 3 i kogebogen at tællerdata er 30 uger. I Epic 727.1 kan det kun ses at der kun indberettes et antal uger - ikke om det max. kan være 30 uger. Er der et max. antal uger der kan indberettes? | DFDG validerer (kun) på at det er et helt antal forbrugte uger. | FB 100575 | 16.05.2017 |
| Forskel i udstilling i GetVariablePersonStatus og GetVariablePersonStatusCV operationen | Hvordan kan det være at tællerværdierne for de 2 strukturer af Genindplaceringskonto (RegradingAccount og RegradingAccountCv) er forskellige ? Når vi anvender GetVariablePersonStatus operationen har vi kun adgang til RegradingAccount typen. Den mangler værdierne: HoursNeededToRegradeTypeIdentifier, HoursNeededMaxProlongationTypeIdentifier og HoursToPreventQualifyingTypeIdentifier. Jeg kan se, at man med kodelister har forsøgt at angive timetallet for fuldtid eller deltid for de 3 værdier. Så det er naturligvis noget vi nemt selv kan finde frem til, men det var måske smartere hvis det 2 strukturer fulgtes ad, så vores kunder har nemmere ved at genskabe 'sparegrisen' på deres egen selvbetjeningssider, ud fra GetVariablePersonStatus operationen? | Det er fordi, det er særlig logik lavet i DFDG af hensyn til tæller-visningen på Jobnet. Det har ikke været rejst som ønske fra a-kasserne/leverandørerne (før nu), at DFDG også skulle udstille disse værdier til a-kasserne. Og derfor har vi ikke taget det med i GetVariablePersonStatus operationen. Vi kan - hvis det ønskes - tage det med som ønske til en senere PSS-version, når tæller-snitfladen skal opdateres. Opdatering: Fra PSS v20 (2017-4) indeholder GetVariablePersonStatus metoden de 3 nævnte kodelister. | FB 100696 | 18.05.2017 08.11.2017 |
| Forbrugstæller (Consumption) | I Tælleren vedrørende forbrug (ConsumptionType), skal der indberettes seneste opgørelse af forbrug, dvs. Forbrug opgjort med udbetaling for (ultimo måned), (InventoryPaymentMonth). Denne tælleroplysning er obligatorisk. Hvis a-kassen opretter en ny indplacering til medlemmet, vil der skulle indberettes et forbrug, men dette er ikke opgjort før efter førstkommende udbetaling. Der vil derfor ikke være en dato (opgjort med udbetaling for ultimo måned) at indberette. Hvilken dato skal indberettes i denne situation? | Hvis der er tale om en helt ny indplacering, så må forbruget være 0 - og så kan forbruget angives til at være opgjort til og med måneden før indplaceringsdatoen. | FB 100994 | 02.06.2017 |
| Supplerende dagpengetæller (SupplementalBenefitsAccount) | ReobtainedWeekValue og RebtainedMonthValue Det angives i kolonnen ”Detaljer”, at det er decimaltal med 2 decimaler. Er dette et levn fra før fremsendelse af udkast til bekendtgørelse om udbetaling af dagpenge? Heri fremgår, at der ved flere indberetningstyper omregnes til hele uger (§ 46, stk. 5). | For at indberetningen kan falde på plads skal der indberettes med 2 decimaler. Indberetning af heltal skal derfor rent teknisk ske som ”heltal,00” | FB 119937 | 24.4.2018 |
| Supplerende dagpengetæller | ObsoleteDate Det fremgår af beskrivelsen i epic, at ObsoleteDate er ReobtainDate + 12 måneder. Dette gælder ved genoptjening, men ikke forlængelse (som ikke har en egentlig referenceperiode jf. bekendtgørelsens § 44, stk. 2). | AMY taler om et 12 måneders krav for både forlængelse og generhvervelse, og har i I-teksterne til Jobnet vedrørende forlængelse skrevet at : ”Forlængelsen sker på baggrund af lønmodtagerbeskæftigelse , som i de seneste 12 måneder er indberetttet til indkomstregisteret samt ikke indberetningspligtig B-indkomst, hvoraf der skal betales arbejdsmarkedsbidrag omregnet til timer med en omregningsfaktor. ” 12 måneders forældelsen må følge af A-lovens § 60, stk. 2, nr. 1: ” Stk. 2. Et medlem, hvis ret til supplerende dagpenge er udløbet, jf. stk. 1, har ret til at få forlænget den periode, hvor medlemmet arbejder på nedsat tid og samtidig får udbetalt supplerende dagpenge med op til 12 uger. Forlængelsen sker på baggrund af: 1) Løntimer og B-indkomst, jf. § 53, stk. 9, nr. 1 og 2, som i de seneste 12 måneder er indberettet til indkomstregisteret i henhold til lov om et indkomstregister og ikkeindberetningspligtig B-indkomst som oplyst af medlemmet på tro og love. B-indkomsten omregnes til timer. Ved opgørelsen af den forlængede ret til supplerende dagpenge giver en månedsindberetning, fire ugeindberetninger eller to 14-dagesindberetninger med det antal løntimer, der fremgår af stk. 6, ret til yderligere 4 uger, hvor medlemmet arbejder på nedsat tid og samtidig får udbetalt supplerende dagpenge.” (red. kursivering) I den borgervendte tekst for generhvervelse har AMY skrevet: ”Her kan du se dine godkendte indberetninger af timer med beskæftigelse indenfor 12 sammenhængende måneder, og hvordan de fordeler sig på de forskellige måneder. Læs mere om, hvornår indberetninger tæller med i informations-teksten til ’Generhvervelse’.” | FB 119937 | 24.4.2018 |
Tællermatrice
| View file | ||||
|---|---|---|---|---|
|
Link til snitfladebeskrivelsen
| Child pages (Children Display) | ||
|---|---|---|
|
Link til forretningsbeskrivelser
| Search Results | ||||
|---|---|---|---|---|
|
Metoder
Rettigheder til at kalde metoderne
Jobcentre, kommuner og anden aktør
Metode | Alle borgere | Egne borgere | Mulighed for gæsteadgang | Beskrivelse |
|---|---|---|---|---|
| CreateBenefitsAccount | Denne metode opretter en indplacering (BenefitGrading). | |||
| GetUnemploymentBenefitsAccountInfo | JC, AA(JC), K | Denne metode henter dagpengetællere. | ||
| UpdateReferentialPeriod | Denne metode opdaterer en referenceperiode (ReferentialPeriod). Denne opdateres i forbindelse med hentning af indkomstkald eller anden dokumentation for indkomst ved hver udbetaling. | |||
| 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). | |||
| 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) | |||
| 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. | |||
| UpdateSupplementalBenefitsAccount | Denne metode opdaterer en borgers supplerende dagpengekonto. Forbrug af supplerende dagpenge opdateres ved alle udbetalinger/reguleringer. | |||
| 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). | |||
| UpdateShorteningReport | Metode som gør, at man kan indberette kontroldata om afkortning af dagpengeperiode (kontroldata vedrørende den store karens). | |||
| SetCounterDisplay | Metode til at sætte et flag for visning af borgers A-Kasse tællere på Jobnet. |
A-kasser
Metode | Alle personer | Egne medlemmer | Tidligere medlemmer | Mulighed for gæsteadgang | Beskrivelse |
|---|---|---|---|---|---|
| CreateBenefitsAccount | X | X | Denne metode opretter en indplacering (BenefitGrading). | ||
| GetUnemploymentBenefitsAccountInfo | X | X | Denne metode henter dagpengetællere. | ||
| UpdateReferentialPeriod | X | X | Denne metode opdaterer en referenceperiode (ReferentialPeriod). Denne opdateres i forbindelse med hentning af indkomstkald eller anden dokumentation for indkomst ved hver udbetaling. | ||
| UpdateBenefitsRate | X | X | Denne metode opdaterer en dagpengesats (BenefitsRate) uden at tage stilling til øvrige tællere. | ||
| UpdateConsumption | X | X | Denne metode opdaterer en indberetning om forbrug af dagpengeretstimer (Consumption). | ||
| UpdateBenefitsExpiry | X | X | 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 | X | X | Metode som gør at man kan opdatere genindplaceringskontoen (EmploymentAccount) | ||
| UpdateRegradingAccount | X | X | 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. | ||
| UpdateSupplementalBenefitsAccount | X | X | Denne metode opdaterer en borgers supplerende dagpengekonto. Forbrug af supplerende dagpenge opdateres ved alle udbetalinger/reguleringer. | ||
| UpdateQualifyingHours | X | X | Metode som gør, at man kan indberette opdateringer om karensdage. | ||
| UpdateQualifyingHoursReport | X | X | Metode som gør, at man kan indberette opdateringer af afholdt karens (kontroldata vedrørende den lille karens). | ||
| UpdateShorteningReport | X | X | Metode som gør, at man kan indberette kontroldata om afkortning af dagpengeperiode (kontroldata vedrørende den store karens). | ||
| SetCounterDisplay | X | X | Metode til at sætte et flag for visning af borgers A-Kasse tællere på Jobnet. |
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:
| Drawio | ||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
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
Navn | Detaljer |
BenefitsGrading * | Indplacering af borger i dagpengeperiode |
ReferentialPeriod * | Referenceperiode |
BenefitsRate | Dagpengesats. |
Consumption * | Forbrug af dagpengeretstimer. |
BenefitsExpiry * | Forventet eller faktisk udløb af dagpengeret |
EmploymentAccount | Beskæftigelseskonto |
RegradingAccount * | Genindplaceringskonto |
SupplementalBenefitsAccount | Supplerende dagpengekonto |
QualifyingHours * | Karenstæller |
QualifyingHoursReport | Indberetning afholdt karens (kontroldata vedrørende den lille karens) |
ShorteningReport | Indberetning om afkortning af dagpengeperiode (kontroldata vedrørende den store karens) |
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.