Enterprise Resource Planning Blog Posts by Members
cancel
Showing results for 
Search instead for 
Did you mean: 
MerveKaya
Explorer
2,543

 

Abstract

Change request attachments in SAP MDG play a crucial role in supporting various business needs. Attachments may range from technical documents to reports. In this scenario, the goal is to implement a derivation process that leverages the information from an uploaded attachment document. Its content provides values for the fields in MDG to be pre-filled upfront instead of manually maintaining them.

 

Introduction

In this blog post, we will provide a step-by-step guide to implementing a derivation process triggered by an attached document within an MDG-M change request. By enabling users to upload an Excel sheet containing the required values for specific fields, we introduce a more user-friendly and efficient way to handle data derivations. This approach is especially beneficial for large datasets, where manual input would be time-consuming and susceptible to errors. With this solution, the attachment serves as a basis for automatically populating fields, streamlining the process and reducing the risk of inaccuracies.

 

Scenario and Feasible Option

The main goal of this implementation is to derive data from an uploaded Excel sheet, which will be used to automatically populate relevant fields in the change request. The Excel sheet should include the following columns: entity type, attribute, and value. (An example of a completed Excel sheet will be provided in the Testing section of this blog.)

As a result of this implementation, it is also necessary to address the challenge of identifying the correct attachment document for the derivation process. To achieve this, we will extend the attachment UI by adding a new field called ‘Attachment Type.’ It will act as a filter for identifying the corresponding document during the derivation process.

Based on this approach, the process can be divided into three main steps:

  1. Extend the Attachment UI: A new custom field labeled "Attachment Type" will be added to both the "Attachment List" and the "Add File" UIBB. A new button, "Derive with Attachment" will also be created to trigger the derivation process.

  2. Identify Corresponding Document: Logic will be developed to identify the correct attachment by filtering based on the "Attachment Type" field. Enhancements will be made to the CL_USMD_CR_GIL_ATTACHMENT class to create post-exit methods, ensuring only the appropriate document is selected.

  3. Perform the Derivation: Derivations will be performed in the ‘GET_DATA’ method of the Attachment List UIBB's feeder class, and relevant messages will be handled in the ‘PROCESS_EVENT’ method.

 

1. Extend the Attachment UI

This part of the solution is adapted from the approach outlined in ‘MDG Change Request Attachments - Hide/Disable attachments in MDG CR based on User Role’. You can check this blog for further information about ‘Attachment Type’ extension.

An MDG change request may contain multiple attachments, making it necessary to differentiate between them. To address this, we will introduce a custom attribute called 'Attachment Type.' This attribute will then be added to the 'Attachment List' and 'Add File' UIBB. Beside these improvements, we will add a custom button ‘Derive with Attachment’. This button will trigger the main derivation code.

a- Create Dictionary Objects

MerveKaya_0-1726211249984.png
Figure 1- Create domain

MerveKaya_1-1726211249993.png
Figure 2- Add value for dropdown list box

MerveKaya_2-1726211249997.png
Figure 3- Create data element

b- Append to Attribute Structure (BSS_CRIL_ATTACHMENT_ATTRIBUTES)

To add a new field to the Attachments section, we need to extend the structure for GenIL MDG CR Attachments. This can be done by navigating to the relevant structure and creating an append structure that includes the new data element.

MerveKaya_3-1726211402509.png
Figure 4- Create append structure

MerveKaya_0-1726474772489.png
Figure 5- Final view of BSS_CRIL_ATTACHMENT_ATTRIBUTES

c- Add Field to USMD_CR_ATT_FILE (‘Add File’ Form UIBB)

First, we will customize the Form UIBB of the ‘Add File’ popup. Navigate to the configuration of USMD_CR_ATT_FILE and add the newly created 'Attachment Type' field to the form.

MerveKaya_5-1726211402534.png
Figure 6- Add ‘Attachment Type’ field to Form UIBB

d- Add Field to USMD_CR_ATTACHMENTS (‘Attachments’ List UIBB)

Then, we will customize the List UIBB of the ‘Attachments’ list. Navigate to the configuration of USMD_CR_ATTACHMENTS and add the newly created 'Attachment Type' field to the list.

MerveKaya_1-1726474828760.png
Figure 7- Add ‘Attachment Type’ column to List UIBB

e- Add ‘Derive with Attachment’ Button

MerveKaya_2-1726474856938.png
Figure 8- Add button to toolbar



2. Identify the Relevant Document

Once the "Attachment Type" field is available, logic will be developed to identify the correct attachment for derivation. The GenIL Object Handler Class for MDG CR Attachment will be enhanced with post-exit methods to ensure the document with the correct attachment type is selected.

a- Create enhancement for CL_USMD_CR_GIL_ATTACHMENT

MerveKaya_8-1726211402558.png
Figure 9- Sample Excel sheet filled with right format

Since this class is a final class, we can’t inherit and modify the required methods. Instead, we will create an enhancement implementation and insert post-exit.

b- Create post-exit to method CHANGE_OBJECT

MerveKaya_9-1726211402564.png

In this part of the code, we retrieve the attributes of the changed attachment and check the value of the "Attachment Type" field. If the attachment type is identified as "Derivation Document" (with the code 'DER'), we mark it for derivation. This value is then stored in memory to be used in the subsequent derivation process. If the attachment does not match the required type, it is excluded from the derivation logic. This ensures only relevant documents are processed during the change request.

c- Create post-exit to method GET_ATTRIBUTES

MerveKaya_10-1726211402570.png

In this section of the code, the attributes of the attachment are retrieved, and based on a flag set in the previous method, the attachment type is classified as either "Derivation Document" or "Other Documents." If it is a derivation document, its attributes are stored in memory and sent to the feeder class for further processing. This ensures that the system can distinguish between documents that are relevant for derivation and others that are not, maintaining the integrity of the process.

 

3. Perform the Derivation

The derivation process will occur in the GET_DATA method of the attachment list UIBB’s feeder class, where the Excel sheet will be read, and the field values will be derived accordingly. Messages related to the derivation process will be handled in the PROCESS_EVENT method, ensuring clear feedback is provided to the user.

a- Create custom feeder class for Attachments List UIBB

The CL_USMD_CR_GUIBB_ATTACHMENTS class, which is the feeder class for the Attachments List UIBB, needs to be enhanced. Therefore, we can create a custom feeder class and use CL_USMD_CR_GUIBB_ATTACHMENTS as its superclass.

MerveKaya_11-1726211402572.png
Figure 10- Custom Feeder Class

 

b- Redefine IF_FPM_GUIBB_LIST~GET_DATA

MerveKaya_12-1726211402575.png

We will begin by retrieving the attachment structure stored in previous methods. An attribute will be used to verify the existence of an attachment with the correct type.

MerveKaya_13-1726211402580.png

A crucial component of this code is the CL_FDT_XL_SPREADSHEET class. We will utilize specific methods from this class to select and read the relevant worksheets. Once the worksheet data is read, it is essential to map these values to the appropriate fields.

MerveKaya_14-1726211402584.png

After completing the data extraction and mapping, we will use the WRITE_ENTITY_DATA method from the CL_USMD_CONV_SOM_GOV_API class to write the entity data.

 

c- Redefine IF_FPM_GUIBB_LIST~ PROCESS_EVENT

MerveKaya_15-1726211402586.png

This method is used to display warning or error messages in unexpected scenarios. For instance, if the "Derivation Document" type of attachment is not uploaded but the derivation button is pressed, this code will trigger a warning message.

 

Outcome - Testing

To validate this implementation, we will upload three different documents. One of these documents will be an Excel sheet with field values that need to be derived. This document will have "Derivation Document" selected for the "Attachment Type" field, ensuring it is used for the derivation process. After document uploads, we will click ‘Derive with Attachment’ button. Only files that comply with the specified structure will be processed, while those that do not match the structure will be ignored.

MerveKaya_16-1726211402587.png
Figure 11- Sample Excel sheet filled with right format

MerveKaya_3-1726474948989.png
Figure 12- Add documents and click button

MerveKaya_18-1726211402591.png
Figure 13- A part of the derived fields

MerveKaya_4-1726474988864.png
Figure 14- Displayed warning message when there is no derivation document uploaded

MerveKaya_5-1726475015041.png
Figure 15- Displayed error message when there are multiple derivation documents uploaded

 

Conclusion

This blog has presented a practical approach to executing derivations in SAP MDG based on an attached document. By incorporating a custom field for attachment types and automating the derivation process, we can greatly minimize manual data entry and enhance operational efficiency. This solution is designed to be both scalable and flexible, making it adaptable to a wide range of business requirements and ensuring long-term usability.

 

Thank you for reading.
Best regards,

Merve, Çınar