A debate at work prompted me to realise that not everyone is up to date with the HMRC regime - what it did, what it does and who's invloved.
Up until 6th April 2012, Payroll Software providers could use test data from HMRC to run payroll calculations and have the results verified by HMRC. Those able to prove the calculations correctly were awarded an accreditation from HMRC and could advertise the fact using a special logo and were listed on the HMRC website.
This scheme has now been retired and replaced with a scheme to accredit suppliers able to make RTI submissions.
Just to be clear - although many suppliers chose to gain the accreditation it was never a legal requirement, and I know of several perfectly competent suppliers who never bothered.
Postings based on 20 years battle-tested Payroll and ERP implementation experience
Wednesday, 12 September 2012
Wednesday, 5 September 2012
5 ways to save Payroll Costs
Don’t do it –
For anyone needing help and advice on any aspect of performance on a PeopleSoft Oracle Database, I highly recommend David Kurtz. One of the principles Dave espouses is (I forget who the source is now) that the single best way to reduce complexity and improve performance is not to do something.
In other words, rather than spend stacks of time and cash creating some hideously complex edifice to carry out calculations in support of a highly complicated payment or deduction – always consider not doing it at all by changing the business process.
Complex payments/deductions
The suppliers of many systems trumpet (with justification) that they can address the most labyrinthine of calculations.
This reminds me of being a young man and marvelling how many car insurance companies advertised they were keen to take on young drivers, even with fast cars. I thought this was wonderful because everyone had been telling me it would be hard to get insurance. What I had missed was that the reason all these outfits were so eager was the huge amounts they wanted to charge me.
Even if you think you can configure the system pretty easily – don’t underestimate the amount of administration that you might need around complex payments and deductions – this may involve the Employee, Manager and HR and Payroll – all of it is non-productive admin.
Don’t report/interface for others
Don’t do stuff for other parts of the business at your time/expense
I’ve lost count of the amount of times Payroll departments have had their implementation project hijacked (usually by finance). Sometimes another business area sees a payroll project as a good way to get some of the things they’d like but don’t have the budget for.
Up to a point of course, Payroll has a responsibility to support the rest of the business, but when this begins to extend beyond what’s reasonably expected in order to pay people, questions need to be asked about who is paying and who has a business case.
Don’t automate
The temptation is to try and automate laborious processes - but wait! If the code/config is costly and the justification dubious, you are just creating something else you need to document and maintain that is costing you, not saving you, even if the Payroll folks are happy because they've dodged some boring work.
Don’t offer
Don’t offer to split net pay between multiple accounts for payees if you don't have to - again it's an overhead in admin you don't need. Many people have online banking these days so they can manage their complex affairs on their own time.
Write it down
Document payment rules so you can be consistent and avoid costly litigation.
Tuesday, 3 July 2012
RTI - Updated technical packs
Update to EDI technical packs for 2013/14 Real Time Information submissions, to apply from April 2013
Tuesday, 24 April 2012
On configuration, customisation and work estimates
Working on a particularly tricky bit of configuration led me to consideration of a few issues.
Configuration
Because customising systems brings cost accountants (and others) out in a cold sweat, we’ve all learned to prefer configurable systems. Great in theory, and fabulous where we’re dealing with data and rules which are a known quantity – for example, addresses (I know there’s a few years debate to be had on that but bear with me).
However, for more complex business rules and workflows there’s a point where the distinction is more blurred. Sure, configuration of the rules means you can realistically expect that they will work when you get a new release of software; but you’ll still need to determine if the new release allows you to improve the configuration you have.
It’s true that your config lives in metadata, but when you get into the more involved business rules (payroll calculations, absence rules), yours are likely unique. Even if two organisations have identical rules, the flexibility of the system may have allowed them to get the same results by two totally different routes in config. Some of this configuration is in fact tantamount to custom code – it just lives in a more controlled environment.
So what’s the point?
Well there are two really One is about the permanent battle I have with trying my best to provide estimates for initial config and changes to calculation rules. And the other is about the differences between customisation and configuration.
On the first point – give some thought to this Are our rules complex? Most organisations tend to answer no to this, most are wrong.
Are our rules unique? As above, Most organisations tend to answer no to this, most are wrong.
Who else uses this software and have they done this already? Did they have help? Who from? The more complex and unique the requirements, the fewer other users and smaller the talent pool of configurers, the more unpredictable the implementation or change process will be.
It will be harder, even for a highly experienced person to estimate work that they haven’t done before. On the second point – don’t assume that the word “configuration” is an automatic route to pain-free implementation and maintenance.
If the system you buy/use has functional limitations that a clever config expert can work around to make your rules and calculations work, that’s great, but it’s not that distant from custom code.
Configuration
Because customising systems brings cost accountants (and others) out in a cold sweat, we’ve all learned to prefer configurable systems. Great in theory, and fabulous where we’re dealing with data and rules which are a known quantity – for example, addresses (I know there’s a few years debate to be had on that but bear with me).
However, for more complex business rules and workflows there’s a point where the distinction is more blurred. Sure, configuration of the rules means you can realistically expect that they will work when you get a new release of software; but you’ll still need to determine if the new release allows you to improve the configuration you have.
It’s true that your config lives in metadata, but when you get into the more involved business rules (payroll calculations, absence rules), yours are likely unique. Even if two organisations have identical rules, the flexibility of the system may have allowed them to get the same results by two totally different routes in config. Some of this configuration is in fact tantamount to custom code – it just lives in a more controlled environment.
So what’s the point?
Well there are two really One is about the permanent battle I have with trying my best to provide estimates for initial config and changes to calculation rules. And the other is about the differences between customisation and configuration.
On the first point – give some thought to this Are our rules complex? Most organisations tend to answer no to this, most are wrong.
Are our rules unique? As above, Most organisations tend to answer no to this, most are wrong.
Who else uses this software and have they done this already? Did they have help? Who from? The more complex and unique the requirements, the fewer other users and smaller the talent pool of configurers, the more unpredictable the implementation or change process will be.
It will be harder, even for a highly experienced person to estimate work that they haven’t done before. On the second point – don’t assume that the word “configuration” is an automatic route to pain-free implementation and maintenance.
If the system you buy/use has functional limitations that a clever config expert can work around to make your rules and calculations work, that’s great, but it’s not that distant from custom code.
Tuesday, 17 April 2012
How is PS Global Payroll formula metadata stored?
There are two main tables
PS_GP_FORMULA and
PS_GP_FORMULA_DTL
The DTL record has a row for each line of the formula.
There are a few useful things you can do in Query or SQL – like finding which formulas reference a given element, or looking for where a particular error/warning is called from (as in this bit of SQL I begged off a person of superior intellect):
SELECT
B.PIN_NM,B.DESCR,A.PIN_NUM,A.FRML_FLD2_DEC_VAL,A.FRML_FLD1_DEC_VAL,Z.FRM
L_FLD2_DEC_VAL,Z.FRML_FLD1_DEC_VAL
FROM PS_GP_FORMULA_DTL A ,PS_GP_FORMULA_DTL Z ,PS_GP_PIN B
WHERE A.PIN_NUM = Z.PIN_NUM
and A.EFFDT = Z.EFFDT
AND A.PIN_NUM=B.PIN_NUM
AND ((A.FRML_FLD2_DAT_TYP='4'
AND A.FRML_FLD2_DEC_VAL='301')
OR
(A.FRML_FLD1_DAT_TYP='4'
AND A.FRML_FLD1_DEC_VAL='301'))
AND((Z.FRML_FLD2_DAT_TYP='4'
AND Z.FRML_FLD2_DEC_VAL='21008 ')
OR
(Z.FRML_FLD1_DAT_TYP='4'
AND Z.FRML_FLD1_DEC_VAL='21008 '))
(The references to 21008 and 301 need to be amended with the appropriate message set number and message as appropriate)
You can also (if you are brave and have suitable access), do some manipulation of the formula content.
There is a vague rumour that PeopleSoft had an in-house text based editor for GP formulas at some point – but they were too frightened of it to allow it out into the wild. It would be great if some enterprising technical person could write something one day – but it will probably never happen. Even an AppEngine that could take a text file as input and parse it into appropriate formula rows would be good and would speed up creation and amendment of formulas immensely. Oh well – I can dream.
Most times if you are making changes, you will want to start out with the last version of the formula you had – however, you may wish to “rip and replace” – which you can do with SQL like this (or similar)
delete from PS_GP_FORMULA_DTL where PIN_NUM =101283 AND EFFDT ='2012-01-01 00:00:00.000' AND SEQ_NUM5 >1
Warning – don’t use this unless you really know what you’re doing and don’t come crying to me if you’ve destroyed the only copy of that 4000 line formula you wrote – you have been warned!
PS_GP_FORMULA and
PS_GP_FORMULA_DTL
The DTL record has a row for each line of the formula.
There are a few useful things you can do in Query or SQL – like finding which formulas reference a given element, or looking for where a particular error/warning is called from (as in this bit of SQL I begged off a person of superior intellect):
SELECT
B.PIN_NM,B.DESCR,A.PIN_NUM,A.FRML_FLD2_DEC_VAL,A.FRML_FLD1_DEC_VAL,Z.FRM
L_FLD2_DEC_VAL,Z.FRML_FLD1_DEC_VAL
FROM PS_GP_FORMULA_DTL A ,PS_GP_FORMULA_DTL Z ,PS_GP_PIN B
WHERE A.PIN_NUM = Z.PIN_NUM
and A.EFFDT = Z.EFFDT
AND A.PIN_NUM=B.PIN_NUM
AND ((A.FRML_FLD2_DAT_TYP='4'
AND A.FRML_FLD2_DEC_VAL='301')
OR
(A.FRML_FLD1_DAT_TYP='4'
AND A.FRML_FLD1_DEC_VAL='301'))
AND((Z.FRML_FLD2_DAT_TYP='4'
AND Z.FRML_FLD2_DEC_VAL='21008 ')
OR
(Z.FRML_FLD1_DAT_TYP='4'
AND Z.FRML_FLD1_DEC_VAL='21008 '))
(The references to 21008 and 301 need to be amended with the appropriate message set number and message as appropriate)
You can also (if you are brave and have suitable access), do some manipulation of the formula content.
There is a vague rumour that PeopleSoft had an in-house text based editor for GP formulas at some point – but they were too frightened of it to allow it out into the wild. It would be great if some enterprising technical person could write something one day – but it will probably never happen. Even an AppEngine that could take a text file as input and parse it into appropriate formula rows would be good and would speed up creation and amendment of formulas immensely. Oh well – I can dream.
Most times if you are making changes, you will want to start out with the last version of the formula you had – however, you may wish to “rip and replace” – which you can do with SQL like this (or similar)
delete from PS_GP_FORMULA_DTL where PIN_NUM =101283 AND EFFDT ='2012-01-01 00:00:00.000' AND SEQ_NUM5 >1
Warning – don’t use this unless you really know what you’re doing and don’t come crying to me if you’ve destroyed the only copy of that 4000 line formula you wrote – you have been warned!
Wednesday, 26 October 2011
CMEC Changes
The changes CMEC is demanding from payroll software providers have now reappeared on their website.
Oracle said at a previous UK user group meeting that the Court Order Functionality in PeopleSoft GP will be rewritten in 9.2, but these changes are required prior to that.
Oracle, PeopleSoft and RTI
Oracle held some meetings with customers on their approach to RTI during October. If you are a PeopleSoft GP customer in the UK or using UK extensions, I hope you were able to get along and hear the word.
Subscribe to:
Posts (Atom)