Des photos WhatsApp à un carnet de commandes en temps réel : un ERP et une application terrain hors ligne pour les distributeurs

La plupart des distributeurs que nous rencontrons fonctionnent avec trois outils : Tally (le logiciel de comptabilité le plus répandu en Inde) pour les factures, Excel pour le stock et les impayés, et WhatsApp pour tout le reste. Un commercial photographie un bon de commande dans une boutique, l’envoie au bureau, quelqu’un le saisit dans Tally le lendemain matin, et c’est seulement là qu’on s’aperçoit que la boutique doit déjà ₹50,000 et n’a rien payé depuis deux mois. Le stock, c’est « environ 20 cartons », jusqu’au jour où ce n’est plus vrai.

Nous avons conçu AIVCJ ERP pour montrer ce qui remplace cette boucle : une application terrain qui fonctionne sans réseau, un carnet de commandes qui vérifie l’encours avant toute expédition, un stock suivi par lot et par date de péremption, des factures GST en un clic, et un moyen pour le dirigeant de poser des questions en langage courant. Elle tourne sur un distributeur de produits de grande consommation fictif : Northwind Distribution, avec 3 entrepôts (Nagpur, Indore, Hubli), 396 détaillants, 8 commerciaux terrain, 123 SKU et 100 jours d’historique. Chaque visiteur dispose de sa propre copie.

La commande, de la boutique à la facture

1. En boutique — le commercial ouvre la tournée du jour (le « beat », son circuit de vente quotidien) dans l’application Northwind Sales, voit la situation de crédit de la boutique, ajoute des cartons et passe la commande. Pas de réseau ? La commande est enregistrée sur le téléphone et marquée « en attente de réseau ».
2. Synchronisation — dès que le téléphone retrouve une connexion, la file d’attente s’envoie d’elle-même. L’ERP valorise chaque ligne selon son propre tarif et effectue le contrôle d’encours dans le code.
3. Blocage pour encours — si la boutique dépasse sa limite ou si une facture a dépassé son échéance, la commande est bloquée avec le motif exact (« Encours ₹49,917 + cette commande ₹12,147 = ₹62,064, au-delà de la limite de ₹50,000 ; la facture NW/26-27/000993 date de 74 jours »). Le dirigeant la débloque en indiquant un motif, ou l’annule. L’application du commercial se met à jour d’elle-même.
4. Préparation et facture — l’entrepôt prélève par lot selon la règle FEFO (premier périmé, premier sorti), en écartant tout ce qui expire dans les 15 jours, et la facture fiscale GST est générée avec les codes HSN, les numéros de lot, la CGST + SGST ou l’IGST et le montant en toutes lettres.
5. Réapprovisionnement — rythme de vente × délai fournisseur signale ce qui va manquer, regroupé par fournisseur et par entrepôt ; un clic émet le bon de commande, et la réception de marchandises ajoute les nouveaux lots au stock.

Hors ligne d’abord, et jamais deux fois

En Inde, la vente terrain se fait dans des godowns (entrepôts locaux), des sous-sols et des petites villes. Une application qui a besoin du réseau pour enregistrer une commande perd des commandes. L’application Northwind Sales (développée avec Expo / React Native) écrit donc chaque commande et chaque encaissement d’abord sur le téléphone — SQLite sous Android — et les envoie plus tard.

La difficulté du hors-ligne n’est pas le stockage, ce sont les nouvelles tentatives. Un commercial appuie sur « passer la commande », la requête atteint le serveur, la réponse se perd dans une zone blanche, et le téléphone réessaie. Sans précaution, cela fait deux commandes. Chaque élément mis en file par l’application porte son propre identifiant, et l’ERP renvoie la commande existante lorsqu’il voit un identifiant deux fois. Les prix et l’encours affichés sur le téléphone ne sont qu’un aperçu : l’ERP revalorise et revérifie tout à la réception, si bien qu’un téléphone non à jour ne peut jamais vendre à un ancien prix ni au-delà d’une limite.

Le stock est affecté au moment de la préparation en entrepôt, pas lors de la prise de commande : deux commerciaux peuvent vendre les 20 derniers cartons en même temps sans qu’aucun n’ait de réseau. La seconde préparation est alors bloquée avec un manquant clair (« il manque 850 »), et le dirigeant transfère du stock ou émet un bon de commande (PO). Rien n’est survendu et aucun lot ne passe en négatif.

Le contrôle d’encours dans le code, pas dans le modèle

Les décisions de crédit sont des décisions d’argent : aucune IA n’intervient. Un petit module de règles décide : l’exposition correspond aux factures impayées plus les commandes ouvertes pas encore facturées plus cette commande, comparée à la limite de la boutique ; et toute facture impayée plus ancienne que les conditions de paiement de la boutique bloque la commande. (Nous avons découvert l’oubli des commandes ouvertes pendant les tests : une seconde commande de la même boutique ignorait la première, pourtant bloquée. C’est corrigé et couvert désormais par son propre test unitaire.) Débloquer une commande exige toujours un motif, et chaque déblocage, changement de limite et ajustement de stock est inscrit dans un journal d’audit.

Interrogez vos données — avec des garde-fous

Le seul endroit où nous utilisons l’IA, c’est quand le dirigeant pose des questions : « Quels détaillants de Nagpur ont plus de 60 jours de retard ? », « Marge brute par catégorie ce mois-ci ». Claude Haiku 4.5 rédige une requête SQL ; l’ERP décide ensuite si elle peut s’exécuter :

• la requête s’exécute dans une transaction en lecture seule, uniquement sur 14 vues de la copie propre au visiteur (montants en roupies, aucun numéro de téléphone) ;
• un contrôle dans le code rejette tout ce qui n’est pas un unique SELECT, ou qui touche aux tables système, aux paramètres ou à quoi que ce soit en dehors de ces vues — testé sur 28 cas autorisés et d’attaque ;
• délai maximal de 5 secondes, plafond de 200 lignes, 15 questions par visiteur et par jour ;
• la requête exacte est affichée avec chaque réponse, sous forme de tableau et de graphique quand la forme des données s’y prête.

Les questions auxquelles les données ne peuvent pas répondre — le prix d’un concurrent, les ventes du mois prochain, « supprime toutes les commandes annulées » — reçoivent une réponse courte indiquant ce à quoi l’outil peut répondre à la place. Une question coûte environ $0.002.

Ce que nous avons mesuré

Deux remarques par souci d’honnêteté. D’abord, les réponses sont notées dans le code, pas par un juge IA : la requête du modèle et une requête correcte écrite à la main s’exécutent sur les mêmes données, et les résultats sont comparés (mêmes lignes, mêmes chiffres à ±1% près). Ensuite, les trois échecs du jeu à l’aveugle étaient bien réels : une liste a été tronquée à 50 lignes, une série est sortie de la plus récente à la plus ancienne, et une question sur le prix d’un concurrent a été cherchée dans notre propre catalogue au lieu d’être déclinée. Nous avons corrigé le premier et le troisième après l’exécution ; le 17/20 reste tel que mesuré. La première exécution scénarisée a aussi révélé quatre erreurs dans nos requêtes de référence — des boutiques portant le même nom étaient fusionnées — c’est pourquoi le jeu de données comporte désormais des noms de boutique uniques.

Ce qu’il faut pour connecter Tally

La plupart des distributeurs ne remplaceront pas Tally du jour au lendemain, et ils n’en ont pas besoin. La voie pragmatique est une synchronisation nocturne ou horaire : les données de base (comptes, articles, godowns) et les factures en attente arrivent par l’interface XML de Tally, les commandes de vente y retournent sous forme d’écritures (vouchers) une fois facturées, et l’ERP conserve ce que Tally ne gère pas — tournées (beats), commandes terrain, stock par lot, blocages et piste d’audit. La démo n’appelle ni Tally ni le portail GST ; les champs de facture électronique (IRN) et d’e-way bill (document de transport électronique) sont prêts pour cette étape.

Essayez : ouvrez erp.demos.aivcj.com, prenez une commande pour Shree Ganesh Kirana dans l’application de vente, regardez-la passer en blocage pour encours, débloquez-la, préparez-la et ouvrez la facture. Puis passez l’application en « pas de réseau » et recommencez.