Fonctionnalité · Mapping cXML et OCI
Un mapping cXML et OCI qu’on peut lire, versionner et réutiliser.
Gatebold propose un modèle de mapping structuré : chaque acheteur hérite d’un socle commun et expose ses spécificités dans une configuration claire, pas dans du code éparpillé.
Le problème
Sans cadre, le mapping cXML et OCI est la zone la plus douloureuse d’un projet e-procurement.
L’approche Gatebold
Une structure, trois niveaux, zéro magie.
Socle commun
Les éléments cXML standards (cart item, tax, unit of measure) sont définis une seule fois, pour tous les acheteurs.
Profil acheteur
Chaque acheteur déclare ses particularités (champs custom, règles de codification) sans toucher au socle commun.
Overrides explicites
Les cas vraiment spécifiques sont isolés, nommés, et documentés - plutôt que cachés dans une branche conditionnelle.
Moteur de mapping flexible
Le moteur comprend les noms cXML natifs (UnitOfMeasure, SupplierPartID) et les alias simplifiés (uom, sku, name). Champs custom mappables via Extrinsic.
Bénéfices
Ce qu’on gagne à structurer le mapping.
-
Onboarding acheteur accéléré
Un nouvel acheteur hérite du socle. Le travail se concentre sur ses vraies spécificités, pas sur le tronc commun.
-
Relecture possible
Le mapping se lit comme une configuration, pas comme du code éparpillé. Les revues de mapping deviennent réelles.
-
Versions traçables
Chaque évolution de mapping est versionnée, avec un historique clair - utile en cas d’incident en production.
-
Moins d’erreurs silencieuses
Le typage empêche les valeurs incohérentes d’atterrir dans un PunchOutOrderMessage.
Un mapping cXML ou OCI qui vous coûte cher ?
Montrez-nous un cas précis. Nous pouvons évaluer rapidement ce qu’un mapping structuré change dans votre contexte.