R⋆STARS Data Entry Guide

Chapter #3

Online Procedures

Purpose

This chapter is intended to provide system users with an understanding of the R⋆STARS on-line functions and procedures.

Table Of Contents

3-1   Terminal Operations

Security Features

Terminal Keyboard Functions

Cursor Control Keys

Data Editing Keys

Function Keys

Sign-On Procedures

Menu Navigation

Logoff Procedures

3-2   Transaction Data Entry

Document Preparation

Transaction Codes

Transaction Batching

Batch Header Identification

Batch Control

Batch Header Data Entry

Transaction ID

Transaction Entry Screens

Accounting Transaction Data Entry

3-3   Accounting Transaction Data Entry Examples

3-4   Transaction Split Data Entry

Recurring Transaction Profile

Common Uses of Transaction Split

Transaction Split by Program and Organization

Establishing the 550 profile

Transaction Split Processing

Entering Split Transactions

Split Transaction Inquiry

Correction of Errors

3-5   Financial Inquiry

Balance Types

Calculated Balances

Inquiry Types

Title and Element Look Ups

Summary and Detail Selection Options

Accessing Financial Inquiry Screens

Drill Down Inquiry

3-6   Help, Interrupt And Link Facilities

The HELP Facility

The INTERRUPT Facility

Beginning an INTERRUPT Session

During an INTERRUPT Session

Returning From an INTERRUPT Session

Link Facility

3-1   Terminal Operations

R⋆STARS is an on-line, interactive system providing users with immediate access to accounting information as well as immediate feedback when entering profile maintenance and financial transactions. The on-line update and inquiry capabilities virtuallyeliminate the delays associated with overnight batch editing and update. To make effective use of the on-line features, users must be familiar with the on-line procedures and options available.

This Chapter discusses procedures for entering transactions into R⋆STARS. On-line profile maintenance instructions are described in Chapters 5 and 6.

The topics discussed in this section include:

◾ Security Features

◾ Terminal Keyboard Functions

◾ Sign-on Procedures

◾ Menu Navigation

◾ Log-Off Procedures

Security Features

The security features of R⋆STARS help prevent unauthorized access to on-line functions. There are various levels of security that can be assigned to users. A designated security officer is responsible for establishing and controlling all aspects of security. Based upon the security level assigned to an individual user, the user is able to perform only those functions for which he or she has been authorized. Any questions regarding security should be directed to the agency's designated security officer.

System access is determined by two elements - The RACF ID and the User Password. The RACF ID identifies to R⋆STARS who is entering transactions into the system. It also controls the security level assigned to the user. The User Password is a personal key assigned to the RACF ID to allow access. The User Password should be kept confidential and be easy to remember. The system requires that the password be changed every 90 days to ensure against theft.

When leaving a terminal, the user should log off so that each operator uses only their own RACF ID and password to access R⋆STARS.

R⋆STARS security is discussed in greater detail in the System Management Guide.

Terminal Keyboard Functions

The keyboard resembles a typewriter with additional function keys. These keys perform special functions when communicating with the R⋆STARS application software. This section discusses the Terminal Keys (Cursor Control Keys and Data Editing Keys) as well as the R⋆STARS Function Keys. For purposes of instruction in this manual, it is assumed that a PC with a standard keyboard is using some form of TCP protocol terminal emulation to access R⋆STARS.

Cursor Control Keys

The following keys move the cursor on the screen:

◾ Return ( ↵ Enter ): Moves the cursor to the first entry position on the next line of an unprotected screen.

◾  ← Backspace : Moves the cursor backward within an unprotected (data entry) field erasing the characters in that position.

◾  Tab ↹    Moves the cursor to the first entry position of the next unprotected field

◾ Backtab ( ⇑Shift  Tab ↹ ): moves backward to the next unprotected field

◾  ↵ Enter : Carriages down to the first unprotected field in the next row

◾  Home : Places the cursor in the LINK TO: field

◾ Arrow Up ( ↑ )/Down ( ↓ )/Left ( ← )/Right ( → ): move cursor to next position on the screen (could be either protected or unprotected)

All of the R⋆STARS screens are formatted so that data elements can only be typed in specific fields. The  Tab ↹  and  ⇑ Shift  Tab ↹   keys move the cursor directly from one data element field to another. The  ↓ ,  ↑ ,  ←  and  →  arrow keys move the cursor a space at a time to any position on the screen. The Tab ↹  and  ⇑ Shift   Tab ↹  keys are more effective navigation tools since they will position the cursor at the beginning of the data entry fields.

Data Editing Keys

The following keys are available to the user to edit the data on the screen:

◾  Insert : In Insert mode, date entered does not overwrite current data, but will “push” it farther along in the field.

Note: if field locks while in insert mode, the field is full. Press  Insert  again to undo  Insert  and unlock field.

◾  Delete : Removes the character at the cursor’s current position (the remainder of the line shifts one character position to the left)

◾  ⇑ Shift : Selects upper characters on dual-character keys, uppercase characters for alphabetic keys, or to turn off shift-lock feature

◾  Caps Lock : Locks keyboard into uppercase mode

Note: R⋆STARS screens are not case sensitive. Characters can be entered in either lower- or uppercase mode. During processing, all characters are eventually re-displayed and saved in uppercase.

Function Keys

Function keys perform special activities based on the on-line program. Functions for each key may vary depending on which screen is used.

In R⋆STARS, Function Keys primarily perform the following functions:

◾ ENTER: Used to retrieve data on a screen. For example, on profile screens, it is pressed after key information is entered to display the specific profile record.

◾ CLEAR: Returns the user to the menu.

◾   F1  :

◽ Help –  Automatically links to the 90 – News/Help Profile. The appropriate type of help record (screen help or error code help) is automatically retrieved, depending on the activity previously performed by the user before pressing   F1  .

◽ Selection Help -  If the user is on a financial data entry screen and the cursor is positioned in any one of the following fields:  Index, PCA, Comptroller Object, Agency Object, Vendor Number or Vendor Name, the corresponding selection help screen is displayed.

◾   F2  : Primarily used to transfer the user to another screen that has some association with the originating screen. If data is displayed on the originating screen, that information is carried to the new screen. Used to access the 520 – View a Batch screen from the 530 – View Batch Headers screen.

◾   F3  : Primarily used to delete records from the database. In addition, it is used for retrieval of recurring transaction records during financial data entry or to transfer the user back to the originating screen during a drill down inquiry.

◾   F4  : Primarily used to perform data look-ups and access Reference Document information during financial data entry. In addition, it is used to transfer to another screen that has some association with the originating screen.

◾   F5  :  Primarily used to recall the next record in the database with the next greatest key value. In batch processing, executes interrupt to 37 - Document Tracking Inquiry.

◾   F6  : Primarily used to 'toggle' from A and B versions of screens and to access the 502 – Batch Balancing screen.

◾   F7  : Primarily used to scroll to a prior page of data on screens that display lists of information. Also used to access 520 screen during batch processing.

◾   F8  : Primarily used to scroll to the next page of data on screens that display lists of information. In batch processing, executes interrupt to the 37 screen.

◾   F9  : (Interrupt): Found on almost all R⋆STARS screens. It initiates an active interrupt to another screen and ends an active interrupt by returning the user to the original screen.

◾  F10 : Primarily used to save (commit) newly entered or changed records in the database. During this function, the data remains on the screen.

◾  F11 : Primarily used to save (commit) newly entered or changed records in the database. During this function, the data is cleared from the screen. Also used to open a new batch once a batch has been released within batch processing.

◾  F12 : Primarily used to access the 530 screen from financial data entry and document tracking screens.

For those keys whose functions vary by screen, look at the function key menu at the bottom of the screen or the screen help record to determine the specific function performed.

Sign-On Procedures

When the user opens the mainframe connection to R⋆STARS, the first screen visible will have a list of system regions. These regions are areas set aside in the system to accomplish certain tasks. The main production region for SFMS is E23 - DASCICSP.

Sample logon procedures:

Type e23 at the bottom of the screen and press  ↵ Enter .

Example:

Press the  Pause/Break  key while in the CICS screen. The screen will clear and the Cursor will be in the home position.

Type cesn and press  ↵ Enter . The Login Screen will appear.

Example:

Type in the RACF ID and password in the appropriate fields and press  ↵ Enter . The following line will appear in the home position.

Type fsys and press  ↵ Enter .

Example:

The following screen should appear.

Example:

This screen allows the user to choose a User Class. A User Class determines the accessible screens and the accounting functions allowed on those screens. If the RACF ID has more than one valid User Class, the lowest numerical value will default. Type the desired User Class or use the default and press  ↵ Enter .

The News Display appears next. The user should always check the News Screen for important information such as programming schedules and projected down time.

Example:

Press  ↵ Enter  to proceed to the R⋆STARS Main Menu.

Example:

Menu Navigation

The Main Menu is the focal point of user interaction with the system. All other menus used in R⋆STARS are selected from this menu. Note that the Main Menu provides a function key (number in parentheses) corresponding to each of the major system functions.

Submenus are selected in one of three ways:

◾ Press the corresponding function key (e.g., press   F2   to access the Cost Accounting Submenu).

◾ Tab down to the desired menu option and press  ↵ Enter .

◾ Enter the submenu ID in the LINK TO: field and press  ↵ Enter .  (See Section 3-6 for further discussion of the link facility).

The following screens illustrate the menu navigation process using the Financial Data Entry submenus as an example.

Example – Financial Data Entry:

From the Main Menu, select the Financial Entry submenu using one of the three options described above.

Example:

The Batch Header Entry screen can be accessed by pressing   F2  , by tabbing to the Batch Header Entry line and pressing  ↵ Enter , or by entering 500 in the LINK TO: field and pressing  ↵ Enter  as shown below.

Example:

The system will display the 500 – Batch Header Entry screen as illustrated below. The user is now ready to input batch header information.

Example:

Logoff Procedures

As previously discussed, log off the system when not in use. Logging Off is relatively simple.

Press  Pause/Break  to return to any menu or submenu. For example, from the 500 screen, press  Pause/Break  to return to the Financial Data Entry Menu.

Type quit or exit in the LINK TO: field and press  ↵ Enter .

Example:

The Following Screen will appear.

Example:

Type over the c in CESF and press  ↵ Enter .

3-2   Transaction Data Entry

This section describes the various procedures involved in accounting data entry with emphasis placed on those procedures performed by users entering data on line.

This section provides information on the following:

◾ Document Preparation

◾ Transaction Codes

◾ Transaction Batching

◾ Batch Header Identification

◾ Batch Control

◾ Batch Header Data Entry

◾ Accounting Transaction Data Entry

◾ Data Element and Function Key Definitions

◾ Detail Coding Instructions

◾ Batch Balancing

Document Preparation

Document preparation is the responsibility of the agencies (see OAM 10.15.00.PO for further guidance). Transaction input forms are optional but recommended especially when doing adjustment transactions. Most agencies use data input forms of one type or another containing all required and optional data elements.

Transaction Codes

A Transaction Code (T-Code) is a three-digit profile record that determines the accounting impact (debits and credits) of each financial transaction entered. It determines which data elements are required, optional or not allowed on each transaction.

T-Codes are established and defined in the 28A – Transaction Code Decision Profile. They are described in the 28B – Transaction Code Description Profile . A listing of each available T-Code can be requested with following reports:

*Used Most frequently

 28A – Transaction Code Decision Profile

Example:

The elements of the 28A profile are described below:

◾ TRANSACTION CODE (TRAN CODE) – A three-digit number that uniquely identifies all the elements in a particular T-Code Profile. Similar T-Codes are grouped together in transaction types:

◾ TITLE – A descriptive title describing the purpose and effect of the transaction code.

◾ GENERAL LEDGER POSTING – Up to four pairs of debits and credits can be entered to determine the general ledger accounting impact; however, the fourth pair is reserved for document liquidations against pre-encumbrance and encumbrance accounts only. It is possible to leave one side of the first debit/credit pair blank. This is done when more than one GL account is used as the debit or credit. The appropriate general ledger account is entered on the transaction. General ledger accounts or ranges of accounts allowed for entries are listed in the 28B profile preceded by an I (include). Specific General Ledger accounts not allowed may also be listed, but preceded by an E (exclude). When one half of a pair is left blank, the General Ledger Account Edit Indicator (described below) must be set to I. This capability offers significant flexibility, but must be used carefully due to the financial impact.

◾ TRANSACTION EDIT INDICATORS (TRANS EDIT INDS) – A one-character edit indicator is entered to control whether data elements that impact a transaction are required, not allowed, or optional. Valid values are:

The transaction edit indicators affect the following data elements:

System Processing Indicators:

◾ Posting Sequence Indicator (POST SEQ) – Determines the order of transactions posting during the batch update cycle. For example, a value of 1 will always post before a value of 2, etc. Oregon posting sequences are:

◾ Register Number (REG NO) – Specifies on which transaction register (control report) the transaction will be reported. Oregon values are:

◾ Warrant Writing Indicator (WW IND) – Classifies the type of transaction as payment or non-payment,which determines whether or not a warrant will be issued.

◾ Direct/Indirect Indicator (D/I) – Determines whether the transaction is entered directly into the system or generated by the cost allocation subsystem.

◾ Warrant Cancellation Transaction Code (WAR CANCL TC)  – Identifies the T-Code used by the Payment Processing Subsystem to generate cancellation transactions. Must exist in the 28A profile.

◾ Prior Year Transaction Code (PYTC – Not used in Oregon ) – Used in place of the T-Code in the key for transactions with Effective Dates in the prior year.

◾ Future Month Indicator (FUTMY) – Determines whether the T-Code can be used on future dated transactions. Y = Yes   N = No

◾ Generate Transaction Code (GEN-TC) – Determines if a second transaction is to be generated during the next batch cycle. The field contains the number of the T-Code that will be used for the generated transaction. The T-Code must exist in the 28A profile.

◾ Generate Document Type (GEN-DT) – Defines the document type used for the current document number of generated or generated accrual transactions. Oregon document types are GT (Generated Transactions) or GA (Generated Accrual Reversal).

◾ Generate Accrual Transaction Code (ACCR TC) – Identifies the T-Code that will be used to reverse the transaction on the first of the month following the Effective Date on the original transaction. In Oregon, this field is primarily used to reverse SARS reclassification transactions at year-end, but can be used throughout the year.

◾ Treasury Users Transaction Code (TR TC – Not used in Oregon) – Identifies the T-Code for transactions needed by the Treasurer's Office. Must exist in the 28A profile.

◾ INTERFACE IND(icator) – There are ten Interface Indicator fields. Oregon is currently using two of them. The first field (position) is a Treasury indicator. Not all T-Codes have a Treasury indicator. This position indicator determines how and if the transaction interfaces to the Treasury. Valid indicators for the first position are as follows:

The second field (position) is the cash reconciliation indicator. The cash reconciliation reports use this  indicator to separate and subtotal the different types of transactions. These breakdowns then correspond to the reports Treasury produces for their indicator types. Not all transaction codes need this indicator. Codes currently used are as follows:

◾ Payment Liquidation Transaction Code (PAY LIQ TC) – Identifies the T-Code used by the Payment Processing Subsystem to liquidate vouchers payable. Must exist in the 28A profile.

◾ Payment Redemption Transaction Code (PAY RED TC) – Identifies the T-Code to be generated when warrants are redeemed at the bank. Must exist in the 28A profile.

◾ Cumulative Post Indicator (CUM POST IND) – Determines whether posting is to the current fiscal month only (Y) or to the current fiscal month and all thereafter (N).

◾ Balance Transaction Code Indicator (BAL TC) – A T-Code required for balancing transactions. A balance T-Code requires that the opposite transaction(s) be entered with the same Current Document Number to balance and release the batch. The T-Code entered in the BAL TC field must exist in the 28A profile.

◾ Add/Subtract Document Amount Indicator (A/S DOC AMT)  – A one-character field (+ or –) that indicates whether the transaction amount will be added or subtracted to calculate the document amount. This allows the document amount to be a net mount rather than an absolute value. If the transaction entered is reversed (reverse code R), this indicator will be reversed in the calculation of the document amount.

◾ Financial Table Posting Indicators (FILE POSTING INDS) – This segment of the profile contains the rules for posting the transaction to the R⋆STARS financial tables. All transactions also post to these tables:

◽ General Ledger

◽ Summary GL

◽ Accounting Event

◽ History File

In addition to determining the financial field to be posted, this segment of the profile determines:

◽ Whether the transaction is an increase or decrease to the Balance Type.

◽ Whether the transaction requires a match (or a match is not allowed) to a previously entered record in the table.

◽ The general ledger account used to post the transaction.

◽ The document used to post the transaction (current or reference document number).

The File Posting Indicator abbreviations are:

*The AGY GL determines which of the eight COMP GL Accounts above in the General Ledger Posting section will be supported by an Agency General Ledger Account if entered on the transactions.

The remaining elements in the 28A Profile are:

◾ A/S – + adds or increases normal balance. – subtracts or decreases normal balance.

◾ BT – Balance Type as defined in the D05 – Balance Type Profile.

◾ MATCH  – Primarily used for the DF, AP and AB tables to ensure that documents and appropriations are correctly updated.

◾ GLA – Identifies which GL account from the General Ledger Posting section is used to post to the table. Also identifies which GLA is supported by the Agency GL Account entered on the transaction entry screen.

◾ DOC – Determines the Posting Document Number to be used to post to the DF Table indicator. Valid values are:

 28B – Transaction Code Description Profile

Example:

This profile provides textual comments for T-Codes established in the 28A profile, and defines processing rules related to Document Types (33 – Document Control Profile), Batch Types ( D54 – System Parameters Profile – Table ID: BTYP), valid/invalid GL Accounts (D31 – Comptroller General Ledger Account Profile) and valid/invalid Comptroller Objects (D10 –  Comptroller Object Profile).

Shown below are examples of the 28A and 28B profiles displaying T-Code 222 to record accounts payable, not encumbered.

Example:

Example:

Transaction Batching

All transactions are entered into R⋆STARS via a batch created by the agency. Data input is arranged into batches by Batch Type for documentation and control. Transactions within a batch are identified by the Batch ID which includes the elements described in the next section.

Batch Header Identification

A Batch ID is comprised of four elements:

◾ Batch Agency – the three-digit agency code.

◾ Batch Date – the date the batch is created or entered.

◾ Batch Type – groups like transactions together.

◾ Batch Number – a three-character identifier assigned to each batch by the agency.

Batch Control

It is recommended that each organization maintain a Batch Control Log to track all batches input into R⋆STARS. The log includes the Batch Agency, Batch Date, Type, Number, Batch Count and Batch Amount, to verify against the DAFR2201 Batch Summary Report (a control report) automatically generated by the system. Most agencies assign blocks of numbers for specific units or purposes (e.g., 000-099 for Receivables Section, 100-199 for the Disbursements Section, etc.)  Prepare a batch by grouping all data input forms by batch type. Assign a batch number to each group.

Batch Header Data Entry

From the Main Menu select the Financial Data Entry submenu by either pressing a function key (   F4  ), entering a submenu ID (FIN) in the LINK TO: field or tabbing to that submenu line and pressing  ↵ Enter . From the Data Entry submenu, the operator selects option 500 Batch Header Entry (by pressing   F2  ) or by typing 500 in the LINK TO: field and pressing  ↵ Enter ).

Generally, based on the User’s 96A/96B Security Profile, the Agency number defaults on the Batch Header and the cursor is positioned at Batch Date. Otherwise, the cursor will begin at the Batch Agency field and the user will be required to either enter the Agency number manually or press  F10  to retrieve the Agency in the security record. Agency 000 is a Security Agency and cannot be used as the Batch Agency.

An example of the 500 screen is shown below:

Example:

500 – Batch Header Input Screen Coding Instructions

Batch header information must be entered before any accounting transactions in the batch can be recorded. The detailed Batch Header input coding instructions are as follows:

◾ BATCH AGENCY – This field is required, but it will default or can be input as explained above. The Batch Agency number used must exist in the D02 – Agency Profile.

◾ BATCH DATE – Enter the six-digit BATCH DATE in MMDDYY format. If left blank, this field defaults to the 97 – System Management Profile Current Effective Date.

◾ BATCH TYPE – Required. Enter the one-character BATCH TYPE. The Batch Type determines which data entry screen will be retrieved by the system after the batch header is saved. Some of the valid Batch Types for data entry and the screens they access are:

There are also system-generated batch types. All Batch Types are defined in the 90 table under the keyword BATCHTYPE.

Each batch should contain only one type of transaction. The Batch Type must be valid for all of the transactions in the batch. Valid Batch Types for each T-Code are shown in the 28B Profile.

◾ BATCH NUMBER – Required. Enter the three-character BATCH NUMBER, which is a unique sequential number for each batch type.

◾ BATCH COUNT – Optional. Enter the total NUMBER OF TRANSACTIONS in the batch (up to a five-digit number). Do not count the Batch Header as a transaction. This field is used with the batch balancing feature.

◾ BATCH AMOUNT – Optional. Enter the total AMOUNT of all transactions in the batch (up to 11 digits with a two-digit decimal). This is an absolute amount that does not consider positives or negatives. For example, if a companion transaction is entered to move $500 out of one fund and into another, the batch amount will be $1,000 even though the document amount is zero (+500/-500).

Like the BATCH COUNT, this field is used with the batch balancing feature. The BATCH COUNT/AMOUNT figures are compared to the COMPUTED COUNT/AMOUNT fields (totals from transactions displayed on the Batch Balancing Screen) to determine if the batch is in balance. If the BATCH COUNT/AMOUNT are not entered, they are derived from the count and amount of the transactions.

◾ BATCH EDIT MODE – The BATCH EDIT MODE indicator will default based on the operator's security record. Valid Edit Mode Indicators are:

◽ If the user's security record has a 0 Edit Mode Indicator, the default is 0 and it cannot be changed.

◽ If the user's security record has a 1 Edit Mode Indicator, the default is 1 and it can be changed to 0.

◽ If the user's security record has a 2 Edit Mode Indicator, the default is 2, and it can be changed to 0 or 1.

◾ PAYMENT DIST(ribution) TYPE – The Payment Distribution Type (PDT) entered here will override the PDT used on 51 – Vendor Mail Code Profile records. If this field is left blank, the default will not appear on the batch header, but will default on each transaction from the 51 profile. It is recommended that the PDT be allowed to default because a manually-entered PDT will override codes on vendors that have direct deposit. The PDT must exist in the D50 – Payment Distribution Type Profile.

◾ DISB(ursment) METH(od) IND(icator) - Enter the one-character indicator as follows:

◾ EFFECTIVE DATE - Defaults to the 97 profile Current Effective date in MMDDYY format. May be overridden on the Batch Header or on individual transactions within the batch. This element determines the accounting period of the transaction.

◾ FAST ENTRY – Enter the one-character FAST ENTRY indicator to bring up the fast entry screens indicated below:

◾ ACTION CODE AGENCY (Not used in Oregon) – Enter the three-character AGENCY for the Agency authorized to input the associated action code.

◾ ACTION CODE (Not used in Oregon) – Enter the three-character ACTION CODE. Must exist in the D44 – Action Code Profile. The Action Code Agency and Action Code will default from the user's security record if not entered. 

Transaction ID

The information entered on the batch header is automatically included on every transaction entered for that batch. R⋆STARS automatically assigns a Sequence Number to each transaction within the batch which, when appended to the Batch ID, creates the Transaction ID. The Transaction ID contains the following elements:

In other words, every transaction recorded in R⋆STARS is uniquely identified by the Transaction ID.

Transaction Entry Screens

When all the elements from the Batch Header have been entered, press  F10  or  F11 . This will save the batch header data and retrieve one of the financial transaction entry screens. Examples of the transaction screens are shown below.

◾ 501 – Journal Voucher Transaction Entry. This screen is accessed from the Batch Header screen when a Batch Type 5 is entered.

Example:

Features:

◽ Single transaction entry per screen

◽ All edit modes allowed

◽ Allows all elements needed to process journal voucher transactions

◾ 503 – Budgetary Transaction Entry. This screen is selected when Batch Type 1 is entered in the Batch Header.

Example:

Features:

◽ Single transaction entry per screen

◽ All edit modes allowed

◽ Allows all elements needed to process budgetary transactions

◾ 504 – Revenue/Receipts Transaction Entry. This screen appears when Batch Type 2 is entered in the Batch Header.

Example:

Features:

◽ Single transactionentry per screen

◽ All edit modes allowed

◽ Allows all elements needed to process revenue/receipt transactions

◾ 505 – Pre-Enc/Enc Expend Transaction Entry. This screen is retrieved when entering Batch Type 3 or 4. This screen is used to enter pre-encumbrances, encumbrances and expenditures.

Example:

Features:

◽ Single transaction entry per screen

◽ All edit modes allowed

◽ Allows all elements needed to process pre-encumbrance/encumbrance/expenditure transactions

◾ 506 – Single Vendor Fast Entry. This screen is intended for input of vouchers which do not require online entry of optional elements such as Agency Code 1, Grant, and Multipurpose Code. The 506 screen provides an efficient method for voucher entry of similar repetitive transactions. This screen is accessed by typing s in the Fast Entry field on the Batch Header screen. The Edit Mode must be either 0 or 1.

Example:

Features:

◽ Multiple transaction entry on one screen

◽ Limited to Edit Modes 0 and 1 (no on-line posting)

◽ Multiple coding blocks for single vendor and invoice number

◽ Limited coding block elements

◽ Example use:  Phone bill with multiple accounting distributions

◾ 507 – Multiple Vendor Fast Entry.   This screen is accessed typing m in the Fast Entry Field on the Batch Header screen. This screen is intended to be used for payments with similar coding elements to multiple vendors. The Edit Mode must be either 0 or 1.

Example:

Features:

◽ Multiple transaction entry on one screen

◽ Limited to Edit Modes 0 and 1 (no on-line posting)

◽ Single Reference Document, Transaction Code, Index and PCA with multiple coding blocks for vendors, objects, and cur doc/ref doc suffixes

◽ Limited coding block elements

◽ Example use:  A batch of bills with multiple vendors and/or objects payable by the same program/organization (Index/PCA)

◾ 508 – Multiple Invoice Fast Entry. This screen is accessed when an I is present in the Fast Entry Field on the Batch Header screen. This screen is intended to be used for multiple invoices with similar coding elements to a single vendor. The Edit Mode must be either 0 or 1.

Example:

Features:

◽ Multiple transactions on one screen

◽ Limited to Edit Modes 0 and 1 (no on-line posting)

◽ Single vendor and coding block with multiple lines of invoice information for remittance advice

◽ Coding block less limited than Screens 506/507

◽ Example use:  more than one invoice for a single vendor, with need for each separate invoice to show up on the remittance advice

◾ 509 – Companion Transaction Entry . This screen is selected when a Batch Type G is entered in the Batch Header. This screen is used for entering two related transactions where the T-Codes require a BAL TC.

Example:

Features:

◽ Two transactions entered on one screen

◽ Ensures that balanced transactions are balanced

◽ All edit modes allowed

◽ Allows all elements needed to process balanced transfers

◾ 516 – Open Document Fast Entry . The Open Document Fast Entry screen is intended to be used for cash received against open receivables or voucher payables against open encumbrances. Suffixes with a non-zero document balance within a document are retrieved all at once and easily paid or liquidated. For example, a user may retrieve numerous suffixes (or transactions) related to a Reference Document that set up an Accounts Receivable, and easily liquidate them all against one cash receipt. The screen is accessible from the 500 Batch Header screen by typing a p in the Fast Entry field. Unlike other fast entry screens, this screen will be available for use in Edit Mode 0, 1 or 2.

Example:

Features:

◽ Multiple transactions on one screen

◽ All edit modes allowed

◽ Single vendor and invoice with multiple, limited coding blocks

◽ Example use:  when writing a voucher against all lines of an encumbrance, this screen does not require the user to enter each line of the document

Accounting Transaction Data Entry

If the information on the batch header is valid, R⋆STARS automatically retrieves one of the nine transaction entry screens. When the transaction entry screen appears, transactions may be entered. The key fields from the batch header are automatically carried forward at the top of each screen, and the sequence number automatically advances one number for each transaction entered. The cursor is positioned at the first data element on the screen. Batch header elements are displayed for information only and cannot be changed.

The screen may contain many blank fields, as some transactions require only a few data elements. For document types defined in the D59 – Current Document Number Increment Profile, the document number can be automatically assigned by entering the document type in the CUR DOC field on the transaction entry screens. The document suffix is also automatically incremented.

Data Element and Function Key Definitions

When the required data elements are entered, press   F4   to edit the data, or press  F10  or  F11  to commit the transaction to the system. The   F4   key does not post the transaction. It edits the transaction for required fields and valid values, and fills in certain looked up elements. The  F11  key commits the transaction and returns an empty screen. The  F10  key commits the transaction, increments the document suffix and batch sequence number and is ready for the next entry. All data fields from the previous transaction remain embedded and available for the next transaction, whether they are visible on the screen or not, with the exception of the Transaction Amount field, Reverse indicator, and Fund Override indicator, which are blank. Function keys are discussed in further detail below.

◾ Function Key 4 – Edit on Transaction Data Entry Screens. If   F4   is pressed and the edit mode of the batch is 1 (data edits) or 2 (data edits and financial table posting) the following functions are performed:

If the transaction requires a matching Document Financial Table record, a Reference Document/Suffix must be entered. Before pressing   F4  , the user must enter the two-digit DOC TYPE, the REFDOC/SFX and amount. Pressing   F4   will then retrieve all the classification elements of the referenced transaction. The following elements will be retrieved if they exist:

Along with retrieving the essential reference/look up data, pressing   F4   initiates the following edits:

◽ Edit Agency. This step edits the agency on the transaction to ensure the agency is compatible with agencies identified on the user's 96A/96B profile. It also edits whether the agency is on the D02 profile.

◽ Edit Index Code. This step edits the Index (24 – Index Code Profile), if entered or looked up, in combination with the Agency and Appropriation Year to determine that it is valid. Then it retrieves any look-up values, such as PCA, Grant and Phase, Project and Phase, etc.

◽ Edit PCA. This step edits the PCA ( 26 – PCA Profile), if entered or looked up, in combination with the Agency and Appropriation Year to determine that it is valid. Then it retrieves any look-up values such as Index Code, Grant and Phase, Project and Phase, etc.

◽ Edit Comptroller Object. This step edits the Comptroller Object (D10 profile), in combination with Appropriation Year, to determine that it is valid.

◽ Edit 1099 Indicator. This step edits the 1099 indicator on the transaction (defaults from the D10 profile).

◽ Edit Subgrantee. The Subgrantee ( 31 – Subgrantee Control Profile) is edited and a Grant Number/Phase is potentially retrieved.

◽ Edit Project Number. The Project Number is edited ( 27 – Project Control Profile and D42 – Project Number Profile) and Grant Number/Phase are potentially retrieved.

◽ Edit Grant Number. The Grant Number is edited ( 29 – Grant Control Profile and D47 – Grant Number Profile) and Project Number/Phase are potentially retrieved.

◽ Edit Vendor Number/Mail Code. The Vendor Name and Address information is retrieved (51 and 52 – Systemwide Vendor profiles).

If a required Reference Document is entered and   F4   is pressed, all classification elements from the reference document are retrieved and marked as input. This means that the transaction screen interprets the retrieved data as if it were entered by the user.

Caution should be used to prevent incorrect classification element values from being carried forward to new transactions. If  F10  is used to commit the transaction, most data elements from the previous transaction remain embedded on the screen.  F11  can be used to commit the transaction and clear the screen. When the next transaction is entered,   F4   can then be used to retrieve the new classification information. A full edit of the transaction (all data edits) and fund control edits and financial table posting are performed if  F10  or  F11  is pressed and the edit mode is 2. If the edit mode is 0 or 1, these edits are performed during the nightly IEU cycle.

◾ Function Key 10 – Process (Commit) Transaction Data Entry.   If  F10  is pressed and the transaction is successfully posted, the following look up information from the 24 profile or the 26 profile either remains blank or is changed to blank on the screen:

If  F10  is pressed and errors are detected, the system will continue to display the items listed above. The only look up information that is not displayed is the Multipurpose Code. If any of the look up information was manually entered on the screen, the information is redisplayed. Elements not manually entered are erased.

Note:  When   F3   is pressed and a Recurring Transaction Index (RTI) value is entered, any elements retrieved from the 550 – Recurring Transaction Profile act as if they were entered. After the data is retrieved and  F10  is pressed, any of the non-blank elements retrieved from the 550 profile are redisplayed.

Detail Coding Instructions

A comprehensive list of all the elements from all of the transaction entry screens and the coding instructions for each is provided. Coding elements are required, not allowed, or optional as indicated on the 28A and 28B T-Code profiles. Also, indicators on other profiles throughout R⋆STARS may determine the coding requirements. As it is applicable, these rules are discussed.

The following elements are required on all transactions regardless of the T-Code used:

◾ Amount

◾ Effective Date

◾ Agency

◾ Transaction Code

◾ Appropriation Year (AY)

Below are definitions of R⋆STARS data entry fields. These elements may be found on only one type of transaction screen, or on all of them. Refer to the transaction entry screens themselves to see which data elements they contain.

◾ 1099 – This defaults from the D10 profile. The one-character indicators are as follows:

◾ ADDRESS LINE 1 – 4 (ADDR 1 – 4) – These 50-character fields identify the postal address of the vendor and may contain internal routing instructions. ADDR-1 is required if a vendor name is entered or looked up. These fields are manually input when the vendor number begins with 9. They are normally populated (inferred) based on the Vendor Number and Mail Code entered. VENDOR NO/MAIL CODE must exist on the 34 –  Agency Vendor Profile or the 51 profile.

◾ AGENCY – A three-digit required field. When entered or inferred, it must exist in the D02 profile.

◾ AGENCY CODE 1 (AGY CD 1) – A four-digit agency-defined field. It must exist in the D26 – Agency Code 1 Profile. Commonly used with grants. The grants must exist in the 29 profile. It may be inferred from either Index or PCA, or entered manually.

◾ AGENCY CODE 2 (AGY CD 2) – A four-digit agency-defined field. It must exist in the D27 – Agency Code 2 Profile. Commonly used with projects. The projects must exist in the 27 profile. It may be inferred from either Index or PCA or entered manually.

◾ AGENCY CODE 3 (AGY CD 3) – A five-digit agency-defined field. It must exist in the D36 – Agency Code 3 Profile. In Oregon, this field is required for the deposit reconciliation process. It may be inferred from either Index or PCA or entered manually.

◾ AMOUNT – Enter up to an 11-digit transaction amount. The last two digits are decimal places. AMOUNT (also known as TRANS AMT) is required for all transactions. If the amount is entered as 1000, 10. or 10.00 the result in each case is 10.00.

◾ AMOUNT (AMT) TO DISTRIBUTE – A 13-digit field available only on the 516 screen. The amount to distribute is an amount that is edited against the Reference Document Amount. It will be distributed among the Reference Document transactions in sequence by suffix.  If the amount to distribute is greater than the Reference Document Amount, a balancing transaction is created and all of the transactions within that document will have a modifier of F indicating that they were fully paid. Any remaining amount is used to record revenue that was not accrued or expenditures that were not encumbered. If the Amount to Distribute is less than the Reference Document Amount, then all remaining transactions after the exhaustion of the Amount to Distribute will have an amount less than the document/suffix balance or a zero balance indicating that the money received was not used to offset their balances. Zero dollar transactions have no financial impact.

Thus, those particular Reference Document suffixes will remain outstanding and have a modifier of P, indicating that they are partially paid. By having the amount to distribute as an amount separate from the Document Amount, multiple Reference Documents can be included on a single current document number.

◾ APPROPRIATION NUMBER (APPN NO) – A five-digit code generally looked up by the Index or PCA. It must exist in the 20 – Appropriation Profile. This field identifies each budgeted line item in legislative appropriation bills as well as other appropriated items belonging to the agency.

◾ APPROPRIATION YEAR (AY) – A two-digit required field. The system automatically defaults to the default appropriation year identified in the 97 profile. Appropriation Year (also known as Biennium) identifies the year for which Funds were appropriated by the legislature.

◾ BANK NAME (BANK) – A 13-digit field.

◾ BANK ID  – A two-character field. The ID entered must exist in the D56 – Bank ID Profile.

◾ CHECK NUMBER (CHECK #) – A nine-character alphanumeric field. This is usually an optional field on cash receipt transactions. The WARR transaction edit indicator on the 28A profile corresponds to both the CHECK # element on the 504 screen, and the WARR NO element on the 505 screen. If the WARR transaction edit indicator on the 28A profile for the T-Code being used is set to I (input), the CHECK Number is required.

◾ CAPITALIZED/INVENTORIED (CI) – Enter a one-character indicator as follows:

The CI indicator is used by agencies who use the Fixed Asset Subsystem (FAS). It identifies whether the purchased item is to be capitalized or inventoried, or whether the transaction is for maintenance expense on capitalized assets. The Fixed Asset Indicator on the 25 – Agency Control Profile determines whether an Agency is using the FAS. The Comptroller Object and Agency Object entered on the transaction determine the CI value. For example, if the CI Indicator on the D10 profile is C, the 25 FA Indicator is Y, and the transaction amount is greater than the capital threshold amount, the CI Indicator on the transaction defaults to C. If entered, the PROPERTY NUMBER must also be entered unless the transaction is from ADPICS. This element is not currently being used in Oregon.

◾ CITY – A 20-character field usually inferred from the Vendor Number and Mail Code. For non-US vendor addresses, the country is substituted in this field.

◾ COMPTROLLER OBJECT/AGENCY OBJECT (COMP/AGY OBJ) – Two separate four-digit codes usually adjacent to each other. If the Comptroller Object is entered, it must exist in the D10 Profile. If the Agency Object is entered, it must exist in the D11 – Agency Object Profile. As a common practice, most users enter the AOBJ since the AOBJ’s D11 profile carries the appropriate D10 profile COBJ into the transaction with it.

The 28B Profile defines the range of Comptroller Objects allowed depending upon the type of transaction. For example, when a revenue (batch type 2) transaction is recorded, only a revenue type Comptroller Object (0001 - 2999) would be valid.

Whether or not an Agency Object is required is determined by the Agency Object Indicator in the 25 profile. If the Agency Object Indicator is N, the Agency Object is not allowed. If the indicator is R (Revenue), E (Expenditure), or B (Both), the Agency Object may be required depending on the type of transaction.

◾ CONTRACT NUMBER (CONT NO) – A ten-character code. It must exist in the 30 – Contract Control Profile.

◾ CURRENT DOCUMENT/SUFFIX (CUR DOC/SFX) – Codes up to Eight Characters and three digits long respectively. The first two digits of the CUR DOC/SFX are the Document Type. The Document Type must exist in the 33 profile. The valid Document Types for each T-Code are defined in the 28B Profile.

Note:  As described earlier, the D59 profile enables individual agencies to establish automatic document numbering for each document type. When auto-incrementing is used, only the two-character Document Type is entered in the CUR-DOC/SFX field; the remaining spaces are left blank.

◾ INVOICE (INV) DATE (also DT) – Enter a six-digit INVOICE DATE in MMDDYY format or leave blank.

◾ DEFAULT TRANSACTION CODE (D-TC) – A three-character optional code that will determine the accounting distribution for all the transactions in sequence for the Current Document. This data element is found only on the 516 screen.

◾ DEPOSIT # – An alphanumeric code up to 14 characters in length. The INVC (Invoice Number) transaction edit indicator on the 28A profile record corresponds to both the Deposit Number on the 504 screen and the Invoice Number on the 505, 506, 508 and 516 payment screens. If the INVC transaction edit indicator on the 28A profile for the T-Code being used is set to I (input), the DEPOSIT Number is required.

◾ DESCRIPTION (also DESC) – Up to 30 characters. Agencies may code this field as desired in order to provide information about the transaction being entered. On a payable transaction, information entered in the Description field will be printed on the payment remittance advice of warrants or on the ACH website for direct deposits.

◾ DISCOUNT AMOUNT (DISC) – A 13-digit amount field. The last two digits are decimal places. This element is for informational use only; it does not reduce a payment made to a vendor.

◾ DISCOUNT DATE (DISC DT) – A six-digit date field in MMDDYY format for informational use only.

◾ DOCUMENT AGENCY (DOC AGY) – Defaults to the batch Agency. It must be in the D02 profile. The DOC AGY represents the Agency that created and is responsible for the document. It is a required element for tracked documents. Note:  It is strongly recommended that the user DOES NOT override the DOC AGY.

◾ DOCUMENT AMOUNT (DOC AMT) – A 13-digit amount field.  The last two digits are decimal places. DOC AMT is required if the document type requires balancing as defined in the 33 profile. It is the total of all transactions entered for the current document. For Batch Balancing, the calculated total of the document must equal the entered DOC AMT in order for the batch to be balanced and released. The same data entry rules apply as before with the AMOUNT field.

◾ DOCUMENT (DOC) COUNT – A system-generated field that will automatically increment. It counts the number of transactions entered for the current document.

◾ DOCUMENT (DOC) DATE – A six-digit date field in MMDDYY format. This element typically identifies the date the document was created. It is optional for most transaction codes, as defined in the 28A profile.

◾ DUE DATE – A six-digit date field in MMDDYY format. Required for payment transactions, this element identifies the date a warrant or direct deposit will be generated if the transaction is error-free and  released/approved.

For accounts receivable transactions, this element identifies the date by which payment is due from the customer. The user can either enter the date on which accounts receivable are due or allow the due date to default to the effective date plus an agency defined number of days. In order to use this default date feature, the Due Date indicator on the 28A profile must be set to R and the A/R DEF DUE DAYS  on the 53 – Agency Document Control Profile must indicate the number of days (up to 999) to be added to the effective date.

◾ EFFECTIVE (EFF) DATE – This field defaults to the current date on the 97 profile or to the entered effective date on the 500 screen. This six-digit field is in MMDDYY format. A different date may be entered on each transaction within a batch; entered dates will override the batch header default or entered date. EFF DATE determines the month and year to which the transaction will post. For months or years that are closed, or when future or prior month/year postings are not allowed by the transaction code being used, the system edits against EFF DATE to determine whether or not the transaction can be posted.

◾ FUND – This 4-digit code must exist in the D23 – Fund Profile. The Fund is the lowest level of the Fund Structure and is assigned by agencies to meet their internal accounting needs. FUND may be inferred by either Index or PCA or manually keyed.

◾ FUND OVERRIDE (FUND OVRD or FO – SFMS Operations Use Only) – Enter the one-character field as follows:

The FUND OVRD indicator allows the system to override fund control edits in order to post an accounting transaction. Only authorized personnel may enter this element. If A or W is entered in this field, it will edit against the Security Fund Override Indicator on the user's 96A profile record.

◾ GASB 38 NUMBER (G38#)  – An 8-digit code identifying interagency and interfund transfers which require reporting under GASB Statement 38 Para.14. The G38 transfer number uses the format AAAFFFF0, where AAA is the agency on the other end of the transfer, FFFF is the appropriate D23 fund in which the other agency will record the transfer, followed by a zero and a blank space or fillers.

◾ COMPTROLLER/AGENCY GENERAL LEDGER ACCOUNT (GL ACCT/AGY)  – Enter a four-digit Comptroller General Ledger Account and/or an eight-digit Agency General Ledger Account. If Comptroller General Ledger Account (COMP GL) is entered, it must exist in the D31 Profile. If Agency General Ledger Account (AGY GL) is entered, and the D31 profile G/L EDIT TYPE is D (for a DUE TO/DUE FROM account), the AGY GL is edited as follows:  the first three digits represent the Financial Agency number and must exist in the D02 profile, the next four digits represent the Fund and must exist in the D23 profile, and the last digit must be zero.

If the D31 profile G/L EDIT TYPE is A (for agency) or S (for system wide), the AGY GL must exist in the D32 – Agency General Ledger Account Profile. If both the COMP GL and the AGY GL are entered, use the COMP GL looked up by the AGY GL. If the Agency has established AGY GL Accounts in the D32 profile before a particular COMP GL, the user will be required to enter an AGY GL on the transaction to affect amounts in the COMP GL. This ensures consistent use of AGY GL.

Note that the COMP GL is normally looked up by the T-Code and is not usually entered on the transaction unless the T-Code being used has an open debit or credit. In this case, the COMP GL must be entered on the transaction. The 28B profile record lists specific COMP GLs that are allowed, or not allowed, for use with specific T-Codes. 

◾ GRANT NUMBER/PHASE (GRANT NO/PH) – Enter the six-digit Grant Number and the two-digit Grant Phase. When entered, they must exist in the 29 and D47 profiles. The Grant Number and Grant Phase elements are set up as a means for accumulating grant expenditures, revenues, receipts, budgets and statistical information in R⋆STARS. These elements are established in the 29 profile, which defines how costs are accumulated and billed for each grant. When the Grant Number and Phase are entered or looked up on accounting transactions, the financial or statistical data is recorded in the Grant Financial Table. GRANT NO/PH may be inferred by Index, Project/Phase, Subgrantee or PCA.

◾ INDEX – Enter the five-digit Index Code. When entered, INDEX must exist in the 24 profile. The Index is required to be entered or looked up when the Agency Budget by Organization Indicator is Y (Yes) on the 25 profile and the T-Code being used posts to the Agency Budget (AB) Financial Table. INDEX may look up a PCA. INDEX is used as a coding reduction tool.

◾ INTEREST TERMS (INT TM) – A two-digit field for informational use only and will not affect the amount of the document.

◾ INVOICE NUMBER (INV NO) – Up to 14-character alphanumeric characters. The Invoice Number is generally an optional element which is coded to associate a particular invoice with the transaction. If entered on a payable transaction, it will print on the payment remittance advice of warrants or on the ACH website for direct deposits. The INVC (Invoice Number) transaction edit indicator on the 28A record corresponds to both the Deposit Number on the 504 screen and the Invoice Number on the 505, 506, 508 and 516 payment screens. If the INVC transaction edit indicator on the 28A profile for the T-Code being used is set to I (input), INV NO is required.

◾ MODIFIER (MOD) – A one-character code required on encumbrance transactions referencing pre-encumbrances and expenditure transactions referencing encumbrances. The valid values are:

◾ MULTIPURPOSE CODE (MPCD) – A ten-character code. This is an agency-defined field which can be used for any coding purpose. The MPCD may be inferred from either the INDEX or PCA or may be entered manually. In Oregon, this field is also used by the system to identify the microfiche address for summarized warrant redemption information. Oregon is not using the following automatic generation of allotment transactions function.  The MPCD Code is used for automatic generation of allotment transactions. The values must follow a specific pattern as described below:

◾ NAME – A 50-Character Field. The Vendor Name is looked up by the Vendor Number, if entered.

◾ NOTE – A one-character Electronic Note indicator defaults to N and is changed to Y by the system when a note is added to the document. The electronic note is used to tie miscellaneous text to a document. After a batch header is created and a transaction is saved, the user may link to the 103 Electronic Note Pad screen from entry screens 501, 503, 504 and 505 by typing NOTE in the LINK TO: field and pressing   F9  . When the note is entered and saved, it will be tied to the document. After the document is final approved, the attached note cannot be changed. The notepad can be accessed via the 37 screen.

Currently, 23 and 27 are the only standard User Classes that have the capability to inquire, add, change or delete items on the 103 screen. All others may inquire only. A special request is needed from the Agency Security Officer for changes to a user’s security profile to allow add, change or delete privileges. The notepad indicators are defined as follows:

◾ PROGRAM COST ACCOUNT (PCA) – Enter the five-digit PCA code. When entered, PCA must exist in the 26 profile. The PCA is required to be entered or looked up if the AGY BUD BY PGM IND: is Y (Yes) on the 25 profile and the T-Code being used posts to the Agency Budget (AB) Financial Table. The PCA may look up an INDEX.  If the PCA looks up a Fund, then that Fund is the only Fund that can be posted for a transaction that uses that PCA.

◾ PAYMENT DISTRIBUTION TYPE (PDT) – Typically, the PDT will be left blank and will default from the 51 profile if the first digit of the Vendor Number is less than 9. If entered, the PDT must exist in the D50 profile. The PDT identifies how transactions are combined for warrants and direct deposits, how warrants are routed, and whether payment will be issued in the form of a warrant, direct deposit, or wire transfer.

◾ PENALTY AMOUNT/DATE (PEN AMT/DT) – The Penalty Amount (PEN AMT) is a 13-digit amount field. The last two digits are decimal places. The Penalty Date (PEN DT) is a six-digit date field in MMDDYY format. These fields are for informational purpose only, and do not affect the document amount.

◾ PAYMENT NUMBER (PMT #) – Enter the nine-digit PMT #, or leave blank. This field is controlled by the WARR indicator on the 28A profile of the transaction code being used.

◾ PAYMENT (PMT) TYPE – Enter the one-digit Cash Receipt PMT TYPE as follows or leave blank:

◾ PROJECT NUMBER/PHASE (PROJ NO/PH) – Enter the six-digit alphanumeric Project Number and the two-digit PROJECT PHASE. When entered, they must exist in the 27 profile. The Project Number and Phase elements are established to accumulate project expenditures, revenues, budgets and statistical information. This profile defines how costs are accumulated and how reimbursable projects are billed. Project-related information is recorded in the Project Financial Table and can be viewed on the 80 – Project Financial Inquiry screen. PROJ NO/PH may be inferred by the INDEX or PCA.

◾ PROPERTY NUMBER (PROP #) (Not used in Oregon) – A ten-digit Number. This field is required if the C/I Indicator is entered unless the transaction is from ADPICS. It must be left blank if the C/I indicator is blank. It identifies each asset recorded in the Fixed Asset Subsystem as a unique item.

◾ REFERENCE DOCUMENT/SUFFIX (REF DOC/SFX) – A two part field. The Reference Document is up to eight characters – the Suffix is three. The Reference Document is automatically left justified. The Suffix is always required when the Reference Document is entered. If the Reference Document Indicator (RDOC) on the 28A profile is blank, REFDOC/SFX is optional and often used for tracking purposes. If the RDOC is I or R, REFDOC/SFX identifies a document previously entered in R⋆STARS.

For example, an encumbrance is established to reserve spending authority. When the goods or services are paid for, the original encumbrance is referenced to reduce the reserve of spending authority. The original encumbrance is identified by entering it in the Reference Document and Suffix fields.

A receivable reference document number is selected for a particular vendor when the vendor number is entered on the transaction entry screen and the user interrupts to the 59 – Vendor Document Inquiry screen. All documents with a non-zero balance associated with a specific vendor are displayed on the 59 screen. The user may select a document and end the interrupt. The document number is carried to the Reference Document and Suffix field on the transaction entry screen. The document amount will also be carried over if the document amount on the transaction entry screen is blank or greater than the Reference Document Amount.

◾ RECURRING TRANSACTION INDEX (RT) AMOUNT – (Fast-Entry Screens Only) A 13-digit amount field where the last two digits are decimal places. This amount will be distributed to the transactions retrieved by the RTI based on the percentage allocation defined in the 550 profile.

◾ RECURRING TRANSACTON INDEX (RTI) – A six-character field. When entered, the RTI must exist in the 550 profile. The RTI is an element used as a coding reduction tool for transactions which are recurrent in nature, such as lease payments or telephone expense. The coding block elements for the recurring transaction are pre-defined in the 550 profile. The RTI may be directly input on any of the 500 series screens. A PCA or Grant may also look up an RTI.

The RTI type indicator on the 550 profile defaults to R, which indicates that the record will be used for traditional recurring transaction entry. If the RTI type is set to s, it is used to perform transaction split. See Section 3.4 for more information on Transaction Split Data Entry.

◾ REVERSE (RVS or R) – Entering an R in this field reverses the impact of the transaction. The 28A Profile identifies whether this element is required, must be input, is optional, or not allowed.

◾ SERVICE (SERV) DATE – (Optional - for Agency Informational Use Only) Enter the six-digit Service Date in MMDDYY format. This field identifies the date on which goods or services are received or rendered. For example, the service date for purchased items would be the day the merchandise was received; the service date for recurring expenses, such as rent, would be the first day of the month; and the service date for payroll would be the last day of the pay period. Additionally, SERV DATE is used to edit against the Final Post Date on the 27 profile and the 29 profile if the Service Date Control Indicator (SERV DATE CTL IND) in the related profile is Y.

◾ STATE – This 2-character field is part of the Vendor Address, and is tied to and looked up by the Vendor Number. For foreign (non-USA) vendors, XX is entered in this field.

◾ SUBGRANTEE – A 14-digit code. It must exist in the 31 Profile. Subgrantees are other agencies, localities, etc., who receive portions of pass-through grants. The Grant must account for advances and expenditures made to the subgrantees. If the Subgrantee entered on the transaction looks up a Grant Number and Phase, they must exist in the 29 profile.

◾ DISCOUNT DATE INTEREST TERMS (TM (DISCOUNT)) – A two-digit field. This field is for informational use only, and does not affect the document amount.

◾ PENALTY DATE INTEREST TERMS (TM (PENALTY)) – A two-digit field. This field is for informational use only, and does not affect the document amount.

◾ TRANSACATION AMOUNT (TRANS AMT) – A 13 digit field found only on the 509 screen. The last two digits are decimal places. The single amount is used for both transactions

◾ TRANSACTION (TRANS) CODE (or T-CODE) – A three-digit code. This element is required for all transactions and must exist in the 28A and the 28B Profiles. It identifies the accounting impact (debits and credits) to be recorded in R⋆STARS. The T-CODE dictates how the rest of the transaction will be entered by determining which elements are required, optional or not allowed. It also determines the valid Document Types, Batch Types, General Ledger Accounts and Comptroller Objects for the transaction. T-CODE elements were described earlier in the chapter.

◾ VENDOR NUMBER/MAIL CODE (VEND/MC) – The ten-digit Vendor Number and the 3-digit Vendor Mail Code must exist in the 34 profile if the first digit equals 0 (zero). If the first digit is greater than 0 and less than 9, the Mail Code must exist in the 51 profile.

The Vendor Number identifies the vendor being paid for purchased materials or services. Expenditure and encumbrance transactions require a Vendor Number. One-time vendor numbers can be created a beginning with a 9, if the payment is not 1099 reportable and it is truly a one-time situation. Since the one-time Vendor Number is not entered on the 52 profile, these fields must be entered on the transaction screen:

In some agencies, a one-time Vendor Number is actually entered on the 52 profile. This number is then used to make multiple one-time payments in situations such as jury duty. When entering Revenue or Expenditure transactions the Vendor Number (if known) can be looked up using the 3N – Vendor Number Inquiry screen to choose the correct Mail Code.

◾ VENDOR NAME – This 50-character field is directly assigned to a specific Vendor Number found on the 34 or 51 profiles. When entering transactions, VENDOR NAME can be looked up using the 3A – Vendor Alpha Inquiry screen.

◾ WARRANT NUMBER (WARR NO) – A nine-digit number. The first two digits denote the Bank Type. If the DISBURSEMENT METHOD INDICATOR (DISB METH IND) for the batch is M (Manual Warrant), WARR NO is required; otherwise it is generated by the system.

◾ ZIP – The first five digits of this numeric field are required on certain transactions, the last four digits are optional. It is tied to and looked up by the Vendor Number.

Batch Balancing

When the last transaction in the batch has been entered and the last transaction has been saved with  F10  or  F11 , press   F6   to bring up the 502 screen. This screen can also be accessed from the 510 – Recall A Batch for Correction, 520 or 530 screens using   F6  .

R⋆STARS computes the number of transactions and the total amount entered for the batch. R⋆STARS then compares the computed count and amount to both the count and amount entered on the 500 screen or to the document count on the transaction entry screen and the total of all transaction amounts. In either case, the 502 screen displays the entered and computed counts and amounts.

◾ Balanced Batch. If the batch is in balance (i.e., the entered count and amount equal the computed count and amount), the user may release the batch for overnight or immediate processing. The message

THIS BATCH IS BALANCED

will be displayed at the bottom of the 502 screen. A 502 screen showing a balanced batch is displayed below.

Example:

◾ Batch/Document Not in Balance.  If the batch is out of balance, the user should attempt to correct the balancing error. Three types of balancing edits are performed when a user attempts to release a batch:

◽ Batch Balancing – The entered batch count and amount are compared to the computed count and amount for all transactions in the batch. The batch total is the total of the absolute value of all transactions.

◽ Document Balancing – The entered document amount is compared to the computed document amount for all transactions in each document. This is a “net” amount which considers the +/- Indicator on the 28A profile and the REVERSE Code (RVS) entered on the transaction. In addition, this process checks for balancing T-Codes (identified by an entry in the BAL TC field on the 28A profile record) to ensure that the right combination of T-Codes is used and that the totals for each T-Code are equal within a document.

In addition, if the document BALANCING INDICATOR on the 33 profile is Y (Yes) for any document type used in the batch, the computed DOC AMT must equal the entered DOC AMT for each tracked document in the batch before the batch is balanced. Most documents are tracked.

◽ Invoice Balancing – The total of all transactions (net) within each Accounts Receivable document is compared to the total of all line items on the corresponding invoice.

Certain Accounts Receivable (AR) T-Codes require invoice balancing  – example: 103 - Establish an Accounts Receivable – Billed. The invoice balancing requirement is set by including a specific T-Code number on the D53 – Titles Profile under Table ID ARIV. Before a batch containing this type of T-Code can be released, the system will require that each invoice be balanced against its corresponding transaction.

If one or more AR transaction and invoice pairs are not in balance, one of two error messages will occur. If there is no matching Invoice for an AR Document, the message

NO MATCHING INVOICE FOUND FOR AR TRANSACTION WITH CURRENT DOCUMENT # . . .

will appear. If the amount on an Invoice does not match the amount on the AR Document, the message will read

INVOICE AMT DOES NOT MATCH AR TRANSACTION AMT FOR CURRENT DOC # . . .

The user can either interrupt to the 515 – Invoice Entry screen to add an invoice or correct an invoice amount, or follow the batch and document correction process described below to correct a transaction error. See Chapter 10 for further discussion on the 515 and 504 screens.

◾ Correcting a Batch Balancing Problem.  After the last transaction in a batch has been saved ( F10  or  F11 ) and an attempt has been made to balance the batch (  F6  ), the 502 screen will appear and indicate whether the batch is balanced. If the batch is not balanced, an error message

WARNING...BATCH OR DOCUMENTS NOT IN BALANCE

will appear. The system will not indicate whether the problem is a batch, document or invoice out of balance (an exception to this is the AR balancing previously discussed). One method of correcting batch and document balancing problems is described below:

1. From the 502 screen, press   F7   and the 520 screen will appear. This screen is a view screen only; the transactions cannot be accessed for correction purposes using this screen. The 520 screen can be reviewed for the accuracy of the transactions in a batch and a document. If a transaction amount is found to have been incorrectly entered, the Batch ID information and the sequence number of the erroneous transactions should be noted.

2. From the 520 screen, press  F11  –CORRECT BATCH. The 510 screen will be retrieved. From this screen the batch header can be changed (press   F2   – CHGE HDR) or individual transactions can be DELETED (press   F3   – DEL TRANS), CHANGED (press   F4   – CHGE), or ADDED (press  F10  – ADD). To delete or change a specific transaction, the SEQUENCE NUMBER must be entered. Entering the sequence number of a transaction to be changed will cause the input screen with that transaction to appear. If the sequence number field is left blank, the first transaction in the batch will be retrieved.

3. Once the transaction entry screen for the sequence number is displayed, correct any erroneous entries by entering accurate information in the field. AFTER CHANGES HAVE BEEN MADE, THE CORRECTED TRANSACTION MUST BE SAVED WITH  F10 . To correct multiple entries in the batch use   F5   – NEXT to progress to the next transaction.

4. If the error is in the batch header, press   F2   on the 510 screen to go to the 511 – Change a Batch Header screen. Correct the ENTERED COUNT, ENTERED AMOUNT or the EFFECTIVE DATE fields as required.

5. After the necessary corrections have been made and saved, press   F6   to balance the batch. The 502 screen will appear and identify that the batch is in balance. Proceed as described in the Balanced Batch section earlier in this chapter.

Example:

Example:

After all batches are complete and balanced, the user can view all the batch headers by entering the 530 screen from the Financial Data Entry Menu, or by pressing  F12  from one of the other Batch Processing screens.

This screen will list all the Batch Headers for a particular agency. It also displays the current status of each batch and the entered and computed counts and amounts. The BAL indicator shows if the batch is in balance with either a Y for yes or N for no.

Example:

◾ Batch Status. The Batch Status is used by IEU (Input, Edit and Update) to determine if and how batches are processed. The valid values are:

◽ R (Release) – Transactions within the batch are released. The user is finished entering transactions.

◽ H (Hold) – Transactions within the batch are held. The user is not finished entering or correcting transactions. If the Edit Mode is 0 or 1, the batch is not processed by IEU. If the Edit Mode is 2, transactions have posted but will not be processed while the batch is on hold.

◽ D (Delete) – In Edit Mode 2, transactions within the batch and the batch itself are immediately deleted from the system. In Edit Modes 0 and 1, the transaction and the batch are flagged for deletion. The deleted transactions do not show on  the 520 screen, but they still exist in the transaction history. The actual deletion of the transactions and batch occur in the batch cycle.

◽ A (Approval Required) – Transactions within the batch are released and require approval (not used in Oregon).

◽ P (Posted) – Transactions within the batch are released and approved.

If a transaction is added/deleted/changed in the batch, the Recompute function will recompute the 'Entered' batch count and amount only if these amounts were not previously entered by the operator. This capability is available if a user exits a batch abnormally and the system does not automatically recompute the count and amount. The recompute function is available on the 510 screen.

3-3      Accounting Transaction Data Entry Examples

Three examples of accounting transaction data entry are presented below. The first example presents a correct and balanced batch. The others contain batch balancing errors. The second example contains an incorrect transaction amount. The third shows an incorrect transaction count. Posting procedures and steps required to correct the second and third batches are described in detail. Each example contains an overview description of the entries, followed by sample data entry screens illustrating each step.

Example 1

Two encumbrance transactions were entered for AGENCY 101. Each transaction has an amount of $100.00.

The first step is to bring up the 500 screen. This entry screen uniquely identifies the batch by agency, date, the type of transactions and the batch number. The number of transactions and the total amount of the batch may also be entered for auditing purposes. Press  F10  or  F11  when header entry is complete.

Example:

Entering Batch Type 3 on the Batch Header retrieves the 505 screen (encumbrances). These two transactions are entered either as two separate documents, or one document with two suffixes (transactions). Note that the Batch ID (Batch Agency, Date Type, and No.) is brought forward from the 500 screen. Also, the first transaction sequence number defaults. These fields are protected and cannot be changed on the transaction entry screen.

After the data elements are entered,  F10  or  F11  is pressed to submit the transaction. The sequence number will automatically advance to the next number after the first transaction is successfully posted. If the D59 profile is set up for auto-incrementing, only the two-character Document Type (EE) is entered in the CUR-DOC/SFX field; the remaining spaces are left blank.

Example:

After the second transaction is entered and successfully posted, press   F6   to go to the 502 screen.

Example:

This screen identifies that the batch is in balance. Press   F6   to release the batch.

Example:

Then press  F11  to bring up a new 500 screen.

Example 2

The same transactions are used in this example, but the user incorrectly enters only $50.00 for the second transaction. After all transactions are entered, the 502 screen identifies that the batch is NOT in balance.

Example:

Press   F7   to view the detail transactions for the batch on the 520 screen.

Example:

Notice that the second transaction (Suffix Number 002) is in error. To correct it, tab the cursor to the Selector (s)  column for the transaction, type s and press  F11 . The system retrieves the 510 screen with the selected transaction’s sequence number in the Sequence Number field.

Example:

Press   F4  . The 505 screen containing the accounting transaction is recalled to the screen.

Example:

Change the amount field to reflect the correct amount of $100.00. Press  F10  or  F11  to save the change.

Example:

Now press   F6  . The system retrieves the 502 screen, which identifies that the batch is now in balance.

Example:

Release the batch by pressing   F6  , then press  F11  to recall a new 500 screen.

Example 3

Once again, the same transactions are used in this example. This time the user incorrectly enters 3 as the number of transactions in the batch.

After all transactions are entered, the 502 screen identifies that the batch is NOT in balance.

Example:

Pressing   F2   retrieves the 510 screen.

Press   F2   again to retrieve the 511 screen, which enables the user to change the number of entered transactions to 2.

Example:

Press  F10  to save the change and return to the 510 screen. Press   F6   to balance the corrected batch. The system retrieves the 502 screen, which identifies that the batch is now in balance. Press   F6   again to release the batch.

Press  F11  to recall the 500 screen for additional transaction processing, or press  Pause/Break  (Clear) to exit to the Financial Data Entry Menu.

3-4      Transaction Split Data Entry

Recurring Transaction Subsystem allows fixed transaction schedules and coding blocks to be stored and accessed to automatically generate transactions. Recurring Transaction Indexes (RTIs) are maintained in the 550 profile. This profile is used to record data elements required for establishing traditional and split RTIs.

Traditional, non-split recurring transactions (RTI type R) are used for those payments which recur regularly in the same amount, such as rent payments, or periodic or monthly accruals. Traditional recurring transactions can also be used for coding block retrieval when entering transactions on the transaction entry screens. These transactions are allocated by specified dollar amounts or percents. See Chapter 8 of this guide and Reference Manual, Chapter 7 for discussion of traditional recurring transactions.

Split recurring transactions (RTI type s) allocate a percentage of a specified amount across multiple funds or appropriations. This process provides the capability for splitting any type of transaction, such as revenues, expenditures, pre-encumbrances, and encumbrances. The Transaction Split process is designed to reduce the manual effort necessary for repetitive posting of like transactions.

This chapter discusses the procedures for setting up RTIs for transaction split, followed by examples of transaction data entry and financial table inquiry.

Recurring Transaction Profile

The 550 profile is accessed by selecting the Financial Data Entry (FIN) option from the Main Menu and then selecting option 550 from the submenu or pressing the related function key. The 550 profile is shown below.  You may also type 550 into the LINK TO: field and press Enter.

Example:

The elements on this profile are described below:

◾ Agency – Each agency maintains its own profiles. This field defaults to the user’s security agency.

◾ Transaction Number – A user-defined number that uniquely identifies each recurring transaction defined within an RTI.

◾ Recurring Transaction Index (RTI) – A user-defined coding block which, when entered on a transaction, identifies the elements to be split or looked up by the RTI and the percentage allocation. Between one and ten coding blocks (splits) can be assigned to one unique RTI.

◾ RTI Type – Valid values are:

The indicator defaults to R. The user must change the type to s when establishing split RTIs. All transactions within a given RTI must have the same RTI type.

◾ Coding Block – These classification elements are allowed on a split transaction RTI:

See Section 3-2 for a description of these elements.

◾ % ALLOCATED – Establishes the total percentage allocated to each transaction within a given RTI. If the RTI Type is s, this field must be entered. The figures are entered in decimal format (e.g. 0.35000 = 35%.)  The total percentage allocation must equal 1.00 (100% percent) for all transactions assigned to a RTI.

Once all of the elements have been added, the 550 profile is saved by pressing F10-SAVE. For each profile, the STATUS indicator will be I (inactive) until all the profile entries are made. Once the final profile is entered and saved, pressing F12-RTI COMPLETE will change the status of the entire RTI to STATUS A (active).

Common Uses of Transaction Split

The RTI Split Process is used by agencies in a variety of ways. Some agencies use Grants to lookup RTIs that split across Funds and Appropriation Numbers. In other instances, PCAs will look up RTIs that split Funds, Appropriation Numbers and various other classification structure elements.

Transaction Split by Program and Organization

The RTI Split Process is also used for splitting across multiple Programs and Organizations. An example of splitting across Programs would be payroll transactions where an individual’s salary is split across multiple programs (PCAs).

When a PCA looks up an RTI that splits across PCAs or Indexes, all classification elements (e.g., Fund, Appropriation Number) required on the Transaction Code should be entered on the Transaction Entry screen, looked up by the Index or Grant, entered on the Transaction Entry screen or looked up by the RTI

As a general rule, when the PCA or Index looks up an RTI that splits across Programs or Organizations, classification elements should be blank on the original Index and PCA profiles. This is because the PCAs or Indexes looked up by the RTI will override the original interfaced (or input) PCA or Index. The resulting split transactions will post using only the elements that are looked up by the RTI.

Establishing the 550 profile

The following example illustrates the steps taken by Agency 101 to establish a Transaction Split RTI. This RTI will split across Program Cost Accounts allocated as follows: 20% to PCA 11100, 45% to PCA 21110, and 35% to PCA 41200. The profile records are established using RTI CPY-01 and Transaction Numbers 060001, 060002 and 060003 respectively.

Example:

The first profile entry for RTI CPY-01 posted successfully; however, the record’s status code is set to I (inactive). A new 550 profile record must be established for each of the other two RTI components. Each component is made unique by manually incrementing the Transaction Number.

The second transaction for RTI CPY-01 is shown below:

Example:

The third transaction is shown below:

Example:

Once all of these components have been entered and saved, the user must press  F12  – RTI COMPLETE to activate all the transaction profiles for this RTI. R⋆STARS will change the status code to A if the total RTI Percentage Allocated equals 1.00 (100 percent). The activation of RTI CPY-01 is illustrated below:

Example:

If a user attempts to post a transaction that includes an inactive RTI while processing transactions in edit mode 2,  the transaction will not post and an error message will be displayed indicating that the RTI must exist in the 550 profile. Also, if an RTI has been activated and one of the records on the 550 profile is subsequently changed or deleted in such a way that the percent allocated no longer equals 1.00, R⋆STARS will automatically inactivate all records assigned to that RTI.

Transaction Split Processing

The Transaction Split process was designed to support up to 3 levels of lookups. For example, if a PCA is entered on the Transaction Entry screen, the PCA can look up an RTI that splits across multiple Programs (PCAs). Each of these PCAs can look up various Funds, Appropriation Numbers, Grants, Projects, etc.

The split RTI must either be entered on the transaction or looked up by any of the following elements:

◾ PCA

◾ Grant/Phase

◾ Project/Phase

If more than one of the above elements is entered on the transaction, each element looks up a different RTI.

An example of PCA 41201 created to look up RTI CPY-01 is shown below.

Example:

Since the elements in the split entry RTI are from different funds and appropriations, these elements must be left out of the PCA. The RTI Coding Block elements cannot be overridden. If any elements of the RTI conflict with elements from the PCA, the transactions will not process. For example, an Appropriation is entered on the Transaction Entry screen along with a PCA that calls up an RTI that splits across different Appropriation Numbers  If the Appropriation is not included in the RTI, the 518 – Split transaction Inquiry screen will appear showing ERROR CODE: EAL – CAN'T OVERRD APPR NO for that transaction.

Entering Split Transactions

Split transactions can be entered on any of the financial transaction entry screens following the same procedures as non-split transactions. These screens, as well as the coding instructions for completing a batch header and entering on-line and batch transactions, are discussed in Section   3-2.

To enter a split transaction:

1. Select the appropriate Batch Type based on the type of transaction to be entered and complete the Batch Header.

2. Once the Transaction Entry screen is displayed, enter the T-Code and any other elements required by the T-Code (e.g., Index, Comptroller Object, and Transaction Amount).

3. If one of the data elements (such as the PCA or Project/Phase) is capable of looking up the RTI, enter that element.

- OR -

If you know which RTI is needed, enter it in the RTI: field.

When all data has been entered, press   F4   to edit the data or, alternatively, press  F10  to save the data. Note: Although the   F3   RTI key is visible on any of the transaction entry screens, this function key is only valid when using an R Type RTI to retrieve a coding block defined in the 550 profile. It cannot be used with split RTIs.

Example – Entering Split Transactions – Edit Mode 2

The following example illustrates the steps taken by Agency 101 to post encumbrance transactions that will be split across three different funds and appropriations according to the percentages allocated in RTI CPY-01.

The Batch Header is entered using Batch Type 3 and Edit Mode 2.

Example:

Note:  If the user chooses to enter a batch count and batch amount, the count and amount must reflect the total of the split transactions ONLY. In the example, the split transaction is entered for $2,000 that will split into 3 transactions. Therefore, the batch count and batch amount will be 3 and $2,000, respectively. If the batch count and amount are left blank, the system will automatically calculate the values.

In the following example, Batch type 3 invokes the 505 screen. All elements required by the T-Code are entered. The previously established PCA 41201 will look up RTI CPY-01.

Example:

Once all data has been entered,   F4   is pressed to edit the transaction (optional) then  F10  to edit, save and post the transaction. The transaction is posted to the Internal Transaction File, Accounting Event Table and all applicable financial tables. The input transaction must be error free before further processing and splitting occurs. If either   F4   or  F10  is pressed and the parent transaction contains data edit errors (e.g., Invalid Index, Document Number Required), some of the looked-up fields will be displayed as well as the related error codes and messages. Press  F10  after all data edit errors have been corrected.

If there are errors associated with the RTI (e.g., RTI looks up an invalid fund or appropriation), R⋆STARS automatically interrupts to the 518 screen to view the resulting errors. This screen displays two lines of data elements and corresponding error codes for each generated transaction. The details of each split transaction and their associated error codes and messages can be selected from this screen by placing an S in the select field of the transaction to be viewed and pressing   F2  .

An example of the 518 screen is shown below. Assume RTI CPY-01 contains two splits with no PCA and an invalid fund (1500) and appropriation (31556). R⋆STARS will successfully split the second transaction but will fail on the first and third transaction when it tries to post. None of the transactions are posted due to the errors. Even correctly entered transactions in the split are reversed.

Example:

The user can select the transaction in error and press   F2   to view the detail of the transaction and the error messages:

Example:

   F6   is pressed to return to the 518 screen, then   F9   to interrupt to the original Transaction Entry screen to correct the errors. A message is displayed indicating

TRANSACTION HAS ERRORS – PLEASE CORRECT.

Example:

The correction is made from the Transaction Entry screen by linking to the 550 profile and removing the incorrect coding from the transaction. Once the error has been corrected,   F9   is pressed to interrupt back to the Transaction Entry screen. Then  F10  is pressed to save the transaction.

Example:

If no additional errors occur, the transaction will successfully post and split. The batch sequence number will increment and the screen is ready for another transaction.

Pressing   F7   invokes the 520 screen to view the details of the batch:

Example:

R⋆STARS assigns a Y in the parent (P) field to indicate the entered transaction. The remaining transactions are split transactions. Although the Parent transaction is displayed here, the transaction as it was entered no longer exists after the transaction is successfully split. No Accounting Event record is created for the parent transaction and it has no impact on the financial tables. Only the split transactions, known as the children, are reflected in the Accounting Event and impact all applicable financial tables.

Split Transaction Inquiry

Split transactions can be viewed and inquired upon in the same manner as non-split transactions. The following screens illustrate the records posted for the split transactions demonstrated above, using the 64 – Document Record Inquiry, 86 – Document Transaction Inquiry and 84 – Accounting Event Inquiry screens.

Example – Document Record Inquiry

A detail record is created for each split transaction ($4,800/$1,600/$700). Each split transaction posts to the same Document No/Suffix, and is incremented by the class sequence number as depicted below in this example of the 64 screen:

Example:

Pressing   F5   scrolls through the remaining records for this document. The CLASS number will increment by one for each split transaction posted to the DOC NO/SFX as shown on the following two screens:

Example:

Example:

Example – Document/Accounting Event Record Inquiry

The 86 screen is used to inquire on the Document Number for the Split Transaction. Using the example transaction for RTI CPY-01, a record is generated for each sequence number in the Batch.

Example:

Note that there is no record found for the parent transaction (#00001) since no accounting records are effected. Tab to the s column entry field for transaction #00002, type s and  ↵ Enter . This invokes the 84 screen and displays the transaction detail.

Example:

The original (parent) Sequence Number is referenced on all split transactions in the ORIG SEQ NO: field. Pressing   F5   advances to the remaining records for this batch. The last Sequence Number is 00004.

Example:

Example:

Example – Entering Split Transactions - Edit Mode 0 or 1

Split transactions can be entered in Edit Mode 0 (no on-line editing or posting) or 1 (on-line data editing only, with fund control editing and posting performed in batch).

The following examples illustrate the entry of a receivable transaction using Batch Type 2 and Edit Mode 0. In the example, PCA 81121 looks up RTI GAS-07 (which splits 25% to each of PCAs 81120, 81130, 82120 and 82130). PCA 82130 has been inactivated for purposes of this demonstration.

Example – A Split Transaction for $3000 in Edit Mode 0