The payment event upload processes are designed to transform remittances from external sources into payment events, tenders and payments within the system, using information is uploaded into the payment event upload staging table.
The following topics highlight the main features of payment event upload.
The upload process uses distribution rules to create payments for the target business entity within the system, which is most commonly an obligation. Each upload staging record must have a valid account, distribution rule and value in order for a payment to be created. However, determining the correct distribution rule and value from the available reference information may be a complex process. For example:
The payment reference information may have multiple valid formats that can only be correctly identified by cross checking against existing system data.
The payment may be processed prior to the creation of the target obligation, for instance when a payment is uploaded before the associated form is posted.
A single payment may be remitted to cover multiple obligations, each with a separate payment reference value.
The first stage of upload processing provides the ability to examine the payment details in order to determine the appropriate target. It achieves this by executing a series of algorithms that are responsible for determining the appropriate account, distribution rule and value needed to create the payment. These algorithms are defined on the installation record. The plug in spot provides the ability to:
Review all the details in the payment upload staging record.
Add characteristic values to the staging record. These may be used capture information derived by the algorithms that should be stored with the payment for use in later processing.
Split a single payment into multiple payments by adding additional staging records. Note that the system assumes that the algorithm is responsible for allocating the combined tender amount across the new payments.
Indicate when the account, distribution rule and value have been determined so that no further algorithms are called.
Note that the algorithms for this plug in spot should not update the staging records directly. They should instead update the details passed from algorithm to algorithm in memory. The staging records are updated by the C1-PEPL0 process when algorithm execution is complete. The base algorithms use the data area C1-PayEvtDetermineDistProcData to read and update those details. Your implementation may extend this data area if your business rules require additional information to be passed between algorithms that does not map to one of the upload staging record fields.
It is possible that the Determine Distribution Rule algorithms are unable to identify the business entity for which the payment was intended. In this case, the system expects that one of the algorithms in this spot will be responsible for returning a distribution rule and value that allocate the payment to excess credit, if the account can be determined, or to general suspense otherwise. Base algorithms are provided for this purpose.
For more information about the Determine Distribution Rule algorithms refer to Installation Options — Algorithms
Each payment event in the system must be linked to a tender control. The second stage of upload processing is responsible for grouping payments by source, transmission and tender type in order to link them to a unique tender and deposit control prior to creating the payments.
The second stage of processing is also responsible for validating the key fields needed to create payments, including tender type and currency code as well as the account and distribution rule details. Validation is deferred until this stage so that records may be uploaded from the source and reviewed without encountering system errors due to invalid foreign keys.
The third stage of processing is responsible for creating the payment records. It creates a payment event and tender for each remittance then invokes the Create Payment algorithm for the associated distribution rule and value. The payment event creation is performed in a separate process, after the payor account has been determined, so that the process may be threaded by the account ID for performance reasons.
The fourth and final stage of processing is responsible for simply setting the tender and deposit controls to balanced for each set of completed upload staging records.
Copyright © 2007, 2016, Oracle and/or its affiliates. All rights reserved. Documentation build: 2.5.2016 10:21:45 [T1_1454696505000]