05 es2x line multi change ownership selected worksites
ES2X - On-line Multi Change of Ownership for Selected Worksites
| Program ID: | ES2XP01 |
|---|---|
| Mapset: | ES2XMS1 |
| Input Files: | Internal Security File (ES2SECR - linked module only), Lookup File (ES2LKUP) |
| I/O Files: | Micro File (ES2MIC), Administrative Transaction File (ES2ATRN), Micro-Omni-Aux Transaction File (ES2MTRN), Quarterly Transaction File (ES2QTRN) |
This transaction enables you to enter the complex set of parameters used in the transfer of a specified group of worksites from one family to another (or to a receiving single account), then enact the transfer on-line. The specific parameter fields involved in both the sending and receiving family are individually labeled for simpler entry, as shown above.
Processing options here are manifold. The top half of the screen is effectively divided into four quadrants. The division of left-to-right distinguishes the sending (predecessor) and receiving (successor) account. The upper and lower division separates master from worksite parameters. The lower half of the screen specifies options and switches for the predecessor/successor transfer, along with the selection of which worksites from the sending family are involved in the transaction.
Master (or “Parent” as it appears on the screen) account data occupy the first four lines. The first row of fields represents the U-I account numbers involved and the expected final setting of the master MEEI codes. The MEEI code only needs to be specified if it will change because of this transfer; if the transfer occurs in the middle of a quarter, a sending master’s MEEI still doesn’t need to be identified, since worksites active for part of a quarter will still keep the master account classified as an MEEI of ‘2’. However, if the receiving account has been a single, the MEEI code should definitely be entered as a ‘2’.
Normally, the U-I account numbers will denote two existing families, though the receiving account may initially be a single. These fields identify a transfer of the yet-to-be-specified sub-units from the sending to the receiving account. However, a special case exists when the receiving account number is set to zeroes. This signifies that the sending account’s worksites are not transferring to a successor. Instead, this special “code” tells ES2X to terminate the sending worksites, as they are permanently closed without being sold to a new owner. In this case, the other right-hand fields in the boxed sections can be ignored.
The second line allows for a sending master account termination with the “EOL DATE:” field. There is no counterpart (such as an initial liability date) on the receiving account side, since the account must already exist. Even though a master account may be terminated along with the selling of all of the worksites, it is more common that the account will remain active, either with fewer worksites or operating as a single establishment. The other fields on the second line are the sending and receiving master’s sub-county zone or township code. Unless this field is both used by the State and changes with the transfer of the worksites, you will not need to enter this field.
The third line identifies the sending and receiving master’s county and comment code designations. The county code specification is most often needed in conjunction with an MEEI code change, since most States use a ‘900’ county code for master records, and a specific county code (‘001’, ‘003’, etc.) for singles. The comment code field allows you to note whether there is a full-scale predecessor/successor transfer (‘93’), or a merger, restructuring, etc. These codes help to explain to BLS what kind of reorganization is going on.
The fourth line lists two fields on the sending side and one on the receiving side. The first is the predecessor/successor effective date (“P/S DATE YYMMDD”), which already has its year-month-day format clearly delineated. This only needs to be listed when the family has been completely bought out by the successor. Although the date could be deduced from the worksite EOL and liability date fields (discussed below), this field acts as a confirmation for a global transfer of ownership. The second field is the predecessor/successor source code (“P/S SOURCE”), which is a big help in identifying how the transfer information was obtained. If it came directly from the employer, this would be set to “ER”, data supplied on the MWR forms would be entered as “MW”, reading in the newspaper or on the company’s website would be coded as “MD” for media, etc. Again, both fields should be left blank if the master is not going away.
The last field on this line is an option that applies only to singles that are receiving worksites to become multi-establishment employers. The yes-or-no question, “SINGLE TO WORKSITE?” is a special processing option; if selected (with a “Y” response), the receiving account’s data (which has been a single until now) will be copied as the first worksite (with RUN 00001) before any of the sending worksites are added to the family. Only data for the processing quarter (specified in the beginning of the lower half of the screen) and onward are included in the RUN #1 data transfer. If this option is not selected with a receiving single, the newly formed family could show significantly out-of-balance employment and wage data, since the transferred worksite data will be the only worksite-level information to balance against the master, which could have both old and new data summed together. Of course, if the receiving account is already a multi-family, this switch will be ignored.
Worksite-related data are found on two lines, below the master account parameters. The first line shows a switch on either side, indicating whether employment and wage data should be transferred from the sending worksites (“DATA XFER?:”), and whether the receiving worksites are willing to accept the same data (“DATA RECV?:”). This is probably an example where “flexibility and options” may have gone a bit too far. If both switches are set to the same value, everything is fine; however, when they are set to opposing values, the data will either be lost or doubled. When the data transfer (predecessor side) switch is set to “Y”, but the receiving (successor side) flag is set to “N”, it says that the employment and wages will be removed from the predecessor, but not received by the successor – so the data are lost. On the other hand, when the transfer flag is “N”, while the receiving flag is “Y”, the predecessor says, “No, I won’t let you have my employment and wages”, while the successor says, “Too bad; I’m going to take them anyway.” Hence, the data are duplicated on both records. We recommend both switches be set to the same value.
Also present on this first worksite line is the receiving worksites’ employment/wages default indicator value (“EMP/WAGE IND:”). This enables you to identify how you want the target quarter’s data, whether as missing (when the data are not received), hand-estimated, or reported (as though the new employer had already listed this information as their own, which may also be the case).
The second worksite data line contains three fields on either side. The sending account fields are the end-of-liability date (“EOL DATE:”), the target quarter’s status code (“STA:”), and the associated comment code (“CMNT:”). The receiving worksites’ fields are the same, except that the worksite initial liability date (“LIAB DATE:”) is substituted for the EOL date. The comment and status code values are connected to the processing year/quarter, which is described below. This is important. If you specify the worksites to be transferring at the end of 2nd quarter, but you use first quarter for the processing year/quarter, it could cause the accounts involved to get scrambled data; this can be difficult to rectify after it has taken place. More information about the processing year/quarter is explained later.
The first line of the bottom half of the screen includes the processing year/quarter (which appears as “PROCESSING YRQ:”), the number of months of employment to transfer (shown as “NBR OF MONTHS TO XFER:”), and an option to transfer the quarterly state usage field data (or “XFER STATE USAGE DATA?:”). Most of the fields shown on the screen (including the master MEEI, county and zone/township, and master and worksite status and comment codes) are quarterly occurrence items. The processing year/quarter sets the tempo for these field settings. The “number-of-months-to-transfer” field shows how many months (form zero through three) to forward from the sending/predecessor account to the receiving/successor account, assuming the switches (data transfer and data receive) have been set to permit these transfers.
These fields, as well as the number of employment months to transfer (shown as “NBR OF MONTHS TO XFER:”) field, will be tailored to the year and quarter specified in the “PROCESSING YRQ:” field. When the predecessor/successor transfer occurs during the midst of a specific quarter, then obviously that quarter should be the one listed in the processing year/qtr field. However, when the exchange takes place between quarters (such as when one set of worksites terminate on December 31, and the new ones are activated January 1, for example), there are two ways to set the quarter.
For an inter-quarter transfer, you can specify the newer of the two quarters in the “PROCESSING YRQ:” field, with all employment for the quarter transferred (“NBR OF MONTHS TO XFER:” set to ‘3’). The other alternative is to use the older year/quarter with no employment transferred. For instance, if the sending worksites terminate 6/30/2017, and the receiving worksites are established on 7/1/2017, then the two options are a year/quarter of “17/3” with “3” months transferred, or a year/quarter of “17/2” with “0” months transferred.
When the transfer occurs in the middle of the quarter, the number of months to transfer will be the number of months left in the quarter. For predecessor worksites terminating on 10/31/2017, there are two months left in the quarter (November and December), so the transfer-month count should be set to “2”. A November 30th EOL date for the worksites means that the month count should be set to “1”, since only December remains in the fourth calendar quarter.
The sample screen shown at the beginning of this ES2X section represents a transfer of worksites from one multi-unit family to a single. The top portion (with master account data) is depicted above. As you can see, several fields are left blank; anything that will not change as a result of this transfer does not need to be entered here. In this instance, the MEEI code will change to a ‘1’ on the sending account, but a ‘2’ on the receiving account, the county and zone codes (if the State even has sub-county zones) remain untouched, and the sending account is also going out of business, so the EOL date is specified. A comment code has not been entered (though a ‘93’ would denote a predecessor/successor relationship had been entered), but a different code could be used if this were a merger, reorganization, etc. Since the receiving account is a single, the “SINGLE TO WORKSITE” switch is selected. The predecessor/successor effective date (i.e., “P/S DATE”) was identified as 3/31/2017, assisting in the setting of the “PSA” (Predecessor / Successor Actual) File data; the P/S source (“WR” for wage record) was also included for completeness.
The worksite-related data (from the middle of the screen) are shown above. This sample is fairly typical of an inter-quarter transfer. The sending worksites’ employment and wage data will be forwarded (“DATA XFER?: Y”) to the newly created successor worksites (from the target year/quarter onward), and the receiving worksites welcome this information into the new records (“DATA RECV?: Y”). Once the new data have been received into the worksites, the wages and employment will be treated as reported through the default indicator (“EMP/WAGE IND: R”). The two date fields are coordinated, so that the sending worksites terminate at the end of first quarter (“EOL DATE: 170331”), while the new worksites start out at the beginning of second quarter (“LIAB DATE: 170401”). The comment code on either side of the relationship confirms the predecessor/successor transfer (’93’).
The lower portion of the screen (in the image below) completes the parameter selection process. As suspected, the processing quarter is 17/2. The “3” in the “NBR OF MONTHS TO XFER:” field declares that all three employment months (as well as the entirety of the wages) for the target (17/2) quarter will be transferred from the sending to the receiving worksites. Since the sending worksites terminate at the end of first quarter, it is altogether appropriate for the second-quarter data to transfer to the successor worksites.
The “XFER STATE USAGE DATA?:” option refers to the quarterly six-byte state usage field. Some States place numeric data in this field (such as an auxiliary employment field). If so, it is often helpful to maintain this information in the successor worksites. States that don’t use this field can leave it at its default of “N”. The next switch (“ADJ S-END R-ECV Y-BOTH MASTERS?”) is used to adjust master account values to compensate for transfer of worksite data between the two accounts. This can be set to an “S” to include only the sending master, “R” to include only the receiving master, “N” to adjust neither the sending nor receiving master, or as a “Y” to specify both the receiving and sending masters to be adjusted. This allows the departing worksites’ employment and wages to be deducted from the sending master, while appending them to the receiving master’s (or single’s) data. This assumes that the data for both accounts had been properly balanced to account for the original presence or absence of these worksites. If the masters were not previously balanced, but are receiving proper reconciliation with the worksites’ transfer, then this switch should be set to “N”.
The one remaining switch, “COPY RECEIVING MSTR LEGAL NAME TO WRKSITES?”, is reasonably straightforward, except for the abbreviations of “Master” and “Worksites”. If set to “Y”, all of the new worksites will accept the receiving master’s legal name as their own. For instance, if the sending worksites belonged to “Joe Smith Electronics Corp.”, but they are now part of “Dan Doherty’s Deluxe Digital Stuff Inc.”, the affirmative selection on the switch will copy Dan’s corporate name to the new worksites, even though the trade names will initially remain the same as they had been. If the switch were set to “N”, then the “Joe Smith” legal name will remain for the additions to Dan Doherty’s corporation.
The worksites’ RUN selection process is the same as that utilized in the ES2V screen. It is not necessary for the entire worksite family on the sending side to transfer to the receiving account. The individual worksites involved can be isolated in either of two ways. First, a range of reporting unit numbers, with a maximum of 20 units, can be specified with the starting and ending RUN fields. This will enact a browse through the Micro File to find all units within the specified range. In the sample above, all of the worksites were involved in the transfer, namely those in the RUN range of 1 to 14, inclusive. These were selected via the range fields, which redisplayed the RUN’s in the desired range. If the affected worksites had widely dispersed RUN’s (like 7, 21, 23, 50, and 64), then you would need to employ the second selection method, namely to type in the affected RUN’s individually in the 20 fields provided below the range line. As with other RUN entries, the leading zeroes do not need to be entered, since the system will zero-fill the information for you.
The selected RUN’s (whether picked by range or individual entry) are displayed in the up-to-20 specific RUN fields for analyst review. If they are correct, the transfer can be enacted by pressing the Enter key. If some of the units in the range should not be included, they can be removed by selectively tabbing and clearing fields with the Erase-to-End-Of-Field (EOF) key (which is usually represented by the End key in PC emulation software). Only those worksites that are active in the selected quarter will go across and be listed with the “TRANSFER” confirmation message. Inactive (status “2”) worksites will show the “INACTIVE” message beside them instead.
One of the goals of this screen is to limit the number of I/O calls performed in a CICS cycle. In transferring 20 worksites, nearly 200 I/O operations are involved between the original family and new family reads, writes and rewrites, and the Transaction File writes.
Function keys used in ES2X are the standard F1 (menu) and F3 (exit), along with the F5 key, which is the “Reset” function. This will clear the screen, which can be useful if you begin typing in entries only to realize that the relationship was already processed, or you’ve made enough mistakes in entry that you just want to begin again with a “clean slate.”
Related Links
