Offentlig e-fakturering bør ikke beskrives som én magisk knap. Der er mindst tre lag: den udstedte faktura, et stabilt e-faktura-artefakt og en transportkanal. Hvis de blandes sammen, bliver det uklart om bogføringssystemet har udstedt dokumentet, forberedt en fil eller faktisk sendt den gennem et access point.
EAN/GLN først
En offentlig modtager skal kunne identificeres deterministisk. I Rentemesters regler betyder det, at den immutable buyer snapshot på fakturaen skal indeholde de nødvendige EAN/GLN-oplysninger, før der kan eksporteres en offentlig e-faktura-preview eller OIOUBL-handoff.
OIOUBL som handoff
Rentemester kan materialisere et deterministisk OIOUBL-handoff-artefakt fra en udstedt faktura. Det er bevidst scoped som handoff: filen er sporbar, reproducerbar og audit-linket, men den må ikke forveksles med bevis for at fakturaen er afleveret gennem PEPPOL.
PEPPOL uden credential-læk
Grafen viser også et PEPPOL-submission-spor. Det bygger en idempotent submission-envelope oven på OIOUBL-handoff, mens access-point-konfiguration og credentials læses udefra. De gemmes ikke i bogføringstilstanden og bliver ikke en del af ledgeren.
Sådan håndterer Rentemester det
CLI-flows for public preview, OIOUBL-handoff og PEPPOL submission-envelope er kodebackede. Den vigtige grænse er, at Rentemester forbereder og registrerer materialet deterministisk; transportansvar, access-point-aftale og credentials ligger uden for kernen.
Ofte stillede spørgsmål
Sender Rentemester PEPPOL-fakturaer direkte?
Koden kan bygge en deterministisk PEPPOL-submission-envelope oven på OIOUBL-handoff, men credentials og access-point transport ligger uden for bogføringstilstanden.
Er OIOUBL det samme som PEPPOL?
Nej. OIOUBL er fakturaformatet/handoff-artefaktet i denne sammenhæng. PEPPOL handler om transporten gennem et access point.