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

[joec]

I’m working on custom validation logic for 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 keep certain fields available for editing.

The problem is that when I display an error message with type E, all input fields get disabled and users cannot modify the reference field to correct the issue.

I need to block most fields but allow editing of two specific ones (the reference field and one other). I’ve tried several approaches without success:

• Using MESSAGE <text> TYPE 'S' DISPLAY LIKE 'E' - this doesn’t work
• The screen number SY-DINNR shows 6000 when debugging
• LOOP AT SCREEN in my BADI doesn’t show the field names I want to control
• I cannot modify standard SAP code outside my BADI implementation

Here’s my current BADI implementation:

*Field symbol contains input values
ASSIGN ('(SAPLMR1M)INVOICE_HEADER') TO <lfs_header>.
IF <lfs_header>-REFERENCE = lv_existing_ref.
  MESSAGE lv_error_msg TYPE 'E'.
ENDIF.

Is there a way to achieve this field control behavior within the BADI? Any suggestions would be helpful.

[RunningTiger]

I’ve encountered similar challenges with field control in MIRO transactions. The default behavior of error messages indeed locks down the screen to maintain data integrity, which can be frustrating. A solution that worked for me was to utilize the MRM_POPULATE_BKPF BADI instead; it activates during the document creation phase and allows for more flexibility in controlling the user interface flow. Additionally, consider issuing a warning message initially rather than an error. This way, you can guide the user to correct the reference field, possibly using a custom memory ID to track their response. If necessary, you can enforce the error later if no action is taken. Lastly, verify if the MRM_SCREEN_MODIFY BADI is available in your system version, as it provides specific functionalities for modifying screens, which might help achieve your desired field-level control.

[pixelPilot]

The Problem:

You’re encountering difficulties with custom validation in the SAP MIRO transaction using the BADI MRM_HEADER_CHECK. When a duplicate reference number is detected, you want to display an error message but allow editing of specific fields (the reference field and one other), rather than disabling all fields. Standard error messages (MESSAGE ... TYPE 'E') disable all input fields, preventing the user from correcting the error. You’ve tried various approaches, including using MESSAGE ... TYPE 'S' DISPLAY LIKE 'E' and manipulating the screen using LOOP AT SCREEN, but these haven’t worked.

Understanding the “Why” (The Root Cause):

The core issue is that SAP’s built-in error handling in MIRO transactions is designed to maintain data integrity by locking the screen to prevent invalid data entry after an error. This rigid approach doesn’t readily support the more nuanced requirement of selectively enabling certain fields for correction after error detection within the BADI MRM_HEADER_CHECK. BADIs, by design, provide limited control over the underlying screen behavior; they are primarily intended to add validation checks, not to comprehensively alter the UI flow. Attempting to achieve the desired selective field control directly within the BADI might be overly complex, potentially leading to issues with maintaining the standard SAP functionality and future upgrades.

Step-by-Step Guide:

Step 1: Automate the Validation and Correction Process Outside of MIRO

The most effective solution is to bypass the limitations of the MIRO transaction’s built-in error handling by creating a separate automated process. This process would monitor MIRO entries for duplicate reference numbers, flag the issues, and provide a user-friendly interface for correction.

1. Develop an External Monitoring System: Create an external application (e.g., using ABAP, a third-party integration platform like Latenode, or other tools) that monitors MIRO transactions either in real-time or periodically. This system would identify transactions with duplicate reference numbers.

2. Create a Correction Interface: Build a user-friendly interface (a separate screen or web application) specifically designed for correcting only the problematic fields (the reference number and the other selected field). This interface should display the invalid transaction data to be corrected.

3. Implement Automated Resubmission: After the user corrects the data in this separate interface, the system would automatically resubmit the corrected transaction data to the MIRO transaction.

Step 2: Consider Alternative BADIs (If External Automation Isn’t Feasible)

If automating the entire process outside MIRO isn’t possible, you could explore using other BADIs. However, these provide less direct control over the user interface.

1. Explore MRM_POPULATE_BKPF: This BADI is called during document creation and might offer more control over the initial data entry. You could implement a preemptive check here.

2. Use Warning Messages: Try using MESSAGE ... TYPE 'W' instead of TYPE 'E'. This will alert the user to a problem but will not lock the screen. You may need to build more complex logic (possibly using custom memory IDs) to manage the state of correction attempts.

Common Pitfalls & What to Check Next:

• Authorization: Ensure your external system or BADI implementation has the required authorizations to access MIRO data and submit transactions.
• Error Handling: Implement robust error handling in your external system or BADI to manage unexpected situations gracefully. Log errors and provide informative feedback to the user.
• Performance: For high transaction volumes, optimize the monitoring and correction process to avoid performance bottlenecks.
• Testing: Test the complete workflow thoroughly, including all error conditions and edge cases, before deploying it to production.

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!

[Zack_45Gaming]

have you thought about using warning msgs? try MESSAGE TYPE ‘W’ - it allows fields to stay editable while letting user kno about dup refs. also look into screen mod exits - they can give better control of field props after error validations.