- The Quantitative Supply Chain Manifesto
- The Lokad test of supply chain performance
- An overview of quantitative supply chain
- Generalized probabilistic forecasting
- Decision-driven optimization
- Economic drivers
- Data preparation
- The Supply Chain Scientist
- Timeline of a typical project
- Project deliverables
- Assessing success
- Antipatterns in supply chain

- Inventory forecasting
- Prioritized ordering report
- Old forecasting input file format
- Old forecasting output file format
- Choosing the service levels
- Managing your inventory settings
- The old Excel forecast report
- Using tags to improve accuracy
- Oddities in classic forecasts
- Oddities in quantile forecasts
- Stock-out's bias on quantile forecasts
- Daily, weekly and monthly aggregations

Home » Resources » Here

Probabilistic demand forecasts are a must-have whenever it comes to inventory optimization. Demand forecasts are said to be

Demand = forecast.demand( category: C1, C2, C3, C4 hierarchy: H1, H2, H3, H4 label: PlainText demandStartDate: LaunchDate demandEndDate: EndDate horizon: Leadtime offset: 0 present: (max(Orders.Date) by 1) + 1 demandDate: Orders.Date demandValue: Orders.Quantity // 'SO' for stock-outs censoredDemandDate: SO.StartDate, SO.EndDate inflatedDemandDate: TVAds.StartDate, TVAds.EndDate // 'Promos' for promotions promotionDate: Promos.StartDate, Promos.EndDate promotionDiscount: Pros.Discount promotionCategory: Promos.Type)

Unlike regular functions, call functions have

The function returns a vector

`Demand`

that is of type The full

`forecast.demand`

syntax includes many arguments, however, only four of them are mandatory:`present`

: a scalar date value`demandDate`

: a date vector with an*item*affinity`demandValue`

: a number vector with an*item*affinity`horizon`

: a distribution vector

The

`present`

value is the date intended as the first day to be forecast, following the assumption that data is complete up to the day before. Some businesses may be closed on Sundays for example, and if the most recent date found in the dataset is a Saturday, there is an ambiguity as to whether the forecast should start on Sunday or Monday. In the illustrative syntax above, we use `max(Orders.Date) + 1`

, assuming that orders are observed every day, and that the input data is fresh from the day before.The

`demandDate`

and `demandValue`

are expected to belong to the same table which exhibits an item affinity, that is `[Id, *]`

in Envision terminology. The dates demonstrate when the demand was observed in the past. The values represent the scale of the demand - which is typically counted in The

`horizon`

represents the probabilistic lead time to be used when forecasting the demand. While the lead time is treated as an input when computing an integrated demand forecast, the lead time is typically also a forecast in itself. The forecasting engine offers the possibility to forecast lead times. The lead time forecast is decoupled from the demand forecast itself, because this offers the possibility to perform ad-hoc adjustments on the lead time distributions, before feeding them into the forecasting engine.Beyond these mandatory arguments, the accuracy of the forecasts can be greatly improved by providing more data to the forecasting engine. The following sections explain this in more detail.

Let $y(t)$ be the demand function and $t$ the time. Let the

$$\text{D} : (y,\Lambda,t_0) \to \int_0^{\infty} \mathbf{P}[\Lambda=\lambda] \left( \int_{t_0}^{t_0+\lambda} y(t) dt \right) d\lambda$$ where $\mathbf{P}[\Lambda=\lambda]$ represents the probability for the lead time random variable $\Lambda$ to be equal to $\lambda$. The demand is qualified as

If $t_0$ represents the present date, then the demand is known - because observed - until the time $t_0$, but unknown afterwards. The purpose of the forecasting engine is to compute $\hat{D}(y, \Lambda)$, a probabilistic estimate of this future demand expressed as a random variable.

See Forecasting with categories and a hierarchy.

`demandStartDate`

argument. When historical start dates are known, it is advised to provide this information to the forecasting engine as it contributes to improving the forecasting accuracy, for both new and old products.The

`demandStartDate`

argument expects a date to be provided for each item. This date is intended to represent the first day when the demand becomes effective for this item. This date is in the past for items that have already been sold, and it remains in the future for items that are yet to be launched.There are two distinct benefits to providing the

`demandStartDate`

argument. Obviously, the first benefit consists of forecasting new items. In this case, it is usually also important to specify the `offset`

argument. Indeed, if the offset is kept at zero - its default value - then the period covered by the forecast might not overlap the The second benefit of specifying the

`demandStartDate`

is to increase the forecasting accuracy for `demandStartDate`

argument to refine the demand forecasts for `censoredDemandDate`

and `inflatedDemandDate`

arguments. Both arguments expect a date vector of item affinity, that is `(Id, Date)`

in Envision terminology.When a date for a given item is marked as

`censoredDemandDate`

argument, the forecasting engine will assume that the demand is higher or equal to the observed value. The engine makes no assumptions on Similarly, demand can be

`inflatedDemandDate`

argument offers the possibility to pinpoint the dates and the items where the demand should be considered as lower or equal to the observed demand. Again, the real demand remains unknowable, but pinpointing the bias is already very helpful to the forecasting engine. In practice, demand is inflated when there are temporary non-recurrent market boosts: for example, the exceptional victory of a local sports team in a national championship may impact very favorably on the sales of local supermarkets for a few days.The two arguments

`inflatedDemandDate`

and `censoredDemandDate`

can take one or two vectors as input. If two date vectors are provided, then, the pairs If demand censorship or inflation are recurrent - per year, per week, etc. - then, there is no need to mark the demand as such, as the forecasting engine handles such patterns automatically.

`promotionDate`

can be provided alone. The argument `promotionDate`

follows the same usage pattern as `censoredDemandDate`

: when a single date vector is provided, promotional periods are considered to be 1-day long, if two dates are provided, the first vector represents inclusive start dates, while the second represents inclusive end dates.The

`promotionDiscount`

argument is optional, and can be provided in order to help the forecasting engine gain insights about the The

`promotionCategory`

argument is also optional, and can be provided as a classification of promotional events. When provided, this argument is leveraged by the forecasting engine to test the affinities between promotional events, and to detect whether events marked within the same category achieve similar demand uplifts. This argument is very similar in spirit to the `category`

argument, except that it is applied to promotions instead of being applied to items.When promotions data is provided, the periods relating to promotional activity should typically not be flagged through the argument

`inflatedDemandDate`

. Flagging a period through both arguments `promotionDate`

and `inflatedDemandDate`

has a subtle semantic: it indicates that the promotional uplift has been inflated beyond what would be reasonably expected from a promotion, and the promotion itself would be considered as biased.