Synchronisation de WooCommerce avec 1C : gestion du commerce en temps réel

Il y a environ trois mois, une connaissance m'a appelé - il gère une boutique en ligne de produits chimiques industriels, environ quatre mille références, deux gérants, un entrepôt dans la région de Moscou. La voix est fatiguée, en fond sonore on entend quelqu'un jurer dans l'entrepôt. "Écoutez", dit-il, "j'ai besoin d'aide. Nous avons encore vendu ce qui était en rupture de stock. Le client a payé, la commande a été traitée et l'étagère était vide. C'est la troisième fois en une semaine. Le responsable dit que dans 1C, les soldes ont été mis à jour hier soir, mais sur le site Web, cela apparaît toujours en stock. Je vais ruiner l'entreprise comme ça." Je lui ai demandé comment ils établissaient la connexion entre 1C et le site Web. Il s'est avéré qu'il s'agissait d'un schéma standard : téléchargement via CommerceML une fois par jour, la nuit, selon un horaire. Si vous avez de la chance, l'échangeur ne se bloquera pas, le fichier sera analysé et les produits seront mis à jour. Si vous n’avez pas de chance – et vous n’avez pas de chance régulièrement – ​​les gérants découvrent le matin que la moitié des prix sont anciens, qu’il n’y a pas de nouveautés et que, pour une raison quelconque, les produits supprimés sont revenus sur le site.

Cette histoire ne fait pas exception. Je dirais même que c'est la règle. Un propriétaire sur deux d'une boutique en ligne en Russie qui tient des registres dans 1C (et cela, selon diverses estimations, de soixante-dix à quatre-vingts pour cent) est tôt ou tard confronté au fait que la synchronisation des données entre le système comptable et le site se transforme en un casse-tête distinct. Ce n'est pas une tâche secondaire, mais un problème qui consomme du temps, des nerfs et de l'argent. Et ce qui est le plus offensant, c’est que ce problème est résolu techniquement depuis longtemps. C’est juste que la grande majorité utilise encore des outils qui ont quinze ans, parce que « bon, ça marche d’une manière ou d’une autre » et « y a-t-il autre chose ?

Oui, il y en a. Et je souhaite parler en détail de la façon dont nous avons abordé cette tâche lors du développement du module d'intégration 1C dans notre plugin COS WP Woo, pourquoi nous avons choisi une voie fondamentalement différente et ce que cela a apporté à nos clients dans la pratique. Pas sous la forme d'un livret publicitaire, mais honnêtement - avec la commission que nous avons collectée, avec des solutions qui ne se sont pas révélées évidentes et avec des résultats mesurables.

Pourquoi CommerceML est un protocole du siècle dernier

Je vais maintenant dire quelque chose qui peut paraître catégorique, mais je suis convaincu de son exactitude : CommerceML en tant que format d'échange de données entre 1C et une boutique en ligne est devenu obsolète il y a une dizaine d'années. Il a été conçu au début des années 2000, lorsqu'une boutique en ligne était une vitrine avec un catalogue et un bouton « commander », la mise à jour des étiquettes de prix une fois par semaine était considérée comme la norme, et l'idée d'une synchronisation en temps réel semblait être un caprice. Ensuite, CommerceML a parfaitement résolu le problème : il a généré un fichier XML avec les produits et les prix, l'a placé dans un dossier sur FTP, le CMS l'a pris, l'a analysé et a mis à jour le catalogue. Simple, fiable, compréhensible.

Mais le monde a changé. Aujourd'hui, le client s'attend à ce que s'il voit « 5 pièces en stock » sur le site Web, cela signifie qu'il y a réellement cinq pièces en stock. Ils n’étaient pas couchés là hier, ils n’y étaient pas il y a trois heures, mais maintenant. Car en même temps, le même produit peut être vendu par un autre canal - par l'intermédiaire du responsable qui a passé la commande par téléphone, via la place de marché, via un point de vente. Et si votre synchronisation fonctionne une fois par heure (ou, comme mon ami, une fois par jour), vous vendez de l'air. Et puis appelez le client et dites-lui : « Désolé, il y a eu une erreur, il n'y a pas de produit, laissez-nous vous rendre votre argent. » Chacun de ces appels n’est pas seulement une vente perdue. C'est une confiance brisée. Il s'agit d'une critique négative. C'est un client qui ne viendra plus vers vous.

Je connais des entreprises qui emploient une personne distincte - en fait, un "responsable de synchronisation", qui vérifie chaque matin si l'échange s'est bien déroulé, corrige manuellement les erreurs, appelle le service 1C et s'occupe des marchandises en double. Cela représente, pour une seconde, un salaire de quarante à soixante mille roubles par mois. Uniquement pour garantir que les données d’un système circulent correctement dans un autre. Absurde? Non, c'est la réalité de milliers de boutiques en ligne russes.

Énumérons honnêtement les problèmes CommerceML que j'ai rencontrés personnellement - dans des projets réels, et non dans des discussions théoriques. Les produits dupliqués sont un classique du genre. CommerceML identifie les produits par le GUID interne de 1C, et si quelque chose ne va pas avec votre base de données, si vous avez restauré une sauvegarde, si 1C a refait le répertoire des articles - c'est tout, les GUID ont disparu, des doublons apparaissent sur le site. La perte d'images est également une histoire courante : CommerceML transfère les images sous forme de pièces jointes binaires en XML, et avec un répertoire volumineux, le fichier d'échange atteint des centaines de mégaoctets, PHP plante en raison d'un délai d'attente ou d'un manque de mémoire au milieu de l'analyse. L'impossibilité de transférer des champs personnalisés est un autre problème : si votre produit en 1C comporte vingt détails supplémentaires (viscosité, point d'écoulement, certificats, approbations du fabricant), l'échangeur CommerceML ne sait tout simplement pas quoi en faire. Maximum - videra la « description » dans un champ de texte. Et, peut-être, la chose la plus désagréable : si l'échange est interrompu au milieu (et avec un grand catalogue, cela arrive tout le temps), vous obtenez un catalogue à moitié mis à jour, où certains produits ont de nouveaux prix et d'autres ont d'anciens prix. Et pas de journal, aucun moyen de comprendre exactement ce qui a été mis à jour et ce qui ne l’a pas été.

Lorsque j'ai réalisé tout cela à partir de ma propre expérience - et j'ai vécu l'intégration de 1C avec le site sur plusieurs projets au cours des dernières années - j'ai réalisé qu'une approche fondamentalement différente était nécessaire. Pas de « CommerceML amélioré », ni de « CommerceML v2 avec des béquilles », mais une architecture d'échange de données complètement différente.

OData : quand 1C parle HTTP

Et nous arrivons ici à une technologie qui, à proprement parler, existe dans 1C depuis longtemps - depuis la version 8.3 - mais que la grande majorité des développeurs de boutiques en ligne, pour une raison quelconque, ignorent obstinément. Je parle de l'interface OData fournie par 1C. Le point est simple : votre base de données 1C devient un serveur API REST. Vous pouvez y accéder via HTTP, recevoir des données au format JSON, filtrer, trier, paginer - tout ce qui est depuis longtemps devenu un standard dans le monde du développement web. Pas de fichiers XML sur FTP. Pas de « téléchargement programmé ». Connexion directe, en temps réel, aux données en direct de votre système comptable.

Honnêtement, lorsque j'ai essayé pour la première fois l'interface 1C OData, j'ai ressenti une sensation étrange - un mélange de plaisir et d'irritation. Délice - parce que cela fonctionne vraiment. Vous faites une requête HTTP GET sur votre 1C et recevez du JSON avec les produits, les prix, les soldes, les caractéristiques - tout ce qui est dans la base de données. Désagrément - parce que cette fonctionnalité existe depuis des années et que nous avons eu du mal avec CommerceML pendant tout ce temps. Pourquoi? Je pense pour plusieurs raisons. Premièrement, OData concerne la programmation, et non « appuyez sur un bouton - obtenez un fichier ». Vous devez comprendre les requêtes HTTP, vous devez être capable de travailler avec l'API REST, vous devez écrire du code. Deuxièmement, la documentation 1C sur OData, pour le moins, est loin d'être idéale. Essayez de trouver une description claire de la façon d'obtenir des détails supplémentaires sur un article via OData - j'ai passé deux jours là-dessus. Troisièmement, la majorité des « pseudos 1C » sont des personnes qui vivent dans le monde 1C et ont peu d'idées sur le fonctionnement du Web moderne. Et la plupart des développeurs Web évitent donc 1C comme quelque chose d'incompréhensible. Le lien entre les deux mondes fait cruellement défaut.

Nous avons résolu ce problème lors du développement du module 1C dans COS WP Woo. L'idée était simple : créer un pont qui, d'une part, communique avec 1C dans son langage (requêtes OData vers l'interface standard), et d'autre part, avec WooCommerce dans son langage (API WordPress, hooks WooCommerce, tables personnalisées). Et faites-le de manière à ce que le propriétaire du magasin n'ait pas besoin de comprendre les requêtes OData, REST API ou HTTP. J'ai établi la connexion et cela fonctionne.

Voici à quoi cela ressemble techniquement, sans aucune simplification. Notre module OnecSync se connecte à l'interface OData de 1C : Trade Management (1C:UT) via HTTP standard. L'adresse de connexion ressemble à une URL normale - quelque chose comme http://votre-serveur/votre-database/odata/standard.odata. Autorisation - Basic Auth, standard pour HTTP. Pas de connecteurs spéciaux, d'objets COM, de traitement de téléchargement - tout fonctionne via des requêtes HTTP régulières, que WordPress peut envoyer via wp_remote_get/wp_remote_post. C'est un point fondamentalement important : votre hébergement n'a besoin d'aucune extension PHP particulière, ni de modules COM, ni de bibliothèques tierces. Si votre WordPress peut effectuer des requêtes HTTP (et il le peut toujours), l'intégration fonctionnera.

Les données que nous récupérons de 1C passent par un système de composants. OnecDataFetcher est responsable de la réception des données brutes - produits, prix, soldes, caractéristiques. OnecProductImporter prend ces données et les convertit en structures WooCommerce - crée ou met à jour des produits, fixe les prix, lie les catégories et les attributs. OnecAttributeMapper est un composant distinct qui compare les attributs 1C (détails supplémentaires sur les éléments) avec les taxonomies WooCommerce. OnecCategoryMapper fait donc de même pour les catégories. Tout cela est enveloppé dans une seule façade OnecSync, qui coordonne le travail des composants et assure la transactionnalité : si quelque chose ne va pas au milieu d'une importation, le système sait ce qui a déjà été traité et ce qui ne l'a pas encore été.

Dix-neuf mille produits : comment ça marche en pratique

Vous savez, parler d'architecture est une chose. Mais montrer comment cela fonctionne sur un répertoire réel est complètement différent. Je vais vous parler de notre propre expérience, car nous avons intégré 1C:UT à WooCommerce pour notre client - une boutique en ligne de lubrifiants avec un catalogue de dix-neuf mille deux cent deux produits. Il ne s'agit pas d'un petit magasin d'essais avec une vingtaine de positions, c'est un catalogue industriel à part entière avec des dizaines de catégories, des centaines de marques et de nombreuses caractéristiques pour chaque produit : viscosité, point d'éclair, point d'écoulement, agréments constructeur automobile, certificats de conformité GOST et TU.

La première chose que nous avons rencontrée était le volume. Dix-neuf mille produits ne peuvent pas être simplement téléchargés avec une seule demande. L'interface 1C OData prend en charge la pagination (paramètres $top et $skip), mais même avec la pagination, le traitement simultané d'un tel volume est une tâche qui ne peut être résolue dans le cadre d'une requête HTTP WordPress classique. Le délai d'attente PHP standard est de trente secondes, parfois soixante sur l'hébergement. Et importer dix-neuf mille biens présentant des caractéristiques, des prix et des soldes prend des minutes, voire des dizaines de minutes.

C'est là qu'Action Scheduler entre en scène, un système de tâches en arrière-plan intégré à WooCommerce. Nous divisons l'importation en morceaux de trois cents produits et définissons chaque morceau comme une tâche d'arrière-plan distincte. Action Scheduler extrait ces tâches de la file d'attente et les exécute séquentiellement, chacune dans sa propre requête HTTP, avec son propre délai d'attente. Si un morceau tombe, le suivant sera quand même traité. Si le serveur redémarre, la file d'attente est enregistrée dans la base de données, le traitement reprend là où il s'était arrêté. C’est une différence fondamentale avec l’approche CommerceML, où si l’échange est interrompu au milieu, c’est tout, recommencez. Chez nous, chaque produit a son propre statut de transformation, et lorsque les importations reprennent, seuls les produits qui n'ont pas encore été transformés le sont.

Le deuxième défi majeur est la cartographie des attributs. Dans 1C:UT, un produit peut avoir des dizaines de détails supplémentaires, et chaque détail a son propre type, son propre nom et son propre ensemble de valeurs acceptables. Dans WooCommerce, les attributs sont des taxonomies, avec leur propre système de slugs, term_id et autres cuisines WordPress. Attacher les uns aux autres avec vos mains est un travail qui prend des jours, voire des semaines. Par conséquent, nous avons réalisé un mappage automatique (découverte automatique) : lors de votre première connexion à 1C, le module analyse tous les détails supplémentaires de l'article et crée automatiquement les taxonomies correspondantes dans WooCommerce. Dans notre cas réel, sur quatre cent quatre-vingt-dix attributs 1C, quatre-vingt-dix-neuf ont été automatiquement mappés à cent vingt et une taxonomies WooCommerce. La différence de chiffres s'explique par le fait que certains attributs 1C sont divisés en plusieurs taxonomies WooCommerce (par exemple, les « Approbations du fabricant » de 1C se transforment en taxonomies distinctes pour chaque fabricant). Les attributs restants n'ont pas été délibérément cartographiés - ce sont des détails de service 1C qui n'ont aucune signification sur le site.

Je me souviens de la première fois que nous avons lancé l'importation complète en direct. Je me suis assis et j'ai mis à jour la page du tableau de bord toutes les trente secondes, regardant le compteur de produits transformés augmenter : trois cents, six cents, neuf cents... Lorsqu'il a atteint trois mille, je me suis déjà détendu - il est devenu clair que le système était stable, qu'il n'y avait pas d'erreurs, chaque morceau était traité en sept à dix secondes. Il restait environ une heure avant la fin. Je suis allé boire du café. À mon retour, dix-neuf mille deux cent deux produits se trouvaient dans WooCommerce, avec des prix, des soldes, des catégories et des attributs. Pas un seul doublon, pas une seule photo perdue (enfin, pour être honnête, les photos étaient une autre histoire, dont je vous parlerai plus tard), pas un seul produit avec un prix erroné. Vous savez, des moments comme ceux-ci valent la peine d’écrire du code.

Mais l'importation ne représente que la moitié de la tâche. Importer des marchandises une fois, c'est comme emménager dans un nouvel appartement : les travaux principaux sont à venir. Ensuite, vous devez maintenir les données à jour. Chaque jour dans 1C, les prix changent, les marchandises arrivent à l'entrepôt, les marchandises quittent l'entrepôt, de nouveaux articles apparaissent, certains sont abandonnés. Et tous ces changements devraient être reflétés sur le site - non pas en un jour ou une heure, mais idéalement en quelques minutes.

Modèle Webhook : laissez 1C lui-même vous dire ce qui a changé

C'est là que nous arrivons à l'une des décisions architecturales clés qui distinguent notre approche de quatre-vingt-dix pour cent des intégrations existantes. La plupart des plugins de synchronisation fonctionnent sur le principe du sondage : toutes les N minutes (cinq, dix, trente, soixante) WordPress fait une requête à 1C et vérifie si quelque chose a changé. C'est comme si vous appeliez l'entrepôt toutes les cinq minutes et demandiez : « Eh bien, avez-vous apporté quelque chose de nouveau ? Après dix appels de ce type, le commerçant cessera de répondre au téléphone - et il aura raison.

Le problème avec l'approche de sondage est l'échelle. Si vous avez un millier de produits, les vérifier toutes les cinq minutes est une tâche relativement légère. Mais que se passe-t-il si vous avez vingt mille produits ? Cent mille ? A chaque itération de sondage, votre WordPress envoie des dizaines de requêtes à 1C, 1C les traite, renvoie les données, WordPress les compare avec ce qui se trouve dans la base de données - et dans quatre-vingt-quinze pour cent des cas, il découvre que rien n'a changé. Tout cet échange de données ne sert à rien. C'est la charge sur le serveur 1C, la charge sur l'hébergement WordPress, le trafic gaspillé, les ressources du serveur gaspillées. Et avec tout cela, il y a un délai allant jusqu'à cinq minutes entre un réel changement dans 1C et sa réflexion sur le site. Pour de nombreuses entreprises, cela est essentiel.

Nous avons pris un chemin différent. Notre module implémente un modèle de webhook : 1C informe lui-même le site des modifications. Il y a eu un changement dans le prix d'un produit - 1C envoie une requête HTTP à votre site Web avec des informations sur quel produit a changé et ce qui a changé exactement. Un envoi est arrivé à l'entrepôt - 1C envoie un webhook avec les soldes mis à jour. Un nouveau produit a été créé - 1C le signale au site. Le site reçoit une notification et ne traite que les produits réellement modifiés. Pas de recherche vide de vingt mille postes. Aucune charge sur 1C due à des demandes constantes.

Je comprends qu'un développeur 1C expérimenté peut maintenant se poser une question : « Comment cela est-il implémenté côté 1C ? C’est une question valable, et y répondre est l’un des endroits où vous devez être honnête sur les complexités. L'interface 1C OData prête à l'emploi ne prend pas en charge les abonnements webhook de la même manière qu'elle est implémentée, par exemple, dans Stripe ou GitHub. Pour un modèle de webhook à part entière, des modifications sont nécessaires du côté 1C - en s'abonnant aux événements et en envoyant une requête HTTP lorsque les données changent. Cela peut être implémenté via des abonnements à des événements, via des tâches en arrière-plan, via des extensions de configuration. Notre module OnecWebhookHooks côté WordPress reçoit ces notifications et les traite. Côté 1C, nous proposons un traitement qui configure l'envoi des webhooks. Oui, cela nécessite une certaine configuration du côté 1C, mais il s'agit d'une configuration unique que tout spécialiste 1C compétent peut effectuer en quelques heures.

Pour les cas où le modèle webhook est impossible (par exemple, le client ne veut pas ou ne peut pas modifier 1C), nous avons une solution de secours - le composant OnecStockSync, qui fonctionne selon un calendrier, mais le fait plus intelligemment qu'une interrogation régulière. Au lieu de parcourir tous les produits, il demande à 1C uniquement les modifications de la dernière période. OData prend en charge le filtrage par date de modification : nous interrogeons uniquement les enregistrements qui ont changé depuis la dernière synchronisation. C'est des ordres de grandeur plus efficaces qu'une recherche complète - au lieu de vingt mille produits, dix à vingt sont traités qui ont réellement changé.

Mais laissez-moi vous parler encore d'une chose qui semble insignifiante, mais qui en pratique permet d'économiser énormément de nerfs : une table de cartographie. Lorsque vous associez deux catalogues - dans 1C et dans WooCommerce - vous avez besoin d'un moyen fiable pour déterminer quel produit dans 1C correspond à quel produit sur le site. Il semblerait que la tâche soit triviale : nous prenons l'article, trouvons le produit grâce à lui dans les deux systèmes, et le tour est joué. Mais en pratique, tout est plus compliqué. Les articles peuvent différer par l’orthographe (espaces, casse, caractères spéciaux). Certains produits peuvent ne pas avoir de numéro d'article. Un produit en 1C peut avoir plusieurs articles (principal et fournisseur). Il se peut qu'il n'y ait aucun article - seulement un nom et un code interne.

Par conséquent, nous avons créé une table de mappage distincte - wpaic_1c_map - qui stocke la relation entre les produits 1C et WooCommerce. La connexion peut se faire par article, par UUID (Ref_Key en 1C), par code barre ou par matching manuel. Lors de l'importation pour la première fois, le système essaie de faire correspondre automatiquement les produits par SKU. Ceux qui n’ont pas pu être mappés automatiquement peuvent l’être manuellement dans l’interface d’administration. Une fois le mappage installé, il est enregistré pour toujours - lors des synchronisations ultérieures, le système sait exactement quel produit 1C correspond à quel produit WooCommerce et le met à jour sans recherches ni comparaisons inutiles. Dans notre cas, avec dix-neuf mille produits, la migration du mappage (à partir de l'ancien plugin qui stockait la relation dans la postmeta) a pris plusieurs minutes, et après cela, chaque synchronisation se déroule sans problème - le système ne « devine » pas la correspondance, mais la retire du tableau.

Et maintenant sur quelque chose qui semble à première vue contradictoire : la protection SEO lors de l'importation. Il semblerait que si nous synchronisons les données de 1C, nous synchronisons tout - nom, description, prix, soldes, caractéristiques. Mais en pratique, c’est une erreur catastrophique. Le nom du produit en 1C est un nom interne de comptabilité, souvent illisible : "Huile moteur synthétique. Shell Helix HX8 5W30 A3/B4 bidon de 4l." Sur le site Web, le même nom est optimisé pour la recherche et la perception humaine : « Huile moteur Shell Helix HX8 5W-30 - synthétique, 4 litres, homologation A3/B4 ». Si, lors de chaque synchronisation, le nom 1C écrase le nom du site, adieu l'optimisation SEO. Adieu à tout le travail d’amélioration des titres effectué par le spécialiste du marketing. Adieu les mots-clés dans les slugs d'URL indexés par Google et Yandex.

Par conséquent, notre module dispose de update_fields personnalisés - une liste de champs mis à jour lors de la synchronisation. Par défaut, seuls les prix et les soldes sont mis à jour – ce qui doit réellement être mis à jour en temps réel. Le titre, la description et le slug sont protégés contre l’écrasement. Si vous souhaitez également les mettre à jour, vous devez l'activer explicitement dans les paramètres. Mais nous vous prévenons : si vous avez consacré du temps à l'optimisation SEO des fiches produits, n'activez pas les mises à jour du titre et de la description lors de la synchronisation avec 1C. Laissez le système comptable gérer ce qu'il gère bien : les prix et les soldes, et le contenu du site reste sous le contrôle du spécialiste du marketing.

Variations, caractéristiques et principal écueil du 1C

Un sujet distinct et très non trivial concerne les variations de produits. Dans WooCommerce, une variante est un produit variable avec des variantes enfants, chacune avec ses propres attributs, prix et équilibre. Un exemple typique : un T-shirt avec un choix de taille et de couleur. Dans 1C, un analogue des variations est les caractéristiques de l'article - un répertoire subordonné lié au produit (ou au type d'article) et décrit des variantes d'exécution spécifiques.

Et c'est là que le plaisir commence. La structure des caractéristiques dans 1C:UT est peut-être l'un des endroits les plus non triviaux de toute l'intégration. Les caractéristiques peuvent être liées à un produit spécifique (Ref_Key de l'article), ou elles peuvent être communes à l'ensemble du type d'article (Type of Item_Key). Autrement dit, si vous disposez du type « Huiles moteur » et que ce type a les caractéristiques « Volume » définies (1L, 4L, 5L, 20L, 208L), alors tous les produits de ce type héritent de ces caractéristiques. Mais un produit spécifique peut avoir ses propres caractéristiques qui ne sont pas liées au type. Nous avons mis en place ce que j'appelle une « recherche de double propriétaire » : lors de l'importation d'un produit, le système vérifie les caractéristiques d'abord par la Ref_Key du produit lui-même, puis par la Item Type_Key. Cela couvre les deux scénarios.

Autre détail non trivial : le répertoire subordonné Catalog_CharacteristicsNomenclature dans 1C ne prend pas en charge les paramètres OData standard $select et $filter. Nous l'avons découvert expérimentalement - une requête avec $filter renvoie HTTP 400, et la documentation 1C n'en avertit nulle part. La solution est de télécharger entièrement toutes les caractéristiques et de filtrer côté PHP. Ce n'est pas parfait en termes de performances, mais cela fonctionne de manière fiable, et pour nous, la fiabilité est plus importante que l'élégance.

Je me suis longtemps demandé s'il valait la peine de parler de telles nuances techniques dans un article destiné à un public professionnel. J'ai décidé que cela en valait la peine – pour une raison simple. Lorsque vous choisissez un plugin pour synchroniser 1C et WooCommerce, on vous dit : « Nous avons l'intégration avec 1C ! Mais l’intégration est différente. Une intégration peut transférer des noms et des prix. L'autre fonctionne entièrement avec les caractéristiques, les variations, les prix multiples, les soldes d'entrepôt et les attributs personnalisés. Et la différence entre eux est la différence entre « notre site affiche d'une manière ou d'une autre les données de 1C » et « notre site reflète pleinement la réalité du système comptable, et nous pouvons lui faire confiance ».

Laissez-moi vous parler d'un autre écueil que nous avons découvert déjà en production, avec de vraies données et de vrais clients. Déduplication lors de l'importation de marchandises présentant des caractéristiques. Imaginez : en 1C il y a un produit « Shell Helix HX8 5W-30 Oil » avec des caractéristiques (variations) en volume : 1 litre, 4 litres, 20 litres. Mais historiquement, sur le site WooCommerce, ce produit n'était pas répertorié comme un produit variable, mais comme trois produits simples distincts : « Huile Shell Helix HX8 5W-30 (1 l.) », « Huile Shell Helix HX8 5W-30 (4 l.) », « Huile Shell Helix HX8 5W-30 (20 l.) ». Il s'agit d'une situation très courante : de nombreux magasins listaient initialement les produits sous forme de « liste plate », sans variations. Si, lors de l'importation depuis 1C, nous créons un produit variable « Shell Helix HX8 5W-30 Oil » avec des variantes, il y aura des doublons sur le site : à la fois d'anciens produits « plats » et un nouveau produit variable. Avec des URL différentes, avec un poids SEO différent, avec des conflits potentiels dans le panier.

Nous avons résolu ce problème grâce à une vérification préalable : avant d'importer un produit avec des caractéristiques, le système vérifie s'il existe sur le site des produits d'emballage portant le nom correspondant. Si une correspondance est trouvée, le produit parent n'est pas importé en double, mais est lié aux positions existantes. C'est une petite chose, mais une petite chose qui évite de graves problèmes sur les sites ayant une longue histoire de contenu.

Parlons maintenant de l'échange bidirectionnel - la partie que beaucoup de gens oublient. La synchronisation ne se fait pas seulement « de 1C vers le site ». C'est aussi "du site en 1C". Lorsqu'un client passe une commande sur le site Web, cette commande doit être transmise à 1C pour un traitement ultérieur - émission d'une facture, réservation des marchandises, génération des documents d'expédition. Notre module OnecOrderHooks intercepte les événements WooCommerce - création de commande, changement de statut, paiement - et génère les documents correspondants en 1C. Commande sur le site = commande de l'acheteur en 1C:UT. Paiement sur le site = réception des fonds. Cela évite aux gestionnaires de transférer manuellement les commandes, un travail qui prend plusieurs heures avec cinquante commandes par jour.

Je sais que beaucoup de gens s'inquiètent du problème de sécurité : si on ouvre l'interface 1C OData pour les requêtes HTTP, la base de données devient-elle vulnérable ? Il s’agit d’une préoccupation légitime et nous la prenons au sérieux. Pour une connexion OData, un utilisateur 1C distinct est créé avec des droits minimaux - lisant uniquement les répertoires et les registres nécessaires à la synchronisation. Cet utilisateur ne peut pas modifier la configuration, supprimer des données ou exécuter du code arbitraire. La connexion peut être restreinte par IP - permettant l'accès uniquement à partir de l'adresse IP de votre hébergement WordPress. Tous les échanges peuvent être effectués via HTTPS, les données sont donc cryptées pendant le transit. Et enfin, l'utilisateur OData dispose d'un mécanisme de blocage pour plusieurs tentatives d'authentification échouées : une protection contre la force brute du mot de passe. D'ailleurs, nous avons rencontré cela dans la pratique : lors du débogage, nous nous sommes trompés plusieurs fois avec le mot de passe et le compte OData a été bloqué pendant quinze minutes. C'est désagréable, mais c'est un avantage en matière de sécurité.

Et puisque nous parlons de choses pratiques, je vais parler de journalisation. C'est ce qui distingue un outil professionnel d'un outil artisanal. Chaque opération de synchronisation - chaque demande à 1C, chaque produit traité, chaque erreur - est enregistrée dans la table wpaic_1c_sync_log. Dans le tableau de bord du module, vous voyez l'historique complet : quand a eu lieu la dernière synchronisation, combien de produits ont été traités, combien d'erreurs et quels produits ont causé des problèmes. Si le responsable appelle et dit "le produit X a un prix erroné" - vous ouvrez le journal, trouvez ce produit, voyez quand il a été mis à jour pour la dernière fois, quel prix provient de 1C et comprenez quel est le problème. Sans journalisation, toute intégration est une boîte noire : les données vont quelque part, viennent de quelque part, et si quelque chose ne va pas, vous ne pouvez que deviner à quel stade la panne s'est produite.

Je me souviens comment, à l'une des premières étapes du développement, nous avons lancé la synchronisation sans journalisation détaillée, et deux jours plus tard, nous avons découvert que deux cents produits avaient des prix nuls. Il s'est avéré que dans 1C pour ces produits, le prix était enregistré dans le registre « Prix des articles » avec le type de prix « Détail », et nous avons demandé le type « Prix de détail du SITE » (c'est ainsi qu'on l'appelait dans les paramètres). Deux cents produits qui n'avaient pas d'enregistrement avec le type de prix requis ont reçu un zéro. Si nous avions un log, nous aurions vu l’avertissement « prix introuvable pour le produit X » et aurions compris le problème en cinq minutes, et non en deux jours. Après cet incident, nous avons rendu la journalisation la plus détaillée possible, avec des avertissements pour chaque situation anormale. Désormais, le système avertit des produits sans prix, des produits sans catégorie, des produits avec un solde nul, des incohérences dans la cartographie - de tout ce qui pourrait constituer un problème potentiel.

Quinze minutes avant la première importation : Assistant Paramètres

L'une des choses dont je suis particulièrement fier est le sorcier. J'ai longtemps réfléchi à la raison pour laquelle l'intégration avec 1C est considérée comme « une tâche complexe nécessitant un programmeur ». Et je suis arrivé à la conclusion qu’il ne s’agit pas de complexité technique en soi, mais de la manière dont cette tâche est présentée à l’utilisateur. Une instruction typique pour la configuration de l'échange 1C et WooCommerce est un document de dix pages avec les termes « URL de publication de l'infobase », « paramètres du service HTTP », « mise en place d'un plan d'échange ». Une personne qui n'est pas un développeur 1C ferme cette instruction sur la deuxième page.

Nous avons créé un assistant étape par étape qui guide l'utilisateur tout au long du processus de configuration. La première étape consiste à saisir l'adresse et les informations d'identification du serveur 1C. Le système vérifie la connexion et affiche : "Connexion établie. Base : Trade Management, version 11.5.16, organisation : LLC "Votre entreprise". La deuxième étape consiste à sélectionner un catalogue de produits et un type de prix. Le système affiche les catalogues disponibles et les types de prix de 1C, l'utilisateur sélectionne ceux dont il a besoin. La troisième étape consiste à mettre en place la cartographie : le système associe automatiquement les produits par article et affiche le résultat. La quatrième étape consiste à sélectionner les champs à synchroniser et à établir un calendrier. Et la cinquième étape consiste en un essai sur dix produits pour s’assurer que tout fonctionne correctement. L'ensemble du processus prend dix à quinze minutes. Pas dix heures, pas trois jours, quinze minutes. A condition bien sûr d'avoir déjà configuré l'interface OData côté 1C. S'il n'est pas configuré, c'est encore une demi-heure de travail pour l'administrateur 1C ; nous fournissons des instructions étape par étape pour cela.

Savez-vous ce que j'ai remarqué en pratique ? La question la plus courante lors de la mise en place de l’intégration n’est pas technique. Pas « comment configurer OData » ni « comment mapper les attributs ». La question la plus courante : « Etes-vous sûr que rien ne va casser sur le chantier ? Les gens ont peur que l’intégration écrase les données existantes, brise le catalogue et supprime des produits. Et c'est une crainte compréhensible - beaucoup ont eu des expériences négatives avec CommerceML, lorsqu'après un échange infructueux, ils ont dû restaurer la base de données à partir d'une sauvegarde. C'est pourquoi nous avons réalisé plusieurs niveaux de protection. Mode « Affichage uniquement » (essai à sec) - le système affiche ce qui sera fait, mais n'apporte aucune modification. Testez l'importation sur dix produits pour vous assurer que le mappage est correct. La protection contre l'écrasement des champs SEO est désactivée par défaut. Et, bien sûr, en enregistrant chaque action afin que si quelque chose se produit, vous puissiez revenir en arrière.

J'entends souvent des concurrents : « Notre plugin fait la même chose. » Permettez-moi de ne pas être d'accord. Lorsque vous achetez un « plugin d’intégration 1C et WooCommerce », regardez attentivement ce qu’il fait réellement. Prend-il en charge OData ou fonctionne-t-il uniquement via CommerceML ? Traite-t-il les caractéristiques des articles et crée-t-il des variations, ou importe-t-il uniquement des articles simples ? Existe-t-il une découverte automatique des attributs, ou devez-vous enregistrer manuellement la correspondance de chaque champ ? Comment les erreurs sont-elles gérées : sont-elles avalées silencieusement ou sont-elles enregistrées avec des détails ? Existe-t-il une protection contre la duplication ? La synchronisation inverse fonctionne-t-elle (commandes depuis le site Internet en 1C) ? Toutes ces questions ne sont pas des « petits plus », mais des exigences fondamentales pour une intégration normale.

Savez-vous ce qui me surprend le plus dans cette histoire ? Combien de temps et d’argent les entreprises consacrent-elles à la résolution d’un problème techniquement résolu. L'interface 1C OData existe depuis de nombreuses années. WordPress peut effectuer des requêtes HTTP dès le premier jour. WooCommerce fournit des hooks pour créer et mettre à jour des produits. Action Scheduler résout le problème des gros volumes. Toutes les briques sont en place depuis longtemps, il suffit de les assembler correctement. Mais « correct » est le mot clé. Correctement signifie prendre en compte les caractéristiques réelles de 1C (et non théoriques), avec traitement de tous les cas extrêmes (doublons, emballages, prix manquants), avec protection contre les actions destructrices et avec une journalisation détaillée. C'est exactement ce que nous avons fait dans COS WP Woo.

Revenant à mon ami possédant une boutique en ligne de produits chimiques industriels, nous l'avons aidé à passer de l'intégration CommerceML à OData. Il a fallu deux jours : une journée pour mettre en place OData côté 1C (ils avaient déjà un spécialiste 1C à plein temps), et une journée pour mettre en place le module dans COS WP Woo. La première importation complète a eu lieu du jour au lendemain : quatre mille marchandises avec prix et soldes. Après cela, la synchronisation des soldes a commencé à fonctionner via des webhooks : un changement dans 1C signifie une mise à jour sur le site en quelques secondes. Au cours du premier mois après la transition, le nombre de situations « vendu quelque chose qui n’est pas là » est passé de trois ou quatre par semaine à zéro. Complètement nul. Un responsable qui passait deux heures le matin à vérifier la bourse passe désormais cinq minutes à ouvrir le tableau de bord, à s'assurer que tout est vert et à se mettre au travail. À propos, le même responsable traite désormais les commandes - une activité plus utile et plus productive que la réconciliation manuelle quotidienne des données entre deux systèmes. Le gain rien que sur son temps de travail est d'environ quinze heures par mois, et il s'agit d'une estimation prudente.

Je ne dis pas que notre solution est parfaite. Cela a des limites. Il fonctionne avec 1C : Trade Management (1C:UT) – la configuration la plus courante pour les sociétés commerciales. Si vous disposez de 1C:Comptabilité ou d'une autre configuration non standard, certaines modifications seront nécessaires. L'interface OData doit être configurée et publiée côté 1C - il s'agit d'une opération unique mais nécessaire qui nécessite un administrateur 1C. Le modèle Webhook nécessite une amélioration côté 1C (traitement de l'envoi des notifications). Et enfin, pour les catalogues volumineux (plus de dix mille produits), la première importation complète prend du temps - de trente minutes à plusieurs heures, selon la vitesse du serveur 1C et le volume de données.

Mais toutes ces restrictions peuvent être résolues. Et ils sont incomparablement moindres que les problèmes que vous rencontrez en restant sur CommerceML : doublons, perte de données, retards d'une journée, manque de feedback, impossibilité de transférer les champs personnalisés. J'ai vu suffisamment de projets pour dire que l'intégration d'OData via un outil normal n'est pas un luxe ou une « option avancée ». C'est une nécessité pour toute boutique en ligne qui travaille sérieusement avec 1C et souhaite que son site Web reflète la réalité, et non une copie obsolète de celle-ci.

Parfois, il me semble que le problème de l'intégration de 1C et des sites Web n'est pas du tout un problème technique. C'est le problème de l'écart entre deux mondes : le monde des systèmes comptables (où vivent les pseudos 1C) et le monde du développement web (où vivent les « développeurs de sites »). Chaque monde connaît ses propres instruments, parle sa propre langue et comprend mal l'autre. CommerceML était le pont entre ces mondes – maladroit, obsolète, mais compréhensible des deux côtés. OData est un pont de nouvelle génération : plus rapide, plus fiable, plus flexible, mais exigeant que les deux parties soient prêtes à faire un pas l'une vers l'autre. Notre module dans COS WP Woo tente de rendre cette étape aussi simple que possible. Sorcier, qui vous guidera par la main. Découverte automatique, qui traitera les attributs eux-mêmes. Une protection SEO qui vous évitera de casser ce qui fonctionne déjà. Et un journal détaillé qui montrera ce qui se passe exactement lors de chaque synchronisation.

Si vous êtes assis maintenant et pensez : « J'ai quatre cents produits, CommerceML peut les gérer, pourquoi ai-je besoin de tout cela ? - Je vais répondre de cette façon. Si votre entreprise ne se développe pas, si vous n’ajoutez pas de nouveaux canaux de vente, si les clients ne se soucient pas de savoir si les soldes sur le site sont à jour, alors ce n’est vraiment pas nécessaire. Mais si vous envisagez de vous développer, si le catalogue augmente, si vous avez besoin de vendre simultanément sur plusieurs canaux (site Web, places de marché, réseaux sociaux) et de disposer de données à jour partout - alors la transition vers une intégration normale via OData n'est pas « si », mais « quand ». Et il vaut mieux le faire avant de commencer à vendre de l'air et à perdre des clients, et pas après. Car regagner la confiance d’un client à qui vous avez vendu un produit inexistant coûte bien plus cher que de passer deux jours à mettre en place une intégration normale.

Essayez COS WP Woo - 14 jours gratuits.Le module d'intégration 1C est inclus dans tous les tarifs. L'assistant de configuration vous guidera de l'installation du plugin à l'importation des produits pour la première fois en quinze minutes. Aucune connaissance particulière n'est requise - si vous disposez de 1C : Trade Management et WooCommerce, tout fonctionnera. Et si vous avez des questions, notre équipe vous aidera à mettre en place OData côté 1C et à la première importation.