NemKonto. XML skemaer for. ukomplette og komplette betalinger. til NKS

Transkript

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

2 Indholdsfortegnelse Indholdsfortegnelse 1 Hvad er formålet med snitfladen? Nemkonto systemet Indhold i XML-snitflade for betalinger Ændringer ift. Tidligere versioner af leverancen: Grafisk overblik Miljø Ansvarlige Ansvarlig for skemaafleveringen Ansvarlig for snitfladen Beskrivelse af NKS betalingsflow Betalingsordre til NKS Opbygning af betalingsmeddelelse Afvigelser fra Swift Særlige problemstillinger ifht. betalingsmeddelelsen Kvittering- og retursvar Bilag NKS_Betaling_Skemaer.zip NKS_Betaling_Metadata.zip NKS_Betaling_XML_eksempler.zip Grænsefladebeskrivelse for komplette og ukomplette betalinger til NKS KMD Side

3 1 Hvad er formålet med snitfladen? Formålet med snitfladen er at beskrive dataudvekslingen mellem offentlige myndigheders udbetalingssystemer og Nemkontosystemet (NKS) i forbindelse med fremsendelse af betalingsordre og modtagelse af kvitteringer og retursvar fra NKS. 1.1 Nemkonto systemet Folketinget har vedtaget at indføre en NemKonto for alle borgere og virksomheder. NemKontoen skal forenkle indberetning af kontooplysninger for borgere og virksomheder og sikre, at udbetalinger fra det offentlige kan foregå elektronisk. NemKonto-systemet vil indeholde én NemKonto for alle borgere og virksomheder, hvortil alle udbetalinger fra det offentlige som hovedregel bliver udbetalt til. Fra idriftsættelsen af NemKonto systemet skal offentlige myndigheder sende udbetalinger til Nem- Konto-systemet, der sender dem videre til myndighedens pengeinstitut. Alle offentlige myndigheder, der foretager udbetalinger, skal tilsluttes NemKonto-systemet. De betalinger myndighederne afsender skal ikke længere indeholde modtagerens kontonummer, men alene modtagerens CPR-nr. eller CVR-nr. For virksomheder gælder endvidere, at disse kan identificeres ved P-nr. og SE-nr. De betalinger, der ikke indeholder modtagerens kontonummer, betegnes som ukomplette betalinger. Der er dog mulighed for at påføre modtagerens kontonummer i betalingsordrer, disse betalinger betegnes som komplette betalinger. Når NemKonto-systemet modtager de ukomplette betalinger fra de offentlige myndigheder, påfører systemet modtagernes NemKonto og sender betalingen videre til afvikling i den udbetalende myndigheds pengeinstitut (betalingen er herefter komplet ). Afsendelse af betalinger efter overgangen til NemKonto er illustreret i nedenstående figur. Myndighed Ukomplette betalinger NemKontosystemet Kompletterede betalinger Myndighedens pengeinstitut Systemerne leverer betalingsordrer til NKS som behandler disse og returnerer kvitteringer og retursvar til afsendersystemet Side 2

4 2 Indhold i XML-snitflade for betalinger XML-Snitfladen til dataudveksling mellem offentlige myndigheders udbetalingssystemer og NKS i forbindelse med fremsendelse af betalingsordre og modtagelse af kvitteringer og retursvar fra NKS omfatter XML skemaer, XML metadata og XML eksempler for: Betalingsordrer til NKS (NKS_NKSPayment) Kvitteringssvar 0 (NKS_NKSReceipt0) Kvitteringssvar 1 (NKS_NKSReceipt1) Retursvar 2 (NKS_NKSResponse2) Retursvar 5 (NKS_NKSResponse5) Retursvar 7 (NKS_NKSResponse7) Retursvar 8 (NKS_NKSResponse8) Retursvar 9 (NKS_NKSResponse9) Alle skemaerne er komplette skemaer, der ikke refererer til underskemaer udenfor leverancen. En fuldstændig liste over de enkelte skemaer kan findes i afsnit 8 Bilag. Efterfølgende afsnit 6-8 indeholder en overordnet beskrivelse af NKS betalingsflow med tilhørende beskrivelse af kvitterings- og retursvar. Yderligere og uddybende beskrivelse er indeholdt i gældende version af dokumentet: Snitfladebeskrivelse for komplette og ukomplette betalinger til NKS på Ændringer ift. tidligere versioner af leverancen: Version Beskrivelse af ændring Skemaændringer fra version 1.1 til version 2.0 Leverancen med version 2.0 indeholder alle skemaer. Skemaerne opdateres og findes I mappe 2006/05/01. Nedenstående er listet ændringerne til de enkelte skemaer. Alle skemaer Namespaces ændres til 2006/05/01 NKS_NKSPayment.xsd Ændringer i underliggende definitioner medfører: 1. I <MessageHeader> er <ErrorList> indsat 2. I <GrpHdr> er <InstrNks> indsat 3. I <PmtId> under <PmtTx> er <InstrId> indsat 4. I <Purp> under <PmtTx> er <Prtry> rettet 5. I <PmtTx> er <InstrForFrstAgt> indsat 6. I <PmtTx> er <BenefitType> indsat NKS_NKSReceipt0.xsd Ændringer i underliggende definitioner medfører: 1. I <MessageHeader> er <ErrorList> indsat Side 3

5 NKS_NKSReceipt1.xsd Ændringer i underliggende definitioner medfører: 1. I <MessageHeader> er <ErrorList> indsat NKS_NKSResponse2.xsd Ændringer i underliggende definitioner medfører: 1. I <MessageHeader> er <ErrorList> indsat 2. I <OrgnlGrpRefInfAndSts> er <AddtlInf> indsat 3. I <PmtId> under <OrgnlTxRefInfAndSts> i <OrgnlPmtInf> er <InstrId> indsat NKS_NKSResponse5.xsd Nyt skema. Skemaet er en kopi af NKS_NKSResponse2 og skal benyttes til elektronisk svar efter standsning af bundt. NKS_NKSResponse7.xsd Ændringer i underliggende definitioner medfører: 1. I <OrgnlGrpRefInfAndSts> er <AddtlInf> indsat 2. I <PmtId> under <OrgnlTxRefInfAndSts> i <OrgnlPmtInf> er <InstrId> indsat 3. I <OrgnlTxRefInfAndSts> under <OrgnlPmtInf> er <OrgnlTxInf> indsat, idet Niveau E Original Transaction Information (yderligere info på Kreditor niveau) tilføjes NKS_NKSResponse8.xsd Ændringer i underliggende definitioner medfører: 1. I <OrgnlGrpRefInfAndSts> er <AddtlInf> indsat 2. I <PmtId> under <OrgnlTxRefInfAndSts> i <OrgnlPmtInf> er <InstrId> indsat NKS_NKSResponse9.xsd Ændringer i underliggende definitioner medfører: 1. I <OrgnlGrpRefInfAndSts> er <AddtlInf> indsat 2. I <PmtId> under <OrgnlTxRefInfAndSts> i <OrgnlPmtInf> er <InstrId> indsat 3. I <OrgnlTxRefInfAndSts> under <OrgnlPmtInf> er <OrgnlTxInf> indsat, idet Niveau E Original Transaction Information (yderligere info på Kreditor niveau) tilføjes SWIFT_NKSPayment.xsd 1. Tilføjet <InstrNks> til <GrpHdr> ved at rette complextype GroupInformation1 : <element name="instrnks" type="swift:instrnkstype" minoccurs="0" maxoccurs="unbounded"/> Øvrige definitioner knyttet til <InstrNks> er også blevet tilføjet: <complextype name="instrnkstype"> <sequence> <element name="cd" type="swift:max35text"> <annotation> <documentation>kode for instruktion</documentation> </annotation> </element> <element name="addtinf" type="swift:max140text"> <annotation> <documentation>valg af service</documentation> </annotation> </element> </sequence> </complextype> Side 4

6 2. Tilføjet <InstrForFrstAgt> og <BenefitType> til <PmtTx> ved at rette complextype GenericPaymentTransaction3 <element name="instrforfrstagt" type="swift:instructionforfirstagent" minoccurs="0"/>... <element name="benefittype" type="swift:max6text" minoccurs="0"> <annotation> <documentation>ydelsesart korttekst</documentation> </annotation> </element> Øvrige definitioner knyttet til <InstrForFrstAgt> er også blevet tilføjet: <complextype name="instructionforfirstagent"> <sequence> <element name="prtry" type="swift:max140text" minoccurs="0"> <annotation> <documentation>instruktion til bogføringscentral</documentation> </annotation> </element> </sequence> </complextype> 3. I <Purp> under <PmtTx> er brug af <Prtry> ændret ved at rette til: <documentation>tekst til modtagers kontoudtog</documentation> Ingen ændringer SWIFT_A_General- Information.xsd SWIFT_B_OriginalGroup- ReferenceInformation.xsd 1. Tilføjet valgfrit element <AddtlInf> i complextype OriginalGroup- ReferenceInformation1 for at tilgodese nyt retursvar 5: <element name="addtlinf" type="swift:max105text" minoccurs="0"> <annotation> <documentation>uddybende tekst</documentation> </annotation> </element> SWIFT_C_OriginalPayme ntinformation.xsd Ingen ændringer SWIFT_D_Original- TransactionReference- InformationAndStatus.xsd SWIFT_E_Original- TransactionInformation.xsd 1. Tilføjet ny complextype PaymentInformation9b med yderligere element <OrgnlTxInf> pga. behov for Niveau E Original Transaction Information (yderligere info på Kreditor niveau) for retursvarene 7 og 9 2. Gjort <StsRsn> valgfri aht. nyt retursvar 5 Ingen ændringer SWIFT_Package.xsd Ingen ændringer Side 5

7 SWIFT_Common.xsd 1. Indsat <InstrId> i <PmtId> under <PmtTx> (Niveau C - Payment Transaction / Kreditor niveau) ved at tilføje følgende til PaymentIdentification: <element name="instrid" type="swift:max35text" minoccurs="0"> 2. Udvidet værdisæt til simpletype PaymentGroupStatusCode aht. positivt retursvar 2: <enumeration value="acpt"/> 3. Tilføjet simpletype Max6Text til brug af nyt felt <BenefitType> EBMS_Common.xsd 1. Opstramning på brug af <PartyId> ved at angive documentation: <documentation>partyid(1) skal indeholde kortnavn, PartyId(2) skal indeholde EAN-nummer.</documentation> 2. Indsat <ErrorList> i <MessageHeader>: <element ref="ebms:errorlist" minoccurs="0"/> Øvrige definitioner knyttet til <ErrorList> er også blevet tilføjet <element name="errorlist"> <complextype> <sequence> <element ref="ebms:error" maxoccurs="unbounded"/> </sequence> <attribute name="highestseverity" type="ebms:severity.type" use="required"/> </complextype> </element> <element name="error"> <complextype> <sequence> <element ref="ebms:description" minoccurs="0"/> </sequence> <attribute name="errorcode" type="ebms:non-empty-string" use="required"/> <attribute name="severity" type="ebms:severity.type" use="required"/> </complextype> </element> <element name="description"> <complextype> <simplecontent> <extension base="ebms:non-empty-string"/> </simplecontent> </complextype> </element> <simpletype name="severity.type"> <restriction base="nmtoken"> <enumeration value="warning"/> <enumeration value="error"/> </restriction> </simpletype> Side 6

8 2.2 Grafisk overblik Side 7

9 3 Miljø Til udarbejdelse af XML skemaerne er anvendt XML Spy og Internet Explorer. 4 Ansvarlige 4.1 Ansvarlig for skemaafleveringen Henvendelser vedrørende skemaafleveringen rettes til: Espen Jürgensen, yderligere info på Ansvarlig for snitfladen Henvendelser vedrørende snitfladebeskrivelse rettes til: NemKonto Support, tlf Side 8

10 5 Beskrivelse af NKS betalingsflow Side 9

11 Betalingflowet illustrerer hvordan NemKonto-systemet modtager de ukomplette betalinger fra de offentlige myndigheder, påfører modtagernes NemKonto og sender betalingen videre til afvikling i den udbetalende myndigheds pengeinstitut Af betalingsflowet fremgår desuden de tilbagemeldinger som returneres til de afsendende systemer. Tilbagemeldinger gives enten i form af Kvitteringssvar eller Retursvar. Kvitteringssvar er tilbagemelding på at en samling af betalingsordrer er modtaget af NemKonto systemet. Kvitteringssvar gives kun elektronisk og som ebms header. Kvitteringssvaret er enten OK eller AFVIST. Yderligere tilbagemeldinger på betalingsordrer gives vha. Retursvar. Retursvar omfatter diverse fejlmeldinger, adviseringer, totaler og afstemninger (opsamling af data). Retursvar er opbygget iht. swift-standarden. Kun for Retursvar (flowpil 2): Fejl - modtagekontrol af betalinger, sendes desuden ebms header. Alle elektroniske kvitterings- eller retursvar sendes til afsendersystemet via en separat MQ-kø. Efterfølgende er listet de mulige Kvitterings- og Retursvar fra NKS, med en kort beskrivelse af disses indhold og form samt hvornår de sendes til afsendersystemet. Kvitteringssvar (flowpil 0), Fejl - XML dokument ulæseligt. NKS XML Brokerfunktionen validerer om XML-formatet er overholdt. Er dette ikke tilfældet stoppes behandlingen af meddelelsen og der sendes fejlmelding til afsendersystemet. Frekvens: Form: Løbende efter behandling af et XML-dokument XML meddelelse og som ebms header Kvitteringssvar (flowpil 1), Advis - Modtagelse af Bundt. Derefter foretages kontrol af betalingsordre på bundtniveau. Der foretages kontrol af DataleverandørID, Check af dobbeltforsendelse på bundtniveau og Check på sumtotaler. Resultat af indgangskontrollen vil være enten en afvisning eller accept af betalingsmeddelelsen/bundtet. Frekvens: Form: Løbende efter behandling af et bundt. XML meddelelse og som ebms header Side 10

12 Retursvar (flowpil 2). Fejl - modtagekontrol af betalinger. Derefter foretages yderligere validering af alle indkomne betalingsordrer iht. valideringsregler. Alle ikke afviste betalinger gemmes i databasen for videre behandling i NKS. Afviste betalinger meddeles på Retursvar 2, med angivelse af fejltype. Frekvens: Form: Løbende efter behandling af et bundt. XML meddelelse indeholdende: ebms header A. General Information B. Original Group reference Information and Status D. Original Transaction reference Information and status Retursvar (flowpil 5). Advis Svar på standsning af bundt/betaling. Retursvar 5 dannes i forbindelse med standsning af bundt eller betaling. Frekvens: Form: Løbende efter behandling af et bundt. XML meddelelse indeholdende: ebms header A. General Information B. Original Group reference Information and Status D. Original Transaction reference Information and status Retursvar (flowpil 7). Fejl - kompletter betalinger. Hvis det ikke er muligt at komplettere de modtagne ukomplette betalingsordrer med det aktuelle Nemkonto/Specifikke kontonummer meddeles disse på Retursvar 7. Frekvens: Form: XML-meddelelse løbende, papirlister dagligt XML meddelelse. Der sendes et svar pr. bundt pr. udbetalingsdato (der kan være flere udbetalingsdatoer i et bundt hvis No grouping er anvendt). Retursvaret indeholder følgende: A. General Information B. Original Group reference Information and Status D. Original Transaction reference Information and status E. Original Transaction Information Side 11

13 Retursvar (flowpil 8). Advis - Betalinger videresendt til PI. Alle betalingsordrer overføres til PI når tidsfrister for betalingsordren er nået (afhængig af udbetalingsdato og betalingsafviklende pengeinstitut). Retursvar 8 er adviseringsliste over betalinger overført til PI. Retursvar 8 sendes umiddelbart efetr at PI har godkendt modtagelsen af betalingsordren (når CTRL er modtaget fra PI). Frekvens: Form: XML-meddelelse løbende, papirlister dagligt XML meddelelse. Der sendes et svar pr. bundt pr. udbetalingsdato (der kan være flere udbetalingsdatoer i et bundt hvis No grouping er anvendt). Retursvaret indeholder følgende: A. General Information B. Original Group reference Information and Status C. Original Payment Information D. Original Transaction reference Information and status E. Original Transaction Information Retursvar (flowpil 9). Fejl - PI-fejl. NKS modtager og behandler meddelelser fra pengeinstitut om kontooverførsler/betalinger, som ikke kan gennemføres (BANSTA). NKS sender meddelelse om fejlbehæftede betalinger videre til afsendersystemet via Retursvar 9. Frekvens: Form: XML-meddelelse løbende, papirlister dagligt XML meddelelse. Der sendes et svar pr. bundt pr. udbetalingsdato (der kan være flere udbetalingsdatoer i et bundt hvis No grouping er anvendt) Retursvaret indeholder følgende: A. General Information B. Original Group reference Information and Status D. Original Transaction reference Information and status E. Original Transaction Information Side 12

14 6 Betalingsordre til NKS NKS systemet modtager betalingsordrer fra de offentlige myndigheder via udbetalingssystemerne/dataleverandørerne. Betalingsmeddelelser til NKS opbygges af: 1. ebms Header, som indeholder oplysninger om meddelelsen, dvs. hvilken type og version samt hvem der er afsender og modtager af meddelelsen. 2. Core Credit Transfer Initiation message, som indeholder selve betalingsmeddelelsen/ordren. 6.1 Opbygning af betalingsmeddelelse En betalingsmeddelelse/ordre (Core Credit Transfer Initiation message) opbygges af følgende tre hovedblokke/niveauer: A. Group Header (Bundtniveau): Group Header/Bundtniveau oplysningerne er obligatoriske og indeholder informationer, som relaterer sig til hele Betalingsmeddelelsen/Bundtet. Group Header indeholder elementer som: Group Identifikation/bundtreference, dato/tidspunkt for hvornår betalingsmeddelelsen er initieret og sumbeløb og -antal for indhold af betalingsordrer samt informationer om afsender (NKS aftalenummer og myndighed). Bundtreferencen dannes af afsendersystemet og vil sammen med information om myndighed og dataleverandør giver en entydig reference til en betalingsordre. Bundtniveauet betyder at der kan refereres til en samling af flere betalingsordrer, eksempelvis ved standsning af massebetalinger Side 13

15 B. Payment Information (Debiteringsniveau): Payment Information/debiteringsniveauet er obligatorisk og indeholder oplysninger, som relaterer sig til debiteringssiden af betalingsordrene. Debiteringsniveauet indeholder fælleoplysninger for et antal krediteringer f.eks. oplysninger om afsender registrerings- og kontonummer samt udbetalingsdatoen. Afsenderregistrerings- og kontonummeret er bestemmende for hvilket PI, som skal afvikle betalingen. Debitorniveauet styrer hvilke debiteringer der skal laves på afsenderens kontoudtog. Det er muligt at vælge om dette niveau skal forekomme en gang og indeholde fællesoplysninger for flere krediteringer (grouping true) eller for hver kreditering (grouping false), se desuden efterfølgende beskrivelse af Scenari er. C. Payment Transaction (Krediteringsniveau): Payment Transaction/Krediteringsniveauet er obligatorisk og gentagelig. Krediteringsniveauet indeholder oplysninger om de enkelte betalingsordrer samt beløbsmodtager for disse. Oplysningerne omfatter bla. beløb, kreditor kontooplysninger samt reference for transaktionen. Alle betalinger skal indeholde en entydig UPR (unik payment reference) dvs. en UPR som er genereret af de afsendende systemer Side 14

16 Opbygning af betalingsmeddelelse: Swift standarden indeholder mulighed for at opbygge betalingsmeddelelser på to forskellige måder: Scenario 1: Grouping (grouping true). I Scenario 1 er det muligt at angive et debiteringsniveau med et antal krediteringer under. Debiteringsniveauet indeholder fællesoplysninger for de enkelte krediteringer; f.eks. oplysninger om afsender registrerings- og kontonummer samt udbetalingsdatoen. Scenario 2: No Grouping (grouping false). I Scenario 2 er der intet debiteringsniveau med fælles oplysninger for flere krediteringer. Her skal debiteringsoplysninger gentages for hver enkelt kreditering. Angivelse af om hvilket Scenario som er valgt angives i feltet Grouping med indikator true for Scenario 1. Hvis et bundt med Grouping=true indeholder flere debitorer afvises hele bundtet Side 15

17 6.2 Afvigelser fra Swift Detaljeret specifikation af Betalingsmeddelelsen C2NKS findes i Snitfladebeskrivelse for komplette og ukomplette betalinger til NKS (afsnit 8.2, 8.3 og 8.4). NKS præciseringer ift. Swiftstandardens fremgår af kolonnen Mult i afsnit 8.2. Der er følgende afvigelser ift Swift-standarden: First Agent Disse informationer er ikke indeholdt i betalingsmeddelelsen DebitPurpose Nyt felt indeholdende Debiteringstekst, feltet skal udfyldes Incomplete Payment Indicator Nyt felt til angivelse af om ukomplet betaling, feltet skal udfyldes BenefitType Nyt felt til angivelse af ydelsesart korttekst Charge Bearer - må kun anvendes for udenlandsk komplet betaling 6.3 Særlige problemstillinger ifht. betalingsmeddelelsen Der er to områder, som man skal være særligt opmærksom på: Opbygning af betalingsmeddelelsen Opbygningen af en udenlandsk komplet betaling Opbygningen af betalingsmeddelelsen kan som beskrevet gøres på to måder via angivelse af feltet Grpg (Grouping). XML skemaet indeholder dog ikke logik til at sikre, at XML et er udfyldt præcist på én af de to måder. Det er således muligt at udfylde flere Payment info strukturer med flere Payment transaction strukturer altså angive flere krediteringer for flere debiteringsniveauer. Og når et bundt - som nævnt tidligere derfor afvises, hvis Grouping=true og der er flere debiteringsniveauer, så sker afvisningen på grundlag af en validering dybere nede i systemet. Mht. opbygningen af en udenlandsk komplet betaling, så har det ikke her været muligt at indbygge logik i XML skemaet til at sikre, at alle nødvendige oplysninger er udfyldt. F.eks. kræver NKS, at landekode er udfyldt, når der er tale om en udenlandsk komplet betaling. Men for en indenlandsk betaling er der ligesom i Swift ikke noget krav om udfyldelse af disse felter. Så hvis XML et er mangelfuldt udfyldt ifbm. en udenlandsk komplet betaling, så vil en eventuel afvisning ske på grundlag af en validering dybere nede i systemet. Der henvises til Snitfladebeskrivelse for komplette og ukomplette betalinger til NKS afsnit 8.4 samt afsnit punkt 3.33 for yderligere beskrivelse Side 16

18 7 Kvittering- og retursvar Retursvar som sendes elektronisk til afsendersystemet er alle opbygget iht. Swift - Payment Initiation Status message standard. Retursvaret (The Payment Initiation Status message) opbygges af følgende blokke: A. General Information: Denne blok er obligatorisk og indeholder oplysninger så som Identifikation af retursvartype, timestamp for generering af svar og afsenderid. B. Original Group Reference Information And Status: Denne blok er obligatorisk og indeholder informationer som relaterer sig til bundtniveauet. Desuden er der mulighed for at angive status for bundtet. C. Original Payment Information: Denne blok er valgfri og indeholder informationer som relaterer sig til Debitorniveauet, så som udbetalingsdato, afsenderkonto og Pi-aftale etc. Det er muligt at gentage denne blok. D. Original Transaction Reference Information And Status: Denne blok er ligeledes valgfri og mulig at gentage. Blokken indeholder referencer på krediteringsniveau samt mulighed for at sende information om status på de enkelte betalinger. E. Original Transaction Information: Denne blok er valgfri og anvendes til at sende yderligere information på krediteringsniveau, så som oplysninger om beløb, modtager konto etc Side 17

19 8 Bilag 8.1 NKS_Betaling_Skemaer.zip Beskrivelse af XML skema Betalingsordren til NKS Kvitteringssvar 0 Kvitteringssvar 1 Retursvar 2 Retursvar 5 Retursvar 7 Retursvar 8 Retursvar 9 NKS tilpasning af SWIFT betaling NKS tilpasning af SWIFT NKS tilpasning af ebms standard Indhold NKS_NKSPayment.xsd NKS_NKSReceipt0.xsd NKS_NKSReceipt1.xsd NKS_NKSResponse2.xsd NKS_NKSResponse5.xsd NKS_NKSResponse7.xsd NKS_NKSResponse8.xsd NKS_NKSResponse9.xsd SWIFT_NKSPayment.xsd SWIFT_A_GeneralInformation.xsd SWIFT_B_OriginalGroupReferenceInformation.xsd SWIFT_C_OriginalPaymentInformation.xsd SWIFT_D_OriginalTransactionReferenceInformationAndStatus.xsd SWIFT_E_OriginalTransactionInformation.xsd SWIFT_Package.xsd SWIFT_Common.xsd EBMS_Common.xsd Side 18

20 8.2 NKS_Betaling_Metadata.zip Beskrivelse af Metadata Betalingsordren til NKS Kvitteringssvar 0 Kvitteringssvar 1 Retursvar 2 Retursvar 5 Retursvar 7 Retursvar 8 Retursvar 9 NKS tilpasning af SWIFT betaling NKS tilpasning af SWIFT NKS tilpasning af ebms standard Indhold NKS_NKSPayment.xsd.meta.xml NKS_NKSReceipt0.xsd.meta.xml NKS_NKSReceipt1.xsd.meta.xml NKS_NKSResponse2.xsd.meta.xml NKS_NKSResponse5.xsd.meta.xml NKS_NKSResponse7.xsd.meta.xml NKS_NKSResponse8.xsd.meta.xml NKS_NKSResponse9.xsd.meta.xml SWIFT_NKSPayment.xsd.meta.xml SWIFT_A_GeneralInformation.xsd.meta.xml SWIFT_B_OriginalGroupReferenceInformation.xsd.meta.xml SWIFT_C_OriginalPaymentInformation.xsd.meta.xml SWIFT_D_OriginalTransactionReferenceInformationAndStatus.xsd.meta.xml SWIFT_E_OriginalTransactionInformation.xsd.meta.xml SWIFT_Package.xsd.meta.xml SWIFT_Common.xsd.meta.xml EBMS_Common.xsd.meta.xml 8.3 NKS_Betaling_XML_eksempler.zip Eksempler på XML skemaer for NKS betalingsordrer, Kvitteringer og retursvar findes på Nemkonto.dk Side 19

21 8.4 Grænsefladebeskrivelse for komplette og ukomplette betalinger til NKS Beskrivelse af Word dokument Gældende version af dokumentet Snitfladebeskrivelse for komplette og ukomplette betalinger til NKS, som findes på Side 20