PA - Consistent Journal Entry for Projects-Grants Management

8/8/2019 PA - Consistent Journal Entry for Projects-Grants Management

1/26

Copyright @ 2000 by Joyce Lush

Consistent Journal Entry for Projects/Grants Management

and General Ledger

Joyce LushYale University

Fred GerbinoYale University

Frances DykstraYale University

Table of Contents

1. ABSTRACT: ....................................................................................................................................... 12. EXECUTIVE SUMMARY:..................................................................................................................... 1

3. YALES ENVIRONMENT ..................................................................................................................... 2Applications ..................................................................................................................................... 2Transaction Volume ......................................................................................................................... 2

Chart of Accounts............................................................................................................................. 2

4. REQUIREMENTS FOR TRANSACTION ENTRY ...................................................................................... 45. GL AND PA/GA STANDARD ORACLE FUNCTIONALITY .................................................................... 4

GL Functionality .............................................................................................................................. 4

PA Functionality .............................................................................................................................. 5

Gaps ................................................................................................................................................. 5

6. SOLUTION ......................................................................................................................................... 6Disadvantages.................................................................................................................................. 6

7. PROCESS FLOWS ............................................................................................................................... 7

Process Flow Import Batch or Spreadsheet File .......................................................................... 7Process Flow Transaction Correction, Manual Entry and Approval ........................................... 7

Process Flow Transfer to Operational Set of Books ..................................................................... 8

8. GL SETUP FOR STAGING AREA SET OF BOOKS ................................................................................. 89. CUSTOM PROGRAMS AND TABLES SUMMARY ............................................................................. 1010. REMAINING PROBLEMS................................................................................................................... 1311. REMAINING OPPORTUNITIES ........................................................................................................... 1312. CUSTOM PROGRAMS AND TABLES DETAIL .................................................................................. 14

Registration Table and supporting functionality............................................................................ 14

Yale Authorization System (YAS) ................................................................................................... 14

Validation Extension ...................................................................................................................... 14

Import Batch and Spreadsheet Files .............................................................................................. 15

On-line Transaction Correction..................................................................................................... 18Manually Entered Transactions..................................................................................................... 21

Transaction Approval..................................................................................................................... 21

Transfer to the Operational Set of Books....................................................................................... 21

Yale Reports ................................................................................................................................... 22

Spreadsheet Templates................................................................................................................... 22

13. APPENDICES.................................................................................................................................... 23Yale Registration Table Layout...................................................................................................... 23

Yale JSA Table Layout ................................................................................................................... 23


2/26

Consistent Journal Entry for Projects/Grants

Management and General Ledger

8/16/00

1.Abstract:Using straightforward extensions to the General Ledger, Yale University created a single-entry

point for financial transactions for both Oracle Projects and General Ledger. This entry-pointsupports manual, spreadsheet, and data file modes of input and provides distributed access,transaction validation and department authorization.

2.Executive Summary:Yale University uses Oracle Projects for all expense transactions, but posts balance sheet andrevenue transactions directly to the General Ledger. Transactions are originated by over 300distributed departments, using a mixture of automated feeds, spreadsheets, and manual entry.From a training and usability perspective, it was essential to Yales implementation that journalentries, regardless of their destination, be input, validated, corrected and authorized using a singleentry point.

Yales requirements include consistent entry of charging instructions, distributed and flexiblemode of entry, distributed correction of validation errors, limiting department access to their owntransactions, and central control of the official set of books. For Oracle Projects, additionalrequirements include transaction transfer between Expenditure Types and ExpenditureOrganizations and the ability to input two-sided entries. For General Ledger, additionalrequirements include enforcement of Yale validation rules.

This paper describes Yales Journal Staging Area (JSA) application, which provides a singleentry and correction point for all journals. JSA consists of creative Oracle General Ledger setupsupplemented by standard technical extensions of the application. The presentation coversfunctionality and a high-level overview of the technical approach. Technical details are found in

the paper.JSA is an extension of the Oracle General Ledger. A separate set of books (the JSA set ofbooks) was created to support transaction entry. Segments in the JSA set of books were defined tosupport both Yales GL account structure and Oracle Projects Project/Task/ExpenditureType/Organization. GL Journal Categories were used to provide a framework for Yale validationand processing. For example, some Categories are Projects-only, some are GL-only, and someresult in transactions to both applications. The GL Journal Entry Form was extended using theCustom Library and a separate set of Responsibilities. For the JSA responsibilities, the set ofbooks is limited to the JSA set of books; the contents of the Segment LOVs are determined by theCategory; and Yale validation rules are enforced. Transactions can be manually entered into theform. Data files and spreadsheets are validated and then loaded into JSA via the GL Interface filefor distributed error correction and authorization. Authorization functionality is supported bythe posting button the button is renamed to Authorize; all transactions in the batch must bevalid; and the result of authorization is posting to the JSA set of books in the General Ledger. Acentrally controlled concurrent request extracts authorized batches from the JSA set of books,reformats them, and interfaces them to the destination applications interface file (Oracle Projectsand/or General Ledger).

This extension successfully supports distributed Journal Entry regardless of destinationapplication, while enforcing Yale business rules and maintaining central control over the officialaccounting records.


3/26



8/16/00

3.Yales EnvironmentApplicationsJSA was developed for a 10.7 Smart Client environment. Yale is currently upgrading to 11i.Oracle Applications used are General Ledger (GL), Oracle Projects (PA), Accounts Payables,Purchasing, Human Resources, Payroll, Fixed Assets, Labor Distribution, and Grants Accounting(GA). Labor Distribution is a module that transfers transactions from Payroll to OracleProjects/Grants Management. Grants Accounting is essentially an extension of Oracle Projects tomeet specific requirements of Higher Education.

For the purposes of this paper, Oracle Projects and Grants Accounting are synonymous. AlthoughYale is using Grants Accounting, all of the concepts and techniques of this paper apply equally toan Oracle Projects implementation. Grants Accounting adds the concept of Award to thecharging instruction along with Oracle Projects Project, Task, Expenditure Type and

Expenditure Organization, Grants Accounting uses Award on every transaction. GrantsAccounting adds other functionality that is not pertinent to this topic.

Transaction Volume

Transaction Type Number per

Month

JSA GL Transactions 100,000

JSA PA/GA Transactions 50,000

AP Invoice Distribution Lines 75,000

Labor Transactions 50,000

Other GL 190,000

Other PA/GA 10,000

Chart of Accounts


4/26



8/16/00

Yales General Ledger chart of accounts is:

Segment Value Set

BalancingSegment

Independent manually input

Project Oracle Projects Projects table

Source Independent manually input

Object Code Independent manually input

Organization Independent Yale extension used tomanually input Organizations and toconsistently update both GL and HROrganizations.

Yales Oracle Projects / Grants Accounting chart of accounts is:

Segment Source of Values Relationship

to GL

Segment

Project Oracle ProjectsProjects Table manually input

Same as ProjectSegment

Task Oracle Projects Task Table manually input

None

Award Grants AccountingAward Table manuallyinput

Rolls up into Source

Expenditure Type Oracle ProjectsExpenditure Type Table manually input

Rolls up into ObjectCode

Expenditure

Organization

HR Organization Table

manually input usingYale extension tosynchronize HR and GLvalues

One-to-one relationship

between leaf-level HROrganization and GLOrganization. GLOrganization Numberstored in HROrganization Table andappended to HROrganization Name


5/26



8/16/00

4.Requirements for Transaction EntryJSA handles only transactions headed for the GL or PA/GA applications. GL transactions are

called Journals and are used at Yale for asset, liability and revenue transactions. PA/GAtransactions are called Expenditure Items and are used at Yale for expenses and some balancesheet transactions. At Yale, JSA is NOT used for AP Invoices, adjustments to AP Invoices thatinvolve vendor payments, or for detail-level Labor adjustments. JSA IS used for corrections tocharging instructions for AP Invoices and for some high-level Labor transfers.

Requirements:

Support distributed entry of transactions into an on-line form, into a specifically formattedspreadsheet, or via a batch interface from an external system.

Validate transactions on entry. Provide feedback to the originating user.

Enforce both standard Oracle and Yale validation rules. Yale validation rules vary with typeof transaction.

The originating user is responsible for correcting invalid transactions.

Provide a distributed access to an on-line correction form. Limit access to transactions thatare associated with the user.

Require approval for all transactions. This approval means that a responsible person hasstated that the transactions are correct and appropriate. Limit access to approval functionality.

Provide central control of posting to applications.

Consistent look-and-feel of on-line forms. Over 300 people originate transactions. Need to

minimize training and confusion. For Internal Service Providers (ISPs), support two-sided entries. One side is the expense

transaction; the second side is the credit to the ISPs recovery (internal revenue) account.

Enter negative transactions that are not limited to reversals of specific original transactions.

Enter mass adjustments, each of which represents many original transactions.

Enter adjustments for any segment value.

Additional data attributes definition varies with type of transaction.

Reporting requirements for distributed users.

Short timeframe for development. Up and running in 6 months.

5.GL and PA/GA Standard Oracle FunctionalityBoth GL and PA have built-in functionality to address transaction entry and adjustment. Yalefound significant gaps between our requirements and the standard Oracle functionality. Many ofthese gaps have been narrowed by new Release 11/11I functionality, but significant gaps stillremain.

GL Functionality

GL Interface Table for support of batch entry

On-line form for Journal Entry and Update


6/26



8/16/00

Cross-validation rules

Value-based security available at Responsibility level

Desktop Integrator (GLDI at the time) for input of journals into a spreadsheet

PA Functionality

PA Interface Table for support of batch entry

On-line form for entry of Pre-approved Expenditure Items

On-line form for transfers and splits of original Expenditure Items, limited to Project, Taskand Award

Enforcement of validation rules, including Yale validation rules

Gaps Three separate on-line Forms. All have different look-and-feel.

PA lacks on-line Form for maintenance of Interface Table. (Available in 11.)

PA adjustments limited to Project, Task and Award (no Expenditure Type or Organization).

PA adjustments done at original line level. No mass adjustment capability. (Improved in 11.)

PA on-line Form for transaction entry does not support input of negative amounts. (Availablein 11.)

PA functionality for ISP credits requires too much setup and maintenance of data.

PA security requires too much setup and maintenance of data.

GL security requires too much setup and maintenance of data.

Two different security designs add complexity.

No GL support for complex validation rules that cant be implemented using cross-validationrules.

Neither GL nor PA support approval concept.

Did not want distributed users posting directly to Operational set of books.

Desktop Integrator (GLDI) not enforcing Yale validation rules; format of spreadsheet does

not meet requirements.


7/26



8/16/00

6.SolutionYale needed:

A single batch file and spreadsheet layout that supported all of the required GL and PA/GAtransactions.

A single transaction validation routine.

A single distributed on-line Form for entry of new transactions, correction of invalidtransactions, and approval of batches. Form had to limit access to batches associated with theuser, and limit access to the approval function.

A centrally run process to interface approved batches to GL and PA/GA.

All up and running in 6 months.

To accomplish all of the above within the 6 month timeframe, Yale had to leverage existingfunctionality. Oracles GL application came the closest to providing the needed functionality.The GL Journal Entry form supported all of the necessary types of transactions (e.g., allows massadjustment of original transactions) and was suitable for distributed use. All Yale had to do was toadd support for PA/GA transactions, security, approval functionality, expanded validation rules,loading of batch files and spreadsheets into the GL Interface Table, and interfacing of approvedtransactions to the GL Operational set of books and to PA/GA!

Yale accomplished this with creative GL setup, use of the custom library to modify the behaviorof the GL Journal Entry and GL Posting Forms, and custom concurrent programs to handleloading data into Interface Tables.

DisadvantagesThe JSA design omits functionality that is found in the standard Oracle GL and PA/GA process.This functionality was not of value to Yale. Lost functionality includes:

1. Correction and adjustment JSA transactions do not tie back to the original transaction,unless their originator manually inputs information about the original transaction. It isvery difficult to reliably report the impact on the original transaction.

2. JSA users can create negative account balances, by transferring more costs than wereoriginally charged.


8/26



8/16/00

7.Process FlowsProcess Flow Import Batch or Spreadsheet File

Process Flow Transaction Correction, Manual Entry and Approval

Batch

File

Import Batch or Spreadsheet FileSource

SystemUnix

Directory

Oracle

Applications

JSA

Staging

Tables

GL

Headers,

Batches,

Lines

GL

Interface

Table

Results

Report

E-Mail

Message

Batch

File

Validation

Bold - visible to Distributed User

Dashed - Native Functionality

Transaction Correction, Manual

Entry and ApprovalOracle Applications

GLHeaders,

Batches,

Lines



Entry and

Correction

Approval

GL Journal

Entry Form

Custom.pll

PostedGL Journal

Entry Form

Custom.pll


9/26



8/16/00

Process Flow Transfer to Operational Set of Books

8.GL Setup for Staging Area Set of BooksA central concept is the establishment of a separate set of books for JSA. Although the GL is usedas a vehicle for implementing JSA, JSA is completely separate from the GL Operational set ofbooks.

Setup:

Journal Staging Area set of books

JSA Journal Categories. Yale validation rules and processing are defined at the Categorylevel. Some categories are used for transactions headed to GL; other categories are used fortransactions headed to PA/GA.

Two new responsibilities YUGL Staging User and YUGL Staging Manager. Only theYUGL Staging Manager can approve batches.

A naming convention for JSA Batches. The Batch Name contains a 6-digit OrganizationNumber, a Source System Name, Batch Date, and Batch Sequence Number. TheOrganization Number in the Batch Name is used to control access to the batch. The SourceSystem Name is used to identify the business unit submitting the batch. The Batch Date is thedate on which the batch is submitted. The Batch Sequence Number is used to uniquelyidentify each batch.

Transfer to Operational Set ofBooks

Oracle Applications

GL

Headers,

Batches,

Lines

GL

Interface

Table



PAInterface

Table

Reformat

Data

GL

Categories

PA/GA

Categories

Approved JSABatches


10/26



8/16/00

GL Segments and value sets for JSA set of books. Segments combine GL Operational Set ofBooks Value Sets with PA/GA PTAEO values. Views are used to combine values.

Segment Source of Data

BalancingSegment

GL Balancing Segments - 00 value used for PA/GA transactions.

Project PA Projects Table. (Same as Operational set of books.) Leadingzeros added to sequential Project Number. Exclude Templates, closedProjects, and GA Award Projects.

Task PA Projects Task Table 00000000 value used for GL transactions.Dependent upon Project Segment. Task must be chargeable.

Source/Award Union of GL Sources and PA/GA Awards. PA/GA Awards must be

Active and Funded (GA concepts).

Object Code /Expenditure Type

Union of GL Object Codes and PA/GA Expenditure Types. PA/GAExpenditure Types limited to System Linkage of USAGES orSTRAIGHT-TIME LABOR.

Organization GL Organization. HR Organizations (used for PA/GA transactions)can be referenced by GL Organization Number. Must be a leaf-levelOrg.

Use of Suspense account turned on, so that invalid transactions are not left behind on import.

Descriptive FlexField definition. One DFF defined as context sensitive on Journal Category,

so that each Journal Category has its own DFF definition. The Context3 DFF is defined ascontext sensitive on Object Code/Expenditure Type, to support additional attributes.


11/26



8/16/00

9.Custom Programs and Tables SummaryThis is a summary of custom Yale programs and tables within JSA. Details follow.

JSA tables. Two Yale tables are used to facilitate import of batch and spreadsheet files intoJSA.

Registration of Source Systems. A Yale Registration Table is used to pre-register businessunits using JSA. This table is used to identify and communicate with originators of JSAbatches. At registration time, a Unix directory is created for batch and spreadsheet users.

Yale Authorization System (YAS). A pre-existing Yale system to support value-basedsecurity.

Validation extension. Implements Yale GL Validation rules, including Category-specificrules. Executed when Batch and Spreadsheet files are loaded. Executed when an on-line user

enters or updates a transaction. Invokes standard and Yale PA/GA validation rules.

For invalid transactions, suspense account processing is used. The original ChargingInstructions and the Validation Error Message are stored in the Transaction Description tomake them easily accessible to the user. The original Transaction Description is saved in aDFF attribute and replaced when the transaction is corrected.

Import Batch and Spreadsheet Files. This process starts with input files and ends withvalidated transactions available for correction and approval in the GL Journal Batches,Headers and Lines table, in the JSA set of books. Originators of batch and spreadsheet filesFTP their files to their own Unix directory. A Unix Autosys job runs periodically to moveinput file from the originators Unix directory to a central directory. A Central user invokes aconcurrent request to import input files into JSA. This process loads batches into the JSAYale Tables, invokes the JSA validation extension, and loads batches into the GL InterfaceTable. It provides feedback to the originator in the form of an e-mail message and a detailreport. The detail report is placed in the originators Unix directory.

On-Line Journal Correction. The native GL Journal Entry Form is used to correct invalidtransactions. It is the responsibility of the originator of the batch to correct errors - 300different people use this form. JSA users are identified by the two specific responsibilitiesthat they use. These responsibilities are limited to the JSA Set of Books.

The custom library (custom.pll) is used to modify the behavior of the GL Journal Entry formfor JSA users. These modifications are:

LOV of Batch Names altered to contain only batches where Organization in Batch Namematches Users YAS list of allowed Organizations.

Validation extension called for every line modified on-line.

For Journal Categories headed to GL, Task is set to 00000000. For JournalCategories headed to PA/GA, Balancing Segment is set to 00.

User can optionally display only invalid lines, using standard Find functionality.


12/26



8/16/00

JSA Batch Header Form:

JSA Journal Header and Detail Lines:


13/26


14/26



8/16/00

Manually Entered Transactions. The native GL Journal Entry Form is also used tomanually input JSA Batches. The custom library Form modifications described above alsoapply to new Batches.

Transaction Approval. The native GL Journal Posting Form is used to support Approval ofa Batch. It is the originating departments responsibility to approve each batch. TheApproval action physically results in posting of the Batch to the JSA set of books. Thecustom library is used to modify the behavior of this form:

Batches must have a Set of Books value of JSA Set of Books.


All lines must be valid before the batch can be approved.

Posted button modified. Name changed to Approve. Button disabled unless users

responsibility is YUGL Staging Manager. Transfer to Operational Set of Books. Approved batches are ready to be interfaced to the

Operational Set of Books. For GL Journal Categories, approved batches are extractedfrom JSA and loaded into the GL Interface Table a Set of Books value of Operational.Other than the Set of Books, they contain the same data as is found in JSA. For PA/GACategories, approved batches are extracted from JSA, reformatted, and loaded into the PAInterface Table.

PA/GA does not have enough DFF attributes to store all of the JSA data, due to GArestrictions. Therefore, transactions are not deleted from the JSA set-of-books. The JSAHeader ID and Line ID are stored in the destination system to support navigation back to the

JSA transaction for reporting purposes. Yale Reports. Several custom reports were created to support Department use of JSA. These

reports have a more meaningful format of the JSA transaction.

Spreadsheet Templates. Spreadsheet users are provided with Templates for creation of theirJSA Batches. A separate template is provided for each JSA Journal Category, to assist theuser in providing accurate and complete data.

10.Remaining Problems If you input the wrong Organization as part of your Batch Name, you cant view the batch!

You dont have access to that Organization.

Some validation rules were hard-coded and are difficult to maintain.

Transactions are not revalidated at time of approval. It is possible that a line that was validwhen input has become invalid by approval time. These transactions become trapped.They can not be changed in JSA once approved, and can not be transferred to PA/GA wheninvalid. The underlying validation issue must be reversed in order to process the transaction.For example, if the Project was closed, it must be reopened.

11.Remaining Opportunities Extend to other applications. Input AP Invoice Adjustments that do affect vendor payments

and feed to AP? Input Labor Distribution Adjustments and feed to LD? Move to Web, possibly using OSSWA functionality.


15/26



8/16/00

12.Custom Programs and Tables DetailRegistration Table and supporting functionality

A Registration function was created to support identification of and communication back to theoriginators of batches. All business units using JSA must be pre-registered. Tableyugl_ext_sys_registration contains the originating business units Source System Name, whichis used in the input file naming convention and in the batch naming convention. It also containstechnical and functional contacts. The technical and functional person ids, tech_person_idandfunc_person_id, stored in this table are the link back to the table hr.per_people_fthat allows thesystem to obtain the e-mail addresses for these contacts. In the event that the functional ortechnical e-mail address cannot be obtained by the system at runtime a default e-mail address isused.

A simple table maintenance form was created to query, insert, update and delete records on

YUGL_EXT_SYS_REGISTRATION.

Yale Authorization System (YAS)

Yale had already implemented a value-based security system. Users and the Organizations theyhave access to are stored in the YAS system. This data was used in JSA to restrict access to JSABatches. On-line JSA users can see only batches for which the Batch Name Organization iswithin their YAS access list. This rule is enforced using custom.pll.

Validation Extension

All records in the GL_INTERFACE table must pass through a validation process. Yale validationrules are enforced, including specific validation rules for the various Journal Categories. Thestandard PA validation program, patc.get_status is called to enforce PA/GA validation rules. Yalehas additional PA/GA validation rules in patcx.tc_extension, which are automatically invoked.

The validation extension is called whenever a JSA transaction is input or updated. It is part of theimport process for Batch and Spreadsheet files. It is called via custom.pll when a transaction isupdated using the on-line form.


16/26



8/16/00

To facilitate correction of invalid transactions, the validation routine stores the invalid segmentvalues and the error messages in the Transaction Description. It saves the original TransactionDescription in a DFF attribute. With GL Suspense processing turned on for the JSA Set of Books,the invalid segment values are overlaid with the Suspense Account when the transaction is

imported into JSA. The original segment values had to be stored somewhere for reference by theuser, and the Transaction Description is an easily accessible location that can be referenced by theFind functionality of the Journal Entry Form. When the transaction is corrected, the originalTransaction Description is restored.

Sample Error Messages:

Message

Number

Message Text

2120 The object code you selected is not available for this journal category. Pleaseverify that you have selected a valid for object code for this category.

2140 The balancing segment must equal 02. This is the only valid choice for"BALANCING SEGMENT" in the detail record.

2170 The project must be a valid 7digit code. Please verify your source code for thistransaction.

2210 The fiscal period must be in the correct format DD_MON_YYYY and it must bein an open accounting period.

Import Batch and Spreadsheet Files

Externally generated files are placed on the data collection server (SAL) with the file extensionTRN. A UNIX shell script,YUGLSTGD.prog, is invoked as a concurrent process and is the driverfor file capture, Yale JSA Staging Table load, Yale JSA Staging Table pre-validation, GLinterface load, and GL interface validation processes. The shell script will look for the data fileswith the TRN extension under the path $SOFTPATH/yugl/data. Data files that exist in thisdirectory will have their extension changed to RCV by the shell script to indicate that the file hasbeen received. The shell script will then insert the data filenames into a control file calledGLI.DAT. This control file holds the names of all the external files on SAL that need to be loadedinto the Yale JSA Staging Tables. The shell script then reads each file named in GLI.DAT andthen calls the appropriate routines to load and pre-validate the data in the Yale JSA StagingTables. Once all the files in GLI.DAT have been loaded and pre-validated, the shell script willcall the procedure, yugl_load_gl_interface_prc, to load the table gl_interface with data from the

Yale JSA Staging Tables. It then kicks off another concurrent process that will perform additionalvalidation on the data in the gl_interface table.

Externally generated files are loaded into the Yale JSA Staging Tables using Oracle SQLLOAD.Prior to loading however, the files are pre-processed to validate the Record Type and to appendheader and group ids to each record in the file. This pre-processing is performed with the UNIXutility AWK. The awk program file used to perform this pre-processing is calledyugl_stg_load.awk. In the event of a failure during this pre-processing, an Invalid Batch Report isgenerated with a file extension of RPT. Otherwise the UNIX driver invokes SQLLOAD to loadthe file. The SQLLOAD control file,yugl_stg_load.ctl, defines the loading of data to both theyugl_staging_header and yugl_staging_lines tables. In the event that an error occurs during theSQLLOAD process an e-mail message is sent to the technical and functional contacts that areregistered for this files source system. At this point an Invalid Batch Report is not generated.Upon successful loading, the shell script will call the validation procedure,yugl_stg_validation_prc, which will verify various data fields.


17/26



8/16/00

During the AWK and SQLLOAD processes, various fields are populated with data values that arenot contained in the external data files. Some of these values are constants and others are derived(e.g., detail line number). A list of attributes and the values they are populated with follows.Fields populated by the AWK process are denoted with an asterisk (*).

YUGL_STAGING_HEADER

header_id * sequence yugl_header_seqgroup_id * sequence gl_interface_control_sheader_status constant LOADED

YUGL_STAGING_LINES

header_id * sequence yugl_header_seqgroup_id * sequence gl_interface_control_sjournal_line sequential line counterstatus constant NEWset_of_books_id constant 2

currency_code constant USDdate_created system date formatted DD-MON-YYYYcreated_by value of batch_organizationactual_flag constant Auser_je_source_name constant Yale Externalreference7 constant NOreference1 batch_organization-batch_source-batch_date-batch_seq_no

Once an external file has been loaded into the Yale JSA Staging tables, the shell script will theninitiate the validation procedure, yugl_stg_validation. The fields that are checked and the criteriafor validation is as follows:

Date Fields: batch_date, fiscal_period, accounting_date, and transaction_date. All fieldsthat should contain dates are checked for the standard date format of DD-MON-YYYY.Since these fields are defined as character fields, the data contained within them is alsochecked for successful conversion to a date datatype. The accounting_date is checked toverify that it is in an OPEN or FUTURE ENTERABLE period. Also, the transaction_date(which is stored in attribute1) is tested to verify that it is not greater than the current systemdate. Note that prior to any date comparison the date values will need to have the hours,minutes and seconds truncated.

Numeric Fields: entered_cr, entered_dr, and total_debits. Because the data is beingcaptured as character data types, it is necessary to verify that all fields that will eventually beconverted to numbers only contain numeric entries. This is accomplished by checking to see

that each of these values can be successfully converted to a number. An additional test isperformed to verify that each detail record has exactly one entry in either the entered_cr orentered_dr field, but not in both. To further validate the batch, running totals are calculatedfor the entered_cr and entered_dr for comparison with each other and for comparison with thevalue of total_debits. If any of these tests fail the record is flagged with an error message

Journal Category: The journal category, stored in the field user_je_category_name, isvalidated against the entries in the table gl_je_categories. In addition, each subsequentrecords journal category is checked against that of the first record for consistency.

Batch Organization: The value given in batch_organization is tested for 6 valid numericdigits and if it passes that check the function yugl_valid_org_unit_fcn is called to verify that itis a valid batch organization.

Duplicate Batch: The values in batch_organization, batch_source, batch_date, andbatch_seq_no are checked against the existing records in yugl_staging_header to see if thisbatch has already been received and processed.


18/26



8/16/00

Whenever these validation checks fail, the appropriate error message is written to the offendingrecord and the header_status is set to FAILED.

Batch acceptance/rejection

Once the validation checks have completed, the Invalid Batch Report is generated. This reportlists the validation errors found for each detail line. It also displays the batch organization, batch,source, and sequence number for processed file, as well as, the journal line number, journalcategory, and the accounting date. If no errors were found then this file is empty. In all cases ane-mail is generated and sent to the Source Systems Functional Contact indicating whether thestaging load and validation process was successful or if it had failed. In the latter case an e-mailmessage is also sent to the Source Systems Technical Contact and gives more details regardingthe cause of the failure.

Sample of the Invalid Batch Report:YALE UNIVERSITY GL EXTERNAL FILE LOAD

INVALID BATCH REPORT

BATCH: GLIMCPOSI26OCT19981234.LDR

Batch Batch Batch Journal Journal AccountingStatus Org. Source Batch Date Seq# Line No Category Date______ ___________________________________ ________ ______________ _________________________________________________________________________________________FAILED 666019-MCPOSI-26-Oct-1998-1234 1 YIntDptTrsf 25-Oct-1998Invalid Journal Category.

FAILED 666019-MCPOSI-26-Oct-1998-1234 2 YIntDptTrsf 25-Oct-1998Invalid Journal Category.

****END OF REPORT****

GLIMCPOSI26OCT19981234.RPT Page 2 26-OCT-1998 15:33

Sample e-mail messages:

Date: Mon, 26 Oct 1998 13:36:22 -0500From: Jane Smith To: [email protected]: GL Staging Loaded

FILENAME: GLITESTHM23OCT19980003.LDRVALIDATION STATUS: Data Validation Successful

Check Directory /OGF5soft/yugl/data for LOG files and_or Reports

Date: Wed, 21 Oct 1998 13:40:39 -0400

From: Jane Smith To: [email protected]: GL Staging Error

FILENAME: GLITESTHM21OCT19980005.LDRERROR: Invalid Batch

Check Directory /OGF5soft/yugl/data for LOG files and_or Reports

Population of Missing Data Elements

The program that moves data from the YUGL_STAGING_LINES table to the GL_INTERFACE

table populates the following fields with the following data:STATUS NEWCURRENCY_CODE USDACTUAL_FLAG A


19/26



8/16/00

SEGMENT1 02REFERENCE7 NOREFERENCE22 Data contained in Reference10REFERENCE27 Total Debit Amount for the Batch

Import to JSA Staging Area

Oracle Corporation has provided the software that import records from the GL_INTERFACEtable into the GL_JE_BATCHES, GL_JE_HEADERS, and GL_JE_LINES table. The Importprocess requires two parameters. The first is the user_je_source_name, which is Yale External forall JSA Batches. The second parameter is group_id, which is assigned a value during theSQL*LOADER process. A concurrent process is submitted which calls the native GL IMPORTPROCESS routine.

Load of Batch Control Amounts

The concurrent process submits a job that updates the control total field in the GL_JE_HEADERtable. This is accomplished by taking the value in the total_debits field in theYUGL_STAGING_HEADER table and assigning it to the control total field in theGL_JE_HEADER table

Eliminate Trailing Spaces in the GL_JE_LINES Description field

The job that updates the control total filed in the GL_JE_HEADER table will also eliminatetrailing spaces in the description field in the GL_JE_LINES table.

On-line Transaction Correction

The native GL Journal Entry form is used to correct transactions. The behavior of the form ismodified using the custom library (custom.pll). These modifications include:


Validation extension called for every line modified on-line.

For Journal Categories headed to GL, Task is set to 00000000. For JournalCategories headed to PA/GA, Balancing Segment is set to 00.

User can optionally display only invalid lines, using standard Find functionality.

Custom.pll Code Example

The following custom.pll code example enforces the use of valid Organizations within the Batch Name.

BEGIN

-- All GL Customisations are only for the Staging Area Set of Books.fnd_profile.get('GL_SET_OF_BKS_NAME', v_gl_set_of_bks_name);IF (v_gl_set_of_bks_name = 'GL Journal Staging Area') then

IF (v_form_name = 'GLXJEENT') THEN

IF (event_name = 'WHEN-NEW-FORM-INSTANCE') THENyugl_new_form_instance(v_form_name);END IF;

IF (event_name = 'WHEN-NEW-ITEM-INSTANCE') THENyugl_new_item_instance (v_item_name);

END IF;


20/26



8/16/00

-- Validate that the first six characters of the batch name are avalid organization number.

IF ((v_block_name = 'BATCH') AND(event_name = 'WHEN-VALIDATE-RECORD') ) THEN

v_batch_name := NAME_IN('BATCH.NAME');v_batch_attribute1:=substr(v_batch_name,1,6); -- rk06/12/2000COPY (v_batch_attribute1,'BATCH.ATTRIBUTE1' ); -- rk06/12/2000IF NOT

(yugl_stg_glint_valid_pkg.yugl_valid_org_unit_fcn(substr(v_batch_name,1,6),v_err_code)) THEN

IF v_err_code = '2200' THENFND_MESSAGE.SET_STRING('Batch Name contains an Invalid

Organization Number. Please go back and correct it.');FND_MESSAGE.ERROR;RAISE FORM_TRIGGER_FAILURE;

END IF;END IF;

END IF;

PROCEDURE yugl_new_form_instance(i_form_name IN VARCHAR2) IS

v_lines_default_where VARCHAR2(2000);

v_set_of_books_id varchar2(15);v_user varchar2(30);v_domain varchar(50) := 'ACCESS ORGS';v_function_name varchar2(60) ;

v_query_ok number;

v_folder_query_blk varchar2(2000);v_batch_query_blk varchar2(2000);v_header_query_blk varchar2(2000);v_batches_blk varchar2(2000);

v_folder_batch_qf_rg varchar2(2000);v_batch_qf_rg varchar2(2000);v_folder_header_qf_rg varchar2(2000);v_header_header_qf_rg varchar2(3000);v_batch_name_qf_rg varchar2(2000);

v_org_select varchar2(2000);v_big_man_select varchar2(100);fnd_profile.get('USERNAME',v_user);fnd_profile.get('RESP_NAME', v_function_name);fnd_profile.get('GL_SET_OF_BKS_ID', v_set_of_books_id);

IF (i_form_name = 'GLXJEENT') THEN -- Journal Entry Form

-- Call the stored procedure to build the SELECT statement whichreturns all leaf level orgs

!that a user is authorized to access for the LOV.!

yugl_yas_pkg.yugl_get_org_select(v_user, v_function_name, v_domain,

v_org_select, v_big_man_select);


21/26



8/16/00

Journal Line Correction

To correct a transaction on-line, the user navigates to Enter Journal. The Find Journals screenappears. The user inputs the batch name (or any part thereof followed by the %, the wild-cardsymbol) and presses the FIND button. Any batch name matching the criteria entered is displayed.The user selects the batch that requires correction. The user navigates to the line containing theerror and makes the necessary correction(s). At this point, the user has two options. Option 1 is tocommit the changes that were made. This causes the WHEN-VALIDATE-RECORD to fire andthe record is re-validated, using custom.pll logic. If no errors are found, the error messages in thedescription box disappear and the original description is displayed. Option 2 is to navigate toanother line. This also causes the WHEN-VALIDATE-RECORD to fire and the record is re-validated. If no errors are found, the error messages in the description box disappear and theoriginal description is displayed.

In either scenario, if more errors or additional errors are found during the validation process, theerror messages are put in the description box.

Journal Line Validation

There are two types of validations (Oracle built-in and Yale University Business Rules) that occurwhile using the on-line forms. The first type of processing is built into the Oracle forms.Validations of this kind include valid segment values, valid category, etc. The Yale BusinessRules validations are called through the use of custom.pll. When the user moves from one recordto another or leaves the form, the event WHEN-VALIDATE_RECORD trigger is fired. Duringthis event, the common validation routine is called and the data is validated against the YaleBusiness Rules. These are same validation rules that are called during the import of batch filesand spreadsheets.

Displaying only Journal Lines in Error

In order to display only those records in error, the user must do the following, after selecting theBatch:

1)Press the More Details button (located in the bottom left corner of the screen)

2)Type a capital E in the Reference Field.

3)Close the screen by clicking the x in the upper right hand corner.

4)Please the cursor in the Line 1 box

5)Press the F8 key this will query the batch and return only those records in error. This isaccomplished using custom.pll.

Journal Batch Deletion

Only unposted batches can be deleted. To delete a Batch, first select the batch. The box to theleft of the Batch Status is highlighted. Click on the big RED X icon. A Decision Box is displayedwith the following message: Do you want to delete the entire batch or just the current journalentry?

Click the BATCH button

Press the icon that looks like a diskette. This issues the commit. The Deletion has officiallyoccurred.

Journal Batch Corrections

Control totals are being captured at the Batch level. If a record gets added or deleted from thebatch, then the control total must be adjusted accordingly. To correct the Batch Control on-line,the user navigates to Enter Journal. The Find Journals screen appears. The user inputs the batch


22/26



8/16/00

name (or any part thereof followed by the %, the wild-card symbol) and presses the FIND button.Any batch name matching the criteria entered is displayed. The user selects the batch they want tomodify, and presses the Review Batch button. The Batch screen appears and the user can modifythe control total. After changing the control total, the user must save the new information.

Pressing the icon that looks like a diskette or pressing F10 will save the data.

Manually Entered Transactions

Electronic Interfaces is one method of getting data into the Oracle General Ledger system.Another method is to manually enter the data on-line, using the native GL Journal Entry Form.For input of transactions, this form is subject to the behavior modifications described under On-Line Transaction Correction. To enter transactions manually, the user follows these steps:

1)Navigate to Enter Journal.

2)The Find Journals screen appears. Press theNew Batch button.

3)The Batch screen is displayed. Fill in the three boxes (Batch, Description, and Control Total).Batch Name must follow the Batch Naming Convention. Press theJournals button. TheJournal screen is displayed. Input information for Journal, Category, and Description.

4)To create a new journal line, position the cursor in the line field, and press the + icon (addrecord) or scroll to the end of the file, using the down arrow key. Regardless of whichmethod is used, the system is ready to accept a new transaction line. Each transaction isvalidated as it is input. After inputting all of the transactions, the user must hit the disketteicon or F10 to save his/her work.

Transaction Approval

The native GL Journal Posting Form is used to support Approval of a Batch. It is the originatingdepartments responsibility to approve each batch. The Approval action physically results in posting ofthe Batch to the JSA set of books. The custom library is used to modify the behavior of this form:

Batches must have a Set of Books value of JSA Set of Books.


All lines must be valid before the batch can be approved.

Posted button modified. Name changed to Approve. Button disabled unless usersresponsibility is YUGL Staging Manager.

In the Staging Area set of books, approving a batch means that the batch is error free and that it is

all right to send the data onto the Operational Set of Books. To approve a batch, the YUGLStaging Manager responsibility must be used. The user does the following:

1)Navigate to Post Journals.

2)The Find Journal Batches screen appears. Type in the Batch Name, or any part thereoffollowed by the %, in the Batch field. Press theFind button.

3)To select the batch you want to approve, click on the box to the left of the period field. If therecord becomes highlighted, then the batch contains no errors and it is can be approved.However, if the record becomes gray, this indicates that the batch contains one or moreinvalid transactions and it cannot be authorized. All validation errors have to be correctedbefore the batch can be approved.

Transfer to the Operational Set of Books

Approved JSA Batches are ready to be posted to GL or to PA/GA. A centrally run customprogram is used to do this. It extracts transactions from the JSA set of books in the GL Journal


23/26



8/16/00

Batches, Headers and Lines tables and inserts them into the GL Interface Table or the PA InterfaceTable. From this point on, native GL and PA/GA functionality is used to process the transactions.

Transaction lines are not deleted from JSA. DFF limitations in PA/GA (due to GA restrictions)prevented propagation of all of the necessary JSA data. Therefore, JSA transactions must bemaintained to record all of the pertinent data. In both the GL Operational Set of Books entries,and in the PA/GA entries, data is stored to support navigation back to the JSA line. In PA/GA,transaction_source is set to the JSA Journal Category and orig_transaction_reference is set to theJSA GL Header ID concatenated to the JSA GL Journal Line ID.

There are currently five journal categories which require the creation of expense transactions inOGM. These are YInterDeptTrsf, YExpenseAdjust, YProcard, YGCCostTrsf,YRevAssement.

The package YUPA_glintrfc_pkg (filename YUPAGLNTRFC.pkg) creates transactions in the PAinterface table from the JSA GL Journal Lines. The procedure load_ogm_interface receives abatch id as an input parameter. If the batch is associated with an appropriate JSA Journal

Category, the lines within are converted to PA/GA transactions and written to the tablePA_Transaction_Interface_All. The process passes back a return code, and an error message if aprocessing exception occurs.

Yale Reports

Several custom reports are needed to support use of JSA. They are:

Yale Staging Journal Detail Attribute Report (YUGLJDEA.rdf)Lists all attributes for all lines in the batch(es) specified.

Yale Staging Journal Error Report (YUGLJERR.rdf)Lists batches which have any journal lines with errors. Includes detail on lines with errors.

Yale Staging Journal Detail Report (YUGLJDER.rdf)Lists details for the batch specified. Includes detail on all lines.

Staging Unposted Journal Aging Report (YUGLJSAA.rdf)Lists unapproved (unposted) journals indicating how old the journals are. The journals fallinto one of 4 buckets: less than or equal to 2 weeks old, between 2 and 3 weeks old, Between3 and 4 weeks old, and more than 4 weeks old.

Spreadsheet Templates

An Excel Spreadsheet Template exists for each Journal Category, to facilitate input oftransactions. The template contains properly formatted columns for all of the data elementsavailable for that Category. Both Header and Detail lines are input into the spreadsheet.

Once final, the user exports the spreadsheet contents as a comma delimited file. This file is thenFTPd to a Unix directory, exactly as is done for a batch file. Processing of Spreadsheet files isthe same as processing for Batch files.


24/26



8/16/00

13.AppendicesYale Registration Table Layout

YUGL_EXT_SYS_REGISTRATIONappl_acronym varchar2(3) not null,src_sys_name varchar2(6) not null,src_sys_desc varchar2(80),tech_person_id number not null,func_person_id number not null,src_ip_address varchar2(15),src_platform varchar2(40),constraint s_reg_appl_src_pk primary key (appl_acronym,src_sys_name)

Yale JSA Table LayoutYUGL_STAGING_HEADER

HEADER_ID NUMBER(15)HEADER_STATUS VARCHAR2(10)HEADER_ERRMSG VARCHAR2(80)RECORD_TYPE VARCHAR2(3)BATCH_ORGANIZATION VARCHAR2(6)BATCH_SOURCE VARCHAR2(6)BATCH_DATE VARCHAR2(11)BATCH_SEQ_NO VARCHAR2(4)FISCAL_PERIOD VARCHAR2(11)TOTAL_DEBITS VARCHAR2(38)GROUP_ID VARCHAR2(15)

YUGL_STAGING_LINESHEADER_ID NOT NULL NUMBER(15)JOURNAL_LINE_NUMBER NOT NULL NUMBER(15)BATCH_ORGANIZATION NOT NULL VARCHAR2(6)BATCH_SOURCE NOT NULL VARCHAR2(6)BATCH_DATE NOT NULL VARCHAR2(11)BATCH_SEQ_NO NOT NULL VARCHAR2(4)RECORD_STATUS VARCHAR2(15)RECORD_TYPE VARCHAR2(3)STATUS NOT NULL VARCHAR2(50)SET_OF_BOOKS_ID NOT NULL VARCHAR2(15)ACCOUNTING_DATE NOT NULL VARCHAR2(11)CURRENCY_CODE NOT NULL VARCHAR2(15)DATE_CREATED NOT NULL VARCHAR2(11)CREATED_BY NOT NULL VARCHAR2(15)ACTUAL_FLAG NOT NULL VARCHAR2(1)USER_JE_CATEGORY_NAME NOT NULL VARCHAR2(25)USER_JE_SOURCE_NAME NOT NULL VARCHAR2(25)CURRENCY_CONVERSION_DATE VARCHAR2(11)ENCUMBRANCE_TYPE_ID VARCHAR2(38)BUDGET_VERSION_ID VARCHAR2(38)USER_CURRENCY_CONVERSION_TYPE VARCHAR2(30)CURRENCY_CONVERSION_RATE VARCHAR2(38)AVERAGE_JOURNAL_FLAG VARCHAR2(1)SEGMENT1 VARCHAR2(25)SEGMENT2 VARCHAR2(25)SEGMENT3 VARCHAR2(25)SEGMENT4 VARCHAR2(25)SEGMENT5 VARCHAR2(25)SEGMENT6 VARCHAR2(25)SEGMENT7 VARCHAR2(25)SEGMENT8 VARCHAR2(25)SEGMENT9 VARCHAR2(25)SEGMENT10 VARCHAR2(25)SEGMENT11 VARCHAR2(25)SEGMENT12 VARCHAR2(25)SEGMENT13 VARCHAR2(25)SEGMENT14 VARCHAR2(25)


25/26



8/16/00

SEGMENT15 VARCHAR2(25)SEGMENT16 VARCHAR2(25)SEGMENT17 VARCHAR2(25)SEGMENT18 VARCHAR2(25)SEGMENT19 VARCHAR2(25)SEGMENT20 VARCHAR2(25)SEGMENT21 VARCHAR2(25)SEGMENT22 VARCHAR2(25)SEGMENT23 VARCHAR2(25)SEGMENT24 VARCHAR2(25)SEGMENT25 VARCHAR2(25)SEGMENT26 VARCHAR2(25)SEGMENT27 VARCHAR2(25)SEGMENT28 VARCHAR2(25)SEGMENT28 VARCHAR2(25)SEGMENT29 VARCHAR2(25)SEGMENT30 VARCHAR2(25)ENTERED_DR VARCHAR2(38)ENTERED_CR VARCHAR2(38)ACCOUNTED_DR VARCHAR2(38)ACCOUNTED_CR VARCHAR2(38)TRANSACTION_DATE VARCHAR2(11)REFERENCE1 VARCHAR2(100)REFERENCE2 VARCHAR2(240)REFERENCE3 VARCHAR2(100)REFERENCE4 VARCHAR2(100)REFERENCE5 VARCHAR2(240)REFERENCE6 VARCHAR2(100)REFERENCE7 VARCHAR2(100)REFERENCE8 VARCHAR2(100)REFERENCE9 VARCHAR2(100)REFERENCE10 VARCHAR2(240)REFERENCE11 VARCHAR2(100)REFERENCE12 VARCHAR2(100)REFERENCE13 VARCHAR2(100)REFERENCE14 VARCHAR2(100)REFERENCE15 VARCHAR2(100)REFERENCE16 VARCHAR2(100)REFERENCE17 VARCHAR2(100)REFERENCE18 VARCHAR2(100)REFERENCE19 VARCHAR2(100)REFERENCE20 VARCHAR2(100)REFERENCE21 VARCHAR2(240)REFERENCE22 VARCHAR2(240)REFERENCE23 VARCHAR2(240)REFERENCE24 VARCHAR2(240)REFERENCE25 VARCHAR2(240)REFERENCE26 VARCHAR2(240)REFERENCE27 VARCHAR2(240)REFERENCE28 VARCHAR2(240)REFERENCE29 VARCHAR2(240)REFERENCE30 VARCHAR2(240)JE_BATCH_ID VARCHAR2(15)PERIOD_NAME VARCHAR2(15)JE_HEADER_ID VARCHAR2(15)JE_LINE_NUM VARCHAR2(15)CHART_OF_ACCOUNTS_ID VARCHAR2(15)FUNCTIONAL_CURRENCY_CODE VARCHAR2(15)CODE_COMBINATION_ID VARCHAR2(15)DATE_CREATED_IN_GL VARCHAR2(11)WARNING_CODE VARCHAR2(4)STATUS_DESCRIPTION VARCHAR2(240)STAT_AMOUNT VARCHAR2(38)GROUP_ID VARCHAR2(15)REQUEST_ID VARCHAR2(15)SUBLEDGER_DOC_SEQUENCE_ID VARCHAR2(38)SUBLEDGER_DOC_SEQUENCE_VALUE VARCHAR2(38)ATTRIBUTE1 VARCHAR2(150)ATTRIBUTE2 VARCHAR2(150)ATTRIBUTE3 VARCHAR2(150)ATTRIBUTE4 VARCHAR2(150)ATTRIBUTE5 VARCHAR2(150)ATTRIBUTE6 VARCHAR2(150)ATTRIBUTE7 VARCHAR2(150)ATTRIBUTE8 VARCHAR2(150)


26/26



ATTRIBUTE9 VARCHAR2(150)ATTRIBUTE10 VARCHAR2(150)ATTRIBUTE11 VARCHAR2(150)ATTRIBUTE12 VARCHAR2(150)ATTRIBUTE13 VARCHAR2(150)ATTRIBUTE14 VARCHAR2(150)ATTRIBUTE15 VARCHAR2(150)ATTRIBUTE16 VARCHAR2(150)ATTRIBUTE17 VARCHAR2(150)ATTRIBUTE18 VARCHAR2(150)ATTRIBUTE19 VARCHAR2(150)ATTRIBUTE20 VARCHAR2(150)CONTEXT VARCHAR2(150)CONTEXT2 VARCHAR2(150)INVOICE_DATE VARCHAR2(11)TAX_CODE VARCHAR2(15)INVOICE_IDENTIFIER VARCHAR2(20)INVOICE_AMOUNT VARCHAR2(38)CONTEXT3 VARCHAR2(150)USSGL_TRANSACTION_CODE VARCHAR2(30)DESCR_FLEX_ERROR_MESSAGE VARCHAR2(240)JGZZ_RECON_REF VARCHAR2(240)

Documents

PA - Consistent Journal Entry for Projects-Grants Management