Expenditure Accounting
This chapter describes expenditure accounting. It contains the following topics:
This chapter covers the basic purchasing features for MARS ADVANTAGE.
The functions of the expenditure module are:
- It provides a mechanism for managers to procure goods and services required to carry out their functions.
- It exercises control over spending and accounts 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. A request for procurement provides useful accounting information for internal management purposes. They are recorded in the accounting system as pre-encumbrances. They do not represent legal obligations.
- Purchase order (encumbrance). A purchase order may represent a purchase order, a contract, or any other type of purchase. Obligations represented by such contracts or orders are encumbered and recorded as reservations of budgetary amounts. When budgetary controls are being used, they reduce the amount available for spending.
- 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 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 MARS ADVANTAGE, payment can be made in one of three ways:
- Manually issuing a manual warrant or check
- Automatically using the automated cash disbursement capability
- Automatically using the electronic funds transfer capability
The following shows these steps and the related accounting events in MARS.
|
Manual Warrant, Automated Disbursement, or Electronic Funds Transfer |
||||
All four steps are not required for every purchasing event; several different processing chains are supported to accommodate various accounting procedures, paper flows, and circumstances surrounding individual purchasing events. The following illustrates the processing chains acceptable in MARS. Each step in the chain is explained in detail in subsequent sections of this chapter.
The following terms are used throughout this chapter:
The various steps in expenditure accounting that apply to the same purchasing event are linked together in MARS by referencing the preceding document. For example, when you enter a purchase order against a previously entered requisition, one of the items entered on the purchase order can be the document ID that identifies the requisition (Enter the document ID in the Reference Requisition field.). Similarly, payment vouchers may reference purchase orders, and manual warrants may reference payment vouchers or purchase orders. This referencing facility accomplishes two purposes:
- It ensures that funds are obligated only once for a particular item or service.
- It ensures that financial records are not cluttered with dangling requisitions, purchase orders, and payment vouchers.
This referencing facility is built into MARS; most expenditure accounting documents (except the requisition) have specific fields designated for preceding document references.
Since checks can be written for partial amounts of total purchases, several payment vouchers, manual warrants, or a combination of both may reference one purchase order. Purchase orders may also reference multiple requisitions.
Outstanding requisitions, purchase orders, and payment vouchers are maintained on the following open item tables and are available for inquiry from windows of the same name.
These tables are maintained by the system and cannot be modified through master table inquiry. To change an entry in any open item table, a modifying document must be entered to reflect the desired changes. The information in the windows can be accessed online and reports can be generated offline.
Documents are added to open item tables when the document recording the transaction is accepted by MARS. For example, when a Requisition (RQ) is accepted, a record is added to Open Requisition (OPRQ). If modifications are made to the requisition, the corresponding recording Open Requisition (OPRQ) is updated to reflect the change.
Items are stored in open item tables when the document recording the transaction is accepted by MARS. A clearing process run by the System Administrator on a regular basis (it is recommended that it be run at the end of every accounting period) reduces the size of the open item tables; this process is called the Monthly Table Clearing (AFINMCCT) process. AFINMCCT will clear records on open item master tables when the closed date is less than the clearing accounting period specified on Application Dates (LDAT).
The contents of each open item table are explained later in this chapter under the section that addresses the document related to the specific window; for example, a discussion on Open Requisition (OPRQ) is found in the section on requisitions.
All expenditure documents are posted to the Current Detail General Ledger (GENLED). In addition, open purchase orders and payment vouchers are maintained in the following ledger files:
These ledgers contain a separate record for each detail document (original entry) and for each modification made to the original entry. This provides a complete inception-to-date tracking capability on open purchase orders and payment vouchers for reporting purposes.
The contents of these ledgers generally correspond to the contents of the purchase order and payment voucher open item windows. If all modifications to a specific purchase order line are summarized, the result is the line as it appears in Open Purchase Order Line (OPOL).
Outstanding (open) requisitions, purchase orders, and payment vouchers are canceled (closed) in MARS when a purchase is not going to be made. Canceling the document reverses the obligation and closes the item on the appropriate open item inquiry table. Canceling is achieved by "zeroing out" the line as follows:
- Completing the header of the appropriate document window with the same document ID used on the original document, and selecting the Modification indicator.
- Typing the line you want canceled exactly as it exists in the open item window, including the outstanding line amount. In Default/Increase/Decrease column, select Dec to decrease the line amount to zero. (If a line is partially cleared, it can only be decreased by the outstanding amount.)
Accounting Basis for Expenditure Processing
MARS performs the various functions that ensure proper expenditure accounting procedures:
- Users enter only the expenditure line of an expenditure document on documents (except for the payroll and journal voucher document types). MARS automatically generates the implied offset, or balance sheet, entry. The actual offset entries generated are listed in subsequent sections of this chapter.
- MARS automatically reverses 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 document.
- Similarly, MARS automatically reverses an encumbrance and reserve for encumbrance when an expenditure is recorded against it.
- MARS permits the distinguishing between the acquisition and use of goods and services. See the discussion under payment vouchers for information on how to record these two events separately in MARS.
- MARS performs a revenue/expenditure reconciliation on internal documents. That is, when an internal payment voucher is processed, not only is the expenditure recorded against the buyer fund, but the revenue is also recognized in the seller fund.
- A cleared item may be reopened in the same accounting period that it was cleared, or in the accounting period immediately following. Open items are stored in inquiry windows. When the table clearing programs are run on a monthly basis, a closed item remains in the inquiry window for one full accounting period after it is closed, and can be reopened during this time. If the item remains unopened for a full accounting period, it is removed by the table clearing program by the clearing process (run by the System Administrator) and cannot be reopened. Once removed, you must enter a new document. Reopening is accomplished with modify documents. These are entered as if the document was still open.
- A detailed audit trail of all accounting activity is always available. It exists on the Current Detail General Ledger for all open accounting periods. For closed periods, this data is available on the Closed Detail (CLSLED) ledger. If the Online General Ledger is in use, accounting activity can be viewed online from Online General Ledger (OLGL).
- Expenditures are obligated only once against the budget, and against appropriation and allotment balances. In addition, encumbrances and expenditures are made against balances at the earliest possible stage in the accounting chain. Funds are no longer obligated when 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.
- When the amount of an expenditure differs from its encumbrance balance, or when adjustments are made to encumbrance or expenditure balances, the obligations are affected only by the net amount changed.
Each purchase order document contains Fund, Agency and Object of expenditure codes. MARS lets you enter and record accounting documents in more detail than the budget. You can enter documents according to site-specific conventions and cost accounting requirements. The level of detail of the budget is the minimum coding requirement on expenditure documents. For example, you may budget expenses by Agency, but enter expenditure accounting documents by Agency, Organization, Activity, and Function; or you may budget expenses by Agency and Organization but enter expenditure accounting documents by Agency, Organization, and Sub-Organization.
Also, you may elect not to budget by activity but mandate activity coding on all expenditure accounting documents. This option is selected when the Expense Budget Activity Option in Fund Agency (FGY2) is Required on Accounting .
To preserve consistency between budgetary and accounting data maintained at different levels of detail, MARS automatically sums to the level of the budget before applying budgetary controls and updating balances in the budget master tables. Therefore, you only enter each document properly from an accounting standpoint; MARS performs the rest automatically.
Accounting distribution consistency must be preserved between succeeding documents in the purchasing chain. For example, when a purchase order references a requisition, the accounting distribution must be the same on both documents. However, the accounting distribution may be "exploded" on the succeeding document, so that it includes additional codes not displayed on the previous document. For example, optional codes such as Job Number, Report Category, and Sub-Organization may be added to a payment voucher, even if these codes are blank on the referenced purchase order.
Budgetary control options affect the way you enter expenditure documents. MARS rejects any documents that do not meet the budgetary controls selected for the fund. Three controls affect the way you enter expenditure documents. They are selected by fund and are listed below.
Each of these options is described in detail. See System Controls and Options for more information.
When purchase orders, payment vouchers, and manual warrants are tested for compliance with budget controls, obligations are defined as:
Encumbered Amount + Expended Amount
When requisitions are tested for compliance with these controls, obligations are defined as:
Pre-Encumbered Amount + Encumbered Amount + Expended Amount
However, pre-encumbrances never affect fund balance, because they are not included in the annual closing calculation of fund balance.
When less strict budgetary controls are needed, the user can select from expense budget, appropriation and allotment presence control or no control. Note that available funds are not checked when these controls are used.
Organization, Activity, and Function Options
Three options exist in MARS that determine coding requirements for expenditure documents. These options are:
These options are selected for each fund/agency combination and recorded in Fund Agency (FGY2).
For funds such as a debt service fund, imprest (petty cash) funds, and certain trust and agency funds, formal budgetary controls generally are an unnecessary administrative burden to an organization. However, some form of expenditure control still may be desirable. In these and other situations, a cumulative surplus or deficit of a fund may be controlled, either in lieu of or in addition to other expenditure controls, by specifying a required minimum amount. For such funds, any expenditure that causes the accumulated surplus or deficit of the fund to be less than the required minimum is rejected. This option, like the budgetary controls, is elected by fund.
The Fund Balance Control Option is explained in detail. See System Controls and Options for more details.
Prior Document Reference Option
The Prior Document Reference option affects the way you enter documents. The option is selected in System Control Options (2 of 2) (SOP2). The valid values are Yes , No , or Default . If the value is Yes , it affects coding requirements in the following ways.
- Coding the accounting distribution on original entries when a previous document is referenced is not necessary. For example, if a payment voucher references a requisition or purchase order, the fund, agency, object, etc., are not required on the referencing document. The system infers the accounting distribution from the referenced document. If the accounting distribution is entered, 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 and Reporting Category may be added to the accounting distribution.
- You do not have to enter the accounting distribution on modifying documents. For example, if a modification against a previously entered requisition is entered, the fund, agency, object, etc., are not entered. The system infers the accounting distribution from the previously entered line. If the accounting distribution is entered, it must match the previously entered line. Previously entered codes in the accounting distribution cannot be changed and new codes cannot be added on modifying documents. (This is true whether the Prior Document Reference option is Yes or No . If you want to change the accounting distribution, you must cancel the document and re-enter it as a new document.)
This referencing facility accomplishes two objectives:
- It ensures that funds are obligated only once for a particular item or service.
- It ensures that financial records are not cluttered with dangling requisitions, purchase orders, and payment vouchers.
When the Vendor Control option on System Controls and Options (SOPT) is selected, a Vendor Code must be used on all purchase orders, payment vouchers, and manual warrants. These options provide some control over vendors that users can place orders with or issue payment.
Prior-Year Encumbrances and the Obligation Carry Forward Option
When a payment voucher includes a reference to a prior year purchase order, the accounting distribution codes on the payment voucher must be valid in the master tables for both the current year and the prior year.
When expenditures refer to prior year encumbrances, the expenditure (payment voucher or manual warrant) may be entered exactly as it normally would (referencing the purchase order from the previous year), as long as the expenditure is less than or equal to the encumbrance amount. When the expenditure is equal to the encumbrance or less than the encumbrance with a Partial/Final Indicator of Final , the encumbrance from the prior year is closed.
However, a special situation exists when the expenditure referencing a prior year encumbrance is greater than the encumbrance. Since unobligated expense budget, appropriation, and allotment balances are closed out at year-end, any expenditure in excess of the outstanding encumbrance is charged to the current year. In MARS, the excess amount is posted to the current fiscal year by recording the excess on a separate line of the voucher or manual warrant form. This separate line should not reference the purchase order because the excess is treated as a separate document. Therefore, the encumbrance from the prior year is cleared, and the additional amount is posted to the current year. Of course, this new obligation is subject to all the budgetary controls in effect for the current year and may be rejected if it does not comply with them.
The Obligation Carry forward option exists in MARS to make it unnecessary to code the second line to accommodate the excess expenditure. When this option is selected, MARS automatically posts the expenditure to the two years. (The payment voucher or manual warrant must reference the encumbrance from the prior year.) Again, the current year obligation created from this document must comply with all budgetary controls in effect for the current year. The Obligation Carry forward option is discussed in detail. See System Controls and Options for more information.
MARS allows for modification of prior year open purchase orders in two cases:
- Modification for a decrease amount
- Modification for a purchase order against a multi-year budget (it is possible to liquidate outstanding obligations from prior years without entering a referencing document)
The detailed accounting model for voucher and warrant documents that reference prior-year purchase orders is presented in detail. See Expenditure Accounting - Special Features for more information.
MARS provides a special facility that lets you liquidate outstanding purchase orders at year-end. All the purchase orders for a fiscal year are rolled over to the new year, or just those purchase orders associated with grants and projects.
Internal purchases are recorded like any other purchases, except that the seller's accounting distribution is included. The fund and agency of the seller can be identified on requisitions and purchase orders. A more detailed seller's accounting distribution is required on payment vouchers. The exact accounting distribution required is determined by the revenue budget options governing the seller's fund/agency.
When internal payment vouchers are used, MARS ensures that both revenue and expenditure entries from an internal purchase and sale are recorded simultaneously. Accordingly, a MARS internal payment voucher serves as the seller's invoice as well as the buyer's payment voucher.
A payment voucher document can be submitted to close an internal purchase order (unless the purchase order is canceled). If the document is between different funds, then the payment voucher may be followed by a manual warrant indicating a cash transfer on a manually written check.
The Internal Cash Voucher option, on System Control Options (1 of 2) (SOPT), controls whether the internal payment voucher posts the buyer's liability (Due To) and the seller's revenue (Due From) accounts, or to cash. When Due To and Due From accounts are used, a journal voucher must be recorded to process the cash transfer.
If the document is transferring money within a fund, the payment voucher is also required, but no check is written, and a manual warrant is not allowed. Payment vouchers for intra-fund transfers are automatically cleared as soon as they are entered in the system. (The payment voucher must be submitted to clear the purchase order and to effect the change in the budgeted balance for the fund/agency involved.)
MARS inquiry windows and master tables provide information that is valuable for researching vendor payment problems, analyzing purchasing trends, and complying with reporting requirements. The windows offer the following types of information:
- Vendor (VEN2, VEN3) assigns Vendor codes to frequently used vendors. A vendor's complete name and address is stored on Vendor (1 of 2) (VEN2), where they are available for reports and for the automated check-writing program. In addition, an alternate vendor name and address may be specified that is used by the vendor purchase order printing program. This accommodates situations where the vendor's ordering address is not the same as the accounts receivable address.
- Vendor Name Inquiry (VNAM) is an alternate view of Vendor (1 of 2) (VEN2), organizing vendors by vendor name. When this window is used in conjunction with the Vendor windows, all details regarding a vendor found on Vendor Name Inquiry (VNAM) can be obtained from Vendor (VEN2 and VEN3) by selecting Related Data on the Display menu to get to that window.
- The Open Purchase Order Header Inquiry (OPOH), Open Purchase Order Header Inquiry (EPS) (OPPH), and Open Payment Voucher Header Inquiry (OPVH), tables contain Vendor as their first key field. This allows online inquiry window searches by Vendor code.
- The Open Payment Voucher Line Inquiry (1 of 2) (OPVL) window contains a Last Check/MW Number field and a Date field. The Open Purchase Order Line Inquiry (OPOL) window contains a Last Reference Transaction Number field and a Date field. This information facilitates immediate online research for questions from vendors concerning payment.
- Vendor (2 of 2) (VEN3) includes a minority and small business indicator, 1099 indicator, and other indicators to flag vendors in those categories.
- If a vendor is flagged as 1099 reportable and a 1099 reportable object is coded in the transaction, information such as vendor TIN, name, address and transaction amount must be captured to do 1099 reporting for the IRS. The 1099 ledger serves as a central repository for 1099 reporting. All 1099 reportable transactions Check Writer, Pro-Card and Name and Address Change are updated daily to this ledger. All 1099 reportable transactions from the Automated Disbursements are updated to the General Ledger and extracted monthly to build the 1099 ledger. The 1099 reporting process such as adjustment and tape generation will be provided post July 1, 1999.
- A purchasing agent or buyer may want to maintain their own notes relative to a specific vendor. This is possible by using Vendor Text (VTXT). The window contains the Vendor code, Name, and any notes made by the buyer for that vendor. Vendor (2 of 2) (VEN3) has a Text Flag field that indicates whether any text exists for that particular vendor. This field is updated automatically with the addition or deletion of text.
Each text line is identified with a date that corresponds to the date when the line was added or changed. The batch program VNPG has the ability to report on text that is to be deleted based on a user-defined date and to then delete that text.
- The Payment Voucher by Batch Number (PVBN), Open Payment Voucher Line Inquiry (1 of 2) (OPVL), Open Payment Voucher Header Inquiry (OPVH), Online General Ledger Inquiry (OLGL), and Recurring Payment Voucher (REPV) contain a Batch Number field which allow documents to be sorted by any user defined category, including vendor code.
- Vendor Zip Code Inquiry (VZIP) displays vendors by Vendor Name, Zip, and Vendor code order.
- The two Vendor Sort (VNA2, VNAS) windows display vendors in a combination of Vendor code, Sort Name and Name.
- Insurance (INSU) provides the ability to record the existence and adequacy of insurance coverage by a vendor under the terms of a particular contract.
Miscellaneous Vendor Indicator
Even when the Vendor Control option is selected on System Control Options (1 of 2) (SOPT), most installations do not want to enter all vendors in the Vendor windows. One-time vendors or trial suppliers, for example, need not clutter up the table. A Miscellaneous Vendor can be established in Vendor (1 of 2) (VEN2) to accommodate such a situation. The name and address associated with the Miscellaneous codes are not used on checks; they may be used as comment fields to describe the miscellaneous code. When Miscellaneous Vendor Indicators are used, users must enter the desired name and address used on checks on the payment voucher document. Some sample entries in Vendor (1 of 2) (VEN2) for miscellaneous codes are listed in the following table. You can define any number of miscellaneous codes in Vendor (1 of 2) (VEN2).
The Miscellaneous Vendor Indicator on Vendor (1 of 2) (VEN2) notifies MARS not to use the Name and Address fields on Vendor (1 of 2) (VEN2) for checks. It also notifies the system to require a vendor name (and, optionally, an address) on the payment voucher.
The Alternate Address group on Vendor (1 of 2) (VEN2) facilitates a vendor being paid at a different address than the address on the purchase order. During purchase order generation this alternate address is printed on purchase orders in lieu of the vendor's main address. This allows the use of a single alternate purchase order address for each vendor. The main address is used for all payments if no alternate address is specified on purchase orders.
The Vendor field consists of two fields; nine spaces for the vendor number and two spaces for the Alternate Address indicator. The vendor number is stored in Vendor (1 of 2) (VEN2) with all eleven characters.
Alternate Address Code Capabilities
The use of alternate addresses can be explained in the following example:
As a user you purchase many kinds of items from a large computer vendor. Software and hardware must be ordered from different locations, but billing is centralized. The following documents might be written for these purchases:
- Purchase orders for hardware:
- Vendor code = IBM
- Alternate address = H
- Purchase orders for software:
- Vendor code = IBM
- Alternate address = S
- Receive hardware (RC):
- Vendor code = IBM
- Alternate address = H
- Receive software (RC):
- Vendor code = IBM
- Alternate address = S
- Receive invoice for month (which includes software Alternate address = P and hardware). Only the first nine characters are required to match the purchase orders described in 1 and 2 above:
- Vendor code = IBM
- Payment authorized (PV)
- Vendor code = IBM
- Alternate address = P
- All 11 characters must match the vendor invoice.
In addition to the Vendor Name and Address, the Vendor Index (VEND) and Vendor (VEN2) windows contain Calendar YTD Amount and Fiscal Year YTD Amount fields which are updated at the time the disbursement is recorded against the vendor in MARS.
Information in the vendor windows is used for reporting and warrant/check printing. This information includes:
- Contact person and phone number
- Indicators for type of organization
- Discount terms
- Customer Account number
- Vendor Type
- Payment terms and a scheduled payment day
- Single Check Request (indicates vendor preference of single-check payment for each service provided)
- Year-to-Date Amount field (updated at the time of payment)
- Calendar Year-to-Date field (updated at time of payment for use with 1099 reporting)
- Minority Vendor Indicator (indicates whether this vendor is classified as a minority vendor)
- 1099 Indicator (identifies whether a 1099 report must be produced for this vendor)
- Backup Withholding (indicates whether this vendor is subject to backup withholding on payment for 1099-reportable expenditures)
- Vendor Tax Code (indicates at what rate the vendor charges tax)
- Electronic funds transfer status (indicates whether the vendor may receive payment through electronic funds transfer)
- Electronic funds transfer type (indicates a default Application Type for electronic funds transfer).
- Primary Vendor Indicator (combines the vendor payment information for 1099 reporting).
A requisition document is a statement of a potential future purchase. MARS accounting procedures always view this document as optional. However, your installation may establish guidelines that require you to submit requisition documents for certain situations.
The requisition document does not obligate amounts in a fund; for example, it does not cause amounts to be subtracted from fund balances. It is considered a memo document because it records data that may be helpful to managers in carrying out their daily planning and forecasting duties.
When a requisition document is processed, it added to Open Requisition Header Inquiry (OPRQ) and Open Requisition Line Inquiry (OPRL). This record remains in an open status on the master tables until a purchase order, payment voucher, or manual warrant fully referencing the requisition is accepted.
The document referencing a requisition must have the same accounting distribution as that recorded on the requisition, however, the amounts do not have be equal.
When either the Expense Budget Control Option, the Appropriation Control Option, or the Allotment Control Option, (found on the Control Options view on Fund (FUN2)) is Full , funds must be available to cover the amount of the requisition or the requisition is rejected. (Available amounts are stored in the budget master tables.) Remember, the available amount is not reduced as a result of the requisition. When requisitions are being validated for compliance with budgetary or fund balance controls, obligations are:
Pre-Encumbered Amounts + Encumbered Amounts + Expended Amounts
Requisition Accounting Model and Ledger
New requisition lines are posted to the Current Detail General Ledger (GENLED) in the following way:
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 document. The table below illustrates the accounting model for requisitions.
Accounting Model for Requisitions
An increase modify document is posted as displayed above. A decrease modify document debits reserve for pre-encumbrances and credits pre-encumbrances.
Records are added to Open Requisition Header Inquiry (OPRQ) and Open Requisition Line Inquiry (OPRL) when new requisition documents are accepted by MARS; lines are changed when modifications are submitted on these documents.
An important line item feature of the requisition is the line number. Each line on a new requisition document is assigned a unique line number that allows purchase order lines to reference individual requisition lines.
A requisition line is closed when one of the following occurs:
- The sum of all purchase orders referencing a requisition line equals the requisition line amount.
- A purchase order forces a requisition closed with a Partial/Final indicator of Final .
When all the lines in a purchase order document are closed on Open Requisition Inquiry (OPRL), the corresponding line in Open Requisition Header Inquiry (OPOH) is closed. When the table clearing process is run on a monthly basis, records are removed from both periods one accounting period after the closing.
The requisition closed amount is the order line amount, regardless of the amount of the order causing the close. For example, if a requisition line exists for $100, and an order closes the purchase order for $90, the requisition closed amount is $100. However, MARS will decrease pre-encumbrances by $10, and increase the pre-encumbrance account balance by $10.
A requisition is canceled by submitting a requisition modifying document with a decrease line amount equal to the requisition line amount.
At year-end, all outstanding requisitions for the year being closed are removed when your System Administrator runs the process New Year Requisition Table Clearing (AFINNYRQ). However, the requisitions still appear on Expense Budget Inquiry (Extended) (EEX2) as pre-encumbered amounts.
For the pre-encumbrance documents, Fund, Agency, and Object codes are always required. Depending on various other options in effect, the Activity, Function, Organization, and Appropriation Unit codes may also be required. The Balance Sheet Account is blank for these documents. The offset entry for all pre-encumbrance documents uses the default Reserve for Pre-Encumbrance account on System Special Accounts (SPEC) on the Miscellaneous view.
The sample purchase requisition shown in Figure 40 is entered to request a purchase for fund 0100, agency 470. See the User's Reference for detailed field descriptions.
A purchase order document is a statement that goods or services were ordered. Purchase orders are not required for MARS accounting procedures, but they are generally considered good accounting practice. They should be submitted when the purchase of materials and services is authorized, or when a contract agreement is finalized.
If a requisition document was previously submitted for an item listed on a purchase order, the requisition document ID is referenced on the purchase order so the appropriate record in Open Requisition Header Inquiry (OPRQ) and Open Requisition Line Inquiry (OPRL) can be closed. When a purchase order references a requisition, the accounting distribution on the two forms must match. More line detail can be introduced on the purchase order, but a purchase order line must at least match the details already entered on the requisition. If the Prior Document Reference option on System Control Options (2 of 2) (SOP2) is Yes , the accounting distribution is not entered on a line that contains a prior document reference.
A purchase order document designates money that will be spent in the future; therefore the purchase order amount is subtracted from the fund specified on the purchase order document. The fund balance is adjusted later if the original purchase order amount is adjusted, if the final liability against the purchase order (recorded on a payment voucher or manual warrant) is different from the purchase order amount, or if the purchase order is canceled.
An important line item feature of the purchase order is the line number. Each line on a new purchase order document is assigned a unique line number that allows payment voucher and manual warrant lines to reference individual purchase order lines. This provides the capability of recognizing the partial receipt of goods or services rather than waiting until items from all lines on a purchase order document are received. Thus, partial or separate deliveries can be accounted for within the system.
A purchase order line is closed when one of the following occurs:
- The sum of all payment vouchers and manual warrants referencing a purchase order line equals the purchase order line amount.
- A payment voucher or manual warrant forces a purchase order line closed with a Partial/Final indicator of Final .
When all the lines in a purchase order document are closed in Open Purchase Order Line (OPOL), the corresponding line in Open Purchase Order Header (OPOH) is closed. When the table clearing process is run on a monthly basis, records are removed from Open Purchase Order Line (OPOL) and Open Purchase Order Header (OPOH) one accounting period after the closing. Accompanying entries on Open Purchase Order Line (OPOL) are also removed at this time.
The purchase order closed amount is the 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 order closed amount is $100. However, MARS will decrease obligations by $10, and increase the unobligated account balance by $10.
Reopening Closed Purchase Orders
You can reopen a closed purchase order if it still remains in the open purchase order tables. (Remember that if the table clearing process is run on a monthly basis, closed lines remain in the tables for one additional accounting period after they are closed. If they are not reopened during that time, they are cleared.) You can reopen a closed line in two ways:
- Reference the closed purchase order on a payment voucher or manual warrant (see the discussion on these documents later in this chapter). This automatically reopens the purchase order, if the amount used to reopen it does not exceed system tolerance logic.
- Enter a purchase order modifying document, using the original purchase order number, to change the amount.
Logic Tests on Purchase Order Amounts
Purchase order line amounts are subject to the following tests:
- When the budgetary full controls are in effect, the unobligated balances must be large enough to cover the new obligation.
- When the Fund Balance Control Option is in effect (on the Control Options view of Fund (FUN2)), the new obligation cannot decrease the fund balance control amount below the level established in Fund Balance (FBAL).
- A decrease document cannot reduce the purchase order to less than the purchase order closed amount (a purchase order cannot be reopened on a decrease document).
Up to 1000 lines of text may be associated with each line of a particular purchase order. The key fields on Purchase Order Text (POTX) are Vendor number and Transaction ID. For convenience, text may be entered independently of document acceptance, and may contain any pertinent information about that purchase order line. Visual verification of text is also provided for each line in documents and on open items tables. For more information, see the User's Reference .
Purchase Order Accounting Model and Ledger
For each line on the purchase order form, entries are posted to the Current Detail General Ledger (GENLED) as follows:
- When no prior requisition is referenced, the following accounting model is used (the amount used is the purchase order line amount):
- When a prior requisition is referenced by the purchase order, the ledger entries generated by the requisition are reversed. In this situation, the following accounting model is used. The amount associated with the requisition reversal is the requisition amount. The amount recorded as an encumbrance is the purchase order line amount. An example of this accounting model is shown below.
Dr Reserve for Pre-Encumbrances
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 for every purchase order document.
Purchase Order Inquiry Windows
MARS contains the following main open purchase order inquiry windows:
- Open Purchase Order Line Inquiry (OPOL)
- Open Purchase Order Header Inquiry (OPOH)
- Purchase Order by Account Distribution Inquiry (POAC)
When a purchase order document is processed, a line is created in Open Purchase Order Line (OPOL) for each line on the document. A line is also created in Open Purchase Order Header (OPOH) containing summary data from the header portion of the document. If modifying documents are accepted, the entries in the open item tables are updated to reflect the modifications.
A separate record is also created in Open Purchase Order by Document Inquiry (OPOD), which contains only the key information of the Purchase Order Number and Vendor code. This window is useful in locating purchase orders when you know the purchase order number, but you do not know the Vendor code. The user can browse this window until the appropriate purchase order and vendor combination is found. The user can then select Related Data from the Display menu and the system automatically locates the appropriate record on Open Purchase Order Header (OPOH).
Another record is created in Purchase Order by Account Distribution (POAC) that contains only key information of the accounting distribution and the Purchase Order 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 document. For example, a final payment voucher of $257.49 can close a $260.00 purchase order line. A record in Open Purchase Order Header (OPOH) is closed when all of its related lines are closed in Open Purchase Order Line (OPOL). When an open item record is considered closed, MARS adds the closing date and closing amount to Open Purchase Order Header (OPOH).
All closed lines are cleared from the tables one accounting period after the closing of the header line (when the monthly table clearing process is run on a monthly basis). When the purchase order is closed with a Partial/Final indicator of Final , 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, MARS decreases obligations by $10, and increases the unobligated account balance by $10.
At year-end, outstanding purchase orders for the year being closed can be rolled over to the new fiscal year. You have the option of rolling over all of the outstanding purchase orders, purchase orders associated with grants and projects, or none.
All purchase order lines require Fund, Agency, and Object codes. Depending on the value of the Expense Budget Organization Option, Expense Budget Activity Option, and the Expense Budget Function Option (on FGY2), the following codes may also be required:
The Organization, Activity, Function and Appropriation Unit codes may be required. Appropriation Unit is required if Full or Presence control is implemented for the appropriation. Other codes are optional.
A base system purchase order document records an encumbrance in the same manner as Extended Purchasing documents, but contains no commodity information. A payment voucher document or a manual warrant document can clear a purchase order.
Purchase order documents are also affected by budgetary controls (the appropriation, allotment and expense budget controls). The Fund Balance option (on the Control Options view of Fund (FUN2)) also may limit the purchase order amount.
On the header level, the Vendor Control option on System Control Options (1 of 2) (SOPT), may require that you use a Vendor Code on the form. If the purchase is internal, the seller fund and agency must be coded. The Order Type field is user-defined. Any alpha-numeric value (except S ) may be used to define various types of expenditures, such as service orders, contracts, maintenance, etc. Custom reports can then be written to select on specific purchase order types. Blank is a valid value in the Order Type field if you prefer not to use it.
S (Special Use) is a valid value for the Order Type field. The vendor purchase order printing facility can print special instructions on the purchase order. For example: call before delivery; no delivery on Saturday; deliver to 100 S. Main Street. An S in the Order Type field indicates that a special instruction is desired. The instruction code must then be provided in the Comments field on the purchase order document. The message associated with each Instruction code is defined in Special Instruction (SPIS) and is inferred at purchase order print time.
The following example illustrates a sample purchase order document coded to order air conditioners from a vendor listed in the vendor table. The line item references a requisition.
Purchase Order (PO) Document (All Attributes View).
A payment voucher authorizes the spending of money and initiates automated check writing 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 that is used by the cash disbursement programs. (The cash disbursement programs actually write the checks.)
MARS ADVANTAGE provides the following documents to enter payment voucher information: the Payment Voucher (PV), the Payment Voucher generated by Job Costing (PVJ), the Payment Voucher for Procard (PVC), the Payment Voucher from Procurement Desktop (PVP), the Payment Voucher Interface (PVI), the Vendor Payment Voucher (P1), the Multiple Vendor Payment Voucher (MP), and the Payment Voucher from Multi-Payee Voucher (PVV).
Vendor Payment Voucher (P1) documents are specifically designed for purchases or credits from outside vendors. Multiple Vendor Payment Voucher (MP) documents generate payment vouchers for different vendors (PVV), within one accounting distribution.
A payment voucher document is submitted if you want computer-printed checks produced by MARS ADVANTAGE. Alternatively, a manual check can be written. Then 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, a check is manually written and recorded on a manual warrant. The manual warrant closes the referenced payment voucher and consequently stops the check writing process.
- If the manual warrant is written for a specific line amount, then the cash disbursement process proceeds using the remaining outstanding lines.
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 purchase order (see the explanation of the Partial/Final indicator in the payment voucher instructions section).
Payment Vouchers - Issues and Concepts
Many vendors have discount policies that provide discounts in return for early payment. MARS vendor discount facility considers these discount policies at the time the check is printed, and if the discount is appropriate, calculates the discount and adjusts the payment amount accordingly.
In Discount Type (DISC), various vendor discount policies are defined. The window defines the percentage of the discount and the number of days you have to make the payment in order to receive the discount. In the vendor's terms, the number of days is usually the time between when the invoice was sent and when payment is received. In MARS, the number of days is the time between the payment voucher's transaction date and the date the check is printed.
The Discount Type code is a field on the payment voucher document. You can specify a different discount type on each payment voucher line. When the cash disbursements process is run for the payment voucher, the discount is taken if the number of days condition is met. The discount taken is printed on the check stub. The Discounts Taken/Lost Report (A658) shows discounts taken and also discounts that were lost because the number of days condition was not satisfied.
Payment vouchers are used to record refunds that you pay to the public or to vendors. The refund refers to money that 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. (Refunds can also be recorded on manual warrants if the refund is paid with a manually written check.) A refund is coded as follows:
- A Revenue code is used 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.
The transaction is stored in Open Payment Voucher Line (1 of 2) (OPVL), like all other payment voucher lines. It is printed as a separate line on the check stub produced by the cash disbursement process.
The refund transaction also adjusts the Recognized Amounts field in Revenue Budget (REV2).
Vendor payment vouchers are used to record credit against future purchases due to overpayment or returned goods. This is money owed to you by a vendor. In MARS, credit memos will only be entered as credits to payments that result in a net amount owed to the vendor on the payment voucher. If the cash is actually received from the vendor, it is recorded on a cash receipt using an Object code (as explained in the cash receipt discussion in this manual).
Credit memos are recorded with a decrease line amount on an original entry payment voucher. The payment voucher is coded as follows:
- The Line amount is the amount of the credit.
- An appropriate accounting distribution is needed, including an Object code (the Discount Type is blank).
- The Referenced Documents fields are blank.
- The Default/Increase/Decrease indicator is Dec .
- The vendor is indicated by a Vendor code or vendor Name .
The transaction is stored in Open Payment Voucher Line (1 of 2) (OPVL) as a negative amount. Credit memos are taken into account by the cash disbursement process in the following manner.
- When the total of the expenditure vouchers scheduled for payment for a vendor is less than, or equal to, the total of all credit memos for the vendor, then you do not owe the vendor money. None of the vouchers involved are selected for payment. The credit memo lines and the expenditure vouchers that were balanced by it are printed on the Nonscheduled Voucher Selection Report, and no check is printed. The credit memo lines and the expenditure voucher lines remain on Open Payment Voucher Line (1 of 2) (OPVL) as open items. These lines are not affected (updated) by the cash disbursement cycle. They remain open items in the table until:
- Scheduled liabilities are greater than the credit memos (see the situation below).
- They are reversed with a payment voucher transaction (this is done when acknowledgment is received from the vendor that the liabilities are balanced with credits).
- When the total of the expenditure vouchers scheduled for payment for a vendor is greater than the total of all credit memos for the vendor, you owe the vendor money. The expenditure vouchers and the credit memo lines are printed on the Scheduled Payment Report, and a check is printed for the outstanding balance after the credit is taken. All the expenditure and credit memo voucher lines are represented on the check stub. They are also closed in Open Payment Voucher Line (1 of 2) (OPVL).
Scheduled Payment Date and Payment Lag
A scheduled payment date is stored in Open Payment Voucher Header (OPVH) for each 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 four methods shown below.
- If a date is entered on the document, that date is stored as the scheduled payment date.
- If a date is not entered on the form, the system looks in Vendor (1 of 2) (VEN2) to see if a value is recorded in the Scheduled Payment Day field on the Payment Information view for the vendor (this value is the day of the month when payment is due). The system calculates the scheduled payment date using this day and the appropriate month.
- If a payment day is not recorded in Vendor (1 of 2) (VEN2), System Control Options (1 of 2) (SOPT) contains a default system payment lag that is used for any vendor. The payment lag is the number of days from the voucher date when payment should be made. The system calculates the scheduled payment date using this payment lag.
- If the Schedule Discount Date option on System Control Options (1 of 2) (SOPT) is selected, the system calculates the optimum payment date for each payment voucher. This date is the last possible day that the voucher can be paid, and all the discounts still received.
A payment voucher document is submitted to end the expenditure processing chain for internal transactions. A manual warrant is not valid for internal transactions. To enter an internal payment voucher, you have two options:
- Enter a Payment Voucher (PV). The Voucher Type field on the payment voucher identifies the voucher as internal.
- Enter a payment voucher that is used specifically for internal transactions. The internal payment vouchers are: Internal Voucher (II) and Expense Transfer (IX).
- Payment Voucher Interface (PVI) and Payment Voucher for Procurement Desktop (PVP) are created automatically within the system through the ADVANTAGE and Procurement Desktop Interface.
Internal Purchase/Sale between Different Funds (type 2)
A type 2 payment voucher transfers money between funds, and posts appropriate accounting transactions to the General Ledger (GENLED) for both the buyer and the seller (revenue and accounts receivable transactions in the seller fund, and expenditure and accounts payable transactions in the buyer fund).
To enter this type of payment voucher, enter a Payment Voucher (PV) or Internal Voucher (II) document and enter 2 in the Voucher Type field.
The balance sheet accounts used on the offsetting entries are for a type 2 payment voucher are:
For the buyer the Offset Liability Account is blank:
- If the Internal Cash Voucher option in System Control Options (1 of 2) (SOPT) is set to Yes , then the cash account inferred through the buyer fund and bank account is used.
- If the Internal Cash Voucher option is set to No , then the Due To account on the Miscellaneous view of System Special Accounts (SPEC) is used.
For the seller the Offset Receivables Account is blank:
- If the Internal Cash Voucher Option in System Control Options (1 of 2) (SOPT) is set to Yes , then the cash account inferred through the seller fund and bank account is used.
If the Internal Cash Voucher Option is set to No , then the Due From Fund account on the Miscellaneous Options view of System Special Accounts (SPEC) is used.
At the end of each accounting period, all Due To Fund and Due From Fund accounts should be cleared with a journal voucher transaction. If separate bank accounts are involved, they can also be recorded on the journal voucher.
Inter- or Intra-Fund Reimbursement (type 4)
A type 4 payment voucher allows reimbursement of the seller by allowing an object rather than a revenue source in the seller accounting distribution. This type of payment voucher transfers money between different funds or transfers money to different accounts within the same fund.
To enter this type of payment voucher, you can either:
- Enter a Payment Voucher (PV) or Automated Payment Voucher (PVA) document and enter 4 in the Voucher Type field.
- Enter an Expense Transfer (IX) document. When the system processes the Expense Transfer (IX), it is posted to the ledgers as PV type 4.
If type 4 reimbursements are made between funds, the offsetting balance sheet account entries are generated as discussed for type 1 payment vouchers above. A type 4 reimbursement between different accounts in the same fund generate no offsetting entries.
Accounting Treatment of Internal Vouchers
When internal payment vouchers are used, MARS ensures that both revenue and expenditure entries from an internal purchase and sale are recorded simultaneously by generating both the invoice and voucher transactions. Accordingly, the internal payment voucher serves as the seller invoice and the buyer payment voucher. The specific accounting events are as follows:
- The MARS payment voucher generates both revenue and accounts receivable transactions in the selling fund, as well as the expenditure and accounts payable transactions in the buying fund. Standard offset payables (due to) and offset receivables (due from) accounts for such transactions are established in System Special Accounts (SPEC). Default cash accounts are used instead of the due to and due from accounts if the Internal Cash Voucher Option in System Control Options (1 of 2) (SOPT) is set to Yes . The default cash accounts are the accounts inferred through the Fund and Bank Account codes.
If Due To and Due From accounts are used, they must be cleared by a journal voucher transaction, as part of the month-end adjustments made before the accounting period is closed. The clearing occurs at the fund level.
- Intra-Fund Vouchers. If the seller is in the same fund as the buyer, the voucher records revenue to the seller and an expenditure to the buyer, but the balance sheet transactions are not required. Since intra-fund transactions do not affect the net assets or liabilities of the fund, these transactions have no balance sheet consequences. Therefore, MARS does not create either payables or receivables offset entries. For the same reason, intra-fund vouchers are not payable, but are considered closed when entered.
A payment voucher document is submitted to clear out an internal purchase order (unless the purchase order is canceled).
If the document is transferring money within a fund (type 4 vouchers), the payment voucher is also required, but no check is written, and a manual warrant is not allowed. Payment vouchers for intra-fund transfers are automatically cleared as soon as they are entered in the system. (The payment voucher must be submitted to clear the purchase order and to effect the change in the budgeted balance for the fund/agency involved.)
Partial and Final Payments Against Purchase Orders
A payment voucher line that references a purchase order can expense the purchase order line in full or partially. The Partial/Final indicator tells MARS whether to clear the purchase order line with this voucher, or to keep it open for a future voucher. The valid values are:
- Partial . This choice is optional.
- Final . Follow the guidelines below.
- If this payment voucher makes the total amount expended against the purchase order equal to the purchase order line amount, then the purchase order line is closed automatically by MARS.
- If this payment voucher makes the total amount expended against the purchase order less than the purchase order amount, but you want to force a close anyway (the item did not cost as much as expected), Final is required.
- If this payment voucher makes the total amount to be expended against the purchase order greater than the purchase order amount (the item cost more than expected), Final is required.
- Default . This is the default.
System Tolerance Logic on Purchase Order Closing Amounts
The System Control Options (SOPT and SOP2) windows contain a field labeled Tolerance . The values entered in this field establish a limit to the amount that can close a purchase order; for example, a limit to the amount that can be written on a payment voucher or manual 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 is only used on a final payment for a purchase order line.
Using the tolerance percent, the maximum amount allowed to close a purchase order is:
|
Percentage (Using the Tolerance Percent) of Recorded Purchase Order Amount |
If you try closing a purchase order with an amount that exceeds this maximum amount, the closing transaction (either a payment voucher or manual warrant) is rejected.
A tolerance percent of 0 indicates that the closing amount may not exceed the purchase order amount, while a tolerance percent of 99 indicates that the purchase order may be closed by almost twice its recorded amount.
If tolerance is expressed as a dollar amount, the calculated percentage amount in the equation is replaced by the specified dollar amount.
Separating the Acquisition and Use of Goods/Services
MARS distinguishes between the acquisition and the use of goods. Normally, the interval between the acquisition and use of goods is irrelevant for accounting purposes. However, in certain cases, like the acquisition of goods for inventory or prepaid items, a distinct time lag exists between acquisition and use. In these cases, the goods are recorded as an asset at the time of acquisition, funds are obligated, and the entry reflected on the balance sheet. As the goods are used, they are expensed and the corresponding entry is reflected as an expense on the income statement.
There is a type of transaction called Recording Only the Acquisition of Goods/Services (Expenditures) and is recorded in the general ledger as account type 23. This type of transaction identifies the purchase price of goods and services acquired when the purchase is to be recognized as an asset. The transaction is recorded on the balance sheet and is an obligation against the expense budget, but it is not reflected on the income and expense statement.
This transaction is recorded on a payment voucher or manual warrant, as follows:
- The Object code is required for budgetary comparisons and proper recording of the obligation.
- The Balance Sheet Account code is also required to override the expenditure/expense account that is otherwise inferred by the system.
The sample payment voucher in Figure 43 is coded to record the purchase of an inventory supply of gravel for road repair.
This type of transaction is recorded in the Current Detail General Ledger (GENLED) as follows:
Dr Expenditures (account type 23)
Cr Vouchers Payable (account type 02)
The dollar amount is the payment voucher or manual warrant line amount.
Dr Expenditures (account type 23)
Cr Vouchers Payable (account type 02)
Dr Reserve for Memo Encumbrances (account type 03)
Cr Memo Encumbrances (account type 19)
When the expenditure is a partial liability, the payment voucher or manual warrant line amount is used. When the payment voucher or manual warrant line is a final liability, the payment voucher line amount is used to record the balance sheet transaction, and the purchase order line amount is used to reverse the encumbrance.
Dr Inventory (account type 01)
Dr Expenditures (account type 23)
Dr Reserve for Memo Encumbrances (account type 03)
Cr Memo Encumbrances (account type 19)
Vendor Payment Voucher (P1) Document (Line Details View for External Payment)
When payment is partial, the amount used is the manual warrant line amount. When payment is final, the warrant amount is used to record the disbursement and the purchase order amount is used to reverse the encumbrance.
The Recording the Use of Goods/Services Previously Acquired (an Expense) is another type of transaction and is recorded in the general ledger as account type 24. It identifies the value of previously acquired goods and services consumed in the related budget period. Examples of this type of accounting include depreciation on previously capitalized fixed assets and the consumption of inventoried items previously booked as assets in inventory. This type of transaction is generally recorded in MARS on a journal voucher document. Follow the steps below to enter the journal voucher.
- Enter one line using an appropriate balance sheet account and fund; use account type 11 (asset offset to expenses); this is usually the credit line.
- Enter the offsetting line with an account type 24 and a blank balance sheet account column; code Object, Fund, and Agency. These codes should match the codes used on the payment voucher or manual warrant that recorded the acquisition of the goods/services. This is usually the debit line.
The sample journal voucher in Figure 44 is coded to record the depletion of an inventory supply of gravel.
Journal Voucher Master (JVM) Document
This type of transaction is recorded in the Current Detail General Ledger (GENLED) in the following manner:
Cr Asset Offset to Expenses (account type 11)
The effect of this transaction is a reduction in the asset account and no impact on the budget, since account type 24 does not update the expense budget table.
Marking Payment Vouchers for EFT
A payment voucher may be marked for Electronic Funds (EFT) payment by selecting Yes in the EFT field on the Other Attributes view and using a valid Application Type code. The vendor used on the payment voucher must be EFT active ( EFT Status on Vendor (1 of 2) (VEN2) is Active ).
If, however, one or more payment voucher lines do not reference vendor invoices, or if all vendor invoices are not marked for EFT, the user must enter the EFT indicator in the header of the payment voucher document. Similarly, if the application types on all referenced vendor invoices are not the same, the user must enter the application type on the header of the payment voucher. The payment voucher may also infer the EFT application type from the vendor ( EFT Status on the Payment Information view of Vendor (1 of 2) (VEN2) is filled in). If the payment voucher does not reference any vendor invoices and the vendor is EFT active with an EFT type filled in, the EFT indicator and application are set on the payment voucher.
Testing Payment Voucher Amounts
Payment voucher document amounts are tested in the following ways.
- When budgetary full controls are in effect, the unobligated balances must be greater than a new obligation or a net change in obligations.
- When fund balance control is in effect, the new obligation or a net obligation change cannot decrease the fund balance control amount to a level below the minimum amount established in Fund Balance (FBAL).
- A decrease transaction cannot reduce the payment voucher to less than the payment voucher closed amount.
- The payment voucher cannot make the amount expended against a purchase order exceed the tolerance limits set recorded in the System Control Options (1 of 2) (SOPT) or Fund (FUN2).
Accounting Model and the Ledgers
When a payment voucher transaction is processed by MARS, ledger records are posted to the Current Detail General Ledger, the Open Payment Voucher Ledger, and the Open Purchase Order Ledger (if a purchase order has been referenced). Due to the numerous uses of the payment voucher, one of several different accounting models may be used to record the accounting event.
The figure below presents the accounting model used for a payment voucher referencing a base system purchase order. Depending on the nature of the payment voucher, however, one of the following accounting models is used.
Accounting Model for a Payment Voucher Referencing a Purchase Order
Below are accounting models for other payment vouchers.
Cr Liabilities (Vouchers Payable)
The amount used is the payment voucher line amount.
Cr Liabilities (Vouchers Payable)
The amount used is the payment voucher line amount.
Cr Liabilities (Vouchers Payable)
When the liability is partial, the amount used is the payment voucher line amount. When liability is final and is different from the purchase order amount, the payment voucher amount is used to record the expenditure, but the purchase order amount is used to reverse the encumbrance.
The vouchers payable balance sheet account is inferred from System Special Accounts (SPEC), unless the offset liability account is entered on the payment voucher.
MARS contains the following Open Voucher tables:
- Open Payment Voucher Line (OPVL)
- Open Payment Voucher Header (OPVH)
- Open Payment Voucher by Document Number (OPVD)
- Open Payment Voucher by Vendor Name (OPVV)
- Open Voucher Invoice Header (OVIH)
When a payment voucher document is processed, a line is created in the Open Payment Voucher Line (OPVL) table for each line on the document. One line is also created in the Open Payment Voucher Header (OPVH) table containing summary data from the header portion of the document. One record is created in the Open Payment Voucher by Document Number (OPVD) table that contains only the key information of Voucher Number and Vendor code. Open Payment Voucher by Document Number (OPVD) is useful in locating payment vouchers when you know the voucher number, but not the vendor number. The user can browse this window until the appropriate payment voucher number and vendor combination is found. The user then specifies Related Data on the Display menu and the system automatically retrieves the appropriate record on the Open Payment Voucher Header (OPVH) table. If modifying transactions are accepted, the entries in the open item tables are updated to reflect the modifications.
A payment voucher line is considered closed when the outstanding amount is zero, or when it is forced closed by setting the Partial/Final indicator on the referencing transaction to Final . For example, a payment voucher of $257.49 with a line (that references a purchase order) set to Final can force closed a $260.00 purchase order line.
A record in Open Payment Voucher Header (OPVH) is closed when all of its related lines are closed in Open Payment Voucher Line (OPVL). When an open item record is considered closed, MARS adds a closing date and closing amount to the record.
Type 2 vouchers are not added to this table. Type 2 (inter-fund) vouchers are summarized at the fund level in the Due To and Due From accounts, and should be cleared with journal voucher transactions at month-end, or they are posted directly to cash.
When a manual warrant or check is written against a payment voucher line, the date and number of the check or manual warrant are added to Open Payment Voucher Line (OPVL). Vendor Payment Cross Reference (VXRF) will display all payment voucher lines that have checks or manual warrants written against them.
Entries are also added to Open Vendor Invoice Header (OVIH) when new payment voucher transactions with an invoice number accepted by MARS. 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 (OVIH) with a type 3 vendor invoice. If the invoice number already exists on Open Vendor Invoice Header (OVIH), the payment voucher is rejected with the overrideable error message; "Record Already on OVIH". You can then research why this invoice number is on Open Vendor Invoice Header (OVIH) and decide whether to override the error. Lines are deleted from the table at the end of an accounting period when they have been closed for one entire accounting period.
The Vendor Payment Voucher (P1) document provides a simplified window for payment voucher documents. The document contains both header and line data on one window, so it can be used for any vendor payment voucher. The Vendor Payment Voucher (P1) is entered to record the receipt of goods ordered by a previous purchase order, plus service charges that were not previously encumbered. Internal transactions cannot be processed on the Vendor Payment Voucher (P1). For more information, see the User's Reference .
Multiple Vendor Payment Voucher (MP)
The Multiple Vendor Payment Voucher (MP) document creates Multi-Payee Payment Voucher Detail (PVV) documents with the same accounting distribution. The Multi-Payee Payment Voucher Detail (PVV) documents generated by the Multiple Vendor Payment Voucher (MP) are placed in the Document Listing (SUSF) with a scheduled status. All document approvals necessary for Multi-Payee Payment Voucher Detail (PVV) documents must be applied before the generated Multi-Payee Payment Voucher Detail (PVV) are processed. After Multiple Vendor Payment Vouchers (MPs) are approved and processed, approvals are carried to the Multi-Payee Payment Voucher Detail (PVV) document.
Multiple Vendor Payment Voucher (MP) documents have the following restrictions:
- They cannot be modified.
- They cannot make a prior document reference to a purchase order or a requisition.
These restrictions can be bypassed by adjusting the generated Multi-Payee Payment Voucher Detail (PVV) documents before they are processed.
Multi-Payee Payment Voucher Detail (PVV)
The Multi-Payee Payment Voucher Detail (PVV) document provides users with a fast, easy means of identifying which vouchers have been created by the multiple vendor payment voucher. These documents cannot be modified since approvals are applied to the Multiple Vendor Payment Voucher (MP).
Payment Voucher for Procurement Card (PVC)
The Payment Voucher for Procurement Card (PVC) is created by Procurement Desktop (PD) for Procurement Card (ProCard) purchases. The Procurement Card (PVC) document is interfaced with MARS Advantage as a Payment Voucher to the cardholder.
Payment Voucher for Procurement Desktop (PVP)
The Payment Voucher for Procurement Desktop (PVP) is created by Procurement Desktop (PD). The Procurement Card (PVP) document is interfaced with MARS Advantage as a Payment Voucher.
A manual warrant document records manually written checks in the system. The manual warrant document results in MARS obligating a fund (if not already done by a referenced document), and adjusting cash balance sheet accounts.
One manual warrant document represents a single check. A manual warrant can be the first, and only, document in the obligation chain. However, the manual warrant is usually preceded by requisitions, purchase orders or payment vouchers. The appropriate requisition, purchase order, or payment voucher is referenced on the manual warrant, so the appropriate lines are updated on the open item master tables. Amounts on manual warrants can vary from the amounts on referenced requisitions, purchase orders, or payment voucher lines.
Most actions performed on payment vouchers are also performed on manual warrants. The difference is that payment vouchers post to liability accounts, and manual warrants post directly to cash. The discussions in the payment voucher section which also apply to manual warrants include refunds and separating the acquisition and use of goods and services.
Manual Warrant Fedwire (MWW) is a transaction that records Federal Wire Transfers. It works very similar as a MW. The only difference between the two is that MWW has an Effective Date . This date is used to record actual transfer date. It is updated to WREC as Cleared Date. A batch program clears the MWW check automatically when the Effective Date is reached.
A Manual Warrant/Investment (MWI) document is used exclusively for investment purposes. The Manual Warrant/Investment (MWI) document works similar to the MWW, it records manually created fedwires, for the purchase of investment securities.
Testing Manual Warrant Amounts
Manual warrants are subject to the same tests as payment vouchers. Manual warrant document amounts are tested in the following ways.
- When budgetary full controls are in effect, the unobligated balances must be greater than a new obligation or a net change in obligations.
- When fund balance control is in effect, the new obligation or a net obligation change cannot decrease the fund balance control amount to a level below the minimum amount established in Fund Balance (FBAL).
- A decrease transaction cannot reduce the manual warrant to less then the closed amount of the referenced transaction.
- The manual warrant cannot make the amount expended against a purchase order exceed the tolerance limits set recorded in System Control Options (1 of 2) (SOPT) or Fund (FUN2).
Manual warrants cannot be entered for a vendor that is subject to backup withholding. See Backup Withholding for more information.
Posting Manual Warrants to Ledgers
Manual warrant lines are posted to the Current Detail General Ledger (GENLED) in the following manner:
The amount posted is the manual warrant line amount.
The amount posted is the manual warrant line amount.
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.
The amount posted is the manual warrant line amount.
Document Control Inquiry (DCTL) tracks manual warrant document numbers used within an accounting period. Document Control Inquiry (DCTL) also tracks cash receipts, journal vouchers, and payroll vouchers. There is one line in Document Control Inquiry (DCTL) for each manual warrant document accepted by the system, for each open accounting period. The line contains only the accounting period, the document number, and the date of record. The purpose of Document Control Inquiry (DCTL) is to prevent the use of duplicate document numbers within an accounting period. Accounting Period is a key field in the Document Control Inquiry (DCTL) Inquiry window.
When the table clearing process is run monthly, all lines in the table associated with the accounting period being closed are removed from Document Control Inquiry (DCTL).
An explanation and detailed field descriptions of Document Control Inquiry (DCTL) is provided in the User's Reference .
The Bank Account Code field is required on all manual warrants. The Cash Account is optional; if it is blank, the system infers the cash account through the Bank Account code. The Vendor Control Option on System Control Options (1 of 2) (SOPT) applies to all warrants except when a Receiving Fund is coded.
On the line level, Fund, Agency, and Object are required on transactions that represent a liquidation of liabilities. Depending on the value of the Expense Budget Organization Option, Expense Budget Activity Option, and Expense Budget Function Option (on Fund Agency (FGY2), the Organization, Activity, and Function codes may also be required. Other codes are optional. The Fund Balance option (on the Control Options view on Fund (FUN2)) and the budgetary controls (Appropriation, Allotment, and Expense Budget controls on Fund Agency (FGY2)) also apply to warrants.
For refunds, Revenue Source is coded instead of Object. The Revenue Budget options control this type of transaction.
On balance sheet transactions, both Revenue and Object are blank, and the Balance Sheet Account code is provided. Depending on the value of the Reporting Category Option (on Balance Sheet Account Index (BACC)), the Reporting Category may be required. Other codes are optional.Purchase orders, payment vouchers, and payroll vouchers may be referenced by manual warrants.
When a manual warrant references a payment voucher, the warrant does not result in a debit to the expenditure accounting distribution. This was done by the payment voucher. The manual warrant liquidates the liability created by the payment voucher.
When coding this type of transaction, the accounting distribution must match the referenced payment voucher. (If the Prior Document Reference option field on System Control Options (2 of 2) (SOP2) is set to Yes , the accounting distribution does not have to be entered.) The only new code that may be added to the accounting distribution is the Balance Sheet Account. If you want to include the Balance Sheet Account on the transaction for reporting purposes, it must be the liability account of the referenced payment voucher from Open Payment Voucher Header Inquiry (OPVH).
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 is assigned a Voucher Closing Date on Open Payment Voucher Line Inquiry (1 of 2) (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 Voucher Closing Date. The scheduled payment date is deleted from the record.
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 is paid the next time the voucher is selected by the cash disbursement program.
If you are using tax on the referenced payment voucher, it is assumed a manual warrant representing a partial payment against that voucher is part of the untaxed amount. Therefore, if the remainder of the payment is made through the automated disbursements process or other automatic payment method, the full amount of the tax entered on the payment voucher will be included in the final check.
If the manual warrant amount (or the closed amount plus the current manual warrant amount in the event that more than one manual warrant is written against the same payment voucher) is greater than or equal to the untaxed amount of the line and the Tax code for that line is a use type, the line will be closed. In this event, the total line amount will be moved to the closed amount, although the total amount of manual warrants will be shown in the disbursed amount on Open Payment Voucher Line Inquiry (1 of 2) (OPVL).
The Partial/Final indicator does not apply to lines referencing payment vouchers. Any remaining liability is reduced using a payment voucher modify transaction.
On the line level, Fund, Agency, and Object are required on the transactions that represent liquidation of liabilities. Depending on the value of the Expense Budget Organization Option, Expense Budget Activity Option, the Expense Budget Function Option (on Fund Agency (FGY2)) and the Sub-Object Option (on Fund (FUN2), the Organization, Activity, Function, and Sub-Object codes may also be required. Other codes are optional. The Fund Balance option (on Control Options of Fund (FUN2)) and the budgetary controls (Appropriation, Allotment, and Expense Budget controls on Fund Agency (FGY2)) also apply to warrants.
For refunds, Revenue source is coded instead of Object. The Revenue Budget options control this type of transaction.
Payment voucher lines with manual warrants written against them are displayed on Vendor Payment Cross Reference (VXRF), which is an alternate view of Open Payment Voucher Line Inquiry (1 of 2) (OPVL).
Manual warrants may not reference Extended Purchasing documents which use Tax codes. If you wish to process a manual warrant against an Extended Purchasing document must first complete a payment voucher transaction referencing the Extended Purchasing document, and process the manual warrant referencing the payment voucher.
Figure 47 shows a sample manual warrant window entered to reflect a partial payment against a payment voucher.
The recurring payment voucher capability of MARS automatically generates documents on a monthly, bi-monthly, quarterly, or end-of-quarter basis using data that users previously entered in a window. The information is entered only once, along with start and end dates and an frequency controlling how often the document is generated. An offline program run by the computer operations personnel actually generates the documents and adds them to the Document Listing (SUSF). Users can then access the documents in correction mode, change them, if desired, and process them.
This facility is useful for accounting events such as rent payments, utility payments, quarterly tax payments, etc. Information is entered in Recurring Payment Voucher (REPV) and data is validated during data entry. Codes are validated against the entry start date and fiscal year. Recurring Payment Voucher (REPV) and Recurring Journal Voucher (REJV) will also perform edits against Fund (FUN2) if the Expense Budge t and Appropriation Control Options are set to Full .
If you are using Tax Codes, the codes are validated on Tax Code (TAXT) and header Tax Codes (if entered) are inferred to the lines, but no other inference occurs from any other source. These types of validation occur when the documents are added to the Document Listing (SUSF) and processed by the payment voucher document processor. Also note the following points about entering data in Recurring Payment Voucher (REPV).
- Since the user does not always know the exact line amount when the recurring information is being entered, the Line Amount field may be blank. If it is, the system places the words FILL-IN in the Line 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 document is added to the Document Listing (SUSF) and change it there.
- You may enter incomplete previous document references. For example, you may enter the Reference Transaction ID without the Line number. The reference can be completed either in Recurring Payment Voucher (REPV) or in the Document Listing (SUSF).
The Frequency field on Recurring Payment Voucher (REPV) indicates how often the document is generated. Valid values are:
- One-Time Future Document . This transaction is for one-time in the future.
- Monthly . This is a monthly transaction.
- Bimonthly . This is a bi-monthly transaction (every other month).
- Quarterly . This is a quarterly transaction.
- End of Quarter. This is an end of quarter transaction (last month of quarter).
Your computer operations personnel should be notified when to run the recurring payment voucher offline program. See the System Administration Guide for the required parameters.
The generated documents have accounting periods as follows:
- If the current accounting period and budget fiscal year parameters are provided in the Date (DATE) entry for the offline programs, those values are used on the generated documents.
- If the Date (DATE) parameters are blank, those fields are blank on the generated documents, and are inferred from the document's transaction date by the payment voucher document processor. The transaction date on the generated documents is the date the program was run (run date).
The to-date parameter determines whether particular entries should be selected for transaction generation.
- If the start-date of the entry is after the to-date, the entry is not selected.
- If the end-date of the entry is before the to-date, the entry is not selected (it is deleted).
- The program compares the entry's latest date posted field and the to-date parameter to determine whether it is time to generate another document for the entry.
The to-date parameter is also used for the following purposes:
- It becomes the latest date posted field for selected entries.
- It becomes the batch date and transaction date for the generated payment voucher documents.
- If the end-date of the recurring entry is before or equal to the to-date, the entry is deleted.
The recurring payment vouchers can be batched by entering a four digit alphanumeric identifier in the Batch Number field. The document number and batch number of each payment voucher is composed of the payment voucher number and batch number from the Recurring Payment Voucher (REPV) entry, followed by the to-date month from the document's Dates (DATE) entry (blanks are replaced by zeros). The documents are loaded to the Document Listing (SUSF) in a "scheduled for offline processing" status.
Selection Examples for Recurring Payment Vouchers
The following illustration shows the relationship between the various dates in the selection process for recurring payment vouchers. Y in the selected column indicates that a document was generated and added to the document database. Y in the deleted column indicates that the entry in Recurring Payment Voucher (REPV) was deleted.
(*) When the ending date equals the to-date, the entry is selected (for example, a document is generated 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 not be selected for two succeeding months. It is not selected again until the to-date is 07-01-00.
(***) A frequency of E means third month of each quarter. The above example for E assumes that 1/1/00 is the first month of a fiscal quarter and 3/1/00 is the third month of the same quarter. This entry would be selected again on 6/1/00, 9/1/00 and 12/1/00 and would then be deleted on 12/1/00.
Two processes disburse funds based on vouchers payable information in the Open Payment Voucher Header (OPVH) and Open Payment Voucher Line Inquiry (OPVL, OPV2) windows. 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. Both processes take discounts and vendor credits into account before the payment is made.
The payments are selected for transfer or printing based on selection criteria provided by the user. A voucher pre-selection can be made, with the results printed on a report, before the actual selection and payment occurs. Cash balances are validated against the cash table after the pre-selection reports are printed. These reports are generated again after the cash balance is validated. These reports display which vouchers do not have sufficient cash and have been skipped by the automated disbursement process.
After the checks are approved, the funds are selected and checks are printed. After transfers are approved, funds are selected then transferred. The disbursement reports, such as the check register or the transfer register, are then produced. These reports should be checked prior to running the final process to post the disbursements ledger records to the general ledger. If the check register does not match the actual checks (due to an operational error during the disbursements process) and the records have not been posted to the general ledger, a reprinting and renumbering program can be run to correct check errors. The example that follows shows the sequence for processes used in the automated disbursement process.
The cash disbursement process is initiated by requesting your computer operations personnel to run two reports. If you are printing checks you need the following reports to run before cash balance is checked:
If you are transferring funds you need the following reports to run before cash balance is checked:
- Scheduled Payment Turnaround Report (A655B)
- Unscheduled Payment Turnaround Report (A656B)
- EFT Scheduled Payment Turnaround Report (EF01B)
- EFT Unscheduled Payment Turnaround Report (EF02B)
Reports A655 and EF01 list all outstanding payment vouchers that were selected based on the parameters provided. A656 and EF02 display all outstanding vouchers that were not selected for the first report (vouchers that were put on hold in SCHD). Line detail from Open Payment Voucher Line Inquiry (OPVL, OPV2) is included on each of these reports.
The A655, A656, EF01 and EF02 reports select records from Open Payment Voucher Header (OPVH) and Open Payment Voucher Line Inquiry (OPVL, OPV2). You should supply parameters to select the appropriate records to the computer operations personnel when you request the reports you need. See the System Administration Guide for a listing of the parameters. The computer program that generates the reports uses the parameters specified on Automated Disbursements Parameter (ADIS). The `B Reports' display the vouchers that show up in the `A Reports' and the vouchers skipped because of insufficient cash.
The Check Disbursement and Electronic Funds Transfer Process
In addition to the payment voucher line detail, the voucher preselection reports summarize all vouchers selected by vendor, and calculate a total amount for each vendor. Only one check or transfer is written per vendor, even if multiple voucher documents exist for the vendor (unless the Single Check Requested option is selected on the General Information view of Vendor (1 of 2) (VEN2)). The summarized amount includes any credit memos (vendor owes the entity money) that may exist for the vendor. It does not include discounts. Discount qualification is based on the number of days between the voucher date and the check date. Since the checks have not actually been created, discounts cannot be calculated. Discount calculation is meaningful only when the payment is actually made through the check generation process.
Payment Voucher Scheduling (SCHD) lets users change the Scheduled Payment Date, the Check Category, the EFT Indicator, Hold Indicator and the Single Check Flag of vouchers in Open Payment Voucher Header (OPVH). It also lets users place vouchers on hold. This prevents them from being paid regardless of their Scheduled Payment Date. This window is also used to remove the hold status from a voucher or override cash for a voucher.
When you access Payment Voucher Scheduling (SCHD), you are actually accessing a portion of Open Payment Voucher Header (OPVH). Changes made on this window are actually changes to Open Payment Voucher Header (OPVH). All maintenance actions to Payment Voucher Scheduling (SCHD) are changes.
To change the scheduled payment date, get the desired voucher, and change the Scheduled Payment Date field. Note that the date is entered as month-day-year ( MMDDYY ). Type the new date in the same format.
To place a voucher on hold, display the desired voucher (by selecting Get Specific Data from the Display menu) and type H in the Hold Payment Indicator field. To remove a voucher from hold, delete the H from the field. Always check the Scheduled Payment Date field when you remove a voucher from on hold. To override cash for a voucher type O in the Hold Indicator field. An S in the Hold Indicator field means the AD process has tried to process the voucher, but found insufficient cash in the CASH table. All vouchers that have and S on SCHD table will be processed again by AD and a check will be written or transfers will be made if there is sufficient cash.
A similar process used to schedule payment vouchers that have been batched to print. To schedule, hold, or override payment vouchers that have been batched, go to the Override Payments by Batch (OVBA) table. The Payment Voucher Information (PVBA) table is used as an inquiry table for this information.
To change a voucher's EFT status, display the desired voucher and select No in the EFT field. You may only change a voucher from EFT eligible to not EFT eligible.
Payment Voucher Scheduling (SCHD) applies to an entire document. (Each record in Open Payment Voucher Header (OPVH) represents a payment voucher document.) You cannot place 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. You can make partial payments against a voucher document with manually written checks, and then record them in the system on a manual warrant. When this occurs, the cash disbursement process pays the remaining outstanding amount the next time the voucher is selected for payment.
Once vouchers are selected they are run against the Vendor Offset programs. If the vendor has outstanding debt, the payment will be intercepted. Refer to the Vendor Offset section for details. At the end of the Automated Disbursements, the following reports are generated for `Vendor Offset'.
- VOFT-A Vendor Offset Funds
- VOFT-B Vendor Offset Detail Intercept Report
- REIP Detail Listing of Receivable Intercept Payments
Vendor Offset is a process to intercept payments to vendors who have outstanding debts. A vendor with an outstanding debt to the Commonwealth of Kentucky is considered to be a debtor vendor. A state agency with an outstanding claim against a debtor vendor creates a debt record. The disbursement process (both Automated Disbursements and Check Writer) checks the debtor vendor file and, if there is a match, the payment to the vendor will be intercepted. The intercept amount will be equal to or less than the payment amount. If there is more than one claim against a vendor, claims are processed in the order of their priority. The intercepted amount is then transferred to the claiming agency.
If the outstanding debt is represented in MARS as a receivable, the debt should be established via the Warrant Intercept (WINT) table. A batch program will read WINT and automatically create a Vendor Offset (VO) transaction to establish the debt. When the debt is satisfied, a Cash Receipt transaction will be automatically generated and update the Open Receivable header/Line (OREH and OREL) tables.
When a payment is intercepted, the original payment amount is closed on the Open Payment Voucher Header (OPVH). The intercept amount is transferred to a holding account which is specified by the user on the Vendor Offset Parameter Table (VOPT). The intercept amount will then be transferred form this holding account to an agency specific account. The agency specific account is set up by the claiming agencies on the Claim Agency Account (CAAC) table. If the transfer is to an internal claiming agency, a journal voucher (JVM) is generated. If the transfer is to an external claiming agency, a payment voucher (PV) is generated.
Accounting model for the vendor offset process is as follows:
Dr Expenditure (entire accounting Line)
Cr Vouchers Payable (entire accounting line)
Dr Vouchers Payable (entire accounting line)
Cr: Cash (entire accounting line)
Vendor Offset for non-receivables:
1. Intercept Process (VOPIA and VOPIC) -
Dr Cash (vendor offset holding accounts from VOPT)
2. Fund Transfer Process (VOFT) -
JVM (transfer to an internal agency):
Dr Liability (vendor offset holding accounts from VOPT)
Cr Cash (vendor offset holding accounts from VOPT)
Dr Cash (accounting line from CAAC)
Cr Revenue (accounting line from CAAC)
PV (transfer to an external agency):
Dr Liability (accounting line form CAAC)
Cr Vouchers Payable (accounting line from CAAC)
Vendor Offset for Receivables:
1. Intercept Process (VOPIA and VOPIC) -
Dr Cash (vendor offset holding accounts from VOPT)
Cr Liability (vendor offset holding accounts from VOPT)
2. Fund Transfer Process (VOFT) -
Dr Liability (vendor offset holding accounts from VOPT)
Cr Cash (vendor offset holding accounts from VOPT)
Dr Cash (accounting line from OREL)
Cr Receivable (accounting line form OREL)
Disbursement Selection, Check Printing and Tape File Creation
Voucher selection, payment calculation, tape file creation, and check printing are performed by the payment disbursement programs. These programs are controlled by parameters that you specify and provide to the computer operations personnel when requesting either check printing or tape file creation. See the System Administration Guide for a listing of these parameters.
Both the cash disbursement process and the fund transfer process select vouchers from Open Payment Voucher Header (OPVH) and Open Payment Voucher Line Inquiry (OPVL, OPV2). The cash disbursement program summarizes all vouchers selected by check category, vendor, and single check flag. A total amount is calculated within each check category for each vendor, with the exception of those vouchers marked Yes for Single Check flag (see below). One check is written for each vendor in each check category and for each voucher marked Yes for Single Check . A vendor may appear under any number of check categories.
The 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 Yes for Single Check (see below). One transfer record is written for each vendor in each application type and for each voucher marked Yes for Single Check . A vendor may appear under any number of application types.
Vouchers with a Single Check of Yes 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 Yes for single check (transfer) printing. The check or transfer amount takes into account all applicable discounts and any existing credit memos (discussions are found in the sections that follow).
The cash disbursement cycle has the following effects on various system files:
- Creates a file that is used to produce reports A657 and A658.
- Updates the expense budget, appropriation, allotment, and fund balance tables, depending on the spending control in effect, if any discounts were taken or penalties were paid.
- Generates records for the following files: Current Detail General Ledger, Open Payment Voucher Ledger, Cash Ledger, and Job Ledger.
- Updates the Open Payment Voucher Header and Line tables (affected fields are: Closed Amount, Disbursed Amount, Voucher Closing Date, Outstanding Amount, Last Check/MW Number, and last check Date).
- Adds the check to Warrant Reconciliation (1 of 2) (WREC) with a status of Open .
- Adds the check to OPCH, OPCA and OPCL.
Checks and check stubs are printed on the pre-printed forms used by your installation.
The effect of the electronic funds transfer cycle is the same as the cash disbursement cycle except the electronic transfer cycle does the following:
- Creates a file that is used to produce EF03 and EF04, instead of A656 and A657.
- Creates a file that may be written to tape to be sent to the bank.
- Adds the transfer to Warrant Reconciliation (1 of 2) (WREC) with a status of Open , instead of a check.
- Adds the electronic funds number to OPCH, OPCA, and OPCL.
The Check Stub for Disbursements
Lines on the check stub summarize amounts by payment voucher transaction number and vendor invoice number. Separate lines exist on the stub for vendor offset information including claiming agency code, claiming agency name, contact phone number and offset amount.
The EFVS Report for EFT Disbursements
A report is generated by the Final EFT Voucher Selection (EFVS) process whenever a voucher which could have been paid electronically is not paid because the vendor is no longer EFT active. Vouchers present on this report are changed by the EFVS process to be non-EFT. (The EFT Indicator on Open Payment Voucher Header (OPVH) is changed to No and the Application Type is changed to spaces .)
The cash disbursement cycle produces two reports:
The funds disbursement cycle produces the following report:
Samples of these reports and brief descriptions are included in the Reports guide.
Automated Disbursements - Other Issues - (Not Used in MARS)
Check Voiding, Reprinting, and Renumbering
Check voiding lets you mark certain check numbers as void in the Check Register Report (A657) so that a hard copy report is available to account for every check in your stock. Voided checks occur in the disbursement process as a result of printer alignment tests, printer malfunctions, or stub overflow.
Check reprinting is performed when a check is damaged or destroyed during the printing process so that it can replaced. When the check is reprinted it is assigned a new check number.
Check renumbering makes it possible to change the check numbers in the MARS ledger records so that reports such as the check register reflect the correct numbers. Check renumbering is necessary when the number on the printed check does not agree with the number recorded by the check register. An operator error while printing the checks, a printer malfunction, or an incorrect starting check number in Automated Disbursements (ADIS) can cause an inconsistency between the check register and the actual checks.
Check reprinting, renumbering, and voiding is accomplished by running a special program. The parameters required for this program are entered in ADIS. For a range of check numbers, indicate either a void, reprint, or renumber action. Up to five ranges can be entered. If additional checks are affected, rerun the program with additional parameters. See the System Administration Guide for a list of the required parameters.
Check renumbering and reprinting is only done before the transactions are posted to the ledger files by the final disbursements process (AFINADPR). If this process has already run, the records remain as they are, with the incorrect check numbers; or, you can cancel the checks and reissue them. (See Check Voids.)
Transfer voiding lets you mark certain transfer numbers as void in the Funds Transfer Register Report (EF03) so that a hard copy report is available to account for every transfer made. Voided transfers occur in the disbursement process as a result of bad or lost tapes, misreading, or computer malfunctions.
If a Discount Type code exists on a payment voucher line, the payment disbursement program first determines whether the discount is valid. If it is valid, it calculates the amount. Discount Type (DISC) defines a number of days and a percentage discount for each discount type. If the number of days between the voucher date and check or transfer date is not greater than the Number Of Days field in Discount Type (DISC), then the discount is taken. Otherwise, the discount is not calculated.
If the Discount Day is used, then the last day when payment can be made without losing the discount is computed as follows.
- If the voucher date is less than the discount day, the last possible payment date will be the nth day of the month when the voucher was entered, n being equal to the discount day.
- If 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 when the voucher was entered, n being the discount day.
If the check or transfer date falls prior to the last possible payment date, the discount is taken. Otherwise, the discount is not taken. The discount amount is calculated by applying the percentage in Discount Type (DISC) against the payment voucher line amount.
If you are using tax on the voucher being paid, then the amount of tax to be paid may be recalculated. If the Recalculate Tax From Discount on Extended Purchasing Systems Option (ESOP) is set to Yes and a discount is taken, the amount of tax is recalculated based on the untaxed line amount less the discount taken. The difference between the old and recalculated tax amounts is the tax adjustment and this amount will be shown on Open Payment Voucher Line Inquiry (1 of 2) (OPVL).
When a discount is taken, the program generates expenditure transactions that refund the discount amount (and tax adjustment, if any) back to the accounting distribution on the payment voucher line. (No special accounting distribution exists 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. If a job number is used on the originating payment voucher, the discount amount is posted to JOBLED.
For cash disbursements, discounts taken (and if using Tax codes, the amount of recalculated tax) are shown on the check stub. The check stub discount lines (and tax recalculation lines) are summarized by vendor invoice number within each payment voucher document.
Since the voucher pre-selection program does not consider discounts, scheduled payment amounts on the Scheduled Payment Turnaround (A655) and EFT Scheduled Payment Turnaround (EF01) reports may be different from the actual check or transfer amount. Sometimes the discount amount makes the difference between whether the entity owes the vendor money or not. When this occurs, the vendor is listed on the A655 or EF01 reports, but no check is written or funds transferred by either disbursement 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 or a transfer made because it is now perceived that money is owed. To prevent this, the voucher should be reversed (with a decrease payment voucher), so it is considered closed.
You should periodically analyze the Discounts Taken/Lost Report (A658 or EF04). If discounts are being lost on a regular basis, you may need to adjust payment policies or discount types.
Credit memos represent money owed to the entity by the vendor. They are entered in MARS as original entry decrease payment vouchers, and stored in Open Payment Voucher Header (OPVH) and Open Payment Voucher Line (OPVL, OPV2) as negative amounts. Both voucher pre-selection and the payment disbursement programs consider credit memos before calculating the check or transfer amount to a vendor. Credit memos are currently not allowed in MARS.
The automated disbursement process handles these two situations when a credit is involved.
- The credit is not enough to cover the liabilities, and even when the credit is considered, the entity still owes the vendor money. In this situation, the check is written or the transfer made for the outstanding balance over the credit. All liability records considered and the credit record are reflected on the check stub (if there is one). Also, all liability records and the credit record are closed on Open Payment Voucher Line Inquiry (1 of 2) (OPVL). The corresponding entry is assigned a closing date in Open Payment Voucher Header (OPVH).
- The credit exactly balances the liabilities, or the credit is more than the liabilities. When this occurs, no check is written or transfer made, and none of the records involved are closed on Open Payment Voucher Header (OPVH) and Open Payment Voucher Line Inquiry (1 of 2) (OPVL). The records remain open in these tables until the liabilities become greater than the credit.
If late payment penalties are used at your installation, the payment disbursement program determines if any penalty should be included with the payment voucher line amount in the check amount. When attempting to void a check/manual warrant with a penalty imposed, use a manual warrant reversal document, not a CX.
Whether to impose a penalty is determined by comparing the check or transfer date with the voucher date. If the time lapse between the two dates is greater than the penalty lag (as specified on System Control Options (SOPT, SOP2), then a late payment penalty is computed. The penalty is equal to the penalty percentage (also specified on SOPT, SOP2) of the unpaid balance of the payment voucher line amount.
Before imposing the penalty, the cycle checks any spending controls that are in effect. If the penalty does not pass all spending controls, the payment voucher line (and the purchase voucher) is left open and unpaid. In addition, the payment voucher line, the penalty amount, and the spending control check that failed are written to the Final Voucher Selection (ADVS) Exceptions report (ADEX) for cash disbursements or EFT Vouchers Not Paid (EFVS) Exceptions report (EFEX) for electronic fund transfers. Both reports are produced from the Final Voucher Selection (AFINADVS) process.
If the penalty passes all spending controls, the amount of the penalty is added into the check or transfer amount. Depending on the spending controls in effect, the appropriate budget tables are updated with the amount of the penalty.
Since the voucher pre-selection program does not consider penalties (or discounts), scheduled payment amounts on the A655 and EF01 reports may be different from the actual check or transfer amount. Also note that if you are using Tax Codes, tax will not be recalculated for a penalty, even if the Recalculate Tax From Discount flag is Y on EPS System Control Options (ESOP).
You should review the Final Voucher Selection (ADVS) exceptions report (AFINADEX) after each run of ADVS (or the EFT Vouchers Not Paid (EFVS) exceptions report (AFINEFEX) after each run of AFINEFVS for fund transfers) so that unpaid vouchers can be identified and the situation corrected. If many unpaid vouchers exist after each disbursement cycle, payment policies or the penalty lag may need adjusting.
Vendors that are required to file quarterly income statements using IRS form 1099 must also furnish payers with correct and complete 1099-related tax information. This information includes: a valid taxpayer identification number (TIN), a valid Federal ID type code, and a correct Name Control code. In the event that this information is not furnished to the payer, funds may be automatically withheld from portions of vendor payments that pertain to 1099-reportable objects by selecting the Backup Withholding option in System Control Options (1 of 2) (SOPT). The Backup Withholding Indicator must also be Yes in Vendor (2 of 2) (VEN3). The percentage of the payment withheld is specified in the System Control Options (1 of 2) (SOPT) Backup Withholding Rate field. The withheld portion of the payment is still considered a disbursed amount but it is placed in a special backup withholding balance sheet account for subsequent payment to the IRS. The Withholding account is specified on the Payable and Disbursement view of System Special Accounts (SPEC).
A vendor that is subject to backup withholding cannot be paid using a manual warrant document. Checks resulting from the automated disbursements process and their corresponding backup withholding amounts can be tracked in Open Check Header Inquiry (OPCH) and Open Check Line Inquiry (OPCL). The data stored in the open check tables is used to generate the Backup Withholding (AFINA941) report which can be used as supporting documentation to pay the IRS on a quarterly basis.
Accounting Model and the Ledger
Automated disbursements generate the following postings to the Current Detail General Ledger (GENLED):
Dr Liabilities (vouchers payable)
The amount posted is the check or transfer amount.
The following additional entries are posted when the Warrant Option and the Warrant Clearing Fund option are set to No .
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.
Accounting Model for Automated Disbursements
The following records are created by the cash disbursement cycle.
- 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 Payment Voucher Line Inquiry (1 of 2) (OPVL) that was paid. These records are posted to the following ledgers:
- Open Payment Voucher Ledger (PVOPEN). The detail records are posted.
- Job Ledger (JOBLED). The detail records that contain a job number are posted.
- Current Detail General Ledger (GENLED). Depending on the option selected in System Control Options (1 of 2) (SOPT), either detail or summary records are posted. To conserve disk space, the detail cash or funds disbursements records can be summarized to the fund/agency level. When the Summarize Disbursements option on System Control Options (1 of 2) (SOPT) is set to Yes , 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.
- 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 Open Payment Voucher Line Inquiry (1 of 2) (OPVL) where a discount was taken. These records are posted to the following ledgers:
- Current Detail General Ledger (GENLED). The detail records are posted.
- Job Ledger (JOBLED). The detail records that contain a job number are posted.
- Penalty records. These are either expenditure or expense/expenditure entries recording late payment penalties from the appropriate accounts. A separate entry is generated for each line in Open Payment Voucher Line Inquiry (1 of 2) (OPVL) where a penalty was paid. These records are posted to the following ledgers:
- Current Detail General Ledger (GENLED). The detail records are posted.
- Job Ledger (JOBLED). The detail records that contain a job number are posted.
- Warrant records. These records are created when the Warrant Option in System Control Options (1 of 2) (SOPT) is set to Yes . These entries record the disbursement in the warrant clearing fund (optionally) and in the warrants payable account. These are summary level records with transaction numbers equal to the check date. These entries are posted to the Current Detail General Ledger (GENLED).
- Tax records. If you are using Tax Codes, these records are created when the amount of tax paid is adjusted because a discount has been paid. These entries record a refund for the difference between the original tax amount and the new tax amount. For use tax codes the refund will be to the use tax accrual account. For sales tax codes, the refund will be to the appropriate expenditure account. A separate entry is generated for each line in Open Payment Voucher Line Inquiry (1 of 2) (OPVL) where the tax was adjusted. These entries are posted to the Current Detail General Ledger (GENLED).
- Backup withholding records. These records are created when the Backup Withholding Option in System Control Options (1 of 2) (SOPT) is selected, the vendor is subject to backup withholding, and the object is 1099 reportable. A separate entry is generated for each line in Open Payment Voucher Line Inquiry (1 of 2) (OPVL) where a percentage of the disbursement is withheld. These entries are posted to the Detail General Ledger (GENLED).
Payments generated outside the central system (MARS) are processed through Check Writer files. Agencies pass the check writer files to MARS after running a pre-edit program The Check Writer Pre-Edit (CWPE) program ensures the file is a valid payment file. Edits include checking balances, checking budget and cash sufficiency, validating accounting line information, validating 1099 vendor TIN, and validating ACH information, etc. Check writer files that pass all the edits except the overrideable errors for insufficient budget and cash will be accepted in MARS. A Check Writer JVM (CJ) document is generated to record accounting events in MARS. If there is insufficient budget and/or cash, the CJ will have overrideable errors and be rejected. Once budget/cash becomes available, user can override the error on line and process the CJ. A valid check file is generated in MARS and sent to the Treasury to write checks. If payments are EFT payments, an ACH file is generated and sent to the Treasury.
Check Writer process status is updated to the Check Writer Status (CWST) table. The table shows when the check writer programs are run and if the check writer file has passed the pre-edits. An authorized user can also use this table to override Budget Edit, Cash Edit and Vendor Offset.
Since check writer payments are generated outside of MARS, payment details are not tracked in the Open Payment Voucher Header/Line (OPVH/L) tables as regular payments. Instead, a new table, Check Writer Check Accounting (CWCA) table is updated with all the accounting line information. Accounting lines are prorated for individual payments from the check writer file based on the weight of the payment amount. Check writer payment information is also updated to the Warrant Reconciliation (WREC) and Open Check Header/Line (OPCH/L) inquiry tables. Check information also updates the Open Check Header Inquiry for Agencies (OPCA).
The accounting entry for Check Writer payments is as follows:
Dr Expenditure (accounting line form CW file or CWCC)
Cr Cash (accounting line form CW file or CWCC)
MARS allows you to void checks in two ways:
Of the two methods for voiding checks, the recommended method is entering a check cancellation document. Both manually written checks and checks produced by the automated disbursement process may be voided.
Check Voids Using the Check Cancellation Document
In order to use the check cancellation document, the following conditions must exist:
- The check being canceled is written against a payment voucher.
- A record for the referenced payment voucher exists in Open Payment Voucher Header (OPVH) and Open Payment Voucher Line Inquiry (OPVL, OPV2).
- The check being canceled represents full payment of the payment voucher (partial payments cannot be handled by the check cancellation document). The program determines this by looking at the Number of Checks Written field on Open Payment Voucher Line (1 of 2) (OPVL). If it is greater than 1 , this check is not a candidate for the check cancellation document.
The check cancellation document posts reversing records to cash, vouchers payable, and if the warrant option is selected, to warrants payable. The records are created from each line in Open Payment Voucher Line (OPVL) paid by the check.
The check cancellation document does not reverse discounts or penalties. Therefore, this method of cancellation should only be used with a type of cancel (type 4 special authority is needed for types 1, 2, or 3). This will leave the payment voucher closed and all adjustments will need to be made manually using a journal voucher. Additionally, the expended amount in Vendor (1 of 2) (VEN2) is reduced, entries in Warrant Reconciliation (1 of 2) (WREC) are marked void, and the Transaction code of the Last Check/Manual Warrant Number field on Open Payment Voucher Line Inquiry (1 of 2) (OPVL) is changed to CX .
For each check being canceled, you must specify a Cancellation Type. The cancel type determines which vouchers payable account will be reversed and how the voucher referenced by the check will be treated. The valid Cancellation Types are listed below.
- Reschedule (type 1) reopens and reschedules the payment voucher using either the date entered on the check cancellation or a computed date. The computed date is determined in the same manner as for a payment voucher. The vouchers payable account to be reversed is determined from the offset liability account recorded in Open Payment Voucher Header (OPVH) entry.
- Unschedule (type 2) reopens the payment voucher but leaves it unscheduled. The vouchers payable account that is reversed is specified in Open Payment Voucher Header (OPVH).
- Cancel (type 3) leaves the payment voucher closed. The Cancel Vouchers Payable account specified on the Payable and Disbursement view of System Special Accounts (SPEC) is reversed.
- Close (type 4) leaves the payment voucher closed. Cancels the check and backs out the payment voucher.
Accounting Model and the Ledgers
For each line in Open Payment Voucher Line Inquiry (OPVL, OPV2) paid by the check being canceled, the following ledger entries are posted to the Current Detail General Ledger:
Cr Vouchers Payable (from Open Payment Voucher Header (OPVH) or System Special Accounts (SPEC))
The following illustrates the accounting model for Cancellation Type Reschedule (type 1) check cancellation documents.
Accounting Model for Check Cancellations
Additionally, the following entries are posted when the Warrant Option is set to Yes on System Control Options (1 of 2) (SOPT):
Dr Warrants Payable (from System Special Accounts (SPEC)
For a negative payment voucher line, these entries are the reverse. Any discounts taken are not reversed; the disbursed amount is the amount used for generating records. For more information on the check cancellation document, see the User's Reference .
Check Voids Using the Manual Warrant Document
Manual warrants void both manually-written checks and checks produced by the automated disbursement process.
The check void procedure involves two steps:
- Reversing the appropriate accounting documents by entering a manual warrant document.
- Marking the check as void in Warrant Reconciliation (1 of 2) (WREC).
This section provides guidelines for voiding checks in MARS. Every possible check void situation is not described here. However, the guidelines can be used as a starting point for a particular situation. Procedures are described for voiding manually written checks and the computer-printed checks produced by the cash disbursement cycle.
The accounting models for the situations described below are found at the end of this chapter.
Reversing the Expenditure and Voiding a Manually Written Check (No Prior Document Reference)
To void a manually written check, reverse the manual warrant document that recorded the check. This section discusses the situation when a requisition, a purchase order, or a payment voucher is not referenced on the manual warrant.
The manual warrant document is reversed by coding a new manual warrant with a decrease (negative) line amount. A negative line amount is valid in MARS, but a negative document total is not valid. Therefore, you must also enter a balancing line on the manual warrant document. The system-generated offsetting lines for these two lines balance each other out. Take the following steps to enter the manual warrant.
- Complete the Reference Document view of the manual warrant as follows:
- If the warrant still exists in Document Control (DCTL), you may want to modify the original manual warrant number.
- The Bank Account Code is required. Use the Bank Account code of the bank for whom you are voiding the checks.
- The Cash Account is optional, but if entered, must match the original warrant.
- Vendor Code or Vendor Name is required. It must match the original warrant. When a check is being voided for a vendor that exists in Vendor (1 of 2) (VEN2), the system decreases Calendar YTD Amount and Fiscal Year YTD Amount on the Payment Information view of Vendor (1 of 2) (VEN2) by the amount of the canceled check.
- Complete the reversal line (record each line as it was originally entered):
- Enter the accounting distribution as it was entered in the original manual warrant.
- If the check number is not represented by the warrant number, enter it in the Description field.
- Enter the amount of the check being voided in the Amount field.
- Set the Default/Increase/Decrease indicator to Dec .
- Complete the balancing line:
- Code one line per fund effected. That is, if several lines from the same fund are being voided, you can enter one summarizing line.
- The Fund must be the same as the Fund on the reversal lines.
- Agency is optional. It is required if the Reporting Category on Balance Sheet Account (BAC2) associated with the balance sheet account is set to Y .
- Balance Sheet Account is required. It must be the Cash Account that was used on the original warrants. This was entered on the original manual warrant header or inferred from Bank Account (BANK).
- The line Amount is the total of all reversal lines (within the fund) being balanced (so the document total is zero).
- Set the Default/Increase/Decrease indicator to Inc .
These manual warrant documents reverse the expenditure transaction throughout the system. For example, the Expended Amount field in the budget windows and the Calendar YTD Amount and Fiscal Year YTD Amount fields on the Payment Information view of Vendor (1 of 2) (VEN2) are reduced, and the balances in Balance Sheet Account Balance (BBAL) and Fund Balance (FBAL) are increased. Manual warrants reverse the cash transaction (the vouchers payable and cash accounts are reversed). You should also change the Status field to V on the appropriate entry in Warrant Reconciliation (1 of 2) (WREC).
- It is important to understand that the system cannot verify that the accounting distribution codes, the Balance Sheet Account codes, and the Vendor codes are correct; for example, that they match the original manual warrant. This cannot be validated because manual warrants are not stored in a master table. (Only the document number and accounting period are kept in Document Control (DCTL).) If the wrong codes are used, you affect the wrong lines in the windows mentioned above. You should verify the results of these transactions on a Transaction Listing Report to ensure that the correct codes were entered.
Figure 51 shows a manual warrant entered to void a manually written check with no prior document reference.
Reverse the Expenditure and Void a Manually
Written Check (with a Prior Document Reference)
This section discusses a case when the original manual warrant document (the one you want to reverse) included a prior document reference. Two possible conditions exist:
- The referenced document no longer exists in the open master tables. This condition is always true for requisitions, since requisitions are deleted from the open requisition table the first time they are referenced. This condition is true for purchase orders and payment vouchers if the monthly clearing program has deleted the document from the tables. In this situation, you enter the check void as if no prior document existed. Follow the directions in the previous chapter.
- The referenced document still exists in the open item master 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 reopens the document, re-establishing the encumbrance (for purchase orders) or the liability (for payment vouchers). Enter the manual warrant following the directions specified under the discussion of manual warrants earlier in this chapter, but add the prior document reference to the line level of the reversal lines. If the Prior Document Reference Option in System Control Options Vendor (1 of 2) (SOP2) is selected, you do not have to enter the accounting distribution. Do not reference the prior document on the balancing line.
The system validates the Vendor code and the accounting distribution codes, and for payment vouchers, the
Bank and Cash Account codes, against the referenced document and line. If they do not match, the manual warrant is rejected.
When a prior document is coded on a check void, the referenced document (and line within the document) is opened in the appropriate open item tables. In addition, the Expended Amount fields in the budget tables and Calendar YTD Amount and Fiscal Year YTD Amount on the Payment Information view of Vendor (1 of 2) (VEN2) are reduced, and the balances in the Balance Sheet Account Balance (BBAL) and Fund Balance (FBAL) are increased. You should also change the Status to V on the appropriate entry in the Warrant Reconciliation (1 of 2) (WREC).
Figure 52 and Figure 53 illustrate voiding a check with a prior document reference. The first window represents the manual warrant recording the check when it was written. The second example reverses it.
Manual Warrant (MW) Document (Prior Document Referenced)
Manual Warrant (MW) Document (Voiding the Check)
Reversing the Expenditure and Voiding an Automated Disbursement Check
When you void a check printed by the automated disbursement process, you must reverse the effects of the documents that the automated disbursement process created. You also have to reverse the expenditure if:
- 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 the new check. (See the next section if you want to keep the same accounting distribution and write a manual check.)
To void an automated disbursement, you need to enter a two-line manual warrant document and reverse the expenditure as follows:
- Complete the document header:
- The Bank Account code and cash account must match those used for the automated disbursement, as inferred from the Fund code used on the related payment voucher. The vendor must match the one used on the payment voucher.
- Increase cash:
- Enter one line per fund affected.
- Enter the appropriate fund, agency, cash balance sheet account (this is the account inferred through the fund and bank account), and other required fields.
- The line amount is the amount of the check
- The Default/Increase/Decrease indicator is set to Inc .
- 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 (OPVH) and Open Payment Voucher Line Inquiry (OPVL, OPV2), include the reference in the document reference field (you can do this even if the payment voucher is closed).
- Code the accounting distribution (optional if the payment voucher was referenced and the Prior Document Reference Option on System control Options (1 of 2) (SOPT) is set to Yes .
- The amount is the payment voucher line amount.
- Default/Increase/Decrease indicator is Dec .
These documents reverse the expenditure transaction throughout the system. For example, the Expended Amount field in the budget tables and the Calendar YTD Amount and Fiscal Year YTD Amount fields under the Payment Information view on Vendor (1 of 2) (VEN2) are reduced, and the balances in Balance Sheet Account Balance (BBAL) and Fund Balance (FBAL) are increased. They also reverse the cash transaction. If a payment voucher was referenced, it is reopened. The normal cash disbursement process is used to generate the new check. You should also change the Status to V on the appropriate entry in Warrant Reconciliation (1 of 2) (WREC).
To re-establish the liability with a different accounting distribution, submit an adjustment payment voucher to cancel the existing liability, and then enter a new payment voucher with the new accounting distribution.
If you cannot reference the payment voucher because it is cleared from the tables, enter a new payment voucher to recreate the liability.
The following manual warrant sample has been entered to void an automated disbursement check and re-establish the liability for a payment voucher that still existed in Open Payment Voucher Header (OPVH) and Open Payment Voucher Line Inquiry (OPVL, OPV2).
Voiding a Check without Reversing the Expenditure
If a check is lost and you want to void it and write another one as a manual warrant, you do not have to reverse the expenditure; you just reverse the cash transaction. However, if you want the new check paid with an automated disbursement check, the expenditure must be reversed to re-establish the liability.
To void a check without reversing the liability, you must enter two lines on a manual warrant document. The requirements are the same whether you are voiding a manually written check or an automated disbursement check.
Enter the document as follows.
- Complete the document header:
- Bank Account, Cash Account, and Vendor codes must satisfy the normal validation requirements of a manual warrant. Although these codes are not checked against any prior documents, they should match the original manual warrant or payment voucher for consistency and accuracy in reporting.
- Increase cash:
- Enter the appropriate fund, agency, cash balance sheet account (this is the account inferred through the fund and bank account), and other required fields.
- Code the cash balance sheet account:
- If you are reversing a manually written check, this is the offset Cash Account coded on the header of the original manual warrant, or inferred from the Bank Account.
- If you are reversing an automated disbursement check, this is the Cash Account as inferred through the Fund and Bank Account.
- The line amount is the amount of the check.
- The Default/Increase/Decrease indicator is Inc .
- Increase vouchers payable:
- Code agency and reporting category if the Reporting Category Option on Balance Sheet Account (BAC2) is Y for the balance sheet account used.
- Code the vouchers payable balance sheet account:
- If you are reversing a manually written check, this is the system-wide vouchers payable account from System Special Accounts (SPEC).
- If you are reversing an automated disbursements check, this is the offset liability account entered on the header of the payment voucher, or if none was entered, the system-wide vouchers payable account from System Special Accounts (SPEC).
- The line amount is the amount of the check.
- The Default/Increase/Decrease indicator is set to Dec .
The system-generated offsetting entries from these transactions balance each other out. You can now enter a third manual warrant line recording the new check. You should also change the Status to V on the appropriate record in Warrant Reconciliation (1 of 2) (WREC).
Accounting Model for Check Voids
This section presents the accounting models for recording the check void examples described above. Note that an asterisk (*) following any ledger entry denotes an entry that is explicitly entered 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 created these entries:
To void the check, you create these entries:
- Reverse the Expenditure and Void a Manually Written Check With a Prior Payment Voucher Document Reference. The manual warrant created these entries:
To void the check, you create these entries:
- Reverse the Expenditure and Void an Automated Disbursement Check. The payment voucher created these entries:
The automated disbursement created these entries:
To void the check, you create these entries:
- Void a Check Without Reversing the Expenditure. The manual warrant or automated disbursement created these entries:
To void the check, you create these entries:
Electronic Funds Transfer Cancellation
In the event that an incorrect amount is paid or a tape is lost or destroyed and cannot be recreated, electronic funds transfer (EFT) may be canceled. This is accomplished by entering a check cancellation document. All check cancellation abilities apply, with the following additions:
- If the check to be canceled by the check cancellation document is an EFT, the EFT Check Indicator should be selected.
- If the Cancellation Type is Reschedule (type 1) or Unschedule (type 2; reopen the payment voucher documents) the vendor will be checked to be sure it is still EFT active; if not, the Open Payment Voucher Header (OPVH) EFT Indicator will be reset.
- If the Cancellation Type is Reschedule and the vendor is not EFT, the voucher will be rescheduled for automated disbursements and a warning will be issued.
- If the Cancellation Type is Unschedule and the vendor is not EFT, the voucher will remain unscheduled, but the EFT Indicator and Application Type will be changed on Open Payment Voucher Header (OPVH) and a warning will be issued.
Expenditure Accounting - Special Features
Accounting Model and Prior-Year Purchase Orders
When prior year purchase orders are referenced by a manual warrant or payment voucher, special processing is performed to ensure that ledger postings and table updates are performed for the correct accounting and budget fiscal years. The following scenarios help to illustrate the accounting model used in that situation.
In Case A, assume a 1996 payment voucher clears a 1995 purchase order for less than the full purchase order amount.
- A purchase order for $100 is established in fiscal year 1995.
- A payment voucher for $60 partially clears the purchase order in fiscal year 1995.
- A payment voucher for $30 finally clears the purchase order in fiscal year 1996.
* In this situation, the budget fiscal year and fiscal year are not the same. You can use an option on System Control Options (1 of 2) (SOPT) to require the budget fiscal year and fiscal year to be the same. It should be noted that the payment voucher has the same budget fiscal year as the referenced document. The fiscal year, however, has the fiscal year of the new year.
In Case B, assume 1996 payment voucher clears a 1995 purchase order for an amount greater than the purchase order amount.
- A purchase order for $100 is established in fiscal year 1995.
- A payment voucher for $60 partially clears the purchase order in fiscal year 1995.
- A payment voucher for $50 finally clears the purchase order in fiscal year 1996.
* This occurs when the Obligation Carry forward system option (on SOP2) is set to Yes .
Escheat is a process to automatically void outstanding checks over a user-controlled age (e.g., one-year-old). A journal voucher (JVM) is automatically generated to deposit the money back into a user specified funding source based on the fund from which the check was written. The user specified time range is provided on the From Date and To Date on the Bank Account (BANK) table. The user specified funding strips are established in the Escheat Accounting Line (ESAL) table. The accounting entry for check escheat is as follows:
Dr Cash (Fund, Agency, Org, Program Budget Unit, Cash Account)
Cr Revenue (Fund, Agency, Org, Program Budget Unit, Revenue Source)
Checks are automatically marked by the Escheat process as Void on the Warrant (WREC) table and Cancelled on the Open Check Header Inquiry (OPCH) table.
Outstanding Check Reconciliation
Check reconciliation is a process of comparing checks issued against checks cleared by the bank. The outstanding check reconciliation feature in MARS automates this process for you. The facility provides you with a list of outstanding checks (manual warrants and automated disbursements) in the form of a master table. Two options exists for tracking these checks through several possible statuses. One is through the Open Check Header Inquiry (OPCH) window, and the other is through the Warrant Update (WR) document.
This reconciliation facility also works for entities that issue warrants instead of checks. See the previous section for a discussion on warrants and MARS.
The automated disbursement process and the manual warrant document processor add entries to Warrant Reconciliation (1 of 2) (WREC). An entry is made for every manual warrant and automated disbursement. If a manual warrant document is a modification (the warrant number is the same as a previously entered warrant number), a new entry is not entered in the Warrant Reconciliation table. Instead, the Warrant Amount field for the warrant number is appropriately updated in the table.
Authorized users can change the status. This option is only valid if the Warrant Option on System Control Options (1 of 2) (SOPT) is set to Yes or No . If the Warrant Option is set to Summary , which is used for warrant summarization, status cannot be changed online. The valid values for Status are:
MARS provides ability to print checks immediately as needed (on demand). Immediate turnaround is required. Access to pre-printed forms for checks must be controlled. Pre-printed checks will usually be aligned with the printer; but, for occasions when alignment is necessary, processing will be included to aid in this task with a minimum loss of forms. Printing will be under normal security features.
For a detailed discussion of the technical requirements for on-demand printing see the System Administration Guide .
On-Demand Print Entries (PRNT)
Print Control (PRNT) is keyed by User ID and Window ID. The user should have one entry for each user who can print purchase orders or checks. The Window ID is the four-character ID of the window the user is accessing for the on-demand prints: For sample window prints and detailed field descriptions for these windows, see the User's Reference .
The on-demand print window (On-Demand Check Print (ODCK)) has an alignment feature that lets you check to ensure that the purchase order form or check and the printer are properly aligned. To check the alignment, go to the appropriate on-demand window and get the check that you want to print.
Select
Modify: Change
to cause an alignment record to be printed. Then, select the Document Alignment Okay to Print field at the bottom of the window to cause the check to print.
On-demand check printing requires these steps:
- A manual warrant document must be entered and accepted by the system. The manual warrant must still be on the Document Listing (SUSF).
- Go to On-Demand Check Print (ODCK) and display the manual warrant which you want to print by entering the manual warrant number (in the Document ID field) and Batch ID.
- Select Modify: Change to start alignment or check printing on the printer dedicated to on-demand check printing.
When the check is printed, the Last Action Date on the Warrant Reconciliation (1 of 2) (WREC) is updated. Once the Last Action Date is filled in, the check for the manual warrant cannot be printed again. If a check jams in the printer, or for some reason is not correct, normal check voiding procedures must be followed and a new manual warrant entered and printed. One check layout is available for printing on demand, and comes from a program, KODODC2.