De-Coupled Versus Non De-Coupled Infotype Framework
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:
- 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.
- 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.
- 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).
- 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.
- 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!!
- 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.
In most implementations I come across, it is not a "this OR that" decision. It is most often, as you point out, the two "co-existing".....sometimes not so peacefully. haha
In many cases, customers have no choice. Newer solutions like ESS/MSS and HCM Processes and Forms fully rely on decoupled infotypes (at least for PA related ones). And at the same time, customers will often have PA20/30/40 heavily customized through old user exits and such that make the transition not so "painless".
The Decoupled Infotype Framework (DCIF) has been around for years now, but the move is still slooooowwwwwwwww. One day? haha
Thanks for the blog! Keep them coming!
Thanks for the blog. However, I would like to get clarifications re: following:
1. I have seen some comments/posts that the DIF does not work correctly for some infotypes, like 2001. Is this still an issue?
2. Under what conditions, DIF would not be suitable or non-DIF is better?
Particularly, for those infotypes maintained by employees - e.g., 6, 9, 2001, 2002 (OT), - where the same default/validation rules should apply for both EIS/MIS and R/3 - I would expect, it is appropriate.
Has any one experienced or a different view in these aspects?
I'd appreciate feedback.