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.