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 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 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 |
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.
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