Points de vente et ERP
Des points de vente à l’ERP : ventes, stocks et prix alignés
Ventes et retours comptabilisés depuis chaque magasin, évolutions de stock et de prix renvoyées, et totaux de fin de journée rapprochés.
Schéma
Faites défiler latéralement pour voir tout le schéma.
Du POS à l’ERP : chaque vente comptabilisée une seule fois
Les ventes remontent des caisses vers l’ERP sous forme d’événements ; les prix et les stocks redescendent. Un magasin hors ligne continue de vendre puis se resynchronise. Une comptabilisation en échec est relancée, puis confiée à une personne.
- Flux principal
- Asynchrone
- Chemin d’exception
Le flux, étape par étape
- Source Terminaux de point de vente, destination Serveur magasin ou cloud POS : Ventes, retours et annulations (flux principal).
- Source Serveur magasin ou cloud POS, destination Couche d’intégration : Événements de vente et totaux de fin de journée, via une file d’événements, via REST/JSON (asynchrone).
- Source Couche d’intégration, destination ERP : Ventes et mouvements de stock comptabilisés, via OData · REST/JSON (flux principal).
- Source ERP, destination Couche d’intégration : Prix, promotions et données articles, par API ou export de fichiers, via REST/JSON (flux principal).
- Source Couche d’intégration, destination Serveur magasin ou cloud POS : Mises à jour des prix et des stocks, via REST/JSON (flux principal).
- Source Couche d’intégration, destination File de nouvelles tentatives : Échec de comptabilisation (chemin d’exception).
- Source File de nouvelles tentatives, destination Couche d’intégration : Relancé (chemin d’exception).
- Source File de nouvelles tentatives, destination Équipe des opérations magasins : Échec persistant : alerte avec le détail (chemin d’exception).
Présentation
Il s’agit du flux entre les caisses de vos magasins et l’ERP qui se trouve derrière elles. Les ventes, les retours et les annulations remontent vers l’ERP. Les prix, les promotions, les données articles et les stocks redescendent. Lorsque les deux divergent, les magasins vendent au mauvais prix, les chiffres de stock perdent toute crédibilité et la finance passe la clôture mensuelle à rapprocher.
L’architecture de référence transmet chaque transaction du magasin sous forme d’événement, via une couche d’intégration dotée d’une file d’attente. La couche convertit chaque événement en pièces de vente et de stock de l’ERP et le comptabilise exactement une fois. Dans l’autre sens, les modifications effectuées dans l’ERP sont envoyées aux magasins concernés, pour que chaque caisse travaille sur les mêmes données.
Les magasins perdent leur connexion, et l’architecture le prévoit. Le serveur du magasin ou le serveur cloud du POS continue de vendre et rattrape son retard au retour de la ligne. Une comptabilisation en échec est relancée, et celle qui échoue durablement est confiée à une personne avec tous les détails, au lieu de disparaître.
Fonctionnement du flux
- 01
Vendre en caisse
Chaque vente, retour et annulation est enregistré sur le terminal de point de vente avec un identifiant unique, le magasin, la caisse et l’heure.
- 02
Conserver en magasin
Le serveur du magasin ou le serveur cloud du POS collecte les transactions et les transmet sous forme d’événements, en les conservant en lieu sûr tant que le magasin est hors ligne.
- 03
Comptabiliser dans l’ERP
La couche d’intégration convertit chaque événement en ventes et en mouvements de stock, puis le comptabilise dans l’ERP en vérifiant son identifiant, afin que rien ne soit comptabilisé deux fois.
- 04
Envoyer les prix et les articles
Les données articles, les prix et les promotions sont publiés depuis l’ERP à chaque modification, avec la date et les magasins concernés.
- 05
Mettre à jour chaque magasin
La couche transmet chaque modification aux magasins concernés et enregistre ceux qui l’ont confirmée.
En cas d’erreur
Une comptabilisation échoue
Les incidents temporaires donnent lieu à de nouvelles tentatives à délais croissants. Une comptabilisation toujours en échec rejoint une file des messages en échec, et l’équipe des opérations magasins reçoit une alerte avec la transaction et l’erreur.
Un magasin passe hors ligne
Le magasin continue de vendre sur ses données locales. Les transactions sont conservées puis envoyées dans l’ordre au retour de la connexion, et un magasin silencieux trop longtemps déclenche une alerte.
Une transaction arrive deux fois
Chaque transaction porte un identifiant unique. La couche reconnaît une répétition et l’ignore, si bien qu’un renvoi après une interruption ne double jamais une vente.
Les totaux du magasin et de l’ERP diffèrent
Les totaux de fin de journée de chaque magasin sont comparés à ce que l’ERP a reçu. Un écart ouvre une revue qui liste les transactions manquantes ou en trop.
Standards et systèmes
- Données et analytique
- Apache Kafka
- Systèmes ERP
- SAP S/4HANA
- Oracle NetSuite
- Microsoft Dynamics 365 Business Central
- Odoo
- Intégration
- REST
- Webhooks
- RabbitMQ
Questions et réponses
Les ventes doivent-elles être comptabilisées en temps réel ou par lots ?
Généralement sous forme d’événements en quasi temps réel, car les chiffres de stock et de ventes sont alors à jour en cours de journée. Certains ERP ou certaines licences rendent les comptabilisations fréquentes coûteuses : la couche peut donc aussi regrouper les événements en synthèses par magasin et par période. Nous choisissons avec vous en fonction des décisions qui exigent des données à jour et de ce que l’ERP traite bien.
Lien vers cette questionComment les totaux de fin de journée sont-ils rapprochés ?
Chaque magasin envoie ses totaux de fin de journée par moyen de paiement et par rayon. La couche les compare aux transactions que l’ERP a reçues pour le même magasin et le même jour. S’ils concordent, la journée est clôturée. Sinon, la revue liste les transactions manquantes ou en trop, afin que votre équipe corrige la cause au lieu de comptabiliser un ajustement.
Lien vers cette questionLes promotions et les changements de prix peuvent-ils être planifiés à l’avance ?
Oui. Chaque changement de prix ou de promotion est envoyé à l’avance, avec la date et les magasins concernés, pour que les caisses basculent au bon moment sans intervention en magasin. La couche enregistre les magasins qui ont confirmé le changement et signale ceux qui ne l’ont pas fait.
Lien vers cette questionComment déployez-vous cette solution sur de nombreux magasins ?
Nous commençons par un pilote dans quelques magasins et comparons chaque jour leurs totaux avec ceux du processus actuel. Une fois les totaux concordants, nous déployons par vagues, à un rythme que votre équipe des opérations magasins peut accompagner. L’ancien processus reste disponible pour chaque magasin jusqu’à ce que son nouveau flux ait fait ses preuves.
Lien vers cette questionAvec quels systèmes de caisse et quels ERP cette architecture fonctionne-t-elle ?
L’architecture fonctionne avec tout système de caisse capable d’exporter ses transactions via une API, des événements ou des fichiers, et avec des ERP comme SAP S/4HANA, Oracle NetSuite, Microsoft Dynamics 365 Business Central et Odoo. Nous confirmons dès le départ les interfaces de votre système de caisse et de votre ERP. La mention d’un produit ne signifie pas un partenariat avec son éditeur.
Lien vers cette questionQui traite les comptabilisations en échec une fois en production ?
C’est convenu avant la mise en production. En général, votre équipe des opérations magasins ou votre équipe financière traite les erreurs métier, comme un article inconnu, depuis une liste de revue, et l’équipe technique traite les incidents du flux lui-même. Nous pouvons assurer ce support technique dans le cadre d’un contrat de suivi, avec un manuel d’exploitation partagé avec votre équipe.
Lien vers cette questionDites-nous ce que vous devez construire ou connecter.
Décrivez les systèmes, le calendrier et les contraintes. Les ingénieurs concernés prennent ensuite le relais.
- Notre équipe vous appellera dans les 24 heures, sur le créneau de votre choix
- Notre équipe est disponible 24 h/24, 7 j/7