PA - Consistent Journal Entry For Projects-Grants Management

Consistent Journal Entry for Projects/Grants Management
and General Ledger
Joyce Lush
Yale University
Fred Gerbino
Yale University
Frances Dykstra
Yale University
Table of Contents
1. ABSTRACT: ....................................................................................................................................... 1
2. EXECUTIVE SUMMARY:..................................................................................................................... 1
3. YALE’S ENVIRONMENT ..................................................................................................................... 2
Applications ..................................................................................................................................... 2
Transaction Volume ......................................................................................................................... 2
Chart of Accounts............................................................................................................................. 2
4. REQUIREMENTS FOR TRANSACTION ENTRY ...................................................................................... 4
5. GL AND PA/GA STANDARD ORACLE FUNCTIONALITY .................................................................... 4
GL Functionality .............................................................................................................................. 4
PA Functionality .............................................................................................................................. 5
Gaps ................................................................................................................................................. 5
6. SOLUTION ......................................................................................................................................... 6
Disadvantages.................................................................................................................................. 6
7. PROCESS FLOWS ............................................................................................................................... 7
Process Flow – Import Batch or Spreadsheet File .......................................................................... 7
Process 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 ................................................................................. 8
9. CUSTOM PROGRAMS AND TABLES – SUMMARY ............................................................................. 10
10. REMAINING PROBLEMS ................................................................................................................... 13
11. REMAINING OPPORTUNITIES ........................................................................................................... 13
12. 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..................................................................................................... 18
Manually Entered Transactions ..................................................................................................... 21
Transaction Approval..................................................................................................................... 21
Transfer to the Operational Set of Books....................................................................................... 21
Yale Reports ................................................................................................................................... 22
Spreadsheet Templates................................................................................................................... 22
13. APPENDICES .................................................................................................................................... 23
Yale Registration Table Layout...................................................................................................... 23
Yale JSA Table Layout ................................................................................................................... 23
Copyright @ 2000 by Joyce Lush

Consistent Journal Entry for Projects/Grants
Management and General Ledger
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-point
supports 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 and
revenue transactions directly to the General Ledger. Transactions are originated by over 300
distributed departments, using a mixture of automated feeds, spreadsheets, and manual entry.
From a training and usability perspective, it was essential to Yale’s implementation that journal
entries, regardless of their destination, be input, validated, corrected and authorized using a single
entry point.
Yale’s requirements include consistent entry of charging instructions, distributed and flexible
mode of entry, distributed correction of validation errors, limiting department access to their own
transactions, and central control of the official set of books. For Oracle Projects, additional
requirements include transaction transfer between Expenditure Types and Expenditure
Organizations and the ability to input two-sided entries. For General Ledger, additional
requirements include enforcement of Yale validation rules.
This paper describes Yale’s “Journal Staging Area” (JSA) application, which provides a single
entry and correction point for all journals. JSA consists of creative Oracle General Ledger setup
supplemented by standard technical extensions of the application. The presentation covers
functionality 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 of
books) was created to support transaction entry. Segments in the JSA set of books were defined to
support both Yale’s GL account structure and Oracle Project’s Project/Task/Expenditure
Type/Organization. GL Journal Categories were used to provide a framework for Yale validation
and processing. For example, some Categories are Projects-only, some are GL-only, and some
result in transactions to both applications. The GL Journal Entry Form was extended using the
Custom Library and a separate set of Responsibilities. For the JSA responsibilities, the set of
books is limited to the JSA set of books; the contents of the Segment LOVs are determined by the
Category; and Yale validation rules are enforced. Transactions can be manually entered into the
form. Data files and spreadsheets are validated and then loaded into JSA via the GL Interface file
for distributed error correction and authorization. “Authorization” functionality is supported by
the “posting” button – the button is renamed to “Authorize”; all transactions in the batch must be
valid; and the result of “authorization” is posting to the JSA set of books in the General Ledger. A
centrally controlled concurrent request extracts “authorized” batches from the JSA set of books,
reformats them, and interfaces them to the destination application’s interface file (Oracle Projects
and/or General Ledger).
This extension successfully supports distributed Journal Entry regardless of destination
application, while enforcing Yale business rules and maintaining central control over the official
accounting records.
8/16/00 Page 1
3. Yale’s Environment
Applications
JSA 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 Oracle
Projects/Grants Management. Grants Accounting is essentially an extension of Oracle Projects to
meet specific requirements of Higher Education.
For the purposes of this paper, Oracle Projects and Grants Accounting are synonymous. Although
Yale is using Grants Accounting, all of the concepts and techniques of this paper apply equally to
an Oracle Projects implementation. Grants Accounting adds the concept of “Award” to the
charging instruction – along with Oracle Projects Project, Task, Expenditure Type and
Expenditure Organization, Grants Accounting uses “Award” on every transaction. Grants
Accounting 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
8/16/00 Page 2
Yale’s General Ledger chart of accounts is:
Segment Value Set

Balancing Independent – manually input
Segment
Project Oracle Projects’ Projects table
Source Independent – manually input
Object Code Independent – manually input
Organization Independent – Yale extension used to
manually input Organizations and to
consistently update both GL and HR
Organizations.
Yale’s Oracle Projects / Grants Accounting chart of accounts is:
Segment Source of Values Relationship

to GL
Segment
Project Oracle Projects Same as Project
Projects Table – Segment
manually input
Task Oracle Projects Task None
Table – manually input
Award Grants Accounting Rolls up into Source
Award Table – manually
input
Expenditure Type Oracle Projects Rolls up into Object
Expenditure Type Table Code
– manually input
Expenditure HR Organization Table One-to-one relationship
Organization – manually input using between leaf-level HR
Yale extension to Organization and GL
synchronize HR and GL Organization. GL
values Organization Number
stored in HR
Organization Table and
appended to HR
Organization Name
8/16/00 Page 3
4. Requirements for Transaction Entry

JSA 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/GA
transactions are called “Expenditure Items” and are used at Yale for expenses and some balance
sheet transactions. At Yale, JSA is NOT used for AP Invoices, adjustments to AP Invoices that
involve vendor payments, or for detail-level Labor adjustments. JSA IS used for corrections to
charging 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 formatted
spreadsheet, 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 type
of transaction.
• The originating user is responsible for correcting invalid transactions.
• Provide a distributed access to an on-line correction form. Limit access to transactions that
are associated with the user.
• Require approval for all transactions. This approval means that a responsible person has
stated 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 ISP’s 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 Functionality

Both GL and PA have built-in functionality to address transaction entry and adjustment. Yale
found significant gaps between our requirements and the standard Oracle functionality. Many of
these gaps have been narrowed by new Release 11/11I functionality, but significant gaps still
remain.
GL Functionality
• GL Interface Table for support of batch entry
• On-line form for Journal Entry and Update
8/16/00 Page 4
• 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, Task
and 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. (Available
in 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 can’t be implemented using cross-validation
rules.
• 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.
8/16/00 Page 5
6. Solution
Yale needed:
• A single batch file and spreadsheet layout that supported all of the required GL and PA/GA
transactions.
• A single transaction validation routine.
• A single distributed on-line Form for entry of new transactions, correction of invalid
transactions, and approval of batches. Form had to limit access to batches associated with the
user, 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 existing
functionality. Oracle’s 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 mass
adjustment of original transactions) and was suitable for distributed use. All Yale had to do was to
add 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 approved
transactions 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 behavior
of the GL Journal Entry and GL Posting Forms, and custom concurrent programs to handle
loading data into Interface Tables.
Disadvantages
The 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 is
very difficult to reliably report the impact on the original transaction.
2. JSA users can create negative account balances, by transferring more costs than were
originally charged.
8/16/00 Page 6
7. Process Flows
Process Flow – Import Batch or Spreadsheet File
Import Batch or Spreadsheet File

Source Unix Oracle
System Directory Applications
JSA GL
Batch Batch Interface
Staging
File File Table
Tables
Results Validation
Report GL
Headers,
Batches,
Lines
E-Mail
Message Bold - visible to Distributed User
Dashed - Native Functionality
Process Flow – Transaction Correction, Manual Entry and Approval
Transaction Correction, Manual

Entry and Approval
Oracle Applications
Entry and GL Journal

Correction Entry Form GL
Headers,
Custom.pll Batches,
Lines
GL Journal “Posted”
Approval Entry Form
Custom.pll
Bold - visible to Distributed User
8/16/00 Page 7
Process Flow – Transfer to Operational Set of Books
Transfer to Operational Set of

Books
Oracle Applications
GL
GL
GL Categories Interface
Headers, Table
Batches, Reformat
Lines Data
Approved JSA PA
Batches PA/GA
Categories
Interface
Table
Bold - visible to Distributed User

8. GL Setup for Staging Area Set of Books

A central concept is the establishment of a separate set of books for JSA. Although the GL is used
as a vehicle for implementing JSA, JSA is completely separate from the GL Operational set of
books.
Setup:
• “Journal Staging Area” set of books
• JSA Journal Categories. Yale validation rules and processing are defined at the Category
level. Some categories are used for transactions headed to GL; other categories are used for
transactions headed to PA/GA.
• Two new responsibilities – “YUGL Staging User” and “YUGL Staging Manager”. Only the
“YUGL Staging Manager” can approve batches.
• A naming convention for JSA Batches. The Batch Name contains a 6-digit Organization
Number, a Source System Name, Batch Date, and Batch Sequence Number. The
Organization Number in the Batch Name is used to control access to the batch. The Source
System Name is used to identify the business unit submitting the batch. The Batch Date is the
date on which the batch is submitted. The Batch Sequence Number is used to uniquely
identify each batch.
8/16/00 Page 8
• GL Segments and value sets for JSA set of books. Segments combine GL Operational Set of
Books Value Sets with PA/GA PTAEO values. Views are used to combine values.
Segment Source of Data

Balancing GL Balancing Segments - “00” value used for PA/GA transactions.
Segment
Project PA Projects Table. (Same as Operational set of books.) Leading
zeros added to sequential Project Number. Exclude Templates, closed
Projects, 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 / Union of GL Object Codes and PA/GA Expenditure Types. PA/GA
Expenditure Type Expenditure Types limited to System Linkage of ‘USAGES’ or
‘STRAIGHT-TIME LABOR’.
Organization GL Organization. HR Organizations (used for PA/GA transactions)
can be referenced by GL Organization Number. Must be a leaf-level
Org.
• 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 as
context sensitive on Object Code/Expenditure Type, to support additional attributes.
8/16/00 Page 9
9. Custom Programs and Tables – Summary

This 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 into
JSA.
• Registration of Source Systems. A Yale Registration Table is used to pre-register business
units using JSA. This table is used to identify and communicate with originators of JSA
batches. 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-based
security.
• Validation extension. Implements Yale GL Validation rules, including Category-specific
rules. 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 Charging
Instructions and the Validation Error Message are stored in the Transaction Description to
make them easily accessible to the user. The original Transaction Description is saved in a
DFF attribute and replaced when the transaction is corrected.
• Import Batch and Spreadsheet Files. This process starts with input files and ends with
validated 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 files
FTP their files to their own Unix directory. A Unix Autosys job runs periodically to move
input file from the originator’s Unix directory to a central directory. A Central user invokes a
concurrent request to import input files into JSA. This process loads batches into the JSA
Yale Tables, invokes the JSA validation extension, and loads batches into the GL Interface
Table. It provides feedback to the originator in the form of an e-mail message and a detail
report. The detail report is placed in the originator’s Unix directory.
• On-Line Journal Correction. The native GL Journal Entry Form is used to correct invalid
transactions. It is the responsibility of the originator of the batch to correct errors - 300
different people use this form. JSA users are identified by the two specific responsibilities
that 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 form
for JSA users. These modifications are:
• LOV of Batch Names altered to contain only batches where Organization in Batch Name
matches User’s 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 Journal
Categories headed to PA/GA, “Balancing Segment” is set to “00”.
• User can optionally display only invalid lines, using standard Find functionality.
8/16/00 Page 10
JSA Batch Header Form:
JSA Journal Header and Detail Lines:
8/16/00 Page 11
JSA Segment Value Entry:
JSA Descriptive FlexField Entry:
8/16/00 Page 12
• Manually Entered Transactions. The native GL Journal Entry Form is also used to
manually input JSA Batches. The custom library Form modifications described above also
apply to new Batches.
• Transaction Approval. The native GL Journal Posting Form is used to support Approval of
a Batch. It is the originating department’s responsibility to approve each batch. The
“Approval” action physically results in posting of the 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 user’s
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 extracted
from 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/GA
Categories, “approved” batches are extracted from JSA, reformatted, and loaded into the PA
Interface Table.
PA/GA does not have enough DFF attributes to store all of the JSA data, due to GA
restrictions. Therefore, transactions are not deleted from the JSA set-of-books. The JSA
Header 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 their
JSA Batches. A separate template is provided for each JSA Journal Category, to assist the
user in providing accurate and complete data.
10. Remaining Problems

• If you input the wrong Organization as part of your Batch Name, you can’t view the batch!
You don’t 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 valid
when 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 when
invalid. 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.
8/16/00 Page 13
12. Custom Programs and Tables – Detail
Registration Table and supporting functionality

A Registration function was created to support identification of and communication back to the
originators of batches. All business units using JSA must be pre-registered. Table
yugl_ext_sys_registration contains the originating business unit’s “Source System Name”, which
is used in the input file naming convention and in the batch naming convention. It also contains
technical and functional contacts. The technical and functional person ids, tech_person_id and
func_person_id, stored in this table are the link back to the table hr.per_people_f that allows the
system to obtain the e-mail addresses for these contacts. In the event that the functional or
technical e-mail address cannot be obtained by the system at runtime a default e-mail address is
used.
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 they
have access to are stored in the YAS system. This data was used in JSA to restrict access to JSA
Batches. On-line JSA users can see only batches for which the Batch Name Organization is
within 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 validation
rules are enforced, including specific validation rules for the various Journal Categories. The
standard PA validation program, patc.get_status is called to enforce PA/GA validation rules. Yale
has 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 the
import process for Batch and Spreadsheet files. It is called via custom.pll when a transaction is
updated using the on-line form.
8/16/00 Page 14
To facilitate correction of invalid transactions, the validation routine stores the invalid segment
values and the error messages in the Transaction Description. It saves the original Transaction
Description 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 the
user, and the Transaction Description is an easily accessible location that can be referenced by the
“Find” functionality of the Journal Entry Form. When the transaction is corrected, the original
Transaction Description is restored.
Sample Error Messages:
Message Message Text

Number
2120 The object code you selected is not available for this journal category. Please
verify 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 this
transaction.
2210 The fiscal period must be in the correct format DD_MON_YYYY and it must be
in an open accounting period.
Import Batch and Spreadsheet Files

Externally generated files are placed on the data collection server (SAL) with the file extension
TRN. A UNIX shell script, YUGLSTGD.prog, is invoked as a concurrent process and is the driver
for file capture, Yale JSA Staging Table load, Yale JSA Staging Table pre-validation, GL
interface load, and GL interface validation processes. The shell script will ‘look’ for the data files
with the TRN extension under the path $SOFTPATH/yugl/data. Data files that exist in this
directory will have their extension changed to RCV by the shell script to indicate that the file has
been received. The shell script will then insert the data filenames into a control file called
GLI.DAT. This control file holds the names of all the external files on SAL that need to be loaded
into the Yale JSA Staging Tables. The shell script then reads each file named in GLI.DAT and
then calls the appropriate routines to load and pre-validate the data in the Yale JSA Staging
Tables. Once all the files in GLI.DAT have been loaded and pre-validated, the shell script will
call 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 additional
validation 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 append
header and group id’s to each record in the file. This pre-processing is performed with the UNIX
utility AWK. The awk program file used to perform this pre-processing is called
yugl_stg_load.awk. In the event of a failure during this pre-processing, an Invalid Batch Report is
generated with a file extension of RPT. Otherwise the UNIX driver invokes SQLLOAD to load
the file. The SQLLOAD control file, yugl_stg_load.ctl, defines the loading of data to both the
yugl_staging_header and yugl_staging_lines tables. In the event that an error occurs during the
SQLLOAD process an e-mail message is sent to the technical and functional contacts that are
registered for this file’s 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.
8/16/00 Page 15
During the AWK and SQLLOAD processes, various fields are populated with data values that are
not 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_seq
group_id * sequence gl_interface_control_s
header_status constant ‘LOADED’
YUGL_STAGING_LINES
header_id * sequence yugl_header_seq
group_id * sequence gl_interface_control_s
journal_line sequential line counter
status constant ‘NEW’
set_of_books_id constant ‘2’
currency_code constant ‘USD’
date_created system date formatted DD-MON-YYYY
created_by value of batch_organization
actual_flag constant ‘A’
user_je_source_name constant ‘Yale External’
reference7 constant ‘NO’
reference1 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 then
initiate the validation procedure, yugl_stg_validation. The fields that are checked and the criteria
for validation is as follows:
• Date Fields: batch_date, fiscal_period, accounting_date, and transaction_date. All fields
that 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 also
checked for successful conversion to a date datatype. The accounting_date is checked to
verify 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 system
date. 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 being
captured as character data types, it is necessary to verify that all fields that will eventually be
converted 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 is
performed to verify that each detail record has exactly one entry in either the entered_cr or
entered_dr field, but not in both. To further validate the batch, running totals are calculated
for the entered_cr and entered_dr for comparison with each other and for comparison with the
value 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, is
validated against the entries in the table gl_je_categories. In addition, each subsequent
record’s 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 numeric
digits and if it passes that check the function yugl_valid_org_unit_fcn is called to verify that it
is a valid batch organization.
• Duplicate Batch: The values in batch_organization, batch_source, batch_date, and
batch_seq_no are checked against the existing records in yugl_staging_header to see if this
batch has already been received and processed.
8/16/00 Page 16
Whenever these validation checks fail, the appropriate error message is written to the offending
record and the header_status is set to ‘FAILED’.
Batch acceptance/rejection
Once the validation checks have completed, the Invalid Batch Report is generated. This report
lists 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, journal
category, and the accounting date. If no errors were found then this file is empty. In all cases an
e-mail is generated and sent to the Source System’s Functional Contact indicating whether the
staging load and validation process was successful or if it had failed. In the latter case an e-mail
message is also sent to the Source System’s Technical Contact and gives more details regarding
the 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 Accounting

Status Org. Source Batch Date Seq# Line No Category Date
______ ___________________________________ ________ ______________ ___________
______________________________________________________________________________
FAILED 666019-MCPOSI-26-Oct-1998-1234 1 YIntDptTrsf 25-Oct-1998
Invalid Journal Category.
FAILED 666019-MCPOSI-26-Oct-1998-1234 2 YIntDptTrsf 25-Oct-1998

Invalid 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 -0500
From: Jane Smith <jas34@ralph.its.yale.edu>
To: john.doe@yale.edu
Subject: GL Staging Loaded
FILENAME: GLITESTHM23OCT19980003.LDR
VALIDATION 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 <jas34@ralph.its.yale.edu>
To: john.doe@yale.edu
Subject: GL Staging Error
FILENAME: GLITESTHM21OCT19980005.LDR
ERROR: 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 “NEW”
CURRENCY_CODE “USD”
ACTUAL_FLAG “A”
8/16/00 Page 17
SEGMENT1 “02”
REFERENCE7 “NO”
REFERENCE22 Data contained in Reference10
REFERENCE27 Total Debit Amount for the Batch
Import to JSA Staging Area

Oracle Corporation has provided the software that import records from the GL_INTERFACE
table into the GL_JE_BATCHES, GL_JE_HEADERS, and GL_JE_LINES table. The Import
process requires two parameters. The first is the user_je_source_name, which is Yale External for
all JSA Batches. The second parameter is group_id, which is assigned a value during the
SQL*LOADER process. A concurrent process is submitted which calls the native GL IMPORT
PROCESS routine.
Load of Batch Control Amounts

The concurrent process submits a job that updates the control total field in the GL_JE_HEADER
table. This is accomplished by taking the value in the total_debits field in the
YUGL_STAGING_HEADER table and assigning it to the control total field in the
GL_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 eliminate
trailing 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 is
modified 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 Journal
Categories 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') THEN

yugl_new_form_instance(v_form_name);
END IF;
IF (event_name = 'WHEN-NEW-ITEM-INSTANCE') THEN

yugl_new_item_instance (v_item_name);
END IF;
8/16/00 Page 18
-- Validate that the first six characters of the batch name are a
valid 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/2000
COPY (v_batch_attribute1,'BATCH.ATTRIBUTE1' ); -- rk06/12/2000
IF 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' THEN
FND_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 which

returns 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);
8/16/00 Page 19
Journal Line Correction
To correct a transaction on-line, the user navigates to Enter Journal. The Find Journals screen
appears. The user inputs the batch 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 that requires correction. The user navigates to the line containing the
error and makes the necessary correction(s). At this point, the user has two options. Option 1 is to
commit the changes that were made. This causes the WHEN-VALIDATE-RECORD to fire and
the record is re-validated, using custom.pll logic. If no errors are found, the error messages in the
description box disappear and the original description is displayed. Option 2 is to navigate to
another 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 the
original description is displayed.
In either scenario, if more errors or additional errors are found during the validation process, the
error 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 occur
while 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 Business
Rules validations are called through the use of custom.pll. When the user moves from one record
to another or leaves the form, the event “WHEN-VALIDATE_RECORD” trigger is fired. During
this event, the common validation routine is called and the data is validated against the Yale
Business Rules. These are same validation rules that are called during the import of batch files
and spreadsheets.
Displaying only Journal Lines in Error

In order to display only those records in error, the user must do the following, after selecting the
Batch:
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 is
accomplished using custom.pll.
Journal Batch Deletion

Only unposted batches can be deleted. To delete a Batch, first select the batch. The box to the
left of the Batch Status is highlighted. Click on the big RED X icon. A Decision Box is displayed
with the following message: “Do you want to delete the entire batch or just the current journal
entry?”
Click the BATCH button
Press the icon that looks like a diskette. This issues the commit. The Deletion has officially
occurred.
Journal Batch Corrections

Control totals are being captured at the Batch level. If a record gets added or deleted from the
batch, 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
8/16/00 Page 20
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 to
modify, and presses the Review Batch button. The Batch screen appears and the user can modify
the 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 the New 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 the Journals button. The
Journal 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 (add
record) or scroll to the end of the file, using the down arrow key. Regardless of which
method is used, the system is ready to accept a new transaction line. Each transaction is
validated as it is input. After inputting all of the transactions, the user must hit the diskette
icon 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 originating
department’s responsibility to approve each batch. The “Approval” action physically results in posting of
the 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 user’s
responsibility 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 “YUGL
Staging 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 thereof
followed by the %, in the Batch field. Press the Find button.
3) To select the batch you want to approve, click on the box to the left of the period field. If the
record 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 more
invalid transactions and it cannot be authorized. All validation errors have to be corrected
before 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 custom
program is used to do this. It extracts transactions from the JSA set of books in the GL Journal
8/16/00 Page 21
Batches, Headers and Lines tables and inserts them into the GL Interface Table or the PA Interface
Table. 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 be
maintained 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 the
JSA GL Header ID concatenated to the JSA GL Journal Line ID.
There are currently five journal categories which require the creation of expense transactions in
OGM. These are ‘YInterDeptTrsf’, ‘YExpenseAdjust’, ‘YProcard’, ‘YGCCostTrsf’,
‘YRevAssement’.
The package YUPA_glintrfc_pkg (filename YUPAGLNTRFC.pkg) creates transactions in the PA
interface table from the JSA GL Journal Lines. The procedure load_ogm_interface receives a
batch 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 table
PA_Transaction_Interface_All. The process passes back a return code, and an error message if a
processing 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 fall
into one of 4 buckets: less than or equal to 2 weeks old, between 2 and 3 weeks old, Between
3 and 4 weeks old, and more than 4 weeks old.
Spreadsheet Templates
An Excel Spreadsheet Template exists for each Journal Category, to facilitate input of
transactions. The template contains properly formatted columns for all of the data elements
available 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 then
FTP’d to a Unix directory, exactly as is done for a batch file. Processing of Spreadsheet files is
the same as processing for Batch files.
8/16/00 Page 22
13. Appendices
Yale Registration Table Layout

YUGL_EXT_SYS_REGISTRATION
appl_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 Layout
YUGL_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_LINES
HEADER_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)
8/16/00 Page 23
ENTERED_DR VARCHAR2(38)
ENTERED_CR VARCHAR2(38)
ACCOUNTED_DR VARCHAR2(38)
ACCOUNTED_CR VARCHAR2(38)
TRANSACTION_DATE VARCHAR2(11)
REFERENCE1 VARCHAR2(100)
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)
8/16/00 Page 24
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)
8/16/00 Page 25

PA - Consistent Journal Entry For Projects-Grants Management

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

PA - Consistent Journal Entry For Projects-Grants Management

Uploaded by

Copyright:

Available Formats

Consistent Journal Entry for Projects/Grants Management

and General Ledger

Copyright @ 2000 by Joyce Lush

Transaction Type Number per

Yale’s General Ledger chart of accounts is:

Segment Value Set

Yale’s Oracle Projects / Grants Accounting chart of accounts is:

Segment Source of Values Relationship

4. Requirements for Transaction Entry

5. GL and PA/GA Standard Oracle Functionality

Process Flow – Import Batch or Spreadsheet File

Import Batch or Spreadsheet File

Process Flow – Transaction Correction, Manual Entry and Approval

Transaction Correction, Manual

Entry and GL Journal

Approval Entry Form

Process Flow – Transfer to Operational Set of Books

Transfer to Operational Set of

Bold - visible to Distributed User

8. GL Setup for Staging Area Set of Books

Segment Source of Data

9. Custom Programs and Tables – Summary

JSA Journal Header and Detail Lines:

JSA Descriptive FlexField Entry:

10. Remaining Problems

11. Remaining Opportunities

12. Custom Programs and Tables – Detail

Registration Table and supporting functionality

Yale Authorization System (YAS)

Message Message Text

Import Batch and Spreadsheet Files

Batch Batch Batch Journal Journal Accounting

FAILED 666019-MCPOSI-26-Oct-1998-1234 2 YIntDptTrsf 25-Oct-1998

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

Sample e-mail messages:

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

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

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

Population of Missing Data Elements

Import to JSA Staging Area

Load of Batch Control Amounts

Eliminate Trailing Spaces in the GL_JE_LINES Description field

On-line Transaction Correction

Custom.pll Code Example

IF (v_form_name = 'GLXJEENT') THEN

IF (event_name = 'WHEN-NEW-FORM-INSTANCE') THEN

IF (event_name = 'WHEN-NEW-ITEM-INSTANCE') THEN

PROCEDURE yugl_new_form_instance(i_form_name IN VARCHAR2) IS

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

-- Call the stored procedure to build the SELECT statement which

Journal Line Validation

Displaying only Journal Lines in Error

Journal Batch Deletion

Journal Batch Corrections

Manually Entered Transactions

Transfer to the Operational Set of Books

Yale Registration Table Layout

Yale JSA Table Layout

You might also like