°ÄÃÅÁùºÏ²Ê¹ÙÍø¿ª½±

Within the °ÄÃÅÁùºÏ²Ê¹ÙÍø¿ª½±, there are many entities that maintain separate databases to comply with management and business requirements. These databases may be a third party vendor system or an in-house system using a file/database structure such as Access, Paradox, or Dbase. The transfer of data from one of these external computer systems to the PeopleSoft General Ledger (PS G/L) is called a feed.

There are two types of feeds to the General Ledger, a MoCode feed and a Chartfield feed. Since a MoCode represents a string of chartfields and is only 5 characters long, many feeders store MoCodes in their system and use this type of feed. After the file is sent to the server, a conversion program takes the MoCode in each transaction, translates it into a chartfield string, and creates a journal entry. All of the MoCode feeds for one day are combined into one transaction file that is loaded into PeopleSoft each night.

A Chartfield feeder sends a file that has all chartfields listed in a predefined journal entry format. Separate processes are run each night to pick up each chartfield feed.

Because feeders transmit large amounts of information on a daily basis, it is imperative that data is correct when it is sent. Problems with missing data or bad file formats can cause the entire feed to reject. And since the MoCode feeds are combined into one file that loads into the General Ledger, an error in one feeder transmission may corrupt the entire file, causing all transactions for the day to fail.

Critical Errors known to halt the MoCode Feed:

• Invalid or missing dates – the date must be during the current month.
• Blank header records – happens when an "H" is in column 1, with no data following
• Blank journal line – happens when an "L" is in column 1, with no data following
• EOF indicator – there should be no End of File indicator in the feed
• Missing decimal in amount field – Amounts must be formatted with decimal points and cents field to two places
• Missing chartfield – account field left blank

Other errors can occur that do not impact the loading of files, but still create a substantial amount of work to resolve and clean up. Edits done before loading the files could significantly reduce these problems.

Other Errors found in Feeds:

• Invalid Accounts – Account is a 6-digit chartfield that must be defined and active in PeopleSoft. Most feeds would use the same list of accounts every time they create transactions, depending on the type of business they engage in. For example, a quick copy service should only have 3 accounts to choose from when charging customers (727100, 727200, 727300). Anything not in that list should be a red flag to examine.
• File layout in wrong columns – When uploading transactions, a predefined layout must be used. Being off 1 character will not reject the feed, but can cause edit errors for all chartfields that are off.
• Invalid or Inactive MoCodes – Typographical errors on MoCodes, such as using the letter O instead of zero, or having 6 characters instead of 5 will cause edit errors. A validation can be done against the speed chart table (SPEEDCHART_TBL) to validate the MoCodes before sending. See sample checklist attached for suggestions on how to query on this table.
• Duplicate or Bad Feeds – Sending a file multiple times or sending the wrong file will necessitate a cleanup effort by the feeder and the Campus Accounting office. If no lines on the journal have posted, the journal entry can be trashed. Otherwise, a reversing entry must be prepared by the feeder and sent to the General Ledger.

To prevent outages or significant clean up efforts, the following guidelines are being implemented, effective immediately. We hope this will provide a consistent approach for all business units when handling problems with data from feeders.

Addressing Critical Errors that stop all MoCode feeds from processing:

1st Offense – Send a test file to the Finance Technical Lead at AITS that can be successfully loaded.

2nd Offense - Send 3 test files to the Finance Technical Lead at AITS that can be successfully loaded and present, in writing, how the feeder plans to rectify the situation.

3rd Offense – Deny access to feed until the feeder comes up with a plan on how this situation will be avoided in the future, signed by their director and the campus Accounting Director. Send 3 successful test files to the Finance Technical Lead at AITS that can be successfully loaded before access is restored.

Addressing Other Errors that cause Cleanup Efforts by Campus Accounting and the Feeder:

1st Offense – Work with Campus Accounting office to correct errors.

2nd Offense - Work with Campus Accounting office to correct errors. Present, in writing, how the feeder plans to rectify the situation.

3rd Offense – Deny access to feed until the feeder comes up with a plan on how this situation will be avoided in the future, signed by their director and the campus Accounting Director. Send file to Campus Accounting office for review before access is restored.

As new operations are identified at the university or different systems are implemented, there will be a need to define additional feeds. Below are the procedures for requesting a new feed.

To Establish a New Feed:

• Submit request for a new feed to the Campus Accounting Office. This request must contain the feeder contact person(s), frequency of the feed, approximate number of transactions, and whether it is a MoCode or Chartfield feed.
• After approval from Campus Accounting Office, a new source code is defined by Controller's Office.
• Feeder owner works with AITS technical staff to determine the method of uploading the file (FTP or Web upload).
• Feeder must prepare and send 2 successful test files to AITS.
• Authorized personnel added to feeder security by Campus Accounting.

The ability to feed transactions is a privilege granted to those who have proven they will guard the integrity of data being transmitted to the General Ledger. If the integrity is compromised, this privilege will be denied until controls are in place to ensure the reliability of the information from this source.