IRT260 4.0 Instructor's Guide

100 

Loading.... (view fulltext now)

Loading....

Loading....

Loading....

Loading....

Full text

(1)

R/3 System

Instructor

Guide

Level 03

Barbara Peatie

Horst Gerlach

IRT260- Retail Store Connection

Release 4.0

October 1998

(2)

Contents Page:

SAP Contact(s)...3

Walldorf – Horst Gerlach... 3

Subsidiaries – Barbara Peatie...3

Revisions To Previous Instructor Guide...3

Course Details...4

Duration... 4

Three Days... 4

Course Materials and other Materials (Training Manual)...4

Country-Specific Units... 4

Course Instructor Profiles...5

Level of Knowledge Required... 5

Courses Recommended as Preparation...5

Online Help Recommended as Preparation...5

Hints on Preparing This Course... 5

Training System IRT client 800...6

Data Required- Sites... 6

User ID and Passwords for Course Participants...6

Preparation in the System... 6

Example ABAPs... 6

CATTs... 6

Technical Hints... 6

Goals and Objectives...7

Course Structure and Flow...7

Course Schedule...8

Course Schedule:... 8

Day One... 8

Unit: Introduction...10

Topic: The Relationships... 13

Topic: ALE, EDI, and POS...Error! Bookmark not defined. Topic: Technical Documentation... 16

(3)

SAP Contact(s)

Walldorf – Horst Gerlach Subsidiaries – Barbara Peatie

(4)

Course Details

Duration Three Days

Course Materials and other Materials (Training Manual) Country-Specific Units

(5)

Course Instructor Profiles

Level of Knowledge Required

Ideally, the instructor will have experience in the retail industry, good R/3 knowledge, and strong SAP Retail knowledge and POS system understanding. The course covers retail communications but touches on MM/SD, ALE, and EDI communications. Accounting and Calculation schema’s are discussed are is workflow briefly as a function of Inbound POS processing.

Courses Recommended as Preparation

 IRT110 and IRT120 provide information on the Retail MM/SD functionality.  IRT250 provides information on the Retail configuration.

 CA210 is an excellent source of EDI information.

 CA910, although primarily ALE for distributed systems, provides ALE exposure.  BC600 provides an introduction to Workflow.

Online Help Recommended as Preparation IMG documentation for POS, ALE, and EDI. POS system documentation and F1 help. Hints on Preparing This Course

Run through the exercises as outlined for the students and also through the demo’s in this guide.

Warning: The demonstrations must be performed in order. Each succeeding step is predicated on the prior configuration being completed.

(6)

Training System IRT client 800, 801, 802, 803, 804

Data Required-

Company Code

R300

Sales Org

R300

Distribution Chnl

R1

Division

R1

Purchasing Org.

R300

Sites

R316 and TS##

Article

R100016

R100005

R100000

Customers

R3001, R3001

Vendor

R3001, R3002

Controlling Area

R300

Cost Center

R3110_001

Cost Element

410050

User ID and Passwords for Course Participants

Use transaction ZUSERS to create users IRT260-01 through IRT260-nn password init. Copy IRT260 to create with the proper authorizations. Save them locked until you are ready for class.

Use transaction PPOM and org structure 50012897. Drill down (Zentr. Org., Logistik/EDV) Assign holders (IRT260-01—nn)

Preparation in the System

Unlock users and run ZENQUEOFF Example ABAPs

CATTs

(7)

Goals and Objectives

Give participants the ability to configure the communications environment to use SAP Retail POS communication functionality.

(8)

Course Schedule

Course Schedule: Day One

Approximate Times

Content: Units and Topics Activities: Instructor and Participant 20 minutes House Keeping and Introductions Participants describe their experience level

and expectations of the course.

20 minutes Introduction 40,000 foot view into all of POS including

60 minutes Technical Grounding Lecture and exercises

15 minutes Break

6 hours Headquarters to store (Outbound processes)

Lecture, Demo and Exercises Day 2

30 minutes Review Day 1 Answer any questions and highlight the

important points of Day 1 60 minutes Headquarters to Store (Assortment

List)

Lecture, Demo and Exercises 15 minutes break

30 minutes Inbound Overview Lecture and Demo

60 minutes Store Physical Inventory Lecture, Demo and Exercises

60 minutes Lunch Lecture, Demo and Exercises

60 minutes Article Master Data Changes Lecture, Demo and Exercises 60 minutes Financial Transactions Lecture, Demo and Exercises

60 minutes Cashier Statistics Lecture, Demo and Exercises

60 minutes Store Orders Lecture, Demo and Exercises

60 minutes Goods Movement Lecture, Demo and Exercises

Day 3

30 minutes Review of Day 2 Answer any questions and highlight the important points of Day 2

60 minutes Sales – Aggregated Lecture, Demo and Exercises

Break

60 minutes Sales – as per receipts Lecture, Demo and Exercises

60 minutes Review Cashier Statistics Review Cashier Statistics now that the participants have generated transactions. Lunch

(9)

30 minutes Background Processes Overview Lecture and Demo

30 minutes Performance Enhancers Lecture and Demo

15 minutes Summary Lecture

(10)

Unit: Introduction

20 minutes

List of Topics in the Unit Main Business Scenario Project Plan

Communication Scenarios Overview of Messages Putting the Unit in Context

This is a high level overview of a POS implementation project. Discuss the two options for hardware configuration. These do not impact the rest of the class but lay the groundwork for how we structure the flow of information

Objectives

Identify the areas that must be considered Explain the transmission options

Explain the transmission messages

Main Business Scenario

Setting up a POS project team. Other teams in the company are working to

customize other functional areas. POS crosses functional modules so how the others configure the MM, SD, and FI areas will impact the POS team. Also, testing the POS functions will test the completeness of the configuration and master data in MM, SD, and FI.

We will use a general merchant as our example because that provides a view to the breadth of Retail functionality. We have multiple stores in 3 western US states that have two point-of-sale systems operating in the stores. The smaller stores have POS servers and the larger ones have a foreign merchandise management system serving their POS terminals.

Replenishment planning is run for all stores and promotions for selected articles are run most weekends.

Although you have a company credit card, you also have a policy of accepting other major credit cards as well as cash and checks.

(11)

Project Plan

There are essentially four phases to a successful implementation:

Consider the size of your organization, where your stores are located, and the kind of data headquarters requires from the stores. Discuss with other functional teams the data requirements and their goals.

Note that the phases are not necessarily discrete steps that rigidly follow one another, and that during the course, as will be true during an implementation, we will step through all phases in small increments before we have the entire process together. Evaluate which tools you are going to use to achieve the teams goals.

Configure the system to reflect the decisions made in phase 1 and phase 2. Test that the configuration performs as they expected.

Considerations

Discuss in some detail what they must consider at the project outset.

The items that we consider up front must be kept in mind as we go through the other three steps. Throughout the course we will be evaluating, customizing, and testing. Transmission Options (1/2)

Schematic showing the modes of connection to the store. Emphasize that an external converter is recommended. Two companies have certified interfaces, Siemons-Nixdorf and IBM.

Transmission Options (2/2)

A second option is available. That is using the distributed mode where servers are physically in different locations and some modules run in these locations. Using multiple servers, reduces the number of records processed by any one system at any one time. We are just mentioning this option but will not discussed it in any detail. Although we have listed some items to consider, if you are considering this option. See CA910, the Application Link Enabling course.

Outbound

The slide shows the types of information that the POS interface handles. The information and message types are discussed in detail in a later unit and are presented as an overview.

Inbound

The slide shows the type of information that the POS interface can receive. Each type is discussed in detail when we discuss the Inbound processes. and are presented as an overview.

(12)

Scenarios

As a last consideration, you will want to consider where the center of control lies in your company and the types of POS systems that you have in the stores. As the slide shows in stores where you have very simple POS sytems you might only send an article message with pricing and the main UPC number. This would provide enough information for the POS server to capture sales and send them back to headquarters. As systems become more intelligent and have more memory, messages can become more complex, as the slide shows.

Both control and POS systems will impact the types of messages you use and how often data is transferred.

For example: If you will be performing auto-replenishment at headquarters, you must receive detailed sales data and the store must have accurate article data to provide the sales at the register.

If stores maintain their own inventory, regular sales volume and store orders inbound might fulfill corporate reporting requirements and periodic inventory counts to sub-stantiate the inventory.

Summary

The slide shows the type of information that the POS interface can receive. Each type is discussed in detail when we discuss the Inbound processes. and are presented as an overview.

(13)

45 minutes

List of Topics in the Unit Profiles

Application Link Enabling Electronic Data Interchange Intermediate Documents POS Monitor

Putting the Unit in Context

We put aside the business aspects of the POS course for a short while and discuss some of the underlying system functionality provided in SAP Retail necessary for using the POS interface. We will be using these parts of the system as we go through the remaining units and will come back to these areas several times throughout the course.

Objectives

Describe the use of profiles to populate data

Explain the relationship among ALE, EDI, POS, and IDocs Describe the role of the ALE layer

Explain the IDoc documentation and structure provided in the system Describe the POS monitor as a tool for interfacing with the IDocs. Topic: The Relationships

Putting the Topic in Context

No matter where we start there is always some piece of information that you might have had earlier. No matter where we start you might feel, “I wish I knew that sooner.” While I think we have started at the right point, this feeling might hold true throughout today. I will ask you to be patient and write down your questions as they come up, at the end of the day I will ask you for those questions that were not answered and will spend a few minutes discussing them before we leave for the day.

This topic covers some of the underlying functionality that you will need to comprehend the later sections.

Topic Objectives

Identify all the pieces of the configuration puzzle that make up POS communications.

(14)

Where do I start?

Just a little swipe at the use of acronyms and at the outset it probably sounds like just a bowl of alphabet soup. The definitions on the notes pages are what is important in this slide.

Describe the definitions.

How it all ties together

This should be a build slide that begins with just the Site Master. Although we won’t populate these fields until last, it is important to know what we are building up to. You should all be familiar with the Site Master and the Customer number of the site master. Are you?

How it all ties together 2

Add EDI Partner Profile that is unique to each site and/or customer. This is the key to moving the IDoc messages in and out of the system. It is linked to the site by way of the site customer number. We are going to discuss this briefly now and again in more detail when we come to the inbound and outbound sections of the course.

How it all ties together 3

Add ALE config. This is the key to moving the data to and from the application areas. We’ll cover this topic next.

How it all ties together 4

Add POS outbound profile. This packages the data appropriately and allows it to be sent to particular stores. The link is through the POS Outbound profile name entered into the site master and the customer number assigned to message types in EDI partner profile. Outbound profiles will be discussed at length later today. How it all ties together 5

Add POS inbound Profile. This is the key to packaging the inbound data and allow it to be handled by the system. The link is through the POS Inbound profile name entered into the site master and the customer number assigned to message types in EDI partner profile. Inbound profiles will be discussed at length beginning tomorrow.

(15)

How it all ties together 6

Add the POS inbound Detail Profiles. At the detail level, each inbound profile “tells” the system what kind of data to expect and how to deal with it. The inbound profile details will also be discussed at length.

How it all ties together 7

Add Calc schema. This is another piece of the link that we touch on but do not discuss in detail. It is a subject of a three day Pricing course and one with which other members of your team will deal. However, I bring it up to remind you that when you get to testing, the calculation schema is critical to getting transactions to post.

How it all ties together 8

Add Assortment list profile. The assortment list profile is the way we handle this special message type. This is covered in detail after outbound profiles.

How it all ties together 9

Now we are back where we started with the focus on Sites with all the links to the profiles that will drive the data down and back from the stores with minimal input from an operator.

Topic Objective

ALE and EDI work together to deliver data out to the POS systems and in to R/3. Explain how the two work together to move data to and from the application to the converter.

Information Flow in POS Outbound

The Application Link Enabling function of R/3 moves the data from the application area. The slide shows generally: folks working in the application areas make changes to master data, for example in a live system, a merchandise manager decides to mark-down a group of articles and does so in the system.

The ALE layer creates a change pointer and a master IDoc that the POS interface converts to communication IDoc and tags it with the appropriate sites. Then the EDI interface passes the IDocs to the assigned port. After the IDoc is created, ALE places the location of the IDoc file in the status file. When the report is started, a message is sent to the converter/communication interface. The communication interface goes to the status file, finds the location of the files and downloads the data to the store.

(16)

Information Flow in POS Inbound

This will be covered in greater detail in the Inbound section of the class. It is sufficient to say at this point, that the data takes the reverse path into the system.

Topic: Technical Documentation Putting the Topic in Context

Discussion of IDocs as the carrier of business data, how they are structured and what data they carry. Where to go to display the technical documentation.

Technical Documentation Objectives Explain the concept and structure of IDocs

Describe the database tables that store the components of individual IDocs Describe the classification of IDocs in terms of IDoc types

Describe and show how to use the online IDoc documentation to determine the contents of an IDoc.

IDocs and IDoc Types

SAP provides over 100 basic IDoc types or structure into which the system places data. The POS interface uses 25 retail specific IDoc types and provides a facility for attaching customer data to the IDoc types .

IDocs: Components

Each IDoc is made up of 1 Control record, at least one, but more likely, many data records.

Inbound IDoc segments that are processed together are called a range and each range has a POS status describing the result of inbound processing, and determining if further processing may be required. The POS status is different from the EDI status. The EDI status is assigned to the entire IDoc.

It also contains one or more IDoc status records that document the life cycle of the whole IDoc.

The components are identified by a numerical key, the IDoc number and the client number through which all the records belonging to one IDoc are linked in the database.

IDocs: Control Record See notes.

(17)

IDocs: IDoc Types vs Message Type See notes. Also,

Syntax means the systematic arrangement of the data Semantic means the contextual meaning

IDocs: Data Records See notes.

IDocs: Data Record Structure See notes.

IDocs: Data Record Structure – Example (1/2) and (2/2) See notes.

IDocs: EDI Status Record See notes.

IDocs: EDI Status vs. POS Status See notes.

Break

10 minutes

Demonstration of IDoc Documentation 20 minutes

Tools  Administration, Administration  Process Technology  IDocs Basis, Documentation  IDoc Types (WE60). Enter WP_PLU02 press Display Tree. Show the structure and the expansion to see segments. Back out

(18)

WARNING: The following is only possible if you are able to save files locally on the trainer’s PC and to retrieve them, e.g. through the Windows NT Explorer using a (basic) text editor!

Show the html documentation. Press Html, enter c:\ in Local directory and some other name in Basis name for HTML files with no extension. Go to Windows NT Explorer then double click on the _F.htm file and the browser will start. Show the three views.

Now show the C header info. Press C header, enter c:\ in Local directory and a name in the local file w/o extension field. Go to Windows NT Explorer and double click on that file. Associate it with Notepad and display the “Automatic Data Declaration” which is the C format of the IDoc.

Demonstration of the Database Files 15 minutes

Tools  ABAP Workbench  Dictionary (SE11) In the Object field, Enter:

EDIDC and press Display to access the Control record table. EDID4 and press Display to access the Data table

EDIDS and press Display to access the Status record table Back out. Go to Overview  Data Browser (SE16)

Enter EDID4 in the table name to view the data within the table. Exercise: IDoc Types

15 minutes 1-1, 1-2

Topic: IDoc Monitoring Putting the Topic in Context

Introducing the POS Monitor. It documents the communication between the system and the converter at a finer level than does the EDI or ALE monitors.

IDoc Monitoring: Objectives

Explain how the POS Monitor documents communication between SAP Retail and point of sale systems.

(19)

POS Monitor: Embedding into POS interface

The POS interface is made up of an Inbound processing unit, an outbound processing unit, and the POS monitor.

POS Monitor: Functional Scope See notes.

POS Monitor: Selection Criteria See notes.

POS Monitor: Tree Structure See notes.

POS Monitor: Functions Relating to Outbound See notes.

POS Monitor: Functions Relating to Inbound See notes.

POS Monitor: Communication Completeness See notes.

Demonstration of POS Monitor 15 minutes

Follow Distr. Retailing  POS Interface, select ‘Monitor POS interf.’, blank out Creation time (from), and enter Customer = R311. Select Execute. On the next screen select ‘Expand subtree’, to expand POS Monitor tree.

You will note that there are (store order) IDocs found. One successful and one unsuccessful.

(20)

Display this IDoc (double-click) with its three components, as well as the follow-on document (= purchase order; double-click).

Select ‘Complete area’ to call upon inbound completeness check, using Partner number = R311; select ‘Execute’ and explain/interpret result of completeness check. Exercise: POS Monitor

15 minutes 2-1, 2-2

(21)

360 minutes

List of Topics in the Unit Outbound IDoc/message types

EDI partner profile for outbound processing Condition type groups

Conversion categories POS outbound profile POS outbound reports Putting the Unit in Context

Master data is required at the electronic cash register if sales data is to be recorded accurately and with detail. Outbound POS transmission of master data is the efficient way to get master data to the stores. For the process to work “automatically” and smoothly, several profiles must be created first for Outbound messages to be transferred seamlessly.

Objectives

Describe the type of business information carried by outbound messages Deliver information that allows the students to understand and:

Customize EDI Ports

Customize EDI Outbound partner profiles

Customize Condition Type groups for an implementation Customize Conversion category for an implementation Customize Conversion parameters for an implementation Customize POS Outbound profile for an implementation Topic: Outbound Messages

Putting the Topic in Context

First we will discuss the types of messages to carry the data out to the stores and go through each of the outbound IDoc message types. Then we will step through all the areas of configuration and set up my demo store to carry outbound messages. We will test sending a message, then you will get to do the same process for your own site.

(22)

Topic Objectives

Describe the Outbound messages to understand which one (s) you might want to use and why you might want to use them. Also, which ones you might want to combine for different stores.

POS Outbound: Business scenario

The flow of data was discussed in the Technical Grounding unit. On a more general level, this slide depicts how the system handles the entire process of capturing master data changes and downloading them to the stores.

In this unit we are concerned with the business uses of outbound data.

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 must complete successfully(status: Preparation OK) before change messages can be created.

After initialization is complete, whenever a user maintains master data, (such as changing a price, adding a new article) the application creates a change 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

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. As we discuss the message types, you will want to keep in mind our business scenario, as the message types we use will impact how we proceed:

We are a general merchant with stores in 3 western US states using 2 different POS systems. Automatic replenishment planning is in place for all stores and we run promotions for selected articles on weekends.

We do have an in-store credit card and also accept other major credit cards as well as cash and checks.

Types of outbound business data

Each of the message types is discussed in this unit as is the customizing that is necessary to ensure the smooth flow of information to the stores.

List of the business data, IDoc type and Message type. We will look at the IDoc types one at a time.

(23)

Outbound Processing: Data Flow

The slide shows that the user intervenes in only two operations, the rest the system handles automatically.

See notes for the process.

Inbound and Outbound Material and Condition IDoc

WP_PLU02, WP_PLU

The basic article data can be carried to the stores using message type WP_PLU. WP_PLU02 IDoc type is shown with all its segments. As was explained each segment has a number of fields.

WP_PLU01 is still available in the system but it is supported only for the simplest of POS systems that were supported for release 1.2.

Critical piece of information: The only message that carries Rebate in kind data is WP-PLU02, so if you do this kind of promotion you must use this IDoc and message type.

View the WP_PLU02 IDoc on line <5 minutes>

Rather than look at this IDoc on slides, lets look at it on-line.

Tools  Administration  Administration  Process Technology  IDoc  IDoc Basis  Documentation IDoc Types. Enter WP_PLU02, press Display Tree E1WPA01, The Inbound and Outbound Identification segment is the only mandatory segment. An IDoc can contain 1 up to 9,999,999 ID segments. It contains the following fields: Site Change indicator Change category Activation date Date changed

Employee number of the person who changed the article master record Main EAN/UPC number

Internal article number Unit of measure

E1WPA02, the Inbound and Outbound article master data is optional and only 1 record. It contains the following fields:

Merchandise category Packaging weight Scales group

(24)

Flag: Price must be entered Flag: Sales block

Flag: Discounts allowed Flag: Article for weighing Flag: Price includes sales tax Flag: Price autonomy of store Flag: Print price

Flag: Display article

Minimum remaining shelf life Total shelf life in days

POS interface: count request for articles.

E1WPA03, the Inbound and Outbound article master text data is optional and an IDoc can contain 1 to 99 segments. It contains the following fields:

Qualifier text Language code Text field

E1WPA04, the Outbound Article conditions data is optional and can contain 1 to 99 segments. It contains the following fields:

Type of condition/discount Promotion number

Condition valid from

Time of price activation (not active as yet) End of price validity

Time of price deactivation

Free for use (customer enhancement field)

E1WPA05, Outbound article condition values data is optional can contain 1-99 segments. It contains the following fields:

+/- sign of condition

Condition rate, percentage conditions Amount

Quantity Currency key

E1WPA11, Outbound Condition scales data is optional and can contain 1-99 segments. It contains the following fields:

Scale basis indicator +/- sign of condition

Condition rate, percentage conditions Amount

Quantity Amount

The only message that carries Rebate in kind data is WP-PLU02, so if you do this kind of promotions you must use this IDoc and message type.

E1WPA09, the Outbound free goods data is optional and can contain 1-99 segments. It contains the following fields:

Type of condition/discount Condition valid from End of price validity

(25)

Free goods: Indicator for on-top / inclusive

E1WPA10, Outbound article free goods scale data is optional can contain 1-99 segments. It contains the following fields:

Minimum free goods quantity Free Goods quantity

Internal number of the discounted article Main EAN/UPC discounted article Additional quantity for free goods Unit of measure

Calculation type for determining free goods quantity

E1WPA07, the Inbound and Outbound article master tax data is optional and can contain 1-99 segments. It contains the following fields:

Tax code

E1WPA08, the Inbound and Outbound additional article number data is optional and can contain 1-99 segments. It contains the following fields:

Qualifier article number Article

E1WXX01, a customer enhancement segment that can contain 1 to 999 segments. Inbound and Outbound EAN/UPC Assignments

WP_EAN01 WP_EAN

If you had articles that were sold under more than one UPC code, you would activate the WP_EAN message type as well as the Article master message. For example, if you sold apparel and changed UPC codes for store brand t-shirts from different manufacturers you might want to use this IDoc type

You must activate both WP_EAN and WP_PLU message types and configure the store profile for both message types as well.

Outbound Exchange Rates

WPDCUR01 WPDCUR

You would use this IDoc if you had international stores that do business in different local currencies from the company code currency and you require translation at the store level. Change pointer analysis is not performed so there is no need to activate the message type but you must configure the store EDI Partner profile.

No change pointer analysis This messagemust be scheduled or activated manually

Outbound Follow-on items

WPDNAC01 WPDNAC

You would use this message type if you carry returnable beverage bottles or other returnable items attached to an article.

If you are using this message type you must activate both WP_PLU, which activates change pointer analysis, and WPDNAC to send the IDoc.

(26)

Outbound Merchandise Categories WPDWGR01 WPDWGR

This might be used by a company that maintained their inventory on a value only basis and therefore did not require article data at the store with the detail of WP_PLU. Also some older POS systems can not handle recording on the article level and must use the Merchandise Category message type

Outbound Taxes

WPDTAX01 WPDTAX

This is another message that must be set up and sent because it is assumed to be something that changes only periodically.

No change pointer analysis This messagemust be scheduled or activated manually

Outbound Set Assignments

WPDSET WPDSET

Use this IDoc if you sell individual items together as a set also.

Outbound Additionals

WTADDI01 WTADDI

Additionals are labels, hangers and the like that are attached to an article.

Outbound Person Data IDoc

WP_PER01 WP_PER

WP_PER is being handled as a special case as we can reduce the IDoc in the ALE layer. We will discuss it in detail because it does have performance implications. This shows the major IDoc segments.

Our scenario is that we have-store cards and we want to supply the POS with customer data.

Demonstration of Reducing the WP_PER01 IDoc <5 minutes>

Tools  Business Engineer Customizing  Implementation Projects  SAP reference IMG (SPRO)

(27)

Activate Change Pointers: Customizing

We begin by activating change pointers generally. That is what turns on the ALE functionality. Then we go to the screen similar to this for activating the message types.

There is not a one-for-one relationship between the message types and change pointer analysis for system performance reasons. Multiple processing of the same change pointer for different message types means that separate change pointers do not have to be created for each message type.

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

WP_PLU WPDSET Set Assignments WPDSET WP_PLU WPDNAC Follow-on items WPDSET WP_PLU WP_PER Customer data WP_PER

WPDTAX Taxes No change pointer analysis WPDCUR Exchange Rates No change pointer analysis

Demonstration of Customizing Change Pointers <5 minutes>

Tools  Business Engineer Customizing  Implementation Projects  SAP reference IMG (SPRO)

Cross-Application Components Distribution (ALE) Master Data Distribution  Activate change pointers Activate change pointers (generally).

Either select or note that this has been selected and so the ALE functionality is turned on. Back out.

Select the next option  Activate change pointers for message types.

Note that all message types are already displayed in this screen. These are all the message types supported by SAP. Our interest is in the POS message types so either page down several times to show the depth of support, or use position to W* to move directly to our message types.

(28)

POS Outbound: Change Analysis

This slide takes us through the process the system goes through to determine which IDocs must be created.

1. Someone in merchandising changes the Selling Price (VKP0) of Generic Article R322228 at the Sales Organization level. The article is a rugby shirt that is a good back to school seller so the price is being increased to $35.00.

2. At the end of the day Report RWDPOSUP, Change message is started. (We will talk more about the reports at the end of this unit.)

3. The system checks for the stores that carry this article, it notes that R316 and R317 carry the shirt in variants 001 and 005.

4. Both stores have a two day lead time which falls within the preparation period. 5. The systems checks for other condition records that might have been created

earlier during this run (access sequence). It finds that store R316 was treated differently because it is located in an upscale neighborhood and another price change to $37.50 was already prepared at the store level. Store R316 is ignored for this price change.

6. Now the system checks and finds that article R322228005 is active in store R317 from 8/16 through the end of the year and creates an IDoc with the price change for transmission.

Break

10 minutes

How it all ties together: customizing

The way we get the system to handle the change analysis is done during

customizing. So lets look again at the links that tie the POS outbound profile to the site and to the other definitions that make communications possible.

Discuss the slide. EDI Port (17 and 18)

EDI provides the main connection with the translator/converter.

The Port customizing identifies the path to the IDocs and status files. It also identifies the movement as an EDI transfer.

The Status directory identifies the location of the trigger pointer files.

Describe the addressing structure that is configured in the EDI Port. The files must be setup by a system admin prior to use. It is important that the directory is the one that the converter expects for outbound. Inbound must be what R/3 expects

(29)

Ports and Profiles (19)

A quick view of the link between port definition and EDI Partner Profile.

Although we are not yet discussing Inbound messages at this point, I want you to note that the only location of the inbound Port for simulation is through the Outbound profile. The converter provides the Port during actual inbound transmissions.

Demonstration of EDI Port 3 minutes

Tools  Business Engineer Customizing  Implementation Projects  SAP reference IMG (SPRO)

Cross-Application Components  Distribution (ALE)  Communication  Manual Maintenance of Partner Profiles  Define Port

Expand File and select POS_TEST. Edit  Copy

Enter SAPIRT for the new name. Click continue. Select SAPIRT and press Change.

*****WARNING****

Use the pswdf05 address ONLY during classes. DO NOT USE it for testing before the class. Clearing this file presents some problems. For testing purposes, USE \\pswdf052\pos\posout\ etc. and attach to this directory using Windows explorer to check your data.

Select Outbound and change the port Directory to:

\\pswdf050\sapmnt\trans\POS\POSout\ Press continue. Select Status and change the port Directory to:

\\ pswdf050\sapmnt\trans\POS\POSstat\ Press continue Press Save and Back out.

EDI Partner Profile – Initial Screen

Partner number use the store Customer number R316. Partner type ‘KU’ for customer

Partner class If you have created a grouping of stores you can enter the code in this field.

Archv. Std. EDI, identifies that contracts and other documents exist.

Partner status Must be active. However, you can create reference profiles and it that case you would use the status T.

Telephony Only used in standard EDI with external customers or vendors. Receiver of Notifications Defaults from predefined PD-Org structure or from the user if no PD-org is defined for that user. All the information is used by the system for Workflow error handling.

(30)

Workcenter, Job, Organization unit, Person, Position, User. Lang(uage) In which a message is to be issued.

receiver for notification specifies whom the system should notify – a particular workcenter, a particular job (defined in PD-Org) etc.

EDI Partner Profile – Outbound Profile

Message type Corresponds to UN/EDIFACT business structure standards, except for POS message types and they are as close as possible.

Message code Not used in Retail, is a further separation of message types and is optional.

Message function Not used in Retail. Has to do with std transmission.

Outbound options Establishes how you wish communication to take place. Receiver port Enter the port filename you defined for POS communications. Transfer IDoc immed. or Collect IDocs Use Collect IDocs for Outbound messages.

Start subsystem or Do not start subsystem Neither one of these is necessary. It was planned to be used but ALE handles it.

Basic IDoc type The SAP parameter that determines, via database table TEDE2, which function module is called to process the data communication. Can be used without additional coding for communication functions that are completed by data from the application.

Extension Customer enhancements to basic IDocs.

syntax check flag determines whether the syntax of the IDocs is checked. If checked, system stops processing if syntax error is incurred. If not, the IDoc is posted but it is flagged as having a syntax error. (You might want to check it while testing in a live system to have the IDoc stopped to determine any error locations, but once errors are corrected, leave this field blank during live processing so that you only deal with problem IDocs.)

Seg. Release in IDoc type is looking for a release version code. The current segment definition is used when this is blank. If the segment definition changes with a new release, the IDoc would also change. With a release number in this field, if a segment definition changes with a new release, the system will use the release definition defined by this release code.

receiver for notification same as prior screen. If you want a different agent for a particular message type, enter that information on the particular message screen.EDI settings Communication settings.

EDI Standard SAP supports E, EDIFACT and X, ANSIX12, use the one that your converter accepts

Message type Optional, you can enter the EDIFACT or ANSIX12 message type that corresponds to the IDoc type you are using.

Version Optional, you can also enter the version is you are using the prior field.

Demonstration of EDI Partner profile 5 minutes

Tools  Business Engineer Customizing  Implementation Projects  SAP reference IMG (SPRO)

(31)

Cross-Application Components  Distribution (ALE)  Communication  Manual Maintenance of Partner Profiles  Maintain partner profile

Enter R316, and KU as partner type. Select Outbound parameters

Message type : IDoc type Receiver Port WP_PLU WP_PLU02 SAPIRT.

Exercise: Create Port and Outbound EDI Partner Profile for their site TS##. 15 minutes

3-1, 3-2

Maintain POS Condition Type group

We must identify to the system the conditions that must be analyzed to download pricing info. The ones we have added to the slide are VKP0, the sales price, VKA0, a promotion price, and UTXJ, the tax condition types.

These are outbound conditions.

Demonstration of POS Condition Type group 5 minutes

Tools  Business Engineer Customizing  Implementation Projects  SAP reference IMG (SPRO)

Sales and Distribution POS Interface  Outbound message processing  Maintain condition type group. Select New Entries.

Type the name US01, and a description. Select Maintain POS cond. type group. Enter the following Condition types:

VKP0, sales price VKA0, a promotion price UTXJ, the tax condition.

These are standard SAP supplied condition types and are the ones that will take prices , promotion prices and taxes down to the stores. These are in the Calculation schema and will be analyzed for changes and downloaded by the outbound messages or the assortment list.

Maintain Conversion Parameters: Customizing

Before we get to this point, we should have a solid understanding of the codes necessary at the point of sale system and how they relate to R/3 codes. What message types we are downloading and uploading. Then we can create one (or

(32)

several) Conversion Category(s) and then go to this customizing screen to identify which parameters we will be converting.

Suggest that for your implementation that you create a matrix for all transaction types, tender types, etc. to link SAP Codes with POS codes.

Detail Conversion : Customizing

For each conversion parameter we selected in the prior step, we must create a set of code pairs to facilitate the conversion. In actuality, the converter does the conversion, this set of screens allows us to maintain the link in one location, the R/3 system. The Condition type codes in the slide are for inbound processing. These are the condition types that pass the sales value of a receipt line to the pricing function in Billing.

Demonstration of POS Conversion Categories group 5 minutes

Tools  Business Engineer Customizing  Implementation Projects  SAP reference IMG (SPRO)

Sales and Distribution POS Interface  Standardized Data  Conversions  Conversion Categories. Select New Entries.

Type in the name TR00 and a description. Press Save. Back Out.

Select Conversion Parameters. SAPD comes up. Back out and select New Entries. Enter TR00 and select Convert Conditions and Payment methods. Press Save. Back Out.

Now select Conversion POS condition types.

As the slide showed we are going to map our R/3 POS condition types to the numerical code for our store system.

Enter TR00 184 VKP0 TR00 185 PN10 TR00 186 VKA0 TR00 187 HB00 TR00 162 UTXJ TR00 163 STTX

What is not on the slide are the codes for the downloaded condition types which we will put in the system.

.

Maintain profile for POS outbound (1/3) Describe the fields as they are shown on the slide.

(33)

Maintain profile for POS outbound (2/3) Describe the fields as they are shown on the slide.

Maintain profile for POS outbound (3/3) Describe the fields as they are shown on the slide.

Note that these fields override the Activate message, and the EDI Partner profile. Remember that when you activate a message type for one store it is active for all stores. Therefore, if you do not want a particular message type to be prepared for a particular store or group of stores, checking these boxes takes precedence over the activate change message and EDI partner profile.

Demonstration of POS Outbound Profile Configuration 5 minutes

Tools  Business Engineer Customizing  Implementation Projects  SAP reference IMG (SPRO)

Sales and Distribution  POS Interface  Outbound message processing  Maintain profile for POS outbound.

SAPD is the only Outbound profile, so it displays. Back out. Select New Entries. Enter OP00 and a description; Tr’s Outbound Profil.

POS Category – We have not created any so we’ll leave it blank. Conversion Category – We will use the category we just created – TR00 Lead Time – Outbound must be at least 2 days.

Exchange Rate type – enter

Condition Type group – Use the category we just created – US00

Person Mastr Reduc. – We have not reduced our person master so we will leave this blank

Status communic. OK – the system places a code in this field when communications is complete

Flag Settings: These provide the tool to limit the work of the system. Since change pointers are either on or off, if one store uses a message the data would be prepared if you set the message in the EDI partner profile and left these settings blank. However, you can improve system efficiency by setting these flags to reflect the data you do want.

Recipient determin – Leave blank this is only used when using direct ALE transfers. Error mode – Leave blank, this will stop outbound processing when the first error is encountered (You might want it set for testing, however.) If blank it will flag any errors and put them into the error log and complete the outbound process.

EDI – Set this one to indicate that data is to be transferred by outbound messages. Sales allowed for all MC (merchandise categories) – Blank for the demo. If set you

(34)

can send all merchandise categories regardless of whether they are listed at a store or not.

Do not prepare art. – Leave blank, if set article data is not prepared for download. No follow-on items – Leave blank, if you do not identify empties or other follow-on set it.

Do not prepare sets – Leave blank, set if you do not want set data downloaded. No mer. catgy (merchandise category) data – Leave blank, set it if you do not want merch. Catgy data downloaded. (We will use this later when it is clear that the merchandise categories are set up wrong in our data.)

No Exchange rates—leave blank Do not prepare taxes – leave blank No customer data – Leave blank

Demonstrate Assign POS Outbound Partner Profile to site R316 5 minutes

Once created, the outbound profile must be assigned to the site. Use the path:

Retail  Master data  Site, Site  Change. Enter R316 and press Enter. Select the move right arrow and select POS tab. Enter OP00 in POS outbound profile.

Exercise: Check Message Types are Active and create POS Outbound Profile for their site TS##.

20 minutes 3-3, 3-4

Break

10 minutes

Background Processes: Topic Objectives

We have completed all the set up for our outbound message WP_PLU. Now we can talk about how the system takes the information from the profiles and sets it up for the converter.

Much of the Retail system processes can be handled automatically with little or no user intervention. Simply setting up background processes allows the system to handle the routine tasks.

Outbound Report Processes

These are the reports that the system uses to prepare Outbound message data. We can access these reports in two ways, through the function and also by setting up Background jobs.

(35)

How many of you know how to set up background jobs? If most do then it is unnecessary to go through the process.

The first thing you must do for Change Pointer analysis to work is to initialize the data. That means you are going to send all data to your stores.

Demonstration of Initialization 10 minutes

Retail  Distr. Retailing  POS Interface Outbound  POS data  Initialization

Enter Sales Org – R300 Distr. Chnl – R1 Store - R316

At this point we can do a number of tasks:

If we go to GoTo  Variant  Save as a variant. Do Save it for the next demo! We can save this to use later to set up our process in the background.

We could kick it off as a background job from this screen, by accessing Program  Execute in background.

We could also select Execute. Or we can start it by pressing execute. Which I am going to do given a single store with only 2 articles listed. When the process is complete Back out to where you can select the POS Monitor.

The first time you execute an outbound assortment list, there are many errors and the message is stopped. Use the POS Monitor Demo below, to deal with the problems… present this in a positive light… this is what they will run into in an implementation and this is why it is a great tool begin using early on in an implementation process.

Display the site once again in the POS Monitor. This time the IDoc should be in Processed. Double click on the POS line and the IDoc types display. Select WP_PLU02 and press Display data. Double click on segment E1WPA01 and the data displays. You can page through each segment, note the header info and the data. With the data displaying on one screen, go to your second screen and view the

communication IDoc. Use transaction code AL11, page down, select DIR_TRANS, then select POS note your three subdirectories. View the POSout file and note the differences between looking at the file through the POS interface and through the communication IDoc. Show POSstat for the .trg file. It is simply the address of the IDoc file and it is placed there when the system has completed creating the IDoc file so that there is no chance for the converter to start transmitting an incomplete IDoc file.

Demo, POS Monitor POS Outbound – Not fully processed < 5 minutes>

(36)

Retailing  Distr. Retailing  POS Interface  Monitor POS interface. Enter R316 in Customer and press process.

Select Outbound processing, Processed. The first time there will be none. Select Not fully Processed. Expand the Site number and double click on POS line with the error message.

Select the line with red highlights (as of 11/98 there are two, the Merchandise category IDoc and the Person data IDoc). Red indicates the most important errors. Select WPDWGR01 and press Display Log. Select the resulting line item and press Display message. A list of all the merchandise categories that are not properly maintained is displayed. Clearly, we should ask someone to correct the problems with these merchandise categories, and we would if we were in a different situation but I like to show how the system highlights the problems and so we leave this one in. If we now press Long text, detail about possible solutions display. Scroll down and display the link to material maintenance, which takes us directly to the Article master data selection screen.

How will we proceed? Now that we know where the problems are we will by-pass them. Go to the Outbound profile, OP00 and select No follow-on item through No customer data, save your change and back out. Go to your second screen where the IDoc is displayed and back out.

Resend the outbound message as above and follow through with that demo.

Scheduling Outbound Change Messages to Run in the Background <5 minutes>

System  Services  Jobs  Define Job Entry screen

Job Name - enter a name you will understand and remember “Download Outbound Changes”

Job Class - A for the highest priority it will run before all other lower priority jobs. In a live system, only an administrator may assign A or B priorities.

Status – As we prepare the job it will be scheduled, as shown on the screen. It must however, be released by the background controller, before it will be run.

Target Host – leave blank and the system will run the report on the server that has the lowest background workload at the starting time of the request. You can designate a specific host upon which to run the background jobs, if you wish.

Select Start date :

(37)

you wanted to make sure that the Outbound processing only took place after some Mass merchandise background job, like massive price changes (Do we do that? Can someone give me an example???)

For our demo we will use today’s date and set the time for the end of the day. We are also going to make this a periodic job. At home probably after close of business but for now daily at lunchtime. So select Periodic values and you can see that we could schedule any period from hourly to monthly. Save.

Now press Steps to create the process to run.

Press ABAP Program, enter RWDPOSUP for the name and variant that you created in the step above. . If you don’t put in a variant, the system makes you.

Save and point out “Job POS Outbound changes has been created.” Now lets go to see if the job is released and set it so if it is not. System Services  Jobs  Job Overview

Demo, Running an Outbound Change message in Background < minutes>

Retail  Dist. Retailing  POS interface  Outbound

Note at this point that we can run both Outbound and Assortment List from this menu

 POS data  Change message

We have the same menu picks for both Outbound and Assortment List. For this demo we will use the Outbound change message.

Enter Sales Org – R300 Dist channel - R1 Store - R316

Go to Program  Execute in Background

Note the system message at the bottom of the screen: Background job was scheduled for program RWDPOSUP.

Outbound Change Message in Background

This slide is a little misleading. Generally, I make a transparency and use the overhead to explain that on day 1the first price change goes down. Then I draw a similar bar from day 2-7 and point out that no message will go out because there are no changes. Now draw from day 3 to 8 , again no changes. On day 4-9 bar, no change. On day 5 the system will pick up the date change that takes effect day 8 and send it that night. Then on day 6, it will send no message to stores 1 and 2 because it knows that the change is already gone.

(38)

Exercise to Initialize Message to store TS## 10 minutes

3-6, 3-7

5 minutes

(39)

90 minutes

List of Topics in the Unit Assortment List message type Assortment List Profile

Review as they relate to Assortment List Activate Message

Customize EDI Partner profile Customize Conversion category Customize Conversion parameters Customize Condition Type groups Customize Conversion parameters Putting the Unit in Context

Using a single message to send data to a foreign merchandise management system allows the store to be the center of control. The Assortment List sent down from headquarters can contain as much or as little data as necessary to support store operation. Outbound POS transmission of the assortment list is the efficient way to get the assortment list to the stores, change pointer analysis provides the process to accomplish this. For the process to work

“automatically” and smoothly, the assortment list profile must be created first for the Assortment List messages to be transferred seamlessly.

The assortment list message is simply a comprehensive Outbound IDoc type and message type. It should be used to send data to a foreign merchandise management system and POS servers that are large enough to handle the capacity of data that is sent.

Objectives

Describe the type of business information carried by the assortment list Deliver information that allows the students to understand and:

Customize EDI Outbound partner profiles

(40)

POS Outbound: Assortment List Business scenario

The flow of data was discussed in the Technical Grounding unit. On a more general level, this slide depicts how the system handles the entire process of capturing master data changes and downloading them to the stores.

In this unit we are concerned with the business uses of assortment list data.

During initial startup report RWDBBINI is run to prepare all the necessary data for the first time and transfer it to the foreign merchandise management systems. This Initialization should be scheduled in the background and must complete successfully (status: Preparation OK) before change messages can be created.

After initialization (a full version) is complete, whenever a user maintains master data, (such as a buyer changing an article, or a price, …) the application creates a change document. If the changed field was transmission-relevant, ALE creates a change pointer that identifies where the data can be found.

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

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. Please also note that you can manually create an assortment list using

RWDBBMAN. Path: RetailMaster DataAssortmentAssortment list Generate  Manual selection.

As we discuss the message type, you will want to keep in mind our business scenario:

We still are a general merchant with stores in 3 western US states using 2 different POS systems. Our larger stores have a foreign merchandise management system and are semi-autonomous, i.e. they order selected articles from local vendors. Automatic replenishment planning is in place for all stores and we run promotions for selected articles on weekends.

We do have a company credit card and also accept other major credit cards as well as cash and checks.

Assortment List

You have all taken IRT110 and IRT120 where the Assortment List and the concept behind it were described in detail.

At this point, you should know that an assortment list exists for each store regardless of whether you use the POS interface to communicate to the stores.

(41)

ways to create the list without downloading it using POS. We will discuss that as we get into customizing.

Assortment List Contents

Discuss the contents of the slide, which shows the types of information that the assortment list contains.

POS Outbound : Assortment List

This is just a visual representation of the slide before and contents discussion can be continued.. What is shows is that with the information sent down by headquarters, the store merchandise management system can function autonomously.

Assortment List IDoc (7 and 8) WBBDLD02

This is a visual representation of what you will see in the IDoc documentation. Remember you go there through transaction code WEDI. Select Documentation and select IDoc types.

We will alternate between this slide and the actual data from an initialization of a site.

Activate Change Pointers: Customizing

As with other Outbound message types, we will activate change pointers for our Assortment List message type, WBBDLD. Activate generally was already “turned On” for the previous outbound messages.

Stay on this slide until demo is completed. Demo, Activate the message type

2 minutes

Tools  Business Engineer Customizing  Implementation Projects  SAP reference IMG (SPRO)

Cross-Application Components Distribution (ALE) Master Data Distribution  Activate change pointers Activate change pointers (generally).

Note that this has been selected and so the ALE functionality is turned on. Back out. Select the next option  Activate change pointers for message types.

Note that all message types are already displayed in this screen. These are all the message types supported by SAP. Our interest is in the Assortment List message type so either page down several times to show the depth of support, or use position to W* to move directly to our message types.

(42)

Deselect the messages previously selected and select WBBDLD. POS Outbound: Creating an Assortment List

This slide shows the process the system goes through to determine which Assortment lists to create.

Break

10 minutes

This break depends upon lunch-time. If you have a longish review and an early lunch, this is a good time to break. If review went quickly, and you have a later lunch slot, wait until the exercise to take a break.

How it all ties together: customizing

Now lets look at the links that tie the Assortment List profile to the site and to the other definitions that make communications between disparate systems possible.

EDI Partner Profile

This is a reminder slide. Like all other outbound messages, the Assortment List message type must be defined in the Site’s Outbound Partner Profile.

Demo, Add to the EDI Partner Profile

Cross-Application Components  Distribution (ALE)  Communication  Manual Maintenance of Partner Profiles  Maintain partner profile

Enter R316, and KU as partner type. Select Outbound parameters

Message type : IDoc type Receiver Port

WBBDLD WBBDLD02 SAPIRT

Assortment List Type: Customizing

We probably want to create different types of assortment lists following different rules. As the slide shows we have three different types of assortment lists. Our food type (F) has a shorter cycle, shorter lead time, and fewer change versions before a full version is generated.

(43)

and start date of validity.

Cycle, change versions, the number of days between last message creation and a new assortment list change version.

No. of Change versions, the number of change versions that are generated before a new full version is run.

I shortened the food version because I believe that food is more volatile than the hardware or apparel industries. Is that true?

POS Outbound: Assortment List Version Management

How lead time and cycle time and versions work together making version management.

We were creating our version rules when we created assortment types with their cycles. Now we can see the effect of what that means. When we talk about the reports we will go into this process again more deeply.

Maintain profile for Assortment List (1/3) Assortment list type

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 – If you had Remote access in the stores, they could access and print at their store. You can view this on line using the path: Retail  Master data  Assortment, Assortment list  Display. after you have created an assortment list.

2 Send as message, do not save versions -- Once you’ve been live for a while and you have had consistent successful transmission this would save space.

3 Send as message and save versions

4 Do not save any version or send any message. .( use for printing or to generate status log)

Condition Type Group

We also need to tell the Assortment list which conditions must be prepared to send out to the stores. 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.

Maintain profile for Assortment List (2/3)

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

(44)

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.

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 Maintain profile for Assortment List (3/3)

The last group of parameters are:

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.

Demonstration of POS Condition Type group 5 minutes

Review of Outbound, see notes there.

Tools  Business Engineer Customizing  Implementation Projects  SAP reference IMG (SPRO)

Sales and Distribution POS Interface  Outbound message processing  Maintain condition type group.

We’ll be using the same condition types so just view. Discussion of Conversion Parameters: Customizing

5 minutes

Review of Outbound, see notes.

Tools  Business Engineer Customizing  Implementation Projects  SAP reference IMG (SPRO)

(45)

Sales and Distribution POS Interface  Standardized Data  Conversions  Conversion parameters

Then view the conditions parameter screen reminding the students that the translation is created in the converter but we enter them here also.

Demonstration of Assortment List Type Configuration 5 minutes

Tools  Business Engineer Customizing  Implementation Projects  SAP reference IMG (SPRO)

Logistics General  Assortment  Assortment List  Number ranges, status tracking

First, view the number ranges. These are provided as you see them. If for some reason you wish to, you can change them.

Logistics General  Assortment  Assortment List  Assortment List types Create a new AL type by copying one of the existing ones. Or, select New Entries and enter a type using: P as the list type for perishables; Training AL type; 2, lead time; 3 days for the cycle; and 10 no of change versions. Remind the students that the AL type is attached to the articles.

Demonstration of Assortment List Profile Configuration <5 minutes>

Tools  Business Engineer Customizing  Implementation Projects  SAP reference IMG (SPRO)

Logistics General  Assortment  Assortment List  Maintain profile for Assortment List

Copy profile 0001 and name the new one AL00,

When the system asks you whether to copy all the dependent entries or just the entry itself, copy all.

Then select AL00 and Maintain assortment list profile parameters

Select Assortment list type 1 and press the mag. Glass to view the contents. Back out and press Trash to delete AL type 1.

Also trash AL type T for apparel. You might note that one AL profile, because of the different AL types, can handle several different groups of articles differently without creating many profiles.

(46)

Demonstrate Assign POS Assortment List Profile to site R316 5 minutes

Once created, the outbound profile must be assigned to the site. Use the path:

Retail  Master data  Site, Site  Change. Enter R316 and press Enter. Select the move right arrow and select POS tab. Enter AL00 in Assort. list profile.

Exercise: Create and review all the necessary profiles and Assortment List Profile for their site TS##.

20 minutes 4-1, 4-2, 4-3, 4-4, 4-5 Break

10 minutes

You only need this break if you didn’t take the earlier one. Demonstration of Assortment List Initialization

10 minutes

Initialize the Assortment List for R316:

Make sure that WBBDLD message type is active.

RetailMaster dataAssortment  Assortment List Generate Initialization Sales organization – R300

Distribution channel R1 Customer R316 Assortment list type F – H

Before running this, go to Goto  Variant  Save as variant. Enter a name, description and Save.

Execute

You might want to talk a bit about the report that displays before you back out to view the POS monitor. Note there are two IDocs because there are two assortment list types. Each has an Outbound log, notes for customer the IDoc number with the number of segments and at the bottom there is a general log with the number of entries.

Figure

Updating...

Related subjects :