On a recent project, working with other great resources who have a deep understanding of their products and modules, it became clear toward the end of the project that very different views of the product integration had come through development. How the organization at a high level was viewed, was the driving force behind this issue. HR had always followed Finance for chartfield values, but because they looked at the employees as groups of people instead of budgetary elements, it caused some problems that weren’t clear in the previous software. And PeopleSoft didn’t help.

From the beginning, Finance was asked what combo codes would they be using and when would they be available for Time & Labor and Payroll. As quickly as the combo edits were created, the rules and their estimated values were passed to the HCM team. Finance then put the small set of rules in place using the combo edit table and wildcards.  HCM wanted to discuss maintenance of the values, but of course this is all handled dynamically on the finance side. Finance provided accounts for earnings, deductions, taxes, garnishments, net pay, etc. being as helpful as possible until someone asked for combo codes again.  We provided the same listing again, but this time HR wanted more.  “Can we see the full set of valid combinations created by your combo codes?”, they asked.  “Sure, but it’s about but it’s a large list.” was the answer.  The good news was that we had used wildcards so it wasn’t as bad as it could be.  Then everything fell apart.  PeopleSoft HCM can’t use wildcards and they needed a listing of all possible chartfeld combinations, not just the rules that created them.

To us in finance, combo codes meant combo rules.  To those in HCM, combo codes meant physical combinations of values.  In finance we call those SpeedTypes and SpeedCharts.  PeopleSoft HCM does not allow for data from the combo selector tables, even in version 9.1.  Only through the use of the old-fashioned combo data table can you pass information from Finance to HCM.  That’s a HUGE issue.

The process is to publish the data while building the table.  Well, on the first run for all business units, we found that it took roughly an hour per business unit to publish the data.  The entire process cost us 80 hours.  We tuned and optimized.  We looked for business units where the data just wasn’t needed.  We searched for every efficiency we could find and wer only able to bring the entire process down to 14 hours.  In an environment with constantly changing chartfield values, this was not a usable solution.

The delivered method of creating chartfield combinations in HCM, without finance modules attached, is to populate the ACCT_CD_TBL, with value combinations.  We could validate individual values in Finance, and create the combinations on the HCM side.  That was our final solution.  It has since caused some major headaches in business process around who creates them and what ‘valid’ combinations means, but it was a workable solution to get through implementation and handle creation on the fly.

This is a simplified view of a very complex problem, but it shows how even within our beloved software, it is very difficult to anticipate and solve integration across products and modules.  PeopleSoft has made some great advances since the advent of PIA, but they have fallen behind in some methods of internal integration.  None of us works enough with multiple modules to understand all the intricacies that can arise during an implementation, but we must learn to be as clear as we can when we ask for information from each other.

Make a promise, take a vow;

And trust your feelings, its easy now.