IDoc Inbound Process

http://erpwhiz.com/ALE_IDOC/Idoc%20inbound%20process.html

IDoc Inbound Process

The inbound process uses components such as the IDoc type, the partner profile, the port definition, posting programs, and service programs. The inbound process components are specified in the partner profile and configuration tables.

Posting Programs

Posting programs are implemented in the system as function modules. A posting program exists for each message type. The programs are named with the following naming convention:

IDOC_INPUT_< message type >

These function modules have a standard interface for their input and output parameters. The function modules can handle one IDoc or multiple IDocs of the same type simultaneously.

A process code is assigned to each posting program. Because process codes are flexible, you can assign any processing type to a process code. A process code can point to a function module or a workflow. In the standard system, process codes always use the Processing by Function module processing type with the Processing with ALE service option.

For example, the posting program for message type ORDERS is IDOC_INPUT_ORDERS. A four-character process code, ORDE, has been assigned to this function module. You can see a list of inbound process codes and their corresponding function modules by executing the following transaction.

Transaction: WE42

Menu Path: From the Area menu of EDI (WEDI), choose Control, Inbound process code.

You can develop your own custom function modules.

The Partner Profile

A partner profile specifies the various components used in an inbound process (partner number, message type, or process code), the mode in which it communicates with the posting program (batch or immediate), and the person to be notified in case of errors.

A partner profile is created for each business partner, and a record exists for each inbound message received from a business partner. For example, if two inbound messages (sales order and sales order change) are received from customer number CUST001, a partner profile must exist for CUST001, and two inbound records (one for each message type) must exist in the partner profile.

Service Programs and Configuration Tables

The inbound process is asynchronous and can be regarded as a sequence of several processes that work together. To link the components and provide customizing options for an inbound process, SAP provides service programs and configuration tables. The process flow for the inbound process describes the role played by each service program.

The inbound process also has two distinct paths for posting the application documents from the IDocs.

• Function module
• Workflow

Function Module

The IDoc from external system is stored in a text file at the operating system (OS) layer. The IDoc file can be passed to the ALE/EDI interface layer immediately via the file port using the startrfc program, or can be processed at a later time through execution of program RSEINB00.

The startrfc program is a standard SAP program at the OS level to call any RFC-enabled function module in SAP. To trigger the inbound process, the startrfc program calls the function module EDI_DATA_INCOMING, which acts as the entry point for inbound processes. The name of the IDoc file is passed as an input parameter to this function module.

The EDI_DATA_INCOMING function module reads the IDoc file into an internal table. The IDoc is first checked for integrity by doing a syntax check. Then the standard ALE services such as version change, filtering, and conversion are applied, if necessary. The ALE/EDI layer creates an application IDoc in the database. At this point a tangible IDoc, which can be monitored via one of the monitoring transactions, is created in the system. The IDoc gets a status code of 50 (IDoc added). If the IDoc passed the syntax check process earlier, it gets a status code of 64 (IDoc ready to be passed to application), signifying that the process can continue.

Next, the processing flag and process code are read from the partner profile table. If the value of the Processing field is set to Process Immediately, the IDoc is passed to the posting program using the RBDAPP01 program. If the field is set to Background Processing, the IDocs are buffered in the system until the RBDAPP01 program is executed explicitly.

The posting function module either calls a standard SAP transaction, using the call transaction command for posting the document, or invokes a direct input function module.

The results of the execution are passed back via the function module's output parameters. If posting is successful, an application document is created. The IDoc gets a status code of 53 (Application document posted). If errors occur, the IDoc gets a status code of 51 (Application document not posted).

Workflow

The inbound process via workflow is similar to the inbound process via function module, as described earlier, except for the difference in the processing that occurs in the application layer. The IDoc, instead of being processed by a posting program, is processed by a single-step task or a multi-step workflow. Pointing the process code to processing by task or process, instead of processing by function module, configures this option. Workflow allows human intervention in the process, which is sometimes necessary.

As an example, invoices greater than $5,000 coming into the system might need an approval for payment. You might want to route the invoices to more than one person. This step can easily be accomplished via workflow. Basically, workflow is a development environment, and you can build any functionality you need.