Release documentation - P&C Enhancements and requests

Problem:
Business Ledger – Column View, Sorting Ascending, Save Setting not saved in the DB.

Solution:
When column settings has been saved for a container so that one or more columns are sorted, either Ascending or Descending, and the user later change the Ascending flag from Yes to No or from No to Yes and again save this settings, the system must store this change in the database also after a refresh.

Workaround:
Remove the sorting of the actual column, then save the settings, refresh, and finally make new sorting of that column with the correct Ascending/Descending value to get that stored correctly in the database.

Root Cause:

Extent of Impact:

Impact on Existing Data

Recovery Method for Existing Data Affected

Problem:
UPR Order Creates 1 Worksheet with Incorrect FC Rate Applied

Solution:
When running the Unearned Premium Reserve order (UPR) for second time (it is correct when running the UPR for the first time), and the system makes adjustments to the existing unearned premium reserve bookings, we must make sure the system calculates the Functional Currency amounts with the SAME sign as its original amount. This means the system must follow the same logic as when the UPR order runs for the first time. The sign of the functional currency amounts (both 1 and 2) must be the same as the sign of detail amount itself.

Workaround:

Root Cause:

Extent of Impact:

Impact on Existing Data

Recovery Method for Existing Data Affected

Problem:
Unexpected Gov. Tax Error Triggered after entry code changed in the rule.

Solution:
If the GT Trigger entry code has been changed in the GT Rule after the worksheet has been created, manually or processed in eMessaging, so that the GT detail in the worksheet is no longer the GT Trigger entry code, then the system shall NOT trigger AC0837 again, but only validate the details on the worksheet against the ACTUAL GT Rules and the entry codes defined in them.

Workaround:

Root Cause:

Extent of Impact:

Impact on Existing Data

Recovery Method for Existing Data Affected

Problem:
Problem with Installment worksheet on ORP level for Non-Prop Treaty OCC, when there is a split % on P&L. The commission is getting split correctly on OCC level but not on ORP level when there are multiple ORPs attached.

Solution:
We need a special handling of the deduction defined as Amount when booking of instalments/adjustments on non-prop treaty OCC and when there are split of AC involved. We need BOTH to calculated down to ORP share, divide the Amount by number of instalments AND split it according to the AC split.

E.g. If there are 4 instalments each of Instalment premium amount 10000,00 and the deduction amount is 1000,00 (in same currency), and there are 2 ACs with split of 40/60 on the AC Split % tab, then the system shall for each instalment do the following:
Split the premium 4000,00/6000,00 on the two ACs and also split the deduction of 250,00 (1000/4 instalments) as 100/150 on OCC level.
And if the OCC has 2 ORPs attached each with 50% share each, then both Premium and Commission amount should again be split as 50% on both the ORPs.
As of now only the Premium amount is getting split correctly and not the Commission amount. 

Workaround:

Root Cause:

Extent of Impact:

Impact on Existing Data

Recovery Method for Existing Data Affected

Problem:
Multi GAAP Accounting Order sometimes creates corresponding As Original bookings on protecting Outward Cedent's Contract without Functional Currency 2, even if Functional Currency 2 is in use. Occurs when a split function in worksheet closing is applied due to amendment of Protection Assignment on the assumed contract. 

Solution:
Make sure Functional Currency 2 is always populated on corresponding As Original bookings when in use. 

Workaround:

Root Cause:

Extent of Impact:

Impact on Existing Data

Recovery Method for Existing Data Affected

Problem:
Instalment order does not calculate FC amount when reversal of instalment that has been booked via instalment order without refreshing the system.

Solution:
When a booked instalment throught instalment order, is reversed, we must make sure the Functional Currency is correctly set/calculated on the reversal details, even if the system has not been refreshed between the booking of the instalment through instalment order and the reversal of the same.

Workaround:
Refresh the system in between the instalment is booked via instalment order and when it is reversed from the instalment conditions.

Root Cause:

Extent of Impact:

Impact on Existing Data

Recovery Method for Existing Data Affected

Problem:
Error on 'Import Technical Worksheet from Spreadsheet' functionality if IP not existing for the given Business

Solution:
When using the function Import Technical Worksheet from Spreadsheet and the selected xls file contains a business and with an insured period that does not exist for this business then an error message must be presented in the Error List with a Description telling that the insured period does not exist for this business. This is the same if the given Business does not exist or the given Accounting Classification is not found on the business. The system shall not fall over with a walkback.

Workaround:
Can get around the problem by giving correct Insured Period in the xls file.

Root Cause:

Extent of Impact:

Impact on Existing Data

Recovery Method for Existing Data Affected

Problem:
GT Validation should not to be applied on OCC/ORP Businesses

Solution:
When making booking on outward business, e.g. prop or non-prop OCC/ORP, the system shall not perform the validation of Government Tax entry codes.
Booking on outward businesses shall behave as if the system parameter Government Tax Framework in use is OFF, i.e. it shall have no affect on bookings on outward business.

Workaround:

Root Cause:

Extent of Impact:

Impact on Existing Data

Recovery Method for Existing Data Affected

Problem:
The system does not consider margin and severe inflation percentage correctly and adds the defined percentage figure to the contractual base index instead of calculating this. 

Solution:
When index clause is either Margin or Severe inflation, the associated percentage field should not be added flat to the contractual base index but calculated from it.

Workaround:

Root Cause:

Extent of Impact:

Impact on Existing Data

Recovery Method for Existing Data Affected

Problem:
The Edit button on the Currencies tab on a Fac ORP

Solution:
Make sure the edit button on the Administration conditions, the Currencies tab, on facultative businesses, both AB and ORP is working, and on non-prop treaty AB, i.e. that it opens the whole A conditions in edit mode. Should work in the same way as the edit button the the Requirements tab.

Workaround:
Use the Edit option from the Accounts tab which give access to edit all tabs on the Administration conditions.

Root Cause:

Extent of Impact:

Impact on Existing Data

Recovery Method for Existing Data Affected

Problem:
Inactivated worksheet types are still shown and selectable in worksheet closing window

Solution:
When worksheet statuses Rejected and/or Suspended are inactivated in the reference table 168 Worksheet Status, and the system parameter Advanced use of Worksheet Status is selected, then the system must disable/hide these two statuses on the worksheet closing window in the Change to drop down field. This must be the case both on Technical and Claim worksheet.

The above is limited to these two statuses, i.e. the system will always show Closed, Inactivated and Authorized, even if they are inactivated.

Workaround:

Root Cause:

Extent of Impact:

Impact on Existing Data

Recovery Method for Existing Data Affected

Problem:
Bookings are not correctly EC Transformed when ECTT is defined on ORP level attached to Fac OCC

Solution:
Preconditions:
An Assumed Business is protected by a FAC OCC and Entry Code Transformation Term is defined on the ORP Placement of this OCC, and booking details exists on these businesses so that the entry code is transferred from the Assumed Business to the ORP.
When the signed share is changed on this ORP so that correction bookings takes place on the ORP, then the system must also correct the detail with the entry code that has been transferred in the same way as all other details that are corrected.

Workaround:
It works fine if the ECTT is defined on the Fac OCC so that it affects all ORPs

Root Cause:

Extent of Impact:

Impact on Existing Data

Recovery Method for Existing Data Affected

Problem:
The Open Worksheet Mass Update order does not refresh the list after worksheets are Inavtivated.

Solution:
On the Open Worksheet Mass Update order, if the user selects the option Inactivate or Inactivate Selected, so that some of the listed worksheets are inactivated, make sure the system refresh the list, i.e. automatically do the functions List Open Worksheet as if the user did this himself/herself. By refreshing the list, and the user selects the option Close or Close Selected, this will make sure the system only close worksheets that are still open and not closing worksheets that recently have been inactivated.

This refresh of the listed open worsheets must also take place when the options Close or Close Selected have been executed as well, so that the actual open worksheets remains in the list.

Workaround:
The Open Worksheet Mass Update order, after worksheets are Inavtivated, make sure you select the option List Open Worksheets manually before you select any of the options Close or Close Selected.

Root Cause:

Extent of Impact:

Impact on Existing Data

Recovery Method for Existing Data Affected

Problem:
ACORD eMessaging Services TimeStamp fields ae being set to null.

Solution:
Ensure that the TimeStamp field is set with current date time as previously.

Workaround:

Root Cause:
Library update in SICS 22.2 missing the default value

Extent of Impact:

Impact on Existing Data

Recovery Method for Existing Data Affected

Problem:
Reinsurance Program/non-proportional treaty parts (XL)
Creating multiple Treaty outlines with different Treaty Type of Cover, the system does not accept Unlimited Cover even if Treaty Types of Cover are different (e.g. Clash Cover and Cost Cover).

Solution:
When creating treaty outlines on a Reinsurance Program (by adding on the program or by creating from assumed businesses) and the outlines have various Treaty Types of Cover, the system should make sure that limits for the same treaty types of cover do not overlap. This should also happen when the cover is unlimited.
The system should only stop you with the message 'Unlimited treaty outline must be defined as top layer' if the outline with unlimited cover has an excess amount less than another treaty outline with the same Treaty Type of Cover.

Workaround:

Root Cause:

Extent of Impact:

Impact on Existing Data

Recovery Method for Existing Data Affected

Problem
Find facilities some times abend when the search involves a high number of business partners. 

Solution:
Extend Base Company Segregation: Selected
and
Hide Business Partners: Selected and/or Hide Insureds: Selected

When the system finds business partners to show the user, (partners linked to the user’s base companies), and the same partner is linked to several base companies, the system should not include this business partner several times in the request. Instead, the business partners in common to several Base Companies, should be included only once, so that the number does not exceed the max number for Oracle (1000) or the max for SQL Server (2100).

Workaround:

Root Cause:

Extent of Impact:

Impact on Existing Data

Recovery Method for Existing Data Affected

Problem:
The Claim Action Date is cleared although Loss Expense Reserve balance is present

Solution:
When validate against reserves parameter is activated, the system must validate against all reserves, and not only Loss Reserves

 Workaround:

Root Cause:

Extent of Impact:

Impact on Existing Data

Recovery Method for Existing Data Affected

Problem:
Accuracy validation error AC0395 for missing reinstatement detail in worksheet appears when booking loss reserves only

Solution:
If there is a zero amount calculated then there should be no trigger for AC0395 for missing reinstatement detail in worksheet

Workaround:

Root Cause:

Extent of Impact:

Impact on Existing Data

Recovery Method for Existing Data Affected

Problem:
The system fails to validate that the classifications of the OCC and IGC are matching, and allows worksheet to be closed.

Solution:
When the classifications are not matching the system should raise error CM0602 and prevent closing of the worksheet.

Workaround:

Root Cause:

Extent of Impact:

Impact on Existing Data

Recovery Method for Existing Data Affected

Problem:
Error message which is appearing when selecting to generate worksheet from FGU from an inactivated claim is not informative.

Solution:
Disable both worksheet options from an inactivated claim.

Workaround:
Activate the claim

Root Cause:

Extent of Impact:

Impact on Existing Data

Recovery Method for Existing Data Affected

Problem:
The Claim FGU Upload fails to consider different setting for reinstatement - they all have to be set to Y in order to calculate for any

The Claim FGU Upload fails to create worksheets (and therefore reinstatements) - when a second upload on existing claims is created.

The Claim FGU Upload returns error message about reinstatement  - so if upload contains a number of claims for which the reinstatement cannot be calculated, the user will have to address this message a number of times

Solution:
The upload must be able to consider different reinstatement calculation per claim.

The upload must be able to create the FGU worksheet for subsequent advisories.

If the upload cannot create reinstatement despite input file indicating this, do not raise the message that it cannot be calculated*.*

Workaround:
For reinstatement issue - the reinstatement indicator can be set to the same for all claims included.

Root Cause:
SE-1798

Extent of Impact:

Impact on Existing Data

Recovery Method for Existing Data Affected

Problem:
Cannot assign a claim to next insured period although Loss Portfolio condition is defined

Solution:
When Loss Portfolio condition is defined, the validation that the Original Policy Period Start date is within Insured Period must be removed.

Workaround:

Root Cause:

Extent of Impact:

Impact on Existing Data

Recovery Method for Existing Data Affected

Problem:
During the processing of CM eMessages the system is changing the disposition of the claims to “Accepted”.

Our Claims managers do not want the B2B process to change claims dispositions.

Solution:
For B2B, if the Claim Disposition is Pending then it is being updated to Accepted based on no response details in the message. This should not be the case as it should remain on Pending. If there are are no specific Response details then the current Disposition should not be changed.

Workaround:

Root Cause:

Extent of Impact:

Impact on Existing Data

Recovery Method for Existing Data Affected

Problem:
There is some outstanding work for upload of claim figures:

• When file contains details such as title, acct period, ect these are not reflected in the created worksheets
• The claim ID max length is validated to be 10 positions - the db field length is 30

Solution:
The upload should create worksheets as per input file.

The claim ID length must support the db field length

Workaround:
Modify directly in the open worksheet

Root Cause:
SE-1798

Extent of Impact:

Impact on Existing Data

Recovery Method for Existing Data Affected

Problem:
Worksheets Created by eMessage Don't Follow 'Leaf Section' Parameters

Solution:
When the system parameter 'Do not allow create Technical Worksheet for non-leaf sections' is selected and the user selects Process on an eMessage, then the system must read this parameter and present the same message 'Create booking on non leaf section is not allowed' if trying to book on a Technical worksheet on a section that is not on the lowest level, as when the user selects the option Swap to Worksheet and applies this worksheet.

When the system parameter 'Create claim only on lowest leaf section level' is selected and the user selects Process on an eMessage, then the system must read this parameter and present the same message 'Create booking on non leaf section is not allowed' if trying to book on a Claim worksheet on a section that is not on the lowest level, as when the user selects the option Swap to Worksheet and applies this worksheet.

Workaround:

Root Cause:

Extent of Impact:

Impact on Existing Data

Recovery Method for Existing Data Affected

Problem:
Unexpected error messages are raised on both lead and follower when expenses are Part of Liability, but loss and expense are not split as per SICS calculation rules.

Both lead and follower raises error for CheckPreviouslyPaid rule - on both the amount is correct, but displays as negative for message and positive for SICS.

Both lead and follower also raises error for FGUClaimAmounts.

On lead the lower container is not populated.

On follower the lower container is populated and displays message value of previously paid loss and expense and SICS value equal to current message booked loss amount. 

Solution:

• The CheckPrevious rule should compare the negated claim ledger amount, not the displayed, with the message amount. It seems as if the message amount is a negative amount, and SICS amount is a positive amount.
• The CheckPrevious rule SICS amount includes both ec 30 and ec 32 (ie Paid Loss and Paid Expense), although usage is only for paid loss. (Note however the enhancement request for this) Would have expected that the check previous prior to enhancement only checked the ec defined in usage.
• When FGUAmounts rule sets an error on lead, the lower container should be populated (as it is for the follower)
• The rule should compare the 'same' amount' for message and SICS.

Workaround:

Root Cause:

Extent of Impact:

Impact on Existing Data

Recovery Method for Existing Data Affected

Problem:
RIP not indexing
Why is the LinkTAReinstatementToCMReferenceRule reporting a different IP on the reinstatement compared to the claim movement, and why the rule is not showing any detail in the lower frame of the error.

Solution:
The problem details on the LinkTAReinstatementToCMReferenceRule should show the correct problem description and include the CM References from the linked Claim Signing TA (if there is one) as per other problems raised on the rule.

Workaround:

Root Cause:

Extent of Impact:

Impact on Existing Data

Recovery Method for Existing Data Affected

Problem:
It is required that LloydsOutwards messages based on certain conditions be set to “Informational”. Although other types of messages such as Tech Account and Claim Movement messages are moving to Informational status but same is not working for LloydsOutwards messages. The rules are not available for LloydsOutwards.

Solution:
As per functionality for other message types, if the message function identification is set to “Informational” for a particular type of message then based on the input value, the message should move to informational status as soon as the message is processed and system finds the value within the message details.

The rule to change message status to Informational SetStatusToInformationalByMessageFunction should also be available for LoydsOutwards.

Workaround:

Roset ot Cause:

Extent of Impact:

Impact on Existing Data

Recovery Method for Existing Data Affected

Problem:
System abends when testing the DuplicateMessageMappingRule for Claim movement messages.

Solution:
When there is a duplicate message mapping is created for the CM, then the DuplicateMessageMappingRule should consider the duplicate message mapping set to automatically discard the duplicate CM Messages.

Workaround:

Root Cause:

Extent of Impact:

Impact on Existing Data

Recovery Method for Existing Data Affected

Problem:
Due Date in SICS BO does not match with SICS System.

Solution: 
As it is going to be a Supplemental stored procedure so the Identifier should be picked up dynamically. Need to change the script to fetch the identifier id on runtime.

Users have the option to modify due date of closed worksheet. Whenever, they are updating the due date of closed worksheet, those changes are not reflecting in BOAC_PC_FACT table. Because Incremental load of BOAC jobs will not fetch the details of closed worksheet. It will update open/new worksheet related information. 

So, we can provide DB Update statement to users to update BOAC_PC_FACT table (For Closed worksheet information). This update statement should go with SICS DB Supportive scripts.

Declination Reason:

Workaround:

Root Cause:

Extent of Impact:

Impact on Existing Data

Recovery Method for Existing Data Affected

Problem:
Definition (Payment partner contact ) cannot work as one should be linked to the BOAC structure and the other should be linked to the AC_LEDGER_BALANCE structure. When using this SQL would get a cartesian product for one of the options. 

Solution:
For Payment Partner: 
To resolve this cartesian product issue create alias tables for Party and Party Relationship and name those alias tables as 
BOAC_PTY_RemContact
BOAC_SJ_PTY_REL_Rem
and update the Payment partner contact details with alias tables. 

For Responsible Partner: 
To resolve this cartesian product issue create alias tables for Party and Party Relationship and name those alias tables as 
BOAC_PTY_SecPayParCON
BOAC_SJ_PTYREL_SPPCon
and update the Responsible partner contact details with alias tables.

Declination Reason:

Workaround:

Root Cause:

Extent of Impact:

Impact on Existing Data

Recovery Method for Existing Data Affected

Problem:
Incorrect Number of Insured Period Days are used by business objects.

Solution:   
The SQL query needs to be updated for the object insured period duration days to get the correct data.

Declination Reason:

Workaround:

Root Cause:

Extent of Impact:

Impact on Existing Data

Recovery Method for Existing Data Affected

Problem:
The object 3rd party Insured(Y/N) is not present in the Universe.

Solution:
Object needs to be added into Partner Unified Universe 22.3

Declination Reason:

Workaround:

Root Cause:

Extent of Impact:

Impact on Existing Data

Recovery Method for Existing Data Affected

Problem:
BO Views cannot be dropped from SICS System admin as there is  no option to drop views. And also few views are missing so need to add those views.

Solution:
To create an option for Dropping BO Views in and missing views need to be created at SICS Admin side.

Important Note:
Simplest option is to add a Drop BO Views option on the right hand side.
We should name the options 'Build BO Reporting Views' and 'Drop BO Reporting Views'.
Note that the 'Drop all User Views' option ignores views that start with V_
You can model this function with a different view filter.

Declination Reason:

Workaround:

Root Cause:

Extent of Impact:

Impact on Existing Data

Recovery Method for Existing Data Affected

Problem:
1. Below objects are not retrieving expected data at report level.

• ReinsurerLoC Balance Amount (Orig) A

• Reinsurer Trust Balance Amount (Orig) A

• Reinsurer Funds Held Balance Amount (Orig) A
   

2. Report level getting null values

Solution:
1. ReinsurerLoC Balance Amount (Orig) A replaced with 'Reinsurer LoC Balance Amount (Orig)'

2. Reinsurer Trust Balance Amount (Orig) A replaced with 'Reinsurer Trust Balance Amount (Orig)'

3. Reinsurer Funds Held Balance Amount (Orig) A replaced with 'Reinsurer Funds Held Balance Amount (Orig)'

4. used the 'is not null' report filter to avoid null values at report level

Should replace below joins with

Need to update the join below join with 'FUNDS_HELD'

Workaround:

Root Cause:

Extent of Impact:

Impact on Existing Data

Recovery Method for Existing Data Affected

Problem:
After Running BOAC004 & BOAC005 scripts, Data is not loading into BOAC Tables in all database platforms.

Solution:
Update the  BOAC004 & BOAC005 scripts to generate the DIM_KEY values and correct the syntax of SQL commands across all database platforms. 

Declination Reason:

Workaround:

Root Cause:
DIM_KEY values are not generated and syntactical issues.

Extent of Impact:

Impact on Existing Data

Recovery Method for Existing Data Affected

Problem:
Object no longer exists issue with BOBU001 Oracle database script. In Oracle, the old solution of BOBU001 script is truncating the table and reloading data into BO_PREM_CURR table. This is causing problem 'Object no longer exists' while running the reports as the table is empty. 

Solution: 
Implement the Merge operation in BOBU001 script for Oracle database.

Declination Reason:

Workaround:

Root Cause: 

Extent of Impact:

Impact on Existing Data

Recovery Method for Existing Data Affected

Problem:
Missing database views and DIMDATE Table's data population script.

Solution:
Needs to be added missing views and missing DIMDATE Table's data population script in SICS.

Declination Reason:

Workaround:

Root Cause:

Extent of Impact:

Impact on Existing Data

Recovery Method for Existing Data Affected

Problem: 
In SQL of the objects Level of Business(code),Level of Business, Type of Business(code),Type of Business, Business ID, Business Title, Former Business ID, Business Title, Related OCC Business ID, Business title, Business Title, Business ID, Underwriting Year, Section Position NO, Section Name, Claim ID, Claim Name, Headline Loss ID, Headline Loss Name getting issue so that we are not getting correct list of values.

Solution: 
SQL of the objects needs to be changed in the PC Main Unified universe.

Declination Reason:

Workaround:

Root Cause:

Extent of Impact:

Impact on Existing Data

Recovery Method for Existing Data Affected

Problem:
This new view V_COLLATERAL_DATE is required in unified CEDE, Life, PC Main universe. So needs to be added to the drop and create script inside SICS Admin. To the function which generates the needed views for reporting.
 
Solution:
Need to add this view in all database in SICS. So that it can be created in databases and used in universes.
 
CREATE VIEW V_COLLATERAL_DATE
AS
SELECT
OBJECT_ID,
convert(char(8),getdate(),112) AS TODAY,
Convert(char(8),BP_LOC.EFFECTIVE_DATE,112) AS EFFECTIVE_DATE,
convert(char(8),BP_LOC.EXPIRATION_DATE,112) AS EXPIRATION_DATE
FROM
BP_LOC
 
Declination Reason:

Workaround:

Root Cause:

Extent of Impact:

Impact on Existing Data

Recovery Method for Existing Data Affected

Problem:
While parsing the base and target objects under Insurable Peril Cession folder getting the Cartesian product issue which produces the incorrect results at the report level.
 
Solution:
These two objects “Base” and “Target” needs to change from CESSION3.FK_CURRENCY to instead be V_CESSION3.FK_CURRENCY and verify the results

Declination Reason: 

Workaround:

Root Cause:

Extent of Impact:

Impact on Existing Data:

Recovery Method for Existing Data Affected:

Problem:
The GL universe the objects Booking Year Period Start Date and Booking Year Period Start Date - Local need to be corrected . While running the reports the accurate data is not populated in the list of values M11 is missing due to the wrong code.
 
Solution:
Replace the code of objects Booking Year Period Start Date and Booking Year Period Start Date - Local where ever 'M01' to 'M11'.
 
Declination Reason: 

Workaround:

Root Cause:

Extent of Impact:

Impact on Existing Data:

Recovery Method for Existing Data Affected:

Problem:
The following objects has concat issues which need to be corrected and check the compatibility with other databases.
Payment Partner Contact First Name,
Payment Partner Contact Last Name,
Payment Partner Contact,
Payment Partner Contact Title,
Payment Partner Contact Middle Name,
Responsible Partner Contact Name,
Responsible Ptnr Contact Title,
Responsible Ptnr Contact Last Name,
Responsible PtnrContact Middle Name,
Responsible Ptnr Contact First Name,
Balance Revaluation Booking Year Period,
Bank Account,
Booked Year And Month,
Entry Revaluation Booking Yr Period,
ORP Booking Year Period - Local,
Paired By,
Accounting Year and Quarter,
Booking Year Period - Local - Latest,
Booking Period Start Date,
Booking Period End Date,
Booking Year Period - Local,
Booking Year Period - Global,
Booking Year Period - Legal,
Pairing Booking Year Period (Detail),
Pairing Booking Year Period Start Date (Detail),
Pairing Booking Year Period End Date (Detail),
WS Inactivated By,
WS Registered By,
WS Last Updated By,
WS Closed By,
Booking Year Period (Paired),
Pairing Booking Year Period,
Remittance Authorized By,
Remittance In Progress By,
Remittance Registered By,
Remittance Final By,
Triangulation Year Period,
Triangulation Year Period Name,
Triangulation Year Quarter,
Party Type,
Party Contact Name,
Created By,
Actual Run By,
Business Created By,
Business Last Updated By,
Creator Name,
Notifier Name,
Notifier (send to),
Modified By,
Signature,
Accounting Year and Period,
From Booking,
To Placements,
From Original,
To Booking,
Broker Contact Person,
Cedent Contact Person,
Former Broker Contact Person,
Former Cedent Contact Person,
Former Reinsurer Contact Person,
Pre-Producer Contact Person,
Producer Contact Person,
Reinsurer Contact Person,
Tax Authority Contact Person,
Premium Payment Warranty,
Premium Payment Warranty Outward,
Final Year Calculation After-DC,
Final Calculation After-Comm Ded,
Loss First Retained Period,
Loss Last Regulation Period,
Premium First Retained Period,
Premium Last Regulation Period,
Recorded By,
Insured Period Last Updated By,
Underwriting Year and Month,
Insured Period Created By,
Updated By,
First Calculation After,
Subsequent Calculations,
Final Calculation After,
Created By Full Name,
Limit User,
Share User,
Claim Signature,
EDI FGU User,
HLEG Created By Full Name,
Claim Program Handler,
Claim Manager,
Claim Analyst,
Updated By,
Estimated By,
AB Insured Period Start (Char),
AB Insured Period End (Char),
CP Responsible,
Booking Year Period - Local LOV,
Underwriting Year and Month LOV,
Triangulation Year Period LOV,
Underwriting Year - Per Start LOV,
Underwriting Year - Period End LOV,
LOV Person Full Name,
LOV User Full Name.

Solution:
Update the Concat function correctly as shown below
concat(concat(TRIG_YEAR.YEAR_NO,' '),TRIG_PERIOD.TRIG_PERIOD_NAME)
 
Declination Reason: 

Workaround:

Root Cause:

Extent of Impact:

Impact on Existing Data

Recovery Method for Existing Data Affected

Problem:
There is a need to slightly adjust these two views V_FC_REVAL_BAL_BYRP, V_FC_REVAL_DTL_BYRP in respect to finding the latest date within a booking year period. It have a big impact so need to adjust this. its not often that revaluation is happening at the same period with years in-between but as it can happen.

Need to alter the view V_BOAC_STL_PAIRING too.

Solution:
Alteration is need to this views V_BOAC_STL_PAIRING, V_FC_REVAL_BAL_BYRP, V_FC_REVAL_DTL_BYRP

Declination Reason:

Workaround:

Root Cause:

Extent of Impact:

Impact on Existing Data

Recovery Method for Existing Data Affected

Problem:
About this loose structure in the universe that is missing a join to the RC_CLAIMS. If the new view V_CLAIMFGU_ADVICRC is to replace the three highlighted tables or if the three highlighted tables should still be in the universe and the objects highlighted should still come from these three tables.
 

Solution:
Adjust the joins between the tables properly. If the new view V_CLAIMFGU_ADVICRC is to replace the three highlighted tables or if the three highlighted tables should still be in the universe and the objects highlighted should still come from these three tables.

Declination Reason: 

Workaround:

Root Cause:

Extent of Impact:

Impact on Existing Data

Recovery Method for Existing Data Affected

Problem:
Some fields are wrong In these views V_AMENDMENT_COND,V_DATE_LOV , V_BOAC_STL_PAIRING and also PARENT_SECTION field is missing in this view V_REPORTING_TABLE. Due to that getting parsing errors in PC main universe. Alteration is required in these views in SICS system admin.

Solutions:
Need to alter the views V_AMENDMENT_COND, V_DATE_LOV , V_BOAC_STL_PAIRING in SICS.
Need to add PARENT_SECTION field in V_REPORTING_TABLE in SICS.

Declination Reason:

Workaround:

Root Cause:

Extent of Impact:

Impact on Existing Data

Recovery Method for Existing Data Affected

Problem:
Headline Loss Name Object definition under Headline Loss Protection Agreement folder is wrong as it is pointing to the wrong table and HDLINE_PROT_AS table outer joins cordiality with HL_CLAIMS, HL_BUSINESS,HL_LCP_COVER and HL_SECTION_DETAIL is wrong.

Solution: 
Change the definition of 'Headline Loss Name' object which is under 'Headline Loss Protection Agreement' folder
concat(concat(concat(concat(HL_CLAIMS.CLAIM_IDENTIFIER, ''), HL_CLAIMS.LOSS_NAME), ''),  HL_CLAIMS.LOSS_START_DT)
since all the others are coming from the HL_CLAIMS
Update the outer joins and their cardinalities for HDLINE_PROT_AS table joins with HL_CLAIMS, HL_BUSINESS,HL_LCP_COVER and HL_SECTION_DETAIL.
 
Declination Reason:  

Workaround:

Root Cause:

Extent of Impact:

Impact on Existing Data

Recovery Method for Existing Data Affected

Problem:
Parsing Error in universe (PostgreSQL connection) on this VIEW V_NOT_RENEWED due to wrong NEXTSTART filed and also outer join query is wrong.

Solution:
Need to be Altered NEXTSTART field and outer join query in this view VIEW V_NOT_RENEWED in SICS PostgreSQL database level.

Declination Reason:

Workaround:

Root Cause:

Extent of Impact:

Impact on Existing Data

Recovery Method for Existing Data Affected

Problem:
Object definition and joins are wrong under Headline Loss Protection Agreement.

1) The outer join is on the wrong side, it should be on the another side
between the BOAC_DIM_PARTY,BOAC_BP_PP_DETAIL,BOAC_BP_RP_DETAIL
BOAC_BP_PP_DETAIL-> BOAC_BP_PP_LOC and
BOAC_BP_RP_DETAIL -> BOAC_BP_RP_LOC
also the two tables BP_PP_LOC and BP_RP_LOC should not go into BOAC_DIM_PARTY.BP_OBJECT_PARTY key, it should go to the right BP and RP key instead

2) The following joins should be left outer join
Reporting_TABLE -> BOAC_LF_FACT

3) Wrong join between V_ENTRYCODE_DATES and BOAC_LF_FACT only be joined to object ID, the FK_BALANCE 

4)Wrong joins between
BP_DETAIL_REINSURER, BP_DETAIL_CEDENT,BP_LOC_REINSURER,BP_LOC_CEDENT.

5)The following outer joins must be addressed
BP_DETAIL_RESPONSIBLE_PRTNR, BP_DETAIL_DETAIL_PAYMENT_PARTNER,BP_LOC_RAYMENT_PARTNR,BP_LOC_RESPONSIBLE_PRTNR.

6) The Reinst. Exchange Rate, Reinst. Currency (Code), Reinst.Curreny Objects are not linked properly at Universe structure  

Solution: 
Change the definition of 'Headline Loss Name' object which is under 'Headline Loss Protection Agreement' folder
concat(concat(concat(concat(HL_CLAIMS.CLAIM_IDENTIFIER, ''), HL_CLAIMS.LOSS_NAME), ''),  HL_CLAIMS.LOSS_START_DT)
since all the others are coming from the HL_CLAIMS
1) Update the following joins
between the BOAC_DIM_PARTY,BOAC_BP_PP_DETAIL,BOAC_BP_RP_DETAIL
BOAC_BP_PP_DETAIL-> BOAC_BP_PP_LOC and
BOAC_BP_RP_DETAIL -> BOAC_BP_RP_LOC
also the two tables BP_PP_LOC and BP_RP_LOC should not go into BOAC_DIM_PARTY.BP_OBJECT_PARTY key, it should go to the right BP and RP key instead
 2) Update to left outer join
Reporting_TABLE -> BOAC_LF_FACT
3)The join between V_ENTRYCODE_DATES and BOAC_LF_FACT only be joined to object ID, the FK_BALANCE should be taken out from the join
4) Update the following outer joins
BP_DETAIL_REINSURER, BP_DETAIL_CEDENT,BP_LOC_REINSURER,BP_LOC_CEDENT.
5) Update the outer joins for the below joins BP_DETAIL_RESPONSIBLE_PRTNR, BP_DETAIL_DETAIL_PAYMENT_PARTNER,BP_LOC_RAYMENT_PARTNR,BP_LOC_RESPONSIBLE_PRTNR.
6) The Fixed Reinst. Exchange Rate, Reinst. Currency (Code), Reinst.Curreny Objects need to be updated and these objects will not work properly as the tables are not linked to anything else in the universe structure
7) The V_REPORTING_DATES3->BUS_PER_EST_UW2 the outer joins must be the other side.

Declination Reason:  

Workaround:

Root Cause:

Extent of Impact:

Impact on Existing Data

Recovery Method for Existing Data Affected

Problem:
The structure of the universe and objects are not properly placed.
1) The two Balance Revaluation Currency Func2 (Code) and Balance Revaluation Currency (Code) (Func2) objects …universe do not have two of them.
2) Balance Revaluation Transf. to GL (Date) object is not parsing because it is pointing to the wrong column (V_FC_REVAL_BAL_BYRP2.TRANS_DATE).
3) Wrong Balance Revaluation Booking Year object ,
4) Balance Revaluation Amount Unsettled (function). The unsettled and settled for function and func2 objects are failing because of the earlier problem with the view having the wrong definition. 
5) The ghost join need to be remove
   
6) The Balance Revaluation Currency Func2 (Code) and Balance Revaluation Currency (Code) (Func2) sequence is not correct.

Solution: 
1) The two Balance Revaluation Currency Func2 (Code) and Balance Revaluation Currency (Code) (Func2) objects …universe do not have two of them so one need to be deleted.
2) .V_FC_REVAL_BAL_BYRP2.TRANS_DATE need to be updated with V_FC_REVAL_BAL_BYRP2.TRANS_TO_GL_DATE
3) update the Balance Revaluation Booking Year object from “…{}TO” to “BOOKING_YEAR{_}_PERIOD”.
4) Balance Revaluation Amount Unsettled (function) needs to be updated. So this needs to be changed in the universe to match what is in the database view.

5) The Ghost joins must be deleted
6)The structure of objects are  re-organize the objects so that we first start with the “generic” objects for func and func2, like the dates and Y/N etc. then put all the func objects together under the func currency and doing the same with func2 so that all func2 are gathered under the func2 currency. This way it will be a lot easier to select the right objects without having to scan through the whole list of objects.

Declination Reason:  

Workaround:

Root Cause:

Extent of Impact

Impact on Existing Data

Recovery Method for Existing Data Affected

Problem:
LOV/Today and System Dates/Todays Date, these two objects are defined as characters so object incompatible error displayed while doing the check integrity.
 
Solution: 
( LOV/Today and System Dates/Todays Date) objects are need to be updated as dates instead of character so that the error will be resolved after changing the data type at the cede universe.

Declination Reason:  

Workaround:

Root Cause:

Extent of Impact:

Impact on Existing Data

Recovery Method for Existing Data Affected

Problem:
The bunch of loops are appeared while doing the check integrity and these are retrieving incorrect results while running the report.

Solution: 
Need to rectify the loops by create alias tables for “REF_RevalBal”, “CNU_CURR_RevalBal”, “CNU_CURR_RevalBalFC2”,” V_FC_REVAL_BAL_LATEST” and provide valid joins.

Declination Reason:  

Workaround:

Root Cause:

Extent of Impact:

Impact on Existing Data

Recovery Method for Existing Data Affected

Problem:
Outer joins cardinality is not correct, So that getting wrong data while running report for the following joins
BUS_RETRO_2 > PTY_BusRetro , AC_LEDGER_DETAIL> REF_settlFlag , DETAIL_BALANCE-> REF_settlFlag2 and DETAIL_BALANCE-> REF_Bal_Type.

Soultion:
Change the cardinality of the outer joins for the motioned tables.

Declination Reason:  

Workaround:

Root Cause:

Extent of Impact:

Impact on Existing Data

Recovery Method for Existing Data Affected

Problem:
Base(Paired) and Target(Paired) objects are coming from the wrong table(BOAC_STL_PAIR2) which leads to wrong output of data in the report.

Solution:

• Two objects, needs to be switched: from V_BOAC_STL_PAIR2 and not from the BOAC_STL_PAIR2 table

• No objects should be coming from this table, they should all be switched to the V_ version of it, the V_BOAC_STL_PAIR

Declination Reason:  

Workaround:

Root Cause:

Extent of Impact:

Impact on Existing Data

Recovery Method for Existing Data Affected

Problem:
The following four objects are coming from the wrong table DETAIL_BOAC_STL_PAIR because DETAIL_BOAC_STL_PAIR is a standalone table. So Output is wrong.

• Detail Settlement Indicator
• Detail Settlement Indicator (Code)
• Detail Amount Unsettled (Base)
• Detail Amount Settled (Base)

Solution:
The above-mentioned objects should not come from DETAIL_BOAC_STL_PAIR they should be coming from the V_DETAIL_BOAC_STL_PAIR instead which is alias table of V_BOAC_STL_PAIRING and connected to the DETAIL_BALANCE so that the output will be accurate.

Declination Reason:  

Workaround:

Root Cause:

Extent of Impact:

Impact on Existing Data

Recovery Method for Existing Data Affected

Problem:
Below objects are not having the correct object format
“Underwriting year”, “Value – Date Year”, “Annulment Date “. So while creating the reports we are getting Underwriting Year as dd.MM.yyyy format and Value - Date Year as same as underwriting year format only. And Anullment Date is not coming form V_BOAC_STL_PAIR alias table.

Solution:
For the Anullment Date object:
Since PC universe is having anul_timestamp in the AC_STL_PAIRING and therefore also in the views V_BOAC_STL_PAIR should not move the anul_timestamp to come from this table instead of the alias. So that the SQL instead become V_BOAC_STL_PAIR.ANUL_TIMESTAMP.

Change the object format for the Underwriting Year at the universe level (PC and Life) as 0 then the list of values will be like '1234','2345'.

Change the object format for the Value – Date Year at the universe level (PC and Life) as yyyy then the list of values will be like '2001,'2020'.

Declination Reason:  

Workaround:

Root Cause:

Extent of Impact:

Impact on Existing Data

Recovery Method for Existing Data Affected

Problem:
Currently Objects from Object1051 down to Object1006 to have the next object to be Object1000. All that need is rearrangement so they will again become in number order.

Solution: 
In User Custom objects (Class), all the objects are not arranged in ascending order, and it has to be numbered in ascending order so that it starts with Object1000 and Object1001 and soon.

Declination Reason:  

Workaround:

Root Cause:

Extent of Impact:

Impact on Existing Data

Recovery Method for Existing Data Affected

Problem: 
In PostgreSql, Timestamp is truncating in the below three tables. Due to this, Data is not matching across database platforms after running BOAC005 and BOAC006 scripts.
BOAC_WK1_PAIRING, BOAC_WK2_PAIRING, BOAC_STL_PAIRING.

Solution: 
Change the PAIRING_TIMESTAMP field datatype from DATE to TIMESTAMP for BOAC_WK1_PAIRING, BOAC_WK2_PAIRING and BOAC_STL_PAIRING tables. 

Declination Reason: 

Workaround:

Root Cause:  

Extent of Impact:

Impact on Existing Data

Recovery Method for Existing Data Affected

Problem:
When using an Oracle DB in 22.4, the view V_BOAC_STL_PAIRING has a column LTST_PAIRING_TIMESTMP_IN_BYRP which is incorrectly named. It should be LATEST_PAIRING_TIMESTAMP_IN_BYRP

Solution:
Ensure the column names are consistent on all platforms.

Problem:
The security domain restriction 'Business Structure' for programs stops editing conditions of assumed business when this is opened from a program.

Solution:
Enhancement

Workaround:

Root Cause:

Extent of Impact:

Impact on Existing Data

Recovery Method for Existing Data Affected

Problem:
Security to Prevent Editing/Deleting of Underwriters Estimates (Pricing Estimate)

Solution:
When use-case 'Business Condition Underwriter's Estimate __ Pricing Estimate' are in use, we must make sure system works as per the provided rights i.e., (C)(U)(D). If use case has only (C) rights, User should be able to create the Pricing Estimate in FIRST Version and will not be able to Update OR Delete the Pricing Estimates further. If User needs to update the condition further, then SICS should seeking for access type (U) and make sure User can delete the Pricing Estimates when (D) rights assigned to the Use Case.

Workaround:

Root Cause:

Extent of Impact:

Impact on Existing Data

Recovery Method for Existing Data Affected

Problem:
The name of 'Allow Booking ignoring Specific Closure Terms for Technical and Claim Worksheets' in System User Settings is misleading

Solution:
When you from the SICS Desktop, open the Security under System Administration, double click on one of the users on the System Users tab and navigates to the Accounting Settings you will see two tick boxes, one of them with the label 'Allow Booking ignoring Specific Closure Terms for Technical and Claim Worksheets'. The name of this tick box should be changed to “Allow Booking within the Specific Closing Booking Terms for Technical and Claim Worksheets” to make it better and more understandable.

Workaround:

Root Cause:

Extent of Impact:

Impact on Existing Data

Recovery Method for Existing Data Affected

Problem:
System abends when creating business with sections using service SicsCreateBusinessWithSection and the XSD Type is BusinessPartnerFindPartial

Solution:
Creating business with section(s) using web service SicsCreateBusinessWithSection and the XSD Type is BusinessPartnerFindPartial, system should create new business in the same way as when XSD Type is BusinessPartnerReference

Workaround:

Root Cause:

Extent of Impact:

Impact on Existing Data

Recovery Method for Existing Data Affected

Problem:
Getting walk back for Installment bookings as of webservicesint.AccountingCreateBalanceGroupInputWSI

Solution:
When Instalments are booked via web service bookInstalment and Government Tax details have been automatically calculated and added on the worksheet created by the web service, AND the worksheet becomes Closed, then the system must do the following:
1. When the worksheet is set to Closed by the web service, then the system must check if the Government Tax Accounting task is given to a partner on the actual insured period and if this is NOT selected, the system must add together all balances linked to the same instalment in an Account Balance Group. If more than one instalment is booked from this soap, then one ABG must be created per instalment and the GT detail is added to the ABG with the matching Due Date. The Payment Partner, Base Company, Due Date and Accounting Year/Period for this ABG shall be taken from the instalment balance. As BP Reference the system must set the Worksheet Id and instalment number, e.g. TW12345 - Instalment 1 for the 1st instalment or TW12346 - Adjustment 1 for the 1st Adjustment.

2. If the Government Tax Accounting task is given to a partner then the system will keep the instalment/adjustment details as separate balances, create separate balances for the GT details defined in the entry code group GOVTAX (within the EC Group Category 'Business Partner Ledger Balance Split'), and set the Notes on ALL these GT balances to Government Tax and create separate balance for the other GT details (not defined in the above group). When the worksheet is closed the system will group the instalment/adjustment balance and the GT balance without the above Notes, in an Account Balance Group so that it appears financially on the BP Ledger as one balance and can be easily paired with the remittance. The GT balances with the above Notes will be kept outside the Account Balance Group. For the information to be set on the ABG, see above point 1.

Workaround:

Root Cause:
Missing implementation of the fix done according to SICSR-22902 in 22.3 for web service

Extent of Impact:

Impact on Existing Data

Recovery Method for Existing Data Affected

Problem:
Using web service, Non-proportional protection is not added if non-proportional protection already exists

Solution:
Using Web Service addOutwardCedentContract to assign non-proportional protection assignment to an assumed business, the Outward Cedent's Contract should be added, independent of existing protection already exist.

Workaround:

Root Cause:

Extent of Impact:

Impact on Existing Data

Recovery Method for Existing Data Affected

Problem:
When a remittance is created or updated, no entry is written to the system event log.

Solution:
Add remittances to the list of objects to be included in the event log record.

Declination Reason:

Workaround:

Root Cause:

Extent of Impact:

Impact on Existing Data

Recovery Method for Existing Data Affected

Problem:
The As Of Date for a Reinstatement Premium booking is set to the As Of Date of the Linked Claim Booking or the Message Creation Date as a fallback. The As Of Date of the ClaimMovement may not be what was actually set on the ClaimMovement booking (especially when the ModifyClaimFGUAsOfDate rule is used to set the Advisory As Of Date to the CM Creation Date).

Solution:
Where the Reinstatement message is linked to a Claim Balance (via message links or manually selected) then set the As Of Date of the Reinstatement Booking to that of the linked claim balance. This is how the Due Date is set already.

Workaround:

Root Cause:

Extent of Impact:

Impact on Existing Data

Recovery Method for Existing Data Affected

Problem:
This is related to system parameter 'Base Company Specific Settings - System Parameter Types - Classification Rules 2 - Section- and Accounting Classification: Mandatory- and In Use rules - Coverage Classification Type - Residence Area - AC'.

It looks like Config manager will abend when we place mouse cursor on the cell showing value of above parameter. (Config manager is trying to show tool tip, but it finds duplicate information and hence unable to show tooltip and abends)

Solution:
@SysParmKeyDocumentation should be corrected per standard so that the field behaves as expected and shows the tooltip as other cases

Workaround:

Root Cause:

Extent of Impact:

Impact on Existing Data

Recovery Method for Existing Data Affected

Aim of function

The new Mass Pairing order for Technical/Claim balances will allow to perform balance pairing for all reversed source and target balance to make them automatically paired and settled. The system will find all matching technical/claim Unsettled balance pairs with same Base Company, Currency and Amount (but with opposite sign). Pairing can be made between balances of different businesses and business partners and also across technical and claim balances. Only Unsettled balance on Closed worksheets are candidates. Also, this functionality will extract driving balance based on the system parameter and booking year & period and including balance as per the closed date defined in the order.

Mass Pairing of Technical/Claim Balance Order-

Business value for customers

When reversal of technical or claim balances have been done by users without access right to perform balance pairing, the system will leave the two balances Unsettled.  Then the user with access right to perform balance pairing will be able to run this new mass pairing order so that all reversed source and target balances becomes automatically paired and settled.

System Parameters Affected

Driving Balance String for Mass Pairing of Technical Balance

Existing functionality affected.

Balance Pairing of Source and Reversal Worksheet.

Aim of function

The Aim of this function is to include balances on worksheets with status Authorized in the create Settlement Balance Group window and the “Create Settlement Balance” option must be enabled also when a balance on Technical/Claim worksheet with status “Authorized” is highlighted on the BP Ledger. An SBG can contain worksheets with both the status Closed and Authorized and an added new column named “Worksheet Status” to the lower container (Balance group information) on the SBG properties, the Worksheet Status for the balances on the worksheet is shown in this column so, that the user can recognize whether it was in “Closed” or “Authorized” Status.

We have added a new error message 'This is not allowed since the balance is part of an SBG' that appears when the Authorized balance already in one of the SBG and the condition is validated.

When the following criteria are met, the system will display an error message:

• Update a balance on a technical and claim worksheet in the status Authorized and is part of an SBG, i.e., if the Currency is changed (the option 'Switch currency on all details' is selected on the worksheet, or balance amount is changed, e.g., if a detail amount is changed or a detail is deleted, or the payment partner is changed on the balance (on the balance properties window).
• Update the status of an Authorized that is part of an SBG to any other status than 'Closed', such as “In Progress”, “Rejected”, 'Inactive' on the worksheet closing window.
• Do pairing in manual pairing or mass pairing or group pairing.
• The user selects the option 'Link To Remittance ' or ' Create Remittance ' on the View Settlement Balance Group window.

Business value for customers

Booking of technical items and actual payment process are not always done at the same time. 

Sometimes transfer/receive money even if worksheets are not closed, i.e., Authorized. Instead of grouping the Authorized worksheets in an excel sheet before they are set to Closed and then make the SBG it would make the process more efficient if they can be grouped in the SBG already when they are in status Authorized. 

System Parameters Affected

A new system parameter named 'Allow Balances in Authorized Status in Settlement Balance Group', is found under accounting>>Balance Pairing, below the last parameter on the left side.

Existing functionality affected

Worksheet Closing Window – when after selecting the check box “Change Status”
Create and Edit Settlement Balance Groups

Aim of function

In mass pairing order, we have added a new option/button “View Business Partner(s)”, by selecting this new button, a new window appears, named “View Business Partner(s)” contains the following column, i.e., Identifier, Business Partner Name. Where all the columns are in view mode only. And it helps the user to cross check that all the partners that they have added in business partner field in mass pairing order are correct or not. And here the system also counts the number of business partners in the order by display in lower container as Found = (count) objects. To close this new window the user can click on the X button in the upper right corner.
Note: -
View Business Partner(s) button/option,
Disable: if there are no business partners selected and the text field for Business Partner(s) is empty.
Enable: only when we have some partners selected.

Business value for customers

To make the Mass Pairing more user friendly when the user has given multiple Business Partner IDs and when the BP Names appears in the Business Partner field, it is necessary to be able to see all given partners in a container where both the ID and the Name appears together. This to be sure the correct partners are included in the order.

System Parameters affected

None

Existing functionality affected

Mass Pairing Order

Aim of function

With Acord Standard 2016, claim related tax amounts are presented on the TA Claim Signing message then the referring CM message that creates the claim worksheet which presents the tax trigger amount should also automatically generate the target tax amount on the claim worksheet.

Business value for customers

Achieve automatic message processing for claim movements with tax amounts. After implementing this change there is no discarding of messages and no manual bookings necessary in case of claim related tax amount situation.

System Parameters Affected

Removed the following fields from Government tax rule table.
• 'Message Function excluded'
• 'Exclude All'
• 'Applicable for Technical WS'
• 'Applicable for Claims WS'

Existing functionality affected

The fields 'Applicable for Technical WS' and 'Applicable for Claims WS' are automatically updated to active from backend for all the Government tax rules.

Aim of function

To give users the ability to use the same Target Entry code with different Government Tax Rules by checking the Switch Sign button in the rule so that it's credit balance for one Government Tax Rule while it's debit for the other. As well as this, the Target Entry code output can also be seen in the output field Credit/Debit.

Business value for customers

• Solves problems in case the same Target Entry Code is applied for different Trigger Entry Code groups having different signs.​
• Provide clients with the option of changing the sign of a Target Entry code to make it accepted as positive for one Government Tax Rule and negative for another.

System Parameters Affected

Government Tax Rules

Existing functionality affected

Automatic Booking of Government Tax functionality both in Technical and Claim Worksheet

Aim of function

On the Business Partner properties, it must be possible to store new information about Letter of Credit information on a partner level, including Trust and Funds Held. These information shall be possible to view and edit manually and to report all these fields in Business Object.  

Part 5 of this enhancement is to implement the collateral Terms like Letter of Credit on Business Partner through MTK, so that it is possible to import the Collateral details on Business Partner. This needs to be implemented in P&C, CEDE and LIFE.

Below steps can be followed to achieve collateral through MTK

1) Create a Business Partner with Collateral information in SICS.

2) Now export this Business partner using Migration Toolkit-> Data Export Functions in System administration Utility.

Select 'Execute Selected Functions' after giving the Business Partner details.

3) Now the export file will be saved in the location given in Step 2 with Collateral details.

4) You can create a new file with modified details like Business Partner ID and required details of Collateral.

5) Now import the new file using Migration Tool Kit- Loader.

After giving the file location, select 'Start Migration'.

6) Once the new file is imported and the details have been written to database, then you can find the new Business Partner created in SICS.
Similar steps can be followed in CEDE and LIFE as well.

Business value for customers

The Collateral information that currently can only be given manually, can now also be loaded through MTK after this enhancement.

System Parameters affected

None

Existing functionality
View and Edit Business Partner Properties
MTK

Aim of function

On the Business Partner properties, it must be possible to store new information about Letter of Credit information on a partner level, including Trust and Funds Held. These information shall be possible to view and edit manually and to report all these fields in Business Object.  

Part 6 of this enhancement is to implement the the possibility to import the above Letter of Credit information through web service. As an Accountant/System Administrator, instead of logging into SICS, it should be possible to create/ update a Business Partner with Collateral details through Web Service.

After this enhancement, now we can create a new Business Partner with Collateral details using an existing 'createBusinessPartner' API. We can even update an existing Business Partner with Collateral details along with other details of BP using an existing 'updateBusinessPartner'. We can even update only Collateral information for the existing BP using a new API 'createOrUpdateCollateral'. And also we can add new details for the 3 special fields Increase By, Decrease By and Withdrawals. And able to update the latest record with bank date and amount same as how we can do in online using a new API 'createOrUpdateCollateralDetails'.

Business value for customers

The Collateral information that currently can only be given manually and through MTK, is now possible to create/update a Business Partner with Collateral information through Web Service after this enhancement. There no necessary to login to SICS for updating the Collateral information.

System Parameters affected

None

Existing functionality
View and Edit Business Partner Properties
Web Service

Aim of function

When an assumed business is linked to a program, the system now checks the security domain restrictions of the assumed business and not the program. This happens also when the assumed business is opened from a program and when the update of the assumed business is executed from a program.

Business value for customers

Keeps the system consistent. Security restrictions affects only items that are set up to be affected.

System Parameters Affected

None

Existing functionality affected

Update Business Terms and Conditions
Create Business
View Business
Manage Security
Maintain Cedent's Program Contract Overview

Aim of function
Enable Claim Program functionality for Facultative Business which will facilitate claim administration also for these types of business.

Business value for customers

Facilitate Claims administration for facultative business and improve possibilities for automation.

System Parameters affected
Claim Program in use
Allow multiple base companies in Claim Program may be activated

Existing Functionality
Create and Update Claim on Facultative Business
Create and Update Claim Program

Aim of function

The system should allow negative loss figures to be considered in the inuring record and calculate inuring accordingly

Business value for customers

The inuring calculation considers the actual FGU figures, and therefore results in correct distribution

System Parameters Affected

Inuring Recovery in FGU must be activated

Negative Figures must be allowed

Existing functionality affected

Create FGU

Create and Calculate inuring record

Aim of function
Automate the processing of duplicate messages by enhancing the “DuplicateMessageMappingRule“, so that an identified duplicate message can process with a new status 'Automatically Discarded' without the need of user intervention.

Business value for customers
Increased process automation, avoiding manual effort from user when system detects duplicate message.

System Parameters Affected
None

Existing functionality affected
Process eMessaging messages

Aim of function

Implementing a new Discard variant for discarding a technical account (TA) message or a claim message (CM) within SICS, where the user can discard a message but at the same time send acknowledgement message back to the broker.

Business value for customers

Enables the client to discard technical account (TA) messages and claim messages (CM) within SICS , but still send a standard L4 Acknowledgement message back to the broker, communicating that the message has not been rejected.

System Parameters Affected

N/A

Existing functionality affected

Process eMessaging messages

Aim of function

Now also supporting Settlements BulkApprove/BulkReject API calls via the already supported integration with ADEPT (ACORD Data Exchange Platform & Translator).
The new integration plugin builds upon the sophisticated SICS eMessaging foundation to provide a next-generation market capability to increase the timeliness, accuracy, and security of business data exchange.

Business value for customers

Enabling rapid data exchange, translation, and transformation via ADEPT, the ACORD Data Exchange Platform & Translator.

System Parameters Affected

Configuration of a new eMessaging ADEPT gateway plugin.

Existing functionality affected

eMessaging
 

Aim of function

To consider the paid loss, expense loss, reserve loss, and expenses in the FGU Claim Amounts Validation Rule when expenses are part of Liability/None. FGU is activated on the claim that is attached to the message and splits the loss amount between the groups either paid loss + paid expense or reserve loss + reserve expense. While processing the eMessage, the FGUClaimAmountsValidationRule must consider the sum of the split amounts rather than individual amounts. There are no changes done to the FGU functionality, we are adding the FGU split amount as one group to avoid the error on the eMessage.

Business value for customers

Improving FGU validation by letting the FGU validation rule consider the sum of the amounts, rather than the individual amounts in the eMessage, when expenses are part of the Liability/None. Avoiding error on FGU associated eMessages.

System Parameters Affected

N/A

Existing functionality affected

Process eMessaging messages

Aim of function

• Reject CM & TA message; user selects the 'Save with Rejection Acknowledgement' option from the discard/reject/restore window the status of the message will be set to Rejected.
• Discard CM & TA message; user selects the 'Save with Acceptance Acknowledgement' option, then the status of the message will be set to Discarded.
• Once the acknowledgement is generated, the acknowledgement ID and the new status of the message will be shown in the Status History tab.

The above functionality comes as an additional update to Reject option for CM & TA Messages with an Error Indicator .

Business value for customers

• User will be able to clearly distinguish between Discarded messages and Rejected messages.
• In the TA & CM Status History tab, the user can view the Acknowledgment message ID and the new message status.

System Parameters Affected

None

Existing functionality affected

Process eMessaging messages

Aim of function

The aim of this epic is 

• Improved Business Partner Ledge window.
• Improved the UX of System Parameter screen for Accounting >> Currency >> General.

Business value for customers

Improved UX on SICS4 Screens

System Parameters Affected

N/A

Existing functionality affected

N/A