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.

Screen-by-screen detail is split across three catalogs: Money movement & banking, Setup & schedules, and Reports, reprint & 1099s.

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 = Ready For Register (selected by the funding batch), RFC = Ready For Check (register assembled, awaiting output), RFCCOPY/RFCOLD (check-run output passes); NULL = at rest	chkrundw/d_register_payments (register_status_cd = 'RFR'), funding/d_fund_check_process_err_rpt; status meanings (User Guide ch. 5)
Claim funding statuses	claims.claim_status_cd: RFF (ready for funding), PAID, RFCAHOLD (held after adjustment/void — the guide calls this "Audit hold status", returning the claim to examiners)	funding/w_fund_deposit, funding/w_fund_reissue_check, funding/w_fund_adjust_claim; (User Guide ch. 5)
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, but its structure is now documented: the user guide's Procedures section describes it as three server-side background processes — see "The check-run batch pipeline" below (User Guide ch. 5). The client-side evidence remains 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.

1a. The check-run batch pipeline (server-side) (User Guide ch. 5)

What operations calls "a check run" is three distinct batch processes, each with its own background console, launched by the nightly scheduler and gated by a processing window in table batch_schedules (a "Not Processing" console message means the current time is outside batch_schedules start/end times).

1. FUNDING — applies funds to specific fund_register rows (FIFO by create_dt across the whole group for Prefunded / Pay Anyway pages) and marks every row that will appear on the register register_status_cd = 'RFR' (Ready For Register). If it crashes it is simply restarted and picks up where it left off. Backing it out means: sum fundtrans.amount_applied for the run date where applied_to = the register keys, restore that sum to fund_pages.fund_balance_amt, subtract it from fund_pages.paid_amt, and delete those fundtrans rows.
2. CHECK REGISTER — gathers all RFR rows, assembles the register by the fund pages the rows resolved to, marks paid rows 'RFC' (Ready For Check), sets the claim to PAID when all its register rows are paid, updates fund_pages.last_register_balance / last_register_dt, and assigns check and worksheet numbers to the fundtrans records (checks sorted by group ID, then fund page, then payee — all payments to the same payee from the same fund page of the same group go on one check; worksheet numbers are a separate sequence). The pre-June-2000 version locked the claims it processed with claims.lock_user_id = 'SFPIBACK' and a lock_seq_no, and a crash required a multi-step manual backout (reset statuses to RFR/RFF, null paid_dt/register_dt, roll back bank_acct_info check/worksheet counters, null fundtrans check/worksheet numbers, restore fund_pages.last_register_balance/_dt, then unlock). The rewrite in production since June 2000 locks nothing and, like the other two processes, only needs to be restarted after a crash.
3. CHECK RUN — creates all output beyond the register itself: the check (or worksheet when there is no payment), EOBs, RAs and all requested copies, written to report_hist. It makes two passes over the data: the first changes rows (as applicable) to 'RFCCOPY' or 'RFCOLD', the second changes everything left to 'RFCOLD'. Restartable after a crash; a deliberate backout deletes the run's report_hist rows (by create_dt) and resets register_status_cd to 'RFC'.

A frequent crash cause was a related_fund_register_sys_key with no matching register_sys_key in fund_register; the guide includes diagnostic SQL against the run's RFR backlog (the data equivalent of data store ADS_PAYMENTS). (User Guide ch. 5, "Debugging Check Run Crashes")

The guide specifies two further batch processes around this pipeline, neither of which is evidenced in the extracted source:

• Check for Skipped Payments — scans funded benefit payments and, when older payments are still awaiting payment, notifies the client that a payment was made out of sequence (a skipped register). The guide considers duplicate payment already prevented by the rewritten Deposit and Fund screen, which marks payments paid as funds are allocated and lists outstanding payments by the register on which they first appeared (User Guide ch. 5, §1.5.2).
• Notify Client — produced with the registers during the check run, telling the client what previously sent information changed, what it changed to, and whom to call. The guide itself flags this as a nice-to-have that had "fallen by the wayside" or been folded into the letters work (User Guide ch. 5, §1.6.5).

Discrepancy for SME confirmation: the user guide (ch. 5) states the check-run process's final pass sets register_status_cd = 'RFCOLD', yet the extracted error report treats only RFR/RFC/RFCCOPY as leftover statuses and the register selection assumes NULL at rest — either RFCOLD was later replaced by nulling the status, or RFCOLD rows are a terminal state the error report deliberately ignores.

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)

Check-run batch pipeline and funding semantics (User Guide ch. 5)

Requirements below are sourced from the official user guide (chapter 5, "Funding", including its Procedures section); they describe the server-side engine and design semantics that the extracted client code only evidences indirectly.

• FND-53 — A "check run" executes as three sequential batch processes: FUNDING (applies funds, marks register entries RFR), CHECK REGISTER (assembles the register, marks paid entries RFC, sets fully-paid claims to PAID, updates fund_pages.last_register_balance/last_register_dt, assigns check and worksheet numbers to fundtrans), and CHECK RUN (renders checks/worksheets/EOBs/RAs/copies in two passes, marking entries RFCCOPY then RFCOLD). FUNDING and CHECK RUN (and, since June 2000, CHECK REGISTER) are restartable after a crash without backout. (User Guide ch. 5)
• FND-54 — Batch funding processes run only inside the processing window defined in batch_schedules (start/end times); outside the window the consoles report "Not Processing". (User Guide ch. 5)
• FND-55 — Check numbers are assigned by sorting on group ID, then fund page, then payee: all payments to the same payee from the same fund page of the same group are combined onto one check; worksheet numbers are assigned by the same procedure from a separate number sequence. (User Guide ch. 5)
• FND-56 — When a claim reaches "Ready for Funding", the application creates its fund_register rows initialized as: backout_ind = 'N', hold_ind = 'N', paid_amt = 0, cobra_ind from the claimant's COBRA standing, waiver_ind per stoploss-waiver parameters, fund_page_sys_key copied from claims; for WDI claims all of a claim's payments get independent_ind = 'N' and a shared related_fund_register_sys_key (otherwise independent_ind = 'Y'); register_dt is left null so the next register run reports the row as Newly Reported. (User Guide ch. 5)
• FND-57 — worksheet_ind is initialized 'Y' in exactly three cases: (a) payable_amt = 0; (b) the group and vendor match an entry in the group_as_vendor table (the client would otherwise write a check to itself); (c) the benefit payment's coverage type resolves to a fund page whose payment method in fund_page_covrs is 'W' (worksheet). Otherwise it is 'N'. (User Guide ch. 5)
• FND-58 — The funding batch pays eligible payments in FIFO order (sorted on fund_register.create_dt across the whole group) for Prefunded and Pay Anyway pages; a large payment that cannot be fully funded is skipped and smaller payments behind it are paid. Payments are never partially funded by the batch — the only way to partially pay is to split the benefit payment. Payments from Authorized pages are untouched by the batch and must be funded manually (Deposit and Fund) before the check run in order to pay. Held or waivered payments may carry funds but no check is produced until released. (User Guide ch. 5)
• FND-59 — Deferred payment types (FITW, SITW, LITW, FICA, MATCH FICA, GARN, UNEMPLOY) are funded together with the main benefit payment (WDI tax payments must fund at the same time as the benefit) but do not cut a check in the check run; WDI tax and withheld amounts transfer to the group's "WDI Taxes and Miscellaneous" fund page, and checks are later cut through the deferred-payment/manual-check path without decrementing the fund page again (the balance was reduced when the payments were funded). (User Guide ch. 5)
• FND-60 — Register section semantics: a payment whose register_dt is null is reported as Newly Reported and stamped with the run date; an unfunded payment (paid_amt = 0) with register_dt before the current run appears under Previously Reported (most recent last); a payment whose paid_amt equals payable_amt appears under Paid. Worksheets appear only in the Paid section. The register's single "pay this amount" total excludes worksheet, on-hold and waivered amounts. (User Guide ch. 5)
• FND-61 — Once a benefit payment has entered funding, only Accounting can place it on hold (Adjudication can instead pull it back to an earlier claim status, with similar effect); a hold requires a reason, stored as a system message; payments can be held or released individually or by register. (User Guide ch. 5)
• FND-62 — The funding batch prohibits funding claims on stoploss waiver; the waiver must be manually removed before the payment can be funded. By convention only a deposit from the stoploss carrier should fund a waivered payment — an administrative rule, not system-enforced. (User Guide ch. 5)
• FND-63 — Worksheeting a terminated group (run-out): the group's fund pages are flagged so all future claims (before Payment Allocation status) generate worksheets instead of checks, and claims already in funding are converted by setting fund_register.paid_amt = payable_amt and worksheet_ind = 'Y'; the register then still informs the group of its benefit payments. (User Guide ch. 5, "Worksheeting Claims for terminated groups")
• FND-64 — Most funding reports must be producible on both a gross and a net basis. Gross (cash) basis reports each event when it happened: a benefit payment paid 4/1 and adjusted 5/1 appears as a payment on 4/1 and an adjustment on 5/1. Net (accrual) basis reports the original transaction net of later activity: the same payment appears on 4/1 already reduced by the adjustment. The guide's convention is year-end reports on the net basis, monthly reports on the gross basis, and the quarterly WDI report on a cash basis. (User Guide ch. 5 and its glossary) No basis switch exists anywhere in the extracted reporting code — this is a system-wide reporting requirement, not a per-report option.

Operational practice (User Guide ch. 5)

Operational context around the code-derived rules above — funding-cycle practice as run by SFPI/M3 accounting:

• Weekly cadence. The register process runs Monday through Thursday nights, with checks printing the following day. Groups run in pairs of register nights: Monday and Wednesday are the first and second registers for Pittsburgh and Chicago; Tuesday and Thursday for Cleveland. Each group produces a register on its first scheduled night; later registers can be suppressed when the group has made no deposits ("activity required"). Holiday/special schedules temporarily replace the standard one, and registers can also be run on request (real-time). Accounting has been in the habit of creating a new schedule component for every run.
• Funding methods. A fund page's FUNDMTHD code decides whether the batch may pay from it: Prefunded pays fundable payments FIFO until money or payments run out; Authorized ("pay by invoice") is never touched by the batch and must be funded by hand in Deposit and Fund (FND-58); Pay Anyway pays regardless of balance and is expected to run negative; Replenishment pays, then requests a top-up. Full definitions are on Setup & schedules.
• Bank relationships. The main bank is Huntington; federal income tax deposits for WDI liabilities are made to Huntington for later payment to the federal government. Some groups instruct their own banks which checks to expect (SFPI e-mails a check file), others wire funds then instruct SFPI when to run a register (Authorized), others use controlled-disbursement accounts. About 40 clients receive their check register by fax; registers are stored electronically and printed on demand.
• Reconciliation procedure. Three steps: (1) post all transactions — record bank interest and fees, reconcile deposits (adding deposits for Pay Anyway groups), and clear the statement's checks (roughly half the checks, from the 20–30 largest clients, arrive on tape and clear via an automated batch process; the rest clear on-screen from paper statements); (2) reconcile to the accounting pages — total uncleared checks and deposits-in-transit to work back to the bank's number (a check outstanding at statement close but voided/reissued afterwards still counts as outstanding for that statement); (3) break the account balance down into fund-page balances, outstanding checks/deposits, and unallocated amounts. Reconciliation types: Normal (full detail reconciliation), Zero-balance / client-controlled (negative fund-page positions are resolved by transfer from Claims Reserve; the Claims Reserve balance should then equal outstanding checks), and no reconciliation (Pay Anyway accounts SFPI is not responsible for).
• Stale and run-out checks. Checks uncashed past a time limit (3 months, 6 months, or 1 year) surface on a report for Adjudication to cancel — voids of these need Claims' approval. For closed groups, Accounting waits ~6 months after run-out completes, voids all outstanding checks as a group (from Outgoing Check Inquiry), and hands the next administrator a list of the benefit payments whose checks were voided.
• Refund practice. A refund can only be recorded once a check is physically received. Refund checks for stoploss payments are usually logged and re-endorsed to the stoploss carrier; refunds returned to the group rather than deposited are recorded in the check log but never appear on the fund page or bank reconciliation. Over-refunds are deposited and the difference re-refunded by manual check.
• NY/MA surcharge process. Runs separately from the register and check run, because New York mandates a formula that rounds at the aggregate level and so cannot be evaluated claim-by-claim. Each month: (1) select payments whose check has already been issued — funded payments still awaiting a check are excluded — for services performed by a New York provider and not yet surcharged; (2) total the payable amounts, rounded up to the nearest dollar; (3) apply 8.18 % and round up to the nearest dollar again. Payments are due by the end of the month following the claims month, broken out by service-incur year back to 1997, on state forms Accounting fills in by hand. Booking is manual — money is moved between fund pages and paid by manual check, cleared in normal reconciliation. A group may instead pay New York a monthly capitated amount for its NY-resident members (reported by "NY Pool Region" zip-code groupings). Known gap: surcharge amounts are never prorated back onto the claims that generated them, even though they should count toward stoploss deductibles and attachment points. (User Guide ch. 5)
• Manual check volume. Accounting generates roughly 400–500 manual checks per month and uses (or wanted) a dedicated printer; the manual check prints alone and its RA/EOB/stoploss output rides the next register process.
• Cross-module accounting practice (billing side). The posting model distinguishes the A/R page from the bank-balance page — a receipt posts to A/R when billed and to the bank balance when deposited, so funding's fund-page balances and billing's receivables are separate views of the same money (User Guide ch. 4). Over/short amounts are booked to dedicated accounts: 222 for miscellaneous over/short and 207 for premium over/short (User Guide ch. 4). Premiums collected for carriers under statement billing are recorded as "Received and Forwarded" entries rather than plan funds (User Guide ch. 4). Binder checks (deposits taken to open a group) reduce the group's first billed premium — until then they appear in reconciliation as unallocated binder-check amounts (see the A/R breakdown in the reconciliation procedure above) (User Guide ch. 4). Commission money moves SFPI Fund → SFPI Agency Fund before broker commission checks are cut, and brokers are paid monthly (Medicare-supplement business may generate multiple payments) (User Guide ch. 8).

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 server-side logic whose shape is now known but whose code is still unrecovered. The user guide (ch. 5) identifies it as three restartable background processes (FUNDING, CHECK REGISTER, CHECK RUN) gated by batch_schedules, with the CHECK REGISTER process historically locking claims as user SFPIBACK — so the binaries/jobs to recover are the three batch consoles running under that identity. Selection (RFR), check/worksheet numbering (group → fund page → payee, one check per payee per page per group), paid_dt stamping, EOB/RA/register rendering and report_hist blob writing all happen there. The guide also documents the manual backout SQL for each stage — effectively a specification of each process's writes. Client-side artifacts (chkrundw DataWindows, funding/w_fund_check_process_err_rpt, reprint/w_reprint_maintenance) define its outputs precisely; the recovered code must still be diffed against both.
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? — Resolved (structure), code still unrecovered (User Guide ch. 5). It is a server-side pipeline of three background processes (FUNDING → CHECK REGISTER → CHECK RUN; see "The check-run batch pipeline" above) triggered by the nightly scheduler from schedule_runs and gated by batch_schedules; the CHECK REGISTER stage assigns check/worksheet numbers (group → fund page → payee) and historically locked claims as user SFPIBACK. Remaining unknowns: the physical form of the three processes (host PB executables? stored procedures?), and whether the post-2000 code still writes RFCOLD (see discrepancy note above).
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. The user guide (ch. 5) adds only that "if taxes are paid, 1099s will be generated based on the benefit payment's payee" — i.e. accumulation is payee-driven from funded benefit payments — but gives no box-level rules. The guide's commissions chapter (ch. 8) likewise leaves open the 1099/taxable distinction for broker payments, and how a commission check is voided — both still open on the accounting side, not just in the extract.
3. Missing windows referenced by the frame menu — partially resolved (User Guide ch. 5). w_fund_check_log_entry / w_fund_check_log_inquiry: the guide documents the Incoming Check Log as the entry/inquiry facility that logs checks before any use (statuses "No Action Taken" / "Forwarded" / "Deposited"; refunds excluded; payer/payee default to the group; only "No Action Taken" checks may be deposited; deposited checks are immutable) — behavior that survives in w_fund_check_maintenance, its rewrite. w_fund_transaction_history: the guide describes a Transaction History screen showing all transactions against a bank account, filtered by date range — used to list each day's receipts per group and to find already-booked refunds (the system offers no dedicated refund listing). w_fund_fundpage_detail remains undocumented (closest guide analogue: the "fund page activity for a period" report).
4. schedule_runs execution semantics — resolved (User Guide ch. 5). A nightly batch process reads the schedule and triggers check runs accordingly: a run is the timing (recurring night of week, specific date, or immediate), a component is what runs (groups plus optional fund-page types — specifying a type runs every page of that type for every group in the component; specifying none runs all pages), and a schedule pairs them; components are reusable across runs. activity_reqd_flg means deposits since the last check run are required for the run to produce output. Guide-era run types: Claims, Holiday, Special (RUNTYPES values still unenumerated in data). Operational cadence and holiday handling: see Operational practice.
5. Worksheet lifecycle — resolved (User Guide ch. 5). A payment becomes a worksheet (worksheet_ind = 'Y') at register-entry creation when payable is zero, the group is also the vendor (group_as_vendor), or the coverage's fund-page payment method is 'W' (see FND-57); terminated-group run-out forces worksheets across a fund page (FND-63). Worksheets are EOBs/RAs without the negotiable check portion, get numbers from their own sequence, appear only in the register's Paid section, and are excluded from the "pay this amount" total.
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 (funding/w_fund_deposit wf_check_data). Intent now confirmed (User Guide ch. 5): benefit payments are by design never partially funded — the only sanctioned partial payment is splitting the payment into two and fully paying one (FND-58, w_fund_split_payments). The dead code is a broken guard for that rule, not evidence that partial funding is allowed; whether anything else prevents partial funding at save time still needs SME/code confirmation.
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. Partially resolved (User Guide ch. 5): the guide names the non-check fund sources as receipt manners such as ACH (automated clearing house) and direct/wire transfer — for these the user keys the amount, whereas Check prefills it from the selected logged check. Exact code values still need enumerating from the codes table.