Release documentation - P&C Enhancements and requests

Problem:
Intra-Group transfer error

Solution:
When an intra group contract has been renewed so that both the IGC ORP and the linked IGC IAB have corresponding insured periods, then we must make sure that bookings created on the IGC ORP are transferred to the correct insured period on the IGC IAB.
The above must be the case when running the Retrocession Estimation Calculation order so that estimates on the As Booking ledger are copied over to the IGC IAB and when running the Retrocession Account order so that these bookings on the As Account ledger are copied over to the IGC IAB

Problem:
Some of the details created on As Booking ledger of the ORPs by the Retrocession Calculation order have mismatch between original detail amount and FC amount even with same currency. There is a rounding problem, i.e. the rounding of the calculated Overriding Commission does not follow the same logic as its FC amounts.

Solution:
When running the Retrocession Calculation Order and deduction details are calculated on the ORPs, both Actual and Estimate details, and the system shall set the Functional Currency Amounts on these details, then the system shall follow the existing logic but with one exception;
If the FC Currency on the detail is the same as the Currency on the original amount, then the system shall set the FC Amount equal the original detail amount.

Recovery Method for Existing Data Affected
Possible to correct the Functional Currency Amount on details created on ORPs by running the Retrocession Calculation order, when these amounts are different from the original amount on the detail and the currency is the same. This can be updated by a script to set the FC Amount equal the original detail amount where the amount are not equal.

Problem:
Bug 1552811: TA - Deposits - SICS 23.1 SP4 TECSNT02: Premium scenario 2 - validation AC0395 expects 0 deposit retained booked (ISSUE 111)

Solution:
When the basis for the Premium Deposit Retained is zero and you book a retained detail amount of zero, then the system accept this without any validation error. But if you don't book a retained detail amount at all, then the system shall not raise the validation error message AC0395, but instead handle this situation as if the retained amount is zero. The logic must be changed so that if a retained detail is missing and the system currently raise AC0395 for this, then an additional check must be done before it is raised; a) if the computed amount for the missing detail is zero then the message AC0395 shall not be raised, but b) if the computed amount for the missing detail is NOT zero, then the message AC0395 shall still be raised.
Same logic must also be implemented for Loss Deposit.

Workaround:
When the basis for the Premium Deposit Retained is zero you can book a retained detail amount of zero, then the system accept this without any validation error. If the validation message appears because the Premium Deposit Retained is NOT booked, then just add the detail with zero amount.

Problem:
Reverse / Copy / Reverse&Replace -> Worksheet is not available for imported worksheet. Only Balance option is active. The Worksheet option is disable intentionally when it contains of more than 1000 details.

Solution:

When a worksheet contains of more than 1000 details the options to Copy, Reverse, Reverse and Replace Worksheet are all disabled.

This is an intended limitation, but we need to look at if this is still relevant and see if we can remove this limitation or increase the number of details on the worksheet before the option is disabled. 

Problem:
Booking Definition saved incorrectly in Booking Terms maintenance window

Solution:
In the process when the user select the option 'Assign a Booking Term Definition' in the Booking Terms Maintenance window, has selected a Definition, but at the end press Cancel to interrupt the process, then the system must roll back the changes so that the booking term definition for the Base Company before the changes remains. The new Definition shall only be committed to the database if the user press OK in the above process.

Problem:

User is unable to save New Premium Adjustment Order  

Solution:

When creating an Adjustment Premium order from the Adjustment tab on the Premium and Limit conditions on a prop treaty OCC AND the Base Company on the OCC is also Selected in my User Preferences under My Default Base Companies for Retrieve Information, then the system must be able to save this Adjustment Premium order to the database without falling over with a walkback.
The system works fine if there are no default base company selected under Retrieve Information in the user preferences.

Workaround:

Do not select the Base Company on the OCC in the User Preferences under Retrieve Information

Problem:

Error on Entering instalment condition

Solution:

When Premium Paymet Warranty is defined on the CL (Clauses) Conditions, the same number of days is automatically updated on the Payment of first and subsequent Instalment on Instalment Conditions.

When calculating instalments on the Premium and Limit Conditions, Instalment tab, the system is using these days when the payment days are set on the instalments. But if the Premium Payment Warranty is defined as blank, it also becomes blank on the Payment days on the Instalment conditions and this not a valid number of days when instalments are calculated. The system must handle this information as 0 and add 0 days to the payment days.

Workaround:

When defining the CL conditions make sure the Premium Payment Warranty is defined with correct number of days/months, and if it shall be zero, make sure you enter 0 as an amount and not just keep it blank.

Problem:
Adjustment booking wrong based on AC Split%

Solution:

When booking Adjustment Premium on a non-prop treaty OCC with AC Split % is defined on the Premium & Limit Conditions, the system shall book split amount on each of the Accounting Classifications only once, so that the total of the Adjustment Premiums booked on all ACs sums up the the Adjustment amount on the conditions.

Problem:

Mandatory RU in the accounting classifications should not be removed when an open worksheet involves the AC

Solution:

Preconditions:
One Reporting Unit Category is mandatory in AC
SCoB is mandatory in AC
AC is created with these values and it is used in bookings (open or closed worksheet)

1) When the system parameter 'Restrict Invalid Accounting Classification when bookings exist' is ON, and booking exists on an Open (pending) worksheet and the user is removing the mandatory SCoB value from the Classification tab on the business, the system correctly stops the user with message BS00276 because it is used in AC on an Open worksheet. This message shall also be presented when the user removes the mandatory RU on the Classification tab, and not BS0687 telling the user that reversal of bookings should be considered.

2) When the system parameter 'Restrict Invalid Accounting Classification when bookings exist' is ON, and booking exists on a Closed worksheet and the user is removing the mandatory SCoB value or RU value from the Classification tab on the business, the system correctly stops the user with message BS0687 because it is used in AC on a Closed worksheet telling the user that reversal of bookings should be considered.

3) When the system parameter 'Restrict Invalid Accounting Classification when bookings exist' is OFF, and booking exists on an Open (pending) worksheet and the user is removing the mandatory SCoB value from the Classification tab on the business, the system correctly raises message BS00276 because it is used in AC on an Open worksheet. This message shall also be presented when the user removes the mandatory RU on the Classification tab, and not just allow this without any warning.

4) When the system parameter 'Restrict Invalid Accounting Classification when bookings exist' is OFF, and booking exists on a Closed worksheet and the user is removing the mandatory SCoB value from the Classification tab on the business, the system correctly raises confirm message BS00279 telling the user that existing AC will be made invalid. This message shall also be presented when the user removes the mandatory RU on the Classification tab, and not just allow this without any warning.

Problem:
System abends when creating FGU Advisory for a Stop Loss OCC. This appears to be because the system is using the calculated limits for assumed business which is found at Claim/Business Info/Limit tab. This tab is not available for Outward Cedent's Contract.

Solution:
Make sure that the FGU Advisory for a an OCC Stop Loss / Aggregate XL Loss is using Claim List Limits when calculating amounts, and not using limits per claim - as the assumed process is doing.

Workaround:
Create Stop Loss recoveries using the automatic process for Outward Cedent's Contract
OR
Create OCC Claim and book recovery amounts directly at Claim ledger

Problem:

System Tolerance Limit is not respected when creating Minor Adjustment as Write Off during Balance Pairing

Solution:

Precondition for this issue to occure is that the Entry Code defined for the Write Off under Accounting, Currency, General must be the same as the Entry Code defined as Minor Adjustment under Accounting, Tolerance Limits.

When balance pairing takes place between two balances of same currency but not fully matching amounts the system creates Write Off amount in the pairing object. The Write Off may be booked as a Minor Adjustment on a technical worksheet (TW) if the system parameter named Entry Code For Write Off is defined under Accounting, Currency, General. If such a TW is created and the Minor Adjustment amount is exceeding the tolerance limit defined for Minor Adjustments in the system parameters under Accounting, Tolerance Limits, then the system must present an error message and prevent the technical worksheet and the pairing to take place. The error message AC0348 should appear in the same way as if the user manually create a TW with a Minor Adjustment that exceed this limit.

Workaround:

It is possible to define an upper limit for Write Off in balance pairing in the Domain Restriction named 'Accounting Balance Pairing Exchange Amount Limit' with the same amount as defined for the upper limit for the Minor Adjustment in the Tolerance Limit. This will stop the user for creating a balance pairing with a Write Off that exceeds this limit and therefore will also prevent the user from creating a technical worksheet with a minor adjustment that exceed this limit.

Problem:

Retro Calc Order not properly working for estimates and IGC involved

Solution:

When running the Retrocession Calculation order with the Include Estimates and Close Worksheet selected on the order and it includes estimates details from the As Original ledger, then the system shall Close the worksheets both on the OCC and on the ORPs. If any of the ORPs has an intra group company link to an Assumed Business, then also worksheets with the estimate details shall be created on this business.

Problem:

Domain Retrieval for Accounting Classification error - shown as valid even if Type of Participation (Method) in the AC is not found on the Business Classification.

Solution:

When the Domain Retrieval for Accounting Classification is executed by use of the object_id or name for a certain section the system correctly shows all available Accounting Classifications for this section and it shows the Accounting Classification as valid/invalid in the element  
<isValid xsi:type='xsd:boolean'>false</isValid>
as true or false, but we must make sure the system also takes the Type of Participation (Method) into consideration together with all the coverage classifications used today to set false or true in the above element.

Problem:

System is not considering message settlement due date when creating Paid Remittance even if the new Modifier Rule is active 

Solution:

When a remittance is created from a Settlement Message in eMessaging and the Modifier Rule is Active, and the Due Date and Value Date are set from the message and opened by the user, then the Due Date and Value Date shall not be reset by other logic even if 'Prepopulate due date/value date for Remittance Creation' parameter is enabled.

Root Cause:

SE-22506 and SE-22594, both implemented in 23.4

Problem:

Mark As special Flag is missing in ORP As Account (Group Order).

Solution:

When running the Retrocession Account Order with the Special radio button selected under Items Included, then the system shall look at details on the As Booking ledger of the ORPs, but only extract details on worksheets marked with the Special flag. If the Special radio button is not selected on the order, e.g. it runs with the Normal selected, then details on all worksheets will be extracted as before, both those marked as Special and normal worksheets.

Workaround:

When Retrocession Account Orders are created from the Retrocession Account Order Group they will be created without the Special flag selected. If the user wants these orders to extract details only on worksheets marked as Special, then the Special radio button on the order must be selected manually by the user.

Problem:

Possible to create Worksheet on Inactive Entry Code (EC) via API

Solution:

When executing the web services/APIs createWorksheet and createClaimWorksheet, the system must check all involved entry codes if the Active box is selected on the entry code properties or not. If it is NOT Active, then an error message must be presented saying that the given Entry Code is not Active.

Workaround:

Avoid using inactive entry codes in API by informing the users about which entry codes to be used and which entry codes that shall not be used.

Problem:

Rename the labels of Threshold Limits on Accuracy Validation Rules

Solution:

On the Accuracy Validation Rule, the Threshold Limits labels' must be renamed to have more appropriate names for better understanding. 

The three labels shall be placed under a single frame with the name 'Threshold Limits'. Within this frame and the 3 threshold limits shall be renamed with below labels.

AC0399 - Target Amount without a corresponding Business Condition

AC0395 - Trigger Amount without a Target Amount

AC0392 - Target Amount without a Trigger Amount

Since the Label for these fields are longer now, the amount fields must be resized to fit the frame and window accordingly.

This mustbe done both for the Accounting and Claims Accuracy Validation Threshold Limits labels'. The claim only have the Treshold Limit AC0399 and AC0395.

Root Cause:

Implemented in 24.1 according to SE-22245https://jira.dxc.com/browse/SE-22245

Problem:

Abend when choosing to remove business from accounting order for the second time - 'missing element on remove'

Problem:

Abend when choosing to remove business from accounting order for the second time

Solution:

The system should 'refresh' list after first removal, and remove the second when option is chosen for the second time

Workaround:

Refresh/save - and repeat

Problem:

Validation Error Message repeats when the target amount is less than or equal to the AC0392 Threshold limit.

Solution:

On the business when a business condition is added, it can be either a Deduction condition or Deposit condition, and on the technical worksheet where only the target amount is added, and the base detail is missing. Then whether the target amount is greater than the threshold limit or the target amount is less or equal to the threshold limit, the Accuracy Validation Log Message should be recorded similarly and there should be only one record added for one error AC0392.

The Business with Estimation Complete flag ON in Pricing and adjusted estimates is being listed under the eligible business list container of Underwriter's Estimation Calculation Order.

The Order should not include the business which has the Estimation Completion flag as YES 

Problem:

Error response in SICS Server during CreateWorksheetRequest - UDF instruction

Solution:

When running the web service createWorksheet, including the elements
<userDefinedFieldsCondition xmlns:cdt='http://www.SicsNt.com/CommonDomainTypes' xsi:type='cdt:UserDefinedFields'>
..
...
</userDefinedFieldsCondition>

then the system must be able to create the worksheet with the related details including the given user defined field values.

Problem:

Upload of Remittance spreadsheet | 'Level of Business - OCC' field does not work

Solution:

Preconditions:
System parameter 'Indicator for Level Of Business On Remittance Worksheet Required' must be selected.

When the above system parameter is selected and the xl spreadsheet contains the value Outward in the column Direction and a valid OCC business Id in the column Level of Business - OCC, then the system shall allow this information and create the actual remittance with these values present.

If the above system parameter is not selected, then it shall not be allowed to give neither of the above information in the xl spreadsheet, i.e. it shall raise an error message in the Error List in the Import window.

Problem:

Duplicates of Default Settings on Booking Terms Maintenance

Solution:

Even if new Booking Terms have been created, assigned to a Base Company, later deleted and finally created and assigned to the Base Company again, without any refresh of the system until now, the system shall NOT create any duplicate of the <Default Settings> terms. The system shall not allow to have duplicate names of booking terms including the name <Default Settings>.

Recovery Method for Existing Data Affected

We need to delete the duplicate <Default Settings> now created in the latest DB as we are not able to edit the Default settings because of validation 'Booking Term definition already exist'.

Problem:

Incorrect system behavior when booking RIP on TM with no active RIP condition active/available

Solution:

Preconditions:
An Accuracy Validation Rule is defined for Reinstatement Premium, and this rule has a Threshold Limit for AC0399 (Target Amount without a corresponding Business Conditions). The Business do not have a Reinstatement Condition defined.

When booking Reinstatement Premium detail on a business with Reinstatement Conditions available but not defined and the detail amount is BELOW the Threshold Limit for AC0399 on the accuracy validation rule, then the system shall NOT raise the error message AC0399, but instead just log the information that booking of Reinstatement Premium expect corresponding conditions. Only if the detail amount is HIGHER than the Threshold Limit for AC0399 that the system should raise this error message and should be able to add Category and Comments so that the worksheet can be closed.

Problem:

AC0770 - Loss Deposit Release strange behavior (ISSUE 157)

Solution:

When the relevant business condition is defined on a business, and on the worksheet both Trigger and Target ECs are present, then system should consider lower and higher Threshold limit values on the rule and trigger the AC0770 error accordingly.

If the deviation(+/-) of the target amount booked is less than the Lower Limit on the rule, then system should just allow the user to close the worksheet. 

If the deviation(+/-) is in between the lower and Higher Threshold limit defined on the rule, then system should allow the user to close the worksheet but there should be an Auto-log of the deviation amount error on the Accuracy Validation Log Message.

If the deviation(+/-) of the target amount if more than the Higher Threshold limit defined on the rule, then system should trigger and Hard-Stop error but should allow user to override the error using the Category and Comments fields on the worksheet.

Problem:

AC0395 not triggered with EC3000 Premium/Claim deposit without releasing the premium deposit retained earlier.

Solution:

On the business when Deposit Condition is added for both Premium and Loss and the worksheet is booked with only a claim booking without releasing the premium deposit retained from last 4th quarter in previous accounting year, then the system raise AC0395 telling that the Premium Deposit Release (from previous accounting year) is missing and also for the missing Loss Deposit Retained (for the current worksheet Claim booking). User should be allowed to override these error with Accuracy Validation Category and Comments.

Problem:

SICS abend when running retrocession calculation order when calculate Deposit.

Solution:
System should not abend when running Retrocession Calculation Order when OCC has the Accounting Basis as Clean Cut and Deposit Condition is set as Release in Next Accounting Year with Transfer to Next Insured Period.

Problem:

No hard stop if booked amount smaller than original amount but deviation higher than threshold

Solution:

When the relevant business condition is defined on a business, and on the worksheet both Trigger and Target ECs are present, then system should consider lower and higher Threshold limit values on the rule and trigger the AC0770 error accordingly.

If the deviation(+/-) of the target amount booked is less than the Lower Limit on the rule, then system should just allow the user to close the worksheet. 

If the deviation(+/-) is in between the lower and Higher Threshold limit defined on the rule, then system should allow the user to close the worksheet but there should be an Auto-log of the deviation amount error on the Accuracy Validation Log Message.

If the deviation(+/-) of the target amount if more than the Higher Threshold limit defined on the rule, then system should trigger and Hard-Stop error but should allow user to override the error using the Category and Comments fields on the worksheet.

Problem:

Incorrect system behavior when booking RIP on TM with no RIP condition(R tab) active/available on the Business

Solution:

Preconditions:
An Accuracy Validation Rule is defined for Reinstatement Premium, and this rule has a Threshold Limit for AC0399 (Target Amount without a corresponding Business Conditions). The Business do not have a Reinstatement Condition(Non prop Business with Type of Participation Stop Loss/Aggregate Loss)

When booking Reinstatement Premium detail on this type of business without Reinstatement Conditions available and the detail amount is BELOW the Threshold Limit for AC0399 on the accuracy validation rule, then the system shall NOT raise the error message AC0399, but instead just log the information that booking of Reinstatement Premium expect corresponding conditions. Only if the detail amount is HIGHER than the Threshold Limit for AC0399 that the system should raise this error message but should be able to add Category and Comments so that the worksheet can be closed.

Problem:

Deposit Regulation Years produces system crash and incorrect AC0770 (ISSUE 193)

Solution:

Precondition:
The Loss Deposit Reserves Business Condition is set to the Deposit Regulation as 'Years' and the Account Frequency as 'Quarters' and Release in 'Same Account in Next Accounting Year'.

When the user books the Original Loss Reserves and Claims on Q2 directly skipping the Q1, and on the next  Quarters system should allow to book the Loss Reserves without any abend.

Problem 1:

AC0395 not triggering properly when target EC is missing. 

Solution 1:

When the Business condition is added and on a worksheet, if we have the Base amount added and no target detail added, then system should look for 'AC0395 - Trigger amount without a Target Amount' Threshold Limit of the Accuracy Validation Rule. If the Base amount is less than or equal to the defined Threshold Limit, then system should Auto-log the error and allow user to close the worksheet. And if the Base amount is greater than the defined Threshold Limit, then system should raise a Hard-stop error and also allow user to override the error using the Category and Comments fields on the worksheet.

Problem 2:

AC0770 not triggering Hard-Stop error when the target amount is less than the Threshold Limit. 

Solution 2:

When the relevant business condition is defined on a business, and on the worksheet both Trigger and Target ECs are present, then system should consider lower and higher Threshold limit values on the rule and trigger the AC0770 error accordingly.

If the deviation(+/-) of the target amount booked is less than the Lower Limit on the rule, then system should just allow the user to close the worksheet. 

If the deviation(+/-) is in between the lower and Higher Threshold limit defined on the rule, then system should allow the user to close the worksheet but there should be an Auto-log of the deviation amount error on the Accuracy Validation Log Message.

If the deviation(+/-) of the target amount if more than the Higher Threshold limit defined on the rule, then system should trigger and Hard-Stop error but should allow user to override the error using the Category and Comments fields on the worksheet.

Problem:

When placing an outward cedent's contract to a retrocessionaire, after the user has added one premium instalment to the contract, the system does not copy this instalment to the retrocessionaires.

Solution:

When creating a retrocessionaire after the user has added One Instalment to the OCC, the system should copy this premium instalment to the retrocessionaire. It should copy this instalment also when there were other instalments present on the OCC before adding the one by the choice One Instalment.

Problem:

The system abends when placing a non proportional facultative Intermediary, created from a sub section, to a retrocessionaire if the Assumed Business does not have a Type of Business Covered being the same as its own Type of Business Method. 

Solution:

When placing a Non-Proportional Facultative Intermediary Protection to a Retrocessionaire Participation, the system should NOT abend when the Assumed Business Type of Business Covered is missing or is different from the Type of Business Covered by of the Intermediary. Instead, the Retrocessionaire should either get the same Type of Business Covered as the parent intermediary (or it should derive it from the assumed business it’s covering by using its ToB METHOD as ToB Covered.)

Workaround:

-Open the Assumed Business.
-On Main section, select Classification Tab.
-In the Coverage container, from the pop up menu, select Edit Classifications.
-From the pop up menu, select Type of Business.
-Select Proportional Facultative.
-Select Save.
-Select Yes to the Automatic Transfer... question.
-Select OK.
-Do a Full Refresh.
-Open the the Assumed Business again, and navigate to the Assumed Sub Section having the Intermediary Fac Protection.
-Select the Intermediary Fac Protection and from the pop up menu, select Place to Retrocessionaire.  
(When having placed to the Retrocessionaire, you can now go back to the assumed business and remove the Type of Business Covered again, if not wanted.)

Problem:
It is possible with missing mandatory classification on business sub sections when removing classifications from the parent section.

Solution:
When removing a classification (e.g. Class of Business) from an agreement and adding another one, the system should check that all sub sections still will have all mandatory classifications.

Problem:
The system abends when having changed the column view in the business partner table within the Business Highlights and then selecting Save Settings.

Solution:
The system should not abend when having changed columns in the Business Partners container, (e.g. changed the column width) and then selecting Save Settings. Instead, the system should save my changes, so that the next time I open this, it shows my saved layout.

Problem:
When renewing a stop loss treaty with a different insured period than the reinsurance program it belongs to, the system abends.

Solution:
When renewing an Assumed Business of the type Stop Loss, being part of a Reinsurance Program, the system should not abend even if its Insured Period is not exactly the same as the Insured Period of the Reinsurance Program. Instead, it should renew the business in the same way as it currently correctly does when the type is, for example Excess of Loss. The new period of the assumed business should then behave normal, e.g. show up in the next year's mass renewal of the program.

Problem:
The system abends when removing one out of several selected business partners without identifier from searching criteria in Find Business and clicking on 'find now' button.

Solution:
SQL Database:
Find Business: 
In Find Business Window, after removing one out of several selected business partners from the search criteria and clicking on 'find now' button system should NOT abend, (like it correctly does when using Oracle database)

Problem:
Classifications are lost when creating a new contract and, in the wizard after the classification page, paging back again to this page and then forward before save.

Solution:
Classifications should not be lost when creating a new contract and, after the classification page, paging back to previous and then forward and save. After full refresh, all classifications given in the wizard should be shown on the business.

Problem:

When using find claims search option Business Identifier without defining a Business ID, and retrieving a claim which is linked to many sections/businesses, and user preference 'transfer automatically if unique match' is selected, the system automatically opens the first listed soc-to-claim.

In emessaging, when the Business Insured Period and section has already been referenced, and then searching for the claim, the user is requested to choose from the list of scopes of cover if search option is Claims to which the claim is linked.

Solution

• The system should not open the unique match unless the result list returns a single object.
• When editing Claim on Message Highlights for a TechAccount or ClaimMovment and a Business Identifier is being provided automatically for the search then also default the Query Specification to Business Identifier (otherwise User Default is applied).

Workaround:
If Business Identifier is provided for Claim Find Options, Query Specification, manually select Business Identifier on Claim Find.

Problem:

Abend when opening FGU when ACR is in use and claim limits are defined and Cover amount is unlimited

Solution:

When claim is a multi currency claim and cover is defined as unlimited on the claim limits, the cover amount in all currencies should be unlimited for paid cover, incurred cover, cibnr cover and acr cover. 

The system must not return null in the calculation.

Problem:

The calculate button on the HL Claim list disappears when tabbing out of the currency field

Solution:

The calculate button should be displayed and enabled

Problem:

Accounting Period From To cannot be entered on Claim Worksheet due to an error message. This worked correctly in 20.4, but not in 22.4.

Looks like a duplicate of  SICSR-28609

Solution:

• 1) Run attached script SICSR-28774.txt to set booked date where this is null.
• 2) Allow entry of Accounting Year, Period and Dates on the Claim Worksheet regardless of whether accounts have been defined or not.

Workaround:

Activate Accounting information based on as of date parameter (Claim Accounting). When set the accounting year, accounting period is set based on as of date in booking detail, but you can still override in worksheet.

Problem:

Action Date is not set or updated correctly with various combinations of as of date parameters.

Solution:

The system should update/clear action date based upon the combination of all parameters and worksheets. 

Problem:
AC0399: When no Reinstatement condition is defined, AC0399 not triggered when booking with only RIP (no Paid Loss booking).

AC0770: When Reinstatement condition is defined, AC0770 not triggered when booking with only RIP (no Paid Loss booking).

Solution:
AC0399
If there is no RIP condition defined on the business IP and the claim worksheet books only the target entry, RIP, the system should trigger AC0399 validation requesting a related business condition. Base entry, paid loss, is not needed.

AC0770:
When Reinstatement condition defined on the business IP and the claim worksheet books only the target entry, RIP (without paid loss), the system should trigger AC0770 validation requesting a related business condition. ** 

Problem:

The system abends when removing all country groups in the Claim Program's Business Find window

Solution:

The system should allow removal of all country groups in one go

Problem:

When adding Business to a Claim Program which is defined with location being country/countries or a mix of country group/groups and country/countries, the system populates the Country Groups with all groups containing the Claim programs countries.

Solution:

The Find Business should only populate Country Groups and Countries exactly as they have been defined on the Claim Program

Workaround:

Remove the country groups not matching

Root Cause:

SE-21793

Problem:

Abend when opening claim list when Domain Restriction Business Structure preventing business updates

Solution:

The Business Structure domain restriction should not impact the viewing of Claims

Problem:

The FGU Upload fails to populate settlement date correctly / this is always set to same as As of Date.

It also fails to populate worksheet tile, booking month, and due date for all rows not deemed as 'first'. For these rows the value is set to default, or blank.

Solution:

The FGU record and worksheet should be generated with the values provided in the input file for each claim

Problem:

When adding businesses to a claim program, and there is either a gap or an overlap, the system should return warning or error. If businesses are added in the create claim program wizard, the warnings appear twice. If businesses are added to an existing Claim Program, the warning/error does not appear at all.

Solution:

The warning/error should only appear once.

The warning/error should appear both in create and update.

Problem:

The element 'includeZeroBookings' in createFGUClaimWorksheet APIs does not work as intended.

Solution:

When the above element is set to true, the API should create worksheet with both adjustments and zero adjustments.

Problem:
Create Zero WS option is not enabled FGU Distribution triggers Creation of Both Zero WS and Claim WS as well as Create Zero WS. User has to create the Claim WS so as to get the option to Enable the option to create Zero WS.
At times when the Claim is linked to several layers, Create Zero WS option is enabled after changing the SOC for the claim or Light/Full Refresh Solution.

Solution:
Create Zero WS option should be enabled simultaneously along with Create WS, when the FGU Distribution triggers Creation of Both Create Zero WS and Create Claim WS. System should not need any refresh for the options to be available.

Problem:

User can inadvertently inactivate a claim worksheet without warning.

Solution:

The existing warning CM0607 should appear on the worksheet edit page, and not only on closing page.

Problem:
Certain Claims Program with no Claims linked, location cannot be edited 
Solution:
If no claims are linked to the Claim Program, the edit option should be available

Problem:

Abend when retrieving claims on a Headline Loss

Solution:

The system should retrieve the claims without any abend

Problem:
When find EDI Batch returns a single result and User Preferences
Open Properties Automatically if Unique Match (Find Windows)
is checked then the system abends

Solution:
When find EDI Batch returns a single result and User Preferences
Open Properties Automatically if Unique Match (Find Windows)
is checked the EDI Batch should automatically open if the Batch status is Unprocessed, otherwise just show the single result row.

Workaround:
Uncheck - User Preferences - Open Properties Automatically if Unique Match (Find Windows)

Root Cause:
SICS 22.3 - SE-13084 - Switch Find windows to Paged Collections

Extent of Impact:
EDI Find Batch with User Preferences - Open Properties Automatically if Unique Match (Find Windows) - checked and there is a single match on find operation.

Problem:
FA is creating fully automatically the SBG. However, it fails/errors on the Remittance creation. When swapping to worksheet creating the remittance manually and than setting it to Final the FA remains in status error rather than changing to processed as it does on every CM/TA which have a linked Worksheet which is closed:

Solution:
Closing an eMessaging Remittance outside the eMessaging module (i.e. not via Swap-to) should behave the same as if Process or Swap-To is used as is the case for a Technical or Claim worksheet.

Workaround:
Separately Process the Settlement message to have it go to Processed state

Root Cause:
Incorrect restriction on functionality limited to London Market messages only

Extent of Impact:
eMessaging B2B Remittance set to Final via find RW etc.

Problem:

Description: A reversal message should not trigger additional accounting validations besides ensuring that the reversal amounts are matching the originally booked amounts. Otherwise, when asking the sender for a correction because something was missing (in our example FET) raises unnecessary errors.

The original message did not raise the error as the Respective FET condition was not set-up, the reversal message than raises the error but serves no purpose as its a reversal:

Solution:
When checking if a reversal booking should be made (or else booking message values) ensure to only check bookings for matching instalment / adjustment on the worksheet.

Workaround:

Root Cause:
There is a test if an Instalment / Adjustment worksheet is already reversed (any balances linked to reversal pairing) but this is incorrect if the worksheet books multiple instalments etc. It should have restricted tests to the specific instalment only etc.

Extent of Impact:
Reversal of instalments that are booked on a worksheet containing multiple instalment bookings.

Problem:
We encountered that the LPC FA message for BP in Trouble is not trigger anymore.

The rule is active on LPC FA messages as well but not triggering. The question is now, If it's not triggered because of a bug or because of some LPC specific 'settings'.

LPC Payment process is a little bit different we still would need to inform Portfolio Management in case of received FA's for Financially Troubled clients. Therefore, we would like to understand the different behavior for B2B and LPC.

B2B FA - TRIGGERS ALERT ERROR - CORRECT BEHAVIOR

B2B FA Due to Sender : f67d3a75-f8cd-43c8-b3e2-e6fa44b57b04 - goes to error 'Responsible Partner is in alert status, balance is due to sender' (Rule CheckResponsiblePartnerAlertStatusBalanceDueToSender)

LPC FA - DOES NOT TRIGGER ALERT ERROR - INCORRECT BEHAVIOR

Solution:
When the FAIBalanceStatusRule is active then upon validation still perform the balance referencing if no balance is linked.
It is still not a requirement to link to a balance and so if no link is made then no problem will be raised and the FAI will still be automatically accepted.

Root Cause:
FAIBalanceStatusRule states When this rule is in force, it is
not a requirement that Financial Account items are referenced to a technical balances before they are accepted, and when processing the message, no Settlement balance group is created.

However it does not state that no balance should be referenced if possible,

Extent of Impact:
FAIBalanceStatusRule when no balance is referenced

Problem:
ClaimReference provided is greater than the 30 character limit on the database and abends when trying to persist.

Solution:
As per business references the field should be trimmed to the maximum field size specified by ACORD (see below) at 35 chars and stored. Any query using the value should also have the value trimmed as required.
Message to message comparisons are on the full field but any extraction from a message to be compared with a value otherwise stored on the database must be max 35 chars.

From version 2006.1 of the ACORD standard, most object (Contract, Claim etc.) references have been updated to allow up to 255 characters to be supplied when using XML messaging. The EDI standard remains unchanged and, as before, will only allow references of 35 characters or less.

Therefore, implementers are strongly advised to continue to supply references of 35 characters or less where so indicated in the RLC Data Dictionary under “EDIFACT size”. Many back-office systems, as well EDI implementations and all previous XML versions of the RLC standard, cannot accept references of greater length, especially in the case of contract or group references.

Workaround:
Request message provider to send Claim References of 30 characters or less.

Problem:
Documentation of First Message Logic in user guide is unclear.

Solution:
Update User Guide to clarify First Message logic for both TechAccounts and ClaimMovement messages.

Workaround:
For TechAccount or Placing a First Message is a message
Not Mapped to a Previous Message (User defined mapping granularity on an Insured Period i.e. can have multiple unmapped first messages)

For TechAccount or Placing a Subsequent Message is a message
Mapped to a Previous Message or
A message where the user has Manually Checked Subsequent Message

For ClaimMovement a First Message has message function New Claim

For ClaimMovement a Subsequent Message has message function Existing Claim or
A message where the user has Manually Checked Subsequent Message

For all other message types all messages are considered a first message
i.e. it is not possible based to skip validations have separate validations performed based on first subsequent messages.

Problem:

Claim reference field length is smaller than ACORD recommendation.

Solution:

Increase claim reference from current 30 to 50.

Problem:

Message processed without applying section split as necessary.

Message 2e3d74e0-4986-47ba-b254-84a555b1dda6 has processed fully automatically without any human intervention:

However, the bookings have all been assigned to the main section which does not have an adjustment condition set-up whereas there are also no accounting classifications linked to the main section either:

Main Section has no adjustment condition definition. Whereas Child sections do-
When we try to reverse the respective booking so this can be corrected we get this error:

Solution:
PreviousMessageMappingRule should consider Processing Option D (along with B) as being Specific regarding the Mapping Set flag Not for Specific.

The AdjustmentReferenceRule and Highlights edit of Adjustment must consider if the Adjustment condition is hidden due to Instalment status (not having instalments or being overridden on sub-section. If the Adjustment is hidden then any Adjustment present should not be considered for referencing.

Workaround:
If bookings are made on a Hidden Adjustment SQL required to de-link the Adjustment from bookings.

Problem:
We are going live with ACORD 2016 and we have come across an issue with outward acknowledgements (Initial & Chaser).

The query message function is not displayed on the highlights screen

We have set up the Query message functions and inwards acknowledgements work ok:

Solution:
When generating an Outbound Query Acknowledgement then execute the MessageFunctionReferenceRule to assign any explicit Message Function(s). Do not assign the default Message Function for Acknowledgement if no explicit assignment is made.

Workaround:

Root Cause:
A Message Function will only be assigned when a message is validated with the MessageFunctionReferenceRule. This will not happen for these messages as they cannot be validated, and have no rules, as opposed to incoming Acks.

Problem:
When a TA message is discarded with acknowledgement, and it is later referenced on a FA – it is not mapped to the FA. Meaning the UUID does not show up in the tech account message line.

This FA is processed and we manually indexed the worksheet after the FA has arrived. But originally it showed only status pending and not the uuid or anything. It does not show the uuid now either.

This way it is hard for us to identify what this balances is for.

And the uuid is available in the message, we just need to search for it today on the rendered view.

In our opinion it should be displayed as such:

Solution:
When a TechAccount is not referenced to an FAI, display the uuid of the TechAccount rather than blank.

Problem:
I have booked 4 Original Installment messages and then 4 Replacement Installment messages
When I book a Reversal I edit the Installment reference in the message highlights from 4th of 4 to 1st of 4. The message reverses both the Original Installment 1st of 4 and the Replacement 1st of 4 with two balances on a worksheet referencing the reversal message.

Solution:
When booking on an Instalment or Adjustment from an eMessage (eMessaging performing Book Instalment Adjustment from the condition works OK) ensure the cached details for the instalment adjustment are reset ensuring that any subsequent process on the same is considering all bookings.

Workaround:
One or both of the validation rules
ValidateNetBookedAmountOnInstalmentRule
CompareReceivedPremiumToNetInstalmentPremium
should raise an Error in this case on the replacement message.

These should not be overridden but rather ensure that the Reversal message is booked first.

Root Cause:
Booking Original Instalment, Reversal, Replacement messages out of sequence.

When booking Replacement before Reversal a timed cache of bookings for the instalment is incorrectly not refreshed. If subsequently booking the Reversal on the same instance within 300 seconds of the timed cache being established then the replacement bookings are missing. This leads to the wrong Worksheet Origin being assigned to a subsequent Reversal thus causing the entire instalment to be Reversed.

The Worksheet Origin being set to Automatic will reverse the Instalment as per acting on the Business Condition.
The presence of other active bookings (Replacement) , would lead the Reversal to have a Worksheet Origin of eMessaging which would simply perform the original reversal booking leaving the instalment with other bookings in place.

Problem:

While setting up the limit for tolerance in any of the validation rule system allows set upper limit till 4 places whereas for lower limit it is allowed up to 22 places.

Solution:
Ensure that the Min Max values for eMessaging tolerance Upper Limit and Lower Limit are consistent and reflect the size of the fields on the Database.
Confirm Decimal Places to 4 with min max values on the GUI to be set to + - 9 significant digits

Problem:

LOV's in the eMessaging universe are wrong for some objects and should be corrected.

Solution:

Need to change the LOV'S SQL for the below mentioned objects.

• Status                                                                
  Message Function
  Base Company (showing all partners names not just base companies)
  Claim Ref
  Exclusion Status
  Message Type
  Tolerance
  Rule Layer
  Error Type
  Attribute on Condition
  Worksheet Type
  Level of Business
  Type of Business (also there is typo in object name Business)
  Accuracy Validation Category
  Gov. Tax Rule Type
  Tax Type
  Category
  Party Role
  Tolerance Type
  Old Status
  New Status
  Event
  Intervention Action
  Sub Status
  Balance Status
  Business Ref

Problem:
Technical worksheet field is visible on Placing message references.

Solution:
Technical worksheet field should not be visible on the highlights tab of Placing messages.

Problem:
ACORD RLC Code Manual 20240531 and xml updates.

Solution:
System Default acord.framework GeneralCodes.xml and AmountCodes.xml updated.

Problem:
While processing e-msg FA a bug is encountered when having to reject single entries. 

Validation error: FAIBalanceReferenceRule

As per the rule description the solution is as follows:

the user has two main options. Either he can reject the FA Item, or you can link it to a SICS balance. If the item is left in pending status, the message cannot be processed. To reject the item, press the 'Reject this item' button.

After having pressed processed, the message gets back to status pending.

We would need to discard the message and create the settlement balance manually taking away the full e-messaging effect.

Solution:
If an FAI is automatically rejected by FAIBalanceReferenceRule then it should be re-referenced on a subsequent re-validation. A problem raised on an FAI that is automatically rejected should be retained and thus require resolution by a user. If the rejection reason is not resolved and the item should be rejected then a user must reject the item manually to confirm the rejection.

Corrected as part of Swiss Re. issue - SICSR-28652 in SICS 24.2 and SICS 24.1 SSP1
Introduced in SICS 23.4

Problem: In SICS System user guide under Business objects tab there is a one deleted image. But still the path of the image is not deleted.

Solution: Need to delete the path of the image.

Problem:   

Slow runtime of BOAC005

Solution: 

Additional indexes to be added for performance improvement .

Problem: 

We are not able to get the same one row extract as it is possible to see in SICS.

Solution: 

Need to adjust the Report Script of Reference Data Universe to get the Exact data same as in SICS.

Problem: 

The BOAC_PC_FACT table needs to replace with view V_BOAC_PC_FACT to improve performance.

Solution:  

View V_BOAC_PC_FACT needs to be altered also the views V_BOOK_PERIODS & V_ACCT_PERIODS needs to be created then all the objects that are coming from BOAC_PC_FACT should change to come from this view.
 

Problem:

BOAC_DIM_TIME index adjustment for faster and efficient running of reports.

Solution:

Creation of index is needed in SICS  to increase the performance.

Problem:

Worksheet Status of FRK_STATUS field on BOAC_PC_FACT table is showing as null.

Solution:

We need to change the FRK_STATUS field data type to varchar from char.

Problem: We are not getting the proper data for the objects Min and Deposit % and amounts in PC Main Universe.

Solution: Need to add column for the tables BO_PREM_CURR and BO_PREM_CURR_MAIN. Also need to make code changes for the view V_BOAC_PREM_CURR and need to adjust select statement for the object Deposit(Original).

Problem: 

'Premium Basis' is not available in the Business Object Universe, so the respective report can be created with proper information.

Solution: 

To resolve the issue, we need to add 'Premium Basis' field to the BO_PREM_CURR & BO_PREM_CURR_MAIN tables and add a new object for Premium basis in the universe level which will fetch the required data.

Problem:

Performance issue for Underestimate views  V_UW_EST &V_UW_EST_LATEST in SQL&Oracle databases.

Solution:

Need to replace  the existing script with new one  for better performances.

Problem:

Outer joins inconsistency issue in PC Main 24.1 Universe.

Solution:

Need to adjust the join structure in universe for a number of views (as attached in the excel file below) in such a way that we should always have CODE=FRK and SUBCLASS=FSK in one join and not in two joins as it is easier to maintain and get right data.

Problem: There are few tables in PC Main Universe that can be taken out which are not in Use.

Solution: Need to delete few alias tables that are no longer needed in the structure and do not have any associated objects.

Problem:

Missing some Joins and joins alteration in the PC main universe 24.1.

Solution:

Need to add the missing joins and joins alteration for PC main universe for the coming release.

Problem:

The view V_BOOK_PERIOD_TO_MONTHS needs to be replaced with V_BOOK_PERIODS & V_ACCT_PERIODS.

Solution:

Replacing the view V_BOOK_PERIOD_TO_MONTHS with the two new views V_BOOK_PERIODS & V_ACCT_PERIODS. (script is attached below).

We also need to create tables for the two new views like we had earlier BOAC_BOOK_PERIOD_TO_MONTHS table for V_BOOK_PERIOD_TO_MONTHS view.

Problem: To Update the views and make universe adjustments in PC Main Universe.

Solution:

1. Need to update the views V_BOAC_STL_PAIRING_BAL1, V_BOAC_STL_PAIRING_BAL2.
2. Need to create the views V_ACCT_PERIODS,V_BOOK_PERIODS in all databases.
3. Need to make adjustments to SQL & Joins of the Derived Tables.

Problem:

Wrong object used for Cover Basis % of Gross in 24.1 PC Main Universe.

Solution:

The object should be defined correctly using the existing development object 499. The existing development object 499 should be modified and renamed as 'Cover Basis % of gross- NEW OBJECT SHOULD BE HIDDEN'.

Then the object should be moved to the correct location i.e., General limit Information>Limits Information>Limits and Premium Condition>Business Information.

The Select statement of the existing development object 499 after renaming it and moving it to the correct location should be modified as 'LPC_LIM_PREM_COND.LIMIT_PCT_ORIG'.

Thereafter, we should make the object hidden.

Problem:

BOAC_PC_FACT, REPORTING_TABLE & AC_LEDGER_BALANCE tables and associated alias tables need to replace with views to get better performance.

Solution:

Need to adjust all the object definitions and joins to replace tables with views to get more performance.

Problem:

The view V_BALANCE_TIMELINE_PC needs to be adjusted. The select statements of a few objects should be modified as well so that it comes from the view V_BALANCE_TIMELINE_PC for better report performance. 

Solution:

The view V_BALANCE_TIMELINE_PC should be adjusted. The FROM part should start with AC_LEDGER_DETAIL instead of AC_LEDGER_BALANCE. (As per the script attached CREATE OR ALTER-REPLACE VIEW V_BALANCE_TIMELINE_PC.sql).

The Select statement of a few objects namely Pairing BYRP Date, Reval Bal BYRP Date, Reval dtl BYRP Date, Pairing BYRP date to, Reval bal BYRP date to and Reval dtl BYRP date to, should be modified so that it comes from the adjusted view V_BALANCE_TIMELINE_PC.

Like for eg, the modified SELECT statement of Pairing BYRP Date should be:

V_BALANCE_TIMELINE_PC.FIRST_DAY_OF_MONTH

Likewise for Pairing BYRP Date to it should be:

V_BALANCE_TIMELINE_PC.LAST_DAY_OF_MONTH

Problem:

Collateral detail amount does not reflect if increase or decrease in BI.

Solution:

We need to add this object  FRK_LOC_AMT_TYPE from BP_LOC_DTL. table in partner universe for the below three folders:

Collateral LOC
Trusts
Funds Held 

Problem:

Pairing timeline objects are mixing information from two pairing database views and this is causing a long run time for reports.

Solution:

Add aggregate aware function in the select statement for the pairing timeline objects (namely pairing booking year, pairing booking period(code), pairing booking year period, pairing date, pairing booking year period start date, pairing booking year period end date, pairing timestamp, annulment date and unsettled date) as shown in the attachment below and settlement indicator as at and settlement indicator as at(code).

Then for all these objects we also need to adjust the LOV so that the LOV does not contain a prompt but rather come from the required columns.

And lastly aggregate aware needs to be set up.

(Refer to the attachment Triglave Re - PC Main - Pairing Timeline Objects.xlsx& Triglav Re - PC Main Universe SICS 24.1 issues with Pairing Timeline Objects - Part 2.xlsx). 

After making all these changes the report needs to be verified (as per the attached report - 24.1 - Remitance - Pairings and Exchange Rate Difference.wid).

Problem:

Problem with some prompts that you must wait some time before values are retrieved - Underwriters Estimate.

Solution:

Need to create the object and also need to change the expression for the SQL.

Problem: To help FFH to maintain customization to PC Main universe we need to make changes for the objects and derived tables.

Solution: Need to update descriptions for the objects and comments to the derived tables in PC Main universe.

Problem:

Adding partner alert objects under responsible partners, payment partners and as well as under reinsurer and cedant (business information>business partner) to reduce cost, run time and improve report efficiency.

Solution:

First add four alias table for REFERENCE_DATA i.e., BOAC_RP_Alert_Reason, ACLB_RP_Alert_Reason, BOAC_PP_Alert_Reason and ACLB_PP_Alert_Reason.

Next join the two new alias tables
BOAC_Alert_Reason.CODE=PTY_BOAC_RP.FRK_RSN_FOR_ALERT AND BOAC_Alert_Reason.SUBCLASS=PTY_BOAC_RP.FSK_RSN_FOR_ALERT

(Refer to the screenshots below)

ACLB_Alert_Reason.CODE=PTY_SecPayPartner.FRK_RSN_FOR_ALERT AND ACLB_Alert_Reason.SUBCLASS=PTY_SecPayPartner.FSK_RSN_FOR_ALERT

Thereafter create a new sub-class Alert status with two objects- Reason for Alert & Reason for Alert(code) for responsible partner, payment partner, cedant and reinsurer.

Reason For Alert:            @Aggregate_aware(BOAC_Alert_Reason.NAME,ACLB_Alert_Reason.NAME)

Reason For Alert (Code):         @Aggregate_aware(PTY_BOAC_RP.FRK_RSN_FOR_ALERT,PTY_SecPayPartner.FRK_RSN_FOR_ALERT)

Problem:  

SICS 24.1 R&D still forget to remove sentences regarding view V_ORP_DATES on several places in chapter 16.11 in System administration guide (SICS docs).

Solution:

Need to remove the sentence regarding view V_ORP_DATES in System administration guide.

Problem:

Table with associated objects do not have any join to connect with universe that will result in cartesian product.

Solution:

Need to adjust the SQL of the objects that are associated with the table SJ_IND_CL_LOS_EST to come from the view V_SJ_IND_CL_LOS_EST.

Problem: Need to adjust definition & LOV SQL of the pairing Timeline objects for better performance in PC Main universe.

Solution:

1. Need to create aliases for the table AC_STL_PAIRING as AC_STL_PAIRING_BAL1 & AC_STL_PAIRING_BAL2.
2. Need to create joins for these new tables.
3. Need to adjust definition and LOV SQL of the objects.
4. Need to set up Aggregate Navigation.

Problem:

LOV's in the partner universe are wrong and should be corrected.

Solution:

Need to change the LOV'S SQL for the below mentioned objects.

• Business Partner Fund Type
• Insurance Product
• Benefit Covered
• Loc Type
• Trust Type
• Funds Held Type
• Processing Action
• MGU MCOB
• MGU COB
• MGU SCOB.

Need to add a table for  reference to the below objects.

• Database Server Name
• Database Name
• All Values
• Zero Value.

Problem: Missing space between the first name & Last name in LOV's also we are getting all the User LOV's not restricting to subclass.

Solution: Need to adjust LOV SQL for the objects so that we can have space between First name & last name in LOV and also to restrict the data.

Problem:

The bank account updated by gets updated even when rating is changed, which is not related to bank account. The bank account updated by is not reading the correct information from SICS.

Solution:

Change the SQL of the LOVs for Bank Account Updated by to:

SELECT DISTINCT
  concat(concat(CNU_BankAcc_UpdBy.FIRSTNAME,' '),CNU_BankAcc_UpdBy.LASTNAME)
FROM
  CNU_USER  CNU_BankAcc_UpdBy RIGHT OUTER JOIN BANk_ACCOUNT ON CNU_BankAcc_UpdBy.OBJECT_ID=BANK_ACCOUNT.FK_UPDATED_BY
ORDER BY
  1

Also change the object definition of Bank account Updated by to:

concat(concat(CNU_BankAcc_UpdBy.FIRSTNAME,' '),CNU_BankAcc_UpdBy.LASTNAME)

 
This would resolve the error and Bank account updated by would only pick the required information and not all the information.

Problem:

The Lovs for a number of objects are picking up all the data from the reference and not just the required data from reference data table.

Solution:

Restrict the SQL of the Lovs of the mentioned objects i.e., JV Entry Code, Type code, Base company name, Responsible roles, User role notes, User Case description, accounting function and accounting calculations by adding a subclass, so that we get the correct data output for that particular subclass.

Like for eg, the SQL of Lovs for JV Entry Codes will be:

SELECT
  concat(concat(REF_EDI_RINET_QUAL.CODE,' '),REF_EDI_RINET_QUAL.NAME)

FROM
  REFERENCE_DATA  REF_EDI_RINET_QUAL
INNER JOIN EDI_RINET_CODES ON
REF_EDI_RINET_QUAL.CODE=EDI_RINET_CODES.FRK_AMOUNT_QUAL and 
REF_EDI_RINET_QUAL.SUBCLASS=EDI_RINET_CODES.FSK_AMOUNT_QUAL

ORDER BY
   1

After modifying the SQL of LOVs of all the objects mentioned above it should give the right data while fetching the Lovs as well.

Problem:

LOV's in the Taskmanager universe are wrong for some objects and should be corrected.

Solution:

Need to change the Lov's SQL for the mentioned objects.

• Trigger Event Type
• PO User Group Language
• Start Action Type
• Documentation Language
• Escalation Type
• Escalation Doc. Description Language
• Notification Esc. Doc. Description Language
• Parameter Language
• Activity Status
• Escalation Type
• Event Type
• New Task Status.

Problem:

Because of reference to BOOK_PERIOD_TO_MONTHS in BO001 for truncation of BOAC tables, it is sometimes picking up wrong references.

Solution:

Replace the reference of BOOK_PERIOD_TO_MONTHS with BOOK_PERIODS and ACCT_PERIODS as provided in the attached script.

Problem:

Functions RTRIM,LTRIM & UPPER are effecting the performance of BOAC Scripts.

Solution:

Need to take out this RTRIM,LTRIM & UPPER from BOAC scripts that will improve the performance.

Problem:

Business ID Notes is picking wrong LOVs in PC Main universe.

Solution:

Change the SQL of LOVs of business id notes to:

SELECT DISTINCT
  CNU_NOTE_ID_NOTES.DESCRIPTION
FROM
  CNU_NOTE  CNU_NOTE_ID_NOTES
RIGHT OUTER JOIN BUSINESS BUSINESS_ID_NOTES ON
BUSINESS_ID_NOTES.FK_NOTE=CNU_NOTE_ID_NOTES.OBJECT_ID
ORDER BY
  1

After making this change it will limit the data.

Problem:

List of values in Reference data universe are wrong for some objects.

Solution:

Need to change the Lov's Sql for the mentioned objects in the Reference data  Universe.

Rating
Rating System

Problem:

Missing Base Company Full Name Object and Wrong LOVs for various Partner Full Names objects in PC Main Universe.

Solution:

Need to add the missing object

Object Name: Base Company Full Name.

Sql definition :Base_CON.FULL_NAME

The Wrong Lov's needs to be corrected .

Base Company Full Name

Cedent Full Name

Broker Full Name

Orginal cedent full Name

Former Orginal cedent full Name

Former  cedent full Name

Former Broker Full Name

Producer Full Name

Reinsurer Full Name

Tax Authority Full Name

Former Reinsurer Full Name

Orig  Reinsurer Full Name etc..  we have to correct the Lov's for the highlighted Objects. 

For reference I'm mentioning one correct Lov SQL similarly we can do for all the objects.

ObjectName:Broker Full Name

LOV:SELECT DISTINCT
  SJ_Broker_CON.FULL_NAME
FROM
  ORGANISATION_NAME  SJ_Broker_CON
right outer join PARTY PTY_Broker ON
SJ_Broker_CON.FK_ORGANISATION=PTY_Broker.OBJECT_ID AND SJ_Broker_CON.SUBCLASS=3
ORDER BY
  1    

Object Name:Cedent Full Name
LOV:SELECT DISTINCT
  SJ_Cedent_CON.FULL_NAME
FROM
  ORGANISATION_NAME  SJ_Cedent_CON  
SJ_Cedent_CON.FK_ORGANISATION=PTY_Cedent.OBJECT_ID AND SJ_Cedent_CON.SUBCLASS=3

Problem: 

Issue in the BOAC stored procedures BOAC004, BOAC005, and BOAC006 logic.  These procedures do not check the schema owner before attempting to drop an index. 

Solution:  

Want to ensure the index is checked against the correct schema.

SQLSERVER 

SELECT 1 FROM SYS.indexes I INNER JOIN SYS.tables T ON (I.object_id = T.object_id) INNER JOIN SYS.SCHEMAS S ON (T.SCHEMA_ID = S.SCHEMA_ID AND S.NAME = CURRENT_USER

Problem:

Joins are not given properly between a few tables in PC Main universe.

Solution:

 
Modify the join between BAL_BASE_COMP_BANK_PARTY & BAL_BASE_COMP_SWIFT
The new join should be defined as:

BAL_BASE_COMP_BANK_PARTY.OBJECT_ID = BAL_BASE_COMP_SWIFT.FK_PARTY and BAL_BASE_COMP_SWIFT.FRK_PARTY_ID_TYPE=’SWIFT’

Modify the join between BAL_BASE_COMP_BANK_AC_TYP & BAL_BASE_COMP_BANK_ACCOUNT
The new join definition will be:

BAL_BASE_COMP_AC_TYP.CODE=BAL_BASE_COMP_BANK_ACCOUNT.FRK_BNK_ACC_TYP AND BAL_BASE_COMP_AC_TYP.SUBCLASS=BAL_BASE_COMP_BANK_ACCOUNT.FSK_BNK_ACC_TYP

Modify the join between BASE_COMP_BANK_ACCOUNT & BASE_COMP_BANK_ACC_TYPE
The new join definition should be :

BASE_COMP_BANK_ACCOUNT.FRK_BNK_ACC_TYP=BASE_COMP_BANK_ACC_TYPE.CODE AND BASE_COMP_BANK_ACCOUNT.FSK_BNK_ACC_TYP=BASE_COMP_BANK_ACC_TYPE.SUBCLASS

Problem:

It is not possible to record Ceded share on a Proportional Treaty Outward Cedent's Contract by Web Service.

Solution:

It should be possible to record Ceded share by Web Service on an Outward Cedent's Contract, in the same way as it is possible to record this on an OCC online.

Problem:
Viewing an item within the User Defined Fields set up, like for Bank or a Person, with no layouts yet defined shows user defined fields of the previously viewed layout, like for Business.

Solution:
Viewing an item within the User Defined Fields set up with no layouts yet defined should not show the user defined fields of the previously viewed layout. Instead, the system should should show the list of user defined fields as empty.

Workaround:
System Administration / User Defined Fields Maintenance
Select the item that you want to create a layout for
Select New from the Pop Up Menu and create a layout: The list of fields will be set empty

Problem:

Period Estimation Rule - Not properly working on Retrocessionaire's Placements

Solution:

When Period Estimation rule having a selection of 'Calculation on Retrocessionaire', we make sure system should do the calculation on ORP level as per their 'our share amounts' for all type variable (example Deposit Premium, Minimum Premium, Premium amount and Flat premium)  and if it's not selected then value should retrieve from the OCC as per their ORP shares even though share within more than 2 decimal places. It should work from both the places (Manually and from the Recalculation Order).

Problem:

Issue with Webservice fastCreateTechnicalWorksheet when using Replacement Calculation with Claim ID/HLL id

Solution:

As per the web service createWorksheet, make sure that Claim Id, HLL and other values included in replacement value rules, are populated on the new detail created by the web service before any calculation of previous amounts takes place, also when running the web service fastCreateTechnicalWorksheet. 

For the fastCreateWorksheet web service, if the Replacement Value is set to True and the New Amount is given, the worksheet will not be closed automatically but remain Open. In this case, the user must go to the SICS workstation and close the worksheet manually.

Workaround:

If the Replacement Value is set to True and you want to enter the New Value, it is recommended to use the createTechnicalWorksheet SOAP web service instead of fastCreateTechnicalWorksheet to have a worksheet that closes automatically.

Root Cause:
The fastCreateTechnicalWorksheet is using same logic as the migration tool kit and therefore there is no calculation or validation of the given data. 

Problem:

We have problem that when we try to use Configuration Manager.

Solution:

The issue was resolved by updating the constructor call in the 'SicsConfigurationManagerCalculateMainTableVisitor' class to include the 'configurationManager' parameter. This ensures that the 'configurationManager' instance is properly initialized, preventing the walkback error when clicking on Configuration Manager. 

Problem:
Changes of identifiers on Facultative Intermediary businesses are not shown in log view. 

Solution
When Insured Period Former Identifier and Original Former ID have been set to be logged for an intermediary participation, then changes in these fields should be shown when the user selects Log from the menu bar. It should be shown in the same way, as the system currently correctly shows changes of these for a Retrocessionaire Participation.

Problem:

When on the claim conditions of an outward cedent's contract, updating information, the changes are not shown in Log View here nor in the log view of sub businesses, like an intermediary participation.

Solution:
When Log Activity Settings are enabled for Event logging, each activity on the Claims Condition should be logged and displayed in Log View, also of parent businesses, like Outward Cedent Contractor Intermediary Participation, (like it correctly does for e.g. Deduction Conditions)

Problem:

Find Claim Program and Claim Program properties display empty location for existing Claim Programs (ie created prior to support for multi location).

Solution:

The location must be displayed both on Claim program and in Find Claim Program.

Workaround:

1) If no claims are linked to the Claim Program, edit the Claim Program, and add the location.
2) If claims are linked to the Claim Program, de-link all claims from the Claim program without location, add the location to the Claim Program, and then relink the claims.

Root Cause:

SE-21793

Problem:

Remittance Authorization from CREW via SOAP call results in unexpected validation for missing Due Date

Solution:

When running the web service changeStatusRemittanceBalance and change the status from e.g. In Progress to Authorized or from Authorized to Final, the system shall NOT set neither the Value Date nor the Due Date to null, but keep them as they are and validate them according to existing functionality.

Root Cause:

Caused by enhancement case SE-22506 in version 23.4

Problem:

Annulment date issue in the two views V_BOAC_STL_PAIRING_BAL1 and V_BOAC_STL_PAIRING_BAL2 and the OBJECT_ID on BOAC_STL_PAIRING  this should be adjusted.

Solution:

In order to get the  correct data we need to adjust some changes in the database and Universe.
Annulment Date for the view and the  join OBJECT_ID to TS_AND_OBJECT_ID needs to be adjusted in the Universe.

Problem:

LOV's for few objects are wrong and also missing space between Year and Month.

Solution:

Need to Adjust the Object definition for Booking Year Period. It should be defined as:

concat(concat(GL_T_ALL.BAL_BOOKING_YEAR,' '),SJ_REF_BYPPeriod.NAME)

Need to Adjust LOV SQL for Booking Period, Entry Code Sub Category, Origin Of Business and Settlement Indicator from all different folders.

Aim of function

The user experience of grouping contracts has been improved.  The user can now manage offer groups, merger groups, bouquet calculation groups and master treaty groups from one and the same place on the contract, namely on the groups tab. Also, while being on the contract, the user can now use new icons for finding, listing, creating and assigning groups.  

Business value for customers

Improved user experience and usability.

System Parameters Affected

N/A

Existing functionality affected

Manage Offer Group
Manage Bouquet Calculation Group
Manage Merger Groups
Manage Master Tretay Groups

Aim of function:
Introduce support for FGU creator and timestamp in domainRetrieval API

Business value for customer
FGU advisories can be retrieved with creator and timestamp

System Parameters affected
None

Existing Functionality affected
domainRetrieval API

Aim of function

• To include the Cedant reference (Receiver Business Ref) in the search criteria of the eMessaging find window

Business value for customers

• Cedant Reference (Receiver Business Ref) will be made available to search eMessages in the eMessaging find window.
• Applicable for LORS (Lloyd’s Outward) Messages

System Parameters Affected

None

Existing functionality affected

Processing of eMessages.

Aim of function

• To include a column for Transaction Type and Transaction Reference in the grid view

Business value for customers

• Transaction Type and Transaction Reference column will be made available in grid view under eMessaging find window.
• Applicable for LORS (Lloyd’s Outward) Messages

System Parameters Affected

None

Existing functionality affected

Processing of eMessages

Aim of function

When the rule ModifyCMAccountClassificationReferencing is defined the reference to AC is required according to eMessaging Processing option. By Extending the functionalities of Accounting classification mapping and Previous message mapping to CM Messages reference to AC is maintained automatically by mapping rules.

Business value for customers

System will make a reference to the Accounting Classification on CM Messages.

System Parameters Affected

Classification Mapping

Previous Message Mapping

AccountingClassificationAfterSectionReferenceRule

AccountingClassificationReferenceRule

PreviousMessageMappingRule

Existing functionality affected

Accounting Classification Reference

Aim of function

To book the missing detail amount of a Multiple Account Type Group when emessage is received with only one detail amount along with a total amount in a group.

Business value for customers

• The missing detail amount will be booked on a worksheet. 
• Correct amounts on the ledger. 
• CompareDuplicateEntryAmounts rule will not raise an error for missing a detail amount in a group.

System Parameters Affected

CompareDuplicateEntryAmountsRule

Existing functionality affected

Booking of individual items in Multiple Account Type Group

Aim of function
The functions Ultimate Loss Ratio Import & UW Estimates Supporting Figures Import only support .CSV files, they should also support Excel and any other formats supported by the tabular framework.

Business value for customers
Ease of uploading files using the Excel spreadsheets, including generating a template with precise details of the needed fields..

System Parameters Affected
N/A

Existing functionality affected
Ultimate Loss Ratio Import & UW Estimates Supporting Figures Import

Aim of function

To enable the flow of figures generated through MultiGAAP Retrocession order on Non-Prop ORP to Prop OCC (i.e., linked through PP condition on Non-Prop OCC) and to enable the flow of manual bookings present on 'Non-Prop ORP' to 'Prop OCC' which is linked through PP condition on 'Non-Prop OCC'.

Business value for customers

User can now notice the figures generated through MultiGAAP Retrocession Order also flow to linked 'Prop OCC' as how the manual bookings are transferring as per existing functionality.

User can now notice the Manual bookings present on Non-Prop ORP transfer onto Prop OCC which is linked through PP condition on Non-Prop OCC.

System Parameters Affected

NA

Existing functionality affected

MultiGAAP Retrocession Order.

Aim of function

Generate nearly all of the API documentation from code - we will have a template framework which may include other elements.
Use the XSD as much as possible to ensure maximum visibility

Business value for customers

Provide easily accessible, up to date generated documentation for SOAP webservices for SICS API Server.

System Parameters Affected

None

Existing functionality affected

None

Aim of function
DB/2 is no longer a supported DBMS platform. However there are remnants of the DB/2 support visible in the UX, which can be confusing.
The DB/2 elements are removed.

Business value for customers
Less confusion when using the system admin functions.

System Parameters Affected
None

Existing functionality affected
Manage Tables

Aim of function

To introduce a new option under Booking Terms i.e. ‘MG/UW Specific’ for Period Offset expressed in Months for both Multi GAAP & Underwriters Estimates will be available under ‘Booking Terms Maintenance’ window. 

Period Offset from system parameter Multi GAAP/General should be considered as the default setting if the newly introduced option is left blank.  

Business value for customers

This newly introduced option will enable the user to specify any base company, where they wish to record the period offset in months for Multi GAAP & Underwriters Estimates.

System Parameters Affected

Period Estimate Offset Quarter 

Existing functionality affected

Period Offset from Multi GAAP system parameter will be overwrite when newly introduced period offset is in use. 

Aim of function

To enhance the Multi GAAP Retrocession Order, so that users can book Estimates/Accruals on Facultative Business as well, using the Period Estimates on Facultative OCC.

Business value for customers

Automating the booking of Estimates/Accruals on Facultative Business, as we have for the Treaty Business. 

System Parameters Affected

None

Existing functionality affected

The Type of Business for Multi GAAP Retrocession Order.

Analyze the Reinsurance contract documents to identify discrepancies between the original PDF contract wording and the digital contract entry represented in JSON format. Focus on key areas such as:

1. Contract Parties: Ensure the names and addresses match between the PDF and the JSON entry.

2. Policy Limits and Terms: Compare policy limits, coverage terms, and expiration dates to verify consistency.

3. Premiums and Payments: Check that the payment terms, amounts, and schedules align.

4. Special Conditions and Exclusions: Identify any mismatches in special conditions or exclusions listed in the documents.

5. Signatory and Date: Confirm that the signing parties and date of agreement are correctly recorded.

Report any discrepancies found, categorizing them by the type of mismatch (e.g., policy terms, payments, conditions). Provide a brief summary of each discrepancy and suggest potential reasons for the mismatches if apparent from the context. Include direct quotations from the documents where relevant to support your findings.

Aim of function
Enable asynchronous logging in the log4j framework as a potential performance benefit when diagnostic logging is enabled.

Business value for customers
The ability to perform diagnostic logging to identify issues without incurring a runtime performance overhead.

System Parameters Affected
N/A
Existing functionality affected
N/A