Intro and purpose
Couple of years ago SAP has launched product called UDF. UDF stands for Unified Demand Forecast or in other version UDF Forecast and Modelling. Despite of naming the purpose of this tool is to provide next generation calculation for Forecasting in Retail environment.
In this article I would like to focus on adding User DIF that can better describe demand influence. The area of UDF is complex and vast and o get more information about UDF please check online documentation or visit other articles like here.
Short overview of standard
In standard we receive couple of predefined model definitions algorithms for calculation:
Where model definition is always a combination of model type PMGA or PMGS and DIFs assigned to model component.
Configuration of model definition is done via view cluster /DMF/VC/MOD/DEF
Each algorithm needs to have data based on which model and forecast are done. As the whole solution is residing at CAR by nature POS sales data is default data source for calculation. With the expansion of range of CAR functionality like online shops integration (OAA functionality) or inclusion of specific sales channels of wholesales sales into time series of forecasting leads to following available data sources:
Time series are imported into CAR system via DDF (Demand Data Foundation) functionality or in case of Sales Orders and Shipment partially via SLT or ERP DRF (Data Replication Framework).
With model definition system provides algorithm for calculation that contains multiple of predefined DIF (Demand influence factor) that are describing data from statistical point of view. Demand influencing factor (DIF) is an abstract representation of a time-dependent event, condition or attribute (for example promotion, price or season trend). By modeling historical variations of demand as a function of historical DIF values, it is possible to determine correlations between DIFs and historical demand and these correlations can then be used to forecast future demand.
One of the main purposes of UDF is the decomposition of past and future demands by each DIF. Very good example of the importance of decomposition is to check how the the price changes are reflected in the forecast or if a promotion with a specific type should be created and what would be the future demand with decomposition to by each DIF.
User DIF
With the standard set of DIF we are not always able to reflect all influences that drives our demand. In this case we need to create our DIF so called User DIF and add it to the model. During modeling and forecasting system distinguishes predefined DIF’s and User defined DIF’s.
Creating User DIF
Each User DIF has one of the following types:
Second parameter to be set is level on which value of DIF is maintained:
Before I will proceed with User DIF creation, please remember that statistical model used in UDF is complex and effect that user diff will have on it needs to be in depth checked and verified.
Within this example I would like to create DIF that will describe level of competition of particular product in location. If in the area where my store is some other retailers have an better offer on the product, I would expect lower level of sales.
To create your own DIF (User DIF) please execute transaction SM30 with view /DMF/V_DIF.
When the DIF is created it needs to be added to model definition. This activity is done via SM34 by editing cluster view /DMF/VS_MOD_DEF.
For my User DIF default value of competition is 4 from the range of 1 – Low level to 10 – high level of competition but it can be determined by system as well.
Forecast and modeling examples.
The fist run is done as a standard model without any User DIF taken into consideration.
Modeling results:
Forecast results:
Next run will show Modeling and Forecasting where created User DIF has status ‘ON – Active’ and default value of own DIF has been entered manually.
Modeling results:
Forecast results:
In last run I’m removing default value set to User DIF
User DIF:
Modeling results:
Forecast results:
Conclusion is that UDF is a complex tool and any new requirement of User DIF should be deeply analyzed and verified that it will not give wrong results. Based on my observation as well User DIF with high range of values is a bit difficult to set as a DIF with some errors in decomposition, but as I wrote in previous sentence it’s nice but complex tool.
Couple of years ago SAP has launched product called UDF. UDF stands for Unified Demand Forecast or in other version UDF Forecast and Modelling. Despite of naming the purpose of this tool is to provide next generation calculation for Forecasting in Retail environment.
In this article I would like to focus on adding User DIF that can better describe demand influence. The area of UDF is complex and vast and o get more information about UDF please check online documentation or visit other articles like here.
Short overview of standard
In standard we receive couple of predefined model definitions algorithms for calculation:
- CPG – SAP Retail Weekly Demand Model Definition for Yearly Seasonality with ACV Active
- RTL – SAP Retail Demand Model Definition for Yearly Seasonality
- RTLSDP – SAP Retail Demand Model Definition for Yearly Seasonality Patterns
Where model definition is always a combination of model type PMGA or PMGS and DIFs assigned to model component.
Configuration of model definition is done via view cluster /DMF/VC/MOD/DEF
Each algorithm needs to have data based on which model and forecast are done. As the whole solution is residing at CAR by nature POS sales data is default data source for calculation. With the expansion of range of CAR functionality like online shops integration (OAA functionality) or inclusion of specific sales channels of wholesales sales into time series of forecasting leads to following available data sources:
- Consumption – the most generic type of demand
- Syndicated – represents regular sales and the promotional sales aggregated to generic location or customer by product and week
- POS Sales – represents historical point-of-sales (POS) data
- Sales Orders and Shipments – the sales order and shipment data consist of either wholesale or digital sources
Time series are imported into CAR system via DDF (Demand Data Foundation) functionality or in case of Sales Orders and Shipment partially via SLT or ERP DRF (Data Replication Framework).
With model definition system provides algorithm for calculation that contains multiple of predefined DIF (Demand influence factor) that are describing data from statistical point of view. Demand influencing factor (DIF) is an abstract representation of a time-dependent event, condition or attribute (for example promotion, price or season trend). By modeling historical variations of demand as a function of historical DIF values, it is possible to determine correlations between DIFs and historical demand and these correlations can then be used to forecast future demand.
One of the main purposes of UDF is the decomposition of past and future demands by each DIF. Very good example of the importance of decomposition is to check how the the price changes are reflected in the forecast or if a promotion with a specific type should be created and what would be the future demand with decomposition to by each DIF.
User DIF
With the standard set of DIF we are not always able to reflect all influences that drives our demand. In this case we need to create our DIF so called User DIF and add it to the model. During modeling and forecasting system distinguishes predefined DIF’s and User defined DIF’s.
Creating User DIF
Each User DIF has one of the following types:
- Boolean – simple influence on model with state like yes or no.
- Metric – allow input to the model with numeric values
Second parameter to be set is level on which value of DIF is maintained:
- product, location, sales order, distribution channel and order channel.
- location, sales order, distribution channel, and order channel.
- product
- product location
Before I will proceed with User DIF creation, please remember that statistical model used in UDF is complex and effect that user diff will have on it needs to be in depth checked and verified.
Within this example I would like to create DIF that will describe level of competition of particular product in location. If in the area where my store is some other retailers have an better offer on the product, I would expect lower level of sales.
To create your own DIF (User DIF) please execute transaction SM30 with view /DMF/V_DIF.
When the DIF is created it needs to be added to model definition. This activity is done via SM34 by editing cluster view /DMF/VS_MOD_DEF.
- Model Component – it should always be PMGA:M (multiplicative) or PMGA:A (additive) in case that results of UDF has been deeply verified and confirmed when choosing this model.
- Usage mode – the status of DIF:
- On – User DIF is taken into consideration during calculation
- Off – User DIF is not considered
- Exclude observation – for Boolean DIF it responsible for Ignore DIF functionality. For Metric DIF it looks the system takes into consideration User DIF data but doesn’t do decomposition on model by DIF.
- Default Prior Value – describes what is default value of DIF. In my opinion this parameter is strongly connected with DIF Minimum and Maximum values. If you don’t set the value UDF will determine it automatically.
- Default Prior Weight, - recommended to keep a value of 1.
- Minimum and Maximum parameters – describes range of values that are foreseen for the DIF and with the Default Prior Value parameter system can discover negative or positive DIF effect.
- DUS Mapping Field - Delta Unit Sales is used to categorize Demand Influencing Factors (DIFs) effect. In my opinion in case of User DIF it should be DUS_OTHER_DIFS.
For my User DIF default value of competition is 4 from the range of 1 – Low level to 10 – high level of competition but it can be determined by system as well.
Forecast and modeling examples.
The fist run is done as a standard model without any User DIF taken into consideration.
Modeling results:
Forecast results:
Next run will show Modeling and Forecasting where created User DIF has status ‘ON – Active’ and default value of own DIF has been entered manually.
Modeling results:
Forecast results:
In last run I’m removing default value set to User DIF
User DIF:
Modeling results:
Forecast results:
Conclusion is that UDF is a complex tool and any new requirement of User DIF should be deeply analyzed and verified that it will not give wrong results. Based on my observation as well User DIF with high range of values is a bit difficult to set as a DIF with some errors in decomposition, but as I wrote in previous sentence it’s nice but complex tool.
- SAP Managed Tags:
