Qu'est-ce que l'intégration e-commerce ERP : comment une commande sort du stock

Dans une entreprise sans intégration, quelqu'un ouvre le matin l'interface de la boutique, saisit une à une les commandes de la nuit dans l'ERP, puis vérifie le comptage de l'entrepôt et corrige à la main le stock du site. Tant que l'activité est petite, cela fonctionne. Quand les commandes augmentent, les fautes de saisie, les retards et les commandes oubliées augmentent aussi. L'information que porte une intégration se répartit selon son sens :

• Du magasin vers l'ERP : la commande, les coordonnées du client, l'état du paiement.
• De l'ERP vers la boutique : niveau de stock, prix, informations produit.
• Dans les deux sens : statut de commande, suivi d'expédition, retours et annulations.

Une intégration est moins une fonction logicielle qu'un accord : deux systèmes s'entendent sur les informations qu'ils partagent, dans quel ordre et selon quelles règles. Quand cet accord n'est pas écrit, l'intégration tourne au débat sur qui a raison dès le premier problème.

Le périmètre de l'intégration doit aussi être fixé dès le départ : seules les commandes seront-elles transférées, ou aussi les fiches clients, les listes de prix et les prix promotionnels ? Plus le périmètre s'élargit, plus les règles de correspondance se multiplient.

Tout commence par la correspondance. Le code du produit dans la boutique et celui de la fiche article dans l'ERP doivent être identiques. Le « piment en flocons, moyennement fort, demi-kilo » du producteur d'épices est une variante sur le site, mais une fiche article distincte dans l'ERP. Si la variante et la fiche article ne correspondent pas, la commande arrive dans l'ERP mais ne touche pas au stock. Nous montrons où une fiche article dans un logiciel séparé atteint ses limites dans fiche article et ERP.

Il y a aussi la question des unités : le paquet sur le site, le carton au dépôt, le kilogramme dans l'ERP. Si la conversion d'unités n'est pas définie, la commande arrive sur le bon produit, mais une mauvaise quantité est déduite du stock. Le retour de l'information de stock vers la boutique est l'autre bout de la chaîne ; quand il ne reste qu'un paquet au dépôt, le site doit lui aussi afficher le dernier paquet.

Si la correspondance est correcte, deux approches existent. Certaines entreprises réservent la quantité dès réception de la commande et la déduisent à l'expédition ; d'autres la déduisent immédiatement. La réservation évite un stock faussé pour les commandes dont le paiement n'est pas confirmé ou qui peuvent être annulées. Le choix dépend de l'organisation de votre comptabilité et de votre entrepôt.

Scénario type : imaginez une soirée de promotion avant une fête. Le dernier carton du dépôt est vendu sur le site ; si le même carton est promis l'après-midi à un épicier qui a appelé par téléphone, le lendemain matin quelqu'un doit appeler l'un des deux clients pour s'excuser. La vente a été bien faite ; ce qui coince, ce sont les deux enregistrements de stock séparés.

Les retours dérapent de la même façon. Le client renvoie le produit, la boutique enregistre le retour, mais dans l'ERP le stock et le compte restent inchangés. En fin de mois, la comptabilité met côte à côte le rapport de la boutique et celui de l'ERP, et cherche pendant des jours d'où vient l'écart.

Le fonctionnement sans intégration a aussi un coût caché : le temps de la personne qui saisit les commandes à la main. En période de promotion, ce travail se prolonge tard dans la nuit, et le risque d'erreur augmente avec la fatigue.

Une fois l'intégration en place, comparer les deux côtés pendant les premières semaines est une bonne habitude : en fin de journée, la liste des commandes de la boutique correspond-elle à celle de l'ERP ?

Si vous vendez aussi sur des places de marché en plus de votre propre site, le même stock est vendu sur plusieurs canaux. Les commandes de chaque canal doivent arriver dans l'ERP avec les mêmes règles de correspondance ; sinon, une vente sur un canal ne met pas à jour le stock des autres. C'est pourquoi certaines entreprises réservent une partie du stock par canal.

Côté comptabilité, les ventes sur une marketplace sont différentes aussi : ce n'est pas le client mais la marketplace qui vous paie, après déduction de la commission et des frais d'expédition. Si ces retenues ne sont pas enregistrées séparément dans l'ERP, le compte tiers et le mouvement bancaire ne concordent pas.

Chaque place de marché a ses propres règles pour le statut des commandes, l'expédition et les retours. Si l'intégration ne fait pas correspondre ces statuts à ceux de l'ERP, une commande apparaît « expédiée » d'un côté et « en préparation » de l'autre. Les paiements des places de marché n'arrivent souvent pas le jour de la commande, mais par versements groupés périodiques ; rapprocher chaque commande du paiement qui l'a soldée est un travail à part pour la comptabilité.

• Les codes produits sont-ils les mêmes dans la boutique et dans l'ERP ; comment les variantes sont-elles associées ?
• Quelle est la source de référence pour le stock : l'ERP ou la boutique ?
• Le transfert se fait-il en temps réel ou à intervalles réguliers ?
• Où apparaît une commande qui n'a pas pu être transférée, et qui est prévenu ?
• Dans quel sens, et sur quel enregistrement, circulent retours et annulations ?
• De quel côté la facture est-elle préparée, et sous quel type de document ?

La dernière question touche à la réglementation fiscale ; précisez avec votre expert-comptable quel document doit être émis. La question des commandes non transmises est la plus souvent oubliée : si l'intégration s'arrête sans bruit, personne ne s'en aperçoit, jusqu'à ce qu'un client demande où est son colis. Si celui qui construit l'intégration n'est pas celui qui l'exploite, la personne à contacter en cas de panne doit aussi être écrite. Savoir qui est prévenu en premier le matin quand le transfert s'est arrêté pendant la nuit, voilà la réponse à cette question.

Après sa commande, le client du producteur d'épices demande sur WhatsApp où en est son colis, puis une semaine plus tard un prix de gros. Ces conversations relèvent de la relation client, pas de l'ERP. Nous avons détaillé la différence entre les deux dans l'article Différence entre CRM et ERP.

C'est pourquoi la relation client ne doit pas rester en dehors de l'intégration. Quand la question sur le colis, la demande de retour et la demande de prix de gros figurent sur la fiche du même client, on y lit aussi à qui proposer quoi lors de la prochaine campagne.

Ici, nous ne présentons pas Corex360 comme un outil d'intégration e-commerce ou de place de marché. Le noyau de Corex360 garde client, devis, contrat, facture, personnel et fichier dans le même enregistrement ; les échanges WhatsApp, Instagram et web arrivent sur la fiche client par une seule boîte de réception. Vous pouvez voir cette organisation sur la page réunissez vos canaux dans une seule boîte de réception.

Corex360 n'est pas présenté comme un logiciel de stock, de commandes ou d'intégration de places de marché ; retirer une commande du stock relève de votre plateforme e-commerce et de votre ERP. Les messages WhatsApp, Instagram et du chat web du client arrivent dans une seule boîte de réception dans la fenêtre Messages, et l'origine de l'opportunité est conservée dans l'enregistrement. Le formulaire de devis du site ouvre automatiquement une fiche d'opportunité. La facture de vente est émise dans le module Comptabilité. Corex360 dispose d'une API pour échanger des données avec des systèmes externes.