June 8, 2000
Codes Herded In
You think you have every code accounted for, and a new one raises its
head. As we get deeper into our integrated system implementation, the
hazards of "best of breed" systems development - the only option until
recently - become increasingly apparent, as do the mirrored benefits of
an integrated system.
"Over the years, each unit has independently
added bits of information to their systems to satisfy reporting requirements
from the federal government, the state, the University, the school, the
department, the division - maybe even the individual," marvels Bill Randolph,
ISP Project Director. "Many of the current codes do not map to one another
in any logical manner. The Oracle applications are forcing a disciplined
approach to the relationship of one code to another. That is the essence
of an integrated system." While last month the
codes in question had to do with organization, this month the project
is reining in object codes, dividing the herd into revenue object codes,
expense object codes, and balance sheet object codes, and then culling
the weaker, aged, no-longer-useful, or redundant codes and putting them
out to pasture. This work will be in draft form for a while and, once
made final, a mapping table will constructed that will contain the current
codes and their relationship to the revised list of codes. This will be
useful when people are preparing comparative analyses.
No current code is being culled without the consent
of its creator or a duly appointed representative. The process is anticipated
to reduce the total number of object codes from 1,800 to less than ˝ that
Final Structure Set for Chart
of Accounts and PTAEO
One of the key factors in the decision for the University to go Project
Centric was that it would free the general ledger to do what it was
intended to do: manage the general accounting requirements of the institution.
This is in contrast to what it has evolved to do because there has been
no alternative: accommodate the reporting needs of individual units.
The ISP Executive Committee has just approved
a structure for the general ledger chart of accounts and for what will
be our funds management tool, the PTAEO, thus dividing institutional accounting
from project management. The two are tightly integrated so that the funds
management information will roll up to the general ledger for institutional
reporting, as follows: (print for better legibility)
That translates from today's world as: (print for better legibility)
For more detail on the account structure of the general ledger, click
For more detail on the segments of the PTAEO, click
The functional teams have moved from paper and planning to placing hands
on keyboard and setting up the Oracle applications for use at UVa. Sufficient
steps have been completed to demonstrate, to a limited degree, the functionality
of the applications: how set up a customer, complete a transaction, and
run a report in Accounts Receivable; how to create a project and award
in Funds Management; and how to open and close a period, create a new
object code, post a journal, and run a report in General Ledger.
"Now is the fun part," exclaims Brenda Boyd of
the General Ledger team. This fun is also hard work, however, since every
one of the hundreds of set up steps requires decisions regarding how to
best suit the needs of the University. Team members will be consulting
with subject matter experts throughout the process.
Team Grows Up Fast
Team Lead Gary Nimax jokes about how his team acronym, POAP-OE/INV, just
rolls off the tongue. But, so far, his team's progress is nothing less
The Purchasing/Accounts Payable Order Entry/Inventory
team has spent the past month in the magical world of "if we could have
everything we would want, the system would…," defining the requirements
of the future system. Now they are coming back to Earth as they examine
what the Oracle applications can do and which requirements are wishes
"I expect excellent functionality from the applications,"
says Nimax, "though we may have to sacrifice a couple of our 'in a perfect
If any team had to begin late, POAP was a good
one, says Bill Randolph. "The application is mature, and the processes
are relatively standardized from industry to industry."
and Center -
All Internal Service Providers
On July 3, 2001, everyone at the University who does internal billing
must be prepared to accept PTAEOs as their payment instructions. As a
result, we are currently identifying all internal service providers so
we can provide them with the information they need to make the transition
in a timely manner. ISP advisors are assisting in this effort, armed with
a list of all units and accounts that processed an IDT over the past year.
If you are or know of any internal service providers who may avoid detection,
please notify Bill Randolph at 3-0346.
Team Preparing to Receive the Baton
As the functional teams push to complete the working
prototype and pass the baton to the technical team for the build and
test phase of the implementation, the technical team is getting in position
to receive it in stride. Team members are installing development
instances; the tools are in place to facilitate interface, conversion,
report development, and testing work; and additional technical staff is
being hired to sustain the pace set by the functional teams.
"We're getting there," reports Virginia Evans,
ISP technical lead. "There's a lot for the technical folks to do before
the end of July, but that pales next to what comes in the build and test
phase. That's when the adrenalin will be flowing."
to ARCHIVED ISP NEWS DIRECTORY
functional teams have moved from paper and planning to placing
hands on keyboard and setting up the Oracle applications for use