Transaction Code Decision Table​ Overview

The Transaction Code Decision Table helps you to identify the impact to general ledger, the financial files posted to, the specific areas in the financial files posted to, and the data entry fields that are required, optional, or not allowed.

A PDF copy is available to view or download (the DAFR8640) in the Related Links menu.

How to View the Transaction Code Decision Table on STARS

If you have security access, you can view the table:

From the STARS Main Menu, type S in the FUNCTION field and press ENTER.

Type 28 in the FUNCTION field and press ENTER

Transaction Code Decision Table (S028) Example

Transaction Code Decision Table Example  

Sections of the Transaction Code Decision Table

TRAN-CODE

In the TC Decision table, the three-character TRAN-CODE field is the control key.  The following is an example of the control key for the TC Decision table.

Example of the Control Key Segments

Example of the Control Key Segments

VERSION 3.1  STARS--TRANSACTION CODE DECISION TABLE MAINTENANCE/INQUIRY   S028

 FUNCTION: R  (A=ADD, C=CHANGE, D=DELETE, N=NEXT, R=RECALL)                   

 TRAN-CODE: 230   TITLE: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX  

 

GENERAL LEDGER POSTING

STARS uses the general ledger (GL) posting to identify the GL account impact of the transaction. Each transaction code can have up to four pairs of debit/credit postings.  In order to post to the GL, the accounts must exist in the General Ledger descriptor table 31.  Each debit/credit pair is described below.

Illustration of Transaction Code 230 and GL Pairs

VERSION 3.1  STARS--TRANSACTION CODE DECISION TABLE MAINTENANCE/INQUIRY   S028

  FUNCTION: R (A=ADD, C=CHANGE, D=DELETE, N=NEXT, R=RECALL)                   

  TRAN-CODE: 230 TITLE: RECORD A EXPENDITURE VOUCHER NOT PREVIOUSLY ENCUMBERED

GENERAL-LEDGER-  DR-1: 4200 CR-1: 1003 DR-2:      CR-2:                    

       POSTING            DR-3: 1003 CR-3: 2101 DR-4:      CR-4:                   

 

  • DR-1/CR-1 - First GL pair
    The first GL debit/credit pair posts to the four-digit accounts represented.  STARS uses these GL accounts to post to the subsidiary files, if needed.  The GL postings may update the document file, general ledger file, operating file, and subsidiary file.
  • DR-2/CR-2 - Second GL pair
    The second GL debit/credit pair posts the same as the first GL debit/credit pair with postings to additional general ledger accounts when necessary.
  • DR-3/CR-3 - Third GL pair
    The third debit/credit pair identifies outstanding warrants payable and cash moving to the warrant-clearing fund 0649.  If the clearing fund indicator is "Y", then the third pair of general ledger accounts must have a posting to cash general ledger 1003 and to outstanding warrants payable general ledger 2101.
  • DR-4/CR-4 - Fourth GL pair
    The fourth debit/credit pair tells STARS to use the document file liquidation logic.  This enables the user to code a modifier of "P" (Partial) or "F" (Final) and STARS will compute the appropriate liquidation balance.  If accounts are coded in this pair, STARS will use the information stored in the document file record when building the liquidation portion of the accounting transaction.  There are edits in the system to verify that only accounts '5100' (Pre-encumbrances), '4300' (Encumbrances) and their appropriate offsets are coded in this pair.


When one side of the debit/credit pair is blank
SCO uses some transactions that leave one side of a debit/credit pair blank.  These transactions are used when the general ledger account is to be coded when entering the accounting transaction.  Transactions that have one part of a pair blank will have the general ledger account (GLA) edit indicator set to "I".

Example of One Side of the Debit/Credit Pair is Blank

VERSION 3.1  STARS--TRANSACTION CODE DECISION TABLE MAINTENANCE/INQUIRY  S028

  FUNCTION: R (A=ADD, C=CHANGE, D=DELETE, N=NEXT, R=RECALL)                   

  TRAN-CODE: AA1 TITLE: RECLASSIFY GENERAL LEDGER ACCOUNT - DEBIT              

GENERAL-LEDGER-  DR-1:      CR-1: 4980 DR-2:      CR-2:                       

       POSTING            DR-3:      CR-3:      DR-4:      CR-4:                       

 

TRANSACTION    CI   N MODI N RVRS N INDX N PCA  N BUDU N FUND I FDTL   ESUB N 

EDIT-INDS      EDTL N RSUB N RDTL N SUBS N MULT   GLA I VNUM N VNAM N VADD N 

PCN            PROJ N GRNT N CDOC I RDOC   INVC   DOCD   DUDT N WARR N SECA N 


 TRANSACTION EDIT INS

Examples of Edit Indicators Segment for TC 230

TRANSACTION    CI     MODI N RVRS   INDX R PCA  R BUDU R FUND R FDTL   ESUB I 

EDIT-INDS      EDTL   RSUB N RDTL N SUBS N MULT   GLA  N VNUM I VNAM   VADD   

PCN N          PROJ   GRNT   CDOC I RDOC   INVC   DOCD   DUDT N WARR N SECA N


 The transaction edit indicators segment of the table controls the data entry coding requirements of the individual transaction.  The values of the indicators are:

  • Blank – The data element is optional. You may enter the code or have it looked up by another table or you may leave it blank.
  • I – You must manually enter the data element.
  • R – This data element is required, but you may enter it manually or have it looked-up by another table based on one of the other data elements.

  • N – This data element is not allowed on the accounting transaction regardless of whether you code the data element during data entry or have it looked-up.

   DESCRIPTION OF THE DATA ELEMENTS

Data Element Description
CI

Capitalization Indicator.

This data element supports the Fixed Asset System (FAS) and capital outlay expenditures.  The CI tells STARS to require a property and component number on the transaction code. You could use this field if you had an operating expenditure that you want to post to the Fixed Asset System or an adjustment that you want to post FAS.

MODI

Modifier.

This data element tells STARS to require a modifier to close, cancel, or re-open an encumbrance.

RVRS

Reverse Indicator.

This data element tells STARS to reverse the normal general ledger and file postings of the transaction code.

INDX

Index Code.

This data element tells STARS that a four-digit Index code must be entered or looked up to provide the means for recording accounting data at various levels of organizational structure.  STARS verifies the index is valid by checking the Index table – 24.

PCA

Program Cost Account.

This data element tells STARS that a five-digit PCA code must be entered or looked up to provide the means for recording accounting data at various levels of program structure.  STARS verifies the PCA is valid by checking the PCA table – 26.

BUDU

Budget Unit.

This data element tells STARS that a four-character Budget Unit code must be entered or looked up to control the level of fund, organization, program, and object classification of each appropriation.  STARS verifies the Budget Unit is valid by checking the Budget Unit table – 20.

FUND

Fund.

This data element tells STARS that a four-digit Fund code must be entered or looked up in order to post the transaction to a certain Fund.  These funds control the amount as well as the level of postings to the financial files.  STARS verifies the fund is valid by checking the Fund descriptor table – D22.

FDTL

Fund detail.

This data element tells STARS a two-digit Fund Detail code must be entered or looked up in order to post the transaction to a certain Fund Detail.  These Fund Details may control the amount, as well as, the level of postings to the financial files.  STARS verifies the Fund Detail is valid by checking the Fund Detail descriptor table - D23.

ESUB

Expenditure subobject.

This data element tells STARS to require a four-digit Expenditure code to identify the type of goods and services and to post to the files for reporting and budgetary controls.  Several subobjects trigger additional internal processes.  STARS verifies the expenditure code is valid  by checking the Expenditure Subobject descriptor table D10.

EDTL

Expenditure subobject detail.

This data element tells STARS to require a two-digit Expenditure Subobject Detail to breakdown the Expenditure Subobject code in more agency-specific detail.  STARS verifies the expenditure subobject detail code is valid by checking the Expenditure Subobject Detail descriptor table - D11.

RSUB

Revenue subobject.

This data element tells STARS to require a four-digit Revenue code that identifies the source or type of revenue received or accrued by the user and posts to the files for reporting and cash controls.  STARS verifies the Revenue code is valid by checking the Revenue Subobject descriptor table – D34.

RDTL

Revenue subobject detail.

This data element tells STARS to require a two-digit Revenue Subobject detail to breakdown the Revenue Subobject code in more agency-specific detail.  STARS verifies the revenue subobject detail code is valid by checking the Revenue Subobject Detail descriptor table – D35.

SUBS

Subsidiary.

This data element tells STARS to require a six-digit subsidiary code to breakdown the general ledger account into subsidiaries, if the transaction posts to the Subsidiary File.  STARS verifies the subsidiary code is valid by checking the Subsidiary descriptor table – D32.

MULT

Multipurpose Code.

This data element tells STARS to require a ten-character MPC (Multipurpose Code).  This field enables the State Division of Purchasing to retrieve information about your agency's purchasing contracts, or purchase orders through STARS.

GLA

General Ledger Account.

This data element tells STARS to require a four-digit General Ledger account code.  This will only be on a transaction code that is missing one of the general ledger accounts.  STARS verifies the general ledger account is valid by checking the General Ledger descriptor table - D31.

VNM

Vendor number.

This data element tells STARS to require a nine-character Vendor Number and a two-character Suffix code that looks up the name and address in order to send the payment to the correct vendor and location.  A transaction code can be set up with the vendor number as an optional field and the vendor name and address required.  If the vendor number is on the vendor edit table and you enter it on the transaction code, you cannot enter the vendor name and address.  When a vendor number is required, STARS verifies the Vendor Number/Suffix is valid by checking the Vendor Edit table – 21.

VNAM

Vendor name.

This data element tells STARS to require manual entry of the Vendor Name.  The Vendor Name is normally looked up on the Vendor Edit Table –21.  However, if the transaction code does not allow the vendor number, you must manually enter the forty-digit Vendor Name.

VADD

Vendor address.

This data element tells STARS to require manual entry of the Vendor Address.  The Vendor Address is normally looked up on the Vendor Edit table – 21.  However, if the transaction code does not allow the vendor number, you must manually enter this forty-digit address, the fifteen-digit city, the two-digit state, the five-digit zip code, and an optional four-digit zip plus.

PCN

Position Control Number.

This data element tells STARS to require a four-digit Position Control Number assigned by Division of Financial Management for use in processing payroll transactions.

PROJ

Project Number.

This data element tells STARS to require an eight-character Project Number that provides a method for tracking several types of projects including capital, externally reimbursed, non-reimbursable, or internally reimbursed.  STARS verifies the Project Number is valid by checking the Project table – 27.

GRNT

Grant.

This data element tells STARS to require a six-character Grant and a two-digit Phase that STARS can look up using your Index or PCA information.  You can also enter it directly or override the looked up Grant and Phase.  Agencies use the Grant/Phase to keep track of certain types of revenues and or expenditures and are not exclusively for Federal Grants.  STARS verifies the Grant Number and Phase is valid by checking the Grant table – 29.

CDOC

Current Document Number.

This data element tells STARS to require an eight-character Current Document and a two-digit Suffix number.  STARS uses this number to track an accounting transaction through the system.  It is required on all transaction codes.  STARS uses this number on the Document File when the transaction code posts to the document file.

RDOC

Reference Document.

This data element tells STARS to require a ten-character Reference Document number that looks up a document you previously posted to the Document File, mostly encumbrances and receivables.

INVC

Invoice Number.

This data element tells STARS to require a fourteen-character field that will print on the warrant stub as information to the vendor that you are paying.  You also use the Invoice Number for Interagency Billings (where one agency bills another).  The Invoice Number provides STARS with the information to know which document to post the payment to on the Document File.

DOCD

Document Date.

This data element tells STARS to require a six-digit Document Date used to identify the date of a document.  STARS uses the document date to age the accounts receivable for documents on the Document File.  Not all transactions require a document date.

DUDT

Due Date.

This data element tells STARS to require a six-digit Due Date that controls the date STARS will create a warrant.  Future due date transactions will post to the STARS files, but these also post to the Warrant Writing file and not create a warrant until the due date.

WARR

Warrant Number.

This data element tells STARS to require a nine-digit Warrant Number to identify the outstanding warrant or sight draft to redeem.  SCO enters the warrant number to record a forged warrant that the system redeemed and purged from the Warrant Control File.  When entering manual warrants, the warrant number must be present due to this control.

SECA

Second Agency.

This data element tells STARS to require a three-digit Second Agency Code used to identify the billing or paying agency on an interagency transaction. STARS verifies the second agency number is valid by checking the Agency descriptor table – D02