IDOC Useful Notes

1, In main business scenario of using IDOC: Company A(R/3)–(IDOC)–EDI Subsystem–(Message)–EDI subsystem–(IDOC)–Company B(R/3)
In this scenario: Both companies have R/3 system and must configure their IDoc interface accordingly. The IDoc are to be translated into another EDI standard form.

2, IDoc stand for intermediate document. It is intermediate in two respects:
Message-oriented–Data is also stored in application, only in other formats(the application documents).
Asynchronous–Data can be stored in IDocs before an application document is created.

3, Examples of systems or applications which use IDocs:
ALE: Application link enabling.
EDI: Electronic data interchange.
Business connector: Sending business documents using the Internet.

4, Outbound processing of IDoc includes:
Posting the application document
Generating the corresponding outbound IDoc
Finding the partner and port
Transfer of the IDoc to the external system via the port

5, IDoc settings including:
Partner profiles
Port definition
Documentation tools
EDI subsystem?
Archive IDoc?

6, Detail Outbound processing of IDoc setting:(sending)
Company A defines the system which will receive IDocs and technical parameters via the port definiton.
Company A defines company B as a partner for message type ORDERS in the partner profiles and enters the port which has already been defined.
Outbound IDocs created in the R/3 system should be archived by company A and then deleted.
The documentation tools inform the EDI subsystem which IDOC type are to be recognized.

7, Inbound processing includes:
Receiving IDoc data from an external system via an inboud port
Creating the inbound IDoc
Find the correct processing type via the partner profils.
Creating the application documentat

8, Detail Inbound processing of IDoc setting:(receiving)
Company B 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 port definition beform IDocs can be accepted by the R/3 system.
In the partner profiles, Company B enters company A as a partner for inbound processing and the message type ORDERS. In addition, agents reponsible for error processing are entered here, specifically for partners and messages.
Like company A, comapny B wishes to archive and subsequently delete inbound IDocs which have been generated.

9, IDoc record types include: 
Control record.
Data records which store the application data in segment and describe the hierachy of these segments.
Status records which determine the defined processing steps of the IDoc. As a result, the number of status records for an IDoc increases as processsing contines .
10, IDocs which are transmitted between two different system are always smaller then the IDocs in the R/3 system because they do not contain status records.
11, Control record:(IDoc ID, Partner, IDoc type and logical message, External structure)
Data records: (Control part, Applicaton data)
Status records:(Idoc ID, status information)
12, During direct outboud processing, the ALE services are always called, including:
Filter the IDoc: Data not required for the communication is removed from the IDocs.
Change the(segment) version: if the recipient only recognizes an earlier version of the IDoc type, the version can be changed here. This menas that less data is transported, as later versions of Idoc type can only contain more data than former vea less.
Determind 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. NOTE: IDOCS cannot be duplicated during inbound processing.
13, Inboud processing using workflow:
The external system sends Idocs to the R/3 system. The R/3 system is address via the port name SAP for example SAPC11 for an R/3 system called C11.
If the Idoc Interface recognizes the external system, the inbound Idocs are accepted and checked that is, a syntxt check is performed and the system checks whether the sender is entered as a partner.
The Idoc is sent to the application via SAP business workflow according to the settings in the partner profile.
If required, the Idoc can be processed by the ALE services before being saved in the database as an inbound Idoc.
14, Idocs can only be deleted from the system when they have been archived. The phrase ‘intermediate document’ dose not refer to the ‘life expectancy’ of an IDoc.

15, Idoc types are only defined by their segments. Idocs, however, can be distinguished by the Idoc type and their contents.

16, In outbound processing, Idocs are always generated by the Idoc Interface or by the application. however, in inbound processing, Idocs are always generated by the Idoc interface.

17, Documentation tools include:
Record types, Idoc types, segments.
Output formats.

18, 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 being 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.

19, As a result, when running the documentation tools, you have to enter tow parameters:
The version of the external record types(as enterd in the port definition)
The releas of the external segment(as entered in the partner profiles)

20, We start the documentation tools from the initial node of the Idoc interface from the documentation menu. The parser has its own menu entry, both for record types and Idoc types.

21, The output formats can be read by external systems, so that no-R/3 systems can quickly recognize the Idoc structure.

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

23, 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 interanl table TXCOM.

24, The Idoc partner profile is divided into four areas:
General partner profile.
Outbound partner profile(general).
Additional parameters for outbound processing under message control(MC).
Inbound partner profile.

25, About Partner profile of outbound processing: 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.

26, About partner profile of Inboud processing: Summary, the Idoc type determines the inbound processing for the Idoc. There are other dependent fields such as recipients of notifications.

27, 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. NOTE: process codes are client-specific.
28, Partner profiles specify which messages are sent to which users, using which method and how they are processed. partner must be entered in the partner profile before Idocs can be sent successfully.

29, The port is part of the outbound partner profile.Technical communication parameters are entered in the port definition. Inboud ports do not require such parameters–their technical parameters are defined by the external sending system.

30, Process codes are also part of the partner profiles. They are used for processing data.

31, Outbound processing using message control:
Message control generates message from application documents. The possible messages are defined as condition records in customizing.
From the possibile message, MC search for those which match the current application data. This message determination can result in several message being found, or possibly none. 
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 before the purchase order is posted.
In any case, the message is generated and processed: for example, if the order is to be printed, the processing progamm 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.
The new message is represented by a new entry in the MC table.Part of this record is the processing staus, which can have the following values: 0=not yet processed, 1=successfully processed, 2=processed with error.

32, About transfer Idoc.
Idocs are transferred individually from program RSNASTED when using output modes ‘1’ and ‘2’ (field outmod in the control record).
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(bathc mode) and sent as a group.

33,Message defined in customizing are examined in a certain sequence to determine whether or not they apply to the current application data.This sequence is defined by the condition components and their hierarchy.

34, Idoc-specific message processing takes place via program RSNASTED.

35, About test Idoc information:
Caution: eldin the caser 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.
Status records must refer to outbound Idocs in the system, otherwise an error occurs in status processing.

36, About some useful Tcode of Idoc:
Data exchange with the file system: WE14(outbound), WE16(inbound), WE17(status confirmation)
Processing MC record: WE15
Data transfer from the Idoc interface to additional inbound processing: WE19
Data transfer to any port: WE14 
Initial node of the Idoc interface: WE12
37, Special test programs require MC records, files or existing Idocs from the database. If necessary, automatic outbound mode from the partner profile and the dispatch time in the MC condition record.
38, The test tool allows general tests for inbound processing, outbound processing and status confirmation via systat01.

39, A process chain: summary.
Special EDI parameters must be entered in the application master data. These include partner informatiion and transmission medium ‘6’ in the condition record for outbond processing using message contro(MC).
Outbound processing using message control is always applied for purchase orders from the mm module.

40, Statistics and monitoring Idoc.
The Idoc data flow can be monitored via four passive programs and one active program in the Idoc interface.(Active monitoring program—RSEIDOCM)
Active monitoring is a function which can be individually configured for error handling or general exception handling.
The level of detail in the passive monitoring programs goes as far as displaying the individual idocs.The least-detailed monitoring tool is the status group display under Idoc statistics.

41, Idoc inbound processing can include a workflow which is triggered by a process code. This workflow is defined by the user.
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.

42, Workflow auto-customizing(transaction SWU3)include 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.

43, Workflow and Idocs: summary
Normal Idoc processing via workflow is only possible for inbound processing of certain Idoc types.
Exception handling always takes place via workflow. It is called in ountbound processing in the same way as in inbound processing.
Errors can be casued by incorrect application data or incorrect Idoc syntax. In these cases, error handling is different.
Through the organizational structure, workflow allows users in a defined task area to be notified, not individual users whose responsibilities may change.
Workflow allows incorrect Idocs to be forwarded as work items ‘in a controlled manner’ from an intergrated inbox and even to be repaired in some cases.

44, The most important task of the EDI subsystem is converting to or from the required EDI standard; this task is carried out by the translator as a subfunction of the EDI subsystem. The individual criteria, for example selecting and assigning fields, are mapping components(usually customer-specific).

45, As a result, an EDI subsystem must send certain fields with their values for Idoc inbound processing:
Partner, message(their 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.
Directin=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.
46, Using an EDI Subsystem: summary
The EDI subsystem is used mainly for converting the Idoc format into an EDI standard(and vice versa).
The EDI subsystem is an interface to external systems and has its own responsibilities.
Format definitions can be defined in the EDI subsystem in a form which can be read by other system.
47, Archiving: summary
All archiving programs are addressed via the central archiving transaction SARA. The archiving object is Idoc.
Idocs can only be deleted if they have been archived. The archiving run must be complete.
Idocs can only be archived if they have been assigned a status which can be archived. The statuses suitable for archiving can be configured in the Idoc interface.

48, Summary of IDOC.
*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.
*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 port definitions.
*In outbound processing, Idocs can be collected in a group or sent to the external system immediately.
*In Inbound processing, Idocs can be processed via workflow.
*Exception handling for incorrect Idocs always takes places via workflow.
*Monitoring programs and statistics programs are available for the Idoc data flow.Active monitoring can be used to automatically notify the agent responsible.
*Idocs which have been processed completely can be archived.
*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.
Studying IDOC More

1, The message can be sent from the application to the IDoc interface along two paths:
*The indirect path using messge control: a series of conditions are checked to find the message.
*The direct path from the application to the receiving system along different paths. Port selection also depends on the receiving system and the hardware used for the installation.

2, In all exception situations where the sender is defined in the partner profile, the permitted agents are read from the profiles. Agents can be organization units(for example , department,job) and not just sap user.
3, Communicate R/3 with external system with Idoc. There will use two sap standard programs rfcexec and startrfc, they are applied to outbound and inbound respectively.