Map Demand History
Map raw rows into demand history: a dated series of past demand, one quantity per (location, product, date).
demand history is transient. Create Scenario carries it in memory to downstream nodes and never writes it to a scenario table. It is input for a forecast, not part of the saved scenario. For the single-period realized outcome you do save, use Map Demand State, which has no date axis.
One node reads the series, and it is not a forecast. XYZ Segmentation reads these rows directly, with no scenario and no other table, and classifies each item by how variable its demand is. So Import Data → Map Demand History → XYZ Segmentation produces a result on its own, from this file alone.
There is no forecasting node yet, so a series mapped for a forecast reaches no analysis. Map it for the segmentation and you get an answer in the same run.
When to use this¶
- You have demand observations spread over time (months, weeks, days) and want them carried on the scenario in their dated form
- You're preparing a series for forecasting
What you need¶
- An upstream Import Data node with one row per (location, product, date) observation
- A date column, a quantity column, and the unit the quantity is in
Field mapping¶
Auto-detection is all or nothing. With no explicit mapping on the node, every field is matched against the headers listed below, case-insensitively, and a space in your header reads as an underscore, so Site Name matches site_name. Set even one field explicitly and detection switches off for the whole node: only the fields named in the mapping are filled, and the rest arrive empty.
Set mappings in the node's panel. Connect an upstream table and select the mapping node to see automatic matches. Choosing a column saves all displayed matches as an explicit mapping. Use Use automatic detection to return to header detection. Required fields without a match are marked in the panel.
| Field | Type | Required | Example | What it is | Auto-detected headers |
|---|---|---|---|---|---|
| Location | text | Yes | Store 1 |
Where the demand was observed. Must match a Location name. | location, loc, name, id, location_id, loc_id |
| Product | text | Yes | Widget |
Product or SKU observed. Required — name the product even in a single-product scenario so the forecast is explicit. | product, sku, item, material, product_id |
| Date | text | Yes | 2025-01-01 |
Observation date as an ISO string (YYYY-MM-DD). The forecaster reads one quantity per date to build the series. | date, ds, period, month, observed_at, timestamp |
| Quantity | number | Yes | 120.0 |
Observed demand quantity on this date. | quantity, qty, amount, volume, units |
| Unit | text | Yes | units |
Unit the quantity is expressed in. Carried onto the forecast output so projections keep the series' unit. | unit, uom, quantity_unit, qty_unit |
How it works¶
Each row becomes one observation. Rows sharing a (location, product) form one series, and the series' unit travels with it. The records reach Create Scenario like any other Map node's and are dropped there rather than saved.
Workflow wiring¶
flowchart LR
n1["Import Data (demand_history.csv)"] --> n2["Map Demand History"]
n4["Import Data (locations.csv)"] --> n5["Map Locations"]
n2 --> n3["Create Scenario"]
n5 --> n3
Common mistakes¶
- Using Map Demand State for a time series. That table is single-period and carries no date.
- Expecting the series back out of a saved scenario. It is transient. Read it in the run that mapped it or not at all.