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.
Monday, 14 June 2010
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
Subscribe to:
Posts (Atom)