Payment
Request functionsDepending on how the rules and options are configured, the Payment Request transaction can perform several functions. These functions are strongly influenced by the Event Type selected on the accounting line, and the rules established on the Transaction Control table.
Be the only transaction in an expenditure processing chain to pay for goods/services which will book the expenditure and establish a payable in the system
Reference another transaction, so that referencing portion is liquidated
Make a payment against multiple budgets that span multiple budget fiscal years
Support multiple vendors at the line level, allowing multiple vendors to be referenced within the same Payment Request transaction
Enter commodities and supporting commodity information, enabling direct payments (those with no supporting purchase order, as well as payments that reference prior transactions, for commodities to be processed within Advantage Financial
Tracks the Fixed Asset Purchases by first identifying a fixed asset purchase at the time the payment request is accepted into the system based on the Commodity Code specified on the PRC Commodity Line.
Create credit memo requests to offset future requests for payment
Authorize payments for inventory items
Authorize payment for fixed assets
Take retainage based on terms established on a referenced order
Liquidate a Purchase Order or Requisition without requesting a payment for corrections
Correct a Purchase Order that will reopen a commodity line and accounting lines with an option to also create a credit memo. The Inverse choice in the Reference Type field enables this functionality
Reference a Master Agreement directly without an order transaction, no liquidation needed
Be part of match process, which determines its function within the processing chain
Be used to process customer or deposit refunds
Report on budget category and match requirements stipulated as part of a grant award
Important
concepts and features of commodity-based transactions
Commodity
Payment Request Event Types
The following are the nature of accounting activity associated with the Commodity Payment Request Transactions:
Payment Authorization - Payment Authorization is used to pay for goods or services that have been received. An invoice or the match process usually precedes a payment authorization, however, the system also accepts direct or standalone payments. When a payment authorization event type is chosen, it may reverse the impacts of the prior transaction, if a transaction is referenced, or just recognize the expenditure if no references have been made.
Pre-payment - Prepayments occur when payments are made to the vendor before the expenditure has occurred. In this situation, the cash is decreased and tracked using a predefined prepaid expense account (asset) until the expenditure event is incurred. When the expenditure is incurred, it is recognized in a separate transaction.
Referencing
Prior Transactions
In Advantage Financial, Payment Request transactions can reference other transactions, such as requisitions and awards. This will liquidate all, or a portion of, the pre-encumbrance and encumbrance, respectively. (Please note that if a Payment Request references a Master Agreement directly then liquidation does not occur, since the Master Agreement does not contain accounting data.)
Referencing prior transactions allows for easy transaction entry because the information on the referenced transaction (such as funding distribution) is automatically inferred to the Payment Request.
Referencing
Master Agreement Transactions
A Payment Request transaction can directly reference the Master Agreement (MA) transaction. The reference can only be done on the PRC in situations where users may need to directly pay a vendor without first needing to process an order transaction. This includes cases where goods or services are delivered on a regular basis based on a Master Agreement (for example, equipment rental), as well as cases where an order is placed directly over the phone. (Note: You cannot reference a Master Agreement Commodity Line that has the Inactive Line flag selected.) The Payment Master Agreement Reference field on the Procurement Transaction Control table determines which Payment Request transactions can reference a Master Agreement.
Please refer to the Procurement Transaction Control topic in this user guide for setup information required for Payment Request transactions referencing MA transactions.
Please refer to the "Master Agreement (MA)" topic in the CGI Advantage - Procurement User Guide for more information.
Commodity
Based Encumbrance Search
The Commodity Based Encumbrance Search (ENCSRCH) page is used to search for an encumbrance based on vendor and transaction details and to create a Payment Request transaction for all or selected accounting lines. Refer to the "Commodity Based Encumbrance Search (ENCSRCH)" topic for more information.
Modifying
and Adjusting the Payment Request Transaction
Sometimes it is necessary to change transaction information after it has been processed. Changes can only be made to the Payment Request transaction lines before it has been disbursed (paid by the Automated Disbursement process or a Manual Disbursement transaction). Once it has been disbursed, changes cannot be made until the check/warrant has been cancelled and the Payment Request transaction is re-opened.
Any changes to the transaction after the Payment Request has been accepted by the system need to be made using the Transaction Modification action. All versions of the modification are stored in the Advantage system so you can track each change made after the Payment Request has been accepted. This history can be viewed on the Transaction History log.
Modifications made to a Payment Request that references another transaction also impact the referencing transaction, depending on the changes made. If the changes do not impact the accounting entries or system maintained tables of the previous transaction, the changes are updated to the Payment Request only. If the payment has accounting impacts to the referenced transaction, extra accounting entries will have to be posted and update the referenced transaction.
Partial/Final payments can be done in two different situations:
Disbursing a Payment Request: Since multiple vendors and disbursement options are allowed, the disbursement can occur on different days. Until all lines are disbursed, the Payment Request transaction is partially paid.
Liquidating a referenced transaction can be performed as follows:
More than one Payment Request liquidates a referenced transaction.
Payment Request transaction partially references a transaction with the ”Final” Reference Type selected and the system forces to close out the referenced transaction by reversing un-referenced portion.
For more information about Partial/Final Payments, refer to the "Referencing" topic in the CGI Advantage - Financial Administration User Guide.
Some payments may occur on a predefined frequency, such as monthly or quarterly. In Advantage Financial, these are known as recurring payments.
Recurring Payments can be created two ways in Advantage - either via Future Transaction Triggering, or by using the Schedule Invoice Generation functionality.
The PRC or GAX transaction can be used for establishing recurring payments.
In order to create a recurring payment, you can use the Future Transaction Triggering option. If this option is selected, it indicates that when this entry is triggered, the original transaction will be copied to create the new transaction. This type can be setup for any frequency. It is the only type that is valid for all of the recurring frequencies.
For more information, refer to the "Future Transaction Triggering” topic in the CGI Advantage - Transactions User Guide.
Many government entities process similar, recurring payments to vendors for goods and services such as leases, rents, or health and human services contracts. Some of these recurring payments have predefined reconciliation periods when the previous amount paid to a vendor during a certain period is reconciled against what was actually delivered. If necessary, the next payment to the vendor for this contract is adjusted to bring the two amounts into alignment. In some cases, these may be legislatively mandated payments made on a recurring schedule in advance of receiving a physical invoice for the services.
This process is used when vendor invoices are received on a monthly basis but payments may need to occur on a more frequent interval. In many cases, these arrangements are made with vendors whose primary or sole customer is the government. A primary feature of this process is that payments can be issued prior to receipt of an invoice. As a result, users can configure order transactions such that the system will initiate payments to vendors frequently enough to help them cover their operating costs. While vendors are required to send a periodic invoice detailing the actual services provided, a physical invoice is not a requirement for payment in these cases. However, once the invoice is received, the actual payment amounts must then be reconciled with the invoiced amounts.
Advantage Financial users will have the ability to designate an order/encumbrance as a recurring payment and choose a recurring payment schedule. The Scheduled Invoice Generation Chain Job, which can be run on demand, will generate invoice transactions for the recurring amount and on the schedule identified. The Matching Manager Chain Job, which can be run on demand, will then match the invoice to the order and generate payment request transactions.
Users will periodically reconcile entries on the Scheduled Invoice Generation table based on an indicator on the Schedule Sequence. Future invoice transactions are not generated for the referenced Order commodity line until the reconciling entries are made on the Schedule Invoice Generation table.
Recurring Payment Schedule
(RPSCHD) Table - The Recurring Payment Schedule
table defines the payment schedules for recurring payments.
Each Schedule can have multiple time periods, or sequences,
defined to it. Having a Schedule split into multiple
Sequences allows for specific Sequences to be defined
as a Reconciling Period (when the schedule has a Recurring
Payment Type of Reconciling).
When an invoice is generated for a recurring payment during
the dates of a Sequence flagged as a Reconciling Period,
additional information is manually added to the Scheduled
Invoice Generation table prior to the generation of the
recurring invoice transaction.
A Schedule defined on the Recurring Payment Schedule table
is entered on the header of Recurring Payment Order (RPO)
transactions. RPO transactions update the Scheduled
Invoice Generation table when submitted to Final and therefore
the Schedule for each RPO is added to Schedule Invoice
Generation along with other information about the RPO.
Scheduled Invoice Generation
(SIG) Table - The Scheduled Invoice Generation
table provides a list of the past and the next scheduled
recurring invoices to be generated. Scheduled Invoice
Generation records cannot be modified once a Recurring
Invoice transaction has been generated.
This table allows you to link to the Scheduled Invoice
Generation Management table to manage invoices scheduled
for generation for recurring payments. You can also link
to the Recurring Payment Schedule table.
Scheduled Invoice Generation Management (SIGM) Table - The Scheduled Invoice Generation page is an alternate view of the Scheduled Invoice Generation table and is used to query and update multiple Schedule Invoice Generation records simultaneously. The Hold Payment, Single Payment and/or Disbursement Handling Code values can be updated from this table.
A Payment Request can be cancelled if the PR transaction was entered in error. The cancellation of the PR is accomplished through the Discard action of the transaction. PR transactions that are partially or fully paid cannot be cancelled. All cancellations will reverse the transaction's impact on all tables, and reverse ledger postings on the journals.
Once a grant is awarded, the most common next step is a request for funds. In general, these types of payments to a grantee follow normal payment processing. Payment requests can be entered manually (on the PRC or PRCI) or generated through matching (with the PRM). The accounting events on the payment requests depend on an internal or external grantee and what type of commodity line on the Grants Given (GG) award transaction is being paid.
There are three general scenarios for disbursement of grant funds:
Full Advance – A grantor sends the fully awarded amount of funding to the grantee and the grantee sends reports back to the grantor on how the funding was expended.
Partial Advance – A grantor sends an advance payment for a portion of the award to the grantee and the grantee sends reports back to the grantor on how the advance was expended. Once the advance is fully expended, the grantee begins to bill the grantor for expenditure reimbursement until the award has been fully expended.
Reimbursement – A grantor executes a grant award contract that has been approved by both the grantor and grantee. The grantee begins accounting for the expended funds and bills the grantor for reimbursement.
Two qualities unique to grants is the need to report on budget category and match requirements stipulated as part of the grant award. The grantor must break down the detail of the available funds and have the grantee submit requests on the amount expended per category. For example, the grantee may specify the reimbursement request for categories such as Administration and Travel. The budget category will need to use a single COA element that will be used across grants awards. It is important to note the following:
The Grant Funding Request does not include accounting lines, but the budget category on the grant funding request instead maps to the appropriate code on the accounting line of the grant award in order to generate the payment request with the appropriate reference line.
The match amount on the grant funding request is not a request for funds, but rather a report of the amount spent by the grantee to fulfill the grant award requirement.
Lines that require a grantee match should be set up on the grant award transaction using non-financial, reporting only event types. The match is not an encumbrance, nor is it expenditure at the time of payment, but needs to be captured as part of grants management so that it can be reported back to the federal government.
The Advantage Matching Manager can automatically generate payment requests through the use of the Matching Status and Matching Status Single Award Line pages, as well with the Matching Manager chain job. When the Matching Manager chain job is run, the first batch job goes through a process of ensuring that commodity lines have met all matching requirements based on their specific matching criteria. If all matching criteria have been met, then a subsequent batch job proceeds to generate XML that is used to create a Payment Request transaction referencing the matched Commodity Line. While the Advantage Matching Manager is the mechanism by which Payment Request transactions are created, it does not actually create the accounting lines for the Payment Request transaction; those are created via the PR Transaction processor logic.
To create the accounting lines, the system looks up the value in the Category field on the GFR transaction’s Grant tab line and matches it to the corresponding Task Code on the accounting line of the Grant Award transaction. It then uses that accounting line data to generate the corresponding accounting line on the Payment Request transaction.
To create accounting lines that reference match event types, the system performs a lookup to the Event Type Defaults page when generating accounting lines if the referenced Award transaction has the Grantor flag checked on the Procurement Transaction Control page. This lookup is based on the Transaction Type and referenced Event Type on the accounting line of the Grant Award transaction. It does this to determine if there is a specific matching Event Type that should be used based on the referenced Event Type. If a match based on Transaction Type and referenced Event Type is found, accounting lines on the Payment Request transaction are generated using the specified Transaction Event Type on the Event Type Defaults page. If there is no match on the Event Type Defaults page, the standard default event type for the payment request transaction is used. Please see “Pay a Grant Funding Request using the Matching process” under the Common Business Tasks topic for a detailed scenario on how this process works.
For detailed information on each of the tabs that exist on the PRC, refer to the following topics:
PR
Delivered Transaction CodesThe PR Transaction Type has the following Transaction Codes (listed alphabetically by Transaction Name).
Name |
Transaction Code |
Intended Use |
Commodity Encumbrance Correction |
CEC |
The CEC transaction can be used to make encumbrance corrections. It will reopen the Purchase Order and correct the following:
If the Invoiced Quantity/Invoiced Amount of the Purchase Order needs to be corrected, then a new Invoice transaction needs to be created with a reference type of Inverse. The IN transaction needs to be created before the CEC is created. The PO transaction will be referenced on the CEC in the Reference tab with a Reference Type of Inverse. The IN (with the Inverse reference) should be entered on the Invoice tab of the CEC transaction. Both the Reference and the Invoice sections are found on the Commodity Line. |
Commodity Payment Request |
PRC |
A Commodity-based Payment Request (PRC) transaction records payment activity at the commodity level. |
Electronic Payment Request |
EPRC |
The EPRC is created by the Electronic Payment Request Generation Chain Job to pay for electronic invoices. |
Internal Payment Request - Commodity Based |
PRCI |
The PRCI transaction works like the PRC, but the PRCI is used to pay Internal Vendors and not for External Vendors. Once the PRCI is submitted, instead of the disbursement, there will be a transfer between the funds specified. The seller fund and detail accounting data is inferred from the Internal Vendor Accounting Data table for the vendor specified, if an entry exists, or the data can be entered manually. For posting logic, the bank account and event type information are also inferred from the Scheduled Invoice Generation table and can be modified manually on the PRCI, if required. |
Matching Payment Request |
PRM |
A PRM transaction is similar to the PRC transaction; however, the transaction is only created as part of the Automated Match Process. The Matching Payment Request (PRM) uses the same structure as the Commodity-based Payment Request. This type of transaction is automatically generated from the match process (two-way or three-way) based on the rules that have been established for the matching process. |
Matching PR - Negative (Inverse Reference) |
PRN |
The PRN transaction, a clone of CEC transaction code, will be used as the Inverse or "negative" payment request generated by the Matching Manager process. Matching Manager batch process will generate the PRN transaction if the IN transaction has a negative Invoiced Qty or negative Invoiced SC Amount, and the reference type is Inverse. |
Maximo Commodity Encumbrance Release |
PRCMER |
The Maximo Commodity Encumbrance Release transaction (PRCMER) liquidates unused encumbrance in response to complete receipts actions in Maximo. The PRCMER is automatically created by the Integration Engine and does not create a payment. |
Maximo Storeroom Receipt Asset Posting |
PRCM |
The Maximo Storeroom Receipt Asset Posting (PRCM) transaction updates the associated inventory Balance Sheet amount in response to receipts or returns entered in Maximo. The PRCM is automatically created by the Integration Engine and does not create a payment. |
Payment Request Match for Internal Vendors |
PRMI |
The PRMI is generated by the Matching Manager. This page infers the seller fund and detail accounting, as well as bank account and event type information from the Internal Vendor Accounting Data table for the vendor specified. The PRMI works like the PRM for external vendors, but PRMI is for Internal Vendors and not for External Vendors, except, instead of the disbursement, there will be a transfer between the funds specified. |
PCard Payment Request |
PRCC |
The PRCC is used to process payment requests for PCard transactions. The PRCC transaction is created via the PCard Chain. |
Pre-Processing PRC |
PPPRC |
A cloned version of the PRC to clearly identify payments entered before the beginning of a year that will be released by the Extended Payment Request Scheduling process. |
TasksTo create a PRC referencing a Master Agreement, go to Paying for Commodities Purchased with a Master Agreement.