The normal life cycle of an outgoing payment transaction ends when the debtor makes payment.
After payment has been dispatched for an outgoing payment transaction, your bank may require tracking related to receipt of confirmations from the counterparty. For this, Oracle FLEXCUBE provides the facility of tracking and monitoring outgoing payment transactions from the time they are dispatched, till confirmation is received from the counterparty.
An outgoing payment transaction goes through the following stages after it is dispatched:
Waiting (WT)
After dispatch, till a response is received, the transaction is ‘in waiting’.
Processed (PD)
When a positive response is received, the transaction is said to be ‘processed’.
Canceling (CG)
After processing, if the transaction is required to be canceled, an appropriate message to this effect is sent to the interface.
Canceled (CD)
When a positive response to a canceling message is received, the transaction stands ‘cancelled’.
Undelivered (UD)
If, after successful processing, the creditor’s bank is not able to deliver payment to the ultimate beneficiary, and an appropriate message is received to this effect, the transaction is said to be ‘undelivered’
Timeout (TO)
If no response is received within a stipulated period for an outgoing payment, the message would be re-dispatched a stipulated number of times. When the stipulated count is reached, the transaction is said to be ‘timed out’.
This situation could also arise when no response is received to a ‘canceling’ message, in which case the transaction acquires a Cancel Timeout (CT) status.
Reject (XX)
The receiver of the payment message could reject it. In such a case, the message stands ‘rejected’.
This situation could also arise when a ‘canceling’ message is rejected, in which case the Cancel Reject (CX) event is automatically logged for the transaction.
Error (ER)
The receiver could also log an error in respect of a message, due to technical problems, for instance. In such a case, the message is said to be in ‘error’, and an appropriate log would be maintained to document the error.
This situation could also arise when an error is logged in respect of a ‘canceling’ message, in which case the transaction acquires a Cancel Error (CE) status.
Note
A message that has been ‘timed out’ (TO) or is in ‘error’ (ER) can be re-sent, in which case it moves back to being ‘in waiting’ (WT).
As mentioned earlier, Oracle FLEXCUBE provides the facility to track the different stages enumerated above. The facility is known as the Outgoing Payments Workflow, and is only available for transactions processed using a product category for which the workflow has been enabled.
This chapter contains the following sections:
This section contains the following topics:
This section address the outgoing payments workflow for payments processed using an outgoing payments product.
You must select the Outgoing Payments Workflow option as a product preference, when you are defining the product.
Outgoing payments are dispatched through the Oracle FLEXCUBE Clearing Gateway, which is an interface provided by Oracle FLEXCUBE for dispatch to clearing. The following specifications are made in the Oracle FLEXCUBE Clearing Gateway for the outgoing payments workflow:
For details about the Oracle FLEXCUBE Clearing Gateway, refer the Clearing Gateway user manuals.
When you are defining the outgoing payment product category, you can indicate whether custom reference numbers must be generated by the system for outgoing payments, either on online entry or during upload. If this option is indicated, then you must also specify the sequence code that must be used to generate the custom reference number sequence. The custom reference numbers are then generated according to the specifications made for the specified sequence code, in the Sequence Generation maintenance.
For details about how the sequence code is constructed in the ‘Sequence Generation Maintenance’ screen, consult the Core Services User Manual.
For contracts using an outgoing payments product for which the outgoing payments workflow has been enabled, the status of the message can be viewed in the ‘PC Transaction Input’ screen.
The status could be any of the following:
When the status of such a contract changes, the event Outgoing Payment Status Change (OPSC) is triggered, updating the status. This event is logged in the event log for the contract, and the details of processing can be viewed in the ‘PC Contract View Events’ screen, which you can invoke from the ‘PC Transaction Input’ screen by clicking ‘Events’ button.