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.
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.
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:
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.
Figure 1- Create domain
Figure 2- Add value for dropdown list box
Figure 3- Create data element
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.
Figure 4- Create append structure
Figure 5- Final view of BSS_CRIL_ATTACHMENT_ATTRIBUTES
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.
Figure 6- Add ‘Attachment Type’ field to Form 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.
Figure 7- Add ‘Attachment Type’ column to List UIBB
Figure 8- Add button to toolbar
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.
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.
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.
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.
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.
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.
Figure 10- Custom Feeder Class
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.
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.
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.
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.
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.
Figure 11- Sample Excel sheet filled with right format
Figure 12- Add documents and click button
Figure 13- A part of the derived fields
Figure 14- Displayed warning message when there is no derivation document uploaded
Figure 15- Displayed error message when there are multiple derivation documents uploaded
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
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
| User | Count |
|---|---|
| 3 | |
| 2 | |
| 1 | |
| 1 | |
| 1 | |
| 1 | |
| 1 | |
| 1 | |
| 1 | |
| 1 |