Db2® has its own validity edit that it imposes on the Business Rules set, but the application does an extra second-pass check. These edit rules are needed
because the Db2 constraint edit has a limitation to ensure current
Business Rules integrity. Currently, the only table that requires this second-pass edit is
POCKET_MAP. If the customer removes the POCKET_MAP entry from the PAYDIR.TABLES table, the second-pass edit is
not done.
Depending on how the user sets up the sort type table, the field names of the following edit rules can be
in multiple different database tables. For the exact field names and related tables, contact your database
administrator.
Edit rule 1
Do not use this
participant ID in another entry in the same sort type for any
other pass. This entry would be the only entry allowed.
| Sort Type |
Pass |
Pkt1 |
Pkt2 |
Pkt3 |
Participant ID |
Pkt |
Endpoint |
| 001 |
1 |
23 |
00 |
00 |
90909090 |
23 |
12345678 |
The entry in the following table is invalid because the
participant with ID
90909090 was already assigned an endpoint that was killed.
| Sort Type |
Pass |
Pkt1 |
Pkt2 |
Pkt3 |
Participant ID |
Pkt |
Endpoint |
| 001 |
2 |
23 |
00 |
00 |
90909090 |
2 |
|
Edit rule 2
Participant IDs that are designated as a rehandle pocket, that is, they were
not assigned an endpoint, must be assigned to a subsequent pass until an endpoint is assigned. The following
table is valid because no endpoint is assigned until the
participant ID is killed.
The last entry of the following table is invalid:
| Sort Type |
Pass |
Pkt1 |
Pkt2 |
Pkt3 |
Participant ID |
Pkt |
Endpoint |
| 001 |
1 |
23 |
00 |
00 |
90909090 |
23 |
|
| 001 |
1 |
23 |
24 |
00 |
90909090 |
24 |
|
| 001 |
1 |
23 |
24 |
26 |
90909090 |
26 |
34534567 |
Edit rule 3
A
participant ID cannot be assigned to a rehandle pocket in a subsequent pass
after it was assigned an endpoint. The following table is invalid because after the
participant ID is killed, no more entries within the same sort type can be made for that
participant.
| Sort Type |
Pass |
Pkt1 |
Pkt2 |
Pkt3 |
Participant ID |
Pkt |
Endpoint |
| 001 |
1 |
23 |
00 |
00 |
90909090 |
23 |
|
| 001 |
1 |
23 |
24 |
00 |
90909090 |
24 |
12341234 |
| 001 |
1 |
23 |
24 |
26 |
90909090 |
26 |
|
Edit rule 4
A
participant ID cannot be assigned twice (to more than one pocket) within the
same pass. The following table is invalid because after the
participant ID was
assigned a pocket and an endpoint, it cannot have another one.
| Sort Type |
Pass |
Pkt1 |
Pkt2 |
Pkt3 |
Participant ID |
Pkt |
Endpoint |
| 001 |
1 |
23 |
00 |
00 |
90909090 |
23 |
23232323 |
| 001 |
1 |
24 |
00 |
00 |
90909090 |
24 |
12341234 |
Edit rule 5
A
participant ID cannot be assigned to a pocket in a subsequent pass if it was not
assigned a pocket in the prior pass. The following table is invalid because each pass must assign a
pocket.
| Sort Type |
Pass |
Pkt1 |
Pkt2 |
Pkt3 |
Participant ID |
Pkt |
Endpoint |
| 001 |
1 |
0 |
00 |
00 |
90909090 |
0 |
|
| 001 |
2 |
0 |
24 |
00 |
90909090 |
24 |
12341234 |
Edit rule 6
Each pocket and endpoint combination must be unique within a pass. It is valid to assign any number of
participant IDs to the same pocket in the same pass. Do not put more than one entry
for a
participant within the same pass.
| Sort Type |
Pass |
Pkt1 |
Pkt2 |
Pkt3 |
Participant ID |
Pkt |
Endpoint |
| 001 |
1 |
10 |
00 |
00 |
80808080 |
10 |
23232323 |
| 001 |
1 |
10 |
00 |
00 |
90909090 |
10 |
23232323 |