Skip to main content

Screen catalog: group maintenance (client) and sales reporting (sales)

Significant windows only; pure ancestor/response shells are noted in passing. Citations are library/object.

client/w_client_enrollment — Client Enrollment browser​

  • Purpose: entry point to identify a client group for Add / Modify / View; shows basic client info, sub-groups, and contacts (window comment).
  • Field groups: search fields (Group ID, Group Name, Contact Last Name); "Current Group" summary (d_client_group_info_display); Sub Groups list (d_client_sub_group_ids); Contacts list (d_client_group_contacts_rpt).
  • Actions: New → opens Group Maintenance in ADD mode (pfc_new → wf_open_group_detail("", "ADD")); select group → opens in CHANGE or DETAIL mode (wf_detail_mode). Search by name uses d_client_group_select (LIKE on group_name_cap, security-filtered); search by contact uses client/w_client_group_select_by_contact.
  • Opens: client/w_client_group_select, client/w_client_group_select_by_contact, client/w_client_maintenance (via pass-parms).
  • Operator procedure (User Guide ch. 2): "All access to the client Maintenance window begins with the tree structure in the Groups section." A group is selected either by clicking it in the tree or, "if the precise identity of the group is known", by typing the group number or group name into the Current Group section; either way the rest of the Current Group fields populate. Parent and sub-group fields are navigation shortcuts — clicking one makes it the current group and refreshes the window, and "This will not change the parent/child group relationship." Everything else in this section is display-only. The tree can be shown by group number or group name (group number is the default). An action button must be clicked before navigating: "When a user navigates between parent groups and sub-groups, the action specified when one of the six activity buttons was clicked then applies to the newly selected group."
  • Button semantics (User Guide ch. 2): New Group adds a sub-group of the entered group and "will inherit selected options of it's parent group by default"; Edit Group allows all data to be altered "except 'Group ID'"; Query Group is display-only but keeps parent/sub-group navigation; Delete Group — "This option will only granted to a few users." The guide also describes dragging groups within the tree to move them in the hierarchy, and a "Print Group Contact Report" on the Edit menu "which prints all authorized contacts for that group (and divisions of that group)".
  • Where to look for a given fact (User Guide ch. 2, Donna Harvey's notes): "You should always look at the division level first. If the information is not at the Division Level, look to the Master Level." At the time of writing "most company information is maintained at the Master level", with a handful of named exceptions.

client/w_client_maintenance — HOMER - Group Maintenance​

  • Title: "HOMER - Group Maintenance (group-id) (Edit Mode | View Only Mode)".
  • Purpose: the master screen for everything a group owns; five tabs.
  • What client maintenance is (User Guide ch. 2): "Client Maintenance is the activity of entering group level information into the system. All data entered here describes the business rules and the parts of the client's corporate structure that effects claims processing." The client entity is the group, divisions are sub-groups, departments are sub-groups below those.
  • The four structures and the CLIENT MASTER GROUP (User Guide ch. 2) — the concept behind parent_group_id, funding_parent_group_id and the master-group flag: "There will exist, for each client, four distinct structures of group and sub-group relationships. These are
    1. Client Maintenance Structure 2) Claims Structure 3) Billing Structure 4) Reporting Structure." Each is normally set up by a different functional area, and only the Client Maintenance structure is required to add a client — the rest follow later. But the top of all four must agree: "There will always be a single highest level group, called a CLIENT MASTER GROUP, for each client under which all of the client's sub groups are subordinate… A CLIENT MASTER GROUP must be consistent across the four structures discussed above. There cannot be a different CLIENT MASTER GROUP for each structure." Above it sits an even higher SFPI or M3 master group. The defining test: "The CLIENT MASTER GROUP is defined as the highest level group across all of a client's structures under which members may transfer between sub-groups without changing member numbers."
  • Enrollment depth rule (User Guide ch. 2): "It is imperative to note that members may only be enrolled into sub-groups which have no subordinate sub-groups. In other words, members may only be enrolled into the lowest sub-group levels."
  • Informational groups (User Guide ch. 2): "'Informational' groups are for SFPI/M3 purposes only and do not reflect the client's corporate structure in any way." When the informational flag is set, "only current group, group name, parent group, and sub-groups will be displayed".
  • Master-group flag interlock (User Guide ch. 2): "If Master Group checkbox is unchecked then TAB page Categories is disabled. Master Group checkbox cannot be unchecked if Categories exist." (Matches wf_set_cat_tabpage.)
  • Inheritance (User Guide ch. 2): "Client Maintenance options for all groups will be inherited by the sub-groups… unless specifically overridden or declined at the sub-group level. As a group is added, the system will check to see that a parent group exists, if so, options will be filled in on the sub-group's Client Maintenance windows based on the parent's options. Whenever a new parent group is added or a group having sub-groups is altered, the system will ask if the changes should be applied to the sub-groups." The confirmation list is pre-checked "to the specifications from the most recent inheritance triggered changes" (all checked when there is no prior inheritance history) and the user unchecks exceptions. On a new group, "a minimum of 2 items can be input by user to activate the inheritance window".
  • Tab: Information — Group Information (d_client_group_info_new + d_client_group_info_new_ext): group id, name, parent group, master-group flag, informational flag, phone/fax, tax id, address (standardization via d_std_address and wf_stand_addr), eff/exp dates + exp code (code table GRPEXP via dddw_client_group_expired_code; exp code required when expiring — wf_validate_exp_code), eligibility waiting period (type / units / length / from), external carrier ids (ELR, CONTROL, SUFFIX, ACCOUNT, ACCOUNT NAME, PLAN NO). Group Contacts (d_client_group_contacts_edit): category (code table CONTACT, ordered by display sequence), position, title, name, phone + ext, e-mail, comments, confidential indicator, address per contact. (User Guide ch. 2) Contact Category is "SFPI/M3 description of a client contact" and Position is "Position that a client contact holds with their company" — the two are not the same field in intent. The contact categories maintained in practice are Bills, Broker, COBRA, Confidential Contact, Enrollment, Executive, ID Cards, Miscellaneous, Registers, Sales Rep and UR/CM. Contacts are held at whichever level actually differs: a master group may carry only the Executive contact because it is common to all divisions, while Enrollment contacts sit on each division. Address handling: "USA is a checkbox. If no checked; city, state and zip are replaced by a single 'postal code' field", and there is "One address per contact".
  • Tab: Enrollment — Enrollment Options (d_client_group_enroll_opts, code table ENROLL, effective-dated); enrollment/flex periods (d_enrollment_periods, retrieved for period types ENROLLMENT and FLEX; "extend to divisions" copies a period row to every sub-group — event ue_extend_to_div); Group Options (d_client_group_options: typed option values per GRP-12). (User Guide ch. 2) Enrollment options are "group level options regarding individual members of the group"; the Option Periods rows are a filter, not decoration — "The Option Periods section controls which set of options are displayed in the Options section. Options are valid over specific periods of time." Editing is deliberately restricted once committed: "Once an Option is added and saved, only the expiration date can be changed or the record deleted." Flex/enrollment period procedure: "At the master group level, right mouse click and add a row", then set the period's effective and expiration dates and the begin month/day and end month/day of the flex window; "The extended year flag is set when the end month is set to mean greater than 12 months"; and "The extend to all divisions box can be checked only at the master level. This will copy the current flex period to all of the divisions under this master group."
  • Tab: Coverages — coverage list (d_client_group_coverage_display) and "Coverage Options (required information)" detail (d_client_group_coverage_opts_new): coverage type (from coverages), plan code (from benefits), description, seq no (auto: max+1 — wf_set_seq_no), eff/exp/run-out dates, waiting period (type/units/length/starts — code tables), salary-based amount fields (multiplier, increment, min/max/default, rounding type ROUNDTYP, round-to amount), ID-card form numbers (front/back/all), COBRA info, tax status, member-coverage applied code (MBRCOVAPP), required flag, applied-to-members date and unapplied-change flag. (User Guide ch. 2) Group coverages "define what coverage(s) are available to a group"; only coverages defined under Plan Design are selectable and "A new coverage can only be added to the system through Plan Design". Assigning a coverage also requires a benefit plan, which is why plan status matters here: COMPLETE — "claims may be adjudicated using the plan"; INCOMPLETE — "claims will hold in adjudication status until plan is completed"; NONPROCESS — "valid for election purposes only, and we do not process these claims"; VOID — "not valid for any purposes". Naming a new plan on this tab "should trigger the automatic creation of benefit plans with an 'Incomplete' status", after which plan design staff build it out and flip the status to COMPLETE. Coverages that are never adjudicated — Life, AD&D, LTD, SupLife — are marked NONPROCESS automatically, because "adding a coverage to a group also requires a Benefit Plan be assigned (to support enrollment)". The applied-to-members date and unapplied-change flag exist to defer member updates: when a coverage is discontinued "members of that group will each have the discontinued coverage expired within the enrollment tables", and "the user will be presented with the option to update the members immediately, or defer making the changes to the enrollment tables during the nightly processing at a later date. Updating large numbers of members immediately will consume a large amount of computer resources and should be discouraged." Immediate application "call[s] a database function (stored procedure) to update the members and set the applied_to_member_dt column to the current date" (see migration note below).
  • Tab: Categories — Standard Categories (d_client_group_mbr_categories, joined to general_cat; applied code MBRCATAPP, value-saved-as VALSAVED), Non-Standard Categories (d_client_group_mbr_new_categories), Category Values (d_client_category_values over grp_mbr_cat_val). Master groups only (wf_set_cat_tabpage); date changes validated across the master group (wf_check_cat_eff_dates / wf_check_cat_exp_dates). (User Guide ch. 2) "The Member Categories section defines the types of members that are valid for the current group for the time period specified by effective and term dates. Terming a date will effect all members of the current group. The system will ask the user whether to term immediately or defer processing until a later date." The Values section "defines the valid values that may be selected for each type of category defined in the Member Categories section", and its content changes as the selected category changes. Category rows also carry an Applies to ("All, subscriber, or dependent") and a Required flag ("Is this optional category mandatory for all subscribers"). Categories are what "fills in the variable information in the Subscriber Information section of the Enrollment maintenance window's Eligibility TAB".
  • Tab: Coverage Eligibility — (d_client_grp_coverage_eligibility_rules over grp_covr_elig_rules): coverage type + plan code restricted to member category / value pairs, effective-dated.
  • Also on the window: client segment assignment (d_client_client_segment), group summary (d_client_group_info_summary), sub-group list (d_client_sub_group_ids), VIP/notes indicators (wf_check_notes, wf_set_vip_notes).
  • Validations / behaviors: unsaved-change prompt on group switch (ue_retrieve_windows); country verification (wf_verify_country); group id and parent id verification (wf_verify_group_id, wf_verify_parent_id); auto security rows on new group (wf_add_security, GRP-5); expiration-date text colored via f_set_text_color.
  • Opens: client/w_client_copy_group_info (copy from parent), client/w_client_grp_chg_prop_hist (propagate to children — see Open question 1), w_select_enroll_options.

client/w_client_copy_group_info — HOMER - Copy Group Info​

  • Purpose: choose which settings of a parent group to copy to a child group.

  • Fields (d_client_copy_group_info): checkbox + source group + effective date for Info, Contacts, Enrollment, Group Options, Billing, Coverages, Categories, Eligibility. Categories protected unless source is a master group. Changing one effective date syncs the enrollment/coverage/category/eligibility dates.

  • Validation: source group id validated via u_app_sql.uf_validate_group_id.

  • Actions: OK invokes the parent window's copy functions (wf_copy_group_info, wf_copy_contact_info, wf_copy_enroll_info, wf_copy_group_opt_info, wf_copy_coverage_info, wf_copy_cat_info); the eligibility copy call is commented out.

  • Guide description (User Guide ch. 2, "Client Inheritance Window"): the window "will have six checkboxes each attached to (1) General Information, (2) Contacts, (3) Enrollment, (4) Coverage, (5) Categories and (6) Eligibilities. These checkboxes will specify which of the appropriate data from the Master Group will be copied down to the new group." The effective-date behavior matches the code: "If no effective date was chosen then the Master Group's effective date will be used. Changing any of the effective dates will change all of them." The code's list carries eight rows — it adds Group Options and Billing to the guide's six. The user guide (ch. 2) lists only six copy categories — discrepancy for SME confirmation (most likely the guide predates the Group Options and Billing additions).

  • Inheritance is a copy, not a link (User Guide ch. 22): "although we call this functionality 'inheritance', it is not true inheritance in the strictest sense… we duplicate the information inside each object. Addresses in our system are the only objects that are truly inherited." Two further rules bear on this screen: "Deletions of rows are not part of inheritance. If you want to delete rows, you must delete them manually from all levels", and changes to a table's key never propagate as updates. Pushing down is a two-list choice — inheritance sets by descendant groups — and "all the inheritance sets selected will be pushed to all the descendent groups selected". The inheritance rules themselves are not table driven: "We will not be table-izing the rules for inheritance. They will be hard-coded within the application."

  • Two hierarchies, one set of endpoints (User Guide ch. 22): attributes belong to either the Client Maintenance hierarchy or the Funding hierarchy (addresses to the former), and "Both hierarchies must share 'top' and 'bottom' levels." Groups added through Funding cannot be master groups or bottom groups; a group added through Client Maintenance is recorded so that "Funding users [are asked] whether to copy changes into the Funding hierarchy when they access the group".

client/w_client_grp_chg_prop_hist — HOMER - Group Change History​

  • Purpose: select which child groups should receive changes made to the parent (window comment). Lists direct children with an Include flag, pre-checked when a grp_chg_prop_hist row exists for the parent/child pair.
  • Actions: Select All; Apply recursively walks each selected child's subtree — but the apply body contains only a placeholder comment ("apply changes to as_group_id here"). See Open questions.

client/w_client_group_select / w_client_group_select_by_contact​

  • Purpose: response pick lists of groups (optionally with contact columns), security-filtered by the requesting user's classes (d_client_group_select, d_client_group_select_by_contact).

client/w_client_term_group — Term Groups​

  • Purpose: terminate a group (subtree) or drop a single coverage type; also a "term members" path for member-level termination.
  • Fields: group id (u_fund_group_enter), termination/exp date, run-out date, reason (ddlb_exp_cds from eligibility exp codes dddw), coverage type selector (d_benefit_coverage_type incl. an "<All>" row).
  • Validations: reason required; multi-step confirmations; member-level blocks (GRP-18 / GRP-19); final "will take hours to undo" warning.
  • Actions: coverage drop updates group_coverages across the subtree; full term calls term_groups_master / term_groups_division; member term deletes future-dated and expires current elections / election_coverages or calls term_members_master / term_members_division; report button prints affected members (d_client_term_group_report).
  • Who may use it (User Guide ch. 2): "Only those with Office Enrollment Managers, Office Managers, MIS or developers class status are allowed to access this window. This window works on both the master and divisional level of a group, as need be."
  • Operator procedure — drop a single line of coverage (User Guide ch. 2): enter the group id (the division's id to affect only that division, otherwise the master) and run Group Search; enter the Term Date; enter the Run Out Date if run-out applies; select the termination reason in the top drop-down; select the coverage type in the bottom drop-down (the system then asks you to confirm you mean only a single line). Then Terminate Members — "this will terminate all active members in that group who have the selected type of coverage who had coverage start before the given date … and delete all records of those who have the selected type of coverage who had coverage start after the given date". Then Terminate Groups — terminates the group coverages "with the run out date, or if no run out date exists then the term date will be used". Both buttons "ask you four times for verification, please read carefully to be sure what you have entered is correct".
  • Operator procedure — terminate an entire group (User Guide ch. 2): identical, except the bottom drop-down is left at "All". Terminate Members then terminates every active member starting before the date and deletes every member starting after it.
  • Ordering guard (User Guide ch. 2): "This process will not commence if any members are found in the selected group who still have the selected type of coverage active" — members must be terminated before groups, which is why the two buttons are separate and ordered.
  • Termination and run-out semantics (User Guide ch. 2): "Terminating a master group implies that the divisions are terminated. Groups are terminated the day after the date entered as the EXP date at the group level." "Groups cannot be terminated unless all coverages in that group are terminated." Run-out rules: "There is no run out when the Group Coverage EXP date is the SAME as the run out end date"; "A run out end date for a Group Coverage with no EXP date is meaningless"; "Null run out end date for a Group Coverage with an EXP date signifies infinite run out."
  • Termination does not stop claims (User Guide ch. 2): "if a claim comes in after the group has terminated, for services incurred during a valid election period for a member, the system WILL process that claim just like the Wang did." The guide suggests audit rules as the means of keeping such a claim out of funding. Plans and packages are deliberately not terminated — "the loss of eligibility should be enough. (Packages are reusable across plans and groups)."
  • This screen is one step in a much longer manual procedure (User Guide ch. 22, "Terminating Clients"). The documented company-wide sequence is a chain of human handoffs: update the tracking spreadsheet; produce the enrollment and accumulator files for the client; notify the PPO/HMO, the EDI companies, the drug companies and the stop-loss carrier; remove the examiner from the case at term (or run-out) date; begin printing and deleting claims; confirm the final bill is paid; terminate the members (Enrollment); and only then "terminate[] the group in client maintenance, making sure to set up runout period if appropriate" — this screen. Two steps after that are automatic: the system "will begin flagging claims with 'should be returned' message", and "System begins deleting claims for terminated clients six months after the termination date (or runout end date) is reached." The guide leaves three questions open: "How to handle unpaid bulk drug? How to handle unbilled UM fees? How to handle claims in funding that were not yet paid?"

client/w_carrier_maint / w_carrier_select — Stoploss Carrier Maintenance​

  • Purpose: maintain stop-loss carriers (d_new_carrier over carriers): code, name, display name, contact, phone/fax/e-mail, active and waiver indicators, address (standardized via d_std_address). w_carrier_select lists carriers for selection.
  • Why carriers are a first-class entity (User Guide ch. 17): "The clients contract with a Stoploss 'carrier' directly and SFPI/M3 oversees the financial and data exchanges between the client and the carrier." Specific and aggregate stop-loss "each will have its own premium and each premium may be paid separately if they are held by separate carriers", and "The system will provide the ability to enter the carrier name, which may be different for specific and aggregate" — hence carriers are selected per contract rather than per group.
  • The waiver indicator (User Guide ch. 17): not every carrier supports waivers. The guide records a client "who requires waivers, but the carrier doesn't support waivers", for whom SFPI "makes fake deposits in the accounting system in order to generate EOB's [then] holds the checks from mailing out, waits for the stoploss carrier … to remit their money and then release[s] the checks." The guide also asks for a carrier-level flag for whether "the carrier require[s] notification at 50%".

client/w_member_waivers — Member Waivers​

  • Purpose: record stop-loss waivers for a member (d_member_waivers over stoploss_waivers): waiver from/through and incurred from/through dates, created-by.
  • Behavior: member chosen via d_member_list; the stop-loss year is located from the group's group_stoploss_parms, falling back to the master group when the division has none (messages in source); period selection via client/w_stoploss_period_select (d_contract_picklist joins group_stoploss_parms to carriers incl. waiver_ind).
  • Opens: client/w_stoploss_period_select. Entry via client/w_member_waiver_select (inherited from enrollment select).
  • What a waiver is (User Guide ch. 17): "Waiver is the portion of a claim remaining when a client only wants to pay up to their specific deductibles. Waivers only apply to Specific Stoploss. At this point, the client stops funding that member." Operationally the client chooses between paying the claim immediately and waiting for reimbursement, or holding "the balance of the original claim over the deductible amount until the Stoploss reimbursement comes in to fund the claim (This is a waiver)". Chapter 5 adds the funding-side consequence: "The Batch processing for funding will prohibit funding of claims on waiver. Processing will require the waiver to be manually removed in order to be funded."
  • Why the screen carries both a waiver period and an incurred period (User Guide ch. 17): waiver status attaches to the member for a span, not just to a claim — "we can say that a member is in 'waiver', and some of his claims are also in 'waiver'". "When a member/family is put into waiver the system should generate the waiver period as being through the end of the stoploss year. So, when TLO kicks in the system will have to check member/family and bump up the ending waiver period to the new TLO ending date."
  • Manual and automatic waiver (User Guide ch. 17): "Stoploss staff will manually put payments (or parts of payments) into waiver status. The system will then automatically put the member/family into waiver. Stoploss staff will also be able to manually put members/families into 'waiver'. When a member/family is manually put into waiver all stoploss eligible unfunded payments currently in the system will automatically be put into waiver at that time." Thereafter, "As claims transition out of Adjudication, and become payments in Funding, the system should check to see if the member/family is in waiver. If so, automatically put the payment into waiver." Whether to waiver the subscriber, the dependent or both is read from the group's stop-loss parameters' single/family handling. Two hard limits: "The system must not allow waivers for Aggregated Specific Stoploss claims", and "Claims do not come off waiver until they have been funded."
  • Which plan year a waivered claim belongs to (User Guide ch. 17) — the rule behind resolving a waiver against group_stoploss_parms: "If the member is not in waiver, use paid date to determine plan year. (If on 12/31 a claim is processed that would throw the member into waiver, a check run must execute prior to 1/1.) If a member is in waiver, use the date that the claim became eligible to appear on a register to determine the plan year."

client/w_stoploss_group / w_stoploss_contract / w_stoploss_period_select​

  • Purpose: pick a group and view its stop-loss contract information; the period response window shows contract periods (d_sl_periods), eligibility groups (d_elig_groups — distinct groups from member_eligibilities for a member and year), and the group hierarchy (d_heirarchy).
  • Why contract periods are a pick list (User Guide ch. 17): carriers are selected "for a length of time. This would normally follow plan years, but is left up to the user so that we can handle clients that switch carriers during a plan year." The entry rules are "User must always enter start date" and "User must enter an end date and a termination reason before adding additional carriers", so a group accumulates a dated sequence of contract periods. Stop-loss years correspond to plan years and are held in the group periods table, "date ranged, and only expire when the user enters a termination date for that Stoploss row". Overlap resolution: "If the date ranges in two Stoploss years for a single client overlap, then the system will always choose the set of parameters with the most recent Stoploss year."
  • Termination reason drives TLO (User Guide ch. 17): "Users will trigger TLO by entering the appropriate termination reason when Stoploss Termination dates are put into the system. If the termination reason entered indicates that carriers have been changed or the case has been terminated … then the system will add units to the ending paid date. If the termination reason entered has changed from indicating that … carriers have been changed or the case has been terminated then the system will subtract units from the ending paid date." Note the countervailing rule: "Changing carriers or terminating the case in the middle of a Plan year must not trigger TLO."

client/w_client_census_rpt_args_sheet / w_client_census_rpt_display​

  • Purpose: parameterize and display client census reports (d_client_census_rpt_select; census DWs cover carriers, group contacts, coverages, enrollment options, option values, member categories — e.g. d_client_census_group_option_vals resolves typed option values as of a run date).

client/w_caremark_group_setup — Caremark Group Setup​

  • Purpose: "Create Matria Claim Files" (window comment) — build a vendor accumulator extract for a group: run date, deductible / OOP accumulator codes, and per-tier amounts (spouse/deps deductible and OOP fields). The window comment appears to be copied from the Burns/Matria extract windows; the user guide documents this screen as CareMark-specific — see below.
  • Business purpose (User Guide ch. 2): "This window is for setting up a group who has taken a linked drug/medical plan directly connected with CareMark." The accumulator amounts entered here are what the downstream flag file report matches against.
  • Adding a group not previously set up (User Guide ch. 2): enter the group id and press Group Search; enter the start date of the CareMark association; enter the OOP and DED amounts in the matching coverage-level / accumulator boxes; set the Embedded checkboxes — leave them unchecked when the group's accumulators are linked, meaning the flag file report "will first check the Single amount to see if the member has met that accumulator and if not then checks the Family amount to see if the family has met that accumulator", and check them otherwise; then Save As.
  • Why Save As writes to client maintenance (User Guide ch. 2): saving "will add the necessary group option value to client maintenance on both the master and divisional levels (in client maintenance the group option value will be CVS; never directly tamper with that value, always change values through this window)". This is the coupling between this screen and the Group Options grid on w_client_maintenance.
  • Master versus divisional level (User Guide ch. 2): accumulator codes are maintained at the master level (where "All OOP and DED maximum values as well as the Embedded check boxes will be grey-ed out as they have no meaning on the master level"), and accumulator amounts at the divisional level (where the accumulator code boxes are greyed out).
  • Two data-entry traps (User Guide ch. 2): "Even if there is no difference between a Family accumulator amount and a n-tier accumulator amount it is still necessary to re-enter that amount into the tier's entry box as the flag file report still wants to match against that tiers accumulator amount (only for when the Embedded box is checked)." And: "If there is no OOP (as the plan pays 100% of drug after DED has been met) just leave all OOP fields blank or at 0."

sales/w_sales_report_wizard / w_sales_report_sheet — Client reporting wizard​

  • Purpose: standard wizard for the sales reporting suite: pick a report type from report_info (d_sales_report_select), select groups (u_sales_wizard_group_select) and parameters (u_sales_wizard_clntbased_parm_select), then render in w_sales_report_sheet. Report engines: n_cst_sales_reportobject*, client-based builders for paid claims, lag triangles (n_cst_sales_clntbased_lag_triangle), and IBNR (n_cst_sales_clntbased_ibnr).

sales/w_sales_rpt_group_claim_detail — Detailed Claims Listing​

  • Purpose: "Detailed Claims Listing. Run by selected group, type of claim, and paid date range" (window comment); variants with discounts, line data, payment data, rule data, and a confidential version (its 9 d_sales_rpt_* DataWindows).
  • Opens: w_group_response_selection (group picker).

sales/w_sales_benefit_category_maintenance — Benefit Category Maintenance​

  • Title: "Benefit Category Maintenance for Segment: …".
  • Purpose: assign benefit definitions to report service categories per client segment and report type. Available definitions (d_sales_ben_cat_maintenance_available) vs chosen (d_sales_ben_cat_maintenance_chosen — definitions in rpt_svc_cat_defs for the selected rpt_svc_cats row); category picker (sales/w_sales_ben_cat_maint_category_select); report types dddw (dddw_sales_ben_cat_maintenance_rpt_types).