Cost to Serve Outputs (Optimization)

When modeling supply chains, stakeholders are often interested in understanding the cost to serve specific customers and/or products for segmentation and potential reposition purposes. In order to calculate the cost to serve, variable costs incurred all along the path through the supply chain need to be aggregated, while fixed costs that are incurred need to be apportioned to the correct customer/product. This is not always straightforward and easy to do, think for example of multi-layer BOMs.

When running a network optimization (using the Neo engine) in Cosmic Frog, these cost to serve calculations are automatically done, and the outputs are written into three output tables. In this help center article, we will cover these output tables and how the calculations underneath to populate them work.

First, we will briefly cover the example model used for screenshots for most of this help center article, then we will cover the 3 cost to serve output tables in some detail, and finally we will discuss a more complex example that uses detailed production elements too.

Network Optimization Output Tables related to Cost To Serve

There are 3 network optimization output tables which contain cost to serve results; they can be found in the Output Summary Tables section of the output tables list:

1. Use Cosmic Frog’s Module menu to go to the Data module.
2. Once in the Data module, click on the round grid icon to show output tables.
3. User here searched for “cost” to filter out the tables which contain this word in their names.
4. There are 3 tables which contain outputs related to cost to serve:
   1. The Optimization Cost To Serve Summary table – contains per unit cost calculations at the period-customer-product level and can be used if desired to aggregate further to the customer or product level.
   2. The Optimization Cost To Serve Path Summary table – contains 1 record for each path in the network (path: from most upstream to furthest downstream location), including all costs that have been incurred along and allocated to the path.
   3. The Optimization Cost To Serve Path Segment Details table – contains details for each segment of each path, including all costs that are incurred on and allocated to the segment.

We will cover the contents and calculations used for these tables by using a relatively simple US Distribution model, which does use quite a few different cost types in it. This model consists of:

• 50 customers (CZs), 1 in the capital of each of the states in the US
• 3 distribution centers (DCs) located in Jacksonville FL, Reno NV, and Memphis TN
• 2 manufacturing locations (MFGs) located in Detroit MI and Dallas TX
• 4 products
• 3 yearly periods: 2025, 2026, and 2027

Following screenshot shows the locations and flows of one of the scenarios on a map:

One additional important input to mention is the Cost To Serve Unit Basis field on the Model Settings input table:

User can select Quantity, Volume, or Weight. This basis is used when needing to allocate costs based on amounts of product (e.g. amount produced or moved). For example, we need to allocate $100,000 fixed operating cost at DC_Raleigh to 3 outbound flows. The result is different when we use a different cost to serve unit basis:

Flow #	Source	Destination	Flow Quantity (EA)	Flow Weight (LBS)	Flow Volume (CFT)	Cost To Serve Unit Basis	Allocated Fixed Operating Cost
1	DC_Raleigh	CZ_1	2,500	3,200	5,320	Quantity	$37,313.43
2	DC_Raleigh	CZ_2	1,200	2,300	4,850	Quantity	$17,910.45
3	DC_Raleigh	CZ_3	3,000	3,600	5,500	Quantity	$44,776.12
1	DC_Raleigh	CZ_1	2,500	3,200	5,320	Volume	$35,164.84
2	DC_Raleigh	CZ_2	1,200	2,300	4,850	Volume	$25,274.73
3	DC_Raleigh	CZ_3	3,000	3,600	5,500	Volume	$39,560.44
1	DC_Raleigh	CZ_1	2,500	3,200	5,320	Weight	$33,950.22
2	DC_Raleigh	CZ_2	1,200	2,300	4,850	Weight	$30,950.86
3	DC_Raleigh	CZ_3	3,000	3,600	5,500	Weight	$35,098.92

Note that in this documentation the Quantity cost to serve unit basis is used everywhere, which is the default.

Optimization Cost To Serve Path Segment Details Output Table

We will cover the 3 output tables related to Cost To Serve using the above described model as an example in the screenshots. Further below in the document, we will also show an example of a model that uses some detailed production inputs and its cost to serve outputs. Let us start with examining the most detailed cost to serve output table, the Cost To Serve Path Segment Details table. This output table contains each segment of each path, from the most upstream product source location to customer fulfillment, which is the most downstream location. Each path segment represents an activity along the supply chain: this can be a production when product is made/supplied, inventory that is held, a flow where product is moved from one location to another, or use of a bill of materials when raw materials are used to create intermediates or finished goods.

Note that these output tables are very wide due to the number of columns they contain. In the screenshots, columns are often re-ordered, and some may be hidden if they do not contain any values or are not the topic of discussion, so they may not look exactly the same as what you see in your Cosmic Frog. Also, grids are often sorted to show records in increasing order of path ID and/or segment sequence.

1. This is the Optimization Cost To Serve Path Segment Details output table.
2. Records with the same Path ID together make up 1 path. Each record represents a segment of the path.
3. A path is from most upstream to most downstream location for a certain product that is being demanded at the downstream customer or needing to be held in inventory at the downstream facility. Therefore, a path has a Path Product Name, a Path Origin and a Path Destination associated with it.
4. The Segment Sequence indicates the order of the segments within the path, which starts at 1 and is incremented by 1 for the next segment, etc.
5. For each segment, the Segment Origin location and Segment Destination location are listed. The Segment Origin of the first segment of the path matches the Path Origin, and the Segment Destination of the last segment of the path matches the Path Destination.
6. The Segment Type field indicates the activity of the segment, this can be production, inventories, flows, billsofmaterials, or no_activity.
7. These 3 records with PathID = 1 make up the 3 segments of 1 path from MFG_Detroit (Path Origin Name) to CZ_Hartford (Path Destination Name) for the P1_Bullfrog product (Path Product Name) together:
   1. The first segment (Segment Sequence = 1) has MFG_Detroit listed as both the Segment Origin and Segment Destination. This is because the Segment Type is production which occurs at a location. This is the most upstream part of the path, where product is created at the Detroit manufacturing location.
   2. The second segment (Segment Sequence = 2) is a flow (Segment Type = flows), e.g. movement of product, from MFG_Detroit to DC_Jacksonville. What was produced during segment 1 is now moved from the manufacturing location in Detroit to the DC in Jacksonville.
   3. The third and last segment (Segment Sequence = 3) is another flow, from DC_Jacksonville to the final customer destination CZ_Hartford, which has demand for P1_Bullfrog.
8. These 3 records with PathID = 341 together make up another path, which also has 3 segments. This path is for product P2_Amphibian and starts at MFG_Dallas where the product is made and is then moved to DC_Memphis, which then fulfills the demand for it at customer CZ_Springfield.
9. These 4 records with PathID = 611 also together make up 1 path, but this one has 4 segments. Again, it starts with a production at an MFG location (Dallas), from which it is moved to a DC (Memphis). The third segment is another flow, just not a customer fulfillment one, but a DC-DC replenishment flow from the Memphis DC to the Jacksonville DC. Finally, DC_Jacksonville fulfills the demand at the CZ_Concord customer.

Please note that several columns are not shown in the above screenshot, these include:

• Scenario Name – indicates which scenario the outputs are for. In this case the column was filtered for 1 specific scenario, 1 that allows DC-DC transfers.
• Path Start Period Name – indicates in which period the first segment of the path begins. Here this was 2025 (the first period in the model) for all records.
• Path End Period Name – indicates in which period the last segment of the path ends. Again, this was 2025 for all records.
• Path Origin Type – indicates the category of the Path Origin, e.g. facility or supplier.
• Path Destination Type – indicates the category of the Path Destination, e.g. facility or customer.

Removing some additional columns and scrolling right, we see a few more columns for these same paths:

1. These 5 columns, Path ID, Segment Sequence, Segment Origin, Segment Destination and Segment Type, are repeated from the previous screenshot with a changed order.
2. Now we are also showing the Segment Product Name, which in our example here is the same for each segment of the path and matches the Path Product Name (not shown). In other cases, these can be different if bills of materials (BOMs) are used in the model, which we will see examples of later on in this documentation.
3. The Segment Quantity field indicates for each segment the amount of product it concerns. For segment 1 of path 1, segment quantity = 707 indicates that 707 units of P1_Bullfrog were made at MFG_Detroit. For segment 2 of path 1, segment quantity = 707 means that 707 units of product P1_Bullfrog were moved from MFG_Detroit to DC_Jacksonville, etc.
4. The Segment Cost field shows the total cost per segment. Producing 707 units of P1_Bullfrog (Path ID = 1, Segment Sequence = 1) resulted in a total cost of $707. Moving 707 units of P1_Bullfrog from MFG_Detroit to DC_Jacksonville cost $7,459.78 in total (Path ID = 1, Segment Sequence = 2). Moving those 707 units of P1_Bullfrog then from DC_Jacksonville to CZ_Hartford incurred a total cost of $21,267.89 (Path ID = 1, Segment Sequence = 3). The individual cost buckets that together make up the total Segment Cost and how they are calculated will be covered next.

We will stay with the example of the path from MFG_Detroit to DC_Jacksonville to CZ_Hartford for 707 units of P1_Bullfrog to explain the costs (Path ID = 1 in the above). Here is a visual of this path, shown on the map:

The following 4 screenshots show the 3 segments of this path in the Optimization Cost To Serve Path Segment Details output table, and the different costs that are applied to each segment. In this first screenshot, the left most column is the Segment Sequence, and a couple of fields that were not present in the screenshots above are now shown:

1. The Demand Quantity field indicates the amount of product used to fulfill demand. This is always at a customer destination of the segment, hence why it is 0 for the first 2 segments of the path, and the amount usually matches the Segment Quantity, unless demand is served using multiple modes.
2. The Segment Cost is the sum of the individual cost buckets for this segment. We will look at these individual cost buckets in the following 3 screenshots, and then further below explain their calculations:

Let us put these on a map again, together with the calculations:

There are 2 types of costs associated with the production of 707 units of P1_Bullfrog at MFG_Detroit:

1. Production Cost: this is calculated as the number of units produced, multiplied by the Unit Cost as specified for the facility-product combination in the Production Policies input table. In this case this is set to $0.80 per each. Therefore, Production Cost = 707 * $0.8 = $565.60.
2. CO2 Cost: this is calculated as the number of units produced, multiplied by the CO2 Emission Rate as specified for the facility-product combination in the Production Policies input table (here set to 2 per each) multiplied by the CO2 Cost specified in the Model Settings input table (here set to $0.10). This results in: CO2 Cost = 707 * 2 * $0.10 = $141.40.

For the flow of 707 units from MFG_Detroit to DC_Jacksonville, there are 4 costs that apply:

1. Outbound Handling Cost (at the source of the flow): this is calculated as the number of units that are flowing multiplied by the Outbound Handling Cost specified for the facility-product combination (MFG_Detroit, P1_Bullfrog) in the Warehousing Policies input table (here set to $0.60 per each). Therefore, Outbound Handling Cost = 707 * $0.6 = $424.20.
2. Transportation Cost: because the Unit Cost field in the Transportation Policies table for the MFG_Detroit to DC_Jacksonville lane is set to $0.01 and the accompanying Unit Cost UOM field is set to EA-MI, this cost is calculated as the amount of units that are flowing multiplied by the distance multiplied by the cost of $0.01 per unit per mile. The distance from MFG_Detroit to DC_Jacksonville is calculated at runtime based on the latitudes & longitudes of the locations (specified in the Facilities input table) and a 17% circuity factor, which is set in the Circuity Factor field in the Model Settings input table. This distance is 974.65 miles. Therefore, the transportation cost = 707 * 974.65 mi * $0.01/mi = $6,890.75.
3. In Transit Holding Cost: this is the holding cost based on the time the product is in transit and is calculated as the amount of units being transported multiplied by the fraction of time the transport time represents as compared to a whole year multiplied by the product’s value ($20 per the Unit Value field on the Products input table) multiplied by the inventory carrying cost percentage (12% per the Inventory Carrying Cost Percentage field in the Model Settings input table). The transportation time is calculated from the transportation distance of 974.65 mi (see previous bullet) and the Average Speed of 55 mph as set in the Model Settings input table, therefore transportation time = 974.65 mi / 55 mph = 17.72 hours. This transport time expressed as a fraction of the year = 17.72 hrs / (365 days * 24 hours/day) = 0.0020. So, the calculation for in transit holding cost becomes: 707 * 0.0020 * $20 * 0.12 = $3.43.
   1. Note that if the Inventory Carrying Cost Percentage field on the Transportation Policies input table is set, this value is used instead of the one specified in the Model Settings input table.
4. Inbound Handling Cost (at the destination of the flow): calculated as the number of units flowing multiplied by the Outbound Handling Cost specified for the facility-product combination in the Warehousing Policies input table, which is $0.20 per each for P1_Bullfrog at DC_Jacksonville. This results in Inbound Handling Cost = 707 * $0.20 = $141.40.

There are 7 different costs that apply to the flow of the 707 units of P1_Bullfrog from DC_Jacksonville to CZ_Hartford where it fulfills the customer’s demand of 707 units:

1. Facility Fixed Operating Cost (at the source of the flow as operating costs are calculated based on outbound flow): the total Fixed Operating Cost at DC_Jacksonville for the period of 2025 is $275,000 per the Fixed Operating Cost set on the Facilities input table. We need to allocate part of it to this flow, and the way this is done is to calculate what the ratio of the amount of flow (707 units) is as compared to the total outbound flow at this location during this period. Aggregating the Flow Quantity field in the Optimization Flow Summary output table, filtered for the correct Scenario Name, Departing Period Name (2025), and Origin Name (DC_Jacksonville), we find that the total outbound flow is 54,003.6 units. Therefore the allocation of Facility Fixed Operating Cost to this flow becomes: $275,000 * 707 / 54,003.6 = $3,600.22.
   1. Note that if a facility has no throughput in a certain period, but Facility Fixed Operating costs are applied, then for this period there will be a record in the Optimization Cost To Serve Path Segment Details output table with Path Origin = Path Destination = Segment Origin = Segment Destination = facility name, where both Path Product Name and Segment Product Name are blank, Segment Type = no_activity, and Segment Quantity = 0 and the whole Fixed Operating Cost of the period is allocated to this record in the Segment Facility Fixed Operating Cost field.
2. Storage Cost (at the source of the flow as this is calculated based on average turn estimated inventory in this case, which is calculated based on outbound flow): in this example model, turns are specified in order to calculate turn estimated inventory. For P1_Bullfrog at DC_Jacksonville, the inventory turns every 12 weeks as specified in the Time Between Inventory Turns field and the accompanying UOM field in the Inventory Policies input table. This means that the inventory turns 365 days/year / (12 weeks * 7 days/week) = 4.35 times per year. An outbound flow of 707 units then results in a maximum turn estimated inventory of 707 / 4.35 = 162.71. Dividing the maximum turn estimated inventory by 2 to get the average turn estimated inventory gives us 162.71 / 2 = 81.35 units of average turn estimated inventory. Since the Unit Storage Cost is set to $0.30 for all products at all DCs in the Inventory Policies table, the Storage Cost associated with this flow of 707 units = 81.35 units turn estimated inventory * $0.30 = $24.41.
3. Turn Estimated Holding Cost: a turn estimated holding cost is also calculated to account for the amount of time these 707 units of product sit in inventory. This is also based on the turn estimated inventory in this case. The calculation is the average turn estimated inventory (which we calculated as 81.35 units in the previous bullet) multiplied by the product value ($20 from the Products input table) multiplied by the inventory carrying cost percentage (12% from the Model Settings input table). Therefore, turn estimated holding cost = 81.35 * $20 * 0.12 = $195.25.
   1. Note that if the Carrying Cost Percentage field on the Inventory Policies input table is set, this value is used instead of the one specified in the Model Settings input table.
4. Sourcing Cost: a Unit Cost of $2.30 per each is set for P1_Bullfrog for all customer locations on the Customer Fulfillment Policies input table. For 707 units flowing to the customer, this means the sourcing cost is calculated as: 707 * $2.30 = $1,626.10.
5. Outbound Handling Cost (at the source of the flow): this is calculated as the number of units that are flowing multiplied by the Outbound Handling Cost specified for the facility-product combination (DC_Jacksonville, P1_Bullfrog) in the Warehousing Policies input table (here set to $0.50 per each). Therefore, Outbound Handling Cost = 707 * $0.5 = $353.50.
6. Transportation Cost: because the Unit Cost field in the Transportation Policies table for the DC_Jacksonville toCZ_Hartford lane is set to $0.02 and the accompanying Unit Cost UOM field is set to EA-MI, this cost is calculated as the amount of units that are flowing multiplied by the distance multiplied by the cost of $0.02 per unit per mile. The distance from DC_Jacksonville to CZ_Hartford is calculated at runtime based on the latitudes & longitudes of the locations (specified in the Facilities and Customers input tables) and a 17% circuity factor, which is set in the Circuity Factor field in the Model Settings input table. This distance is 1,093.67 miles. Therefore, the transportation cost = 707 * 1,093.67 mi * $0.02/mi = $15,464.56.
7. In Transit Holding Cost: this is the holding cost based on the time the product is in transit and is calculated as the amount of units being transported multiplied by the fraction of time the transport time represents as compared to a whole year multiplied by the product’s value ($20 per the Unit Value field on the Products input table) multiplied by the inventory carrying cost percentage (12% per the Inventory Carrying Cost Percentage field in the Model Settings input table). The transportation time is calculated from the transportation distance of 1,093.67 mi (see previous bullet) and the Average Speed of 55 mph as set in the Model Settings input table, therefore transportation time = 1,093.67 mi / 55 mph = 19.88 hours. This transport time expressed as a fraction of the year = 17.72 hrs / (365 days * 24 hours/day) = 0.0023. So, the calculation for in transit holding cost becomes: 707 * 0.0023 * $20 * 0.12 = $3.85.
   1. Note that if the Inventory Carrying Cost Percentage field on the Transportation Policies input table is set, this value is used instead of the one specified in the Model Settings input table.

There are cost fields in the Optimization Cost To Serve Path Segment Details output table that are not shown in the above screenshots as these are all blank in the example model used. These fields and their calculations should there be inputs to calculate them are as follows:

1. Segment Shipment Cost: cost resulting from setting a Fixed Cost input on the Transportation Policies input table. The Fixed Cost Rule, Average Shipment Size, and Average Shipment Size UOM fields on the same table also factor into this calculation if specified. See also the Transportation Costs in Optimization help article to understand how these costs are calculated.
2. Segment Fuel Surcharge Cost: cost resulting from setting a Fuel Surcharge input on the Transportation Policies input table. The Fuel Surcharge Basis field on the same table also factors into the calculation if specified.
3. Segment Duty Cost: cost resulting from setting a Duty Rate on the Transportation Policies input table. The Duty Rate is applied as a percentage of the value of product using the transportation lane.
4. Segment Process Cost: cost resulting from setting a Unit Cost and/or Fixed Cost on the Processes input table. The Unit Cost UOM field also factors into the calculation if specified.
5. Segment Supply Cost: cost resulting from setting a Unit Cost on the Supplier Capabilities input table. The Unit Cost UOM field also factors into the calculation if specified.
6. Segment Prebuild Holding Cost: holding costs resulting when Average Prebuild Inventory > 0 on segments where Segment Type = inventories. This can happen due to initial inventory levels or production / inventory constraints, for example. The calculation is similar to the one for turn estimated holding cost detailed above: take the Segment Quantity and divide it by the Average Prebuild Inventory Quantity for the Facility – Product – Period combination (found on the Optimization Inventory Summary), multiply with the product’s value (from Products input table), multiply with the inventory carrying cost percentage (from the Inventory Policies input table if specified, or otherwise from the Model Settings table), and pro-rate it for the length of the period as compared to a year (multiple with # days in the period / 365).
7. Segment Facility Fixed Startup Cost: if a facility is opened, a fixed startup cost based on the value set in the Fixed Startup Cost field in the Facilities table is applied. This cost is allocated to flows where the location is the source and split out based on the segment flow amount divided by the total outbound flow amount for the periods where the facility is open. For example:
   1. A model has 4 periods, say 2024, 2025, 2026, and 2027.
   2. The Fixed Startup Cost for MFG_2 is set to $2,500,000 in the Facilities input table; this MFG location is being considered for opening (Status = Consider and Initial State = Potential).
   3. MFG_2 is opened in 2025 and has throughput in periods 2025, 2026, and 2027.
   4. Total throughput quantity for periods 2025-2027 together is 16,550,000 units (can get this number from for example the Optimization Facility Summary output table).
   5. A segment with Segment Origin = MFG_2 and Segment Type = flow has a Segment Quantity of 20,430.
   6. The Segment Facility Fixed Startup Cost allocated to this segment = $2,500,000 * 20,430 / 16,550,000 = $3,086.10.
8. Segment Facility Fixed Closing Cost: if a facility is closed, a fixed closing cost based on the value set in the Fixed Closing Cost field in the Facilities table is applied in the period of the facility closing. This cost is allocated to all flows in the period(s) prior to closing the facility where the location is the segment origin and split out based on the segment flow amount divided by the total outbound flow amount in the period(s) prior to closing. For example:
   1. A model has 4 periods, say 2024, 2025, 2026, and 2027.
   2. The Fixed Closing Cost for DC_1 is set to $120,000 in the Facilities input table; this DC is being considered for closing (Status = Consider and Initial State = Existing)
   3. DC_1 has throughput in periods 2024 and 2025 and is closed in 2026.
   4. Total throughput quantity for periods 2024 and 2025 together is 387,442 units (can get this number from for example the Optimization Facility Summary output table).
   5. A segment with Segment Origin = DC_1 and Segment Type = flow has a Segment Quantity of 1,320.
   6. The Segment Facility Fixed Closing Cost allocated to this segment = $120,000 * 1,320 / 387,442 = $408.84.
   7. Note that if facility DC_1 is closed in the first period of the model (2024 here), there are no flows to allocate the fixed closing cost to. The Optimization Cost To Serve Path Segment Details output table will then have 1 record for this location with Path Origin = Path Destination = Segment Origin = Segment Destination = DC_1, where both Path Product Name and Segment Product Name are blank, Segment Type = no_activity, and Segment Quantity = 0 and the whole Facility Fixed Closing Cost of $120,000 is allocated to this record in the Segment Facility Fixed Closing Cost field.
9. Segment Work Center Fixed Operating Cost: if a work center has any productions, a fixed operating cost based on the value set in the Fixed Operating Cost field in the Work Centers input table is applied in each period. This cost is divided over all productions on the Work Center during that specific period. The calculation is: Period’s Work Center Fixed Operating Cost * Segment Quantity / Period’s Total Production Quantity on the Work Center (this last number can be found in the Optimization Work Center Summary output table for example).
   1. Note that if a work center has no productions in a certain period, but Work Center Fixed Operating costs are applied, then for this period there will be a record in the Optimization Cost To Serve Path Segment Details output table with Path Origin = Path Destination = Segment Origin = Segment Destination = facility where the work center is located, where both Path Product Name and Segment Product Name are blank, Segment Type = no_activity, and Segment Quantity = 0 and the whole Fixed Operating Cost of the period is allocated to this record in the Segment Work Center Fixed Operating Cost field.
10. Segment Work Center Fixed Startup Cost: if a work center is opened, a fixed startup cost based on the value set in the Fixed Startup Cost field in the Work Centers table is applied. This cost is divided over all productions on the Work Center during the period(s) it is open. For example:
    1. A model has 5 periods, say YEAR1, YEAR2, YEAR3, YEAR4, and YEAR5.
    2. The Fixed Startup Cost for PLT_1_NewLine is set to $50,000 in the Work Centers input table; this work center is considered to be opened (Status = Consider, Initial State = Potential).
    3. PLT_1_NewLine stays closed in the first 2 periods, YEAR1 and YEAR2, and opens from YEAR3 onwards.
    4. The total production quantity at this work center in YEAR3, YEAR4, and YEAR5 together is 106,983 units (can get this number from the Optimization Work Center Summary output table).
    5. A segment with Segment Type = production and a Process Name which has 1 step that uses the PLT_1_NewLine work center has a Segment Quantity of 469.65.
    6. The Segment Work Center Fixed Startup Cost allocated to this segment = $50,000 * 469.65 / 106,983 = $219.50.
11. Segment Work Center Fixed Closing Cost: if a work center is closed, a fixed closing cost based on the value set in the Fixed Closing Cost field in the Work Centers table is applied. This cost is allocated to all productions on this work center in the period(s) prior to closing the work center. For example:
    1. A model has 5 periods, say YEAR1, YEAR2, YEAR3, YEAR4, and YEAR5.
    2. The Fixed Closing Cost for PLT_1_ExistingLine is set to $75,000 in the Work Centers input table; this work center is considered to be closed (Status = Consider, Initial State = Existing).
    3. PLT_1_ExistingLine has throughput in the first 4 periods, YEAR1-YEAR4, and closes in YEAR 5.
    4. The total production quantity at this work center in periods YEAR1-YEAR4 together is 320,000 units (can get this number from the Optimization Work Center Summary output table).
    5. A segment with Segment Type = production and a Process Name which has 1 step that uses the PLT_1_ExistingLine work center has a Segment Quantity of 150.
    6. The Segment Work Center Fixed Closing Cost allocated to this segment = $75,000 * 150 / 320,000 = $35.16

Segment Type = inventories

In the above examples we have seen Segment Types of production and flow. When inventory is modelled, we will also start seeing segments with Segment Type = inventories, as shown in this next screenshot (Cosmic Frog outputs of the Optimization Cost To Serve Path Segment Details table were copied into Excel from which the screenshot was then taken):

Here, 75.41 units of product P4_Polliwog were produced at MFG_Detroit in period 2025 (segment 1), then moved to DC_Jacksonville in the same period (segment 2), where they have been put into inventory (segment 3). These units are then used to fulfill customer demand at CZ_Columbia in the next period, 2026 (segment 4).

Segment Type = no_activity

The Optimization Cost To Serve Path Segment Details table can also contain records which have Segment Type = no_activity. On these records there is no Segment Origin – Segment Destination pair, just one location which is not being used during the period (0 throughput). This record is then used to allocate fixed operating, startup, and/or closing costs to that location.

Additional Fields

There are still a few fields in the Optimization Cost To Serve Path Segment Details table that have not been covered so far, these are:

• Mode Name: the transportation Mode used for the segment, which can be populated for segments with Segment Type = flow.
• Segment Revenue: the revenue associated with the segment, which can be populated for flow segments where the segment destination is a customer location.
• Segment User Defined Cost: if the model uses user defined variables and costs, the resulting total user defined costs will be allocated to individual segments.

Optimization Cost To Serve Path Summary Output Table

The Optimization Cost To Serve Path Summary table is an output table which is an aggregation of the Optimization Cost To Serve Path Segment Details table, aggregated by Path ID. In other words, the table contains 1 record for each path where all costs of the individual segments of the path are rolled up into 1 number. Therefore, this table contains many of the same fields as the Path Segment Details table, just not the segment specific ones. The next screenshot shows the record for Path ID = 1 of the Optimization Cost To Serve Path Summary table:

1. We are on the Optimization Cost To Serve Path Summary output table.
2. The unique Path ID for each path is listed in this field. If wanting to understand the individual segments of a path, user can use this ID to filter the Optimization Cost To Serve Path Segment Details table with.
3. A path is characterized by its Path Origin, Path Destination, and Path Product Name. The Path Demand Quantity is also listed.
4. Path Cost – the total cost of the path. This is the sum of individual cost buckets, which are also listed in this table (not shown in screenshot above). It is also the sum of the Segment Cost field of all segments of this path.

Optimization Cost To Serve Summary Output Table

This output table summarizes the cost to serve at the customer-product-period level and this table can be used to create reports at the customer or product level by aggregating further.

1. We are on the Optimization Cost To Serve Summary output table.
2. Period Name, Site Name, Product Name – the names of the period, customer, and product for which this record shows the cost to serve numbers.
3. Cost, Revenue, and Quantity – the total cost, revenue and quantity for the given period-customer-product combination.
4. Per Unit Cost and Per Unit Revenue – the calculated per unit cost and per unit revenue. These are calculated as the total Cost (from bullet 3) or total Revenue (also from bullet 3) divided by the Quantity (also from bullet 3). These numbers can be used to compare with other period-customer-product combinations to see which combinations are most profitable, and which are least.
5. In this highlighted record for product P1_Bullfrog at customer CZ_Austin during the 2025 period of the model, we see that the total cost and quantity lead to a per unit cost of $27.53 and a per unit revenue of $45.

Note that all these 3 output tables can also be used in the Analytics module of Cosmic Frog to create any cost to serve dashboards. For example, this Optimization Cost To Serve Summary output table is used in 2 standard analytics dashboards that are part of any new Cosmic Frog model and will be automatically populated when this table is populated after a network optimization (Neo) run: the “CTS Unprofitable Demand” and “CTS Customer Profitability” dashboards. Here is a screenshot of the charts included in this second dashboard:

To learn more about the Analytics module in Cosmic Frog, please see the help center articles on this page.

Example with Production Details

In the above discussion of cost to serve outputs, the example model used did not contain any detailed production inputs, such as Bills Of Materials (BOMs), Work Centers, or Processes. We will now look at an example where these are used in the model and specifically focus on how to interpret the Optimization Cost To Serve Path Segment Details output table when bills of materials are included.

Consider the following records in the Bills of Materials input table for making the finished good FG_BLU (blue cheese):

1. The first BOM, BOM_BULK_BLU, is to make the bulk material for blue cheese and it has 3 raw materials as ingredients: RAW_ADDITIVE, RAW_MILK, and RAW_RENNET. To make 1 unit of bulk blue cheese, 0.1 units of RAW_ADDITIVE, 5 units of RAW_MILK, and 0.01 units of RAW_RENNET are used.
2. The second BOM, BOM_FG_BLU, is to make the finished good from the bulk material. 1 unit of BULK_BLU is used to make 1 unit of FG_BLU.

In the model, these BOMs are associated through Production Policies for the BULK_BLU and FG_BLU products.

Next, we will have a look at the Optimization Cost To Serve Path Segment Details output table to understand how costs are allocated to raw material vs finished good segments:

1. The column names here are: Segment Sequence, Segment Origin, Segment Destination, Segment Type, Segment Product Name, Segment Quantity, and Demand Quantity.
2. BOM Name and Process Name are 2 columns that are now populated for certain segments too, these contain the used Bill of Materials or Process, respectively.
3. This path contains 8 segments, which are sorted top to bottom from 1 to 8. This path represents the part of creating FG_BLU from the raw material RAW_ADDITIVE:
   1. Segment 1: 168 units of RAW_ADDITIVE are produced at a supplier location, SUP_1.
   2. Segment 2: these 168 units are moved from SUP_1 to manufacturing site PLT_1.
   3. Segments 3 and 4: at PLT_1 the Bill of Materials named BOM_BULK_BLU is used to create in total 1,680 units of BULK_BLU (the 4^th segment of each of the green outlined boxes 3, 4, and 5: 32.88 + 3.29 +1,643.84 = 1,680). This uses 168 units of RAW_ADDITIVE (segment 3 in block #3), 16.8 units of RAW_RENNET (segment 3 in block #4), and 8,400 units of RAW_MILK (segment 3 in block #5). So, the total units of raw materials going in are: 168 + 16.8 + 8,400 = 8,584.8. To allocate how much of BULK_BLU is made from either of the 3 raw materials, its ratio of the total is calculated and applied to the 1,680 units of BULK-BLU that are being made. For RAW_ADDITIVE this leads to: (168 / 8,584.8) * 1,680 = 32.88. Note that the segment that indicates the raw material and the amount of it that is used in the bill of materials has segment type = billsofmaterials, while the segment that indicates the product that is being made by the BOM has segment type = production.
   4. Segments 5 and 6: still at PLT_1 the Bill of Materials named BOM_FG_BLU is used to create 32.88 units of FG_BLU from 32.88 units of BULK_BLU. Now, a process is used too: PROC-PLT_1_Line-FG_BLU.
   5. Segment 7: the 32.88 units of FG_BLU are moved from PLT_1 to DC_2.
   6. Segment 8: the 32.88 units of FG_BLU are moved from DC_2 to the end customer CUS_AT, which matches the demand quantity.
4. This is also 1 path that contains 8 segments and represents the part of creating FG_BLU from the raw material RAW_RENNET. The segments are similar to those discussed under bullet 3, except that this raw material is supplied by SUP_3 and the quantity is different since the input into the BOM is 0.01 unit of RAW_RENNET for 1 unit of BULK_BLU.
5. Again, this is 1 path that contains 8 segments and represents the part of creating FG_BLU from the raw material RAW_MILK. The segments are similar to those discussed under bullets 4 and 5, and this raw material is also supplied by SUP_3. The quantity is different since the input into the BOM is 5 units of RAW_MILK for 1 unit of BULK_BLU.
6. The total demand that is fulfilled at this customer = 32.88 + 3.29 + 1,643.84 = 1,680.

As we have seen before, there are many more cost columns in this table, so for each segment these can be reviewed by scrolling right. Finally, let’s look at these 3 paths in the Optimization Cost To Serve Path Summary output table:

Note that the Path Product Name is FG_BLU for these 3 paths and there are no details to indicate which raw materials each of the paths pertains to. If required, this can be looked up using the Path IDs from this table in the Optimization Cost To Serve Path Segment Details output table.