Snitfladebeskrivelse for. ukomplette og komplette betalinger. til NKS

Transkript

1 NemKonto KMD Selma Lagerlöfs Vej Aalborg Snitfladebeskrivelse for ukomplette og komplette betalinger til NKS Version Økonomistyrelsen er ansvarlig for NemKonto, som udvikles af KMD

2 Indholdsfortegnelse Indholdsfortegnelse Ændringer i forhold til forrige version...3 Ordliste n Formål og målgrupper Hvad er formålet med standardsnitfladen? Hvem er målgrupperne? Beskrivelse af betalingsflow NKS funktioner til behandling af betalingsmeddelelser Modtage betalinger i NKS (funktion 1) Kompletter betalinger (funktion 2) Videresend betalinger (funktion 3) Returmeldinger fra PI (funktion 4) Stands betalinger (funktion 5) Standardsnitfladens arkitektur Teknisk implementering Betingelser for anvendelse af standardsnitfladen Teknik Tilslutningsaftale Afleveringsfrister Versionstyring Garantier Indhold og beskrivelse af betalingsmeddelelse Opbygning af betalingsmeddelelse (NKSPayment) Indhold komplet og ukomplet betalingsmeddelelse Feltbeskrivelser for betalingsmeddelelse ebms header Niveau A Group Header (Bundtniveau) Niveau B - Payment Information (Debitor Niveau) Niveau C Payment Transaction (Kreditor Niveau) KMD Side

3 Indholdsfortegnelse 8.4 Valgfri/obligatoriske felter for komplet og ukomplet betaling Sammenhænge mellem felter: Kreditor navn og adresse Kreditor identifikation af virksomheder Brug af bankkode i udenlandske betalinger PI navn og adresse Adviseringstekst, fakturanummer og læselinie Kvitterings og retursvar Opbygning af Retursvar Referencer Kvitteringssvar0 (flowpil 0), Fejl - XML dokument ulæseligt Indhold af Kvitteringssvar Kvitteringssvar1 (flowpil 1), Advis - Modtagelse af Bundt Indhold af Kvitteringssvar Retursvar2 (flowpil 2). Modtagekontrol af betalinger Indhold af Retursvar Retursvar5 (flowpil 5). Fejl - stands betalinger Indhold af Retursvar Retursvar7 (flowpil 7). Fejl - kompletter betalinger Indhold af Retursvar Retursvar8 (flowpil 8). Advis - Betalinger videresendt til PI Indhold af Retursvar Totaler som angives (kun på Papir): Retursvar9 (flowpil 9). Fejl - PI-fejl Indhold af Retursvar Sikkerhed Registrering af benyttelse KMD Side

4 Ændringer i forhold til forrige version Version Dato Ændring Første version Følgende ændringer er fortaget ift. Version 1.0: Punkt 8.2 og 8.3 Indhold i komplet og ukomplet betalingsmeddelelse: Indsat Tidsfristtype som CPAid-element i ebms header. Tidsfristtypen angiver hvilke tidsfrist der gælder for modtagelse og videresendelse af betalingsordren til PI. 3.3 Payment Identification, End to end ID ændres fra A35 til A27. Dette skyldes at bundreference skal påsættes ved videresendelse til PI som CR3 reference. Dette er desuden tilføjet i afsnit og 3.11 Amount. Beløb angives med max. 15 cifre (indeholdende 3 decimaler og uden decimalseparator). Eks. angives 75,50 kr. som og 75 kr. som Instruction for Final agent, Code feltet udgår. Feltet anvendes ikke Incomplete Payment Indicator (Obligatorisk felt). Repræsentation er ændret til Boolean med værdisæt 1 (True) for ukomplet betaling eller 0 (False) for komplet betaling. Punkt 8.4 Valgfri/obligatoriske felter. Her er præciseret at hvis der udfyldes felter, ud over de påkrævede/valgfrie (eks. angivelse af Gebyrkode for Indenlandsk Komplet betaling eller ukomplet betaling) vil disse ikke blive anvendt i NKS. Punkt Retursvar (flowpil 9) PI-fejl. Fejltekst fra BANSTA - er samlet tekst, som indeholder fejlkode og/eller fejltekst, som er fastlagt af PI. Fejlteksten placeres altid i Additionel information og der sættes ukendt i Status Reason Følgende ændringer er fortaget ift. Version 1.1: Punkt 8.2 og 8.3 Indhold i komplet og ukomplet betalingsmeddelelse: Tidsfristtype som CPAid-element i ebms header udgår Charge Bearer er ændret til : For komplette udenlandske betalinger kan anvendes 'BEN', 'OUR' eller 'SHA', For ukomplette betalinger anfører NKS altid: 'BEN' (modtager) ved vidersendelse af udenlandske betalinger Side 3

5 Version Dato Ændring Følgende ændringer er fortaget ift. Version 1.2: Få kosmetiske ændringer er fortaget. Eks. Final institution Identification tag, indsat i betalingsmeddelelsesskema pkt Afsnit 9.5. Præcisering af Retursvar 2 ved fejl i alle/nogle af betalingerne i en betalingsmeddelelse Følgende ændringer er foretaget ift. Version 1.3: Afsnit 6.3: Afleveringsfrister frister for systemer, der sender til øvrige betalingsafviklende pengeinstitutter end Jyske bank indsat. Afsnit 8.3: 3.33 og 3.38: Tilføjet Swift-kode som obligatorisk til scenario C, Tilføjet scenario C til beskrivelsen af Swift-koden, samt præcisering omkring udfyldelse af IBAN, BBAN mv. for en komplet udenlandsk betaling Præcisering vedr. 1.1 Bundtreference og 3.3: UPR skal være unikke indenfor myndighed+dataleveramdør. 3.6 Purpose; Proprietary : Tilføjet præcisering af brugen af feltet (ydelsesart) Timestamp i ebms header og 1.2 Creation Timestamp angivelse af tidszone er valgfri for Timestamp. Afsnit 9.: Uddybning vedr. tidspunkter for afsendelse af kvittering og retursvarr; herunder ændring vedr. Retursvar 8: Retursvar 8 sendes elektronisk umiddelbart efter modtagelse af CONTRL for en PAYMUL. Uddybning/justering af fejltekster for de enkelte kvitteringer og retursvar Følgende ændringer er foretaget ift. Version 1.4: Afsnit 5: Tilføjet: På mindre driftsinstallationer uden mainframe kan anvendes en MQ-Series klient (IBM WebSphere MQ Client v. 5.3). Denne klient er gratis. Ved anvendelse af MQ klient opbevares returmeddelelser på en returkø hos KMD til de er hentet af klienten. Denne returkø må ikke indeholde over 50 meddelelser, herefter blokeres afsendelseskøen. I praksis bør klienten derfor tømme returkøen inden afsendelse. Afsnit 7: Tilføjet: KMD og Økonomistyrelsen er ansvarlige for snitfladen. Afsnit 8.1: Tilføjet: Størrelsesbegrænsninger. Det anbefales, at et enkelt bundt betalinger ikke indeholder over betalinger (4-6 MB). Betalingsbundter op til maksimalt beta Side 4

6 Version Dato Ændring linger (20-30 MB) accepteres dog. Ved behov for afsendelse af større mængder betalinger i et enkelt bundt skal dette aftales særskilt med KMD. Afsnit og 8.3.2: Afsnit om Timestamp, punktet Repræsentation, erstattes af: ISO-standard 8601 timestamp (YYYY-MM- DDThh:mm:ss) Visse XML-værktøjer sætter automatisk kode Z efter timestamp. Dette angiver anvendelse af GMT-tidszone (zulutid). Andre værktøjer påfører den lokale tidszone (f.eks. +02:00), og andre påfører ikke tidszone. Det er valgfrit om der påføres tidszone. Afsnit om Timestamp, punktet Validering, erstattes af: Validering: Valid timestamp Afsnit 8.3.1: Version 1.0 er erstattet med version 1.1 For Kvitteringer og retursvar vil versionsnummer være den gældende version for disse, uanset hvilken version af betalingsordre der er modtaget i NKS. Afsnit 8.3.1: Ændring til ebms messageid: Værdisæt for feltet er på MAX 35 tegn. Afsnit 8.2, 8.3.1, 8.4, 9.3.1, og 9.5.1: Feltet From; PartyId(2) (vedrørende proxy ID) på betalingsmeddelelser samt To; PartyId(2) på Kvitteringsvar 0 og 1 og retursvar 2. Feltet er ikke længere nødvendigt og UDGÅR derfor. Feltet vil ikke blive anvendt såfremt det sendes til NKS. Afsnit 8.3.2, punkt 1.3: Authorisation (NKS aftalenr.), rettes: Det fremgår at aftalenummeret er 8-cifret. Der kan imidlertid også være på færre cifre. Det præciseres, at foranstillede nuller ikke er nødvendige ved aftalenummer på færre en 8 cifre. Afsnit 8.3.2, punkt 1.8: Afsnit OrganisationsType, punktet Værdisæt, tilføjes: Bemærk, at i forbindelse med massetilslutning (statslige myndigheder) anvendes kun organisationstype 08. Afsnit punkt 2.15 og afsnit punkt 3.33: BBAN, her præciseres at feltet skal udfyldes med 14. Hvis kontonummeret ikke er 10 cifre langt, indsættes nuller mellem regnr og kontonummer (f.eks ) Afsnit 8.3.3, punkt 2.12: Tilføjes (vedr. PI aftalenummer): Nogle betalingsafviklende PI tillader ikke, at betalinger sendes med samme PI aftalenummer ad to forskellige kanaler. Det medfører, at betalinger sendt via NemKonto-systemet skal have et andet PI aftalenummer end betalinger, der sendes direkte til betalingsafviklende PI, selvom udbetalingen sker fra samme konto. Afsnit 8.3.3, punkt 2.26: Præciseres, at bogføringscentralerne kun viser de første 20 tegn på kontoudtog. Afsnit 8.3.4, punkt 3.3: Tilføjes til End-to-end Id, under Værdi Side 5

7 Version Dato Ændring sæt: For kunder i SKB (Statens Koncern Betalinger) gøres opmærksom på, at kun de første 20 cifre anvendes af Jyske Bank. Resten ses der bort fra. Desuden anbefales det, at de første 10 cifre af UPR udgøres af CPR, CVR, SE eller P-nr. CVR/SE numre foranstilles med to nuller. Denne anbefaling gælder for betalinger, hvor CPR/CVR/SE/P-nr. er myndighedens indgangsnøgle i banken til udbetalingen/modtageren af udbetalingen. Fx lønninger, SU, børneydelse, div. tilskud og støtteydelser osv. Afsnit 5: Ny formulering vedr. fejlmelding: Der gives kun en fejlmelding pr. betaling, d.v.s. hvis en betaling indeholder flere fejl, vil kun den 1. fejl,blive fejlmeldt. Afsnit 9.4: Nye fejlmeldinger tilføjet Kvittering 1: 14. Aftale:ikke startet/udløbet 15. Ugyldig Bogføringscentral 16. Invalidt ebms_messageid Afsnit 9.5: Nye fejlmeldinger tilføjet Retursvar 2: 19. BELØBSFELT ER FOR LANGT 20. INVALIDT POSTNUMMER 22. INVALID BRANCH KODE 43. ('INGEN TIDSFRISTER FOR DATALEVERANDØR/BOGFØRINGSCENTRAL') 44. ('BETALINGS ID SKAL ANGIVES FOR KORTART') 45. ('BETALINGSBELØB MÅ IKKE VÆRE KR. 0,00') Afsnit 9.6: Nye fejlmeldinger tilføjet retursvar 7: - Myndighed har valgt check retur - Fejltekst fra CPR- og CVR/SE-registret (eks ved. Ikke validt CRP) Afsnit 9.5.1, 9.6.1, og 9.8.1: Rettes: Multiplicitet for niveau B er ikke 0..n men 1..1 Afsnit 9.7: I tabellen under kolonnen Tilbagemelding til offentlig myndighed tilføjes: Bemærk, at betalinger, der er sendt til pengeinstitut som checkordrer ikke fremgår af retursvar 8, men af retursvar 7. Afsnit 9.7.1: Værdisæt for TransactionStatusCode rettes, så Pending erstattes med ACPT. Tekst rettes til: Angiver at betalingen er videresendt og modtaget af banken. Evt. efterfølgende fejl fra PI vil fremgå af Retursvar Følgende ændringer/præciseringer er lavet ift. version 1.5: kapitel 6.3, Tilføjet: Eksempel vedr. bankdage og afleveringsfrister. kapitel 7, Slettet: Afsnittet vedr. ændringer frem til idriftsættelse Side 6

8 Punkt 3.38, BIC, Rettet: Feltet er obligatorisk for komplette udlandsbetalinger. Multiplicitet ændret til NKS præcisering Afsnit 8.3.1, PartyId(2), Præciseret: PartyId(2) returneres IKKE i Kvitteringssvar0. punkt 2.15, BBAN, Rettet: max slettet i repræsentation af reg.nr. og kontonr. Disse skal altid være hhv. 4 og 10 cifre. punkt 2.15, IBAN, Rettet: IBAN repræsentation ændret fra max. 35 til max. 34 tegn. punkt 3.31, Creditor Name, rettet: Creditor Name ændret fra obligatorisk til valgfrit felt. punkt 3.31, Creditor, Postal Address, Country, rettet: Country ændret fra obligatorisk til valgfrit felt punkt 3.33, scenario D, rettet: ClearingSystemMemberIdentification ændret til ProprietaryId;Id. punkt 3.38, PI Name, rettet: Pengeinstitut Name ændret fra obligatorisk til valgfrit felt. punkt 3.38, Final agent, Postal address, Country, rettet: Country ændret fra obligatorisk til valgfrit felt. afsnit 8.4, tilføjet: SWIFT referencenumre nyt afsnit 8.5 nederst, tilføjet: Nyt afsnit med uddybende beskrivelse af sammenhænge mellem udvalgte felter: - kreditor navn og adresse - kreditor identifikation af virksomheder - brug af bankkode i udenlandske betalinger - PI navn og adresse adviseringstekst, fakturanummer og læselinie afsnit 9, præciseret: NB: I visse sjældne situationer sender pengeinstituttet fejlmeddelelser før kvittering. Dette kan medføre, at Retursvar9 bliver sendt FØR Retursvar8. Afsnit 9.3.1, PartyId(2), præciseret: PartyId(2) returneres IKKE i Kvittering0. Afsnit 9.4, Kvitteringsvar1, fejltekster, tilføjet/ændret: 2. Datalev:ingen betalingsrolle (tekst rettet/afkortet) 6. Forkert aftale nr. for mynd. (rettet/afkortet) 11. Ukendt aftale nr. (rettet) Side 7

9 13. Manglende slut record UDGÅET 18. Invalid afsender konto (ny) 19. Beløbsfelt er for langt (ny) Afsnit 9.5, Retursvar2, rettet: Afsnittet vedr. Fejlmelding i Retursvar2 omformuleret, fordi der var fejl i den gamle beskrivelse ifm. fejlmelding, når der var fejl i alle betalinger i et bundt. Afsnit 9.5, Retursvar2, fejltekst, rettet: Fejltekst 43 ændret fra Ingen tidsfrister for dataleverandør/bogføringscentral til Opsætningsfejl i NKS vedr tidsfrist. Afsnit 9.5, Retursvar2, tilføjet: Bemærkning vedr. genbrug af bundtreference og UPR Afsnit 9.6, Retursvar7, fejlmelding, rettet: Afsnittet omstruktureret. Fejlteksten vedr. Myndigheden har valgt check retur er ændret. Der er suppleret med flere fejl- og advistekster vedr. udlandsbetalinger. Afsnit 9.6.1, status reason, rettet: Beskrivelsen af ADVI generaliseret. Afsnit 9.7, Retursvar8, fejlmelding, tilføjet: Beskrivelse af opbygning af Retursvar8 i blokke for hhv. grouping=yes og grouping=no. Afsnit 9.7.1, Retursvar8, Creditor, rettet: Multiplicitet ændret for tags i Postal address, samt tilføjet henvisning til afsnit vedr. sammenhænge mellem felterne i kreditors navn og adresse. Afsnit 9.7.1, Retursvar8, Final Agent, rettet: Multiplicitet ændret for tags i Final agent, samt tilføjet henvisning til afsnit vedr. sammenhænge mellem felterne i PI navn og adresse Ordliste Tilføjet Definition af bogføringscentralen Afsnit 3, Figur 1 rettet: Retursvar 5 tilføjet Afsnit 3.1.1, Rettet: Beskrivelsen vedrørende enkeltebetalinger udgår. Afsnit 3.1.2, Rettet: Beskrivelsen vedrørende komplettering. Afsnit 3.1.5, tilføjet: Beskrivelse af ny funktion, Stands betaling Afsnit 4, rettet: KMD VANS vises på arkitektur tegning Afsnit 6.3, rettet: Beskrivelse af tidsfrister for enkeltebetalinger udgået. Afsnit 6.4, tilføjet: Versionstying Side 8

10 Afsnit 8.2, EBMS header rettet: From:PartyId(2) indeholder EAN-nummer To:PartyId(1) indeholder NKS/NKSTEST To:PartyId(2) indeholder EAN-nummer Group Header rettet: 1.11 Instruction for NKS, tilføjet Payment Transaction rettet: 3.2 Instruction ID, tilføjet Afsnit 8.3.1, EBMS header rettet: Afsnit 8.3.2, Group header rettet: 3.6 Purpose:Proprietary, ændret formål 3.9, 3.11 Udenlandsk valuta tilladt 3.50, 3.57 Instruction for First Agent tilføjet 3.90, Benefit Type (Ydelsesart) tilføjet Mapning og validering af Version rettet From:PartyId (2) rettet (EAN-nummer) To:PartyId (2) Værdisæt rettet (EAN-nummer) 1.11 Instruction for NKS, tilføjet Afsnit 8.3.3, Payment Information rettet: 2.1 Validering af udbetalingsdato rettet Afsnit 8.3.4, Payment Transaction rettet: 3.2 Instruction ID, tilføjet 3.3 End-to-end Id, beskrivelsen rettet. 3.6 Purpose:Proprietary, ændret formål 3.9, Validering af valutakode ændret 3.57 Instruction for First Agent tilføjet 3.83 Document Reference No, Sammenhænge 3.90 Benefit Type (Ydelsesart) tilføjet Afsnit 8.4 rettet: Tabel over valgfri/obligatoriske felter opdateret med nye felter Afsnit 9 rettet: Beskrivelse vedrørende nyt Retursvar 5 tilføjet. Afsnit 9.2 tilføjet: Debitors betalingsreference Side 9

11 Afsnit 9.3 rettet: Beskrivelse af fejlmelding i Kvitteringssvar0 Afsnit rettet: From:PartyId(1) indeholder NKS/NKSTEST From:PartyId(2) indeholder EAN-nummer To:PartyId(2) indeholder EAN-nummer ErrorList tilføjet Afsnit 9.4 rettet: Beskrivelse af fejlmelding i Kvitteringssvar1, error 13 udgået Afsnit rettet: From:PartyId(1) indeholder NKS/NKSTEST From:PartyId(2) indeholder EAN-nummer To:PartyId(2) indeholder EAN-nummer ErrorList tilføjet Afsnit 9.5 rettet: Validering vedrørende enkeltebetalinger udgået, beskrivelse af ACPT Retursvar2 tilføjet. Fejlkoder tilføjet. Afsnit EBMS Header rettet: From:PartyId(1) indeholder NKS/NKSTEST From:PartyId(2) indeholder EAN-nummer To:PartyId(2) indeholder EAN-nummer Original Group ReferenceInformation and Status rettet Group Status, Værdi ACPT tilføjet rettet Original Transaction Reference Information and Status Instruction ID, tilføjet Afsnit 9.6 tilføjet: Nyt Retursvar5 tilføjet Afsnit 9.7 rettet: Fejlmelding vedrørende fejlkonto tilføjet, kundecheck udgået Afsnit General Information rettet: Dataleverandør kortnavn tilføjet (kun på papir) Instruction ID, tilføjet Original Transaction Information tilføjet. Afsnit General Information rettet: Instruction ID, tilføjet Afsnit 9.9 rettet: Fejlmelding vedrørende fejlkonto tilføjet, kun Side 10

12 decheck udgået Afsnit General Information rettet: Dataleverandør kortnavn tilføjet (kun på papir) Instruction ID, tilføjet Original Transaction Information tilføjet Side 11

13 Side 12

14 Ordliste Terminologi Aftaleregister Betalingsafviklende pengeinstitut Betalingsdatabase Bogføringscentral CAP/IP CPR CVR Dataleverandør Fejludbetaling Ikke kompletteret betaling KMD CAP I/P Komplet betaling Kompletteret betaling KSP / CICS Definition Et register til styring af aftaler med offentlige myndigheder i forbindelse med tilslutning til NemKonto-systemet. Registeret indeholder bl.a. aftaletype, anvendelse, kompletteringsfaciliteter, håndtering af kvitteringer og fakturering. Betegnelse for de bogføringscentraler, der sørger for betalinger fra det offentlige til betalingsmodtager. Indeholder alle betalinger, der bliver håndteret at NemKonto-systemet. En bogføringscentral er betegnelsen for den datacentral, som myndighedens pengeinstitut benytter. Kan pt. være Jyske Bank, Nordea, Danske Bank, SDC, BEC og Bankdata. Forkortelse for Common Access Point / Internet Protocol. CAP/IP anvendes til sikring af kommunikation mellem KMD og kunderne via dedikerede kredsløb. Yderligere information om KMD CAP/IP kan indhentes ved at kontakte afdelingen KMD Netbroker på telefon nr Forkortelse for det Centrale Personregister, som indeholder data om alle personer i Danmark. Forkortelse for det Centrale Virksomhedsregister, som indeholder data om alle virksomheder i Danmark. CVR-nummeret er virksomhedens identifikationsnummer over for offentlige myndigheder. Identifikation af det system som fremsender betalingsmeddelelser til NKS. Dataleverandør kortnavn tildeles i forbindelse med indgåelse af aftale om anvendelse af snitfladen. Alle nye dataleverandører i NKS skal bestå en tilslutningsprøve. Et dataleverandør kortnavn kan benyttes af flere myndigheder (fx fællessystemer) eller være specifik for en myndighed (fx et enkeltstående PC-system). En komplet eller kompletteret betaling, der af en eller anden årsag ikke kan effektueres af det betalingsafviklende pengeinstitut, og derfor er sendt tilbage til NemKonto-systemet som en fejludbetaling. Modtaget ukomplet betaling, der endnu ikke er kompletteret og sendt videre. Se CAP / IP. En komplet betaling er fuldt udfyldt inkl. modtagerkontonummer af den udbetalende myndighed og videresendes uændret til betalingsafviklende pengeinstitut. En modtaget ukomplet betaling som før videresendelse af NKS er påført ennemkonto eller en Specifik konto. Forkortelse for KMDs SikkerhedsProdukt, som er et sikkerhedssystem til CICS / MVS, der sikrer forsvarlig anvendelse af CICS-transaktioner og af Side 13

15 Terminologi LOS Moduluskontrol MQ Myndighedsnummer NemKonto NKS OCES Offentlig myndighed P-data PI-register P-nr SE-nr Definition de data, der anvendes i denne forbindelse. Med LOS (LinieOrganisationsSystem) er det muligt at samle og organisere oplysninger om, hvilke administrative enheder der indgår i organisationen. De administrative enheder, som f.eks. kan være en forvaltning, en afdeling eller en institution, er registreret med oplysninger om navn, adresse, type og lignende oplysninger. En linieorganisation er et hierarki, som består af et antal af sådanne administrative enheder, hvor en enhed refererer til en overordnet enhed. I samspil med KSP / CICS er det muligt at tildele autorisationer på forskellige niveauer i organisationen. Detaljeret beskrivelse findes her: Kontrol der sikrer, at det angivne kontonummer er korrekt i forhold til PBS modulusregister, som indeholder valide intervaller af pengeinstitut registreringsnumre og kontonumre. Forkortelse for Message Queue, som er en metode til udveksling af data. Entydig identifikation af en myndighed i NKS, der bl.a. benyttes af LOS og KSP / CICS. Betegnelsen for den konto, hvortil de offentlige myndigheder med frigørende virkning kan foretage udbetaling af ydelser til borgere og virksomheder. Forkortelse for NemKonto-systemet. Forkortelse for Offentlige Certifikater til Elektroniske Services, som i daglig tale kaldes digital signatur. En digital signatur baserer sig på PKI (Public Key Infrastructure, Offentlig nøgleinfrastruktur), som er en infrastruktur, der muliggør entydig fastlæggelse af identifikation, og hemmeligholdelse i elektronisk kommunikation mellem to parter. Fælles betegnelse for amter, kommuner og statslige myndigheder. P-data står for Person-data, og er en KMD standardkomponent, der indeholder relevante data fra CPR-registret. Forkortelse for PengeInstitut-register, som indeholder pengeinstittuternes registreringsnumre. Forkortelse for Produktionsnummer, som angiver en produktionsenhed i en virksomhed SE er en forkortelse for Stamregister over Erhvervsdrivende, og SE-nr er det nummer man får tildelt af Told Skat i forbindelse med registreringen som en virksomhed, der skal trække bidrag og A-skat. Det er det nummer, som virksomheden er registreret under i det register, som Told Skat har Side 14

16 Terminologi Specifik konto SWIFT-kode TCP / IP Udbetalende enhed Ukomplet betaling UPR V-data Ydelsesart Definition oprettet til brug for bl.a. opkrævningen af AM-bidrag, SP-bidrag og A- skat. Betegnelsen for en konto, hvortil de offentlige myndigheder med frigørende virkning kan foretage udbetaling af en specifik ydelse til borgere og virksomheder, f.eks. børnebidrag eller pension. Forkortelse for Societé Worldwide International Fonds Transfer. SWIFT er en organisation som varetager udvekslingen af internationale betalinger. SWIFT-koden er en unik bogstavkode, som alle banker har, og som identificerer den enkelte bank. Forkortelse for Transmission Control Protocol / Internet Protocol, som er en standard for kommunikation på internettet. En betegnelse for en administrativ enhed i den offentlige myndighed, der står for en given udbetaling. En betaling fra en offentlig myndighed, der skal kompletteres med kontonummeret fra enten en Nemkonto eller en Specifik konto inden den sendes videre til det betalingsafviklende pengeinstitut. Forkortelse for Unique Payment Reference. Den udbetaliende myndigheds unikke identifikation af en betaling. Alle betalinger skal indeholde en UPR, som er genereret af de afsendende systemer. V-data står for Virksomheds-data, og er en KMD standardkomponent, der indeholder relevante data fra CVR. Betegnelse, der anvendes for de forskellige typer af ydelser, som de offentlige myndigheder udbetaler til borgere / virksomheder, f.eks. boligsikring eller landbrugsstøtte Side 15

17 1 n Denne snitfladebeskrivelse udgør grundlaget for indgåelse af konkrete aftaler med KMD's kunder om udveksling af data med NemKonto Systemet (herefter kaldet for NKS) baseret på standardsnitfladen. Grundlag for indgåelse af aftaler. Beskrivelsen er desuden et praktisk arbejdsredskab til støtte for kommunikationen mellem kunderne og KMD om standardsnitfladens anvendelse. Beskrivelsen må ikke overdrages eller kopieres i videre omfang end forudsat i ophavsretsloven men kun udlånes til softwareleverandører i forbindelse med etablering af snitfladen samt ved fremtidige ændringer. Henvendelser vedrørende standardsnitfladen rettes til: Udlån til andre leverandører. Kontakt til KMD. NemKonto Support, tlf Formål og målgrupper 2.1 Hvad er formålet med standardsnitfladen? Formålet med snitfladen er at beskrive kommunikation mellem offentlige myndigheders udbetalingssystemer og NKS. Systemerne leverer betalingsordrer til NKS som behandler disse og returnerer kvitteringer og retursvar til afsendersystemet. 2.2 Hvem er målgrupperne? Der er p.t. identificeret følgende interessenter: Udviklerne af NKS host og XML-broker applikationer. Udviklerne af eksterne udbetalingssystemer, som skal tilpasses til at kommunikere direkte med NKS. Offentlige myndigheder Side 16

18 3 Beskrivelse af betalingsflow. FIGUR Side 17

19 3.1 NKS funktioner til behandling af betalingsmeddelelser NKS systemet modtager betalingsordrer fra de offentlige myndigheder via udbetalingssystemerne/dataleverandørerne. NKS behandling af betalingerne er, som det fremgår af betalingsflow (Figur 1), opdelt i en række hovedfunktioner. Formål med de enkelte funktioner samt disses kvitterings- eller retursvar til dataleverandørerne, er kort beskrevet nedenstående. Uddybende beskrivelse af Betalingsmeddelelsen findes i afsnit 8 og beskrivelse af kvitterings- og retursvar findes i afsnit Modtage betalinger i NKS (funktion 1) Funktionen Modtage betalinger i NKS (funktion 1) er opdelt i tre delfunktioner: 1. XML Broker funktion, 2. Forbrænderfunktion og 3. Funktionen Modtagekontrol af betaling. XML Broker funktionen behandler alle indkomne betalingsordrer. Alle betalinger fra en dataleveandør modtages i samme MQ kø uanset om der er få eller mange betalinger. Brokerfunktionen sender Kvitterings- og retursvar via en separat kø. XML Brokerfunktionen validerer om XML-formatet er overholdt. Er dette ikke tilfældet stoppes behandlingen af meddelelsen og der sendes fejlmelding til afsendersystemet. Hvis afsender ikke kan identificeres skrives på en Bad Message kø. Den bliver så håndteret af NKS og NemKontosupport. Yderligere beskrivelse af Kvittering fra XML brokerfunktionen (Kvitteringssvar 0) fremgår af afsnit 9.3. Overholder XML-dokumentet XML-skemaets formater, pakkes XML-dokumentet ud, og betalinger overføres til Forbrænderfunktionen. I Forbrænderfunktionen foretages en første indgangskontrol af betalingsordren. Indgangskontrollen omfatter bla. Check for dobbeltforsendelse på bundtniveau, Kontrol af at sum-totaler og antal transaktioner er korrekt. Resultat af indgangskontrollen vil være enten en afvisning eller accept af betalingsmeddelelsen/bundtet. Accepteres betalingsmeddelelsen sendes betalingerne videre til funktionen Modtagekontrol af betalinger. Afvises bundtet foretages ikke yderlig behandling af betalingsmeddelelsen i NKS og bundtet skal genfremsendes fejlrettet. Kvittering fra Forbrænderfunktionen (Kvitteringssvar 1) er beskrevet i afsnit 9.4. I funktionen Modtage betalinger, modtages og valideres alle indkomne betalingsordrer iht. valideringsregler. Alle ikke afviste betalinger gemmes i databasen for videre behandling i NKS. Betalinger som afvises i denne funktion gemmes ikke i databasen. Retursvar fra Modtagekontrol af betalinger (Retursvar 2) er beskrevet i afsnit Side 18

20 3.1.2 Kompletter betalinger (funktion 2) Funktionen har til formål at komplettere de modtagne ukomplette betalingsordrer med det aktuelle Nemkonto/Specifikke kontonummer. Hvis der ikke kan tildeles Nemkonto/specifik konto sendes som bankcheck, anvises til fejlkonto eller der sendes fejlmeddelelse i henhold til nedenstående regelsæt. Overordnet regelsæt for komplettering: 1. Benyt Specifik Konto registreret på beløbsmodtager for aktuel ydelsesart. 2. Benyt NemKonto, registreret på beløbsmodtager, hvis Specifik Konto ikke findes. 3. Hvis konto ikke findes, og der findes Instruktion til Nemkonto på bundt niveau skal betaling behandles på måden angivet i Instruktion til NemKonto, og der sendes en retursvar7. De mulige behandlinger er: a. Anvises til fejlkonto. b. Sendes som bankcheck. c. Retur (fejlmelding). 4. Hvis konto ikke findes, og der ikke findes Instruktion til Nemkonto på bundt niveau skal betaling behandles som valgt iht. Aftaleregistret, og der sendes en retursvar7. De mulige behandlinger er: a. Anvises til fejlkonto. b. Sendes som bankcheck. c. Retur (fejlmelding). Hvis den valgte behandling ikke understøttes af bogføringscentralen, sendes en fejlmeddelelse (retursvar7) Retursvar fra Kompletter betalinger (Retursvar 7) er beskrevet i afsnit 9.7. Når kompletteringen er gennemført overføres de kompletterede og komplette betalinger til PI vha. funktionen Videresendelse betalinger Videresend betalinger (funktion 3) Funktionen har til formål at overføre komplette og kompletterede betalinger fra NKS til betalingsafviklende pengeinstitut. Betalingerne flyttes når tidsfrister for betalingsordren er nået (afhængig af udbetalingsdato og betalingsafviklende pengeinstitut). Alle betalingsordrer opbygges/konverteres til EDIFACT-format (PAYMUL) som overføres til PI. Retursvar fra Videresendt betalinger (Retursvar 8) er beskrevet i afsnit 9.8. Retursvar 8 genereres dog først umiddelbart efter at Forsendelsen (PAYMUL) er accepteret af PI (se desuden efterfølgende afsnit) Side 19

21 3.1.4 Returmeldinger fra PI (funktion 4) I denne funktionen håndteres kvitteringssvar (CONTRL) for betalinger videresendt til betalingsafviklende pengeinstitut. Umiddelbart efter modtagelse af CONTRL for en PAYMUL dannes Retursvar 8. Funktionen modtager og behandler desuden meddelelse fra pengeinstitut om kontooverførsler/betalinger, som ikke kan gennemføres (BANSTA). Retursvar fra Returmeldinger fra PI (Retursvar 9) er beskrevet i afsnit Stands betalinger (funktion 5) Sagsbehandlere i offentlige myndigheder kan via standse betalinger, som ligger i NemKonto-systemet, og endnu ikke er kompletteret og videresendt til de betalingsafviklende pengeinstitutter. Betalinger der er standset via funktionaliteten Stands enkeltbetaling eller Stands bundt på vil blive returneret til det udbetalende system i Retursvar5 (beskrevet i afsnit 9.6). Betalinger der er standset via funktionaliteten Stands enkeltbetaling på kan også blive anvist til fejlkonto hvis myndigheden har valgt FEJLKONTO i tilslutningsaftale eller funktion er valgt via Instruktion til NemKonto, og hvis bogføringscentralen understøtter den funktionalitet Side 20