Friday, 31 December 2010
Windows Live Mesh
One of my activities over my Christmas/New Year break has been to try to syncronise data between my various computers. A quick Google led me to a free Microsoft tool for this; Windows live mesh. If like me, you have multiple computers and it's useful to find the same set of documents, music and pictures on each one, I encourage you to take a look at this. In a nod to "The Cloud", it includes 5GB online to store stuff too.
Happy New Year to All
2010 was a pretty good year for me, I hope it was for you too. Whatever 2010 brought you I wish you a Happy 2011
Friday, 19 November 2010
More on Messages
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.
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.
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
Tuesday, 9 February 2010
Top Tips For Any New Payroll Implementation
I came across this list I wrote some time ago; it's as relevant now as it was then.
Complexity isn't related to numbers of employees being processed.
Even though bureaux and similar providers sometimes charge per payslip,
the costs and complexity of processing are related to issue like the
numbers and complexity of payments and deductions, the reporting and
interface requirements, employee turnover and accuracy and timeliness of
data recording in the organisation. This is why reports and interfaces
are usually additional to the costs of bureau processing.
A software solution cannot, of itself, correct poor business processes.
If, for example, parts of the organisation are accustomed to not
reporting the fact that some one has left or joined the organisation
until weeks or months after the event, this will result in extra work
for payroll, regardless of any computer system that's in place. Any
system that attempts to provide an automated solution to issues of poor
process is likely to be expensive, complex and disappointing.
End user training.
* Make sure end users have received enough training to be
confident in the operation of the system
* Make sure the training covers details of procedures required in
order to achieve various results in payroll (e.g. how to process
backdated/retro changes, how to make corrections, etc)
Experience of projects where this isn't done shows end users (quite
reasonably) try to perform actions in the same way they have done on
previous systems; then blame the system when the results are not what
they expected.
Don't assume you know and understand the scope and functionality of the
new system until you do!
Don't assume a particular function either exists or operates in a given
way until you've checked.
Don't assume that because a piece of configuration is delivered it will
meet all your needs until you've checked.
Don't assume that functionality in the new system will be the same as
the old.
It definitely won't. Even if they have identical capabilities, results
will be achieved in different ways - at the very least input screens or
pages will look different.
Don't assume the legacy system is always correct.
We have seen examples of legacy systems that have been calculating
payments or deductions wrongly for years.
Don't assume current practises are correct/legal
We were recently asked how to set up the system to process mid-period
changes to NI category codes and calculate each part period using the
appropriate code. The system doesn't support this process because the
NI rules don't require it - in fact they make it clear it shouldn't be
done.
Don't assume "that's how everyone does it"
If consultants had a pound for every time they'd been told "our payroll
is just like everyone else's", they'd have a lot of pounds. Whilst
there shouldn't be too much doubt about the major statutory issues,
there are many variations on pension scheme rules, and calculation of
hourly rates (just two examples).
In addition there are two different (and acceptable) ways of calculating
NI on advance payments and many variations of how NI can be levied on
gifts.
Do plan carefully
If you are implementing retrospective processing, for example, take time
to plan and test so that you have devised procedures for all the
instances where you do/don't want retro to apply. This is particularly
important where, for example, you are implementing retro for the first
time.
Make sure you identify what processes are important - if you have a high
staff turnover, automated P45 production in accordance with your
business processes may be a high priority.
Do allow for the unexpected (and the expected) exception
When designing configuration, if you are trying to automate and
streamline a process (perhaps have the system calculate a rate of pay
based on a number of factors) try to think about circumstances where
there might be an exception. Who is allowed to override the calculation
and under what circumstances? We learned that building rules exactly as
described by users almost always results in a later request for a change
to allow for "special cases".
Migration - Get the data from the system of record.
Example - If you are running a bureau system with a monthly feed of data
down to local enquiry systems, get the data from the provider's records,
not the local enquiry databases. Experience in this example proved that
the local enquiry databases hadn't been kept fully up to date and NI
data was missing.
Even though bureaux and similar providers sometimes charge per payslip,
the costs and complexity of processing are related to issue like the
numbers and complexity of payments and deductions, the reporting and
interface requirements, employee turnover and accuracy and timeliness of
data recording in the organisation. This is why reports and interfaces
are usually additional to the costs of bureau processing.
A software solution cannot, of itself, correct poor business processes.
If, for example, parts of the organisation are accustomed to not
reporting the fact that some one has left or joined the organisation
until weeks or months after the event, this will result in extra work
for payroll, regardless of any computer system that's in place. Any
system that attempts to provide an automated solution to issues of poor
process is likely to be expensive, complex and disappointing.
End user training.
* Make sure end users have received enough training to be
confident in the operation of the system
* Make sure the training covers details of procedures required in
order to achieve various results in payroll (e.g. how to process
backdated/retro changes, how to make corrections, etc)
Experience of projects where this isn't done shows end users (quite
reasonably) try to perform actions in the same way they have done on
previous systems; then blame the system when the results are not what
they expected.
Don't assume you know and understand the scope and functionality of the
new system until you do!
Don't assume a particular function either exists or operates in a given
way until you've checked.
Don't assume that because a piece of configuration is delivered it will
meet all your needs until you've checked.
Don't assume that functionality in the new system will be the same as
the old.
It definitely won't. Even if they have identical capabilities, results
will be achieved in different ways - at the very least input screens or
pages will look different.
Don't assume the legacy system is always correct.
We have seen examples of legacy systems that have been calculating
payments or deductions wrongly for years.
Don't assume current practises are correct/legal
We were recently asked how to set up the system to process mid-period
changes to NI category codes and calculate each part period using the
appropriate code. The system doesn't support this process because the
NI rules don't require it - in fact they make it clear it shouldn't be
done.
Don't assume "that's how everyone does it"
If consultants had a pound for every time they'd been told "our payroll
is just like everyone else's", they'd have a lot of pounds. Whilst
there shouldn't be too much doubt about the major statutory issues,
there are many variations on pension scheme rules, and calculation of
hourly rates (just two examples).
In addition there are two different (and acceptable) ways of calculating
NI on advance payments and many variations of how NI can be levied on
gifts.
Do plan carefully
If you are implementing retrospective processing, for example, take time
to plan and test so that you have devised procedures for all the
instances where you do/don't want retro to apply. This is particularly
important where, for example, you are implementing retro for the first
time.
Make sure you identify what processes are important - if you have a high
staff turnover, automated P45 production in accordance with your
business processes may be a high priority.
Do allow for the unexpected (and the expected) exception
When designing configuration, if you are trying to automate and
streamline a process (perhaps have the system calculate a rate of pay
based on a number of factors) try to think about circumstances where
there might be an exception. Who is allowed to override the calculation
and under what circumstances? We learned that building rules exactly as
described by users almost always results in a later request for a change
to allow for "special cases".
Migration - Get the data from the system of record.
Example - If you are running a bureau system with a monthly feed of data
down to local enquiry systems, get the data from the provider's records,
not the local enquiry databases. Experience in this example proved that
the local enquiry databases hadn't been kept fully up to date and NI
data was missing.
Wednesday, 20 January 2010
Using setup manger to generate a GP task list
Setup Manager can be used to generate task lists for the configuration of modules or particular business processes.
This module replaced the old table loading sequences from v8.9 on.
Once generated, the task list identifies the task, menu navigation and any CI associated with the data load. It also has a hyperlink to the page where the data is entered and a place to record the task assignment, start finish dates, % complete and notes. There’s an option to download to Excel or in XML format too.
1. Need to ensure user profile has correct roles – only those with PTLT_PROJECT_MGR can create projects.
2. You can then create an implementation project – by product –
You can select products and untick any parts of the standard product setup you don’t need from the detail listing. When complete – save and click generate tasks.
This submits a job to process scheduler – when complete the “view setup tasks” button is available –
The results appear on a page with three tabs:
Subscribe to:
Posts (Atom)