Across the world, a lot of retail businesses centrally manage their organizational retail processors using SAP S4 HANA ERP systems. For such organizations, it is important to integrate Point of Sales (POS) information of the retail stores with SAP S4 HANA back-end system. In this article, we will look at the system landscape of a typical POS integration with S4 HANA. Moreover, we’ll see how article master data and POS transitional data are integrated between the systems. And then take a deep dive into WESOUT functionality of service-based integration technique.
Overview of the Systems in the Integrated Landscape
SAP S4 HANA
SAP S4 HANA is the latest version of SAPs Enterprise Resource Planning (ERP) software. SAP S4 HANA also reintegrates certain SAP industry-specific verticals, such as Customer Relationship Management (CRM) and Supplier Chain Management (SCM). HANA stands for the SAP proprietary database technology that features an in-memory, column-based relationship database.
SAP S4 HANA can be deployed as a cloud-based solution, on-premise solution, or as a hybrid of both.
Customer Activity Repository (SAP CAR)
SAP CAR provides one platform for all customer-centric transactional data. It is a unified platform to store various types of customer transactional data, such as POS sales, orders placed through call centers, etc.
Since CAR is integrated with the POS systems in real-time and has access to SAP S4 HANA inventory data, the system has real-time visibility of the overall inventory picture.
Integration Broker (SAP PI/PO or CPI)
SAP Process Integration (PI), SAP Process Orchestration (PO), and SAP Cloud Platform Integrator (CPI) are different versions/products from SAP that facilitate the integration of SAP ERP with different legacy/third-party systems.
Middleware allows a secure gateway to SAP S4 HANA for third party applications.
Main functionalities of a middleware are;
- Connecting systems using communication protocols, such as sFTP, AS2, SOAP, HTTP, etc.
- Routing messages between systems. PI/PO can route messages from one sender system to one or more receiver systems based on business process rules or technical routing rules.
- Transforming or mapping message formats between the sender and target systems.
- Providing a run-time environment for exchanging messages between systems and interface monitoring capabilities.
- Executing integration workflows with a series of steps, such as Purchase Order process integration with approval actions.
You can read more about SAP PI/PO and the history of SAP middleware in my previous article.
POS Terminals
These are digital devices that process customer payments, usually in retail locations. POS terminals have the ability to scan credit cards, check balances, and process payments for sales. Additionally, POS terminals can print receipts and accept return orders.
POS Central Database
This is the central database/application that manages all the POS terminals in the ecosystem. It has the capabilities to distribute master data and control data to POS terminals, as well as to centrally collect transactional data from all the POS systems.
An organization may use POS terminals in retail stores across different regions of the world. The payment format in each region depends on TAX, VAT, and other regional rules. Central POS databases bring different transaction formats of POS terminals into a common format so that data can be integrated with other systems, such as SAP S4 HANA in a standard format.
S4 HANA, CAR, and POS Integration Architecture
Here is how a typical POS-and-S4 HANA-integrated landscape will look. On one end we have POS terminals in retail stores that are integrated with POS data center, and on the other end, we have SAP systems of the organization. SAP S4 HANA and SAP CAR can be hosted in the cloud or on-premise or as a hybrid of both on-premise and cloud.
SAP PI/PO or CPI function as the middleware for all inbound and outbound interfaces of SAP systems. Data transferred by SAP S4 HANA as iDocs or SOAP services (XML) are transformed and mapped to POS target data structures within SAP middleware and vice versa.
Data shared between these systems can be mainly divided into two segments: master data and transactional data. Different interfaces that belong to these two types of data should be implemented to integrate the systems.
Master Data Objects Integrated between S4 HANA, CAR and POS Central System
Master data is usually centrally managed by SAP S4 HANA system and is transferred to POS central system that, in turn, distributes it to POS terminals.
Main Master Data Types that are Integrated between S4 HANA and POS Systems:
| Master Data Object | Information shared |
| Article (Product) master | General information about the article such as Article number, description, EAN codes, etc. |
| Merchandizing category | The logical hierarchy of the articles as they are maintained in the ERP system. For example, Levi’s can belong to the hierarchy Apparel>Jeans>Denim. |
| Price master | Price of sellable articles, such as recommended retail price. |
| Bonus buy and promotions | Information about deals, start/end dates of promotions, and promotional prices |
Each data type is usually transferred with a dedicated interface via SAP PI/PO and AIF (Application Integration Framework).
SAP CAR system is kept in sync with master data from SAP S4 HANA system using SAP Landscape Transformation Replication (SLT). SLT is an ETL tool that allows real-time replication of data directly to SAP HANA database tables. Master data is created in S4 HANA ERP system and the same information is replicated to sub-systems, such as SAP CAR via SLT.
Transactional Data Integrated Between S4 HANA, CAR, and POS
Sales transactions collected by POS terminals are first sent to the central POS database. The transactional data is cleansed and normalized at the POS data center before being integrated to the SAP CAR system.
SAP CAR records detail-level transitional information, however, the S4 HANA system is only fed with an aggregated view of the transactions. This procedure ensures the S4 HANA ERP system is not overwhelmed with granular-level data, but has the data necessary for management reporting.
Following are the main types of transactional data communicated from POS systems to SAP CAR. Each of these objects is integrated with a dedicated interface similar to master data objects.
| Transactional data type | Information |
| Sales and return transactions | Transactions that happen at the POS terminals, like regular sales, returns and exchanges |
| Financial transactions | Transactions, such as opening balances, deposit, cash drop, and cash count, that take place at terminals will be transferred via this interface. |
Integration Mythology and Technology in S4 HANA and CAR Systems
There are two main methods in SAP that enable POS-related integration:
- iDoc-based integration
- Service-based integration
iDoc-Based POS Integration
iDoc-based communication is part of the SAPs Application Link Enable (ALE) technology. iDoc is a proprietary data format developed by SAP that corresponds with EDI message formats.
A mechanism called “change pointers” can be used to distribute master data from S4 HANA system to third-party systems. You can read the following articles to learn in detail about change pointer technology.
At a high-level, the change point mechanism tracks changes of master data objects, such as articles, prices, etc. These change pointers can be processed to create outbound iDocs to POS systems.
iDocs are transferred to PI/PO system using RFC or HTTP protocol. PI/PO route the messages to POS system in the protocol/format expected by the system.
Following are the iDoc types used mainly in SAP Retail:
- Articles (IDoc category: WP_PLU02)
- Merchandise categories (IDoc category: WPDWGR01)
- EAN/UPC references (IDoc category: WP_EAN01)
- Set assignments (IDoc category: WPDSET01)
- Taxes (IDoc category: WPDTAX01)
- Bonus buys (IDoc category: WPDBBY01)
- Promotion discount (IDoc type: WPDREB01)
- Exchange rates (IDoc category: WPDCUR01)
You can read how to create custom iDocs in my previous article.
Service-Based Integration via WESOUT
With Retail and S4 HANA verticals, SAP has provided a standard set of services that exchange messages in XML format instead of iDocs. A service corresponds to a certain master data object, like articles, prices, etc.
These services can be configured (enabled) under transaction WESIMG. Once the services are configured, transaction WESOUT can generate XML messages from S4 system.
A method called Data Type Enhancement allows organizations to customize the standard format of these XMLs according to their needs.
Overview of WESOUT Functionality
Here are the key features of Service Bases WESOUT:
Outbound XML Messages Generation
WESOUT can generate outbound XML messages for configured services.
Messages can be generated in three processing modes. Initialization is where an external system can be fed with all the data from ERP for a given service (master data object). It is usually used during go-live or cut-over phases. In Changes mode, subsequent changes of master data records (after the initialization stage) are sent to an external system using SAP change pointer mechanism. In Manual Request mode, data feeds happen on request.
Explicit Filter Criteria
Data can be filtered, when generating outbound messages, based on different elements: article basic data, organization-level data, article listing information, etc.
For example, you can generate article outbound messages only for sellable articles. Or, generate article master XMLs if articles are listed to the store.
Reference Store Assignment
Outbound messages valid for multiple stores are processed only once, based on the reference store assigned to the store.
Application log and Message Monitoring
End-to-end processing of WESOUT messages can be monitored.
Key Services of WESOUT
Here are some of the main services with WESOUT functionality provided by SAP with their corresponding purposes:
- ProductCategoryHierarchyERPReplicationRequest – Send relevant merchandise category data from SAP system to external systems.
- MerchandiseERPReplicationBulkRequest – Exchange article and price master data information with POS systems.
- PhysicalInventoryCountERPRequest – Request and accept inventory count of a store.
- RetailEventERPStoreReplicationRequest – Integrate promotional and sales events of a store.
To summarize, we discussed the system landscape of a POS integrated S4 HANA system. In a typical integrated landscape, there are systems, such as S4 HANA, CAR, POS terminals, POS data center, etc., integrated through SAP middleware SAP PI/PO/CPI.
S4 HANA system distributes master data centrally to other systems. iDoc or service-based WESOUT functionality can be used for integrating master data with POS systems. Moreover, we discussed the functionality and features of WESIMG and WESOUT at a high level.
Translation data from POS systems are interfaced to S4 HANA through SAP CAR.
If you have any questions on POS integration with SAP, leave a comment below!
Great Blog.
I am an Abaper, here in my firm we are doing this through IDoc.
Now due to POS system updation, we are trying to implement this through WESIMG,
can you kindly help us with the configuration guide for WESIMG.
hi thank you for sharing, i have some question about SAP CAR PO et POS ( customer checkout ) integration et deployment. is it possible to install all this product in the same database
Hi, we are implementing the integration of SAP S/4 HANA and POS via SAP CAR. I am a functional consultant so I would require your help.
Hi,
Great blog, very insightfull. Can you help me with this question: you mentioned a reference store so outbound messages are processed/created only once. How do you set this up? Now a new article is sent xx times to the POS backend creating errors (duplicate material) I want to sent an article once to the POS backend for creation (in initialisation for instance)
Hope you can help!
Marc