Réapprovisionnement

Chainez deux skills pour que la réorganisation se termine dans les livres plutôt que dans un email oublié : inventory-planner décide ce qu'il faut acheter, ap-processor prépare ce que cela coûtera.

L'écart que cela comble est petit et onéreux. La commande est déterminée, le bon de commande est rédigé, l'email est envoyé — et ensuite rien n'est enregistré nulle part, alors quand la facture arrive six semaines plus tard personne ne peut dire si le prix ou la quantité était juste.

Étape 1 — Déterminer ce qu'il faut acheter (inventory-planner)

Invoquez inventory-planner.

Entrées : historique des ventes et stock disponible depuis Shopify, Square ou NetSuite, ou un CSV téléchargé des deux.
Sorties : vélocité 7 jours et 28 jours par article, dates de rupture conservatrices, un réapprovisionnement dimensionné 60 jours avec coûts en dollars, et une liste distincte des articles à rotation lente.

inventory-planner est propriétaire de tous les calculs — les deux fenêtres de vélocité, la gestion de la distorsion, la comparaison des délais, la règle de saisonnalité. Ne refaites aucun de ces calculs ici.

Deux de ses règles méritent d'être nommées dans la chaîne :

Les articles à vélocité zéro ne sont jamais des candidats au réapprovisionnement. Ils apparaissent sous forme d'articles à rotation lente avec la trésorerie immobilisée. Pas de ventes signifie arrêter les achats, non acheter plus.
Une période de rupture de stock n'est pas une demande zéro. C'est une demande réprimée, et la traiter comme zéro commande l'article insuffisamment à jamais.

Portail — la liste d'achat. Affichez le total en dollars et le nombre d'articles sur le point de rupture avant que quoi que ce soit soit rédigé. Le propriétaire approuve la liste, la réduit ou change les quantités. Chaque ligne porte sa vélocité, ses jours de couverture, son délai, sa quantité et son coût, donc la décision prend une minute au lieu de une reconstruction.

Étape 2 — Rédiger le bon de commande et l'email au fournisseur (inventory-planner)

Pour les lignes approuvées, inventory-planner rédige un bon de commande par fournisseur et l'email qui l'accompagne, écrit avec la voix du propriétaire.

Portail — les deux attendent un oui explicite, séparément de l'étape 1. Approuver la liste d'achat signifie s'accorder sur ce qu'il faut commander. Envoyer le bon de commande signifie engager l'argent et dépenser la relation fournisseur. Indiquez le fournisseur, les articles et le total avant de demander.

Sans connecteur de courrier (Gmail ou Microsoft 365) connecté, le bon de commande et l'email sont des fichiers que le propriétaire envoie à la main. C'est un résultat complet.

Étape 3 — Laisser un enregistrement que la future facture peut rapprocher

Deux choses différentes se produisent ici, et il importe quel skill possède lequel.

inventory-planner conserve le bon de commande lui-même. Le bon de commande approuvé est son document — fournisseur, articles, quantités, prix, date prévue. Il est sauvegardé et remis au propriétaire à l'étape 2, et c'est l'enregistrement de ce qui a été commandé.

ap-processor prend la mémorisation codée, pas le bon de commande. Donnez-lui le fournisseur, le numéro du bon de commande, le total, la date prévue et le compte, la classe et le projet auxquels appartient la dépense. ap-processor ne crée pas de bons de commande dans le grand livre — il les lit quand une facture arrive, pour exécuter le rapprochement tripartite de la facture par rapport au bon de commande par rapport au reçu de réception. Ce dont il a besoin de cette étape est un enregistrement codé situé où ce rapprochement le cherchera.

Entrées : fournisseur, numéro du bon de commande, total, date prévue et codification.
Sorties : une mémorisation codée classée par fournisseur, donc quand la facture arrive dans six semaines le prix et la quantité peuvent être vérifiés par rapport à ce qui a été réellement approuvé.

Portail — l'approbation de la codification. C'est le propre portail de ap-processor et il tient ici. Rien n'est écrit au grand livre jusqu'à ce que le propriétaire dise oui, et rien n'arrive en tant que facture et jamais en tant que paiement. Aucun argent ne bouge dans cette commande du tout — payer ce qui arrive est /pay-the-bills.

Si un code est incertain sur un nouveau fournisseur, ap-processor demande plutôt que de deviner. Une question maintenant bat un codage erroné pendant un an.

Sans connecteur de grand livre, la mémorisation codée sort sous forme de fichier d'importation et d'un résumé aux côtés du bon de commande. Le rapprochement tripartite se produit toujours plus tard, à la main, par rapport à un enregistrement qui existe.

Étape 4 — En faire un rythme

Ray Okonkwo gère Okonkwo Mechanical à partir d'une étagère de pièces qu'il vérifie quand quelque chose manque, ce qui est toujours trop tard. Avec Google Calendar connecté, offrez une fois — après un réapprovisionnement que le propriétaire a trouvé utile — de mettre un bloc récurrent sur le calendrier pour la décision de réapprovisionnement.

Cela fonctionne bien mieux comme un rythme que comme un forage d'urgence. Offrez-le une fois. Sur un non ou sur le silence, abandonnez.

Chemin de secours

Un CSV de ventes plus un décompte de stock est une entrée entièrement supportée. De nombreuses entreprises comptent sur un presse-papiers, et c'est une donnée légitime. La vélocité, les dates de rupture, le dimensionnement du réapprovisionnement, le bon de commande et l'email au fournisseur sortent tous de la même manière. L'entrée des livres devient un fichier d'importation.

Ce qu'il ne faut pas faire

N'envoyez pas un bon de commande ou un email au fournisseur sans approbation. L'un dépense l'argent, l'autre dépense la bonne volonté.
Ne traitez pas l'approbation de la liste d'achat comme l'approbation d'envoi. Deux portails, deux décisions.
Ne réapprovisionnez pas un article à vélocité zéro.
Ne dimensionnez pas un réapprovisionnement sans soustraire ce qui est déjà en cours de livraison. Double-commander un article à rotation lente enterre la trésorerie pendant des années.
N'inventez pas une vélocité, un délai ou une date de rupture. Trop peu d'historique est signalé par SKU.
Ne payez rien ici. Les bons de commande sont préparés, pas payés. Le paiement est /pay-the-bills.
Ne signalez pas les unités sans dollars. Le propriétaire décide de la trésorerie, pas des pièces.

Sortie

Livrez le plan de réapprovisionnement selon la préférence de sortie stockée du propriétaire — ne prenez jamais par défaut un fichier markdown. Vérifiez le bloc ## Business context préférence Output preference (règle de guide de style partagé, ../../shared/artifact-style.md) :

Artefact visuel (par défaut) : restituez le plan comme une page HTML au style maison — total engagé comme tuile de statistique principale en dollars, chaque SKU une ligne avec vélocité, date de rupture et taille de réapprovisionnement en tabular-nums, et une pastille sur tout ce qui est déjà en cours de livraison. Les documents de bon de commande et tout fichier d'importation vont de pair en tant que fichiers de travail, pas livrerables secondaires.
Préférence docx / md / notion / canva : livrez le même contenu sous cette forme — un fichier DOCX ou markdown, une page Notion créée via le connecteur (destination nommée, jamais en écrasant), ou un Canva Doc créé via le connecteur Canva (une nouvelle conception à chaque exécution, nommée avec la date ; les tableaux deviennent des listes) ; revenez à l'artefact visuel si Notion ou Canva n'est pas connecté — et dites pourquoi.
Meilleur pour le skill : utilisez l'artefact visuel — cette sortie est une décision d'achat, pas de la prose.

Après l'exécution

Les bons de commande sont dehors et un enregistrement codé attend les factures pour les rapprocher. Quand ces factures arrivent, l'étape naturelle suivante est « payer les factures » — /pay-the-bills exécute le rapprochement, la vérification de trésorerie et le portail de paiement. Également à proximité : « prévisions de trésorerie » (cash-flow-snapshot) pour voir ce que les commandes engagées font aux 60 jours suivants, et « clôturer le mois » (/close-month) quand la période se termine. Offrez au maximum trois, et passer toute offre que le propriétaire a déjà déclinée cette session.

Utiliser un outil qui n'est pas listé

Les connecteurs nommés dans ce skill sont les chemins testés, pas un mur. Si le propriétaire veut que ce flux utilise un outil qui n'est pas connecté ou listé, offrez build-connector — il vérifie d'abord le répertoire des connecteurs et se connecte via Zapier sinon, jamais en construisant à la main contre une API brute. Une fois la connexion établie, l'outil rejoint ce skill comme tout autre connecteur optionnel, sous les mêmes portails d'approbation.

restock