Map Supply State
Map raw rows into the scenario's supply state table: the outcome of supply, how much was used at each location, and the cost realized.
This is the output side of supply. Pair it with Map Supply Policy, the rules, on baselines you will compare against an optimization.
When to use this¶
- The scenario is a baseline that should preserve observed supply history for later comparison
- Cost to Serve allocates the realized cost on this table, so a per-customer breakdown needs it
Network Optimization does not read this table. It writes it fresh every run. Optimization-only workflows can skip this node.
What you need¶
- An upstream Import Data node with one row per (location, product) you have observations for
- An observed-quantity column or a realized-cost column, typically both
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 | Warehouse A |
Where the supply was used from. Must match a Location name. | location, loc, name, id, location_id, loc_id |
| Product | text | Yes | Widget |
Product or SKU. Required — name it even in a single-product scenario. | product, sku, item, material, product_id |
| Used Quantity | number | No | 800.0 |
Quantity actually supplied in the recorded baseline. Its unit goes in Quantity Unit. | used_quantity, quantity, qty, amount, volume, units |
| Quantity Unit | text | No | units |
Unit that used quantity is expressed in. | quantity_unit, qty_unit, unit, uom |
| Realized Supply Cost | number | No | 4000.0 |
Total supply cost actually incurred in the baseline (not per-unit). | realized_cost, supply_cost, handling_cost, total_supply_cost, production_cost, total_handling_cost |
| Realized Emissions | number | No | 120.0 |
Total emissions actually produced by this supply in the baseline. Its unit goes in Emissions Unit. | realized_emissions, emissions, co2, carbon, ghg, carbon_emissions |
| Emissions Unit | text | No | kg CO2 |
Unit for realized emissions (e.g. kg CO2). | emissions_unit, co2_unit |
How it works¶
Each row becomes a supply state record. The scenario stores the realized totals so dashboards, the map and side-by-side comparisons can read what flowed, and so Cost to Serve has a supply cost to allocate.
An optimization overwrites this table; nothing else does. A run that solves recomputes the state and replaces what was there. A scenario loaded and saved again without an optimization keeps the rows it was carrying. That is what makes a mapped baseline a baseline, and why an observed table mapped here survives into the comparison you built it for.
Workflow wiring¶
Pair with Map Supply Policy when building a baseline:
flowchart LR
n1["Import Data (supply.csv)"] --> n2["Map Supply Policy"]
n2 --> n3["Create Scenario"]
n1 --> n4["Map Supply State"]
n4 --> n3
Common mistakes¶
- Wiring only this node and expecting the optimizer to use it. The optimizer reads Map Supply Policy. State is observation.
- Mapping a per-unit cost here. Realized Supply Cost is a total. The per-unit rate belongs on Map Supply Policy.