Transaction Approval & Review Gateway via Electronic Transmission
User Guide
September 15, 1997
BASIS Development Team
University of Arkansas, Fayetteville
Introduction
Overview
Processes: "How-To"
Command Reference: Online Functions
Appendix A. General System Features
Appendix B. System Definitions
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.
The following type/font conventions are intended to make this document
more consistent, and easier to use:
- Field names (both in the banner and in the body of the screen) are
identified in italicized type.
- Column headings or screen segments are also identified in
italicized type.
- 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.
- 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.
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:
- The "Purpose" of the command.
- Which "Key Fields" are required in the banner in order to utilize
the command.
- 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.
- Any field and/or system "Validations" which exist that will affect
the user's processing of the command.
- Comments on how "Processing" of the command works.
- 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.
|
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.
The objectives of the TARGET system can be summarized as
follows:
- 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.
- Employ this architecture in a generic manner such that it can
be implemented in various administrative applications.
This will result in:
- The consistent use and deployment of this technology
across the University community resulting in reduced training and
support requirements.
- Centralized management of control
tables and all transactions.
- Cost savings in the development process due
to the shared use of the design, program code and
system utilities.
- Meet the increasing
demand for electronic forms processing with a system where:
- Data will be completely validated at the point of entry.
- Forms will not have to be printed in order to be processed.
- Transaction information will only have to be keyed once.
- The original transaction will become an
integrated part of the central administrative information
system and the University data base.
- 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.
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:
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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."
- 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.
- 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.
- Several features have been designed into the system to ensure that
the review process is simple and effective.
- Transactions are presented in the chronological order that they
were requested.
Each may be approved, rejected or bypassed and the next transaction
is retrieved automatically for processing.
- To aid in the identification of what is being changed by an
update transaction (a transaction where new data overlays
existing information), the screen displays both the old and the new
values.
The old field values are displayed only when they differ from the
new entries.
They may also be displayed using special features such as reverse video
or color, if that capability is supported by the terminal and
terminal emulation software.
This will allow identification of a field whose old value was blank.
- A summary list function will be available to identify
how many transactions of each type are pending an individual's review.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.)
- 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.
- 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.
- 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.
- 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.
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).
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".
The RG function employs the following validations:
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.
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".
The RC function employs the following validations:
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.
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".
The DRG function employs the following validations:
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.
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".
The CCCR function employs the following validations:
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.
The following sections document the Proxy maintenance function:
- "Purpose"
- "Key Fields"
- "Actions"
- "Special Processing"
- "Related Topics"
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.
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.
|
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 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 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 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.
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 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 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.
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.
- Information on the following topic may be selected after issuing
the command "HELP"
Proxies & their functions -
| This topic summarizes proxies and the functions they perform.
|
- The following commands provide lists associated with proxies.
Help information for these commands may be viewed by pressing PF1
while the cursor is in the "Command" field of these screens.
LDPD -
| A list of Desk IDs for a specific Proxy ID can be displayed for
those proxy assignments effective on a specific date.
|
LDPF -
| A list of Desk IDs for a specific Proxy ID can be displayed for
those proxy assignments effective starting from a beginning date.
|
LPDF -
| A list of Proxy IDs for a specific Reviewer Desk ID
can be displayed starting from a beginning dateŁ
|
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"
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.
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:
- The Department Head or Director
- 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.
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
|
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:
- A common user interface for Natural applications
- Central facilities for displaying menus and processing commands
- Security features needed by most applications
- Maintenance facilities that allow individuals responsible for an
application the ability to administer the security for their system
directly and independently
Additional information on the NSM architecture can be obtained
online by requesting help (pressing PF1) from any
Menu screen.
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:
- Application level help is obtained by entering
"help" in the
Command field on any screen within the system.
A menu of help topics is then provided for selection.
- Screen level help for a function is obtained by placing the cursor
on the Command field (or off of any specific field) and
pressing PF1.
A pop-up window will be displayed allowing the selection
of a help topic, either for the current command or for other
general topics.
The description of the processing performed by the current command,
if selected from the menu, is accessed from the Predict data
dictionary and displayed.
- Element level help is accessed by placing the cursor on the field
desired and pressing PF1 or by entering a "?" in
the field and pressing Enter.
Element level help displays the definition associated with an element
from the Predict data dictionary.
If an element has specific valid values associated with it, those
values will be displayed and a value may be selected and returned to
the field where help was requested.
Similarly, fields that have their values stored on tables or files may
allow specification of a starting value and then provide a list of
values to select from.
Some fields using this special form of help are:
- DeptCatg (Departmental Category)
- Class (Category Class)
- Disallowed Company Type
- Type (Company Type)
- Permitted Funding Types
- Budget Maintenance Restriction CDs
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.
|
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:
- From 01/01/1911 through 12/31/2099 when two digit years are
entered.
- From 01/01/1800 through 12/31/2099 when a fully formatted 8-digit
date with delimiters are 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
|
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:
- 999999999999999
- 9999-99999-99-9999
- 9999-99999-99
- 9999 99999-99
- 99999999999
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.
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:
- 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.
- 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.
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
|
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.
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.
|
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.
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.
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.
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.
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:
- The type of computer system you are running (PC/Mac)
- Your operating system (Mac, Windows 3.x, Windows 95, Unix,
OS/2, etc.)
- Your type of connection (On-campus Networked or PPP dial-up,
dial-up through Voyager, etc.)
- The 3270 software product and version you are running (tn3270,
OnNet 2.1, ProComm Plus, Kermit, PCTCP 2.3, NCSA, Red Ryder,
etc.)
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).
|
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)
|
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)
|
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:
- 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.
- 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.
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.
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:
- Displaying existing application data and outstanding pending
transactions when present.
- Processing the original input data for a transaction complete with
data edits, the enforcement of application security, and saving the
transaction for later review, posting, and audit.
- Presenting pending transactions for review and recording the results
of the review (approval or rejection).
- After all approvals have been obtained, posting the transaction
to the appropriate application data base.
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.
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.
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.
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:
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.
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.
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.
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.
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.
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.
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.
|
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 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.
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 university administration must develop and adopt a policy
endorsing the concept of electronic approval of transactions and
specifically the TARGET system.
- An office and individuals must be designated to maintain the
required routing tables (the review criteria and review groups)
and to act as the central administrator for the TARGET system.
- Campus wide, all offices must receive the appropriate training
to use the new systems that are deployed.
- The individuals designated to review pending transactions must
perform that task in a timely manner.
- Computing Services must provide adequate resources for processing,
storage, maintenance, support and enhancement of the system.
Since these applications will become integral to almost all
administrative processing, added attention may also need to be directed
toward backup, recovery and disaster planning.
- Due to the wider access that will be provided to online administrative
systems, security issues must be emphasized.
Confidentiality of IDs and passwords will need added emphasis, auditing
of computer use activities must be increased, and other policing actions
instigated.
- When position-based security is implemented, detail maintenance
will be required of the association of desks to positions.
In the interim, the association of desks to individuals requires
an even greater level of activity due to personnel changes.
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.
The following points are included to clearly state operational
characteristics or issues which may have only been implied or not stated
to this point.
- 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.
- 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.
- 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.
- If the requestor is also established as a reviewer, based upon the
review criteria, that review status is automatically set to approved.
- 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.
- 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.
- 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).
- 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.
- 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.
- 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.
- 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."