EDI Message Control Architecture part two

This post is in continuation with EDI Message control architecture part one and going through that post will give comfort in understanding the present post.

Communication Structure

The communication structure passes application information to the Message control. The communication structure acts as a container. Each application has its own application structure.

The communication structure for output determination uses the naming convention KOMxByy, where x can be K or P. K means the header structure and P means the line−item structure. yy is the two−character application ID. Hence, KOMKBV1 is the communication structure for sales order header information.

Procedure

A procedure defines a set of possible outputs for an application. A procedure is assigned a six−character name. We can define several procedures for an application, but only one can be configured as active.

A list of procedures for an application can be seen via the IMG or, in transaction NACE, by selecting an application and clicking the Procedures button. To see the attributes of a procedure, select a procedure and double−click the Control folder in the Dialog Structure frame. A procedure has three main attributes that affect the proposal of an output type .

1. A list of output types ·
2. A Requirement field ·
3. A manual flag

We can view fields in a communication structure by using transaction SE11. By using append structures, even we can extend communication structures. If a communication structure is extended, the extended fields have to be populated in a user exit to pass those values to the Message control.

User exits are available for populating the extended fields in a communication structure. The list of output types represents a set of outputs that are possible for an application. It does not mean that they will be proposed; it simply means that the system evaluates these outputs for proposal. An output type that does not exist in a procedure cannot be proposed. Examples of certain output types applicable for a sales order are

1. A sales order response
2. An internal message
3. Hard copy output

For each output type, we can define preconditions. (For example, a sales order response should not be sent out unless the sales order is complete.) These preconditions are captured in the requirements. A requirement is implemented as an ABAP/4 program and assigned a number. You can view a list of requirements defined in the system by using transaction VOFM. A requirement is optional, but if you want, you can specify one for each output used in a procedure.

We can mark an output type as manual in a procedure, meaning that the system does not attempt to propose that output automatically. This output can only be selected manually by a user. This type of output can be important when you do not want an automatic proposal or when the business rules are based on human intelligence and cannot be encapsulated in an ABAP/4 routine.

We can create new procedures, output types, and requirements to suit your needs.

Related Posts

EDI Message control configuration
Maintaining partner profiles in EDI
EDI in bound parameters over view
EDI outbound parameters view part one and Two
EDI partner profile configuration