Friday, 31 December 2010
Friday, 19 November 2010
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
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
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
a page to call instructional text (mainly in Self Service Pages) - as it was in this case.
Tuesday, 8 June 2010
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
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
Tuesday, 9 February 2010
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
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
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
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
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
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
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: