NemHandel eDelivery – hvad ved vi på nuværende tidspunkt? Og hvordan skal I forholde jer?
NemHandel er overgået til den nye eDelivery-baserede infrastruktur, som metode for udveksling af OIOUBL-dokumenter. Få her en grundig teknisk og forretningsmæssig gennemgang af eDelivery.
Overblik over artiklen:
NemHandel eDelivery kort fortalt
For i højere grad at aligne med Peppol-standarden vil Erhvervsstyrelsen opgradere OIOUBL til en version 3. Her tager man udgangspunkt i samme koncept som Peppol, kaldet eDelivery eller four corner-model.
Erhvervsstyrelsen udgav referenceimplementeringen tilbage i maj 2023, som er det danske bud på en four corner-model. Deadline for at overgå til NemHandel eDelivery var den 31. oktober 2023. Den eksisterende måde man udveksler på, OIORASP, må man beholde i overgangsfasen indtil april 2024. I overgangsperioden kører mySupply et dual setup, hvor begge protokoller understøttes, da forsendelser i OIORASP stadig er muligt efter den 31. oktober 2023. Vi tjekker således begge netværk inden afsendelse for at sikre, at dokumenterne havner ved den korrekte modtager.
NemHandel referenceklienten, som mange benytter til afsendelse, udløb 31. oktober 2023. Derfor skal brugere til afsendelse af elektroniske OIOUBL fakturaer finde en operatør, der kan understøtte eDelivery.
Overgangen til NemHandel eDelivery er en major release, hvilket vil sige, at man bryder med bagudkompatibiliteten. Dermed kan man ikke længere sende i tidligere formater, men skal opdatere alle dokumenter, som er gældende for bogføringsloven.
Four corner-model – kort fortalt
Den danske NemHandel eDelivery-model tager udgangspunkt i four corner-model efter Peppol.
Corner 1 er afsender.
Corner 2 er afsenders operatør.
Corner 3 er modtagers operatør.
Corner 4 er modtager.
Når corner 1 skal afsende et dokument til corner 4, laver corner 2 et opslag i Nemhandelsregistret. Corner 3 modtager herefter for corner 4, som modtager dokumentet i deres økonomisystem.
Modellen giver bedre sikkerhed, da det kører efter AS4 transportprotokol. Modellen tager som sagt inspiration efter Peppol-netværket, hvilket er et åbent netværk, hvor afsender ikke nødvendigvis skal kende modtagers service provider. Service providere laver opslag i netværket for at finde korrekt modtager.
Eksempel:
eDelivery kan sammenlignes med et telefonopkald. Når vi tager vores telefon og laver et opkald, så indtaster vi nummeret og telefonoperatører sørger for, at opkaldet går igennem til modtageren. Dette sker også ved, at Corner 1 ringer til Corner 4, men inden det kan ske, så er der et opslag og en udveksling mellem to operatører, der sørger for, at opkaldet går igennem.
Migreringsplan
Erhvervsstyrelsen har lavet følgende migreringsplan i overgangen til eDelivery.
OIORASP fortsætter som selvstændig protokol indtil 31. oktober 2023, hvorefter det kræves, at modtager som minimum er registreret i eDelivery-netværket. Dog kan OIORASP stadigvæk benyttes indtil end-of-life i november 2024.
Alle modtagere skal have de profiler, som de har i OIORASP, registreret i eDelivery.
Når en ny operatør skal implementere NemHandel, stilles der udelukkende krav om eDelivery og dermed ikke om et dual setup (OIORASP og eDelivery på samme tid). Det er altså kun gældende for eksisterende operatører.
Hvilke dokumenttyper kommer?
Som nævnt i artiklen ”Bogføringsloven – hvad ved vi? Og hvordan skal I forholde jer?” kommer der med udrulningen af NemHandel eDelivery flere specifikke dokumentkrav, som standard bogføringssystemer skal kunne.
Systemet skal kunne:
- afsende og modtage OIOUBL 3 faktura og kreditnota
- afsende en Application response ved modtagelse af en OIOUBL-faktura
- afsende og modtage Peppol-faktura og kreditnota
- afsende Message Level response ved modtagelse af en Peppol-faktura
- afsende Invoice Response ved modtagelse af en Peppol-faktura
Man skelner mellem to typer af kvitteringer – en teknisk og en forretningsmæssig. En teknisk kvittering (Message Level Response) er, at man skal kunne afvise en faktura, hvis den grundlæggende ikke lever op til regelsættet. En forretningsmæssig (Invoice Response) er en tilkendegivelse af, om man har tænkt sig at betale fakturaen eller ej. Det kan eksempelvis være en afvisning, hvis prisen ikke er korrekt.
Application Respons splitter man ligeledes op i en teknisk kvittering, og det man kalder et fakturasvar.
Selvom der er et krav om, at standard bogføringssystemer kan sende en kvittering, er det umiddelbart ikke et krav om, at man skal gøre det.
Fakturaafsenderen skal være registreret til at kunne modtage en Application Response til tekniske afvisninger. Derimod er det ikke et krav, at fakturaafsenderen skal være registreret til at kunne modtage en Application Response til forretningsmæssige afvisninger. Men det er forventeligt.
OIOUBL 3 dokumentpakker
Når vi snakker OIOUBL 3 dokumentpakker, så er der dokumenter, som er direkte omfattet af bekendtgørelsen (faktura og kreditnota), men der er ligeledes dokumenter, som ikke er omfattet af bogføringsloven, men derimod en afledt konsekvens heraf.
Pakke 1 er den første dokumentpakke, som vi på nuværende tidspunkt er sikre på. De andre pakker er vores bedste bud på, hvilke dokumenter der kan komme i OIOUBL 3.
Med indførelsen af pakke 1 er der lagt op til en tvungen registrering af fakturasvar, som er en registrering af fakturaafsender til modtagelse af forretningsmæssige elektroniske svar. Der lægges op til en større alignment med Peppol OIOUBL 3-dokumenterne.
En af dokumenttyperne i Pakke 1 er varestamdatablad. Vi har fået af vide, at det er et delkatalog, hvor man udlader leverandørspecifikke oplysninger, men tager de masterdata, som er relevante for at beskrive produkter. Årsagen til, at man allerede introducerer denne dokumenttype, må være af hensyn til det øgede fokus på cirkulær økonomi, grøn økonomi og de øgede krav der bliver til ESG-rapportering, som træder i kraft for alle større virksomheder til i 2024.
Dokumentpakke | Dokumenttype |
Pakke 1 | |
Faktura | |
Kreditnota | |
Fakturasvar | |
Applikationsmeddelelse (Teknisk) | |
Varestamdatablad | |
Varemodtagelseskvittering | |
Despatch advice | |
Bestillingspakke | |
Ordre | |
Simpel ordrebekræftelse | |
Ordrebekræftelse | |
Ordreændring | |
Ordreannullering | |
OrdreAgreement | |
Katalogpakke | |
Katalog | |
Katalogforespørgsel | |
Opdatering af katalogelement | |
Opdatering af katalogpriser | |
Katalogrespons | |
PunchOut |
Man har ligeledes annonceret, at der kommer kommende leverancer på de dokumenttyper, vi kender i dag. Det gælder varemodtagelseskvittering, bestillingspakke, katalogpakker. Vi har ikke dato herpå endnu.
Vi har yderligere fået oplyst, at UTS (forsyningsspecikation) og tilhørende rykker, som findes i dag, også vil fortsætte, selvom der ikke findes tilsvarende i Peppol. Så om de fortsætter uændret eller hvad proceduren bliver, ved vi på nuværende tidspunkt ikke.
Pakke 1 – tidsplan
Fra november 2023 er høringsrunde 1 for de overordnede designprincipper og ændringer. Den første release af dokumentpakken sker til marts 2024, og i april 2024 offentliggøres den endelig release. Der vil være en kort deadline for implementering af dokumentpakken, som har obligatorisk understøttelse af OIOUBL 3 i NemHandel fra maj 2024.
I perioden maj til november 2024 udfases den eksisterende OIOUBL version, og fra november vil det ikke længere være muligt at udveksle den eksisterende OIOUBL-faktura vis NemHandel.
Høringsrunde 1 Overordnede designprincipper og ændringer | November 2023 |
Release candidate Release af første dokumentpakke | Marts 2024 |
Final release Endelig release af første dokumentpakke | April 2024 |
Understøttelse af OIOUBL 3 Obligatorisk understøttelse af OIOUBL 3 blandt NemHandel-aktørerne | Maj 2024 |
End-of-life OIOUBL 1.13 End-of-life på den nuværende OIOUBL version | November 2024 |
mySupply står klar
mySupply står som altid klar til at håndtere jeres elektroniske end-to-end dokumenthåndteringsproces. Vi besidder den nyeste viden, og sidder med i alle større udvalg, så vi er først ude med nye retningslinjer.
For alle kunder håndterer vi alt omkring eDelivery. Vi sørger for, at kunder ikke mærker skiftet af infrastruktur. I udrulningen af nye dokumenttyper laver vi en gapanalyse, således vi er på forkant med forskelle.
For kunder, hvor vi laver konverteringer til og fra OIOUBL 2.1, opdaterer vi til OIOUBL 3, så vi overholder nye formater. Vi håndterer ligeledes løbende alle øvrige OIOUBL 3-dokumenter, som der ikke stilles krav om i bogføringssystemerne.
For ikke eksisterende kunder, står vi altid klar til at drøfte jeres nuværende løsning, således vi kan sikre os, at I er klar til eDelivery.
Vil I have yderligere information, er I velkommen til at kontakte os.