IDoc Basics For Functional Consultants - SAP Blogs

Download as pdf or txt
Download as pdf or txt
You are on page 1of 39

Community Topics Groups Answers Blogs Events Programs

Ask a Question Write a Blog Post Login

Niranjan Nagle
December 31, 2012 | 12 minute read

IDoc Basics For Functional


Consultants
 314  596  796,674
Follow

 Like ABSTRACT

Today IDocs are used in most SAP applications for


 RSS Feed
transfer of message(information) from SAP system to
other systems and vice versa. Though lot of
documentation is available on IDocs it is difficult for a
functional consultant to understand such documents
due to their technical nature. While a functional
consultant is not expected to know the IDoc concepts
in its entirety, an effort has been made to capture the
minimum necessary information that one needs to be
aware of in order to handle project/support issues on
IDocs.

OVERVIEW

IDoc is an SAP object that carries data of a business


transaction from one system to another in the form of electronic
message. IDoc is an acronym for Intermediate Document. The
purpose of an IDoc is to transfer data or information from SAP
to other systems and vice versa. The transfer from SAP to
non-SAP system is done via EDI (Electronic Data Interchange)
subsystems whereas for transfer between two SAP systems,
ALE is used.

IDoc can be triggered in SAP system or in EDI subsystem. This


depends on the direction in which IDoc is sent and is called as
Inbound IDoc and Outbound IDoc accordingly. In case of
outbound flow, IDoc is triggered in SAP through document
message control which is then sent to EDI subsystem. EDI
converts the data from IDoc into XML or equivalent format and
then sends the data to partner system through Internet.

For inbound flow, EDI converts partner data and IDoc is


created in SAP. After successful processing of this IDoc,
Application Document is posted in SAP.

EDI STANDARDS AND IDOC

“EDI is electronic exchange of business document between the


computer systems of business partners, using a standard
format over a communication network”. EDI stands for
Electronic Data Interchange.

For transmission of information electronically, two widely used


standards are ANSI ASC X12 and EDIFACT. ANSI ASC X12 is
a committee formed by representatives of major organizations,
government bodies and EDI software companies which defines
standards and guidelines for information interchange over EDI.
UN/EDIFACT stands for United Nations EDI for Administration,
commerce and Transport and was formed in 1985 using ANSI
X12 and UNTDI (United Nations Trade Data interchange) as
base standards. ANSI X12 describes business document as
transactions and each transaction is represented by three digit
number e.g. 850 – Purchase Order, 855 – Purchase Order
Acknowledgement. EDIFACT describes business document as
messages, represented by standard names e.g. ORDERS for
purchase order.

IDOC TERMINOLOGIES

IDOC (BASIC) TYPE

IDoc Types are based on the EDI standards and mostly on


EDIFACT standards.

Basic Types (or IDoc Type) defines the structure of an IDoc.


Each basic type describes standard IDoc segments, format of
data fields and their size. Basic Type also defines number of
segments and fields in an IDoc. All the fields that are necessary
for transmission of message for a particular business
transaction are mapped in different segments. It also defines
the structure and relationship of IDoc segments along with
mandatory and optional segments.
IDOC EXTENSION

Basic type contains all the standard fields that are necessary
for carrying out a business transaction. However, if any
additional values are to be sent to the partner then we can
make use of the IDoc Extension feature. IDoc extension is
extension of basic type and contains additional custom IDoc
segments and fields that are not available in standard basic
type.

IDOC SEGMENTS

IDoc segments contain the actual data that is sent to or


received from a partner. These segments contain the actual
values that are sent as part of IDoc transmission.
PARENT AND CHILD SEGMENTS

IDoc segment is termed as Parent segment if it contains its


own segments. The dependent segments are called as child
segments.

INBOUND/OUTBOUND IDOCS

IDocs sent outside the system are termed as Outbound IDocs


and the ones that are received into the system, are called as
Inbound IDocs.

IDOC DIRECTION

This signifies the direction is which information is sent and is


similar to terminology used in mails. If information is sent
outside the system then the direction is outbox when it is
received into the system then direction is inbox. In SAP Outbox
direction is represent by “1” i.e. outbox and Inbox direction is
represented by “2”.

PARTNER
Partner is the Business Partner with which the exchange of
information is to take place using IDoc. It can be a vendor or
customer or any other system. Depending on the direction of
information in which the information is sent it plays a role of
either a “sending partner” or a “receiving partner”.

PARTNER TYPE

Partner type/role is used to identify partners within the sap


systems. Partner type is KU for customer, LI for vendor and LS
for Logical System.

MESSAGE TYPE

IDoc processing involves transmission or receipt of document


in the form of a message, each of which represents a
document in SAP. These documents can be Order, Shipment
Confirmation, Advance Shipping Notification, Goods Receipt, or
Invoice. Message type is associated with Basic IDoc Type
(Basic Type) and defines the kind of data or document that is
exchanged with the partner.
PROCESS CODE

The process code contains the details of the Function Module


that are used for IDoc processing. Message Type can be linked
to the Process code.

PORT

IDoc Port contains the information about the way data is sent
between the source or target system. The type of port defines
the information contained within the port. For port type
“Internet” Port will contain IP address of the target system. For
port type “file”, directory or file name information is maintained.
“tRFC” port contains information about the RFC destination of
the target system. For IDoc transmission using ALE “tRFC”
ports are used.

PARTNER PROFILE MAINTENANCE

PARTNER PROFILE (WE20)

Partner profile must be maintained for all the business partners


to whom we want to send or receive the IDocs. The TCODE for
maintaining the partner profile is WE20.

Double clicking on the Partner will show the following screen:


Partner profile contains parameters for Inbound and Outbound
processing of IDocs. For each message type we can maintain,
inbound/outbound options, message control, post processing
options and contact information within Inbound and outbound
parameters.

OUTBOUND OPTIONS (OUTBOUND PARAMETERS)

This involves sender/receiver port, Output mode and relation to


IDoc type i.e. Basic Type and extension.
MESSAGE CONTROL (OUTBOUND PARAMETERS)

This contains application for which IDoc will be created e.g. EF


for Purchase order, the message type of the application that will
trigger the IDoc and Process Code that will convert SAP
document to an IDoc. For example, if PO is to be sent to the
Vendor AXXXXZ, then in the outbound option of the partner
AXXXXZ we need to maintain the message type ZXX1 and link
it to the Process Code ME10. So when message type ZXX1 is
triggered in the PO then an IDoc will be created for the partner
vendor AXXXXZ.

Process Code is linked to the Function Module in SAP that


converts application data into an IDoc. Standard function
modules are provided by SAP for this conversion however
these can also be customized as per business needs.
Change Message Indicator indicates whether the IDoc is
sentas a notification of change. For example, Purchase Order
change messages are sent to vendor using EDI standard
message type 860.

Separate message type should be triggered in the purchase


order for PO change. Additional line with change message type
must be added in the Message control tab with change
message indicator on.
INBOUND OPTIONS (INBOUND PARAMETERS)

For inbound options process code is maintained in the Inbound


screen only. IDoc processing can be triggered by background
program and triggered immediately.

POST PROCESSING (INBOUND/OUTBOUND


PARAMETERS)

In the post processing option we can maintain the workflow


details of the users or positions to which an error notification
will be sent if an IDoc processing fails.
TELEPHONY (INBOUND/OUTBOUND PARAMETERS)

We can also maintain the contact details in the telephony


option.

EDI STANDARD (OUTBOUND PARAMETERS)

EDI standard screen contains the details of the Standard EDI


terminology used for the IDoc transmission.

For example, Message Type 850 is an EDI standard for


Purchase Order IDoc and is linked to IDoc Message Type
Orders.

IDOC STRUCTURE AND RECORDS

STRUCTURE

IDoc structure is divided into Control Record, Data Records


and Status records.
These records are stored in the transparent tables in SAP.
These are EDIDC, EDID4 and EDIDS.

CONTROL RECORD (EDIDC)

It contains information such as IDoc number, direction, IDoc


Status, Basic Type, Message Type, Partner (Sender/Receiver),
date and time of creation/update, Interchange File or ISA
number,etc.
DATA RECORD (EDID4)

It contains the details of the IDoc segments.


IDoc segment has fields that contain the data necessary for
posting the documents.
STATUS RECORDS (EDIDS)

IDoc Status defines the processing status of the IDoc. IDoc


statuses are used to track the IDoc and its various processing
states. Status Numbers represents IDoc status. Current status
of the IDoc is present in Control record.

Initial Status numbers are 64 for inbound and 03 for outbound.


Successful status is 53 for inbound and 16 for outbound IDocs.
SENDING AND RECEIVING IDOCS

TRIGGERING AN OUTBOUND IDOC

Outbound IDocs can be triggered from the output message


types of Purchase Orders, deliveries, Material Documents,
invoices, etc. The following figure shows that once the output
ZXX1 of PO XXXXXXX1 is processed an IDoc
“000000XXXXXXXXX1” is added/created.

The relationship between the IDoc and the application


document can be found in two ways:

1. Relationship tab of IDoc


2. Relationship tab of Application Document, e.g. PO, SO,
Material Document, etc.

The initial status of this IDoc will be 30, which after successful
processing will convert into status 16.

A successful outbound IDoc will pass through all the above


statuses in reverse order (01-03-18-06-12-16). Each status
represents an IDoc validation step. If an IDoc passes all the
validations it would reach status 16. These different validation
steps for outbound IDocs are explained below:

01: IDoc generation successful

30: IDoc is ready to be processed by IDoc Processing job


03: IDoc data is passed to the Port

18: IDoc successfully triggered EDI subsystem

06: IDoc data translated to EDI format

12: IDoc is dispatched successfully to the partner

16: Partner has received the IDoc successfully

IDoc can possibly fail at any of the above steps during


validation.

RECEIVING AN INBOUND IDOC

The initial status of an inbound IDoc is 64 and successful status


is 53.

Different validation steps for inbound IDocs are explained


below:

50: IDoc received successfully in the system

64: IDoc is ready to be processed by IDoc processing job

53: Application document created and saved successfully. The


document number can be found by expanding the status node
53
An inbound IDoc goes through all the above statuses in reverse
order (50-64-53).

IDOC PROCESSING

AUTOMATIC/IMMEDIATE PROCESSING

In this case, IDoc are processed immediately as they


generated or added in the system. The check “Transfer IDoc
immediately” is selected in Outbound Options and “Trigger
Immediately” is selected in Inbound Option. These checks are
generally used when the real time information exchange is
necessary between two systems.

MANUAL PROCESSING

IDocs can also be manually processed using the TCODE BD87


in SAP.

PROCESSING VIA BACKGROUND JOB

IDoc processing by background is the most preferred way of


processing the IDocs. Following Programs are used from
processing the IDocs using background job:
RBDAPP01 – Inbound IDocs

RSEOUT00 – Outbound IDocs

REPROCESSING IDOCS

On the basis of IDoc statuses different programs can


be used for reprocessing of failed IDocs. These are
given below:

SEARCHING IDOCS IN SAP

TCODE WE02/WE05: GENERAL SEARCH

IDocs can be displayed in system via TCODE WE02 and


WE05. If IDoc number is not known then search can be made
on the basis of IDoc Date, Direction, BASIC TYPE, MESSAGE
TYPE, and PARTNER NUMBER. Partner number can be
found in the Output Messages of the documents.
IDoc search can also be made on the basis of ISA or Transfer
file Reference.

TCODE WE09: SEARCHING DATA IN IDOC SEGMENTS

If we are looking for specific information within the IDocs


Segments then this can be found using TCODE WE09. This is
useful if you are searching for a particular information in similar
kind of IDoc within IDoc segments. For example, if you want to
search a particular Purchase Order number e.g. 100000001 in
multiple IDocs which lies in Segment E1EDK01 of an IDoc
under field BELNR. Then the search can be executed in the
following manner.

IDOC VALIDATIONS, COMMON IDOC ERRORS

AND SOLUTION

Though, the IDoc failure may not be related to any of the above
mentioned reasons, the best way to find the IDoc error is to
compare the existing IDoc with the good example. Good
example IDoc can be easily searched with any of the IDoc
search methods as described above.
DOCUMENTATION FOR IDOC TYPES

IDoc documentation can be found using TCODE WE60 and


can be helpful to obtain information of the IDoc Type or its
particular segment. It also provides information such as
mandatory and optional segments, minimum and maximum
number of segments, etc.

GENERAL INFORMATION FOR COMMON IDOC

MESSAGE TYPES

The following list gives the Basic Type and Message Type
combination for common idocs
ARCHIVING/DELETION OF IDOCS FROM

DATABASE

As IDocs grow older they are archived and deleted from the
database. Archived IDocs can be viewed using TCODE SARI
in Achieve Explorer using archiving object as IDoc. Following
are the few programs that are used for archiving and deletion of
IDocs from database.
Alert Moderator

Assigned Tags

MM (Materials Management)

SAP ERP

edi

enterprise resource planning

idoc

sap

sap erp logistics materials management


Similar Blog Posts 
Inbound Delivery : Automatic Creation from Outbound Delivery
By Former Member Oct 06, 2014

Functional Consultant roles and understanding on SAP Interfaces


By Abdul Saleem Mar 21, 2022

Display Material Picture in Material Master Screens MM01/MM02/MM03


By Lalitha Varalakshmi C S Mar 22, 2022

Related Questions 
IDOC's Process in MM in a easy way
By Former Member May 02, 2008

RELATION_NOT_FOUND error Rollout


By Ramon Pajes Jun 01, 2021

Basic ABAP knowledge for Functional consultants


By Former Member Apr 15, 2008

Join the Conversation 


SAP TechEd
Tune in for tech talk. Stay for inspiration. Upskill your future.

SAP BTP Learning Group


SAP Business Technology Platform Learning Journeys.

Coffee Corner
Join the new Coffee Corner Discussion Group.

314 Comments

You must be Logged on to comment or reply to a post.


B S Hada
December 1, 2016 at 7:30 am

Very Informative, thanks

Like 3 | Share

Santhosh Venreddy
December 2, 2016 at 10:16 am

Many Thanks for this information

Like 1 | Share

Former Member
December 4, 2016 at 2:11 pm

It's really very helpful..

Like 1 | Share

Former Member
December 20, 2016 at 4:25 pm

Hi Niranjan Nagle,
thank you so much for this helphul information, I've read your explanation about IDOC and I'm thinking to
use it to post a Sales Order on SAP.
My client is asking me to post SO based on the existing data in the Purchase order.

Based on your explanation in the "Overview" paragraph, you said " for transfer between
two SAP systems, ALE is used" do you think if I used ALE it will be feasible for such
requirement.
Please let me know your opinion and if you have any explanation regarding my client requirement,
Thank you so much,
Moha

Like 0 | Share
Former Member
January 16, 2017 at 8:47 pm

Hi Mohamad,

Yes, it is true that ALE can be used in this scenario. I am assuming you are trying to post SO in one
system that triggers PO in another system.

You still have to generate outbound IDoc (for SO) in sending system and Inbound IDoc (for PO) in
receiving system. Please check with your basis consultant on the usage of ALE in this scenario.

Regards,
Niranjan

Like 0 | Share

CMA Ramesh Kolluru


February 23, 2017 at 10:11 am

Excellent Article ...aptly tailored for functional consultants like me. Thanks a lot for your efforts and time.

Like 0 | Share

DAMODAR SAI MALLIKA


May 20, 2017 at 3:20 am

Very Helpful.. Good Work

Like 0 | Share

Former Member
June 3, 2017 at 8:48 am

very useful. Thanks.

Like 0 | Share

Former Member
September 16, 2017 at 6:19 am

This is Very useful document.

Thank you Very Very much

Respect your hard work and knowledge sharing spirit

Like 0 | Share

Former Member
November 3, 2017 at 2:54 pm

Very much informative.

Thank you.

Like 0 | Share

Former Member
January 8, 2018 at 11:15 pm

I found this information really useful. Well explained. Appreciate the work you have put into this.

Like 0 | Share

Former Member
February 8, 2018 at 6:30 am

Great work Niranjan.

Regards,

G.V.Shivakkumar

Like 0 | Share

Adarsha Ak
March 13, 2018 at 6:08 am
Thanks for making us to understand in simple way.

Thanks,

AK

Like 0 | Share

Angelo Flores
March 21, 2018 at 6:39 am

Great. Thanks.

Like 0 | Share

Marky ACS
April 2, 2018 at 6:09 pm

Hi Niranjan Nagle

Good day

Do you have also an article that explain how does SAP populate IDOCS?

Regards,

Mark.

Like 0 | Share

Raghava S
April 6, 2018 at 6:06 pm

Hi Niranjan,

Well documented...! You simply rocked it.

BR
Raghava

Like 0 | Share

Former Member
April 13, 2018 at 7:08 am

Very helpful documentation. Thank you for sharing this with us.

Best Regards,

Carsten

Like 0 | Share

Nripacharya Chowdhury
August 28, 2018 at 7:25 am

Very helpful document.

Like 0 | Share

Samy G
October 26, 2018 at 6:42 am

Hi Niranjan...very informative docs..keep rocking

Like 0 | Share

Felipe Ricardo Guerra Soto


December 3, 2018 at 8:21 pm

Hi Niranjan Nagle, thank you so much for this great document with very useful information.

Like 0 | Share
Jeff Sirkis
January 16, 2019 at 7:47 pm

I have been reading everything I can find regarding IDoc and EDI and this is the best post I have found.
Thank you for sharing!

Like 0 | Share

Santosh Mathew
July 25, 2019 at 3:29 pm

Awesome Blog. Had I read this blog before I could have got through my interview :). Great work and
very useful for functional guys like me. This is more than basic information and everything at one place.
Great!!

Like 1 | Share

Rahul Ramesh
September 5, 2019 at 4:23 am

Extremely helpful read!

Thanks for sharing.

Like 0 | Share

Vijay Sonavane
October 31, 2019 at 6:16 am

Thanks for sharing.

Very much informative doc.

Like 0 | Share

Deepesh Kumar
November 3, 2019 at 4:45 pm

Very Helpful
Like 0 | Share

Linh Huynh
March 15, 2020 at 6:23 am

Thanks so much for your post.

It is very useful information for me.

Like 0 | Share

Sijin Chandran
April 3, 2020 at 8:25 am

This document is GOLD especially for IDOC beginners like me. It really helped me in getting a clear picture
of IDOCs. This should be a one stop document which everyone should refer before getting into IDOCs.

And not only for Functional even for Technical(am a Technical resource) as well this document is very
helpful.

Thanks,

Sijin

Like 0 | Share

Roddi Gee
May 7, 2020 at 7:35 pm

Thanks for your post. Well written and extremely useful and helpful!

Like 0 | Share

Sreemohan Sivadasan
May 7, 2020 at 10:15 pm
Excellent document and contains very useful information.

Like 0 | Share

NARAYANAPPA KURABA
May 11, 2020 at 11:08 am

Thank you for in detailed explanation on IDOCs. Very informative.

Like 0 | Share

Nitish Chawla
May 26, 2020 at 5:33 am

Even after 8 years of publishing... document is still relevant and informative

a big thanks !!!

Like 0 | Share

Jorge Velásquez
June 24, 2020 at 2:13 pm

Hi.

How do you send Product Category to CPI --> C4C

Regards.

Like 0 | Share

Naga Koteswara Rao Panchumarthi


August 13, 2020 at 4:52 am

Good one...
Like 0 | Share

Sai Kumar Mada


August 16, 2020 at 5:59 am

Hats up and big thank you.

Like 0 | Share

JAGANNATHAN SRINIVASAN
October 27, 2020 at 10:15 am

Thanks a lot for a wonderful effort. Even though as a Functional Consultant I can wash off my hand to the
technical consultant stating failure of idoc, after going through I can provide more inputs to the technical
guy based on your document for quickly resolving the issue of why idocs failed. Great effort

Like 0 | Share

Rajya Lakshmi Chithaluri


November 12, 2020 at 12:51 pm

Nice document (Y)

Like 0 | Share

Navya Sree
November 16, 2020 at 7:07 am

Very Informative and Thanks for the explanation.

Like 0 | Share
Babu Abraham
February 20, 2021 Gidla
at 4:47 pm

Thanks a ton. Really very helpful and you did a real help here.

Like 0 | Share

Bob marray
March 27, 2021 at 4:23 pm

Very helpful documentation. Thank you for sharing this with us.

Like 0 | Share

Halil Erdur
July 13, 2021 at 12:20 pm

very informative article, thank you very much, we look forward to the next :)

Like 0 | Share

Tiarnan Mc Gabhann
January 5, 2022 at 5:46 pm

Really really useful post. Thank you very much.

Like 0 | Share

Yuxi Liang
January 16, 2022 at 10:02 am

useful

Like 0 | Share
Veena Valsan
February 4, 2022 at 3:24 am

Excellent writing . Found it very useful..! Thank you!

Like 0 | Share

bolin zhang
February 23, 2022 at 4:01 am

Very Helpful!

Thank you!

Like 0 | Share

Previous 6 of 6 Next

Find us on

Privacy Terms of Use

Legal Disclosure Copyright

Trademark Cookie Preferences

Newsletter Support

You might also like