La réponse UPS contient un tarif négocié, mais le checkout continue d’afficher le tarif public. Le symptôme se voit dans le panier ; sa cause peut tenir à une seule lettre dans le mapping. Sous NegotiatedRateCharges, le total attendu se nomme TotalCharge, au singulier. Un connecteur qui cherche TotalCharges à cet endroit peut tomber sur son repli vers le montant public, sans faire apparaître d’erreur visible pour l’acheteur.
Le diagnostic doit couvrir le trajet du montant depuis la réponse de Rating jusqu’à la règle commerciale du panier. Retrouver un chiffre inférieur ne suffit pas : il faut identifier le service, la devise, la base retenue et la demande qui a produit le résultat. Le contrat officiel UPS consulté le 17 octobre 2026 sert ici à qualifier les champs. L’exercice utilise exclusivement des extraits fictifs ; il ne représente ni un devis transport réel ni une facture.
Pour réparer ce passage, notre accompagnement d’intégration UPS dans votre SI peut examiner le connecteur et son consommateur e-commerce. Le périmètre rejoint notre expertise en intégration API lorsque les règles de prix, les données ERP et la préparation logistique traversent plusieurs logiciels. L’objectif concret est de retrouver quel montant a été choisi, puis pourquoi il a été affiché.
Pour qui : un écart entre réponse UPS et prix du panier
Séparer le tarif reçu de la politique commerciale
Ce contrôle s’adresse aux équipes e-commerce, aux responsables transport et aux mainteneurs d’un connecteur qui voient une remise dans la réponse conservée sans la retrouver dans le prix proposé. Commencez par rapprocher un dossier précis : demande de tarif, réponse correspondante, service choisi et calcul du panier. Une comparaison entre deux simulations faites à des heures différentes ou sur des caractéristiques de colis différentes ne localise pas un défaut de sélection.
Un marchand peut décider de facturer un forfait, d’offrir une partie du transport ou d’appliquer une règle commerciale au montant reçu. Ce choix n’est pas une anomalie de l’API. En revanche, si le cahier de recette prévoit de transmettre le tarif négocié et que le mapping prend un autre champ, l’écart relève du connecteur. Faites apparaître séparément la donnée transporteur, la transformation décidée et le montant finalement proposé à l’acheteur.
Ne pas transformer toute remise absente en incident
Le contrat décrit aussi des situations où le conteneur négocié n’est pas retourné, notamment pour des remises conditionnelles dont l’envoi ne remplit pas les critères. Son absence ne prouve donc pas à elle seule une erreur de parsing. Certaines options changent aussi les bases retournées : le contrat prévoit notamment un parcours MasterCartonIndicator qui ne renvoie pas les tarifs publics lorsqu’il est demandé avec les tarifs négociés. Le profil du démonstrateur l’exclut explicitement. La première branche du diagnostic consiste à savoir si le tarif est présent dans cette réponse. L’autre branche examine la demande, le contexte du compte et les conditions applicables, sans inventer un montant attendu.
Le démonstrateur distingue ces deux cas. Quand le conteneur existe, il recherche son champ exact. Quand il manque alors que le profil local exige un tarif négocié, il demande une revue. Un autre profil autorise explicitement le montant public et en conserve l’origine. Ce sont des décisions de l’application fictive : elles ne modifient ni les droits du compte UPS ni les conditions commerciales du transporteur.
Lire le bon total dans le bon résultat Rating
Un singulier qui change la donnée sélectionnée
Le contrat officiel Rating consulté distingue TotalCharges et le total négocié NegotiatedRateCharges.TotalCharge. Dans les extraits fictifs étudiés, le premier porte le montant public. Les objets monétaires portent notamment CurrencyCode et MonetaryValue. Une recherche du pluriel dans le conteneur négocié ne désigne pas le même chemin. Dans notre reproduction, elle échoue réellement dans le lecteur JSON Pointer avant que le code naïf ne prenne le montant public.
Le premier scénario fictif contient 12,40 EUR dans le total public et 8,60 EUR dans le total négocié. Le repli erroné affiche 12,40 ; le chemin corrigé retrouve 8,60. L’écart arithmétique de 3,80 décrit seulement cette fixture. Il ne mesure aucune économie client, aucun supplément réel et aucun manque à gagner annuel. Sa valeur est de rendre observable le champ lu, plutôt que discuter une remise supposée.
Choisir le service avant de choisir son montant
La version du parcours compte également : la documentation indique une collection RatedShipment systématique à partir de v2409, avec un comportement différent pour certaines versions antérieures. L’exercice retient un profil local Shop en v2409. Il recherche le code de service demandé dans la collection. Il ne suppose pas que le premier élément correspond au choix fait dans le panier, ni que le premier prix négocié appartient au service attendu.
Le deuxième scénario fictif inverse les deux résultats de tarif. Le montant du service demandé doit rester 8,60 EUR, alors que son chemin passe de l’indice zéro à l’indice un. Le seuil de recette est cette égalité exacte, pas une baisse moyenne du prix du transport. Deux résultats portant le même code de service restent ambigus pour notre profil : le démonstrateur les met en revue au lieu d’éliminer silencieusement une option qu’il ne sait pas interpréter.
Conserver la devise et la base du montant affiché
Un nombre sans provenance ne suffit pas au panier
Conservez ensemble le chemin source, le code de service, la devise et la base d’affichage. Un montant de 8,60 dans une autre devise ne devient pas un tarif en euros parce que le panier travaille en EUR. L’exercice refuse ce rapprochement. Il utilise des chaînes décimales et Decimal pour ses calculs locaux, sans convertir de devises. La règle de précision retenue couvre volontairement des montants EUR avec au plus deux décimales.
Cette restriction est une politique du démonstrateur, pas une grammaire universelle des montants UPS ou des monnaies. Les cas avec une virgule, une valeur numérique JSON, une chaîne non finie ou une précision supplémentaire sont orientés vers une revue locale. Le cas zéro reste lisible comme 0,00. Aucun de ces essais ne prouve qu’un service est gratuit sur un compte réel ou qu’une combinaison pays, produit et devise serait commercialement disponible.
Lire le total avec taxes lorsqu’il appartient au périmètre demandé
Le contrat prévoit aussi TotalChargesWithTaxes, avec un contexte lié à la demande d’informations fiscales. Dans la demande native, TaxInformationIndicator est un marqueur de présence ; le booléen du profil local enregistre ce choix sans représenter son format d’envoi. Le montant ne doit pas être mélangé avec le total de base dans un même calcul de présentation. Le profil fictif indique donc quelle base il attend et si cette demande a été enregistrée. Pour le cas correspondant, le lecteur récupère directement 10,32 EUR dans le champ prévu ; il ne reconstitue pas ce montant en ajoutant un taux de taxe inventé.
Si ce total manque, le sélecteur demande une revue au lieu de recalculer une fiscalité. S’il existe mais que le profil de demande n’a pas été conservé, il refuse aussi de deviner le périmètre. La présence d’un montant décrit comme incluant des taxes ne certifie pas une facture finale, l’ensemble des droits et frais d’importation ou le coût réellement facturé après expédition. Le rapprochement comptable reste un autre contrôle, avec ses propres documents.
Atelier : reproduire le mauvais chemin sans appeler UPS
Faire lire les deux montants au moteur JSON Pointer
L’exercice Python complet utilise le paquet original jsonpointer 3.0.0. Les octets du moteur installé ont été vérifiés contre la distribution officielle et sa source publiée. La fonction resolve_pointer effectue les lectures ; le choix commercial reste dans le petit sélecteur local. Le paquet n’est pas un SDK UPS et les objets fournis sont des extraits construits pour la reproduction, pas des réponses complètes validées par le fournisseur.
Le résultat suivant provient de l’exécution réelle de la première expérience locale. Le programme tente le chemin au pluriel, constate son absence, puis lit le total public et le total négocié sur le même extrait. Aucune connexion, aucun devis UPS et aucune écriture dans le checkout ou l’ERP n’intervient. Les codes de service présents dans les fixtures servent au rapprochement ; ils ne qualifient pas une offre activée dans votre pays ou sur votre compte.
{
"wrongPluralPathMissing": true,
"displayedOrigin": "published",
"displayedAmount": "12.40",
"receivedNegotiatedAmount": "8.60",
"currency": "EUR",
"fictionalDifference": "3.80"
}Lancer les vingt-trois cas et garder leurs limites
Le programme couvre 23 cas fictifs et passe 53 contrôles, avec 55 appels au lecteur natif, y compris ceux qui échouent comme attendu. Les variantes portent sur l’ordre des services, un conteneur absent ou mal formé, les champs monétaires, les options de taxes et le profil d’opération. Les décisions acceptables restent nommées candidate_for_checkout_review. Le fichier ne modifie pas un panier et ne délivre aucune autorisation de vente.
python3 -m venv .venv-ups-rate
.venv-ups-rate/bin/python -m pip install jsonpointer==3.0.0
.venv-ups-rate/bin/python ups_negotiated_rate_selection.py
checksPassed: 53
cases: 23
nativeJsonPointerReads: 55
networkConnectionAttempts: 0
upsApiCalls: 0
checkoutWrites: 0
erpWrites: 0Le moteur JSON Pointer de la version utilisée sert à vérifier les chemins, pas à certifier un contrat transport. Le démonstrateur ne valide pas l’ensemble du schéma OpenAPI, l’authentification ou les conditions du compte. Pour votre recette, reprenez des échanges autorisés du parcours concerné et reliez-les au calcul réellement exécuté par la boutique. La sélection correcte d’un extrait ne suffit pas à prouver ce parcours complet.
| Cas fictif | Décision ou observation |
|---|---|
| Pluriel dans le conteneur négocié | Chemin absent ; repli naïf vers 12,40. |
| Ordre des services inversé | Le même service conserve 8,60 EUR. |
| Deux options du même service | Revue de l’ambiguïté. |
| Base avec taxes enregistrée | Lecture du champ à 10,32 EUR. |
| Montant négocié dans une autre devise | Revue de la devise. |
| Tarif public explicitement autorisé | Origine publique conservée dans le résultat. |
Plan d’action : retrouver le prix choisi avant de corriger
Localiser la transformation responsable de l’écart
Si un middleware relie l’ERP, l’OMS et le WMS au calcul du panier, gardez en entrée la demande Rating, sa réponse, le service choisi et les caractéristiques colis fournies par ces logiciels. Ajoutez le contexte du compte et la configuration commerciale du panier. En sortie, documentez le chemin réellement lu, la devise, la base et le calcul appliqué. La responsabilité du connecteur est de rendre cette provenance exploitable. La boutique conserve celle de sa présentation et de ses règles commerciales ; l’ERP ne doit pas réinterpréter un montant décontextualisé comme le coût final du colis.
Commencez par la réponse conservée sur le dossier litigieux. Si le total négocié est présent, suivez sa projection vers le modèle interne puis vers le panier. Si le modèle contient 8,60 et que le panier affiche 12,40, l’enquête a déjà dépassé le simple nom du champ UPS. Elle doit examiner la règle appliquée, une valeur mise en cache ou une autre proposition de transport sélectionnée, plutôt que modifier à nouveau le parseur qui a correctement lu la réponse.
- En priorité, rapprocher une demande, une réponse et le calcul du même panier avant de comparer les montants.
- Relever ensuite le service, le chemin monétaire, la devise et la base réellement sélectionnés.
- Corriger le mapping ou la règle identifiée, puis rejouer l’ordre inversé des services sans modifier le montant attendu.
- Différer la restitution automatique lorsqu’une option reste ambiguë ou que la provenance de la demande manque.
Recetter la reprise sans réécrire les commandes déjà validées
La correction d’un sélecteur ne définit pas le traitement des ventes existantes. Un panier en cours, une proposition enregistrée et une commande payée n’ont pas la même fenêtre de modification. Décidez avec le commerce quels dossiers peuvent être recalculés et lesquels doivent conserver leur montant accepté. Le runbook doit nommer ces états. Un retry technique sur le calcul ne vaut pas autorisation de changer la somme attachée à une commande déjà conclue.
L’observabilité doit distinguer un timeout de Rating d’une réponse où aucun montant négocié n’est disponible. La journalisation peut conserver l’identifiant de calcul, le profil, le service et le chemin source. Le monitoring doit distinguer absence de remise, montant introuvable et choix commercial public explicitement autorisé. Pour le repli, définissez quelle sortie la boutique sait traiter : revue du tarif, proposition alternative qualifiée ou attente. Cette décision dépend de votre parcours ; le programme hors ligne ne choisit pas la promesse que vous présenterez aux acheteurs.
Erreurs fréquentes qui masquent la cause du mauvais prix
Prendre systématiquement le plus petit montant
Comparer tous les nombres de la réponse pour retenir le minimum mélange des objets différents. Un autre service, une autre base ou une autre devise peut donner un chiffre inférieur sans correspondre au transport demandé. Le deuxième scénario de l’exercice isole cette question : l’ordre change, le service attendu reste le même. La recette doit défendre cette identité avant de chercher un prix plus séduisant à afficher.
Une même vigilance s’applique aux options répétées du même service. Notre profil les classe comme ambiguës parce qu’il ne dispose pas d’un critère supplémentaire qualifié. Cela ne prouve pas que la réponse UPS serait incorrecte. L’adaptateur réel doit savoir quelle dimension permet de choisir dans son contrat et dans son parcours. La supprimer pour retrouver artificiellement un résultat unique ferait perdre une information utile au calcul commercial.
Déduire une facture à partir du seul Rating
Un tarif calculé avant l’expédition et le montant facturé après transport peuvent appartenir à des documents et à des moments différents. Conservez la donnée qui a servi à la proposition, puis rapprochez séparément la facture reçue et ses références. L’exercice ne traite ni les corrections de caractéristiques du colis ni les conditions de facturation. Sa portée reste la sélection d’un montant retourné, avec une provenance que les logiciels peuvent expliquer.
Contre-intuitivement, obtenir une valeur plus basse après correction ne suffit donc pas à déclarer le parcours réparé. Le bon signal est que le panier utilise le montant prévu par la règle approuvée, pour le bon service et la bonne base. Un tarif public explicitement assumé peut être conforme ; un tarif négocié mal rattaché à la proposition peut rester faux. La comparaison métier complète l’accès technique au champ.
Lectures complémentaires pour relier tarif et coût transport
Conserver le contexte lorsqu’un prix traverse plusieurs logiciels
L’analyse du prix PrestaShop et de son contexte de lecture examine les dimensions qui donnent un sens à une valeur exportée. Elle traite un autre système, mais pose une question utile au raccordement UPS : quelles informations disparaissent lorsque le modèle interne ne conserve plus qu’un nombre ? Le montant ne doit pas arriver dans l’ERP sans les dimensions nécessaires à son interprétation.
Pour le flux transport, gardez le service, la devise, la base et la proposition dont le montant provient. Pour le prix produit, qualifiez les dimensions propres à la boutique. Les noms de champs ne sont pas transposables entre ces interfaces. Le rapprochement utile se trouve dans la conservation du contexte et dans une recette qui compare la même situation métier à chaque étape du calcul.
Séparer le tarif lu des paramètres qui feront évoluer le coût
L’analyse du poids volumétrique et de sa conversion complète la sélection du montant par la lecture des données colis. Une valeur correctement extraite peut reposer sur des caractéristiques différentes de celles finalement expédiées. Identifier le bon champ Rating évite une erreur de mapping ; conserver les paramètres d’envoi permet ensuite d’examiner une différence de coût sans accuser automatiquement ce mapping.
Faites circuler la référence de proposition entre le commerce et la logistique lorsque le parcours le permet. L’équipe pourra rapprocher la configuration tarifée, le colis préparé et le document financier disponible, sans effacer la valeur initiale. Chaque comparaison doit garder son périmètre. Un contrôle de lecture ne remplace pas une recette des données colis, et cette recette ne reconstitue pas à elle seule les conditions de facturation du compte.
Conclusion : rendre le montant affiché explicable
Le premier scénario montre une remise bien présente mais ignorée par un chemin au pluriel. Le lecteur natif reproduit l’échec ; la sélection corrigée retrouve le champ au singulier. Le scénario d’ordre inversé vérifie ensuite que le même service conserve son montant. Ces deux observations localisent un défaut concret sans faire passer les extraits fictifs pour des devis UPS.
La reprise réelle doit encore relier le compte, la demande, la version, le service et le calcul du panier. Les variantes de devise, de taxes et d’options empêchent de réduire cette décision à une recherche du chiffre le plus bas. Le critère de sortie est une provenance lisible et une règle commerciale validée, avec une revue explicite lorsque le profil ne permet pas de choisir.
Notre accompagnement pour relier UPS à vos logiciels et à vos expéditions peut reprendre ce diagnostic avec vos équipes e-commerce et transport. Le premier résultat attendu est un dossier de recette où le montant reçu, le montant retenu et le montant présenté ne sont plus confondus.
Dawap peut cadrer cette intégration API et son calcul de restitution, puis vérifier le passage jusqu’au logiciel consommateur. Vous pourrez expliquer le choix d’un tarif sur une proposition précise et conserver les décisions nécessaires pour corriger le flux sans réécrire les ventes déjà validées.
