Release documentation - Cede - Enhancements and requests

Problem:
Wrong UPR calculations - RECALC pro-rata order

Solution:
When doing Pro rata Temp calculation in the Retrocession Calculation Order, system should not include the criteria that only include the balances that have the accounting year which is larger or equal to the accounting year set in the order.

Problem:

Loading ACORD message into SICS via SicsAcordClient does not preserve special characters compared to loading the same via import from file

Solution:

ACORD message should be transported preserving UFT-8 encoding.

Workaround:

For SicsAcordClient
In acord-client.bat set / amend the following line to force utf-8
SET JVMARGS=-Djava.util.logging.config.file=conf/logging.properties -Dfile.encoding=UTF-8

Problem:

The Service Provider Reference is still not reflecting for LORS messages.

Solution:

For LORS messages that have a message ServiceProviderReference without the messages actually having a ServiceProvider any message ServiceProviderReference present should still be displayed.

Problem:

Triangulation objects are not present in CEDE Universe.

Solution:

Triangulation objects needs to be Developed in CEDE Universe, to get proper data for Triangulation reports.

Problem:

Objects related to OIP Level ( Intermediary) are not present also objects that are needed to extract all the policy classification details are not available.

Solution: 

1. Need to move the object to the exact to find easily in the universe along with all other details.

2. Need to create a view and then objects to extract all the policy classification details i.e., (All) Classification details.

3. Need to create OIP level( Intermediary) objects.

Problem:

The problem is that in the table TRIG_YEAR, data only have years up to 2020 and no further, which is making difficult to extract data for triangulation objects after year 2020.

Solution:

Some additional years need to be created in this table in order for triangulation reports to be able to run correctly.

The solution for this release is a DB patch to add the additional years.

Problem:

Getting error while trying to create BOBU001 Script from SICS Admin with PostgreSQL Version 14.

Solution:

Need to update the BOBU001 Script in order to create the procedure successfully with PostgreSQL version 14.

Problem:

There is a full outer join between tables LIGHT_SOC and IO, which is not correct.

Solution:

To correct the join between tables LIGHT_SOC and IO, to get the correct data in CEDE universe.

Problem:

There is a mismatch between object name YEAR_OF_BOOKING across cede database and SQL of the view V_ORP_DATE also not defined properly.

Solution:

The object name YEAR_OF_BOOKING is renamed correctly in the universe and database just the same way as it is in PC &LIFE. Although the view V_ORP_DATE needs to be adjusted as the RTRIM() is not needed anymore due to database optimization.

Problem:

The object 'date of loss' type is character, which needs to be converted to date so that it becomes easily reportable.

Solution:

We need to modify the view as it is mentioned in the attachment by the client so that the object 'date of loss from' can be reported with ease.++

Problem:

The definition of the view V_ORP_DATE also not defined properly

Solution:
The SQL of the view V_ORP_DATES needs to be adjusted and rtrim() part should be changed as it is not needed any longer due to database optimization

The BO Views will need to be dropped and created to realize this correction

Problem:

The issue is due to missing configuration, 'caseSensitiveCnuUserNames' in SICS API Server datasource definition file

Solution:

Add <caseSensitiveCnuUserNames>false</caseSensitiveCnuUserNames>in /WEB-INF/classes/sics-database-sources.xml along with other JNDI configuration as follows

<source name='JNDI'>
    <dataSource>java:comp/env/jdbc/sics</dataSource>
    <caseSensitiveUserNames>true</caseSensitiveUserNames>
    <caseSensitiveCnuUserNames>false</caseSensitiveCnuUserNames>
    <useParameterizedSql>true</useParameterizedSql>
</source>

The <caseSensitiveCnuUserNames> tag in the datasource definition controls how the retrieval of the SICS user from the database table handles case. The default value is false, which means that SICS presumes that the user id stored in SICS is in uppercase and it will convert the authentication user id into uppercase in order to retrieve it.

In a situation where the authentication user id and the SICS user id are in lowercase or mixed case, then you must set the value to true

Problem:

I run Multi Business Auto Protection Order with Non Proportional protection with Save on Business and Claims, and Policy Light is automatically protected by Non Prop OCC (linked to Protection Program). Light Claim does however not get the claim allocation automatically set.

Solution:

In Multi Business Auto Protection Order the Non Proportional protection must be saved to Claim when Automatic Assignment flag is set at Light Claim, and Save on Business and Claims are selected at MBAP Order.

This must be the case for Non Proportional Protetcion when New, Changed or All Business is selected.

Workaround:

Run Multi Claim Auto Protection Order to get the Claim allocation set.

If system parameter Automatic Protection Assignment on Claim is selected, all new Light Claims created at a later stage for an existing Policy Light will be automatically protected when creating the Light Claim via Cede Interface.

Problem:

Light Claims has incorrect non proportional protection validation for claims when classifications are optional for both Business and Accounting Classification.
This is currently incorrect for Light Claim protection allocation if the inward policy has any of this classification given, and the OCC does not have the corresponding ones.
In addition it is incorrect in Multi Business Protection Order, when saving to business in order it is not saved to Claim when selecting the Save Claim button at order. This is the case both for Assumed Direct/Fac business Claims and for Light Claim.

Solution:

When a classification is optional for both Business and Accounting Classification (setting on system parameter / classification rules 2 = Yes/No/Yes) there should be no validation of inward claims against OCC classification when doing non proportional protection allocation.
Corrections to be done:
From Light Claim:
Manual Assignment to Protection Program (currently incorrect when additional classification given on inward Policy)
Automatic Assignment to Protection Program (currently incorrect when additional classification given on Inward Policy)

In Multi Business Protection order:
When running order and selecting Save to claim the non proportional protection assignment must be saved to Light Claim as well as Assumed Direct / Fac Claim.

Workaround:

None

Problem:

Recycle Process in Cede Interface Monitor abends when editing the incorrect record and thereafter doing a recycle.

Solution:

We need to make sure this process is handled correctly, The process of recycling should be done to enable editing of the same record and thereafter include the batch / record in a Cede Interface Order again. The possibility to fix the record before recycling must be considered removed as a possibility.
Instead the recommend workaround must be used:

Workaround:

Two alternatives:
1. Go into the excel spreadsheet and fix the issues directly there - and then run a new Cede Interface order. It should then go through and create the wanted bookings
OR
2. a) Go to error tab and open the batch which has the error.
b) Highlight the batch (left hand container), and select 'Mark for recycling' (To be recycled changes to 'Yes')
c) Select Recycle at the bottom
d) Go to Pending records - and select the batch again and do the required fixes
e) Run the order again for this corrected batch.

Problem:

Error message when not including any value into the new UDF Ref Data2 fields (FRK_UDF_REF_DATA_2 and FSK_UDF_REF_DATA_2)

Solution:

Even though you have defined UDF Ref Data2 to be a part of the UDF conditon of a Policy Light, it must be possible to leave it empty without error message. The UDF Ref data fields have two elements; the code and the value (name).

Validation when running Cede Interface Order is that if the given ref data value does not correspond with the available values, a validation error must be given. If reference data code field is missing (i.e. system has nothing to validate against) - no validation is done, and field is left empty in the Policy Light UDF condition (even though a ref data value is given).

Additionally UDF Ref Data 2 should be independent of UDF Ref Data1 - either both, none or one of them could be filled in.

Workaround:

Fill in a valid code and value

Problem:

If Risk Name for a Light Claim is too long when running it in Cede Interface Order, there is a message that claim Identifier is too long.

Solution:

Make sure the error message if Risk Name is too long relates to the Risk Name - and not the Claim Identifier.

Workaround:

Reduce the length of the Risk Name to comply with the limit of 60 characters

Problem:

Policy Light assigned to Business Group is not appearing on the list of members

Solution:

Make sure Policy Light business which are assigned to Business Group appears on the list of group members

Workaround:

None

Root Cause:

SE-13085

Problem: 

Warning message appears when upgrading SICS to 23.3 version due to new DB table(& mediator) created for Configurable Support URL links in Help Menu

Solution:
Suppress the warning message in the System Admin desktop.