| Hijacked Fields | KEVIN RESCHENBERG
05-31-2006 |
I ran across a minor data mystery the other day.
An obscure field was found to contain a
numeric code, although it would have been expected
to contain letters instead. Opening up the translate
values, I found that they were indeed numeric
codes but they didn't seem to have anything to do
with the expected purpose of the field. Also, what
appeared to be the original (PeopleSoft-delivered) translates
had been inactivated.
I started to go through a series of searches to
find how this field was used.
Luckily, one of the people from the functional team
knew immediately what was going on: the field was
originally unused, so it had been taken over for
a custom purpose. It had been "hijacked."
This is a fairly common situation, but usually not
a good idea. It may be true that your company will
never use a particular field for its original
purpose. So why not take it over for custom use?
First, doing this requires you to review the current
use of the field to be sure that no unexpected
side effects will occur due to delivered code. When
a new update is released, changes in the delivered
code could cause new side effects. And even though
your documentation is, of course, extensive and
up to date, how would an unfamiliar user (such
as myself, a consultant) know to look at it for
this field? Does it really make sense to use
the NUMBER_OF_WIDGETS field for your sales
commission percent?
It would take much less work in most cases to
add a new custom field rather than doing all of
the necessary research around an existing
delivered field. Adding a field to a table is
not a major operation. (There are a few tables
that are maintained by COBOL programs in the PeopleSoft
HRMS/HCM product, and so adding a field requires
you to update COBOL and/or the stored SQL statements.
These situations are rare and you would probably
never run into them. If you do, you'll know
immediately.)
If you want to avoid creating a new field just
because you can't face the prospect of filling
out all that paperwork, then you need to fix your
process. But that's another topic...
Some people feel that we should avoid creating
custom objects unless absolutely necessary. This
is generally not a good way to approach a problem.
Sometimes avoiding customization results in more
work, more upgrade issues, and more
risk to your system, not less.
|
