Funding, Check Runs & 1099s

Libraries: funding (largest library in the system), chkrundw (check-run/register DataWindows), reprint (check/EOB/register reprint), plus the 1099 print screens that live in provider (provider/w_1099_print). Requirement prefix: FND.

Purpose

This domain moves the plan's money. HOMER is used by a TPA administering self-funded health benefit plans; adjudicated claims do not become checks until the client group's money is available. This domain covers:

• Funding setup — bank accounts, fund pages (sub-ledgers of a bank account), the group funding hierarchy, and funding schedules (funding/w_fund_acct_hierarchy, funding/w_fund_page_maint, funding/w_fund_tab_schedule).
• Deposits and funding of claims — receiving client money (logged incoming checks, wires, adjustments), depositing it into fund pages, and applying it against payable claim register entries (funding/w_fund_deposit, funding/w_fund_check_maintenance).
• Check runs and the check register — payable rows in fund_register selected at status RFR are printed as checks/EOBs/remittance advices and reported on a check register mailed to the group (chkrundw/d_register_payments, chkrundw/d_checkrun_eob*, reprint/w_reprint_maintenance).
• Manual checks, drug-card vendor checks, transfers, splits (funding/w_fund_manual_check, funding/w_fund_drug_card_payment, funding/w_fund_transfer, funding/w_fund_split_payments).
• Void / stop / stale / reissue of checks and claim adjustments/refunds (funding/w_fund_reissue_check, funding/w_fund_check_detail, funding/w_fund_adjust_claim, funding/w_fund_receive_refund).
• Bank reconciliation — manual reconciliation, imported bank clearing files, and reports (funding/w_fund_reconcile, funding/w_fund_bank_reconciliation_file, funding/w_fund_reconcile_report, funding/w_fund_outstanding_checks).
• Bank interfaces — positive-pay export files and per-bank cleared-check files (funding/w_pospay, funding/w_fund_bank_reconciliation_file); OME-RESA wire-transfer remittance (funding/w_bill_ome_wire_transfer).
• Annual 1099 printing for vendors (provider/w_1099_print, provider/d_1099_form, provider/d_1099nec_form) and state surcharge-withholding reports (funding/w_withholding_reports).
• Reprint queue — every check, EOB, RA, register and manual check is archived as a data blob in report_hist and can be re-rendered and reprinted (reprint/w_reprint_maintenance, reprint/w_reprint).

Core concepts (as evidenced in code)

Term	Meaning	Evidence
Fund page	Sub-account of a bank account holding a balance (fund_pages.fund_balance_amt), with a funding method (FUNDMTHD code) and covered benefit types (fund_page_covrs)	funding/d_fund_page_edit, funding/d_fund_fundpage_coverages
Fund register entry	One payable/payment row per payee per claim (fund_register), carrying payable_amt, paid_amt, waiver/hold flags, worksheet indicator, and lifecycle dates	chkrundw/d_register_payments, schema fund_register
Fund transaction	Double-entry style movement log (fundtrans): deposits into fund pages, payments from fund pages to register entries, transfers, adjustments, manual checks	funding/w_fund_deposit pfc_preupdate
Worksheet	A non-negotiable "check" (number begins with W, fund_register.worksheet_ind = 'Y'); prints without the negotiable check portion and is excluded from check totals	chkrundw/d_checkrun_eob_hdr_generic visible expressions, reprint/w_reprint_maintenance
Register statuses	fund_register.register_status_cd: RFR (selected for the register run), RFC, RFCCOPY; NULL = at rest	chkrundw/d_register_payments (register_status_cd = 'RFR'), funding/d_fund_check_process_err_rpt
Claim funding statuses	claims.claim_status_cd: RFF (ready for funding), PAID, RFCAHOLD (held after adjustment/void)	funding/w_fund_deposit, funding/w_fund_reissue_check, funding/w_fund_adjust_claim
Report history	report_hist stores the rendered data of every check/EOB/RA/register/manual check as a blob, keyed by type (EOBCHK, RACHK, REGISTER, MANUAL, ...)	reprint/w_reprint_maintenance, funding/w_fund_manual_check

Actors

Grounded in code; role names are inferred from department checks and window comments:

• Accounting / funding staff — the only users allowed to edit in Deposit and Fund: users outside the MIS or ACCOUNTING department groups get a read-only screen (funding/w_fund_deposit pfc_postopen). Window comments name accounting users ("This is Accountings report...", funding/d_fund_funding_status).
• MIS department — same edit rights in Deposit and Fund; error messages direct users to "inform the MIS Dept." on claim-lock failures (funding/w_fund_deposit).
• Funding setup administrator — maintains hierarchy, bank accounts, fund pages, schedules ("This is a report for Kathy to use to know what is set up and what is not", funding/w_fund_fund_page_listing).
• Print/mailroom operator — reprints checks, EOBs, registers, letters from the reprint queue (reprint/w_reprint_maintenance, reprint/w_reprint).
• Client group — receives the check register (mailed to the group's "Registers" contact) which reports paid, previously-reported and newly-reported claims (reprint/w_reprint_maintenance REGISTER case, chkrundw/d_register_payments section headings).
• Banks — receive positive-pay files; supply cleared-check files (Bank One, Huntington, National City, Citizens) (funding/w_pospay, funding/w_fund_bank_reconciliation_file).
• Vendors / members — check payees (fund_register.payee_cd in VENDOR / MEMBER); vendors flagged irs_1099_flg receive 1099s (provider/d_provider_vendor).

Key workflows

1. Claim payment funding cycle (end-to-end)

Adjudication (outside this domain) creates fund_register rows and puts the claim in status RFF. The funding domain then moves it to a printed, cleared check.

The batch engine that assigns check numbers, sets fund_register.paid_dt, and writes the report_hist blobs is not present in the extracted client source — the client-side evidence is the RFR selection SQL of chkrundw/d_register_payments, the leftover-status error report funding/w_fund_check_process_err_rpt (statuses RFR, RFC, RFCCOPY), the bank_acct_info.last_check_no / last_worksheet_no counters (funding/d_fund_bank_acct_info_maint), and the reprint logic that re-renders its outputs. See Open questions.

2. Deposit and Fund (funding/w_fund_deposit)

• Deposit types come from code table FUNDSOURCE (funding/d_fund_reconcile_deposit joins codes.code_key = 'FUNDSOURCE'); type CHECK requires picking a logged incoming check (funding/w_fund_deposit wf_check_data, funding/d_fund_check_select).
• Funding a claim writes two fundtrans rows: deposit-source → fund page, and fund page → register entry ("Note, this is two records..." comment in funding/w_fund_deposit pfc_preupdate).

3. Check run outputs, register and reprint

• Register selection: fund_register rows with register_status_cd = 'RFR' grouped by fund page / group / payee; section headings computed as "THE FOLLOWING CLAIMS WERE PAID / ARE NEWLY REPORTED / WERE PREVIOUSLY REPORTED" (chkrundw/d_register_payments).
• Check face: MICR line composed of check number + routing transit code + bank account number rendered in the Micr font; amount printed in words via f_fund_money_to_word; worksheet numbers (leading W) suppress the negotiable portion (chkrundw/d_checkrun_eob_hdr_generic).
• Every output is stored in report_hist (type EOBCHK, EOBWRK, EOBEECOPY, EOBERCOPY, RACHK, RAWRK, RACOPY, REGISTER, MANUAL, CLMLETTERS) as a multi-section blob delimited by SEPSEPSEPSEP markers, and can be re-rendered and reprinted; printing sets prt_flg = 'Y' (reprint/w_reprint_maintenance).
• At print time, signature text, font, size and x/y position are pulled from bank_forms via the account's bank_form_sys_key and applied to the check header (reprint/w_reprint_maintenance pfc_print).
• The register package is: address page for the group's "Registers" contact (d_system_group_contact_min_cat), master summary (chkrundw/d_register_summary_comp), then per-group activity/summary/paid/previously-reported/newly-reported sections (chkrundw/d_register_data_comp); the count of groups in the blob is stored in report_hist.check_number for REGISTER rows (reprint/w_reprint_maintenance).

4. Check void / stop / stale / reissue (funding/w_fund_reissue_check)

WDI (weekly disability income) claims additionally reverse the related tax register rows and transfer withheld tax back from the claim's WDI tax fund page (funding/w_fund_reissue_check pfc_preupdate).

5. 1099 annual cycle

The job that accumulates payments into print_1099s is not in the extracted client source (the only reader/writer found is provider/d_1099_print_select / provider/w_1099_print) — see Open questions.

6. Bank reconciliation and interfaces

• Manual reconciliation (funding/w_fund_reconcile): user enters statement ending balance, ticks cleared checks (uncleared, unvoided fundtrans rows with a check number — funding/d_fund_reconcile_check) and cleared deposits (funding/d_fund_reconcile_deposit); Save is enabled only when the computed difference is exactly zero, then check_cleared_date / deposit_date are stamped and bank_acct_info.last_reconciliation_dt/balance updated.
• Bank clearing files (funding/w_fund_bank_reconciliation_file): fixed-position files from Bank One (hard-coded groups 501-404/500-005), Huntington (multi-group; only transaction code 05 processed; account number mapped to group via bank_acct_info), National City (hard-coded group 501-541). A check clears only when the file amount equals the HOMER amount to the cent; mismatches are listed as discrepancies, unknown checks counted.
• Positive pay (funding/w_pospay): three exports (JHP and 125 to \\sfpiserver1\acctg\huntington_outgoing_checks, 750 to citizens_outgoing_checks) of unsent issued and voided checks; issue type IS/CN (or I/V for Citizens); rows are marked sent (issued_notify/void_notify + filename) only after the CSV file save succeeds. The unsent-check selection for the JHP file is hard-filtered to group OME-RESA and transactions after 2019-03-01 (funding/d_pospay_unsent).
• OME-RESA wire transfer (funding/w_bill_ome_wire_transfer, funding/d_bill_ome_wire_transfer): summarizes funded benefit payments (BENPMT/PREPAID with a check number) by claim type across the OME-RESA group tree into a wire-transfer remittance to a hard-coded Huntington National Bank account.

Business rules

Each statement is testable and cited. "Register entry" = row of fund_register; "transaction" = row of fundtrans.

Funding eligibility and locking

• FND-1 — A claim payment is eligible for funding only when the claim status is RFF and its register entry has worksheet_ind = 'N', backout_ind = 'N', paid_dt null and register_status_cd null, for a group under the selected bank account's group tree. (funding/w_fund_deposit pfc_retrieve; funding/d_fund_fund_claims)
• FND-2 — Opening Deposit and Fund locks all eligible claims for the bank account by stamping claims.lock_seq_no with a session-unique sequence value; only rows carrying the session's lock may be modified, and locks are released on close/re-retrieve. If some claims are already locked by other users, the user is shown the list (funding/d_fund_deposit_locked_claims) and may continue without them or exit. (funding/w_fund_deposit pfc_retrieve, close; funding/w_fund_deposit_locked_claims)
• FND-3 — Only users in the MIS or ACCOUNTING department groups may enter deposits or change funding; all other users get the screen read-only with fund/unfund/waiver/hold buttons suppressed. (funding/w_fund_deposit pfc_postopen)

Deposits and applying money

• FND-4 — A deposit must balance exactly: the amount left to apply (deposit amount minus amounts applied to fund pages and claims) must be zero at save; both unapplied and over-applied amounts block the save with an explanatory message. (funding/w_fund_deposit wf_check_data)
• FND-5 — A negative deposit amount is allowed only when the deposit type is ADJ; a negative amount can never be deposited to a claim, and depositing more than a claim's payable amount ("overfunding") is blocked. (funding/w_fund_deposit wf_check_data)
• FND-6 — Deposit type CHECK requires selecting one logged incoming check for the group (check_log rows not yet deposited); on save the check's check_log.status is set to 'D' (deposited), and the check's number becomes the transaction source reference. (funding/w_fund_deposit cb_check clicked, pfc_preupdate)
• FND-7 — Every deposit into a fund page writes a fundtrans row (source = check number or generated sequence, type = deposit source, applied_to = fund page); every claim funding writes two fundtrans rows — one recording the deposit into the fund page and one recording the payment from the fund page to the register entry. (funding/w_fund_deposit pfc_preupdate)
• FND-8 — Funding an entire register date ("Fund" button) skips payments on hold or waiver and locked payments; unfunding an entire register date likewise skips held/waivered/locked rows. (funding/w_fund_deposit dw_claims buttonclicked)
• FND-9 — Waiver and hold changes on a payment whose independent_ind = 'N' propagate to all payments sharing its related_fund_register_sys_key (related payments must appear on the same register). (funding/w_fund_deposit dw_claims itemchanged/clicked and buttonclicked comment)
• FND-10 — Fund page balances update in lockstep with claim funding; saving a deposit that leaves a fund page balance negative requires explicit user confirmation. (funding/w_fund_deposit wf_check_data)

Check number assignment

• FND-11 — Each bank account carries three counters: last_check_no, last_worksheet_no, last_manual_check_no (funding/d_fund_bank_acct_info_maint). Manual and drug-card checks assign the next manual check number with an optimistic-concurrency update (UPDATE ... SET last_manual_check_no = last_manual_check_no + 1 WHERE ... AND last_manual_check_no = :old); if no row updates (another user took the number), the save aborts with "Could not assign check number...please try again". (funding/w_fund_manual_check pfc_preupdate; funding/w_fund_drug_card_payment pfc_save)

Manual and vendor checks

• FND-12 — A manual check requires a payee resolved to a vendor (auto-complete against vendors with client_segment = 'FUNDING'; unmatched names prompt the Vendor Quick Add flow) and a non-negative amount; writing a check for more than the selected fund page's balance requires explicit confirmation. (funding/w_fund_manual_check wf_check_data, dw_check itemchanged/itemfocuschanged)
• FND-13 — Saving a manual check decrements the fund page balance, writes a fundtrans row of type Manual with the assigned check number, inserts a report_hist row of type MANUAL with the rendered check blob, and writes an archive text file <archive_dir>\YYYYMM\A<report_sys_key>.txt; failure of any step rolls the save back. (funding/w_fund_manual_check pfc_save/pfc_preupdate)
• FND-14 — Drug-card vendor payments generate one manual-style check per drug plan group with check_auth_ind = 'Y', summing entered cash-card fees, admin fees and claims amounts; each check decrements the fund page, assigns a manual check number, and is archived to report_hist like a manual check. (funding/w_fund_drug_card_payment pfc_save; funding/d_fund_drug_card_payment)

Void, stop, stale, reissue

• FND-15 — Batch-run (claim) checks are voided through the Reissue/Void screen; manual checks are refused there and can only be voided on the Outgoing Check Detail screen. (funding/w_fund_reissue_check ue_retrieve; funding/w_fund_check_detail ue_void_check)
• FND-16 — A check that already has a void_date cannot be voided or stopped again. (funding/w_fund_reissue_check ue_retrieve)
• FND-17 — Voiding a check: sets fundtrans.void_date for the check's payment rows; writes a reversing ADJ transaction per payment with description "Void|Stop|Stale Check#<n> (<paid date>)"; deletes the check's report_hist row; sets the original register entries to backout_ind = 'Y', paid_amt = 0, paid_dt NULL; and writes offsetting dummy register entries with payment_type_cd = 'VOID' and negated amounts for the audit trail. (funding/w_fund_reissue_check pfc_preupdate)
• FND-18 — Void with reissue re-creates the register entries fully paid (payable = paid = original amount) so a replacement check is produced, and returns a PAID claim to status RFF; fund page balances are not restored (the money remains committed). (funding/w_fund_reissue_check pfc_preupdate)
• FND-19 — Void without reissue restores the fund page balance(s), re-creates the register entries unpaid (paid_amt = 0), sets a PAID claim to RFCAHOLD, and appends a claim message recording the void/stop of the check number. (funding/w_fund_reissue_check pfc_preupdate)
• FND-20 — For WDI claims, void also backs out the related tax register entries and transfers the withheld tax from the claim's wdi_tax_fund_page_sys_key page back to the claims fund page. (funding/w_fund_reissue_check pfc_preupdate)
• FND-21 — The user records the void reason as one of Void, Stop, or Stale (three buttons setting the description prefix). (funding/w_fund_reissue_check cb_void/cb_stop/cb_stale)
• FND-22 — Voiding a manual check adds its amount back to the fund page and writes an ADJ transaction "Void of Manual Check#<n>"; un-voiding subtracts it again with a negative ADJ transaction. (funding/w_fund_check_detail ue_void_check)

Claim adjustments, refunds, splits

• FND-23 — A paid claim cannot be adjusted while any of its register entries has a non-null register_status_cd (it is in the check-register process). (funding/w_fund_adjust_claim pfc_preupdate)
• FND-24 — When adjusting a claim, the expected-refund amount must be ≥ 0 and ≤ the paid amount; PREPAID and EXPECTED rows are display-only and cannot be backed out again. (funding/w_fund_adjust_claim pfc_preupdate)
• FND-25 — Adjusting a BENPMT payment backs out the original register entry and creates a replacement row: EXPECTED (payable = expected refund) when a refund is awaited, or PREPAID (recording the retained payment) when the expected amount is zero; non-BENPMT payments always require full refund and post an ADJ (or WDI tax Transfer) transaction restoring the fund page. The claim is set to RFCAHOLD with a claim message "Adjustment of claim". (funding/w_fund_adjust_claim pfc_preupdate)
• FND-26 — Receiving a refund converts checked EXPECTED register entries to PREPAID, reduces payable/paid to the related entry's payable minus the refunded amount, writes an ADJ transaction, and increments the fund page balance by the refund; refunds entered against a new vendor row insert a fully-paid PREPAID register entry and decrement the fund page. (funding/w_fund_receive_refund pfc_save; funding/d_fund_receive_refund selects only payment_type_cd = 'EXPECTED', backout_ind = 'N')
• FND-27 — A benefit payment may be split only while unpaid and off-register (unpaid_flg = 'Y', worksheet_ind = 'N', backout_ind = 'N', payment_type_cd = 'BENPMT'); the split amount must be positive and strictly less than the payable amount; the original entry is backed out (with a reversing ADJ and fund-page restore if it had been funded) and two new BENPMT entries are created whose payables sum to the original. (funding/w_fund_split_payments pfc_save; funding/d_fund_split_payments)
• FND-28 — Transfers between fund pages of one bank account write a single Transfer transaction and move the balance; transferring more than the source balance produces a warning but is allowed. (funding/w_fund_transfer ue_transfer_funds)

Reconciliation, clearing and stale checks

• FND-29 — Manual reconciliation can be saved only when ending balance − starting balance − cleared deposits + cleared checks = 0 (difference exactly zero enables Save); saving stamps check_cleared_date on the cleared checks' transactions, deposit_date on cleared deposits, and updates bank_acct_info.last_reconciliation_dt and last_reconciliation_balance. (funding/w_fund_reconcile wf_set_menu_items, pfc_save)
• FND-30 — A check imported from a bank clearing file is marked cleared only when the file amount equals the system amount to two decimals; amount mismatches are reported as discrepancies (not cleared) and unmatched check numbers are counted as unfound. (funding/w_fund_bank_reconciliation_file wf_process_file)
• FND-31 — Check Inquiry lets a user clear/unclear checks in a date range (voided checks cannot be cleared) and adjusts bank_acct_info.last_reconciliation_balance by the net cleared amount on save. (funding/w_fund_check_inquiry ue_clear_check, pfc_save)
• FND-32 — The Outstanding Checks report lists Payment/Manual checks at least N months old (user parameter) that are uncleared, unvoided, and numbered — the stale-check candidates that feed the "Stale" void reason. (funding/d_fund_outstanding_checks; funding/w_fund_outstanding_checks)
• FND-33 — Leftover register statuses (RFR, RFC, RFCCOPY) after a check-processing run are an error condition surfaced by the Check Process Error Report. (funding/w_fund_check_process_err_rpt; funding/d_fund_check_process_err_rpt)

Positive pay

• FND-34 — Positive-pay export selects unsent transactions per bank profile: issued checks not yet notified and voided checks not yet void-notified; one output row per check number with account number, amount (full check total across the check's transactions), serial number, issue date, payee name, and issue type IS (issued) / CN (cancel) — I/V for the Citizens format. (funding/w_pospay; funding/d_pospay_unsent*, funding/d_pospay_output*)
• FND-35 — Transactions are flagged as sent (issued_notify/void_notify = 'Y' with the export filename) and committed only after the CSV file is successfully written; a failed file save leaves the rows unsent. (funding/w_pospay cb_1/cb_2/cb_3 clicked)

Reprint and register distribution

• FND-36 — Any archived output can be reprinted by searching report_hist on report type, group (including child groups), recipient, check/worksheet number and run-date range; by default only unprinted items (prt_flg = 'N') are shown, and a "to be mailed" filter separates external payees from internal ones (internal_payees). (reprint/w_reprint_maintenance ue_retrieve)
• FND-37 — Printing a reprint item sets report_hist.prt_flg = 'Y'; blob data purged to archive media is recovered by report key from an archive file (A<report_sys_key>.txt) that the operator is prompted to mount. (reprint/w_reprint_maintenance pfc_print)
• FND-38 — Check reprints re-apply the bank form's signature text, font, size and position from bank_forms for the check's bank account at print time; an optional group logo (font-rendered) is applied from the letter-header configuration. (reprint/w_reprint_maintenance pfc_print)
• FND-39 — The register reprint prints an address page per distinct "Registers" group contact (marking "**** NO REGISTER CONTACT ****" when none), the master summary once, then per-group detail; the "Accounting copy" option suppresses address pages, and "Master Summary Only" suppresses detail. Groups with enrollment option REGSUMPRNT (or the operator checkbox) get the register summary on a new page. (reprint/w_reprint_maintenance pfc_print)
• FND-40 — A QMCSO mode restricts EOB employee-copy reprints to recipients who are QMCSO custodians and drops documents that do not mention the relevant dependent's name. (reprint/w_reprint_maintenance ue_retrieve)
• FND-41 — The Check Recon reprint report summarizes, for a given run date, first/last check number, check count, worksheet range and form count per group and report type from report_hist. (reprint/w_reprint_check_recon; reprint/d_reprint_check_recon)

Incoming checks (check log)

• FND-42 — Incoming client checks are logged in check_log with payer, payee, amount, check date, received date, a purpose code (PURPOSECD codes) and status N (new), D (deposited) or F (forwarded); entering a forward code (FRWRDCODE) sets status to F, and a purpose code is mandatory. (funding/w_fund_check_maintenance; funding/d_fund_check_maintenance; funding/dddw_fund_check_status, funding/dddw_fund_purpose_codes, funding/dddw_fund_forward_codes)

Funding schedules

• FND-43 — Funding schedule runs (schedule_runs) execute either nightly (nightly_cd) or on a specific date (run_dt), have an active flag and an activity-required flag; each run is composed of components (sched_comp with a run type from code table RUNTYPES, linked via sched_run_comps) that specify included groups (grp_sched_incls) and fund page codes (grp_sched_funds). (funding/w_fund_tab_schedule; funding/w_fund_schedule_component; funding/d_fund_schedule, funding/d_fund_component_groups, funding/d_fund_component_fundpages, funding/dddw_fund_run_types)
• FND-44 — Groups can be globally excluded from scheduled funding via funding_group_excludes; the "missing" tab lists groups with claims in RFF that are on no schedule so setup gaps are caught. (funding/d_fund_grp_excludes; funding/d_fund_schedule_missing)
• FND-45 — Deleting a component removes its fund page codes, group inclusions and run links; deleting a run removes its component links. (funding/w_fund_tab_schedule — DELETE statements on grp_sched_funds, grp_sched_incls, sched_run_comps)

Funding setup

• FND-46 — The funding hierarchy screen maintains a group tree (groups.funding_parent_group_id), the bank accounts attached to groups (bank_acct_info + bank_acct_info_grps), the fund pages under each account (fund_pages + fund_page_grps), and per-coverage payment routing (fund_page_covrs with payment method codes PAYMETHOD and matching-FICA indicator). (funding/w_fund_acct_hierarchy; funding/d_fund_hierarchy; funding/d_fund_fundpage_coverages)
• FND-47 — A fund page that has been used on claims cannot be deleted. (funding/w_fund_page_maint dw comment "If fund page has already been used on claims, then prevent delete")

1099s

• FND-48 — 1099 forms print from print_1099s snapshots keyed by tax year, group (payer, with TIN and address) and vendor (payee, with TIN, TIN type and address), carrying tax_amt_box_6 and tax_amt_box_7 amounts. (provider/d_1099_print_select; schema print_1099s)
• FND-49 — Reprinting any already-printed 1099 requires the operator to enter a reason, stored in reason_for_reprint; first prints stamp printed_ind = 'Y' and orig_print_dt, every print updates last_print_dt; forms that fail to print are not marked printed. (provider/w_1099_print pfc_print; provider/w_1099_reason)
• FND-50 — Group 501-069Z prints on the 1099-NEC layout; all others use the standard 1099 form with the overlay image 1099text.wmf. (provider/w_1099_print pfc_print; provider/d_1099nec_form)
• FND-51 — Whether a vendor gets a 1099 is governed by vendors.irs_1099_flg ("Produce 1099?"), editable in vendor maintenance and in Funding's Vendor Quick Add (which defaults it to 'N'); vendor consolidation preserves the flag. (provider/d_provider_vendor; funding/w_fund_vendor_quick_add; provider/w_provider_consolidate_vendors)

Surcharge withholding

• FND-52 — The Surcharge Withholding claims report selects MEDICAL register entries paid in the requested period whose claim's service-provider or facility-provider address is in a selected state, and exports a fixed-width file (claim id, input/paid dates, group, claimed amount, claim type, provider city/state/zip) to the path configured in code table APPPATHS/WITHHOLD; a per-state census file (group, SSN, name, election level, birth, city, zip) accompanies it. A shortcut selects NY and MA together. Closing with unprinted/unsaved state reports prompts a warning. (funding/w_withholding_reports; funding/d_withholding_reports_base_data, funding/d_withholding_reports_claims, funding/d_withholding_reports_census)

Data

Core tables

Table	Role	Key columns (from schema/DW usage)
fund_register	One payable/payment row per payee per claim; the check register is built from it	register_sys_key, claim_id, payee_sys_key/payee_cd, payable_amt, paid_amt, payment_type_cd (BENPMT, PREPAID, EXPECTED, VOID), register_status_cd (RFR/RFC/RFCCOPY), worksheet_ind, backout_ind/backout_dt, waiver_ind, hold_ind/hold_desc, independent_ind, related_fund_register_sys_key, wdi_ind, paid_dt, original_paid_dt, register_dt, unpaid_flg, fund_page_sys_key, group_id
fundtrans	Money-movement journal	fundtrans_sys_key, tran_source, applied_to, tran_type (Payment, Transfer, Manual, ADJ, CHECK/other FUNDSOURCE values), amount, amount_applied, check_number, check_cleared_date, void_date, deposit_date, worksheet_number, issued_notify/void_notify (+ filenames, for positive pay), group_id
fund_pages	Sub-account balances per bank account	fund_page_sys_key, bank_acct_info_sys_key, fund_page_cd (ACCTPAGE codes), fund_balance_amt, funding_method_cd (FUNDMTHD), minimum_balance, last_register_balance/last_register_dt, register_sort_order, inactive_dt
fund_page_grps, fund_page_covrs	Fund page ↔ group links; coverage routing (benefit_coverage_type_cd, payment_method_cd, matching_fica_ind)	funding/d_fund_page_deposit, funding/d_fund_fundpage_coverages
bank_acct_info (+ bank_acct_info_grps, bank_forms)	Bank accounts, check-number counters, reconciliation state, check form/signature layout	bank_acct_no, bank_form_sys_key, last_check_no, last_worksheet_no, last_manual_check_no, last_reconciliation_dt/balance, multigroup_ind; bank_forms: routing code, signature text/font/position
check_log	Incoming client checks	check_log_sys_key, group_id, check_number, amount, check_date, received_dt, payer, payee, purpose_cd/desc, forward_cd/desc, status (N/D/F)
report_hist	Archived rendered outputs (checks, EOBs, RAs, registers, manual checks, letters)	report_sys_key, report_type_cd, report_desc, report_data (blob), orig_run_dt, check_number, worksheet_number, recipient_id/type, payee_sys_key, prt_flg, batch_id, dw_object
print_1099s	Per-vendor/group/tax-year 1099 snapshot	tax_year, group_id + payer TIN/address/phone, vendor name/TIN/vendor_tin_type/address, tax_amt_box_6, tax_amt_box_7, printed_ind, orig_print_dt, last_print_dt, reason_for_reprint
schedule_runs, sched_comp, sched_run_comps, grp_sched_incls, grp_sched_funds, funding_group_excludes	Funding schedule configuration	funding/w_fund_tab_schedule, funding/w_fund_schedule_component

CRUD by library (from analysis/schema.json)

Table	funding	chkrundw	reprint	provider
fund_register	CRUD	CRUD	—	U
fundtrans	CRUD	R	—	—
fund_pages / fund_page_grps / fund_page_covrs	CRUD	—	—	—
check_log	CRUD	—	—	—
bank_acct_info (+grps)	CRUD / CR	R	R	—
report_hist	CD	—	CRUD	—
print_1099s	—	—	—	CRUD
claims	CRUD	R	RU	R
claim_messages	CR	CRUD	—	R
vendors	CRUD	R	—	CRUD
schedule_runs / sched_comp / sched_run_comps / grp_sched_incls / grp_sched_funds	CRUD	—	—	—
groups	CRUD	R	R	R
bank_forms	R	R	R	—

Code tables used

FUNDSOURCE (deposit types), FUNDMTHD (funding methods), ACCTPAGE (fund page types), PAYMETHOD (coverage payment methods), CHECKSTAT (incoming check statuses), PURPOSECD, FRWRDCODE, RUNTYPES (schedule component types), GRPPRNDIST (print distribution options), APPPATHS/WITHHOLD (withholding export path), TESTGROUPS (excluded from delinquency reporting). (funding/dddw_*, reprint/dddw_grpprndist, funding/w_withholding_reports, funding/d_fund_delinquent_claims_summary)

Money-handling controls evidenced in code

• Balanced application — deposits must apply exactly; over/under blocked (FND-4).
• Double-entry journal — all movements recorded in fundtrans; voids and adjustments always write reversing entries rather than deleting history (FND-7, FND-17, FND-25).
• Audit rows for voids — negative-amount VOID register rows preserve the original register linkage (FND-17).
• Optimistic check-number issuance — no two checks can take the same manual number (FND-11).
• Pessimistic claim locking — session lock sequence on claims.lock_seq_no prevents concurrent funding (FND-2).
• Segregation by department — funding edits restricted to MIS/ACCOUNTING (FND-3).
• Zero-difference reconciliation — reconciliation cannot be saved out of balance (FND-29); cleared-file matching requires exact amounts (FND-30).
• In-flight protection — claims cannot be adjusted while on an active register run (FND-23); leftover run statuses are surfaced as errors (FND-33).
• Positive pay — issued and voided checks reported to banks; mark-as-sent only after successful file write (FND-34, FND-35).
• Stale-check surfacing — outstanding-check aging report plus an explicit "Stale" void reason (FND-32, FND-21).
• Reprint audit — print flag, batch id and creator recorded; 1099 reprints require a reason (FND-37, FND-49).

Migration notes

This domain moves real money. Beyond feature parity, the target system must preserve the control behaviors:

1. Do not lose the journal. fundtrans + fund_register (including backed-out and VOID rows) are the audit trail used by reconciliation, positive pay, the register, voids, and 1099s. Migrate history, not just balances; fund_pages.fund_balance_amt is a derived running balance that today is updated in application code alongside every journal write — in the target it should be derivable/verifiable from the journal.
2. Check number issuance must be transactional and gap-aware. Today three counters live on bank_acct_info with optimistic-concurrency increments in at least three separate screens plus the batch run. Centralize issuance; preserve per-account series (check vs. worksheet vs. manual).
3. The check-run batch is undiscovered server-side logic. Selection (RFR), check/worksheet numbering, paid_dt stamping, EOB/RA/register rendering and report_hist blob writing happen outside the extracted client code. This process must be located and reverse-engineered from the database/host side before parity can be claimed (see Open questions). Client-side artifacts (chkrundw DataWindows, funding/w_fund_check_process_err_rpt, reprint/w_reprint_maintenance) define its outputs precisely.
4. Void/reissue is state-machine-critical. Reissue vs. plain void differ in fund-page restoration, claim status (RFF vs RFCAHOLD), and paid-amount seeding of the replacement rows (FND-17..FND-20). WDI tax side-entries double the row volume. Model this explicitly; ad-hoc SQL re-implementation is the highest-risk area.
5. Bank interfaces are hard-coded. Positive-pay paths (UNC shares), bank file layouts, per-bank group hard-codes (Bank One = 501-404/500-005, National City = 501-541, pospay JHP = OME-RESA-only with a fixed date floor), and the OME-RESA wire instruction constants must become configuration in the target.
6. report_hist blobs are DataWindow-format text. Reprints re-import tab-delimited DataWindow dumps split by SEPSEPSEPSEP markers. Historical reprint capability after migration requires either converting these blobs to a portable rendition (e.g., PDF) at cutover or keeping a legacy renderer.
7. 1099 accumulation is invisible. Only the print screen exists in source; the population of print_1099s (which payments count, box 6 vs box 7 split, vendor vs provider attribution) must be recovered from the database job before rebuilding. The NEC special case for group 501-069Z signals form-type logic that belongs in configuration.
8. Concurrency model. Claim locking uses a nullable lock_seq_no column with manual unlock on window close — a crash leaks locks (error text tells users to call MIS). Target should use real transactional locking or short-lived reservations.
9. Department-based authorization (MIS/ACCOUNTING) is enforced in window code, not centrally. Re-express as roles/permissions on the funding functions.
10. Legacy quirks to not carry forward blindly: Oracle optimizer-mode session toggles around the bank-file screen (funding/w_fund_bank_reconciliation_file open/close), retry-until-sorted loops in register reprint (reprint/w_reprint_maintenance), archive-CD prompts, and hard-coded UNC/local paths (C:\scratch default archive dir in funding/w_fund_manual_check).

Open questions

1. Where is the check-run batch? No object in the extracted libraries inserts report_hist rows of type EOBCHK/RACHK/REGISTER, sets register_status_cd, or consumes bank_acct_info.last_check_no/last_worksheet_no. It presumably runs server-side (scheduled via schedule_runs?). Its selection, numbering, EOB assembly and register-balance update rules must be confirmed.
2. Who populates print_1099s? Only provider/d_1099_print_select reads it and provider/w_1099_print updates print flags; no accumulation source found in source. Which payments accumulate into box 6 vs box 7, and how vendor consolidation (provider/w_provider_consolidate_vendors) affects prior-year totals, is unconfirmed.
3. Missing windows referenced by the frame menu: w_fund_check_log_entry, w_fund_check_log_inquiry, w_fund_fundpage_detail, w_fund_transaction_history are opened from homersys/m_sys_frame but are not present in the extracted source. Their behavior (initial incoming-check entry, fund page drill-down, transaction history) is documented here only via their sibling screens.
4. schedule_runs execution semantics — the UI maintains runs/components but nothing in the client executes them; confirm the nightly job's interpretation of nightly_cd, activity_reqd_flg and run_type_cd (RUNTYPES values were not found enumerated in source).
5. Worksheet lifecycle — worksheets (worksheet_ind='Y', numbers W...) are printed and reported but the rule for when a payment becomes a worksheet vs a check was not found client-side (likely group/fund-page configuration consumed by the batch).
6. w_fund_deposit partial-funding check is ineffective as written — the condition compares paid_amt to itself (Round(paid_amt,2) <> Round(paid_amt,2)), so the "Cannot Partially Fund" message can never fire; confirm whether partial funding of a payment is actually allowed today (funding/w_fund_deposit wf_check_data).
7. Huntington bank-file group resolution bug — the "group not found" message concatenates with = (string expression "...account" + ls_bank_acct = " in HOMER.") and processing continues with the previous ls_group_id; clarify intended behavior (funding/w_fund_bank_reconciliation_file).
8. Check Inquiry reconciliation-balance adjustment — idbl_amt accumulates clear/unclear deltas including rows later not saved; confirm the intended effect on last_reconciliation_balance (funding/w_fund_check_inquiry).
9. OME-RESA constants — wire bank/ABA/credit-account values and the pospay JHP filter (group_id = 'OME-RESA', tran_date > 2019-03-01) are hard-coded; confirm which clients remain active and what parameterization the target needs.
10. d_fund_fund_source deposit types — the DataWindow selects a blank from dual; the actual FUNDSOURCE list is a code table whose values (beyond CHECK and ADJ referenced in code) need enumerating from data.