Distributed Transaction Entry and Approval

July 29, 1991
W. David Wimberly

Table of Contents

Distributed Transaction Entry and Approval
  • Functional requirements/objectives
  • Technical objectives
  • Questions

  • 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 electronic approval. 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.

    Functional requirements/objectives

    1. 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.

    2. Use of the distributed entry system should, in most circumstances, eliminate paper documents.

    3. 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 required approvals.

    4. Use of the distributed entry capabilities should be optional for an office. Via security definitions, the controlling office (data custodian) can be defined to enter another office's transactions.

    5. Allow the transaction to be rejected or stopped at any approval level. An audit trail of the transaction should be retained.

    6. 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 transaction.

    7. Allow reviewers to be designated for a transaction so that they may view and add comments, but not approve it.

    8. Final approval and processing of a transaction should be allowed to be held pending the receipt of back-up materials (paper work).

    9. Restrict access to transactions to those in the approval chain or to the data custodian.

    10. 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.

    11. 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.

    12. 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).

    13. Allow the data custodian to effect the transactions online, as they are reviewed and accepted. This office essentially has final approval authority.

    14. 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.

    Technical objectives

    1. 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 redundancy.

    2. 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.

    Questions

    1. Should changes be allowed to be made to the approvers of outstanding transactions?

    2. Should approval at each level be performed by one or by any one of several individuals?

    3. Is approval responsibility transferable to a another individual, if so in what circumstances? By whom?

    4. 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)?

    5. Should an approver be allowed to modify any (or selected) information within the transaction?

    6. Are multiple approvals needed at a given level, or can the approvals be structured into a single threaded chain?

    7. Should approvals be allowed out of sequence, or required to take place at the 1st level before appearing at the 2nd?

    8. Should the "encumbrance" of funds be considered at some point prior to the final posting of the transaction?

    9. Should future and past "effective" dating of transactions be addressed by the entry/approval system or be specific features of each application transaction?

    10. Is there a need for a "confidential" classification to be associated with a transaction and how would it be handled differently.