IDOC Development Procedures1

  • View
    28

  • Download
    9

Embed Size (px)

DESCRIPTION

IDOC Development Procedures1

Text of IDOC Development Procedures1

Global ABAP Naming tandard

Information Technology

Information Technology

IDoc Template

SAP Development Architecture

Effective:

Revised:

Owner:

IT Architect:

Prepared By:

Document Version:

Document Revision History

DateVersion AuthorChange Description

Table Of Contents

3Introduction to IDocs

3Structure of an IDoc.

4General Definition

51)Creating a New IDoc

13Outbound IDoc

131)Programming in the IDoc Interface

162)Configuring the system for Outbound IDocs

213)Transporting the IDoc to the receiving system.

22Inbound IDoc

221)Programming in the IDoc Interface

232)Configuring the system for Inbound IDocs

27Testing IDocs

28Monitoring IDoc

33Appendix A

35APPENDIX B

36APPENDIX C

38REFERENCES

Introduction to IDocs

The term IDoc stands for Intermediate document. It is simply a data container (like a text file) used to exchange information between any two systems, which can understand the structure and content of the data. An IDoc is created as a result of an outbound ALE or EDI process; an IDoc serves as input to create an application document. For example, an IDoc is created when an order is placed and this IDoc can be used to create a purchase order. Idocs are stored in the database. Every IDoc has a unique number. They can be used for SAP to SAP and SAP to non-SAP communication as long as the participating processes can understand the structure and content of the data.

IDoc types are independent of the direction of data exchange. An inbound and an outbound process can use the same IDoc type. Eg. ORDERS01 IDoc is used by the purchasing module to send a purchase order and it is also used by the Sales and Distribution module to accept a sales order.

IDocs can be viewed in a text editor since the data is stored in character format.

Structure of an IDoc.

An IDoc structure consists of several segments. A segment consists of several data fields. The IDoc structure defines the syntax of the data by specifying a list of permitted segments, the arrangement of the segments, mandatory versus optional segments. Segments define a set of fields and their formats.An IDoc is an instance of an IDoc type and consists of three types of records.

One control record. Each IDoc has only one control record. The control record contains all the control information about an IDoc, including IDoc number, the sender and recipient information, information such as message type it represents, IDoc type, present status. The control record structure is the same for all IDoc types. The SAP defined structure is EDIDC and can be viewed using transaction SE11. One or many data records. An IDoc can have multiple data records, as defined by the IDoc structure. Segments translate into data records. Data records store the application data, such as purchase order header information and purchase order detail lines. The structure of a data record is defined in EDI_DD40 and the data records are found in EDID4. One or many status records. Multiple status records are usually attached to an IDoc. Status records are attached to an IDoc throughout the process, as the IDoc goes through different stages. A status code, date and time are assigned at every stage. Transaction WE47 will give you a list of status codes and their definitions. Codes 01 through 49 are used for outbound IDocs and 50 onwards for inbound. The status records are stored in EDIDS table.Multiple messages per IDoc type.

A message represents a specific type of document transmitted between two partners. Orders, order response, customer master are examples of messages. An IDoc type can be used to represent several message types (of course, the messages must be logically related). For example, the orders IDoc type (ORDERS05) is used for several messages, including orders (ORDERS), order response (ORDRSP), and order change (ORDCHG).General Definition

When creating a new IDoc, the following steps needs to be carried out in both the sending (ES1150) and receiving system (GDV200).

There are six phases involved in the methodology to create an IDoc for any Outbound Process (With or without MC).

1) Analysis: Analyze the business requirements and compare them with what SAP Provides.

2) Preparation: Identify various parameters used in the process

3) Setup: Configure the EDI components and build the necessary Master Data.

4) Testing: test the setup phase.

5) Execution: Execute the process

6) Verification: Verify the results

Case Scenario:

Lets go through the whole process of creating a new IDoc. We will use a simple example where the system sends out a monthly report for each employees weekly hours. The report is divided in three parts: Header, Details and Summary. Here is an example of a Flat file and actual report

Last Name

(15)First Name

(15)Social Security

(11)Date of Birth

(8)

Week Number

(1)Hours Worked

(3)Hourly Rate

(3)Client Site

(20)Work Description

(40)

Total Hours

(3)Total Amount

(10)

SmithJohn123-45-6789102668

13040Houston BreweryBeer Testing

23040Network ComputersHigh level consulting

33050Network ComputersProgramming

45060DSP SystemsEDI Programming

1406900

To accomplish this we will first: create a new IDoc (covers the first three phases above), second: Configure the IDoc (phase three), and last test, execute and verify.

Here is also the break up of names that will be assigned to the different components

COMPONENTNAMING CONVENTIONACTUAL NAME

Message TypeZZEMP_MNT_RPT

Idoc TypeZ 01ZEMP_MNT_RPT01

Segment TypeZ Z1EMP_HD, Z1WK_DET, Z1CL_DET, Z1SUMRY

Outbound Function ModuleZ_IDOC_OUTPUT_Z_IDOC_OUTPUT_EMPMTHRPT

1) Creating a New IDoc

The following steps take you through a standard procedure whenever creating a New IDoc. Before going to this, it is important get the right standards.

Naming Convention:

Names assigned to an IDoc type should be meaningful. It should tell the user what that IDoc does. Maximum length allowed is 30 characters for release 4x. Here is a format for naming custom IDocs.

Z

Custom IDoc type must start with Z and end with two numeric characters. This number denotes the version of the IDoc. In general the version number is incremented by one. Example, for our case we will assgin the name ZEMP_MNT_RPT01. For the next version, this IDoc will be ZEMP_MNT_RPT02.

Naming Segments requires the following format

Z1

All custom segments begin with Z1 and all SAP Segments begin with E1

Design Guidelines:

Develop an IDoc type for a function, not for a specific application. Example: ORDERS02 is designed for the order process and not specifically for the sales order entry application. Thus, this IDoc is used for several documents such as Purchase order, Sales order, Order response. You should follow a similar strategy when creating a new Basic IDoc type.

Use industry standards whenever possible for your data elements. Consult EDI standards for the appropriate length and data types and ISO codes for fields such as measurement units and currencies.

Organize the document to contain header, detail and summary information.

Do NOT repeat a segment type in an IDoc Definition

Use the parent-child relationship when you are going to permit several entries of the same type in one IDoc. Example: The following diagram shows processing one employee at a time. If you want to support multiple entries of employees then the second diagram shows how to set up the parent-child relationship

Avoid having too many mandatory segments. Having extra mandatory segments reduces the reusability of the IDoc.

Make sure that the segments are less than 1000 bytes. If they are bigger than 1000, try to split them.

Combine IDoc segments that are functionally similar into one segment whenever possible.

Create segments that can be used by other IDoc.

Formatting Guidelines Data fields in a segment can contain only alphanumeric values.

Data TypesDescription

CHARCharacter String

CLNTClient

CUKYCurrency Key, refrenced by CURR fields

DATSDate Field ( YYYYMMDD) stored as char(8)

LANGLanguage Key

NUMCCharacter field with only digits

TIMSTime Field (HHMMSS), stored as char(6)

Fields should be left aligned. Character fields are automatically left aligned, but number values when assigned to a character field are padded with spaces on the left. These spaces must be removed from the fields programmatically using the condense command.

Data is not case sensitive.

Negative values are indicated by a minus sign after the value. Therefore 123 is written as 123-.

Numbers with fractional values use a period to represent the decimal point.

Floating-point numbers also use a period to represent the decimal point.

No formatting is used to separate values in the thousands. E.g 29,000.00 ( 29000.00

Now that you have covered the basic requirement for creating a new IDoc, lets move on to the actual process. The following five steps will guide you to successfully creating a New IDoc. However, before moving ahead make sure you have created a Developing Class to store all your objects and save everything as LOCAL. (See Appendix A for creating a new developing class.)

1.1 Data AnalysisAnalyze the data that needs to be exchanged between two systems. It is