EDI Inbound Process via Workflow

The inbound process via workflow is similar to the inbound process via function module, 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. A typical example is the sales order change transaction coming in via EDI. Someone might need to review any change from a customer before the change can be accepted; if you have already begun production, you might not be able to accept a change in quantity or delivery date. This process gives you the option of reviewing the changes and taking appropriate action.

In the standard system, the inbound processes use function modules for posting the document. Although no process uses workflow by default, you can customize the interface to start workflow.

The inbound process via workflow differs from processing via function module mainly in the processing that occurs in the application layer. The processing that occurs in the EDI subsystem layer and the ALE/EDI layer is the same in the two approaches as shown in the figure.

Processing in the Application Layer

The posting module in this case is a workflow task. The workflow task can be designed to accommodate any customized processing, such as reviewing an incoming order change transaction followed by posting, or posting an incoming order change document followed by review.

If a complex business process is associated with an incoming document, you can use a multi−step workflow to map that process.

Workflow is a useful method for processing inbound EDI transactions, but it adds additional load to the system, especially when you have high−volume EDI transactions. It also blocks the process unless someone processes the work item, which can cause unnecessary delays.

Exception Handling in the Inbound Process

The inbound process described in this chapter shows the success path from the IDoc's creation through the final creation of the application document, but the system can experience problems at any stage during the process. Compared to the outbound process, the inbound process has more opportunity for error because data originates outside the SAP system. SAP validates the data using the same business rules as if the document were entered online.

The workflow system uses the Post Processing: Permitted Agent fields in the partner profile to send the error notification. For example, an error might occur before an IDoc is created or because the partner profile cannot be read; in any case, the EDI administrator is notified.(47)

Related Posts

EDI inbound process overview
EDI outbound process part one and two
Outbound process with message control

What is EDI an introduction
Business process with EDI