Matching Manager
The concept of automatic payment request generation based on the matching status of award lines is dependent upon a chain job called the Matching Manager. The chain job consists of three different job steps.
-
The first job, Run Matching Manager, evaluates which commodity lines have met all matching requirements and selects those for payment request creation. The job then goes on to creates payment transaction information in an XML file. When creating transactions in the XML file, the job will ensure that no transaction created will exceed any line limit restrictions for the PR_DOC_VEND, PR_DOC_COMM, or PR_DOC_ACTG components established on the Transaction Component Requirements table. A new transaction will be generated whenever a limit is reached in addition to the parameter option of breaking on a change of vendor code.
-
The second job, Match Load, is a System Maintenance Utility (SMU) job that loads the XML file created in the first job into the application. Transactions are loaded with the Ready status. The transactions at this point do not have any accounting lines, only commodity lines.
-
The third job, Match Submit, is another System Maintenance Utility job, which submits the Ready PRM/PRMI/PRN transactions. In the process of being submitted, accounting lines are generated on the payment requests. The same logic is used to generate these lines offline now as is used for online generation. The accounting lines created on the Payment Request are the same as those found on the referenced Purchase Order. Any lines on the Order that have a Reserved Funding value of No will be created on the Request if that accounting line is not already closed. Lines that have a Reserved Funding value of Yes or Locked will not be generated.
The Matching Manager processing logic operates almost identically for Grant transactions as it does for all other transactions. The only difference is that Commodity Lines from Grant Funding Request (GFR) transactions are all consolidated under a single Payment Request referencing the Grant Award transaction. When the Matching Manager selects the IN Transaction Type transaction Commodity Lines for processing, if the Transaction Sub Type is equal to GFR, the system consolidates any Commodity Lines that have the same Referenced Transaction Department, Referenced Transaction Code, Referenced Transaction ID, and Referenced Commodity Line into one Payment Request transaction.
The Payment Request Matching (PRM) transaction is generated by the Matching Manager process with a Reference Type of Final only when both the Invoice (IN) and Receiver (RC) transactions have the Reference Type set to Final. If any one of the transactions, IN or RC has a Reference Type set to Partial, then the PRM transaction that is generated will have the Reference Type set to Partial. The following tables displays several scenarios to illustrate this logic:
|
Test Case |
PO CL # |
PO QTY |
RC QTY |
RC Ref Type |
IN QTY |
IN Ref Type |
PRM QTY |
PRM Ref Type |
|
1 |
1 |
10 |
10 |
Final |
10 |
Final |
10 |
Final |
|
2 |
1 |
10 |
10 |
Final |
6 |
Final |
6 |
Final |
|
3 |
1 |
10 |
6 |
Partial |
6 |
Partial |
6 |
Partial |
|
4 |
1 |
10 |
6 |
Partial |
6 |
Final |
6 |
Partial |
|
5 |
1 |
10 |
6 |
Final |
6 |
Partial |
6 |
Partial |
|
6 |
1 |
10 |
6 |
Final |
6 |
Final |
6 |
Final |
|
7 |
1 |
10 |
10 |
Final |
6 |
Partial |
6 |
Partial |
|
8 |
1 |
10 |
6 |
Partial |
10 |
Final |
6 |
Partial |
|
9 |
1 |
10 |
6 |
Final |
10 |
Final |
6 |
Final |
|
10 |
1 |
10 |
6 |
Final |
9 |
Partial |
6 |
Partial |
|
11 |
1 |
10 |
9 |
Partial |
6 |
Final |
6 |
Partial |
Your CGI Advantage System Administrator will set up this process. The process allows you to specify how often you want to run the matching manager, Real Time to On-Demand. The run sheet for that batch job contains much more information on the program.
