store business offline epos en cust v147[1]

Best Practices for mySAP RetailVersion 1.47

based on SAP R/3 Enterprise with Retail Extension 1.10 and SAP BW 3.0b

Customizing Guide Scenario

Store Business Offline (ePOS)

SAP AG

Neurottstrasse 16

69190 Walldorf, Germany

Best Practices for mySAP Retail

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.

Sales Channel Support EPOS Scenario of 151

Key:

<XXX> Variable entries'XXX' Fixed entries[XXX] Pushbutton


Table of ContentsCUSTOMIZING 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.3.5 Set Article 32

3.2.3.6 Empties 32

3.2.3.7 Currencies 32

3.2.3.8 Tax 33

3.2.3.9 Customer Master Data 33

3.2.3.10 Bonus Buys & Coupons 34



3.2.3.11 Promotion Rebates 34

3.2.3.12 Condition Type for Promotion Rebate 35

3.2.4 Assortment List................................................................................................36

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 Type71

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.1 Maintain Condition Types 75

3.3.13.2 Maintain Condition Type for Cash Payment 76

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.4.19 Define Item Category Determination in Deliveries.........................................106

3.5 Store Physical Inventory....................................................................................107



3.5.1 Store Physical Inventory Control...................................................................108

3.5.2 EDI Basic Settings.........................................................................................109

3.5.2.1 Inbound Parameters for Store Physical Inventory 109

3.5.2.2 Outbound Parameters for Store Physical Inventory 110

3.5.3 Allow Freezing of Book Inventory Balance in Storage Location....................112

3.5.4 Activate Info Structure for Physical Store Inventory......................................113

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

3.10.5 Incoming Master Data...................................................................................149



Customizing Guide Store Business Offline (ePOS)



1 IntroductionThis 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 PreconditionsThe 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 RangesHierarchy 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

IMG Sales and Distribution Billing Billing Documents Define Number Range for Billing Documents

or enter transaction VN01

to check whether the number range interval is large enough for the volume of data to be handled.

BC Set: /BPR3R/NRK_FAKTURA



3.1.1.7 Number Range for Accounting Documents 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.



3.1.2 Maintain Settings for ALEHierarchy 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 client copies are made.

NOTE: THE TABLE IS CROSS 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 administrator.



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:

/BPR3R/ALE_LOGSYS_DEF



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[OUTBOUND: TRIGGER] TABSTRIP Maintain file

Create system port for POS inbound:

Select the File folder,choose [CREATE], specify port name, port description, version, and RFC destination.

BEST PRACTICES-RFC / BEST PRACTICES RFC port (EDI) / … SAP Release 4.x / [own



system].

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

NOT POSSIBLE USING BC SETS



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)


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 KUTyp USAgent PRECONFLang. EN



Relevant outbound parameters: 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-POSOutput mode: Transfer IDoc immed.

Start subsystemSyntax check: X

Relevant inbound parameters:

Message type Transaction codeWPUBON WPUBWPUFIB WPUFWPUTAB WPUTWPUUMS 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.

If an appropriate copy rule has been maintained in the site profile, the partner profile is copied over when you create a new site.

Not possible using a BC Set, is created in the BEST PRACTICES using CATT.



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:

/BPR3R/ALE_CH_POINT_ACT



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:

/BPR3R/ALE_CH_POINT_SPEC_ACT



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:

kein Customizing.



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:

/BPR3R/LO_RIS_AKTIV_POS



3.2 POS-OutboundHierarchie 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 OutboundThe 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: SAPDLead Time: 5Exch. Rate Type: MCond. Type Group: SAPDAutomatic 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

and then assign it to the site in the site master.



Prerequisites for entering the POS profile in the site: The site must have been created using 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:


or


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.

Collect IDocs X, mandatory in POS outbound

Start subsystem: X, subsystem start is triggered by R/3 System.

Do not start subsystem: Subsystem actively retrieves the messages itself.

‘IDoc Type’ subscreen:



Basic type: Depends on the message

BACKGROUND:

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:

Maintain the outbound parameters using CATT.



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

Since Release 4.70, a discontinuation status field has been available for message type WP_PLU. If an article is deleted in the next reorganization run (after the discontinuation), it is assigned status 05. The store must be informed of this.

To be able to consider this change in the article master when the change analysis is performed, message type WP_PLU must be informed using transaction BD52 that this status



field is relevant for the realignment run. Only then is a change pointer generated when the status is changed. A change message can then be sent to the store.

Path: BD52

Tools Application Link Enabling (ALE) ALE Development IDoc Engineering Change Management

Procedure:

Enter message type WP_PLU and press [ENTER].


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 the store are downloaded.



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:

/BPR3R/POS_AK_RB



3.2.4 Assortment ListAn 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 TypesIn 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.

Enter the required assortment list types here.


sapevent:DOCU_LINK/DS:TX.ISR_RETAIL_TEXT


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


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


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 changes, such as prices or new articles.



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.

Enter the required assortment list types here.


sapevent:DOCU_LINK/DS:SIMG.OALE_IDOCRED_BD53


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:

/BPR3R/LO_SL_PROF_STORE



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.

BC SET:

/BPR3R/LO_SL_PROF_STORE



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:


or


PROCEDURE:

Create (in Best Practices already done via CATT)

PARAMETER SETTINGS:

HEADER:

Partner no. M002 (Store with internal billing)Partn. type KUTyp USAgent PRECONFLang. EN

Test: ‘BLANK’

Message type Receiver portWBBDLD 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:



MAINTAINED VIA CATT.



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.

BC SET:

Maintained via CATT.



3.2.5 General Workflow Settings

3.2.5.1 Perform Automatic Workflow Customizing

To activate the Business Workflow, choose:

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.

BC SET:

Maintained via CATT.



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:


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:

BC SET:

Maintained CATT.



3.2.6 Configure IDoc AdministrationTo 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:


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:

None



3.3 POS InboundHierarchy 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:

/BPR3R/POS_PROFIL_IN



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:


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:

/BPR3R/POS_IN_PRUEFREGEL



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:

/BPR3R/POS_STRG_BON_UMS



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:


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:

/BPR3R/POS_VART_BON_UMS



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:


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

Itm. cat. standard: ‘DLN’



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:

/BPR3R/POS_VART_STRG_BONUMS



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 indicatorBilling: ‘X’ Set indicatorUpdate replen.-based inv. m. ‘X’ Set indicatorBW update: ‘X’ Set indicatorAnonym. 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:

BC SET:

/BPR3R/POS_STG_VERD_UMS



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

/BPR3R/POS_STG_ZLIST



3.3.5 POS Goods Movements Control

PRECONDITIONS:


PATH: (SPRO)

IMG Sales and Distribution POS Interface Inbound POS Goods Movements Control

PROCEDURE:

BUTTON [NEW ENTRIES]

PARAMETER SETTINGS:


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:

/BPR3R/IN_STEUERG_WARENBWG



3.3.6 Movement Type-Dependent Control of Goods Movements

PRECONDITIONS:


PATH: (SPRO)

IMG Sales and Distribution POS Interface Inbound Movement Type-Dependent Control of Goods Movements

PROCEDURE:


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:

/BPR3R/FIL_STRG_WBW_BWART_ABH



3.3.7 Transaction Types for Financial Transactions

PRECONDITIONS:

PATH: (SPRO)

IMG Sales and Distribution POS Interface Inbound Transaction Types for Financial Transactions

PROCEDURE:


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:

/BPR3R/POS_VART_GELDBW



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:


PARAMETER SETTINGS:

Inb. profile: ‘KASI’FI trans.: ‚ABSC’

Item No.: 1G/L account: ‘113100’Posting key: ‘40’

Item No.: 2G/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:

/BPR3R/POS_VART_STG_GELDBEW



3.3.9 Further Settings for POS Inbound in FI and SDHierarchy BC Set: /BPR3R/POS_IN_FI

3.3.9.1 Release Number Range for Customers for External Number Assignment

PRECONDITIONS:

Settings have been made for the company code in the enterprise structure.

PATH: (XDN1)

IMG Financial Accounting Accounts Receivable and Accounts Payable Customer Accounts Master Data Preparations for Creating Customer Master Data Create Number Ranges for Customer Accounts

PROCEDURE:

[Change Intervals] BUTTONThe indicator for external number assignment must be set for the customer number range object.

PARAMETER SETTINGS:

No. FromNumber ToNumber Ext.01 00000 99999 ‘X’ Set indicator

BACKGROUND:

These settings enable the customer number to be assigned when customers are created.

REMARKS:

Used to create the anonymous store customer and additional customers.

Optional! Yet not used in the Best Practices !

BC SET:

/BPR3R/FI_NKR_DEB_EXT



3.3.9.2 Define Tolerance Groups for G/L Accounts

PRECONDITIONS:

Settings have been made for the company code in the enterprise structure.

PATH: (OBA0)

IMG Financial Accounting General Ledger Accounting Business Transactions Open Item Clearing Clearing Differences Define Tolerance Groups for G/L Accounts

PROCEDURE:

Add missing entries.

PARAMETER SETTINGS:

CoCd Debit Credit PerD PerCPS01 1,000 1,000 50.0 50.0

BACKGROUND:

This setting is a prerequisite for carrying out the settlement run. Absolute and relative tolerances are defined for the company code.

REMARKS:

BC SET:

/BPR3R/FI_TOL_GRP_KTO



3.3.9.3 Define Account Key

PRECONDITIONS:

Path: (OV34)

Customizing Sales and Distribution Basic Functions Account Assignment/Costing Revenue Account Determination Define and Assign Account Keys Define Account Key

PROCEDURE:

[NEW ENTRIES]

PARAMETER SETTINGS:

PPC Cash payment

PPG Voucher

PPS Checks

ERL Sales revenues

MWS Sales tax

BACKGROUND:

The G/L accounts to which postings are to be made are determined using the account key assigned to the condition type.

REMARKS:

Preconfigured account keys are used in the BEST PRACTICES settings. PPC (cash payment), PPG (voucher), and ERL (sales revenues) are all important account keys for cash payments. The amount that is posted to the revenue account is calculated from the sales price entered in the IDoc, taking the VAT into consideration.

BC SET:

/BPR3R/SD_KTO_SCHL



3.3.9.4 Assign Account Keys

PRECONDITIONS:

Path: (OV35)

Customizing Sales and Distribution Basic Functions Account Assignment/Costing Revenue Account Determination Define and Assign Account Keys Assign Account Keys

PROCEDURE:

[NEW ENTRIES]

PARAMETER SETTINGS:

Procedure Step CType ActKey

POSPCS 810 PTCS Payment type – Cash PPC Cash payment POSPCS 811 PTCH Payment type - Check PPS Check payment POSPCS 812 PTVO Voucher PPG VoucherPOSPCS 900 MWSI Output tax MWS Taxes on sls/purch.POSPCS 901 PNET Net value ERL Sales revenues

BACKGROUND:

Depending on the pricing procedure, you then assign the account keys to the condition types

REMARKS:

TIP: You can find the required entry quickly by choosing [Position].

BC SET:

/BPR3R/SD_KTO_SCHL



3.3.9.5 Assign G/L Accounts

PRECONDITIONS:

The account keys have already been created.

Path: (VKOA)

Customizing Sales and Distribution Basic Functions Account Assignment/Costing Revenue Account Determination Assign G/L Accounts

PROCEDURE:

Choose table 005 and assign accounts.

PARAMETER SETTINGS:

App CndTy. Chart of Accounts SOrg. AAG G/L Account No.

V KOFI INT V001 PPS 100102V KOFI INT V001 PPC 100100 V KOFI INT V001 PPG 100001 V KOFI INT V001 ERL 800000V KOFI INT V001 MWS 175000

BACKGROUND:

G/L accounts can be assigned on the basis of various criteria. The type of assignment is determined by means of the account determination table used. In this case, the G/L account is determined on the basis of the sales organization, account determination type, chart of accounts, and account key (corresponds to table 0005 Account Key).

REMARKS:

BC SET:

/BPR3R/SD_KTO_FDG



3.3.10 Maintain Billing Category for Billing Type

PRECONDITIONS:

Billing category FP has been created.

PATH: (VOFA)

IMG Sales and Distribution Billing Billing Documents Define Billing Types Define Billing Types

PROCEDURE:

Choose: Define Billing Types

BillT ‘FP’ – Billing POS Interfce

[Details] BUTTON

PARAMETER SETTINGS:

Billing Category: ‘W’ POS Billing Document

BACKGROUND:

POS billing type FP must be assigned POS billing category W. Otherwise an error message is output in the POS monitor.

REMARKS:

BC SET:

/BPR3R/NRK_FAKTURA



3.3.11 Maintain Copying Control: Sales Document to Billing Type

In a billing document, reference is always made to a reference document. Either the entire document or parts of the document are billed. The billing type used (FP) is predefined in the system. The appropriate billing type is usually proposed on the basis of the reference document category. Although no sales documents are created in inbound processing, you need to make certain “copying control” settings. The default billing type is FP (billing POS interface) for the POS interface. You maintain copying control settings for this billing type as follows:

PRECONDITIONS:

In Customizing for the POS inbound profile, billing type FP, order type OR, and item category DLN have been entered for the control settings for sales as per receipts and aggregated sales, while item category TATX has been entered for the payment list.

PATH: (VTFA)

IMG Sales and Distribution Billing Billing Documents Maintain Copying Control for Billing Documents Copying Control: Sales Document to Billing Document

PROCEDURE:

Position your cursor on target FP and source OR and select the line.Double-click Item in the dialog structure.Select item DLN, check the parameters by choosing [Details], and choose [BACK].Choose [Display -> Change], [Item], and [NEW ENTRIES], and maintain the parameters for TATX.

PARAMETER SETTINGS:

Item Copying reqmts. Billing quantity Pos/Neg quantity Pricing typeDLN 000 C + CTATX 000 C + G

BACKGROUND:

In copying control, you make settings for each sales document type to specify how information is forwarded to the billing documents. Item category TATX is particularly important for the payment list transaction.

REMARKS:

BC SET:

/BPR3R/SD_KOP_STG_FAKTURA



3.3.12 Settings in AccountingThe data on the sales in a store in the store’s POS system is transferred to the central Retail system via the POS interface. Billing in the Sales and Distribution component (SD Billing) is called up here in order to process the sales data. The billing document amounts are transferred to Financial Accounting via an internal interface. The R/3 System posts the amounts to the relevant G/L or subledger accounts using account determination. In the standard SAP system, the billing types are configured in such a way that the pricing conditions are posted in a revenue account (credit side) taking value-added tax into consideration (output tax on the credit side) and an offsetting entry is made in the customer account on the debit side. When postings are carried out in a customer account, the data is posted automatically to the appropriate reconciliation account (domestic receivables) in the general ledger. The offsetting entry can, however, be made in a G/L account instead of a customer account, for example, POS or receivables from payment cards as a debit posting.

The following table lists the G/L accounts that are required for the business case:

SAP Menu Accounting Financial Accounting General Ledger Master Records Individual Processing Centrally

(G/L Account Creation and Processing Edit G/L Account (Individual Processing) Edit G/L Account Centrally)

G/L Account No.

G/L Acc. Long Text

Balance Sheet Account

P&L Statement Acc

Account Group

100100 Petty cash X General G/L accounts

Default acc. from INT

100001 Voucher X Liquid funds account


146500 Credit card receivables

X General G/L accounts


113100 Deutsche Bank (domestic)

X Liquid funds account


113105 Deutsche Bank - other postings

X Liquid funds account


175000 Output tax X General G/L accounts


479000 Bank charges X General G/L accounts


Depending on the payment method and whether you know the customer (whether the customer exists in the SAP R/3 system), various postings are made when the billing document is transferred to Financial Accounting.



Aggregation

Payment Method

Customer Debit Posting Credit Posting

As per receipts

Cash Anonymous 100000 Petty cash 175000 Output tax

800000 Sales revenues - domestic

As per receipts

Debit card

Credit card

Customer card

Anonymous Store customer (such as M001)

146500 Receivables from payment cards

Store customer (such as M001)

175000 Output tax


As per receipts

Debit card

Credit card

Customer card

Known BEST PRACTICES-C101 Customer with customer card

146500 Receivables from payment cards

BEST PRACTICES-C101 Customer with customer card

175000 Output tax


As per receipts

Customer card

(retailers collect money themselves)

Known BEST PRACTICES-C101 Customer for posting to customer account

175000 Output tax


Aggregated None Anonymous Store customer (such as M001)

175000 Output tax


Payment list

Cash Anonymous 100000 Petty cash BEST PRACTICES-C100 Anonymous store customer

The accounts used are standard accounts from the INT chart of accounts. An individual account can, of course, be created for any type of card (American Express, Visa and so on) for the charges and receivables using a standard account as a template.

The numerous open items from card payments that are included in G/L account 146500 “Receivables from payment cards” can be settled using transaction WPCA and transferred to clearing houses. Offsetting entries are created for the open items in the credit account and one posting is made to the debit side of the clearing account (113105, Bank 1, interim posting). The incoming payment can be posted to the bank account (113100) taking discounts into consideration (479000 expenses for money transactions) for this cash clearing account. The credit card institute stipulates a discount (markdown) when a credit card is used for payment. This means that the retailer receives the amounts from the credit card institute that the customer has to pay minus the discount. As the retailer is taking advantage of the payment by the credit card institute with the discount, the retailer is usually subject to VAT. If a debit card is used as payment, the banks and saving institutions repay



the complete amount. The charges are calculated in a separate invoice, which is later posted to expenses as an incoming invoice.

3.3.12.1 Maintain Card Types

PRECONDITIONS:

PATH: (SPRO)

IMG Sales and Distribution Billing Payment Cards Maintain Card Types

PROCEDURE:

Add missing card types.[NEW ENTRIES] BUTTON

PARAMETER SETTINGS:

Card Type Description

DIN Diners cardKK Customer cardEC Electronic cashAMEX American ExpressVISA Visa CardMC Master Card

BACKGROUND:

This information about the card type can be specified in the IDoc and used as selection criteria for reports in the RIS.

REMARKS:

BC SET:

/BPR3R/SD_KART



3.3.12.2 Assign Account Determination Procedures for Credit Cards to Billing Type

PRECONDITIONS:

Billing type FP has been maintained in the POS interface - inbound.

PATH: (SPRO)

IMG Sales and Distribution Billing Payment Cards Authorization and Settlement Maintain Clearing House Account Determination Maintain Procedures Assign Account Determination Procedures

PROCEDURE:

Assign an account determination procedure to the billing type for the POS interface (FP).

PARAMETER SETTINGS:

BillT ADPyCdFP A00001

BACKGROUND:

The account determination procedure determines the reconciliation account (account in which the receivables are posted to the clearing house, such as 146500). The account determination procedure is a pricing procedure for account determination for payment cards. It contains condition type A001, which refers to the access sequence of the same name. You can display the access sequence in transaction 0V84.

REMARKS:

BC SET:

/BPR3R/SD_ZKART_SCHEMA



3.3.12.3 Assign Clearing Account

PRECONDITIONS:

Settings have been maintained for the company code, in particular the chart of accounts.The account determination procedure has been assigned to the billing type.

PATH: (SPRO)

IMG Sales and Distribution Billing Payment Cards Authorization and Settlement Maintain Clearing House Account Determination Assign G/L Accounts Table 4 - General

PROCEDURE:

Specify a reconciliation account (G/L account) for each sales organization.

PARAMETER SETTINGS:

Appl. CandTy Charts of Accounts SOrg. G/L AccountVD A001 INT V001 146500

BACKGROUND:

In this step, you assign the appropriate card types the accounts to which the open items to be settled to the clearing house are posted.

REMARKS:

In this case, only one account from chart of accounts INT is assigned to the various card types. If a settlement is carried out, the card type is specified as an additional selection criterion. Table 6, however, enables you to specify different G/L accounts for each card type, if a particular volume of receivables is reached. If you are working with different clearing houses, you have to specify an account for each clearing house, since a logical destination for the data transfer is assigned to each clearing house.

BC SET:

/BPR3R/SD_ZO_KTO_ZKART



3.3.12.4 Make Central Settings for Payment Cards

PRECONDITIONS:

The customer who is paying by card has been maintained in the system.

PATH: (SPRO)

IMG Financial Accounting Accounts Receivable and Accounts Payable Business Transactions Payments with Payment Cards Make Central Settings for Payment Cards

PROCEDURE:

Maintain settings to determine whether the customer line item is to be retained in the accounting document.

PARAMETER SETTINGS:

‘Settings for Forwarding Billing Documents to FI’ subscreen

Retain cus. item: ‘X’ Set indicator

‘Settings for the Settlement Document’ subscreen Document type: ‘AB’

‘Settlements for Resetting Clearing when Settlement Unsuccessful’ subscreen

Document type: ‚AB’

BACKGROUND:

You specify whether the posting to customer account is to be retained for your customer who is paying by card. The open item in the document is cleared immediately and an open item is created in the clearing house’s G/L account instead (receivables from payment cards).

In addition you specify the document type for settling payment card data to the clearing house.

REMARKS:

Although more database space is needed if this indicator is set (due to more line items), you have the advantage of being able to display receivables on the debit side and being able to deal with any settlement problems more easily.

BC SET:

/BPR3R/FI_ZKART



3.3.12.5 Settlement Control Per Account

PRECONDITIONS:

The customer who is paying by card has been maintained in the system.

PATH: (SPRO)

IMG Sales and Distribution Billing Payment Cards Authorization and Settlement Maintain Clearing House Set Authorization / Settlement Control Per Account

PROCEDURE:

PARAMETER SETTINGS:

ChAc Receivable Clearing

INT 146500 113105

Choose [Details].

‘Authorization Control Functions’ subscreen

Authorization: CCARD_AUTH_SIMULATION

‘Settlement Control Functions’ subscreen

Settlement: CCARD_SETTLEMENT_SIMULATION

BACKGROUND:

REMARKS:

You do not need to maintain any further settings here, since the standard settings for chart of accounts INT are used.



3.3.13 Pricing Control

3.3.13.1 Maintain Condition TypesThe sales price and the payment methods are set as condition types in the IDoc. These fields are filled by the converter, which also performs calculations if necessary. Condition types have to be maintained for this purpose. Condition types are one element of the standard pricing activities. They can be created for all types of pricing element, such as prices, markups and markdowns, tax, and so on. For the individual pricing elements and conditions, standard SAP condition types can be used or new ones defined to suit company requirements.

Conditions represent a set of circumstances that apply when a price is calculated. The variable factors, such as the customer, product, and so on, determine the final price. This information is stored in the system as condition records in condition tables. Several condition records usually exist for each condition type.

A pricing procedure defines the valid condition types and the sequence in which they are calculated. An access sequence can be assigned to each condition type. An access sequence is a search strategy that the system uses to find valid records in a condition table. The names of the access sequences often correspond to the condition types for which they were designed. The system repeats this process for each condition type in the pricing procedure and determines a final price.

Condition types can be determined using automatic pricing, or set manually. Condition records must already exist for all the condition types that the system is to use automatically. These are maintained in the customer/material master record. In Customizing, you make precise settings for each condition type to define the extent to which manual changes can be made.

In this ‘sales’ process, the condition types are set manually (by the converter).

Important condition types for the process:

Payment method for cash payment (PTCS)

Payment method for voucher (PTVO)

Payment method for customer card (PTBL) if postings are to be made directly to the customer (payment by invoice to customer).

Sales price (PN10)

Item discounts (RB10, RB19)

Header discounts (HB00)

Net value (PNET)



3.3.13.2 Maintain Condition Type for Cash Payment

PRECONDITIONS:

Condition type PTCS already exists. You just need to define the condition category for this type.

PATH: (V/06)

IMG Sales and Distribution Basic Functions Pricing Pricing Control Define Condition Types Maintain Condition Types

PROCEDURE:

Change the settings for the existing condition type PTCS. Position your cursor on PTCS by choosing [Position]. Select the row, choose [Details], check the parameters, and add the condition category (lower case).

PARAMETER SETTINGS:

Cond. Type

Cond. Class Calc. Type Cond. Category Group Cond. Manual Entries Plus/Minus Header Condit. Item Condition

PTCS

A B g X Blank X X Blank

BACKGROUND:

Condition type PTCS is required in pricing procedure POSPCS for pricing and for determining the accounting account for the POS using an account key assigned to the condition type.

REMARKS:

BC SET:

/BPR3R/SD_KOND_ART

Discounts can also be transferred and the VAT calculated for domestic sales.

To maintain the condition types, choose:

Customizing Sales and Distribution Basic Functions Pricing Pricing Control Define Condition Types Maintain Condition Types

or enter transaction V/06.

The standard system already contains the required condition types and their settings. It is only for the means of payment that you have to define the condition category (lower case).

INFO : SAP contains further payment methods for checks (PTCH).

To go straight to the required condition type, choose [Position].

The following condition types must be maintained:



Payment Method Cash (PTCS) and Voucher (PTVO)

Access sequence No

Condition class A Discount or surcharge

Calculation type B Fixed amount

Condition category g Payment

Rounding rule Commercial

Header condition X

Item condition No

Group condition X

Plus/minus X Negative

Manual entries No limitations

Payment method, in which postings are made directly to the customer (PTBL).

If you want to make postings to a customer card on the debit side, you can either use payment method PTBL or not transfer a means of payment, which means that the system automatically posts the amounts that are not covered by the means of payment to the customer.

Access sequence No



Condition category


Header condition X

Item condition No

Group condition X

Plus/minus X Negative




Sales Price (PN10)

Access sequence No



Condition category H Basic price


Header condition No

Item condition X

Group condition No

Plus/minus Positive and negative


Net Value (PNET)

Access sequence No


Calculation type G Formula

Condition category L Generally new when copying


Header condition No

Item condition X

Group condition No


Manual entries D Not possible to process manually



Output Tax (MWSI)

The system determines the VAT using tax codes. You cannot specify VAT amounts manually.

Access sequence MWST Value-added tax

Condition class D Taxes

Calculation type H Percentage included

Condition category D Tax


Header condition No

Item condition X

Group condition X


Manual entries D Not possible to process manually

Group cond. routine 0

RefConType MWST

RefApplicatio V Sales/Distribution



3.3.13.3 Maintain Pricing Procedures

The pricing procedure is used to determine which condition types are taken into account, and in what order. In addition, the pricing procedure determines what subtotals are formed and the pricing screen on which they are displayed, how far it is possible to edit pricing manually, on what basis percentage markups and markdowns are calculated, as well as the conditions that must be met to assure a certain condition type can be taken into account.

PRECONDITIONS:

The condition types and keys have already been maintained.

PATH: (V/08)

Customizing Sales and Distribution Basic Functions Pricing Pricing Control Define and Assign Pricing Procedures Maintain Pricing Procedures

PROCEDURE:

Take a look at pricing procedure POSPCS and find the condition types described.

PARAMETER SETTINGS:

Refer to the screenshots below for the parameter settings.

BACKGROUND:

The POS inbound profiles in sales contain the name of the pricing procedure to be used. The existing standard SAP pricing procedure called POS000 already contains condition type PTBL for invoiced amounts (used for customer card) and PTCS for cash payments. Pricing procedure POSPCS, which is used in the BEST PRACTICES, has been extended to additionally take account of the requirements of the bonus buy process for example.

REMARKS:

INFO: If you want to make changes to the existing pricing procedure, you are advised against making direct changes to the standard pricing procedure. Instead, you should copy the standard pricing procedure and create your own pricing procedure, in which you then make the required changes.

IMPORTANT: Copy the pricing procedure with all the dependent settings.

BC SET:

/BPR3R/SD_KALKSCHEMA_ZO



3.3.14 Additional Settings for Production Environment

3.3.14.1 Conversions

In the Retail system and the POS system used, fields with the same meaning often contain different values. This might mean that a POS system only accepts numeric values as keys for merchandise categories, while SAP Retail uses alphanumeric values, for example. These types of value must be converted. You can define the conversion rules by manually specifying the corresponding values in the various systems. You can also use user exits, which enable appropriate algorithms to be incorporated.

To call up conversion tables, which you can use to convert R/3 data to POS system data, choose IMG Sales and Distribution POS Interface Adjustments Conversions. The data is converted in extension WPDA0001. Reference source code exists for the user exits contained in this extension and can be activated in an enhancement project.

If a converter is used (such as the SAP Business Connector), it converts the data when the POS system is unable to do so.

3.3.14.2 Extensions

The R/3 System provides over 100 IDoc types for standard communication, which are processed by the EDI interface. SAP Retail also provides 25 IDoc types for communication between the store and the central SAP Retail system. These IDoc types are sent via the POS interface.

In addition to the basic types that have already been defined in the SAP system, the system provides tools for creating customer-specific extensions for the existing IDoc types. Additional data fields are provided for inbound and outbound communication in the data segments. User exits are supplied to enable these additional fields to be transferred when data is sent and received.

3.3.14.3 Reports and Batch Jobs

Definition is possible in the R/3 System of one or more variants for the reports that prepare data. These variants determine which data is to be prepared for which stores.

3.3.14.4 Outbound Processing in Background

In the BEST PRACTICES, “Output immediately” has been set in the partner profile in outbound processing for demonstration purposes. In a production environment, the output mode must be set to “Collect IDocs” and transferred to the port with a report in one step. Rather than being set to status 03 ‘IDoc written to port’, the IDocs are then set to status 30 ‘IDoc ready for dispatch’.

3.3.14.5 Inbound Processing in BackgroundIn the BEST PRACTICES, “Trigger immediately” has been set in the partner profile in inbound processing for demonstration purposes. In a production environment, the input mode must be set to “Processing by background program” and background processing is



triggered with a scheduled report. You are only advised to use immediate dispatch with very low volumes of documents.

3.3.14.6 Job Scheduling

These types of report are scheduled using jobs. They can be scheduled with a fixed time or as successors of previous jobs. To schedule jobs, choose

System Services Jobs Define Job.

When defining the steps in a job, you have to specify the ABAP program and an existing variant. To display the program name from the relevant online transaction, choose System Status. To create a variant, choose Goto Variants Save as Variant.



3.3.15 Change VersionsIn production operation, manual requests are only used to transfer individual articles or merchandise categories in particular cases.

A store is usually supplied with merchandise for the first time during initialization. From then on, only change versions are generated.

If master data is changed in the system and change pointers have been activated, the system saves change pointers, which the system evaluates when the POS request is made. Although the system only transfers the articles that have been changed, it transfers the entire data record and not just the fields that have been changed.

3.3.15.1 Initialization

SAP Menu Logistics Retailing Distributed Retailing POS Interface Outbound POS Data Initialization

3.3.15.2 Create Change Versions

Prerequisites in Customizing:

IMG Basis Application Link Enabling (ALE) Modelling and Implementing Business Processes Master Data Distribution Replication of Modified Data Activate Change Pointers - Generally

IMG Basis Application Link Enabling (ALE) Modelling and Implementing Business Processes Master Data Distribution Replication of Modified Data Activate Change Pointer per Message Type

or transaction BDCP.

Change Version Requirements:

SAP Menu Logistics Retailing Distributed Retailing POS Interface Outbound POS Data Change Message

3.3.15.3 Reorganize the Change Pointers

The change pointers are updated to tables BDCP and BDCPS. To avoid these tables becoming too large, the processed or obsolete change pointers have to be deleted. The POS status must be reorganized beforehand.

Reorganize the POS Interface:

SAP Menu Logistics Retailing Distributed Retailing POS Interface Outbound Status Reorganization

Reorganize the Change Pointers:

Tools ALE ALE Administration Services Change Pointers Reorganize



3.4 Store Order/Store Order ReturnHierarchy BC Set: /BPR3R/FIL_AUFTRG_RETOURE

Precondition

POS inbound profile KASI has been defined in the system.

Distribution center VZ01:

Distribution chain for site: V001, V2, S1

EDI partner profiles should already be maintained

POS outbound and inbound profiles should be maintained as KASI

Shipping point VS01 should be assigned

Warehouse number 100

The site has a Warehouse Management System

Store M002:

It should be possible to deliver goods to the store from distribution center VZ01 using distribution chains V001, V2, S1 (customer view)

The site debitor view should be expanded for distribution chain V001, V1, S1 to be able to use the postings of unknown customer sales to the store debitor concerned.

EDI partner profiles should be maintained

POS outbound and inbound profiles should be maintained as KASI

<ARTICLE1 and <ARTICLE2 should be listed in both sites and the purchasing info record should exist

Delivery type NLR and default order category DLR must exist (store returns)

Store order

Check the store order settings in the POS inbound profile. Here, you maintain the document types of the follow-on documents generated as a result of the IDoc (type WGSREQ) being processed further.

You need to maintain inbound profile KASI for the goods movements transaction in POS Customizing.

To be able to post goods movements for the store using the POS interface, you need to identify the movement types in POS Customizing and maintain the relevant reversal movement type.

Store order return

Check the store order settings in the POS inbound profile. Here, you maintain the document types of the follow-on documents generated as a result of the IDoc (type WGSREQ) being processed further.

You need to enter the delivery type for store returns to distribution center VZ01. If you do not do this, the system will not find a delivery type and will not be able to generate a delivery of a store return.



To ensure that the return is not posted to the unrestricted-use stock in the distribution center, a returns storage location is created. In this storage location, the goods are checked and, depending on the result of the check, then either forwarded (returned) to the vendor or posted to the unrestricted-use stock in the distribution center.



3.4.1 Check EDI Partner Profiles for Store Inbound Message

PRECONDITIONS:

The EDI header entries for the store or distribution center and the ports have already been created. The sites have been defined in the system.

PATH: (WE20)


or


PROCEDURE:

[CREATE]

PARAMETER SETTINGS:

HEADER:

Partner no. >STORE1 / >STORE2Partn. type ‘KU’Typ ‘US’Agent ‘PRECONF’Lang. ‘EN’


Message type Transaction code‘WGSREQ’ ‘WVFB’

Processing by function moduleTrigger immediately: ‘X’ Set indicator.

BACKGROUND:


If an appropriate copy rule has been maintained in the site profile, the partner profile is copied when creating a new site.

REMARKS:

As of Release 4.7, cannot be mapped as a BC Set. Parameters are created in the Best Practices using CATT.



3.4.2 Check EDI Partner Profiles for Store Outbound Message

PRECONDITIONS:

PATH: (WE20)


or


PROCEDURE:

[CREATE]

PARAMETER SETTINGS:

HEADER:

Partner no. VZ01 (Distribution center)Partn. type KUTyp USAgent PRECONFLang. ENRelevant outbound parameters:

Message type Basic typeWGSREQ WGSREQ02

Receiver port PCS-POSOutput mode Transfer IDoc immed.

Start subsystemSyntax check X

Processing by function module Trigger immediately

BACKGROUND:


If an appropriate copy rule has been maintained in the site profile, the partner profile is copied over when you create a new site.



Remarks:

Since Release 4.7, can no longer be mapped using BC Sets. Parameters are created in the BEST PRACTICES using CATT.

3.4.3 Check POS Inbound Profile KASI

PRECONDITIONS:


PATH: (SPRO)

IMG Sales and Distribution POS Interface Inbound Store Order Control

PROCEDURE:

You check the settings in the KASI profile and save them if you make any changes.

Select POS inbound profile KASI,choose [Details],check the parameter settings and change them, if necessary, (see below).Choose [SAVE].

PARAMETER SETTINGS:

Any fields not listed here are set to ‘blank’ and are, therefore, also relevant.

Doc. Control subscreen:Document cat. default: 3 (Purchase order)Default delivery type: UL (Delivery for stock transfer)Default order doc. type: UB (Corresponds to stock transfer order in MM Purchasing)

Communication subscreen:Warning level error messages: 4 (Log all errors, warnings and notes)

Control subscreen:Default doc. category ext. replenishment: 3 (Create PO, otherwise error will occur)Default doc. category external store order: 3 (Create PO, otherwise error will occur)Check double PO: 'X'

BACKGROUND:

Check the inbound profile that controls processing of the ‘Store Order’ IDoc.

REMARKS:

BC SET:

/BPR3R/FIL_STRG_FIL_AUFTRG



3.4.4 POS Goods Movements Control

PRECONDITIONS:


PATH: (SPRO)


PROCEDURE:

[NEW ENTRIES]Enter parameters.[SAVE]

PARAMETER SETTINGS:

POS inbound profile: KASIPO search: Termination after first criterion: PO numberPO not found: Warning and GR with PO generationUsing workflows: Completely deactivate workflow for processing exceptions

BACKGROUND:

Only the goods movements that are entered in the control settings for the POS inbound profile can be transferred using the POS. The reversal movement types are always specified here for each movement type.

REMARKS:

BC SET:




3.4.5 Movement Type-Dependent Control of Goods Movements

PRECONDITIONS:

POS inbound profile KASI has been defined in the system. The movement types have already been created.

PATH: (SPRO)


PROCEDURE:

[NEW ENTRIES]Enter parameters.[SAVE]

PARAMETER SETTINGS:

POS inbound profile: Movement type: Rev. mvnt 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.4.6 Assign Delivery Type and Checking Rule

PRECONDITIONS:

Supplying sites are maintained. Delivery types are maintained.

PATH: (OGMN)

IMG Materials Management Purchasing Purchase Order Set up Stock Transport Order Assign Delivery Type and Checking Rule

PROCEDURE:

New Entries.

PARAMETER SETTINGS:

the following entries must be maintained:

DocType UBSuppl.Site P100Delivery Type NLCheck.Rule 01

For cross company processes You should maintain the following entry also:

DocType NBSuppl.Site P100Delivery Type NLCCCheck.Rule

Use the Pushbutton [Purch.Doc.Type] and maintain the following entry

VZ01/ Mxx / UB, in this case xx stands for all created stores named M001,…

BACKGROUND:

Otherwise You cannot see the transport orders (for example created by replenishment running) in the delivery worklist of the shipping point.

REMARKS:

BC SET:

/BPR3R/FIL_AUFT_LFART_ZO



3.4.7 Assign Document Type, One-Step Procedure, Underdelivery Tolerance

PRECONDITIONS:

Delivery plant and stores, delivery types maintained.

PATH: (OGMN)

IMG Materials Management Purchasing Purchase Order Set up Stock Transport Order Assign Document Type, One-Step Procedure, Underdelivery Tolerance

PROCEDURE:

New Entries

PARAMETER SETTINGS:

following entries have to be created:

SPlt P100 (Vorlagebetrieb für Lieferwerk) Site M001 ... M00x (für alle Betriebe einen Eintrag!)Type UB bzw. NB (für eigene Filialen UB, für Franchiser NB)

BACKGROUND:

REMARKS:

BC SET:

/BPR3R/FIL_AUFT_UML_BELART



3.4.8 Maintain Delivery Type for Store Returns

PRECONDITIONS:

Distribution center VZ01 and delivery type NLR (delivery type is shipped by SAP) have been defined in the system.

PATH: (SPRO)

IMG Materials Management Purchasing Purchase Order Returns Order Store Return

PROCEDURE:

Create and save a new entry for the distribution center.

[NEW ENTRIES], make parameter settings (see below), [SAVE].

PARAMETER SETTINGS:

Purch. doc. category: F (Purchase order)Purchasing doc. type: UB (Stock transport order)Supplying plant: VZ01Del. type store returns: NLR (Ret. stock transp. order)

BACKGROUND:

Maintain the delivery type for the store returns to distribution center VZ01.

REMARKS:

The purchasing document type here is the stock transport order because a stock transport order is generated in the store order returns process (stock transport order with return item).

BC SET:

/BPR3R/FIL_R_STG_R_BEST



3.4.9 Maintain Delivery Type NLR

PRECONDITIONS:

Delivery type NLR and default order type DLR (shipped by SAP) have been defined in the system.

PATH: (0VLK)

IMG Logistics Execution Shipping Deliveries Define Delivery Types

PROCEDURE:

Select delivery type NLR, choose [Details].In delivery type NLR, maintain the default order type.[SAVE]

PARAMETER SETTINGS:

Order Reference subscreen:Default ord. ty.: DLR (order type returns delivery)

BACKGROUND:

To create the delivery, you require data that is stored in the default order type.

REMARKS:

BC SET:

/BPR3R/FIL_R_LFART



3.4.10 Define Shipping Conditions

PRECONDITIONS:

PATH: (OVSF)

IMG Logistics Execution Shipping Basic Shipping Functions Shipping Point and Goods Receiving Point Determination Define Shipping Conditions

PROCEDURE:

[NEW ENTRIES]

PARAMETER SETTINGS:

SC: 03

Description: 'BEST PRACTICES: Store Return'

[SAVE]

BACKGROUND:

The shipping condition is used later on to determine the storage location.

REMARKS:

BC SET:

/BPR3R/FIL_R_VSBEDING



3.4.11 Assign Order Type Template to Shipping Point

PRECONDITIONS:

Shipping condition 03 (BEST PRACTICES: Store Return) has already been defined.

PATH: (VOV8)

IMG Sales and Distribution Sales Sales Documents Sales Document Header Define Sales Document Types

PROCEDURE:

Select order type DLR, choose [Details], enter parameters, choose [SAVE].

PARAMETER SETTINGS:

Shipping subscreen:Shipping conditions: 03 (BEST PRACTICES: Store Return)

BACKGROUND:

Delivery type NLR is now supplied with the shipping condition 'Store Return' using the default order type DLR.

REMARKS:

BC SET:

/BPR3R/VKBLART_DEF



3.4.12 Define Shipping Points

PRECONDITIONS:

PATH: (EC07)

IMG Enterprise Structure Definition Logistics Execution Define, Copy, Delete, Check Shipping Point

PROCEDURE:

Copy, Delete, Check Shipping Point,choose [Check Org. Object],in the dialog box, enter from shipping point VS01 to shipping point RS01, and

choose [BACK]. Define Shipping PointChange name of RS01: 'Shipping Point Store Return BEST PRACTICES',and choose [SAVE].

PARAMETER SETTINGS:

BACKGROUND:

The shipping point is assigned to the distribution center and is used later on to determine the storage location.

REMARKS:

BC SET:

/BPR3R/VSSTELLE_DEF



3.4.13 Check Assignment Shipping Point to DC

PRECONDITIONS:

Shipping point RS01 has been created.

PATH: (OVXC)

IMG Enterprise Structure Assignment Logistics Execution Assign Shipping Point to Site

PROCEDURE:

Check whether shipping point RS01 has been automatically assigned to distribution center VZ01.

PARAMETER SETTINGS:

BACKGROUND:

The shipping point is used later on to determine the storage location.

REMARKS:

BC SET:

/BPR3R/VSSTELLE_ZO_BETR



3.4.14 Maintain Shipping Point Determination

PRECONDITIONS:

Shipping point RS01 and distribution center VZ01 have already been created.

PATH: (OVL2)

IMG Logistics Execution Shipping Basic Shipping Functions Shipping Point and Goods Receiving Point Determination Assign Shipping Points

PROCEDURE:

Selection By Contents Select Site and choose BUTTON [Enter],enter Site: ‘VZ01’, BUTTON [Choose],select a record for loading group 0001 and for 0002,choose [Copy As],enter parameters,and choose [BACK] and [SAVE].

PARAMETER SETTINGS:

Enter shipping condition 03 and site RS01.

BACKGROUND:

Shipping point determination settings are made here. These settings depend on the site, the loading group in the article master, and the shipping conditions of the delivery.

REMARKS:

BC SET:

/BPR3R/VSS_FINDG



3.4.15 Maintain Storage Location

PRECONDITIONS:

VZ01 has been defined in the system.

PATH: (OX09)

IMG Enterprise Structure Definition Materials Management Maintain Storage Location

PROCEDURE:

In dialog box,enter site VZ01.

Choose [NEW ENTRIES],enter parameters, choose [SAVE], and [BACK].

PARAMETER SETTINGS:

0007: Store return

BACKGROUND:

The returns are to be posted directly to this storage location so that they can first be checked. This storage location should be set in the availability check in such a way that the goods have the status “restricted use”. The availability check is not included in this Best Practices documentation, however.

REMARKS:

BC SET:

/BPR3R/LGORT_DEF



3.4.16 Create Storage Location Automatically

PRECONDITIONS:

Movement type 671 has been defined in the system (is shipped by SAP).

PATH: (OMJ8)

IMG Materials Management Inventory Management and Physical Inventory Automatic Movements Create Storage Location Automatically

PROCEDURE:

BUTTON [Movement Type], Create SLoc. automat. : ‘X’ Set indicator for movement type ‘671’ (TR to stck in trans.),BUTTON [SAVE] and [BACK].

PARAMETER SETTINGS:

BACKGROUND:

To be able to put away an article in a storage location, this article must be identified in the storage location (a MARD segment is created). If this setting is made, this segment is created the first time an article is posted to a particular storage location. This means that when the article is posted in the future, it has already been identified. You can also create this record, which is required for putaways, in MARD table by calling up the distribution center view, entering the storage location in the storage data subscreen, and saving your data.

REMARKS:

BC SET:

/BPR3R/LGORT_AUTOM



3.4.17 Define Rules for Picking Location Determination

PRECONDITIONS:

Delivery type 'NLR' and rules for determining the picking location 'MALA' have been defined (are shipped with the system).

PATH: (OVLQ)

IMG Logistics Execution Shipping Picking Determine Picking Location Define Rules for Picking Location Determination

PROCEDURE:

Check the assignment.

PARAMETER SETTINGS:

Rule 'MALA' Delivery type 'NLR'

BACKGROUND:

The MALA rule stipulates that picking location determination is shipping point dependent.

REMARKS:

BC SET:

/BPR3R/LGORT_FDG



3.4.18 Assign Picking Locations to Sites

PRECONDITIONS:

Picking locations have been created and sites have been maintained.

PATH: (OVL3)

IMG Logistics Execution Shipping Picking Determine Picking Location Assign Picking Locations

PROCEDURE:

The assignments have already been created automatically for all sites, but are only to be kept for the distribution centers:Select all assignments for site, storage conditions, picking location and

choose [Delete]

except for the assignment: parameters

PARAMETER SETTINGS:

RS01, VZ01, with picking location 0001.For RS01, overwrite picking location 0001 with 0007,[SAVE], [BACK].

BACKGROUND:

The assignments created automatically are not necessary, since the picking location is only to be used for this process in VZ01 for posting changes to ‘unrestricted use’ (if the goods returned by the store are acceptable) and returns to the vendor (if the goods returned by the store are faulty).

REMARKS:

BC SET:

/BPR3R/ZO_KO_LGORT



3.4.19 Define Item Category Determination in Deliveries

PRECONDITIONS:

The item category has been created.

PATH: (SPRO)

IMG Logistics Execution Shipping Deliveries Define Item Category Determination in Deliveries

PROCEDURE:


Maintain the entry for generic articles.

Save your data.

PARAMETER SETTINGS:

Maintain the following values:

DlvT ItCG Usg. ItmC ItmC

NL SAMM V NLN

NLR SAMM V NLRN

or copy:

NL NORM V NLN

and change the item category group from NORM to SAMM.

BACKGROUND:

Important for generic articles only.

Since a generic article has a different item category group than a single article, an entry must also be made for the generic article in item category determination for deliveries so that a delivery item can be generated. The item category group is the only difference between the entry for a generic article and the entry for a single article.

REMARKS:

BC SET:

/BPR3R/FIL_R_POSTYP_LIEFG



3.5 Store Physical InventoryHierarchy BC Set:

In this step, you control the creation of physical inventory documents in inbound processing of the IDocs from the store.

You can select the following processing control settings:

1 Create work item “Count without entering document reference”

2 Do not create physical inventory documents: Issue message only

3 Create physical inventory document only after repeat of IDoc

4 Create physical inventory document directly

PRECONDITIONS

A suitable POS inbound profile must be maintained.

If a work item is to be processed:

o Using the Business Workflow Organization function the organizational plan must be maintained, as well as the position and the employee.

o A standard task must be assigned for the position.

o The employee must be assigned to a position.

Standard Settings

The following entry is shipped with the system:

POS Inbound Profile Description Control Phy. Inv. Doc. CreationSAPD SAP default 2



3.5.1 Store Physical Inventory Control

PRECONDITIONS:

Your R/3 System is configured as an SAP Retail System.

PATH:

IMG Sales and Distribution POS Interface Inbound Store Phys. Inventory Control

PROCEDURE:

Copy the SAP proposal SAPD and make the creation control settings for physical inventory documents.

PARAMETER SETTINGS:

Inbound Profiles Doc. Creation Ctrl. Grouping Type

KASI 4 Create doc. immed. 01 Merch. cat.

BACKGROUND:

Control settings 2 to 4 represent the standard processing options.

Work item processing should be used if the physical inventory documents have already been created and if this scenario only occurs occasionally because work items are generated for each item that is not counted.

Grouping type 01 means that the physical inventory documents that have been automatically created are sorted by merchandise category for count items that could not be assigned to an existing document.

At present, you can choose between no sorting or sorting by merchandise category.

REMARKS:

Note that creating a physical inventory document automatically you can not use the option to fix the book balance because the physical inventory documents not yet exists when inbound processing is used.

BC SET:

/BPR3R/IN_STEUERG_FILINV


sapevent:DOCU_LINK/DS:TX.ISR_RETAIL_TEXT


3.5.2 EDI Basic Settings

3.5.2.1 Inbound Parameters for Store Physical Inventory

PRECONDITIONS:

The store has already been created as an EDI partner ‘customer’.

PATH: (WE20)


or

Tools Business Communication IDoc Partner Profiles

PROCEDURE:

[CREATE]

PARAMETER SETTINGS:

HEADER:

Partner no. >STORE2 (Store with int. settlement)Partn. type KUTyp USAgent PRECONFLang. EN


Message type Transaction codeWVINVE WVIN

Processing by function module: Trigger immediately

BACKGROUND:


If an appropriate copy rule has been maintained in the site profile, the partner profile is copied when you create a new site.

REMARKS:

Not possible using BC Sets.

Created in the BEST PRACTICES using CATT.



3.5.2.2 Outbound Parameters for Store Physical Inventory

PRECONDITIONS:

The store has already been created as an EDI partner ‘customer’.

PATH: (WE20)


or


PROCEDURE:

[CREATE]

PARAMETER SETTINGS:

HEADER:

Partner no. >STORE2 (Store with int. settlement)Partn. type KUTyp USAgent PRECONFLang. EN

Test: BLANK

Message type Receiver portWVINVE PCS-POS

Output mode:

Transfer IDoc immed. ‘X’ Set indicator

Do not start subsystem ‘X’ Set indicator (only start for production operation)

Basic type:

WVINVE01

BACKGROUND:





REMARKS:

Not possible using BC Sets.

Created in the BEST PRACTICES using CATT.



3.5.3 Allow Freezing of Book Inventory Balance in Storage Location

PRECONDITIONS:

Storage location is maintained.

PFAD:

IMG Materials Management Inventory Management and Physical Inventory Physical Inventory Allow Freezing of Book Inventory Balance in Storage Location

PROCEDURE:

Set the indicator for the concerning storage locations of the Site >FILIALE1 />FILIALE2.

PARAMETER SETTINGS:

Site: >FILIALE1 / >FILIALE2

Stor.Loc. Description Freeze book inc.SLoc

0001 X

BACKGROUND:

Only if this indicator is set it is possible to freeze the article’s stock of this storage location.

REMARKS:

BC SET:

/BPR3R/MM_IM_INV_BST_FIX



3.5.4 Activate Info Structure for Physical Store Inventory

PRECONDITIONS:

PATH:

IMG Logistik Allgemein Logistik Informationssystem (LIS) Logistics Data Warehouse Fortschreibung Fortschreibung aktivieren Warenwirtschaft (RIS)

PROCEDURE:

With the mouse You choose the Info Structure S200 and press the BUTTON [DETAIL].

Then You activate the asynchronous Update (2) and confirm with BUTTON [ENTER].

Now You should save with BUTTON [F11-SAVE] and confim the following popup.

PARAMETER SETTINGS:

Info structure: S200

Update: Asynchronous Update

BACKGROUND:

REMARKS:

BC SET:

/BPR3R/MM_INV_FIL_INFO



3.6 Store ReplenishmentHierarchy BC Set: /BPR3R/POS_IN_FIL_NACHS

3.6.1 Preconditions for Replenishment with MM Inventory Management

The following settings must be made in the site master for the store (<STORE2):

Purchasing /Distribution:

Automatic Order Conversion: X

POS :

POS Outbound Profiles: KASI (POS simulation)POS Inbound Profiles: KASI (POS simulation BEST PRACTICES)

The article master of the articles for which replenishment with MM Inventory Management is to be allowed must be maintained as described in the following section:

Note :

The article should be created using a category 02 CATT because this CATT already contains the appropriate settings (any settings not contained in the CATT are specified in the following section).

Listing /mat.plng.:

Listing procedures: B1 (Basic procedure: mdse cat./assortment grade)

The article must be listed for generating the follow-on documents rather than for replenishment itself in the appropriate store for which replenishment is to take place. This enables replenishment to be planned even if the articles have not yet been listed, which means that no checks (performance-intensive) have to be carried out on listing during the replenishment run.

Purchasing :

Var.order unit: 1

Logistics store:

RP type: RP (replenishment)Target stock: 100 (e.g.)Replenishm.IM: BlankOnly incl. GI: BlankPlnd dely time: 3 (days)Supply source: 4 (stock transfer before standard)Purch. group: E01Avail. check: 01 (daily requirements)Neg. stocks: BlankStor. location: 0001



3.6.2 Maintain Replenishment Control

3.6.2.1 Number Ranges for Replenishment Run

PRECONDITIONS:

PATH: (WC61)

IMG Materials Management Consumption-Based Planning Replenishment Control Number Ranges for Replenishment Run

PROCEDURE:

PARAMETER SETTINGS:

No further Customizing settings are required here.

BACKGROUND:

Maintain the number ranges for the replenishment run. The number range is used to provide unique numbers for the replenishment run.

REMARKS:

BC SET:

None



3.6.2.2 POS Inbound Updates (Aggregated Sales and Sales as per Receipt)

PRECONDITIONS:

The POS inbound profile has been created.

PATH: (SPRO)

IMG Materials Management Consumption-Based Planning Replenishment Control POS Inbound Updates Aggregated Sales Control/Control Sales as per Receipts

PROCEDURE:

Select the inbound profile and choose [Details].

PARAMETER SETTINGS:

‘Proc.’ subscreen

‘Update rep. based IM’ Indicator indicates that the stock changes in replenishment-based inventory management are to be updated.

- Set the indicator to X (KASI) if replenishment is to be run for materials for which value-based inventory management rather than quantity-based inventory management is run at material group level.

- Set the indicator to 1 (PSNA) to adopt the sales data in store planning. This is carried out in a special run before inbound processing. (Set here for multistep replenishment)

BACKGROUND:

Maintain the update in the POS interface - inbound. In the section on controlling the aggregated sales and the sales as per receipts, you can specify whether and how replenishment-based inventory management is updated in the POS interface - inbound.

REMARKS:

The indicator and control settings for sales as per receipts and aggregated sales are identical.

BC SET:

Here not necessary. Maintained in control sales as per receipts.



3.6.2.3 Follow-On Documents (Via Store Order)

PRECONDITIONS:


PATH: (SPRO)

IMG Materials Management Consumption-Based Planning Replenishment Control Follow-On Documents (Via Store Order)

PROCEDURE:

None

PARAMETER SETTINGS:

None

BACKGROUND:

Maintain the follow-on documents using the store order. Here, you specify which follow-on documents are generated by replenishment. No further Customizing settings are required here.

REMARKS:

BC SET:

None



3.6.2.4 Store Order Control

The POS inbound profile is KASI/PSNA (POS simulation BEST PRACTICES). Change View “Follow-On Document (Via Store Order)”: Details. Has already been maintained in the BEST PRACTICES.

Replenishment uses the store order functions to generate the follow-on documents. You maintain the control parameters of the store order in a POS inbound profile in Customizing for the POS interface - inbound.

The following parameters are relevant for replenishment:

- Document category default

This controls whether a purchase order or delivery, for example, is to be generated as a follow-on document. You can enter various default values depending on the type of source of supply (internal or external vendor). If no detailed information is available, the general default value is used.

- Default delivery type

If deliveries are to be generated as follow-on documents, you can specify a default value for the document type of the delivery.

- Control settings for error messages

PRECONDITIONS:

POS inbound profile (KASI / PSNA) has been defined in the system.

PATH: (SPRO)

IMG Sales and Distribution POS Interface Inbound Store Order Control

PROCEDURE:

Position your cursor on the KASI /PSNA profile and choose 'Details'.

PARAMETER SETTINGS:

Any fields not listed here are set to ‘blank’ and are, therefore, also relevant.

Doc. Control subscreen Document cat. default: 3 (Purchase order) for KASI A (Stock transfer order or Purchase order) for PSNADefault delivery type: UL (Del.for stock trans.)Default order doc. type: UB (Corresponds to stock transfer order in MM Purchasing)

Communication subscreen Warning level error mess.: 4 (Log all errors, warnings and notes)

Control subscreen Default doc. cat. ext. replenishment: 3 (Create PO, otherwise error will occur)Default doc. category external store order: 3 (Create PO, otherwise error will occur)Check double PO: 'X'

BACKGROUND:

Purchase orders are to be created as soon as a store order is received (default: stock transport



orders).

REMARKS:

BC SET:

/BPR3R/FIL_STRG_FIL_AUFTRG



3.6.2.5 Aggregated Sales Control

The POS inbound profile is KASI (POS simulation BEST PRACTICES). Change View “Aggregated Sales Control”: Overview. No further Customizing settings are required here.

The inventory management, billing, information system, and replenishment planning functions are supplied with the aggregated sales data. Here, you determine how the aggregated sales data is to be prepared and forwarded to the various functions.

PRECONDITIONS:

Number ranges have been maintained for customers (external number assignment).The calculation schema (POSPCS) and POS inbound profile KASI /PSNA 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 POS inbound profile KASI /PSNA.

To do so, select SAPD, choose Edit Copy As, and enter KASI /PSNA.

Then maintain the storage location and the calculation schema under Goto Details.

PARAMETER SETTINGS:

Inventory mgmt: ‘X’ Inventory management without aggregationBilling: ‘X’ Billing, with billing document saved Update rep.-based IM: ‘X’ Integrated replenishment-based inventory management

(for KASI)

‘1’ Special Replenishment-Based Inventory Management

(for PSNA)

RIS and BW update: ‘X’Anonym. customer: Storage location: ‘0001’Mov. type: Sales: ‘251’Mov. type: Returns: ‘252’Sales doc. type: ‘OR’Item cat. standard: ‘DLN’Bill. type ‘FP’Calculation schema: ‘POSPCS’Number of items: ‘100’Condition type: ‘PN10’Cond. 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:

All of the entries, except for the storage location, have been maintained. Check them carefully.

BC SET:

/BPR3R/POS_STG_VERD_UMS

/BPR3R/POS_STG_BON_UMS



3.6.2.6 Availability Check Control

PRECONDITIONS:

Availability check 01 and checking rule RP must have been created.

PATH: (SPRO)

IMG Sales and Distribution Basic Functions Availability Check and Transfer of Requirements Availability Check Availability Check with ATP Logic or Against Planning Carry Out Control for Availability Check

PROCEDURE:

Select the combination 01 (Daily requirements) and RP (Replenishment) [Details] pushbutton.

PARAMETER SETTINGS:

Deactivate the indicators for:

Include quality inspection stock

Include purchase requisitions

Include dependent requirements

Include reservations

Only set the indicators for:

Stocks:

Include safety stock: ‘X’ Set indicator

This indicator specifies whether, during an availability check, the system adds the safety stock to the available inventory in the respective plant.

Stock in transfer: ‘X’ Set indicator

This indicator specifies whether, during an availability check, the system takes into account any stock that is being transferred to the plant with which you are working.

In/outward movements

Include purchase orders: ‘X’ Set indicator

This indicator specifies whether, during an availability check, the system takes into account reservations that are assigned to purchase orders.

Related:

Include dependent reservation: ‘A’ Set indicator

You set this indicator to specify that the reservations for purchase orders are taken into account in such a way that only reservations that can be withdrawn are considered.

Include sales requirements: ‘X’ Set indicator

This indicator specifies whether, during an availability check, the system takes into account the requirements generated by existing sales documents (sales orders, for example).



Include release order requirements: ‘A’ Set indicator

The indicator specifies whether the system takes requirements resulting from stock transport orders into account during the availability check.

Include shipping notification.

BACKGROUND:

In this step, you define checking rules for the availability check and assign them to a checking group.

REMARKS:

If you want to include the expected in/outward movements, you need to use the availability check in the replenishment run.

To improve performance, you can carry out the replenishment process without using the indicators mentioned above in the availability check.

BC SET:

/BPR3R/POS_IN_NACHS_STRG_VP



3.6.3 Special Settings (Optional)

3.6.3.1 Maintain Rounding Profiles

In this IMG activity, you define the rounding profile in order to adapt the units of measure in material requirements planning to the delivery and transport units, for example, if purchase orders can only be delivered in bundles of 24 pieces or as pallets.

You can define several combinations of threshold and rounding values for a rounding profile. The individual combinations are then assigned a level.

The threshold value is the value from which the system rounds up to the next deliverable quantity. If the threshold value is not reached, the system rounds the quantity according to the next lower level. If the lowest level is not reached, the system rounds up to a multiple of the rounding value, if the requirements quantity is larger than the threshold quantity. Otherwise, the requirements quantity remains unchanged. The rounding value is the value to which the system rounds the quantity if the threshold value is exceeded.

The following rounding profiles should have been created using CATT.

- RPRO: Food

- RPRF: Fashion

Details on the rounding profiles:

PRECONDITIONS:

PATH: (OWD1I)

IMG Materials Management Consumption-Based Planning Planning Lot-Size Calculation Maintain Rounding Profiles

PROCEDURE:

Enter 'RPRO' as the rounding profile and choose [Create Statically].

PARAMETER SETTINGS:

Threshold val. Round. value

1,000 144,000

145,000 720,000

PROCEDURE:

Enter 'RPRF' as the rounding profile and choose [Create Statically].



PARAMETER SETTINGS:

Threshold val. Round. value

1,000 10,000

11,000 15,000

16,000 25,000

21,000 50,000

51,000 75,000

76,000 100,000

101,000 150,000

REMARKS:

BC SET:

/BPR3R/POS_IN_NACHS_RUND_PROF



3.7 Error Messages in InboundError messages can be sent from the POS system to the head office using message type WPUERR01. Either standardized error messages can be sent or error messages entered manually and sent to the head office.

3.7.1 Inbound Parameters

PRECONDITIONS:

The customer partner type ‘KU’ has already been maintained as the header entry for the store.

PATH: (WE20)


or


PROCEDURE:

[CREATE]

PARAMETER SETTINGS:

HEADER:

Partner no. >STORE1Partn. type KU

Inbound parameters

Message type: ‘WPUERR’

Test indicator: ‘X’ set indicator

‘Input Options’ subscreen:

Transaction code: ‘WPUE’ ‘WPUERR messages FWWS/POS/SCS’

Processing by function module:

Immediately ‘X’ set indicator

Syntax check: ‘X’ set indicator

BACKGROUND:





REMARKS:

No BC Set. Is created using CATT.



3.7.2 Outbound Parameters

PRECONDITIONS:

Partner ‘LS’ has already been maintained as the header entry for the logical system.

PATH: (WE20)


or


PROCEDURE:

[CREATE]

PARAMETER SETTINGS:

HEADER:

Partner no. <log.system> e.g. PCSCLNT509 in Best PracticesPartn. type LS

Outbound paramtrs.

Message type: ‘WPUERR’

Test: ‘ ‘

Output mode:

Transfer IDoc immed.: ‘X’ set indicator

Do not start subsystem: ‘X’ set indicator

Basic type: ‘WPUERR01’

BACKGROUND:

To be able to send the message back to the store, the message type must be maintained in the outbound parameters for the logical system (head office).

REMARKS:

Is created using CATT:



3.7.3 Create a Message (no Customizing)

PRECONDITIONS:

Message class ‘W9’ is already contained in the standard system and is used to create new messages.

PATH: (SE91)

SAP Menu Tools ABAP Workbench Development Programming Environment Messages

PROCEDURE:

Enter a message class and maintain a new entry for this message class. This new message can then be transferred to the head office or to the store using the error IDoc type.

PARAMETER SETTINGS:

MESSAGE CLASS: ‘W9’

Messages: ‘X’

Input: Number (for example, 099)

BUTTON: [MAINTAIN]

BACKGROUND:

This is a workaround to enable messages to be sent to the POS system and is a special case. The messages from the POS system are updated in the central system but it should be possible to display and read them in the POS monitor - inbound.

For the outgoing message, a message must be maintained to enable the message to be sent back to the POS system.

REMARKS:

BC SET:

No Customizing. Maintain manually.



3.8 Goods MovementsHierarchy BC Set:

In this step, you define the different characteristics for processing goods movements that are sent by the POS system.The parameters used for controlling goods movements processing are assigned to profiles that are used in plant maintenance.

The individual parameters influence the automatic search for purchase orders acting as reference documents for a goods receipt and for integrating workflows for coping with exceptional situations.

These settings are delivered as standard by SAP so that POS goods movements are handled in exactly the same way as in previous SAP Retail releases, up to and including 4.5B.

Recommendation

No settings are compulsory due to system compatibility with previous releases. However, you should activate the revised workflow integration available as of Release 4.6A, by making the suitable settings for the workflow usage parameter in the POS inbound profile.

Path:


You can choose three options here:

Activate old workflow for processing exceptions (as before 4.6A)

Activate new workflow for processing exceptions

Completely deactivate workflow for processing exceptions

In this case, the KASI profile is set to the old workflow for processing exceptions and the KASN profile is set to the new workflow.



3.8.1 Store Goods Receipt

3.8.1.1 Control Store Goods Receipt

PRECONDITIONS:

The POS inbound profile has already been maintained. In this case: KASI.

The parameter for the goods movements in the POS interface - inbound has been created for the stores.

PATH: (SPRO)


PROCEDURE:


PARAMETER SETTINGS:

POS inbound profile: KASI

Process control:

Prevent PO gen.: Blank

PO search: Termination after first criterion

PO not found: Work item ...

Eval. final delivery order indic.: Blank

Selection parameters: Blank

Selection param. for GR reversal: Blank

The workflow settings depend on what type of exception processing you want to use. In this case, standard tasks are assigned, in other words, the old workflow is used for processing exceptions.

Using workflows: Old workflow for processing exceptions...

Workflow template: Blank

BACKGROUND:

Controls the goods receipt in the store. When the message arrives at the head office, a search is carried out to find the relevant store purchase order. If no purchase orders are found and you have activated a workflow for processing exceptions, a work item is generated, depending on the type of exception processing you have selected, and placed in the inbox of the assigned user.

REMARKS:

BC SET:




3.8.2 Movement Type-Dependent Control of Goods MovementsIn this step, you can add additional inventory management information to the goods movements sent by the POS systems.

PRECONDITIONS

You can specify the following:

The cost center to which a goods movement is to be assigned if it is relevant for cost accounting.

Default: Blank

The G/L account to which consumption is to be posted.

Note: If you do not make an entry, account determination is carried out in Inventory Management.You can configure this using the IMG for Inventory Management.

Default: Blank

PRECONDITIONS:

The POS inbound profile has already been maintained. In this case: KASI.

PATH: (SPRO)


PROCEDURE:


PARAMETER SETTINGS:

POS inbound profiles: Movement type Rev. mvmt. type

KASI 101 (GR for PO) 102

KASI 102 Reversal 101

KASI 251 (GI for Sales) 252


KASI 301 Stock transf. site to site 302


KASI 551 (GI for scrapping) 552


BACKGROUND:

Here, you specify the movement types that can be transferred by the store via the POS interface, together with the relevant reversal movement types.



REMARKS:

BC SET:




3.8.3 Goods Movements Control

PRECONDITIONS:

POS inbound profile KASI has been created.

PATH: (SPRO)


PROCEDURE:


PARAMETER SETTINGS:


Process Control subscreen:

PO search: ‘Termination after first criterion: PO number’

PO not found: ‘Generate work item for PO search’

Using workflows ‘Activate old workflow...’

or ‘Deactivate...’

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. Alternatively, if you have chosen ‘Deactivate’, a workflow is not triggered when a goods movement IDoc is incorrect.

REMARKS:

BC SET:




3.9 Coupon & Bonus BuyHierarchy BC Set: /BPR3R/COUPON_B

3.9.1 PreconditionsThe basic Customizing settings have been made. Check the following settings:

- Outbound file in file port

- EDI outbound parameters

3.9.2 Maintain Outbound File in File Port

PRECONDITIONS:

The file port has already been created via CATT.

PATH: (SM59)

Tools Business Communication IDoc Basis Administration Port Definition

or

IMG SAP Web Application Server Sending and Receiving Systems Systems in Network Asynchronous Processing Maintain Port Define Port

PROCEDURE:

Selection: [File]

File port: PCS-POS

Tabstrip [Outbound file]

BUTTON [ACCESS TEST]

BACKGROUND:

If the access test is not positive, you need to ask your system administrator for the correct path. The port details are system dependent and must also be maintained in your system when you create ports using the BEST PRACTICES. The process cannot be carried out in your system until the port has been maintained correctly.

REMARKS:

No BC SET required



3.9.3 Maintain EDI Outbound Parameters

PRECONDITIONS:

The partner has already been created as an entry (in this case, KU/M001 using BEST PRACTICES-CATT).

PATH: (WE21)

Tools IDoc Basis Administration IDoc Administration Partner Profiles

or

IMG SAP Web Application Server Modelling and Implementing Business Processes Partner Profiles and Time of Processing Maintain Partner Profiles Manually

PROCEDURE:

Click Partner [KU] and choose M001.

Outbound Parameters subscreenBUTTON [CREATE OUTBOUND PARAMETER]

PARAMETER SETTINGS:

Message type Receiver port

‘WPDBBY’ ‘PCS-POS’

Collect Idocs ‘X’ set indicator

Start subsystem ‘X’ set indicator

Basis IDoc type: ‘WPDBBY01’

BACKGROUND:

To transfer the bonus buy data to the store the message type must have been maintained for the relevant store. The data is then transferred using an IDoc of this type. The POS system therefore recognizes the bonus buy conditions and can provide the customer with the relevant conditions directly when appropriate sales transactions take place.

REMARKS:

Not possible via BC Sets



3.9.4 Activation of Bonus Buy

PRECONDITIONS:

PATH: (VBKD)

IMG Sales and Distribution Basic Functions Bonus Buy Maintain Condition Type

PROCEDURE:

Enter the condition types, choose [Save].

PARAMETER SETTINGS:

Condition type Access seq. Bonus buy type Scale basis

BB01 BB00 P BBB02 BB00 R BBB03 BB00 % BBB04 BB00 N C

BACKGROUND:

A discount can only be granted upon presentation of a coupon if condition types have been assigned to the bonus buy application.

REMARKS:

BC SET:

/BPR3R/C_BK_KONDART



3.9.5 Maintain Condition Types

PRECONDITIONS:

PATH: (V/06)

IMG Sales and Distribution Basic Functions Pricing Pricing Control Maintain Condition Types

PROCEDURE:

Choose [NEW ENTRIES], enter the condition types, and choose [Save].

PARAMETER SETTINGS:

Condition type: CPH1 Description: Coupon header

Cond. class: ‘A’

Calculat. type: ‘B’

Group condition

Group cond.: X

Changes which can be made

Header condit.: X

[SAVE] BUTTON

Condition type: CPL1 Description: Coupon item 1 (same for 2 and 3)

Cond. class: ‘A’

Calculat. type: ‘B’

Changes which can be made

Header condit.: X

Make the same setting for CPL2 and CPL3.

[SAVE] BUTTON

BACKGROUND:

These condition types are maintained later on in the pricing procedure. The header and item condition types are maintained so that distribution in the coupon profile takes place to the accounts once and for each sale.

REMARKS:

Condition types CPL1 to 3 represent subconditions of header condition type CPH1. Condition type CPH1 is used to grant the discount at the POS system when the sales takes place. The item condition types are used for internal distribution of the discount to various cost objects.

BC SET:

/BPR3R/SD_KONDART_DEF



3.9.6 Define and Assign Account Key

PRECONDITIONS:

PATH: (V/06)

IMG Sales and Distribution Basic Functions Account Assignment/Costing Revenue Account Determination Define and Assign Account Determination Procedures Define Account Key

PROCEDURE:

Choose [NEW ENTRIES], enter the new account key, and choose [Save].

PARAMETER SETTINGS:

ActKy: CP1 Description: Account key Coup1

CP2 Description: Account key Coup2

CP3 Description: Account key Coup3

PATH: (OV34)

IMG Sales and Distribution Basic Functions Account Assignment/Costing Revenue Account Determination Assign G/L Accounts

PROCEDURE:

Choose table 005 (Acct. key), choose [NEW ENTRIES], make entries, and choose [Save].

PARAMETER SETTINGS:

App. CndTy Chart of Acc. Sales Org. ActKy G/L Account No. G/L Account No.

V KOFI INT V001 CP1 884000 884000

V KOFI INT V001 CP2 883000 883000

V KOFI INT V001 CP3 889000 889000

BACKGROUND:

Precondition for the coupon distribution profile. Here, the G/L account to which postings are to be made is assigned for distributing the costs of the discount that has been granted for the sales. The account is determined in line with the chart of accounts, the sales organization and this account key.

REMARKS:

BC SET:

/BPR3R/SD_KTOSCHLUESSEL_DEF



3.9.7 Assignment of Condition Type to Pricing Procedure

PRECONDITIONS:

The condition type, pricing procedure, and account key have already been created.

PATH: (V/08)

IMG Sales and Distribution Basic Functions Pricing Pricing Control Define and Assign Pricing Procedures Maintain Pricing Procedures

PROCEDURE:

1. Select the pricing procedure: ‘POSPCS’

BUTTON [CONTROL DATA]

PARAMETER SETTINGS:

Step CType Man. AltCTy ActKy

15 CPL2 Blank CP2

16 CPL3 Blank CP3

170 CPL1 Blank CP1

300 CPH1 220 Blank

BACKGROUND:

You can enable condition types to be used during pricing by assigning them to a pricing procedure. By assigning the account keys, you also control which G/L accounts are used for posting various conditions. Using a condition or basis formula provides you with further control options at individual condition type level.

REMARKS:

BC SET:

/BPR3R/SD_KALKSCHEMA_ZO



3.9.8 Define Coupon Profiles

PRECONDITIONS:

Cond. types (CPH1, CPL1 – 3)

Account keys (CP1 – 3)

PATH: (SPRO)

IMG Sales and Distribution POS Interface Inbound Define a Profile for Distributing Coupon Discounts

PROCEDURE:

Choose [NEW ENTRIES], make entries, choose [SAVE].

PARAMETER SETTINGS:

Key

Coupon distrib. profiles: ‘COUP’ ; Description: ‘BEST PRACTICES coupon profiles’

Cost object 1

Coupon share: ‘50’Condition type: ‘CPL2’Account key : ‘CP2’

Cost object 2


Cost object 3


BACKGROUND:

This assignment is used to control the ratio used to distribute the difference between the normal price and the price reduced by the discount to the cost objects involved.

REMARKS:

The values used in this distribution are just default values. Any combination of values is possible, however. The coupon distribution profile ‘COUP’ is created using CATT.

BC SET:

/BPR3R/C_BK_COUP_VERTPROFILE



3.10 Workflow Customizing The workflow tool assigns open tasks (work items) to employees and sends them to their SAPoffice inbox. You can use transaction PFTC to display the workflow objects, such as standard tasks or workflow templates.

The employee responsible is determined from the organizational plan in the R/3 System. An area of responsibility can be defined for a job a position or a work center. If a work item falls in an area of responsibility, it is forwarded to the employees responsible. More than one employee can be responsible for one work item.

Work items can be executed individually or in groups and can be forwarded if the task is the responsibility of another employee/area. All the steps carried out when processing a work item are recorded in a log and can be analyzed statistically (processing time, number of work items per employee, and so on).

In this activity, you make all the settings required to adjust the standard tasks and workflow templates shipped by SAP. Only carry out this activity if you want to use the scenarios supported by SAP.

Possible agents must be specified for each standard task in order to clearly define the organizational responsibility for processing.

Workflow templates can only be started online by their possible agents. If a scenario requires that the particular workflow template be started online, this workflow template must be assigned to its possible agents.

A standard task or workflow template can be started as a reaction to events created by the application functionality. For this purpose, certain events are defined as triggering events for the standard task or workflow template. If you want to create the linkage between event and standard task or workflow template as suggested by SAP, activate this linkage between triggering event and task.



PRECONDITIONS

Check that all the basic Customizing settings for the application component WFM (workflow management) have been made.

Activities

1. Carry out the activity and, from the displayed component hierarchy, select the application component for which you can/want to

o Assign possible agents to standard tasks

o Activate triggering events for standard tasks and workflow templates (poss.)

2. Expand the branch “Assign agents to tasks”.

3. Select a standard task for processing.

Assign the task to its possible agents. This assignment determines the total number of persons who are allowed to process this task.

Specify all the relevant agents:

You have the following options:

o Job

o Organizational unit

o Position

o Work center

o User

Multiple assignments are possible.

Alternatively, you can classify a standard task as a “general task”.

4. Expand the branch “Assign agents to tasks”.

5. Select a standard task or workflow template for processing.

Only some of the standard tasks and workflow templates have triggering events. This is indicated by the folder icon in front of the task name. If you double-click this icon, the event entered as a triggering event is displayed.

6. Activate the linkage.

Activating event/receiver linkages determines which of the linkages in question you actually want to use.



Recommendation

You will usually assign a standard task to an organizational unit, job, or position so if personnel changes occur in the organizational plan, no changes are required in the workflow components.

Further Notes

For further information, refer to Customizing for the application component in question.

This Customizing activity gives you the opportunity to set up all the standard tasks and workflow templates that you want to use in the implementation phase. It is also possible, however, to execute the steps required from the task definitions at a later date.

The settings cannot be transported and must, therefore, not be integrated in BC Sets.

The application transaction is PFTC. To maintain and display the assignment, choose Additional Data Agent Assignment.

Path:

Tools Development Workflow Definition Tools Tasks/Task Groups Create

For more detailed workflow information, take a look at the article discontinuation scenario.

Merchandise-Driven Master Data_EN_DOCU_V147.doc



3.10.1 Store Order, New WFWF template: WS 65400051

The assignment of the workflow template is fixed in the program coding. So assignment is not necessary. In contrast to standard tasks, using new workflows to process exceptions covers a whole series of possible errors by assigning a workflow template. This means that rather than assigning several tasks you simply have to assign the workflow template in the control of the store order. You execute this assignment only if you want to use your own workflow template.

The assignment of agents remains the same as it is in the old workflow processing. In addition it is possible now to assign an agent to the hole task group.

PRECONDITIONS:

All the basic workflow Customizing settings have been made.

The store’s EDI partner profile has been maintained for message type WGSREQ.

The POS inbound profile has been created and the control settings made for the store order.

PATH: (SPRO)

IMG Sales and Distribution POS Interface Workflow Store Order

PROCEDURE:

1. Call up the Customizing activity mentioned above.

2. Carry out the first option “Assign agents to tasks”.

3. Select the entry for your task (in this case 65400070) and choose Agent Assignment Create.

4. In the dialog box that appears, choose the organizational unit that is to be notified for exception processing. Here, select “USER” and confirm with [ENTER].

5. The system now asks you to specify the appropriate organizational unit. Enter the system user name for the user that is to be notified (see point 4).

6. When you confirm your selection, the agent/organizational unit is assigned to the task. Now press BUTTON [REFRESH INDEX].

7. Finally, call up your SAPoffice inbox and choose Office Workplace Settings Workflow Settings Refresh Organizational Environment.

PARAMETER SETTINGS:

BACKGROUND:

First assign an agent to the standard task who is to be notified when an exception occurs in the POS interface inbound. Then refresh the organizational environment so that this assignment takes immediate effect without having to log on again.

REMARKS:



3.10.2 Store Order, Old WFWF tasks: 900060 Post sales order

900071 Error log

900073 POST PURCHASE ORDER

900075 Create purchase requisition

900079 Post delivery

Task 900073 ‘Post purchase order’ is set up as an example.

PRECONDITIONS:


The store’s EDI partner profile has been maintained for message type WGSREQ.

The POS inbound profile has been created and the control settings are made for the store order.

PATH: (SPRO)

IMG Sales and Distribution POS Interface Workflow Store Order

PROCEDURE:

Process analogically as described in 3.10.1

PARAMETER SETTINGS:

BACKGROUND:


REMARKS:

For more detailed workflow information, take a look at the article discontinuation scenario.



3.10.3 Store Goods Receipt (New Workflow, as of 4.6A)Task: TS 20000706 Store goods receipt: Processing step

PRECONDITIONS:



The store’s EDI partner profile has been maintained for message type WPDWBW.

The new workflow for exception processing has been chosen in the POS inbound profile.

PATH: (SPRO)

IMG Sales and Distribution POS Interface Workflow Master Data

PROCEDURE:


PARAMETER SETTINGS:

BACKGROUND:

REMARKS:



3.10.4 Store Goods Receipt (Old Workflow)WF tasks:

TS 00900059 Store GR for Purchase order

TS 00900061 Store GR for anonym. PO

TS 00900063 Store GR with autom. PO creation

TS 00900065 Store GR with diff. quantities

TS 00900067 Store GR for delivery

TS 00900069 Store GR for shipping element

The workflow for task 900061 ‘Store GR for anonym. PO’ is set here as an example.

PRECONDITIONS:


PATH: (SPRO)

IMG Sales and Distribution POS Interface Workflow Store Goods Receipt (Old Workflow, Release Independent)

PROCEDURE:


PARAMETER SETTINGS:

BACKGROUND:


REMARKS:



3.10.5 Incoming Master DataTasks: 900048 POS inbound article master data

900049 POS inbound EAN references

900051 Error in WP_EAN

900050 Error in WP_PLU

Task 900049 is used here as an example.

PRECONDITIONS:


Message type WP_EAN/WP_PLU has been set up for the store.

PATH: (SPRO)

IMG Sales and Distribution POS Interface Workflow Master Data

PROCEDURE:


PARAMETER SETTINGS:

BACKGROUND:


REMARKS:
