300107456-Cross Policy Generic Rules (Functional Specification)
\
IUG Development
IRIS-ENH
Cross Policy Generic Rules
IUG Ref: 0984, SN: 300107456
Current Location & Status
File Location / Q:\Lmd\Development\300107456-Cross Policy Generic Rules-IUG\02 Specification\IUG-300107456-Cross Policy Generic Rules.Functional.01.docDocument Owner / Xchanging Global Insurance Solution Ltd
Status / Authorised by Xchanging
Authorised by
Name / Authorising Role / Date / SignatureAlan Chisham / Development manager / 9/11/07 / Signed copy on file
Daryl Yeats / Project manager / 9/11/07 / e-mail on file
Rob Locke / Production Director / 12/11/07 / e-mail on file
John Colwell / Financial Director / 12/11/07 / e-mail on file
IRIS User Group / Client
Prepared by: Mark Larter and Tim Herbert
Project ManagerDaryl Yeats
Office:XGIS
34 Leadenhall Street
London
EC3A 1AX
Issue Date:12th November 2007
© Xchanging Global Insurance Systems Ltd. 2007
All rights reserved. No part of this publication may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, electronic, mechanical, photocopying, recording, or otherwise, without the prior permission of Xchanging Global Insurance Systems Limited (Xchanging).
This document contains information which is confidential and of value to Xchanging. It may be used only for the agreed purpose for which it has been provided. Written consent is required before any part is reproduced.
Trademark Information
Company, product, or brand names mentioned in this document, may be the trademarks of their owners.
Document Control
Revision History
Version / Description/Reason for Change / Date01 / Document Created / 9/11/2007
Circulation List
Name / Business Area / For Review / For Sign-off / Agreement to proceedAlan Chisham / IS / X / X
Daryl Yeats / IS / X / X
Rob Locke / IS / X / X / X
John Colwell / Financial Director / X / X
IRIS User Group / Client / X / X / X
Document Purpose
This document is the Functional Specification for the IRIS User Group’s proposed development ‘Cross Policy Generic Rules’ in IRIS-ENH[1]. It has been compiled in accordance with the Xchanging XPERT package Implementation Methodology.
Contents Page
1Introduction
1.1Background to Requirement
1.1.1Summary
1.1.1.1SUMMARY:
1.1.1.2BUSINESS REQUIREMENT DEFINITION:
1.1.1.3BUSINESS JUSTIFICATION:
1.1.2Documentation
1.2Business Requirement
1.2.1Requirements
1.3Scope
1.4Assumptions and Limitations
1.5Impact Analysis
1.6Implementation
1.7Terminology
2Summary of Functional Changes
2.1IRIS Business Customisation Changes
2.2IRIS Application Changes
2.3Business and Functional Requirements Matrix
3IRIS Business Customisation
3.1Allow the user to create rules based on field values from another policy (FS01)
3.1.1Overview
3.1.2Details
3.1.2.1Accessing Source Policy Fields
3.1.2.2Accessing Lineslip Master Fields
3.1.2.3Accessing Related Object Information
3.1.2.4Constraint Rule Items
3.1.2.5Expression Fields
3.1.2.6Conditional Rule Groups
3.1.2.7Field Assignment Action
3.1.2.8Script Execution Action
3.1.2.9Changes to the IRIS Function Assistant
3.2Edit simple database queries (FS02)
3.2.1Overview
3.2.2Details
3.2.2.1Example 1 - Counting the accounting terms of a policy
3.2.2.2Example 2 – Checking that the Policy User Reference is Unique
3.3Include simple database queries in rules (FS03)
3.3.1Overview
3.3.2Details
3.4Configure a rule to be a ‘Warning’ or an ‘Error’ (FS04)
3.4.1Overview
3.4.2Details
3.5Configure a rule such that it’s warning message will be shown in a message box (FS05)
3.5.1Overview
3.5.2Details
3.6Allow the user to filter the rules displayed on the screen (FS06)
3.6.1Overview
3.6.2Details
4IRIS Application
4.1Evaluate Rules based on values from another policy (FS07)
4.2Evaluate rules based on a simple database query (FS08)
4.3Show Broken Rules as either a ‘warning’ or an ‘error’ (FS09)
4.3.1Overview
4.3.2Details
4.4Show the warning message for broken rules in a message box as appropriate (FS10)
4.4.1Overview
4.4.2Details
5Acceptance Criteria
5.1Test Plan
6Costs
1Introduction
1.1Background to Requirement
1.1.1Summary
The IRIS User Group has requested that IRIS be enhanced so that:
1)Rules within Policy Input can include fields from other policies.
2)Rules can be defined as either a ‘warning’ or an ‘error’.
3)Rules can be defined to show their warning/error message as per current functionality or in a message box.
The original text of the IUG voting list item was as follows:
1.1.1.1SUMMARY:
It should be possible to define validation rules for policy input which relate to other policies already in IRIS e.g. the policy you are renewing from
1.1.1.2BUSINESS REQUIREMENT DEFINITION:
Business Customisation should be modified to allow validation rules (warnings, errors & pop-ups) to be defined based on: - information held on the policy you are renewing from - a simple enquiry Examples of possible uses of this functionality are: - Inception date on policy is not contiguous with expiry date on originating policy - IRIS policy number matches on renewal policy but slip number doesn’t - Period of policy i.e. number of days between inception and expiry is greater than number of days allowed - Policy being created but the slip number is the same as a skeleton that already exists on IRIS - Skeleton being expanded but the slip number is the same as a policy that already exists on IRIS These rules should be applied during policy input and the user should be advised of failed validation by warnings, errors or pop-ups as defined within Business Customisation.
1.1.1.3BUSINESS JUSTIFICATION:
Many user errors when entering policies could be averted up front by validating against existing IRIS data rather than just using IRIS code tables. This would reduce time spent running exception reports and amending incorrect data.
1.1.2Documentation
Business Requirements Document: Q:\Lmd\Development\300107456-Cross Policy Generic Rules-IUG\01 Business Requirements\IUG-300107456-Cross Policy Generic Rules-Requirements.01.doc
1.2Business Requirement
The Cross Policy Generic Rules business requirement definition is as follows:
Business Customisation should be modified to allow validation rules (warnings, errors and pop ups) to be defined based on:
- Information held on the policy you are renewing from
- A simple database query
1.2.1Requirements
The following are the business requirements as listed in the Business Requirements document referenced in section 1.1.2Summaryabove:
BR01)Validate From Related Policies
BR02)Validate From the Results of a Simple Database Query
BR03)Determine Error Type
BR04)Determine Error Display Type
BR05)Rules Applied in Policy Input
BR06)Filter and Search Rules
1.3Scope
The following areas fall within the scope of this enhancement:
1)Editing of rules based over fields from another policy
2)Configuring a rule to be either a ‘warning’ or an ‘error’
3)Configuring a rule to show it’s warning/error message in a message box
4)Editing of simple database queries.
5)Inclusion of simple database queries in rules
6)Cross Policy Generic Rules will be restricted to ‘Policy Input’ within the IRIS application.
7)Within IRIS Business Customisation a rules filter will be made available.
1.4Assumptions and Limitations
Within the IRIS Business Customisation application the rule edit screens are generic rule screens that apply across all the applications and functions. Hence, these changes to these screens (to allow the user to configure a rule to be a warning or an error) will be effective for rules in all products and applications even though the scope of this enhancement is specifically to provide this functionality to Policy Input.
1.5Impact Analysis
The generic rules system is an area of IRIS where performance is critical for a quick response time when the user changes a field on the screen (a single field change can cause a number of rules to be tested).
Obtaining field values from another policy and, more significantly, running a simple database query can never be as quick as obtaining values from an already loaded policy, hence this enhancement at least where these new rule types are implemented on a policy will have an impact on the performance.
Rule performance is a priority design consideration to ensure that these new rule types run as efficiently within the IRIS Framework as possible.
1.6Implementation
Upon implementation of Cross Policy Generic Rules any user of IRIS Business Customisation will need to keep in mind the performance of the rules being created when including fields from another policy and simple database queries.
1.7Terminology
This document uses the following terms which are described here for clarity.
1)Copy actions – there are several actions in IRIS that result in data being copied from one entity to another. Where this document references copy actions it encompasses all of the following policy, skeleton, quote, promise, memo and declinature actions:
a)Copy
b)Add Declaration
c)Add Promise as Declaration
d)Add Quote as Declaration
e)Add Sequence
f)Add Skeleton as Declaration
g)Renew
h)Renew to Promise
i)Renew to Quote
j)Renew to Skeleton
k)Take-up to Policy (but excluding where skeletons are taken up to policies since this is not a copy action but a status change because no new entity is created – the existing skeleton’s status is just updated to indicate that it is now a policy)
l)Take-up to Skeleton
2)Source – where this document refers to a source policy it means the entity (policy, skeleton, quote, promise, memo, declinature) from where the data is being copied.
3)Target – where this document refers to a target policy it means the entity which being created (onto which the data is being coped and on which the rules are going to be applied)
4)Copy Session – a copy session is defined as the time between when the user creates a new policy entity via one of the Copy actions to when that entity is closed. A policy entity being any one of the following
a)Policy
b)Skeleton
c)Quote
d)Promise
e)Memo
f)Declinature
2Summary of Functional Changes
This enhancement is split into two main parts:
1)Changes to IRIS Business Customisation
2)Changes to the IRIS Application.
2.1IRIS Business Customisation Changes
IRIS Business Customisation will be enhanced to:
FS01)Allow the user create rules based on field values from another policy when editing rules for Policy Input.
FS02)Edit simple database queries.
FS03)Include the simple database queries in rules.
FS04)Configure a rule to be a ‘warning or an ‘error’.
FS05)Configure a rule such that its warning/error message will be shown in a message box.
FS06)Allow the user to filter the rules displayed on the rules tab in business customisation.
2.2IRIS Application Changes
The IRIS Application will be enhanced to:
FS07)Evaluate rules based on field values from another policy.
FS08)Evaluate rules based on a simple database query.
FS09)Show broken rules as either a ‘warning’ or an ‘error’.
FS10)Show the warning/error messages for broken rules in a message box as appropriate.
2.3Business and Functional Requirements Matrix
BR01 / BR02 / BR03 / BR04 / BR05 / BR06FS01 / /
FS02 / /
FS03 / /
FS04 / /
FS05 / /
FS06 /
FS07 / /
FS08 / /
FS09 / /
FS10 / /
3IRIS Business Customisation
3.1Allow the user to create rules based on field values from another policy (FS01)
3.1.1Overview
During the process of creating a new policy (including copy actions such as copy, declare, renew,take-up, add sequence etc), the IRIS rules system currently allows fields to be initialised to a preset value or to be copied from the originating policy (in this case the field value can also optionally be incremented).
Currently, values can only be copied from the same field. These types of rules are created by adding Default Values and Copy Values items to the product-code specific rules hierarchy item within the rules configuration page of Business Customisation.
This enhancement will allow new branches of the hierarchy to be created which will take a more flexible approach to these types of rules, allowing additional rule entities (such as conditions, constraints and rule scripts) to access fields from both the source policy and the target policy.
3.1.2Details
When defining product rules within Business Customisation, expressions used within the individual rule items will be able to obtain values from related objects that are within the scope of the input function whose rules are being defined, or within a branch of the rules hierarchy that is specific to a copy operation being performed.
These will include:
1)Access to details of the policy being copied for the various copy type actions.
2)Access to the lineslip master when editing a declaration.
3)Access to the parent policy’s fields from within any of Policy Input's ancillary functions.
3.1.2.1Accessing Source Policy Fields
Rules specific to a copy type operation will be added to a new "Copy Rules" branch of the rules tree within Business Customisation. This will be added by the administrator when required by accessing the rule tree's context menu or by pressing the "Add Rule" button. The copy action will be selected in the same way as adding the existing "Default Values" and "Copy Values" items. The copy action selected will be included in the text within the rules tree within parentheses.
Underneath the new Copy Rules branch, expressions used by Rule items will be able to reference fields from both the source policy and the policy currently being created. Within these expressions, source policy fields will be referenced by prefixing the names of fields with "SourcePolicy.".
This new branch of the rules tree will be able to contain the standard rule items (constraints, list constraint, mandatory constraint, field change actions, expression field, conditional rule group, and 'other events[2]').
The rules defined within the Copy rules branch will be applied to the policy ONLY during the life span of a given closings session (see point 4)on page 8)
3.1.2.2Accessing Lineslip Master Fields
Similarly, for lineslip products, it will be possible to add a "Declaration Rules" branch to the rules tree. Within this branch, it will be possible to refer to fields from the lineslip master by prefixing the names of fields with "MasterPolicy.".
3.1.2.3Accessing Related Object Information
When defining rules for an ancillary function (such as Accounting Terms), it will be possible for an expression to contain a reference to a field from the parent policy object, by using the "ParentPolicy." prefix. References to fields from the parent policy will be available from anywhere within the branch of the rules hierarchy for the ancillary function.
3.1.2.4Constraint Rule Items
The Constraint editor dialog allows an expression to be entered that must hold true for the policy or ancillary function to validate successfully. Currently, an expression used to constrain a field value might look like:
Product Rules
├─ [POCBCD] = 'A' Or [POCBCD] = 'B'
This specifies that the policy class code (POCBCD) must be equal to A or B.
Where access to a related policy is available, it will be possible to extend field names within an expression in order to specify that the field value from the related policy should be used.
For example, within the "Copy Rules (Copy)" branch:
Product Rules
├─ Copy Rules (Copy)
│ └─ [POCBCD] = [SourcePolicy.POCBCD]
This rule will requires that the class code (POCBCD) on the policy be equal to theclass code of the policy from which it was copied.
It will be possible to include a constraint in an ancillary function such as Accounting Terms that includes a policy details field in an expression, or a constraint which is conditional on a policy details field, such as:
Product Rules
├─When [ParentPolicy.POCBCD] = 'A'
│ ├─[ATDUD1] >= [ParentPolicy.POICDT]
│ ├─[ATDUD2] >= [ParentPolicy.POICDT]
│ ├─[ATDUD3] >= [ParentPolicy.POICDT]
│ ├─[ATDUD4] >= [ParentPolicy.POICDT]
│ ├─[ATDUD5] >= [ParentPolicy.POICDT]
│ └─[ATDUD6] >= [ParentPolicy.POICDT]
├─When [ParentPolicy.POCBCD] > 'A'
│ ├─[ATDUD1] >= DateAdd('d', -7, [ParentPolicy.POICDT])
│ ├─[ATDUD2] >= DateAdd('d', -7, [ParentPolicy.POICDT])
│ ├─[ATDUD3] >= DateAdd('d', -7, [ParentPolicy.POICDT])
│ ├─[ATDUD4] >= DateAdd('d', -7, [ParentPolicy.POICDT])
│ ├─[ATDUD5] >= DateAdd('d', -7, [ParentPolicy.POICDT])
│ └─[ATDUD6] >= DateAdd('d', -7, [ParentPolicy.POICDT])
This rule applies to an accounting terms and specifies that if the class code on the policy is set to A then the a/c term due dates (from 1 through 6; ATDUD1-ATDUD6) must be greater than or equal to the policy’s inception date (POICDT). Whereas if the class code on the policy is NOT set to ‘A’ then the a/c term due dates (from 1 through 6; ATDUD1-ATDUD6) must be greater than or equal to the date 7 days before the policy’s inception date (POICDT).
This gives an example where two sets of constraints are dependant on the value of a policy details field.
3.1.2.5Expression Fields
Similarly, it will be possible for expression fields to contain expressions that reference related data:
Product Rules
├─ Copy Rules (Copy)
│ └─ [POPONR] ← 'Copied from ' & [SourcePolicy.PHUSRF]
This rule will automatically populate the policy contract narrative field (POPONR)with some text that says ‘Copied from’ followed by the policy reference (PHUSRF)of the policy being copied.
3.1.2.6Conditional Rule Groups
Product Rules
├─ Copy Rules (Copy)
│ └─ When [SourcePolicy.POCBCD] = 'A'
│ └─ [POCBCD] = 'A1' Or [POCBCD] = 'A2'
This rule will ensure that when a policy having a class code of 'A' is copied, the new class code will be either 'A1' or 'A2' on the new policy.
3.1.2.7Field Assignment Action
When an rule event occurs (such as a field change or other event), a field can be set to the result of an expression:
Product Rules
├─ Copy Rules (Copy)
│ └─ When [POICDT] Changes
│ └─ [POEKDT] ← [POICDT] + DateDiff('d',
│ [SourcePolicy.POICDT], [SourcePolicy.POEKDT])
This rule will execute whenever the user enters an inception date (POICDT) for the new policy during the copy session. It will cause the expiry date (POEKDT) to change such that the duration of the policy is equal to that of the policy being copied.
3.1.2.8Script Execution Action
A rule event can also be used to trigger an IRIS script to be executed. Within these scripts, it will be possible to reference fields belonging to the related policy as part of any expression. Attempting to modify a value in the original policy will have no effect.
The following sample script will be executed when a new copy of the policy is first displayed. Different sections of the script are executed depending on the value of a field from the policy being copied. It would basically result in the policy written line share (POWLPC) being set to that of the policy being copied if the class code on the policy (POCBCD) being copied is set to ‘A’ whereas in all other cases it will set the policy signed line share (POSLPC) to be equal to that on the policy being copied.
Product Rules
├─ Copy Rules (Copy)
│ └─ OnInitialValidate
│ └─┌── Script ───────────────────────────┐
│ │ If [SourcePolicy.POCBCD] = 'A' Then │
│ │ [POWLPC] := [SourcePolicy.POWLPC] │
│ │ Else │
│ │ [POSLPC] := [SourcePolicy.POSLPC] │
│ │ EndIf │
│ └─────────────────────────────────────┘
3.1.2.9Changes to the IRIS Function Assistant
When editing an expression within Business Customisation, the Function Assistant is accessed by pressing the Ctrl and Space keys and allows the user to select from a list of available fields, functions and operators. In addition to a list of available fields for the function being configured, this list will be extended to include the list of prefixes required to access related data.