I’m working on validation logic in MIRO transaction using the BADI MRM_HEADER_CHECK. When I detect that a reference field value has been used before, I need to show an error message but still allow the user to edit certain fields to correct the issue.
The problem is that when I display an error message with type E, all input fields become disabled and the user cannot modify the reference field to fix the duplicate value.
Here’s what I’ve already tried:
Using MESSAGE <text> TYPE 'S' DISPLAY LIKE 'E' but this doesn’t provide the blocking behavior I need
Checking SY-DYNPRO value which shows 6000 at breakpoint
Using LOOP AT SCREEN in my BADI code but it doesn’t show the field names I want to control
I need to show an error type message to block most fields but keep two specific fields editable so users can fix their input. I cannot modify code outside of my BADI implementation like PAI/PBO modules.
Here’s my current BADI implementation:
*Get reference to input data structure
ASSIGN ('(SAPLMR1M)INVOICE_HEADER') TO <lv_header_data>.
IF <lv_header_data>-REFERENCE_NO = lv_existing_ref-reference_no.
MESSAGE lv_error_text TYPE 'E'.
ENDIF.
Is there a way to selectively enable certain fields after showing an error message within the BADI? Any suggestions would be helpful.
Unfortunately, you can’t do this with the MRM_HEADER_CHECK BADI. When you throw a TYPE ‘E’ message from this BADI, SAP locks down the entire screen to prevent processing with invalid data. The BADI runs too late in the process - PBO’s already finished and LOOP AT SCREEN won’t work. Here’s what I’ve done instead: Use a two-step validation. First, throw a MESSAGE TYPE ‘W’ with a clear warning about the duplicate reference. This keeps fields editable while alerting the user. Then add logic in an earlier BADI like MRM_PAYPLAN_MODIFY or use enhancement spot MRM_HEADER_CHECKS to catch duplicates before the hard validation kicks in. You could also create a custom popup using POPUP_TO_CONFIRM within your BADI. Let users acknowledge the error and return to editing mode, but you’ll need to handle the message flow carefully.
The issue here is that MRM_HEADER_CHECK is executed too late in the process, which prevents you from modifying screen elements when the error message is displayed. I encountered a similar challenge with duplicate invoice validations. Instead, I used the MRM_HEADER_PROCESS enhancement spot, which operates earlier in the flow, allowing you to alter field properties. Additionally, a user exit like MRMH0001 can be beneficial; it enables you to implement checks for duplicates and adjust screen properties using LOOP AT SCREEN before the standard validation process takes control. The key is to perform these checks before the SAP error messages become active.
This is where automation saves the day. I’ve dealt with similar SAP validation headaches - trying to work around BADI timing issues is a nightmare.
I moved the entire validation logic outside SAP. Built a workflow in Latenode that monitors MIRO transactions in real time and handles duplicate checking before data hits the system.
Here’s how: Latenode intercepts transaction data, runs the duplicate check against your reference table, and if there’s a match, presents a custom form with only the fields they need to edit enabled. Once they fix the reference number, it automatically resubmits to SAP.
You completely bypass SAP’s rigid field locking behavior. No more fighting screen modifications or trying to time validations perfectly.
I set this up for invoice processing and cut user frustration by 90%. Users get clear feedback and can fix issues immediately without getting locked out.
Whole setup took me 2 hours in Latenode versus weeks hacking around SAP’s limitations.
i’ve faced the same problem! for better control, using user-exit M08M0003 is your best bet. it lets you adjust screen field properties before the display. alternatively, consider saving the error in a global var and manage it later rather than showing it immediately.