De-Coupled Versus Non De-Coupled Infotype Framework

[Bryan_Johannsen]

De-Coupled Versus Non De-Coupled Infotype Framework

On a recent project the question was raised on various occasions as whether we should fully de-couple the infotype framework as part of the implementation.  Some useful content below that may assist you to answer the same question.  The purpose is not to provide a technical brief, as I’m sure there is content available already, but rather to provide some summary feedback on the investigations.

The project scope included HR Renewal 2.0 (FP 4) for HR Professional User Role.  When implementing any of the ‘new technology’, by nature you are already using the de-coupled framework, and as part of this implementation should consider at least activate the ‘PC_UI’ Switch (see attached for example) on the system table. This is to ensure data consistencies between the User Interface (UI) method and database data tables.

Once activated, the tendency may be to fully de-activate the infotype framework. In simple terms, regardless as to whether the UI is a traditional SAP GUI modulepool screen or a ‘new technology’ screen; the same processing logic will be used in the outcome.

Do you need to fully de-couple the infotype framework?  Consider below as part of your assessment:

1. Once activated, then as standard, some of the infotypes will be de-coupled.  This is defined by table V_T582ITVCLAS (see attached for example):  Typically these are the data sharing applicable infotypes, like infotype 0002 / 0006 / 0009, to enable concurrent employment processes.
2. If the infotype is set as ‘Permissible in certain Circumstances’, then those country circumstances are specified in table V_T582ITVCHCK (see attached for example):  As standard, SAP provides some countries de-coupled infotype framework.
3. Depending on above settings, table V_T582ITD can be used to specify the modulepool dialog module (see attached for example).  This is used in Personnel Administration (PA) when using normal SAP GUI (i.e. normal PA30, infotype maintenance).
4. The PA screen modifications are done in the normal way using table T588M.  If no entry is in table V_T582ITD, then the normal modulepool entry will be used to set the screen modifications (see attached for example):  for example, MP000200 versus MP000200_CE.
5. Traditional PA Infotypes using SAP GUI, and ‘new technology’ screens can CO-EXIST.  Both can be used at the same time and the old cliché ‘if it’s not broken, then do not try fix it’ comes to mind!!
6. What is gained by fully de-coupling the infotypes? And how much effort is involved?

Fully de-coupled infotype framework may only add value if your solution contains extensive use of the modulepool BAdi’s, or you planning on implementing extensive infotype custom enhancements.  The main reason for this is that in the de-coupled infotype framework, the same user exists are called within the processing logic.

In Summary:

Give some thought to above points before fully de-coupling the infotype framework.  The traditional infotypes and ‘new technology’ can co-exist and it’s worth the effort to do some initial homework before implementing an infotype framework solution.

I hope you found this content useful.  Please contact me directly for further details.

(Bryan.Johannsen@Epiuse.com)