7 exemples curés - cart return et setup request - illustrant à la fois les configurations propres (OCI 4.0, OCI 5.0 attachments) et les pièges classiques (PRICEUNIT x1000, index [0], ~Target=_self, etc.). Copier, télécharger ou tester directement dans le validateur.
Données fictives - usage de test uniquement.
Toutes les valeurs (VENDOR, VENDORMAT, codes produit, HOOK_URL, credentials) sont inventées. À ne jamais envoyer en production - utilisez ces exemples comme structure de référence puis remplacez chaque valeur par les vôtres.
Setup request
URL d'ouverture de session OCI - construite par l'acheteur (SAP SRM, S/4HANA, etc.) pour entrer dans le catalogue supplier. Paramètres USERNAME, PASSWORD, HOOK_URL, ~OkCode, ~Target, etc.
La configuration recommandée pour un appel OCI vers un catalogue supplier en production.
Setup RequestClean
URL d'ouverture de session OCI conforme aux bonnes pratiques : HTTPS pour le tunnel, USERNAME et PASSWORD distincts, HOOK_URL absolu en HTTPS, ~OkCode=ADDI (ajout au shopping cart courant côté SAP), ~Target=_top (échappe toutes les iframes pour que le retour panier remonte au niveau de la fenêtre SRM), ~Caller=CTLG, et LANGU=FR pour servir le catalogue en français. C'est exactement le pattern qu'un acheteur SAP SRM configure côté supplier dans la table de connexion OCI.
Setup request avec warnings - frame trap, HTTP, PASSWORD en query
Trois mauvaises pratiques fréquentes qui font échouer un punchout en production sans erreur explicite.
Setup RequestWarnings
Trois pièges à éviter, tous présents dans cette URL : (1) HOOK_URL en HTTP - bloqué silencieusement par Chrome en mixed-content depuis un catalogue HTTPS. (2) ~Target=_self qui piège le formulaire de retour dans la frame courante (cas classique SRM derrière reverse proxy : le HOOK_URL n'est jamais déclenché). (3) PASSWORD passé en query string GET au lieu d'un POST form-urlencoded - le mot de passe se retrouve dans tous les logs de reverse proxy et historique navigateur. Le validateur Gatebold lève un warning sur chacun de ces points sans bloquer la validation.
Le plus petit retour OCI valide qui passe sans erreur ni warning.
Cart ReturnOCI 4.0Minimal
Le retour panier minimum techniquement valide selon OCI 4.0 : une seule ligne avec les cinq champs obligatoires (DESCRIPTION, QUANTITY, UNIT, PRICE, CURRENCY). Pas de VENDOR, pas de MATGROUP, pas de DELIVERYDATE. Utile pour démarrer une intégration depuis zéro et vérifier que le tunnel HOOK_URL fonctionne avant d'enrichir le mapping. À noter : sans MATGROUP (UNSPSC), de nombreux acheteurs SAP recatégoriseront la ligne dans un groupe par défaut - c'est volontairement absent ici pour montrer le strict minimum.
Trois lignes variées avec VENDOR, MATGROUP UNSPSC, DELIVERYDATE et une ligne de service.
Cart ReturnOCI 4.0Complet
Un retour réaliste de catalogue B2B sur OCI 4.0. Trois lignes : du câble Cat6a (matériel réseau, UNSPSC 43222600), un cordon d'alimentation IEC (UNSPSC 39121600), et une prestation de service (NEW_ITEM-SERVICE=X, unité HUR = heure). Chaque ligne porte sa référence fournisseur (VENDOR + VENDORMAT), son code UNSPSC (MATGROUP) et la première ligne pousse une date de livraison souhaitée. C'est ce niveau de richesse qu'un acheteur SAP attend en production - le minimum technique ne suffit jamais en pratique au-delà du POC.
Démontre la source numéro un d'erreurs prix en intégration OCI : PRICEUNIT mal interprété par le buyer.
Cart ReturnOCI 4.0Piège
Le fournisseur envoie un prix unitaire de 12,50 EUR... pour 1000 unités (PRICEUNIT=1000) sur de la visserie. Le prix réel par pièce est 0,0125 EUR. Si l'acheteur SAP ne mappe pas PRICEUNIT côté MM-PUR, il facturera 12,50 EUR par pièce - facteur 1000 d'erreur. C'est le bug le plus coûteux et le plus silencieux du protocole OCI : aucune erreur de validation, aucun warning d'encodage, juste un panier qui rentre dans SAP avec un montant astronomique. Le validateur Gatebold calcule le prix effectif et alerte explicitement sur cette ligne.
Un panier volontairement cassé pour voir ce que le validateur attrape réellement.
Cart ReturnDémo erreurs
Quatre lignes, quatre catégories d'erreur : (1) Une ligne sur l'index [0] interdit par la spec OCI 4.0 avec en bonus une devise inexistante (XXX). (2) Une ligne [2] où le champ obligatoire PRICE est absent. (3) Une ligne [3] avec une date de livraison invalide (2026-13-45). (4) Indices [0], [2], [3] non contigus, le validateur signalera aussi le saut d'index. C'est le payload idéal pour comprendre quels checks le validateur applique avant d'envoyer ton vrai retour panier de prod.
OCI 5.0 - pièces jointes et références produit externes
Une ligne enrichie avec ATTACHMENT, EXT_PRODUCT_ID (GTIN) et EXT_CATEGORY_ID (UNSPSC), spécifiques à OCI 5.0.
Cart ReturnOCI 5.0
Démonstration des champs introduits par OCI 5.0 : NEW_ITEM-ATTACHMENT (URL d'une fiche technique PDF), NEW_ITEM-ATTACHMENT_TITLE + PURPOSE, NEW_ITEM-EXT_PRODUCT_ID (code GTIN/EAN), NEW_ITEM-EXT_SCHEMA_TYPE (GTIN ici), et NEW_ITEM-EXT_CATEGORY_ID/EXT_CATEGORY pour pousser une classification externe en plus du MATGROUP. Le validateur reconnaît ces champs et les marque comme OCI 5.0 dans le rapport. En pratique, peu d'acheteurs SAP accepteront ces champs sans configuration spécifique - démarrer en OCI 4.0 et négocier l'ajout avec le buyer.
Codes UNSPSC - le référentiel produit/service pour le champ NEW_ITEM-MATGROUP.
Questions fréquentes
À quoi servent ces exemples ?
Chaque exemple est un payload OCI réaliste prêt à coller dans le validateur ou à utiliser comme base d'implémentation côté supplier. Certains illustrent des configurations propres, d'autres sont volontairement piégés pour démontrer les erreurs classiques (PRICEUNIT mal mappé, index [0] interdit, ~Target=_self, encodage Latin-1, etc.) que le validateur Gatebold détecte.
Puis-je utiliser ces exemples en production ?
Non, jamais directement. Les valeurs sont fictives (VENDOR=ACME01, codes UNSPSC réalistes mais associés à des produits de démo, etc.). Utilisez-les comme structure de référence et remplacez chaque valeur par celles propres à votre catalogue et à votre acheteur.
Comment le bouton 'Tester dans le validateur' fonctionne ?
Le bouton stocke le payload dans le sessionStorage de votre navigateur (clé 'gatebold-oci-prefill') puis vous redirige vers le validateur OCI, qui détecte le préfill au chargement et insère automatiquement le payload dans la zone de saisie. La donnée ne quitte jamais votre navigateur.
Quelle est la différence entre cart return et setup request ?
Le setup request est l'URL d'ouverture de session que l'acheteur (ERP/SRM) ouvre pour entrer dans le catalogue fournisseur. Le cart return est le body POST que le catalogue fournisseur renvoie sur le HOOK_URL une fois que l'acheteur a validé son panier. Les deux flux composent un PunchOut OCI complet.
