I’m working on custom validation logic for SAP transaction MIRO using the implementation MRM_HEADER_CHECK. My goal is to validate that a reference number hasn’t been used before.
When I display an error message (type E), all input fields become disabled and users cannot edit them anymore. However, I need certain fields to remain active so users can correct their input.
What I’ve tried:
- Using
MESSAGE <text> TYPE 'S' DISPLAY LIKE 'E' but it doesn’t provide the blocking behavior I need
- Checking screen modifications with
LOOP AT SCREEN but the required field names are not visible in my enhancement point
- The system variable
SY-DYNPR shows value 6000 when I debug
My current implementation:
*Access form data structure
ASSIGN ('(SAPLMR1M)INVOICE_DATA') TO <lfs_data>.
IF <lfs_data>-REF_DOC = lv_existing_ref.
MESSAGE lv_error_text TYPE 'E'.
ENDIF.
Constraints:
- Cannot modify standard SAP code outside the enhancement
- Must use error type message to prevent saving
- Need selective field control after validation
Is there a way to enable specific input fields after showing an error message within the BADI implementation? Any suggestions would be helpful.
Classic MIRO validation headache. This happens because error messages in header check BADIs trigger SAP’s standard screen protection - locks down everything. Here’s what works: don’t throw the error directly in MRM_HEADER_CHECK. Instead, store your validation results in a global variable or memory object. Then handle the actual field control in a screen enhancement at PBO level where you can use LOOP AT SCREEN. Validate your reference number in the BADI but just set a flag for the error state. During PBO processing, check that flag and enable/disable specific fields using the screen-input attribute. Use screen-name values to target exactly which fields stay editable. Basically, split validation from field control. You get the blocking behavior you want while keeping granular control over field access. I’ve done this on several MIRO enhancements - works consistently across different SAP versions.
Been through this exact scenario with MIRO validations. SAP treats header validation BADI errors as transaction-level failures, which locks down all fields. Here’s what works: use a two-phase approach with message class handling. Don’t throw the error immediately in MRM_HEADER_CHECK. Instead, capture the validation failure and use MESSAGE TYPE ‘W’ with a specific message class. You’ll get a warning that alerts users without locking fields. For the blocking part, add logic in a save document BADI like MRM_UR_APPROVE. Re-validate there and throw the actual error only when they try to save. Users can keep editing after the warning, but the transaction won’t complete with bad data. The trick is separating user notification from save prevention. Warnings give feedback without triggering SAP’s field locking. Save-time validation keeps your data clean. I’ve used this pattern successfully in procurement docs where users needed multiple tries to fix complex reference data.
The Problem: You’re encountering issues with custom validation in SAP transaction MIRO using the MRM_HEADER_CHECK BADI. Specifically, when displaying an error message (type ‘E’), all input fields are disabled, preventing users from correcting their input. You need to maintain the ability to edit specific fields after an error message is shown, while still preventing the transaction from saving with invalid data. You’re constrained by not being able to modify standard SAP code outside your enhancement and must use error-type messages to prevent saving.
Understanding the “Why” (The Root Cause):
SAP’s standard error handling within BADIs like MRM_HEADER_CHECK locks the entire screen when an error message of type ‘E’ is triggered. This behavior is designed to prevent data corruption by halting the transaction upon detecting invalid input. The limitation lies in the lack of granular control over individual field enabling/disabling within the BADI itself. Directly attempting to modify screen behavior within this BADI is often unsuccessful due to the tight integration with SAP’s transaction framework.
Step-by-Step Guide:
-
Separate Validation from Field Control: The core solution is to decouple the validation logic from the screen field control. Instead of raising the error directly in the MRM_HEADER_CHECK BADI, use a two-phase approach:
- Phase 1: Validation in
MRM_HEADER_CHECK: Perform your reference number validation within the BADI. Instead of displaying the error message here, set a flag (e.g., a global variable or memory object) to indicate whether validation passed or failed. This flag will act as a signal for your screen enhancement. Example:
*Access form data structure
ASSIGN ('(SAPLMR1M)INVOICE_DATA') TO <lfs_data>.
IF <lfs_data>-REF_DOC = lv_existing_ref.
gv_miro_validation_error = 'X'. "Set a global flag
ENDIF.
- Phase 2: Screen Control in PBO Enhancement: Create a screen enhancement (using a suitable enhancement point like a PBO exit within the MIRO transaction) to control individual field behavior. Within this enhancement, check the flag you set in the BADI. If the flag indicates an error, use
LOOP AT SCREEN to selectively disable or enable fields based on their screen names.
* In your PBO screen enhancement
LOOP AT SCREEN.
IF screen-name = 'REF_DOC' AND gv_miro_validation_error = 'X'.
screen-input = 0. "Disable the reference document field
ENDIF.
IF screen-name = 'ACCOUNT' AND gv_miro_validation_error = 'X'.
screen-input = 1. "Keep the account field enabled
ENDIF.
MODIFY SCREEN.
ENDLOOP.
Remember to replace 'REF_DOC' and 'ACCOUNT' with the actual screen names of the fields you want to control. You can find these screen names by debugging the MIRO transaction.
-
Display the Error Message: Only after the user attempts to save the document (potentially within a MRM_UR_APPROVE BADI) should you display the actual error message (type ‘E’) to prevent the saving action.
Common Pitfalls & What to Check Next:
- Incorrect Screen Names: Double-check the screen names used in your
LOOP AT SCREEN statement. Incorrect names will result in no effect on the fields. Use debugging to confirm the correct names.
- Global Variable Scope: Ensure your global variable (
gv_miro_validation_error in this example) is accessible in both your BADI and your screen enhancement.
- Enhancement Point Selection: Choose the appropriate enhancement point for your PBO screen modification. This depends on the specific SAP version and the customization you need.
Still running into issues? Share your (sanitized) config files, the exact command you ran, and any other relevant details. The community is here to help!
I tried a workaround with MESSAGE TYPE ‘I’ and POPUP_TO_CONFIRM. When validation fails, I show an info popup asking if they want to keep editing. This skips the field locking since info messages don’t trigger screen protection. If they hit ‘yes’, they can edit normally. If ‘no’, I use sy-ucomm = ‘CANC’ to exit. Not perfect, but it keeps fields editable while warning about duplicate references.
This topic was automatically closed 24 hours after the last reply. New replies are no longer allowed.