PROJECT ACCOUNTING - Louisiana ppm/pm-ch16.pdfeach project. Project Accounting provides the capability to reject spending transactions which exceed budgeted project amounts.

PROJECT ACCOUNTING ________________________________________________________________

16 PROJECT ACCOUNTING . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116.1 Project Accounting Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

16.1.1 Project Accounting Policies. . . . . . . . . . . . . . . . . . . . . . . 316.2 Project Accounting Hierarchy/Structure Overview . . . . . . . . . . . 4

16.2.1 Project Coding Data Elements . . . . . . . . . . . . . . . . . . . . 516.3 Project Accounting Controls Overview . . . . . . . . . . . . . . . . . . . . 6

16.3.1 Project Accounting Control Policy . . . . . . . . . . . . . . . . . 716.4 Project Accounting Budgets Overview . . . . . . . . . . . . . . . . . . . . 8

16.4.1 Project Accounting Budgets Policy. . . . . . . . . . . . . . . . . 916.5 Project Accounting Multi-Year/Full Cost Overview . . . . . . . . . . 10

16.5.1 Project Accounting Multi-Year/Full Cost Policies . . . . . . 1016.6 Project Accounting User-Maintained Tables Overview. . . . . . . . . 11

16.6.1 Project Accounting User-Maintained Tables Policies. . . . 1116.6.2 Project Phase Reference (PRPH) Table Overview. . . . . . 12

16.6.2.1 Project Phase Reference (PRPH) TableProcedures. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

16.6.2.2 Agency-Specific Procedures for the ProjectPhase Reference (PRPH) Table. . . . . . . . . . . . . . . . 12

16.6.2.3 Project Phase Reference (PRPH) Table ScreenPrint and Field Descriptions . . . . . . . . . . . . . . . . . . 13

16.6.3 Project Status Reference (PRST) Table Overview. . . . . . 1416.6.3.1 Project Status Reference (PRST) Table

Procedures. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1416.6.3.2 Agency-Specific Procedures for the Project

Status Reference (PRST) Table. . . . . . . . . . . . . . . . 1416.6.3.3 Project Status Reference (PRST) Table Screen

Print and Field Descriptions . . . . . . . . . . . . . . . . . . 1516.6.4 Charge Class Reference (CHRG) Table Overview. . . . . . 16

16.6.4.1 Charge Class Reference (CHRG) TableProcedures. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

16.4.2 Agency-Specific Procedures for the Charge ClassReference (CHRG) Table. . . . . . . . . . . . . . . . . . . . . . . . . 16

16.4.3 Charge Class Reference (CHRG) Table Screen Printand Field Descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

16.6.5 Project by Appropriation (PAPR) Table Overview . . . . . 1816.6.5.1 Project by Appropriation (PAPR) Table

Procedures. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

DIV. OF ADMINISTRATION ANDSTATE TREASURER POLICIES MANUAL - June 1996 16-i


16.6.5.2 Agency-Specific Procedures for the Project byAppropriation (PAPR) Table . . . . . . . . . . . . . . . . . 18

16.6.5.3 Project by Appropriation (PAPR) Table ScreenPrint and Field Descriptions . . . . . . . . . . . . . . . . . . 19

16.6.6 Sub-Project Name (SPNT) Table Overview. . . . . . . . . . . 2016.6.6.1 Sub-Project Name (SPNT) Table Policies. . . . . . 20

16.7 Project Accounting System-Maintained Tables Overview. . . . . . . 2316.7.1 Agency Project (AGPR) Table Overview. . . . . . . . . . . . . 2316.7.2 Agency Project Description (AGP2) Table Overview. . . . 2516.7.3 Project Budget Line (PRBL) Table Overview . . . . . . . . . 2716.7.4 Project Budget Line Inquiry - 2 (PRB2) Table

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3016.7.4.1 Budget Line Inquiry - 2 (PRB2) Table Screen

Print and Field Descriptions . . . . . . . . . . . . . . . . . . 3016.7.5 Project Fiscal Year (PFYT) Table Overview . . . . . . . . . . 34

16.7.5.1 Project Fiscal Year Inquiry (PFYT) TableScreen Print and Field Descriptions . . . . . . . . . . . . 34

16.7.6 Appropriation by Project (APRP) Table Overview . . . . . 3616.7.6.1 Appropriation by Project (APRP) Table Screen

Print and Field Descriptions . . . . . . . . . . . . . . . . . . 3716.7.7 Government-Wide Project Application (GVPR) Table

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3916.7.7.1 Government-Wide Project Application (GVPR)

Table Screen Print and Field Descriptions . . . . . . . 3916.8 Project Accounting Transactions Overview . . . . . . . . . . . . . . . 42

16.8.1 Project Accounting Transaction Policies. . . . . . . . . . . . . 4416.8.2 Project Establishment Control Agency Procedures. . . . . 44

16.8.2.1 Agency-Specific Procedures for ProjectEstablishment . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

16.8.3 Project Master (PJ) Transaction Control AgencyProcedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4516.8.3.1 Agency-Specific Procedures for the Project

Master (PJ) Transaction . . . . . . . . . . . . . . . . . . . . . 4516.8.3.2 Project Master (PJ) Transactions Screen Print

and Field Descriptions . . . . . . . . . . . . . . . . . . . . . . 4616.8.4 Project Charge (PX) Transaction Control Agency

Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5216.8.4.1 Agency-Specific Procedures for the Project

DIV. OF ADMINISTRATION AND16-ii STATE TREASURER POLICIES MANUAL - June 1996


Charge (PX) Transaction . . . . . . . . . . . . . . . . . . . . 5216.8.4.2 Project Charge (PX) Transaction Screen Print

and Field Descriptions . . . . . . . . . . . . . . . . . . . . . . 5216.8.5 Non-Payable Invoice (NP) Transaction Overview. . . . . . . 55

16.8.5.1 Non-Payable Invoice (NP) Transaction Policies . . 5516.8.5.2 Non-Payable Invoice (NP) Transaction

Procedures. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5516.8.5.3 Non-Payable Invoice (NP) Transaction Screen

Print and Field Descriptions . . . . . . . . . . . . . . . . . . 5616.9 Project Purge/Archive Process Overview. . . . . . . . . . . . . . . . . . . 5916.10 Capital Outlay Project Close-Out Process Overview. . . . . . . . . 60

16.10.1 Capital Outlay Project Close-Out Process ControlAgency Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

DIV. OF ADMINISTRATION ANDSTATE TREASURER POLICIES MANUAL - June 1996 16-iii


16 PROJECT ACCOUNTING

16.1 Project Accounting Overview

This section describes the basic concepts of Capital Outlay Project Accounting. It identifies the tables thatare used, both user-maintained and system-maintained, and gives the details for the Project Master (PJ)and Project Charge (PX) transactions.

The Project Accounting component in GFS maintains project related data independent from theorganization structure. Each state agency can define the project structure and usage specific to theiragency. Projects may be divided into subdivisions (subprojects) to account for subprojects by definedphases. The major uses of Project Accounting are to:

· Plan and budget for alternate fiscal years and for multiple fiscal years, independent of thestate fiscal year and to record revenues and expenditures by year for life of the project;

· Record all applicable costs and revenues so that full costs can be matched to revenues foreach accounting period and over the life of the project;

· Provide management with total costs and associated revenues to assist in the decisionmaking process, so that limited resources can be used more cost-effectively.

The primary function of the Project Accounting module is to identify and collect all project-relatedfinancial information. All descriptive and financial information pertaining to a project structure will bemaintained in the various project tables and ledgers. Information is available to support a wide varietyof reporting options.

Numerous system-maintained tables are updated as project specific data is processed. These tables containdescriptive data, budgets, encumbrances, expenditures, revenues and balances for each project, sub-projectand phase. In addition, there is a project ledger that maintains inception-to-date detail transactions foreach project.

Project Accounting provides the capability to reject spending transactions which exceed budgeted projectamounts. The available funds edit checks for project spending and is performed at the sub project/phasebudget line level. Transactions which exceed available funds can be rejected or accepted based on thecontrol level desired for each project budget line and established by the agency. Appropriations will existand all transactions are subject to appropriation control, but these are independent of the project budget.In addition, start and end date ranges may be established that identify the time span in which projecttransactions may be processed. Projects and portions of projects may be closed so that transactions arenot allowed.

Frequently, projects are not monitored by the same fiscal year as the state accounting fiscal year and oftenextend over more than one year. GFS addresses this issue by specifically providing a "project fiscal year"for each project which is independent of the accounting fiscal year. This allows the preparation of project

DIV. OF ADMINISTRATION ANDSTATE TREASURER POLICIES MANUAL - June 1996 16-1


budgets that are based on lifetime budgets. Thus, budgets can be established that are not closed at the endof the accounting fiscal year, but continue into the new year and for the life of the project with remainingbalances and expended amounts intact. Reports can be produced based upon the state fiscal year, orinception to date for the life of the project on multi-year projects.

The principal functions of Project Accounting include:

· Aggregation of all project related data

· Multi-year inception-to-date budgeting

· Encumbrance/spending control against project budgets

GFS uses four processes for handling project related data:

· Processing Project Master (PJ) Transactions· Entering Information on Project System Tables· Processing Accounting Transactions from GFS· Processing Project Charge (PX) Transactions

In the first process, the Project Master transaction (transaction code PJ) is used to establish a new projectin GFS complete with budgetary and descriptive information, or to change the basic information pertainingto an existing project. A Project Master transaction must be accepted and a valid project established inGFS before any accounting transactions that reference that project or Project Charge (PX) transaction willbe accepted. The following information is entered on the Project Master (PJ) transaction:

· Valid project, subproject, and phase codes

· Project descriptive information such as start, end and agreement dates, status, manager,etc.

· Project budgets for both the entire project and for each subproject/phase

· A project expenditure budget edit control option indicating whether budgetary fundscontrol outside of the normal appropriation control will be placed on the project, and

· A definition of how the project is to be funded.

The second step is to add additional information on various tables after the project is established with theProject Master (PJ) transaction. Entry occurs on two tables: additional project information is stored onthe Agency Project Description (AGP2) table and valid project/appropriation combinations are establishedon the Project by Appropriation (PAPR) table. Although the entry of the AGP2 is optional, transactionswill not be allowed to process without validating against the PAPR table. An alternate view of the PAPR

DIV. OF ADMINISTRATION AND16-2 STATE TREASURER POLICIES MANUAL - June 1996


table may be found on the Appropriation by Project (APRP) table, which is sorted by agency,appropriation, and project as a complement to the PAPR key of agency, project, and appropriation.

Once the project has been established in GFS and linked to the Means-of-Financing (MOF) AppropriationUnits, the system is ready to begin accepting the third type of input -- accounting transactions, includingpurchase orders, invoices, payment vouchers, journal vouchers, and cash receipts. This processing occurswhenever a valid code is entered in the project/job field on a transaction. GFS will perform edits on theproject field, which includes validating the code against the subproject/phase table. If a match is found(and, optionally, available funds exist for the project), the results of the transaction are posted to theapplicable tables and ledgers.

The fourth process, Project Charge, (PX) transactions, are indirect (non-accounting) expenditures. Theseare optional and are entered on PX transactions. PX transactions are edited and once validated, are postedto a project memo ledger. Appropriations are not affected by PX transactions and the financial accountingGeneral Ledger is not updated by Project Charge amounts. There will be limited usage of this transactionby the State.

16.1.1 Project Accounting Policies

The following policies apply to Project Accounting in GFS:

· OSIS will maintain the project accounting functional components in GFS, which includeprocessing of the daily updates (nightly cycles), month-end processing and annualprocessing. Project-life-to-date information will also be maintained in GFS.

· OSRAP will maintain the functional components in GFS project accounting and will beresponsible for informing all affected users of any changes that are made to projectaccounting, either through system modifications or upgrades.

· Agencies using the Project Accounting functionality for capital outlay projects will spenddirectly against respective Means-of-Financing (MOF).



16.2 Project Accounting Hierarchy/Structure Overview

This section describes the project components and hierarchy. It also describes the project structure relativeto the GFS data elements.

The project accounting capabilities of GFS provide a project planning and control structure which isavailable for on-line query and project reporting. GFS provides a four-level hierarchical structure forproject planning and accounting. The four-level structure is:

· Government-wide Project- The codes previously described for project management areall restricted to projects within a single agency. GFS provides a higher optional levelattribute to link together, for reporting purposes, multiple projects within an agency. Thiscode, the government-wide project number, is a five-character alphanumeric field. It maybe used, for example, in a construction project where one project accounts for the landpurchases and another project accounts for construction of a building. When this modelis followed, the system will account for the separate projects, as well as tie them togetherfor central monitoring and reporting.

· Project - The key component of the project hierarchy is the project number. The projectnumber is a five-character alphanumeric code which is defined as unique within anagency. In this way, agencies will have the flexibility to determine exactly what definesa project and to assign their own numbers.

· Subproject - Projects are divided into subprojects. Subproject is a two-characteralphanumeric code, which will be agency-defined as to number, purpose, and description.In order to facilitate processing and edits, GFS requires that every project have at leastone subproject (and phase). For example, construction projects can be fairly well definedby phases such as site acquisition, pre-construction engineering, site preparation,construction, etc.

· Phase- Projects and subprojects are further divided into phases. Phases represent distinctstages in the project life-cycle. The phase code is a single alphanumeric character and isnot unique by agency, which means that agencies will share the phase identifiersstatewide. In order to facilitate processing and edits, GFS requires that every project haveat least one subproject and phase.

The numbering scheme for projects and subprojects is unique by GFS agency (Agency). It will be theresponsibility of agencies using project accounting to determine and maintain the numbering scheme fortheir own projects and subprojects.



16.2.1 Project Coding Data Elements

Both the financial accounting and the project accounting capabilities in GFS share the coding elements,so that both are entered on the same transaction line. The following presents the GFS coding dataelements:

· Required Fields:

- Fund- Agency- Appropriation Unit- Object/Revenue Source- Project/Job Number

· Optional Fields:

- Activity

When the project data field, along with the additional data elements specific to certain transactions, isentered on the transaction(s), the accepted data results in both the financial and project accounting tablesand ledgers being updated.



16.3 Project Accounting Controls Overview

This section describes the various controls used for Project Accounting. These controls relate to whenthe project is initially set up and the timing of editing and processing transactions.

Controls and edits are performed by GFS that are specific to projects. Some of the controls are requiredand some are optional. The more significant controls are discussed below.

Transactions that include a project code are subject to two primary types of edit controls: budgetarycontrols and document processing controls. These are discussed below:

· Two types of budgetary controls may be applied to transactions that reference projects.The standard GFS appropriation edits and controls are enforced. In addition, availablebudget edits and controls are enforced on project budget lines, if the optional projectbudget funds control has been selected.

· Document processing controls apply to general accounting transactions on which projectnumbers have been coded, such as purchase orders, payment vouchers and cash receipts.First, the project, subproject, and phase must exist on the project tables before anytransactions containing the project number will be accepted by GFS. Second, thetransaction date must be after the starting date of the project and, with the exception ofrevenues and receipts, must be dated earlier than the end date of the project. Revenuesand receipts can be posted to valid projects until the project is closed or purged, withoutregard to the end date.

· Another control method used to edit project or job transactions is defined on theFund/Agency (FAGY) table. This control is the project/job precedence indicator. Itdetermines whether to first edit a data element in the job/project coding field as a job orproject. Agencies will need to determine which one will be used more frequently, so thatOSRAP can set this indicator accordingly. FAGY table setup is discussed in the "GeneralAccounting" section of this manual.NOTE: The State currently is not using the JobCost Billing subsystem, therefore, the "project" will always be the precedence indicator.

The GFS Project Accounting module contains a status indicator at the subproject and phase line level foreach project on the Project Budget Line (PRBL) table. This status can be either "O" (Open) or "C"(Closed), and is initially set up or changed using a Project Master (PJ) transaction. In order to charge orreceive funds against a project, the referenced subproject/phase must have a status of "O" (Open). Asparticular phases of a project are completed, or for a temporary stopping of updates, the user canoptionally close ("C") the subproject/phase line. This prevents expenditures and receipts from beingcharged to the subproject and phase.



Overall, project status codes are:

P Pending (funding for project is pending)E Ended (project is closed; however, information is to remain in the system and will not

be purged)O Open (project is active)

C ClosedN Non-Payable ProjectF Non-Payable Project (Project is finished; however, information is to remain in the system

and will not be purged.)

The optional funds control edit, also at the subproject and phase line level, is used to limit projectspending control to the budgeted amount. If the funds edit is selected, GFS will check for availableproject budget before expenditure transactions can be accepted. If the spending document causes theproject budget to be exceeded, the transaction will be rejected.

When establishing a new project the phase code must be valid on the Project Phase Reference (PRPH)table. The edits and controls listed above are discussed in the Project Accounting - Project Transactionssection of this manual. See Section 16.8.3 (Project Master (PJ) Transaction Initial Entry andModifications Procedures).

16.3.1 Project Accounting Control Policy

It will be the responsibility of Project Accounting users at the agencies to establish and maintain thosecontrols that are optional with projects.



16.4 Project Accounting Budgets Overview

This section discusses the budgeting concepts and methods available for Project Accounting in GFS.

Project budgets are established at two levels:

· Project level for source of funding estimates

· Project, subproject and phase levels for expenditure estimates

The Project Master (PJ) transaction establishes the original budgets and modifies an existing budget. Thetotal of the source of funds estimate at the project level must equal the total of the expenditure estimatesat the subproject and phase level.

Project budgets are independent of, and in addition to, appropriations established for financial accounting.The appropriation controls are always enforced on accounting transactions. The Project Accounting usercan enforce the additional project budget control at the subproject and phase level by setting the fundscontrol edit to "Y" (Yes).

The subproject and phase detail level of the budgeted expenditures is established for each detail line indollar amounts, including cents. The total of all subproject and phase detail line budgets must equal thetotal of the estimated funding sources at the project level.

There are situations where Project Accounting users want to account for a project using several subprojectand phase lines, but do not want to budget using all subproject and phase combinations. All of these mustbe established and validated on the project tables. This is accomplished in GFS by establishing the non-budget subproject and phase combinations with zero dollar budgets and no funds control.

The overall project level budget, which is the estimated funding source(s) at the project level, isestablished for both dollar amounts (including cents) and percentage of total project funding by eachfunding source. The funding sources are:

· Bond Funds - This is the amount of revenue estimated to be received to fund the projectfrom the issuance of bonds.

· Federal Funds - This is the amount of revenue estimated to be received to fund theproject from federal funding sources.



· Government Funds- This is the amount of state appropriation(s) expected to be used tofund the project.

· Other Funds - This is the amount of revenue estimated to be received from other fundingsources.

The combined total expected to be received from the above funding sources must equal the total expectedto be spent on the project and must equal 100 percent of the funding. Setting up the estimated fundingsources are discussed in the "Project Transactions - Project Master (PJ) Transaction Procedures" sectionof this manual. See Section 16.8.3.

16.4.1 Project Accounting Budgets Policy

It will be the responsibility of Project Accounting users at the agencies to establish and maintain thebudgets for their projects.



16.5 Project Accounting Multi-Year/Full Cost Overview

This section discusses the multi-year and full cost capabilities using Project Accounting.

When a project is established, the start and end dates are determined and entered on the project record.This allows multiple year projects to be budgeted for the life of the project and to remain open formultiple fiscal years. The detail transactions for the life of the project are maintained in an inception-to-date project ledger, which permits the reporting of detail data as long as the project is open.

The project is not closed at the end of each state fiscal year, but continues for as many years as the projecttakes to complete or close. The year-end processing and subsequent closing of the State’s financialrecords for a fiscal year does not affect projects. The project is closed when the project end date isreached and no further transactions need to be posted. The end date is set up with the Project Master (PJ)transaction.

Recording of indirect and overhead costs is accomplished using the Project Charge (PX) transaction. Thistransaction posts these costs to the project ledger only. It does not post them to the general ledger sincethe costs were not paid directly by the State. Using the project charge transaction allows costs such aslocal government or private participation to be charged to the project. Using the Project Chargetransaction is discussed in the "Project Transactions - Project Charge (PX) Entry Procedures" section ofthis manual. See Section 16.8 4.

16.5.1 Project Accounting Multi-Year/Full Cost Policies

The following policies apply to Project Accounting multi-year/full cost:

· Agencies using project accounting will be responsible for determining the length of timea project may have transactions recorded to it, and to close the project when it has ended.

· Agencies are responsible for recording full costs to a project to ensure the transaction iscorrect.



16.6 Project Accounting User-Maintained Tables Overview

This section provides instructions on how to enter additions and modifications of the data on the user-maintained master reference tables to assist Project Accounting users at the agencies. User is defined aseither an agency end user or a control agency system administrator.

The GFS Project Accounting and Management module has five user-maintained master reference tablesand six system-maintained master application tables. The user-maintained master reference tables aredescribed below. Information about the user-maintained reference tables follow. The system-maintainedmaster application tables are discussed in theGFS Online FeaturesGuide,Appendix B.

The project accounting user-maintained reference tables are:

· AGP2 table (AGP2)· Project Phase Reference table (PRPH)· Project Status Reference table (PRST)· Charge Class Reference table (CHRG)· Project by Appropriation table (PAPR)· Sub-Project Name table (SPNT)

Each of the tables are described further following the user-maintained table policies section.

16.6.1 Project Accounting User-Maintained Tables Policies

The following policies apply to the Project Accounting User-Maintained tables:

· Facility Planning and Control will maintain the data on the Project Phase and ProjectStatus tables. Agency users that want changes or additional entries made to these tablesshould contact that office.

· Agency Project Accounting users will enter and maintain the data on the Charge Class(CHRG) and Project by Appropriation (PAPR) user-maintained tables.



16.6.2 Project Phase Reference (PRPH) Table Overview

The Project Phase Reference (PRPH) table contains valid codes established to define the various phasesof a project or subproject. Project phase codes are defined statewide. This means that all projects mustuse the standard phase codes on this table. The project phase code is composed of one alphanumericcharacter. Requests for additional phase definitions may be made through Facility Planning and Control.

16.6.2.1 Project Phase Reference (PRPH) Table Procedures

The following procedures identify the responsibilities for maintaining the Project Phase table (PRPH).

Responsibility Action

Agency Determines the project code value and the description of the phase to be addedto the table for new entries, and ensures that the new code value is not alreadyon the Project Phase Reference (PRPH) table. For the modification of an existingentry, the only data that can be modified is the Phase Description, ShortDescription, or Construction Indicator.

Completes the "Project Phase/Status Table Addition/Modifications Form"(FORM PRPH) and forwards it to Facility Planning and Control. The "ProjectPhase/Status Table Addition/Modification" (FORM PRPH) and instructions forcompletion are presented in this section of the manual.

Facility Planning andControl When the "Project Phase/Status Table Addition/Modification Form" (FORM

PRPH) is received, reviews for completeness. If either the addition ormodification can be made, updates the Project Phase Reference (PRPH) table andnotifies the requestor that the entry is completed. If the addition or modificationcannot be made, notifies the requestor and states reason that entry cannot bemade.

16.6.2.2 Agency-Specific Procedures for the Project Phase Reference (PRPH) Table



16.6.2.3 Project Phase Reference (PRPH) Table Screen Print and Field Descriptions

The screen print of the Project Phase Reference (PRPH) table is pictured below, and field descriptionsfollow.

Project PhaseTable (PRPH) ACTION: . TABLEID: PRPH USERID: ........

PROJECT PHASE TABLEKEY IS PHASE

CONSTPHASE DESCRIPTION SHORT DESC IND----- ------------------------------ ------------ -----

01- . .............................. ............ .02- . .............................. ............ .03- . .............................. ............ .04- . .............................. ............ .05- . .............................. ............ .06- . .............................. ............ .07- . .............................. ............ .08- . .............................. ............ .09- . .............................. ............ .10- . .............................. ............ .11- . .............................. ............ .12- . .............................. ............ .13- . .............................. ............ .14- . .............................. ............ .15- . .............................. ............ .

The field descriptions for the Project Phase Reference (PRPH) table are as follows.

The Project Phase (PRPH) table contains valid codes established to define the various phases of a projector subproject. Since this table is user-maintained, the meaning associated with each phase code will bedefined based on the individual needs of a user. The phases are defined system-wide.This means that, inthe interest of standardization, each department establishing a project must choose its phase codes fromthe standard codes on this table. Since the project phase code is restricted to one alphanumeric character,there is a limited number of unique codes available. Therefore, defining a set of codes relevant to allpossible projects for all departments must be a well-planned and coordinated effort.

This is a user-maintained table. Only those users with appropriate authority may add, change, or deletephase codes on this table.

PHASE

DESCRIPTION

SHORT DESC

CONST IND

Required. Enter a character specifying a project phase.

Optional. Enter a description of the phase.

Optional. Enter a short description of the phase.

Optional. If used, enter "Y" (Yes) if this is a constructionphase or "N" (No) if this is not a construction phase.



16.6.3 Project Status Reference (PRST) Table Overview

The Project Status Reference (PRST) table contains valid codes used to define the status of the totalproject. These status codes are informational only and are used to define the overall status at the projectlevel. Two of the typical codes are open and closed. Project status codes are defined statewide, whichmeans that all projects must use status codes from the valid codes on this table. The project status codeis composed of one alphanumeric character.

16.6.3.1 Project Status Reference (PRST) Table Procedures

The following procedures identify the responsibilities for maintaining the Project Status Reference (PRST)table.


Agency Determines the status code value and the description of the status to beadded to the Project Status Reference (PRST) table for new entries, andensures that it is not already on the Project Status Reference (PRST) table.For the modification of an existing entry, the only data that can be modifiedis the Status Name and the Status Short Name.

For requests to change or additions to the Project Status Reference (PRST)table, agency prepares memo stating reason for change or addition to thetable. Forwards memo to Facility Planning and Control for approval.

Facility Planning andControl When the agency’s memo to request change/addition to the Project Status

Reference (PRST) table is received, reviews for completeness. If either theaddition or modification can be made, updates the table and notifies therequestor that the entry is completed. If the addition or modification cannotbe made, notifies the requestor and explains reason that entry cannot bemade.

16.6.3.2 Agency-Specific Procedures for the Project Status Reference (PRST) Table



16.6.3.3 Project Status Reference (PRST) Table Screen Print and Field Descriptions

The screen print of the Project Status Reference (PRST) table is pictured below, and field descriptionsfollow.

Project StatusTable (PRST) ACTION: . TABLEID: PRST USERID: ........

PROJ STATUS TABLEKEY IS PROJ STATUS CODE

STATUS CODE STATUS DESCRIPTION SHORT NAME----------- ------------------------------ ------------

01- . .............................. ............02- . .............................. ............03- . .............................. ............04- . .............................. ............05- . .............................. ............06- . .............................. ............07- . .............................. ............08- . .............................. ............09- . .............................. ............10- . .............................. ............11- . .............................. ............12- . .............................. ............13- . .............................. ............14- . .............................. ............15- . .............................. ............

The field descriptions for the Project Status Reference (PRST) table are as follows.

The Project Status (PRST) table contains user-defined codes to be used for inquiries and reports. Thesecodes are used primarily to indicate the current status of a project (e.g. open, pending final close out,closed), but may be used for other purposes also.

This is a user-maintained table. Only those users with appropriate authority may add, change, or deletephase codes on this table.

STATUS CODE

STATUSDESCRIPTION

SHORT NAME

Required. Enter a code to be used to identify project status.

Optional. Enter a description for the status code defined onthis line.

Optional. Enter a short description of the status code.



16.6.4 Charge Class Reference (CHRG) Table Overview

The Charge Class Reference (CHRG) table is used to establish different classes of goods and services andassign each a standard cost or rate per unit. When a PX document is processed, the Project Chargeprogram uses these codes to compute indirect charges by multiplying the units of goods or services bythe standard rate defined on the Charge Class (CHRG) table. This table is shared with the Job CostAccounting and the Federal Aid Management components of GFS. CHRG and the associated ProjectCharge (PX) transaction will have limited use by the State.

16.6.4.1 Charge Class Reference (CHRG) Table Procedures

The following procedures identify the responsibilities for maintaining the Charge Class (CHRG) Table.


Agency Determines the charge classes and standard rate for each class that will beused for standard charging on the Project Charge (PX) transaction.

16.4.2 Agency-Specific Procedures for the Charge Class Reference (CHRG) Table



16.4.3 Charge Class Reference (CHRG) Table Screen Print and Field Descriptions

The screen print of the Charge Class Reference (CHRG) table is pictured below, and field descriptionsfollow.

Charge ClassTable (CHRG) ACTION: . TABLEID: CHRG USERID: ........

CHARGE CLASS TABLEKEY IS FISC YEAR, CHARGE CLASS

CHARGE STANDARD ACCTFY CLASS CHARGE CLASS NAME RATE TYPE ACCOUNT-- ------ ------------------------------ --------- ---- -------

01- .. ... .............................. ........ .. .... ..02- .. ... .............................. ........ .. .... ..03- .. ... .............................. ........ .. .... ..04- .. ... .............................. ........ .. .... ..05- .. ... .............................. ........ .. .... ..06- .. ... .............................. ........ .. .... ..07- .. ... .............................. ........ .. .... ..08- .. ... .............................. ........ .. .... ..09- .. ... .............................. ........ .. .... ..10- .. ... .............................. ........ .. .... ..11- .. ... .............................. ........ .. .... ..12- .. ... .............................. ........ .. .... ..13- .. ... .............................. ........ .. .... ..14- .. ... .............................. ........ .. .... ..

The Charge Class Reference (CHRG) table field descriptions are as follows.

The Charge Class (CHRG) table is a user-maintained table. The CHRG table is used to establish differentclasses of goods and services and assign each a standard cost or rate per unit. It is keyed by fiscal yearand charge class code. The Federal Aid Charge program uses these codes to compute indirect charges bymultiplying the units of goods or services by the standard rate defined on the Charge Class ReferenceTable. This table is shared by the Job Cost Accounting and Project Management subsystems.

FY

CHARGE CLASS

CHARGE CLASSNAME

STANDARD RATE

Required. Entered the last two digits of applicable fiscal year.

Required. Enter a unique code identifying the class of goodor service.

Optional, but no description will appear on reports if leftblank. Up to 30 characters may be entered to describe thegood or service. May be used to indicate the unit ofmeasurement to which the standard rate applies (e.g., rate perhour or rate per day).

Required. Enter the cost per unit (dollars and cents). Valuemay not be greater than 9999999, if entered without a decimal



ACCT TYPE

ACCOUNT

point (format routine will insert with 4 decimal placesassumed) or value must be entered with 4 decimal places.

The rate will be multiplied by the number of units coded ona federal aid charge transaction to compute the full cost to becharged to the grant.

Not used in the Federal Aid system.

Not used in the Federal Aid system.

16.6.5 Project by Appropriation (PAPR) Table Overview

The Project by Appropriation (PAPR) table is used to establish the valid project/appropriationcombinations for project accounting transactions. Agencies will enter all valid combinations on this tableonce a project is established in the Project Accounting subsystem. Transactions (except the DepositSuspense (DS), Warrant Voucher (WV), and Non-Payable Invoice (NP) documents) that do not have acombination appearing on this table, will reject when they are processed.

An alternate view of this table is provided by the Appropriation by Project (APRP) table. Whenever anaddition, deletion, or change is entered on the Project by Appropriation (PAPR) table, the APRP isautomatically updated by the system.

16.6.5.1 Project by Appropriation (PAPR) Table Procedures

The following procedures identify the responsibilities for maintaining the Project Appropriation (PAPR)table.


Agency Defines and maintains the values for the Project by Appropriation (PAPR)table.

16.6.5.2 Agency-Specific Procedures for the Project by Appropriation (PAPR) Table



16.6.5.3 Project by Appropriation (PAPR) Table Screen Print and Field Descriptions

The screen print of the Project by Appropriation (PAPR) table is pictured below, and field descriptionsfollow.

Project ByAppropriation ACTION: TABLEID: PAPR USERID: ....

Table (PAPR) PROJECT BY APPROPRIATION TABLE

KEY IS AGENCY, PROJECT, APPR, BUDGET FISC YEAR, FUND, ORGANIZATION

AGENCY PROJECT APPR BFY FUND ORGN PRIORITY LEGIS ACT------ ------- ---- --- ---- ---- -------- ---------

01- ... ..... .... .. ... .... . ....02- ... ..... .... .. ... .... . ....03- ... ..... .... .. ... .... . ....04- ... ..... .... .. ... .... . ....05- ... ..... .... .. ... .... . ....06- ... ..... .... .. ... .... . ....07- ... ..... .... .. ... .... . ....08- ... ..... .... .. ... .... . ....09- ... ..... .... .. ... .... . ....10- ... ..... .... .. ... .... . ....11- ... ..... .... .. ... .... . ....12- ... ..... .... .. ... .... . ....13- ... ..... .... .. ... .... . ....14- ... ..... .... .. ... .... . ....15- ... ..... .... .. ... .... . ....

The Project by Appropriation (PAPR) table field descriptions are as follows.

The Project by Appropriation (PAPR) table is used to establish the valid project/appropriationcombinations for project accounting transactions. The table is keyed by agency, project, appropriation,budget fiscal year, fund, and appropriation organization. After a project is established in the projectaccounting system, the user will enter all valid combinations on this table. Transactions (except the DS,WV, and NP) which do not have a combination appearing on this table will reject when they areprocessed.

An alternate view of this table is provided by the Appropriation by Project Table (APRP). Whenever anaddition, deletion, or change is entered on the Project by Appropriation Table, the APRP is automaticallyupdated by the system.

This is a user-maintained table.

AGENCY

PROJECT

Required. The agency associated with the project andappropriation unit entered in the PROJECT and APPR fields.

Required. Unique code identifying the project associated withthe agency and appropriation entered.



APPR

BFY

FUND

ORGN

PRIORITY

LEGIS ACT

Required. Appropriation unit number for the Means ofFinancing (for the agency entered) that finances the projectnumber entered in the PROJECT field.

Required. Budget fiscal year of the Means of Financingappropriation associated with the project.

Required. Capital Outlay fund used by the project.

Leave blank. This field is not being used at this time.

Optional. Priority specified in the Capital OutlayAppropriation Act. This field is optional and should be leftblank if there was no required priority.

Optional. The Legislative Act number associated with theproject.

16.6.6 Sub-Project Name (SPNT) Table Overview

The Sub-Project Names (SPNT) table contains the valid sub-project codes and the identifying sub-projectnames. These names are used for descriptions on reports. The table is available for inquiry purposes andad-hoc reporting. Users with appropriate authority may add, change, or delete information as necessary.The table is keyed by agency, project and sub-project.

16.6.6.1 Sub-Project Name (SPNT) Table Policies

The following policies apply to the maintenance of the Sub-Project Name (SPNT) table.

· Agency Project Accounting users will maintain the data on the Sub-ProjectName (SPNT) table.

· Agency users with appropriate authority will add, change, or deleteinformation on this table as necessary.

· The Sub-Project Name (SPNT) table is informational. This table is availableto agency users for inquiry and ad-hoc reporting.



· The Agency users will determine what the sub-project code represents basedon the individual needs of their agency.

16.6.6.2 Sub-Project Name (SPNT) Table Screen Print and Field Descriptions

The screen print of the Sub-Project Name (SPNT) table is pictured below, and field descriptions follow.

Sub-ProjectName Table ACTION: . TABLEID: SPNT USERID: ........

(SPNT)SUB PROJECT NAME TABLEKEY IS AGENCY, PROJECT, SUB-PROJECT

AGENCY: ... PROJECT: .....SUB PROJ SUB PROJECT NAME--------- ------------------------------

01- .. ..............................02- .. ..............................03- .. ..............................04- .. ..............................05- .. ..............................06- .. ..............................07- .. ..............................08- .. ..............................09- .. ..............................10- .. ..............................11- .. ..............................

The field descriptions of the Sub-Project Name (SPNT) table are as follows. The Sub-Project Name(SPNT) table is used to store names for sub projects. These names are used for descriptions on reports.

This is a user-maintained table. Users with appropriate authority may add, change, or delete informationas necessary.

AGENCY

PROJECT

SUB PROJ

Required. The agency code in which the project/sub- projectis established. Must be valid on the Agency Table (AGCY).

Required. The project number for which sub-project namesare defined. The agency/project combination must be valid onthe Agency Project Table (AGPR).

Required. The two character sub-project code for which a



SUB PROJECTNAME

name is defined. No validation occurs on this field.

Required. Enter the name of the Sub Project, up to thirty (30)characters. This name will appear on applicable reports.



16.7 Project Accounting System-Maintained Tables Overview

The GFS Project Accounting and Management module has five user-maintained reference tables and fivesystem-maintained application tables. The user-maintained master reference tables are described in the"Project Accounting - User-Maintained Tables" section of this manual. (See Section 16.6.2.1.) Thesystem-maintained master application tables are discussed below.

The Project Accounting system-maintained application tables are:

· Agency Project (AGPR) table· Project Budget Line (PRBL) table

· Project Fiscal Year (PFYT) table· Appropriation by Project (APRP) table· Government-Wide Project Application (GVPR) table

The following sections present a description (overview) of each of the system-maintained applicationtables, screen prints, and field descriptions and values for each field in the tables. Additional informationon each of these tables may be found in theGFS Online FeaturesGuide,Appendix B.

16.7.1 Agency Project (AGPR) Table Overview

The Agency Project (AGPR) table maintains descriptive information and summarizes financial data at theproject level for the life of the project. Some of the information is used by GFS to perform validity edits.The project descriptive data is added or changed on this table when a Project Master (PJ) transaction isaccepted. Financial data on this table is updated when GFS accounting transactions are processed thatreference the project, or when Project Charge (non-accounting) transactions are processed.

16.7.1.1 Agency Project (0AGPR) Table Screen Print and Field Descriptions

The screen print of the Agency Project (AGPR) table is pictured below, and field descriptions follow.

AgencyProject Inquiry ACTION: . TABLEID: AGPR USERID: ........

Table (AGPR) *** AGENCY PROJECT INQUIRY ***

KEY IS AGENCY, PROJECT

AGENCY: ...PROJECT: ..... PROJ YEAR STARTING PRD: ..

PROJECT MANAGER: ....................STATUS: . PROJECT START DATE: .. .. .. PROJECT END DATE: .. .. ..

PROJECT DESCRIPTION: ..............................FHWA PROJECT NUMBER: ....................



GOV-WIDE PROJ: ..... FEDERAL APPR: ... LAST ACTION DATE: .. .. ..

BOND FUNDED AMT: .............. ENCUMBERED AMT: ..............FEDERAL FUNDS AMT: .............. EXPENDED AMT: ..............

GOVERNMENT FUNDS AMT: .............. EXPENSED AMT: ..............OTHER FUNDS AMT: .............. PROJ CHARGES: ..............

ACCRUED REVENUE AMT: ..............COLLECTED REVENUE AMT: ..............

TOTAL AGREEMENT AMT: .............. AVAIL AGREEMENT AMT: ..............FED %: ....... BOND %: ....... GOV’T %: ....... OTHER %: .......FED ROUTE/SECTION: ... .

The Agency Project (AGPR) table field descriptions are as follows. Activity groups group similar activitytypes. The Activity Group (AGRP) table defines valid activity group codes. It is optional (used forreporting purposes only) and, therefore, may not exist at your installation. The actual assignment ofactivity groups into types occurs in the Activity (ACTV) table. See the section on the Activity Table.

Activity Group is predefined as follows:

ACTIVITY GROUP NAME VALUE

General Government 01Public Safety 02Highways and Streets 03Sanitation 04Health Services 05Social Services 06Culture-Recreation 07Education 08Debt Service 09

Other Activity Groups should be added as needed.

FY

ACT GROUP

NAME

Required. Enter the last two digits of the applicable fiscalyear associated with the activity group code.

Required. If adding a new line, enter a unique code; ifchanging or deleting an existing line, enter the affected code.

If you are deleting a line, do not enter the following fields. Ifyou are changing a line, enter only the fields in the rest of thistable that you want changed. If you are adding a new line,follow the instructions for all of the remaining fields.

Optional. However, there will be no descriptions on reportsfor this code if this field is left blank.



ACT GROUPSHORT NAME

Optional. Enter the name that you want to appear on reportswhen there is not enough room for the full name.

16.7.2 Agency Project Description (AGP2) Table Overview

The Agency Project Description (AGP2) table is a user-maintained table which records additionaldescriptive information about projects not captured on the Project Master (PJ) document. When a PJdocument is processed to establish a project, records are created on the Agency Project Master (AGPR)and Agency Project Description (AGP2) tables. The AGPR stores all data entered on the PJ document.The AGP2 record will be initialized with the key (agency, project) but with all descriptive fields empty.The user will then call up the AGP2 record that was created and complete all descriptive fields.

16.7.2.1 Agency Project Description (AGP2) Table Screen Print and FieldDescriptions

The screen print of the Agency Project Description (AGP2) table is pictured below, and field descriptionsfollow.

Agency ProjectDescription Table ACTION: . TABLEID: AGP2 USERID: ........

(AGP2) AGENCY PROJECT DESCRIPTION TABLE

KEY IS AGENCY, PROJECT

AGENCY: ... PROJECT: ..... REQUESTING AGENCY: ... LEGISLATIVE ACT: ....DESC: ..............................................................................................................................................................................................................................................................................................................................................................................................

ACT YR .. SCH. NO: .... PREDOMINANT: PARISH .. SEN DIST .. LEG DIST ...

PRIORITY AMOUNTS1 2 3 4 5

.... .... .... .... ....NO PRIORITY AMOUNT: XXXXXXXXX.XX

COMMENTS: ..............................................................................................................................................................................................................................................................................................................................................................................................

The Agency Project Description (AGP2) table field descriptions are as follows.

The Agency Project Description (AGP2) table records additional descriptive information about projectsnot captured on the PJ document. When a PJ document is processed to establish a project, records are



created on the Agency Project Master (AGPR) and Agency Project Description (AGP2) tables. The AGPRstores all data entered on the PJ document, while the AGP2 record will be initialized with the key (agency,project) but with all descriptive fields empty. The user will then call up the AGP2 record which wascreated and complete those descriptive fields that are needed. All fields on this screen, except RequestingAgency, are optional. This table has as its key the agency and project number.

The AGP2 is a hybrid table. Records are created when the PJ transaction is processed, but all informationis user-maintained afterwards.

AGENCY

PROJECT

REQUESTING AGCY

LEGISLATIVEACT

DESC

ACT YR

SCH.NO

PREDOMINANTPARISH

SEN DIST

LEG DIST

PRIORITY AMOUNTS(1-5)

NO PRIORITYAMOUNT

The agency responsible for the project or subproject. Thisfield is system-populated from the PJ transaction.

Unique code identifying the project. This field is system-populated from the PJ transaction.

Required. The agency which requested the project.

Optional. The number of the Capital Outlay AppropriationAct Number in which the project was authorized.

Optional. A free-form description field in which any otherproject information may be recorded.

Optional. The year of the Capital Outlay Appropriation Actproject was initially approved.

Optional. The schedule number that best describes thisproject. For reporting purposes only.

Optional. Parish that will predominantly benefit from theproject.

Optional. The Senatorial District that will predominantlybenefit from the project.

Optional. The Legislative District that will predominantlybenefit from the project.

Optional. Amount specified in the Capital OutlayAppropriation Act for each priority level (1-5).

Optional. The amount approved that will be spent on theproject for which there is no required priority (usually smallprojects that do not require the sale of bonds.



COMMENT Optional. A free-form comments field in which other projectinformation may be recorded.

16.7.3 Project Budget Line (PRBL) Table Overview

There are two tables used for inquiry of the project budget line data. These tables show the detail levelfor a project where budgets are established and spending controls are set. The Project Budget Line(PRBL) table presents inception-to-date data for the project, subproject, and phase in total. The ProjectBudget Line Inquiry - 2 (PRB2) table presents summary inception-to-date data by each of the fundingsources. These tables maintain descriptive information and summarized financial data at the project levelfor the life of the project. Some of the information is used by GFS to perform validity edits. The projectdescriptive data is added or changed on these tables when a Project Master transaction (PJ) is accepted.Financial data on these tables is updated when GFS accounting transactions are processed that referencethe project, or when Project Charge (PX) transactions are processed.

16.7.3.1 Project Budget Line (PRBL) Table Screen Print and Field Descriptions

The screen print of the Project Budget Line (PRBL) table is pictured below, and field descriptions follow.

Project BudgetLine ACTION: . TABLEID: PRBL USERID: ........

Table (PRBL) *** PROJECT BUDGET LINE INQUIRY ***

KEY IS AGENCY, PROJECT, SUB-PROJECT, PHASE

AGENCY: ... PROJ: ..... SUB-PROJ: .. PHASE: .AUTH DATE: .. .. .. AGREE DATE: .. .. ..

DESCRIPTION: .............................. JOB NUMBER: ........PART / NON-PART: . STATUS: . FUNDS EDIT: . CE PHASE %: .......

ORIG BUDGET AMT: .............. ENCUMBERED AMT: ..............CURR BUDGET AMT: .............. EXPENDED AMT: ..............

AVAIL BDGT AMT: .............. EXPENSED AMT: ..............PROJ CHARGES: ..............

EARNED/UNBILLED: .............. BILLED AMT: ..............REVENUE CREDITS: .............. COLLECTED AMT: ..............

LOCAL MATCH: ..............

The Project Budget Line (PRBL) table field descriptions are as follows.

The Project Budget Line (PRBL) table presents inception-to-date data for the project, sub-project, andphase. It provides the means to plan and control spending by budget line (sub-project/phase combination).



The table is organized by agency, project, subproject, and phase.

This is a system-maintained table. Table records are created by the Project Master (PJ) transaction. Linesare updated on this table whenever a project transaction is accepted by GFS. The table is also updatedby GFS general accounting transactions coded with valid project codes and by Project Charge (PX)transactions.

AGENCY

PROJ

SUB-PROJ

PHASE

AUTH DATE

AGREE DATE

DESCRIPTION

JOB NUMBER

PART/NON-PART

STATUS

FUNDS EDITS

Key field. The agency managing the project.

Key field. The assigned project number for the project.

Key field. The code identifying a certain portion of theproject.

Key field. A unique code used to further segregate theproject. Some phase codes identify areas in which thetransactions originated. Examples: 0 = CFMS; 1 = GFS; 2 =AGPS.

The authorization date (the date spending may begin on thissub-project/phase of the project).

The agreement date (the date billing for reimbursement ofparticipating costs may begin). This field is not being used inLouisiana at this time.

The description of the sub-project as entered on the PJdocument.

If the Job Cost Subsystem is installed for project billing, avalid job number may be entered for this subproject/phase line.This field is not being used in Louisiana at this time.

Defines if this sub-project/phase is eligible to participate in anexpenditure reimbursement process ("P"), or is not eligible forparticipation ("N"). This field is not being used in Louisianaat this time.

Indicates status of sub-project/phase. Valid values are "O"open or "C" closed.

If " Y", this indicates available funds should be calculated andedited prior to spending. If "N", available funds edit isperformed, but only warning messages are issued if



CE PHASE %FED SEQUENTIAL

ORIG BUDGET AMT

ENCUMBERED AMT

CURR BUDGET AMT

EXPENDED AMT

AVAIL BDGT AMT

EXPENSED AMOUNT

PROJ CHARGES

EARNED/UNBILLED

BILLED AMT

REVENUE CREDITS

COLLECTED AMT

LOCAL MATCH

expenditures exceed available budget.

The percent of the budget amount funded by either bonds,federal, government or other funds for the constructionengineering phase of the sub-project phase.

The original budget amount for the project budget line.

The total of all outstanding purchase orders submitted againstthis project budget line.

The current total budget amount for the project budget line,including any modifications made on the Project Master (PJ)document.

The total amount spent against this project budget line (i.e., allpayment vouchers and expenditure journal vouchers).

The unobligated portion of the budget for the project budgetline.

The total amount of all expenses charged to this project budgetline (for example, issued from inventory). This amount willdiffer from the EXPENDED AMT only if the distinction ismade between the expenditure for an item and when thecharge is reclassified as an expense.

Amounts charged to this project budget line on Project Charge(PX) transactions.

All unbilled spending transactions for participating costs. Thisfield is not being used in Louisiana at this time.

All billed spending transactions for participating costs. Thisfield is not being used in Louisiana at this time.

Revenues earned by the project which can be netted againstbillable costs (for example, the sale of land, rent, etc.). Thisfield is not being used in Louisiana at this time.

Revenues recorded as collected by the project through cashreceipts transactions.



Calculated. This field contains the revenues recorded ascollected by the project through local match receipts. Thisfield is not being used in Louisiana at this time.

16.7.4 Project Budget Line Inquiry - 2 (PRB2) Table Overview

The Project Budget Line Inquiry - 2 (PRB2) table presents summary inception-to-date by each of thefunding sources (federal-funded, bond funds, state funds, and other funds). This table maintainsdescriptive information and summarized financial data at the project level for the life of the project.

16.7.4.1 Budget Line Inquiry - 2 (PRB2) Table Screen Print and Field Descriptions

The screen print of the Project Budget Line Inquiry - 2 (PRB2) table is pictured below, and fielddescriptions follow.



ACTION: S TABLEID: PRB2 USERID: ........*** PROJECT BUDGET LINE INQUIRY (2 OF 2) ***

KEY IS AGENCY, PROJECT, SUB-PROJECT, PHASE

AGENCY: PROJ: SUB-PROJ: PHASE:

AUTH DATE: AGREE DATE:

DESCRIPTION: JOB NUMBER:

PART / NON-PART:

CURR BUDGET AMT: AVAIL BUDGET AMT:

FEDERAL STATE BOND OTHER

------- ----- ---- -----

EXP SHARES

EXPENDED

PRJ CHARGES

BILLED REV

COLLECT REV

REV CREDITS

The Project Budget Line Inquiry - 2 (PRB2) table field descriptions are as follows.

Field Name Field Description

AGENCY Required (Key Field). This field contains avalid agency code for the agency managing theproject. The code used must be valid on theAgency Master Reference (AGCY) table.




PROJECT Required (Key Field). This field contains theunique assigned project number for the project.

SUB-PROJECT Required (Key Field). This field contains thecode that identifies a certain portion (subproject)of the applicable project.

PHASE Required (Key Field). This field contains thecode that identifies where the transactionoriginated. Valid values are:

0 - CFMS; 1 - GFS;2 - AGPS;3 - Unauthorized or Unobligated.

AUTHORIZATIONDATE

Inferred. This field contains the authorizationdate (the date spending may begin on thissubproject/phase of the project). Enter the datein "calendar date" format (MMDDYY).

AGREEMENT DATE Inferred. This field contains the agreement date(the date billing for reimbursement ofparticipating costs may begin). The date isentered in "calendar date" format (MMDDYY).

DESCRIPTION Inferred. This field contains any descriptivei n f o r m a t i o n a p p l i c a b l e t o t h i sproject/subproject/phase line.

JOB NUMBER Inferred. This field contains the valid jobnumber for this project/subproject/phase line.

PARTICIPATION/NON-PARTICIPATION

Inferred. This field contains a valid code if theJob Cost Billing subsystem is installed, and ifthis subproject/phase is eligible to participate inan expenditure reimbursement process. Ifeligible, valid value is "P" (participation). If thesubproject/phase is not eligible for participation,"N" (non-participation) is entered in this field.

CURRENT BUDGETAMOUNT

Calculated. This field contains the current totalproject budget amount including changes madeby adjustment actions on the project transaction.

AVAILABLE BUDGETAMOUNT

Calculated. This field contains the unobligatedportion of the project budget.




EXPENSED SHARES Calculated. This field contains the percentamount of expensed shares from each fundingsource (federal, state, bond, other funds).

EXPENDED Calculated. This field contains the total amountspent against this project (i.e., all paymentvouchers and expenditure journal vouchers) fromeach funding source (federal, state, bond, otherfunds).

PROJECT CHARGES Calculated. This field contains the amountrecorded on charge transactions against thisproject from each funding source (federal, state,bond, other funds).

BILLED REVENUE Calculated. This field contains the amount ofrevenues billed by the project (spendingtransactions) for participating costs from eachfunding source (federal, state, bond, other funds).

COLLECTED REVENUE Calculated. This field contains the revenuescollected by the project through cash receiptstransactions from each funding source (federal,state, bond, other funds).

REVENUE CREDIT Calculated. This field contains the revenuesearned by the project which can be nettedagainst billable costs (for example, the sale ofland, rent, etc.) from each funding source(federal, state, bond, other funds).



16.7.5 Project Fiscal Year (PFYT) Table Overview

The Project Fiscal Year (PFYT) table presents summary data by project fiscal year at the subproject andphase level for each project. This is in contrast to the other project tables which maintain life-to-date data.The table is updated by GFS accounting transactions and Project Charge (PX) transactions. The key tothe table is fiscal year, agency, project, sub-project, and phase. The project fiscal year presented beginswith the calendar month input on the Project Master (PJ) transaction and identified on the Agency Project(AGPR) table as "PROJ YEAR STARTING PRD" and each successive fiscal year begins with the samemonth. The "PROJ YEAR STARTING PRD" is July, therefore the fiscal year presented is the same asthe State’s fiscal year.

16.7.5.1 Project Fiscal Year Inquiry (PFYT) Table Screen Print and FieldDescriptions

The screen print of the Project Fiscal Year Inquiry (PFYT) table is pictured below, and field descriptionsfollow.

Project FiscalYear Inquiry ACTION: . TABLEID: PFYT USERID: ........

Table (PFYT) *** PROJECT FISCAL YEAR INQUIRY ***

KEY IS FISC YEAR, AGENCY, PROJECT, SUB-PROJ, PHASE01-

FISC YEAR: .. AGENCY: ...PROJECT: ..... SUB-PROJ: .. PHASE: .

PROJ-FISC-YR-ST-PRD: ..FY BDGT AMT: ..............

YTD ENCUMBERED AMT: .............. YTD EXPENDED AMT: ..............YTD EXPENSED AMT: .............. PROJ CHARGES AMT: ..............

02-FISC YEAR: .. AGENCY: ...

PROJECT: ..... SUB-PROJ: .. PHASE: .PROJ-FISC-YR-ST-PRD: ..

FY BDGT AMT: ..............YTD ENCUMBERED AMT: .............. YTD EXPENDED AMT: ..............

YTD EXPENSED AMT: .............. PROJ CHARGES AMT: ..............



The Project Fiscal Year Inquiry (PFYT) table field descriptions are as follows.

The Project Fiscal Year Inquiry (PFYT) table provides a summary of budget, encumbrances, expenditures,and project charges by the state fiscal year for each sub-project/phase of a project. This is in contrast tothe other project tables which maintain lifetime data. This table contains only accounting actuals.

The table is organized by fiscal year, agency, project, sub-project and phase.

This is a system-maintained table. Table records are created by the Project Master (PJ) transaction, andare updated by normal expenditure transaction processing.

FISC YEAR

AGENCY

PROJECT

SUB-PROJ

PHASE

PROJ-FISC-YR-ST-PRD

FY BDGT AMT

YTD ENCUMBEREDAMT

YTD EXPENDEDAMT

YTD EXPENSED AMT

Key field. The fiscal year (usually the state fiscal year) forwhich project/subproject/phase data is summarized. Financialactivity listed was processed during accounting periods withinthe fiscal year.

Key field. The agency responsible for the project.

Key field. The assigned project number for the project.

The code identifying the portion of the project accounted foron this line.

The code further segregating the project accounted for on thisline.

The calendar month in which the fiscal year associated withthis project starts. Project years will usually coincide with thestate fiscal year, so this field will usually be "07".

This fiscal year’s current budget amount for thesubproject/phase. This is the total of all budget transactionsprocessed for this fiscal year.

The total of all outstanding purchase orders submitted againstthe project/subproject/phase for this fiscal year.

The total amount spent against the project/subproject/phase forthis fiscal year (i.e., all payment vouchers and expenditurejournal vouchers).

The total amount of all expenses charged against the



PROJ CHARGES AMT

project/subproject/phase for this fiscal year,(i.e., issued frominventory). This amount will differ from the YTDEXPENDED AMT only if the distinction is made between theexpenditure for an item and when the charge is reclassified asan expense.

Amounts charged to this project/subproject/phase on ProjectCharge (PX) transactions for this fiscal year.

16.7.6 Appropriation by Project (APRP) Table Overview

The Appropriation by Project (APRP) table is used for inquiries on valid appropriation by projectcombinations for project accounting transactions. The table is keyed by agency, appropriation, project,budget fiscal year, fund, and organization. This table is an alternate view of the Project by Appropriation(PAPR) table, which is keyed by agency, project, and appropriation, with the rest of the keys identical.Whenever an addition, deletion, or change is entered on the PAPR table, the Appropriation by Projecttable is automatically updated by the system. Transactions (except the Deposit Suspense (DS), WarrantVoucher (WV), and Non-Payable Invoice (NP) document) which do not have a combination appearingon this table, will reject when they are processed.



16.7.6.1 Appropriation by Project (APRP) Table Screen Print and Field Descriptions

The screen print of the Appropriation by Project (APRP) table is pictured below, and field descriptionsfollow.

Appropriation ByProject Table ACTION: TABLEID: APRP USERID: ........

(APRP) APPROPRIATION BY PROJECT TABLE

KEY IS AGENCY, APPR, PROJECT, BUDGET FISC YEAR, FUND, ORGANIZATION

AGENCY APPR PROJECT BFY FUND ORGN PRIORITY LEGIS ACT------ ---- ------- --- ---- ---- --------- ---------

01- ... .... ..... .. ... .... . ....02- ... .... ..... .. ... .... . ....03- ... .... ..... .. ... .... . ....04- ... .... ..... .. ... .... . ....05- ... .... ..... .. ... .... . ....06- ... .... ..... .. ... .... . ....07- ... .... ..... .. ... .... . ....08- ... .... ..... .. ... .... . ....09- ... .... ..... .. ... .... . ....10- ... .... ..... .. ... .... . ....11- ... .... ..... .. ... .... . ....12- ... .... ..... .. ... .... . ....13- ... .... ..... .. ... .... . ....14- ... .... ..... .. ... .... . ....15- ... .... ..... .. ... .... . ....

The Appropriation by Project (APRP) table field descriptions are as follows.

The Appropriation by Project (APRP) table is used for inquiries on valid coding combinations for projectaccounting transactions. The table is keyed by agency, appropriation, project, budget fiscal year, fund,and appropriation organization. This table is an alternate view of the Project by Appropriation Table(PAPR), which is keyed by agency, project, and appropriation, with the rest of the key identical.Transactions (except the DS, WV, and NP) which do not have a combination appearing on this table willreject when they are processed.

This is a system-maintained table. Whenever an addition, deletion, or change is entered on the PAPRtable, the Appropriation by Project Table is automatically updated by the system.

AGENCY

APPR

PROJECT

Key field. The agency associated with the appropriation unitand project listed in the APPR and PROJECT fields.

Key field. Appropriation unit number for the Means ofFinancing (for the agency listed) that finances the projectnumber listed in the PROJECT field.

Key field. Unique code identifying the project associated with



BFY

FUND

ORGN

PRIORITY

LEGIS ACT

the agency and appropriation unit listed.

Key field. Budget fiscal year of the Means of Financingappropriation associated with the project.

Key field. Capital Outlay fund used by the project.

Organization used by the project, and specified on PAPR, ifany. (Most projects will not use organizations).

Priority specified in the both the Capital Outlay Act andPAPR, if any.

The Legislative Act number associated with the project.



16.7.7 Government-Wide Project Application (GVPR) Table Overview

The Government-wide Project Application (GVPR) table summarizes financial data for all projects thatare defined on the Agency Project (AGPR) table as reportable within this government-wide project. Thekey to the table is government-wide project number. The government-wide project provides a method toaccumulate the financial activity of several projects, administered by the same agencies. The financial dataon this table is updated when GFS accounting transactions or Project Charge (PX) transactions areprocessed that reference an associated project.

16.7.7.1 Government-Wide Project Application (GVPR) Table Screen Print andField Descriptions

The screen print of the Government-wide Project Application (GVPR) table is pictured below, and fielddescriptions follow.

Government-WideProject Inquiry ACTION: . TABLEID: GVPR USERID: ........

Table (GVPR) *** GOVERNMENT-WIDE PROJECT INQUIRY ***

KEY IS GOVERNMENT-WIDE PROJECT NUMBER01-

GOVT-WIDE PROJECT NUMBER: .....DESCRIPTION: ..............................

BOND FUNDED AMT: .............. ENCUMBERED AMT: ..............FEDERAL FUNDS AMT: .............. EXPENDED AMT: ..............

GOVERNMENT FUNDS AMT: .............. EXPENSED AMT: ..............OTHER FUNDS AMT: .............. PROJ CHARGES: ..............

ORIG PROJECT BUD AMT: .............. ACCRUED REV AMT: ..............CURR PROJECT BUD AMT: .............. COLLECTED REV AMT: ..............

02-GOVT-WIDE PROJECT NUMBER: .....

DESCRIPTION: ..............................BOND FUNDED AMT: .............. ENCUMBERED AMT: ..............

FEDERAL FUNDS AMT: .............. EXPENDED AMT: ..............GOVERNMENT FUNDS AMT: .............. EXPENSED AMT: ..............

OTHER FUNDS AMT: .............. PROJ CHARGES: ..............ORIG PROJECT BUD AMT: .............. ACCRUED REV AMT: ..............CURR PROJECT BUD AMT: .............. COLLECTED REV AMT: ..............



The Government-wide Project Application (GVPR) table field descriptions are as follows.

The Government-Wide Project (GVPR) table consolidates estimated revenues and financial activity forall projects that are tied to the same government-wide ("umbrella") project. Individual projects that aretied to a government-wide project may be administered by more than one agency. The table is organizedby government-wide project number.

This is a system-maintained table. Lines are added to this table whenever a Project Master (PJ) transactionidentifies a project as belonging to a particular government-wide project. Lines are modified by theProject Master (PJ) transaction and by expenditure accounting transactions.

GOVT-WIDEPROJECT NUMBER

DESCRIPTION

BOND FUNDEDAMT

FEDERAL FUNDSAMT

GOVERNMENTFUNDS AMT

OTHER FUNDSAMT

ENCUMBERED AMT

EXPENDED AMT

EXPENSED AMT

PROJ CHARGES

Key field. The identifying number that connects a group ofprojects (agency projects) together.

Description of the government-wide project.

Estimated revenue resulting from one or more of the fourpossible types of revenue connected to the project.

The total amount of all encumbrances (i.e. all outstandingpurchase orders) charged to all projects that report to thegovernment-wide project.

The total amount of all expenditures (i.e. all payment vouchersand expenditure journal vouchers) charged to all projects thatreport to the government-wide project.

The total of all expenses (including inventory issues) chargedto all projects that report to the government-wide project. Thisamount will differ from the EXPENDED AMT only if thedistinction is made between the expenditure for an item andwhen the charge is reclassified as an expense.

The total of all project charges made (on PX documents) to allprojects that report to the government-wide project.The original budget amount for all projects in this government-wide project.



ORIG PROJECT BUDAMT

ACCRUED REV AMT

CURR PROJECT BUDAMT

COLLECTED REVAMT

The total of all original project budget amounts (excludingallmodifications made on PJ transactions) for all projects thatreport to the government-wide project.

Will normally be "0.00" unless a journal voucher (JV) hasbeen processed affecting revenues with the JV cash indicatorset to "N". Louisiana will not use invoices for revenues.

The total of all current project budget amounts (including allmodifications made on PJ transactions) for all projects thatreport to the government-wide project.

Total revenues collected by all projects that report to thegovernment-wide project.



16.8 Project Accounting Transactions Overview

This section provides instructions for the initial entry and subsequent modifications of Project Master (PJ)and Project Charge (PX) transactions. For detail instructions on how to access and process GFStransactions, see theGFS Online FeaturesGuide, Chapter 4,Document ProcessingandAppendix A.

Three transactions are used for establishing and modifying project master data and indirect (non-accounting) charges to a project:

· Project Master Transaction (PJ)· Project Charge Transaction (PX)· Non-Payable Invoice Transaction (NP)

The Project Master (PJ) transaction is used to establish a new project and the associated sub-projects andphases in GFS complete with budgetary and descriptive information, or to change the basic informationpertaining to an existing project/sub-project/phase. A project master transaction must be accepted by GFSbefore any accounting transactions that reference that project will be accepted. The following types ofinformation are entered on the Project Master (PJ) transaction:

· Valid project, subproject, and phase codes

· Project descriptive information such as start, end and agreement dates, status,manager

· Project budgets for both the entire project and for each subproject/phase

· A funds edit control option indicating whether funds control outside of thenormal appropriation control and expense budget control will be placed onthe project

· Definition of how the project is to be funded

The Project Master (PJ) transaction results in entries made to the Agency Project (AGPR) table, ProjectBudget Line Inquiry (PRBL) tables, Project Fiscal Year (PFYT) table and, if the project is linked to agovernment-wide project number, the Government-wide Project (GVPR) table.

The overall project budget is established by entering amounts to be received from the various fundingsources such as bonds, federal, state, or local governments. Each subproject/phase has its own budgetedamount. The sum of all subproject/phase budgets within a project cannot exceed the total project budget.

In order to be able to charge or receive funds against a project, the referenced subproject/phase must havea status of "open." As particular phases of a project are completed, the subproject/phase line must beclosed to prevent additional expenditures and receipts from erroneously being recorded. This is done bychanging the status for the line to "C" (closed).



The statuses stored on the PJ transaction will have an important impact on the project purge process.Projects will be archived and deleted from the active tables only if the project status and all thesubproject/phase statuses are "C." If the lines have the status of "C," but the project has a different status(for example "E" "Ended"), then the project purge will not be archived and deleted.

The Project Charge (PX) transaction can be used to record indirect (non-accounting) charges against aproject; for example, an allocated charge for computer usage, or a "per hour" charge for use of aconstruction vehicle. This information is posted to a memo project ledger only and does not enter thefinancial general accounting ledgers maintained in GFS. The PX transaction can be used to record costsassociated with the project, such as local government costs or private participation, which are not paiddirectly by the State.

Two methods are available for entering a charge into GFS on the PX. Both methods may be used on thesame transaction. They are:

· System-Computed Amount - A charge class code is entered from theCharge Class Master Reference (CHRG) table and a quantity in units, suchas number of hours, number of pages, etc. To compute the chargeableamount, the system will infer a dollar rate from the table and multiply therate by the number of units entered on the transaction.

· User-Coded Amount- The exact amount to be charged against the projectis entered directly in the amount column of the transaction. With thismethod, either an object code or a charge class code must also be entered onthe same line.

When Project Charge transactions are accepted by the system, the full charge amount will update theAgency Project Master (AGPR) table, Project Budget Line (PRBL) table, Project Fiscal Year Master(PFYT) table and, if the project is linked to a government-wide project, the Government-wide ProjectMaster (GVPR) table. In addition to updating the above master tables, this transaction also generatesmemo ledger entries for the Detail Project Inception-to-Date Ledger.

Each project charge transaction is identified by a document number and date in addition to the projectnumber. Each line item must be identified by either a charge class code or an object code. All otheraccounting codes are optional.



16.8.1 Project Accounting Transaction Policies

The following policies apply to Project Accounting transactions:

· It will be the responsibility of Project Accounting users at the agencies toenter the Project Master (PJ) transactions to establish valid projects/sub-projects/phases and related data.

· It will be the responsibility of Project Accounting users at the agencies tomaintain and modify the Project Master data, when and if needed.

· It will be the responsibility of Project Accounting users at the agencies todetermine if Project Charge transactions are to be used, and to process thesetransactions when applicable.

· If Project Charge transactions are used, it will be the responsibility of theProject Accounting users at the agencies to ensure the accuracy of the data,and perform any reconciliations that are needed.

The following section defines the project establishment procedures and also includes screen prints of theProject Master (PJ), Project Charge (PX), and Non-Project Charge (NP) transactions. In addition, fielddescriptions for each transaction are included.

16.8.2 Project Establishment Control Agency Procedures


Agency Determines the project code, subproject(s), phases(s), and associated dataneeded to establish the project. The project codes areunique by agency.The phase codes arestatewide and must be valid on the Project Phase(PRPH) table. The Project Phase table is discussed in the "ProjectAccounting User-Maintained Tables" section in this manual. See Section16.6.2.2.

Completes the Project Master (PJ) transaction and processes into GFS.

Facility Planningand Control Maintains the Project Phase (PRPH) and Project Status (PRST) tables in

accordance with policies defined in this manual.



The Project Master (PJ) transaction is also used to modify existing project non-key data. Key information,including agency and project number, must be coded on the transaction to provide the system with themeans for locating the project to be modified. Then, only information to be changed needs to be coded.The modification transaction performs as follows:

· Data fields which are input will overlay existing data.

· Data fields which are left blank will not be changed.

· Data fields coded with an asterisk (*) will result in that field being set tospaces.

16.8.2.1 Agency-Specific Procedures for Project Establishment

16.8.3 Project Master (PJ) Transaction Control Agency Procedures

Procedures and responsibility for entering project modifications using the Project Master (PJ) transactionare as follows.


Agency Determines the changes that are needed and processes any additions ormodifications. The project and agency number and cannot be changed.

Completes the Project Master (PJ) transaction with applicable changes andprocesses into GFS.

16.8.3.1 Agency-Specific Procedures for the Project Master (PJ) Transaction



16.8.3.2 Project Master (PJ) Transactions Screen Print and Field Descriptions

The screen print of the Project Master (PJ) transaction is pictured below, and field descriptions follow.

Project MasterTransaction (PJ) FUNCTION: ............... DOCID: PJ ... ...........

STATUS: BATID: ... ... ...... ORG: ....H- ACTION: . PJ DATE: .. .. .. AGENCY: ... PROJ: .....

PROJECT STATUS: . PROJ MANAGER: ....................START DATE: .. .. .. END DATE: .. .. .. PROJ FISC YR: ..DESCRIPTION: .............................. PROJ FY START: ..FHWA APPR CODE: ... GOV-WIDE PROJ NO: ..... FED ROUTE/SEC: ....FHWA PROJECT NUMBER: .......................

BOND FUNDED AMT: .............. I/D: . PCT: .......FED FUNDS AMT: .............. I/D: . PCT: .......

GOVT FUNDS AMT: .............. I/D: . PCT: .......OTHER FUNDS AMT: .............. I/D: . PCT: .......

TOTAL PROJ BUD AMT: .............. I/D: .

The Project Master (PJ) transaction field descriptions are as follows.

COMMAND AREA

ACTION

PJ DATE

AGENCY

PROJ

PROJECT STATUS

See Chapter 4, "Transaction Processing," in theISIS/GFSOnline Features Guidefor an explanation of the commandarea fields.

Optional. Valid entries are "E" (for original entry) or "M" (tomodify an existing project). If left blank, this field defaults to"E".

Inferred. The current date entered for this document type onthe Dates (DATE) table.

Required. Must be a valid code on the Agency Reference(AGCY) table.

Required. The number assigned to uniquely identify theproject. If a new project, the code must not exist. Ifmodifying an existing project, the code must match theoriginal code.

Required. Entry must be valid on the Project Status (PRST)



PROJ MANAGER

START DATE

END DATE

PROJ FISC YR

DESCRIPTION

PROJ FY STARTPRD

FHWA APPR CODE

GOV-WIDE PROJ NO

FED ROUTE/SEC

FHWA PROJECTNUMBER

table.

Optional. The person managing the project.

Required for the initial load of the project. Enter, inMMDDYY format, the beginning date for the project. Thedate must be valid in the Calendar Date Master Reference(CLDT) table.

Required. Enter in MMDDYY format, the estimated last dayof project activity. Must be greater than the START DATEand must be valid in the Calendar Date Master ReferenceTable.

Required. Enter in YY format, the first state fiscal year forwhich the project was authorized.

Optional. A description of the project. This description willappear on applicable reports.

Required. The calendar month in which the fiscal yearassociated with this project starts. Project years will usuallycoincide with state fiscal years, so this field will usually be"07".

Subsystem. If your installation is not using that subsystem,leave blank. Otherwise, enter the federal appropriationprogram code associated with this project. The code must bevalid in the Federal Aid Highway Appropriation Master(FAPP) table. This field is not being used in Louisiana at thistime.

Optional. The umbrella number which joins a group ofprojects together. Use only when applicable; otherwise, leaveblank.

Optional. Enter the federal route/section numbers, ifapplicable. This field is not being used in Louisiana at thistime.

Optional. Enter the FHWA (Federal Highway) Number, if



Source of Funding:

BOND FUNDED AMTFED FUNDS AMTGOVT FUNDS AMTOTHER FUNDS AMT

I/D

PCT

TOTAL PROJBUD AMT

SUBPROJ

PHASE

STATUS

P/NP

FUNDS EDIT

CE PHASE PCT

AUTH DATE

applicable. This field is not being used in Louisiana at thistime.

Required. One or more of the four types of revenue amountsshould be coded.

Optional on original entry, required on modificationdocuments. The increase (I) or decrease (D) to a prioramount. If left blank, this field will default to "I".

Optional. The percentage each revenue source (bond, federal,government, or other funds) contributes to the project’s totalfunding.

Required. The sum of all budgeted amounts.

Required for a new project. The code identifying a certainportion or all of the project.

Required for a new project. The code further identifying acertain portion of a project.

Required. Must be "O" for open or "C" for closed.

Optional. Leave blank - this field is not being used at thistime. Indicates if this subproject/phase combination isassociated with Project Billing subsystem.

Required. Must be "Y" (Yes) or "N" (No). Indicates editmade when accounting transactions are made against theproject.

Optional. For use with the optional GFS Project BillingSubsystem. If this is a construction engineering phase, enterthe percentage (999999 format with an implied decimal point)of construction engineering (CE) costs that are eligible forreimbursement. Leave blank; this field is not being used inLouisiana at this time.



AGRMT DATE

BUDGET AMOUNT

I/D

JOB NUMBER

DESCRIPTION

Optional. The date when expenditures may be incurredagainst the subproject/phase combination. If left blank, thisfield defaults to the Project Start Date.

Required if GFS Project Billing Subsystem is installed;optional, otherwise. Enter the date when projectreimbursement for expenditures may be obtained. This fieldis not being used in Louisiana at this time.

Required. The amount of this portion of the project. The sumof the budget line amounts must equal the total amount.

Optional on original entry, required on modificationdocuments. The increase (I) or decrease (D) to a prioramount. If left blank, this field will default to "I".

Optional. If your installation is maintaining the optional GFSJob Cost Accounting Subsystem and there is a job numberassociated with this project/subproject/phase, enter the jobnumber. Leave blank; this field is not being used in Louisianaat this time.

Optional. A brief description of the sub-project/phase.



Screen 2 of the Project Master (PJ2) transaction is pictured below, and field descriptions follow.

FUNCTION: DOCID: PJ ... ...........STATUS: BATID: ORG:

000-000 OF 000FUNDS CE AUTH AGRMT

BUDGET SUBPROJ PHASE STATUS P/NP EDIT PHASE PCT DATEDATE AMOUNT I/D

------- ----- ------ ---- ----- --------- -------- -------- -------------- ---

JOB NUMBERDESCRIPTION ---------- ------------------------------

The field descriptions for Screen 2 of the Project Master (PJ2) transaction are as follows.


SUBPROJECT Required. Enter a valid code for a newproject. This code identifies a certain portionor all of the project.

PHASE Required. Enter the code that identifieswhere the transaction originated. Validvalues are:

0 - CFMS; 1 - GFS;2 - AGPS;3 - Unauthorized or Unobligated.

STATUS Required. Enter "O" for open. Otherwise,enter "C" for closed.

PARTICIPATION/NON-PARTICIPATION (P/NP)

Optional. If Project Billing (Job Cost) isused, enter "P" if this subproject/phase combination is associated with projectactivity participating in an expenditurereimbursement process. Enter "N" ifassociated costs are not eligible forparticipation in a reimbursement process. TheState is not using this option.




FUNDS EDIT Required. Enter "Y" (Yes) if edits are madewhen accounting transactions are madeagainst the project. Otherwise, enter "N"(No).

CE PHASE PERCENT Optional. This field is used with the ProjectBilling subsystem. If this is a constructionphase, enter the percentage (9999999 formatwith an implied decimal point) ofconstruction engineering (CE) costs that areeligible for reimbursement. Leave this fieldblank if this is not a construction phase, or ifthe Project Billing subsystem is not used.

AUTHORIZATION DATE Required. Enter the date when expendituresmay be incurred against the subproject/phasecombination.

AGREEMENT DATE Required (if the Project Billing subsystem isinstalled). Otherwise, optional. Enter thedate when project reimbursement forexpenditures may be obtained.

BUDGET AMOUNT Required. Enter the amount of this portion ofthe project. The sum of the budget lineamounts must equal the total amount.

INCREASE/DECREASE(I/D)

Required. Enter "I " to increase to a prioramount. Enter "D" to decrease to a prioramount. If this field is left blank, the systemdefaults to "I ."

JOB NUMBER Optional. If the Job Cost Accountingsubsystem is maintained and there is a jobnumber associated with this project/subproject/phase line, enter the appropriatejob number. Otherwise, leave this fieldblank.

DESCRIPTION Optional. Enter a brief description of thesubproject phase or any other additionalinformation applicable to this subproject.



16.8.4 Project Charge (PX) Transaction Control Agency Procedures

Procedures and responsibility for entering and reconciliation of charges to projects using the ProjectCharge (PX) transaction are as follows.


Agency Determines whether project charges are to be made to a project and the chargemethods to be used.

Completes the Project Charge (PX) transaction and processes into GFS.

NOTE: When the Project Charge (PX) transaction is used, agencies areresponsible for ensuring that the entry is correct and for reconciling the balances.

16.8.4.1 Agency-Specific Procedures for the Project Charge (PX) Transaction

16.8.4.2 Project Charge (PX) Transaction Screen Print and Field Descriptions

The screen print of the Project Charge (PX) transaction is pictured below, and field descriptions follow.

Project ChargesTransaction FUNCTION: ............... DOCID: PX ... ...........

(PX) STATUS: BATID: ... ... ...... ORG: ....

PROJECT CHARGES INPUT FORMH- DATE: .. .. .. ACCTG PRD: .. ..

UNITS TOTAL: ....... DOCUMENT TOTAL: ..............

AG SUB SUB SU P CHG CHGFY FND CY ORGN ORG ACTV OBJ OBJ PROJ PJ H CLS UNITS-- --- --- ----------- ---- -------- ----- -- - --- -------

AMOUNT I/D---------------- ---

01- .. ... ... .... .. .... .... .. ..... .. . ... ..................... .

02- .. ... ... .... .. .... .... .. ..... .. . ... ..................... .

03- .. ... ... .... .. .... .... .. ..... .. . ... ..................... .

04- .. ... ... .... .. .... .... .. ..... .. . ... ..................... .

05- .. ... ... .... .. .... .... .. ..... .. . ... ..................... .



The Project Charge (PX) transaction field descriptions are as follows.

COMMAND AREA

PX DATE

ACCTG PERIOD

UNITS TOTAL

DOCUMENT TOTAL

FY

FND

AGCY

ORGN

SUB-ORG

ACTV


Inferred. The current date entered for this document type onthe Dates (DATE) table.

Optional. If blank, the accounting period defaults to theaccounting period associated with the charge date (in theCLDT table). Enter, using MMYY format, only if you wishto change this transaction to a different open period.

Required if units are entered on the transaction. If left blank,defaults to zero. Must equal the net sum of all units enteredon the transaction (i.e., sum of increases and decreases). Mustenter decimal point

in up to seven digits (99999.99) or system will assume twodecimal places.

Required if amounts are entered on the transaction. If leftblank, defaults to zero. Must equal the net sum of all dollaramounts entered on the transaction (i.e., sum of increases anddecreases). Must enter decimal point up to seven digits(99999.99) or system will assume two decimal places.

Optional. The budget fiscal year that the charge is to berecorded against in YY format. If blank, the fiscal yeardefaults to the fiscal year associated with charge date (in theCalendar Date (CLDT) table).

Required. Must exist on Fund Reference (FUND) table.

Required. Must exist on the Agency Reference (AGCY) tableand the fund/agency combination must be valid in theFund/Agency Reference (FAGY) table.



Optional. If entered, it must exist on the Activity Reference



OBJ

SUB-OBJ

PROJ

SU PJ

PH

CHG CLSCHG UNITS

AMOUNT

I/D

(ACTV) table. This field is not being used in Louisiana atthis time.

Optional. If used, the code must exist on the ObjectReference (OBJT) table.

Optional if object is entered; otherwise, must be blank.

Required. The five character project number to whichproject charges are being entered.

Required. A two-digit subproject number associated withthe above project number.

Required. A one-character phase code that exists on theProject Phase (PRPH) table as part of an eight-characterproject/subproject/phase number.

Optional. Enter a valid charge class code from the ChargeClass Master (CHRG) table in conjunction with charge units(CHG UNITS) if the project charge is to be systemcomputed rather than entered directly in the AMOUNTfield. Required if charge class is entered; otherwise,optional. Enter up to seven digits including two decimalplaces (99999.99).

Decimal point is required or system will assume two places.Leading zeros are not required.

Required if charge class (CHG CLS) and charge units (CHGUNITS) are not entered. Enter the amount that is to becharged to the project. A decimal point must be entered;otherwise the system will assume the last two digits to becents.

Required if unit or amount fields are to be decreased. If notentered, defaults to "I" (increase). Enter "I" for increase or"D" for decrease. Applies to both entered and computedamounts.



16.8.5 Non-Payable Invoice (NP) Transaction Overview

The Non-Payable Invoice (NP) transaction will be used to record charges against non-payable projects.The NP transaction will update the expenditure amount on the Agency Project (AGPR) table, ProjectBudget Line (PRBL) table, Project Fiscal Year (PFYT) table and, if the non-payable project is linkedto a government-wide number, the Government-wide Project (GVPR) table. In addition, the NPtransaction will update the Non-Payable Project Invoice (NPPI) table with all relevant information.The NP transaction will be edited to ensure the overall project status is "Non-Payable," the transactionis within the project start and end dates, the sub-project/phase has a status of "O" (Open), and thatsufficient budget exists to process the transaction. As with the PX transaction, the NP transaction willnot post to the General Ledger or update any budgetary tables.

16.8.5.1 Non-Payable Invoice (NP) Transaction Policies

To be determined.

16.8.5.2 Non-Payable Invoice (NP) Transaction Procedures



16.8.5.3 Non-Payable Invoice (NP) Transaction Screen Print and FieldDescriptions

The screen print of the Non-Payable Invoice (NP) transaction is pictured below, and field descriptionsfollow.

Non-PayableInvoice Input FUNCTION: ............... DOCID: NP ... ...........

Form (NP) STATUS: BATID: ... ... ...... ORG: ....

H- NON-PAYABLE INVOICE INPUT FORM

NP DATE: .. .. .. ACCTG PRD: .. .. BUDGET FY: ..AGENCY: ... PROJ: ..... SUB-PROJ: .. PHASE: .

DOC TOTAL: .............. CALC DOC TOTAL: ...............

ACT INV NUMBER INV DATE PO/RQ NUMBER REC FPC REC FISC FWD DATE--- -------------- -------- -------------- -------- --------- ---------

FPC PROJ NUMBER VENDOR NAME AMOUNT I-D------------------- ------------------------------ -------------- ---COMMENTS----------------------------------------------------------------

01- . .............. .. .. .. .............. .. .. .. .. .. .. .. .. .................... ................................ ............. .................................................................................................................................

02- . .............. .. .. .. .............. .. .. .. .. .. .. .. .. .................... ................................ ............... .................................................................................................................................

The field descriptions for the Non-Payable Invoice (NP) transaction are as follows.

COMMAND AREA

NP DATE

ACCTG PERIOD

BUDGET FY


Inferred. The current date entered for this document type onthe Dates table (DATE).

Optional. If blank, the accounting period defaults to theaccounting period associated with the charge date (in theCLDT table). Enter, using MMYY format, only if you wish tochange this transaction to a different open period.

Optional. If left blank, defaults to current budget fiscal year.A prior year can only be entered during the 13th accountingperiod, and only if the invoice(s) being entered apply to theimmediate previous fiscal year. Must be valid on the FiscalYear Table (FSYR).



AGENCY

PROJ

SUB-PROJ

PHASE

DOC TOTAL

CALC DOC TOTAL

ACT

INV NUMBER

INV DATE

PO/RQ NUMBER

Required. The valid agency code for the agency responsiblefor the Non-Payable Invoice (NP) transaction. The agencycode must exist on the Agency Reference (AGCY) Table.

Required. The project code for which the invoice is entered.For an NP transaction to be recorded, the status of the projecton the Agency Project Inquiry Table (AGPR) must be "N"(Non-Payable project).

Required. A 2-digit subproject number associated with theabove project number.

Required. A one-character phase code that exists on the ProjectPhase (PRPH) Table. Must be associated with the aboveproject/subproject combination.

Required. The net sum of all dollar amounts entered on thetransaction (i.e., sum of increases and decreases).

Calculated. The system-computed net sum of all dollaramounts entered on the transaction (i.e., sum of increases anddecreases).

Optional. Action for the line entry. Valid entries are "A"(Add) and "C" (Change). If left blank, defaults to "A". The"A" action may be used to add new invoices and to add creditmemos. When adding credit memos, the ACT field must be"A" and the I-D field must be "D" - to indicate the amountentered is to be processed as an invoice credit. The "C" actionmay be used to change most of the data fields previouslyentered, except for invoice number. When a change action isprocessed for the AMOUNT, an "I " or "D" must be entered inthe I-D field.

Required. The invoice number to be recorded on the NPdocument. May be up to 14 characters.

Required. The date on which the invoice was created. Mustbe a valid date, in MM DD YY format.

Optional. The Purchase Order or Requisition documentnumber referenced by the invoice.

Optional. The date the invoice was received by the Office of



REC FPC

REC FISC

FWD DATE

FPC PROJNUMBER

VENDOR NAME

AMOUNT

I-D

COMMENTS

Facility Planning and Control. Must be a valid date, in MMDD YY format.

Optional. The date the invoice was received by FacilityPlaning and Control’s fiscal office. Must be a valid date, inMM DD YY format.

The date the invoice was forwarded to the appropriate officefor payment. Must be a valid date, in MM DD YY format.

Optional. 17 character (maximum) number assigned by Officeof Facility Planning and Control to further identify a project.

Optional. The name of the vendor submitting the invoice.

Required. The amount of the invoice.

Required if Amount field is to be decreased. If left blank, thisfield will default to "I" (Increase). Enter "I" for increase or"D" for decrease. Applies to both entered and computedamounts.

Optional. Unrestricted field for the entry of comments on therecorded invoice.



16.9 Project Purge/Archive Process Overview

Projects that are closed will remain on Project Accounting system tables until they are removed with thePurge/Archive process. If selected by this process, a project is written to an archive file, deleted from theAgency Project Master (AGPR) table, Agency Project Description (AGP2) table, and Project Budget Line(PRBL) table, and a record is written to the process report. There is also the option to produce only thereport, without purging/archiving any records.

Projects are selected to purge with the following criteria:

· A single agency may be selected for this process, or projects may be purgedfor all agencies.

· Projects will be archived and deleted from the tables only if the project statusand all subproject/phase statuses are set to "C." If the lines have the status of"C," but the project has a different status (for example, "E" - "Ended"), thenthe project will not be archived and deleted.



16.10 Capital Outlay Project Close-Out Process Overview

Agencies with capital outlay projects will initiate the steps to close out capital outlay projects which willnot have any further activity.

16.10.1 Capital Outlay Project Close-Out Process Control Agency Procedures

Procedures and responsibility for closing out capital outlay projects in GFS are as follows. Proceduresmay vary slightly, depending on the type of monies appropriated to the capital outlay project (e.g., Self-Generated, Interagency Transfer (IAT), FEDA, etc.). These procedures are also defined for each possiblefunding situation in this section.

For All Funding Situations:


Agency Prepares and completes Capital Outlay Project Close-Out Report form andsubmits it to the State Treasurer’s Office.

Enters PJ document with "M " (Modify) action and changes sub-project/phasestatus to "C" (Closed) and overall project status to "E" (Ended).

State Treasurer’sOffice Receives completed Capital Outlay Project Close-Out Report form from the

appropriate agency and reviews for completeness.

Reviews the Appropriation Master Inquiry (APPR) table for the appropriateMeans-of-Financing appropriations for cash available and budget in theMeans-of-Financing Appropriation.

Prints the Appropriation Master Inquiry (APPR) table screen (screen print) andattaches screen print to the Capital Outlay Project Close-Out Report form.This action will verify the cash available and budget in the Means-of-Financing appropriation.

If money is re-appropriated for new projects, then the agency will establisha new Means-of-Financing for re-appropriated programs. STO will preparetransfer adjustment (JV or J1) to move cash to the new appropriation(s).

If money is notre-appropriated for new project, the STO prepares a JournalVoucher (JV or J1) to move cash to its source of funding.



Notifies agencies that funds have been moved and the Office of FacilityPlanning so that the appropriation can be deactivated.

Facility Planning De-activates the original (old) appropriation through BDS.

Other Procedures:

In all of the steps and situations defined below:

State Treasurer’sOffice Forwards a memo to the Office of Facility Planning & Control to

deactivate the appropriation.

Files the Capital Outlay Project Close-Out Report form and copies of theJournal Voucher and other related documents in a folder entitled, " ProjectClose-Outs."

The following steps are broken down into separate procedures for various funding situations to befollowed depending on the type of monies appropriated to the Capital Outlay Project (General Fund, Self-Generated, Interagency Transfer, FEDA, etc.).

For Alternate Funding Situations:

Situation 1: General Fund Means-Of-Financing Balance Reverting Back to the General Fund.


Agency Enters a Project master (PJ) transaction with a "M" (Modify) action andchanges all sub-project/phases of "C" (closed) and the overall project status to"E" (Ended).

Completes Capital Outlay Project Close Out form and submits to the StateTreasurer’s Office.

State Treasurer’sOffice Receives completed Capital Outlay Project Close Out form.

Reviews the APPR table for the appropriate Means of Financingappropriation and verifies the remaining budget amount.

Prepares a Journal Voucher (JV) to transfer the cash from the Capital



Outlay fund to the general fund (remaining budget from APPR table).

The accounting entries are as follows for 148:

FUND AGENCY ORG APPR UNIT OBJ/RSRC/B/S ACCT PROJECT DR CR

000 148 7125 T91 T100 xxx

000 148 6005 xxx

The accounting entries are as follows for Capital Outlay assuming fund 075:

FUND AGENCY ORG APPR UNIT

OBJ/RSRC/B/S ACCT PROJECT DR CR

BANKCODE

075 115 t110 12345RRR xx

075 115 6000 xx 03

NOTE: Since the budget year is in the header of the journal voucher, if thecash is being transferred from a prior budget year to the current budgetyear, two JV’s will have to be prepared.

Forward a memo to the Office of Facility Planning indicating that themonies have been transferred and that the MOF appropriations should bedeactivated.

Facility Planning Deactivates the appropriation(s) through the BDS system.

Situation 2: Non-General Fund Means-Of-Financing Appropriation Remaining Monies Revertingto the General Fund (Self-Generated, Interagency Transfer, etc.)


Agency Enters a Project master (PJ) transaction with a "M" (Modify) action andchanges all sub-project/phases to "C" (closed and the overall project status to"E" (Ended).

Completes the Capital Outlay Project Close Out form and submits to theState Treasurer’s Office.




Reviews the APPR table for the appropriate Means of Financingappropriation and verifies the remaining cash (actual collected lessexpended).

Prepares a Journal Voucher (J1) to transfer the cash from the CapitalOutlay fund and decrease the actual collected in the appropriation to theamount expended.


FUND AGENCY ORG APPR UNITOBJ/RSRC/

B/S ACCT PROJECT DR CR

000 148 7125 T91 T100 XXX

000 148 6005 XXX

The accounting entries are as follows for Capital Outlay assuming fund 075 agency 115:

FUND AGENCY ORG APPR UNITOBJ/RSRC

/B/S ACCT PROJECT DR CRBANKCODE

075 115 xxx* t100 12345RRR xx

075 115 6000 xx 03

* The appropriation unit indicated on the Close Out form should be used.

Forwards a memo to the Office of Facility Planning indicating that themonies have been transferred and that the MOF appropriations should bedeactivated.

OSRAP Approves the J1 in GFS.




Situation 3: Non-General Fund Means-of-Financing Appropriation Remaining Monies Revertingto Other Funds (Other than General Fund). If federal funds or bond monies, see Situation Number4 and Situation Number 5.


Agency Enters a Project master (PJ) transaction with a "M" (Modify) action andchanges all sub-project/phases to "C" (closed) and the overall project status to"E" (Ended).




Prepares a Journal Voucher (JV) to transfer the cash from the CapitalOutlay fund and decrease the actual collected in the appropriation to theamount expended.

The accounting entries for 148 will be determined on a case by case basis.




075 115 xxx* t100 12345RRR xx

075 115 6000 xx 03


Forwards a memo to the Office of Facility Planning indicating that themonies have been transferred and that the MOF appropriations should beactivated.





Situation 4: Capital Outlay Projects Funded with Federal Funds.



Prepares a Journal Voucher (J1) to transfer the cash from the CapitalOutlay fund and to decrease the actual collected in the appropriation to theamount expended. The cash should be returned to the agency from whichthe federal funds were obtained.




075 115 xxx* T100 orT130

12345RRR xx

075 115 6000 xx 03

* The appropriation unit which is being closed should be used.

Completes Capital Outlay Project Close out form and submits to the StateTreasurer’s Office.


State Treasurer’sOffice Receives a completed Capital Outlay Project Close Out form.

Reviews the APPR table for the appropriate Means of Financingappropriation and verifies the remaining cash equals $0.00 (actual collectedless expended).





Situation 5: Capital Outlay Projects Funded with Bond Monies.






Prepares Appropriation Transaction (AP) to establish one Means ofFinancing appropriation number (T appropriation) using the same bondseries number that is on the MOF being closed out. This step is notnecessary if an MOF has already been established with the specific bondseries number.

Prepares a Journal Voucher (J1) to reclassify the cash from the CapitalOutlay appropriation being closed by decreasing the actual collected in theappropriation to the amount expended and increasing the actual collectedin the "T" appropriation.


FUND AGENCY ORG APPR UNITRSRC/B/S ACCT PROJECT DR CR

BANKCODE

xxx 148 txx 1855 xx

xxx 148 6000 xx 03

NOTE: Organizations are not used in the Capital Outlay funds.





BANKCODE

xxx 148 txx 1855 xx

xxx 148 6000 xx 03

NOTE: Organizations are not used in the Capital Outlay funds.



BANKCODE

075 115 xxx* 1855 12345RRR xx

075 115 6000 xx 03







Situation 6: Monies Remaining in Means-of-Financing From Allocation of Interest Earnings AreTo Be Transferred to Bond Security and Redemption Fund.




State Treasurer’sOffice Receives completed Capital Outlay Project Close out form.

Reviews the APPR table from the appropriate Means of Financingappropriation and verifies the remaining revenue amount (actual collectedless expended).

Prepares a Journal Voucher (J1) to transfer the cash from the CapitalOutlay fund and decrease the actual collected in the appropriation to theamount expended.


FUND AGENCY ORG APPR UNITOBJ/RSRC/

B/S ACCT PROJECT DR CR

B15 148 7504 XA3 T100 XXX

B15 148 6B15 XXX




075 115 xxx* T110 12345RRR xx

075 115 6000 xx 03


Forwards a memo to the Office of Facility Planning indicating that themonies have been transferred and that the MOF appropriations should be



deactivated.





ThisThis pagepage isis leftleft blankblank intentionally.intentionally.


PROJECT ACCOUNTING - Louisiana ppm/pm-ch16.pdfeach project. Project Accounting provides the capability to reject spending transactions which exceed budgeted project amounts.

Documents