Service Metadata Publisher (SMP) je adresář sítě Peppol. Když Access Point (AP) odesílá dokument, použije Participant Identifier příjemce, aby -- prostřednictvím Service Metadata Locator (SML) a Domain Name System (DNS) -- zjistil, v jakém SMP je příjemce zaregistrován, jakou URL koncového bodu volat a které typy dokumentů jsou podporovány. Tento článek popisuje řetěz objevování krok za krokem.

Peppol je otevřená síť: neexistuje centrální poštovní schránka, která by přijímala a distribuovala všechny dokumenty. Místo toho každý certifikovaný poskytovatel služeb spravuje vlastní SMP s metadaty svých zákazníků -- které dokumenty mohou přijímat, přes jaký AP a jakými certifikáty podepisují. Odesílající AP musí před každým odesláním zjistit, kam dokument doručit, a k tomu využívá SMP příjemce.

Specifikace SMP je standardem Organization for the Advancement of Structured Information Standards (OASIS). eConnect je uveden na seznamu řešení kompatibilních s eDelivery SMP Evropské komise s vlastní implementací.

Každá organizace v Peppolu má alespoň jeden Participant Identifier, složený ze scheme a value:

iso6523-actorid-upis::<scheme>:<value>

Scheme je kód ze seznamu kódů Electronic Address Scheme (EAS) -- registru OpenPeppol národních a mezinárodních identifikačních systémů. Nejčastěji používané kódy EAS:

Úplný přehled je k dispozici na docs.peppol.eu/edelivery/codelists/ a v Peppol ID a identifikátory.

Odesílající AP odpovídá na tři otázky pro každý dokument:

1. Kde se nachází SMP příjemce? Vyhledávání přes SML / DNS NAPTR.
2. Který koncový bod a certifikát odpovídají požadovanému typu dokumentu? Vyhledávání v SMP.
3. Jaký profil Peppol příjemce podporuje? Odpověď je v odpovědi SMP (BIS Billing V3, NLCIUS, PINT EU atd.).

B-<md5>.iso6523-actorid-upis.edelivery.tech.ec.europa.eu

B-<md5>.iso6523-actorid-upis.edelivery.tech.ec.europa.eu
   IN NAPTR 100 10 "U" "Meta:SMP" "!^.*$!https://smp.example.com/!" .

GET https://smp.example.com/iso6523-actorid-upis%3A%3A0106%3A54441587

GET https://smp.example.com/iso6523-actorid-upis%3A%3A0106%3A54441587/services/<DocumentTypeId>

Následující end-to-end ilustrace ukazuje, jak nizozemský Participant Identifier (číslo KvK) vede ke konkrétnímu URL koncového bodu:

1. Odesílatel chce poslat fakturu:
   iso6523-actorid-upis::0106:54441587  (eConnect, EAS 0106 -- KvK)

2. AP odesílatele provede DNS NAPTR lookup:
   B-<md5>.iso6523-actorid-upis.edelivery.tech.ec.europa.eu
   --> URL SMP: https://smp.econnect.eu/

3. AP odesílatele dotazuje SMP:
   GET https://smp.econnect.eu/iso6523-actorid-upis%3A%3A0106%3A54441587
   --> ServiceGroup mimo jiné s DocumentTypeId pro fakturu NLCIUS

4. AP odesílatele dotazuje ServiceMetadata pro NLCIUS:
   GET https://smp.econnect.eu/iso6523-actorid-upis%3A%3A0106%3A54441587/services/<NLCIUS-DocumentTypeId>
   --> EndpointURI: https://ap.econnect.eu/as4
   --> Certificate: <X.509 / certifikát PKI>
   --> TransportProfile: peppol-transport-as4-v2_0

5. AP odesílatele vytvoří SBDH s metadaty routování,
   podepíše a odešle přes AS4 + TLS na EndpointURI.

Při registraci v SMP jsou na organizaci nakonfigurovány capabilities pro každou rodinu dokumentů:

Každá capability má hodnotu on, off nebo inherited. Úplná sada capabilities určuje, které typy dokumentů může odesílající AP v SMP najít -- a tedy pro co je příjemce fakticky dosažitelný.

Lookup SMP se provádí při každém odesílání. Pro škálovatelnost a robustnost používá eConnect SMP vlastní cachovací vrstvu: lookup zůstává dostupný -- i když externí SMP dčasně nereaguje -- opětovným použitím cacheovaných metadat v rámci doby platnosti. eConnect garantuje 99,99% dostupnost SMP.

Dva podobně znějící pojmy, které jsou v praxi často zaměňovány:

• SML (Service Metadata Locator) je centrální zóna DNS (edelivery.tech.ec.europa.eu pro produkci), ve které jsou zveřejněny všechny Participant Identifiers a která odkazuje na správný SMP. Existuje jeden produkční SML a jeden testovací; OpenPeppol přebírá správu od Evropské komise (přechod do konce srpna 2026).
• SMP (Service Metadata Publisher) je adresář jednotlivého poskytovatele služeb. Každý SP provozuje vlastní SMP pro své vlastní zákazníky.

Analogie s DNS: SML je centrální telefonní seznam, který odkazuje na správný regionální adresář; SMP je ten adresář se skutečnými daty.

Participant Identifier může být registrován pouze u jednoho SMP najednou -- jinak by C2 nevěděl, kam dokument odeslat. Při změně poskytovatele platí migrační postup s migračním klíčem: aktuální SMP vygeneruje klíč a nový SMP jej použije k bezproblemému převzetí registrace. Během přechodu zůstává organizace dostupná; identifikátor se nemění, takže obchodní partneré nic nezaznamenají.

Vedle strojově čitelného SMP existují dva veřejné portály pro ruční vyhledávání:

• Peppol Directory -- directory.peppol.eu: veřejný registr účastníků Peppol s vyhledáváním podle názvu organizace, země a Participant ID. Asynchronní a nespolehlivý pro ověřování dostupnosti: Directory nacítá svá data ze SMP periodicky a služba Directory je někdy dočasně nedostupná. V důsledku toho se registrace nebo odregistrace může v Directory zobrazit se zpožbením -- nebo vůbec. Organizace tedy může figurovat v Directory, zatímco vyhledávání SMP vrací No valid delivery options / PartyId not found, nebo naopak. Nepoužívejte Directory jako důkaz, že někdo může nebo nemůže přijímat.
• Peppol Lookup Service -- lookup.peppol.org, od března 2026: dotazuje SMP přímo a zobrazuje aktuální stav publikace. Užitečné při odstraňování problémů, kdy se Directory a skutečná registrace liší.

Pro spolehlivé zodpovězení otázky může tento příjemce přijímat, nebo ne je nutné provést skutečné vyhledávání SMP -- nespoléhat na zobrazení v Directory. Dva veřejné nástroje provádějí skutečné vyhledávání Peppol (stejné jako PSB eConnect):

• test.peppolautoriteit.nl/discover
• peppol.helger.com

Pokud vyhledávání v některém z těchto nástrojů uspěje, příjemce je dostupný; pokud selhá (PartyId not found / žádné možnosti doručení), příjemce pro daný typ dokumentu není připojen -- bez ohledu na to, co zobrazuje Peppol Directory. Programově dává queryRecipientParty PSB stejný, směrodatný výsledek.

V adresáři Peppol Directory zobrazuje pole „additional information" název registrujícího poskytovatele služeb -- u registrací prostřednictvím PSB eConnect se zde zobrazuje „eConnect". Jde o metadata registrara SMP registrujícího SP a nejsou součástí businessCard konfigurovatelné per účastník. Pole konfigurovatelná per účastník jsou spravována přes businessCard.names; pole „additional information" leží mimo tento rozsah, a proto není konfigurovatelné per účastník -- ani pro white-label partnery registrující se přes endpoint PSB eConnect.

Pro zákazníky, kteří chtějí programově ověřit, zda je příjemce dosažitelný, nabízí Peppol Service Bus (PSB) eConnect endpoint queryRecipientParty, který SMP dotazuje přímo a uvádí, přes jaký kanál a formát je příjemce dosažitelný.

Příjemce může být v Peppolu dohledatelný -- vyhledávání NAPTR i dotaz SMP uspějí -- a přesto nemůže přijímat faktury. SMP totiž zveřejňuje pro každý typ dokumentu zvláštní capability. Přijímání faktur spadá pod invoices; vracení obchodního stavu (BIS Invoice Response 3.0) spadá pod oddělenou capability invoiceResponse. Jedná se o nezávislé registrace.

Je-li příjemce na svém ID Peppol zaregistrován výhradně pro Invoice Response transaction 3.0 (invoiceResponse nastaveno na on, invoices na off), odesílající AP v SMP nenajde žádný endpoint invoices. Neexistuje pak žádná platná cesta doručení faktury a platforma eConnect hlásí při odesílání No valid delivery options. Příjemce může přes tento identifikátor odeslat Invoice Response, ale sám na něj fakturu přijmout nemůže.

Dvě řešení:

1. Alternativní způsob doručení: požádejte zákazníka, aby kontaktoval příjemce a zeptal se, jakým kanálem (e-mail nebo dodavatelský portál) lze fakturu doručit.
2. Jiné Peppol ID: ověřte, zda má příjemce druhé Peppol ID, na němž je typ dokumentu faktury (invoices) zaregistrován. Organizace může registrovat více identifikátorů s vlastními capabilities typů dokumentů na identifikátor.

Při pochybnostech zkontrolujte, které typy dokumentů příjemce publikuje prostřednictvím Peppol Lookup Service nebo programově přes queryRecipientParty.