Distributed Transaction Entry and Approval
July 29, 1991
W. David Wimberly
Distributed Transaction Entry and Approval
The following are some ideas and considerations for how the university
may wish to provide for remote transaction entry and associated
The functional requirements identify features and operational
characteristics that I think would be desired.
The technical objectives are of a similar nature.
The questions are issues for which I do not see a clear answer.
- Plan for the use of position based security, to be implemented when
the supporting data is available.
Initially implement the system using user based security.
- Use of the distributed entry system should, in most circumstances,
eliminate paper documents.
- Via table definitions, have the system generate the approval
hierarchy based upon the transaction being processed, the specific data
involved (i.e. accounting distribution or organizational structure),
and the operator entering the transaction.
The dollar value associated with the transaction may also affect the
- Use of the distributed entry capabilities should be optional for an
Via security definitions, the controlling office
(data custodian) can be defined to
enter another office's transactions.
- Allow the transaction to be rejected or stopped
at any approval level.
An audit trail of the transaction should be retained.
- Allow comments to be attached to the transaction
by anyone in the approval chain.
These comments should be viewable by anyone that can access the
- Allow reviewers to be designated for a transaction so that they
may view and add comments, but not approve it.
- Final approval and processing of a transaction should be allowed
to be held pending the receipt of back-up materials (paper work).
- Restrict access to transactions to those in the approval chain or
to the data custodian.
- Provide a list function so an individual may view summary information
about all transactions which are pending their approval.
Additionally allow a similar list for a specific transaction and
a means to sequentially process (approve) those transactions.
- When entering and reviewing transactions that are of an update
nature (data entered will overlay existing attributes),
display the old and new values.
The changes made should be readily apparent, old (or new) values are
only displayed when different from the other.
- Do not allow multiple transactions of the same type to be
entered for the same entity (two address changes for the same
individual pending at the same time).
- Allow the data custodian to effect the
transactions online, as they are reviewed and accepted.
This office essentially has final approval authority.
- Provide a complete audit trail of all transactions and their
approvals including an
archive of all transactions.
Most recent transactions should be retrievable on-line.
- The same edits and validations for the transactions should be
invoked at the time of original entry and at the time of final posting.
These should be performed by the same program to minimize code and
- One system and design should be used for the management of
electronic approval tables and pending transactions,
regardless of the application employing distributed entry and approval.
- Should changes be allowed to be made to the approvers of
- Should approval at each level be performed by one or
by any one of several individuals?
- Is approval responsibility transferable to a another individual, if so
in what circumstances? By whom?
- Should the data custodian be allowed to bypass the approval cycle
and make direct updates that are otherwise effected through
distributed transactions (to make corrections)?
- Should an approver be allowed to
modify any (or selected) information within the transaction?
- Are multiple approvals needed at a given level, or can the
approvals be structured into a single threaded chain?
- Should approvals be allowed out of sequence, or required to
take place at the 1st level before appearing at the 2nd?
- Should the "encumbrance" of funds
be considered at some point prior to the final posting of the
- Should future and past "effective" dating of transactions
be addressed by the entry/approval system or be specific features
of each application transaction?
- Is there a need for a "confidential" classification to be
associated with a transaction and how would it be handled