Screen Catalog — Funding Setup & Schedules

Configuration screens in library funding: the funding hierarchy, bank accounts, fund pages, funding schedules, and the vendor quick-add used by check-writing screens.

---

Funding Account Hierarchy — funding/w_fund_acct_hierarchy

• Purpose: One screen listing a group's funding hierarchy, bank accounts and fund pages (window comment).
• Field groups:
  • Hierarchy tree (d_fund_hierarchy): group tree walked by groups.funding_parent_group_id, showing per-group counts of bank accounts and fund pages.
  • Bank accounts (d_fund_hierarchy_bank_accts, d_fund_hierarchy_bank_acct_info): account number, routing/bank form (bank_forms via dddw_bank_forms), print name/address, check counters (last_check_no, last_worksheet_no, last_manual_check_no), multigroup indicator.
  • Fund pages (d_fund_hierarchy_fund_pages, d_fund_hierarchy_fund_page_list, d_fund_hierarchy_fund_page_info): page code (ACCTPAGE), description, balance, funding method (FUNDMTHD), minimum balance, register sort order, inactive date.
  • Coverages per fund page (d_fund_hierarchy_coverages / d_fund_fundpage_coverages over fund_page_covrs): benefit coverage type, payment method (PAYMETHOD), matching-FICA indicator.
• Actions (save logic): inserts/updates bank_acct_info + bank_acct_info_grps, fund_pages + fund_page_grps, fund_page_covrs; can create funding-only group nodes (groups insert with funding_parent_group_id) and move groups within the funding tree; deletes cascade to bank_acct_info_grps/bank_acct_info, fund_page_covrs, and funding-only groups rows (with audit_groups cleanup).
• Opens: funding/w_fund_acct_hierarchy_add_entity (add bank account or fund page), funding/w_fund_acct_hierarchy_add_group, funding/w_fund_acct_hierarchy_select_group.
• Business purpose of the hierarchy (User Guide ch. 5): the funding hierarchy is "a modified version of the Enrollment hierarchy" — the enrollment structure is used as the initial template and then rearranged to suit how the client wants money organized. The choice it encodes is co-mingling: a group may run "one set of funding pages for the entire hierarchy (co-mingling the deposits and checks from different divisions in one place)" or a separate page per level, so deposits must then be broken down per division. Consequences: "The hierarchy established for funding is only going to accurately reflect the needs of the group as long as the enrollment structure from which the funding structure is based has not changed" — adding or deleting a base node in enrollment puts the funding hierarchy in question. A newly added enrollment base group "will appear attached to the master group" and "until this position has been confirmed or moved, the new node will not accept any attributes of the parent".
• Placement rules (User Guide ch. 5): a funding-only added group "must be below the master group and above the base (childless) groups"; on rearrangement, "base groups must be lower than their master group". Naming of added funding nodes is unconstrained — "any conventions will be business practices only". When a benefit payment cannot resolve to a fund page — a new group sending payments, or a coverage type the pages were not set up to pay — "a message will be placed on the claim".
• Payment method per coverage (fund_page_covrs, codes PAYMETHOD) (User Guide ch. 5): the payment method "designate[s] the form the 'payment' will take" — Checks (SFPI generates the payment for the client) or Worksheets (SFPI adjudicates but the client generates its own payment, or the payment is for zero dollars). Deferred payments are not a payment method: they are identified by payment type code (FITW, SITW, LITW, FICA, MATCH FICA, GARN, UNEMPLOY, versus the normal BENPMT) and "will be allowed to be funded but will not cut a check through the normal process" — a check is cut only from the deferred-payment screen. A coverage whose payment method is W forces the worksheet indicator on the register row, as does a zero payable amount or a group/vendor match in the GROUP_AS_VENDOR table (the client is its own payee).
• Matching-FICA indicator (User Guide ch. 5): applies to WDI only and records whether the group funds matching FICA in addition to the gross benefit. "In this case, if taxes are funded by the group's account, matching FICA is also funded by the group's account. There is never a situation where SFPI/M3 funds the taxes for the group, calculates and reports the Matching FICA, but does not fund it." The alternative is that SFPI "doesn't calculate, report or fund the matching FICA amount".

Fund Page Maintenance — funding/w_fund_page_maint (with funding/w_fund_page_selection)

• Purpose: Maintain individual fund pages (window comment "Fund Page Maintenance"); selection sheet lists a group's pages (d_fund_group_fund_list).
• Field groups: group hierarchy and page/group cross reference (d_fund_group_hierarchy, d_fund_group_fund_info, d_fund_page_group_list, d_fund_fund_page_grps); page editor (d_fund_page_edit: page code, balance, funding method, minimum balance, description, last register balance/date, inactive date, register sort order, audit columns); coverages (d_fund_hierarchy_coverages).
• Rules: a fund page already used on claims cannot be deleted (pfc_deleterow comment).

What a fund page is (User Guide ch. 5): fund pages are "virtual sub-accounts" that "divide the money in the group's actual bank account into individual 'pots' of money, based upon the group's funding needs and the level of reporting detail they require". They exist only inside the SFPI/M3 system — the real bank balance is reconstructed by summing "all the individual fund page balances, all outstanding checks, and then all the funds residing with funded benefit payments". Pages can hang at any level of the funding hierarchy, "but only after a bank account has been established", and every group must have at least one page, the Claims Reserve page (a rule the guide says is enforced by the application).

Page types are labels only, not behavior: "The types of fund pages are merely names and no attempt to restrict coverage types being assigned to any fund page will be made" — a WDI payment may pay from a Claims Reserve page and vice versa. The catalogued types are Claims Reserve; WDI or Disability Claims Reserve; COBRA Reserve; Flex Fund; a "Stand alone" Reserve; Stoploss Reserve; PCS and other Related Drug Plans; Interest and Service Charges; Miscellaneous Charges; NYI Surcharge; Unallocated Funds; Credits (User Guide ch. 5).

Field meanings and lifecycle rules (User Guide ch. 5):

• Coverage uniqueness — pages may repeat across nodes of a master group, but "the coverage types cannot be duplicated within a specific node", and no two pages at the same level may hold All plus anything else. The guide states this constraint "will be enforced by the database" (see migration note below).

• Minimum balance is a client notification trip point, not a payment block: "An informational message to the client will appear when the account has fallen below a particular trip point", delivered as a system-generated letter or a message on the next register, with optional early warning as the page nears the trip point.

• A page saved with no coverage type and no payment method is a "balance page" — "a page that never has a benefit payment pay from it"; funds leave it only by inter-fund transfer.

• Inter-fund transfers carry three access levels — general, expert and Super-user (the guide's example: only a super-user may transfer into the COBRA fund). Transfers "will not affect the group's overall balance".

• Delete / inactivate — a page that has ever had activity (deposits, transfers) cannot be deleted, nor can one that has had claims resolved to it. Inactivating "will prohibit any future claim from resolving to it" and also "suspend the rules for adding a page so that other pages can be added to that group regardless the coverage type on the inactive page"; reactivating reapplies the rule.

• Funding method (FUNDMTHD) determines how money leaves the page:

  • Prefunded — payments need not appear on a register first; each check-register run pays fundable benefit payments in FIFO order "until the benefit payments are all paid or the specific fund page runs out of funds".
  • Authorized — "a 'pay by invoice' concept" requiring manual designation of which payments are funded; the invoice is the register sent to the client.
  • Pay Anyway — pays whenever ready "regardless of the funding available", for zero-balance / cash-disbursement accounts where the client has its own bank arrangement; "The balance will continue to go negative" by design.
  • The guide also names a Replenishment Funded method (pay first, request replenishment after).

  A page with a zero balance stops funding until a deposit or transfer arrives — "The exception to this rule is the Pay Anyway method, where balance is not a factor when disbursing funds."

Bank Account Maintenance — funding/w_fund_bank_acct_info_maint / selection funding/w_fund_bank_acct_info_selection

• Purpose: Maintain bank accounts independent of the hierarchy screen.
• Field groups (d_fund_bank_acct_info_maint): bank account number, bank form / routing transit code (bank_forms), print name and print address, last check / worksheet / manual check numbers, multigroup indicator. Selection window filters by bank (d_fund_bank_form_bank) and lists accounts (d_fund_bank_acct_info_select).
• Note: bank_forms also carries the signature text/font/size/x-y positions applied to checks at print time (reprint/w_reprint_maintenance).
• Field meanings (User Guide ch. 5): Print Name is "the name of the bank to print on the check" (the guide notes it "will equate to the Check Name on the Wang"); Bank Routing Code is "the electronic routing number identifying the bank"; Signature Code designates "what signature 'image' is printed on the check"; Last Check Number and Last Worksheet Number are the high-water marks — "the next check number will be one more than what is entered". Check and worksheet numbers run as two separate sequences.
• Why the multigroup indicator exists (User Guide ch. 5): "Any funding structure established will normally draw from a single bank account at the master group level of the funding structure, but the data supports multiple accounts for one group and multiple groups per account. The multi-account functionality will be accomplished by more than one group having a fund page that goes back to a single bank account."
• Delete / inactivate rules (User Guide ch. 5): "If the bank account has any fund pages, it cannot be deleted." There is no explicit inactivation — "if all the fund pages attached to the bank account are inactive, the bank account is basically inactive too."

Funding Schedules — funding/w_fund_tab_schedule

• Title: "Funding Schedules". Menu m_fund_schedule_components.
• Purpose: Maintain scheduled funding runs and their components.
• Tabs:
  • Runs (d_fund_schedule, d_fund_schedule_runs over schedule_runs): run description, active flag, activity-required flag, nightly code vs specific run date (radio "nightly"/"date").
  • Components (d_fund_component_list): component descriptions with run type.
  • Schedules: tree of runs and their components (sched_run_comps), drag-and-drop assembly; deleting a run deletes its sched_run_comps links; deleting a component deletes its grp_sched_funds, grp_sched_incls, and sched_run_comps rows.
  • Group report (d_fund_schedule_missing): groups with claims in RFF status that belong to no schedule (excluding parent 501-003), so nothing payable is silently unscheduled. The guide specifies the alerting behavior: "If any are found the tab will turn deep pink indicating that a group should be added to a register schedule." (User Guide ch. 5)
• Opens: funding/w_fund_schedule_component.

What the schedule controls (User Guide ch. 5): the schedule governs the whole check run — "the funding of the non-Authorized benefit payments and the printing of the registers, checks and RA/EOB". It "basically determines when to look for benefit payments to pay, and when a run has been applied to a funding page, that schedule can also determine what type of benefit payments to pay." A schedule attaches to a master group, to an informational grouping that ties several master groups together, or to specific fund pages that divisions share (for example WDI and Disability Reserve on a different night from Claims Reserve), so "it is entirely possible that a master group may have several different schedules at any given time".

Field meanings (Runs tab) (User Guide ch. 5): Active? distinguishes a live schedule from "a dormant 'special use' schedule"; Activity Required states "whether activity (meaning deposits) are required to run the schedule" — the mechanism behind suppressing a later register for a group that has not deposited; Night opens only when the nightly radio is chosen, Date only when the date radio is chosen.

Operating pattern as documented (User Guide ch. 5): "the register process runs every Monday through Thursday night, with checks printing the following day. Check registers run for different groups each night. They currently work in pairs of two. Monday is the first register for Pittsburgh and Chicago and Wednesday is the second register. Tuesday and Thursday are the first and second runs respectively for Cleveland. Each group produces a register on their first scheduled night." Accounting disables the standard schedule and substitutes a special one for holiday weeks, client requests, or when two days' runs must be combined; registers may also be run on request in real time. Office and region assignments are explicitly volatile — the guide notes they "may vary slightly from week to week".

The run radio group in code offers nightly and specific date only. The user guide (ch. 5) describes a third option, an Immediate radio button ("run on a nightly basis (a recurring schedule), on a specific date (a non-recurring schedule), or immediately") — discrepancy for SME confirmation.

Create Schedule Components — funding/w_fund_schedule_component

• Title: "Create Schedule Components".
• Purpose: Define one schedule component (window comment).
• Business purpose (User Guide ch. 5): a component is an arbitrary scheduling entity — "take the enrollment structure for a group or several groups and create an entity to which a schedule can be applied. The scheduling entity could be all the groups in Cleveland, all the groups in Pittsburgh and Chicago, or just a single division of one group." Components deliberately cut across the funding and enrollment hierarchies: the guide's example groups Cleveland, OME-RESA and FOSECO together purely because their registers must run at the same time.
• Operator procedure (User Guide ch. 5): enter a Description (the component's name) and a Run Type ("such as Claims, Holiday, or Special"); explode the funding tree in the Groups panel; drag the wanted groups or divisions into Component Groups; then select fund pages for those groups in the Component Funds panel. "Once a schedule is attached to the component, the funds will be disbursed to the associated claims when that schedule is triggered."
• Fund-page selection semantics (User Guide ch. 5): pages are specified generically by type, not as specific pages — the user cannot differentiate between two Claims Reserve pages. "If no fund page types are specified, then all fund pages will have a check run when the schedule is triggered for this component." Selections are not validated against the component's groups: "If a fund page is specified for a group that the group in the component does not have, nothing will happen for that group when the schedule is triggered."
• Field groups: component name and run type (d_fund_component over sched_comp, run type from dddw_fund_run_types = codes RUNTYPES); group tree pickers (d_fund_base_groups, d_fund_heirarchy_v2, bank-account groups d_fund_bank_acct_grps); included groups (d_fund_component_groups over grp_sched_incls); fund page codes (d_fund_component_fundpages over grp_sched_funds, codes via d_fp_codes); fund page/coverage context (d_fund_fundpage_list, d_fund_fundpage_coverages); global exclusions (d_fund_grp_excludes over funding_group_excludes); user-class check (d_fund_security_users).

Vendor Quick Add — funding/w_fund_vendor_quick_add

• Title: "Vendor Quick Add" (response window).
• Purpose: Add or edit a vendor inline from check-writing screens (window comment).
• Field groups: vendor info (d_fund_vendor_info_quick_add over vendors): name, lookup name, TIN, TIN type, client segment, "Produce 1099?" checkbox (irs_1099_flg, defaulted N for new funding vendors); address (d_fund_vendor_address_quick_add over pm_addresses): addr1/2, city, state, zip, country.
• Opens: funding/w_fund_vendor_select_quick_add when a name search matches multiple vendors (d_fund_vendor_select).
• Why it exists inline (User Guide ch. 5): on the manual-check screen the payee line has a type-ahead, and "If the payee is not already in the table, the user will have the ability to add a vendor" — hence adding a vendor mid-check rather than leaving the check screen. The "Produce 1099?" flag matters because "If taxes are paid, 1099's will be generated based on the benefit payment's payee."

Selector response windows

Window	Purpose
funding/w_fund_group_select	Pick a group (d_fund_group_select) for u_fund_group_enter
funding/w_fund_bank_acct_select	Pick one of a group's bank accounts (d_fund_bank_acct_select)
funding/w_fund_check_select	Pick a logged incoming check when several qualify (d_fund_check_select over check_log). Per the guide this is the fund-source picker: when a check is the fund source and Retrieve is clicked, "a listing of all the checks received but not deposited will appear" — checks logged with status "No Action Yet Taken" (User Guide ch. 5)
funding/w_fund_deposit_locked_claims	Show claims locked by other users during funding; print list; continue or exit

Database-enforced constraints noted by the guide

The user guide states that the fund-page coverage-uniqueness rule (no duplicate coverage type on one node; no All page alongside another page at the same level) "will be enforced by the database", while the "every group has at least one Claims Reserve page" rule is enforced by the application (User Guide ch. 5). Any Oracle-side constraint or trigger implementing the first rule is outside the PowerBuilder extract and must be recovered from the schema before migration.