Une taille s’arrête : pourquoi votre connecteur coupe-t-il toutes les autres ?

La taille M d’un modèle sort de votre assortiment ERP, mais les tailles L et XL restent vendues. Le connecteur reçoit « inactif », désactive la fiche PrestaShop entière et coupe toutes les tailles. Une correction manuelle rétablit le produit ; le lot suivant remet la taille M en vente. Pendant ce temps, une commande ancienne contenant cette déclinaison attend son export parce que la correspondance catalogue a disparu.

Le risque vient du mélange entre trois décisions : arrêter de nouvelles ventes, conserver une référence technique et reconnaître ce qui a déjà été commandé. En pratique, le retrait doit commencer par la déclinaison et son contexte boutique, puis préserver les identités nécessaires aux dossiers anciens. Un statut ERP ne donne pas automatiquement le droit de désactiver le produit parent ou de supprimer son historique de raccordement.

Nous allons suivre un modèle avec deux tailles, distinguer les champs natifs des règles du connecteur et corriger huit intentions fictives. Vous pourrez préparer le retrait commercial, refuser une portée trop large et retrouver une ligne ancienne sans la remplacer par l’article actuellement disponible. Les essais exécutés restent des comparaisons locales de faits fournis ; ils ne modifient aucune boutique, aucun stock ni aucune commande ERP.

Notre accompagnement en intégration API entre logiciels peut construire ce contrat de cycle de vie. Pour une intégration PrestaShop avec votre ERP, nous qualifions les ressources de la version installée et les interfaces du logiciel de gestion avec son intégrateur. Le premier périmètre peut être une famille de tailles dont une seule référence s’arrête.

Pour qui : un catalogue ERP qui arrête des tailles ou des coloris

Reconnaître le retrait qui dépasse la référence concernée

Le besoin apparaît chez un fabricant ou un distributeur dont l’ERP pilote l’assortiment, tandis que PrestaShop rassemble plusieurs déclinaisons sur une fiche. Une couleur peut sortir du catalogue sans arrêter le modèle. Une taille peut rester préparée pour des commandes déjà acceptées alors qu’aucune nouvelle vente ne doit être ouverte. Les opérations doivent nommer cette différence avant de choisir un champ d’écriture.

Un premier signal faible est le retour d’une référence arrêtée après une réception de stock ou un import nocturne. Un autre est une série de commandes rejetées pour « article inconnu » juste après un nettoyage catalogue. Ces incidents relient des traitements distincts : publication courante, lecture des commandes et résolution des références. Le diagnostic rassemble leur chronologie au lieu d’accuser seulement la disponibilité affichée.

Distinguer fin d’assortiment, rupture et remplacement

Une rupture temporaire signifie que la référence peut revenir. Une fin d’assortiment engage une décision commerciale durable. Un remplacement par une nouvelle version change éventuellement l’identité vendue. Ces motifs doivent rester séparés dans le contrat ERP : une quantité nulle ne décrit pas lequel s’applique, et un libellé « inactif » peut porter plusieurs intentions selon le logiciel source.

Si le besoin concerne l’arrêt de tout le modèle dans une boutique, une action au niveau produit peut être cohérente après validation de sa portée. Si une seule taille est visée, le connecteur doit disposer d’un mécanisme qualifié pour cette taille. Une règle personnalisée n’est justifiée que lorsque les possibilités natives et les modules en place ne couvrent pas le parcours attendu. La recette précède ce choix.

Anatomie du dossier : produit parent, déclinaison et ligne commandée

Conserver l’identité technique en plus de la référence commerciale

Le dossier fictif utilise le produit PrestaShop 80 et les déclinaisons 8 et 9, dans la boutique 1. La déclinaison 8 représente une taille M ; la 9 représente une taille L. Leurs correspondances ERP sont distinctes. Les nombres et les noms de tailles servent uniquement à l’exercice. Un identifiant PrestaShop n’est pas global entre deux installations, et une référence commerciale peut être modifiée ou réutilisée.

La clé de raccordement conserve donc installation, boutique, produit et déclinaison, puis leur relation avec la société et l’article ERP. Le nom du modèle aide à lire le dossier ; il ne remplace pas ces identités. Si une référence fournisseur change, l’équipe qualifie son alias et sa période. Elle ne réaffecte pas toutes les ventes anciennes au premier article actuel qui porte le même texte.

Lire les noms de champs dans chaque ressource

La ressource de stock PrestaShop 9 utilise notamment id_product et id_product_attribute. La ressource des détails de commande expose product_id et product_attribute_id, ainsi que nom et référence vendus. Le mapping doit traduire ces contrats sans confondre la ligne historique avec une lecture du catalogue courant.

Un export de commande tardif doit partir de la vente et de ses correspondances conservées. Il ne redemande pas au catalogue actuel quelle taille le client aurait pu acheter aujourd’hui. La preuve de ligne inclut les identités et les valeurs utiles au traitement ERP. Les capacités de facturation, retour et réintégration restent à vérifier dans vos logiciels ; la présence de champs documentés ne garantit pas tous ces parcours.

Pourquoi le champ actif du produit ne retire pas une seule déclinaison

Vérifier la propriété avant de traduire le statut ERP

Dans le schéma Products du Webservice PrestaShop 9, active et available_for_order appartiennent au produit. Le schéma Combinations ne documente pas une propriété active équivalente. Il expose d’autres champs, dont produit associé, référence et choix par défaut. Cette lecture porte sur le contrat publié, pas sur toutes les extensions possibles d’une boutique.

Le connecteur ne peut donc pas copier « inactif ERP » dans un champ de déclinaison qu’il suppose exister. Écrire l’état du produit parent transforme une décision sur M en décision sur M et L. Une interface personnalisée peut offrir un contrôle plus précis, mais son comportement doit être décrit et testé. Son existence ne se déduit ni du nom d’un module ni de la réussite d’un appel générique.

Qualifier le mécanisme commercial réellement disponible

Le cadrage examine le thème, les modules, les parcours d’achat et les interfaces autorisées. Il définit comment une déclinaison est exclue des nouvelles ventes tout en restant reconnaissable pour le support. Selon l’installation, le travail peut porter sur une règle existante, un module ou un développement adapté. Aucun endpoint de retrait universel n’est proposé ici.

La candidate de retrait contient l’identité concernée, le motif source, la version et le comportement attendu. Une validation de portée protège les déclinaisons voisines avant l’écriture éventuelle. Si le mécanisme qualifié ne permet pas cet isolement, le dossier revient au cadrage. Le middleware ne désactive pas le parent simplement pour obtenir un résultat techniquement accepté.

Une quantité nulle ne constitue pas une preuve d’arrêt des ventes

Lire la politique de vente en rupture avec la quantité

La FAQ officielle sur le stock PrestaShop 9 distingue quantité disponible et politique out_of_stock. Cette politique peut refuser la vente en rupture, l’autoriser ou reprendre la configuration par défaut. Mettre un compteur à zéro ne prouve donc pas, à lui seul, que la taille arrêtée ne peut plus être commandée.

Cette limite devient visible lorsqu’un import ERP remet une quantité positive ou lorsqu’une politique globale autorise les commandes sans stock. Le connecteur doit conserver le retrait commercial indépendamment de l’observation logistique. Un retour de marchandise peut fournir des unités à contrôler sans autoriser leur remise en vente. La décision d’assortiment reste attribuée au commerce.

Recetter une barrière d’achat et préserver les quantités existantes

La recette tente une nouvelle commande par les chemins disponibles dans votre boutique : fiche, panier déjà rempli, lien conservé et interfaces de vente concernées. Elle observe la décision obtenue pour la déclinaison visée et pour une taille encore vendue. Masquer une option dans le navigateur peut améliorer la présentation ; cela ne démontre pas le contrôle effectué lors de l’engagement de commande.

Le retrait n’autorise pas une falsification du stock physique ou une suppression des réservations. Les commandes déjà prises gardent leur traitement logistique. La FAQ déconseille de modifier directement les quantités physiques et réservées qu’elle décrit comme recalculées. Le projet définit avec la logistique les mouvements et décisions réellement nécessaires ; un indicateur « retiré » ne remplace pas ces observations.

Garder une correspondance retirée pour reconnaître les ventes anciennes

Un registre de retrait distinct du catalogue publiable

Le registre du connecteur conserve la correspondance avec un état de cycle de vie et une version. Les nouvelles publications consultent la décision commerciale ; les lectures historiques retrouvent encore les références utilisées lors de la vente. Ce registre appartient à l’architecture d’intégration proposée. Il n’est pas présenté comme une ressource native supplémentaire du Webservice PrestaShop.

Paradoxalement, conserver la correspondance d’une référence retirée protège l’arrêt commercial : le connecteur peut reconnaître les demandes anciennes sans recréer l’article dans le catalogue publiable pour débloquer leur traitement. Cette conservation ne réautorise aucune vente. Le registre distingue son usage historique de son état de publication ; le support retrouve la référence sans demander au commerce de rouvrir la taille.

Ne pas substituer le successeur dans une commande déjà passée

Une taille ou une génération de remplacement possède sa propre identité. La commande ancienne conserve celle de la référence vendue. Si le client accepte un échange, cette nouvelle décision commerciale est traitée explicitement avec ses pièces et ses opérations. Elle ne se cache pas dans une mise à jour automatique du mapping destinée à débloquer un export.

Le stockage historique doit être défini selon les usages et les règles applicables au projet. Il garde les valeurs nécessaires et protège l’accès aux données commerciales. Le diagnostic technique n’a pas besoin d’une copie complète du compte client. La recette vérifie que l’équipe peut résoudre la ligne avec une correspondance datée, même lorsque la référence courante est absente ou a changé.

Exercice corrigé : huit décisions autour d’une taille retirée

Comparer des intentions sans exécuter de modification catalogue

Le comparateur local reçoit boutique 1, produit 80, déclinaison 8 et une version de décision 2. Les entrées déclarent la correspondance, la conservation du mapping, la présence d’une preuve historique et la vérification d’une barrière d’achat. Il n’obtient pas ces faits dans PrestaShop. Leur qualification réelle constitue précisément le travail que le pilote doit effectuer.

Une candidate conforme signifie seulement que ces faits fournis satisfont notre politique de comparaison. Le programme ne construit pas de payload natif, ne calcule pas de stock et ne choisit aucun module. Pour la lecture historique H, il retourne l’identité ERP figée qui lui a été transmise. Cette sortie ne démontre ni la recherche d’archive dans votre SI ni l’export d’une commande.

Ce que les cas et les contre-tests établissent

Les huit cas passent, avec huit gardes d’entrée. Celles-ci refusent notamment un identifiant boutique booléen, un produit nul, une déclinaison négative, des versions non qualifiées et une identité ERP vide. Elles contrôlent le contrat fictif du programme. Elles ne préjugent pas des formats natifs attendus par le Webservice ou par votre adaptateur ERP.

Cinq frontières complémentaires vérifient une autre boutique, une autre déclinaison, un mapping retiré, une lecture historique indépendante du SKU courant et une ancienne décision de réactivation. Toutes les entrées restent inchangées. Le contrôle est séquentiel et hors connexion : aucune transaction, concurrence de workers, session d’achat ni logique de retour n’est reproduite.

Cas concret fictif : le modèle comporte 2 SKU, M et L, associés aux déclinaisons 8 et 9. Si la décision ne vise que M, alors l’intention de modifier l’état du produit 80 est refusée avant toute préparation d’écriture : sa portée comprend aussi L. Le cas B exerce ce refus dans notre comparateur. Il ne démontre pas encore que la taille L reste achetable dans une boutique ; cette vérification appartient à la recette du mécanisme choisi.

Empêcher le prochain import de rouvrir une référence arrêtée

Faire porter la version sur la décision d’assortiment

Un événement de stock plus récent ne constitue pas nécessairement une décision commerciale plus récente. La version d’assortiment et la date d’observation logistique répondent à deux questions différentes. Si le worker choisit la dernière information reçue sans distinguer ces autorités, une livraison peut effacer le retrait décidé par le commerce.

Dans le scénario fictif G, la version commerciale 2 retire la taille M ; un ancien lot de version 1 arrive ensuite. Le comparateur refuse cette ancienne décision, même si le transport vient de la recevoir. Le contrat précise quelle source peut retirer, réouvrir ou corriger la correspondance. Si l’ERP ne fournit pas de version exploitable, le projet doit qualifier une autre règle d’ordre : l’heure d’arrivée ne suffit pas à départager ces décisions.

Retrouver une action incertaine avant toute nouvelle tentative

Une réponse perdue après envoi laisse le résultat incertain. La reprise conserve l’intention, la cible, le contexte et les observations attendues. Elle relit le mécanisme qualifié et la barrière commerciale avant de préparer une autre action. L’idempotence doit être éprouvée sur le stockage et les interfaces disponibles ; la présence d’une version dans notre dictionnaire ne prouve pas cette garantie dans votre SI.

Dans une queue de traitement, un timeout après transmission devient une action à rapprocher, plutôt qu’un retrait immédiatement renvoyé. Le retry attend la lecture du résultat précédent et garde la même cible commerciale ; un backoff espace les tentatives lorsque le service répond mal. Il ne corrige ni une mauvaise portée ni un résultat inconnu. La recette coupe volontairement la réponse sur un environnement de test, puis vérifie que la reprise ne reconstruit pas une demande portant sur tout le produit.

L’adaptateur ERP doit aussi préserver cette cible dans son payload, que l’interface qualifiée utilise REST, SOAP ou un échange de fichiers. Le format de transport ne devient pas l’autorité commerciale : société ERP, boutique, déclinaison et version restent des données séparées. Une conversion vers le contrat PrestaShop conserve ces identités et refuse une correspondance absente ; elle ne remplace pas la déclinaison inconnue par l’identifiant de son parent.

Le runbook distingue décision refusée, action inconnue et retrait observé. Ses responsabilités attribuent au commerce la réouverture, au référentiel la correspondance et à l’intégration les reprises de transmission. La journalisation rattache les entrées à leur contrat et aux dépendances du connecteur. Le seuil d’arrêt bloque une nouvelle action lorsque sa portée ou le résultat précédent ne peut plus être retrouvé.

Éviter qu’un arrêt local ferme une seconde boutique

Qualifier la boutique et les partages réellement configurés

La documentation multiboutique PrestaShop 9 décrit les paramètres de contexte boutique et groupe pour les requêtes. Les ressources peuvent aussi conserver leurs propres champs de périmètre. Un connecteur doit traduire ces dimensions selon l’installation, pas considérer que le même identifiant numérique représente partout une décision indépendante.

Un produit peut rester vendu sur un marché tandis qu’une taille s’arrête sur un autre. Le partage des stocks ou des données ajoute des dépendances à qualifier. La recette relève les boutiques, leurs associations et les décisions d’assortiment attendues. Un succès observé sur le compte administrateur global ne démontre pas le comportement du visiteur de chaque boutique.

Contrôler les projections, les prix et les canaux secondaires

Les modules de flux marketplace, les caches et les exports tarifaires peuvent conserver leur propre lecture de la référence. L’arrêt dans une interface ne prouve pas leur mise à jour. Le relevé doit indiquer quels consommateurs prennent l’identité et quel contrat transmet le retrait. Il évite de traiter l’apparition dans une recherche et l’acceptation d’une commande comme un seul résultat.

Le monitoring conserve la décision commerciale par cible, les consommateurs à rapprocher et l’âge des écarts. Son instrumentation relie contexte, version et dernière observation de la barrière d’achat. Le contrat de rollback précise ce qui peut revenir à une version précédente sans rouvrir une référence arrêtée depuis. Le support sait ainsi quelle dépendance reste à corriger avant l’extension.

Erreurs fréquentes : supprimer une identité pour arrêter une vente

Confondre disparition du catalogue et retrait commercial

Une référence absente d’un lot ne signifie pas forcément qu’elle doit être supprimée. Le fichier peut être partiel, son filtre incomplet ou son traitement interrompu. Un flux de retrait attend une intention explicite et une identité qualifiée. Transformer toute absence en fin de vie multiplie les incidents lors d’un changement de périmètre ou d’une erreur d’export.

La suppression physique éventuelle suit un autre chantier avec ses dépendances, sauvegardes et procédures de reprise. Ce pilote ne l’exécute pas et ne promet pas qu’une déclinaison supprimée laisserait tous les modules, retours et raccordements fonctionnels. L’objectif commercial est d’abord de maîtriser les nouvelles ventes tout en retrouvant les pièces existantes.

Réutiliser la référence de remplacement dans le passé

Résoudre un ancien SKU avec le catalogue courant peut importer la nouvelle taille, la nouvelle génération ou une autre société ERP. Le document résultant semble complet mais décrit une autre vente. La correction doit retrouver la correspondance applicable à la commande et classer les cas historiques manquants. Elle ne réécrit pas silencieusement les identités anciennes.

Une autre erreur consiste à retirer les règles de prix ou les composants d’un pack pour faire disparaître la taille de toutes les vues. Ces objets possèdent leurs propres usages et versions. L’équipe prépare une décision par dépendance, puis vérifie les effets. Une purge globale peut fermer l’écran rapidement tout en créant de nouveaux dossiers rejetés dans l’ERP.

Mesurer les commandes bloquées et les réouvertures non autorisées

Séparer contrôle des nouvelles ventes et résolution historique

Le suivi compare références retirées attendues, cibles dont la barrière est observée et dossiers historiques encore résolus. Il conserve le nombre de déclinaisons contrôlées avec chaque taux. Une boutique peut afficher zéro rejet de commande simplement parce qu’aucun ancien dossier n’a été rejoué ; ce compteur ne certifie pas le raccordement.

Mesurez également les réouvertures sans décision commerciale, les mappings manquants et les consommateurs en retard. Une fiche encore visible ne prouve pas une vente encore possible, et une option masquée ne prouve pas le refus d’achat. Le tableau de contrôle garde ces observations séparées et attribue une prochaine action à chaque écart confirmé.

Chiffrer la recherche de référence avec des dossiers réels

Sur 7 jours fictifs, onze commandes anciennes demandent chacune quatorze minutes pour retrouver taille, boutique et correspondance ERP : 154 minutes de recherche. Le responsable du raccordement choisit de traiter d’abord la cause commune, une correspondance retirée du registre, plutôt que de rouvrir onze fois la taille dans la boutique. Ce calcul illustre une charge de diagnostic ; il ne constitue ni un gain client mesuré ni un montant de chiffre d’affaires récupéré.

Le pilote relève le temps réellement passé, les causes retrouvées et les contrôles ajoutés pour conserver l’historique. Il distingue résolution d’un dossier et remise en vente décidée. La valeur du raccordement se juge sur ces gestes : fermer une nouvelle vente interdite, préserver la taille voisine et expliquer une commande ancienne sans recréer son identité.

Plan d’action : arrêter une taille et rejouer une commande ancienne

Choisir une famille et rendre ses autorités explicites

Le commerce choisit un modèle avec une taille à retirer et une autre toujours vendue. Le référentiel confirme les correspondances et les anciennes références. L’intégrateur ERP qualifie le statut source et les interfaces de lecture. L’équipe PrestaShop relève version, modules, boutiques et chemins d’achat. Ce dossier ferme les ambiguïtés avant toute modification de configuration.

Le livrable décrit décision de retrait, identités techniques, registre historique et critères de retour. Le contrat d’export distingue absence de référence, arrêt explicite et nouvelle version. Les tests incluent une commande encore à préparer et une commande déjà traitée dont le support doit retrouver la ligne. Une démonstration sur une fiche sans historique ne couvre pas ces frontières.

Éprouver le retrait et la reprise avant de généraliser

La recette tente une nouvelle vente de la taille retirée, confirme celle de la taille voisine et exerce un panier existant. Elle rejoue ensuite une ancienne ligne vers les interfaces ERP de test réellement disponibles. Le pilote ajoute retour de stock, lot commercial ancien, seconde boutique et modification du SKU courant. Les preuves comparent identités, décisions et résultats observés, pas seulement les codes HTTP.

Le seuil d’arrêt de cette famille est atteint dès qu’une taille voisine devient invendable, qu’une nouvelle vente de la taille retirée est acceptée ou qu’une ancienne ligne change d’identité. Le repli suspend le flux concerné et conserve ses intentions ; il n’efface pas le registre pour repartir de zéro. Commerce et intégration valident ensemble les reprises avant d’ouvrir une autre famille de catalogue.

• À qualifier : le statut ERP, la cible exacte et le mécanisme de contrôle des nouvelles ventes.
• À conserver : les correspondances datées et les identités des commandes déjà passées.
• À refuser : une désactivation du parent par défaut, une substitution historique et une réactivation par ancien lot.

Lectures complémentaires : maîtriser les autres portées PrestaShop

Conserver les effets des packs et les destinataires des remises

Le diagnostic des packs PrestaShop avec doubles déductions ERP suit la composition et le premier mouvement. Il devient utile si la déclinaison arrêtée appartient aussi à un coffret : une nouvelle décision d’assortiment ne doit pas reconstruire la composition d’une vente ancienne.

La qualification des remises individuelles ERP dans PrestaShop conserve client, boutique et déclinaison. Elle aide à traiter les règles futures sur une référence retirée sans élargir une condition commerciale aux tailles restantes. Le prix déjà commandé garde sa propre provenance.

Comparer les interfaces sans transporter les règles d’un autre moteur

La présentation des interfaces et flux d’intégration PrestaShop replace catalogue et commandes dans le raccordement au SI. Le retrait conserve toutefois son contrat propre : qualifier une seule déclinaison et résoudre les dossiers anciens avant de choisir une action native ou personnalisée.

Le diagnostic d’un stock Shopify positif avec un niveau d’inventaire inactif montre une autre frontière entre quantité et possibilité de vente. Il fournit un point de comparaison, sans attribuer à PrestaShop les niveaux d’activation Shopify ni supposer que leurs mutations sont interchangeables.

Conclusion : arrêter une nouvelle vente sans perdre la référence vendue

Le retrait d’une déclinaison concerne une cible commerciale précise. La fiche parent, les tailles voisines et les lignes anciennes restent des objets différents. Le mapping doit conserver cette distinction avant de traduire un statut ERP en action sur la boutique.

Une quantité nulle ne démontre pas la barrière d’achat, et une correspondance supprimée peut empêcher la résolution d’un dossier ancien. Le pilote conserve la décision de cycle de vie et les identités historiques, puis observe le comportement réel de la version PrestaShop installée. Les huit comparaisons locales préparent cette recette ; elles ne l’exécutent pas dans une boutique.

Les imports suivants doivent respecter l’autorité commerciale, tandis que les commandes anciennes retrouvent les références utilisées lors de leur vente. Une réouverture ou un remplacement devient une décision explicite. Le raccordement cesse alors de dépendre d’une correction manuelle du parent ou d’un SKU actuel utilisé à la place du passé.

Construire un raccordement qui distingue les deux circuits

Notre prestation d’intégration PrestaShop et ERP qualifie ces correspondances, le retrait commercial et les reprises avec vos équipes et l’intégrateur ERP. Une première famille de tailles permet de confronter les règles aux commandes et aux outils disponibles.

Dawap peut vous accompagner pour cadrer et construire votre intégration API sur mesure, du contrat de cycle de vie au contrôle des dossiers transmis. Le résultat attendu est une taille réellement arrêtée pour les nouvelles ventes, une taille voisine préservée et une commande ancienne dont l’identité reste explicable.