Sorry, but your search for documentation yielded No Results.

There is not currently a document devoted specifically to
the function for which you requested information.

Use your browser's BACK button (or Click Here) to return to the previous screen.












Transaction Approval-Review Gateway via Electronic Transmission

TARGET

Hotz Hall
University of Arkansas, Fayetteville

Table of Contents

Introduction

Overview

Processes: "How-To"

Command Reference: Online Functions

Appendix A. General System Features

Appendix B. System Definitions

Approval Review Gateway via Electronic Transmission

BASIS Development Team

September 15, 1997

Introduction

Purpose of this Document

This document is meant to introduce concepts for the TARGET (Transaction Approval Review Gateway via Electronic Transmission) application. In addition to that general purpose, it is intended to provide a detailed reference for the on-line functions, as well as "how-to" guidelines at an overview level. These "how-to" sections are not detailed, step-by-step, keystroke-by-keystroke instructions, but are instead meant to supplement the command reference section by providing a synthesis of entire processes. They are a roadmap to the rest of the manual, especially the "Command Reference: Online Functions" section. These sections will hopefully aid the already experienced BASIS user in knowing which commands are used to perform what activities. See "Manual Sections" for further descriptions of the layout of the manual.

Manual Conventions

The following type/font conventions are intended to make this document more consistent, and easier to use:
  1. Field names (both in the banner and in the body of the screen) are identified in italicized type.
  2. Column headings or screen segments are also identified in italicized type.
  3. These field and column names appear in the exact format and spelling as you will see on-screen, although expanded definitions are often added, either as parenthetical notes or footnotes.
  4. Keys that you need to press in order to perform selected activities will appear in boldface type, as in: To save the transaction, press PF10.

Manual Sections

The heart of this manual consists of the following four sections:
Processes: "How-To" Brief overview documents intended to tell the user which functions to use to achieve a desired result, and a bit about how the functions work, especially in combination with each other. By linking specific functions with desired activities, this section tells you where to look in the "Command Reference: Online Functions" section of the manual for further information.
Command Reference:
Online Functions Breaks the system down into its single command components. Each command or function is described in a separate section. These sections tell the user:
  1. The "Purpose" of the command.
  2. Which "Key Fields" are required in the banner in order to utilize the command.
  3. Which "Actions" are valid (not included for lists since "Action" is not a "Key Field").

    Note: Both the "Key Fields Required in the Banner" and the "Valid Actions" are shown in easy-to-scan bullet point lists.

  4. Any field and/or system "Validations" which exist that will affect the user's processing of the command.
  5. Comments on how "Processing" of the command works.
  6. Any "Related Topics" which will increase overall understanding of the system and its inter-relationships.
Appendices General help topics ranging from more detailed system definitions, to tips on system usage, to explanation of concepts.
Glossary Brief definitions of terms and concepts used throughout the manual and within the system.

Overview

System Overview

TARGET, (Transaction Approval & Review Gateway via Electronic Transmission) is intended to provide state of the art electronic forms processing capabilities for the University of Arkansas. It provides direct transaction data entry into an application at the point of data origin. These remotely entered transactions are held in a pending state until appropriate reviews and approvals are obtained. Once final approval has been electronically obtained the transaction is posted to the data base within the University's administrative information system.

Note: A transaction as used within the TARGET system represents a request for a specific and independent activity to be performed within an administrative system. This is normally to add, delete or update information, but may take various forms as dictated by the application implementing the activity.

The TARGET system itself only provides a framework for this processing. The administrative applications employing TARGET must be designed and written with the intent of using this framework and in accordance with specific requirements. The University is fortunate to be at the initial stage of developing new applications in the human resource, budgeting, purchasing, and financial areas which will be able to take advantage of TARGET capabilities. The TARGET components assume that applications that use these facilities will be developed using the Natural Secured Menus Architecture (NSM) and the internally developed Program Generator.

Goals & Objectives

The objectives of the TARGET system can be summarized as follows:
  1. Provide a core architecture to facilitate the implementation of applications which utilize a distributed data entry function combined with centralized reviews and approvals of those activities in a secure and auditable manner.
  2. Employ this architecture in a generic manner such that it can be implemented in various administrative applications. This will result in:
  3. Meet the increasing demand for electronic forms processing with a system where:
  4. Implement these facilities using the Natural programming language within the applications development framework of the NSM Architecture, both of which are proven and established at the University.

System Features

TARGET offers numerous special processing features. Many of these are the result of the total integration of the original transaction entry and review processing with the base application which manages the resulting data. Some of the features, facilities, and resulting benefits provided by TARGET include:
  1. TARGET replaces the use of paper forms including the need to copy, file, mail, and process these forms. Electronic transactions replace forms, but contain the same information for directing actions and effecting changes within the administrative systems. This results in cost savings in the areas of copying, internal mail distribution, personnel time, and storage.
  2. Electronic transactions are available for review and approval immediately online, eliminating the time lag associated with handling paper. The benefits of more timely processing of administrative transactions are intangible and difficult to quantify, but are obviously highly desirable.
  3. The basic transaction data is entered at the point of origin and is not re-keyed by the administrative office responsible for the application. This reduces the data entry work load within the central offices. Within the originating offices, the data entry function replaces the manual entry or typing of the same information onto forms. The screens used to enter data are a part of the primary application and employ strict edits and validations, which results in more accurate, higher quality information. This improvement in the integrity of the data is one of the primary benefits of TARGET. Fewer errors will result in fewer corrections and reduce the number of times and the number of people that have to handle an item. This is expected to result in significant improvements in office efficiency and productivity.
  4. The ability to track and review the status of transactions is provided. Pending, completed, and rejected transactions are maintained in a data base and are available online for review for a period of time as defined for each transaction. Transactions may be listed by requestor and transaction status, by reviewer (pending transactions only), and by data base entity affected (this is dependent on, and varies by, transaction). This simple and rapid access to, and availability of, data is expected to reduce the number of inquiries made by departments to the central offices. This will save time both within the departments and within the office previously required to research those questions.
  5. Security definitions and the review process have been designed to operate based upon a desk concept rather than an individual's ID. These position based security and transaction routing definitions provide a significant advantage over individual based security in the administration area. When security is tied to an individual and that person is reassigned within the University, all their security (access privileges) and review (transaction routing) definitions must be reviewed and updated. Position based security is just that--all security definitions are tied to a desk associated with a job so that transfers and personnel changes do not necessitate mass changes within the system. Instead, the new person is assigned to the old desk and immediately given the appropriate access and authority. Desks are associated with departments who control the assignment of those desks to the employees of the departmnet. This scheme also allows one definition to service multiple individuals since several people may be authorized to work the same desk.
  6. The association of a transaction with the desks that are to be assigned the review responsibility is the heart of the electronic approval system. The TARGET system uses one central routine to make this determination for all transactions based upon the type of transaction and the data being acted upon within the transaction (referred to as the "review criteria"). This approach provides maximum control over the process while allowing flexibility since the maintenance and enhancement of this function is localized to one routine.
  7. An optional criteria for the establishment of the desks responsible for reviewing a transaction is the dollar value associated with the transaction. Different desks may be defined based upon this dollar value. This allows assigning review responsibility for some transactions based upon the spending authority of the desk.

    Note: The dollar value is not the primary criteria which is used to determine which desk should review a transaction. Those criteria are unique and specific to each type of transaction and are described generically within TARGET as "review criteria."

  8. Another aspect of the establishment of the desks required to review a transaction is exception handling. If, using tables established for this purpose, the system cannot determine the desks of the reviewers based upon the transaction data, a default set of desks may optionally be defined to be established. This will ensure that a transaction is not prevented from being entered due to missing control information.
  9. TARGET allows from 1 to 10 desks to be established for the review of each transaction, each assigned a review level. All approvals must be obtained at a lower level prior to the transaction being presented for review at a higher level. This will permit multiple individuals to review the same transaction at the same time while also holding a transaction back from review at higher levels until appropriate. Either or both options may be employed selectively.

    Note: The term "presented" is used to mean that a transaction will either appear on a transaction list for review or will automatically be retrieved for review according to its time of entry, based upon the identity of the reviewer and the desk they are working.

  10. Several features have been designed into the system to ensure that the review process is simple and effective.
  11. The edits and validations performed on the original transaction are invoked each time the transaction is reviewed and at the time of final posting. These consistent checks will help guarantee the integrity of the data within the University data base. Technically , these edits are performed by the same program each time, which minimizes code redundancy, the opportunity for programmer error, and the program maintenance effort when changes are required.
  12. A complete audit trail is maintained for all transactions by recording the date, time, and individual performing any action on the transaction. This includes the original entry, all review actions performed, and the final disposition. This history of the transaction and review process will be available online via a pop-up window displayed by a centralized routine. Thus, complete document tracking and status checking information will be available to the originator, the reviewers, and all others with access rights to the transaction.
  13. Transactions may have up to 12 comments associated with them. These short, electronic "stickies" may be entered or viewed by anyone associated with the entry or review process. In this manner explanations and references outside the actual transaction may be communicated between the originator, the reviewers, and the central administrative office responsible for the application. A comment will be required whenever a transaction is rejected during the review process. Comments, similar to the transaction history, will be available via a pop-up window managed by a centralized routine.
  14. Rejected transactions will require entry of a rejection code and a comment. In addition, a notice to the transaction originator is posted to a central data base file. These and other notices will be checked whenever a user signs on to Natural. The user is informed at that time of outstanding notices and each is displayed for their review and subsequent action.
  15. The TARGET system is built on the philosophy that a desk is identified to review selected transactions as determined by the central administration. The individual or individuals associated with that desk should be the ones that normally perform that function, and it must be their responsibility to fulfill that role. TARGET will establish the appropriate transactions with that desk's ID for review expecting that review to occur. However, there will be times when all reviewers authorized to work a desk are absent and someone else must be designated to act on behalf of at least one of those reviewers. In this circumstance the TARGET system provides a "proxy" facility. Other individuals may be predefined, for a period of time, to act as a proxy for a desk for specific applications. The system will maintain as part of the audit trail when and who was acting as a proxy when action was taken on a transaction. The establishment of proxies will be allowed by any individual directly authorized to work a desk, but that authority must also be granted to a system administrator to be used in situations involving illness or other unexpected absences.
  16. Existing transactions, either completed or canceled, may be copied and used as the basis for entering a new transaction. The original transaction must first be selected for viewing and then the keys for the new transaction and the copy action specified. This option may be used to enter several transactions that are nearly identical or to retrieve a canceled transaction so that it can be modified and resubmitted. (There may be situations where this feature cannot be provided due to the processing constraints of specific transactions.)
  17. Reports will be available to print all transactions of a selected type which occurred over a selected time period. This facility should assist in problem analysis and in meeting audit requirements.
  18. Transaction data is stored in a generic format on the central transaction file. This means that individual fields such a salary, grade, or department are not identified as such. Instead, the applications that process the specific transactions redefine the generic data area according to their specific requirements. It can be expected that the transaction contents and generic format may change over time for a transaction. Therefore the system retains a transaction version with each transaction so that the format and processing requirements of the transaction will always be known. This will assist in the transition from new to old during periods of change.
  19. The application functions used to view data will detect if there is a transaction pending for a data entity and will display the pending transaction information. It will also identify the originator and the date and time the transaction was entered. This means that the latest information will always be available, although the user must be aware that the transaction is still pending and has not received final approval.
  20. The TARGET administrator may request a list of transactions that have been pending review longer than considered normal. The number of days a transaction may be pending before being reported may be customized via online definitions for each type transaction. With this facility, the system can be monitored to ensure that transactions are not lost within the system.

Processes: "How-To"

The following pages provide brief step-by-step instructions in the maintenace of review criteria and review groups as well as the use of common TARGET lists. For more detailed validations, processing rules, as well as sample screen snapshots, please refer to the corresponding portion of the "Command Reference: Online Functions" segment of this manual (beginning on page xx).

Command Reference: Online Functions

RG - Review Group maintenance

Figure 1 is an example of the screen presented during processing of the RG function.

Figure 1. Data Entry Screen - RG


 Please enter new key fields
   Values decoded                                            RG   09/15/97 16:06
  Command:      Action: V Appl:           Crit Type:       Rev Desk:
  Rev Group: ACCT-1
 -------------------------------------------------------------------------------
  Action: V Review Group: ACCT-1
 
       Level  Desk ID    Desk Name                                 BU
        100   AEACUS     Accounting Chair                          ACCT
        200   HEBE       desk for CBA Accountant                   BADM
 
 
 
 
 
 
 
 
 
 
  Entered: 05/18/94 08:32 Updated: 06/03/97 15:10 By: SAFCSAK
                                                      Nancy C. Safcsak
 Enter-PF1---PF2---PF3---PF4---PF5---PF6---PF7---PF8---PF9---PF10--PF11--PF12---
       Help  Suspd Quit  DCode                   NextR

The following sections describe the Review Group maintenance function:

"Purpose"
"Key Fields Required in the Banner"
"Valid Actions"
"Validations"
"Processing"
"Related Topics".

Purpose

Key Fields Required in the Banner

Valid Actions

View {V}
Update {U}

Validations

The RG function employs the following validations:

Processing

Related Topics

Information on the following topics may be selected after issuing the Command Help: The following commands perform processing functions related to Review Group maintenance. Information on these commands may be viewed by pressing PF1 while the cursor is in the Command field of these screens:
RC Review Criterion maintenance
DRG Default Review Group maintenance
Pressing PF1 while the cursor is in the Command field of any Menu screen will produce a pop-up window from which help can be selected on how to use menus, commands, key fields, PF keys, and list functions.

RC - Review Criterion maintenance

Figure 2 is an example of the screen presented during processing of the RC function.

Figure 2. Data Entry Screen - RC


 Please enter new key fields
   De-coding has been performed                              RC   09/15/97 16:07
  Command:      Action: V Appl:           Crit Type: CBCC  Rev Desk:
  Rev Group:                   Co: 0102 BU: 1222 ( HMRS ) Ctr: 02130-61-0000
 -------------------------------------------------------------------------------
 Action: V  Crit Type: CBCC            Comp -Budg Unit-   Cost Center
                             Starting: 0102 1222 ( HMRS ) 02130-00-0000
                             Ending:   0102 1222 ( HMRS ) 02130-99-9999
 
 
                    Review Group      Dollar Max
                    D-GEIS             9999999
 
 
 
 
 
 
 
 
 Entered: 03/16/94 14:35 Updated: 03/16/94 14:35 By: AVCF005
                                                     Cathy Renner
 Enter-PF1---PF2---PF3---PF4---PF5---PF6---PF7---PF8---PF9---PF10--PF11--PF12---
       Help  Suspd Quit  DCode                   NextR

The following sections describe the Review Criterion maintenance function:

"Purpose"
"Key Fields Required in the Banner"
"Valid Actions"
"Validations"
"Processing"
"Related Topics".

Purpose

Key Fields Required in the Banner

Valid Actions

View {V}
Update {U}

Validations

The RC function employs the following validations:

Processing

Related Topics

Information on the following topics may be selected after issuing the Command Help: The following commands perform processing functions related to Review Criterion maintenance. Information on these commands may be viewed by pressing PF1 while the cursor is in the Command field of these screens:
RG Review Group maintenance
DRG Default Review Group maintenance
Pressing PF1 while the cursor is in the Command field of any Menu screen will produce a pop-up window from which help can be selected on how to use menus, commands, key fields, PF keys, and list functions.

DRG - Default Review Group maintenance

Figure 3 is an example of the screen presented during processing of the DRG function.

Figure 3. Data Entry Screen - DRG


 HPWR displayed; please enter new key fields
  TAODRG  1                 Default Review Group - DRG            09/15/97 16:10
  Command:      Action: V Appl:           Crit Type: HPWR  Rev Desk:
  Rev Group:
 -------------------------------------------------------------------------------
  Action: V Criterion Type: HPWR
 
         Description:  Wage Rate - special routings
 
         Default Review Group Cd:
 
     Comments:
     HRLY-TS/WR special criteria: Work Study = 1, Unit or Special Rate = 2,
     OT at Straight Rate = 3, Different and Sporadic = 4.
 
     Suffix for initialization (TANI) and entry (TANE) subprograms:  1NUM
 
 
 
 
  Entered: 05/24/95 18:26 Updated: 05/24/95 20:46 By: WDW
 
 Enter-PF1---PF2---PF3---PF4---PF5---PF6---PF7---PF8---PF9---PF10--PF11--PF12---
       Help  Suspd Quit  DCode                   NextR

The following sections describe the Default Review Group maintenance function:

"Purpose"
"Key Fields Required in the Banner"
"Valid Actions"
"Validations"
"Processing"
"Related Topics".

Purpose

Key Fields Required in the Banner

Valid Actions

View {V}
Update {U}

Validations

The DRG function employs the following validations:

Processing

Related Topics

Information on the following topics may be selected after issuing the Command Help: The following commands perform processing functions related to default review group maintenance. Information on these commands may be viewed by pressing PF1 while the cursor is in the Command field of these screens:
RC Review Criterion maintenance
RG Review Group maintenance
CCCR Company Cost Center Routing via CBCC
Pressing PF1 while the cursor is in the Command field of any Menu screen will produce a pop-up window from which help can be selected on how to use menus, commands, key fields, PF keys, and list functions.

CCCR - Company Cost Center Routing via CBCC

Figure 4 is an example of the screen presented during processing of the CCCR function.

Figure 4. Data Entry Screen - CCCR


 0402 12003-21-0000 displayed; please enter new key fields
  TAOCCCR 1         Company Cost Center Routing via CBCC - CCCR   09/15/97 16:08
  Command:      Action: V Appl:           Crit Type:       Rev Desk:
  Rev Group:                    Co Cost Center: 0402 12003-21-0000
 -------------------------------------------------------------------------------
  Action: V Co Cost Center: 0402 12003-21-0000     BU: 1080  ( CVEG )
            US/DOT/NRTSC-ADMN/LEFEVRE                      Status: Active
 
      RG:  D-PENATES-RA
   $ LMT:  9999999
 
  PENATES  Hancock, Sandra
  RESACCT  Shaw, Phyllis T
 
 
 
 
 
 
 
 
 
 Enter-PF1---PF2---PF3---PF4---PF5---PF6---PF7---PF8---PF9---PF10--PF11--PF12---
       Help  Suspd Quit                          NextR

The following sections describe the Company Cost Center Routing via CBCC function:

"Purpose"
"Key Fields Required in the Banner"
"Valid Actions"
"Validations"
"Processing"
"Related Topics".

Purpose

Key Fields Required in the Banner

Valid Actions

View {V}
Update {U}

Validations

The CCCR function employs the following validations:

Processing

Related Topics

Information on the following topics may be selected after issuing the Command Help: The following commands perform processing functions related to company cost center routing via CBCC. Information on these commands may be viewed by pressing PF1 while the cursor is in the Command field of these screens:
RC Review Criterion maintenance
RG Review Group maintenance
DRG Default Review Group maintenance
Pressing PF1 while the cursor is in the Command field of any Menu screen will produce a pop-up window from which help can be selected on how to use menus, commands, key fields, PF keys, and list functions.

PROX - PROXy maintenance

The following sections document the Proxy maintenance function:

"Purpose"
"Key Fields"
"Actions"
"Special Processing"
"Related Topics"

Purpose

The Proxy function is used to view, create, and maintain proxies. PROX can be found on the menu PSB, Proxy Sub-Menu, which also contains list functions helpful in locating defined proxies. The Proxy identifies the individual user ID who is authorized to act on behalf of a reviewer for a particular application. A Proxy ID, therefore, is associated with a specific Reviewer Desk ID and an Application ID and is effective for a defined period of time. A maximum of three users may be defined as proxies for a given reviewer desk and application for the specified time period. A proxy can be defined either by the individual authorized to work the designated reviewer desk or by the TARGET administrator.

Key Fields

Action Possible values for action are V (View), A (Add), U (Update), D (Delete), and N (New).
Reviewer Desk ID
Application ID
Effective Date The effective date may be entered in any number of formats as described in "Entering dates", which is a topic accessible from the HELP screen of this application. The proper value for Effective Date is determined by the action being performed. For further details, see the section that addresses the specific action desired.

Actions

The following actions are possible for this function. Use of some actions may be restricted for some users. No data will be created, modified, or deleted until PF10 is pressed.

View (Display existing Proxy assignments)

View displays the associated proxy data for the specified Reviewer Desk ID and Application ID that is effective for the date indicated. The effective date entered in the banner may be any date within the range from the beginning date through the ending date of the record.

Add (Create new Proxy assignments)

Add is used to define proxy IDs for a reviewer and an application effective for a specific time period. To create a proxy record that defines up to three users as proxies for a reviewer and an application, enter in the banner fields the appropriate Reviewer Desk ID and the valid Application ID, for which the reviewer is authorized, and the beginning date for the proxy period in the Effective Date field. The end date for the proxy period is automatically calculated by the program to be two weeks from the begin date, but it may be changed simply by modifying the value.

Update (Modify Proxy assignments)

Update is used to modify data for either effective or future records. For a record to be effective, its begin date must be less than the current date, and its end date must be greater than or equal to the current date. To prevent historical data from being altered, only the end date of an effective record may be modified. All other data is protected from entry and cannot be altered. A future record is one whose begin and end dates are greater than or equal to the current date. Because it has not yet become effective, a future record may have all data modifiable. Update may not be used on a record whose end date is less than the current date. Thus, it is important that all data entered is correct when the proxy record is created.

Delete (Delete Proxy assignments)

A record may only be deleted if its begin date is greater than or equal to the current date. To delete a specific proxy record, enter in the banner an effective date for the record along with the required Reviewer Desk ID and Application ID.

Copy (Use displayed data as model to create or update Proxy assignments)

Copy can be used to either add a new record or update an existing one, and screen values are copied to the desired record as specified in the banner. Normally, the source proxy record is displayed first. Then, to copy to the destination proxy record, enter in the banner the appropriate values in Reviewer Desk ID, Application ID, and the record's begin date (if new) or an effective date (for the existing record) in the Effective Date field. As with an Add, the new record must have a beginning date greater than or equal to the current date. And, in order to Copy to an existing proxy record, the destination record's begin date must be greater than or equal to the current date.

New (Alter data for existing Proxy assignment to be effective during a new time period)

New is a slightly more complicated action that combines both Add and Update. New creates a new period of the proxy record by copying the proxy IDs from an existing period. Thus, a new proxy record is created. At the same time, the existing period for that proxy record is closed as of the day before the begin date for the new period. In this manner, the existing proxy record is updated to reflect the change in its end date. To create a new proxy period and close an existing one, enter in the banner the new begin date in the Effective Date, along with the proper values for Reviewer Desk ID and Application ID. (It is not necessary to first view the existing period of the record.) The begin date for the new period cannot be less than the current date or greater than the end date of the existing period. The proxy IDs and the end date are copied from the existing period, and this data can be modified. Upon pressing PF10, the existing period is closed as of the day before the begin date of the new record, and the new period for the proxy record is created.

Special Processing

PF4 provides a decode facility to display the names and budgetary units of the proxy user IDs. PF4 will also decode the user ID of the last person who updated the record and show the individual's full name.

Related Topics

TARGET Rules for PSB Position Control

The following sections describe the TARGET rules for the PSB PACT (Personnel ACTion) function:
"Overview"
"How to maintain the Review Criterion - PBPB for PACT"
"How to maintain the Review Criterion - PBPA for PACT"

Overview

The TARGET rules for PSB Personnel Actions are based upon Budgetary Units for 'normal' routing. Certain special situations, covered below in "How to maintain the Review Criterion - PBPA for PACT" are routed to specific administrative reviewers. In addition to the appropriate Department Head or Director for a BU, PACT transactions are routed to the Dean, or Vice Chancellor for those units not reporting to a Dean.

How to maintain the Review Criterion - PBPB for PACT

Maintenance of the PBPB criterion is relatively straightforward. Once Review Groups are established via the RG (Review Group maintenance) command, the criteria can be established using the RC (Review Criterion maintenance) function. Since transactions are routed by BU, each Budgetary Unit involved in personnel activity must have criterion established. The chain of approval should include, in this order:
  1. The Department Head or Director
  2. The Dean or Vice Chancellor
Figure 5 is an example of the screen presented during processing of the RC function for Criterion Type = PBPB.

Figure 5. Review Criterion maintenance for type PBPB


 1060 (CMNT) displayed; please enter new key fields
  TAORC   1 DEMO         Review Criterion maintenance - RC        04/02/97 13:47
  Command:      Action: V Appl:           Crit Type: PBPB  Rev Desk:
  Rev Group:                   BUnit: 1060 ( CMNT )
 -------------------------------------------------------------------------------
 Action: V  Crit Type: PBPB           BUnit
                             Starting: 1060 ( CFAC )
                             Ending:   1062 ( CMNT )
 
 
                    Review Group      Dollar Max
                    RENNER             9999999
 
 
 
 
 
 
 
 
 Entered: 03/11/97 14:42 Updated: 03/11/97 14:42 By: PCAMPBE
 
 Enter-PF1---PF2---PF3---PF4---PF5---PF6---PF7---PF8---PF9---PF10--PF11--PF12---
       Help  Suspd Quit  DCode                   NextR

In the above example, the group 'Renner' would include the appropriate Dept. Head/Director and Dean/Vice Chancellor for the specified BU range. Please note that a starting BU is placed in the banner, and an ending BU is entered in the body of the screen. If the review criteria for a single BU is to be established, simply make the beginning and ending BUs for the range the same.

How to maintain the Review Criterion - PBPA for PACT

The PBPA criterion exists to handle five special scenarios and their various combinations:
Situation Reviewer
Overmax Budget Office
Prior Service/Ex. Well-Qual Class/Comp
Academic VCAD
Special Sal/LC/PD/CP HR, Employment
Graduate Assistants Graduate School

It should be noted that the Academic transactions routed to the VCAD will not include student titles, and the LC (Lateral Change), PD (Promotion/Demotion) and CP (Change Position) transactions will be for non-academic titles only.

The following groups need to be established via the RG (Review Group maintenance) command (the number in the left column is the 'situation #' assigned by the program):

1 Employment only
2 VCAD only
3 Employment + VCAD
4 Class/Comp only
5 Class/Comp + Employment
6 Graduate School only
7 Graduate School + Employment
8 Budget Office only
9 Budget Office + Employment
10 VCAD + Budget Office
11 Budget Office + Employment + VCAD
14 Graduate School + Budget

Then, as shown in Figure 6, a link is made on the RC command between the Review Groups and the numbers representing their interrelationships. In this example, criterion '03' represents a transaction requiring both Employment and VCAD approval. So, the '03' criterion is linked to a Review Group which includes the reviewers from both units. In our example, this group was named 'Employ+VCAD'. Figure 6 is an example of the screen presented during processing of the RC function for Criterion Type = PBPA.

Figure 6. Review Criterion maintenance for type PBPA


 3 displayed; please enter new key fields
  TAORC   1 DEMO         Review Criterion maintenance - RC        04/02/97 13:47
  Command:      Action: V Appl:           Crit Type: PBPA  Rev Desk:
  Rev Group:                   Number: 03
 -------------------------------------------------------------------------------
 Action: V  Crit Type: PBPA           Number
                             Starting: 03
                             Ending:   03
 
 
                    Review Group      Dollar Max
                    EMPLOY+VCAD        9999999
 
 
 
 
 
 
 
 
 Entered: 04/02/97 08:47 Updated: 04/02/97 08:47 By: PCAMPBE
 
 Enter-PF1---PF2---PF3---PF4---PF5---PF6---PF7---PF8---PF9---PF10--PF11--PF12---
       Help  Suspd Quit  DCode                   NextR

Appendix A. General System Features

NSM Architecture

The Natural Secured Menus (NSM) Architecture is a standard set of facilities used for the development and operation of online Natural applications. It has been developed at the University of Arkansas using Natural 2, a fourth generation programming language provided by Software AG. The NSM Architecture imposes a command driven, menu augmented approach to the navigation of an application (the act of moving from one function to another). Anyone using an NSM application will be able to move from any function to any other function, within their security constraints, by entering the desired command. Additionally, menus are provided for command selection when the desired command is not known.

Additionally, all NSM applications use the same basic screen format and operate in a similar manner. For example, the first three lines of each screen are reserved for the title, command, and key information. The last two lines are reserved for displaying available PF keys and their associated functions with a standard usage defined for most of these keys. In summary, the NSM Architecture provides:

Additional information on the NSM architecture can be obtained online by requesting help (pressing PF1) from any Menu screen.

Online Help

Online help is available at the application level, the screen or function level, and the element level. Access to each of these help facilities is as follows:

In addition to these system-wide help facilities, each specific function may provide additional help. Some functions provide the use of PF4 for DeCode. The de-code function will return descriptions associated with coded values on the screen or retrieve additional associated data. This feature will be described in the command description when it is available, and the PF4 function will be labeled on the bottom of the screen.

Information on the following topics may be selected after pressing PF1 while the cursor is in the Command field of any Menu screen.

Menus and how to select a command from a menu:

Describes the information presented within menus, three options for specifying a desired command, and how key fields may be passed to the command in advance.

Explanation of what a command is:

Describes in broad terms what a command is and how they are used in an application.

How to use key fields appearing in the banner:

Describes key fields which appear at the top of the screen and how they can be used across multiple commands.

How PF Keys are used:

Describes how each of the PF keys at the bottom of the screen can be used, and how PF12 can be used to get to PF13 through PF24.

Definition of the Natural Secured Menus Architecture:

Provides background on why we are using the structure that you experience with these applications.

Features of the Natural Secured Menus Architecture:

Describes the features that make our applications user-friendly and make development simpler.

List Functions:

Describes what lists are and how they can be used.

How to report problems or make suggestions:

Describes how to report system problems as well as make suggestions for improvement of the system.

Alternate Entry Formats

Date Formats

A 10-character field is used to display all dates. To ease data entry, the system accepts the entry of a date in several formats and returns it in a standard format. The proper convention is MM/DD/YYYY. A dash (-) or slash (/) is acceptable as a divider between month, day, and year components. You can also enter the date with no dividers. In addition to the above format, the system will accept the following:

MM-DD-YYYY
MM-DD-YY
MM/DD/YY
MMDDYY
MMDDYYYY

The following date ranges are available based on the format used:

When any date outside of the above ranges and formats is entered, it is assumed that a date with only a two-digit year has been typed in over an existing date and only the first two digits are utilized. Whenever a two-digit year is being utilized, if those digits are less than 11, it is assumed to be in the 21st century, otherwise, it is set to the 20th century. For example:

03/17/1799 is returned 03/17/1917
03/17/1800 is returned 03/17/1800
03171800 is returned 03/17/1918
03172100 is returned 03/17/1921
031711 is returned 03/17/1911
031710 is returned 03/17/2010
03/17/11 is returned 03/17/1911
03/17/10 is returned 03/17/2010

Cost Center Formats

An 18 character field is most commonly used for company cost center numbers. To ease data entry, the system accepts the entry of a cost center number in several formats and returns it in a standard format. The system also sets a 15 digit numeric value which is actually stored on the database. The proper convention is 9999 99999-99-9999, where the last four digits are an optional project number that when not entered is returned as zeroes. In addition to the above format, the system will accept the following:

Occasionally, a 15 character field is presented for entry of a cost center number, and an 18 character formatted field is returned. This version was developed to support data-entry intensive functions, where the 15-digit number could be entered and, because that filled the field, the cursor would skip to the next required field without tabbing forward.

Using the Suspend Feature

The suspend feature allows a user to access a second or third function while still retaining in a suspended state the activity within the original function, including any data entered prior to the suspend request. This means that you can suspend to another function without losing what has been entered in the first function. Three active levels are permitted; although suspending to or from a menu or an application independent command is not allowed. The system keeps track of these levels, and displays a "1," "2," or "3," respectively, on the current function in the top line of the banner to the left of the Command field. The ability to suspend is most useful in the following situations:
  1. While viewing information on a list of transactions or documents, mark selected entries from the list and suspend to a function to view or perhaps update the marked selections.
  2. Midstream in the entry of data for an update, access a table to obtain a value or make a change necessary for completion of the original update.

Depending on the activity the user initiates in the second (or third) function, pressing PF3, PF10, and sometimes PF8 will return the user to the suspended function. When suspended from a function and using an Action that will permit a change in the second function, then PF10 will be labeled "Sav/Q." If the suspended function is a list, pressing PF10 will cause the changes to be saved, but will exit the function only if there were no other entries selected in the first function; otherwise the next entry selected in the first function will be presented. If the suspended function is not a list, pressing PF10 will cause the changes to be saved and exit to the suspended function. PF8 will be labeled "Q/Nxt" in the second (or third) function, indicating that pressing PF8 will cause all selected entries to be successively displayed until the function is exited. PF3 will always result in an exit to the function. A warning message is provided whenever a user's actions would cause a suspended function to be lost (e.g. enter a Command without pressing PF2).

During the suspend process the user may make changes to fields in the banner. When the functions suspended to are exited, the key fields required by the original function are restored to the values which were previously in effect.

Suspending from a List

The suspend feature generally is used from lists by entering the desired Command and new keys in the banner and then pressing PF2. In this case, the user would select or mark an entry or entries on the list, then enter the desired Command in the banner. In addition, the user might want to check the current action displayed in the banner, since that is the action that will be used in the second function. For instance, assume that for a list function the Action is V (view), but an update is desired in the second function; in that case the user would change the Action to U before suspending. If the selected entries do not contain the key fields required for the function to be accessed, then the required fields should be entered in the banner.

The Command and the key fields are maintained as a part of the list when there is a single command that one would normally suspend to, such as the command in which a document was created or submitted. When the Command and the key fields are part of the list, the Command ID will normally be displayed in the far left column, and suspending can be accomplished merely by selecting/marking an entry (or entries) and pressing PF2.

Note: The Command (and keys) supplied as part of the list can be overridden by an entry in the Command field in the banner.

When returning to the list from a suspend, the lines which were selected will have a space beside them instead of the underscore. This helps the user keep track of which entries have been viewed. is an example of a list command from the UPS system where the Command and key fields are part of the list. 



 Select an entry, or enter new keys
  UPOLIPO 1 PROD           List Invoices for a PO - LIPO          12/21/99 08:37
  Command:       Action: V  Req:         :       PO: 6029791 : 1     TA:
  Date Invoice Received:
 -------------------------------------------------------------------------------
 List Invoices for PO Number: 6029791 received on or before
      Vendor: VWR Scientific
           Date                        Inv Paid       Inv   Inv  Inv Prob
    Cmd  Received Invoice No/Suffix     Amount   Disc Date  Type Sta Cd  AP ID
  _ ILOG 05/03/99 382252                  157.92   T 04/26/99 R   A    000484071
  _ ILOG 04/07/99 278294                  479.81 * T 03/25/99 R   A    000475401
  _ ILOG 04/07/99 288105                   62.09   T 03/29/99 R   A    000474305
  _
  _
  _
  _
  _
  _
  _
 
                 Invoices     1 through     3 of     3 displayed
 
 Enter-PF1---PF2---PF3---PF4---PF5---PF6---PF7---PF8---PF9---PF10--PF11--PF12---
       Help  Suspd Quit  DCode RStrt

Suspending from Functions other than Lists

When suspending from functions other than lists, the Command and desired keys must be entered in the banner. After pressing PF2, the current function will be suspended temporarily, and the second function will be displayed. The work being done in the original function is not affected by the suspend or any updates done in the second function. However, it may be that the suspend was initiated in order to add or update information in another function that is validated in the first function. In that case, the validity of data entered in the first function is impacted by the work done in the second function.

PF Key Usage

All valid PF keys are named and the names displayed on the last two lines of the screen, in either Natural format or a PC style format. PF keys that are not valid in a certain circumstance will have their names removed so that they do not appear as valid options. The error message "PFxx is unassigned, valid PF Keys are displayed on the screen" is displayed whenever an inappropriate PF key is entered. The standard PF key usage is:

Key & Name

Usage

Enter

If new key field values or a new command have been entered, initiate processing for the new keys or the new command issued. Otherwise, validate any entries made in the body of the screen and prompt for the next activity.

PF1 (Help)

Initiate help processing. This will be field help if the cursor is on a field defined with a help routine; otherwise, screen level help will be provided.

PF2 (Suspd)

Suspend the current program and transfer control temporarily to the requested function module. Entry of a command is required.

PF3 (Quit)

Quit the current operation and back up one level in the processing hierarchy:

  • If within a window, return to the primary screen.
  • If within a function module and at level one (no programs are suspended), return to the menu which contains that function module.
  • If within a function module and at a level greater than one, return to the program suspended at the next lowest level.
  • If within a menu, return to the menu that contains that menu command, or if on the main menu, return to the LOGON application. If the current application is the user's default application, sign off Natural.
  • If within the application selection screen of the LOGON application, sign off of Natural.

PF4 (DCode)

Decode selected coded values on the screen by performing lookups and displaying associated names, descriptions, or other information. This key may also be used to explode a selected entry by displaying within a window more detailed information than was available on the original screen.

PF5 (RStrt)

Restart the operation with the keys specified in the banner area (disregard any changes or entries made within the body of the screen). On list functions, any previously marked entries for selection are cleared.

PF7 (Back, PrevS)

Page backward to values or previous screens displayed within the same function module.

PF8 (NextS, NextR, NextT, Q/Nxt, Forwd)

PF8 always moves the user forward to access the next set of data, although the key is labeled and the function is performed in a different manner dependent upon the circumstances.

  • If on a multi-screen function, this key is labeled "NextS" and pages forward to the next screen.
  • On the last screen of a function, or when there is a command or key error, it is labeled "NextR" and will retrieve the next logical record for display.
  • Additionally, within a function that is operating at level 2 or 3 and which was accessed from a suspended list, this key is labeled "Q/Nxt" for quit this function and retrieve the next selection. If no other entries are marked, the effect is a quit to the suspended list.
  • At other times, PF8 is labeled "Forwd" and pages forward to display the next set of records.

PF10 (Save, Sav/Q)

Normally PF10 will save onto the data base any changes that have been made or data that has been entered. Within a function module operating at level 2 or 3, the key is labeled "Sav/Q" to save the changes and then quit that function and return to the suspended function.

PF11 (Options)

This key is provided for the selection of options that may be available in individual function modules.

PF12 (Print or Flip)

On lists where a print function has been associated with the listed items and the user has selected (by default via the user profile or use of the RODS command) a Report Output Destination ID, this key will generate a print (report) of the selected items. On function modules where more than 12 PF keys are defined, PF12 is flip and will flip the display of PF keys to show PF13 thru PF24.

PF24(Flip)

This key flips the display of PF keys to show PF1 thru PF12.

How Your Computer Communicates with BASIS

Although this document includes some technical concepts that may be confusing at first glance, the payoff for digesting the concepts will be your greatly enhanced effectiveness in using BASIS applications. When you know how to control the look of your screen (field colors, color and location of the message line, function key colors, etc.), how to navigate around the screen quickly and efficiently, and how to use your keyboard to perform time-saving tasks, you will find that your work within BASIS progresses more quickly and easily.

The Mainframe Environment

In order to understand some of the discussion below with regard to how your screen looks and how your keyboard functions, we first need to begin with a basic overview of our mainframe environment. BASIS applications live on a mainframe computer and run under CICS and Adabas TPF. These terms may mean nothing to you, but what they signify to you as a user is that you use your PC or Macintosh desktop computer to interface with a computer application running under a very complex and sophisticated mainframe environment. By itself, without a standard interface, your desktop computer would be unable to communicate properly.

3270 emulation

The interface you use is called a 3270 telnet (a TCP/IP protocol) program. These programs come in many different flavors, with different capabilities. But before we discuss the various capabilities, you must first understand a bit about 3270 emulation. The term "3270 emulation" refers to the fact that these software programs interface with mainframe applications by making it look to the mainframe as if your desktop computer is an IBM 3270 terminal (sometimes called dumb terminals). These terminals were the original devices used to connect with mainframe computers many years ago. Typically, they consisted of a monitor (display) and a keyboard, and did not have their own internal processing capability. Once this sort of connection is established, you are in effect no longer using the 486, Pentium, or PowerMac in front of you, but are instead working within the rules and confines of the 3270 environment.

One final note should be made here about 3270 terminals. The 3270 screen is made up of fields, either protected or modifiable. The terminals operate in blockmode which means that the mainframe (BASIS) does not respond to any entries or changes you make to these onscreen fields until you submit the updated screen, usually by pressing Enter or a PF key. This is different from many PC-based spreadsheet, database or word-processing applications you may use where on-screen changes take immediate effect.

3270 terminal types

The term 3270 is a generic one since there are actually three basic types of 3270 connections supported by BASIS, each with different capabilities.
3270 The simplest of the three. 3270 terminals are monochromatic (one-color) displays able to show only normal or intensified (bold) text.
3278 Adds reverse video and underlined text. Among the development team and veteran BASIS users, the reverse video (or reverse highlighting) is a favorite since it allows the user to quickly determine via visual cues which fields are modifiable, required, etc.
3279 The most capable of the emulations. It adds the ability to display text in seven different colors.
You can set your 3270 type, and control the 3279 colors (if supported by your emulation software) through the BASIS user profile screen (accessed by pressing PF6 on the logon screen). See "Maintaining Your User Profile" for further information about customizing the screen.

Generally speaking, if your software and monitor support it, you are encouraged to use 3279 mode since it offers the greatest control over the look of your screen. This is usually available while using a Network or PPP connection, but will not be available while using a non-PPP, dial-up connection.

BASIS Mainframe Keys and Keyboard Mapping

Keyboard mapping is important to you because you need to know which keys on your desktop machine are being used to emulate the 3270 keys the mainframe is expecting. Below we cover some common function keys and other special use keys. If a BASIS program tells you to press PF10, this could literally be any key or any combination of keys on your machine. Generally, default keyboard mapping for emulation programs will use your PC or Macintosh F (function) keys to represent the mainframe PF (programmable function) keys, but other 3270 keys are not so clear. When you wish to move your cursor from one line to the next, or from one field to another, or you want to erase an entry in a field, you need to know how your software represents 3270 keys like Newline, Tab, and Erase EOF (end of field).

Depending upon the 3270 software you are running, you may see variations in the keys used in the default setup, and in your ability to reset, or re-map those keys. This is especially true of dial-up software. Addressing all variations in 3270 emulation software and keyboard mapping is beyond the scope of this document. Instead, this is intended to provide support and explanation for the common usage seen with on-campus PC-compatible and Macintosh computers. Contact Computing Services Help Desk at campus extension 5-2905 with any questions or problems not addressed here. Please be prepared to tell the technician:

Commonly used 3270 keys

The following list shows mainframe 3270 keys. In order to process these keys using your desktop computer, you need to know how your tn3270 software emulates these keystrokes. For that information, please refer to "Common PC-compatible keyboard mapping" for PCs or "Common Macintosh keyboard mapping" for Macintosh computers.
3270 Key Purpose
Enter Submit on-screen entries to mainframe for processing. 1
Insert Toggles between typeover and text insertion.
Home Moves cursor to first input field on the screen (the Command field in BASIS).
Tab Moves the cursor to the first position of the next field on the screen (fields run left to right, top to bottom, and wrap from last field to first field).
Back Tab Moves the cursor to the first position of the previous field on the screen.
Clear Clears (resets) current screen display. This is used in other mainframe applications, such as CMS, but is trapped and will result in an error in BASIS. Instead, PF5 is used to reset a screen.
Erase EOF Erase to End Of Field. This key deletes any characters from the current cursor position to the end of the current field. It is especially handy for deleting lengthy or unwanted text entries, instead of spacing over each character or holding down the delete key.
Newline Moves the cursor to the first position of the first modifiable field which is on a line vertically below the current cursor position. In the example below, we would move from the field One to the field Five with a single keystroke, whereas Tab would require four (4) keystrokes. 
One : _____ Two: _____ Three: _____ Four : _____
 
Five: _____ Six: _____ Seven: _____ Eight: _____

Note: The usage noted below for all PF keys is for BASIS. Other mainframe applications are likely to utilize the PF keys in different manners.

PF1 Help
PF2 Suspend (See Help Topic "Using the Suspend Feature" for more information.)
PF3 Quit
PF4 DeCode
PF5 Restart
PF6 Can vary by application. Often used to access Detail or Percentage windows.
PF7 Back/Previous/PageUp
PF8 Next/Forward/PageDown
PF9 Can vary by application. Often used to access Display or Detail facilities.
PF10 Save
PF11 Options/Comments or other special function
PF12 Flip (change PF key display to show PF13-24) or Print, or other special function.
PF13-24 As assigned for special functions. Usually only available when PF12 is labeled as "Flip." 2
PA1 Access the COM-PASS Natural session manager, which allows you to simultaneously run up to nine BASIS applications (or other Natural applications which run under Adabas TPF).
PA2 Prints the current screen at Computing Services. Since the printout is not identified with a user and will be recycled, please do not use this key.
PA3 Switch to the next COM-PASS session (first setup under the Natural session manager accessed via PA1).

Common PC-compatible keyboard mapping

Again, depending upon your software, the default mapping (or mapping customized by a previous user) may be different. These are common settings seen on many of the configurations around campus. If for some reason they do not work for you, check to see if your software has re-mapping capabilities, and/or contact Computing Services for assistance.
3270 Key PC-Compatible Key
Enter Enter
Insert Insert
Home Home
Tab Tab
Back Tab Shift + Tab
Clear + (plus) on numeric keypad
Erase EOF - (minus) on numeric keypad
Newline End
PF1 - PF12 F1 - F12
PF13 - PF24 (Shift + F1) - (Shift + F12)

Common Macintosh keyboard mapping

3270 Key Macintosh Key(s)
Enter return
Insert apple + i
Home home
Tab tab
Back Tab shift + tab
Clear clear (num lock)
Erase EOF apple + e
Newline shift + return
PF1 - PF12 F1 - F12
PF13 - PF24 (shift + F1) - (shift + F12)

Maintaining Your User Profile

Before reading this section, you should be familiar with the terms and concepts presented in "How Your Computer Communicates with BASIS". Figure 7 shows the user profile screen, which is accessed by pressing PF6 on the logon screen.

Figure 7. Natural User Profile


 Make changes and press ENTER to validate and see the results
                    User Profile for  PCAMPBE   Peter Campbell
 
   CMS ID:          @                              Default Application:
   Email:                                          Campus Bldg:      Room:
   Report Output Destination ID: PIKE_301_L
   PFKey Format: N           Message Line: T             Terminal Type: 3279
 
 Color Selections Available to 3279 Type Terminals:    BL GR NE PI RE TU YE
 
                         Modifiable:     Protected:
  D  Default intensity:  TU   sample     NE   sample    PFKey name: YE
  I  Intensified:        GR   sample     YE   sample    Function:   NE
  V  Reverse video:      TU   sample     NE   sample
  U  Underline:          GR   sample     BL   sample
 
 Override program assigned colors (T/F): F        Message Line Color: YE
 
 NSM Field options:    Modifiable default      V   color:  TU    sample
                       Modifiable intensified  V           PI    sample
                       Conditionally protected D           NE    sample
                       Previous value          V           NE    sample
 Enter-PF1---PF2---PF3---PF4---PF5---PF6---PF7---PF8---PF9---PF10--PF11--PF12---
       Help        Quit        RStrt Deflt                   Sav/Q Color Mono
The figure printed here is unfortunately not able to truly represent the look of the 3279 emulation seen onscreen. It will, however, help demonstrate the various modifiable fields which control the look of your BASIS screen.

Beginning near the top, notice the Report Output Destination ID: field. This sets the default location to which report and/or file outputs will be sent. It can also be set via the RODS (Report Output Destination Specification) command. An online help facility is available to help you with your selection; a full description of these choices is beyond the scope of this document.

Just below this, is the Message Line field. This controls the location of your message line. Possible values are:

B Bottom of the screen
T Top of the screen
Just to the right is the Terminal Type: field. This controls which type of 3270 emulation you use, which also of course depends upon the ability of the software you are using to support that level of emulation. Refer to "3270 terminal types" for a description of the differences between these terminal types. Possible values here are:
3270 Basic functionality
3278 Extended attributes
3279 Color support
Below this, you will see the color options available under 3279 emulation:
BL Blue
GR Green
NE Neutral (white)
PI Pink
RE Red
TU Turquoise
YE Yellow
In the middle section of the screen, you control (if using 3279 emulation) the colors used for the four basic field types: default intensity, intensified, reverse video, and underlined. Since each field type can be either modifiable or protected, there are eight color values to be entered here. Essentially, you are telling the system how (which color) to display the various field types. If you are using 3270 or 3278 emulation, none of these color fields will be available, although some tn3270 software allows for a kind of synthetic color specification for different field types under 3270 or 3278 emulation. Such color specification is done within the microcomputer software, rather than in your user profile.

To the right of this middle section are the PFKey name and Function fields, which set the colors for your function key list shown at the bottom of the screen. Below this is the field where you set the Message Line Color.

The last section of the screen allows you to specify further options for some special NSM (Natural Secured Menus) fields, which all BASIS applications use. There are four field types, each of which has two entries:

  1. The type of attribute option you want linked to the NSM field. For example, in the figure, we see that Modifiable default fields are set to be V (reverse video). The options available to you will depend upon your type of emulation. For example, you cannot select V under 3270 emulation since it does not support reverse video.
  2. The color to be used for this NSM field type. In our example of the Modifiable default, we chose TU (turquoise). Again, these colors will only be modifiable if the Terminal Type is 3279.
To save any changes made, simply press PF10.

Appendix B. System Definitions

Overview

The TARGET system assumes a complete integration of the distributed data entry function and its resulting electronic approval with the application where the data is processed. In this primary area, TARGET provides a framework and model for building application programs that incorporate electronic transaction processing features. This requires the application to be designed with the intent of using TARGET and that application programs are written according to standards and models provided by TARGET. Due to this tight integration, TARGET cannot be easily overlaid onto existing applications.

In another area, TARGET provides a set of core support functions which are used independently by all TARGET applications. The establishment of the BASIS desks that will be responsible for the review of a transaction is one example of a function performed by one of these independent routines. There are many others.

A third area is the TARGET administration system. This is an application that provides operational and management support of TARGET. Functions provided by this application include maintenance of control tables and transaction routing tables; routines to archive, print, and purge transactions; identification of transactions which have not been reviewed within a reasonable period; and the ability to establish proxies for others.

Note: Since each application and its requirements are unique, TARGET is described using generic references to application components such as data base entities, data base keys (data values which uniquely identify a data entity), and transactions. Such references will be found throughout TARGET documentation.

Processes

The primary processes for TARGET can be divided into two areas: those that are performed for a transaction within an application and those which support that operation via the TARGET administration system. Each of these is discussed briefly.

The transaction processor is the key component of a TARGET application and is responsible for performing all of the following functions:

Several TARGET subprograms assist in this process by establishing the appropriate desks for review of the transaction, displaying and allowing entry of comments to be carried with the transaction, displaying a historical log of activities performed on the transaction, generating a notice to the requestor of the transaction if it is rejected, and verifying the proxy authority of a user.

The TARGET administration application provides facilities for managing the data required to drive TARGET systems. This includes maintenance of transaction control information, routing information (via review groups, criteria types, and review criteria), and proxies. Facilities are also provided to report transactions which have been pending too long and to archive, print, and purge transactions based upon defined parameters.

Proxies and their Function

Definition

A Proxy is an individual who is authorized to act on behalf of a reviewer for a particular application. That authority is only applicable within the context of the TARGET system and is limited to a specific time period. A maximum of three users may be defined as proxies for a given reviewer desk and application for the identified time period. A proxy can be defined either by the individual authorized to work the designated reviewer desk or by the TARGET administrator.

Function

A proxy acts on transactions in the specified application that are to be reviewed by the reviewer desk ID to which the proxy is assigned. In order to act as a proxy, the user must identify himself as a proxy at the time of logon to the application (?). When a transaction is reviewed and the proxy approves, rejects, or holds it, the transaction is identified as having been acted upon by a proxy for that reviewer.

Data Requirements

The TARGET system uses 6 logical files, all critical to the operation of TARGET applications. Five of these are defined on one physical Adabas file while the TARGET transactions reside on an independent file. The name and purpose of each file follow:

TARGET-TRANSACTION

The contents of each TARGET transaction is maintained on this file along with other control and descriptive data. The transaction data itself is maintained in a generic field which each application must redefine for its own use. Associated transaction attributes include type identification, status information, a complete history of all actions taken including requestor and reviewers, and comments. This file also has several indexes to allow direct access to transaction data based upon different requirements.

TARGET-TXN-CONTROL

Several pieces of control information are maintained on this file and associated with each type of TARGET transaction. The transaction types are identified by the NSM application and command ID associated with the primary transaction processing program. A primary purpose for this control information is for the print, purge and archive process. The review criteria employed by each transaction type are also identified here for documentation purposes.

TARGET-CRITERION-TYPE

This file contains control information associated with each type of review criteria. This includes a description, a lengthy comment, and identification of the desks to be established if the criteria value is not found on the review criteria file.

TARGET-REVIEW-CRITERION

Review criteria are used to determine what desks should review a specific transaction based upon data associated within the transaction. Multiple criteria may be used for a single transaction and criteria may differ for each type transaction. Additionally, a single criterion may incorporate multiple data attributes associated with the transaction. Criteria are identified by an ID and a value range. The range is allowed to simplify the definition and maintenance of the criteria. Department, company/cost center, and/or Action being performed (add versus delete) are examples of the type of data that might be used to establish the desks that will be responsible for reviewing a transaction. A dollar value is also associated with a review criterion so that different desks might be established based upon their spending authority.

TARGET-REVIEW-GROUP

The review group file permits the identification of a set of desks (from 1 to 10) by a group code. That set may then be associated with various review criteria by only entering the group code. An important part of the set is the review level assigned to each desk.

TARGET-PROXY

The proxy file contains the record of who may act as a proxy for a desk and application during a period of time. Reviewers who wish to grant authority for other individuals to act on their behalf do so by directly entering those definitions into this file using UAOPROX, which appears as command PROX in other applications. In emergency situations, the TARGET administrator is permitted to make entries to this file by using TAOPROX from within the TARGET administration application.

Subprograms

The following subprograms reside on the system library and are called to perform specific functions in support of TARGET processing.

Subprogram

Description

TANETRL

The centralized routine which will establish the transaction review list for all transactions. Based upon the transaction data passed to it and the criteria definitions stored in the data base it will determine the desks that are required to review the transaction and their review levels. If multiple criteria are being used for the same transaction, the routine will merge the review lists resulting from each criteria.

TANVTH

Displays a window to view transaction history. This subprogram may be invoked from any transaction processor function module and will display the date and time of the transaction request and all reviews including requestor and reviewers.

TANVATC

Allows viewing or adding transaction comments. Comments are displayed in a window where they may be browsed or additional comments added. This function is available from any transaction processor function module.

TANEOPR

Establishes the operator as a proxy for a desk, if so allowed by pre-existing data base definitions. This function will be available within each application, allowing an individual to act as a proxy in reviewing various types of transactions within the application.

TARGET Administration

The following functions will be available within the TARGET Administration application. These functions are primarily required for maintenance of TARGET data and centralized management of the transaction file.

Function

Description

TC

Transaction control file maintenance.

RG

Review group maintenance.

RCT

Review criteria type maintenance.

RC

Review criteria maintenance.

PA

Proxy authorization maintenance.

LTPD

List transactions which have been pending longer than their maximum allowed number of days.

LTHD

List transactions which have been held longer than their maximum allowed number of days.

LTSC

List transactions of a specified status and type in chronological sequence.

PTD

Print transaction detail for transactions of a specified status, type and status date range.

PAP

Print, archive and purge transactions meeting purge criteria.

PPE

Purge proxy authorizations that have expired based upon their effective date.

RTP

Reviewer test procedure used to display the reviewers and their review levels established for a test set of review criteria. This facility is used to test out review criteria and review group definitions.

Security and Auditability

Security issues are of greater concern when broader access is provided to applications performing critical or financial functions. Access to TARGET applications will be controlled by the same means as currently used within our financial systems, personalized IDs and private passwords. There will only be the CICS ID/password required, unlike MSA and some other systems which require dual sign ons. This should actually be an improvement since only one ID/password will have to be remembered, resulting in less need to write it down.

Access to applications and privileges within those applications is based upon definitions maintained within the NSM Maintenance System. This administration function is performed directly by individuals within the offices with data custodian responsibility. These administrators must make the correct definitions and be conscientious in performing this task; however, this is no different than with any other system. The same situation exists with the review criteria and review groups which must be maintained by a TARGET administrator.

The audit function should be much improved with TARGET since all distributed transactions will be centrally located and contain a complete history of the review process. To assist in this area a batch program will be provided to report all transactions of a specific type over a date range. The transaction file itself may be perceived as vulnerable since it must be updated from every transaction processing function, and thus subject to corruption. This is true. However the same is true for any data base file for which update is permitted. The production environment is a controlled environment where update to data base files is restricted to production programs and records are maintained of all updates to production programs. If added security features or new procedures are deemed necessary, they should be pursued on an independent basis.

New responsibilities

In order for distributed transaction entry and approval to be successful, new responsibilities must be assumed by many offices and individuals. Some of the specific areas where this is true include: The full commitment of the university will be required to support the successful implementation of TARGET. The advantages of more timely processing, reduction of errors, higher quality data, increased productivity, and greater access to information warrants this commitment.

Clarifications

The following points are included to clearly state operational characteristics or issues which may have only been implied or not stated to this point.
  1. TARGET provides no facility for priority coding a transaction so that its processing might be expedited. If a transaction needs to be "walked-through" the system, the originator will need to telephone the reviewer(s), identify the transaction, and request that immediate action be taken on it. The reviewer can then directly select that transaction from a list and process it. It is expected that the need for this type of activity will be significantly reduced due to the speed in which the electronic entry and review can be accomplished.
  2. Changes made to the review criteria will affect transactions entered after that point. Transactions entered previously are established with the reviewers and review levels that were in effect at the time of entry. No facilities have been planned or provided for altering the reviewer information (who is to review a transaction at what level) that is established for a transaction.
  3. Multiple review criteria may be used to establish the reviewers for a single transaction. In this situation the review list resulting from each criteria is always merged with duplicate reviewers eliminated at their lower level. If the result of the merge process is more than 10 reviewers, reviewers at the lowest levels will be eliminated.
  4. If the requestor is also established as a reviewer, based upon the review criteria, that review status is automatically set to approved.
  5. Transactions which require special forms, paper work or other backup materials in the central administrative office can also be processed through TARGET. In this situation, the central office or the recipient of the paper work must be defined as a reviewer of the transaction. Special procedures must be employed by that reviewer to ensure that such transactions are not approved until the necessary documentation has physically been received. A reviewer may indicate this situation with a special status code. This hold status may be placed on transactions for other reasons and will be available on transaction lists. A comment should be added to a transaction that it is being held.
  6. The system will not permit multiple transactions of the same type to be pending for the same data base entity at the same time (e.g., two address changes for the same individual pending at the same time). One change would logically overlay the other at final approval and is therefore not allowed.
  7. Transactions are not applied to the data base until they reach final approval. Validations associated with a transaction may involve data base checks which are affected by the completion of other transactions. Therefore it is possible that a transaction will be valid at the time of original entry but may no longer be valid when it is being reviewed. Such transactions cannot be approved. They must either be rejected or held until some subsequent action would allow them to pass validation criteria (perhaps a transfer of funds).
  8. Applications that use TARGET, due to their nature of allowing distributed transaction entry, may also need to implement security by value. This will permit restrictions to be placed on what data is allowed to be entered for a transaction based upon the originator. For example, an individual in Computing Services would only be allowed to enter vacation/leave data for Computing Services and not for any other department.
  9. Comments are retained as they are originally entered--there are no facilities provided to delete or alter comments. Additional comments may be entered up to the maximum allowed.
  10. The transaction file will always contain the new information being submitted for the transaction. After a transaction has been completed, this will correspond to the information stored on the data base, referred to in data processing as the "after image." To determine what data existed prior to a transaction being processed, the previous transaction completed for that data base entity/transaction type must be retrieved.
  11. The new applications being developed employ much tighter controls and more stringent online validations than previous systems. These validations are implemented in an integrated fashion within our total information system. This should result in fewer needs for transaction approval, eliminating many of the check points currently being employed.

TARGET routing/transaction:

The term "Target transaction" refers to any request through a BASIS application which requires an approval or approvals. Examples are wage rates and hourly time approval in the Hourly system, and overtime approval in Leave. In the LABOR application, only the PD command requires an approval. These requests are routed by the cost center criterion used also for wage rates and GJIM fund transfers. When you press the PF10 key to save changes you make to a distribution, they are not immediately effected to the database unless you are working under a desk which is the sole approver for the cost centers involved. Normally, your changes will show as proposed ones (status P, pending) until all approvals are in, and the request is electronically routed as a TARGET transaction through the required desks. After the last approval is received, your request will become the actual, current distribution (status E, effected).

Footnotes:
1
This is distinct from the BASIS save action, which uses PF10 to initiate a TARGET transaction, posts changes immediately to the database, or otherwise commits your action.
2
For further information on the use of PF keys in BASIS, refer to Help Topic "PF Key Usage."
Back to Top











Sorry, but your search for documentation yielded No Results.

There is not currently a document devoted specifically to the function for which you requested information.

Use your browser's BACK button (or Click Here) to return to the previous screen.