Explaining Store Connection with Point-of-Sale Sales

A POS (Point of sale) system is used to post the sales activities in a store. Typically, based on the scanned article GTIN and the captured quantity, it determines the sales price for the relevant article. In addition, it includes and forwards the payment method, the amount due, and customer returns.

Many POS solutions also enter the POS number, the cashier (as a user key, for example), the date, and the time of the sale. All this data is stored in a special Transaction Log (TLog).

The Transaction Log (TLog) database contains information about most transactions performed at POS registers. It can be used for balance inquiries, employee monitoring, order management, and customer service issues. For example, the TLog can be monitored to determine if an employee is following store procedures, or when a customer disputes the amount charged on a credit card for an item purchased the previous day. In this case, the store manager can search the TLog for all of the previous day’s transactions to determine if the proper amount was charged on that particular credit card number.

The TLog can be accessed at the corporate level and at the store level. If you are viewing the TLog at the store level, you have access to local information at your store. At the corporate level, you can view data for the entire corporate hierarchy, one site at a time. You can also print transaction information from the TLog.

With the SAP Retail POS Interface, you can connect Point-of-Sale (POS) systems with the central system to exchange required master- and transactional data. The integration scenarios include the exchange of data in both directions.

In the area of POS Outbound, the central SAP Retail system provides relevant data for the POS system. This includes master data such as article and price information using individual messages or using the assortment list. Also merchandise category hierarchy data, and promotion data can be transferred, and also specific movement data, such as shipping notifications, can be part of the outbound messages.

On the other hand, the central SAP Retail system can receive data from the POS system through the POS Inbound interface. These are sales and returns, financial transactions, but also merchandise management related data such as goods movements, and store goods receipts as well as inbound deliveries. Also store orders, and physical inventory counts can be received, besides master data, and cashier statistics. Further POS inbound services are available, for example to transfer customer order payment information.

The POS Simulation functionality allows you to enter inbound POS transactions manually in the SAP Retail system. With that, you can check if your system configurations for posting the incoming data in the central system are correct. This is particularly useful for testing purposes, when no actual POS system is connected. The figure above, POS Interface Inbound, shows the available simulation functions for POS inbound, with the example of a POS sales transaction (POS cash register receipt).

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.