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

Størrelse: px
Starte visningen fra side:

Download "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 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="http://rep.oio.dk/oes.dk/nemkonto/xml/schemas/ 2005/02/23/" xmlns:ebms="http://rep.oio.dk/oes.dk/nemkonto.ebms/x ml/schemas/2005/02/23/" xmlns:swift="http://rep.oio.dk/oes.dk/nemkonto.swift/xml/ schemas/2005/02/23/" xmlns:xsi="http://www.w3.org/2001/xmlschemainstance" xsi:schemalocation="http://rep.oio.dk/oes.dk/nemkonto/ 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.

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

NemKonto. XML skemaer for. ukomplette og komplette betalinger. til NKS NemKonto KMD Selma Lagerlöfs Vej 300 9100 Aalborg www.nemkonto.dk NemKonto XML skemaer for ukomplette og komplette betalinger til NKS Version 2.0 19-05-2006 Økonomistyrelsen er ansvarlig for NemKonto,

Læs mere

Testspecifikationer. - Beskrivelse af specifikationer for tilslutningsprøven. Rapport. KMD August Version /

Testspecifikationer. - Beskrivelse af specifikationer for tilslutningsprøven. Rapport. KMD August Version / NemKonto KMD Selma Lagerlöfs Vej 300 9100 Aalborg www.nemkonto.dk info@nemkonto.dk Telefon: 44 60 10 00 Rapport Testspecifikationer - Beskrivelse af specifikationer for tilslutningsprøven. Version 2.1

Læs mere

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

NemKonto. XML skemaer for. ukomplette og komplette betalinger. til NKS NemKonto KMD Selma Lagerlöfs Vej 300 9100 Aalborg www.nemkonto.dk NemKonto XML skemaer for ukomplette og komplette betalinger til NKS Version 1.4 31-08-2005 Økonomistyrelsen er ansvarlig for NemKonto,

Læs mere

Lokale, danske betalinger - Business Online

Lokale, danske betalinger - Business Online Lokale, danske betalinger - Business Online Side 1 af 8 Dette dokument beskriver, hvorledes du skal opbygge filer med kommaseparerede betalingsrecords. Filen skal indeholde en linie for hver betaling.

Læs mere

Snitfladebeskrivelse for ukomplette og komplette betalingsmeddelelser

Snitfladebeskrivelse for ukomplette og komplette betalingsmeddelelser Snitfladebeskrivelse for ukomplette og komplette betalingsmeddelelser til NKS NemKonto Version 2.04 januar 2015 Digitaliseringsstyrelsen er ansvarlig for NemKonto, som udvikles af KMD Indholdsfortegnelse

Læs mere

Snitfladebeskrivelse for. ukomplette og komplette betalinger. til NKS

Snitfladebeskrivelse for. ukomplette og komplette betalinger. til NKS NemKonto KMD Lautrupparken 40-42 2750 Ballerup www.nemkonto.dk info@nemkonto.dk Telefon: 44 60 10 00 Snitfladebeskrivelse for ukomplette og komplette betalinger til NKS Version 2.05 10.03.2016 Digitaliseringsstyrelsen

Læs mere

August 2013 (version 1.1) Tilslutningsguide. Opgaver, der skal løses på vej mod NemKonto. NemKonto hører under Økonomistyrelsen.

August 2013 (version 1.1) Tilslutningsguide. Opgaver, der skal løses på vej mod NemKonto. NemKonto hører under Økonomistyrelsen. August 2013 (version 1.1) Tilslutningsguide Opgaver, der skal løses på vej mod NemKonto NemKonto hører under Økonomistyrelsen Side 0 Tilslutningsguide til NemKonto August 2013 (version 1.1) Tilslutningsguide...

Læs mere

Snitfladebeskrivelse for. ukomplette og komplette betalinger. til NKS

Snitfladebeskrivelse for. ukomplette og komplette betalinger. til NKS NemKonto KMD Selma Lagerlöfs Vej 300 9100 Aalborg www.nemkonto.dk Snitfladebeskrivelse for ukomplette og komplette betalinger til NKS Version 2.0 19.05.2006 Økonomistyrelsen er ansvarlig for NemKonto,

Læs mere

Specifikationer til tilslutningsprøven for Private Betalingsformidlere. Version 1. februar 2008

Specifikationer til tilslutningsprøven for Private Betalingsformidlere. Version 1. februar 2008 Specifikationer til tilslutningsprøven for Private Betalingsformidlere Version 1. februar 2008 Indholdsfortegnelse 1 Indledning...1 1.1 Formål med specifikationerne... 1 1.2 Forudsætninger for specifikationerne...

Læs mere

Unitel til pc Kommasepareret format for Posteringsdata August 2010

Unitel til pc Kommasepareret format for Posteringsdata August 2010 Unitel til pc Kommasepareret format for Posteringsdata August 2010 Indhold 1. Indledning... 3 2. Generelt... 3 2.1 Posteringstype- og reference-koder... 3 3. Feltbeskrivelse... 4 4. Record-beskrivelse

Læs mere

Kom godt i gang med. Nem Konto. Vejledning til sagsbehandlere. NemKonto hører under Økonomistyrelsen

Kom godt i gang med. Nem Konto. Vejledning til sagsbehandlere. NemKonto hører under Økonomistyrelsen Kom godt i gang med Nem Konto Vejledning til sagsbehandlere NemKonto hører under Økonomistyrelsen Indholdsfortegnelse 1 Introduktion... 2 2 Sådan bruger du NemKonto... 3 2.1 Log på NemKonto... 3 2.2 Signering

Læs mere

Snitfladebeskrivelse for Komplettering af Betalingsmeddelelser for Private Udbetalere NemKonto Version 1.02 januar 2015

Snitfladebeskrivelse for Komplettering af Betalingsmeddelelser for Private Udbetalere NemKonto Version 1.02 januar 2015 Snitfladebeskrivelse for Komplettering af Betalingsmeddelelser for Private Udbetalere NemKonto Version 1.02 januar 2015 NemKonto Snitfladebeskrivelse for Komplettering af Betalingsmeddelelser for Private

Læs mere

Snitfladebeskrivelse. NemKonto systemets Integration med Debitormotoren i SKAT EFI

Snitfladebeskrivelse. NemKonto systemets Integration med Debitormotoren i SKAT EFI Snitfladebeskrivelse NemKonto systemets Integration med Debitormotoren i SKAT EFI Indholdsfortegnelse Dokument og versionsoversigt (ændringslog)... 5 1 Brug af snitfladebeskrivelsen... 6 2 Formål og målgrupper...

Læs mere

1 Brug af snitfladebeskrivelsen... 2. 2 Formål og beskrivelse... 2. 2.1 Hvad er formålet med snitfladen?... 2. 2.2 Beskrivelse af snitfladen...

1 Brug af snitfladebeskrivelsen... 2. 2 Formål og beskrivelse... 2. 2.1 Hvad er formålet med snitfladen?... 2. 2.2 Beskrivelse af snitfladen... AUB - Indberet skoleophold(al8) Indholdsfortegnelse Indholdsfortegnelse 1 Brug snitfladebeskrivelsen... 2 2 Formål og beskrivelse... 2 2.1 Hvad er formålet med snitfladen?... 2 2.2 Beskrivelse snitfladen...

Læs mere

Unitel Betalingsadviseringer i EDI/4-format August 2009

Unitel Betalingsadviseringer i EDI/4-format August 2009 Unitel Betalingsadviseringer i EDI/4-format August 2009 Indhold 1. Indledning...3 2. Generel beskrivelse...4 3. Ændring af gebyrafregning pr. 1. november 2009...4 4. Opbygning af betalingsadviseringer...4

Læs mere

Dataleverandører leverer data til NemKonto-systemet via en direkte forbindelse til KMD.

Dataleverandører leverer data til NemKonto-systemet via en direkte forbindelse til KMD. Dataleverandør Dataleverandøraftale vedrørende NemKontoSystemet Dato Ref.: Mellem Dataleverandør adresse postnr. og by og KMD A/S cvr. nr. 26911745 Lov 1203 af 27. december 2003 om offentlige betalinger

Læs mere

Implementeringsvejledning NemKonto-betalinger via Danske Bank Version 1.2

Implementeringsvejledning NemKonto-betalinger via Danske Bank Version 1.2 Implementeringsvejledning NemKonto-betalinger via Danske Bank Version 1.2 NemKonto-betaling Side 1 af 13 Implementeringsvejledning Indholdsfortegnelse Indholdsfortegnelse... 2 Formål... 3 Målgruppe...

Læs mere

Snitfladebeskrivelse for GO000002Q Betalingsadministration Send sagsoplysninger til KMD Opus Debitor. Version 1.0,

Snitfladebeskrivelse for GO000002Q Betalingsadministration Send sagsoplysninger til KMD Opus Debitor. Version 1.0, Af Snitfladebeskrivelse for GO000002Q Betalingsadministration Send sagsoplysninger til KMD Opus Debitor Version 1.0, 05.09.2012 Indholdsfortegnelse Indholdsfortegnelse Ændringer i forhold til forrige version...

Læs mere

Fejlbehæftede betalinger

Fejlbehæftede betalinger Danske Bank, Statens Betalinger Fejlbehæftede betalinger Juni 2015 Side 1 Indhold 1 Formål... 3 2 Forespørgsel på en betaling i Business Online... 3 3 Identifikation af fejlbehæftede betalinger, der indsættes

Læs mere

Corporate Netbank og Unitel til pc. Kommasepareret format til betalinger (UTF-format) November 2009

Corporate Netbank og Unitel til pc. Kommasepareret format til betalinger (UTF-format) November 2009 Corporate Netbank og Unitel til pc Kommasepareret format til betalinger (UTF-format) November 2009 Indhold 1. Indledning...3 2. Formattype...4 3. Feltbeskrivelse...5 4. Maksimum- og minimumfelter...14

Læs mere

Recordbeskrivelser August 2015. Jyske Netbank Erhverv

Recordbeskrivelser August 2015. Jyske Netbank Erhverv Recordbeskrivelser August 2015 Jyske Netbank Erhverv Indledning... 4 Jyske Banks format... 4 Formatbeskrivelse... 6 af records med fast længde... 6 af records med variabel længde... 7 Betaling start...

Læs mere

SelskabMasterKom. Danpot 2010. KomTabel-layout. Art: 41 Sendes: Begge veje

SelskabMasterKom. Danpot 2010. KomTabel-layout. Art: 41 Sendes: Begge veje SelskabMasterKom Bemærkninger: Ny protokol (opr. Art 11) Generelt : 1. + 2. byte = RecordArt 3. byte = Transaktionskode 1 = Opret 2 = Ændring 3 = Slet Email og Hjemmeside reduceret til 30 kar. Samlet længde

Læs mere

Formatbeskrivelse til ERH Bankens Erhvervsformat (BEC format) November 2010

Formatbeskrivelse til ERH Bankens Erhvervsformat (BEC format) November 2010 Formatbeskrivelse til ERH Bankens Erhvervsformat (BEC format) November 2010 Dette dokument er inddelt i 4 hovedområder: Beskrivelse af filformatet, kontonummerformater og datatyper. Betalingsformat for

Læs mere

KMD accepterer opkobling ved etablering af enten VPN-tunnel eller fast forbindelse.

KMD accepterer opkobling ved etablering af enten VPN-tunnel eller fast forbindelse. Tilslutning til NemKonto via KMD EDI-service (VANS) Overordnet foregår en udbetaling via NemKonto-systemet ved at et udbetalende system sender en betalingsordre til NemKonto-systemet. Som standard anbefaler

Læs mere

Vejledning i opsætning af MQ

Vejledning i opsætning af MQ NemKonto KMD Lauritzens Plads 1 9000 Aalborg www.nemkonto.dk support@nemkonto.dk Vejledning i opsætning af MQ 19. februar 2016 Side 1 Beskrivelse af MQ opsætning ved opkobling til KMD Nemkonto 1. Formål

Læs mere

Recordbeskrivelser. Nordbank Erhverv

Recordbeskrivelser. Nordbank Erhverv Recordbeskrivelser Nordbank Erhverv 04-03-2008 A-Z Rekordbeskrivelse Indledning... 3 Nordjyske Banks format... 3 Formatbeskrivelse... 5 af records med fast længde... 5 af records med variabel længde...

Læs mere

SelskabMasterKom. Per Kjærulf-Møller ApS 13. november 2008. KomTabel-layout. Art: 41 Sendes: Begge veje

SelskabMasterKom. Per Kjærulf-Møller ApS 13. november 2008. KomTabel-layout. Art: 41 Sendes: Begge veje SelskabMasterKom Bemærkninger: Ny protokol (opr. Art 11) Generelt : 1. + 2. byte = RecordArt 3. byte = Transaktionskode 1 = Opret 2 = Ændring 3 = Slet Email og Hjemmeside reduceret til 30 kar. Samlet længde

Læs mere

OverførselsService. Recordbeskrivelser overførsler

OverførselsService. Recordbeskrivelser overførsler Recordbeskrivelser overførsler INDHOLDSFORTEGNELSE INDHOLDSFORTEGNELSE INDHOLDSFORTEGNELSE... 2 HISTORIK... 3 OVERFØRSLER... 4 Overførselsarter... 4 Recordstruktur... 5 Eksempel på opbygningen af en leverance

Læs mere

Formatbeskrivelse til indlæsning af betalinger

Formatbeskrivelse til indlæsning af betalinger Formatbeskrivelse til indlæsning af betalinger - ERH Bankens Erhvervsformat (BEC) Udarbejdet af: BEC Gældende fra: 21. februar 2013 Version Udarbejdet af Dato 1.0 BEC Bankernes EDB Central 21. februar

Læs mere

NemKonto - Anmodning om tilslutning

NemKonto - Anmodning om tilslutning Status: Eksisterende aftale Nej, vi har ingen systemer, der er på NemKonto-systemet Benytter KMD til udbetaling Nej, vi anvender ikke nogen af KMDs udbetalingssystemer i vores organisation Eksisterende

Læs mere

LeverandørService Beskrivelse af elektronisk uddata fra Nets

LeverandørService Beskrivelse af elektronisk uddata fra Nets INDHOLDSFORTEGNELSE ELEKTRONISK UDDATA FRA Nets KVITTERING OG ANMÆRKNINGER (690)... 3 LEVERANCE START... 5 KVITTERING FOR BETALINGSOPLYSNINGER... 7 ANMÆRKNING... 9 BEMÆRKNING... 11 ÆNDRING... 13 LEVERANCE

Læs mere

Recordbeskrivelser Indlæs April 2014. Jyske Netbank Erhverv Plus

Recordbeskrivelser Indlæs April 2014. Jyske Netbank Erhverv Plus Recordbeskrivelser Indlæs April 2014 Jyske Netbank Erhverv Plus Indledning... 3 Jyske Bank format... 3 Formatbeskrivelse... 4 af records med fast længde... 4 Betaling start (IB000000000000)... 6 Indenlandsk

Læs mere

Corporate Netbank Posteringsdata ver. 2, 3 og 4 DK August 2015

Corporate Netbank Posteringsdata ver. 2, 3 og 4 DK August 2015 Corporate Netbank Posteringsdata ver. 2, 3 og 4 DK August 2015 Indhold 1. Indledning... 3 2. Generelt... 3 2.1 Posteringstype- og reference-koder... 3 1. Feltbeskrivelse... 4 2. Record-beskrivelse version

Læs mere

Kodeliste. Statuskode Statustekst

Kodeliste. Statuskode Statustekst Side 1 af 11 Denne kodeliste beskriver de koder, der kan forekomme i statusmeddelelsen. Statuskode Statustekst 001 Træk-/forfaldsdato skal udfyldes som AAAAMMDD 002 Fakturadato skal udfyldes som AAAAMMDD

Læs mere

Snitfladebeskrivelse for GO000003Q Betalingsadministration Send forespørgsel til og modtag svar fra KMD Opus Debitor. Version 1.0,

Snitfladebeskrivelse for GO000003Q Betalingsadministration Send forespørgsel til og modtag svar fra KMD Opus Debitor. Version 1.0, Af Snitfladebeskrivelse for GO000003Q Betalingsadministration Send forespørgsel til og modtag svar fra KMD Opus Debitor Version 1.0, 05.09.2012 Indholdsfortegnelse Indholdsfortegnelse Ændringer i forhold

Læs mere

AO FORRETNINGSREGLER EDI fakturaer fra vareleverandører. (offentliggøres på Suppliers Portal)

AO FORRETNINGSREGLER EDI fakturaer fra vareleverandører. (offentliggøres på Suppliers Portal) AO FORRETNINGSREGLER EDI fakturaer fra vareleverandører (offentliggøres på Suppliers Portal) Version 6 / 09.08.2010 Formater og Tegnsæt AO ønsker at modtage EDI i følgende formater og tegnsæt: Formatering

Læs mere

Vejledning i opsætning af MQ

Vejledning i opsætning af MQ NemKonto KMD Lauritzens Plads 1 9000 Aalborg www.nemkonto.dk support@nemkonto.dk Vejledning i opsætning af MQ 20-11-2008 Side 1 Økonomistyrelsen er ansvarlig for NemKonto, som udvikles af KMD Beskrivelse

Læs mere

Dataudvekslingsaftale vedrørende tilslutning til NemRefusions Virksomhedsservice

Dataudvekslingsaftale vedrørende tilslutning til NemRefusions Virksomhedsservice Dataudvekslingsaftale vedrørende tilslutning til NemRefusions Virksomhedsservice Dato: Ref.: Mellem og KOMBIT A/S Formål Formålet med denne aftale er at fastlægge de tekniske krav til kommunikationen mellem

Læs mere

Unitel til pc Kommasepareret format for kreditadvis på indenlandske bankoverførsler September 2007

Unitel til pc Kommasepareret format for kreditadvis på indenlandske bankoverførsler September 2007 Unitel til pc Kommasepareret format for kreditadvis på indenlandske bankoverførsler September 2007 Indhold 1. Indledning... 3 2. Generelt... 3 3. Feltbeskrivelse... 4 4. Record-beskrivelse... 5 4.1 Eksempel

Læs mere

Integration af DocuBizz og Helios

Integration af DocuBizz og Helios Integration af DocuBizz og Helios v. 0.2 Side 1 af 7 Integration af DocuBizz og Helios 1 Overordnet beskrivelse... 1 2 Format for de overførte data... 1 3 Overførsel af stamdata fra Helios til DocuBizz...

Læs mere

Vejledning der beskriver processen mellem manuelle bilag i IndFak2 og NS 7.0

Vejledning der beskriver processen mellem manuelle bilag i IndFak2 og NS 7.0 INDFAK2 og NS 7.0 ØSY/STPEL/TIE 30.06.2015 Vejledning der beskriver processen mellem manuelle bilag i IndFak2 og NS 7.0 Formål I denne vejledning kan du se hvilke oplysninger der skal udfyldes ved oprettelse

Læs mere

Unitel EDI Indbetalingskort advisering August 2003

Unitel EDI Indbetalingskort advisering August 2003 Unitel EDI Indbetalingskort advisering August 2003 Solo-symbolet står for sikker og nem adgang til Nordea via forskellige elektroniske kanaler. Indhold 1. Generelle oplysninger...3 2. Advisering af indbetalinger...3

Læs mere

Formatbeskrivelse til indlæsning af betalinger

Formatbeskrivelse til indlæsning af betalinger Formatbeskrivelse til indlæsning af betalinger - ERH Bankens Erhvervsformat (BEC) Udarbejdet af: BEC Gældende fra: 21. februar 2013 Version Udarbejdet af Dato 1.0 BEC Bankernes EDB Central 21. februar

Læs mere

Corporate Netbank og Unitel. Betalinger i EDI/4 format Juni 2011

Corporate Netbank og Unitel. Betalinger i EDI/4 format Juni 2011 Corporate Netbank og Unitel Betalinger i EDI/4 format Juni 2011 Indhold 1. Indledning...3 2. Generel beskrivelse...4 2.1. Filnavne...4 2.2. Filopbygning...4 2.3. Formattype...4 2.4. Numeriske og alfanumeriske

Læs mere

Udgivelsen er beskyttet af Creative Commons license, Navngivning 2.5

Udgivelsen er beskyttet af Creative Commons license, Navngivning 2.5 OIOUBL Guideline OIOUBL Valutakurser og -koder UBL 2.0 Currency Exchange Rates G18 Version 1.2 Udgivelsen er beskyttet af Creative Commons license, Navngivning 2.5 OIOUBL Valutakurser og -koder Version

Læs mere

Formatbeskrivelse til ERH - Bankens Erhvervsformat (BEC format) Oktober 2005

Formatbeskrivelse til ERH - Bankens Erhvervsformat (BEC format) Oktober 2005 Formatbeskrivelse til ERH - Bankens Erhvervsformat (BEC format) Oktober 2005 Dette dokument er inddelt i 3 hovedområder: Beskrivelse af filformatet, kontonummerformater og datatyper Betalingsformat for

Læs mere

Standardformat for FI-kort (kortart 71, 73 og 75)

Standardformat for FI-kort (kortart 71, 73 og 75) Standardformat for FI-kort (kortart 71, 73 og 75) Side 1 af 9 Ønsker man at arbejde med finanssektorens standardformat for fælles indbetalingskort, skal det bemærkes, at der opereres på 3 niveauer: * Leverance

Læs mere

DKAL Snitflader REST Register

DKAL Snitflader REST Register DKAL Snitflader REST Register 1 Indholdsfortegnelse A2.1 INTRODUKTION 3 A2.1.1 HENVISNINGER 3 A2.1.2 LÆSEVEJLEDNING 4 A2.1.2.1 SÅDAN LÆSES EN REST GRAF 4 A2.1.2.2 SÅDAN LÆSES EN RESSOURCE OG EN TYPE 4

Læs mere

Snitfladebeskrivelse for Snitfladebeskrivelse STD-8 KMD Boligstøtte Version 1.0.0, 13.12.2011

Snitfladebeskrivelse for Snitfladebeskrivelse STD-8 KMD Boligstøtte Version 1.0.0, 13.12.2011 Snitfladebeskrivelse for Snitfladebeskrivelse STD-8 KMD Boligstøtte Version 1.0.0, 13.12.2011 Indholdsfortegnelse Ændringer i forhold til forrige version... 2 1 Brug af snitfladebeskrivelsen... 3 2 Formål

Læs mere

DKAL Snitflader Masseforsendelse

DKAL Snitflader Masseforsendelse DKAL Snitflader Masseforsendelse 1 C.1 Indholdsfortegnelse C.1 INDHOLDSFORTEGNELSE... 2 C.2 LÆSEVEJLEDNING... 3 C.3 TILMELDINGSLISTE... 4 C.3.1 RECORD-STRUKTUR... 4 C.3.2 OIOXML-STRUKTUR... 5 C.4 MATERIALE-INDLÆSNING...6

Læs mere

Tilslutning til ecomone Basis (OIO Faktura)

Tilslutning til ecomone Basis (OIO Faktura) Tilslutning til ecomone Basis (OIO Faktura) 1. november 2009, Version 1.1 1. POST DANMARKS ECOMONE BASIS (OIO FAKTURA)... 3 1.1 BEGREBER... 3 2 KANALER... 3 3 MODEL FOR DATAUDVEKSLING... 4 4 KOMMUNIKATION...

Læs mere

Eksport FI-indbetalinger i Netbanken

Eksport FI-indbetalinger i Netbanken -------------------------- Eksport FI-indbetalinger i Netbanken Indhold: side Generel information 2 Beskrivelse af layoutformat 3-7 Konceptafdelingen side 1 -------------------------- Generel information

Læs mere

Instruktion til UNGDOMSSKOLEWEB BETALINGSMODULER. Version 1.04

Instruktion til UNGDOMSSKOLEWEB BETALINGSMODULER. Version 1.04 Instruktion til UNGDOMSSKOLEWEB BETALINGSMODULER Version 1.04 Indholdsfortegnelse BETALINGSMODULER... 3 OVERSIGT OVER TILMELDINGER... 3 Status for tilmelding... 3 INDBETALINGER... 4 Åben FI-ordre/uafsluttede

Læs mere

Snitfladebeskrivelse for. ukomplette og komplette betalinger. til NKS

Snitfladebeskrivelse for. ukomplette og komplette betalinger. til NKS NemKonto KMD Selma Lagerlöfs Vej 300 9100 Aalborg www.nemkonto.dk Snitfladebeskrivelse for ukomplette og komplette betalinger til NKS Version 1.5 31-08-2005 Økonomistyrelsen er ansvarlig for NemKonto,

Læs mere

Recordbeskrivelser kort. Office Banking/Netbank Erhverv ALM. BRAND BANK

Recordbeskrivelser kort. Office Banking/Netbank Erhverv ALM. BRAND BANK Recordbeskrivelser kort Office Banking/Netbank Erhverv ALM. BRAND BANK 03-06-2008 3. juni 2008 A-Z PI-systemer PCB - Rekordbeskrivelse - kildedok Indledning... 3 ALM. BRAND BANKs format... 3 Formatbeskrivelse...

Læs mere

Mamut Stellar Banking

Mamut Stellar Banking Mamut Stellar Banking Mamut Stellar Banking understøtter betalinger på en overskuelig måde, og det er muligt at fratrække evt kreditnotaer fra en Saldobetaling før den gennemføres. Dermed får man automatisk

Læs mere

Finanstilsynets indberetningssystem. Vejledning til Regnearksskabelonerne

Finanstilsynets indberetningssystem. Vejledning til Regnearksskabelonerne Finanstilsynets indberetningssystem Vejledning til Regnearksskabelonerne Finanstilsynet - 2. udgave oktober 2009 Indholdsfortegnelse 1 INDLEDNING... 2 2 FORUDSÆTNINGER... 3 3 TRIN FOR TRIN... 4 3.1 Hent

Læs mere

3. Fælles struktur for betalingstransaktioner

3. Fælles struktur for betalingstransaktioner 07.10.2013 3. Fælles struktur for Indholdsfortegnelse Indledning... 2 Dataelementer... 3 Betalingstransaktioner... 5 Overførsel med kort advisering... 6 Overførsel med udvidet advisering uden krav om straks-advisering...

Læs mere

Nedenstående oversigt viser elementerne i den meddelelse, der skal overføres fra fødeafdeling til kirkekontor/sogn.

Nedenstående oversigt viser elementerne i den meddelelse, der skal overføres fra fødeafdeling til kirkekontor/sogn. Teknisk oversigt over elementer i fødselsanmeldelsen Nedenstående oversigt viser elementerne i den meddelelse, der skal overføres fra fødeafdeling til kirkekontor/sogn. Der anvendes XML. Denne version

Læs mere

Indledning... 2 Opbygning... 2 Servicesegmenternes sammenhæng... 3 UNA... 4 UNB... 6 UNH... 10 UNT... 12 UNZ... 14

Indledning... 2 Opbygning... 2 Servicesegmenternes sammenhæng... 3 UNA... 4 UNB... 6 UNH... 10 UNT... 12 UNZ... 14 05.05.2000 5. SERVICESEGMENTER Indholdsfortegnelse Indledning... 2 Opbygning... 2 Servicesegmenternes sammenhæng... 3 UNA... 4 UNB... 6 UNH... 10 UNT... 12 UNZ... 14 Side: 2 Indledning Dette afsnit indeholder

Læs mere

Import i netbank. Generel information. Beskrivelse af SDC layoutformat. Hvilke formater understøttes også? Version 2.0 Danmark 02-10-2013 / 09:46 /VC

Import i netbank. Generel information. Beskrivelse af SDC layoutformat. Hvilke formater understøttes også? Version 2.0 Danmark 02-10-2013 / 09:46 /VC Import i netbank Generel information Beskrivelse af SDC layoutformat Hvilke formater understøttes også? Version 2.0 Danmark 1 Generel information Data fra fx. økonomisystemer kan importeres i netbanken.

Læs mere

Online Banking Recordbeskrivelse

Online Banking Recordbeskrivelse Recordbeskrivelse hotline@sydbank.dk Side 1 af 64 Indholdsfortegnelse Indledning... 3 Sydbanks format... 3 Formatbeskrivelse... 5 af records med fast længde... 5 af records med variabel længde... 6 Betaling

Læs mere

Recordbeskrivelse. Elektroniske kontoposter version 4.05

Recordbeskrivelse. Elektroniske kontoposter version 4.05 Recordbeskrivelse Elektroniske kontoposter version 4.05 19. april 2010 Side 1 af 6 Formål Leverer posteringsoplysninger i semikolon separeret fil. Filen er velegnet til indlæsning i et Excel-regneark,

Læs mere

Det skal bemærkes at der opereres med leverance start/slut, sektion start/slut, betalings-, navn/adresse- og adviseringsrecords.

Det skal bemærkes at der opereres med leverance start/slut, sektion start/slut, betalings-, navn/adresse- og adviseringsrecords. af standardformat for Indbetalingskort Det skal bemærkes at der opereres med leverance start/slut, sektion start/slut, betalings-, navn/adresse- og adviseringsrecords. Leverancestart/slut skal kun forekomme

Læs mere

Vejledning til SLS webservice Løbende løndele

Vejledning til SLS webservice Løbende løndele Side 1 af 12 Vejledning til SLS webservice Løbende løndele Indholdsfortegnelse Ændringslog... 1 Formålet med webservicen... 2 Forretningsmæssig beskrivelse... 2 Wsdl-dokumenter... 2 OIOXML-skemaer... 3

Læs mere

OIOUBL Guideline. OIOUBL Guideline

OIOUBL Guideline. OIOUBL Guideline OIOUBL Guideline OIOUBL Guideline OIOUBL Datatyper UBL 2.0 Datatypes G29 Version 1.3 Udgivelsen er beskyttet af Creative Commons license, Navngivning 2.5 Kolofon Kontakt: Digitaliseringsstyrelsen E-mail:

Læs mere

Det fælles indbetalingskort M604 - Adviseringsleverance

Det fælles indbetalingskort M604 - Adviseringsleverance Datamodtager startrecord Dato: 10.05.93 2 RECORDTYPE 3 N 003 005 Ja 010 3 DATAAFSENDER 8 N 006 013 Ja SE-nummer på dataleverandøren 4 DATAMODTAGER 10 N 014 023 Ja Se-nummer på datamodtager 5 LEVERANCENUMMER

Læs mere

Digital post Snitflader Bilag A2 - REST Register Version 6.3

Digital post Snitflader Bilag A2 - REST Register Version 6.3 Digital post Snitflader Bilag A2 - REST Register Version 6.3 1 Indholdsfortegnelse A2.1 INTRODUKTION 4 A2.1.1 HENVISNINGER 4 A2.2 OVERSIGT OVER FUNKTIONSOMRÅDE 5 A2.2.1 OPRET / HENT OPLYSNINGER OM SLUTBRUGER

Læs mere

Mamut Stellar efaktura

Mamut Stellar efaktura Mamut Stellar efaktura Med Mamut Stellar e-faktura er det muligt at afsende og modtage e-fakturaer fra det offentlige og private virksomheder med GLN nummer (tidligere EAN-lokationsummer) via OIOSI eller

Læs mere

AO FORRETNINGSREGLER EDI fakturaer fra vareleverandører. (offentliggøres på Suppliers Portal)

AO FORRETNINGSREGLER EDI fakturaer fra vareleverandører. (offentliggøres på Suppliers Portal) AO FORRETNINGSREGLER EDI fakturaer fra vareleverandører (offentliggøres på Suppliers Portal) Version 7 / 13.01.2011 Formater og Tegnsæt AO ønsker at modtage EDI faktura i følgende formater og tegnsæt:

Læs mere

DK-Unit Point version 2.xx til PWE 37

DK-Unit Point version 2.xx til PWE 37 Beskrivelse af DK-Unit til Point Yomani og Xenta Dankort terminaler DK-Unit programmet er udviklet til at kunne benyttes sammen med forskellige applikationer, hvor man ønsker at kunne danne en Dankort

Læs mere

JTA-DynamicsKost JTA. Til. Microsoft Dynamics C5 vers. 3 eller højere. DATA. Jylland

JTA-DynamicsKost JTA. Til. Microsoft Dynamics C5 vers. 3 eller højere. DATA. Jylland -DynamicsKost Til Microsoft Dynamics C5 vers. 3 eller højere. -Data www.jta-jylland.dk -DynamicsKost vers. 1.2.1 til Microsoft Dynamics C5 1. Introduktion til -DynamicsKost -Kost til Microsoft Dynamics

Læs mere

Overførselsservice Vejledning for betalingsafsendere og dataleverandører

Overførselsservice Vejledning for betalingsafsendere og dataleverandører Nets Denmark A/S Lautrupbjerg 10 P.O. 500 DK-2750 Ballerup T +45 44 68 44 68 F +45 44 86 09 30 www.nets.eu CVR-nr. 20016175 Overførselsservice Vejledning for betalingsafsendere og dataleverandører P. 1-53

Læs mere

Vejledning: Fakturablanketten på Virk.dk

Vejledning: Fakturablanketten på Virk.dk Vejledning: Fakturablanketten på Virk.dk Fakturablanketten version 2.4.0 (Opdatering april 2015) Vælg fakturablanket... 2 Start indberetning... 2 Opret faktura... 3... 6 Faktura-modtager... 6 Leverandør...

Læs mere

Datatransport... 2. Import & Eksport af data... 2. Generelt... 2. Import/eksport... 4. Felter i Import og Eksport... 5

Datatransport... 2. Import & Eksport af data... 2. Generelt... 2. Import/eksport... 4. Felter i Import og Eksport... 5 Indhold Datatransport... 2 Import & Eksport af data... 2 Generelt... 2 Import/eksport.... 4 Felter i Import og Eksport... 5 Trykknapper til Import og Eksport... 7 1 Alle... 7 2 Slet... 7 3 Editor... 7

Læs mere

Import i Portalbank 4.1

Import i Portalbank 4.1 Import i Portalbank 4.1 Generel information Importforskelle KaSel - Portalbank Beskrivelse af KaSel layoutformat Hvilke formater understøttes også? Version 1.0 Generel information Data fra fx. økonomisystemer

Læs mere

1 Brug af feltbeskrivelsen... 3. 2 Formål og beskrivelse... 4. 2.1 Hvad er formålet med feltbeskrivelsen?... 4. 2.2 Modtagelse af data...

1 Brug af feltbeskrivelsen... 3. 2 Formål og beskrivelse... 4. 2.1 Hvad er formålet med feltbeskrivelsen?... 4. 2.2 Modtagelse af data... Indholdsfortegnelse Indholdsfortegnelse 1 Brug af feltbeskrivelsen... 3 2 Formål og beskrivelse... 4 2.1 Hvad er formålet med feltbeskrivelsen?... 4 2.2 Modtagelse af data... 4 2.3 Begreber, definitioner

Læs mere

PBS menuen 5.1. Når du anvender et PBS-modul, må der max være 14 cifre i forbrugernummeret.

PBS menuen 5.1. Når du anvender et PBS-modul, må der max være 14 cifre i forbrugernummeret. PBS menuen 5.1 5. PBS-MENUEN Generelt Et PBS-modul er ensbetydende med besparelser, både omkostnings- og administrationsmæssigt, idet en stor del af det arbejde, som er forbundet med opkrævninger, overtages

Læs mere

Uddybende vejledning til UTS Forsyningsspecifikation i OIOUBL

Uddybende vejledning til UTS Forsyningsspecifikation i OIOUBL Uddybende vejledning til UTS Forsyningsspecifikation i OIOUBL 4. januar 2013 Indhold UTS og forskellen i forhold til det gamle format...2 Udfordringer med UTS...2 Tiltag med henblik på at afhjælpe udfordringerne...3

Læs mere

14. KONTROLMEDDELELSE

14. KONTROLMEDDELELSE 01.03.2001 14. KONTROLMEDDELELSE Indholdsfortegnelse Indledning...3 Anvendelse...3 Anvendelse ved forsendelse fra kunde...3 Anvendelse ved forsendelse fra pengeinstitut...3 Kontrolmeddelelsens funktioner...4

Læs mere

DK701. Snitfladebeskrivelse mv. om overførsel af erstatnings-anmodning fra Hospitaler til "danmark" 30. april 2002 IT-afdelingen, danmark

DK701. Snitfladebeskrivelse mv. om overførsel af erstatnings-anmodning fra Hospitaler til danmark 30. april 2002 IT-afdelingen, danmark DK701 Snitfladebeskrivelse mv. om overførsel af erstatnings-anmodning fra Hospitaler til "danmark" 30. april 2002 IT-afdelingen, danmark Overførsel af erstatningsanmodning fra hospitaler til "danmark"

Læs mere

Snitfladebeskrivelse. til Ferie Ind

Snitfladebeskrivelse. til Ferie Ind Snitfladebeskrivelse til Ferie Ind Version 1.1. 06-10-2007 KMD A/S 2003. Alle rettigheder forbeholdes. Dette materiale er ophavsretligt beskyttet og må ikke kopieres i videre omfang end forudsat i ophavsretsloven.

Læs mere

Generelle regler for OverførselsService

Generelle regler for OverførselsService Generelle regler for Gældende fra 1. november 2009 1. Hvad er er et produkt, som giver beløbsafsender mulighed for via Nets at iværksætte overførsel af beløb i danske kroner til beløbsmodtageres konti

Læs mere

Betaling via Business Online

Betaling via Business Online Forløbet for en betaling Du får her en kort beskrivelse af, hvordan du opretter og godkender en betaling i Business Online. 1. Opret betalinger/mapper 2. Kontroller betalinger 3. Luk mappen og godkend

Læs mere

BENCHMARK ANALYSE. The Continia Way to Pay!

BENCHMARK ANALYSE. The Continia Way to Pay! BENCHMARK ANALYSE The Continia Way to Pay! Baseret på løsninger i mere end 3.500 aktive Microsoft Dynamics NAV licenser fra Continia Software ligger mere end 20 års erfaring og arbejde i at finjustere

Læs mere

Vilkår for betalingskonti

Vilkår for betalingskonti Vilkår for betalingskonti Vilkår for betalingskonti Erhvervskunder Gældende fra den 18-08-2014 1. Indledning Disse vilkår gælder for betalingstjenester tilknyttet betalingskonti oprettet med henblik på

Læs mere

Overførsler til udlandet

Overførsler til udlandet Danske Bank, Statens Betalinger Overførsler til udlandet Juli 2010 Side 1 Indhold 1 Indledning... 3 2 Krav til STP-betalinger indenfor EU:... 3 3 Krav til STP-betalinger udenfor EU:... 3 4 BIC (SWIFT)...

Læs mere

S N I T F L A D E B E S K R I V E L S E : G F 2 0 0 0 0 1 Q U D B E T A L I N G S T R A N S A K T I O N E R T I L U D B E T A L I N G V I A

S N I T F L A D E B E S K R I V E L S E : G F 2 0 0 0 0 1 Q U D B E T A L I N G S T R A N S A K T I O N E R T I L U D B E T A L I N G V I A S N I T F L A D E B E S K R I V E L S E : G F 2 0 0 0 0 1 Q U D B E T A L I N G S T R A N S A K T I O N E R T I L K M D U D B E T A L I N G V I A D A T A F A N G S T Dataleverandør-id : Udleveret af Udleveringsdato

Læs mere

Du får her en kort beskrivelse af, hvordan du kommer i gang med at oprette en opkrævning som elektronisk faktura e Faktura i Business Online.

Du får her en kort beskrivelse af, hvordan du kommer i gang med at oprette en opkrævning som elektronisk faktura e Faktura i Business Online. Afsendelse af e Faktura Du får her en kort beskrivelse af, hvordan du kommer i gang med at oprette en opkrævning som elektronisk faktura e Faktura i Business Online. 1. Opret stamoplysninger (Fakturerings-

Læs mere

Axapta 3.0 Konverteringsvejledning

Axapta 3.0 Konverteringsvejledning Axapta 3.0 Konverteringsvejledning ectrl Dokumentversion 3.0 Juli 2008 - Datakonvertering 2008 Side 1 af 14 Indholdsfortegnelse DATAKONVERTERINGSVÆRKTØJET:...3 KARTOTEK INFORMATIONSOVERSIGT - FANEBLAD...5

Læs mere

OPDATERINGSVEJLEDNING FOR AKC5 1.20 DECEMBER 2008

OPDATERINGSVEJLEDNING FOR AKC5 1.20 DECEMBER 2008 OPDATERINGSVEJLEDNING FOR AKC5 1.20 DECEMBER 2008 Denne vejledning beskriver installation af opdatering, nyheder og ændringer som skal bruges fra og med 1. januar 2009. Det er derfor meget vigtigt at du

Læs mere

DKAL Snitflader Afsendelse og modtagelse af meddelelser via S/MIME

DKAL Snitflader Afsendelse og modtagelse af meddelelser via S/MIME DKAL Snitflader Afsendelse og modtagelse af meddelelser via S/MIME 1 Indholdsfortegnelse B.1. INTRODUKTION... 3 B.1.1. HENVISNINGER... 3 B.1.2. INTEGRATION MED EKSISTERENDE SIKKER E-POSTLØSNING... 3 B.1.3.

Læs mere

Kvikguide til opsætning af Navision Stat 5.2 for afvikling af betalinger via Business Online (Danske Bank)

Kvikguide til opsætning af Navision Stat 5.2 for afvikling af betalinger via Business Online (Danske Bank) Kvikguide til opsætning af Navision Stat 5.2 for afvikling af betalinger via Business Online (Danske Bank) Side 1 af 31 ØKO/TIE Opr. 16.12.10 Overblik Introduktion Denne guide beskriver, hvordan du sætter

Læs mere

Elektronisk kontoudtog Ver 1.00

Elektronisk kontoudtog Ver 1.00 Elektronisk kontoudtog Ver 1.00 Formål I Webbank er der mulighed for at foretage en eksport af sine kontoterne til en fil. Følgende er en beskrivelse formatet for elektroniske kontoter. Datafil BEC danner

Læs mere

Vejledning om. Automatisk Bankkontoafstemning i. Navision Stat via API eller Business Online

Vejledning om. Automatisk Bankkontoafstemning i. Navision Stat via API eller Business Online Vejledning om Automatisk Bankkontoafstemning i Navision Stat via API eller Business Online Indholdsfortegnelse 1. Indledning... 3 2. Hvordan kontoafstemning... 3 3. Bestillinger... 3 3.1 Bestilling via

Læs mere

Udvalgte nye elementer i Navision 5.2.01. DDI en

Udvalgte nye elementer i Navision 5.2.01. DDI en Version 1 10. juni 2011 Udvalgte nye elementer i Navision 5.2.01 DDI en Oplæg juni 2011 til Kulturministeriet Bestillingsoversigt i DDI en - Bestillingsoversigten åbnes via Indrapportering til ØSC \Bestillingsoversigt,

Læs mere

DK-Unit Point version 1.xx

DK-Unit Point version 1.xx Beskrivelse af DK-Unit til Point Yomani og Xenta Dankort terminaler DK-Unit programmet er udviklet til at kunne benyttes sammen med forskellige applikationer, hvor man ønsker at kunne danne en Dankort

Læs mere

KØBSPROCESSEN i forbindelse med Elektroniske fakturaer

KØBSPROCESSEN i forbindelse med Elektroniske fakturaer KØBSPROCESSEN i forbindelse med Elektroniske fakturaer 1. Kreditor generelt For at Navision Stat kan modtage en elektronisk faktura på en given kreditor skal der foretages opsætning heraf. Dette betyder,

Læs mere

Håndbog Til CPR services. Bilag 8 GCTP-standard m.m. CPR-kontoret

Håndbog Til CPR services. Bilag 8 GCTP-standard m.m. CPR-kontoret Håndbog Til CPR services Bilag 8 GCTP-standard m.m. CPR-kontoret Datavej 20, Postboks 269, 3460 Birkerød E-post: cpr@cpr.dk. Telefax 45 82 51 10. Hjemmeside: www.cpr.dk Side 2 af 14 Indholdsfortegnelse

Læs mere

SEPA DIRECT DEBIT. Vejledning til forespørgselsprocedure ved fejlagtig erhvervsbetaling

SEPA DIRECT DEBIT. Vejledning til forespørgselsprocedure ved fejlagtig erhvervsbetaling SEPA DIRECT DEBIT Vejledning til forespørgselsprocedure ved fejlagtig erhvervsbetaling Payment Business Services PBS A/S Lautrupbjerg 10 P.O. 500 DK 2750 Ballerup T +45 44 68 44 68 F +45 44 86 09 30 pbsmailservice@pbs.dk

Læs mere