Lesson: Enhancements in Inbound Processing

Lesson Overview

In order to enhance an ALE scenario that includes the transfer of additional fields, you have enhanced an IDoc type. This lesson discusses all the steps required for enhancing inbound processing. It is assumed that the application enhancement is based on a table append, and that the database change, including the append fields, is therefore included in the SAP standard. You want to enhance inbound processing so that the contents of the segment fields in the customer segment are copied to the corresponding fields in the application. The field types used mean that conversions are required that exceed the type conversion of the^MOVEstatement.

Lesson Objectives

After completing this lesson, you will be able to:

• List the steps required for implementing an enhancement in inbound processing

Business Example

The material master has been enhanced. In addition to the fields allocated by SAP, information on the cheapest competitor product is also entered and saved in the application documents. To achieve this, the database table^MARAhas been enhanced by the addition of a table append from the

APPENDstructure^YBIT350. This enhancement should also take effect in the ALE scenario for material master distribution. The customer fields should be transferred with the IDoc for the message type^MATMAS. For this purpose, an enhancement of the IDoc type^MATMAS03has been created, which contains an additional segment as a subsegment of^E1MARAM. You want to enhance inbound processing in this way, on the condition that the fields of this segment are filled. The fields of the segment are to be converted to internal format and saved in the append fields for the database table^MARA, together with the material master application document. If possible, you want to achieve this using an enhancement.

In the first step, you need to check whether an enhancement that you can use to make your adjustment is available in the inbound function module of the application . This enhancement must be processed at a point when the IDoc data is known, but the application document has not yet been written. You therefore only need to consider enhancements in the inbound function module of the application. Application documents are often realized using update function modules, in which enhancements can also be possible. These enhancements cannot be used, because the IDoc data is not recognized in the update function module.

Figure 57: ALE Services

Hint: To avoid explaining too many aspects at once, this unit is restricted to the inbound processing of individual IDocs. To optimize performance, you can also use package processing. This means that multiple IDocs are processed in one LUW. For more information on package processing, see the Package Processing lesson.

Figure 58: Enhancement for Append Fields in Inbound Processing In this scenario, an application table has been enhanced using a table append. In the inbound program, a structure must exist for the application data in internal format. This structure normally has the same row type as the application table in which the application document is saved. In this case, the fields of the append structure are automatically available in the structure. Before you can use an enhancement for inbound processing, the following requirements must be met:

• The enhancement must be processed before the application document is written.

• The interface must contain a structure as an^IMPORTparameter and as an^EXPORT or^CHANGINGparameter, with the same row type as the application table. Alternatively, it can contain a^TABLESparameter, with the row type of the application table.

• The data records of the IDoc, or at least the customer segment, must be transferred to an^IMPORTparameter of the enhancement.

You then need to program the conversions, consistency checks, and field mapping from the fields of your customer segment into the fields of the

APPENDstructure. The normal conversion rules apply here.

Figure 59: Example: Enhancements in Inbound Processing For transparency and consistency in the diagrams, the variables have descriptive names: A structure with the line type EDIDD is called edidd_s, and a structure that has the same row type as the database table mara, is called mara. There is no naming convention for variables in inbound programs. You therefore need to use the typing to determine the name of the corresponding variables. For the inbound program IDOC_INPUT_MATMAS01 for the message type MATMAS, the header line of the internal table IDOC_DATA is used instead of edidd_s. The function module exit call in this program is:

CALL CUSTOMER-FUNCTION '002'

EXPORTING MESSAGE_TYPE = IDOC_CONTRL-MESTYP F_CUST_SEGMENT = USER_SEGMENTS TABLES RES_FIELDS = T_RES_FIELDS CHANGING F_MARA_UEB = I_MARA_UEB EXCEPTIONS APPLICATION_ERROR = 1

OTHERS = 2.

Figure 60: Example: Enhancements in Inbound Processing: Details In the enhancement, the field sdata can be copied, with the data of the customer segment, into a structure that is typed with the row type of the customer segment type. The fields must then be converted to internal format, and copied to the target fields of the append structure.

Exercise 6: Enhancing Inbound Processing

Exercise Objectives

After completing this exercise, you will be able to:

• Enhance inbound processing for the message type ORDLGT so that the fields of the additional customer segment are also saved in the application document.

Business Example

A scenario for ordering materials has been deliberately simplified for this exercise. Some of the functions from the standard scenario have been omitted. You want to create the order for another SAP system. For the outbound order, the message typeÔRDLGT is available with an outbound function module for message control. For the incoming order, an inbound function module for the message typeÔRDLGTis available. In this scenario, the two fields of the purchase order header, ÎNCO1andÎNCO2, are not transferred. You want to enhance the scenario by the addition of these fields. You have already enhanced the IDoc type, and you now want to enhance inbound processing.

Task

Implement the enhancement for inbound processing.

1. A customer exit is available in the inbound function module

BIT350_INPUT_##. The interface contains a structure with the two fields

INCO1and^INCO2. If they are not initial, the inbound program writes both fields in the inbound application document. Check the interface of the enhancement. Which steps do you need to implement to ensure that the customer segment fields are written from the IDoc into the application document? Which conversions are required?

2. Implement the enhancement.

Solution 6: Enhancing Inbound Processing

Task

Implement the enhancement for inbound processing.

1. A customer exit is available in the inbound function module

BIT350_INPUT_##. The interface contains a structure with the two fields

a) The export interface parameter^pe_vbak621contains the two fields

INCO1and^INCO2, which are typed with the data elements, in the same way as they are entered for the segment fields of the segment^Z1INCO##. The whole data part of the IDoc is transferred to the enhancement as the^TABLESparameterpt_idoc_data_records. b) The row with the customer segment must be read from the

internal tablept_idoc_data_records. Copy the field^sdatainto a structure with the segment type^Z1INCO##. Then copy the fields of this structure into the same fields of the export parameter

pe_vbak621.

c) Because both fields are only text fields, no conversion is necessary.

2. Implement the enhancement.

a) DATA edidd_s TYPE edidd.

DATA z1inco##_s TYPE z1inco##.

READ TABLE pt_idoc_data_records INTO edidd_s WITH KEY segnam = 'Z1INCO##'.

IF sy-subrc = 0.

MOVE edidd_s-sdata TO z1inco##_s.

MOVE z1inco##_s-inco1 TO pe_vbak621-inco1.

MOVE z1inco##_s-inco2 TO pe_vbak621-inco2.

ENDIF.

Lesson Summary

You should now be able to:

• List the steps required for implementing an enhancement in inbound processing

In document BIT350 (Page 114-122)