idocs

[Former Member]

hi

pls send me the details of creation and modification idocs screen shots

outbound and inbound process(separately).

advance thanks to all

[Former Member]

HI..

Please look at the documentation..

It gives you a clear picture how to create, use IDOCS Inbound as well as outbound..

Also creation and using Inbound IDOC /Outbound IDOcs are shown in steps clearly.

read it you will understand and can do it on your own..

<b>IDoc Definition and Use</b>

An IDoc stands for ‘intermediate document’; it is a container for exchanging data between R/3, R/2 and non-SAP systems.

ALE (Application Link Enabling) uses IDocs to exchange data between logical systems. Non SAP-systems can use IDocs as the standard interface for data transfer.

IDocs are created by messages; a check is made on the message types that the sending and receiving operating systems allow. These are then used to process the IDoc.

An Idoc type specifies the structure of the data. A message type specifies the meaning of the data. An Idoc type must be assigned to a Message type so that the data in the Idoc is processed correctly.

An IDoc contains only character fields. However, the data elements within segments can be of any format as data is moved and automatically converted into a character field (EDID4-SDATA) before being transferred into the IDoc.

SAP has its own standard Idocs with segments containing certain fields. If an Idoc does not contain all of the required fields, it can be extended whereby additional segments are inserted into the Idoc.

Idocs can also be reduced. This is where they are modified to only include the data that is valuable to the receiving system. Note, Idocs can only be reduced for master data. Reduced Idocs cannot be used with Mercator.

If an SAP Idoc does not exist, custom Idocs are created.

<b>

IDoc Structure</b>

An IDoc is a configuration of an IDoc type that determines the IDoc structure.

IDocs consist of a Header, several Data Segments and Status Records.

The functions of the individual elements of an IDoc are as follows:

An Idoc has a control record that stores the characteristics of the Idoc. The contents, sender, receiver and current status of the IDoc are defined in this control record.

Table: EDIDC holds the Control record details.

There is one control record for each IDoc Structure.

Each Data Segment contains a standard header consisting of a sequential number, a description of the segment type and a 1000 character long string containing the actual data of the segment (field name = sdata).

Each IDoc must have at least one Segment. Secondary Segments are optional.

Table: EDID4 holds the IDoc Data Records.

This table will hold all records to be transferred into the IDoc. The number of records will equal the number of segments.

Note: The complete contents of the 1000 character field ‘sdata’ cannot be viewed unless the ‘List Width’ of the table is changed from 250 to 1023. This is done through transaction code SE11 when the table’s contents are executed.

<b>Status Records</b> show the history of the processing steps applied to the IDoc.

For example: the client, the time of creation, the user etc.

Table: EDIDS - Status Record (IDoc). - There can be multiple status records for each IDoc.

Table EDIDS does not need to be mentioned in the actual ABAP code.

Key Terms

<b>IDoc Type</b>

The IDoc type describes the technical structure of a message. It defines which segments will be used and what is the hierarchical structure of the segments. For each segment it also specifies whether it is mandatory or optional and how many times the segment may appear in the IDOC.

<b>MESSAGE Type</b>

The Message Type describes the contents of the ‘sdata’ field in the data structure that is passed to the function module ‘Master Idoc Distribute’. It passes the information to the FM on how to populate data into the segments of the Idoc.

SECTION 2. Steps to Creating a Customised IDOC

(see Appendix III for Screenshots of Steps)

<b>2.1 Outbound Interface</b>

PROCESS DIAGRAM

Outbound Interface

1. Analyse Hierarchy Levels

2. Create New segment

3. Create New IDoc Type

4. Create New Message Type

5. Link Message with IDoc Type

6. Create an entry in EDP13 via transactions WE20 and BD64

7. Populate the Custom IDoc via ABAP Program

7b Error Handling

7c. Send Status Email

8. Test the Population of the Custom IDoc

<b>Step 1 – Analyse Hierarchy Levels:</b>

Analyse the data relationships being processed in the interface. Define the appropriate hierarchical Parent-to-Child relationships.

Navigate to transaction code WEDI

Transaction WEDI displays the IDOC main menu. This allows navigation around the various development and control areas to create a customised IDOC.

<b>Step 2 – Create a new segment:</b>

via wedi : Development - IDOC Segments or Transaction code WE31.

Enter segment name and click on Create.

The name of the segment type must start with Z11, and have a maximum of eight characters.

Enter description and enter the relevant field names and data elements.

The segment should represent a structure in the program so for each field in the segment a field name and a data element must be defined.

Save the segment and enter Person Responsible and Processing Person2.

Go to Edit and Set Release.3

Repeat this procedure for each new Segment in the IDOC.

<b>

Step 3 – Create a new IDOC Type</b>via wedi Development - IDOC Types or Transaction WE30.

Enter segment name (starting with Z), click on Basic Type and then Create.

Create as new, enter Person Responsible and Processing Person4 and enter description.

On ‘Create Basic Type’ screen decide where segments should be inserted and go to Edit/Create Segment.

Complete relevant fields in the Maintain Attributes screen:

From the relevant segments created in Step 2 enter the Segment type and if mandatory segment.

The Minimum and Maximum number of segments to be allowed in the sequence. (One minimum and one maximum if segment is mandatory).

The Parent Segment and Hierarchy Level will be automatically created depending on where in the IDOC tree you decided to create that particular segment.

Repeat this process for each segment needed in the IDOC type, deciding whether to add the next segments at the same level or as a ‘Child’.

When IDOC created return to initial screen. Go to Edit and Set Release.

Go to Transaction WE60 to view the IDoc Type you have created.

<b>Step 4 – Create new Message Type</b>

via wedi Development - Message Types or Transaction WE81.

Display/Change and click on New Entries

Create a new Message Type and Save.

<b>Step 5 – Link Message Type to IDOC Type</b>

via wedi Development - IDOC Type/Message or Transaction WE82.

Display/Change and then click on New Entries.

Enter Message Type, Basic Type (IDOC Type) and Release (46C) and Save.

<b>Step 6 – Create an entry in EDP13 via transactions WE20 and BD64.</b>

The partner profile for the Idoc must be set up and generated in the transaction BD64 and transaction WE20.

WE20 – Add Message Type to appropriate Partner Type, Enter Message Type, Receiver Port and Idoc Type and Save.

BD64 – Create a Model View, Enter Sender and Receiver Ports, Attach Message Type. Go to ‘Environment’ on Menu and click on Generate Partner Profiles and generate (not save) profile.

<b>Step 7 – Populate the custom IDOC via ABAP Program</b>

See Test Program ZOUTBD_IDOC_TEMPLATE, Appendix IV.

Create an Internal Table for each segment type, this should be exactly the same structure as the segment type.

The control record is filled into a structure like EDIDC. The message type and the Idoc type for the Idoc must be populated into the eddic structure.

- PERFORM populate_Control_structure USING c_mestyp

c_SEGMENT_type1.

The data segments are filled into a structure like edidd-sdata; sdata and the segment name are populated into the edidd structure.

- PERFORM transfer_Parent_data_to_seg.

The standard SAP function module MASTER_IDOC_DISTRIBUTE is called to pass the populated IDOC to the ALE Layer.

- PERFORM master_idoc_distribute.

NOTE: This function module is only called for stand alone programs and Shared Master Data programs (SMD). It is not called when using extensions or output determination.

The ALE Layer handles the sending of the IDOC to the receiving system.

Error Handling (see Step 7b).

Commit work.

Project Specific

<b>Step 7b – Error Handling</b>

Analyse which fields in the interface are mandatory for the receiving system and who needs to receive error notification.

Declare a structure of type ‘MCMAILOBJ’ for sending instructions.

Enter values for the internal table based on structure ‘MCMAILOBJ’5

For selection processes, on SY-SUBRC checks and where fields are mandatory for the receiving system; insert Function Module ‘MC_SEND_MAIL’.

Enter values in the following parameters: -

MS_MAIL_SENDMODE = ‘B’ (Batch Mode)

MS_MAIL_TITLE = 'Mail Title'

MS_MAIL_DESCRIPTION = ‘Error description’ (e.g. MATNR not given)

MS_MAIL_RECEIVER = ‘Name of Receiver’ (To be determined)

MS_MAIL_EXPRESS = ‘E’ (Express Delivery)

MS_MAIL_DLINAME = Leave Blank

MS_MAIL_LANGU = 'E' (Language)

MS_MAIL_FUNKOBJ_NAME = Leave Blank

TABLES

MS_MAIL_CONT = I_MCMAILOBJ

Note:

It has to be determined separately for each interface how these errors and mail notifications are to be grouped – dependant upon the number of errors that are potentially likely. One possible approach is to send an email for each reason for rejection and include all the records that failed for that reason in the mail notification. Another possible approach is to send an email for every failure.

When error checking for mandatory fields it is common SAP practice to reject a record on its first failure (irrespective of subsequent errors in that record)

<b>Step 7c – Send status mail</b>

Append to table I_MCMAILOBJ details of the time the interface was processed, how many Idocs were created and how many of these produced a status of 03.

Select the user to receive the mail from ZINT_RECEIVER, using the name of the program as a key (SY-CPROG).

Use function Module ‘MC_SEND_MAIL’ to send a mail to the user containing the contents of I_MCMAILOBJ at the end of the interface processing.

<b>Step 8 – Test the population of the custom IDOC</b>

via wedi IDoc - Display IDoc or Transaction WE02.

Enter your message type and execute.

Status should be green, double click on one of the Idocs you have created to view its contents.

If a problem has occurred click on Status which will give you a description of the error.

Drop down Data Records arrow and this should list the data in the IDoc in the correct hierarchical structure.

Click on each individual segment and view the content to check that the correct data has been read.

If you have UNIX access by using AL11 you can view the file that you have created.

Note:

For some interfaces it may be valid to send an empty file to SAP. This empty file is converted to the custom IDOC format expected by SAP. This custom IDOC will contain dummy information. In the inbound processing code, if the dummy information is identified then the processing of the IDOC is considered to be complete and the IDOC should then be assigned a successfully processed status of 53, even though it has not been processed at all.

<u><i><b>2.2 Inbound Interface</b></i></u>

<b>Follow steps 1 to 5 inclusive as detailed above.</b>

<b>Step 6</b>

Write a custom function module to handle custom inbound processing. This custom function module must

Check for the correct message type

Read the IDoc data segment

Perform data conversion and validate the data as appropriate

Post the data to the database

Handle any error situations

Set the correct return values for the status record

Note that the Function Module must not make a commit to the database. This is because the status record is not written until control returns to the ALE layer. So if you commit work in the Function Module and an error occurs in returning to the ALE Layer, the status record must not be updated with a successful outcome.

The commit work is executed in the ALE Layer after the status records are updated, via the standard SAP function module IDOC_INBOUND_PROCESS. This attributes of this function module are set up in (Transaction BD51), click on ‘New Entries’ and fill in data; the main input parameters being ‘Input Type’ and ‘Dialog Allowed’.

Take care as some standard SAP transactions contain a Commit Work as part of their processing. Therefore using a BDC to process inbound data to SAP may not be acceptable. You need to check that the SAP transaction is ALE enabled.

<b>Step 7</b>

(Transaction WE57)

Assign the custom function module to the IDoc type and the message type.

Set function module to type ‘F’ and direction ‘2’ for inbound.

<b>Step 8</b>

(Transaction WE42)

Create a new process code and assign it to the function module. The process code determines how the incoming IDoc is to be processed in SAP.

<b>Step 9</b>

(Transaction BD67)

Assign the function module to the process code created above. Got to ‘New Entries’ and enter the process code and the function module name.

<b>Step 10

(Transaction</b> WE20 and Transaction BD64)

Create a partner profile for your message and ensure that in transaction WE20 the process code is the one that points to your function module. (See step 6 of creating Outbound Idocs).

<b>Step 11</b>

Ensure that error handling functionality is present.

<u><i><b>Note:</b></i></u>

If an interface is expecting a file every day, and a custom IDoc may only be output from SAP periodically, it would be necessary to create some kind of output from SAP on a daily basis to pass to Mercator to allow it to map to an empty file. As we are dealing with custom IDoc types we can design the IDoc so that the data segments are not mandatory. Therefore the SAP program, on finding no data to populate the custom IDoc, would only need to create the control record. The empty IDoc containing the control record would be passed to Mercator. Mercator will map this to an empty file format.

<b>Useful Transaction Codes:</b>

WEDI : IDoc Menu

WE02 : IDoc List (can enter IDoc number to select on)

WE05 : IDoc List

WE19 : Transaction WE19 can be used to test the IDoc

WE30 : IDoc Type Development: Initial Screen

WE31: Development Segments: Initial Screen

WE60 : Documentation for IDoc Types. This allows you to view the IDoc you have created.

WE81 : Display View ‘EDI: Logical Message Types’: Overview

WE82: Display View ‘Message Types and Assignment to IDoc Types’: Overview

rewards if useful,

regards,

nazeer

[Former Member]

Hi,

Check the following links:

http://www.sapbrainsonline.com/TUTORIALS/TECHNICAL/IDOC_tutorial.html

http://sapmaterial.com/idoc_sample.html

Regards,

Bhaskar