300102994-Delinked Messages (Functional Specification)

IRIS User Group Development

IRIS-ENH

Delinked Messages

IUG-0006; SN-300102994

Current Location & Status

File Location / Q:\Lmd\Development\300102994-Delinked Messages-IUG\02 Specification\IUG-300102994-Delinked Messages-Functional.01.doc
Document Owner / Xchanging Global Insurance Systems
Status / Authorised by XGIS

Authorised by

Name / Authorising Role / Date / Signature
Alan Chisham / Development Project Manager / 08/05/07 / Signed copy on file
Daryl Yeats / Project Manager / 08/05/07 / See e-mail in folder
Mick Hobbs / Director / 09/05/07 / See e-mail in folder
John Colwell / Financial Director / 08/05/07 / See e-mail in folder
IRIS User Group / Client

Daryl Yeats

Project Manager

10th May 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 / Date
1 / New Document / 03/05/2007

Circulation List

Name / Business Area / For Review / For Sign-off / Agreement to proceed
Alan Chisham / Development / X / X / X
Daryl Yeats / IS / X / X
Mick Hobbs / IS / X / X / X
John Colwell / IS / X / X / X
IRIS User Group / Client / X / X / X

Document Purpose

This document is the Functional Specification for the Delinked Message Processing Enhancement for IRIS-ENH[1]. It has been compiled in accordance with the Xchanging XPERT package Implementation Methodology.

Contents Page

1 Introduction 6

1.1 Background to Requirement 6

1.2 Business Requirement 6

1.2.1 Requirements 6

1.3 Scope 7

1.4 Outside Scope 7

1.5 Terms and Definitions 7

1.5.1 Message File 7

1.5.2 Message 7

2 Summary of Functional Changes 8

2.1 Business and Functional Requirements Matrix 10

3 Detailed Functional Specifications 11

3.1 Message Download - FS1) 11

3.2 Message Upload - FS2) 11

3.3 Translate Messages and Load to Bureau Receiver Files - FS3) 11

3.4 Numerical Validation – FS4) 11

3.5 Create Closings - FS5) 12

3.6 Transaction Validation - FS6) 12

3.7 Signings file Status - FS7) 13

3.8 Generic Bureau Screens - FS8) 14

3.9 Updating IRIS - FS9) 14

3.10 iSeries Message Processing - FS10) 14

3.11 GUI Message Processing - FS11) 15

3.12 GUI Processing Options - FS12) 16

3.13 Policy Input - FS13) 17

3.14 Cancelled Delinked Messages FS14) 17

3.14.1 GUI Cancelled Delinked Processing 17

3.14.2 iSeries Cancelled Delinked Processiing 17

3.15 Delinked Action History - FS15) 18

3.15.1 GUI Delinked Action History - FS15)a) 18

3.15.2 iSeries Delinked Action History - FS15)b) 18

3.16 Closings Update - FS16) 18

3.17 Closings Edit - FS17) 18

3.18 Closings Reversal - FS18) 18

3.18.1.1 Closings Reversal Enquiry 18

3.18.1.2 Enquiry Navigation for Transaction Enquiries 18

3.19 Fix Program - FS19) 18

4 Acceptance Criteria 19

4.1 Test Plan 19

4.2 Matrix to Reference the Functional Statements to the Test Cases 30

4.3 Test Cases 30

5 Costs 31

6 Appendix 32

6.1 Database Additions/Changes 32

6.1.1 New/Changed Files 32

6.1.1.1 UPPSREP 32

6.1.1.2 UCGFREP 32

6.1.2 Data Output 32

6.1.2.1 Action History Records 32

6.1.2.2 Signed Line/Order Percentages 32

6.1.3 Sample Reports 34

6.1.3.1 Example of Transaction Validation Report 34

XPERT Release 1 Stage G Page 34 of 34

300102994-Delinked Messages (Functional Specification)

1  Introduction

1.1  Background to Requirement

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.

It should be noted that IRIS already has the capability to process the equivalent Lloyds Delinked message.

1.2  Business Requirement

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.

1.2.1  Requirements

BR1)  Download Message

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

BR2)  Translate Message

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

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

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

BR5)  Updating Policy

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

BR6)  Delinked Status

Policy Input should indicate if a policy has had a Delinked message processed against it.

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

BR8)  Action History

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

BR9)  System Administration

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

1.3  Scope

The scope of this document is to enable IRIS to be able to process Company Delinked messages, for LIRMA data, the IPCDSM message and for ILU data, the IPCCSM message.

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.

1.4  Outside Scope

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

Delinked messages will be processed to update the Policy using the GUI, or in Batch on the iSeries. It will not be possible to use On-Line-Edit for Delinked records.

1.5  Terms and Definitions

1.5.1  Message File

This relates to the transmission that is downloaded from Bureau. The transmission will be a file that contains messages.

1.5.2  Message

A Message is a collection of data that represents a business transaction. A number of messages may be transmitted in a single message file.

2  Summary of Functional Changes

FS1)  FTP Download

The Bureau Message Workflow Manager application (BureauMsgWFM.exe) will be used to download the message to a network by selection the ‘Poll for new Messages’ option. 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.

FS2)  FTP Upload

The ‘Upload new Messages to RDBMS‘ selection in the Bureau Message Workflow Manager application (BureauMsgWFM.exe) will download the message into the iSeries library dedicated to receiving intermediate messages using the existing FTP upload.

FS3)  Translate Messages and Load to Bureau Receiver Files

Once the messages have been transferred to the iSeries The Bureau Message Workflow Manager application (BureauMsgWFM.exe) will be used to translate the messages into the Bureau Reciever Files.

a) The message layout will be validated

b) The message will be loaded into the Bureau Receiver Files.

FS4)  Numerical Validation

The existing Bureau Closings Application will be enhance, so that Delinked Messages can be Numerically Validated (LIRMA only)

FS5)  Create Closings

The existing iSeries Bureau Closings application will be enhanced, so Delinked messages are loaded into the Bureau Closings Log Files, where they can be processed.

FS6)  Transaction Validation

The existing iSeries Closings application will be enhanced to validate Delinked messages.

FS7)  Signings File Status

The Signings File Screen will need to be changed for LIRMA and ILU, so that a flag will indicate if a message file is delinked or not.

FS8)  Generic Bureau Screens

The generic screen used to submit Numerical Validation, Create Closings and Transaction Validation will need to be changed for LIRMA and ILU, so that a flag will indicate if a message file is delinked or not.

FS9)  Updating IRIS

Whether the GUI, or iSeries, is used, the message processing will be the same.

a) The Policy files will be updated with data from the Delinked message.

b) ‘Dummy’ closings records, with zero amounts will be created, but these will not be written to the ledger.

FS10)  iSeries Message Processing

There will be further iSeries changes, so that ILU, or LIRMA Delinked messages can be processed in Batch, to allow the message transactions to be processed.

FS11)  GUI Message Processing

IRIS GUI will be enhanced, so that ILU, or LIRMA Delinked message transactions can be Processed.

a) The Bureau Closings Selection Wizard will be enhanced to include, or exclude Delinked records.

b) Once selected the Bureau Closings will be enhanced to process the Delinked Records.

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

FS13)  Policy Input

There will be a new flag on the policy files that will indicate the Delinked Status of a policy.

FS14)  Cancelled Delinked Message

Cancelled Delinked messages, where the broker has decided not to proceed with a signings message will also be processed and the Policy updated.

FS15)  Delinked Action History

To maintain an audit trail of Delinked Processing an Action History record will be created whenever a delinked, or cancelled delinked message is processed against a policy.

a) GUI Action History

IRIS GUI Bureau Closings already creates action history records and this will be extended to write a Delinked record

b) iSeries Action History

The iSeries Bureau Closings Batch Processing will also need to be enhanced to write an Action History record for delinked messages.

FS16)  Closings Update

Delinked records will be processed to the Stats, but not to the Ledger.

FS17)  Closings Input

Closings Input will be amended, so that it will not be possible to Edit, or Copy a delinked item.

FS18)  Closings Reversal

It will not be possible to reverse a delinked item.

FS19)  Fix Program

A fix program will need to be run to set the Delinked Status flag for existing polices.

2.1  Business and Functional Requirements Matrix

The following matrix shows the relationship between the business and functional requirements listed in this document.

BR1 / BR2 / BR3 / BR4 / BR5 / BR6 / BR7 / BR8 / BR9
FS1 / P
FS2 / P
FS3 / P
FS4 / P
FS5 / P
FS6 / P
FS7 / P
FS8 / P
FS9 / P / P / P
FS10 / P / P / P
FS11 / P / P / P
FS12 / P
FS13 / P
FS14 / P
FS15 / P
FS16 / P
FS17 / P
FS18 / P
FS19 / P

3  Detailed Functional Specifications

The Delinked messages will be identified by their message types IPCDSM for LIRMA and IPCCSM for ILU. The format of the messages will be the same as the existing closings messages, so the messages will be processed through the existing Bureau Closings Application.

3.1  Message Download - FS1)

Currently all Bureau messages are downloaded into a network directory using the Bureau Message Workflow Manager application (BureauMsgWFM.exe) and so will the Delinked message download process. The messages will be coming from the same site as existing signings messages, so no additional configuration of IRIS will be needed (in regards to an FTP site).

3.2  Message Upload - FS2)

The Message will be loaded into the same iSeries library dedicated to receiving existing closing intermediate messages using the existing Bureau Message Workflow Manager application (BureauMsgWFM.exe) FTP upload.

3.3  Translate Messages and Load to Bureau Receiver Files - FS3)

Once the messages have been transferred to the iSeries the ‘Translate messages’ selection of Bureau Message Workflow Manager application (BureauMsgWFM.exe) will be used to translate the messages into the Bureau Reciever Files.

·  The message layout will be validated

·  The message will be loaded into the Bureau Receiver Files

Depending on data area settings (UTPSRSA3 for LIRMA and UTILRLA1 for ILU) it is possible to Validate the messages and load them into the Bureau Closing Log Files from the ‘Translate messages’ option of the Bureau Message Workflow Manager (see 3.4, 3.5 & 3.6 on page 11). This will enable the messages to be fully processed using only the GUI.

Selecting ‘Poll, upload and translate’ will execute the Message Download (3.1), Message upload (3.2) and Translate (3.3) in a single job. Jobs from the Bureau Message Workflow Manager application can either be submitted to the scheduler, or run interactively using the ‘Run Now’ option.

3.4  Numerical Validation – FS4)

The existing Bureau Closings Application will be enhanced to, so that Delinked Messages can be Numerically Validated. This is the first level of validation and checks that numerical fields are numeric and character fields are characters. Numerical Validation is option 2 from the LIRMA menu, although depending on data area UTPSRSA3, this job may have been completed automatically from the Translate (see section 3.3 on page 11)