The UK P45 App Engine writes a message to the log if it thinks it can't find Tax details for a given employee. Based on what the message was telling us (set 17135,541 since you ask) I disagreed that no tax details existed, however I wanted to check the code to see how the App Engine makes the decision to issue the message. Normally I'd run a find in PeopleCode and SQL looking for the message set and number* - but this produced nothing.
Baffled, I asked on of the techy guys - he pointed out that App Engine can have a step that writes to the log - and so it proved. Unfortunately, neither I nor he knows a simple way to search for such a message as it's neither PeopleCode nor SQL at least not as the search understands it.
* Top tip - when searching PeopleCode for an error/warning message, insert a space after the message set and comma - so 17135,541 becomes 171, 541 - for reasons best known to itself PeopleCode adds the space.
Update - The client has a PeopleSoft/Oracle Service Request logged for this fault.
Friday, 19 November 2010
Wednesday, 17 November 2010
Big Fish, Small Pond
If you are a customer of large organisation, the relationship you have with that supplier is a function of your relative importance to them. My recent experiences dealing with two suppliers to my current project have highlighted this very clearly.
To one supplier my client is a large and valued customer. Asking them to work on their product to accomodate some of the vaguaries of a larger organisation has been met with refreshing response. They agreed to make some changes at no cost because they recognise the value of these in making the product saleable to other large organisations.
On the other hand, asking our larger supplier to incorporate a few features (and a few fixes!) from packages costing less than one hundreth of what the customer paid for this one has been met with a total lack of interest and "works as designed" response. They know that clientco is "trapped" with the package and so they have no need to bother spending anything on keeping them happy.
To one supplier my client is a large and valued customer. Asking them to work on their product to accomodate some of the vaguaries of a larger organisation has been met with refreshing response. They agreed to make some changes at no cost because they recognise the value of these in making the product saleable to other large organisations.
On the other hand, asking our larger supplier to incorporate a few features (and a few fixes!) from packages costing less than one hundreth of what the customer paid for this one has been met with a total lack of interest and "works as designed" response. They know that clientco is "trapped" with the package and so they have no need to bother spending anything on keeping them happy.
Monday, 27 September 2010
Oracle UK User Group - Global Payroll
I attended (and presented at) a very valuable day today. The UK OUG has responded to requests from users of PeopleSoft Global Payroll in the UK to set up a special interest group for GP in the UK.
The event was well attended and aside from the usual suspects (like me) there were useful presentations and participation from customers. However much I can offer, I always feel customers can get more value from speaking to each other.
Some interesting stuff from Oracle - they are revamping the Court Order pages and processing in UK GP - but probably not for a while. I had a hand in the Court order provision and to be honest, it probably is due for a revisit. It's one of those things I'd have differently if I'd known what I know now. Oracle do know - so they are re-doing it. Otherwise, Oracle didn't have a huge amount to tell us except for some overall enhancements using the latest tools technology to provide more user-configurable dashboards and similar so a user role can be defined and have all transactions, reporting and the like appear in front of the user.
The event was well attended and aside from the usual suspects (like me) there were useful presentations and participation from customers. However much I can offer, I always feel customers can get more value from speaking to each other.
Some interesting stuff from Oracle - they are revamping the Court Order pages and processing in UK GP - but probably not for a while. I had a hand in the Court order provision and to be honest, it probably is due for a revisit. It's one of those things I'd have differently if I'd known what I know now. Oracle do know - so they are re-doing it. Otherwise, Oracle didn't have a huge amount to tell us except for some overall enhancements using the latest tools technology to provide more user-configurable dashboards and similar so a user role can be defined and have all transactions, reporting and the like appear in front of the user.
Monday, 14 June 2010
Message Cat
My acquaintance with things tech is that dangerous sort where I know enough to be a hazard. Looking for a message number in PeopleCode, I was puzzled to find that it didn't appear to be referenced anywhere - I was forgetting of course that the message catalogue can be referenced on
a page to call instructional text (mainly in Self Service Pages) - as it was in this case.
a page to call instructional text (mainly in Self Service Pages) - as it was in this case.
Tuesday, 8 June 2010
Migrating PeopleSoft Global Payroll Configuration
One thing to think about and plan for carefully in any software implementation is the process by which the new or revised system is going to be tested and then moved to live or production. In GP this can be extra tricky, because there are different types of config/setup data as well as any customisations to migrate to the test system and then to live.
GP has 2 specific software tools for migration of GP configuration - each involves creating a package of configuration. These are the rules and non-rules packagers.
In addition, there are other means of moving configuration - the well-tried package export and DMS routes for migrating customisations and the contents of config tables respectively.
There is also an overlap between the methods - for example; it is possible to migrate the defintions for XLATvalues for a given field via DMS or the GP non-rules packager.
Each project will have to decide which tools to use, although in some cases, such as GP rules - there isn't any choice so the decision is easy.
Even for PeopleSoft specialists of many years standing, the rules packager can take some getting used to - it is pretty alien to anyone used to migrating projects.
To close - a quick note about the non-rules packager.
Why does the non-rules packager still reference rules?
On the face of it, non-rules items don't relate to rules, however in some cases, for example payslip templates, the non-rules record stores the PIN_NUM of the payment or deduction element that is to appear on the payslip.
Because of the way the rules packager works, the PIN_NUM may not be the same for the same element in different environments. This means that to successfully move a payslip definition, it must take across the names of the earnings and deduction and get the PIN_NUM when
the destination environment is reached. The non-rules package does this by taking these details along with the non-rules data.
GP has 2 specific software tools for migration of GP configuration - each involves creating a package of configuration. These are the rules and non-rules packagers.
In addition, there are other means of moving configuration - the well-tried package export and DMS routes for migrating customisations and the contents of config tables respectively.
There is also an overlap between the methods - for example; it is possible to migrate the defintions for XLATvalues for a given field via DMS or the GP non-rules packager.
Each project will have to decide which tools to use, although in some cases, such as GP rules - there isn't any choice so the decision is easy.
Even for PeopleSoft specialists of many years standing, the rules packager can take some getting used to - it is pretty alien to anyone used to migrating projects.
To close - a quick note about the non-rules packager.
Why does the non-rules packager still reference rules?
On the face of it, non-rules items don't relate to rules, however in some cases, for example payslip templates, the non-rules record stores the PIN_NUM of the payment or deduction element that is to appear on the payslip.
Because of the way the rules packager works, the PIN_NUM may not be the same for the same element in different environments. This means that to successfully move a payslip definition, it must take across the names of the earnings and deduction and get the PIN_NUM when
the destination environment is reached. The non-rules package does this by taking these details along with the non-rules data.
Thursday, 3 June 2010
More Errors
We've had a couple of Cobol 153 errors lately. I remember this error from my old days of trying to support a distribution system that was written in Cobol, although I don't pretend to know exactly what it means.
In the olden days we used to get this error where a piece of data didn't match the definition in the program - so for example, it was expecting a numeric value and got a text string.
In this case, in at least one case of PeopleSoft Global Payroll failure it was caused by an Array limit being set too small - something that took an age to track down.
Edit: I plan to post more on this including some tips on how to track down which payee is experiencing the error
In the olden days we used to get this error where a piece of data didn't match the definition in the program - so for example, it was expecting a numeric value and got a text string.
In this case, in at least one case of PeopleSoft Global Payroll failure it was caused by an Array limit being set too small - something that took an age to track down.
Edit: I plan to post more on this including some tips on how to track down which payee is experiencing the error
Sunday, 28 March 2010
Tracking down an obscure GP error
We recently had a problem in our test database with a large number of employees being placed in error status. The error message referred to a missing frequency - but it wasn't specific about which element (it would have helped a lot to know).
After a great deal of work, we found that there was a small number of employees for whom the error didn't appear and these turned out to be those who had a particular rate code entered in their compensation record.
It transpired that by adding the rate code, a frequency could be established by the payrun.
There are a few points to bear in mind:
A rate code element which has the eligibility of "eligibility group" rather than "payee" and appears in a section in the process list will be processed for every employee - this processing will effectively be "silent" for most employees if (as in this case) they don't have a corresponding rate code in compensation (the element resolution chain
didn't help us here as the element in error didn't appear in most people's records). However, if a piece of data is missing - in this case the frequency on the HR rate code, it may cause an obscure and unexpected error for large numbers of employees
After a great deal of work, we found that there was a small number of employees for whom the error didn't appear and these turned out to be those who had a particular rate code entered in their compensation record.
It transpired that by adding the rate code, a frequency could be established by the payrun.
There are a few points to bear in mind:
A rate code element which has the eligibility of "eligibility group" rather than "payee" and appears in a section in the process list will be processed for every employee - this processing will effectively be "silent" for most employees if (as in this case) they don't have a corresponding rate code in compensation (the element resolution chain
didn't help us here as the element in error didn't appear in most people's records). However, if a piece of data is missing - in this case the frequency on the HR rate code, it may cause an obscure and unexpected error for large numbers of employees
Subscribe to:
Posts (Atom)