ALE/IDOC

[Former Member]

Hello....

Please tell me about

1. metohds of trigaring idocs

2. how to create our own idoc and extended idocs

regards

basavaraj

[Former Member]

Hello....

Please tell me about

1. metohds of trigaring idocs

2. how to create our own idoc and extended idocs

regards

basavaraj

[Former Member]

Hi Basavaraj,

Check the below thread. May help you.

Regards,

Atish

[Former Member]

Hi,

1. Methods of trigering IDocs

You can set the inbound and outbound partner profile to trigger immediately or process by background job. For inbound, you can schedule to run program RBDAPP01 and RSEOUT00 for outbound.

2. How to create our own idoc and extended IDocs

1) Create segment (WE31)

Of course it will have naming convention for different company. Here are some tips:

If you copy from existing or std segment eg: Z1E1EDP01_01.

If not you can just put Z1….but this is only the example.

2) Create IDOC Types (WE30)

3) Create message type (WE81)

4) Link message type with basic type (WE82)

5) Create FM

In the FM all the attributes should be the same for Inbound or Outbound. Basically you can get an example from the std FM eg: Inbound - IDOC_INPUT_DELVRY

Outbound - IDOC_OUTPUT_SHPMNT.

6) Create Process Code (Inbound - WE41/ Outbound - WE42)

IMPORTANT: Before you key in the FM, you are required to add the FM in this table V_TBD51.

7) Link FM with Basic Type

For testing go to WE19.

Regards,

Ferry Lianto

[Former Member]

Hi Basavraj,

Application Linking and Enabling (ALE)

In this document you will learn the step-by-step procedure to setup the ALE system and go through a transaction between two clients

For our purpose we have two clients

namely Client 100 and Client 200.

System name is SAPKDC (FOR BOTH 100 AND 200 CLIENTS).

Distribution of Material Master Data Between two Systems

1) SETUP LOGICAL SYSTEM: (Note: Do Not Create This Step)

To do this follow the following steps

Execute SALE Transaction Code

On The Screen Click on Sending and Receiving Systems.

Then Click on Logical Systems.

Then Click Defining Logical Systems.

Click New Entries Button

(E.g. (LG100 sending system)

(LG200 receiving system))

Enter two logical system names and their description.

Save

Comeback to SALE Transaction Code screen.

2) Now you have to allocate the created logical systems to respective clients.( Note: Do Not Create This Step)

LG100 assign to client 100

LG200 assign to client 200

To do this, do the following.

Click Assigning Client to Logical System.

Ignore the message that comes up on the screen.

Select client 100

Click details button on the toolbar icon or press F2.

In the logical system box, enter LG100.

Click on the save Icon

Click the back button.

Now select client 200.

Click details icon or press f2.

In logical Systems box, enter LG200.

Save

Back.

Comeback to SALE Transaction Code screen.

3) Maintain RFC Destination: (TR.CODE:SM59)

(Note: Do Not Create This Step)

Click Create Button on the Screen

On the Screen Maintain RFC Destination i.e LG200.

Enter LG200 in RFC destination box.

Connection type is 3

Give a description for the RFC destination.

Maintain Technical Settings on Details on Technical Settings tab

Target Host as : SAPKDC (NOTE: Save it as a Host Name)

Maintain Logon Details on Logon/Security tab.

Language: EN.

User: MMUSER200 (This is the logon for dist.)

Client : 200

Password: MM1234.

Save.

Click on create to do the above process for Client 200 in

The client 200 system.

4) Maintain Distribution Model.(BD64). (ABAPer role starts here)

Execute Maintain distribution model directly for

creating the model.

Click on change mode button on App tool bar of the Screen.

Create Model View pushbutton on App tool bar of the Screen.

A pop screen will appear in which you specify

Short text as Distribution for MM Data.

Enter Technical Name as LGMODEL.

Select Model View and Click on Add Message Type Pushbutton on App toolbar of the Screen.

A popup screen will appear in which you specify

Model View as LGMODEL.

Sender as LG100.

Receiver as LG200.

Again Click on Add Message Type Pushbutton on App toolbar of the Screen.

A popup screen will appear in which you specify

Model View as LGMODEL.

Sender as LG200.

Receiver as LG100.

SAVE.

On the same screen goto Menubar and select Environment.

And then select Generate Partner Profiles , then execute it.

On the Screen specify the Logical System as LG200.

Then execute the screen.

Click back.

Again On the same screen goto Menubar and select EDIT.

Again select Model View and then select Distribute.

****LOGIN to client 200.

Execute Tr.code BD64 and again On the same screen goto Menubar and select Environment.

And then select Generate Partner Profiles , then execute it.

On the Screen specify the Model View as LGMODEL

And Specify the Logical System as LG100.

Then execute the screen.

Click back.

*******Switch back to client 100 Session.

5) Create Material using MM03 Tr.Code.

Enter the material name as LGMATERIAL

Industry sector as Mechanical Engineering

Material Type as Finished Products.

And then Click on Data Pushbutton on the App tool bar.

Select views.

In the select views box for materials check basic data 1 AND 2.

Click enter icon.

In the next screen that you get

Give the text of the material as NEW MATERIAL.

Base unit of measure as KG.

Gross Weight as 200.

Net Weight as 100.

Weight Unit as KG.

In the description area language (E) and material description.

Click Save.

Now I Created a Material in Client 100 , I want to transfer this data to Client 200.

6) Execute BD10 to transfer the material in which you specify

the material as LGMATERIAL and

message type as MATMAS (client100).

Then a Screen will be displayed in which it shows that

1 Master Idoc Generated .. Enter

1 Communication Idoc Generated..Enter.

*******LOGIN to Client 200.

7) Execute BD11 to get the material in which you specify

the material as LGMATERIAL and

message type as MATMAS (client200).

😎 Execute Tr.code MM03 and give the material as LGMATERIAL

and see that the material is displayed as it was in Client 100.

If not follow these steps.

9) Execute Tr.code WE19( for rectification of errors in client200).

Specify the Existing Idoc Number and Executes it .

A Screen is displayed in which you specify the corresponding Function Module as INPUT_IDOC_MATMAS01 and execute it.

10) Execute Tr.code MM03 and give the material as LGMATERIAL

and see that the material is displayed as it was in Client 100.

Now the Material is correctly displayed in Client 200.

11) Monitoring of IDOCS.

Transaction Codes:

IDOC Display of Status: WE 05.

IDOC Date and Time: WE07.

Do the following steps, idoc will trigger automatically.

If you need additional logic you have write user exit.(for first step you don't need coding).

Go to NACE and select V2 and click output type from menu.

Give following value.

Condition component Value

Access sequence 0005 (sales organization/customer)

Condition 0 (no condition)

“Exclusive” select

Output type LAVA (shipping notification outbound)

Procedure V10000 (shipping output)

Application V2 (shipping)

Processing subroutine Program RSNASTED,

form routine EDI-PROCESSING

General data Select Condition access and Multiple sending of output, otherwise

leave the fields blank

Time e.g. 4 (immediately, IDocs are generated immediately after

posting)

Transmission medium 6

Partner function WE

Language DE (German)

You must maintain following values for outbound partner profile.

Message type : Desadv

Partner type : Ku

Partner function : WE

Port : Subsystem

Outbput mode: Collect idoc

Basic type : Delvry01

Packet size: 1

Application: V2

Output type : LAVA

Process code: DELV.

You can post the delivery by selecting Logistics ??Sales and Distribution ??Shipping, Delivery

-->Create (transaction VL01). Output control is used to find the condition record and the shipping

notification is sent to the customer via EDI (IDoc Interface). The shipping time in the condition

record determines when the corresponding outbound IDoc is generated

On the Create Condition Records (Outg. ship notifica.): Fast Entry screen:

-->Enter customer number in Customer, SAP Ship-to # .

-->Enter WE in PartF.

-->Enter 6 in Medium.

-->Enter 4 in Time.

-->Enter EN in Language.

-->Choose Save.

<b>Reward pts if found usefull :)</b>

Regards

Sathish

[Former Member]

Hi,

Basic IDOCs have supplied by SAP with standard structure. (Segments). You can extend them with your own segments.

IDOCs does have unique number. They contain control, data, and status records.

Useful Transaction Codes:

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

WE21 - Creation of POrt

WE20 - Partner Profile creation

SALE - ALE (Application Linking and Enabling) settings

For Outbound ALE Configurations: (Example)

IDoc definitions and necessary ALE configurations settings for the outbound .

Create Idoc segments – Transaction WE31.

Create Idoc type – Transaction WE30.

Create Message Type – Transaction WE81.

Assign Message Type to Idoc type – Transaction WE82.

Create a distribution Model - Transaction BD64

An IDoc is simply a data container that is used to exchange information between any two processes that can understand the syntax and semantics of the data...

1.IDOCs are stored in the database. In the SAP system, IDOCs are stored in database tables.

2.IDOCs are independent of the sending and receiving systems.

3.IDOCs are independent of the direction of data exchange.

The two available process for IDOCs are

Outbound Process

Inbound Process

AND There are basically two types of IDOCs.

Basic IDOCs

Basic IDOC type defines the structure and format of the business document that is to be exchanged between two systems.

Extended IDOCs

Extending the functionality by adding more segments to existing Basic IDOCs.

for creating a IDOC

see the below steps for outbound processing IDOCS..

2.1 Outbound Interface

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

Step 1 – Analyse Hierarchy Levels:

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.

Step 2 – Create a new segment:

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

• Enter segment name and click on Create.

The&#61662; name of the segment type must start with Z1 , 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&#61662; each field in the segment a field name and a data element must be defined.

• Save the segment and enter Person Responsible and Processing Person .

• Go to Edit and Set Release.

• Repeat this procedure for each new Segment in the IDOC.

Step 3 – Create a new IDOC Type

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

Step 4 – Create new Message Type

via wedi Development - Message Types or Transaction WE81.

• Display/Change and click on New Entries

• Create a new Message Type and Save.

Step 5 – Link Message Type to IDOC Type

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.

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

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.

Step 7 – Populate the custom IDOC via ABAP Program

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 SpecificStep 7b – Error Handling

• 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’

• 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)

Step 7c – Send status mail

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

Step 8 – Test the population of the custom IDOC

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.

2.2 Inbound Interface

Follow steps 1 to 5 inclusive as detailed above in outbound interface.

Step 6

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.

Step 7

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

Step 8

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

Step 9

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

Step 10

(Transaction 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).

Step 11

Ensure that error handling functionality is present.

Note:

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.

Update outbound parameters of the Partner profile – Transaction WE20

For the Logical system A for the above two message types update the partner profile.

For each message type specify the Port and the IDoc types.

( Note : Port definition need to maintained using transaction WE21 and

it has to be defined as a Transactional RFC port with RFC destination for

system specified, which need to be maintained using SM59 ).

http://www.allsaplinks.com/idoc_sample.html

http://www.sapgenie.com/sapedi/idoc_abap.htm

Go through the link for basics related to IDOCs:

http://help.sap.com/saphelp_nw04/helpdata/en/0b/2a6cdd507d11d18ee90000e8366fc2/plain.htm

Regards

[Former Member]

Hi,

Methods of triggering idocs are:

1.Message control.

2.Change pointers.

3.Application specific change programs.

4.BTE(Business Transaction Events).

For methods of triggerring refer follwing link:

<a href="http://www.dataxstream.com/doclib/SAP%20Interface%20Design.pdf">http://www.dataxstream.com/doclib/SAP%20Interface%20Design.pdf</a>

<b>ALE/IDOC</b>

IDOC Programming

There are two processes in IDOC processing one is INBOUND PROCESS( IDOC coming to the system and its handling at various stages) and the other is OUTBOUND PROCESS( IDOC is send to other system . Separate ABAP programs are written for these 2 processes and different configuration settings are required for each one .Depending upon the trigeering mechanism different programming approaches are used.OUTBOUND PROGRAMS handle the IDOC creation and INBOUND PROGRAMS handle the inbound IDOC and the data trasfer from the IDOC to the database tables.

NEED FOR ABAP PROGRAMMING arises if

1)New IDOC was created

Depending upon the triggering mechanism i.e change pointer,message control

etc the programming technique changes and the type of process.

2)Existing IDOC was extended

User Exits are used to populate data in new segments added and to read them

back.

3)To enhance an exsiting process.

User Exits are used .

Basic structure of an OUTBOUND PROGRAM

The basic structure of all outbound programs is same. The CONTROL

record which is of TYPE EDIDC has to be filled. It contains important fields like

IDOCTP IDOC type

MESTYP Message Type

RCVPRN Recieving Partner (Destination)

RCVPRT Partner Type (it is LS i.e Logical System)

The DATA RECORD internal table which is of TYPE EDIDD has to be filled

in the same order as there are segments in the IDOC definition.

It has 2 important fields which are to be filled ,these are

SEGNAM Name of the segment

SEGDATA Data in the segment and can be upto 1000 bytes.This field

is corresponds to each data segment in the IDOC.

e.g.

DATA INT_EDIDD LIKE EDIDD OCCURS 0 WITH HEADER LINE.

DATA W_SEGDATA LIKE zsegment "custom segment zsegment

INT_EDIDD-SEGNAM = 'ZSEGMENT'

W_SEGDATA-field1 = value "taken from some table

W_SEGDATA-field2 = value "taken from some table

INT_EDIDD-SEGDATA = W_SEGDATA

APPEND INT_EDIDD

This will fill the data record corresponding to the segment ZSEGMENT . For all

segments the sam steps will be repeated until all the data corresponding to all the

segments in the idoc is filled in the internal table of type EDIDD.

There is only one control record and can be multile data records in the idoc

structure.

Which data is to be extracted from the tables to be filled in EDIDD type internal table is determined in standalone programs from the objects which are specified in the selection screen and from the object key passed to the function module in case of message control and is taken from BDCP table in case of change pointers using function modules "CHANGE_POINTERS_READ"

In case of stand alone programs and function modules based on change pointers method the function module "MASTER_IDOC_DISTRIBUTE" is used to send the IDOC to ALE layer for distribution ,in case of message control it is handled automatically by the RSNASTED program invoked by the message control.

OUTBOUND PROCESS AND OUTBOUND PROGRAM.

Outbound programs are used in outbound process to genearte IDOCs . There

purpose is to extract the data from the tables and to fill the IDOC data records

and the control record in the IDOC and pass ito the ALE layer for distribution to the recieving system .

Depending upon the triggering mechanism (how and when the outbound program will be started different techniques and interface is used for outbound program.

1)Message control

Application like PO(purchase order) creation use this technique , where the output type is linked to the application(Message control is a configurable cross application component which can be set in IMG .Such programs are created in the form of function modules and linked to the output type which is linked to the apllication.These have predefined interfaces.

In outbound programs(function module) that use message control the key of the

application document is passed to the function module whcig will read the data from the table depending upon the key passed(NAST structure) and fill the IDOC segemnts with the application data.The control record is also passed to the function module but is not fully filled, the rmaining fields are filled and the control is passed back to the calling program which is RSNASTED and is invoked by the

message control to process ALE and EDI output types and this program on recieving the IDOC data will create the physical IDOC in the system.

The parameteers passed to the function module are

IMPORTING PARAMETERS

OBJECT LIKE NAST

It contains documents key.

CONTROL_RECORD_IN LIKE EDIDC

It contains the partailly filled control record

EXPORETING PARAMETER

OBJECT_TYPE

CONTROL_RECORD_OUT LIKE EDIDC

TABLES

INT_EDID LIKE EDIDD

The internal table used to fill the data records in the same order as they exists in the IDOC.

The important parameters that should be filled in the custom function module are

CONTROL_RECORD_OUT and INT_EDIDD .The OBJK field of the structue NAST contains the key of the apllication document.

2)Stand alone programs

Generally used for Master Data transfer and as such depending upon the requirement can have different interfaces.The programs have a selection screen which has select options to select the objects, and parameters for specifying the recipient Logical System and the Message Type.

Data is selected based on the specified objects from the tables . and control record of type EDIDC is created and filled with important values like DIRECTION ,IDOCTP,RCVPRT,RCVPRN and MESTYP .

Data is filled in an internal table of TYPE EDIDD according to segment definitions

and in same order and the function module MASTER_IDOC_DISTRIBUTE is called passing the control record and the internal table containg IDOC data and importing an internal table consisting of control records for each communication IDOCS created.

3)Change pointer

Change Pointer table is read and checked if changes were made to important fields , if so the outbound program will be triggered automatically , these have predefined interfaces

ALE/IDOC Transaction

SALE Area Menu for ALE configurations.It includes transactions for

Logical System definition and linking it to a client, Transactions for

RFC Destination and Port Definition Etc.

SM59 RFC Destination

Here we specify the login settings for the destination including

the I.P address or Application Server name and the User name and

password.The information entered here is used to run Remote Function

Calls(RFC ) on the destination server .We can create number of types

of RFC Destinations but 3 types are important .

R/3 (R/3 to R/3), LS(logical system) and TCP/IP.

The name of the RFC destination should be same as that of Logical

System as it helps in creation of automatic partner profiles.

WE21 Port Definition.

There are 6 types of ports but only 2 types File and Transactional RFC

types of ports are important.

We have to specify the RFC Destination before a port can be created.

WE57 This is used to assign the Inbound function module to the Message Type

and to the IDOC Type.

WE42 This is used to define the process Code for Inbound Processing.

BD95 Define Filter object type .We can specify the field and the table it belongs

to as a filter object .

BD59 Assignment of Filter object type to the Message Type .Here we create the

link between Filter object and the segment and the message type and the

segment Field.

BD50 Set message Type to reducible.

BD65 Define Mandatory Fields.

BD64 Distribution Model . Also known as Customer Distribution Model Used to

define all the messages that will be exchanged between remote systems

and the name of thes logical systems. Any filters can also be specified.

The model once created has to be distributed on every system which will

be communicating ,It can be maintained on only One system.

BD21 Creating IDOcs from change pointers.

This can be used to create IDOCs from change pointers for a particular

message LIKE MATMAS.

BD22 This can be used to delete change pointers.

BD87 Status Monitor. Idocs can be selected base on number of criteria and there

processing status can be seen in detail.

BD10 Material Master Data Distribution .

Based on Message MATMAS.

BD12 Customer Master Data Distribution .

Based on Message CREMAS.

BD14 Vendor Master Data Distribution

Based on Message DEBMAS .

BDFG Generate ALE Interface for BAPI.

Here we specify the Business Object and the BAPI Function module for

which the interface has to be created.

WE31 Segment Editor.

This is used to create segments. We create the segment type and

segment definition is automatically created by editor e.g. Z1DUMMY is

segment type and Z2DUMMY is the segment definition .We specify the

fields and the data elements these cp\orresponds to create segments.

WE30 IDOC Editor

It is used to create a new IDOC Type or IDOC Extension .We specify the

segments that will be addd to the IDOC type.

WE02/05 IDOC List.

Various selct options and parameters are provided to select IDOCs

depending on the date, direction , mesage type etc.

WE20 Partner Profile

Here we create partner profile for each and every partner from / to which

the messages will be exchanged.There are 6 types of PF generally only

profiles of type LS(Logical System) ,KU(Customer) ,LI(Vendor) is used.

We specify the partner number and partner type and the agent and

the agent type responsible for handling of errors .

For every message send to the partner we have a outbound record and for

evry message coming from the partner we have the inbound record .

We specify the message in the otbound/inbound records ,double

clicking will take us to the detailed screen where the IDOC Type ,Port

and whether the IDCO will be immediatelt processed or collected are

mentioned.

IDOC Status Code

Status Description

00 Not used, only R/2

01 IDoc generated

02 Error passing data to port

03 Data passed to port OK

04 Error within control information of EDI subsystem

05 Error during translation

06 Translation OK

07 Error during syntax check

08 Syntax check OK

09 Error during interchange handling

10 Interchange handling OK

11 Error during dispatch

12 Dispatch OK

13 Retransmission OK

14 Interchange Acknowledgement positive

15 Interchange Acknowledgement negative

16 Functional Acknowledgement positive

17 Functional Acknowledgement negative

18 Triggering EDI subsystem OK

19 Data transfer for test OK

20 Error triggering EDI subsystem

21 Error passing data for test

22 Dispatch OK, acknowledgement still due

23 Error during retransmission

24 Control information of EDI subsystem OK

25 Processing despite syntax error (outbound)

26 Error during syntax check of IDoc (outbound)

27 Error in dispatch level (ALE service)

28 Not used

29 Error in ALE service

30 IDoc ready for dispatch (ALE service)

31 Error - no further processing

32 IDoc was edited

33 Original of an IDoc which was edited

34 Error in control record of IDoc

35 IDoc reloaded from archive

36 Electronic signature not performed (timeout)

37 IDoc added incorrectly

38 IDoc archived

39 IDoc is in the target system (ALE service)

40 Application document not created in target system

41 Application document created in target system

42 IDoc was created by test transaction

50 IDoc added

51 Application document not posted

52 Application document not fully posted

53 Application document posted

54 Error during formal application check

55 Formal application check OK

56 IDoc with errors added

57 Test IDoc: Error during application check

58 IDoc copy from R/2 connection

59 Not used

60 Error during syntax check of IDoc (inbound)

61 Processing despite syntax error (inbound)

62 IDoc passed to application

63 Error passing IDoc to application

64 IDoc ready to be transferred to application

65 Error in ALE service

66 IDoc is waiting for predecessor IDoc (serialization)

67 Not used

68 Error - no further processing

69 IDoc was edited

70 Original of an IDoc which was edited

71 IDoc reloaded from archive

72 Not used, only R/2

73 IDoc archived

74 IDoc was created by test transaction

IDOC Function

CALL FUNCTION 'MASTER_IDOC_DISTRIBUTE'

EXPORTING

VALUE(MASTER_IDOC_CONTROL) LIKE EDIDC STRUCTURE EDIDC

" Control record of master IDoc

VALUE(OBJ_TYPE) LIKE SERIAL-OBJ_TYPE DEFAULT ''

VALUE(CHNUM) LIKE SERIAL-CHNUM DEFAULT ''

TABLES

COMMUNICATION_IDOC_CONTROL STRUCTURE EDIDC

" Control records of created comm. IDocs

MASTER_IDOC_DATA STRUCTURE EDIDD

" Data records of master IDoc

EXCEPTIONS

ERROR_IN_IDOC_CONTROL

" Incorrect entry in IDoc control record

ERROR_WRITING_IDOC_STATUS

" Error when writing IDoc status records

ERROR_IN_IDOC_DATA

" Incorrect entry in IDoc data records

SENDING_LOGICAL_SYSTEM_UNKNOWN

" Own logical system unknown

CALL FUNCTION 'CHANGE_POINTERS_READ'

EXPPORTING

VALUE(ACTIVATION_DATE_HIGH) LIKE SY-DATUM DEFAULT SPACE

VALUE(ACTIVATION_DATE_LOW) LIKE SY-DATUM DEFAULT SPACE

VALUE(ACTIVATION_TIME_HIGH) LIKE SY-UZEIT DEFAULT '000000'

VALUE(ACTIVATION_TIME_LOW) LIKE SY-UZEIT DEFAULT '000000'

VALUE(CHANGE_DOCUMENT_OBJECT_CLASS) LIKE CDPOS-OBJECTCLAS

DEFAULT SPACE

VALUE(CREATION_DATE_HIGH) LIKE SY-DATUM DEFAULT SPACE

VALUE(CREATION_DATE_LOW) LIKE SY-DATUM DEFAULT SPACE

VALUE(CREATION_TIME_HIGH) LIKE SY-UZEIT DEFAULT '000000'

VALUE(CREATION_TIME_LOW) LIKE SY-UZEIT DEFAULT '000000'

VALUE(MESSAGE_TYPE) LIKE BDCPS-MESTYPE

VALUE(READ_NOT_PROCESSED_POINTERS) LIKE BDCPS-PROCESS DEFAULT

'X'

TABLES

CHANGE_POINTERS STRUCTURE BDCP

MESSAGE_TYPES STRUCTURE BDMSGTYP OPTIONAL

EXCEPTIONS

ERROR_IN_DATE_INTERVAL

ERROR_IN_TIME_INTERVAL

CALL FUNCTION change_pointers_status_write.

IMPORTING

VALUE(MESSAGE_TYPE) LIKE EDIDC-MESTYP

TABLES

CHANGE_POINTERS_IDENTS STRUCTURE BDICPIDENT

Examples of Inbound function modules are

IDOC_INPUT_BLAOCH IDoc inbound processing: change Ccontract

IDOC_INPUT_BLAORD IDoc inbound processing: Create Contract

IDOC_INPUT_MATMAS01 IDoc inbound processing: Material Master

Examples of Outbound function modules are

IDOC_OUTPUT_BLAOCH

IDOC_OUTPUT_BLAORD

Pls reward all helpful points.

Regards,

Ameet