The standard method of transferring data from any Point of Sale system to its central on\u0002premise retailing system involves middleware: an (external) converter, or SAP's PI or PO resp. (Process Integration/Process Orchestration), using IDocs(Intermediate Documents) or IDocs/RFC. A converter is responsible for two tasks: 1. Monitoring communication and 2. Converting data. For example, the SAP IDoc format has to be converted to the format that the POS server uses. However, service-based communicationis also available, for example, specifically for the transfer of bonus buy data to POS systems, using the function Generate Outgoing Messages - Integration Scenario (transaction code WESOUT).
Specifically in SAP Cloud solutions, you use the Data Replication Framework Outbound (DRFOUT) to transfer the product master data from the SAP S/4HANA (SAP Retail) system to point-of-sale (POS) systems. In this framework, you can use enterprise services to create one or more outbound messages for target POS systems. With POS inbound SOAP-based services, you can transfer business transaction data from POS systems to SAP S/4HANA (SAP Retail). POS inbound processing can then be monitored using the SAP Application Interface Framework (AIF).
Detailed information about the data transfer options in SAP S/4HANA regarding POS Integration can be found in the Online documentation on help.sap.com.
POS outbound processing supplies the POS servers with current data (article data, GTINs, prices, and so on).
The store's POS server is supplied with data for the first time by means of an initialization message (initial data transfer). After this initial transfer, it is possible to only transfer changes, that is delta information such as new/changed articles or changed prices, instead of creating a full data download every time.
POS outbound processing prepares the data required for each store at regular intervals and sends it to the POS server. Data which is currently valid can be sent to the POS server, as well as prices that will be valid in future, new articles, and so on. You can specify the frequency for transferring changes only (that is, delta information instead of full messages), and the period (in number of days) for which the data should be transferred in the SAP Retail customizing settings.
Article data, price changes, promotion data, as well as merchandise category hierarchy data, complex conditions of a bonus buy, and so on, all represent data that is required at POS. Note: If a company uses a non-SAP store retailing system, additional data is also required: In order to post goods receipts, the purchase orders created at head office for the store must be sent to the store. If a physical inventory is planned at the head office, the physical inventory documents must be sent to the store.
POS inbound processing takes place in SAP Retail. In this case, POS data are transferred from the POS server to SAP Retail.
Sales entered at the POS in the store can be transferred from the POS server to the POS interface of the central SAP Retail component using a converter or SAP PO/PI. The stock accounts at the stores are updated, and billing documents are created. The billing document is used to transfer the data to Financial Accounting. Payment data (credit cards, customer cards, cash sales, and so on) are also transferred to Accounting.
There are various ways in which central headquarter systems communicate with local store systems:
Option A: As explained already, it is possible to set up the communication with the store's POS server directly from the SAP Retail system.
Then, instead of the direct communication between SAP Retail and the store's POS system for uploading the POS sales data to the central system, it is common not to upload the sales data directly to SAP Retail, but to send it to the SAP Customer Activity Repository system with it's SAP POS Data Transfer and Audit (SAP POS DTA) component, and then have the sales data passed on to SAP Retail from there. The sales data may be loaded and stored in SAP Customer Activity Repository on a sales-as-per-receipt level, and can be aggregated and sent to SAP Retail for inventory and financial accounting posting. This process is explained in the next figure, POS System Integration with SAP Customer Activity Repository / POS DTA.
Option B: In addition to a POS Server with it's connected POS (cash register) terminals in the store, it is also possible that the store runs a local, external (non-SAP) store merchandise management system. In this case, the external merchandise management system communicates with the central headquarters systems, and accordingly updates the local POS server.
Option C: SAP's solution providing comprehensive store merchandising functions is SAP In-Store Merchandising. It is an integral component of SAP Retail that has been developed especially for use at stores, and offers access to user-friendly transactions by using the SAP Fiori Store Operations apps. SAP In-Store Merchandising puts the store online with central SAP Retail. In addition, the stores still also have a POS server with connected cash register terminals, at which the sales activities are recorded. The POS server communicates separately with the headquarters systems. In this scenario, the POS server does not need to have any additional retail functions, for example for entering goods receipt. The SAP Fiori Store Operations apps will be covered in detail in the next unit.
SAP POS Data Transfer and Audit (SAP POS DTA) is an integral component of the SAP Customer Activity Repository, and is the central tool to efficiently manage POS data in the Retailer's central system landscape.
The scenario shown in the figure above, POS System Integration with SAP Customer Activity Repository / POS DTA, provides many advantages: SAP POS DTA can be used to load the stores' POS sales data into SAP Customer Activity Repository, and to analyze and stage it for use in other applications. The POS data is checked and corrected centrally (sales audit) before it is passed on to further central components (such as SAP Retail), or made available for analytics. A key advantage of SAP POS DTA is that the POS data can be transferred with different degrees of granularity for different target systems at different times. This means for example sales as per receipt data is sent from the POS system to SAP POS DTA for detailed editing and evaluations, and can then be aggregated for the transfer to Demand Data Foundation (providing the time series used for forecasting), to SAP Retail, SAP FI, SAP Forecasting and Replenishment, or to a customer loyalty management system, and further systems. So the editing and correction tasks (sales audit) only have to be done once, and data consistency across systems is ensured.
SAP Customer Activity Repository (SAP CAR) is a foundation that collects granular sales data previously spread over multiple siloed applications in diverse formats. As the basis for multi-channel transactions, SAP Customer Activity Repository captures information on customer / consumer sales activities across all interaction channels enriched by master and transactional data. The Repository stores data at the most granular level of detail, allowing the embedded science layer to execute advanced statistical algorithms and pattern predictions.
SAP CAR offers real time visibility into the current stock situation in the stores by taking unrestricted use stock in SAP Retail, and unprocessed sales into account.
To date, there are five consuming applications (consuming apps) on SAP Customer Activity Repository, which you can see on top of the below figure, SAP Customer Activity Repository. SAP Promotion Management, and SAP Replenishment Planning will both be introduced in other lessons of this course.
SAP Merchandise Planning integrates and facilitates channel financial, location-to-merchandise, and open-to-buy processes including inventory management, purchase planning, and budgeting. It provides a centralized repository for all planning activities that enable the fast reconciliation of strategic merchandise plans and reduces the manual effort associated with spreadsheet based planning processes.
With SAP Assortment Planning, you can determine assortments and their respective product mix in line with strategic goals, and plan demand quantities for upcoming seasons based on referenced historical data across product categories and selling locations. It aligns assortments with objectives like Budget, Shelf space, Sales and Financial objectives. Further key capabilities are simulation, planning and refinement of assortments.
SAP Allocation Management allows you to manage the distribution of fashion articles to stores, for example for initial merchandise supply, or in-season fill-ins. The tool provides a set of best-of-breed allocation strategies, and you can work with system-proposed allocation plans based on SAP Customer Activity Repository’s analytical functionality.
The Demand Data Foundation (DDF) is the platform and data model defined to support SAP Retail applications. DDF provides flexibility to integration with SAP Suite or any other master data system. SAP HANA is utilized to manage, aggregate, and filter data in a faster way than previously possible.
Unified Demand Forecasting (UDF) combines strengths of the forecast capabilities from SAP Promotion Management for Retail and SAP Forecasting and Replenishment and, at the same time, leverages the speed of SAP HANA.
Omnichannel Promotion Pricing in SAP Customer Activity Repository is a central place to store all sales prices and all promotional rules (including Bonus Buy conditions) that serves as a basis to determine the effective sales price for the end-customer in the respective sales channel.
Omnichannel Article Availability (OAA) within SAP Customer Activity Repository supports Advanced ATP (aATP).
On Shelf Availability (OSA) provides intra-day sales patterns which can be used to break down daily forecasts from UDF into 15-minute batches. This is for example relevant for fresh item production, or for potential out of stock prediction, or to analyze potential lost sales - for example, when items have been out of shelf in the past.