Download doc - IDOC Development Procedures1

Information Technology

IDoc Template

SAP Development Architecture

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


Document Revision History

Date Version Author Change Description

document.doc Page 1 of 41


Table Of ContentsIntroduction to IDocs...............................................................................................................3Structure of an IDoc.............................................................................................................................. 3

GENERAL DEFINITION.............................................................................................................................. 41) CREATING A NEW IDOC................................................................................................................... 5

OUTBOUND IDOC.................................................................................................................................... 131) PROGRAMMING IN THE IDOC INTERFACE.........................................................................................132) CONFIGURING THE SYSTEM FOR OUTBOUND IDOCS........................................................................163) TRANSPORTING THE IDOC TO THE RECEIVING SYSTEM....................................................................21

INBOUND IDOC........................................................................................................................................ 221) PROGRAMMING IN THE IDOC INTERFACE.........................................................................................222) CONFIGURING THE SYSTEM FOR INBOUND IDOCS............................................................................23

TESTING IDOCS....................................................................................................................................... 27

MONITORING IDOC................................................................................................................................. 28

APPENDIX A............................................................................................................................................. 33

APPENDIX B............................................................................................................................................. 35

APPENDIX C............................................................................................................................................. 36

REFERENCES.......................................................................................................................................... 38



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 processes systems, which can understand the semantics and syntaxstructure 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.

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 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.IDoc’s 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 and segments 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 –o IDoc number,o the sender and recipient information, o information such as message type it represents, o IDoc type,o 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 achieves goes through different stagesdifferent milestones. A status code, date and time are assigned at every milestonestage. 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 can 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 DefinitionWhen 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 process3) Setup: Configure the EDI components and build the necessary Master Data.4) Testing: test the setup phase.5) Execution: Execute the process6) 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 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)

Smith John 123-45-6789 1026681 30 40 Houston Brewery Beer Testing2 30 40 Network

ComputersHigh level consulting

3 30 50 Network Computers

Programming

4 50 60 DSP Systems EDI Programming140 6900

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 NAMING CONVENTION ACTUAL NAMEMessage Type Z<Meaningful name> ZEMP_MNT_RPT


Employee Header(Occurs Once, Required)

Weekly Details(Multiple)

Summary (Occurs once)


Idoc Type Z <Message Type> 01 ZEMP_MNT_RPT01Segment Type Z <Data structure> Z1EMP_HD, Z1WK_DET, Z1CL_DET,

Z1SUMRYOutbound Function Module

Z_IDOC_OUTPUT_<MT> 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 <meaningful name> <version number>

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 <meaningful name>

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


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 Types DescriptionCHAR Character StringCLNT ClientCUKY Currency Key, refrenced by CURR fieldsDATS Date Field ( YYYYMMDD) stored as

char(8)LANG Language KeyNUMC Character field with only digitsTIMS Time 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 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

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.





ZEMP_MNT_RPT01

Z1EMP_HD (M, 1,1)

Z1WK_DET (O, 1,99999)

Z1CL_DET (O, 1, 1)

Z1SUMRY (O, 1, 1)

M-Mandatory MinimumO-Optional Maximum

IDoc Type 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 ElementsIn 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.


LANME FNAME SSN DOB (10) (10) (11) (8)

WEEKNO TOTHRS HRLYRT (1) (3) (3)

CLSITE WORKDESC (20) (40)

TOTHOURS TOTAMNT (3) (10)

Z1EMP_HD

Z1WK_DET

Z1CL_DET

Z1SUMRY


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.



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 Segment Documentation

Steps to create a new segment


See above for naming convention


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



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.



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 TypeOnce 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.



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 IDocThere 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 InterfaceIDoc 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.



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 transmission4. 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

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

Program Logic: 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 = <the message type defined above>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 informationFS_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 recordFS_INT_EDIDD-SEGNAM = C_HEADER_SEGMENT.FS_INT_EDIDD-SDATA = FS_EMPHD_DATA.

*append the employee header data record to the IDoc dataAPPEND 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.



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 naming convention above. Click save.

2) Link the IDoc type to the Message Typei. 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.



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.



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 profileA 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.



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.



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 save. Sender is the sending system (ES1150), and receiver is the receiving system (GDV200). Save the model.



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.



Inbound IDocInbound 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 Interface1.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_<Message Type>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 parametersINPUT_METHOD BDWFAP_PAR-INPUTMETHD Describes how the function module is to

be processed (example: in the background)

MASS_PROCESSING BDWFAP_PAR-MASS_PROC Mass inbound processing? (flag)

Export parametersWORKFLOW_RESULT BDWFAP_PAR-RESULT Set to 99999 if a workflow event is to be

triggered for error handlingAPPLICATION_VARIABLE BDWFAP_PAR-APPL_VAR Variable freely available from application

for workflowIN_UPDATE_TASK BDWFAP_PAR-UPDATETASK Asynchronous update? (flag is not set in

example)CALL_TRANSACTION_DONE BDWFAP_PAR-CALLTRANS Transaction called? (flag is not set in

example)TableIDOC_CONTRL EDIDC IDoc control recordIDOC_DATA EDIDD IDoc data records

IDOC_STATUS BDIDOCSTAT IDoc status records for ALE

RETURN_VARIABLES BDWFRETVAR IDoc assigned to workflow method parameters

SERIALIZATION_INFO BDI_SER 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.

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 ScenarioAdvanced 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 IDocs1. 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.



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.



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.



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.



Testing IDocsThe 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. At the end of the program you will get the IDoc number corresponding to your request. 4. Now go to transaction SE16 in the receiving system. Check the contents of the tables and see if they

have been updated.



Monitoring IDocNow 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. FeaturesThe following tools are available for passive monitoring:

1) IDoc DisplayThis 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.



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.



2) IDoc ListThis 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.



3) IDoc StatisticsThe 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 groupsOutbound InboundGenerated GeneratedReady for dispatch transferred to applicationBeing transmitted (transferred to external (sub)system)

transferred to dialog

Transmission successful (in target system)Completed in target system completed in applicationError in IDoc interface error in IDoc interfaceError in external system error in applicationWith deletion indicator with deletion indicator

To see the IDoc statistics, go to transaction WE07.



4) IDoc SearchThere 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.



Appendix ACreating a new development class.1. Go to transaction SE80.

2. Choose “Development Class” from the drop down list.3. Enter a name for the Development Class. (see Celestica ABAP naming Standards, V1).

e.g ZIDOC_EG4. 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.



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.



APPENDIX B

IMPORTANT TABLES

EDIDC Control Records

EDIDS Status RecordsEDID2/3/4 Data Records (version 3c/3/4)EDIMSG Message Type and Assignment to IDocEDISDEF IDoc Development: IDoc Segment definition

EDISEG IDoc Segment with assignment to Segment type

EDISEGMENT IDoc SegmentsRFCDES RFC Destinations.



APPENDIX CIMPORTANT TRANSACTION CODES

Main MenusWEDI Main menu for EDI-related activitiesBALE Main menu for ALE-related activities.SALE Main menu for ALE configuration.NACE Main menu for Message Control

configuration

IDoc DefinitionSE11 Data DictionaryWE31 Segment EditorWE30 IDoc editor to create and extend IDoc typeBD53 Reduce IDoc for master dataWE60 IDoc documentation (IDoc structure and segment definition)WE61 IDoc Documentation (control record, data record, and status

records)

IDoc MonitoringWE02 IDoc DisplayWE05 IDoc ListsWE07 IDoc Statistics

Configuration (Basic Infrastructure for ALE & EDI)WE20 Maintain partner profile manuallyBD82 Generate partner profiles

automaticallyWE21 Port DefinitionSM59 RFC DestinationBD64 Maintain customer modelBD71 Distribute customer model

TestingWE19 Test tool for IDocsWE12 Convert an outbound to inbound

IDoc.WE16 Process an incoming IDoc fileWE17 Process an incoming status file

Reprocessing IDocsBD88 Process outbound

IDocsBD87 Process inbound

IDocs

Configuration of New IDoc ComponentsWE81 Create new message typeWE82 Link IDoc type and message typeWE41 Create outbound process codeWE42 Create inbound process codeWE57 Allocate inbound function module to message



typeBD51 Define settings for inbound function moduleBD67 Assign input methods for a process code

(inbound)



REFERENCES

1. ALE,EDI, & IDoc Technologies for SAP by Arvind Nagpal

2. SAP Online Documentation Release 4.6C (CD)

by SAP
