Obligatory attachment in MIGO via ‘Services for Objects’

If you are using transaction MIGO to post goods movements in your ERP system you may want to use the “Services for Objects” functionality to create attachments for your documents. For example you may want to upload the corresponding documents’ scanned versions for each goods movement. In this case you may also want to make the attachment obligatory for the endusers in MIGO. If you are seeking for a custom solution to create a check for uploaded documents using MIGO BAdis you are at the right place as in today’s blog I will demonstrate an example implementation for this.

Please note that the example program here is not a standard SAP solution, implementing and using it falls strictly into your own responsibility.

What do we need for this?

• A BADI implementation of MB_MIGO_BADI in transaction SE19
• A custom database table in SE11
• A little ABAP coding knowledge

How will this work?

1. When we start transaction MIGO, we will save the latest attachment ID in our custom database that the current user has created
2. When we check the document (also called at the time of posting) we compare the latest attachment ID with the one saved in point 1.
   • If the IDs are matching there has been no attachment uploaded >> we prevent a missing attachment
   • If the IDs are not matching:
     A) The user has created an attachment in MIGO >> user did not forget to upload the document
     B) The user has created an attachment in a concurrent parallel session >> this scenario may still result in missing attachments, not covered here
3. If the check is passed, during document posting we update the custom database with the new latest attachment ID so that the checks will also be working for the upcoming postings in the same session

How do we implement this?

• In transaction SE11 we create a custom database table which will help us comparing the attachment versions

As the key of ZMIGOATTACHMENT is only the MANDT and the username it will only store 1 entry / user.
To avoid duplicate insertion short dumps we will only insert/update (into) this table with the MODIFY keyword.

• In transaction SE19 we create an implementation for MB_MIGO_BADI

We need to implement three methods here:
INIT: to save the latest ID in our custom table
CHECK_ITEM: to compare the saved ID with the latest ID at the time of posting
POST_DOCUMENT: to update the latest ID in our custom table

Let’s see an example implementation:

method IF_EX_MB_MIGO_BADI~INIT.
DATA: ls_sood TYPE zmigoattachment,
lt_sood TYPE TABLE OF zmigoattachment.
SELECT * FROM sood INTO CORRESPONDING FIELDS OF TABLE lt_sood WHERE CRONAM = sy–uname.
SORT lt_sood BY CRDAT DESCENDING CRTIM DESCENDING.
READ TABLE lt_sood INDEX 1 INTO ls_sood.
IF ls_sood IS NOT INITIAL.
MODIFY zmigoattachment FROM ls_sood.
ENDIF.
CLEAR: ls_sood, lt_sood.
endmethod.

method IF_EX_MB_MIGO_BADI~CHECK_ITEM.
DATA: ls_zmigoattachment TYPE zmigoattachment.
DATA: ls_sood LIKE ls_zmigoattachment,
lt_sood TYPE TABLE OF zmigoattachment.
SELECT SINGLE * FROM zmigoattachment INTO ls_zmigoattachment WHERE cronam = sy–uname.
    IF sy–subrc = 0.
SELECT * FROM sood INTO CORRESPONDING FIELDS OF TABLE lt_sood WHERE CRONAM = sy–uname.
SORT lt_sood BY CRDAT DESCENDING CRTIM DESCENDING.
READ TABLE lt_sood INDEX 1 INTO ls_sood.
IF sy–subrc = 0 AND ls_sood = ls_zmigoattachment.
MESSAGE ‘Upload an attachment!’ TYPE ‘E’.
ENDIF.
ENDIF.
CLEAR: ls_zmigoattachment, ls_sood, lt_sood.
endmethod.

method IF_EX_MB_MIGO_BADI~POST_DOCUMENT.
DATA: ls_sood TYPE zmigoattachment,
lt_sood TYPE TABLE OF zmigoattachment.
SELECT * FROM sood INTO CORRESPONDING FIELDS OF TABLE lt_sood WHERE CRONAM = sy–uname.
SORT lt_sood BY CRDAT DESCENDING CRTIM DESCENDING.
READ TABLE lt_sood INDEX 1 INTO ls_sood.
IF ls_sood IS NOT INITIAL.
MODIFY zmigoattachment FROM ls_sood.
ENDIF.
    CLEAR: ls_sood, lt_sood.
endmethod.

Let’s see how this works:
I start MIGO and try to check or post the document:

If I upload any attachment and try again:

After successfully posting this goods receipt within the same session I can start posting another one, where the check will work again (as we updated the custom table in the post_document method).

If your users also use the F5 button sometimes (reset) you may also add the same coding into the RESET method as the one in INIT. There could also be a function module which contains this logic, as this same piece of code is called in INIT and POST_DOCUMENT as well, this makes maintenance easier.

You can obviously add further checks and extend this logic as well, this is just a rough example.

I hope it will be useful for someone!

Regards,
Peter