Post Payments Run

The Post Payments Run task posts eligible payment batches to billing accounts. This task creates account transactions and deposit transactions to apply funds to unpaid charges until each payment is used up. This task is typically run once a day.

To post payment batches, these steps are completed:

Query the PAYBATCH table for payment batches that are ready to post (RDYPSTFLAG = Y, POSTFLAG = N, and BATCHSTAT = C [Closed]).
Load all active bill types and ensure that each one has a payment line item.
For each payment, validate the account.
If the account number can’t be found in the system, the payment status is changed to UNMATC (unmatched). If the account has a batch payment posting alert, the status is changed to ALERT. Unmatched and alert payments will not be posted.
Before posting the payment, post any account credits.
Posting credits is the same basic process as reconciling the account.
Create account and deposit transactions to apply the payment to unpaid charges until the payment fund are used up.
If funds remain after all charges are paid, create an overpayment in the ACCTTRAN table.
Create an account activity record for each payment posted.
For any accounts in delinquency, check if delinquency is eligible to be auto-decremented or resolved after payments are posted.

Payment application

Payments are applied in this order:

Donations. If the payment indicates that it includes a donation amount, then create a donation charge and post the donation amount toward that charge.
Pay Specific Bills. If the payment is directed to pay specific bill numbers, then pay those bills.
Deposits. If the payment specifies a bill type, then post toward unpaid, billed deposits on that bill type. If the payment doesn’t specify a bill type, then pay unpaid, billed deposits for any bill types that have the Pay Deposits First check box selected (BILLTYPE.PAYDEPOSITFIRSTFLAG = Y).
Unpaid Debt. If the payment specifies a bill type, then get all unpaid debt for that bill type and apply funds as available. If payment funds remain, follow the bill type's payment application rule to possibly apply toward other bill types as specified. If the payment application rule allows credits to be shared with other bill types, then pay those bills based on their payment order: first bill types with a pay order greater than the payment's bill type, then bill types with a pay order less than the payment's bill type. For example, if the payment’s bill type has pay order 4, then pay all unpaid charges for that bill type, then for bill types with pay order 5, then 6, and so on. After the highest pay order is reached, pay unpaid charges for bill types with pay order 1, then 2, then 3. If the payment doesn’t specify a bill type, then apply to all bill types on the account. The order of application to unpaid debts is as follows:
1. Bill Type Pay Order: Lowest to highest.
2. Bill Type Key: The lowest bill type key is the "tiebreaker" if there are multiple bill types with the same pay order.
3. Charge Status: Billed charges first, then Unbilled.
4. Bill Due Date: Oldest bills first.
5. Bill Key: The lowest bill key first is the "tiebreaker" if there are multiple bills with the same due date.
6. Line Item Pay Order: Lowest to highest
7. Line Item Key: The lowest line item key first, "tiebreaker" if there are multiple line items with the same pay order.
8. Line Item Add Date/Time: Earliest line items first.

Setup

This table describes the Configuration Editor settings that affect this task:


Configuration and path	Comments
BatchProcessing/TASKS/Task: PostPaymentsRun/Threads	Sets the number of asynchronous threads the Batch Manager will use for the Post Payments Run process. Note: The default number of threads for all multithreaded processes is set in the BatchManager configuration’s Number of Task Threads attribute. You only need to enter a separate value here if you want to override the default.
BILLING/BATCHMANAGER/Post Payment Batch Task Name	Sets the commit number for all payment posting runs. The commit number determines the number of payments processed in each thread. Note: You can enter any number, but there are limitations at the database level. Oracle databases have a limit of 1,000 records, and SQL Server databases have a limit of 2,000 records. Entering a larger number will cause errors.

This table describes the Infor Public Sector setup forms that are used to configure this task:


Setup form	Comments
Bill Type	The payment order and payment application rules for each bill type define how payments are applied.

This table lists the database tables that store setup information for this task:


Table	Comments
BILLING.BILLTYPE	The PAYDEPOSITFIRSTFLAG, PAYMENTAPPLICATIONRULE, and PAYMENTORDER columns control how payments are applied for each bill type.

Invocation

You can use the Batch Manager to schedule post payments runs, or you can use the Post Payment Batches form to post batches manually. This task has no parameters, so it isn’t available in the Billing Calendar.

Monitoring

If the payment posting task is successful, you should see a series of log entries similar to these in the Billing Batch Process log:

Payment Posting Run process, Started.
Payment Posting Run process, flagged for processing mode.
Payment Posting Run process, retrieving valid Payment batches available.
Payment Posting Run process, retrieved valid Payment batches available. Total count of batches: [#].
Payment Posting Run process, retrieved all valid billtypes. Total count of billtypes eligible to receive payments: [#].
Payment Posting Run process, finding if the batch [batch key] is valid for posting.
Payment Posting Run process, found [batch key] as valid for posting.
Payment Posting Run process, update the batch [batch key] for status as Pending.
Payment Posting Run process, is starting the generator.
Posting payments, in PaymentBatch number: [key] in a task batch size of: [#]
Payment # [key] in Batch # [#] loaded for posting.
Payment # [key] in Batch # [#] has been posted successfully.
Payment Posting Run process, finished calling the generator.
Payment Posting Run process, is stopping the generator.
Payment Posting Run process, completed successfully

In the database, the PROCESSINGFLAG column in the POSTPAYMENT table is set to Y at the beginning of the run, and set to N when the run is completed. In addition, the POSTFLAG column in the PAYBATCH table gives the current posting status of each batch, using these codes:

N: Not Posted
P: Pending
S: Selected
Y: Posted

Common errors

This table lists some common errors that this task may return:


Error message	Comments
`Payment batch [#] header count does not match with its payments count.`	The specified payment batch isn’t valid for posting because its batch count doesn’t match the number of payments in the batch. (The batch count is the number of payments expected in the batch, as entered by the user.)
`Payment batch [#] header amount does not match with its payments amount.`	The specified payment batch isn’t valid for posting because its batch amount doesn’t match the total amount of the payments in the batch. (The batch amount is the total amount expected in the batch, as entered by the user.)
`Payment batch [#] cannot be posted. It is currently in use by [#] cash drawers.`	The cash drawer must be closed before the batch can be posted.
`Account is on BatchPaymentPosting Alert.`	Batch Payment Posting alerts are triggered when you attempt to post payments to the accounts they’re attached to.
`Unmatched Account.`	The specified account number for a payment can’t be found in the database.
`Payment could not be posted. There is no payment line item defined for this bill type.`	Check your bill type setups. Each bill type must have a payment line item associated with it.
`User Exceptions defined for Batch Payment Posting encountered. Payment not posted. Payment # [#]`	The payment wasn’t posted due to a user-defined exception.
`Payment # [key] in Batch # [#] could not be posted successfully as no payment lineitemsetup was found on the billtypes: [bill types]`	Check your bill type setups. Each bill type must have a payment line item associated with it.
`Payment # [key] in Batch # [#] not eligible for posting as its status is [status]`	Depending on the status, you can use the Payment InfoViewer to fix the problem, such as transferring an unmatched payment.
`Unable to start the payment posting process. Bill Types [list of bill types] were found without an active Payment Line Item setup. A Payment line item setup must be assigned to these bill types before payment posting can continue.`	Check your bill type setups. Each bill type must have a payment line item associated with it.
`BillTypes [list of bill types] were found without an active Payment Line Item setup. A Payment line item setup must be assigned to these bill types before payment posting can continue.`	Check your bill type setups. Each bill type must have a payment line item associated with it.

User exceptions

The Post Payments Run is one of four batch processes (in addition to Bill Run Schedule, Direct Debit Run, and Penalty Run) for which you can define your own custom exceptions. Each custom exception you define uses a formula to determine when Infor Public Sector will return the exception. For post payments runs, there are two user exception severity levels:

Level 1: Do not process the account.
Level 2: Process the account but add an exception record.

Data output

This table lists the database tables in which this task adds or updates records:


Table	Comments
BILLING.ACCOUNTACTIVITY	Stores the account activity records added in the payment posting run.
BILLING.ACCTTRAN	Stores the account transactions added in the payment posting run.
BILLING. BATCHPAYMENTALERTEXCEPTION	Stores exceptions returned for accounts with Batch Payment Posting alerts.
BILLING.BILL	Updates the PAIDSTAT column for each bill paid in the payment posting run.
BILLING.LINEITEM	Updates the PAIDSTAT column for each line item paid in then payment posting run.
BILLING.PAYBATCH	Updates the POSTFLAG, POSTBY, and POSTDTTM columns for posted payment batches.
BILLING.PAYMENT	Updates the STATUS column for each posted payment.
BILLING.PAYSPECIFICBILL	Stores information on payments that are allocated to specific bills. See “How to Allocate a Payment to Specific Bills” in the Infor Public Sector Billing User Guide.
BILLING.POSTPAYMENTSRUN	Stores information on each payment posting run, including the run key, the number of exceptions, and the time the run started and stopped.

This table lists the Infor Public Sector forms that you can use to review the results of this task:


Table	Comments
Lookup Payment Batches	Standard Infor Public Sector lookup used to search for payment batches.
Payment Batch InfoViewer	Shows information on a selected payment batch, and can also be used to unpost the batch.
Lookup Payments	Standard Infor Public Sector lookup used to search for payments.
Payment InfoViewer	Shows information on a selected payment.
Line Item InfoViewer	Shows information on a selected bill line item. Can be opened from the Bill InfoViewer.
Bill InfoViewer	Shows information on a selected bill.
Lookup Transactions	Standard Infor Public Sector lookup used to search for transactions.
Transaction InfoViewer	Shows details for a selected transaction.