TARGET Concepts

Draft: August 1, 1994
W. David Wimberly

Table of Contents

TARGET Concepts
  • What is TARGET?
  • Why do we need electronic transactions?
  • How does TARGET process changes?
  • Do others know when there is a change pending?
  • Can there be more than one TARGET change per entity?
  • How can I view information about non-pending TARGET transactions?
  • How is TARGET processing implemented in LEAVE?
  • How is TARGET processing implemented in GJIM?

  • TARGET Concepts

    This is a short paper intended to communicate basic concepts and principles related to TARGET, the University's integrated electronic transaction processing facility. It is directed toward anyone desiring additional information about TARGET and specifically those seeking an understanding of why TARGET processing functions operate the way they do. It takes a broad perspective and provides the rationale for the overall design of TARGET processing. In addition, it explains the specific approaches taken to implement TARGET processing in LEAVE and GJIM. It is not intended as an independent reference regarding TARGET, but must be used in conjunction with application documentation and other reference materials such as the TARGET Proposal, the paper "TARGET - Integrated Electronic Transactions" presented at CAUCUS '94, and the TARGET Functional Specifications.

    What is TARGET?

    TARGET is a set of facilities that provides integrated electronic transaction processing from within the University's administrative information system. It is the means by which our applications have been expanded to To accomplish this, changes are stored as TARGET transactions which, when pending approval, are automatically presented on screen side by side with current application data. In spite of these added capabilities, for consistency TARGET functions have been designed to operate as much like standard non-TARGET functions as possible.

    Note: The term change is used here to refer to any alteration of data that is needed within the information system. This may mean the creation of new information (the Add action), the modification of existing information (the Update action), or the deletion of information (the Delete action). Such changes are often discussed in terms of adding, changing, or deleting records on the data base. TARGET transactions are always requests to perform some change.

    Why do we need electronic transactions?

    Electronic transactions save everyone time and effort since they are more efficient to process and easier to locate than paper documents. Prior to TARGET, applications were developed in a traditional manner using online maintenance functions: existing data was presented, the operator typed over fields he desired to change, the program edited the data, and if everything was valid the data base was updated in real time. In some situations, this access was restricted to appropriate subsets of data using value based security. However, many changes require approval by numerous individuals and this approval cannot be obtained using this model. Historically, the method for effecting these changes was to provide a central data entry operator with a form which has been appropriately authorized via the proper signatures. The form must be initiated, traverse the campus receiving the proper signatures, and end up in the central office responsible for the application so that the data can be entered and the update effected. These were time consuming and labor intensive steps. More importantly, the data on the form may be unacceptable to the information system since it had not been subjected to the stringent validations enforced at the point of data entry.

    With TARGET, paper forms are eliminated and information system changes are captured and edited at their point of origin (or as close as possible to that point), yielding tremendous cost and time savings.

    How does TARGET process changes?

    With TARGET, a change is initiated within the application in the same manner as traditional maintenance -- even though there are separate approvals required before the change can be effected. The screen used to enter the change appears the same as any other maintenance screen: new fields may be entered or existing values changed and subsequent data validations are performed on that input. However, TARGET functions provide before and after images for each modifiable field. The before image is non-display until a change has been made. Once the user changes a modifiable field, the corresponding before image of the field is displayed with user selectable attributes (the color as well reverse video or underline settings may be chosen). This makes it very easy to see what is being changed. Once the initiator commits the request for the change by pressing PF10, the system confirms the creation of the TARGET transaction identifying the change via the message line ("Txn created for ..."). Behind the scenes, the appropriate reviewers for the transaction are established based upon predefined rules for that function in conjunction with the contents of the data being operated on, and the transaction is placed in the state of pending approval.

    Note: Maintenance screens used for TARGET and non-TARGET functions are not only made up of modifiable fields where changes may be keyed, but also include protected fields used to display current information. Any given screen may have more or less of either type of field. In this manner, a screen normally used to perform some maintenance function may also be very useful for inquiry purposes. For example, the xxTP functions of GJIM show mostly document information in conjunction with the TARGET change, which is merely a change of status for the document.

    Do others know when there is a change pending?

    Yes, TARGET functions automatically access and present information on pending transactions whenever the entity 1 affected by the transaction is referenced. This is done to ensure that the user is aware and has knowledge of pending changes, since this information could be beneficial to anyone inquiring into the information system. In addition to displaying the before and after images of the modified fields, a transaction status line appears which shows that a TARGET transaction is being displayed. This line identifies the requestor of the transaction, the date it was requested, the existence of any transaction comments, and the transaction status (P for pending transactions). This transaction status line overlays a portion of the delimiter line used to separate the banner of an NSM screen from the body of the screen. In addition, PF11 (Optns) becomes available when viewing a TARGET transaction. Via this key the operator may view the transaction reviewers' activity, view existing comments, or create a transaction comment.

    When a TARGET processing function is used to reference an entity for which there is no pending change, nor has a transaction been explicitly selected (as explained below), data about the entity as it currently exists within the information system is displayed. No TARGET transaction is involved in such an inquiry, and information about the entity is reported as it exists on the data base. The transaction identification line is not displayed nor is the PF11 (Optns) key available since no TARGET transaction is involved in the inquiry. In this situation, the TARGET function operates the same as any non-TARGET function.

    Can there be more than one TARGET change per entity?

    Yes, there may be numerous changes made to the same entity. However, TARGET functions permit only one pending change per entity. If a second change were permitted to be initiated while another change was pending, its creation and validation would have to be predicated upon the first change being accepted and approved before the second change. Addressing the processing associated with such a situation would add greatly to the complexity of the system. Therefore, the system only permits a change to be initiated if there is no currently pending change for the same entity.

    Once a pending or proposed change receives final approval it becomes effected and the information system is updated to reflect that change. There may be several effected changes for the same data base entity, each constituting a separate TARGET transaction. In addition to pending and effectedtransactions, there may be rejected and withdrawn transactions. A single entity may have any number of these types of TARGET transactions (other than pending).

    How can I view information about non-pending TARGET transactions?

    To view information about non-pending transactions, of which there could be many, you must first select a specific transaction. This selection may be accomplished using a list function that displays the desired TARGET transaction. LTRS (List Transactions by Requestor, Status and date) is one such function that is present in all TARGET applications. TARGET applications also provide additional list functions that display the TARGET transactions for the specific entity operated on by the TARGET function. Given the selection of a transaction 2 from any one of these lists, the TARGET processing command will directly access that TARGET transaction and display it complete with the transaction identification line and the availability of the PF11 Optns. The change requested by the transaction is also displayed where the modifiable fields normally exist and the existing data base values (when different) are displayed in the before 3 image fields.

    This requirement to select non-pending transactions in order to view them may seem inconvenient. However, it should be recognized that the current real data is always displayed via the TARGET process along with any currently pending transaction. This current information is what is needed to make business decisions. Normally, information about effected, rejected, or withdrawn TARGET transactions is of little importance other than as an audit trail of past activity. An exception is the need for a requestor of a rejected TARGET transaction to read the comments that were entered by the reviewer at the time of rejection. This and any other auditing of past transactions is provided via the explicit selection of the desired transaction to be examined.

    How is TARGET processing implemented in LEAVE?

    Leave's TARGET implementation is different for each of its two TARGET functions.

    1. The MB (monthly balance adjustment) function is a straightforward TARGET process. Adjustments to leave balances are keyed over old values and the prior values appear to the right of the new proposed adjustment amount. The same applies to the note that is required when entering an adjustment except that the existing note is displayed below the proposed value. It is important to also realize that many adjustments may be entered for the same employee and month. This is an example of a simple TARGET function.

    2. The OTA (overtime approval) function was designed to record the approval of all overtime entered for a budgetary unit and month. 4 The entity operated on is the data base record of this approval; therefore, when it exists the overtime has been approved. Since the initial state is that overtime has not been approved, the only possible change is to create this record. In essence, the TARGET transaction is a request to add this record to the data base. To make this operation easier to understand, the action used to perform this step is S to represent the submission of the overtime for approval. There is never an update of existing data by this function, so there are no before and after fields on the screen. There is a provision for deleting overtime approval, once obtained. This is requested using action D and, once final approval is obtained, results in the deletion of the approval record. (Without that record of approval, the unit's overtime for that month will not be sent to MSA to be paid.) This may result in two effected TARGET transactions for the approval of overtime for the same budgetary unit and month, with the requested deletion occurring in between.

    How is TARGET processing implemented in GJIM?

    The creation and manipulation of GJIM documents is very complex due to their line orientation and the number of lines permitted. The processing requirements to support these maintenance functions were such that there was little room left to incorporate TARGET processing features on top of these other facilities. In addition, there is no need for the before image display, because once a document is submitted for approval it can no longer be changed. (If implemented in a pure TARGET sense, GJIM documents would have been like LEAVE's OTA: always a request to add a document.) For these reasons, and the sake of data entry flexibility and programming simplicity, the maintenance of documents was separated from the approval of documents, and corresponding xxM (maintenance) and xxTP (TARGET processing) functions were created.

    Note: The terms document and transactionare used in a very precise manner since there is a significant difference between the meaning of the two words in GJIM. Document refers to the entity created by the user with the xxM function. It represents all the details necessary to describe the desired adjustment that is being sought within the GL system. Transaction, or TARGET transaction, refers to the request for a change to the document's status and how that request was acted upon. Information about the TARGET transactions is only available through the xxTP, TARGET Processing, functions. However, the xxTP functions also provide facilities for viewing entire GJIM documents. As such, they are on the main menu and users are encouraged to use those functions over xxMs unless they need to perform maintenance on documents.

    To provide for the necessary management and control of documents, a document status was created. 5 This document status is in some cases automatically changed by the system to reflect the user's request for approval or to reflect other actions taken on that request. Documents are created with a status of open. Only open documents can be updated by the xxM maintenance functions. Once completely built and visually inspected for accuracy, documents are submitted (action S) for approval using xxTP, which is the TARGET processing function for GJIM. At this point, several unique special processes have been incorporated to manage GJIM documents.

    There is one additional variance to standard TARGET processing that was introduced in the GJIM IITP function: it permits the Reviewers to change the Account numbers on a pending transaction. The Account numbers being changed are part of the TARGET transaction. If viewed later, the changed values appear as if they were part of the transaction as it was originally requested. Furthermore, once the transaction becomes effected there is no record of the original Account numbers since at that time the values on the TARGET transaction and the document match. In this situation, there are valid reasons for permitting reviewers to change this specific portion of a TARGET transaction, but it is an exception to the rule.

    The GJIM variances to normal TARGET processing noted above were incorporated to address specific problems or to simplify processing for the user. However, learning this specialized implementation is difficult without a basic understanding of normal TARGET processing. Once familiar with basic TARGET concepts, it is much easier to understand GJIM, since it really does fit the model -- it just adds a few twists of its own.


    The term entity is used to generically reference the set of related information being accessed and changed via a TARGET process. Current examples include a GJIM document (identified by a type, fiscal year, and document number), an overtime approval (identified by a budgetary unit and month), and a leave balance adjustment (identified by an SSN and month).

    There is no visible identifier for a TARGET transaction, and thus no key field displayed from within the list that is moved to the banner. However, there is a unique internal identifier which is being used and passed from the selection made on the list to the TARGET processing command.

    The screen attribute setting for the before image fields is labeled as "previous value" on the User Profile. This is a poor name for this attribute, as is referring to it as a before image, both of which assume the perspective of looking at a pending transaction that is presumed to be approved. A true name and description for the fields displayed with this attribute would be current or existing data base values, as opposed to the transaction values which differ.

    The use of OTA requires that overtime has been entered previously for each employee using EXTM. The approval of overtime for all employees within a budgetary unit with one TARGET transaction is done to simplify and speed up the process, since there is always a pressing deadline for receiving this approval.

    An additional confusion factor in GJIM is related to the fact that there is a GJIM document status and a TARGET transaction status, and both are displayed almost side by side. Adding to this is the fact that the document status is what is being changed, so there is the document status from the transaction and the document status from the data base. Again, all three are displayed within close proximity. To help alleviate the confusion, special labels and decodes have been provided for the document status fields.