PSB je certifikovaný Peppol Access Point a SMP (Service Metadata Publisher). Přes API se konfigurují typy dokumentů, které organizace může přijímat, publikují firemní údaje v Peppol Directory a spravuje se SMP registrace. Tento článek pokrývá technické pozadí a API endpointy, které se k tomu používají.

Peppol funguje s modelem 4-corner: odesílatel (C1) odesílá přes svůj Access Point (C2) dokument na Access Point příjemce (C3), který jej předá příjemci (C4). Routing probíhá přes dvě centrální komponenty:

• SML (Service Metadata Locator): centrální DNS registr, který odkazuje na správný SMP příjemce
• SMP (Service Metadata Publisher): obsahuje metadata příjemce, jaké dokumenty může přijímat a přes jaký Access Point

Když odešlete fakturu přes PSB, PSB automaticky provede SML/SMP lookup pro nalezení správného Access Pointu příjemce. Jako integrátor to nemusíte dělat sami.

Infrastruktura Peppol se aktivně vyvíjí. Pro integrátory používající API PSB to nemá žádný dopad: PSB provádí SML/SMP lookupy automaticky. Níže jsou aktuální změny pro informaci.

Insourcing SML. OpenPeppol přebírá správu SML od Evropské komise (DG DIGIT). Migrační okno bylo otevřeno 19. března 2026. Platí dva samostatné termíny: termín pro SMP registrace je 31. května 2026, migrační období pro AP Lookup (DNS rozlišení) bylo prodlouženo do 31. srpna 2026. OpenPeppol diskutuje s Evropskou komisí, zda je možné prodloužit i termín SMP registrace. Pro API integrátory se nic nemění v endpointech ani lookupech: PSB řeší migraci interně.

Migrace CNAME na NAPTR. Migrace DNS CNAME záznamů na NAPTR záznamy pro SML lookupy byla dokončena v březnu 2026. NAPTR je povinný od 1. února 2026. Staré CNAME záznamy byly odstraněny z testovací sítě SMK (4. března 2026) a produkční sítě SML (11. března 2026). Jde o interní DNS změnu v infrastruktuře Peppol. PSB již používá NAPTR a nejsou potřeba žádné úpravy integrace.

Migrace PKI G3. OpenPeppol připravuje přechod z certifikátů PKI Generation 2 (G2) na Generation 3 (G3). G3 certifikáty se používají pro vzájemnou komunikaci mezi Access Pointy. Peppol Testbed podporuje G2 i G3 certifikáty od března 2026, aby Service Providers mohli testovat předem. Povinné datum přechodu zatím nebylo zveřejněno. Pro API integrátory se nic nemění: PSB řeší obnovu certifikátů interně.

Peppol podporuje logistické typy dokumentů kromě faktur přes specifikaci Peppol Logistics. Verze 1.2 je povinná od 16. března 2026. Verze 1.3 je povinná od 24. srpna 2026.

Podporované logistické dokumenty:

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

Nové funkce ve vydání 1.3:

• ProductTraceID se schemeID pro ItemInstance
• DespatchAdviceTypeCode rozšířen o hodnoty pro identifikaci use case (101, 102, 112, 203-211, 303-311)
• DocumentStatusCode s novou hodnotou "55 - Notification only" pro změny po fakturaci
• Waste Declaration Number jako AdditionalItemProperty
• Nový seznam kódů ProductTraceIDschemeIDCode

Vydání 1.3 řeší RFC LLC-27 až LLC-35, včetně zarovnání ItemInstance, nefakturačních aktualizací a kódů podúpravy pro odpad.

Při registraci party v SMP eConnect se přes capability určují typy dokumentů, které tato party může přijímat. Každá capability má tři možné stavy:

Doporučená hodnota pro nové registrace je inherited, pokud party nemusí specificky odchýlit od standardu.

Capability se konfigurují přes Peppol config endpoint:

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

V body požadavku se uvede požadovaný stav pro každou capability. Příklad:

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

Peppol Directory je veřejný registr všech účastníků Peppol. Publikováním businessCard se party stává vyhledatelnou v directory. BusinessCard obsahuje:

BusinessCard se publikuje přes Enrollment endpoint nebo přes SMP konfiguraci. Po publikaci je organizace vyhledatelná na directory.peppol.eu.

PSB API neodvozuje žádná pole z propojeného obchodního rejstříku. Bez ohledu na schéma identifikátoru (KvK 0106, DPH 9944, OIN 0190, GLN 0088 nebo jiné) musí být v payloadu explicitně uvedena pole names i address s kódem země. Příklad správně nakonfigurované 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 země (v příkladu výše NL na konci pole address) musí být explicitně uveden.

Tato chybová zpráva je diagnosticky jednoznačná: zaslaný payload neobsahuje names, nebo pole address neobsahuje kód země. Řešením je vždy explicitní doplnění těchto polí do payloadu businessCard, nikoli úprava na jiné úrovni (party, identifikátor, SMP capabilities). Zpráva se v praxi objevuje poměrně často při integraci GLN (0088), protože integrační partneři používající GLN méně často využívají šablonu, která tato pole standardně odesílá. PSB nemá pro GLN odlišné chování než pro ostatní schémata.

Předběžná kontrola, zda je příjemce dostupný na Peppol, se provádí podle typu dokumentu a přes pokročilý lookup endpoint:

Odpověď zobrazuje dostupné kanály, vybraný Access Point a podporované typy dokumentů. Tyto endpointy použijte pro předběžnou validaci, zda doručení bude úspěšné. Jsou neomezeně dostupné ve všech balíčcích (proaktivní detekce/discovery tras).

Poznámka: při neshodě SML/SMP na endpointu deliveryOption volání nevrátí chybu ihned. V produkci není implementována obsluha fail-fast: volání pokračuje a vrátí timeout teprve po přibližně 30 sekundách. Vezměte to v úhaz v obsluže chyb své integrace.

V síti Peppol ukazuje jedno participantId v SML na jednu SMP. Záznamem Redirect v SMP lze pro konkrétní kombinace typu dokumentu a identifikátoru procesu odkázat na sekundární SMP. Peppol podporuje jen jednu úroveň redirectu: cíl redirectu nesmí sám obsahovat redirect.

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

Každá party v SMP je identifikována přes identifikátor se schemeID. Nejčastěji používané schémata:

API PSB přijímá numerický schemeID i kód písmen: 9925:BE0835689642 je ekvivalentní s BE:VAT:BE0835689642. Při použití externích vyhledávacích nástrojů (jako SMP lookup) se musí používat oficiální numerické schemeID.

Party může mít více identifikátorů, ale každá faktura může obsahovat pouze jeden EndpointID.

V Belgii se pro Peppol používají dva typy identifikátorů. Číslo podniku (KBO, schemeID 0208) je primární identifikační číslo a povinné pro příjem Peppol. Registrace na DIČ (schemeID 9925) je volitelná, proto je vyhledávání belgické organizace podle čísla podniku úspěšnější než podle DIČ.

Číslo podniku lze odvodit z DIČ odstraněním prefixu kódu země (BE). Například: DIČ BE0835689642 odpovídá číslu podniku 0835689642.

Při odesílání dokumentu PSB extrahuje Peppol identifikátor z elementu EndpointID v XML. Tento element určuje, kterému příjemci je dokument směrován. Pokud EndpointID chybí nebo je nesprávně vyplněn, dokument není platný a obdrží stav InvoiceSentError.

Nesprávný XML se automaticky neopakuje. Oprava je na straně zdrojového systému (softwarového balíku generujícího fakturu), nikoli na straně PSB. Zkontrolujte předem přes queryRecipientParty, zda je příjemce dostupný na síti Peppol.

Validační pravidlo NLCIUS, které vyžaduje, aby schemeID prvku CompanyID mělo hodnotu 0190 (OIN), pokud je příjemcem veřejný subjekt. Na platformě musí ID organizace a "Odeslat přes" používat stejný typ identifikátoru. Neshoda vede k validační chybě dokumentu.

Když dodavatel hlásí, že faktura byla doručena do eConnect jako Access Point, ale příjemce uvádí, že nic neobdržel, probíhá diagnostika na straně příjemce přes returnedMessageId.

returnedMessageId je ID, které eConnect vytvoří v okamžiku, kdy Access Point dokument na úrovni AS4 přijme nebo odmítne. Obvykle má tvar GUID@econnect.eu. Podle tohoto ID může podpora fakturu v systému dohledat a sledovat cestu zpracování.

Nejčastější příčiny, proč odesílající AP považuje dokument za "doručený", ale k příjemci nedorazí:

• Neplatný dokument: dokument je na úrovni AS4 odmítnut přijímajícím AP. Odesílající AP dostane chybové hlášení.
• Porušení Enveloping Compliance: odesílatel a příjemce v dokumentu neodpovídají odesílateli a příjemci na obálce (SBDH). Taková neshoda vede k odmítnutí.

Cesta podpory: pomocí returnedMessageId podpora dohledá téměř všechny dokumenty přes Management API. Pokud vyhledání selže, podpora zapojí TechSupport.

Chcete automatizovat celý registrační proces? Přečtěte si článek o Enrollment API, se kterou nakonfigurujete registraci, capability a hooky v jednom API volání.

• Peppol registrace přes API (Enrollment)
• Migrace na nebo z eConnect
• Konfigurace multi-channel doručení
• Přehled: Procurement Service Bus (PSB)
• Co je Peppol a jak funguje síť?
• Registrace na Peppol (platforma)