I’m working on custom validation logic in SAP MIRO transaction using the BADI MRM_HEADER_CHECK. When I detect that a reference field value has been used before, I need to display an error message but still allow users to edit certain fields on the screen.
The problem is that when I show an error message with type E, all input fields become disabled and users cannot correct the problematic field value.
What I’ve tried so far:
- Using
MESSAGE <msg> TYPE 'S' DISPLAY LIKE 'E' but this doesn’t work
- Adding
LOOP AT SCREEN logic in my BADI but it doesn’t detect the field names I want to enable
- Checking
SY-DINNR which shows value 6000 at breakpoint
My current BADI implementation:
*Access form data structure
ASSIGN ('(SAPLMR1M)INVOICE_DATA') TO <lfs_invoice>.
IF <lfs_invoice>-REF_DOC = lv_existing_ref.
MESSAGE lv_error_msg TYPE 'E'.
ENDIF.
Constraints:
- I must use error type E to block most fields except two specific ones
- Cannot modify standard PAI/PBO modules or CHAIN/ENDCHAIN logic
- Need solution within BADI scope only
Is there a way to selectively enable certain fields after showing an E-type message in this context?
Try a two-phase validation in your BADI. Instead of throwing the E message immediately upon finding the duplicate reference, consider setting a custom flag or storing the result in a global variable. Update your screen logic to check this flag and conditionally enable the necessary fields using LOOP AT SCREEN. In my experience with MM transactions, manipulating screen elements after validation but before displaying the message allows for better control. Another option is to use CALL FUNCTION ‘POPUP_TO_CONFIRM’ or similar dialog functions, as they manage user interaction without activating SAP’s standard field locking that comes with TYPE E messages.
Have you tried using MESSAGE with ID and NUMBER parameters plus field modification? I’ve done similar MIRO customizations and found that MESSAGE ID 'custom_message_class' TYPE 'E' NUMBER '001' WITH field_value works well if you manipulate the screen fields right after in the same processing block. This sometimes keeps field accessibility intact. The trick is modifying the screen table after the message call but before the transaction hits the error state. Also check if your BADI supports the CHANGING parameter for screen modifications - newer MRM_HEADER_CHECK implementations let you access the screen table directly. Another thing that worked for me was creating a custom transaction variant with SHD0 to predefine which fields stay active during errors. You’ll need to coordinate with your functional team though.
i totally get your frustration with E messages! what worked for me was using a custom flag to manage validation. try triggering a different event or using POPUP_TO_INFORM instead to show your messages without locking the fields. it ain’t perfect, but it might help you out!