Mikro Farm vend de l'aliment pour bétail, des médicaments vétérinaires, des semences, des pesticides et des engrais — au kilo, au sac, au container. Le propriétaire avait testé tous les POS du marché : aucun ne séparait l'entrepôt de la boutique, aucun ne recalculait les prix quand les fournisseurs bougeaient, et aucun n'indiquait au client ce qui était en rayon avant qu'il fasse une heure de route pour rien. On a donc construit celui qui le fait.
Avant d'écrire la moindre ligne de code, le propriétaire nous a raconté le même samedi cinq fois de suite. Voici les plaies qui revenaient sans cesse.
Le magasin est loin de la plupart des éleveurs. Quand ce qu'ils sont venus chercher est en rupture, le déplacement est perdu — et la confiance aussi.
Les clients arrivent dans une boutique bondée sans avoir préparé leur liste — ils lisent les étiquettes en rayon pendant que dix autres personnes font la queue. Le temps du personnel en prend un coup.
L'entrepôt et la boutique sont physiquement séparés, mais chaque POS du marché les fusionne. L'écran affiche 40 sacs, le rayon en a 3 et le dépôt 37 — et personne ne le sait jusqu'à ce qu'un client pose la question.
Chaque vendredi, quelqu'un compte. À la main. À l'œil. Les erreurs remontent deux semaines plus tard, quand une commande arrive en dessous de ce dont ils avaient vraiment besoin.
Ce n'est pas un sac à la fois. Une commande fournisseur, c'est un container d'aliment. Trop peu — rupture pendant un mois. Trop — capital immobilisé, péremption qui approche sur les médicaments et les semences.
La première chose que nous avons construite n'est pas pour le personnel. C'est un catalogue public, pédagogique, que le client ouvre avant de monter en voiture. Chaque produit affiche le stock en temps réel par site, des notes de dosage pour les médicaments et les semences, et un bouton « réserver / commander » pour que le sac soit mis de côté à l'arrivée.
Le problème en rayon se résout de lui-même : les clients qui ont déjà choisi chez eux n'ont pas besoin de lire des étiquettes dans la file. Le problème de l'heure de route aussi : si c'est en rouge, ils ne bougent pas.
Chaque article a un enregistrement maître unique, mais deux lignes de stock — une pour l'entrepôt, une pour la surface de vente. Le coût unitaire (HPP) est également suivi par site, de sorte qu'un transfert emporte son coût tel quel et que les rapports de marge restent fiables.
Les ventes sont d'abord déduites de Toko. Si Toko vient à manquer, le système bascule automatiquement sur Gudang — mais enregistre le prélèvement, afin que le calcul de réapprovisionnement sache que c'est le rayon qui doit être réalimenté, pas seulement le dépôt.
Les alertes de stock bas fonctionnent par site, pas en agrégat. L'onglet « Quoi commander » fait la même logique qu'on effectuait à la main le vendredi soir — sauf qu'il ne se trompe jamais et affiche les articles par urgence, pas par ordre alphabétique.
Les catégories avec suivi de péremption (médicaments, semences, pesticides) bénéficient d'un second passage : tout ce qui expire dans moins de 60 jours apparaît dans le même onglet pour être vendu ou déplacé avant d'être sans valeur.
| Article | Site | En stock | Min | Action |
|---|---|---|---|---|
| Pakan Ayam Petelur 50kg | Toko | 3 | 10 | Pindah |
| Pupuk Urea 50kg | Gudang | 82 | 120 | Réappro |
| Vit. B-Complex 1L (exp 09/26) | Toko | 2 | 4 | Vendre d'abord |
| Decis 100ml | Gudang | 26 | 50 | Réappro |
Pour un détaillant au sac, « commander plus quand le stock baisse » suffit. Pour Mikro Farm, la question est combien de sacs remplissent un container de 20 pieds sans dépasser six mois de demande. Le réapprovisionnement n'est donc pas un bouton — c'est une calculatrice que le propriétaire peut ajuster.
Le système agrège les 12 dernières semaines de ventes, les multiplie par le délai fournisseur, et arrondit le résultat à la MOQ fournisseur et à la prochaine ligne de remplissage du container. Le propriétaire voit le calcul, pas seulement la réponse, et peut le régler avant d'envoyer.
Chaque réception recalcule le coût unitaire moyen pondéré (HPP) par site. Si le nouveau HPP franchit la plage de marge définie par le propriétaire, le prix de vente se met à jour automatiquement et est consigné — aussi bien dans le POS que dans le catalogue client.
Le propriétaire dispose d'un fil unique de tous les mouvements : ce qui a changé, pourquoi, et de combien. Fini le « attends, pourquoi la marge a chuté ce mois-ci ».
On n'est pas partis de zéro. Le squelette du POS venait de notre propre modèle Floural — ventes, dépenses, présences, paiements. Le travail sur mesure portait sur l'inventaire : le séparer, le coûter, et le rendre visible.
Modèle d'inventaire sur papier avant la moindre ligne de code. Cartographie de chaque catégorie, chaque unité (kg / sak / litre / pcs), chaque MOQ fournisseur, chaque SKU avec suivi de péremption.
Construction de la jonction inventory_items + inventory_stock (un maître, quantité et HPP par site). Coût moyen pondéré câblé sur chaque réception. Flux de transfert (« Pindah ke Toko ») livré la même semaine.
Les ventes touchent d'abord Toko, basculent sur Gudang, capturent le HPP sur la ligne de commande. Alertes de stock bas et onglet « Quoi commander » pilotés par des jointures en temps réel.
PWA client lisant la même table de stock que le POS alimente. Calculateur de réappro avec arrondi au container. Fil de prix lu sur les événements de réception.
Pendant une semaine complète, chaque comptage a été fait à la fois sur le système et sur le carnet. Réconciliation à la fin. Écarts → bugs → correction → remise.
Pas de chiffres fabriqués mois par mois — le système est récent. Voici les flux de travail qui sont passés du papier à l'écran.
Gudang et Toko ont leur propre quantité et HPP. Les ventes se répercutent proprement. Les transferts portent leur coût.
Chaque réception recalcule le HPP et réajuste le prix de vente selon la plage de marge du propriétaire. Le catalogue le reflète instantanément.
Un onglet, trié par urgence, incluant les articles proches de la péremption. Remplace la ronde du vendredi au carnet.
Le catalogue public lit la même table que le POS alimente. Sans staging, sans délai de cache.
Les suggestions de réappro s'arrondissent à la MOQ et au remplissage container. Le propriétaire voit le calcul, peut l'ajuster, puis envoie.
Remplace toutes les tentatives de POS du Play Store qui ne convenaient pas. Entièrement détenu. Hébergé sur un petit VPS.
Tourne sur la tablette Android du personnel à la caisse. Offline-first via une file de synchronisation — la caisse continue d'enregistrer les ventes quand le wi-fi clignote, et rejoue à la reconnexion. Mises à jour OTA pour déployer des correctifs JS sans réinstallation.
Un fichier par domaine, routage ?action=, PDO brut. Auth JWT. Journal d'audit sur chaque mutation pour retracer tout changement de stock jusqu'à une personne et un instant.
Appli navigateur publique. Lit la même table inventory_stock que le POS alimente — sans synchronisation séparée. Pédagogie d'abord : chaque produit porte une note « pourquoi ce produit » pour le contexte de vente croisée.
Une ligne inventory_items par SKU. Deux lignes inventory_stock (Gudang, Toko) indexées par (item_id, location). Chaque réception déclenche un HPP moyen pondéré et un éventuel recalcul du prix de vente.
Appel de cadrage gratuit. On vous dit la solution la moins chère qui convient vraiment.