handle dynamic field control

[Atul_Joshi85]

In module pool programming, what is the best way to handle dynamic field control (enable/disable/mandatory) without making the PBO logic complex and hard to maintain?

When enhancing standard SAP transactions, how do you decide between building a custom module pool screen vs using user exits/BAdIs for screen enhancements?

[TMNielsen]

Hi 

I don't know a good method, so this is one of those no-answer answers. My suggest is to maybe make multiple dynpros instead of one dynpro handling multiple scenarios with  dynamic field control.

I have some programs where it has become very complex with a lot of rules for single fields and also for fields inside table controls.
The reason I ended in this complex situation is classic. The business requested a program to handle something for production of -  lets say bikes. "We must be able register how much plastic is used in the handlebars, saddle and 2 wheels".

They are happy and use the program for 2 years. Then they come back with an idea "we also want to use this program for kick scooters without a saddle, so to prevent errors you must hide this field when it is kick scooters".

Next year they want to use the program for go-karts, so now we need four fields for registering wheels data, b only when it is go-karts.
Next they want to register both plastic and steel, but only for bikes and for green kick scooters.
..and so on.

From the beginning and with the first new requirements to the program it seemed to be an easy fix to use dynamic field control, but in the end it turned out to be very complex to maintain. 
If I from the beginning had know the full requirements, I would have made one dynpro for bikes, one for saddles and one for kick scooters. The rest of the program with pai/pbo moduls, sub routions, class methods etc. I would have structured with reusable objects, so I would for example only have one plastic registration mechanism reused in all 3 dynpros.

So, I'm sorry this answer is not good ideas how to make dynamic field control simple. It is an advice to only use dynamic field control in simple scenarios.

I am excited to follow this thread to see if others have truly good advice about how to handle complex dynamic field control.

Best regards 
Thomas Madsen Nielsen

[Atul_Joshi85 · Accepted solution]

Hi Thomas,

You’re absolutely right — dynamic field control becomes unmanageable when every new business rule adds another IF/ELSE branch in PBO. I’ve been in the same situation, especially with table controls.

I eventually settled on a pattern that keeps the PBO clean by externalizing all field rules into a configuration table + screen groups, and then using one single LOOP AT SCREEN to apply the rules.
This way, the PBO never grows — only the config does.

How I solved it
Assign every field to a SCREEN-GROUP1 (e.g., GR1, GR2, MAND, HIDE).

Maintain a small internal table of rules based on scenario, document type, or user action.

Apply all rules in one LOOP AT SCREEN, without hardcoding field names.

Example Code (clean, scalable)

TYPES: BEGIN OF ty_rule,
group TYPE screen-group1,
input TYPE c,
required TYPE c,
invisible TYPE c,
END OF ty_rule.

DATA: lt_rules TYPE STANDARD TABLE OF ty_rule,
ls_rule TYPE ty_rule.

" Build rules dynamically based on scenario
IF gv_scenario = 'REST'. " Residential Customer
    APPEND VALUE #( group = 'GR1' input = '1' required = '1' ) TO lt_rules.
    APPEND VALUE #( group = 'SADD' invisible = '0' ) TO lt_rules.
ELSEIF gv_scenario = 'IND'. " Industrial customer
   APPEND VALUE #( group = 'SADD' invisible = '1' ) TO lt_rules.
ELSE.
   APPEND VALUE #( group = 'GR2' input = '1' required = '1' ) TO lt_rules.
ENDIF.

" Apply rules in ONE place
MODULE pbo_field_control OUTPUT.
LOOP AT SCREEN.
READ TABLE lt_rules INTO ls_rule WITH KEY group = screen-group1.
IF sy-subrc = 0.
IF ls_rule-input IS NOT INITIAL.
screen-input = ls_rule-input.
ENDIF.
IF ls_rule-required IS NOT INITIAL.
screen-required = ls_rule-required.
ENDIF.
IF ls_rule-invisible IS NOT INITIAL.
screen-invisible = ls_rule-invisible.
ENDIF.
MODIFY SCREEN.
ENDIF.
ENDLOOP.
ENDMODULE.

This approach kept my module pool maintainable even when the business added multiple new scenarios over time. 

My problem solve with this approach and based on customer type my screen fields getting populated for user input.