Show TOC

 Approval and Release of Payment Specifications by Workflow


You want to subject the creation and change of payment specifications to an approval process.


When you create or change a payment specification, the workflow for check and approval in accordance with the dual control principle can be run.

You cannot change a payment specification with the status to be approved until it has been approved/rejected.

For a change that is subject to approval, the payment data is stored with the status To Be Approved.

When you change a payment specification, the system writes history records for the header data; it then displays these on a separate tab page in the display. The person actually doing the approving also sees which change needs to be approved. When you include new items or remove items, the new items or items deleted are also displayed on separate tab pages if the change is subject to approval. Each item contains information about when it was included in the payment specification.

If the payment specification is accepted, the check indicator is automatically removed from the payment specification and the payment specification receives the status Approved .

If a payment specification is rejected, it receives the status Rejected . In the line items assigned, the reference to the payment specification is automatically removed.


You decide whether the creation/change must be approved in event 5514; the relevant business object is CA_INDPAY. In addition to the status field (open/to be approved/approved), the Complete attribute exists. This must be set if the payment run or payment lot is to use a payment specification. This attribute can control the start of the approval workflow. For example, event 5514 can be so defined that the workflow only starts if the Complete attribute is set. This means that different users can carry out different changes without having to have each individual change approved before the next clerk can process the payment specification further.