Professional Documents
Culture Documents
Carrying out certain checks (for example, the check for missing receipt numbers) can prove to be difficult in
some situations with real-time individual processing.
1.1.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.
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.
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.
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.
You now have two options:
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
Note, that only the header information of the POS transaction is created and that you must enter additional
details using the POS Workbench editor.
2. Copy Existing POS Transaction
To copy existing POS transactions, highlight one or more POS transactions in the POS Workbench overview and
choose Copy POS Transaction. As a result, the system creates the new POS transactions only in the overview at
first and displays these with the corresponding transaction status. You also have the opportunity to change the
POS transactions using the POS Workbench editor before you create them in the system with Save. Use the
editor just as described in the following section for existing transactions.
3. Change Existing POS Transaction
To change existing POS transactions, highlight one or more POS transactions in the POS Workbench overview
and choose Editor. Alternatively, you can select the POS transaction directly with a double-click. In both cases,
the POS Workbench editor starts.
In the navigation area the system shows you the segments of the selected POS transaction. Highlight a heading
that belongs to one of more segments in the navigation area and the data of all the relevant segments is
displayed in the overview. If you choose a specific segment, the system shows you the data of this segment in
the editor view. Alternatively, you can also highlight a POS transaction in the overview and then click Individual
Segment.
In the change mode of the editor view you have the following options:
○By choosing Copy Entries, you can change the input-ready fields of the chosen segment and accept the
changes that have been made.
○By choosing Reject Changes you can undo changes that have previously been made and revert to the last
version. This is possible, so long as you have not activated the changes using Accept Changes.
○By clicking Save you can save in the system the changes that have already been accepted for the segment
currently shown.
The system automatically performs master data checks after data has been entered. If you have entered
incorrect data, this will be displayed in an error message. For more information, see Automatic Checks.
You can only edit POS transactions so long as you have not successfully performed any associated tasks with
them. As long as this is the case, you cannot make any further changes to the transaction data to avoid
inconsistencies in the system and follow-on systems. If, however, you would still like to make changes to a POS
transaction, then you must first cancel the processed tasks. Only then is it possible again to make changes to
the transaction data.
After you have performed all the changes regarding your POS transaction segments, leave the editor using Back
and you return to the transaction view of the POS Workbench.
1.2.1.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 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.
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.
●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.
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.
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
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.
For more information, see Rules.
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.
●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:
●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.
Alternatively, you can also supply SAP Retail with data by generating aggregates and carrying out the
corresponding outbound processing.
For more information, see Outbound Processing.
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
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.
If the task has been carried out successfully, the system sets the task status for all processed POS transactions
to Completed.
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
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 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.
If the task has been carried out successfully, the system sets the task status for all processed POS transactions
to Completed.
●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 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.
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.
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.
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.
●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 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.
If the task has been carried out successfully, the system sets the task status for all processed POS transactions
to Completed.
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.
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.
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.
Carry out processing of the task for the relevant POS transactions depending on the task type. For more
information, see Task Processing.
Once the task has been carried out successfully, the system sets the task status for all processed POS
transactions to Completed.
1.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 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
You have made the following settings in PIPE Customizing:
●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 Customizing, this takes place in connection with other rules that are
linked.
The processing can deliver the following results for each individual POS transaction:
●The system processes the task and, if appropriate, carries out an operation predetermined by you in the event
of a rule being checked successfully.
●The system does not carry out task processing and places the task in status Ready or Ready to be Canceled.
●The system does not carry out task processing and sets the task status to Error, Error During Cancellation, or
Rejected.
●The system does not carry out task processing and reacts by performing an operation you have predetermined.
For more information, see Rules.
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.
●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.
For more information, see Rules.
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.
The processing can deliver the following results for each individual POS transaction:
●The system processes the task and, if appropriate, carries out an operation predetermined by you in the event
of a rule being checked successfully.
●The system does not carry out task processing and places the task in status Ready or Ready to be Canceled.
●The system does not carry out task processing and sets the task status to Error, Error During Cancellation, or
Rejected.
●The system does not carry out task processing and reacts by performing an operation you have predetermined.
For more information, see Rules.
Based on the result, you can see if the credit card data relating to a POS transaction is in order.
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 -
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
1.12 Roles