Module: Computing daily sales forecast¶
Executive summary¶
The module Computing monthly forecasts computes only an absolute quantity sold in a given month. However, the monthly forecast is not good enough for ordering, therefore, the computed quantity for a month must be split into days. Given certain randomness, it is better (and more accurate) to split the quantity computed for a month into days – rather than to try to forecast daily sales directly.
The module Computing daily forecast computes the expected non-promotion sales split proportionally into days of a given month. These are the outputs of the module:
- a relative distribution of sales into different days of a week,
- a relative distribution of sales into three sections in each month (1st to 10th, 11th to 20th and 21st to the last day of the month): the reason is to catch the payday effect in retail.
If a sufficient correlation between sales fails to be established, the algorithm divides the monthly quantity into days evenly, taking into account global selling days (Mon-Fri, Mon-Sat, Mon-Sun).
Functional description¶
Splitting the monthly forecast into days¶
Computation takes historical sales as a base, from which an algorithm learns statistics.
Depending on the configuration, a number of data sources can be used. The computations are then evaluated, and for each product and warehouse, the best solution is selected (taking specific sales into considerations):
- Uniform distribution into sale days (evenly to all sale days)
Another 2 inputs (data sources) use (similarly to monthly forecast) the idea that if the products are of the same category (or sufficiently similar and at various branches), it is preferable to make statistics over multiple data series.
- Distribution of sales by product category.
- Distribution of sales by the position of an item in a top-down (a particular product in different locations)
Extensions¶
Analysis of days split for Christmas and Easter¶
As a default, extreme impacts of holidays, such as Christmas or Easter are ignored. This expansion takes the impact into account. The main point is to improve daily forecast: we have to accommodate a steep increase in sales before the holiday and its subsequent sharp decline. We start by learning from the historical data of the given months, specifically by looking at daily sales and trying to find a regularity – which is then applied to the future forecast. The result is thus a split of daily forecast into days with the holidays being reflected.
The computation consists of two main blocks:¶
- Learning (Easter and Christmas): An analysis of the past sales and preparation of proportional breakdowns.
- Monthly adjustment for March and April (Easter only): forecasting the sales (taking into consideration the moveable dates), again, based on the monthly history.
Learning¶
The same pattern-based algorithm is used for both Easter and Christmas and the starting point is to learn from the historical sales data. Specifically, characteristics of a data series are tested and verified (cf. the effect of day or week of the month) by various patterns. If a pattern assesses that a data series meets its requirements, the pattern is taken into account for the forecasted split into days.
Notice that the algorithm never runs over a single inventory item (typically, not enough data is available and effects of extremes are enormous). Rather, the algorithm runs over a certain level of a product hierarchy; which level is open for selection.
The result of the learning is a percentage split of the forecast into individual days.
Adjustments for March and April¶
Easter is difficult, because the dates vary (and the holiday is not always in the same month). This affects the historical sales of two months in particular (March and April). To balance the forecast, we use a so-called balancer: it adjusts these two months for the forecast; consequently, the output is split into the days based on the data from the first step of the analysis.