Frågor och svar om inkomstregistret för programutvecklare

Laddningstjänsten

Hur används inkomstregistrets laddningstjänst?

Laddningstjänsten är en del av inkomstregistrets elektroniska ärendehanteringstjänst, och inloggningen sker med nätbankskoder, mobilcertifikat eller certifikatkort. Via tjänsten kan man lämna in material till inkomstregistret. Materialen ska vara i XML-format och motsvara inkomstregistrets schema. Det är inte möjligt att hämta material genom laddningstjänsten.

Var beskrivs laddningstjänstens egenskaper?

Materialet som lämnas in via laddningstjänsten har samma format som materialet som skickas till det tekniska gränssnittet och beskrivs i tjänstebeskrivningarna av det tekniska gränssnittet. Läs mera:  

Behandlingsresponsen från laddningstjänsten har samma format som responsen från det tekniska gränssnittet, och den beskrivs också i tjänstebeskrivningarna av det tekniska gränssnittet.

Ger laddningstjänsten felmeddelanden redan när material skickas?

När material skickas ger tjänsten användaren felmeddelanden relaterade till schemat.

Hur får man behandlingsrespons på material som skickats via laddningstjänsten?

Behandlingsrespons är tillgänglig via laddningstjänsten efter att inkomstregistret har kontrollerat hela materialet enligt behandlingsreglerna.

Avstämning, rapporter och koder

Ska avstämning göras utifrån ett svarsmeddelande, eller har informationsproducenterna åtkomst till inkomstregistret för att kontrollera det skickade materialet, utifrån vilket avstämningen kan göras?

Prestationsbetalaren kan få en avstämningsrapport om den information som anmälts till inkomstregistret. Om informationen i inkomstregistret skiljer sig från informationen i löneberäkningssystemet, ska eventuell felaktig information i inkomstregistret korrigeras med ett ersättande förfarande. 

Läs mera om rapporter: Prestationsbetalaren kan beställa rapporter om uppgifter som anmälts till inkomstregistret

Hur får parterna information om förändringar i inkomstregistrets koder?

Inkomstregistrets interna koder i det tekniska gränssnittets meddelanden och deras värden beskrivs i dokumenten ”Koder” och ”Löner – Koder – Inkomstslag” samt "Förmåner – Koder – Inkomstslag". Parterna informeras om förändringar i koderna och dokumenten.

Koder utanför inkomstregistret är till exempel Kevas koder, arbetspensionsförsäkringsbranschens försäkringsnummer och Statistikcentralens yrkesklassificering. Förändringar i dessa anmäler kodernas ägare till inkomstregistret och parterna precis som i dag. Även inkomstregistermyndigheten informerar parterna om förändringar.

Användningen av certifikat i gränssnittsanrop

Vilken del av materialet som ska skickas undertecknas i olika kanaler?

Oberoende av servicekanalen avser underteckningen alltid material som skickas till inkomstregistret, inte överföringsramen som gäller servicekanalen. När Web Service- kanalen används skapas underteckningen utifrån grundelementet (Root Element) i enlighet med inkomstregistrets schema inom elementet Envelope/Body. I enlighet med dokumentationen placeras det undertecknade grundelementet inom elementet SOAP Body innan den skickas till inkomstregistret. Det undertecknade materialet får inte ändras under denna fas.

Underteckningens faser i Web Service-kanalen sammanfattningsvis:

  1. Skapa ett XML-material och SOAP Envelope för inkomstregistret.
  2. Hämta grundelementet inom SOAP Envelopen Bodyn och skapa ett nytt XML-dokument av det.
  3. Underteckna det nya XML-dokumentet enligt dokumentationen.
  4. Radera grundelementet inom Bodyn och lägg ersätt den med grundelementet som undertecknades för en stund sedan.
  5. Skicka SOAP Envelope. 

WS-gränssnitt

Varför kommer det ett SSLHandshakeException-undantag (inkomstregistrets och certifikattjänstens gränssnitt) när man använder Web Service-tjänsterna?

Problemet hänger sannolikt ihop med den TLS/SSL-version som kundprogrammet använder och därmed anknutna kryptobibliotek. Inkomstregistrets och certifikattjänstens Web Service-gränssnitt använder ett protokoll enligt TLSv1.2 och kundprogrammet ska använda samma version. Kända problem: 

Java 7 och tidigare versioner → Uppdatera till Java 8 eller senare.

SoapUI OpenSource, version 5.3.0 och tidigare använder en föråldrad version av Java. → Uppdatera SoapUI till version 5.4.0 eller uppdatera/ersätt SoapUI-paketerade Java till version 8.

SFTP-gränssnitt

Hur är XML-filerna som inkomstregistret hämtat namngivna i OUT-mappen?

Filerna i OUT-mappen namnges enligt formatet:

<QueryDataType>_<MainSubscriptionId>_<SubscriptionId>_<hämtningens ordningsnummer>_<IRQueryId>_<delfilernas totala antal>_<dilfilernas löpande nummer>.xml

Detta beskrivs närmare i följande dokument: Tekniskt gränssnitt – Tillämpningsanvisning 2020 (pdf) (på finska)

Materialbeställningar

Varför är tidsstämplarna för materialbeställning och svarsmeddelande olika till formen? I beställningen ger vi nedanstående uppgifter om var sökningen börjar och var den slutar. Det klockslag som vi uppgett är så vitt jag förstår Finlands tidszon, när den anges i formatet ”+02:00".

<ModifiedTimespanStart>2018-01-01T00:00:00+02:00</ModifiedTimespanStart>

<ValidFrom>2018-05-17</ValidFrom>

<OnetimeDeliverySchedule>

<Time>13:00:00+02:00</Time>

I svaret kom den hämtade intervallen. Där är formen dock avvikande, för "+02:00” saknas.  

<QueryTimespanStart>2017-12-31T22:00:00Z</QueryTimespanStart>

<QueryTimespanEnd>2018-05-17T11:00:00Z</QueryTimespanEnd>

Varför är tidszonen för svaret en annan än tidszonen för den beställning som sänts?

Hämtningsintervallet sparas i inkomstregistrets databas i UTC-tid oberoende av tidszonen i beställningen.

Det klockslag som anges i beställningen är vintertid i Finland, det vill säga två timmar tidigare jämfört med UTC-tid:

<ModifiedTimespanStart>2018-01-01T00:00:00+02:00</ModifiedTimespanStart>

I inkomstregistrets databas är tiden i UTC-tid:

<QueryTimespanStart>2017-12-31T22:00:00Z</QueryTimespanStart>

Hämtningar påbörjas alltid i finsk tid.

Om med behandlingsresponsen returneras vilket som helst Error-element, MessageErrors, DeliveryErrors eller ItemErrors, innebär detta alltid att man inte kan skapa någon egentlig svarsfil?

Om ett fel på meddelandenivå (MessageErrors) eller materialnivå (DeliveryErrors) förkommer i materialet, kan inte materialet behandlas. Om ett fel på objektnivå (ItemErrors) returneras ur materialet, är det möjligt att behandla materialet till den del som inställningarna för materialet tillåter.

Sändning av material

Tar inkomstregistret emot komprimerat material?

Inkomstregistret tar inte emot komprimerat material.

Om materialet är så stort att det måste sändas i flera delar, är delarna självständiga sändningar eller ska de ha en identifierare som anger att de hör till en större helhet?

Varje material är ett eget material. Materialet består alltså inte av separata delar. Ett versionsnummer kan anges för anmälan. Med hjälp av numret kan anmälaren rikta sin korrigering till gällande anmälan. Samma material kan dock inte ha kombinationerna ”ny-ersättande” eller ”ny-makulering” som riktas mot samma anmälan.

Hur behandlar inkomstregistret om anmälan innehåller fel?

En felaktig anmälan som inlämnats via det tekniska gränssnittet returneras alltid till betalaren. Betalaren får med behandlingsresponsen information om fel i anmälan. Reglerna för kontrollen av löneuppgiftsanmälan beskrivs i dokumentet ”Inlämnande av uppgifter – Scheman – Anmälan om löneuppgifter”.

Får informationsanvändaren information om en inlämnad anmälan om en felaktig anmälan utreds i inkomstregistret (t.ex. för kontroll av delgivningsskyldigheten)?

Om det finns ett fel i en anmälan på grund av vilket anmälan förkastas sparas eller behandlas anmälan inte i inkomstregistret. Betalaren får med behandlingsresponsen information om fel i anmälan. Betalaren ska lämna in en korrigerad anmälan inom fem kalenderdagar från betalningsdagen.

Till informationsanvändare skickas endast anmälningar som sparats korrekt i inkomstregistret. Informationsanvändarna har egna basregisteruppgifter med vilkas hjälp de själva övervakar hur betalarna uppfyller sin informationsskyldighet. Betalaren försummar sin anmälningsskyldighet om den inte lämnar in en korrigerad anmälan inom utsatt tid.

Distribution av material

Till inkomstregistret har lämnats med hämtningsintervall 1 version 1, som har hämtats i den första hämtningen. Med det andra hämtningsintervallet lämnas versionerna 2 och 3. Om det sökkriterium som getts är IncludeAllVersions = ”False”, hämtas med hämtningsintervall 2 då endast version 3? (25.5.2018)

Endast version tre hämtas.

Är ersättning och makulering jämförbara ur inkomstregistrets synvinkel? Om således version 3 i ovanstående fall i stället för ersättning skulle innebära makulering, fungerar då hämtningen på samma sätt så att endast makuleringen (version 3) hämtas?

Ja, det stämmer.

Och hur är det i en situation där man med samma hämtningsintervall har lämnat version 1 och makulering (version 2). Hämtas då utgående från kriteriet IncludeAllVersions = ”False” endast makulering för meddelandet (version 2)?

Ja.

Hur fungerar elementet med tidsinställning med meddelanden i SFTP-trafik? Om jag definierar innevarande dag i ValidFrom-data och om klockslaget den dagen redan är förbi, startar då hämtningen genast?

<Schedule>

<OnetimeDeliverySchedule>

<Time>11:00:00+02:00</Time>

</OnetimeDeliverySchedule>

</Schedule>

Jag antog att hämtningen skulle ha startat först följande klockslag i fråga, men det fungerade inte så här. Om jag vill göra en tidsinställning för efternatten följande dag, ska då följande dag definieras som ValidFrom-datum? (15.6.2018)

Om ValidFrom-datumet för en engångsbeställning är innevarande dag och klockslaget är i förfluten tid, startar hämtningen genast. För engångsbeställningen ska datum anges för framtiden, om man vill att hämtningen ska starta följande dag.

Den tidsinställda hämtningen inledes enligt tidsinställningen vis nästa tidpunkt.

Anmälan och anmälning

Om anmälan har skickats som en fil, kan en annan anmälningskanal, till exempel e-tjänsten, användas för korrigering?

Ja. Informationen kan skickas och korrigeras via olika kanaler. Samma anmälningskanal som för den ursprungliga anmälan behöver inte användas för korrigering av informationen.

Finns det begränsningar gällande användningstiderna för SFTP-gränssnittet eller Web Service-gränssnittet i inkomstregistret? Kan uppgifter hämtas till exempel endast vardagar eller även under helger och veckoslut?

Det finns inga tidsbegränsningar då det gäller användningen av det tekniska gränssnittets tjänster. Inkomstregistrets serviceavbrott, då även gränssnitten är ur bruk, anmäls på förhand. Läs mera: Inkomstregistrets serviceavbrott

Vad avses med anmälan?

Anmälan avser en inkomsttagares information för en betalningsgång. Om flera olika betalningar har gjorts till en och samma löntagare på samma betalningsgång, ska endast en anmälan lämnas in om dessa. Det kan finnas flera olika inkomstslag på en anmälan.

Kan flera anmälningar lämnas in om en och samma person, om arbetsgivaren har löneuppgifter i flera olika system?

Ja. Flera anmälningar kan lämnas in om en och samma person för samma löneperiod, och informationen kan anmälas från flera olika system. När "Ny" väljs som åtgärdstyp för anmälan, ersätter den inte föregående anmälan, utan alla anmälningar som getts under samma löneperiod förblir i kraft.

Med vilka referensuppgifter kan korrigeringar och makuleringar hänföras till de ursprungliga anmälningarna?

I inkomstregistret kan anmälningar ha två separata preciserande referenser: inkomstregistrets anmälningsreferens och betalarens betalningsreferens. Inkomstregistret ger automatiskt inkomstregistrets anmälningsreferens för en anmälan, om anmälan sparas i inkomstregistret. Dessutom får den som betalar prestationen fritt välja betalarens anmälningsreferens i det fall att uppgifterna sänds genom det tekniska gränssnittet eller nedladdningstjänsten.

Vilka uppgifter kan inte korrigeras med en ersättande anmälan? När ska man makulera en tidigare anmälan och lämna in en ny anmälan?

Uppgifterna ska korrigeras genom att makulera en tidigare anmälan och därefter lämna in en ny anmälan i följande situationer:

  • Korrigering av betalningsdatum
  • Korrigering av löneutbetalningsperiod
  • Korrigering av prestationsbetalarens och inkomsttagarens kundidentifierare
  • Korrigering av typ av tilläggsuppgift om inkomsttagaren då tilläggsuppgiften Idrottare eller Samfund ändras
  • Korrigering av typ av betalare då uppgiften Tillfällig arbetsgivare ändras
  • Korrigering av kundidentifieraren för egentlig arbetsgivare i datagruppen ställföreträdande betalare
  • Korrigering av uppgiften Fungerar som ställföreträdande betalare
  • Korrigering av inkomsttagarens födelsedatum
  • Korrigering av pensionsarrangemangsnummer
  • Korrigering av arbetsolycksfallsförsäkringsbolagets identifierare eller försäkringsnumret
  • Korrigering av uppgifter i Typ av undantagssituation för försäkring:
    • Ändring av uppgifterna Ingen försäkringsskyldighet retroaktivt
    • Ändring av uppgifterna Omfattas inte av tillämpningsområdet för Finlands socialskydd retroaktivt.
    • Ändring av uppgiften Frivillig försäkring i Finland (arbetspensionsförsäkring) retroaktivt.

Uppgifterna bör makuleras först då man kan lämna in en ny anmälan. Rekommendationen är att den tidigare anmälan makuleras och en ny anmälan lämnas in under en och samma dag.

Kan material och anmälan makuleras med samma anmälan om löneuppgifter som används för att ge nya och ersättande anmälningar?

Makulering av material och anmälan inlämnas inte med samma anmälan om löneuppgifter som nya och ersättande anmälningar. Makulering av anmälan har en egen materialtyp. Med denna materialtyp kan man makulera en enskild anmälan, hela materialet om löneuppgifter, arbetsgivarens separata anmälan eller materialbeställning. Makulering har en separat schemastruktur, vilket innebär att man till exempel inte behöver uppge de obligatoriska uppgifterna i samband med att en enskild anmälan om löneuppgifter makuleras.

Granskar inkomstregistret datainnehållet i materialet på samma sätt oavsett om materialet lämnats in elektroniskt eller på papper? Kontrollerar inkomstregistret i båda leverenskanalerna till exempel att prestationsbetalaren och inkomsttagaren inte är desamma?

Inkomstregistret gör samma granskningar i datainnehållet oberoende av vilken kanal man använt för anmälning av uppgifter (tekniskt gränssnitt, e-tjänst, ärendeskötseln på papper).

Enligt behandlingsreglerna kan prestationsbetalaren och inkomsttagaren inte vara samma person.