05 es2h line master worksite inquiry
ES2H - On-line Master/Worksite Inquiry
| Program: | ES2HP01 |
|---|---|
| Mapsets: | ES2HMS1, ES2HMS2, ES2HMS3 |
| Input Files: | Internal Security File (ES2SECR), Lookup File (ES2LKUP) |
| I/O Files: | Micro File (ES2MIC), Quarterly Transaction File (ES2QTRN) |
This is the on-line inquiry transaction for master and worksite records that comprise multi-unit families. The program controls three screens, which allow the user to view a master account and all associated worksites. This program permits inquiry and some updates. The individual records on the Micro File are primarily updated through the maintenance screens (ES2C, ES2R, and ES2V), or from batch jobs 024E and 024P. The updates available here are an on-line proration feature and the ability to update employment and total wages, all on the Taxable Wages screen.
The first screen (shown above) gives a short summary for each of the worksites, in order to fit more of the sub-units on the screen at one time. The summed worksite data are optionally displayed as well (determined by the “SUM” entry field). If used, the sums are compared to the master account values, providing a simple and straightforward method of visually checking the balance of the family. To assist in balancing, the standard multi-family balance edits are performed on-line. Any fields that are out of balance by more than the allowed set of tolerances will be displayed in red. Selection options found at the bottom of the screen can limit the number of sub-units to be displayed; these selections filter out any worksites that do not share the desired county (or MSA counties), NAICS, and/or zone or township codes. In addition, a particular status code can be isolated by using the STATUS indicator, to show active (1, the default), inactive (2), pending (9) worksites, or establishments of any status (X).
Three forms of this screen exist. The first (as shown above) includes the status code, sub-county zone or township, county, NAICS, four months of employment, and the total wages. The second form (shown below) provides more historical detail on the individual sub-units. Switching between the first and second screen is accomplished by pressing the F6 key. Note that it still has the SIC code, though that field is obsolete now. The third format (appearing later) removes the status, the quarterly code values, and the oldest (third month of the prior quarter) employment, shifts the remaining fields to the left, and adds taxable wages and contributions to the right side of the screen. Toggling between the first and third screen formats is enacted with the F11 key. This format has extra processing features, which will also be described on following pages.
Another option for the first screen is to display the reporting unit description field in place of the trade/DBA name, by typing the F12 key. For some multi-families, the reporting unit description can be more relevant for identifying the individual worksites. It may contain a store number or other unique identifying information that can be helpful in the review of the family.
It is often difficult to distinguish reported from estimated data without including an indicator field in the display. For the screens on the current and previous page, there simply isn’t enough space on the line for these fields. To address this problem, the employment and wage fields are color-coded on the primary and detailed ES2H screens. Missing fields appear in blue. Estimated data appear as pink. Reported values show up in the standard turquoise color. Besides adding to the aesthetics, the color scheme also allows more information to be displayed, since the addition of indicator fields requires several bytes of valuable screen width.
The second screen format (shown above) gives more detailed information on each worksite. Five quarters of employment and total wage data appear with physical address information. The master account (or topmost worksite if the master is not currently displayed) also includes the phone number. With all of these added data fields, only three worksites appear on the screen at a time. Even though more data are shown for each worksite, the worksite-sum line is not available on the detailed screen. Therefore, it is best used for historical reference rather than for balance checking.
To scroll through the worksites in either screen, the F7 (for paging up (back)) and F8 (for paging down (forward)) keys are used. Both screens are cursor-sensitive. Tabbing the cursor beside any of the displayed worksites and pressing the Enter key will transfer control to the ES2C Front Screen, displaying full data for that worksite. This same transfer can be accomplished by pressing the F9 key, but this uses the reporting unit number displayed in the bottommost detail line of the screen, just above the ACCT: entry and PF key descriptions.
Unlike the first screen, no selection by status code, NAICS, county or zone/township is enacted on the detailed screen. An added field, however, is the total wage indicator. Although this cannot show whether the employment values are estimated or reported, it helps to define the color-coding of the employment and wage fields (specifically whether a pink estimate is hand-entered (‘H’) or machine generated (‘E’)) already in use for all ES2H screens. As noted previously, pressing the F6 key enacts transfers from one display to another.
The third form of the screen (shown above) is quite similar in appearance to the first, but has a significant expansion of functionality. The status, sub-county zone/township, county, NAICS, and prior-month employment fields are replaced by the taxable wage and contribution fields shown on the right-hand side of the screen. The total wage indicator is also now displayed (the same as in the detailed screen), but the only displayed values are ‘E’ or ‘H’, to isolate machine-generated versus hand-entered estimates.
There is also a default indicator (IND:) field entry available, since this is the one ES2H screen that allows updates to be made to the employment and wage fields.
In addition to the format differences, however, there are several special features available only on this third screen format. All of these are enacted through the function keys. First, the F10 and PF22/Shift-F10 keys enable on-line proration of a delinquent family of worksites. Second, the PF23/Shift-F11 key (only visible to administrators) can be used to erase the worksite employment and wage data for the quarter, making it available for a proration, using F10 or PF22. Third, you can bookmark your current position in multi-balance review with the F4 key, in the same manner as has already been employed with the ES2E screen for micro-edit bookmarks. Fourth, the out-of-balance multi-families can be sought out and displayed here using the F6 (next-unbalanced) and F5 (previous unbalanced) keys. Each of these special functions will be described in more detail in the paragraphs that follow.
This particular ES2H screen essentially uses an “editing” mode. Unlike the other “H” screen variations, the employment and wage fields are updateable in this format, either by direct data entry or by function key family-level changes. You can peruse through all families that have been identified as out-of-balance by Job 003D through the use of the F5 and F6 keys. F6 will take you to the next family in the out-of-balance report, even if you have entered the screen without displaying a family. For a blank initial screen, F6 calls up the first out-of-balance family for the current quarter. The F5 key reverses the direction, searching for and displaying the previous out-of-balance family in the report.
When the proration option is selected, the results are immediate and gratifying; the EXPO “auto-pilot” proration method will counteract rounding problems to produce a precisely in-balance family. For the sample account shown on the previous page, the F10 proration results would appear like the image above.
In this case, there are two worksites that carry partial reported data. It looks like a smooth transition between the worksites and the master account. In this case the employment (off by 10), and wages (off by $100,000), are smoothed out using the prior-quarter data.
Normally the out-of-balance families are listed in U-I account number sequence. However, the ownership code can be used as a high-level sort parameter, if desired; in this case, all of the Federal-ownership families would appear first, followed by State-government, local-government, and finally privately owned multi-families.
Multi-balance edits are conducted for two quarters (current and prior), but will be listed only for a single quarter at a time. ES2H will default to the current quarter unless the year/quarter field (at the top of the screen) is entered first. As you scroll forward and backward through the out-of-balance families using the F6 and F5 keys, only those families identified for the displayed quarter will appear. If you type in the other year / quarter on the screen’s top-line field, the display will shift to those that are unbalanced for that quarter instead.
Note: If the quarters have shifted since your last multi-balance (Job 003D) run, there will be no out-of-balance families found for the new current quarter.
Once you have an out-of-balance family displayed, the challenge becomes how to resolve and correct the disparities present. As with the micro edit resolution in ES2E, there are numerous reasons for the family to be unbalanced between the master and the summed worksites. Some States use scanners to read in MWR data directly; these may have spotty results, missing or misinterpreting some figures. When such mistakes are found, the corrections can be entered by hand in the absent or misconstrued fields. The revised totals will be calculated as soon as the Enter key is pressed, and the multi-balance edits are re-performed to show which fields, if any, are still deficient.
When both the master’s QCR (quarterly contribution report) and the worksites’ MWR have been received, but the totals disagree, manual adjustments need to be made to align both sides. There is no pat answer as to how to make such adjustments. There may be mistakes or incompleteness in the MWR data, or the employer may have made a mistake in submitting the QCR. The best resolution for such disparities is other source data. Wage record data can provide definitive evidence as to which side is correct, especially when the differences are sizeable. These can be checked on the ES2C Wage Screen.
Note: There is also a possibility that both the worksites and the master account were fully reported, yet out-of-balance. This will be handled eventually by a Shift-F9 key that has not yet been developed.
In the absence of corroborative data from external sources, you may need to review family historical employment and wages. If the worksite data show little variation versus the prior quarter, but the master account shows a tremendous downturn, the QCR may have contained a typographic error. When a solution is found to the inconsistencies, it can be applied by entering any deficient fields. Once the family is balanced, the record is removed from the Micro Edit File, allowing processing to continue with the next family.
Occasionally, the worksite data may have been completely misprocessed. The employer may have filled out the form incorrectly, such as with monthly wages instead of monthly employment figures. Manual correction of the entire family can be quite time consuming, especially when there are dozens or even hundreds of worksites contained therein. Fortunately, there are some useful tools to automate much of the worksite global adjustment procedure.
The PF23/Shift-F11 key is available as a worksite data erasure key. However, only administrators (with an access level of “A” on the ES2M screen) can access this feature. For everyone else, there is not even a description of the ‘F11’ key at the bottom of the screen. If a manager-level (“M” access) person wants to make use of the erasure feature, they must first go to ES2M and alter their own security level to “A”.
This worksite employment/wage removal feature is similar to the one available in the ES2R MWR data entry screen via the F11 key. However, the “R” screen can only remove estimated or prorated data, whereas the ES2H PF23/Shift-F11 key can even clear out reported data. It is therefore a powerful function that should be used with great caution. The employment/wage data erasure is done in anticipation of the application of system-generated prorations for the worksite family. After the PF23 key has been enacted, almost all worksite data will have been changed to zero/missing values. The one exception to this erasure is for worksites that would become inestimable once their reported data were removed. These are worksites are first-time reporters that have no historical data upon which to base a current-quarter estimate. If these values are incorrect, they must first be manually adjusted before a proration can be applied for the rest of the family.
There are two forms of on-line proration available. Using F10, prorations can be computed based upon prior-quarter-to-current-quarter data shifts. The PF22/Shift-F10 key, however, utilizes year-ago data for a highly seasonal multi-family that may have insufficient prior-quarter information, but adequate year-ago values upon which to base the proration. These processes will be described separately, since they vary markedly from one another. First up is the most common usage, the prior-quarter-data prorations.
The F10 on-line proration feature is capable of accommodating a multitude of shortcomings in the worksite data. First of all, the presence of reported data for some of the worksites does not preclude a proration of the delinquent worksites. They are simply removed from the master’s combined values so that the remainder can be parceled out among the remaining worksites using proper proration ratios. Secondly, worksites that go out of business mid-way through the quarter will not cause an out-of-balance problem in the prorations. Normally, a worksite that is active only for the first one or two months would cause the remaining months of employment to be short-changed, and the terminated worksite’s wages to be overstated. Thirdly, unlike Job 003D, these prorations can be implemented for any quarter on the Micro File, except for the very oldest quarter (i.e., the eighth quarter, which is always locked and can never be altered). In the batch estimations, only future, current, or immediate prior quarter data are eligible to be prorated. On the other hand, the out-of-balance families for older quarters must be found manually, since the information is not stored in the Micro Edit File. The more complete proration is enabled by a tactical modification to the distribution algorithms.
The BLS-defined batch prorations for employment process each worksite in turn. The first month’s employment is estimated by applying a ratio to the worksite’s prior-quarter third month employment (that ratio defined as the master’s first month employment divided by the sum-of-worksites-prior-quarter, third-month employment). Then the newly estimated first month’s employment is multiplied by the second-month/first-month master employment ratio to determine the second month employment for the worksite, and the third month’s employment is calculated last, using the second month’s employment multiplied by the master’s third-to-second month employment ratio. Hence, the third-month employment estimate is not based directly on reported data; it uses second-order indirection. In other words, it is an estimate of an estimate of an estimate.
The on-line proration method uses a ratio of estimable employment for each month divided by the sum of applicable prior quarter employment to form three imputation ratios, which are applied to the delinquent worksites. The term “applicable” here refers to those worksites that had prior-quarter reported data, but are delinquent in the specific month of the estimated quarter, and are still active for that estimable month. The use of applicable sums allows the months of employment to be treated individually and uniquely, based upon their requirements. For example, the multi-family below has five worksites, each with a different situation.
Three of the worksites terminate through the course of the quarter, one of which (RUN #2) is not active at all in this quarter. The applicable worksites for January estimates are RUN’s 3, 4, and 5 (because RUN #1 is reported in January, while RUN #2 is no longer active). Only RUN 5 is applicable for February (because RUN’s 2 and 4 have become inactive, and RUN’s 1 and 3 are reported for February). Only RUN 3 is applicable for March (since RUN 1 is reported, and RUN’s 2, 4, and 5 have all terminated).
To review the family’s status by worksite, RUN 2 is not applicable for any of the three months, since it is not active. RUN 1 is not applicable either, since it is fully reported. RUN 3 is not applicable in February because it has a reported field there. RUN 4 is not applicable to February or March estimates, as it is inactivated at the end of January. RUN 5 is only applicable for January and February, when it is still active.
So the applicable third-month, prior-quarter sum for January is 23 (RUN #3) + 19 (RUN #4) + 15 (RUN #5) = 57. For February, the value is 15 (RUN #5), and for March, 23 (RUN #3). Next the current-month reported values are subtracted from the master account employment values to obtain the distributable employment figures. For January and March, only RUN #1 is already reported, so their values are Master – RUN1, or 62 (93 – 31) for January, and 38 (82 – 44) for March. In February, RUN’s 1 and 3 have reported, so the distributable employment is 16 (88 – 38 – 34). The ratios of distributable to prior employment then become 62 / 57 (January), 16 / 15 (February), and 38 / 23 (March). This follows the proration “auto-pilot” method of reduced ratios that is described in detail in Appendix D (Estimation Methods) in this manual.
Pressing the PF22/Shift-F10 key enacts the year-ago-based prorations. The general processing algorithm parallels the F10 prorations quite well, except that the initial start-up data are different. Instead of applying the useable portion of prior quarter total wages and prior month employment, the total wage estimates are based upon last year’s total wages, and the employment prorations are based upon last year’s same three months of employment.
In the example shown, there was a tremendous drop for the June employment for worksite 1, and a tremendous rise for RUN 2. This can be seen in the seasonal prorations for second quarter 2017. Even though the quarter-ago employment estimates had very different results, the seasonal nature of these worksites may work better for making the estimates. Because this type of proration is using year-ago data, there need to be four prior quarters available. Therefore, the PF22 prorations can only be applied to the four newest quarters (i.e., the future, current, and two prior quarters). Since older quarters are usually locked anyway, this should almost never present a problem to State analysts. For more details on how these year-ago prorations are applied, please refer to Appendix D (Estimation Methods).
New worksites can be included in the proration environment as well. However, it is not possible to determine an estimate for the initial employment (or wages) of a new worksite. So it is essential that either the true employment or a hand estimate be obtained beforehand, so that the rest of the delinquent family can receive adequate prorations that can keep the family in perfect balance.9
It is not possible to make estimates for the master account using the F10 key’s proration feature. If the entire family (master and worksites) is delinquent, hand estimates for the master must be determined and entered on the ES2C screen (or here in ES2H on the updateable screen). Then the worksites can be estimated, based on the master data. Of course, any worksite distribution based upon non-reported master data cannot be considered true prorations. Therefore, they will be flagged as estimates (with an indicator of “E”) rather than prorations (with an indicator of “P”).
When you come to a stopping point in multi-balance review/correction - lunch time, attending a meeting, or the end of the day - you can save your place in the Micro Edit File with the F4 key. Pressing this key produces a “BOOKMARK HAS BEEN SET” message on the bottom of the screen. Bookmarks are stored in the Lookup File with a “QH” record type (‘Q’ as a general indicator for bookmarks, and ‘H’ to denote the ES2H transaction). If you want to remove the bookmark, press the F4 key again (you will see the message “BOOKMARK HAS BEEN REMOVED”. You must be displaying the bookmarked family at the time you press the key in order for the bookmark to be removed. Otherwise, you will replace the bookmark with whichever family is currently displayed.
Once the bookmark has been set, returning to the ES2H screen will generally restore not only this family to the display (with the message - “BOOKMARKED FAMILY DISPLAYED”), but the program will also transfer directly to the taxable-wage ES2H screen so you can continue to work on the out-of-balance resolution. The bookmark usage will be stymied, however, if you are transferring to ES2H from the ES2C screen or from the menu, and are carrying an account number in tow. The system assumes that such transfers are to take precedence over the default use of bookmarks for the initial ES2H display.
Forced additivity is a new feature that has been added to the full-format screen, the one that includes the taxable wages and contributions, that is reached through the F11 key. Forced additivity means that both the master and worksites show reported data, but they don’t balance exactly. See the screen below for an example. If there is at least one estimated worksite, or there is either a non-reported master or there are non-reported worksites, then there will be no description of the forced additivity in the functions; however, the screen above has the indicated Shift-F8 key for forced additivity to force the employment and wages to match that of the master account, even though the worksites have reported data. The QUEST process has a change for the same alternative has a new indicator of “J” (for Jiggled Reported Data) in all of the changed worksites; however, we at EXPO keep the old reported indicator in place, and only will change the data. The quarterly transactions will indicate when a change is made as well. The processed screen will look like the one below.
Note that the Shift-F8 description has vanished (indicated by the red rectangle on the screen), once the employment and wage data are in balance. This has been stated as one of the most laborious items in hand-estimating the biggest worksites when processing a fully-reported family that is still out-of-balance. By having this process automated, it makes it much smoother and cleaner to adjust the worksites according to the master value. This process can include a large multi-account (over 1000 worksites) in about a second, which is much quicker than the same process in QUEST.
Since this is part of the special screen (with taxable wages and contributions included), it is possible to quickly scan through the edited accounts by setting the year-quarter (if necessary), and then by pressing the F6 key to look at the next out-of-balance account. Of course, this assumes you have already processed the 003D job to get the current out-of-balance list. By checking which of these accounts has the Shift-F8 showing, you can quickly determine which of the accounts needs to have this forced additivity enacted.
Beware of those that have the forced additivity activated, but the balance is clearly off. For instance, if you have over a million dollars in the master but the worksites have only a few hundred thousand, it shouldn’t be forced to a match with the master account, as it will greatly change the worksites. Only a small amount of employment or wages should be off.
Note also, that the estimated worksites may be out of balance with respect to the taxable wages and contributions when this is done. To correct this, use the F10 key to get these other fields in proper balance. It may be necessary, then, to type in two keystrokes to get a family in proper balance; but that is still a sight better than having to manually enter some of the worksites.
9 Note: Batch proration processes are able to counter the initial proration problem by drawing in predecessor/successor data.
Related Links
