How To Extend An Outbound IDoc
How To Extend An Outbound IDoc
How To Extend An Outbound IDoc
Applies to:
Developing and configuring SAP Intermediate Documents (IDocs) for data transfer.
Related till version ECC 6.0.
For more information, visit the Idoc homepage and the ABAP homepage.
Summary
This document provides details on why we need an extended Idoc and how to create it. We will also see a
step by step procedure of creating an extended Idoc. The Steps involve creating a segment of required
structure, Extend basic Idoc and assign new segment to extended Idoc. Also involves Maintaining message
type, partner profile and implementing the User exit. Further the Idoc is transferred to the destination. A
whole overview of Extended Outbound Idoc can be learned with this article. Though some related
information already available in SCN, to make it more comprehensive, I plan to explain it using screen shots
along with a real world example making it easier.
Author Bio
Lakshmi Narayana Neeli works with Intelligroup Asia Pvt Limited since 2008. He has good knowledge in SAP
ABAP and CRM.
Table of Contents
Introduction .........................................................................................................................................................3
Why We Need an Extended Idoc?..................................................................................................................3
Business Scenario – Invoice...............................................................................................................................4
Basic Steps in Invoice Extension Outbound Idoc ...........................................................................................4
WE31- Create Segment Type ......................................................................................................................................4
Create IDOC Type ..........................................................................................................................................9
Create Logical Message Type ......................................................................................................................15
Create Output Types and Assignment to IDOC Type...................................................................................16
Creating Partner Profile.................................................................................................................................17
Finding and Updating Customer Exit Using SMOD ......................................................................................21
Outbound Process Code...............................................................................................................................25
Create a Transaction and Send IDoc............................................................................................................31
Monitoring IDoc .............................................................................................................................................34
Related Content................................................................................................................................................36
Disclaimer and Liability Notice..........................................................................................................................37
Introduction
SAP’s presence in the IT world is propelled by its unique integration of all its sub systems to a central
system. More than a linking together of applications, implementing SAP redirects the flow of information
through a company and its partners to enhances the potential of its business functions. This flow of
information is enabled by a core element - Intermediate Document, or IDoc. Technically, the IDoc is an
example of Electronic Data Interchange (EDI).The IDoc concept borrows the best features of EDI and
combines them with the best features of conventional transaction file formats. SAP R/3 systems send out
data through Idoc (Intermediate Document), which in internally has segments and fields containing the data.
To create a segment with two VBRK-KTGRD (Account assignment group for this customer) and VBRK-
MANSP (Dunning block)
Click here
So segment is created and set to release. After you release the system automatically updates the version
release (Here it is 700 in above diagram). Only one unique version segment is released per version i.e. here
ZTRGEDC with release 700 exists once only and no changes are allowed until it is in released status (the
Tick mark in Released tab).
So in order to make changes unrelease the segment and make changes and once again “set release” it. So
now ZTRGEDC segment is created and set to release. Now we need to create the IDOC type.
Create an Idoc by
clicking on create
We get the following screen showing the set of segments. Since the extensions VBRK-KTGRD and VBRK-
MANSP belong to “HEADER” tab in transaction VF02 the extension is done for the relevant segment type
E1EDK01 related to “Header General Data”. We extend it as shown.
Click on Create
Click Create
Select this
The attributes include whether it is a mandatory Segments. The Maximum and minimum numbers specify the
no of times the segment can be repeated in sequence. The Hierarchy level suggests the parent relation
ships. For a segment which do not have a parent segment either have hierarchy level 1 (if they cannot be
repeated) or hierarchy level 2 (if they can be repeated). Segments which have a parent segment have a
hierarchy level which is one higher than that of their parent.
The extension is
created as shown
Save it.
Click here
Click here
Click here
We can also create the customized logical message type according to the requirements. Since we are using
the invoice here we can use the existing message type INVOIC.
In transaction WE81- Logical message type we can see for message type INVOIC
Since we have a standard message type we did not create it else we can create using NEW ENTRIES tab.
Saved successfully
So we created Output types and Assignment to IDOC type as an entry. This is used in the Idoc processing.
Select Customer
We chose 1600 as an example, for general you can choose any customer
In real time, we do not use test flag in message control to send an Idoc. We used this test flag enabled only
to show that we are creating the IDoc for ‘testing’ purpose on the outbound side.
The Message type, Partner Role, Receiver port, Basic and extended Idoc type with output mode “Transfer
Idoc immediately” is given as a partner profile as shown in above document.
Click on the message control to give the values of application, Message type and process code.
Save it
These key fields application, Message type and process code assigned in the message control together
uniquely identify a message type which uniquely identifies an IDoc type.
The key fields application, Message type and process code are used as
Application: The Application specified in message control determines the output type and uniquely identifies
a message type which can be assigned uniquely to an IDoc type.
For Example: 'EA' is used for ‘Purchasing RFQ' in Materials Management (MM).
V3' is used for 'Billing' in Sales and Distribution (SD).
Message type: Message type along with the application uniquely identifies a message type which can be
assigned uniquely to an IDoc type.
For Example: 'LAVA' = 'Shipping notification' in dispatch (application 'V2').
Process code: The Process code is used by an IDoc Interface to determine the application selection
module which converts the SAP document into an IDoc.
For Example: ME10: Purchase order (MM)
Here the values are chosen depending on the description having billing or invoice.
The application is V3: Billing
The Message type MD00: MKS -Invoice O/P type
The process code SD09: INVOIC: Invoice
We get the function module embedded in the process code where the functionality is coded. This is a Top –
Down approach of finding the relevant function module to write User Exit. We can also find the process code
and relevant function module in the Bottom - Up approach.
The function module which is embedded in each process code follows a naming convention
“IDOC_<OUTPUT / INPUT >_NAME OF BASIC TYPE”. This helps in finding the process code and then the
other attributes. For our example here we do an outbound with basic Idoc INVOIC. So the function module
will be “IDOC_OUTPUT_INVOIC”.
Search this in Function builder SE37 and find the relevant process code in transaction codes WE40
(inbound) or WE41 (outbound). Here we followed the top approach. Many times depending on the
description of the application, message type we find the relevant key fields and link them up.
But if we could not find the relevant function module then there is another method of finding it. The process is
explained below using the Transactions SMOD and CMOD. We can use this method as an alternative. We
choose among the Bottom - Up, Top – Down and SMOD depending on the scenario.
After clicking on display. Go to the “Attributes” tab and look for the package name.
Here we get the Package as “VED”, Use this Package name in SMOD to find the respective function module.
Go to Transaction SMOD and give the value of Package we got (here “VED” ) in F4 help or utilities Æ Find.
We get the set of Exit names; Find the most suitable by the short text description. The description here
”User Exit for Idoc infotype” is more apt. So select the exit “LVEDF001” to get the list of function modules
From which we select the option which is more apt.
Click on components
This is the function module where we are going to add the functional change.
Go to CMOD and give “BPID” standard enhancement or you can create a new project with ‘LVEDF001’
Standard Project
BPID is given
Click here
Click here
You can Click here to directly go to the function “exit_saplvedf_002” or follow the path as shown below.
You need to add the changes required in this customer exit. The process is explained in detail below.
So the process using the Transactions SMOD and CMOD is explained above. Now we need to make the
changes in the code according to the requirement.
Double click
We can get into the function module to find the customer exit. So after getting into the function module how
you find the relevant customer exit is defined below. Double click on the function module to get to the next
screen.
Double click
You will find a customer function for control record “customer-function '001'” which is not useful for us. Find
the perform which normally come at the end of the Function module having a naming convention starting
with “Fill” or “Fuellen”. This is shown in the above screen shot.
Double click
Double click
Since we are adding our segment to e1edk01 find the perform having this string. Here it is
perform fill_e1edk01. Double click on it.
Double click
At the end of it you will have perform with name “perform customer_function.” Double click it. You will get
the “customer-function '002'” which is the required customer function. Double click it.
Double click
Double click
We will get the required customer function “function exit_saplvedf_002” with an include “include
zxedfu02”. This will lead you to the customer exit where we write the required changes.
Double click
IF SY-SUBRC = 0.
Wa_ZTRGEDC-KTGRD = WA_VBRK-KTGRD.
Wa_ZTRGEDC-MANSP = WA_VBRK-MANSP.
INT_EDIDD-SEGNAM = 'ZTRGEDC'.
MOVE Wa_ZTRGEDC TO INT_EDIDD-SDATA.
APPEND INT_EDIDD.
CLEAR INT_EDIDD.
ENDIF.
ENDIF.
ENDIF.
Press enter
Document is saved
Click here
Monitoring IDoc
In WEo2 transaction gives the details as shown and finds the generated IDoc.
Related Content
Extending an IDoc Type
Extension of IDoc types and Processing
Idoc homepage
For more information, visit the ABAP homepage.