I’m working on field validation in MIRO transaction using BADI MRM_HEADER_CHECK. When I detect that a reference field value is already in use, I need to display an error message but keep certain fields editable so users can correct their input.
The problem is that when I use message type E, all fields become disabled and users cannot modify anything on the screen. I need to keep two specific fields active 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 value (shows 6000)
- Using
LOOP AT SCREEN in my BADI - can’t see the field names I want to control
I cannot modify standard SAP code outside my BADI implementation like PAI/PBO modules or CHAIN statements.
My current BADI implementation:
*Field symbol contains input values
ASSIGN ('(SAPLMR1M)INVOICE_DATA') TO <lfs_invoice>.
IF <lfs_invoice>-REFERENCE = lwa_check-reference.
MESSAGE lc_error_text TYPE 'E'.
ENDIF.
Is there a way to show an error message while keeping specific fields editable for user correction?
try switching from message type E to W - warnings don’t usually lock all fields like errors do. Also check if you can set field properties directly in the BADI using screen-input = 1 for specific fields after the message.
This happens a lot with BADI MRM_HEADER_CHECK because it runs during field validation, and MESSAGE TYPE ‘E’ locks up the fields. Don’t use MESSAGE TYPE ‘E’ directly - try a custom validation instead using the BADI’s export parameters. Set the returning parameter to flag validation failure without throwing the error right away. Then handle the actual error display in a user exit or enhancement that fires later when you’ve got more control over screen behavior. You could also use function module POPUP_TO_INFORM to show your error as a popup while keeping the screen fields accessible. Users can acknowledge the error and keep editing the problem fields without getting locked out.
had the same issue b4. the E message locks inputs in MRM_HEADER_CHECK, so instead of directly throwing the error in the BADI, just collect validation errors in a global var. later, in PBO, check that var and show a custom error dialog. fields remain editable this way.
It’s common to encounter issues with MESSAGE TYPE ‘E’ in BADI MRM_HEADER_CHECK. Here’s a method that has worked for me: Instead of directly triggering the error in MRM_HEADER_CHECK, gather your validation issues in a custom structure and mark a flag to indicate validation failure. Later, during the PBO, use enhancement points or user exits to inspect this flag and display messages with MESSAGE TYPE ‘S’, adjusting screen field properties as needed. Additionally, consider utilizing the CHANGING parameters offered by the BADI to modify field attributes, as some setups allow for screen behavior adjustments this way. Using function CALL FUNCTION ‘POPUP_TO_DISPLAY_TEXT’ can also help, as it provides a notification without affecting field interaction. In short, steer clear of the standard MESSAGE TYPE ‘E’ approach, as it disrupts user input.