> ## Documentation Index
> Fetch the complete documentation index at: https://help.kwentra.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Inventory — Per-Ingredient Store on Recipes

> Each recipe ingredient names its own store, so one dish can draw from several warehouses while costing and consumption stay accurate.

Each ingredient now names its own store, so one dish can draw from several warehouses.

### **Business Value**

* Draws one recipe's ingredients from several stores.
* Prices each line from the store that has the item.
* Removes stock transfers invented to satisfy a single-store recipe.
* Blocks direct-receiving stores and items, which hold no balance.
* Rejects recipes with zero portions before they fail at the till.

### **Use Cases**

* Chef writes one Mixed Grill drawing from three stores.
* Cost controller sees each ingredient priced from its own warehouse.
* Kitchen manager imports recipes with a store code on every ingredient row.

### **How It Works**

| **Where:** Back Office → Inventory → Recipes |
| - |

A recipe named **one Store** on its header. Every ingredient was priced from that store. A kitchen keeping meat, dry goods and drinks in three stores could not write that recipe at all. The store now sits on each ingredient line, and the header Store is gone.

#### **The example below**

Every figure here uses one setup. **Mixed Grill** makes **4** portions, profit factor **3**:

| Ingredient | Store | Qty per recipe | Stock price | Available |
| - | - | - | - | - |
| Chicken | **Butchery** | 2 kg | 80.00 / kg | 20 kg |
| Flour | **Main Store** | 0.5 kg | 20.00 / kg | 10 kg |
| Cola | **Beverage Store** | 1 litre | 15.00 / litre | 30 litres |

**Number of portions** is how many dishes one run makes. **Qty** is what the whole run uses, not one dish. So 2 kg of Chicken over 4 portions deducts 0.5 kg per dish.

Line values are **160.00**, **10.00** and **15.00**. Total cost **185.00**, cost per portion **46.25**.

#### **Store on the ingredient line**

Each line has its own **Store**, right after **Item**:

| Column | Who fills it | On a Store change |
| - | - | - |
| Item | You pick it | — |
| **Store** | You pick it | *this is the change* |
| Store unit | Defaults from the item | — |
| Qty | You type it | Stays as typed |
| Unit cost | Shown | Priced again from the new store |
| Value | Shown | Recalculated |

**Store is required on every line.** A line saved without one cannot be saved.

#### **The recipe header**

**The header Store is removed**, from the screen and the database. A recipe no longer belongs to a store. Its ingredients do.

The listing's **Store** filter now matches the stores on the ingredient lines. The export writes each line's own store.

#### **How costs are calculated**

* **Unit cost** and **Value** are priced from **that line's** store. Chicken reads 80.00 from the Butchery, Flour 20.00 from the Main Store.
* Changing a line's Store prices it again. **Total cost**, **Cost per portion** and **Suggested selling price** update at once.

#### **Number of portions**

**Zero is now rejected.** Before, only negative values were refused. Zero is the field's default, so a recipe could be saved with it and then fail when the dish sold.

| Message | When it appears |
| - | - |
| *Number of portions must have positive value !* | You save with Number of portions at 0 or below. |

#### **What a sale deducts**

Each ingredient comes out of the store on **its own** line. Selling one Mixed Grill draws from three stores, on **one** stock usage:

| Store | Before | After |
| - | - | - |
| Butchery | 20 kg | 19.5 kg |
| Main Store | 10 kg | 9.875 kg |
| Beverage Store | 30 litres | 29.75 litres |

Every line records its own source store. All three keep the expense account from the dish's menu item.

#### **How refunds are treated**

**A refund puts back only what is returned.**

* A row marked **returned** creates a second usage with negative quantities. Each ingredient goes back to its own store.
* A row marked **wasted** is not reversed. Those ingredients stay consumed.

#### **The recipe import**

The store code moves off the recipe row onto **each ingredient row**, where it is **required**. This is the column order after [Recipe Categories](/back-office/inventory/recipe-categories):

| Column | Recipe row | Ingredient row |
| - | - | - |
| 0 | Category code | *empty* |
| 1 | **Recipe code** | *empty — marks an ingredient row* |
| 2 | Recipe name | — |
| 3 | Preparation time | — |
| 4 | Number of portions | — |
| 5 | Profit factor | — |
| 6 | Non-stock item code | — |
| 7 | — | **Item code** |
| 8 | — | **Qty** |
| 9 | — | **Store code** |

* The import applies the same rules as the screen, with the row number added to each message.
* **Line numbers are now correct.** Messages used to name a line one lower than the file's own.
* The **Help** panel lists the columns in their new order.

#### **Direct-receiving stores and items are barred**

A direct-receiving store or item is issued straight back out on receipt, so it never has a balance. Neither can be used on a recipe.

Both are filtered out of the autocomplete and the lookup. The rules are also checked **on save**:

| Where | Message |
| - | - |
| Store on a line | *Direct receiving stores can't be used in recipes* |
| Ingredient | *Direct receiving items can't be used in recipes* |

The import gives the same two, with the line number added.

#### **What happens to existing recipes**

Each recipe's header Store is copied onto its ingredient lines. **No price changes and no balance moves.**

| **Note:** A recipe holding a direct-receiving store, a direct-receiving ingredient, or 0 portions cannot be saved again. A one-off check reports every such recipe and what needs changing. |
| - |


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.