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.
No comments:
Post a Comment