Provides an introductory discussion of the functions of the expenditure module and the accounting events represented in the expenditure process. A terminology section is also included, as well as detailed descriptions of various types of controls.
Provides an overview of the inquiry windows and master tables that are valuable for researching vendor payment problems, analyzing purchasing trends, and complying with reporting requirements and it also describes the 1099 payment information collection.
Describes the basic concepts involved with manual warrant and manual warrant fedwire documents. This section also discusses referencing payment vouchers on manual warrants within the context of the accounting model and the ledger.
Explains the following expenditure accounting special features: Vendor Purchase Order Printing, Recurring Payment Voucher Facility, Warrant Facility, Outstanding Check Reconciliation, On-Demand Check Printing and Warrant Escheat.
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 amount cleared to date against an open item; for example, an outstanding purchase order, or payment voucher. When the item is finally closed and no further activity occurs against it, the cleared amount represents the portion of the total open item amount that has actually been utilized. Until the item is closed, the cleared amount equals the closed amount.
The amount closed to date against an open item; for example, an outstanding requisition, purchase order, or payment voucher. When the item is closed and no further activity occurs against it, a closed date is assigned to the open item and the closed amount indicates that the total open item amount is closed. Until the item is closed, the cleared amount equals the closed amount.
A code used on payment voucher documents indicating that a discount may be taken against the line amount of the document if a corresponding cash disbursement is made within a specified number of days. Discount parameters, including number of days, are defined by discount type on Discount Type (DISC).
The percentage or amount used to calculate a maximum upper limit for purchase order closing amounts. A system-wide tolerance is specified in System Control Options (SOPT, SOP2). The system-wide tolerance may be overridden for a given fund by specifying a tolerance amount or percent for that fund in Fund (FUN2).
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:
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.
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.
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:
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 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.
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.
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.
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.
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.
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:
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.
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.
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:
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.
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.
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:
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.
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.
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.
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.
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.
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:
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 .
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.
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).
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.
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.
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).
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:
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.
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).
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.
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:
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).
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.
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.
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.
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:
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.
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.)
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:
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.
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.
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.
The sample payment voucher in Figure 43 is coded to record the purchase of an inventory supply of gravel for road repair.
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.
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.
The sample journal voucher in Figure 44 is coded to record the depletion of an inventory supply of gravel.
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.
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.
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.
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 .
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.
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).
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.
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.
Manual warrants cannot be entered for a vendor that is subject to backup withholding. See Backup Withholding for more information.
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.
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.
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.
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).
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.
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).
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.
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 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:
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.
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.
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'.
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.
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).
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.
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 .)
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 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 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.
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.
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.
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.
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).
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.
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.
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 .
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.
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.
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).
Figure 51 shows a manual warrant entered to void a manually written check with no prior document reference.
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.
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:
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.
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).
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.
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).
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.
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:
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 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.
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:
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.
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.
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.
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.