Release documentation - P&C Enhancements and requests

Problem:
Incorrect uw-year assigned to Claim booking when system parameter 'Transfer Premium/Portfolio on OCCs with Claim Basis Losses Occuring' is active.
The uw-year of the Claim detail is not the uw-year according to the Insured Period of the detail, but the original uw-year.
The Accounting Year/Period and the Accounting Period From-To of the Claim is also incorrect.

Solution:
When system parameter 'Transfer premium/Portfolio on OCCs with claim basis Losses occurring' is active and the Claim detail made on the source business (e.g. Assumed Business) is with a Date of Loss/Claims Trigger Date higher than the Insured Period To of the protecting OCC, this Claim detail is made on the OCC renewed IP. In addition, the uw-year of the outward claim detail (as Booking) must be the uw-year from the assigned Insured Period.
Furthermore, the Accounting Year must be increased by one, compared to the one on the Order and the Accounting Period must be set equal to the 1st Accounting Period for the Accounting Year (i.e. the same as the ACYRP assigned for the Portfolio Entry).
Ensure that the Accounting Period From-To reflects the Accounting Year/Period assigned to the detail.

Workaround:

Root Cause:

Extent of Impact:

Impact on Existing Data

Recovery Method for Existing Data Affected

Problem:
Unable to complete pairing if the included balance becomes partially settled and has an Expected Payment balance linked.

Solution:
When an included technical balance becomes Partially Settled during the balance pairing, and this balance is linked to an Expected Payment balance, we must make sure the Expected Payment balance is deleted during the pairing process so that the pairing can be completed and the included balance set to Partially Settled. This is independent if the parameter 'Always keep Expected Payment Balance after pairing' is selected or not, and independent if the currency of the Expected Payment balance is the same as the currency of the driving balance or not.
When this situation occurs and the the Expected Payment balance has to be deleted, then a new informational message should appear, telling the user that a balance becomes Partially Settled and therefore the Expected Payment is deleted.

Workaround:

Root Cause:

Extent of Impact:

Impact on Existing Data

Recovery Method for Existing Data Affected

Problem:
Unexpected Hard stop error for Loss portfolio withdrawal

Solution:
When booking details for Loss Portfolio Withdrawal on a worksheet and the Calculation Method for the Loss Portfolio Withdrawal is Pct of Reserve (Premium Portfolio Withdrawal is Pct of Premium), and the worksheet is applied to the database so that the accuracy validations take place, then the calculation in the validation process must
1) calculate the loss withdrawal in base currency as the NEW cumulated loss portfolio withdrawal (including current worksheet) LESS the PREVIOUS cumulated loss portfolio (exclude current worksheet). This is working fine for premium when it is based on Pct on Premium.
2) sum up the previous cumulated premiums or loss reserve on all closed worksheets less those premium/loss reserves belonging to the same worksheets as the relevant premium/loss portfolio withdrawal.

Workaround:

Root Cause:

Extent of Impact:

Impact on Existing Data

Recovery Method for Existing Data Affected

Problem:
Technical Account Document production abends when System Parameter is set for Accounting - Retrocession - General - Miscellaneous - Show cumulated Reserves on TA

Solution:

Remove abend

Workaround:

Root Cause:
SICS 4.9.5 SE-1863 New tags for technical Account template

Extent of Impact:
Accounting - Retrocession - General - Miscellaneous - Show cumulated Reserves on TA

Impact on Existing Data

Recovery Method for Existing Data Affected

Problem:
Change in Loss Incurred PBR is not correctly processed for Worksheet with multiple Entry Codes

Solution:
When running the PBR report Change in Loss Incurred for a worksheet containing multiple entry codes with Loss Incurred and the sum of these details is different from zero, even if one or more of the details are zero, then the report must be triggered.

Workaround:

Root Cause:

Extent of Impact:

Impact on Existing Data

Recovery Method for Existing Data Affected

Problem:
Listing balances on Business Partner Ledger takes long

Solution:
1. Make a new system parameter under Accounting, Worksheet, named 'For Intra Group Contract bookings, show WS Id of source ORP booking on BP Ledger'
2. When the above new system parameter is selected then the new column Source WKs ID on ORP is available on the BP ledger. If an Intra Group Contract IAB balance is highlighted on the BP Ledger it will show the Worksheet Id of the ORP booking and the popup menu will enable the new option Source Settlement Status. If this option is selected the system will open a small window with information about the source ORP balance (Business Id, Worksheet Id, Currency, Balance Amount, Unsettled Amount and Settlement Indicator)
If this parameter is not selected then this new column and the new popup menu option are hidden.
3. Make sure the functionality and the logic implemented in SE-3183 is NOT activated with the above system parameter off.

Workaround:

Root Cause:
Enhancement of SE-3183 in version 20.3

Extent of Impact:

Impact on Existing Data

Recovery Method for Existing Data Affected

Problem:
Wrong calculation of discrepancy amount in accuracy validation log

Solution:
When the warning message AC0770 appears because the difference between the computed amount for the trigger entry code and the entered amount for this trigger entry code exceeds the upper limit in the actual accuracy validation rule, we must make sure the amounts shown in the message is the original amount of the details booked, both the computed value and the entered value.
But of cause, the calculation of the discrepancy between the computed value and the given value must be converted to the Base Currency in the rule so that it can be compared with the Upper Limit in the rule.
We also need to change one more sentence in the AC0770 message so that it becomes clear that the '.....Upper Limit in Base Currency XXX nnn', where the XXX shows the Base Currency from the rule and nnn shows the Upper Limit in the rule. This will make it clear for the user what the system is computing.

Workaround:

Root Cause:

Extent of Impact:

Impact on Existing Data

Recovery Method for Existing Data Affected

Problem:
Extended Booking Terms list of orders - Occurrence Year Allocation of Losses

Solution:
Make sure the accounting order type Occurrence Year Allocation of Losses is among the Available Accounting Order Types in the Extended Booking Terms in system parameter Base Company Specific Settings.
Make also sure that the Extended Booking Terms functionality is working as for other accounting orders when Occurrence Year Allocation of Losses order is selected, i.e. the extended booking periods are available in the Booking Year/Period field on the order and the selected period will be used, if not selected then the default booking period from the extended booking term will be used.
Since this is an accounting order for multi base companies, the system will use the Booking Terms for the Base Company <Default Settings>, if none, two or more base companies are selected. But if only ONE base company is selected on the order, then the system will use this base company's settings.

Workaround:

Root Cause:

Extent of Impact:

Impact on Existing Data

Recovery Method for Existing Data Affected

Problem:
Unable to close technical worksheet with link to headline loss

Solution:
1) Make a new system parameter on the Accounting, P&C Miscellaneous tab, named e.g. Only warning message when linked Headline Loss is outside IP.
2) When this parameter is NOT selected, existing functionality remains so that the error message AC0249 appears if portfolio conditions are missing. But if the new system parameter is selected, then the system will never present error message AC0249, but in all situations where this currently is triggered, present warning message AC0497 instead.

Workaround:

Root Cause:

Extent of Impact:

Impact on Existing Data

Recovery Method for Existing Data Affected

Problem:
Wrong calculation of the Premium Portfolio Entry for a new ORP on the next (opening) Insured Period when Premium Portfolio Entry is in pct of Premium and the Premium Accounting Basis is Run-Off

Solution:
Running Retrocession Calculation Order for the last Account of the Insured Period;
SICS must use the Premium amount for the last Accounting Year of the Insured Period to be closed as basis for the calculation of the Premium Portfolio Entry for the next (opening) Insured Period when Accounting Basis = Run-Off

Workaround:

Extent of Impact:

Impact on Existing Data

Recovery Method for Existing Data Affected

Problem:
Mass Pairing - Paid column in Administration Condition incorrectly updated to 'Yes' even when the matching balances could not be paired

Solution:
When in the Mass Pairing, the system finds a match between a technical balance and a remittance the system will update the matching account on the administration conditions as part of the pairing between these two matching balances. But if the pairing cannot be completed e.g. because the matching remittance is in a pending status and this is not allowed according to the setup in the system (or any other reason), then we must also make sure the system does not update the matching account on the administration conditions.

Workaround:

Root Cause:

Extent of Impact:

Impact on Existing Data

Recovery Method for Existing Data Affected

Problem:
Recovery Calculation OCC Claim Figures View includes ACR Expenses Unplaced Share although ACR is not included in Recovery calculation

Solution:
When system parameter 'Include ACR in Recovery Calculation' is NOT selected, ACR Expenses Unplaced Share should NOT be included as a column in OCC Claim Figures view.

Workaround:
None

Root Cause:

Extent of Impact:

*+Impact on

Problem:
TW via Web service abends

Solution:
When running createWorksheet or createClaimWorksheet with or without chained operation with closeWorksheet we must also make sure the element 'lmmReference' has been properly removed and that the element 'londonMarkedReference' is available and used.

Workaround:

Root Cause:

Extent of Impact:

Impact on Existing Data

Recovery Method for Existing Data Affected

Problem:
Calculation of Instalment amount to be booked on an eMessage is including Government Tax on Deductions

Solution:
Ensure that all Government Tax amounts that are mapped via Tax Application mapping to Government Tax Entry Codes are excluded from the calculation of Instalment amount

Workaround:

Root Cause:

Extent of Impact:

Impact on Existing Data

Recovery Method for Existing Data Affected

Problem:
A normal balance pairing assigns one pairing ID to all the included balances of SBGs in SICS 4.8.6 SSP18. But in this its shows different paring IDs.

Solution:
When creating balance pairing through the Mass Pairing function and the system uses the same remittance balance as the driving balances for several included balances, because they belongs to a balance group (SBG or ABG), then the system must create and use the same Pairing ID on all pairings with this driving remittance balance.

Workaround:

Root Cause:

Extent of Impact:

Impact on Existing Data

Recovery Method for Existing Data Affected

Problem:
updateWorksheetDetail does not update some fields

Solution:
1.
When the web service updateWorksheetDetailInformation is executed and the Accuracy Validation Category and Accuracy Validation Comment fields shall be updated for a certain detail we must make sure both of these fields can be updated properly on the worksheet if the detail is pointed to by the fk_source_dtl in the acc_val_rule_log table AND that the ACC_VLD_MSG is not null. In case the detail in the soap does not have such link or the ACC_VLD_MSG is null, then nothing will be updated in these two fields for this detail.
This is the case both when the detail belongs to a TW and a CW.
2.
When the web service updateWorksheetDetailInformation is executed and the Tax Country, Tax % and Tax Type fields shall be updated for a certain detail we must make sure that these fields are updated properly on the CLAIM worksheet on the actual detail. This is working fine for a technical worksheet.

Workaround:

Root Cause:

Extent of Impact:

Impact on Existing Data

Recovery Method for Existing Data Affected

Problem:
Able to pair Received remittance via Mass update although I expect AC0504 message

Solution:
When balance pairing takes place through the periodic function Mass Pairing, and the system parameter 'Validate BYRP in Balance Pairing' is selected, the the system must check each pairing and if one or more of the pairing fails, i.e. because the Booking Year/Period on one or more of the included balances is higher than the default booking year/period, then if this is the case for a pairing, this pairing is interrupted (will not take place) and the system will continue with the next pairing to be performed (same as when message AC0504 is triggered when the pairing takes place online).

Workaround:

Root Cause:

Extent of Impact:

Impact on Existing Data

Recovery Method for Existing Data Affected

Problem:
Failed to reverse wrong uploaded remittances

Solution:
With the system parameter Reverse with Re-Calculation NOT selected and when a remittance balance is reversed the system sets the flag 'Functional Currency is Manually Set by User' to true. This is to indicate that the FC amount shall be kept when the worksheet is closed. When this reversal remittance balance is set to Final and committed to the database we must make sure this flag is used so that the FC amounts are kept.
Only if the user make changes to the balance attribute that triggers a recalculation, e.g. if the balance amount or currency is changed, then the system shall recalculate (and the flag removed)

Workaround:

Root Cause:
This is caused by an internal case back in 2014, internal tracker 66030, in version 4.4.2:
When the system parameter 'Change Functional Currency Rate For Pending Remittances' is On then the system shall recalculate the FC Amount 1 and FC amount 2 if the FC amounts are zero.
This overrules the new flag on the balance 'Functional Currency is Manually Set by User'

Extent of Impact:

Impact on Existing Data

Recovery Method for Existing Data Affected

Problem:
When running the Occurrence Year Allocation of Losses order with zero details the FC amounts are not zero

Solution:
When running the Occurrence Year Allocation of Losses Order and the details to be booked are created, we must make sure all details with zero amounts are suppressed and not booked on the worksheet.

Workaround:

Root Cause:

Extent of Impact:

Impact on Existing Data

Recovery Method for Existing Data Affected

Problem:
Automatic Booking of Gov Taxes not working consistently

Solution:
When the user on the worksheet manually book both a government tax trigger AND target entry code with the amount of ZERO and then select the option Change Status or press the button Apply so that the validation of the government tax target detail takes place, then the system must present the error message AC0837 for the user and inform that the entered zero amount is wrong compared with the computed amount, and NOT replace the zero amount with the computed amount. This takes correctly place if the target amount is different from zero (and different from the computed amount), but not if the target amount is zero.
It also works fine if the target detail of zero amount has already been validated and linked to the trigger GT detail in the rule, then the system correctly use the zero amount in the validation and keeps the zero amount on the detail.
One exception to the above:
If the Automatic Booking is selected in the GT Rule and if the target GT detail exists, with Amount of zero or blank, and this detail is NOT linked to a trigger GT detail, then it shall still be recalculated and replace the existing target GT detail amount.

Workaround:

Root Cause:

Extent of Impact:

Impact on Existing Data

Recovery Method for Existing Data Affected

Problem:

Adjust Claim Figures in Underwriter Estimates Order – List Businesses is returning all Business matching the specified Criteria but also ones that are Marked Estimates Complete. Although the Adjusted Estimates are not generated, it is a waste of time including them in the list and makes identifying business that have been updated very hard to identify.

Solution:

Make sure the List Business function on the Adjust Claim Figures in Underwriters Estimates Order (Underwriters Estimation Calculation Order) excludes insured periods where the Estimation Complete flag has been set

Workaround:

Root Cause:

Original implementation

Extent of Impact:

Impact on Existing Data

Recovery Method for Existing Data Affected

Problem:
Create Balance Pairing function for URB is disabled in SICS4.8.6SSP19

Solution:
When an Unallocated Remittance Balance with Allocation Status Unallocated (i.e. it is paired with a Remittance balance) is highlighted on either the Business Ledger or the Business Partner Ledger, a new popup menu option named e.g. Replace selected URB in Pairing is enabled, independent if it is involved in a balance pairing that is Pending or Definite (Pending flag is false).
When the user selects this option, then the system will annul the URB from the driving Remittance balance. The user is now free to include and replace the URB with other balances found on the BP Ledger; technical/claim balances, balance groups (SBG/ABG) or other remittance balances. When the user select OK to complete these pairings, the system will allocate the same Pairing ID for the annulling of the URB and all the new pairings created.

Workaround:

Root Cause:

Extent of Impact:

Impact on Existing Data

Recovery Method for Existing Data Affected

Problem:
Gov. Tax Category OR Comment fields not emptied after using Automatic Gov. Tax Booking option on WS

Solution:
When the user enter a Government Tax trigger entry code on the worksheet and Apply/Change Status on this worksheet without entering the respective target entry code then the message AC0834 appears correctly. If the user now automatically calculates or manually enter the missing GT target entry code and again press Apply/Change Status, then the system must remove the Government Tax Category/Comment from the GT source detail if existing.

Workaround:

Root Cause:

Extent of Impact:

Impact on Existing Data

Recovery Method for Existing Data Affected

Problem:
GOV TAX - Cedent outside Tax Country and VAT should not be validated

Solution:
When the user selects the Automatic Booking of Government Taxes or the system validates the government tax rules we must make sure all criteria on the rule are fulfilled before the rule is used. This is working fine except for the Cedent within Tax Country. If the Cedent within Tax Country is set to Yes, the rule shall only be triggered if this is the case. Today the system instead check if the Cedent country is within the Cover Area defined in the rule.

Workaround:

Root Cause:

Extent of Impact:

Impact on Existing Data

Recovery Method for Existing Data Affected

Problem:
GOV. TAX - TA - Automatic Gov. Tax Booking doesn't work if partial Target EC is already booked - partially fixed

Solution:
When the user on the worksheet manually book both a government tax trigger AND target entry code and then select the option Automatic Calculation of Government Tax, without pressing Apply to validate the target detail first, then the system correctly calculates the GT trigger amount BUT it also keeps the manually entered amount and adds this to the calculated amount. We must make sure the system REPLACE the manual given amount with the new calculated amount.

Workaround:
If the user press Apply BEFORE selecting Automatic Booking of Government Tax, then the system will correctly replace the target amount, i.e. when the target details already is linked to the Government Tax Rule Ref

Root Cause:
SICSR-21705

Extent of Impact:

Impact on Existing Data

Recovery Method for Existing Data Affected

Problem:

Options to modify and revoke commutations on assumed businesses are dependent on system parameter 'Allow Revoke Commutation when Account is booked/commuted'

Solution:

On Assumed Businesses only:

• When Commutation Status = Commuted, options 'Modify Commutation' and 'Revoke Commutation' should always be available, independent on system parameter 'Allow Revoke Commutation when Account is booked/commuted'
• When Commutation Status = Revoked, options 'Modify Commutation' and 'Business to be Commuted' should be always be available, independent on system parameter 'Allow Revoke Commutation when Account is booked/commuted

**Workaround:

Root Cause:

SE-7678

Extent of Impact:

Impact on Existing Data

Recovery Method for Existing Data Affected

Problem:
Gov. Tax Category AND Comment fields not emptied after using Automatic Gov. Tax Booking option on WS

Solution:
When the user enter a Government Tax trigger entry code on the worksheet and Apply/Change Status on this worksheet without entering the respective target entry code then the message AC0834 appears correctly. If the user now automatically calculates or manually enter the missing GT target entry code and again press Apply/Change Status, then the system must remove both the Government Tax Category AND Comment from the GT source detail if existing.

Workaround:

Root Cause:

Extent of Impact:

Impact on Existing Data

Recovery Method for Existing Data Affected

Problem:
String Length Error while uploading Input File Balance

Solution:
The BP Reference (bp_ref) field in the ac_ledger_balance table is a VARCHAR2 field of 40 characters and therefore the file used in the function Automatic Search for SBG that contains a BP Reference of less than or equal 40 characters must be allowed. The error should appear only if the BP Reference exceeds 40 characters, and then the message should read: String value is longer than the maximum length (40).

Workaround:

Root Cause:

Extent of Impact:

Impact on Existing Data

Recovery Method for Existing Data Affected

Problem:
TA shows the same bookings many times

Solution:
Interation on document to be fixed.

Workaround:

Root Cause:

Extent of Impact:

Impact on Existing Data

Recovery Method for Existing Data Affected

Problem:
Unable to assign a Remittance Worksheet type Write Off to a Settlement Balance Group

Solution:
When the user creates or edit a balance group, both Settlement Balance Group and Account Balance Group, it must be possible also to include unsettled remittances of type Write Off. This should be possible independent if the system parameter 'When Pairing, always use Remittances as the driving Balance' is on or off.

Workaround:
Keep the Write Off remittance outside the balance group and include it in the balance pairing together with the balance group when the balance pairing takes place.

Root Cause:

Extent of Impact:

Impact on Existing Data

Recovery Method for Existing Data Affected

Problem:
Exclude GL Transferred pairing of Unallocated Remittances

Solution:
1. In the domain restriction 'Accounting Balance Pairing Annulling' there is a tick fox for 'Annulling a Transferred Pairing not Allowed'. When this is selected a new tick box becomes enabled, named 'Exclude Transferred Pairing of Unallocated Remittance'
2. When the user is assigned to this domain restriction with the new tick box selected, this user shall still be restricted from annulling pairing in general, but with the exception that annulling of pairing with unallocated remittances involved shall be allowed.
3. When the new option Replace Selected URB in Pairing is selected for an Unallocated URB on business ledger or BP ledger and this URB has been annulled before, i.e. has inactivated pairings, we must make sure the system uses the ACTIVE pairing when the URB is annulled from the driving remittance, so that message AC0403 does not appear anymore.

Workaround:

Root Cause:

Extent of Impact:

Impact on Existing Data

Recovery Method for Existing Data Affected

Problem:
Gov Tax Booking and Gov Tax Tab on Reinstatement Message does not work correctly
When there is a Gov Tax error on the RIP booking (Swap to worksheet and apply) then this is not reflected when Processing the message. There is no Gov Tax problem raised or presented on the Gov Tax tab.

Solution:
When processing a TA RIP message with Gov Tax applicable settings then the message bookings should be validated against the Gov Tax, If there is a problem then it should be logged on the worksheet and present an error on the message problems tab and the Gov Tax tab.

Workaround:

Root Cause:

Extent of Impact:

Impact on Existing Data

Recovery Method for Existing Data Affected

Problem:
Reverse Balance option produces duplicate booking rows

Solution:
When a balance or detail is selected on the business ledger or BP ledger, and the balance contains of Government Tax details, and the user selects the option Revers or Reverse and Replace Balance, we must make sure the system only reverse the details/balance once.

Workaround:
When reversing Worksheet, it seems to reverse the details/balances only once.

Root Cause:

Extent of Impact:

Impact on Existing Data

Recovery Method for Existing Data Affected

Problem:
The windows of SICS condition screen : Commission, Deductibles and Profit Commission are not resized and the new fields are not aligned correctly. Gui Cleanup required.

Solution:
All relevant fields should be visible in view and edit mode.
This also applies to the fields for 'Final Year End Calculation Frequency' in Deduction Condition and Profit Commission condition when Sliding Scale and Stepped Sliding Scale Commission and in Deductibles condition when Loss Corridor.

Workaround:
Maximize widow

Problem:
Sum up from child sections on Non-Proportional Treaty leads to abend when one is with Flat Premium and another - with Fixed Rate.
Abend happens only when Section with Flat Premium is summed up first.

Solution:
When having sections with different Premium Types, at least one having 'Flat Premium', system should NOT abend when summing up premium values to the parent section which is with 'Fixed Rate'.
System should not abend independent on which order the sections are summed up.
When summing up Premiums from sections with different Premium Types, at least one having 'Flat Premium', the 'Period Premium' should be summed up to 'Deposit Premium' on the parent section and the 'Minimum Premium' should be set to 0 - as per existing functionality. 'Minimum Premium' can, if wanted, be manually entered on the parent section.

Declination Reason:

Workaround:
Firstly sum up the Section that has Fixed Rate premium type. Then, sum up the Flat Premium Section

Root Cause:

Extent of Impact:

Impact on Existing Data

Recovery Method for Existing Data Affected

Problem:
When having connected an Extending amendment to a Non-Proportional Facultative Protection Assignment, and here selecting the Amendment button (extension), the value in the Def. Placed % column displays 0 instead of the Signed Share of the Non-Prop FAC Protection business of the same Amendment.

Solution:
When having connected an Extending amendment to a Non-Proportional Facultative Protection Assignment, and having pressed down this Amendment button, the value in the Def. Placed % column must be taken from the Signed Share of the Non-Prop FAC Protection business of the same Amendment, and not display the current 0 (unless the share really is 0).

Workaround:

Root Cause:

Extent of Impact:

Impact on Existing Data

Recovery Method for Existing Data Affected

Problem:
Under Deduction condition flow, for Stepped Sliding Scale Commission, when importing the table on Edit Stepped Sliding Scale Commission window, the value of Maximum Loss Ratio shown in Maximum Loss Ratio column is not correctly displayed.
However, after table is saved, the value of Maximum Loss Ratio displayed on Stepped Sliding Scale is correct.

Solution:
1. ‘Edit Stepped Sliding Scale Commission’ screen – when pop-up option ‘Import Table’ is used to load a table with data, the mentioned Edit screen must immediately display correct calculated values of ‘Max Loss Ratio’ based on the import file, right after button ‘Import’ is pressed and even before pressing the Save button.
Right now, if there are 2 or more rows in the imported file, the system is displaying wrong initial values for column ‘Max Loss Ratio’ (see first screen below) which are automatically fixed later when first ‘Save’ button is pressed.

2. ‘Edit Stepped Sliding Scale Commission’ screen – when pop-up option ‘Import Table’ is used to load a table with data, AND user presses the first button Cancel (see second screen below), the loading process must be aborted and the loaded data must be removed and deleted.
Right now, even if users presses the first button Cancel, the loaded data remains, just as if user pressed button ‘Save’, instead of ‘Cancel’.

Declination Reason:

Workaround:

Root Cause:

Extent of Impact:

Impact on Existing Data

Recovery Method for Existing Data Affected

Problem:

Bad performance when running Underwriters Estimation Calculation Order

Running Underwriters Estimates Calculation Order with option 'Recalculate Existing Adjusted Estimates' selected, does not recalculate all estimation items

Period Estimation Items which have a calculation rule retrieving amounts from the Adjusted Estimates are calculated when running Multi GAAP Accounting Order

Solution:

Rollback SC-4518 which is the source of the problem

Implement a new solution for SC-4518 (bad read performance of estimates in Estimate Condition)

Workaround:

Root Cause:

SC-4518

Extent of Impact:

Impact on Existing Data

Recovery Method for Existing Data Affected

Problem:
When creating Protection Program the base company specific classifications are not being displayed instead all values are shown

Solution:
Level Of Business: Protection Program
Operations:
a) Create New Protection Program
b) Update existing Protection Program
c) Renew Protection Program

When creating new / update existing / renew Protection Program, on page Classify the Business (or Edit Business Classficaitions), the system must display only those Main Class Of Business, Class Of Business and Sub Class Of Business (if activated) that are available for the selected Base Company -> Details -> “MCOB/COB/SCOB business partner details”.

Declination Reason:

Workaround:
Manually select only the needed Main Class Of Business, Class Of Business and Sub Class Of Business (if in use)

Root Cause:

Extent of Impact:

Impact on Existing Data

Recovery Method for Existing Data Affected

Problem:
When protecting Non Prop OCC proportionally there is no indiation at the protecting Prop OCC that it is protecting a Non Prop OCC

Solution:
When System Parameter 'Proportional Protection Assignment on Non-Prop OCC in use' is activated, the AB condition (showing protected) Assumed Businesses must be extended with a new small container at the bottom of the GUI, to show the protected Non Prop OCCs.
If the system parameter is not selected; this container should not appear; it should be showing only protected assumed business, as in current solution.

System Parameter fix:
System parameter 'Proportional Protection Assignment on Non Prop OCC in use' is correctly located at Retrocession/General - but two dependent system parameters was incorrectly moved to Retrocession
&C Miscellaneous when implementing SE-8007 in SICS 21.3.
The following two System parameters must be moved back beneath 'Proportional Protection Assignment on Non Prop OCC in use:

• Retrocede Informational Entry Codes from Non Prop OCC
• Keep Sign from Non Prop OCC

Workaround:
Inspect As Original ledger / details for Prop OCC and find protected business/es in source details.

Root Cause:

Problem:
For Facultative and Direct assumed businesses (Proportional and Non-Proportional), on the Insured Period tab, 'Cease Accounting of Insured Period' checkbox field is not visible.

Solution:
For all Levels / Types of Business where Cease Accounting can be set, make sure all relevant fields are visible in both view and edit mode. Relevant fields are:

• Cease Accounting for Insured Period (tick box)
• Cease Description (text field)
• Last Updated By

Root Cause:

Extent of Impact:

Impact on Existing Data

Recovery Method for Existing Data Affected

Problem:
Some optional Claim Classifications are not reflected on the claim created through SICS Server

Solution:
Claim should be created with both optional and mandatory items as defined in SOAP

Workaround:

Root Cause:

Extent of Impact:

Impact on Existing Data

Recovery Method for Existing Data Affected

Problem:
System does not allow data of loss prior to Insured Period when Risks Attaching, CLean Cut and has Loss portfolio defined

Solution:
When business has a loss portfolio the system must accept claims prior to insured period, and within the Original Policy Period. The Original Policy Period can be prior to Insured Period, regardless of the clean cut provision.

Workaround:

Root Cause:

Extent of Impact:

Impact on Existing Data

Recovery Method for Existing Data Affected

Problem:
When expenses are either not defined or defined as none on proportional facultative business, the accuracy raises errors for loss reserves and expense reserves separately, instead of only raising the Loss reserve validation.

Solution:
On a Prop Fac business, when the claim condition is either defined or not defined, expenses and loss amounts are always considered as losses. Loss Expense reserves are positive for AC should not be triggered in this scenario - only Loss Reserves Positive validation should be triggered. (Both loss reserve and expense reserves must be added together)

On a Non-prop Fac business, if the claim condition is either not defined, or defined and expenses are none or part of liability, the expense amounts are validated together with loss amounts. The error  Loss Expense reserves are positive for AC should not be triggered in this scenario. Both Loss Reserves and Expense reserves must be added together in this case. If the expenses are defined as In Addition To, (or In addition Capped/Uncapped, Proportionate Stabilized) - the loss reserves and expense reserves must be validated separately,

Workaround:

Root Cause:

Extent of Impact:

Impact on Existing Data

Recovery Method for Existing Data Affected

Problem:
The system abends when accuracy validates claim bookings against limits, but these have been removed.

Solution:
For non proportional business the presence of limits are validated during the creation of the claim. However, if limits have been removed, and reinstatements are validated, AC0399 must be raised, referring to Reinstatement rule.

Workaround:

Root Cause:

Extent of Impact:

Impact on Existing Data

Recovery Method for Existing Data Affected

Problem:
When having combined Aggregate limit on main section, and reinstatement per insured period, the accuracy for reinstatement computed amount displays incorrect amount for both sections included in technical worksheet if these sections have same classification items

Solution:
The system must be able to consider sections when calculating the computed amount.

Workaround:

Root Cause:

Extent of Impact:

Impact on Existing Data

Recovery Method for Existing Data Affected

Problem:
Very poor performance when opening FGU due to calculations taking place when opening window.

Solution:
Remove correction made by SICSC-323, the main purpose was to check if FGU has adjustments in order to enable popup options to create FGU worksheet.. FGU can be displayed in 100% or in ourshare. The adjustment shall be based on ourshare regardless how FGU is displayed. The adjustment here is non zero adjustment for all possible types of bookings. Rewrite the method which calculates the adjustments (in 100% or in ourshare) such that it can be called for both creation of FGU worksheet and enabling/disabling popup options.

Workaround:

Root Cause:
SICSC-323

Extent of Impact:

Impact on Existing Data

Recovery Method for Existing Data Affected

Problem:
Abend when validating claim worksheet on proportional business which contains bookings in currency not defined on business where limits have not been defined

Solution:
When validating claim worksheet (in any currency) the system must first validate the presence of limits - if they are not present, the system should raise AC0399.

Workaround:

Root Cause:

Extent of Impact:

Impact on Existing Data

Recovery Method for Existing Data Affected

Problem:
Accuracy error Loss Expense Reserves are positive for AC is raised on all entry codes in the worksheet, rather than Loss Expense Reserve entry code only.

Solution:
Accuracy error must be raised on relevant entry code only, when this is present in the worksheet

Workaround:

Root Cause:

Extent of Impact:

Impact on Existing Data

Recovery Method for Existing Data Affected

Problem:
Accuracy error for positive expense reserve is raised on a non-proportional treaty when expenses are none, and claim is created on main section.

Solution:
On non-proportional treaty business accuracy error positive expense reserve should not be raised if expenses are defined as none, or part of liability, regardless of whether claim is created on main or child section. It should be raised in all other circumstances, also when condition is not defined.

Workaround:

Root Cause:

Extent of Impact:

Impact on Existing Data

Recovery Method for Existing Data Affected

Problem:
When processing a claim movement which is booking annuity, the worksheet generated from FGU does not reflect correct annuity split for reserves if message annuity reserve new is zero, and loss reserves are increased accordingly.

Solution:
Expected is that the system should also consider the message amount for new res annuity, calculate the necessary adjustment to this, and then make necessary adjustments to the loss reserve amount so that total reserve adjustment equals the FGU reserve adjustment.

Workaround:

Root Cause:
SE-1976 and SE-6774
Extent of Impact:

Impact on Existing Data

Recovery Method for Existing Data Affected

Problem:
Abend when opening FGU when parameter include Client IBNR/Client IBNR LAE is activated due to BigDecimalZERO in code

Solution:
The method must be replaced with compareTo method

Workaround:

Root Cause:

Extent of Impact:

Impact on Existing Data

Recovery Method for Existing Data Affected

Problem:
When reversing a claim worksheet with emessaging origin the 'affect in FGU' indicator is not set despite source worksheet having indicator set

Solution:
When reversing a worksheet always set the affect FGU distribution.

Workaround:

Root Cause:

Extent of Impact:

Impact on Existing Data

Recovery Method for Existing Data Affected

Problem:
It is possible to generate claim balances for a provisional business partner when this partner is added to the claim directly, and balance partner is modified in the booking.

Solution:
Introduce validation that partners added to a claim in Links - Business Partners - are not provisional - similar to validation error BS0231.

Workaround:

Root Cause:

Extent of Impact:

Impact on Existing Data

Recovery Method for Existing Data Affected

Problem:
CM triggers error for previously booked Target EC without update

Solution:
1. When the user applies a claim worksheets to the database and the system raises the message AC0167, asking the user “Do you want the system to generate bookings for the entry codes with no Adjustment?”, and the user replies No to this question, we must make sure the system removes ALL details with zero adjustments including government tax target details.
2. If the system parameter 'Remove entry codes without adjustments' is ON then the question in message AC0167 does not appear, instead the system removes the adjustments with zero amounts automatically when claim worksheets are applied to the database, and also here we must make sure the system removes also the government tax target details with zero adjustment amounts.
3. When a Claim or Technical Worksheet is applied to the database and validated, and the system finds a government tax target entry code without a relevant trigger entry code, the message AC0835 appears correctly, but if the target detail amount is zero, and the trigger entry code is missing, then the message AC0835 must be suppressed and not presented to the user.

Workaround:

Root Cause:

Extent of Impact:

Impact on Existing Data

Recovery Method for Existing Data Affected

Problem:

When calculating inuring amounts in steps 3 and 4 the system does not check if the variable is null, which is causing the abend.

Solution:

Change method applied, so that when returned variable is null return 0.

Workaround:

Define inuring cover and excess as zero

Root Cause:

Extent of Impact:

Impact on Existing Data

Recovery Method for Existing Data Affected

Problem:

Abend when opening FGU - related to calculation of split percentages between currencies - when an informational client ibnr amount has been recorded.

Solution:

The system should not calculate the limits for Incurred with Client IBNR when the parameter 'Include Client IBNR/LAE in worksheet' is not activated.

Workaround:

Activate the the parameter

Root Cause:

Extent of Impact:

Impact on Existing Data

Recovery Method for Existing Data Affected

Problem:
We have come across an issue where when processing con and cor messages on non-prop messaging is causing SICS to not cooperate. Usually the system would be clever enough to realise that the messages net down to a nil value as they are just in and out values therefore no financial impact. But we have noticed that this is no longer the case and are having to do some major fixes as its just won’t work.

For example IAB1051147 this deal had 30 messages that netted down to nil and as you can see from the P/L screen prior to booking the messages this was all booked fine.
So now this has left 57k un booked which should not be the case as like I said the financial impact was 0. Somewhere along the lines of this processing in the background it just can not cope and throws it all out.

Solution:
When reversing a single Instalment or Adjustment then
provided that the reversal message has located the original message and that original message can be identified on one or more instalment bookings for the referenced instalment by eMEssage UUID, Sender BP Reference or LM Reference
then from the instalment bookings valid for reversal select only those referred to the original message to reverse, leaving other bookings on the instalment as-is. In this case the origin of the worksheet will be eMessaging (rather than Automatic).

Otherwise reverse all bookings on the instalment per the instalment as before.

Workaround:

Root Cause:

Extent of Impact:
Mismatch between granularity of messages being sent for a contract and the instalments / sections on a contract.
Receiving multiple payments for a single contract and then later reversing the multiple messages and rebooking.

Impact on Existing Data

Recovery Method for Existing Data Affected

Problem:
When booking Lloyd's Treaty Statement messages with Claim Bookings on Prop Treaty with transfer to ledger having multiple worksheets / payments in a single TechAccount then
eMessaging is not correctly setting the expected payment amounts when adding an expected payment to a referenced existing worksheet.

Solution:
When adding an expected payment to a pre-existing worksheet then the expected payment amounts should be set correctly as per when creating a new worksheet by applying the exchange rate to the original balance amount.

Workaround:

Root Cause:

Extent of Impact:
Lloyd's Treaty Statement messages with Claim Bookings on Prop Treaty with transfer to ledger having multiple worksheets / payments in a single TechAccount

Impact on Existing Data
Expected Payment amount is not correctly set for each individual balance based on the exchange rate and original balance amount

Recovery Method for Existing Data Affected

Problem:
Lloyds FA - Not settling CM and TA messages when the TA is a normal Reversal message because the due date of the reversal booking is not being set from the message (although the LM Reference is being correctly set.
This results in no automatic pairing because while the LM References match the due dates probably will not.

Solution:
As per other scenarios, for London Market Service Provider messages, when creating an automatic reversal worksheet ensure that when the LM Reference is updated on the balance from the eMessage that the Due Date is also updated on the balance from the eMessage.

Workaround:

Root Cause:
Missing update of Due Date on Reversal for London Market messages.

Extent of Impact:
London Market automatic booking of reversal messages.

Impact on Existing Data

Recovery Method for Existing Data Affected

Problem:
Claim limits are not using the latest list of limits resulting in accuracy error

Solution:
Correct any methods which are being used that are ignoring the transient latest claim share limit record that has just been created.

Workaround:

Root Cause:

Extent of Impact:

Impact on Existing Data

Recovery Method for Existing Data Affected

Problem:
CL Response not registered on worksheet

Solution:
Ensure that the Claim Response updates the worksheet

Workaround:

Root Cause:

Extent of Impact:

Impact on Existing Data

Recovery Method for Existing Data Affected

Problem:
There is no link to a referred message. When this message was processed, there was nothing to trigger the reprocessing of the circulation message.

So the question is why do some response messages have a link to the circulation messages, and others do not?

Solution:
Ensure that once a Linked CM Circulation message is established for a response that the link is maintained when setting the insured period on the Response from the Circulation message.

Workaround:
Reprocess the Circulation message to complete it,

Root Cause:
Response messages can get their Insured Period set from the Linked CM via the ClaimAdjustmentCMReferenceRule but if this happens the Linked CM is removed if the same Insured Period was not already referenced. If the Response is directly processed without any re-validation then there is no Link to a CM for reprocessing.

Extent of Impact:
LIRMA Response messages being directly Processed in one go (after referencing IP via ClaimAdjustmentCMReferenceRule) not reprocessing the Circulation CM.

CM messages with Closed Worksheets left in status Waiting

SELECT cm.UUID
FROM EMES_MSG cm
JOIN AC_WORKSHEET w on cm.SUBCLASS = 12 AND cm.FRK_STATUS = 'WAITING' AND w.OBJECT_ID = cm.FK_REF_WORKSHEET
WHERE
w.FRK_STATUS = 'C'

Impact on Existing Data

Recovery Method for Existing Data Affected

Problem:
Various eMessaing objevts missing

*+SolutionNew objects added.
Workaround:

Root Cause:

Extent of Impact:

Impact on Existing Data

Recovery Method for Existing Data Affected

Problem:
GOV TAX - eMessaging Government Tax Tab not working as expected. When Government Tax validation errors are presented as problems there is nothing displayed in the Government Tax tab to Override.

Solution:
The Government Tax tab should show a row for each AC validation error in the problems tab and a row for each Government Tax Rule. The override should work on these rows and apply to the validations.

Workaround:

Root Cause:

Extent of Impact:

Impact on Existing Data

Recovery Method for Existing Data Affected

Problem:
System fails to raise accuracy validation Loss Expense Reserve Positive for Accounting Classification when expenses are in addition to capped, and user books positive expense reserves when swapping to worksheet

Solution:
If a ClaimMovement message has a created worksheet linked then Processing the message should trigger the worksheet validations.

Workaround:

Root Cause:

Extent of Impact:

Impact on Existing Data

Recovery Method for Existing Data Affected

Problem:
CheckForExistingBooking matching of message booking to previous bookings does not detect a duplicate booking if there are additional 0 adjustment bookings. It currently requires that all Entry Codes (and amounts) are matched between message and previous booking.

Solution:
The message is linked to a single balance but bookings for same claim section and currency may be on multiple balances on the worksheet.
Check all balances for bookings to match the message.
If there is an additional EC being booked on the worksheet then this should not cause a mismatch.

Workaround:

Root Cause:

Extent of Impact:

Impact on Existing Data

Recovery Method for Existing Data Affected

Problem:
With SICS 21.3, the attributes on the eMessage have been rearranged, which in general makes sense. However, I'm missing one attribute and have a problem if the message is not in full screen mode (for example to compare two messages on the same screen):
• 'Message Type' Attribute is missing

• If I look at a message that is not in full screen size (on a normal and not widescreen), most relevant information is not visible. It is crucial to see this information when comparing two different message on the same screen. See comparison between SICS Version 21.1 and 21.3

Solution:
Message Type and Status fields have been removed from TechAccount (only so far) as they are visible on the top bar.
Add a Sash bar to the lower parts of highlights windows for TechAccount, ClaimMovement, Placing and Settlement to allow resizing of left and right panels.

Workaround:

Root Cause:

Extent of Impact:

Impact on Existing Data

Recovery Method for Existing Data Affected

Problem:
What is supposed to happen to TA claim signing and TA RIP message if referenced CM message has detected duplicate booking and processes with status Informational?

CM msg: The system correctly detected existing booking, did not generate a new worksheet but updated CM msg reference to existing balance and processes with status 'Informational'
The related TA claim signing and TA RIP message remain in status 'Waiting'.
Ideally TA claim signing and TA RIP messages receive trigger from CM message and process automatically.

Solution:
When a CM goes to Informational due to duplicate booking (no new claim adjustment) then the linked balance is the connection to the already booked worksheet). This is not being picked up by the TA Claim Signing or TA Reinstatement messages and it should be.
Ensure the status and linked balance / worksheet is recognized by the TA claim associated messages and rules as if the CM had actually made the booking.

Workaround:

Root Cause:

Extent of Impact:

Impact on Existing Data

Recovery Method for Existing Data Affected

Problem:
Example L4's:
1) '3a0a75f8-aee1-4b87-bbab-1d5326932cd2'
2) '7f87a4a2-f1a5-49c2-8490-1ad786f05b40'

Bad date value has been found for those in the L4 xmls like:
<CreationDate>2021-06-01T11:54*Z*</CreationDate>

Solution:
Ensure the seconds are never used as 0.000 and thus always formatted correctly. If 0.000 then increment to 0.001

Workaround:

Root Cause:
There is a feature in the Java display method that converts the time now to a string which removes the seconds from a date if the seconds are 0.000. This results in the invalid date as the seconds are missing and required to be present. The 'Z' is the time zone.
The field should be e.g. <CreationDate>2021-08-16T18:26:00.000Z</CreationDate> rather than <CreationDate>2021-08-16T18:26Z</CreationDate>
There is a 1 in 60 000 chance of this occurring.

Extent of Impact:

Impact on Existing Data

Recovery Method for Existing Data Affected

Problem:
Claim_No_Amount messages - no longer creating CWS's automatically.

The business have been processing these types of messages since we went live with B2B 18 months ago and are reluctant to change the process that will affect 60% of all their messages.

Solution:
Messages that are flagged as claim_no_amounts - 'Claim transaction with update of non-financial information only' but contain amount items that can be mapped and booked should be treated in the same way as claim_amounts messages and automatically generate a worksheet if applicable.

There is no validation in place that such messages should only create 0 adjustments.

Workaround:

Root Cause:

Extent of Impact:

Impact on Existing Data

Recovery Method for Existing Data Affected

Problem:

The SICS Classloader is not loading package-info causing JAXB to not work because it is loading the XmlSchema annotation from package-info.

Solution:

Fix the classloader so that it also loads package-info.

Workaround:

Root Cause:

Caused by: javax.xml.bind.JAXBException: {http://webconnectivity.co.uk/}SessionToken is not a valid property on class uk.co.webconnectivity.GetMessage  at com.sun.xml.bind.v2.runtime.JAXBContextImpl.getElementPropertyAccessor(JAXBContextImpl.java:939) ~[jaxb-impl-2.3.3.jar:?] at com.sun.xml.ws.db.glassfish.JAXBRIContextWrapper.getElementPropertyAccessor(JAXBRIContextWrapper.java:91) ~[?:2.3.3] at com.sun.xml.ws.client.sei.BodyBuilder$DocLit.<init>(BodyBuilder.java:212) ~[?:2.3.3] at com.sun.xml.ws.client.sei.StubHandler.<init>(StubHandler.java:102) ~[?:2.3.3] at com.sun.xml.ws.db.DatabindingImpl.initStubHandlers(DatabindingImpl.java:132) ~[?:2.3.3] at com.sun.xml.ws.db.DatabindingImpl.<init>(DatabindingImpl.java:77) ~[?:2.3.3] at com.sun.xml.ws.db.DatabindingProviderImpl.create(DatabindingProviderImpl.java:44) ~[?:2.3.3] at com.sun.xml.ws.db.DatabindingProviderImpl.create(DatabindingProviderImpl.java:28) ~[?:2.3.3] at com.sun.xml.ws.db.DatabindingFactoryImpl.createRuntime(DatabindingFactoryImpl.java:90) ~[?:2.3.3] at com.sun.xml.ws.client.WSServiceDelegate.buildRuntimeModel(WSServiceDelegate.java:852) ~[?:2.3.3] at com.sun.xml.ws.client.WSServiceDelegate.createSEIPortInfo(WSServiceDelegate.java:869) ~[?:2.3.3] at com.sun.xml.ws.client.WSServiceDelegate.addSEI(WSServiceDelegate.java:832) ~[?:2.3.3] at com.sun.xml.ws.client.WSServiceDelegate.getPort(WSServiceDelegate.java:421) ~[?:2.3.3] at com.sun.xml.ws.client.WSServiceDelegate.getPort(WSServiceDelegate.java:390) ~[?:2.3.3] at com.sun.xml.ws.client.WSServiceDelegate.getPort(WSServiceDelegate.java:372) ~[?:2.3.3] at javax.xml.ws.Service.getPort(Service.java:139) ~[jakarta.xml.ws-api-2.3.3.jar:?] at uk.co.webconnectivity.Service.getServiceSoap(Service.java:78) ~[?:?] at com.csc.sics.web.connectivity.client.WebConnectivityGatewayClient.getWcMrService(WebConnectivityGatewayClient.java:39) ~[?:?] 

Extent of Impact:

Impact on Existing Data

Recovery Method for Existing Data Affected

Problem:
eMessaging Insured Period information Processing Option is changed with navigation to other IP on eMsg Info screen

Solution:
Navigation between Insured Periods should result in presenting the correct values for each Insured Period and not change any values.

Workaround:

Root Cause:

Extent of Impact:

Impact on Existing Data

Recovery Method for Existing Data Affected

Problem:
Clinet has IGC contracts but no way to determine in reporting. Suggest a user object call IGC Y/N
Solution:

New object IGN Y/N

Workaround:

Root Cause:

Extent of Impact:

Impact on Existing Data

Recovery Method for Existing Data Affected

Problem:
Exchange rate conversions for Base, Target on balance and detail level for FX Claim Date and Worksheet Closed Date
Solution:

New objects added

Workaround:

Root Cause:

Extent of Impact:

Impact on Existing Data

Recovery Method for Existing Data Affected

Problem: The LOV for Claim ID seems to have gone away and become inactive in the PC Main universe.

Solution: Go to SQL Server, PC Main SICS Universe 21.2. In the universe Go to Claim ID in the Claim Information. In the Object properties go to properties and the associate list of values should be checked.

Workaround:

Root Cause:

Extent of Impact:

Impact on Existing Data

Recovery Method for Existing Data Affected

Problem:
Universe objects for Notifiers missing. Client needs them to Go-Live for claims to pass the approval up the authority ladder.

Missing Objects are Notifier Name and Notifier Sent To. See Attached SICS Screenshot
Solution: Under the Claim Information section inside the universe, Notifier Name and Notifier Sent To should be present in SPC Main SICS 21.2 Universe and OPC Main SICS 21.2 Universe.

Workaround:

Root Cause:

Extent of Impact:

Impact on Existing Data

Recovery Method for Existing Data Affected

Problem: Some objects are placed wrongly in claim information in PC main SICS universe 21.2.

Solution: The objects that are placed wrongly in claim information folder should be placed under FGU folder.

Workaround:

Root Cause:

Extent of Impact:

Impact on Existing Data

Recovery Method for Existing Data Affected

Problem:
BOAC004 creation crash
Solution:

DIM table for entry code wring.

Workaround:

Root Cause:

Extent of Impact:

Impact on Existing Data

Recovery Method for Existing Data Affected

Problem:
Join issues in SQL Server Pc main universe

Solution:

Joins fixed

Workaround:

Root Cause:

Extent of Impact:

Impact on Existing Data

Recovery Method for Existing Data Affected

Problem:

In SPREF DATA SICS Universe, the object 'Calculation Rule' within GAAP System Parameters/Calculation Rule, does not return any data

Solution:

Make sure the object returns the calculation rule stored in SICS

Workaround:

Root Cause:

Extent of Impact:

Impact on Existing Data

Recovery Method for Existing Data Affected

Problem: While working on Hamilton and ACIM upgrade to 21.3, some problems with the way implementation of the unsettled amount for as at extraction.
The solution in 21.3 is not working as the prompt is not implemented into the join for balance and it totally missing in detail extraction.
Missing detail unsettled/settled options for main1,2,3 base1,2,3 and target1,2

Solution: The objects whose sql queries are wrong should be corrected and some objects needs to be added the location specified

Workaround:

Root Cause:

Extent of Impact:

Impact on Existing Data

Recovery Method for Existing Data Affected

Problem: Achmea have ORP businesses with sections. When looking at the relationship between inward, OCC and ORP businesses there is a join between OCC and ORP which is limiting the extraction to only include main section, i.e. hierarchy level 1.

Solution: AND SJ_REP_TBL_OP.HIERARCHY_LEVEL = 1” should be removed

Workaround:

Root Cause:

Extent of Impact:

Impact on Existing Data

Recovery Method for Existing Data Affected

Problem:
When working on a report for Achmea and Toa re Europe have stumbled across a derived table. When using the estimate currency and the (All) estimation objects the aggregate navigation is not working causing a mixture of (All) and (Latest) tables to be mixed up. We should adjust this to instead use the view we have created for this.

Solution: The V_BUS_PER_EST_UW_Derived table here should be changed to include the database view instead by adding the existing view V_BUS_PER_EST_UW to the universe structure.
After the database view and joins have been changed the Select part of the objects needs to be adjusted

Workaround:

Root Cause:

Extent of Impact:

Impact on Existing Data

Recovery Method for Existing Data Affected

Problem:
Domain Restriction Accounting Worksheet Claim Details for Threshold Amount does not work as expected

Solution:
The DR amount must be interpreted as a negated amount. 10k is the equivalent of -10k in worksheet. Bookings of amounts 'exceeding' the defined amount must be prevented. (eg -12k), whereas bookings of worksheet amounts 'less' than defined amount; eg -9k or +100k must be allowed.

Workaround:

Root Cause:

Extent of Impact:

Impact on Existing Data

Recovery Method for Existing Data Affected

Problem:
User without appropriate security access are able to create business partners with approved comleteness status.

Solution:
For users who are assigned Security Domain Restriction: 'Partners Create Business with Status, with e.g. Completeness Status 'Provisional' selected, when creating a new business partner and here selecting another Completeness Status e.g. Approved, the system should stop the user with the message BP0056 'You do not have access right for creating a partner with this status.

Workaround:

Root Cause:

Extent of Impact:

Impact on Existing Data

Recovery Method for Existing Data Affected

Problem:
SICS versions prior to 4.8.6 are using the 1.2.x versions of the log4j library that are unaffected by CVE-2021-44228 and CVE-2021-45046.
If you are using SICS version 4.8.5 or lower, there are no mitigation actions necessary for any SICS Desktop or SICS Server components.

SICS versions from 4.8.6 to 21.3 are using the 2.x versions of log4j and are affected by CVE-2021-44228 and CVE-2021-45046.
The best mitigation strategy is to upgrade log4j to version 2.16.0 on all SICS components using the 2.x version of log4j.

Solution:
Replace these 5 files with the 2.16.0 versions:

• log4j-1.2-api
• log4j-api
• log4j-core
• log4j-slf4j-impl
• log4j-jul

Workaround:

Upgrade log4j to version 2.16.0 on all SICS components using the 2.x version of log4j.

Problem:
When sending a Web Service Business update to edit Deduction Condition with BS00269 answerNo (confirm edit when bookings exist) then
SICS Server - error message is a Generic Cancel / Rollback without specific details and as such does not indicate the specific problem.

Solution:

Assumptions:

• System Parameter 'Accounting - Validation Rules - Raise Warning Message when Business Condition is changed and Booking exists' is activated.
• Bookings exist on business.

In this case, when sending a SOAP message to update a condition, e.g. Deduction Condition, and the message includes the message response <answerNo>BS00269</answerNo>, the system should not update the condition and the response should be a standard response for executed message.

Workaround:

Root Cause:

Extent of Impact:

Impact on Existing Data

Recovery Method for Existing Data Affected

Verifier Name & Date:

Pawan Rajoriya, 14/10/2021

DB/Environment/Version/Build/Userid/Password used:

SRV_TEST_PC / SRV_TEST_PC / 3V

Reported Error:

Verification Steps ( How to recreate the error):

• Setup Swanlake server on SRV_TEST_PC / SRV_TEST_PC / 3V
• Open link http://localhost:8989/SwanLake/SwanLakeManagementConsole (after updating port number) on any browser
• It is not showing pool related detailed information about Sytem1, System2 and System3 on Management Console

IMPORTANT Observations:

The root cause seems to be related to Axis upgrade in 4.9.5 in case 'SE-896 Upgrade to Apache Axis2'.
In this upgrade soapenc:arrayType has been removed, due to which code changes done in SC-1903 specific to Axis is not working after 4.9.5.
So sics.status.js script need to be updated and tested accordingly

Problem:
SICS Server is not throwing error message even though correctly stopped from changing amendment From Date by web service when linked premium and limits exist

Solution:
When executing web service updateAmendment, system should check if Amendment “From Date” is locked for edit due to already linked business conditions (like it currently does in SICS online where field Amendment “From Date” gets locked for Edit when Share Condition and/or Limit and Premium Condition are linked to Amendment)
If that is, then system should return a new validation message “Amendment “From Date” is not allowed for edit due to linked conditions.” and stop the process.
This new validation message must apply only for SICS Server (web services) and is not needed in SICS Workstation.

In case business conditions 'Share Condition' and/or 'Limit and Premium Condition' are NOT linked to the Amendment, then it still should be possible to update Amendment “From Date” via web service updateAmendment using the current system behaviour.

Declination Reason:

Workaround:

Root Cause:
Old code

Extent of Impact:

Impact on Existing Data

Recovery Method for Existing Data Affected

Problem:

Unable to close worksheet via Web Service, because  'IS_BASED_ON_EC_LIQUIDITY' in DB table AC_BAL_GRP_PARM has a null value. 

Solution:

Make sure 'IS_BASED_ON_EC_LIQUIDITY' is always set to 'N' (false), unless specifically set to 'Y' by the Multi GAAP Accounting or Multi GAAP Retrocession Order

Workaround:

Root Cause:

Extent of Impact:

Impact on Existing Data

Recovery Method for Existing Data Affected

Problem:
China Re reports one abend when they call web service createAccountingOrder via Java API client. They code in Java with the API client jar, build the Java request object and call the web service createAccountingOrder, then get an abend. Please find the walkback as attachment: Administrator.038.walkback.zip .

I have discussed with Mads Johannessen about this issue. There is one error in the SOAP:
<levelOfBusinessList xmlns:ns3='http://www.SicsNt.com/ReferenceItems' xsi:type='ns3:SicsReferenceDataReference'>
The xsi:type here seems to be incorrect. It should be the type for levelOfBusinessList. Actually if we remove the xsi:type from here, there is no abend.

Please raise it for fix if we can confirm it is a bug. Thanks.

Declination Reason:

Workaround:

Root Cause:

Extent of Impact:

Impact on Existing Data

Recovery Method for Existing Data Affected

Problem:
Swiss Re has a need to create declarations and claims through ADH.
For this they will use the new 'External' Output Pattern that was implemented and delivered in SICS 21.3.
Harald has already provided files for creating a declaration (see comments and attachments below).
What remains, is to do the same for creating a claim.
NOTE: This is a customer support request, not a bug or enhancement.

Solution:
Provide,

• a simple input file with data for creating a simple claim
• an External OP with some output fields and corresponding XSLT, enough to create a simple claim
• a mapping using the input data and the OP; dead simple, just passing the data through from input to output
• the SOAP output that is generated from the mapping and the OP, and which in our internal test case is sent to our internal API Server at http://cscsvrosl024v.no.emea.csc.com:8082/SwanLake_SICS4PC/SicsWSServlet

Problem:
Find Person is not working properly when searching based on names (Last, First or Middle) or Title. Pressing ‘New Search’ is not clearing the entered criteria

Solution:
‘Find: Person’ screen must consider entered search criteria when searching based on names (Last, First or Middle) or Title and must return correct results, just like it correctly worked in SICS 21.1.
Furthermore, pressing ‘New Search’ must clear all entered search criteria (if any) on ‘Find: Person’ screen

Declination Reason:

Workaround:
Can additionally restrict returned results via pop-up option ‘Generic Find in Name’

Root Cause:
SE-6454

Extent of Impact:

Impact on Existing Data

Recovery Method for Existing Data Affected

Problem:
Removal of areas does not work if additional coverage and/or method reference data is added at the same time. This is not a bug as List must be used. However using includedRefDataList results in an abend

Solution:
It should be possible to use both AreaList and includedRefDataList etc. in the same classification update.

Workaround:

Root Cause:

Extent of Impact:

Impact on Existing Data

Recovery Method for Existing Data Affected

Problem:
MG Retrocession order on OCC with sections and estimates both on main section and sections gives incorrect error message.

Solution:
Give error message only when applicable.

Workaround:

Root Cause:

Extent of Impact:

Impact on Existing Data

Recovery Method for Existing Data Affected

Problem:

Solution:
Business Partner / tab Details / Bank Accounts
When in Edit mode changing Bank via type ahead functionality on existing Bank Account – the system must not abend.
Instead, the system should allow user to find, select and save the new Bank and fill in the Bank container without any abend.

Workaround:
For the bank field use the magnifying glass instead of entering the bank name/identifier (so avoid the type ahead functionality)

Root Cause:
SE-5039

Extent of Impact:

Impact on Existing Data

Recovery Method for Existing Data Affected

EastAfricaRe getting abend when firing CloseClaimWorksheet webservice.

Walkback attached. 'LOCAL SERVICE.006.walkback.zip'
SOAP Attached 'SOAP.txt'

class com.sun.proxy.$Proxy251 cannot be cast to class com.csc.sics.jac.webservicesint.AuxiliaryAccountingAccountingWorksheetCreateAndCloseWSI (com.sun.proxy.$Proxy251 and com.csc.sics.jac.webservicesint.AuxiliaryAccountingAccountingWorksheetCreateAndCloseWSI are in unnamed module of loader org.apache.catalina.loader.ParallelWebappClassLoader @60009664)

Aim of function

1：In the 'Select Open Worksheet' screen, you can see a new column with 'BP Reference'.
If the worksheet contains of only one balance, the BP Reference, if any, is shown by default. If the worksheet contains more than one balance, the user needs to right click on the worksheet with a balance where no BP Ref is shown and if the option View BP References is enabled this can be selected to see the different references on the various balances.

2: In the 'Business Ledger' screen, add new column 'Worksheet Title' in the balance table and details table.

System Parameters Affected

N/A

Existing functionality affected

1: Select Open Worksheet window from business or business ledger
2: View worksheet's balance and details on the business ledger

Aim of function

This enhancement will enable the user the to mark the business/insured period on a sanction watchlist and to warn the user about this when booking takes place on that specific insured period. The aim is to ensure thorough verification of the business/insured period is done on the basis of information available and in co-ordination with the Legal Risk & Compliance team prior to any booking or Payment being processed in SICS.

System Parameters Affected

No

Existing functionality affected

Manual booking on the Actual tab of Technical worksheet and Booking on Claim worksheet. Also booking done through e-messaging.