Tutorial
Project your purchasing spend before a change
Save a planning scenario, read its four columns, and know which figure came from your files and which one you supplied yourself.
About 8 minutes. Last reviewed against the product on .
By the end of this you will have a saved scenario that projects purchasing spend forward, and you will know which part of it was read from your files and which part you supplied yourself.
1. Check that your history can carry a projection
A scenario is arithmetic over your accepted purchase rows. With no rows it saves anyway and reports that no purchase history is available, which is the honest answer rather than a zero.
The projection divides the spend it finds by the whole baseline window, whether or not your imports cover that much time.
2. Save a scenario
Open Planning and fill the one form on the page. The name is the only free text; everything else is a number or a choice.
- Forecast horizon
- 30, 60 or 90 days
- the period being projected
- Baseline window
- 30, 60, 90 or 180 days
- the offered default is 90
- Cost change
- -100% to +500%
- entered in tenths of a percent
- Volume change
- -100% to +500%
- a multiplier you supply, not one measured
Measured from the scenario form in app/app/planning/page.tsx and its validation in app/app/planning/actions.ts.
Viewer access can read scenarios but cannot save or remove them.
3. Read the four columns
Each saved scenario renders a small table, one row per currency found in the window. Currencies never meet.
| Column | How it is worked out |
|---|---|
| Currency | One row per currency in the window; a row with no currency is filed as UNSPECIFIED |
| Baseline | Spend in the window, divided by the window length, multiplied by the horizon |
| Projected | Baseline multiplied by the cost factor, then by the volume factor |
| Variance | Projected minus baseline, shown red when it is positive |
Measured from projectSpendByCurrency in src/lib/planning/calculations.ts.
Baseline is therefore not a figure from your history. It is your observed daily rate stretched over the horizon you chose, which is why changing the horizon alone moves it.
4. Change one thing at a time
The two percentages multiply rather than add, so a modest change to each is a larger change together than either suggests on its own.
| Input | Factor applied |
|---|---|
| Cost change of +10% | 1.10 |
| Volume change of +10% | 1.10 |
| Combined effect on the baseline | 1.21 |
Measured from the cost and volume factors in projectSpendByCurrency, src/lib/planning/calculations.ts.
Save one scenario per question. Two changes in one scenario give you a number you cannot attribute.
5. Check where the window ends
The window is anchored on your most recent purchase date, not on today. If imports stopped a month ago, the baseline does not fall; it keeps describing the last window that had rows in it.
A scenario also stores its settings, not its answer. The table is recalculated from your current purchases each time the page loads, so a projection can move between two visits without anybody editing anything.
- Scenarios listed
- 25
- most recently created first
- Purchase rows read
- 20,000
- most recent purchase dates first
Measured from the queries in app/app/planning/page.tsx.
What this does not tell you
Nothing about sales. There is no revenue, no covers, no menu price and no margin anywhere in this calculation, so a scenario cannot tell you whether you can afford the projection it just produced.
The volume change is a number you type. Nothing on the page measures how much you buy or predicts how much you will, and entering a rise does not make one likely.
There is no seasonality, no per-supplier or per-item breakdown, and no conversion between currencies. Rows carrying a negative or unreadable total are skipped rather than reported, so a malformed row leaves the projection quietly smaller.
Next: what the calculators assume.