The Budget Query Report displays the current balances of your account on the Account Summary page and the transactions of the account on the Account Transaction page. Before describing the reports themselves, there are a few terms you should know as follows:
Chart of Accounts. The complete list of account names and numbers used by an organization
General Ledger. The accounting record book that shows all the transactions for all accounts used by an organization
Actual Entries. Expenditures
Encumbrance Entries. In government accounting, an encumbrance is an anticipated expenditure, or funds restricted for anticipated expenditures, such as for outstanding purchase orders
Balancing Entries. A General Ledger transaction (often automated) that moves dollars from one account to another, for example from a budget account to a cash account.
Reference Material. For a dictionary of accounting terms, try http://www.ventureline.com/glossary.asp.
Account Summary page reads from the account balances table in Oracle Financials. The account balances table holds a summarized balance for each account in DePauw's chart of accounts, and each balance is recalculated when new transactions are posted to the General Ledger. As for the Account Summary Report, what you see is what you get. The data on the report is that actual data from the balances table.
Account Transaction page reads directly from the Oracle General Ledger table including GL Header and GL Lines. The Account Transaction Report is filtered extensively in order to eliminate unnecessary information overload as a result of expired encumbrance entries as well as balancing entries.
The following filters apply to transactions:
Journal Sources Filter.
3 DPU Budget Load. The source used to load budgets at the beginning of the year.
14 DPU Legacy Balances. The source used to load the original balances from Legacy into Oracle.
16 DPU Budget Transfers. The source used to move money from one account to another.
17 DPU Interfund.
Budget Journal.
A,E Type Filter. Only Actual or Encumbrance Entries are displayed.
GetActivityFilter. For Journal Sources Purchasing and Accounting. Transactions are summed for these sources. If the sum equals zero, then we know that the balancing entries have been posted and the transactions do not need to be displayed.
FilterPORowNumbers. As an item moves through the system, it is encumbered at the purchase order level, then un-encumbered and re-encumbered at the invoice level. This filter tests for the purchase order encumbrance and un-encumbrance. If the transaction totals equal zero, then the item is filtered out.
FilterPOAPRowNumbers. In some occasions the item is encumbered at the purchasing level and balanced at the accounts payable level. If the transaction totals equal zero, then the item is filtered out.
FilterAPRowNumbers. As an item moves through the system to the invoice level, it is encumbered, then at the payment level, it is un-encumbered and re-encumbered until paid. This filter tests for the payables encumbrance and un-encumbrance. If the transaction totals equal zero, then the item is filtered out.
NOTE: When all of the filters have been applied, only open encumbrances and payments should appear on the Budget Query Report with one exception. Sometimes, the invoice sent by a vendor will not match a Purchase Order total. If this is the case, then you will see the encumbrances from the Purchase Order as well as from the Invoice. When you compare the numbers, you can see the discrepancy between the two.
We're not done. The General Ledger payment entry does not contain a very helpful description for the researcher. The description is "Journal Import Created." Several additional steps are required, therefore, to un-filter the payment rows and obtain information that would help a researcher understand a transaction as follows:
Date Matching: Because the payment and balancing entries are automated transactions, they appear in the General Ledger at exactly the same second. The payment is compared to the balancing entries, which are then used to find the payment information.
Invoice Id: The first item that is traced is the Invoice Id. This number is used to find the Vendor Name and the vendor's Invoice Number.
PO Header Id: The Invoice Id is used to search through the PO tables to find the PO Header Id, which then leads to the PO Number.
DePauw Request Number: The PO Header Id is used to join seven tables together that make up the Purchase Order and the Requisition, which then leads back to the DePauw Request Number, which is the identifier of the requester's original transaction.
NOTE: There is not always a one-to-one correspondence between a PO Request and a Purchase Order, or a Purchase Order and a Payment, or a Check Request and a Payment. As a result, you may see groups of request numbers or vendors when payments are batched together. This is a result of the payment process and a normal function of the system.
For each line of the budget report, Zoom functionality has been developed to link back to the original requests.
Because of the request combinations on Purchase Orders or Accounts Payable Payments, an additional filter has been applied to the zoom. The filter tests to see whether the account number matches the account number on the request linked through zoom. If they do match, then the link is displayed. Otherwise, the link and description are not displayed.