Show TOC

  Processing by Payment Run/Payment Lot

Use

Processing of payment specifications in the payment run and payment lot

Features

The payment run pays only complete payment specifications that have the status Open, Approved, or Reopened after Reversal of Payment. The payment run does not pay payment specifications that are in a workflow with the status To Be Approved. Instead it creates a payment exception. The changes from the workflow process (approval or rejection) are documented accordingly in the status.

Since you can group items from different business partners, the use of payment specifications is not suitable for parallelization using business partner intervals in the payment run. Items that the payment run reads in interval 1 (contains the business partner) are skipped here. In interval 2 (contains the payer), the payment run reads the items read in interval 1 again, since all related items have to be determined here.

Note Note

This second reading of line items increases the runtime of the payment run, which means that the procedure should not generally be used as a replacement for document changes (for example, entering payment method and bank data).

End of the note.

If the payment run makes the payment successfully, the system enters the number of the created clearing document (or payment order) and the payment run ID in the payment specification. The system displays this data on a separate tab. From this tab, you can navigate to the payment document, the payment order, or the display of bank data from the payment run, and from there to the payment run display. The following new exceptions can occur in the payment run:

  • 66 Payment Specification Still Has To Be Approved

  • 68 Amount of Payment Specification Does Not Correspond to Item Total

  • 69 Payment Specification Is Locked by Online Processing

When processing a payment specification, the payment run considers any existing payment and clearing locks in the contract account to be paid. The payment run does not consider locks on the assigned contract accounts of the line items – unless you have defined event 0617 accordingly (see below). Locks cannot exist on the assigned line items themselves, since locked items cannot be included in a payment specification for the payment run and no locks can be set for items in a payment specification.

The payment run does not consider custom selections (selection, for example, by document number or posting date) for the assigned items of a payment specification, since a payment specification can only be paid completely or not at all (and not partially).

The following logic applies for the interpretation of the payment data (header level):

The payment run treats the payment method, paying company code, bank details, card details, and own details as if they had been entered at item level and includes them in the payment data (DPAYH) such that they appear in the payment list and on the payment media printout.

The payment run evaluates your own bank details regardless of the indication of the payment method for controlling the bank selection (transaction FQP4). However, you can override this logic at event 0650.

The execution date is transferred to the payment data (DPAYH) and overrides the otherwise applicable standard logic. The standard logic determines the execution date from the due date of the items to be paid (for collection and several items with different due dates: the latest date; for outgoing payments: the earliest date). The payment run replaces an execution date in the past with the current date. Since not all payment media formats support an execution date at the individual payment level – sometimes such a date is only supported for the complete file – it can be necessary to agree with the receiving bank to what extent a file with payments with different execution dates can be processed.

The system transfers the DME data to the payment data (DPAYH) and overrides any specifications from the module in event 0630.

The text for the payment is not saved in the payment data (DPAYH) and is therefore not visible in the payment list. You can determine this text when the file is created by reading the data from the payment specification – the key is in the payment data – and noting it in a suitable place on the payment medium.

Partial payments are not possible with payment specifications. Event 0610 is therefore not processed in the payment program when you process payment specifications. Partial payment is also not possible if you use a payment specification as the selection criterion in the payment lot (comparable with the use of payment advice notes). In contrast, overpayments are possible in the payment lot and lead, for example, to postings on account or to other items being cleared.

Activities

If you define event 0617, you can turn a payment specification that the payment run considers to be payable into a payment exception by returning a corresponding item indicator (and corresponding message). For example, in this event, you can determine the payment locks of the contract accounts/contracts involved and prevent payment if a contract account of an assigned item has a payment lock in its master record. To put this into effect, you can use module FKK_SAMPLE_0617_PAYMENT_LOCKSV, or use it as a template for your own module.