Calculateur de stock de sécurité
Avec une consommation maximale de 50 unités par jour sur un délai maximal de 14 jours, contre 30 unités et 10 jours en moyenne, il vous faut 400 unités de stock de sécurité. Quatre chiffres suffisent, sans taux de service ni écart type. Gratuit dans votre navigateur.
- Gratuit
- Fonctionne dans votre navigateur
- Sans inscription
- Vos données restent sur votre appareil
Lancer gratuitement
Exemple résolu
- Utilisation quotidienne maximale
- 50
- Délai de livraison maximal
- 14
- Utilisation quotidienne moyenne
- 30
- Délai de livraison moyen
- 10
- Demande maximale
- 700
- Demande moyenne
- 300
- Stock de sécurité
- 400
Le stock de sécurité est l'inventaire supplémentaire qu'un entrepôt retient afin qu'un pic de demande ou un fournisseur en retard ne vident pas le rayon avant la prochaine réception. L'identité classique moyenne-maximum calcule ce coussin comme consommation quotidienne maximale fois délai maximal, moins consommation quotidienne moyenne fois délai moyen. Planificateurs, acheteurs et étudiants en opérations utilisent ces quatre chiffres lorsqu'ils veulent une quantité transparente plutôt qu'un modèle statistique de z-score qu'ils n'ont pas encore paramétré. Ce calculateur de stock de sécurité accepte les quatre nombres finis non négatifs, renvoie la quantité de coussin dans les mêmes unités que la consommation quotidienne, et rejette une consommation ou un délai négatifs afin que l'identité ne consomme jamais une demande ou un calendrier impossibles.
Ce que mesure le stock de sécurité et l'identité moyenne-maximum
Le stock de sécurité est un coussin planifié au-dessus de la demande attendue pendant le réapprovisionnement, retenu afin qu'une rupture n'intervienne pas lorsque la consommation est élevée ou le fournisseur lent. La méthode moyenne-maximum, enseignée dans les cours de stocks et utilisée en entrepôt lorsque les historiques de consommation et de délai sont courts, n'a besoin ni d'un z-score de niveau de service ni d'un écart-type.
Elle demande quatre grandeurs : la consommation quotidienne la plus haute que vous avez vue ou que vous planifierez, le délai le plus long que vous planifierez, la consommation quotidienne moyenne et le délai moyen. La demande du pire réapprovisionnement plausible est la consommation quotidienne maximale fois le délai maximal. La demande d'un cycle typique est la consommation quotidienne moyenne fois le délai moyen.
Leur différence est les unités extra qui couvrent l'écart entre un mauvais cycle et un cycle moyen, et cette différence est la quantité de stock de sécurité. Un magasin qui culmine à cinquante unités par jour avec un pire délai de quatorze jours, et qui moyenne trente unités par jour avec un délai typique de dix jours, a besoin de quatre cents unités de stock de sécurité, parce que sept cents moins trois cents égale quatre cents.
Une consommation moyenne nulle est autorisée lorsqu'un article est dormant ; le coussin égale alors la consommation maximale fois le délai maximal. Une consommation ou un délai négatifs ne sont pas un chiffre de demande ni de calendrier ; c'est une erreur de données, et ce calculateur les refuse au lieu d'inventer un coussin à partir d'une entrée impossible. Conservez la consommation en unités par jour et le délai en jours afin que le produit soit une quantité en unités.
Mélanger une consommation hebdomadaire avec un délai mesuré en jours est la façon dont un coussin ment en silence. La formule est quatre multiplications et une soustraction afin que corrigés, oracles MRP et cahiers de réapprovisionnement partagent une définition reproductible sans dérive d'arrondi intermédiaire dans le tableur.
Où un calculateur de stock de sécurité gagne sa place
Les personnes qui tapent stock de sécurité dans une boîte de recherche savent déjà qu'elles ont besoin d'une quantité de coussin et veulent les unités extra, pas une leçon qui commence par les systèmes d'inventaire perpétuel contre périodique.
Un éditeur qui se classe sur cette requête brève sert des planificateurs d'entrepôt qui ont une consommation quotidienne de pic, un pire délai, une consommation quotidienne moyenne et un délai moyen ; des étudiants qui doivent remplir la ligne de stock de sécurité d'un devoir d'inventaire ; et des acheteurs qui ont besoin d'un oracle déterministe qui refuse une consommation ou un délai négatifs au lieu de produire en silence un coussin absurde.
Les petits fabricants qui tiennent un cahier de réapprovisionnement veulent le même chiffre max-fois-max moins moyenne-fois-moyenne que les analystes écrivent sur des diapositives, sans erreurs de main lorsque les décimales de consommation changent. Les cours en classe et de certification qui enseignent la méthode moyenne-maximum ont besoin d'un service qui renvoie stock de sécurité, demande maximale et demande moyenne et rien d'autre, afin qu'un correcteur compare à une clé de manuel sans que cet outil prétende faire tourner un moteur MRP complet. Une validation échouée ne consomme pas le solde.
Associez cette capacité à un outil séparé de quantité économique de commande lorsque vous avez besoin de la taille de lot ; gardez cette surface centrée sur les unités extra que les gens veulent dire lorsqu'ils recherchent stock de sécurité.
Cas d’usage
Coussins de réapprovisionnement d'entrepôt
Transformez la consommation quotidienne de pic, le pire délai, la consommation quotidienne moyenne et le délai moyen en une quantité de stock de sécurité avant de lancer le prochain bon de commande.
Contrôles de classe et de devoirs
Laissez les élèves envoyer les quatre entrées moyenne-maximum et vérifier la quantité de coussin contre l'identité du manuel, sans erreurs de signe ni d'unité.
Questions fréquentes
Que se passe-t-il si une entrée est négative ?
La consommation et le délai ne peuvent pas être négatifs, donc l'identité n'est pas facturée et aucun coussin n'est inventé à partir d'un chiffre impossible.
La consommation quotidienne ou le délai peuvent-ils être nuls ?
Oui. Une consommation moyenne nulle est autorisée pour un article dormant ; un délai nul est autorisé pour un réapprovisionnement instantané. Le maximum ne peut toujours pas se situer sous sa moyenne appariée.
Est-ce la formule statistique de stock de sécurité avec z-score ?
Non. Cet outil met en œuvre l'identité moyenne-maximum, pas z × σ × √L. Il ne prend pas un niveau de service, un écart-type de la demande ni un z-score.
Comment calculer le stock de sécurité avec la méthode du maximum et de la moyenne ?
Multipliez la consommation quotidienne maximale par le délai maximal, puis retranchez la consommation moyenne multipliée par le délai moyen. Avec 50 unités sur 14 jours contre 30 sur 10, cela fait 700 moins 300, soit 400 unités.
Pourquoi la consommation et le délai doivent-ils utiliser la même unité de temps ?
Parce que des unités par jour multipliées par des jours donnent des unités. Mélanger une consommation hebdomadaire et un délai en jours produit un stock de sécurité plausible en apparence, mais faux.
Outils associés
Pour les développeurs — accès API
Tout sur cette page est disponible par programmation. Cette section s'adresse aux équipes qui veulent l'intégrer à leurs systèmes ; les autres peuvent simplement utiliser l'outil ci-dessus.
Endpoint
Authentification par jeton Bearer : un seul POST met la tâche en file d’attente, et le résultat vous parvient par webhook ou lien signé.
Appeler depuis votre stack
curl -X POST https://api.kit.forhosting.com/fin/safety-stock \
-H "Authorization: Bearer $KIT_KEY" \
-H "Content-Type: application/json" \
-d '{"max_daily_usage":50,"max_lead_time":14,"avg_daily_usage":30,"avg_lead_time":10}'const res = await fetch("https://api.kit.forhosting.com/fin/safety-stock", {
method: "POST",
headers: {
"Authorization": `Bearer ${process.env.KIT_KEY}`,
"Content-Type": "application/json"
},
body: JSON.stringify({
"max_daily_usage": 50,
"max_lead_time": 14,
"avg_daily_usage": 30,
"avg_lead_time": 10
})
});
const { task_id } = await res.json();import os, requests
res = requests.post(
"https://api.kit.forhosting.com/fin/safety-stock",
headers={"Authorization": f"Bearer {os.environ['KIT_KEY']}"},
json={
"max_daily_usage": 50,
"max_lead_time": 14,
"avg_daily_usage": 30,
"avg_lead_time": 10
},
)
task_id = res.json()["task_id"]<?php
$res = file_get_contents("https://api.kit.forhosting.com/fin/safety-stock", false, stream_context_create([
"http" => [
"method" => "POST",
"header" => "Authorization: Bearer " . getenv("KIT_KEY") . "\r\nContent-Type: application/json",
"content" => '{"max_daily_usage":50,"max_lead_time":14,"avg_daily_usage":30,"avg_lead_time":10}',
],
]));
$task = json_decode($res, true);body := bytes.NewBufferString(`{"max_daily_usage":50,"max_lead_time":14,"avg_daily_usage":30,"avg_lead_time":10}`)
req, _ := http.NewRequest("POST", "https://api.kit.forhosting.com/fin/safety-stock", body)
req.Header.Set("Authorization", "Bearer "+os.Getenv("KIT_KEY"))
req.Header.Set("Content-Type", "application/json")
res, _ := http.DefaultClient.Do(req)Exemple de requête
{
"max_daily_usage": 50,
"max_lead_time": 14,
"avg_daily_usage": 30,
"avg_lead_time": 10
}Exemple de réponse
{
"task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
"type": "fin.safety_stock",
"status": "queued",
"_links": {
"result": "/tasks/tsk_…/result"
}
}L’API est asynchrone : chaque appel renvoie un task_id immédiatement, puis vous interrogez l’état à raison d’une requête par seconde.
Tarifs
Le prix est publié, sans tokens ni crédits. Une tâche qui échoue n’est pas facturée.
Erreurs
| HTTP | Code | Signification |
|---|---|---|
401 | unauthorized | Clé API absente ou invalide : vérifiez l’en-tête Authorization. |
402 | insufficient_balance | Solde insuffisant : rechargez votre compte pour lancer cette tâche. |
404 | unknown_type | Type de tâche inconnu : vérifiez le champ type de votre requête. |
429 | rate_limited | Trop de requêtes : ralentissez la cadence, puis réessayez. |
Notes techniques
Les appels réussis sont facturés à $0.002 ; une entrée invalide n'est pas débitée.
Contrat d'entrée, forme de la réponse et validation
Un maximum qui se situe sous sa moyenne appariée est également rejeté, parce que ce couple n'est plus une histoire de maximum contre moyenne. Exemple : cinquante unités par jour avec un pire délai de quatorze jours, trente unités par jour avec un délai typique de dix jours, donnent demande maximale sept cents, demande moyenne trois cents et stock de sécurité quatre cents. Préférez les nombres nus aux chaînes formatées ; les séparateurs de milliers et libellés d'unité en fin de chaîne ne sont pas analysés. Cet outil ne prend pas un z-score, un écart-type de la demande ni un niveau de service cible, et n'émet pas un point de commande ; intégrez cela dans une identité séparée si vous en avez besoin. Envoyez un corps JSON avec quatre nombres finis obligatoires dans des unités cohérentes : consommation quotidienne en unités par jour, délai en jours. max_daily_usage est la demande quotidienne la plus haute attendue et doit être supérieur ou égal à zéro ; les alias maximum_daily_usage, max_usage et maximum_usage sont acceptés afin qu'un export du planificateur n'ait pas besoin d'une étape de renommage. max_lead_time est le réapprovisionnement le plus long attendu en jours et doit aussi être non négatif ; les alias maximum_lead_time et max_lt sont acceptés. avg_daily_usage est la demande quotidienne moyenne et doit être non négatif et pas supérieur à max_daily_usage ; les alias average_daily_usage, avg_usage et average_usage sont acceptés. avg_lead_time est le réapprovisionnement moyen en jours et doit être non négatif et pas supérieur à max_lead_time ; les alias average_lead_time et avg_lt sont acceptés. Chaque champ peut arriver comme nombre JSON ou comme chaîne numérique qui correspond à un motif décimal fini strict. Champs manquants, chaînes vides, valeurs non finies ou toute consommation ou délai négatifs échouent avec invalid_input en nommant le champ et ne sont pas facturés. En cas de succès le corps répète les quatre entrées arrondies, renvoie max_demand comme consommation quotidienne maximale fois délai maximal, renvoie avg_demand comme consommation quotidienne moyenne fois délai moyen, renvoie safety_stock comme demande maximale moins demande moyenne, et inclut une chaîne de formule qui reformule l'identité afin qu'un tableau de bord imprime la définition à côté du nombre. Le prix d'un élément réussi est un $0.002 forfaitaire.
Où un calculateur de stock de sécurité gagne sa place
Parce que l'implémentation est du code analytique parse de tier A, chaque appel réussi reste bon marché à $0.002 sans jetons de modèle et sans réseau sortant. Gardez les requêtes petites, figez safety_stock arrondi dans les tests, et vous obtenez un coussin reproductible pour devoirs, générateurs d'examen et cahiers de réapprovisionnement légers sans dresser un paquet statistique d'inventaire.
Cas d'intégration
Cahiers MRP et de réapprovisionnement
Appelez un oracle déterministe depuis un script de clôture ou de planification afin que les unités extra qui couvrent un mauvais cycle coïncident avec le widget de la page.
Questions techniques
Comment calcule-t-on le stock de sécurité à partir de la consommation et du délai ?
Envoyez des nombres finis non négatifs max_daily_usage, max_lead_time, avg_daily_usage et avg_lead_time. L'API renvoie safety_stock = (max_daily_usage × max_lead_time) − (avg_daily_usage × avg_lead_time).
Combien coûte le calculateur de stock de sécurité ?
L'outil du navigateur est gratuit. Les requêtes API utilisent un solde KIT prépayé à $0.002 par appel réussi ; une entrée invalide n'est pas facturée.