- SAP Managed Tags
SAP Unified Demand Forecast (UDF) is a topic that has been close to my heart throughout my journey as an SAP consultant. A significant portion of my career has revolved around this product, and I’ve always found it fascinating how this core engine operates at the center of the SAP Customer Activity Repository (CAR). I want to share some thoughts and perspectives on UDF—from its ease of activation to the complexity of fine-tuning it for optimal performance.
The Role of UDF in SAP CAR
If you search for “SAP UDF” online, you’ll likely come across visual representations similar to the one shown here. These diagrams consistently place UDF at the very heart of CAR, symbolized by a cog or gear—a fitting metaphor for its role as the core engine that drives the entire solution.
But what does this mean in practical terms? From a consultant’s perspective, UDF is relatively straightforward to activate. However, the real challenge lies in its fine-tuning. UDF’s functionality is much more than a checkbox in a configuration menu; it’s the beating heart of SAP CAR
The Value of Demand Forecasts
A forecast, by itself, does not generate any business value. The real value emerges only when the forecast is fed into the right planning applications. Despite its significance, many SAP projects do not prioritize UDF. Its value is often perceived as indirect compared to more tangible business outcomes. I’ve seen stakeholders make reluctant decisions to include UDF in project plans, only to replace it with other urgent priorities when time and budget are limited. While this may seem like a reasonable trade-off, it ultimately reduces software adoption rates and diminishes the long-term benefits.
In this blog, I won’t emphasize how critical or valuable accurate demand forecasts are—those points are well understood. Instead, I’ll focus on the practical steps to achieve accurate forecasting and maximize the potential of UDF.
How to Get There
To achieve an accurate forecast, the first step is to build a demand time series that best represents your business. UDF processes demand signals at the article/location/date/offer level. In other words, it considers every store, all active products, the quantities sold, at what price, and whether or not they were sold under an offer.
You might wonder: how much impact can inaccuracies have, and how do they affect the forecast? Since UDF outputs forecasts at the same granularity as the input data (article/location/date/offer), any misallocated data can skew results. For example, a sale recorded without an offer might be mistakenly categorized as a regular sale due to incorrect aggregation. Similarly, sales data from one date might be attributed to another if a POS system’s polling delays confuse transaction times.
Typically, sales data originates from either POSDTA or a BI system and lands in the /DMF/BI_SALES staging area. Often, those managing these data sources lack knowledge of UDF’s workings, making the transformation from source data to BI_SALES a critical factor in a successful demand planning project.
From a POSDTA perspective, SAP provides a standard aggregation and outbound task tailored for UDF sales staging. Task 2050, “Material + Offer (DMF-Based Applications),” is the standard reference. Unlike sales posting IDocs, Task 2050 includes an additional “offer” attribute. This distinction is crucial because offers are key sales drivers, or Demand Influencing Factors (DIFs).
Key Considerations for Aggregating Sales with Offers
What Is My Offer Identifier?
The offer identifier could be an Offer ID, Promo ID, or Discount ID. These standard TLOG fields can serve as aggregation keys, depending on whether you use SAP’s promotion tools or non-SAP ones. For SAP tools, options include S/4HANA or ECC promotion modules or the PMR module in CAR. Unfortunately, official documentation rarely details how to map these TLOG fields to UDF, making this step one of the most critical yet overlooked in UDF projects. Incorrect mappings can lead to significant rework, especially when dealing with large data volumes.
At What Level Is My Offer Labeled?
In CAR POSDTA, offers can be tagged at either the transaction or item level. Inadequate consideration of this mapping during interface design often leads to errors. For instance, tagging item-level promotions at the transaction level (or neglecting to tag them entirely) is a common mistake. Another example is the “bonus buy” scenario: deciding whether to tag the qualifying items (buy part), the “get” items, or both requires careful thought. These decisions should be based on historical patterns, as they significantly impact forecast accuracy.
Are There Overlapping Scenarios?
Promotions can sometimes overlap within the same transaction, creating complex scenarios. For instance, a generic promotion offering $1 off on a category might combine with a “multi-buy” deal offering an additional $0.50 off when buying more than two items. In such cases, you might allocate sales quantities proportionally based on the price reduction value. For example, if a customer buys four items, receiving $1.50 off ($1 from the generic promotion and $0.50 from the multi-buy), you could attribute 2/3 of the sales to the generic promotion and 1/3 to the multi-buy. However, this approach is not standard SAP.
Out of the box, UDF can only forecast one offer per product/location/day. Enhancements are necessary to accommodate multiple offer lines in the time series table /DMF/TS_PS. Without such customizations, your ability to handle overlapping promotions remains limited.
Tuning UDF for Forecast Accuracy
In general, there are three key directions for improving UDF forecast accuracy:
Cleaning Data: This includes both master data and transaction data.
Tuning Parameters: Adjusting UDF modeling and forecasting parameters.
Introducing Demand Influencing Factors (DIFs): Adding factors that impact demand.
Cleaning Data
The most common issue in this area is listing accuracy. In many retail projects, the listing function is either poorly configured or not used at all. Often, retailers operate smoothly without listing controls, especially when the number of article/store combinations is manageable. However, UDF models and forecasts at the most granular level. If, for example, a product was never intended to be sold at a certain store but a bad listing suggests otherwise, UDF will still forecast demand for that product at the store, resulting in over-forecasting.
Price is another frequent culprit of inaccurate forecasts. UDF interprets price in two ways: during modeling, it calculates price fluctuations based on actual revenue divided by sales quantity, ignoring price master data. During forecasting, UDF predicts selling prices using base price master data and offer master data. For example, if the base price in S/4HANA is $3 and CAR PMR applies a 20% discount, the predicted selling price is $2.40.
However, what happens when not all customers use the promotion? Walk-in customers who don’t present a membership card may pay the original price. In such cases, the predicted price should be a blended value reflecting both scenarios. This can be addressed by introducing a redemption rate—a percentage that indicates how often the offer is redeemed. The blended predicted price can be calculated as:
Blended Predicted Price = Base Price - Offer Reduction * Redemption Rate (REACH)
For stacked offers (e.g., a 20% discount combined with a $2 digital coupon), the formula becomes:
Blended Predicted Price = Base Price - Offer1 Reduction * REACH1 - Offer2 Reduction * REACH2
Identifying and correcting pricing issues through these calculations can significantly improve forecast accuracy.
Tuning Parameters
UDF offers numerous parameters for both modeling and forecasting. Proper tuning of these parameters is critical. Official documentation provides detailed guidance:
For modeling: SAP UDF Modeling Parameters
For forecasting: SAP UDF Forecasting Parameters
By following these strategies, you can systematically improve UDF forecast accuracy and unlock its full potential.
Introducing Demand Influencing Factors (DIFs)
Another commonly used method to improve forecast accuracy is by introducing external influencing factors that UDF cannot observe out of the box. These factors can include weather conditions, calendar events, or any other special variables that significantly influence demand. The application of DIFs is highly dependent on individual business requirements.
Example: Weather as a DIF
A retailer located in the northeastern United States observed a strong correlation between consumer demand and weather forecasts. Severe weather conditions, such as snowstorms, can block roads and disrupt regular weekend shopping patterns. In such cases, predicted snow inches from public sources can be used to create a time series like this:
Product Category / Store Area / Date / Snow Inches
This is referred to as a metric DIF.
During a UDF modeling run, the system can analyze historical data and identify patterns. For instance, demand might spike dramatically a couple of days before a forecasted snowstorm (e.g., January 20) and drop significantly on the storm day itself (e.g., January 21).
After the modeling run, UDF captures this behavior, showing a demand boost prior to the storm (highlighted in orange) and demand suppression on the storm day (highlighted in red).
Using this insight, the system can leverage weather forecast data to predict similar demand patterns before future snowstorms. This enables retailers to drive extraordinary replenishment efforts to better prepare for demand spikes, ensuring products are available when consumers need them most.
Example: Lifecycle as a DIF
Another customer, who sells electronics and video games, observed that demand for some products is heavily dependent on their lifecycle. With every new generation of the product launched, demand follows a consistent pattern: it spikes dramatically at launch and gradually declines until the next generation is introduced. For example, in November 2021, the first generation was launched and sold quickly until November 2022, when the next generation replaced it.
In this case, a lifecycle DIF was introduced to mimic the high-to-low diminishing trend typical of such products. By analyzing demand patterns for similar products, a weighted average of demand was calculated, resulting in a time series (illustrated by a green dotted line).
This metric DIF allows UDF modeling to capture and decompose the lifecycle effect. Once this trend is understood, the system applies it to forecast demand for new products at launch, significantly improving forecast accuracy for this type of product.
Forecast Accuracy and Alerting Mechanism
What is an accurate demand forecast? You simply can’t define it in one KPI, especially in the retail world, where you are managing thousands, if not millions, of combinations of different product types.
There are a few ways to measure forecast accuracy using different KPIs. The most commonly used KPI is wMAPE (weighted Mean Absolute Percentage Error). However, other approaches, such as MAPE or WAPE, might fit slightly different scenarios. This tutorial link clearly explains the differences between these KPIs.
After choosing the right KPI to measure forecast quality, we typically build tools to visualize these numbers at different granularities. For example, wMAPE can be shown at the merchandise category level or any hierarchy of interest. Ideally, the tool should have drill-down capabilities so demand planners can easily identify patterns and trace the root causes of poor forecasts.
An even better approach is to implement an alert mechanism that automatically proposes items or categories for investigation. With so many product/location combinations, it’s impractical for demand planners to identify issues manually. A system-driven approach to prioritize and propose working items is far more effective.
Not all the discussed features are readily available in UDF, but some are at least planned in the successor cloud version. Hopefully, I will write something about the cloud version of UDF in the coming years. 😊
| User | Count |
|---|---|
| 5 | |
| 4 | |
| 2 | |
| 2 | |
| 1 | |
| 1 | |
| 1 | |
| 1 | |
| 1 | |
| 1 |
