SAP_IS_Retail_IRT360_46C_NW

8/20/2019 SAP_IS_Retail_IRT360_46C_NW

http://slidepdf.com/reader/full/sapisretailirt36046cnw 1/262

SAP AG 2001

IRT360 Headquarters -- Store Connections:Headquarters -- Store Connections: POSPOS InterfaceInterface

IRT360IRT360Headquarters -- Store

Connections: POS Interface

Headquarters -- StoreHeadquarters -- Store

Connections: POS InterfaceConnections: POS Interface

System R/3

Release 4.6 C

May 2001

50047604

C Contact for Buying Any SAP Module Materials: [email protected] Visit: www.sapfans.co.nr



SAP AG 2001

Copyright 2001 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.

All rights reserved.

Copyright

Trademarks:

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®, OS/2®, DB2/6000®, Parallel Sysplex®, MVS/ESA®, RS/6000®, AIX®, S/390®,

AS/400®, OS/390®, and OS/400® are registered trademarks of IBM Corporation.

ORACLE® is a registered trademark of ORACLE Corporation.

INFORMIX®-OnLine for SAP and INFORMIX® Dynamic Server TM are registered trademarks of

Informix Software Incorporated.

UNIX®, X/Open®, OSF/1®, and Motif ® are registered trademarks of the Open Group.

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.

SAP, SAP Logo, R/2, RIVA, R/3, ABAP, SAP ArchiveLink, SAP Business Workflow, WebFlow,

SAP EarlyWatch, BAPI, SAPPHIRE, Management Cockpit, mySAP.com Logo and mySAP.com

are trademarks or registered trademarks of SAP AG in Germany and in several other countries all

over the world. All other products mentioned are trademarks or registered trademarks of their

respective companies.




SAP AG 2001

SAP Retail

Pricing in SD

LO620 3 daysLevel 2

SAP Retail ProcessOverview

IRT100 5 days

SAP Retail Master Data

IRT310 3 days

Consumption-BasedForecast

LO525 2 days

PurchasingDetails/Optimization

LO520 3 days

Pricing in Purchasing

LO521 2 days

Sales

LO605 4 days

Invoice Verification

LO515 3 days

Cross-ApplicationBusiness Processes inSD and MM

LO925 2 days

Shipping

LO610 2 days

Billing

LO615 2 days

Transportation

LO611 3 days

Basic Processes inWareh.Management

LO530 5 days

Level 3

SAP Retail Pricing and

Promotions

IRT320 3 days

SAP Retail Buying

IRT330 3 days

SAP Retail Supply

Chain Management

IRT340 3 days

SAP Retail BW/MAP

IRT350 3 days

SAP Retail Store

Connection

IRT360 3 days

SAP Retail Store

IRT370 2 days




SAP AG 1999

Prerequisites:

Recommended:

Basic knowledge of Application Link Enabling is useful but not essential

Basic knowledge of Electronic Data Interchange is useful

Good knowledge of content of IRT310 Retail Master Data

Good knowledge of content of IRT320 Pricing and Promotions

Good knowledge of content of IRT330 Requirements Planning and

Buying

Good knowledge of content of IRT340 Supply Chain Management

Essential:

Good knowledge of content of IRT100 Retail Process Overview




SAP AG 1999

Project Team members responsible for setting up

Store Communications

SAP and partner consultants

Target Group




SAP AG 1999

Course Goals

This course will enable you to:

Plan and implement communication between your

headquarters and stores

Set up the POS configuration for comm-unications

Set up Sales Audit Reporting




SAP AG 1999

Course Objectives

Configure your own inbound, outbound and

Assortment List communications

Explain how to transfer data to and from store

systems, both point-of-sale (POS) and foreign

merchandise management systems

Monitor transmissions via the POS interface and

handle any anomalies

Configure the Sales Audit Reporting functionality of

the POS interface

At the conclusion of this course, you will be able

to:




SAP AG 2001

Contents

Unit 5 Merchandise Management System Case Study

Unit 6 Sales Audit Reporting

Unit 7 Performance Issues

Unit 8 Conclusion

Unit 1 Introduction

Unit 2 Technical Aspects of POS

Unit 3 Mapping Store Systemsto SAP Retail

Unit 4 Simple POS Case Study

Preface

Exercises

Solutions

Appendices




© SAP AG IRT360 1-1

SAP AG 2001

Main Business Scenario Project Plan

Communication Scenarios

Overview of Business Information

SAP AG

Contents:

Unit: Introduction





SAP AG 2001 SAP AG

At the end of this unit, you will be able to:

Identify the areas that must be considered in

planning communication between headquarters

and stores

Describe the transmission options supported

by SAP Retail

List the business information that can be

transmitted via the SAP Retail POS interface

Objectives





SAP AG 2001


Unit 8 Conclusion



Unit 4 Simple POS System Case Study

Unit 3 Mapping Store Systems to SAP Retail


Course Overview

Unit 1 Introduction





SAP AG 2001

R300-DC

R301-DC

R316

20

15

14

12

11

13

10

Smart Retailer, Inc.Smart Retailer, Inc.Smart Retailer, Inc.

MMM

R317

Main Business Scenario

You are a member of your company’s store communication integration team.

You must create the appropriate configuration to communicate with your store point-of-sale

systems.

Other project teams already have configured the core business processes on SAP Retail. You have

been requested to determine the optimum configuration to communicate with the stores.

Configuration assumptions:

Your company is a general merchant with stores in three western US states.

There are two different point of sales systems currently operating in those stores. The small storesuse a point of sales server to drive their registers, while the large format stores have a merchandise

management system.

Central replenishment will be run for all stores and it is company policy to run promotions for

selected articles on weekends.

Although you have a company card, you also have a policy of accepting other major credit cards as

well as cash and checks.





SAP AG 2001

Project Plan

• Number of different typesof store systems

• Number of tax jurisdictions

• Usage of current data

• Converter/ Communicationsoptions

• Partners for converters

• Data requirements

• Conversion requirements

• Assortment List Size

• Transmission frequency

• ALE

• EDI

• POS

• Assortment List

• Schedules

• Simulate Outbound POSprocesses

• Simulate Inbound POSprocesses

• Stress Test C o n f i g u

r e

C o n f i g u

r e

C o n f i g u

r e

C o n s i d e r

C o n s i d e r

C o n s i d e r

E v a l u a t e

E v a l u a t e

E v a l u a t e

T e s t

T e s t

T e s t

Planning is the key to smooth implementation of your store communication systems. How much,what kind of data, and how often you send it are keys to system performance.

How will you enable store integration? SAP does not provide the communication interface.

- Will you contract with a certified partner? (SAP recommended solution.)Early contact with converter partners ensures communication availability when

you are ready to test.- Will you create your own converter?

How many different types of store systems are in use and where are they located?- Each store system type may require an unique POS profile and conversion category.

- Each tax jurisdiction will require a unique POS profile.

Where does the center of control reside in your company?

- Determines the kinds of data located at headquarters and at the stores and consequently,

which data you send down to the stores and receive back from the stores.

Reporting requirements

Your reporting requirements directly influence the message types you use to transport information.





SAP AG 2001

POS server MMM

StoreStoreMMM

Conversion

Communication

SAP Retailremote


Transmission Options (1/2)

Store system

SAP Retail

POS Interface Intermediate doc. (IDOC)

12

Most in-store merchandise management systems can be linked to SAP Retail.

Examples of systems include:

A POS server with merchandise management functions.

A store-based merchandise management system.

In-store systems must be linked to SAP Retail in one of two ways.

- via a certified converter/communication interface using the Retail POS Interface (SAP

recommended Solution)

- via your own converter/communication interface using EDI and SAP Intermediate Documents(IDocs).

Some data can be downloaded to merchandise management systems directly using SAP’s standard

ALE technology. (Beyond the scope of this course.) SAP Retail applications are also EDI enabled

for standard message transmission. (cf., course CA210 EDI Interface.)

The central SAP Retail system also can be accessed remotely via an in-store terminal and via the

internet using Retail Store.





SAP AG 2001

MMM

StoreStoreMMM

POS server

SAP RetailSystem

SAP Retail

ALE/EDI Intermediate doc. (IDOC)

Conversion


Transmission Options (2/2)

SAP Retail also can be set up in distributed mode with multiple application servers in various stores.

If using a distributed model, you must resolve the following questions:

- In which sites are application servers to be installed?

- Which applications are to run on which systems?

- Which master data and transaction data is to be interchanged?

- Which control data is to be made available to the central SAP Retail system?

Standard R/3 Application Link Enabling (ALE) and reference models facilitate creating a

distribution model.

The standard SAP Application Link Enabling course, CA910 provides information on distribution

modeling.





SAP AG 2001

Articlemaster data

EAN/UPCreferences

Exchangerates

Articlesales prices

Merchandisecategories

Taxes

Customer data

Inventorydata

POSOutbound

Outbound

Types of business information that SAP Retail sends through the POS outbound interface to storesystems.

Article master data

Article sales prices

EAN/UPC assignments

Customer data

Exchange rates

Products

Set Assignments

Taxes

Merchandise Category Master

Label data

Physical Inventory

Assortment Lists

Promotions





SAP AG 2001

ArticleMaster Data

EAN/UPCReferences

FinancialTransactions

Sales Data Customer Data

Cashier Data

POSInbound

Tender TypeData

Inventory

Inbound

Types of business information that SAP Retail can receive through the POS inbound interfacefrom store systems.

Sales Data (receipt-based and aggregated)

Cashier dataPayment types

Financial Transactions

External MessagesInventory (Store Orders, Goods movement and Physical count data)

Article data changesPricing conditions

Customer data

EAN/UPC assignments





SAP AG 2001

Simple POSSystem

Sales

Finance

Master Data

Purchasing

MerchandiseManagement

A r t i c l e, P

r i c e,

EA N / U P C

IntelligentPOSSystem

StoreStore

MMM

MMM

MerchandiseManagementSystem

Article, Price, EAN/UPC,Customer, Taxes

Article, Price, EAN/UPC,Customer, Vendors,...

S a l e s $

Sales $ and Q,Articles, Customers

Sales $ and Q, Articles,Customers, Inventory count...

HumanResources

Scenarios

StoreStore

MMM

MMM

IDES Smart Retailer Inc.IDES Smart Retailer Inc.IDES Smart Retailer Inc.

StoreStore

MMM

MMM

How you do business plus store system capabilities determines which:

- types of Outbound SAP Retail data you will send

- types of Inbound SAP Retail data you will receive





SAP AG 2001

Summary

Implementing Headquarter-Store communicationis an iterative process with many variables --

location of stores, types of store systems, and

choice of converter are among those that must be

considered early in an implementation.

The types and amounts of business information

sent to and received from stores depends on the

capabilities of the store systems.

SAP AG





Some definitions:

Application Link Enabling (ALE) - is a technology developed by SAP. It performs the distributionservices that interact with the SAP applications, processing IDocs and passing them to the

communications software.

Electronic Data Interchange (EDI) - is an IEEE standard for data transfer between disparate systems.

SAP can convert IDocs into an EDI compliant format for data export.

Intermediate Document (IDoc) - is the standard SAP structure used to communicate business data

between systems. IDocs can be exchanged freely between R/3 systems, but generally must beconverted to a standard format (such as EDI) for export to other systems.

Point Of Sale (POS) - as a term, is used in two ways:

First, it is used as a shorthand reference for the POS Interface, the SAP Retail module that

determines the recipient and creates IDocs for outbound POS transmission and creates the inbound

IDoc from the communication IDoc delivered by the converter system.

Secondly, it is also a generic shorthand reference for all store systems (point-of-sale or merchandise

management systems).





ALE technology is used in conjunction with the POS Interface and the EDI Interface to

automatically prepare master data changes to be sent to store systems.

ALE controls the generation of change pointers which POS Outbound uses to create multiple

message types.

Outbound data flow is handled in the following manner:

1. Users maintain master data and when they save it, database tables are updated, a changedocument is created and a change pointer is also created.

2. Nightly, when the outbound and/or Assortment List report is run, the change documents and

change pointers are analyzed and changed data from the database tables is used to build master

IDocs.

Note: The POS interface assigns the site and prepares a site specific IDoc for each site

affected by the master IDoc.

3. The IDoc is passed to the EDI interface port designated in the Outbound profile, and when one

site IDocs are completed, the trigger file is created and the system prepares the next site’s data.

4. The converter checks the trigger file (status) to identify the location of the IDoc files and the

IDoc files are copied to the converter.

5. When the converter has received the file, it sends a status message and it deletes the IDoc file at

the EDI interface.

6. The converter handles all communication with the store. If a store cannot be reached, the

converter sends an error message back to R/3.





SAP recommends that the inbound message data flow be organized as shown. The POS converter

communicates with the POS system(s) via a WAN (Wide Area Network) and with the R/3 system

via a LAN (Local Area Network). Inbound data flow should then proceed along the following steps:

The POS converter receives data from a store system, converts them to the IDoc format, and

stores the resulting IDocs in a file (one per store and IDoc type) on the POS converter server.

1. The IDoc file is then copied, via remote copy, to the R/3 application server.

2. The IDoc file is deleted from the POS converter server.

3. Subsequently, the POS converter performs a remote function call (RFC) of the C-program‘startrfc’ on the R/3 application server, with the location of the IDoc file on this server passed as

one of the parameters. This C-program triggers the concluding processing of the inbound data:

4. The ABAP report edi_data_incoming is started automatically and reads the IDoc file on the R/3

application server. The IDoc data are saved in the R/3 database in tables EDIDC, EDID4 and

EDIDS.

5. The IDoc file on the R/3 application server is deleted.

6. Finally, for each newly arrived IDoc, the system determines the corresponding EDI partner

profile for the message type to post the information to the appropriate application. This can

happen either directly by a function module, or indirectly (via workflow or process technology).





The POS Interface provides an inbound data simulation tool to facilitate testing the customizing

settings of the inbound messages, as well as underlying functions (e.g. pricing procedures, G/L

account determination).

Technically, the simulation replaces steps 1 - 5 of the live scenario by generating an inbound IDoc

directly on the R/3 database, and then posting the data (step 6).

Note: The (data) fields in a given IDoc type used in inbound simulation do not generally match the

fields on the corresponding simulation screen 1-to-1. Some IDoc fields cannot be filled throughsimulation at all (e.g., because they are no longer used), some others are calculated from severalfields on the corresponding simulation screen. Conversely, some simulation screens contain fields

that may, in some circumstances, be necessary to send, but are currently not contained in thecorresponding IDoc type.

Warning: The POS simulation tool generates business data (e.g., sales, goods movements, financialtransactions, ...) that the system does not distinguish from genuine data. Hence, POS inbound

simulation should NOT be used in a productive system for testing!





SAP Retail uses profiles, which are collections of standard information that are needed repeatedly in

similar combinations for maintenance of different objects. They act as data entry tools and simplify

the management of data.

One profile may be used by many sites, but each site will have only one outbound, inbound and

assortment list profile.

All the profiles associated with store communication are linked through each store’s Site Masterrecord.





The Customer number associated with each site links to the partner number in the EDI Partner

Profile.

The EDI Partner Profile is created to provide message handling information that is required by SAPRetail to send or receive messages.

The EDI Partner Profile is unique to each site.





Although it is not a profile, ALE Activate Messages function is the location where message types

are “turned on.” The ALE function itself must be turned on by activating the “Activate Generally”

option in the IMG before the active messages will work.

Messages are either on or off. So, if one store requires a particular message type, that message type

is created for all stores.

The link to the Site Master is through the message types assigned to a partner number in the EDIPartner Profile. If a message type is activated in ALE and not activated in the site’s EDI Partner

Profile, the message type will not be transmitted.





The POS Outbound profile is the repository of outbound specific information. One POS Outbound

profile can be used for many sites.

The Outbound Profile is used in conjunction with the EDI Partner Profile and the ALE Activatemessage types to control the flow of message types to the stores.

Once the POS Outbound profile is created, its name is entered into the store Site Master record

which creates the link between the store and the outbound processing information.





The POS Inbound profile is the repository of inbound specific information. One POS Inbound

profile can be used for many sites.

The Inbound Profile is used in conjunction with the EDI Partner Profile to control the flow ofmessage types to SAP Retail.

Once the POS Inbound profile is created, its name is entered into the store Site Master record which

creates the link between the store and the inbound processing information.

Specific handling of inbound data requires several different types of information, depending upon

the particular inbound messages you use. These details are described later in the course.





The Assortment List profile is a particular POS Outbound IDoc type. It relies on a separate profile

for communications to the stores. The Assortment List is covered in more detail in a subsequent unit.

The Assortment List profile and EDI Partner Profile are linked through the message type which must be activated in the EDI Partner Profile.

The Assortment List profile links to the store though the assortment list profile name and through the

listing type that is also recorded in the Site Master record.





IDocs are an SAP tool for communicating business data between an SAP R/3 system and a partner

system. Just as different business documents may have different data structures, there are different

IDoc types.

SAP R/3 provides in excess of 100 such IDoc types to cover most standard communication needs,

and these are processed by the system’s EDI Interface. SAP Retail provides an additional 25 IDoc

types used specifically to communicate between an SAP Retail system and a store system through

the POS Interface. In addition to the basic IDoc types, the system provides tools to create customer-specific extensions

of existing IDoc types. This is done by including additional data fields required for in-/outbound

communication in data segments (usually called E1WXX01) that are specifically reserved forcustomer enhancements. User exits (i.e., ABAP functions of an assigned name and source code to be

defined by the customer, that are called at a particular point within an application’s ABAP source

code) are provided to fill these additional fields on outbound communication, and to read and

process data transmitted via these fields on inbound communication.





Each IDoc (inbound or outbound) consists of the following three components:

- Exactly one control record exists per IDoc containing partner information regarding the sender,

the receiver, and the message type. These are stored in database table EDIDC.

- One or several data records made up of a hierarchical segment structure containing the actual

business data. These data may represent business documents such as store orders, assortment

lists, etc., or single line items, as in the case of aggregated sales or stock counts.

For inbound IDocs, each group of data segments that is processed together (e.g. all segments

representing a particular store order) in the POS Interface, is referred to as an IDoc range. Each

such IDoc range has a POS status, that reflects the result of its inbound processing, and

determines the further processing to which the IDoc range may be subject. IDoc data records

are stored in database table EDID4.

- One or several (EDI) status records that document the life cycle of the entire IDoc. These are

stored in EDIDS.

All control records, data records and status records contain a numerical key (IDoc number) that

identifies the IDoc client wide. It is by this key (and the client number) that all records belonging to

one IDoc are linked together on the system’s database.

Which data can be included in a particular IDoc, possible groupings of such data to segments (e.g.

PO header, PO item, ...), and the hierarchical order between these segments, are defined by the IDoc

type.

The structure of all IDoc types is documented in the system and can be retrieved online, as well as

exported, e.g., as a html-file, or as a C-header file.





Each individual IDoc is characterized by exactly one IDoc type and exactly one (logical) message

type, both of which are stored in its control record.

While the IDoc type describes the (syntactical) structure and hierarchical order of the data

transmitted in an associated IDoc (e.g., which header segments, which subordinate segments, which

fields in which segment, length and data type of fields, ...), the message type describes the semantics

of the data transmitted in the IDoc, i.e., how the recipient should interpret the IDoc data.

Consequently, the message type enables the system to distinguish business documents that, from thedata structure point of view, are identical.Example: The (standard) IDoc type ORDERS01 may be used to transmit both purchase orders

(message type ORDERS), purchase order confirmations (message type ORDRSP), as well as

notifications on change of purchase order (message type ORDCHG).

Thus, some IDoc types may be combined with several message types. The converse is also true,

hence the relation between IDoc types and message types is many to many.





Details of the data record structure associated with any particular IDoc type can be displayed in the

form of a structural tree. This tree provides a drill-down functionality to look at the definition of

segments, and eventually the definition of individual data fields, at any level of dis/aggregation.

The example shown represents part of the data record structure of IDoc type WP_PLU02, which is

the ‘carrier’ for article master data, both for outbound and inbound.

Each IDoc of this type consists, at the top level, of 1 to 9999999 mandatory ID segments E1WPA01.

Each of these segments may contain some application data (segment fields), plus further, optionalsegments E1WPA02, E1WPA03 , E1WPA04, E1WPA07, E1WPA08, E1WPA09, E1WXX01 (forcustomer enhancements). While the segment E1WPA02 (data) may occur at most once within a

particular E1WPA01-segment, the others are allowed up to 99 occurrences.

Each of the subsegments of E1WPA01 contains their respective data (texts, material conditions,

condition values, ...), with E1WPA04 and E1WPA09 each containing a further subsegment.





A drill-down on a folder representing data fields of a particular segment lists all fields assigned to

that folder, as well as for each of these fields, a short description, its internal length (in bytes), the

corresponding data type, and a brief definition of the field.





The prior two slides show how the IDoc is described in the system. This slide depicts how the data is

structured in an IDoc when it is transferred to or from the converter.

How the system structures an IDoc can be seen using IDoc Type (parser).





The EDI status of an (entire) IDoc (inbound or outbound) primarily documents the passing of the

IDoc through ALE/EDI during transmission, but may also be updated by the subsequent inbound

processing of the IDoc that reports back to the EDI status. Furthermore, the EDI status of an IDocmay also change as a result of user intervention, e.g., by editing a faulty inbound IDoc in the POS

Monitor before resubmitting it for processing.

EDI status < 50 apply to outbound messages, those > 50 to inbound messages.

In addition to a global EDI status, each range of an inbound IDoc, that has successfully passedthrough ALE/EDI, is assigned a POS status by the inbound processing of the range in question. ThePOS status reflects the state reached by an IDoc range during inbound processing, i.e., whether the

range has been successfully posted by the corresponding application, or at what stage of the inbound

processing which error was encountered. The POS status of an IDoc range may also be changed

manually in the POS Monitor.





EDI Port identifies the address of the port and its type. The name of this port must be

SAP<system id>.

The port type for POS communications is File. Other types provided are:

Transactional RFC- for use with distributed ALE.CPI-C - for use in communicating with R/2 systems

Internet - for use with internet communications.

Your System Administrator should create a main POS directory at the operating system level with

three sub directories for outbound, inbound and status to make the management of these files easier.

Once your directories are created, you identify them for ALE and EDI when you define the port and

type. The directories must be created on all R/3 message servers that are used to communicate with aconverter.





Control file customizing is not required for transmission via POS interface.

Suggested values for outbound file:

Directory /enter the directory path for POS outbound/

Outbound file

Function module EDI_PATH_CREATE_POS_UNIX_DOS

The function module address plus the blank outbound file field combine to allow for the IDoc file

name to be dynamically created each time an outbound process is run.(SAP recommends that youuse this module.)

Although, on inbound communication, the location of the IDoc file on the SAP application server is

passed by the POS converter to the C-function ‘startrfc’, ALE/-EDI requires that a recipient port (oftype ‘File’) be defined in ALE-customizing of the SAP R/3 system. The name of this port must be

SAP<system id>

and is specified in the control record of each inbound POS IDoc.

Status file for ease of handling should be a separate subdirectory of the POS directory:

Suggested values:Directory / enter the directory path /

Status file STAT

Function module

You enter the EDI Port name in the EDI Partner Profile, Outbound section in the Receiver port field

for the system to place outbound and status files in the proper location.





Each store must have an EDI Partner Profile before data can be transmitted either outbound to the

store or inbound from the store. The information on the primary screen carries over to both the

inbound and outbound sections of the EDI Partner Profile. You define the following information foreach store:

Partner number -- Use the Customer number of the store

Partner type -- For POS use ‘KU’ which identifies the partner as a customer

Partner class -- If you have created a class of stores

Partner status -- Must be active

Telephony -- Only used in standard EDI with external customers or vendors

Receiver of Notifications -- The following fields are filled with default information if Workflow has been established in PD-Org.

Typ(e) -- Identifies the kind of name to expect in the ID field. Options include, Workcenter, Job,Organization unit, Person, Position, User

Lang(uage) -- In which a message is to be issued

ID -- Must correspond with Type field described above. For example, if the type is Work Center theID must be the name of the work center





You must list each message type that you will send to the store in the Outbound section of the EDI

Partner Profile.

Outbound options - Establishes how you wish communication to take place.

- Receiver port -- Enter the name of the port already defined in the EDI Port profile forOutbound IDocs.

- Transfer IDoc immed. or Collect IDocs-- Use Collect IDocs for all Outbound message types.- Start subsystem or Do not start subsystem-- Not necessary.

IDoc type - Correlates to the function module that is called to process communication.

- Basic IDoc type -- Provides necessary information to perform communications with no

additional data.

- Extension-- Customer enhancement to basic IDocs

- Syntax check flag-- If the field is selected, the system stops if a syntax error is encountered.

Leave blank to have the IDoc posted with a flag for a syntax error.

- Seg. Release in IDoc type-- Optional, release version code.

Receiver for notification--specifies the ‘agent’ the system should notify in case of errors during

inbound processing.

- EDI settings -- Communication settings.

- EDI Standard-- SAP supports E, EDIFACT and X, ANSIX12

- Message type-- Optional, the EDIFACT or ANSIX12 message type

- Version--Optional, enter the version if you are using the prior field.





You must customize the following parameters for each message type that a store is allowed to send

to the central SAP Retail system in the inbound section of the store’s EDI partner profile:

Test flag -- Must be set to use the simulation tool to send an IDoc. Leave blank for a productive

message.

Process code -- Only parameter (apart from client number) that determines, via database table

TEDE2, which function module is called to process the inbound data.

Syntax check flag -- If the field is selected, the system stops when a syntax error is encountered.

Leave blank to have the IDoc posted with a flag for a syntax error.

Processing mode -- Determines, whether incoming IDocs are to be processed immediately, or

later in background.

Receiver for notification -- Specifies the ‘agent’ the system should notify in case of errors during

inbound processing.

Upon receipt of an IDoc from a store, the POS Interface uses the EDI partner profile, along with the

POS inbound profile assigned to it, which controls the inbound processing of the IDoc, through the

seven keys partner number, partner type, message type, partner function, message code, messagefunction and test, as read off the IDoc’s control record.





The POS Monitor, together with the POS Inbound Processing Unit and POS Outbound Processing

Unit, make up the POS Interface. It is through this interface that an SAP Retail system is able to

communicate, through a POS Converter, with a store based POS system.

The main tasks of the POS Monitor are to document both inbound and outbound communication

between the SAP Retail system and partner systems, and to provide tools to view and edit this

information. Only POS IDoc types can be displayed in the POS Monitor, because the distinction

between POS IDoc types and the remaining ones is hardcoded in the system! The POS Monitor provides functions to obtain either a top-level, or a detailed view of a selected

portion of both inbound and outbound communication in the SAP Retail system. It may, for

instance, be used to inform the user which assortment lists were downloaded to a store or range ofstores during the last two weeks, or which inbound IDocs were rejected by the system.

In addition to displaying information on past communication activity in the system, the POSMonitor also allows the user to edit IDocs or to change the POS status of ranges of an inbound IDoc.





According to the selection criteria specified, the POS Monitor displays the matching communication

items, sorted into categories that are arranged hierarchically.

At top level, there are four categories:

Outbound Processing,

Outbound message communication,

Partner system messages,

Inbound processing.

All except the ‘Partner system messages’-category are divided into two subcategories: one for itemsthat were successfully processed, and another one for those not fully processed.





The main ‘Inbound processing’ features of the POS Monitor are:

Starting at any (non-terminal) node of the POS Monitor tree, you can drill down to display theimmediate descendants of that node, down to individual IDocs and beyond.

For each such IDoc, its unique numeric key, its creation date, and a status are displayed in the POSMonitor.

The status displayed is the EDI status of the entire IDoc if a problem was encountered during EDItransmission. If EDI transmission was successful, the status displayed is the POS status of an IDoc

range within that IDoc.

You may select to edit a single IDoc by double-clicking on the IDoc number, the word IDoc, or the

date. If you select “To be processed” and Process you can activate the Sales Audit Editor with a list

of IDocs, limited by your original selection, that you may edit individually or in groups.

If you select the IDoc status, you may (by a single click on the POS status) change the POS status of

that IDoc range, e.g. by rejecting it, resubmitting it for processing, or triggering its immediate processing.

A further drill-down on an individual IDoc displays any follow-on documents (e.g. billingdocuments, article documents) created during inbound processing, if successful, or errors or

workitems that were generated as a consequence of problems encountered during inbound

processing.





The Sales Audit Editor screen provides the facility to edit IDocs in the Monitor and to reprocess

them as soon as they are corrected.

Individual IDocs can be edited and all IDocs containing a similar error can be processed using the

Mass change function.





Additionally, the POS monitor provides a completeness check for inbound communication.

This check compiles:

a statistic of the number of IDocs received within each message type , as well as the number of

those IDocs that were processed with, or without errors

a summary of the total number of IDocs received, the number of message types within which

inbound communication has occurred, and the number of stores from which inboundcommunication was complete (i.e., from which at least one IDoc was received within each

message type for which inbound communication is defined according to a store's EDI partner profile).





Unit: Technical Aspects of POS

Topic: IDoc Documentation

At the conclusion of this exercise, you will be able to:

• Retrieve technical information about the structure of basic

IDoc types from the system

As a member of the implementation team, you must determine

which POS IDoc type would be best to use to send the stores

article data. You know the large format stores can receive the

Assortment List IDoc, but you are not so sure about the point of

sale servers in the smaller format stores. To start your

investigation, you want to evaluate the Article message and IDoc

type.

1-1 Investigate an IDoc structure by using the IDoc documentation in the system.

1-1-1 If you were to use WP_PLU02 for your smaller stores, which segment

would carry the internal article number?

1-1-2 In what segment is the main EAN/UPC code carried? Is there a segment for

another EAN/UPC in this IDoc.

1-2 Now, check an inbound message type. Select WPUFIB01 to determine if it can

carry the type of financial transaction data you want to collect from your stores.

1-2-1 You require a transaction code to identify your financial transactions, is

there a segment/field identified for transaction types? If there is, which one

and is it a required segment?

1-2-2 Is there any required segment in WPUFIB01? What data fields does that

segment carry?

1-2-3 If this message does not carry all that you require, is there a way you can

attach additional information? If yes, how.





Technical Aspects of POS Exercises


Topic: EDI Ports and Partner Profiles


• Create an EDI partner port

• Create an EDI partner profile with an outbound and an

inbound message.

You are ready to begin testing, but before any messages can be

sent or received there is some System customizing you must do.

The first step to POS testing is customizing the communicationsarea.

Important note: The R/3 locking mechanism is switched off for courses doing Customizing

therefore, it is necessary for you to check that your settings have been saved. Use DISPLAY

after you have saved your changes to confirm that they are recorded.

2-1 The technical members must have already identified your logical system. Before

beginning with the communications area, please check that the system is identified.

2-1-1 Where do you check if the logical system is identified?

2-1-2 What is the name of the logical system you are using today?

2-2 Either you or the technical members of your team must define a port for the

interface. While you are preparing the communications area, you should check if

they have defined one that you can use.

2-2-1 Under which Port type will you find the port definition for the POS

interface?





2-2-2 Use the copy function to create a new port and name it T8##. Remember ##

is the number you are assigned. The name of the directory (created by the

system administrator) where your files will reside is:

2-2-3 What is the name of the Port you copied to create your new port?

2-3 Now you want to create an EDI Partner Profile for your test site T8##. Remember

## is the group number you have been assigned.

2-3-1 While you are testing you will probably test one message type at a time, so

at this point just add one message type to your outbound Partner Profile.

Remember to make the profile active. To send article data to your store,

which message type will you use?

2-3-2 Create a record for that message type. What IDoc type will you use with that

message type?

2-3-3 What other information must you enter for this message type to work?

2-3-4 If you had completed your testing phase and were going to create Partner

Profiles for a lot of stores, how would you go about doing that?

2-4 You probably will want to send article information from the store back to

headquarters. So create an inbound partner profile for your article information thatyou can test with the POS Simulation tool.

2-4-1 What message type will you use for the inbound article data?

2-4-2 Must you set the test box for the message type?

2-4-3 What do you require for inbound message types to handle follow-on

functions?

2-4-4 Do you have to assign a Port to the Inbound Profile? Why or why not?






Topic: IDoc Documentation

1-1 To use the IDoc documentation in the system to evaluate IDoc type WP_PLU02.The menu path to display the structure of an IDoc type is:

Tools Business Communication, IDoc IDoc Basis Documentation

double-click IDoc types

enter WP_PLU02 in the field ObjectName and, leaving all other selection criteria as

defaulted, press button Display Tree (F8).On the subsequent screen, select

E1WPA01 and press Expand Subtree.

1-1-1 The segment that carries the internal article number is field ARTIKELNR in

segment E1WPA01.

1-1-2 The main EAN/UPC is also carried in segment E1WPA01. It is carried in

field HAUPTEAN. No other segment in this IDoc type carries fields foradditional EAN/UPC numbers.

1-2 Back out to the IDoc selection screen. Enter WPUFIB01 in the field ObjectName

and, leaving all other selection criteria as defaulted, press button Display Tree (F8)

1-2-1 Expand the structure tree and you find that IDoc type WPUFIB01 is made

up of three segments. The first is E1WPF01 with the field VORGANGART

that carries the transaction code from the POS system. The segment is

optional.

1-2-2 The only required segment is E1WPF02, item segment, and the fields

associated with it are:

Item number, Assignment, Account assignment obj, Cost center, Amount,

and currency code.

1-2-3 E1WXX01, the customer enhancement segment, can be used to carry

additional information in the IDoc.





Technical Aspects of POS Solutions


Topic: EDI Ports and Partner Profiles

2-1 The system must have a logical system name before you can complete any

communications.

2-1-1 You can check for the logical system name using the following path:

Tools AcceleratedSAP Customizing double-click Edit Project

SAP Reference IMG

Basis Components Distribution (ALE) Sending and Receiving

Systems Logical systems Define Logical system

2-1-2 You can see that DMRCLNT400 is defined.

Now look at the next selection, Assign Client to Logical System. On this

screen you can select Client No. xxx and see that the logical system is

identified as assigned to our client, which is a copy of the training master.

2-2 To define a port that will define where to send your outbound files so the converter

will find them. Take the paths from the SAP standard for Retail tree:

Tools AcceleratedSAP Customizing double-click Edit Project SAP

Reference IMG

Basis Components Distribution (ALE) Sending and Receiving Systems

Systems in Network Asynchronous Processing Assigning ports Define

port

or

Tools Business communication, IDoc double-click Port Definition

You can also use Transaction code WE21.

2-2-1 On the left side of the screen, is a tree with the available port types. Expand

the Port type File and see other ports for the POS interface. Your port type

is also File.

2-2-2 The process you use to copy a Port is as follows:

Select the port name you wish to copy.Press the Copy icon. Enter your Port name in the to port field.





Field Name or Data Type Values

Message type WP_PLU

Receiver port T8##

IDoc Basic Type WP_PLU02

Output mode Collect IDocs

Start subsystem

2-3-4 When you are sure of the message types and IDoc types you are going to

uses, both inbound and outbound, create an EDI partner profile with all your

correct settings, then copy it to as many stores as necessary. Or, you can

copy the partner profile to your reference store and use an extended copy

function when creating your other stores.

2-4 Now, create the EDI partner profile for inbound article messages.

From the EDI Partner profile screen for your store TS##, you may have to scrolldown the work area to display the section for inbound parameters.

Press the Create Inbound Parameters button below the Inbound parmtrs. Section on

the work area. On the next screen, create your message details.

2-4-1 WP_PLU, message type names with the third character an underscore

(_) can be used in both directions.

2-4-2 Yes, you do need to set up WP_PLU in the inbound parameters with the

test box selected to use the simulation tool for inbound testing.

2-4-3 Rather than an IDoc type, you must enter the process code (WP_P,

Product Master) to handle the follow-on functions.

2-4-4 No, you do not. The converter sends the inbound IDocs to the correct

directory and tells the system where the IDocs are located.





SAP AG 2001

Transaction Logs

Conversion Categories

SAP AG

Contents:

Unit: Mapping Store Systems to SAP Retail





SAP AG 2001 SAP AG


Describe the types of data that might require mapping

List and describe the Conversion Category parameters

Configure a Conversion Category

Mapping Store Systems to SAP Retail: Objectives





SAP AG 2001


Unit 8 Conclusion






Unit 1 Introduction

Course Overview





SAP AG 2001

Mapping Store Systems to SAP Retail

Tender Cash - 0010

Check, personal -0020

Check, payroll - 0021

Store Card - 0040

Cr. Card, AMEX -0050

Transaction

Sales -0001

Staff Sales - 0101

Cashier pickup - 04

Returns - 06

Discount types

Promo - 0018

Coupon - 0018

Tender Cash - 100

Check - 102

Store Card -108

Transaction

Sales - 100

Staff Sales - 300

Exchange - N/A

Discount types

Promo - N/A

Coupon - N/A

Employee - 162

Tender TypesCash - PTCS

Check -PTCH

Voucher - PTVO

Invoice - PTBL

Transaction Types

Sales - PN10

Staff Sales -

Returns

Discount Types

Promotion -

Coupon -

Payout Reasons

Payin Reasons

SAP Retail Stores - System A Stores - System B

Not all store conditions are pre-configured in SAP Retail. Therefore, as a part of the planning

process you should perform a thorough evaluation of the transaction logs from several stores. When

you have a clear picture of the transactions, tenders, and other items that the stores currently capture,

you can map those items to SAP Retail. In some cases, as with the condition type for Cash, PTCS,the customizing is provided.You can use this as a guide for modeling additional tender types or

payment methods.

When your map is complete and the customizing completed, you are ready to record the map in the

Conversion Categories.





SAP AG 2001

EDI

Partner

Profile

R310

Site

Master

R310

IP00

USD

AL01

OP00

POS

Outbound

Profile

OP00

Conversion

Details

CC00

CC00

Conversion

Parameters

CC00

US00

Conversion

Category

CC00

X

X

X

XXXX

XXXX

OP00

POS

Inbound

Profile

IP00

XXXX

X = Y

Customize Conversion Mapping

Inbound and outbound messages use the same conversion categories. The inbound message process

access the conversion categories directly, taking the store POS codes as delivered by the converter

and SAP Retail translates them into the corresponding SAP Retail terminology.

Outbound messages require an additional Customer Enhancement to prepare the translation fromSAP Retail to store POS terminology. A User Exit and sample program are provided for each

outbound message type. See Function group XWPD in the Repository Browser for these.





SAP AG 2001

Conversion Parameters: Customizing

IDES Smart Retailer Inc.IDES SmartIDES Smart Retailer IncRetailer Inc.. C

ustomize

Conversion parameters

KeyCC00Conversion category

Con.transaction type-SpR

Con. condition type

Con. tax code

Con.movement type

Con. language

Con. Transaction type

Con. mdse categories

Con. Unit of measure

Curr. Code conversionCon. Payment methods

Tax classification con.

Control

CC00

First, a Conversion Category is created. Then, Conversion Parameters must be selected and

customized if the POS system in the stores use values different from those of SAP Retail.

These flag fields allow you to identify which parameters must be converted from R/3 codes to point

of sale system codes. Selecting a parameter in this list requires that the corresponding code pairs beidentified in the proper detail parameter screen.

No further action is necessary if conversion is not required.





SAP AG 2001

Conversion Detail: Customizing

IDES Smart Retailer Inc.IDES SmartIDES Smart Retailer IncRetailer Inc..

Customize

Conversion POS condition types

CC00 POS

code

Conversion

categoryDes.Des. Condition

type

CC00 PN10

CC00 HB00

CC00 STTX

185

187

163

If a conversion category parameter is selected for conversion, a corresponding detail entry must be

maintained. The detail screens are filled in similarly as the example in the slide. This example is for

condition types.

Condition type parameter is selected for conversion.

You must specify the condition types that are uploaded from the stores. These will be the condition

types identified in your POS calculation schema.

The Condition types displayed in the slide are those that pass the sales value, discount value, and

tax value to the pricing function in billing.

Generally, you will require at least one condition type group for each country because of the

differing tax conditions.

You may also require different condition type groups for each POS system.

In addition, you must activate the user exit for the message and use or modify SAP default coding.





SAP AG 2001 SAP AG

Summary

R/3 and most POS systems use different values to

identify similar objects. A mapping project must be undertaken to

determine the values necessary to communicatebetween the systems.

Conversion categories provide the facility totranslate these values.

Inbound messages use the Conversion categorytables directly to perform the translation.

Outbound messages additionally require aCustomer enhancement to perform the translation.





Mapping Store Systems to SAP Retail Exercises


Topic: Customizing Conversion Categories


Customize a conversion category.

You have checked the transaction logs from your smaller store

system. In the process, you have determined that it uses

numerical codes for payment types, transaction types, etc. where

SAP Retail uses alpha codes.

3-1 Just to convince yourself that the conversion can be handled correctly by SAP

Retail, you are going to create your own Conversion Category. Later, you will map

each transaction and condition but to begin testing, you will only convert the

payment types. Name your category CC##.

3-1-1 What path do you take to define your Conversion Category?

3-1-2 What must you do first after naming your Conversion Category?

3-1-3 The payment types that will be used later in this course are:

PTCS, PTCH, PTVO, PTBL and PTAM. Use 150 through 154 as your store

system conditions.

Note: Do write down the code relationships you are using. It will be important in a

later exercise.





Store Systems to SAP Retail Solutions


Topic: Customizing Conversion Categories

3-1 You are creating a conversion category.

3-1-1 To define your Conversion Category, take the following path:

Tools AcceleratedSAP Customizing double-click Edit

Project(SPRO) SAP Reference IMG

Sales and Distribution POS Interface Adjustments Conversions


Select New Entries and enter Conversion Category: CC##.

3-1-2 For your next IMG activity, select Conversion parameters. Press New Entries and enter your conversion category name. Select the field Conv.

Payment methods. Press Save and Back .

3-1-3 Now you must identify the payment methods and their POS counterparts.

Select POS Payment Method Conversion. Enter the following values:

Conversion

Category

Payment Methods Condition type

CC## 150 PTCS

CC## 151 PTCHCC## 152 PTVO

CC## 153 PTBL

CC## 154 PTAM





SAP AG 2001

Outbound IDoc/message types Condition Type Groups POS Outbound profile POS Outbound Reports Bonus Buy Promotions POS Inbound Transactions POS Inbound Customizing Using Retail Store

SAP AG

Contents:

Simple POS System Case Study





SAP AG 2001 SAP AG

Describe the business informationcommunicated with simple POS systems

Customize POS Condition Type groups Set up and run Alternative Method for

Condition Analysis Customize POS Outbound profiles Set up POS Outbound Reports Handle Bonus Buy Situations Customize some Inbound POS profiles Simulate some Inbound POS messages Describe using SAP Retail Store

At the conclusion of this unit, you will be able to:

Simple POS Scenario : Objectives





SAP AG 2001


Unit 8 Conclusion






Unit 1 Introduction

Course Overview





SAP AG 2001

Simple POS System Case Study


Nightly:

Article + PriceEAN

Nightly:

Sales ReceiptsLoss Prevention

Converter

Retail Store

Vendors

ITS Server

POS Server

As Required:

Logistics Info

BW

Unit Case Study:

- Smart Speciality is installing SAP Retail. The company has many small stores. Their storeshave fairly simple POS systems which limits how much data they exchange with headquarters.Smart Speciality expects at some point to replace their POS systems but in the interim willmake use of personal computers and SAP Retail Store to handle their logistics information thathas been handled manually up to now.

- Smart Speciality is evaluating WP_PLU and WP_EAN as outbound message types to supplythe store with data to drive their cash registers.

- The headquarters merchandise manager wants the team to model Bonus Buy functionality todetermine if it will support her plan to aggressively pursue manufacturer discounts that she can pass on to customers.

- The merchandise manager has also requested that the stores report sales using Sales as perReceipt which will give her more detail about companion purchases and input into store layout.

- The accounting team is also pleased with the Sales as per Receipt plan as it provides them withgreater detail and coupled with the Loss prevention message will lead to greater financial

control in the stores.- The inventory management folks are very interested in the types of information Retail Store

will provide them.

Some technical details:

- The technical team supporting the business believes that using the Alternative ConditionAnalysis to prepare the outbound data will improve performance and has asked that we set upand test the functionality.

- They have also completed sizing the hardware and suggest that we process POS messages usingmultiple application servers.





SAP AG 2001

Describe the type of business informationcarried by outbound messages

Customize POS Condition Type groups

Customize POS Outbound profiles

Set up POS Outbound Reports

At the conclusion of this topic, you will be able to:

SAP AG

POS Outbound: Topic Objectives





SAP AG 2001

SAP Retail


Using ALE Technology change pointer

analysis, create change document

Download data to store POS systems

Report: prepare POS master data

Store POS Server

Report: create trigger file

1

4

3

2

POS Outbound: Process Steps

Article(s)

add new articles new EAN/UPCs change retail price change margin include in a promotion

POS Outbound master data message types are handled similarly using standard ALE technology andchange pointers for IDoc creation.

During initial startup report RWDPOSIN is run to prepare all the necessary data for the first time

and transfer it to the POS systems. This Initialization should be scheduled in the background andmust complete successfully (status: Preparation OK) before change messages can be created.

In cases where all data is at the store POS system, the dummy initialization program (RWDPOSDU)which transfers no data but generates the required entries in the status tables for POS outbound can be run instead of the the initialization report.

After either initialization is complete, whenever a user maintains master data, the application createsa change document. If the changed field was transmission-relevant, ALE creates a change pointerthat identifies where the data can be found.

RWDPOSUP, the change message report, is scheduled to run in the background at regular intervalsafter close of business. This report:

• analyzes the changes that have occurred since the last time the data was successfully prepared

• analyzes which sites are affected by the changes

• prepares the changed data into site specific IDocs and places them into the outbound directory

• creates a trigger file, which contains the paths and names of all the IDoc files to be downloaded,into the status directory which the converter accesses.





SAP AG 2001

Article and condition WP_PLU02 WP_PLUEAN/UPC assignments WP_EAN01 WP_EAN

Customer WP_PER01 WP_PER

Exchange rates WPDCUR01 WPDCUR

Products (Follow-on items) WPDNAC01 WPDNAC

Material group master WPDWGR01 WPDWGR

Taxes WPDTAX01 WPDTAXSet assignments WPDSET01 WPDSET

Physical inventory WVINVE02 WVINVE

Bonus Buys** WPDBBY01 WPDBBY

Assortment list* WBBDLD02 WBBDLD

Business Data (Outbound) IDoc type Message type

* * require special handling

Types of Outbound Business Data

Specific master data must be available at the point of sale in a store for any transactions to take placeat an electronic cash register.

Point of sale systems have a variety of capabilities, many do not have large data bases to contain the

same detailed master data that R/3 contains. Therefore, SAP Retail provides several message typesto carry critical master data to the stores.

The types of outbound master data that can be processed via SAP Retail POS Interface and thecorresponding IDoc types and message types that may be used as a ‘carrier’ for each of these dataare shown.

The Bonus buy message is only sent by direct request.

The Assortment list data and message types are described separately as it is a special message type.





SAP AG 2001

EDIPartner Profile

R310

SiteMaster

R310

IP00

USD

AL01

OP00

POSOutboundProfile

OP00

CC00

ConditionType

Group

US00

US00

ALEActiveMessages

DetailsConditions

US00

Calc

Schema

CAL1

XXXX

XXXX

OP00

Customize Automatic Outbound Processing

The POS outbound profile, the EDI partner profile and ALE work together to capture information to be downloaded to the stores.

Condition type group and its detail condition types are linked to the POS outbound profile.

The conditions entered in the Condition type group must be the same as those in the CalculationSchema assigned to this store.

Conversion parameters provide the preliminary link to the translation of R/3 values to point of salevalues.

A User Exit is supplied and required to facilitate outbound processing of conversion parameters.





SAP AG 2001


Customize

Activate Change Pointers for message types

WPDNAC

WBBDLD

WPDSET

WP_PER

WP_EANWPDWGR

Log. Message Typ.

WP_PLU

Activ

Activate Change Pointers: Customizing

First, activate the ALE functionality in customizing by selecting Activate Change Pointers(generally).

Then “turn on” the message types for which you desire change pointer monitoring.

For POS Outbound, the message analysis uses multiple processing of change pointers for differentmessage types so that separate change pointers do not have to be created for each message type. Youmust take the following links into account when activating change pointers.

Log. msg type Object Message types to be activated

WPDWGR Merchandise Categories WPDWGR

WP_PLU Article Master WP_PLU

WP_EAN EAN/UPC references WP_EAN and WP_PLU

WPDSET Set Assignments WPDSET and WP_PLUWPDNAC Follow-on items WPDNAC and WP_PLU

WP_PER Customer data WP_PER

WPDTAX Taxes No change pointer analysis

WPDCUR Exchange Rates No change pointer analysis





SAP AG 2001


Customize

US00

Cond.type

Cond. TypeGroup

Des.Des. Note endperiod

POS Condition Type GroupPOS Condition Type Group

US00 VKP0US00

US00 UTXJ

VKA0

Condition Type Group: Customizing

You must identify the condition types that you are using in the pricing calculation schema in SAPRetail, that you want to analyze for changes and transfer to stores. You combine all the conditiontypes together that will be used at a location in a Condition type group.

Generally, you may require one condition type group for each country because of differing taxcondition types.

You may need to create different condition type groups for different POS systems.

As shown in the example, we are identifying Sales Price (VKP0), Promotion prices (VKA0), and aTax code (UTXJ) as conditions that are transmission relevant.





SAP AG 2001


Customize

OP00 POS outbound profile

Maintain Profile for POS OutboundMaintain Profile for POS Outbound

POS category

Conversion category

Lead time

Exch. rate type

. .

.

.

Control

KeyOP00POS outbound profile

POS Outbound Profile: Customizing (1/4)

Each store’s POS outbound profile provides a refinement to IDoc processing of all outgoingmessages.

POS category - You may enter a name in this text field for identification. For example, you might

want to identify the stores in one state with the POS system type, IBM-RA, AZRA and later youwould know to assign this profile to new sites with a similar location and POS system.

Conversion category - Enter the name of the Conversion category that you created for the point ofsale system in this store.

Lead time - The future period for POS outbound that determines the number of days in the futurefor which data is prepared and transferred. For example, if you download to a store once a weekyou would enter 7.

Exch. rate type - Key that you use to store exchange rates for currencies in the system.





SAP AG 2001


Customize

OP00

Maintain Profile for POS OutboundMaintain Profile for POS Outbound

Control

Cond. type group

Person master reduc.

Status communic. OK

Recipient determin.

Error mode

Reduced art master

.

.

.


Cond. type group - Enter the name of the Condition type group you created so that the conditionsare analyzed and downloaded to the store. If you leave this field blank, prices cannot be determinedor downloaded.

Person master reduc. - Enter the name of the logical message type for reducing the person masterIDoc structure that you created in the ALE environment. If you leave the field blank and theWP_PER message type is active the entire person master is downloaded. Performance is improvedif a reduced person master is created.

Reduced article master - Enter the name of the logical message type for your reduced article masterIDoc structure that you created in the ALE environment. If you leave the field blank and theWP_PLU message type is active, the entire article master IDoc is downloaded.

Status communic OK - The system places a code in this field after outbound processing is completeindicating that communication was completed successfully.

Flag settings:

Recipient determin. - This flag is only used when transferring data through direct ALE transfers.

Error Mode - Set this flag if you want the outbound program to terminate when an error isencountered. If left blank, the incorrect items are recorded in a log and the outbound programcontinues with the next item.





SAP AG 2001


Customize

OP00

Maintain Profile for POS Outbound

Sales permitted for all merch.cats

Cross ref. Material/EAN

Transfer merch. catgry article

Cross ref. follow on item/materialAddit.del. Records for EAN ref

Automatic data interchange


Flag settings continued:

Automatic data interchange- This flag when set indicates that data is transferred to and from thePOS systems in the store. If it is not set, the communication profile is used to control only the

assortment list.

Sales permitted for all merch.cats - When this flag is set, all merchandise categories are preparedfor download to the store. If it is not set, data is prepared for only merchandise categoriesassigned to the store.

Cross ref. Material/EAN - Set to generate an article change when an additional EAN/UPC ischanged. This is used for POS systems that cannot manage EAN/UPC references and need a fullarticle master for each EAN/UPC version of the article.

Addit.del.Records for EAN ref - Set to prepare an additional deletion record with the deletedEAN as the main EAN when an additional EAN deleted.

Cross ref. Follow on item/material - Set if the POS system cannot handle a separate emptiesmessage from a change to the follow-on item, but must receive a complete article master.

Transfer merch. catgry article - Set to prepare an article master record with merchandise categorychanges when merchandise category information alone is not sufficient.





SAP AG 2001


Customize

Maintain Profile for POS Outbound

OP00

Do not prepare follow-on items

Do not prepare article

Do not prepare sets

Do not prepare taxes

Do not prepare exchange rates

Do not prepare customer

Do not prepare merch. catgry

No POS receipt texts

No factory calendar


These flag fields allow you to explicitly disallow data preparation for a particular store when themessage type is activated for other stores. No action is necessary if the message type is not activated.

Do not prepare article - If this flag is set, article data (including EAN/UPC references) is not

prepared for outbound processing.

No POS receipt texts - If this flag is set, receipt texts are not prepared for download. If receipttext in not required at the stores, set this field to improve performance.

Do not prepare follow-on items - Set this flag if you do not want follow-on items prepared fordownload to the store.

Do not prepare sets - Set this flag, if you do not want sales set data prepared for download to thestore.

Do not prepare merchandise category - Set this flag, if you do not want merchandise categorydata prepared for download to the store.

Do not prepare exchange rates - Set this flag, if you do not want exchange rates prepared fordownload to the store.

Do not prepare taxes - Set this flag, if you do not want tax rates prepared for download to thestore.

Do not prepare customer - If this flag is set, you do not want customer data prepared fordownload to the store.

No factory calendar - Set this flag, if your stores are open seven days a week. The system doesnot take a factory calendar into consideration when preparing outbound data.





SAP AG 2001

Description of Process

Alt. Condition Analysis

Initialization

Dummy Initialization

Change message

Direct request

Reorganization

Subsequent creation of

trigger files

POS Interface Program

RMEBEIN4

RWDPOSIN

RWDPOSDU

RWDPOSUP

RWDPOSAN

RWDPOSRS

RWDPOSTG

Outbound Processes

Alternative Condition Analysis report, if used, should be run before executing the Change messagereport.

The Initialization reports should be run prior to going live. Regardless of which type of article

message you use to populate your POS systems, each store must be initialized before Changemessage outbound processing can be used.

Change Message report for POS Outbound can be set to run nightly and the system checks for storeopen days. If, for example, some stores are open 7 days and others only 6, the report only preparesdata for the stores that are open on the following day and not those that are closed.

Direct request or manual reports are used for testing, replacing missing store data, or to change a particular price when you do not wish to run the entire change analysis. These reports can still be setto run in the background, saving system resources.

Reorganization reports are described in the unit on performance issues.

Subsequent Creation of trigger files is a report that is used infrequently to check if there is any prepared data for which a trigger file has not been created. A trigger file might have been not created

because reorganization reports were not run and sufficient disk space was not available for the file.





SAP AG 2001

Alternative Condition Analysis

ConditionChanges

Worklist...….….

POS RelevantConditionChanges

The system generates a change pointer for every condition change that is made in the system. Someof these condition changes are not relevant for the stores.

The alternative method of condition analysis provides a method to analyze the changes once for each

application and generates a work list for each of these applications.

In POS outbound and Assortment List the work list is processed rather than all condition change pointers, resulting in improved system performance.

You define the specific conditions and their table names in the Condition document index beforeyou can take advantage of this improvement.





SAP AG 2001


Customize

Cond.type

Count.. No.Des. Table

10 VKP0

20 VKA030 UTXJ

Article per PlantArt.per SOrg/DChDomestic Taxes

Maintain the Document IndexMaintain the Document Index

71

732

Alternative Condition Analysis: Customizing

When Change pointer generation is activated, the system records all changed conditions not justthose relevant to POS. By using the Alternative method of Condition analysis, you can strengthen performance by limiting analysis to a worklist of POS relevant conditions.

You specify which condition changes are relevant for each application in this table and run the program RMEBEIN4.

Ensure that you identify all POS relevant condition types here for their inclusion in the conditionworklist.





SAP AG 2001


Store System

StoreStore

MMM

MMM

Document categories

Def Ine

Control Data

POS outbound

Purchasing documents

Pricing documents

PO-based load building

Flag processed change pointers for reorganization

Process change pointers flagged for reorganization

Flag all change pointers for reorganization

Condition change date to

Restrictions

Automatic Document Adjustment: Create Worklist

Preparing to run the Alternative Condition Analysis requires that you create a variant for programRMEBEIN4.

In the variant you select which document categories you want to process and how you want to mark

the documents.

Schedule this job to run prior to your change message job.





SAP AG 2001


Store System

StoreStore

MMM

MMM

Distribution channel

Sales organization

Organizational Levels for Changes

Store

to

Def Ine

Parameters for parallel processing

Server grp. for parallel proc.

Parallel processing

Reorganize pointers

POS Interface Outbound: Change Message

Preparing to run Outbound message automatically on a regular basis, requires that you createvariants of the report. You define your variants at POS Outbound for the particular message type.

You also determine at this time, if the system will process the messages using multiple application

servers.





SAP AG 2001

Customize SAP Retail to include bonus buyfunctionality.

Send a Bonus Buy message to the store.

Bonus Buy: Topic Objectives


SAP AG





SAP AG 2001

Bonus Buy

Peaches, $4.00 basketwith Smart card

or $4.50

Free

Boom Box39.95

Any 4 tapes@ 9.99

SaleTake an additional 20%of purchases of $100.00

Bonus buy conditions can be defined so that specific requirements must be met before a promotional price is offered.

Requirements can be a minimum amount, a group of required articles at a certain price, and only

when a loyalty card is presented, for example.





SAP AG 2001


Store System

StoreStore

MMM

MMM

Sales organization

Organizational Level

Store

to

Def Ine

Data to be transferred

Bonus buy

Transfer Bonus buy data

.

.

.

.

to

Bonus buy data

.

.

.


POS Interface Outbound: Direct Request

Bonus buy data can only be sent to the stores by a manual Outbound message.

You select transfer Bonus buy data and identify the condition or conditions to transfer.





SAP AG 2001


Customize

Define Checking Rules ...

.

.

. . . .

GAP analysis

Max gap errors

Gap analysis type

Gap percentage rate

KeyKeyIP00

Store’s POSInbound profile

IP00POS inbound profile

Define Checking Rules for POS Inbound (1/3)

The inbound checking rules functions as an IDoc preprocessor. Additional business rules for IDoc posting can still be defined in User exits.

Inbound checking rules can be set up to block IDocs from posting, if the threshold level is reached.

You can select to check for gaps in the transaction number either in the current IDoc (1) or in the previous IDoc also (2).

You determine the acceptable threshold for gaps in numbering either by absolute numbers or a percentage rate.





SAP AG 2001


Customize

IP00



.

.

. . . .

Double doc.anal.

Max error DDA

Duplicate analysis type

% Error DDAnalysis

Days DDA


A second check can be configured in the same customizing table, duplicate document check. Thereare several options that you can set here.

Type of duplicate analysis

- 1 check only the selected field- 2 check all fields (performance intensive)

You can set either a specific number of duplicates to refuse or a percentage.

You can also select to check only the current IDoc (0), all IDocs from the current day (1), and also anumber greater than 1 to check historical IDocs. Caution should be used, because the larger thenumber of IDocs searched for the duplicate document check the greater the performanceimplications.





SAP AG 2001


Customize

IP00


.

.

. . . .

Check POS controller

Check POS number Check transaction date

Check transaction time

Chck rcpt no

Check qualifier

Check partner number

Check currency

Check cashier nameCheck cashier number


Double doc.anal.


You can select one or several fields upon which to perform duplicate document checks. These fieldsare then used by the Duplicate Analysis Type (with a selection of check selected fields), todetermine if a duplicate document is being sent.

If the same receipt number is used at different stores, you might select the POS controller, forexample, to ensure that the system only checks for duplicate receipt numbers from a single store.





SAP AG 2001


Customize

Coupon Distribution Profile

.

.

. . . .

Cost Object 1

Condition type

Coupon Share

Account key

KeyCP50Coupon Profile

Affects margins

Coupon Distribution

The Coupon Distribution Profile provides the system with information to automatically handleaccounting for coupons redeemed at the store.

The cost of a coupon can be distributed to three shares, the percentage of which must add to 100.

The Coupon condition and account key ensure correct General Ledger posting.

Whether or not the share of the coupon affects margin, determines how the system handles the valueof the coupon share.





SAP AG 2001

• Master data for store/article(s)• Inventory management for

store/article• FI accounts

SAP Retail

Forward sales data to inventory manage-ment, replenishment, billing, SAP BW

4

Store System

1

3

2

Gather sales data at point of sale, balanceand aggregate(items, quantity, taxes, payment meth., ...)

If required, check customer’s credit limitand validity of credit/payment cards

Upload data to central SAP Retail systemat regular intervals

Receipt-Based Sales: Process Steps


Sales are those transactions where goods are exchanged for payment and recorded at the cash

register.

Related to sales are returns where goods are returned to a store for a refund. Technically, returns are

treated as negative sales by the SAP Retail system. Sales may feed data to several functions in theSAP system: inventory management, replenishment, billing and SAP Business Information

Warehouse(BW).

The process steps are as follows: over a set period of time, sales data (articles, quantity, taxes,

payment method, date/time, ...) are recorded at the point of sale and uploaded to the central SAP

Retail system at regular intervals (e.g., each night at 2 am). Upon receipt of the data, the SAP Retail

system forwards the relevant data to inventory management, replenishment, billing and SAP BW for

further processing.





SAP AG 2001

SUN, Russian Hill 18 Jan, 2000

2 Milk, 1qt 1.78

1 Pen-Set 2.99

Receipt no. 482167

5 Coke, 2l 9.90

1 Postcard 0.25


3 Milk, 1qt 2.762 Postcard 0.50

Receipt no. 482165

1 Coke, 2l 1.98

1 Apples 1.99

1 Eggs, 1dz 2.49

Article Qty. Amount ...Milk, 1qt 5 4.45 ...Postcard 3 0.75 ...Coke, 2l 7 13.86 ...

Apples 1 1.99 ...Eggs, 1dz 1 2.49 ...Pen-Set 3 8.97 ...Hairbrush 1 2.99 ...

Aggregated salesIDoc 9979345IDoc type WPUUMS01

Rec. no. Article Qty. Amount ... 482165 Milk, 1qt 3 2.76 ...

Postcard 2 0.50 ...... ... ... ...

482166 Pen-Set 2 5.98 ...Coke, 1.5 1 1.98 ...

... ... ... ... 482167 Milk, 1qt 2 1.78 ...

Pen-Set 1 2.99 ...... ... ... ...

Sales as per receiptIDoc 9979657IDoc type WPUBON01


2 Pen-Set 5.98

1 Coke, 1.5 1.98

Receipt no. 482166

1 Hairbrush 2.99

Sales: Aggregated vs. Sales as per Receipt

SAP Retail provides two IDoc types, WPUUMS01 (message type WPUUMS) and WPUBON01

(message type WPUBON), for transmission of sales data at two levels of detail:

- Sales as per receipt

The details of every sales transaction are transferred to SAP R/3 system. The store system itself

may assign a unique receipt number to each sales transaction, which may be transmitted to the

SAP Retail system (in field BONNUMMER in IDoc type WPUBON01). Via a user exit, theSAP Retail system can be set up to check validity of the receipt numbers received from the

stores (no gaps, no duplicates, ...). This user exit may also be used to assign receipt numbers to

sales transaction data received from a store if the store does not do so itself. The upload of sales

data per receipt is recommended if all sales transactions are to be used for statistical analysis or

auditing purposes.

- Aggregated sales

Sales data are aggregated over all sales transactions occurring at a particular store during a set

period of time and then uploaded to the SAP Retail system. Details of individual sales

transactions are lost. This option greatly reduces the amount of data to be transferred and is preferred if performance is a critical issue.





SAP AG 2001


2 Pen-Set 5.98

1 Coke, 1.5 1.98

Receipt no. 482166

1 Hairbrush 2.99


2 Milk, 1qt 1.78

1 Pen-Set 2.99

Receipt no. 482167

5 Coke, 2l 9.90

1 Postcard 0.25



Receipt no. 482165

1 Coke, 2l 1.98

1 Apples 1.99

1 Eggs, 1dz 2.49

Article Qty. Amount ...Milk, 1qt 5 4.45 ...Postcard 3 0.75 ...Coke, 2l 7 13.86 ... Apples 1 1.99 ...

Eggs, 1dz 1 2.49 ...Pen-Set 3 8.97 ...

Hairbrush 1 2.99 ...


Invoice .............................

P/meth. Total P/card Card no. ...cash 983 ...c/card 471 VISA 1023214 ...invoice 85 ...e/cash ... ...e/purse ... ...check ... ...d/debit ... ...

Payment listIDoc 9979576IDoc type WPUTAB01 Rec. no. Article Qty. Amount ...

482165 Milk, 1qt 3 2.76 ...Postcard 2 0.50 ...

... ... ... ... 482166 Pen-Set 2 5.98 ...

Coke, 1.5 1 1.98 ...... ... ... ...

482167 Milk, 1qt 2 1.78 ...Pen-Set 1 2.99 ...

... ... ... ...invoice

c/card

cash

Sales as per receiptIDoc 9979657IDoc type WPUBON01

Sales: Payment Methods

When sales data are transmitted to SAP Retail in the aggregated form, the associated payment data

are transmitted as a payment list in a separate message of message type WPUTAB, using IDoc type

WPUTAB01.

In Sales as per Receipt, the data transmitted for each receipt includes the payment method(s) andother details used in the individual sales transaction. Combinations of payment methods in a single

transaction are also possible, for example, a customer purchases goods for $120, pays $20 in cash

and the remaining $100 by credit card.





SAP AG 2001


Customize

Movements type-dependentcontrol of goods movements

KeyKeyIP00


POS inbound profile

Movement type

Cost center

G/L account

Rev. mvmt. type 252

IP00

251

Goods Movements: Customizing

In addition to the necessary settings in the store’s inbound EDI profile for message type WPUWBW,the processing of goods movement IDocs (IDoc type WPUWBW01) must be customized in thestore's POS inbound profile goods movement parameters.

Goods movement must be identified for the Inbound POS interface so that the system knows how tohandle the follow-on documents, even though the standard goods movement governs the internal processing.

The processing of a goods movement in SAP Retail can be customized as follows:

Cost center

- If a goods movement type is relevant for cost accounting, the default cost center to which theassociated costs are to be assigned is specified here. Note: If a goods movement is to be assigned to a cost center, the cost element must be definedin CO for the G/L account to which the goods movement is posted.

G/L account

- If the goods movement type is to be assigned to a specific G/L account, the account numbercan be maintained here. If no G/L account is entered here, account determination is carriedout automatically in inventory management instead.

Movement type for reversal of goods movement

- If the goods movement is to be reversed, the movement type specified here is used.





SAP AG 2001


Customize

Control Sales as per Receipt

.

.

. . . .

KeyIP00



Inventory management

Proc.

Billing X

Update rep.-based IM

Statistic update

Receipt-Based Sales: Customizing (1/5)

In addition to the necessary settings in the store’s inbound EDI profile for message type WPUBON,

the processing of aggregated sales data IDocs (IDoc type WPUBON01) must also be customized in

the store’s POS inbound profile detailed sales parameters.

SAP processes to which sales data should be forwarded

Billing (SD-) - if active, sales data are passed to the billing functions that prepares them for further

processing in Financial Accounting, Information System, Profit Center Accounting, ProfitabilityAccounting, and Cost Accounting. Billing also automatically handles discounts granted at the point

of sale, on which no information was provided with the sales data.

Inventory management (MM-) - if active, inventory is updated according to sales data received

from a store;

Replenishment based inventory management - if replenishment is used in conjunction with the

(simplified) replenishment-based inventory management, this indicator must be set for sales data toupdate replenishment-based inventory.

Statistics - if active, sales data update information structures S120, and S122 in the Retail

Information System (RIS). It is strongly recommended that SAP BW be used, therefore, do not

activate.





SAP AG 2001


Customize


.

.

.

.

.

.

IP00


Anon. customer

Organization levels

Storage location 0001


Organization levels

The follow-on processing of sales data in SD and FI require the reference to a customer.

If no customer is defined, the system posts sales to the store customer number.

It is further possible to specify a storage location to which inventory is updated by sales data. If astorage location is not specified, the system determines a storage location based on the article(s) and promotion number.





SAP AG 2001


Customize


IP00


(MM-) inventory management

.

.

.

Mov. type: Return 252

Mov. type: Sale 251

Explode mat.

Process control

.

.

.


Controls for sales data processing by inventory management and billing:

The SAP Retail system can be told to ‘explode’ articles subject to deposits during inbound processing of sales data, if inventory is to be updated on individual article level, i.e., separately

for article and associated empty. This option may be chosen if the POS system is unable to do soitself.

(Note that articles subject to deposit are the only structured articles, for which this option iscustomizable in SAP Retail. For all other structured articles, explosion must be done either by thePOS system itself, or by a POS inbound user exit in the SAP Retail system.)

The movement types to be used for the posting of sales and returns are specified here.Additionally, for each of these two movement types and the POS inbound profile, acorresponding entry must be made in POS inbound customizing under ‘Movement typedependent control of goods movements’.





SAP AG 2001


Customize


IP00


(SD-) BillingInvoice .............................

.

.

.

Bill. type FP

Item cat. standard DLN

Calculation schema POSUSJ

Number of items 100

Process control .

.

.

Sales doc. type OR

•salesprice

•dis-counts

• taxes

.

.

.


If billing is active, a sales document type and item category must be specified to serve as source forthe copy control (sales documents ® billing documents) as defined in SD-customizing.The item category specified is also used in the billing document to be created, which is of the typechosen here.

A calculation schema must be specified. Starting with the sales price that is uploaded from the POSsystem, the calculation schema derives values, in the form of condition records or subtotals, that are passed on to billing, inventory management, Retail Information System and accounting for further processing. In addition to the sales price, this calculation scheme usually includes various discountsand taxes.

The maximum number of items to be included in each billing document may be specified.





SAP AG 2001


Customize


.

.

.IP00


Cond. type SAP val. pr. PBEW

Condition PN10

Cond. type FI val. pr. PBFI

Condition


The condition types identified must be included in the calculation scheme chosen for billing.

The first of these condition types represents the sales price sent by the POS system, minus alldiscounts calculated (by the calculation schema) or granted (at the point of sale).

The second condition type is used to pass the value for sales price valuation of the goodsmovements to billing.

The third condition type is used to pass the valuation of value-only articles in FI to billing.





SAP AG 2001


store system

customize

Transaction type Description

STSA standard sale

PTVO voucher sale

SFSA staff sale

... ...

transactions transaction typesstandard sale 100voucher sale 120staff sale 300...... ...

conversion

Transaction types for sales as per receipt

Receipt-Based Sales: Transaction Types

The inbound processing of receipt-based sales data by the SAP system can be customized in twoways:

transaction type independent

In this case, the controls of the inbound processing of receipt-based sales data are exactly the ones just discussed, and dependent solely on the (sending store's) POS inbound profile;

transaction type dependent

If data arising from different types of sales transactions are to be processed differently, it isnecessary to define those transaction types (for sales as per receipt) in customizing.It is then possible to override some (not all!) of the transaction type independent controls of theinbound processing of receipt-based sales data for each individual transaction type. These over-rides are dependent on both the store’s POS inbound profile and on the transaction type the storeuploads with an individual sales transaction.

In both cases, however, the necessary settings in the inbound section of the sending store’s EDI profile for message type WPUBON must be maintained.

If stores use keys different from the ones used by the SAP Retail system to distinguish their differenttypes of sales transactions at the point of sale, the conversion between the transaction types used atthe store(s) and the transaction types (for sales as per receipt) used by SAP Retail must becustomized.





SAP AG 2001


Customize

Transaction type-dependentcontrol of sales as per receipt

Key

IP00



PTVOTransaction type

.

.

Process control

Reversal till recpt

Payment method .

.

.

Acct. Assignment grp

Default valuesMdse category

Receipt-Based Sales: Customizing

If the inbound processing of sales data as per receipt is customized for a transaction type, it may

override some controls that are maintained at the POS inbound profile only level. Also, some

additional fields may be maintained:

The Process choices are the same as Sales as per receipt customizing and may be redefined, as maythe storage location.

Reversal till receipt

- If flagged, this transaction reverses the prior transaction in the IDoc and neither transaction is

posted.

Payment method

- If flagged, this transaction is treated as if it were a payment method.

Additional default values also may be defined.

Merchandise category

- Enter a merchandise category in this field to post transactions that do not specifically refer to anarticle, for example, a gift certificate or service. These items are passed to SAP Retail as text

items.

Account assignment group

- Enter a different Account assignment group in this field to post these transactions to a different

account from the one associated with the article master.





SAP AG 2001

Store System

Gather POS data per cashier number

(and condition type, if required)Upload data to central SAP Retail system

1

2

Process cashier statistics data

View accumulated cashier statistics data,whenever needed

Define appropriate exception handling of cashier statistics data, if required

3

4

5• Master data for store

SAP Retail


Loss Prevention: Process Steps

POS statistics data gathered at a store can be stored, and retrieved, to the central SAP Retail system.

Examples of such data, gathered at one or several cash registers, can include

- total sales

- target till amount

- Number of drawer openings

- number of cancelled receipts

The business scenario is as follows: over a given period of time (e.g., one day), a store gathers

POS data recorded at its cash registers. These data may be accumulated for each individual

cashier, and, if required, for each condition type. At the end of the set period, the data are uploaded

to the central SAP Retail system for processing, i.e., they are fed into one of the Retail

Communication structures for extraction into BW.





SAP AG 2001


Customize

S122 Cashier X

Info structure Description D W M P FYV P

1

. .

. . .

.

. .

.

updateinterval

updatemode

Activate update RISS122

fiscalyear

variant

Loss Prevention: (LIS-) Customizing

The processing of cashier statistics IDocs (IDoc type WPUKSR01) sent by a store requires the

necessary settings in the inbound EDI profile for message type WPUKSR.

The store’s POS inbound profile requires no further customizing for the processing of cashier

statistics IDocs by SAP Retail system. If you are using RIS during your initial testing, it is necessary to activate the updating of the RIS

information structure S122 (Cashier) in customizing. This involves determining the update interval

(daily, weekly, monthly, at posting period intervals), possibly a fiscal year variant, as well as the

update mode (synchronous, asynchronous, in dialog).

Note: When testing is complete and before going live, remember to deactivate the RIS information

structures.





SAP AG 2001


Nightly:Article + Price

EAN

Nightly:

Sales ReceiptsLoss Prevention

Converter

Retail Store

Vendors

ITS Server

POS Server

Purchasing activities


Sales

Master data maintenance

Evaluating reports

SAP Retail Store

SAP Retail Store:

Smart Specialty will make use of personal computers and SAP Retail Store to handle their storelogistic information that has been handled manually up to now.

The stores carry some articles that customers purchase in store but are delivered directly by thevendor to their homes. Sales clerks will use Retail Store to record these transactions online.

The merchandise managers will be ordering merchandise and stock clerks recording those receiptsusing Retail Store.





Simple POS System Case Study – Outbound Documents Exercises

Unit: Simple POS System Case Study – Outbound

Documents

Topic: Customizing POS Outbound Profile and Sendan Initializing Message to your Store.


• Customize an Outbound POS Profile and create test messagesto send to the stores.

Other implementation team members have completed theirconfiguration, you have set up the communication customizing,there is just one more area to customize and you can test POSOutbound for your simple POS system case study.

Important note: The R/3 locking mechanism is switched off for courses doing Customizing,therefore, it is necessary for you to check that your settings have been saved. Use DISPLAYafter you have saved your changes to confirm that they are recorded.

4-1 Just to make sure the message type is active, go and check in the IMG that yourmessage type is active.

4-1-1 Was it? How did you find out its status?

4-2 Gather the information needed before you can create a POS Outbound Profile.

Remember that you will require a Condition Type Group and a ConversionCategory. Please check these before creating your Outbound profile.

4-2-1 What path must you take to access the POS Outbound profile?

4-2-2 Does this also bring you to where you can check the Condition Type groupand the Conversion Category? If not, please identify that path.





4-2-3 What is the name of the Condition Type Group you will be using in this profile?

4-2-4 What is the name of the Conversion Category you will be using in this profile?

Now, you have the information to create your Outbound profile, OP## .

4-3 Create your POS Outbound Profile. Use the name OP##.

4-3-1 What flag do you have to set to indicate that the POS systems in the storereceive and supply data? What happens if this indicator is not set?

4-4 Once you are sure that your Outbound profile has been saved. Assign it to your siteT8##.

4-4-1 What is the path to the site?

4-4-2 Which tab and field do you access to enter your Outbound Profile?

Remember to check that the change was saved.

4-5 Your site belongs to Sales organization R300 and distribution channel R1. Initializethe article data for your site only.

4-5-1 What path did you take to access the Initialization process?

4-5-2 Did the initialization create an IDoc the first time you tried it? Look at themessage sent after the initialization report is complete in the POS Monitor .

4-5-3 Did the POS Monitor display any errors?

4-5-4 If yes, what were those errors?

4-5-5 Is there a way you can work around any errors? How?

Repeat the initialization process after you make any changes:

4-6 Using the POS Monitor, determine for which articles IDocs were created. Whatwere those articles.





4-7 How can you access the IDoc file?

4-7-1 Use the IDoc file that was created to determine the price for some of thearticles.





Simple POS System Case Study – Inbound Documents Exercises

Unit: Simple POS System Case Study – Inbound

Documents

Topic: Inbound Sales as per Receipts

Customizing and Simulation


• Customize the EDI inbound partner profile for this messagetypes and customize the parameters for Inbound Sales as perReceipt and use the simulation tool for this message.

You are continuing with your small POS system case study. Nowthat you know how to structure and test your outbound message,

you want to configure and test the Sales as per Receipt messageand determine if it will provide the information necessary tosatisfy your finance department.

5-1 In the EDI partner profile of your store, T8##, maintain EDI controls for inbound processing of sales data as per receipt (message type WPUBON). You will alsorequire inbound message type WPUWBW for goods movement. Don’t forget to setthe test flag!.

5-2 Create an inbound profile IP## and assign it to your site, T8##.

5-2-1 Does the profile provide any default data? What is its purpose?

5-3 Configure the inbound processing controls for goods movement data for your POSinbound profile, IP##, to allow goods movements data for sales to be processed bythe POS interface (movement types 251 and 252). For movements of either type, donot post to a cost center, and do not override the standard G/L accountdetermination in MM customizing.

5-3-1 How many entries were you required to make?

5-4 Configure the inbound processing controls for sales data as per receipt for yourPOS inbound profile, IP##, copying the settings maintained by the instructor forinbound profile IP00.

5-5 Create a transaction type ST## for standard sales as per receipt, for which you want billing to be carried out in the R/3 system, but NO billing document to be saved.

5-5-1 What path do you take to create a specific transaction type?





5-5-2 Maintain the inbound processing controls for sales data as per receipt foryour POS inbound profile, IP##, and this new transaction type, ST##.

Use the same settings as for IP## sales as per receipt except

for the field Billing

5-6 Simulate the inbound processing of sales data as per receipt, T8##, with a billing

document to be created. Sell 2 pieces of article R100016 for cash ( Payment method

PTCS) at T8##, at a sales price (value) of 396 USD.

Remember if you have a conversion category payment

method active, payment type PTCS = 150.

5-6-1 Verify the result of the simulation. View the article document. Check that a

billing document was created. How can you accomplish these checks?

5-6-2 View the G/L accounting documents. Check the open line items in your

stores customer account.

5-7 Repeat the above simulation, this time you want no billing document to be saved so

enter transaction type ST## in field ShTy on the simulation screen. Use the payment

method for a check (PTCH or 151).

5-7-1 Verify the result of the simulation. View the article document. Check that

no billing document was saved? How can you accomplish these checks?





Simple POS System Case Study – Inbound Documents Exercises

Unit: Simple POS System Case Study – Inbound

Documents

Topic: Inbound Cashier Statistics Simulation


Customize the EDI inbound partner profile for this message typeand use the simulation tool to test the Loss Prevention message.

You are continuing to test each of the inbound message types. Forthe prior inbound testing you have entered your cashier number.

Now you will add a cashier message to complete the posting tothe info system.

6-1 In the EDI partner profile of your store, T8##, maintain EDI controls for inbound processing of cashier statistics data (message type WPUKSR). Don’t forget to setthe test flag!

6-2 Simulate the inbound processing of cashier statistics data from your store, T8##.Consider entering a composite of the data you have passed in the sales transactions.You might also enter an amount of canceled transactions and their value.

6-2-1 What path do you take to simulate this transaction?

6-2-2 Verify the result of the simulation (standard analysis Cashier ). How did youverify the results?

6-3 Which info structure is updated by the upload of cashier statistics by a store?

6-4 What are the characteristics of this info structure?

6-5 What are the key figures of this info structure?

6-6 What information do the Loss Prevention and the POS balancing reports give you?





Simple POS System Case Study – Outbound Documents Solutions

Unit: Simple POS System Case Study – Outbound

DocumentsTopic: Customizing POS Outbound Profile and Send

an Initializing Message to your Store.

4-1 Before you can use change pointer analysis on any message type it must be active.

4-1-1 To ensure that the message type is active, use the following path:



Basis Components Distribution (ALE) Modelling and Implementing

Business Processes

Master Data Distribution Replication of Modified

Data

First select Activate Change Pointers (Generally). To ensure that ALE isactive in the system.

Next select Activate Change Pointers for Message Types, click on Positionand enter W* to bring you to the POS message types, to ensure thatWP_PLU is set to active (Checked)

4-2 To gather the information needed before you create your POS Outbound profile:

4-2-1 The path to access the POS Outbound profile is:

Tools AcceleratedSAP Customizing double-click Edit Project(SPRO) SAP Reference IMG

Sales and Distribution POS Interface Outbound Maintain Profile

for POS Outbound

4-2-2 Yes, you can check the Condition type group with the selection above forthe outbound profile. It is:

Maintain condition type group

But to go to the Conversion Category, in the IMG use the path:

Also in the POS Interface tree select Enhancement Conversions

4-2-3 Select Condition type group : US00.4-2-4 Select Conversion Category: CC##

4-3 Now you can use the copy function to create your POS Outbound profile or create it by pressing New entries.

To copy, use OP00 as the basis to save data entry. Select OP00 and press Copy.Type over the data displayed with the correct information.

In the following fields enter this data.





Field Name Values

Conversion Category CC##

Lead time 5

Exch. Rate type 1012

Condition type group US00

Select Automatic Data Interchange.

Save your data, back out, and return to ensure the customizing was saved.

4-4 Assign Outbound Profile to Site master.

4-4-1 Use the following path to assign your profile OP## to your site T8##.

Logistics Retailing Master Data Site Data Site double-click Change.

Enter your site name and select Enter .

4-4-2 Select the POS tab and enter your Outbound profile OP## in the fielddesignated. Press Save.

4-5 Perform an Outbound message Initialization.

4-5-1 Take the following path to initialize:

Logistics Retailing Distributed. Retailing POS Interface

Outbound POS data double-click Initialization

Field Name Values

Sales Org R300

Distr. Chnl R1

Store T8##





Select Execute

Review the Processing Status screen and note the number of IDocs created.

Back out of the screen and then check the POS monitor to determine if yourinitialization completed with no errors.

4-5-2 To determine if the initialization created an IDoc the first time:

Select POS Monitor , enter your site T8## and press Execute.Expand Outbound, select Processed . If your site is not there, select Not fully

processed

4-5-3 Although there is an IDoc, you might have error messages under Not fully processed .

4-5-4 Double-click the line that is displayed. On the next screen, select one of thered high lighted lines, press Display Log to see the error messages. Whenyou click on some categories’ error messages, the Help will lead you to thecustomizing area that must be corrected. However, in this case, simply,identify those IDoc categories that will continue to stop the processing ofthe Initialization.

4-5-5 Go to your Outbound profile and select the categories of data that you donot want to prepare. For example Merchandise categories, Customer data,etc.

Note: In an implementation, you would contact other project members towarn them of the missing information and have them correct it. Or youwould fix it yourself.

Now perform the Initialization a second time. This time it should work.

4-6 To determine which articles were prepared, select POS Monitor , enter your siteT8## and press Execute. Expand Outbound, select Processed and locate your

successful IDoc by date and time.

Double-click the IDoc and on the subsequent screen, press Display data. Pagethrough the IDoc to find which articles were prepared for your store.

4-7 The path to view your IDoc file is: enter Transaction code AL11.

When the SAP Directories screen displays, page down to DIR_TRANS. Doubleclick to expand the directory. Double-click on POS and then on POSout and thenexpand your IDoc by double clicking it.

4-7-1 You must scroll to the right to view the article number in segmentE2WPA01. The condition type, VKPO, is identified in segment E2WPA04and the price is in segment E2WPA05001.





Simple POS System Case Study -- Inbound Documents Solutions

Unit: Simple POS System Case Study -- Inbound

Documents

Topic: Inbound Sales as per Receipt Customizing

and Simulation

5-1 To simulate inbound processing of sales as per receipt data, message typeWPUBON must be maintained in the EDI partner profile with the test flag set.

Tools AcceleratedSAP Customizing double-click Edit Project(SPRO)

SAP Reference IMG

Basis Components Distribution (ALE) Modeling and Implementing

Business Processes Partner Profiles and Time of Processing Maintain

Partner Profile Manually or

Tools Business communication IDoc Partner Profile

Expand Partner type KU . Select your site T8##. Scroll down to display Inbound

parameters and press Create Inbound parameters.

The message type and process codes are:

Field Name or Data type Values

Message type WPUBON (sales per receipts)WPUWBW

Process code WPUB (sales per receipts)WPUWBW

Test Check

Trigger Immediately Check

5-2 Create an inbound profile IP## and assign it to your site T8##. Use the path:


SAP Reference IMG

Sales and Distribution POS Interface Inbound Maintain profile for POS

inbound

Assign the profile to your site. Use the path:

Logistics Retailing Master Data Site Data Site double-click Change.

Enter your site name T8## and select Enter .

Select the POS tab and enter your POS inbound profile in the designated field.





5-2-1 The inbound profile provides the name that links your other profiles to thesite.

5-3 Configure inbound processing controls for goods movement data for your POSinbound profile, IP## to allow the system to move data between quality inventoryand cost of good sold to be processed by the POS interface. Use the path:


SAP Reference IMG

Sales and Distribution POS Interface Inbound click Movement type-

Dependent Control of Goods Movements

5-3-1 You require 2 entries, each movement type with its reversal.

Select New entries and then enter: These are your entries:


POS Inbound Profile IP##

Movement type 251

252

Rev. mvnt.ty 252

251

For the movement type lines, do not enter a cost center, and do not enter aG/L account. Account determination in MM will default in the correctaccount number.

5-4 Configure inbound processing of sales data as per receipt. Use the path:


SAP Reference IMG

Sales and Distribution POS Interface Inbound Control sales as per

receipts

Maintain the inbound processing controls for sales data as per receipt for your POSinbound profile, IP##. Copy the settings maintained for inbound profile IP00 orSAPD, if IP00 is not available. Modify your profile to ensure that your StorageLocation 0001 is identified, the Calculation schema is POSUSJ.

5-5 Configure inbound processing of sales data as per receipt with a new transactiontype as an additional control key.

5-5-1 Use the path:


SAP Reference IMG

Sales and Distribution POS Interface Inbound Transaction types for

sales as per receipts

First, identify the transaction type by entering ST## and a description.





5-5-2 Now, complete the control screen, using the path:



Sales and Distribution POS Interface Inbound Transaction type-

dependent control of sales as per receipts

Select New entries. Enter your POS inbound profile, and the transactionST##. You want inventory management and replenishment based inventorymanagement so, select both fields and set field ‘Billing’ to 1. Use theMatchcode on the Billing field to determine the meaning of 1 in the field.Enter your storage location, 0001; movement type Sale, 251, the return 252,and item cat. Standard, DLN.

5-6 Simulate the inbound processing of sales data as per receipt from your store, T8##,with a billing document. Use the path:

Logistics Retailing Distributed. retailing POS interface Extras

Simulation double-click Sales

Enter your site number and select Sales as per recpts.


Currency USD

Qual artn

Number R100016

Quantity 2Sales value 396

ShTy Blank

Select Payment methods. The sale was for cash so enter 150 for the Paymentmethod and 396 for the final total. Press Save.

5-6-1 Select IDoc status to verify the result of the simulation. With a status of 53,Application document posted, select POS monitor to view the resultingdocuments. Two documents are created, a Billing document and an Article

document.

5-6-2 Double click on the Billing document, select Accounting doc, whichdisplays your document choices. Double clicking on each of the documenttypes, displays the detail information associated with the document type.

In addition to accessing these documents through the POS monitor , you alsocan use the following paths to access them through the modules.

To display article documents:





Logistics Retailing Merchandise. logistics Inventory management

Article document double-click Display

To display billing documents:

Logistics Retailing Sales Billing Billing document double-click Display

To display G/L account document:

Accounting Financial accounting General ledger Document

double-click Display/change line items

To display open line items in a customer account:

Accounting Financial accounting Accounts receivable Account

double-click Display line items

Enter Customer = T8##Company code = R300, and select field Open items.

5-7 Simulate processing sales data as per receipt, this time referring to transaction typeST##.

Create the same item data as above, but enter ST## in ShTy. Select Paymentmethods and enter 151 for payment type check and the final total, $396. Press Save.

5-7-1 Select IDoc status to verify the result of the simulation. With a status of 53,Application document posted, select POS monitor to view the resultingdocuments. Only one Article document is created, no billing document, aswe specified in configuring.





Simple POS System Case Study -- Inbound Documents Solutions

Unit: Simple POS System Case Study -- Inbound

Documents


6-1 To simulate inbound processing of cashier statistics, message type WPUKSR must be maintained in the EDI partner profile with the test flag set. Use the path:


SAP Reference IMG



Partner Profile Manually

or


Expand Partner type KU . Select your site T8##. Scroll down to display Inbound


The message type and process code are:

Field Name or Data type Values

Message type WPUKSR

Process code WPUK

Test Check

Trigger Immediately Check

Reminder: No specialized customizing is required for

inbound processing of Cashier Statistic. However, the

Information Structure must have been maintained.





6-2 Simulate the inbound processing of cashier statistics data, uploaded from yourstore, T8##.

6-2-1 Use the following path:



Enter your site number and select, Cashier statistics

Accept today’s date, leave the update group blank and the system defaults800. Enter your group number ## in the Cashier field, and USD in Targetcurrency.

Some example data:


Cashier Group ##

Till amount target 792

Actual amount till 780

Neg. till difference 12

Value canceled transactions 200

No. terminations 4

Sales 792

Bus. Vol w/o tax 792

6-2-2 Verify the result of the simulation first by selecting IDoc status to determine

if the simulation worked error free. Then, take the following path to Cashierstandard analysis:

Logistics Retailing Info system/Planning Retailing Standard

analyses Special processes Sales audit double-click Cashier

6-3 To find which info structure is updated by the upload of cashier statistics by a store.

On the initial list generated by the Cashier standard analysis, select Goto Other

info struct... Note the structure S122

6-4 To determine the characteristics of this info structure.

On the initial list generated by the Cashier standard analysis, select Extras Disp.

std drilldown. You will see the answer: Sales district, Site, Cashier number,Condition type, and Date.






On the initial list generated by the Cashier standard analysis, select Edit Choose

key figures...

6-6 These two reports capture the data sent by the store that has been captured by thePOS system in the store. Depending on the system, every key press at the register iscaptured by the store system providing the sales auditor with valuable loss

prevention information.





SAP AG 2001

Contents:

SAP AG

Outbound Assortment List Configuring Inbound Logistics

Simulating Inbound Logistics

Configuring Aggregated Sales and Payment List

Simulating Aggregated Sales and Payment List

Configuring FI transactions

Simulating FI transactions

Merchandise Management System Case Study





SAP AG 2001


Unit 8 Conclusion






Unit 1 Introduction

Course Overview





SAP AG 2001

Merchandise Management System Scenario

Mer. Mgmt. SysIDES Smart Retailer Inc.IDES Smart Retailer Inc.IDES Smart Retailer Inc.

Assortment

ListNightly :

Agg. Sales

Payment Types

Financial Trans.

Loss Prevention

Store Orders

Goods Receipt

Converter

Vendors

DCs

As Needed:

Article Change

EAN Change

Physical Inventory

BW

Unit Case Study:

Smart’s General Merchandise stores present a different situation from their specialty stores. The

stores, in this case, are fairly autonomous, doing their own buying both externally and from the

DC. Their accounting books are kept at headquarters and they report all they do via POS interface.

The team is evaluating the assortment list message for supplying the stores with article

information. Although they are looking into reducing the message to eliminate segments they donot use.

The inventory management team would like us to provide logistics information to headquarters

through the POS interface, so we are evaluating Store Order and Goods movement messages and

also the Article and EAN changes, and Physical Inventory messages.

Since each of the stores reconcile their sales at the end of the day before reporting, there is no need

to capture the detailed receipt based sales. Consequently, for these stores we will report salesthrough the Aggregated sales and payment list messages. To reconcile all store cash at

headquarters, we will also use the Financial Transactions message.

After we complete our testing, we will meet with the Sales Audit group to ensure that our planned

message types meet their requirements for reporting.





SAP AG 2001 SAP AG

At the end of this topic, you will be able to:

Describe the Assortment List message

Evaluate whether to use the Assortment List

message

Customize the Assortment List profile

Assortment List: Topic Objectives





SAP AG 2001

Article(s)


Article(s)


SAP Retail


1 Using ALE Technology change pointer analysis, create change document

3 Download data to store POS systems

Report: prepare POS master data

Store Merchandise Management System

2

Assortment List Outbound: Process Steps

The Assortment List master data message is handled similarly as other outbound messages using

standard ALE technology and change pointers for IDoc creation.

During initial startup report RWDPOSIN is run to prepare all the necessary data for the first time and

transfer it to the POS systems. This Initialization should be scheduled in the background and mustcomplete successfully (status: Preparation OK) before change messages can be created.

After initialization is complete, whenever a user maintains master data, the application creates achange document. If the changed field was transmission-relevant, ALE creates a change pointer that

identifies where the data can be found.

RWDPOSUP, the change message report, is scheduled to run in the background at regular intervals

after close of business. This report:

analyzes the changes that have occurred since the last time the data was successfully prepared

prepares the changed data into IDocs and places them into the outbound directory





SAP AG 2001

All articles that can be ordered per store within a given time,

description of new articles and those to be discontinued

Information about presentations and article sales

(labels, sales prices, layout specifications)

Information about sources of supply (DC or vendor,

purchase information, delivery unit, sales unit)

Information about important movement data (promotions,

allocation tables, last orders)

Assortment List Contents

The Assortment list contains selected data of the integrated article maintenance that are relevant for

the store or customer.

A source determination is made for the articles so that the store knows from where to order each

article. More than one source can be transmitted.

Optionally, transaction data (promotions, allocation tables, orders) are read as well. This data can

support the store's merchandise planning functions.

Information about the layout of the store provides directions for article placement and planning by

visual inspection and also, where necessary, for generating shelf-edge labels.





SAP AG 2001

Site

Master

R310

EDI

Partner

Profile

R310

POS2

USD

AL00

POS1

Assort.

List

Profile

AL00

AL

Type

A

ALEActive

Messages

B

C

Article

Master

A

POS

Outbound

Profile

POS1

Customize Automatic Assortment List Processing

The Assortment List profile with its assortment type, the POS Outbound profile, the EDI partner

profile, and ALE work together to create an outbound assortment list message.





SAP AG 2001


Customize

Assortment list Types

Lead time

Assort.

list

Assort

list type

No. of

change

versions

Des. Cycle,

change

versions

F

A

H

2

3

3

5

14

7

3

4

4

Assortment List Types: Customizing

The above example has three types of Assortment List which allows for different cycles for the three

types of articles in our training company--Food, Hardware, and Apparel articles.

Using Assortment list types allows multiple versions to be handled by a single Assortment List

profile.





SAP AG 2001

08/1508/15

==

NextNext

GenerationGeneration

Definition of n change versions before the next full version

08/1008/10

==

1st generation1st generation

Lead timeLead time

2 days2 days

Version 1Version 1

(full version)(full version)Version 2Version 2

(change version)(change version)... next... next

full versionfull version

08/2008/20 tt n+1n+1

Cycle timeCycle time

5 days5 days

POS Outbound: AL Version Management

Version management is recorded in the Assortment List Type entries in the system. This slide

provides a detailed look at how version management works.

The cycle time definition provides the data for the system to calculate the validity period and the

next generation dates for the assortment list.

In addition, you can define how many change versions to send before the system sends a full version.





SAP AG 2001

IDES Smart Retailer Inc.IDES Smart Retailer Inc.IDES Smart Retailer Inc. c

ustomize

AL00

Maintain profile for assortment lists

.

.

. . . .

AL00

AL applic. mode 3

Cond. Type group US00

Reduction

Parameters

Key

Assortment list type

AL profile

H

Assortment List Profile: Customizing (1/4)

Like all other profiles in R/3, the Assortment List profile handles data entry in a most efficient

fashion.

The Parameters are:

Application mode: how will the assortment list be used.

- 1 Save versions, do not send as message

- 2 Send as message, do not save versions

- 3 Send as message and save versions

- 4 Do not save any version or send any message.

Condition Type Group

- Group created earlier to handle conditions used to prepare pricing to download.

Reduction

- If you have created a reduced Assortment List message, enter the name in this field. Otherwise,the system will use the full WBBDLD message.





SAP AG 2001


Customize

AL00

Maintain profile for assortment lists

.

.

.

. . . . .

.

Print form Assortment_List

OutputDevice

Number of lines

AL structure

Sorting procedure 1

WBBP_LINE

Assortment List profile: Customizing (2/4)

Sorting Procedure controls how the Assortment List will be structured. The options are by:

1 - Department, layout area

2 - Layout area

3 - Vendor, vendor sub-range, article number

4 - Vendor, merchandise category, article number

5 - Department, merchandise category, article number

6 - Merchandise category, article no.

9 - Other, a user exit.

Assortment List data line structure. This field identifies a dictionary structure that is used to create

and interpret the assortment list data line. The data for the structure is taken from the WBBP_MAX

structure and consequently only fields that are included in that structure should be included. The

system is supplied with the following Assortment List structures:

WBBP_LINE for the retail sector

WBBP_LAB for shelf-edge labeling

WBBP_WH_SL for the wholesale sector

WBBP_STORE for Retail Store

Number of lines is to designate the number of lines that fit on a single page of the assortment list.

This allows one to create a table of contents for the assortment list.

Format for printing the assortment list. This is used in conjunction with the data line structure.

OutputDevice is the name of your printer, if you want a printed assortment list.





SAP AG 2001


ustomize

AL00

Maintain profile for assortment listsMaintain profile for assortment lists


Print immed.

Flag changes

Sales usage

Recipient determin.

.

.

.

.

.

.

Print immed.(iately). Select this field if you want the system to print the assortment list immediately

after creating the assortment list.

Flag changes, tells the system to examine the master data changes even when creating a full version.

Selecting this field has performance implications.

Sales usage, selecting this field allows an article to remain in the assortment list after the end of the

ordering period. The article remains until the end of the selling period.

Recipient determin., identifies that the system should use the ALE distribution model to determine

where to send the list when creating IDocs. This has performance implications and should not be

used for POS outbound.





SAP AG 2001



ustomize

RS00

Maintain profile for assortment listsMaintain profile for assortment lists

Vendor Info.

Ext. change info

Ext. layout modules

Lyt module versions

Other functionalityOther functionality

Vendor Info – If stores perform purchasing locally, select this field to include Vendor information in

the assortment list. When this field is not selected, segment W1WBB13 of IDoc WBBDLD03 is not

prepared for the store.

Ext. change info – If you are including change information from an external source, select this field.

Ext. Layout modules – If you are using an external space management system for your store layout,

select this field.

Lyt module versions – Becomes active when you select external layout modules.





SAP AG 2001 SAP AG

Description of Process

Alt. Condition Analysis

Initialization

Change message

Direct request

Reorganization

Assortment List Report

RMEBEIN4

RWDBBINI

RWDBBUPD

RWDBBMAN

RWDPOSRS

Assortment List Report Processes

Alternative Condition analysis report, if used, should be run before executing the Change message

report.

The Initialization report should be run prior to going live. If you are using the Assortment List

message to populate your store systems, each store must be initialized before change messagedownload can be used.

Change Message report for Assortment List can be set to run synchronous with the assortment listcycle time, if all stores are, for example, on a 5 day cycle. If, however, stores are on different cycles

you might set the report to run nightly. Then the report checks the cycle you set in Version

Management and prepares Change message only for those stores that have cycles requiring one.

Direct request or manual reports are used for testing, replacing missing store data, or to change a

particular price when you do not wish to run the entire change analysis. These reports can still be set

to run in the background, saving system resources.

Reorganization reports are described in the last unit under performance issues.





SAP AG 2001


Store System

StoreStore

MMM

MMM


Sales organization

Assortment user

Store

to

Def Ine

Control data

Logon/server group

Generate merged versions

Max. no. processes

Parallel processing

Do not use cycle

Assortment list type to

Assortment list

Assortment List: Change Message

Preparing to run the Assortment List message automatically on a regular basis, requires that you

create variants of the report. You define your variants at POS Outbound, Assortment List Change

message.

You may choose to ignore an assortment list type cycle and include all articles assigned to thedefined User selections.

You may also choose to merge all other change versions with the last full version after the systemgenerates this change version.

You also determine at this time, if the system will process the messages using multiple application

servers, if you want to limit the number of processes running in parallel, and the name of a server

group to perform the parallel processing.





SAP AG 2001

At the end of this topic, you will be able to:

Customize the inbound profile for back office

transaction messages

Use the system’s simulation tool for inbound

processing of these messages

SAP AG

Inbound - Back Office Transactions: Objectives





SAP AG 2001

store physical inventory WVINVE01* WVINVE -

WVINVE02 WVINVE x

article master WP_PLU01 WP_PLU -

WP_PLU02** WP_PLU x

WP_EAN01 WP_EAN x

financial transactions WPUFIB01 WPUFIB x

cashier statistics WPUKSR01 WPUKSR x

store order WGSREQ01* WGSREQ x

WGSREQ02 WGSREQ x

ORDERS01 ORDERS x

ORDERS02 ORDERS x

ORDERS03 ORDERS x

goods movements WPUWBW01 WPUWBW x

sales (& returns) data WPUUMS01 WPUUMS xWPUBON01 WPUBON x

payment lists WPUTAB01 WPUTAB x

* obsolete (only maintained for upward compatibility reasons)** contains extensions (of WP_PLU01) relevant for outbound communication only

IDoc type Message type SimulationBusiness data (inbound)

Types of Inbound Business Data

The above list summarizes the types of inbound business data that can be processed by the SAP POS

interface. In each case, also shown are the corresponding IDoc types and message types that may be

used as a carrier for each of these business data. The last column indicates, whether or not the

corresponding message can be generated and passed on to the inbound processing unit of the POSInterface, by the POS inbound simulation tool.

In addition to the IDoc type/message type combinations shown in this list, the IDoc type

WPUERR01 can go with message type WPUERR to send error messages from the converter to the

SAP Retail system. These messages, however, are only displayed within the POS Interface Monitor

and not passed for further processing by any other application within the SAP system.

Finally, IDoc type WP_PER01 and message type WP_PER can be used to communicate person data

between store and SAP Retail system. After release 4.0, however, inbound processing of this

message is not supported.





SAP AG 2001

MMM

MMM

StoreStore

Store system

SAP Retail

P O S

I n b o un d

POS Inbound Back Office

Transactions

Back office transactions are those that are required to run the store itself. Normally, no customers are

involved in these transactions.

The back office functions supported by the POS interface are inventory management transactions:

Physical Inventory

Store Master data changes

Store Orders

Goods movements, for example:

- Goods receipts from a DC, other store, or vendor

- Floor to damaged goods





SAP AG 2001

POS2POS2

Site

Master

R310

EDI

Partner Profile

R310

POS2

USD

AL01

POS1

POS

Outbound

Profile

POS1

Details

Agg.Sales

POS2POS

Inbound

Profile

POS2

XXXX

Details

Conversion

TR00

Conversion

Parameters

TR00

Conversion

Category

TR00

X

X

X

Details

Store

Order

POS2

Details

GdsMvmt

POS2

Customize Automatic Inbound Processing

The processing of inbound data by the POS Interface is controlled by two main factors:

- POS Inbound Profile

POS inbound profiles are defined in customizing in terms of a key and description, and are

assigned to stores in their site master data. The processing, in the SAP system, of each inbound

message sent by a store is configured (in customizing) with reference to a particular POS

inbound profile.Thus, if the SAP Retail system receives a message from a store, it retrieves the store’s POS

inbound profile and processes the message according to the active customizing settings.

- Inbound parameters in the EDI Partner Profile

For each of the message types that a store sends to SAP Retail, a number of control parameters

must be set in customizing. This is done in the inbound section of the store’s EDI profile (with

partner type ‘KU’ = customer).

If the store system and the central SAP Retail system use different keys for movement types, units of

measure, merchandise categories, etc., the conversion between the two systems must be defined in

customizing using a conversion category. This conversion category is then assigned to the store’sPOS outbound profile and used both for conversion on outbound and on inbound communication.





SAP AG 2001


Customize

Store phys. inventory controlStore phys. inventory control

IP00

2

Key

IP00

Store’s POSinbound profile

POS inbound profile

Creation control inv. docs

Grouping type

Store phys. Inventory control

Store Physical Inventory: Customizing

In addition to the necessary settings in the store’s inbound EDI partner profile for message type

WVINVE, the processing of store physical inventory IDocs (IDoc type WVINVE02) must also be

customized in the store’s POS inbound profile physical inventory parameters.

Physical inventory data in the SAP Retail system can be customized as follows:

Creation of physical inventory documents in the SAP Retail system

Values ‘1’ through ‘4’ are possible. Depending on whether or not a matching active physicalinventory document item already exists in the SAP Retail system, the following reaction results:

matching open phys. inv. matching open phys. inv.

doc. item exists doc. item does NOT exist

value ‘1’ update phys. inv. doc. create work item

value ‘2’ update phys. inv. doc. issue message

value ‘3’ update phys. inv. doc. issue message; create phys. inv. doc

on repeat of IDoc

value ‘4’ update phys. inv. doc. create phys. inv. doc.

Values ‘2-4’ should be chosen for regular inbound processing of store physical inventory IDocs.

Value ‘1’ (work item processing) should be used if physical inventory documents have already been created. That is, work item processing is used as a type of exceptional processing.

Grouping type

If physical inventory documents are to be created from the store IDocs, identify by which

characteristic you want to group the articles counted into fewer documents.





SAP AG 2001

Changes to article master in store

merchandise management systemUpload changes to central SAP Retailsystem

1

2

• Master data for articles

SAP Retail


articleR100018article

R100018

40...89240...890

Blouse Blouse (linen)

$119,00 $99,00

4

Create workitem and forward to staff incharge of article master data maintenance(poss. exception: EAN/UPC changes)

3

Carry out workitem to realize changesin SAP Retail article master

Article Master Data Changes: Process Steps

The management of a store decides to change part of the master data of one or several of the articles

sold at the store. Examples:

- Change article EAN/UPC

In stores where some local purchasing is allowed, if the manufacturer/producer of an articlechanges the article’s EAN/UPC (e.g., to reflect a slight modification of the article or its

packaging)

- Change article cash register receipt text

To provide the customer with more information on the particular article (e.g., ‘Blouse silk’

instead of ‘Blouse’)

- Change article sales price

To clear stock.

These changes are made in the store’s merchandise management system and then uploaded to thecentral SAP Retail system. There, one or several workitems are created and forwarded to the staff

in charge of article master data maintenance, who decides to either reject the proposed changes, or

to accept them in the SAP R/3 system.

Possible exception: changes of EAN/UPC can be carried through directly/automatically in the

SAP Retail article master without using workflow, if preferred.





SAP AG 2001


Customize

Automatic EAN/UPCcreation controlAutomatic EAN/UPCcreation control

Auto. EAN creation

KeyIP00

X

IP00


POS inbound profile

Article Master Data Changes: Customizing

Article master data changes other than EAN/UPC changes:

All such changes are uploaded from the store initiating the change to the central SAP Retail system

via IDocs of IDoc type WP_PLU01 (or WP_PLU02) with message type WP_PLU, which must be

maintained in the store’s inbound EDI profile.Upon receipt of any such IDoc, the SAP Retail system always creates a workitem in the inbox of the

person responsible for updating article master data. The workitem lists the proposed changes in

article master data, which must be either rejected, or manually entered through Article Master data

maintenance.

Article EAN/UPC changes:

A store initiated change of EAN/UPC for an article is uploaded to the central SAP Retail system via

an IDoc of IDoc type WP_EAN01 with message type WP_EAN, which must be maintained in the

store’s inbound EDI profile.

The store’s POS inbound profile can be customized for EAN/UPC changes to:

EITHER use workflow

OR lead to an automatic update of the article master

If workflow is selected, executing the workitem automatically carries the master data changes over

to the SAP Retail article master.





SAP AG 2001

• Master data for store/article(s)• Master data for DC/vendor

SAP Retail


1

2

7

Determine short/medium term replenish-ment need at store(which articles, how much, when by, ...)

Upload data to central SAP Retail system

Register order confirmation

3

6

4

5

Check for, and add, missing data requiredfor further processing(e.g., order unit, source of supply, ...)

Optimize order item(s)(min. order qty., rounding to log. units)

Create procurement document(PReq, PO or delivery)for exceptions: trigger workflow

Create and send order confirmation tostore (optional)

PReqPReq

DeliveryDelivery

POPO

Store Order: Process Steps

Store order is the functionality by which store (or customer) replenishment needs are uploaded to

SAP Retail, which triggers the actual procurement using the system’s purchasing and shipping

functionality.

The business scenario: a store determines, using it’s own merchandise management system, its shortor medium term replenishment demand. Details of this demand (e.g., articles, amount, preferred

delivery date, ...) are then uploaded to the central SAP Retail system, usually in regular intervals.

Upon receipt of the store order data, the SAP Retail system checks for missing details that are

required for further processing, but were not provided by the store (e.g., order unit, source of supply,

...). It adds these details, using information stored in the system. Further, it optimizes individual

order items, adapting order quantities to minimum order quantities, or rounding to logistical units of

measure according to a defined rounding profile. If the augmented data is sufficient, they are then

used to create a document that triggers the procurement of the articles. Depending on the

customizing settings of the SAP Retail system, this document can be:

- EITHER a purchase requisition (PReq),

- OR a purchase order (PO),

- OR a delivery.

If the augmented data are still insufficient to create the appropriate document, exception handling is

triggered through workflow. Finally, an order confirmation may be sent back to the store and

recorded in the store’s own merchandise management system.





SAP AG 2001


Customize

Store order control

(dep. on MC)

Document type default 3

KeyKey




Default del. type LO

Default order doc. type UB

Sales document type OR

Doc. control

PReqPReq

deliverydelivery

POPO

sales order sales order

IP00

Store Order: Customizing (1/6)

In addition to the necessary settings in the store’s inbound EDI profile for message type WGSREQ,

the processing of store order IDocs (IDoc type WGSREQ02) must be customized in the POS

inbound profile Store Order controls. These can be defined at store level, or at store/merchandise

category (MC) level. The processing of store order data in SAP Retail system can be customized as follows:

Inbound processing of a store order IDoc by the SAP Retail system creates a particular documenttype that is determined by means of a ‘next-level logic’, that involves the ‘Document type default’

selected. This Document type default is used only, if document type data is not defined in any of

the following fields, or more specific direction described in slide 6 of 6.





SAP AG 2001

IDES Smart Retailer Inc.IDES SmartIDES Smart Retailer IncRetailer Inc.. c

ustomize

Store order control

.

.

.

.

.

.

IP00


(dep. on MC)

Substitute doc. type NB

Substitute doc. type UB

Group items X

Doc. control

.

.

.


Substitute document types for (standard) NB and UB

If the standard document types for purchase orders (i.e., NB and UB) have been renamed in

standard customizing of the SAP R/3 system, their new names must be specified here.

Note: It is NOT recommended to rename NB and UB!

Grouping of order items (flag only used at store level)

If activated, store order items containing the same article, receiving store, ... are combined to a

single item in the follow-on document created from the store order through inbound processing.





SAP AG 2001


Customize

Store order control

IP00


(dep. on MC)

.

.

.

.

.

.

Warning level error mess.

Communication

Reply type

2


Scope of message log (flag only used at store level)

Depending on the selection made in this field, not only errors, but also warnings or notes are logged

during inbound processing of store order IDocs. These messages can then displayed as leaves of the

tree generated by the POS Interface Monitor. Scope of store order confirmation (flag only used at store level)

This flag is only relevant for confirmation of store order. Depending on its value:

EITHER everything,

OR changes only,

OR all store order items, including variances,

are to be confirmed to the sender of the store order.





SAP AG 2001


Customize

Store order control

.

.

.

IP00


(dep. on MC)Unit determin. default key

Control

Check outline agreements

Default doc. cat. ext. replen.

Default doc. cat. int. replen.

3

4

Default doc. cat. ext. store order

Default doc. cat. int. store order

. . .


Further processing controls

• Settings made in this field group determine:

How missing units of measure are handled

Whether, or to what extent, the automatic source of supply determination should also check for

outline agreements (performance critical!),

The selections for ‘Default doc. cat. ... replen.’ are only relevant for store order inbound

processing triggered by replenishment, as opposed to POS upload. In this case, they are used to

determine the document category of the follow-on document to be generated.

The selections for ‘Default document category ... store orders’ are relevant for store order

inbound processing triggered by POS upload. Depending on the source of supply (either

provided explicitly, or determined automatically), the ‘Default doc. cat. external store ord.’ or

the ‘Default doc. cat. internal store ord.’ are used in a ‘next-level logic’ to determine the

document category of the follow-on document to be generated.





SAP AG 2001


Store order control

.

.

.

IP00


Customize

(dep. on MC)

Check double PO

Switch off doc. flow

Other planning methods

Two steps

Cheapest source

Control

.

.

.


Finally, five check-boxes are provided to determine:

• Whether the automatic source of supply determination, when triggered by store order inbound

processing, should try to find the cheapest source of supply (very performance critical !!!).

Whether store order inbound processing should check for duplicate external document numbers

Whether document flow update is deactivated during inbound processing of store order IDocs;

(performance critical! used only at store level)

Whether store order data should be posted in one or in two steps;

if posting is in two steps, the system imports the original store order data and adds missing data in

the first step. In the second step, the system posts the document. Optimizing processing steps can

take place on a cross-order basis between steps one and two; (used only at store level)

Whether store order items containing an article, that is to be procured via replenishment or

allocation, are not to be copied over to the follow-on document created by store order inbound

processing.





SAP AG 2001

store order IDoc

doc. type = 4

(delivery)

PReqPReq

deliverydelivery

POPO

User exit:............................................-

Store order IDoc:...............................-

POS inbound profile- at store/MC level, depending

on source of supply(field ´Default doc. categoryexternal/internal store order`):.......-

- at store/MC level(field ´Document type default`):....4

- at store level, dependingon supply source

(field ´Default doc. categoryexternal/internal store order`):...... -

- at store level(field ´Document type default`):....3

Default (if anything else fails):........3

2

3

4

a

b

c

d

1

document type = ?


... continued

As the slide shows, SAP Retail searches the store order IDoc from the most specific to the least

specific to determine which type of document to create.

The checks are performed in the following order:

check if a document type was transferred via a user exit;

check if a document type was sent with the store order IDoc;

check if a document type was maintained for the POS inbound profile

- defined at the store/ MC level, dependent on the source of supply (field ‘Default doc. category

external store order’)

- defined at the store/ MC, not dependent on the source of supply (field ‘Document type default’)

- defined at the store level, dependent on the source of supply (‘Default doc. category external

store order’)

- defined at the store, not dependent on the source of supply (field ‘Document type default’);

document type = 3 (PO), if everything else fails.





SAP AG 2001

1

2


store/article• Master data for FI accounts• Master data for cost centers

SAP Retail

IDES Smart Retailer Inc.IDES SmartIDES Smart Retailer IncRetailer Inc.. 3

4

5

Forward goods movement to inventorymanagement of MM module(material document)

Determine affected FI accounts and post

Determine affected cost centers in CO(if any) and post

Carry out (physical/logical) goods move-ment at store and gather related data in

store systemUpload data to central SAP Retail systemat regular intervals

Goods Movements: Process Steps

Goods movements are transactions that involve goods, but not necessarily money. A goods

movement can be either physical (e.g., the transfer of stock from storage location x to storage

location y), or logical (e.g., the reclassification of stock that was ‘in quality inspection’ to stock that

is now ‘available for unrestricted use’). Examples include:- Some stock transfers

- Floor to damaged goods

- Consignment goods on approval at customer

- Consumption posted to a cost center.

These can be modeled and documented by the inventory management functionality of the SAP

system‘s MM-module. G/L accounts must be defined in the FI module and, if cost accounting is

required, cost centers must also be defined in the CO module to which goods movements (e.g.,

consumption) are posted.

The following is a typical business scenario: goods movement data (type of goods movement, items,

amount, date/time, ...) are gathered at the store and uploaded to SAP Retail at regular intervals.There, the data are forwarded to inventory management which updates stock quantities accordingly

and creates an article document. Further, the associated values are posted to the appropriate G/L

accounts in FI and cost centers in CO (if required).





SAP AG 2001


Customize

Copy, change movement types

MvT Movement type text

101 GR goods receipt ... ... ...

102 Reversal of GR ... ... ...

... ... ... ... ...

201 GI for cost center ... ... ...

... ... ... ... ...

... stat. relevant ...

posting controls

for goods movement(IM, Inv. Contr.,...)

Goods Movements: Movement Types

For each type of (physical or logical) goods movement, a (3-digit) movement type, together with a

textual description, must be defined in standard SAP R/3 system customizing. For most of the

conceivable goods movements, corresponding movement types are already predefined in the SAP

R/3 system, for instance:movement type description

101 GR goods receipt

102 Reversal of GR

... ......

201 GI for cost center... ......

For each defined movement type, a movement type for its reversal is also defined, with a number

equaling the number of the original movement type plus 1, e.g., movement type 102 (Reversal of

GR) is the reversal of movement type 101 (GR goods receipt).

There is a set of controls associated with each movement type that determine, among other things,

the effects of the posting of a related goods movement in inventory management and in statistics

(‘Inventory Controlling’).





SAP AG 2001


Customize

POS goods movements control

KeyIP00


POS inbound profile IP00

Process control

PO SearchPO not found

Eval. final delivery order indic

Prevent PO gen.


The defaults for Good Receipts movement types, with which the system is delivered are set up the

way the system searched for goods receipts in prior releases; doing a complete search for the

article/store combination and if none is found, generating a purchase order.

Purchase order search can be customized to limit the length of the search.

- Complete search

- Terminate after the article/store/Purchase order number combination are not found.- Terminate after the article/store/delivery date and vendor combination are not found.

- Terminate after the article/store/vendor combination are not found

Specific actions for the system to take can be set in the PO not found field.

- Receive the goods and generate a purchase order

- Receive the goods, generate a purchase order, but issue a warning notice

- Generate a workitem- Display an error message, and do not process the IDoc

Stores with this profile can also be prohibited from generating a purchase order by selecting the

first field.

Evaluate final delivery order indicator when set, tells the system to trigger exception handling if

the end delivery indicator has been set. If it is not set, the system will post the goods receipt to a

purchase order that is ‘completed’ if the quantity is within tolerance regardless. Only when it is

outside the tolerance will it trigger a workflow.





SAP AG 2001


Customize

IP00


POS goods movements control

Using workflows

Workflow template

Selection parameter

Sel. param. for GR reversal

Process control

.

.

.


A selection parameter can be identified as a further filter for selecting purchasing documents. This is

not taken into consideration when a purchase order number is explicitly stated in the IDoc.

The same parameters are available for filtering on the reversal of a Goods Receipt.

The control of exception processing is defined in the Using workflows field. This field is delivered

with “Activate old workflow for processing exceptions.” You may also select:

- Activate new workflow for processing exception- Deactivate workflow for processing exceptions.

You may also identify a self-defined workflow template or task. If this field is left blank, the system

uses the SAP defined WS20000519 workflow.





SAP AG 2001


Customize

Movements type-dependentcontrol of goods movements

KeyIP00


POS inbound profile

Movement type

Cost center

G/L account

Rev. mvmt. type 202

IP00

201


In addition to the necessary settings in the store’s inbound EDI profile for message type WPUWBW,

the processing of goods movement IDocs (IDoc type WPUWBW01) must be customized in the

store's POS inbound profile goods movement parameters.

The processing of a goods movement in SAP Retail can be customized as follows:

Cost center

If a goods movement type is relevant for cost accounting, the default cost center to which the

associated costs are to be assigned is specified here.

Note: If a goods movement is to be assigned to a cost center, the cost element must be defined

in CO for the G/L account to which the goods movement is posted.

G/L account

If the goods movement type is to be assigned to a specific G/L account, the account number can

be maintained here. If no G/L account is entered here, account determination is carried out

automatically in inventory management instead.

Movement type for reversal of goods movementIf the goods movement is to be reversed, the movement type specified here is used.





SAP AG 2001

1

2

• Master data for store• Master data for FI accounts• FI posting keys

SAP Retail

IDES Smart Retailer Inc.IDES SmartIDES Smart Retailer IncRetailer Inc.. 3

4

Acc.No. 714398

dr cr

311.50

D

5

Forward financial transaction data to FI(account determination and postingFI document)

Follow-on processing in FI (if necessary)

Posting to corresponding cost centersin CO (optional)

Acc.No. 714398

cr

311.50

dr

Gather financial transaction data atmerchandise management system

(type of transaction, amount, ...)Upload data to central SAP Retail systemat regular intervals

bankBank

Financial Transactions: Process Steps

Financial transactions are events that involve cash but no goods or other movement. Common types

of financial transactions encountered at the point of sale include, for example:

- Petty cash payment,

- Cash deposits to bank,

- Invoice settlement by customer.

The following is a typical business scenario: financial transactions data (type of transaction, amount,

date/time, ...) take place in the store and are uploaded to the central SAP Retail system at regular

intervals. The SAP Retail system determines the accounts involved and post the amounts

accordingly. These can be either G/L accounts, customer accounts, or vendor accounts. Depending

on the financial transaction, follow-on processing of the data received in the SAP system’s FI

module is required (e.g., invoiced sales: a customer payment on account. In this case, a credit was

posted to the customer’s account at the time of the purchase (POS upload of sales data), and a debitat the time of payment (POS upload of financial transaction data). The follow-on processing in FI

then consists of clearing the customer's account.)

Finally, if Controlling is active, the costs involved are posted to the appropriate cost centers.





SAP AG 2001


Store System

StoreStore

MMM

MMM

Customize

FI transaction type Description

PECA petty cash payout

CABA cash deposit to bank

DEIN customer payment on acct

... ...

financial transactions POS transaction typesCash payout CAPACash to bank BANK

Invoice settlement CUST...... ...

conversion

Transaction types for financial transactions

Financial Transactions: Transaction Types

For each type of financial transaction recorded in the store, a corresponding FI transaction type must

be defined in the SAP Retail system. It is the FI transaction type (together with the store’s POS

inbound profile) that determines how data on financial transactions uploaded by a store are posted in

the FI module of the SAP system.

If a particular store system uses keys (POS transaction types) different from the ones used by theSAP Retail system to distinguish the different types of financial transactions at the point of sale, the

conversion between the POS transaction types used by the store system and the FI transaction types

used by the SAP Retail system must be customized in SAP Retail.





SAP AG 2001


Customize

Transaction type-dependentcontrol of financial transactions

G/L account 301005

Posting key 40

KeyKey


PECAFI transaction type

1Item no.

IP00


Financial Transactions: Customizing

In addition to the necessary settings in the store’s inbound EDI profile for message type WPUFIB,

the processing of financial transactions IDocs (IDoc type WPUFIB01) must also be customized in

the store’s POS inbound profile financial transaction parameters.

Posting an item of a financial transaction in SAP Retail-FI can be customized as follows:

G/L account

For each POS inbound profile and FI transaction type, the default G/L account number can bemaintained here. Consequently, a store communicating financial transactions to the SAP Retail

system does not need to include the FI account number in the IDoc(s), unless it wants to vary from

the default, i.e., if either a different G/L account is to be posted to, or if a customer/vendor account

is to be posted.

Posting key

Enter a posting key that determines various details for posting, including:

- which side of an FI account is posted (debit, credit)

- which type of account is posted (G/L-, customer-, vendor account);

- a posting key for the posting reversal.

The customizing settings described, minimizes the amount of data to be uploaded to SAP Retail to

describe a particular financial transaction. From these data, the SAP system is able to create a

complete FI document.





SAP AG 2001


store/article• FI accounts

SAP Retail


Forward sales data to inventory manage-ment, replenishment, billing, SAP BW

4

Store System

1

3

2

Gather sales data at point of sale, balanceand aggregate(items, quantity, taxes, payment meth., ...)

If required, check customer’s credit limitand validity of credit/payment cards

Upload data to central SAP Retail systemat regular intervals

Sales: Process Steps

Aggregated Sales are handled the same as receipt-based sales in the store. The individual receipts are

aggregated in the merchandise management system and uploaded. Sales may feed data to several

functions in the SAP system: inventory management, replenishment, billing and BW, the Business

Information Warehouse. The business scenario follows: over a set period of time, sales data (articles, quantity, taxes, payment

method, date/time, ...) are recorded at the point of sale, aggregated and balanced at the store then

uploaded to the central SAP Retail system at regular intervals (e.g., each night at 2 am). Upon receipt

of the data, the SAP Retail system forwards the relevant data to inventory management,

replenishment, billing and SAP BW for further processing.





SAP AG 2001


2 Pen-Set 5.98

1 Coke, 1.5 1.98

Receipt no. 482166

1 Hairbrush 2.99


2 Milk, 1qt 1.78

1 Pen-Set 2.99

Receipt no. 482167

5 Coke, 2l 9.90

1 Postcard 0.25



Receipt no. 482165

1 Coke, 2l 1.98

1 Apples 1.99

1 Eggs, 1dz 2.49

Article Qty. Amount ...Milk, 1qt 5 4.45 ...Postcard 3 0.75 ...Coke, 2l 7 13.86 ... Apples 1 1.99 ...

Eggs, 1dz 1 2.49 ...Pen-Set 3 8.97 ...

Hairbrush 1 2.99 ...


Invoice ...

.................

.........

P/meth. Total P/card Card no. ...cash 983 ...

c/card 471 VISA 1023214 ...invoice 85 ...e/cash ... ...e/purse ... ...check ... ...d/debit ... ...

Payment listIDoc 9979576

IDoc type WPUTAB01

Sales: Aggregated and Payment Methods

Sales data are aggregated over all sales transactions occurring at a particular store during a set period

of time and then uploaded to the SAP Retail system. Details of individual sales transactions are lost.

This option greatly reduces the amount of data to be transferred and is preferred if performance is a

critical issue. When sales data are transmitted to SAP Retail in the aggregated form, the associated payment data

are transmitted as a payment list in a separate message of message type WPUTAB, using IDoc type

WPUTAB01.





SAP AG 2001


Store System

StoreStore

MMM

MMM

WPUBON

WPUTAB

or

AMEX

Clearing

Acct

MC

Clearing

Acct

Payment Cards: Inbound Message Handling

The POS system in the store captures the customer name, card type, card number, expiration date

and the amount of the sale.

If payment card settlement is carried out at each store, the inbound payment type should be defined

as a cash like payment, since no subsequent settlement takes place through SAP Retail.

For payment card settlement carried out at headquarters, the detailed card information is uploaded as

detailed payment information in the Sales as per receipt IDoc. If sales are aggregated at the store anduploaded via Aggregated sales, the payment card detail is uploaded via the Payment list IDoc.

Posting to the appropriate General Ledger accounts is handled by account determination and account

keys as customized.





SAP AG 2001

Merchant Bank

Submit convertedstructure

Call Back

to reconstruct batch

Outbound

Inbound


AMEX

ClearingAcct

MC

ClearingAcct

Bank

Acct

Bank

Charges

Acct

Payment Cards: Settlement Flow

A payment card interface is required both for authorization and settlement. It is this interface that

structures the R/3 data into your bank’s format.

When you manually trigger settlement, the R/3 file is sent to the payment card interface and stored.

The interface converts a copy of the file and forwards it to your bank.

When the bank confirms settlement, it generally advises of the batch number, amount settled and

exceptions that could not be settled.

SAP Retail requires the detail line items to clear the documents in the Clearing account. So, the

payment card interface matches the batch number with the original outbound file and uses that with

the inbound data to recreate an inbound file with the settlement detail.

With the Financial Accounting area properly customized, only the exceptions require any handling.





SAP AG 2001


Customize

Aggregated Sales Control

.

.

. . . .

KeyIP00




Proc.

Billing

X

Update rep.-based IM

Statistic update

X

Aggregated Sales: Customizing (1/5)

In addition to the necessary settings in the store’s inbound EDI profile for message type WPUBON,

the processing of aggregated sales data IDocs (IDoc type WPUBON01) must also be customized in

the store’s POS inbound profile detailed sales parameters.

SAP processes to which sales data should be forwarded

Billing - if active, sales data are passed to the billing functions that prepares them for further

processing in Financial Accounting, Information System, Profit Center Accounting, ProfitabilityAccounting, and Cost Accounting. Billing also automatically handles discounts granted at the point

of sale, on which no information was provided with the sales data.

Inventory management - if active, inventory is updated according to sales data received from a

store;

Replenishment based inventory management - if replenishment is used in conjunction with the

(simplified) replenishment-based inventory management, this indicator must be set for sales data toupdate replenishment-based inventory.

Statistics – must be active for sales data to update information structures.





SAP AG 2001


Customize


.

.

.

.

.

.

IP00


Anon. customer

Organization levels



Organization levels

The follow-on processing of sales data in SD and FI require the reference to a customer. Specified

here is the number of a defined customer to be used if the POS system does not transfer the

number of the actual customer involved in a particular sales transaction (sales to anonymouscustomers). If no customer is defined, the system posts sales to the store customer number.

It is further possible to specify a storage location to which inventory is updated by sales data. If astorage location is not specified, the system determines a storage location based on the article(s)

and promotion number.





SAP AG 2001


Customize


IP00


(MM-) inventory management

.

.

.

Mov. type: Return 252

Mov. type: Sale 251

Explode mat.

Process control

.

.

.


Controls for sales data processing by inventory management and billing:

The SAP Retail system can be told to ‘explode’ articles subject to deposits during inbound

processing of sales data, if inventory is to be updated on individual article level, i.e., separately

for article and associated empty. This option may be chosen if the POS system is unable to do soitself.

(Note that articles subject to deposit are the only structured articles, for which this option iscustomizable in SAP Retail. For all other structured articles, explosion must be done either by the

POS system itself, or by a POS inbound user exit in the SAP Retail system.)

The movement types to be used for the posting of sales and returns are specified here.

Additionally, for each of these two movement types and the POS inbound profile, a corresponding

entry must be made in POS inbound customizing under ‘Movement type dependent control of

goods movements’.





SAP AG 2001


Customize


IP00


(SD-) BillingInvoice ...

.................

.........

.

.

.

Bill. type FP

Item cat. standard DLN

Calculation schema POSUSJ

Number of items 100

Process control .

.

.

Sales doc. type OR

•sales

price

•dis-

counts

• taxes

.

.

.


If billing is active, a sales document type and item category must be specified to serve as source for

the copy control (sales documents ® billing documents) as defined in SD-customizing.

The item category specified is also used in the billing document to be created, which is of the type

chosen here. A calculation schema must be specified. Starting with the sales price that is uploaded from the POS

system, the calculation schema derives values, in the form of condition records or subtotals, that are

passed on to billing, inventory management, Retail Information System and accounting for further

processing. In addition to the sales price, this calculation scheme usually includes various discounts

and taxes.

The maximum number of items to be included in each billing document may be specified.





SAP AG 2001


Customize


.

.

.

.IP00


Cond. type SAP val. pr. PBEW

Condition PN10

Cond. type FI val. pr. PBFI

Condition


The condition types identified must be included in the calculation scheme chosen for billing.

The first of these condition types represents the sales price sent by the POS system, minus all

discounts calculated (by the calculation schema) or granted (at the point of sale).

The second condition type is used to pass the value for sales price valuation of the goods

movements to billing.

The third condition type is used to pass the value for valuation of the goods movements in FI to

billing.





SAP AG 2001


POS inbound profile

Payment list controlPayment list controlCustomize

Key

IP00


IP00

Anon. customer

Organization levels

Process control

Sales doc. type OR

Number of items 100

Item cat. payment list TATX .

.

.

.

.

.

POS inbound profile

Payment Lists: Customizing

Payment details associated with aggregated sales data are uploaded from a store to the central SAP

R/3 system (in the form of a payment list) in a separate message of message type WPUTAB, using

IDoc type WPUTAB01.

In addition to the necessary settings in the store’s inbound EDI profile for message type WPUTAB,the processing of payment list data IDocs (IDoc type WPUTAB01) must also be customized for the

store’s POS inbound profile payment list parameters. These are:

Organizational level

A defined ‘anonymous’ customer can be defined. However, the system takes the store’s customer

number when none is identified in this field.

Process control

Settings made here are as for aggregated sales. In addition, an item category to be used for

payment lists in the billing document to be generated must be specified. Together with the sales

document type chosen, this item category is used as a source for the copy control (sales documents

- billing documents) as defined in SD-customizing.





SAP AG 2001

You are now able to:

SAP AG

Describe the business information communicated

among an SAP Retail system and store

merchandise management systems.

Customize outbound Assortment List message.

Customize inbound back office messages

Customize inbound aggregated sales and

payment lists.

Test outbound and inbound processes in the

Merchandise Management system case study.

Merchandise Management System: Unit Summary





Merchandise Management System Case Study – Outbound Assortment List Exercises

Unit: Merchandise Management System Case Study

– Outbound Assortment List

Topic: Customizing Assortment List Profile andInitializing the Store


• Customize an Assortment List Profile and create anAssortment List to send to the stores.

You are ready to take your first step in customizing your storeswith merchandise management systems. That step involves someadditional customizing and then testing the Assortment Listmessage.

Important note: The R/3 locking mechanism is switched off for courses doing Customizingtherefore, it is necessary for you to check that your settings have been saved. Use DISPLAYafter you have saved your changes to confirm that they are recorded.

7-1 You want to review the port you created earlier that defines where to send youroutbound files so the converter can find them.

7-1-1 Do you require a different port for your Assortment List?

7-1-2 Do you need a different file directory?

7-2 Create a new EDI Partner Profile for your large format store.

Your site is TS##. Where ## is the group number you have been assigned. Youwant to send your Assortment List message directly to your store.

7-2-1 Which message type and IDoc type will you use?

7-2-2 Explain how you do these processes.

7-3 Just to make sure the message type is active, go and check in the IMG that yourmessage type is active.

7-3-1 Was it? How did you find out its status?





7-3-2 Does it matter if WP_PLU is also active in the Change Message pointerfile?

7-3-3 Please explain why or why not?

7-4 Prepare to create your Assortment List profile.

7-4-1 Is there any customizing you must do to ensure that the Condition Typegroup and the Conversion Categories work with your Assortment List?

7-5 Use the copy function to create your Assortment List Profile. Use the name AL##.And only use assortment list types S and H for your site.

7-5-1 What path must you take to access the Assortment List profile?

7-5-2 How did you accomplish this?

7-5-3 Why might a retailer want to use different assortment list types?

7-6 Once you are sure that your Assortment List profile has been saved. Assign it toyour site TS##. At this time also assign the outbound profile OP## to this store thatyou created earlier.

7-6-1 What is the path to the site?

7-6-2 Which tab and field do you access to enter your Assortment List Profile?

Remember to check that the change was saved.

7-7 Your site belongs to Sales organization R300 and distribution channel R1. Initializethe Assortment List message type for your site only.

7-7-1 What path did you take to access the Initialization process?





7-7-2 Did the initialization create an IDoc the first time you tried it?

7-7-3 Were there errors? If yes, what were those errors?

7-7-4 How many IDocs did the system create and why?

7-7-5 How would you correct any errors or, is there a way you can work aroundthe errors?

7-7-6 Using the POS Monitor, determine for which articles IDocs were created.

7-8 Use the IDoc file that was created to determine what data was sent for the firstarticle.

OPTIONAL:

7-9 Create a reduced message type WBBDLD for your assortment list. Assume that youwill not be sending empties data and additionals data.

7-9-1 What path do you take to reduce an IDoc type?

7-9-2 What segment or segments will you not select?

7-9-3 Where must you identify the new reduced message for it to carry yourassortment list?





Merchandise Management System Case Study – Inbound Logistics Documents Exercises


– Inbound Logistics Documents

Topic: Inbound POS Profile and Store Physical

Inventory Customizing and Simulation


• Create an Inbound POS Profile

• Customize the EDI inbound partner profile for this messagetype

• Customize the parameters for Inbound Physical Inventory

• Use the simulation tool for Inbound Physical Inventory.

It is now time to customize and test each of the inbound messagetypes. You are beginning with the back office functions, in thiscase physical inventory. During normal operation the storesdecide when to count inventory, so you are going to test in R/3that way also, plus you want the system to create the inventorydocuments for you.

Important note: The R/3 locking mechanism is switched off for courses doing Customizingtherefore, it is necessary for you to check that your settings have been saved. Use DISPLAYafter you have saved your changes to confirm that they are recorded.

8-1 Create an inbound POS profile IM## and assign it to your store, TS##.

8-1-1 What path did you take to create the inbound profile?

8-1-2 What path did you take to assign the inbound profile to your site?

8-2 Maintain EDI partner profile for processing of store physical inventory data foryour store, TS##. Remember that the physical inventory message is message typeWVINVE. Since we will use the simulation tool to test, don’t forget to set the test

flag!

8-2-1 Which process code did you use for this message type?

8-2-2 What purpose does the process code serve?





8-3 Configure the inbound processing controls for store physical inventory data foryour POS inbound profile, IM##, in such a way, that a physical inventory documentis created automatically in the R/3 system (unless already existing).

8-3-1 What field must you set to ensure that the physical inventory document iscreated directly, and what value did you use?

8-4 Simulate the inbound processing of store physical inventory data from your store,TS##, counting only article R100016. Assume, that the count of R100016 in TS##found 2 pieces more than currently is in stock according to the R/3 inventory (checkthis first!).(Hint: On the simulation screen, leave the field UNIT blank.)

8-4-1 What path did you take to check the inventory of the article for your site?Record the amount of stock currently available.

8-4-2 What path did you take to simulate the physical inventory inbound

message?

8-4-3 Verify the results of the simulation. Was a physical inventory documentcreated?

8-4-4 What was its status?

8-4-5 Check your stock after simulation. Are there any changes?

8-5 Post the difference manually.

8-5-1 Did the stock change after posting the difference to the physical inventorydocument? How did you check this?

8-5-2 Did the status of the physical inventory document change.








Topic: Inbound Article Master Data Changes




• Customize the parameters for Inbound Article Master Datachanges

• Use the simulation tool for Inbound Article Master Datachanges.

You are know you want to send article changes from time to time,so you will test article master data changes message types.

9-1 In the inbound EDI partner profile of your store, TS##, maintain the controls forinbound processing of article master data changes (message types WP_EAN andWP_PLU). Don’t forget to set the test flag to use the simulation tool!

9-1-1 Which process code did you assign to each message type?

9-2 Configure the inbound processing controls for EAN/UPC changes for your POSinbound profile, IM##, so that such changes are NOT posted to the article masterautomatically.

9-2-1 How did you accomplish this?





9-3 Simulate inbound processing of article master data changes from your store, TS##,and execute the resulting workitem for your store only. (Hint: On the simulationscreen, refer to the article R100016 by its article number and and use the EAN/UPCnumber that your instructor provides.)

9-3-1 What path did you take to find and execute your workitem?

9-4 What would headquarters’ staff have to do, if she or he would like to follow the proposal of the store manager? Where are the required changes made? (Do notmake these changes, but consider how and where you would change article masterdata.)





Merchandise Management System Case Study Inbound Logistics Documents Exercises


Inbound Logistics Documents

Topic: Inbound Store Order Customizing and

Simulation



• Customize the parameters for Inbound Store Orders

• Use the simulation tool for Inbound Store Orders

You are continuing to test each of the inbound message types, inthis case store orders.

10-1 In the EDI partner profile of your store, TS##, maintain EDI controls for inbound processing of store order data (message type WGSREQ). Don’t forget to set thetest flag!

10-2 Configure the inbound processing controls for store order data for your POS

inbound profile, IM##. Copy the settings maintained for inbound profile IM00.Then modify those settings to have store order inbound processing always try togenerate a purchase order (both for internal and for external procurement), and to

produce an error if unsuccessful.

10-2-1 What settings did you have to change?





10-3 Simulate the inbound processing of a store order for10 pieces of article R100016 byyour store, TS##.

On the simulation screen, use Identifier 006 to identify the

article by its article number, and leave the field Unit blank.

10-4 Verify the result of the simulation.

10-4-1 Was a purchase order created?

10-4-2 What was your source of supply?

10-4-3 What steps did you take to verify the result?








Topic: Inbound Goods Movement Data




• Customize the parameters for Inbound Goods Movement

• Use the simulation tool for Inbound Goods Movement.

You are continuing to test each of the inbound message types, in

this case goods movement. You also remember that without agoods movement control attached to your inbound profile, salesmovements will not be processed by the POS interface.

11-1 In the EDI partner profile of your store, TS##, maintain EDI controls for inbound processing of goods movement data (message type WPUWBW). Don’t forget toset the test flag!

11-2 Configure POS Goods Movement control to allow the system to perform acomplete search and if no document is found, to generate a purchase order.

11-3 Configure the inbound processing controls for goods movement data for your POSinbound profile, IM##, to allow goods movements data between quality inspectionstock and unrestricted use stock to be processed by the POS interface (movementtypes 321 and 322). For movements of either type, do not post to a cost center, anddo not override the standard G/L account determination in MM customizing. Whileon the control screen, also make entries for movement types 251 and 252 to be usedlater with your sales messages.

11-3-1 How many entries were you required to make?

11-3-2 What were they?

11-4 Simulate inbound processing of a movement of half of the quantity of articleR100016 in quality inspection stock (check quantity first!) to unrestricted use stockin your store, TS##.

11-4-1 How much R100016 was in quality inspection stock before you started?





Merchandise Management System Case Study –Inbound Documents Exercises


–Inbound Documents

Topic: Inbound Financial Transactions




• Customize the parameters for Inbound Financial Transactions

• Use the simulation tool for Inbound Financial Transactions

You know one important balancing transaction is the financialtransactions that take place in the stores. So, you will test theFinancial Transactions message simulation.

12-1 In the EDI partner profile of your store, TS##, maintain EDI controls for inbound processing of financial data (message type WPUFIB). Don’t forget to set the testflag!

12-2 Configure the financial transactions inbound processing controls for. your POS

inbound profile, IM##, so that cash-to-bank deposits of a store (identified byfinancial transaction type CABA) produce the following two posting items in FI:

ITEM G/L ACCOUNT POSTING KEY1 110000 40 (debit entry)2 100009 50 (credit entry)

12-3 Simulate the inbound processing of a cash-to-bank deposit of 173712 USD by yourstore, TS##.

12-3-1 Verify the result of the simulation. Record the path you took to find yourresults.

12-3-2 What G/L Document was created and what items were posted?





Merchandise Management System Case Study –Inbound Documents Exercises



Topic: Inbound Aggregated Sales and Payment List



• Customize the EDI inbound partner profile for these messagetypes

• Customize the parameters for Inbound Aggregated Sales andPayment List

• Use the simulation tool for Inbound Aggregated Sales andPayment List

You are testing the front office inbound message types, in thiscase you want to know if the Aggregated Sales and Payment ListsIDocs will provide enough information to satisfy your financedepartment.

13-1 In the EDI partner profile of your store, TS##, maintain inbound processingcontrols for both aggregated sales data and payment list data (message typesWPUUMS and WPUTAB). Don’t forget to set the test flag!

13-2 Configure the inbound processing controls for aggregated sales data for your POSinbound profile, IM##. Copy the settings maintained for inbound profile IM00.Then modify them to not update replenishment based inventory because none of thestores carrying POS inbound profile IM## use replenishment based inventory.

13-2-1 How do you ensure that replenishment based inventory is not updated?

13-3 Configure the inbound processing controls for payment list data for your POSinbound profile, IM##. Copy the settings maintained for inbound profile IM00.

13-4 Simulate the inbound processing of aggregated sales data from your store, TS## for2 pieces of article R100016 for a total sales value of 392 USD, which included acomplaint discount of 6 USD (condition type RB10).

13-4-1 Verify the result of the simulation. What documents are created by inbound processing?





13-4-2 What does the article document tell you? How did you access it and whataccounts were posted?

13-4-3 How do you access the billing document? What does the billing documenttell you?

13-4-4 Can you access G/L accounting documents? How?

13-4-5 View the open line items in your customer account. What additionalinformation does that give you?

13-5 Simulate the inbound processing of the associated payment list data from yourstore, TS##. You want to record total check sales value of $392. Remember thatyou have an active Conversion Category!

13-5-1 What document types are created as a result of a payment list simulation?





Merchandise Management System Case Study – Inbound Documents Exercises


– Inbound Documents



• Customize the EDI inbound partner profile for this messagetypes

• Use the simulation tool for Cashier Statistics.

You are continuing to test each of the inbound message types. Forthe prior inbound testing you have entered your cashier number.

Now you will add a cashier message to complete the posting tothe info system

14-1 In the EDI partner profile of your store, TS##, maintain EDI controls for inbound processing of cashier statistics data (message type WPUKSR). Don’t forget to setthe test flag!

14-2 Simulate the inbound processing of cashier statistics data from your store, TS##.Use your group number for your cashier number. Consider entering a composite ofthe data you have passed in the sales transactions. You might also capture the

discount (condition type) and amount, and.an amount of canceled transactions andtheir value.

14-2-1 What path do you take to simulate this transaction?

14-2-2 Verify the result of the simulation.

How did you verify the results?

14-3 Which info structure is updated by the upload of cashier statistics by a store?

14-4 What are the characteristics of this info structure?






14-6 What information do the Loss Prevention and the POS balancing reports give you?





Merchandise Management System Case Study – Outbound Assortment List Solutions


– Outbound Assortment List

Topic: Customizing Assortment List Profile andInitializing the Store

7-1 You want to review which port will define where to send your outboundAssortment List so the converter will find them.

The paths you take to review the port is:


SAP Reference IMG

Basis Components Distribution (ALE) Sending and Receiving Systems

Systems in Network Asynchronous Processing Assigning Ports Define port

or

Tools Business communication, IDoc double-click Port Definition

You can also use Transaction code WE21.

7-1-1 No, the system will use the same port for the Assortment List.

7-1-2 No, the name of the file directories where all your outbound messages,including the Assortment List, reside is:

Outbound: \\app.server\sapmnt\trans\ POS\ POSout\ (note there are no spaces

and the last \ is important)

Status: \\ app.server \sapmnt\trans \ POS\ POSstat\

You do not have to create a separate directory, because Assortment List isessentially just another outbound message.

7-2 You need to create your EDI Partner Profile for your site TS##.

The path you take to do this is:


SAP Reference IMG




or

Tools Business communication

IDoc double-click Partner Profile

or use transaction code WE20.





7-2-1 You will use message type WBBDLD and IDoc type WBBDLD02.

7-2-2 On the left side of the screen is a tree with the available Partner Types,expand the Partner Type KU, Customer. You note that other stores are listedhere, but not your store. To create an EDI Partner profile for your storeTS##, press the create button.

You are now able to enter information in the upper third of the work area.


Partn. number TS##

Partn Type KU

Typ US

Agent IRT360-##

Language EN for English or

DE for German

Press Save. Now the Create Outbound Parameters button is active.Press the Create Outbound Parameters button below the Outbound parmtrs.Section on the work area. On the next screen, create your message details.


Message type WBBDLD

Receiver port T8##

IDoc Basic Type WBBDLD02

Output mode Transfer IDocs immed

Start subsystem

Press Save.

7-3 To ensure that the message type is active, use the following path.


SAP Reference IMG


Business Processes Master Data Distribution Replication of Modified Data

7-3-1 Select Activate Change Pointers for Message Types, click on Position and

enter W* to bring you to the POS message types, to ensure that WBBDLDis set to active.

Yes, the message type is active if it is checked.

7-3-2 No, both message types can be active. In a live situation several messagetypes will be active.

7-3-3 This one table is used by the system and one company could be usingdifferent message types to supply their stores with information.





7-4 Prepare to create the Assortment List profile by checking the Condition TypeGroup and the Conversion Categories.

The path to check these


SAP Reference IMG

Sales and Distribution POS Interface Outbound Maintain POSCondition Type Group

Also in the POS Interface tree select Enhancement Conversions

7-4-1 No, as long as they have been created and assigned to my outbound profileand that profile assigned to my site nothing else is necessary. However, ifthe code partners are different, a new Conversion category would benecessary.

7-5 Use the Copy function to create your Assortment List profile or create it using New

entries. Use the following path to access the Assortment List profile:

7-5-1 Use the path:Tools AcceleratedSAP Customizing double-click Edit


Logistics - General Assortment Assortment List Maintain profile

for assortment lists

7-5-2 Copy using AL00 as the basis to save data entry. Select AL00 and pressCopy. Enter your Assortment name, AL## and press the check.

The system asks you to ‘ specify object to be copied ’. Select Copy all . Afterthe system displays the number of entries that were copied, select your newAssortment List and double-click Maintain assortment list profile

parameters in the Dialog Structure.

Select the buttons for Assortment list type 1, R and T and press Delete.

Save your data, back out, and return to ensure the customizing was saved.

7-5-3 A retailer might use different assortment lists to maintain different cycletimes to handle slow moving goods differently from fast moving goods.

7-6 Assign the Assortment List profile to your site TS##.

7-6-1 Use the following path to assign your profile AL##.

Logistics Retailing Master Data Site Data Site double-click

Change. Enter your site name and select Enter .

7-6-2 Select the POS tab and enter your Assortment List profile AL## in the fielddesignated. Enter OP## in the outbound profile field. Press Save.

7-7 Initialization

7-7-1 To perform an Initialization, take the following path:





Logistics Retailing Distributed Retailing POS Interface

Outbound Assortment List double-click Initialization

Note: There is a second path to Assortment List. It is:

Logistics Retailing Master Data Assortment/Listing Assortment List Generate double-click Initialization


Sales Organization R300

Distribution channel R1

Customer no. - site TS##

Assortment list type S

H

Select Execute. When the initialization is complete a report screen displays.

View that screen and note the information it provides.

Back out of the report and check the POS monitor to determine if your

initialization completed with no errors.

7-7-2 Select POS Monitor , enter your site TS## and press execute.

Expand Outbound , select Processed . If your site is not there, select Not fully

processed.

The initialization should have been successful.

If it was not, double-click the line that is displayed. On the next screen,select one of the red high lighted lines, press Display Log to see the error

messages. When you click on some categories’ error messages, the Help

will lead you to the customizing area that must be corrected. However, in

this case, simply, identify those IDoc categories that will continue to stop

the processing of the Initialization.

7-7-3 There were no message stopping errors.

7-7-4 The system creates two IDocs, one for each assortment type.

7-7-5 IDocs were created for several articles.

7-8 Now, go to the IDoc file to view the Assortment List communication IDoc.

The path to view your communication IDoc is:

Transaction code: AL11

When the SAP Directories screen displays, page down to DIR_TRANS. Double

click to expand the directory. Double click on POS and then on POSout and then

expand your IDoc by double clicking it.





OPTIONAL:

7-9 Create a reduced message type WBBDLD

7-9-1 The menu path to display the structure of an IDoc type is:




Business Processes Master Data Distribution Scope of Data for

Distribution Message Reduction Create Reduced Message Type

Enter ZTS## in the Reduced message type field, and press Create. EnterWBBDLD in the Message type reference field, press Check. Enter ReducedMsg WBBDLD for TS## in the Description field.

Expand the folder E1WBB01, the major segment.

Expand all the folders, including the sub-folders so that all segments ofIDoc type WBBDLD03 are exposed.

7-9-2 Select all segments, except:

E1WTADAL1 – AdditionalsE1WTADAL2 – Additionals textE1WBBEM – EmptiesE1WBB21 – BOME1WBB22 – Article valuation.

E1WBB22 – Article valuation cannot be selected as it is part

of the not yet released WBBDLD03, where the other

segments are released inWBBDLD02 for 4.6B.

Save your selection. Back out to the main screen. Select Activate change

pointers, which inserts your reduced message type in the Activate change

pointer table and sets it to active.

7-9-3 You must also identify the reduced message type in your Assortment List

profile. Use the path:



Logistics - General Assortment Assortment List Maintain profile

for assortment lists

Select each Assortment List type and enter your reduced message typeZTS## in the Reduction field.

Save your changes and if you like reinitialize your store assortment, using

the description in step 7-7, above.





Merchandise Management System Case Study – Inbound Logistics Documents Solutions



Topic: Inbound POS Profile and Store Physical

Inventory Customizing and Simulation

8-1 Create and assign POS inbound profile

8-1-1 The path to create the POS inbound profile, IM## is:


SAP Reference IMG

Sales and Distribution POS Interface Inbound Maintain profile

for POS inbound Maintain profile for POS inbound

Select New entries and enter your profile, IM## and the description group ##.

8-1-2 The path to assign the POS Inbound Profile to your store is:

Logistics Retailing Master Data Site Data Site double-click Change

Enter your site name TS## and select Enter .

Select the POS tab and enter your POS inbound profile in the designatedfield.

8-2 Maintain EDI partner profile and controls for processing store physical inventory

data

The path to maintain EDI partner profiles is:


SAP Reference IMG




or

Tools Business communication IDoc double-click Partner Profile

Expand Partner type KU . Select your site TS##. Scroll down to display Inbound






Field Name Values

Store TS##


Fiscal year current

Qualifier artn

Identifier R100016

Quant. 2 + the Stock overview Q

Enter your test data. Press Save.

8-4-3 When the system completes the simulation, press IDoc Status. On the nextscreen, press POS monitor . Record the Phys. Inventory document numberand double click on the IDoc to display physical inventory count. Yes, adocument should have been created.

8-4-4 On the physical inventory document screen, select Phys. inv. History to

determine that the status is “counted”.8-4-5 To check if the simulation changed your inventory, use the following path:

Logistics Retailing Info System/Planning Retailing Standard

Analyses Article double-click Article

This is a different path to check your inventory. It is only

intended to give you another way to check your article. The

earlier inventory check also will accomplish the same goal.

Enter your store and article number. Press Process and drill down on the

subsequent screen. Page down on the next display to note the Quantity and

value associated with this article. It should not have changed.

8-5 To accept the new count, post it using the following path:

Logistics Retailing Merchandise logistics Physical inventory Difference

double-click Post

8-5-1 The system defaults your Physical inventory document number, or enter the

document number and press Enter . Note the difference quantity and value.

Press Save to accept the change.

8-5-2 Review your inventory to note the new quantity and value.

Logistics Retailing Info System/Planning Retailing Standard

Analyses Article double-click Article

Once on the screen, you can also check that the system tracks all goods

movements, by using the following path:

Extras Goods movements Article document








Topic: Inbound Article Master Data Changes


9-1 Maintain EDI controls for processing article master change data in the EDI partner profile of your store, TS##. Use the path:


SAP Reference IMG







9-1-1 The message type and process code are:


Message Type WP_EANWP_PLU

Process code WP_EWP_P

Test Check

Trigger immediately check

9-2 Configure inbound processing of EAN/UPC change data so that such changes are NOT posted to the article master automatically.


SAP Reference IMG

Sales and Distribution POS Interface Inbound→ Automatic EAN/UPC

Creation Control

9-2-1 Select New Entries to enter your inbound profile, IM##, and leave the field Auto. EAN creation blank. Blank means do not update automatically.





9-3 To simulate processing an article master change use the following path:


Simulation double-click Master data

Enter your store TS## and today’s date. Then select EAN references.

On the detail screen enter the following information associated with article

R100016:

Field Name Values

Change flag MODI

Dates accept today’s date

main EAN/UPC 2050000001208

EAN/UPC Provided by instructor

Press Save.Press IDoc status to determine if your document posted without errors.

9-3-1 Since it was configured to stop rather than to automatically update, therewill be a workflow item. To execute your workitem, use the following path:

Press POS Monitor , double-click on the message attached to your IDoc. Onthe resulting help screen double-click on the message Office inbox(highlighted in red).

9-4 The required changes would have to be made in the article master by someone inthe organization authorized to accept them.





Merchandise Management System Case Study Inbound Logistics Documents Solutions


Inbound Logistics Documents

Topic: Inbound Store Order Customizing and

Simulation

10-1 To simulate inbound processing of store orders, message type WGSREQ must bemaintained in the EDI partner profile with the test flag set. Use the path:


SAP Reference IMG








Enter WGSREQ in the Message type field. Then select Matchcode (F4) on the

Process code field. It is WVFB. Set the test flag and also set the message type toTrigger immediately.

10-2 Maintain the inbound processing controls for store orders for your POS inbound profile, IM##, copy the settings of inbound profile IM00. Use the following path:


SAP Reference IMG

Sales and Distribution POS Interface Inbound→ Store order control

To copy profile IM00, select it from the list of inbound profiles, then select theCopy icon. When the copied screen displays, enter your profile, IM## in the key

field.10-2-1 Enter 3 in Document type default, leave blank, or clear, ‘Default doc.

category external store order’ and ‘Default doc. category internal storeorder’ at the bottom of the screen to have a purchase order created.

10-3 Simulate inbound processing of a store order, TS##. Use the path:


Simulation double-click Store order





Enter your store TS## in Customer and accept today’s date and the Messagecategory, WGSREQ02. Select Order Overview.

On the simulation screen, enter:

Field Name Values

Identifier 006

Article/EAN R100016

Quantity 10

Uni Leave blank

Press Create icon.

10-4 To verify the result of the simulation:Press IDoc status and POS monitor when the system completes the simulation.

10-4-1 Yes, a purchase order should be created.

10-4-2 Double click on the Purchase order number. The Purchase Order ItemOverview screen displays and you will find that the Vendor from whom you purchase the tuner is R3002, Meyer Hardware, and the order type was astandard order, NB.

10-4-3 Select Header Statistics to view the processing statistics. SelectMatchcode (F4) on the status field to determine what the status codesignifies.

You can also access more data by backing out of the POS monitor andtaking the following path:

Logistics Retailing Purchasing Purchase order Purchase order

double-click Display








Topic: Inbound Goods Movement Data


11-1 To simulate inbound processing of store orders, message type WPUWBW must bemaintained in the EDI partner profile with the test flag set.


SAP Reference IMG







Enter WPUWBW in the Message type field. Then select Matchcode (F4) on theProcess code field. Use process code WPUW.

11-2 Configure inbound processing controls for goods movement data for your POSinbound profile, IM## to allow the system to search all purchasing documents andif no purchase order is found to create one.


SAP Reference IMG

Sales and Distribution POS Interface Inbound→ POS Goods Movement

control

Select New entries and accept the defaults:


PO search Perform complete search

PO not found GR with PO generation

Save and back out.





11-3 Configure inbound processing controls for goods movement data for your POSinbound profile, IM## to allow the system to move data between quality inspectionstock and unrestricted use stock to be processed by the POS interface. Also createentries for Sales movement types. Use the path:


SAP Reference IMG

Sales and Distribution POS Interface Inbound→ Movement type-


11-3-1 You require 4 entries, each movement type with its reversal.

11-3-2 Select New entries and then enter: These are your entries:


POS Inbound Profile IM##

Movement type 321

322

251

252

Rev. mvnt.ty 322

321

252

251

For the movement type lines, do not enter a cost center, and do not enter aG/L account. Account determination in MM will default in the correctaccount number.

11-4 Simulate the inbound processing of a movement of half of the quantity of articleR100016 in quality inspection stock to unrestricted use stock in your store, TS##.Check for the inventory level first.

11-4-1 There are 30 pieces in quality inspection.

11-4-2 You can find this information using the path.

Logistics Retailing Merchandise logistics Inventory management

Environment Stock double-click Stock overview

Now simulate the movement. Use the path:


Simulation double-click Goods movements

Enter your store number TS## and select Goods Movements.

On the simulation screen enter the following:





Field Name Values

Reference no. IRT360-##

The second qualifier ARTN

Number R100016Mtyp 321

Quantity 15

Press Save.

11-5 Press IDoc status to verify the result of the simulation, and then POS monitor toview the document.

11-5-1 Discussion, if you did not expect the result.

11-5-2 Yes, there is an article document. Double click on it and select Accounting

docs on the resulting screen.11-5-3 No accounting document should have been created because there was no

change in your inventory value, just the location.





Merchandise Management System Case Study –Inbound Documents Solutions



Topic: Inbound Financial Transactions


12-1 To simulate inbound processing of financial transactions, message type WPUFIBmust be maintained in the EDI partner profile with the test flag set, use the path:


SAP Reference IMG







Enter WPUFIB in the Message type field. Then select Matchcode (F4) on theProcess code field. The process code to use is WPUF.

12-2 Configure inbound processing of financial transaction, in this example, cash-to- bank deposits for your POS inbound profile, IM##.

You were to establish the financial transaction type with the following postingitems in FI:

ITEM NO. G/L ACCOUNT POSTING KEY1 110000 40 (debit entry)2 100009 50 (credit entry)

Use the following path to check that the Financial Transaction type, CABA, has

been created: Tools AcceleratedSAP Customizing double-click Edit Project(SPRO)

SAP Reference IMG

Sales and Distribution POS Interface Inbound→ Transaction types for

financial transactions

If the transaction name is not entered on this screen, please create one for CABA.Only one is necessary, these are SAP Retail specific rather than site or profilespecific.





Now, also in the Inbound section of the IMG, select Transaction type-dependent

control of financial transactions

Select New entries. Enter the following details:

Profile /trans item G/L Acct Posting Key

IM## / CABA 1 110000 40

IM## / CABA 2 100009 50

Select Save and back out

12-3 Simulate the inbound processing of a cash-to-bank deposit of 173712 USD by yourstore, TS## using the path:

Logistics Retailing Distributed Retailing POS interface Extras

Simulation double-click Financial Transactions

Enter the following data in the header area:

Field Name Values

Customer TS##

Reference No. IRT360-##

Transaction type CABA

On the item level, enter:

Field Name Values

Item 1

Acc. Assgnnt Obj Blank

Cost center Blank

Amount 173712

Crcy USD

Assignment Line 1

Press Save.

12-3-1 To verify the result of the simulation, select IDoc status. If there were noerrors press POS monitor , view your IDoc.

12-3-2 To display G/L account document in the case of FI transactions, use this path:



Items as expected.





Merchandise Management System Case Study –Inbound Documents Solutions



Topic: Inbound Aggregated Sales and Payment List


13-1 To simulate inbound processing of aggregated sales, message type WPUUMS must be maintained and for payments lists, message type WPUTAB must be maintainedin the EDI partner profile with the test flag set. Use the following path:


SAP Reference IMG


Business Processes Partner Profiles and Time of Processing Maintain Partner Profile Manually

or

Tools Business communication

IDoc Partner Profile





Message Type WPUUMS (aggregated sales)WPUTAB

Process code WPUU (aggregated sales)

WPUT

Test Check

Trigger immediately Check

13-2 Configure inbound processing of aggregated sales data

Copy the settings maintained for inbound profile IM00 or SAPD, if IM00 is not

available.

Use the following path to maintain control of Aggregated sales:


SAP Reference IMG

Sales and Distribution POS Interface Inbound→ Aggregated sales control

13-2-1 To eliminate replenishment based inventory updating, deselect field Update

rep.-based IM on the Aggregated sales control-screen.





13-3 Use the following path to maintain control of Payment lists:


SAP Reference IMG

Sales and Distribution POS Interface Inbound→ Payment list control

Copy the settings maintained for inbound profile IM00 or SAPD, if IM00 is not

available. Modify it so that the Calculation schema is POSUSJ.

13-4 Simulate the inbound processing of aggregated sales data from your store of 2 pieces of article R100016 for a total sales value of $392, which included acomplaint discount of $6.

Logistics Retailing Distributed retailing POS interface Extras


Enter your store number, TS## and accept today’s date. Select Aggregated sales toaccess the item level.

Field Name Values

Wahrung (Currency) USD

Qual ARTN

Number R100016

Sales qty 2

Sales value 392

Select Edit Item discount

Field Name Values

CTyp RB10

Sales discount 6

Press Save .

13-4-1 Select IDoc status to verify the result of the simulation. With a status of 53,Application document posted, select POS monitor to view the resultingdocuments.

Two documents are created, a Billing document and an Article document.13-4-2 Double click the Article document, select Accounting and you will see the

inventory postings, to relieve Inventory and increase Cost of goods.

13-4-3 Double click on the Billing document, select Accounting , to display thedocument choices.

13-4-4 Double clicking on each of the document types, displays the detailinformation associated with each document type.





13-4-5 In addition to accessing these documents through the POS monitor, you alsocan use the following paths to access them through the components.

To display article documents:

Logistics Retailing Merchandise logistics Inventory management


To display billing documents:

Logistics Retailing Sales Billing Billing document double-click Display

To display G/L account document:



To display open line items in a customer account:

Accounting Financial accounting Accounts receivable Account

double-click Display/change line items

Enter Customer = TS## (the customer associated with your site), Company

code = R300, and select field Open items

13-5 Simulate the inbound processing of the associated payment list data from yourstore, TS##. You want to record total check sales value of $392.



Enter your store, TS## and select Means of payment .

Enter 151 (by check) for payment method and 392 for Final total and USD, thetarget currency.

13-5-1 Select IDoc status to verify the result of the simulation. With a status of 53,Application document posted, select POS monitor to view the resultingdocument. Only one document is created, a Billing document.





Merchandise Management System Case Study – Inbound Documents Solutions


– Inbound Documents


14-1 To simulate inbound processing of cashier statistics, message type WPUKSR must be maintained in the EDI partner profile with the test flag set. Use the path:


SAP Reference IMG




or






Message Type WPUKSR

Process code WPUK

Test Check

Trigger immediately Check

Reminder: No specialized customizing is required for

inbound processing of Cashier Statistic. However, the

Information Structure must be active.

14-2 Simulate the inbound processing of cashier statistics data, uploaded from your

store, TS##.





14-2-1 Use the following path:



Enter your store, TS## accept today’s date and press Cashier statistics .

On the simulation screen, leave the update group blank and the systemdefaults 800. Enter USD in Target currency.


Cashier Group ##

Condition type RB10

Number of conditions 1

Amount 6

Value canceled transactions 200

No. terminations 4

Sales 392

14-2-2 Verify the result of the simulation first by selecting IDoc status to determineif the simulation worked error free. Then, take the following path to Cashierstandard analysis:

Logistics Retailing Info system/Planning Retailing Standard

analyses Special processes Sales audit double-click Cashier

14-3 To find which info structure is updated by the upload of cashier statistics by a store.

On the initial list generated by the Cashier standard analysis, select Goto Other

info struct... Note the structure S122

14-4 To determine the characteristics of this info structure.

On the initial list generated by the Cashier standard analysis, select Extras Disp.

std drilldown. You will see the answer: Sales district, Site, Cashier number,Condition type, and Date.






On the initial list generated by the Cashier standard analysis, select Edit Choose

key figures...

14-6 These two reports capture the data sent by the store that has been captured by thePOS system in the store. Depending on the system, every key press at the register iscaptured by the store system providing the sales auditor with valuable loss

prevention information.





SAP AG 2001

Sales Audit Process

Sales Audit Postings to R/3 Applications

A Day in the Life of the Sales Auditor …

SAP AG

Contents:

Sales Audit Reporting





SAP AG 2001

Describe the Sales Audit Processing steps

Explain which R/3 applications are affected

by Sales Audit

Describe the tasks of a sales auditor using

SAP Retail

At the conclusion of this unit, you will be able to:

SAP AG

Objectives





SAP AG 2001


Unit 8 Conclusion






Unit 1 Introduction

Course Overview





SAP AG 2001

IDocfile

IDocfile

ApplicationServer

DatabaseServer

R/3 Applications

> startrfc

22

POS-Converter

IDoc

file

WAN

LAN

POS data

EDIDC

EDID4

EDIDS

directory = /.../.../...file name = ...

3

2

1

4

5

6

Inbound Processing: Data Flow

We described the flow of data inbound in the unit, Technical Aspects of POS. At this time, we focus

on the movement of data from the original database files to the applications and to the SAP BW

Information Structures.





SAP AG 2001

System receives data from POS Converter in IDoc format

Store IDoc in R/3 database

Process Sales Audit data

Success?Create error messages

for POS Monitor

Post data to different

modules

User analyzes and

fixes the problems

User can check

the posting

Initiate reversal

of transaction

Repeat processing of unprocessed transactions

Ok?

B

4

1

A

C 6

D F

J G

E

H

No Yes

No Yes

POS

I

nbound

Mon

Itor

Pr

ocessIng

Sales Audit: Process Steps

Step A - The IDoc interface calls Sales Audit Processing, either directly after the POS converter

triggered R/3. Details of this step are explained in the next slide. However, processing means to

verify the data in one IDoc, prepare it for posting, and posting it.

Step B - the system checks the success of posting and posts the successful transactions of the IDoc(step 6) for those transactions that are in error, the system creates a message in the error log (step C).

Step D - You can track the error messages and fix them through the POS monitor.

Step 6 - When step B is successful, the document flow is also posted. The document flow reports the

documents that are created in SAP Retail by store and transaction.

Step G - Although Sales Audit processing should normally detect all possible problems

automatically, when you are testing it is a good idea to do some manual checking and when all the

IDocs are processed to run RIS and exception reports. Use the display function in the POS monitor to

view the follow-on billing and article documents for individual transactions. When ready to test SAP

Retail with SAP BW, deactivate RIS and use a similar process reviewing your reports in SAP BW.





SAP AG 2001

Preprocessor handling (supplied and customer)

Prepare documents for posting

Call User-Exit for document modifications

Errors? Write log messages

Post the different documents

Write log messages

Post the document flow

Errors?

Call Customer postprocessor

A.3

A.1

A.2

A.4

A.7

A.5

A.6

A.8

A.9

A.10

Do

for

each

trans-

action

No

Yes

Yes

No

Sales Audit Step A in Detail

Step A.1 - Customer preprocessing handling is described in detail in the next slide.

Step A.2 - When Customer preprocessing is complete, Sales Audit Processing prepares the data for

posting to the follow-on functions.

Step A.3 - A second user exit is called. If it is active, the data prepared for the follow-on functions is

passed to it and the posting controlled by the exit.

Step A.4 - Sales Audit checks if the User Exit has created an error or rejected the current transaction.

Step A.5 - Log errors to the POS monitor that were identified in step A.4.

Step A.6 - Pass error free transactions to follow-on functions that handle posting to the R/3 database.

Step A.7 - Sales Audit Processing checks if the follow-on functions created errors for the current

transaction.

Step A.8 - Log errors to the POS monitor that were identified in step A.7

Step A.9 - Follow-on processing returns the number of the created document to Sales Audit

Processing. Sales Audit assigns this number to the current transaction number and posts theinformation as document flow to the database which can be displayed in the POS monitor.

Step A.10 - When the IDoc is completely processed, Sales Audit calls the Post Processor User Exit.

If one is available, it can be set up to trigger functions that you would like performed after IDoc

processing is complete.





SAP AG 2001

Messages

raised?

IDoc

modified?

Change log

required?

Reject

IDoc?

Create log messages

for POS Monitor

Call preprocessor

Log changes

for POS Monitor

Update IDoc

database

Log rejection for

POS Monitor and exit

A.1.1

A.1.2

A.1.3

A.1.4A.1.5

A.1.6

A.1.7

A.1.8A.1.9

Yes

No

Yes

No

Yes

No

Yes

No

Sales Audit Step A.1 in Detail

The customer preprocessor is an optional User Exit that can be maintained to check the contents of

IDocs. The contents of the preprocessor are customer specific. However, if the preprocessor

determines problems it must be capable of passing error messages back to Sales Audit.

Step A.1.2 - Sales Audit checks for error messages and saves them to a database where they can bedisplayed later in the POS monitor.

Step A.1.4 - Sales Audit checks if the IDoc was corrected by the preprocessor and if a change log is

required. If a change log is required, it is recorded in step A.1.6.

Step A.1.7 - Sales Audit copies any modified IDocs to maintain the original data and posts the

changes to the IDoc database.

Step A.1.8 - Sales Audit checks if the preprocessor rejected the entire IDoc. If it did, Sales Audit

creates a log entry for the POS monitor and stops the processing of that IDoc.

When Sales Audit has completed checking the results of the customer preprocessor, it passes the

IDoc to step A.2, as shown in the previous slide.





SAP AG 2001

Sales Audit: Data Flow (2/2)

InfoCubesUpdate

rules

2LIS_44_POSREC

2LIS_43_POSCAS

InfoSource

0RT_C07

Receipts

0RT_C06

Cashier

0RT_C08

POS Monitoring

SAP BW

The data is transferred to the InfoSource structures, which are the metadata describing extract

structures.

Update rules control how the data is stored in the Infocubes.

The above noted Infocubes are delivered with the Business Information Warehouse and queries

provide access to necessary Sales Audit data.

Additional stand-alone InfoObjects can be defined in BW during implementation, if you find them

necessary.





SAP AG 2001

Market Basket Info: Data Flow

InfoCubesUpdate

rules

2LIS_44_POSREC

InfoSource

0RT_C30Receipts

0RT_C31

Receipt /Article

Similarly, the receipt data from the POS interface is delivered to the Market Basket Analysis

Infocubes.





SAP AG 2001

Sales Audit Postings to R/3 Applications (1/3)

Replenishment

Cost Center Acctng

Profitability Analysis

Profit Center Acctng

0RT_C07

0RT_C30

0RT_C31

BW

Sales/Returns

Goods Receipts

Other Gds Mvmnts.

MM

BillingSD

Stock Ledger

G/L Accounts

Accounts receivable

Credit Card Proc.

Accounts payable

FI

CO

WPUBON01

WPUUMS01

Follow-on Functions

various

An example of Sales Audit posting to R/3 modules is that of Sales, IDoc types, WPUBON01 and

WPUUMS01. As shown, the IDoc can update Billing, Replenishment, Inventory Management, and

SAP BW.

Billing is called for each sales transaction to:

- determine additional figures such as prices and discounts - calculate additional figures

- prepare posting to financial accounting - calculate sales taxes or process those

- manage credit card data and prepare it for further 3,9,that are provided by another system

processing in FI and credit card settlement

- provide follow-on functions with the necessary figures

MM, Inventory Management can be supplied with Sales Audit data and also automatically updates

the stock ledger. Also, Cost Center Accounting can be posted automatically.

Updates to financial accounting are triggered automatically by inventory management and billing.

Inventory management provides the stock ledger with goods movements and billing provides the

following account types: General Ledger and Accounts Receivable.

The BW structures, 0RT_C07, 0RT_C30, and 0RT_C31 are posted directly by the IDoc whereas

other information structures are posted by the individual applications as shown.





SAP AG 2001

Follow-on Functions


Replenishment

Cost Center Acctng

Profitability AnalysisProfit Center Acctng

various

0RT_C06

BW

Sales/Returns

Goods Receipts

Other Goods Mvmnts.

MM

BillingSD

Stock Ledger

G/L Accounts

Accounts receivable

Credit Card Proc.

Accounts payable

FI

CO

WPUKSR01

The Cashier Statistics inbound message, IDoc type WPUKSR01, updates only the BW structure.





SAP AG 2001


Replenishment

Cost Center Acctng

Profitability Analysis

Profit Center Acctng

Sales/Returns

Goods Receipts

Other Goods Mvmnts.

MM

BillingSD

Stock Ledger

G/L Accounts

Accounts receivable

Credit Card Proc.

Accounts payable

FI

CO

WPUFIB01

0FIGL_C01

0FIAR

0FIAP

BW

In the case of the Financial Transactions, the posting is directly to the Finance component and no

data is recorded directly in the BW.

The finance component, however, feeds several Infocubes.





SAP AG 2001

Describe the daily tasks of a Sale Auditor in

SAP Retail


A Day in the life…: Topic Objectives





SAP AG 2001


1. POS Monitor

Communication Complete?

Research Errors Edit Errors

2. Business Information Warehouse

Review daily reports

A Day in the Life...

Course Case Study Wrap-up:

- The Smart Retailer project team has installed SAP Retail and SAP BW, their work is completed.

- Now, the Sales Audit business group takes ownership to perform the day to day operation of

POS.





SAP AG 2001

SAP Retail

?

Completeness check on POS inbound

Date 12/31/00-1/5/01Partner number

R317, R316

Partner Message OK Error SumCategory

R310 ORDERS 5 1 6WGSREQ 3 0 3

R316 ORDERS 5 1 6WPUBON 0 0 0WPUUMS 15 1 16

Partners with complete transfer 1Partners with incomplete transfer 1Total partners 2

.

.

.

Partner number Type Message TypeR152 KU ORDERS

WPUBONWPUUMS

Partner number Type Message TypeR152 KU ORDERS

WPUBONWPUUMS

EDI partner profile: inboundEDI partner profile: inbound

Partner number Type Message TypeR316 KU ORDERSR316 KU WPUBONR316 KU WPUUMS

EDI partner profile: inboundStoreStore

MMM

MMMStoreStore

MMM

MMMR317

R316

POS Monitor: Communication Completeness

The sales auditor uses the POS monitor to ensure all stores have completed their inbound

communication.

Report variants limits the display to the messages and/or stores you are over seeing.

Using this tool makes it easy to determine if a store’s sales data has been received at headquarters in

a timely fashion. Also, an overview of errors directs the sales auditor to the location of IDocs in error

so that they can be corrected and posted to the proper accounts.





SAP AG 2001


Mass change Change status Process

Find

TranType

Term

PMeth

Status Reason

Sto.. S R.. Tra.. Pmet Total Cashier POS.. Date Time

Only display hits

Correct and Reprocess Errors

If on examination, the sales auditor finds errors, she can quickly correct and reprocess them using the

SAP Retail sales audit editing tool.

When all IDocs are posted, SAP BW can be evaluated for further information.





SAP AG 2001

Describe the Sales Audit Processing steps

Explain which R/3 applications are affected

by Sales Audit

Describe the Communication and

Information Structures

Perform the tasks of a Sales Auditor

You are now able to:

SAP AG

Sales Audit Processing: Unit Summary





SAP AG 2001

Archiving POS Documents

Reorganizing Status files

Reorganizing Change Pointer files

SAP AG

Contents:

Unit: Performance Issues





SAP AG 1999


Describe the reason for archiving POS created

objects

Create a variant and run the archiving

programs

Describe the reason behind change pointer

reorganization

Perform change pointer reorganization

SAP AG

Objectives





SAP AG 2001


Unit 8 Conclusion






Unit 1 Introduction

Course Overview





SAP AG 1999

You have gone live on SAP Retail and you havebeen communicating among headquarters and

stores for a week.

Now it is time to implement the performance

measures that you have been planningsince the

beginning of the project.

Main Business Scenario





SAP AG 2001

SAP Retail

DatabaseArchiving

Object

Archive

Files

Archiving POS Documents

The IDocs in the SAP Retail database are not deleted automatically after data transfer. As notedearlier, the communication IDoc is deleted once it has been transferred to the database. Outbound

IDoc files are deleted by the converter, once they are transferred to the converters database; and

Inbound IDoc files are deleted by R/3 once they are transferred to the R/3 database.

When a report is run that accesses the database, it will go through each IDoc to determine if it

requires processing, thus slowing the process. To minimize the time, SAP recommends that databaseitems created as a result of POS transfers be archived on a regular schedule, as noted in the

following slide.





SAP AG 1999

Object and Description IDOC - Fully processed IDocs

WORKITEM - Completed workitems

SD_VBRK - Billing documents

MM_MATBEL - Inventory documents

FI_DOCUMNT - Accounting

documents

When Older than 1 week

Older than 1 week

Older than 1 week

Older than 1 week

Older than 1 month

Objects to Archive

In addition to the objects to be archived, the document flow displayed in the POS Monitor must bedeleted using report RSWWWIDE. After this report is run, you can not display which applications

were created during the POS upload.

- Note: this report also deletes the document flow for standard IDocs as well as for POS IDocs.For this reason, SAP recommends that you only delete document flow for uploads that are older

than 3 months.





SAP AG 2001

SAP Retail

Status Docs Change Pointers

Reorganizing Change Pointers

The reorganization function (report RWDPOSSRS) is used to remove all unnecessary POS outboundstatus records, log records and IDocs from the system.

- Note: This report is available through the POS outbound menu.

When RWDPOSSRS is run, it also flags unnecessary change pointers for deletion.

Once the change pointers are flagged, they can be deleted in the ALE layer by running report

RBDCPCLR. Access to this report is through ALE Administration.

SAP recommends that you reorganize change pointers weekly.





SAP AG 2001

SAP Performance Map

SAPNet Alias: performancemarket and performancemap

Released for customers and partners (free of charge)

Central point of access for performance-related topics

Divided up in line with the mySAP.com components (containscore and industry-specific areas, plus cross-component andtechnical blocks)

Gives recommendations and suggestions, detailedinformation, documents and links, and a direct link to relevantnotes and collective notes in OSS

Continually updated and enhanced

Available in English (some notes and details are translated into

other languages)





SAP AG 1999 SAP AG

SAP Retail provides the transaction SARA, thearchiving tool, to make archiving a simple task.

Through SARA one can archiveIDocs, Billing

documents, Accounting Documents and most other

documents created via POS Inbound processing.

SAP Retail also provides several reports that delete

unnecessary workitems and error messages.

The change pointer reorganization report is provided

to remove already processed change pointers. All these tools enhance performance.

Summary





SAP AG 2001

You have heard what must be considered in

planning communication betweenheadquarters and stores. You have heard the transmission options

supported by SAP Retail. You have heard what business information can

be transmitted via the SAP Retail POSinterface.

You have successfully completed two casestudies customizing and testing the POSInterface and related areas.

You have reviewed the data that you created in

the Information System.

SAP AG

Unit: Conclusion





SAP AG 2001


Unit 8 Conclusion






Unit 1 Introduction

Course Overview





SAP AG 2001

Project

Start Go Live

Reminder !!

St r ess

T est s

E v a l u

a t e

Te s t

C o n f i g

u r e

E v a l u a t e

C o n

s i d e

r

Planning is the key to smooth implementation of your SAP Retail communication project.

First, consider and engage a certified communication interface partner or begin creating your own

interface.

Evaluate your data requirements, profile requirements, messages to send and receive, and your

reporting needs.

Then, configure SAP Retail.

Test the outbound messages and evaluate the preliminary results.

Simulate the inbound messages and evaluate the results.

Repeat as necessary, until you have your desired results.

Test data transmission through the converter both ways.

Test using CATT tool to generate large quantities of data.





SAP AG 2001

IntelligentPOSSystem


Simple POSSystem

StoreStore

MMM

MMM

Sales

Finance

Master Data

Purchasing

MerchandiseManagement

A r t i c l e, P

r i c e,

EA N / U P C

StoreStore

MMM

MMM

MerchandiseManagementSystem

Article, Price, EAN/UPC,Customer, Taxes

Article, Price, EAN/UPC,Customer, Vendors,...

S a l e s $

Sales $ and Q,Articles, Customers

Sales $ and Q, Articles,Customers, Inventory count...

What Is YOUR Scenario?

StoreStore

MMM

MMM

HumanResources

How do you do business today?

How will you do business going forward?

It is up to you to decide!





SAP AG 2001

SAP Best Practices for Retail ...

...Offer you "Best Practice" configuration of mySAP.comRetail in a number of versions for the following sectors:

• Fashion (including apparel, textiles, footwear) *

• Food (discounters, supermarkets, hypermarkets, convinience stores) *

• Wholesale (technical wholesale, mail order, Internet) **

• Hardlines (specialists in building materials, electrical items, toys, and

so on) **

...Are an implementation tool combining AcceleratedSAP(ASAP) and Preconfigured Systems (PCS), are free of charge, and can be installed in a day

* already available ** planned





SAP AG 2001

SAP Best Practices for Retail ...

...Provide help in every mySAP.com Retail implementation!

... The preconfigured development client reduces the projectruntime.

... SAP Best Practices for Retail allow early prototyping in theimplementation, which reduces problems later thanks to a system-based discussion in the Blueprint Workshops.

... They contain detailed documentation of the preconfiguredprocesses including full integration with AcceleratedSAP.

...They enable you to set up a pared-down, functioning system in ashort period of time and test live operations.





SAP AG 1999

Implementing Headquarter-Store communicationis an iterative process with many variables -- youhave been through many iterations in this course.

You are ready to begin planning for your POSInterface implementation.

SAP AG

Summary





Frequently-used Menu Paths

Activity Menu Path

Technical Aspects of POS:

View IDoc documentation Tools Business Communication, IDoc

IDoc Basis Documentation double-click IDoc types

Check the Logical System

nameTools AcceleratedSAP Customizing

double-click Edit. Project SAP

Reference IMG

Basis Components Distribution (ALE)

Sending and Receiving Systems

Logical systems Define Logical system

Check the Logical System

client assignmentTools AcceleratedSAP Customizing


Reference IMG Basis Components Distribution (ALE)


Logical systems Assign Client to

Logical system

Create an EDI port

through IMGTools AcceleratedSAP Customizing


Reference IMG



Systems in Network Asynchronous Processing Assigning ports Define

port

Create an EDI port

through SAP Easy AccessTools Business communication, IDoc

double-click Port Definition

Create an EDI Partner Profile

through IMGTools AcceleratedSAP Customizing


Reference IMG


Modeling and Implementing Business

Processes Partner Profiles and Timeof Processing Maintain Partner Profile

Manually

Create an EDI Partner Profile

through SAP Easy AccessTools Business communication, IDoc

double-click Partner Profile





Activity Menu Path

Creating a Conversion Category:

Define the Conversion

Category NameTools AcceleratedSAP Customizing

double-click Edit Project(SPRO) SAP

Reference IMG Sales and Distribution POS Interface

Adjustments Conversions


Select parameters to convert Tools AcceleratedSAP Customizing


Reference IMG

Sales and Distribution POS Interface

Adjustments Conversions

Conversion parameters.

Define parameter pairs Tools AcceleratedSAP Customizing


Reference IMG


Adjustments Conversions Select

each type of conversion necessary

Activity Menu Path

Simple POS System Case Study:

Check if Change Message isactive

Tools AcceleratedSAP Customizing


Reference IMG


Modelling and Implementing Business

Processes Master Data Distribution

Replication of Modified Data Activate

Change Pointers (Generally)

Check if a particular message

type is activeTools AcceleratedSAP Customizing


Reference IMG


Modelling and Implementing Business

Processes Master Data Distribution

Replication of Modified Data Activate

Change Pointers for Message Types

Maintain a Condition Type

GroupTools AcceleratedSAP Customizing


Reference IMG





Activity Menu Path


Outbound Maintain condition type

group

Maintain a POS Outbound

ProfileTools AcceleratedSAP Customizing


Reference IMG


Outbound Maintain Profile for

POS Outbound

Assign Profile to Site Logistics Retailing Master Data

Site Data Site double-click Change,

select POS tab

Initialize Outbound Messages Logistics Retailing Distributed.

Retailing POS Interface Outbound

POS data double-click Initialization

Verify success of

initialization IDoc Status POS Monitor

View POS Directory Transaction code AL11

Create an inbound profile Tools AcceleratedSAP Customizing


Reference IMG


Inbound Maintain profile for POS

inbound

Assign profile to site Logistics Retailing Master Data


select POS tab

Configure Goods Movement

ControlsTools AcceleratedSAP Customizing


Reference IMG


Inbound Movement type-


Configure Sales as per

Receipt ControlsTools AcceleratedSAP Customizing


Reference IMG


Inbound Control sales as per

receipts

Define Sales as per Receipt

transaction typeTools AcceleratedSAP Customizing


Reference IMG





Activity Menu Path


Inbound Transaction types for

sales as per receipts

Configure specific transaction

Sales as per ReceiptTools AcceleratedSAP Customizing


Reference IMG


Inbound Transaction type-

dependent control of sales as per receipts

Simulate Sales as per Receipt

inbound data Logistics Retailing Distributed.

retailing POS interface Extras

Simulation double-click Sales, select

Sales as per recpts

Verify IDoc through

simulation tool IDoc Status POS Monitor

POS Monitor

through SAP Easy Access Logistics Retailing Distributed.

Retailing POS Interface Monitor

double-click POS interface

Display article documents Logistics Retailing Merchandise.

logistics Inventory management


Display billing documents Logistics Retailing Sales Billing

Billing document double-click Display

Display G/L account

document

Accounting Financial accounting

General ledger Document double-click Display/change line items

Display open line items in a

customer account Accounting Financial accounting

Accounts receivable Account double-

click Display line items

Simulate Cashier Statistics Logistics Retailing Distributed.



View Sales Audit Reports Logistics Retailing Info

system/Planning Retailing

Standard analyses Special processes Sales audit double-click Cashier/POS

Balancing/Sales

View Sales Audit Reports

through POS area Logistics Retailing Distributed.

Retailing POS Interface

Environment Sales Audit double –click

Loss prevention/ POS Balancing / Sales





Activity Menu Path

Merchandise Management System Case Study:

Check Port definition Tools Business communication, IDoc

double-click Port Definition

Maintain EDI Partner Profile Tools Business communication


Create Assortment List



Reference IMG

Logistics - General Assortment

Assortment List Maintain profile for

assortment lists

Assign Profile to site Logistics Retailing Master Data

Site Data Site double-click Change.

Initialize Assortment List Logistics Retailing Master Data

Assortment/Listing Assortment List

Generate double-click Initialization

Verify success of

initialization Logistics Retailing Distributed.

Retailing POS Interface Monitor

double-click POS interface

Create a Reduced Message

TypeTools AcceleratedSAP Customizing


Reference IMG


Modeling and Implementing Business Processes Master Data Distribution

Scope of Data for Distribution

Message Reduction Create Reduced

Message Type

Create an Inbound POS



Reference IMG


Inbound Maintain profile for POS

inbound

Maintain profile for POS

inbound

Assign POS Profile to Site Logistics Retailing Master Data


select POS tab

Maintain EDI Partner Profile Tools Business communication


Maintain POS Store Physical

Inventory controlsTools AcceleratedSAP Customizing






Activity Menu Path Reference IMG


Inbound→ Store phys. inventory

control

View Inventory Logistics Retailing , Merchandise.

logistics Inventory management,

Environment Stock double-click Stock

overview

Simulate Store Physical

Inventory Count Logistics Retailing Distributed.


Simulation double-click Store physical

inventory

View Inventory Logistics Retailing Info

System/Planning Retailing

Standard Analyses Article double-click

Article

Post Inventory differences Logistics Retailing Merchandise

logistics Physical

inventory

Difference double-click Post

Maintain POS EAN/UPC

change controlsTools AcceleratedSAP Customizing


Reference IMG


Inbound→ Automatic EAN/UPC

Creation Control

Simulate an Article Master

change Logistics Retailing Distributed.


Simulation double-click Master data

Maintain POS Store Order

controlsTools AcceleratedSAP Customizing


Reference IMG


Inbound→ Store order control

Simulate a Store Order Logistics Retailing Distributed.

retailing POS interface Extras Simulation double-click Store order

View a Purchase Order Logistics Retailing Purchasing

Purchase order Purchase order double-

click Display

Maintain POS Goods

Movement processing controlTools AcceleratedSAP Customizing


Reference IMG






Activity Menu Path Inbound→ POS Goods Movement

control

Maintain POS Movement

type-dependent Goods

Movement control

Tools AcceleratedSAP Customizing


Reference IMG


Inbound→ Movement type-


Simulate Goods movement

data Logistics Retailing Distributed.


Simulation double-click Goods

movements

Create Financial Transaction

typesTools AcceleratedSAP Customizing


Reference IMG


Inbound→ Transaction types for

financial transactions

Maintain POS FI Transaction

type-dependent controlsTools AcceleratedSAP Customizing


Reference IMG


Inbound→ Transaction type-

dependent control of financial transactions

Simulate inbound Financial

Transaction data Logistics Retailing Distributed

Retailing POS interface Extras

Simulation double-click Financial

Transactions

View General Ledger

documents Accounting Financial accounting

General ledger Document double-click

Display

Maintain POS Aggregated

Sales controlsTools AcceleratedSAP Customizing


Reference IMG


Inbound→ Aggregated sales control

Maintain POS Payment List

controlsTools AcceleratedSAP Customizing


Reference IMG


Inbound→ Payment list control

Simulate Aggregated Sales

data Logistics Retailing Distributed





Activity Menu Path Simulation double-click Sales, select

Aggregated Sales

Simulate Payment List data Logistics Retailing Distributed


Simulation double-click Sales, select

SAP_IS_Retail_IRT360_46C_NW

Documents

Transcript of SAP_IS_Retail_IRT360_46C_NW