PSB je certifikovaný Peppol Access Point a SMP (Service Metadata Publisher). Cez API sa konfigurujú typy dokumentov, ktoré organizácia môže prijímať, publikujú firemné údaje v Peppol Directory a spravuje sa SMP registrácia. Tento článok pokrýva technické pozadie a API endpointy, ktoré sa na to používajú.

Peppol funguje s modelom 4-corner: odosielateľ (C1) odosiela cez svoj Access Point (C2) dokument na Access Point príjemcu (C3), ktorý ho prepošle príjemcovi (C4). Routing prebieha cez dva centrálne komponenty:

• SML (Service Metadata Locator): centrálny DNS register, ktorý odkazuje na správny SMP príjemcu
• SMP (Service Metadata Publisher): obsahuje metadáta príjemcu, aké dokumenty môže prijímať a cez aký Access Point

Keď odošlete faktúru cez PSB, PSB automaticky vykoná SML/SMP lookup na nájdenie správneho Access Pointu príjemcu. Ako integrátor to nemusíte robiť sami.

Infraštruktúra Peppol sa aktívne vyvíja. Pre integrátorov používajúcich API PSB to nemá žiadny vplyv: PSB vykonáva SML/SMP lookupy automaticky. Nižšie sú aktuálne zmeny na informáciu.

Insourcing SML. OpenPeppol preberá správu SML od Európskej komisie (DG DIGIT). Migračné okno bolo otvorené 19. marca 2026. Platia dva samostatné termíny: termín pre SMP registrácie je 31. máj 2026, migračné obdobie pre AP Lookup (DNS rozlíšenie) bolo predĺžené do 31. augusta 2026. OpenPeppol diskutuje s Európskou komisiou, či je možné predĺžiť aj termín SMP registrácie. Pre API integrátorov sa nič nemení v endpointoch ani lookupoch: PSB rieši migráciu interne.

Migrácia CNAME na NAPTR. Migrácia DNS CNAME záznamov na NAPTR záznamy pre SML lookupy bola dokončená v marci 2026. NAPTR je povinný od 1. februára 2026. Staré CNAME záznamy boli odstránené z testovacej siete SMK (4. marca 2026) a produkčnej siete SML (11. marca 2026). Ide o internú DNS zmenu v infraštruktúre Peppol. PSB už používa NAPTR a nie sú potrebné žiadne úpravy integrácie.

Migrácia PKI G3. OpenPeppol pripravuje prechod z certifikátov PKI Generation 2 (G2) na Generation 3 (G3). G3 certifikáty sa používajú na vzájomnú komunikáciu medzi Access Pointmi. Peppol Testbed podporuje G2 aj G3 certifikáty od marca 2026, aby Service Providers mohli testovať vopred. Povinný dátum prechodu ešte nebol zverejnený. Pre API integrátorov sa nič nemení: PSB rieši obnovu certifikátov interne.

Peppol podporuje logistické typy dokumentov okrem faktúr cez špecifikáciu Peppol Logistics. Verzia 1.2 je povinná od 16. marca 2026. Verzia 1.3 je povinná od 24. augusta 2026.

Podporované logistické dokumenty:

• Despatch Advice (dodací list)
• Weight Statement
• Transport Execution Plan
• Waybill

Nové funkcie vo vydaní 1.3:

• ProductTraceID so schemeID pre ItemInstance
• DespatchAdviceTypeCode rozšírený o hodnoty na identifikáciu use case (101, 102, 112, 203-211, 303-311)
• DocumentStatusCode s novou hodnotou "55 - Notification only" pre zmeny po fakturácii
• Waste Declaration Number ako AdditionalItemProperty
• Nový zoznam kódov ProductTraceIDschemeIDCode

Vydanie 1.3 rieši RFC LLC-27 až LLC-35, vrátane zarovnania ItemInstance, nefakturačných aktualizácií a kódov podúpravy pre odpad.

Pri registrácii party v SMP eConnect sa cez capability určujú typy dokumentov, ktoré táto party môže prijímať. Každá capability má tri možné stavy:

Odporúčaná hodnota pre nové registrácie je inherited, pokiaľ party nemusí špecificky odbočiť od štandardu.

Capability sa konfigurujú cez Peppol config endpoint:

PUT /api/v1/peppol/config/party/{partyId}

V body požiadavky sa uvedie požadovaný stav pre každú capability. Príklad:

{
  "capabilities": {
    "invoices": "on",
    "selfbilling": "inherited",
    "invoiceResponse": "on",
    "orderOnly": "on",
    "orderAdvanced": "off"
  }
}

Peppol Directory je verejný register všetkých účastníkov Peppol. Publikovaním businessCard sa party stáva vyhľadateľnou v directory. BusinessCard obsahuje:

BusinessCard sa publikuje cez Enrollment endpoint alebo cez SMP konfiguráciu. Po publikácii je organizácia vyhľadateľná na directory.peppol.eu.

PSB API neodvodzuje žiadne polia z prepojeného obchodného registra. Bez ohľadu na schému identifikátora (KvK 0106, DPH 9944, OIN 0190, GLN 0088 alebo iné) musia byť v payloade explicitne uvedené polia names aj address s kódom krajiny. Príklad správne nakonfigurovanej businessCard:

"businessCard": {
  "names": {
    "value": "eVerbinding, eConnect",
    "state": "on",
    "description": "Business names."
  },
  "address": {
    "value": "Pelmolenlaan 16A, 3447 GW, Woerden, NL",
    "state": "on",
    "description": "Geographic information."
  },
  "emailAddress": {
    "value": "techsupport@econnect.eu",
    "state": "on",
    "description": "Technical contact"
  },
  "state": "on"
}

Kód krajiny (v príklade vyššie NL na konci poľa address) musí byť explicitne uvedený.

Táto chybová správa je diagnosticky jednoznačná: zaslaný payload neobsahuje names, alebo pole address neobsahuje kód krajiny. Riešením je vždy explicitné doplnenie týchto polí do payloadu businessCard, nie úprava na inej úrovni (party, identifikátor, SMP capabilities). Správa sa v praxi objavuje pomerne často pri integrácii GLN (0088), pretože integrační partneri využívajúci GLN menej často používajú šablónu, ktorá tieto polia štandardne odosiela. PSB nemá pre GLN odlišné správanie ako pre ostatné schémy.

Predbežná kontrola, či je príjemca dostupný na Peppol, sa vykonáva podľa typu dokumentu a cez pokročilý lookup endpoint:

Odpoveď zobrazuje dostupné kanály, vybraný Access Point a podporované typy dokumentov. Tieto endpointy použite na predbežnú validáciu, či doručenie bude úspešné. Sú neobmedzene dostupné vo všetkých balíčkoch (proaktívna detekcia/discovery trás).

Poznámka: pri nezhodě SML/SMP na endpointe deliveryOption volanie nevráti chybu ihneď. V produkcii nie je implementovaná obsluha fail-fast: volanie pokračuje a vráti timeout až po približne 30 sekundách. Zohľadnite to pri spracovaní chýb vo vašej integrácii.

V sieti Peppol ukazuje jedno participantId v SML na jednu SMP. Záznamom Redirect v SMP možno pre konkrétne kombinácie typu dokumentu a identifikátora procesu odkázať na sekundárnu SMP. Peppol podporuje len jednu úroveň redirectu: cieľ redirectu nesmie sám obsahovať redirect.

Alternatívne zdroje pre SMP lookup: peppolautoriteit.nl/discover (NPa), peppol.helger.com a directory.peppol.eu (neúplné).

Každá party v SMP je identifikovaná cez identifikátor so schemeID. Najčastejšie používané schémy:

API PSB akceptuje numerický schemeID aj kód písmen: 9925:BE0835689642 je ekvivalentné s BE:VAT:BE0835689642. Pri externých vyhľadávacích nástrojoch (ako SMP lookup) sa musia používať oficiálne numerické schemeID.

Party môže mať viacero identifikátorov, ale každá faktúra môže obsahovať iba jeden EndpointID.

V Belgicku sa pre Peppol používajú dva typy identifikátorov. Číslo podniku (KBO, schemeID 0208) je primárne identifikačné číslo a povinné pre príjem Peppol. Registrácia na DIČ (schemeID 9925) je voliteľná, preto je vyhľadávanie belgickej organizácie podľa čísla podniku úspešnejšie ako podľa DIČ.

Číslo podniku sa dá odvodiť z DIČ odstránením prefixu kódu krajiny (BE). Napríklad: DIČ BE0835689642 zodpovedá číslu podniku 0835689642.

Pri odosielaní dokumentu PSB extrahuje Peppol identifikátor z elementu EndpointID v XML. Tento element určuje, ktorému príjemcovi sa dokument smeruje. Ak EndpointID chýba alebo je nesprávne vyplnený, dokument nie je platný a dostane stav InvoiceSentError.

Nesprávny XML sa automaticky neopakuje. Oprava je na strane zdrojového systému (softvérového balíka generujúceho faktúru), nie na strane PSB. Skontrolujte vopred cez queryRecipientParty, či je príjemca dostupný na sieti Peppol.

Validačné pravidlo NLCIUS, ktoré vyžaduje, aby schemeID prvku CompanyID malo hodnotu 0190 (OIN), ak je príjemcom verejný subjekt. Na platforme musia ID organizácie a "Odoslať cez" používať rovnaký typ identifikátora. Nezhoda vedie k validačnej chybe dokumentu.

Keď dodávateľ hlási, že faktúra bola doručená do eConnect ako Access Point, ale príjemca uvádza, že nič nedostal, diagnostika na strane príjemcu prebieha cez returnedMessageId.

returnedMessageId je ID, ktoré eConnect vytvorí v okamihu, keď Access Point dokument na úrovni AS4 prijme alebo odmietne. Zvyčajne má tvar GUID@econnect.eu. Podľa tohto ID môže podpora faktúru v systéme dohľadať a sledovať cestu spracovania.

Najčastejšie príčiny, prečo odosielajúci AP považuje dokument za "doručený", ale k príjemcovi nedorazí:

• Neplatný dokument: dokument je na úrovni AS4 odmietnutý prijímajúcim AP. Odosielajúci AP dostane chybové hlásenie.
• Porušenie Enveloping Compliance: odosielateľ a príjemca v dokumente nezodpovedajú odosielateľovi a príjemcovi na obálke (SBDH). Taká nezhoda vedie k odmietnutiu.

Cesta podpory: pomocou returnedMessageId podpora dohľadá takmer všetky dokumenty cez Management API. Ak vyhľadanie zlyhá, podpora zapojí TechSupport.

Chcete automatizovať celý registračný proces? Prečítajte si článok o Enrollment API, s ktorým nakonfigurujete registráciu, capability a hooky v jednom API volaní.

• Peppol registrácia cez API (Enrollment)
• Migrácia na alebo z eConnect
• Konfigurácia multi-channel doručenia
• Prehľad: Procurement Service Bus (PSB)
• Čo je Peppol a ako funguje sieť?
• Registrácia na Peppol (platforma)