Bestpractice Pos Analytics

BP_MO_for_POS-DataMgmt_POS-AnalyticsContent_V30.doc 24.04.
2009
Best Practice for Solution Operations
Manage Operations for
POS Data Management
POS Analytics Content
Dietmar-Hopp-Allee 16
D-69190 Walldorf
CS STATUS
customer published
DATE VERSION
Mar-19, 2009 3.0
SOLUTION MANAGEMENT PHASE SAP SOLUTION
Operations & Continuous Improvement Best Practices for Solution Operations
TOPIC AREA SOLUTION MANAGER AREA
Application & Integration Management Business Process Operation
Best Practice for Sol ution Operations
Manage Operations for SAP POS Data Management - POS Analytics Content
2009 SAP AG - BP_MO_for_POS-DataMgmt_POS-AnalyticsContent_V30.doc page 2/32
Table of Contents
1 Management Summary 3
1.1 Goal of Using this Best Practice 3
1.2 Alternative Practices 3
1.3 Staff and Skills Requirements 3
1.4 System Requirements 4
1.5 Duration and Timing 4
1.6 How to Use this Best Practice 4
1.7 Best Practice Procedure 5
1.7.1 Preliminary tasks 5
1.7.2 Monitoring Concepts 5
1.7.3 Business Process Monitoring in SAP Solution Manager 5
1.7.4 Monitoring Types for Business Process Monitoring in SAP Solution Manager 6
1.7.4.1 Application Monitor 7
1.7.4.2 Background J ob 7
1.7.4.3 ABAP Dump Collector 8
1.7.4.4 Dialog performance 9
1.7.4.5 Update errors 11
1.7.4.6 Application Log 12
1.7.4.7 Analysis and monitoring tools 13
1.7.4.8 Monitoring activities 15
1.7.4.9 Notifications 15
1.7.5 Business Process Monitoring Process 16
2 Process execution and monitoring for a POS Analytics BI Content scenario 17
2.1 Sample Scenario 17
2.1.1 Process Step 12: Transfer master data for POS data management to SAP NetWeaver BI 18
2.1.1.1 Description 18
2.1.1.2 Monitoring objects 23
2.1.1.3 Error handling per monitoring object 23
2.1.2 Proc. step 7b: Update transactional POS data for POS data management to SAP NetWeaver BI 24
2.1.2.1 Description 24
2.1.2.2 Monitoring requirements: 28
2.1.2.3 Monitoring Objects 28
2.1.2.4 Error handling per monitoring object 28
3 Further Information 30
3.1 Related Best Practice Documents 30
3.2 Background Information and References 30
Index of Figures 31
Index of Tables 31
1 Management Summary
1.1 Goal of Using this Best Practice
This Best Practice helps you set up a Business Process Monitoring concept for your POS data management
solution. The concept aims to define procedures for business process oriented monitoring and error handling
and escalation procedures for your processes in POS analytics content. These procedures intend to ensure a
smooth and reliable flow of this core business process so that your business requirements are met.
This Best Practice gives orientation for defining suitable application oriented monitoring objects in order to
detect any irregularities or deviations from an ideal business process flow or to detect error situations
concerning a core business process at an early stage.
This Best Practice contains the recommended approach from SAP which uses whenever possible the SAP
Solution Manager for the Monitoring functionalities. But even if you do not use the SAP Solution Manager we
recommend to follow the procedures described in this document as much as possible in order to ensure a
smooth and reliable flow of your business processes as well as an appropriate response in case of
unforeseen errors.
1.2 Alternative Practices
You can have SAP experts deliver this Best Practice on-site by ordering an Solution Management
Optimization (SMO) service for SAP Business Process Management (BPM). This service is exclusively
available within SAPs support engagements SAP MaxAttention and SAP Safeguarding. If your company
currently does not have any support engagement with SAP, it is also possible to get assistance by SAP
experts from SAP Consulting. If this case, please contact your local SAP Consulting representative.
1.3 Staff and Skills Requirements
To implement this Best Practice, you require the following teams:
Appli cation management t eam
This team creates the retail business process monitoring concept and consists of experts from several areas
of your company:
Business department
Solution support organization (for example the Basis Support or the Application Support)
Implementation project team
Busi ness Process Operations Team
The Business Process Operations Team will be responsible for applying the resulting procedures derived
from implementing this best practice. They include the following groups:
Persons designated to perform business process oriented monitoring and ensure that the process runs
smoothly (e.g. the business process champion for each business process)
All parties in your solution support organization and IT department involved in monitoring focused on the
application aspects (application support, development support, job scheduling management)
SAP Technol ogy Operations Team
All parties in your solution support organization and IT department involved in monitoring focused on the
system administration side (program scheduling management, software monitoring team, system
administration team including the System Administrator)
Busi ness process champion
The business process champion is the person in the business department that is responsible for the
successful execution of the business process. He coordinates all activities necessary for the business
process. Therefore, he is usually responsible for the escalation paths in case of problems. Often he is a
second level in the escalation procedure, if the application monitoring team needs to escalate an issue.
More information about roles and responsibilities of these teams can be found in the super-ordinate Best
Practice General Business Process Management, which you can obtain through SAP Solution Manager or
the SAP Service Marketplace, quicklink /BPM.
Necessary or useful trai nings
SM300 Business Process Management and Monitoring
E2E300 End-to-end Business Process Integration and Automation Management
1.4 System Requirements
In order to monitor business processes running in your SAP POS DM solution via SAP Solution Manager, the
SAP basis release of the systems to be monitored have to be at least 4.6C. To have all described monitoring
objects available in SAP Solution Manager, the add-on ST-A/PI 01L has to be installed on the SAP
NetWeaver BI system.
1.5 Durati on and Timing
Durati on
Creating a Business Process Monitoring concept could take around one week per business process.
Implementing the Business Process Monitoring concept might take approximately an additional week.
Timing
The best time to apply this Best Practice is during the planning phase or during the implementation phase of
your SAP solution.
1.6 How to Use this Best Practice
Here you find a brief description of how you should proceed in using this document:
Read through the general SAP Business Process Management Best Practice, available on the SAP
Service Marketplace. This document explains the procedures you should use to create a general Business
Process Management concept. This includes the definition and documentation of the core business
processes, definition of monitoring objects, definition of monitoring activities including error handling
procedures, monitoring tools and monitoring frequencies, the definition of communication and escalation
procedures and the assignment of responsibilities.
At the beginning of Chapter 2 you will find a typical flow chart of the core business process explained in
this Best Practice. It is intended to be used as a guideline for writing down your company specific process
documentation.
In Chapter 1.7.4 you find further information that is relevant for more than one scenario. In case
information from the generic part is relevant for a specific business process step in one of the scenarios
you will find a clear link to the corresponding chapter in the generic part.
1.7 Best Practice Procedure
1.7.1 Preliminary tasks
Before performing this Best Practice, ensure that you perform the following preliminary tasks or checks in the
system:
Complete all installation and post-installation actions and procedures including customizing
Ensure that the initial download has been successfully executed
Apply all SAP recommendations from SAP Service Sessions and any SAP recommendations resulting
from customer problem messages
Implement all current Support Packages upon availability
1.7.2 Moni tori ng Concepts
The monitoring procedures proposed for each business process step are the core of this Best Practice. The
monitoring procedures help you to ensure that the technical processes meet the requirements for stability,
performance and completeness. These procedures cover monitoring for the five areas:
Error monitoring
Performance monitoring
Throughput monitoring
Backlog monitoring
Data consistency monitoring
For each of the business process steps you will find the following information:
A detailed functional description of the process step
Identifiedmonitoring requirements for the process step
Defined monitoring objects, alerts and selection criteria
Description of error handling procedures and restartability
General monitoring activities that are valid for all or most scenarios are described in the generic part in
Chapter 1.7.4. Recommendations for performance monitoring can also be found in this chapter. The
performance of the most important steps of your core business processes should be monitored on a regular
basis. The monitoring procedure for performance monitoring of all steps that are executed in an SAP
NetWeaver BI solution is generally the same. Therefore, you will only find specific performance monitoring
recommendations on selected business process steps.
1.7.3 Business Process Monitoring in SAP Solution Manager
Business Process Monitoring (BPMon), as part of Solution Monitoring means the proactive and process-
oriented monitoring of the most important or critical business processes including the observation of all
technical and business application specific functions that are required for a steady and stable flow of the
business processes.
The core business processes that are implemented in a SAP NetWeaver BI system or other software and
operated by a company are of particular importance, and Business Process Monitoring is intended to ensure
a smooth and reliable operation of the business processes and, thereby, that the core business processes
meet a companys business requirements in terms of stability, performance, and completeness. The SAP
Solution Manager provides a graphic to visualize a companys (distributed) system and solution landscape
and all related business processes. By using Business Process Monitoring, it is possible to define and
customize alert situations from a basic set of configurable alerts provided by the SAP Solution Manager.
These alerts are then visualized by green, yellow, and red alert icons for each individual business process
step in the graphical business process representation. Business Process Monitoring is intended to detect and
respond to critical situations as early as possible in order to solve problems as fast as possible.
In addition, the SAP Solution Manager offers extended functionality for error handling and problem resolution.
By the definition of contact persons and escalation paths, Business Process Monitoring can be integrated into
the companys overall strategy for Business Process Management and Solution Management within their
Solution Support Organization.
In general, a Business Process Monitoring includes the solution-wide observation of:
Business process performance (Key Performance Indicators)
Background jobs (J ob Scheduling Management tasks)
Business application logs (such as any error log, general application log, due list logs etc.)
Data transfer via interfaces between software components
Data consistency
Technical infrastructure and components which are required to run the business processes
Required periodic monitoring tasks
For further details on Business Process Monitoring please refer to http://service.sap.com/bpm.
1.7.4 Moni tori ng Types for Busi ness Process Monitoring in SAP Solution Manager
Monitoring Types are part of the functional scope of Business Process Monitoring as it is available in the SAP
Solution Manager. The below mentioned Monitoring Types are available:
Application Monitor (Throughput and Backlog Indicators, Data Consistency Checks, Mass Activity
Monitors, Due List Log, MRP key figures, User Exit)
Background J obs (J obs running on SAP Systems with an SAP Basis)
Dialog Performance (Dialog transaction performance)
Update Error (V1 and V2 update errors from SM13 for specific transactions and programs)
Due List Log (messages for deliveries and billings)
Application Log (messages from the Application Log SLG1)
Document Volume (based on table call statistics in ST10)
Other CCMS Monitor (all alerts that are configured in the CCMS Alert Monitor)
Depending on what is executed during a specific business process step the relevant monitoring types must
be selected. In order to receive detailed information on how to set up the monitoring objects in the SAP
Solution Manager, please refer to the documentation that is available under http://service.sap.com/bpm.
One prerequisite for setting up Business Process and Interface Monitoring in the SAP Solution Manager is
that all business processes and business process steps are maintained in the respective solution that
contains all affected system components. If you want to learn more about how to set this up, please turn to
(URL http://help.sap.com) SAP Solution Manager Basic Settings.
1.7.4.1 Application Monitor
The Application Monitor is just one of many different monitoring types within the Business Process
Monitoring. The latest monitoring objects are only provided if the latest ST-A/PI plug-in is installed on the
satellite system. The service tool for ST-A/PI is available via the SAP Service Marketplace quick link
/installations Entry by Application Group Plug-Ins SAP Solution Tools ST-A/PI.
Please ensure that the ST-A/PI is installed on the SAP Solution Manager system and on the respective
satellite system. In case of problems refer to SAP Note 915933.
For the throughput and backlog indicator functionality available as of ST-A/PI 01J *, the minimum ST-
SER release is 700_2007_1.
More detailed information about the different Application Monitor functionalities and a detailed description on
how to define self-written monitoring collectors for the user exit are explained in the documents Setup Guide
Application Monitoring and Setup Guide User Exit respectively (URL http://www.service.sap.com/ Alias
BPM Media Library).
1.7.4.1.1 Throughput and Backlog Indicators (TBIs)
As of ST-A/PI 01H a completely new set of Application Monitors has been introduced. While the already
established monitors are all evaluating specific logs or performance data these new monitors are considering
(un-)processed documents in the SAP system and provide so called throughput and backlog indicators.
These TBIs should especially provide
Automated and early detection of application error situations and backlogs in the core business processes
Automated error and backlog analysis tools
For example, in ERP Logistics the following monitors are available:
Sales and services (e.g. Sales Documents, Invoices)
Warehouse management (e.g. transfer requirements, transfer orders)
Inventory management (e.g. goods movements)
Logistics execution (e.g. deliveries, shipments)
Procurement (e.g. planned orders, purchase requisitions, purchase orders)
Manufacturing (e.g. planned orders, production or process orders, autom. goods movements posted with
error, confirmation pool errors)
Plant maintenance (e.g. PM/CS Notifications, PM/CS Orders)
For further information on the different TBIs refer to the document Setup Guide Application Monitoring (URL
http://www.service.sap.com/BPM Media Library).
1.7.4.2 Background Job
The background job monitoring should be part of a job scheduling management concept (go to
http://service.sap.com/solutionmanagerbp Topic Area Business Process Operations to find a Best Practice
document Job Scheduling Managemen). Because of several restrictions regarding background job
scheduling, e.g. time restrictions, restriction of hardware resources (CPU, main memory, ) or existing
dependencies between different activities (e.g. invoices can only be created after the corresponding goods
issue is posted, or back order processing and material requirements planning should not run at the same
time) it is very important to ensure the stable run of background jobs. A cancelled background job should be
identified as soon as possible in order to react as fast as possible. Therefore it is also necessary to define
restart procedures and escalation paths.
Monitoring Objects
Before setting up monitoring the monitoring objects must be clearly defined. A monitoring object is a single
background job or a group of background jobs. There are four different possibilities to identify a special
background job or a group of background jobs. This information needs to be maintained in the sub-node
Background Job below a business process step.
A more detailed description (than provided in this document) on the subject what kind of alerts make sense or
what kind of alerts are possible are discussed in the Best Practice document Background Job Monitoring with
SAP Solution Manager which can be found on the SAP Marketplace
http://service.sap.com/solutionmanagerbp Topic Area Business Process Operation.
1.7.4.3 ABAP Dump Collector
To provide monitoring features for alerting on occurrences of ABAP dumps of specified runtime errors or to
collect statistical data of ABAP dumps for reporting reasons.
Monitoring Objects
The monitoring object is an ABAP runtime error. This runtime error can be specified via the runtime error
name, the user who is responsible for the runtime error, the Client on which the runtime error occurs or the
Program which leads to the runtime error.
Monitoring Alerts
Possible alerts types are the number of ABAP Dumps (Delta) all dumps since the last collector run and
number of ABAP Dumps (Reporting) all runtime errors of specified type, client and program for this day or
for the previous day.
Figure 1: Monitoring alert types
1.7.4.4 Dialog performance
Dialog performance implies the monitoring of the dialog transaction performance of any transaction in the
SAP System. This could be a standard transaction or an own developed transaction.
Monitoring obj ects
The monitoring object is the transaction itself. The customizing has to be done in node Dialog Performance.
In table Transactions all transactions that are already configured to that business process step are listed.
The relevant transactions need to be selected for monitoring. It is also possible to add or to remove
transactions within table Add/Remove Transactions. The monitoring can be performed per SAP instance.
Therefore the respective instances have to be selected in table SAP Instances. All instances that are
maintained for a system are listed there. Table Alert Types shows the dialog response time and all parts of
the response time, like queue time, load and generation time, database request time and the front-end
response time, that can be monitored. Those times that are relevant for monitoring have to be selected.
After saving this node a sub-node Perf ormance Al erts will appear where the threshold values have to be
entered.
Figure 2: Monitoring objects dialog performance
Monitoring alerts
Each table in the sub-node Performance Alerts corresponds to an alert type chosen in the higher-level
node, and lists the combinations of specified transaction code and SAP instance.
For each combination of transaction code and instance that should be included in the monitoring, the
threshold values resulting in alert messages for changes fromGREEN to YELLOW, fromYELLOW to RED,
back fromRED to YELLOW, and back fromYELLOW to GREEN have to be specified.
Since the monitoring object for performance monitoring is created on the satellite system, it might be possible
that the object already exists there. Therefore you can load the current threshold values from the respective
systems via the button Load thresholds from XYZ, whereas XYZ represents the SID.
If successfully retrieved for an SAP instance, the values are filled in columns. If no active settings for the
threshold values were found for a certain transaction code, default values are set (indicated in column
Default). To transfer the threshold values for a single line from right to left, the copy icon can be used. To
transfer all at once (all thresholds for all columns and tables) there is an additional button "Copy all".
Figure 3: Monitoring alerts dialog performance
1.7.4.5 Update errors
Changes to the data in an SAP system caused by a business process should be written to the database in full
or not at all. If the operation is canceled while the transaction is being executed, or if an error occurs, the
transaction should not make any changes to the database. These activities are handled by the SAP update
system.
The SAP system makes a distinction between primary, time-critical (V1) and secondary, non-time-critical (V2)
update errors. This distinction allows the system to process critical database changes before less critical
changes.
V1 modules describe critical or primary changes; these affect objects that have a controlling function in the
SAP system, for example order creation or changes to material stock.
V2 modules describe less critical secondary changes. These are pure statistical updates, for example, such
as result calculations.
Monitoring obj ects
Monitoring of update errors can be configured for online transactions and/or ABAP programs relevant in a
business process. This is the object type. The name of the object is the name of a transaction or the name of
the ABAP program itself. If desired a user executing the transaction or the ABAP program can be specified.
If no user is specified explicitly, all users (represented by '*') will be considered in monitoring data evaluation.
Figure 4: Monitoring objects update errors
Monitoring alerts
Since update errors are usually very critical the default configuration is to raise a yellow alert as soon as one
update error occurs. This is valid for V1 and for V2 update errors. To raise a red alert for a V1 or a V2 update
error a threshold must be specified.
1.7.4.6 Application Log
The application log provides an infrastructure for collecting messages, saving them in the database and
displaying them as a log. Situations can arise at runtime in application programs that must be brought to the
attention of the user in some way. These are usually errors. It can also be useful to report a successful
completion. The information that arises is called a message. The set of messages is a log. A log usually also
has header information (log type, creator, creation time, etc.). A transaction can generate several logs. The
application log is not written consecutively but as a whole at one point in time.
Monitoring obj ects and al erts
The application log allows an application- or object-oriented recording of events. An object and any sub-
object that belongs to it classify each event. The analysis of the logs is similarly object (or sub-object)
oriented. The name of an object (and/or sub object) can be found in transaction /nSLG1 together with all
other specific information to that log.
Figure 5: Monitoring objects and alerts - application log
It is possible to monitor for the total number of messages belonging to an object. Therefore the number of
messages that raises a YELLOW alert and the number of messages changing from a YELLOW to a RED
alert must be maintained.
It is also possible to monitor specific messages that are considered as critical in table CriticalMsgs. To
configure the monitoring of critical application log messages, the relevant object-sub object combinations
need to be selected. For each of these combinations the message type, the message ID and the message
number as well as the threshold values for the number of critical messages that are supposed to result in
changes from GREEN to YELLOW and from YELLOW to RED can be specified. It is also possible to use wild
cards.
Figure 6: Monitoring alert application log/critical messages
1.7.4.7 Analysi s and monitoring tools
It is possible to specify analysis transactions or URL addresses (including file directories) per monitoring
object. In case of analysis transactions these should be used to analyze errors or problems either locally in
the SAP Solution Manager system itself (Call Opti on 1 ) or directly in the respective satellite systems (Call
Option 2 ). Per default some standard transactions are maintained, e.g. transaction SM37, that provides a
job overview in an SAP system, is maintained for background jobs or transaction SLG1 to have a look into the
application log.
It is also possible to add new transactions; this could be standard transactions or customer self-written
transactions.
Figure 7: Analysis & monitoring transactions
On the second tab strip it is possible to specify an URL which should be called in order to further analyze the
given problem. This is especially interesting if you have some knowledge documents linked to a portal. You
define a short text and the URL to be called.
For web pages to be called, specify the full URL, e.g. http://help.sap.com. For content available on file
servers specify the full file path, using the nomenclature: file://\\\<server>\..., e.g.
file://\\\server1\operations_documents\operations-handbook.txt
Figure 8: Analysis & monitoring url
The specified transactions or URLs will be available in the form of buttons within a business process step
when using the monitoring later on inside the Business Process Monitoring session. By pressing these
buttons (e.g. ), the user will jump directly into the corresponding transaction
either in the SAP Solution Manager system (here: SAT) or the connected satellite system (here: CT1) for
further analysis. For URLs the push-button (e.g. ) contains the short text (limited to
20 characters) from the set-up session and leads the user to the defined URL in a newly opened browser
window.
1.7.4.8 Moni tori ng acti vi ties
Monitoring activities should be set up for every monitoring object within a business process step. All
monitoring objects defined within a business process step are listed here. To ensure effective monitoring and
efficient problem resolution the responsibilities should be assigned and problem resolution procedures should
be defined as described in the following table. Some information is taken from the previous node Solution
Support Organization.
Monitoring Team Defines the team that is responsible for monitoring the relevant Monitoring
object. Use value help [F4].
Person Resp. Defines the person who is responsible for monitoring the monitoring object. Use
value help [F4].
Frequency Describes how often the responsible person should process the required
monitoring activity.
Start time Describes at which time the responsible person should process the required
monitoring activity.
Problem Indicator A description about what indicates a problem.
Error handling Describes how to react on problems or errors, i.e. how to solve the
problem/correct the error.
Escal ation Path Describes the escalation path in case that the person responsible could not
solve the problem. Persons who can be contacted should be maintained here.
Tabl e 1: Responsibilities and problem resolution procedures
Additional information related to this business process step can be entered in the tables Monitoring
Acti viti es, Error Handling, Restart of Step and Escalation Path. Those information would be valid for the
whole business process step and helps users who have to carry out the monitoring and who are not so
familiar with that particular business process.
1.7.4.9 Noti fications
Notifications can be set up for the whole business process or for each business process step individually.
There are two types of notifications: Workflow notifications and support notifications. Workflow notifications
allow sending messages in case of alerts to a specified recipient. This could be an e-mail or SAPOffice mail.
Support notifications allow setting up a service desk message in case of an alert. The information entered for
the service desk message serves as a template. The service desk message can be created manually or
automatically.
On business process level it is possible to define notifications for the whole business process i.e. as soon as
the business process gets an alert status, notifications will be triggered. Alternative notifications can be
defined for every monitoring Type individually, e.g. all alerts related to all background jobs of the business
process are forwarded to a defined e-mail address.
Notifications defined on business process step level will overrule the configuration made on business process
level for this particular step.
1.7.5 Business Process Monitoring Process
For a successful and efficient Business Process Monitoring concept, a process for the execution of the
monitoring concept has to be defined. This includes the definition of the roles and responsibilities involved. It
has to be defined who is supposed to carry out which activity within the process and how communication
between the different roles within the support organization is supposed to take place.
A Business Process Monitoring concept has to be tightly integrated with the support organization. This
includes the integration with the Incident/Problem Management process and the Change Management
process. These processes have to be adjusted to the Business Process Monitoring concept so that
communication and escalation procedures contained within these processes are adequate to support the
Business Process Monitoring concept. This includes the final communication of open alert to SAP.
Wherever communication connected with Business Process Monitoring happens outside these support
processes, separate communication and escalation paths and procedures have to be defined.
Please see the above mentioned separate Best Practice for General Business Process Management for
further details.
2 Process executi on and monitori ng for a POS Analytics BI Content
scenario
A retailer is using POS data management to poll, control and send sales data to SAP NetWeaver BI. POS
data management is the combination of the POS Inbound Processing Engine (PIPE) and a preconfigured
business content data model called POS Analytics Content inSAP NetWeaver BI.
Sales transactions are usually registered at the POS system located in the stores. This information is
extracted on a regular basis (ranging from every x seconds to once a day) and transferred via an EAI
middleware and transformation tool (i.e. SAP PI) to POS data managements central component called PIPE
(POS Inbound Processing Engine). Within this tool the incoming data is verified and posted to subsequent
applications. The design of PIPE allows to process data for each subsequent application either immediately
or as a bulk process with a self-defined frequency and a customized aggregation level. Apart from sales data,
other data generated at the POS such as goods movements or financial transactions as well as statistical
information can be transferred using the same path as the sales data. The delivered POS Analytics content
data sources to extract these data to SAP NetWeaver BI are:
0RT_PA_TRAN_CONTROL
0RT_PA_TRAN_CON_REM
0RT_PA_TRAN_GDS_MOV
0RT_PA_GDS_REMOTE
0RT_PA_TRAN_MOV_FIN
0RT_PA_FIN_REMOTE
0RT_PA_TRAN_TOTALS
0RT_PA_TOTALS_REM
0RT_PA_TRAN_INDEX
0RT_PA_TRAN_LOYALTY
After the extraction of the POS data to SAP NetWeaver BI, the data can be analyzed on different levels of
aggregation in the predefined data targets of POS Analytics content.
2.1 Sample Scenario
To enable the POS data management solution in general, the retailer has to make specific master data
available in SAP NetWeaver BI. The required master data can be for example extracted from SAP ERP for
Retail (process 12 in following picture) also using standard BI business content.
The retailer transfers the POS data from PIPE immediately after data consistency checks (master data check,
duplicate check, sequencing gap check, transaction balancing check and totals balancing check) non-
aggregated in detail to SAP NetWeaver BI to enable detailed analysis. The transacti onal data is put into the
BI delta queue of the BI DataSource 0RT_PA_TRAN_CONTROL by PIPE task processing (process 7b in
following pictures).
The upload of the non-aggregated POS transaction data and the master data into the business content data
targets is triggered with standard BI Data transfer processes (InfoPackages and DTPs).
The retailer is analyzing the data aggregated on store/article/day level using InfoCube 0RPA_C01.
These upload processes (transactional & master data) should be monitored to guarantee that BI reporting
shows accurate values on the following day.
Following figure provides an overview of the exemplary process that will be used within this document (step
7b. update BI and step 12. transfer master data):
SAP POS DM / BI System
PIPE
EAI
SAP ERP for Ret ail POS System
2. Send Sales Data
1. Poll Sales Data
SAP SCM F&R
4. Transform Information
3. Receive Information
5. Send Information
6. Post Sales Data
8. Post IDocs
7a. Send IDocs
TLOG
9. Post Goods Movement
7b. Update BI 10. Create Billing Document
11. Create FI Document
7c. Update Sales Data
BI Master Data
12. Transfer Master Data:
Sites, Articles, EAN
Assignment, Unit Conversion
Figure 9: Overview of the exemplary process
For managing and monitoring the operations of the preceding POS Inbound processes, please refer to the
generic business process documentation
Manage operations for IS Retail POS Inbound under https://service.sap.com/solutionmanagerbp
2.1.1 Process Step 12: Transfer master data for POS data management to SAP NetWeaver
BI
2.1.1.1 Description
General information:
To deliver the full set of functionality, SAP POS data management requires the availability of specific master
data in SAP NetWeaver BI. In the sample scenario, this data is available in SAP ERP for Retail and can be
uploaded into SAP NetWeaver BI using standard IS Retail Business Content extractors (except for
0RPA_MEAN and 0RPA_MARM; follow SAP Note 835111).
The following InfoObjects are required byPOS data management
BW Info Object Description Remarks
0MATERIAL Material (article) extraction of Attributes
0PLANT Plant (store) extraction of Attributes
0RPA_MARM Units of measure for article extraction of Attributes
0RPA_MEAN EAN assignment to article extraction of Attributes
0MAT_PLANT or
DSO 0RT_DS01
Plant material
Product and Location Attributes
without data extraction, only activate the Info Object
DSO activated from Business Content
0SALESORG Sales Organisation extraction of Attributes
0COMP_CODE Company Code extraction of Attributes
0FISCPER &
0FISCVARNT
Fiscal Period
Fiscal Year Variant
Maintained in customizing table
Tabl e 2: InfoObjects required by POS data management
Legend:
Mandatory for PIPE dependant on used material level handled by POS DM
Mandatory for PIPE to be available in active version; availability of data not mandatory
Not mandatory for PIPE, but used in SAP NetWeaver BI dataflow form POS Analytics DataSources
upwards
Even if SAP does not deliver preconfigured process chains for the POS Analytics business content, it is
highly recommended to create process chains to upload the master data fromERP for Retail on a daily base
before the transactional data are uploaded.
Figure 10: Example for daily master data process chains setup
This example process chain executes InfoPackages to upload all necessary master data InfoObject attributes
in the correct sequence. The attribute change run as final step of the process chain executes the master data
modificatons on the SAP BW reporting layer in case of changed master data attributes.
The transactional data flow in SAP NetWeaver BI is referring to some of the mentioned InfoObjects in a way
that will be described in more detail. If the master data are not updated regularly, the risk of erroneous data
uploads is high. Additionally, PIPE is executing master data lookups to check and enrich the transactional
POS data internally. As master and transactional data staging can not be handled individually regarding the
functionality of POS data management, a regular monitoring of the master data uploads is mandatory to
establish a stable system environment (find further details in the following chapter Error, Throughput and
Backlog Monitoring). If a customer is using customer InfoObjects instead of the delivered standard
InfoObjects, it is necessary to set up the PIPE as described in SAP Note 732579
The following InfoObjects are used internally in PIPE or in the data flow.
0FISCPER & 0FISCVARNT
are used in the start routines and the field routines that are mapped between the source field
BUSINESSDAYDATE and the target fields 0FISCPER and 0FISCVARNT of the transformations between the
DataSources 0RT_PA_TRAN_CONTROL, 0RT_PA_TRAN_GDS_MOV, 0RT_PA_TRAN_MOV_FIN and
0RT_PA_TRAN_TOTALS and their assigned InfoSources. During the upload of the transactional data to the
data targets, the delivered coding tries to execute the methodr t f / cl _t i me=>get _r et ai l _f per s_f r om_dat e
to derive a valid fiscal variant and period from the table /MAP/TC_FISCYV. The maintenance of these values
can be executed in the BI customizing cockpit with transaction SPRO under the path IMG, SAP NetWeaver,
Business Intelligence Settings for Business Content Trade Industries, Retailing, Set Fiscal Year Variant.
Valid values can be checked and maintained using the transaction code OB29. If no valid fiscal periods and
variants can be derived during the data upload, the upload will fail with an error. See SAP Note 782745.
0MAT_PLANT or DSO 0RT_DS01
have to be available in active version to use the full functionality of POS data management. These objects are
used to enrich the moving average cost price on store article level in SAP NetWeaver BI. In the start routine
of the transformation between the DataSource 0RT_PA_TRAN_CONTROL the FM
RSBCT_RPA_MOVI NG_AVERAGE_GET is called that tries to get the moving average cost price from InfoObject
0MAT_PLANT or the DSO 0RT_DS01 (the specific target has to be specified in the customizing cockpit
/nSPRO under the path IMG, SAP NetWeaver Business Intelligence Settings for Business Content, Trade
Industries, Trade Foundation, General Settings). If this routine fails, the processed data package will raise
and error or warning. It is possible, to influence the system behavior in that area by maintaining the BI
customizing cockpit under the same path. When the missing data for article and plant - critical flag is set, the
executed data upload will raise an error. If it is not flagged, only a warning is given and the data are available
in the data targets for reporting. See SAP Notes 1159170, 819464, 1120082 and 1253582.
0MATERIAL
is a mandatory InfoObject in SAP NetWeaver BI that is used internally in PIPE to execute the master data
check and to enrich additional data in PIPE related to the article. In the standard, PIPE is reading the attribute
0BASE_UOM to check whether the article sales unit combination in the transactional data is valid. The
attribute 0MATL_GROUP is read for each SAP article number and enriched into the transactional data. The
PIPE customizing allows the user a setup, which does not execute that check in the described detail
(/n/POSDW/IMG under path general setting, master data filter and checks using check profiles flag). It is
possible to turn the master data check off in general or for each check profile (under path Check Profil es). In
case that the master data check is not executed, the PIPE will enrich automatically the PIPE field material
number with the value of the field itemid in case that the itemidqualifier was set to SAP article number. The
same enrichment will be executed into the field merchandi secategory in case that the itemidqualifier was
set to SAP Material group. It is necessary to customize the parameter group in the PIPE customizing
/n/POSDW/IMG under path Tasks, One step processing, define parameters for tasks for parameter profile
0006 Master Data Check for the parameters for task, NO_CHECK_FOR_MATERIAL in that way, that no
checks are executed for the material. This parameter profile must be assigned to the task supply BW.
Please refer for further details to SAP Notes 811393 and 1273520
The InfoObject 0PLANT is mandatory in SAP NetWeaver BI in a similar way as described for 0MATERIAL.
PIPE is internally checking the attribute 0LOC_CURRCY to enrich the store currency into the transactional
data. An error occurs in PIPE internally only, if the parameter group in the PIPE customizing /n/POSDW/IMG
under Tasks, One step processing, Define Parameters for Tasks for Parameter Profile 0006 Master Data
Check for the parameters for task NO_CHECK_FOR_STORE_CURRENCY is maintained in that way, that
no checks are executed for the plant. This parameter profile must be assigned to the task supply BW.
The validity of the store is checked in PIPE by reading the attribute 0RT_CUSTPL and comparing the value
with the transactional data value in the PIPE field RETAILSTOREID.
If 0PLANT does not get a value for the attribute 0LOC_CURRCY from the extract on 0PLANT_ATTR, the
field routine of the transformations on 0PLANT raises a warning message when the try fails to get a store
currency by reading the attribute from 0SALESORG and 0COMP_CODE. Therefore it is also necessary to
load information to the Company Code and Sales Organisation InfoObject. Please refer for further details to
SAP Notes 811393 and 1273520
0RPA_MARM and 0RPA_MEAN are InfoObjects that are used by PIPE in case that EANs are delivered
from the POS system. PIPE delivers the standard functionality to enrich for EANs the SAP article number
and SAP material group by executing a lookup in 0RPA_MEAN. Additionally, PIPE recalculates the quantities
sold in base unit of measure by looking up in 0RPA_MARM. Like this, sales data can be delivered in sales
and base units of measure to SAP NetWeaver BI. As the business content in SAP ERP for Retail and SAP
NetWeaver BI does not deliver preconfigured extractors, please follow SAP Note 835111 to create own
generic master data extractors for 0RPA_MEAN). For InfoObject 0RPA_MARM the DataSource
0MAT_UNIT_ATTR can be used to feed the necessary attributes to the InfoObject.
For further details about master data staging in SAP NetWeaver BI, please refer to the generic Run SAP -
Best Practices for Solution Management documentation SAP BW Master Data Upload, Operational Data
Storage Upload with BW 3.x and SAP BW 3.x Data Target Upload under
https://service.sap.com/solutionmanagerbp.
Error, Throughput and Backlog Monitoring:
For successfully executed checks of POS data in PIPE and the processing into the POS Analytics content
data targets the availability of up to date and correct master data is mandatory.
Sample Scenario speci fic:
The master data upload of the described InfoObject attributes must be executed successfully before
transactional POS data can be uploaded to SAP NetWeaver BI. The master data are extracted from the
source system by executing the InfoPackages of the corresponding DataSources and the DTPs into the
InfoObjects.
The following monitors and tools are important for data staging:
Upload Monitor: To have an overview about all upload processes running on your BW system, you
should use the Upload Monitor (transaction RSMO). In the detail monitor of each request (upload process)
the progress of this upload and the single process steps are shown.
Process Chai n Overview: For the application-side analysis of the processes executed via process chain
you can use the Process Chain Overview (transaction RSPC). Here you have an overview about the
progress of your process chains and which processes are taking place at the moment. You see an
overview about the process steps done so far for each process. From here, you can jump to more detailed
monitors of single processes (Open Hub Monitor, Upload Monitor) or to the job log of the processes.
Changerun Moni tor: For problems with changeruns you can use the monitor for changeruns (transaction
CHANGERUNMONI).
Open Hub Monitor: For problems with Open Hub Service and InfoSpokes you can use the Open Hub
Monitor. Similar to the Upload Monitor the Open Hub Monitor shows the progress of each request and the
single process steps.
Performance Monitoring:
To ensure a high availability of master data, it can be useful to regularly check the system performance
during the upload execution. For further details please refer to the generic Run SAP - Best Practices for
Solution Management documentation Periodic J obs and Tasks in SAP BW under
https://service.sap.com/solutionmanagerbp.
2.1.1.2 Moni tori ng objects
Moni tori ng Obj ect Analysi s Tool on
Satell ite System
Moni tori ng Frequency / Data
Col lecti on
Master data upload process chains RSPC during InfoPackage and DTP
execution
Master data upload RSMO during InfoPackage and DTP
execution
Change run execution after master data
upload
CHANGERUNMONI during InfoPackage and DTP
execution
Tabl e 3: Transfer master data Monitoring objects
2.1.1.3 Error handling per moni toring object
If the upload of the master data process chains is failing, the reason for the error can be found by using the
following analyzing tools
Moni tori ng Obj ect Analysi s tool on satelli te syst em Monitoring frequency / data
coll ection
System Log SM21 after InfoPackage and DTP
execution
ABAP Runtime Errors ST22 after InfoPackage and DTP
execution
Tabl e 4: Transfer master data Error handling per monitoring object
Further details about monitoring tools in SAP NetWeaver BI are available as generic Run SAP - Best
Practices for solution management documentation in https://service.sap.com/solutionmanagerbp under
Monitoring for BI Basis (ABAP and J ava), Monitoring for BI Reporting and Background J ob monitoring with
SAP Solution Manager
2.1.2 Proc. step 7b: Update transacti onal POS data for POS data management to SAP
NetWeaver BI
2.1.2.1 Description
General information:
A POS generates different types of transactions like sales transactions, goods movements and financial
transactions as well as statistical information. The design of PIPE allows to process these data to SAP
NetWeaver BI either immediately or as a bulk process with a self-defined frequency and a customized
aggregation level.
The PIPE data are transferred to the BI delta queues of the followingPOS Analytics DataSources:
0RT_PA_TRAN_CONTROL (sales transactions)
0RT_PA_TRAN_GDS_MOV (goods movements)
0RT_PA_TRAN_MOV_FIN (financial transactions)
0RT_PA_TRAN_TOTALS (statistical information)
Since SAP NetWeaver BI CONT 7.03 SP6, this data is extracted to the PSA tables of the DataSources using
transformations. The POS Analytics content delivers preconfigured data flows for the DataSources
0RT_PA_TRAN_CONTROL and 0RT_PA_TRAN_TOTALS on InfoSource and InfoCube (MultiCube) level.
For the DataSources 0RT_PA_TRAN_GDS_MOV and 0RT_PA_TRAN_MOV_FIN, data flows are available
to InfoSource level. The upload from the PSA tables to the InfoCubes is executed by DTPs via preconfigured
transformations. In the transformation between the DataSource and its corresponding InfoSource, the logic
for the key figure calculation is encapsulated in ABAP service classes. The instantiation of the trade
foundation service classes are called in the start routine of the transformation. Additionally each key figure
simply calls a the same method with a unique key figure name. Depending on the key figure name a different
calculation logic is executed. It is possible to create own implementations for service classes for own key
figures. Using this concept has the benefit, that established and productive data flows for transactional data
will not get inactive, when content or development changes are imported into the SAP NetWeaver BI system
(for further details, please refer to the following document: How to Use Service Classes for
Keyfigure Transformations (http://service.sap.com/~sapidb/011000358700000194902009E). After the upload
of the transactional data into the InfoCubes, analyses of the POS data can be executed on different levels
and views using content queries. The POS Analytics content delivers reporting possibilities on cashier,
receipt, and store/article (day/week/month) level. For further information please see SAP Note 811393.
Sample scenario specific information:
Sales data delivered from POS are sent from PIPE to the SAP NetWeaver BI delta queue
0RT_PA_TRAN_CONTROL. The transactional data is extracted from the BI delta queue into the InfoCube
0RPA_C01 (store/article/day)
Figure 11: Process chain
Even if SAP does not deliver preconfigured process chains for the POS Analytics business content, it is
highly recommended to create process chains to upload the transactional data regularly from the delta queue
into the POS Analytics InfoCube after the master data loads are executed.
Example for a regularly executed transactional data process chains setup:
Figure 12: Example for a regularly executed transactional data process chains setup
As POS data management is designed to handle huge volumes of transactional data generated at POS and
the volumes of data transferred into SAP NetWeaver BI are critical. So a regular monitoring of the
transactional data uploads is mandatory to establish a stable system environment (please refer to the
described monitoring tools in chapter Error, Throughput and Backlog Monitoring). Because of these huge
volumes, a detailed view on the used staging areas in SAP NetWeaver BI is useful to decide measure to
avoid critical redundancies and to enable a performing data upload, staging and reporting process in SAP
NetWeaver BI.
BI delta queue
The transactional data from PIPE are stored in the delta queue to establish a delta scenario to upload
unprocessed data to the PSA table. Please pay attention that a full upload is not supported to update the
SAP NetWeaver BI data targets from PIPE. To establish the delta queue, it is mandatory to create and
execute at the first time an InfoPackage to initialize the delta process without data transfer.
Figure 13: Initialize delta process
After the delta queue is initialized, the deltas are uploaded to the PSA table with a separate InfoPackage for
delta upload.
Figure 14: Delta update
PSA tabl e
The persistent staging area table is keeping the original transactional data from the SAP NetWeaver BI delta
queue. The PSA table ensures an easy reprocessing of data into InfoCubes or other data targets without the
need of affecting other source systems in case that data have been processed incorrectly or have been
deleted.
InfoCube
The InfoCube is storing the data on the required level for long term usage for reporting. The scenario
InfoCube 0RPA_C01 is storing POS data on the level store/article/day. Two additional InfoCubes are storing
the data on higher timely aggregation (week and month).
Recommendations
As POS data management processes high volume data, a concept for avoiding redundancies and retention
periods is mandatory. A detailed view, for how long time data have to be kept in the delta queue and the PSA
table can support the customer in avoiding large overheads in the processing and staging of POS data.
Integrating a corporate memory DSO (1:1 copy of the PSA table for mid term storage) or near line storage
solutions can completely avoid performance issues during data processing in the whole POS Analytics data
flow. The retention period of POS data to be available in PIPE must be taken into consideration dependant on
the quality of data delivered in a production environment (the more erroneous data from POS, the longer the
retention period in PIPE). The InfoCubes should not store more then 100 million records when the classic
reporting environment is in use. If a BIA (SAP NetWeaver BI Accelerator) is available, the InfoCube can
easily manage much more data.
2.1.2.2 Moni tori ng requirements:
Backlog moni tori ng:
To get a good overview over the data staging and database performance situation of the system, the usage
of monitoring tools is helpful.
Sample scenario specific:
Check the data upload and staging performance for the delta queue and PSA table of DataSource
0RT_PA_TRAN_CONTROL and InfoProvider 0RPA_C01. Monitor the execution of the InfoPackage that
transfers the data from the BW delta queue into the 0RT_PA_TRAN_CONTROL PSA table and the DTP that
transfers the transactional data form the PSA table to the InfoCube 0RPA_C01
Performance Monitoring:
To ensure a high availability of transactional data, it can be useful to regularly check the system performance
during the upload execution. To optimize the system performance, please refer to the described details in the
generic Run SAP Best Practices for Solution Management documentation and Background J ob monitoring
with SAP Solution Manager chapters:
Performance
Data management
2.1.2.3 Moni tori ng Obj ects
Moni tori ng Obj ect Analysis Tool on Satel lite
System
Monitoring Frequency/
Data Col lection
Transactional Data upload process chains RSPC during InfoPackage and DTP
execution
Transactional Data upload RSMO during InfoPackage and DTP
execution
Tabl e 5: Update transactional POS data Monitoring objects
2.1.2.4 Error handling per monitoring obj ect
If the upload of the transactional data process chains is failing, the reason for the error can be found by using
the following analyzing tools
Monitoring Object Anal ysis Tool on
Satelli te System
Monitoring Frequency/Data Col l ection
System Log SM21 after InfoPackage and DTP execution
ABAP Runtime Errors ST22 after InfoPackage and DTP execution
Tabl e 6: Update transactional POS data Error handling per monitoring object
Further details about monitoring tools in SAP NetWeaver BI are available as generic Run SAP Best
Practices for Solution Management documentation in https://service.sap.com/solutionmanagerbp under
Monitoring for BI Basis (ABAP and J ava), Monitoring for BI Reporting and Background J ob monitoring with
SAP Solution Manager
3 Further Information
3.1 Related Best Practice Documents
There are several other Best Practice documents available on the SAP Service Marketplace under
https://service.sap.com/solutionmanagerbp that relate to this Best Practice document. These documents are:
General Business Process Management: This document explains the procedures you should use to
create a general c concept. This includes the definition and documentation of the core business
processes, definition of monitoring objects, definition of monitoring activities including error handling
procedures, monitoring tools, monitoring frequencies, the definition of communication and escalation
procedures and the assignment of responsibilities.
ALE Monitoring: This Best Practice helps you set up an Interface Monitoring concept with the focus on
ALE Monitoring for your SAP solution. This document will outline possibilities on how to optimally monitor
ALE-based interfaces manually as well as automated by using SAP Solution Manager. Both monitoring
approaches aim to detect any irregularities or deviations or to detect error situations at an early stage.
Job Scheduling Management: This Best Practice provides a detailed description what SAP recommends
as a standardized formal process to support a job request process, including an end user job request form
and an approval process. This integrated process will avoid error-prone and time intensive manual
processes of copying redundant data from one data source to another (for example, MS excel to MS Excel
or MS Excel to job scheduling tool).
SAP Business Process Management for ERP Logistics: This Best Practice helps you set up a Business
Process Monitoring concept for your SAP ERP solution. The concept aims to define procedures for
business process oriented monitoring and error handling and escalation procedures for your companys
ERP core business processes. These procedures intend to ensure a smooth and reliable flow of the core
business processes so that your business requirements are met.
Background Job monitoring with SAP Solution Manager: This Best Practice will help you to set up
background job monitoring properly in the framework of Business Process Monitoring in the SAP Solution
Manager.
Please note that these documents are also available in the SAP Service Marketplace using alias RunSAP
RunSAP Best Practices.
3.2 Background Information and References
How to Use Service Classes for Keyfigure Transformations available under:
http://service.sap.com/~sapidb/011000358700000194902009E
Index of Figures
Figure 1: Monitoring alert types 9
Figure 2: Monitoring objects dialog performance 10
Figure 3: Monitoring alerts dialog performance 10
Figure 4: Monitoring objects update errors 11
Figure 5: Monitoring objects and alerts - application log 12
Figure 6: Monitoring alert application log/critical messages 13
Figure 7: Analysis & monitoring transactions 14
Figure 8: Analysis & monitoring url 14
Figure 9: Overview of the exemplary process 18
Figure 10: Example for daily master data process chains setup 20
Figure 11: Process chain 25
Figure 12: Example for a regularly executed transactional data process chains setup 26
Figure 13: Initialize delta process 26
Figure 14: Delta update 27
Index of Tables
Table 1: Responsibilities and problem resolution procedures 15
Table 2: InfoObjects required by POS data management 19
Table 3: Transfer master data Monitoring objects 23
Table 4: Error handling per monitoring object 23
Table 5: Update transactional POS data Monitoring objects 28
Table 6: Error handling per monitoring object 28
Copyright 2009 SAP AG. 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 AG.
The information contained herein may be changed without prior notice.
Some software products marketed by SAP AG and its distributors contain proprietary software components of other software vendors.
Microsoft, Windows, Outlook, and PowerPoint are registered trademarks of Microsoft Corporation.
IBM, DB2, DB2 Universal Database, OS/2, Parallel Sysplex, MVS/ESA, AIX, S/390, AS/400, OS/390, OS/400, iSeries, pSeries, xSeries,
zSeries, z/OS, AFP, Intelligent Miner, WebSphere, Netfinity, Tivoli, and Informix are trademarks or registered trademarks of IBM
Corporation.
Oracle is a registered trademark of Oracle Corporation.
UNIX, X/Open, OSF/1, and Motif are registered trademarks of the Open Group.
Citrix, ICA, Program Neighborhood, MetaFrame, WinFrame, VideoFrame, and MultiWin are trademarks or registered trademarks of Citrix
Systems, Inc.
HTML, XML, XHTML and W3C are trademarks or registered trademarks of W3C, World Wide Web Consortium, Massachusetts
Institute of Technology.
J ava is a registered trademark of Sun Microsystems, Inc.
J avaScript is a registered trademark of Sun Microsystems, Inc., used under license for technology invented and implemented by
Netscape.
MaxDB is a trademark of MySQL AB, Sweden.
SAP, R/3, mySAP, mySAP.com, xApps, xApp, SAP NetWeaver, and other SAP products and services mentioned herein as well as their
respective logos are trademarks or registered trademarks of SAP AG in Germany and in several other countries all over the world. All
other product and service names mentioned are the trademarks of their respective companies. Data contained in this document serves
informational purposes only. National product specifications may vary.
The information in this document is proprietary to SAP. No part of this document may be reproduced, copied, or transmitted in any form
or for any purpose without the express prior written permission of SAP AG.
This document is a preliminary version and not subject to your license agreement or any other agreement with SAP. This document
contains only intended strategies, developments, and functionalities of the SAPproduct and is not intended to be binding upon SAP to
any particular course of business, product strategy, and/or development. Please note that this document is subject to change and may
be changed by SAP at any time without notice.
SAP assumes no responsibility for errors or omissions in this document. SAP does not warrant the accuracy or completeness of the
information, text, graphics, links, or other items contained within this material. This document is provided without a warranty of any kind,
either express or implied, including but not limited to the implied warranties of merchantability, fitness for a particular purpose, or non-
infringement.
SAP shall have no liability for damages of any kind including without limitation direct, special, indirect, or consequential damages that
may result from the use of these materials. This limitation shall not apply in cases of intent or gross negligence.
The statutory liability for personal injury and defective products is not affected. SAP has no control over the information that you may
access through the use of hot links contained in these materials and does not endorse your use of third-party Web pages nor provide any
warranty whatsoever relating to third-party Web pages.

Bestpractice Pos Analytics

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Bestpractice Pos Analytics

Uploaded by

Copyright:

Available Formats

BP_MO_for_POS-DataMgmt_POS-AnalyticsContent_V30.doc 24.04.

You might also like