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 y poco fiable para las comprobaciones de accesibilidad: el Directory obtiene sus datos periódicamente de los SMP y el servicio Directory a veces no está disponible temporalmente. Como resultado, un registro o una baja puede aparecer en el Directory con retraso -- o no aparecer. Una organización puede por tanto figurar en el Directory mientras la búsqueda SMP devuelve No valid delivery options / PartyId not found, o a la inversa. No utilice el Directory como prueba de que alguien puede o no puede recibir.
• 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 obtener una respuesta fiable a la pregunta ¿puede recibir o no este destinatario?, debe realizarse una búsqueda SMP real -- no consultar la vista del Directory. Dos herramientas públicas realizan la búsqueda Peppol real (la misma búsqueda que ejecuta el PSB de eConnect):

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

Si la búsqueda tiene éxito en alguna de estas herramientas, el destinatario es accesible; si falla (PartyId not found / sin opciones de entrega), el destinatario no está conectado para ese tipo de documento -- independientemente de lo que muestre el Peppol Directory. Mediante programación, queryRecipientParty del PSB ofrece el mismo resultado autoritativo.

En el Peppol Directory, el campo «additional information» muestra el nombre del proveedor de servicios que realizó el registro -- en el caso de registros vía PSB de eConnect, aparece «eConnect». Se trata de metadatos de registrar SMP del SP registrador y no forman parte de la businessCard configurable por participante. Los campos configurables por participante se gestionan a través de businessCard.names; el campo «additional information» queda fuera de ese ámbito y, por tanto, no es configurable por participante -- ni siquiera para los socios de marca blanca que se registran a través del endpoint PSB de eConnect.

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.