You are on page 1of 191

%&6$3,'RF,QWHUIDFH 7HFKQRORJ\

%&
6$3,'RF
,QWHUIDFH
7HFKQRORJ\
 SAP AG 1999
 SAP AG

n Release: 4.6B
n January 2000
n Mat. No.: 5003 4022
&RS\ULJKW

&RS\ULJKW6$3$*$OOULJKWVUHVHUYHG
1HLWKHUWKLVWUDLQLQJPDQXDOQRUDQ\SDUWWKHUHRIPD\
EHFRSLHGRUUHSURGXFHGLQDQ\IRUPRUE\DQ\PHDQV
RUWUDQVODWHGLQWRDQRWKHUODQJXDJHZLWKRXWWKHSULRU
FRQVHQWRI6$3$*7KHLQIRUPDWLRQFRQWDLQHGLQWKLV
GRFXPHQWLVVXEMHFWWRFKDQJHDQGVXSSOHPHQWZLWKRXWSULRU
QRWLFH

$OOULJKWVUHVHUYHG

 SAP AG 1999

7UDGHPDUNV
n Microsoft ®, Windows ®, NT ®, PowerPoint ®, WinWord ®, Excel ®, Project ®, SQL-Server ®,
Multimedia Viewer ®, Video for Windows ®, Internet Explorer ®, NetShow ®, and HTML Help ® are
registered trademarks of Microsoft Corporation.
n Lotus ScreenCam ® is a registered trademark of Lotus Development Corporation.
n Vivo ® and VivoActive ® are registered trademarks of RealNetworks, Inc.
n ARIS Toolset ® is a registered Trademark of IDS Prof. Scheer GmbH, Saarbrücken
n Adobe ® and Acrobat ® are registered trademarks of Adobe Systems Inc.
n TouchSend Index ® is a registered trademark of TouchSend Corporation.
n Visio ® is a registered trademark of Visio Corporation.
n IBM ®, OS/2 ®, DB2/6000 ® and AIX ® are a registered trademark of IBM Corporation.
n Indeo ® is a registered trademark of Intel Corporation.
n Netscape Navigator ®, and Netscape Communicator ® are registered trademarks of Netscape
Communications, Inc.
n OSF/Motif ® is a registered trademark of Open Software Foundation.
n ORACLE ® is a registered trademark of ORACLE Corporation, California, USA.
n INFORMIX ®-OnLine for SAP is a registered trademark of Informix Software Incorporated.
n UNIX ® and X/Open ® are registered trademarks of SCO Santa Cruz Operation.
n ADABAS ® is a registered trademark of Software AG
n The following are trademarks or registered trademarks of SAP AG; ABAP/4, InterSAP, RIVA, R/2, R/3,
R/3 Retail, SAP (Word), SAPaccess, SAPfile, SAPfind, SAPmail, SAPoffice, SAPscript, SAPtime,
SAPtronic, SAP-EDI, SAP EarlyWatch, SAP ArchiveLink, SAP Business Workflow, and ALE/WEB.
The SAP logo and all other SAP products, services, logos, or brand names included herein are also
trademarks or registered trademarks of SAP AG.
n Other products, services, logos, or brand names included herein are trademarks or registered trademarks
of their respective owners.
%XVLQHVV,QWHJUDWLRQ7HFKQRORJLHV,,

/HYHO /HYHO


3 days
Application Link
Enabling (ALE)
Technology
 4

2 days 1 day ,-"./'0'!1!')&!


SAP IDoc Interface SAP IDoc Interface -
Technology Development
  

3 days 4 days

Business Integration EDI Interface


Technology



2 days  
Building Enterprise 5 days
Solutions with SAP Data Transfer 2 3
'
Components 2 days
  Communication
 !"
5 days Interfaces in ABAP
Programming with  $$ #$%'&)((+* )&
BAPIs in Visual Basic 5 days
  Programming with
BAPIs in JAVA
5 days
R/3 Interface and BAPI
Programming in C++
 SAP AG 1999
&RXUVH3UHUHTXLVLWHV

l 5HFRPPHQGHG
%DVLFNQRZOHGJHRIWKH56\VWHPDVJDLQHGIURP
FRXUVHV6$3DQG6$3IRUH[DPSOH

 SAP AG 1999
7DUJHW*URXS

l 3DUWLFLSDQWV
5 &RQVXOWDQWV
5 $GPLQLVWUDWRUV
5 3URMHFWWHDP
PHPEHUV
l 'XUDWLRQGD\V

 SAP AG 1999
&RXUVH2YHUYLHZ

&RQWHQWV

l &RXUVH*RDOV
l &RXUVH2EMHFWLYH V
l &RXUVH&RQWHQW
l &RXUVH2YHUYLHZ'LDJUDP
l 0DLQ%XVLQHVV6FHQDULR

 SAP AG 1999

 SAP AG BC620 1-1


&RXUVH*RDOV

7KLVFRXUVHZLOOHQDEOH\RXWR

l 8QGHUVWDQGWKHSRVVLELOLWLHVRIIHUHGE\WKH
,'RF,QWHUIDFHIRUHOHFWURQLFGDWDWUDQVIHU

l 8VHWKH,'RF,QWHUIDFH

 SAP AG 1999

 SAP AG BC620 1-2


&RXUVH2EMHFWLYH V

$WWKHFRQFOXVLRQRIWKLVFRXUVH\RXZLOOEH
DEOHWR
l &RQILJXUHWKH,'RF,QWHUIDFH

l 7UDFHWKHSURFHVVLQJRI,'RFVLQWKH
V\VWHP

l 6HOHFWDQGXVHWKHFRUUHFW,'RFW\SHVIRU
\RXUEXVLQHVVSURFHVVHV

 SAP AG 1999

 SAP AG BC620 1-3


&RXUVH&RQWHQW

3UHIDFHDQG,QWURGXFWLRQ

Unit 1 &RXUVH2YHUYLHZ Unit 9 *HQHUDO6HWWLQJV


Unit 2 %DVLF3ULQFLSOHV Unit 10 )XUWKHU7HVW3URJUDPV
Unit 3 ,'RFVLQ%XVLQHVV3URFHVV Unit 11 $3URFHVV&KDLQ
Unit 4 'RFXPHQWDWLRQ7RROV Unit 12 6WDWLVWLFVDQG0RQLWRULQJ
Unit 5 3RUW'HILQLWLRQ Unit 13 :RUNIORZVDQG,'RFV
Unit 6 3DUWQHU3URILOHV Unit 14 8VLQJDQ(',6XEV\VWHP
Unit 7 7KH7HVW7RRO Unit 15 $UFKLYLQJ
Unit 8 0&DQG,'RFV

([HUFLVHV
6ROXWLRQV
$SSHQGL[

 SAP AG 1999

 SAP AG BC620 1-4


&RXUVH2YHUYLHZ'LDJUDP

R/3 System

,'RFVLQ%XVLQHVV
3URFHVVHV
Archive
Archive IDoc?
IDoc? Partner
Partner Profiles
Profiles
7HVW
PRQLWRULQJ

0HVVDJH
&RQWURO Port
Port Definition
Definition
:RUNIORZ

$3URFHVV&KDLQ

Documentation
Documentation
EDI
EDI Subsystem?
Subsystem? 'DWDIORZ
External System
Tools
Tools

 SAP AG 1999

n The units can be divided as follows:


• Units which describe how to configure the IDoc Interface
• Units which describe the data flow in the R/3 System and between R/3 Systems and external
systems
n The unit "Test" describes an important step in the process of configuring the IDoc Interface. The
emphasis is placed on the implementation of the test programs in the data flow.
n The unit "General Settings" describes Customizing activities which, for example, create templates
for configuring the IDoc Interface. You should therefore consider this chapter to be more advanced
than the other "configuration chapters".

 SAP AG BC620 1-5


0DLQ%XVLQHVV6FHQDULR

6PDUW0DUW
4XLFN'HOLYHU

6$356\VWHP 6$356\VWHP

  

 

(',6XEV\VWHP (',6XEV\VWHP

 SAP AG 1999

n In order to reduce costs, the company SmartMart wishes to send purchase orders to QuickDeliver via
EDI. QuickDeliver wishes to immediately post these purchase orders electronically. Both companies
have R/3 Systems and must configure their IDoc Interface accordingly. The IDocs are to be
translated into another EDI standard form.

 SAP AG BC620 1-6


%DVLF3ULQFLSOHV

&RQWHQWV

l ,'RFFRQFHSWDQGIXQGDPHQWDOWHUPV
l 'DWDIORZDQGSURFHVVIORZVZKHQXVLQJWKH,'RF,QWHUIDFH

 SAP AG 1999

(C) SAP AG BC620 2-1


7RSLF2EMHFWLYHV

$WWKHFRQFOXVLRQRIWKLVXQLW\RXZLOOEHDEOHWR

l ([SODLQWKHWHUPV,'RF(',DQG$/(
l ,GHQWLI\WKHEDVLFVWHSVLQ,'RFSURFHVVLQJ

 SAP AG 1999

(C) SAP AG BC620 2-2


,'RF&RQFHSW

6\VWHP 6\VWHP

'RFXPHQW ,'RF 'RFXPHQW

l 0HVVDJHRULHQWHG
l $V\QFKURQRXV

 SAP AG 1999

n IDoc is an SAP standard format for data transfer between systems. IDoc stands for ,QWHUPHGLDWH
'RFXPHQW It is LQWHUPHGLDWHin two respects:
é 0HVVDJHRULHQWHG - Data is also stored in applications, only in other formats (the application
documents). The IDoc communicates between these application documents, as the language
spoken by both applications. It is not important whether the application is programmed by SAP or
by another third-party system.
é $V\QFKURQRXV - Data can be stored in IDocs before an application document is created. This is
important, for instance, when incorrect data is transferred: In this case, the application document is
only created when the data is corrected.
n The IDoc Interface is available in the R/3 System from Release 2.1A onwards and in the R/2 System
from Release 5.0F.

(C) SAP AG BC620 2-3


,'RF$SSOLFDWLRQV

%XVLQHVV
56\VWHP &RQQHFWRU
,QWHUQHW
,QWUDQHW

$/(

,'RF
(',
6XEV\VWHP
56\VWHP

2WKHU
:RUNIORZ 6\VWHPV
(OHFWURQLF
)RUP

 SAP AG 1999

n Examples of systems or applications which use IDocs:


é ALE: Application Link Enabling
é EDI: Electronic Data Interchange
é Business Connector: Sending business documents using the Internet

(C) SAP AG BC620 2-4


(',DQG$/(

'RFXPHQW

,'RF
6$356\VWHP 6$356\VWHP

,'RF ,'RF

0HVVDJH
(',6XEV\VWHP (',6XEV\VWHP

 SAP AG 1999

n Two special IDoc application areas should be defined:


é EDI: Electronic data interchange between different companies
é ALE: Electronic data interchange between different systems within one company
n Systems can exchange IDocs either directly (for example R/3 with R/3) or have them translated into
other standards (for example UN/EDIFACT or ANSI X.12) by EDI subsystems.
n The application which uses IDocs (for EDI or ALE) must be able to write data to IDocs, or read data
from IDocs, or both.
n The IDoc format is valid as an EDI standard when used for EDI. However, translating IDocs into
other standards has the advantage of allowing communication with more partners.
n Within the R/3 System, only IDoc formats are used. All translations into other EDI Standards are
performed by an EDI subsystem. The advantage is that SAP applications only have to recognize the
IDoc format - not several EDI standards - and are therefore easier to maintain. The disadvantage is
that SAP do not supply an EDI subsystem and customers must purchase such a subsystem when
other EDI standards are to be used.

(C) SAP AG BC620 2-5


3URFHVV)ORZ6HQGLQJ'DWD

R/3 System
3RVWGRFXPHQW

*HQHUDWH,'RF

&KHFNSDUWQHUILQGSRUW

7UDQVIHUGDWD
SURFHVVIXUWKHU

External system

 SAP AG 1999

n In the following examples, data flow is always seen from the point of view of the R/3 System.
Therefore, if data is sent via IDocs from an R/3 System to an external system, the process is called
RXWERXQGSURFHVVLQJor simply outbound.
n Outbound processing includes:
• Posting the application document
• Generating the corresponding outbound IDoc
• Finding the partner and the port
• Transfer of the IDoc to the external System via the port

(C) SAP AG BC620 2-6


,'RF6HWWLQJV6HQGLQJ'DWD

R/3 System
Post document

$UFKLYH,'RF"
$UFKLYH,'RF" Generate IDoc 3DUWQHU3URILOHV
3DUWQHU3URILOHV

Check partner, find port


3RUW'HILQLWLRQ
3RUW'HILQLWLRQ

External System

Transfer data, 'RFXPHQWDWLRQ


'RFXPHQWDWLRQ
(',6XEV\VWHP"
(',6XEV\VWHP" process further 7RROV
7RROV

 SAP AG 1999

ΠSmartMart must configure the IDoc Interface for outbound processing:


• SmartMart defines the system which will receive IDocs and the technical parameters via the
SRUWGHILQLWLRQ.
• SmartMart defines QuickDeliver as a partner for message type ORDERS in the SDUWQHU
SURILOHV and enters the port which has already been defined.
• Outbound IDocs created in the R/3 System should be DUFKLYHGby SmartMart and then deleted.
• The GRFXPHQWDWLRQWRROV inform the (',6XEV\VWHP which IDoc types are to be recognized.

(C) SAP AG BC620 2-7


3URFHVV)ORZ5HFHLYLQJ'DWD

External System

6HQGGDWDWR
56\VWHP
WUDQVIHU

R/3 System

&KHFNSRUW SDUWQHU
*HQHUDWH,'RF

3RVWGRFXPHQW




 (UURUKDQGOLQJ

 SAP AG 1999

n Receiving data from an external system and the subsequent processing in the R/3 System is called
LQERXQG SURFHVVLQJor also LQERXQG
n Inbound processing includes:
• Receiving IDoc data from an external system via an inbound port
• Creating the inbound IDoc
• Finding the correct processing type via the partner profiles
• Creating the application document
n If an error occurs, HUURUKDQGOLQJ (more general: exception handling) is triggered. Exception
handling is a different kind of processing and is not part of inbound processing. There is also
exception handling for outbound processing but it is less important: For outbound processing you
should usually presume that the data being sent is correct.

(C) SAP AG BC620 2-8


,'RF6HWWLQJV5HFHLYLQJ'DWD

External System

Send data to
(',6XEV\VWHP"
(',6XEV\VWHP" R/3 System

'RFXPHQWDWLRQ
'RFXPHQWDWLRQ
7RROV
7RROV

3RUW'HILQLWLRQ
3RUW'HILQLWLRQ
$UFKLYH,'RF"
$UFKLYH,'RF"
Check port & partner,
3DUWQHU3URILOHV
generate IDoc 3DUWQHU3URILOHV

Post document

(UURUKDQGOLQJ

R/3 System

 SAP AG 1999

n QuickDeliver must configure the IDoc Interface for inbound processing:


• The documentation tools inform the EDI Subsystem which IDoc types are to be recognized.
• The port name must be maintained in the SRUWGHILQLWLRQ before IDocs can be accepted by the
R/3 System.
• In the SDUWQHUSURILOHV QuickDeliver enters SmartMart as a partner for inbound processing and
the message type ORDERS. In addition, agents responsible for error processing are entered here,
specifically for partners and messages.
• Like SmartMart, QuickDeliver wishes to DUFKLYHand subsequently delete inbound IDocs which
have been generated.

(C) SAP AG BC620 2-9


%DVLF3ULQFLSOHV6XPPDU\

l ,'RFLVDQ6$3VWDQGDUGIRUGDWDWUDQVIHUEHWZHHQ
V\VWHPV
l .QRZQLPSOHPHQWDWLRQDUHDVIRU,'RFV$/(DQG
(',VFHQDULRV
l 7KH,'RF,QWHUIDFHIDFLOLWDWHVERWK,'RFSURFHVVLQJ
DQGIOH[LEOHHUURUH[FHSWLRQKDQGOLQJ

 SAP AG 1999

(C) SAP AG BC620 2-10


,'RFVLQ%XVLQHVV3URFHVVHV

l ,'RF5HFRUG7\SHV

l ,'RFDQG,'RFW\SH

l ,'RFSURFHVVLQJ,QERXQGDQGRXWERXQG
SURFHVVLQJ

 SAP AG 1999

 SAP AG BC620 3-1


,'RFVLQ%XVLQHVV3URFHVVHV&RXUVH2EMHFWLYHV

$WWKHFRQFOXVLRQRIWKLVXQLW\RXZLOOEHDEOHWR

l ([SODLQWKHGLIIHUHQFHEHWZHHQ,'RFVDQG
,'RFW\SHV
l 'HVFULEHWKHVWUXFWXUHRIDQ,'RF
l 'HWHUPLQHZKHUHLQWKHEXVLQHVVSURFHVVRU
WKHSURFHVVFKDLQWKH,'RFZDVFUHDWHG

 SAP AG 1999

 SAP AG BC620 3-2


%XVLQHVVVFHQDULR

l $VDPHPEHURIWKHLPSOHPHQWDWLRQWHDPIRU
\RXUFRPSDQ\ 6PDUW0DUWRU4XLFN'HOLYHU \RX
DUHUHVSRQVLEOHIRUFRQILJXULQJWKH,'RF
,QWHUIDFH<RXPXVWWKHUHIRUHXQGHUVWDQGWKH
EDVLFSULQFLSOHVEHKLQGWKHLQWHUIDFHWKH,'RF
IRUPDWDQGKRZWRHPEHGWKHLQWHUIDFHLQERWK
RXWERXQGSURFHVVLQJ 6PDUW0DUW DQGLQERXQG
SURFHVVLQJ 4XLFN'HOLYHU 

 SAP AG 1999

 SAP AG BC620 3-3


,'RF5HFRUG7\SHV

&RQWUROUHFRUG

'DWDUHFRUGV

6WDWXVUHFRUGV

 SAP AG 1999

n Each IDoc in the SAP database consists of:


• One control record
• Data records which store the application data in segments and describe the hierarchy of these
segments.
• Status records which determine the defined processing steps for the IDoc. As a result, the
number of status records for an IDoc increases as processing continues.
n An IDoc for transmission to or from an external system, however, only consists of:
• One control record
• The data records
n If the external system is to inform the R/3 System of the progress of the IDocs which were sent, a
VWDWXVFRQILUPDWLRQmessage is sent. The R/3 System then appends the status records which were
received to the corresponding outbound IDoc in the database. The R/3 System can also send status
confirmation messages for IDocs. However, this is only possible via the special IDoc type
SYSTAT01, that is, no control records or data records are sent in this case. The status information is
therefore located in the data records for each IDoc!
n Summary: IDocs which are transmitted between two different systems are always ’smaller’ than the
IDocs in the R/3 System because they do not contain status records.

 SAP AG BC620 3-4


&RQWUROUHFRUG

&RQWUROUHFRUG IDoc ID
Partner
IDoc type and logical message
External structure

 SAP AG 1999

n An important part of the control record is the IDoc ID, a 16-digit number which is assigned
automatically by the system. This number is used as a unique identifier for the IDoc in the R/3
System. Status confirmations also refer to this number.
n The control record also contains the key fields for partner profiles: Partner and logical message (3
fields each), as well as a flag indicating whether it involves a test partner. For inbound IDocs, these
key fields determine the dependent parameters of the inbound partner profile, for example, how
inbound IDocs should be processed in the R/3 System.
n The three key fields for the partner (recipient) are:
• Partner number (internal number from master data in the R/3 System)
• Partner type (customer, vendor or logical system in ALE scenarios)
• Partner function (important in outbound processing using Message Control, otherwise optional)
n The three fields for logical messages are:
• Message type (corresponds to UN/EDIFACT messages if possible)
• Message variant (optional)
• Message function (optional)
n Other fields relate to the control record, for example conversion to another EDI standard via an EDI
subsystem or an external EDI message archive.

 SAP AG BC620 3-5


'DWD5HFRUGVDQG6HJPHQW6WUXFWXUHV

'DWDUHFRUG
Control part, contains Application data
segment names Field 1 Field 2 ...

Segment

 SAP AG 1999

n Segment names are stored in the control part of a data record. This segment is defined as a structure
in the R/3 System.
n As a result of the segment name being stored in the control part, a structure is assigned to the
unstructured section of the application data by applying the "network of application fields". This
always happens when an application reads data from an IDoc or when the application writes data to
an IDoc.
n The data type of the segment fields is FKDUDFWHU.
n If possible, ISO codes are used for coded fields.

 SAP AG BC620 3-6


6WDWXV5HFRUG

6WDWXV5HFRUG IDoc ID
Status information

 SAP AG 1999

n The IDoc number of the IDoc to which the status record refers is an important part of the status
record. This allows the IDoc relevant to a status conformation message to be identified in the system
and the returned status records can therefore be appended.
n The first status information during processing is taken from the status value or status. This is used as
a basis for the exception handling.
n More detailed information can be obtained from three fields which are used to name R/3 messages in
the standard system. If an error occurs during IDoc processing in the R/3 System, a corresponding
error message can be stored in the status record via the status value "incorrect". Example - message
SAPE0133 ("error during RFC with port X"):
• SAP: R/3 message, displayed in a standard window (field STAMQU)
• E0: Message class as defined in table T100 (field STAMID)
• 133: Message number as defined in table T100 (field STAMNO).
If the first three characters refer to an external system, special messages can be displayed for the
system. However, the display must be programmed specifically and a link to the program must be
included to table TEDE3.
n Other fields in the status record include the creation date, creation time and name of the program
which discovered the error during IDoc processing.

 SAP AG BC620 3-7


,'RF5HFRUG7\SHV6XPPDU\

&RQWUROUHFRUG IDoc ID
Partner
IDoc type and logical message
External structure

'DWDUHFRUGV

Control part Application data

6WDWXVUHFRUGV IDoc ID
Status information

 SAP AG 1999

 SAP AG BC620 3-8


,'RF7\SHV

&RQWURO5HFRUG

'DWDUHFRUGVUHSUHVHQWHGDVDVHJPHQWWUHH

(+''2& (7/680
M 1 C 1
(+'$'5 (,7'2&
  
 
C 5 M 1

(,76&+
(,76&+
 
 
C 99 C 5

6WDWXV5HFRUGV

 SAP AG 1999

n Each business process (for example a purchase order) usually corresponds to a certain IDoc type,
which can include the relevant data.
n An IDoc type is defined by the segments, their hierarchy, sequence and frequency of use. This
information is contained in the control part of the data records.
n The segment hierarchy can be represented in tree form as parent and child segments. This allows the
application data to be structured.
n Summary: IDoc types are special data structures for special applications or messages. If such a
structure contains application data, an IDoc is created (the instance of the IDoc type).

 SAP AG BC620 3-9


2XWERXQGDQG,QERXQG3URFHVVLQJ

6$3$SSOLFDWLRQ

,'RF,QWHUIDFH$/(6HUYLFHV

56\VWHP

([WHUQDO6\VWHP

2XWERXQG3URFHVVLQJ ,QERXQG

 SAP AG 1999

n Directions are always defined from R/3. Therefore, in the RXWERXQGdirection, data is sent from the
application to the external system via the IDoc Interface. For the inbound direction, the opposite is
true.
n For inbound processing, the external system must be assigned certain authorizations. Documents
(IDocs and application documents) are to be created in the R/3 System.
n Different options are available for both inbound and outbound processing. These options are
explained in the following slides.

 SAP AG BC620 3-10


2XWERXQG3URFHVVLQJXVLQJ0HVVDJH
&RQWURO

6$3$SSOLFDWLRQ
)!*
+

0HVVDJH&RQWURO 0&
#&
%$
( !('

,'RF,QWHUIDFH$/(6HUYLFHV
" !

([WHUQDO6\VWHP

 SAP AG 1999

n During outbound processing using Message Control, the application sends IDocs to the IDoc
Interface via Message Control. The IDocs can be processed further (for example filtered) by the ALE
services, if required, before being sent to the port.
n The IDoc Interface sends each IDoc to the subsequent system according to the technical port
definition. Examples of various port types:
• External system = R/3 System: usually transactional RFC (standard ALE scenario)
• External system = EDI subsystem: Usually the file interface

 SAP AG BC620 3-11


'LUHFW2XWERXQG3URFHVVLQJXVLQJ$/(

6$3$SSOLFDWLRQ

:;
89 7
5 64
23

,'RF,QWHUIDFH$/(6HUYLFHV
$01
+/
+.)! $0
,+
-+
/. )! $0
-
+/.  !

([WHUQDO6\VWHP

 SAP AG 1999

n During direct outbound processing, the ALE services are always called. These services:
• Filter the IDoc: Data not required for the communication is removed from the IDoc
• Change the (segment) version: if the recipient only recognizes an earlier version of the IDoc
type, the version can be changed here. This means that less data is transported, as later versions
of IDoc types can only contain more data than former versions and never less.
• Determine the IDoc recipient using a maintained distribution model, in case the application itself
did not specify the recipient.
• Duplicate the IDoc, if required, for distribution models.
n The ALE services create one (or more) FRPPXQLFDWLRQ,'RF V from one PDVWHU,'RF (which is
transferred to function module MASTER_IDOC_DISTRIBUTE).Only communication IDocs are
saved in the database.

 SAP AG BC620 3-12


,QERXQG3URFHVVLQJXVLQJ:RUNIORZ

([WHUQDO6\VWHP
"<!

,'RF,QWHUIDFH $/(6HUYLFHV
 !%&=
>  !


6$3%XVLQHVV:RUNIORZ
)<!*
+

6$3$SSOLFDWLRQ

 SAP AG 1999

n The external system sends IDocs to the R/3 System. The R/3 System is addressed via the port name
SAP<SID> for example SAPC11 for an R/3 System called C11.
n If the IDoc Interface recognizes the external system, the inbound IDocs are accepted and checked,
that is, a syntax check is performed and the system checks whether the sender is entered as a partner.
n The IDoc is sent to the application via SAP Business Workflow according to the settings in the
partner profile.
n If required, the IDoc can be processed by the ALE services before being saved in the database as an
inbound IDoc.

 SAP AG BC620 3-13


'LUHFW,QERXQG3URFHVVLQJXVLQJ$/(

([WHUQDO6\VWHP
"<!

,'RF,QWHUIDFH $/(6HUYLFHV

" <!

6$3$SSOLFDWLRQ

 SAP AG 1999

n Until the partner profile settings are read, direct inbound processing works in the same way as
inbound processing via workflow:
n The IDoc is passed directly to the application function module according to the partner profile
settings.
n You can also set the process code (see the Partner Profiles unit) so that the ALE services are always
called during direct inbound processing. As in the case of outbound processing, these services are
responsible for filtering and version changes. However, IDocs cannot be duplicated during inbound
processing.
n When using an ALE service, the “end result” is only ever stored in the database. This is the
DSSOLFDWLRQ,'RF, in contrast to the inbound FRPPXQLFDWLRQ,'RF.

 SAP AG BC620 3-14


,'RFVLQ%XVLQHVV3URFHVVHV6XPPDU\

l (DFK,'RFLQWKH5GDWDEDVHFRQVLVWVRIRQHFRQWURO
UHFRUGDQGVHYHUDOGDWDDQGVWDWXVUHFRUGV2QO\
FRQWUROUHFRUGVDQGGDWDUHFRUGVDUHH[FKDQJHGZLWK
H[WHUQDOV\VWHPV
l 7KHUHDUHYDULRXV,'RFW\SHVZKLFKDUHGLVWLQJXLVKHG
E\WKHLUVHJPHQWVDQGWKHLURUGHU7KLVLQIRUPDWLRQLV
VWRUHGLQWKHFRQWUROSDUWRIWKHGDWDUHFRUGV
l 'LIIHUHQWSURFHVVLQJRSWLRQVDUHDYDLODEOHIRU,'RFVLQ
ERWKLQERXQGDQGRXWERXQGSURFHVVLQJ

 SAP AG 1999

 SAP AG BC620 3-15


([HUFLVH
'DWDIRUH[HUFLVHV
7UDLQLQJV\VWHP:LOOEHDQQRXQFHGE\WKHLQVWUXFWRU IRUH[DPSOH,
&OLHQW
8VHU%&QQ
3DVVZRUG.856
3RUWV68%6<67(0RIW\SH³)LOH´ GHIDXOW

'DWD 'DWDLQWUDLQLQJV\VWHP 'DWDLQ,'(6


&XVWRPHUVLGH
Material SH-100 SH-100
Vendor T-BILQQ 1014
Purchasing organization 1000 1000
Purchasing group 001 001
Plant 1100 1100
9HQGRUVLGH
Material SH-100 SH-100
Sold-to party T-BIKQQ 1110
Order type TA
Sales organization 1020 1020
Distribution channel 22 22
Division 00 00
Delivering plant 1100 1100

QQ is your group number

 SAP AG BC620 3-16


8QLW,'RFVLQ%XVLQHVV3URFHVVHV

Explain terms
Define IDoc structure

1.1 True or false:


1.1.1 IDocs are always used for process chains.
1.1.2 IDocs are intermediate documents: When the application documents have
been created, the IDocs are deleted from the R/3 System.
1.1.3 IDoc types describe how IDocs are structured.
1.1.4 There are basic rules for IDoc structures.
1.1.5 The differences between IDoc types involve more than the segments which
they contain.

1.2 True or false:


1.2.1 In outbound processing, IDocs are always generated by the IDoc Interface
or by the application.
1.2.2 In inbound processing, IDocs are always generated by the IDoc Interface.
1.2.3 Exception handling via workflow is not possible in outbound processing.
1.2.4 An external system has its own formats for IDoc data. There are therefore
no IDocs in the external system.

 SAP AG BC620 3-17


6ROXWLRQV

8QLW,'RFVLQ%XVLQHVV3URFHVVHV

1.1 True or false:


1.1.1 IDocs are always used for process chains.
IDOVH3URFHVVFKDLQVFDQDOVREHXVHGZLWKLQWKH56\VWHP IRUH[DPSOH
ZRUNIORZ DQGFDQWKHUHIRUHEHXVHGZLWKRXW,'RFV
1.12 IDocs are intermediate documents: When the application documents have
been created, the IDocs are deleted from the R/3 System.
IDOVH,'RFVFDQRQO\EHGHOHWHGIURPWKHV\VWHPZKHQWKH\KDYHEHHQ
DUFKLYHG7KHSKUDVH³LQWHUPHGLDWHGRFXPHQW´GRHVQRWUHIHUWRWKHOLIH
H[SHFWDQF\RIDQ,'RF
1.1.3 IDoc types describe how IDocs are structured.
WUXH
1.1.4 There are basic rules for IDoc structures.
WUXH
1.1.5 The differences between IDoc types involve more than the segments which
they contain.
IDOVH,'RFW\SHVDUHRQO\GHILQHGE\WKHLUVHJPHQWV,'RFVKRZHYHUFDQ
EHGLVWLQJXLVKHGE\WKH,'RFW\SHDQGWKHLUFRQWHQWV

1.2 True or false:


1.2.1 In outbound processing, IDocs are always generated by the IDoc Interface
or by the application.
WUXH
1.2.2 In inbound processing, IDocs are always generated by the IDoc Interface.
WUXH
1.2.3 Exception handling via workflow is not possible in outbound processing.
IDOVH([FHSWLRQKDQGOLQJH[LVWVIRUSURFHVVLQJHUURUVRUV\QWD[HUURUV
ZKHQGHDOLQJZLWKERWKLQERXQGDQGRXWERXQGSURFHVVLQJ
1.2.4 An external system has its own formats for IDoc data. There are therefore
no IDocs in the external system.
IDOVH7KH,'RFIRUPDWPXVWDWOHDVWEHUHFRJQL]HGE\WKHH[WHUQDOV\VWHP
,QDGGLWLRQH[WHUQDOV\VWHPVFDQEH56\VWHPVRU56\VWHPVLQ
ZKLFKFDVH,'RFVDUHDOZD\VVWRUHGLQWKHV\VWHP

 SAP AG BC620 3-18


'RFXPHQWDWLRQ7RROV

l 5HFRUGW\SHV,'RFW\SHVVHJPHQWV

l 2XWSXWIRUPDWV

 SAP AG 1999

 SAP AG BC620 4-1


'RFXPHQWDWLRQ7RROV8QLW2EMHFWLYHV

$WWKHFRQFOXVLRQRIWKLVXQLW\RXZLOOEHDEOHWR

l 8VHWKHGRFXPHQWDWLRQWRROV
l 'HFLGHLQZKLFKVLWXDWLRQVWKH\ZRXOGEHXVHIXO

 SAP AG 1999

 SAP AG BC620 4-2


2YHUYLHZ'LDJUDP 6HQGLQJ'DWD

R/3 System
Post document

Archive
Archive IDoc
IDoc ?? Generate IDoc Partner
Partner Profiles
Profiles

Check partner, find port


Port
Port Definition
Definition

([WHUQDO6\VWHP
'RFXPHQWDWLRQ
EDI
Transfer data, 7RROV
EDI Subsystem
Subsystem ?? process further

 SAP AG 1999

n SmartMart must configure the IDoc Interface for outbound processing:


n Using the GRFXPHQWDWLRQWRROV, SmartMart sends information about the structure of IDoc Type
ORDERS01 to the EDI subsystem.

 SAP AG BC620 4-3


%XVLQHVVVFHQDULR

l $VDPHPEHURIWKHLPSOHPHQWDWLRQWHDPIRU\RXU
FRPSDQ\ 6PDUW0DUWRU4XLFN'HOLYHU \RXDUH
UHVSRQVLEOHIRUFRQILJXULQJWKH,'RF,QWHUIDFH
<RXU(',VXEV\VWHPGRHVQRW\HWNQRZWKHVWUXFWXUH
RIWKH,'RFW\SHWREHXVHG7KH,'RF,QWHUIDFHFDQ
H[SRUW,'RFW\SHVWUXFWXUHVLQYDULRXVIRUPDWVXVLQJ
WKHGRFXPHQWDWLRQWRROV<RXPXVWNQRZDERXWWKLV
IXQFWLRQDV\RXFDQVDYH\RXUVHOIDORWRI
SURJUDPPLQJZRUNLQWKH(',VXEV\VWHP

 SAP AG 1999

 SAP AG BC620 4-4


,QWHUQDODQG([WHUQDO6WUXFWXUHV

6HJPHQW

( Field 1 Field 2 Field 3 Field 4

LQWHUQDO

5HOHDVH
H[WHUQDO

( Field 1 Field 2

 SAP AG 1999

n IDoc types are distinguished by their segments, that is the structure or raster laid upon the data part
of the data record. These Segments exist in both internal and external form:
é Internally as a release-independent structure (SAP names begin with E1), containing all the
defined segment fields.
é Externally as a release-dependent structure (SAP names begin with E2), containing only the
segment fields defined for the specified release in the partner profile.
n In addition to the segments, there are also IDoc record types, in both internal (in the R/3 database)
and external (as structures sent to the external system) forms. Both have changed in different R/3
Releases. The documentation tools only export the external structures in this case.
n As a result, when running the documentation tools, you have to enter the following parameters:
é TheYHUVLRQof the external UHFRUGW\SHV(as entered in the port definition)
é TheUHOHDVHof the external segment(as entered in the partner profiles)
n The default values are the current release number and the relevant status record version. If you
change the values, “go back to the past”.

 SAP AG BC620 4-5


2XWSXWLQ9DULRXV)RUPDWV,

" "
" "

 SAP AG 1999

n IDoc types, segments and record types can be displayed in user-friendly formats which can be read
by other systems. The following display options are available:
é R/3 tree display: In the case of general record types, the "tree" has only one level because the
hierarchy only exists for segments and therefore for special IDoc types.
é HTML file In the IDoc administration user parameters you can set whether an external browser is
to be started or whether the SAP internal HTML control should be used.
n The documentation goes beyond the structure: It also relates to the data elements behind the segment
structure fields. The documentation tools can also provide information about using individual IDoc
types.

 SAP AG BC620 4-6


2XWSXWLQ9DULRXV)RUPDWV,,
" "
" "

%HJLQ ;0/ W\SHGHIVWUXFW]LQFRG[


«
«
(QG ]LQFRG[

 SAP AG 1999

n Machine-readable formats are:


é A simple chain of begin..end declarations which can be read by a parser
é C-Header
é Meta-IDoc, type SYRECD01 (IDoc record types) or SYIDOC01 (IDoc types)
é Meta data for IDoc types in XML format
n You start the documentation tools from the initial node of the IDoc Interface from the
'RFXPHQWDWLRQmenu. The parser has its own menu entry, both for record types and IDoc types.

 SAP AG BC620 4-7


'RFXPHQWDWLRQ7RROV6XPPDU\

l 7KHGRFXPHQWDWLRQWRROVGHVFULEHERWKWKH
VWUXFWXUHDQGWKHXVHRIGLIIHUHQW,'RFV
l 7KHVWUXFWXUHLVLQWKHVWUXFWXUHLQIRUPDWLRQ
([WHUQDOVWUXFWXUHVDUHDOZD\VGRFXPHQWHG
VSHFLILFDOO\UHJDUGLQJKRZWKH\DUHH[FKDQJHG
ZLWKH[WHUQDOV\VWHPV
l 7KHRXWSXWIRUPDWVFDQEHUHDGE\H[WHUQDO
V\VWHPVVRWKDWQRQ56\VWHPVFDQTXLFNO\
UHFRJQL]HWKH,'RFVWUXFWXUH

 SAP AG 1999

 SAP AG BC620 4-8


([HUFLVH

8QLW'RFXPHQWDWLRQ7RROV
7RSLF2XWSXWIRUPDWV

At the conclusion of these exercises, you will have:


• Learned about different output formats

As a member of the EDI project team for your company, you require
information on IDoc type ORDERS01 for two reasons:
To prepare for a project discussion about “purchase order/order via EDI”.
To inform your EDI subsystem provider of this data structure.

1-1 Select'RFXPHQWDWLRQ→,'RFW\SHVfrom the initial node of the IDoc interface. As


you wish to use the standard and have not yet extended any IDoc types, enter the IDoc
type25'(56 and then select %DVLFW\SHin the'HYHORSPHQWREMHFWframe
1-2 You wish to receive all the information on the IDoc type. By selecting *RWR→8VHU
VHWWLQJV you can check that all the display attributes are activated. Save your entries
and return to the initial screen.
1-3 When preparing for the discussion, you opt for the output format +70/SDJHdue to
the convenient navigation options. Three files are generated on your PC. If you have
not changed any of the settings, these files are ORDERS01_F.HTM,
ORDERS01_I.HTM and ORDERS01_D.HTM. File ORDERS01_F.HTM can be
opened via Internet Explorer.

 SAP AG BC620 4-9


3RUW'HILQLWLRQ

l 3RUWW\SHVDQGZKHQWKH\DUHXVHG

l 3RUWGHILQLWLRQSDUDPHWHUV

l &RPPXQLFDWLRQZLWK2OGHU5HOHDVHV

 SAP AG 1999

 SAP AG BC620 5-1


3RUW'HILQLWLRQ8QLW2EMHFWLYHV

$WWKHFRQFOXVLRQRIWKLVXQLW\RXZLOOEHDEOHWR

l 'HFLGHZKLFKSRUWW\SHVVKRXOGEHLPSOHPHQWHG
IRUZKLFKH[WHUQDOV\VWHPV
l (QWHUDSRUWGHILQLWLRQLQWKH56\VWHP

l 'HWHUPLQHZKLFKDGGLWLRQDOVWHSVDUHUHTXLUHGIRU
OLQNLQJWRWKHUHOHYDQWH[WHUQDOV\VWHP
l (QWHUVSHFLDOVHWWLQJVZKLFKDUHUHTXLUHGIRU
FRPPXQLFDWLRQZLWKROGHU5UHOHDVHVDQG5
6\VWHPV

 SAP AG 1999

 SAP AG BC620 5-2


2YHUYLHZ'LDJUDP 6HQGLQJ'DWD

R/3 System

3RVWGRFXPHQW

Archive
Archive IDoc
IDoc ?? *HQHUDWH,'RF Partner
Partner Profiles
Profiles

&KHFNSDUWQHUILQGSRUW
3RUW'HILQLWLRQ

([WHUQDO6\VWHP
Documentation
Documentation
7UDQVIHUGDWD Tools
Tools
EDI
EDI Subsystem
Subsystem ?? SURFHVVIXUWKHU

 SAP AG 1999

n The company SmartMart wishes to send purchase orders to QuickDeliver via EDI. QuickDeliver
wishes to immediately post these purchase orders electronically. Both companies have R/3 Systems
and must configure their IDoc Interface accordingly.
SmartMart must configure the IDoc Interface for sending data (outbound processing or simply
RXWERXQG):
n SmartMart defines the system which will receive IDocs and the technical parameters via the SRUW
GHILQLWLRQ.

 SAP AG BC620 5-3


3RUW'HILQLWLRQ%XVLQHVV6FHQDULR

l $VDPHPEHURIWKHLPSOHPHQWDWLRQWHDPIRU
6PDUW0DUW\RXDUHUHVSRQVLEOHIRUFRQILJXULQJ
WKH,'RF,QWHUIDFH
l <RXPXVWGHFLGHZKLFKSRUWW\SHLVVXLWDEOHIRU
WKHV\VWHPRI\RXUSDUWQHUFRPSDQ\
4XLFN'HOLYHU

 SAP AG 1999

 SAP AG BC620 5-4


,'RF,QWHUIDFH3RUW7\SHV

,'RF,QWHUIDFH

       0    


! ! !"#$!


&('*) +-,  . + 0/ . +  %

"
([WHUQDO6\VWHP 56\VWHP

 SAP AG 1999

n Ports are the channels via which the IDocs are exchanged. The IDoc Interface supports six different
transmission methods. These are the port types:
n "File": IDocs are written in files at an operating system level. The receiving system can read the files
here. The receiving system can also be started using the synchronous RFC. Besides IDocs (that is
data and control records), status records can also be exchanged by file.
n "XML": The IDocs are written in XML format in the files. As is the case with the port type "file",
the receiving system is started via RFC, but here status records are only transferred by means of the
IDoc type SYSTAT01.
n "Transactional RFC" IDocs are sent as tables. Typically here, the external system is an R/3 System
(ALE scenarios).
n "CPI-C" IDocs or control records are transferred according to the CPI-C protocol, in the way it is
implemented for the IDoc Interface in the R/2 System. The external system is always an R/2 System.
IDocs are always exchanged by means of the CPI-C protocol in the R/2 IDoc Interface (available
from R/2 Release 5.0F). For further information see the R/2 handbook, p53.2.
n "Internet": The IDocs are written in MIME format to an e-mail attachment.
n "Programming Interface (PI)": IDocs are sent as tables to one of the function modules defined. <RX
WKHUHIRUHGRQRWOHDYHWKH56\VWHPYLDD3,SRUW. Your function module can naturally trigger or
perform an external dispatch.

 SAP AG BC620 5-5


3RUW'HILQLWLRQ3RUW7\SH)LOH

5)&GHVWLQDWLRQ
7&3,3FRQQHFWLRQ 7 15:!5
 ;<   7 3 8 
&RPPDQGILOH
2XWERXQGILOH
21$3 4 5
Inbound file 6 $7 598 7 
Status file

 SAP AG 1999

n Data for technical linking is determined in the port definition for the IDoc Interface. So that a port
can be used, settings outside of the IDoc Interface must be made.
n The port definition for the port type "file" includes
é Name and directory of files. Only the outbound file is important, as the place and name of the file
are determined by the external system during inbound processing of IDocs or a status
confirmation. However, if you do enter a parameter for the inbound IDoc and status file, the test
tool can generate default values. It is important that the port exists every time, even if it is only
used in inbound processing, as the IDoc Interface only accepts ports that it recognizes.
é Instead of the outbound file, you can also store a function module, which dynamically generates
names and thus helps to prevent files from being over-written. You can also use logical file names:
You should also see the F1 Help for the field.
é Name and directory of command file that is to be called from program "rfcexec" and which should
start the external system - this file must be created so that the R/3 System can start the receiving
system automatically (= WULJJHU) as soon as it has generated an IDoc file.
é If you trigger using RFC, you require the RFC destination. This is maintained with the transaction
SM59 (TCP/IP connections). It is a setting outside of the IDoc Interface.

 SAP AG BC620 5-6


3URFHVV)ORZ3RUW7\SH)LOH ZLWK7ULJJHULQJ

,'RF,QWHUIDFH

:ULWH 5)&  
  5HDG 5)&
7 1F#5:5 = >?ABC D E !97 $7 1"
= >@?AB C D E G;H IJHKMLON EQPQ? N H 3R <  7 38 
 F<   7 3 8   !@<   7 3 8 
5HDG &DOO  
  :ULWH &DOO

([WHUQDO6\VWHP

 SAP AG 1999

n IDoc outbound:
In step 1, a new file is generated with the transferred IDocs by the IDoc Interface. In the second step,
the program “rfcexec” (synchronous RFC) with the path to an executable program is called (here:
“out.script”) and also the path to the IDoc file. “out.script” thus contains the path and name of the
file as an input value. In step 3, it therefore calls the external system, which reads the file in step 4.
After successful processing of the IDoc file, the external system must delete the IDoc file. The call
command in “out.script” depends on the external system.
n IDoc inbound:
In step 1, the external system generates an IDoc file. In step 2 it starts the R/3 System in which it
executes the program "startrfc". “startrfc” receives the logon parameter and the names of the function
module to be executed, the port and the path to the IDoc file. The “startrfc”command can be included
in an executable program, here “in.script”. In step 4, the R/3 System started then processes the IDoc
file and deletes it after successful processing. ,WLVLPSRUWDQWWKDWWKHH[WHUQDOV\VWHPORJVRQWR
DQ56\VWHPZLWKDXVHUZKLFKKDVWKHFRUUHVSRQGLQJDXWKRUL]DWLRQIRUFUHDWLQJDSSOLFDWLRQ
GRFXPHQWV
n The status report works in exactly the same way as an inbound IDoc, except that here a status file
instead of an IDoc file is transferred.
n “rfcexec” and “startrfc” are example programs for the use of the RFC library and are supplied with
this.

 SAP AG BC620 5-7


3RUW7\SH;0/)ODW)LOHDQG;0/)LOH

EDI_DC40 004000000000030702346B 3013 ORDERS01


...
E2EDP01005 00400000000003070230000210000000200
E2EDP20 00400000000003070230000220000210323
...
E2EDPT1001 004000000000030702300002600002103BESTD
E2EDPT2001 004000000000030702300002700002604This is

 SAP AG 1999

n The IDoc data is written in a file under the port type "XML", but in XML format. Hence the port
definition and technical structure are almost identical.
n Under port type "file", no structure information at all is written in the file. The individual segments
are put in a row one after another as data records and are separated with FDUULDJHUHWXUQ. Thus you
also speak of a "flat file".
n The fields are identified by means of their position in the individual records. Such a flat file therefore
contains as many blank characters as possible so that the fields are in the right place.

 SAP AG BC620 5-8


3RUW7\SH;0/)ODW)LOHDQG;0/)LOH 

SUT  V T XWY <EDI_DC40 SEGMENT="1"><TABNAM><![CDAT


A[EDI_DC40]]></TABNAM><MANDT>004</MAN
DT><DOCNUM>0000000000307023</DOCNUM>
...
<E1EDP01 SEGMENT="1"><POSEX>00010 </POS
S%Z[S%T OY Z
EX><ACTION>001</ACTION><PSTYP>0</PSTYP
><MENGE>23.000</MENGE>...
...
S%Z[S%T O\[Y <E1EDP20 SEGMENT="1"><WMENG>23.000 </W
MENG><EDATU>19990622</EDATU></E1EDP2>
...
<E1EDPT1 SEGMENT="1"><TDID>BEST</TDID>
S%Z]S^T 
_ Z
<TSSPRAS>D</TSSPRAS>...
...
...
S%Z[S%T `_`\ <E1EDPT2 SEGMENT="1"><TDLINE>This is the
purchase order text.</TDLINE>...
...
</E1EDPT1> </E1EDP01>
 SAP AG 1999

n The segments are also written one after another in the XML file. But they are considerably different
to a flat file:
n Segments are enclosed by start and end tags and therefore do not need to be separated by FDUULDJH
UHWXUQ. As the fields are also enclosed by tags, the segments are only ever as long as the data
contained requires hence there are no "unnecessary" blank characters.
n As the tags can be connected with one another in XML, you can display an XML file as a tree. The
SAP system IDoc structure therefore remains in the file received and can be displayed in any XML-
compatible browser.

 SAP AG BC620 5-9


3RUW'HILQLWLRQ3RUW7\SHW5)&

5)&GHVWLQDWLRQ
5FRQQHFWLRQ

acb
bO  de + f .hg 0/Fi
/`j$fk/
/$ ]d] 0 i` .lmg[n]g + o

3RUWQDPH DVVLJQHGDXWRPDWLFDOO\

 SAP AG 1999

n Only the name of an existing logical RFC destination is entered in the port definition. The system
then generates a name for this port which consists of an "A" and a 9 digit number. The automatic
number assignment requires a number range which is configured in IDoc Interface Customizing.
There you can also set whether the numbers are to be assigned internally or by an external system.
n Alternatively to port definition in the IDoc Interface, you can create tRFC ports from ALE
Customizing.
n The RFC destination itself is maintained with the transaction SM59 as the "R/3 connection".

 SAP AG BC620 5-10


3URFHVV)ORZ3RUW7\SHW5)&

,'RF,QWHUIDFH

,  p. +
/ j e]d

_`0q$ 

,  p. +
/ j e]d

([WHUQDO6\VWHP

 SAP AG 1999

n For tRFC a system calls a function module in a second system. It follows for the IDoc data exchange
that the sending system is always the active system: It calls the function module in the receiving
system and transfers the IDocs as tables. The function modules are therefore inbound function
modules of the respective system.
n Inbound function modules in the IDoc Interface are the function modules
INBOUND_IDOC_ASYNCHRONOUS (new for Release 4.0) and INBOUND_IDOC_PROCESS
(older releases). Therefore if you want to send IDocs from a 4.0 System to an older R/3 release, you
must call INBOUND_IDOC_PROCESS there: This is set via the SRUWYHUVLRQ.
n Non-R/3 Systems require the R/3 RFC library. The external RFC Interface can be generated for the
function module from the development environment (transaction SE37) (menu: 8WLOLWLHV!5)&
,QWHUIDFH!*HQHUDWH). If a non-R/3 System wants to be able to receive IDocs by tRFC, it still needs
a function module that is configured like INBOUND_IDOC_ASYNCHRONOUS or
INBOUND_IDOC_PROCESS.
n All IDocs transferred are saved asynchronously in the database using the single COMMIT WORK
command.
n For further information see the ALE documentation (under 5/LEUDU\!&$%XVLQHVV)UDPHZRUN)

 SAP AG BC620 5-11


3RUW'HILQLWLRQ&3,& 56\VWHP

VLGHLQIRHQWU\

7;&20HQWU\
rUf g + f . , q"\

+RVWGHVWLQDWLRQ

5)&GHVWLQDWLRQ

7HFKQLFDOSDUDPHWHUV
6HQGVWDWXVUHFRUGV"

 SAP AG 1999

n The logical destination and the host destination are determined in the port definition. The RFC
destination is created with the transaction SM59 and contains the logon data (name, password). The
host destination indicates an entry in the R/3 internal table TXCOM.
n The TXCOM entry refers to a gateway. The logical destination is assigned a ORJLFDOXQLWon the R/2
side in a sideinfo-file of this gateway. The ORJLFDOXQLWis part of the network architecture SNA and
identifies computers or also programs to be started.
n Besides the target system, the port definition also contains technical parameters like the buffer size
of the CPI-C data buffer or a flag showing whether the R/2 System should send a confirmation of
receipt.
n Note that for this port type not only the name, but rather also technical parameters are also important
IRULQERXQGSURFHVVLQJ The reason for this is that the R/2 System is always passive, that is, the R/3
System also collects the IDocs from the R/2 System under inbound processing.
n The exact functions and configuration of this port type can be found
é In the R/2 manual S53.2 (IDoc Interface). Unit 8 of the manual describes in detail how the sending
and receiving side of the CPI-C connection in an EDI subsystem are configured
é In the R/3 OSS note 61524 and
é In the R/2 OSS notes 52553 and 57014.

 SAP AG BC620 5-12


3URFHVV)ORZ3RUW7\SH&3,&

5,'RF,QWHUIDFH

_`0q$ 

&RPPXQLFDWLRQ
VWUXFWXUH 5HWULHYHVHQG,'RFVRU
5HWULHYHVHQG,'RFVRU
^ 
UHFHLYHVHQGVWDWXV
UHFRUGV

)`sutv \

5,'RF,QWHUIDFH

 SAP AG 1999

n The R/2 System is always passive, the communication is always started from the R/3 System. The
data bindings supported are:
é R/3 outbound, IDoc from R/3 to the R/2 (R/3 sends IDocs: from R/2 Rel. 5.0F, from R/3 Rel. 3.0)
é R/3 inbound, IDoc from R/2 to R/3 (R/3 receives IDocs: from R/2 Rel. 5.0F, from R/3 Rel. 3.1)
é Status report (R/3 sends exactly one status record per IDoc: from R/2 Rel. 5.0F, from R/3 Rel. 3.1)
é Status report (R/3 receives exactly one status record per IDoc: from R/2 Rel. 5.0H, from R/3 Rel.
3.1)
n The CPI-C protocol commands are used (Common User Programming Interface). The gateway
converts the CPI commands into:
é LU 6.2 protocol commands to the R/2 side (IBM mainframe)
é TCP/IP protocol commands to the R/3 side (client/server systems)
n The IDocs are saved synchronously in the database.

 SAP AG BC620 5-13


3RUW'HILQLWLRQ,QWHUQHW

,QWHUQHWGHVWLQDWLRQ

,QWHUQHWDGGUHVV
)ROGHUQDPHIRURXWERXQG,'RFV
$GGLWLRQDOPDLODWWULEXWHV

 SAP AG 1999

n The most important part of the port definition is the Internet address (IP address). Together with the
IDoc it is transferred via SAPconnect to the Internet gateway (or the Microsoft Exchange server).
n Furthermore, the port definition contains mail attributes:
• an explanatory text which can be read first when receiving a mail as the mail body
• the title of the mail in the mail header
• the name of a folder in which IDocs to be sent can be saved in the original system for control
purposes.
n The general settings (IDoc Administration) contain the name of the folder where mails with the
inbound IDocs are saved. Normal IDoc inbound processing can only be started from this folder.

 SAP AG BC620 5-14


3URFHVV)ORZ3RUW7\SH,QWHUQHW

,'RF,QWHUIDFH

 0

6$3RIILFH6$3FRQQHFW

0,0(HPDLO

([WHUQDO6\VWHP

 SAP AG 1999

n For sending via the Internet, IDocs are converted to another format (SAPoffice name: R3I): a table
with 255 characters. This table is transferred by SAPconnect:
é To the Internet gateway (VHQGPDLOprogram), or
é To the Microsoft Exchange server.
n The gateway (or the Exchange server) converts the IDoc table into MIME format.
n For inbound processing, the procedure is reversed. Internet IDocs are displayed to the relevant users
as mail attachments in SAPoffice.
n To use this port type, the following parameters must be entered:
é A SAPconnect node for address type INT (Internet) must be configured (for forwarding and
managing Internet messages)
é The user must have a SAPoffice address for address type INT to receive IDocs
é The recipient of an Internet IDoc forwards this to the dummy user EDI USER (see the +HOSRQWKH
DSSOLFDWLRQ in the port definition: “ Configure the SAPRIILFH user address for the Internet”

 SAP AG BC620 5-15


3RUW'HILQLWLRQ3,

2ZQ
IXQFWLRQPRGXOH
LQWKH56\VWHP

)XQFWLRQPRGXOH
1DPHDQGGHVFULSWLRQ

 SAP AG 1999

n For a port of type "programming interface", only enter the name of the function module to be called
for outbound processing.
n In this ABAP function module you can program any type of processing. Only the interface is
standard.
n The standard system includes the function module OWN_FUNCTION as an example.

 SAP AG BC620 5-16


3URFHVV)ORZ3RUW7\SH3,

,'RF,QWHUIDFH

 0

2ZQIXQFWLRQPRGXOH

 SAP AG 1999

n Outbound Processing
The IDoc Interface calls the function module and transfers the IDoc control records in table format.
Further processing (reading data, processing data, writing status records) is programmed by the user.
n Inbound Processing
Your function module must call the SAP function module IDOC_INBOUND_ASYNCHRONOUS,
which saves the IDocs in the database and triggers the event. This event asynchronously starts
inbound processing.

 SAP AG BC620 5-17


&RPPXQLFDWLRQZLWK2OGHU5HOHDVHV

'LIIHUHQFHVLQ,'RFUHFRUGW\SHV

;
)LHOG )LHOG )LHOG

)LHOG )LHOG 1HZILHOG 

)LHOG )LHOG


 SAP AG 1999

n The IDoc record types are defined in the dictionary by their structure.
n Structures have changed in different releases, with names becoming longer and new fields being
added.
é Example: For R/3 Release 3.0, the partner function was included in the control record.
n To be able to communicate with earlier releases, the YHUVLRQis specified in the port definition:
é Version 1: Record types are transferred using the Releases 2.X structure
é Version 2: Structure of Release 3.X
é Version 3: Structure of Release 4.X
n For port type "tRFC", a non-R/3 System must also recognize the function module to be called, as
well as the correct record types: INBOUND_IDOC_ASYNCHRONOUS (new in Release 4.0) or
INBOUND_IDOC_PROCESS (older releases).
n As record types in the R/2 System always have the same structure, no version must be maintained for
port type CPI-C. The structure is covered by R/3 Release 3.0/3.1 (version 2).

 SAP AG BC620 5-18


3RUW'HILQLWLRQ6XPPDU\

l ,'RFVRUVWDWXVUHFRUGVDUHDOZD\VH[FKDQJHGZLWKDQ
H[WHUQDOV\VWHPYLDDSRUW
l ,QWKHSRUWGHILQLWLRQIRUWKH,'RF,QWHUIDFHXVHUVGHILQH
WKHWDUJHWV\VWHPDQGWKHWHFKQLFDOFRPPXQLFDWLRQ
SDUDPHWHUV,QDGGLWLRQXVHUVFDQVSHFLI\WKHUHOHDVH
VWDWXVIRUWKHH[WHUQDOV\VWHPYLDWKHYHUVLRQHQWU\
l $GGLWLRQDOWHFKQLFDOVHWWLQJVPXVWDOVREHHQWHUHG DOVR
RXWVLGH5 EHIRUHDSRUWFDQEHXVHG
l 7KHUHDUHVL[EDVLFFRPPXQLFDWLRQWHFKQLTXHVIRUWKH
,'RF,QWHUIDFHUHSUHVHQWHGE\WKHVL[GLIIHUHQWSRUW
W\SHV

 SAP AG 1999

 SAP AG BC620 5-19


([HUFLVH

8QLW3RUW'HILQLWLRQ

At the conclusion of these exercises, you will be able to:


• Create a port

You are a member of the EDI project team. The decision has been made
to connect the EDI subsystem to the R/3 System via the file (port type
"File").

1-1 Create a new port: From the initial node of the IDoc Interface, select ,'RF→ 3RUW
GHILQLWLRQchoose)LOH and select &UHDWH.
You should use the port name PORT-QQ As the first test does not involve triggering,
you only have to maintain the 2XWERXQGILOHtab page. Ensure that the file names can
be generated dynamically. Select the logical directory (',B*/2%$/B3$7+ and a
suitable function module. Leave the 2XWERXQGILOH field empty.
From the 2XWERXQGILOH tab page, check the settings using the corresponding
pushbutton (check icon). Save your entries.

6,'!is the 3-character system ID (for example I40)


QQ is the number of your group (01 to 18)

 SAP AG BC620 5-20


3DUWQHU3URILOHV

l 6WDQGDUGSDUWQHUSURILOHV

l &KHFNLQJ3DUWQHU3URILOHV

l )DVWHQWU\

 SAP AG 1999

 SAP AG BC620 6-1


3DUWQHU3URILOHV8QLW2EMHFWLYHV

$WWKHFRQFOXVLRQRIWKLVXQLW\RXZLOOEHDEOHWR

l ([SODLQWKHSXUSRVHRISDUWQHUSURILOHVDQG
SURFHVVFRGHV
l 0DLQWDLQSDUWQHUSURILOHV

 SAP AG 1999

 SAP AG BC620 6-2


2YHUYLHZ'LDJUDP 6HQGLQJ'DWD

R/3 System
3RVWGRFXPHQW

3DUWQHU3URILOHV
Archive
Archive IDoc
IDoc ?? *HQHUDWH,'RF

&KHFNSDUWQHUILQGSRUW
Port
Port Definition
Definition

Documentation
Documentation
7UDQVIHUGDWD Tools
Tools
EDI
EDI Subsystem?
Subsystem? SURFHVVIXUWKHU

 SAP AG 1999

n The company SmartMart wishes to send purchase orders to QuickDeliver via EDI. QuickDeliver
wishes to immediately post these purchase orders electronically. Both companies have R/3 Systems,
use EDI subsystems and must configure their IDoc Interface accordingly.
n SmartMart must configure the IDoc Interface for sending data (outbound processing or simply
RXWERXQG):
SmartMart defines QuickDeliver as a partner for message type ORDERS in the SDUWQHUSURILOHV and
enters the port which has already been defined.

 SAP AG BC620 6-3


3DUWQHU3URILOHV%XVLQHVV6FHQDULR

l 6PDUW0DUWPXVWGHILQH4XLFN'HOLYHUDVDSDUWQHU
<RXKDYHDOUHDG\FRQILJXUHGDVXLWDEOHSRUWLQWKH
SRUWGHILQLWLRQ
l ,QRXWERXQGSURFHVVLQJ4XLFN'HOLYHULVWKHSDUWQHU
IRUWKHSXUFKDVHRUGHU,QRXWERXQGSURFHVVLQJLW
LVWKHSDUWQHUIRUWKHRUGHUDFNQRZOHGJPHQW

 SAP AG 1999

 SAP AG BC620 6-4


3DUWQHU3URILOHV)LHOGV

Partner
Permitted agents
*HQHUDO Partner
Message
Port
IDoc type
EDI structure
Permitted agents Partner
Application
2XWERXQG3URFHVVLQJ
Process code
Logical message
Partner 0&SDUDPHWHUV
Message
Process code
Permitted agents
,QERXQG3URFHVVLQJ
 SAP AG 1999

The IDoc partner profile is divided into four areas:


General partner profile: Contains partner data from the master data as a key (2 fields: Number and type).
Additional general parameters: For example, "party to be notified" when an error occurs if no special settings
have been entered (in outbound or inbound).
Outbound partner profile (general): 3 keys are used - partner (3 fields: number, type, function), logical message
(3 fields: (type, code, function) and the test flag. The partner refers to the general partner profile. Additional
parameters: For example, the outbound port and IDoc type. This means that the values for partner, message and
test flag define the port and IDoc type in a unique way.
The outbound processing values must DOZD\Vbe maintained, regardless of the type of outbound processing
used (direct or using Message Control).
Additional parameters for outbound processing under Message Control (MC): This type of outbound
processing (applied in MM and SD) uses the MC key (from the condition record): Application key and output
type. The partner key part consists of the partner type and function and is taken from the general partner
profile. You must ensure that you enter the correct partner function, that is, the one the application uses to call
Message Control.
&DXWLRQ The output type has nothing to do with the logical message in the IDoc interface.
Inbound partner profile: The same 7 key fields which are included in the outbound partner profile are used in
this case. The partner refers to the general partner profile. Additional parameters: For example, the process
code which defines the type of inbound processing (business process). Summary: Partner, message and test
flag define the business process in a unique way.

 SAP AG BC620 6-5


&KHFNLQJ3DUWQHU3URILOHV

 SAP AG 1999

n Partner profiles can be checked for consistency. This function is reached via a pushbutton from the
partner profile initial screen.
n You should ensure that both parts of the outbound partner profile are maintained: The "outbound
parameter" (general) part and the "Message Control" part: If the Message Control part is missing, a
warning is always displayed, even if this part is not required because the system cannot recognize
whether or not this part is needed. If you do not require the Message Control part, you should simply
ignore this warning message.

 SAP AG BC620 6-6


3DUWQHU3URILOHV2XWERXQG3URFHVVLQJ,

6$3$SSOLFDWLRQ



 


0&VHWWLQJV
0&VHWWLQJV


 

MC


  

*HQHUDORXWERXQG
,'RF,QWHUIDFH$/(6HUYLFHV
*HQHUDORXWERXQG




5HFHLYLQJ6\VWHP

 SAP AG 1999

n The company SmartMart wishes to send purchase orders from module MM to QuickDeliver. IDoc
outbound processing must therefore be configured. In the MM module, outbound processing always
takes place using Message Control (MC). As a result, SmartMart must maintain the following parts
of the partner profile for QuickDeliver:
n General partner profile: Here, the name QuickDeliver is entered as the SDUWQHUQXPEHUusing the
form in which it appears in the master data. The SDUWQHUW\SHis LI: This identifies QuickDeliver as
a vendor in the R/3 System.
n Outbound processing (general): Partner number and partner type are entered from the general
settings. Additional parameter: 3DUWQHUIXQFWLRQLF (vendor): This function must be entered as it
refers to the corresponding key in the MC record. The PHVVDJHW\SHis ORDERS.
n Additional parameters for outbound processing under MC: The partner function and message type
are entered from the general outbound settings. MC-specific keys are the DSSOLFDWLRQEF
(purchasing) and the RXWSXWW\SHNEW (in contrast to change messages).
n The message type is to be used productively. As a result, the test flag is not set.
n 1RWHOnly the key fields are considered here!

 SAP AG BC620 6-7


3DUWQHU3URILOHV2XWERXQG3URFHVVLQJ,,

Partner: QD ; Appl: EF; OtptType : NEW Object type, 0&UHFRUG


language,...

Partner: QD ; Appl: EF; OtptType : NEW Process code: ME10


0&
Message: ORDERS VHWWLQJV

Partner: QD; Output type: ORDERS


*HQHUDO
2XWERXQG
Port: SUBSYSTEM Permitted agent:
IDoc type: ORDERS01 EDI agent for partner
QuickDeliver (QD) (purchase orders)

 SAP AG 1999

n As always, the key fields determine the contents of the other fields. As a result, when SmartMart
sends an order to QuickDeliver, the partner profiles have the following effect:
n Message Control (MC) creates a data record containing the application EF, output type NEW and the
partner QuickDeliver. In the MC settings for the partner profile, these key fields define the process
code ME10 and the message ORDERS.
n The process code specifies the function module which inserts the order data in the IDoc type. The
message ORDERS and partner QuickDeliver are assigned to the corresponding fields in the general
partner profiles, which are the key fields in this case. They determine that the IDoc type ORDERS01
is to be used (that is, will contain the application data); as well as the outbound port.
n Summary: In conclusion, the MC record determines the IDoc type, port and function module, hence
the entire outbound processing. There are other dependent fields such as "permitted agents" for
notifications.
n The appendix contains a set of common combinations of MC and partner profile fields.

 SAP AG BC620 6-8


3DUWQHU3URILOHV,QERXQG3URFHVVLQJ

Partner: QD; Message: ORDRSP


IDoc type: ,'RF
ORDERS01 &RQWURO5HFRUG

Process code:
Partner: QD; Message: ORDRSP
ORDR;
Permitted agents: EDI ,QE3URFHVVLQJ
agent for partner
QuickDeliver, order
acknowledgments

 SAP AG 1999

n SmartMart wants to be able to receive and process EDI order acknowledgments from QuickDeliver
for their purchase orders. IDoc inbound processing must therefore be configured. As a result,
SmartMart must still maintain the inbound part of the partner profile for QuickDeliver. 3DUWQHU
QXPEHUand SDUWQHUW\SH are entered from the general settings. The PHVVDJHW\SHis ORDRSP
(order confirmation). The message is to be received productively. As a result, the WHVWIODJ is not set.
As well as these NH\ILHOGV the process code ORDR is an important data field.
n If QuickDeliver now sends an order acknowledgment to SmartMart, the partner profiles have the
following effect:
n In the control record, the inbound IDoc contains the partner QuickDeliver and the message
ORDRSP, which are assigned to the corresponding fields in inbound processing. Together with the
test flag (also part of the control record), these key fields uniquely determine the process code.
n The process code specifies the function module which reads the data from the inbound IDoc.
n Summary: The IDoc type determines the inbound processing for the IDoc. There are other dependent
fields such as recipients of notifications.

 SAP AG BC620 6-9


3URFHVV&RGHV,

Partner
Application
Mess.type

Process code

Function module (writes the application


([DPSOH0&SDUDPHWHUVLQSDUWQHUSURILOHV
Process code
data in an outbound IDoc)

 SAP AG 1999

n A process code is only another name for a process carried out by a function module or a workflow.
IDocs are processed in these cases, that is data is written to the IDocs or read from the IDocs.
n The partner profiles only contain the process codes, never the real name of the function module. You
can therefore replace an old process with a new one for all relevant partners in one single step:
Assigning the new process to the existing process code.
n Partner profiles contain process codes for inbound and outbound processing. In addition, process
codes for error handling are configured in the IDoc Interface, which do not save any work in the
above sense. They were introduced for completeness, so that all processes connected to the IDoc
Interface can be processed via a process code.
n Only one process code exists for outbound processing when Message Control (MC) is used (because
the direct way simply sends an IDoc to the IDoc Interface). This process code always identifies a
function module.
n 1RWHProcess codes are client-specific!

 SAP AG BC620 6-10


3URFHVV&RGHV,,

([DPSOH,QERXQG

Partner
Message

Process code

Function module/workflow (reads data from an


Process code
inbound IDoc and processes data further)

 SAP AG 1999

n The inbound partner profiles always contain a process code which specifies either a workflow or a
function module (direct processing).
n There are two types of process codes for error handling:
é System: Error handling for IDoc processing (both inbound and outbound)
é Process code status: Error handling for status confirmation
All process codes are assigned to processes via the &RQWURO menu in the IDoc Interface.
n See the online documentation for more information about process codes.

 SAP AG BC620 6-11


3URFHVV&RGHV,,,

'RFXPHQWDWLRQYLDPHVVDJHV

Message

Process code

 SAP AG 1999

n In order to find the correct process code for your business process, search for it via the "logical"
message (for example ORDERS for a purchase order).
n Then choose 'RFXPHQWDWLRQ→ 3URFHVVFRGH from the initial node of the IDoc Interface.
n There is an n:m relationship between process codes and message types. For new definitions of
business processes or IDoc types you determine new process codes or messages in the assignment
table (see BC621).

 SAP AG BC620 6-12


2XWERXQG0RGHV3RUW7\SH)LOH

3DUWQHU 'HVFULSWLRQ
SURILOH

Transfer single IDoc +


start external system (trigger)

Transfer single IDoc;


no trigger

Transfer multiple IDocs + start


external system (trigger)

Transfer multiple IDocs;


no trigger

 SAP AG 1999

n The transfer time is only defined if the external system is triggered, which helps maintain data
consistency.
n Non-triggered data transfer includes the danger that IDoc or status files may be processed several
times or not processed at all.
n Other port types always include external system triggering (because the IDocs are not saved
temporarily in files but transferred directly). Only outbound modes which include triggering are
displayed here.
n The IDoc Interface programs use sequential numbers for outbound modes: field OUTMOD has
values from 1 to 4 (read from top to bottom in the diagram).

 SAP AG BC620 6-13


3DUWQHU3URILOHV2XWSXW

'LVSOD\

 SAP AG 1999

n Partner profiles can be displayed in the R/3 System (the same initial access as create). A link from
the 8WLOLWLHV menu leads to the tree output which provides a clear means of display, even for several
partners.
n The tree can be printed from the menu 6\VWHP!/LVW. Also check the "application help" in the
transaction.
n Partner profiles can also be sent via the special IDoc type SYPART01. A partner profile for this
IDoc type with the "logical" message SYPART is therefore a prerequisite.

 SAP AG BC620 6-14


3DUWQHU3URILOHV6XPPDU\

l 3DUWQHUSURILOHVVSHFLI\ZKLFKPHVVDJHVDUHVHQWWRZKLFK
XVHUVXVLQJZKLFKPHWKRGDQGKRZWKH\DUHSURFHVVHG
3DUWQHUVPXVWEHHQWHUHGLQWKHSDUWQHUSURILOHEHIRUH,'RFVFDQ
EHVHQWVXFFHVVIXOO\
l 7KHSRUW WKHZD\ LVSDUWRIWKHRXWERXQGSDUWQHUSURILOH
7HFKQLFDOFRPPXQLFDWLRQSDUDPHWHUVDUHHQWHUHGLQWKHSRUW
GHILQLWLRQ,QERXQGSRUWVGRQRWUHTXLUHVXFKSDUDPHWHUVWKHLU
WHFKQLFDOSDUDPHWHUVDUHGHILQHGE\WKHH[WHUQDOVHQGLQJ
V\VWHP
l 3URFHVVFRGHVDUHDOVRSDUWRIWKHSDUWQHUSURILOHV
7KH\DUHXVHGIRUSURFHVVLQJGDWD
l 3URFHVVFRGHVZKLFKDUHGHILQHGRXWVLGHWKHSDUWQHUSURILOHDUH
XVHGLQHUURUKDQGOLQJ

 SAP AG 1999

 SAP AG BC620 6-15


([HUFLVH

8QLW3DUWQHU3URILOHV

As a member of the EDI project team for your company, enter the
company 7%,/QQ as the EDI vendor with whom purchase orders and
order acknowledgments are to be exchanged.

1-1 Maintain the partner profiles for your EDI vendor as follows:
• Purchase orders can be sent to the EDI vendor
• Order acknowledgments from the vendor can be received
The corresponding master data in the MM application has already been created for you.

1-2 From the initial node of the IDoc Interface, choose,'RF→ 3DUWQHU3URILOH. Firstly,
enter the header data for the vendor. Position the mouse on the partner type LI and
choose &UHDWH. There, enter a permitted agent.
1-3 Configure the outbound processing. Choose &UHDWHRXWERXQGSDUDPHWHU. Enter the
vendor (code /)). The message is 25'(56. Firstly, maintain the 2XWERXQGRSWLRQV:
The recipient port has already been maintained as 3257QQ and represents the
connection to the EDI subsystem. In output mode choose 6HQG,'RFLPPHGLDWHO\ and
'RQRWVWDUWVXEV\VWHP. Finally in this view, enter the data structure for the exchange as
an IDoc type. As you are going to use the standard system, select the IDoc type
25'(56.
As outbound processing for confirmations is determined via Message Control, you must
also maintain the 0HVVDJH&RQWURO tab page. The application is linked to Message
Control. In MC, the process is identified by the partner function (code /)) and the
application (application () and message type 1(8). You determine how the document
data is generated as an IDoc via the process code. You should remember that in certain
circumstances, there can be several process codes for one message. Select the most
recent version of confirmation outbound processing via process code 0(.
1-4 Now configure inbound processing for the order acknowledgment in &UHDWHLQERXQG
SDUDPHWHUV. The process depends on the vendor and the message. Using the information
sent to your system by the EDI subsystem in the control record, the correct partner
profile can be determined. You should therefore select the message 25'563 to identify
the process. The actual processing of the IDoc is selected via the process code. Select the
process code 25'5.
1-5 Check the settings you have entered by selecting 3DUWQHU→&KHFN.
QQ is the number of your group (01 to 18).

 SAP AG BC620 6-16


7KH7HVW7RRO

7HVW7RRO2SWLRQV

 SAP AG 1999

 SAP AG BC620 7-1


7HVW7RRO2SWLRQV

 SAP AG 1999

n You DOZD\V create a new test-IDoc with the test tool. However, you can use one of the IDocs
available in the database as a WHPSODWHand HGLWthe copy.
é You can add or delete segments and therefore create your own IDoc type in an ad hoc manner.
é You can change the content of every single segment field
é You can change all the control record fields
n There are other possibilities if you do not want to use an IDoc as the model for editing:
é You can enter data in the empty IDoc type (including the control record)
é You can import an IDoc from a file.
é You can even create an IDoc from nothing by simply adding segments step by step.
n The test tool saves the edited IDoc as a new IDoc in the database before the actual processing test
begins.

 SAP AG BC620 7-2


7HVW7RRO2SWLRQV 

)XQFWLRQ0RGXOH


   







+ &%'%,-#&%'  !"$#&%'%()*



 



 SAP AG 1999

n The following options are available in the test tool for both LQERXQGDQGRXWERXQGSURFHVVLQJ:
é Standard processing: Your test IDoc is sent for normal inbound or outbound processing.
é Mass testing: Several copies of the edited IDoc are sent for processing. If the relevant flag is not
set, only one copy is sent.
n In addition, the following options are available for LQERXQGSURFHVVLQJ:
é Generate file: In the case of a port with type "File", an IDoc file is created during inbound
processing. The test tool takes over the role of the external system. Inbound processing does not
have to be triggered by the generation of the IDoc file, which means that the IDoc file is not
deleted by the system and is therefore available for further tests.
é Direct call of inbound function module. This allows the function module to be debugged. If this
flag is not set, the IDoc is sent for standard processing, as in the outbound test.
n Like the other test programs, the test tool has a special test status with which you can identify test
IDocs in the monitoring programs.

 SAP AG BC620 7-3


([HUFLVH

8QLW3URFHVVLQJ7HVWV
7RSLF7HVW7RRO RUGHUDFNQRZOHGJPHQW

At the conclusion of these exercises, you will be able to:


• Use the test tool
• Use IDoc display to trace IDocs

As a member of your EDI project team in purchasing, you want to test the
following as soon as possible:
• Sending purchase orders
• Receiving order acknowledgments

1-1 Create a purchase order for methanol (material number 6+ from the vendor 7
%,/QQ by selecting /RJLVWLFV→0DWHULDOV0DQDJHPHQW→3XUFKDVLQJ→3XUFKDVH
2UGHU→&UHDWH→9HQGRU.QRZQ (transaction ME21).
1-2 As a member of the purchasing department, you belong to SXUFKDVLQJRUJDQL]DWLRQ
 and SXUFKDVLQJJURXS. The methanol is required for SODQW (Berlin).
&RPSDQ\FRGH is  (IDES AG 1000).
1-3 After the data has been entered successfully, select Header -> Messages from the menu
in the item overview to check the proposal for the output of the purchase order via
Message Control. If GLVSDWFKWLPH has been selected, an IDoc for this purchase order
is generated as soon as the data is saved.
1-4 Change to 3XUFKDVH2UGHU→'LVSOD\. By selecting 6\VWHP→/LQNV the IDoc that has
just been generated is displayed.

2-1 You can now use the purchase order IDoc that has just been generated as a template for
the inbound order acknowledgment to be tested.
2-2 From the initial node of the IDoc Interface, choose7HVW→ 7HVW7RRO. Choose ([LVWLQJ
,'RF and call the value help, in which you search with the recipient partner number.
Choose &UHDWH.

 SAP AG BC620 7-4


2-3 Select the control record (the first record) by clicking with the mouse and change the
following fields:

Recipient, Port: SAP<SID>


Sender, Port: PORT-nn
Sender, Partner number: T-BILnn
Sender, Partner type: LI
Sender, Partner function: LF
Message type: ORDRSP
Choose &RQWLQXH.

2-4 As the order acknowledgment should contain at least the order number of the vendor,
create a corresponding segment. Copy segment E1EDK02 and change the following
fields:

Qualifier: 002
Document For example BC620-
: Test-4711
Choose &RQWLQXH to close the dialog box.

2-5 The acknowledgment of your vendor now has to be assigned to the item. Create a
corresponding segment E1EDP02 directly after the item segment E1EDP01 as a
subsegment. Maintain the following fields:

Qualifier: 001
Document: Order number, in segment E1EDK02, qualifier 001, field
GRFXPHQW
Document Document item, in segment E1EDP01, field GRFXPHQWLWHP
item:
Choose &RQWLQXH.

2-6 Choose 6WDQGDUG,QERXQG and then &RQWLQXH.

2-7 The system changes your original order. You can display the changed order by
selecting /RJLVWLFV→0DWHULDOV0DQDJHPHQW→3XUFKDVLQJ→3XUFKDVH2UGHU→
'LVSOD\. If you double-click on the item, you will see the acknowledgment number that
has just been transferred. By selecting 6\VWHP→ /LQNV from the item overview, you
can display the IDoc which is linked to the outbound purchase order, as well as the
IDoc which is linked to the inbound acknowledgment.

6,'!is the 3-character system ID (for example, ID3)


QQ is the number of your exercise group (from 1 to 18)

 SAP AG BC620 7-5


0HVVDJH&RQWURODQG,'RFV

l 0HVVDJHGHWHUPLQDWLRQDQGPHVVDJHSURFHVVLQJ

l &RQGLWLRQFRPSRQHQWV

l 'LVSDWFKWLPHV

 SAP AG 1999

 SAP AG BC620 8-1


0HVVDJH&RQWURODQG,'RFV8QLW2EMHFWLYHV

$WWKHFRQFOXVLRQRIWKLVXQLW\RXZLOOEHDEOHWR

l ([SODLQFRQGLWLRQFRPSRQHQWV
l )LQGH[DPSOHVRIFRQGLWLRQFRPSRQHQWVLQ00
&XVWRPL]LQJ
l 'LVSOD\DQGSURFHVVWKHSURSRVHGPHVVDJHIURPWKH
00DSSOLFDWLRQWUDQVDFWLRQ

 SAP AG 1999

 SAP AG BC620 8-2


%XVLQHVV6FHQDULR

l $VDPHPEHURIWKHLPSOHPHQWDWLRQWHDPIRU
6PDUW0DUW\RXDUHUHVSRQVLEOHIRUFRQILJXULQJWKH
,'RF,QWHUIDFH
$SXUFKDVHRUGHUIURP6PDUW0DUWLVILUVWO\FUHDWHGDVD
PHVVDJHE\WKH0HVVDJH&RQWUROPRGXOHEHIRUHEHLQJ
FRQYHUWHGLQWR,'RFIRUPDW<RXNQRZWKDWWKHEDVLF
VHWWLQJVIRUWKLVPRGXOHH[LVWLQWKHVWDQGDUG6$3
V\VWHPEXWZLVKWRILQGRXWPRUHDERXWRWKHU0HVVDJH
&RQWUROIXQFWLRQV

 SAP AG 1999

 SAP AG BC620 8-3


2XWERXQG3URFHVVLQJXVLQJ0HVVDJH
&RQWURO

6$3$SSOLFDWLRQ

  
)LQGSURSRVDO

0& (GLW


   
 3URFHVV

,'RF,QWHUIDFH$/(6HUYLFHV

 SAP AG 1999

n Message Control (MC) generates messages from application documents. The possible messages are
defined as condition records in Customizing.
n From the possible messages, MC searches for those which match the current application data. This
message determinationcan result in several messages being IRXQGor possibly none. In the
following example, we will presume that one message was found.
n If supported by the application, this message is proposed for editing in the transaction which started
MC. When creating a purchase order, this means that the message proposal can be edited (displayed
and changed) before the purchase order is posted.
n In any case, the message is generated and SURFHVVHG(if not deleted during the editing process): for
example, if the order is to be printed, the processing program sends the message to the printer. If the
message is to be sent as an IDoc, a special processing program is called from the IDoc Interface.
n The new message is represented by a new entry in the MC table. Part of this record is the SURFHVVLQJ
VWDWXV, which can have the following values: 0 = not yet processed, 1 = successfully processed, 2 =
processed with error.
n 1RWH For reasons of clarity, this slide does not show the transfer of the IDoc to an external system,
although this is also part of outbound processing.

 SAP AG BC620 8-4


0HVVDJH&RQWURO

6$3$SSOLFDWLRQ
(GLWLQJ

$SSOLFDWLRQGDWD

0HVVDJH'HWHUPLQDWLRQ
0HVVDJHSURSRVDO

0&UHFRUG

3URFHVVLQJ WDEOH71$35

3URFHVVLQJSURJUDP 2XWSXWIRU
IRUH[DPSOH561$67(' H[DPSOH,'RF

 SAP AG 1999

n The process diagram shows message determination, message editing and message processing.
n Message Control allows a GLVSDWFKWLPHflag to be set, which determines whether the message is
processed immediately after the application document is created or at a later time. In the second case,
you must schedule report RSNAST00 as a job, otherwise the message remains as an MC record with
processing status 0.
n The MC record refers to the document as a BOR object (BOR = Business Object Repository) which
contains all the important data for the message.
n Table TNAPR contains the processing programs (RSNASTED in the case of EDI). Form routine
EDI_PROCESSING is accessed within this program.

 SAP AG BC620 8-5


&RQGLWLRQ(OHPHQWV

6$3$SSOLFDWLRQ
Q
3URFHGXUH

PQ

2XWSXW7\SH
Q

$FFHVV6HTXHQFH
PQ
&RQGLWLRQ7DEOH

 SAP AG 1999

n Message determination uses the condition technique, which is also used in SD price determination.
Messages defined in Customizing are searched in a specified sequence. The FRQGLWLRQHOHPHQWV and
their hierarchy define this sequence.
n The messages are records in a FRQGLWLRQWDEOH. Several condition tables can belong to one RXWSXW
W\SH. The condition tables can be accessed according to a certain DFFHVVVHTXHQFH with different key
fields.
n Several RXWSXWW\SHV can belong to one procedure and severalSURFHGXUHV can belong to one
application, for example the DSSOLFDWLRQ EF (purchasing).
n Therefore, if one application wishes to send EDI messages via Message Control, only the procedure
for that application and the current application object (for example the document) is searched for
corresponding messages.
n The condition component "Access sequence” can be used to define whether only one message is to
be found: If this is the case, you should set the "exclusive” flag. If this flag is not set, the entire
access sequence is processed, that is, several messages have possibly been found.

 SAP AG BC620 8-6


0HVVDJH3URFHVVLQJ,'RFV

Check 0& record 5


6
Read partner profile 1
$
Call selection module 6
(from application) 7
(
Call $/( Services
'
Transfer according to
output mode
’1’/ ’2’ ’3’/ ’4’

Single IDoc Multiple IDocs


via 56(287

 SAP AG 1999

n The WUDQVPLVVLRQPHGLXP is part of the condition record (the message defined in Customizing). The
transmission media for IDoc processing with Message Control are:
é "6" EDI (Electronic Data Interchange), that is, without distribution model
é "A" ALE (Application Link Enabling), that is, with distribution model
The EDI program for message processing is started with these parameters: RSNASTED, with the
form routines EDI_PROCESSING or ALE_PROCESSING.
n IDocs are transferred individually from program RSNASTED when using output modes "1" and "2"
(field OUTMOD in the control record).
n IDocs are not transferred directly when using output modes "3" and "4" (field OUTMOD in the
control record). Instead, they are collected by the program RSEOUT00 (batch mode) and sent as a
group.

 SAP AG BC620 8-7


'LVSDWFK7LPHVLQ2XWE3URFJXVLQJ0&

Application MC IDoc Interface External System

3RVW 96=73  28702' 


5HDOWLPH

  28702' 
96=73 
)DVWEDWFK

  28702' 
96=73 
%DWFK

  28702' 
96=73 
%DWFK

 SAP AG 1999

n You should note that there are WZRdifferent dispatch times for outbound processing using Message
Control: one controlled by MC, the other by the IDoc Interface. Each of these times can be switched
between "immediately" and "later". If "later" is selected, the program must be started manually (for
test purposes) or as a batch job (in production operation), while the program is started automatically
if "immediately" is selected.
n If an EDI subsystem is the external system and port type "file” is used, there is a third stop sign: The
subsystem, when it is not triggered.
n Recommended combinations of stop signs (see slide):
é Real time: IDocs are sent to the external system individually when the application documents are
created.
é Fast batch: IDocs are sent to the external system individually when the MC selection program is
started manually or as a batch job. This can result in large amounts of data requiring inbound
processing in the EDI subsystem in a short space of time.
é Batch: A stack of IDocs is sent to the external system when the IDoc Interface selection program
is started manually or as a batch job. To use the system resources efficiently, you should select the
first stop sign, the MC dispatch time "later" (1 or 2).

 SAP AG BC620 8-8


6XPPDU\

l 0HVVDJH&RQWUROLVLPSRUWDQWLQ,'RFRXWERXQG
SURFHVVLQJ
l 0HVVDJHVGHILQHGLQ&XVWRPL]LQJDUHH[DPLQHGLQD
FHUWDLQVHTXHQFHWRGHWHUPLQHZKHWKHURUQRWWKH\
DSSO\WRWKHFXUUHQWDSSOLFDWLRQGDWD7KLVVHTXHQFHLV
GHILQHGE\WKHFRQGLWLRQFRPSRQHQWVDQGWKHLU
KLHUDUFK\
l ,'RFVSHFLILFPHVVDJHSURFHVVLQJWDNHVSODFHYLD
SURJUDP561$67('
l 8SWRWKUHHGLIIHUHQWGLVSDWFKWLPHVFDQEHGHILQHGIRU
RXWERXQGSURFHVVLQJ

 SAP AG 1999

 SAP AG BC620 8-9


([HUFLVH

8QLW0HVVDJH&RQWURODQG,'RFV
7RSLF&RQGLWLRQ(OHPHQWV

At the conclusion of these exercises, you will be able to:


• Create an output type
• Create a condition record

As a member of the EDI project team you must configure the electronic
dispatch of an order acknowledgment. For this you create an individual
output type and condition records.

1-1 Create the output type ZBQQas a copy of output type BA01 in transaction NACE.
The output type should provide the transmission medium 6 (EDI) as the default
values for the condition records.

1-2 You must transfer the processing program and routine for your transmission
medium EDI from output type BA01 . You must also ensure that the possible
partner function $*(sold-to party) is entered for your new output type.

1-3 Determine your new output type in the procedure for the sales 2UGHUPHVVDJHV
(application V1). Go to the navigation &RQWURO for this procedure.

1-4 Now create a condition record for output type ZBQQfor your partner T-BIKQQ of
sales organization 1020. You should use 6 (EDI) as the transmission medium.

QQ is your group number

 SAP AG BC620 8-10


6ROXWLRQ

8QLW0HVVDJH&RQWURODQG,'RFV
7RSLF&RQGLWLRQHOHPHQWV

1-1 In transaction NACE select ([SHUWPRGH and choose the application 9 (sales).

Select 2XWSXWW\SHV, go to change mode and select %$.

Choose (GLW → &RS\DV

Enter =%QQ as the target entry. In the 'HIDXOWYDOXHV tab page change the
transmission medium, if necessary, to (',.

When saving, you must confirm that you also want to copy all of the dependent
entries. You must still maintain the language field for the dependent entry for the
mail title (also if you do not use the transmission medium “mail” ). Choose, for
example, (1 (English).

1RWH By copying you have also transferred the access sequence of the original
BA01, which contains a condition table. You must fill this condition table in the
last part of the exercise.

1-2 In the output types screen, select your new output type =%QQ.

In the navigation frame select the entry 3URFHVVLQJURXWLQHV by double-clicking.

Check the entry. The program 561$67(' and the form routine
(',B352&(66,1* must be determined for the transmission medium 6 ((',).

In the navigation frame, now select the entry 3DUWQHUIXQFWLRQV.

To add the partner function $*, select 1HZ(QWULHV and enter this function for the
transmission medium 6 ((',).

Save your changes and return to the initial screen of transaction NACE.

 SAP AG BC620 8-11


1-3 In the initial screen of the transaction NACE, select the application 9 (sales).

Choose 3URFHGXUHV.

Select the procedure 9 (order messages).

In the navigation frame select the entry &RQWURO by double-clicking.

Choose 1HZ(QWULHV. Enter the following:

/HYHO (determines the order) QQ \RXUJURXS


QXPEHU
&RXQWHU (not relevant here) 
&7\S (= output type) =%QQ

Do not enter a condition, in order to ensure that in determination your output type
is searched every time for messages.

Save your changes and return to the initial screen of transaction NACE.

1-4 In the initial screen of the transaction NACE, select the application 9 and choose
&RQGLWLRQUHFRUGV.

Position the mouse on =%QQ and select &RQGLWLRQUHFRUGVagain.

Enter the sales organization  in the selection screen and select FRQWLQXH.

Make the following entries in the condition table:

&XVWRPHU 7%,.QQ
)XQFWLRQ $*
7UDQVPLVVLRQPHGLXP  ((',)
7LPH  (LPPHGLDWHO\)
/DQJXDJH (1 ((QJOLVK)

You can leave the SDUWQHU field empty as the partner is determined from the
customer master data. In the present case, it is identical to the customer. Finally the
message is sent to them, here as an IDoc.

Save your changes and return to the initial screen of transaction NACE.

1RWH The condition table is usually maintained in the sales master data as an order
message. The maintenance interface is the same as in the NACE initial access.

QQ is your group number

 SAP AG BC620 8-12


*HQHUDO6HWWLQJV

l 1XPEHUUDQJHV

l (YHQWUHFHLYHUOLQNDJH

l ,'RFDGPLQLVWUDWLRQ

l )DVWHQWU\

l /RQJQDPHVVKRUWQDPHV

 SAP AG 1999

 SAP AG BC620 9-1


*HQHUDO6HWWLQJV8QLW2EMHFWLYHV

$WWKHFRQFOXVLRQRIWKLVXQLW\RXZLOOEHDEOHWR

l &RQILJXUHWKHJHQHUDOSDUDPHWHUVLQWKH,0*
l 'HVFULEHZKHQWKH,'RF$GPLQLVWUDWRULVQRWLILHG

 SAP AG 1999

 SAP AG BC620 9-2


&XVWRPL]LQJXVLQJWKH,0*

5&XVWRPL]LQJ,0*

&URVVDSSOLFDWLRQ
FRPSRQHQWV

,0*GRFXPHQWDWLRQ ,'RF,QWHUIDFH
3URMHFWGRFXPHQWDWLRQ

3URMHFWPDQDJHPHQW

$FWLYLWLHV

 SAP AG 1999

n General parameters for the IMG can be entered via the IMG. The IMG is a set of implementation
guidelines which can be used by customers to configure the R/3 System to meet their requirements
("Customizing"). The corresponding tables are maintained via DFWLYLWLHV
n By selecting the appropriate attributes, users can display only the activities which are required in
each case. For example, if a customer wishes to adopt all SAP standard settings, only the activities
with the attribute "required" must be executed.
n The IMG node or path for the IDoc Interface is &URVVDSSOLFDWLRQ&RPSRQHQWV ->,'RF,QWHUIDFH.
You should read the ,0*GRFXPHQWDWLRQ, which is available for each activity (double-click on the
relevant document).
n You can also create your own projects from the standard IMG: Projects are a type of view of the
standard IMG, which are used by different teams. The IMG offers SURMHFWPDQDJHPHQW functions
(resource planning and so on) as well as functions for creating your own SURMHFWGRFXPHQWDWLRQ via
customer notes.

 SAP AG BC620 9-3


1XPEHU5DQJHV

,'RF,QWHUIDFH

[…]

 SAP AG 1999

n Number ranges are intervals of natural numbers which are assigned to objects centrally by the R/3
System. This is called "internal number assignment".
n In the IDoc Interface, number ranges are set for:
• IDocs: the IDoc IDs are taken from the interval
• Ports: the names of the tRFC ports are defined by the interval
• Mailbags: These are only used for communication with an R/2 System. IDocs are transmitted in
mailbags
n These number ranges are maintained from the IMG node for the IDoc Interface.

 SAP AG BC620 9-4


(YHQW5HFHLYHU/LQNDJH

,'RF,QWHUIDFH

3URFHVVLQJ

5$SSOLFDWLRQ

 SAP AG 1999

n When IDocs are received, they are first saved in the database. In a second and independent step, they
are processed further (for port types "file", "XML", "CPI-C"). This is made possible by the workflow
event concept: If IDocs are saved in the database, an event is created , which waits for the "receiver"
in the system. The "receiver" (a function module) finds the event and triggers inbound processing.
As a result of this step, the function module has used the event, which no longer exists in the system.
The Workflow Manager determines when the receiver starts to search for events: There is therefore
an interval between the data being saved and further processing being initiated (asynchronous
processing).
n To enable this new form of inbound processing to take place, the corresponding event must be
actively linked to the receiver.
n You must therefore activate the event-receiver linkage in the IMG for the IDoc Interface.

 SAP AG BC620 9-5


,'RF$GPLQLVWUDWLRQ*OREDO3DUDPHWHUV

l 3DUW\WREHQRWLILHG ,'RF$GPLQLVWUDWRU
l 6\VWHPHQYLURQPHQW %DVLVV\VWHP"
l 3URFHVVLQJGHWDLOV

 SAP AG 1999
 SAP AG

n The IDoc administrator is always notified when an error occurs during IDoc processing and no
partner profile could be found. Otherwise, the partner-specific agent (and the message-specific agent,
if required) entered in the partner profile is notified.
n In the system environment, the IDoc interface is informed whether non-Basis components exist, for
example Message Control or application components. If these entries are not made, it is possible that
the IDoc interface may call function modules, for example, that do not exist in the specified system
(Basis system only).
n Processing details:
é The maximum number of syntax errors which can be recognized in one IDoc and therefore logged
as status records. The larger this value, the higher the probability that the error messages do not
refer to "real" errors, but only subsequent errors.
é Whether or not IDoc inbound processing is triggered synchronously (not via the event-receiver
linkage) (port type File). In this case, immediately after the event of the event receiver
é System parameters can be entered as "global parameters" from the initial screen of the IDoc
interface by choosing &RQWURO!,'RF$GPLQLVWUDWLRQor can also be set from the IMG node of the
IDoc interface.
é After how many data records a COMMIT WORK is initiated. You should also see the F1 Help
function for the input fields.

 SAP AG BC620 9-6


,'RF$GPLQLVWUDWLRQ8VHU3DUDPHWHUV

l 7HVWV
l 'RFXPHQWDWLRQ7RROV
l 'HYHORSPHQW

 SAP AG 1999
 SAP AG

n User-specific parameters for the IDoc interface FDQQRW be entered from the IMG. Instead, choose
&RQWURO!,'RFDGPLQLVWUDWLRQfrom the initial node of the IDoc interface.
n The WHVWSDUDPHWHUis the port proposed as standard by the test programs.
n For the GRFXPHQWDWLRQWRROVyou should define the default documentation output, for example,
whether the individual segment fields are also to be included in the documentation of IDoc types.
n You can enter a default GHYHORSPHQWclass for the development of IDocs and segments. Course
BC621 contains more information about developing and defining IDoc types.

 SAP AG BC620 9-7


)DVWHQWU\

'HIDXOWYDOXHV

 SAP AG 1999

n During fast entry of the partner profile values, default values ("templates") are already set in the
IMG, which facilitates the maintenance of the partner profiles in the IDoc interface.
n The default values are set for partner type and direction (inbound/outbound).
n If you select the fast entry option for partner profiles (via the pushbutton on the initial screen, see
later unit), the values which you have entered in the IMG for the current partner type and direction
are entered as the default values. According to your requirements, you need only select and modify
these values.
n You can also reach the transaction from the initial node of the IDoc interface.
n In the IDES system, the following message types are maintained for the vendor or customer,
depending on the direction:
é DELINS - forecast/JIT delivery schedule
é ORDCHG - change purchase order/sales order
é ORDERS - purchase order/sales order
é DESADV - shipping notification
é INVOIC - invoice/billing document
é ORDRSP - order/sales confirmation

 SAP AG BC620 9-8


/RQJ1DPHV6KRUW1DPHV

5HOHDVH 5HOHDVH;

7\SH
7\SH6KRUW
/RQJ1DPH;<=

 SAP AG 1999

n Release 4.0 introduced the concept of the extended namespace. As a result, new IDoc Interface
objects which were developed for Release 4.0 (for example IDoc types) can have longer names than
before.
n This fact can lead to problems when communicating with older releases which only recogníze short
names. If required, tables which can convert the long names to short names must therefore be
maintained.
n These tables are maintained in the IMG or from the IDoc Interface development (path for segments
or IDoc types from the relevant editor: (QYLURQPHQW!&RQYHUVLRQ!REMHFWQDPH! You should
also read the online documentation.

 SAP AG BC620 9-9


*HQHUDO6HWWLQJV6XPPDU\

l *HQHUDOVHWWLQJVDUHHQWHUHGYLDWKH,0*,Q
DGGLWLRQXVHUVSHFLILFSDUDPHWHUVFDQEHFKDQJHG
DWDQ\WLPHYLDWKHFRQWUROPHQX
l 7KH,'RF$GPLQLVWUDWRULVSDUWRIWKHJOREDO
SDUDPHWHUVZKLFKDUHPDLQWDLQHGLQ,'RF
$GPLQLVWUDWLRQ:KHQH[FHSWLRQVRFFXUWKH
DGPLQLVWUDWRULVDOZD\VQRWLILHGLIQRSDUWQHUSURILOH
LVIRXQG

 SAP AG 1999

 SAP AG BC620 9-10


([HUFLVH

8QLW*HQHUDO6HWWLQJV
7RSLF)DVWGDWDHQWU\

At the conclusion of these exercises, you will be able to:


• Maintain the default values for fast entry.

As a member of the EDI project team enter the company T-BIKQQ as the
EDI customer for the sales orders and order acknowledgments As you
expect further EDI customers for these messages, you want to use
corresponding proposals in Customizing.

1-1 Go to IDoc Interface Customizing (choose %DVLV&RPSRQHQWV→%DVLV6HUYLFHV→


,'RF,QWHUIDFH) and check the following default values:
Outbound Processing:

3DUDPHWHU 9DOXH
Partner type KU
Message type ORDRSP
Partner function AG
Basic type ORDERS01
Application V1
Output type BA00
Process code SD10

Inbound Processing:

3DUDPHWHU 9DOXH
Partner type KU
Message type ORDERS
Partner function AG
Process code ORDE

 SAP AG BC620 9-11


2-1 Now transfer these default values to the partner profiles of your customer. As a result
you can
• Receive sales orders from the customer
• Send order confirmations to this customer

The corresponding master data in the SD application has already been created for you.

2-2 From the initial node of the IDoc Interface, choose,'RF→ 3DUWQHU3URILOH. Choose
8WLOLWLHV → )DVW'DWD(QWU\ and enter the customer number T-BIKQQ. Select the
proposal for outbound processing. The logical message is ORDRSP.

2-3 Choose 8WLOLWLHV → )DVW'DWD(QWU\ again but now for inbound processing. The logical
message is ORDERS. Save your entries.

2-4 Go to the outbound parameters for message ORDRSP. Replace output type BA00 with
your output type ZBQQ from the exercise in the “Message Control” unit.

QQ is your group number

 SAP AG BC620 9-12


$GGLWLRQDO7HVW3URJUDPV

l 7HVWOD\HUV

l 7HVWSURJUDPV

 SAP AG 1999

 SAP AG BC620 10-1


3URFHVVLQJ7HVWV8QLW2EMHFWLYHV

$WWKHFRQFOXVLRQRIWKLVXQLW\RXZLOOEHDEOHWR

l 8VHVSHFLDOWHVWSURJUDPVDQGGHWHUPLQHZKHQWR
LPSOHPHQWWKHPGXULQJSURFHVVLQJ

 SAP AG 1999

 SAP AG BC620 10-2


3URFHVVLQJ7HVWV%XVLQHVV6FHQDULR

l $VDPHPEHURIWKHLPSOHPHQWDWLRQWHDPIRU\RXU
FRPSDQ\ 6PDUW0DUWRU4XLFN'HOLYHU \RXDUH
UHVSRQVLEOHIRUFRQILJXULQJWKH,'RF,QWHUIDFH
$IWHUWHVWVKDYHEHHQFRPSOHWHGVXFFHVVIXOO\LQ
\RXURZQV\VWHPDQGWKH(',VXEV\VWHPKDVEHHQ
FRQQHFWHG\RXZLVKWRWHVWGDWDWUDQVIHU
7KH,'RF,QWHUIDFHWHVWSURJUDPVDUHWREHXVHGIRU
WKLVSXUSRVHDQGWKLVXQLWFRQWDLQVLQIRUPDWLRQ
DERXWXVLQJWKHVHWRROV

 SAP AG 1999

 SAP AG BC620 10-3


7HVW/D\HUV2YHUYLHZ

$SSOLFDWLRQ

0& :RUNIORZ
%0&.(2143
%6&.(27 %0&.(25

,'RF,QWHUIDFH

%0&.(98:3%;&.(<1 %'&)(-, %'&.(/

([WHUQDO
  
%'&)(+*  
 

6\VWHP
            "!$#

)LOH6\VWHP
%6&.(25

 SAP AG 1999

n The arrows show the layers where the tests start. Alongside is the relevant transaction. Outbound
processing is on the left, inbound processing on the right. According to the process code (partner
profile entry), the inbound test IDocs are processed directly in the application or via a workflow.
n All test programs write a special status. Hence you can determine whether or not each IDoc was
generated for test purposes.
n The IDoc statistics provide an overview of all test IDocs (F5 key, also see "Statistics and
Monitoring").
n The test tool (transaction WE19, see corresponding unit) is the most general tool. Both inbound and
outbound processing can be tested for one IDoc (which can even be created manually).
n The other test programs require either an existing file, a message status record (MC record), or a file
in the file system (at the operating system level).
n If a file port is selected in outbound processing, a complete test cycle (from outbound processing to
inbound processing) can be executed, including the file system.

 SAP AG BC620 10-4


7HVW/D\HUV2XWERXQG3URFHVVLQJ

$SSOLFDWLRQ

0&
0&

%6&.(27

,'RF,QWHUIDFH

%0&=(98 3%;&.(-1

([WHUQDO
6\VWHP

 SAP AG 1999

n When testing from MC (transaction WE15), you can test whether an IDoc is created correctly from a
generated MC record. In this case, dispatch time 1 or 2 must be configured in the message condition
record: This stops message processing, that is, the processing program RSNAST00 is not started
directly when the application document is created, and the MC record is assigned the status 0 (not
yet processed).
Transaction WE15 does nothing but start program RSNAST00, that is, trigger further processing
manually. Using this method, you can, for example, go into debugging mode or export messages,
which is not possible in other cases.
n Both the IDoc test (transaction WE14) and the test tool (transaction WE19) test the transfer of one or
more IDocs to the specified port. As a prerequisite for the IDoc test, an outbound IDoc which has not
been sent to any ports must exist already (current status 30). Such an IDoc can be generated, for
example, using transaction WE15: In the corresponding partner profiles, the output mode must be
entered as "collect IDocs”, so that the IDocs are not forwarded immediately.
There are no prerequisites for the test tool.
n 1RWH Transaction WE15 can only be used in conjunction with moving data from the applications SD
and MM. The corresponding message types are ORDERS, ORDRSP, DESADV and INVOIC, for
example. Only these modules and messages use Message Control for IDoc outbound processing.

 SAP AG BC620 10-5


7HVW/D\HUV,QERXQG3URFHVVLQJ

$SSOLFDWLRQ

:RUNIORZ

%'&=(21

,'RF,QWHUIDFH

%'&=(,

%0&=(+*

)LOH6\VWHP
 @:
 

 > 4   > ?  

 SAP AG 1999

n Both the modified outbound file test (transaction WE12) and the original inbound file test (WE16)
test the transfer of an IDoc file via the IDoc Interface. WE12 changes control records to create an
inbound IDoc from an outbound IDoc, before the IDoc is sent to the IDoc Interface.
n There are no prerequisites for the inbound test tool: no inbound port of type "file" is needed and no
files are required from the file system. The test tool can even create inbound IDocs if necessary.
n Check the online documentation (extended help) for the test tools.
n 1RWH WE16 erases the inbound file after the file has been read successfully. This does not apply to
outbound files, which are read by WE12 and can therefore be used for further test runs.

 SAP AG BC620 10-6


7HVW/D\HUV6WDWXV&RQILUPDWLRQ

$SSOLFDWLRQ

:RUNIORZ
%'&)(+1J3
%'&)(+5

,'RF,QWHUIDFH

%'&)(-, %'&)(</

  
@ 

%'&)(+*  
A  4B' C   BK AC
   L!;#
 DEFG=FH:I D>>FG=FHI

)LOH6\VWHP
%6&.(25

 SAP AG 1999

n You test the transfer of status confirmations in file format with "process status file" (transaction
WE17). Transaction WE18 ("generate status file") does not need a file as it is self-generating. The
IDoc display function can be used to check if the status records were written correctly to the relevant
IDoc.
&DXWLRQAs in the case of an original inbound IDoc, the status file is deleted after being read
successfully. The test can therefore be carried out only once for each file.
n When a status record is received which indicates an error, a workflow is started: The (status) process
code for this purpose in the standard system is EDIS. Other process codes for other tasks/workflow
definitions for status processing can be created via &RQWURO ->6WDWXVSURFHVVFRGH and &RQWURO ->
6WDWXVPDLQWHQDQFHfrom the IDoc Interface initial screen.
n Status records must refer to outbound IDocs in the system, otherwise an error occurs in status
processing.
n The general status confirmation for all port types and directions runs via the special IDoc type
SYSTAT01, which is processed by standard task TS300000206. This status processing therefore
always takes place via workflow. If an incorrect status is returned, a work item is generated.
n SYSTAT01 can be used with all the inbound test programs. IDocs of this type must be present in file
form, except in the case of the test tool.

 SAP AG BC620 10-7


:KHQWR7HVW:KLFK)XQFWLRQ"

l 'DWDH[FKDQJHZLWKWKHILOHV\VWHP:(
RXWERXQG :( LQERXQG :( VWDWXV
FRQILUPDWLRQLQERXQG
l 3URFHVVLQJ0&UHFRUG:(
l 'DWDWUDQVIHUIURPWKH,'RF,QWHUIDFHWRDGGLWLRQDO
LQERXQGSURFHVVLQJ:(
l 'DWDWUDQVIHUWRDQ\SRUW:(

 SAP AG 1999

 SAP AG BC620 10-8


3URFHVVLQJ7HVWV6XPPDU\

l 6SHFLDOWHVWSURJUDPVUHTXLUH0&UHFRUGVILOHVRU
H[LVWLQJ,'RFVIURPWKHGDWDEDVH,IQHFHVVDU\
DXWRPDWLFRXWERXQGSURFHVVLQJPXVWEHVWRSSHGYLD
WKHRXWSXWPRGHIURPWKHSDUWQHUSURILOHDQGWKH
GLVSDWFKWLPHLQWKH0&FRQGLWLRQUHFRUG
l 7KHWHVWWRRODOORZVJHQHUDOWHVWVIRULQERXQG
SURFHVVLQJRXWERXQGSURFHVVLQJDQGVWDWXV
FRQILUPDWLRQYLD6<67$7

 SAP AG 1999

 SAP AG BC620 10-9


$3URFHVV&KDLQ

l 6HQGSXUFKDVHRUGHU

l 3RVWVWDQGDUGRUGHU

 SAP AG 1999

 SAP AG BC620 11-1


$3URFHVV&KDLQ8QLW2EMHFWLYHV

$WWKHFRQFOXVLRQRIWKLVXQLW\RXZLOOEHDEOHWR

l 6HQGDSXUFKDVHRUGHUYLD,'RF
l 5HFHLYHDVWDQGDUGRUGHUYLD,'RF

l ([SODLQZKLFK(',VSHFLILFPDVWHUGDWDPXVWEH
PDLQWDLQHG

 SAP AG 1999

 SAP AG BC620 11-2


$3URFHVV&KDLQ%XVLQHVV6FHQDULR

l $VDPHPEHURIWKHLPSOHPHQWDWLRQWHDPIRU\RXU
FRPSDQ\ 6PDUW0DUWRU4XLFN'HOLYHU \RXDUH
UHVSRQVLEOHIRUFRQILJXULQJWKH,'RF,QWHUIDFH
)RUWHVWSXUSRVHV,'RFVDUHWREHFUHDWHGE\
6PDUW0DUWDQGVHQWWR4XLFN'HOLYHU

 SAP AG 1999

 SAP AG BC620 11-3


3XUFKDVH2UGHUVIRU6PDUW0DUW

R/3 System - SmartMart


3RVWSXUFKDVHRUGHUZULWH0&UHFRUG

)LQGSRUW W\SH)LOH IRU4XLFN'HOLYHU

*HQHUDWH,'RFVHQGWRSRUW

&RS\GDWDSURFHVVIXUWKHU

External System = SmartMart EDI Subsystem

 SAP AG 1999

For SmartMart, the data flow appears as follows:


n As the purchase order is created in MM, outbound processing has to take place using Message
Control. The master data for the vendor QuickDeliver therefore contains a condition record which
uses the order to find the corresponding EDI message and writes an MC record.
n The key fields in the MC record are assigned to the corresponding key fields in the partner profile
(outbound processing using Message Control). They determine the process code, which in turn
defines the outbound processing (generating an outbound IDoc using a function module).
n The key fields in the partner profile (outbound processing using Message Control) are assigned to the
corresponding key fields in the partner profile (general outbound processing). This determines the
IDoc type (ORDERS01) and the port.
n The IDoc Interface now knows which IDoc type to generate with which function module. The IDoc
is created. The partner profile specifies that the IDoc is immediately sent to the port.

 SAP AG BC620 11-4


(',5HOHYDQW0DVWHU'DWDLQ3XUFKDVLQJ

9HQGRUPDVWHUUHFRUG 'DWDUHFRUG E1EDKA1


'() * ,+%"+-/.

Partner number, type, Partner information


function
'DWDUHFRUG

 
E1EDKA1 :
9HQGRUPDVWHUUHFRUG Partner information
Vendor account
'DWDUHFRUG
  !"$#%&
E1EDP19 :
0DWHULDOPDVWHUUHFRUG Material number
Material name
'DWDUHFRUG
  !"10&
E1EDP19 :
9HQGRUPDWHULDOQXPEHU Material number
Material name for vendor
,'RF7\SH25'(56
0&FRQGLWLRQUHFRUG with
transmiss. medium "6" (EDI)
 SAP AG 1999

The MM master data must contain certain parameters which are sent to the order recipient via IDoc:
n Apart from the partner number and type, the vendor master record must contain the partner function.
The partner function is a required field entry in the additional outbound partner profile using
Message Control (MC).
n The vendor master record should contain the name which appears as the partner number in the
recipient partner profiles as the "account with vendor" (field LFB1-EIKTO). This field is compared
with the partner number value in the recipient inbound partner profile. If this field is not maintained,
additional conversions are required in the recipient system.
n The vendor material information must contain the material name for the vendor, because the
recipient determines from the contents of a segment of type E1EDP19 which material has been
ordered.
n The MC condition record must contain a transmission medium "6” (EDI). The recipient cannot see
this value. If another transmission medium is entered, the IDoc Interface will not be activated.

 SAP AG BC620 11-5


6WDQGDUG2UGHUIRU4XLFN'HOLYHU

External System = QuickDeliver EDI Subsystem

6HQGGDWDWR
56\VWHP

R/3 System

'HWHUPLQHSURFHVVLQJIRU6PDUW0DUWGDWD
JHQHUDWH,'RF

3RVWVWDQGDUGRUGHU
2354

1R

2354
Generate work item
1R

 SAP AG 1999

For QuickDeliver, the data flow appears as follows:


n The external system (QuickDeliver EDI subsystem) calls the inbound function module for the port
type "File" in the QuickDeliver R/3 System via RFC. The inbound port is therefore defined by the
external system.
n The IDoc Interface recognizes the external system if the system is defined as an inbound port. The
IDoc is then created in the database.
n Control record fields in the inbound IDoc are assigned to the corresponding key fields in the inbound
partner profile. They determine inbound processing (in this case, direct processing by a function
module). This function module reads the order data and posts the document as a standard order in
SD.
n 1RWHDo not confuse the two function modules described here: The first is called by the external
system via RFC and generates the IDoc, while the second is the application function module which
reads the data in the new inbound IDoc.

 SAP AG BC620 11-6


(',6SHFLILF0DVWHU'DWDLQ6DOHV

'DWDUHFRUG E1EDKA1 &XVWRPHUPDVWHUUHFRUG


6  9
:
Partner information Partner number, type,
function
'DWDUHFRUG E1EDKA1
6 ,+%$+7.

Partner information 6'&XVWRPL]LQJ


Assigning customer/
vendor to sales
'DWDUHFRUG E1EDP19
8  !0&
: organization
Material number
0DWHULDOPDVWHUUHFRUG
Material name

,'RF7\SH25'(56
,'RF7\SH25'(56

 SAP AG 1999

The SD master data must contain EDI-specific parameters which are compared with the data from the
order IDoc:
n Partner number, type and function of the sender are assigned according to the data in the partner
profile. This data must also exist in the SD master data.
n The material number is transferred in a segment of type E1EDP19. This material must exist in the
material master record. The qualifier 002 in the segment shows that this is the material number for
the vendor.
n If the EDI subsystem does not assign the combination of customer and vendor to a sales organization
via segments of type E1EDK14 (document header organizational data), you must maintain this
assignment yourself using the customizing transaction (VOED).

 SAP AG BC620 11-7


$3URFHVV&KDLQ6XPPDU\

l 6SHFLDO(',SDUDPHWHUVPXVWEHHQWHUHGLQWKH
DSSOLFDWLRQPDVWHUGDWD7KHVHLQFOXGHSDUWQHU
LQIRUPDWLRQDQGWUDQVPLVVLRQPHGLXPLQWKH
FRQGLWLRQUHFRUGIRURXWERXQGSURFHVVLQJXVLQJ
0HVVDJH&RQWURO 0& 

l 2XWERXQGSURFHVVLQJXVLQJ0HVVDJH&RQWUROLV
DOZD\VDSSOLHGIRUSXUFKDVHRUGHUVIURPWKH00
PRGXOH

 SAP AG 1999

 SAP AG BC620 11-8


([HUFLVH

8QLW$3URFHVV&KDLQ
7RSLF6HQGSXUFKDVHRUGHU

At the conclusion of these exercises, you will be able to:


• Use IDoc display to trace IDocs

As a member of the EDI project team you want to simulate the message
chain from the outbound purchase order via the incoming order to the
sending and subsequent receiving of the order acknowledgment. First,
you take the role of the customer, then the vendor (incoming order and
outbound order acknowledgment) in order to act as the customer again
(incoming order acknowledgment) at the end of the message chain.

1-1 Create a purchase order for methanol (material number 6+ from the vendor 7
%,/QQ by selecting /RJLVWLFV→0DWHULDOV0DQDJHPHQW→3XUFKDVLQJ→3XUFKDVH
2UGHU→&UHDWH→9HQGRUNQRZQ (transaction ME21).
1-2 As a member of the purchasing department, you belong to SXUFKDVLQJRUJDQL]DWLRQ
 and SXUFKDVLQJJURXS. The methanol is required for SODQW.
1-3 After the data has been entered successfully, select *RWR → 0HVVDJHV from the menu in
the item overview to check the proposal for the output of the purchase order via
Message Control. If GLVSDWFKWLPH has been selected, an IDoc for this purchase order
is generated as soon as the data is saved.
1-4 Change to 3XUFKDVHRUGHU→'LVSOD\. By selecting 6\VWHP→/LQNV the IDoc that has
just been generated is displayed.
As 6HQG,'RFLPPHGLDWHO\ has been set in the partner profiles, the IDoc has the status
03, that is, it has been written in a file.

 SAP AG BC620 11-9


8QLW$3URFHVV&KDLQ
7RSLF,QFRPLQJRUGHU

2-1 In the previous exercise, a file was created in which the data is correct but the control
record is incorrect.

2-2 Select 7HVW!,QERXQG3URFHVVLQJ0RGLILHG2XWERXQG)LOH from the initial node of


the IDoc Interface (transaction WE12). This transaction allows you to change the
control record so it is correct, that is, matches the partner profile you created in the
exercise "General Settings" for your customer T-BIKQQ.

You can set default values for source, destination and port, by setting your port 3RUWQQ
for the test by choosing *RWR→8VHUVHWWLQJV.

2-3 The sender is customer T-BIKQQ from whom you wish to receive the order. Enter 7
%,.QQas the partner number, .8 as the partner type and $* as the partner function.
The logical message is 25'(56. For all other values, you can use the default values.

2-4 Choose ([HFXWH.

2-5 Choose ,'RF→'LVSOD\,'RF or ,'RF→,'RF/LVWV to view the IDoc which you have
created. By choosing 6\VWHP→/LQNV the order that has just been generated is
displayed.

 SAP AG BC620 11-10


8QLW$3URFHVV&KDLQ
7RSLF6HQGRUGHUDFNQRZOHGJPHQW

3-1 In the previous exercise you posted an order. An outbound IDoc has already been
generated by Message Control for order acknowledgment. The IDoc has the status 30,
therefore has not yet been sent by the SAP System.
3-2 Initiate the transfer of the order IDocs by choosing 7HVW→ 2XWERXQG3URFHVVLQJIURP
,'RF from the initial node of the IDoc Interface. Select with the recipient partner
number.
3-3 Return to the order (transaction VA03) and check the status of the ORDRSP IDoc, and
choose 6\VWHP→/LQNV. If this IDoc has status 03, you have generated a file.

 SAP AG BC620 11-11


8QLW$3URFHVV&KDLQ
7RSLF5HFHLYHRUGHUDFNQRZOHGJPHQW

4-1 In the previous exercise, a file was created in which the data is correct but the control
record is incorrect.

4-2 Select 7HVW!,QERXQG3URFHVVLQJRI0RGLILHG2XWERXQG)LOH from the initial node of


the IDoc Interface. This transaction allows you to change the control record so it is
correct, that is, matches the partner profile you created in the exercise "partner profiles"
for your customer T-BILQQ.

4-3 The sender is vendor T-BILQQ from whom you wish to receive the order
acknowledgment. Enter 7%,/QQas the partner number, /, as the partner type and /)
as the partner function. The logical message is 25'563. For all other values, you can
use the default values.

4-4 Choose ([HFXWH.


4-5 Choose ,'RF→'LVSOD\,'RF or ,'RF→,'RF/LVWV to view the IDoc which you have
created. By choosing 6\VWHP→/LQNV the purchase order that has just been changed is
displayed. If you double-click on the item, you will see the acknowledgment number
that has just been transferred.

 SAP AG BC620 11-12


6WDWLVWLFVDQG0RQLWRULQJ

l 3DVVLYHDQGDFWLYHPRQLWRULQJ

l :RUN,WHP$QDO\VLV

 SAP AG 1999

 SAP AG BC620 12-1


6WDWLVWLFVDQG0RQLWRULQJ8QLW2EMHFWLYHV

$WWKHFRQFOXVLRQRIWKLVXQLW\RXZLOOEHDEOHWR

l 'HFLGHZKHQGLIIHUHQWWRROVVKRXOGEHLPSOHPHQWHG
IRU,'RFPRQLWRULQJ
l 8VHWKHLQGLYLGXDOPRQLWRULQJWUDQVDFWLRQV

 SAP AG 1999

 SAP AG BC620 12-2


%XVLQHVV6FHQDULR

l $VDPHPEHURIWKHLPSOHPHQWDWLRQWHDPIRU\RXU
FRPSDQ\ 6PDUW0DUWRU4XLFN'HOLYHU \RXDUH
UHVSRQVLEOHIRUFRQILJXULQJWKH,'RF,QWHUIDFH
7KHH[FKDQJHRI,'RFVEHWZHHQWKHWZR
FRPSDQLHVLVWREHPRQLWRUHG$VDUHVXOW\RX
PXVWEHIDPLOLDUZLWKWKH,'RFPRQLWRULQJWRROV
DYDLODEOHIRUWKH,'RF,QWHUIDFH

 SAP AG 1999

 SAP AG BC620 12-3


0RQLWRULQJ3URJUDPV2YHUYLHZ

3DVVLYHPRQLWRULQJ $FWLYH
PRQLWRULQJ

6WDWLVWLFV 56(,'2&0


/LVW,'RF 

VHDUFK


'LVSOD\

 SAP AG 1999

n When errors occur, the IDoc Interface always notifies users actively (error handling via work items).
n In addition, the IDoc Interface provides four passive programs and one active program for IDoc
monitoring.
n The passive monitoring tools can be ordered according to their level of detail: The IDoc statistics
assign IDocs to status groups according to their current status, for example, to the group "inbound
error within the IDoc Interface". The individual IDocs are displayed in the IDoc list. This also
applies to the IDoc search, where IDocs are selected according to values in the segment fields.
Finally, IDoc display allows direct access to an individual IDoc via the ID. Double-clicking on the
relevant entry displays more details, as usual.
The passive monitoring tools can be found in the ,'RFmenu from the IDoc Interface initial node.
n Active monitoring (report RSEIDOCM) uses the status groups from IDoc statistics. It is possible to
define threshold values. When these values are exceeded, responsible users are notified via work
items. Active monitoring can therefore be seen as a configurable error handling function.
Active monitoring is scheduled as a job (from the R/3 initial screen, choose System -> Services ->
Jobs -> Define job). Variants are created from the ABAP editor (choose Goto -> Variants).

 SAP AG BC620 12-4


6HOHFWLRQ)LHOGVIRU0RQLWRULQJ

&RQWUROUHFRUG

&UHDWLRQ &KDQJH 3DUWQHU (',


GDWH GDWH PHVVDJH 5HIHUHQFHV

,'RFVWDWLVWLFV
,'RFOLVW
,'RFVHDUFK
,'RFGLVSOD\
$FWLYH
PRQLWRULQJ

 SAP AG 1999

n The monitoring programs are reports which select IDocs in the R/3 database according to certain
criteria from the control record.
n The most important selection field is the date on which the control record was created. The IDoc
statistics tool selects according to the change date.
n All monitoring programs allow selection of IDocs according to partner and message. In IDoc
statistics, this works via the extended selection.
n The highest number of selection fields is offered by the IDoc display function. Apart from the IDoc
ID, users can make selections according to EDI-specific parameters, for example the transmission
file in the EDI subsystem, which allows the data flow with the EDI subsystem to be monitored.

 SAP AG BC620 12-5


,PSOHPHQWLQJ)XQFWLRQV

$SSOLFDWLRQOHYHO3DUWQHUPHVVDJH

,'RFOLVW

7HFKQLFDOOHYHO6WDWXV,'RF,'

,'RFGLVSOD\

 SAP AG 1999

n All monitoring functions can display an individual IDoc. However, users can only access an IDoc
directly via the IDoc display function (using the IDoc ID). As the most selective tool, IDoc display is
usually used when technical questions arise (for example problems when communicating with an
EDI subsystem)
n The IDoc list function has less selection fields and is therefore easier to use. As with the remaining
tools, this function is used when application questions arise (for example how to display all IDocs of
message type INVOIC).
n IDoc statistics gives a broad overview and is often used for presentations because of its graphical
capabilities. To obtain statistics about "repaired" IDocs, choose the function "Evaluation history" in
the IDoc statistics. This displays all status records for the IDoc.
n You can use active monitoring as an alternative to normal exception handling if a user (employee) is
only to receive awork item if a certain number of incorrect IDocs (the threshold value) are found
within a specified time period. However, note that normal exception handling still takes place.
n Note that IDoc statistics selects all IDocs which have experienced a status change within the
specified time period, while active monitoring selects all IDocs created during the same period.

 SAP AG BC620 12-6


6WDWXV*URXS0RQLWRU6WDWLVWLFV







  
    
               

 ,'RFWUDQVIHU
VXFFHVVIXO
 
6HQGRN  
5HWUDQVPLVVLRQ 6HQGRN
RN

 ,'RFLQ
WDUJHWV\VWHP $/( 

 SAP AG 1999

n Status values for active monitoring and statistics about status groups are combined to prevent the
information becoming too complicated.
n The standard R/3 System assigns a group to each status via the "qualification” (synonym for "status
group”) value. This assignment can be changed from the initial IDoc Interface menu by choosing
&RQWURO!0DLQWDLQVWDWXVYDOXHV.
n According to the status group the individual statuses, for example, are displayed in the IDoc list in
the traffic light colors green, yellow or red. It should therefore be clear in the standard system
whether it concerns an error status, transfer- or success status. The traffic light color assignment for
status groups can be changed by choosing &RQWURO!0DLQWDLQVWDWXVJURXSV.
n For more information about the status groups which are supplied in the standard R/3 System, you
should read the online documentation for the IDoc statistics function.

 SAP AG BC620 12-7


:RUN,WHP$QDO\VLV

l 8VXDOO\UHIHUVWRH[FHSWLRQKDQGOLQJ
l :RUNLWHPVZKLFKH[LVWLQWKHV\VWHPDUHOLVWHG
$SSOLFDWLRQIRUORVWZRUNLWHPVIRUH[DPSOH QRXVHU
VHOHFWHG

 SAP AG 1999

n Work items are instances of defined single-step tasks. The IDoc Interface uses them mainly for
exception handling (see corresponding unit). They therefore contain the incorrect IDoc or the
incorrect application document which was created from the inbound IDoc.
n As in IDoc statistics, the work item analysis function allows work items belonging to a certain task
to be displayed. This can be useful, for example, if no user could be found for the work item, and the
work item did not therefore appear in any inbox. From the work items, you can jump to the IDoc
display function.
n The work item analysis function can be accessed by choosing 7RROV -> %XVLQHVV:RUNIORZ ->
'HYHORSPHQW-> 5HSRUWLQJ -> :RUNLWHPDQDO\VLVfor example the ZRUNLWHPVSHUWDVN (transaction
SW12_FREQ).

 SAP AG BC620 12-8


6WDWLVWLFVDQG0RQLWRULQJ6XPPDU\

l 7KH,'RFGDWDIORZFDQEHPRQLWRUHGYLDIRXUSDVVLYH
SURJUDPVDQGRQHDFWLYHSURJUDPLQWKH,'RF
LQWHUIDFH

l $FWLYHPRQLWRULQJLVDIXQFWLRQZKLFKFDQEH
LQGLYLGXDOO\FRQILJXUHGIRUHUURUKDQGOLQJRUJHQHUDO
H[FHSWLRQKDQGOLQJ

l 7KHOHYHORIGHWDLOLQWKHSDVVLYHPRQLWRULQJSURJUDPV
JRHVDVIDUDVGLVSOD\LQJWKHLQGLYLGXDO,'RFV7KH
OHDVWGHWDLOHGPRQLWRULQJWRROLVWKHVWDWXVJURXS
GLVSOD\XQGHU,'RFVWDWLVWLFV

 SAP AG 1999

 SAP AG BC620 12-9


([HUFLVH

8QLW6WDWLVWLFVDQG0RQLWRULQJ
7RSLF3DVVLYHPRQLWRULQJ

At the conclusion of these exercises, you will be able to:


• Use IDoc search
• Use IDoc display

You are the EDI administrator in your company. The purchasing


department has asked you the following questions:

1-1 ’’Which statuses has IDoc XY, which contains a purchase order for vendor 7
%,/QQ, already been assigned?’’

1RWH Use the IDoc display function

2-1 "Which IDoc was used to send purchase order XY to vendor 7%,/QQ?" You have
the following information:

Direction As a purchase order is involved, the direction is "outbound".


Basic type Purchase orders are sent to the EDI subsystem in your company
via IDoc type ORDERS01.
Segment You have the number of the purchase order. From the
documentation, you know that the order number is transferred in
the field BELNR in segment E1EDK02 with the qualifier "001"
(field QUALF).

1RWH Use the IDoc search function

3-1 "As a member of the purchasing department, can I access the corresponding IDocs
directly from my purchase order?"

4-1 "As a member of the purchasing department, can I access the corresponding IDocs
directly from my sales order?"

1RWHIRUH[HUFLVHVDQG: Choose 6\VWHP→/LQNV from your application


document.

 SAP AG BC620 12-10


8QLW6WDWLVWLFVDQG0RQLWRULQJ
7RSLF$FWLYHPRQLWRULQJ

• Using active monitoring

5-1 You want to trace IDocs in status 03. Include the report RSEIDOCM.

5-2 Go into the ABAP Workbench (SE38) and enter the report.

5-3 Choose ([HFXWH. Enter the following values in the selection screen:

Recipient type US

Recipient Your name BC620QQ

Start/end time before batch job Enter a meaningful value

Critical IDoc number 1

Status group 3 (contains status 03)

5-4 After executing the report you receive notification in the Business Workplace.
Execute the work item. The IDoc statistics are displayed where the current status of
the report execution is displayed. By selecting 5HIUHVK, the current status is
displayed.

 SAP AG BC620 12-11


6ROXWLRQ

8QLW6WDWLVWLFVDQG0RQLWRULQJ

1-1 Search by selecting ,'RF→'LVSOD\,'RF and entering the GLUHFWLRQ as “outbound”


and the SDUWQHUQXPEHURIWKHUHFLSLHQW. You have already generated the purchase
order IDoc in exercise 1 of the previous chapter.
1-2 Apart from the status which has been reached, determine which message has been put
on hold with the status value "30", that is, the values for code, message number,
message type and ID.

2-1 Search for the IDoc(s) using the IDoc search function. Select the following:

Direction 1 = “outbound”
Basic type ORDERS01
Segment You have the number of the purchase order. The number is in
field BELNR of segment E1EDK02 with the qualifier "001“.

3-1 Select /RJLVWLFV→0DWHULDOV0DQDJHPHQW→3XUFKDVLQJ→ 3XUFKDVH2UGHU→


'LVSOD\ (transaction ME23). Enter the purchase order number and choose &RQWLQXH.
From the transaction overview screen, choose 6\VWHP→/LQNV. The IDoc which is
linked to this purchase order is displayed and you can request more detailed
information about the IDoc by double-clicking with the mouse on the relevant entry.

4-1 Select /RJLVWLFV→6DOHVDQG'LVWULEXWLRQ→6DOHV→2UGHU→'LVSOD\ (transaction


VA03). Enter the sales order number and choose &RQWLQXH. The overview screen for
the transaction is displayed. Alternatively, find the sales order via the purchase order
number from exercise 3 and the search function. Choose 6\VWHP→/LQNV. The IDoc
which is linked to this sales order is displayed and you can request more detailed
information about the IDoc by double-clicking on the relevant entry.

 SAP AG BC620 12-12


:RUNIORZDQG,'RFV

l ,QERXQGSURFHVVLQJ

l ([FHSWLRQKDQGOLQJ

l 1RWLILFDWLRQFRQFHSW

l 2UJDQL]DWLRQDOVWUXFWXUH

 SAP AG 1999

 SAP AG BC620 13-1


:RUNIORZDQG,'RFV8QLW2EMHFWLYHV

$WWKHFRQFOXVLRQRIWKLVXQLW\RXZLOOEHDEOHWR

l ([SODLQKRZWKHDJHQWUHVSRQVLEOHLVLQIRUPHGLI
DQHUURURFFXUVGXULQJ,'RFSURFHVVLQJ
l 0DLQWDLQWKHRUJDQL]DWLRQDOVWUXFWXUH

 SAP AG 1999

 SAP AG BC620 13-2


:RUNIORZDQG,'RFV%XVLQHVV6FHQDULR

l $VDPHPEHURIWKHLPSOHPHQWDWLRQWHDPIRU
4XLFN'HOLYHU\RXDUHUHVSRQVLEOHIRUFRQILJXULQJ
WKH,'RFLQWHUIDFH
$SXUFKDVHRUGHUIURP6PDUW0DUWLVUHFHLYHGE\
4XLFN'HOLYHUDVDQLQERXQG,'RFRIW\SH
25'(56,QERXQGSURFHVVLQJLVFRQILJXUHG
XVLQJDSURFHVVFRGHDVGLUHFWYLDDIXQFWLRQ
PRGXOHH[FHSWLRQKDQGOLQJWDNHVSODFHE\PHDQV
RIZRUNIORZ<RXPXVWFRQILJXUHDSDUW\WREH
QRWLILHGLIDQHUURURFFXUV

 SAP AG 1999

 SAP AG BC620 13-3


,QERXQG3URFHVVLQJZLWK:RUNIORZ

,'RF,QWHUIDFH $/(6HUYLFHV



  

5HYLHZ
HGLW
:RUNIORZ
IRUZDUG
DQGVRRQ




6$3$SSOLFDWLRQ

 SAP AG 1999

n IDoc inbound processing can include a workflow which is triggered by a process code. This
workflow is defined by the user. Examples:
é An application document is created automatically from the IDoc. The application document is then
sent to a user for review.
é The IDoc is edited and modified if necessary before the application document is created. In this
case, the IDoc is edited and not the application document.
é The IDoc or application document is forwarded to other users or new (outbound) IDocs are sent,
using the inbound IDoc as a basis.
é Note: For reasons of clarity, this slide does not show the transfer of the IDoc from the external
system, although this is also part of inbound processing.

 SAP AG BC620 13-4


([FHSWLRQ+DQGOLQJZLWK:RUNIORZ

R/3 System
Check partner, generate IDoc


Post document
!#"
Express
 
!#" Error handling 0HVVDJH

 SAP AG 1999

n Exception handling or error handling is always defined as a workflow. One or more agents can be
notified about the error situation. The agents are defined in the IDoc Interface and in the organization
model of your company.
n SAP standard exception handling in the IDoc Interface always takes place using single-step tasks. It
is identified by means of process codes.
n If you set the express indicator in the process codes maintenance, the agent responsible for the
corresponding task receives a message on their screen as soon as a new work item appears in their
integrated inbox.
n The slide only shows exception handling being accessed from inbound processing. However,
exception handling can also be accessed from outbound processing.

 SAP AG BC620 13-5


([FHSWLRQVLQ2XWERXQG3URFHVVLQJ

6$3$SSOLFDWLRQ
RU0& X\9:<:A1Q9]PS. @'R"),<@?204#"6
(',0 PS. @'R"^,<@?X[Z WW0W

Document (',1 W5WW PU. @(RYX[Z


or MC
record =?> /<@BA<CD9%'%8")%
(',; .5/E2F4?"-6

$&%'%(")%+*),-%'.0/13254&"6
(',2
,'RF,QWHUIDFH
7 8% "69;:<:.5/1

$&%'%(")%QPSR.T 9 7 %8"69;:<:.5/1
(',3 2F4&"6U:<@BA;6V
IDoc

(',5
([WHUQDO6\VWHP
= @BA@',;:D6<")/;_'.%(`EA@'. "?/
(',6
GH<I-JLKM3NO

 SAP AG 1999

Single-step tasks are identified by (system) process codes:


n The process codes EDIM and EDIN are valid for inbound and outbound processing. No IDoc could
be created here. EDIN is used for outbound processing using Message Control: Using the MC record
you can branch from the work item to the application document.
n EDIO identifies an IDoc affected by an error during outbound processing.
n EDIX identifies an IDoc which contains a syntax error.
n EDIP identifies a stack of outbound IDocs (from a batch run of report RSEOUT00), in which a
processing error occurred and affected all the IDocs (a non-existent port, for example). The
corresponding single-step task can be used to correct the error and send the IDoc stack for processing
again.
n If the status "incorrect" is assigned to the group by the external system, a single-step task is
addressed using the status process code EDIS. Additionally, you can use code EDIR to trigger
outbound processing again after you have corrected the error.
1RWH EDIR is new for the Enjoy Release and replaces the old EDIS in the standard system. When
upgrading, you must explicitly execute the change to EDIR in the IMG.
n Additional exception handling for status confirmations can be defined and identified via process
codes.

 SAP AG BC620 13-6


([FHSWLRQVLQ,QERXQG3URFHVVLQJ

X[9::;A;1Q9ce-. AS2f4?"6
7;75$:

([WHUQDO6\VWHP X\9:<:A;1Q9]PS. @'R"^,<@?204#"6


(',0
IDoc W0WW 9Q%'%(")%+*),-%'.0/1
(',/ :<@(A@a,<:g_a.0T 9
$?%'%(")%+*),-%'.0/1Y2F4?"-6
,'RF,QWHUIDFH (',, 7 8% "6;9:<:.F/1

=^> /;@BACD9-%a%8"^%
IDoc
(',< .5/E254b"6

6$3$SSOLFDWLRQ 2F4?"6cPU. @aRE")%PS. @'R"),<@


$SSOLFDWLRQ A  7 7 T5. 6A@'. "?/D*"-6,`d9Q/<@

 SAP AG 1999

n Exception handling via single-step tasks for inbound processing is the same as for outbound
processing. Errors which occur when posting an application document (due to incorrect data, for
example) are sometimes handled and repaired by application-specific tasks and the corresponding
process codes. Application documents can also be generated in this way.
n EDIM applies as in outbound processing, EDII and EDIY are the same as the outbound process
codes EDIO and EDIX.
n Any messages can be sent in text format using the IDoc type TXTRAW01. Special case: an
exception occurs in the external system and the R/3 System is to be notified of this exception.
n If a status file of the external system cannot be read, the process code EDIL is activated. The SAP
System error message is displayed in exception handling.

 SAP AG BC620 13-7


1RWLILFDWLRQ&RQFHSW,

k %81QA/. lA;@'. ")/;ATm:;@'%j,6@a,%89


o^":;:.pT 9gA;1Q9Q/;@B:
nA:V

hb")T 9d%i9:Q")T,<@j. "^/ = 9QT 9;6@B9;*dA1Q9/<@

o-AQ%i@a/;9Q% 7 %8"Q_a.0T 9
o)9Q%a`Y. @B@B9*EA19Q/<@L:
254b"6S2/;@i9Q%B_BA6<9

 SAP AG 1999

n The agent determined in the IDoc Interface is only the permitted agent of a workflow task. All
"possible agents" are attached to the task itself. 5ROHUHVROXWLRQdetermines the set of agents which
are both allowed and possible agents. These agents are called the selected agents.
n All selected agents now receive the notification as a work item (as an "instance" of the workflow
task) in their integrated inbox.
n The IDoc Interface function module for role resolution is EDI_ROLE_FOR_PROCESSING.
n The IDocs can only be "repaired" and processed further from the integrated inbox.
n Note: If the tasks are defined as general tasks for notification, all users are possible agents, and the
set of selected agents is the same as the set of permitted agents.

 SAP AG BC620 13-8


1RWLILFDWLRQ&RQFHSW,,

SDUWQHUVDQGPHVVDJHV
SDUWQHUDQGPHVVDJH

EXWIRUDOOPHVVDJHV
6SHFLDOIRUSDUWQHU

*HQHUDOIRUDOO
6SHFLDOIRU

k ;, @ap"),/*x r 9Q/;9%iAQT r Q 9 /;9-%iAQT:;9<@f@'./Q1:


sa204&"6\tu*+`Y./. :;@(%iA@v. ")/w o+9Q%(`3. @B@B9;*qA;1Q9/<@L:
20/p"),/Q*

(',2(',,(',1 (',0(',3
(',;(',< (',5(',6(',/

 SAP AG 1999

n Permitted agents are entered in the following partner profiles for the IDoc Interface: Inbound,
outbound (optional), and general (required entry field). When an error occurs (for example a syntax
error in an inbound IDoc), the most relevant permitted agent is determined: The search for the agent
responsible for the PHVVDJHand SDUWQHU (key fields in the profiles) therefore starts in the inbound or
outbound partner profile.
n If no agent could be found in the inbound or outbound profiles (either because no value had been
entered or because no inbound or outbound partner profile could be found for the current partner-
message combination), the general partner profile is searched to determine a permitted agent for the
partner.
n If this search is also unsuccessful (because no general partner profile for the current partner could be
found), the search continues in IDoc Administration (general settings). If no entry is found, no users
are notified! For this reason, you should always enter an agent ("administrator") in the general
settings.
n In all cases, the agent can be a single person (type US=user) or a group which must be maintained in
the PD-ORG model, either as a job or a department.

 SAP AG BC620 13-9


1RWLILFDWLRQ&RQFHSW,,,

    0 f 
| ‚   |   F
mmm   F € | { 


2UJDQL]DWLRQDOXQLW &RVWFHQWHU
ym z  { F   <  5 
€ <| { 

| z m} 

}m m  | y m}\y y z  { F

} m  | y  | mz } 


-RE 3RVLWLRQ :RUNFHQWHU
}   | ym }\y
~;z } 
}   | ym }\y
}   | ym  }   | ym  ~m<z } 

3HUVRQXVHU
7DVN

 SAP AG 1999

n Workflow auto-customizing (transaction SWU3) includes all tasks relating to the IDoc Interface as
"general tasks", that is, all R/3 users are possible agents. If you want to restrict this number, you can
do this using an organizational structure.
n The organizational structure defines a responsibility hierarchy. For example, a general organizational
unit "administrators" could exist. This RUJDQL]DWLRQDOXQLW can now be assigned to several persons
who hold as many SRVLWLRQV This RUJDQL]DWLRQDOXQLW (not an individual) could be entered as a
possible agent in the IDoc Interface.
n You can also enter a position which corresponds to one person as a possible agent. The advantage is
that notifications are tied to positions, not to individuals whose responsibilities can change. This
concept can be compared to the process code and the relevant function module/workflow.
n Further elements of the organizational structure which can be entered as "possible agents" for a
standard task:
é -RE
é 8VHU R/3 user
é :RUNFHQWHU

 SAP AG BC620 13-10


0DLQWDLQLQJDQ2UJDQL]DWLRQDO6WUXFWXUH

l &XVWRPL]LQJDFWLYLWLHV
l 0DLQWHQDQFHIURPWKH:RUNIORZ
PHQX

 SAP AG 1999

n If an element of the organizational structure is to be entered as a possible agent instead of a person


(R/3 user), this element must be defined. This takes place in Customizing or from the workflow area
menu ('HILQLWLRQ): 2UJDQL]DWLRQDOSODQ!&UHDWH(transaction PPOM).
n From here, elements can be defined and assigned to each other or to R/3 users.

 SAP AG BC620 13-11


,QWHJUDWHG,QER[

6$3RIILFH

0HVVDJH :RUNIORZ

0LVVHGGHDGOLQH



 SAP AG 1999

n The integrated inbox can be accessed directly from the IDoc area menu (,'RF -> ,QWHJUDWHGLQER[) or
via transaction SO01. Via :RUNIORZ, you access your "worklist", that is, the list of work items for
which you are entered as a "selected agent". Work items are the instances of the single-step tasks.
n You can edit a work item from your worklist. As a result, the work item disappears from the
integrated inbox of all other selected agents.

 SAP AG BC620 13-12


:RUNIORZDQG,'RFV6XPPDU\

ƒ
1RUPDO,'RFSURFHVVLQJYLDZRUNIORZLVRQO\SRVVLEOHIRULQERXQG
SURFHVVLQJRIFHUWDLQ,'RFW\SHV
ƒ
([FHSWLRQKDQGOLQJDOZD\VWDNHVSODFHYLDZRUNIORZ,WLVFDOOHGLQ
RXWERXQGSURFHVVLQJLQWKHVDPHZD\DVLQLQERXQGSURFHVVLQJ
ƒ
(UURUVFDQEHFDXVHGE\LQFRUUHFWDSSOLFDWLRQGDWDRULQFRUUHFW
,'RFV\QWD[,QWKHVHFDVHVHUURUKDQGOLQJLVGLIIHUHQW
ƒ
7KURXJKWKHRUJDQL]DWLRQDOVWUXFWXUHZRUNIORZDOORZVXVHUVLQD
GHILQHGWDVNDUHDWREHQRWLILHGQRWLQGLYLGXDOXVHUVZKRVH
UHVSRQVLELOLWLHVPD\FKDQJH
ƒ
:RUNIORZDOORZVLQFRUUHFW,'RFVWREHIRUZDUGHGDVZRUNLWHPVLQ
DFRQWUROOHGPDQQHUIURPDQLQWHJUDWHGLQER[DQGHYHQWREH
UHSDLUHGLQVRPHFDVHV

 SAP AG 1999

 SAP AG BC620 13-13


([HUFLVH

8QLW:RUNIORZDQG,'RFV
7RSLF2UJDQL]DWLRQDOVWUXFWXUH

At the conclusion of these exercises, you will be able to:


• Maintain the organizational structure

As a member of the EDI project team, you should maintain the


organizational model for your company, so that notifications for the
individual areas of responsibility can be addressed correctly, for example
EDI administration and purchasing.

1-1 The organizational unit 50010120 ("EDI Department“) has already been created for
EDI administration. You should now assign your user to the organizational unit. To do
this, proceed as follows:
Choose 7RROV→%XVLQHVV:RUNIORZ→'HYHORSPHQW→'HILQLWLRQ7RROV→
2UJDQL]DWLRQDO0DQDJHPHQW→2UJDQL]DWLRQDO3ODQ→&KDQJH. Enter
RUJDQL]DWLRQDOXQLW and select &KDQJH. Access the 6WDIIDVVLJQPHQWV. Place
the cursor on the required function and choose $VVLJQKROGHU. On the next screen, you
can now assign yourself as user %&QQ of the organizational unit. Choose 6DYH.

 SAP AG BC620 13-14


8QLW:RUNIORZDQG,'RFV
7RSLF1RWLILFDWLRQFRQFHSW

As a member of the EDI project team, you wish to test whether


notifications about errors in the control information for inbound
processing are sent to your organizational unit 50010120 (EDI
department).

2-1 This exercise continues from exercise 3 in the unit "A Process Chain" (outbound order
acknowledgment). In this exercise, a file was created in which the data is correct but
the control record is incorrect. This outbound file is to be modified to an incorrect
inbound file.

2-2 Choose 7HVW→,QERXQG3URFHVVLQJ0RGLILHG2XWERXQG)LOH from the initial node of


the IDoc Interface. This transaction allows you to change the control record so it is
correct and matches the partner profile you maintained in the exercise "partner profiles"
for your vendor T-BILnn. However, you should intentionally make one mistake so that
a notification is generated.

2-3 The sender is vendor T-BILnn from whom you wish to receive the sales orders. Enter
7%,/QQ as the partner number. You should intentionally make one error in the partner
type and enter 86 (instead of /,). This results in no partner profile being found and the
IDoc administrator is notified. But this is the organizational unit 50010120.

2-4 You must still enter /) as the partner function and 25'563 for the logical message.
Choose ([HFXWH.

2.5 Select ,QER[ to display the integrated inbox. Execute the work item. Look at the status
record and the logged long text. Access the control record via the tree display for the
IDoc. If you use change mode here, you can change the partner type to /,. After you
have saved your entries and gone back to the previous screen via the F3 key, you can
choose (GLW→3URFHVV→%DFNJURXQG3URFHVVLQJ to continue inbound processing.

2.6 You can display the resulting IDocs via 'LVSOD\,'RF or ,'RF/LVWV (select with the
partner number). One IDoc was generated as a result of the test, the other was
generated as a copy of the original IDoc immediately before the original was modified.

QQ is the number of your exercise group (from 1 to 18)

 SAP AG BC620 13-15


8VLQJDQ(',6XEV\VWHP

l &RQYHUWLQJWRDQRWKHUVWDQGDUG

l 5HTXLUHGGDWDLQFRQWUROUHFRUGV

l 0RUHGRFXPHQWDWLRQ

 SAP AG 1999

 SAP AG BC620 14-1


8VLQJDQ(',6XEV\VWHP8QLW2EMHFWLYHV

$WWKHFRQFOXVLRQRIWKLVXQLW\RXZLOO
EHDEOHWR
l 5HFRJQL]HWKHWDVNVRIWKH(',VXEV\VWHP
l 'HVFULEHWKHGLIIHUHQFHVEHWZHHQUHTXLUHGILHOGVDQG
RSWLRQDOILHOGVLQFRQWUROUHFRUGV
l 8QGHUVWDQGWKHGLIIHUHQWZD\VWRLQIRUPWKH(',
VXEV\VWHPDERXWYDULRXV,'RFIRUPDWV

 SAP AG 1999

 SAP AG BC620 14-2


2YHUYLHZ'LDJUDP 5HFHLYLQJ'DWD

(',6XEV\VWHP" Send data to


R/3 System

Documentation
Documentation
Tools
Tools
R/3 System
Check port & partner, Port
Port Definition,
Definition,
Archive
Archive IDoc?
IDoc? generate IDoc Partner
Partner Profiles
Profiles

Post document

Error handling

 SAP AG 1999

n QuickDeliver must configure the IDoc Interface for inbound processing:


n QuickDeliver connects the (',VXEV\VWHP and enters the information about which data is to be sent.
The format definitions for the inbound IDocs can be defined by the subsystem. The R/3 System is
informed that the subsystem is a port.

 SAP AG BC620 14-3


%XVLQHVV6FHQDULR

l $VDPHPEHURIWKHLPSOHPHQWDWLRQWHDPIRU\RXU
FRPSDQ\ 6PDUW0DUWRU4XLFN'HOLYHU \RXDUH
UHVSRQVLEOHIRUFRQILJXULQJWKH,'RFLQWHUIDFH
<RXZLVKWRFRQQHFW\RXU(',VXEV\VWHP<RXPXVW
ILQGRXWDERXWWKHZRUNLQYROYHGLQFRQILJXULQJWKH
VXEV\VWHPEHIRUHFDUU\LQJRXWWKHZRUN

 SAP AG 1999

 SAP AG BC620 14-4


(',6XEV\VWHP5HVSRQVLELOLWLHV

+ ,.-
 /,0  
   $%&"
 '
$*
     ( 
 & )
   !
 "  # 

 SAP AG 1999

n The most important task of the EDI subsystem is converting to or from the required EDI standard;
This task is carried out by the WUDQVODWRU as a subfunction of the EDI subsystem. The individual
criteria, for example selecting and assigning fields, are mapping components (usually customer-
specific).
n Further processing, PHVVDJHKDQGOLQJ, is divided into outbound processing, inbound processing and
status confirmation. In outbound processing, the messages transferred from the translator are
combined in transmission files. In the case of inbound processing, the messages are separated from
the transmission files and sent to the translator. Status confirmations depend on the selected EDI
standard: For example, standard ANSI X.12 uses functional and interchange acknowledgments to
confirm successful data transfer between EDI systems.
n Physical data transfer takes place using the FRPPXQLFDWLRQPRGXOH of the EDI subsystem. This also
includes the implementation of the communication protocols, for example X.25 and X.400. The
communication module is often produced by a different supplier.
n 3DUWQHUSURILOHV contain the individual settings for a partner and a process, for example mapping.
n The DGGUHVVHVare required by the communication module.
n $UFKLYLQJtakes place in accordance with various laws and directives. These include the guidelines
laid down by the relevant tax authorities.
n When EDI processes are being PRQLWRUHG, certain statuses are expected to be sent to the R/3 System
as reference points to ensure integration with the applications.

 SAP AG BC620 14-5


5HTXLUHG)LHOGVLQ,'RF,QE3URFHVVLQJ&RQWURO
5HFRUG

(Number, type, function) (Type, code, function) ,'RF


FRQWUROUHFRUG
Partner Message Test?

Partner Message Test? ,QERXQG


3URFHVVLQJ
SDUWQHU
3URFHVVFRGH,QERXQGSURFHVVLQJZLWK$/(" SURILOHV
3HUPLWWHGDJHQWV$QGVRRQ

 SAP AG 1999

n In inbound processing, the IDoc Interface assigns the key fields from the partner profiles to fields in
the control record. The values of other fields are checked explicitly in the coding.
n As a result, an EDI subsystem must send certain fields with their values for IDoc inbound
processing:
é Partner, message (three fields each) and test flag (1 field) must correspond to the entries in the
partner profile. This also means that the partner function value, for example, must be left empty if
the corresponding field in the partner profile is also empty.
é Direction = 2 (inbound), structure = EDI_DC40 (external control record structure in Release 4.0).
An R/3 System (Release 3.x) would expect a different structure.
é Sender port and recipient port
é IDoc type. The IDoc Interface checks whether the IDoc type is assigned to the message
(assignments can be maintained from the initial node by selecting 'HYHORSPHQW -> ,'RF
W\SH/PHVVDJH).
n Special requirements can require additional fields:
é (Customer-) extension. (see course BC621 for more information)
é Logical address of sender/recipient for automatic forwarding
n The IDoc Interface enters values for empty optional fields and checks the values, which can lead to
an error if the wrong value is found.
n A complete list of fields can be found in the appendix.

 SAP AG BC620 14-6


0RUH'RFXPHQWDWLRQ

,'RF,QWHUIDFH'RFXPHQWDWLRQ7RROV

%HJLQ ;0/ W\SHGHIVWUXFW]LQFRG[


«
«
(QG ]LQFRG[

 SAP AG 1999

n The EDI subsystem can use a parser which "understands" the appropriate output format for the IDoc
Interface. This means that the external formats (record types and IDoc types) can be recognized by
other systems.
n C-headers fulfill the same purpose: They can be included in the corresponding C-programs in the
EDI subsystem.
n There are also "meta-IDocs": These are two special IDoc types which describe the external formats
in their data records: The types are called
é SYIDOC01 - contains the format definition of an IDoc type (that is record types and segments)
é SYRECD01 - contains the format definitions of IDoc record types:
It is conceivable, for example, that an EDI subsystem only recognizes record types from releases
2.X and 3.X (that is, "versions” 1 and 2). Using SYRECD01 (record type versions 1 or 2), the new
record types for Release 4.0 (version 3) can be sent to the EDI subsystem.
n Metadata can also be output for XML IDocs.

 SAP AG BC620 14-7


8VLQJDQ(',6XEV\VWHP6XPPDU\

l 7KH(',VXEV\VWHPLVXVHGPDLQO\IRUFRQYHUWLQJ
WKH,'RFIRUPDWLQWRDQ(',VWDQGDUG DQGYLFH
YHUVD 
l 7KH(',VXEV\VWHPLVDQLQWHUIDFHWRH[WHUQDO
V\VWHPVDQGKDVLWVRZQUHVSRQVLELOLWLHV
l )RUPDWGHILQLWLRQVFDQEHGHILQHGLQWKH(',
VXEV\VWHPLQDIRUPZKLFKFDQEHUHDGE\RWKHU
V\VWHPV

 SAP AG 1999

 SAP AG BC620 14-8


([HUFLVH

8QLW8VLQJDQ(',6XEV\VWHP
7RSLF0RUH'RFXPHQWDWLRQ

At the conclusion of these exercises, you will be able to:


• Send a meta-IDoc

As a member of the EDI project team for your company, you require
information on IDoc type ORDERS01 for two reasons:
1. To prepare for a project discussion about “purchase order/order via
EDI”.
2. To inform your EDI subsystem provider of this data structure.

1-1 A machine-readable format should be generated for your subsystem provider. You
decide to transfer the information on IDoc type ORDERS01 with the aid of the
7UDQVSRUW,'RF. A partner profile with partner type /6and partner number
,'&/17 already exists and can be used in this exercise.
Note down the number of the IDoc generated.

1-2 Choose ,'RF→ 'LVSOD\,'RF or ,'RF→,'RFOLVWV from the initial node of the
IDoc interface to view the IDoc which you have created. Search for "your" IDoc
number.

 SAP AG BC620 14-9


$UFKLYLQJ

l $UFKLYLQJREMHFW,'2&

l 6WDWXVWUDQVIHUV

l $UFKLYLQJVWDWXV

 SAP AG 1999

 SAP AG BC620 15-1


$UFKLYLQJ8QLW2EMHFWLYHV

$WWKHFRQFOXVLRQRIWKLVXQLW\RXZLOOEHDEOHWR

l $UFKLYH,'RFV
l 'HVFULEHDVWDWXVWUDQVIHU

l &RQILJXUHWKHDUFKLYLQJVWDWXVLQWKHV\VWHP

 SAP AG 1999

 SAP AG BC620 15-2


2YHUYLHZ'LDJUDP 6HQGLQJ'DWD

R/3 System
Post document

$UFKLYH,'RF" Generate IDoc Partner


Partner Profiles
Profiles

Check partner, find port


Port
Port Definition
Definition

Documentation
Documentation
Transfer data, Tools
Tools
EDI
EDI Subsystem?
Subsystem? process further

 SAP AG 1999

n SmartMart must configure the IDoc interface for outbound processing:


n When communication with QuickDeliver has been tested successfully, SmartMart wishes to
determine which statuses are suitable for archiving and can then be deleted from the system.

 SAP AG BC620 15-3


$UFKLYLQJ%XVLQHVV6FHQDULR

l :KHQWKHEXVLQHVVSURFHVVKDVEHHQFRPSOHWHGWKH
SURFHVVHG,'RFVVKRXOGEHGHOHWHGIURPWKH
GDWDEDVH
l +RZHYHU\RXPXVWDUFKLYHWKHUHOHYDQW,'RFVEHIRUH
WKH\DUHGHOHWHG7KH,'RFVPXVWWKHUHIRUHEH
DVVLJQHGDQDUFKLYLQJVWDWXV:KHQFRQILJXULQJWKH
,'RF,QWHUIDFH\RXFDQGHWHUPLQHZKLFKVWDWXVHVFDQ
EHDUFKLYHG

 SAP AG 1999

 SAP AG BC620 15-4


$UFKLYLQJ2EMHFW,'2&

,'RF,QWHUIDFH

Archiving
programs

Possible
Storage

)LOH6\VWHP

 SAP AG 1999

n IDocs which can be archived are copied from the R/3 database to one or more archive files in a file
system (at operating system level) via the archiving programs in the IDoc Interface. Settings in ADK
Customizing (Archive Development Kit, enhanced function builder application) determine whether
the IDocs are exported to an external storage medium (optical disk, for example).
n In a second, separate step, all IDocs which have been archived can be deleted from the R/3 database.
n The archiving programs in the IDoc Interface are called via the central archiving transaction
(SARA). This transaction provides you with the archiving object IDOC. As a result, you can see
which programs you have to call. A message and time period are entered as "variants" for the
programs (reports), and define when the IDocs are generated. The programs check whether the
current status can be archived.
n The deletion job FRPSOHWHVan archiving run. A complete archiving run therefore moves the IDocs to
an external storage medium and deletes the IDoc from the database.

 SAP AG BC620 15-5


6WDWXV7UDQVIHUVLQ2XWERXQG3URFHVVLQJ



   


 

 



 







 




 








6HOHFWHGVWDWXVHVFDQEH 

DUFKLYHG
LQWKHVWDQGDUGV\VWHP
 SAP AG 1999

n Statuses can only be assigned to an IDoc in defined combinations. This slide illustrates the permitted
combinations for outbound processing: The following mean:
01 IDoc generated
02 Error while sending data to port
03 Data transfer to port OK
04 Error in EDI subsystem control information
05 Error during conversion
06 Conversion OK
07 Syntax error in EDI message
08 Syntax check OK
09 Error in interchange handling
10 Interchange handling OK
11 Error while sending
12 Send OK
14 Interch. Acknowledgment positive (EDI-Subsystem)
15 Interch. Acknowledgment negative (EDI subsystem)
16 Funct. Acknowledgment positive (EDI subsystem)
17 Funct. Acknowledgment negative (EDI subsystem)
18 EDI subsystem triggered OK
20 Error while triggering
22 Send OK, still waiting for acknowledgment (EDI subsystem)
24 EDI subsystem control information OK (EDI subsystem)
25 Further processing despite syntax error
26 Syntax error in IDoc
29 Error in ALE services
30 IDoc is ready for dispatch (ALE services)
31 Error, no further processing (deletion flag)
35 IDoc retrieved from archive
37 IDoc added with error 1
39 IDoc in target system (ALE services)
40 Application document not created in target system
41 Application document created in target system
42 IDoc from test transaction

 SAP AG BC620 15-6


6WDWXV7UDQVIHUVLQ,QERXQG3URFHVVLQJ

 



 


 





    

   
  

6HOHFWHGVWDWXVHVFDQEHDUFKLYHGLQWKH6$3
VWDQGDUGV\VWHP
 SAP AG 1999

n The permitted status combinations for inbound processing are displayed above. 50 IDoc added

51 Application document not posted


52 Incomplete application document posted
53 Application document posted
54 Error during formal application check
56 Incorrect IDoc added
57 Test IDoc: Error during application check
60 Syntax error in IDoc
61 Further processing despite syntax error
62 IDoc sent to application
63 Error while sending IDoc to application
64 IDoc is ready to be sent to application
65 Error in ALE services
66 IDoc waiting for predecessor (serialization)
68 Error, no further processing (deletion flag)
69 IDoc edited
70 Original version of edited IDoc
71 IDoc retrieved from archive
73 IDoc archived
74 IDoc created from test transaction

 SAP AG BC620 15-7


6WDWXV0DLQWHQDQFH$UFKLYLQJ

! "#"
%$&('*),+!) .- ","/"

0'12$3),-54
6),'7$5*) .- "
0'12$3),-5498  :5$&' "

;<=<7$( 
> 38,) <?) @) .- "

AB'1&C) DE)/-54
+5&)/F28 $
$ G&&8#5H$3H

 SAP AG 1999

n From the initial node of the IDoc Interface, select &RQWURO -> 6WDWXVPDLQWHQDQFH (transaction WE47)
to change the attributes of an individual status. An example of an attribute is whether or not
archiving is permitted.
n This transaction can also be used to find out general information about a certain status.

 SAP AG BC620 15-8


$UFKLYLQJ6XPPDU\

l $OODUFKLYLQJSURJUDPVDUHDGGUHVVHGYLDWKHFHQWUDO
DUFKLYLQJWUDQVDFWLRQ6$5$7KHDUFKLYLQJREMHFWLV
,'2&
l ,'RFVFDQRQO\EHGHOHWHGLIWKH\KDYHEHHQDUFKLYHG
7KHDUFKLYLQJUXQPXVWEHFRPSOHWH
l ,'RFVFDQRQO\EHDUFKLYHGLIWKH\KDYHEHHQ
DVVLJQHGDVWDWXVZKLFKFDQEHDUFKLYHG7KH
VWDWXVHVVXLWDEOHIRUDUFKLYLQJFDQEHFRQILJXUHGLQ
WKH,'RFLQWHUIDFH

 SAP AG 1999

 SAP AG BC620 15-9


&RXUVH6XPPDU\

6$3$SSOLFDWLRQ

([WHUQDO6\VWHP ([WHUQDO6\VWHP

 SAP AG 1999

n The IDoc Interface allows the exchange of business data between SAP applications and external
systems. The formats used for transmitting data (IDoc types) are documented.
n IDocs are exchanged with external systems on a partner-specific and message-specific basis. IDoc
data flow is therefore defined via the partner profiles and the port definitions.
n In outbound processing, IDocs can be collected in a group or sent to the external system
immediately.
n In inbound processing, IDocs can be processed via workflow.
n Exception handling for incorrect IDocs always takes place via workflow.
n Monitoring programs and statistics programs are available for the IDoc data flow. Active monitoring
can be used to automatically notify the agent responsible.
n IDocs which have been processed completely can be archived.
n If the IDoc types in the standard system do not meet your requirements, you can add upwardly-
compatible extensions or define your own IDoc types. This is the subject of course BC621.

 SAP AG BC620 15-10


$SSHQGL[

l 7KLVVHFWLRQFRQWDLQVVXSSOHPHQWDU\PDWHULDO
WREHXVHGIRUUHIHUHQFH
l 7KLVPDWHULDOLVQRWSDUWRIWKHVWDQGDUGFRXUVH
l 7KHUHIRUHWKHLQVWUXFWRUPLJKWQRWFRYHUWKLV
GXULQJWKHFRXUVHSUHVHQWDWLRQ

 SAP AG 1999

 SAP AG BC620 16-1


Appendix

Glossary

Access sequence Sequence used by Message Control to access condition records when
searching for messages.
Access An access identifies the document fields used by the system
when searching for a condition record.
Basic type IDoc type supplied by SAP. Basic types can be modified by
customers to create a new, upward-compatible IDoc type.
Condition component Part of the hierarchy which is examined when searching for a message.
Example: the message type which is at the top of the hierarchy: when a (new)
purchase order is posted, only the messages under the node for message type
NEW are searched.
Condition record Data record in which the key fields represent the condition under
which the message is "found". The remaining fields describe the
message itself. Therefore, if one of the data records transferred
from the application matches these key fields, the message is
found and can be processed (e.g. exported as a print form or as
an electronic message.
Control record The part of an IDoc which contains the data for identifying the
sender and recipient, as well as the structure of the IDoc itself.
Each IDoc always has one control record.
Data record The part of an IDoc which contains the application data. An
IDoc usually contains more than one data record.
EDI = Electronic Data Interchange (e.g. documents) between business
partners, sometimes in separate countries, who may use different
hardware, software and communication services. The data is
formatted according to specific standards.
EDI message Standard format for a business process (for example, a purchase order) to be
handled by EDI. Various EDI standards (EDIFACT or ANSI X12) can define
different EDI messages for the same business process.
EDI standard General format for data to be transferred electronically.
An EDI standard generally comprises:
EDI syntax
Data element service
Message type service
The SAP standard ’IDoc’ is not yet an EDI standard, but can be compared to
other EDI standards.
EDI subsystem System which converts the SAP standard IDoc into an EDI standard (e.g.
EDIFACT, ANSI X12) and vice versa. In addition to this task (which is
carried out by the EDI subsystem converter), there are also administration
activities, e.g. archiving the transferred messages, and technical tasks, e.g.
technical connection to the subsequent system and syntax checks for formats,
to be considered.
Field catalog Contains all fields which can be selected as key fields for
condition tables in Message Control.
File interface = port type „File“
Hierarchy level Determines the position of a segment in a tree structure. A
segment carries business data in an IDoc. Dependencies in the
application data can be represented in this tree structure, i.e. the
various hierarchy levels.

 SAP AG BC620 16-2


IDoc Interface Definition of IDoc types and data interchange methods (port
definitions) between SAP Systems and partner systems.
IDoc type SAP format in which the data for business process is to be sent.
An IDoc is a real business process, formatted according to a
certain IDoc type.
Inbound processing Conversion and processing of data for a business process from
the time the data is received in IDoc format to the posting of the
corresponding document(s) in the SAP application.
Mapping Rules for assigning the data elements of an EDI message type to
the fields of an IDoc type.
Message Control Module designed to offer interfaces for further processing for
applications. This includes descriptions of the various data
configurations and the required actions. An example of an action
is printing a document at a certain time in German. The action is
triggered when the application transfers data which matches your
configuration.
Message determination A check to determine whether the application data matches the condition
records (specified in Customizing)". If this is the case, one or more messages
are "found" and can then be processed (e.g. sent electronically).
In message determination, a search is made for the condition records using a
predefined hierarchy.
Message status record = MC record. Log record for the MC table which describes the send status of
a message in Message Control.
Message Business process (for example, a purchase order), which is
transferred in IDoc-Format between an SAP System and an
external system.
Notification If an error occurs (for example, an IDoc with incorrect syntax), a
notification is sent to one or more users. The users responsible
are defined in the IDoc Interface or indirectly via the
organization model (PD-ORG). Notifications are sent to the
integrated inbox.
Optional segment Part of an IDoc type (standard format for data communication),
which can include additional, optional data about the business
process. The segment does not therefore have to appear in an
IDoc for a specific business process.
Outbound file Contains certain IDocs to be sent for port type „File“.
Outbound processing Conversion and processing of SAP document data from posting a
document to sending the data in IDoc format.
Partner profile Definition of the general conditions for electronic data
interchange with a business partner via the IDoc Interface: which
message is sent in which direction using which method?
If a partner profile does not exist, communication with a partner
via the IDoc Interface is not possible.
Partner Communication partner for the IDoc Interface. Definition from
SD: „An individual within or outside of your own organization
who is of commercial interest and who can be contacted in the
course of a business transaction.“
Port Description of the channel used by the SAP system for
communicating with the external system during electronic data
interchange. There are various technical methods for

 SAP AG BC620 16-3


implementing this type of communication (port types). The
selection of the port type depends on the technical configuration
of the external system. Example: most EDI subsystems read
IDocs in the form of sequential files, i.e. the port type ’File’ is
used.
Process code Another name for a defined processing type, e.g. a function
module or an SAP Business Workflow task. In contrast, a
defined IDoc type (standard format for data communication) is
usually assigned to a certain process code. If the processing type
for this IDoc type is to be changed, you should assign the
corresponding process code to the new processing type. Without
the process code, this IDoc type must be assigned to the new
processing type directly.
Record type An IDoc type consists of the following three record types:
- Control record
- Data record
- Status record
Required segment The part of an IDoc type which contains important application
data and must therefore exist in an IDoc for an actual business
process.
Schema A group of messages. A schema is searched for messages which
are to be processed for the specified data configuration (e.g. sent
electronically or printed).
Segment Structure which includes the application data for an IDoc from the data
records. As a result, the data can be assigned to the correct application fields.
Status Processing status of an IDoc (SAP standard format for electronic
data interchange), for example: "generated" or "ready for
sending".
An IDoc has usually had several statuses, which are stored in the
status records and reveal information about the IDoc history. The
current (processing) status is also stored in the control record for
the IDoc.
Status confirmation Report from an external system about the processing status of
business data received from the R/3 System in IDoc format. The status
confirmation is added to the IDoc in the R/3 System in the form of status
records.
Status file File which contains the status records sent to the IDoc Interface
by the EDI subsystem for outbound messages.
Status group The status group contains several statuses ("milestones" in the
process chain), so that the monitoring programs only have to
consider these groups and not each individual status. Examples:
Group 3 = outbound: IDoc in the external system
Group B = inbound: IDoc sent to application
Status record One of the three record types in an IDoc (SAP standard format
for electronic exchange of application data).
Each status record contains a status which corresponds to one
step in IDoc processing. This means that the number of status
records increases as the processing continues.
Translator Converts internal data formats (IDocs) into EDI messages and
vice versa. The translator is a component of the EDI subsystem.

 SAP AG BC620 16-4


Transmission file A data packet which contains the messages to be exchanged
electronically. The messages are EDI messages, i.e. they are
formatted according to an EDI standard (e.g. EDIFACT).
The conversion of the SAP standard IDoc into the EDI standard
is carried out by an external system (EDI-subsystem).

 SAP AG BC620 16-5


Important Menu Paths

Archiving
Tools → Administration
Administration → Data archiving
Display IDoc
IDoc initial screen:
IDoc → Display IDoc
,'RF$GPLQLVWUDWLRQ
IDoc initial screen:
Control → IDoc Administration
IDoc initial screen
Tools → Business Communication
IDoc → IDoc Basis
IDoc statistics
IDoc initial screen:
IDoc → IDoc statistics
Maintaining an RFC destination
IDoc initial screen:
IDoc → RFC destination
0DLQWDLQLQJDUFKLYLQJVWDWXV
IDoc initial screen:
Control → Status maintenance
Partner profile
IDoc initial screen:
IDoc → Partner profile
Port definition
IDoc initial screen:
IDoc → Port definition
Processing tests
IDoc initial screen:
Test → <menu option according to the required function>

 SAP AG BC620 16-6


5HTXLUHG)LHOGVLQ,QERXQG3URFHVVLQJ ,'RF&RQWURO5HFRUG

The following tables contain the fields from the IDoc control record which:
• must always be entered by the external system in structure EDI_DC40
• must be entered in special cases by the external system in structure EDI_DC40
• may be entered by the external system in structure EDI_DC40 (optional fields). If the
values are entered, they are checked by the IDoc Interface.

Fields which must always be entered by the external system:

)LHOG 'HVFULSWLRQ
TABNAM Record type (structure): = „ EDIDC_40“ for IDocs to be processed in Release 4.0.
DIRECT Direction: = „ 2“ (inbound).
IDOCTYP Basic type.
MESTYP Message type, e.g. ORDERS. Assigned to one or more IDoc types in the IDoc
Interface.
SNDPOR Sender port. Must be defined as a port in the receiving R/3 System.
SNDPRN Partner number of the sender. Must correspond to a partner number from the
partner profiles.
SNDPRT Partner type of the sender. „ LS“ (logical system) in ALE scenarios. In non-ALE
scenarios, this value is usually „ KU“ (customer) or „ LI“ (vendor).
RCVPOR Receiver port: = „ SAP<SYSID>“ , where <SYSID> is the ID of the receiving R/3
System, e.g. C11.
RCVPRN Partner number of the recipient. In ALE scenarios, this value is
<SYSID>CLNT<CLNT>, where <CLNT> is the client of the receiving R/3
System and <SYSID> is defined in the field RCVPOR. In non-ALE scenarios,
this value is application-specific (e.g. the value can be the organization number).
RCVPRT Partner type of the recipient „ LS“ (logical system) in ALE scenarios. In non-ALE
scenarios, this value is application-specific (e.g. „ SD“ for the SD module).

)LHOGVZKLFKDUHHQWHUHGLQVSHFLDOFDVHV

)LHOG 'HVFULSWLRQ
CIMTYP Customer extension to a basic type. Must be present in the corresponding partner
profile.
MESFCT Message function for further message division. Must be present in the
corresponding partner profile.
MESCOD Message code for further message division. Must be present in the corresponding
partner profile.
SNDPFC Partner function for further partner division. Must be present in the corresponding
partner profile.
TEST Test flag.
EXPRSS Express flag: if this flag is set, the ALE services are called immediately in IDoc
inbound processing.
 SAP AG BC620 16-7
2SWLRQDOILHOGV
)LHOG 'HVFULSWLRQ
MANDT Client in the R/3 System. An incorrect entry causes an error.
DOCREL R/3 release version. An incorrect entry causes an error.
OUTMOD Outbound processing mode (e.g. send IDocs individually, start subsystem). Each
value is overwritten in inbound processing.
DOCNUM IDoc ID. As the inbound IDoc is generated first in the database, each value here is
overwritten by the internal IDoc ID.
CREDAT Date of IDoc generation. Handling as in DOCNUM.
CRETIM Time of IDoc generation. Handling as in DOCNUM.

 SAP AG BC620 16-8


7\SLFDOFRPELQDWLRQVRI0&ILHOGVDQGILHOGVIURPRXWERXQG
SDUWQHUSURILOHV

3URFHVVFRGH and 0HVVDJHW\SH are fields in the IDoc partner profiles, all other fields belong to
Message Control (MC):

Partner Application Message Change Message Process code


function type category
LF EA NEU REQOTE ME12
LF EF NEU ORDERS ME10
LF EF NEU X ORDCHG ME11
AG V1 AN00 QUOTES
AG V1 BA00 ORDRSP
WE V2 LAVA DESADV SD05
WE V3 AUS1 EXPINV
RE V3 RD00 INVOIC SD09 (invoice)

 SAP AG BC620 16-9


([DPSOH&RPPDQGILOH 6KHOOVFULSW 2XWERXQG

Note: in this example, a UNIX operating system is used.

#!/bin/sh
DIRWORK=/users/ediadm
cd $DIRWORK
FILE=’basename $1’
date >> $DIRWORK/ediadm.trace
echo ++ run external system with file $FILE >> $DIRWORK/ediadm.trace
LQVHUWFRPPDQGWRVWDUW(',VXEV\VWHPKHUH
echo ++ removed IDoc file $FILE from application server >> $DIRWORK/ediadm.trace
chmod 666 $DIRWORK/ediadm.trace

 SAP AG BC620 16-10


([DPSOH&RPPDQGILOH 6KHOOVFULSW ,QERXQG

Note: in this example, a UNIX operating system is used.

#!/bin/sh
DIREXEC=/users/ediadm/run
DIRWORK=/users/ediadm
cd $DIRWORK
date >> $DIRWORK/ediadm.trace
echo ++ start SAP system with file $1 >> $DIRWORK/ediadm.trace
$DIREXEC/startrfc -3 -t
-d <system ID> -u <user> -p <password> -c <client>
-h <router string> -s <system number>
-g <gateway machine> -x <gateway name>
-F EDI_DATA_INCOMING
-E PATHNAME=$DIRWORK/$1
-E PORT=<subsystem>
chmod 666 $DIRWORK/ediadm.trace

Note: the script for VWDWXVILOHV only differs from the script for inbound IDocs because the
function module EDI_STATUS_INCOMING is called.

 SAP AG BC620 16-11