FAQ vedrørende overgang fra NemHandel til eDelivery

Validering af OIOUBL 3.0

Spørgsmål: Der valideres ikke længere i kommunikationslaget?

Svar: Nemhandel validerer fortsat både schema og schematron i både afsenders og modtagers adgangspunkt. Dele af valideringen er løftet ud af transportprotokollen, for at sikre at modtager kan kvittere for modtagelsen indenfor protokollens timeout-vindue. Modtager validerer således fortsat dokumentets schema (”er det overhovedet velformet XML i et genkendeligt format?”) i kommunikationslaget. Øvrige valideringer (schematron-valideringer) foregår asynkront, efter modtagelse, men fortsat i adgangspunktet. Hvis schema-valideringen fejler, afbryder det modtagende adgangspunkt AS4-overførslen med en fejlkode. Hvis schematronvalideringen fejler, sender modtagende adgangspunkt en Application Response tilbage med den fundne valideringsfejl, men denne sendes som en ny AS4 kommunikation. Begrundelsen for opdelingen imellem schema- og schematron-valideringer er at schematron-valideringer kan tage væsentligt længere tid end schema-valideringen, hvilket ville betyde at vi skulle bruge en væsentligt længere timeout på AS4 kanalen før afsender giver op og lukker kanalen med manglende kvittering. En afvisning af dokumentet på grund af schematronfejl er fortsat at regne som en teknisk afvisning, ikke en kommerciel.

Spørgsmål: Alle afsendere er pålagt validering med XSD og XSLT?

Svar: Korrekt. Dette er uændret fra de nuværende krav.

Spørgsmål: Alle afsendere skal være registreret med modtagelse af ApplicationResponse (teknisk validering) sådan at evt. invalide filer modtaget ved C3 kan afvises automatisk? (På denne måde havner vi ikke i Peppols problematik med afsendelse af invalide filer). 

Svar: Alle afsendere skal være registreret til at modtage Application Response, til modtagelse af tekniske afvisninger. Derudover forventes OIOUBL 3 at være baseret på et princip om at alle profiler indeholder mulighed for eksplicitte kommercielle svar – fakturasvar, ordrebekræftelser, osv. Så generelt må man forvente at afsendere af dokumenter skal registreres som modtagere af de tilsvarende bekræftelser.

Spørgsmål: I hvor høj grad forventes kravene til OIOUBL 3.0 at lægge sig op ad de eksisterende CIUS-regler for Peppol BIS 3.0, som anvendt i NemHandel i dag?

Svar: OIOUBL 3 forventes at ligge nærmere Peppol end den eksisterende OIOUBL. Men der vil fortsat være forskelle – OIOUBL har f.eks. tradition for strammere syntaksvalidering end Peppol, og en tradition regner vi med at videreføre.

Spørgsmål: Hvornår offentliggøres OIOUBL v3.0 CIUS'en? 

Svar: Udkastet til de større planlagte ændringer i faktura og kreditnota forventes offentliggjort i løbet af sommeren. Release candidates følger efter den offentlige høring af samme.

Spørgsmål: Vil Nemhandel eDelivery kun køre med OIOUBL 3.0? 

Svar: De eksisterende OIOUBL profiler videreføres som udgangspunkt. OIOUBL 3 er en kompatibilitets-brydende opdatering af OIOUBL dokumentstandarden og er formelt og teknologisk uafhængig af overgangen til Nemhandel eDelivery. OIOUBL 3 indføres efter den eksisterende migrationspolitik for kompatibilitetsbrydende ændringer af OIOUBL dokumenter.

Spørgsmål: Hvis man som ERP system ikke selv er C2 og C3  men blot anvender en service leverandør - er der så noget I udstiller så man "indenfor ERP" kan konvertere mellem OIOUBL og PEPPOL? 

Svar: Ikke endnu. OIOUBL 3 forventes at adressere konvertering imellem OIOUBL og Peppol formaterne. I forhold til transmissions-netværket kan en given instans af Nemhandel eDelivery Referenceimplementeringen køres som enten Nemhandel eller Peppol endepunkt, afhængigt af hvilket certifikat den indlæser (MitID eller Peppol). Erhvervsstyrelsen er i gang med at undersøge om det er praktisk at give mulighed for at udenlandske Peppol-adgangspunkter kan sende Nemhandel med Peppol certifikater i stedet for MitID certifikater. Denne afklaring er endnu ikke afsluttet.

Spørgsmål: Hvorfor lave opslag gennem NHR API isf. SML/SMP direkte?

Svar: NHR API tillader et bredere udvalg af søgninger. og returnerer flere oplysninger i søgeresultatet. SML/SMP kræver at man allerede ved hvilket endepunkt man ønsker at sende til. NHR API lader brugeren søge på f.eks. en virksomheds navn og adresse og se hvilke endepunkter den er registreret med.

Migration, deadlines, etc.

Spørgsmål: Hvad er deadline for implementeringen af Nemhandel eDelivery?

Svar: 31. oktober 2023.

Spørgsmål: Kan vi allerede nu begynde at sende LIVE gennem eDelivery, eller er det først muligt efter den 31-10-2023?

Svar: Ja.

Det er tilladt at benytte Nemhandel eDelivery før 31. oktober, og det er fortsat tilladt at benytte OIORASP efter 31. oktober, forudsat at man også fra 31. oktober understøtter Nemhandel eDelivery. Det er ikke et krav at man slukker sine OIORASP-services 31. oktober, men ej heller et krav at man holder dem åbne efter 1. november. 

Spørgsmål: Betyder dette at alle modtagere skal være migreret og registeret i den centrale danske SMP på alle dokumenttyper?

Svar: Delvis korrekt.

Alle modtagere skal have alle de profiler de i dag har i OIORASP registreret i en SMP. Der er ikke noget krav om at den SMP er Nemhandelsregisteret, men det anbefales da Nemhandelsregisteret stiller visse supplerende funktionaliteter til rådighed udover standard SMP funktionaliteter. Bemærk i øvrigt at danske offentlige myndigheder er forpligtede til at benytte Nemhandelsregisteret som SMP, i medfør af Lov om Offentlige Betalinger.Det er ikke obligatorisk at slette de eksisterende OIORASP profiler pr. 30. oktober, blot at have tilsvarende Nemhandel eDelivery profiler registreret. OIORASP videreføres i en overgangsperiode som en protokol man kan men ikke behøver understøtte.

Spørgsmål: Betyder det at Ingen trafik bør gå over NemHandel RASP efter 31. Oktober og alt trafik uafhængigt at dokumenttype skal leveres over NemHandel eDelivery?

Svar: Det er tilladt at benytte Nemhandel eDelivery før 31. oktober, og det er fortsat tilladt at benytte OIORASP efter 31. oktober, forudsat at man også fra 31. oktober understøtter Nemhandel eDelivery. Det er ikke et krav at man slukker sine OIORASP-services 31. oktober, men ej heller et krav at man holder dem åbne efter 1. november. De centrale komponenter i OIORASP forventes at blive end-of-lifet i første halvår af 2024, hvorefter det ikke længere vil være muligt at benytte OIORASP i Nemhandel.

Spørgsmål: For e-faktura, kræves support af OIOUBL 3.0 og eDelivery, fra 1. november 2023?

Svar: Alle der benytter NemHandel, skal kunne udveksle forretningsdokumenter over NemHandel eDelivery senest den 1. november. 
Der opfordres til, at systemudbyderne fortsat understøtter OIORASP, indtil de kan konstatere at de kan udveksle med deres forretningspartnere over eDelivery, eller indtil OIORASP udfases 30. april 2024.
 

Spørgsmål: OIORASP protokollen er nævnt adskillige steder i jeres Vejledninger og Guides, men det er ikke lykkedes mig at finde en teknisk protokol beskrivelse? 

Svar: Hvis du ikke allerede benytter OIORASP, så skal du ikke installere denne protokol, da denne udfases 1/11-23. I stedet skal du bruge e-Delivery AS4 protokollen. Læs her, hvor du finder alle henvisningerne til informationen.

Spørgsmål: Andre lande (Italien, Polen) har valgt at stille en central statslig løsning til rådighed som formidler e-fakturaer. Ville det ikke være simplere for serviceleverandørerne at følge den strategi?

Svar: Det er ikke oplagt at en central løsning ville være simplere at bygge eller lettere at anvende. Et Oxalis-baseret adgangspunkt med et mindre antal REST-grænseflader vurderes ikke at være en tung løsning. Herudover kan nævnes: 

1. En central løsning skaber en central flaskehals i netværket, som kan lægge hele netværket ned ved driftsforstyrrelser.
2. En centraliseret løsning ville stride imod det forventede indhold af EUs kommende moms-direktiv.
3. En centraliseret løsning vanskeliggør grænsekrydsende dokumentudveksling. eDelivery AS4 er den fælleseuropæiske standard for denne type dokumentudveksling.
4. En central løsning ville fortsat kræve at afsender og modtager bygger henh. læser OIOUBL dokumenter korrekt.

Spørgsmål: Er det korrekt at Nemkonto ikke kan håndtere Mitid?

Svar: Der er intet i Nemhandel der bør forhindre at man kører NemKonto på foces2 og resten på Foces3, hvis NemKonto ikke er klar. Det vil i så fald kræve to separate instanser af de relevante sende/modtage services, men der er intet der blokerer for at man kan have forskellige receiver-services knyttet til samme endepunkt. For konkrete henvendelser om Nemkonto må vi henvise til Nemkontos support-linje. Nemkonto benytter Nemhandels-infrastrukturen, men er ikke en Nemhandel-løsning, så vi kan ikke give detaljeret support på den.

Spørgsmål: Er det rigtigt forstået, at modtagere nu skal registrere deres brugere i både NHR og sin egen database, i modsætning til tidligere, hvor det var muligt at modtage på vegne af ukendte modtagere? Er der en mulighed for at deaktivere denne dobbelte registreringskrav?

Svar: Ja, det er korrekt forstået. Som serviceleverandør skal dine brugere både være indregistrerede i NHR, med et GLN nummer eller anden participant_id, og stå opført i din egen interne database. Det er ikke muligt at deaktivere dette dobbelte registreringskrav. Kravet er indført som en sikkerhedsforanstaltning for at forhindre, at der sendes uønskede eller irrelevante data til C3. C3 vil derfor skulle afvise dokumenter, hvis det tilhørende participant_id ikke er kendt.
 

Profiler og dokumenter

Spørgsmål: Kommer der nye profiler, og i så fald hvornår?

Svar: Profiler er som udgangspunkt uafhængigt af overgangen til Nemhandel eDelivery. Nemhandel planlægger at frigive OIOUBL 3 profiler for de dokumenter der er omfattet af Bogføringsloven (faktura og kreditnota, omfattende dokumenterne faktura, kreditnota, fakurasvar og application response) i 2. halvår, samt en profil til udveksling af varestamdata. Disse vil blive indfaset som kompabilitetsbrydende opdateringer, efter de eksisterende migrations- og opdateringspolitikker for Nemhandel (Bortset fra varestamdatabladdet, som er et nyt dokument og derfor ikke er kompabilitetsbrydende).

Spørgsmål: Bliver der krav om registrering af afsendere i den danske nationale SMP?

Svar: Det er nødvendigt at registrere et gyldigt endepunkt til modtagelse af Application Response, og OIOUBL 3 forventes udarbejdet ud fra et princip om at man kan give eksplicit kommercielt svar på alle dokumenter.Der bør ikke være nogen teknisk hindring for at man kan benytte en anden SMP end Nemhandelsregisteret til disse registreringer. Men Nemhandelsregisteret udstiller en række funktionaliteter som ligger udover hvad en standard-SMP leverer ”ud af boksen,” og Nemhandel eDelivery er kun testet imod Nemhandelsregisteret. Så det anbefales at benytte Nemhandelsregisteret. Bemærk i øvrigt at offentlige myndigheder er forpligtede til at være registrerede i Nemhandelsregisteret, ikke i andre SMPer, i medfør af Lov om Offentlige Betalinger.

Spørgsmål: OIOUBL 3.0 Faktura og KreditNota bliver en CIUS på den europæiske norm, sidestillet med Peppol BIS Billing 3.0? 

Svar: Korrekt.  

Spørgsmål: Andre OIOUBL dokumenttyper bliver selvstændige danske customizations ikke direkte relateret til Peppol BIS?

Svar: Korrekt.  

Spørgsmål: Hvilke formater er der planer om at skulle understøttes på kodelisten for indlejrede dokumenter?

Svar: Som udgangspunkt følger OIOUBL 3 Peppols kodelister for dette, med mindre der er tungtvejende grunde til at fravige dem.

Spørgsmål: Er det planlagt at korrigere brugen af TaxExclusiveAmount, således det følger den internationale standard, og ikke den danske afvigelse som benyttes i de nuværende  OIOUBL dokumenter?

Svar: Ja.  

Spørgsmål: I forbindelse med lovkrav for det offentlige om fremtidige ESG rapportering, stilles der krav til indberetning af “grønne” dimensioner. Er der planlagt brug af felterne i OIOUBL 3.0, således der skabes symmetri omkring rapportering af disse krav til det offentlige og de kommende format?

Svar: Ja, det er et arbejde vi følger tæt og forsøger at understøtte i videst muligt omfang. Planen om at frigive et format til udveksling af varestamdatablade er en del af denne understøttelse.

Spørgsmål: OIOUBL UtilityStatement (UTS): Fortsætter man med denne dokumenttype? (denne eksisterer ikke i Peppol). 

Svar: Ja. OIOUBL profiler og dokumenter er som udgangspunkt uændret af overgangen til Nemhandel eDelivery. Bemærk dog at Erhvervsstyrelsen planlægger at lancere OIOUBL 3 faktura, kreditnota, fakturasvar og application response i efteråret 2023, efter den eksisterende migrationspolitik for kompabilitetsbrydende ændringer.

Spørgsmål: OIOUBL Reminder: Fortsætter man med denne dokumenttype? (denne eksisterer ikke i Peppol).

Svar: Ja. OIOUBL profiler og dokumenter er som udgangspunkt uændret af overgangen til Nemhandel eDelivery. Bemærk dog at Erhvervsstyrelsen planlægger at lancere OIOUBL 3 faktura, kreditnota, fakturasvar og application response i efteråret 2023, efter den eksisterende migrationspolitik for kompabilitetsbrydende ændringer.

Governance

Spørgsmål: Bliver der nogen form for certificering? Skal en dansk NemHandel eDelivery operatør bevise deres kapabiliteter på nogen måde? Som certificeringsprocessen/whitelisting fungerer i Peppol i dag?

Svar: Det er der ikke p.t. planer om. Nemhandel eDelivery understøtter et højere niveau af sporbarhed og teknisk sikring af dokumentets autentitet og integritet, hvilket tillader en lavere grad af organisatorisk og bureaukratisk sikring.

Spørgsmål: Hvilken relation har opgraderingen af Nemhandel til implementeringen af VIDA direktivet i Danmark?

Svar: Nemhandel teamet følger arbejdet med VIDA tæt. VIDA lægger i sin nuværende form op til en decentraliseret transaktionskontrol model (D-CTC), som Nemhandel let vil kunne understøtte med ganske små opdateringer af infrastrukturen.

Relation til Bogføringsloven

Spørgsmål: Hvilke dokumenter skal modtageren lovmæssig opbevare og have adgang til i den lovpligtige opbevaringsperiode?
Alene det oprindelige OIOUBL XML dokument, det HTML stylede OIOUBL dokument, eller begge dokumenter?

Svar: Det oprindelige OIOUBL XML er det oprindelige, og autoritative, dokument. Nemhandel eDelivery understøtter signering af det oprindelige OIOUBL XML dokument, hvilket brugerne anbefales at benytte. En af fordelene ved signering af dokumentet er at det tillader en entydig definition af "det orginale dokument": Det er det dokument der validerer korrekt med den oprindelige elektroniske signatur. HTML stylingen er ikke en del af dokumentet. HTML stylingen er alene læserens ansvar.

Spørgsmål: I visse tilfælde udveksles dokumenter med et total beløb på 0.00 DKK. Er det et krav, at disse dokumenter også er tilgængelige hos modtageren i den lovpligtige periode?

Svar: Det kan det være, ja. En faktura der repræsenterer slutafregningen af en a conto betaling vil f.eks. stadig være omfattet bogføringsmateriale.
Bemærk at Nemhandel som udgangspunkt alene stiller krav om opbevaring af logfiler. Krav om opbevaring af selve dokumentet er hjemlet andetsteds (typisk Bogføringsloven eller skattelovgivningen). Nemhandel teamet og supporten kan derfor ikke som udgangspunkt vejlede udtømmende om sådanne krav. Spørgsmål hertil skal stiles ad de for den relevante lovgivning sædvanlige kanaler.

Spørgsmål: Hvordan er forholdet mellem kravene til Standard Bogføringssystemet og kravene til en leverandør af Nemhandel eDelivery Access Pointet? Er det et krav at disse parter indgår en en kontrakt?

Svar: Peppol forlanger, at adgangspunktet har en ubrudt kæde af aftaleforhold til den endelige slutbruger, og er i stand til på forlangende at identificere den pågældende slutbruger (f.eks. i tilfælde af tvister).De tekniske krav, der er fastsat efter bogføringsloven kræver, at udbyderen af et digitalt standard bogføringssystem understøtter fremsendelse og modtagelse af e-faktura efter Peppol-standarden. Hvis bogføringssystemudbyderen er adgangspunkt, skal udbyderen derfor opfylde dokumentationskravene efter Peppol-standarden. Bogføringssystemudbyderen skal endvidere kunne dokumentere, at bogføringssystemet understøtter, at slutbrugeren kan tilgå Nemhandel. Det vil normalt betyde, at man kan fremvise en kontrakt, som dokumentation for at man har outsourcet sin Nemhandel tilslutning.

Spørgsmål: Hvordan påvirkes et eventuelt krav om kontraktuelle relationer imellem adgangspunkt og bogføringssystem af at adgangspunktet konverterer imellem Nemhandel og Peppol dokumenter, eller bogføringssystemet tilgår Nemhandel og Peppol igennem forskellige underleverandører?

Svar: Hverken konvertering imellem Nemhandel og Peppol, eller hvilke dokumenter der understøttes af et adgangspunkt, gør nogen forskel for hvilke forpligtelser adgangspunktleverandøren eller bogføringssystemleverandøren har. Alle krav til bogføringssystemer vedr. e-fakturering og Nemhandel fastsættes efter bogføringsloven. Denne model omfatter både regulering af relationen bogføringssystem-virksomhed og relationen bogføringssystem-access point.

Referenceimplementeringen

Spørgsmål: Vil Oxalis være en del af leverancen fra ERST incl. installationsvejledning, eller skal vi forvente at vi selv skal downloade, installere og konfigurere en Oxalis.

Svar: Referenceimplementeringen inkluderer Oxalis, så det er ikke nødvendigt at installere den separat. Bemærk at referenceimplementeringen har en håndfuld modifikationer til Oxalis' kode, så det er i øjeblikket ikke muligt blot at installere referenceimplementeringens konfigurationer og plugins ovenpå en "ren" Oxalis.

Spørgsmål: Hvilken version af Oxalis bygger Referenceimplementeringen på?

Svar: 5.5.0, som er den seneste version. Referenceimplementeringen vil blive holdt ajour med Oxalis, når Oxalis udgiver nye versioner.

Spørgsmål: Vil Referenceklienten stadig fungere sammen med eDelivery?

Svar: Nej Nemhandels klienten vil ikke fungere med eDelivery. 

Spørgsmål: Kan man afsende varekataloger via Oxalis ud i Nemhandel netværket?

Svar: Ja, alle tidligere forretningsdokumenter, kan fremover også bruges i eDelivery netværket. Vi anbefaler, at man holder sig opdateret på nemhandel.dk

Spørgsmål: Kører Nemhandel Referenceklienten videre i sin nuværende form samtidig med introduktionen af Oxalis?

Svar: Nemhandel Referenceklienten (Nemhandelsprogrammet) ophører 31/10-23, og vil derefter ikke kunne anvendes og support af denne ophører ligeledes.

Spørgsmål: I dag har man en simpel Nemhandel Reference Klient. Findes der ikke en executable der er standalone, så der ikke kræves 3.parts produkter blot for at kunne sende fakturaer ud?

Svar: Nej, og det kan ikke lade sig gøre at konstruere en sådan. Det er i Nemhandel eDelivery obligatorisk at kunne modtage detaljerede fejlmeddelelser når man forsøger at sende et fejlbehæftet dokument. En sender-service uden en tilknyttet receiver-service ville ikke være i stand til at honorere dette krav.

Spørgsmål: Det står ikke klart beskrevet nogen steder den nemmeste mulighed for overgang fra gammel til ny referenceklient?

Svar: Nemhandel eDelivery Referenceimplementeringen har en vejledning til hvordan den kan installeres i en Java Virtual Machine. Brugeren forudsættes at være i stand til at oprette og vedligeholde en sådan.Nemhandel eDelivery Referenceimplementeringen implementerer REST API grænseflader, som er beskrevet i den relevante systemdokumentation. Nemhandelsprogrammet anvendte hotfolders til at organisere udbakken. Når eDelivery Referenceimplementeringen skal implementeres i et eksisterende systemlandskab som tidligere har benyttet Nemhandelsprogrammet er det derfor blandt andet nødvendigt at tilpasse de komponenter der genererer OIOUBL dokumenterne og lægger dem til afsendelse. Disse skal nu kalde Outbox REST APIen i stedet for at generere en fil i outbox-mappen.

Bemærk at Erhvervsstyrelsen ikke som udgangspunkt yder support til integration i brugerens lokale systemlandskab, udover disse overordnede betragtninger om forskellene i de to applikationers snitflader.

Spørgsmål: Kan vi bruge den officielle Oxalis klient, eller skal vi bruge forken, I selv linker til?

Svar: Den officielle oxalis klient implementerer ikke nok af de skærpede krav der er til afsendelse og modtagelse jvf. den nye bogføringslovgivning. Så selvom det ikke er et krav at bruge den referenceimplementering som ERST udstiller, så vil dette være referencen for hvad der er behov for i et system som skal være godkendt efter denne skærpelse (også deraf navnet).

Erhvervsstyrelsen arbejder på at gøre overbygningen uafhængig af Oxalis kodebasen, således at Erhvervsstyrelsens referenceimplementering kan køres "ovenpå" en standard Oxalis. Forhåbningen er at dette kan nås inden næste Oxalis major release, hvor alle brugere alligevel vil skulle opdatere deres installation.

Dokumenter

Spørgsmål: Når en kunde skal oprettes i PEPPOL, kan det gøres igennem NHR, eller har PEPPOL sin egen metode til dette?

Svar: At registrere en Peppol bruger i NHR er tilstrækkeligt (så længe endepunktet peger på en gyldig Peppol receiver service, hvilket kræver et gyldigt Peppol certifikat).

Offentlige organer skal være registrerede i NHR. Private virksomheder må gerne være registrerede i en anden Peppol SMP end NHR. I så fald er det op til den valgte SMP hvor meget brugeren selv skal registrere andre steder (men normalt vil SMP'en gøre det for brugeren).

Spørgsmål: Hvad koster et certifikat til PEPPOL, og hvor kan vi få et?

Svar: Priserne for at oprette sig i Peppol kan findes her - du vil sandsynligvis kigge under Service Providers - 2a. For at få mere information omkring PEPPOL's certifikater henviser vi til PEPPOL's support.

Spørgsmål: Er det nødvenligt at ændre XML til at bruge et PEOPPL format i modsætning til OIOUBL formatet?

Svar: Ja. De to formater er ikke helt ens.

Med OIOUBL 3 forventer Erhvervsstyrelsen at udgive et sæt af konverterings-stylesheet, der lader brugeren automatisk konvertere imellem de to. Men indtil videre er der kun udgivet et konverterings-stylesheet der konverterer fra Peppol faktura til OIOUBL 1.13 faktura. 

Spørgsmål: Kan den nye Nemhandels Softvarekonponenter, konvertere et OIOUBL format til Peppol. Kundens ERP løsning kan kun danne OIO format (elektroniske faktura) som via Nemhandelsklienten sendes til deres kunder. Kan den nye løsning konvertere fil formatet hvis modtageren kun kan modtage Peppol formatet?

Svar: Ikke endnu. OIOUBL 3 forventes at indeholde konverterings-stylesheets for de udgivne dokumenter, som kan benyttes til at konvertere imellem OIOUBL og Peppol formater (for dokumenttyper hvor begge formater eksisterer). Bemærk i øvrigt at Nemhandelklienten udgår af support 31. oktober 2023. Nuværende brugere af Nemhandelklienten skal i stedet skifte til Nemhandel eDelivery Referenceimplementeringen. Bemærk desuden at det fra 2024 kan være obligatorisk for Jeres kunde at have en bogføringsløsning der understøtter Nemhandel og Peppol.

Spørgsmål: Tilbyder I et standard stylesheet (xsl format), som vi kan bruge til at rendere et PDF-preview for indkommende e-dokumenter? Når vi f.eks. implementerer at vi kan modtage e-fakturaer, vil vi gerne visuelt vise det i regnskabsprogrammet og der tænker vi det ville være smart, hvis I havde et standard stylesheet der kunne bruges til det formål.

Svar: Erhvervsstyrelsen har udgivet en eksempel-stylesheets for en række dokumenttyper, men udgangspunktet har hidtil været at den enkelte systemudvikler selv tilpassede visnings-stylesheets til sine konkrete behov. Derfor er Erhvervsstyrelsens stylesheets kun blevet sporadisk vedligeholdt siden den oprindelige udgivelse. Med OIOUBL 3 forventer vi at offentliggøre officielle visnings-stylesheets, som blandt andet implementerer alle de felter som er obligatoriske for et system at afløfte.

Spørgsmål: I nuværende implementering bruger man DK som prefix er dette krav bortfaldet? 

Svar: Det er valgfrit om man vil benytte DK præfikset i SML-registreringer, men da ældre dokumenttyper og implementeringer fortsat kan forventes, er det kraftigt anbefalet.

Spørgsmål: Hvad hvis dokumentet der modtages i C3 ikke er validt?

Svar: Det er obligatorisk for modtagende adgangspunkt at schema-validere indkommende trafik inden det udsteder en transport-kvittering, og schematronvalidere inden det videresender til slutbrugeren. Hvis modtagende adgangspunkt finder en schematron-fejl, skal det sende en Message Level Response/Application Response. Det er obligatorisk for afsender at være i stand til at modtage og behandle denne.

Spørgsmål: Hvad er en SBD?

Svar: SBD er en forkortelse af Standard Business Document. Et SBD består af en Standard Business Document Header (SBDH), der indeholder addresseringsoplysninger, afsenders oplysninger, og en nyttelast (selve forretningsdokumentet, f.eks. en faktura). SBDH'en fungerer som en konvolut, der fortæller netværket hvordan dokumentet skal behandles, uafhængigt af det forretningsmæssige indhold.

Schematron

Spørgsmål: Vi skal indbygge schematron validering på vores OIOUBL-kataloger; men udvikler siger at de ikke kan finde værktøjer til det som er moderne nok til at køre i Azure miljø?

Svar: Nemhandel eDelivery Referenceimplementeringen benytter Saxon HE, udgivet af Saxonica: https://www.saxonica.com/welcome/welcome.xml

Systemcertifikater

Spørgsmål: Hvordan installeres MitID rodcertifikat? 

Svar: Du kan installere rodcertifikatet direkte på den computer hvorfra Referenceklienten eller Nemhandel eDelivery Referenceimplementeringen kører, ved at udpakke MitID-rodcertifikatet. Certifikatet installeres ved at dobbeltklikke på .cer-filen og følge Windows installationsguide. Certifikatet skal installeres ved at vælge LocalMachine ved feltet om lageringsplacering. Ved punktet om hvorvidt du har tillid til certifikatet, skal du sige ja. Hvis du fortsat anvender et NemID systemcertifikat (FOCES2) skal du være opmærksom på at du skal skifte til MitID (FOCES3). Du kan læse mere om NemHandels opfordring til alle aktører om at opgradere til MitID her. 

Implementeringsdeadline for FOCES3 er 30. juni 2023, og Digitaliseringsstyrelsen har varslet at samtlige FOCES2 certifikater vil blive revokeret 31. oktober 2023.

Transportkoreografi

Spørgsmål: Betyder kravet om asynkrone fejlmeldinger ved schematronvalidering at NESUBL profilerne ikke længere vil være understøttet i Nemhandel eDelivery?

Svar: Nej, Nemhandel eDelivery understøtter fortsat NESUBL profilerne.

Nemhandel eDelivery og OIOUBL 3 skelner lidt skarpere imellem tekniske og kommercielle roller og dokumenter end vi historisk har gjort i OIORASP og OIOUBL 1.

Den kommercielle afsender kan fortsat sende med NES5, og behøver ikke modtage nogen form for kvittering eller feedback, udover hvad deres profil angiver.

Den tekniske afsender skal kunne modtage Application Response dokumenter med tekniske valideringsfejl, uanset hvilken profil der sendes med, men dette modtager-endepunkt behøver ikke være unikt for den kommercielle afsender. Den tekniske afsenders endepunktsadresse er angivet i SBDH. Den kommercielle afsenders endepunktsadresse (i BilSim profilen) er angivet i AccountingSupplierParty. De to behøver ikke (og bør ikke) være identiske.

I OIOUBL 3 vil der være specialiseret understøttelse til tekniske meddelelser, og vi forventer at udfase NESUBL profilerne med OIOUBL 3. Dog skal det nævnes, at denne skelnen imellem C2 i rollen som teknisk endepunkt og C2 i rollen som formidler af forretningsmæssig feedback til C1 ikke er 100 % stringent implementeret i de eksisterende OIOUBL 1.13 profiler. Det betyder indtil videre, at løsningen er, at den tekniske afsender registrerer et endepunkt som ”BilSim Supplier” på det endepunktsnummer, som de angiver i SBDH’en.

Spørgsmål: Er de tekniske responses (fra C3 til C2) implementeret i referenceimplementeringen - dvs. genererer og sender referenceimplementeringen automatisk disse responses til sender endpoint fra SBDH, eller er det noget alle operatører selv skal implementere?

Svar: Ja, referenceimplementeringen implementerer Nemhandel AS4 inklusiv en Application Response til C2 ved schematronfejl.

Spørgsmål: Hvordan bør et endpoint opføre sig, hvis der ikke kan findes en registrering at sende responses til?

Svar: Hvis afsenderen har angivet et ugyldigt endepunkt til MLR'en, bør afsenderen kontaktes manuelt. Det er vigtigt, at schematronfejl bliver kommunikeret korrekt og rettidigt, da det for eksempel kan få betydning for gyldigheden af rykkere og en eventuel inkassoproces. Sagen kan eventuelt eskaleres til ERST, som kan kontakte afsender. Principielt set er det ikke meget anderledes, end hvis en afsender sender så store mængder fejlbehæftede dokumenter, at de er til gene for modtageren.

Spørgsmål: Det fremgår af et tidligere svar, at den tekniske afsenders response endpoint skal være registreret som BilSim Supplier. Er dette en blivende løsning?

Svar: Nej. Der er i øjeblikket et arbejde i gang i Peppol-regi med at revidere Peppol-netværkets anvendelse af Message Level Response. Vi havde håbet at kunne følge deres konklusioner, men dette arbejde er stadig i gang. Derfor er den midlertidige løsning at registrere den tekniske modtager som "BilSim Supplier", indtil der kommer en anbefaling fra Peppol. Når denne anbefaling foreligger, vil vi følge den.

Spørgsmål: Sender ERSTs Demo endpoint (0184:16356706 - https://edel-demo.nemhandel.dk/as4) asynkrone kvitteringer? Dvs. kan jeg se at jeg får en kvittering tilbage, hvis jeg registrerer mit tekniske afsender ID i Demo NHR og sender til Demo endpointet?

Svar: Vores demo-endepunkt sender kun de obligatoriske fejlmeddelelser ved schematronfejl. Hvis vi får kendskab til, at vore brugere har et behov eller ønske om at det sender positive kvitteringer også, så bør vi kunne få det til at gøre det. Indtil videre har vi dog valgt ikke at implementere dette.

Spørgsmål: Bliver der en kvittering (MLR/AR) mellem C2 og C3. Hvordan adresseres disse?

Svar: Ja. I regi af Peppol arbejdes der på en revision af MLR transaktionen, og OIOUBL 3 vil indarbejde resultaterne af det arbejde. Indtil da benyttes BilSim Sender rollen som "Application response receiver" endepunkts beskrivelse.

Alle afsendere skal registrere et modtage-endepunkt med denne rolle, til at modtage tekniske svar fra fejlede asynkrone valideringer i modtager-endepunktet. Afsendere skal inkludere dette endepunkts ID (typisk GLN-nr) i SBDH-headeren, som bør være forskelligt fra det kommercielle afsender-ID.

Spørgsmål: På et tidspunkt blev det nævnt at trafikken mellem C1 og C2 / C3 og C4 også skulle krypteres. Er det fortsat et krav eller er det out of scope?

Svar: Et endepunkt skal være konformt med denne specifikation.

Derudover siger Nemhandel ikke i sig selv noget om sikkerhedsforanstaltninger for datatransport imellem C1/2 og C3/4. ERST forventer i den ikke så fjerne fremtid at udgive retningslinjer for hvordan man bør sikre den kommunikation, men det vurderes p.t. ikke at være hensigtsmæssigt at lade en større netværksomlægning falde tidsmæssigt tæt sammen med en obligatorisk stramning af sikkerhedskravene i netværket.

Spørgsmål: På et tidspunkt blev det nævnt at C3 ved modtagelse skal slå C1 op i SMP’et for at verificere afsender. Er det stadig et krav. Hvilken registrering skal man i givet fald slå op?

Svar: Nej, ikke for nuværende. Se dog ovenfor om kryptering af C1/2 og C2/3 transporten, og evt. dokumentationen omkring valideringer.