based on SAP R/3 Enterprise with Retail Extension
1.10 and SAP BW 3.0b
Customizing Guide Scenario
Store Business Offline (ePOS)
Copyright
©Copyright 2003 SAP AG. All rights reserved.
No part of this publication may be reproduced or transmitted in any form or for any purpose without the express permission of SAP AG. The information contained herein may be changed without prior notice.
Some software products marketed by SAP AG and its distributors contain proprietary software components of other software vendors.
Microsoft®, WINDOWS®, NT®, EXCEL®, Word®, PowerPoint® and SQL Server® are
registered trademarks of Microsoft Corporation.
IBM®, DB2®, DB2 Universal Database, OS/2®, Parallel Sysplex®, MVS/ESA, AIX®, S/390®,
AS/400®, OS/390®, OS/400®, iSeries, pSeries, xSeries, zSeries, z/OS, AFP, Intelligent Miner,
WebSphere®, Netfinity®, Tivoli®, Informix and Informix® Dynamic ServerTM are trademarks of
IBM Corporation in USA and/or other countries.
ORACLE® is a registered trademark of ORACLE Corporation.
UNIX®, X/Open®, OSF/1®, and Motif® are registered trademarks of the Open Group.
Citrix®, the Citrix logo, ICA®, Program Neighborhood®, MetaFrame®, WinFrame®,
VideoFrame®, MultiWin® and other Citrix product names referenced herein are trademarks
of Citrix Systems, Inc.
HTML, DHTML, XML, XHTML are trademarks or registered trademarks of W3C®, World
Wide Web Consortium, Massachusetts Institute of Technology. JAVA® is a registered trademark of Sun Microsystems, Inc.
JAVASCRIPT® is a registered trademark of Sun Microsystems, Inc., used under license for
technology invented and implemented by Netscape.MarketSet and Enterprise Buyer are jointly owned trademarks of SAP Markets and Commerce One.
MarketSet and Enterprise Buyer are jointly owned trademarks of SAP AG and Commerce One.
SAP, SAP Logo, R/2, R/3, mySAP, mySAP.com, and other SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP AG in Germany and in several other countries all over the world. All other product and service names mentioned are the trademarks of their respective companies.
Key:
<XXX> Variable entries 'XXX' Fixed entries [XXX] Pushbutton
Table of Contents
CUSTOMIZING GUIDE STORE BUSINESS OFFLINE (EPOS)...8
1 INTRODUCTION...9
2 PRECONDITIONS...10
3 CUSTOMIZING SETTINGS...11
3.1 General POS Settings...11
3.1.1 Maintain Number Ranges...11
3.1.1.1 Number Range for Ports 11 3.1.1.2 Number Range for IDoc Number 11 3.1.1.3 Number Range for Change Pointer 12 3.1.1.4 Number Range for Status Tracking - Outbound 12 3.1.1.5 Number Range for Document Flow - Inbound 12 3.1.1.6 Number Range for Billing Documents 12 3.1.1.7 Number Range for Accounting Documents 13 3.1.1.8 Number Range for Customers 13 3.1.2 Maintain Settings for ALE...14
3.1.2.1 Define Logical System and Assign To Client 14 3.1.2.2 Define Port for POS Simulation 16 3.1.3 Partner Profiles for Store Communication...18
3.1.3.1 Maintain Partner Profiles 19 3.1.3.2 Activate Change Pointers - Generally 21 3.1.3.3 Activate Change Pointer for Message Types 22 3.1.3.4 Define Change-Relevant Fields 23 3.1.3.5 Activate Infostructures for Update(S120/S121) 24 3.2 POS-Outbound...25
3.2.1 Maintain POS Condition Type Group...25
3.2.2 Maintain Profile for POS Outbound...26
3.2.3 Maintain Outbound Parameters for Outbound Message Types...28
3.2.3.1 Detail Settings Valid for all Parameters 28
3.2.3.2 Merchandise Category Information 30
3.2.3.3 Article Master Data 30
3.2.3.4 EAN References 31
3.2.4.1 Maintain Assortment List Types 36
3.2.4.2 Maintain Assortment List Profile 38
3.2.4.3 Control Data of Assortment List Profile 40
3.2.4.4 Maintain POS Outbound Parameters for Assortment Lists 41 3.2.4.5 Replace Process Technology with Business Workflow (Exceptions) 42
3.2.5 General Workflow Settings...43
3.2.5.1 Perform Automatic Workflow Customizing 43 3.2.5.2 Activate Event Receiver Linkage for IDoc Inbound 44 3.2.6 Configure IDoc Administration...45
3.3 POS Inbound...47
3.3.1 Maintain Profile for POS Inbound...47
3.3.2 Define Checking Rules for POS Inbound...48
3.3.3 Sales as per Receipts...49
3.3.3.1 Control Sales as per Receipts 49 3.3.3.2 Transaction Types for Sales as per Receipts 51 3.3.3.3 Transaction Type-Dependent Control of Sales as per Receipts 52 3.3.4 Aggregated Sales...54
3.3.4.1 Aggregated Sales Control 54 3.3.4.2 Payment List Control 55 3.3.5 POS Goods Movements Control...56
3.3.6 Movement Type-Dependent Control of Goods Movements...57
3.3.7 Transaction Types for Financial Transactions...58
3.3.8 Transaction Type-Dependent Control of Financial Transactions...59
3.3.9 Further Settings for POS Inbound in FI and SD...60
3.3.9.1 Release Number Range for Customers for External Number Assignment 60 3.3.9.2 Define Tolerance Groups for G/L Accounts 61 3.3.9.3 Define Account Key 62 3.3.9.4 Assign Account Keys 63 3.3.9.5 Assign G/L Accounts 64 3.3.10 Maintain Billing Category for Billing Type...65
3.3.11 Maintain Copying Control: Sales Document to Billing Type...66
3.3.12 Settings in Accounting...68
3.3.12.1 Maintain Card Types 70 3.3.12.2 Assign Account Determination Procedures for Credit Cards to Billing Type 71 3.3.12.3 Assign Clearing Account 72 3.3.12.4 Make Central Settings for Payment Cards 73 3.3.12.5 Settlement Control Per Account 74 3.3.13 Pricing Control...75
3.3.13.3 Maintain Pricing Procedures 81
3.3.14 Additional Settings for Production Environment...83
3.3.14.1 Conversions 83 3.3.14.2 Extensions 83 3.3.14.3 Reports and Batch Jobs 83 3.3.14.4 Outbound Processing in Background 83 3.3.14.5 Inbound Processing in Background 83 3.3.14.6 Job Scheduling 84 3.3.15 Change Versions...85
3.3.15.1 Initialization 85 3.3.15.2 Create Change Versions 85 3.3.15.3 Reorganize the Change Pointers 85 3.4 Store Order/Store Order Return...86
3.4.1 Check EDI Partner Profiles for Store Inbound Message...88
3.4.2 Check EDI Partner Profiles for Store Outbound Message...89
3.4.3 Check POS Inbound Profile KASI...90
3.4.4 POS Goods Movements Control...91
3.4.5 Movement Type-Dependent Control of Goods Movements...92
3.4.6 Assign Delivery Type and Checking Rule...93
3.4.7 Assign Document Type, One-Step Procedure, Underdelivery Tolerance...94
3.4.8 Maintain Delivery Type for Store Returns...95
3.4.9 Maintain Delivery Type NLR...96
3.4.10 Define Shipping Conditions...97
3.4.11 Assign Order Type Template to Shipping Point...98
3.4.12 Define Shipping Points...99
3.4.13 Check Assignment Shipping Point to DC...100
3.4.14 Maintain Shipping Point Determination...101
3.4.15 Maintain Storage Location...102
3.4.16 Create Storage Location Automatically...103
3.4.17 Define Rules for Picking Location Determination...104
3.4.18 Assign Picking Locations to Sites...105
3.6 Store Replenishment...114
3.6.1 Preconditions for Replenishment with MM Inventory Management...114
3.6.2 Maintain Replenishment Control...115
3.6.2.1 Number Ranges for Replenishment Run 115 3.6.2.2 POS Inbound Updates (Aggregated Sales and Sales as per Receipt) 116 3.6.2.3 Follow-On Documents (Via Store Order) 117 3.6.2.4 Store Order Control 118 3.6.2.5 Aggregated Sales Control 120 3.6.2.6 Availability Check Control 122 3.6.3 Special Settings (Optional)...124
3.6.3.1 Maintain Rounding Profiles 124 3.7 Error Messages in Inbound...126
3.7.1 Inbound Parameters...126
3.7.2 Outbound Parameters...128
3.7.3 Create a Message (no Customizing)...129
3.8 Goods Movements...130
3.8.1 Store Goods Receipt...131
3.8.1.1 Control Store Goods Receipt 131 3.8.2 Movement Type-Dependent Control of Goods Movements...132
3.8.3 Goods Movements Control...134
3.9 Coupon & Bonus Buy...135
3.9.1 Preconditions...135
3.9.2 Maintain Outbound File in File Port...135
3.9.3 Maintain EDI Outbound Parameters...136
3.9.4 Activation of Bonus Buy...137
3.9.5 Maintain Condition Types...138
3.9.6 Define and Assign Account Key...139
3.9.7 Assignment of Condition Type to Pricing Procedure...140
3.9.8 Define Coupon Profiles...141
3.10 Workflow Customizing...142
3.10.1 Store Order, New WF...145
3.10.2 Store Order, Old WF...146
3.10.3 Store Goods Receipt (New Workflow, as of 4.6A)...147
3.10.4 Store Goods Receipt (Old Workflow)...148
1 Introduction
This Customizing guide outlines the settings required to carry out the standard activities involved in store business.
For the sake of clarity, the settings are discussed together with the relevant processes. This document describes the following scenarios and the Customizing settings for the processes they involve. Reference is made to any industry-specific Customizing settings that apply for the individual processes.
POS outbound
o Merchandise category information o Article master data
o Control data o Customer data o Exchange rates o Follow-on items o Set articles
o Bonus buys & coupons o Promotion discounts o Assortment lists POS inbound o Sales o Payment lists o Cashier statistics o Error messages
o Store physical inventories o Store orders/returns o Store replenishments o Store goods movements o Bonus buys & coupons
2 Preconditions
The preconditions for the individual processes are specified in the relevant section of the process description.
3 Customizing Settings
Highest Business Configuration (BC) Set node: /BPR3R/SCS_EPOS
3.1 General POS Settings
3.1.1 Maintain Number Ranges
Hierarchy BC Set (1): /BPR3R/NR_KREISE
Number ranges are the prerequisite for creating documents in the SAP system. SAP also provides number range intervals. For some number range objects, the standard number ranges can be used. For documents such as billing documents, customer-specific number ranges have to be defined, depending on the volume of documents. The number ranges must be maintained in each client. They cannot be transported.
SNUM is the central transaction for maintaining number ranges.
3.1.1.1
Number Range for Ports
Ports can be identified uniquely by means of internal numbers. The system can only generate the numbers if a number range interval has been entered for the number range object EDIPORT.
Check whether a number range interval exists for the number range object EDIPORT (generated port name) by choosing:
IMG SAP Web Application Server Application Link Enabling (ALE) Sending and Receiving Systems Systems in Network Asynchronous Processing Maintain Ports Define Number Range for Ports
or entering transaction OYSM. BC Set: /BPR3R/NRK_PORT
3.1.1.2
Number Range for IDoc Number
Check whether a number range interval exists for the number range object EDIDOC (EDI number) by choosing:
IMG SAP Web Application Server Application Link Enabling (ALE) Sending and Receiving Systems Systems in Network Asynchronous Processing Define Number Range for IDocs
or entering transaction OYSN. BC Set: /BPR3R/NRK_IDOC
3.1.1.3
Number Range for Change Pointer
Check whether a number range interval exists for the number range object ALE_CP by choosing:
IMG SAP Web Application Server Application Link Enabling (ALE) Modelling and Implementing Business Processes Master Data Distribution Replication of Modified Data Maintain Number Range for Change Pointers
or entering transaction BDCP.
BC Set: /BPR3R/NRK_AEND_ZEIGER
3.1.1.4
Number Range for Status Tracking - Outbound
Check whether a number range interval exists for the number range object W_Download by choosing:
IMG Sales and Distribution POS Interface Outbound Number Ranges, Status Tracking
or entering transaction WC06.
BC Set: /BPR3R/NRK_OUT_STATUS
3.1.1.5
Number Range for Document Flow - Inbound
Check whether a number range interval exists for the number range object “upload update number” (W_UPLOAD_P) by choosing:
IMG Sales and Distribution POS Interface Inbound Number Ranges, Document Flow
or entering transaction WC38.
BC Set: /BPR3R/NRK_IN_BELEG
3.1.1.6
Number Range for Billing Documents
A number range interval is assigned to each billing type. Billing type FP is entered in the POS profile for sales as per receipts and aggregated sales. You assign number range interval 19 to billing type FP by choosing
IMG Sales and Distribution Billing Billing Documents Define Billing Types or entering transaction VOFA.
Choose
The billing type also contains a document type field in which you can assign an FI document type. If the field is blank, document type RV is used. Object: RF_BELEG for PS01, PS0L, AND PS0K
Choose
IMG Financial Accounting Financial Accounting Global Settings Document Document Header Define Document Types
or enter transaction OBA7
to assign number range interval 00 to document type RV.
Choose
IMG Financial Accounting Financial Accounting Global Settings Document Document Number Ranges Define Document Number Ranges
or enter transaction FBN1
to check whether the number range interval for the company code is large enough for the volume of data to be handled.
BC Set: /BPR3R/NRK_FI_BELEGART
3.1.1.8
Number Range for Customers
An anonymous customer (dummy customer) and a number of other customers might have to be created for the POS sale process. Customers are created using master data CATTs. Beforehand, the customer number range object must be released for external number assignment.
If only credit card functionality is to be used at the POS, a customer master is not required, since the clearing house collects the payments. The clearing house is provided with the necessary information via the payment card terminal at the point of sale.
Customers who have payment cards can also be created as customers (debtors) in the central Retail system. The payment card information can also be maintained in this master record. A master data CATT can be used here.
Choose
IMG Financial Accounting Accounts Receivable and Accounts Payable Customer Accounts Master Data Preparations for Creating Customer Master Data Create Number Ranges for Customer Accounts
or enter transaction XDN1
to check the size of the number range.
The suitable number range for the customer is determined using the assignment of the number range to the account group that is used to create the customer.
Hierarchy BC Set (2):/BPR3R/ALE
3.1.2.1
Define Logical System and Assign To Client
The EDI messages are sent to a logical system. A logical system is a system in which applications sharing a common data basis run. In SAP terms, a logical system is a client in a database.
You define the logical system by choosing
IMG SAP Web Application Server Application Link Enabling (ALE) Sending and Receiving Systems Logical Systems Define Logical System.
In the next step, you assign the logical system to the client by choosing
IMG SAP Web Application Server Application Link Enabling (ALE) Sending and Receiving Systems Logical Systems Assign Client to Logical System.
Choose Goto Details
to maintain the location, system description, standard currency, and client role, and to select appropriate settings regarding maintenance authorization for client-dependent and cross-client objects and for protecting data if changes or cross-client copies are made.
NOTE: THE TABLEISCROSS CLIENT.
PRECONDITIONS:
PATH: (SPRO)
IMG SAP Web Application Server Application Link Enabling (ALE) Sending and Receiving Systems Logical Systems Define Logical System
PROCEDURE:
Choose [NEW ENTRIES]. PARAMETER SETTINGS:
Log. System Name of the logical system, such as BEST PRACTICESLOGSYS1 Name Description of the logical system
BACKGROUND:
The logical system is required for the ALE (Application Link Enabling) component. The logical system is the unique name used throughout the company for this client in this database. This is a cross-client setting. It cannot be transported but is maintained in each system by the system
REMARKS:
When maintaining the logical system, note:
The logical system must be unique throughout the company. It must not be used by any other systems in the ALE integrated system.
If a non-initial value has been entered, no further changes to the logical system are allowed in the production system.
If the logical system and the document do not correspond with one another, the system assumes that the document is located in a different system.
Since the logical system setting has to be unique, it cannot be transported, but has to be made manually for each system/client.
BC SET:
3.1.2.2
Define Port for POS Simulation
The following section describes how the file ports are maintained for the sales simulation. Four port categories are available in the standard SAP R/3 System, to which you can assign ‘real’ ports:
Transactional RFC (Remote Function Call) for R/3 – R/3 connections and non-SAP systems
File port
CPI-C for R/2 connections
Internet
Data is exchanged between the Retail system and the converter in IDoc format. The POS interface - outbound stores files on a server in IDoc format (“flat files”). The converter can access this data via the file port and store it in its own database in the form of IDocs. The files on the server are deleted.
PRECONDITIONS:
The RFC destination has been created and the UNIX files for the inbound and outbound files as well as the trigger files have already been maintained, since these are required entries in the port details.
PATH: (WE21)
Tools Business Communication IDoc Basis Administration Port Definition or
IMG SAP Web Application Server Application Link Enabling (ALE) Sending and
Receiving Systems Systems in Network Asynchronous Processing Maintain Ports Port Definition Define Port
PROCEDURE:
Create file port for POS outbound: Select the File folder,
choose [CREATE],
enter the port name, port description, and version.
Here: ‘BEST PRACTICES-POS, Port for POS simulation BEST PRACTICES’ [Outbound File] TABSTRIP File, maintain function module
PARAMETER SETTINGS:
Port for POS outbound: Port: <Name>, Description: <Text>, Version: 'IDoc record types SAP Release 4.x'
TABSTRIP: Outbound File <Name of the individual UNIX file, function module: EDI_PATH_CREATE_POS_UNIX_DOS
TABSTRIP: Outbound: Trigger: File <Name of the individual UNIX file> BACKGROUND:
Messages can only be sent if the port description has been maintained. For the POS interface - outbound, the data is stored in the file system in the form of files. The converter can access the files from here. For the outbound port, only the outbound file and outbound: trigger are
maintained.
In the POS interface - inbound, files are also contained in a UNIX file. The converter uses a command file to start the C program STARTRFC, which in turn calls up a function module EDI_DATA_INCOMING in the SAP system. The port is one of the parameters specified in this RFC. This is a system port that must follow the naming convention SAP <System name>. This port should also be created as a file port. It only has to exist. Outbound, inbound, and command files are not relevant.
REMARKS:
Created in the BEST PRACTICES using CATT BC SET:
3.1.3 Partner Profiles for Store Communication
For ALE communication, the partners that communicate with one another must be defined with inbound or outbound parameters. The basic conditions for electronic data exchange are defined, in other words, which message is exchanged, how, and in which direction. The partner profile must be set up for each store. Reference stores and an appropriate CATT procedure can be used for this purpose. The message types in the POS interface - inbound must be entered twice: Once for test purposes using the POS simulation (test indicator) and once for production operation.
Enter transaction WE20 or choose:
Tools Business Communication IDoc Basis Administration Partner Profiles or
IMG SAP Web Application Server Application Link Enabling (ALE) Modelling and Implementing Business Processes Partner Profiles and Time of Processing Maintain Partner Profiles Manually.
Since the stores use the “sale” process as well as other processes, such as “physical inventory” and “store order”, the message types required by these processes have also been entered in the partner profile.
You can call up a description of the IDocs as follows: Transaction WE60 Documentation HTML Format
The table below shows the messages that are essential for providing the POS systems with data from the central system.
Message Type
Basic Type
WPDCUR
Download currencies
WPDCUR01
WPDNAC
Download empties
WPDNAC01
WPDSET
Download set assignments
WPDSET01
WPDTAX
Download taxes
WPDTAX01
WPDREB
Download promotion rebates
WPDREB01
WPDWGR
Download merchandise categories
WPDWGR01
WPUBON
Upload sales doc. as per receipt
WPUBON01
WPUERR
Upload messages/error messages
WPUERR01
WPUTAB
Upload cash balancing POS (payment list)
WPUTAB01
WPUUMS
Upload sales aggregated
WPUUMS01
WP_EAN
Upload and download EAN assignments
WP_EAN01
WP_PER
Upload and download customer master data
WP_PER01
WP_PLU
Upload and download article master data
WP_PLU02
3.1.3.1
Maintain Partner Profiles
PRECONDITIONS:
To be able to maintain the parameters for the relevant EDI partners, the header entries must have already been created.
PATH: (WE20)
Tools Business Communication IDoc Basis Administration Partner Profiles or
IMG SAP Web Application Server Application Link Enabling (ALE) Modelling and Implementing Business Processes Partner Profiles and Time of Processing Maintain Partner Profiles Manually
PROCEDURE:
Choose [CREATE]. PARAMETER SETTINGS:
HEADER:
Partner no. M001 (or own site number)
Partn. type KU
Typ US
Agent PRECONF
Lang. EN
Message type Basic type
WBBDLDWBBDLD04 (also suitable for HPR)
WPDCUR WPDCUR01 WPDREB WPDREB01 WPDSET WPDSET01 WPDTAX WPDTAX01 WPDWGR WPDWGR01 WP_EAN WP_EAN01 WP_PLU WP_PLU02 WP_PER WP_PER01
The following settings are always the same:
Receiver port: BEST PRACTICES-POS Output mode: Transfer IDoc immed.
Start subsystem
Syntax check: X
Relevant inbound parameters:
Message type Transaction code
WPUBON WPUB
WPUFIB WPUF
WPUTAB WPUT
WPUUMS WPUU
WPUERR WPUE
The following settings are always the same:
Processing by function module: Trigger immediately
These settings must be made for all stores (M001, M002, M003, M004, M005). BACKGROUND:
The parameters are needed to process inbound and outbound message types. For the inbound IDocs, you always have to maintain two entries - one with and one without a test indicator. The test indicator is needed for the POS simulation.
3.1.3.2
Activate Change Pointers - Generally
PRECONDITIONS:
PATH: (BD61)
IMG SAP Web Application Server Application Link Enabling (ALE) Modelling and
Implementing Business Processes Master Data Distribution Replication of Modified Data Activate Change Pointers - Generally
PROCEDURE:
Set indicator
PARAMETER SETTINGS:
None
BACKGROUND:
This is the basic setting that enables change management to be used throughout your system. REMARKS:
Change management enables you to control which changes from your central R/3 System are to be sent to your stores in the form of change messages.
BC SET:
3.1.3.3
Activate Change Pointer for Message Types
PRECONDITIONS:
Change pointers have been activated (generally). PATH: (BD50)
IMG SAP Web Application Server Application Link Enabling (ALE) Modelling and
Implementing Business Processes Master Data Distribution Replication of Modified Data Activate Change Pointers for Message Types.
PROCEDURE:
Set indicator for message type (for example, WP_PLU). PARAMETER SETTINGS:
None
BACKGROUND:
In addition to activating change pointers/documents globally, you define explicitly whether they are to be generated for each message type.
REMARKS:
BC SET:
3.1.3.4
Define Change-Relevant Fields
PRECONDITIONS:
Change pointers have been activated for the message type. PATH: (BD52)
Tools ALE ALE Development IDoc Engineering Change Management Define Change-Relevant Fields
PROCEDURE:
Enter the message type (such as WP_PLU). PARAMETER SETTINGS:
Find the entries for the relevant table and add the missing table field. BACKGROUND:
You can use this function to decide which fields are to be considered for the change pointers and which fields are to be excluded.
REMARKS:
BC SET:
3.1.3.5
Activate Infostructures for Update(S120/S121)
PRECONDITIONS:
PATH: (MCH6)
Logistics General Logistics Information system (LIS) Logistics Data Warehouse Updating Updating Control Activate Update Retailing (RIS)
PROCEDURE:
Select the infostructure (120 bzw. 121) and press BUTTON [DETAIL]. PARAMETER – SETTINGS:
In the Popup [Parameter] Subscreen [Update] select ‚Asynchronous Update (2)’ BACKGROUND:
So you activate the update of POS sales. REMARKS:
BC SET:
3.2 POS-Outbound
Hierarchie BC Set(3): /BPR3R/POS_OUT
3.2.1 Maintain POS Condition Type Group
In this step, you group the condition types that are sent to the POS systems and assign them to the outbound profile. Before doing so, you have to maintain the condition types that are to be analyzed and transferred to the POS system by choosing
IMG Sales and Distribution Basic Functions Pricing Pricing Control Define Condition Types
or by entering transaction V/06.
The POS condition type group remains set to standard group SAPD with the relevant condition types (VKP0, VKA0, MWST, MWSI) that are to be downloaded.
IMG Sales and Distribution POS Interface Outbound Maintain POS Condition Type Group
Select condition type group ‘SAPD’.
Double-click the POS condition type group.
These are the condition types for sales price, promotion sales price, and value-added tax that are shipped with the standard system.
NOTE: Only the condition types that are contained in the condition type group are transferred to the POS system.
3.2.2 Maintain Profile for POS Outbound
The POS outbound profile determines how the data to be transferred in the POS interface – outbound is processed, in other words, which data is to be transferred, with what lead time, how errors are handled, and so on.
PRECONDITIONS:
You have maintained the number range, status tracking for downloads to stores, as well as the condition group SAPD by choosing IMG Sales and Distribution POS Interface Outbound. PATH: (SPRO)
IMG Sales and Distribution POS Interface Outbound Maintain Profiles for POS Outbound
PROCEDURE:
Copy the standard POS outbound profile SAPD as POS outbound profile KASI: To do so, select SAPD, choose Edit Copy As, and enter KASI.
Then select KASI, choose 'Goto Details', and maintain the appropriate settings. PARAMETER SETTINGS:
Conversion Category: SAPD
Lead Time: 5
Exch. Rate Type: M
Cond. Type Group: SAPD
Automatic Data Interchange: Select
BACKGROUND:
The POS outbound profile controls how the data, such as prices and conditions, is downloaded. The data that is not required in the POS systems in the stores can be “deactivated” here so that it is not prepared.
REMARKS:
The standard POS outbound profile SAPD should not be changed. BC SET:
/BPR3R/SD_POS_PROFIL_OUT
the reference site.
The POS outbound profile ‘KASI’ is assigned to the sites. A master data CATT is available for creating the sites. You can display the entered POS outbound profile from the SAP menu as follows:
PATH SAP Menu Logistics Retailing
Master Data Site Data Site
Display WB03 ENTER Site ‘M001, ... M005’ BUTTON [ENTER] TABSTRIP [POS] BUTTON 2 X [BACK]
3.2.3 Maintain Outbound Parameters for Outbound Message Types
The outbound parameters are described here as examples for the BEST PRACTICES store M001.
The only settings that vary are those for the message type and the related IDoc type.
3.2.3.1
Detail Settings Valid for all Parameters
These settings are the same for all subsequent parameters and are, therefore, only described once.
PRECONDITIONS:
The store has already been created as a header entry in the partner profiles. The POS outbound profile has been created and assigned to the store. PATH:
Tools Business Communication IDoc Basis Administration Partner Profiles or
IMG SAP Web Application Server Application Link Enabling (ALE) Modelling and Implementing Business Processes Partner Profiles and Time of Processing Maintain Partner Profiles Manually.
PROCEDURE:
Choose:
Partner type ‘KU’,
such as ‘M001’ or a different store, [Create outbound parameter] BUTTON PARAMETER SETTINGS:
Message type: Depends on the message
The same for all message types:
Receiver port: BEST PRACTICES-POS ‘Output Mode’ subscreen:
Transfer IDoc immed.
SAP reserves a specific message type for each form of message transfer in the POS interface - outbound. Messages can only be transferred if an outgoing entry has been maintained for each message type in the partner profiles for the stores.
In the POS interface - outbound, a trigger file is created for each outgoing message generated, and stored in a system file. This trigger file contains information about the generated messages and the storage location from which the converter can retrieve them.
REMARKS:
For performance reasons, it might make sense to collect message types that have to be
transferred frequently, such as article master data, and then send them in an IDoc. All outgoing messages must be collected before they are transferred.
BC SET:
3.2.3.2
Merchandise Category Information
The system provides merchandise category information in two different ways:
It only transfers the merchandise categories that are explicitly assigned to the target store and that are not excluded from the transfer. You can make appropriate settings in the site maintenance transaction.
The system transfers all merchandise categories. For this purpose, settings must have been made in the target store’s POS outbound profile to specify that the sales for this store involve all merchandise categories.
PARAMETER SETTINGS:
Message Type: WPDWGR Basic Type: WPDWGR01
3.2.3.3
Article Master Data
The object is time dependent.
This object is one of the POS outbound objects that can be reduced using the ALE layer. The newly created, reduced message type must be entered in the store’s POS outbound profile.
The following subobjects belong to the Article object: Master data
Article texts (article short texts and cash register receipt texts)
Article conditions (such as sales and promotion sales prices) including price scales Free-goods discounts
Tax codes
PARAMETER SETTINGS:
Message Type: WP_PLU Basic Type: WP_PLU 02
Path: BD52
Tools Application Link Enabling (ALE) ALE Development IDoc Engineering Change Management
Procedure:
Enter message type WP_PLU and press [ENTER]. Choose [NEW ENTRIES].
Parameter:
Object: WLK1 Table Name: WLK1 Field Name: SSTAT
Choose [ENTER] and confirm the message that then appears. You can then save your data by pressing F11.
The system outputs a message informing you that your data has been saved.
This entry means that the status field will be considered in future change analyses and the appropriate change message is generated for the download.
3.2.3.4
EAN References
The EAN references are separated from the article master so that the POS does not have to carry a complete master record for each EAN.
The EAN references of an article are only transferred to the POS systems if the article belonging to it meets the conditions for transferal and if at least one additional EAN exists for the main EAN of the article.
PARAMETER SETTINGS:
Message Type: WP_EAN Basic Type: WP_EAN01
3.2.3.5
Set Article
The following conditions must be met before a set article can be transferred to the POS systems:
The set article must be managed in the store during the preparation period (validity period for sales in the store; valid WLK2 record).
The set article must have already been listed in the store.
If the merchandise category of the set article has been assigned to the store, the merchandise category must not be explicitly excluded from the transfer to this store. The set article must have a main EAN.
The set article must have set components.
PARAMETER SETTINGS:
Message Type: WPDSET Basic Type: WPDSET01
3.2.3.6
Empties
The preconditions for transferring set articles also apply for transferring empties. PARAMETER SETTINGS:
Message Type: WPDNAC Basic Type: WPDNAC01
3.2.3.7
Currencies
All the exchange rates for a configurable exchange rate type can be prepared for the local currency of a store.
PARAMETER SETTINGS:
Message Type: WPDCUR Basic Type: WPDCUR01
No change pointers are generated when changes are made. After a change is made, a realignment run always triggers an initialization, which means that all the exchange rates for
3.2.3.8
Tax
The system always fully transfers the tax rates of the country to which the store belongs. Any time-dependent taxes are not transferred. This applies in particular to taxes in the USA. Time-dependent taxes are usually processed using a separate software solution.
PARAMETER SETTINGS:
Message Type: WPDTAX Basic Type: WPDTAX 01
3.2.3.9
Customer Master Data
This object is one of the POS outbound objects that can be reduced using the ALE layer. The newly created, reduced message type must be entered in the store’s POS outbound profile.
The following subobjects belong to the Person data object: Credit limits
Master data (address data) Credit card information Bank details
PARAMETER SETTINGS:
Message Type: WP_PER Basic Type: WP_PER01
3.2.3.10 Bonus Buys & Coupons
The following subobjects belong to the Bonus Buys object: Header information for bonus buys
Condition targets
Prerequisites (header and item) for bonus buys Conditions (header and scales)
Short text Long text
The POS systems can consider the data transferred by analyzing all the articles scanned in one transaction to determine whether the articles are being purchased in the relevant combination. If so, the special offer is granted.
The system can only distribute the information on bonus buys using a direct request. Realignment runs are not possible.
Use transaction VBK6 to delete bonus buys. Once you have deleted the bonus buys from the SAP system, you can start report BBY_POS_DELETE to create deletion records for the POS systems concerned. If you are expecting a lot of deletion records, do not run the program online. Plan it to run daily in the background.
PARAMETER SETTINGS:
Message Type: WPDBBY Basic Type: WPDBBY01
3.2.3.11 Promotion Rebates
PARAMETER SETTINGS:
Message Type: WPDREB Basic Type: WPDREB01
3.2.3.12 Condition Type for Promotion Rebate
Path:
IMG Logistics - General Retail Promotion Control for Condition Tables for Promotion Discount
Procedure:
[NEW ENTRIES] BUTTON
Parameters:
Condition Type: KA02 Organizational Level: 02 (Site)
Article DiscntLevel: 02 (Merchandise category) Table: 4 (Article)
[SAVE] BUTTON Remarks:
This entry is required in order to specify a condition in a promotion at merchandise category level. When the promotion discounts are downloaded, only a condition that is higher than article level is considered. Article IDoc WP_PLU provides information on promotion conditions at article level. BC Sets:
3.2.4 Assortment List
An assortment list can be easily tailored to your individual company requirements. The most important part of an assortment list is the “assortment list message”, which involves retrieving and preparing article-related data. After a message has been prepared, it can be sent directly to other systems. Messages created in the assortment list function are structured as intermediate documents (IDocs) with segment hierarchy. The intermediate document provides the interface to other systems.
Preconditions
The EDI partner profiles must be maintained for each store in the central system. The appropriate message must also be set for the assortment list in the outbound parameters of the partner profiles.
Rather than using the standard POS outbound profile for transferring the assortment list, a separate profile is used to generate the assortment list. This profile is maintained in the site master data in the same way as the POS outbound profile.
3.2.4.1
Maintain Assortment List Types
In this step, you define your assortment list types. You can store a time management setting for each assortment list type. This setting determines the format of the lists. The assortment list type is assigned to the relevant article in the article master (transaction MM42).
The time management setting includes the Lead time
Cycle for generating change versions
Number of change versions until the next complete version of the assortment list is created
PRECONDITIONS:
Your R/3 System is configured as an SAP Retail System.
PATH:
IMG LOGISTICS - GENERAL ASSORTMENT ASSORTMENT LIST ASSORTMENT LIST TYPES
PROCEDURE:
Copy SAP reference object 0001 and call up the transaction for maintaining the assortment list parameters for the new assortment list profile.
PARAMETER SETTINGS:
AListType Description Lead Tm AL Cycle, Change Vers. No. of Change Vers.
7 Food - BEST PRACTICES 2 5 3
8 Fashion - BEST PRACTICES 3 7 4
9 Hard goods - BEST PRACTICES 3 14 4
BACKGROUND:
Assortment lists are generated for each plant and assortment list type. Precondition: The assortment list type has been assigned to the material.
REMARKS:
As is the case with material types, you should only create a few assortment list types. BC SET:
/BPR3R/POS_SLART
Settings for Old POS Systems
Lead Time AL Cycle, Change Vers. No. of Change Vers.
0 1 Max. (32xxx)
After the full version (from the initialization) has been created, these POS systems can only store the change data for one day and, therefore, require a change version each day. Changes with a validity date in the future (1 day + x) cannot be held.
Settings for More Recent POS Systems
Lead Time AL Cycle, Change Vers. No. of Change Vers.
0 x (any) Max. (32xxx)
Here, you can choose a longer cycle for the change versions, since changes that become valid at a future date can also be considered (stored).
Settings for Fashion
Lead Time AL Cycle, Change Vers. No. of Change Vers.
90 x (any) Max. (optional)
For the FASHION scenario in particular, it might be worth notifying the store of data well in advance. The lead time (future period) here is set to 90 days, for example. This enables the store to be notified well in advance (for example, 3 months in advance) of particular
3.2.4.2
Maintain Assortment List Profile
In this step, you maintain assortment list profiles and their parameters. Definition
An assortment list profile is used to group control parameters for generating assortment lists.
It can be used for more than one plant.
Each plant can be assigned an assortment list profile.
The assortment list profile parameters control the appearance of assortment lists and how they are generated for each assortment list type. They determine:
Whether IDocs are generated for electronic transfer of data Whether the data is stored in assortment list version management How the materials are sorted
Which data is prepared
The appearance of an assortment list line PRECONDITIONS
Your R/3 System is configured as an want to reduce the data, first maintain the reduction for the logical message category 'WBBDLD' in the assortment list.
If you are using your own structure for the assortment list line, it must be created beforehand in the ABAP Dictionary.
Nevertheless the reduction field has to be filled. Not using a reduction of your own you fill in the field with standard message type WBBDLD.
PRECONDITIONS:
PATH:
IMG Logistics - General Assortment Assortment List Maintain Profile for Assortment Lists
PROCEDURE:
Copy SAP reference object 0001 and call up the transaction for maintaining the assortment list parameters for the new assortment list profile.
PARAMETER SETTINGS:
AListType Description
7 Food - BEST PRACTICES 8 Fashion - BEST PRACTICES 9 Hard goods - BEST PRACTICES BACKGROUND:
Make an entry for all combinations of assortment list type and assortment list profile for which you want to generate assortment lists.
REMARKS:
We recommend you only maintain a few assortment list profiles.
Plants with the same assortment list profile can be managed with better performance when the assortment list is generated.
BC SET:
3.2.4.3 Control Data of Assortment List Profile
PATH:
IMG Logistics - General Assortment Assortment List Maintain Profile for Assortment Lists
PROCEDURE:
Select assortment list profile 0006 and double-click the assortment list profile parameters folder. This calls up the detail settings for a particular assortment list type.
PARAMETER SETTINGS:
BACKGROUND:
In this step, you make detailed settings to specify how individual assortment types are to be handled in your assortment list profile, for example, how the assortment list is to be sent. REMARKS:
You can maintain different settings for the various assortment list types within one particular assortment list profile.
The settings here are identical for all assortment list types.
This also improves performance if your sites can only be supplied with assortment messages by means of one or very few assortment list profiles.
BCSET:
3.2.4.4
Maintain POS Outbound Parameters for Assortment Lists
PRECONDITIONS:
The stores have already been maintained as EDI header entries of partner type ‘KU’. PATH:
Tools Business Communication IDoc Basis Administration Partner Profiles or
IMG SAP Web Application Server Application Link Enabling (ALE) Modelling and Implementing Business Processes Partner Profiles and Time of Processing Maintain Partner Profiles Manually.
PROCEDURE:
Create (in Best Practices already done via CATT) PARAMETER SETTINGS:
HEADER:
Partner no. M002 (Store with internal billing)
Partn. type KU
Typ US
Agent PRECONF
Lang. EN
Test: ‘BLANK’
Message type Receiver port
WBBDLD BEST PRACTICES-POS Output mode:
4, Collect (optional but better performance) Subsystem: Start or do not start
This setting is only relevant for production operation. It depends on the type of POS system.
IDoc type:
WBBDLD01 BACKGROUND:
Make these settings for all the stores to which you want to send an assortment list message via EDI. You create the outbound parameter for each store. You can create the parameter with a test indicator but are advised against doing so.
REMARKS:
BC Set:
3.2.4.5
Replace Process Technology with Business Workflow (Exceptions)
In Release 4.6, Business Workflow replaces process technology. You need to carry out the following transaction:
IMG SAP Web Application Server Basis Services IDoc Interface/Electronic Data Interchange Replace Process Technology with Business Workflow (Exceptions) (transaction OYSP).
Table changes made during the transaction are not transported, which means that the transaction must be started in every newly set up system. For this reason, a CATT that calls this transaction is recorded.
PRECONDITIONS:
PATH: (OYSP)
IMG SAP Web Application Server Basis Services IDoc Interface/Electronic Data Interchange Replace Process Technology with Business Workflow (Exceptions) PROCEDURE:
Set and execute everything as a general task. PARAMETER SETTINGS:
Test run No
Tasks -> General tasks Yes
Reset express flag Yes
Reset inactive flag Yes
BACKGROUND:
In this section, the error processes for the process technology of Release 2.1 are converted to the standard workflow tasks. The old processes are then no longer supported. In addition, the corresponding standard tasks can be classified as “general tasks”. This means that every SAP user becomes a permitted agent for this task. This ensures that if errors occur, agents defined in the IDoc interface are informed.
BCSET:
IMG Basis Basis Services IDoc Interface/Electronic Data Interchange Perform Automatic Workflow Customizing
or
enter transaction SWU3.
You also make non-transportable settings here.
A CATT starts this transaction in the newly constructed system once.
PRECONDITIONS:
PATH: (SWU3)
IMG Basis Basis Services IDoc Interface/Electronic Data Interchange Perform Automatic Workflow Customizing
PROCEDURE:
Execute the transaction. PARAMETER SETTINGS:
None
BACKGROUND:
In this step, you make basic workflow settings that are a prerequisite for IDoc processing. The workflow runtime system is important. A green checkmark must be set for all subitems. The traffic light then changes to green and the setting is correct.
BCSET:
3.2.5.2
Activate Event Receiver Linkage for IDoc Inbound
To use inbound processing, choose:
IMG SAP Web Application Server Basis Services IDoc Interface/Electronic Data Interchange Activate Event Receiver Linkage for IDoc Inbound
or
enter transaction OYEB.
You also make non-transportable settings here. PRECONDITIONS:
None PATH:
IMG SAP Web Application Server Basis Services IDoc Interface/Electronic Data Interchange Activate Event Receiver Linkage for IDoc Inbound
PROCEDURE:
Execute the transaction. PARAMETER SETTINGS:
None
BACKGROUND:
Inbound IDocs are first saved in the database and then transferred to application-specific inbound processing.
This transfer is triggered by an event, except in the case of port type ‘tRFC’. The processed standard task (the ‘event receiver’) must therefore be linked to this event. The linkage must also be activated.
REMARKS:
BCSET:
3.2.6 Configure IDoc Administration
To configure IDoc administration, choose:
IMG SAP Web Application Server Basis Services IDoc Interface/Electronic Data Interchange IDoc Administration
or
enter transaction OYEA.
These global parameters in IDoc system administration do not have an automatic transport connection.
PRECONDITIONS: None
PATH: (OYEA)
Tools Business Communication IDoc Basis Administration IDoc Administration PROCEDURE:
Execute the transaction. PARAMETER SETTINGS:
IDoc administrator
Object type ‘US’
Identification ‘PRECONF’ General IDoc Interface
Max. numbers of syntax errors ‘5’ IDoc inbound from file
Synchronous processing ‘No’ Suppress warnings for status processing ‘No’ Commit after 10,000 data records
BACKGROUND:
IDoc administrator
To define an agent to be informed in the case of an error, the IDoc interface reads the partner profile. If errors occur before the partner profile has been read, the IDoc administrator defined here is informed.
IDoc system environment
The IDoc interface is informed whether or not certain R/3 components used by the interface are available in the system: message control component and applications.
Maximum number of syntax errors
If syntax errors occur when IDocs are sent, these are logged in status records. The maximum number of syntax errors that can be logged as individual status records is specified here. IDoc inbound: synchronous processing?
Once this indicator is set, further inbound processing is triggered synchronously (through the ‘synchronous consumption’ of an event). In this case, the transfer to the interface takes longer than with asynchronous triggering. Note: In the port type ‘tRFC’, the indicator has no effect because inbound processing is not started using the event receiver linkage. Inbox folder for Internet mails
The IDoc interface is connected to the Internet using SAPoffice. For this reason, inbound IDocs are stored in an SAPoffice folder. Suppress error warnings in status processing?
If an incorrect status record is imported from a file in a status confirmation and this indicator is set, no warning is generated. Workflow notifications that are created by the status confirmation and refer to the contents of the status records are not affected by this indicator. After how many data records is a COMMIT WORK to be issued?
As a result of the COMMIT WORK command, IDocs are stored in the database after they have been read from a file. The value affects the performance of data transfer for this port type.
REMARKS:
None BC SET:
3.3 POS Inbound
Hierarchy BC Set : /BPR3R/POS_IN
If you are configuring the POS interface - inbound in your system, refer to composite SAP Note 213546 concerning performance problems in the POS interface - inbound
(release independent).
The following settings have to be maintained for all inbound profiles and are shown here for inbound profile ‘KASI’ as an example.
3.3.1 Maintain Profile for POS Inbound
PRECONDITIONS:
You have maintained the number range document flow for store uploads under IMG Sales and Distribution POS Interface Inbound.
PATH: (SPRO)
IMG Sales and Distribution POS Interface Inbound Maintain Profile for POS Inbound PROCEDURE:
Select SAPD, choose Edit Copy As, and enter KASI.
Copy the standard POS inbound profile SAPD as POS inbound profile KASI. BUTTON [SAVE]
PARAMETER SETTINGS:
None, simply create the entry. BACKGROUND:
In this step, you create the entry for the POS inbound profile. You maintain the appropriate settings in the later sections on aggregated sales, sales as per receipts, the payment list, controlling goods movements, transaction types for sales as per receipts, and financial transactions. The settings for the outbound profile were made in one step, however. REMARKS:
BC SET:
3.3.2 Define Checking Rules for POS Inbound
PRECONDITIONS:
POS inbound profile KASI has been created. PATH: (SPRO)
IMG Sales and Distribution POS Interface Inbound Define Checking Rules for POS Inbound
PROCEDURE:
Choose [NEW ENTRIES].
PARAMETER SETTINGS:
POS inbound profiles: ‘KASI’
Gap analysis type: ‘1’ ...only in current IDoc Duplicate analysis type: ‘1’ ...only in current IDoc Chck rcpt no: ‘X’ set indicator BACKGROUND:
For performance reasons, you should consider setting ‘1 - only in current IDoc’ as the GAP analysis and duplicate analysis types. The more IDocs you include in the two checks, the greater the impact on system performance.
REMARKS:
The receipt number is normally used as a check field for the duplicate analysis. BC SET:
3.3.3 Sales as per Receipts
3.3.3.1
Control Sales as per Receipts
PRECONDITIONS:
Number ranges have been maintained for customers (external number assignment).
The calculation schema (POSBEST PRACTICES) and POS inbound profile KASI have been defined in the system.
PATH: (SPRO)
IMG Sales and Distribution POS Interface Inbound Control Sales as per Receipts PROCEDURE:
Copy standard POS inbound profile SAPD to POS inbound profile KASI. To do so, select SAPD, choose Edit Copy As, and enter KASI.
Maintain the storage location and calculation schema under Goto Details. PARAMETER SETTINGS:
Billing: ‘X’ Set indicator.
You can use this indicator to control how billing is updated.
Update rep.-based IM: ‘X’ Set indicator. Setting this indicator means that the stock changes in replenishment-based inventory management are posted.
Inventory management: ‘X’ Set indicator BW update: ‘X’ Indicator
Anonym. customer: BLANK, which means that the system uses the store customer to post the anonymous sales.
Storage location: ‘0001’
Mov. type: sales: ‘251’
Mov. type: returns: ‘252’
Sales doc. type: ‘OR’
Itm. cat. standard: ‘DLN’
Fbill. type: ‘FP’
Calculation schema: ‘POSPCS’
No. of till receipts: BLANK, this can be used to control whether the sent till receipts are aggregated in R/3 to improve performance by generating fewer follow-on documents. The statistics are still updated for each till receipt.
Condition type: ‘PN10’
Condition type SAP valuation price: ‘PBEW’ Condition type FI valuation price: ‘PBFI’
BACKGROUND:
The settings control the subsequent functions after inbound processing, such as billing, inventory management, and statistics updates. The entered calculation schema controls account
determination in accounting for cash payment. REMARKS:
BC SET:
3.3.3.2
Transaction Types for Sales as per Receipts
PRECONDITIONS:
PATH: (SPRO)
IMG Sales and Distribution POS Interface Inbound Transaction Types for Sales as per Receipts
PROCEDURE:
[NEW ENTRIES] BUTTON Parameter Settings:
Trans.: ‘PTVO’
Description: ‘Voucher handling’
BACKGROUND:
Transaction types enable more finely-tuned control of the individual sales items in the cash register receipt than is provided by the general control functionality for sales as per receipts. The transaction type is a field at item level in the WPUBON IDoc. A transaction type can be used to make different control settings for billing, updates to the Retail Information System, inventory management, the storage location, and so on.
If a transaction type is specified after the relevant article item in the IDoc, the system refers to these control settings. In this case, we require a transaction type for voucher processing. You only define the transaction type here.
REMARKS:
You only make the header entry here. BC SET:
3.3.3.3
Transaction Type-Dependent Control of Sales as per Receipts
PRECONDITIONS:
POS inbound profile KASI and the transaction type for sales as per receipts have been created. PATH: (SPRO)
IMG Sales and Distribution POS Interface Inbound Transaction Type-Dependent Control of Sales as per Receipts
PROCEDURE:
[NEW ENTRIES] BUTTON
POS inbound profile: ‘KASI’ Transaction: ‘PTVO’ PARAMETER SETTINGS:
Inventory management: BLANK Update replen.-based inv. m.: BLANK
Billing: ‘X’ Set indicator
Update statistics: Blank
Storage location: ‘0001’
Reversal till recpt: BLANK
Payment method: ‘X’ Set indicator (important)
Mov. type: Sale: ‘251’
Mov. type: return ‘252’
Special stock: BLANK
BACKGROUND:
The settings enable the general settings for controlling the sales as per receipts to be finely tuned. This means that particular items of the IDoc can be taken from a different storage location or not updated, for example. In the case of vouchers, the payment method indicator is
important. This indicator converts the item to a further negative payment method.
PTVO is defined in the same way as a payment method (see Section 3.13, Pricing Control). In a POS sales, the system determines the article items with the value of condition type PN10 and calculates the value of the net revenue using the calculation schema. It then posts this value as a credit posting minus tax using account key ERL, and posts the condition types for payment methods in the means of payment segment as a debit posting. For vouchers, payment methods are to be posted twice, however: PTCS cash payment as a debit posting as usual and PTVO as a credit posting. This is controlled by the payment method indicator, which handles the item value in the same way as a negative payment method.
REMARKS:
BC SET:
3.3.4 Aggregated Sales
3.3.4.1
Aggregated Sales Control
PRECONDITIONS:
Number ranges have been maintained for customers (external number assignment).
The calculation schema (POSBEST PRACTICES) and POS inbound profile KASI have been defined in the system.
PATH: (SPRO)
IMG Sales and Distribution POS Interface Inbound Aggregated Sales Control PROCEDURE:
Copy the standard POS inbound profile SAPD to the POS inbound profile KASI. To do so, select SAPD, choose Edit Copy As, and enter KASI.
Maintain the anonymous customer, the storage location, and calculation schema under Goto Details.
PARAMETER SETTINGS:
Inventory management: ‘X’ Set indicator
Billing: ‘X’ Set indicator
Update replen.-based inv. m. ‘X’ Set indicator BW update: ‘X’ Set indicator Anonym. customer:
Storage location: ‘0001’
Mov. type: Sale: ‘251’
Mov. type: Return: ‘252’
Sales doc. type: ‘OR’
Item cat. standard: ‘DLN’
Bill. type: ‘FP’
Calculation schema: ‘POSPCS’
Number of items: ‘100’
Condition type: ‘PN10’
Condition type SAP valuation price: ‘PBEW’ Condition type FI valuation price: ‘PBFI’ BACKGROUND:
The settings control the subsequent functions after inbound processing, such as billing, inventory management, and updates in the RIS. The entered calculation schema controls account
determination in accounting for cash payment. REMARKS:
3.3.4.2
Payment List Control
PRECONDITIONS:
Number ranges have been maintained for customers (external number assignment).
The calculation schema (POSPCS) and POS inbound profile KASI have been defined in the system.
PATH: (SPRO)
IMG Sales and Distribution POS Interface Inbound Payment List Control PROCEDURE:
Copy the standard POS inbound profile SAPD to POS inbound profiles KASI, KASN, and PSRS. To do so, select SAPD, choose Edit Copy As, and enter KASI.
Maintain the anonymous customer and the calculation schema under Goto Details. PARAMETER SETTINGS:
Anonym. customer: BLANK Sales doc. type: ‘OR’ Bill. type ‘FP’ Calculation schema: ‘POSPCS’ Condition type : ‘PN10’ Itm cat. payment list: ‘TATX’ Number of items: ‘100’ BACKGROUND:
The settings control the subsequent functions after inbound processing, such as billing, inventory management, and updates in the RIS. The entered calculation schema controls account
determination in accounting.
The payment list is used to send information about the means of payment. It is always used in conjunction with the aggregated sales if “non-smart” POS systems cannot prepare all the detailed information about a sales item.
The item category, which has to be used for payment lists in the billing document to be generated, is of particular importance here. This is item category TATX for text items.
REMARKS:
BC SET:
3.3.5 POS Goods Movements Control
PRECONDITIONS:
POS inbound profile KASI and the transaction type for sales as per receipts have been created. PATH: (SPRO)
IMG Sales and Distribution POS Interface Inbound POS Goods Movements Control PROCEDURE:
BUTTON [NEW ENTRIES] PARAMETER SETTINGS:
POS inbound profiles: ‘KASI’ Subscreen: Process Control
PO search: ‘Termination after first criterion: PO number’ PO not found: ‘Generate work item for PO search’
Using workflows ‘Activate old workflow...’ BACKGROUND:
If the appropriate purchase order number is not found for a goods receipt IDoc in the store, the system is to send a work item to an agent who can then continue handling the process.
REMARKS:
BC SET:
3.3.6 Movement Type-Dependent Control of Goods Movements
PRECONDITIONS:
POS inbound profile KASI and the transaction type for sales as per receipts have been created. PATH: (SPRO)
IMG Sales and Distribution POS Interface Inbound Movement Type-Dependent Control of Goods Movements
PROCEDURE:
[NEW ENTRIES] BUTTON PARAMETER SETTINGS:
POS inbound profile: Movement type: Rev.mvmt type: KASI 101 102 KASI 102 101 KASI 251 252 KASI 252 251 KASI 301 302 KASI 302 301 KASI 551 552 KASI 552 551 BACKGROUND:
In this step, you can add additional inventory management information to the goods movements sent by the POS systems.
REMARKS:
BC SET:
3.3.7 Transaction Types for Financial Transactions
PRECONDITIONS:
PATH: (SPRO)
IMG Sales and Distribution POS Interface Inbound Transaction Types for Financial Transactions
PROCEDURE:
[NEW ENTRIES] BUTTON PARAMETER SETTINGS:
FI trans.: ‘ABSC’
Description: ‘Cash withdrawals BEST PRACTICES’
BACKGROUND:
With these settings, you define which financial transactions in the store can be transferred using the inbound profile.
You define the transaction types of the financial transactions, which are then specified in the WPUFIB IDoc. You only define the entries here.
REMARKS:
You only make the header entry here. BC SET:
3.3.8 Transaction Type-Dependent Control of Financial Transactions
PRECONDITIONS:
POS inbound profile and the “financial transaction” transaction type have been created. PATH: (SPRO)
IMG Sales and Distribution POS Interface Inbound Transaction Type-Dependent Control of Financial Transactions
PROCEDURE:
[NEW ENTRIES] BUTTON PARAMETER SETTINGS:
Inb. profile: ‘KASI’
FI trans.: ‚ABSC’ Item No.: 1 G/L account: ‘113100’ Posting key: ‘40’ Item No.: 2 G/L account: ‘100000’ Posting key: ‘50’ BACKGROUND:
In this step, you can define how data transferred by your POS systems that contains financial transactions is to be converted to documents for R/3 Financial Accounting.
This control function enables POS systems to transfer only the most basic data on financial transactions to R/3. They do not have to transfer a fully predefined FI document.
Note: If the POS system only sends one item, R/3 automatically creates the second item for the accounting document.
REMARKS:
BC SET:
