Connecter SPS Commerce : commandes EDI entrantes, ASN et factures sortantes

Dernière mise à jour 2026-11-01

Copiez l’URL de base de l’API depuis vos documents d’ouverture SPS, prenez le Client ID et le Client Secret émis ensemble à l’ouverture de votre compte SPS, collez les trois dans Integration, testez, mappez chaque partenaire commercial et activez : les commandes 850 entrent, les documents 856 / 810 sortent.

Le connecteur SPS Commerce échange des documents EDI avec vos partenaires commerciaux de la distribution via SPS Commerce (RSX / API) : les documents entrants, comme les bons de commande 850, arrivent des partenaires et deviennent des commandes, et les documents sortants, comme les avis d’expédition 856 et les factures 810, repartent vers ces mêmes partenaires. Ce n’est pas une connexion de boutique et il n’y a pas d’autorisation de boutique — tout est organisé par partenaire commercial et par type de document, donc chaque partenaire se configure et se vérifie séparément.

Étapes SPS Commerce : URL de base et identifiants, test, mapping des partenaires commerciaux, activation.

Prérequis#

Un compte SPS Commerce ouvert avec un accès API. Vos identifiants et votre URL de base de l’API viennent de cette ouverture — ils ne se créent pas dans Integration.
Vos documents d’ouverture SPS. Ils indiquent l’URL de base de l’API pour votre compte et contiennent le Client ID et le Client Secret émis pour votre accès API — gardez-les sous la main pour les deux étapes suivantes.
Au moins un partenaire commercial avec qui échanger des documents via SPS Commerce, et une liste claire des types de documents échangés avec ce partenaire — par exemple commandes 850 entrantes, 856 et 810 sortants. Cette connexion ne crée pas le partenaire à votre place.
Pour la première connexion, validez d’abord la configuration avec un partenaire et un type de document — ne testez jamais un nouveau mapping sur des documents réels d’un partenaire.

Obtenir les identifiants#

Trouvez l’URL de base de l’API dans vos documents d’ouverture SPS et copiez-la exactement comme elle est écrite. Tous les points de terminaison utilisés par la connexion, y compris celui du token OAuth, sont relatifs à cette adresse de base : une adresse copiée avec un morceau manquant ou en trop ne fonctionnera pas.
Trouvez le Client ID et le Client Secret dans ces mêmes documents d’ouverture. Ils ont été émis ensemble, en paire, à l’ouverture de votre compte SPS avec accès API — conservez la paire ensemble et ne la mélangez pas avec les identifiants d’un autre compte.
Il n’existe aucune page en libre-service où générer ces identifiants vous-même. Si le Client Secret est perdu ou n’a jamais été remis, contactez l’interlocuteur SPS qui a géré l’ouverture de votre compte et demandez-lui de le réémettre — n’essayez pas de créer un remplaçant ailleurs.
Conservez les trois valeurs ensemble pour l’étape suivante : l’URL de base de l’API, le Client ID et le Client Secret. Le test d’une étape ultérieure a besoin des trois, et tout oubli est signalé comme une valeur manquante.

Remplir dans Integration#

Ouvrez Integration → Marketplace → SPS Commerce → Nouvelle connexion.
URL de base de l’API (base_url) — obligatoire : collez l’adresse de base de l’API exactement comme elle figure dans vos documents d’ouverture SPS. Ne laissez pas ce champ vide et ne le remplacez pas par une adresse web générale de SPS : la connexion parle à cette adresse de base et, sans elle, le test s’arrête avant même d’essayer vos identifiants.
Client ID (client_id) — obligatoire : collez le Client ID émis pour votre compte à l’ouverture du compte SPS. Attention à ne pas coller le Client Secret dans ce champ — les deux valeurs forment une paire et chacune a son propre champ.
Client Secret (client_secret) — obligatoire : collez le Client Secret émis avec le Client ID. Il est stocké chiffré et n’est jamais réaffiché après l’enregistrement, donc collez-le avec soin et conservez votre propre copie dans les documents d’ouverture.

Tester la connexion#

Cliquez sur Tester la connexion. Le test vérifie d’abord que l’URL de base de l’API, le Client ID et le Client Secret sont tous présents, puis les utilise pour échanger un token OAuth avec SPS — il demande un token à SPS et confirme qu’un token revient. Le test ne récupère aucun document EDI. Une réussite prouve donc seulement que l’adresse de base et la paire d’identifiants sont utilisables ; elle ne signifie pas que vos partenaires commerciaux ou votre mapping de documents sont déjà configurés — c’est l’étape suivante.

Mapping / choisir un modèle#

Sur SPS Commerce, le mapping se fait par partenaire commercial et par type de document — il n’existe pas un mapping unique qui couvre tous les partenaires, car chaque partenaire de la distribution peut exiger des champs et des règles différents sur le même type de document. Pour chaque partenaire, choisissez le modèle des types de documents que vous échangez avec lui et vérifiez le mapping côte à côte : sur les bons de commande 850 entrants, le numéro de commande, les lignes, les quantités et les coordonnées de livraison arrivent sur la commande standard ; sur les documents sortants, comme les avis d’expédition 856 et les factures 810, les détails d’expédition et de facture sont remappés au format attendu par le partenaire. Si un partenaire demande un champ que vos documents habituels ne portent pas, ajoutez-le dans le mapping de ce partenaire plutôt que de changer celui de tous les autres. Passez en revue chaque partenaire avec qui vous comptez échanger avant d’activer — un partenaire sans mapping terminé n’échangera aucun document, même si le test de connexion réussit.

Aller-retour des documents SPS Commerce : commandes 850 entrantes via SPS, documents 856 et 810 renvoyés au partenaire.

Activer#

Après activation, Integration échange des documents avec chaque partenaire commercial mappé via SPS Commerce : les documents entrants, comme les bons de commande 850, sont récupérés et deviennent des commandes, et les documents sortants, comme les avis d’expédition 856 et les factures 810, sont renvoyés au fil du fulfillment et de la facturation. Les partenaires dont le mapping n’est pas terminé ne commencent pas à échanger simplement parce que la connexion est active. Surveillez les premiers documents de chaque partenaire dans Runs / Logs avant de laisser le flux tourner sans surveillance.

FAQ#

Le test s’arrête et dit que l’URL de base de l’API est manquante

Le champ base_url est resté vide. Ce champ se manque facilement, car la connexion SPS a besoin de trois valeurs, pas de deux — sans l’adresse de base, la connexion ne sait pas à qui parler, donc le test s’arrête avant de vérifier vos identifiants.

Copiez l’URL de base de l’API depuis vos documents d’ouverture SPS exactement comme elle est écrite, collez-la dans le champ URL de base de l’API, enregistrez et relancez le test. Si l’adresse de vos documents semble incomplète, faites-la confirmer par votre interlocuteur SPS chargé de l’ouverture plutôt que de deviner la suite.

Le test échoue à l’échange de token — l’authentification ne passe pas

SPS n’a pas renvoyé de token pour les valeurs saisies. En termes simples, l’adresse de base, le Client ID et le Client Secret ne correspondent pas entre eux : l’adresse de base peut être mal copiée, le Client ID et le Client Secret peuvent être inversés entre leurs deux champs, le secret peut avoir été réémis depuis votre copie, ou la paire peut appartenir à un autre compte SPS.

Recopiez les trois valeurs depuis vos documents d’ouverture SPS, en vérifiant que le Client ID va dans le champ Client ID et le Client Secret dans le champ Client Secret, puis testez à nouveau. Si l’échec persiste, contactez l’interlocuteur SPS qui a géré l’ouverture de votre compte et demandez-lui de confirmer l’adresse de base et de réémettre le secret si besoin — il n’existe aucune page en libre-service pour le réinitialiser vous-même.

Le test réussit, mais aucune commande 850 n’arrive

Cela ne signifie généralement pas que la connexion est cassée. Le test ne fait qu’échanger un token — il ne récupère jamais de document — donc une réussite ne dit rien sur les commandes. Les commandes restent absentes quand le mapping du partenaire commercial n’est pas terminé, quand ce partenaire et son type de document 850 ne font pas partie de votre configuration active, ou quand le partenaire n’a tout simplement pas encore envoyé de nouvelles commandes.

Terminez le mapping de ce partenaire et de son type de document 850, assurez-vous que la connexion est activée et vérifiez Runs / Logs pour ce partenaire. Si tout est configuré et que le partenaire confirme l’envoi d’une commande, utilisez l’heure d’envoi du partenaire pour retrouver ce document dans Runs / Logs.

Le partenaire rejette les documents sortants 856 / 810

La connexion et le token vont bien — c’est le document lui-même qui ne correspond pas à ce que ce partenaire attend. Chaque partenaire de la distribution peut exiger ses propres champs et règles sur les documents 856 et 810, donc un mapping qui fonctionne pour un partenaire peut toujours manquer un champ exigé par un autre, ou porter une valeur sous une forme que ce partenaire n’accepte pas.

Comparez le document rejeté aux exigences de ce partenaire, ajoutez ou corrigez les champs uniquement dans le mapping de ce partenaire, et renvoyez un document pour confirmer avant de laisser passer le reste. Ne modifiez pas le mapping partagé de tous les partenaires pour corriger le rejet d’un seul.