POS Retail PDF

SAP POS Data Management
PDF download from SAP Help Portal:

http://help.sap.com/saphelp_posdm/helpdata/en/c8/642344102740f1ba74a9be390e4ac5/content.htm
Created on August 12, 2015
The documentation may have changed since you downloaded the PDF. You can always find the latest information on SAP Help Portal.
Note
This PDF document contains the selected topic and its subtopics (max. 150) in the selected structure. Subtopics from other structures are not included.
The selected structure has more than 150 subtopics. This download contains only the first 150 subtopics. You can manually download the missing subtopics.
© 2015 SAP SE or an SAP affiliate company. All rights reserved. No part of this publication may be reproduced or transmitted in any form or for any purpose
without the express permission of SAP SE. The information contained herein may be changed without prior notice. Some software products marketed by SAP SE
and its distributors contain proprietary software components of other software vendors. National product specifications may vary. These materials are provided by
SAP SE and its affiliated companies ("SAP Group") for informational purposes only, without representation or warranty of any kind, and SAP Group shall not be
liable for errors or omissions with respect to the materials. The only warranties for SAP Group products and services are those that are set forth in the express
warranty statements accompanying such products and services, if any. Nothing herein should be construed as constituting an additional warranty. SAP and other
SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP SE in Germany and other
countries. Please see www.sap.com/corporate-en/legal/copyright/index.epx#trademark for additional trademark information and notices.
Table of content
PUBLIC Page 1 of 83
© 2014 SAP SE or an SAP affiliate company. All rights reserved.
Table of content
1 SAP POS Data Management
1.1 POS Inbound Processing Engine
1.1.1 Generation of POS Transactions
1.1.1.1 POS Inbound
1.1.1.1.1 Use of the BAPI /POSDW/BAPI_POSTR_CREATE
1.1.1.1.2 Use of IDocs
1.1.1.2 Generation Using the POS Workbench
1.1.1.3 Real-Time Individual Processing (Trickle Feed)
1.1.2 Aggregation of POS Transactions
1.1.2.1 Aggregation in Task Processing
1.1.2.2 Forming of Aggregates
1.1.3 Task Processing
1.1.3.1 Sending Data to SAP CRM
1.1.3.2 Using the PIPE Dispatcher
1.1.3.3 Sending Data to POS Analytics
1.1.3.4 Sending Data to SAP Retail
1.1.3.4.1 Sending Sales Data via IDoc WPUBON
1.1.3.4.2 Sending Sales Data via IDoc WPUUMS
1.1.3.4.3 Sending Means of Payment Data via IDoc WPUTAB
1.1.3.4.4 Sending Financial Transaction Data via IDoc WPUFIB
1.1.3.4.5 Sending Goods Movement Data via IDoc WPUWBW
1.1.3.5 Sending Data to SAP F&R
1.1.3.6 Sending Data to Credit Card Settlement
1.1.3.7 Outbound of sales data to SAP DMF-based applications
1.1.3.8 Task Processing for POS In-Memory Analytics
1.1.3.8.1 Enhancing Transaction Data for POS In-Memory Analytics
1.1.3.8.2 Supplying POS In-Memory Analytics with Distributed Transaction D
1.1.3.8.3 Determining Transaction Data Status
1.1.3.9 Aggregation Tasks
1.1.3.10 Using Outbound Tasks
1.1.3.11 Tasks for Checking Transactions
1.1.3.11.1 Check for Duplicate Transaction Numbers
1.1.3.11.2 Displaying Gaps in Receipt Numbers
1.1.3.11.3 Checking Comparisons for Totals Transactions
1.1.3.12 Rules
1.1.3.12.1 Check for Balanced Transaction
1.1.3.12.2 Comparing Receipt Data and Cash Desk Totals
1.1.3.12.3 Check for Performance of Sales Audit
1.1.3.12.4 Credit Card Data Check
1.1.4 Outbound Processing of Aggregates
1.1.4.1 Performing Outbound Processing
1.1.5 Archiving Transaction Data
1.1.6 Providing POS Transactions for Online Stock Queries and Inventor
1.1.7 Encryption of Payment Cards
1.1.8 Roles
1.1.8.1 Sales Auditor/POS Monitoring
1.1.8.2 POS Inbound Processing Engine (PIPE) Administration
1.1.9 Enterprise Services
1.1.9.1 Point Of Sale Transaction Processing
1.1.9.1.1 Point Of Sale Transaction
1.1.9.1.1.1 Point Of Sale Transaction In
1.1.9.1.1.1.1 Create Point Of Sale Transaction as Bulk
1.1.9.1.1.2 Point Of Sale Transaction Out
1.1.9.1.1.2.1 Request Loyalty Membership Activity Journal as Bulk
1.2 Carrying Out of Sales Audits
1.2.1 Use of the POS Workbench
1.2.1.1 Display of Secure Data
1.2.1.2 Selection and General Settings
1.2.1.3 Checking the Data Transfer
1.2.1.4 Control of Task Processing
PUBLIC Page 2 of 83
1.2.1.5 Analyzing Errors and Messages
1.2.1.6 Display of Processing History and Follow-On Documents
1.2.1.7 Editing POS Transaction Data
1.2.1.8 Searching for POS Transactions
1.2.1.9 Mass Changes to POS Transactions
1.2.1.10 Display of Stores Without Communication
1.2.1.11 Carrying Out Ad Hoc Analyses
1.2.1.12 Monitoring of POS Aggregates
1.2.2 Automatic Checks
1.2.2.1 Master Data Checks
1.2.2.2 Rules
1.2.3 Short/Over Balancing
1.2.3.1 Determining Short/Over Differences
1.2.3.2 Checking the Short/Over Status
1.2.3.3 Verifying/Manually Processing Short/Over Differences
1.2.3.4 Sending Short/Over Differences Using IDoc WPUFIB
1.3 Analytics
1.3.1 POS Analytics
1.3.2 Trade Foundation Analytics
1.3.3 POS In-Memory Analytics Content
1.3.3.1 Roles
1.3.3.2 Analytic Views
1.3.3.2.1 Average Number of Items per Transaction
1.3.3.2.2 Average Sales per Transaction
1.3.3.2.3 Sales
1.3.3.2.4 Markdown Sales
1.3.3.3 Key Figures
1.3.3.3.1 Counter
1.3.3.3.2 Discount Value
1.3.3.3.3 Distributed Discount
1.3.3.3.4 Distributed Included Transaction Tax
1.3.3.3.5 Normal Sales Value
1.3.3.3.6 Tax Included
1.3.3.4 Characteristics
1.3.3.4.1 Business Transaction
1.3.3.4.2 Calendar Day
1.3.3.4.3 Calendar Month
1.3.3.4.4 Calendar Week
1.3.3.4.5 Calendar Year
1.3.3.4.6 Classification of Sales Item: Category
1.3.3.4.7 Classification of Sales Item: Subcategory
1.3.3.4.8 Credit/Debit Indicator at Line Item Level
1.3.3.4.9 Credit/Debit Indicator at Transaction Level
1.3.3.4.10 Customer Number of Plant/Store
1.3.3.4.11 Hour
1.3.3.4.12 Item ID
1.3.3.4.13 Markdown Sales Transactions
1.3.3.4.14 Material Group
1.3.3.4.15 Offer
1.3.3.4.16 Promotion
1.3.3.4.17 Reason
1.3.3.4.18 Record Qualifier
1.3.3.4.19 Retail Type Code
1.3.3.4.20 Retailstrid, Bussdaydate & TransIndx
1.3.3.4.21 Start Date
1.3.3.4.22 Start Time Stamp (Time)
1.3.3.4.23 Task Canceled
1.3.3.4.24 Transaction Type Code
1.3.3.5 MultiProviders
1.3.3.5.1 Sales
1.3.3.5.3 Number of Sales
PUBLIC Page 3 of 83
1.3.3.6 Info Cubes
1.3.3.6.1 Sales
1.3.3.6.3 Number of Transactions
1.3.3.6.4 Averages Sales per Transaction
1.3.3.7 Queries
1.3.3.7.1 Sales Summary
1.3.3.7.2 Gross Sales
1.3.3.7.2.1 Gross Sales Summary
1.3.3.7.2.2 Gross Sales Rolling Time Period Trend
1.3.3.7.2.3 Gross Sales Top Location Performers
1.3.3.7.2.4 Gross Sales Bottom Location Performers
1.3.3.7.2.5 Gross Sales Top Merchandising Category Performers
1.3.3.7.2.6 Gross Sales Bottom Merchandise Category Performers
1.3.3.7.2.7 Departments Gross Sales for a Given Location and Items Gross Sal
1.3.3.7.3 Net Sales
1.3.3.7.3.1 Net Sales Summary
1.3.3.7.3.2 Net Sales Rolling Time Period Trend
1.3.3.7.3.3 Net Sales Top Location Performers
1.3.3.7.3.4 Net Sales Bottom Location Performers
1.3.3.7.3.5 Net Sales Top Merchandising Category Performers
1.3.3.7.3.6 Net Sales Bottom Merchandise Category Performers
1.3.3.7.3.7 Departments Net Sales for a Given Location and Items Net Sales f
1.3.3.7.4 Discounts
1.3.3.7.4.1 Discounts Summary
PUBLIC Page 4 of 83
1 SAP POS Data Management
The SAP POS Data Management (SAP POS DM) application is used to receive, audit, process and analyze transactional data from your stores.
It includes the following integral parts:
POS Inbound Processing Engine (PIPE)
Analytics, including:
POS Analytics
POS Analytics data supplied to Trade Foundation Analytics
Customers implementing SAP POS DM on SAP NetWeaver BW powered by SAP HANA can also take advantage of the POS In-Memory Analytics content
available for SAP POS DM.
Loss Prevention Analytics

Loss Prevention Analytics (LPA), a set of analytical tools helping you to identify critical POS transactions, can only be used if you use SAP POS Data
Management. For more information, see the Loss Prevention Analytics application help.
1.1 POS Inbound Processing Engine
Using the POS Inbound Processing Engine (PIPE), you can receive and process movement data from your stores. The PIPE can process the following data:
Sales and returns including the related tax data and discount information
Means of payment data
Financial transactions
Goods movements
Totals records and cashier statistics
The PIPE updates the transaction data and makes it available for further processing.
You have the following options:
Checking and correction of the data from the transferred POS transactions
Summarization of the data of POS transactions in order to reduce the data volume
Supply of follow-on systems (for example, SAP BI, SAP Retail or SAP F&R) with the data from the POS transactions for further processing.
Integration
The transferred sales data is relevant for providing the following functions in SAP for Retail with POS data:
Supply of POS data to Business Content for POS Analytics and Point of Sale in SAP BI
Supply of the POS Interface Inbound in ERP and SAP R/3 with POS data
Supply of SAP Forecasting and Replenishment in SAP SCM with POS data
Supply of credit card settlement with POS data
The following figure represents the data flow in the PIPE:
PUBLIC Page 5 of 83
Features
Generation of POS transactions:
This includes both the manual creation of POS transactions and the conversion of data that is received in different formats such as IDocs of message types
WPUBON, WPUUMS, WPUTAB, WPUWBW, WPUFIB and WPUKSR or also in BAPI format.
Carrying out of the sales audit with the POS Workbench
Manual check of the data transfer
Error and message analysis
Display of processing history and follow-on documents
Search for POS transactions
Changing POS transactions
Carrying out checks for transaction data
This includes the following:
Carrying out of automatic master data checks
Check for Duplicate Transaction Numbers
Display of gaps in receipt numbers
Check for balanced sales and tender totals of POS transactions
Comparing receipt data and cash desk totals
Checking credit card data
Summarization of transaction data using automatic aggregation when sending POS data to follow-on systems or by formation of aggregates
Supply of follow-on systems with POS transaction data
This includes the following:
Send data to SAP BI
Send sales data via IDoc WPUBON to SAP Retail
Send sales data via IDoc WPUUMS to SAP Retail
Send sales data via IDoc WPUTAB to SAP Retail
Send financial transaction data via IDoc WPUFIB to SAP Retail
Send goods movement data via IDoc WPUWBW to SAP Retail
Send data to SAP F&R
Send data to credit card settlement
1.1.1 Generation of POS Transactions
You wish to create POS transactions in the PIPE in order to check them in the PIPE and to be able to forward the related data to the linked follow-on systems.
There are several ways to generate POS transactions:
POS Inbound via BAPI
POS Inbound via IDoc
Create Using the POS Workbench
Using the Point Of Sale Transaction In inbound service interface
1.1.1.1 POS Inbound
This function enables you to transfer transaction data from the POS system to the PIPE for further checking and processing.
Features
The system provides the following alternatives for supplying the PIPE with POS transaction data:
Synchronous Transfer with the Standard BAPI Structure
Asynchronous Transfer Using IDocs
Master data checks are automatically carried out during the inbound processing as described in Master Data Checks.
By default, the following BAdIs are activate in the inbound processing:
BAdI: POS Transaction Aggregation on Header Level
BAdI: POS Transaction Aggregation on Item Level
BAdI: POS Transaction Aggregation on Tender Level
BAdI: POS Transaction Data Distribution to Item Level
BAdI: POS Transaction Inbound Data Status Processing Enablement
For more information on the BAdIs listed above, refer to their corresponding descriptions in the SAP POS DM Customizing. Also, see Task Processing for In-
Memory Analytics.
1.1.1.1.1 Use of the BAPI /POSDW/BAPI_POSTR_CREATE
This function enables you to transfer POS transaction data synchronously from the POS store system to the PIPE. The use of the BAPI
/POSDW/BAPI_POSTR_CREATE is the preferred method for sending POS transaction data from a store to the PIPE and, if appropriate, processing the data
immediately (see also Real-Time Individual Processing (Trickle Feed)).
PUBLIC Page 6 of 83
Features
You have set up an RFC-capable program that transfers the POS transaction data from the store system to the BAPI and maps it to the required structures and
fields.
Activities
The store system transfers the data of the POS transactions to the BAPI /POSDW/BAPI_POSTR_CREATE . The BAPI receives the data and posts it to the
connected database. The POS transactions are generated automatically.
1.1.1.1.2 Use of IDocs
This function enables you to use IDocs to transfer POS transaction data from the POS store system to the PIPE and to make use of the advantages of
asynchronous transfer.
Activities
You can use different IDoc types in order to transfer different data from the POS system to the PIPE. In addition to the standard POS IDoc types, a generated IDoc
(message type /POSDW/POSTR_CREATEMULTIPLE ) is also available:
POS IDoc types:
You can use the following POS IDoc types for data transfer:
WPUBON : Transfer Detailed Sales Data to PIPE
WPUUMS : Transfer Sales Data Without Means of Payment Info to PIPE
WPUTAB : Transfer Means of Payment Information to PIPE
WPUFIB : Transfer Financial Transactions to PIPE
WPUKSR : Transfer Cashier Data to PIPE
WPUWBW : Transfer Goods Movements to PIPE
Generated ALE Interface:
You can use the generated message type /POSDW/POSTR_CREATEMULTIPLE for data transfer to PIPE. This way you can transfer the same POS
transaction data as with BAPI /POSDW/BAPI_POSTR_CREATE since the structure of the message type comprises all elements of the BAPI structure.
The interface then matches. The only difference is that the transfer is asynchronous with use of the IDocs.
1.1.1.2 Generation Using the POS Workbench
In this process, you manually generate POS transactions in the PIPE in order to use them productively or for test purposes.
Process
Start the POS Workbench and generate whatever POS transactions you wish as described under Editing POS Transaction Data.
1.1.1.3 Real-Time Individual Processing (Trickle Feed)
You can use this function to transfer POS transactions from the POS system to the PIPE in order to process them in real time and to supply the follow-on systems
with the corresponding data. Real-time individual processing therefore, comprises the complete processing of POS transaction data, and the POS inbound is only
the first part of this.
Activities
You transfer the occurring transaction data regularly and in real time to the PIPE using one of the POS Inbound options. Prioritize the tasks to be carried out and
assign them the task type Immediate Processing in order to carry out automatic checks and rules or to quickly supply follow-on systems with data. As soon as a
POS transaction is posted in the PIPE, the system carries out all defined checks immediately and sends the transaction data to the follow-on systems if no errors
have occurred. The processing there can now start.
Note
Carrying out certain checks (for example, the check for missing receipt numbers) can prove to be difficult in some situations with real-time individual
processing.
1.1.2 Aggregation of POS Transactions
In this process, the data of POS transactions are summarized (aggregation). Then you can send this aggregated data to other systems.
This significantly reduces the data volume generated. At the same time, the transfer of aggregated information improves performance and saves time.
PUBLIC Page 7 of 83
Process
The system provides two options for aggregating POS transaction data. On the one hand, you can set up automatic aggregation for processing of tasks that are
processed with the single-step procedure. On the other hand, you can form aggregates that are first stored in the database. These aggregates are then processed
in a subsequent step.
1.1.2.1 Aggregation in Task Processing
You would like to group and aggregate POS transaction data during task processing.
Prerequisites
Ensure that you have assigned the required aggregation methods in the PIPE Customizing to the tasks to be processed in the Tasks One-Step Processing
Tasks area. You can check the settings for the aggregation methods under Tasks One-Step Processing Tasks in Customizing and if you wish
you can configure your own aggregation method.
Activities
The system automatically performs the aggregation of POS transaction data within task processing.
You can choose between the following aggregation methods:
Aggregate Loyalty Items According to Customer Card Number:
The system aggregates loyalty data of POS transactions for each customer card number. The aggregation is also valid for loyalty data that is associated with
the sales items.
The aggregation method is intended for use in connection with the task of creating and sending Loyalty Data to SAP CRM.
Grouping According to Posting Date:
The system does not perform any specific aggregation for task processing, but simply groups the transactions to be processed according to their posting
date. In this way they are always unique thanks to their posting date.
Aggregation According to Material:
The system aggregates sales item data of POS transactions for each material number, unit of measure and currency and creates packages within task
processing.
The aggregation method is intended for use in connection with the task for creating and sending the IDoc WPUUMS.
Aggregating Material with Conditions:
The system aggregates sales item data of POS transactions for each material number, unit of measure and currency. The corresponding taxes and
discounts are also aggregated for the aggregation of the sales item data. The system creates the corresponding packages within the task processing.
Aggregation according to F&R Type and Material:
The system aggregates sales item data of POS transactions for each material number, unit of measure and currency and creates packages within task
processing.
The aggregation method is intended for use in connection with the task of sending data to SAP F&R and is generally to be used for this.
Aggregation Means of Payment:
The system aggregates the means of payment of POS transactions for each posting date, means of payment type and means of payment currency and
creates packages within task processing.
The aggregation method is intended for use in connection with the task for creating and sending the IDoc WPUTAB.
Aggregation Means of Payment Enhanced:
The system aggregates the means of payment of POS transactions for each posting date, POS number and cashier and creates packages within task
processing.
This aggregation method is intended for use in connection with the task for creating and sending the IDoc WPUTAB.
Aggregate Sales Items According to ItemID and Qualifier:
The system aggregates sales item data of POS transactions for each itemID, qualifier, unit of measure, and currency, and creates packages within task
processing.
Aggregate Sales Items According to ItemID and Qualifier with Details:
The system aggregates sales item data of POS transactions for each itemID, qualifier, unit of measure and currency. The corresponding taxes and
discounts are also aggregated for the aggregation of the sales item data. The system creates the corresponding packages within the task processing.
For each of the named aggregation methods you can set an additional time grouping criterion, the aggregation period. This enables you to use the system for even
finer aggregation. Only POS transactions that are in the same aggregation period are aggregated together. You can choose from the following aggregation period
options:
10-minute schedule line for time stamp
Posting Date
Posting date/Transaction currency
Hour of time stamp
Day of time stamp
Week of posting date
Week of time stamp
Month of posting date
Month of time stamp
After aggregation the system sends the data aggregated within the task processing, for which the aggregation was performed, on to the corresponding follow-on
system. For more information, see Task Processing.
1.1.2.2 Forming of Aggregates
PUBLIC Page 8 of 83
You can use this function to summarize POS transaction data by updating it to aggregates in the database. Then, in a second step, you can process the
summarized data further.
Prerequisites
Ensure that you have made the necessary settings in the PIPE Customizing.
For more information, see Aggregation Tasks.
Features
Summarization of POS transaction data by way of formation of aggregates is carried out using separate tasks (aggregation tasks) that can be set for POS
transactions.
1.1.3 Task Processing
In this process, you process one or more of the tasks provided by the system for specific transaction data.
Operations on POS transactions are called tasks. The system provides the following task types for processing POS transactions:
Tasks for supplying follow-on systems with POS transaction data
Tasks that are to be carried out manually, where completion is retained in the PIPE as a reminder
Tasks for checking transaction data
Aggregation tasks that serve to form aggregates by summarizing POS transaction data
The following table provides an overview of the tasks that are provided for processing in the standard system:
Task Code Task Description
0001 Supply BW Without Distribution
0002 Sales Audit Performed, Manual Task
0004 Supply BW with Distribution
0005 Supply of Old POS Content in BW
0009 Generate WPUBON IDoc (Non-Goods Items)
0010 Generate WPUBON IDoc
0011 Generate WPUWBW IDoc
0012 Generate WPUFIB IDoc
0013 Generate WPUTAB IDoc
0014 Generate WPUUMS IDoc
0015 Credit Card Settlement
0016 Confirmation of Credit Card Settlement
0017 Supply ERP Inventory Management
0018 Supply CRM Loyalty Interface
0020 Supply SAP Forecasting and Replenishment
0030 Check Balancing for Totals Transactions
0040 Perform Transaction Reversal
0050 Supply - DMF-Based Applications
0060 Calculation for Short/Over Balancing
0061 Send Short/Overs to ERP
0101 Oil & Gas SSR Payment Card Data Processing
1001 Check for Duplicate Transaction Numbers
1002 Check for Receipt Numbers Without Gaps
5001 LPA: Provision of Suspicious Transactions
8001 Aggregate Transaction Data for Analytics
8002 Supply Analytics Cont. with Distributed Transaction Data
8003 Determine Transaction Data Status
The specified aggregation tasks are listed under Aggregation Tasks.
Prerequisites
If you wish to carry out a certain task for a defined POS operation, and thus for a specific type of POS transaction, you ensure that the following settings are made
PUBLIC Page 9 of 83
in PIPE Customizing.
Ensure that you have set the type of tasks to be carried out under Tasks One-Step Processing Define Tasks or Tasks Two-Step
Processing Define Aggregation Task depending on the requirements to one of the values Immediate Processing , Collective Processing or Manual
Processing .
Under POS Transactions , check the task group that is assigned to the relevant POS transaction and assign a task group if required.
Under Tasks Define Task Group , ensure that the task group that is assigned to the transaction type of your POS transaction actually exists.
Ensure that the task to be carried out is assigned to the relevant task group under Tasks Assign Tasks to Task Group .
Check also, if necessary, if processing of a task for a defined POS transaction type makes sense.
Process
Depending on the setting in PIPE Customizing for the type of task to be processed, you have the following options for carrying out task processing:
Automatic task processing:
In the case of tasks with type Immediate Processing , the system carries out the processing immediately the POS transaction is created. The creation of
POS transactions in the POS Workbench is an exception to this. In this case, no immediate processing takes place and you must carry out processing as
described in the following section.
Task processing using POS Workbench or PIPE Dispatcher:
In the case of tasks with type Collective Processing , you must start processing of the task with an explicit call.
To do this, you have the following two options:
You carry out the task processing using the POS Workbench.
For more information, see Control of Task Processing.
You carry out task processing with the PIPE Dispatcher (transaction /POSDW/PDIS).
For more information, see Using the PIPE Dispatcher.
Manual task processing and conversion of task status
In the case of tasks with type Manual Processing , you must set the task to Completed by way of the user interface as soon as you have completed it. To
do this, use the POS Workbench.
For more information, see Control of Task Processing.
1.1.3.1 Sending Data to SAP CRM
In this process, you send the loyalty data of POS transactions to SAP CRM via the service interface LoyaltyMembershipActivityJournalCRMBulkRequest_Out .
Prerequisites
In Customizing, you created the outbound task by choosing in the IMG POS Data Management POS Inbound Processing Tasks One-Step
Processing Define Tasks and by copying the Profile 0001 Task Code 0018 as a template. In the Parameters for this task, also ensure that in the Control
Section, the Code for Aggregation Method is 0009.
Process
The Task Code 0018 Transfer Loyalty Data is available in the standard SAP system for sending loyalty data at header level or retail line item level that is
available in POS transactions to CRM.
You send the relevant data aggregated by setting the aggregation method for task processing in task Customizing according to the customers' loyalty card number.
For more information, see Aggregation in Task Processing.
You carry out processing of the task for the relevant POS transactions depending on the task type. For more information, see Task Processing.
Once the task has been carried out successfully, the system sets the task status for all processed POS transactions to Completed .
1.1.3.2 Using the PIPE Dispatcher
You process one or more tasks for a quantity of POS transactions in the background.
Procedure
1. In the PIPE menu, choose POS Processing POS Data Parallel Processing and start the PIPE Dispatcher (transaction /POSDW/PDIS).
2. Set the data selection criteria you require. Enter the tasks to be processed by entering the corresponding task codes in the selection screen. In addition, you
can restrict the POS transactions to be considered by way of store, posting date, and business transaction. If you require further selection criteria, you can
extend the data selection area by choosing the pushbutton Further Selections .
3. By selecting the appropriate checkbox in processing control you can:
Carry out a processing test run:
The processing protocol displays the results of processing with your chosen selection criteria. The test run does not make any changes to the
database.
Process errors:
Tasks that have status Error or Error During Cancellation are taken into account in processing if you first choose the status Ready or Ready to be
Canceled . Remove the errors so that the system can process the relevant tasks.
Consider Customizing changes:
Tasks that have subsequently become active for POS transactions by way of Customizing changes are taken into account by the system.
Switch off prioritization of task processing:
PUBLIC Page 10 of 83
The system carries out processing of the tasks in the order in which they are entered on the selection screen. This way you can override the priorities
assigned in task Customizing.
4. You can enable parallel processing using the PIPE Dispatcher. To do so, select the Parallel Processing checkbox and enter the appropriate parameters
in the selection screen.
5. Then you can select the criteria for the processing protocol output. By selecting Protocols you can view the saved protocols of earlier processing. The
system displays a specific selection screen for choosing the protocol. Here you can restrict the choice of the relevant protocol as well as set time
restrictions, for example, for users or programs.
6. Perform the processing once you have made all the settings. The result is displayed in the processing protocol if you have activated this. If errors have
occurred, the system displays a red status symbol with a corresponding error message. If a processing step was performed successfully, the system
displays a green status symbol.
7. You can view the task status for individual POS transactions in the POS Workbench.
More information, see Using the POS Workbench.
1.1.3.3 Sending Data to POS Analytics
In this process, you send the data from POS transactions to POS Analytics in order to create analyses and statistics such as sales analysis, error statistics, or
loss prevention. For more information, see https://help.sap.com/bicontent BI Content Version Application Help Industry Solutions Trading Industries
Retail Trade Store Analytics POS Analytics .
Prerequisites
You have made the following settings in PIPE Customizing.
You have set the type of the task to be carried out under Tasks One-Step Processing Define Tasks depending on the requirements to either
Immediate Processing or Collective Processing and you have checked the correctness of the other task settings.
Under POS Transactions , you have checked the task group that is assigned to the relevant POS transaction and you assign a task group if required.
You have ensured that the task group, which is assigned to the transaction type of your POS transaction, exists under Tasks Define Task Group .
You have ensured that the task to be carried out is assigned to the relevant task group under Tasks Assign Tasks to Task Group .
Process
The following tasks are available in the standard system for sending data to POS Analytics:
0001: Supply BW Immediately, Non-Aggregated, with Distribution
0004: Supply BW with Distribution
Carry out processing of the task for the relevant POS transactions depending on the task type.
For more information, see Task Processing.
If the task has been carried out successfully, the system sets the task status for all processed POS transactions to Completed .
1.1.3.4 Sending Data to SAP Retail
You can send the data from POS transactions to SAP Retail in order to generate follow-up documents there or to process the data in other ways.
The following options are available for sending POS transaction data to SAP Retail:
Send Sales Data via IDoc WPUBON
Send Sales Data via IDoc WPUUMS
Send Means of Payment Data via IDoc WPUTAB
Send Financial Transaction Data via IDoc WPUFIB
Send Goods Movement Data via IDoc WPUWBW
Alternatively, you can also supply SAP Retail with data by generating aggregates and carrying out the corresponding outbound processing.
For more information, see Outbound Processing.
1.1.3.4.1 Sending Sales Data via IDoc WPUBON
In this process you send the sales data of POS transactions, both individually and summarized, to SAP Retail. You can use the IDoc WPUBON for this to transfer
the following data:
Header information of POS Transaction
Data of sales items
Discount information
Tax information
Tender data
Prerequisites
Process
Both of the following tasks are available for sending sales data to SAP Retail when using the IDoc WPUBON.
0010 - Generate IDoc WPUBON
0009 - Generate IDoc WPUBON (Non-Merchandise Items)
With the provision of a separate task for non-merchandise items, you can process this item data at an early stage independently of the merchandise item data and
then send it to SAP Retail.
Carry out processing of the task for the relevant POS transactions depending on the task type.
1.1.3.4.2 Sending Sales Data via IDoc WPUUMS
In this process you can send the sales data of multiple POS transactions, summarized, to SAP Retail. You can use the IDoc WPUUMS for this to transfer the
following POS transaction data:
Header data:
Store
Posting date
Transaction currency
Data of sales items
Discount information
Tax information
Note
Transfer of tender data via IDoc WPUUMS is not possible. If you wish to transfer this data also to SAP Retail, you send, in addition to IDoc WPUUMS
also the IDoc WPUTAB to SAP Retail.
Prerequisites
Process
The task 0014 Generate IDoc WPUUMS is available for sending sales data to SAP Retail when using the IDoc WPUUMS.
If you wish to send the relevant data aggregated, you have to set an appropriate aggregation method for task processing in task Customizing. For more information,
see Aggregation in Task Processing.
Carry out processing of the task for the relevant POS transactions depending on the task type. For more information, see Task Processing.
1.1.3.4.3 Sending Means of Payment Data via IDoc WPUTAB
In this process you can send means of payment data of multiple POS transactions (summarized) to SAP Retail. You can use the IDoc WPUTAB for this to
transfer the following POS transaction data:
Header data: store, posting date, department, POS number, and cashier
Means of payment data
Prerequisites
The task 0013 Generate IDoc WPUTAB is available in the standard system for sending means of payment data to SAP Retail using the IDoc WPUTAB.
If you wish to send the relevant data aggregated, you have to set an appropriate aggregation method for task processing in task Customizing. For more information,
see Aggregation in Task Processing.
1.1.3.4.4 Sending Financial Transaction Data via IDoc WPUFIB
In this process you can send financial transaction data related to POS transactions to SAP Retail. You can use the IDoc WPUFIB for this to transfer the following
POS transaction data:
Header data:
Store
Posting date
Transaction number
Cashier
Financial transaction data
Prerequisites
Process
The task 0012 Generate IDoc WPUFIB is available in the standard system for sending financial transaction data to SAP Retail using the IDoc WPUFIB.
1.1.3.4.5 Sending Goods Movement Data via IDoc WPUWBW
In this process you can send goods movement data from POS transactions to SAP Retail. You can use the IDoc WPUWBW for this to transfer the following POS
transaction data:
Header data
Store
Posting date
Transaction number
Cashier
Goods movement data
Prerequisites
Process
The task 0011 IDoc WPUWBW is available in the standard system for sending goods movement data to SAP Retail using the IDoc WPUWBW.
Sending Data to SAP F&R
In this process you send the data of POS transactions to SAP Forecasting & Replenishment (SAP F&R).
Prerequisites
Process
The task 0020 Supply SAP Forecasting and Replenishment is available in the standard system for sending sales data, goods receipt information, and goods
issue information to SAP F&R.
You should send the relevant data aggregated by setting the aggregation method for task processing in task Customizing according to the F&R type and material.
For more information, see Aggregation in Task Processing.
1.1.3.6 Sending Data to Credit Card Settlement
In this process, you send transaction data from credit card payments to credit card settlement and receive confirmation of the processing status.
Prerequisites
Process
The standard system provides the following tasks for sending transaction data to credit card settlement:
0015: Credit Card Settlement
0016: Confirmation of Credit Card Settlement
Using task 0015, you can transfer the settlement data to credit card settlement.
The external system further processes the data asynchronously and, on completion of settlement, provides confirmation of the result of processing. The
corresponding status is updated as status of the manual task 0016 in the PIPE.
1.1.3.7 Outbound of sales data to SAP DMF-based applications
You can use this function to send the sales and related data from POS sales transactions to SAP DMF-based receiver systems. This data is needed by SAP
Demand Management Foundation (SAP DMF) to create suitable demand models. In addition, other applications besides SAP DMF that require up-to-date sales
information can also make use of this data.
The following information is transferred:
Data for the combination of store, day, product and offer:
Sales in base unit of measure
Net sales in local currency of the store
Gross sales in local currency of the store
Transaction count
Squared sales in base unit of measure (squared sales is calculated per transaction and then added to existing data)
Cubed sales in base unit of measure (cubed sales is calculated per transaction and then added to existing data)
Data for the combination of store and day:
Store traffic
You can perform the transfer in either of two ways:
One-step process - In the standard customizing (profile 0001) this is provided as the task with code 0050.
Two-step process:
The aggregation of the transactions in a POS aggregate is done in the first step.
The outbound of the aggregated data is done in the second step.
In the standard customizing this function is provided as follows:
Aggregation of transactions is done by the task with code 2050.
The POS aggregate has code 0050.
The corresponding outbound task is done by the task with code 3050.
Choose either the one-step process or the two-step process based on your processing requirements:
The advantage of the one-step process is that it has the minimum overall resource consumption (runtime, disk space). This advantage occurs when the
block size is not restricted and all data to be sent is available. (The transfer of POS data takes place after shop closing when the complete POS upload
has taken place). If either the block size is restricted or the transfer starts when not all data is available, sales records might be sent several times. This
increases the network load as well as the workload on the receiver system.
The advantage of the two-step process approach is that each sales record is sent only once if the outbound task is executed after all transactions have
been aggregated in the POS aggregate. This reduces the network load and the workload on the receiver system. In addition, if you execute the aggregation
task (in a trickle feed scenario) multiple times during the day, the multiple execution as well as the restriction of the package size will have no
consequences for the transfer of data itself. If you restrict the package size you have more control over the main memory consumption. Additionally, if you
execute the aggregation task multiple times during the day, you reduce the workload in the critical night window. The drawback of this approach is the
higher overall workload because the POS aggregates have to be updated on the database.
Prerequisites
You have made the following settings in Customizing for POS Inbound Processing (PIPE):
You have created a suitable customizing profile by choosing General Settings Define Profiles .
You have assigned the transfer relevant stores to that profile by choosing General Settings Store Settings .
You have maintained a task group for the aggregation and transfer of sales transactions by choosing Tasks Define Task Group .
Transaction types:
You have maintained a transaction type group for the transfer relevant (sales) transactions by choosing POS Transactions Define Type Group for
POS Transactions .
You have maintained the transfer relevant transaction types and assigned them to the corresponding transaction type group and task group by choosing
POS Transactions Define POS Transaction Type .
Sales item types:
You have maintained the relevant sales item type groups by choosing POS Transactions Define Type Group for Sales Items .
You have maintained the transfer relevant sales item types and assigned them to the corresponding item type group and task group by choosing POS
Transactions Define Sales Item Types .
Tax types:
You have maintained the relevant tax type groups by choosing POS Transactions Define Type Group for Taxes .
You have maintained the relevant tax types and assigned them to the corresponding tax type groups and task group by choosing POS Transactions
Define Tax Types .
Discount types:
You have maintained the relevant discount type groups by choosing POS Transactions Define Type Group for Discounts .
You have maintained the relevant discount types and assigned them to the corresponding discount type groups and task group by choosing POS
Transactions Discount Type .
When using the one-step process:
You have created the outbound task by choosing Tasks One-Step Processing Define Tasks (using task 0050 for profile 0001 as a copy
template). You have set the task type to 1 (Collective processing). You have set the parameter DMF_APPS to a suitable value depending on the set of
applications running on the receiver system.
You have maintained the RFC destination of the receiver system by choosing Tasks Define Additional Details for Tasks .
You have assigned the task to the corresponding task group for the transfer of sales transactions by choosing Tasks Assign Tasks to Task Group .
When using the two-step process:
You have created the task for the aggregation of data in Customizing by choosing Tasks Two-Step Processing Define Aggregation Task (using
task 2050 for profile 0001 as a copy template). You have set the task type to 1 (Collective processing). You have set the parameter DMF_APPS to a
suitable value depending on the set of applications running on the receiver system.
You have created the task for the outbound of data by choosing Tasks Two-Step Processing Define Outbound Tasks (using task 3050 for profile
0001 as a copy template).
You have maintained the RFC destination of the receiver system by choosing Tasks Additional Details for Outbound Tasks .
You have assigned the aggregation task to the corresponding task group for the transfer of sales transactions by choosing Tasks Assign Tasks to
Task Group .
If you have set the parameter DMF_APPS: You have ensured that for the value of this parameter an active implementation for the BAdI
/POSDW/DMF_RELEVANCE exists (see Customizing activity Integration with other SAP components DMF based applications Control the transfer
relevance of products ).
Activities
The aggregation and outbound of sales data is executed using the existing PIPE framework. You can find further information under Task Processing.
1.1.3.8 Task Processing for POS In-Memory Analytics
If you have implemented SAP POS DM on SAP NetWeaver BW powered by SAP HANA and want to accelerate decision making in your business using the
POS In-Memory Analytics content, the following tasks are provided for processing in the standard system:
8001 Aggregate Transaction Data for Analytics
8002 Supply Analytics Cont. with Distributed Transaction Data
8003 Update Data Status for Analytics
For more information on tasks for POS In-Memory Analytics, see:
Enhancing Transaction Data for POS In-Memory Analytics
Supplying POS In-Memory Analytics with Distributed Transaction Data
Updating Transaction Data Status
Prerequisites
To use POS In-Memory Analytics and to process the associated tasks, SAP POS DM must be implemented on SAP NetWeaver BW powered by SAP HANA.
1.1.3.8.1 Enhancing Transaction Data for POS In-Memory

Analytics
In this process, you enhance the transaction header, item, or tender information to accelerate the querying of data when you use the POS In-Memory Analytics
content.
By default, the enhancement of transactional data is performed during the POS Inbound process by the following activated BAdIs:
BAdI Implementation Transaction Data Enhancement Description
POS Transaction Aggregation on Header Level /POSDW/ANALYTIC_AGG_HEADER_IMP The start timestamp (or business day date, if no start
timestamp is present) contained in the transaction header
is decomposed into separate year, month, day, hour, and
calendar week values. This accelerates grouping by time
period when querying the transactional data.
POS Transaction Aggregation on Item Level /POSDW/ANALYTIC_AGG_ITEM_IMP The included taxes and discounts for individual transaction
line items are totaled and written to dedicated item
analytics fields in the TLOGF table. This eliminates the
need for complex and time-consuming joins when
querying data.
Note that the taxes and discounts included in the
transaction header, and which are distributed to the
transaction line items, are not included in these sums.
POS Transaction Aggregation on Tender Level n/a Currently, no default implementation is provided.
If you disable the execution of these BAdIs during the POS Inbound process, you can still perform the enhancement of transactional data by using task 8001
Aggregate Transaction Data for Analytics .
For more information about the BAdIs listed above, see their accompanying documentation in the Customizing under Customer-Specific Enhancements and
BAdI Implementations Enhancements for In-Memory Analytics .
Voided Transactions and Line Items

Whether you are using the POS Transaction Aggregation on Header Level BAdI, the POS Transaction Aggregation on Item Level BAdI, or task 8001
Aggregate Transaction Data for Analytics , voided transactions and line items are flagged by SAP POS DM (DISTVOID field of the TLOGF table). This allows
voided transactions and line items to be excluded from the calculations performed by the POS In-Memory Analytics content.
For more information on how SAP POS DM populates the DISTVOID field, refer to the documentation accompanying the POS Transaction Aggregation on
Header Level and the POS Transaction Aggregation on Item Level BAdIs.
Prerequisites
SAP POS DM implemented on SAP NetWeaver BW powered by SAP HANA.
If you are using task 8001 Aggregate Transaction Data for Analytics , you have made the following settings in PIPE Customizing:
You have set the Type of Task to be carried out under Tasks One-Step Processing Define Tasks as required for your implementation
and you have checked the correctness of the other task settings.
Under POS Transactions , you have checked the task group that is assigned to the relevant POS transaction and you assign a task group if
required.
You have ensured that the task group, which is assigned to the transaction type of your POS transaction, exists under Tasks Define Task
Group .
Process
By default, the BAdI implementations for the transaction data enhancements are activated in the POS Inbound process.
If you have chosen to deactivate the BAdI implementations for transaction data enhancements, you can use task 8001 Aggregate Transaction Data for Analytics
to perform the transaction data enhancements on transactions in the TLOGF table. For more information, see Task Processing.
1.1.3.8.2 Supplying POS In-Memory Analytics with Distributed

Transaction Data
In this process, you distribute the discount, tax, and tender information contained on the header level of a POS transaction to the individual transaction line items.
This distribution reduces the execution time of POS In-Memory Analytics queries.
Caution
The distribution performed in this process assumes a standard implementation of the SAP POS DM and does not take into consideration any custom sales
item types or distribution requirements. Distribution can significantly impact analytic reports built on POS In-Memory Analytics Content; ensure that the
standard distribution calculations fulfill your business requirements.
By default, the distribution is performed during the POS Inbound process by the following activated BAdI:
POS Transaction Data Distribution to Item Level /POSDW/ANALYTIC_DIST_ITEM_IMP The discount, tax, and tender information contained on the
header level of a POS transaction is distributed to the
individual line items. The distributed figures are stored in
dedicated fields of the /POSDW/TLOGF table.
The distribution is performed based on the line item's
sales amount within a transaction as follows:
line item discount amount = transaction discount
amount * [ | line item sales amount | ÷ (sum of all |
transaction line item sales amounts |) ]
Discounts are not distributed to line item types for
which the Remove f. Distr. of Header Discounts
option of the POS Inbound Processing POS
Transactions Define Sales item Types
Customizing activity is enabled.
line item tax amount = transaction tax amount * [ |
line item sales amount | ÷ (sum of all | transaction
line item sales amounts |) ]
Excluded taxes are not considered in the
distribution. In the SAP POS DM Customizing
under POS Inbound Processing → POS
Transactions → Define Tax Types , use the Tax
Included checkbox to specify if a tax type is
“included” or “excluded”.
Furthermore, taxes are not distributed to line item
types for which the Remove Item fr. Distr of
Header Tax option of the POS Inbound
Processing POS Transactions Define Sales
item Types Customizing activity is enabled.
line item tender amount = transaction tender
amount * [ | line item sales amount | ÷ (sum of all |
transaction line item sales amounts |) ]
Tenders are not distributed to line item types for
which the Remove from Distribution of Tender
option of the POS Inbound Processing POS
Transactions Define Sales item Types
Customizing activity is enabled.
Note
Absolute values are used for the line item and
transaction sales amounts to ensure that the ratio
between the two results in a positive value.
If you disable the execution of this BAdI during the POS Inbound process, you can still perform the data distribution by using task 8002 Supply Analytics Cont.
with Distributed Transaction .
For more information about the BAdI listed above, see its accompanying documentation in the Customizing under Customer-Specific Enhancements and BAdI
Implementations Enhancements for In-Memory Analytics .
Prerequisites
If you are using task 8002 Supply Analytics Cont. with Distributed Transaction , you have made the following settings in PIPE Customizing:
and you have checked the correctness of the other task settings.
required.
Group .
Process
By default, the BAdI implementation for data distribution is activated in the POS Inbound process.
If you have chosen to deactivate the BAdI implementations for data distribution, you can use task 8002 Supply Analytics Cont. with Distributed Transaction Data
to perform the data distribution on transactions in the TLOGF table. For more information, see Task Processing.
1.1.3.8.3 Determining Transaction Data Status
The POS In-Memory Analytics content allows you to perform analysis directly on the POS transactional data stored in the TLOGF table in the SAP HANA
database.
In this process, you verify the transactional data stored in the database prior to querying it. As a result, a data status value is stored in the TLOGF table for each
transaction. SAP POS DM maintains the data status of a transaction record:
During inbound processing and when the editor is started for a particular POS transaction within the POS Workbench.
The data status is determined using the following BAdI, which is activated in the POS Inbound process by default:
POS Transaction Inbound Data Status Processing /POSDW/ANALYTIC_INB_DATASTATUS The data status is maintained for the transaction.
Enablement
For more information about the BAdI listed above, see its accompanying documentation in the Customizing under Customer-Specific Enhancements and
BAdI Implementations Enhancements for In-Memory Analytics .
During task processing, using task 8003 Determine Transaction Data Status .
The data status of a transaction is set to one of the following values:
Data Status Description
0 (Undefined) This status is assigned to transactions on which no master data checks have been
performed and no tasks have been processed.
1 (Error) This status is assigned to transactions which fail a master data check or for which at least
one processing task has resulted in an Error status.
2 (Master Data Check OK; No Tasks Processed) This status is assigned to transactions that pass a master data check and for which no
tasks have been processed.
3 (MD Check OK; One or More Tasks Processed, No Tasks in Error) This status is assigned to transactions that pass a master data check and for which:
At least one task has been processed
All tasks that have been processed have no errors (not in Error state)
Prerequisites
You have made the following settings in SAP POS DM Customizing:
and you have checked the correctness of other task settings.
You have enabled the Data Status Relevant Flag under Tasks One-Step Processing Define Tasks for all tasks that process
transactional data stored in the TLOGF table and which you consider to have impact on the data status.
required.
Group .
You have defined a check profile to used for data status determination under General Settings Define Check Profiles .
You have specified the identifier of a check profile in the Master Data Checks for Data Status Determination section of the General Settings
Define Profiles Customizing activity.
You have enabled the Checks Using Check Profiles checkbox under General Settings Define General Settings .
For more information , see Master Data Checks.
Process
Task 8003 Determine Transaction Data Status is available in the standard system for updating the data status of a transaction stored in the TLOGF table.
When using task 8003 , we recommend that you also use rules to ensure that task 8003 is the last task to be executed on a transaction. For more information,
see Task Processing.
Note
Manual task status changes in the POS Workbench are not detected by task 8003 Determine Transaction Data Status and will not trigger changes to the
data status.
1.1.3.9 Aggregation Tasks
You use this function to summarize POS transaction data by forming aggregates that the system first stores in the database. This way you have the facility to send
the summarized data to follow-on systems at a later date using the PIPE outbound processing.
Prerequisites
You have set the type of the task to be carried out under Tasks Two-Step Processing Define Aggregation Task depending on the requirements
to either Immediate Processing or Collective Processing and you have checked the correctness of the other aggregation task settings.
You have ensured that the data of the aggregation level assigned to the aggregation task is set correctly under Tasks Two-Step Processing Define
Aggregation Level .
Under POS Transactions , you have checked the task group that is assigned to the relevant POS transaction and you have assigned a task group if
required.
Under Tasks Define Task Group , you have ensured that the task group that is assigned to the transaction type of your POS transaction actually
exists.
Activities
The system summarizes POS transaction data by way of formation of aggregates using separate tasks (aggregation tasks) that you can set for POS transactions.
The following table provides an overview of the aggregation tasks that are provided in the standard system. The description shows the type of aggregation:
2001 Material/Stock
2002 Material/Stock with Taxes and Discounts
2011 Register/Cashier/Department/Tender
2012 Means of Payment
2050 Material + Offer (DMF-Based Applications)
Carry out processing of the aggregation task for the relevant POS transactions depending on the task type. For more information, see Task Processing.
During processing, the system forms a new aggregate if no open one exists for the chosen aggregation method. If another aggregate exists with aggregated data
records, which has not yet been completed, the system aggregates the data of the POS transactions to be processed in this aggregate.
When the system has successfully carried out the aggregation task, it sets the status of the task for all processed POS transactions to Completed .
You can send the data of all the aggregates generated through aggregation tasks to other systems by way of the available outbound processing. The aggregation
tasks provided, therefore, are only appropriate with use of certain outbound tasks. For more information, see Outbound Processing of Aggregates.
1.1.3.10 Using Outbound Tasks
With this function you can send data, which you have cumulated in the form of POS aggregates and updated in the database, for further processing to the follow-on
system.
Prerequisites
You have made the following settings in PIPE Customizing:
You have assigned the correct aggregation task to the outbound task to be processed under Tasks Two-Step Processing Define Aggregation
Task ; this must also adjust to the chosen outbound task BAdI filter.
You have checked that the further data of the outbound task is set correctly under Tasks Two-Step Processing Define Aggregation Task .
Activities
Using an outbound task and associated outbound processing, you can now send data that you previously updated in an aggregate in the aggregation task to the
follow-on system. The following table provides an overview of the outbound tasks that are provided in the standard system. The description shows the type of
outbound tasks:
3001 Sales data at WPUUMS IDoc
3002 Means of Payment as WPUTAB IDoc
Perform the processing of the outbound tasks for the POS aggregates required using the PIPE outbound processing. For more information, see Outbound
Processing.
You can view the processing status of POS aggregates in the POS Workbench. For more information, see Monitoring POS Aggregates.
1.1.3.11 Tasks for Checking Transactions
You can check the POS transaction data using special tasks. The result of the check is reflected in the corresponding task status and remains evident until the
task is processed successfully at a later time.
The system provides the following tasks in the standard for checking transaction data:
1001: Check for duplicate transaction numbers
1002: Check for Receipt Numbers Without Gaps
0030: Check Balancing for Totals Transactions
For more information on the tasks mentioned, see Outbound Tasks and Outbound Processing of Aggregates.
1.1.3.11.1 Check for Duplicate Transaction Numbers
With this process you can define whether doubled transaction numbers for the POS transactions transferred to PIPE from the POS system.
Prerequisites
Process
The system provides you with task 1001 - Check for Duplicate Transaction Numbers in the standard. When processing the task, the system checks for a
number of POS transactions if the transaction numbers are duplicated for a specific POS number. The transaction numbers must therefore be unique for each
POS number.
1.1.3.11.2 Displaying Gaps in Receipt Numbers
With this process you can define whether gaps appear for the assigned transaction numbers for the POS transactions transferred to PIPE from the POS system.
Prerequisites
Process
The system provides you with task 1002 - Check for Receipt Numbers Without Gaps in the standard. When processing the task, the system checks for a
number of POS transactions if the transaction numbers for a specific POS number are numbered consecutively and that there are no gaps.
Any gaps show that not all POS transactions have been transferred from the POS system to the PIPE.
1.1.3.11.3 Checking Comparisons for Totals Transactions
Use this process to check whether the sums of the individual POS transactions correspond when combined to the relevant cash desk totals, which are transferred
in a totals transaction from the POS system. You want to document the result in the system as the status of a task processing.
Prerequisites
Process
The system provides you with task 0030 - Checking Comparisons for Totals Transactions in the standard. When processing the task only the corresponding
0004 rule - Check the Comparison of Totals Transactions is processed. The rule check result is reflected in the task status because no additional data
processing is set for the task.
1.2.2.2 Rules
You can check transaction data when processing tasks using predefined rules and then carry out a specific activity depending on the result. You use rules in
cases where you only wish to process tasks if certain conditions are fulfilled.
Prerequisites
You have ensured that the rule used in the PIPE Customizing is properly set under Tasks Define Rules and that the rule that is to be used for the relevant
task is assigned under Task One-Step Processing Define Tasks or Tasks Two-Step Processing Define Aggregation Task .
Activities
A rule consists of a condition and actions that are be performed if the condition is, or is not, fulfilled.
In contrast to task processing, which is performed package by package for multiple POS transaction, the system performs rules individually for each POS
translation within task processing. In doing so, each individual POS transaction can be excepted from task processing if the rule that is assigned is not fulfilled.
An assigned rule is normally checked while a task is processed.
The system offers you the following rule types:
Task Complete :
The system only performs the task processing, to which the rule is assigned, when another task in rule Customizing has already been successfully
processed.
BAdI :
The system performs a check of the POS transaction with a BAdI implementation. Only when the check has been successful does the system perform
task processing.
Link rules AND , OR , NOT as well as Perform all Linked Rules :
The system gives you the chance to link rules together logically. This means you can perform multiple rules for one task processing. The link rules mean:
AND Link:
All linked rules must be fulfilled.
OR Link:
At least one of the linked rules must be fulfilled.
NOT Link:
None of the linked rules are to be fulfilled.
Perform all Linked Rules:
The system processes all linked rules, irrespective of whether errors have occurred in the meantime so that a rule is not fulfilled. This behavior
highlights the difference from the AND link because there the system ends the execution with the first error.
Create the required link rule in Customizing in which you set out the required type and save it. Create the linking rule in Customizing. Then enter the link rule
into the Link Rule field for the each other rules that are to be processed.
This behavior can be used on multiple levels so that you can construct conditions that are as complex as you wish.
The following are possible actions from a result of a rule check in the standard:
The system performs the task processing because the rule is fulfilled. The status of the task processing of the POS transaction under consideration is
therefore dependent on the processing result.
Postpone the POS transaction: The task keeps the status Ready or Ready for Cancellation , but is excluded from further processing. This action is used
when the POS transaction does not fulfill a precondition, such as a previously processed task, for example.
The system changes the status to Error , Error During Cancellation or Rejected . In this case the POS transaction does not participate further in the
processing.
You can complete the named actions with actions of your own for fulfilled or not fulfilled rules as you wish and that way you can react according to your own
individual needs to the results of a rule check.
Rules are executed according to their priority. If priorities are equal then the alphabetical series of the rule code is followed.
The system provides the following rules in the standard:
0001: Balanced Transaction
0002: Check Credit Card Data
0003: Sales Audit Performed
0004: Check Balancing of Totals Transactions
0005: Calculation for Short/Over Balancing Performed
1.1.3.12.1 Check for Balanced Transaction
You can use this function to check if a transaction is balanced. A transaction is balanced if the total of the sales values of all sales items of a transaction including
taxes and discounts is equal to the total of the corresponding means of payment.
Prerequisites
The rule to be used with the relevant task is assigned under Tasks One-Step Processing Define Tasks or Tasks Two-Step Processing
Define Aggregation Task .
Customizing of the rule is set correctly under Tasks Define Rules . This is especially important if you wish to use the rule in conjunction with other
rules.
Features
For each POS transaction, the system carries out the rule automatically when processing tasks to which you have assigned the rule. Depending on the settings in
Customizing, this occurs together with other linked rules.
The processing can deliver the following results for each individual POS transaction:
The system processes the task and, if appropriate, carries out an operation predetermined by you in the event of a rule being checked successfully.
The system does not carry out task processing and places the task in status Ready or Ready to be Canceled .
The system does not carry out task processing and sets the task status to Error , Error During Cancellation, or Rejected .
The system does not carry out task processing and reacts by performing an operation you have predetermined.
For more information, see Rules.
This way you can see for each individual POS transaction if it is balanced or if an inconsistency exists.
1.1.3.12.2 Comparing Receipt Data and Cash Desk Totals
Use this function to check whether the sums of the individual POS transactions correspond when combined to the relevant cash desk totals, which are transferred
in a totals transaction from the POS system.
The rule performs the check for sales items, taxes, discounts, and means of payment of the relevant transactions in relationship to the cash desk totals.
Prerequisites
Define Aggregation Task.
rules.
Features
For each POS transaction, the system carries out the rule automatically when processing tasks to which you have assigned the rule. Depending on the
Customizing, this takes place in connection with other rules that are linked.
In this way you see whether the receipt data that has been checked corresponds in total to the relevant cash desk totals, or if there is an inconsistency.
This function for comparing transaction data and cash desk totals is also available as a single transaction that you can use as an alternative to using the rule. For
more information, see Checking Comparisons for Totals Transactions.
1.1.3.12.3 Check for Performance of Sales Audit
You can use this function to ensure that a sales audit, that is, a check of the POS transaction data, has already been performed before any other task is
processed.
Prerequisites
rules.
Features
This way, you can see if the status of the relevant task 0002 Sales Audit Performed, Manual Task has been set to Completed manually. If this is the case, you
should have completed the check of the transaction data earlier.
1.1.3.12.4 Credit Card Data Check
You can use this function to check the credit card data that has been used in payment in a POS transaction.
Prerequisites
rules.
Features
Based on the result, you can see if the credit card data relating to a POS transaction is in order.
1.1.4 Outbound Processing of Aggregates
In this process you send the data, summarized in the form of POS aggregates and updated to the database, to follow-on systems in order to be able to process it
further there.
Process
The outbound processing of a POS aggregate can be split into the following components:
1. Closing the aggregate:
This way no further update of data to the aggregate is allowed. Closing of an aggregate means that, during a subsequent aggregation of data, a new
aggregate is generated automatically.
2. Starting the outbound processing for the aggregate:
The aggregate records are split into packages. This step cannot then be undone.
3. Processing of the individual packages of an aggregate.
4. Receipt of package confirmations of recipient system (if planned in Customizing).
5. Following processing of all packages, the aggregate receives the status Completed .
1.1.4.1 Performing Outbound Processing
Procedure
If you wish to perform outbound processing, proceed as follows:
1. Start the PIPE Outbound Dispatcher (transaction /POSDW/ODIS), the report for PIPE outbound processing.
2. Set the data selection criteria you require. Enter the outbound tasks to be processed by entering the corresponding task codes in the selection screen. In
addition, you can restrict the POS aggregates that are to be taken into consideration, such as stores, aggregation levels, aggregation numbers, the
aggregation task used, package status and group.
3. By selecting the appropriate checkbox in processing control you can:
Close open aggregates
Start outbound processing and, through this, package creation
Process outbound tasks for POS aggregates
Reorganize a package status
Processed packages are confirmed by the receiver system. However, due to blocking, it is possible that the package status has not yet been updated. The
system carries out checks and changes the package status.
Set aggregate status to complete
Perform a processing check run
In a check run, the processing protocol displays the results of processing with your chosen selection criteria. This does not trigger database changes.
4. You can use the outbound dispatcher for parallel processing. To do so, select the Parallel Processing checkbox and enter the appropriate parameters in
the selection screen.
5. You can also select the criteria for the processing protocol output. By selecting Protocols you can view the saved protocols of earlier processing. The system
displays a specific selection screen for choosing the protocol. Here you can restrict the choice of the relevant protocol as well as set time restrictions, for
example, for users or programs.
6. Perform the processing once you have completed all your settings. The result is displayed in the processing protocol, provided you have activated this. If
errors have occurred, the system displays a red status symbol with a corresponding error message. If a processing step was performed successfully, the
system displays a green status symbol.
7. You can view the status for individual POS aggregates in the POS Workbench. More information, see Using the POS Workbench.
1.1.5 Archiving Transaction Data
You archive POS transaction data or POS aggregates and all related data if they are no longer required in order to reduce the volume of data in your system.
Prerequisites
Ensure that you have completed processing of the POS transactions and POS aggregates and that you no longer require the data.
Prior to archiving POS transactions or POS aggregates, ensure the following:
For all POS transactions for a Store/Date combination selected for archiving, all the tasks for these transactions must have the status Completed ,
Rejected , or Cancelled .
You no longer require the data you are archiving to be available SAP POS DM.
Procedure
1. Start transaction SARA and use the following archiving objects:
/POSDW/TL for archiving of POS transactions. If you are using SAP POS DM implemented on SAP NetWeaver BW powered by SAP HANA, use
archiving object /POSDW/TLF.
/POSDW/AGG for archiving of POS aggregates
You have the following options in each case:
Write data to an archive
Delete archived data from the system
View archived data
For POS transactions, you also have the possibility of reloading archived data into the system.
Alternatively, you can use the relevant reports for archiving of POS transactions and POS aggregates. These run in archive administration in the
background:
Write POS transactions to an archive: /POSDW/ARCHIVE_WRITE
Delete archived POS transactions from the system: /POSDW/ARCHIVE_DELETE
Read archived POS transactions: /POSDW/ARCHIVE_READ
Reload archived POS transactions: /POSDW/ARCHIVE_RELOAD
Write POS aggregates to an archive: /POSDW/ARCHIVE_WRITE_AGGREGATE
Delete archived POS aggregates from the system: /POSDW/ARCHIVE_DELE_AGGREGATE
Read archived POS aggregates: /POSDW/ARCHIVE_READ_AGGREGATE
1.1.6 Providing POS Transactions for Online Stock Queries and

Inventories During Opening Hours
With this function you can send POS transactions needed for online stock queries and physical inventories during opening hours to ERP.
Prerequisites
Ensure that you have made the following settings in PIPE Customizing to facilitate the PIPE-side processing:
You have set up task processing using the two-step process (update of aggregate data through an aggregation task and a later outbound task) for sending
sales data using the WPUUMS IDoc.
You have set up an aggregation task under Tasks Two-Step Processing Define Aggregation Task . Pay particular attention to the following:
Depending on your needs, you have either set the aggregation task to Immediate Processing or Collective Processing .
For the aggregation control you have selected Active Index and chosen aggregation period 11 - Posting Date/Transaction Currency .
For the aggregation level, choose either of the parameters 0001 or 0002 or an analog aggregation level of your own.
You have set up an aggregation task under Tasks Two-Step Processing Define Aggregation Task . Pay particular attention to the following:
You have assigned either the 3001 task filter, or an analog task filter of your own.
You have selected Confirmation Expected .
Under Tasks Define Index/Worklist for POS Transactions you have set up an index for unprocessed sales transactions with the following details:
You have chosen Save POS Transactions as time point for update.
You have chosen Aggregation Task as time point for deleting index information.
You have selected Master Data .
You have entered the appropriate aggregation task code in the Task field.
Under Integration with Other SAP Components General Assignments Assign Tasks to Task Codes choose the setting Two-Step Processing,
Outbound Task for task 03 - Transfer of Data to Inventory Management and assign the outbound task code to create the WPUUMS IDoc.
1.1.7 Encryption of Payment Cards
The following options are used for the encryption of payment cards:
· Encrypted storage of credit card numbers, cardholder names, and card expiration dates
· Masked display of credit card number
· Display of the complete credit card number
· Logging of display of the complete credit card number
The selection of the security level (with/without encryption/masking ), the update of the access log with unmasked display, the selection of the additional
authorization check with unmasked display and the number of visible characters with masking are controlled by way of the settings on payment card security
described below.
For display of the complete credit card number in the POS Workbench, a display pushbutton is visible in the segment for the credit card data behind the field for
the credit card number (if the authorization object B_CCSEC exists in the user master record). You can save each display of a non-masked payment card
number in an access log. This way you can trace which user has displayed which payment card and when.
Integration
Migration of old Data

The migration of existing POS transactions with credit card numbers without security level takes place using transaction /POSDW/PCAM. Note the settings for the
changeability of POS transactions if tasks with status Completed exist.
Archiving of Encrypted Credit Card Numbers

Archiving of the encrypted credit card numbers takes place by way of the archiving object CA_PCA_SEC.
Access Logs
You can evaluate the access to payment card data with the program RCCSEC_LOG_SHOW. In order to evaluate the access log, you require authorization for
activity 71 in the authorization object B_CCSEC.
You can delete the log records if these are at least one year old. You carry out deletion with program RCCSEC_LOG_DEL. In order to activate the deletion
program, you must have authorization for object B_CCSEC with activity 06.
Prerequisites
Making the Settings for Payment Card Security:

Make the general security settings using transaction SM30, maintenance view V_TCCSEC. Note that, on selection of the security level Masked Display, No
Encrypted Save, credit card numbers may be lost in the SAP System. This setting should only be selected if the credit card data is not to be processed further.
Application of the security settings occurs with all POS transactions with credit card information that are to be newly created or changed.
The steps described in the following section are only required if you use the security level Masked Display and Encrypted Save .
Setting Up the Encryption Software:

The functionality SAPCRYPTOLIB contains the necessary functions for encryption. Install SAPCRYPTOLIB. You can make general settings for execution of the
encryption software in the Implementation Guide (IMG) for SAP NetWeaver . Choose Application Server -> System Administration -> Maintain the Public Key
Information for the System.
If you set the encryption with transaction SSFA, you must use the application PAYCRD.
For more information, see Note 662340.
If you set the encryption with the transaction SSFVA, you must use the application PAYCRV.
For more information, see Converting to Versioned Encryption.
Setting Up the Encryption for Each Credit Card Institute:

Use transaction SM30, maintenance view V_TB033 to determine for each credit card institute whether credit card numbers are to be encrypted or not. The
settings can also be called up by way of the implementation guide (IMG) for cross-application components. Choose Payment Cards -> Basic Settings ->
Maintain Payment Card Type.
The complete security settings only come into effect if the encryption indicator is set. Note the following: If the encryption indicator (TB033) for a credit card institute
is not set, but the general security level (TCCSEC) is Masked Display and Encrypted Save , then the security level for this credit card institute is lowered to
Masked Display, No Encrypted Save .
For the display of complete credit card numbers, the authorization object B_CCSEC is required in the user profile.
1.3.3.1 Roles

Role: /POSDW/SALES_AUDIT
The business role of the Sales Auditor includes tasks for the daily monitoring of the POS inbound including analyses and evaluations.
Within POS Data Management, this role includes above all the transactions required for working in the POS Workbench and programs for processing POS data:
POS Workbench
POS WB: Selection and overview
POS WB: Overview of yesterday and today
POS WB: Errors yesterday and today
POS processing
Parallel processing of POS data
Parallel processing of IDocs
1.1.8.2 POS Inbound Processing Engine (PIPE) Administration

Role: /POSDW/ADMINISTRATOR
In addition to the /POSDW/SALES_AUDIT role, this role contains administrative activities that should not be carried out by normal users. These include deleting
data and explicitly reconstructing index records:
PIPE Administration
Reconstruct index records
Delete PIPE data
POS Data Warehouse Customizing
POS Processing
Parallel processing of POS data
Parallel processing of IDocs
1.1.9 Enterprise Services
1.1.9.1 Point Of Sale Transaction Processing
Definition
Point Of Sale Transaction Processing enables a company to receive, process and analyze point of sale data. It includes aggregation and forwarding
capabilities.
Technical Data
Software Component Version RTLPOSDM 1.0
Technical Name PointOfSaleTransactionProcessing
Namespace http://sap.com/xi/RTLPOSDM
Business Context and Use

This process component enables you to send retail, financial, and goods movement transactions that are performed in a retail store to SAP POS DM. Once in
SAP POS DM, transactions can be analyzed, aggregated and forwarded to subsequent processes.
This process component may be optionally referenced within the following software component(s):
Store Connectivity
ESM BI CONT
ESM Integration
Notes on SAP Implementation

To use the Point Of Sale Transaction Processing process component:
SAP POS DM must be configured for use according to the business requirements of the customer
You must be using the BW-BCT-ISR-PIP application component
You must be using one of the following software components:
SAP NW 7.0 BI Content Add-On 7.07, or higher
SAP NW 7.3 BI Content Add-On 7.37, or 7.47, or higher
More Information
Point Of Sale Transaction
1.1.9.1.1 Point Of Sale Transaction
Definition
A Point Of Sale Transaction is a business activity that is performed in a retail store, usually at the point of sale.
A point of sale transaction can refer to any of the following:

retail transaction
financial transaction
inventory movement transaction
control transaction
summary transaction
Technical Data
Technical Name PointOfSaleTransaction
Object Category Business Process Object

This business object enables you to send retail, financial, and goods movement transactions that are performed in a retail store to SAP POS DM. Once in SAP
POS DM, transactions can be analyzed, aggregated and forwarded to subsequent processes.
Constraints and Integrity Conditions

Currently, inventory transactions and summary transactions are not supported in the service operations.

To use the Point Of Sale Transaction business object:
More Information
Point Of Sale Transaction In
Point Of Sale Transaction Out
1.1.9.1.1.1 Point Of Sale Transaction In
Definition
An asynchronous inbound service interface to create point of sale transactions.
Technical Data
Category: SAP A2A
Direction inbound

The Point Of Sale Transaction In inbound service interface contains a bulk operation that can be used to create many point of sale transactions in SAP
POS DM with a single service call.
Point of sale transactions are transferred from the POS to the process component Point Of Sale Transaction Processing for further processing such as analysis,
aggregation and forwarding to subsequent processes.
The Point Of Sale Transaction In inbound service interface does not support the creation of inventory or summary transactions.

To use the Point Of Sale Transaction In service interface:
More Information
Create Point Of Sale Transaction as Bulk
1.1.9.1.1.1.1 Create Point Of Sale Transaction as Bulk
Definition
To create point of sale transactions in bulk.
Technical Data
Release State released
Technical Name PointOfSaleTransactionERPBulkCreateRequest_In
Namespace http://sap.com/xi/RTLPOSDM/Global2
Application Component BW-BCT-ISR-PIP
Related Web Service Definition POSTrxERPBulkCRTRQ
Category SAP A2A
Direction inbound
Mode asynchronous
Idempotency not applicable
Change/Update Behavior not applicable
P2P Communication Enabled yes
Notes on Release State (Technical Data)

This operation is the successor to operation of the same name under namespace http://sap.com/xi/BICONTENT/Global2.
Business Context
The operation is used to create POS transactions that have been sent from a POS system in the retail sector to SAP POS DM in bulk. This operation supports
encryption of credit card data and credit-card-related data.
The corresponding outbound service of this operation resides in third-party component.
Features
The Create Point Of Sale Transaction as Bulk inbound operation is available to create POS transactions that have been sent from a POS system
to SAP POS DM. The Create Point Of Sale Transaction as Bulk is a bulk operation that can contain multiple POS transactions within a single
message. It is also possible to mix different transaction types within a single message.
The implementation of this inbound operation allows posting of the following transaction types:
Retail transactions, for example, sales, return, payment on account
Financial transactions, for example, deposit, paid in, tender adjustment
Control transactions, for example, cashier sign-on, close register, open store
Per single transaction, credit card data and credit-card-related data can be transferred in a single encrypted data segment.
The implementation of the inbound service is completely embedded in the existing SAP POS DM infrastructure and environment and uses the API
/POSDW/CREATE_TRANSACTIONS_INT, which is also called in RFC, BAPI, and IDoc processing. Therefore, the structure of the service operation is mapped to
the importing parameter of table type /POSDW/TT_TRANSACTION_INT.
The business object Point Of Sale Transaction is sent as input and describes a business activity as performed in a retail store (including retail transactions,
financial movements, and goods movement).
Prerequisites
SAP POS DM must be configured for use according to the business requirements of the customer (the implementation of this inbound service is embedded in the
environment of SAP POS DM). The Customizing settings required are the same as for other possible inbound interfaces and techniques such as IDoc, BAPI, or
RFC.
Integration
This operation may be optionally referenced within the following software component(s):
Store Connectivity
ESM BI CONT
ESM Integration
There exists a mirrored test operation PointOfSaleTransactionERPBulkCreateRequest_Out under namespace
http://sap.com/xi/RTLPOSDM/Global2/Testing.
Error Handling
Forward error handling (FEH) is not available in SAP NetWeaver BW.
As a result, any message that cannot get processed within the service implementation (for example, due to a mapping error) is rejected and a corresponding fault
message is raised using cl_proxy_fault=>raise.

The operation cannot currently import inventory or summary transactions. This is currently only possible using IDoc, BAPI, and RFC interfaces.
Processing
The Create Point Of Sale Transaction as Bulk operation is an alternative method of transferring POS transactions to SAP POS DM. As a result, the
following apply:
Depending on the SAP POS DM Customizing settings (transaction /POSDW/IMG) for the store sending the data, you can post the incoming data
immediately or to use the SAP POS DM inbound queue (transactions /POSDW/QMON and /POSDW/QDIS) to post the data in a separate processing unit or
step.
If the SAP POS DM inbound queue is used, the XML messages of the service can be identified in the queue monitor in the following fields:
Key: Carries the GUID of the message instance
Object Type: Displays XML_DOC
Successfully processed POS transactions transferred using the Create Point Of Sale Transaction as Bulk operation can be monitored in the
POS Workbench (transaction /POSDW/MON0). In the POS Workbench, it is not possible to identify which method was used to import the transactions into
SAP POS DM (that is, operation, IDoc, RFC, or BAPI).
Configuration
Values of codelists of GDTs are mapped to corresponding values of SAP POS DM Customizing (criteria values of type 1 and type 2) to determine the PIPE
category code. These Customizing settings are found under: POS Data Management POS Inbound Processing Integration with Other SAP Components
SAP POS Definition of Values for Category Code Criteria .
Enhancements
The /POSDW/SE_POS_TRANSACT_INBOUND Business Add-In (BAdI) is available for this operation under Enhancement Spot
/POSDW/SPOT_SE_POS_TRANSACTION.
1.1.9.1.1.2 Point Of Sale Transaction Out
Definition
An asynchronous outbound service interface to confirm the creation of point of sale transactions in SAP POS DM.
Technical Data
Category SAP A2A
Direction outbound

The is outbound service interface groups operations that send out confirmations of the creation of point of sale transactions in SAP POS DM.

The Point Of Sale Transaction Out outbound service interface does not support the confirmation of creation of inventory or summary transactions.

To use the Point Of Sale Transaction Out service interface:
More Information
Request Loyalty Membership Activity Journal as Bulk
1.1.9.1.1.2.1 Request Loyalty Membership Activity Journal as

Bulk
Definition
To send a mass request from SAP POS DM to loyalty membership activity.
Technical Data
Release State released
Technical Name LoyaltyMembershipActivityJournalCRMBulkRequest_Out_V1
Namespace http://sap.com/xi/RTLPOSDM/Global2
Application Component BW-BCT-ISR-PIP
Related Web Service Definition /POSDW/CO_LylMbrshpActJrBkReq
Category SAP A2A
Direction outbound
Mode asynchronous
Idempotency no
P2P Communication Enabled no
Notes on Release State (Technical Data)

This operation is the successor to operation of the same name under namespace http://sap.com/xi/BICONTENT/Global2.
The change to the XML namespace allows for optional P2P communication.
Business Context
The operation sends loyalty information from SAP POS DM to SAP CRM. Loyalty information can be included at the header level or at the retail line item level of
the POS transaction. Customizing settings determine how the service is filled.
Features
Initially, a transaction log (TLOG) containing loyalty information is sent to the SAP POS DM. Once data is in SAP POS DM, loyalty information within the TLOG
must be sent to SAP CRM using the operation Request Loyalty Membership Activity Journal as Bulk. Loyalty points/amounts are aggregated
based on the customer card number.
Different options are as follows:
Send loyalty amount at header level
Send loyalty points at header level
Send loyalty amount at retail line item level
Send loyalty points at retail line item level
Main nodes of the operation are as follows:
MemberParty: Contains the customer loyalty card number
SalesDocumentReference: Contains the transaction number, the store ID, and the loyalty amount
Point: Contains loyalty points
Prerequisites
The system must call Maintain Loyalty Membership Activity Journal before using the Request Loyalty Membership Activity
Journal as Bulk operation. This operation is not available in SAP POS DM but is available in a system that uses the operation to create loyalty membership
activity with the POS transaction details.
Integration
This operation may be optionally referenced within the following software component(s):
Store Connectivity
ESM BI CONT
ESM Integration
Error Handling
Forward error handling (FEH) is not available in SAP NetWeaver BW.
As a result, any message that cannot get processed within the service implementation (for example, due to a mapping error) is rejected and a corresponding fault
message is raised using cl_proxy_fault=>raise.
Typical errors are as follows:

Customizing is missing for loyalty data transfer
A duplicate customer card number is found, which means no aggregation is done
An empty customer card number is detected

The operation cannot currently support inventory or summary transactions.

The Supply CRM Loyalty Interface task in SAP POS DM sends loyalty information to CRM component using the service interface. This task must be set
up for the retail store that is being used.
Inside PIPE customizing: POS Data Management POS Inbound Processing Integration with Other SAP Components CRM Integration settings
determine which fields are mapped in the operation. Different options are as follows:
Points from TLOG header level mapped to CRM
Amount from TLOG header level mapped to CRM
Points from TLOG line item level summed up mapped to CRM
Amount from TLOG line item level summed up mapped to CRM
B2B And A2A Related Information

SAP NetWeaver BW and SAP CRM are the back-end components that are involved. The corresponding inbound service of this operation resides in the SAP
CRM component.
Processing
LoyaltyMembershipActivityProfileCode determines if points are redeemed or awarded. The redeemed scenario is not supported for the communication
between SAP POS DM to SAP CRM (offline scenario). Therefore the value is always 13 (POS ACCURAL). In the offline scenario, the 'TypeCode' under
SalesDocumentReference is set to 903, which is related to POS transactions.
Asynchronous outbound operations only

POS Workbench (transaction /POSDW/MON0) can be used to send out the service interface.
Enhancements
The /POSDW/SE_LOYALTY_OUTBOUND Business Add-In (BAdI) is available for this operation under Enhancement Spot /POSDW/SPOT_SE_LOYALTY.
1.2 Carrying Out of Sales Audits
You can use this process to view, analyze, and adjust data and processing status of POS transactions in the POS Inbound Processing Engine. This includes
viewing of data transferred from the POS system, analysis and correction of errors, carrying out of checks, changing and recreation of transaction data, and also
possible adjustments to the processing status of tasks.
Process
You carry out sales audits in the PIPE in the POS Workbench and by way of automatic checks.
1.2.1 Use of the POS Workbench
In the POS Inbound Processing Engine (PIPE) the POS Workbench enables you to check the data and processing status of POS transactions and POS
aggregates.
The POS Workbench contains the following functions:
Selection and General Settings
Checking the Data Transfer
Control of Task Processing
Analyzing Errors and Messages
Display of Processing History and Follow-On Documents
Creating, Changing, or Deleting POS Transaction Data
Searching for POS Transactions
Mass Changes to POS Transactions
Display of Stores Without Communication
Carrying Out Ad Hoc Analyses
Displaying Processing Status of POS Aggregates
1.2.1.1 Display of Secure Data
This function enables you to define field selection profiles that can be used to influence the protection level of fields and structures in the POS Workbench. For
example, you can determine whether credit card data and cardholder names should be visible or not in the system.
Activities
See the Customizing steps in the IMG under POS Data Warehouse Management POS Inbound Processing General Settings Field Selection Profile
.
1.2.1.2 Selection and General Settings
When you enter the POS Workbench, you determine the criteria according to which the data is to be selected or displayed:
Limit the selection area:
In the General Settings area you can restrict your selection with respect to store and distribution chain.
You can select whether you wish to have POS transactions, POS aggregates, or both displayed. You flag or unflag the relevant checkbox in each case in
the appropriate area of the POS Workbench initial screen.
In addition, the following options are available to restrict the selection area for POS transactions:
Entry of a posting date
Consideration of the transaction status:
You can select the following statuses:
Tasks with errors exist
Tasks with warnings exist
Unprocessed tasks exist
All tasks have been processed successfully
Consideration of the business transaction:
You can include the following business transactions in the selection:
Sales movements
Goods movements
Totals records
Reversal transactions
Financial transactions
Control transactions
Undefined transactions
Restrictions on header data of transactions:
In the POS Workbench, you can select POS transactions using the data of the transaction header. This way you can restrict the selection of
transactions, for example, to specific POS numbers, transaction types, time intervals or cashiers.
For POS aggregates also, the following options are available to restrict the selection area:
Entry of a posting date
Consideration of the aggregate status:
You can select the following statuses:
Aggregation started
Aggregation completed
Outbound processing started
Outbound processing completed
Completed
Restrictions on aggregation level and aggregation task:
You may wish to consider only the aggregate data for specific aggregation levels or for specific aggregation tasks.
Definition of the layout of the navigation area and the folder hierarchy:
Using the title elements Folder Hierarchy for POS transactions and POS aggregates and Folder with respect to POS transactions, you can adjust the
appearance of the navigation area to suit your requirements.
You can define the main fields and additional fields of your folder hierarchy and their order, that is, their hierarchy level. The possible selections for the
main fields are posting date, store, and business transaction. The possible selections for the additional fields are time interval, cashier, POS number,
and department for POS transactions. As the time interval, you can select from seven default settings between ten minutes and twelve hours.
In the case of POS aggregates, you can only define the order for the first three of the seven hierarchy levels. The values here are restricted to store,
maximum posting date, and aggregation level.
You can decide if, and for which hierarchy level, the system is to display a heading. For the main fields of the POS transactions, you can flag a
checkbox to hide the corresponding tree level if it only appears once in the display.
Other settings:
There are further optional settings. These include, for example, the general display of the descriptions and the date format, or also the system behavior on
loading and refreshing the folder structure of the navigation area and the corresponding data.
1.2.1.3 Checking the Data Transfer
After you have transferred POS transactions from the POS system to the PIPE, you use this process to check if your data has arrived completely and correctly.
Process
1. You start the POS Workbench, define your settings, and restrict your selection area. Ensure that the view display is selected for POS transactions in the
workbench and then carry out the selection.
2. In the navigation area, you navigate along the folder hierarchy to the level of the individual POS transactions and display them in the overview. Now you can
see if the data you transferred is complete and error-free.
If you double-click and select a specific POS transaction from the overview, this takes you to the editor display which enables a detailed view of the POS
transaction. You have the facility to look at all segments of the transaction. If the master data of the transaction is incorrect, this is displayed by way of a
corresponding error message and a red status indicator. You should correct any errors you find in the editor so that you can process relevant tasks for the
POS transaction without errors.
For more information on master data checks, see Master Data Checks.
For more information on changing POS transactions, see Editing POS Transaction Data.
1.2.1.4 Control of Task Processing
You can use this process to check the status of task processing of POS transactions. You can start the processing of tasks for POS transactions manually. You
can cancel task processing and then run it again. You can change the status of task processing manually.
Prerequisites
The task you have scheduled for processing is relevant for the POS transaction. For more information, see the section on Task Processing. The status of task
processing for POS transactions can be seen independent of the relevance of the task.
Process
You start the POS Workbench, define your settings, and restrict your selection area. Ensure that the view display is selected for POS transactions in the
In the navigation area, you navigate along the folder hierarchy to the level of the individual POS transactions and display them in the overview.
1. Check status of task processing.
In addition to the actual POS transaction data in the overview, you can also find information on the task processing for each POS transaction that you can
use when checking the task status:
You can see if tasks are in status Ready. The system displays a gray status indicator.
You can see if tasks have been processed without errors. The system displays a green status indicator.
You can see if tasks have been processed with warnings. The system displays a yellow status indicator.
You can see if tasks have not been processed due to errors. The system displays a red status indicator.
The transaction status displays a summary of the task processing for the relevant POS transaction. It can be one of the following:
All Tasks Processed Without Errors, if all relevant tasks have been processed and no warnings or errors have occurred.
Unprocessed Tasks Exist, if at least one relevant task has not yet been processed and no warnings or errors have occurred for all tasks that
have been processed.
Tasks with Warnings Exist, if at least one task exists with a warning but no other task has been processed with errors.
Tasks with Errors Exist, if at least one task has been completed with errors.
The status of the task processing is reflected also in the folder hierarchy in the navigation area for the relevant area.
To see detailed information on the status of each task of a POS transaction, you highlight the POS transaction and choose the pushbutton Task Status:
Overview . This brings an overview of the tasks assigned to the POS transaction. You can see if a task is relevant for the POS transaction and if it can be
processed or not. In addition, the system shows whether processing of a task can be started manually. For more information, see Task Processing.
The status of each task is displayed. The following table provides an overview of the possible statuses of tasks.
Task Status Meaning
Ready The task is ready to be executed. This is the initial status for new POS transactions.
Error The task cannot be executed due to an error.
Completed with warning The task was executed successfully but warning messages were issued.
Completed The task was completed successfully.
Ready to be canceled The task is to be canceled.
Error during cancellation An error occurred when canceling the task.
Canceled with warning The task was canceled successfully but warning messages were issued.
Canceled The task was canceled successfully.
Rejected The task was not completed and will not be processed further.
You can change the task status manually by choosing the relevant pushbutton or you can decide to cancel or process a task based on its current status.
2. Carry out task processing manually.
Within the POS Workbench, you have the facility to manually change the task processing for POS transactions. To do this, you select one or more POS
transactions in the transaction overview and choose the pushbutton Process Tasks Online . A dialog box appears in which you can define the details for
task processing. You can now process either one specific task or all tasks for the selected POS transaction(s). Only those tasks that have been assigned
in Customizing are offered for selection. For more information, see Task Processing.
Since the assigned tasks result from Customizing at the time of generation of a transaction, you must, if you have changed the Customizing in the meantime,
flag the checkbox Take Account of Customizing Changes , if you wish to take note of the changes.
As an additional option, you can choose whether to process tasks that have been completed with errors. You do not have to manually set the tasks to
Ready first, you can carry out processing again immediately.
As soon as you have carried out the task processing, a further dialog box appears providing you with a processing protocol. The system shows whether the
processing has been carried out, in some cases with warnings, or if it could not be completed due to errors. The system shows the error messages that
have occurred in the processing protocol. The processed task then receives a status corresponding to the result.
3. Cancel task processing
You can cancel a task that has already been processed. This operation is useful if you wish to reset the processing of a task in order to carry it out again
under different conditions.
To do this, you first set the status of the task to be canceled for the relevant POS transaction(s) to Ready to be Canceled . Then you can carry out
processing of the task again as described in the previous section and the system carries out the cancellation. Manual conversion of the task status is
described in the following section. After you have canceled the task, you must reset the status to Ready in order to be able to process it again.
Note
You can enable Task Cancelation Tracking so that task with a status Canceled or Canceled with Warning will be tracked in transaction records.
When a task is canceled for a transaction, the TASK_CANCELED field in the TLOGF table will be set to X for each row associated with that transaction.
You can enable Task Cancelation Tracking in Tasks One-Step Processing Define Tasks in the Customizing.
Also note, that following a transaction reversal, performed using task 0040 Perform Transaction Reversal in the standard SAP POS DM profile, tasks
are only cancelled if they have been assigned to task group 0009 Tasks Relevant for Transaction Reversal in the standard profile.
4. Manual change of the task status and related status transitions

In the POS Workbench, you can manually change the status of tasks for POS transactions. You highlight a POS transaction for this and choose the
pushbutton Task Status - Overview . In the following dialog box, you choose the pushbutton Task Status – Change for whatever tasks you wish.
Depending on the current status of task processing and the intended further processing, you can now select a new status.
Below, the different statuses and status transitions in task processing are clarified - from the beginning to the end of task processing of a new transaction.
Before they are processed, the tasks have status Ready .
There are various ways of ending a process for a task:
You can reject processing of the task immediately. The task receives the status Rejected .
An error occurred during the first processing of the task. The task receives the status Error .
You now have two options:
You reject processing of the task. The task receives the status Rejected .
You correct the error. You assign the task status Ready and restart processing.
No errors occurred during the first processing of the task. If no warnings are issued during processing of the task, the task receives status
Completed .
If, however, warnings are issued during processing of the task, the task receives status Completed with Warning .
You ignore the warning and set the status of the task to Completed .
Due to the warning, you wish to cancel processing of the task. You flag the task for cancellation. The task receives the status Ready to be
Canceled .
You can also cancel a task that has status Completed . You flag the task for cancellation. The task receives the status Ready to be Canceled .
If an error occurs during cancellation of a task, the task receives the status Error During Cancellation .
You remove the cause of the error and reset the status to Ready to be Canceled .
You stop the cancellation and set the status to Completed .
If a warning is issued during cancellation of a task, the task receives the status Canceled with Warning .
In this case, you have two options:
You ignore the warning and set the status to Canceled .
You schedule the task for further processing and set the status to Ready .
If no warnings are issued during cancellation of a task, the task receives the status Canceled .
You can flag tasks with status Canceled and Canceled with Warning for repeat processing.
The following graphic shows the relationships between the different task status values and the permitted status transitions:
Task Status
The following table provides an overview of the meaning of the status transitions.
Status Transition Meaning
Process The task is processed in a processing run. It is either executed or canceled.
Reject The processing of the task is rejected. This can occur as a result of action taken by
the user or as a result of the occurrence of specific conditions during the
processing run.
Execute This transition is used when a task is no longer to be carried out, for example, in
the case of duplicate POS transactions or with incorrect data.
Ignore warning The task is to be executed. The user triggers this change.
Cancel Warnings should be ignored. This is triggered by the user. This means that the
user can convert a status with warning to a status without warning thus removing
the POS transaction from the worklist.
Stop cancel A task that has been executed is to be canceled. The user triggers this change.
1.2.1.5 Analyzing Errors and Messages
You want to check which warnings or errors have occurred during the processing of tasks for POS transactions so that you can fix them, and also to check which
tasks could be performed successfully.
Prerequisites
You have already performed the processing of tasks.
Process
In the navigation area, you can see from the task status from the status indicator:
Tasks with errors: red status indicator
Tasks with warnings: yellow status indicator
Tasks incomplete: grey status indicator
POS transactions were processed correctly: green status indicator
Highlight one or more POS transactions, whose warnings or errors you would like to analyze. Also select Warnings .
Instead of showing you the POS transaction overview, the system shows you a list of the notifications that have occurred regarding the POS transaction that was
selected earlier. You see all the available details for individual messages; you can also view these in their own dialog box by clicking Details . You can sort the
messages according to your own needs.
If errors occur during processing, then you must fix these, for example, in the POS Workbench editor.
You can return to the POS transaction overview by choosing Overview .
1.2.1.6 Display of Processing History and Follow-On Documents
You can use this process to check what type of processing has been carried out for specific POS transactions.
Process
Select one or more POS transactions whose processing history you wish to display, and choose the pushbutton Document Flow . Instead of the overview of the
POS transactions, the system now displays the process flow of the processing that has occurred up to this point including the generated follow-up documents
such as IDocs.
You can see what kind of processing has taken place at what time for which transactions. You can display the task processing starting with the entry of the POS
transaction into the PIPE right up until the output of transaction data using IDocs or you can display it in the reverse order.
You can return to the POS transaction overview by choosing the pushbutton Overview .
1.2.1.7 Editing POS Transaction Data
In this process you use the POS Workbench to create new POS transactions. You copy existing transactions. You can change existing POS transactions in the
POS Workbench editor.
Process
Here you can create new, change, or copy individual POS transactions.
1. Create New POS Transaction
To create new POS transactions, in the navigation area highlight any folder for the validity of which you would like to create a new POS transaction. In the
context menu choose New POS Transaction . The system provides a dialog box to create POS transactions. You can add to or change the transaction data
as necessary.
If you would like to create multiple POS transactions, choose New POS Transaction in the dialog box. The previous POS transaction data is copied into
the corresponding list in the dialog box as the POS transaction that is to be created and you can enter transaction data of other POS transactions to the
corresponding fields of the dialog box.
You can delete or copy POS transactions that are already in the dialog box list of POS transactions that are to be created.
As soon as you choose Save POS Transactions , the system creates all those POS transactions that are shown in the dialog box.
Note
Note, that only the header information of the POS transaction is created and that you must enter additional details using the POS Workbench editor.
2. Copy Existing POS Transaction

To copy existing POS transactions, highlight one or more POS transactions in the POS Workbench overview and choose Copy POS Transaction . As a
result, the system creates the new POS transactions only in the overview at first and displays these with the corresponding transaction status. You also
have the opportunity to change the POS transactions using the POS Workbench editor before you create them in the system with Save . Use the editor just
as described in the following section for existing transactions.
3. Change Existing POS Transaction
To change existing POS transactions, highlight one or more POS transactions in the POS Workbench overview and choose Editor . Alternatively, you can
select the POS transaction directly with a double-click. In both cases, the POS Workbench editor starts.
In the navigation area the system shows you the segments of the selected POS transaction. Highlight a heading that belongs to one of more segments in the
navigation area and the data of all the relevant segments is displayed in the overview. If you choose a specific segment, the system shows you the data of
this segment in the editor view. Alternatively, you can also highlight a POS transaction in the overview and then click Individual Segment .
In the change mode of the editor view you have the following options:
By choosing Copy Entries , you can change the input-ready fields of the chosen segment and accept the changes that have been made.
By choosing Reject Changes you can undo changes that have previously been made and revert to the last version. This is possible, so long as you
have not activated the changes using Accept Changes .
By clicking Save you can save in the system the changes that have already been accepted for the segment currently shown.
The system automatically performs master data checks after data has been entered. If you have entered incorrect data, this will be displayed in an error
message. For more information, see Automatic Checks.
You can only edit POS transactions so long as you have not successfully performed any associated tasks with them. As long as this is the case, you cannot
make any further changes to the transaction data to avoid inconsistencies in the system and follow-on systems. If, however, you would still like to make changes to
a POS transaction, then you must first cancel the processed tasks. Only then is it possible again to make changes to the transaction data.
After you have performed all the changes regarding your POS transaction segments, leave the editor using Back and you return to the transaction view of the
POS Workbench.
1.2.1.8 Searching for POS Transactions
With this function you can search for pre-defined character strings within the fields of specific segments of a POS transaction.
Activities
You can search for POS transaction data in the following ways:
You search in a number of POS transactions which the system displays to you after navigation in the navigation area in the folder hierarchy until the level of
your choice in the overview.
Choose Search in the POS transactions overview.
You search in either one specific or all folders in the navigation area.
When searching in a specific folder, you can also choose the folder of a store or posting date. Select the folder of your choice and choose Search in the
navigation area. From the list displayed, choose whether you want to search in the selected folder or all folders in the navigation area.
In both cases, the system displays a dialog box for the search. You enter the character string that you want to search for and specify the maximum number of
hits. You have the following options:
You can perform the search on all segments and all fields of POS transactions.
You can restrict the search to a specific segment and take all segment fields into account.
You can perform the search in a specific field.
If you want to restrict the search to a specific field, you can reduce the fields offered by the system in the dropdown list by restricting it to a specific POS
transaction segment. This results in the choice of one single field.
You can specify whether it is relevant to your search if it is case-sensitive or not. By selecting the relevant checkbox the system performs case-sensitive
searches for specific character strings.
If you would like to take the 5 words Deleted intra-system format into account for the search then select the Internal Display checkbox.
Once you have set your settings, you can start the search by pressing return. The result is displayed in a dialog box. The system lists all the relevant
transactions including unique transaction index and field where the character string was found and sorts them into a tree structure according to store and posting
date. If the search is unsuccessful, the system displays the corresponding message.
1.2.1.9 Mass Changes to POS Transactions
Use this to make mass changes to existing POS transactions.
Activities
The mass change consists of a search and subsequent replacement of data.
You have the following options for performing mass changes to POS transactions:
You search for and replace data in a number of POS transactions which the system displays to you after navigation in the navigation area in the folder
hierarchy until the level of your choice in the overview.
Choose Mass Changes (POS Data) in the POS transactions overview.
You search for and replace data in a number of POS transactions that are distributed across a specific folder, or all folders, in the navigation area.
You can choose a specific folder or the folder of a store or posting date for the mass change. Highlight the folder of your choice and choose Mass Changes
(POS Data) in the navigation area. From the list displayed, choose whether you want to perform the mass changes on the highlighted folder or all folders in
the navigation area.
In both cases, the system displays a dialog box for the mass change. First specify the character string that you want to search for, then specify the character
string with which you would like to replace the first. Enter the maximum number of hits or the maximum number of search results in the tree display.
You have the following options for the mass change:
You perform the mass change on all segments and all fields of the POS transaction.
You restrict the search to a specific POS transaction segment and take all fields into consideration.
You only perform the mass change on a specific field.
If you want to restrict the mass change to a specific field, you can reduce the fields offered by the system in the dropdown list by restricting it to a specific POS
transaction segment. This results in the choice of one single field.
You can specify whether it is relevant if searches are case-sensitive or not. By selecting the relevant checkbox the system performs case-sensitive searches for
specific character strings.
If you would like to take into account the intra-system format for the search and the corresponding syntax, then select the Internal Display checkbox.
Once you have set your settings, you can start the mass change search by pressing return. The result is displayed in a dialog box. The system lists all the
relevant transactions including unique transaction index and field where the character string was found and sorts them into a tree structure according to store and
posting date. If the search is unsuccessful, the system displays the corresponding message.
You can select or deselect the entries found by pressing the corresponding button. It is not possible to select single entries. Once you have selected the POS
transactions, you can end the mass change by choosing Replace and Save .
1.2.1.10 Display of Stores Without Communication
This function enables you to display in the POS Workbench additional stores, or exclusively those stores, which do not have any POS transactions matching your
defined selection criteria, and which therefore, do not have any communication between POS and PIPE.
Activities
workbench. Switch to the view Folder and make the setting for stores without communication.
You have the following selection options:
Do not Display Stores Without Communication
Also Display Stores Without Communication
Only Display Stores Without Communication
Run the selection. Depending on the setting, the system displays in the navigation area only stores without communication, only the data on stores with
communication, or both.
1.2.1.11 Carrying Out Ad Hoc Analyses
This function enables you to analyze the data of the POS transactions that have been transferred from the POS system to the PIPE.
Activities
In the navigation area, the system displays the relevant folder structure for your selection. You can see for which stores, posting dates, and business transactions,
POS transactions exist in the PIPE. For each folder, and therefore for each hierarchy level, the system displays the number of POS transactions and the
corresponding total sales. If required, you can also have this data displayed in combinations by cashier, POS number, department, or 10 minute intervals.
1.2.1.12 Monitoring of POS Aggregates
In this process, you monitor the data and processing status of POS aggregates.
Prerequisites
You have used aggregation tasks and generated aggregates for further processing in the system.
Process
You start the POS Workbench, define your settings, and restrict your selection area. Ensure that the view display is selected for POS aggregates in the
Navigate along the folder hierarchy to the appropriate level and have a look at the number of aggregates and their processing status in the overview. The system
provides the following information:
You can see how many POS aggregates are unprocessed or completed and how many were processed with warnings or could not be processed due to
errors.
You can see how many packages, into which aggregates are split for processing, are unprocessed or completed and how many were processed with errors
or could not be processed due to errors.
The system displays the total status of all aggregates of a hierarchy level using an appropriately colored status indicator.
If you wish to process existing POS aggregates based on the given information, you start the outbound processing using the Outbound Dispatcher of the PIPE.
For more information, see Outbound Processing of Aggregates .
1.2.2 Automatic Checks
This function enables you to carry out automatic checks for POS transaction data. You carry out part of these checks in order to guarantee the consistency and
completeness of your POS transaction data.
The following two options are available:
You check POS transaction data using Master Data Checks.
You check POS transaction data and its processing status using Rules that you define and you can then react to the results.
Recommendation
The master data checks are also used for data enrichment in the processing of standard tasks. For this reason, you should always carry out automatic
master data checks.
Prerequisites
You must make relevant Customizing settings for the PIPE so that the system processes the appropriate checks.
Activities
The system automatically carries out the checks you have determined at the appropriate times.
1.2.2.1 Master Data Checks
You can use this function to check the master data of POS transactions. You can choose between two different models for performing master data checks:
Classic master data check
Master data check that uses check profiles. Check profiles can be defined for:
Inbound processing and to be used by the POS Workbench
Data status determination
Task processing
The classic and the profile-based master data check models do not differ in results, but the profile-based model does offer more flexibility.
Prerequisites
You have configured the SAP POS DM Customizing to perform master data checks as follows:
To perform a classic master data check, you have entered the Master Data Filter value in the Define General Settings Customizing activity and have
ensured that the Checks Using Check Profile checkbox is not selected.
To perform checks using check profiles, ensure that:
You have selected the Checks Using Check Profile checkbox in the Define General Settings Customizing activity.
For master data checking during the inbound processing and POS Workbench:
You have specified a check profile in the Master Data Checks in Dialog section of the Define Profiles Customizing activity. This check profile
is used to verify the master data included in transactions during the inbound processing.
You have specified a check profile in the Master Data Check for Data Status Determination section of the Define Profiles Customizing
activity. This optional check profile is used to verify the master data included in transactions for the purposes of determining the transaction data
status.
For master data checking during the task processing:
You have specified a check profile for individual tasks by settings the check profile in either the Tasks One-Step Processing Define
Tasks or in the Tasks Two-Step Processing Defined Aggregation Task Customizing activity. You can specify a master data
check profile for the tasks that is different from the master data check profile used for the inbound processing or by the POS Workbench.
Recommendation
Since SAP POS DM uses the automatic checks to enhance the transaction data, SAP recommends that you generally activate and
process master data checks when you are processing standard tasks for POS transactions.
You can use the SAP standard check profile, or you can create one or more of your own using the Define Check Profiles Customizing activity.
Note
If you enable the use of check profiles and do not enter a valid check profile value for inbound or task processing, then no check and, furthermore, no data
enhancement takes place. This can lead to errors with task processing, for example. Also, when you are using master data check profiles, SAP POS DM
does not consider the Master Data Filter value set in the Define General Settings Customizing activity.
Features
The system automatically carries out the checks you have determined at the appropriate times. They are processed in the following situations:
During the inbound processing of POS transactions
When the editor is started for a particular POS transaction within the POS Workbench
When tasks are processed
The system checks for POS transaction data and automatically enhances them with further data.
If there is no transactional data in the system and the master data check is therefore unsuccessful, then a corresponding error message is displayed. No further
processing of the relevant POS transaction occurs within the task processing.
For an incorrect or missing material number you can set either an error material or standard material as default in the PIPE customizing in the Standard Values
area.
If all checks and data enhancements are successful, then the system can continue the functions, under the guidelines of which the checks were performed,
without restrictions.
1.2.2.2 Rules
Using this function, you can check transaction data when processing tasks using predefined rules and then carry out a specific activity depending on the result.
You use rules in cases where you only wish to process tasks if certain conditions are fulfilled.
Prerequisites
Define the available rules in PIPE Customizing in the area POS Data Management POS Inbound Processing Tasks Define Rules and assign to
each task the rule that the system is to use for checking during task processing.
For more information, see Task Processing Rules.
Features
In task processing, the system automatically carries out any rules you have defined for a task.
For more information, see Task Processing Rules.
1.2.3 Short/Over Balancing
Short/Over Balancing is the process of determining the difference between the (counted) tender amount in a Totals Record POS transaction and the expected
tender amount.
Short/Over Balancing contains the following functions:
Determining Short/Over Differences
Checking the Short/Over Status
Verifying/Manually Processing Short/Over Differences
Sending Short/Over Differences Using IDoc WPUFIB
1.2.3.1 Determining Short/Over Differences
In this process the short/over differences are calculated according to one of three methods indicated in the Short/Over Balancing Customizing:
1. Copy expected amount and short/over amount from Totals Records POS transactions.
2. Copy expected amount from Totals Records POS transactions and calculate short/over amount
3. Calculate expected amount and short/over amount from related sales and financial POS transactions
The short/over and the expected amounts are calculated as follows:
Calculation Description
Short/Over Amount = Actual Amount - Expected Amount Actual Amount refers to the amount of tenders physically counted at the register.
Expected Amount = Tender Amount + Pay-In Amount - Pay-Out Amount Pay-In Amount refers to the amount added to the till.
Pay-Out Amount refers to the amount removed from the till.
For methods 1 and 2 listed above, Pay-Out Amount = Removal Amount + Bank
Amount, where Removal Amount refers to the amount removed from the till and
Bank Amount refers to the amount transferred to the bank.
For method 3, Tender Amount is calculated from the POS transactions associated to
the Totals transaction. Pay-In and Pay-Out amounts are calculated from the Financial
transactions associated to the Totals transaction.
Prerequisites
You have made the following settings in POS Data Management Customizing:
You have set the type of the task to be carried out under Tasks One-Step Processing Define Tasks depending on the requirements for either
Under POS Transactions , you have verified that an appropriate task group is assigned to the relevant transaction types.
You have activated and customized the short/over parameters under Short/Over Balancing .
Process
The task 0060 Calculation for Short/Over Balancing is available in the standard system for determining the short/over differences.
You can carry out task processing with the PIPE Dispatcher (transaction /POSDW/PDIS). For more information, see Using the PIPE Dispatcher.
1.2.3.2 Checking the Short/Over Status
In this process, you use the POS Workbench to verify the determined short/over differences for a certain store on a certain posting date. You can also check the
warnings or errors that have occurred during the short/over balancing.
Prerequisites
You have already determined the short/over differences. For more information, see Determining Short/Over Differences.
Process
You start the POS Workbench, define your settings, and restrict your selection area. Ensure that the Totals records business transactions are included in the
selection. In the navigation area, you can see in the Short/Over status column the corresponding status of a certain store on a certain posting date. The status
can be one of four colors:
Red: indicates an out-of-tolerance short/over difference
Yellow: indicates missing short/over customizing
Grey: indicates that short/over differences are not determined yet
Green: indicates a tolerated short/over difference
In the navigation area, you navigate along the folder hierarchy to the level of the individual Totals Records POS transactions and display them in the Overview
tab. You can click on the Short/Over button in the toolbar to open the Short/Over tab. You can see here the details of the short/over differences for the selected
store and posting date, grouped by Workstation/Operator , tender type and currency.
1.2.3.3 Verifying/Manually Processing Short/Over Differences
After checking the short/over status, verify and possibly adjust the Totals Records POS transactions and the related Sales/Financial POS transactions. After any
change to the tender amounts in any of these transactions, you may want to determine the short/over differences again, and possibly manually send them over to
a financial system (for example, SAP ERP FI).
Prerequisites
Process
You start the POS Workbench, define your settings, and restrict your selection area. Ensure that the view display is selected for POS transactions in the POS
Workbench and the Totals records business transactions are included, and then carry out the selection. In the navigation area, you navigate along the folder
hierarchy to the level of the individual Totals Records transactions and display the Short/Over tab by clicking on the Short/Over button.
You can drill down and double-click on a specific Totals Records POS transaction from the short/over tree. This takes you to the editor display which enables a
detailed view of the POS transaction. You can also display and modify the segments of the transaction. Furthermore, you can browse the related Sales and
Financial POS transactions and make any required adjustments.
The start and end of transaction timestamp of a Totals Records transaction will determine the interval in which the Sales and Financial transactions belong. For
example, if:
the calculation method was set to Calculate Expected Amount and Short/Over amount from related sales and financial POS transactions, and
a Totals Records transaction has 04.11.2012 09:00:00 and 04.11.2012 17:00:00 for the start and end timestamps
then all Sales and Financial transactions having a start of transaction timestamp between 9:00 and 17:00 on 04.11.2012 will be taken into consideration when
determining the short/over differences.
After making modifications, you come back to the Short/Over tab and click on the Recalculate Short/Overs button, which can trigger changes in the
Short/Over status column. To conclude the process, send the newly determined short/over differences to ERP by clicking the button Send Short/Overs to ERP .
For more information on changing POS transactions, see Editing POS Transaction Data.
1.2.3.4 Sending Short/Over Differences Using IDoc WPUFIB
In this process you can send short/over differences related to POS transactions to SAP ERP FI. You can use the IDoc WPUFIB to transfer the following POS
transaction data:
Header data:
Store
Posting date
Financial movement type
Item data:
Short/over difference amount
Currency
Prerequisites
You have made the following settings in POS Data Management Customizing:
Under POS Transactions , you have verified that an appropriate task group is assigned to the relevant transaction types.
You have activated and customized the over/short processing parameters under Short/Over Balancing .
You have maintained financial transaction types SAP ERP FI under SAP Customizing Implementation Guide Sales and Distribution POS Interface
Inbound Transaction Types For Financial Transactions . For successful processing of short/over differences sent to SAP ERP FI, financial transaction
types defined in SAP POS DM must have corresponding definitions in SAP ERP FI.
Process
The task 0061 Send Short/Overs to ERP is available in the standard system for sending the short/over differences to SAP ERP FI using the IDoc WPUFIB. You
carry out processing of the task for the relevant POS transactions depending on the task type. For more information, see Task Processing.
You can carry out task processing with the PIPE Dispatcher (transaction /POSDW/PDIS). For more information, see Using the PIPE Dispatcher.
1.3 Analytics
1.3.1 POS Analytics
The POS Inbound Processing Engine provides transactional data to the following POS Analytics DataSources:
POS Analytics: Retail Control
POS Analytics: Transaction Totals
POS Analytics: Financial Movement
POS Analytics: Goods Movement
POS Data: Receipt Data from the PIPE
POS Data: Cashiers from the PIPE
POS Analytics: Loyalty Program
For more information on transactional data supplied by the POS Inbound Processing Engine to POS Analytics, see https://help.sap.com/bicontent
Application help BI Content Industry Solutions Trading Industries Retail Trade Store Analytics POS Analytics .
1.3.2 Trade Foundation Analytics
The POS Inbound Processing Engine provides transactional data to the following Trade Foundation DataSources:
POS Analytics: Retail Control
POS Analytics: Sales and Test Transaction - Direct Access
For more information on transactional data supplied by the POS Inbound Processing Engine to Trade Foundation analytics, see https://help.sap.com/bicontent
Application help BI Content Industry Solutions Trading Industries Trade Foundation .
1.3.3 POS In-Memory Analytics Content
The POS In-Memory Analytics content is only available to customers who install SAP POS DM on SAP NetWeaver BW powered by SAP HANA. It allows you to
query uncompressed, real-time POS transaction data stored in the SAP HANA database (TLOGF table).
The POS In-Memory Analytics content consist of: internal BI Content and SAP HANA Business Content.
Internal BI Content
The internal BI Content is included in the SAP POS DM installation on SAP NetWeaver BW powered by SAP HANA. The internal BI Content included with SAP
POS DM can:
be used as is, if you have evaluated it and it fits your business needs
be adapted so that you can work with it to any degree of detail
serve as a template or as an example for customer-defined BI Content
The internal BI Content included with SAP POS DM is configured with the following assumptions:
Voided transactions and line items are excluded from analysis
Return amounts are inverted in the transaction records
Training transactions are excluded from analysis
Caution
The standard configuration can significantly impact the result of your analysis; ensure that the standard configuration meets your business needs.
Furthermore, the internal BI Content included with SAP POS DM allows you to:
Include or exclude canceled transactions from your analysis, provided that you set the Task Cancellation Tracking option under Tasks One-Step
Processing Define Tasks in Customizing.
Filter out transactions based on their data status, provided that you set the Data Status Relevant option under Tasks One-Step Processing Define
Tasks in Customizing. See Determining Transaction Data Status for more information.
SAP HANA Business Content

You can install and deploy the SAP HANA Business Content as described in SAP Note 1720277.
Implementation Considerations
The following SAP POS DM BAdIs and tasks can be used to accelerate the calculations performed by the POS In-Memory Analytics content:
BAdI (Active in the Inbound Processing by Default) Task Effect
POS Transaction Aggregation on Header Level 8001 Aggregate Transaction Data for Analytics A number of TLOGF table fields are pre-populated
POS Transaction Aggregation on Header Level prior to performing the analysis.
POS Transaction Aggregation on Tender Level
POS Transaction Data Distribution to Item Level 8002 Supply Analytics Cont. with Distributed Transaction The discount, tax, and tender information contained on the
Data header level of a POS transaction is distributed to the
individual transaction line items.
Note
Only included taxes are considered during the
distribution; Tax Types set to excluded using the
Tax Included checkbox in the Define Tax Types
Customizing activity are not distributed.
POS Transaction Inbound Data Status Processing 8003 Determine Transaction Data Status A data status is maintained for transactions stored in the
Enablement TLOGF table. The data status value can be used to evaluate
the integrity of the transactional data prior to analysis.
1.3.3.1 Roles
The customer must maintain the necessary/allowed authorization values as required for the delivered content. SAP NetWeaver BW Authorization Dimension
functionality should be used. This authorization can the be used when creating roles in the Role Maintenance transaction. For more information, see
http://help.sap.com/saphelp_erp60_sp/helpdata/en/b1/0c9441b8972e7be10000000a1550b0/frameset.htm.
1.3.3.2 Analytic Views
Analytic View:sap.is.retail.posdm.AN_COUNT
Used to calculate the number of transactions and retail line items.
Prerequisites
SAP POS DM installed on SAP NetWeaver BW powered by SAP HANA and SAP HANA Business Content installed as described in SAP Note 1720277.
Data Modeling
Tables Involved
Table Description
/POSDW/TLOGF SAP POS DM POS transaction log table
Definition for Output Table
Table Field Name Attribute(A), Measure(M) Description Description Mapping Hidden
/POSDW/TLOGF TRANSINDEX A Transaction Index No
/POSDW/TLOGF BUSINESSDAYDATE A Posting Date No
/POSDW/TLOGF RETAILSTOREID A Store No
/POSDW/TLOGF BEGINTIME A Time on which POS No

Transactions starts
/POSDW/TLOGF BEGINDATE A Date on which POS No
Transactions Starts
/POSDW/TLOGF MERCHANDISECAT A Material group No
/POSDW/TLOGF TRANSTYPECODE A Transaction Type No
/POSDW/TLOGF RETAILTYPECODE A Sales Item Type No
/POSDW/TLOGF ITEMID A Article Identifier No
/POSDW/TLOGF CALWEEK A Calendar Week No
/POSDW/TLOGF CALMONTH A Calendar Month No
/POSDW/TLOGF CALYEAR A Calendar Year No
/POSDW/TLOGF CALHOUR A Calendar hour No
/POSDW/TLOGF CALDAY A Calendar day No
/POSDW/TLOGF RETAILREASONCODE A Retail Reason Code No
/POSDW/TLOGF DATASTATUS A Data Status No
/POSDW/TLOGF BUSINESSTYPE A Business Transaction Type No
/POSDW/TLOGF TRANSDEBITFLAG A Debit/Credit Indicator No
/POSDW/TLOGF RETL_ITEM_CAT A Classification of Sales Item: No

Category
/POSDW/TLOGF RETL_ITEM_SCAT A Classification of POS No

Segments: Subcategory
/POSDW/TLOGF RETAILDEBITFLAG A Debit/Credit Indicator No
/POSDW/TLOGF TASK_CANCELED A Transaction Cancelled via No

Task
/POSDW/TLOGF ITEMIDQUALIFIER A Qualifier for Article Identifier No
/POSDW/TLOGF MATERIALNUMBER A Material Number No
/POSDW/TLOGF SALESUOM A Sales Unit No
/POSDW/TLOGF BASEUOM A Base Unit of Measure No
/POSDW/TLOGF RETAILQUANTITY M Quantity in Sales Unit No
/POSDW/TLOGF BASEQUANTITY M Quantity in Base Unit of No

Measure
Calculated Attributes
ID Description Formula Hidden
ALL_KEY Retailstoreid, Businessdaydate, "RETAILSTOREID"+string("BUSINESSD No

Transindex AYDATE")+string("TRANSINDEX")
Analytic View: sap.is.retail.posdm.AN_SALES_COUNT
Used to calculate average net sales per transaction.
Prerequisites
Data Modeling
Tables Involved
Table Description
/POSDW/TLOGF ROWKEY A Row Key No
/POSDW/TLOGF BUSINESSDAYDATE A Posting Date No
/POSDW/TLOGF TRANSCURRENCY A Transaction Currency No
/POSDW/TLOGF TRANSTYPECODE A Transaction Type No
/POSDW/TLOGF BEGINTIME A Time at Which POS No

Transaction Starts
/POSDW/TLOGF BEGINDATE A Date on Which POS No

Transaction Starts
/POSDW/TLOGF MERCHANDISECAT A Material Group No
/POSDW/TLOGF CALHOUR A Calendar Hour No
/POSDW/TLOGF CALDAY A Calendar Day No

Category

/POSDW/TLOGF TASK_CANCELED A Transaction Canceled via No

Task
/POSDW/TLOGF TAXINC M Tax Included No
/POSDW/TLOGF SALESAMOUNT M Sales Amount No
/POSDW/TLOGF ITEMDISC M Item Discount No
/POSDW/TLOGF DISTDISC M Distributed Discount No
/POSDW/TLOGF DISTTAX M Distributed Header Tax No
ALL_KEY Retailstoreid, Businessdaydate, "RETAILSTOREID" No

Transindex +string("BUSINESSDAYDATE")
+string("TRANSINDEX")
1.3.3.6.1 Sales
Analytic View: sap.is.retail.posdm.AN_SALES
Used to calculate gross sales, net sales and discounts.
Prerequisites
Data Modeling
Tables Involved
Table Description
/POSDW/TLOGF ROWKEY A Row key No
/POSDW/TLOGF BUSINESSDAYDATE A Business Day Date No
/POSDW/TLOGF TRANSTYPECODE A Transaction Type Code No
/POSDW/TLOGF BEGINTIME A Begin Time No
/POSDW/TLOGF BEGINDATE A Begin Date No
/POSDW/TLOGF MERCHANDISECAT A Material Group No
/POSDW/TLOGF PROMOTIONID A Promotion ID No
/POSDW/TLOGF CALHOUR A Calendar Hour No
/POSDW/TLOGF CALDAY A Calendar Day No

Category

/POSDW/TLOGF TASK_CANCELED A Transaction Canceled via No

Task
/POSDW/TLOGF DISTDISC M Distributed Discount No
/POSDW/TLOGF DISTTAX M Distributed Header Tax No
Analytic View: sap.is.retail.posdm.AN_MARKDOWN_SALES

Used to calculate net sales for all markdown sales.
Prerequisites
Data Modeling
Tables Involved
Table Description

/POSDW/TLOGF ROWKEY A Row key No
/POSDW/TLOGF TRANSINDEX A Transaction index No
/POSDW/TLOGF BUSINESSDAYDATE A Posting date No
/POSDW/TLOGF TRANSTYPECODE A Transaction type code No
/POSDW/TLOGF BEGINTIME A Time at which POS No

Transaction starts
/POSDW/TLOGF BEGINDATE A Date at which POS No
transaction starts
/POSDW/TLOGF MERCHANDISECAT A Material group No
/POSDW/TLOGF PROMOTIONID A Promotion ID No
/POSDW/TLOGF CALWEEK A Calender Week No
/POSDW/TLOGF CALHOUR A Calender Hour No
/POSDW/TLOGF CALDAY A Calender Day No
/POSDW/TLOGF CALMONTH A Calender Month No
/POSDW/TLOGF CALYEAR A Calender Year No
/POSDW/TLOGF DISTDISC M Distributed discount No
/POSDW/TLOGF DISTTAX M Distributed taxes No
MARKDOWN_SALES Markdown Sales Transactions Flag if( "DISTDISC" > 0 or "ITEMDISC" > 0 or No
strlen("PROMOTIONID") > 0, 0, 1)
1.3.3.3 Key Figures
1.3.3.3.1 Counter
Key Figure: 0RPM_COUNT
This key figure is used to count the number of transactions.
Technical Data
Available as of Release SAP POS DM 1.0 SP01
Aggregation Summation
Exception Aggregation Summation
Calculation No
Restriction No
1.3.3.3.2 Discount Value

Key Figure: 0RPM_REA
This key figure represents the discount amount.
Technical Data
Calculation No
Restriction No
Data Modeling
Has unit
Object Type Name Technical Name
InfoObject Document currency 0DOC_CURRCY
1.3.3.3.3 Distributed Discount

Key Figure: 0RPM_DID
This key figure represents the distributed discount amount.
Technical Data
Calculation No
Restriction No
Data Modeling
Has unit
1.3.3.3.4 Distributed Included Transaction Tax

Key Figure: 0RPM_DITXI
This key figure is used to represent the distribution of all included transaction taxes.
Technical Data
Calculation No
Restriction No
Data Modeling
Has unit
1.3.3.3.5 Normal Sales Value

Key Figure: 0RPM_NSA
This key figure represents the normal sales amount.
Technical Data
Calculation No
Restriction No
Data Modeling
Has unit
1.3.3.3.6 Tax Included

Key Figure: 0RPM_TXI
This key figure represents the amount of included taxes.
Technical Data
Calculation No
Restriction No
Data Modeling
Has unit
1.3.3.4 Characteristics
1.3.3.4.1 Business Transaction

Characteristic: 0RPM_BTY
This characteristic represents the business transaction.
Technical Data
External Hierarchy Not available
1.3.3.4.2 Calendar Day

Characteristic: 0RPM_DAY
This characteristic is used for the drill down on a daily basis for different queries.
Technical Data
1.3.3.4.3 Calendar Month

Characteristic: 0RPM_MTH
This characteristic is used for the drill down on a monthly basis for different queries.
Technical Data
1.3.3.4.4 Calendar Week

Characteristic: 0RPM_WEK
This characteristic is used for the drill down on a weekly basis for different queries.
Technical Data
1.3.3.4.5 Calendar Year

Characteristic: 0RPM_YER
This characteristic is used for the drill down on a yearly basis for different queries.
Technical Data
1.3.3.4.6 Classification of Sales Item: Category

Characteristic: 0RPM_RIC
This represents the category for the classification of sales item.
Technical Data
Data Modeling
Error while merging data SXDP_QUERY_BI_SAP_POSDM_100_PS2
No BW object exists for this query: TLOGO=IOBJ

OBJNM=0RPM_RIS
1.3.3.4.7 Classification of Sales Item: Subcategory

Characteristic: 0RPM_RISC
This characteristic represents the classification of a sales item at the subcategory level.
Technical Data

Characteristic: 0RPM_RDF
Technical Data
1.3.3.4.9 Credit/Debit Indicator at Transaction Level

Characteristic: 0RPM_TRD
This characteristic represents the credit/debit indicator at the transaction level.
Technical Data
1.3.3.4.10 Customer Number of Plant/Store

Characteristic: 0RPM_RSI
This characteristic represents the Retail Store ID.
Technical Data
1.3.3.4.11 Hour
Characteristic: 0RPM_HOR
This characteristic is used for the drill down on an hourly basis for different queries.
Technical Data
1.3.3.4.12 Item ID
Characteristic: 0RPM_ITI
This characteristic represents the TLOG Item ID (Retail Item).
Technical Data
Characteristic: 0RPM_MARK
This characteristic is used internally (as a flag) in the BEx queries to identify if Markdown Sales.
Technical Data
1.3.3.4.14 Material Group

Characteristic: 0RPM_MATGRP
This characteristic represents the Items Material Group (Merchandise Category).
Technical Data
1.3.3.4.15 Offer
Characteristic: 0RPM_OFFER
This characteristic represents the Offer ID at the discount level.
Technical Data
1.3.3.4.16 Promotion
Characteristic: 0RPM_PROMO
This characteristic represents the Promotion ID at the Item Level.
Technical Data
1.3.3.4.17 Reason
Characteristic: 0RPM_RRC
This characteristic represents the reason for a sale at the item level.
Technical Data
1.3.3.4.18 Record Qualifier

Characteristic: 0RPM_QUALIF
This characteristic is used internally to expose the TLOGF record qualifier. This field defines the type of data stored in a given row of the TLOG flat table. It is used
internally in the BEx queries for filtering purposes.
Technical Data
1.3.3.4.19 Retail Type Code

Characteristic: 0RPM_RTC
This characteristic represents the retail type code at the TLOG item level.
Technical Data
Retailstrid, Bussdaydate & TransIndx

Characteristic: 0RPM_ALLKEY
This characteristic is used internally to count the number of transactions at the BEx query level. It is the concatenation of the store, the business day and
transaction index. The concatenation is done at the HANA model level.
Technical Data
1.3.3.4.21 Start Date

Characteristic: 0RPM_BTS1
This characteristic represents the transaction start date.
Technical Data
Data Modeling
Refers to characteristic
InfoObject Date 0DATE
Has as Hierarchy Characteristic

InfoObject Calendar Day 0CALDAY
InfoObject Calendar Year/Month 0CALMONTH
InfoObject Calendar month 0CALMONTH2
InfoObject Quarter 0CALQUART1
InfoObject Calendar Year/Quarter 0CALQUARTER
InfoObject Calendar Year/Week 0CALWEEK
InfoObject Calendar Year 0CALYEAR
InfoObject Fiscal year / period 0FISCPER
InfoObject Posting period 0FISCPER3
InfoObject Fiscal year 0FISCYEAR
InfoObject Halfyear 0HALFYEAR1
InfoObject Weekday 0WEEKDAY1
1.3.3.4.22 Start Time Stamp (Time)

Characteristic: 0RPM_BTS2
This characteristic represents the transaction start time.
Technical Data
Data Modeling
Refers to characteristic
InfoObject Time 0TIME
1.3.3.4.23 Task Canceled

Characteristic: 0RPM_CANC
This characteristic represents a canceled task.
Technical Data
1.3.3.4.24 Transaction Type Code

Characteristic: 0RPM_TTC
This characteristic represents the transaction type code.
Technical Data
1.3.3.5 MultiProviders
1.3.3.6.1 Sales
MultiProvider: 0RPM_MC02
This MultiProvider enables POS reporting on sales. All sales queries delivered as part of the POS In-Memory Analytics content are based on the definition of this
MultiProvider. This is why we recommend you use 0RPM_MC02 as your source for reporting.
This MultiProvider is constructed in the same way as the corresponding InfoCube 0RPM_VP02.
Data Modeling
Requires
InfoObject Change Run ID 0CHNGID
InfoObject Material 0MATERIAL
InfoObject Material group 0MATL_GROUP
InfoObject Record type 0RECORDTP
InfoObject Request ID 0REQUID
InfoObject Business Transaction 0RPA_BTY
InfoObject Qualifier for Article Identifier 0RPA_IQU
InfoObject Item ID 0RPA_ITI
InfoObject Credit/Debit Items Indicator 0RPA_RDF
InfoObject Classification of Sales Item: Category 0RPA_RIC
InfoObject Classification of Sales Item: Subcategory 0RPA_RISC
InfoObject Sales Item Type 0RPA_RTC
InfoObject Credit/Debit Transaction Indicator 0RPA_TRD
InfoObject Transaction Type 0RPA_TTC
InfoObject Start Date 0RPM_BTS1
InfoObject Start Time Stamp (Time) 0RPM_BTS2
InfoObject Task Canceled 0RPM_CANC
InfoObject Data Status 0RPM_DAT
InfoObject Calendar Day 0RPM_DAY
InfoObject Distributed Discount 0RPM_DID
InfoObject Distributed Included Transaction Tax 0RPM_DITXI
InfoObject Hour 0RPM_HOR
InfoObject Calendar Month 0RPM_MTH
InfoObject Normal Sales Value 0RPM_NSA
InfoObject Discount Value 0RPM_REA
InfoObject Tax Included 0RPM_TXI
InfoCube Sales 0RPM_VP02
InfoObject Calendar Week 0RPM_WEK
InfoObject Calendar Year 0RPM_YER
InfoObject Retail location 0RT_LOCATIO
InfoObject Promotion 0RT_PROMO

This MultiProvider enables POS reporting on markdown sales. All markdown sales queries delivered as part of the POS In-Memory Analytics content are based
on the definition of this MultiProvider. This is why we recommend you use 0RPM_MC06 as your source for reporting.
Data Modeling
Requires
InfoObject Markdown Sales Transaction 0RPM_MARK
InfoCube Markdown Sales Transactions 0RPM_VP06
1.3.3.5.3 Number of Sales

This MultiProvider enables POS reporting on the number of sales. All number of sales queries delivered as part of the POS In-Memory Analytics content are
based on the definition of this MultiProvider. This is why we recommend you use 0RPM_MC07 as your source for reporting.
Data Modeling
Requires
InfoObject Retailstrid, Bussdaydate & TransIndx 0RPM_ALLKEY
InfoObject Counter 0RPM_COUNT
InfoCube Number of Transactions 0RPM_VP07

This MultiProvider enables POS reporting on the average sales per transaction. All average sales per transaction queries delivered as part of the POS In-
Memory Analytics content are based on the definition of this MultiProvider. This is why we recommend you use 0RPM_MC08 as your source for reporting.
Data Modeling
Requires
InfoCube Average Sales per Txn 0RPM_VP08

This MultiProvider enables POS reporting on the average number of items per transaction. All average number of items per transaction queries delivered as part
of the POS In-Memory Analytics content are based on the definition of this MultiProvider. This is why we recommend you use 0RPM_MC09 as your source for
reporting.
Data Modeling
Requires
InfoObject Base Unit of Measure 0BASE_UOM
InfoObject Quantity in Base Units 0RPM_BQTY
InfoObject Quantity in Sales Units 0RPM_SQTY
InfoCube Average Number of Items per Txn 0RPM_VP09
InfoObject Sales unit 0SALES_UNIT
1.3.3.6 Info Cubes
1.3.3.6.1 Sales
InfoCube: 0RPM_VP02
This virtual InfoCube is used in all reports related to gross and net sales, and discounts. It calculates the amounts at the TLOG item level and exposes many key
figures needed to calculate the KPIs.
Data Modeling
Requires

InfoCube: 0RPM_VP06
This virtual InfoCube is used in all reports related to markdown sales. It exposes the main key figures needed to calculate the markdown sales at the TLOG item
level.
Data Modeling
Requires
InfoObject Markdown Sales Transaction 0RPM_MARK
1.3.3.6.3 Number of Transactions

InfoCube: 0RPM_VP07
This virtual InfoCube is used in all reports related to the number of transactions.
Data Modeling
Requires
InfoObject Counter 0RPM_COUNT
1.3.3.6.4 Averages Sales per Transaction

InfoCube: 0RPM_VP08
This virtual InfoCube is used in all reports related to average net sales per transaction.
Data Modeling
Requires

InfoCube: 0RPM_VP09
This virtual InfoCube is used in all reports related to average number of items per transaction.
Data Modeling
Requires
InfoObject Base Unit of Measure 0BASE_UOM
InfoObject Quantity in Base Units 0RPM_BQTY
InfoObject Quantity in Sales Units 0RPM_SQTY
InfoObject Sales unit 0SALES_UNIT
1.3.3.7 Queries
1.3.3.7.1 Sales Summary

Query: 0RPM_VP02_Q0001
This query is used to display sales summary (gross, net, discounts and net returns).
This query displays the summary of gross sales, net sales, discounts and net returns of selected material groups for selected stores over specified time periods.
For the selected stores and material groups, the query also provides the variance of gross sale, net sales, discounts and net returns during the specified time
periods. Users can drill down to view results by store and/or material group.
Users can select the currency in which to display the data in order to more easily compare the results, for example, for stores located in different countries.
The query can be filtered by data status.
Structure
Filters
Filters
Object Type Name Technical Name Value Restriction / Calculation
Characteristic Material 0RPM_MAT Restricted by variable 0P_RPM_MAT
Characteristic Cust. No. of Plant 0RPM_RSI Restricted by variable 0P_RPM_STORES
Characteristic Task Canceled 0RPM_CANC Restricted by variable

0P_RPM_TASK_CANCELED
Characteristic Credit/Debit Indicat 0RPM_TRD Excluding: X
Characteristic Business Transaction 0RPM_BTY Including: 1
Characteristic Classification of Sa 0RPM_RIC Restricted by variable

0P_RPM_CAT_MULTI
Characteristic Classification of Sa 0RPM_RISC Restricted by variable 0P_RPM_SCAT
Characteristic Data Status 0RPM_DAT Restricted by variable

0P_RPM_DATA_STATUS
Characteristic Material Group 0RPM_MATGRP Restricted by variable 0P_RPM_MATGRP
Characteristic Document Currency 0DOC_CURRCY Restricted by variable 0P_RPM_CURRCY
Free Characteristics
Characteristic Cust. No. of Plant 0RPM_RSI
Characteristic Material Group 0RPM_MATGRP
Characteristic Material 0RPM_MAT
Characteristic Trans. Type Code 0RPM_TTC
Characteristic Retail Type Code 0RPM_RTC
Variables
Variable POSDM Sales Analysis Stores List 0P_RPM_STORES
Variable POSDM Sales Analysis Material Group 0P_RPM_MATGRP
Variable POSDM Sales Analysis Material 0P_RPM_MAT
Variable POSDM Sales Analysis Date Range 1 0I_RPM_DATE1
Variable POSDM Sales Analysis Time Range 1 0I_RPM_TIME1
Variable POSDM Sales Analysis Data Status 0P_RPM_DATA_STATUS
Variable POSDM Sales Analysis Sub-Category 0P_RPM_SCAT
Variable POSDM Sales Analysis Category 0P_RPM_CAT_MULTI
Variable POSDM Sales Analysis Task Canceled 0P_RPM_TASK_CANCELED
Variable POSDM Sales Analysis Currency 0P_RPM_CURRCY
Rows
Columns
Key Figure Gross Sales Range 1 SEL_RPM_RK009 Gross Sales for a date range specified
using variable 0I_RPM_DATE1 and time
range specified using variable
0I_RPM_TIME1 (Restricted Key Figure).
Gross Sales are calculated as follows:
Gross Sales = Normal Sales Value
(0RPM_NSA) — Tax Included
(0RPM_TXI) — Distributed Included
Transaction Tax (0RPM_DITXI) +
Distributed Discount (0RPM_DID) +
Discount Value (0RPM_REA).
Key Figure Gross Sales Variance CKF_RPM_CK013 Variance between Gross Sales Range 1
and Gross Sales Range 2 (Calculated Key
Figure).
Key Figure Net Sales Range 1 SEL_RPM_RK005 Net Sales for a date range specified using
variable 0I_RPM_DATE1 and time range
specified using variable 0I_RPM_TIME1
(Restricted Key Figure).
Net Sales are calculated as follows:
Net Sales = Normal Sales Value
Transaction Tax (0RPM_DITXI) —
Distributed Discount (0RPM_DID).
Key Figure Net Sales Variance CKF_RPM_CK005 Variance between Net Sales Range 1 and
Net Sales Range 2 (Calculated Key Figure).
Key Figure Discounts Range 1 SEL_RPM_RK013 Discounts for a date range specified using
Discounts are calculated as follows:
Discounts = Distributed Discount +
(ORPM_DID) Discount Value
(0RPM_REA).
(0RPM_REA).
Key Figure Discounts Variance CKF_RPM_CK018 Variance between Discounts Range 1 and
Discounts Range 2 (Calculated Key
Figure).
(0RPM_REA).
Key Figure Net Returns Range 1 SEL_RPM_RK018 Net Returns for a date range specified using
Net Returns are calculated as follows:
Net Returns = Normal Sales Value
Key Figure Net Returns Range 2 SEL_RPM_RK019 Net Returns for a date range specified using
Key Figure Net Returns Variance CKF_RPM_CK019 Variance between Net Returns Range 1
and Net Returns Range 2 (Calculated Key
Figure).
1.3.3.7.2 Gross Sales
1.3.3.7.2.1 Gross Sales Summary

This query displays the gross sales summary of selected material groups for selected stores over specified time periods. For the selected stores and material
groups, the query also provides the variance of gross sales during the specified time periods. Users can drill down to view results by store and/or material group.
Structure
Filters


0P_RPM_CAT_MULTI

0P_RPM_DATA_STATUS
Characteristic Task Canceled 0RPM_CANC
Characteristic Data Status 0RPM_DAT
Variables
Variable POSDM Sales Analysis Task Cancelled 0P_RPM_TASK_CANCELED
Rows
Columns
Key Figure Gross Sales Variance CKF_RPM_CK013 Variance between Gross Sales Range 1
and Gross Sales Range 2 (Calculated Key
Figure).
1.3.3.7.2.2 Gross Sales Rolling Time Period Trend

This query displays the trend of gross sales for selected material groups and selected stores over a specified time period. It also provides the trend of gross sales
during the same time period for the previous year. Users can drill down to view the results by year, month, week, day, or hour.
Structure
Filters


0P_RPM_CAT_MULTI

0P_RPM_DATA_STATUS
Characteristic Calendar Day 0RPM_DAY
Characteristic Calendar Month 0RPM_MTH
Characteristic Calendar Week 0RPM_WEK
Characteristic Calendar Year 0RPM_YER
Characteristic Hour 0RPM_HOR
Variables
Rows
Columns
1.3.3.7.2.3 Gross Sales Top Location Performers

This query displays the top ranking stores based on the gross sales for the selected stores and the selected material groups during the specified time period. The
query provides the total amount of the gross sales for each store included in the query.
Conditions
Characteristic Gross Sales Range 1 SEL_RPM_RK009 Display top stores. This number is defined
using variable 0P_RPM_SINGLE
Structure
Filters


0P_RPM_CAT_MULTI

0P_RPM_DATA_STATUS
Variables
Variable POSDM Sales Analysis Single Parameter 0P_RPM_SINGLE
Rows
Columns
Gross sales are calculated as follows:
1.3.3.7.2.4 Gross Sales Bottom Location Performers

This query displays the bottom ranking stores based on the gross sales for the selected stores and the selected the material groups during the specified time
period. The query provides the total amount of the gross sales for each store included in the query.
Conditions
Characteristic Gross Sales Range 1 SEL_RPM_RK009 Display bottom stores. This number is
defined using variable 0P_RPM_SINGLE
Structure
Filters


0P_RPM_CAT_MULTI

0P_RPM_DATA_STATUS
Variables
Rows
Columns
1.3.3.7.2.5 Gross Sales Top Merchandising Category Performers

This query displays the top ranking material groups based on the gross sales for the selected stores and the selected material groups during the specified time
period. The query provides the total amount of the gross sales for each material group included in the query.
Conditions
Characteristic Gross Sales Range 1 SEL_RPM_RK009 Display top merchandise category. This
number is defined using variable
0P_RPM_SINGLE
Structure
Filters


0P_RPM_CAT_MULTI

0P_RPM_DATA_STATUS
Characteristic
Variables
Variable POSDM Sales Analysis Material Group List 0P_RPM_MATGRP
Rows
Columns
1.3.3.7.2.6 Gross Sales Bottom Merchandise Category

Performers
This query displays the bottom ranking material groups based on the gross sales for the selected stores and the selected material groups during the specified
time period. The query provides the total amount of the gross sales for each material group included in the query.
Conditions
Characteristic Gross Sales Range 1 SEL_RPM_RK009 Display bottom merchandise categories.

This number is defined using variable
0P_RPM_SINGLE
Structure
Filters


0P_RPM_CAT_MULTI
0P_RPM_DATA_STATUS
Variables
Rows
Columns
1.3.3.7.2.7 Departments Gross Sales for a Given Location and

Items Gross Sales for a Given Department
This query displays the gross sales for selected material groups within a selected store. It also displays the gross sales for items (products) within a selected
material group.
Structure
Filters

Characteristic Classification of Sa 0RPM_RIC Restricted by variable 0P_RPM_CAT

0P_RPM_DATA_STATUS
Characteristic Item ID 0RPM_ITI
Characteristic Item Qualifier 0RPM_IQU
Variables
Variable POSDM Sales Analysis Category 0P_RPM_CAT
Rows
Columns
0I_RPM_TIME1 (Restricted Key Figure)
(0RPM_NSA) — Tax Included(0RPM_TXI)
— Distributed Included Transaction Tax
(0RPM_DITXI) + Distributed Discount
(0RPM_DID) + Discount Value
(0RPM_REA)
1.3.3.7.3 Net Sales
1.3.3.7.3.1 Net Sales Summary

This query displays the net sales summary of selected material groups for selected stores over specified time periods. For the selected stores and material
groups, the query also provides the variance of net sales during the specified time periods. Users can drill down to view results by store and/or material group.
Structure
Filters


0P_RPM_CAT_MULTI

0P_RPM_DATA_STATUS
Variables
Rows
Columns
(Restricted Key Figure)
Distributed Discount (0RPM_DID)
Key Figure Net Sales Variance CKF_RPM_CK005 Variance between Net Sales Range 1 and
Net Sales Range 2 (Calculated Key Figure).
1.3.3.7.3.2 Net Sales Rolling Time Period Trend

This query displays the trend of net sales for selected material groups and selected stores over a specified time period. It also provides the trend of net sales
during the same time period for the previous year. Users can drill down to view the results by year, month, week, day, or hour.
Structure
Filters


0P_RPM_CAT_MULTI

0P_RPM_DATA_STATUS
Characteristic Calendar Day 0RPM_DAY
Characteristic Calendar Month 0RPM_MTH
Characteristic Calendar Week 0RPM_WEK
Characteristic Calendar Year 0RPM_YER
Characteristic Hour 0RPM_HOR
Variables
Rows
Columns
1.3.3.7.3.3 Net Sales Top Location Performers

This query displays the top ranking stores based on net sales for the selected stores and the selected material groups during the specified time period. The query
provides the total amount of net sales for each store included in the query.
Conditions
Characteristic Net Sales Range 1 SEL_RPM_RK005 Display top stores. This number is defined
using variable 0P_RPM_SINGLE
Structure
Filters


0P_RPM_CAT_MULTI

0P_RPM_DATA_STATUS
Variables
Rows
Columns
1.3.3.7.3.4 Net Sales Bottom Location Performers

This query displays the bottom ranking stores based on net sales for the selected stores and the selected material groups during the specified time period. The
query provides the total amount of the net sales for each store included in the query.
Conditions
Characteristic Net Sales Range 1 SEL_RPM_RK005 Display bottom stores. This number is
defined using variable 0P_RPM_SINGLE
Structure
Filters

Business Transaction Including: 1

0P_RPM_CAT_MULTI

0P_RPM_DATA_STATUS
Variables
Rows
Columns
1.3.3.7.3.5 Net Sales Top Merchandising Category Performers

This query displays the top ranking material groups based on the net sales for the selected stores and the selected material groups during the specified time
period. The query provides the total amount of the net sales for each material group included in the query.
Conditions
Characteristic Net Sales Range 1 SEL_RPM_RK005 Display top merchandise category. This
0P_RPM_SINGLE
Structure
Filters


0P_RPM_CAT_MULTI

0P_RPM_DATA_STATUS
Characteristic Trans. Type Code 0RPM_TTC Including: 1001
Variables
Rows
Columns
1.3.3.7.3.6 Net Sales Bottom Merchandise Category Performers

This query displays the bottom ranking material groups based on the net sales for the selected stores and the selected material groups during the specified time
period. The query provides the total amount of the net sales for each material group included in the query.
Conditions
Characteristic Net Sales Range 1 SEL_RPM_RK005 Display bottom merchandise category. This
0P_RPM_SINGLE
Structure
Filters


0P_RPM_CAT_MULTI

0P_RPM_DATA_STATUS
Variables
Rows
Columns
1.3.3.7.3.7 Departments Net Sales for a Given Location and

Items Net Sales for a Given Department
This query displays the net sales for selected material groups within a selected store. It also displays the net sales for items (products) within a selected material
group.
Structure
Filters


0P_RPM_CAT_MULTI

0P_RPM_DATA_STATUS
Characteristic Item ID 0RPM_ITI
Characteristic Item Qualifier 0RPM_IQU
Variables
Rows
Columns
1.3.3.7.4 Discounts
1.3.3.7.4.1 Discounts Summary

This query displays the discounts summary of selected material groups for selected stores over specified time periods. For the selected stores and material
groups, the query also provides the variance of discounts during the specified time periods. Users can drill down to view results by store and/or material group.
Structure
Filters


0P_RPM_CAT_MULTI

0P_RPM_DATA_STATUS
Variables
Rows
Columns
(0RPM_REA).
(0RPM_REA).
Key Figure Discount Variance CKF_RPM_CK018 Variance between Discounts Range 1 and
Discounts Range 2 (Calculated Key
Figure).
(0RPM_REA).

POS Retail PDF

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

POS Retail PDF

Загружено:

Авторское право:

Доступные форматы

SAP POS Data Management

PDF download from SAP Help Portal:

Created on August 12, 2015

Loss Prevention Analytics

1.1 POS Inbound Processing Engine

1.1.1 Generation of POS Transactions

1.1.1.1 POS Inbound

1.1.1.1.1 Use of the BAPI /POSDW/BAPI_POSTR_CREATE

1.1.1.1.2 Use of IDocs

1.1.1.2 Generation Using the POS Workbench

1.1.1.3 Real-Time Individual Processing (Trickle Feed)

1.1.2 Aggregation of POS Transactions

1.1.2.1 Aggregation in Task Processing

1.1.2.2 Forming of Aggregates

1.1.3 Task Processing

Task Code Task Description

0001 Supply BW Without Distribution

0002 Sales Audit Performed, Manual Task

0004 Supply BW with Distribution

0005 Supply of Old POS Content in BW

0009 Generate WPUBON IDoc (Non-Goods Items)

0010 Generate WPUBON IDoc

0011 Generate WPUWBW IDoc

0012 Generate WPUFIB IDoc

0013 Generate WPUTAB IDoc

0014 Generate WPUUMS IDoc

0015 Credit Card Settlement

0016 Confirmation of Credit Card Settlement

0017 Supply ERP Inventory Management

0018 Supply CRM Loyalty Interface

0020 Supply SAP Forecasting and Replenishment

0030 Check Balancing for Totals Transactions

0040 Perform Transaction Reversal

0050 Supply - DMF-Based Applications

0060 Calculation for Short/Over Balancing

0061 Send Short/Overs to ERP

0101 Oil & Gas SSR Payment Card Data Processing

1001 Check for Duplicate Transaction Numbers

1002 Check for Receipt Numbers Without Gaps

5001 LPA: Provision of Suspicious Transactions

8001 Aggregate Transaction Data for Analytics

8002 Supply Analytics Cont. with Distributed Transaction Data

8003 Determine Transaction Data Status

The specified aggregation tasks are listed under Aggregation Tasks.

1.1.3.1 Sending Data to SAP CRM

1.1.3.2 Using the PIPE Dispatcher

1.1.3.3 Sending Data to POS Analytics

1.1.3.4 Sending Data to SAP Retail

1.1.3.4.1 Sending Sales Data via IDoc WPUBON

1.1.3.4.2 Sending Sales Data via IDoc WPUUMS

1.1.3.4.3 Sending Means of Payment Data via IDoc WPUTAB

1.1.3.4.4 Sending Financial Transaction Data via IDoc WPUFIB

1.1.3.4.5 Sending Goods Movement Data via IDoc WPUWBW

Sending Data to SAP F&R

1.1.3.6 Sending Data to Credit Card Settlement

1.1.3.7 Outbound of sales data to SAP DMF-based applications

1.1.3.8 Task Processing for POS In-Memory Analytics

Task Code Task Description

8001 Aggregate Transaction Data for Analytics

8002 Supply Analytics Cont. with Distributed Transaction Data

8003 Update Data Status for Analytics

1.1.3.8.1 Enhancing Transaction Data for POS In-Memory

BAdI Implementation Transaction Data Enhancement Description