Sendcloud V3 : comment garder le point relais choisi ?

Scénario fictif : une boutique migre son connecteur Sendcloud vers la V3. Les commandes remontent toujours dans l’ERP avec l’adresse du point relais, mais l’identifiant retenu au checkout disparaît du nouveau mapping. Le préparateur retrouve une rue et un transporteur ; il ne sait plus si l’option proposée correspond au lieu accepté par l’acheteur.

Le passage de version doit conserver ce choix avant de convertir la méthode d’expédition. Une adresse de retrait, un identifiant Sendcloud, une référence de point chez le transporteur et un code d’option ne désignent pas le même objet. Les rapprocher par leur position dans une réponse ou par un libellé similaire peut laisser partir un colis selon une autre promesse.

Deux alertes méritent une vérification : les opérateurs rechoisissent le relais après l’import, ou les nouvelles options sont recherchées avec le colisage de la veille. Le risque est de croire qu’un code V3 retrouvé suffit à migrer la commande. Nous allons examiner les données à garder, puis huit dossiers fictifs dont les décisions ont été exécutées sans compte transporteur ni création d’étiquette.

Dawap cadre ces échanges dans un projet d’intégration API, avec vos équipes e-commerce, logistiques et vos installateurs ERP. Notre accompagnement d’intégration Sendcloud dans votre SI peut qualifier le choix relais, les correspondances de méthodes et les reprises avant la bascule. Le laboratoire décrit une décision locale sur des données fournies, sans valider une requête native complète.

Pour qui reprendre le choix relais pendant une migration Sendcloud

Les boutiques dont plusieurs outils préparent la même expédition

Ce contrôle concerne une boutique ou un opérateur qui transmet les commandes vers un ERP, un OMS ou un WMS avant de demander les documents de transport. Le client sélectionne un lieu dans le checkout ; la préparation peut commencer plus tard, depuis un autre logiciel. Le connecteur doit donc retrouver ce choix sans demander au préparateur de le reconstruire.

Une migration est un bon moment pour qualifier les champs, car l’ancien adaptateur peut avoir conservé des conventions implicites. Un numéro stocké dans une colonne « relais » peut venir de Sendcloud, du transporteur ou d’un composant de carte. Sa présence dans l’ERP ne démontre pas que le nouvel adaptateur saura l’interpréter.

Un contrôle centré sur le choix de retrait

La présentation des produits, étiquettes et retours Sendcloud traite déjà le cadrage de l’agrégateur et la transition entre versions. Ici, la décision est plus étroite : garder l’identité du point choisi et rapprocher l’ancienne méthode du code réellement proposé pour le dossier à préparer.

Les règles douanières, le tarif transporteur et la reprise d’une création au résultat perdu demandent leur propre recette. Les quelques identités rapprochées dans le laboratoire apportent une décision sur le choix de retrait ; les autres conditions de l’expédition restent à vérifier avant de poursuivre.

Distinguer l’adresse, le point Sendcloud et la référence transporteur

Retrouver l’origine du numéro avant de le déplacer

La documentation de migration Sendcloud indique le passage de la valeur V2 to_service_point vers to_service_point.id en V3. Elle distingue également l’ancien shipment.id du code d’option utilisé dans ship_with.properties, avec le type shipping_option_code. Ces correspondances ne dispensent pas de qualifier la provenance de vos valeurs historiques.

Dans votre base, conservez la sélection initiale avec sa source et le contexte de commande. Une adresse lisible aide le support à reconnaître le lieu ; elle ne remplace pas son identité. Si l’ancien connecteur a perdu le numéro, le nouveau mapping doit ouvrir une qualification au lieu de choisir automatiquement le premier établissement situé dans la même rue.

Ne pas ranger un identifiant transporteur dans le champ Sendcloud

La procédure de livraison en point relais emploie l’identifiant Sendcloud sélectionné et montre séparément carrier_service_point_id dans son exemple de résultat. Un numéro provenant du transporteur ne devient donc pas l’identifiant Sendcloud simplement parce que les deux valeurs sont numériques.

Notre laboratoire suit uniquement la branche où le choix client est déjà identifié côté Sendcloud. Il compare la valeur transportée par l’ancien dossier à cette identité fournie. Les interfaces natives peuvent proposer d’autres modes de désignation ; leur existence ne permet pas de mélanger les champs sans qualifier le transporteur et le schéma de l’opération utilisée.

Rapprocher l’ancienne méthode du bon code d’option

Associer les résultats par clé, sans faire confiance à leur ordre

La référence actuelle de l’API de compatibilité décrit une correspondance depuis des identifiants de méthodes. Elle avertit que l’ordre n’est pas garanti, que certaines correspondances peuvent être nulles et que des méthodes inexistantes peuvent être absentes. Elle indique une limite de cent identifiants par requête et précise que cette API est dépréciée.

Un raccordement qui associe deux listes par la position de leurs éléments peut donc attribuer à une commande le code d’une autre méthode. Retrouvez la clé de la méthode d’origine dans le résultat qualifié. L’absence et la valeur nulle ouvrent des dossiers différents, mais aucune des deux ne justifie de prendre une option voisine pour rendre le traitement réussi.

Utiliser la compatibilité pour la transition, puis sortir de la dépendance

Une correspondance peut aider à analyser les méthodes historiquement inscrites dans le SI. Elle ne constitue pas un catalogue permanent de services disponibles pour chaque commande. Préparez la sélection courante depuis les informations du colis et du point, plutôt que de faire dépendre tous les nouveaux départs d’un outil annoncé comme déprécié.

L’arbitrage dépend de votre existant : garder une table de transition versionnée pour expliquer les anciennes commandes, puis qualifier le parcours de recherche destiné aux nouvelles. Le responsable du connecteur précise comment fermer la dépendance temporaire. Une bascule qui ne possède aucun critère de fermeture finit par maintenir deux modes de sélection indéfiniment.

Rechercher une option pour le point et le colis effectivement préparés

Vérifier le schéma actuel plutôt que recopier une annonce de lancement

La référence Shipping Options actuelle présente to_service_point comme objet et marque l’ancien to_service_point_id comme déprécié. Elle précise aussi que, lorsque id et carrier_service_point_id sont fournis ensemble, le second est prioritaire pour cette recherche. Ce comportement appartient à cet endpoint ; il ne doit pas être attribué à toute opération de création.

Cette évolution explique pourquoi une recette doit citer la référence vérifiée, pas seulement une ancienne note de changement. Si votre adaptateur conserve un champ ancien, faites qualifier sa compatibilité et la trajectoire de remplacement. Ajouter les deux identités pour « couvrir tous les cas » pourrait changer le filtre effectif alors que le code semble seulement plus complet.

Relire le résultat dans son contexte de colisage

La documentation des options et devis transport explique que les options dépendent notamment des transporteurs activés, des destinations et des caractéristiques du colis. Une réponse HTTP 200 peut contenir une liste vide. Ce résultat ne fournit aucune option à sélectionner pour les filtres employés.

Dans votre orchestration, attachez la recherche au point retenu et à une version du colisage. Si l’entrepôt modifie le poids, les dimensions ou le nombre de pièces, le résultat précédent doit être réexaminé selon le besoin. Notre jeu de données utilise seulement une version de dossier fournie : elle ne calcule aucun gabarit admissible ni aucune règle native de poids.

Exercice corrigé : huit dossiers à classer avant toute annonce

Le jeu fictif porte une ancienne méthode 123, un point Sendcloud 1000001 et un colisage P1. Deux codes internes, local:relay et local:other, représentent des correspondances déjà fournies ; ils ne sont pas des codes transporteur utilisables. Le tableau compare les décisions du programme exécuté, sans envoyer de requête à Sendcloud.

Séparer dossier prêt à qualifier et dossier à reprendre

Chaque cas est indépendant. La liste d’options et le contexte de sa recherche sont des observations fictives fournies, pas une lecture actuelle d’un compte. La sortie permettant de poursuivre contient quelques champs rapprochés ; elle attend toujours la validation du schéma complet, des droits et des autres exigences de votre expédition.

Lire les frontières effectivement testées

Les huit cas passent et huit entrées invalides sont refusées : méthode booléenne, ancien numéro négatif, liste de codes mal typée ou dupliquée, correspondance vide ou booléenne, identité entourée d’espaces et exigence exprimée avec le mauvais type. Ces gardes protègent le schéma propre au jeu ; elles ne constituent pas un validateur universel des réponses Sendcloud.

Le premier test de frontière inverse l’ordre des correspondances et des options : la méthode 123 garde local:relay. Le second retire la clé 123 : la décision attend une qualification au lieu de prendre 456. Le troisième change le point sélectionné vers 1000002 : la recherche fournie pour 1000001 doit être renouvelée. Les données d’entrée restent intactes après les décisions.

La sortie A ne contient ni toutes les adresses ni tous les attributs obligatoires de l’API. Elle n’annonce aucun colis et ne démontre aucune disponibilité transporteur. La sortie H s’appuie sur une preuve historique fournie ; le laboratoire ne télécharge pas ce document et ne teste pas sa validité d’impression.

Compléter les exigences sans modifier silencieusement le choix client

Obtenir les informations de retrait réellement requises

La procédure de livraison citée plus haut précise que certains points, comme une PackStation DHL, demandent aussi un numéro de retrait ; lorsqu’il est requis, il est transmis via to_address.po_box. L’absence de cette information ne se corrige pas en recopiant le code postal du lieu ou le numéro du point. La donnée appartient à un besoin distinct du routage.

Dans notre cas G, l’exigence est simplement un fait fourni. Le programme ne détecte pas qu’un établissement réel impose ce numéro. Votre intégration doit obtenir cette règle et la valeur associée depuis le parcours qualifié. Elle doit ensuite limiter leur exposition aux personnes et aux traitements qui en ont besoin pour cette expédition.

Faire approuver une alternative lorsqu’elle change la promesse

Une option introuvable peut venir d’un filtre, d’un compte ou d’une évolution du dossier. Le support classe la cause avant de proposer un autre transporteur ou un autre lieu. Le connecteur conserve le choix initial et la proposition modifiée, sans présenter le nouveau résultat comme si l’acheteur l’avait déjà accepté.

Le suivi des points relais et de leur validation avant préparation prolonge cette question dans le quotidien des commandes. La migration change le mapping ; les responsabilités de décision restent à qualifier avec le métier, particulièrement lorsque le lieu de retrait ou les conditions de livraison doivent être modifiés.

Garder les expéditions V2 existantes séparées des départs V3

Relire une preuve ancienne dans son contrat d’origine

Un dossier déjà annoncé peut conserver son identifiant, son document et le contrat qui l’a produit. L’ouverture du nouvel adaptateur ne lui donne pas automatiquement une nouvelle intention d’expédition. Faire passer toutes les lignes historiques dans la création V3 ajouterait des effets, alors que le besoin consiste souvent à consulter ou à rapprocher l’ancien départ.

Le cas H conserve donc le document fourni comme historique. Cette règle locale suppose que son état a été correctement qualifié avant l’entrée du jeu. Si les équipes ne savent pas si une création passée a abouti, elles doivent examiner ce résultat avec le mécanisme de rapprochement approprié ; notre sortie historique ne résout pas cette incertitude.

Rattacher la bonne version aux flux ERP et entrepôt

La commande, l’expédition et le document suivent des identités séparées dans le SI. Votre ERP peut avoir besoin d’une confirmation de départ ou d’une livraison, mais cette écriture ne découle pas de la conversion d’un code de méthode. Conservez la version de l’adaptateur et les références nécessaires pour relire chaque état.

Le rapprochement des départs fractionnés avec l’ERP traite une autre rupture de cette chaîne. Il rappelle qu’une correspondance transport n’explique pas à elle seule les quantités et les écritures attendues. La bascule Sendcloud doit garder ce lien métier lorsqu’un ordre rejoint plusieurs dossiers de préparation.

Enregistrer la décision de mapping avant de construire le payload

Le middleware reçoit en entrée le point sélectionné, la méthode historique et la version de préparation. Sa sortie conserve la décision, le code retenu et la référence du résultat examiné. Ces responsabilités doivent être attribuées dans le contrat d’échange : le checkout fournit le choix, l’ERP garde sa provenance et l’adaptateur prépare le payload complet après validation. La traçabilité permet de retrouver une correction sans déduire la sélection depuis la seule étiquette.

La synchronisation ne doit pas transformer une commande déjà annoncée en nouvelle demande à chaque passage du worker. L’idempotence du traitement local conserve l’identité de cette intention et la décision enregistrée ; elle ne garantit pas, à elle seule, l’absence de doublon distant. L’équipe qualifie séparément le mécanisme de création et de rapprochement que l’API utilisée permet réellement.

Le runbook de repli distingue une lecture d’options interrompue d’une annonce dont le résultat manque. Après un timeout de lecture, un retry peut renouveler la recherche en conservant son contexte ; après une création incertaine, les opérations doivent retrouver l’effet avant d’autoriser une autre demande. Le laboratoire ne simule pas ces échanges. Ils font partie de la recette du raccordement avec le compte et les logiciels réels.

Mesurer les commandes reprises pour un mapping inexpliqué

Compter les causes avant d’étendre la migration

Exemple concret fictif : vingt commandes demandent quatre minutes chacune pour retrouver le point choisi dans un autre écran. Le calcul produit 80 minutes de recherche, sans attribuer de gain client ni de coût d’étiquette. Le coût caché de la reprise dépend ensuite du poste mobilisé, de la préparation interrompue et des modifications à faire accepter.

Comptez séparément les points absents, les numéros d’une autre origine, les méthodes non rapprochées et les recherches devenues anciennes. Un taux global de refus ne permettrait pas de décider si la priorité est le checkout, la transformation ERP ou la recherche d’options. Une même commande doit garder son identité pendant plusieurs échanges de qualification.

Limiter l’ouverture aux causes dont la reprise est démontrée

Une file d’attente peut être utile au début, à condition que chaque dossier indique la donnée manquante, le responsable et la prochaine action. L’opérateur ne doit pas relancer le même traitement indéfiniment face à une correspondance nulle. L’équipe du connecteur doit pouvoir modifier le mapping après une vérification, puis expliquer la décision réexécutée.

Contre-intuitivement, un périmètre plus petit peut permettre une bascule plus utile : quelques transporteurs avec des points et des options expliqués valent une activation large qui oblige à rechoisir les lieux à la main. Cet arbitrage ne vise pas un taux de migration flatteur. Il vise des commandes que la préparation peut continuer sans inventer une nouvelle sélection.

Plan d’action : recetter une famille de commandes en point relais

Écrire le contrat de données avec les équipes qui préparent

Choisissez un parcours qui porte le point du checkout jusqu’à la préparation, puis listez ses consommateurs. Pour chaque passage, retrouvez les entrées, les sorties, les identités et les transformations réalisées. L’équipe e-commerce confirme la sélection ; les responsables logistiques expliquent le colisage ; l’installateur ERP qualifie les champs et les dépendances disponibles dans votre logiciel.

Conservez une observation avant et après transformation sur des dossiers représentatifs, avec une journalisation limitée aux données utiles. Introduisez une identité absente, une correspondance nulle, une liste vide et une modification de colisage. La recette compare les décisions attendues et leur responsable de reprise avant d’autoriser une création distante. Les codes du laboratoire ne deviennent pas une configuration d’exploitation.

Définir l’ouverture et le repli avant les nouveaux départs

Le seuil proposé pour votre échantillon de recette est zéro sélection silencieuse d’une autre méthode ou d’un autre point. Un second seuil exige zéro nouvelle annonce destinée uniquement à remplacer l’historique d’un dossier déjà qualifié. Ce sont des critères locaux de recette, sans garantie sur toutes les futures commandes. Les échecs restent expliqués et démontrent une reprise avant l’élargissement.

En mode de repli, suspendez le nouveau parcours de création sur les dossiers concernés, puis relisez les effets déjà obtenus avant toute autre tentative. Le monitoring garde les causes de qualification et la version de mapping ; le responsable d’intégration décide des corrections avec les opérations. Les nouvelles sélections repartent de leur contexte, tandis que les expéditions historiques conservent leurs preuves.

• À ouvrir d’abord : les commandes dont point, méthode, recherche et dossier de préparation peuvent être rapprochés.
• À reprendre : les identités absentes, correspondances nulles et informations de retrait requises mais manquantes.
• À maintenir séparés : les résultats historiques et les nouvelles intentions d’expédition.

Erreurs fréquentes dans le nouvel adaptateur de transport

Choisir la première valeur parce que la réponse est réussie

Un résultat techniquement reçu peut manquer la correspondance de la méthode demandée. Le programme doit retrouver cette clé avant de proposer un code. Une liste vide ne devient pas un catalogue dans lequel prendre le moins cher, et une valeur nulle ne désigne pas le service suivant dans un tableau.

• Rapprocher les valeurs par leur identité d’origine, sans dépendre de l’ordre du résultat.
• Conserver absence, valeur nulle et option non présente comme trois causes à examiner.

Réutiliser une recherche après modification de la préparation

Le point retenu et le dossier utilisé pour rechercher les options doivent rester liés. Une modification en entrepôt ouvre une nouvelle qualification si elle affecte les conditions de transport. Dans notre test, P2 ne peut pas hériter du résultat fourni pour P1, même lorsque le code présent dans l’ancienne liste paraît familier.

• Attacher l’observation de recherche au contexte qui l’a produite.
• Faire expliquer le changement avant de libérer la nouvelle préparation.

Transformer une preuve ancienne en ordre de recréation

Un historique ne demande pas automatiquement une nouvelle étiquette lors d’un changement de version. Relisez d’abord l’objet et l’effet déjà qualifiés. Si leur état reste incertain, le dossier attend une investigation adaptée ; il ne rejoint pas le flux nominal simplement pour afficher partout le même format d’identifiant.

• Retrouver la version et la preuve du dossier existant avant de lui appliquer une nouvelle opération.
• Limiter la création aux intentions dont les conditions ont été établies.

Guides complémentaires pour relier migration, préparation et SI

La conversion des champs ne termine pas le raccordement. Les lectures suivantes abordent les capacités de l’agrégateur, la vie du point relais, les écritures ERP et la diversité des contrats logiciels. Elles prolongent les décisions sans faire du petit jeu de données un modèle complet de transport.

Qualifier l’agrégation et les exceptions de retrait

L’étude des produits, documents et retours Sendcloud remet le point dans la chaîne de transport. Le parcours des points relais jusqu’à la préparation explique la continuité du choix client. Ces parcours aident à répartir les actions : corriger une identité perdue, rechercher une option adaptée ou faire examiner une alternative commerciale.

• Garder le point accepté visible pour le support après chaque transformation.
• Examiner les exceptions de retrait avec leur source et leur moment de décision.

Préparer les différences entre deux systèmes clients

La méthode du connecteur ERP pour un second client logiciel rappelle qu’un raccordement ne se généralise pas par copie de ses champs. L’un de vos clients peut conserver le numéro Sendcloud et l’autre seulement une référence transporteur ; leurs sources doivent être qualifiées avant une transformation commune.

• Documenter la provenance et le contrat de chaque champ transmis par le logiciel client.
• Tester la décision sur les variantes réellement rencontrées avant de présenter le connecteur comme réutilisable.

Relire le sens du trajet après une difficulté de retrait

Une migration qui préserve le point choisi doit également conserver les exceptions du parcours. Si le colis repart vers son expéditeur, une remise finale au retour ne termine pas la promesse faite à l’acheteur. Le suivi et la préparation gardent leurs identités et leurs décisions distinctes.

Le diagnostic DHL : retour expéditeur annoncé livré au client examine le contre-exemple parcel-de et seize observations locales. Il prolonge la chaîne après le départ sans assimiler le contrat Unified aux réponses normalisées de Sendcloud.

Conclusion : migrer le raccordement en gardant le choix de retrait

La commande en point relais doit retrouver le lieu accepté par le client avant de chercher une option de transport. Déplacer un numéro entre deux champs ne suffit pas : son origine, la méthode historique et le contexte de préparation expliquent ce que le nouveau raccordement peut réellement proposer.

Les huit dossiers fictifs distinguent les sorties utiles. Une identité manquante appelle une qualification, une correspondance nulle ne permet aucun choix de remplacement et un résultat associé à un ancien colisage doit être réexaminé. Le dossier déjà annoncé conserve son histoire. Aucune de ces décisions locales ne crée ni ne valide une étiquette réelle.

La référence actuelle de l’API, les exigences du compte et les champs disponibles dans vos logiciels fixent ensuite la recette. L’ouverture peut commencer par une famille de commandes dont les reprises sont explicables, avec les anciennes expéditions maintenues dans leur contrat d’origine et les nouvelles préparations qualifiées avant annonce.

Dawap vous accompagne dans votre intégration API pour retrouver la sélection de retrait, cadrer le mapping entre vos logiciels et organiser cette transition avec les équipes de préparation. Nous partons des commandes et de leurs données disponibles, puis construisons un premier parcours de qualification, de reprise et de création dont les décisions peuvent être relues.