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.

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!