Tutorials on ALE & IDOCs

Step-by-Step Tutorials

Step-by-step guide to ALE and IDOCs (More details) NEW HOT

Serialization of IDOC Message type (More details)
ALE - Error handling through Workflow (More details)
Archiving IDocs (More details)
IDOC Filtration (More details) 87TH PAGE
Distributing Material Master Data using Standalone programs and Change
Pointers (More details)
ALE-IDOC Scenario using Custom IDOC (More details)
Distributing Master data (Outbound) (More details)
Creation of Custom IDOC Type (More details)
Automatic IDOC generation whenever a PO is created/changed (More details)
Enhancement/Extension of Standard IDOC type. (More details)
Conversion of IDOCs to XML format (More details)
Download IDOC to excel, HTML or any other format (More details)
Change Pointers in ALE (More details) NEW
Extending the standard IDOC for Outbound delivery (VL02N) (More details)
NEW

Tutorials on ALE & IDOCs

Step-by-Step TutorialsStep-by-step guide to ALE and IDOCs
By Shankar Reddy Chamala, ITChamps Software
Introduction to EDI and ALE:
EDI (Electronic Document interchange) - Edi is the electronic exchange of business
documents between the computer systems of business partners, using a standard
format over a communication network.
Edi is also called paperless exchange.
Advantages:
Reduced Data entry errors
Reduced processing time
Availability of data in electronic form
Reduced paperwork
Reduced Cost
Reduced inventories and better planning
Standard means of communications
Better business process
EDI has two process

1. Outbound process
2. Inbound process
Outbound Process:
1.Application document is created.
2. IDOC is generated
3.Idoc is transferred from SAP to Operating system layer
4.Idoc is converted into EDI standards
5.Edi document is transmitted to the business partner
6.The Edi Subsystem report status to SAP
Inbound Process:
1.EDI transmission received
2.EDI document is converted into an IDOC
3.IDOC is transferred to the SAP layer
4.The application document is created
5.The application document can be viewed.
IDOC:
IDOC is a container that can be used to exchange data between any two processes.
Each IDOC is assigned a unique number for tracking and future reference.
IDOC consists of several segments, and segments contain several fields.
IDOC contains the following three types of records...
1. One Control Record.
2. One or many Data Record
3. One or many Status record.
In IDOCs the following terms are to be known.
PORT:
Port is used in the outbound process to determine the name of the EDI subsystem
program, the directory path where the IDOC file will be created at the operating
system level, the IDOC file names and the RFC destinations.
RFC Destination:
Used to define the characteristics of communication links to a remote system on
which a functions needs to be executed.
Partner Profile:
Partner profile specified the various components used in an outbound process (Partner
number, IDOC type, message type, Port, Process code), the mode in which it
communicates with the subsystem (batch or immediate) and the person to be notified
in case of errors.
Message Control
Used in pricing, account determination, material determination, and output
determination. The message control component enables you to encapsulate business
rules with out having to write ABAP programs.
TO Process IDOCS the following TCODES will be used.

On both sides:
Logical System Names SALE
Setup RFC destinations SM59
Port Destinations WE21
In Source system:
Segment Creation WE31
Basic IDOC Type Creation WE30
Message Type Creation WE81
Assign Message Type To Basic IDOC Type WE82
Distribution Model BD64
Writing Report Program SE38
Partner Profile WE20
Message control NACE
Check IDOCs WE02, WE05
In Destination System:
Creating FM SE37
Assign FM to Logical Message WE57
Define I/P method for Inbound FM BD51
Create Process Code WE42
Generate Partner Profile BD64
IDOC processing in the same instance of R/3 Clients.
For example two clients in the same R/3 instance.
Client 900.
Client 800.
To transfer the data between two clients the table structures and their data types
should be match.
In this example, Client 900 is Source system, and Client 800 is destination system.
In Client 900 I have created a customized table and inserted some records.

In Client 800 I have created only table.

Common Steps in Both Clients:
Creating the Logical System Names and Assigning to Clients:
Go to TCODE SALE.
IMG path IDoc Interface / Application Link Enabling (ALE) -> Basic Settings ->
Logical Systems -> Define Logical System

Click on Display / Change Button

Click on New Entries

Specify the Logical System name and description.

Note: Logical System Naming convention is <SID>CLNT<NNN>

Click on Save and Back buttons

Now you will come back to the IMG path screen. Click on Assign Logical System to
client.

Click on Display / Change Button

Click on New Entries

Click on Save and Back.

Creating the RFC Connection Names:

Go to TCODE SALE. Direct TCODE SM59
IMG Path IDoc Interface / Application Link Enabling (ALE) -> Communication ->
Create RFC Connections

Click on Create button.

Specify all the details in RFC connection screen

Click on Logon Security tab and specify the details.

Click on the Special options tab and specify the details which you want.

Now click on Test Connection button

It show the connection log in next screen

Click on Back
Click on Remote Logon Button

Depends upon your settings the destination client will open. If you check the Current
user option under Logon/ Security tab, then it will show the screen directly without
asking the user name and password details.

Creating RFC ports:

Go to TCODE WE21
Select the Transactional RFC in left side tree and click on Create button

In dialog box you can select either Generate port name or own port name. If you
select Generate Port name system will generate automatically. Here I selected Own
port name. Click on continue.

Specify the description and RFC destination name.

Click on Save.

Repeat the same above process in other client. By using opposite client instead of 900
specify 800.
In Client 900 steps:
Creating table structure:
Go to TCODE SE11.
Specify table name as ZSTUDENTS.
In Delivery and Maintenance tab set attributes as Display Maintenance
Allowed
The table fields are.

 Insert some records in table.

Go to TCODE WE31.
Specify a name and Click on Create Button.

Here specify all the ZSTUDENTS table fields and their types as shown below.

Click on SAVE button, then it will show dialog box with user name, press continue.

Specify your package name and click on save.

Specify your request and press Continue.

Click on Back button, and then you will see the created segment.

Creating Basic IDOC Type:

Go to TCODE WE30
Specify a name to your IDOC and click on create button.

In next dialog box select create new option and specify the description of IDOC and click on
continue.

Click on Create segment in the screen.

In dialog box specify the segment name which you created and check mandatory check box.

Click on SAVE and BACK button.

Go to menu EDIT ->Click Set Release

In next dialog box, click on Yes.

Creating Message Type:

Go to TCODE WE81.
Click on Display / Change button.

Click on New Entries button.

Specify a message type name and Description and click on SAVE button.

Click on Back and Save

Assign Message Type to Basic IDOC Type:

Go to TCODE WE82
Click on Display / Change Button

Click on New Entries, Specify the Message Type and Basic IDOC Type and Release version.
Click on Save.

Click on Back.
Note:

Here the Release version you can find in this way

Creating Model View and Distributing and Generating Partner profile:

Go to TCODE BD64
Click on Display/ Change button

Click on Edit menu -> Model View -> Create

Specify description of model view and technical name in dialog box and press continue.

Select your model view and click on Edit menu -> Add Message type

In dialog box specify the sender, receiver, message type and click on continue.

Now your Model View looks like

Click on Environment Menu -> Generate Partner profile

It will show the following screen, click on execute.

It will show the partner profile log in next screen.

Click on Back button 2 times, it will take back to Distribution Model screen.

Click on Edit Menu -> Model View -> Distribute.

In displayed dialog box select the partner system and click continue

Then it will show the Log of Model View Distribution.

Click on Back button.

To check partner profile Go to TCODE WE20
In displayed screen select the partner system in left side tree under Partner Type LS.

Write a Report Program in SE38 to create IDOC control records and transfer it to
destination partner system.
The following is the program to generate the IDOC control records and process it.
*&--------------------------------------------------------------------*
*& Report ZSHAN_IDOC_STUD
*&
*&--------------------------------------------------------------------*
*&
*&
*&--------------------------------------------------------------------*
REPORT ZSHAN_IDOC_STUD.
TABLES: ZSTUDENTS.
DATA : S_CTRL_REC LIKE EDIDC, "Idoc Control Record
S_ZSHSTUSEG LIKE ZSHSTUSEG. "CUSTOMER Header Data
DATA : T_ZSTUDENTS LIKE ZSTUDENTS OCCURS 0 WITH HEADER LINE.
DATA : T_EDIDD LIKE EDIDD OCCURS 0 WITH HEADER LINE.
"Data
Records
DATA : T_COMM_IDOC LIKE EDIDC OCCURS 0 WITH HEADER LINE. "Generated
Communication IDOc
CONSTANTS :C_ZSHSTUSEG LIKE EDIDD-SEGNAM VALUE 'ZSHSTUSEG'.
CONSTANTS: C_IDOCTP LIKE EDIDC-IDOCTP VALUE 'ZSHSTUDIDOCS'.
*** Selection Screen
SELECT-OPTIONS : S_STUID FOR ZSTUDENTS-ZSTUID OBLIGATORY.
PARAMETERS : C_MESTYP LIKE EDIDC-MESTYP DEFAULT 'ZSHSTUDMT',
"Message Type
C_RCVPRT LIKE EDIDC-RCVPRT DEFAULT 'LS',
"Partner type of receiver

C_LOGSYS LIKE EDIDC-RCVPRN DEFAULT 'IT3CLNT800',

C_RCVPOR LIKE EDIDC-RCVPOR DEFAULT 'PORTSH800',
C_SNDPRN LIKE EDIDC-SNDPRN DEFAULT 'IT3CLNT900',
C_SNDPRT LIKE EDIDC-SNDPRT DEFAULT 'LS'.
"Destination System
***START-OF-SELECTION
START-OF-SELECTION.
PERFORM GENERATE_DATA_RECORDS.
PERFORM GENERATE_CONTROL_RECORD.
PERFORM SEND_IDOC.
*&--------------------------------------------------------------------*
*&
Form GENERATE_DATA_RECORDS
*&--------------------------------------------------------------------*
*
text
*---------------------------------------------------------------------*
* --> p1
text
* <-- p2
text
*---------------------------------------------------------------------*
FORM GENERATE_DATA_RECORDS .
SELECT * FROM ZSTUDENTS
INTO TABLE T_ZSTUDENTS
WHERE ZSTUID IN S_STUID.
IF SY-SUBRC NE 0.
MESSAGE E398(00) WITH 'No Students Found'.
ENDIF.
PERFORM ARRANGE_DATA_RECORDS.
ENDFORM.
" GENERATE_DATA_RECORDS
*&--------------------------------------------------------------------*
*&
Form GENERATE_CONTROL_RECORD
*&--------------------------------------------------------------------*
*
text
*---------------------------------------------------------------------*
* --> p1
text
* <-- p2
text
*---------------------------------------------------------------------*
FORM GENERATE_CONTROL_RECORD .
S_CTRL_REC-RCVPOR = C_RCVPOR. "Receiver Port
S_CTRL_REC-MESTYP = C_MESTYP. "Message type
S_CTRL_REC-IDOCTP = C_IDOCTP. "Basic IDOC type
S_CTRL_REC-RCVPRT = C_RCVPRT. "Partner type of receiver
S_CTRL_REC-RCVPRN = C_LOGSYS. "Partner number of receiver
S_CTRL_REC-SNDPRT = C_SNDPRT. "Sender Partner type
S_CTRL_REC-SNDPRN = C_SNDPRN. "Sender Partner Number
ENDFORM.
" GENERATE_CONTROL_RECORD
*&--------------------------------------------------------------------*
*&
Form SEND_IDOC
*&--------------------------------------------------------------------*
*
text
*---------------------------------------------------------------------*
* --> p1
text

* <-- p2
text
*---------------------------------------------------------------------*
FORM SEND_IDOC .
CALL FUNCTION 'MASTER_IDOC_DISTRIBUTE'
EXPORTING
MASTER_IDOC_CONTROL
= S_CTRL_REC
*
OBJ_TYPE
= ''
*
CHNUM
= ''
TABLES
COMMUNICATION_IDOC_CONTROL
= T_COMM_IDOC
MASTER_IDOC_DATA
= T_EDIDD
EXCEPTIONS
ERROR_IN_IDOC_CONTROL
= 1
ERROR_WRITING_IDOC_STATUS
= 2
ERROR_IN_IDOC_DATA
= 3
SENDING_LOGICAL_SYSTEM_UNKNOWN
= 4
OTHERS
= 5
.
IF SY-SUBRC <> 0.
MESSAGE ID SY-MSGID TYPE SY-MSGTY NUMBER SY-MSGNO
WITH SY-MSGV1 SY-MSGV2 SY-MSGV3 SY-MSGV4.
ELSE.
COMMIT WORK.
LOOP AT T_COMM_IDOC.
WRITE:/ 'IDoc Generated - ', T_COMM_IDOC-DOCNUM.
ENDLOOP.
ENDIF.
ENDFORM.
" SEND_IDOC
*&--------------------------------------------------------------------*
*&
Form ARRANGE_DATA_RECORDS
*&--------------------------------------------------------------------*
*
text
*---------------------------------------------------------------------*
* --> p1
text
* <-- p2
text
*---------------------------------------------------------------------*
FORM ARRANGE_DATA_RECORDS .
DATA: W_INDEX1 LIKE SY-TABIX,
W_INDEX2 LIKE SY-TABIX.
SORT T_ZSTUDENTS BY ZSTUID.
LOOP AT T_ZSTUDENTS.
S_ZSHSTUSEG-ZSTUID = T_ZSTUDENTS-ZSTUID.
S_ZSHSTUSEG-ZSNAME = T_ZSTUDENTS-ZSNAME.
T_EDIDD-SEGNAM = C_ZSHSTUSEG.
T_EDIDD-SDATA = S_ZSHSTUSEG.
APPEND T_EDIDD.
CLEAR T_EDIDD.
ENDLOOP.
ENDFORM.
" ARRANGE_DATA_RECORDS
Now execute the program, and specify the range of records to transfer

Go to TCODE WE02 to check the generated IDOC control records.

Click on Execute

In Client 800 Steps:

Function Module Creation:
Create a Function Module to update the table from the IDOC segments
Go to SE37
Specify a name and click on create.

In dialog box specify function group and description, and click on save.

Specify the Import parameters in Import tab

Specify the Export parameters in Export tab

Specify the Table parameters in Tables tab

Specify the Exceptions in Exception tab

Click on Source code Tab.

Write the following code in Source code tab.

FUNCTION ZSHAN_IDOC_ZSHSTUDMT.
*"------------------------------------------------------------------*"*"Local Interface:
*" IMPORTING
*"
REFERENCE(INPUT_METHOD) LIKE BDWFAP_PAR-INPUTMETHD
*"
REFERENCE(MASS_PROCESSING) LIKE BDWFAP_PAR-MASS_PROC
*" EXPORTING
*"
REFERENCE(WORKFLOW_RESULT) LIKE BDWF_PARAM-RESULT
*"
REFERENCE(APPLICATION_VARIABLE) LIKE BDWF_PARAM-APPL_VAR
*"
REFERENCE(IN_UPDATE_TASK) LIKE BDWFAP_PAR-UPDATETASK
*"
REFERENCE(CALL_TRANSACTION_DONE) LIKE BDWFAP_PAR-CALLTRANS
*" TABLES
*"
IDOC_CONTRL STRUCTURE EDIDC
*"
IDOC_DATA STRUCTURE EDIDD
*"
IDOC_STATUS STRUCTURE BDIDOCSTAT
*"
RETURN_VARIABLES STRUCTURE BDWFRETVAR
*"
SERIALIZATION_INFO STRUCTURE BDI_SER
*" EXCEPTIONS
*"
WRONG_FUNCTION_CALLED
*"------------------------------------------------------------------* Include File containing ALE constants
INCLUDE MBDCONWF.
TABLES : ZSTUDENTS.
DATA : W_ZSHSTUSEG LIKE ZSHSTUSEG.
DATA : T_ZSTUDENTS LIKE ZSTUDENTS OCCURS 0 WITH HEADER LINE.
WORKFLOW_RESULT = C_WF_RESULT_OK.
LOOP AT IDOC_CONTRL.
IF IDOC_CONTRL-MESTYP NE 'ZSHSTUDMT'.
RAISE WRONG_FUNCTION_CALLED.

ENDIF.
Before reading a new entry, clear application buffer
LOOP AT IDOC_DATA WHERE DOCNUM EQ IDOC_CONTRL-DOCNUM.
W_ZSHSTUSEG = IDOC_DATA-SDATA.
MOVE-CORRESPONDING W_ZSHSTUSEG TO T_ZSTUDENTS.
INSERT INTO ZSTUDENTS VALUES T_ZSTUDENTS.
ENDLOOP.
UPDATE ZSTUDENTS FROM T_ZSTUDENTS.
IF SY-SUBRC EQ 0.
IDOC_STATUS-DOCNUM = IDOC_CONTRL-DOCNUM.
IDOC_STATUS-STATUS = '53'.
IDOC_STATUS-MSGTY = 'I'.
IDOC_STATUS-MSGID = 'YM'.
IDOC_STATUS-MSGNO = '004'.
IDOC_STATUS-MSGV1 = T_ZSTUDENTS-ZSTUID.
APPEND IDOC_STATUS.
CLEAR IDOC_STATUS.
ELSE.
IDOC_STATUS-DOCNUM = IDOC_CONTRL-DOCNUM.
IDOC_STATUS-STATUS = '51'.
IDOC_STATUS-MSGTY = 'E'.
IDOC_STATUS-MSGID = 'YM'.
IDOC_STATUS-MSGNO = '005'.
IDOC_STATUS-MSGV1 = T_ZSTUDENTS-ZSTUID.
APPEND IDOC_STATUS.
CLEAR IDOC_STATUS.
WORKFLOW_RESULT = C_WF_RESULT_ERROR.
RETURN_VARIABLES-WF_PARAM = 'Error_Idocs'.
RETURN_VARIABLES-DOC_NUMBER = IDOC_CONTRL-DOCNUM.
APPEND RETURN_VARIABLES.
CLEAR RETURN_VARIABLES.
ENDIF.
ENDLOOP.
ENDFUNCTION.
*

Click on Save and Activate.

Assign FM to Logical Message:
Go to TCODE WE57
Click on Display / Change button.

Click on New Entries Button

Specify created FM name, Function Type, Basic Type (IDOC), Message Type, and Direction
and click on SAVE button.

Click on Back button.

Define Input Method for Inbound Function Module:

Go to TCODE BD51
Click on Display / Change button

Click on New Entries

Specify FM name and Input Types as 2. And Click on Save and Back buttons.

Creating Process Code:

Go to TCODE WE42
Click on Display / Change Button

Click on New Entries button

Specify a process code name, Description and select the options processing with ALE
services, Processing by Function Module.

Click on save button

In next screen select the FM name and click on SAVE button and Click on BACK button.

It will take to you previous screen. Double Click on Logical Message in left side tree.

Click on Display / Change button

Click on New Entries button

Specify the Message Type and Click on Save button

Click on Back button

Generating the Partner Profile:

Go to TCODE BD64.
Select the Model View which you distributed in client 900.

Click on Environment Menu -> Generate Partner Profile

It will show the next screen, in that click on Execute button

It will show the Partner Profile details

To check the partner profile details. Go to TCODE WE20. Select the partner system name.

Transferring the IDOC control records from Client 900 to 800:

In source system, go to TCODE SE38. (In client 900)
Execute the Report program which you created.

Check in Destination System: (Here client 800)

Go to TCODE WE02

Check in ZSTUDENTS table in SE11.

Serialization of IDOC
Message type
By Vijayendra Krishnamurthy Rao, Hewlett-Packard
Serialization for Sending and Receiving Data
With serialized message distribution, IDocs are created, sent and posted in a specific order.
This prevents errors occurring when inbound IDocs are processed. Interdependent messages
can be distributed serially in different ways, as described in the following sections.

Serialization Using Message Types

Serialization Using Business Objects

In this Tutorial we will learn Serialization using IDOC Message types and the details steps
involved.
Serialization Using Message Types
When master data is distributed, interdependent objects are often distributed together (for
example, purchasing info record is distributed with vendor and material). With serialized
message distribution IDocs are created, dispatched and posted in a specific order. The
interdependency of objects is at message type level and this avoids errors occurring during
inbound processing of IDocs. Serialization groups in which the messages to be used and the
posting order is specified, are used to distribute interdependent messages serially.
Example

If you distribute materials and the material classes, they must be distributed together. You
cannot process classification data in the receiver system, if this system does not also have
the data of the material to be classified. For this reason materials should be included with the
associated classifications in a serialization group. To use serialized distribution you must carry
out the following steps in Customizing:
Steps to be followed:

Define Serialization Groups

Assign Message Types to the Serialization Group

In addition to the message types used, the dispatch of the message type SERDAT must be
modeled in the distribution model.
STEP 1 Define Serialization Groups
In this section you create serialization groups and assign message types and the processing
order to each group. Both the sender and the receiver of the serialization group must know
the assignments. This means this step needs to be carried out in both the receiving system
and the sending system.
Serialization groups are required to distribute interdependent objects together so that they are
processed in the correct order.
Example
The message types MATMAS (material master) and CLFMAS (classification) are assigned to
a serialization group for dispatching materials and their accompanying classifications. The
message type MATMAS is assigned the suffix 1 and the message type CLFMAS the suffix 2,
so that the materials are processed first and then the classifications.
Create serialization group: Goto IMG Modelling and Implementing Business
Proccess Master Data Distribution Serialization for sending and Receiving data
Serialization using Message types and click on DEFINE SERIALIZATION GROUPS

On the next screen Choose 'New entries' in the view 'Serialization groups' to add a
new entry, In our case we will just modify one of the existing groups provided by

SAP.

We will modify the existing group GRP_MATMAS Material Master Complete. So select the
group from the list and Place the cursor on a serialization group and choose 'Assign message
types to serialization group'.

Click on the Change/Display button and Select 'New entries'. In our case we will add one
more message type in this group. The message type to be added is CLSMAS. After adding
the new entry we need to adjust the sequence of serialization if required.

Enter the message types used and add a sequence number for each one.

Save your entries.

Further notes
The message types in a serialization group are processed in ascending order of the sequence
number added. You can also leave spaces between the individual numbers. (For example:
1,2,4,10,20).
If the serialization group is to be dispatched later a setting must be made so that the outbound
IDocs are collected and inbound processing is carried out in the background for all message
types. This is set under Partner Profiles -> Generate Partner Profiles. You can also make
these settings in the SAP Menu for each partner profile and message type (choose ALE ->
ALE Administration -> Services -> Runtime Settings -> Partner Profiles).
Step 2 Maintain Distribution Model

Maintain the Distribution model as per the requirement and add the additional message type
SERDAT as shown in the screen shot below.

Note: The distribution model needs to have all the message types that will be distributed
between systems. It however need not have all the message types defined in the Serialization
groups.

Select the option from the menu to generate the partner profile

On the next screen select EXECUTE

Once you execute the system will generate the partner profiles in the sending system and
update the partner profiles with the associated messages

You can cross check the details by going into WE20 and checking the partner profile.

As seen from the above by automatically generating the partner profile the system creates the
required entries.
Select all the message types and ensure that the option TRANSFER IDOC IMMEDIATELY is
selected. PLEASE NOTE THIS OPTION MUST BE SET ONLY IN THE OUTBOUND
PARMETERS OR IN THE SENDING SYSTEM.

Similarly maintain for all the other messages in the partner profile and once done save your
entries.
Next distribute the model created in the sending system to the receiving system. To do this
select the menu option as shown below.

Step 3 Define Inbound Processing

In this section you can make the settings for processing inbound message types for a
serialization group. These settings are made in the receiving system.
You can specify the size of the IDoc packet forwarded to the application, whether the packet
is transferred in parallel and what server group is used.
Example
For a serialization group containing materials and associated classifications you can specify
how the message types MATMAS (material) and CLFMAS (classification) are processed.
For the message SERDAT processing in the inbound partner profiles should be set to
'immediate processing'.
From the SALE transaction select Define inbound processing as shown in the image
below

On the next screen click on NEW ENTRIES button and add the details as shown below

Under the groups column mention the Serialization group name created in the first step.
Under the Message Type define the messages assigned to the Serialization group. Under the
sending system column enter the sending systems. If the data is sent to more than one
system then all these steps have to repeated for all the individual receiving systems. Under
the Object column enter the number of objects per process. In our case we will use 1 per
process.
For Example: Number of objects (e.g. materials, vendors, customers) assigned to an
available process.
Under the Indicator: Parallel processing yes/no set the indicator as per your requirement.
Generally it is set to YES.
If the indicator is set then the inbound processing of the application uses one free dialog
process for each IDoc packet on the application server ('asynchronous RFC' is used for this).
This means that the packets can be processed in parallel. If several IDoc packets have been
selected, then the IDoc processing will occupy all the dialog processes on the application
server.
If the indicator is not set then the IDocs will not be processed in parallel. This means that
each packet will passed to the application in turn. Only one work process will be used for this
action on the application server.

Under the RFC server group define the server which will be used by the transaction in parallel
processing.

You can check the server group from the transaction RZ12.
Once done save your entries.
Step 4 Enable Change pointers in the system globally using BD61 transaction and also for
all the message types using the BD50 transaction.

Change pointer has to be activated to enable data distribution through Change documents.
SETTINGS IN THE RECEIVING SYSTEM
Once you have completed the above steps in the sending system login to the receiving
system and do the following steps.
Step 1 Maintain the serialization group as done in the above steps in the receiving system
as well.
Step 2 Go to to the distribution model and select the model that was distributed from the
sending system. And from the menu generate the partner profile in the receiving system. This
step will create the partner profiles in the receiving system.
Step 3 Change the partner profile settings for all the message types EXCEPT the SERDAT
message type to TRIGGER BY BACKGROUND PROGRAM
As shown below

BUT DO NOT CHANGE THE SETTINGS FOR THE SERDAT message type.

SERDAT will have the option TRIGGER IMMEDIATELY.

Once these settings are done both the systems are now ready for distributing data in a
serialized order.
To dispatch a serialization group two steps are required:
The IDocs belonging to a serialization group are created
These IDocs are then dispatched
These two activities are scheduled as a periodic job in the sending system.
Creating IDocs
The report RBDSER01 creates the IDocs for a serialization group. The serialization group to
be created is specified as a parameter in this report. The report selects all the master data
change pointers assigned to this serialization group. The IDocs are then created from the
change pointers.

Dispatching IDocs
After the IDocs have been created the report RBDSER02 dispatches the IDocs belonging to a
serialization group. The name of the serialization group to be sent is specified as a parameter
in this report. You can also specify the receiving systems and in the time period that IDocs
can be created/changed.
The report also schedules the report RBDSER03 which checks whether all the IDocs have
been successfully sent to the receiving system. If they have, a control message of message
type SERDAT is sent to the receiving system and posts the serialization group there. To do
this specify in the parameters of report RBDSER02 the time that should be scheduled after
sending report RBDSER03.
You also have the option to always dispatch the control message. This means dispatch it
even if all the IDocs have not been passed to the receiving system. This means that IDocs
arriving in the receiving system can be processed even if some IDocs are still being
transferred. However, serialization difficulties may occur.
Further notes
You can schedule reports RBDSER01 and RBDSER02 after each other in the same job
(choose SAP Menu -> Tools -> ALE -> ALE Administration -> Services -> Periodic Processing
-> Outbox -> Serialized Distribution Using Message Types - SM36).
The report RBDSER03 can be scheduled as an independent job. In this case you should not
enter the date and time.
The processing of inbound IDocs of a serialzation group can be directly started by the
Report RBDSER04.

ALE - Error handling through workflow

By Abhijit Daptary & Siddharth Samal, Capgemini India
Pre-requisites.
It is assumed that the reader of this article has some knowledge in SAP workflow BOR
objects and ALE Idoc process like process code, Partner Profile etc.
Description
Here, we will be discussing in details the Error handling of an Inbound Idoc through triggering
an event, which in turn will be triggering a workflow attached to the workflow.
Steps:1. Create custom BOR object with the events, Start and Stop event
2. Create a workflow for the error handling, like generating a notification whenever an
error occurred in the Inbound Idoc.
3. Creation of Function Module and attachment with the Process Code
4. Create the settings for the Inbound Process of the Idoc through the Process Code.
Creation of BOR objects. Go to the transaction SWO1.

Enter a name for the Object type and click CREATE button for creating the custom BOR
object.

Enter the details required for creating the BOR objects...

Create the Key fields and events of the BOR object.

For creating the Key fields place the cursor on the Key fields and Click on the Create Button

Create events for triggering the workflow and stopping the workflow.
For creating the event place the cursor on the EVENTS and Click the create button like Key
fields.
Create two events.
Enter the event name description etc and proceed further to create it.

Similarly create another event for ending the Workflow in the similar manner like that created
earlier.

Now, Generate the BOR object through the generate button

Release the EVENTS and subsequently release the BOR object.

After the creation of BOR object

Create a workflow for the generation of notification whenever an error is reached in the
Inbound Idoc.
Execute the transaction SWDD.

Click on the CREATE button for creating the workflow for error handling.

Choose the Step type to be inserted for the notification like here we are using Send Mail
option for sending a mail to the user whenever any error occurred.

Activate the Workflow and test it whether it is working as per the requirement.
After the successful completion it is required to attach the workflow with the event.
Go to the Header section (Denoted by CAP).

Go to the Start Events TAB.

Enter the details of the event with which the workflow should be linked like the category, BOR
object type and the event with which that should be linked.
Enter here the BOR object that has been created and give the name of event created for
starting the workflow.
Click on the Binding Button for generating the binding between the event and the workflow.

Generate the binding and click OK button to save the binding.

Click on Activate / deactivate button for activating the linkage.

After the successful linkage the following sign will appear on the workflow.....

This shows that the workflow has been linked to the event and it will be triggered whenever
that particular event will be triggered.
After the creation and successful linkage of workflow with the event it is required it is required
to generate a function module and attached it to the process code.
Go to SE37 transaction and copy a standard process code function module to a custom one.
Do no delete any parameters from the function module as the SAP standard program itself is
calling this.
In that function module do the required validation and whenever the validation fails set a
standard parameter WORKFLOW_RESULT to 9999 from within the function module,
otherwise normally proceed to set the status to 53.

After the creation of function module it is required to attach it to the process code and
corresponding attached to the message type at the Partner Profile stage.
The process code is being created through the transaction WE42
Go to the change mode and click the New Entries button for creating new process code.

Enter the Process Code Name, description and choose the processing type as Processing by
function module. Click on the extension button of Identification.

The details for the of the Process Code after clicking the identification button will be

Whenever idoc arrives into the Destination system then the standard SAP triggers the
Process code attached to the Message type in the partner profile. The partner profile is being
maintained in the transaction WE20.

Since, it is and inbound scenario so the message type and the corresponding process code
will be maintained for the Inbound Parameters.
Click on Create Inbound Parameters button for creating new Inbound Message type and the
corresponding message type.

Enter the process code for the corresponding message type.

Click SAVE button for saving the changes.

Whenever the IDOC arrives into the target system, it checks the partner profile and
finds the corresponding process code. The process code is being linked with the
function module through which the IDOC is required to be processed.

Archiving IDocs
This document details about the step-by-step process in archiving the IDocs. Archiving is the
process of offloading Out-of-date data onto a file at the operating system. The following are
the two important reasons for archiving:

Improving the performance

Saving the disk space on the SAP Server

Scenario: In this scenario, let us archive the IDocs created before Jan 1 st 1995.
Let us view at the IDocs created on or before 31 st Dec 1994. Go to transaction WE05 and
provided necessary details:

Press Execute. Following are the IDocs available in the given date range.

You can observe that all the above IDocs are in error state. The IDocs in error state cannot be
archived. However, we would leave this part to the end of the document and proceed further.
Initial settings to archive IDocs: (Maintaining Logical path and Physical path)
Go to Transaction FILE

Click on New Entries.

To assign physical path: Select the Z logical path created above and now double-click on the
assignment of physical paths on the left side of the screen.

Click on New Entries and enter the following data

Leave the file name as shown above.

Maintaining File Names: Now click on Logical file name definition and click on new entries.
Provide the details as shown below:

Archiving of IDocs: There are two

methods of archiving IDocs:

Using the transaction SARA

Using the standard programs like RSEXARCA (for archiving), RSEXARCR (for
reading) and RSEXARCL (reloading of data into the system)

This document would detail the procedure using the transaction SARA.
Go to transaction SARA and the enter the Archiving Object name as IDOC

Press Enter. You could observe some difference in the screen as shown below:

Click on Write button.

Click on Maintain. Enter a name for your variant.

Enter the information as shown below:

Click on Continue. Now in this screen, you would mention the data or the IDocs that needs to
be archived.

Click on attributes.

Click on Save and return to main screen. Now we need to mention the start date for the
archive to begin. Click on button Start Date.

Here we are scheduling the archival process immediate.

Save your entries. Now click on Execute button:

Following message appears:

From the above screenshot, you can observe that the IDOC could not be archived. The IDocs
shouldnt be in error status for the IDocs to be archived.
To change the status of the IDocs, execute the program RC1_IDOC_SET_STATUS.

Enter the list of IDocs and the new status

Click on Execute.
Now check in WE05 for the change in the IDoc status:

Now try executing the transaction SARA and archive the IDocs.

IDOC Filtration
By Jaya Vani Bheemarasetti, YASH Technologies
A Business Scenario:
Consider a company that has 10 plants manufacturing the material MAT01. The
material master data is maintained in the central SAP system for all 10 plants. The
material MAT01 has an MRP view for each plant. If we distribute this material with
MRP views, including the ones for other plants. When the number of materials
exchanged between the systems is large and very frequent, this approach can be an
unnecessary waste of network resources and can be undesirable from a business point
of view.

The technique of filtering at the IDoc level enables to send a subset of data that is
relevant for a receiving system. The system provides several filter objects for each
message type to filter data. We have to choose the appropriate filter for our business
needs and add it to our distribution model.
Maintain the Following Configurations:
Step 1 : Port Definition: T.code WE21.

Step 2: Partner Profile: T.code WE20

Double click on the Message Type MATMAS and enter Message type, Receiver port,
Pack size, basic type and select the radio button Transfer IDOC immed.

Step 3: Distribution Model View: T.code BD64

There are no filtering objects attached to the Distribution model.

The actual process is whenever a mater IDoc is created, the IDoc consults the
distribution model and determines whether any filter objects are specified for a
receiver. If so, the value in the filter object is compared to values in the master IDocs
data record. If the values do not match, the data record is dropped.
To test the scenario, go to BD10 to send a material and here give the Message type
and Partner system Logical name and execute.

.
Here is the IDoc generated before applying filtering object.

For IDOC Filtration we have to search for a suitable filtering object in transaction
BD59.

There are many predefined filtering objects available for standard message types.
Here we have to give the Segment name and filed name that we want to drop.

The filtering objects we maintained in BD59 for a message type will be in the
Distribution model.
Double click on the No filter set in our distribution model, a screen will appear like
below.

Create a filter group using Create filter group button. By default all the filter objects
will appear. Double click on any of the filter objects and give values as shown below.

In Distribution Model we can see Data Filter Active

Below is the IDoc generated after applying filter object for Plant.

Distributing Material Master data using Standalone

programs and Change Pointers
By Jaya Vani Bheemarasetti
MASTER Data is the data that exists in the organization like employee details, material
master, customer master, vendor master etc.
Master data can be transferred by two methods:

1. Triggering through stand-alone programs

2. Triggering through change pointers
Data Transfer using Standalone programs:
A material is created in R3SCLNT800 and should be transferred to R3SCLNT810.
Step1: Define Logical Systems

T.code SALE

Path: ALE--> Basic settings Logical Systems Define Logical systems

Step 2: Assign Client to the logical system

T.code: SALE

Path: ALE--> Basic Settings Logical Systems Assign client to Logical System

Step 3: Create RFC Destination

Tcode: SM59

Note: Provide Connection type as 3 indicating connection to R/3 system

Enter the following details.

Step 4: Define port

Tcode: we21

Port is the medium in which data is transferred.

Step 5: Maintain Partner Profiles

Tcode: WE20

In partner profile we specify the names of the partners which are allowed to exchange
IDocs .

Double Click on the Message type MATMAS the following opens.

Enter the details for Receiving port, Pack size and Basic type.

Step 6: Create Customer Distribution model Tcode: BD64

Click on the Create button and enter the short text, Technical name etc as shown below

Now select the created model view and click on Add message type button .A pop up box
appears, enter Sending system, receiving system and message type.

Save the Distribution model

Generate Partner Profiles
Click the menu item Generate Partner Profiles.

It leads to the next transaction where in the selection screen you have to provide Model view
name, Partner System logical system and execute.
Then, you will be intimated about the partners, port creation, and outbound parameters
creation.

Distribute Customer Distribution Model

In the menu item Distribute to the destination client.

Popup window appears , press Enter.

Generate Partner Profiles in partner system (in bound system)
Transaction: BD82
Provide Model view and logical system of Partner system to this system (our Outbound
system)
Execute, again you will be intimated about the creation of inbound parameters.

NOTE:
You cannot maintain a message type between the same sender and receiver in more than
one customer distribution model.
Only the owner is authorized to modify the model. Step 7: Creation of material T.code
MM01.
Enter the details as shown below and create a material.

Step 8: Send the created material.

T.code BD10

Enter the material created or changed, message type and the destination system as follow
and execute.

We get the information as 1 master Idoc created, 1Communication Idoc created.

Step 9: View the IDoc

T.code we05

Technical Settings In the Receiving system R3SCLNT810.

Partner Profile

T.code WE20

For the partner add the message type .here the message type is MATMAS

Double click on the message type and enter the processing code (MATM) and select Trigger
Immediately radio button, save.

Get the material

T.code BD11.

Enter the material created or changed, and the Message as shown below.

If every thing is fine IDOC will be created.

View the Idoc in the T.code We09.

Data Transfer by Change Pointers:

Steps from 1 to 6 are same as stand alone programs.
Step1: Define logical system
Step2: Assign logical system to the client
Step3: Create RFC Destination
Step4: Define Port
Step5: Generate partner profiles
Step6: Create Customer Distribution model
The following are the additional steps for Change pointers

Note (The following steps are to be maintained in both the sending and receiving systems)
Step 1: Activate change pointers generally

T.Code BD61

Check the box so that change pointers get activated and keep track the changes to
trigger ALE process.

Step 2: Activate change pointers for the message type

T.code BD50

Step3: Change Document should be checked at data element level

Step4: Run the program RBDMIDOC or the T.code BD21

Enter message type and execute.

Create or change a material and check for the Idoc creation in the T.code WE09.

ALE-IDOC Scenario using Custom IDOC

By Sachin Dabhade
Aim: Transfer the data from one system to another using user customized IDOC.
Sender System:
Server: 172.25.8.185
Client: 200
Data from Z table: zsach1
ReceiverSystem:
Server: 172.25.9.198
Client: 800

Data from Z table: zsach1

Data is fetched from Z table on the sender system and inserted it in the Z table of Receiver
system using ALE/IDOC.
Settings on the Sender End
Table Creation T Code SE11. The table contains data that is to be sent to Receiver.
ALE Configuration
T-Code SALE

Defining Logical System

200 is our sender

800 is our receiver
Assigning Client to Logical System

200 is our sender

800 is our receiver
Defining Target System for RFC Calls (Tcode SM59)

Click on R/3 Connections and then Create TAB

Step 1

Step 2

Save and test the connection.

Defining Port

The sender system is connected to the receiver system through this Port. Defining
Partner Profiles

The partner for client 200(Sender) is the client 800 (Receiver)

Since this is a sender we have to define only Outbound Parameters in this case.
Here you can see the Message type is Z message type.
2.

Maintaining Distribution Model ( TCode BD64 )

Create new Distribution Model

Add Message Type

Now Distribute this Model View

Distribute it from Edit Model View Distribute Defining the Z Segment type
Tcode WE31

Defining the Basic Type

T Code WE30

Click on New

This will take you to next screen as follows

Here you have connected the basic type to the segment type.
Enter again and this will take you to screen as follows

This shows the relation between the basic and the segment types.
Next you need to make the entry of the segment in the system table.
Tcode : WE81

Next is the following entry which is required.

Here you are specifying the message type and the basic type and the release version.

This is all about the configuration you need to do on the sender side.
Now on the sender side you also need a program that will fetch the required data,
couple it in the IDOC format and post it.
Here is a small piece of code that could be useful.
*&---------------------------------------------------------------------*
*& Report ZSACH_CUST_IDOC
*
*&
*
*&---------------------------------------------------------------------*
*&
*
*&
*
*&---------------------------------------------------------------------*
report zsach_cust_idoc
.
parameters :
p_logsys like tbdlst-logsys.
data : gen_segment like edidd-segnam value 'ZSACH'.
data : control_dat like edidc,
gen_data like z1hdr .
tables :zsach1.
data: begin of inttab occurs 0,
lname type z1hdr-lname,
fname type z1hdr-fname,
end of inttab.
data :
int_edidd like edidd occurs 0 with header line,
int_edidc like edidc occurs 0 with header line.
select * from zsach1 into corresponding fields of table inttab.
if sy-subrc ne 0.
message 'no data' type 'I'.
exit.
endif.
control_dat-mestyp = 'ZSACH'.
control_dat-idoctp = 'ZSACH'.
control_dat-rcvprt = 'LS'.
control_dat-rcvprn = p_logsys.
loop at inttab.
gen_data-lname = inttab-lname.
gen_data-fname = inttab-fname.
* GEN_DATA-SSN = INTTAB-SSN.
* GEN_DATA-DOB = INTTAB-DOB.
int_edidd-segnam = gen_segment.
int_edidd-sdata = gen_data.
append int_edidd.
endloop.
call function 'MASTER_IDOC_DISTRIBUTE'
exporting
master_idoc_control
= control_dat
* OBJ_TYPE
= ''
* CHNUM
= ''
tables
communication_idoc_control
= int_edidc
master_idoc_data
= int_edidd
exceptions
error_in_idoc_control
=1
error_writing_idoc_status
=2
error_in_idoc_data
=3
sending_logical_system_unknown
=4
others
=5

.
if sy-subrc <> 0.
message id sy-msgid type sy-msgty number sy-msgno.
else.
loop at int_edidc.
write :/ 'IDOC GENERATED',int_edidc-docnum.
endloop.
commit work.
endif.

Settings on the receiver side.

The ALE configuration is same as we did it on the sender side. Please refer to earlier pages.
The receiver specific differences are mentioned below.
T-Code SALE
200 is our sender
800 is our receiver
Steps
Defining Logical System (Same as sender)
Assigning Client to Logical System (Same as sender)
Defining Target System for RFC Calls (Tcode SM59) (Same as sender)
Defining Port(Same as sender)
Defining Partner Profiles Here we are accepting the data from Sender system. Hence we
need to configure it as Inbound.

Click on the

sign above to go to next screen.

Here the message type is to be created again as it was created on the sender side.
The following steps are repeated, as done on the sender side, on the receiver end
Tcode WE30
Tcode WE31
Tcode WE82
Tcode WE81
Here on the receiver end, we need to specify a process code at the time of defining the
partner profile.
Process code is something that has the logic defined about what to be done after receiving
the IDOC.
In our case, on receipt of the IDOC, we are updating the Z Table. i.e Inserting the data from
the IDOC into the Z Table.

Creating a Process Code

Tcode WE42

The logic associated is coded in the Function Module which is specified in the Identification
Field above.
Also the processing type is selected as Processing by Function Module as above.
The function Module is specified in the following screen.

To have your function Module in the above drop down list, the entry is to be made
using the following transaction
TCode BD51

Once the entry is done here, the function module appears in the drop down list in the previous
stage. Also it is important to make the following entry
Tcode WE57

Function Module will look something as below:

Source Code
function z_idoc_input_sach .
*"---------------------------------------------------------------------*"*"Local interface:
*" IMPORTING
*" VALUE(INPUT_METHOD) LIKE BDWFAP_PAR-INPUTMETHD
*" VALUE(MASS_PROCESSING) LIKE BDWFAP_PAR-MASS_PROC
*" VALUE(NO_APPLICATION_LOG) LIKE SY-DATAR OPTIONAL
*" VALUE(MASSSAVEINFOS) LIKE MASSSAVINF STRUCTURE MASSSAVINF
*"
OPTIONAL
*" EXPORTING
*" VALUE(WORKFLOW_RESULT) LIKE BDWF_PARAM-RESULT
*" VALUE(APPLICATION_VARIABLE) LIKE BDWF_PARAM-APPL_VAR
*" VALUE(IN_UPDATE_TASK) LIKE BDWFAP_PAR-UPDATETASK
*" VALUE(CALL_TRANSACTION_DONE) LIKE BDWFAP_PAR-CALLTRANS
*" TABLES
*"
IDOC_CONTRL STRUCTURE EDIDC
*"
IDOC_DATA STRUCTURE EDIDD
*"
IDOC_STATUS STRUCTURE BDIDOCSTAT
*"
RETURN_VARIABLES STRUCTURE BDWFRETVAR
*"
SERIALIZATION_INFO STRUCTURE BDI_SER
*" EXCEPTIONS
*"
WRONG_FUNCTION_CALLED
*"---------------------------------------------------------------------include mbdconwf.
data : it_emp_data like zsach1 occurs 0 with header line.
data : gen_data like zsach1 .

workflow_result = c_wf_result_ok.
data : counter type int4.
select count( * ) from zsach1 into counter.
counter = counter + 1.
loop at idoc_contrl.
if idoc_contrl-mestyp ne 'ZSACH'.
raise wrong_function_called.
endif.
clear gen_data.
refresh it_emp_data.
loop at idoc_data where docnum eq idoc_contrl-docnum.
if idoc_data-segnam = 'ZSACH'.
gen_data = idoc_data-sdata.
it_emp_data-mandt = counter.
it_emp_data-lname = gen_data-lname.
it_emp_data-fname = gen_data-fname.
counter = counter + 1.
append it_emp_data.
else.
message 'ERROR' type 'I'.
endif.
endloop.
endloop.
insert zsach1 from table it_emp_data.
*****
call function 'EDI_DOCUMENT_OPEN_FOR_EDIT'
exporting
document_number
= idoc_data-docnum
importing
idoc_control
= idoc_contrl
tables
idoc_data
= idoc_data
exceptions
document_foreign_lock
=1
document_not_exist
=2
document_not_open
=3
status_is_unable_for_changing = 4
others
= 5.
call function 'EDI_CHANGE_DATA_SEGMENTS'
tables
idoc_changed_data_range = idoc_data
exceptions
idoc_not_open
=1
data_record_not_exist = 2
others
= 3.
data t_itab_edids40 like edi_ds40 occurs 0 with header line.
clear t_itab_edids40.
t_itab_edids40-docnum
= idoc_data-docnum.
t_itab_edids40-status
= '51'.
t_itab_edids40-repid
= sy-repid.
t_itab_edids40-tabnam
= 'EDI_DS'.
t_itab_edids40-mandt
= sy-mandt.
t_itab_edids40-stamqu
= 'SAP'.
t_itab_edids40-stamid
= 'B1'.
t_itab_edids40-stamno
= '999'.
t_itab_edids40-stapa1
= 'Sold to changed to '.
*t_itab_edids40-stapa2
= t_new_kunnr.
t_itab_edids40-logdat
= sy-datum.
t_itab_edids40-logtim
= sy-uzeit.
append t_itab_edids40.

call function 'EDI_DOCUMENT_CLOSE_EDIT'

exporting
document_number = idoc_data-docnum
do_commit
= 'X'
do_update
= 'X'
write_all_status = 'X'
tables
status_records = t_itab_edids40
exceptions
idoc_not_open = 1
db_error
=2
others
= 3.
endfunction.
Running the Application
Sender system
Execute the program we created earlier

Checking the IDOC

T Code WE02

Checking the data on the Receiver end

Tcode: WE02

The IDOC has arrived here

Checking the Data
Double click on the IDOC

Checking the Database

This way, the data has come to the receiver end successfully.
Distributing Master Data (Outbound)
By Sarang Kahu
Master data can be distributed in two ways. In both case the IDOC receives data for only one
master data object.
1. Master data object sent directly
This process sends the entire data of the master objects.

This is done by triggering a report program starting with RBDSEXXX where XXX is the first
three characters of the message type. Example for message type MATMAS the program is
RBDSRMAT. For DEBMAS the program is RBDSEDEB and so on.
Inside the report programs a function module is called which is responsible for generating and
dispatching the IDOC for the master data. The naming convention for the function module is
MASTERIDOC_CREATE_REQ__XXXXX where XXXXX is the name of the message type.
The function module executes the change pointers and generates IDOC in the following
manner

Creates IDOC for each master data objects where the first field of each segment
MSGFN is 005.
Pass the IDOC to the ALE layer by calling the function module MASTER
IDOC_DISTRIBUTE.
Executes COMMIT WORK and calls DEQUEUE_ALL Function module

2. Master data is distributed using SMD tool (Shared master data tool)
The SMD tools logs changes to a master data using changed pointers. Changed document
should be written whenever the master data is changed or created or deleted. Only changed
data is written to the IDOC, send to the ALE layer and dispatched to the other system.
For example when a modification is recorded in customer information (VD02 transaction), an
entry is saved in BDCPS or BDCP2 table, it depends on the customizing. At the entry
creation, the PROCESS field is empty. As soon as the change pointer has been processed,
the field is filled with the value X.
Steps for distributing Master data using SMD tool.

Define change relevant field for the message type

Transaction BD52

For master data to be distributed to other systems change document fields are defined in
transaction BD52 so that change pointers are written. This creates entry in table TBD62.

Activate change pointers for message type.

Transaction BD50
The message type for which master data is to be downloaded has to be activated if change
pointers are to be written. This create a entry in table TBDA2

Activate change pointers - generally.

Transaction BD61.

This activates master data distribution using change pointers

Define function module to evaluate change pointers

Transaction BD60
This create entry in table TBDME

A function module needs to be defined

for each message type. This function module generates and dispatches the IDOC for the
master
data.
The
naming
convention
for
the
function
module
is
MASTERIDOC_CREATE_SMD_XXXXX where XXXXX is the name of the message type.

The function module executes the change pointers and generates IDOC in the following
manner
Read all the changed pointers from change pointer table BDCP that has not been processed
for the message type using function module CHANGE_POINTERS_READ.

For each record retrieved from table BDCP populate IDOC segments. For
each segment the first field MSGFN is filled in the following manner
009 For any new master data
004 For any change in master data
003 For any deletion in the master data
018 If there was no change to the particular segment but the segment have to
included because hierarchy subordinate segments have to be dispatched

be

Pass the IDOC to the ALE layer by calling the function module MASTER
IDOC_DISTRIBUTE

For the master data that are processed set the change pointer status to Processed
in table BDCP by calling function module CHANGE_POINTER_STATUS_WRITE.

Adding message type to partner profile

Transaction BD64
Add message type for the master data to the distribution model and from menu path
Environment generate partner profile.

Create IDOC from change pointers

Transaction BD21 - Program RBDMIDOC.

SAP includes a scheduled program, RBDMIDOC that runs periodically to

check the change pointers for a particular message type. RBDMIDOC
references the correct IDOC program for any given type via TBDME, which is
maintained through transaction BD60.

In the production system, it is obvious that the users will not launch the BD21 transaction by
themselves. A periodic job will be scheduled to execute the RBDMIDOC program, which is
actually run by BD21 transaction, with a variant containing the right message type.

Population custom field for extended IDOC.

For any modification or population of custom fields in extended IDOC through this program
RBDMIDOC or RDBSEXXX a user exit is available in function module
MASTERIDOC_CREATE_XXXXX where XXXXX is the message type.

Function module MASTERIDOC_CREATE_XXXXX is called from the function module

MASTERIDOC_CREATE_REQ_XXXXX
for
program
RBDSEXXX
or
MASTERIDOC_CREATE_SMD_XXXXX for program RBDMIDOC as defined in transaction
BD60.
For e.g for message type MATMAS for material download
Function Module:

USER EXIT:

MASTERIDOC_CREATE_MATMAS

EXIT_SAPLMV01_002

ENHANCEMENT:
Extended IDOC Field:

MGV00001

IDOC_CIMTYPE

Set Change Document Flag on for custom fields

Transaction SE11

If change pointers are to be written for custom fields then the change
document flag
at the domain level should be activated
for that field. Then maintain an entry for this field in transaction BD52.
Changes to custom fields will be only picked if the change document for
such fields is maintained in table BDCP.
Reference Links:

1. http://help.sap.com/saphelp_45b/helpdata/en/78/2178da51ce11d189570000e
829fbbd/content.htm

2. http://help.sap.com/saphelp_nw04/helpdata/en/12/83e03c19758e71e100000
00a114084/content.htm
https://www.sdn.sap.com/irj/sdn/thread?threadID=133101

Creation of Custom IDOC Type

By Sarang Kahu
1.Business Case

SAP R/3 systems send out data through IDoc (Intermediate Document), which in
internally has segments and fields containing the data. But sometimes, these fields are
not sufficient for a specific end-to-end business scenario as far as data transfer is
concerned. So in such scenario, either few fields are to be added or subtracted, or

completely new structure- IDoc needs to be created. This are called as Custom
IDOC Types. Following blog gives out step-by-step approach for creation of the
same.
2.Development of IDOC types
2.1 Creation of Segment Types

Run T-code WE31 to create segment type, which has fields to contain the data and
are added to the segment type in the same transaction. The data stored contained into
the segment mesh is finally stored in EDISEGMENT table.

Add your custom fields as per business scenario.

To make it available to other transactions, release the segment created.

Go to Edit -> Set Release

2.2 Creation of IDoc type

Run T-code WE30 to create custom IDoc type. Enter the name of custom IDoc you
want to create and click on red box for creation.

Now, it takes you to following screen. Here you can add description for your IDoc
type. Also you can specify name of existing IDoc for Copy or Successor mode.
Now, you can maintain attributes of the custom IDoc, which consists of attaching
segment type created above to the IDoc type. Also specifying the details of frequency
of these segments getting filled i.e. Maximum and Minimum number. Fill the
necessary details and release this IDoc type as well.
2.3 Creation of logical message types

Run T-code WE81 to create the logical message types. Go to Edit mode and click
New Entry to go to following screen.

Save the entered data.

2.4 Linking Message type and IDoc type.

Run T-Code WE82. Now we have to link these created IDoc types and Message
types. Enter the message type name, Basic IDoc type (ZCUST_IDC) and release type

to be linked. In the data transfer through ALE, these message types represent the
IDOC structure.

Extension field above will be used as per the Extended IDoc type scenario i.e. in case
of addition of few more fields into the existing IDoc type.
Hence, now our Creation of Custom IDoc is ready to use in ALE scenarios.

Automatic IDOC generation whenever a PO is created/changed

This document details about the step-by-step procedure in generating an IDOC
whenever a PO is either created or changed.
1. Go to transaction NACE.

2. Select the row EF Purchase Order and click on Procedures.

3. From the above screenshot, it is evident that there are 2 procedures for the
application EF (Purchase Order). To proceed further, we would need to find out
the procedure that is currently active.
Go to transaction SPRO. In this, navigate as following:
Materials management Purchasing Messages Output control Message
Determination Schemas Define Message Schema for Purchase Order

Click on Assign Schema to Purchase Order.

So, the procedure RMBEF1 is active for EF (Purchase Order) .

4. Go back to transaction NACE. Select EF and click on Output types.

5. Let us use the output type NEU for our demonstration purpose. Double-click on
NEU.

6.

Ensure that the checkboxes Access to conditions and multiple issuing are
checked.

7. Now click on Processing Routines on the left hand side.

8. Ensure that there is an entry for Medium A (Distribution ALE).

9. Now go back to the main screen of NACE.
10. Select EF (Purchase Order) and click on Condition Records.

11. Select NEU and click on Condition records. Following pop-up box appears.

Select the radio button Purchase Organization.

The following list appears.

12. Enter a new record for the medium A (Distribution ALE) and 4 (Send
immediately) in the date/time.

13. Also ensure that you have done the necessary ALE configuration (not covered in
this document). In the partner profiles, use the message type ORDERS and the
IDOC type ORDERS05.

In the tab Message Control, use the process codes ME10 and ME11 for
PO Create and PO Change respectively.

Enhancement of IDoc Type

By Suraj Kumar Pabbathi
Usually enhancement takes place when the content in IDocs provided by SAP
are not sufficient for the business process. IDoc extension can take place
whenever dictionary table has a new structure appended required by the
business process.
In brief IDoc extension takes place when extra fields are required for the
business process.
Let us take a scenario and understand the process of IDoc extension.
In this scenario say visitor is different from the actual customer who has
came to the sales office in behalf of the customer to obtain the quotation or
inquiry etc. Or an authorized agent qualified by the actual customer to
order for items. So a field by name NAMEVI (Visitor) is added to Customer
master data. As there is no provision given by SAP to handle this, we need
to extend an IDoc.
The standard message type and IDoc type provided by SAP are DEBMAS
and DEBMAS05.
Consider the data in the table below for extending the IDoc. These details
can be understood in different sections in the process of extending it.
Basic IDoc type

DEBMAS05

Version

4.7

IDoc extension

DEBMASEXT

Custom segment

Z1KNA1

Fields in Custom Segment

Visitor

Parent of Custom Segment

E1KNA11

Outbound process
Step1. Customize kna1 table by appending a structure provided by SAP
(ZAKNA1)
Component

Component Type

VISITOR

NAMEVI

Step2: Write a module pool program to update some existing customers to

add data for Visitor.
Step3: Create a custom segment
Transaction Code: WE31
Segment type: Z1KNA11 Click

(create). Provide short text

Field Name

Data element

VISITOR

NAMEVI

Save
Step4: Create IDoc extension
Transaction

WE30

Object Name

DEBMASEXT

Choose Extension

Click

and it leads to next screen.

Linked basic type: DEBMAS05

Provide description and enter
Observe all the segments to be copied into your IDoc extension from linked
basic
type.

Select E1KNA11 and click

(create segment) to obtain a popup window

Provide the required values and observe child segment Z1KNA11 to be added
to
parent segment E1KNA11.
Step5: Release segment and IDoc extension
Transaction: WE31
Segment type: Z1KNA11

Path: Edit Set release

Step6: Assign Basic type to extension / messages

Transaction: WE82
Click

, then

Select DEBMAS message type against DEBMAS06 basic type

Click

provide the information

Message Type

Basic Type

Extension

DEBMAS

DEBMAS06

DEBMASEXT

Delete the earlier one from which it was copied.

Save.
Observe the result as follows

Version
4.7

Step 7: Check and Transport IDoc extension

Transaction: WE30
Object name: DEBMASEXT
Path: Development object -> Check

Ensure that there are no errors or warnings

Now transport
Path: Development -> Transport

Step8: Find suitable user exit for writing code to support IDoc extension
Transaction: SE84.
Click Enhancements
In short text provide *customer*
Find suitable enhancement to be VSV00001
Alternative way
Transaction: SMOD
Click F4 help for Enhancement
Path: F4help -> SAP Applications -> Logistics general -> Logistics Basic Data
->
Business partners -> Vendor Master.
Find the enhancement as VSV00002, which is an approximate user exit.
Now search for different extensions like VSV00001. Then see for its
components.
Identify the appropriate user exit to be EXIT_SAPLVV01_001 (Create Export
of
Additional Customer Master Segments). This user exit can be used in
outbound ALE
process, meant for filling the data into custom segments.
You have to identify here another user exit as EXIT_SAPLVV02_001, which
is
helpful for inbound ALE process. This user exit can be used to read the
segments
and post it to Application repository.
Step9: Develop a project to encapsulate enhancements and components.
Transaction: CMOD.
Enhancement: custex and click Create to provide attributes.
Click Enhancement Assignments.

Provide VSV00001, short text and save.

From the initial screen of the transaction, select components and click
change.
Find 4 components to be added.
Activate them.
Select user exit EXIT_SAPLVV01_001 for outbound process and double
click it. It leads to function builder.
Double click on provided include program ZXVSVU01 and press enter.
Now, write supporting code for IDoc extension, i.e., populating custom
segments in IDoc.
Check the code and activate.
Code in ZXVSVU01
*&---------------------------------------------------------------------*
*& Include

ZXVSVU01

*&---------------------------------------------------------------------*
*In this scenario, the E1KNA11 has been extended to accommodate
*User-defined fields in the customer table kna1. The name of the
*extended
*segment is z1kna11. There is one custom field: visitor
*&---------------------------------------------------------------------*
*Data declarations
DATA: kna1m like e1kna1m,
kna11 like e1kna11,
z1kna11 like z1kna11,
w_kna1 like kna1.
* make sure you are processing correct message type
check message_type eq 'DEBMAS'.
* make sure data is added after the correct segment
check segment_name eq 'E1KNA1M'.

* since customer number is not passed in this user exit, you need to go
* through the data records to find the customer number
loop at idoc_data.
case idoc_data-segnam.
when 'E1KNA1M'.
move idoc_data-sdata to kna1m.
when 'E1KNA11'.
move idoc_data-sdata to kna11.
endcase.
endloop.

" case idoc_data-segname.

" loop at idoc_data.

* select data from the user-defined fields in kna11.

select single *
from kna1

" Customer master table

into w_kna1
where kunnr = kna1m-kunnr.
if sy-subrc eq 0.
* set the idoc extension name for control record
idoc_cimtype = 'DEBMASEX'.
* clear custom fields from kna1 to extended segment
clear z1kna11.
* copy custom fields from kna1 to extended segment
move-corresponding w_kna1 to z1kna11. " field name must be same
* condense all fields of extended segment
condense: z1kna11-visitor.
* populate segment name in the data record, copy data contents into it
* and append the data record to existing data records in
move 'Z1KNA11' TO IDOC_data-segnam.
move z1kna11 to idoc_data-sdata.
append idoc_data.

" administrative section

" data section

endif.

" if sy-subrc eq 0.

Step 10:
Define Logical System
Assign client to Logical System
Maintain RFC Destination
Maintain Customer Distribution
Model
Generate Partner Profiles
Distribute Customer Distribution
Model
INBOUND PROCESS
Step 11: Append the custom structure to the table KNA1 similar to the
process done
in outbound process.
Step 12.
Define Logical System
Assign client to Logical System
Generate Partner Profiles

Step 13. Execute the transaction to Send Customers from Outbound

system.

Step 14. Now in the Inbound system, create the project in the similar way
as done at
outbound side.

In the user exit EXIT_SAPLVV02_001, find include ZXVSVU02. Write the

code to
support IDoc extension.
Code in ZXVSVU02
*&---------------------------------------------------------------------*
*& Include

ZXVSVU02

*&---------------------------------------------------------------------*
data: kna1m like e1kna1m,
kna11 like e1kna11,
z1kna11 like z1kna11.
data fs_kna1 type kna1.

message i000(0) with 'INBOUND PROCESS CALLED'.

LOOP AT IDOC_data.
case idoc_data-segnam.
when 'E1KNA1M'.
kna1m = idoc_data-sdata.
when 'E1KNA11'.
kna11 = idoc_data-sdata.
when 'Z1KNA11'.
z1kna11 = idoc_data-sdata.
select single *
from kna1
into fs_kna1
where kunnr = kna1m-kunnr.
if sy-subrc eq 0.
update kna1
set visitor = z1kna11-visitor
where kunnr = kna1m-kunnr.

else.
idoc_status-docnum = idoc_control-docnum.
idoc_status-status = '51'.
idoc_status-msgty = 'E'.
idoc_status-msgid = 'ZE'.
idoc_status-msgno = '005'.
idoc_status-msgv1 = kna1m-kunnr.
append idoc_status.
endif.
endcase.
endloop.

" if sy-subrc eq 0.
" case idoc_data-segnam.
" LOOP AT IDOC_data.

Step 15. Assign FM to extension/Message type

Transaction:

WE57

Path: Change New Entries

Select IDOC_INPUT_DEBITOR against DEBMAS06 basic type, to fill
extra
information as shown below.
Function Module
Extension

Basic Type

IDOC_INPUT_DEBITOR DEBMAS06
DEBMASEXT

Message Type
DEBMAS

Step 16. Execute the transaction to Get Customers.

And observe that records with extra

data are saved in database.
Conversion of IDOC's to XML format

By Suresh Parvathaneni and Narasimha Motupalli

This Tutorial details about the step by step in conversion of IDOCs to XML format for
further use in XI or any other application. It is assumed that the reader of this Tutorial
has some knowledge in ALE, IDOCs and Change Pointers.
Scenario: Conversion of the Material IDOC (Message type: MATMAS) to XML
format and store the same in the application server of SAP.
Approach
Change pointers are used for sending IDOCs for master data like Material Master. To
work with Change pointers, following two steps have to be performed:

Turn on change pointer update generally

Providing the message types to be included for change pointer updation.

To do the above configurations:

TCode: SALE --> IDOC Interface / Application Link Enabling (SALE) --> Modeling
and implementing Business Processes --> Master Data Distribution --> Replication of
Master Data
ALE Configuration Steps:
1.
2.
3.
4.

Creation of logical system for the sender system.

Assignment of logical system to the client.
Create a logical system for the recipient
Creation of RFC destination (Connection type:TCP/IP)

5.

Creation of Model View (TCode: BD64).

6. Save the Model View and Generate Partner Profiles.

7. There might be a problem with the automatic Port creation. Creation of the
port has to be done manually.
8. Create an XML Port from the transaction WE21 (Port type: XML File).

Here directory is the path on the application server. The Function Module is used for
file naming conventions. Any of the SAP provided function modules could be used
for this (Use F4 help to check on this) or create any custom function module for any
other naming conventions.
In the outbound trigger tab, mention the RFC destination created earlier.

9. Make an entry in the partner profile generated earlier for message type
MATMAS.

10. A background job need to be scheduled, for a periodic run (interval as

required) for the program RBDMIDOC with the message type MATMAS.
11. Depending on the settings in the partner profiles, it may be necessary to send
IDocs directly by executing the program RSEOUT00 (if the setting is to
Collect IDocs)

Test the above scenario by creating a material using MM01.

An XML file would have been created in the directory
specified in the XML port. The file could be downloaded
onto the front-end system using the transaction CG3Y.
Download IDOC to excel, html or any other format
By Sravani
To download an IDOC into an Excel, HTML or any other format:
Go to transaction IDOC

Select the radio button Analyse IDoc field values and click on Execute.

Enter an IDoc number and select the check box Also output empty fields. Click on Output in
Internal Form.
Following screen appears:

Click on Execute.

Now click on List -> Save/Send -> File

Now select the required format and hit Enter. The IDoc is now stored on your system in the
required format.

Change Pointers in ALE

By Kamesh G, IBM
1. Change Pointers
Change Pointers are log entries to remember all modified records relevant for ALE. Change
pointers are log entries to table BDCP, which are written every time a transaction modifies
certain fields.

2. Activate/De-activate change pointers

2.1 Activate change pointers

A) TCODE: BD50 (Activate change pointer for message type)

Below screen shows Activating change pointer for Message Type 'MATMAS'

In above screen if active flag (Check box) is unchecked then Change pointers
is deactivated.
B) TCODE: BD66 (Segment Field-Change Document field)
Change Document field should exist in this TCODE align particular Segment
type.
The above screen shows the fields in change document.
Message Type: MATMAS
Segment Type: E1MAKTM

The below screen shows actual fields in segment.

C) TCODE: BD61 (Activate change pointers generally)

The Below screen shows how to activate change Pointers generally.

2.2 De-activate change pointers.

If some messages types are no longer to be distributed by change pointers, you can
deactivate change pointers for this message type (by removing active flag in BD50). We can
deactivate change pointers for the message type and reactivate them again in transaction
BD50.
Following screen shows how to deactivate change pointers for reduced message types.

Example: I have taken ZMATMAS. Here the shaded part is shows Deactivate change
pointers PUSH button.
3. Creating IDOC with change pointers.

TCODE: BD21
Purpose: Create IDOC type from change pointers
Program: RBDMIDOC
We can create IDOCS from change pointers with the report RBDMIDOC

The report tells how many master and communication IDocs have been
created.

TCODE: BD22
Purpose: Delete Change Pointers
Program: RBDCPCLR

Here we can delete obsolete and processed change pointers in specific time and for specific
message type.

Example:
In above screen I have selected obsolete change pointers for MATMAS message type.

Example:
In below screen I have selected processed change pointers.

Execute

Extending the standard IDOC for Outbound delivery (VL02N)

By Rajeev Sharma, Intelligroup
Scenario:
Step by step procedure for extending a standard IDOC, populating the custom segment and
trigger the extension IDOC from VL02N transaction.
Extending an IDOC:
This begins with creating a custom segment; custom segment creation is developed in
transaction WE31.

Custom segments begin with Z1 (just a name standard), now go to T-code: WE31 and type
your custom segment name as Z1EDLPI and click on the create button as shown below.

When the create button is clicked, the below shown screen will be displayed. Enter a short
description for the custom segment and add the required field name and the corresponding
data element. Once the required fields are added click on the save button.

After clicking on save button, click on back button you will see the below shown screen. Now
click on the segment definition you have created and do Set Release from EDIT menu.
Note: Without releasing your segment definition you cannot use the segment.

With this, custom segment creation is completed.

Next step is to create an extension IDOC with the above created custom segment, Go to
transaction WE30.
Enter a name ZDELVRY03 for the extension IDOC and check on the Extension check box
and click create button.

The following popup screen will be displayed. Click on the Create New radio button to create
an extension with the help of a Basic IDOC type. Enter the standard basic type name
DELVRY03 in the Linked Basic type field and enter a short description and click continue.

The following screen will be displayed with all the standard segment of basic type delvry03.
Now we need to add our custom segment to the required segment, in our example we will
take segment E1EDL22. We will have to add the custom segment Z1EDLPI to segment
ELEDL22.

Select the segment E1EDL22 and click on the create button, an information message will pop
up and say Extension segment type(s) will be in child segment type(s) of E1EDL22. Click on
continue. Another pop up will be prompted for entering the custom segment name and
attributes.
Enter the name of the segment Z1EDLPI, minimum and maximum occurs as shown below.
Note: Attribute entries may vary depending on the requirement, the below shown attribute
entries are for our requirements only.

Newly added segment is seen as below.

Save the extension IDOC and click on the back button and go to Utilities -> Enhancement
->Assign basic type.

The below pop up will be prompted with the basic type name, which we have used to create
our extension type. In our case it is delvry03. Click on the continue button.

Now click on the Set Release menu item in EDIT menu to release the extension IDOC.

A pop up will be prompted as shown below, click on YES to release the Extension IDOC.

We have successfully created our extension IDOC ZDELVRY03.

Next step is to create a logical message type. Go to transaction WE81.
By default the screen will be in display mode, go to change mode to enter a new entry.
Give some name to the logical message type and a short description. Save the entry.

Next step is to assign the created extension IDOC type with the above created logical
message type. This is carried out in transaction WE82.
Here you will assign the message type with the extension IDOC type along with the basic type
and release version combination as shown below.

Save the entry.

Next step is to create a partner profile and assign our message type to it. Also provide details
like output types, process code etc in message control tab. To create a partner profiles go to
transaction WE20.
Note: The partner number in partner profile and ship to party number in delivery (VL02N)
should be same. In the below shown example we are using Delivery number 80016347 and
hence the ship to party 1171 will be our partner number. In WE20 transaction, expand the
partner type Partner type KU Customer and find the partner number 1171. If it doesnt exist
then click on the create button and type the partner number 1171 and save the entry.

Now click on the Create Outbound Parameter button (A icon with green plus symbol).

The following screen

will be displayed. Enter the partner role(optional), message type, receiver port, basic type and
extension type names respectively. Also select the Transfer IDOC immed. Radio button. And
save the entries.

Now click on the message control tab as shown below and click on the insert row icon (green
plus symbol) to enter the necessary details.
Use the F4 help to select the appropriate application, in our case it is V2 (For Delivery). The
next entry is choosing the message type (note that this message type is different from the one
which we have created earlier, this message type is used to set the output types in VL02N
transaction). In our case the message type is LD00.
NOTE: Appropriate message types are selected with the help of NACE transaction. In NACE
transaction, select the appropriate Application (V2) and click the output type PUSH button in
the application tool bar. List of output types will be displayed, see which output type is
configured for your required output medium (ALE, EDI, PTINTER, FAX etc.) you can use only
those output types as message types in partner profile.
Next entry is to choose the process code.
For each applications (V1for sales order, V2 for delivery, V3 for invoice) there are set of
process codes maintained in transaction WE41 (For outbound process code). Go to WE41
transaction and select the appropriate process code. In our case it is DELV.
NOTE: The process codes are assigned to function modules which has the code to process
(Populate the IDOC segments, save the segment data in EDI specific database table etc) the
IDOC segments at runtime.
Once the necessary entries are made click on save button.

This ends your partner profile creation.

Time for a little coding, as stated earlier the process codes are associated with function
modules to process our extension IDOC. To see the function module double click on the
process code DELV. It will take to the following screen.

Next step is to find the customer exit in the function module to populate the custom segment
in the extension IDOC. Check for the PERFORM that fill the Data records internal table and
proceed to find the relevant customer exit or directly you can search customer exit for Data
record. Usually the customer exits for Data records will be customer-function 002 .

Note: FM: IDOC_OUTPUT_DELVRY has all the standard logic to populate the standard
segments of the extension IDOC ZDELVRY03. We use the customer exit to imply our logic
on standard segments and to populate custom segments. In our case we are using it for latter
case.

The below code has the logic for adding the custom segment Z1EDLPI as child of E1EDL22
and what data needs to be populated in the fields of the custom segment. Save and activate
include ZXTRKU02.

Note: The code written above will be executed only if this enhancement components Project
is activated in SMOD.

With this all the necessary configurations on the EDI IDOC front is over. The next step will be
configuring the output types in VL02N to trigger the Extension IDOC. To do this, go to
Transaction VL02N.

Select the Send Immediately option and click on back button and save the Delivery.

When the delivery is saved successfully we can see the IDOC number by selecting the output
type and clicking on processing log push button as shown below.

Now to see whether the custom segment has been populated as desired and to know the
status of the IDOC, go to transaction WE02.