Customer Orders

Internal Table Name: CustomerOrders

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.

Customer

Technology: NO IO S

Table: CustomerOrders

Internal Name: CustomerName

Type: Short Text (100)

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

Product

Technology: NO IO S

Table: CustomerOrders

Internal Name: ProductName

Type: Short Text (100)

Enter the Product or product group that is being demanded.

Mode

Technology: NO S

Table: CustomerOrders

Internal Name: ModeName

Type: Short Text (100)

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

Quantity

Technology: NO IO S

Table: CustomerOrders

Internal Name: Quantity

Type: Short Text (50)

RNE Eligible

Enter the amount of product demanded by the customer for this order. Enter a value, then optionally 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.

Minimum Quantity

Technology: NO

Table: CustomerOrders

Internal Name: MinQuantity

Type: Short Text (50)

Use this field to define the minimum quantity of the order that must be met. This effectively softens the order 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 Min Quantity is summed over this set of records.

Unit Penalty Cost

Technology: NO

Table: CustomerOrders

Internal Name: DemandPenalty

Type: Short Text (100)

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. Optionally, select a currency to apply to the value. If no currency is selected, the default Currency in Model Settings is used.

Order Date

Technology: NO IO S

Table: CustomerOrders

Internal Name: OrderDate

Type: Date/Time

The Order Date is the date the order is placed.

For Network Optimization, the Order Date (or Order Date Formula) is used to determine the period in which the demand must be satisfied. For example, assume that your model has weekly periods:

Period_001 1/1/2016
Period_002 1/8/2016
Period_003 1/15/2016
Period_004 1/22/2016

If you have demand with an Order Date of 1/10/2016, 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.

If you populate both Order Date and Order Date Formula, Order Date Formula is used when running Optimization or Simulation.
If both the Order Date and Order Date Formula are blank or if demand occurs before the model horizon, Simulation will discard the demand.

Safety Stock Optimization uses Order Date or Order Date Formula (not Due Date or Service Level) to perform Demand Analysis.

If you want to change the Order Date through a scenario, you should use the Order Date Formula field with numeric values, not the date-based Order Date field.

Order Date Formula

Technology: NO IO S

Table: CustomerOrders

Internal Name: OrderDateFormula

Type: Short Text (50)

Specify a number or distribution that defines when the order is placed. Enter a value, then 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. A value of 0 is the first day of the model horizon.

For Network Optimization, the Order Date Formula (or Order Date) is used to determine the period in which the demand must be satisfied. For example, assume that your model has weekly periods:

Period_001 1/1/2016
Period_002 1/8/2016
Period_003 1/15/2016
Period_004 1/22/2016

If you have demand with an Order Date Formula 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.

If you populate both Order Date and Order Date Formula, Order Date Formula is used when running Optimization or Simulation.
If both the Order Date and Order Date Formula are blank or if demand occurs before the model horizon, Simulation will discard the demand.

Safety Stock Optimization uses Order Date or Order Date Formula (not Due Date or Service Level) to perform Demand Analysis.

If you want to change the Order Date through a scenario, you should use the Order Date Formula field with numeric values, not the date-based Order Date field.

Due Date

Technology: NO IO S

Table: CustomerOrders

Internal Name: DueDate

Type: Date/Time

Used to specify the date by which an order must be filled.

In Simulation, the order cycle time is the period of time between the Order Date or Order Date Formula 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 Due Date or Service Level. This is how the software determines if an order is on time or late.

For example:

If you want the Due Date to occur: Enter
As soon as an order is placed 0 or leave blank
1 day after the order is placed 1 Day
Set the actual day it is due Use the Due Date field
If Due Date and Service Level are left blank, the order is due immediately when demand occurs.

In Network Optimization, Coupa recommends that you use the Service Level column, rather than Due Date. Due Date is not actually the date on which the order is due. Instead, it is used to determine the order lead time. For example, if you have an Order Date of 1/10/2016 and a Due Date of 1/12/2016, this indicates an order lead time of 2 days (or 48 hours). See Service Level for additional information.

If you want to change the Due Date through a scenario, you should instead use the Service Level column with numeric values, not the date-based Due Date column.

Service Level

Technology: NO S

Table: CustomerOrders

Internal Name: DueDateFormula

Type: Short Text (50)

Used to specify when an order must be filled. Enter a value, then 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, the order cycle time is the period of time between the occurrence of the order (Order Date or Order Date Formula) 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 Due Date or Service Level. This is how the software determines if an order is on time or late.

If Due Date and Service Level are left blank, the order is due immediately when demand occurs.

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 an Order Date Formula of 8 Day and a Service Level of 2 Day, this indicates an order lead time of 2 days. This constraint basically says that the order 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 order with due date constraints will not be able to use any mode or lane that is longer than the specified Service Level.

Unit Price Override

Technology: NO S

Table: CustomerOrders

Internal Name: UnitPrice

Type: Short Text (50)

You can define a customer-specific price for each order. 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 in Model Settings is used.

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

  • When the Unit Price Override field is left blank for all Customer Orders records, the Price field of the Products table will be used to calculate revenue.
  • If you have multiple entries in the Customer Orders table for the same Period for the same Customer-Product-Mode combination, and one of them uses the Unit Price Override field, then this price is used to override the Price of the Products table for this Customer-Product-Mode combination for the whole order amount in that period. This is because optimization works on aggregates and not individual orders.
  • If you have multiple entries in the Customer Orders table for the same Period for the same Customer-Product-Mode combination, and a number of these use the Unit Price field, the straight average of these Unit Price Override numbers is used for the entire order in that Period for this Customer-Product-Mode combination.
  • The Price is a weighted average of the Customer Order 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: CustomerOrders

Internal Name: UnitWeight

Type: Short Text (50)

Enter a value, then 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.

Simulation: 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 Weight field in the Products table.

When the Unit Weight Override field is left blank, the 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: CustomerOrders

Internal Name: UnitVolume

Type: Short Text (50)

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

Simulation: 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 Volume field in the Products table.

When the Unit Volume Override field is left blank, the 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: CustomerOrders

Internal Name: Priority

Type: Short Text (50)

Network Optimization: This column is not currently used.

Simulation: Enter a number indicating priority. This property is accessible when using scripting in simulation.

Time Allowed Early

Technology: NO

Table: CustomerOrders

Internal Name: TimeAllowedEarly

Type: Integer

Enter the length of time for which the orders can be fulfilled early. For example, enter 45 DAY if the order can be fulfilled 45 days prior to the Order Date. Optionally, select a time unit of measure to apply to the value. If no time is selected, the default Time from Model Settings is used.

The actual number of periods early will be adjusted if the Time Allowed Early results in a number of periods that is more than available prior to the period in which the product is demanded. For example, assume the following in a model with 4 quarterly periods:

Customer Product Order Date Time Allowed Early -> Early fulfillment date Actual periods allowed early Notes
Customer1 Product1 1/1/2023 120 DAY   9/3/2022 0 120 days before the Order Date is before the start of the model horizon. Therefore, the demand cannot be moved to an earlier period.
Customer1 Product1 4/1/2023 120 DAY   12/2/2022 0 120 days before the Order Date is before the start of the model horizon. Therefore, the demand cannot be moved to an earlier period.
Customer1 Product1 7/1/2023 120 DAY  

3/3/2023

(Period_001)

2 120 days before the Order Date puts the demand in Period_001. The original demand period was Period_003. Two periods prior to Period_003 is Period_001. Therefore, 2 periods allowed early is valid (demand in Period_001 or Period_002).
Customer1 Product1 10/1/2023 120 DAY  

6/3/2023

(Period_002)

2 120 days before the Order Date puts the demand in Period_002. The original demand period was Period_004.Two periods prior to Period_004 is Period_002. Therefore, 2 periods allowed early is valid (demand in Period_002 or Period_003).

Early Delivery Penalty Cost

Technology: NO

Table: CustomerOrders

Internal Name: EarlyDeliveryPenaltyCost

Type: Short Text (100)

You can define a cost incurred when an order 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

Period Penalty cost conversion from KG to LB Number of days in period Early Delivery Penalty Cost
Period_001 (5 / 2.20462) = 2.267965 90 (2.267965 * 90) = 204.116809246038
Period_002 (5 / 2.20462) = 2.267965 91 (2.267965 * 91) = 206.384773793216
Period_003 (5 / 2.20462) = 2.267965 92 (2.267965 * 92) = 208.652738340394
Period_004 (5 / 2.20462) = 2.267965 92 (2.267965 * 92) = 208.652738340394

Early Delivery Penalty Cost Basis

Technology: NO

Table: CustomerOrders

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: CustomerOrders

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.52))= $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: CustomerOrders

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 Due Date, any balance on the order will be dropped. If at the time of order processing, there is still time remaining until the Due Date, the order will be processed including manufacture and shipment even if those events might cause the order to arrive after the Due Date. This process is analogous to an order clerk comparing the Due Date to the current time and deleting the order if it is already past the Due Date; 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

Time Allowed Late

Technology: NO

Table: CustomerOrders

Internal Name: TimeAllowedLate

Type: Integer

Enter the length of time for which the orders can be fulfilled late. For example, enter 45 DAY if the order can be fulfilled 45 days after the Order Date. Optionally, select a time unit of measure to apply to the value. If no time is selected, the default Time from Model Settings is used.

The actual number of periods late will be adjusted if the Time Allowed Late results in a number of periods that is more than available after the period in which the product is demanded. For example, assume the following in a model with 4 quarterly periods:

Order Date Customer Product Time Allowed Late -> Late fulfillment date Actual periods allowed late Notes
1/1/2023 Customer1 Product1 120 DAY  

5/1/2023

(Period_002)

1

120 days after the Order Date puts the demand in Period_002. The original demand period was Period_001.One period after Period_001 is Period_002. Therefore, 1 period allowed late is valid (demand in Period_002).

4/1/2023 Customer1 Product1 120 DAY  

7/30/2023

(Period_003)

1 120 days after the Order Date puts the demand in Period_003. The original demand period was Period_002.One period after Period_002 is Period_003. Therefore, 1 period allowed late is valid (demand in Period_003).
7/1/2023 Customer1 Product1 120 DAY  

10/29/2023

(Period_004)

1

120 days after the Order Date puts the demand in Period_004. The original demand period was Period_003.One period after Period_003 is Period_004. Therefore, 1 period allowed late is valid (demand in Period_004).

10/1/2023 Customer1 Product1 120 DAY   1/29/2024 0

120 days after Period_004 exceeds the end of the model horizon. Therefore, the demand cannot be moved to a later period.

Late Delivery Penalty Cost

Technology: NO

Table: CustomerOrders

Internal Name: LateDeliveryPenaltyCost

Type: Short Text (100)

You can define a cost incurred when an order 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.

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.

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

Period Penalty cost conversion from KG to LB Number of days in period Time conversion from MO to DAY based on Units of Measure Late Delivery Penalty Cost
Period_001 ((5 / 2.20462) * 2) = 4.535929 90 (90 / (2592000 / 86400)) = 3 (4.535929 * 3) = 13.60779
Period_002 ((5 / 2.20462) * 2) = 4.535929 91 (91 / (2592000 / 86400)) = 3.033 (4.535929 * 3.033) = 13.75898
Period_003 ((5 / 2.20462) * 2) = 4.535929 92 (92 / (2592000 / 86400)) = 3.067 (4.535929 * 3.067) = 13.91018
Period_004 ((5 / 2.20462) * 2) = 4.535929 92 (92 / (2592000 / 86400)) = 3.067 (4.535929 * 3.067) = 13.91018

Late Delivery Penalty Cost Basis

Technology: NO

Table: CustomerOrders

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: CustomerOrders

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.52))= $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: CustomerOrders

Internal Name: SingleSourceFulfillment

Type: Boolean

One of Yes, No.

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

Default: No

Single Period Fulfillment

Technology: NO

Table: CustomerOrders

Internal Name: SinglePeriodFulfillment

Type: Boolean

One of Yes, No.

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

Default: No

Fulfillment ID

Technology: NO

Table: CustomerOrders

Internal Name: FulfillmentID

Type: Short Text (100)

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

Tracking ID

Technology: NO S

Table: CustomerOrders

Internal Name: TrackingID

Type: Short Text (50)

Simulation: If Tracking ID is populated, this value is traced through simulation as long as the facilities through which the order is sourced have inventory policies of "Demand Flow" for the product. This property is accessible when using scripting in simulation as well.

Status

Technology: NO IO S

Table: CustomerOrders

Internal Name: Status

Type: Short Text (80)

One of Include, Exclude.

Use this field to exclude Customer Order records when running the model.

Default: Include

Notes

Technology: NO IO S

Table: CustomerOrders

Internal Name: Notes

Type: Memo

Use this field to enter optional descriptive information about the order.

Last modified: Friday May 12, 2023

Is this useful?