Change enablement of custom fields in Material Documents in MIGO - 1

[former_member185414]

Dear Community,

Through this blog, I would like to detail the implementation steps needed to enable change handling  ( updation ) of custom fields for material documents via the transaction code MIGO. This has been implemented in SAP S/4 HANA 1709 system. I would like to thank @Gaurav Punj for his support and co-authoring.

Also, this will be a long blog so I will thank you in advance for reading.

Background -

Material Documents are considered very critical data because of its inherent deep linking within the entire business process of any organization. Be it manufacturing or delivering or procurement, everywhere whenever a goods movement occurs a material document gets posted in the SAP system. They also gain importance due to the financial impact associated with such movements.

Generally, standard SAP has provided change handling for very few fields namely – Material slip and Document Header text at header level and Goods Recipient, Unloading point and Text at the material document item level.

Though ‘MB_MIGO_BADI’ as the screen enhancement mechanism has been provided but this BADI does not cater to change scenarios. It is only triggered in case of create scenarios.

This reuse will demonstrate how change handling can be achieved for custom fields added at the material document item level.

As below three major scenarios are possible, and they have been catered. Also, custom business validations are also implemented which will be discussed.

1. Changes in only standard fields


2. Changes in only custom fields


3. Changes in both standard and custom fields

We can mix these scenarios like changes to standard header and item fields along with changes to custom item fields, changes to only custom item fields and standard header fields, changes to only some items in a document which has multiple items, etc.

The building blocks for this reuse will be

1. Enhancement of view V_MSEG_UPDATE with additional fields


2. Explicit and Implicit enhancements in include LMIGOKD1.


3. Screen programming to enable validations.

 

2. Steps to enable change handling of material documents via MIGO transaction code. 

Before detailing the steps, we would like to demonstrate the program flow via the below sequence diagram –



Following steps are to be followed –

A. Enhancement of view V_MSEG_UPDATE

1. Go to T-code SE11 and enter view V_MSEG_UPDATE


2. Then choose More-> Go to -> Append View as below –

 



B. Identify the hook for enhancement

1. The Function Group for transaction code MIGO is SAPLMIGO. This has an include LMIGOKE2 for kernel which in turn has include LMIGOKD1 for document operations. This is the include which contains the necessary enhancement points

C. Handle business validations via screen programming

1. As shown in above sequence diagram, we write Input modules in custom screen to validate the data after user enters the same. These PAI modules are part of screen program of the custom sub-screen.

 

2. Do note that same business validations have to be replicated during saving of changed values as during save all validations are re run to verify the data sanctity.

D. Implement the Implicit enhancement at the beginning of method

 

1. In the document operations include LMIGOKD1, we implement implicit enhancement in method – DOCUMENT_CHANGE. Here we check if any of custom fields values have changed between what is stored in database and what is currently on screen. If a change is detected, we issue call to MB_CHANGE_DOCUMENT function module with the changed data.

It exclusively takes care of changes in custom fields added as part of material document item enhancement.

Also, we keep a track of whether data is changed or not because we use same to issue commit work at the end.

This is shown below -





 





E. Implement the Explicit enhancement

1. Standard code line has given us enhancement section - LMIGOKD1_08 ; spot ES_SAPLMIGO which it uses to tackle handling of property changes at the material document item level. We used same to patch the changes of custom fields along with standard fields.

 

F. Implement the Implicit enhancement at the end of method

1. In same method DOCUMENT_CHANGE, if standard code base has issued commit work statement then changes in custom fields will also be saved because update Function Modules will be triggered on encountering commit work statement. In case standard fields are not changed and only custom fields are changed, we need to issue commit work and data change success message.

 



Observations: -

1. Multiple updates to MSEG does not cause any issue because sequence is controlled by standard in the order of registration.

PS: I will publish another blog on how to test this functionality.

Any feedback/questions are most welcome.