Post on 21-Nov-2014
description
How to get the best out of HCM
Chris PaineSAP Mentor 2011
ConsultantPresence of IT
When “Good” just won’t cut it
• SAP “standard” HCM delivers a good solution
• For most of us it’s not 100% what we want• 2 choices:
Change the company to fit SAP Change SAP to fit the company
But the Unmentioned Law
Don’t stuff it up and don’t cost me a fortune!
Changing SAP
• Enhancing not modifying!• Some key areas
Triggering something off an update WDA versus WDJ and Classic Dynpro Decoupled Infotype Framework Build your own versus adapt some standard
(BYO ASS)
Triggering off an update
• Multiple use cases Want to create/update additional data records
when some information updated. » E.g. Removing a reminder when a qualification has been
obtained
Causing an external action.» E.g. Creating a user when a user id is entered against a
person
Notifying another party.» E.g. Starting a workflow to update key data when a new hire
is entered
Where to trigger, the good, bad and ugly• Ugly
Custom infotype screen logic in customer include area
• Bad Dynamic Actions Table T588Z User Exits (EXIT_SAPFP50M_00n (n=1,2), exit
HRBAS001)• Good
Enhancement spots!
Triggering an update within Enhancement Spot HRPAD00INFTYBL
• Only trigger on DB update – not on check! Use “in update task” extension of FM to update infotypes (otherwise locking/buffer issues).
• Many standard implementations – use them as guidelines
WDA versus WDJ and Classic Dynpro
• WDA gives a lot of flexibility in enhancing – much more than we have been used to Method pre and post and replace, View enhancement: remove, replace, adjust Replace entirely and re-use model Application and component configuration
• FPM gives even more flexibility Detailed configuration options
So many options!
Add, delete, copy, it’s all there
Flexible layout configuration (OVP floorplan of WDA FPM)
GUIBB configuration (WDA ESS EhP5)
WDA versus WDJ and Classic Dynpro
• Don’t bother enhancing WDJ code No simple way to detect changes when support
packs applied Creating a custom solution may mean look and
feel differs from SAP solution• Enhance WDJ screens through
configuration• Classic Dynpro screens sometimes have
areas for customer enhancements
&sap-config-mode=XCtrl-Shift Right-Click
CI_includes
Adding new field to WDJ
• Insert fields in CI include• Go to personalisation
View main structure Add custom extension fields Remember to map fields either to custom field
in infotype, or through conversion classes.
Custom Extension Fields
Decoupled Infotype Framework
• The “new” way to read, create and update infotype records.
• PA and OM Infotypes – Time is only notionally supported (is very different logic)
• Main difference – do update, get results, then decide whether to commit result to database.
Decoupled Infotype framework components• Check classes
Infotype and country version dependent –E.g. CL_HRPA_INFOTYPE_0008_13
Manipulates data to pass to user – E.g. Evaluating indirectly evaluated wagetypes.
Independent of any screen logic Can be replaced with custom version (modify table
T582ITVCLAS (but really not recommended!)) Explicit enhancement points
» Enhancement Spot HRPAD00INFTYBL
Enhancement for Business Logic Check classes
N.B. possibility to intercept DB update, not really part of BL check classes but a very valuable exit!
Decoupled Infotype framework components• Conversion Classes
Convert between infotype structure Pnnnn and screen structure
E.g. HCMT_BSP_PA_AU_R0008 converted by class CL_HRPA_UI_CONVERT_0008_AU (see table T588UICONVCLAS)
Explicit enhancement points »Enhancement Spot HRPAD00INFTYUI
Enhancement Spot for Conversion Classes
Deprecated (I think) cool stuff
• Generic Text Reader Part of decoupled framework – but does not
appear to be implemented in latest BOL layer over DCIF – use with caution!
Table V_T588AUTO_TEXTC• Required/Read Only fields
Occasionally referenced in Check Classes not part of BOL implementation (AFAIK)
Table T588MFPROPC
Build your own versus adapt some standard• Build your own solution
Pros Cons
Complete control No base to work from
Can be designed for reuse Takes a good knowledge of eventual use cases to make reusable
Have functionality that is of business benefit
SAP may release similar solution in near future which could be
Relatively safe from upgrade/support pack changes
Requires extensive documentation to support
Build your own versus adapt some standard• Adapt a standard solution
Pros Cons
A working base to improve on Underlying SAP code not documented – can be tricky to enhance
Benefit from SAP enhancements Not exactly as per user requirements
Return to standard with lower support cost is easier
Limited to areas where SAP already have some kind of implementation
Less development to document Development needs extensive regression testing on support pack/upgrade
Too much or too little or not enough?
Thank you for your time
• Questions?
Paying It Forward – Call me!
chris.paine@presenceofit.com.au – chris@wombling.com – Twitter @wombling