Back Market : retrouver l’appareil de chaque commande

Votre préparateur ferme un colis Back Market avec un smartphone de 128 Go. L’ERP connaît la commande, le connecteur connaît le SKU, mais le support ne peut pas retrouver quel appareil a été envoyé. Deux semaines plus tard, un retour portant la même référence produit arrive à l’atelier. Rien ne permet encore de confirmer qu’il correspond à cette vente.

Le défaut ne vient pas nécessairement du transport des commandes. Une fiche produit peut représenter plusieurs appareils du même modèle, tandis que chaque numéro de série désigne une unité. Le risque est d’enregistrer une expédition avec l’identité du téléphone resté sur l’étagère lorsque ces niveaux sont confondus. Le remboursement et la remise en vente deviennent alors difficiles à justifier.

Le rapprochement doit commencer par l’appareil affecté à la ligne de commande, avant la transmission des identifiants, puis rester retrouvable au retour. Nous allons distinguer les interfaces disponibles, préparer le contrôle au poste d’emballage et examiner huit situations fictives. Le rapprochement porte sur une ligne de commande précise ; connaître son SKU ne suffit pas à identifier l’unité réellement sortie.

Notre accompagnement des vendeurs marketplace relie cette traçabilité aux opérations quotidiennes. L’expertise Back Market pour les vendeurs professionnels aide à qualifier les échanges entre le canal, l’ERP, la préparation et le SAV, avec votre installateur logiciel. Les exemples qui suivent ne décrivent aucun résultat client Dawap.

Pour quels reconditionneurs la commande ne suffit-elle plus à retrouver l’appareil ?

Ce travail concerne les vendeurs qui disposent de plusieurs exemplaires sous une même référence commerciale. Les appareils peuvent partager modèle, capacité, couleur et grade tout en conservant des historiques différents. La relation avec la vente se construit au moment de l’affectation et de la préparation, puis devient indispensable lorsqu’une question porte sur une unité particulière.

Partir d’un dossier que le support ne peut pas expliquer

Choisissez une commande expédiée dont le support doit retrouver la série, le contrôle atelier et le colis. Demandez également la référence de la ligne dans le canal et celle du mouvement dans l’ERP. Une recherche qui retrouve seulement le modèle acheté reste incomplète : elle ne distingue pas deux appareils interchangeables pour le catalogue, mais différents pour cette vente.

Un premier signal faible apparaît lorsque les opérateurs copient des numéros depuis plusieurs écrans pendant l’emballage. La répétition de cette tâche révèle une rupture entre l’affectation physique et l’export. Un second apparaît lorsque les retours sont rapprochés par modèle et montant, alors que le bon de sortie conserve une autre série. L’accord sur le prix ne résout pas cette différence d’identité.

Avec peu de commandes et une préparation centralisée, un contrôle assisté peut suffire. Le développement devient pertinent si les systèmes ne partagent pas les références nécessaires, si plusieurs postes travaillent simultanément ou si la reprise repose sur une personne qui connaît les appareils de mémoire. L’achat d’un connecteur supplémentaire doit répondre à cette rupture observée.

Comparer les fonctions existantes avant d’ajouter un pont ERP

Un outil déjà installé peut couvrir l’import des commandes et l’envoi des identifiants. Commencez par une démonstration avec vos variantes, votre préparation et un retour. Le fournisseur doit préciser quel chemin écrit dans Back Market, quelle donnée l’alimente et ce que l’opérateur voit lorsqu’une transmission reste incertaine.

Sellercloud : qualifier le service et les options activées

La documentation Sellercloud sur Back Market présente notamment commandes, suivi, stock et IMEI. Elle distingue son intégration API de l’intégration historique, dont l’emploi simultané peut produire des doublons. La présence de la fonction dans cette documentation ne prouve pas qu’elle est active dans votre compte ni raccordée à votre ERP.

Demandez à voir l’origine de la série envoyée sur une vente réelle anonymisée. Est-elle portée par l’unité prélevée, renseignée à la main ou obtenue depuis un autre logiciel ? Vérifiez le comportement lors d’une modification avant fermeture du colis. Le bon critère est la filiation retrouvable, plutôt que le nombre de cases cochées dans le paramétrage.

ChannelEngine : relire le parcours réellement utilisé

La documentation IMEI de ChannelEngine, mise à jour en septembre 2023, décrit son export et le réglage qui peut retenir une expédition sans IMEI. Elle expose aussi des limites de catégorie et de quantité. Ces indications concernent le parcours documenté : elles ne doivent pas remplacer la vérification de l’interface native actuelle.

Si votre chemin partenaire couvre les besoins, gardez-le comme responsable de l’écriture et raccordez la source qui lui manque. Si une fonction reste absente, délimitez l’adaptation avec son éditeur avant de développer. Deux chemins concurrents pour une même donnée compliquent le diagnostic, particulièrement lorsque la première transmission engage une identité difficile à modifier.

Séparer le SKU, l’unité ERP et la ligne Back Market

Le SKU décrit l’offre que le canal vend. L’unité interne désigne l’appareil que l’entreprise contrôle. La ligne de commande rattache la quantité achetée à une vente. Ces trois repères se complètent ; les ranger dans une seule colonne fait disparaître la différence entre un produit commercial et son exemplaire expédié.

Conserver les correspondances au moment de l’affectation

Dans notre scénario français fictif, le vendeur A reçoit les lignes 7101 et 7102 pour le même SKU PHONE-128. U17 et U18 représentent deux appareils distincts. La préparation affecte U17 à la première ligne et U18 à la seconde. Le support doit retrouver cette relation depuis la commande, la série ou le colis, sans remplacer les deux unités par une quantité globale de deux.

Le dossier conserve aussi le profil de connexion, le marché concerné, la société ERP et les références de ses documents. Ce contexte est nécessaire lorsque plusieurs comptes sont raccordés ; son format reste un choix du projet. Vérifiez la portée des identifiants fournis avant de décider lesquels peuvent être utilisés sans leur source.

Ne pas générer une identité commerciale depuis un compteur ERP

La documentation Odoo 19 sur les numéros de série distingue le suivi unitaire, les opérations qui créent ou utilisent les séries et leur affichage sur les bons de livraison. Ce paramétrage mérite une vérification avec l’installateur : la génération d’une référence interne ne relève pas automatiquement l’identifiant présent sur l’appareil.

Une série utilisée pour classer le stock peut donc différer de la série fabricant. Conservez leur correspondance lorsque les deux existent. Les identifiants restent des chaînes de caractères ; une conversion numérique peut retirer des zéros initiaux. Leur contrôle de validité et leur provenance physique sont deux vérifications distinctes, à prévoir avant l’ouverture des transmissions.

Vérifier l’interface native avant l’enregistrement de l’IMEI

La documentation API officielle Back Market présente une opération PATCH sur une ligne identifiée par orderline_id. Elle accepte imei, serial_number ou les deux ; les valeurs enregistrées ne peuvent ensuite pas être corrigées. Le schéma indique des longueurs maximales de quinze et cinquante caractères et une application à toutes les catégories.

Distinguer cette opération de la mise à jour de commande

La spécification expose également UpdateOrder : ses champs d’identité sont traités avec l’état d’expédition et seulement pour une commande contenant une ligne de quantité un. Un parcours utilisant cette opération et un parcours utilisant PATCH ne possèdent donc pas le même contrat. Faites confirmer celui que votre compte et votre connecteur emploient effectivement.

L’intégration prépare l’envoi après rapprochement du prélèvement, de la ligne et de l’identifiant contrôlé. Elle garde la donnée source, le résultat du contrôle et l’opération choisie. Une longueur admise n’atteste ni la validité d’un IMEI, ni la présence de ce téléphone dans le carton. Le poste de préparation doit apporter cette deuxième preuve.

Traiter un résultat incertain avant une nouvelle tentative

Si la réponse se perd, l’exploitation cherche les valeurs effectivement enregistrées avant toute reprise. Un accord permet de rattacher le résultat au dossier initial ; une différence demande une investigation. Lorsque l’interface ou les droits ne permettent pas cette lecture, le dossier reste suspendu pour rapprochement assisté. Une relance ne doit pas inventer la possibilité d’écraser l’identité précédente.

La personne qui reprend doit aussi retrouver l’affectation valable lors du premier envoi. Si le préparateur a changé l’appareil entre-temps, l’accord sur la nouvelle série ne prouve pas l’accord sur celle qui a été transmise. Conservez donc la version de l’affectation examinée, avec le dossier suspendu et son prochain contrôle.

Rattacher le scan au colis que l’opérateur ferme

Le contrôle au poste d’emballage doit afficher la commande, la variante attendue et l’unité affectée. L’opérateur lit ou scanne l’appareil présent, puis confirme le rapprochement. L’application ne valide pas l’expédition parce que le champ est rempli : elle vérifie que cette observation correspond à l’affectation encore autorisée.

Refuser une bonne référence sur le mauvais appareil

U17 et U18 peuvent posséder les mêmes caractéristiques vendues. Leur substitution paraît alors acceptable au préparateur, mais elle modifie la filiation conservée. Si l’entreprise autorise ce changement avant transmission, elle doit mettre à jour l’affectation par son circuit validé. Si une donnée a déjà été engagée vers le canal, le support doit traiter la contradiction avant de refermer le colis.

Une erreur de capacité réclame une autre réponse. PHONE-256 ne remplace pas PHONE-128 sous prétexte que les téléphones se ressemblent. Le refus mentionne la variante constatée et celle attendue afin que l’opérateur puisse reprendre le prélèvement. Réessayer le même scan ne peut pas corriger une différence de produit.

Conserver les preuves propres à chaque étape logistique

Identifiant préparé, donnée transmise, colis fermé et colis remis au transporteur sont des résultats différents. Enregistrez leur ordre et leurs références dans le circuit retenu. Une série vérifiée ne prouve pas le départ physique ; une étiquette imprimée ne confirme pas davantage que le colis a quitté l’entrepôt.

Le retour ERP suit les mouvements et documents prévus dans votre installation. La finance conserve son déclenchement de facturation et ses validations. Un statut logistique aide à expliquer la vente, mais ne remplace ni la pièce produite ni sa lecture par l’administration des ventes. La recette doit retrouver la même unité après chacun de ces passages.

Qualifier les commandes de plusieurs unités avant leur automatisation

Une quantité de deux appareils nécessite deux identités physiques dans votre exploitation. La présence d’un champ unique dans un schéma ne suffit pas à démontrer comment les transmettre. Le PATCH consulté ne décrit pas ici une règle de quantité autorisant ce rapprochement multiple. Cette absence documentaire demande une qualification ; elle ne prouve ni possibilité générale ni interdiction générale.

Demander une recette sur la forme réellement reçue

Présentez au fournisseur du connecteur une commande comportant deux unités d’un même SKU, puis une commande de deux références différentes. Il doit montrer les lignes reçues, les séries conservées, l’export et le résultat visible dans Back Market. Un essai réussi sur deux lignes de quantité un ne valide pas automatiquement une ligne de quantité deux.

Ne scindez pas une ligne dans vos registres comme si cette opération créait deux lignes natives dans le canal. Le modèle interne peut conserver deux unités, mais il doit toujours retrouver l’engagement reçu. Lorsque l’interface ne couvre pas le besoin démontré, gardez ce cas dans le traitement assisté et faites préciser la solution disponible.

Notre pilote fictif se limite volontairement aux lignes de quantité un. Il refuse le cas de quantité deux avant préparation des identifiants. Ce seuil est une décision locale destinée à maintenir un périmètre vérifiable ; il n’est pas attribué au comportement universel de Back Market. L’extension attend sa propre preuve sur le chemin choisi.

Rapprocher le retour sans confondre réception, qualité et remboursement

À réception, le dossier retrouve la ligne vendue, l’appareil attendu et la série effectivement relevée. Si les identités diffèrent, l’unité reste dans une zone de vérification avec son motif. Le rapprochement ne doit pas choisir la première commande du même modèle pour faire disparaître l’exception.

Vérifier les données disponibles pour votre circuit de retour

Les lectures de retours décrites dans l’API BackShip sont réservées aux marchands abonnés à ce service. Elles portent notamment les références de commande, de ligne et de transport. Vérifiez votre accès avant de les employer dans le raccordement. Un numéro de suivi renseigne le transport ; l’atelier doit encore observer l’appareil reçu.

L’état natif 6 décrit un remboursement après expédition, plutôt qu’une validation de remise en stock. Dans votre ERP, l’entrée physique, la décision qualité et la décision financière conservent leurs objets. Le connecteur transmet les observations disponibles sans inventer un mouvement de remboursement depuis la seule arrivée du colis.

Préserver l’historique lorsqu’un appareil est remplacé

Une réparation peut conserver l’appareil initial ; un échange peut employer une autre unité. Le dossier doit montrer le choix réellement effectué et les références des nouveaux mouvements. Remplacer la série dans la vente d’origine ferait perdre la preuve de ce qui a été expédié, puis reçu. Le SAV conserve donc la filiation entre appareil sorti, appareil retourné et éventuel remplacement.

Paradoxalement, une série parfaitement rapprochée peut laisser l’appareil retourné indisponible à la vente. Batterie, accessoires, état matériel et intervention atelier déterminent la prochaine décision dans votre procédure qualité. L’accord d’identité permet de poursuivre ce contrôle ; il ne transforme pas instantanément le produit en disponibilité commerciale pour une autre commande.

Exercice : huit situations de préparation et de retour corrigées

Le scénario utilise un vendeur fictif, deux lignes françaises de quantité un et trois unités internes. U17 et U18 correspondent à PHONE-128 ; U19 à PHONE-256. Les séries SN-DEMO-017 et SN-DEMO-018 servent de repères. Les IMEI de démonstration ne sont pas des identifiants certifiés valides ; leur contrôle métier reste hors de cet exercice.

Un modèle en mémoire prépare les correspondances et simule un enregistrement distant. Les contrôles vérifient les sorties et les effets conservés, avec une panne d’accusé injectée après une écriture simulée. Ils n’appellent aucune API, ne modifient aucun ERP et ne réalisent ni expédition ni remboursement.

Lire le résultat sans attribuer des garanties au canal

A vérifie deux affectations malgré un SKU commun et conserve les zéros initiaux d’une chaîne fictive. B et C refusent deux causes différentes avant tout envoi. D porte sur la comparaison avec l’affectation, plutôt que sur la validité intrinsèque du numéro. E retrouve une écriture simulée ; F ne modifie pas son résultat lorsqu’une autre identité est présentée.

Un contre-test positif reçoit ensuite la série attendue de U17. Le dossier passe à la qualité en attente, sans remise en vente ni remboursement automatique. Cette sortie vérifie la distinction entre identité retrouvée et produit revendable. H reste, séparément, un dossier d’identité contestée.

Les huit groupes sont exécutés séquentiellement. Ils n’établissent pas la résistance de votre ERP à deux réservations simultanées, la validité d’un IMEI ou la possibilité de rechercher un résultat avec vos droits réels. La recette de l’installation complète ces limites par ses transactions, ses lectures autorisées et l’observation des objets effectivement écrits.

Plan d’action : ouvrir un poste de préparation avec une seule voie d’écriture

Le pilote commence sur un vendeur, un marché et une famille de produits sérialisés. Relevez les documents ERP, les données du connecteur et les gestes au poste de préparation. Les entrées comprennent ligne reçue, variante, unité affectée et identifiant observé. Les sorties montrent la donnée préparée, son résultat transmis et les références du départ.

Donner une décision à chaque équipe avant l’ouverture

Le responsable vendeur confirme le parcours du canal et les cas conservés en assistance. La logistique valide prélèvement, scan et fermeture du colis. L’atelier décide de la qualification des retours. L’installateur ERP vérifie réservations, séries, droits et mouvements ; l’intégrateur du connecteur confirme lecture, écriture et reprise. La finance conserve l’autorisation des pièces et remboursements.

Le contrat du raccordement précise les champs, leur source, le format des identifiants et les opérations autorisées. Sa journalisation relie le dossier à la version du mapping et au résultat obtenu. Évitez de disperser les identifiants complets dans tous les logs : les accès aux données de traçabilité suivent les besoins des personnes qui traitent la vente.

Définir le veto et la reprise au niveau du dossier

Le seuil proposé pour ce périmètre est zéro unité affectée à deux ventes actives, zéro scan contradictoire transmis et zéro conflit d’identité traité par écrasement. La CI rejoue les exemples approuvés lors d’une évolution du mapping. La QA ajoute deux opérateurs concurrents, une indisponibilité du canal et une permission retirée pendant la préparation.

Le monitoring distingue donnée manquante, variante différente, résultat inconnu et retour contesté. Le runbook donne la recherche à effectuer, le responsable de décision et la preuve nécessaire à la reprise. Le rollback suspend les nouveaux envois et rétablit le contrôle assisté ; il conserve les enregistrements déjà effectués et les colis déjà partis.

• Ouvrir d’abord : les lignes de quantité un dont l’appareil peut être retrouvé depuis le scan jusqu’au dossier vendeur.
• Différer : les lignes multi-unités et les échanges de remplacement dont l’interface reste à qualifier.
• Refuser : une identité contradictoire, une affectation physique double ou une disponibilité créée depuis un retour non examiné.

Mesurer la charge de recherche et les dossiers encore inexpliqués

Le nombre de commandes importées ne révèle pas combien d’appareils sont effectivement retrouvables. Mesurez les lignes pour lesquelles le support peut relier unité, série, colis et retour. Gardez aussi les dossiers refusés et leur âge : ils représentent le travail restant, même lorsque les autres ventes sont correctement synchronisées.

Comparer un coût de traitement sur une population stable

Un budget fictif de quarante retours, examinés pendant douze minutes chacun, représente huit heures. Un traitement de cinq minutes par retour représenterait trois heures et vingt minutes, soit une différence de quatre heures et quarante minutes. Ce calcul ne constate aucune économie réelle. Le pilote doit mesurer recherche, qualification et reprise sur les mêmes catégories de dossiers.

Ajoutez les dossiers qui restent en investigation, les adaptations du connecteur et le maintien du poste de scan. Une baisse du temps moyen peut cacher le transfert des cas difficiles vers l’atelier. Le bilan conserve donc les exceptions et leur délai de fermeture, plutôt que présenter les seuls dossiers simples comme la performance générale.

Si le suivi devient récurrent sur plusieurs canaux, Ciama peut être étudié comme relais de pilotage après confirmation des fonctions disponibles. L’affichage d’une vente dans un outil de suivi ne prouve pas qu’il porte la réservation unitaire ou l’écriture des identifiants. Ces responsabilités restent attribuées aux systèmes qualifiés pour votre parcours.

Erreurs fréquentes : trois rapprochements qui masquent le mauvais appareil

• Rapprocher par le seul SKU : deux téléphones identiques commercialement restent deux unités différentes. La recherche repart de l’affectation conservée et du document de sortie, puis confirme le numéro observé.
• Corriger une vente en remplaçant sa série : ce geste peut masquer une substitution ou un retour différent. Le support conserve la contradiction et ouvre le circuit prévu pour l’examiner, avec les effets déjà transmis.
• Réintégrer dès la réception : le colis revenu peut contenir un autre appareil ou un produit encore à contrôler. L’atelier confirme séparément identité, état et décision de disponibilité avant toute nouvelle promesse commerciale.

Pour chacune de ces erreurs, vérifiez également le document consulté par le support. Un écran à jour peut présenter une correspondance corrigée sans expliquer celle qui a servi à l’expédition. Les références historiques doivent rester retrouvables pour comprendre le dossier et décider de sa prochaine action.

Guides complémentaires : approvisionnement, ERP et atelier

La traçabilité unitaire intervient entre les sources d’approvisionnement, la vente et le traitement du retour. Ces guides approfondissent les opérations qui l’entourent ; ils ne remplacent pas la qualification des interfaces Back Market présentées ici.

Raccorder un ERP qui travaille encore par fichiers

Le parcours marketplaces avec un ERP sans API devient utile lorsque vos correspondances arrivent par exports. Il aide à distinguer fichier reçu, opération acceptée et preuve de résultat. La filiation de l’appareil doit alors survivre à ces échanges plutôt qu’être reconstruite après expédition.

Le premier extrait à demander contient la ligne de vente, la référence interne de l’unité et l’identifiant physique relevé. Si l’export ne comporte que produit et quantité, la trace nécessaire doit venir d’une autre restitution autorisée. Un format CSV correct ne peut pas fournir une correspondance absente du système source.

Relier la vente à l’achat fournisseur

La démarche d’automatisation des achats fournisseurs marketplace précise les références et confirmations à conserver lorsque l’approvisionnement répond à la vente. Une acceptation fournisseur peut annoncer une quantité ; l’entrée en stock doit encore permettre d’identifier les appareils réellement reçus.

Lorsque l’approvisionnement remplace une unité refusée, gardez la vente et l’achat qui expliquent cette nouvelle entrée. La disponibilité annoncée par le partenaire ne choisit pas l’appareil qui servira la commande. Le prélèvement et son affectation interviennent après la réception qualifiée, avec leurs propres références.

Préparer les offres sans confondre catalogue et unité

Les catalogues fournisseurs XML pour les marketplaces concernent les prix, références et disponibilités en amont. Leur rapprochement produit ne fournit pas à lui seul la série de l’appareil affecté. Cette séparation aide à choisir ce que le flux catalogue peut alimenter et ce que la préparation doit observer.

Les prix et variantes du flux restent liés à la version produit utilisée lors de la vente. Un enrichissement ultérieur du catalogue ne doit pas transformer l’appareil historique en modèle différent. Le support confronte la promesse vendue à l’unité sortie plutôt que consulter seulement la fiche courante.

Organiser un atelier qui suit les retours et réparations

Le portail SAV relié aux réparations et à l’ERP traite demandes, accords et interventions. Il prolonge le suivi lorsque votre propre atelier gère le dossier après réception. Son exemple fabricant reste distinct du fonctionnement natif de Back Market.

Le besoin d’un portail se juge sur les échanges que l’atelier n’arrive pas à suivre : diagnostic reçu, pièce attendue ou restitution à organiser. Gardez les fonctions existantes si elles rendent ces étapes lisibles. Une nouvelle interface ne compense pas l’absence de série rapprochée dans la vente d’origine.

Conclusion : conserver l’appareil de la vente jusqu’à la décision atelier

Une commande correctement importée laisse encore une question essentielle au vendeur : quel appareil a été affecté, transmis, expédié puis éventuellement retourné ? La réponse demande des correspondances conservées entre la ligne du canal, les documents ERP et l’unité physique. Le modèle produit et le montant de la vente ne peuvent pas les remplacer.

Le choix d’un connecteur commence par la preuve sur votre parcours. Les opérations natives et les chemins partenaires doivent être distingués, particulièrement avant l’engagement des identifiants. Le poste d’emballage vérifie l’appareil présent ; le support traite un résultat incertain avec la filiation déjà acquise.

Les huit situations donnent une recette locale limitée : variante refusée, unité déjà affectée, scan différent, accusé perdu et retour contesté. Elles ne certifient aucun service distant. Leur prolongement est une démonstration sur les interfaces autorisées, avec les opérations concurrentes et les documents que vos équipes utiliseront réellement.

Dawap peut cadrer ce raccordement dans votre organisation vendeur marketplace, avec la préparation, l’atelier et votre installateur ERP. Une vente anonymisée, son appareil, son colis et un retour représentatif permettent de choisir les adaptations utiles avant d’étendre l’automatisation.