Oracle® Insurance Rules Palette 10.1.2.0 E59346-01

Overview of Screen Rules

Screen rules are used to control the display of screens in OIPA. Screen rules exist as global rules but can be overridden to meet the needs of individual plans. Global screen rules are located in the Global Explorer tab in the Business Rules folder. Any overrides (except company level overrides) created will be stored in the Main Explorer tab under the Company | Plan | Business Rules | Screen node.     

Most screen rules are configured using the XML Source pane. Visual editing is not available for these rules at this time. An explanation of each rule is provided below. There are two exceptions: RoleScreen and CompanyScreen. These two rules can be configured using visual editing tools.     

Please see the XML Configuration Guide topic in this help system for a complete list of all elements, attributes and values needed for Screen rule configuration. View Business Rules | Screen Rules. 

Screen Rules

ActivityRequirementScreen: The ActivityRequirementScreen business rule must be configured in order for OIPA to handle requirements properly. This rule will need to be configured as a screen rule. The global rule should only have an empty opening and closing tag. The actual rule is configured as a company level override.    

ActivityResultsScreen: This rule defines the configuration of the Activity Result screen in OIPA. The screen displays when the Activity Detail icon to the left of a processed activity is clicked. Configuration allows the user to control whether parent and/or child funds display and whether the original allocation amount displays. The rule should be overridden at the transaction level if either one of these display enhancements is required. If one or both of these display enhancements is needed, the rule configuration should be updated to reflect the display required and should be attached to a specific transaction. A transaction override of the rule is not included in the TransactionBusinessRulePacket.

The Verification Screen provides a different view, completely configurable, with a section for allocation. The VerificationScreen makes the optional SHOWORIGINAL attribute available.

AddressScreen: This business rule allows the user to configure the non-fixed fields and validations for the address roles on the Address screen.   Fixed field values can also be controlled through configuration of this rule.  Mailing addresses can be set to expire based on date criteria and a contingent value established to introduce an active or inactive status. Configuration supports foreign addresses and dates. The AddressType is controlled by the AsCode table > AsCodeAddressType.

If phone number fields are required on the Address screen, then the <DisplayPhoneScreen>Yes</DisplayPhoneScreen> configuration must be present in the AddressScreen business rule.

An address change letter can be automatically generated when a change is made to an existing address. The Spawn IF logic will determine when and if a letter is generated. Configuration has the option to spawn a client level activity and create messages as needed through events/actions. To make use of this functionality the following configuration requirements must be met.

• The activity must be a client level activity.
• Spawning is only available from the Address screen.
• The only spawn code supported is 03.

Refer to the Address Change Letter Prototype for configuration steps to accomplish this task.

Agreement Screen: The Agreement screen rule allows the user to configure the Agreement Screen on the Group Customer navigation options to either show the summary level Group Customer information or skip it and also define the number of levels of agreement hierarchies to be displayed ONLOAD.

AgreementRoleScreen: This rule allows the configuration of agreement roles as they relate to a specific Agreement Role Type (AsCodeAgreementRoleType). This includes the configuration of fields or field subsections specified on the Agreement Role Details tab for the Agreement Role screen in OIPA. Each agreement role, such as a Contact, Administrator, Bank Representative or TPA resource, can have configured fields for capturing relevant data required by the business. 

• The TYPECODE attribute defines the role types that are available as an agreement role. If this attribute is not present in the <AgreementRole> element, then roles cannot be added to the agreement.

• The ALLOWGROUPCUSTOMER attribute controls whether the Find Customer tab displays at the top of the Add Agreement Roles window. The Find Customer tab will appear on the screen if at least one of the agreement role types has this attribute set to Yes. Only the agreement role types that have the attribute set to Yes will be available in the Agreement Role drop down list under the Find Customer tab.

• The DISABLEBYAGREEMENTSTATUS attribute restricts the use of a role by agreement status. Agreement statuses are defined in the Rules Palette in the Admin Explorer. Click Admin Explorer | Administration | Code Names | AsCodeAgreementStatus to add and update agreement statuses.

• A CLIENTTYPE attribute allows the role to be restricted to specific clients. This is a required attribute. If a client is not identified in this attribute, then that client cannot be associated with the role. Client Type drop down box for “The Find Client” and “New Client” are controlled by this attribute. If this attribute is omitted or no client types are defined for a particular role type, that particular role type will not be listed in the role type dropdown for New Client and Find Client tabs.

The AddAgreementRoles business rule can be attached to a transaction to add roles to agreements via activity processing.

AllocationScreen: This business rule defines the allocations that are assigned for the plan and policy. This rule does not have visual editing support and must be configured directly in the XML Source pane. It is used when configuring allocations using the default method.

Alternate Name Screen: This business rule defines an alternate naming convention for a Group Customer. The alternate name will be a field used when search criteria is entered for the Customer Search screen and can be used for identifying the Group Customer and additional information housed under the alternate name.

CaseScreen: This business rule allows a user to create and edit case records, part of the New Business Underwriting process. In OIPA, the Case screen is accessed by selecting Case from the Main Menu and clicking on New Case, or by selecting Search Case from the Main Menu, then searching for and selecting an existing case.

Information displayed on this screen includes the case name, case number, case status, creation date and date last updated, all of which correspond to columns within the AsCase database table. Additionally, dynamic fields can be configured to display other information on the screen. A case's status is represented by a two digit role code, and these role codes are defined in the AsCodeCaseStatus code name.

The screen has three sections:

• The Case General Info section displays the screen's fixed fields, such as case name and number.
• The Policy/Application Table section displays the table defined in the <Table> tags within the <Policies> tags of the CaseScreen rule.
• The Case Detail section displays the dynamic, configurable fields defined in the CaseScreen rule's configuration. These fields' values are stored in the AsCaseField database table.

Masking and field-level security is supported on the Case screen.

CaseSearchScreen: This business rule is used to configure the CaseSearchScreen, which allows an underwriter or CSR to search for cases or applications as part of the New Business Underwriting process. The CaseSearchScreen functions similarly to the Policy Search screen. The CaseSearchScreen's configuration defines the fields that are used to store the results of a case or application search. In OIPA, the Case Search screen is accessed by selecting Case from the Main Menu and clicking on Search Case.

The screen has two sections:

• The Case Search Criteria section contains the fields into which case search criteria can be entered.
• The Case Search Results section displays the results of a case search.

ChartOfAccountsScreen: This rule determines the set-up of the dynamic fields for the ChartOfAccounts screen (only for the criteria section) and determines how validation can be performed. 

ChildFundScreen: This rule has been deprecated as of the 9.5.0.0 release. Refer to the Child Fund page for information on setting up child funds.

Class Screen: This business rule defines the characteristics for each class within a Class Group. Information such as the class type, class name and class description displays as well as any dynamic fields captured at the class level. In addition, the screen provides a tabbed view that allows a user to drill down to the plans associated to each class (if applicable). Class rules and Class Rule Variables used for defining membership are also available on this screen. Any members enrolled in the plans associated with the class are available as well.

This screen rule has an upper section that allows for the display of Fixed Fields for class type, class name, description, and number of members. In addition, there are configurable dynamic fields to further define the class. The screen layout contains a subsection that can be expanded and collapsed by clicking on the section header for Class Detail and the expanded subsection tab will be highlighted in red. Tabs are available for Class Details, Class Plans, Class Rules and Class Members. Refer to Classes and Class Groups summary section and the Classes and Class Groups prototype example for understanding this rule in more detail.

Class Group Screen: This business rule defines the collection or arrangement of classes for the purpose of viewing and editing Class Groups. The Class Groups are arranged by type and can be copied and created in OIPA. The Class Group Screen also has options to define whether Business Statuss should be used for class group records and also to define the transaction that needs to be spawned in case a class group time slice is submitted. Refer to Classes and Class Groups summary section and the Classes and Class Groups prototype example for understanding these rule in more detail.

Client Relationship Screen: This business rule defines the primary and secondary relationships associated with a Group Customer. The screen provides the connection between a client entity through a primary relationship to the Group Customer. The relationship can be further defined by a secondary relationship type.  The optional <MaximumDuplicate> attribute specifies the number of times a relationship can be duplicated for a client. A validation will prevent the user from adding more than the maximum number designated and presents the user with the following error message, “Maximum count exceeded for this relationship.” If the <Maximum> attribute is not configured, then an infinite number of same client/same primary/same secondary relationships may exist for the Group Customer.

ClientScreen: This business rule allows the user to configure fixed and dynamic fields on the Client screen. A separate section is configured for each Client Type, which is identified by its typecode. This rule is also used to control the display of policy roles, individual fields, address table, the TaxID field on Client screen, and the process button for future activities on the Client Activity screen.   

Configuration supports the display of foreign calendars and dates as well as numerous formats of the client name. The LegalResidenceCode field and the TypeCode are the only required fields and they determine the display of all information on the screen.

If this screen is called as a result of the use of a client field in an activity, then it will display in a popup window. Security for fields and buttons displayed in the popup window tabs will be determined by the security established on the current Client screen.

The Spawn element can be used within Actions and Events to trigger the spawning of activities when specific fields are updated on the Client screen. View the prototype for configuration details.

There are some configuration considerations to keep in mind when working with the Client screen. In version 9 of OIPA, the ClientGUID is not an inherent GUID available to the fields section of the Client screen. This means that when a new client is created, a ClientGUID does not yet exist until after the Save button is clicked. If there are fields that require a ClientGUID, they can cause the screen to crash (stack trace) since the ClientGUID cannot be found. To avoid this situation, move any SQL in the field section that needs to resolve the ClientGUID into the Action/Event section for OnChange or OnSubmit events. The will insure proper screen results for a new client. This is not an issue for saved clients in the database since the ClientGUID already exists.

The Client screen controls several aspects of the Group Customer screen in OIPA. Within the <Client> element, several important attributes are:

• TYPECODE: one of two attributes used to identify the type of client. Values for this attribute are stored in AsCodeOrganizationType.
• CLIENTTYPE: the second attribute that is used to identify the type of client. Values for this attribute are stored in AsCodeClientType.
• ACTIVITYPLAN: used to tell OIPA which plan to use when the Group Customer screen is loaded. All activities configured on this plan will be available as Group Customer level activities in OIPA.
• RELATIONSHIPACTIVITYPLAN: used to tell OIPA which plan to use when the Relationship link is selected in OIPA. All activities configured on this plan will be available as ClientRelationship activities in OIPA. These activities must be configured as Client-Relationship transaction types in order to appear in the Client-Relationship activity drop down list in OIPA.

If phone number fields are required on the Client screen and Group CustomerScreen, then the <DisplayPhoneScreen>Yes</DisplayPhoneScreen> configuration must be present in the ClientScreen business rule.

ClientSearchScreen: This business rule defines the configuration for search criteria and fields for the Client Search screen. The screen allows the user to search on various client types such as Individual, Corporate or Producer. When the user enters this screen, the default search criterion is Individual.  

External clients can be searched from this screen in OIPA if the supporting configuration is added to this rule. The attribute EXTERNAL=”Yes” can be added to the <Client> section to indicate that the client type is external. The element, <ExternalClientSearchRetriever>, can also be added to the <Client> section of the ClientSearchScreen. This element defines how the client specific information is to be populated in the Client Search results when the user hits the Find button. This element contains a class name that implements an interface. The data retrieved is defined in the ExternalClientDetailScreen business rule

If this screen is called as a result of the use of a client field in an activity, then it will display in a popup window. Security for fields and buttons displayed in the popup window tabs will be determined by the security established on the current Client Search screen.

This rule will also allow use of policy and segment context variables providing POLICYGUID and SEGMENTGUID values for any search parameters. The PolicyGUID and SegmentGUID context variables will return appropriate values when there is a Policy and Segment context. In case there is no Policy context , the values will be returned as "Null" without any system error.

ClientSearchScreen BusinessRule works in three modes:

• Client Search under Client Context

• Find Client in RoleScreen (Policy and Segment Roles)

• Find Client in any Activities

In the RoleScreen FindClient context, the ClientSearchScreen will be able to access the POLICYGUID (both Policy and Segment RoleScreen)and SEGMENTGUID (only in Segment RoleScreen) fields using which other policy and screen field values can be calculated for search parameters. In other contexts, these two values will return “Null” in the ClientSearchScreen BusinessRule.

CommentsScreen: This business rule is used to configure OIPA's various Comment screens, which can be implemented for policies, segments, clients, activities and suspense records. Comments on these screens can use preset comment templates, which are configured with the Comment Templates node in the Admin Explorer's Administration folder, or can be completely user-entered. Comment templates can be implemented at the global, company, Product or plan level.

CommentsSearchScreen: This business rule is used to define the search criteria for comments and to configure the display of comment search results. It can be configured at the global, policy, segment, activity, and client levels, as well as for suspense records. In addition to containing fixed fields, the Comments Search screen can use dynamic fields to filter out specific types or categories of comments.

CompanyScreen: The CompanyScreen business rule must be configured before accessing the Company Data node in the Main Explorer. This business rule defines the fields that hold constant values related to a company. It should only be overridden at the company level. The XML Source pane can be used to configure the screen using XML.   A field defined as <DataType>Money</DataType> in the CompanyScreen business rule will display a currency field for entry in the Rules Palette CompanyData node.

DisbursementApprovalScreen: This business rule allows for the configuration of dynamic fields on this screen. These fields will be used to search for specific disbursements. The table section defines how the results are displayed to the user. The Disbursement Amount column can be totaled using optional configuration. Currencies must be of the same type. Mixed currencies will not total.

DisbursementScreen: This business rule contains the fields that display when the Disbursement link is selected in the Activity Results window.

DisbursementSearchScreen: This business rule is used to configure the dynamic fields in the DisbursementSearchScreen to allow the user to search for disbursement records that match the specified criteria. If the DisbursementSearchScreen business rule is not used the fixed fields will be displayed by default and used for searches. For example Company, Plan, Start Date and End Date will be displayed.    

The DisbursementScreen and DisbursementSearchScreen business rules together constitute the Disbursement screen. Configuration for the Disbursement Search section is done in the DisbursementSearchScreen business rule; whereas the configuration for the Disbursement details section is done in the DisbursementScreen business rule.   

Enrollment Screen: This business rule defines the enrollment processing for an eligible member to participate in coverage. The selections made within the Enrollment screen are for coverage, beneficiaries and dependents. The screen provides the ability to enroll the member into multiple coverages simultaneously as well as perform partial enrollment while saving the in-progress data for completion at a later time. Enrollment can be active and complete or pending and partially complete.

ExternalClientDetailScreen: This business rule holds the associated configurable fields for an external client. The fields defined in this business rule will be accessible through SQL. Specific external client information stored in the external database will not be accessible in the OIPA database.

Client details for a role may be configured in this rule. Role fields are configurable fields on the Role Screen business rule based on the role code. The Role Code for the External Client will be labeled as ‘External’. The field data is stored in OIPA’s AsRole and AsRoleField tables.

FundScreen: The FundScreen business rule can be configured to provide additional information for fund records. This rule defines whether there will be child funds and/or benefit funds. Parent and child funds are used when the same fund may be offered but there are different classes of the fund (versions, bands, groups, etc.). Extra fields can be stored at the parent and child level of the fund. Additionally this is where funds applicable to benefit split are determined as well.

This rule is overridden at the Primary Company Level and copybooks are not supported in this rule.

This rule must be configured in the XML Source pane.

If child funds or benefit funds are needed, the following attributes must be present in the <ChildFunds> element.

• ALLOWED: this is a required attribute that will accept a literal Yes or No with the default value being No. This attribute will indicate if child funds should be created from parent funds.
• BENEFITFUNDS: this is an optional attribute that will accept a literal Yes or No with the default value being No. This attribute will indicate if benefit funds should be created from child funds.

Group Customer Screen: This business rule is similar to the Client Screen, but pertains specifically to Group Customers. The screen allows for the addition or editing of Group Customer clients. The business rule can be overridden at the Primary Company level.

A complete explanation of the elements available for this rule is included in the XML Configuration Guide. An overview of the major elements is provided below.

• The TYPECODE attribute in the <PrimaryRelationship> element defines the primary relationship type from AsCodePrimaryRelationshipType.
• The secondary relationships that can be associated to the primary relationship are defined in the <SecondaryRelationships> section.
  • The <TypeCode> element has a VALUE attribute, which identifies the secondary relationship type from AsCodeSecondaryRelationshipType.
  • The <ClientTypeIdentifier> element is used in conjunction with the main level <ClientTypeIdentifier> element at the bottom of the rule. This element identifies the ID that should be referenced when determining the client types that can be assigned a secondary relationship.
• The <ClientTypeIdentifier> element at the bottom or the rule has an ID attribute, that corresponds to the <ClientTypeIdentifier> element above in the <SecondaryRelationship> secton. Match the value from the above <ClientTypeIdentifier> element to the ID to find the client type.
  • The <ClientType> element in the <ClientTypeIdentifiers> section holds the code that comes from either AsCodeOrganizationType or AsCodePersonType. Only client types defined in this element will be available to assign a secondary relationship.

Group Customer Search Screen: This business rule allows for the configurable search criteria in order to find the applicable Group Customer. The search can be filtered by selecting various criteria and selecting values for those criteria.

IntakeFileSearchScreen: This business rule allows the user to search for specific Intake Files. Search fields can be configured to be able to search on fixed and dynamic fields in order to narrow the results based on the search criteria. The rule also allows for configuration of a search results tables. The IntakeFileSearchScreen can be overridden at the global or primary company levels only. This screen contains several tabs that display various details pertaining to a selected Intake File:

• File Details: This tab displays an Intake File's status, received date, processed date and other basic information.
• Activity Math: This tab displays all of the MathVariables for the Intake File's Intake File transaction once the activity has moved to "Active" status.
• System Error: This tab appears when a system error is incurred during Intake File-level transaction processing, and displays an error table displaying the details of each error.
• Business Error: This tab appears when a business error is incurred during Intake File-level transaction processing, and displays an error table displaying the details of each error.

IntakeProfileScreen: The IntakeProfileScreen business rule allows for configuration of the Intake Profiles table via an optional table section, which has access to any combination of available columns from the AsIntakeProfile and AsIntakeProfileDefinition tables. The Intake Profiles table displays Data Intake Profiles for the current Group Customer. This screen also allows for the creation of Data Intake Profiles, although this functionality involves no configuration.

IntakeRecordSearchScreen: This business rule allows the user to search for specific Intake Records. Search fields can be configured to be able to search on fixed and dynamic fields in order to narrow the results based on the search criteria. The rule also allows for configuration of a search results tables. The IntakeRecordSearchScreen can be overridden at the global or primary company levels only. This screen contains several tabs that display various details pertaining to a selected Intake Record:

• Record Details: This tab, open by default, displays an Intake Record's status, record type, processed date, pre-processed date and other basic information.
• Activity Math: This tab displays all of the MathVariables for the Intake Record's Intake Record transaction once the activity has moved to "Active" status.
• Activity Sequence: This tab displays a hierarchical "tree" of activities generated by the Intake Record transaction for the selected Intake Record. Details pertaining to each selected activity on the tree of activities are displayed to the right of the tree.
• Record XML: This tab displays the received Intake Record XML configuration for the selected Intake Record.
• System Error: This tab appears when a system error is incurred during Intake Record-level transaction processing, and displays an error table displaying the details of each error.
• Business Error: This tab appears when a business error is incurred during Intake Record-level transaction processing, and displays an error table displaying the details of each error.

PhoneScreen: This business rule controls the configuration and display of phone numbers on the Phone screen when the PhoneNumbers link is click from the Address screen, Client screen and Group Customer screen. The <DisplayPhoneScreen>Yes</DisplayPhoneScreen> configuration must be added to the Address screen and Client screen to invoke this business rule.

The phone format is driven by the phone type and country selected in OIPA from the Phone screen. The PhoneScreen business rule defines all the possible phone type and country combinations using <Phone> sections. A default country and phone type can also be specified in the rule using the <DefaultCountry> and <DefaultPhoneType> elements. Use values from the AsCountry table for the default country and values from AsCodePhoneType for the phone type.

Each phone type is configured in a <Phone> section. The following elements apply to each <Phone> section.

• The <PhoneType> element has two attributes. VALUE is the code value and NAME is the short description of the phone type. These can be found in AsCodePhoneType. The <CountryCode> element should have a value from the CountryCode column of AsCountry.
• The <FixedFields> section contains the fields that are used to capture the phone information. Masks are supported as a field datatype. If a mask is used, it will control how the phone information displays as the user types it in. Masks are defined in the Mask editor of the Rules Palette.
• The <DisplayFormat> section controls how the phone number displays in search results and on screens in OIPA.

To view all the configuration steps required in formatting phone numbers, refer to the Group Customer Address and Phone Number page.

PlanActivityScreen: This Business Rule controls the Plan-Level Activity screen. The configuration will determine the number of activities that will be shown on the Plan-Level Activity screen, set the date from which to display activities and provide warnings when using activity icons. This rule may be defined at the Global level or as a Plan level override. 

PlanCoverageScreen:  The PlanCoverageScreen business rule allows users to attach sub-plans to a class. This screen is accessed by clicking on the Sub-Plan Details tab of the Class Sub-Plans screen. The only configurable aspect of this screen is the table in which the sub-plan records display. Refer to Classes and Class Groups summary section and the Classes and Class Groups prototype example for understanding this rule in more detail. 

PlanSegmentNameClassParticipantsScreen:  The PlanSegmentNameClassParticipantsScreen business rule controls the data that displays on the Class Sub-Plan Participants tab of the Class Sub-Plan screen. This tab displays data related to participants enrolled in a particular Sub-Plan. The participants that display on this tab are determined based on the policies that have a Class Sub-Plan with a segment role code indicating that the member is a sponsor. Refer to Classes and Class Groups summary section and the Classes and Class Groups prototype example for understanding this rule in more detail.

PlanSegmentNameClassScreen:  The PlanSegmentNameClassScreen business rule controls the configuration of the Class Sub-Plans screen, which displays the Class Sub-Plan associations for a selected class. The Class Sub-Plans screen is a tab of the Class screen, which is configured with the ClassScreen business rule. Refer to Classes and Class Groups summary section and the Classes and Class Groups prototype example for understanding this rule in more detail. 

PolicyOverviewScreen: This business rule is used to configure the PolicyOverviewScreen. This screen provides a read only summary of all policy details. It is the first option on the Left Navigation menu and is the default screen view when a policy is loaded in OIPA. Both fixed and dynamic fields from the PolicyScreen can be configured on this screen, as well as new fields, and CopyBooks are supported. All Data Types supported by the Field section of OIPA screen rules are supported in the PolicyOverviewScreen, with the exception of Client and Identifier types. Overrides of this screen are supported at the Global, Subsidiary Company, Product and Plan levels. Screen warning can be configured using Actions, Events and ScreenMath. On Load events for fixed and dynamic fields are also supported. Security is applied at the Plan Page level in the Admin Explorer.

The screen is divided into sections, the order of which is shown below and is set in base code. If a section is not present in configuration, then it will not display on the Policy Overview screen. If a user does not have access to the original page that corresponds to the section, then that section will also not display.

• Policy Details: This is the first section of the rule. If this element is present in configuration, but no fields are defined, then the section will appear, but will be blank. Fields seeking data outside of Policy (for example, Client, Segment, Address, etc.) will require a query to populate. For all SQL access, the PolicyGUID must be a known value on the screen. If you are configuring a policy field for display, no query is needed. The field configuration will carry the same field name and data type and will pull the value from the Policy screen. If the field value changes on the Policy screen, the same field value will be reflected on the Policy Overview screen. Field level security and masking are defined in the PolicyOverviewScreen rule and are not inherited from the PolicyScreen rule. Field names determine whether fixed and dynamic fields belong to the Policy screen. Values are initiated from the corresponding Policy fixed or dynamic fields.
• Policy Roles: The SHOW="Yes" attribute tells OIPA to display the Policy Roles section. All active roles will display. The <Message> element allows a configured message to be presented to the user on the Policy Roles section in OIPA.
• Segments: The SHOW="Yes" attribute tells OIPA to display the Segments section. All segment fields will be displayed. The <Message> element allows a configured message to be presented to the user on the Segments section in OIPA. If Segments configuration is not present, Segment Roles will not be available for display.
• Segment Roles: The SHOW="Yes" attribute tells OIPA to display the Segment Roles section. This section displays all information for segment roles that is configured in the SegmentRoleScreen rule. The <Message> element allows a configured message to be presented to the user on the Segment Roles section in OIPA.
• Values: The SHOW="Yes" attribute tells OIPA to display the Values section. The <Message> element allows a configured message to be presented to the user on the Values section in OIPA.

PolicyRequirementScreen: This business rule is used to configure OIPA's requirement summary table, which is accessed by clicking the Requirements link in the menu on the left side of the screen when an application or policy is open. If this rule is not configured, a default table will be used to display the requirement summary.

PolicySearchScreen: This business rule is used to configure the PolicySearchScreen. It defines the fields that are used to store the results of a search.   

RequirementResultSearchScreen: This business rule is used to configure the Requirement Result Search screen, which is used to search for requirement results and, if needed, match them to existing requirements.

SegmentRoleScreen: This business rule defines the dynamic fields that can be displayed and updated on the specified Role Detail(s) windows.  The segment selected during the policy entry process dictates which role options are visible and available on the Segment Role screen.  This rule exists at Global and Plan levels. Configuration should only create company level overrides of this rule at the primary company level.

SuspenseScreen: This business rule is used to create and control suspense records. Suspense records are used to track money. This business rule identifies where the money came from and allows for the money to be used as payment to various polices. A suspense record is used as a holding account until the money is applied or refunded. A unique suspense number is generated with the suspense record for identification purposes.

SuspenseSearchScreen: This business rule is used to configure the Suspense Search Criteria section and Results section of the Suspense Search screen. Fields from AsSuspense and AsSuspenseField tables can be used as the suspense search criteria, based on specific suspense records in the database. The Results section can be configured as is the case with other search screens, to present on the UI as a grid using standard table definition syntax. View prototype example...

UnmatchedResultSearchScreen: This business rule allows a user to search for unmatched requirement results and to manually match them to requirements.

WithholdingScreen: This business rule defines the layout of the Withholding screen, which signifies the amount or percentage of federal and state taxes to be withheld from taxable disbursements defined by the Policy Owner.