Screen Catalog — Reports, Reprint & 1099s

Funding reports (funding), the reprint subsystem (reprint + chkrundw DataWindows), the 1099 screens (provider), and the withholding export.

---

Funding reports (funding)

Window	Title / menu	Purpose and key inputs
w_fund_funding_status	"Funding Status Report"	Accounting report of unpaid claims per bank account: fund page balances plus deposits and payables since a start date (default last 7 days); all-groups variant DataWindows included (d_fund_funding_status, d_fund_funding_status_for_all_grps)
w_fund_negative_balance	Negative Balance report	Fund pages with fund_balance_amt < 0 (excluding funding method P), grouped by bank account with totals (d_fund_negative_balance)
w_fund_delinquent_claims_summary	Delinquent claims summary	Registered, unpaid (unpaid_flg='Y'), non-WDI register entries older than N days rolled up to the master funding group; splits outstanding totals into waiver / hold / total with counts; excludes TESTGROUPS (d_fund_delinquent_claims_summary)
w_fund_delinquent_claims_detail	Delinquent claims detail	Same population per group with claim, subscriber, payable vs paid, register date, waiver/hold flags; days-unpaid parameter (d_fund_delinquent_claims_detail)
w_fund_outstanding_checks	Outstanding checks	Uncleared, unvoided Payment/Manual checks at least N months old, with bank account and group (d_fund_outstanding_checks) — stale-check surveillance
w_fund_fund_page_listing	"Fund Page Listing Report"	Setup completeness listing of fund pages ("report for Kathy to use to know what is set up and what is not") (d_fund_fund_page_listing)
w_fund_group_transaction_history	Group transaction history	All fundtrans for a group/bank account by type and period, joining source/destination fund pages, check numbers, claim ids and incoming check-log numbers; summary variant (d_fund_group_transaction_results, _summary; criteria d_fund_group_transaction_select_criteria, types d_fund_group_transaction_trans_type)
w_fund_check_process_err_rpt	Check process error report	Register entries stuck in register_status_cd RFR/RFC/RFCCOPY after a run, with payee and TIN/SSN (d_fund_check_process_err_rpt)
w_fund_wdi_period_rpt, w_fund_wdi_period_as_modified_rpt	WDI period reports	Weekly disability income period reports, incl. short-SSN print variants (d_fund_wdi_period_rpt*, d_fund_wdi_period_as_modified_rpt)
w_clm_payments_on_waiver	Payments on waiver	Report of payments on waiver (d_rpt_payments_on_waiver)
w_burns_claim_dump, w_burns_enrollment_dump	"Burns Claims Transfer" / "Burns EnrollmentTransfer"	Create Matria claim/enrollment extract files (window comments) — vendor extracts adjacent to funding

Operator context for these reports (User Guide ch. 5):

• Funding Status Report is explicitly a non-binding snapshot: "a snapshot of all benefit payments needing to be paid, whether they have been on a register or not. This report has no 'locking' effect on the register, nor will it mark the claims as the register. This report will have similar sections to the register, but will provide totals only." It is filterable to specific coverage types (for example WDI only), and Authorized-method groups pay from it "so their remittance arrives to meet the register produced".
• Negative Balance report — the code's exclusion of funding method P matches the guide's Pay Anyway method, for which a negative balance is the designed state: "This is used for Zero balance or cash disbursement accounts where SFPI/M3 is not responsible for ensuring sufficient funds exist in the account. These groups have specific arrangements with their banks. The balance will continue to go negative." The guide also asks for exactly this screen: a report that "finds and shows detail on accounts and funds with a negative balance… run on request from the basic reporting menu. We don't need to show zero balance or unreconciled accounts."
• Delinquent claims summary / detail — the guide specifies the weekly 30-day report these implement: "a report showing unpaid benefit payments that have been outstanding for more than 30 days. The report should display held (stoploss waiver or whatever) benefit payments separately from normal unfunded benefit payments… has a summary and detail portion. The reports are sent to accounting, then sales, and give them an idea of how the group is funding or not funding its benefit payments responsibilities. The detail is used to identify what the problem might be." Summary shows group, number of benefit payments and total dollars — matching the waiver / hold / total split in the code.
• Outstanding checks — the business trigger is check voiding for account closure: "Checks that have not been cashed before a specified time limit (3 months, 6 months, or 1 year) will be on a report for Adjudication to cancel. These would need the approval of Claims for the transaction to actually process." For terminated groups, "Accounting generally waits for a period of time after run-out is complete (6 months for example) and voids any outstanding checks to the account so the account can be closed", and a list of the outstanding items is produced for the client's next administrator.
• Group transaction history — the guide's "List Each Day's Receipts For Each Group": "The Transaction History Screen will enable the user to look at all transactions performed against a bank account (based upon date range if desired). All deposits may be checked in this manner." It is an on-screen report runnable at any time. The underlying fundtrans table "acts as a general ledger" for every funding event.

Special Reports named in the guide but absent from this catalog (User Guide ch. 5)

Chapter 5's "Special Reports" section lists reports beyond the funding-report windows above. The guide is candid about the section's status — it "was a rough 'best guess' to begin with", "many of these reports fell under the other sections of HOMER", and it points at a Wang-era menu (RPTMENU) "full of reports that are run" that was never inventoried. Several of the items below are implemented, some elsewhere in the application; several have no client implementation at all. Each entry states what was found in the extracted source.

Report	Guide timing	Client implementation
FMI Report	Weekly	None found
OME-RESA Cash Summary	Monthly	Partial — OME-RESA machinery exists, the summary does not
Aggregate stop-loss	Monthly / year-end	Partial, non-functioning — report DataWindow orphaned, button wired to a missing object
A/R Summary	Monthly	None found (guide itself assigns it to Billing)
Quarterly WDI	Quarterly	Implemented as a date-range report — funding/w_fund_wdi_period_rpt
Reporting calendar	Daily to fiscal-yearly	Partial — a batch_reports registry exists; no cycle definitions

"None found" means "not in the source extract"

HOMER's report catalog is partly database-driven: the report_info table (report_cd, description, report_dw, report_object, report_type_cd, parameter_mask, …) drives the reprint subsystem via reprint/n_cst_reportobject, and batch_reports drives scheduled batch reports. A report can therefore exist as a table row pointing at a DataWindow whose name contains none of the words searched for. _re/analysis holds schema only, with no table data, so the negative findings below cannot be absolute. n_cst_reportobject explicitly contemplates per-group custom reports — OME-RESA's own subrogation form is the in-code example — which is precisely how a customer-specific FMI or Cash Summary would have been wired. Confirm against a live database with SELECT report_cd, description, report_dw FROM report_info and SELECT report_cd, report_name, report_dw FROM batch_reports before concluding a report was never built.

FMI Report — no client implementation found

• Purpose and timing (User Guide ch. 5): a weekly report for a single client, "FOSECO - 501-128 gets a FMI Report on a weekly basis that shows by division how much is spent on benefit payments premiums". The guide immediately doubts its own note — "did I write this down wrong - should it be how much is spent paying benefit payments from Claims Reserve?" — and defers the format entirely: "Need to talk to Carol for format and problems". The acronym is never expanded anywhere in the guide.
• Client check: no match for FMI as an object name, window title, menu label or comment anywhere in _re/src, and nothing in _re/analysis/inventory.json. No client implementation. Given the report is defined only by a single group id, an unexpanded acronym and an unresolved question about what it measures, it should be treated as undocumented until the surviving FOSECO output is produced for an SME.

OME-RESA Cash Summary Report — partially implemented

• Purpose and timing (User Guide ch. 5): monthly, and it is not an ordinary report — "OME RESA gets a Cash Summary Report on a monthly basis that shows how the Claims Reserve was spent by group. This is in place of the regular register run." OME-RESA is an informational grouping that ties many master groups together rather than a true master group, which is why the report is by-group across the whole hierarchy.

• Known defects, carried in the guide (User Guide ch. 5): the report "needs a lot more attention and currently has enough problems that the report output is manually adjusted and totals recomputed". The listed problems are stop-loss payments that are paid by the group, reimbursed by the carrier and then refunded by the provider (the money returns to the carrier, "but the report does not show this well"); void and reissue of checks; refunds processed in the same month as the payment; PCS benefit payment processing; and NY surcharge reporting, which "is done manually. Maybe this logic is just not in the current Cash Summary Report." A separate reconciliation burden sits alongside it — PCS benefit payments for OME-RESA are entered by Enrollment so the amounts are available for reporting, and the totals OME-RESA reports must be reconciled by hand against them, which "generates large problems".

• Client check: partial. No object is named or titled "Cash Summary", but an OME-RESA-specific family does exist in the funding library, all of it keyed off the hierarchy START WITH group_id = 'OME-RESA':

  • funding/w_fund_omeresa_monthly_claims_data — "OMERESA Monthly Claims Data" (d_fund_omeresa_monthly_claims_data): a start/end-date claim-level extract of paid fund_register rows across the OME-RESA hierarchy, with group, paid date, check number, patient and subscriber, payee vendor, claim type and paid amount. This is the claim detail a cash summary would be built from, not the by-group summary itself.
  • funding/w_bill_ome_b_and_r — "Ome-Resa Billing and Remittance Process", with current-month and prior-month member/coverage census DataWindows (d_bill_ome_b_and_r_current_month, _prior_month).
  • funding/w_bill_ome_wire_transfer and w_bill_ome_wire_transfer_adj — "OME-RESA Wire Transfer" plus its adjustments, over an ome_resa_wire_xfer_adj table, with Aetna-only and non-Aetna variants (d_bill_ome_wire_transfer*).

  So the monthly OME-RESA cycle is partly automated, but the Claims-Reserve-spent-by-group summary that replaces the register run is not among the extracted objects. Because the guide records that the output is manually adjusted anyway, the surviving process is likely part screen, part spreadsheet — confirm with the SME what Kathy Koch's monthly procedure actually runs.

Aggregate stop-loss reporting — partially implemented, in stoploss not funding

• Purpose (User Guide ch. 5): the report "lists # of lives (EE and Dependent) and multiplies this by a factor to calculate an estimated attachment point for the month and the year", then shows benefit payment totals MTD or YTD alongside "aggregate benefit payments (which are total benefit payments less specific stoploss benefit payments)". The guide wants "the end of the year reports to be done on a Net or Accrual Basis and the monthly reports to be done on a Gross or Cash Basis" — the split already captured as FND-64.

• Unresolved basis question (User Guide ch. 5): the guide never settles whether to "Calculate the aggregate benefit payments amount on a monthly basis for that month and keeping that total for the month static" or to "Re-calculate the aggregate benefit payment amount for each month on a monthly basis (adjusting for any fluctuation due to benefit payments changes)", noting only "We need to make clear which of these methods we are using" and that "the year-end report should be accurate for the entire year". Elsewhere it commits to the static reading for adjustments: a payment made in one month and refunded in another leaves the first month unchanged and books the net change in the month of the adjustment.

• Carrier-specific outputs (User Guide ch. 5): "There are currently 5 different reports, 1 for each stoploss carrier… 3 show stoploss on a Year-to-date basis and 2 on a Month-to-date basis." The guide's instruction is deliberately to not reproduce them: "Instead of creating carrier specific reporting of aggregates, create something that is more generic for now and accounting will create the carrier specific forms/reports from this data." Monthly Aggregation — determining monthly whether the carrier owes the group or the reverse — is explicitly out of scope but should be supportable: "we don't currently know its format and it is a low priority".

• Client check: partial and broken, and it lives in the stoploss library, not funding. Three separate objects are involved and they do not connect:

  • stoploss/d_sl_agg_summary — a genuine aggregate report DataWindow, bannered "Aggregate Stoploss Summary". It selects one row per group and stop-loss period from group_stoploss_parms joined to paid fund_register rows for the group's stop-loss coverages, reporting total paid and LEAST(SUM(PAID_AMT) / AGGR_MIN_ATTCHMENT_PT, 100) as a percent-met. It measures against AGGR_MIN_ATTCHMENT_PT — the minimum attachment point — so even at its best it does not compute the lives-times-factor monthly attachment point, does not subtract specific stop-loss to yield net aggregate claims, and produces no monthly MTD/YTD series. It is orphaned: no window, menu or NVO in the extract assigns it as a DataObject.
  • stoploss/w_sl_summary (StopLoss Summary Report, catalogued under Stop-loss screens) offers Specific and Aggregate radio buttons and a "Run Aggregate" button. Its aggregate path (ue_agg, cb_ag.clicked) — and the equivalent in stoploss/w_sl_specific_summary — sets the report DataObject to d_sl_spec_2, a DataWindow that does not exist anywhere in the extract. The aggregate branch is a verbatim copy of the specific branch.

  So the aggregate report is written but unreachable, and the reachable aggregate button is wired to a missing object. Here the code and the guide agree: chapter 13 says of this screen's aggregate option "This option does not currently work", and the extracted source shows exactly why. Treat aggregate stop-loss reporting as not functioning in the client; whatever accounting produces for the five carriers today is being produced some other way.

• A fuller specification exists in chapter 13, unimplemented here: a Monthly Aggregate Excess Report taking master group and stop-loss period, sorted by month/year and contract coverage, with single and family counts times the aggregate deductible factors giving a Monthly Accumulation Point, running Accumulated Accumulation Point and Accrued Minimum Aggregate Deductible columns, monthly and year-to-date net paid claims, and totals for Claims Excess Specific Amount and Net Aggregate Claims. That is the calculation chapter 5 asks for. No window or DataWindow matching it was found in the extract — worth raising with the SME as the intended target shape if aggregate reporting is in migration scope.

A/R Summary — no client implementation found

• Purpose and timing (User Guide ch. 5): "A/R Summary (we have a sample) – this is a spreadsheet prepared monthly that is different for M/III and SFPI. This will be under BILLING, most likely" — the guide itself does not place this report in Funding.
• Structure (User Guide ch. 5): grouped by office (Cleveland, Chicago, Pittsburgh), then "report all groups, summarize them, then re-report groups that were not billed in advance (since most groups bill in advance, these are the exceptions). These are summarized and show the net of those exceptions (this represents the Net A/R for the month)." The M/III variant is simpler, showing only the Medillume III benefit payment fees. The SFPI variant shows "the Gross Billed Amount, the Self Adjustments Taken, Net Bill and then breaks down that bill into its A/R components", separating COBRA and Flex — the COBRA line carrying only separately collected benefit payment fees, with all other COBRA money reported with the rest of the group, and Flex "listed totally separately".
• Why it must be a spreadsheet (User Guide ch. 5): "This needs to be provided as a spreadsheet – the reason is – we may not have billed some groups yet and Rolf will need to create estimates for these." The deliverable is an editable working document, not a fixed report — a requirement any replacement should honour rather than design away.
• Client check: no A/R summary or accounts-receivable summary object was found in funding, reprint, chkrundw or elsewhere in _re/src, and none in _re/analysis/inventory.json. No client implementation. A related but distinct monthly need is recorded in the same section — "a report tracking A/R activity for a group over a month. What we billed, who we paid" — also not found. See the Billing screen catalog for what billing reporting does exist.

Quarterly WDI report — implemented as a date-range report

• Purpose and status (User Guide ch. 5): this is the one item in the section the guide signs off on — "The quarterly report for WDI that is produced now is fine as it is." Its specification: "By Group, By Division, By employee – shows each benefit payment (and all its component amounts). Subtotals at each sort/break. Reprinted checks should be flagged and should not affect totals. Done on a Cash Basis". A second quarterly WDI need is listed separately under quarterly processing — "A report that shows the way WDI benefit payments are paid over the quarter - how much went to the subscriber, how much held and sent for each type of tax and withholding."
• Client check: implemented, as the already-catalogued funding/w_fund_wdi_period_rpt ("WDI Period Report") and its sibling w_fund_wdi_period_as_modified_rpt. The match to the guide's specification is close: d_fund_wdi_period_rpt selects fund_register rows with wdi_ind = 'Y' and worksheet_ind not 'Y', filtered by applied_dt between a start and end date, and groups four levels deep — parent (master) group, then group (division), then subscriber SSN, then claim — with a trailer band at every level, which is the guide's "subtotals at each sort/break". Inputs are a group (or an all-groups checkbox), the date range, and a full-SSN versus short-SSN print choice (d_fund_wdi_period_rpt_short_ssn, _print, _print_short_ssn).
• The gap is scheduling, not content. Nothing in the window makes the report quarterly: the operator types whatever date range they want. There is no quarter picker, no fiscal quarter concept, and no record that a given quarter has been reported. The report also carries original_paid_dt alongside paid_dt, which is how reissued payments can be told apart, but no explicit reprint flag or reprint-excluding total was found — so the guide's "Reprinted checks should be flagged and should not affect totals" is not evidently satisfied and needs SME confirmation against a produced quarterly report.

The reporting calendar — no client implementation found

• What the guide specifies (User Guide ch. 5): chapter 5 does not only list reports, it organises them into recurring production cycles, each its own numbered process — Produce Daily Reports ("daily meaning whenever there is a register produced"), Produce Weekly Reports (examples: the FMI Report, and the over-30-days unpaid benefit payments report), Produce Monthly Reports (examples: the OME-RESA Cash Summary, NY Pool/Surcharge reporting, the NY capitated per-member amount, the NY provider-type benefit payment report, and the monthly A/R activity report), Produce Quarterly Reports on standard calendar quarters (the WDI quarterly reports and some NY Pool/Surcharge reporting), Produce Fiscal Quarterly Reports, Produce Yearly Reports, and Produce Fiscal Yearly Reports. The distinction between calendar and fiscal cycles is drawn deliberately and twice.
• Client check: partial — the registry exists, the calendar does not. No object named or commented as a reporting calendar was found, and no daily/weekly/monthly/quarterly or fiscal-period reporting concept appears in funding, reprint, chkrundw or _re/analysis/inventory.json. Every funding report catalogued on this page is an on-demand window driven by operator-entered dates. What does exist is the infrastructure such a calendar would sit on:
  • homersys/w_batch_reports (+ d_batch_reports), menu "Batch Report Maintenance" — a maintenance grid over a batch_reports table whose columns include report_cd, report_name, report_dw, report_parameter_window, report_type, allow_run_events and allow_times. The last two are when-to-run metadata, which makes this the nearest thing in HOMER to a reporting calendar — but it is a per-report permission registry, not a definition of the seven production cycles.
  • system/n_batch_scheduler ("This nvo schedules when a process should run") over BATCH_SCHEDULES, which gates the batch process windows (Funding, Check Register, Check Run), not reports.
  • funding/w_fund_tab_schedule and w_fund_schedule_component (with d_fund_schedule, _runs, _run_components, _missing) schedule register and check runs per group and fund page. These are the register schedules described elsewhere in chapter 5 and should not be mistaken for report scheduling.
• Migration implication: the recurring-cycle structure is a real operational requirement that exists today only as staff habit plus the register schedule. If the replacement is expected to produce these cycles, the calendar has to be built, not converted — and the list of which report belongs to which cycle needs SME confirmation, since chapter 5 offers its cycle contents as "Examples" rather than a complete enumeration.

New requirements from this section

Continuing the FND- sequence maintained in the Funding module overview, which ends at FND-64. These are additions, not renumberings.

• FND-65 — Funding and accounting reports must be producible on defined recurring cycles — daily (per register run), weekly, monthly, calendar-quarterly, fiscal-quarterly, yearly and fiscal-yearly — with the cycle's report set defined as configuration rather than staff habit, and with fiscal periods distinct from calendar periods. (User Guide ch. 5) The extracted client has a per-report batch registry (batch_reports, with allow_run_events and allow_times) but no cycle definitions; every funding report is an on-demand, operator-dated window.
• FND-66 — For an informational grouping that reports in place of the register (OME-RESA is the documented case), the system must produce a monthly by-group summary of how the Claims Reserve was spent, substituting for the regular register run, and must handle the cases the current process cannot: carrier-reimbursed stop-loss payments later refunded by the provider, voided and reissued checks, refunds processed in the month of payment, PCS benefit payments, and NY surcharge amounts. (User Guide ch. 5) Today the output is manually adjusted and its totals recomputed by hand.

Reprint subsystem (reprint, rendering via chkrundw)

Reprint Maintenance — reprint/w_reprint_maintenance

• Title: "Reprint Maintenance". Menu m_reprint_maintenance. Comment: "menu for the check/form letter/register reprint maintenace".

• Purpose: Search report_hist and reprint checks, EOBs, RAs, registers, manual checks and claim letters from their archived blobs.

• Search fields: report type (d_reprint_maintenance_report_types + dddw_rpt_type, % wildcards allowed), group (with child groups), run date range, check/worksheet number (W prefix = worksheet), recipient id; "Printed and Unprinted Material?" (default unprinted only), "To be mailed" vs internal payees (internal_payees), "Print Logo", "Accounting copy" and "Master Summary Only" (REGISTER only), "Register Summary on New Page", spool-to-printer vs PDF-format modes, QMCSO mode.

• Rendering by type:

  • MANUAL → d_fund_manual_check_print (signature block re-applied from bank_forms).
  • EOBCHK/EOBWRK/EOBEECOPY/EOBERCOPY → composite d_checkrun_eob (header d_checkrun_eob_hdr_*, detail by claim-type prefix of the description: d_checkrun_eob_wdi, _medreim, _depcare, _dedsupp, else _mdv; legend child).
  • RACHK/RAWRK/RACOPY → d_checkrun_ra (+ _dedsupp/_mdv detail, _hdr_copy header for copies).
  • REGISTER → address page (d_register_address_page/_landscape), master summary (d_register_summary_comp), per-group d_register_data_comp sections (activity/summary/paid/previously-reported/newly-reported); group count carried in report_hist.check_number.
  • EOBCKWKST/EOBINFO/RACKWKST/RAINFO/CHKREGISTR → legacy formats refused with "contact IS".
  • CLMLETTERS → renders whatever DataWindow report_hist.dw_object names.

• Post-print: prt_flg = 'Y' per item; archived (purged) blobs recovered from CD/file A<report_sys_key>.txt after prompting.

• Why reprint is pure replay (User Guide ch. 5): "Do not confuse producing the register initially and reprinting the register. There will be no computing done in reprinting a register. It will be a simple reproduction of the register that had been produced before." The archive requirement is stated in the same terms the code implements: "The registers, EOBs, and RAs need to be archived in a non-editable format such as saving the print image as a binary large object (BLOB). The archived material may be searched by register date (the run date, which also serves as the check date), check number, or worksheet number. From this material, a print may be requested." Note the guide's identity register run date = check date, which is what the search-by-run-date criteria mean.

• What each rendered type is (User Guide ch. 5): "An EOB will always be produced and sent to the subscriber. A RA will always go to the vendor." Copies exist because "the group may request copies of the check, the EOB and/or the RA", and a legal guardian (for example on a child-support payment) also receives an EOB — the business reason behind the EOBEECOPY / EOBERCOPY / RACOPY variants. A check "will be printed at the top of an EOB or a RA, depending on to whom the check will go", and "for the purposes of the funding section, an EOB or a RA without a check is a worksheet".

• Register structure (User Guide ch. 5): the register is grouped by fund pages sharing a register sort order, "with the final goal of producing a single 'pay this' amount for which the group needs to fund"; that total excludes worksheets, waivered and held amounts. Its sections are defined by state, not by choice:

  • Newly Reported — first appearance; the run date is stamped into the row's register date, and the payment must be completely unfunded.
  • Previously Reported — still completely unfunded, register date earlier than this run; moved to the end of the section so "the most recent benefit payments are last".
  • Benefit Payments Paid — paid amount equals payable amount.

  The register also flags stop-loss exceeders: "Any unwaivered stoploss benefit payment that exceeds the stoploss deductible will be noted but otherwise shown on the check registers as usual." Prefunding groups pay such a payment "without actually being given the opportunity to ask for a waiver", whereas Authorizing groups see it on a register first and can request a waiver before paying.

• Worksheet numbers (User Guide ch. 5): a worksheet number "is the identifier assigned to adjudicated benefit payments that have no check (and therefore no amount) to be paid by SFPI" — a separate number sequence from check numbers, assigned in the same pass. Worksheets appear only in the Paid section and never count toward the "Pay this amount" total. The categories are: nothing to pay at all; an amount the group pays directly rather than from SFPI-managed Claims Reserve; funding requests where the funding check is issued separately (PCS is the example); the client is also the payee; and a terminated group that still has benefit payments, "shown on the register as worksheets so that the group knows about the benefit payments". This last case is why the W prefix in the check/worksheet number search matters when researching terminated clients.

• Check numbering (User Guide ch. 5): "Check numbers will be assigned by sorting first on the group ID, then on the fund page, and lastly on the payee. All those for the same payee from the same fund page from the same group will be on one check."

Other reprint windows

Window	Purpose
reprint/w_reprint	Print queue manager over report_hist filtered by report-type list (d_reprint)
reprint/w_reprint_check_recon	Per run-date summary from report_hist: first/last check number, counts of checks, worksheets and forms per group and report type (d_reprint_check_recon) — the daily check-run reconciliation sheet. Distinct from bank reconciliation, which the guide describes as a separate monthly process with its own screens (clear checks against the statement, add deposits in transit, record interest and fees, roll up sub-fund balances) (User Guide ch. 5)
reprint/w_reprint_claim_letters	"Print Claim Letters": prints queued claim letters with mailing page and letters register (d_claims_frm_mailing_page, d_claims_frm_register over claim_letters_hist; claim-lock parameter)
reprint/w_reprint_claim_reprice_letters	Letters requesting repricing sheets (d_reprint_claim_reprice_letters)
reprint/w_claim_letters_setup	Configure claim letters (d_claim_letters_setup)
reprint/w_group_print_distribution	"Set up print and check options for groups": per-group print distribution options (group_print_distribution table, option codes GRPPRNDIST), with a custom-vs-default indicator per group (d_check_and_letter_setup, d_group_print_distribution)
reprint/w_reprint_letter_display	"Letter Display" viewer (response)
reprint/w_parameterwindow	Generic parameter prompt used by reprint/n_cst_reportobject

chkrundw DataWindow inventory (check-run outputs)

• Check + EOB composites: d_checkrun_eob, d_checkrun_eob_ee_copy, d_checkrun_eob_er_copy; headers d_checkrun_eob_hdr_generic / _ee_copy / _er_copy — the generic header prints the payee, amount in words (f_fund_money_to_word), boxed amount, check/worksheet number, and the MICR line (o<check>o t<routing>t <account>o in the Micr font), all suppressed when the number starts with W (worksheet).
• EOB detail variants: d_checkrun_eob_mdv (medical/dental/vision), _wdi, _medreim, _depcare, _dedsupp; legend d_checkrun_eob_legend_generic; supporting d_checkrun_claim_lines, d_checkrun_claim_pricing, d_checkrun_pricing_reasons (also used by clmprint/n_check_copy to regenerate EOB copies with accumulator and deductible legends).
• Remittance advice: d_checkrun_ra, d_checkrun_ra_mdv, d_checkrun_ra_dedsupp, d_checkrun_ra_hdr_generic, d_checkrun_ra_legend_generic.
• Register: d_register_payments (selection: fund_register where register_status_cd = 'RFR'; grouped fund page → group → payee; computed section headings PAID / NEWLY REPORTED / PREVIOUSLY REPORTED), d_register_activity, d_register_summary, d_register_summary_detail, d_register_summary_register, d_register_data_comp, d_register_summary_comp, d_register_address_page (+ landscape).

1099 screens (provider)

Print 1099 Forms — provider/w_1099_print

• Title: "Print 1099 Forms". Menu m_1099_print.
• Purpose: Filter, print and reprint vendor 1099 forms from print_1099s.
• Filter fields (d_1099_filter): group id, tax year, vendor TIN (9 digits), original-print date range, last-print date range, unprinted-only flag (defaults N = unprinted).
• Grid (d_1099_print_select): tax year, group (payer) with TIN/address/phone, vendor (payee) with TIN/TIN type/address, box 6 and box 7 amounts, printed flag, print dates, reason for reprint (shown in a side panel when a single printed row is selected).
• Actions: multi-select print; any selected already-printed form forces a reason prompt (provider/w_1099_reason, cancel aborts); group 501-069Z prints d_1099nec_form, others d_1099_form with overlay image 1099text.wmf; successful prints stamp printed_ind/orig_print_dt/last_print_dt (reason stored on reprints); failed prints counted and left unmarked; single update/commit at end.
• Opens: provider/w_1099_reason (reason capture, response window).

Business purpose (User Guide ch. 22): "Each year SFPI/M3 issues 1099 forms on behalf of our clients. These 1099 forms are sent to each provider who received payment from our clients, and whose earnings fell within IRS guidelines for 1099's." This is why the grid carries both a payer (the client group, with its own TIN and address) and a payee (the vendor) — SFPI is the filing agent, the client is the payer of record. Chapter 5 adds the funding-side trigger: "If taxes are paid, 1099's will be generated based on the benefit payment's payee."

The TIN-mismatch (CP2100 / B-notice) follow-up is a separate process and is not one of these screens. Since tax year 1994 the IRS has required SFPI/M3 "to resolve TIN and name discrepancies, between 1099's that were issued and the government's internal TIN and name records for the providers receiving 1099's"; each affected provider "is sent, and must return, to SFPI/M3, a federal form CP2100", governed by IRS Publication 1281, "Backup Withholding on Missing and Incorrect Name/TINs". The documented procedure — enter received CP2100 notices, match the provider TIN against that employer's 1099 file in dash-less / TIN / SSN formats, decide first versus second offence, generate primary and follow-up B notices (follow-up defaulting to 10 calendar days), track returns, and print the log reports — runs against a bnotice table (provider TIN, tax year, name, address, notice date, primary date, follow-up required/date, returned date, notes) plus FoxPro tables and a WANG "krisfile", and includes setting a stop-pay switch on the WANG when a return is received (User Guide ch. 22). None of that is implemented in the provider 1099 screens catalogued here; it is legacy/external tooling. Whether a HOMER-era replacement exists, and what became of bnotice, needs SME confirmation before migration.

Vendor 1099 flag

Vendor maintenance (provider/w_provider_vendor_maintenance, provider/d_provider_vendor) exposes "Produce 1099?" (vendors.irs_1099_flg) plus TIN and TIN type; vendor consolidation (provider/w_provider_consolidate_vendors, also in base) copies the flag to the surviving vendor.

Withholding Reports — funding/w_withholding_reports

• Title: "Withholding Reports" (menu label "Surcharge Withholding" in homersys/m_sys_frame).
• Purpose: Produce per-state surcharge-withholding claim and census extracts.
• Field groups: search start/end dates (default: prior calendar month), multi-select state list (dddw_states) with an "NY and MA" shortcut; base-data grid d_withholding_reports_base_data (MEDICAL register entries paid in range whose service- or facility-provider address is in a selected state); per-state claims/census report status grids (d_withholding_reports_printed).
• Actions: "Print/Save Claims Report" — builds per-state fixed-width file (claim id, input date, paid date, group, claimed amount, claim type, city/state/zip) via d_withholding_reports_claims per claim/paid-date, saved under the path from code table APPPATHS/WITHHOLD named <STATE>_<Mon><YYYY>, then prints; "Print/Save Census Report" — per-state census (d_withholding_reports_census: group, SSN, names, election level, birth, city, zip) named Census<STATE>_<Mon><YYYY>.
• Rules: overwrite prompts on existing files; closing with any state report not printed/saved warns per report (closequery).
• Why only NY and MA (User Guide ch. 5): "Currently, SFPI only does Surcharges for the states of New York and Massachusetts" — which is what the screen's "NY and MA" shortcut encodes. Two surcharge shapes exist: "Flat percentage per claim regardless of where in the state that the service was performed" and a percentage that "varies depending upon where in the state the service was performed". New York clients may instead elect a capitated amount paid monthly to the state, "only … for members that live in NY".
• The New York formula (User Guide ch. 5), stated as mandated by the state: identify claims whose services were performed in NY and that have not yet had the surcharge applied; total the payable amounts (including withhold) and round up to the nearest dollar; apply an 8.18% surcharge to that rounded total and round up again. "Because the preceding formula is mandated from NY, we cannot calculate the surcharges claim by claim and pass each through as an individual payment." The guide notes the rate was not date-ranged at the time of writing.
• Selection basis and manual steps (User Guide ch. 5): "The surcharge process will select payments for surcharge calculations based upon the date that the check was issued for the payment. (Note that funded payments for New York providers that have not yet had their checks issued will not show up as part of the surcharge process.)" Surcharge processing "will be distinct and occur separately from the normal funding processes such as the register and the check run"; New York also requires payments broken out by the year services were incurred, back to 1997. Everything downstream of this extract is manual: "Accounting will manually fill out all of the forms required to accompany the payments", and "Booking all surcharge related dollars into the system will be manual" — money moved between fund pages and manual checks cut, cleared in the normal bank reconciliation.
• Known gap the guide flags (User Guide ch. 5): surcharge amounts are not spread back to the originating claims, "required because the surcharge amounts should be included when figuring stoploss deductibles and attachment points. We are currently not doing this." A migration that reproduces the extract as-is inherits this gap.