In a highly competitive retail environment characterized by shifting consumer behavior, rapid commerce, slim margins, and increasing pricing complexity, retailers must employ advanced pricing strategies to remain competitive.
This post presents a unified framework that manages multiple prices from different sources and applies user-defined, validity-based winning price rules to find the best store price. This price is then used in the standard sales price calculation process to generate the final winning price record. We’ll focus on the unified pricing framework utilizing SAP solutions.
Let’s understand how store prices are determined within the standard SAP process. The price calculation begins with the cost (purchase) price, to which a markup percentage is applied to derive the retail selling price. Based on the organizational structure and master data setup, the SAP Fiori application Create Sales Price Calculation (Transaction code VKP5) is used to carry out the price calculation.
The unified pricing framework uses a standard process to determine the winning price based on the participating prices. The pricing table will be updated to display all participating prices in separate columns, and the winning price will be shown as the final selling price, ready to save.
With an understanding of standard SAP price calculation functionality, we can now explore the unified pricing framework and see how these standard features are leveraged to support the winning price methodology. Below are the main design elements of this unified pricing framework:
As mentioned earlier, the unified pricing logic involves multiple participating prices. Let’s explore various types of participating prices and their condition types, which we will use later in our design. For understanding the unified pricing framework, we are assuming the following participating prices.
For prices planned at the corporate level:
For prices planned at specific stores, participating prices are usually managed centrally for consistency and brand alignment, but store-level adjustments may be needed. Store managers can maintain a store-specific regular base price via standard or custom SAP Fiori apps, ensuring overrides comply with business rules and corporate pricing policies.
The unified pricing framework determines the final winning price by consolidating all participating prices into a single, unified price. Each material has a POS winning base price (condition type ZBSE) and a POS winning selling price (condition type VKP0). Receipts show the regular price plainly, while promotional sales highlight percentage savings to inform customers of the discount.
POS winning prices are automatically set by the unified pricing algorithm, and this also determines the validity period of each record based on the selected participating prices. The example below illustrates this derivation in real time. Let’s assume a material with its regular base price.
On January 1st, 2025, the single participating price ZRET is $5.99 with long-term validity, and the unified pricing logic uses it to generate the corresponding POS winning price records.
Now, let’s assume that on January 8th, 2025, an optimized price, ZOPT, is introduced.
When a new participating price is added, the unified pricing algorithm recalculates VKP0. Effective January 8th, following a “lowest price wins” rule, a new winning price is created with validity based on the ZOPT price.
The POS winning base price remains unchanged, but three VKP0 records are created for the POS winning selling price to maintain continuity: the existing price (January 1, 2025–December 31, 9999), the ZOPT-adjusted price (January 8–25, 2025), and a reversion to $5.99 (January 26–December 31, 9999). This is called condition splitting and ensures uninterrupted store pricing.
To illustrate a more dynamic scenario, consider material A1000001, which is going on a one-week promotion starting January 16th, 2025.
When a weekly promotion starts, the unified pricing algorithm recalculates VKP0. Effective January 16th, a new winning price is generated for the promotion period, following a promotion-priority rule.
The POS winning selling price is adjusted for varying validity periods using condition splitting in the SAP system: the existing ZOPT-based price (January 8–25, 2025) is split for the promotion, creating a VKA0 record (January 16–22, 2025), a post-promotion reversion (January 23–25, 2025), and the regular price reinstated from January 26–December 31, 9999.
This example shows how participating prices interact to determine POS winning prices, which can be recalculated whenever underlying prices change. The unified pricing framework relies on custom configuration tables that define business rules, winning price logic, and customization, providing flexibility and ensuring consistent settings across environments.
The table below outlines all custom tables used to store customization settings.
| Customizing Setting | Table Name | Purpose |
| Winning Price Area | ZPR_PRICE_AREA | Stores various winning price types—corporate and POS base and selling prices—as reference values to support winning price configuration and calculations. |
| Pricing Types & List Variants | ZPR_PRICING_TYPE | Maps winning price areas to pricing types and output condition types to ensure accurate pricing procedures and retrieval of relevant participating conditions. |
| Price Priority | ZPR_PR_PRIORITY | Manages participating condition types for a pricing area, allowing condition prioritization, UPC-based access, and flexible validity-period rules to ensure accurate winning price calculations. |
All participating and winning prices are stored as pricing records in standard SAP condition tables, along with additional metadata used to enhance pricing logic, control, analytics, and reporting. Since this metadata exceeds the standard SAP condition structure, it will be stored in a custom extended condition table rather than extending KONP. This approach ensures flexibility, future scalability, and maintainability, while also protecting the integrity and performance of core SAP tables and processes.
The unified pricing framework stores participating prices across multiple condition tables (e.g., ZRET at A073 or A155) with records split between “A” tables, KONP, and custom extensions. Consolidating these into a unified custom CDS view improves performance and scalability by centralizing access for calculating POS winning selling prices.
With all participating conditions and customizing in place, the unified pricing framework focuses on deriving the winning price through a reusable utility that supports multiple business scenarios, such as transactional inquiries, price calculations, extracts, and analytics. It also enables forward-looking price determination for any specified date based on active participants, with the overall process flow illustrating how user inputs are processed to calculate final POS winning prices.
The unified pricing framework supports the configuration of multiple winning price types, each determined by selected participating condition types defined for a specific pricing area. All winning price types must be defined as unique price areas in the customizing table called price priority, described above.
Each winning price logic is encapsulated within dedicated function modules, enabling it to be reused across multiple processes as needed. By centralizing the calculation logic, any future enhancements or changes can be implemented in a single location, ensuring that all dependent processes and applications automatically benefit from the updates.
You would input these parameters for the winning price function module:
| Field in Each Input Record | Purpose of the Field in Each Output Record |
| Array of Stores/Materials | Table of records containing store number, material number, and UPS |
| Pricing Dat | Pricing date for which the winning price is to be derived. |
The function module reads the customizing table for each winning price scenario to drive further processing logic. Before accessing this table, several key fields are required to support the evaluation. The following section outlines and explains these key fields.
Besides the input parameters, the winning price logic depends on several key fields that are generated internally within the function module. Since the current inputs are enough to determine these fields, there's no need to include them in the interface. This approach keeps the input interface simple while hiding complexity inside the module, enhancing reusability and making it easier to integrate in different scenarios.
The table below outlines the key fields derived for subsequent processing.
|
Key Field |
Purpose of Determining the Key Field |
|
Sales Organization |
To determine participating price records for determining the winning price. |
|
Distribution Channel |
To determine participating price records for determining the winning price. |
|
Division |
To form the sales area to derive other essential key fields (required). |
|
Price List at Store |
To store pricing in a store’s master data. |
|
Merchandise Category |
To assign each material to a merchandise category. |
|
Price List at Merchandise Category Level |
To provide greater flexibility in retail pricing. |
|
Generic Material of Input Variant Material |
To note generic material if the input material is a variant article. |
|
Material’s Sales UoM |
To note the sales unit of the input material. |
|
UPC/EAN |
To note the barcode for the input material. |
Once all input parameters are available and the required key fields have been derived, the next processing step is to collect all participating prices.
Each winning price scenario is maintained as a price area via a customization activity. Participating prices, their priorities, and rules for selecting the lowest or most recent price are defined in customizing activity. These settings are saved in the price priority table, which the logic queries to retrieve the relevant condition types for further processing.
After identifying the participating condition types, the relevant condition records are collected. To efficiently handle the potentially large number of store/material combinations, the previously defined CDS views are utilized, allowing for a single, unified query to retrieve the necessary condition records along with additional pricing attributes from the extended condition tables.
The pricing date provided in the input parameters, along with the other key fields identified earlier, acts as the main criterion for selecting valid pricing records. The specific key fields used will vary depending on the underlying condition type and its defined structure.
Standard SAP pricing records are always created with validity dates. A condition record is considered valid if its valid from date is on or before the pricing date, and its valid to date is on or after the pricing date. This validation ensures that only the relevant prices active on the specified pricing date are included in determining the winning price.
The selection query retrieves all pricing records for the participating condition types, providing the necessary data to derive the winning prices.
Participating prices can be maintained at different organizational levels, with prices defined at more specific levels overriding those at more general levels. The following logic is executed to derive the winning prices from the identified participating prices.
At the first stage, all candidate pricing conditions are assumed to have been derived from their most appropriate organizational level. To enable accurate comparison and selection of the winning price, normalization steps are applied.
First, all prices are converted to a unit price, allowing consistent comparison when determining the lowest price. For example, a price of $5.00 for 2 EA would be normalized to $2.50 per EA. This conversion is used solely for comparison, with the original quantity retained in the winning price record.
Second, all candidate prices are aligned to a consistent unit of measure by applying the necessary conversion factors, ensuring valid comparisons across conditions defined with different units. It will then look at the price priorities of the participating prices in the price priority table and take the participating price with the highest priority as the winning price record.
In scenarios where multiple participating prices share the same priority, the system evaluates the lowest or recent flag associated with each participating price to determine the winning price. If the lowest flag is set, the system compares the condition values of the participating price records and selects the price condition with the lowest value. If the recent flag is set, the system compares the valid from dates of the condition records and selects the price condition with the most recent date.
This approach ensures a clear and consistent method for resolving conflicts among condition types with equal priority, enabling accurate determination of the winning price.
After determining the winning price, the system prepares output records for downstream business processes. The function module provides a structured output parameter, allowing the winning price to be seamlessly integrated into pricing, reporting, and other operational workflows. The output is delivered as a table containing multiple records, with each detailing the winning price and its associated attributes to support subsequent processing.
|
Field in Each Output Record |
Purpose of the Field in Each Output Record |
|
Sales Organization |
This output field corresponds to the sales organization of the store provided as an input to the function module. |
|
Distribution Channel |
This output field corresponds to the distribution channel of the store provided as an input to the function module. |
|
Store |
This is the store that was received as input. |
|
Material Number |
The material number for which the winning price is determined |
|
UPC |
If UPC had been used to get any participating price condition, the same UPC could be passed in the output. |
|
Valid From Date |
The valid from date for the winning price record is derived from the corresponding valid from date of the winning participating price record. If this date is in the past, the winning price will take effect from the current date or the input pricing date, whichever is later. |
|
Valid To Date |
The valid to date price record is derived from the corresponding valid to date price record of the winning participating price record. |
|
Price |
This is the price from the winning participating pricing record. |
|
Price Quantity |
This is the quantity (pricing unit) from the winning participating pricing record. |
|
Pricing UoM |
This is the UoM from the winning participating pricing record. |
|
Extended Price Structure |
This structure stores the additional pricing attributes for the winning participating price record. Below are the fields to be populated in each structure record:
|
The function module output is organized to allow easy use by downstream programs or processes. Specifically, it is designed so that the resulting data can be used to create the winning price condition record without needing additional transformation.
Based on the above design, a dedicated module for determining winning prices can be developed to handle various types of winning prices. Examples of such winning prices that can be implemented using this approach are outlined below.
With the required configuration and the winning price function module in place, you can now leverage these capabilities within the standard sales price calculation process to generate winning prices for the POS system. The following processing steps describe the complete, end-to-end process flow used to calculate, evaluate, and determine the winning prices that are ultimately made available to POS.
SAP offers a variety of reporting tools, including embedded analytics options and SAP Analytics Cloud. In addition to the standard pricing reports, dedicated auditing reports can be developed within this unified pricing framework.
The proposed unified pricing framework demonstrates its practical application through a real-world example. Unlike standard SAP pricing, which relies on a single active condition record, this framework evaluates multiple active prices to identify the most advantageous “winning” price. Designed for flexibility in retail pricing, and particularly in cooperative environments, the framework provides a systematic approach to expanding pricing options and serves as a practical guide for doing so.
The following references provide more detailed information on the topics covered in this paper.