Data Setup Examples of Payment Distribution Details
Typically, each staging record will represent a single payment event - with a corresponding payment tender and payment. However, it is possible to specify complex relationships within a set of staging records. For example, it will be straightforward to define a set of staging records that represent a single tender but multiple payments (to model the single payment tender of a welfare agency which covers payments for multiple accounts). Similarly, it is equally possible to define a set of staging records that represent a single payment but multiple tenders (although not a common requirement).
Each staging record can represent:
• Zero or one new payment events. Typically, each detail staging record will represent a single payment event. However, it is possible to define multiple records for a single payment event. All details for a single payment event are identified by a common value on the staging record: Pay Event Process ID.
Note:
Pay Event Process ID. This field is used for grouping staging records and for organizing parallel threads (in the C1-PEPL2 process). Therefore, it is strongly encouraged that it bears a relationship to the tender account ID.
• A partial or one new payment tenders. Typically, each detail staging record will represent a single payment tender. However, it is possible to define multiple staging records for a single pay tender. All details for a single tender are identified by a common payment event ID as well as common tender information (tender type, tender account ID, check number, external reference, etc.).
• A partial or many new payments. Typically, each detail staging record will represent a set of one or many new payments. However, it is possible to define multiple staging records for a single payment. All details for a single payment are identified by a common payment event ID as well as common distribution rule and characteristic value information.
The sections below provide examples of a few of these complex payment event configurations. Note that these examples assume the same distribution rule is referenced in all staging records.
• Staging Entry Example 1: One Payment Event, Two Tenders, Two Payments
• Staging Entry Example 2: One Payment Event, One Tender, Two Payments
• Staging Entry Example 3: One Payment Event, Two Tenders, One Payment
Staging Entry Example 1: One Payment Event, Two Tenders, Two Payments
Seq. | Pay Event Process ID | Tender Account ID | Tender Ref. | Date | Rule Value | Amount | Tender Type | Check No |
1 | 1234567890 | 1234567890 | 112A | 1/1/2006 | 113-54-8978 | 30.00 | Check | 101 |
2 | 1234567890 | 1234567890 | 112B | 1/1/2006 | 575-40-3030 | 40.00 | Check | 102 |
Top of Page
Staging Entry Example 2: One Payment Event, One Tender, Two Payments
Seq. | Pay Event Process ID | Tender Account ID | Tender Ref. | Date | Rule Value | Amount | Tender Type | Check No |
1 | 1234567890 | 1234567890 | 112A | 1/1/2006 | 113-54-8978 | 30.00 | Check | 101 |
2 | 1234567890 | 1234567890 | 112A | 1/1/2006 | 575-40-3030 | 40.00 | Check | 101 |
Top of Page
Staging Entry Example 3: One Payment Event, Two Tenders, One Payment
Seq. | Pay Event Process ID | Tender Account ID | Tender Ref. | Date | Rule Value | Amount | Tender Type | Check No |
1 | 1234567890 | 1234567890 | 112A | 1/1/2006 | 575-40-3030 | 30.00 | Check | 101 |
2 | 1234567890 | 7878787870 | 888Q | 1/1/2006 | 575-40-3030 | 40.00 | Check | 9872 |
Parent topic