posdm

Table of Contents1. POS Inbound Processing Engine...........................................................................................................3

1.1. Generation of POS Transactions....................................................................................................51.1.1 POS Inbound............................................................................................................................5

1.1.1.1 Use of the BAPI /POSDW/BAPI_POSTR_CREATE.....................................................61.1.1.2 Use of IDocs....................................................................................................................7

1.1.2 Generation Using the POS Workbench...................................................................................71.1.3 Real-Time Individual Processing (Trickle Feed).....................................................................8

1.2 Carrying Out of Sales Audits...........................................................................................................81.2.1 Use of the POS Workbench.....................................................................................................8

1.2.1.1 Selection and General Settings........................................................................................91.2.1.2 Checking the Data Transfer............................................................................................111.2.1.3 Control of Task Processing............................................................................................111.2.1.4 Analyzing Errors and Messages.....................................................................................161.2.1.5 Display of Processing History and Follow-On Documents...........................................171.2.1.6 Editing POS Transaction Data.......................................................................................171.2.1.7 Searching for POS Transactions....................................................................................191.2.1.8 Mass Changes to POS Transactions...............................................................................191.2.1.9 Display of Stores Without Communication...................................................................211.2.1.10 Carrying Out Ad Hoc Analyses....................................................................................211.2.1.11 Monitoring of POS Aggregates....................................................................................21

1.2.2 Automatic Checks..................................................................................................................221.2.2.1 Master Data Checks.......................................................................................................221.2.2.2. Rules.............................................................................................................................23

1.3 Aggregation of POS Transactions.................................................................................................241.3.1 Aggregation in Task Processing.............................................................................................241.3.2 Forming of Aggregates..........................................................................................................25

1.4 Task Processing.............................................................................................................................261.4.1 Using the PIPE Dispatcher....................................................................................................281.4.2 Sending Data to POS Analytics.............................................................................................29

1.5 Sending Data to SAP Retail..........................................................................................................291.5.1 Sending Sales Data via IDoc WPUBON...............................................................................301.5.2 Sending Sales Data via IDoc WPUUMS...............................................................................301.5.3 Sending Means of Payment Data via IDoc WPUTAB..........................................................311.5.4 Sending Financial Transaction Data via IDoc WPUFIB.......................................................321.5.5 Sending Goods Movement Data via IDoc WPUWBW.........................................................33

1.6 Sending Data to SAP F&R............................................................................................................331.7 Sending Data to Credit Card Settlement.......................................................................................341.8 Outbound of sales data to SAP DMF-based applications.............................................................35

Activities....................................................................................................................................371.9 Aggregation Tasks.........................................................................................................................371.10 Using Outbound Tasks................................................................................................................381.6 Tasks for Checking Transactions...................................................................................................39

1.6.1 Check for Duplicate Transaction Numbers............................................................................391.6.2 Displaying Gaps in Receipt Numbers....................................................................................401.6.3 Checking Comparisons for Totals Transactions....................................................................40

1.7 Rules..............................................................................................................................................41

1.7.1 Check for Balanced Transaction............................................................................................431.7.2 Comparing Receipt Data and Cash Desk Totals....................................................................431.7.3 Check for Performance of Sales Audit..................................................................................441.7.4 Credit Card Data Check.........................................................................................................44

1.8 Outbound Processing of Aggregates.............................................................................................451.8.1 Performing Outbound Processing..........................................................................................45

1.9 Archiving Transaction Data...........................................................................................................461.10 Providing POS Transactions for Online Stock Queries and Inventories During Opening Hours.............................................................................................................................................................471.11 Encryption of Payment Cards......................................................................................................481.12 Roles............................................................................................................................................49

1.12.1 Sales Auditor/POS Monitoring............................................................................................491.12.2 POS Inbound Processing Engine (PIPE) Administration....................................................49

1. POS Inbound Processing Engine

Purpose

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:

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. 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 three ways to generate POS transactions:

●POS Inbound via BAPI

●POS Inbound via IDoc

●Create Using the POS Workbench

1.1.1 POS Inbound

Use

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

http://help.sap.com/saphelp_nw70/helpdata/en/46/65216a1c931b54e10000000a155369/content.htm

http://help.sap.com/saphelp_nw70/helpdata/en/46/6472c472ed1b53e10000000a155369/content.htm

http://help.sap.com/saphelp_nw70/helpdata/en/46/65216a1c931b54e10000000a155369/content.htm

http://help.sap.com/saphelp_nw70/helpdata/en/46/64de26f9891b52e10000000a155369/content.htm

http://help.sap.com/saphelp_nw70/helpdata/en/46/6472c472ed1b53e10000000a155369/content.htm

1.1.1.1 Use of the BAPI /POSDW/BAPI_POSTR_CREATE

Use

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 Immediate Individual Processing (Trickle Feed)).

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.

Real-Time Individual Processing (Trickle Feed)

Use

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.

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.

http://help.sap.com/saphelp_nw70/helpdata/en/46/65213d1c931b54e10000000a155369/content.htm

http://help.sap.com/saphelp_nw70/helpdata/en/46/6657352f2f0d76e10000000a1553f7/content.htm

1.1.1.2 Use of IDocs

Use

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, an automatically generated IDoc type 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

○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.2 Generation Using the POS Workbench

Purpose

In this process, you manually generate POS transactions in the PIPE in order to use them productively or for test purposes.

Process Flow

Start the POS Workbench and generate whatever POS transactions you wish as described under Processing the POS Transaction Data.

http://help.sap.com/saphelp_nw70/helpdata/en/46/6502d5075a1b55e10000000a155369/content.htm


1.1.3 Real-Time Individual Processing (Trickle Feed)

Use

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.

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.2 Carrying Out of Sales Audits

Purpose

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 Flow

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

●Controlling Task Processing

●Error and Message Analysis

●Display of Processing History and Follow-On Documents

●Creating, Changing, or Deleting POS Transaction Data

●Search for POS Transactions

http://help.sap.com/saphelp_nw70/helpdata/en/46/650369075a1b55e10000000a155369/content.htm


http://help.sap.com/saphelp_nw70/helpdata/en/46/654be539cf1b53e10000000a155369/content.htm

http://help.sap.com/saphelp_nw70/helpdata/en/46/64eb68f9891b52e10000000a155369/content.htm

http://help.sap.com/saphelp_nw70/helpdata/en/46/654a3a39cf1b53e10000000a155369/content.htm

http://help.sap.com/saphelp_nw70/helpdata/en/46/64e9eff9891b52e10000000a155369/content.htm

http://help.sap.com/saphelp_nw70/helpdata/en/46/64e9b6f9891b52e10000000a155369/content.htm

http://help.sap.com/saphelp_nw70/helpdata/en/46/654f8f1c931b54e10000000a155369/content.htm

http://help.sap.com/saphelp_nw70/helpdata/en/46/64e7aaf9891b52e10000000a155369/content.htm


●Mass Change of POS Transactions

●Display of Stores Without Communication

●Carrying Out Ad Hoc Analyses

●Displaying Processing Status of POS Aggregates

1.2.1.1 Selection and General Settings

Use

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 without errors

○Consideration of the business transaction:

You can include the following business transactions in the selection:

■Sales movements

■Goods movements

■Totals records

■Cancellation 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:

http://help.sap.com/saphelp_nw70/helpdata/en/46/648ebd44d71b56e10000000a155369/content.htm

http://help.sap.com/saphelp_nw70/helpdata/en/46/648e9144d71b56e10000000a155369/content.htm

http://help.sap.com/saphelp_nw70/helpdata/en/46/648e6544d71b56e10000000a155369/content.htm

http://help.sap.com/saphelp_nw70/helpdata/en/46/6558181c931b54e10000000a155369/content.htm

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.2 Checking the Data Transfer

Purpose

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 Flow

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 Processing the POS Transaction Data.

1.2.1.3 Control of Task Processing

Purpose

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 section 4 - Task Processing. The status of task processing for POS transactions can be seen independent of the relevance of the task.

Process Flow

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.

In the navigation area, you navigate along the folder hierarchy to the level of the individual POS transactions and display them in the overview.


http://help.sap.com/saphelp_nw70/helpdata/en/46/648eec44d71b56e10000000a155369/content.htm

I.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.

Meaning of Task Status

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.

http://help.sap.com/saphelp_nw70/helpdata/en/46/6520ad1c931b54e10000000a155369/content.htm

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 cancelation 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 now 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.

II. 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.

III.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 cancelation. 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.

IV.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:

i. You reject processing of the task. The task receives the status Rejected.

ii. 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.


i. You ignore the warning and set the status of the task to Completed.

ii. Due to the warning, you wish to cancel processing of the task. You flag the task for cancelation. The task receives the status Ready to be Canceled.

You can also cancel a task that has status Completed. You flag the task for cancelation. The task receives the status Ready to be Canceled.

○If an error occurs during cancelation of a task, the task receives the status Error During Cancelation.


i. You remove the cause of the error and reset the status to Ready to be Canceled.

ii. You stop the cancelation and set the status to Completed.

If a warning is issued during cancelation of a task, the task receives the status Canceled with Warning.

In this case, you have two options:

i. You ignore the warning and set the status to Canceled.

ii. 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:

The following table provides an overview of the meaning of the status transitions.

Meaning of Status Transition

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.4 Analyzing Errors and Messages

Purpose

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 Flow


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.5 Display of Processing History and Follow-On Documents

Purpose

You can use this process to check what type of processing has been carried out for specific POS transactions.

Process Flow



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.6 Editing POS Transaction Data

Purpose

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 Flow



Here you can create new, change, or copy individual POS transactions. Section deleted

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, 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.

http://help.sap.com/saphelp_nw70/helpdata/en/46/654f8f1c931b54e10000000a155369/content.htm

1.2.1.7 Searching for POS Transactions

Use

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.8 Mass Changes to POS Transactions

Use

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.9 Display of Stores Without Communication

Use

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

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. 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.10 Carrying Out Ad Hoc Analyses

Use

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.11 Monitoring of POS Aggregates

Purpose

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.

For more information, see Aggregation Tasks.

Process Flow

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 workbench and then carry out the selection.

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.

http://help.sap.com/saphelp_nw70/helpdata/en/46/65615050d11b55e10000000a155369/content.htm

●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.

1.2.2 Automatic Checks

Use

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.

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

Use

You can use this function to check the master data of POS transactions.

Since the system partly 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 choose between two different models for performing master data checks; these do not differ in results, but in flexibility. You can either choose the classic master data check or the master data check that uses check profiles.

Prerequisites

You have customized the PIPE so checks are processed by the system.

If you would like to perform a classic master data check, then in the PIPE Customizing General Settings area

http://help.sap.com/saphelp_nw70/helpdata/en/46/648f1844d71b56e10000000a155369/content.htm

http://help.sap.com/saphelp_nw70/helpdata/en/46/648eec44d71b56e10000000a155369/content.htm

http://help.sap.com/saphelp_nw70/helpdata/en/46/6520df1c931b54e10000000a155369/content.htm

enter the master data filter value and ensure that the Checks using Check Profile checkbox is not selected.

If, however, you would like to perform checks using check profiles, ensure that the Checks using Check Profile checkbox is selected in the General Settings area.

The Master Data Filter is irrelevant. Since master data checks are processed for both the POS Workbench area as well as within the task processing, different check profiles can be set. For the POS Workbench, store the check profile in the Profile area specific to each customizing profile. For each future task that is to be processed, set the check profile in either the Tasks ® One-Step Processing ® Tasks area or the Tasks ® Two-Step Processing ® Aggregation Tasks area.

If you do not want to use the SAP standard check profile, you can create one or more of your own in the check profile area of the PIPE customizing.

If you use check profiles and do not set a check profile for a customizing profile or a task process, then no check and, furthermore, no data enhancement will take place in this case. This can lead to errors with task processing, for example.

Features

The system automatically carries out the checks you have determined at the appropriate times. They are processed in the following situations:

●When the editor is started for a particular POS transaction within the POS Workbench

●When POS transactions are created

●When tasks are processed

The system checks for POS transaction data and automatically enhances them with further data.

If there are not any POS transaction data in the system and the 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

Use

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 Tasks ® Rules and assign to each task the rule that the system is to use for checking during task processing.

For more information, see Rules.

Features

In task processing, the system automatically carries out any rules you have defined for a task.


http://help.sap.com/saphelp_nw70/helpdata/en/46/6cffbbdc700ad3e10000000a11466f/content.htm


1.3 Aggregation of POS Transactions

Purpose

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.

Process Flow

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.3.1 Aggregation in Task Processing

Use

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:

●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.

http://help.sap.com/saphelp_nw70/helpdata/en/46/6572311c931b54e10000000a155369/content.htm

http://help.sap.com/saphelp_nw70/helpdata/en/46/65585c39cf1b53e10000000a155369/content.htm


●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.3.2 Forming of Aggregates

Use

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




http://help.sap.com/saphelp_nw70/helpdata/en/46/65588839cf1b53e10000000a155369/content.htm


Ensure that you have made the necessary settings in the PIPE Customizing.


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.4 Task Processing

Purpose

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 Immediately, Non-Aggregated, with Distribution

0002 Sales Audit Performed, Manual Task

0004 Supply BW with Distribution

0009 Generate WPUBON IDoc(non-merchandise 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

0020 Supply of F&R

0030 Check Balancing for Totals Transactions

1001 Check for Duplicate Transaction Numbers

1002 Check for Receipt Numbers Without Gaps

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 in PIPE Customizing.

●Ensure that you have set the type of tasks to be carried out under Tasks ® One-Step Processing ® Tasks or Tasks ® Two-Step Processing ® Aggregation Tasks depending on the requirements to one of the values Immediate Processing, Collective Processing or Manual Processing.

●Under Tasks ® POS Transactions, check the task group that is assigned to the relevant POS transaction and assign a task group if required.

●Under Tasks ® 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 ® Tasks for Task Group.

Check also, if necessary, if processing of a task for a defined POS transaction type makes sense.

Process Flow

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.


http://help.sap.com/saphelp_nw70/helpdata/en/46/648f9d44d71b56e10000000a155369/content.htm


●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.4.1 Using the PIPE Dispatcher

Use

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 Processingand 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:

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.4.2 Sending Data to POS Analytics

Purpose

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.

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 ® Tasks depending on the requirements to either Immediate Processing or Collective Processing and you have checked the correctness of the other task settings.

●Under Tasks ® 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 ® Task Group.

●You have ensured that the task to be carried out is assigned to the relevant task group under Tasks ® Tasks for Task Group.

Process Flow

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.5 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.


http://help.sap.com/saphelp_nw70/helpdata/en/46/6558e239cf1b53e10000000a155369/content.htm





http://help.sap.com/saphelp_nw70/helpdata/en/db/b43ff5c4bd3d49ae3bc72d12ba9df7/content.htm

For more information, see Outbound Processing.

1.5.1 Sending Sales Data via IDoc WPUBON

Purpose

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 Flow

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.5.2 Sending Sales Data via IDoc WPUUMS

Purpose

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

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 Flow

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 During the Processing of Tasks.

Carry out processing of the task for the relevant POS transactions depending on the task type. For more information, see Task Processing.


1.5.3 Sending Means of Payment Data via IDoc WPUTAB

Purpose

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








Process Flow

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 During the Processing of Tasks.



1.5.4 Sending Financial Transaction Data via IDoc WPUFIB

Purpose

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 Flow

The task 0012 Generate IDoc WPUFIB is available in the standard system for sending financial transaction data



to SAP Retail 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.


1.5.5 Sending Goods Movement Data via IDoc WPUWBW

Purpose

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 Flow

The task 0011 IDoc WPUWBW is available in the standard system for sending goods movement data to SAP Retail using the IDoc WPUWBW.



1.6 Sending Data to SAP F&R

Purpose

In this process you send the data of POS transactions to SAP Forecasting & Replenishment (SAP F&R).

Prerequisites








Process Flow

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 During the Processing of Tasks.



1.7 Sending Data to Credit Card Settlement

Purpose

In this process, you send transaction data from credit card payments to credit card settlement and receive confirmation of the processing status.

Prerequisites






Process Flow

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.

You carry out processing of the task for the relevant POS transactions depending on the task type. For more




information, see Task Processing.

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.8 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 Profiles.

• You have assigned the transfer relevant stores to that profile by choosing Store Customizing.

• You have maintained a task group for the aggregation and transfer of sales transactions by choosing Tasks Task Group

Transaction types:

• You have maintained a transaction type group for the transfer relevant (sales) transactions by choosing POS Transactions POS Transactions Type Group

• You have maintained the transfer relevant transaction types and assigned them to the corresponding

transaction type group and task group by choosing POS Transactions POS Transactions Type

Sales item types:

• You have maintained the relevant sales item type groups by choosing POS Transactions Sales Items Type Group

• 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 Sales Items Type

Tax types:

• You have maintained the relevant tax type groups by choosing POS Transactions Taxes Type Group

• You have maintained the relevant tax types and assigned them to the corresponding tax type groups and task group by choosing POS Transactions Tax Type

Discount types:

• You have maintained the relevant discount type groups by choosing POS Transactions Discount Type Group

• 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 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 Additonal

Details for Tasks

• You have assigned the task to the corresponding task group for the transfer of sales transactions by choosing Tasks Tasks for Tasks 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 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 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 Two-Step Processing 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 Tasks for 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.9 Aggregation Tasks

Use

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 ® Aggregation Tasks 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 ® Aggregation Level.

●Under Tasks ® 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 ® 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 / inventory

2002 Material / inventory with taxes + discounts

2011 Cash desk / cashier / department / means of payment

2012 Means of Payment

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.10 Using Outbound Tasks

Use

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 ® Aggregation Tasks; 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 ® Aggregation Tasks.

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.6 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


Once the task has been carried out successfully, the system sets the task status for all processed POS transactions to Completed.

For more information on the tasks mentioned, see Outbound Tasks and Outbound Processing of Aggregates.

1.6.1 Check for Duplicate Transaction Numbers

Purpose

With this process you can define whether doubled transaction numbers for the POS transactions transferred to PIPE from the POS system.

Prerequisites




●You have ensured that the task group, which is assigned to the transaction type of your POS transaction, exists


http://help.sap.com/saphelp_nw70/helpdata/en/46/6db9e406290ad5e10000000a11466f/content.htm


http://help.sap.com/saphelp_nw70/helpdata/en/46/648ebd44d71b56e10000000a155369/content.htm


under Tasks ® Task Group.


Process Flow

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.6.2 Displaying Gaps in Receipt Numbers

Purpose

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 Flow

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.6.3 Checking Comparisons for Totals Transactions

Purpose

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 Flow

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.7 Rules

Use

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 ® Rules and that the rule that is to be used for the relevant task is assigned under Tasks ® One-Step Processing ® Tasks or Tasks ® Two-Step Processing ® Aggregation Tasks.

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:

1.7.1 Check for Balanced Transaction

Use

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 ® Tasks or Tasks ® Two-Step Processing ® Aggregation Tasks.

●Customizing of the rule is set correctly under Tasks ® 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.


This way you can see for each individual POS transaction if it is balanced or if an inconsistency exists.

1.7.2 Comparing Receipt Data and Cash Desk Totals

Use

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




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.7.3 Check for Performance of Sales Audit

Use

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




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.7.4 Credit Card Data Check

Use

You can use this function to check the credit card data that has been used in payment in a POS transaction.


http://help.sap.com/saphelp_nw70/helpdata/en/46/6c78c7850869dfe10000000a11466f/content.htm

http://help.sap.com/saphelp_nw70/helpdata/en/46/6c78c7850869dfe10000000a11466f/content.htm


Prerequisites




Features








Based on the result, you can see if the credit card data relating to a POS transaction is in order.

1.8 Outbound Processing of Aggregates

Purpose

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 Flow

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.8.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 check box 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 processings. 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.9 Archiving Transaction Data

Use

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.

Procedure

Start transaction SARA and use the following archiving objects:

●/POSDW/TL for archiving of POS transactions

●/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.10 Providing POS Transactions for Online Stock Queries and Inventories During Opening Hours

Use

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 ® Aggregation Tasks. 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 ® Aggregation Tasks. 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 ® 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 ® Assignment of 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.11 Encryption of Payment Cards

Use

The following options are used for the encryption of payment cards:

·Encrypted storage of credit card numbers

·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.

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.12 Roles

1.12.1 Sales Auditor/POS Monitoring

Technical name: /POSDW/SALES_AUDIT

Tasks

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.12.2 POS Inbound Processing Engine (PIPE) Administration

Technical name: /POSDW/ADMINISTRATOR

Tasks

In addition to the /POSDW/SALES_AUDIT role, this role contains administrative activities that should not be

http://help.sap.com/saphelp_nw70/helpdata/en/13/86f741404a212be10000000a155106/content.htm

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