IDOC Development Procedures

Information Technology

IDoc Template SAP Development Architecture

Effective: Revised: Owner: IT Architect: Prepared By: Document Version:


Document Revision History Date

143680243.doc

Version

Author

Change Description

Page 1 of 41


Document Revision History Date

143680243.doc

Version

Author

Change Description

Page 1 of 41


Table Of Contents Introduction to IDocs.............................................................................................................................................3 Structure of an IDoc.................. IDoc............................ ..................... ..................... .................... ..................... ..................... ..................... ..................... .................... .........................................3 ...............................3 GENERAL

DEFINITION............................................................................................................................................4

1)CREATING A NEW IDOC...........................................................................................................................................5 OUTBOUND

IDOC...................................................................................................................................................14

1)PROGRAMMING IN THE IDOC I NTERFACE..................... ............................... ..................... ..................... ..................... ..................... .................... .....................................14 ...........................14 2)CONFIGURING THE SYSTEM FOR OUTBOUND IDOCS .............................................................................................17 3)TRANSPORTING THE IDOC TO THE RECEIVING SYSTEM.................... .............................. .................... ..................... ..................... ......................................22 ............................22 INBOUND IDOC.............. IDOC........................ .................... ..................... ..................... ..................... ..................... .................... ..................... ..................... ..................... ..................... ..................................23 ........................23

1)PROGRAMMING IN THE IDOC I NTERFACE..................... ............................... ..................... ..................... ..................... ..................... .................... .....................................23 ...........................23 2)CONFIGURING THE SYSTEM FOR I NBOUND IDOCS.................... ............................... ..................... .................... ..................... ..................... ...................................24 .........................24 TESTING

IDOCS.......................................................................................................................................................28

MONITORING

IDOC................................................................................................................................................29

.......................................................................................................................................................................................33 APPENDIX

A..............................................................................................................................................................34

APPENDIX

B..............................................................................................................................................................36

APPENDIX

C..............................................................................................................................................................37

REFERENCES............................................................................................................................................................39

143680243.doc

Page 2 of 41


Introduction to IDocs The term IDoc stands for Intermediate document. It is simply a data container (like container (like a text file) used to exchange information between any two processes systems, systems, which can understand the semantics and syntaxstructure and content of the data. An IDoc is created as a result of an o utbound ALE or EDI process; an IDoc serves as input to create an application document. For example, example, an IDoc is created when an order is placed and this IDoc can be used to create a purchase order. Idoc’s 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 ORDERS01 IDoc is used by the purchasing purchasing module to send a purchase order and it is also used by the Sales and Distribution module to accept a sales order. IDoc’s can be viewed in a text editor since the data is stored in character format. Structure of an IDoc. An IDoc structure structure consists of several segments. segments. A and segments segments consists 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 an instance of an IDoc IDoc type and consists of three types of records. records. • One control record. Each IDoc has only one control record. The control record contains all the control information about an IDoc, including – including – o IDoc number, the sender and recipient information, o o information such as message type it represents, represents, o IDoc type, present status. o

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 the process, as the IDoc IDoc achieves goes through different stagesdifferent milestones. milestones. A status code, date and time are assigned at every milestonestage.. Transaction WE47 will give milestonestage give you a list of status status codes and their definitions. definitions. Codes 01 through 49 are used for outbound IDocs and 50 onwards for inbound. The status records can are stored in EDIDS table table..

Multiple messages per IDoc type. A message represents a specific type of document transmitted transmitted between two two partners. Orders, 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

143680243.doc

Page 3 of 41


(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 employee’s weekly hours. The report is divided in three parts: Header, Details and Summary. Here is an example of a Flat file a nd actual report Last Name (15)

First Name (15)

Week Number (1) Total Hours (3) Smith

Social Security (11)

Employee Header (Occurs Once, Required)

Date of Birth (8)

Hours Hourly Rate Worked (3) (3) Total Amount Summary (10) (Occurs once)

Client Site (20)

Work Description Weekly Details (40) (Multiple)

John

123-45-6789

102668

Houston Brewery Network Computers Network Computers DSP Systems

Beer Testing High level consulting

1 2

30 30

40 40

3

30

50

4

50 140

60 6900

Programming EDI Programming

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 COMPONENT Message Type 143680243.doc

NAMING CONVENTION Z

ACTUAL NAME ZEMP_MNT_RPT

Page 4 of 41


Idoc Type Segment Type

Z 01 Z

Outbound Function Module

Z_IDOC_OUTPUT_

ZEMP_MNT_RPT01 Z1EMP_HD, Z1WK_DET, Z1CL_DET, Z1SUMRY 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 IDoc’s. 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 ZEMP_MNT_RPT01

Employee monthly report

Z1EMP_HD

Employee header info

Z1WK_DET

Employee Weekly details

Z1CL_DET Client Details Z1SUMRY Monthly report summary

143680243.doc

Page 5 of 41

Information Technology •

• • •

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 b igger 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 Types

Description

CHAR CLNT CUKY DATS

Character String Client Currency Key, refrenced by CURR fields Date Field ( YYYYMMDD) stored as char(8) Language Key Character field with only digits Time Field (HHMMSS), stored as char(6)

LANG NUMC TIMS •

• • • • •

Fields should be left aligned. Character fields are a utomatically 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 Analysis

Analyze the data that needs to be exchanged between two systems. It is suggested that you follow a top-down approach if you are stating at a business-document level and a bottom-up approach at the field level. Break the document (fields functionally related) into segments. Group these fields into segments groups and arrange them in an IDoc type. Identify any parent-child relationship. After this you are now ready to build your basic IDoc type. Analysis of our Case brings out the following: • Report is divided into three parts: Header, Details and summary. Right away we know that we will need at least three segments. • Header and summary will have only one entry whereas week detail’s has multiple entries. • The weekly details can further be divided into two. → Week number, hours worked, hourly rate → Client site, work description

143680243.doc

Page 6 of 41


This is because an employee can work multiple times in the same client site but the reverse is not true. An employee can not work at multiple client sites at one time. • Here is an IDoc type representation of the flat file structure.

143680243.doc

Page 7 of 41


ZEMP_MNT_RPT01 Z1EMP_HD (M, 1,1)

LANME FNAME (10) (10)

Z1WK_DET (O, 1,99999)

WEEKNO (1)

Z1CL_DET (O, 1, 1) Z1SUMRY (O, 1, 1) M-Mandatory O-Optional

Minimum Maximum

IDoc Type

•

•

•

TOTHRS (3)

SSN (11)

DOB (8)

HRLYRT (3)

CLSITE (20)

WORKDESC (40)

TOTHOURS (3)

TOTAMNT (10)

Z1EMP_HD Z1WK_DET Z1CL_DET Z1SUMRY

Segments

There will be four segments that we will have to create. The header is made Mandatory because a Monthly report will not make sense without the employees basic information and also allows the reusability of the IDoc if only the Employee information needs to be sent out. The arrangement of the segments shows that there is a parent-child relationship between Z1WK_DET and Z1CL_DET. This signifies that the child segment cannot exist without the parent and is commonly used for text segments. Only Z1WK_DET is assigned to a maximum of 99999 range. This shows that this data record will occur multiple times. And Z1CL_DET is assigned once because it is dependent of the weekly detail.

1.2 Create Data Elements

In the previous step we analyzed our scenario and defined what needs to be created. In order to create segments we first need to make sure that all the required data elements exist. If SAP data elements do not match then we will need to create new ones. Only in rare situation a new elements needs to be created. Example: The Future Price field (ZKPRS) in the E1MBEWM segment uses data type CHAR 12 instead of ZKPRS. This is because ZKPRS is CURR (Currency) which is not allowed in a segment definition. (See 1.3 Create Segment for the formatting guidelines for segment) . 1. Go to transaction SE11. Enter the name for your data element, select the radio button for data type and click the command button for create.

143680243.doc

Page 8 of 41


2. Select the radio button for data element.

3. Enter a short text, either a domain or built in type and length. In the Field label give lengths and descriptions for your data type. Save.

143680243.doc

Page 9 of 41


1.3 Create Segment

We are now ready to create the segments as all the required Data Elements are already created. But first check if there are any existing that we can use. In our case we will have to create four new segments. Follow these steps to successfully create a new segment. (Please consult the guidelines above before attempting to create a new segment). Technically, a segment is implemented in three physically separate pieces. • Segment Type • Segment Definition See above for naming convention • Segment Documentation Steps to create a new segment

143680243.doc

Page 10 of 41


1.

Go to transaction WE31 (segment editor used to create or change a segment). Enter the name for your Segment Type (version independent) and click on the create button.

2.

Enter the Short text and the field with the appropriate Data Elements. Click on save and the system will automatically generate the Segment Definition (version dependent). It generally starts with Z2 and end with the version number.

3.

We will create the following four segments as above. Z1EMP_HD Z1WK_DET Z1CL_DET Z1SUMRY

1.4 Create Basic IDoc Type

Once all the necessary segments are created, you are ready to create the IDoc type. Follow these steps to create a Basic IDoc Type

143680243.doc

Page 11 of 41


1. Execute the transaction WE30. Enter a meaningful name for the IDoc type. (Consult the guide above). Click on create and a window will pop up to enter the description. Select the “Create new” option, enter the description and hit enter.

2. On the next screen: highlight the IDoc type and click on the create icon. This will allow you to enter the segment type and definite its attributes. Choose the appropriate values and press Enter. The system will transfer the segment type to the IDoc Editor. To add the next segment, highlight the last segment added and click on either same level or parent/child relationship depending on your design.

143680243.doc

Page 12 of 41


3. Once all the segments have been added, cick on save. This is what the screen looks like once all the segments have been defined.

1.5 Release the Segment Type and Basic IDoc Type

Once you are satisfied with your IDoc structure and Segment, you can release them formally to signify their completion. In order to release your IDoc Type, you will first have to release the individual segments and then the IDoc Type. Here are the steps for releasing Segments. 1. Go to transaction WE31. Enter the segment type you want to release. 2. Choose from the menu bar “EDIT”  “Set Release”.

3. Once this is done the gray check box is now checked. Repeat this for all the segments.

143680243.doc

Page 13 of 41


Similarly, release an IDoc type. 1. Go to transaction WE30. Enter the IDoc type you want to release. 2. Choose from the menu bar “EDIT”  “Set Release”.

3. The system will prompt you to confirm the release of the IDoc type. Confirm this and now you will not be able to make any changes to the IDoc Type. NOTE: You can cancel the release and modify the IDoc or the segment provided that you are still in the originally SAP System where these were created. To cancel the release, go to the menu bar “EDIT”  “Cancel Release”.

Outbound IDoc There are two paths to create an Outbound IDoc 1. Using Message Control (MC): Message Control is basically used to generate and manage various outputs from an application. It also controls their timing and medium of exchange. In other word it is a Function module controlling the circumstances under which a document will be sent. Example: • which document has to be sent • of which type is the document • when does the document have to be dispatched • which means of output is to be used Advantage of using MC is that it allows you to encapsulate business rules without having to write ABAP/4 Programs. MC is commonly used in the SD and MM Modules. To Learn more about Message Controls see chapter 8 of ALE,EDI, & IDoc Technologies for SAP by Arvind Nagpal.

2. Direct Outbound Processing: Here, the outbound processing path must be selected for R/3 components which are not linked to the Message Control module. You can develop custom programs to select the IDoc data and pass it directly to the ALE/EDI layer.

1) Programming in the IDoc Interface IDoc generation logic is carried out depending upon the use of a message control or not. For message control component, the IDoc generation logic must be placed in a function module. And for Direct processing you create a custom stand-alone report program. Message control is mostly used in the SD and MM module while FI, PP and HR do not use Message Control. Thus, to trigger the Outbound process for message control you need to create an interface for Function Module and without Message Control you will create a stand alone program. Prior to creating a FM, You must already have created a Developing Class and Function Group. This is required at the time of creating the FM, as this allocates the path for saving purposes.

143680243.doc

Page 14 of 41

Information Technology 1.1 Interface and Program Flow for Function Module.

Interface: IMPORTING Parameters: The following parameters are passed to the FM by the message Control Components: − CONTROL_RECORD_IN. This parameter is prefilled with information that is already known to the calling program. E.G: Sender system, receiving partner, IDoc type…. − OBJECT. This parameter is the NAST entry that contains the key of the document to be extracted. EXPORTING Parameters: the FM returns the following parameter to the calling program. − CONTROL_RECORD_OUT: This parameter has all the information filled out like the message type, IDoc Type, direction and receiver. TABLES Parameters: Has the data records filled by the FM. Data records are filled according to the sequence defined in the IDoc type. EXCEPTIONS: conveys any problems Program Flow: 1. Generally, you will declare the IDoc type, Message Type and segments in the Data Declaration part. Also need to declare the object key from the NAST entry. 2. Select the data you require from the DB tables. 3. Build the Control records: IDoc type, message type, partner type and number, and direction for the IDoc transmission 4. Build the Data Records. Populate the internal table. Example: We are going to use FM “Z_IDOC_OUTPUT_EMPMTHRPT” 1. Go to transaction SE37. Enter the FM name above and click on Create. 2. Define the interface as above. Write the program logic as follows. This program is broken down in the following parts: Definitions:  Define the segment name, IDoc Types and message type. Data Declaration:  − Declare a local internal table for Data records. e.g. fs_int_edidd like edidd −

Declare Local fields for all the segments. e.g. fs_emphd_data like Z1EMP_HD

−

Declare Local variables for the calculated fields. e.g. total_hrs_mnth type I.

−

The database tables used. e.g. zzempdet and zzempwkdet

−



143680243.doc

An internal table to hold all the weekly details –application data. e.g. it_wkdet like sempwkdet occurs 0 with header line

Program Logic:

Page 15 of 41

Information Technology −

−

−

Determine the objectkey from NAST entry and select data from the database using this as the criteria. Build the control record. Here you will define the following fields: Control_record_out-direct =’1’ (defines the direction of the Idoc. 1=outbound, 2=inbound) Control_record_out-mestype = Control_record_out-idoctp = < the IDoc type defined above > Control_record_out-rcvprt = ‘LS’ Control_record_out-rcvprn = ‘GDVCLNT200’ Build data record. Here for every segment, you first fill the segment, then fill the administrative section of the Local internal table for data record and last append this into the main internal table defined in the FM interface. Repeat this for all the segments. Here is an example of one * fill the employee header information FS_EMPHD_DATA-LNAME = ZZEMPDET-LNAME. FS_EMPHD_DATA-FNAME = ZZEMPDET-FNAME. FS_EMPHD_DATA-SSN = ZZEMPDET-SSN. FS_EMPHD_DATA-DOB = ZZEMPDET-DOB. *fill the administrative section of the data record FS_INT_EDIDD-SEGNAM = C_HEADER_SEGMENT. FS_INT_EDIDD-SDATA = FS_EMPHD_DATA.

*append the employee header data record to the IDoc data APPEND FS_INT_EDIDD TO INT_EDIDD. Once this is done. Save and check you work. If you are satisfied, then activate the FM by using the activate icon. 1.2 A stand-alone program to Generate IDocs.

1.

Go to transaction SE38. Enter a name (See the Global ABAP Naming standards) for your program and click on the create button. Program name is this example is ZZRAEMPMTHRPT 2. Give your program a short description and make it an Executable Program and assign it in the Development class you have created for the IDoc. 3. The program logic usually contains the following: − Provide a selection screen to allow a user to specify the various objects for which IDocs are to be generated. e.g: *object key (Social Security Number) PARAMETERS: P_SSN LIKE ZZEMPDET-SSN.

Determine the key of the application document from the object specified above. − Select application data from the database using the object key identified above. − Populate control record information. − Populate an internal table of type EDIDD with data records for the various segments. − Call the ALE service layer (MASTER_IDOC_DISTRIBUTE) to create the IDocs in the database. − Commit work. 4. Once this is done. Save and check you work. If you are satisfied, then activate the Program by using the activate icon. −

143680243.doc

Page 16 of 41


2) Configuring the system for Outbound IDocs After creating IDoc Type and the necessary programs, you need to configure the system to make these components known to the ALE/EDI interface layer. This settings are required only if you have created or changed Idocs or programs. 2.1 Steps for configuring an IDoc using Message Control.

1) Create a new Message Type i.

Go to transaction WE81. Click on the “Display/Change” Icon (

).

ii. Click on . iii. Enter name for the message type and give it a short description. Make sure the name is same as the one defined in your FM. Also see the na ming convention above. Click save. 2) Link the IDoc type to the Message Type i. Go to transaction WE82. Click on the “Display/Change” Icon. ii. Click on “New Entries”. iii. Enter data and click save.

3) Create a new process code: Another name for a specific process, for example function module or workflow. IDocs are read or written in this process. i. Go to transaction WE41. Click on the “Display/Change” Icon. ii. Click on “New Entries”. iii. Enter data and click save.

143680243.doc

Page 17 of 41


For Steps 4 to 7, To create any of these please refer to the Celestica Global ALE Configuration Guide. 4) Check the Logical System. Go to the IMG Basis  ALE  Sending and Receiving System  Logical System  Define Logical system. Check to see if the logical system that you want to send your IDoc to is defined here. In our case it is GDV200

5) Check the RFC Destination. Go to transaction SM59 and see if a remote connection has been defined for the receiving system. Test the connection to see if you are able to connect remotely.

143680243.doc

Page 18 of 41


6) Check for port. A port defines the medium in which the data is exchanged between the two systems. At least one port must exist for each external system. To give you a better idea, here is how IDocs are sent to two subsystems via three ports.

To check the port definition for the receiving system, go to transaction WE21. In our case it is A0000005.

7) Create or change a partner profile A partner profile is created for every partner system that sends or receives IDoc. Partner Profile has four major components that need to be defined. • Partner information • Agent • Outbound parameters • Inbound parameters Here is a graphical presentation of dependencies and important fields of partner profiles.

143680243.doc

Page 19 of 41


Usually on an existing Partner Profile, only the message type need to be defined in the outbound or the inbound parameters. The partner information and agents don’t change unless you are creating a new Profile. For our example we are going to send the IDoc to the GDV system. Here are the steps for adding a message type to an existing partner profile. i.

Go to transaction WE20 and get the profile for logical system GDV200.

ii. Click on the Icon for creating new outbound parameter . iii. On the following screen enter the Partner Function: specify the relationship (Logical System in our case) Message Type: ZEMP_MNT_RPT

Outbound option tag: Receiver Port: A000000003 (Xtricity) (need to define port if doesn’t exist) Output mode : select “transfer IDoc Immediately” & “Do not start subsystem” IDoc Type: Basic Type: ZEMP_MNT_RPT01 Post Processing: Permitted Agent tag : Type: US (User) Agent: PPATEL (your SAP user ID) Lang: EN (English) iv. Click save.

143680243.doc

Page 20 of 41


Congratulations! You have now completed the entire process of creating and configuring a new outbound IDoc. 2.2 Steps for configuring an IDoc using stand alone program.

Configuring the IDoc in this process is the same as above except for Step 3. Instead of creating a Process code, we have to add the message to the Customer Distribution table. So follow all the same step as above except for creating process code and do this following step after. 1.

Distribution model describes the ALE message flow between logical systems. It could be relationship between BAPIs or Message Types or a BAPI & Message Type. Follow these step to maintain relationships: i. Go to transaction BD64. ii. Look for a model view that corresponds to your requirement. If not then click on the “create model view” button. Enter a short description and technical name.

iii. Then click on “Add message type”. And the following window will pop up. Make the appropriate entries and click on sa ve. Sender is the sending system (ES1150), and receiver is the receiving system (GDV200). Save the model.

143680243.doc

Page 21 of 41


iv. Go to “Environment “ on the pull down menus and click on “Generate partner profile”. Enter the name of the model and click on “execute”.

(Note: The 2 snapshots above were taken during the execution of a different model, hence the values of model, message type and logical system are different)

3) Transporting the IDoc to the receiving system. Now you have to transport all the new objects you have created in this system to the receiving system. You also have to do the configuration for the port, RFC Destination, and the Partner Profile. Follow the step as above for all this. Remember you may not have to do any configuration if it is already existing, as this is usually a one time process. The only thing different is the Partner Profile configuration. Here you will add your Message type in the inbound parameters.

143680243.doc

Page 22 of 41


Inbound IDoc Inbound programs are also called Posting programs. They are designed to read IDoc data and post application documents. To create a new Inbound IDoc you will first need to follow the steps in the general definition above. (if you have created a new outbound IDoc in the sending system, the transport will take care of this step). There are two scenarios when programming for inbound Basic and Advanced. Each scenario is described in more details below.

1) Programming in the IDoc Interface 1.1 Basic Scenario: This is direct inbound processing via the ALE layer. It involves the following steps: 1. Creating a New Function Module Create a new Function module using the transaction SE37. The naming Convention to follow is same as outbound. Z_IDOC_INPUT_ e.g.: Z_IDOC_INPUT_EMPMNTRPT. Interface for most of the Inbound FM is preset by SAP and is the same for any of the two scenario Import parameters INPUT_METHOD

BDWFAP_PAR-INPUTMETHD

MASS_PROCESSING

BDWFAP_PAR-MASS_PROC

Describes how the function module is to be processed (example: in the background) Mass inbound processing? (flag)

Export parameters WORKFLOW_RESULT APPLICATION_VARIABLE IN_UPDATE_TASK CALL_TRANSACTION_DONE

BDWFAP_PAR-RESULT

Set to 99999 if a workflow event is to be triggered for error handling BDWFAP_PAR-APPL_VAR Variable freely available from application for workflow BDWFAP_PAR-UPDATETASK Asynchronous update? (flag is not set in example) BDWFAP_PAR-CALLTRANS Transaction called? (flag is not set in example)

Table IDOC_CONTRL

EDIDC

IDoc control record

IDOC_DATA

EDIDD

IDoc data records

IDOC_STATUS

BDIDOCSTAT

IDoc status records for ALE

RETURN_VARIABLES

BDWFRETVAR

SERIALIZATION_INFO

BDI_SER

IDoc assigned to workflow method parameters If several IDocs are to be processed in a certain sequence: this structure contains the necessary information

The function module should carry out the following steps: •

Check that the IDoc contains the correct message type (field Idoc_Contrl-Mestyp). If it does not, raise the exception Wrong_Function_Called with an appropriate message.

143680243.doc

Page 23 of 41

Information Technology o

When implementing an inbound function module for master data that can be "reduced" by customers, don’t check the message type; check the basic IDoc type instead (field Idoc_Contrl-Idoctp) Initialize/refresh any global variables and/or tables.

•

Initialize/refresh any global variables and/or tables. The inbound function module can be called a number of times by the same process, so the global variables will not be empty the second time around.

•

Convert the character data in table Idoc_Data to internal format in internal tables. See the example coding below to see how to do this. Special attention must be paid to fields containing: o

Units of measure (ISO code in IDoc)

o

Currency codes (ISO code in IDoc)

o

Country codes (ISO code in IDoc)

o

Shipping instructions (ISO code in IDoc)

o

Monetary amounts (conversion factor needed)

o

Dates and times (see below)

Fields containing dates and times can lead to errors during inbound processing when the field in the IDoc is empty (i.e. blank): In ABAP, moving a blank character field into a date field leaves the date field blank, rather than initial (all zeros) i.e. the date field ends up containing an invalid value. Errors will occur in subsequent processing whenever the field is checked for an initial value "if DateField is initial..." To avoid this, clear the date field if the IDoc field is empty, as shown in the example code. Remember: the function module should not do a Commit Work. If you have the choice, don’t update the database using Call Function "xxx" In Update Task - it is unnecessary for ALE inbound processing, and only increases database load. 1.2 Advanced Scenario Advanced scenario is basically an addition to the basic scenario that handles mass processing (multiple IDocs at the same time), serialization checks (sequence of the IDoc posted), advanced workflow programming (for raising application specific events) and enabling an existing transaction for ALE (when the same IDoc can’t be posted twice even in the worse case scenario).

2) Configuring the system for Inbound IDocs 1.

Maintaining the Attributes of a Function Module This step is to set the characteristics of the function module. Whether it is outbound or inbound. Go to transaction BD51. Click on New Entries and make an entry for your FM as individual input. Save.

143680243.doc

Page 24 of 41


2. Assigning a Function Module You can specify that the new function module may process the new basic type with a certain message. In addition, you assign an application object from the Business Object Repository (BOR) (such as employee) to the function module, which can transfer the application data from the IDoc to the application object. This step is the ALE registration for the function module. Go to transaction WE57 and click on “New Entries”. On the new window enter the following data.

143680243.doc

Page 25 of 41


3. Assigning a Process Code This enables the function module to be identified from the partner profiles defined in the IDoc Interface when an IDoc of the new message type is received. To do this, go to transaction WE42 (Inbound Process Code) and click on “New Entries”. Enter a process code and description and choose the Processing with ALE and Processing by function module options and save your entries. On the new window that pops up upon saving, enter your Function Module. This step is important for you to link your process code with your Function Module. Make entries and save.

Go back, via the back icon , to maintain the inbound process codes and choose the logical message navigation. In change mode choose “New Entries” .

Enter the message type (logical message) and the process code and save your entries. As a result, the value help (F4) in the partner profiles can display the possible process codes from the logical message, that is to say, the business view.

143680243.doc

Page 26 of 41


4.

Defining a Partner (Direct Inbound Processing) In inbound processing, define the new process code for inbound processing and exception handling for the basic type. Here you will enter the message type in the inbound process in the Logical System that you are receiving the IDoc from. To do this go to WE20 and click on the “Create inbound parameter” Icon in the Inbound Parameter.

Make the entries as below and save.

This completes your entire process of configuring the Inbound IDoc. The next step is to test your IDoc.

143680243.doc

Page 27 of 41


Testing IDocs The final step is to test your IDoc. 1. Go to transaction SE38 and execute your program in the sending system, ES1 client 150. 2. Enter the SSN number for the employee whose report you want to send, the message type and the targeted logical system. (These parameters are what you designed in your program. Some information like the message type and logical system can be hard coded.)

3. 4.

At the end of the program you will get the IDoc number corresponding to your request. Now go to transaction SE16 in the receiving system. Check the contents of the tables and see if they have been updated.

143680243.doc

Page 28 of 41


Monitoring IDoc Now that you have tested your IDoc, the next step is to monitor it. You can easily and effectively monitor inbound and outbound processing of IDocs using special reports and graphic displays.

Features The following tools are available for passive monitoring: 1)

IDoc Display This report generates a list of individual IDocs or, if you have restricted your selection to one IDoc using the available selection criteria, the report displays the relevant IDoc (for example, if you select only one IDoc number as a selection criterion). In addition to the selection criteria, which are also available in the other statistics programs (message, partner), you can select the following, more technical parameters: • IDoc type (basic type or basic type with extension) • Test option from the partner profiles (is the IDoc created and sent for test purposes only?) • Current status • Port (recipient and sender) • EDI reference numbers (interchange file, message, EDI archive – file card EDI selection). The individual IDoc is displayed as a tree structure. The initial node is the IDoc number. The control record, data and status records are displayed as subnodes. You can expand nodes and display individual records. To see your IDocs Now go to transaction WE02. And execute to get a list of all the IDoc processed. You will come to the following screen.

Double click on your IDoc. Example: 00000000000122003. You will now come to the following screen.

143680243.doc

Page 29 of 41


The IDoc is divided into three parts: I. Control Records: The control record displays, for example, the "letter header" (sender and recipient), direction and IDoc type. Value in control record is stored in EDIDC table II.

Data Record: In the case of the data records, the segment name , segment number and short text are displayed. Value in the data record is stored in EDID2/3/4 table (number signifies the release 3C, 3, 4 respectively.

III. Status Record: displays the individual status values (status) with a short text. 53 is the status number that tells us that the IDoc has been posted successfully. Expanding these numbers will give you more details. This is quite helpful when an error has occurred during the IDoc processing. Example: Below, status number 60 shows : “EDI: Syntax error in IDoc (segment cannot be identified)”.

Double click on the message and you will get the following screen with more details.

Values in the status record are stored in EDIDS table.

143680243.doc

Page 30 of 41

Information Technology 2)

IDoc List This report returns lists, if necessary in graphical format. The selection criteria are • The time (IDoc creation or last status change) • The message • The partners or also the separate identification for the partner • Technical parameters: IDoc number, IDoc type, current status, direction. The lists are displayed according to message type and status. You can display statistics for the time distribution of the IDocs with a specific status as a graphic. The time axis can be homogeneous (that is, the time progression is uniform) or IDoc-oriented (that is, only time intervals in which IDocs were created are selected). IDocs with an error status can be easily displayed via the status bar . Errors are shown in the IDoc list with the use of warning colors. The error message is displayed immediately as a short text and, if necessary, you can also call the long text to receive further information for troubleshooting. (The warning colors are assigned specific status groups in the standard system. All statuses in a specific status group have the same color. ) To get IDoc list go to transaction WE05.

143680243.doc

Page 31 of 41


IDoc Statistics The IDocs are sorted and represented graphically according to predefined status groups. The IDocs are grouped together according to their processing status for statistical purposes. The status groups shown in the table below are used here. Only those IDocs, which have undergone a status change within a defined period, are selected. Statistics status groups Outbound Generated Ready for dispatch Being transmitted (transferred to external (sub)system) Transmission successful (in target system) Completed in target system Error in IDoc interface Error in external system With deletion indicator

Inbound Generated transferred to application transferred to dialog

completed in application error in IDoc interface error in application with deletion indicator

To see the IDoc statistics, go to transaction WE07.

143680243.doc

Page 32 of 41


IDoc Search There are two ways to search for your IDoc, in the Database or in the archive. Archiving IDocs is discussed in more details in the next section. Searching in the Database is done from Transaction WE09.

143680243.doc

Page 33 of 41


Appendix A Creating a new development class. 1. Go to transaction SE80.

2. 3.

Choose “Development Class” from the drop down list. Enter a name for the Development Class. (see Celestica ABAP naming Standards, V1). e.g ZIDOC_EG 4. Click on the “Display” Icon . 5. You will get a message as follows

6.

Click on yes and make appropriate entries and save as local.

143680243.doc

Page 34 of 41


7.

Then next step is to create a Function Group in this Development class. Now highlight the new Development class in the “Left Window” and right click on it. You will get menu options as below.

8.

Choose create  function group.

9.

Make appropriate entries on the new window that pops up and save.

143680243.doc

Page 35 of 41


APPENDIX B

IMPORTANT TABLES

EDIDC

Control Records

EDIDS

Status Records

EDID2/3/4

Data Records (version 3c/3/4)

EDIMSG

Message Type and Assignment to IDoc

EDISDEF

IDoc Development: IDoc Segment definition

EDISEG EDISEGMENT

IDoc Segment with assignment to Segment type IDoc Segments

RFCDES

RFC Destinations.

143680243.doc

Page 36 of 41


APPENDIX C IMPORTANT TRANSACTION CODES Main Menus WEDI BALE SALE NACE IDoc Definition SE11 WE31 WE30 BD53 WE60 WE61 IDoc Monitoring WE02 WE05 WE07

Main menu for EDI-related activities Main menu for ALE-related activities. Main menu for ALE configuration. Main menu for Message Control configuration Data Dictionary Segment Editor IDoc editor to create and extend IDoc type Reduce IDoc for master data IDoc documentation (IDoc structure and segment definition) IDoc Documentation (control record, data record, and status records) IDoc Display IDoc Lists IDoc Statistics

Configuration (Basic Infrastructure for ALE & EDI) WE20 Maintain partner profile manually BD82 Generate partner profiles automatically WE21 Port Definition SM59 RFC Destination BD64 Maintain customer model BD71 Distribute customer model Testing WE19 WE12 WE16 WE17 Reprocessing IDocs BD88 BD87

Test tool for IDocs Convert an outbound to inbound IDoc. Process an incoming IDoc file Process an incoming status file Process outbound IDocs Process inbound IDocs

Configuration of New IDoc Components WE81 Create new message type WE82 Link IDoc type and message type WE41 Create outbound process code WE42 Create inbound process code WE57 Allocate inbound function module to message 143680243.doc

Page 37 of 41


BD51 BD67

143680243.doc

type Define settings for inbound function module Assign input methods for a process code (inbound)

Page 38 of 41

IDOC Development Procedures

Recommend Documents