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 frequen
t, 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.

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

user

exit

is

available

MASTERIDOC_CREATE_XXXXX where XXXXX is the message type.

in

function

module

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

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

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.

left

hand

side.

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
VISITOR

Component Type
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

Step 7: Check and Transport IDoc extension

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

Version
4.7

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.

" administrative section

" data section

append idoc_data.
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.

" if sy-subrc eq 0.

endcase.

" case idoc_data-segnam.

endloop.

" 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

Basic Type

Message Type

Extension

IDOC_INPUT_DEBITOR

DEBMAS06

DEBMAS

DEBMASEXT

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

Save the Model View and Generate Partner Profiles.

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

8.

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.