Understanding Payment Run
Payment Run (PYR) is used to settle selected outstanding transactions on creditor/payables accounts. It can also settle transactions on client accounts with a credit balance. Payment Run can trigger the creation of the necessary payment documentation, for example, remittances and cheques. It can also produce a bank transfer file for electronic transmission.
Payment Run can be initiated from the SunSystems menu, or from a control desk, or from Payment Selection and Review (PYS) (which is a specific control desk function that allows you to save sets of selected transactions for review and payment). The method you choose determines how the transactions to be considered for payment are chosen:
- If you initiate Payment Run from the SunSystems menu, the transactions are selected by the payment profile you choose, and any run time selection criteria you enter. You can define any number of payment profiles although only one can apply to a particular payment run. Each profile can contain different selection criteria, including account selection criteria, currency codes, due dates, and so on.
- If you initiate Payment Run from a control desk, the transactions considered for payment are those displayed on the control desk in-tray when you initiate the payment run process. A filter is used to extract the transactions for payment using the selection criteria defined within the filter.
- If you initiate Payment Run by using Payment Selection and Review (PYS), the transactions considered for payment are those in the payment set (saved set) that you create.
Payment Run does not automatically pay all of the transactions it is presented with for payment. It only pays those that are eligible for payment according to the many different payment criteria that can apply.
When you initiate Payment Run you must choose a payment profile, even if you run it from a control desk or from Payment Selection and Review. This is because the payment profile determines other important payment details including the type of payment output required, and the payment bank details.
Before you initiate a Payment Run, regardless of the method you use, you should identify or define the payment profile that contains the payment run requirements. You may also want to preview the payment selections.
If the Authorization facility is enabled and authorization stages have been defined for payment processing, Payment Run checks whether the transactions selected for payment require authorization. If they do, the payment run is suspended until the transactions are fully authorized. When they are fully authorized, the payment run is completed automatically and all you will need to do is produce the payment documents, if required.
When you run the Payment Run, you can choose to produce the payment run details report only and use this to verify that the correct payments are produced. This allows you to review the proposed payments and make adjustments, if necessary.
What Does the Payment Run Do?
Payment Run performs the following tasks:
- if it has been run from the SunSystems menu, it uses the selection criteria to locate the transactions to be considered for payment.
- it identifies the transactions eligible for payment.
- it produces a payment run details report that lists or summarizes the account transactions selected for payment and shows the total number and amount of the payments being generated.
- it optionally produces a warning if the bank accounts will become overdrawn as a result of the payments.
- it optionally produces a warning if a cheque payment exceeds the Cheque Payment Limit set in Ledger Setup (LES).
- it creates the payment details from which the payment documents are produced, for example cheques and remittances.
- it generates and posts the ledger transactions required to record the payments, any settlement discounts taken, and tax adjustments on the discount.
- Alternatively, if the Non Match of System Payments option is set to Yes in Ledger Setup, the payments and transactions are assigned the allocation marker of Paid Unmatched. This prevents them from being reselected for payment but allows them to be matched manually using a matching process. An allocation reference is entered on both sets of transactions but an allocation date is not entered until the transactions are matched.
- it optionally produces a bank transfer file, and users may view the bank file format, if the payment method is Bank.