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
Sunday, 28 March 2010
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:
Tuesday, 8 December 2009
Who knows?
Sometimes you're going to find that no-one in the organisation knows (really knows) what the rules are for some things. Of course it may be better to keep quiet about this rather than make a big fuss, but you'll need a strategy for dealing with it.
How you do this will depend on the client - you have to find a way that suits them, their politics and so on.
How you do this will depend on the client - you have to find a way that suits them, their politics and so on.
Wednesday, 25 November 2009
Old Payroll Systems
In older payroll systems (and indeed many other systems) storage was at a premium so they couldn't do some things we can do easily now. One of these is manage transactions historically.
All the older systems tend to treat data items as having only a single dimension - only the current value is stored and anything that went before is lost (or hard to retrieve). This makes it easier to deal with, but ultimately less capable.
These days we can use the history of a range of data items to do more complex payroll calculations.
All the older systems tend to treat data items as having only a single dimension - only the current value is stored and anything that went before is lost (or hard to retrieve). This makes it easier to deal with, but ultimately less capable.
These days we can use the history of a range of data items to do more complex payroll calculations.
Monday, 23 November 2009
Payroll system Parallel Runs
When I started doing this kind of work in the early 1990s it was customary to run any new payroll system alongside the old one for a month or two to check the results were the same. It seemed a pretty sensible way to evaluate the system configuration.
Just have a think about how everything's changed since the early 1990s - Televisions, Radios, Cars, Computers - you can probably see where this is going.
Payroll systems are much more capable these days and they interact with a huge range of other systems too.
Now have a think about the world of work during that period (if you're old enough !) Consolidations, buyouts, reorganisations, redundancies and management pressures to do more with less have meant that people are often firefighting rather than thinking strategically.
Enter the parallel run - and imagine that the organisation has decided to spend a little on a new payroll system (in order to realise cost savings of course). Everything's been set up and along the way we've figured out that a few things aren't being calculated properly in the current system anyway. We clearly aren't going to design the same errors into the new system - which means they aren't going to agree.
Which is all a long way around to say that parallel runs are a little outdated these days - aside from the fact that for a "true" parallel requires people to do most of their work twice for the duration of the parallel - not an easy sell in a modern workplace (and I'm not sure it ever was).
Just have a think about how everything's changed since the early 1990s - Televisions, Radios, Cars, Computers - you can probably see where this is going.
Payroll systems are much more capable these days and they interact with a huge range of other systems too.
Now have a think about the world of work during that period (if you're old enough !) Consolidations, buyouts, reorganisations, redundancies and management pressures to do more with less have meant that people are often firefighting rather than thinking strategically.
Enter the parallel run - and imagine that the organisation has decided to spend a little on a new payroll system (in order to realise cost savings of course). Everything's been set up and along the way we've figured out that a few things aren't being calculated properly in the current system anyway. We clearly aren't going to design the same errors into the new system - which means they aren't going to agree.
Which is all a long way around to say that parallel runs are a little outdated these days - aside from the fact that for a "true" parallel requires people to do most of their work twice for the duration of the parallel - not an easy sell in a modern workplace (and I'm not sure it ever was).
Subscribe to:
Posts (Atom)