Customer Demand

Internal Table Name: CustomerDemand

You can use Customer Orders in place of Customer Demand for Network Optimization, Demand Analysis (Safety Stock Optimization), and Simulation.

For each technology, use the Run Options as described below to select demand source:

• Customer Model Demand – Select “Run from Demand table” if you want to use demand as defined in the Customer Demand table. Select “Run from Orders table” if you want to use demand as defined in the Customer Orders table.
• Site Model Demand – Select “Run from Demand table” if you want to use demand as defined in the Site Demand table. Select “Run from Orders table” if you want to use demand as defined in the Site Orders table.

Period

Technology: NO IO S

Table: CustomerDemand

Internal Name: PeriodName

Type: Short Text (100)

Optionally, select the period name to which the demand applies.

For Network Optimization and Inventory Optimization, if you enter a Period , the Series Offset Time is used as an offset from the start of this period. If you do not enter a Period Name, the Series Offset Time is used as an offset from the start of the model horizon.

For Simulation, the Series Offset Time is always used as an offset from the start of the model horizon, regardless of the Period .

Customer

Technology: NO IO S

Table: CustomerDemand

Internal Name: SiteName

Type: Short Text (100)

Enter the Customer or customer group that is requesting the product.

Product

Technology: NO IO S

Table: CustomerDemand

Internal Name: ProductName

Type: Short Text (100)

Enter the product or product group that is being demanded.

Mode

Technology: NO IO S

Table: CustomerDemand

Internal Name: Mode

Type: Short Text (100)

Enter the mode for the demand to use. This will assign the Mode of transportation for this order in both optimization and simulation.

Quantity

Technology: NO IO S

Table: CustomerDemand

Internal Name: Demand

Type: Short Text (50)

RNE Eligible

Enter the amount of product demanded by the customer. Enter a value, then select a quantity, weight or volume unit of measure. If you do not select a unit of measure, the default Quantity Unit Of Measure from Model Settings is used

If a probability distribution is specified, the requirement will be randomly selected each time the demand requirement occurs in Simulation. For Optimization, the mean of the distribution will be used as the demand amount.

Default: 1

Minimum Quantity

Technology: NO

Table: CustomerDemand

Internal Name: MinimumDemand

Type: Short Text (100)

Use this field to define the minimum demand that must be met in Network Optimization. This effectively softens the demand constraint that is in place based on the Quantity. This value can be a number between 0 and the Quantity. When this value is null, the Quantity is used.

If you have multiple records for each Customer-Product in the same Period, the Minimum Quantity is summed over this set of records.

Unit Penalty Cost

Technology: NO

Table: CustomerDemand

Internal Name: DemandPenalty

Type: Number (Float)

Use this field to impose a penalty when total demand Quantity is not satisfied in Network Optimization. You can use this penalty in combination with Minimum Quantity as a soft constraint on demand.

Series Offset Time

Technology: NO IO S

Table: CustomerDemand

Internal Name: PeriodOffsetTime

Type: Short Text (50)

Specify a number or distribution that defines when the order is placed. A value of 0 is the first day of the model horizon. If you have selected a Period and you are using Network Optimization or Inventory Optimization, a value of 0 is the first day of that period. Optionally, select a time unit of measure. If you do not select a unit of measure, the default Time Unit Of Measure from Model Settings is used.

In Simulation, if more than one occurrence is scheduled, then the Series Offset Time field becomes the time of the first Order, and the Order Frequency field dictates the next time an order occurs.

For Network Optimization, the Series Offset Time is used to determine the period in which the demand must be satisfied. For example, assume that your model has weekly periods:

If you have demand with an Series Offset Time of 9, this means that the demand must be satisfied in Period_002. Fixed Order Time and Transport Time must be such that the product can reach the customer in Period_002 or the model is infeasible.

Optimization currently only supports orders with one Occurrence.

Safety Stock Optimization uses Series Offset Time to perform Demand Analysis.

Service Level

Technology: NO IO S

Table: CustomerDemand

Internal Name: DemandLeadTime

Type: Short Text (50)

Used to specify when an order must be filled. Enter a value, then select a time unit of measure. If you do not select a unit of measure, the default Time Unit Of Measure from Model Settings is used.

In Simulation, the order cycle time is the period of time between the occurrence of the order (Series Offset Time) and the time the order was satisfied (arrives at the customer and fulfills demand). When the order arrives at the customer, the current time is checked and compared to the date based on Series Offset Time and Service Level. This determines if a shipment is on time or late.

In Network Optimization, the Service Level field can be used as a constraint. It is used to determine the demand lead time. For example, if you have a Service Level of 2, this indicates a demand lead time of 2 days (or 48 hours). This constraint basically says that demand can only be satisfied from a source which is at most 48 hours away. If you populate the Service Level field for records in a Network Optimization, and then check "Classify Demand By Due Date" in the Optimization Options Constraints tab, it will act as a constraint for flow on the customer flow (the last echelon of the model). The demand with due date constraints will not be able to use any mode or lane that is longer than the specified Service Level.

For example:

Occurrences

Technology: NO IO S

Table: CustomerDemand

Internal Name: Occurrences

Type: Short Text (50)

Enter how many times this demand will occur. A demand must occur at least once. When you enter a number greater than one, demand will occur multiple times.

For example:

Default: 1

Order Frequency

Technology: NO S

Table: CustomerDemand

Internal Name: Frequency

Type: Short Text (50)

For Simulation, the Order Frequency field is used to specify the time between multiple orders. Enter how much time must pass between each recurring demand. Optionally, select a time unit of measure. If you do not select a unit of measure, the default Time Unit Of Measure from Model Settings is used. For example, Order Frequency can be 24 HR, meaning that orders recur every 24 hours for as many occurrences specified.

For optimization, the Order Frequency is ignored if the demand doesn’t have Occurrences defined. If the Occurrences are greater than 1, You must enter data in this field. If you do not enter Order Frequency and demand recurs, the software will assume that this demand happens once a day.

Order Frequency examples are shown below:

Seasonality

Technology: NO IO S

Table: CustomerDemand

Internal Name: SeasonalityName

Type: Short Text (100)

Select the Seasonality that applies to the demand. If a Seasonality is selected, the Factor associated with the Period as defined in the Demand Seasonality Factors is applied to the demand.

If both a Seasonality Name and Trend are assigned to the demand then:

Demand(n) = calculated Avg Quantity * Seasonality Factor(n) * (Trend)^(n-1)

Trend

Technology: NO IO S

Table: CustomerDemand

Internal Name: Trend

Type: Number (Float)

In multi-period models, use the Trend to define a factor that is applied to the demand in a period over period method. For example:

Period 1 demand = calculated Average Quantity

Period 2 demand = calculated Average Quantity * Trend

Period 3 demand = calculated Average Quantity * Trend * Trend

…. Period n demand = calculated Average Quantity * Trend^(n-1)

If both a Seasonality Name and Trend are assigned to the demand then:

Demand(n) = calculated Avg Quantity * Seasonality Factor(n) * (Trend)^(n-1)

Unit Price Override

Technology: NO IO S

Table: CustomerDemand

Internal Name: UnitPriceOverride

Type: Short Text (50)

You can define a customer-specific price for each unit of the product being demanded. This number will then be used to calculate revenue generated by this customer demanding this specific product instead of the value listed in the Price field on the Products Table. Optionally, select a currency to apply to the value. If no currency is selected, the default Currency from Model Settings is used.

If you set Unit Price Override for one or more entries in the Customer Demand table, be aware of the following Optimization behavior:

• When the Unit Price Override field is left blank for all Customer Demand records, the Price field of the Products table will be used to calculate revenue.
• If you have multiple entries in the Customer Demand table for the same Period for the same Customer-Product-Mode combination, and one of them uses the Unit Price field, then this price is used to override the Price of the Products table for this Customer-Product-Mode combination for the whole demand amount in that period. This is because optimization works on aggregates and not individual orders.
• If you have multiple entries in the Customer Demand table for the same Period for the same Customer-Product-Mode combination, and a number of these use the Unit Price Override field, the straight average of these Unit Price Override numbers is used for the entire demand amount in that Period for this Customer-Product-Mode combination.
• The Price is a weighted average of the Customer Demand records per Customer-Product-Mode created over each period. The weighting of this value takes into consideration demand quantity and occurrences.

Unit Weight Override

Technology: S

Table: CustomerDemand

Internal Name: UnitWeightOverride

Type: Short Text (50)

Enter a value, the optionally select a weight unit of measure. If you do not select a unit of measure, the default Weight Unit Of Measure from Model Settings is used.

You can define a customer-specific weight for each unit of the product being demanded. This number will then be used to calculate shipment weight at this site demanding this specific product instead of value in the Unit Weight field in the Products table.

When the Unit Weight Override field is left blank, the Unit Weight field in the Products table is used to calculate Shipment Weight. Currently this Unit Weight Override will only apply to the first echelon above the customer.

Unit Volume Override

Technology: S

Table: CustomerDemand

Internal Name: UnitVolumeOverride

Type: Short Text (50)

Enter a value, the optionally select a weight unit of measure. If you do not select a unit of measure, the default Weight Unit Of Measure from Model Settings is used.

You can define a customer-specific volume for each unit of the product being demanded. This number will then be used to calculate shipment volume at this site demanding this specific product instead of value in the Unit Volume field in the Products table.

When the Unit Volume Override field is left blank, the Unit Volume field in the Products table is used to calculate Shipment volume. Currently this Unit Volume Override will only apply to the first echelon above the customer.

Priority

Technology: NO S

Table: CustomerDemand

Internal Name: Priority

Type: Short Text (50)

Enter a number indicating priority.

Network Optimization: This column is not currently used.

Simulation: This property is accessible when using scripting in simulation. Aside from use in simulation scripting, it does not have any direct functionality.

Periods Allowed Early

Technology: NO

Table: CustomerDemand

Internal Name: PeriodsAllowedEarly

Type: Integer

Enter the number of periods for which the demand can be fulfilled early. The actual number of periods will be adjusted if the Periods Allowed Early exceeds the number of periods available prior to the period in which the product is demanded. For example, assume the following:

Early Delivery Penalty Cost

Technology: NO

Table: CustomerDemand

Internal Name: EarlyDeliveryPenaltyCost

Type: Short Text (100)

You can define a cost incurred per unit when demand is delivered early. This cost is applied based on the value of Early Delivery Penalty Cost Basis. Optionally, select a currency to apply to the value. If no currency is selected, the default Currency from Model Settings is used.

When calculating the unit penalty cost, the Early Delivery Penalty Cost is first converted based on the Early Delivery Penalty Cost Basis. For example, assume the following:

Early Delivery Penalty Cost = 5

Early Delivery Penalty Cost Basis = "KG-DAY"

Product Unit Weight = 1 LB

Base Weight UOM = LB

Base Time UOM = DAY

Quarterly Periods

Early Delivery Penalty Cost Basis

Technology: NO

Table: CustomerDemand

Internal Name: EarlyDeliveryPenaltyCostBasis

Type: Short Text (25)

Select the basis by which the Early Delivery Penalty Cost is incurred. Values are for Quantity-Time, Weight-Time or Volume-Time, such as EA-DAY or KG-MO.

Early Delivery Penalty Cost Inflation Factor

Technology: NO

Table: CustomerDemand

Internal Name: EarlyDeliveryPenaltyCostInflationFactor

Type: Number (Float)

Enter the factor by which the Early Delivery Penalty Cost is adjusted for inflation. For example, assume:

Demand: 100 units

Early Delivery Penalty Cost: $1 / EA / Period

Early Delivery Penalty Cost Inflation Factor: 1.5

For the demand originally demanded in Period_004, the penalty cost accounting for inflation would be:

Demand delivered 1 period early= 100 * 1 = $100

Demand delivered 2 periods early = 100 * (1 * 1.5) = $150

Demand delivered 3 periods early = 100 * (1 * (1.5²))= $225

Keep the following in mind when defining the inflation factor:

• If the inflation factor is below 1, the model favors greater deviation from the requested period. The rationale is that if we are fulfilling the request ahead of or after the expected time, it is acceptable to push it to the earliest/latest possible time.

• If the inflation factor is above 1, the model aims to fulfill the request as close as possible to the requested period.

• If the inflation factor equals 1, the penalty rate remains unchanged if we are one or more periods early/late. Instead, the model uses a fixed penalty cost multiplied by the number of periods early/late.

Cancel If Late

Technology: NO S

Table: CustomerDemand

Internal Name: CancelIfLate

Type: Short Text (5)

One of Yes, No.

Simulation: If set to Yes, the customer order will be canceled if it is late at the moment of order processing; this is determined at the site that ships to the customer. If the time of order processing is greater than the Series Offset Time plus the Service Level, any balance on the order will be dropped. If at the time of order processing, there is still time remaining until the Series Offset Time plus the Service Level, the order will be processed including manufacture and shipment even if those events might cause the order to arrive after the Series Offset Time plus the Service Level. This process is analogous to an order clerk comparing the Series Offset Time plus the Service Level to the current time and deleting the order if it is already past the Series Offset Time plus the Service Level; otherwise it’s passed to manufacturing and/or shipping.

Orders that have a portion canceled are noted in the Order Report Simulation Output table. At the time of cancellation, the user order number field is appended with the term ‘Canceled’ and the amount canceled is noted in the Backorder Quantity field. The quantity and value of items canceled are also recorded in the Customer Product Summary Simulation Output table in the Lost Demand and Lost Revenue fields. These values are summed in the Customer Summary Simulation Output table. In addition, the quantity and value canceled are recorded in the Site Product Summary Simulation Output table in the Lost Downstream Demand and Lost Downstream Demand Revenue fields. This information is only recorded for the customer-facing site that is the originally chosen fulfillment location for the order. Finally, the network total quantity and value canceled are summed in the Network Summary Simulation Output table in the Lost Demand and Lost Revenue fields.

Default: No

Periods Allowed Late

Technology: NO

Table: CustomerDemand

Internal Name: PeriodsAllowedLate

Type: Integer

Enter the number of periods for which the demand can be fulfilled late. The actual number of periods will be adjusted if the Periods Allowed Late exceeds the number of periods available after the period in which the product is demanded. For example, assume the following:

Late Delivery Penalty Cost

Technology: NO

Table: CustomerDemand

Internal Name: LateDeliveryPenaltyCost

Type: Short Text (100)

You can define a cost incurred when demand is delivered late. This cost is applied based on the value of Late Delivery Penalty Cost Basis. Optionally, select a currency to apply to the value. If no currency is selected, the default Currency from Model Settings is used.

When calculating the unit penalty cost, the Late Delivery Penalty Cost is first converted based on the Late Delivery Penalty Cost Basis. For example, assume the following:

Late Delivery Penalty Cost = 5

Late Delivery Penalty Cost Basis = "KG-MO"

Product Unit Weight = 2 LB

Base Weight UOM = LB

Base Time UOM = DAY

Quarterly Periods

Late Delivery Penalty Cost Basis

Technology: NO

Table: CustomerDemand

Internal Name: LateDeliveryPenaltyCostBasis

Type: Short Text (25)

Select the basis by which the Late Delivery Penalty Cost is incurred. Values are for Quantity-Time, Weight-Time or Volume-Time, such as EA-DAY or KG-MO.

Late Delivery Penalty Cost Inflation Factor

Technology: NO

Table: CustomerDemand

Internal Name: LateDeliveryPenaltyCostInflationFactor

Type: Number (Float)

Enter the factor by which the Late Delivery Penalty Cost is adjusted for inflation. For example, assume:

Demand: 100 units

Late Delivery Penalty Cost: $1 / EA / Period

Late Delivery Penalty Cost Inflation Factor: 1.5

For the demand originally demanded in Period_001, the penalty cost accounting for inflation would be:

Demand delivered 1 period late = 100 * 1 = $100

Demand delivered 2 periods late = 100 * (1 * 1.5) = $150

Demand delivered 3 periods late = 100 * (1 * (1.5²))= $225

Keep the following in mind when defining the inflation factor:

• If the inflation factor is below 1, the model favors greater deviation from the requested period. The rationale is that if we are fulfilling the request ahead of or after the expected time, it is acceptable to push it to the earliest/latest possible time.

• If the inflation factor is above 1, the model aims to fulfill the request as close as possible to the requested period.

• If the inflation factor equals 1, the penalty rate remains unchanged if we are one or more periods early/late. Instead, the model uses a fixed penalty cost multiplied by the number of periods early/late.

Single Source Fulfillment

Technology: NO

Table: CustomerDemand

Internal Name: SingleSourceFulfillment

Type: Boolean

One of Yes, No.

If set to "Yes", the demand must be fulfilled by a single source.

Default: No

Single Period Fulfillment

Technology: NO

Table: CustomerDemand

Internal Name: SinglePeriodFulfillment

Type: Boolean

One of Yes, No.

If set to "Yes", the demand must be fulfilled within a single period.

Default: No

Fulfillment ID

Technology: NO

Table: CustomerDemand

Internal Name: FulfillmentID

Type: Short Text (100)

Enter an identifier specific to fulfillment behavior related to single sourcing and period timing.

Tracking ID

Technology: S

Table: CustomerDemand

Internal Name: TrackingID

Type: Short Text (50)

Simulation: Enter a tracking number. If Tracking Number is populated, the Tracking Number is traced through Simulation as long as the facilities through which the demand is sourced have inventory policies of "Demand Flow" for the product. This property is accessible when using scripting in Simulation as well.

Seed

Technology: S

Table: CustomerDemand

Internal Name: Seed

Type: Number (Long Integer)

Use this field to control the ordering pattern used for demand. For example, if you have customers that should follow the same ordering pattern, you can populate the Seed value with the same value in the demand records for these customers. By default, this field is not populated and the seed value is determined based on the order in which the demand is processed. As a result, it is somewhat random in its results.

Notes

Technology: NO IO S

Table: CustomerDemand

Internal Name: DemandNotes

Type: Memo

Enter optional descriptive information about the demand.

Status

Technology: NO IO S

Table: CustomerDemand

Internal Name: Status

Type: Short Text (80)

One of Include, Exclude.

Use this field to exclude Customer Demand records for inclusion in the optimization or simulation.

Default: Include