SAP Business Processes

The business process shown above depicts an SAP cycle that involves ALE model to exchange business
data like
Purchase Order / Order - Message Type ORDERS
Order Confirmation

- Message Type ORDRSP

Order change

- Message type ORDCHG

IDOC Intermediate Document:

IDOC acts as a standard SAP interface to exchange business data through ALE. From an SAP
system, an IDOC can be sent to and received from

An SAP R/3 system

An SAP R/2 system

An EDI subsystem

Any third-party application software

IDOC is an Intermediate document that holds application data. (SD,MM,FI,etc..)

A container used to exchange data

It is independent of the complex SAP structure to store data.

It serves as the vehicle for data transfer.

IDOC Type defines the structure and format in which the data is exchanged.
It is similar to a structure in SAP

IDOC data is an instance of IDOC Type

Segments IDOC data is arranged in Rows, The rows make up segments of an IDOC. Each
segment consists of fields/segments. Fields can contain data.

Message type is a name given, that tells us what type of business data is being exchanged.

E.g.: MATMAS (material master data) , DESADV (delivery Data)

Message type is always linked to an IDOC type .

Where the IDOC Type represents the data format. While the message tells us the purpose of data
being sent

Ex: In an organization. Employee details are needed for different purposes.

Like Payroll as well as Security department may need different details about the same
employee. A standard format for employee details is created (IDOC type :EMPINFO01).
Different messages , 1 for payroll (EMPSAL) and 1 for security (EMPSEC) so that same
employee details can be sent for different purposes.

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.

IDOC DIRECTION
In SAP Outbox direction is represent by 1 i.e. outbox and Inbox direction is represented by 2.

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.

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 Type & Segments
An IDOC Type defines the syntax(arrangement) of the data permitted segments and their
arrangements mandatory/optional segments.

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.

IDOC Components:Control Record:- is updated in EDIDC table

IDOC# (**IDOC # the unique identifier for each IDOC)
Sending business system
Receiving business system
IDOC type and logical message
Creation date and time.

Data Record:- is updated in EDID4 table

IDOC#(**IDOC # the unique identifier for each IDOC)
Sequence/Hierarchy
Segment-Format definition for
header data
item data
Status Record:- is updated in EDIDS table
IDOC#.(**IDOC # the unique identifier for each IDOC)
Status information like
success/failure.
Data Records constitute of segments with a sequential segment number, a segment type description and
field containing the actual data of the segment (to a max of 1000 bytes)

ALE:-

Application link enabling is SAPs terminology, used to integrate business processes between R/3
Systems and non-R/3 systems.

ALE is the technology used to transfer business data between different systems using IDOCs /
BAPIs.

*IDOC is the container for the business data and ALE is the technology which builds the road for
data transfer.

For example to send Employee Data to Payroll department from HO, HO will populate Employee
detail into the EMPINFO01 format(IDOC). ALE settings will determine who is the receiver, how
to connect to the receiver and transmits the data.

SAP Business units (Sales Unit & production Unit) can use ALE for internal data exchange.
ALE is SAP Technology to send and receive business data in SAP Systems.
Container for the data is IDOC.

Advantages of ALE:

ALE business process is used for following distribution of tasks:

1. Synchronizing customizing data between systems.
2. Master data distribution
3. R/2 Connection
4. External system connection

ALE Model is independent of the participating application systems.

Technology supports guaranteed delivery.

Ensures backward compatibility of messages exchanged between systems.

E.g. Version Compatibility.

Reduced Processing Cycle time

Reduced Paperwork

Reduced Cost

Standard means of communication

Basic components Involved in ALE Model Setup:

The below are the basic configuration steps involved in exchanging the business data between
two systems in distribution service layer.

Logical Systems
( TCode SALE ) - Logical System is a name given to uniquely
identify, the systems involved in data exchange. Logical Systems (LS) represent R/3 or
external systems in the SAP R/3 environment for the distribution of data. A client of an

SAP instance is represented by a logical system in the ALE context. This logical system
will act as sender or receiver of IDOCs.
Partner Type - Partner type are used to classify the business system.
Ex: Logical System (LS) for other SAP clients,

Customer (KU), Vendor (LI) etc..

R/3 Clients involved in data exchange

RFC Connections

Distribution Model ( TCode BD64 ):- Distribution Model A model that describes the
ALE message flow between logical systems. Applications and the ALE distribution
service layer use the model to determine receivers and to control the data distribution.
The relationships between logical systems, message types, BAPIs and filters are defined
in the distribution model.

( TCode SALE ):( TCode SM59 )

Sender Logical System EC1CLNT800, Receiver Logical System SALES, Message Type
CREMAS, No filter conditions defined.

IDOC + Message Type

( TCode WE82 )

Partner Type / Partner Profiles

( TCode WE20 )

Ports ( TCode WE21 ):- Ports are a logical representation of the communication
channels in SAP. R/3 defines four types of ports viz. tRFC (transactional Remote
Function Calls), File, R/2, and Internet. tRFC ports once created are assigned to RFC
destination. ALE can use all port types to distribute IDOCs.

Process Code:

Process Codes are used to identify the function module or API (Application Programming
Interface) to be invoked for subsequent processing (Outbound or Inbound) of the business
application.

Outbound process code - Outbound process code under Message Control, generated the IDOC in
the IDOC Interface. The process code determines the relevant function module. (TCode WE41)

Inbound process Code - names the function module or workflow which reads the IDOC data and
transfers the data to the application document. (TCode WE42)

Outbound process codes are stored in table TEDE1, while inbound process codes are stored in
TEDE2.

Services Involved in Decentralized Data Exchange:

Applications services: This layer provides ALE with an interface (for instance: IDOCs/BAPI) to
facilitate data exchange to or from external R/3 systems.
Ex: A program that collects Master / Transactional data to send to its partner system.

Distribution services: This service is the core in ALE model. Distribution model is used to
identify the receivers (partners) to which the data is to be exchanged. It acts as a sandwich layer
between application and communication layer.

* The onus of filtering and converting messages exchanged between SAP and non-SAP systems
is on the distribution layer of ALE.

Communications services: ALE supports synchronous as well asynchronous communication.

Asynchronous messaging is used for transmitting or receiving application data through IDOCs.

The communication layer performs a remote function call using the port definition and
RFC destination specified by the customer model.

EDI:

When communicating with Business Partners (customers/suppliers on non-SAP platforms) SAP

business units can exchange data through EDI using IDOCs.

Business data

Head Quarters
Suppliers

e
sin
Bu

ta
da
ss

Business data
Business data

Customer

Business data

Sales Office

Production

Typical EDI Scenario:What does EDI mean ?

EDI (Electronic Data Interchange) means exchange of business documents among companies using
electronic communication systems.
Trading partners - The parties who exchange EDI transmissions.

EDI (Electronic Data Interchange)

IDOC

EDI Subsystem

File
(Vendor
Format)

Translate IDOC to EDI Standard. Translated EDI standard to vendor format

EDI (Electronic Data Interchange):

EDI is a standard format for exchanging business data between any 2 systems on different
networks .

Any two systems that use different data formats , and need to communicate with each other can
use EDI.
In case of EDI , EDI being a standard format .Any data format can be converted to universal EDI

format.

In case of SAP , IDOCs from SAP can be converted to EDI format. This is useful and is widely
used for communication with customers and vendors (non-SAP ) who do not understand IDOC
format .

EDI subsystem is needed for communication between 2 systems. This translates the data into
standard EDI format that is understood by receiver / sender system.

EDI uses either ANSI X12 or EDIFACT as standard formats in the data exchange.

In SAP communicating partners are not defined as logical systems for EDI. They have partner
types like KU-Customer, LI-Vendor etc...which uses a file port.

To use EDI -IDOC (intermediate document) a standard data structure is generated by an

application program / transaction in SAP system, it uses file port (to hold application data in file
format) as a technical channel for communication and sends the data to EDI (Electronic Data
Interchange) subsystem.

EDI subsystem:- A system that converts the SAP standard IDoc into an EDI standard such as EDIFACT or
ANSI X12, and vice versa.

IDOC Processing:

The IDOC Interface supports three types of data flow with the external system.

Outbound processing - IDOCs are transferred to a receiving system from the SAP
System.

Inbound processing - IDOCs are transferred to the SAP System from a sender system.

Status processing - The follow-on system confirms the processing status of outbound
IDOCs to the SAP System.

Outbound Processing

Inbound Processing

Outbound Process Flow:

Each layer in ALE model has its own functionality starting from application layer -> distribution
layer -> communication layer in processing outbound IDOCs when message types are used to
transfer data asynchronously.

Application Layer - An application FM creates a master IDOC in outbound processing. This layer
fills the data record of IDOC.

ALE service Layer The Master-IDOC will travel through ALE layer for Receiver Determination
Data Selection, Segment Filtering, Data Conversion, Version Control and dispatch control. This
layer fills the control record of the IDOC and generates a communication IDOC.

Communication Layer - The formatted IDOC is passed to the communication layer from where it
is sent to the system (server) that was called via a tRFC (for SAP systems) or file interfaces (for
example, EDI).

IDOC - Control Record:- The format of the control record is similar for all IDOC types.

IDOC Status Records:- The status record shows the information regarding the processed stages
and processing stages of the IDOC. It attains appropriate statuses during its journey from one
system to another and it has identical format for each IDOC type.

Distribution service layer and Communication service layer add these statuses on the status
record, describing various phases of processing.

Outbound ALE Process:

Prerequisites for outbound interface:

Distribution model (BD64)

Only for ALE

Between sending and receiving LS

Trigger

Message Control & Process code

Extraction program / Change Pointers

Application

Port (WE21)

RFC port for ALE

File port for EDI

Others

Partner Profile Outbound:

Partner Profile - Defines the partner type with whom you communicate asynchronously via
IDOCs. This has to be maintained in the partner profiles configuration TCode WE20.

To configure the partner profiles

Master data must be available in the system for partners.

A port is created to assign in the outbound partner profiles. This port must be configured
already.

Inbound processing:

List of process are carried on inbound IDOCs in the ALE layer.

Inbound Process uses:

Segment filtering, Field conversion, Transfer control, Serialization

IDOC Structure, Service Programs, Partner Profile (derives from control record), Posting
Programs, Configuration Tables

Process Flow

Function Module, Workflow (used mainly in EDI).

Inbound Process Flow:Each layer in ALE model has its own functionality starting from application layer -> distribution layer
-> communication layer in processing inbound IDOCs to post the application data.
Communication Layer This layer receives the communication IDOC structure from the remote system
to post the application data.
ALE service Layer This layer can perform Segment Filtering, Field Conversion, Serialization and
Transfer Control on the communication IDOC structure.
Application Layer The posting program or process code calls the FM to finally post the document to the
database.

Partner Profile Inbound:The below screen shot depicts the message type, inbound process code and posting function module for
vendor master data.

Scenario: Message flow in Manufacturing Industry

The diagram depicts the business process flow between a customer and a vendor in common manufacturing
industries.
To automate the process in exchanging the business data between these partners we can configure the ALE model
with standard messages defined by SAP as shown like
Ex: QUOTES Quotation, ORDERS Purchase Order, ORDRSP Order Confirmation.

Scenario: Message flow in Automotive Industry:-

The diagram depicts the business process flow between a manufacturer and a supplier in an automotive industry.
To automate the process in exchanging the business data between the manufacturer and supplier standard
message type provided by SAP can be used in message exchange such as:
Ex: DELINS Delivery / JIT schedule, DELORD Delivery request, ORDRSP Order Confirmation.

Scenario: Message flow in Retail & Consumer Products.

The diagram depicts the business process flow between a Retailer and a consumer in a Retail Industry.
To automate the process in exchanging the business data between the manufacturer and distribution center
standard messages types provided by SAP can be used in message exchange such as:
Ex: PRICAT Price List / Catalogue, PROACT Stock & Sales Data, ORDRSP Order Confirmation

Jargons used in ALE Model:

SALE

Logical Systems

Clients (Appln.Systems) involved in data exchange ( TCode SALE)

RFC Connections

( TCode SM59)

Distribution Model

( TCode BD64)

Message Type

Partners & Partner Profiles

Ports

IDOC Type

( TCode SALE)

(TCode WE81)
(TCode WE20)
(TCode WE21)
(TCode WE30)

IDOC Segment

Messages / Message Type

(TCode WE81)

IDOC + Message Type

(TCode WE82)

IDOC Monitoring

(TCode WE02)

ALE Monitoring

(TCode BD87)

(TCode WE30)

Demo Scenario:Demo showing distribution of master data.

E.g. Synchronization of master data like customer / vendor / material between 2 SAP systems.
Configuration Steps:
1. Creation of logical systems
2. Assign client to logical systems
3. Creating RFC destinations
4. Creating Distribution model & distributing the view.
5. Generating partner profiles.
6. Check partner profiles & ports generated.
7. Trigger master data and check the status of IDOC in sender and receiver systems.

BAPI:Think of the pre-ERP universe as a series of small lakes, some connected, some not. Each lake (company) is filled
with data. Occasionally, boats venture from the shore to the middle of the lake for some data. Occasionally, one of
these
boats
transfers
data
from
one
lake
to
another.
With the advent of ERP, a canal systemSAP R/3is installed. A vast network of bidirectional waterways takes the
place of the lakes. Small, powerful ships and barges populate these waterways, keeping data in constant motion.
For the SAP consultant, IDocs are the barges. And Business Application Programming InterfacesBAPIsare the
small, powerful ships that keep these barges of data moving.
BAPI is Business Application Programming Interface and has the role as communication platform for developing
applications, e.g. booking material documents from flat files, see more in trx BAPI.
BAPI - Business Application - commonly a function module that is normally RFC enabled as well and acts as a
method of a business object. For example, Sales Order as the business object with a method of create - the BAPI is
BAPI_SALESORDER_CREATEFROMDAT2.
BAPI/RFC Interface
A remote function call is a call to a function module running in a system different from the caller's.

The remote function can also be called from within the same system (as a remote call), but usually caller and callee
will be in different systems.
In the SAP System, the ability to call remote functions is provided by the Remote Function Call interface system
(RFC). RFC allows for remote calls between two SAP Systems (R/3 or R/2), or between an SAP System and a nonSAP System.
RFC consists of the following interfaces:A calling interface for ABAP programs
Any ABAP program can call a remote function using the CALL FUNCTION...DESTINATION statement. The
DESTINATION parameter tells the SAP System that the called function runs in a system other than the caller's.
RFC communication with the remote system happens as part of the CALL FUNCTION statement.
RFC functions running in an SAP System must be actual function modules, and must be registered in the SAP System
as "remote".
When both caller and called program are ABAP programs, the RFC interface provides both partners to the
communication. The caller may be any ABAP program, while the called program must be a function module
registered as remote.
Calling interfaces for non-SAP programs
When either the caller or the called partner is a non-ABAP program, it must be programmed to play the other partner
in an RFC communication.
To help implement RFC partner programs in non-SAP Systems, SAP providesExternal Interfaces
RFC-based and GUI-based interfaces can be used by external programs to call function modules in SAP R/2 or R/3
systems and execute them in these systems.
Vice versa, ABAP programs in R/2 or R/3 can use the functions provided by external programs via these interfaces.
M<reward if useful>
BAPI interface technology forms the basis for the following developments:

Connecting:

New R/3 components, for example, Advanced Planner and Optimizer (APO) and Business
Information Warehouse (BW).

Non-SAP software

Legacy systems

Isolating components within the R/3 System in the context of Business Framework

Distributed R/3 scenarios with asynchronous connections using Application Link Enabling (ALE)

Connecting R/3 Systems to the Internet using Internet Application Components (IACs)

PC programs as frontends to the R/3 System, for example, Visual Basic (Microsoft) or Visual Age
for Java (IBM).

Workflow applications that extend beyond system boundaries

Customers' and partners' own developments.

The interface concept of the classic R/3 is based on two different strategies: Remote Function Calls (RFC) and data
exchange through IDoc message documents. RFC makes direct and synchronous calls of a program in the remote
system. If the caller is an external program it will call an RFC-enabled function in R/3 and if the calling program is
the R/3 system it will call an RFC-function in another R/3-system or it will call a non-R/3 program through a
gateway-proxy (usually rfcexec.exe). BAPIs are a subset of the RFC-enabled function modules, especially designed
as Application Programming Interface (API) to the SAP business object, or in other words: are function modules
officially released by SAP to be called from external programs.

IDocs are text encoded documents with a rigid structure that are used to exchange data between R/3 and a foreign
system. Instead of calling a program in the destination system directly, the data is first packed into an IDoc and then
sent to the receiving system, where it is analyzed and properly processed. Therefore an IDoc data exchange is always
an asynchronous process. The significant difference between simple RFC-calls and IDoc data exchange is the fact,
that every action performed on IDocs are protocolled by R/3 and IDocs can be reprocessed if an error occurred in one
of the message steps.

While IDocs have to be understood as a data exchange protocol, EDI and ALE are typical use cases for IDocs. R/3
uses IDocs for both EDI and ALE to deliver data to the receiving system. ALE is basically the scheduling mechanism
that defines when and between which partners and what kind of data will be exchanged on a regular or event triggered
basis. Such a set-up is called an ALE-scenario.

The philosophical difference between EDI and ALE can be pinned as follows: If we send data to an external partner,
we generally speak of EDI, while ALE is a mechanism to reliable replicate data between trusting systems to store a
redundant copy of the IDoc data. The difference is made clear, when we think of a purchase order that is sent as an
IDoc. If we send the purchase order to a supplier then the supplier will store the purchase order as a sales order.
However, if we send the purchase order via ALE to another R/3 system, then the receiving system will store the
purchase order also as a purchase order.

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 sent as 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:

TESTING AND EDITING IDOCS

If an IDoc contains error in the data then such IDocs can be edited using TCode WE02 or WE05. When an IDoc is
edited the original IDoc information(backup) is saved in a New IDoc under status 70 (for inbound) / 33 (for
outbound). These IDoc stays in the system for reference only and cannot be processed. The status of the edited IDoc
becomes 69 (inbound) and 32 (outbound). These IDocs can then be processed using BD87 transaction or batch jobs.

Debugging of IDocs can be done using by copying the IDocs using TCode WE19. WE19 is a test tool for Idocs
processing. WE19 copies the existing idoc and creates a new IDoc which can then be modified as per testing needs.
The newly generated IDoc can also be processed using BD87.

CONVERTING IDOC STATUS

Report RC1_IDOC_SET_STATUS can be used to change the status of IDoc. Status changes are generally needed to
move an IDoc to status 68 no further processing

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.