Les ventes POS qui ne correspondent pas à votre système de stocks : les deux causes principales et comment les réconcilier

Identifiez d’abord lequel des deux décalages POS-stocks vous concerne

Lorsque votre système de point de vente et votre plateforme de stocks ne s’accordent pas sur ce que vous avez vendu — lorsque vos ventes POS ne correspondent pas à votre inventaire — la cause n’est presque jamais aléatoire. Dans la quasi-totalité des cas, il s’agit de l’une de deux choses : les ventes ont commencé à affluer avant que vos recettes aient été mappées, ou une modification ultérieure du POS a discrètement rompu un mappage qui fonctionnait. Identifiez lequel des deux s’applique avant de corriger quoi que ce soit.

Cette seule question — le décalage existait-il dès le premier jour, ou est-il apparu après le lancement ? — divise presque tous les cas de façon nette, parce que les deux causes nécessitent des corrections opposées. Un manque dès le premier jour signifie que les liens n’ont jamais été terminés. Une dérive qui apparaît des mois plus tard signifie que quelque chose a changé côté POS et que le côté stocks n’en a jamais été informé. Sans diagnostic, un décalage de chiffre d’affaires peut rester non résolu pendant quatre mois et transformer un tableau de bord pour lequel les opérateurs ont payé en un tableau de bord qu’ils cessent d’ouvrir. Commencez donc par l’arbre de décision ci-dessous, puis accédez à la section correspondante.

Quand les ventes commencent à affluer avant que vos articles soient mappés

C’est l’échec de réconciliation le plus courant à l’Onboarding. Le flux de ventes est activé pour respecter une date de lancement, mais le mappage des recettes et des articles de menu n’est pas encore terminé. Chaque commande pour un article non mappé atterrit quand même dans le système en tant que chiffre d’affaires, mais comme cet article de menu n’est pas lié à une recette, aucun ingrédient n’est déduit. Les ventes semblent à peu près correctes tandis que les stocks cessent discrètement de bouger, si bien que l’utilisation théorique et l’utilisation réelle divergent et que vos chiffres de coût matière les suivent dans leur chute.

La correction consiste à terminer les liens, pas à réimporter les données. Chaque article de menu que votre POS peut vendre doit pointer vers la recette qu’il consomme, de sorte qu’une vente déduit les ingrédients corrects, modificateurs inclus. La liaison recette et article de menu de Supy est ce qui comble cet écart : liez chaque article vendu à sa recette une fois, et la déduction commence à s’effectuer dès qu’une commande arrive. Faites cela pour l’ensemble du menu avant de vous fier à un seul rapport d’écart, et effectuez un nouveau comptage afin que le système dispose d’un point de départ précis pour mesurer.

Quand une modification POS n’atteint jamais les stocks

La deuxième cause est différente parce que tout se réconciliait auparavant. Puis quelqu’un côté POS renomme un centre de revenus, ajoute un nouveau PLU pour un article saisonnier, ou divise un article de menu en deux. Aucune de ces modifications n’est incorrecte en soi, mais le côté stocks attend toujours les anciens noms, si bien que les articles modifiés arrivent désormais sans mappage et que les chiffres se séparent à nouveau. Personne n’a intentionnellement cassé quoi que ce soit ; les deux systèmes ont simplement perdu leur synchronisation.

Réconcilier cela signifie remapper ce qui a bougé, puis le confirmer. L’écran Intégrations affiche vos importations de ventes entrantes, de sorte que vous pouvez filtrer les articles arrivés sans mappage et corriger exactement ceux-là plutôt que de tout reconstruire. Pour les fournisseurs utilisant des centres de revenus, vous pouvez mapper plusieurs centres au sein d’un même site vers un seul emplacement de stockage, ce qui permet de capturer un centre renommé ou nouvellement ajouté. Après avoir remappé, déclenchez une resynchronisation manuelle et vérifiez l’historique des importations pour confirmer que les tickets précédemment non mappés arrivent désormais correctement.

La vérification que tout le monde oublie : votre intégration circule-t-elle vraiment dans les deux sens ?

Avant d’accuser un mappage quelconque, confirmez que les ventes arrivent bien. Certaines connexions appelées « intégration POS » n’exportent que les données hors du POS ; elles n’écrivent jamais les ventes en retour dans les stocks. Si c’est votre cas, chaque ticket doit être téléchargé manuellement et le flux automatique que vous attendiez n’existe pas — aucun remappage ne pourra jamais le réconcilier. C’est le piège que les opérateurs ne découvrent qu’après le lancement, lorsqu’ils réalisent que le flux en direct promis était unidirectionnel dès le départ.

Confirmez d’abord la direction : sur une semaine normale, le nombre d’importations de ventes correspond-il à peu près aux tickets enregistrés par votre POS ? S’il affiche zéro alors que le POS montre plus de mille tickets, vous avez un flux unidirectionnel, pas un problème de mappage. La solution est une véritable connexion bidirectionnelle — Supy se connecte à plus de 75 intégrations sur les principales plateformes POS — et là où un POS régional n’a aucun connecteur natif, la réponse honnête provisoire est une importation gérée planifiée, pas la promesse d’une synchronisation en temps réel instantanée. Si vous souhaitez un contexte plus large, ces décalages ne représentent qu’une partie des lacunes de qualité des données POS qui faussent discrètement les stocks. Vérifiez la direction avant de passer un après-midi à revoir des mappages qui étaient corrects depuis le début.

Réconciliez dans cet ordre

Travaillez les trois vérifications de l’extérieur vers l’intérieur, et arrêtez-vous à la première qui échoue. Premièrement, confirmez que le flux est bidirectionnel — si les ventes n’importent jamais, corrigez la connexion avant tout. Deuxièmement, si le décalage existait dès le premier jour, terminez les liens recette-article de menu sur l’ensemble du menu et effectuez un nouveau comptage pour un point de départ propre. Troisièmement, si la réconciliation fonctionnait et a dérié ensuite, identifiez la récente modification POS, remappez l’article ou le centre de revenus concerné, et resynchronisez. Identifiez la branche dans laquelle vous vous trouvez, faites le seul mouvement qui lui correspond, et vérifiez vos achats dans l’historique des importations avant de faire confiance au tableau de bord à nouveau.