Come Peppol trova il destinatario corretto tramite SML, DNS NAPTR e SMP: passo dopo passo, inclusi i messaggi di errore comuni.
Il Service Metadata Publisher (SMP) è la rubrica della rete Peppol. Quando un Access Point (AP) invia un documento, utilizza il Participant Identifier del destinatario per trovare -- tramite il Service Metadata Locator (SML) e il Domain Name System (DNS) -- in quale SMP è registrato il destinatario, quale URL di endpoint chiamare e quali tipi di documento sono supportati. Questo articolo descrive la catena di scoperta passo dopo passo.
Peppol è una rete aperta: non esiste una casella di posta centrale che riceve e distribuisce tutti i documenti. Invece, ogni fornitore di servizi certificato gestisce il proprio SMP con i metadati dei propri clienti -- quali documenti possono ricevere, tramite quale AP e con quali certificati firmano. L'AP mittente deve determinare dove consegnare il documento prima di ogni invio, e utilizza per questo l'SMP del destinatario.
La specifica SMP è una norma dell'Organization for the Advancement of Structured Information Standards (OASIS). eConnect è elencato nell'elenco delle soluzioni conformi a eDelivery SMP della Commissione europea con la propria implementazione.
Ogni organizzazione su Peppol ha almeno un Participant Identifier, composto da uno scheme e un value:
iso6523-actorid-upis::<scheme>:<value>
Lo scheme è un codice dell'elenco di codici Electronic Address Scheme (EAS) -- un registro OpenPeppol di sistemi di identificazione nazionali e internazionali. I codici EAS più utilizzati:
iso6523-actorid-upis::0106:54441587iso6523-actorid-upis::0190:00000001820029336000iso6523-actorid-upis::9944:NL851306469B01iso6523-actorid-upis::0208:0899965307iso6523-actorid-upis::0204:991-01234-56iso6523-actorid-upis::0192:745707327iso6523-actorid-upis::0235:100123456700003iso6523-actorid-upis::0088:1548079098355Una panoramica completa è disponibile su docs.peppol.eu/edelivery/codelists/ e in ID Peppol e identificatori.
L'AP mittente risponde a tre domande per ogni documento:
Il Participant Identifier viene sottoposto a hash MD5 e codificato in esadecimale minuscolo. Il valore hash diventa l'etichetta più a sinistra di un dominio SML, seguita dallo scheme Peppol e dalla zona SML. Per la produzione:
B-<md5>.iso6523-actorid-upis.edelivery.tech.ec.europa.eu
L'ambiente di test Peppol utilizza una zona SML separata. Da marzo 2026, vengono pubblicati solo record NAPTR per produzione e test -- i vecchi record CNAME sono stati rimossi.
L'AP mittente esegue una query DNS sul dominio precedente, per il tipo di record NAPTR (Naming Authority Pointer). NAPTR è obbligatorio dal 1° febbraio 2026. La risposta NAPTR contiene un tag di servizio (Meta:SMP) e un campo regexp che punta all'URL SMP del destinatario:
B-<md5>.iso6523-actorid-upis.edelivery.tech.ec.europa.eu
IN NAPTR 100 10 "U" "Meta:SMP" "!^.*$!https://smp.example.com/!" .
Risultato: l'AP sa su quale URL SMP il destinatario è registrato.
Con l'URL SMP, l'AP costruisce l'URL dei metadati specifico per questo partecipante:
GET https://smp.example.com/iso6523-actorid-upis%3A%3A0106%3A54441587
L'SMP restituisce un ServiceGroup in XML con tutti i tipi di documento supportati. Per tipo di documento, l'AP può richiedere il ServiceMetadata tramite una seconda richiesta:
GET https://smp.example.com/iso6523-actorid-upis%3A%3A0106%3A54441587/services/<DocumentTypeId>
La risposta contiene l'URL di endpoint, il profilo di trasporto, il processo e il certificato PKI dell'AP ricevente. Con queste informazioni, C2 cifra e firma il documento, apre una connessione AS4 verso C3 all'EndpointURI trovato e lo consegna.
L'illustrazione end-to-end seguente mostra come un Participant Identifier olandese (numero KvK) porta a un URL di endpoint concreto:
1. Il mittente vuole inviare una fattura a:
iso6523-actorid-upis::0106:54441587 (eConnect, EAS 0106 -- KvK)
2. L'AP mittente esegue un lookup DNS NAPTR:
B-<md5>.iso6523-actorid-upis.edelivery.tech.ec.europa.eu
--> URL SMP: https://smp.econnect.eu/
3. L'AP mittente interroga l'SMP:
GET https://smp.econnect.eu/iso6523-actorid-upis%3A%3A0106%3A54441587
--> ServiceGroup con, tra gli altri, il DocumentTypeId per la fattura NLCIUS
4. L'AP mittente interroga i ServiceMetadata per 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. L'AP mittente costruisce l'SBDH con i metadati di instradamento,
firma e invia tramite AS4 + TLS all'EndpointURI.
Al momento della registrazione in un SMP, vengono configurate capability per famiglia di documenti per organizzazione:
invoicesselfbillinginvoiceResponseorderOnlyorderAdvancedorderResponsepintProfilesmls / mlrOgni capability ha un valore on, off o inherited. L'insieme completo delle capability determina quali tipi di documento l'AP mittente può trovare nell'SMP -- e quindi per cosa un destinatario è effettivamente raggiungibile.
I lookup SMP vengono eseguiti ad ogni invio. Per scalabilità e robustezza, l'SMP di eConnect applica un proprio livello di cache: i lookup rimangono disponibili -- anche se un SMP esterno è temporaneamente irraggiungibile -- riutilizzando i metadati in cache nel periodo di validità. eConnect garantisce il 99,99% di uptime sull'SMP.
Due termini simili che vengono spesso confusi nella pratica:
edelivery.tech.ec.europa.eu per la produzione) in cui vengono pubblicati tutti i Participant Identifier e che punta all'SMP corretto. Esiste un SML di produzione e uno di test; OpenPeppol sta assumendo la gestione dalla Commissione europea (transizione fino alla fine di agosto 2026).Analogia con il DNS: l'SML è l'elenco telefonico di primo livello che rimanda alla giusta directory regionale; l'SMP è quella directory con i dati effettivi.
Un Participant Identifier può essere registrato solo presso un SMP alla volta -- altrimenti C2 non saprebbe dove inviare il documento. In caso di cambio di fornitore, si applica una procedura di migrazione con una chiave di migrazione: l'SMP attuale genera una chiave, e il nuovo SMP la utilizza per assumere la registrazione in modo trasparente. Durante la transizione, l'organizzazione rimane raggiungibile; l'identificatore non cambia, quindi i partner commerciali non si accorgono di nulla.
Oltre all'SMP leggibile dalle macchine, esistono due interfacce pubbliche per ricerche manuali:
No valid delivery options / PartyId not found, o viceversa. Non utilizzare il Directory come prova che qualcuno possa o non possa ricevere.Per una risposta affidabile alla domanda questo destinatario può ricevere o no, è necessario eseguire una vera ricerca SMP -- non consultare la vista del Directory. Due strumenti pubblici eseguono la ricerca Peppol reale (la stessa ricerca eseguita dal PSB di eConnect):
Se la ricerca ha successo in uno di questi strumenti, il destinatario è raggiungibile; se fallisce (PartyId not found / nessuna opzione di consegna), il destinatario non è connesso per quel tipo di documento -- indipendentemente da ciò che mostra il Peppol Directory. Programmaticamente, queryRecipientParty del PSB fornisce lo stesso risultato autorevole.
Nel Peppol Directory, il campo «additional information» mostra il nome del fornitore di servizi che ha effettuato la registrazione -- per le registrazioni tramite PSB di eConnect appare «eConnect». Si tratta di metadati registrar SMP del SP registrante e non fanno parte della businessCard configurabile per partecipante. I campi configurabili per partecipante vengono gestiti tramite businessCard.names; il campo «additional information» è al di fuori di tale ambito e pertanto non è configurabile per partecipante -- nemmeno per i partner in white label che si registrano tramite l'endpoint PSB di eConnect.
Per i clienti che desiderano verificare programmaticamente se un destinatario è raggiungibile, il Peppol Service Bus (PSB) di eConnect offre l'endpoint queryRecipientParty che interroga l'SMP direttamente e indica tramite quale canale e formato il destinatario è raggiungibile.
SMP not found / la risoluzione NAPTR falliscequeryRecipientPartyService not foundNo valid delivery optionsinvoices -- vedere sezione seguenteCertificate expired / invalidEndpoint not reachablequeryRecipientParty timeoutUn destinatario può essere rintracciabile su Peppol -- la ricerca NAPTR e la query SMP hanno successo -- eppure non essere in grado di ricevere fatture. L'SMP pubblica infatti per tipo di documento una capability. La ricezione di fatture rientra in invoices; il rinvio di uno stato aziendale (BIS Invoice Response 3.0) rientra nella capability separata invoiceResponse. Queste sono registrazioni indipendenti.
Se un destinatario è registrato sul suo ID Peppol esclusivamente per Invoice Response transaction 3.0 (invoiceResponse su on, invoices su off), l'AP mittente non trova alcun endpoint invoices nell'SMP. Non esiste quindi alcun percorso di consegna valido per una fattura, e la piattaforma eConnect segnala No valid delivery options all'invio. Il destinatario può inviare un Invoice Response tramite quell'identificatore, ma non può ricevere una fattura su di esso.
Importante: questo non è un errore da parte di eConnect o del mittente -- è un riflesso accurato di ciò che il destinatario ha pubblicato nel proprio SMP.
Due soluzioni:
invoices) è registrato. Un'organizzazione può registrare più identificatori con capability di tipo di documento indipendenti per identificatore.In caso di dubbio, verificare quali tipi di documento pubblica un destinatario tramite il Peppol Lookup Service o programmaticamente tramite queryRecipientParty.
Il Peppol Directory (directory.peppol.eu) è un registro asincrono che recupera periodicamente i dati dagli SMP. Può essere in ritardo rispetto allo stato di registrazione effettivo ed è quindi inaffidabile per le verifiche di raggiungibilità. Il Peppol Lookup Service (lookup.peppol.org) interroga l'SMP direttamente e mostra lo stato attuale. Per la risoluzione dei problemi, il Lookup Service è autorevole. Alternative che interrogano anche direttamente l'SMP: test.peppolautoriteit.nl/discover e peppol.helger.com.
Un destinatario può figurare nel registro Peppol ma essere registrato esclusivamente per Invoice Response (capability invoiceResponse) e non per ricevere fatture (capability invoices). Non esiste quindi alcun percorso di consegna valido per una fattura. Verificare tramite queryRecipientParty o il Peppol Lookup Service quali capability sono attive, e contattare il destinatario per un punto di consegna alternativo o un altro ID Peppol.
Una modifica nella registrazione SMP effettiva ha effetto al prossimo invio: l'AP mittente interroga l'SMP per ogni invio. Le visualizzazioni esterne non autorevoli come il Peppol Directory (directory.peppol.eu) o peppolcheck.be possono mostrare la modifica più tardi a causa della propria strategia di caching e del recupero asincrono. Si noti la distinzione: gli strumenti che interrogano l'SMP direttamente -- come test.peppolautoriteit.nl/discover e peppol.helger.com -- mostrano sempre lo stato attuale. Per lo stato autorevole, il Peppol Lookup Service o una query SMP diretta tramite queryRecipientParty è determinante.
Sì. Un'organizzazione può registrare più Participant Identifier -- ciascuno su uno scheme EAS diverso (ad esempio KvK e numero IVA). Per identificatore, è possibile configurare capability di tipo di documento indipendenti. Se una fattura viene rifiutata su un ID con No valid delivery options, vale la pena verificare se il destinatario ha un altro ID Peppol con la capability invoices attivata.
Ulteriori informazioni su ID Peppol e identificatori