Field Selection – An insight on the technical implementation
After reading the Dibyendu’s blog post about field selection, I have decided to write a little bit about this topic with a more technical perspective.
You may have already asked yourself:
1) I set some field as OPTIONAL and when checking in the screen the field is BLOCKED or MANDATORY, why?
2) How does the system know how to link the fields into field selection tables T162, T162K, T162X and T162Y?
There are special logic behind the field selection process that overcome the customizing due to some business rule, so where does it happen?
Taking into account the Enjoy transactions, like ME21N:
- Each field is described as a metafield
- It is a unique identifier of a model. It can be a field, a function or a sub-object.
Metafields are constants defined in type pool MMMFD.
The metafield values above are the link into field selection customizing, table T162-FAUNR.
During the ME21N, system calls function module MEX_FELDAUSWAHL to process all the field selection logic.
The model has a list of objects, which map to metafields. Each object carries the business logic, for example:
Account Assignment Category
Object Reference (function group MEPO -> Class)
Here you can see the business logic that will overcome the field selection customizing.
Now, whenever you want to understand why such field has a different behavior that is customized (display only, mandatory, optional) you can just check the metafield and the correspondend class (function froup MEPO) to see if there is some business rule influencing the behavior.
PS: This logic applies for Purchase Orders only!