Docsity
Docsity

Prepare for your exams
Prepare for your exams

Study with the several resources on Docsity


Earn points to download
Earn points to download

Earn points by helping other students or get them with a premium plan


Guidelines and tips
Guidelines and tips

Payment Voucher Processing and Accounting in AFS: A Comprehensive Guide, Schemes and Mind Maps of Accounting

Enterprise Resource Planning SystemsFinancial Management Information SystemsAccounting Systems and Software

An in-depth exploration of payment voucher processing and accounting in AFS (Advanced Funds Management System). Topics covered include marking payment vouchers for electronic funds transfer, logic tests on payment voucher amounts, accounting models and ledgers, open voucher tables, manual warrants, vendor lien/levy processing, and backup withholding. The document also discusses the importance of maintaining financial records and the role of various open item tables and ledger files.

What you will learn

  • What is the difference between payment vouchers and manual warrants?
  • What are the logic tests performed on purchase order line amounts?
  • What are the criteria for payments to incur backup withholding?
  • How are open purchase orders and payment vouchers maintained in the system?
  • How is vendor lien/levy processing handled in the system?

Typology: Schemes and Mind Maps

2021/2022

Uploaded on 09/07/2022

zaafir_ij
zaafir_ij 🇦🇪

4.4

(60)

888 documents

1 / 100

Toggle sidebar

Related documents


Partial preview of the text

Download Payment Voucher Processing and Accounting in AFS: A Comprehensive Guide and more Schemes and Mind Maps Accounting in PDF only on Docsity! TABLE OF CONTENTS ISIS/AFS USER GUIDE, VOL. II (07/03) 2 - i Chapter 2 - Expenditure Accounting Overview ................................................................................... 2-1 Definition of Terms................................................................... 2-3 Key Concepts ........................................................................... 2-4 Referencing Facility..............................................................................2-4 Open Item Tables.................................................................................2-5 Open Item Ledgers ..............................................................................2-6 Other Tables ........................................................................ 2-7 Canceling Expenditure Transactions ...................................................2-7 Accounting Basis for Expenditure Processing .....................................2-7 Account Code Structure .......................................................................2-8 Budgetary Controls ..............................................................................2-9 Obligations .........................................................................................2-10 Organization, Activity, and Function Controls ....................................2-10 Check Cash Indicator.........................................................................2-12 Prior Document Reference Option .....................................................2-12 Prior Year Encumbrances ..................................................................2-12 Vendor Related Research..................................................................2-13 Vendor Controls2-14 • Vendor Control Option....................................................2-14 • Miscellaneous Vendor Code...........................................2-14 • Other Vendor Information ...............................................2-14 • Vendor Alternate Addresses...........................................2-15 • Purging Old Vendors ......................................................2-15 Requisitions............................................................................ 2-15 Logic Tests.........................................................................................2-16 Accounting Model and Ledger ...........................................................2-16 Open Requisition Inquiry....................................................................2-17 Purchase Orders .................................................................... 2-19 Reopening Closed Purchase Orders .................................................2-19 Logic Tests on Purchase Order Amounts ..........................................2-20 Accounting Model and Ledger ...........................................................2-20 Tables ................................................................................................2-21 Internal Purchases .............................................................................2-24 Purchase Order Transaction ..............................................................2-25 TABLE OF CONTENTS 2 - ii ISIS/AFS USER GUIDE, VOL. II (07/03) Payment Vouchers2-26 Issues & Concepts .............................................................................2-27 • Scheduled Payment Date & Payment Lag .....................2-27 • Partial and Final Payments Against Purchase Orders ...2-27 • System Tolerance Logic on Purchase Order • Closing Amounts ............................................................2-28 • Refunds ..........................................................................2-28 • Credit Memos .................................................................2-29 • Discounts........................................................................2-30 • Marking Payment Vouchers for Electronic Funds • Transfer ..........................................................................2-32 Logic Tests on Payment Voucher Amounts .......................................2-32 Accounting Model and the Ledgers....................................................2-33 Tables ................................................................................................2-34 • Open Voucher Tables.....................................................2-34 • Open Vendor Invoice Header Inquiry .............................2-36 Payment Voucher Transaction...........................................................2-38 Vendor Payment Voucher ..................................................................2-40 Quick Payment Voucher ....................................................................2-40 Internal Vouchers ...............................................................................2-41 Accounting Treatment of Internal Vouchers.......................................2-42 Recurring Payment Vouchers ............................................................2-43 • To Date Parameter .........................................................2-44 • Document IDs.................................................................2-45 • Selection Examples ........................................................2-45 Manual Warrants .................................................................... 2-47 Check Cash Indicator and Manual Warrants .....................................2-47 Logic Tests on Manual Warrant Amounts ..........................................2-48 Accounting Model and Ledger ...........................................................2-48 Tables ................................................................................................2-49 Manual Warrant Transaction..............................................................2-50 • Referencing a Payment Voucher....................................2-51 Automated Disbursements.................................................... 2-53 Voucher Preselection .........................................................................2-54 Payment Voucher Scheduling............................................................2-57 Disbursement Parameters .................................................................2-58 Voucher Selection ..............................................................................2-58 Check Printing and Tape File Creation ..............................................2-61 Cash Disbursement Outputs ..............................................................2-62 The Check Stub and Checkstub (STUB) ...........................................2-63 The Remittance Advice Form.............................................................2-64 Open Check Header and Line Inquiry................................................2-64 The EVFS Report for Fund Transfer Disbursements .........................2-66 EXPENDITURE ACCOUNTING ISIS/AFS USER GUIDE, VOL. II (07/03) 2 - 1 Chapter 2 - Expenditure Accounting This chapter describes the purchasing/disbursement cycle. It is organized as follows: • Overview • Key Concepts • Requisition (Exclusively handled through AGPS) • Purchase Order • Payment Voucher • Recurring Payment Voucher Facility • Manual Warrant • Automated Disbursements • Check Voids • Special Features -- Outstanding Check Reconciliation -- Lien and Levy Processing -- Backup Withholding -- Vendor 1099 Processing Overview The purposes of the expenditure module are: 1. To provide a mechanism by which managers can procure goods and services required to carry out their functions; and 2. To exercise control over spending and to account for the goods and services purchased for both financial and cost accounting purposes. The four accounting events represented in the expenditure process are: • Requisition (Pre-encumbrance). A request for procurement represents the intent to incur an obligation. Requests for procurement can be useful accounting information for internal management purposes. They are recorded in the accounting system as pre-encumbrances. They do not represent legal obligations of a government. Requisitions are exclusively processed in AGPS. • Purchase Order (Encumbrance). A purchase order in AFS may represent a reservation of an agency's budget for a particular purpose: for example, utility payments. They are reductions in the amount available for spending when budgetary controls are being used. • Receipt of Goods or Service (Expenditure). The acceptance of a delivery of goods or services by an authorized individual represents the initial point at which EXPENDITURE ACCOUNTING 2 - 2 ISIS/AFS USER GUIDE, VOL. II (07/03) liability for payment is incurred. Generally, liabilities are recorded on the basis of vendor's invoices. • Payment (Cash Disbursement). Generally, payment represents the liquidation of a liability and the final event in the purchasing process. In AFS, payment can be accomplished in one of three ways: 1) manually by issuing a manual warrant or check, 2) automatically through the use of the automated cash disbursement capability, or 3) automatically using the electronic funds transfer capability. Figure 2-1 shows these steps and the related accounting events in AFS. Figure 2-1 Purchasing & ACTION: Decision to Contractual Receipt of Goods Payment to Expenditure Purchase Commitment or Services Supplier Accounting Steps AFS DOCUMENT: Purchase Purchase Payment Manual Warrant Requisition Order Voucher or Automated Disbursement or EFT ACCOUNTING EVENT: Pre- Encumbrance Expenditure Cash Encumbrance Disbursement All four steps need not be recorded for every purchasing event; several different processing chains are supported in AFS to accommodate various accounting procedures, paper flows, and circumstances surrounding individual purchasing events. Figure 2-2 illustrates the processing chains acceptable in AFS and AGPS. Each step in the chain is explained in detail in subsequent sections of this chapter. The rest of this section discusses topics that apply generally to the expenditure process. EXPENDITURE ACCOUNTING ISIS/AFS USER GUIDE, VOL. II (07/03) 2 - 3 Figure 2-2 Alternative Processing CASH DISBURSEMENT Chains - Expenditure RECOGNITION OF RECOGNITION OF RECOGNITION OF AGAINST PREVIOUSLY Accounting PRE-ENCUMBRANCE ENCUMBRANCE EXPENDITURE RECOGNIZED EXPENDITURE Requisition ────> Purchase Order ──> Payment Voucher ──> Manual Warrant, AGPS Automated Disbursement or EFT Purchase Order ──> Payment Voucher ──> Manual Warrant, AFS or Automated Disbursement AGPS or EFT Purchase Order ──────────────────────> Manual Warrant AFS only Payment Voucher ──> Manual Warrant, AFS or Automated Disbursement AGPS or EFT Manual Warrant AFS Only Definition of Terms The following terms are used throughout this chapter: Closed Amount. The amount that has been closed to date against an open item (for example, the amount from a requisition that has been referenced on a purchase order). When the item is finally closed and no further activity is to occur against it, a closed date is assigned to the open item and the closed amount indicates that the total open item amount has been closed. Until the item has been closed, the expended amount will equal the closed amount. Committed Amount. The sum total of pre-encumbrances, encumbrances, and expenditures. Discount Type. A code used on payment voucher transactions to indicate that a discount may be taken against the line amount of the transaction if a corresponding cash disbursement is made within a specified number of days. Discount parameters, including number of days, are defined by discount type on Discount Type (DISC). Electronic Funds Transfer (EFT). A transfer of funds electronically from buyer to seller through bank notification. Encumbered Amount. The amount submitted on a purchase order document. EXPENDITURE ACCOUNTING 2 - 6 ISIS/AFS USER GUIDE, VOL. II (07/03) • Open items and partially closed items are not affected by the purge process. • Payment vouchers, purchase orders and requisitions which have been marked closed are removed from the tables based upon a date parameter as specified by OSRAP. For instance, the date parameter could be set so that all items which have been closed for more than 90 days are removed from the tables. Items can be removed from the tables based on different parameters. For instance, requisitions and purchase orders can be removed based on a different date parameter than payment vouchers. Also, requisitions and purchase orders from the Contract Financial Management System (CFMS) are purged on a different basis than the requisitions and purchase orders from AGPS and AFS. More information about the purge process can be found in the ISIS/AFS User Guide, Volume II, Chapter 5- Accounting Period Clearing and Closing. The contents of each open item table are explained later in this chapter under the section that addresses the transaction related to the specific table (for example, a discussion on Open Requisition Inquiry may be found in the section on Requisitions). Open Item All expenditure transactions are posted to the Current Detail General Ledger Ledgers (GENLED). In addition, open purchase orders and payment vouchers are also maintained in the following ledger files: • Open Purchase Order Ledger File (POOPEN) • Open Payment Voucher Ledger File (PVOPEN) These ledgers contain a separate record for each detail transaction (original entry) and for each modification made to the original entry, for purchase orders and payment vouchers. These ledgers also contain a separate record for each referencing transaction. For example, in the Open Purchase Order Ledger file, a Payment Voucher that references a Purchase Order is also stored in the Open Purchase Order Ledger. Any Manual Warrant or Automated Disbursement (check) that references a Payment Voucher is also stored on the Open Payment Voucher Ledger. These referencing transactions are stored in the appropriate Open Items Ledger until the Purchase Order or Payment Voucher is purged from the Ledger, at which time the referencing transactions are also purged from the Ledger. This provides a complete inception-to-date tracking capability on open purchase orders and payment vouchers for reporting purposes. More information on the purge process for the Open Items Ledgers can be found in the ISIS/AFS User Guide, Volume II, Chapter 5- Accounting Period Clearing and Closing. EXPENDITURE ACCOUNTING ISIS/AFS USER GUIDE, VOL. II (07/03) 2 - 7 Other Tables Besides the Open Items tables, other screens exist in AFS to summarize expenditure activity. Most of these tables are discussed in the Budgeting chapter (chapter 1) of this guide. Tables discussed in the budgeting section include: Expense Budget Inquiry (Extended) (EEX2), Expense Budget Summary Inquiry (Extended) (EESM), Organization Rollups by Object Code (OROC), Expenditure Summary Inquiry (ORGE), and Organization by Object Inquiry (EORG). (ORGE and EORG do not include continuing appropriations). All of these tables compare budgeted amounts with actuals. There are additional tables which show only actual amounts. They are: Object/ Sub-Object Inquiry (OBSO), Organization/Sub-Object Inquiry (ORSO), Reporting Category/Sub-Object Inquiry (RCSO), and Reporting Category/Object Inquiry (RCOB). All of these tables show actual Pre-Encumbered, Encumbered, and Expended amounts as of the previous business day (they are updated by a nightly batch process). More information on all of these tables may be found in the ISIS/AFS Online Features. Canceling Outstanding (open) purchase orders, and payment vouchers should be canceled Expenditure (closed) in AFS when it becomes known that a purchase is not going to be made. Transactions Canceling the transaction reverses the obligation and closes the item on the appropriate open item table. Canceling is achieved by "zeroing out" the line in the following manner: • Complete the header of the appropriate transaction input screen with the same document ID used on the original document, and an "M" in the action field. • Code the line to be canceled exactly as it exists in the open item table, including the outstanding line amount. Code a "D" in the increase/decrease column, which decreases the line amount to zero. (If a line has been partially cleared, it can only be decreased by the outstanding amount.) Accounting Basis AFS performs various functions that ensure proper expenditure accounting for Expenditure procedures. Processing • Users code only the expenditure line of an expenditure transaction on input documents (except for the payroll and certain journal voucher transaction types). AFS automatically generates the implied offset, or balance sheet, entry. The actual offset entries generated are listed in subsequent sections of this chapter. • AFS automatically closes a pre-encumbrance when an encumbrance is recorded against it. For example, in addition to the entry generated to offset the encumbrance, other entries are generated to reverse the original pre-encumbrance transaction. • Similarly, AFS automatically reverses an encumbrance and reserve for encumbrance when an expenditure is recorded against it. EXPENDITURE ACCOUNTING 2 - 8 ISIS/AFS USER GUIDE, VOL. II (07/03) • AFS performs a revenue/expenditure reconciliation on internal transactions. That is, when an internal payment voucher is processed, not only is the expenditure recorded against the buyer's fund, but the revenue is also recognized in the seller's fund. • A closed item may be reopened as long as the item is stored in the open items tables; a closed item remains in the table until it is purged off. Refer to the OSRAP Policy and Procedures Manual for the purge schedule on the open items tables. "Reopening" is accomplished with modifying transactions, coded just as if the transaction was still open. • A detailed audit trail of all accounting activity is always available. It exists on the Current Detail General Ledger (GENLED) for all open accounting periods. For closed periods, this data is available in the Closed Detail (CLSLED) ledger. Detail is also available on Online General Ledger Inquiry (OLGL). Data will remain on OLGL until purged off. Refer to the OSRAP Policy and Procedures Manual for the purge schedule. • Expenditures are obligated only once against the budget, and against appropriation balances. In addition, encumbrances and expenditures are made against balances at the earliest possible stage in the accounting chain. Funds are no longer obligated as soon as encumbrances or expenses are reduced. Merely transferring an expenditure from an encumbered to an expensed condition as a result of the chain of accounting events does not affect obligations, if all entries are for the same amount. However, transferring a pre-encumbrance to an encumbrance or expenditure always causes a change in obligations for the amount of the encumbrance or expenditure. • When the amount of an expenditure differs from its encumbrance balance, or when adjustments are made to encumbrance or expenditure balances, obligations are affected only by the net amount changed. Account Code Each expenditure accounting transaction must contain agency, organization, and Structure object of expenditure codes (or agency, fund and object of expenditure for capital outlay). AFS allows the coding and recording of accounting transactions in more detail than the budget, according to the government's conventions and cost accounting requirements. The level of detail of the budget is the minimum coding requirement on expenditure transactions. For example, you may budget expenses by agency but code expenditure accounting transactions by agency and organization, or you may budget expenses by agency and organization but code expenditure accounting transactions by agency, organization, and object. EXPENDITURE ACCOUNTING ISIS/AFS USER GUIDE, VOL. II (07/03) 2 - 11 The Appropriation Organization Option is set to "A" in Louisiana for agencies’ funds, and "N" for capital outlay funds. The Expense Budget Organization Option has one of the following values: • "Y" means that an organization code is required on all expenditure accounting transactions. • "N" means that the organization code is optional. There are no organization codes in the expense budget (for this fund/agency). The Expense Budget Organization Option is set to "Y" for Louisiana for agencies’ funds, and "N" for capital outlay funds. The Expense Budget Activity Option has one of the following values: • "Y" means that activity codes are required on all budget and accounting transactions. • "A" means that activity codes are required on accounting transactions, but precluded on budget transactions. • "N" means that activity codes are optional on accounting transactions and precluded on budget lines. The Expense Budget Activity Option is set to "N" for both agencies’ funds and capital outlay funds. The Expense Budget Function Option has one of the following values: • "Y" means that function codes are required on all budget and accounting transactions. • "A" means that function codes are required on accounting transactions, but precluded on budget lines. • "N" means that function codes are optional on accounting transactions and precluded on budget transactions. The Expense Budget Function Option is set to "N" for both agencies’ funds and capital outlay funds. EXPENDITURE ACCOUNTING 2 - 12 ISIS/AFS USER GUIDE, VOL. II (07/03) Check Cash Besides budgetary controls, transactions which impact cash may also be subject to Indicator a Cash Check. The Check Cash Indicator is established for the appropriation and has three options: "C" (Cash [CASH]), "M" (the available cash for the appropriation), or "N" (no cash check). Cash balances on CASH and Appropriation Inquiry (Extended) (EAP2) are checked by the following documents: AD, CI, EF, II, J4, J6, MW, OC, PV, P1, PVQ, SN, and TR. If there is insufficient cash, the user will receive an error message. The Cash Check Indicator is explained in detail in Chapter 4 of the ISIS/AFS User Guide, Volume I. Prior Document The Prior Document Reference Option affects the way that you code transactions. Reference Option The option is chosen in System Control Options (SOPT), and is either "Y" or "N". Since this option is set to "Y" for Louisiana, it affects coding requirements in the following manner: • You do not have to code the accounting distribution on original entries when a previous document is referenced. For example, if a payment voucher references a purchase order, the fund, agency, object, etc., do not have to be coded on the referencing transaction. The system will infer the accounting distribution from the referenced document. If the accounting distribution is coded, all codes must match the codes on the referenced document. More codes may be added to expand the accounting distribution. For example, optional codes such as sub-object may be added to the accounting distribution. • You do not have to code the accounting distribution on modifying transactions. For example, if a modification against a previously entered purchase order is entered, the fund, agency, object, etc., do not have to be coded. The system will infer the accounting distribution from the previously entered line. If the accounting distribution is coded, it must match the previously entered line. Previously entered codes in the accounting distribution cannot be changed and new codes can not be added on modifying transactions. (This is true whether the Prior Document Reference Option is "Y" or "N". If you want to change the accounting distribution, you must cancel the transaction and reenter it as a new line.) Prior Year In the State of Louisiana a payment voucher can include a reference to a prior year Encumbrances Purchase Order only with a multi-year appropriation. When expenditures refer to prior year encumbrances, the expenditure (payment voucher or manual warrant) may be coded exactly as it would normally be coded (referencing the previous year's Purchase Order), as long as the expenditure is less than or equal to the encumbrance amount. When the expenditure is equal to the encumbrance or is less than the encumbrance with a Partial/Final Indicator of "F", the prior year's encumbrance is closed. EXPENDITURE ACCOUNTING ISIS/AFS USER GUIDE, VOL. II (07/03) 2 - 13 AFS provides a special facility that allows you to liquidate outstanding purchase orders at year end for the prior fiscal year. All outstanding purchase orders, that have not been rolled previously, will be rolled into the new fiscal year. If a purchase order has been rolled before, it will be closed in the prior fiscal year, but not rolled into the new year. In the State of Louisiana, regular appropriation purchase orders are rolled over to the new year as part of the 8/14 close process. Vendor Related The AFS tables provide information that can be valuable for researching vendor pay- Research ment problems, analyzing purchasing trends, and complying with governmental reporting requirements. The tables offer the following types of information: • Vendor (VEN2) records vendor codes. Vendor codes are exclusively entered on the AGPS Common Vendor Screen (VENC). A vendor's complete name and address is stored on Vendor (VEN2) in AFS to be available for reports, and for the automated check-writing activity. • Open Purchase Order Header Inquiry (OPOH), Open Purchase Order Line Inquiry (OPOL), Open Payment Voucher Header Inquiry (OPVH), and Open PV Line Inquiry (OPVL) all have vendor as their first key field. This permits online table searches on vendor code. • Open Payment Voucher Line Inquiry (OPVL) contains a last check number field and a last payment date field. Open Purchase Order Line Inquiry (OPOL) contains a last voucher reference number field and a last voucher reference date field. This information facilitates immediate online research for questions from vendors concerning payment. • Vendor (VEN2) includes a last action date field and a total expended amount field. This information can be used as an aid in purging unused vendors from the table and for assistance in vendor analysis. Vendor (VEN2) also includes a 1099 indicator, to mark vendors subject to 1099 processing. • Vendor Zip Code Inquiry (VZIP) displays vendors in vendor name, vendor zip code order. • Vendor Name Inquiry (VNAM) displays vendors in vendor name and vendor code order. • Alternate Vendor Name (VNA1) displays vendors on Vendor (VEN2) with a name in the NAME2 field, in alphabetic order. It also displays the name in the NAME field and the vendor code. EXPENDITURE ACCOUNTING 2 - 16 ISIS/AFS USER GUIDE, VOL. II (07/03) The transaction referencing a requisition line must have the same accounting distribution as that recorded on the requisition line, but amounts do not have to be the same. Logic Tests When either the Expense Budget Control Option, the Appropriation Category Control Option, or the Appropriation Control Option is "C" for full control, there must be funds available to cover the amount of the requisition or the requisition will be rejected. (Available amounts are stored in the budget tables.) Remember, however, that the available amount will not be reduced as a result of the requisition. When requisitions are being validated for compliance with budgetary controls, obligations are considered to be: PRE-ENCUMBERED + ENCUMBERED + EXPENDED AMOUNTS AMOUNTS AMOUNTS Accounting Model New requisition lines are posted to the Current Detail General Ledger (GENLED) and Ledger in the following manner: Dr Pre-encumbrances Cr Reserve for Pre-encumbrances The reserve for pre-encumbrances balance sheet account is inferred from System Special Accounts (SPEC). It cannot be overridden. The amount posted is the line amount from the requisition transaction. Figure 2-3 illustrates the accounting model for requisitions. EXPENDITURE ACCOUNTING ISIS/AFS USER GUIDE, VOL. II (07/03) 2 - 17 RESERVE FOR PRE-ENCUMB PRE-ENCUMB 11475 47511 BS ACCT FUND AGCY ORGN ACTV APPR OBJT ACCT TYPE AMOUNT Dr 100 100 0400 200 3100 20 $475 Cr 100 100 6705 03 $475 Ledger Updates: GENLED 11 Pre-encumber $475.00 of appropriation 100 to be used for paper supplies (object code 3100) within the specified fund, agency, and organization. Figure 2-3 Accounting Model for Requisitions An increase modifying transaction is posted as shown above. A decrease modifying transaction debits reserve for pre-encumbrances and credits pre-encumbrances. The pre-encumbrances and reserve for pre-encumbrances are not posted to budgetary or proprietary account balances. They are for information only. Open Requisition Lines are added to Open Requisition Inquiry (OPRQ) and Open Requisition Line Inquiry (OPRL) when new requisition transactions are accepted by AFS; lines are changed when modifications are submitted on these transactions. Requisitions are closed as purchase orders reference them. Requisitions will be closed for the amount of the referencing document, unless the document indicates a Final reference, in which case the entire requisition is closed. A requisition is considered cancelled when a requisition modifying document with a decrease line amount equal to the requisition line amount(s) is submitted in AGPS. Closed records are purged off OPRQ and OPRL based on a schedule defined by OSRAP. Requisitions from the Contract Financial Management System (CFMS) are purged on a different basis than the requisitions from AGPS. See OSRAP Policy and Procedures Manual for purge schedule. Figures 2-4 and 2-5 are sample screens from Open Requisition Inquiry (OPRQ) and Open Requisition Line (OPRL). EXPENDITURE ACCOUNTING 2 - 18 ISIS/AFS USER GUIDE, VOL. II (07/03) Figure 2-4 Open Requisition ACTION: . SCREEN: OPRQ USERID: Inquiry O P E N R E Q U I S I T I O N I N Q U I R Y RQ NUMBER= ... ........... RQ DATE: .. .. .. TOTAL RQ AMOUNT: .............. CLOSED DATE: .. .. .. CLOSED AMOUNT: .............. AGPS CREATED: . TOTAL OUTSTANDING AMOUNT: .............. Figure 2-5 Open Requisition ACTION: . SCREEN: OPRL USERID: Line O P E N R E Q U I S I T I O N L I N E REQ AGCY= ... REQ NO= ........... 01- LN NO= .. BFY: .. FUND: .... AGCY: ... ORGN: .... APPR: ......... ACTV: .... FUNC: .... RPTG: .... OBJT: .... SOBJT: .. RQ TYPE: . RSV ACCT: .... SELL FUND: .... SELL AGCY: ... BS ACCT: .... COMMENT: ............ RQ AMOUNT: .............. CLOSED AMOUNT: .............. OBLIG AMOUNT: .............. OUTSTANDING AMOUNT: .............. 02- LN NO= .. BFY: .. FUND: .... AGCY: ... ORGN: .... APPR: ......... ACTV: .... FUNC: .... RPTG: .... OBJT: .... SOBJT: .. RQ TYPE: . RSV ACCT: .... SELL FUND: .... SELL AGCY: ... BS ACCT: .... COMMENT: ............ RQ AMOUNT: .............. CLOSED AMOUNT: .............. OBLIG AMOUNT: .............. OUTSTANDING AMOUNT: .............. EXPENDITURE ACCOUNTING ISIS/AFS USER GUIDE, VOL. II (07/03) 2 - 21 FUND BALANCE RESERVE FOR ENCUMBRANCES RES FOR ENCUMB PRE-ENCUMB PRE-ENCUMB 1450 45011 2475 22475 BS ACCT FUND AGCY ORGN ACTV APPR OBJT ACCT TYPE AMOUNT Dr 100 100 0400 100 3100 21 $450 Cr 100 100 6615 03 $450 Dr 100 100 6705 03 $475 Cr 100 100 0400 100 3100 20 $475 Ledger Updates: GENLED, POOPEN 1 A purchase order is entered to encumber $450 of appropriation 100 within the specified fund, agency, and organization. 2 The purchase order references a prior requisition line, which had established a pre-encumbrance for $475.00. The pre-encumbrance is fully reversed and closed, even though the purchase order is for a lesser amount. Figure 2-6 Accounting Model for Purchase Orders The reserve for encumbrances balance sheet account is inferred from System Special Accounts (SPEC). It cannot be overridden. Decrease adjustments reverse the debit/credit codes indicated above. In addition, one entry is posted to the Open Purchase Order Ledger (POOPEN) for every purchase order transaction. Tables There are four open purchase order tables: • Open PO by Document Number Inquiry (OPOD) • Open Purchase Order Header Inquiry (OPOH) • Open Purchase Order Line Inquiry (OPOL) • PO by Account Distribution Inquiry (POAC) When a purchase order transaction is processed, a line is created in Open Purchase Order Line Inquiry (OPOL) for each line on the document. One line is also created in Open Purchase Order Header Inquiry (OPOH), containing summary data from the header portion of the document. If modifying transactions are accepted, the entries in the open item tables are updated to reflect the modifications. A separate record is also created in Open PO by Document Number Inquiry (OPOD) which contains only the key information of the purchase order ID and vendor code. This table is useful in locating purchase orders when the vendor code is not known but the purchase order number is. The user can scan this table until the appropriate purchase order and vendor combination is found. The user can then specify a leaf EXPENDITURE ACCOUNTING 2 - 22 ISIS/AFS USER GUIDE, VOL. II (07/03) action and the system will automatically leaf to the appropriate record on Open Purchase Order Header Inquiry (OPOH). Another record is created in PO by Account Distribution Inquiry (POAC) that contains key information of the accounting distribution, vendor code and transaction number. A purchase order line is considered closed when its outstanding amount is zero, or when it is "forced" closed with the final indicator on a subsequent referencing transaction. For example, a final payment voucher of $257.49 can force closed a $260.00 purchase order line. A record in Open Purchase Order Header Inquiry (OPOH) is closed when all of its related lines are closed in Open Purchase Order Line Inquiry (OPOL). When an open item record is considered closed, AFS adds the closing date and closing amount to the header record. When the purchase order is closed with a Partial/Final Indicator of "F", the purchase order closed amount is the purchase order line amount, regardless of the amount of the voucher or warrant causing the close. For example, if a purchase order line exists for $100, and a payment voucher closes the purchase order for $90, the purchase order closed amount is $100. However, AFS will decrease obligations by $10, and increase the unobligated account balance by $10. Closed purchase orders are purged from the tables based on a schedule defined by OSRAP. Purchase orders from CFMS are purged on a different basis than the purchase orders from AGPS and AFS. See OSRAP Policy and Procedures Manual for purge schedule. At year-end, outstanding purchase orders for regular appropriations (non capital- outlay) for the year being closed can be rolled over to the new fiscal year. All outstanding purchase orders, that have not rolled previously, will be rolled into the new fiscal year. If a purchase order has been rolled before, it will be closed in the prior fiscal year, but will not be rolled into the new fiscal year. In the State of Louisiana, regular appropriation purchase orders are rolled over to the new year as part of the 8/14 close process. Figure 2-7 is a sample screen from Open Purchase Order Line Inquiry (OPOL). Figure 2-8 illustrates Open Purchase Order Header Inquiry (OPOH). Figure 2-9 is a sample screen from Open PO by Document Number Inquiry (OPOD). Figure 2-10 is a sample screen from PO by Account Distribution Inquiry (POAC). EXPENDITURE ACCOUNTING ISIS/AFS USER GUIDE, VOL. II (07/03) 2 - 23 Figure 2-7 Open Purchase Order ACTION: S SCREEN: OPOL USERID: Line Inquiry (OPOL) O P E N P U R C H A S E O R D E R L I N E I N Q U I R Y VENDOR= ......... PO NUMBER= ... ........... LINE NO= .. FUND: .... AGENCY: ... ORG/SUB-ORG: .... .. APPR UNIT: ......... ACTIVITY: .... FUNCTION: .... OBJ/SUB-OBJ: .... .. REPT CAT: .... JOB NUMBER: ........ PROJECT: ........ LINE AMT: .............. INTERNAL REF FUND/AGCY: .... / ... CLOSED AMT: .............. LAST REF TRANS NO: ................ EXPENDED AMT: .............. LAST REF TRANS DATE: .. .. .. OUTSTANDING AMT: .............. TEXT IND: . DESCRIPTION: .............................. Figure 2-8 Open Purchase Order ACTION: S SCREEN: OPOH USERID: Header Inquiry (OPOH) O P E N P U R C H A S E O R D E R H E A D E R I N Q U I R Y VENDOR= ......... PO NUMBER= ... ........... NAME: .............................. ALT ADDR: .. COMMENTS: ............ BUDGET FY: .. OFFSET RESERVE ACCT: .... TYPE: . PO DATE: .. .. .. PO AMOUNT: .............. CLOSED DATE: .. .. .. CLOSED AMOUNT: .............. AGPS CREATED: . OUTSTANDING AMOUNT: .............. EXPENDITURE ACCOUNTING 2 - 26 ISIS/AFS USER GUIDE, VOL. II (07/03) Figure 2-12 Sample Purchase FUNCTION: DOCID: PO 011 R-10005 Order (PO) STATUS: BATID: ORG: 000-000 OF 000 H- PURCHASE ORDER INPUT FORM PO DATE: 07 03 97 ACCTG PRD: BUDGET FY: 98 ACTION: E ORDER TYPE: 1 PART/FINAL: COMMENTS: VENDOR: 811540051 NAME: GAS AND ELECTRIC CO. INT IND: SELLER FUND: SELLER AGENCY: CALCULATED DOC TOTAL: DOC TOTAL: 770.00 LN REF RQ JOB NO NUMBER LN FUND AGY ORG/SUB APPR UNIT ACTV FUNC OBJ/SUB NUMBER -- ------------------ ---- --- ------- --------- ---- ---- ------- -------- TEXT RPTG UNITS DESCRIPTION AMOUNT I/D ---- ---- ------- ------------------------------ -------------- --- 01- 01 440 440 3200 200 2940 10 GAS UTILITIES 440.00 02- 02 440 440 3200 200 2940 AA ELECTRIC UTILITIES 330.00 03- Payment Vouchers A payment voucher authorizes the spending of money and initiates automated check writing or electronic funds transfers procedures. With the payment voucher, you record all information necessary for the system to create vouchers payable ledger entries. The payment voucher also schedules a specific payment date for the voucher, which is used by the cash disbursement activities. (The cash disbursement activities actually write the checks.) AFS provides four payment vouchers: the Payment Voucher (PV), the Vendor Payment Voucher (P1), the Quick Payment Voucher (PVQ), and the Internal Voucher (II). II transactions should be used for internal purchases and sales, as well as governmental refunds. P1 transactions are specifically designed for purchases or credits from outside vendors. The PVQ is a simplified version of the PV. A payment voucher document must be submitted if you want computer-printed checks produced by AFS. The alternative is to request a manual check, in which case the transaction must be recorded on a manual warrant document. If, after a payment voucher is submitted, the items recorded on it become urgent and a check must be written immediately, you can still write the check manually and record it on a manual warrant referencing the payment voucher. The manual warrant, in effect, closes the payment voucher, halting the automated check writing procedures for that payment voucher. Note: If the manual warrant is written for a partial amount, then the cash disbursement process will proceed using the remaining outstanding balance. EXPENDITURE ACCOUNTING ISIS/AFS USER GUIDE, VOL. II (07/03) 2 - 27 A purchase order usually precedes a payment voucher, although the payment voucher can be the first document in the expenditure accounting chain. The amount on a payment voucher that references a purchase order can be different from the amount on the referenced document (see the explanation of the partial/final indicator in the payment voucher coding instructions section). Issues & A scheduled payment date is stored in Open Payment Voucher Header Inquiry Concepts (OPVH) for every payment voucher when it is accepted. This date is either coded on the payment voucher document by the user or inferred from one of the tables, in Scheduled Payment order as follows: Date & Payment Lag • If a date is coded on the input document, that date is stored as the scheduled payment date. • System Control Options (SOPT) contains a default scheduled payment lag, to be used for any payment voucher, for any vendor, when no other date is specified, as noted above. The payment lag is the number of days from the voucher date on which payment should be made. The system calculates the scheduled payment date using this payment lag. The system payment lag is set to 30 days for Louisiana. • If the Schedule Discount Date option on System Control Options (SOPT) is set to "Y", the system calculates the optimum payment date for each payment voucher. This date is the last possible day on which the voucher can be paid, and all the discounts still taken. Partial and Final A payment voucher line that references a purchase order can expense the referenced Payments Against document line in full or partially. The partial/final indicator tells AFS whether to Purchase Orders close the purchase order line with this voucher or to keep it open for a future voucher. The valid values are: • "P" for Partial. This choice is optional. • "F" for Final. Follow the guidelines below. - if this payment voucher makes the total amount expended against the purchase order equal to the referenced line amount, then the referenced line will be closed automatically, and the "F" is optional. - if this payment voucher makes the total amount expended against the purchase order less than the referenced line amount, but you want to force a close anyway (the item didn't cost as much as expected), the "F" is required. EXPENDITURE ACCOUNTING 2 - 28 ISIS/AFS USER GUIDE, VOL. II (07/03) - if this payment voucher makes the total amount to be expended against the purchase order more than the referenced line amount (the item cost more than expected), the "F" is required. System Tolerance System Control Options (SOPT) contains a "Tolerance" field. The value entered in Logic on Purchase this field establishes a limit to the amount that can close a purchase order; for Order Closing example, a limit to the amount that can be written on a payment voucher or manual Amounts warrant that references a purchase order. This limit may be either a dollar amount or a percentage amount over the recorded purchase order amount and only applies to the final payment for a purchase order line. Using the tolerance percent, the maximum amount allowed to close a purchase order is: MAXIMUM AMOUNT = RECORDED + PERCENTAGE (USING THE TOLERANCE ALLOWED TO CLOSE PO AMOUNT PERCENT) OF RECORDED PO AMOUNT If you try to close a purchase order with an amount that exceeds this maximum amount, the closing transaction (either a payment voucher or manual warrant) will reject. A tolerance percent of zero means that the closing amount may not exceed the purchase order amount, while a tolerance percent of 99 means that the purchase order may be closed by almost twice its recorded amount. The Tolerance percentage in Louisiana is 10%. If tolerance is expressed as a dollar amount, the calculated percentage amount in the equation is replaced by the specified dollar amount. The Tolerance dollar amount in Louisiana is $0.00. Refunds Payment vouchers can be used to record refunds that the government pays to the public or to vendors. The refund refers to money which was previously recognized as revenue on a cash receipt. A common example is the tax refund. This type of transaction is recorded on a payment voucher because it represents a liability that must be paid. (Governmental refunds can also be recorded on manual warrants, if the refund is paid with a manually written check.) Code a refund as follows: • Use a revenue source code instead of an object code. • The line amount is the amount of the refund. • The payee is indicated by the vendor code or vendor name. EXPENDITURE ACCOUNTING ISIS/AFS USER GUIDE, VOL. II (07/03) 2 - 31 • If the day of the voucher date is greater than or equal to the discount day, the last possible payment date will be the nth day of the month following the month in which the voucher was entered, n being the discount day. If the check date falls prior to the last possible payment date, the discount is taken. Otherwise, it is not. For example, when a payment is processed directly in AFS, the user would enter a discount type using the DISC table as a reference. The user can schedule the payment for the automated disbursement process anytime within the discount period (taking into consideration a one day lag for the automated disbursement process) and the discount would be deducted from the vendor’s payment. (Example - payment entered in AFS 3/10/98 with a discount type A, 1% 10 days. If the payment’s schedule payment date falls within 3/10/98 and 3/19/98, a 1% discount will be deducted from the payment. To figure the maximum schedule payment date for this payment, the user would add 10 days to the voucher date minus one day for the one day lag.) Using the same scenario above, if the user does not enter the schedule payment date, the system will calculate the schedule payment date using the discount type and the voucher date. In the example, the payment was entered in AFS on 3/10/98, the system sets the schedule payment date as 3/20/98 based on a discount type A, 1% 10 days. The discount would be lost since payments with a scheduled payment date of 3/20/98 would run through the automated disbursement process on 3/21/98. The discount amount is calculated by applying the percentage in Discount Type (DISC) against the payment voucher line amount. When a discount is taken, the activity generates expenditure transactions that "refund" the discount amount back to the accounting distribution on the payment voucher line. (There is no special accounting distribution to collect discounts.) As a result of these system generated transactions, the expended amount fields in the budget tables are updated and detail ledger records are posted to GENLED. For cash disbursements, discounts taken are shown on the check stub. The check stub discount lines are summarized by vendor invoice number, within each payment voucher document. Since the voucher pre-selection activity does not consider discounts, scheduled payment amounts on the 1G06 and 1G25 reports may be different from the actual check or transfer amount. Sometimes the discount amount makes the difference between whether the government owes the vendor money or not. When this occurs, the vendor will be listed on the 1G06 or 1G25 reports, but no check is written or funds transferred by either process because no money is owed once the discount is taken. However, the next time the payment disbursement cycle is run, the discount may be considered lost, and a check will be printed because it is now perceived that EXPENDITURE ACCOUNTING 2 - 32 ISIS/AFS USER GUIDE, VOL. II (07/03) money is owed. To prevent this, the voucher should be reversed (with a decrease payment voucher), so it is considered closed. The Discounts Taken/Lost Report (1G24/1G28) should be periodically analyzed. If discounts are being lost on a regular basis, payment policies or discount types may need adjusting. Marking Payment For a vendor to receive payments through electronic funds transfer, the vendor must Vouchers for Electronic be set up on Electronic Funds Transfer (1 of 2) (EFTT) and Electronic Funds Funds Transfer Transfer (2 of 2) (EFT2) with a status of "A" (active). The EFT status on Vendor (VEN2) must also be active and is inferred from EFTT. The EFT IND on a payment voucher will default to "Y" when the vendor is EFT active. The application type is inferred from Agency (AGC2) and cannot be changed on the payment voucher. The EFT IND on the payment voucher can be changed from "Y" to "N" or from "N" to "Y". When changing from "Y" to "N", an overrideable error message will be issued which can only be cleared by users with the proper override authority. When changing from "N" to "Y", the vendor must be EFT active on VEN2 and EFTT, otherwise the document will reject. Logic Tests on Payment voucher transaction amounts are subjected to the following tests: Payment Voucher Amounts • When budgetary "full" controls are in effect, the unobligated balances must be greater than a new obligation or a net change in obligations. • A decrease transaction cannot reduce the payment voucher to less than the payment voucher closed amount. • The payment voucher cannot cause the amount expended against a purchase order to exceed the tolerance limits set recorded in System Control Options (SOPT) or Fund (FUN2). Accounting Model When a payment voucher transaction is processed by AFS, ledger records are posted and the Ledgers to the Current Detail General Ledger (GENLED), the Open Payment Voucher Ledger (PVOPEN), and the Open Purchase Order Ledger (POOPEN)- if a purchase order has been referenced. Due to the many uses of the payment voucher, one of several different accounting models may be used to record the accounting event. Figure 2-13 presents the accounting model used for a standard payment voucher referencing a purchase order. EXPENDITURE ACCOUNTING ISIS/AFS USER GUIDE, VOL. II (07/03) 2 - 33 Figure 2-13 Accounting Model for Payment Vouchers VOUCHERS RESERVE FOR EXPEND/EXPENSE PAYABLE ENCUMBRANCES ENCUMBRANCES 1751 1751 1952 1952 BS ACCT FUND AGCY ORGN APPR OBJT ACCT TYPE AMOUNT Dr 100 100 0400 200 3100 22 $175 Cr 100 100 6335 02 $175 Dr 100 100 6615 03 $195 Cr 100 100 0400 200 3100 21 $195 Ledger Updates: GENLED, PVOPEN, POOPEN 1 A payment voucher is entered to record an expenditure of $175.00 against appropriation 100 within the specified fund, agency, and organization. 2 The payment voucher references a purchase order (for $195.00), which had established an encumbrance. Since this is a final payment, the purchase order is closed and the encumbrance is fully reversed. Below are accounting models for other payment vouchers. • For a refund from an organization without an original fund: Dr Revenue Cr Liabilities (vouchers payable) If the organization is linked to an original fund, then the revenue is automatically transferred from the original fund to the final fund, as follows: Dr Revenue FOR ORIGINAL FUND Cr Assets (Cash) FOR ORIGINAL FUND Dr Assets (Cash) FOR ORIGINAL FUND Cr Expend. (Auto Transfer Out) FOR ORIGINAL FUND Dr Revenue (Transfers In) FOR FINAL FUND Cr Liabilities (vouchers payable) FOR FINAL FUND In all cases, the amount used is the payment voucher line amount. EXPENDITURE ACCOUNTING 2 - 36 ISIS/AFS USER GUIDE, VOL. II (07/03) Figure 2-15 Open Payment ACTION: . SCREEN: OPVH USERID: Voucher Header O P E N P A Y M E N T V O U C H E R H E A D E R I N Q U I R Y Inquiry (OPVH) VENDOR= ......... .. VOUCHER NUMBER= ... ........... NAME: .............................. ADDRESS: .............................. : .............................. CITY: .................. STATE: .. ZIP: .......... VOUCHER DATE: .. .. .. VOUCHER TYPE: . EFT IND/TYPE: . / .. SCHED PYMT DATE: .. .. .. BUDGET FY: .. HOLD PYMT IND: . OFFSET LIAB ACCT: .... FREIGHT IND: . CHECK CATEGORY: .. SINGLE CHECK IND: . VOUCHER AMOUNT: .............. TOTAL QUANTITY: ............ DISCOUNT AMOUNT: .............. FREIGHT AMOUNT: .............. WITHHELD AMOUNT: .............. TAX CODE: ... CLOSED AMOUNT: .............. USE TAX AMOUNT: .............. OUTSTANDING AMOUNT: .............. CLOSED DATE: .. .. .. AGPS CREATED: . LIEN/LEVY: . ACTUAL DELIVERY DATE: .. .. .. REMIT TO VENDOR: ......... .. REMIT TO AMOUNT: .............. REMIT TO VOUCHER: ........... Figure 2-16 Open PV by ACTION: . SCREEN: OPVD USERID: Document Number Inquiry (OPVD) O P E N P V B Y D O C U M E N T N U M B E R I N Q U I R Y VOUCHER NUMBER VENDOR =============== ============ 01- ... ........... ......... .. 02- ... ........... ......... .. 03- ... ........... ......... .. 04- ... ........... ......... .. 05- ... ........... ......... .. 06- ... ........... ......... .. 07- ... ........... ......... .. 08- ... ........... ......... .. 09- ... ........... ......... .. 10- ... ........... ......... .. 11- ... ........... ......... .. 12- ... ........... ......... .. 13- ... ........... ......... .. 14- ... ........... ......... .. 15- ... ........... ......... .. Open Vendor Invoice This table includes information from the line of the payment voucher transaction Header Inquiry and captures amounts associated with the invoice from the vendor which is coded on the payment voucher. Invoice numbers are required on payment documents (PVs, IIs, MWs). Invoice numbers must be unique statewide. EXPENDITURE ACCOUNTING ISIS/AFS USER GUIDE, VOL. II (07/03) 2 - 37 Entries are added to this table when new payment voucher transactions with an invoice number are accepted by AFS. Table entries are changed when modifications are submitted on these transactions. When an invoice number field is used on a payment voucher, an entry is added to Open Vendor Invoice Header Inquiry (OVIH). Lines are deleted from the table according to a schedule to be determined by OSRAP. Figure 2-17 illustrates Open Vendor Invoice Header Inquiry (OVIH). Figure 2-17 Open Vendor Invoice ACTION: . SCREEN: OVIH USERID: O P E N V E N D O R I N V O I C E H E A D E R I N Q U I R Y VENDOR= ......... .. TRANSACTION ID= .. ............ NAME: .............................. INVOICE DATE: .. .. .. FIXED ASSETS IND: . TYPE: . LAST REFERENCE NO: ... ........... CHECK DESCRIPTION: ........................... DISCOUNT TYPE: . AGPS CREATED FLAG: . ------------------ EPS ----------------- TOTAL LINE AMT: .............. DISC CODE: . DISC AMT: .............. FREIGHT IND: . TOTAL QTY: ............ FREIGHT AMT: .............. FREIGHT AMT: .............. TAX AMT: .............. TAX CODE: ... TOTAL INVOICE AMT: .............. USE TAX AMT: .............. PAYMENT VOUCHER AMT: .............. CLOSED DATE: .. .. .. EXPENDITURE ACCOUNTING 2 - 38 ISIS/AFS USER GUIDE, VOL. II (07/03) Payment Voucher Figure 2-18 is the AFS standard payment voucher (transaction code PV) input Transaction screen. See ISIS/AFS Online Features for coding instructions. Figure 2-18a PV Input FUNCTION: DOCID: PV Screen STATUS: BATID: ORG: H- PAYMENT VOUCHER INPUT FORM PV DATE: ACCTG PRD: .. .. BUDGET FY: .. ACTION: . PV TYPE: . ACT DEL DT: .. .. .. SCH PAY DATE: .. .. .. OFF LIAB ACCT: .... FA IND: . DOCUMENT TOTAL: .............. EFT IND: . APPLICATION TYPE: .. USE TAX AMT: CALC DOC TOTAL: VENDOR CODE: ......... .. CHECK CATEGORY: SINGLE CHECK FLAG: . VENDOR NAME: .............................. TAX CODE: ... ADDR1: .............................. ADDR2: .............................. ADDR3: .................. .. .......... FREIGHT IND: . FREIGHT TOT: .............. FREIGHT I/D: . TOTAL AMT: .............. TOT AMT I/D: . CALC TOT AMT: TOTAL QTY: ............ TOT QTY I/D: . CALC TOT QTY: SELLER: FUND: .... AGCY: ... ORG: .... SUB-ORG: .. APPR UNIT: ......... ACTV: .... FUNC: .... REV SRC: .... SUB-REV: .. JOB NO: ........ RCAT: .... OBJECT: .... SUB-OBJ: .. OFF REC ACCT: .... BS ACCT: .... Figure 2-18b PV Input FUNCTION: DOCID: PV Screen STATUS: BATID: ORG: 000-000 OF 000 LN REFERENCE COM VENDOR INV NO CD NUMBER LN LN INVOICE LN DESCRIPTION -- -- --------------- -- --- ------------ --- --------------------------- D SUB FUNC SUB REV SUB T FUND AGCY ORG ORG APPR UNIT ACTV TION OBJ OBJ SRC REV JOB NO - ---- ---- ------- --------- ---- ---- ------- ------- -------- BS REPT CAT ACCT QUANTITY I/D FREIGHT AMOUNT I/D AMOUNT I/D -------- ---- -------------- - -------------- - -------------- - TAX CODE TAX AMOUNT TOTAL AMOUNT P/F -------- -------------- -------------- - 01- .. .. ... ........... .. ... ............ ... .................. . .... ... .... .. ......... .... .... .... .. .... .. ........ .... .... ............ . .............. . .............. . ... . 02- .. .. ... ........... .. ... ............ ... .................. . .... ... .... .. ......... .... .... .... .. .... .. ........ .... .... ............ . .............. . .............. . ... . EXPENDITURE ACCOUNTING ISIS/AFS USER GUIDE, VOL. II (07/03) 2 - 41 Internal An Internal Voucher (II) transaction must be submitted to end the expenditure pro- Vouchers cessing chain for internal transactions. A manual warrant is not valid for internal transactions. The type of voucher field on the internal voucher header identifies the voucher as internal. Valid voucher types are "2" and "3". A Type 1 payment voucher is a normal vendor payment. No special posting occurs for Type 1 vouchers. A Type 2 payment voucher, which transfers money between different funds, posts appropriate accounting entries to the General Ledger for both the buyer and the seller (revenue and cash entries in the seller's fund, and expenditure and cash entries in the buyer's fund). Furthermore, if the seller's organization is linked to an original fund, additional postings are created to transfer the revenue from the original fund to the final fund. (See below). For Internal Voucher (II) transactions in the State of Louisiana, the cash account is determined in the following way: For the buyer: The cash account is inferred from Organization (ORG2) for the organization coded on the transaction. For the seller: The cash account is inferred Organization (ORG2) for the organization coded on the transaction. A Type 3 internal voucher, which transfers money to different accounts within the same fund, posts appropriate revenue and expenditure entries in the General Ledger. Cash lines are also posted within the fund. Furthermore, if the seller's organization is linked to an original fund, additional postings are created to transfer the revenue from the original fund to the final fund. (See below). Type 2 and 3 payment vouchers are also subject to a cash check at the time of processing. The Check Cash Indicator on Appropriation Inquiry (Extended) (EAP2) dictates where available cash will be determined when the transaction processes. This indicator is set for each appropriation individually. There are three options for this indicator: "C" (Cash [CASH]), "M" (the available cash for the appropriation), or "N" (no cash check). If there is insufficient cash, the user will receive an error message. For more information on the Check Cash Indicator, see Chapter 4 of the ISIS/AFS User Guide, Vol I. Internal payment vouchers are not stored in the Open Payment Voucher Tables. To change the results of a previously entered internal transaction, code a new internal voucher transaction using the batch modification process. EXPENDITURE ACCOUNTING 2 - 42 ISIS/AFS USER GUIDE, VOL. II (07/03) Accounting When internal vouchers are used, AFS ensures that both revenue and expenditure Treatment of entries from an intra-governmental purchase and sale are recorded simultaneously by Internal Vouchers generating both the invoice and voucher transactions. Accordingly, the AFS internal payment voucher can serve as the seller's invoice as well as the buyer's payment voucher. The specific accounting procedures are as follows: • Inter-Fund Vouchers. If the selling entity is in a different fund than the purchasing entity, the AFS voucher generates both revenue and cash entries in the selling fund, as well as the expenditure and cash entries in the buying fund. The default cash accounts are the accounts inferred through the organization code. If the seller's organization is linked to an original fund, additional postings are created to transfer the revenue from the original to the final fund. (See below). • Intra-Fund Vouchers. If the selling entity is in the same fund as the purchasing entity, the AFS voucher records revenue to the seller and an expenditure to the buyer. Cash lines to offset the revenue and expenditure lines are also automatically produced by AFS, using the cash account coded for each organization on Organization (ORG2). If the seller's organization is linked to an original fund, additional postings are created to transfer the revenue from the original fund to the final fund. (See below). The ledger postings produced by a type 2 or 3 internal voucher are: • If the seller organization does not use an original fund: For the Buyer: Dr Expenditures Cr Assets (Cash) For the Seller: Dr Assets (Cash) Cr Revenue • If the seller organization is linked to an original fund: For the Buyer: Dr Expenditures Cr Assets (Cash) For the Seller: Dr Assets (Cash) FOR ORIGINAL FUND Cr Revenue FOR ORIGINAL FUND Dr Expend. (Auto Transfer Out) FOR ORIGINAL FUND Cr Assets (Cash) FOR ORIGINAL FUND EXPENDITURE ACCOUNTING ISIS/AFS USER GUIDE, VOL. II (07/03) 2 - 43 Dr Assets (Cash) FOR FINAL FUND Cr Revenue (Transfer In) FOR FINAL FUND In all cases, the amount used is the payment voucher line amount. If the transaction is transferring money within a fund (a Type 3), the internal voucher is also required, but no check will be written, and a manual warrant is not allowed. Internal vouchers for intra-fund transfers are automatically closed as soon as they are entered in the system. (The internal voucher must be submitted to clear the purchase order and to effect the change in the budgeted balance for the fund/agency involved.) Recurring Payment The recurring payment voucher capability of AFS automatically generates trans- Vouchers actions on a monthly, bi-monthly, quarterly, or end-of-quarter basis using data that users have previously entered on Recurring Payment Voucher (REPV). The information is entered only once, along with starting and ending dates and an indicator controlling how often the transaction should be generated. An offline job actually generates the transactions and adds them to Document Suspense (SUSF). Users can then access the transactions in correction mode, change them if desired, and process them. This facility is useful for accounting events such as rent payments, utility payments, etc. Information is entered in Recurring Payment Voucher (REPV); see the ISIS/AFS Online Features for coding instructions. During table data entry, the data is validated to a limited extent. Codes are validated against the entry start date and fiscal year. However, no checks are made against budget tables. That type of validation occurs when the transactions are processed by the Payment Voucher (PV) document processor. Also note the following three points about entering data in Recurring Payment Voucher (REPV): 1) Since the user may not always know the exact line amount when the recurring information is being entered, the amount field may be left blank. If it is, the system places the words "FILL-IN" in the amount field to serve as a reminder that an amount is still required. You may enter the real amount in Recurring Payment Voucher (REPV) at a later time, or wait until the transaction has been added to Document Suspense (SUSF) and change it there. 2) You may enter incomplete previous document references. For example, you may enter the referenced purchase order document number without the line number. The reference can be completed either in Recurring Payment Voucher (REPV) or in Document Suspense (SUSF). 3) The Actual Delivery Date field and Vendor Invoice field of the created Payment Voucher will be left blank. These fields must be completed before. EXPENDITURE ACCOUNTING 2 - 46 ISIS/AFS USER GUIDE, VOL. II (07/03) Figure 2-22 - Recurring Payment Voucher Selection Examples To-Date To-Date To-Date To-Date Start End 01-01-95 02-01-95 03-01-95 03-01-95 Frequency Date Date Select Delete Select Delete Select Delete Select Delete PV-01 F 01-01-95 - Y Y - - - - - - PV-02 F 02-15-95 - N N N N Y Y - - PV-03 M 03-01-95 12-31-95 Y N Y N Y N Y N PV-04 M 01-01-95 03-01-95 Y N Y N Y Y - - PV-05 01-01-95 02-01-95* Y N Y Y - - - - PV-06 M 01-01-95 02-28-95* Y N Y N N Y - - PV-07 M 02-01-95 12-31-95 N N Y N Y N Y N PV-08 01-15-95 12-31-95 N N Y N Y N Y N PV-09 B 01-01-95 12-31-95 Y N N N Y N N N PV-10 B 01-15-95 12-31-95 N N Y N N N Y N PV-11 B 01-01-95 02-15-95 Y N N N N Y - - PV-12 Q 01-01-95 12-31-95 Y N N N N N Y N PV-13 Q 03-01-95 12-31-95** N N N N Y N Y N PV-14 E 01-01-95 12-31-95*** N N N N Y N N N * Note that when the ending date equals the to-date, the entry is selected (i.e., a document is generated in DDM for it) and then immediately deleted. However, when the ending date is after the current to-date (but before the next run's to-date), the entry is not deleted immediately. ** A frequency of "Q" means once per quarter, not every three months. Thus, the entry would be not selected for two succeeding months. It will not be selected again until the to-date is 07-01-85. *** A frequency of E means third month of each quarter. The above example for E assumes that 1/1/95 is the first month of a fiscal quarter and 3/1/95 is the third month of the same quarter. This entry would be selected again on 6/1/95, 9/1/95, and 12/1/95 and would then be deleted on 12/1/95. EXPENDITURE ACCOUNTING ISIS/AFS USER GUIDE, VOL. II (07/03) 2 - 47 Manual Warrants A Manual Warrant (MW) transaction records in the system checks that have been written manually. The manual warrant causes AFS to obligate a fund (if this has not already been done by a referenced document), and to adjust cash balance sheet accounts. One Manual Warrant (MW) transaction represents a single check. A manual warrant can be the first (and therefore only) document in the obligation chain. Usually, however, the manual warrant is preceded by purchase orders or payment vouchers. The appropriate purchase order or payment voucher must be a referenced on the manual warrant, so the appropriate lines can be updated on the open item tables. Amounts on manual warrants can be different from the amounts on referenced purchase orders or payment voucher lines. Most actions that can be performed on payment vouchers can also be done on manual warrants. The difference is that payment vouchers post to liability accounts, whereas manual warrants post directly to cash. The following discussions in the payment voucher section also apply to manual warrants: • "Vendor Discounts" • "Refunds" Manual Warrant (MW) documents are not allowed for vendors with a Lien/ Levy or Backup Withholding recorded against them. If a user attempts to process an MW against such a vendor, the document will reject and an error message will appear informing the user that the vendor is subject to a Lien/Levy or Backup Withholding. Check Cash The Check Cash Indicator on Appropriation Inquiry (Extended) (EAP2) dictates Indicator and where available cash will be determined when a transaction or automated Manual Warrants disbursement processes. This indicator is set for each appropriation individually. There are three options for this indicator: "C" (Cash [CASH]), "M" (the available cash for the appropriation), or "N" (no cash check). Cash balances on the CASH and appropriation tables are impacted by Manual Warrants, along with other documents. Although the Manual Warrant updates the cash balance, it is not subject to a logic test for cash available with this edit. Manual Warrants process even without sufficient cash. For more information on the Check Cash Indicator, please see Chapter 4 of the ISIS/AFS User Guide, Volume I. EXPENDITURE ACCOUNTING 2 - 48 ISIS/AFS USER GUIDE, VOL. II (07/03) Logic Tests on Manual warrants are subject to the same tests as payment vouchers. See the dis- Manual Warrant cussion on "Logic Tests on Payment Voucher Amounts" for a list of criteria. Amounts Accounting Model Manual warrant lines are posted to the Current Detail General Ledger (GENLED) and Ledger in the following manner: • Expenditure that is also an expense, with no prior document reference, Dr Expenditures/Expenses Cr Assets (cash) The amount posted is the manual warrant line amount. • Expenditure that is also an expense, with a prior payment voucher referenced, Dr Liabilities (vouchers payable) Cr Assets (cash) The amount posted is the manual warrant line amount. • Expenditure that is also an expense, with a prior purchase order referenced (see Figure 2-23 for an illustration of this accounting model), Dr Expenditure/Expenses Cr Assets (cash) Dr Reserve for Encumbrances Cr Encumbrances The amount posted is the manual warrant line amount when the warrant is a partial payment. When the payment is final, the warrant line amount is used to record the disbursement, and the purchase order amount is used to reverse the encumbrance amount. When processing a refund of revenue on a manual warrant, if the organization does not use an original fund, then the posting is: Dr Revenue Cr Assets (cash) EXPENDITURE ACCOUNTING ISIS/AFS USER GUIDE, VOL. II (07/03) 2 - 51 Referencing a When a manual warrant references a payment voucher, the warrant does not result Payment Voucher in a debit to the expenditure accounting distribution. That was already done by the payment voucher. The manual warrant liquidates the liability created by the payment voucher. When coding such a transaction, the accounting distribution must match the referenced payment voucher. Since the Prior Document Reference Option on System Control Options (SOPT) is "Y" for Louisiana, the accounting distribution does not have to be coded; it will be inferred when the payment voucher document number is coded in the reference document field on the manual warrant. The manual warrant closes a payment voucher line when the manual warrant line amount is equal to or greater than the payment voucher line amount. The payment voucher line will be given a closed date in Open PV Line Inquiry (OPVL). If all lines in the payment voucher document are closed, then the corresponding record in Open Payment Voucher Header Inquiry (OPVH) is also assigned a closed date. If a manual warrant represents a partial payment against a payment voucher, then the scheduled payment date is not deleted, and the outstanding balance on the voucher will be paid the next time the voucher is selected by the cash disbursement cycle. The partial/final indicator indicates whether the line is closing out a purchase order line (final payment) or authorizing partial payment of a reference line amount. On the line level, the referenced document(s) is coded. The accounting distribution and dollar amount are inferred from the referenced document. Figure 2-25 is the AFS standard Manual Warrant input form. See ISIS/AFS Online Features for coding instructions. EXPENDITURE ACCOUNTING 2 - 52 ISIS/AFS USER GUIDE, VOL. II (07/03) Figure 2-25a Sample MW FUNCTION: DOCID: MW Transaction STATUS: BATID: ORG: H- MANUAL WARRANT INPUT FORM MW DATE: ACCTG PRD: .. .. BUDGET FY: .. ACTION: . RECEIVING FUND: .... BANK ACCT CODE: .. CASH ACCT: .... VENDOR CODE: ......... .. VENDOR NAME: .............................. COMMENTS: ............ DOCUMENT TOTAL: .............. CALCULATED DOC TOTAL: Figure 2-25b Sample MW FUNCTION: DOCID: MW Transaction STATUS: BATID: ORG: 000-000 OF 000 ----- REFERENCED DOCUMENT(S) ----- CD NUMBER LN LN INVOICE LN -- --------------- -- --- ------------ --- SUB FUNC SUB REV SUB JOB FUND AGCY ORG ORG APPR UNIT ACTV TION OBJ OBJ SRC REV NUMBER REPT CAT ---- ---- ------- --------- ---- ---- ------- ------- -------- -------- BS ACTUAL I I P ACCT DEL DATE DESCRIPTION QUANTITY D AMOUNT D F ---- ---------- ------------------- ------------ - -------------- - - 01- .. ... ........... .. ... ............ ... .... ... .... .. ......... .... .... .... .. .... .. ........ .... .... .. .. .. .................. ............ . .............. . . 02- .. ... ........... .. ... ............ ... .... ... .... .. ......... .... .... .... .. .... .. ........ .... .... .. .. .. .................. ............ . .............. . . 03- .. ... ........... .. ... ............ ... .... ... .... .. ......... .... .... .... .. .... .. ........ .... .... .. .. .. .................. ............ . .............. . . Figure 2-26 is an illustration of a Manual Warrant input screen, coded to reflect a partial payment against the voucher shown in Figure 2-19. EXPENDITURE ACCOUNTING ISIS/AFS USER GUIDE, VOL. II (07/03) 2 - 53 Figure 2-26a Illustration MW FUNCTION: DOCID: MW 347 MW000000592 Transaction STATUS: BATID: ORG: H- MANUAL WARRANT INPUT FORM MW DATE: 03 30 98 ACCTG PRD: BUDGET FY: 98 ACTION: E RECEIVING FUND: BANK ACCT CODE: 10 CASH ACCT: VENDOR CODE: 620139960 00 VENDOR NAME: COMMENTS: PARTIAL DAY DOCUMENT TOTAL: 240.00 CALCULATED DOC TOTAL: Figure 2-26b Illustration MW FUNCTION: DOCID: MW 347 MW000000592 Transaction STATUS: BATID: ORG: 000-000 OF 000 ----- REFERENCED DOCUMENT(S) ----- CD NUMBER LN LN INVOICE LN -- --------------- -- --- ------------ --- SUB FUNC SUB REV SUB JOB FUND AGCY ORG ORG APPR UNIT ACTV TION OBJ OBJ SRC REV NUMBER REPT CAT ---- ---- ------- --------- ---- ---- ------- ------- -------- -------- BS ACTUAL I I P ACCT DEL DATE DESCRIPTION QUANTITY D AMOUNT D F ---- ---------- ------------------- ------------ - -------------- - - 01- PV 347 PV000005296 01 05 15 98 240.00 P 02- 03- Automated Disbursements Two processes disburse funds based on vouchers payable information in Open Payment Voucher Header Inquiry (OPVH) and Open PV Line Inquiry (OPVL). The Automated Cash Disbursement process prints checks based on this information; the Electronic Funds Transfer (EFT) process initiates the transfer of payments based on this information from your bank account to the vendor's bank account and can create a Remittance Advice form as physical notification. Both processes take discounts, liens/levies, backup withholding, and vendor credits into account before the payment is made. EXPENDITURE ACCOUNTING 2 - 56 ISIS/AFS USER GUIDE, VOL. II (07/03) Figure 2-27b Electronic Funds Transfer Process START Run voucher pre-selection turnaround reports (1G25 and 1G26). Review reports and adjust selection criteris if necessary. Run disbursements process and print Remittance Advice forms (ADRS, EFVS, EFCG, and 1G29). Run final disbursements job to post records to ledger files (EFPR). Review EFT Voucer Payments Register (1G29) and compare with 1G31 EFT Tape Register. STOP In addition to the payment voucher line detail, the reports also summarize all vouchers selected by vendor, and calculate a total amount for each vendor. Only one check or transfer line is written per vendor, even if multiple voucher documents exist for the vendor. The summarized amount includes any credit memos (the vendor owes the government money) that may exist for the vendor. The summarized amounts do not include discounts, liens, levies, or backup withholdings. Discount qualification is based on the number of days between the voucher date and the check date. Therefore, discount calculation is meaningful only at the time of the check run. Based on the information in these reports, you may want to contact OSRAP or the State Treasurer’s Office to: • Put a payment voucher on hold or take one off hold. • Change the scheduled payment date on a voucher. • Change a voucher's EFT status. EXPENDITURE ACCOUNTING ISIS/AFS USER GUIDE, VOL. II (07/03) 2 - 57 The first two actions are done through Payment Voucher Scheduling (SCHD), which is described in the next section, or through a Payment Voucher (PV) modification. The last action is done through the Payment Voucher Scheduling (SCH2) by the State Treasure’s Office. Payment Voucher Payment Voucher Scheduling (SCHD) allows users to change the scheduled Scheduling payment date and the single-check flag of vouchers in Open Payment Voucher Header Inquiry (OPVH). It also lets authorized users place vouchers on hold. This prevents them from being paid regardless of what their scheduled payment date is. The table is also used to remove the hold status from a voucher. Changes are made using standard MTI update procedures, as described in the ISIS/AFS Online Features. Figure 2-28 is an example of Payment Voucher Scheduling (SCHD). SCH2 is identical to SCHD. Figure 2-28 Payment Voucher ACTION: . SCREEN: SCHD USERID: Scheduling P A Y M E N T V O U C H E R S C H E D U L I N G VOUCHER SCHEDULED HOLD EFT CHK APL SINGLE VENDOR NUMBER PAYMENT DATE IND IND CAT TYP CHECK FLAG ============ =============== ------------ ---- --- --- --- ---------- 01- ......... .. ... ........... .. .. .. . . 02- ......... .. ... ........... .. .. .. . . 03- ......... .. ... ........... .. .. .. . . 04- ......... .. ... ........... .. .. .. . . When you access Payment Voucher Scheduling (SCHD or SCH2), you are actually accessing a portion of OPVH. Changes made on this screen are also updating OPVH. All maintenance actions to Payment Voucher Scheduling (SCHD or SCH2) will be changes. Use a GET (G) action to access the correct voucher, and then use a CHANGE (C) action to make your change. To change the scheduled payment date, display the desired voucher (use a GET action), and change the SCHEDULED PAYMENT DATE field. Note that the date is stored in the table as year-month-day (YYMMDD). Any new date that you supply must be in that format. To put a voucher on hold, display (use a GET action) the desired voucher and put an "H" in the HOLD field. To take a voucher off hold, use a CHANGE action to delete the "H" from the field. Always check the scheduled payment date field when you take a voucher off hold. EXPENDITURE ACCOUNTING 2 - 58 ISIS/AFS USER GUIDE, VOL. II (07/03) The EFT status can only be changed on SCH2. To change a voucher's EFT status, display the desired voucher (using GET) and type "N" in the EFT IND field. You may only change a voucher from EFT eligible to not EFT eligible. SCHD applies to an entire document. (Each record in OPVH represents a payment voucher document.) You cannot put individual lines in a payment voucher document on hold, or reschedule individual lines for payment. The automated disbursement and the electronic funds transfer processes always pay the entire outstanding amount of a selected voucher. Partial payments against a voucher document can be made with manually written checks, and then recorded in the system on a manual warrant. When this occurs, the cash disbursement process will pay the remaining outstanding amount the next time the voucher is selected for payment. Disbursement Voucher selection, payment calculation, file creation, and check printing are Parameters performed by the payment disbursement activities. These activities are controlled by specific parameters. The computer job that selects vouchers and calculates check amounts will add the parameters to Automated Disbursements Parameter (ADIS). Voucher Selection Each payment voucher line is considered individually during the voucher selection process. A voucher may be skipped for disbursement due to any of the following reasons: • The payment voucher has been put on hold on SCHD, • The vendor has been put on hold on Vendor (VEN2), • The vendor has been excluded (or was not included) on Automated Disbursement Restriction by Vendor (ADRV), • The agency has been excluded (or was not included) on Automated Disbursement Restriction (ADRT), • The vendor's total credits equal or exceed the total debits for the voucher agency, • The voucher failed its cash check, or • The voucher disbursement would be greater than the remaining Maximum Disbursement amount for the fiscal year. Placing a voucher on hold is performed on Payment Voucher Scheduling (SCHD). A discussion of the table and instructions on holding vouchers may be found earlier in this section. EXPENDITURE ACCOUNTING ISIS/AFS USER GUIDE, VOL. II (07/03) 2 - 61 The second cash edit is performed for all disbursements. As each voucher is processed, a running total is kept of the total cash disbursed for the day. With each new payment voucher line, the running total is compared to the Maximum Disbursement Amount stored on Fiscal Year (FSYR). If the voucher line will make the daily disbursement amount greater than the Maximum Disbursement Amount, then the entire voucher is skipped. Should it ever be necessary to stop all disbursements, setting the Maximum Disbursement Amount to 0.00 on FSYR will do the trick. Figure 2-31 is an example of FSYR. Figure 2-31 Fiscal Year ACTION: . SCREEN: FSYR USERID: (FSYR) F I S C A L Y E A R FISCAL YEAR/END NUMBER OF CLOSED BUDGET MAX DISBURSEMENT YEAR NAME DATE PERIODS IND APPROVED IND AMT ====== ---- -------- --------- ------ ------------ ---------------- 01- .. .... .. .. .. .. . . .............. 02- .. .... .. .. .. .. . . .............. 03- .. .... .. .. .. .. . . .............. 04- .. .... .. .. .. .. . . .............. 05- .. .... .. .. .. .. . . .............. 06- .. .... .. .. .. .. . . .............. 07- .. .... .. .. .. .. . . .............. 08- .. .... .. .. .. .. . . .............. 09- .. .... .. .. .. .. . . .............. 10- .. .... .. .. .. .. . . .............. 11- .. .... .. .. .. .. . . .............. 12- .. .... .. .. .. .. . . .............. 13- .. .... .. .. .. .. . . .............. 14- .. .... .. .. .. .. . . .............. Check Printing and Both the cash disbursement process and the fund transfer process select vouchers Tape File Creation from OPVH and OPVL. The cash disbursement program first summarizes all vouchers by vendor for consolidated checks, then takes into account vouchers with a single check flag. A total amount is calculated for each vendor, with the exception of those vouchers marked "Y" for single-check flag (which will have their own individual totals). One check is written for each vendor and for each voucher marked "Y" for single check flag. Only positive vouchers may be flagged "Y" for single check printing. The check amount takes into account all applicable liens, levies, backup withholding, and discounts. Consolidated checks also take into account any existing credit memos. The check category also determines whether a check is mailed or hand delivered, according to the following rules: • Check category "99" will consolidate payments to a single vendor from multiple agencies. Checks from this category are sorted by vendor zip code and mailed. EXPENDITURE ACCOUNTING 2 - 62 ISIS/AFS USER GUIDE, VOL. II (07/03) • Check category "AA" will consolidate payments to a single vendor from one voucher. These checks are not sealed, they are hand delivered to the paying agency. Although Application Type for EFT payments will have the same values as check category (99 or AA), all EFT payments are automatically sent to the bank. For those EFT payments flagged as "single check" (AA), only the lines included on a single payment voucher are included in the EF transaction. Voucher flagged as consolidated (99) may contain vouchers from multiple agencies. The electronic funds transfer program summarizes all vouchers selected by vendor, application type, and single check flag. A total amount is calculated within each application type for each vendor, with the exception of those vouchers marked "Y" for single check flag (see below). One transfer record is written for each vendor in each application type and for each voucher marked "Y" for single check flag. A vendor may appear under any number of application types. Vouchers with a single check flag of "Y" have their own individual totals regardless of whether the process used is electronic funds transfer or cash disbursement. Only positive vouchers may be flagged with "Y" for single check (transfer) printing. The check or transfer amount takes into account all applicable discounts, liens or levies or backup withholding. Cash Disburse- The cash disbursement cycle has the following effects on various system files: ment Outputs • It creates a file that is used to produce reports 1G18, 1G19 and 1G24. • If any discounts were taken, the cycle updates EEX2 and EAP2 depending on the spending control in effect. • It generates records for the following files: Current Detail General Ledger (GENLED) and Open Payment Voucher Ledger (PVOPEN). • It updates Open Payment Voucher Header Inquiry (OPVH) and Open PV Line Inquiry (OPVL). Affected fields are: closed amount, disbursed amount, closed date, outstanding amount, lien/levy amount, withheld amount, last check number, and last check date. • It creates records on Open Check Header Inquiry (OPCH) and Open Check Line Inquiry (OPCL). OPCH and OPCL are keyed by Bank Account Code and Check ID. OPCH fields include: vendor information; a check cancellation flag; and the check's amount, date, backup withholding amount, and closed date. OPCL displays each check line's vendor invoice, reference payment voucher, fund, agency, amount, and backup withholding amount. EXPENDITURE ACCOUNTING ISIS/AFS USER GUIDE, VOL. II (07/03) 2 - 63 • It creates a record on Checkstub (STUB). This table is keyed by Transaction Code, Check Number, and Bank Account Code. STUB displays information that appeared on the vendor check and checkstub. • It adds the check to Warrant Reconciliation (WREC) with a status of "open". • It creates additional payment vouchers for the lienholders as a result of lien/levy processing. Checks and check stubs will be printed on pre-printed forms. The effect of the electronic funds transfer cycle is the same as the cash disbursement cycle except the electronic funds transfer cycle does the following: • It creates a file that is used to produce 1G29 and 1G28, instead of 1G07 and 1G18/1G19. • It creates a file to be sent to the bank. • It updates the last check number and last check date on Open PV Line (OPVL) with the EFT transfer number and transfer date. • It adds the transfer to WREC with a status of "closed." • Instead of a printing a check, a Remittance Advice Form maybe printed for all vendors. The Check Stub Lines on the check stub summarize amounts by payment voucher transaction and Checkstub number and vendor invoice number. A separate line exists on the stub for discounts (STUB) taken; this line is also summarized by payment voucher transaction number and vendor invoice number. Credit memos, liens, levies, and backup withholdings are also shown as separate lines, within payment voucher transaction number and vendor invoice number. All information provided on the check stub or EFT remittance advice form may be viewed on Checkstub (STUB). Manual warrant transactions do not update this table. This table displays, for each check or EFT, important check and vendor information. Lines of the table show all payment voucher lines disbursed by the check, along with their referenced document, vendor invoice, comments, and line amount. Lien/Levy deductions, Backup Withholding deductions, credit memos, and discounts that appear on the check stub also appear on this table. EXPENDITURE ACCOUNTING 2 - 66 ISIS/AFS USER GUIDE, VOL. II (07/03) The EFVS Report A report is generated by EFVS whenever a voucher which could have been paid for Fund Transfer electronically is not paid because the vendor is no longer EFT active. Vouchers Disbursements present on this report are changed by the EFVS process to be non-EFT (the EFT-IND on OPVH is changed to N and the APPLICATION-TYPE is changed to spaces). Disbursement Two reports can be produced during the cash disbursement cycle. Reports • Check Register (1G18, 1G19) • Discounts Taken/Lost (1G24) The EFT cycle produces two reports. • Funds Transfer Register (1G29) • Discounts Taken/Lost (1G28) Samples of these reports are included in the ISIS/AFS Reports Manual. Order of Occasionally, automated disbursements require multiple reductions. In this instance, Reductions there is a specific order for reductions, as follows: Discounts, Backup Withholdings, Credit Memos, Lien/Levy payments. Accounting Model Automated disbursements generate the following postings to the Current Detail and Ledger General Ledger (GENLED): Dr Liabilities (vouchers payable) Cr Assets (cash) The amount posted is the check or transfer amount. Unless otherwise noted, all ledger records generated by the cash disbursement process have a transaction ID of "AD" and a transaction number equal to the check number. Unless otherwise noted, all ledger records generated by the electronic funds transfer process have a transaction ID of "EF" and a transaction number equal to the transfer number. Figure 2-35 illustrates the accounting model. EXPENDITURE ACCOUNTING ISIS/AFS USER GUIDE, VOL. II (07/03) 2 - 67 VOUCHERS PAYABLE CASH 111170 11701 BS ACCT FUND AGCY ORGN APPR OBJT ACCT TYPE AMT Dr 100 100 6335 02 $1170 Cr 100 100 6000 01 $1170 Ledger Updates: GENLED, PVOPEN 1 The automated disbursements process generates a check for $1170.00, thereby reducing the liability (Vouchers Payable) recorded on balance sheet account 6335. Figure 2-35 Accounting Model for Automated Disbursements Five types of records are created by the payment disbursement cycle. 1. Cash or electronic funds disbursement records. These transactions record the outlay of cash or funds. A separate transaction is generated for each line in Open PV Line Inquiry (OPVL) that was paid. These records are posted to the following ledgers: • Open Payment Voucher Ledger (PVOPEN). The detail records are posted. • Current Detail General Ledger (GENLED). Depending on the option selected in System Control Options (SOPT), either detail or summary records are posted. The cash record has a transaction code of "AD" and a transaction number that is the check date. The electronic funds record has a transaction code of "EF" and a transaction number that is the transfer date. 2. Discount records. These are expense/expenditure entries recording the refund of money to the appropriate account resulting from a discount. A separate entry is generated for each line in OPVL for which a discount was taken. These records are posted to the Current Detail General Ledger (GENLED); detail records are posted. 3. Lien\Levy records. These are expense/expenditure and liability entries recording the withholding of payments for a vendor with a lien or levy recorded and the posting of payments to the lienholder. A separate entry is EXPENDITURE ACCOUNTING 2 - 68 ISIS/AFS USER GUIDE, VOL. II (07/03) generated for each line in OPVL that must be reduced on the original payment to account for the lien or levy amount. Another entry is created for the payment to the lienholder, which is created during the automated disbursement cycle and which only has one line on the payment voucher document. These records are posted to the Current Detail General Ledger (GENLED); detail records are posted. 4. Backup Withholding records. These records are created when the vendor is subject to backup withholding, and the object is 1099 reportable. A separate entry is generated for each line in Open PV Line Inquiry (OPVL) where a percentage of the disbursement is withheld. These entries are posted to the Current Detail General Ledger (GENLED). Check Voids Checks can be voided in AFS in two ways: • By entering a Check Cancellation (CX) document. • By entering a reversing Manual Warrant (MW) document. Of the two methods for voiding checks, the recommended method is entering a Check Cancellation (CX) document. Both manually written checks and checks produced by the automated disbursement process may be voided. Check In order to use the Check Cancellation (CX) document, the following conditions Cancellation must exist: • The check being canceled must have been written against a Payment Voucher (PV). • A record for the referenced payment voucher must still exist in Open Payment Voucher Header Inquiry (OPVH) and Open PV Line Inquiry (OPVL). • The check being canceled must represent full payment of the payment voucher (partial payments cannot be handled by the check cancellation transaction). The check cancellation process posts reversing records to cash and vouchers payable. The records are created from each line in Open Payment Voucher Header Inquiry (OPVH) paid by the check. Any discounts, liens, or levies taken are not reversed. Additionally, the expended amount in Vendor (VEN2) is reduced, entries in Warrant Reconciliation (WREC) are marked void, and the transaction code of the last check/MW number field in Open PV Line (OPVL) is changed to "CX." EXPENDITURE ACCOUNTING ISIS/AFS USER GUIDE, VOL. II (07/03) 2 - 71 Reverse the To void a manually written check, you must reverse the manual warrant transaction Expenditure & Void that recorded the check. This section discusses the situation when no requisition, a Manually Written purchase order, or payment voucher was referenced on the Manual Warrant (MW). Check (no Prior Document Reference) The manual warrant is reversed by coding a new manual warrant with a decrease (negative) line amount. A negative line amount is valid in AFS but a negative document total is not valid. Therefore, a balancing line must also be coded on the manual warrant transaction. The system-generated offsetting lines for these two lines will balance each other out. Code the manual warrant as follows: • Document header. 1. If the warrant still exists in Document Control Inquiry (DCTL), you may want to use the original warrant number with a document action of "M". Otherwise, use the warrant number with a document action of "E". 2. The bank account code is required. Use the bank account code of the bank for whom you are voiding the checks. 3. The cash account is optional, but if coded, must match the original warrant. 4. Vendor code or name is required. It must match the original warrant. When a check is being voided for a vendor that exists in Vendor (VEN2), the system will decrease the expended amount field in Vendor (VEN2) by the amount of the canceled check. • Reversal line (record each line as it was originally coded). 1. Code the accounting distribution exactly as it was coded on the original manual warrant. 2. If the check number is not represented by the warrant number, code it in the description field. 3. Code the amount of the check being voided. 4. The increase/decrease indicator must be "D". • Balancing line. 1. Code one line per fund affected. That is, if several lines from the same fund are being voided, one summarizing line can be coded. 2. The fund must be the same as the fund on the reversal lines. EXPENDITURE ACCOUNTING 2 - 72 ISIS/AFS USER GUIDE, VOL. II (07/03) 3. Agency is required. 4. Balance sheet account is required. It must be the cash account that was used on the original warrants. This would have been coded on the original manual warrant header or inferred from Bank Account (BANK). 5. The line amount is the total of all reversal lines (within the fund) being balanced (so the document total will be zero). 6. The increase/decrease indicator must be "I". These manual warrant transactions will reverse the expenditure transaction throughout the system. For example, the expended amount fields in the budget tables and in Vendor (VEN2) are reduced, and the balances in Balance Sheet Account Balance (BBAL), and BS Account Bal by BS Account Inquiry (BBAB) are increased. They will also reverse the cash transaction (the vouchers payable and cash accounts are reversed). You should also use MTI to change the status field to "V" on the appropriate entry in Warrant Reconciliation (WREC). Note: It is important to realize that the system can not verify that the accounting distribution codes, the balance sheet account codes, and the vendor codes are correct (i.e., that they match the original manual warrant). This validation cannot be made because manual warrants are not stored in a table; only the document number and accounting period are kept in Document Control (DCTL). If the wrong codes are used, you will affect the wrong lines in the tables mentioned above. You should verify the results of these transactions on a Transaction Listing Report or the Online General Ledger (OLGL) to ensure that the correct codes were entered. Figure 2-38 shows a manual warrant coded to void one manually written check with no prior document reference. EXPENDITURE ACCOUNTING ISIS/AFS USER GUIDE, VOL. II (07/03) 2 - 73 Figure 2-38a Void Check FUNCTION: DOCID: MW 011 R-10005 Reference STATUS: BATID: ORG: H- MANUAL WARRANT INPUT FORM MW DATE: 03 25 98 ACCTG PRD: BUDGET FY: 98 ACTION: E RECEIVING FUND: BANK ACCT CODE: 04 CASH ACCT: VENDOR CODE: 199450986 VENDOR NAME: COMMENTS: DOCUMENT TOTAL: 0.00 CALCULATED DOC TOTAL: Figure 2-38b FUNCTION: DOCID: MW 011 R10005 Void Check STATUS: ACCPT BATID: ORG: 000-000 OF 000 References ----- REFERENCED DOCUMENT(S) ----- CD NUMBER LN LN INVOICE LN -- --------------- -- --- ------------ --- SUB FUNC SUB REV SUB JOB FUND AGCY ORG ORG APPR UNIT ACTV TION OBJ OBJ SRC REV NUMBER REPT CAT ---- ---- ------- --------- ---- ---- ------- ------- -------- -------- BS ACTUAL I I P ACCT DEL DATE DESCRIPTION QUANTITY D AMOUNT D F ---- ---------- ---------------- ------------ - -------------- - - 01- 100 100 1001 100 3100 03 25 98 VDCK#42985 1500.00 D 02- 100 100 6000 03 25 98 VDCK#42895 1500.00 I 03- Reverse the This section discusses the situation when the original manual warrant transaction Expenditure & Void (the one you want to reverse) included a prior document reference. There are two a Manually Written possible conditions. They are: Check (with a Prior Document Reference) 1. The referenced document no longer exists in the open tables. This condition will be true for requisitions, purchase orders, and payment vouchers if the monthly clearing activity has deleted the transaction entry from the tables. In this situation, you must code the check void as if there was no prior document. Code it following the directions in the previous section. 2. The referenced document still exists in the open item tables (even if it is marked closed). In this situation, you may include the prior document reference on the manual warrant that voids the checks. This will reopen the EXPENDITURE ACCOUNTING 2 - 76 ISIS/AFS USER GUIDE, VOL. II (07/03) Reverse the To void a check printed by the AFS automated disbursement process, you must Expenditure & Void reverse the effects of the transactions that were created by the automated disburse- an Automated ment process. You must also reverse the expenditure if: Disbursement Check • You want to re-establish the liability with a different accounting distribution. • You want to keep the liability for the same accounting distribution, but you want the automated disbursement cycle to write a new check. To void an automated disbursement, you need to enter a two-line manual warrant document and reverse the expenditure as follows: 1. Document header. • The bank code and cash account must match those used for the AD, as inferred from the fund and organization codes used on the related payment voucher. The vendor must match the one used on the payment voucher. 2. Increase cash. • Enter one line per fund affected. • Enter the appropriate fund. • Enter the cash balance sheet account. This is the account inferred through the organization or fund and bank account. • The line amount is the amount of the check. • The increase/decrease indicator is "I". 3. Decrease (reverse) the expenditure. One line is required for each payment voucher line included in the check. • If the related payment voucher still exists in Open Payment Voucher Header Inquiry (OPVH) and Open PV Line Inquiry (OPVL), include the reference in the document reference field. You can do this even if the payment voucher is closed. • The amount is the payment voucher line amount. • Increase/decrease indicator must be "D". EXPENDITURE ACCOUNTING ISIS/AFS USER GUIDE, VOL. II (07/03) 2 - 77 These transactions reverse the expenditure transaction throughout the system. For example, the expended amount fields in the budget tables and in Vendor (VEN2) are reduced, and the balances in Balance Sheet Account Balance (BBAL) and BS Account Bal by BS Account Inquiry (BBAB) are reduced. They will also reverse the cash transaction. If a payment voucher was referenced, it is reopened. The normal cash disbursement process can be used to write the new check. You should also change the status to "V" on the appropriate entry in Warrant Reconciliation (WREC). If you wanted to re-establish the liability with a different accounting distribution, you must submit an adjustment payment voucher to cancel the existing liability, and then enter a new payment voucher with the new accounting distribution. If you could not reference the payment voucher because it had been cleared from the tables, you will have to enter a new payment voucher to recreate the liability. Figure 2-41 shows a manual warrant coded to void an automated disbursement check and reestablish the liability for a payment voucher that still existed in Open Payment Voucher Header Inquiry (OPVH) and Open PV Line Inquiry (OPVL). Figure 2-41a Voiding Automated FUNCTION: DOCID: MW 011 R-10005 Disbursement Check STATUS: BATID: ORG: H- MANUAL WARRANT INPUT FORM MW DATE: 03 13 98 ACCTG PRD: BUDGET FY: 98 ACTION: E RECEIVING FUND: BANK ACCT CODE: 04 CASH ACCT: 6000 VENDOR CODE: 199628048 VENDOR NAME: COMMENTS: DOCUMENT TOTAL: 0.00 CALCULATED DOC TOTAL: EXPENDITURE ACCOUNTING 2 - 78 ISIS/AFS USER GUIDE, VOL. II (07/03) Figure 41b Voiding Automated FUNCTION: DOCID: MW 011 R-10005 Disbursement Check STATUS: BATID: ORG: 000-000 OF 000 ----- REFERENCED DOCUMENT(S) ----- CD NUMBER LN LN INVOICE LN -- --------------- -- --- ------------ --- SUB FUNC SUB REV SUB JOB FUND AGCY ORG ORG APPR UNIT ACTV TION OBJ OBJ SRC REV NUMBER REPT CAT ---- ---- ------- --------- ---- ---- ------- ------- -------- -------- BS ACTUAL I I P ACCT DEL DATE DESCRIPTION QUANTITY D AMOUNT D F ---- ---------- ------------------- ------------ - -------------- - - 01- PV 100 PV000004567 01 INV#00980003 100 100 0012 200 3100 03 13 98 VDCK#98421 REV EXP 200.00 D 02- 100 100 6000 03 13 98 VDCK#98421 REV EXP 200.00 I 03- Accounting Model This section presents the accounting models used to record the check void examples for Check Voids described above. Please note that an asterisk (*) following any ledger entry denotes an entry that is explicitly coded by the user. These entries are not automatically generated by the system. Reverse the Expenditure and Void a Manually Written Check with No Prior Document Reference. The manual warrant that recorded the check created these entries: Dr Expenditure* Cr Cash To void the check you will create these entries: Dr Cash* Cr Expenditure* Reverse the Expenditure and Void a Manually Written Check With a Prior Payment Voucher Document Reference. The manual warrant that recorded the check created these entries: Dr Vouchers Payable* Cr Cash To void the check you will create these entries: Dr Cash* Cr Expenditures* EXPENDITURE ACCOUNTING ISIS/AFS USER GUIDE, VOL. II (07/03) 2 - 81 Figure 2-42a Warrant ACTION: . SCREEN: WREC USERID: Reconciliation (WREC) W A R R A N T R E C O N C I L I A T I O N ( 1 O F 2 ) BANK ACCOUNT CODE= .. WARRANT LAST ACT WARRANT NO FUND VENDOR NAME DATE AMOUNT STAT DATE ============= ==== -------------------- -------- ------------- ---- --------- ............. .... . .. .. .. ............. .... . .. .. .. ............. .... . .. .. .. ............. .... . .. .. .. ............. .... . .. .. .. ............. .... . .. .. .. ............. .... . .. .. .. ............. .... . .. .. .. ............. .... . .. .. .. ............. .... . .. .. .. ............. .... . .. .. .. ............. .... . .. .. .. ............. .... . .. .. .. ............. .... . .. .. .. Figure 2-42b Screen Two (WRE2) ACTION: . SCREEN: WRE2 USERID: W A R R A N T R E C O N C I L I A T I O N ( 2 O F 2 ) BANK ACCOUNT CODE= .. ------ INTEREST ------ WARRANT NO FUND RATE AMOUNT ============= ==== ------ -------------- ............. .... ............. .... ............. .... ............. .... ............. .... ............. .... ............. .... ............. .... ............. .... ............. .... ............. .... ............. .... ............. .... ............. .... EXPENDITURE ACCOUNTING 2 - 82 ISIS/AFS USER GUIDE, VOL. II (07/03) Warrant Maintenance The status field on Warrant Reconciliation (WREC) can be maintained through MTI. Through MTI Authorized users can change the status by using the change "C" action in MTI after modifying the status. Following are the valid statuses: • Outstanding (O). The check has not been returned from the bank. All records are initially assigned this status. • Cleared (C). The check has been cleared through the bank. An automated process has been established to update this status, although authorized users may change the status to "C" as checks are returned. • Void (V). Authorized users may change the status from "O" to "V" when necessary. Records can be purged from WREC on a periodic basis. Only closed or voided records that fall within the specified date parameters are purged. Vendor Lien/Levy Sometimes, a user agency is notified of the need to apply a lien or levy against a Processing vendor. The system provides a means of automatically processing liens and levies in a way that the user does not even need to know if the vendor has a lien or levy recorded. If a user agency applies a lien or levy to a vendor, all future payments from that agency for the vendor are reduced as specified. Payments are reduced until a lien is satisfied. Levies are handled on a one-time basis. All payments in one nightly cycle are reduced by the amount of the levy or by the amount of the payments, whichever is greater. This special processing only applies to payments from the agency type grouping that recorded the lien/levy; payments from other agency types process as normal. Once the full amount of the lien or the amount of the levy is remitted to the lienholder, payments are no longer reduced and disbursements will be made normally. The status indicator for the levy is also automatically changed to "Inactive". Vendor Lien/Levy A user records a vendor lien or levy on Vendor Lien/Levy (VLLT). This table stores (VLLT) all information necessary for processing liens and levies against vendors, and also serves as an inquiry screen as to the status of the lien or levy. When a record is made on VLLT, the following data elements are required: • Agency Type • Vendor (whose payments will be reduced) • Lien/Levy Indicator • Date the lien/levy was Received • Remit-to Vendor (lienholder) • Lien/Levy Reference Number • Start Date and End Date for the Lien/Levy EXPENDITURE ACCOUNTING ISIS/AFS USER GUIDE, VOL. II (07/03) 2 - 83 • Lien/Levy Amount • Maximum Payment Amount per month or • Monthly Percent to be deducted from all payments Optionally, the status indicator may be invoked to record an inactive lien for future use. In addition, a maximum amount per payment may be recorded, which will override any other field on the table in limiting the deduction amount for a single payment. Finally, users have the option of recording the name of the agent responsible for the lien or levy. If a record exists on this table, then payment vouchers for the vendor will undergo lien/levy processing before the automated disbursement cycle. During this process, the payment voucher is recomputed to reduce the check total by the lien or levy amount. The reduction of the original payment voucher is performed by the Lien/Levy Auto Disbursement Post Processor (ADLL). A second payment voucher document is created for the lienholder (by the Lienholder Voucher Creation Process (LLPV)), which itself creates a check after a one-day lag. Both of these programs follow the Automated Disbursement process. After the VLLT record is entered, the lien or levy will take effect immediately, unless the current date is outside the Start and End Dates or the status indicator is set to "I" (Inactive). Once the lien/levy begins, VLLT may be used as an inquiry screen to determine current status. Fields on VLLT track the amount of lien/levy paid for month-to-date and inception-to-date as well as a difference of the lien amount less the amount paid to date. Figure 2-43 shows a sample screen of Vendor Lien/Levy (VLLT). EXPENDITURE ACCOUNTING 2 - 86 ISIS/AFS USER GUIDE, VOL. II (07/03) Backup "Reportable" payments not subject to normal income tax withholding, such as pay- Withholding ments to independent contractors, interest and dividends, royalties, etc., are subject to backup withholding if the payor is notified that the payee's tax identification number (TIN) is incorrect. TINs are incorrect when the IRS cannot match a given name to the number. Backup withholding applies to all payments to the payee that are reportable to the IRS. Upon notice from the IRS that a payee's TIN is incorrect, the payor must withhold taxes from subsequent payments at a specific rate based on federal guidelines. Backup withholding must continue until the payee furnishes the payor a correct TIN, or the IRS or Social Security Administration verifies the receipt of a correct TIN. In addition, backup withholding also applies when a payee fails to furnish a TIN, or furnishes one that is obviously incorrect. In these cases, backup withholding is employed when reportable payments are made. Backup withholding must be reported by the payor to the IRS in two ways. First, the amount withheld during the calendar year for a particular vendor must be included on the vendor's 1099 form. Second, the total amount withheld for all vendors by the payer must be reported on the 945 form and paid in accordance with the Deposit Schedule found in the IRS Instruction for Form 945. System Settings for Backup withholding is a system-enforced action, which will only occur if specific Backup Withholding criteria are met. For backup withholding functionality to execute, entries must be made to the following table fields: • Backup Withholding Option, on System Control Options (SOPT) • Backup Withholding Rate, on System Control Options (SOPT) • Backup Withholding Account, on System Special Accounts (SPEC) • Backup Withholding Flag, on Vendor (VEN2) The fields on SOPT define, for the whole system, if Backup Withholding is implemented, and at what rate payments are withheld. The Backup Withholding Account on SPEC defines the balance sheet account used to record the withheld amounts. Finally, the Backup Withholding Flag for a vendor's record on VEN2 must be set to "Y" before that vendor will have payments withheld. Criteria for Payments It is not necessary for the user entering a payment to know if backup withholding to Incur Backup applies to the payee; all withholding is computed and performed by the system. The Withholding same is true of cancellations of checks to vendors who had withholding applied - it is not necessary for the user entering the Check Cancellation (CX) to know if backup withholding occurred. EXPENDITURE ACCOUNTING ISIS/AFS USER GUIDE, VOL. II (07/03) 2 - 87 When a payment voucher (PV) is processed, each line of the voucher is processed individually to determine if it is subject to backup withholding. It is possible for some lines of a PV to be withheld, while other lines on the same document are not. On a line by line basis, the following criteria must be met before backup withholding occurs: • Backup Withholding Option = "Y" on SOPT. • Vendor's Backup Withholding Flag = "Y" on VEN2. • Object of Expenditure must be 1099 reportable If a payment line meets all of the above criteria, a percent of the payment amount equal to the Backup Withholding Rate on System Control Options (SOPT) is withheld from the disbursement. The withheld amount is computed during the Automated Disbursement Voucher Selection (ADVS) process, which is also when the payment lines are compared to the withholding criteria, listed above. If a disbursement meets the criteria for withholding, then it is reduced by the amount withheld, and a line is added to the check stub displaying the withheld amount and a description. Manual Warrant (MW) documents are not allowed for vendors who are subject to backup withholding. If a user attempts to process an MW against such a vendor, the document will reject and an error message will appear informing the user that the vendor is subject to backup withholding. Processing Related to When the Backup Withholding option is activated, a specified percentage is de- Backup Withholding ducted from the disbursements paid to vendors subject to backup withholding for 1099-reportable objects and placed into the backup withholding balance sheet account specified in System Special Accounts (SPEC). The withheld amount is considered part of the disbursement, however, it does not appear in the final amount of the check. When an amount is withheld from a vendor, the following entry is posted to the General Ledger: Dr Liabilities (Vouchers Payable) Cr Assets (Cash) Cr Liabilities (Vouchers Payable Withholding Account) Note: One entry is posted for each Open PV Line Inquiry (OPVL) line subject to withholding. This entry does not affect the Vouchers Payable entry in the General Ledger; however, cash is decreased by the amount of the backup withholding. After the Payment Voucher Selection program is run, the withheld amount is displayed on Open Payment Voucher Header Inquiry (OPVH) and Open PV Line Inquiry (OPVL). Open Check Header Inquiry (OPCH) and Open Check Line EXPENDITURE ACCOUNTING 2 - 88 ISIS/AFS USER GUIDE, VOL. II (07/03) Inquiry (OPCL) display the actual check amount and the withheld amount. The withheld amount is printed on the check stub. Cancelling Checks When a payment to a vendor is subject to backup withholding, the payment is re- Reduced by Backup duced, with the withheld amount recorded in a special liability account. If a backup Withholding withholding check is cancelled, both the disbursed amount and the withheld amount must be reduced. Check Cancellation (CX) documents are entered normally for payments with backup withholdings; it is not even necessary for the person entering the CX to know that a withholding occurred. When the CX document is accepted, it posts in the normal manner. The following fields are reduced as a result of the canceled check: • Disbursed Amount, on Vendor (VEN2), • Calendar YTD Disbursed Amount, on Vendor (VEN2), • Withheld Amount on Open Payment Voucher Header Inquiry (OPVH), • Withheld Amount on Open PV Line Inquiry (OPVL), • Closed Amount on Open Payment Voucher Header Inquiry (OPVH) Furthermore, Open Check Header Inquiry (OPCH) and Open Check Line Inquiry (OPCL) must be updated for the cancellation. There are three distinct scenarios for these updates: • If the IRS was not paid, then the OPCH Canceled flag is set to "Y" and the OPCH Closed Date is set to the date of the CX. • If the IRS was paid but the Open Check Table Purge (CKPG) program did not run then the OPCH Closed Date is set to spaces and the OPCH Canceled flag is set to "Y". Also, the OPCH and OPCL withheld amounts are made negative and the OPCH and OPCL check amounts are set to zero. The withheld amount is negative so that the next 3G00 report will include these canceled items as negative amounts, so the payment to the IRS will be reduced. • If the IRS was paid and the Open Check Table Purge (CKPG) program ran, then the OPCH and OPCL entries are recreated using information from the CX, Vendor (VEN2), and Open PV Line (OPVL). The recreated OPCH and OPCL entries are then updated as follows: The OPCH Closed Date is set to spaces and the OPCH Canceled flag is set to "Y". Also, the OPCH and OPCL withheld amounts are made negative and the OPCH and OPCL check amounts are set to zero. The withheld amount is negative so that the next 3G00 report will include these canceled items as negative amounts, so the payment to the IRS will be reduced. EXPENDITURE ACCOUNTING ISIS/AFS USER GUIDE, VOL. II (07/03) 2 - 91 "6" Medical and Health Care Payments "7" Non-Employee Compensation, Crop Insurance Proceeds, or Excess Parachute Payments "8" Substitute Payments in Lieu of Dividends or Interest "9" Direct Sales "Indicator" Return and income types are recorded for object codes on Object (OBJ2) in the 1099 TYPE field. If an object does not have entries in this field, it is not considered 1099 reportable. Balance sheet accounts which are 1099 reportable require entries on 1099 Balance Sheet Account (BS99). On BS99, each balance sheet account code is recorded with the return and income types for the calendar year. The 1099 The creation of 1099 reporting forms, for both the IRS and payees, is driven by a Reporting Process series of batch processes. The order of these processes is critical; some processes depend upon the results of prior ones. The first 1099 process, the Reportable Payments Selection Process (IS01LD99), is performed monthly throughout the year. This process creates the monthly 1099 ledger (1099LED), which contains all transactions that should be checked for 1099 reportability at the end of a calendar year. General ledger records included in the output 1099LED ledger meet these criteria: If an object is coded: • Manual warrants (MW) with account types 02, 22, or 23; or • Automated disbursements (AD) or electronic fund transfers (EF) with account types 02 or 22; or • Cash receipts (CR) and Journal Vouchers (JV) with account types 22 or 23 If a balance sheet account is coded: • If the balance sheet account is the reserved Backup Withholding Account; or • Cash receipts (CR) and Journal Vouchers (JV) with account types 01 or 02; or • Manual warrants (MW), Automated disbursements (AD), or electronic fund transfers (EF) which liquidate payment vouchers recorded with a balance sheet account; or • Check cancellations (CX) with account type 02 (these are written to the 1099 ledger with the object or balance sheet account code of the referenced payment voucher) Note: the object or balance sheet account code is not checked for reportability (or its income type and return type) each month. Eligible transactions from the entire year are checked once at calendar year end. At the end of the calendar year, the Yearly 1099 Ledger Update process (IS01RP99) is run. This program collects the 12 monthly ledgers and determines which transactions are 1099 reportable. Transactions are only considered reportable if the vendor is 1099 reportable (their 1099 IND = "Y" on VEN2) and the object or balance EXPENDITURE ACCOUNTING 2 - 92 ISIS/AFS USER GUIDE, VOL. II (07/03) sheet account code has return and income types recorded. (See above for a discussion of return type and income type.) If a transaction is deemed 1099 reportable, the income type, return type, and information about the master vendor and agency type are all included on the Yearly 1099 Ledger record. The third 1099 process, the 1099 Summarization (T99C), condenses the Yearly 1099 Ledger and records the totals on the 1099 table. This process first sums the yearly ledger together by the key fields: calendar year, return type, agency type, FEIN/SSN number, and income type. Each sum is then compared to the existing 1099 table. If a record already exists on the 1099 table for the same key fields, then the summed amount is added to the VENDOR INCOME AMOUNT of the existing 1099 entry. If no 1099 table entry exists for the key, a new record is added with the summarized amount. After the 1099 table has been updated, corrections may be made manually to the 1099 table. Adjustments are entered in the MISAPPLIED AMT field if they are attributable to ISIS transactions and the OUTSIDE PAYMENT field if they are not attributable to ISIS transactions. For each manual adjustment entered on the 1099 table, a record must already exist on 1099 Text (99TX) with the same key fields. Once the 1099 table entries have been reviewed, the final process may be run, the 1099 Annual Reporting process (NY1099). This program reads the 1099 table and produces 1099 reports in two formats: 1099 forms for the vendors and a 1099 tape to be sent to the IRS. 1099 reports are only produced if the following criteria are met: • The REPORT IND is "N" or blank (1099 report criteria has not been met); • The calendar year of the 1099 record matches the year specified with the parameters for the NY1099 process; and • There is at least $600 of Adjusted 1099 income (the ADJUSTED 1099 field) to the master vendor from the agency type. Vendor 1099 (1099) This table records the types and amount of reportable payments made to each Taxpayer Identification Number. The table is populated by a batch process that collects information from the general ledgers. Manual adjustments to the computed amounts are made as necessary directly on the table. For each manual adjustment, a record with the same key fields must exist on 1099 Text (99TX). Figure 2-54 shows the format of Vendor 1099 (1099). EXPENDITURE ACCOUNTING ISIS/AFS USER GUIDE, VOL. II (07/03) 2 - 93 Figure 2-54 Vendor 1099 ACTION: . SCREEN: 1099 USERID: V E N D O R 1 0 9 9 CAL YR= .. RET TYPE= . AGCY TYPE= .... FEIN/SSAN= ......... VENDOR NAME: INCOME VENDOR INCOME REPORT TYPE AMOUNT MISAPPLIED AMT OUTSIDE PAYMENT IND ====== ----------------- -------------- --------------- ------ 1099 AMT REVISED ADJUSTED 1099 ---------------- -------------- . .............. .............. .............. . .............. .............. .............. . .............. .............. .............. . .............. .............. .............. 1099 Text (99TX) 1099 Text (99TX) is associated with Vendor 1099 (1099) and is used to enter explanations of all manual adjustments to 1099. Each manual adjustment to 1099 must have a record on 99TX with the same key fields. Figure 2-55 shows the format of 1099 Text (99TX). Figure 2-55 1099 Text ACTION: . SCREEN: 99TX USERID: 1 0 9 9 T E X T YR= .. RETURN TYPE= . AGCY TYPE= .... FEIN/SSAN= ......... INCOME TYPE= . VENDOR NAME: TEXT LINE ----------------------------------------------------------------------- ==== ...................................................................... ... ...................................................................... ... ...................................................................... ... ...................................................................... ... ...................................................................... ... ...................................................................... ... ...................................................................... ... ...................................................................... ... ...................................................................... ... ...................................................................... ... ...................................................................... ...
Docsity logo



Copyright © 2024 Ladybird Srl - Via Leonardo da Vinci 16, 10126, Torino, Italy - VAT 10816460017 - All rights reserved