Service Metadata Publisher (SMP) to katalog adresowy sieci Peppol. Gdy Access Point (AP) wysyła dokument, używa Participant Identifier odbiorcy, aby -- przez Service Metadata Locator (SML) i Domain Name System (DNS) -- ustalić, w którym SMP odbiorca jest zarejestrowany, jaki URL punktu końcowego wywołać i jakie typy dokumentów są obsługiwane. Ten artykuł opisuje łańcuch odkrycia krok po kroku.

Peppol jest otwartą siecią: nie istnieje centralna skrzynka pocztowa, która odbiera i dystrybuuje wszystkie dokumenty. Zamiast tego każdy certyfikowany dostawca usług prowadzi własny SMP z metadanymi swoich klientów -- jakie dokumenty mogą odbierać, przez jaki AP i jakimi certyfikatami podpisują. Wysyłający AP musi przed każdym przesłaniem ustalić, dokąd trafić ma dokument, i w tym celu używa SMP odbiorcy.

Specyfikacja SMP jest standardem Organization for the Advancement of Structured Information Standards (OASIS). eConnect figuruje na liście rozwiązań zgodnych z eDelivery SMP Komisji Europejskiej z własną implementacją.

Każda organizacja w Peppol ma co najmniej jeden Participant Identifier, zbudowany ze scheme i value:

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

Scheme to kod z listy kodów Electronic Address Scheme (EAS) -- rejestru OpenPeppol krajowych i międzynarodowych systemów identyfikacji. Najczęściej używane kody EAS:

Pełny przegląd dostępny jest na docs.peppol.eu/edelivery/codelists/ i w ID Peppol i identyfikatory.

Wysyłający AP odpowiada na trzy pytania dla każdego dokumentu:

1. Gdzie znajduje się SMP odbiorcy? Wyszukiwanie przez SML / DNS NAPTR.
2. Który punkt końcowy i certyfikat odpowiadają żądanemu typowi dokumentu? Wyszukiwanie w SMP.
3. Jaki profil Peppol obsługuje odbiorca? Odpowiedź znajduje się w odpowiedzi SMP (BIS Billing V3, NLCIUS, PINT EU, itp.).

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>

Poniższa ilustracja end-to-end pokazuje, jak niderlandzki Participant Identifier (numer KvK) prowadzi do konkretnego URL punktu końcowego:

1. Nadawca chce wysłać fakturę do:
   iso6523-actorid-upis::0106:54441587  (eConnect, EAS 0106 -- KvK)

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

3. AP nadawcy odpytuje SMP:
   GET https://smp.econnect.eu/iso6523-actorid-upis%3A%3A0106%3A54441587
   --> ServiceGroup z m.in. DocumentTypeId dla faktury NLCIUS

4. AP nadawcy odpytuje ServiceMetadata dla NLCIUS:
   GET https://smp.econnect.eu/iso6523-actorid-upis%3A%3A0106%3A54441587/services/<NLCIUS-DocumentTypeId>
   --> EndpointURI: https://ap.econnect.eu/as4
   --> Certificate: <X.509 / cert. PKI>
   --> TransportProfile: peppol-transport-as4-v2_0

5. AP nadawcy tworzy SBDH z metadanymi routingu,
   podpisuje i wysyła przez AS4 + TLS do EndpointURI.

Przy rejestracji w SMP konfigurowane są capability dla każdej rodziny dokumentów na organizację:

Każda capability ma wartość on, off lub inherited. Pełny zestaw capability określa, jakie typy dokumentów wysyłający AP może znaleźć w SMP -- a tym samym dla czego odbiorca jest faktycznie osiągalny.

Lookup SMP jest wykonywany przy każdym wysyłaniu. Dla skali i niezawodności SMP eConnect stosuje własną warstwę buforowania: lookups pozostają dostępne -- nawet jeśli zewnętrzny SMP jest tymczasowo niedostępny -- ponownie wykorzystując buforowane metadane w okresie ważności. eConnect gwarantuje 99,99% dostępności SMP.

Dwa podobnie brzmiące terminy, które w praktyce są często mylone:

• SML (Service Metadata Locator) to centralna strefa DNS (edelivery.tech.ec.europa.eu dla produkcji), w której publikowane są wszystkie Participant Identifiers i która wskazuje właściwy SMP. Istnieje jeden produkcyjny SML i jeden testowy; OpenPeppol przejmuje zarządzanie od Komisji Europejskiej (przejście do końca sierpnia 2026).
• SMP (Service Metadata Publisher) to katalog indywidualnego dostawcy usług. Każdy SP prowadzi własny SMP dla własnych klientów.

Analogia z DNS: SML to centralna książka telefoniczna, która odsyła do właściwego regionalnego katalogu; SMP to ten katalog z rzeczywistymi danymi.

Participant Identifier może być zarejestrowany tylko w jednym SMP naraz -- w przeciwnym razie C2 nie wiedziałby, dokąd wysłać dokument. Przy zmianie dostawcy obowiązuje procedura migracji z kluczem migracyjnym: obecny SMP generuje klucz, a nowy SMP używa go do bezproblemowego przejęcia rejestracji. Podczas przejścia organizacja pozostaje osiągalna; identyfikator się nie zmienia, więc partnerzy handlowi niczego nie zauważą.

Oprócz czytelnego maszynowo SMP, istnieją dwa publiczne interfejsy do ręcznych wyszukiwań:

• Peppol Directory -- directory.peppol.eu: publiczny rejestr uczestników Peppol, z wyszukiwaniem po nazwie organizacji, kraju i Participant ID. Asynchroniczny i nierzetelny do weryfikacji osiągalności: Directory pobiera dane okresowo z SMP, a usługa Directory bywa tymczasowo niedostępna. W efekcie rejestracja lub wy-rejestracja może pojawić się w Directory z opóźnieniem -- lub wcale. Organizacja może więc widnieć w Directory, podczas gdy wyszukiwanie SMP zwraca No valid delivery options / PartyId not found, lub odwrotnie. Nie traktuj Directory jako dowodu, że ktoś może lub nie może odbierać.
• Peppol Lookup Service -- lookup.peppol.org, od marca 2026: bezpośrednio odpytuje SMP i pokazuje aktualny status publikacji. Przydatny podczas rozwiązywania problemów, gdy Directory i rzeczywista rejestracja są rozsynchronizowane.

Aby uzyskać wiarygoodną odpowiedź na pytanie czy ten odbiorca może lub nie może odbierać, należy wykonać prawdziwe wyszukiwanie SMP -- nie polegaj na widoku Directory. Dwa publiczne narzędzia wykonują rzeczywiste wyszukiwanie Peppol (to samo, które wykonuje PSB eConnect):

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

Jeśli wyszukiwanie powiedzie się w jednym z tych narzędzi, odbiorca jest osiągalny; jeśli się nie powiedzie (PartyId not found / brak opcji dostawy), odbiorca nie jest podłączony dla tego typu dokumentu -- niezależnie od tego, co pokazuje Peppol Directory. Programowo queryRecipientParty PSB daje ten sam, miarodajny wynik.

W Peppol Directory pole „additional information" wyświetla nazwę rejestrującego dostawcy usług -- w przypadku rejestracji przez PSB eConnect widnieje tam „eConnect". Są to metadane registrara SMP rejestrującego SP i nie stanowią części konfigurowalnej per uczestnik businessCard. Pola konfigurowalne per uczestnik są obsługiwane przez businessCard.names; pole „additional information" leży poza tym zakresem i w związku z tym nie jest konfigurowalne per uczestnik -- także dla partnerów white-label rejestrujących się przez endpoint PSB eConnect.

Dla klientów, którzy chcą programowo sprawdzić, czy odbiorca jest osiągalny, Peppol Service Bus (PSB) eConnect oferuje endpoint queryRecipientParty, który bezpośrednio odpytuje SMP i wskazuje, przez jaki kanał i w jakim formacie odbiorca jest osiągalny.

Odbiorca może być odnajdywalny w Peppol -- wyszukiwanie NAPTR i zapytanie SMP kończą się sukcesem -- a mimo to nie być w stanie otrzymywać faktur. SMP publikuje bowiem dla każdego typu dokumentu oddzielną capability. Odbieranie faktur należy do invoices; zwracanie statusu biznesowego (BIS Invoice Response 3.0) należy do oddzielnej capability invoiceResponse. Są to niezależne rejestracje.

Jeśli odbiorca jest zarejestrowany na swoim ID Peppol wyłącznie dla Invoice Response transaction 3.0 (invoiceResponse ustawione na on, invoices na off), wysyłający AP nie znajduje żadnego punktu końcowego invoices w SMP. Nie istnieje wtedy żadna prawidłowa ścieżka dostarczenia faktury, a platforma eConnect zgłasza No valid delivery options podczas wysyłania. Odbiorca może wysłać Invoice Response przez ten identyfikator, ale sam nie może przez niego odbierać faktur.

Dwa rozwiązania:

1. Alternatywny punkt dostarczenia: poproś klienta, aby skontaktował się z odbiorcą i zapytał, przez jaki kanał (e-mail lub portal dostawcy) można dostarczyć fakturę.
2. Inne ID Peppol: sprawdź, czy odbiorca ma drugie ID Peppol, na którym typ dokumentu faktury (invoices) jest zarejestrowany. Organizacja może rejestrować wiele identyfikatorów z oddzielnymi capability typów dokumentów na identyfikator.

W razie wątpliwości sprawdź, jakie typy dokumentów publikuje odbiorca za pośrednictwem Peppol Lookup Service lub programowo przez queryRecipientParty.