Cost to Serve

Trace the costs your scenario recorded to the customers they served, and see the costs that remain with the system. Customer costs plus system costs add up to the recorded scenario costs.

When to use this¶

You want to know which customers are most expensive to serve
You need costs broken down by type — supply, transport, inventory, handling, production, fixed site costs
You're looking for places to reduce logistics cost

What you need¶

The run stops and says why when the scenario has:

A missing product reference. Product-specific records must name a product listed in Map Products. Shared fixed site costs need no product
A bill of materials that cannot be rolled up, such as a recipe that consumes its own output
A row the scenario checks refuse: a location the scenario does not list, a blank required field or a negative quantity — the same checks Network Optimization makes, with the rows named

Quantities are read in the scenario's Unit, converted with each product's conversion — recipe components included — as the optimizer converts them, so flows and recipes stated in different units split costs in the right proportions. A scenario that states no unit is refused with the optimizer's message, and a quantity no conversion reaches with the product and units named.

Demand and shipments are optional. Without them, recorded costs remain as system costs at their relevant locations. A row on demand policy or demand state identifies a demand point. A scenario with no recorded costs returns no cost rows.

It allocates recorded costs, never rates¶

Every cost it allocates is a realized total already recorded on the scenario. No per-unit rate enters the arithmetic — the rates on supply policy, lanes, handling policy and inventory policy are what the optimizer reads, and populating the state tables from them is upstream work, done by the run that built the baseline.

Recorded supply, transport, production, handling and inventory carrying amounts may be negative when they represent credits. Credits keep their original sources and follow the same customer or system destinations as costs; their signed total is conserved at currency precision. Fixed site operating costs must be finite and nonnegative, and zero at a closed site. Quantities, capacities and policy rates retain their own validation rules.

Cost type	The number it reads
Transport	Transport Cost on the flows table — the realized total for that flow. Several rows on one route, one per shipment, add up
Supply	Realized Supply Cost on supply state
Inventory carrying	Realized Carrying Cost on inventory state
Handling	Realized Handling Cost on handling state
Production	Realized Cost on production state, at the location that made the product
Fixed site	Total Fixed Cost on location state, incurred once at the site

Two tables shape the allocation without adding any cost. Demand policy and demand state mark the demand points, and the flows are the connections costs travel along. Lanes are not read. They say where the optimizer may ship, not where anything was shipped, so every recorded flow is allocated whether or not a lane lists its route, and a lane the optimizer would refuse — one with no unit cost — does not stop the run.

How it apportions. Each location's recorded cost is pushed forward to the demand points its outbound flows reach, split in proportion to those flows — a linear system solved once per product, so a cost at a hub reaches every customer the hub serves in the ratio the hub actually shipped in. A location whose outbound flows carry no quantity splits its cost equally between the places it ships to. A demand point that also ships the product on counts its own Fulfilled Quantity as one of the places its arrivals go: a store that kept 10 and sent 10 on carries half of everything that reached it, and the shops it supplied carry the other half. One with no demand state for the product kept none of it and passes everything on. Where such a location's fulfilled quantity is blank, or none of its outbound flows carries a quantity, the split cannot be made and the run is refused, naming the location. An absent cost contributes nothing; the node does not estimate it from a policy rate.

Products are processed component-before-output, so a finished good's cost to serve carries the cost of the components its recipe consumed. Each component cost keeps its type: the supply cost of a component is part of the finished good's supply cost, and only the realized cost of making it is production cost. A plant that consumes a component and also ships some of it on splits what reached it the same way a forwarding demand point does: the quantity its recipes consumed is its share, carried into the finished good, and its outbound flows carry the rest.

Costs that remain with the system¶

System costs are explicit rows in the same result as customer costs. They retain their original cost type, with the product where known and the recorded source. They are not spread over other customers or products.

Stock reaching no customer: the system location is where the stock's recorded path ends. For example, a shipment into a depot with no demand or onward flow retains the supply and transport costs that reached that depot. A terminal demand point explicitly recording zero fulfilled quantity also retains its arrivals as system stock.
Closed circulation: when flows circulate without reaching any customer, the rows identify their recorded source locations and transport routes. There is no invented terminal location.
Shared site costs: fixed operating costs stay at their site, including an active site's costs, with no product assigned. The recorded site cost has no product allocation basis. A location-wide handling cost also stays site-wide when no positive flow quantity supports a product allocation, even if the scenario lists products.

The reason names what the recorded data shows. No onward flow alone does not establish that stock is a return or a write-off.

For example, S supplies 20 units for 40 and ships 10 units to customer C for 10 and 10 to depot X for 30. C carries supply cost 20 and transport cost 10. X carries system supply cost 20 and transport cost 30. The result totals 80, the same as the recorded costs.

Reconciliation and rounding¶

The result includes recorded supply, production, transport, handling, inventory carrying and fixed site operating costs exactly once. It does not claim to include unrecorded costs, such as one-time opening or closure charges. Adding the result to the source cost tables would count the same money twice.

Amounts are rounded after allocation and production roll-up, at the scenario currency's precision. Any residual minor units are assigned deterministically to preserve the total: 100 split equally can appear as 33.34, 33.33 and 33.33. A numerical allocation failure is reported as a failure, not hidden in a balancing system row.

What you get¶

A result table on the scenario, with Allocation Type identifying customer or system rows. Customer rows name the demand location; system rows leave it blank and name a System Location and System Reason. Both carry the cost type and source details. Source Product remains the original product even when Product names a finished good made from it. Location-wide handling keeps Source Product as ALL while its cost follows products in proportion to their recorded inbound quantities, or outbound quantities where a product has no inflow. The original recorded amount remains the rounding budget before this split.

Sum the rows to obtain a customer or product breakdown; different recorded sources can contribute rows to the same customer and cost type. Filter Allocation Type to customer for customer comparisons. Include system rows when reconciling the complete total, including shared site costs with no product. Group by source product to reconcile component costs before production roll-up, or by product to see where those costs ended up.

Wire the result into Save Data to export, into a dashboard to chart it, or into another analysis to keep going. Downstream nodes still see the full scenario plus the breakdown. Results are saved with the scenario when the node runs in a workflow.

Workflow wiring¶

This node takes scenario data — wire it after Create Scenario, Load Scenario, or another analysis step. Do not wire it straight to a Map node.

flowchart LR
    n1["Import Data (locations.csv)"] --> n2["Map Locations"]
    n3["Import Data (shipments.csv)"] --> n4["Map Transport"]
    n4 --> n5["Create Scenario"]
    n5 --> n6["Cost to Serve"]
    n7["Import Data (demand.csv)"] --> n8["Map Demand Policy"]
    n9["Import Data (supply.csv)"] --> n10["Map Supply State"]
    n11["Import Data (inventory.csv)"] --> n12["Map Inventory State"]
    n2 --> n5
    n8 --> n5
    n10 --> n5
    n12 --> n5
    n13["Import Data (products.csv)"] --> n14["Map Products"]
    n14 --> n5

The state nodes carry the costs. Of the policy nodes, only Map Demand Policy is read, and only for where the demand is; the rates on the others are for the optimizer.

Common mistakes¶

Wiring this node to a Map node instead of through Create Scenario
Mapping only the policy halves and expecting an allocation. Rates are not costs here; with the state tables empty every allocation is zero and the node returns no rows
Omitting Map Products when costs or flows name products. List those products; a scenario containing only shared fixed site costs needs no product rows

Messages this node can show¶

A run gives this node 5 minutes. A node that takes longer stops with Time limit reached.

Like every node, it can also stop on the checks before a run and the run's limits.