Delinked Messages

Delinked Messages

Requirements Document
Distribution : / XGIS
IUG
Reference : / Q:\Lmd\Development\300102994-Delinked Messages-IUG\01 Business Requirements\IUG-300102994-Delinked Messages-Requirements.02.doc
Author : / Barry Rolfe and Mark Thompson
Applicability : / Product
Customers / IRIS-ENH
IUG
Global Insurance Solutions Ref / 300102994
SAP Network ID / P-IRGRP078
IUG Reference : / 0006
Version : / 02
Revision Date : / 13th November 2006
Authorised by: / ______/ Projects Manager / Date: / / /

© Xchanging Global Insurance Solutions Ltd. 2006

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 Solutions Limited (XGIS).

This document contains information which is confidential and of value to Xchanging Global Insurance Solutions Ltd. It may be used only for the agreed purpose for which it has been provided. Written consent is required before any part is reproduced.

Note: This document is submitted to the IRIS User Group solely for informational purposes and shall not be deemed or construed to be a contract or agreement binding on Xchanging Global Insurance Solutions Ltd. Only signed hard copies and electronic masters of documents will be controlled. Any other copy may not be current.

Trademark Information

Company, product, or brand names mentioned in this document, may be the trademarks of their owners.

1.Amendment History

Ver / Reason / Date / NewReference
01 / Initial Draft / 06/11/06 / Q:\Lmd\Development\300102994-Delinked Messages-IUG\01 Business Requirements\IUG-300102994-Delinked Messages-Requirements.01.doc
02 / Functional Requirements added and Estimate completed / 13/11/06 / Q:\Lmd\Development\300102994-Delinked Messages-IUG\01 Business Requirements\IUG-300102994-Delinked Messages-Requirements.02.doc

Contents

1.Amendment History......

2.Summary......

2.1Background......

2.2Scope......

2.3Outside Scope......

3.Business Requirements......

4.Functional Design Requirements......

4.1Message Download......

4.2Message Translation......

4.3Loading Onto IRIS......

4.4Processing the Message......

5.Business and Functional Requirements Matrix......

6.Costing......

2.Summary

The Early Signing Message (Delinked message) is available from Xchanging Ins-Sure Services (XIS) for those companies who register to take it.

The message, available for both “LIRMA” and “ILU” data, is sent by XIS when the Signed Line information is received from the Broker by them. This enables a message to be sent that can update existing IRIS policy records with this information rather than having to wait for the daily signing message which is, for LIRMA data, the DSIGN message and for ILU data, the ILUCSM message. The delivery of these subsequent signing messages is often some considerable time later due to the Broker not submitting the risk for closing.

This enhancement is to describe the outline business requirements to enable IRIS to be able to process Company Delinked messages, for LIRMA data, the IPCDSM message and for ILU data, the IPCCSM message.

Please note that IRIS already has the capability to process the equivalent Lloyds Delinked message.

2.1Background

These messages are in the same format as the existing closings messages (DSIGN and ILUCSM) but have a different message type and it is this that identifies the message as being a Delinked or Early Signing Message.

The messages contain as much data as is available to XIS, and that will also be included in the subsequent signing messages, but it should be noted that some data items cannot be provided at this stage in the processing cycle.

2.2Scope

The scope of this enhancement will be to include applicable processing within automatic message processing procedures and also the Bureau Closings application to be able to identify, edit and process these early signing messages.

It is envisaged that only existing policies that are present on IRIS policy files will be able to be updated with the signed line/order message information and new IRIS policy records will not be created for any message that references a non-existent policy reference.

2.3Outside Scope

XIS also have the capability of producing a CDF file (comma delimited file) of Delinked data. Processing of this input form will not be included in this enhancement.

3.Business Requirements

The basic requirement is for IRIS to be able to process the Company Delinked messages, IPCDSM message for LIRMA data and for ILU data, the IPCCSM message, using the existing message control procedures where possible.

B1)Download Message

The Delinked Messages will be downloaded from the FTP site onto the iSeries.

B2)Translate Message

The message will be validated and translated into the message capture files.

B3)Upload Message to IRIS

The Delinked messages will be loaded into IRIS, such that they can be treated like other ILU and LIRMA Bureau Transactions.

B4)Process Message

It is proposed that the Delinked Messages will be processed by the existing Bureau Closings application for ease of development and a reduced development cost. They will be processed in batch on the iSeries, or interactively by the GUI. Depending on the enquiry selections,Delinked messages can either be displayed alone, or with together with other messages.

B5)Updating Policy

Processing the Delinked messages will update details on the Policy Files.

B6)Delinked Status

Policy Inputshould indicate if a policy has had aDelinked message processed against it.

B7)Cancelled Delinked Messages

Policy Input should indicate if a policy has had a delinked message processed against it that was subsequently cancelled and not to date replaced.

B8)Action History

A history of whether Delinked messages have been processed against a policyshould be recorded at the policy reference level.

B9)System Administration

Access to The Delinked Message processing will be controlled by existing Bureau and Closing settings in System Administration.

4.Functional Design Requirements

4.1Message Download

Currently all Bureau messages are downloaded using the Bureau Message Workflow Manager application (BureauMsgWFM.exe) and it is proposed that the Delinked message download process will as well.

F1)BureauMsgWFM.exe

This will need to be able to be configured to recognise and process the new message types only if the messages come from a different site than the other messages.

F2)FTP Upload

The FTP upload will not require any changes. The Message will be loaded into the iSeries library dedicated to receiving intermediate messages.

4.2Message Translation

Once the messages have been loaded onto the iSeries, the iSeries programs will be used to translate the messages into the format needed to load them onto IRIS.

F3)Translate Messages and Load to Bureau Receiver Files

Once the messages have been transferred to the iSeries, there will be enhancements to the existing Bureau Closings application, so that Delinked messages can be validated and loaded into the Bureau Receiver Files. This will be implemented by selecting ‘Load’ from the LIRMA and ILU Signings iSeries screens.

4.3Loading Onto IRIS

After the message has been translated, then the records will be loaded into the Bureau Closings Log files.

F4)Loading into Bureau Closings Log Files

The existing iSeries Bureau Closings application will be enhanced to include Delinked messages, so once a message has been loaded into the Bureau Closings Log files, it will appear similar to other Bureau Messages. This will be implemented from the LIRMA and ILU Signings iSeries screens, by selecting ‘Create Closings’, or depending on system settings it can be included in the ‘Load’ process.

4.4Processing the Message

The message can be processed to update the policy files in batch using enhanced iSeries Programs, or interactively using the GUI.

F5)Updating IRIS

Whether the GUI, or iSeries, is used, the message processing will be the same. Processing the message will update the Policy files with data from the Delinked message. To enable existing functionality to be used, which will reduce cost, ‘Dummy’ closings records, with zero amounts will also be created, but these will not be written to the ledger.

F6)iSeries Processing Message

There will be further iSeries changes, so that ILU, or LIRMA Delinked transactions can be processed in Batch, to allow the Closings and Policy files to be automatically updated. Depending upon system settings, this will be implemented automatically from selecting ‘Load’, or ‘Transaction Validation’.

F7)GUI Processing Message

Once the iSeries option of ‘Create Closings’ has been run, the Delinked message will be available to the GUI. The GUI Bureau Closings application will be enhanced, so that ILU, or LIRMA Delinked transactions can be Processed.

a)Enquiry Wizard Selection

There will be an option on the existing Bureau Closings Enquiry Wizards to allow Delinked messages to be included. This provides the capability to include only Delinked messages, or other messages as well, in the results list of messages produced. Selected messages will appear in the Bureau Closings Enquiry List. This method is preferred to having a separate application, as it is more flexible and more cost efficient.

b)Process Selected Bureau Transaction

Selecting a Delinked record from the Bureau Enquiry List is to be the same as for other message types. The Bureau Closings Detail screen will open and the record can be treated as with the other messages. The difference being that dummy closings, with zero amounts will be written to the closings logs. Since we are only interested in updating policy details, the Procession of R/I will not be allowed, so the only process button to be displayed on the Bureau Closings detail screen will be the "Process (No R/I)”.

F8)GUI Processing Options

The Processing options available to the Bureau Enquiry will not change for Delinked messages, so access to the options will be controlled by existing Bureau and Manual Closings settings in System Administration.

The processing options available via a right click option, or the selection of a menu option, will be :

a)Validate

This option will validate the message data against the entered policy data currently in force for the IRIS policy selected. Errors will be displayed on the Errors tab for any invalid fields.

b)Amend

This option will allow for any invalid fields to be changed on the IRIS policy to clear the validation errors. The values entered will be validated to ensure the integrity of the IRIS policy remains.

c)Process

This option will update an IRIS policy with the valid transaction data and create the dummy closings records. The status column of the results grid will be set to ‘Completed’.

d)Delete

This option will mark the message as deleted and set the “Deleted” value against that item in the Status column of the results grid.

e)Undelete
This option will mark the message as active and remove the “Deleted” value against that item in the Status column of the results grid.

F9)Policy Input

There will be a new flag on the policy files that will indicate the Delinked Status of a message. This field will be updated when a message is processed and the Delinked status can be displayed on the Details screen of Policy Input, depending upon system settings.

F10)Cancelled Delinked Message

Cancelled Delinked messages, where the broker has decided not to proceed with a signings message will also be processed. When Process is selected on a cancelled Delinked message the Bureau Closings screen will not be displayed, but the policy new Delinked Policy Flag will be updated. Cancelled Messages will be rejected by iSeries Batch processing and will need to be processed by the GUI.

F11)Delinked Action History

There is already action history capability on Bureau Closings, so this will be enhanced to create an entry whenever a Delinked message (or a cancellation of a Delinked message) is processed against a policy.

F12)iSeries Delinked Action History

The risk action history functionality is currently only available to the GUI. The iSeries batch processing will be modified to also record these specific actions in the risk action history file.

5.Business and Functional Requirements Matrix

The following matrix shows the relationships between the business and technical requirements listed in this document.

B1 / B2 / B3 / B4 / B5 / B6 / B7 / B8 / B9
F1 / 
F2 / 
F3 / 
F4 / 
F5 /  /  / 
F6 / 
F7 / 
F8 /  / 
F9 / 
F10 / 
F11 / 
F12 / 

6.Costing

Quotation:

Full Specification / 25 / days
Estimated Development / 48 / days

This quotation is valid for 90 days.

The estimate for the production of the full specification is an approximate figure only. The Specification will be produced on a fixed price basis based on this approximate figure.

The estimate for the development is also an approximate figure. The full specification will involve more detailed analysis and will provide a firm quotation for enhancement implementation that may vary from the figure given above.

Strictly Private & ConfidentialPage 1 of 11

Global Insurance SolutionsVersion Error! Reference source not found.

Printed 14/11/06

Q:\Lmd\Development\300102994-Delinked Messages-IUG\01 Business Requirements\IUG-300102994-Delinked Messages-Requirements.02.doc