Conectar SPS Commerce: pedidos EDI entrantes, ASN y facturas salientes

Copie la URL base de la API desde sus documentos de apertura de SPS, tome el Client ID y el Client Secret emitidos juntos al abrir su cuenta de SPS, pegue los tres en Integration, pruebe, mapee cada socio comercial y active: entran pedidos 850 y salen documentos 856 / 810.

El conector de SPS Commerce intercambia documentos EDI con sus socios comerciales minoristas a través de SPS Commerce (RSX / API): los documentos entrantes, como las órdenes de compra 850, llegan de los socios y se convierten en pedidos, y los documentos salientes, como los avisos de envío 856 y las facturas 810, vuelven a los mismos socios. No es una conexión de tienda ni hay autorización de tienda: todo se organiza por socio comercial y por tipo de documento, así que cada socio se configura y se comprueba por separado.

Requisitos previos#

• Una cuenta de SPS Commerce abierta con acceso a la API. Sus credenciales y su URL base de la API vienen de esa apertura: no se crean dentro de Integration.
• Sus documentos de apertura de SPS. Indican la URL base de la API para su cuenta y traen el Client ID y el Client Secret emitidos para su acceso a la API: téngalos a mano para los dos pasos siguientes.
• Al menos un socio comercial con quien intercambiar documentos a través de SPS Commerce, y una lista clara de qué tipos de documento intercambiará con ese socio: por ejemplo, órdenes de compra 850 entrantes y 856 y 810 salientes. Esta conexión no crea el socio por usted.
• Para la primera conexión, pruebe primero la configuración con un socio y un tipo de documento; nunca pruebe un mapping nuevo con documentos reales de un socio.

Obtener credenciales#

1. Encuentre la URL base de la API en sus documentos de apertura de SPS y cópiela exactamente como está escrita. Todos los extremos que usa la conexión, incluido el extremo del token OAuth, son relativos a esta dirección base, así que una dirección copiada con una parte faltante o sobrante no funcionará.
2. Encuentre el Client ID y el Client Secret en los mismos materiales de apertura. Se emitieron juntos, como un par, cuando su cuenta de SPS se abrió con acceso a la API: guarde el par junto y no lo mezcle con credenciales de otra cuenta.
3. No hay una página de autoservicio donde usted genere estas credenciales por su cuenta. Si el Client Secret se perdió o nunca se entregó, contacte a la persona de SPS que gestionó la apertura de su cuenta y pida que lo vuelva a emitir; no intente crear un reemplazo en otro lugar.
4. Guarde los tres valores juntos para el siguiente paso: la URL base de la API, el Client ID y el Client Secret. La prueba de un paso posterior necesita los tres, y omitir cualquiera se reporta como un valor faltante.

Completar en Integration#

1. Abra Integration → Marketplace → SPS Commerce → Nueva conexión.
2. URL base de la API (base_url), obligatoria: pegue la dirección base de la API exactamente como aparece en sus documentos de apertura de SPS. No deje este campo vacío ni lo sustituya por una dirección web general de SPS: la conexión habla con esta dirección base y, sin ella, la prueba se detiene antes incluso de probar sus credenciales.
3. Client ID (client_id), obligatorio: pegue el Client ID emitido para su cuenta en la apertura de la cuenta de SPS. Tenga cuidado de no pegar el Client Secret en este campo: los dos valores forman un par y cada uno va en su propio campo.
4. Client Secret (client_secret), obligatorio: pegue el Client Secret emitido junto con el Client ID. Se guarda cifrado y nunca se vuelve a mostrar después de guardar, así que péguelo con cuidado y conserve su propia copia en los materiales de apertura.

Probar la conexión#

Haga clic en Probar la conexión. La prueba primero comprueba que la URL base de la API, el Client ID y el Client Secret estén todos presentes, y luego los usa para intercambiar un token OAuth con SPS: le pide un token a SPS y confirma que vuelve uno. La prueba no trae ningún documento EDI. Aprobarla, por tanto, solo prueba que la dirección base y el par de credenciales son utilizables; no significa que sus socios comerciales o su mapping de documentos ya estén configurados: eso es el paso siguiente.

Mapping / elegir plantilla#

En SPS Commerce, el mapping se hace por socio comercial y por tipo de documento: no hay un único mapping que cubra a todos los socios, porque cada socio minorista puede exigir campos y reglas distintos sobre el mismo tipo de documento. Para cada socio, elija la plantilla de los tipos de documento que intercambia con él y revise el mapping lado a lado: en las órdenes de compra 850 entrantes, el número de pedido, las líneas, las cantidades y los datos de envío llegan al pedido estándar; en los documentos salientes, como los avisos de envío 856 y las facturas 810, los datos de envío y de factura se mapean de vuelta al formato que espera el socio. Si un socio pide un campo que sus documentos habituales no llevan, añádalo en el mapping de ese socio en lugar de cambiar el de todos los demás. Recorra cada socio con el que planea comerciar antes de activar: un socio sin un mapping terminado no intercambiará documentos, aunque la prueba de conexión apruebe.

Activar#

Tras activar, Integration intercambia documentos con cada socio comercial mapeado a través de SPS Commerce: los documentos entrantes, como las órdenes de compra 850, se traen y se convierten en pedidos, y los documentos salientes, como los avisos de envío 856 y las facturas 810, se envían de vuelta según avanzan el fulfillment y la facturación. Los socios cuyo mapping no está terminado no empiezan a intercambiar solo porque la conexión esté activa. Vigile los primeros documentos de cada socio en Runs / Logs antes de confiar en el flujo sin supervisión.

Preguntas frecuentes#

La prueba se detiene y dice que falta la URL base de la API

El campo base_url quedó vacío. Este campo se pasa por alto con facilidad, porque la conexión de SPS necesita tres valores, no dos: sin la dirección base, la conexión no sabe con dónde hablar, así que la prueba se detiene antes de comprobar sus credenciales.

Copie la URL base de la API desde sus documentos de apertura de SPS exactamente como está escrita, péguela en el campo de URL base de la API, guarde y vuelva a ejecutar la prueba. Si la dirección de sus documentos parece incompleta, pida a su contacto de apertura de cuenta de SPS que la confirme en lugar de adivinar el resto.

La prueba falla en el intercambio de token: la autenticación no pasa

SPS no devolvió un token para los valores que ingresó. En términos simples, la dirección base, el Client ID y el Client Secret no coinciden entre sí: la dirección base puede estar mal copiada, el Client ID y el Client Secret pueden estar intercambiados entre sus dos campos, el secret puede haber sido reemitido después de que se hizo su copia, o el par puede pertenecer a otra cuenta de SPS.

Vuelva a copiar los tres valores desde sus documentos de apertura de SPS, comprobando que el Client ID va en el campo Client ID y el Client Secret en el campo Client Secret, y pruebe de nuevo. Si aún falla, contacte a la persona de SPS que gestionó la apertura de su cuenta y pida que confirme la dirección base y vuelva a emitir el secret si hace falta: no hay una página de autoservicio donde pueda restablecerlo usted mismo.

La prueba pasa, pero no llegan pedidos 850

Esto no suele significar que la conexión esté rota. La prueba solo intercambia un token — nunca trae un documento — así que aprobarla no dice nada sobre los pedidos. Los pedidos siguen sin llegar cuando el mapping del socio comercial no está terminado, cuando ese socio y su tipo de documento 850 no forman parte de su configuración activa, o cuando el socio simplemente aún no ha enviado pedidos nuevos.

Termine el mapping de ese socio y de su tipo de documento 850, asegúrese de que la conexión esté activada y revise Runs / Logs para ese socio. Si todo está configurado y el socio confirma que envió un pedido, use la hora en que el socio lo envió para buscar ese documento en Runs / Logs.

El socio rechaza los documentos salientes 856 / 810

La conexión y el token están bien: el problema es que el documento en sí no coincide con lo que este socio espera. Cada socio minorista puede exigir sus propios campos y reglas en los documentos 856 y 810, así que un mapping que funciona para un socio puede seguir omitiendo un campo que otro socio exige, o llevar un valor en una forma que ese socio no acepta.

Compare el documento rechazado con los requisitos de ese socio, añada o corrija los campos solo en el mapping de ese socio y reenvíe un documento para confirmar antes de dejar fluir el resto. No cambie el mapping compartido de todos los socios para arreglar el rechazo de uno solo.