Adding Demand (Simulation)

Simulations are generally (mostly) driven by demand specified as customer orders. These orders can be entered in the Customer Orders and/or the Customer Order Profiles input tables. The Customer Orders table typically contains historical transactional demand records to simulate a historical baseline. The Customer Order Profiles table on the other hand contains descriptions of customer order behaviors from which the simulation engine (Throg) generates orders that follow these profiles.

‍

In this documentation we cover both these input table, the Customer Orders table and the Customer Order Profiles table.

Customer Orders Table

To achieve the level of granularity needed and the time-based events to mimic reality as best as possible, every customer order to be simulated is explicitly defined in the customer orders table; this includes line items, order and due dates, and order quantities:

1. We are on the Customer Orders input table
2. Order ID and Line Item ID – these are user-defined IDs which will be repeated in the output tables so individual orders can be traced through the simulation. Records with the same Order ID together make up an order. Line Item IDs within an order should be unique. If transactional systems contain naming conventions for orders and line items, they can be used here. Otherwise user can for example use the same method as in the screenshot to start numbering orders from 1 and increment for each next order, and have line items within the orders also start at 1, incrementing by 1 for each next line item.
3. Customer Name and Product Name – specifies for which customer – product combination the line item is being specified.
4. Quantity and its UOM field – how much does this customer order of this product. This can be a numeric value or a distribution to be sampled, which will add variability to the simulation. This help article covers distributions in simulation. The UOM can be in terms of quantity, volume or weight.
5. Order Date – when does the order occur. When just a date is entered, the order occurs at midnight on that day. User can also enter a date and time into this field.
6. Due Date – when is the order due at the customer: it needs to be received before or at this date & time to be counted towards the on-time service metric. If a due date cannot be met, it depends on settings like allowing backorders and partial fill what happens with the order, which are settings that can be set per order (see additional fields listed below) or at the customer level.
7. CZ_MA places an Order with ID 1, which consists of 3 line items, 1 for each of 3 products. CZ_MA requires 20 units of Product_1, 600 units of Product_2 and 160 units of Product_3. The order is placed on January 2^nd, and is due 13 days later, on January 15^th.
8. Similarly, CZ_TX places an order (ID = 3) with 3 line items, 1 for each product. This order is placed on January 5^th and is due 17 days later, on January 22^nd.

Users can utilize the following additional fields available on the Customer Orders table if required. The single sourcing, allow partial fill, and allow backorder settings behave the same as those that can be set on the Customers table (see this help article), except these here apply to individual orders/individual line items rather than to all orders at the customer over the whole simulation horizon. Note that if these are set here on the Customer Orders table, these values take precedence over any values set for the particular customer in the Customers table:

• Unit Price and its UOM field – the price the customer pays for 1 unit of the product, used for revenue calculations. If set here, this overrides any Unit Price entered for the product on the Products table.
• Source Name – if the line item needs to be sourced from a particular source, the name of the source (which needs to be a facility or supplier) can be entered in this field. If multiple sources can be used, a facilities of suppliers group name can be used in this field too.
• Single Source Order – set this field to True if the whole order needs to be fulfilled by just 1 source.
• Single Source Line Item – set this field to True if the line item needs be fulfilled by just 1 source. Single Source Order = True overrides Single Source Line Item = False.
• Allow Partial Fill Orders – set this field to True if it is allowed to fill part of an order. If set to False, the whole order needs to be filled. If partially filling orders is allowed and backorders are allowed too, any remaining quantity that cannot be filled by the due date may be filled late on a future shipment. If there is a time limit on backorders, then any amount not fulfilled by the time this limit is reached will be cancelled.
• Allow Partial Fill Line Items – set this field to True if it is allowed to fill part of a line item. If set to False, the whole line item needs to be filled. Allow Partial Fill Orders = False overrides Allow Partial Fill Line Items = True.
• Allow Backorders – set to False when an order needs to be fulfilled by its due date; the order will be cancelled if it has not been filled by its due date. When set to True, a backorder is created in cases where the order cannot be fulfilled by the due date.
• Backorder Time Limit and its UOM field – if backorders are allowed, then this time limit indicates after which time any unfulfilled backorders will be cancelled. Not setting a time limit (leaving the field blank) means that backorders can be filled indefinitely. Setting the time limit to 0 is effectively settings Allow Backorders = False.

Customer Order Profiles Table

Rather than specifying individual orders and line items, the Customer Order Profiles table generates these individual orders from profiles which can for example disaggregate monthly demand forecasts into assumed or inferred profiles, using variability to randomize characteristics like quantities and time between orders.

1. We are on the Customer Order Profiles table.
2. Order ID – unique identifier for the profile. Orders generated from the profile have the same Order ID appended with a number for the order and line item within the order, i.e. CO_Profile_a_1-1, CO_Profile_a_2-1, etc.
3. Customer Name and Product Name – the customer – product combination for which the order profile is being set up. Group names can be used, and the product name can also be left blank.
4. Quantity and its UOM field – the amount of product that is being ordered. This can contain a single numeric value or a distribution.
5. Number Of Orders and Number Of Lines – when an order is generated (based on Start Date, Time Between Orders, and End Date, see next screenshot), this Number Of Orders field’s value indicates how many orders need to be placed at that time. If the Product Name is left blank, recurring orders can be generated with a varying number of line items in each order. If the Number Of Lines is 2 or greater, the Order Profile Product Selection and Order Profile Product Affinity tables will be used to determine which products are to be ordered.
6. This profile CO_Profile_a sets up orders for Product_4 at customer CZ_CO for 200 units in each order.
7. This profile CO_Profile_b also sets up orders for Product_4 at customer CZ_CO, however, it is excluded so will not be used unless the status is changed to Include through a scenario or in this table directly. Also, the quantity is now not a fixed number, but a Poisson distribution with a lambda of 200.

1. Service Level and its UOM field – this determines the due date for an order: due date = order date + service level.
2. Start Date – date & time from which the profile will start generating orders.
3. Time Between Orders and its UOM field – the interval between subsequent orders. This can be a fixed amount of time or can be randomized by using a distribution.
4. End Date – the last date the profile can generate any orders.
5. The CO_Profile_a profile requires a service level of 10 days, meaning the due date of any generated orders is 10 days from its order date. The interval between orders is set to be 14 days.
6. The CO_Profile_b profile also requires a service level of 10 days. Its time between orders is set to sample from the Normal distribution with a mean of 14 days and standard deviation of 2.

Note that by using start and end dates for profiles, users can control the portion of the simulation horizon in which a profile is used. This enables users to for example capture seasonal demand behaviors by defining a profile for Customer A/Product X in winter, and another profile for the same customer-product combination in summer.

Example Orders Generated by Customer Order Profiles

Two scenarios were run, 1 named “CZ_CO P4 profile a” where customer order profile a to generate orders at CZ_CO for Product_4 is included and 1 named “CZ_CO P4 profile b” where customer order profile b to generate orders at CZ_CO for Product_4 is included. These are the profiles shown in the 2 screenshots above. In the Simulation Order Report output table one can see the individual orders generated by these profiles during the simulation runs of these 2 scenarios:

1. These 6 records are the first 6 orders generated by customer order profile a:
   1. The quantity of each order is 200 units.
   2. The orders are exactly 14 days apart.
2. These 5 records are the first 5 orders generated by customer order profile b:
   1. The quantity of the orders varies as they are generated by sampling the Poisson distribution with lambda = 200.
   2. The interval between the orders varies too, as these too are generated from sampling a distribution, in this case the Normal distribution with a mean of 14 days and a standard deviation of 2. Looking at the Order Dates of the first and second order we see that there are about 15.5 days in between these 2 orders.