Import XML vers PrestaShop sans doublons : identifiants et règles de mise à jour

L’import XML sans doublons commence par un identifiant constant et univoque, ainsi qu’une relation enregistrée entre l’enregistrement du fournisseur et le produit dans PrestaShop. Avant le premier lancement, définissez ce que l’importateur peut créer, quels champs il met à jour et ce que signifie l’absence d’un produit dans le fichier suivant. Un XML simplement correct ne répond pas à ces questions.

Ce guide s’adresse aux boutiques qui prévoient un import depuis un grossiste ou un autre système. Deux petits fichiers de démonstration montrent comment distinguer un nouveau produit, une modification de données et l’absence d’un enregistrement. Il ne s’agit ni du flux d’un fournisseur réel ni d’un format universel pris en charge par chaque importateur.

1. Choisissez le système responsable de chaque champ

Décidez d’abord d’où proviennent le prix correct, le stock, le nom et la description. Souvent, le grossiste est responsable de la disponibilité et du prix d’achat, tandis que la boutique conserve sa propre description et un prix de vente calculé selon une règle. Si l’importateur écrase tous les champs à chaque mise à jour, il peut supprimer le travail éditorial réalisé dans la boutique.

Avec plusieurs fournisseurs, précisez également s’ils proposent le même produit ou des offres distinctes. La gestion de plusieurs sources ne signifie pas automatiquement l’addition des stocks, le choix du prix le plus bas ni le basculement d’un fournisseur à l’autre. Une telle règle doit être conçue, puis confirmée dans la solution concrète.

2. Ne confondez pas l’ID fournisseur avec l’ID produit dans la boutique

L’enregistrement A-100 dans le XML peut correspondre au produit 501 dans PrestaShop. Ces numéros ne doivent pas forcément être identiques. L’importateur doit connaître leur correspondance et l’utiliser lors de la lecture suivante. Créer une nouvelle fiche à chaque changement de nom est une erreur du modèle d’identification.

L’identifiant doit être stable dans le temps et univoque dans le périmètre choisi. Si deux grossistes utilisent le numéro 100, une liaison sûre doit tenir compte de la source, et pas uniquement de ce nombre. Ne supposez pas non plus que l’EAN est toujours disponible et unique : le fichier peut contenir des absences, des erreurs ou des doublons qui nécessitent une clarification.

Avant la première correspondance avec le catalogue existant, préparez un rapport des clés manquantes et répétées. Ne choisissez pas automatiquement le « premier produit trouvé » s’il existe deux fiches avec la même référence.

3. Le produit et la variante nécessitent des règles distinctes

Une même fiche produit peut avoir plusieurs combinaisons, chacune avec son propre stock, sa référence, son image ou son impact sur le prix. Déterminez si l’enregistrement XML décrit la fiche entière ou une variante individuelle. Si le fournisseur envoie des tailles distinctes comme des enregistrements séparés, leur regroupement dans une seule fiche nécessite une règle de groupement.

Vérifiez également la signification du prix de la variante : il peut s’agir du prix complet ou d’une différence par rapport au produit de base. Utiliser la différence comme prix final donne un résultat incorrect. La même prudence s’applique aux ensembles d’attributs — un changement de nom de couleur ne devrait pas créer une nouvelle variante sans décision préalable.

Si l’importateur synchronise l’ensemble complet des combinaisons, définissez si les variantes absentes du fichier doivent être conservées, désactivées ou supprimées. C’est particulièrement important lorsque la boutique gère elle-même une partie des variantes.

4. Deux versions XML et le résultat attendu

La structure ci-dessous a été préparée uniquement à des fins de démonstration. Les prix sont des prix d’entrée HT en PLN. Dans l’exemple, nous ne créons pas de variantes ; chaque enregistrement correspond à une fiche produit. Le parseur ou l’adaptateur de l’importateur concret doit être adapté à la structure réelle de la source.

Premier fichier complet

  
    DEMO-BUTELKA
    Butelka oliwkowa
    50.00
    12
  
  
    DEMO-KUBEK
    Kubek kremowy
    20.00
    8
  

Fichier complet suivant

  
    DEMO-BUTELKA
    Butelka oliwkowa
    55.00
    0
  
  
    DEMO-KOC
    Koc beżowy
    40.00
    5
  

L’attribut complete="true" fait partie de notre exemple, et non d’une garantie standard de complétude du XML. Dans un déploiement réel, il faut définir comment le fournisseur confirme la complétude et comment l’importateur la reconnaît.

Ce sont les résultats attendus du scénario, et non le résultat d’un import exécuté. Les numéros de produits dans la boutique sont donnés à titre d’exemple. Les deux fichiers ci-dessus ont un schéma illustratif ; ce ne sont pas des fichiers d’entrée de l’adaptateur d’exemple du module.

Le retraitement du même fichier correct ne devrait pas créer une nouvelle bouteille ni un nouveau plaid. La comparaison après le deuxième lancement est un critère simple de validation de la correspondance. Pour un importateur qui ignore les enregistrements inchangés, leur omission peut également être un résultat correct.

Essai séparé de mappage dans le code du module 2.0.5

Le 27 septembre, nous avons vérifié en mémoire la méthode SampleAdapter::mapProduct() sur trois petits fichiers XML, en PHP 7.0 et 8.1. Cet adaptateur attend la structure ainsi que les champs nazwa, cena_netto et stan_magazynowy. Cela diffère du schéma illustratif ci-dessus. Nous n’avons pas effectué de récupération d’URL ni d’import dans la base de la boutique.

Téléchargez les données et les résultats enregistrés de l’essai de mappage (ZIP, 4,4 kB) : trois fichiers XML, les résultats PHP 7.0 et 8.1 ainsi qu’une instruction de comparaison. Il s’agit des matériaux de l’essai décrit du 27.09.2026, mis à disposition le 28.09.2026. L’archive ne contient ni le module ni la configuration pour un import complet. Le résultat 19,99 → 19 documente une erreur de format de prix, et non un prix correct.

Limite de l’essai : il s’agit du résultat du mappage des champs, et non d’une preuve de création ou de mise à jour des fiches, de gestion des variantes ou d’absence de doublons après un nouvel import. SampleAdapter est exclu de la sélection dans le panneau et lui-même indiqué comme exemple inadapté à la production. Ne lancez pas un import complet d’un court échantillon sur une source existante : la règle pour les produits absents du fichier peut modifier l’état du catalogue. La validation complète exige une copie isolée de la boutique, la confirmation de la complétude du flux et la comparaison des fiches avant et après l’exécution.

5. L’absence d’un enregistrement ne signifie pas toujours l’absence du produit

Un produit peut disparaître d’un catalogue complet, mais il peut aussi ne pas apparaître dans un fichier contenant uniquement les modifications. Un fichier vide, une erreur de connexion, un téléchargement partiel ou un import inachevé sont encore d’autres situations. Elles ne devraient pas conduire automatiquement à la désactivation de tout l’assortiment.

Avant d’exécuter une opération pour les produits manquants, confirmez le bon téléchargement, la bonne lecture et l’achèvement du type d’import approprié. Définissez également le périmètre : uniquement les fiches liées à cette source. La disparition d’un enregistrement du grossiste A ne devrait pas modifier automatiquement un produit ajouté manuellement ou une offre du grossiste B.

Dans l’exemple, nous laissons le mug manquant en contrôle afin de montrer la différence entre une absence d’information et un stock explicitement à zéro. Il s’agit d’une règle de démonstration choisie, et non d’un paramétrage adapté à chaque boutique. Pour la production, la décision doit être liée à la nature de la source et au risque de vendre un produit indisponible.

6. Import complet et mise à jour rapide

Dans le code de Import grossiste Pro / pdxmlimport 2.0.4, l’import complet et la mise à jour rapide ont des portées différentes. Le chemin complet peut créer des produits et mettre à jour les données prises en charge par l’adaptateur conformément à la configuration. La mise à jour rapide concerne les prix et les quantités des produits de base déjà liés à la source ; ce n’est pas un chemin de création de nouvelles fiches ni de mise à jour des stocks des combinaisons individuelles.

Ne supposez pas que les commutateurs d’écrasement des noms et descriptions contrôlent chaque opération du module. Avant la planification, indiquez précisément l’action, la source et la portée. Une modification de la règle de prix peut également nécessiter un nouveau traitement des données malgré un XML inchangé.

Si vous avez besoin uniquement d’une mise à jour des fiches existantes à partir d’un CSV, consultez les guides séparés sur les prix et sur les stocks. Le choix du format doit découler des données et des opérations qu’il faut réellement exécuter.

7. Planification seulement après contrôle du résultat

Effectuez le premier essai sur un petit ensemble représentatif comprenant un nouveau produit, un produit déjà lié, une absence d’identifiant, une collision et des variantes. Comparez le nombre d’enregistrements ajoutés, modifiés, ignorés et erronés. Ouvrez les fiches produits et vérifiez le prix de vente, le stock, les images et le mappage des catégories.

Ce n’est qu’ensuite que vous définirez l’ordre de téléchargement et de traitement des lots ainsi que la fréquence du CRON. La planification doit tenir compte de la publication du fichier par le fournisseur et du temps réel d’import. Définissez qui réagit en cas d’erreur et comment reconnaître une exécution inachevée. Le simple lancement de l’adresse CRON n’est pas une preuve de mise à jour de l’ensemble du catalogue.

Envoyez un échantillon de la structure XML sans données confidentielles et décrivez les règles de mise à jour. Après vérification des champs et des variantes, il est possible de définir le périmètre de l’import et de l’export de données PrestaShop. Si l’adaptateur existant prend en charge cette structure, consultez Import grossiste Pro ; une autre disposition des données nécessite une adaptation et un essai sur une copie de la boutique.

L’import du catalogue ne signifie pas automatiquement l’envoi des commandes au grossiste, la réservation du stock ni une synchronisation bidirectionnelle. Ces besoins doivent être inclus séparément dans le périmètre de l’intégration.

Vérification du texte d’origine : 13 septembre 2026 dans le code pdxmlimport 2.0.4. Essai séparé de mappage : 27 septembre 2026 dans le code local 2.0.5 sur PHP 7.0 et 8.1, sans import dans la boutique. Les fichiers XML et les numéros de produits sont démonstratifs ; ils ne contiennent ni données ni structure d’un flux grossiste protégé.