
The process flow of the payment program is as follows:
- Open items are selected and grouped for payment.
- Open items requiring special processing are determined.
- The payment methods and bank details are determined.
- The payments are posted and payment media are created.
If desired, you can execute a test run of the payment program prior to the actual payment run. The test run creates a payment list, but no payment documents (tables DPAYH, DPAYP).
Payment data and payment exceptions can be viewed (but not changed) in the payment list.
Payment media (in electronic form or as printouts) is created based on the payment data.
Payment runs use the technique of parallel processing.
You can specify for each item, whether an item is to be placed in the clarification list.
The data that controls the payment run is specified in the master data, in the document, in customizing, and in the current payment run parameters.

You can use preselections for a set of master data in the payment run by choosing Technical Preparations → Define Preselection.
Selection according to company code is mandatory. Payment methods are country-specific. For this reason, it's only possible to select company codes within a country that has the same currency in each payment run.
The posting date of the payment run is applied as the baseline date for determining the due date, except in the following cases:
If a deferral date has been entered in an item, it's always used to determine the due date.
If the cash discount date is prior to the posting date, the cash discount due date is used to determine the due date and the item is paid minus the cash discount.
If the cash discount period has expired, the due date for net payment is used.
The due date for an item that is determined in this manner must fall within the due date interval entered in the General Selections tab of the payment run parameters for the item to be paid.
You can restrict the payment run to one payment card type. You can then run separate payment runs for each payment card type, even though the payment method category of Card Payment is always the same.
Grouping of Open Items
Business Partner
Alternative Payer
Contract Account
Payment Method
Payment Term
Payment Lock
Currency Key
Paying Company Code
Application Area
Business partner items are grouped together into payable groups. Items can only be grouped together if business partner items are not restricted by the selection of a contract account.
The paying company code and the account being offset are determined using the assigned contract account in the document.
The application area can enter data in its own grouping field in the designated event 0600. This data could include reference details from the contract. This event can also be used to lock items while the payment program is running.

You can specify multiple payment methods for outgoing payments in a contract account’s or contract object’s master data. In this case, the checks outlined in the figure above are carried out for each payment method until a valid payment method is found.
If payment optimization is not required, the house bank with the highest priority is always selected (see bank selection in parameter maintenance).

The payment program is implemented as a mass activity.
Once open items have been grouped, the system determines the appropriate payment method, and selects a bank from the bank parameters entered in the payment run.
Currently, it's only possible to prioritize banks for bank selection optimization. It's not yet possible to enter available amounts for each of the respective bank accounts. You can maintain bank selection for all company codes simultaneously.
For cross-company-code postings, the company code belonging to the contract account must also be the responsible company code for the company codes in the line items.
If other company codes are billed using the contract account, incoming payments on receivables in these company codes are always posted to a company code settlement account in the responsible company code first (same procedure for outgoing payments).
Choose figure 162 payment list, Course IUT240, Col 62, see also file iut240_en_col62_fv_inst_a4.pdf

You can exclude items from payment within the payment run as well (in addition to setting processing locks on a contract account or in a document).
You can define payment lock reasons in customizing to exclude items from payment.
You can review all items that cannot be paid automatically in the exception list.

You can specify that payment media is to be created in the language of the business partner. If this indicator is not selected, the system searches the content table (depicted in the preceding figure) for a blank language key and uses the parameters specified for this table entry. It's, therefore, important to enter a language key for each note to payee category in the table.
You can use the SAPFKPY3 report to determine whether or not this indicator has been selected.