Enhancing SAP HCM - Thoughts and opinions hcm
Upcoming SlideShare
Loading in...5
×
 

Enhancing SAP HCM - Thoughts and opinions hcm

on

  • 2,695 views

Slide deck from presentation given at #SAUG Plenary in Melbourne Nov 2011 - all views contained are my own and do not reflect those of my employer or SAP.

Slide deck from presentation given at #SAUG Plenary in Melbourne Nov 2011 - all views contained are my own and do not reflect those of my employer or SAP.

Statistics

Views

Total Views
2,695
Views on SlideShare
2,691
Embed Views
4

Actions

Likes
0
Downloads
62
Comments
0

2 Embeds 4

https://twitter.com 3
http://www.slashdocs.com 1

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Enhancing SAP HCM - Thoughts and opinions hcm Enhancing SAP HCM - Thoughts and opinions hcm Presentation Transcript

  • How to get the best out of HCM
    • Chris Paine
    • SAP Mentor 2011
    • Consultant
    • Presence 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=X Ctrl-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! [email_address] – [email_address] – Twitter @wombling