Demand

Random periodic demand
Demand defined with probability distribution
Demand occurrence does not depend on the experiment start date

Customers of your supply chain order products in accordance with their demand. In the Demand table you define the mechanism of how the customer's demand for the product is formed.

By default demand is generated on the first day of the first period. In the following cases demand will be automatically set to Next day after interval:

The imported scenario was created in the older version
The outdated database is updated to the new version. This affects all scenarios of this project.

Column	Description
Customer	Defines the customer. The cell contains a list of customers (defined in the Customers table).
Product	Defines the product for which the demand is specified. The cell contains a list of products (defined in the Products table). If you generate scenario with 2 or more products, this column will be set by default to the newly created Generated products group for every customer.
Demand Type	Type of demand definition: Periodic demand — select this option if the demand is of repetitive nature: a certain volume of products is ordered during a certain period of time. You can define volume and period values in the Parameters column. Periodic demand with first occurrence — same as Periodic demand, but has the First occurrence parameter (defined in the Parameters column), that defines the date, on which the first demand occurs. No demand will be generated before this date. Historic demand — select this option if you have the exact demand data (this could be order records from CRM). Define the data in the Parameters column. The cell contains a drop-down list with the demand types.
Parameters	Defines the demand data. For more flexibility, you can set these parameters to be of stochastic nature. In this case, they will vary in accordance with the certain probability distribution. More details on how it affects demand. Demand occurrence does not depend on the experiment start date Periodic demand parameters: First occurrence — defines when the demand is generated within each Order interval: First day — (default choice for new scenarios) demand is generated on the first day of the first Order interval, which is the very first day of scenario. Next day after interval — (default choice when importing old scenarios or updating database) demand is generated in the number of days defined in the Order interval, i.e., if it is set to 5, then demand will be generated on day 6. Random time within interval — demand occurs at a random time within the Order interval. More details on how random works. Order interval — defines the time period during which the specified Quantity of product units is ordered. Quantity — defines the quantity of the product units that is ordered at every given Order interval. Periodic demand with first occurrence parameters: First occurrence — defines the date on which the first demand is generated. No demand will be generated before this date. Order interval — defines the time period during which the specified Quantity of product units is ordered. Quantity — defines the quantity of the product units that is ordered at every given Order interval. Historic demand parameters: Date — the date the demanded quantity refers to. Quantity — the value displayed in the Parameters cell is Total Q, which represents the summarized quantity of the demanded product. The demand value is based on the individual product demand entries that are taken from the Historic demand sheet of the scenario template. Learn how to define demand parameters. Learn more about constraints and penalties.
Time Period	Defines the period of time (previously defined in the Periods table) for the demand specified in Parameters. The cell contains a list of available periods.
Revenue	[Available in NO and SIM scenario type] Allows you to set selling price for product. It might be as well used for selling the same product for a different price to a certain customer. If specified, the value will override Selling Price defined in the Products table The specified value can be overridden by Price (per unit) defined in the Sale Batch table
Down Penalty	[Available in NO scenario type] Defines the penalty to be paid per product item for violating the specified demand Quantity (defined in the Parameters column). E.g. The demanded Quantity is set to 50, Down Penalty is set to 1000. If the delivered quantity is 40, the Down Penalty must be paid per lacking product item. It is calculated as 1000 * ( 50 - 40 ) = 10000. If the penalty is set to 0, the specified Quantity will be considered as a hard constraint, i.e., it cannot be violated. In other cases the Quantity is treated as a soft constraint. For more information refer here.
Up Penalty	[Available in NO scenario type] Defines the penalty to be paid per product item for violating the specified demand Quantity (defined in the Parameters column). E.g. The demanded Quantity is set to 50, Up Penalty is set to 1000. If the delivered quantity is 60. the Up Penalty must be paid per extra product item. It is calculated as 1000 * ( 60 - 50 ) = 10000. If the penalty is set to 0, the specified Quantity will be considered as a hard constraint, i.e., it cannot be violated. In other cases the Quantity is treated as a soft constraint. For more information refer here.
Currency	The type of currency in which the Revenue is expressed. In case of Network Optimization scenario type, this also refers to Down Penalty and Up Penalty.
Expected Lead Time	[Available in Simulation-based experiments] Defines the time period (in time units specified in the Time Unit column) within which the ordered product is expected to be received by the customer. The value is used to calculate the ELT service level statistics.
Time Unit	[Available in Simulation-based experiments] Specify the time unit, in which the Expected Lead Time is expressed. The list of available units comprises the units defined in the Manage units dialog.
Backorder Policy	[Available in Simulation-based experiments] Defines the backorder policy for the selected product and customer. The backorder policy defines how the order is handled in case the required number of products is not yet available for shipping. There are two alternative options: Not Allowed — the order is canceled and no products are shipped. The number of cancelled orders is added to the Demand Received (Dropped orders) (for sites) and Demand Placed (Dropped Orders) by Customer (for customers) statistics respectively. Allowed Total — the order is pending until the required number of products is available for shipping.
Inclusion Type	Defines the status of the given demand. Include — consider this demand in supply chain configuration. Exclude — exclude this demand from supply chain configuration. If selected, the table record will be grayed out to denote the current inclusion type. The table record stays editable.

Random periodic demand

Once the demand has occurred on a random day of the order interval, it is then scheduled to occur according to the defined Order interval parameter (e.g. in 5 days).

Depending on scenario type the Random option will set:

A random day within the Order interval in case of a SIM scenario type. The next time the demand will occur in 5 days (in case of the default value of the Order interval parameter).
A day in the middle of the Order interval in case of GFA, NO, TO type of scenarios.
E.g. If the order interval is 5 days, the demand will occur on day 3. The next time the demand will occur in 5 days.

Demand defined with probability distribution

If you add stochastics to periodic demand, the demand will be processed in the following way:

For the SIM scenario type a certain amount of product (within the range defined in the Quantity parameter) will be ordered on a certain day within the period defined in the Order interval parameter.
For the GFA and NO scenario types it works like this:
1. First, the actual demand is defined within the range specified in the Quantity parameter.
  E.g. The average of 10 items will be taken if we set Quantity parameter to 5-15 items (uniform distribution).
2. Then we check how many Order intervals fit into the period defined in the Periods table.
  E.g. The Order interval is set to 10 days and the Periods table contains 12 periods (one period per month). The first period is January (31 days). In this case we have 31 / 10 = 3.1 order intervals in January.
3. Now we estimate the overall demand per period, which is calculated as items demanded per order interval * number of intervals in the first period or 10 * 3.1 = 31 item
For the TO scenario type the average value is taken for both Quantity and Order interval cases.
E.g. The average of 10 items will be taken if we set Quantity parameter to 5-15 items (uniform distribution). Same refers to Order interval.

Demand occurrence does not depend on the experiment start date

By default the experiment start date coincides with the scenario start date, but you can change the experiment duration by setting any other start/end dates. This will not affect the initial demand occurrence schedule as it is based on the scenario start date.

Below you can see how it works with the default demand settings:

First occurrence is set to First day
Order interval, days is set to 5 days
Quantity is set to 10

Demand occurs on the first day of the scenario (which is the same first day in the period and the ordering interval). Later on, the demand occurs every 5 days, i.e., on the first day of every succeeding order interval (marked blue).

If we decide to start the experiment from any other date, this schedule will not change. The estimation of the demand occurrence will remain the same, since the Order interval is calculated from the scenario start, not the experiment start.

E.g. if we start the experiment from February 1st, the demand will occur on February 5th and not on February 1st.

How can we improve this article?