Importer et synchroniser les produits PrestaShop en sécurité

Ce que nous ferions

Le parcours dépend de votre catalogue existant et de la qualité de ses données, des flux fournisseurs, des modules installés, des intégrations et des exigences du thème, ainsi que des champs que le personnel tient à jour à la main. Pour un chargement ponctuel depuis un tableur, nous testerions d’abord l’importateur CSV natif sur une copie de préproduction avec le format d’exemple de cette boutique. Pour des mises à jour fournisseur répétées, évaluez un module de synchronisation de flux éprouvé avant de commander un script API. Pour les exports, partez des champs exigés par le système destinataire. Pour une connexion ERP bidirectionnelle, définissez les responsabilités, les conflits et la reprise avant de choisir une interface.

Si le processus nécessite une intégration spécifique, notre PrestaShop Custom Module Development Service commence par un cahier des charges écrit couvrant les règles métier, les connexions, les exclusions et les critères de recette, suivi d’un devis fixe ; les frais de tiers et les changements d’infrastructure sont distincts.

Choisir un CSV, une API ou un flux récurrent

Utilisez Paramètres avancés > Importer pour un CSV préparé et un chargement ponctuel ou occasionnel. Utilisez un processus d'intégration pour une synchronisation récurrente avec un fournisseur ou un ERP, des reprises fiables ou des transformations qu'un tableur ne permet pas de maintenir. Un PIM peut gérer des données de catalogue plus riches, mais nécessite toujours une correspondance testée vers PrestaShop.

L’importateur CSV natif ne lit pas n’importe quel flux XML fournisseur. Convertissez ce flux au format CSV de l’entité choisie, utilisez un connecteur qui prend explicitement en charge sa structure, ou développez une intégration avec une API disponible. Les variantes imbriquées, les valeurs d’image répétées et les champs de langue exigent une correspondance réfléchie ; changer l’extension du fichier ne convertit pas les données. Un module d’export ou de flux planifié peut produire des fichiers récurrents pour les places de marché ; un export manuel de la grille du catalogue n’est pas une sauvegarde complète.

Choisissez entre ces approches à partir d’un essai représentatif et de vos besoins d’exploitation. La taille du catalogue ne détermine pas à elle seule la méthode. Les téléchargements d’images, les déclinaisons, les hooks, les limites du serveur et la qualité des données influent sur la capacité. Commencez par un échantillon représentatif contenant des accents, plusieurs catégories, des variantes et des images. Choisissez la taille des lots d’après des temps d’exécution mesurés.

Lorsque l’import fait partie d’un passage vers une nouvelle boutique, le parcours habituel est une boutique cible propre en préproduction, alimentée par une migration des données répétée, puis une bascule planifiée. Pour le traitement des comptes, des commandes et des URL propre à une migration, consultez le guide de migration de plateforme.

Convenir des responsabilités sur les champs avant l’import

Notez quel système est responsable de chaque champ : le fournisseur, votre ERP ou PIM, ou le personnel dans le back-office. Une exécution ne doit modifier que les champs dont elle est responsable. Les descriptions rédigées par le personnel, vos propres photos et un prix de vente validé restent protégés, sauf si la règle convenue en dispose autrement.

Le tableau suivant illustre une spécification de correspondance ; ce n’est ni un CSV importable ni la promesse qu’un outil précis propose ces noms de champs :

Notez à côté les règles de création, de mise à jour et d’enregistrement absent, séparément pour les produits parents, les déclinaisons et chaque boutique. Convenez si une cellule vide signifie laisser inchangé, effacer la valeur ou rejeter la ligne. Résolvez les références en double, les identifiants vides, les parents inconnus et les catégories manquantes avant d’appliquer un lot.

Pour une connexion bidirectionnelle, convenez aussi de l’interaction entre une vente ultérieure dans la boutique et une mise à jour de stock plus ancienne venant de l’ERP. Demandez au développeur de démontrer l’ordonnancement, la résolution des conflits et la reprise, plutôt que de laisser la dernière écriture arrivée devenir la règle par accident.

Préparer le CSV et associer les champs

1. Conservez une copie intacte du fichier source et effectuez chaque correction sur une copie.
2. Téléchargez le fichier d'exemple de l'entité sélectionnée dans votre écran d'import. Les champs disponibles varient selon l'entité et la version.
3. Enregistrez en UTF-8. L'importateur natif de PrestaShop 1.7.8 et 9.1 ignore automatiquement la marque d'ordre des octets UTF-8. Supprimer un BOM n'est pas une correction nécessaire pour cet importateur.
4. Réglez le séparateur de champs et celui des valeurs multiples selon le fichier. Le séparateur de champs par défaut est le point-virgule. Entourez de guillemets les champs contenant le séparateur, des guillemets ou des sauts de ligne, selon les règles d'échappement CSV.
5. Associez explicitement les colonnes, ignorez la ligne d'en-tête et enregistrez une correspondance nommée si vous comptez la réutiliser. Vérifiez la langue, le contexte boutique et toutes les options destructives avant de commencer.
6. Importez un petit échantillon et examinez les produits obtenus. Vérifiez la correspondance des taxes, identifiants et stocks sur les produits importés, ainsi que la syntaxe CSV.

Active;Name;Reference;Price tax excluded;Tax rule ID;Quantity
1;Blue widget;WIDGET-BLUE;100.00;1;12

Cet en-tête est un exemple, pas un contrat de correspondance automatique. Associez chaque colonne dans votre installation. Lorsque vous chargez la source dans un tableur, définissez les références, GTIN et codes postaux au format texte avant que la conversion automatique ne puisse supprimer les zéros initiaux ou altérer les identifiants longs. Comparez le fichier enregistré à l’original pour confirmer que les zéros initiaux et les références longues ont été conservés. L’encodage d’Excel dépend du format d’export choisi et de la plateforme ; examinez le fichier obtenu, par exemple avec un nom de produit accentué, plutôt que de vous fier au libellé de l’export. Examinez la ligne en échec avant de modifier les fins de ligne CRLF.

Les guillemets comptent dès qu’une valeur contient le séparateur. Cet extrait de fichier fournisseur illustre uniquement l’usage des guillemets ; ce n’est pas un modèle d’import natif :

supplier_sku;description
MUG-BLUE;"Blue mug; gift range"

Le point-virgule à l’intérieur de la description doit rester une partie de cette valeur. Ouvrez le fichier avec les paramètres d’analyse prévus et vérifiez que chaque ligne comporte le nombre de colonnes attendu avant d’établir la correspondance.

Importez les catégories avant de leur affecter des produits. Conservez une correspondance explicite des catégories. Vérifiez si le champ choisi accepte un ID ou un nom et si un nom inconnu crée une catégorie. Ne considérez pas des colonnes d'entités quelconques comme des identifiants interchangeables.

Mettre à jour les produits existants et importer les déclinaisons

Déterminez si un enregistrement met à jour un produit existant ou en crée un. Dans PrestaShop 1.7.8 et 9.1, la correspondance par référence produit nécessite l'option correspondante. Pour utiliser la colonne d'ID produit, activez « Forcer tous les identifiants » : sinon, l'importateur de produits écarte cet ID avant la recherche de correspondance. Avec cette option, un ID inexistant peut créer un produit portant cet ID. Vérifiez chaque ID cible et chaque référence avant l'import, et rejetez les références ambiguës.

Importez d'abord les produits parents, puis effectuez un passage distinct pour les Déclinaisons. Pour le parent, fournissez l'ID produit cible, ou activez la correspondance par référence et fournissez sa référence produit. Le SKU ou la référence propre d'une déclinaison diffère de la référence de son parent.

1. Associez les axes de variante comme Taille et Couleur à des groupes d’attributs et à des valeurs. Vérifiez l’orthographe des noms et valeurs d’attributs avant de créer les déclinaisons.
2. Associez les spécifications descriptives qui ne sélectionnent pas de variante aux caractéristiques.
3. Définissez la référence, la référence fournisseur, les identifiants, le stock et les impacts sur le prix et le poids de chaque déclinaison selon les besoins.
4. Utilisez l'indicateur de déclinaison par défaut de l'import pour désigner la déclinaison à sélectionner par défaut.
5. Vérifiez la valeur sélectionnable, le prix final, l'image et la quantité de chaque variante importée.

Par exemple, si le prix hors taxes du parent est de 100 EUR et qu’une variante doit se vendre 120 EUR hors taxes, son impact sur le prix est de 20 EUR. N’importez pas les 120 EUR entiers comme impact. Testez un second import pour confirmer qu’il met à jour les enregistrements voulus au lieu de les dupliquer. Prouvez la règle de correspondance avec un produit existant et une variante existante, puis relancez le même échantillon et vérifiez les descriptions, images et prix protégés ainsi que le nombre de doublons.

Associer taxes, prix et stocks dans le bon périmètre

L'importateur natif propose des champs distincts Prix HT et Prix TTC. Utilisez celui correspondant à votre source. Lors de l'import de prix TTC, confirmez le taux de taxe utilisé pour calculer le prix de base enregistré. Affectez le bon groupe de règles de taxes et vérifiez les totaux du panier selon la destination. Associer un prix TTC de 120 EUR à un prix HT de 120 EUR ne devient pas correct simplement parce que vous sélectionnez un groupe de taxes.

Séparez le coût d'achat fournisseur, le prix de vente, la conversion monétaire, les remises et le traitement fiscal. Vérifiez les prix de vente effectifs après application des déclinaisons, prix spécifiques et remises catalogue, sans vous fier uniquement à la colonne du prix de base.

Si la tâche se limite à un ajustement de prix en masse, Mass Price Updater propose des ajustements en pourcentage ou en montant fixe des prix de vente ou d’achat, un aperçu obligatoire et l’enregistrement des valeurs précédentes pour une restauration vérifiée, sans export ni réimport. C’est une tâche différente de la synchronisation d’un catalogue fournisseur.

Le stock relève de stock_available. Utilisez les services de stock de PrestaShop, StockAvailable ou la ressource API prise en charge au lieu de modifier directement l'ancien champ de quantité du produit. Les opérations de stock correctes déclenchent également les hooks concernés.

Limitez les prix à l'enregistrement product_shop prévu. Limitez le stock à la boutique ou au groupe de boutiques partageant le stock. Les quantités des déclinaisons nécessitent leurs propres identifiants d'attribut produit ; une ligne au niveau du produit n'est pas un stock supplémentaire à ajouter à toutes les lignes de déclinaisons.

Le paramètre out_of_stock permet de refuser, d'autoriser ou d'hériter. Le comportement hérité lit PS_ORDER_OUT_OF_STOCK dans le contexte de configuration applicable. Une quantité nulle peut rester achetable si les commandes hors stock sont autorisées.

Gérer les images et les imports volumineux

L'importateur natif traite des lots avec décalage et limite. Il ne récupère pas nécessairement toutes les images dans une seule requête longue. Une image distante lente ou inaccessible peut néanmoins épuiser les limites d'un lot.

1. Importez d'abord les données principales des produits, sans les images, et validez-les.
2. Si l’importateur choisi prend en charge un passage distinct de mise à jour des images, répétez-le avec les champs requis et une règle de correspondance éprouvée avant de l’appliquer. Vérifiez l’accès distant, les certificats, les redirections, la taille des images et l’espace disque du serveur. Répétez ce passage sans suppression et vérifiez qu’une nouvelle exécution n’ajoute pas de copies indésirables.
3. Utilisez l'option permettant d'ignorer la régénération des miniatures si cela convient, puis générez les miniatures nécessaires après le chargement. Conservez les formats d'image requis par votre thème.
4. Utilisez « Supprimer les images existantes » uniquement pour un remplacement planifié : cette option peut supprimer les images ajoutées manuellement aux produits correspondants.
5. Mesurez ce qui prend le plus de temps : téléchargements, redimensionnement, écritures en base de données, hooks ou indexation. Si vous suspendez l'indexation automatique de la recherche pendant un chargement contrôlé, reconstruisez ensuite les index concernés de recherche et de navigation à facettes.

Examinez upload_max_filesize, post_max_size, memory_limit, max_execution_time et max_input_time. Pour les envois multipart, vérifiez aussi les limites applicables au nombre de fichiers envoyés. Les limites d'arrêt PHP-FPM, les délais de lecture du serveur web ou du proxy et les limites de requête du CDN constituent des contraintes distinctes. Augmenter une valeur PHP ne les remplace pas toutes.

Un processus CLI ou cron retire la requête du navigateur du traitement, mais conserve des limites de mémoire, d'exécution et d'exploitation. Ne supposez pas qu'une commande native prestashop:import existe. Vérifiez les commandes disponibles dans votre installation ou utilisez un importateur maintenu avec un processus de traitement identifié.

Répéter une simulation et un retour arrière sélectif

Répétez les imports courants sur une copie de préproduction isolée de la boutique en production. Pour une migration, répétez-les sur la boutique cible propre décrite ci-dessus. Un import réussi n’établit pas que les modifications sont correctes pour votre activité : examinez les pages produit, les déclinaisons et les totaux du panier.

1. Préparer la restauration. Sauvegardez la base de données, les fichiers et les images, vérifiez que la restauration est possible et travaillez en préproduction. Isolez la copie des paiements réels, des messages clients, des fournisseurs et des systèmes d’expédition.
2. Constituer un échantillon représentatif. Au-delà des accents, des catégories multiples, des variantes et des images, incluez un article existant, un nouvel article, des identifiants manquants, un prix suspect et une image en échec, ainsi que les cas de langue et de boutique concernés.
3. Examiner les modifications proposées. Utilisez l’aperçu d’un outil lorsqu’il existe. Sinon, comparez la préproduction avant et après ; ne présentez pas un import en production non vérifié comme une simulation. Comptez les créations, mises à jour, exclusions et échecs.
4. Vérifier la boutique. Examinez les vraies pages produit, déclinaisons, disponibilités, images et totaux du panier, en parallèle du journal d’import. Vérifiez que les champs protégés restent inchangés et qu’une nouvelle exécution est sans risque.
5. Prouver le retour arrière. Répétez le retour arrière documenté de l’outil ou une restauration ciblée. Tenez compte des modifications ultérieures du personnel et des commandes, afin que la restauration n’écrase pas des données commerciales plus récentes.
6. Lancer un lot mesuré. Choisissez sa taille d’après le temps d’exécution mesuré en préproduction. Rapprochez les nombres, les échecs et les valeurs modifiées avant de continuer, et suspendez la planification si les résultats s’écartent des règles convenues.

Une restauration complète de la base d’une boutique en activité peut effacer des commandes et des paiements plus récents. Convenez de la façon de les préserver avant toute opération destructive ; les valeurs de flux conservées ne remplacent pas non plus une sauvegarde restaurable de la boutique. Ne supprimez pas de produits, n’élaguez pas de formats d’image et n’augmentez pas les limites du serveur en première réponse à un import échoué.

Ce que l’agence doit remettre

• Une correspondance précisant les responsabilités sur les champs et l’identification, avec les produits, variantes, boutiques et langues.
• L’importateur ou les opérations API testés, les formats source et les permissions, en excluant les identifiants des journaux d’exécution courants.
• Des preuves pour les cas de doublon, de cellule vide, d’enregistrement absent, de prix suspect, de ligne rejetée et d’exécution interrompue, ainsi que les conditions d’arrêt convenues et ce qui se passe lorsque deux exécutions se chevauchent.
• Le responsable de la planification, le canal d’alerte des échecs, la procédure de reprise et les étapes de restauration répétées protégeant les commandes et modifications ultérieures.

Si la responsabilité du stock est le problème plus large, consultez le guide de gestion des stocks. L’intégration doit suivre le processus d’exploitation convenu.

Diagnostiquer un import échoué ou partiellement terminé

1. Conservez le fichier en échec, la correspondance, les options, l’heure et les derniers enregistrements confirmés. Suspendez les exécutions planifiées ou simultanées susceptibles d’écrire dans les mêmes enregistrements. Réalisez une sauvegarde avant la réparation.
2. Examinez les journaux d'erreur de l'application, de PHP-FPM et du serveur web. Utilisez les chemins réellement configurés pour votre installation ; var/logs/ est un emplacement courant pour l'application.
3. Si la même ligne échoue, isolez-la et examinez les valeurs obligatoires, séparateurs, guillemets, encodage, références de catégories et URL d'images.
4. Si l'échec dépend de la durée ou de la taille des lots, mesurez la requête en échec et comparez toutes les limites de délai et de mémoire.
5. Examinez la base de données et la boutique pour identifier les enregistrements validés. Une page blanche ou un lot échoué ne signifie pas qu'aucune ligne n'a été enregistrée.
6. Reprenez avec des références stables ou des ID associés. Résolvez les enregistrements ambigus avant de réessayer. N'activez pas la suppression du catalogue pour contourner un import incomplet.
7. Corrigez les images, indicateurs d'activation ou associations incomplets, puis reconstruisez les index applicables après le dernier lot.

Exporter la bonne boutique, la bonne langue et le bon stock

Un export SQL utile doit inclure le périmètre de boutique et de langue. L'exemple suivant, en lecture seule, exporte les quantités agrégées des produits pour la boutique 1 et la langue 1 lorsque cette boutique possède son propre stock. Remplacez le préfixe des tables et les ID selon votre installation.

SELECT p.id_product, pl.name, p.reference,
       ps.price AS price_tax_excluded, sa.quantity
FROM ps_product p
JOIN ps_product_shop ps
  ON ps.id_product = p.id_product AND ps.id_shop = 1
JOIN ps_product_lang pl
  ON pl.id_product = p.id_product
 AND pl.id_shop = 1 AND pl.id_lang = 1
LEFT JOIN ps_stock_available sa
  ON sa.id_product = p.id_product
 AND sa.id_product_attribute = 0
 AND sa.id_shop = 1 AND sa.id_shop_group = 0;

Pour un stock partagé, sélectionnez la ligne du groupe partageant réellement le stock, généralement id_shop = 0 et le id_shop_group concerné. N'ajoutez pas un OR trop large qui joint les deux périmètres. Pour le stock par variante, exportez séparément les enregistrements des déclinaisons et leurs références. Vérifiez le lien entre les quantités agrégées et ces enregistrements.

La requête renvoie le prix de base enregistré, qui n’est pas forcément ce que paie un client après taxes, impacts de déclinaison et prix spécifiques. Si le Gestionnaire SQL est utilisé pour une telle extraction en lecture seule, faites vérifier par un développeur les jointures ainsi que le périmètre de boutique, de langue et de déclinaison.

Utilisez un export de flux récurrent lorsque la destination a besoin de prix et de disponibilités à jour selon un calendrier. Il nécessite un générateur en plus d’une planification, des contrôles de livraison et un responsable des échecs ; consultez le guide des flux produits pour les exigences des destinations. Les exports de commandes et de factures sont des jeux de données distincts (voir exports de commandes et de factures). Ni une liste de produits ni cette requête ne fournissent une sauvegarde restaurable de la base de données.

Rédiger le contrat d’export avant de construire l’export

Ne supposez pas qu’un export de la liste des produits contient les déclinaisons, les images, les contenus traduits ou les prix dont la destination a besoin. Décidez si chaque ligne représente un produit parent ou une déclinaison vendable, et identifiez sa boutique et sa langue. Précisez le prix dont le destinataire a besoin, y compris la devise, la base de taxes et tout contexte de groupe de clients. Incluez les exigences de disponibilité, d’image et de destination dans un échantillon accepté par le système destinataire, et comparez chaque export d’échantillon à cette liste de champs écrite. Pour un flux planifié, vérifiez la fraîcheur et le contenu du fichier livré, et pas seulement qu’une tâche signale une réussite.

Utiliser correctement les requêtes XML et les réponses JSON

Le Webservice historique et l'Admin API de PrestaShop 9 sont des interfaces différentes. Le Webservice historique de PrestaShop 1.7.8 et 9.1 accepte les écritures d'entités en XML et peut renvoyer du JSON avec output_format=JSON. La nouvelle API n'est pas nécessaire simplement pour recevoir une réponse JSON.

GET /api/products?display=full&output_format=JSON
GET /api/products?schema=blank

Activez le service historique sous Paramètres avancés > Webservice et n’accordez que les permissions de ressources nécessaires. Protégez les clés et utilisez HTTPS. Tenez les clés à l’écart des fichiers partagés avec les fournisseurs. Examinez le schéma de la ressource cible avant de construire les requêtes, et confirmez la version exacte, les extensions installées, les permissions et le format d’écriture accepté pour chaque ressource dont vous avez besoin. Une sortie JSON ne prouve pas que les écritures JSON sont acceptées, et une autre API peut ne pas exposer toutes les ressources nécessaires.

Les implémentations de requêtes de PrestaShop 1.7.8 et 9.1 parcourent plusieurs entités XML dans une requête d'écriture. Cela ne garantit pas une transaction atomique en masse. Les premières entités peuvent être enregistrées avant l'échec d'une validation ou association ultérieure. Testez le comportement multi-entités pour votre version et votre ressource exactes.

Journalisez un ID d'exécution, la clé source, l'ID cible, l'opération et une réponse expurgée des données sensibles. En cas de dépassement de délai ou d'erreur ambiguë, récupérez l'état cible avant de répéter une création. Réessayez les échecs temporaires avec un délai progressif limité. Corrigez les erreurs d'authentification, d'autorisation, de schéma et de validation avant de réessayer. Ne supposez pas que chaque erreur HTTP 500 peut être répétée sans risque.

Utilisez le point d’accès pris en charge d’envoi d’images produit pour les images binaires. Planifiez les produits, déclinaisons, associations et stocks comme des opérations liées avec des points de contrôle, et testez séparément les opérations sur les produits, les déclinaisons, le stock et les images sur la boutique installée. Mesurez le débit et respectez les limites de l’hébergement ou du WAF ; un délai fixe entre les requêtes ne prédit pas la durée totale de l’exécution.

Contrôler les mises à jour fournisseur et les planifier sans risque

Smart Wholesaler Feed Sync commence par une source, un test de connexion et la correspondance de colonnes d’exemple. Sa fiche produit mentionne des champs gérés, des priorités entre fournisseurs, des règles de prix et la protection des valeurs manuelles ou figées. Un examen avant/après, des limites d’actions et la mise en quarantaine des prix suspects encadrent les mises à jour ; chaque flux a sa propre planification, et les exécutions appliquées conservent les valeurs précédentes pour un retour arrière.

Vérifiez que votre format source, votre authentification et vos champs obligatoires sont pris en charge avant de le choisir. Décidez de ce qui se passe lorsqu’un fichier est en retard, vide ou incomplet, lorsque plusieurs fournisseurs correspondent au même article et lorsqu’un prix est rejeté. Sa description indique que les mises à jour sûres du stock et du contenu peuvent continuer pendant qu’un prix fournisseur suspect reste inchangé. Les valeurs précédentes conservées permettent un retour arrière sélectif des modifications de cet outil ; elles ne constituent pas une sauvegarde restaurable de la boutique et ne règlent pas à elles seules les conflits avec des modifications ultérieures du personnel.

Un prix fournisseur change, mais votre description doit rester intacte

Vous avez réécrit la description de MUG-BLUE et pris vos propres photos. Un fichier fournisseur contient un nouveau prix d’achat, des informations de stock et une ancienne description. L’exécution convenue gère le prix d’achat fournisseur et sa contribution définie au stock ; votre contenu modifié reste protégé. Le prix de vente ne change que par la règle de prix approuvée.

Le fournisseur envoie maintenant un prix suspect. Examinez le montant rejeté et le motif tout en vérifiant que les mises à jour autorisées ont suivi la politique convenue. Si le fichier est tronqué, suspendez-le pour examen plutôt que d’appliquer l’absence comme une modification de stock sur tout le catalogue. Conservez le fichier source et le journal d’exécution pour que le personnel puisse expliquer quelles valeurs ont changé et pourquoi.

Cron Manager peut planifier des tâches de fond et afficher les résultats et les échecs. C’est un outil de planification : il ne fournit pas la correspondance de l’import et ne transforme pas un flux non pris en charge en connecteur. Vérifiez que l’importateur choisi expose une tâche compatible, et n’ajoutez pas un autre planificateur lorsque l’outil de flux planifie déjà le traitement.

Bloquer les données fournisseur incorrectes avant publication

Documentez les règles d'identification du fournisseur. Un ID fournisseur peut être stable ou réutilisé. Un GTIN, MPN ou une référence marchand peut manquer, être dupliqué ou être affecté à un autre niveau. Recherchez les correspondances dans le périmètre prévu du fournisseur, du fabricant, du produit ou de la déclinaison et de la boutique. Rejetez les correspondances ambiguës.

Validez indépendamment les longueurs requises des GTIN et leurs chiffres de contrôle. Dans le modèle produit de PrestaShop 1.7.8 et le modèle de déclinaison de 9.1, ean13 utilise isEan13(), qui accepte jusqu'à 13 chiffres. Le modèle produit de PrestaShop 9.1 utilise à la place isGtin(), dont le motif accepte jusqu'à 14 chiffres. Aucun de ces motifs ne vérifie à lui seul l'ensemble des longueurs GTIN requises ni le chiffre de contrôle. Les champs MPN ne sont pas disponibles dans toutes les anciennes versions, notamment dans la version standard 1.6.1.24.

1. Placez le fichier téléchargé dans une zone de préparation. Vérifiez la fin du transfert, la somme de contrôle attendue lorsqu'elle est fournie, l'horodatage source et les résultats d'analyse.
2. Enregistrez le début et la fin de l'exécution, le fournisseur, le nombre de lignes, le nombre de lignes précédent, la somme de contrôle, le statut et le motif de rejet.
3. Rejetez les changements invraisemblables ou un fichier tronqué avant d'appliquer des suppressions. Une ligne absente ne signifie un arrêt de commercialisation que si les règles de la source le prévoient.
4. Appliquez des prix planchers et des garde-fous sur les variations de quantité avant publication. Signalez les changements rejetés au lieu de substituer silencieusement une valeur supposée.
5. Enregistrez les valeurs avant et après, ainsi que les ID cibles. Validez avant de transmettre les changements aux places de marché.
6. Séparez le stock de produits abandonnés par le fournisseur du stock local réel. Vendez le stock restant uniquement selon votre politique de disponibilité prévue.

Distinguer une information absente d’une instruction d’effacement

Un fournisseur omet un mug dans le fichier du jour. Cela peut signifier un article arrêté, un téléchargement incomplet ou un fichier ne contenant que les changements. Convenez de la signification de chaque situation de la source avant qu’une exécution ne la traite comme une instruction de stock ou de visibilité.

Ce sont des règles de fonctionnement à spécifier et à tester, pas l’affirmation que tout importateur fournit ces contrôles.

Un stock fictif peut entraîner des surventes ; une mauvaise correspondance peut publier le prix d'un autre produit. Les conséquences sur les places de marché dépendent du canal et de l'opération effectuée. Réapprovisionner, modifier ou remplacer une offre ne réinitialise pas systématiquement son historique.

Examiner les identifiants en double et les prix inférieurs au coût d'achat

Ces requêtes identifient des cas à examiner. Elles ne prouvent pas une erreur. Remplacez ps_ par le préfixe de votre base de données.

SELECT ean13, COUNT(*) AS records_found
FROM ps_product
WHERE ean13 <> ''
GROUP BY ean13
HAVING COUNT(*) > 1;

SELECT p.id_product, p.reference, ps.id_shop,
       ps.price, ps.wholesale_price
FROM ps_product p
JOIN ps_product_shop ps ON ps.id_product = p.id_product
WHERE ps.id_shop = 1 AND ps.active = 1
  AND ps.wholesale_price > 0
  AND ps.price < ps.wholesale_price;

Répétez les audits d'identifiants pour les déclinaisons et les autres champs uniquement là où ces champs existent. Examinez le périmètre des boutiques et fournisseurs avant de déclarer les doublons anormaux. Un produit vendu sous son coût de base enregistré peut refléter des coûts obsolètes, une liquidation volontaire ou une correspondance incorrecte. Vérifiez la comparabilité des taxes et devises, les impacts des déclinaisons et les remises effectives avant de décider quoi modifier.

Conservez une trace des écritures de stock permettant d'en attribuer l'origine, ainsi qu'un instantané récupérable. Si un flux incorrect atteint les clients, suspendez sa propagation, identifiez les annonces et commandes concernées, puis évaluez les obligations contractuelles et de protection des consommateurs réelles. Aucune règle financière universelle n'affirme qu'annuler toutes les commandes ou les honorer toutes est toujours moins cher.