Since beginning of Covid situation Retail industry is just experiencing a very fast pacing revolution where Customer is as always in the center point of the business process but as well in different physical locations. That means that some of shopping bags are filled in the brick and mortar store and some of them are just a virtual basket.
The challenge in this environment is always to keep prices and promotions in sync through all different shopping areas. With rather simple pricing where prices are managed in a master system, let’s assume S/4 Retail then distributed to different systems either via Idoc (in standard COND_A) or to POS system via assortment list, it seems to be straight forward. As a cherry on the cake recently we implemented a solution where the external system was calling pricing on S/4 to calculate prices, subtotals and it was working really well. I can only assume that reason of it could be that SAP is has improved module PRICING (including option to call module for number of articles PRICING_MULTI_ITEM) or we have had a really good developer who did a complex design and build of the solution.
The scenario where there is a new promotional price or simple discount out of regular price as described looks rather no normal to handle. The real problem is coming when you hear from the Customer “we have as well promotion Buy 2 get 3 half price” and this needs to be available for Customers using POS and any virtual basket (web, application etc). For POS system you can almost automatically think about bonus buys available in Retail system which is a good direction. In transaction RDMBBY01 you simple maintain data as an example for buy 2 get 3 half price.
User interface is not the newest one but it works and I have to admit it’s straight forward. Stored bonus buy is then distributed to POS but unfortunately in case of integration with sap pricing procedure it’s not so easy anymore. For any external receiving system some integration logic needs to be built but in case of integration with f.ex pricing used in Sales orders in Retail there is no easy way to integrate it, besides implementing your own logic using sale condition grouping calculation or free items but sooner or later you will find out that this solution is simply saying very heavy to extend and maintain.
Theory
As the new is always coming and SAP has decided to solve this issue with a central repository for pricing and promotion via tool SAP Omnichannel Promotion Pricing (OPP). In theory OPP is a central tool to store prices and promotions across channels and use to either calculate sales price per request or distribute it to relevant application.
Inputs
With definition of OPP that is a central tool for prices and promotion with function of either calculation of price or distribution to relevant systems to keep this area in sync throughout the landscape. For this purpose, as a input for the system following is needed:
- Regular price – this price is not set in OPP but usually is distributed from your backend system (S/4 or ECC) via DRF or imported to SAP CAR from external system as well via DRF inbound functions on CAR.
- In case of technical aspect, Sales price is integrated from S/4 as a PSPR or PMPL (includes valuation price) DRF object and Purchase price as PSOS. Then on CAR respectively processing of Product Location and Transportation Line objects are launched.
- Offer/Promotion – Offers are created either in Fiori app Manage Promotional Offers or simply imported from backend systems like S/4 (objects n S/4 are Promotions or Bonus Buys) or external systems in both cases via DRF tool.
- In case of technical aspects Offers are stored in table /DMF/OFR_TRM_PRD for items details and later on are converted to Promotions that follow format of Association for Retail Technology Standards (ARTS) stored in table /ROP/PROMOTION. To import offer from external system, use DRF function of /DMF/OPIF_OFFER_INBOUND in SAP CAR. In S/4 integration can be done via DRF with objects POFF and PBBY respectively for Promotion and Bonus buy.
What you can see so far, for the integration with SAP backend system Demand Data Foundation (DDF) would be really appreciated. For a kind of simple workaround, would be calling function module for respective objects processing in CAR as it’s in case of external tool integration, but it’s not going to be so smooth like in case of use DDF.
Calculation location option.
What is very powerful from OPP perspective it’s a place where the calculation is taking place. In the past it was always a hiccup at backend if you have had to integrate promotions with sales order (possible via sales conditions) but bonus buys created in backend system and integrated into sales process was nearly not possible. I assume this was one of the reasons why with the OPP you have two options for deployment of this tool.
Central deployment – with this option webservice is residing at CAR system (more preciously I assume it’s kind of java bean). This service is taking regular price, and all offers residing in CAR system and calculates required figures. Nice thing about it is the smooth integration into pricing on you SAP backend. At S/4 side configuration includes setting up RFC connection to service followed by step of setting up what should be sent out and received from service.
What you can see above, towards PPS (Promotion Pricing Service) you can send regular price as a baseline for calculation (I assume f.ex for transaction level discounts) and as a response receive aggregated figures about discount or individual promotions. To receive individual promotions or to limit the results you can use filters and map it into individual conditions in pricing procedure of backend. To trigger calculation at PPS service, routing 317 – OPP: call PPS needs to be assigned to condition in pricing procedure at backend. To achive higher level of flexibility inside routine number of BADIs are available for enhancements.
Entire configuration at S/4 system is done in SPRO -> Logistics General -> Retail: Omnichannel Promotion Pricing (OPP).
Local deployment – with this option of processing, calculation logic of discounts and final sales price is moved to external system. For this reason SAP CAR distributes two types of Idocs via DRF to target system.
- Regular price – with the DRF outbound implementation ROP_PRICE system generates Idoc type /ROP/BASE_PRICE01 with grouped locations for same price and with all price intervals.
- Promotions – using DRF outbound implementation ROP_PROMO system sends out standard promotion Idoc /ROP/PROMOTION02 to target system.
Not bonus buy any more in backend but offer in OPP
With the introduction of OPP new Fiori application has been launched to create offer in SAP CAR. As already mentioned, offers can be created either in OPP or they can be imported into system via DRF.
Below are presented couple of examples of OPP offer created with new Fiori app “Manage Promotional Offers” which has similar functionality as part of SAP Promotion Management (SAP PMR).
Every Offer will require couple of header information like a offer name, location where is valid, validity period. On top of it you can assign as an extra information about offer set (grouping purpose) and leading category of products (merchandise category or article hierarchy node) but this is only for reporting purpose. Interesting options compering to backend bonus buy processing is option to create promotion not only for a full day but also happy hours form is available and option to decide if offer is valid only in case non other discount applied so far during processing – Regular Price Only checkbox.
- Buy 3 get 1 for free – typical promotion
Beside the data filled at the level of header of the offer core processing information are enclosed in terms section. What is really nice comparing to backend bonus buy is a usage of term style as a predefined set of fields that user needs to fill in to achieve business logic.
In below example of defined term style for a promotion buy X units get 1 PC for free.
Typical offer similar to bonus buys at backend has two sections buy and get, which conditions that customer needs to fulfill on buy side to be granted with rewards at get side. Important part of each offer is a dimension field that describes which level is taken into account for each side. Possible values:
To reach example with buy 3 get 1 for free, if promotion is on group of products (f.ex same product different tastes) then dimension of product group would be useful and quantity on buy side and similar settings on get side.
- Transaction more then 100 Eur 5% off on total
Another very often promo type is to reach some level of transaction then Customer is receiving either something for free or some discount on total. In below case buy side has dimension of transaction and get side percentage discount on total.
- Buy 3 PC from one group and get 5% discount on products from the other product group
This example shows combination of two conditions at buy side like buy at least 3 PC from current collection to get an extra discount on winter collection.
Each offer initially is stored in tables /DMF/OFR* and then when activated it’s converted to promotion object stored in table /ROP/PROMOTION.
With couples of the OPP examples it’s not possible to explain all useful features of new software. Good thing about all new functionalities residing on CAR is fact that plenty of BADIs are available so custom logic can be built as not all parameters are visible to user in Fiori app. Pay attention to dedicated BADI triggered during conversion of offer to promotion and two fields:
- Sequence – sequence number can be used to describe order with which promotions are applied in target system.
- Exclusiveness – could be use in target system to discontinue other promotions from being processed if one with promotion is reached.
