ECO, Ltd.

TABLE OF CONTENTS
1 APPROACH NOTE PROCESS DOCUMENT

Project AIM

2 6

DELIVERY TRACKING REVISION HISTORY 2 BUSINESS PROCESS SUMMARY 3 BUSINESS REQUIREMENTS 4 BUSINESS PROCESS DESCRIPTION 5 BUSINESS OBJECTS AND MASTER DATA DESIGN DOCUMENT

6 7 9 10 11 15 17

DELIVERY TRACKING REVISION HISTORY 6 BUSINESS PROCESS SUMMARY 7 BUSINESS REQUIREMENTS 8 OBJECT DEFINITION

17 I 3 4 5

Copyright 2005 SAP AG. All rights reserved

ECO, Ltd.
1 APPROACH NOTE

Project AIM

SAP SCEM implementation through Global Delivery Methodology

Global Delivery is a part of ASAP methodology for SAP Solution implementations. This approach note aims at providing certain guidelines and considerations for carrying out the SAP SCEM (Supply Chain Event Management) solution implementation as per ASAP involving Global Delivery. The approach has been divided into sections that reflect various ASAP phases and are marked with the corresponding Global Delivery Involvement in each section. This note also includes or includes links to accelerators that may be used to expedite the implementation.

Level 1 Questions

Level 2 Questions

Process Document

Evaluation / Confirmation

Final testing and UAT

Test Scripts Generation

Realization / Developments

Detailed Design Doc.

Done at a GDC Location

Above figure shows the flow of activities, the extent of Global Delivery based activities marked in color. Each of the steps are described below.

1.1 Level -1 Questions

Global Delivery Methodology has a set of standard questions that are useful in understanding the broad profile of requirements or customer expectations from the Supply Chain Event Management. Depending on the functions and processes involved in the tracking scenarios, the standard content provided by SAP will be evaluated to assess the extent to which it can be used. Also depending on the systems involved, an integration strategy will need to be developed.

See Appendix A for Level 1 Questions Accelerator

1.2 Level 2 Questions

After above has been done, a level two set of questions will be prepared. This will contain a set of standard questions as well as some specific questions based on the actual scenarios. This shall be

Copyright 2005 SAP AG. All rights reserved

ECO, Ltd.

Project AIM

done in coordination with other concerned entities working on the project and customer responsible. This can be done either from Global Delivery location or customer location depending on the assessment made by the SCEM consultant.

1.3 Process Documentation

After understanding the requirements and the landscape, the Global Delivery team will prepare a process document that will highlight the Event Management related aspects in the business process. It will clearly mention the activities that will be tracked, the statuses that will need to be monitored, what will be system reaction to the events, what data will be captured and what channels will be used for gathering and distributing event related information. In short, this document will describe the process of event management without yet getting into the configuration or technical design.

See Appendix B for Process Documentation Accelerator

1.4 Evaluation & Confirmation

The Customer will evaluate and confirm the processes recorded in the process document.

1.5 Detailed Design Document

The Global Delivery team will prepare a detailed design document. This shall list down the configuration guidelines. For example it will list the Event Handlers to be configured, Naming Convention, Status Profiles to be configured, Standard Objects to be used from Visibility Scenarios, Development requirements, etc.

See Appendix C for Detailed Design Document

1.6 Realization / Developments

The actual configuration and developments related to ABAP and J2EE will be done by the Global Delivery team from the Global Delivery locations. Some examples of the key objects are following: Configuration of SAP Application Systems
o o Application Object Types with all Extractors Event Types with all Extractors

Configuration of the SAP Event Management System

o Event Handlers

Copyright 2005 SAP AG. All rights reserved

ECO, Ltd.
o o o o Alerts Status Monitoring Expected and Unexpected Events BW profiles

Project AIM

Configuration for Web based monitoring and reporting through WCL

o o o WCL Transaction configuration User Profiles for WCL Look and Feel related developments for WCL

Etc.

1.7 Test Scripts

After the configuration phase is complete, the testing will follow. This step before testing involves developing test scripts that represent the actual business scenario. This will obviously depend on the extent of dependencies on other solution component. The test scripts will list down the step by step transactions to be carried out and the expected results.

Appendix D for Test Scripts Accelerator

1.8 Testing / UAT

(User Acceptance Test) Once the test scripts are ready, the first round of testing will be carried out by the designated testers at Global Delivery Locations. Next level will be testing by the actual business users. The recorded method of carry out the process during testing may be provided to the users from the customer site. There will be template provided to the users to record any observations or issues. The issues will be resolved by the Global Delivery Team along with the other concerned teams. More rounds of testing may be needed if there are significant changes suggested during testing.

Copyright 2005 SAP AG. All rights reserved

ECO, Ltd.
Appendix A. Level 1 Questions

Project AIM

It is assumed here that the participants from Customer side will have conceptual understanding of Event Management, if not that will be taken up taken up in the form of training by the implementation team before gathering these requirements.

Q. Do you want to use SCEM for monitoring only? Or you want certain automatic actions to be
triggered by SCEM System.? Q. Q. Which are the functions that will be involved in tracking? List down all tracking scenarios (a string or set of events that you want to view together or want to have a status of) that you would like to have. Ex: Tracking of delivery process from Delivery creation till proof of delivery. Q. Which are the processes that will be involved in tracking?

Q. For each of above scenarios list down following..

a. All the expected events that will be part of the tracking scenario b. All the unexpected events that may occur under the scenario c. For each event, what is the source of information? It could be own system or a partner system, SAP or Non-SAP system. It could also be a manual recording of an event. d. For each expected event, if you would like to have an expected date and time, what will be the source of this information. e. What would be the reaction for reporting expected or unexpected event? Similarly reaction to an overdue expected event? Reaction could involve, sending e-mail alerts to partners or customers, updating statuses or carrying out some activity in the systems. f. What status would you like to monitor? Statuses can be managed independent of events and are updated as a result of event reporting. Q. Would you like to extract the SCEM data into BW system for analysis? Q. What is data you would want to extract from each of the tracking scenarios? Q. Would you require status monitoring on the internet or Portal?

Copyright 2005 SAP AG. All rights reserved

ECO, Ltd.

Project AIM

Appendix B. Sample Process Documentation

Sample Project
PROCESS DOCUMENT

DELIVERY TRACKING

Version 1.0
<24.03.2005 > Steve Balmer

Copyright 2005 SAP AG. All rights reserved

ECO, Ltd.
REVISION HISTORY
Version Number 1.0 Amendment Number 1 Date Description Initial Release

Project AIM

Author

Copyright 2005 SAP AG. All rights reserved

ECO, Ltd.
TABLE OF CONTENTS
1 APPROACH NOTE PROCESS DOCUMENT

Project AIM

2 6

DELIVERY TRACKING REVISION HISTORY 2 BUSINESS PROCESS SUMMARY 3 BUSINESS REQUIREMENTS 4 BUSINESS PROCESS DESCRIPTION 5 BUSINESS OBJECTS AND MASTER DATA DESIGN DOCUMENT

6 7 9 10 11 15 17

DELIVERY TRACKING REVISION HISTORY 6 BUSINESS PROCESS SUMMARY 7 BUSINESS REQUIREMENTS 8 OBJECT DEFINITION

17 I 3 4 5

Copyright 2005 SAP AG. All rights reserved

2 BUSINESS PROCESS SUMMARY

Various business processes have been described in detail in other documents. Its being described here from the Event Manager (EM) perspective. There are three entities involved in the whole process. HUB, Drop Off Point (DOP) and Client 1 customer. The Customer places an order on a HUB for the equipment. The HUB delivers the material to the DOP which is geographically suitable to the Customer. The DOP can make a partial receipt of a delivery. Ie it can accept some handling units of all the handling units in a delivery. The DOP then puts away the HUs in the storage area. Receipt of incomplete deliveries (not all HUs being there) is handled as an exception. The Client 1 customer engages one or more installation partners for installing the equipment across various sites. An installer can work for more than one customer and can install equipment at more than one site for the same customer. The respective installer, representing the customer, fixes up an appointment by calling up the DOP and then picks up the material at a pre-agreed time. The DOP can issue only complete deliveries to the Installer. Delivery cant be made to the installer even if one HU is missing or is not in deliverable condition due to damage etc. In case the installer does not find any HU as expected, he has to reject the complete delivery. The installer can return complete deliveries to the DOP for temporary storage, in which case he can pick them again at a later point of time. Only complete deliveries can also be returned to the DOP due to rejection. The DOP can initiate the process of sending back the HUs to the HUB. Event Manager will also collect information in the process which needs to be stored somewhere on a regular basis so that it can be analyzed later or can be used for activities like billing etc. Hence Event Manager will keep sending the required information to the Business Information Warehouse. Following events have been identified for tracking. (U= unexpected event) Inbound 1. PGI from Client 1 2. Departure from HUB* 3. Arrival at DOP ` 4. PUT away 5. Return to HUB (U) Outbound 1. Installer arrival 2. Pickup by installer 3. Installer no-show (U)** 4. Installer rejection (U)** 5. Installer return (U)**

* The event of Departure from HUB will not be separately tracked; PGI from Client 1 will be taken as departure from HUB. ** Three unexpected events of No-show, Rejection and return will be combined into one unexpected event.

Copyright 2005 SAP AG. All rights reserved

ECO, Ltd.
3 BUSINESS REQUIREMENTS

Project AIM

In the business process described above various users need to know the status of various events in order to coordinate the work. The DOP needs to know when a delivery is dispatched from the HUB. They also need the information about who is the ultimate receiver of this material and when is he going to come and collect this material. The Installer needs to know when his order has been dispatched from the HUB and when its arriving at the DOP. He needs the information about when his material is ready for pickup from the DOP. The DOP needs to know, in case the Installer has changed his plan of picking the material. And on the overall level, CLIENT 1 needs to know about the material movement from and to the DOP. Broadly the business requirement from the Tracking point of view can be divided into four categories 1. Ability to see an online and up-to-date status of various business objects (Ex. Delivery etc) and various events (Ex. Arrival of truck at DOP, Delivery pickup by the Installer ) 2. Ability to get automatic alerts as a result of occurrence of different events. (Ex. An alert to Client 1 when a delivery reaches the DOP ) 3. Various data points generated in the process of tracking should be available for use later. (Ex. Time which a Handling unit spends at the DOP ) Proposed Solution Event Manager Solution in SAP SCM 4.0

Copyright 2005 SAP AG. All rights reserved

10

ECO, Ltd.

Project AIM

4 BUSINESS PROCESS DESCRIPTION

There are several places in the processes chain where capturing of specific events is a business requirement. At most of the places the business requirement is to record and report the status of processes at a delivery level. However at some places for example partial receipt of a delivery, the status capturing needs to be done at handling unit level. Hence both HU level and delivery level tracking will be provided as per business requirement. The Business process has been described below from the point of view of occurrences of events at various stages. Entire process has been divided into two parts:

4.1 Inbound Logistics

HU comes into existence before the shipment process in Client 1 system. After the packing Client 1 sends out a Shipment request to CLIENT 2. CLIENT 2 takes a delivery and transports it to the designated Drop off point. In above process the event to be noted is handing over of the Shipment to CLIENT 2. Hence this should form the first event in the series. The shipment from the HUB may not leave at the same time as the shipment creation. Hence the actual departure of the delivery from the HUB forms another important event. After remaining in transit for some time, the delivery reaches the DOP and arrival of delivery at the DOP marks another significant event. Delivery is received at the DOP and handling units are checked for correctness. Correct HUs / Deliveries are put away into the warehouse. Once a delivery is completely put away, its technically ready to be picked up by the recipient of the delivery. Hence this forms another important event. There can be a scenario where an HU or entire delivery is to be returned to the HUB after receiving it at the DOP, which is an unexpected event and hence should be tracked. Thus following are the key events on the inbound side of the process...

4.1.1 Expected Events

The expected events by definition are events that are expected to take place in the normal flow of activities. Based on above understanding of the process and discussions with CLIENT 2 and Client 1 following expected events have been identified.

Copyright 2005 SAP AG. All rights reserved

11

ECO, Ltd.
4.1.1.1 PGI from Client 1

Project AIM

Its actually sending of the Shipment request but due to convention being followed in the project, its being called so.

4.1.1.2 Departure from HUB (Proposed not to be separately tracked)

Since a manual entry will be required to specifically mark the departure from the HUB, its been decided that the event PGI from Client 1 will be taken as the indicative of departure from the HUB.

4.1.1.3 Arrival at DOP

Arrival of the HU at the DOP is recognized by the system, however at this time the HU has still not been taken into the storage space.

4.1.1.4 Put away at DOP

When the HUs is taken into the storage space and are put away into specific storage bins, the event of HU put away is marked.

4.1.2

Unexpected Events

Unexpected events are not part of normal flow but are expected to occur due to some abnormal conditions. Hence a provision is to be made to track such occurrences. Following have been identified as unexpected events.

4.1.2.1 Return to the HUB (Unexpected Event)

There can be instances where a handling unit is returned to the HUB after being received into the DOP or after having been returned by the installer.

4.2 Outbound Logistics

Once all the HUs of a delivery have been put away in the DOP the outbound side of the DOP process starts. From here on, the transaction happen only at complete delivery level. The respecting installer receives a notification about the arrival of his goods at the DOP. The installer then calls up the DOP and fixes an appointment for picking up the delivery from DOP. The DOP records the proposed pickup time against the name of the installer, the customer it represents and the delivery he intends to collect. The DOP brings the Handling units corresponding to the delivery which Installer intends to collect, into the delivery area. This is done before the installer arrives. The Installer then comes to pickup the delivery. At this time the Instance of Arrival of the Installer is manually recorded along with the time of arrival. This forms an important event because this determines how much time passed between arrival of the delivery at the DOP and its pickup by the installer. The installer picks up the goods and then the PGI for the delivery is carried out. This marks the Goods picked up by Installer event. In case of unexpected Installer no-show, an unexpected event is reported. After which Installer can refix an appointment and collect the delivery as a normal process.

Copyright 2005 SAP AG. All rights reserved

12

ECO, Ltd.

Project AIM

There can also be a case of one or more handling units being rejected by the installer, after inspection. This results in complete rejection of the delivery by the installer. This event of rejection is recorded as an unexpected event. And if after rejection, the HUs are sent back to the Hub, this is also reported to the EM. Hence the events in the outbound chain are as follows.

4.2.1 Expected Events

4.2.1.1 Installer arrival
Actual arrival time of the installer is recorded and marked as an event of Installer Arrival.

4.2.1.2 Pickup by the installer

When installer picks up the corresponding delivery this event is marked.

4.2.2 Unexpected Events

Following unexpected events have been identified on the outbound side of DOP processing.

4.2.2.1 Installer No-show (Unexpected)

In case the Installer doesnt turn up at the agreed time, the DOP records this event manually. Since there can be situations where the Installer might call up some time before the scheduled pickup time and change the appointment time. Its on the discretion of the DOP operator to record this event.

4.2.2.2 Rejection (Unexpected) 4.2.2.3 Return by Installer (Unexpected) 4.2.2.4 HU returned to the HUB (Unexpected)
In Return to HUB process remains the same as in the case of return to Hub in the inbound side. Its been decided that all unexpected events related to the Installer will be recorded as one event in the phase 1 of the project.

Copyright 2005 SAP AG. All rights reserved

13

ECO, Ltd.

Project AIM

Copyright 2005 SAP AG. All rights reserved

14

ECO, Ltd.

Project AIM

5 BUSINESS OBJECTS AND MASTER DATA

5.1 Business objects in R/3
5.1.1 Business Process type
A Business process type is defined as a segregation of areas of tracking. For example finance related trackings need to be kept separate from logistics related trackings. Application object types and Event types are defined under a Business Process type.

5.1.2 Application Object Types

The application object type is used to determine the supply chain event management relevance (SCEM relevance) of objects or processes in the application system. The Handling unit & the Deliveries will have to be defined as Application Object type. EM relevance of an AOT is decided by the conditions or functions assigned to the AOT. Creation of an AOT in the R/3 system will typically trigger creation of an Event Handler which is a counterpart of the AOT in the EM system.

5.1.3 Event Types

Various events that occur in the application system (Ex. Completion of packing for a delivery) are defined as event types. Each event type is tested for Event Management relevance by applying the relevance conditions. A relevant event sends an event message to the EM system and corresponding event is reported in the suitable event handler.

5.1.4 Tracking IDs

Tracking ID group: A tracking ID group, is basically a type of tracking IDs. For example in order to track a Handling Unit, one can use either the HU number or the Delivery number. Hence HU number is one group and Delivery number is another group. Within a group a particular number (Ex. HU no. 87349200) is called a Tracking ID. When we enter a tracking ID, the system needs to be told whether the number being entered is a HU number or a Delivery number, hence tracking ID group is specified. Following tracking ID groups are proposed to be used... 1. Client 1 Delivery Number 2. Client 1 Handling Unit number 3. CLIENT 2s internal Handling unit no. 4. CLIENT 2s internal SO number.

5.2 Business objects in EM

5.2.1 Business Process type
Business Process type is defined in EM similar to R/3. The Business Process type is common in both the systems. The event handler types are defined under a business process type.

Copyright 2005 SAP AG. All rights reserved

15

ECO, Ltd.
5.2.2 Event Handler type

Project AIM

Event handler is the smallest unit at which tracking is done. Event handler in EM corresponds to the application object type. Event handler types shall be defined for HU and Delivery.

5.2.3 Internal Event codes

Codes will need to be defined for various events that are expected to be tracked, both expected and unexpected.

5.2.4 Expected Event Profile

An expected event in EM corresponds to the milestones in the R/3 system. These milestones for an application object type are identified by the Expected Event Extractor of the AOT. An expected event profile is to be assigned to an event handler type.

5.2.5 Status profile

A status profile is assigned to an Event Handler type. A status basically contains a list of status messages and possible values for every message. For example one of the status message in a profile can Delivery status and possible values of the same can be Not started, In transit & Completed Following status profile is proposed Message HUB to DOP Transport Put away at DOP Pickup by Installer HU status Possible Values To start; In transit; Completed To Start; Completed To Start; Going on; Completed To reach DOP; Lying at DOP; Picked up by installer; Returned to HUB

5.2.6 Authorization Profiles

An authorization profile is assigned to a user and the user can display or change the data, post event messages etc based on the assigned profile. Initially standard profiles will be defined, once the system is configured, profiles can be assigned to the actual users as per CLIENT 2s need.

Copyright 2005 SAP AG. All rights reserved

16

ECO, Ltd.

Project AIM

Appendix C. Sample Design Documentation

Sample Project
DESIGN DOCUMENT

DELIVERY TRACKING

Version 1.0
<24.03.2005 >

Copyright 2005 SAP AG. All rights reserved

17

ECO, Ltd.
REVISION HISTORY
Version Number 1.0 Amendment Number 1 Date Description Initial Release

Project AIM

Author

Copyright 2005 SAP AG. All rights reserved

ECO, Ltd.
TABLE OF CONTENTS
1 APPROACH NOTE PROCESS DOCUMENT

Project AIM

2 6

DELIVERY TRACKING REVISION HISTORY 2 BUSINESS PROCESS SUMMARY 3 BUSINESS REQUIREMENTS 4 BUSINESS PROCESS DESCRIPTION 5 BUSINESS OBJECTS AND MASTER DATA DESIGN DOCUMENT

6 7 9 10 11 15 17

DELIVERY TRACKING REVISION HISTORY 6 BUSINESS PROCESS SUMMARY 7 BUSINESS REQUIREMENTS 8 OBJECT DEFINITION

17 I 3 4 5

Copyright 2005 SAP AG. All rights reserved

ii

ECO, Ltd.
6 BUSINESS PROCESS SUMMARY

Project AIM

Various business processes have been described in detail in other documents. Its being described here from the Event Manager (EM) perspective. There are three entities involved in the whole process. HUB, Drop Off Point (DOP) and Client 1 customer. The Customer places an order on a HUB for the equipment. The HUB delivers the material to the DOP which is geographically suitable to the Customer. The DOP can make a partial receipt of a delivery. Ie it can accept some handling units of all the handling units in a delivery. The DOP then puts away the HUs in the storage area. Receipt of incomplete deliveries (not all HUs being there) is handled as an exception. The Client 1 customer engages one or more installation partners for installing the equipment across various sites. An installer can work for more than one customer and can install equipment at more than one site for the same customer. The respective installer, representing the customer, fixes up an appointment by calling up the DOP and then picks up the material at a pre-agreed time. The DOP can issue only complete deliveries to the Installer. Delivery cant be made to the installer even if one HU is missing or is not in deliverable condition due to damage etc. In case the installer does not find any HU as expected, he has to reject the complete delivery. The installer can return complete deliveries to the DOP for temporary storage, in which case he can pick them again at a later point of time. Only complete deliveries can also be returned to the DOP due to rejection. The DOP can initiate the process of sending back the HUs to the HUB. Event Manager will also collect information in the process which needs to be stored somewhere on a regular basis so that it can be analyzed later or can be used for activities like billing etc. Hence Event Manager will keep sending the required information to the Business Information Warehouse. Following events have been identified for tracking. (U= unexpected event) Inbound 1. PGI from Client 1 2. Departure from HUB* 3. Arrival at DOP ` 4. PUT away 5. Return to HUB (U) Outbound 1. Installer arrival 2. Pickup by installer 3. Installer no-show (U)** 4. Installer rejection (U)** 5. Installer return (U)**

* The event of Departure from HUB will not be separately tracked; PGI from Client 1 will be taken as departure from HUB. ** Three unexpected events of No-show, Rejection and return will be combined into one unexpected event.

Copyright 2005 SAP AG. All rights reserved

ECO, Ltd.
7 BUSINESS REQUIREMENTS

Project AIM

In the business process described above various users need to know the status of various events in order to coordinate the work. The DOP needs to know when a delivery is dispatched from the HUB. They also need the information about who is the ultimate receiver of this material and when is he going to come and collect this material. The Installer needs to know when his order has been dispatched from the HUB and when its arriving at the DOP. He needs the information about when his material is ready for pickup from the DOP. The DOP needs to know, in case the Installer has changed his plan of picking the material. And on the overall level, CLIENT 1 needs to know about the material movement from and to the DOP. Broadly the business requirement from the Tracking point of view can be divided into four categories 4. Ability to see an online and up-to-date status of various business objects (Ex. Delivery etc) and various events (Ex. Arrival of truck at DOP, Delivery pickup by the Installer ) 5. Ability to get automatic alerts as a result of occurrence of different events. (Ex. An alert to Client 1 when a delivery reaches the DOP ) 6. Various data points generated in the process of tracking should be available for use later. (Ex. Time which a Handling unit spends at the DOP ) Proposed Solution Event Manager Solution in SAP SCM 4.0

Copyright 2005 SAP AG. All rights reserved

ECO, Ltd.
8 OBJECT DEFINITION

Project AIM

8.1 APPLICATION OBJECT AND EVENT TYPES

Application Object Types ZDN_DEL_IN ZDN_DEL_OUT ZDN_HU_AOT Event Types ZDN_HU_TO_CREATE ZDN_HU_TO_CONFIRM Transfer order creation for an HU in inbound delivery Transfer order confirmation for HU in inbound delivery Inbound delivery process Outbound delivery process Handling unit

8.2 EXPECTED EVENT CODES

Expected Events ZDN_PGIDON_DH ZDN_LEFHUB_DH ZDN_ARRDOP_DD ZDN_ARRDOP_HH ZDN_PUTDOP_DD ZDN_PUTDOP_HH ZDN_ARRINS_DH ZDN_DELDOP_DD ZDN_DELDOP_HH Unexpected Events ZDN_NOINST_DH ZDN_INSREJ_DD ZDN_INSREJ_HH ZDN_RETHUB_HH ZDN_RETHUB_DD ZDN_INSRET_DD ZDN_INSRET_HH Installer doesnt arrive Installer rejects the delivery Installer rejects the HU Handling unit returned to HUB Delivery returned to HUB Installer returned the Delivery Installer returned the Handling Unit PGI done Delivery left the HUB Delivery arrived at the DOP Handling unit arrived at the DOP Delivery put away done at DOP Handling unit put away done at DOP Installer arrived at DOP Delivery picked up from DOP Handling unit picked up from DOP

Copyright 2005 SAP AG. All rights reserved

ECO, Ltd.
8.3 STATUS PROFILE DEFINITIONS

Project AIM

Status profile for the Inbound Delivery Event Handler Status Profile: (ZDN_INBDEL: Inbound Delivery status profile) Attributes of profile: ZDN_ARR_DEL_IB: Arrival of delivery at the DOP In transit Partially arrived at DOP Fully arrived at DOP ZDN_DEL_PUT_IB: Put away of delivery at DOP Not started Partially put away Fully put away ZDN_PICKUP_IB: Delivery pickup by Installer Pick up not done Pick up completed Status profile for the Outbound Delivery Event Handler Status Profile: (ZDN_OUTDEL: Outbound Delivery status profile) Attributes of profile: 1. ZDN_STAT_OB: Status of outbound delivery Delivery created Delivery handed over to the Customer

Copyright 2005 SAP AG. All rights reserved