Coût total du lot de recette

Une validation en échec — surtout des portions nulles ou négatives — renvoie invalid_input et n’est pas facturée.

Comment le coût du lot se construit à partir de la quantité et du coût unitaire

Le total d’un lot de recette n’est pas un chiffre unique saisi de mémoire ; c’est la somme de chaque ligne d’ingrédient du service complet. Les libellés name optionnels n’affectent pas le calcul ; ils rendent seulement la liste des lignes lisible lorsque vous affichez les résultats à côté d’une liste de courses ou d’une fiche menu. Les listes vides et plus de deux cents lignes sont rejetées afin qu’un import incontrôlé n’épuise pas le budget du worker. La chaîne formula renvoyée à chaque succès rappelle le contrat en trois étapes : coût de ligne égal à quantité fois coût unitaire, coût total égal à la somme des lignes, coût par portion égal au total sur les portions. Pour chaque ligne vous fournissez une quantité finie non négative dans l’unité d’achat ou de mesure — kilogrammes de farine, litres de lait, pièces d’œufs, bouteilles d’huile — et un unit_cost fini non négatif, prix d’une de ces unités dans une seule devise. La capacité multiplie quantity par unit_cost pour obtenir le line_cost de la ligne, puis additionne tous les line_cost pour obtenir total_cost du lot entier. Le coût par portion est total_cost divisé par servings, de sorte que la même liste d’épicerie s’exprime en coût de plateau traiteur et en coût par assiette sans ressaisir les prix.

Contrat d’entrée, règle des portions et forme de la réponse

Exemple : farine deux unités à un virgule vingt-cinq, œufs six à zéro virgule trente-cinq, lait un à un virgule un, beurre zéro virgule vingt-cinq à huit, pour quatre portions, donne des coûts de ligne deux virgule cinq, deux virgule un, un virgule un et deux, un total de lot sept virgule sept et un coût par portion un virgule neuf deux cinq. Champs manquants, valeurs non finies et quantités ou coûts unitaires hors limite absolue échouent sans débiter le compte. Envoyez un corps JSON avec deux champs obligatoires. ingredients est un tableau non vide d’objets ; chaque objet doit inclure quantity et unit_cost comme nombres finis non négatifs, et peut inclure un name optionnel. servings est un nombre fini strictement supérieur à zéro : zéro et les valeurs négatives échouent avec invalid_input car un lot sans assiettes ne définit pas de coût par portion. Les alias acceptés incluent items, list et lines pour le tableau, et portions, people, yield et serves pour le nombre de portions, afin que tableurs et constructeurs de formulaires conservent leurs noms de colonnes. En succès la réponse renvoie ingredient_count et un tableau ingredients normalisé avec index, name, quantity, unit_cost et line_cost pour chaque ligne ; servings arrondi pour un JSON stable ; total_cost ; cost_per_serving ; une chaîne formula ; un message court pour les bannières d’interface ; et un tableau steps qui parcourt chaque multiplication et la division finale. Conservez une seule devise pour tous les unit_cost ; le calculateur ne convertit ni monnaies ni systèmes d’unités : il multiplie et divise uniquement les nombres que vous envoyez.

Où une API de coût total de lot de recette trouve sa place

Marques de meal-prep et cuisines scolaires suivent le coût du lot et le coût par portion lorsqu’elles passent une recette de base de quatre à quarante assiettes, en ne changeant que les quantités tout en réutilisant la même table de unit_cost. Les applications de budget courses peuvent appeler l’API après un scan code-barres qui résout les prix unitaires, puis stocker total_cost et cost_per_serving à côté du nombre d’invités prévu.