El Service Metadata Publisher (SMP) es el directorio de la red Peppol. Cuando un Access Point (AP) envía un documento, utiliza el Participant Identifier del destinatario para encontrar -- a través del Service Metadata Locator (SML) y el Domain Name System (DNS) -- en qué SMP está registrado el destinatario, qué URL de endpoint llamar y qué tipos de documentos se admiten. Este artículo describe la cadena de descubrimiento paso a paso.

Peppol es una red abierta: no existe un buzón central que reciba y distribuya todos los documentos. En cambio, cada proveedor de servicios certificado mantiene su propio SMP con los metadatos de sus clientes -- qué documentos pueden recibir, a través de qué AP y con qué certificados firman. El AP remitente debe determinar dónde entregar el documento antes de cada envío, y utiliza para ello el SMP del destinatario.

La especificación SMP es una norma de la Organization for the Advancement of Structured Information Standards (OASIS). eConnect figura en la lista de soluciones conformes con eDelivery SMP de la Comisión Europea con su propia implementación.

Cada organización en Peppol tiene al menos un Participant Identifier, compuesto por un scheme y un value:

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

El scheme es un código de la lista de códigos Electronic Address Scheme (EAS) -- un registro de OpenPeppol de sistemas de identificación nacionales e internacionales. Los códigos EAS más utilizados:

Un resumen completo está disponible en docs.peppol.eu/edelivery/codelists/ y en ID Peppol e identificadores.

El AP remitente responde a tres preguntas para cada documento:

1. ¿Dónde está el SMP del destinatario? Búsqueda mediante SML / DNS NAPTR.
2. ¿Qué endpoint y qué certificado corresponden al tipo de documento deseado? Consulta al SMP.
3. ¿Qué perfil Peppol admite el destinatario? La respuesta está en la respuesta SMP (BIS Billing V3, NLCIUS, PINT EU, etc.).

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>

La ilustración end-to-end siguiente muestra cómo un Participant Identifier neerlandesa (número KvK) conduce a una URL de endpoint concreta:

1. El remitente quiere enviar una factura a:
   iso6523-actorid-upis::0106:54441587  (eConnect, EAS 0106 -- KvK)

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

3. El AP remitente consulta el SMP:
   GET https://smp.econnect.eu/iso6523-actorid-upis%3A%3A0106%3A54441587
   --> ServiceGroup con, entre otros, el DocumentTypeId para la factura NLCIUS

4. El AP remitente consulta los ServiceMetadata para 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. El AP remitente construye el SBDH con metadatos de enrutamiento,
   firma y envía vía AS4 + TLS a la EndpointURI.

Al registrarse en un SMP, se configuran capabilities por familia de documentos por organización:

Cada capability tiene un valor on, off o inherited. El conjunto completo de capabilities determina qué tipos de documentos puede encontrar el AP remitente en el SMP -- y por lo tanto para qué es realmente accesible un destinatario.

Los lookups SMP se realizan en cada envío. Para escala y robustez, el SMP de eConnect aplica su propia capa de caché: los lookups permanecen disponibles -- incluso si un SMP externo no está disponible temporalmente -- reutilizando metadatos en caché dentro del período de validez. eConnect garantiza un 99,99% de disponibilidad del SMP.

Dos términos similares que a menudo se confunden en la práctica:

• El SML (Service Metadata Locator) es la zona DNS central (edelivery.tech.ec.europa.eu para producción) en la que se publican todos los Participant Identifiers y que apunta al SMP correcto. Existe un SML de producción y uno de pruebas; OpenPeppol está asumiendo la gestión de la Comisión Europea (transición hasta finales de agosto de 2026).
• El SMP (Service Metadata Publisher) es el directorio de un proveedor de servicios individual. Cada SP gestiona su propio SMP para sus propios clientes.

Analogía con el DNS: el SML es la guía telefónica de nivel superior que remite a la guía regional correcta; el SMP es esa guía con los datos reales.

Un Participant Identifier solo puede estar registrado en un único SMP a la vez -- de lo contrario, C2 no sabría a dónde enviar el documento. Al cambiar de proveedor, se aplica un procedimiento de migración con una clave de migración: el SMP actual genera una clave, y el nuevo SMP la utiliza para asumir el registro sin interrupciones. Durante la transición, la organización sigue siendo accesible; el identificador no cambia, por lo que los socios comerciales no notan nada.

Además del SMP legible por máquina, existen dos interfaces públicas para consultas manuales:

• Peppol Directory -- directory.peppol.eu: el registro público de participantes de Peppol, con búsqueda por nombre de organización, país y Participant ID. Asíncrono: puede ir por detrás del estado SMP real.
• Peppol Lookup Service -- lookup.peppol.org, desde marzo de 2026: consulta el SMP directamente y muestra el estado de publicación actual. Útil para la resolución de problemas cuando el Directory y el registro real están desincronizados.

Para los clientes que deseen comprobar programáticamente si un destinatario es accesible, el Peppol Service Bus (PSB) de eConnect ofrece el endpoint queryRecipientParty que consulta el SMP directamente e indica a través de qué canal y formato es accesible el destinatario.

Un destinatario puede ser localizable en Peppol -- la búsqueda NAPTR y la consulta SMP tienen éxito -- y aun así no poder recibir facturas. El SMP publica por tipo de documento una capability. La recepción de facturas cae bajo invoices; el envío de un estado empresarial (BIS Invoice Response 3.0) cae bajo la capability separada invoiceResponse. Son registros independientes.

Si un destinatario está registrado en su ID Peppol exclusivamente para Invoice Response transaction 3.0 (invoiceResponse en on, invoices en off), el AP remitente no encuentra ningún endpoint invoices en el SMP. No existe entonces ninguna ruta de entrega válida para una factura, y la plataforma eConnect indica No valid delivery options al enviar. El destinatario puede enviar un Invoice Response a través de ese identificador, pero no puede recibir una factura en él.

Dos soluciones:

1. Punto de entrega alternativo: pida al cliente que contacte al destinatario para preguntar por qué canal (correo electrónico o portal de proveedores) se puede entregar la factura.
2. Otro ID Peppol: compruebe si el destinatario tiene un segundo ID Peppol en el que el tipo de documento factura (invoices) esté registrado. Una organización puede registrar varios identificadores con capabilities de tipo de documento independientes por identificador.

En caso de duda, compruebe qué tipos de documentos publica un destinatario a través del Peppol Lookup Service o mediante programación a través de queryRecipientParty.