Skip to main content

Screen Catalog — Money Movement & Banking

Screens in library funding that move or reconcile money. Most funding sheets embed the shared group/bank-account selector funding/u_fund_group_enter (group id + name lookup with a bank-account requirement flag ii_force_bank_acct); "Select group/bank account" below refers to that control. Response windows funding/w_fund_group_select, funding/w_fund_bank_acct_select, funding/w_fund_check_select support it.

Deposit and Fund — funding/w_fund_deposit​

  • Title: "Deposit and Fund" (suffixed with group id). Menu m_fund_deposit.
  • Purpose: Record client deposits into fund pages and apply money to payable claims (window comment: "allows the user to make deposits and fund registers/claims").
  • Field groups:
    • Header: group/bank account (u_fund_group_enter), Deposit Type (d_fund_fund_source, defaults CHECK), Check picker button, Amount to apply (masked $###,###,###,###.00), Description (40 chars), Date Applied, Amount left to apply (display-only).
    • Tab "Claims": d_fund_fund_claims — payable register entries with payee (VENDOR:/MEMBER:/CUSTODIAN: prefixes), subscriber/patient, payable/paid/deposit amounts, fund status (F/P/N), waiver/hold indicators, lock info.
    • Tab "Deposit": d_fund_page_deposit — fund pages with balance, page type (ACCTPAGE code desc), funding method (FUNDMTHD code desc), deposit amount, new balance.
  • Validations: valid date applied; CHECK type requires a selected logged check; amount left must be exactly 0; negative amounts only for type ADJ; no negative or over-payable deposits to claims; negative fund-page balance requires confirmation (wf_check_data).
  • Actions: per-row fund/unfund toggle via fund-status click; register-level buttons cb_fund/cb_unfund/cb_waiver/cb_unwaiver/cb_hold/cb_unhold (skip held/waivered/locked rows); Save writes fundtrans rows, updates check_log, fund page balances and fund_register.paid_amt; claims locked on retrieve (claims.lock_seq_no) and unlocked on close.
  • Access: editable only for MIS/ACCOUNTING department users (pfc_postopen).
  • Opens: funding/w_fund_check_select (multiple logged checks), funding/w_fund_deposit_locked_claims (claims locked by other users; print list, continue or exit).
  • Operational role (User Guide ch. 5): this is the manual arm of the funding process. Payments on Authorized fund pages are never funded by the batch — they must be funded here before the check run to be paid on it. Funding from a not-yet-deposited source records the guide's "simultaneous deposit and withdrawal" (the two fundtrans rows of FND-7); if no deposit is selected, money already in the resolved fund page is applied. The Claims tab organizes payments by the register date on which they first appeared, which is also how out-of-sequence (skipped-register) payments are spotted. Non-check fund sources include ACH and wire/direct transfer (amount keyed manually); a Check source prefills the amount from the logged check. The screen must not save until the whole deposit is applied to fund pages and/or payments — matching FND-4.

Write Manual Check — funding/w_fund_manual_check​

  • Title: "Write Manual Check" (+ group). Menu m_fund_manual_check.
  • Purpose: Issue an on-demand check from a fund page to a vendor.
  • Field groups: group/bank selector; fund page list (d_fund_page_transfer_list: page, balance, type, method); check form (d_fund_manual_check: pay-to, address lines, city/state/zip, amount, description/memo, date applied, check number).
  • Validations / lookups: pay-to auto-completes against vendors with client_segment = 'FUNDING'; unknown vendor prompts Vendor Quick Add; amount must be ≥ 0; amount above fund page balance requires confirmation; check number assigned from bank_acct_info.last_manual_check_no with optimistic concurrency (retry message on clash).
  • Actions: Save decrements fund page, inserts fundtrans (type Manual), writes report_hist type MANUAL (blob of d_fund_manual_check_print) and archives A<report_sys_key>.txt under <archive_dir>\YYYYMM (INI SETTINGS/archive_dir, default C:\scratch).
  • Opens: funding/w_fund_vendor_quick_add.
  • Usage (User Guide ch. 5): Accounting cuts roughly 400–500 manual checks per month; the memo line prints on the check and doubles as the transaction description; once saved, check data cannot be edited (only the payee's address may be updated). Manual checks are also the disbursement path for deferred payments (WDI taxes, withholds, garnishments held on the WDI Taxes and Miscellaneous page) and NY surcharge remittances — for deferred payments the fund page is not decremented again, since the money was deducted when the benefit payment was funded (FND-59). Guide-era design put deferred-payment selection on a dedicated screen that determined the check amount from the selected funded payments; in the extract only the manual-check path exists — discrepancy/for SME confirmation whether a separate deferred-payment screen ever shipped.

Drug Card Payments — funding/w_fund_drug_card_payment​

  • Title: "Drug Card Payments". Menu m_fund_drug_card_payment.
  • Purpose: Enter cash-card fees, admin fees and claim amounts per drug-plan group and cut vendor checks (window comment).
  • Field groups: drug plan selector (d_fund_drug_card_plans); per-group grid (d_fund_drug_card_payment): group, check-authorization indicator, cash card fees, fees, claims fees, totals; memo line.
  • Behavior: for each modified row with check_auth_ind = 'Y' and total > 0: fund page decremented, manual check number assigned per group's bank account, fundtrans type Manual written with vendor as applied-to, report_hist MANUAL blob written (vendor address from latest vendor_addresses/pm_addresses).
  • Related maintenance: funding/w_fund_drug_card_plan_maintenance (vendors with drug plans; opens w_fund_vendor_quick_add), funding/w_fund_drug_card_groups_maintenance (groups per plan, drug_card_groups CUD).
  • Background (User Guide ch. 5): this three-screen set (plans → groups per plan → per-group payment amounts) is the PCS/drug-card design: the plan screen picks the vendor to which the batch of checks is written, and the payments screen produces one check per group to that vendor. Reimbursement from the group is separate: the disbursed amount is put against a per-group "bogus member" and a worksheet for the PCS amount is produced as the funding request, with two paired fundtrans entries — a positive "PCS claims paid by client" and a reversing negative "Reverse PCS from [register date] register". PCS pages never break down by division; they are a general fund for the group.

Transfer Funds — funding/w_fund_transfer​

  • Purpose: Transfer money between two fund pages of the same bank account.
  • Field groups: group/bank selector; source and destination fund page lists (d_fund_page_transfer_list); transfer amount; description.
  • Validations: source ≠ destination, amount > 0; over-balance transfer produces a warning only.
  • Actions: writes one fundtrans type Transfer and moves the balances (ue_transfer_funds).

Split Payments — funding/w_fund_split_payments​

  • Purpose: Split one unpaid benefit payment into two (window comment: "splitting benefit payments").
  • Field groups: claim id entry; payment grid (d_fund_split_payments: register key, paid/payable, subscriber, claimant, payee, split amount) restricted to BENPMT, unpaid_flg='Y', worksheet_ind='N', backout_ind='N'.
  • Validations: split amount ≥ 0 and strictly less than payable.
  • Actions: backs out original entry (reversing ADJ + fund page restore if funded; backout_dt only when never on a register) and inserts two BENPMT register rows summing to the original payable.

Adjust Claim — funding/w_fund_adjust_claim​

  • Title: "Adjust Claim". Menu m_fund_adjust_claim.
  • Purpose: Back out payments on a paid claim and record expected refunds.
  • Field groups: claim id; payments grid (d_fund_adjust_claim: register key, paid amount, payee, expected amount, payment type, WDI flag) — PREPAID/EXPECTED rows shown for context but filtered from processing.
  • Validations: expected ≥ 0 and ≤ paid; blocked while register_status_cd is set (claim in check-register process).
  • Actions: BENPMT → replacement EXPECTED (or PREPAID when expected = 0) row, original backed out; non-BENPMT → full refund with ADJ/WDI-tax Transfer fundtrans and fund page updates; claim set RFCAHOLD + claim message "Adjustment of claim".

Update Expected Refunds — funding/w_fund_adjust_expected_refund​

  • Purpose: Adjust or add expected-refund amounts on claims in payment allocation (window comment); modes "fix claim" vs "adjust refund" (radio buttons), updating fund_register expected rows (d_fund_adjust_expected_refund, d_fund_add_expected_refund, d_fund_adjust_refund).

Receive Refund — funding/w_fund_receive_refund​

  • Title: "Receive Refund".
  • Purpose: Record receipt of refunds for adjusted claims (window comment).
  • Field groups: claim id, adjust date, description; refund grid (d_fund_receive_refund: EXPECTED rows with payable amount, payee, receive-payment checkbox); rows can also be added for a chosen vendor (payee picked via w_fund_receive_refund_vendor_list).
  • Actions: checked existing rows → converted to PREPAID (payable/paid = related payable − refund), ADJ fundtrans, fund page incremented; added rows → new fully-paid PREPAID register row with negative ADJ fundtrans and fund page decremented.
  • Opens: funding/w_fund_receive_refund_vendor_list.
  • Usage (User Guide ch. 5): a refund is only booked once a physical check is received — a mismatched check is returned to the payee (or a difference requested), not booked. If the received check doesn't match the expected refund because the expectation was keyed wrong, or the claim was adjusted incorrectly, the operator adds a payment line (Pick A Payee) for the difference and books both. There is no screen listing already-booked refunds — users trawl the transaction log/history for them. Refunds on stoploss payments are usually logged and re-endorsed to the carrier rather than booked here; a refund may also be split between group and carrier when both paid.

Reissue/Void Check — funding/w_fund_reissue_check​

  • Title: "Reissue/Void Check". Menu m_fund_reissue_check.
  • Purpose: Void, stop or stale-date a batch check (or worksheet), optionally reissuing it.
  • Field groups: group/bank selector; check/worksheet number; Reissue checkbox; detail grid d_fund_check_detail (fundtrans payments behind the check: applied register entry, claim, payee, amounts, cleared/void dates).
  • Validations: manual checks refused (use Outgoing Check Detail); already-voided checks refused.
  • Actions: buttons Void / Stop / Stale stamp void_date rows; Save performs the full void/reissue transaction (reversing ADJ fundtrans, report_hist delete, register backout, VOID audit rows, WDI tax reversal, claim status RFF on reissue / RFCAHOLD + message otherwise). See FND-15..FND-21.
  • Usage (User Guide ch. 5): Void is used when the user has the physical check in hand; Stop when they do not (a stop payment is requested of the bank; procedurally the reissue waits until the bank confirms the stop — not system-enforced). The screen must never be used on a check that has already been cashed; a cashed voided check is "unvoided" (reinstated with the original paid date) and then cleared in reconciliation. Reissue is typically used to correct payee addresses/names — the address change must be in place before the next check run, since reissued payments go out automatically on it. Without reissue, the claims land back with the examiners ("Audit hold") for correction.

Outgoing Check Detail — funding/w_fund_check_detail​

  • Purpose: Show what a check or worksheet paid; void/unvoid manual checks (window comment: "shows what has been paid by a check (or worksheet)"). Menu m_fund_check_detail.
  • Field groups: group/bank selector, check/worksheet number; detail switches between d_fund_check_detail (claim checks) and d_fund_manual_check (manual checks).
  • Actions: toolbar void/unvoid — manual checks only: fund page balance adjusted and ADJ fundtrans "Void/Unvoid of Manual Check#" written; claim-check void path is commented out (must use Reissue/Void screen).

Outgoing Check Inquiry — funding/w_fund_check_inquiry​

  • Title: "Outgoing Check Inquiry For Group ...".
  • Purpose: Inquire on outgoing checks in a date range and clear/unclear (and historically void/unvoid) them (window comment).
  • Field groups: group/bank selector, from/thru dates, "uncleared only" checkbox; grid d_fund_check_inquiry (paid date, summed amount per check, check number, cleared date, void date, payee).
  • Actions: select-all; clear/unclear toolbar toggle (voided checks cannot be cleared); Save adjusts bank_acct_info.last_reconciliation_balance by the net cleared amount.
  • Usage (User Guide ch. 5): this screen is also where Accounting performs the group void for closed groups — after run-out completes (typically ~6 months), all outstanding checks on the account are voided together so the account can be closed, and a list of the affected benefit payments is produced for the client's next administrator.

Incoming Check Maintenance — funding/w_fund_check_maintenance​

  • Title: "Incoming Check Maintenance For Group ...". Menu m_fund_check_maintenance.
  • Purpose: Maintain the incoming check log (check_log).
  • Field groups: search panel (d_fund_check_status_search: check/received date ranges, amount range, status, check number); grid d_fund_check_maintenance (status, check number, amount, dates, payer, payee, purpose code/desc, forward code/desc, audit columns).
  • Code tables: status CHECKSTAT (N new, D deposited, F forwarded; "All" searches F+D+N), purpose PURPOSECD, forward FRWRDCODE.
  • Validations: purpose code required; entering a forward code sets status F, clearing it returns N; new rows keyed by all_purpose_seq and default status N.
  • Note: initial check-log entry/inquiry windows (w_fund_check_log_entry, w_fund_check_log_inquiry) are referenced from the frame menu but missing from the extract. The user guide (ch. 5) documents the original Incoming Check Log this screen replaced, and its rules carry through: all incoming checks except refunds are logged before the system can use them (refunds instead go through Receive Refund); payer and payee default to the group being logged and may be overridden; a check starts as "No Action Taken" (N) unless forwarding info is given ("Forwarded", F); only "No Action Taken" checks may be deposited; clearing the forward code returns a forwarded check to N; once "Deposited" (D) a check can no longer be altered or deleted — an erroneous deposit is corrected by a fund-page adjustment or transfer, never by deleting the check. The check number (or a system-generated transaction ID for non-check deposits) is retained so how the deposit was spent can be traced.
  • Cross-module note (User Guide ch. 4): premiums collected on behalf of carriers under statement billing are booked as "Received and Forwarded" entries — forwarded incoming checks are part of that flow, not plan funds.

Reconciliation — funding/w_fund_reconcile​

  • Title: "Reconciliation" (+ group). Menu m_fund_reconcile.
  • Purpose: Manual bank reconciliation per bank account.
  • Field groups: group/bank selector; statement date; starting balance (from bank_acct_info.last_reconciliation_balance), ending balance, difference (computed); deposits grid d_fund_reconcile_deposit (undeposited fundtrans grouped by source with FUNDSOURCE description); checks grid d_fund_reconcile_check (uncleared, unvoided checks grouped by check number).
  • Rules: Save enabled only when difference = 0; stamps deposit_date / check_cleared_date and updates bank_acct_info.last_reconciliation_dt/balance.
  • Procedure (User Guide ch. 5): the on-screen flow implements step 1 of the three-step monthly reconciliation (post all transactions: record interest/fees as deposits, clear the statement's checks, add Pay Anyway deposits); steps 2–3 (working back to the bank's balance via outstanding checks/deposits-in-transit, then breaking the balance into fund-page balances and unallocated amounts) are produced by the Bank Reconciliation Report. Reconciliation types differ by account: Normal accounts get full detail reconciliation; zero-balance / client-controlled accounts are reconciled by transferring out of Claims Reserve until other pages are non-negative (Claims Reserve should then equal outstanding checks); Pay Anyway accounts either reconcile late or not at all. A check voided/reissued after the statement close still counts as outstanding for that statement. See "Operational practice" on the overview page.

Bank Reconciliation Report — funding/w_fund_reconcile_report​

  • Title: "Bank Reconciliation". Menu m_fund_reconcile_report.
  • Purpose: Produce the reconciliation report for an account: summary of receipts vs disbursements since a date, plus outstanding-check listing (d_fund_reconcile_report, d_fund_reconcile_report_check, print via d_fund_reconcile_report_print).

Bank Reconciliation File — funding/w_fund_bank_reconciliation_file​

  • Title: "Bank Reconciliation File". Menu m_fund_bank_file.
  • Purpose: Import a bank's cleared-check file and auto-clear matching checks.
  • Field groups: bank selector dropdown (Bank One / Huntington Bank / National City Bank); message grid (d_fund_bank_reconciliation_file_errors); print via d_fund_bank_reconciliation_file_print.
  • Rules: per-bank fixed positions parsed; Bank One fixed to groups 501-404/500-005; Huntington processes only tran code 05 and resolves group by bank account number; National City fixed to 501-541; clear only on exact amount match; discrepancies and unfound checks reported and counted; commits every 1000 records. Session toggles Oracle optimizer mode on open/close.

Positive Pay Check Outbound File — funding/w_pospay​

  • Title: "Positive Pay Check Outbound File" (plain window, not a sheet).
  • Purpose: Export issued/voided checks to bank positive-pay CSV files.
  • Field groups: three buttons — "Create File - JHP" (d_pospay_unsent → d_pospay_output), "Create File - 750" (d_pospay_unsent_citz → d_pospay_output_citz), "Create File - 125" (d_pospay_unsent_125 → d_pospay_output_125); "write file" and "show processing" checkboxes; counters for rows retrieved/output/updated/voids.
  • Rules: one output row per check number (account, total check amount, serial, issue date MMDDYY, payee, issue type IS/CN, Citizens I/V); rows marked issued_notify/void_notify = 'Y' with filename SFPI<MMDDYYYY>.csv; DB update committed only after successful SaveAs to \\sfpiserver1\acctg\huntington_outgoing_checks\ or ...citizens_outgoing_checks\; overwrite prompts if the file exists.

OME-RESA Wire Transfer — funding/w_bill_ome_wire_transfer​

  • Title: "OME-RESA Wire Transfer". Menu m_bill_ome_wire_transfer.
  • Purpose: Summarize funded benefit payments (BENPMT/PREPAID with check numbers) for the OME-RESA group tree by claim type into a wire-transfer remittance (fixed Huntington bank/ABA/account constants); variants exclude/only Aetna (d_bill_ome_wire_transfer_aetna_only, _non_aetna); adjustments entered via funding/w_bill_ome_wire_transfer_adj (w_maint_single over d_bill_ome_wire_transfer_adj).
  • Related: funding/w_bill_ome_b_and_r ("Ome-Resa Billing and Remittance Process", current vs prior month DataWindows) and funding/w_fund_omeresa_monthly_claims_data ("OMERESA Monthly Claims Data").