How to keep specific fields editable after displaying error message in MIRO transaction?

Other Questions Miro
1

I’m working on custom validation logic in MIRO transaction using BADI MRM_HEADER_CHECK. When I detect that a reference number is already in use, I need to show an error message but still allow users to edit certain fields to correct the issue.

The problem is that when I display a type E message, all fields become disabled and users cannot make corrections. I need to keep two specific fields editable while blocking all others.

Here’s what I’ve tried without success:

  • Using MESSAGE <text> TYPE 'S' DISPLAY LIKE 'E' - doesn’t work
  • Checking SY-DINNR which shows 6000 at breakpoint
  • Using LOOP AT SCREEN in my BADI code - doesn’t show the field names I want to control

I cannot modify code outside my BADI implementation like PAI/PBO modules with chain statements.

My current validation code:

*Field symbol contains input values
ASSIGN ('(SAPLMR1M)INVOICE_DATA') TO <lfs_invoice>.
IF <lfs_invoice>-REF_DOC = lwa_existing-ref_doc.
  MESSAGE lc_error_msg TYPE 'E'.
ENDIF.

What approach would allow me to show the error while keeping selected fields editable for user corrections?

2

This is tricky because TYPE ‘E’ messages disable screen elements by design in SAP. Since you’re stuck working within the BADI, you need a different approach. Don’t throw an error message right away - store the validation result in a global variable or custom table and use a TYPE ‘W’ warning instead. This keeps all fields editable while alerting the user about the duplicate reference. You could also implement validation logic that prevents saving without triggering field locking. Set a flag when you detect the duplicate, then check this flag in later processing steps. The real problem is MIRO’s standard behavior - it locks fields after error messages to prevent processing conflicts. To work around this, you’ll have to ditch standard error messaging patterns in your BADI.

3

You’re hitting a basic SAP constraint - error messages automatically disable screen elements. Since you can’t modify PBO/PAI modules, try a two-phase validation approach in your BADI. First, collect all validation errors without throwing messages right away. Then check if the user has fixed the problematic fields since the last validation cycle. Store previous field values in a static internal table and compare them with current values. Only throw the error message when the user tries final processing (like saving) while issues still exist. For intermediate validations, use informational messages or populate custom screen fields with warning text instead of blocking messages. Check the current processing step within MIRO by examining system variables or the call stack. The trick is delaying the hard error until you absolutely need it while giving continuous feedback through non-blocking methods.

4

your timing’s off - throwing that error in MRM_HEADER_CHECK happens too early. Try MRM_PAYMENT_TERMS_CHECK or MRM_FOREIGN_TRADE_CHECK instead since they fire at different screen stages. Or catch the duplicate check in a separate method and just show a status message with SET TITLEBAR or something similar that won’t block the process.