11 identifying potential predecessor successor pairings
Identifying Potential Predecessor-to-Successor Pairings
The second selection type is for a predecessor account seeking a successor. This kind of pairing is less restrictive than the Successor-Predecessor selection, since it places no requirements on the current quarter’s status code. It must only be active during the prior quarter and show a successor SESA ID in the micro record. Those that are ignored by the selection are expressed by the formulation:
One of the offshoots of this selection logic is that accounts with obsolete associations to a successor can be selected every quarter if this account is reactivated at a later date. Since the active status code remains quarter after quarter, the existence of archival successor pairings can greatly expand the number of potential predecessor-to-successor selections. To offset the chance of false flagging of potential successors, an additional pre-match has been incorporated into the selection logic. The identified successor is read from a second copy of the Micro File. The only way for the potential successor relationship to be edited is by finding the successor and finding that it has not active during the previous quarter. Coding of this check looks like the following:
If the listed successor account does not exist on the Micro File, there is still one way that the predecessor may be chosen for inclusion in the predecessor/successor edits; that way is through a high ending employment value. To know whether this is possible, though, we must first determine what that terminal employment level is.
Just as the successor’s initial employment month needs identification, so too does the predecessor’s terminal employment month. The “T” notation is used for the terminal month’s index number, and for the associated employment value. The final month of employment is sought out, searching from the end of the four-month period to the beginning (i.e., from third month of current quarter back through to the third month of the prior quarter). Tied into this check is an inspection of the current quarter’s status code, since it is possible for an account to show non-zero employment values during non-active quarters (even though this condition can be flagged in the standard micro edits). If the employer is not active for the processed (a.k.a. “current”) quarter, then none of the current quarter’s months can be identified as representing the terminal employment.
The following table expresses the conditions that determine the terminal employment index and employment value:
| Step Sequence | Status Check | Empl Check | "T" Mon Index | EmplT |
|---|---|---|---|---|
| 1 | Statusc,x = '1' | Mon3c,x > 0 | 4 | Mon3c,x |
| 2 | Statusc,x = '1' | Mon2c,x > 0 | 3 | Mon2c,x |
| 3 | Statusc,x = '1' | Mon1c,x > 0 | 2 | Mon1c,x |
| 4 | (no check) | Mon3p,x > 0 | 1 | Mon3p,x |
| 5 | (no check) | (all others) | 0 | 0 |
If the account has been deselected up to this point because of the absence of the indicated successor on the Micro File, the terminal employment level is now checked for a special inclusion due to high employment. If the terminal employment exceeds PK016, the missing-successor predecessor record is still written to the Predecessor-to-Successor File. Otherwise, it is ignored.
Note: Before the introduction of the new predecessor/successor edits, the PK016 editing parameter had an alternative definition in P/S editing, with a 2-digit constant. Some States may not have modified this constant to the new 6-digit standard. If it still is a 2-digit value, the default value of 250 employment is employed as a default limit.
The P-to-S and S-to-P records are stored in two temporary predecessor/successor data transfer files that are externally sorted so they can be processed within the predecessor/successor edit program itself. Prior to getting into the edits themselves, however, the program must make a determination as to whether there is a one-to-one relationship present, or even if the supposed predecessor or successor exists. This paring down process is described next.
For each potential predecessor or successor pairing, the indicated matching SESA ID is read from the Micro File. If the record does not exist, it is usually inconsequential and may be skipped over. However, for an unusually large employer (one with employment above the PK016 level), the account will be flagged due to the absence of its predecessor or successor (this was already mentioned on the potential successor selection side as a fallback, but didn’t previously enter the potential predecessor side). For the predecessor seeking a successor, the non-existent account condition must be accompanied by a status code change for this predecessor (from active to inactive). However the successor seeking a predecessor has already been identified as changing from inactive to active during the processed quarter, so this additional check is superfluous. Coding for the discontinuity edit is as follows:
Edit Code 161 signifies an employment gap between the predecessor and the successor, which is certainly understandable when the successor fails to provide a future, or the predecessor fails to provide a past for the account association.
Once a predecessor/successor match is found (for which both the predecessor and successor employer exist), the edits can begin. There are two classes of predecessor/successor pairings, namely when the temporary predecessor and temporary successor records match, and when they don’t. If all of the information is brought forth in the two temporary files (one for the P-to-S checks, the other for S-to-P searches), then the data for both accounts are loaded into the program directly and the edits commence.
When only half of the relationship is found, however, the Micro File must be used to fill in the blanks for the remaining employer. In the same manner as had been previously described the predecessor’s terminal month or successor’s initial month information must be deduced by examining the employment values found in the micro record. The same index numbers are employed, as listed in the table below:
| Initial / Terminal Month Description | "I" / "T" Setting |
|---|---|
| [Statusc,x = '1' OR Mon1c,x = Mon3c,x = 0] AND Mon3p,x = 0 | T = 0 |
| [Statusc,x = '1' OR Mon1c,x = Mon2c,x = Mon3c,x = 0] AND Mon3p,x > 0 | T = 1 |
| Statusc,x = '1' AND Mon1c,x > - AND Mon2c,x = Mon3c,x = 0 | T = 2 |
| Statusc,x = '1' AND Mon2c,x > 0 AND Mon3c,x = 0 | T = 3 |
| Statusc,x = '1' AND Mon3c,x > 0 | T = 4 |
| Mon1c,y > 0 | I = 2 |
| Mon1c,y = 0 AND Mon2c,y > 0 | I = 3 |
| Mon1c,y = Mon2c,y = 0 AND Mon3c,y > 0 | I = 4 |
| Mon1c,y = Mon2c,y = Mon3c,y = 0 | I = 5 |
Now that the initial and terminal employment months have been established, the standard employment gap (Code 161) and overlap (Code 160) edits can be conducted. The gap edit was already applied for the one-sided relationship (where the indicated predecessor or successor account does not exist on the Micro File, but the employment on the present member is high. In both edits, multi-family break-outs are exempt, since they are not true one-to-one transitions. This exemption is checked with the following equation:
For the non-breakout situations, the following two edit formulations are enacted:
Related Links
