Catalogue PunchOut pour Shopify B2B

Un catalogue PunchOut est une boutique fournisseur que l’acheteur atteint depuis son propre système d’approvisionnement, et non depuis son navigateur. L’acheteur est dans Ariba, Coupa, Jaggaer ou SAP, clique sur votre nom dans sa liste de fournisseurs et arrive dans une session authentifiée sur votre boutique — déjà identifié, déjà tarifé à ses conditions contractuelles. Il constitue un panier, clique sur un bouton de retour, et le panier est transféré dans son système sous forme de demande d’achat. L’approbation s’y déroule, et un bon de commande vous revient. L’acheteur ne quitte jamais son processus, et vous n’avez aucun fichier de prix statique à maintenir chez lui. C’est la raison d’être du PunchOut : un catalogue hébergé est périmé le jour où on le dépose, alors qu’une session PunchOut lit les prix et les stocks en direct à chaque fois.

Ce sont les deux protocoles PunchOut dominants, et ils résolvent le même problème différemment. cXML — commerce eXtensible Markup Language, issu d’Ariba — est fondé sur XML : le système d’approvisionnement envoie un PunchOutSetupRequest contenant les identifiants et une URL de retour, votre point de terminaison répond par un PunchOutSetupResponse portant l’URL de session, et le panier terminé repart en PunchOutOrderMessage. C’est ce que parlent nativement Ariba, Coupa et Jaggaer. OCI — Open Catalog Interface, le standard de SAP — est plus simple et plus ancien : la poignée de main passe par des paramètres d’URL, et le panier revient sous forme de formulaire HTML POST de champs nommés plutôt que de document structuré. Aucun n’est plus difficile que l’autre, mais ils ne sont pas interchangeables : un fournisseur qui sert à la fois un acheteur Coupa et un acheteur SAP a besoin des deux points de terminaison. Cartographiez qui utilise quoi avant de construire.

Non, et autant le dire franchement. Shopify Plus offre un excellent B2B natif — comptes d’entreprise, catalogues, listes de prix, conditions de paiement, checkout B2B — mais ne fournit ni point de terminaison cXML ni OCI, et aucun réglage ne permet d’en activer un. Le PunchOut sur Shopify est un travail de middleware : un service qui termine la poignée de main du système d’approvisionnement, authentifie la session, associe l’acheteur à la bonne entreprise et au bon catalogue Shopify, l’envoie dans la boutique, puis sérialise le panier de retour en cXML ou en OCI. Les objets B2B natifs de Shopify rendent l’exercice raisonnable plutôt que pénible : le modèle entreprise / catalogue / liste de prix correspond presque directement à ce qu’une session PunchOut doit exposer. Le middleware fournit le protocole ; Shopify fournit le commerce.

Prévoyez 8 à 14 semaines pour un premier point de terminaison, et attendez-vous à ce que le calendrier, pas le code, dicte le rythme. La construction elle-même — poignée de main, authentification de session, périmètre catalogue, sérialisation du panier — est un travail bien cadré. Ce qui allonge le délai, c’est la certification : chaque acheteur teste la connexion dans son propre bac à sable, et c’est sa disponibilité, pas la vôtre, qui fixe la date. Ariba comme Coupa opèrent des processus d’activation fournisseur avec leurs propres files d’attente. Les acheteurs suivants sur le même protocole vont beaucoup plus vite, généralement deux à quatre semaines, puisque le point de terminaison existe déjà et que seuls changent les identifiants, le périmètre catalogue et le mappage tarifaire.

Quatre choses qu’une boutique grand public n’a aucune raison de porter. Les prix contractuels, résolus par organisation acheteuse au moment de la session et non au moment de la mise en cache. Le périmètre catalogue, pour qu’un acheteur ne voie que les références couvertes par son accord — un article hors contrat dans le panier est traité par les services achats comme un manquement de conformité, pas comme une commodité. Les codes de classification, généralement UNSPSC, parce que la demande d’achat et l’analyse de dépenses côté acheteur reposent dessus. Et un modèle d’unités de mesure qui survit à l’aller-retour, puisque les systèmes d’approvisionnement raisonnent dans les unités d’achat du client, pas dans vos unités de vente. Une erreur sur l’un de ces points et le panier revient, mais la demande d’achat échoue à la validation — le mode de défaillance le plus coûteux à diagnostiquer, puisqu’il se produit sur le système de quelqu’un d’autre.

Le panier devient une demande d’achat, passe la chaîne d’approbation, et vous revient sous forme de bon de commande — et ce bon de commande est une intégration distincte, pas une partie du PunchOut. La plupart des grands acheteurs l’envoient en cXML OrderRequest ou en EDI 850, et attendent un accusé de réception. La même relation demande ensuite généralement un EDI 855 pour la confirmation de commande, un 856 pour l’avis d’expédition et un 810 pour la facturation. Beaucoup d’équipes cadrent le PunchOut seul, le livrent, puis découvrent que l’acheteur ne passera pas en production tant que le canal de bon de commande n’existe pas. Cadrez les deux dès le départ, même si vous les construisez en séquence.

Le catalogue hébergé — un fichier de prix déposé dans le système de l’acheteur — coûte moins cher à démarrer et davantage à vivre. Chaque changement de prix et chaque ajout de produit devient un échange de fichier, le stock n’est jamais représenté, et les produits configurables ou fabriqués sur commande ne peuvent tout simplement pas s’exprimer. C’est pertinent pour une gamme courte, stable et peu profonde. Le PunchOut se justifie dès que votre catalogue bouge, que les prix sont négociés par compte, que le stock compte dans la décision d’achat, ou que l’acheteur veut chercher et comparer plutôt que parcourir un tableur. Le test honnête : si l’état de votre fichier hébergé trois mois après le dépôt vous gênerait, il vous faut un PunchOut.