¿Qué es PunchOut? La guía completa para proveedores

Cómo funciona PunchOut

PunchOut conecta dos sistemas que no se diseñaron para comunicarse entre sí: el sistema de compras de su cliente y su tienda online. Las grandes organizaciones compran mediante sistemas de eProcurement como SAP Ariba, Coupa o SAP S/4HANA, donde cada compra sigue unas reglas de aprobación y se imputa al presupuesto correcto. En lugar de copiar sus productos a ese sistema, le piden un catálogo PunchOut: un enlace que abre su tienda desde su sistema de compras.

Una sesión PunchOut tiene cuatro pasos:

1. Configuración. Un solicitante hace clic en su catálogo dentro de su sistema de compras. El sistema envía al suyo una solicitud de configuración con credenciales y una dirección de devolución.
2. Compra. Su tienda se abre en su navegador, con la sesión ya iniciada con el rol de ese cliente, con su catálogo y sus precios contractuales.
3. Devolución del carrito. El solicitante llena el carrito y hace clic en «devolver» (o «finalizar compra»). En lugar de pasar por su proceso de pago, el carrito vuelve a su sistema de compras como un mensaje estructurado.
4. Aprobación y pedido. El carrito pasa por la aprobación interna del cliente. Una vez aprobado, se le envía el pedido de compra y usted lo tramita como cualquier otro pedido.

Para el cliente, su tienda se integra en su proceso de compras: ve precios y existencias en tiempo real, y cada pedido sigue sus reglas. Para usted, los pedidos llegan con el número de pedido de compra del cliente y sin introducir datos manualmente en ninguna de las partes.

PunchOut frente a un catálogo estático

Algunos clientes también piden a los proveedores un archivo de catálogo estático (a menudo un CIF o un índice cXML) que se carga en su sistema. Los dos modelos son complementarios:

Si su surtido es pequeño y estable, puede bastar un archivo. Si vende miles de productos, artículos configurables o con precios específicos por cliente, los clientes suelen preferir PunchOut.

Los dos protocolos: cXML y OCI

Cada sesión PunchOut utiliza uno de dos protocolos, según el sistema de su cliente. cXML (Commerce eXtensible Markup Language) intercambia documentos XML mediante HTTPS y lo utilizan SAP Ariba, Coupa, Jaggaer, Ivalua, Oracle, Workday y la mayoría de los sistemas source-to-pay. También transmite el propio pedido de compra como OrderRequest. OCI (Open Catalog Interface) es el protocolo de SAP, utilizado por SAP S/4HANA, SRM y ECC: su tienda se abre con un HOOK_URL y el carrito vuelve como campos de formulario HTML denominados NEW_ITEM-*. El pedido de compra le llega después por un canal independiente.

Nuestra guía cXML frente a OCI compara ambos mensaje a mensaje, con ejemplos.

Por qué los clientes piden PunchOut

Para el cliente, PunchOut resuelve tres problemas a la vez. Primero, el control: cada compra empieza dentro de su sistema de compras y sigue sus reglas de aprobación, presupuestos y proveedores preferentes. Segundo, la precisión: los precios, códigos de producto y descripciones proceden de su tienda, por lo que nadie los vuelve a introducir y las facturas coinciden con los pedidos. Tercero, la comodidad para quienes compran: utilizan una tienda real, con búsqueda, filtros y configuraciones, en lugar de una lista estática.

Para un proveedor, la solicitud suele llegar con un plazo: un nuevo contrato, un acuerdo marco o una licitación que incluye PunchOut entre sus requisitos. Los proveedores que responden rápido conservan al cliente; quienes no pueden hacerlo a menudo son sustituidos por un competidor que sí puede.

Quién participa

Un proyecto PunchOut implica a varias personas en ambas partes. Identificarlas pronto ahorra semanas:

PunchOut de nivel 1 y nivel 2

Puede encontrar referencias a dos niveles de PunchOut. El nivel 1 abre la página de inicio de su tienda: el cliente busca y navega allí. El nivel 2 permite al cliente buscar en su propio sistema de compras, donde se carga un índice breve de sus productos, y abre su tienda directamente en el producto o categoría elegido. El nivel 2 necesita un archivo de índice estático además de la tienda en tiempo real, así que pregunte al cliente qué nivel espera; la mayoría empieza con el nivel 1.

Qué sistemas de compras utilizan PunchOut

Prácticamente todos. SAP Ariba es la solicitud más habitual que recibimos de proveedores, seguido de SAP mediante OCI y Coupa. Jaggaer, Ivalua, GEP SMART, Oracle, Workday y decenas de herramientas procure-to-pay para medianas empresas también admiten PunchOut. Consulte la lista completa de sistemas compatibles.

Qué le pedirá su cliente

El departamento de compras de su cliente suele enviar documentación para proveedores o un email de incorporación. Léalo primero: enumera exactamente lo que espera. Normalmente le pedirán o facilitarán:

• Credenciales: para cXML, identidades (en SAP Ariba, el Ariba Network ID o ANID de ambas empresas) y un shared secret; para OCI, parámetros de acceso a su catálogo.
• URL: la URL de configuración que expone su sistema y la URL de devolución (cXML) o HOOK_URL (OCI) del sistema del cliente.
• Reglas del catálogo: qué productos y precios debe ver este cliente, unidades de medida y un estándar de clasificación (UNSPSC o ECLASS) a un nivel determinado.
• Un plan de pruebas: un entorno de pruebas y fechas para su prueba de aceptación de usuario (UAT).
• Documentos, en licitaciones y con grandes clientes: información sobre seguridad y alojamiento, un acuerdo de encargo de tratamiento y referencias.

Las respuestas varían según el sistema; nuestras páginas sobre SAP Ariba, SAP OCI y Coupa las detallan.

Qué cambia en su tienda

PunchOut exige a una tienda cosas que los compradores web habituales nunca hacen. Estos son los bloqueos más frecuentes:

• Abrirse dentro de otro sitio. Muchos sistemas de compras muestran su tienda en un marco o una ventana nueva que controlan. Cabeceras de seguridad como X-Frame-Options y cookies sin SameSite=None; Secure interrumpen la sesión. Consulte la guía del error de iframe.
• Iniciar sesión con el cliente correcto, para que vea su surtido y precios de contrato sin contraseña.
• Devolver el carrito en lugar de ejecutar su proceso de pago, en el formato que espera el sistema del cliente.
• Datos de producto: unidades de medida asociadas con los códigos del cliente y un código de clasificación para cada producto. Consulte categorías PunchOut.
• Recibir el pedido: importar el pedido de compra aprobado a su tienda.

Un plugin y un gateway PunchOut gestionan estos aspectos de forma estándar, para que la tienda, el tema y el proceso de pago que ya tiene sigan funcionando para sus demás clientes.

Un plan realista de 30 días

La configuración técnica de una conexión PunchOut en una plataforma compatible lleva horas, no semanas. Lo que lleva tiempo es la coordinación con el cliente. Un plan habitual:

La cola de pruebas del cliente determina la fecha final: algunos departamentos de compras programan las UAT con semanas de antelación. Pida las fechas pronto y, si el plazo es ajustado, valore encargar la configuración a especialistas, por ejemplo con nuestro servicio Go-Live Assist.

Cuánto cuesta PunchOut

Hay tres formas habituales de responder a una solicitud PunchOut, con costes muy diferentes:

• Un proyecto de integración a medida desarrollado por un programador o agencia para su tienda. Paga el desarrollo y las pruebas de cada protocolo y cliente, y el mantenimiento cuando cambia su plataforma o el sistema del cliente.
• Un servicio que cobra por cliente, normalmente una cuota mensual por cliente conectado más gastos de configuración. Económico para uno, caro al añadir más.
• Un plugin con un gateway gestionado como PunchOut Rocket: un precio anual fijo por sitio. PunchOut Rocket cuesta 1.950 € al año para WooCommerce y 2.950 € para Magento, PrestaShop, nopCommerce o la REST API, con hasta 10 clientes incluidos.

Consulte los precios para ver la lista completa y una calculadora comparativa.

Lista de comprobación antes de las pruebas del cliente

• Las credenciales y URL del entorno de pruebas están configuradas y una sesión de prueba funciona de principio a fin.
• El cliente solo ve los productos y precios acordados en el contrato.
• Cada producto del surtido del cliente tiene el código de clasificación y la unidad de medida exigidos.
• El carrito devuelto contiene sus códigos de producto, precios, cantidades y moneda como espera el cliente.
• Sabe cómo le llegará el pedido de compra (cXML OrderRequest u otro canal acordado con el cliente) y quién lo gestiona.
• Tiene un contacto en el equipo del cliente para el día de las pruebas, y el cliente tiene el suyo.

Errores habituales

• Empezar por la tienda antes de leer la documentación para proveedores del cliente: suele incluir reglas de campos que cambian la configuración.
• Probar solo en el sistema de producción del cliente: pida siempre primero el entorno de pruebas.
• Olvidar las unidades de medida y la clasificación: los carritos se rechazan si los códigos no coinciden con los del cliente.
• Subestimar el calendario del cliente: puede que no haya huecos para UAT hasta dentro de semanas. Resérvelos en cuanto tenga las credenciales.
• Prometer confirmaciones de pedido, avisos de envío o facturas mediante cXML sin la opción adecuada: las confirmaciones y avisos requieren la opción OC & ASN; las facturas se presupuestan bajo petición.