Modelling Returns (Network Optimization)

For various reasons, many supply chains need to deal with returns. This can for example be due to packaging materials coming back to be reused at plants or DCs, retail customers returning finished goods that they are not happy with, defective products, etc. Previously, these returns could mostly be modelled within Cosmic Frog NEO (Network Optimization) models by using some tricks and workarounds. But with the latest Cosmic Frog release, returns are now supported natively, so that the reuse, repurposing, or recycling of these retuned products to help companies reduce costs, minimize waste, and improve overall supply chain efficiency can be taken into account easily.

This documentation will first provide an overview of how returns work in a Cosmic Frog model and then walk through an example model of a retailer which includes modelling the returns of finished goods. The appendix details all the new returns-related fields in several new tables and some of the existing tables.

Modelling Returns – Overview

When modelling returns in Cosmic Frog:

• Product that is being returned, can be returned from the customer location it was delivered to back to the appropriate facility, which can be different from the one that supplied it to the customer in the first place.
• If there are multiple possible locations for a product to be returned to, this can be set up and the model can be allowed to pick the optimal return location(s), pick an optimal single location from multiple possible return locations, or will be set to follow specified rules about ratios of returns to multiple locations.
• The returned product can be different from the delivered product. This can for example be the case when packaging material is concerned.
• The amount of product that is returned is specified as a ratio of the amount of delivered product. For example, a return ratio of 15% means that for every 100 units of product delivered, 15 units of the return-product are returned.
• An important assumption to keep in mind is that the returned product arrives at the return destination immediately, i.e. in the same period as the original product delivery and can be reused within the same period.

Returns Input tables

Users need to use 2 new input tables to set up returns:

1. Use the Module Menu to go to the Data module in Cosmic Frog
2. If the Input Tables list is not showing, click on the first of the 3 icons on the right-hand side at the top of the tables list.
3. Go to the Sourcing section of the Input Tables list.
4. There are 2 new tables here which are needed to be populated when modelling returns: Return Policies and Return Ratios.

The Return Ratios table contains the information on how much return-product is returned for a certain amount of product delivered to a certain destination:

1. The first record in the Return Ratios table indicates that when Space Suits are delivered to Customers, Space Suits (the same product) are returned. Since the Return Ratio is set to 50, this means half (50%) of all Space Suits delivered to Customers are being returned.
2. The second record in the Return Ratios table indicates that when Consumables are delivered to Customers, Packaging (a different product) is returned. Since the Return Ratio is set to 10, this means that the amount of Packaging returned is equal to 10% of the number of Consumables delivered. In other words, for 10 units of Consumables delivered to Customers, 1 unit of the Packaging product is returned.

The Return Policies table is used to indicate where returned products need to go to and the rules around multiple possible destinations. Optionally, costs can be associated with the returns here and a maximum distance allowed for returns can be entered on this table too.

1. The first record in the Return Ratios table indicates that when the Packaging product is returned from Customers, it will go to any of the DCs (Destination Name = DCs = a group of all DCs in the model). The Optimization Policy field is left blank here, which means the default of “To Optimize” will be used, where the model determines which DC(s) the Packaging product will be returned to based on overall cost.
2. The second record in the Return Ratios table indicates that when the Space Suits product is returned from customers, it will also go to any of the DCs. With no Optimization Policy defined, it will also use the default “To Optimize”.

Note that both these tables have Status and Notes fields (not shown in the screenshots), like most Cosmic Frog input tables have. These are often used for scenario creation where the Status is set to Exclude in the table itself and changed to Include in select scenarios based on text in the Notes field.

All columns on these 2 returns-related input table are explained in more detail in the appendix.

Other Input Tables

In addition to populating the Return Policies and Return Ratios tables, users need to be aware that additional model structure needed for the returned products may need to be put in place:

• Transportation Policies – to create and optionally cost the lanes to be used to get the return-product from the customer location it was delivered to back to the location(s) it is returned to. Whether you need to set up Transportation Policies depends on the Lane Creation Rule network optimization run parameter. Please see this Help Center article for a more detailed explanation of the Lane Creation Rule parameter. When set to:
  • Transportation Policies Only – Transportation Policies need to be added for the return lanes. Note that Return Policies are still required in this setup too.
  • Sourcing Policies Only – Transportation Policies do not need to be added for the return lanes, the ones set up in the Return Policies table (in the Sourcing section of the input tables) are sufficient to create the return lanes.
  • Intersection – Transportation Policies need to be added for the return lanes.
  • Union – Transportation Policies can be added, for example for transport costing purposes.
• Inventory Policies – if the returned product needs to be able to stay in inventory and/or inventory holding costs need to be applied, inventory policies at the location(s) the product(s) are returned to need to be added if these do not yet exist.
• Warehousing Policies – if inbound and/or outbound costs need to be captured for returned products, warehousing policies at the location(s) the product(s) are returned to need to be added if these do not yet exist.
• Bills of Materials – if the returned product is consumed to create new finished goods from, bills of materials at the location(s) the product(s) are returned to or elsewhere in the supply chain (e.g. further upstream) may need to be added if these do not yet exist.

Returns Output Tables

The Optimization Return Summary output table is a new output table that will be generated for Neo runs if returns are included in the modelling:

1. The first record shows that for scenario “S1 Include Returns”, 8,850 units of product Bag_1 were delivered to customer CZ_001, and that 876.15 units of the same product Bag_1 were returned.
2. The second record shows that for scenario “S1 Include Returns”, 422 units of product Bag_2 were delivered to customer CZ_01, and that 7.6 units of the same product Bag_2 were returned.

This table and all its fields are explained in detail in the appendix.

The Optimization Flow Summary output table will contain additional records for models that include returns; they can be identified by filtering the Flow Type field for “Return”:

These 2 records show the return flows and associated transportation costs for the Bag_1 and Bag_2 products from CZ_001, going to DC_Cincinnati, that we saw in the Optimization Return Summary table screenshot above.

Other Output Tables

In addition to the new Optimization Return Summary output table, and new records of Flow Type = Return in the Optimization Flow Summary output table, following existing output tables now contain additional fields related to returns:

• Optimization Demand Summary: Return Quantity, Return Volume, and Return Weight – how much of any served demand (by scenario-customer-product-period) is returned in terms of units, volume, and weight.
• Optimization Customer Summary: Total Return Quantity, Total Return Volume, and Total Return Weight – how much (by scenario-customer-period) is returned in terms of units, volume, and weight.
• Optimization Network Summary:
  • Total Return Quantity, Total Return Volume, and Total Return Weight – how much (by scenario) is returned in terms of units, volume, and weight.
  • Total Return Cost: what is the total cost associated with returns by scenario.

Example Returns Model

Introduction

The example Returns model can be copied from the Resource Library to a user’s Optilogic account (see this help center article on how to use the Resource Library). It models the US supply chain of a fashion bag retailer. The model’s locations and flows both to customers and between DCs are shown in this screenshot (returns are not yet included here):

Historically, the retailer had 1 main DC in Cincinnati, Ohio, where all products were received and all 869 customers were fulfilled from. Over time, 4 secondary DCs were added based on Greenfield analysis, 2 bigger ones in Clovis, California, and Jersey City, New Jersey, and 2 smaller ones in West Palm Beach, Florida, and Las Lomas, Texas. These secondary DCs receive product from the Cincinnati DC and serve their own set of customers. The main DC in Cincinnati and the 2 bigger secondary DCs (Clovis, CA, and Jersey City, NJ) can handle returns currently: returns are received there and re-used to fulfill demand. However, until now, these returns had not been taken into account in the modelling. In this model we will explore following scenarios:

1. Baseline – how the network operates currently with the main DC and 4 secondary DCs, not taking returns into account.
2. S1 Include Returns – as Baseline, plus add returns to the model: customers served by Clovis, CA and Jersey City, NJ return their products to these secondary DCs, while customers served by the Cincinnati, West Palm Beach and Las Lomas DCs all return their products to the main Cincinnati DC.
3. S2 Include Returns West Palm Beach – as S1, except that we now create the capability at the West Palm Beach DC to accept returns from the local customers to see if that would be beneficial.
4. S3 Include Returns Las Lomas – as S1, except that we now create the capability at the Las Lomas DC to accept returns from the local customers to see if that would be beneficial.
5. S4 Include Returns (all local DCs) – if S2 and S3 both look positive (i.e. reducing overall cost as compared to S1), then this scenario will be run where all customers can return their products to their local DC.

Other model features:

1. Two finished goods, for which all of the 869 customers have demand, are included: Bag_1 (value: 20, price: 35) and Bag_2 (value: 25, price: 42). See the Products and Customer Demand tables.
2. Groups are being used in this model to facilitate setting up policies for products/locations that behave in the same way. See the Groups table which contains following groups:
   1. All_Products – contains the 2 products in the model, Bag_1 and Bag_2
   2. All_DCs – contains all 5 DCs, the main one in Cincinnati and the 4 secondary ones
   3. Secondary_DCs – contains the 4 secondary DCs
   4. All_Customers – contains all 869 customers
   5. Cincinnati_Customers – contains the subset of customers served by the DC in Cincinnati, OH
   6. Clovis_Customers – contains the subset of customers served by the DC in Clovis, CA
   7. Jersey City_Customers – contains the subset of customers served by the DC in Jersey City, NJ
   8. Las Lomas_Customers – contains the subset of customers served by the DC in Las Lomas, TX
   9. West Palm Beach_Customers – contains the subset of customers served by the DC in West Palm Beach, FL
3. Costs included in the model:
   1. In the model both products originate at the Cincinnati DC where a production unit cost is entered, this is essentially the procurement cost. For Bag_1 this cost is 15 and for Bag_2 it is 20. See the Production Policies table.
   2. Depending on the type of lane, there are different costs associated with transport, see the Transportation Policies table:
      1. The transportation cost on the linehaul lanes from the main DC in Cincinnati to the 4 secondary DCs is 0.0001 per unit per mile.
      2. The LTL cost of transport from any of the 5 DCs to their local customers is 0.02 per unit per mile.
      3. When returns are taken into account from scenario S1 onwards, the transportation cost for these from the local customer to either its local DC or the Cincinnati DC is set to 0.04 per unit per mile.
   3. All 5 DCs have the same inbound and outbound handling costs for both products, which is set to 1 per unit. See the Warehousing Policies table.
   4. The DCs have fixed operating costs associated with them. The yearly cost for the main Cincinnati DC is 25M, for the 2 bigger secondary DCs (Clovis and Jersey City) 5M, and for the 2 smaller secondary DCs (West Palm Beach and Las Lomas) 3M. In scenarios S2, S3, and S4 the operating costs for the 2 smaller DCs are increased to 3.5M to model the cost for adding the capability to handle returns at these facilities. See the Facilities table.

Please note that in this model the order of columns in the tables has sometimes been changed to put those containing data together on the left-hand side of the table. All columns are still present in the table but may be in a different position than you are used to. Columns can be reset to their default position by choosing “Reset Columns” from the menu that comes up when clicking on the icon with 3 vertical dots to the right of a column name.

Baseline Scenario

After running the baseline scenario (which does not include returns), we take a look at the Financials: Scenario Cost Comparison chart in the Optimization Scenario Comparison dashboard (in Cosmic Frog’s Analytics module):

We see that the biggest cost currently is the production cost at 394.7M (= procurement of all product into Cincinnati), followed by transportation costs at 125.9M. The total supply chain cost of this scenario is 625.3M.

S1 Include Returns Scenario

In this scenario we want to include how returns currently work: Cincinnati, Clovis, and Jersey City customers return their products to their local DCs whereas West Palm Beach and Las Lomas customers return their products to the main DC in Cincinnati. To set this up, we need to add records to the Return Policies, Return Ratios, and Transportation Policies input tables. To not change the Baseline scenario, all new records will be added with Status = Exclude, and the Notes field populated so it can be used to filter on in scenario items that change the Status to Include for subsets of records. Starting with the Return Policies table:

1. We use the groups of local customers in the Site Name field to set the source of the returned product. When running the model, the group will be enumerated into all its members.
2. The Return Product Name field also uses a group, the one that contains the 2 products in the model. When running the model, this group will also be enumerated into the 2 members.
3. The first 5 records in this table will be included in scenario S1 based on the Notes field containing S1. Note that the remainder of the Notes field also indicates which other scenario(s) the record will be included in.
4. The Destination Name indicates which DC the returns will go to. As mentioned above, for scenario S1, this is the Cincinnati DC for the Cincinnati, Las Lomas, and West Palm Beach customers (rows 4, 2, and 1, respectively), and the local DC for the Clovis and Jersey City customers (rows 5 and 3, respectively). Note that this field can also contain a group of destinations instead of a single destination.
5. This record where the West Palm Beach customers return product to their local DC is set up in anticipation of scenarios S2 and S4 in which it will be included.
6. Similarly, this record where the Las Lomas customers return product to their local DC is set up in anticipation of scenarios S3 and S4 in which it will be included.
7. The Optimization Policy field is set to Single Destination here, which means that if multiple possible destinations are set up for 1 source location to return product to, the optimization needs to select 1 of these destinations (the one that will lead to the overall lowest costs) to ship all returns to. Note that since we will only allow 1 return destination for each customer in each scenario, the optimization policy of Single Destination is not actually used in this model to make decisions around return destinations. See the appendix for additional available optimization policies.

Next, we need to add records to the Transportation Policies table so that there is at least 1 lane available for each site-product-destination combination set up in the return policies table. For this example, we add records to the Transportation Policies table that match the ones added to the Return Policies table exactly, while additionally setting Mode Name = Returns, Unit Cost = 0.04 and Unit Cost UOM = EA-MI (the latter is not shown in the screenshot below), which means the transportation cost on return lanes is 0.04 per unit per mile:

Finally, we also need to indicate how much product is returned in the Return Ratios table. Since we want to model different ratios by individual customer and individual product, this table does not use any groups. Groups can however be used in this table too for the Site Name, Product Name, Period Name, and Return Product Name fields.

1. The Site Name and Product Name fields specify the location-product combination for which the record is being set up. In this example model, a record is added for each customer-product combination (= 869 * 2 = 1,738 records). These 2 are for customer CZ_001, 1 for Bag_1 and 1 for Bag_2.
2. The Return Product Name field indicates which product is returned for this site-product combination. It can be the same product as is the case in this example, or it could be a different product or part of a product.
3. In the Return Ratio field, the amount of product that is returned needs to be indicated. This is a percentage of the amount of product going to this site (the combination from bullet 1 above): for the first record this is set to 9.9, meaning that for 100 units of Bag_1 sent to CZ_001, 9.9 units of Bag_1 will be returned. The return ratios used in this example model are between 7% and 17% for Bag_1 and between 1% and 5% for Bag_2.
4. In a multiperiod model, user could set different return ratios for different periods if so desired.

Please note that adding records to these 3 tables and including them in the scenarios is sufficient to capture returns in this example model. For other models it is possible that additional tables may need to be used, see the Other Input Tables section above.

Now that we have populated the input tables to capture returns, we can set up scenario S1 which will change the Status of the appropriate records in these tables from Exclude to Include:

1. A scenario named “S1 Include Returns” has been added. It has 3 scenario items:
2. The first scenario item is called “Include Return Policies S1”; its configuration is shown on the right hand-side:
   1. Return Policies is selected from the Table Name drop-down list as this is the table we want to make the scenario change on.
   2. In the Actions field, we typed “status = ‘Include’” which will set the Status field of the filtered records on this table to Include.
   3. The Condition Builder is used in the Conditions section; we typed “notes like ‘%S1%’” here, which means any record where the Notes field contains the text S1 (either it begins with S1, ends with S1, or contains the text somewhere in between) will be filtered out and the scenario change will be made to it. See also this Help Center article on syntax for conditions.
3. The second scenario item is called “Include Return TPs S1”. Its configuration is not shown here, but it is similar to that of the previous scenario item, except that Transportation Policies has been selected in the Table Name drop-down list.
4. The third scenario item is called “Include Return Ratios”. Its configuration is not shown here, but it is also similar to that of the first scenario item described in bullet 2 above, except that 1) Table Name is set to the Return Ratios table, and 2) no condition is applied, the change is made to all records in the table.

After running this scenario S1, we are first having a look at the map, where we will be showing the DCs, Customers and the Return Flows for scenario S1. This has been set up in the map named Supply Chain (S1) in the model from the Resource Library. To set this map up, we first copied the Supply Chain (Baseline) map and renamed it to Supply Chain (S1). Then clicked on the map’s name (Supply Chain (S1)) to open it and in the Map Filters form that is showing on the right-hand side of the screen changed the scenario to “S1 Include Returns” in the Scenario drop-down. To configure the Return Flows, we added a new Map Layer, and configured its Condition Builder form as follows (learn more about Maps and how to configure them in this Help Center article):

1. The name of this layer is “Return flows”.
2. The layer is drawn from the Optimization Flow Summary output table which has been selected in the Table Name drop-down list.
3. The Condition Builder is used to filter this output table just for records where Flow Type = return.

The resulting map is shown in this next screenshot:

We see that, as expected, the bulk of the returns are going back the main DC in Cincinnati: from its local customers, but also from the customers served by the 2 smaller DCs in Las Lomas and West Palm Beach DCs. The customers served by the Clovis and Jersey City DCs return their products to their local DCs.

To assess the financial impact of including returns in the model, we again look at the Financials: Scenario Cost Comparison chart in the Optimization Scenario Comparison dashboard, comparing the S1 scenario to the Baseline scenario:

We see that including returns in S1 leads to:

1. A 4M increase in transportation costs: from 125.9M in the Baseline to 167.3M in S1. This is due to the 0.04 per unit per mile transport cost that is associated with returns, and some of the returns traveling quite long distances from the Las Lomas and West Palm Beach customers all the way to the Cincinnati DC.
2. A 5M decrease in production costs: from 394.7M in the Baseline to 357.2M in the S1 scenario. This is due to being able to reuse the returns to fulfil demand, so about 10% less product needs to be procured.
3. The fixed operating costs are the same for the 2 scenarios.
4. An increase in inbound handling costs by close to 1M because the Cincinnati DC receives product due to the returns from 2 of the secondary DCs.
5. A decrease in the outbound handling costs at the Cincinnati DC by about 2.5M since it needs to ship out less product to the 2 secondary DCs that handle their own returns (Clovis and Jersey City) as these reuse their returns to fulfill some of the demand.
6. Overall, the total cost in the S1 scenario is close to 3.4M higher than the Baseline scenario.

Seeing that the main driver for the overall supply chain costs being higher when including returns are the high transportation costs for returning products, especially those travelling long distances from the Las Lomas and West Palm Beach customers to the Cincinnati DC sparks the idea to explore if it would be more beneficial for the Las Lomas and/or West Palm Beach customers to return their products to their local DC, rather than the Cincinnati DC. This will be modelled in the next three scenarios.

Return to Local DC Scenarios

Building upon scenario S1, we will run 2 scenarios (S2 and S3) where it will be examined if it is beneficial cost-wise for West Palm Beach customers to return their products to their local West Palm Beach DC (S2) and for Las Lomas customers to return their products to their local Las Lomas DC (S3) rather than to the Cincinnati DC. In order to be able to handle returns, the fixed operating costs at these DCs are increased by 0.5M to 3.5M:

1. Scenario “S2 Include Returns West Palm Beach” has been added. It contains 3 scenario items that are very similar to the 3 included in the “S1 Include Returns” scenario, except that the filtering on the tables is not for S1 in the Notes field, but for S2:
   1. Include Return Policies S2: in this item the Status of all records on the Return Policies table that contain “S2” in the Notes field is changed to Include
   2. Include Return TPs S2: in this item the Status of all records on the Transportation Policies table that contain “S2” in the Notes field is changed to Include
   3. Include Return Ratios: this is the same item as included in S1 to change the Status of all records on the Return Ratios table to Include
2. A new scenario item “Incr Operating Cost S2” has been added, its configuration can be seen on the right-hand side:
   1. The table to be updated is the Facilities table
   2. The field to be updated is the Fixed Operating Cost field and it will be set to 3.5M
   3. A condition is applied so that the change is only made to the record where the Facility Name is DC_West Palm Beach
3. Similarly, scenario S3 is set up so that the Status of the records that include “S3” in the Notes field on the Return Policies and Transportation Policies tables is changed to Include, the Status is set to Include for all records on the Return Ratios table, and the Fixed Operating Costs of DC_Las Lomas are increased to 3.5M.

Scenarios S2 and S3 are run, and first we look at the map to check the return flows for the West Palm Beach and Las Lomas customers, respectively (copied the map for S1, renamed it, and then changed the scenario by clicking on the map’s name and selecting the S2/S3 scenario from the Scenario drop-down in the Map Filters pane on the right-hand side):

As expected, due to how we set up these scenarios, now all returns from these customers go to their local DC, rather than to DC-Cincinnati which was the case in scenario S1.

Let us next look at the overall costs for these 2 scenarios and compare them back to the S1 and Baseline scenarios:

Besides some smaller reductions in the inbound and outbound costs in S2 and S3 as compared to S1, the transportation costs are reduced by sizeable amounts: 6.9M (S2 compared to S1) and 9.4M (S3 compared to S1), while the production (= procurement) costs are the same across these 3 scenarios. The reduction in transportation costs outweighs the 0.5M increase in fixed operating costs to be able to handle returns at the West Palm Beach and Las Lomas DCs. Also note that both scenario S2 and S3 have a lower total cost than the Baseline scenario.

Since it is beneficial to have the West Palm Beach and Las Lomas DCs handle returns, scenario S4 where this capability is included for both DCs is set up and run:

The S4 scenario increases the fixed operating costs at both these DCs from 3M to 3.5M (scenario items “Incr Operating Cost S2” and “Incr Operating Cost S3”), sets the Status of all records on the Return Ratios table to Include (the Include Return Ratios scenario item), and sets the Status to Include for records on the Return Policies and Transportation Policies tables where the Notes field contains the text “S4” (the “Include Return Policies S4” and “Include Return TPs S4” items), which are records where customers all ship their returns back to their local DC. We first check on the map if this is working as expected after running the S4 scenario:

We notice that indeed there are no more returns going back to the Cincinnati DC from Las Lomas or West Palm Beach customers.

Finally, we expect the costs of this scenario to be the lowest overall since we should see the combined reductions of scenarios S2 and S3:

Between S1 and S4:

1. The total transportation cost reduction is 16.2M.
2. The production (= procurement) costs are the same.
3. The increase in fixed operating cost is 1M.
4. The combined decrease in inbound and outbound handling costs is about 0.9M.
5. Overall, scenario S4’s total cost is 612.6M, which is a reduction of 16.1M (or about 2.6%) as compared to S1 (628.7M).

Additional Table Outputs

In addition to looking at maps or graphs, users can also use the output tables to understand the overall costs and flows, including those of the returns included in the network.

Often, users will start by looking at the overall cost picture using the Optimization Network Summary output table, which summarizes total costs and quantities at the scenario level:

For each scenario, we are showing the Total Supply Chain Cost and Total Return Quantity fields here. As mentioned, the Baseline did not include any returns, whereas scenarios S1-4 did, which is reflected in the Total Return Quantity values. There are many more fields available on this output table, but in the next screenshot we are just showing the individual cost buckets that are used in this model (all other cost fields are 0):

How these costs increase/decrease between scenarios has been discussed above when looking at the “Financials: Scenario Cost Comparison” chart in the “Optimization Scenario Comparison” dashboard. In summary:

• Including returns as they are set up today increases the transportation cost by more than the production costs is reduced and therefore the total cost of S1 is higher when compared to the Baseline.
• Scenarios S2 and S3 show a sizeable reduction in transportation cost by returning product to the local DCs rather than to the main Cincinnati DC by the customers served by those 2 smaller DCs (West Palm Beach and Las Lomas).
• Therefore, S4 is set up and run to see the total benefit of both these DCs handling returns, where it is very clear that the 1M increase in fixed operating costs is by far offset by the reduction in transportation costs.

Please note that on this table, there is also a Total Return Cost field. It is 0 in this example model. It would be > 0 if the Unit Cost field on the Return Policies table had been populated, which is a field where any specific cost related to the return can be captured. In our example Returns model, the return costs are entirely captured by the transportation costs and fixed operating costs specified.

The Optimization Return Summary output table is a new output table that has been added to summarize returns at the scenario-returning site-product-return product-period level:

Looking at the first record here, we understand that in the S1 scenario, CZ_001 was served 8,850 units of Bag_1, while 876.15 units of Bag_1 were returned.

Lastly, we can also see individual return flows in the Optimization Flow Summary table by filtering the Flow Type field for “Return”:

Note that the product name for these flows is of the product that is being returned.

Example: Reuse Percentage of Returns

The example Returns model described above assumes that 100% of the returned Bag_1 and Bag_2 products can be reused. Here we will discuss through screenshots how the model can be adjusted to take into account that only 70% of Bag_1 returns and 50% of Bag_2 returns can be reused. To achieve this, we will need to add an additional “return” product for each finished good, set up bills of materials, and add records to the policies tables for the required additional model structure.

The tables that will be updated and for which we will see a screenshot each below are: Products, Groups, Return Policies, Return Ratios, Transportation Policies, Warehousing Policies, Bills of Materials, and Production Policies.

Products Table

Two products are added here, 1 for each finished good: Bag_1_Return and Bag_2_Return. This way we can distinguish the return product from the sellable finished goods, apply different policies/costs to them, and convert a percentage back into the sellable items. The naming convention of adding “_Return” to the finished good name makes for easy filtering and provides clarity around what the product’s role is in the model. Of course, users can use different naming conventions.

The same unit value as for the finished goods is used for the return products, so that inventory carrying cost calculations are consistent. A unit price (again, same as the finished goods) has been entered too, but this will not actually be used by the model as these “_Return” products are not used to serve customer demand.

Groups Table

To facilitate setting up policies where the return products behave the same (e.g. same lanes, same costs, etc.), we add an “All_Return_Products” group to the Groups table, which consists of the 2 return products:

Return Policies Table

In the Return Policies table, the Return Product Name column needs to be updated to reflect that the products that are being returned are the “_Return” products. Previously, the Return Product Name was set to the All_Products group for each record, and it is now updated to the All_Return_Products group. Updating a field in all records or a subset of filtered records to the same value can be done using the Bulk Update Column functionality, which can be accessed by clicking on the icon with 3 vertical dots to the right of the column name and then choosing “Bulk Update this Column” in the list of options that comes up.

Return Ratios Table

We keep the ratios of how much product comes back for each unit of Bag_1 / Bag_2 sold the same, however we need to update the Return Product Name field on all records to reflect that it is the “_Return” product that comes back. Since this table does not use groups because the return ratios are different for different customer-finished good combinations, the best way to update this table is to also use the bulk update column functionality:

1. Filter the table for Product Name equals Bag_1 (or for Return Product Name equals Bag_1)
2. Bulk update the Return Product Name column and set its value to Bag_1_Return
3. Repeat steps 1 and 2 for Bag_2 and bulk update the Return Product Name to Bag_2_Return

Note that only 4 of the 1,738 records in this table are shown in the screenshot below.

Transportation Policies Table

Here, the records representing the lane back from the customers to the DC they send returns back to need to be updated so that the products going back are the “_Return” ones. Since the transportation costs of the return products are the same, we can keep using the grouped policies and just bulk update the Product Name column of the records where Mode Name equals Returns: change the values from the All_Products group to the All_Return_Products group.

Warehousing Policies Table

We want to apply the same inbound and outbound handling costs for the return products as we do for the finished goods, so a record is added for the “All_Return_Products” group at All_DCs in the Warehousing Policies table:

Bills of Materials Table

We can use the Bills of Materials (BOM) table to convert the “_Return” products back into the finished goods, applying the desired percentage that will be suitable for reuse. For Bag_1, we want to set up that 70% of the returns can be reused as finished goods, this is done by setting up a BOM as follows (the first 2 records in the screenshot below):

1. We create a BOM named “Reuse_Bag_1”
2. In the second record we see that this BOM takes 1 unit of the Bag_1_Return Component (the product that is consumed by the BOM)
3. In the first record we see that 0.7 units of End Product (Bag_1) are the result of this BOM.

Similarly, we set up the BOM “Reuse_Bag_2” where 1 unit of Bag_2_Return results in 0.5 units of Bag_2 (the 3^rd and 4^th record in the screenshot):

Production Policies table

For the BOMs to be used, they need to be associated with the appropriate location-product combinations through production policies. So, we add 2 records to the Production Policies table, which set that at All_DCs the finished goods can be produced using the 2 BOMs. The Unit Cost set on this table represents the cost of inspecting each returned bag and deciding whether it can be reused.

Optimization Return Summary Output Table

With all the changes made on the input side, we can run the S1 Include Returns scenario (which was copied and renamed to “S1 Include Returns w BOM”). We will briefly look at how these changes affect the outputs.

In the Optimization Return Summary output table, users will notice that the Product Name is still either Bag_1 or Bag_2, but that the Return Product Name is either Bag_1_Return (for Bag_1) or Bag_2_Return (for Bag_2). The quantities are the same as before, since the return ratios are unchanged.

Optimization Flow Summary Output Table

When looking at records of Flow Type = Return, we now see that the Product Name on these flows is that of the “_Return” products.

Optimization Production Summary Output Table

In this output table, we see that Bag_1 and Bag_2 are no longer only originating from the main DC in Cincinnati, but also at the 2 bigger local DCs that accept returns (Clovis, CA, and Jersey City, NJ) where a percentage of the returns is converted back into sellable finished goods through the BOMs.

Appendix – Returns Tables Field Details

In this appendix we will cover all fields on the 2 new input tables and the 1 new output table.

Return Policies Input Table

• Site Name: the customer of group of customers the return product originates from.
• Return Product Name: the product or group of products that is being returned.
• Destination Name: the facility or group of facilities where the returned product will be sent to.
• Optimization Policy and Optimization Policy Value: the logic to follow when multiple destinations are set up. Options are:
  • To Optimize – the destination(s) to return product and how much to each will be picked from the available ones based on what will result in the lowest overall cost.
  • By Ratio (Auto Scale) – this will enforce a flow split to the specified destinations. The amount of flow to each location is set in the Optimization Policy Value field, it is used as a percentage of the total flow from this customer to all specified destinations. If the percentages add up to more or less than 100%, they are automatically scaled up or down so that the total becomes 100%
  • By Ratio (No Scale) – this will enforce a flow split to the specified destinations, where the flow is the percentage (as set in the Optimization Policy Value field) of the total flow out of this customer. If the percentages add up to less than 100%, the remainder can be sent to any other destination that is set up. If the percentages add up to more than 100%, all will be scaled down proportionally and the policy behaves the same as the By Ratio (Auto Scale) one in this case.
  • Single Destination – multiple destinations for the return product can be set up with this policy, but the optimization engine will have to pick 1 single one of them to ship all returns to, this will be determined based on the destination that will result in the lowest overall cost solution.
• Status – Include: the policy exists in the model run; Exclude: the policy does not exist in the model run. Often switched through scenario items to test different policies in different scenarios.
• Unit Cost – the cost incurred per unit returned for the specified site – return product – destination combination.
• Unit Cost UOM – the unit of measure applied to the unit cost field.
• Max Delivery Range – the maximum distance allowed for this return policy. When using groups for customers and/or destinations, this will remove lanes that are excessively long from consideration immediately.
• Max Delivery Range UOM – the unit of measure applied to the max delivery range field. This UOM needs to be of Type = Distance.
• Notes – free type text field where user can enter text that for example helps with filtering the table for a specific subset of records, which can be helpful when setting up scenarios.

Return Ratios Input Table

• Site Name – the name of the customer of group of customers where the return originates.
• Product Name – the product or group of products that is delivered to the customer (e.g. customer has demand for this product); this is not necessarily the same product as the one that is being returned.
• Period Name – the period or group of periods for which the return ratio is specified.
• Return Product Name – the product or product group that is being returned. This can be the same as or different to the Product Name field value.
• Return Ratio – the amount of return product that will be returned. This is the percentage of the amount of product that is served to this customer in this period. For a return ratio of 25%, enter 25 into this field.
• Status – Include: the record exists in the model run; Exclude: the record is ignored during the model run. Often switched through scenario items to test different records in different scenarios.
• Notes – free type text field where user can enter text that for example helps with filtering the table for a specific subset of records, which can be helpful when setting up scenarios.

Optimization Return Summary Output Table

• Scenario Name – the scenario the record pertains to
• Period Name – the period the record pertains to
• Site Name – the customer location where the return originated
• Product Name – the product that is served to the customer and with which a return is associated
• Served Demand Quantity – the number of units served of this product (Product Name) to this customer (Site Name)
• Return Product Name – the name of the product that is being returned
• Return Quantity – the amount of return product (Return Product Name) being returned in terms of units
• Return Volume – the amount of return product (Return Product Name) being returned in terms of units
• Return Weight – the amount of product (Return Product Name) being returned in terms of units
• Return Cost – the cost associated with returning this product (Return Product Name), this is based on the Unit Cost and Unit Cost UOM fields when used in the Return Policies table.