Greetings online friends

I had a discussion last week with a payroll funky here at W-D, which reminded me of an issue I had encountered in my past life at the Big 'O' - one of many encountered during the infamous 'Fat Boy Bloater Snacks' payroll implementation (based at the even more infamous Crispy Towers, Theale, Berkshire) - wherein, for my sins, I was billed as the 'functional payroll lead'. No, I couldn't believe it either...

Well, here for your enlightenment and entertainment (you need to get out more if you find this drivel entertaining) is the story, with the workaround...

"> I casually mentioned (as you do) in our
> latest stream leaders meeting
> today that the problem with having multiple
> links on a salary admin element
> (which one might want to do if there are
> specific costing requirements) is
> that when an employee's eligibility shifts in
> such a way that the
> eligibility to the salary element entry is via a
> new link, the existing
> entry is end-dated, and is *not* reinstated
> automatically via the new link.
> One must instead revisit the salary admin
> screen, and repropose the existing
> salary, and then have it approved so as to pick
> up the new link criteria.
> Still with me???? OK. From trawling Metalink,
> this is evidently not a bug,
> but a feature (no, honestly, I'm not
> kidding!!!). So, my question is... has
> anyone else found a workaround to this issue,
> even if it did involve a
> customisation?"

Well, after a bit of head-scratching (which required the attention of some special shampoo to put right) we came up with this workaround...

"Dear all

I thought I had better send this quick before Del-Boy claims the glory

I think (ie still need to check) that we can get round this problem by:

1. Set up a single link (all payrolls) to the salary admin element.
2. In the formula results, send the resulting payment to an indirect informational element, which element may be costed as our crispy friends see fit.

End result -
1. Salary admin works to the obvious enjoyment of our HR contingent
2. Salary element is paid but not costed
3. Equivalent (ie the indirect) amount is costed but not paid (cos it is informational)

Can any payroll bods think of a reason why this would not work?"

In point of fact it did work, but for one reason only - by coincidence, the default costing of an informational element is the same as that for an Earnings element. We tried doing the same with PAYE and got into all sorts of problems because the costed values appeared on the debit side when they should have appeared on the credit side - or was it the other way around - I can't remember which. But I do remember it was wrong for deduction-type elements. It defo worked for Salary Admin though!

Hope this helps someone.


CT