You are here: Global Explorer and Business Rules > Screen Rules > Overview of Screen Rules

Overview of Screen Rules

Screen rules are used to control the display of screens in OICE. 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

ActivityResultsScreen: This rule defines the configuration of the Activity Result screen in OICE. 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.

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.

The <Agreement> element has several important attributes.

The TYPECODE attribute defines the agreement type from the AsCodeAgreementType table.
The ROLETYPE attribute defines the roles that can be assigned to the agreement from the AsCodeAgreementRoleType table.
The PARENT attribute identifies the agreements that are children of another agreement.
- PARENT attribute with a value indicates that the agreement is a child of the agreement types listed. Ex: PARENT="01,02". The Add Child right-click option will not be available on the agreement.
- Absence of a PARENT attribute indicates that the agreement is a parent. The Add Child right-click option will be available on the agreement.
The ROOT attribute identifies agreements that can appear in the Agreement Type drop down box when a new agreement is added to a Group Customer.
- Absence of a ROOT attribute identifies that the agreement type can appear in the Agreement Type drop down box when a new agreement is added.
- ROOT="Yes" indicates that the agreement type can appear in the Agreement Type drop down box when a new agreement is added to a Group Customer.
- ROOT="No" indicates that the agreement type cannot appear in the Agreement Type drop down box when a new agreement is added to a Group Customer.

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.

CaseScreen: This business rule allows a user to create and edit case records, part of the New Business Underwriting process. In OICE, 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 OICE, 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.

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.

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 OICE, 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.

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 OICE 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

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 OICE'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, plan group 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.

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 OICE 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 OICE’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.

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.

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.

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.

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 OICE. 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 OICE 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, Plan Group 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 OICE 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 OICE.
Segments: The SHOW="Yes" attribute tells OICE 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 OICE. If Segments configuration is not present, Segment Roles will not be available for display.
Segment Roles: The SHOW="Yes" attribute tells OICE 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 OICE.
Values: The SHOW="Yes" attribute tells OICE to display the Values section. The <Message> element allows a configured message to be presented to the user on the Values section in OICE.

PolicyRequirementScreen: This business rule is used to configure OICE'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.

RequirementScreen: The RequirementScreen business rule must be configured in order for OICE 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.

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...

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.