Besvaret dato Spørgsmål Svar. den i fremtidig kontrol mod dobbeltforsendelse på bundtniveau.

Transkript

1 Spørgsmål- og svar, Betalinger Side 1 af (11) 1. Elementer i betalings-xml 1.1 referencer Referencer "Bundtreference (GrpId), skal være unik identifikation for et bundt indenfor myndighed.. " (se evt. snitfladebeskrivelse side 28), det antages at der her menes myndighed,system - korrekt? Bundtreferencen skal være entydig indenfor myndighed + dataleverandør. Det fremgår af side 49 (vers. 1.3). I kan få en dataleverandøridentifikation til hvert system, og dermed nøjes med at være unikke pr. system. Referencer "Betaling Unik payment Ref" (EndToEndId), sammen med myndighedsnr en global entydig reference". Hvordan bliver dette felt entydig i forhold til myndighed/system? Betalingsreferancen skal være entydig indenfor myndighed + dataleverandør. Det fremgår af side 49 (vers. 1.3). I kan få en dataleverandøridentifikation til hvert system, og dermed nøjes med at være unikke pr. system. Referencer Den unikke betalingsreference (identifikation på krediteringsniveau). Det fremgår, at vi selv kan disponere over 27 tegn, og at disse 27 tegn skal sættes sammen med et 8-cifret NKSbundtnummer. Sidtsnævnte synes ikke at fremgå i øvrigt i snitfladen. Hvad er det for et nummer? Er sammensætningen noget, der sker i NKS, så vi kun skal bekymre os om de 27 valgfrie tegn? Det ser også ud til, at vi i tilbagemeldinger fra NKS på transaktionsniveau kun får vores reference på de 27 tegn tilbage. Ved videresendelse til PI vil Nemkontosystemet danne en unik reference (som sammensættes af et 8 cifret NKS-nummer samt Betalings Unik Payment Ref på 27 cifre). Dette er for at sikre at der dannes en reference som også er unik selv om to dataleverandører leverer betalinger med samme Betalings Unik Payment Ref til Nemkonto-systemet. I kan disponere frit over de 27 tegn. Referencer april Punkt Betaling Unik Payment Ref (UPR) Jeg går ud fra, at tilvalg af dataleverandøridentifikation gør, at feltet kun behøver at være unik pr. system - korrekt? Unikheden er indenfor myndighed + dataleverandør (og dette kan være flere systemer). Referencer april Genforsendelse af bundter som er afvist: Bundtreferencen gemmes først i NKS efter Hvornår gemmes en bundtreference, dvs. hvornår indgår godkendelse/delvis godkendelse af et bundt. Dette vil den i fremtidig kontrol mod dobbeltforsendelse på bundtniveau. ske (hvis bundtet ikke afvises) i Modtage betalinger funktionen. Efter den er godkendt i 'forbrænderfunktion' eller efter den er godkendt i 'modtag betaling funktion' eller? Referencer april Genforsendelse af bundter som er afvist: Hvornår gemmes en UPR, dvs. hvornår indgår den i fremtidig kontrol mod at den ikke er modtaget tidligere. Efter den er godkendt i 'modtag betaling funktion' eller? UPR gemmes først i NKS efter godkendelse/delvis godkendelse af betalingen. Dette vil ske (hvis betalingen ikke afvises) i Modtage betalinger funktionen. Referencer april XML Niveau A (bundtniveau), hvad skal indhold være:hvordan skal Bundtreference opbygges? Der er tilsyneladende ingen krav! Bundtreferencen skal være entydig indenfor myndighed + dataleverandør, eller er der ingen krav. I kan få en dataleverandøridentifikation til hvert system, og dermed nøjes med at være unikke pr. system. Referencer april XML Niveau C (krediteringsniveau), hvad skal indhold være:ydelsesart korttekst Skal denne benyttes og i så fald: Hvilke værdier kan disse evt. have. Benyttes til komplementering vedr. specifik konto. Ydelsesart kortnavn anvendes på betalingerne til at påsætte evt. specifik konto hvis en sådan findes. Mulige valide ydelsesarter vil afhænge af den afsendende organisation Referencer april Kommer myndighedens bundtreference med Ved videresendelse til PI vil Nemkontosystemet danne betalingerne til pengeinstituttet, således at alle betalinger en unik reference for betalingsbundtet, som ikke er i et bundt evt. kunne fremstå som én postering på kontoudtoget, eller må myndighederne leve med, at der her kommer en postering for hver betalinger? relateret til den oprindelige. Dette skyldes at et betalingsbundt kan blive opdelt i flere EDIFACTmeddelelser. Der er en begrænsning i EDIFACTformatet som betyder at PI kun kan modtage 9999 betalinger i samme debitering, hvilket vil medføre en postering på kontoudtoget. Hvis myndigheden ønsker at identificere bundtet i PI skal bundtreferancen anføres i debiteringsteksten.

2 Spørgsmål- og svar, Betalinger Side 2 af (11) Referencer april Hvordan skal feltet MessageID i ebms-headeren opbygges? Feltet kan opbygges frit, dog med en maksimal længde på 256 karakterer. Feltet benyttes som reference (RefToMessageId) i de retursvar, der gives i forbindelse med modtagelse af en betaling (flowpil 0, 1 og 2). Bemærk at MessageID er identifikationen af den ebms (svarende til en kuvert), som betalingsmeddelelsen ankommer med. Selve identifikationen af betalingsmeddelelsen er GroupId (bundtreferencen). I modsætning til GroupId er der ingen kontrol af MessageId, og MessageId gemmes ikke til senere reference. Evt. kan man benytte samme værdi som MessageId og GroupId, forudsat den opfylder kravene til GroupId. 1.2 udbetalingsenheder (LOS) LOS Hvad skal der stå i elementet GrpHdr/InitgPty/OrgId/PrtryId/Id (version 1.1 af snitfladebeskrivelsen) Her skal stå angivelse af myndighedens LOS-enhed. Dette er en identifikation, som myndigheden udstyres af af KMD ved tilslutning. LOS-enheden kan identificeres med to forskellige koder - enten admid eller admnavn. Værdierne fremgår af myndigheds aftale med NemKonto. Hvilken der anvendes vælges i elementet Issr. LOS Hvad skal der stå i elementet GrpHdr/InitgPty/OrgId/PrtryId/Issr (version 1.1 af snitfladebeskrivelsen) LOS april I tilslutningsaftalen står der, at myndighedens bogføringskredse skal oprettes som administrative enheder i LOS. Den administrative enhed skal også fremgå ved betalingsafvikling (dvs. af betalingsmeddelelsen: orgid). Hvad er det helt præcist af numrene i bilag 4 (massetilslutningsaftale), der skal oprettes i LOS (for NavisionStat og øvrige udbetalende systemer af kunden selv) og fremgå af betalingsmeddelelsen? Er typeangivelsen på Id, altså hvilken type kode, der identificerer LOS-enheden. Kan være 'AdmId' eller 'AdmNavn'. Først skal det besluttes om LOS-enheden skal identificeres med AdmId eller AdmNavn. Når dette er besluttet er identifikationen enten - Hvis AdmId: Tallet i sidste kolonne i bilag 4 - Hvis AdmNavn: OrgId (4 cifre, kolonne 1) + OrgType (2 cifre, kolonne 4) + Kaldenavn Kort (op til 10 cifre, kolonne 2) LOS april Hvis SLS og NavisionStat ligger i samme bogføringskreds, hvorledes sondres så mellem LOSidentifikationer for SLS og LOS-identifikationer for NavisionStat (sidstnævnte skal myndigheden selv indtaste)? LOS april Tilsvarende hvis flere udbetalende systemer håndteres under samme bogføringskreds, kan disse systemer så godt dele administrativ enhed i LOS? Rettighedsmæssigt sondres mellem disse betalinger ved hjælp af ydelsesarten. Det vil sige, at en medarbejder lønmedarbejder ikke får ret til at se betalinger markeret med som Leverandørudbetalinger - og vice versa. Ja, dette sker på tilsvarende vis ved hjælp af ydelsesarten. LOS april Er administrativ enhed lig med udbetalende enhed (et begreb, der benyttes i snitfladevejledningen til betalingsmeddelelsen)? Ja, administrative enhed i LOS vil svare til den Udbetalende enhed. LOS april Hvad er AdmId og AdmNavn for OrgID og OrgType? Identifikation af den afsendende offentlige myndighed og evt. underliggende enhed. ID?en fastlægges ved myndighedens tilslutning til NKS. 1.3 grouping Grouping I eksempel 2 står der, at forsendelsen består af en indenlandsk og en udenlandsk, hvorfor der ikke kan være grouping. Men der står faktisk true i groupheaderen, og der er to indenlandske transaktioner, der deler samme debitor, uden over den udelandske, der har sin egen debitor. Hvordan hænger dette sammen? Der er fejl i eksemplet der burde stå false i grouping vil blive rettet i næste version.

3 Spørgsmål- og svar, Betalinger Side 3 af (11) Grouping I group-headeren skal der være en angivelse af, om betalingstransaktionerne er "groupede" eller ej. I beslrivelsen står der, at værdierne kan være '1' (true) eller '0' (false). I eksemplerne er værdien angivet til "true". Betyder det, at man fx frit kan vælge mellem at skrive "true" eller "1". 1.4 ekspeditionsdato Ekspeditionsd ato april Punkt Ekspeditionsdato Afvises betalingen hvis ekspeditionsdato ikke er >= d.d. eller stilles den i kø.? (Spørgsmålet er specielt relevant ved en evt. genleveringssituationer efter fejl). Dette elements type er boolean, og her kan man frit vælge mellem de to måder at anføre værdien. Hvis ekspeditionsdatoen ikke er >= d.d.afvises betalingen. Ekspeditionsd ato april Er det rigtigt opfattet, at et helt bundt betalinger kan afvises, hvis NKS kan se, at ingen af betalingerne kan nå at blive ekspederet til pengeinstituttet inden ekspeditionsdatoen for sent afleveret, og at der i dette tilfælde ikke kommer afvisninger på enkeltbetalingsniveau. Dvs. at myndigheden selv skal sørge for hurtigst muligt, at omlevere datasættet med en anden bundtreference og en håndterbar ekspeditionsdato? Bundt/Betalinger afvises hvis udbetalingsdatoen ikke er valid eller < dd. Hvis de er modtaget for sent ift. aftale med PI, vil de blive markeret med for sent modtaget i NKS, men bliver sendt videre til PI, så hurtigt som muligt. Bundtreferencen gemmes først i NKS efter godkendelse/delvis godkendelse af et bundt. Så hvis bundtet er afvist eks. pga ikke valid udbetalingsdato - kan bundtreferencen genanvendes af afsendende system (ved grouping=true). 1.5 modtageridentifikation Id Hvad er udfaldsrummet for PmtInf/PmtTx/Cdtr/OrgId/PrtryId/Issr - XSD skema og snitfladebeskrivelse er forskellig, hvilken af dem er rigtig, hvilke koder skal bruges CVR og P eller CVR og PNR. (version 1.1 af snitfladebeskrivelsen) Ja, det er en fejl! Det skal være 'PNR', skemaerne rettes. Id april Er det muligt at anvende komplette betalinger uden at angive SE/CVR/P/CPR nr.? Vi har udbetalinger til visse identer hvor vi ikke har disse oplysninger og som ikke er omfattet af NemKonto. Men vi kunne jo alligevel godt anvende NemKonto til betalingen. Id april Er det muligt at fremsende betalinger med fiktive CPRnr. (eller CVR/SE/P)? Ja, der er ikke krav om angivelse af SE/CVR/P/CPR nr ved komplette betalinger. CPR, CVR, SE og P-nummer valideres i forhold til de respektive registre, derfor vil betalinger med fiktiv modtageridentifikation fejle. Bemærk dog, at for komplette betalinger er det ikke nødvendigt at identificere modtager med CPR, CVR, SE eller P, idet kontooplysninger er tilstrækkelige. Id juni Hvordan valideres et CPR-nr. i en komplet betaling? Et CPR-nr. i en komplet betaling valideres på samme måde som et CPR-nr. i en ukomplet betaling. Det vil sige, at betalingen afvises, hvis CPR-nr. ikke findes i NemKontos CPR-register. Bemærk at dette register også indeholder CPR-nr. for udrejste (selvom de ikke omfattet af loven) Id juni Hvad sker i kompletteringen hvis vi sender en sekundær nøgle (P-nummer, SE-nummer) som ikke eksisterer i NemKontos Virksomhedsbase? Får vi fejl retur eller tager Nemkonto CVR-nummeret som P-nummeret tilhører / SE-nummeret er relateret til? Det vil give et Retursvar7 med StatusReason: RJCT Additionel information: <nummer> findes ikke. Hvis der i en betaling kun er angivet en sekundær nøgle, og denne kendes af NKS, forsøger NKS altid at finde en konto efter følgende regelsæt: 1. Find specifik konto til sekundær nøgle 2. Find NemKonto til sekundær nøgle 3. Find specifik konto for tilhørende CVR-nummer 4. Find NemKonto for tilhørende CVR-nummer Hvis der ikke findes en konto i NKS, vil betalingen blive kompletteret som check eller sendt retur, afhængig af myndighedens valg af checkløsning. 1.6 specifikation af beløb

4 Spørgsmål- og svar, Betalinger Side 4 af (11) Beløb Hvordan skal elementerne i Amt (amount) bruges? Som jeg forstår det så skal elementet PmtInf/PmtTx/Amt/InstdAmt, og attributten PmtInf/PmtTx/Amt/InstdAmt@Ccy anvendes til indenlandske betalinger hvor valutaen er DKK. Ja det er korrekt. Bemærk, at 100 kr. skal angives som , idet det indeholder 3 decimaler og man ikke bruger decimalseparator F.eks udbetaling af Kr 100 til dansk konto. <PmtInf> <PmtTx> <Amt> <InstdAmt Ccy="DKK">100000</InstdAmt> </Amt> </PmtTx> </PmtInf> Beløb Ved udenlandske betalinger bruges de på denne måde. F.eks ved udbetaling af 100 DKK til en USD konto: <PmtInf> <PmtTx> <Amt> <EqvtAmt> <Amt Ccy="DKK">100000</Amt> <CcyOfTrf>USD</CcyOfTrf> </EqvtAmt> </Amt> </PmtTx> </PmtInf> Ja, der angives kun valutaen for hvordan udbetalingen ønskes, altså f.eks. <CcyOfTrf>USD</CcyOfTrf> og omregningen af DKK til den udenlandske valuta sker i pengeinstituttet. Er det korrekt forstået? Beløb Kan man anvende EUR som valuta kode som afsender valuta? Valuta koden er er angivet som fixed= "DKK" i skemaet, men med DKK/EUR i snitfalde beskrivelsen. Nej, man skal indtil videre bruge 'DKK' (EUR ville kun være relevant, hvis myndigheden førte sin konto i Euro ) Beløb april I dag gælder det, at valutakoden skal være = blank, hvis der fremsendes indenrigsbetaling i danske kroner til Jyske Bank via JNE. Er valutakode = DKK et krav for disse betalinger via NKS? Ja, valutakoden skal være DKK. Koden anføres som attribut til XML-elementet InstdAmt. Beløb april I dag gælder det, at valutakoden skal sættes = DKK, hvis der fremsendes udenrigsbetaling i danske kroner til Jyske Bank via JNE. Vi antager, at dette også er gældende for betalinger via NKS! 1.7 PI aftalenummer PI-aft. nr PI-aftalenummer Er det et nyt nummer, vi vil få udstedt af Jyske Bank. Så vidt jeg kan se, indgår et sådant aftalenummer ikke i den nuværende snitflade, vi har til SKB. Ja NKS sender blot PI-aftalenummer videre til betalingsafviklende PI. Det er myndighedens PI der skal oplyse det aftalenr., der skal anvendes. PI-aft. nr Vi går ud fra at PI-aftale nummeret og/eller afsenders reg.nr. + kontonummer samt ekspeditionsdato vil blive tilknyttet den enkelte postering, så bogholderiet i det mindste ved, hvilket udbetalende system og hvilken udbetalingskørsel heri posteringen kan henføres til? PI-aftalenummer, afsenderkonto samt ekspeditionsdato sendes til PI - om de på kontoudtog fra PI vil blive tilknyttet de enkelte posteringer, kan ikke svare på. 1.8 ydelsesarter Ydelsesart Ydelsesartkortnavn Er det noget vi selv kan bestemme, eller er det de samme kortnavne vi bruger i tilvejebringelsesfasen? Ydelsesart skal altid påføres betalinger, da de anvendes af Nemkonto-systemet til at påsætte en evt. specifik konto hvis en sådan findes. Mulige valide ydelsesarter vil afhænge af den afsendende organisation, og kan oprettes via Ydelsesart kortnavn anvendes ikke i tilvejebringelsesfasen.

5 Spørgsmål- og svar, Betalinger Side 5 af (11) Ydelsesart Hvorfor anbefales det, at feltet ydelsesart så vidt muligt skal udfyldes med en kode for ydelsesarten for alle betalinger? Skal det ikke kun være i de tilfælde, hvor betalingen skal til en ydelsesspecifik konto? Der skal så vidt muligt ydelsesart på alle betalinger, da det så er muligt for Nemkontosystemet at undersøge om der er registreret en specifik konto for den pågældende borger/virksomhed (for pågældende ydelsesart/myndighed). Det er ikke de afsendende systemer, som selv skal registrere om der findes en specifik konto for den pågældende ydelsesart for den pågældende borger/virksomhed. Ydelsesart april Ydelsesart korttekst. Er det korrekt opfattet, at hvis vi ikke skriver noget i feltet, anvises betalingen altid til NemKontoen, uanset om modtager gerne ville have haft pengene på en specifik og der i øvrigt er oprettet en sådan? Omvendt hvis vi følger anbefalingen og altid skriver et ydelsesnavn i feltet, vil betalingen automatisk gå til den specifikke konto, hvis den altså fortsat er åben? Det er korrekt. NKS vil kun kunne påføre en specifik konto til en specifik ydelsesart+myndighed - og angives ikke specifik ydelseart i betalingsordren vil Nemkonto altid blive valgt. Ydelsesart april Hvordan skal feltet Purpose/Propietary (ydelsesart) bruges? Selv om feltet er frivilligt, er det vigtigt, at det udbetalende system så vidt muligt udfylder feltet med en kode for ydelsesarten. Der kan enten bruges en af de generelle ydelsesarter (som vil fremgå her på nemkonto.dk fra 15. april), eller en, som myndigheden har oprettet. Kun i de tilfælde, hvor det udbetalende system har mange typer udbetalinger, som der ikke kan skelnes mellem, kan feltet efterlades blankt. Ydelsesart maj Hvilke regler er der for fastlæggelse af korttekster for ydelsesarter? 1.9 diverse Local Instrument Recordlængde r Adviseringstek st Debiteringstes kt Hvilket udfalds rum er der for elementet: PmtInf/CdtTrfTpId/LclInstrm - XSD skema og snitfladebeskrivelse er forskellig, hvilken af dem er rigtig (version 1.1 af snitfladebeskrivelsen) Er det korrekt opfattet, at betalingsrecords til NKS kan have variabel længde, jf. at et bundt kan indeholde både ukomplette og komplette betalinger april Er maksimum for adviseringstekst (41 x 35 tegn) helt fast? Er der nogen mulighed for at få længere adviseringstekst? Korttekst må ikke være længere end 6 tegn. De første tre tegn må ikke være 'NKS' Feltet benyttes kun for indbetalingskort og udenlandske komplette betalinger. Indbetalingskort markeres med 'IBK' og udenlandsk komplette betalinger markeres med 'UBB'. Det er korrekt at et bundt både kan omfatte komplette og ukomplette betalinger (og antal oplysninger for de enkelte betalinger derfor er forskellige i omgang) men grænsefladen er XML og der er derfor ikke tale om fast/variabel længde. Maksimum er fast. Det er fastlagt af den standard, der bruges til at kommunikere med bogføringscentralerne (EDIFACT) april Hvad skal feltet debiteringstekst benyttes til? Udfyldes med den tekst, som skal fremgå af debitors bankudtog for den pågældende debitering. Indholdet er valgfrit. IBAN april Hvorfor bruges IBAN ikke for indenrigsbetalinger? IBAN vil blive taget i brug, når det er fuldt understøttet af bankerne. Separatorværd april Hvad er separatorværdien i punkt 3.84 vedr. kortartkoder Separatorværdien er ' ' og bruges til at adskille i og identifikationslinje? kortartkoden og betalingsid. Tegnsæt april XML encoding. Hvis kommunikation er fra mainframe til mainframe er det så stadigvæk UFT-8 eller kan det bare være IBM-277 (EBCDIC)? Tegnsættet skal være UTF-8 Blanke felter maj En del elementer er af typen Max35Text, eller Max70Text. Den type er defineret til at indholde fra 1 til henholdvis 35 og 70 tegn. Det er et problem når denne type anvende til et element der iflg snitfladen må optræde 0 til 1 gang. For konsekvensen er at hvis element er tomt så skal det fjernes helt, da type ellers vil få det til at fejle i valideringen. Kan det lade sig gøre at aflevere feltet tomt alligevel? Definitionen af disse typer stammer fra SWIFTstandarden. Disse fastslår, at typen skal have en længde på mellem 1 og 35/70. Hvis dette ikke overholdes, vil XML'en ikke validere. Det betyder, at man ikke kan aflevere et tomt felt. Blanke felter maj Kan jeg sende et tom element som <Nm /> eller skal det sendes som <Nm></Nm>? Begge dele er mulige.

6 Spørgsmål- og svar, Betalinger Side 6 af (11) Header maj I eksemplerne vises et "NKSPaymentlag" uden om det hele, altså uden om Headeren. Dette lag vises ikke i snitfladebeskrivelsen. Betyder det, at dette ikke skal/behøver være med?? - <NKSPayment xmlns=" 2005/02/23/" xmlns:ebms=" ml/schemas/2005/02/23/" xmlns:swift=" schemas/2005/02/23/" xmlns:xsi=" xsi:schemalocation=" xml/schemas/2005/02/23/..\nks_nkspayment.xsd">... Det skal være med i OIOXML'en (rettet i snitfladebeskrivelse ver. 1.4). Det angiver hvilket skema som er anvendt - der var dog en enkelt fejl i xsi:schemalocation stien -..\ skal slettes. Vil blive rettet i eksemplerne. Timestamp maj Timestamp ISO standard 8601 I eksemplerne er der sat et Z på i halen på timestamp'et, som ikke er med i beskrivelsen. Hvad betyder det??? <ebms:timestamp> T12:00:00Z</ebms:Timestamp> Z anvendes til at angiver tidszoner og visse XMLværktøjer sætter "koden" automatisk - da vi i Nemkontosystemet kun behandler danske betalinger - vil NKS ikke tage højde for dette, men kun læse datoen (og Z er valgfrit - NKS vil ignorere dette). Ændringer juni Snitfladebeskrivelse. Ændring til struktur/valideringsregler vil efter 1/ og frem til drift, blive varslet med en måned. Hvordan sker denne varsling. Via myndigheden? Der vil ske varsling til de myndigheder som har indgået aftale om anvendelse af snitfladen (via tilslutningsaftalen) Adviseringstek st juni Vedr. Betalingssnitfladen: 3.72 Remittance information unstructured: Spørgsmål: Vi går ud fra, at vi her kan angive en adviseringstekst vedrørende den enkelte betaling, der når helt ud til det modtagende pengeinstittut og fx kommer ud på et kontoudtog fra dette til kontoindehaver, uden at vi skal betale ekstra herfor. Det er korrekt at der i feltet kan angives adviseringstekst for betalingen, der kan indeholde oplysninger vedrørende den enkelte betaling. Oplysningen sendes videre fra NKS til Pengeinstituttet - som formodentligt vil sætte informationen på kontoudtoget (men denne sidste del er op til de enkelte banker og er ikke indeholdt i NKS s aftaler). Feltet er på 140 pos. i OIOXML grænsefladen, men kan gentages - således at den samlede adviseringstekst kan være op til max. 41 linier á 35 pos. (som er det format NKS kan sende videre via. Edifact grænsefladen til PI.) - der mappes 4 linier i hvert <RmtInf><Ustrd> element, undtagen sidste element (her kun 1 linie). Er der behov for flere elementer skal formen være : <RmtInf><Ustrd>xxxxx max.140 tegn</ustrd></rmtinf><rmtinf><ustrd>xxxxx max.140 tegn</ustrd></rmtinf>...

7 Spørgsmål- og svar, Betalinger Side 7 af (11) Debitors kontonr juni Jeg er stødt på problemer med DebitorAccount (BBAN). KMDs modtageprogram forventer, at kontonummeret er helt udfyldt, dvs. med foranstillet nuller i kontonummer. BBAN (registreringsnummer og kontonummer) skal altid afleveres som 14 cifre for at undgå misforståelser. Snitfladebeskrivelsen vil i næste version blive gjort klar på dette punkt. I snitfladenbeskrivelsen (v. 1.4) for komplette og ukomplette betalinger fremgår: Repræsentation : Numerisk, max 10 cifre, Værdisæt : Der står ikke noget om, at kontonummeret skal være helt udfyldt. 2. Retursvar og kvitteringer XML i retursvar april Punkt Indhold af Retursvar (9) Hvad er feltlængde for feltet 'StatusReason'/kode for fejl? Status Reason feltet er 4 og vil indeholde: # på fejlmelding for betaling (vil oftest være 1 - ved flere fejlmeldinger på samme betaling >1). Additionel information feltet vil indeholde: Fejltekst fra BFC (fra BANSTA eller CONTRL). Vil indeholde de første 105 tegn for fejlmeldingen fra BFC (som er på 5*70). XML i retursvar XML i retursvar april Kan man se det kontonummer, som NemKonto har påført betalingen med, i retursvarene? april Hvad er de mulige værdier for fejltekster i returmeldingen fra PI? Ja, det anvendte kontonummer fremgår af retursvar 8. Dette afhænger pengeinstituttet. NKS refererer den oprindelige fejltekst uden yderligere behandling. Flowdiagram april Får afvisninger, hvor der ikke er en aktiveret NemKonto, men kun en ikke-aktiveret NemKonto, samme Hvis der ikke i NKS kan påføres en Nemkonto på en ukomplet betaling vil der blive førsøgt udstedt fejlmeddelelse, som hvis der hverken er en aktiveret eller check/betalingen eller det vil blive fejlmeldt (afhængigt af en ikke-aktiveret konto? myndighedens valg) - og der er ingen forskel på om der findes en ikke aktiveret Nemkonto eller ej. Flowdiagram april Til tegningen side 9: Yderst til højre på tegningen går der en pil fra PI til 'tilbagemelding udenom NKS'. Hvad dækker denne pil over, da det må forventes at PI levere fejlbetalinger retur via BANSTA? Er det en pil der dækker over noget automatisk (og dermed er vigtgt for myndighedens EDB-system) eller blot noget manuelt? Der vil kunne være fejlmeldinger fra PI som ikke sendes til NKS, eksempelvis fordi de først opdages flere dage efter Øvrige tilbagemeldinger fra PI (eks. ved udenlandske betalinger). Svartider Hvad er svartiden på kvitteringssvar 0, 1 og 2? I princippet bør de genereres løbende efter behandling af et bundt, men i praksis kan det jo nok variere noget, hvornår de bliver sendt. Kan man give en indikativ angivelse af, hvor længe man kan komme til at vente? Et afledt spørgsmål er, hvilken tidsmæssig sammenhæng der er mellem svar 1 og 2. Kommer de altid samtidig, eller er de tidsmæssigt forskudt? Tidsmæssigt forventer vi at behandling af betalingsordrer behandles løbende og at kvitteringssvarene derfor vil blive sendt umiddelbart efter behandlingen (men at sætte præcis tidangivelse på kan vi desværre ikke pt.). Da kvitteringssvar 0, 1 og 2 genereres fra forskellige programmer, vil de ikke blive sendt samtidigt. Men betalingsordren bliver "færdigbehandlet" og svar 2 vil derfor komme umiddelbart efter 1 - men igen en præcis tidsangivelse kan ikke gives pt.

8 Spørgsmål- og svar, Betalinger Side 8 af (11) Svartider april Kan der oplyses om tidspunkt for hvor hvornår de enkelte funktioner udføres og dermed hvornår vi modtager de enkelte retursvar ( som XML). Har betydning for hvordan kvitteringer/retursvar kan/skal indarbejdes i driftflow for det modtagende system: 0 - kvittering 1 - kvittering 2 - Retursvar 7 - Retursvar 8 - Retursvar 9 - Retursvar Kvittering- / retursvar 0,1,2 og kommer 'umiddelbart efter modtagelse' af et bundt. Retursvar 7 (e) sendes umiddelbart efter komplettering og lige før betalingsordren sendes til PI. Retursvar 8 (e) sendes umiddelbart efter at NKS har modtage accept fra PI. Retursvar 9 (e) sendes umiddelbart efter at der modtages evt. fejlmeldinger på de enkelte betalinger fra PI. Med (e) menes elektroniske tilbagemeldinger. Retursvar 7,8,og 9 på papir sendes til myndigheden dagligt. Totaler april Punkt Totaler Kommer disse på myndighedsniveau eller på myndigheds/systemniveau? Retursvar 8 sendes til Overordnede myndighed, og der sendes et retursvar pr. bundt (pr. udbetalingsdator). Totalerne vil omfatte totaler for bundtet. Valg Papirkvitteringer og retursvar ifm. betalingsflowet: Kan man vælge, hvilke af disse papirkvitteringer man er interesseret i? Altså f.eks. sige at man gerne vil have nr. 9 på papir (fejl fra banken), men at man ikke er interesseret i nr. 8, overførselslister, på papir. Tilsvarende for de elektroniske XML-kvitteringer? Valg april Vi går ud fra, at valget om hvorvidt retursvar skal komme som XML-meddelelse eller papir kan tages pr. myndighed/system - korrekt? Kvitteringssvar0, Kvitteringssvar1 og Retursvar2 sendes til alle. For Retursvar7, Retursvar8, Retursvar9 kan man for hver enkelt retursvar vælge: 1. Kun XML-meddelelse 2. Kun papir 3. Begge 4. Ingen Nej. Valget tages på myndighedsniveau, ikke systemniveau, hvilket naturligvis kan være uhensigtsmæssigt. For myndigheder, der er omfattet af massetilslutning vil der ikke være mulighed for at fravælge XML, da SLS og Navision skal bruge disse retursvar. Det valg myndigheden skal træffe vil derfor alene være om man ønsker papir eller ej. 3. Checks og enkeltbetalinger Checks Jeg antager, at valget mellem om der skal udskrives check eller sendes en fejlmeddelelse (retursvar 7) er et valg der kan tages pr. myndighed/system og ikke generelt pr. myndighed (se evt. snitfladebeskrivelse side 10, vers. 1.3)? Checks Det valg myndigeheden foretager vedrørende check, kan det bevirke at retursvar 7 aldrig sendes eller vil den altid blive sendet som kvittering? Det er pr. myndighed. Økonomistyrelsen er opmærksom på, at dette kan være uhensigtsmæssigt, men forholdet vil ikke kunne rettes inden idriftsættelse. Nej, valget af check har ikke indflydelse på om retursvar 7 kommer eller ej. Retursvar 7 kommer dog ikke altid - kun hvis der konstateres en fejl. At betalingen er blevet til en check tæller som en fejl, så uanset om man har valgt check eller ej så kommer der en 7'er, hvis systemet ikke kunne finde en NemKonto. Enkeltbetaling er Enkeltbetaling er Vi har forstået, at samme snitflade kan benyttes til enkeltog massebetalinger. Hvordan sondrer NKS på, om vores kø. Der er dog ikke pt. forskel på hvordan betalingerne Enkelt- og massebetalinger skal leveres på hver sin MQ- forsendelse er det ene eller det andet. Skal der aftales fra de to kø-typer behandles i NKS. en særlig ident, hvis vi også vil sende enkeltudbetalinger? april Sker kontrol af enkeltbetalinger på myndighed/systemniveau eller på myndigheds-niveau? (spørgsmål opstår bl.a. fordi der i snitfladebeskrivelsen afsnit 9.5 står "check for at der max modtages 20 enkeltbetalinger fra samme (overordnede) myndighed"). Det er på myndighedsniveau. Med de nuværende aftaler for enkeltbetalinger med bankerne er disse ikke attraktive at benytte, da der ikke bedre leverancefrister for disse end for øvrige leverancer. Alle betalinger kan derfor lige så godt sendes som massebetalinger.

9 Spørgsmål- og svar, Betalinger Side 9 af (11) Enkeltbetaling er april Er Massebetaling = "Grouping" og enkeltbetalinger = "No Grouping"? Nej, der er ingen sammenhæng mellem Grouping og enkelt/massebetalinger. Skelnen mellem enkelt og massebetalinger sker ved MQ-køer, dvs. en kø for enkelt og en for masse. Grouping vedrører om flere krediteringer skal samles til en debitering (altså et enkelt træk på afsenders konto). Enkeltbetaling er april Kan håndteringen af, om det er et betalingsbundt contra de såkaldt enkeltudbetalinger anskueliggøres. Vi har forstået, at snitfladen er helt fælles, men at Det er korrekt at Enkelt- og massebetalinger skal leveres på hver sin MQ-kø. Betalingsmeddelelserne er ens i opbygning og der er pt. ingen forskel på hvordan enkeltbetalingerne håndteres i separat MQ-kø? Er det på betalingerne fra de to kø-typer behandles i NKS. Der er denne vis, at NKS kan se, om myndigheden sender mere end 20 enkeltudbetalinger om dagen? mulighed for at nogle BFCér fremtidigt vil differentiere på tidsfristerne for de to betalingstyper, men pt. er de ens og der er ingen grund til at anvende køen for enkeltbetalinger. Enkeltbetaling er april Er de 'max. 20 betalinger pr. dag', det eneste kriterie for valget mellem massebetaling og enkeltbetaling, eller er der økonomiske aspekter for myndigheden? Der er ingen økonomiske aspekter. Formålet med enkeltbetalinger er at tilbyde, at små mængder betalinger kunne sendes hurtigere igennem NemKonto/banken. Imidlertid har bankerne ikke kunne tilbyde bedre tidsfrister, og derfor leverancefristen den samme uanset antal. Derfor er der ingen grund til at benytte enkeltbetalingsfunktionaliteten. 4. MQ og datakommunikation Datakommuni kation Datakommuni kation Datakommuni kation april Punkt 10 i snitfladebeskrivelsen. 'Proxy-userid skal matche den entydige TCP/IP-adresse i netværket'. Vi går ud fra, at dette ikke betyder at protokollen skal være TCP/IP - korrekt? (vi antager at dermed proxyuserid menes MCA-userid) april Da både vi og KMD er tilknyttet det fælles MPLSnetværk (MPLS - Multi Protokol Label Switching - netværk i Danmark mellem mainframes), vil vi gerne bruge SNA-APPN på MPLS til MQ-kommunikationen. Det er nemt og sikkert og derved kan SSL-kryptering undgås, da det er et beskyttet netværk? april Myndigheden kan benytte en allerede forekommende VPN-forbindelse til KMD. Skal den opgraderes, så den benytter Advanced Encryption Standard (AES)? Protokollen skal være TCP/IP SNA kan ikke benyttes Ikke nødvendigvis, men muligheden foreligger for også at benytte AES. Datakommuni kation april Hvor lang til regner KMD med, at det tager at overføre et Tiden afhænger af dataleverandørens forbindelse til betalingsbundt på fx betalinger, jf. at en betaling KMD. Det er ikke KMDs vurdering, at netværkstiden ser ud til at indeholde ca. 4 gang så mange bytes som betalingen til Jyske Bank i dag, som det kan tage op til bliver nævneværdig i forhold til dataleverandører som CSC, hvor der i dag er stor linjekapacitet. 1,5 time at overføre? MQ I en tidligere udgave af snitfladebeskrivelsen sondrede man mellem bundter/betalingsmeddelelser og "forsendelser". Vi går ud fra, at betalingsmeddelese og bundt er det samme? Forsendelser var åbenbart på et teknisk niveau, der skulle helst være under betalinger ad gangen. Forsendelsesniveauet omtales ikke længere i snitfladebeskrivelsen. Er det noget kommunikationsværktøjet (MQ) i sig selv styrer eller kan sættes op til at styre? Det er korrekt at begrebet forsendelse er udgået i nuværende udgave af snitfladebeskrivelsen det var et teknisk niveau, som viste sig ikke at være nødvendig.