Kvitteringsprincipper og -regler
|
|
- Lotte Rasmussen
- 7 år siden
- Visninger:
Transkript
1 Forskrift F: EDI-kommunikation Bilagsrapport 2: Kvitteringsprincipper og -regler April 2007 Rev. 1 Dok.løbenr /15
2 Indholdsfortegnelse 1. Kvitteringsprincipper og -regler Begreber af kvitterings- og fejlmeddelelsesniveauer Generiske kvitteringsprincipper Punkt 1 - Generelt Punkt 2 - Er afsender kendt? Punkt 3 Syntaks og struktur OK? Punkt 4 - Positiv kvittering? (gælder kun EDIFACT) Punkt 5 - Behandling af meddelelsen Punkt 6 - Fejl? Punkt 7 - Overholdes tidsfristen? Punkt 8 Fejlbehandling EDIFACT-kvittering CONTRL APERAK Negativ APERAK Positiv APERAK XML-kvitteringer Dok.løbenr /15
3 1. Kvitteringsprincipper og -regler Det overordnede princip i forbindelse med EDI-udvekslinger i Danmark er, at der skal foreligge et svar fra modtageren af data enten i form af en accept eller en fejlmeddelelse. For at sikre at de elektroniske meddelelser sendes og modtages korrekt, og at eventuelle fejl bliver fundet og behandlet, skal aktører efterleve reglerne for brug af kvitteringer og fejlmeddelelser, som de er beskrevet i dette dokument. UN/CEFACT angiver tre overordnede niveauer af accept. Accept af modtagelse (sendt fra kommunikationssoftware/edi-konverter) Accept af EDI-meddelelse (sendt fra EDI- og/eller forretningsapplikationen) Meddelelsessvar (sendt fra forretningsapplikationen) Sidstnævnte anvendes kun, når det sker i overensstemmelse med en forretningsproces og dermed ikke for simple meddelelser. Meddelelsessvar behandles ikke nærmere i dette dokument, men er beskrevet i de enkelte forretningsprocesser. Ud over disse niveauer af accept findes der flere niveauer af fejlmeddelelser, der afsendes, når der opstår fejl hos modparten. Overordnet har kvitteringer og fejlmeddelelser til formål at informere meddelelsesafsender om modtagers reaktion. 1.1 Begreber 1 Nedenstående figur beskriver sammenhængen mellem de anvendte begreber i kvitteringsprincipperne. Begreber og niveauer for kvitteringer UN/CEFACT-niveauer Modtagelseskvittering Syntakskvittering Meddelelse (header-niveau) Strukturkvittering Indholdskvittering 0..* Modtagelsesaccept Dokument Forretningsdokument Meddelelse: Beskriver overordnet information (header-information), der er gældende for alle de underliggende dokumenter, f.eks. afsender og modtager. Dokument: Repeterede oplysninger under meddelelsen, eksempelvis én tidsserie ud af alle meddelelsens tidsserier. 1 Se bilag 1 Syntaks og struktur i EDI-meddelelser for en mere specifik beskrivelse af de enkelte begreber. Dok.løbenr /15
4 1.2 af kvitterings- og fejlmeddelelsesniveauer Herunder specificeres principperne og reglerne for anvendelse af kvitteringer. Principperne er identiske, uanset hvilket dataformat, der er tale om. Derimod er der forskel på detailreglerne inden for XML og EDIFACT. De følgende afsnit er derfor inddelt i de specifikke regler for EDIFACT og XML. Meddelelsestype EDIFACT: Positiv CONTRL XML: Anvendes ikke Modtagelseskvittering Modtagelseskvittering anvendes kun, hvis det er krævet i forretningsprocessen, eller ved kritiske processer. Kvitteringen, som sendes fra EDI-konverteren, benyttes til at bekræfte, at syntaksen er korrekt. Modtagelseskvitteringen kan desuden anvendes i testsituationer. Syntakskvittering Syntakskvittering sendes fra EDI-konverteren og benyttes i de tilfælde, hvor en meddelelse er modtaget, og der er fejl i syntaksen. Meddelelsestype EDIFACT: Negativ CONTRL XML: Acknowledgement document på baggrund af en XMLskema validering. Strukturkvittering (Model Error Report) Strukturkvitteringen er syntaks-neutral og anvendes til validering mod Business Information Model (klassediagram m.m. beskrevet i forretningstransaktionerne). Omhandler f.eks. verificering af korrekt brug af attributter. Strukturkvitteringen skal være på dokumentniveau og refererer til et Business Document (f.eks. aktørplan, regulerkraftbud eller regulerkraftbestilling), hvis det er muligt. Hvor det ikke er muligt at referere til det underliggende dokumentniveau, skal hele meddelelsen afvises. Meddelelsestype EDIFACT: Negativ APERAK XML: Acknowledgement document på baggrund af XMLskema validering. Dok.løbenr /15
5 Indholdskvittering (Processability Error Report) Indholdskvitteringen er syntaks-neutral og anvendes til at kvittere for indholdet på dokumentniveauet, f.eks. validering af målepunkt-id. Indholdet af kvitteringen afhænger af indholdet i den meddelelse, der kvitteres for. Reglerne for hvornår og hvordan indholdskvitteringen skal anvendes er beskrevet i de forretningstransaktioner, hvori den indgår. Meddelelsestype EDIFACT: Negativ APERAK XML: Acknowledgement document Modtagelsesaccept (Acknowledgement of Acceptance) Meddelelsestype Modtagelsesaccepten skal altid gives på dokumentniveau. En modtagelsesaccept betyder, at modtageren har modtaget, valideret (syntaks) og behandlet indholdet positivt. Accepten gælder hele den modtagne meddelelse. EDIFACT: Positiv APERAK XML: Positivt acknowledgement document Forretningsdokument (Business Document) Forretningsdokumentet er et svar på en forespørgende meddelelse og er udformet som et Business Document. Kvitteringen afslutter hele forretningstransaktionen. Meddelelsestype Det er angivet i den aktuelle forretningstransaktion, hvilke Business Documents der anvendes. Dok.løbenr /15
6 1.3 Generiske kvitteringsprincipper Nedenstående figur beskriver de generiske principper for udvekslingen af meddelelser og kvitteringer. Krav og anbefalinger vedrørende de enkelte punkter i figuren fremgår af skemaer i de efterfølgende afsnit. Afsender - Aktør A Modtager - Aktør B Afslut Send meddelelse Pkt. 1. Initierende meddelelse Modtag meddelelse [Ja] Pkt. 7. Overholdes tidsfristen? Kontakt modtager [Nej] Gensend berørte meddelelser Pkt. 8. Undersøg fejl Ignorer meddelse Afslut [Nej] [Ja] Er afsender kendt? Pkt. 2. [Nej] [Ja] Modtag meddelelse Send negativ kvittering [Nej] Syntaks og struktur OK? Pkt. 3. Afslut [Ja] Fejl? Pkt. 6. Modtag meddelelse Send positiv kvittering Gælder kun EDIFACT Positiv kvittering? Pkt. 4. Behandling af meddelelserne Modtag meddelelse Send negativ indholdskvittering [Nej] Er meddelelsesindholdet OK? Afslut [Ja] Pkt. 5. Modtag meddelelse Afsluttende meddelelse Send modtagelsesaccept Afslut Punkt 1 - Generelt Alle kvitteringsforløb indledes med en initierende meddelelse. En meddelelse kan også være en kvittering Punkt 2 - Er afsender kendt? Modtager (Aktør B) skal være i stand til at identificere afsender (Aktør A) og validere vedkommende mod de valide afsendere, der er indgået aftale med. Der kan være to udfald af valideringen: Dok.løbenr /15
7 Afsender (Aktør A) er ikke valid eller ukendt. I disse tilfælde afsluttes processen. Afsender (Aktør A) er valid. I dette tilfælde fortsætter processen. Krav 2.1 Krav 2.2 Modtager skal validere afsender. Afsender og modtager skal føre et opdateret kartotek over valide aktører Punkt 3 Syntaks og struktur OK? Modtager (Aktør B) struktur- og syntaksvaliderer den modtagne meddelelse og dens indhold. Der kan være to udfald af valideringen: Syntaksen og strukturen er ikke korrekt. Modtager (Aktør B) sender en negativ kvittering (syntaks-/strukturkvittering). Denne skal referere til afsenderens (Aktør A) initierende meddelelse, således at vedkommende ikke har problemer med at identificere den fejlagtige meddelelse. Syntaksen og strukturen er korrekt og processen fortsætter. Krav 3.1 Krav 3.2 Krav 3.3 Anbefaling 3.4 Krav 3.5 Modtagers (Aktør B) EDI-system skal være i stand til automatisk at validere en meddelelse ud fra følgende kriterier: 1. Grundlæggende struktur (UN/CEFACTmeddelelsen ved EDIFACT, skema ved XML) 2. Syntaks Ved fejl skal modtager (Aktør B) kunne afsende en negativ kvittering, der refererer til den initierende meddelelse. Afsender af den initierende meddelelse skal løbende undersøge de indkomne negative kvitteringer. Hvis der opstår fejl i syntaks- og strukturvalideringen, skal modtager (Aktør B) svare inden for 5 minutter efter modtagelse. Det er kun tilladt at sende én kvittering pr. meddelelse (positiv eller negativ) Punkt 4 - Positiv kvittering? (gælder kun EDIFACT) Den positive kvittering (modtagelseskvittering) kan anvendes under to omstændigheder: Det kan være under et testforløb, eller hvis det er praksis, at modtagelsesaccepten afsendes meget senere end modtagelseskvitteringen. Der kan være tale om to situationer: Afsender ønsker ikke en modtagelseskvittering. I disse tilfælde må den ikke sendes. Afsender ønsker en modtagelseskvittering. I disse tilfælde skal det fremgå af den initierende meddelelse. Modtagelseskvitteringen skal referere til den initierende meddelelse. Dok.løbenr /15
8 Anbefaling 4.1 Krav 4.2 Krav 4.4 Krav 4.5 Anbefaling 4.2 Modtagelseskvitteringen bør ikke anvendes, med mindre mindst et af følgende forhold gør sig gældende: 1. Afsender og modtager er i et testforløb. 2. Der er stor tidsforskel mellem afsendelse af modtagelseskvitteringen og modtagelsesaccepten. Modtager (Aktør B) skal kunne sende en modtagelseskvittering med reference til den initierende meddelelse. Modtager skal svare med en kvittering inden for 5 minutter. Der skal sendes en kvittering for hver meddelelse. Forespørger Aktør A på en kvittering, bør vedkommende løbende undersøge, om kvitteringen er modtaget Punkt 5 - Behandling af meddelelsen Når meddelelsen er syntaksvalideret, kan EDI-systemet videresende de indeholdte dokumenter til de aktuelle applikationer, hvor meddelelsen og dokumenterne valideres. Afhængigt af EDI-system kan dele af indholdsvalideringen foregå i EDI-konverteren. Der kan være følgende udfald af valideringen: Der er indholdsmæssige fejl. I disse tilfælde skal modtager (Aktør B) fremsende en indholdskvittering, indeholdende en reference til den initierende meddelelse og det specifikke dokument. Det skal fremgå af indholdskvitteringen, hvad fejlen er og hvor i meddelelsen/dokumenterne, fejlen er identificeret. Kvitteringen skal være på et niveau, der gør afsenderen af den initierende meddelelse (Aktør A) i stand til at identificere og udbedre fejlen uden at skulle tage kontakt til afsender af fejlmeddelelsen (Aktør B). Meddelelsen/dokumenterne er blevet valideret positivt (der er ingen indholdsmæssige fejl). Modtager (Aktør B) skal i disse tilfælde sende en positiv indholdskvittering. Applikationen behandler meddelelsen, og kvitteringsudvekslingen afsluttes. Krav 5.1 Modtagers (Aktør B) applikation (eller EDI-system) skal være i stand til automatisk at validere en meddelelse med tilhørende dokumenter ud fra følgende: Krav 5.2 Anbefaling Klassediagrammer og kodelister jf. den gældende forretningstransaktion. 2. Fælles dataformat-regelsæt, der er gældende for hele markedet. Det skal sikre, at afsender altid kan forvente den samme validering. Modtager (Aktør B) skal kunne sende en indholdskvittering på et informationsniveau, der muliggør, at afsender (Aktør A) kan identificere den initierende meddelelse/dokument samt finde årsagen til en eventuel negativ indholdskvittering. Hvis ikke andet fremgår af forretningstransaktionerne for den pågældende meddelelse/dokument, skal modta- Dok.løbenr /15
9 Krav 5.4 ger (Aktør B) svare med en indholdskvittering inden for to timer efter modtagelse. Det er kun tilladt at sende én indholdskvittering pr. dokument Punkt 6 - Fejl? I punkt 6 gennemføres samme procedure som i punkterne 2 til 4. Det vil sige, at den modtagne kvittering (modtagelses-/syntaks-/struktur- /indholdskvittering) eller modtagelsesaccept valideres i forhold til syntaks og struktur. Forskellen i forhold til punkterne 2 til 4 er, at der ikke må sendes en kvittering på en kvittering. Der er følgende muligheder for svar på den initierende meddelelse: Svaret er negativt. Årsagen skal i dette tilfælde undersøges. Den initierende meddelelse er godkendt, og processen fortsætter. Krav 6.1 Der må ikke sendes en kvittering på en kvittering Punkt 7 - Overholdes tidsfristen? Alle meddelelser skal besvares i overensstemmelse med den foreskrevne forretningstransaktion. Det påhviler modtager (Aktør A) at sikre, at alle afsendte meddelelser bliver rettidigt besvaret 2. Der er følgende muligheder: Svar udebliver. Sker dette, skal afsender (Aktør A) kontrollere egne systemer, før der tages kontakt til modtager (Aktør B). Svar kommer rettidigt. Er svaret afgivet inden for tidsfristen, afsluttes forløbet. Anbefaling 7.1 Anbefaling 7.2 Alle afsendte meddelelser bør overvåges. Såfremt et rettidigt svar udebliver, skal den berørte aktør reagere jf. forskrift F, afsnit 8.1. Såfremt tidsfristen ikke overholdes, bør afsender (Aktør A) undersøge egne systemer for fejl, før Aktør B kontaktes Punkt 8 Fejlbehandling Aktør A skal undersøge og udbedre fejlen. Krav 8.1 Fejl skal undersøges og udbedres inden for en tidshorisont, der muliggør rettidig fremsendelse af ændringer. 1.4 EDIFACT-kvittering Overordnet er der to typer af svar på en EDIFACT-meddelelse: 2 Dette kan f.eks. ske i forbindelse med en "timer" i applikationen, som kan trigge tiden fra afsendelse. Dok.løbenr /15
10 1. CONTRL godkender eller afviser hele meddelelsen. Her valideres meddelelsens struktur og syntaks efter gældende regler. 2. APERAK godkender eller afviser på meddelelses- og/eller dokumentniveau. Her valideres meddelelsens forretningsmæssige indhold og underliggende dokumenter ud fra reglerne, der er specificeret i den aktuelle forretningstransaktion. o Såfremt der er fejl i headeren, afvises hele meddelelsen inkl. underliggende dokumenter. o Er der ingen fejl i headeren, skal hvert enkelt dokument besvares. Hvis den modtagne EDIFACT-meddelelse indeholder flere dokumenter (f.eks. tidsserier) er det legalt at sende én APERAK pr. dokument eller at sende én samlet APERAK for alle dokumenter. Dataformatet EDIFACT benytter følgende kvitteringer: Niveau Kvitteringer Dækker følgende punkter fra afsnit 1.3 Meddelelsesniveau CONTRL 1-4 (Modtagelses-/syntaks- /strukturkvittering) Meddelelsesniveau (Indholdskvittering) Dokumentniveau (Indholdskvittering) APERAK CONTRL CONTRL-kvitteringen oplyser, om en given meddelelse er godkendt eller afvist i forhold til den angivne syntaks og struktur. En CONTRL-meddelelse er en standard EDIFACT-meddelelse, der kan kvittere for alle EDIFACT-meddelelser. CONTRL-meddelelsen dannes i konverteren efter modtagelse af en EDIFACTmeddelelse, og CONTRL s er altid ens er opbygget. Kvitteringen kan være positiv eller negativ. De almindelige EDIFACT syntaks-regler er gældende for CONTRL en. Disse er beskrevet i: CONTRL Syntax og Service Report Message Danish Ediel Message Implementation Guide 3. Eksempel på CONTRL: UNA:+.? ' UNB+UNOC: : : : ' UNH+1+CONTRL:2:2:UN:EDIEL2' UCI+M : :14+1' UNT+3+147' UNZ ' 3 Dok.løbenr /15
11 1.4.2 APERAK APERAK-kvitteringen tjener overordnet to formål: 1. At informere afsender om, at bestemmelsesapplikationen har modtaget meddelelsen eller dele heraf og afvist indholdet på grund af fejl. 2. At informere afsender om succesfuld modtagelse og behandling af meddelelsen eller dele heraf. APERAK en fremsendes kun, hvis EDIFACT-syntaksen er valid. APERAK en sendes altid som kvittering på en meddelelse, hvis det fremgår af forretningstransaktionen. Dette gælder, uanset om afsender beder om en APERAK i BGM-segmentets element 4343 i original-meddelelsen. APERAK en dannes delvist i applikationslaget og kan derfor kvittere for selve indholdet i meddelelsen. APERAK en godkender indirekte EDIFACT-syntaksen, idet den kun sendes, såfremt meddelelsen er blevet behandlet i applikationen og derfor er blevet syntaks-valideret positivt. Positive CONTRL s bør derfor ikke anvendes. Som beskrevet i afsnit 1.4 er det valgfrit, om APERAK en svarer på hele meddelelsen med underliggende dokumenter eller hver enkelt dokument i en særskilt APERAK. Der skal kvitteres for ethvert dokument med en APERAK, der, uanset niveau, skal referere til den oprindelse meddelelse. Teksterne, der angiver fejlårsagen i den negative APERAK, skal være klart formulerede og medvirke til en hurtig afklaring af fejlen. De almindelige EDIFACT syntaks-regler er gældende for APERAK en. Disse er beskrevet i: APERAK Application Error and Acknowledgement Message Danish Ediel Message Implementation Guide Negativ APERAK En negativ APERAK afsendes, hvis der er fejl i den modtagne EDIFACTmeddelelse. Der er forskellige måder at kvittere på, afhængigt af om der er fejl i header-sektionen eller på dokumentniveau. Fejl på header-niveau Følgende forhold valideres på header-niveau: At meddelelses-id har ikke været modtaget før. At påkrævede attributter jf. forretningstransaktionen er til stede inkl. UNBattributter. At forretningstransaktionen og versionen er understøttet (UNH/0068). Skal også benyttes, hvis modtager ikke har implementeret forretningsscenariet, der initierer meddelelsen. At implementeringsguidens version (UNH/S009) stemmer overens med forretningstransaktionen. At meddelelsesfunktionen er i overensstemmelse med forretningstransaktionen. 4 Dok.løbenr /15
12 At modtager er i stand til at behandle dokumenter for "Interchange Recipient". At tidszonen er UTC, medmindre andet er blevet bilateralt aftalt. At kodede værdier er indeholdt i liste over accepterede værdier. Ved fejl på header-niveau stopper behandlingen, og den negative APERAK dannes og sendes efter følgende regler: Segmentgruppe. Værdi segment.element BGM Afvist SG3.ERC.C Fejlkoden jf. ovenstående skema Fejlkode skal fremgå af elementet i ERC-segmentet. SG3.FTX.C Tekstbeskrivelse Fejlbeskrivelsen på dansk og engelsk adskilt af tegnet /. Navnet på fejl behæftet element (fx Startdato) SG1.RFF.C Meddelelses-ID Indeholder en reference til meddelelses-id fra den validerede meddelelse. Eksempel på APERAK der oplyser om header-fejl: UNA:+.? ' UNB+UNOC: : : : DK- TIS-MET++1+DK' UNH+1+APERAK:D:96A:UN:E2DK02+DK-BT ' BGM+++27' DTM+137: :203' RFF+ACW:7179' NAD+FR ::9' NAD+DO ::9' ERC+42::ZZZ' FTX+AAO+++Forkert meddelelsesnavn / Wrong Message Name' UNT+9+1' UNZ ' Fejl på dokumentniveau Meddelelser, der indeholder en række repeterede dokumenter, som f.eks. tidsserier i MSCONS og UTILTS, skal der kvitteres for individuelt i form af en samlet APERAK eller en APERAK pr. dokument. Før dokumenterne kan valideres kræves et validt header-niveau. Følgende forhold bliver valideret: At påkrævede attributter jf. forretningstransaktionen er til stede. At kodede værdier er indeholdt i liste over accepterede værdier. At værdier er korrekt formateret jf. implementeringsguiden. At attributter overholder antallet af repetitioner. Uanset antallet af fejl valideres alle dokumenter, og der sendes efterfølgende en APERAK med oplysninger om fejlene efter følgende regler: Dok.løbenr /15
13 Segmentgruppe. segment.element Værdi BGM Godkendt med kommentarer SG1.RFF.C Meddelelses-ID Indeholder en reference til meddelelses-id fra den validerede meddelelse. eller målepunkts- ID SG3.ERC.C Fejlkoden jf. ovenstående skema Fejlkode skal fremgå af elementet i ERC-segmentet. SG3.FTX.C Tekstbeskrivelse Fejlbeskrivelsen på dansk og engelsk adskilt af tegnet /. Navnet på fejlbehæftet element (fx startdato). SG4.RFF.C Transaktions-ID, serie-id Det er angivet i forretningstransaktion, hvad der skal bruges i forhold til den meddelelse, APERAK en vedrører. Modtageren af en negativ APERAK er forpligtet til at reagere på denne Positiv APERAK Accept sendes altid på dokumentniveau og skal overholde følgende regler: Segmentgruppe. Værdi segment.element BGM Godkendt med kommentarer SG1.RFF.C Meddelelses-ID 100 Objektet er godkendt SG3.ERC.C SG3.FTX.C SG4.RFF.C Tekstbeskrivelse Transaktions- ID eller Serie-ID eller Målepunkts-ID n skal kun anvendes, hvis det fremgår af forretningstransaktionen (BT). Såfremt det er tilfældet, skal beskrivelsen være dansk og engelsk adskilt af tegnet /. Det er angivet i forretningstransaktion, hvad der skal bruges i forhold til den meddelelse, APERAK en vedrører. En APERAK kan indeholde både positive og negative svar på dokumenter fra samme meddelelse. 1.5 XML-kvitteringer Dette afsnit indeholder en specifik beskrivelse af reglerne for XML-kvitteringer anvendt i forbindelse med XML-meddelelser. Følgende to kvitteringstyper anvendes til XML-meddelelser: Dok.løbenr /15
14 Niveau Kvitteringer Dækker følgende Meddelelsesniveau (Syntaks-/struktur- /indholdskvittering) Dokumentniveau (Syntaks-/struktur- /indholdskvittering) Acknowledgement Document punkter fra afsnit I XML-konteksten anvendes kun én type kvittering, hvilket afspejler anvendelsen af ETSO s Acknowledgement Document 5. Ved modtagelse valideres meddelelsen i forhold til et XML-skema og videre med indholdsvalidering. Herefter sendes et Acknowledgement Document retur. Dokumentet er positivt eller negativt alt efter udfaldet af valideringen. Alle meddelelser/dokumenter skal således kvitteres af et og kun et Acknowledgement Document, der refererer til den oprindelige meddelelse. Når en aktør kalder en webservice hos Energinet.dk, sker der en validering af den modtagende XML-meddelelse i forhold til det XML-skema, der er relateret til den aktuelle webservice. Valideringen kontrollerer både, at XML-meddelelsen er well-formed, det vil sige, at indholdet overholder W3C s standard for opbygning af XML-meddelelser. Derudover kontrolleres, om de elementer, der indgår i XML-meddelelsen, er tilladte i forhold til XML-skemaet. Desuden kan skemaet definere regler for indholdet af de enkelte elementer. Stemmer XML-indholdet ikke overens med det relaterede XML-skema, returneres en negativ kvittering, og kvitteringsprocessen afsluttes. Hvis skemavalideringen gennemføres uden problemer, fortsættes med en semantikvalidering, som er et resultat af applikationsvalidering. Resultatet af kontrollen kan være en negativ kvittering, hvis applikationskontrollen eller indholdet på anden vis ikke stemmer overens med de opsatte regler for semantikken (jf. valideringstabellen for den aktuelle forretningsproces). Kvitteringen vil på meddelelsesniveauet indeholde overordnet information om meddelelsen (meddelelses-id, afsender og modtager), samt en årsag bestående af en kode samt tilhørende beskrivelse. Ved brug af Acknowledgement Document som positiv kvittering påhæftes årsagen med årsagskode A01 (Message fully accepted). Kvitteringen tjener således tre formål: At informere afsender om, at meddelelsens indhold er afvist på grund af fejl i syntaksen (meddelelsesniveau). At informere afsender om succesfuld modtagelse og om, at behandling af hele meddelelsen fortsætter (meddelelses- og dokumentniveau). 5 Dok.løbenr /15
15 At informere afsender om, at bestemmelsesapplikation har modtaget meddelelsen, eller dele heraf, og at oplyse om mulige fejl i indholdet. Dok.løbenr /15
Bilagsrapport 2: Kvitteringsprincipper og -regler 31439-10. Forskrift F1: EDI-kommunikation med DataHub'en i elmarkedet. Træder i kraft den 1.3.
Forskrift F1: EDI-kommunikation med DataHub'en i elmarkedet Bilagsrapport 2: Kvitteringsprincipper og -regler Marts 2011 Version 2.0 Træder i kraft den 1.3.2013 1.0 2.0 16-6-2010 24-6-2010 27-6-2010 DATE
Læs mereOversættelse til dansk af APERAK. Application Error and Acknowledgement Message. Dank EDI Message Implementation Guide
Oversættelse til dansk af APERAK Application Error and Acknowledgement Message Dank EDI Message Implementation Guide Status: Dansk oversættelse Version: 3 Release: 1 Dato: Januar 2009 Indledning og generelle
Læs mere14. 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 mereEdiDKgas Implementeringsguide
EdiDKgas Implementeringsguide til skift af gasleverandør Status: Til implementering Version: 1.4 Revision: Dato: 9. november 2006 Dokument: 365-v2-EdiDKgas_1_4_- _ARBEJDSUDKAST.DOC 2 Indholdsfortegnelse
Læs mereEDI-guide for Regres Bilag 2 Ajourføringshistorik
EDI-guide for Regres Bilag 2 Ajourføringshistorik Version 3.3 Final Dokumentoplysninger Titel: Projekt: EDI-guide for Regres EDI kontorets branchekoordinerede dataudveksling Forfatter: Bidragsydere til
Læs mereSyntaks og struktur i EDI-meddelelser
Forskrift F: EDI-kommunikation Bilagsrapport 1: Syntaks og struktur i EDI-meddelelser November 2011 Rev. 2 Dok.løbenr. 79520-07_v2 1/15 Indholdsfortegnelse 1. EDIFACT-syntaks og -struktur... 3 1.1 EDIFACT-struktur
Læs mereMetodeanmeldelse af markedsforskrift F1 - EDIkommunikation
Til Energitilsynet Metodeanmeldelse af markedsforskrift F1 - EDIkommunikation med DataHub'en i elmarkedet 31. januar 2012 HBK/LRP Energinet.dk skal i følge Energistyrelsens bekendtgørelse nr. 1085 af 20.
Læs mereInternt notat 202542 2
Internt notat Arbejdspapir Systemdesign Dato: 6. september 2004 Sagsnr.: 5564 Dok.nr.: 202542 v2 Reference: PMO/PMO Beskrivelse af Eltra XML-struktur 1. Indhold Dette er beskrivelsen af den XML-struktur,
Læs mereMeddelelses Implementerings Guide (MIG) for CONTRL meddelelsen
Meddelelses Implementerings Guide (MIG) for CONTRL meddelelsen Ver 2.0 01.12.1996 0 Indhold 0 Indhold 2 1 Forord 3 2. CONTRL meddelelsen 4 2.1 Funktion 4 2.2 Principper 4 2.2.1 MedCom specifikke principper
Læs mereBilagsrapport 4: DataHub - Webservice interface Forskrift F1: EDI-kommunikation med DataHub'en i elmarkedet. Træder i kraft den 1.3.
Forskrift F1: EDI-kommunikation med DataHub'en i elmarkedet Bilagsrapport 4: DataHub - Webservice interface Februar 2011 Version 2.0 Træder i kraft den 1.3.2013 1.0 2.0 16-6-2010 24-6-2010 29-6-2010 DATE
Læs mereIndledning... 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 mereForretningsprocesser for EDIkommunikation
Forretningsprocesser for EDIkommunikation på gasmarkedet Bestemmelser om EDI-kommunikation mellem: -Distributionsselskab og Gasleverandør -Distributionsselskab og Transmissionsselskab I forbindelse med
Læs mereIndholdsfortegnelse. 1. Formål Referencer... 4
Pseudo-forskrift F: EDI kommunikation i elmarkedet Bilagsrapport 1: Syntaks og struktur i EDIFACT og XML meddelelser Marts 2011 Version 2.0 1.0 2.0 16-6-2010 24-6-2010 27-6-2010 DATE BOO MBN JHH NAME 25-2-2011
Læs mereOversættelse til dansk af UTILMD. Utility Master Data Message. Dansk EDI Message Implementation Guide
Oversættelse til dansk af UTILMD Utility Master Data Message Dansk EDI Message Implementation Guide Status: Dansk oversættelse Version: 3 Release: Dato: Januar 009 Indledning og generelle principper. Indledning
Læs mereForskrift F: EDI-kommunikation
Forskrift F: EDI-kommunikation September 2009 Rev. 2 Jan. 2007 Feb. 2007 Apr. 2007 Apr. 2007 DATE CCO HEP CCO LSO NAME Aug. 2009 Sep. 2009 Sep. 2009 Sep. 2009 DATE CCO HEP CCO LSO NAME REV. DESCRIPTION
Læs mereDen Gode VANSEnvelope. MedCom
Den Gode VANSEnvelope MedCom Den Gode VANSEnvelope Jacob Glasdam Bolette Friis Jensen KMD Erik Jacobsen Multimed Ole Vilstrup CSC Thomas Jørgensen Evenex Dorthe Skou Lassen MedCom Gitte Fleckner Henriksen
Læs mereEDI-kommunikation med DataHub i elmarkedet
Forskrift F1: EDI-kommunikation med DataHub i elmarkedet November 2013 Høringsudgave Version 4.0 Træder i kraft den 1.10.2014 Nov. 2013 Nov. 2013 Nov. 2013 Nov. 2013 DATE CCO HBK LRO LRO NAME REV. DESCRIPTION
Læs mereEDI-guide for CONTRL. Version 1.0 Final
EDI-guide for ONTRL Version 1.0 Final EDI-guide ONTRL, bilag 1 - EDIFAT Dokumentoplysninger Titel: Projekt: EDI-guide for EDIFAT og ONTRL EDI kontorets branchekoordinerede dataudveksling Forfatter: Bidragsydere
Læs mereVejledning og feltværdier
Vejledning og feltværdier Den Gode VANSEnvelope - Bilag MedCom Vejledning og feltværdier: Den Gode VANSEnvelope - Bilag Jacob Glasdam, MedCom udgivelsesdato 10. marts 2011 Revisionshistorie Revision 1.1
Læs mereForskrift F: EDI-kommunikation
Forskrift F: EDI-kommunikation September 2009 Rev. 2 Jan. 2007 Feb. 2007 Apr. 2007 Apr. 2007 DATE CCO HEP CCO LSO NAME Aug. 2009 Sep. 2009 Sep. 2009 Sep. 2009 DATE CCO HEP CCO LSO NAME REV. DESCRIPTION
Læs mereTeknisk Implementerings Guide UN/EDIFACT & UNA/UNB-UNZ
Teknisk Implementerings Guide UN/EDIFACT & UNA/UNB-UNZ MedCom Ver. 2.0 01.12.1996 0 Indhold 0 Indhold 3 1 Forord 4 2. UN/EDIFACT 5 2.1 Definition 5 2.2 EDIFACT directories 6 2.3 EDIFACT-syntaks 6 2.3.1
Læs mereUdgivelsen er beskyttet af Creative Commons license, Navngivning 2.5
OIOUBL Guideline OIOUBL Bekræftelse UBL 2.0 Response G35 Version 1.1 Udgivelsen er beskyttet af Creative Commons license, Navngivning 2.5 Kolofon Kontakt: IT- & Telestyrelsen E-mail: oioubl@itst.dk OIOUBL
Læs mereOversættelse til dansk af MSCONS Metered Services Consumption rapport. Dansk "EDI Message Implementation Guide
Oversættelse til dansk af MSCONS Metered Services Consumption rapport Dansk "EDI Message Implementation Guide Status: Dansk oversættelse Version: 3 Release: Dato: Januar 2009 Indledning og generelle principper.
Læs mereMT 940 Customer Statement Message ( i FINSTA format)
MT 940 Message Side 1 af 9 MT 940 er en SWIFT meddelelse fra udenlandske pengeinstitutter. Et FINSTA dokument kan indeholde flere MT 940/MT950 meddelelser. FINSTA-dokumentet er dermed information til en
Læs mereEDI-guide for Regres. Version 3.3 draft F
EDI-guide for Regres Version 3.3 draft F Dokumentoplysninger Titel: Projekt: EDI-guide for Regres EDI kontorets branchekoordinerede dataudveksling Forfatter: Bidragsydere til dokumentet: Godkendt af: Dokumentansvarlig:
Læs mere15. FINANSIEL AFLYSNINGSMEDDELELSE (FINCAN)
27.06.2001 15. FINANSIEL AFLYSNINGSMEDDELELSE (FINCAN) Indledning... 2 Formål... 2 Dansk tolkning... 2 UNH... 5 BGM... 7 DTM... 9 Segmentgruppe 4 (niveau B)... 11 LIN... 12 Segmentgruppe 5 (niveau B)...
Læs mereMetodeanmeldelse af markedsforskrift F1 EDIkommunikation
Til Energitilsynet Metodeanmeldelse af markedsforskrift F1 EDIkommunikation med DataHub i elmarkedet Juni 2014 HBK/ADA Energinet.dk skal ifølge Energistyrelsens bekendtgørelse nr. 1085 af 20. september
Læs mereDigital post Snitflader Bilag B - Afsendelse og modtagelse af meddelelser via S/MIME Version 6.3
Digital post Snitflader Bilag B - Afsendelse og modtagelse af meddelelser via S/MIME Version 6.3 1 Indholdsfortegnelse B.1. INTRODUKTION... 4 B.1.1. HENVISNINGER... 4 B.1.2. INTEGRATION MED EKSISTERENDE
Læs mereDen Gode VANSEnvelope, Scenariebeskrivelser. MedCom
Den Gode VANSEnvelope, Scenariebeskrivelser MedCom Den Gode VANSEnvelope, Scenariebeskrivelser Jacob Glasdam, MedCom Ulrik Schønnemann, MedWare udgivelsesdato 19. november 2010 Revisionshistorie Revision
Læs mereFESD-standardiseringsgruppen Att: Palle Aagaard IT- og Telestyrelsen IT-strategisk kontor Holsteinsgade 63 2100 København Ø
FESD-standardiseringsgruppen Att: Palle Aagaard IT- og Telestyrelsen IT-strategisk kontor Holsteinsgade 63 2100 København Ø Høringssvar vedr. FESD GIS-integrationsmodel version 2.0 Geodata Danmark har
Læs mereKvitteringspolitik. Syntaks- og kommunikations-regler. Aaaaaa Aaaaaaa. Regler for beskedforsendelse og eventuel kvittering
Syntaks- og kommunikations-regler Aaaaaa Aaaaaaa Kvitteringspolitik Regler for beskedforsendelse og eventuel kvittering Michael Johansen, Standarder, test & certificering mjo@medcom.dk Syntaks- og kommunikations-regler
Læs mereBilag A til Aftale om modtagelse af elektroniske fakturaer og samtalespecifikationer
14. maj 2008 Bilag A til Aftale om modtagelse af elektroniske fakturaer og samtalespecifikationer STANDARDVILKÅR for EDI EDIFACT D 96A Disse vilkår om elektronisk dataudveksling (EDI) finder anvendelse
Læs mere13. BANK-STATUSMEDDELELSE (BANSTA)
01.03.2001 13. BANK-STATUSMEDDELELSE (BANSTA) Indledning... 2 Formål... 2 Dansk tolkning... 2 UNH... 4 BGM... 6 DTM... 8 Segmentgruppe 1 (niveau A)... 11 RFF... 12 DTM... 14 Segmentgruppe 3 (niveau A)...
Læs mereDKAL 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 mereOIOUBL Guideline. OIOUBL Profiler. UBL 2.0 Profiles (UTS) Appendiks til G26. Version 1.3
OIOUBL Guideline OIOUBL Profiler UBL 2.0 Profiles (UTS) Appendiks til G26 Version 1.3 Udgivelsen er beskyttet af Creative Commons license, Navngivning 2.5 OIOUBL Profiler (UTS) Version 1.3 Side 2 Kolofon
Læs merePlanhåndtering i det danske elmarked
Forskrift F: EDI-kommunikation BS-dokument: Planhåndtering i det danske elmarked Fælles forretningsprocesser mellem balanceansvarlige aktører og Energinet.dk jævnfør forskrift C3: "Planhåndtering - daglige
Læs mereNemKonto. 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 mereITD ecmr WEB Services. Af Allan Wisborg, IT Udvikler
Af Allan Wisborg, IT Udvikler Til løsningen ecmr Det elektroniske fragtbrev udbydes en række offentlige WEB services. Dette er beskrivelsen af disse services og hvorledes de anvendes. 21. December 2015
Læs mereDriftsudfordringer. DataHub den 21. april 2015. Markedsdrift El
Driftsudfordringer den 2 april 2015 Markedsdrift El 1 Agenda Vi arbejder på nuværende tidspunkt med flere betydelige ITudfordringer: modtager meddelelser der ikke behandles/ viderefremsendes af Datahub
Læs mereUdgivelsen 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 mereDansk Ediel implementeringsguide til skift af leverandør
Dansk Ediel implementeringsguide til skift af leverandør 132881v1 IG-status: Til brug IG-version: 1.0 IG-revision: A IG-dato: 30. juni 2002 Versioner Version Revision Dato Afsnit Bemærkning 1.0 A 2002-06-30
Læs mereVejledning VEDRØRENDE GENERELLE BETINGELSER FOR ANVENDELSE AF NEMHANDEL. Februar 2015 (VERSION 1.4 AF FEBRUAR 2015)
Vejledning Februar 2015 VEDRØRENDE GENERELLE BETINGELSER FOR ANVENDELSE AF NEMHANDEL (VERSION 1.4 AF FEBRUAR 2015) Side 2 af 12 Indholdsfortegnelse: Indholdsfortegnelse:... 2 INDLEDNING... 4 GENERELLE
Læs mere2. BRUGEN AF EDIFACT. Indholdsfortegnelse 05.05.2000
05.05.2000 2. BRUGEN AF EDIFACT Indholdsfortegnelse Hvad er EDI og EDIFACT... 2 Organisation i standardiseringsarbejdet... 3 Strukturen i EDIFACT... 3 Konvoluteksempel... 4 Logisk opbygning (strukturen)...
Læs mere0.9 19-09-2012 DAVAR Omdøbt til SagDokumentFormat. Attention er skilt ud i et selvstændigt format, AttentionFormat.
Specifikation 19. september 2012 DAVAR J.nr. 2012-6211-281 Sagdokumentformat Versionshistorik Version Dato Initialer Noter 0.7 15-06-2012 DAVAR Høringsversion. Indsat MeddelelseAttention. 0.9 19-09-2012
Læs mereForretningsprocesser for EDIkommunikation
Forretningsprocesser for EDIkommunikation på gasmarkedet Bestemmelser om EDI-kommunikation mellem: - Distributionsselskab og Gasleverandør - Distributionsselskab og Transmissionsselskab i forbindelse med
Læs mereBeskrivelse af fejlkoder. Version 1.0,
Beskrivelse af fejlkoder KMD Indkomst Opgørelser (P13-5) WEBService IndkomstEnkeltForespoergsel og MQService IndkomstMasseForespoergsel Version 1.0, 20.02.2017 Indholdsfortegnelse 1. Versionsoversigt...
Læs mereBeskrivelse af fejlkoder. Version 7.0, KMD Indkomst WEBService IndkomstEnkeltForespoergsel og MQService IndkomstMasseForespoergsel
Beskrivelse af fejlkoder KMD Indkomst WEBService IndkomstEnkeltForespoergsel og MQService IndkomstMasseForespoergsel Version 7.0, 15.04.2016 Senest gemt den 31-08-2016 11:40, ID190-D Indkomstgrænseflade_P13_5
Læs mereUdgivelsen er beskyttet af Creative Commons license, Navngivning 2.5
OIOUBL Guideline OIOUBL Udvidelse UBL 2.0 Extension G33 Version 1.2 Udgivelsen er beskyttet af Creative Commons license, Navngivning 2.5 OIOUBL Udvidelse Version 1.2 Side 1 Kolofon Kontakt: IT- & Telestyrelsen
Læs mereForretningsprocesser for det danske elmarked. (EDI guide - BRS'ere)
Forretningsprocesser for det danske elmarked (EDI guide - BRS'ere) Marts 2011 2012 Version 2.0 2.1 1.0 4-6-2010 24-6-2010 30-6-2010 DATE BOO MBN JHH NAME 2.0 2.1 02-2012 03-2 02-2011 02-2011 03-2011 DATE
Læs mereOIOUBL Guideline. Profiler i OIOUBL bekendtgørelsen Version 1.0. Udgivelsen er beskyttet af Creative Commons license, Navngivning 2.
OIOUBL Guideline Profiler i OIOUBL bekendtgørelsen Version 1.0 Udgivelsen er beskyttet af Creative Commons license, Navngivning 2.5 OIOUBL Profiler Version 1.0 Side 1 Kolofon Kontakt: IT- og Telestyrelsen
Læs mereDataHub Dialogmøde. 6. august 2012
DataHub Dialogmøde 6. august 2012 Dagsorden 1. Overordnet status 2. Aktørtest 3. Krydsende processer 4. Solceller 5. Dialog og Eventuelt DataHub planlægningsmøde 6. juni 2012 2 Status Udviklingen af DataHub
Læs mereDigital post Snitflader Bilag A5 - REST HTTP returkoder Version 6.3
Digital post Snitflader Bilag A5 - REST HTTP returkoder Version 6.3 1 Indholdsfortegnelse INDHOLDSFORTEGNELSE 2 A5.1 INTRODUKTION 4 A5.2 HTTP RETURKODER 4 A5.3 DIGITAL POST FEJLKODER 7 A5.3.1 DIGITAL POST
Læs mereFordeling af journalnotater og dokumenter Udkast til løsningsmodel. Marts 2014
Fordeling af journalnotater og dokumenter Udkast til løsningsmodel Marts 2014 1 Indledning Denne præsentation beskriver, på et overordnet plan, følgende områder i forhold til en fremtidig fordelingsmekanisme,
Læs mereIntroduktion til MeMo
Introduktion til MeMo 1. februar 2019 CIU I forbindelse med Digitaliseringsstyrelsens udbud af Næste generation Digital Post løsningen (NgDP) er der udviklet en ny model for udveksling af digitale postmeddelelser,
Læs mereEDI-kommunikation med DataHub i elmarkedet
Forskrift F1: EDI-kommunikation med DataHub i elmarkedet Maj 2015 Version 4.5 Træder i kraft 1. april 2016 Maj 2015 Maj 2015 Maj 2015 DATE CCO PHQ SHR NAME REV. DESCRIPTION PREPARED REVIEWED APPROVED 15/02670-2
Læs mereDansk Ediel implementeringsguide til skift af leverandør
Dansk Ediel implementeringsguide til skift af leverandør Word 125757v8 PDF: 137346 IG-status: Til brug IG-version: 1.0 IG-revision: B IG-dato: 3. september 2002 Versioner Version Revision Dato Afsnit Bemærkning
Læs mereAFGØRELSE VEDRØRENDE SKIFT AF BA- LANCEANSVARLIG AKTØR
AFGØRELSE VEDRØRENDE SKIFT AF BA- LANCEANSVARLIG AKTØR 14. januar 2016 Engros & Transmission 15/09396-1 PCO SAGSFREMSTILLING BAGGRUND 1. I denne sag skal Sekretariatet for Energitilsynet (SET) tage stilling
Læs mereFælles Fallback-procedure for EDI-meddelelser
Fælles Fallback-procedure for EDI-meddelelser Resumé: Dokumentet beskriver, hvordan transmission og distributionsselskaberne håndterer situationer, hvor der ikke kan sendes korrekte måledata til tiden.
Læs mereSEPA Direct Debit. Vejledning for tilbageførsel. privatbetalinger (CORE) Nets Denmark A/S Lautrupbjerg 10 P.O. 500 DK-2750 Ballerup
SEPA Direct Debit Vejledning for tilbageførsel af uautoriserede privatbetalinger (CORE) Nets Denmark A/S Lautrupbjerg 10 P.O. 500 DK-2750 Ballerup Indholdsfortegnelse 1 Indledning... 3 1.1 Tidsfrister...3
Læs mereDKAL 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 mere1. FORORD TIL BRUGERVEJLEDNING FOR FLYTNING AF LD-KONTI... 3
Version 1.1.1 Oktober 2014 INDHOLDSFORTEGNELSE 1. FORORD TIL BRUGERVEJLEDNING FOR FLYTNING AF LD-KONTI... 3 2. ÅBNINGSSKÆRMBILLEDET, START AF DATABEHANDLING... 4 2.1. ADGANGSKONTROL... 4 2.2. INDBAKKEN...
Læs mereRegler for CTF. (Energinet.dk Gastransmissions regler for Capacity Transfer Facility)
Regler for CTF (Energinet.dk Gastransmissions regler for Capacity Transfer Facility) VILKÅR OG BETINGELSER FOR BILATERAL HANDEL MED KAPACITET I TRANSMISSIONSSYSTEMET Version 5.2 Juni 2010 Regler for CTF,
Læs mereTilslutningsprøvedrejebog til NemKonto for Private Udbetalere. Version 1. december 2007
Version 1. december 2007 Indholdsfortegnelse 1 Indledning...3 1.1 Formål med drejebogen... 3 1.2 Mål med tilslutningsprøven... 3 2 Overordnet beskrivelse af tilslutningsprøven...4 2.1 Beskrivelse af hvad
Læs mereUdgivelsen er beskyttet af Creative Commons license, Navngivning 2.5
OIOUBL Guideline OIOUBL Kontakt UBL 2.0 Contact G34 Version 1.2 Udgivelsen er beskyttet af Creative Commons license, Navngivning 2.5 OUOUBL Kontakt Version 1.2 Side 1 Kolofon Kontakt: IT- & Telestyrelsen
Læs mereBILAG 9. DataHub- og markedsrapportering. 1. Markedsoverblik. 1.1 Leverandørskift. 1.2 Fejlagtige leverandørskift. Direktørgruppen. 14.
BILAG 9 Til Direktørgruppen DataHub- og markedsrapportering 14. oktober 2014 Dette notat udgør statusrapporteringen for DataHub drift til Direktørgruppen i oktober 2014. Notatet indeholder et generelt
Læs mereTilslutning 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 mereEPJ-Syd SPØRGSMÅL OG SVAR I PRÆKVALIFIKATIONSFASEN FOR UDBUD VEDR. EPJ/PAS
SPØRGSMÅL OG SVAR I PRÆKVALIFIKATIONSFASEN FOR UDBUD VEDR. EPJ/PAS 1. Spørgsmål & Svar i prækvalifikationsfasen... 1 1.Spørgsmål & Svar i prækvalifikationsfasen Ordregiver har modtaget nedenstående spørgsmål
Læs mereUnderbilag 2O Beskedkuvert Version 2.0
Underbilag 2O Beskedkuvert Version 2.0 Indhold Indledning... 34 2 Beskedkuvertens struktur... 34 3 Indhold af Beskedkuverten... 34 3. Overordnet indhold... 45 3.2 Detaljeret indhold af Beskedkuverten...
Læs mereElektronisk signering manual 1.3
Estatetool ApS support@systembolig.dk +45 70 20 11 90 ELEKTRONISK SIGNERING Elektronisk signering manual 1.3 Hvem har min. adgang til at styre denne funktion: Projektadmin Hvem har min. adgang til at benytte
Læs mereAO 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 mereOIOUBL 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 mereUdkast til dataudveksling med elleverandører og andre tredjeparter via kundestyret dataadgang
Udkast til dataudveksling med elleverandører og andre tredjeparter via kundestyret dataadgang 29.04.2015 USS/XSTJ Version 1.3 1. Indledning... 2 2. Proces for kundestyret dataadgang... 2 2.1 Fuldmagtsgivning
Læs mereFORSLAG TIL MASSEAFSENDELSE
FORSLAG TIL MASSEAFSENDELSE Digital Post og Fjernprint 2015-03-11 Dagsorden 1. Velkomst 2. Nuværende OIO-rest 3. Udfordringer 4. Afrunding Nuværende OIO-REST løsning Digital post De nuværende Digital Post
Læs mereFællesoffentlig beskedmodel version 1.0
Side: 1 Fællesoffentlig beskedmodel version 1.0 Dokumentet indeholder dels en informationsmodel for hændelsesbeskeden og dens miljø, dels en generisk datamodel for hændelsesbeskeden, som kan danne en fælles
Læs mereEPJ-Syd SPØRGSMÅL OG SVAR I PRÆKVALIFIKATIONSFASEN FOR UDBUD VEDR. EPJ/PAS
SPØRGSMÅL OG SVAR I PRÆKVALIFIKATIONSFASEN FOR UDBUD VEDR. EPJ/PAS 1. Spørgsmål & Svar i prækvalifikationsfasen... 1 1.Spørgsmål & Svar i prækvalifikationsfasen Ordregiver har modtaget nedenstående spørgsmål
Læs mereEDI kvalitetssikring af den elektroniske kommunikation
EDI kvalitetssikring af den elektroniske kommunikation Kommune Lægepraksis Hospital Udkastet er udarbejdet af; Thomas Koldkur Bitsch Konsulent Kvalitet og Sundhedsdata, Strategisk kvalitet Skottenborg
Læs mereÆndring i vilkår for skift af elleverandør for elproduktionsanlæg
Ændring i vilkår for skift af elleverandør for elproduktionsanlæg FebruarJuni 20110 Version 21.0 1.0 2.0 6-6-2010 7-6-2010 30-6-2010 DATE LRO/MAA MBN JHH NAME 1-3-2011 1-3-2011 1-3-2011 DATE LRO ADA LRP
Læs mereVejledning til anvendelse af MeMo og SMTP. Næste generation Digital Post Maj 2018, version 0.9
Vejledning til anvendelse af MeMo og SMTP Næste generation Digital Post Maj 2018, version 0.9 Indhold Indhold 2 1 Introduktion 3 1.1 Præciseringer 3 1.2 Terminologi 3 2 Anvendelse af SMTP-felter 5 3 Anvendelse
Læs mereXML webservice for pensionsordninger. Version 1.0 Draft A
XML webservice for pensionsordninger Version 1.0 Draft A Dokumentoplysninger Titel: Projekt: Webservice for pensionsordninger EDI kontorets branchekoordinerede dataudveksling Forfatter: Bidragsydere til
Læs mereDKAL Snitflader REST HTTP returkoder
DKAL Snitflader REST HTTP returkoder 1 Indholdsfortegnelse INDHOLDSFORTEGNELSE 2 A5.1 INTRODUKTION 3 A5.2 HTTP RETURKODER 3 A5.3 DKAL FEJLKODER 6 A5.3.1 DKAL XML FEJLFORMAT 7 Bilag A5: REST HTTP returkoder
Læs mereEDI-guide for Regres. Version 3.2
EDI-guide for Regres Version 3.2 Dokumentoplysninger Titel: Projekt: EDI-guide for Regres EDI kontorets branchekoordinerede dataudveksling Forfatter: Bidragsydere til dokumentet: Godkendt af: Dokumentansvarlig:
Læs mereForretningsprocesser for EDIkommunikation
Forretningsprocesser for EDIkommunikation på gasmarkedet Bestemmelser om EDI-kommunikation mellem: -Distributionsselskab og Gasleverandør I forbindelse med Leverandørskift, Flytning og forbrugsopgørelser
Læs mereTeknisk Dokumentation
Sundhedsstyrelsens E2B Bivirkningswebservice Teknisk Dokumentation Side 1 af 8 Indhold Indledning... 3 Terminologi... 3 Arkitektur... 4 Web Service Snitflade... 4 Valideringsfejl... 5 Success... 5 E2B...
Læs mereEDI-guide for Panthaverdeklarationer. Version 5.2 final
EDI-guide for Panthaverdeklarationer Version 5.2 final Dokumentoplysninger Titel: Projekt: EDI-guide for panthaverdeklarationer EDI kontorets branchekoordinerede dataudveksling Forfatter: Bidragsydere
Læs mereAfsnittet er temmelig teoretisk. Er du mere til det praktiske, går du blot til det næste afsnit.
Afsnittet er temmelig teoretisk. Er du mere til det praktiske, går du blot til det næste afsnit. XML (eng. extensible Markup Language) XML er en måde at strukturere data på i tekstform. På samme måde som
Læs mereIntroduktion til eblisten... 2. Opret brugerkonto... 2. Abonnementtyper... 2. Kom godt i gang med eblisten... 3. Start eblisten...
Indholdsfortegnelse Introduktion til eblisten... 2 Opret brugerkonto... 2 Abonnementtyper... 2 Kom godt i gang med eblisten... 3 Start eblisten... 3 Send dokumenter med eblisten... 4 Udgående dokumenter...
Læs mere1 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 mereImplementeringsvejledning 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 mereSEPA 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 mereReducér risikoen for falske mails
Reducér risikoen for falske mails Center for Cybersikkerhed 1 November 2017 Indledning Center for Cybersikkerhed oplever i stigende grad, at danske myndigheder og virksomheder udsættes for cyberangreb.
Læs mereDigital 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 mereFejlbehæ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 mereDrejebog for tilslutningsprøve OIO sag
Drejebog for tilslutningsprøve OIO sag Indholdsfortegnelse Ændringer i forhold til forrige version... 3 1 Indledning... 4 1.1 Formål med drejebogen... 4 1.2 Mål med tilslutningsprøven... 4 2 Overordnet
Læs mereDen Gode LÆ-blanket Webservice (DGLÆ:WS)
Den Gode LÆ-blanket Webservice (DGLÆ:WS) MedCom arbejdspapir. Ver 0.2 18-06-2006. HVO Den Gode LÆ-blanket Webservice (DGLÆ:WS)...1 Del A: Formål og funktionalitet...2 Formål (=Usecase)...2 Sagsgangen i
Læs mereIndholdsfortegnelse. Systembeskrivelse kapitel 8 Administrationsdatabase
Indholdsfortegnelse 5. Administrationsdatabase... 2 5.1 Metadata... 2 5.2 Administrationsdata... 3 5.2.1 Indstillingsmuligheder... 3 5.2.2 Webside... 4 5.2.3 Klikafgift (Udgået)... 4 5.2.4 Modtageboks...
Læs mereMØDE OM INTEGRATION GENNEM ØKONOMI I RAMMEARKITEKTUREN 27/8-2015
MØDE OM INTEGRATION GENNEM ØKONOMI I RAMMEARKITEKTUREN 27/8-2015 Introduktion ERP-leverandører har været med i afklarings- og specificeringsforløb siden 2013. Der vil være gentagelser og opsummeringer
Læs mereEDIFACT Kursus. Mandag den 16. juni 2014 hos MedCom
EDIFACT Kursus Mandag den 16. juni 2014 hos MedCom Program 1. Velkomst, Præsentationsrunde og programgennemgang 2. MedCom meddelelser generelt 3. EDIFACT gennemgang Syntaksregler Dokumentation 12:00 Frokost
Læs mereEDI-guide for Opsigelser. Version 5.7 draft G
EDI-guide for Opsigelser Version 5.7 draft G Dokumentoplysninger Titel: Projekt: EDI-guide for Opsigelser EDI kontorets branchekoordinerede dataudveksling Forfatter: Bidragsydere til dokumentet: Godkendt
Læs mereKRAVSPECIFIKATION for underretningsstatistik
Ankestyrelsen Data og Analyse Den 4. marts 2014 KRAVSPECIFIKATION for underretningsstatistik Kontakt: Jesper Nyholm, Statistiksektionen, jny@ast.dk, tlf. 61 89 75 07 1 af 12 1. Indledning I denne kravspecifikation
Læs mere