Release documentation - Life - Enhancements and requests

Problem:
Copy Worksheet does not get populated original WS ID on all Balances in column Notes

Solution:
When a worksheet is created by the Copy function and each balance on the new worksheet gets a Note filled in with the source worksheet Id, the system must keep this Note on each balance, even if some of the balances are regrouped or recreated.

Workaround:

Root Cause:
SICSR-21397 in version 21.2

Problem:

Walkback on Retro Estimation Calculation Order

Solution:

The Retrocession Estimation Calculation Order should not abend. Exclude the Retrocession Estimation Orders from the solution as implemented in SE-8093. The solution on SE-8093 should be applicable only to the Retrocession Calculation Order as intended

Problem:

Abend after clicking on Retrocession Accounting Run Due Orders - Life

Solution:

On clicking the Retrocession Accounting Run Due Orders from the Periodic Functions the system should not abend. 
The P&C orders should not be listed in the Life system and vice versa when accessed on a combined database
On clicking Run Now the selected orders should be run

Problem:

Not able to get the primary life& First death data into the report.

Solution:

For the above Joint Life fields, i.e.., Primary Life and First Death only FN and LN are defined. After adding FULLN also at the universe level we are getting the data for both the objects. 

Attaching all the respective screenshots for the reference in this case. 

Problem:

Allianz AG facing Restriction :: XSD restrictions with UserDefinedStringField.setUserDefinedStringField() method
While assigning values to user defined fields screenshot added for reference

Solution:

Need to fix the User Defined fields NAME XSD
It can be seen that this is 30 long in SicsUserDefinedFieldsClass.getInstance().lengthOfStringFields(). Need to increase the length of string by calling the method 'lengthOfStringFields()'.

Problem:

The Objects 'Sum At Risk_Latest' and 'Cession Class of Business' are not present in the Universe.

Solution:

The objects needs to be added in the Universe

Problem:

SICS is corrupting the Arabic data after creating cession through loader

Solution:

Data in any language other than English (a language that is supported in SICS) should be accepted and updated irrespective of what format of input file is used for the cession and claim loading

The created cessions and claims should have the data in the language of the uploaded file

When the reject file is created, the reject file should also have the data in the language of the input file

This is applicable for all formats that is supported for cession loader- delimited txt files, database upload and spreadsheet

Problem:
SICS abends while processing daily file

Solution:

For all types of input file formats : csv, txt xlsx process all the records in the input file when setting the data type

Do not set the data data type based on only the first 500 records

When the reject file is created use the same data type as the input file when creating the reject file and reuploading the reject file

Problem:

Duplicate IO is getting created when we load multiple records on same life due to case sensitivity of life names

Solution:

 Life id should never be case sensitive. When a unique life identifier is present or has been created by the batch then when the next record is being referenced and it has the same unique id in any case, the case should be ignored and if the id already exists a new IO should never be created

If there are two IOs with the same unique identifier and the alternative names and id field is edited and saved without making any change, the existing life id should be referenced and the validation error that the id already exists should be thrown

When editing an existing IO and trying to add a unique identifier that already exists on another IO the validation error should be thrown and it should not be possible to add an IO with a duplicate unique identifier

Here the duplicate check should be a combination of ID type+ ID. If the ID alone is duplicated and it is a different ID type, then the identifier should not be considered as a duplicate

eg: Social Security Number 123 and State ID 123 will not be considered duplicates

Problem:

On the Inward Cession, Transaction age is incorrectly calculated on a renewal transaction.

Solution:

 Transaction age for any transaction should be calculated based on the Date of birth and the transaction effective date and be calculated using the defined Age basis on the respective PM condition on the section to which the cession is linked to

This is applicable to all types of transactions and all levels of cessions (inward, retro, placement )

Problem:

System is not validating life id while loading a batch with existing policy number with different insurance product and life id

Solution:

When the loader tries to reference a cession or a cession benefit on a single life and the business id and the policy number is the same, but the life id is different then irrespective of the transaction the record should fail with a message 'Life id <life id> does not exist on policy number/ cedent cession number <policy number/ cedent cession number>

There should never be a cession where different benefits have different insurable objects attached

However if the cession is a joint life cession it should be possible to create different benefits on the same cession for the lives within the same joint life insurable object

Problem:

Retrocessions are getting displayed on reinstatement transaction instead of Lapse when we run one RPO for both the transaction

Solution:

When there is both a lapse and a reinstatement that is to be picked up by the RPO update the retrocession window on the inward cession with the details of the lapse in the corresponding lapse transaction. The full recapture transaction of the retrocession should be listed in this Lapse window and the ceded factor on the window should be 0 and the status should be inactive

Problem:

Ceded percentage is getting calculated in an inward cession when there is no retrocession linked to that cession

Solution:

The ceded factor should always be calculated based on the Total Retro Sum at Risk/ Sum at Risk
This should be calculated only when there is a Retro Sum at Risk calculated. When the cession is fully retained the ceded percentage on the cession benefit should always be 0
Only when the ceded percentage field is manually overridden or entered at the time of creating the cession there should be a value in that field when there are no retrocessions attached.

Problem:

Net Sum Retained and Retroceded amounts are calculated incorrectly when we increase or Decrease SAR in subsequent transactions

Solution:

When the system parameter Sum at Risk standalone retrocession only is NOT selected:

When the SAR decrement basis is selected as Proportional on the SR condition:

Always apply the same retro factor to the Sum at Risk when processing the retrocessions and calculating the Retro Sum at Risk
For all the retrocessions linked to the cession the decreased SAR should be calculated using the same percentage that was used to calculate the retro factor in the new business transaction and the retro SAR should be proportionally decreased

The retro SAR should reflect on the retrocession level and the on placement levels using the retrocessionaire percentage.

Problem:
When an ‘Increase’ in SAR is performed with ‘OTHER’ transaction through loader then system is not considering Increased SAR
Solution:

On an Other transaction the cession benefit transaction the Sum at Risk field on the transaction should be created with the value mapped to the Initial Sum at Risk field in the mapping. If the Initial Sum at Risk field is not explicitly mapped, then the value from the Ceded Sum Assured field should be defaulted to the Sum at Risk field

Problem:
Incorrect retention and retroceded amount calculated for Lapse and reinstatement transaction

Solution:

Irrespective of whether the SAR calc rule is set or not
When the lapse transaction has been created in a period where there is no active transaction then there should be no recalculation of the sum to be retroceded. The lapse should create a corresponding full recapture transaction on the outward cession,

When the lapse is created in an active transaction period then the full recapture should be created and the retrocession information should be updated based on the transaction within which the lapse falls in.

When any transaction is reinstated the retrocession information should be copied from the corresponding termination transaction.

Problem:
Expiry age is not updating for reinstatement transaction.

Solution:

Copy all fields from the termination transaction to the transaction that is being reinstated. This should not impact any calculations.

Problem:

Incorrect validation of Limits due to referencing to an LUT that was part of the source business on a copied business

Solution: 

For Surplus business :

On a Surplus Assumed Business or OCC:

When the Limits are edited from a Table and defined as Amounts then all references and links to the LUT should be removed
This is applicable when
a) The business was copied from a source business that had the limits defined as a table and the Limits were then changed to Amounts
b) The section was inherited from a parent that had a table and the child section was then overridden and only the section's LUT was edited to Amounts
c) The condition was initially saved with a LUT and then later edited or amended to an Amounts value

On the Surplus OCC this is applicable to Retention, Underlying Top Limits, Autocover Limit and Jumbo Limit

When the LUT is delinked from all the sections on the business then the Relationships tab on the LUT should be updated accordingly and the business should not appear in the relationships.

Problem:

System abends when we try to open Non - Propositional claims
Solution:

 Non Proportional Claims- both inward and outward should open without an abend
None of the changes done for proportional claims regarding expenses or claim statuses should apply to non proportional claims
Ceded status is not applicable for a non proportional claim.

Problem:

System abends when we try to create a cession with out Life Id type through loader
Solution:

 Irrespective of whether the life id type is marked as mandatory or not in the output pattern all mandatory fields required for creating a cession should be validated
The system should not abend- instead the error message '<field name> is mandatory should be thrown.

Problem:

Reverse transactions are getting created automatically on retrocessions when a termination transaction is performed with in the renewal transaction effective period on inward cession but not on the placements

Solution:

When a reversal transaction is done on a later amendments on the inward cession due to a termination that is backdated then the reversal transactions should be made on the retrocession cession and placement cessions without the RPO being run
Once the RPO is run the full recapture should be created for the termination transaction on the corresponding retrocession transaction
When the termination is reinstated on the inward cession then the full recapture should be reinstated on the retrocession

Problem:

On Refreshing the System, the ACI of Inward Cession is getting removed, when the Retro's are created with the Calculation Rule on the OCC.  

Solution: 

The RPO should never make any changes to the inward cession
Only when the SAR calculation rule is present, the SAR field should be updated with the calculated value. However this should never result in a recalculation or removal of already calculated/ entered ACIs on the inward cession.

Problem:

Unique ID for all type Lifes-  IS_CEDED_POLICY is used to get the status as Y/N and to perform the currency conversions remaining objects need to be created. 

Solution:

 IS_CEDED_POLICY, SAR Net Sum Retained (Target), Sum At Risk Reins/Retro_LATEST(Target), Sum At Risk_Latest, Cession Class Of Business are the objects need to be created at Life Universe. 

Problem:

System abend while saving cession when there are additional classifications in the QS LUT

Solution:

When the Quota Share LUT has a parameter which is an additional classification or user defined value on the LUT allowable columns and the policy HAS a Ceded Flag:

Use the additional classification value in the cession classifications to validate the limits.
If the classification is not available then the cession should fail with the existing LUT validation message 'No value found for <missing parameter>'

When there is an additional classification or user defined value in the Limits table and the policy DOES NOT have the ceded flag:
Force the user to select the value as part of a qualifier. If the value is not selected then fail the cession with the existing validation message 'Missing qualifier'

In the table attached the parameter is additional classifaction 00265 and hence it should either be a qualifier (non ceded) or in the cession classifications (ceded) for the validations to happen.

Problem:

RCPO is not calculating Expenses on Retro claims if expenses Payment due date is later that RCPO payment due date

Solution:

Only for claims that have a status of Paid, In Payment or Special Paid (claims linked to a cession that does not have the ceded flag)
Do not check the payment due date on the expenses while picking up the Expenses ACIs
If the payment due date on the Decision Liability tab is within the Period End date on the RCPO then pick up all the ACIs on the claim including the Expenses ACIs even if the Expense ACI payment due date is outside the Period End Date

Create the Retro claim with the Payment Due date of the expenses = the Expenses ACI payment due date of the inward claim expenses.

Problem:

System is not showing the correct ceded Factor on the Retrocession window and SAR is changing after opening the Retrocession window, when Retros are created with OCC having calculation rule.

Solution:

Always display the ceded factor based on the transaction from which it is being viewed
Once the user clicks on a particular transaction and navigates to the retrocessions from the retrocessions icon then all the details displayed in the window should show the retrocession details of the corresponding transaction only.

When navigating back and forth within the retrocession window the ceded factor and the other details should reflect based on the the corresponding inward cession transaction.

The above will not be applicable when the retrocession basis is proportional in excess of retention (since each inward transaction may always not have a corresponding retro).

Problem:

 Loading details and Deductible got updated on Reinstatement transaction on Inward cession

Solution:

When a reinstatement transaction is done the reinstatement should ONLY reinstate the details present on the termination transaction that is being reinstated. Any other values that are mapped should be ignored when done through the loader and on a manual cession it should not be possible to update any fields on the reinstatement transaction.

The reinstatement on the inward cession should automatically reinstate the corresponding termination on the retro and no additional values should reflect on the retrocession cession and placements.

Problem:

After Decreasing SAR on Inward cession having fac retros, in subsequent transactions the fac retros are updating with incorrect Retro SAR.

Solution:

If there is no change in the SAR on the inward cession then the fac retrocession details in the Retrocession tab should remain the same as it was on the previous transaction.

Problem:

System abends when we click on any benefit on standalone individual retrocession after performing termination from individual cession window or create a reinstatement.

Solution:

When a termination is done from the main cession level (not benefit level) on all benefits then all the future transactions that are active after the termination transaction should be inactivated on the main cession level (similar to the cession benefit level.

Once a termination is done from the cession level it should also be possible to reinstate and open the benefits from the cession level without an abend.
 

Problem:

Transaction number is not updating automatically when amendments are created from Individual cession window.

Solution:

When the system parameter 'Allow transaction number on cessions and claims' is selected then all transactions that are created from the cession level should also get the transaction number similar to the cession benefit level transactions when the renewals are performed on the cession level.

The same should also happen when the renewals are created through the cession renewal order since this order creates the renewals on cession level.

Problem:

Full recapture transaction is creating with incorrect transaction effective date after running RPO for backdated termination transactions other than lapse.

Solution:

For all types of termination transactions the timestamp of the termination transaction should be set as the effective date of the entered/ mapped termination transaction and the time as 23:59:59 of the termination effective date.

For all types of termination transactions the timestamp of the termination transaction should be set as the effective date of the entered/ mapped termination transaction and the time as 23:59:59 of the termination effective date.

When the system parameter 'Method of Retrocession is Reinsured Sequentially in excess of retention' is selected,
The date of termination of the retrocessions should be equal to the date of termination of the inward cession transaction,

When the system parameter ''Method of Retrocession is Reinsured Proportionally in excess of retention' is selected,
The date of termination of the retrocessions should be equal to the effective date of the RPO,

Problem:

Refresh issue-When full unplaced share is placed with Facultative on Other Transaction system gives validation and does not allow to proceed further.

Solution:

For any type of active transaction if there is a value in the field 'Remaining Unplaced Amount' it should be possible to create one or more Facultative retrocessions upto the value of the amount in the Remaining Unplaced Amount field without having to refresh the system.

Problem:

New claim status is updating on retro claim when RCPO has not ran for that new status.

Solution:

 When the system parameter 'Sum at Risk Standalone Retrocessions Only' is selected :
The claim status on the retro claim for any transaction where there is a Payment Due Date and ACIs applicable should only be updated when the RCPO is run.
This is applicable to In Payment, Update Claim Reserve, Special Paid and Ceased.

Problem:

Incorrect amendment number is updating on Facultative retrocessions for subsequent transactions.

Solution:

The amendment number on the Fac Retro should follow the amendment sequence of the Fac Retrocession and not be copied from the inward. Irrespective of which transaction of the inward is linked to the Fac Retrocession, the first Fac Retro transaction should be New Business - Amendment 0 and the subsequent transactions should follow the sequence from the new business amendment.

However when the transaction number is in use, the transaction number of the Fac Retrocession should copy the linked inward transaction's transaction number.

Problem: 

RPO not calculating correct SAR Net Sum Retained and Total Sum Retroceded when 2 policies on same life are retroceded to 2 different PP's/OCC's.

Solution:

Only when the system parameter 'Method of Reinsurance is reinsured Sequentially in excess of Retention' is selected:

Total retention per life, per benefit should be considered across all PPs that have the same base company.
The Insurance Product should not be considered for accumulation.

If the benefit covered for the life has already been retained by one PP/ OCC then this retention should be considered as already utilised and when another policy for the same life, same benefit covered is picked up by another PP/ OCC the previous retention should be factored even if the life has not been reinsured through this PP/ OCC.

Problem:

System is throwing a wrong Message and not allowing to create a Faculatative Retrocession on a Cession with Unplaced Amount. 

Solution:

For any type of active transaction if there is a value in the field 'Remaining Unplaced Amount' it should be possible to create one or more Facultative retrocessions upto the value of the amount in the Remaining Unplaced Amount field.
This is applicable when the Unplaced Amount is created due to an increase/ decrease in the SAR due to a direct calculation or a SAR decrement/ rule recalculation.
This is applicable for both ceded and non ceded cessions.

Problem:

On Running RPO, SAR is wrongly calculated for the Transaction which falls outside the attached LUT on the Calculation Rule of OCC.

Solution: 

If the SAR calculation rule cannot be applied for any reason including the reason where the LUT which is part of the rule does not find the relevant parameters in the cessions:
Always fail the cession when running the RPO with the existing error message 'Unable to apply the SAR calculation rule'.

The SAR should not be calculated by skipping the rule and using the defaulted SAR or skipping only the LUT or just using any of the other values within the rule.

Problem:
Ceded Percentage Field is not visible for the Non Ceded Claim.

Solution: 

Only when the system parameter 'Sum at Risk Standalone Retrocessions Only' is selected:

When a claim is created on a cession that does not have a ceded flag also similar to the field available on the cession the ceded percentage field should be visible on the claim.

This field will have the value copied from the ceded percentage field of the cession benefit effective period to which the claim is linked.

This will be available on all statuses and can be editable on the statuses where ACIs are calculated - Paid, In Payment, Update Claim Reserve, Special Paid, Ceased.
When the RCPO is run the claim ACIs will be calculated based on the ceded percentage.
As part of this case we will not handle the calculations when the value is overridden if there is any discrepancy.

Problem:

SAR of Inward Cession is changing when we are validating the Claim Amount with a Calculation Rule Attached on the SR Condition of Inward Business.

Solution:

When the SAR calculation rule is applied when validating a claim (inward business, non ceded claim) the calculation rule should not reset the Sum at Risk on the inward cession in any scenario with or without a refresh.

Problem:

Coverage indicator is not updating on facultative retrocessions linked to inward cession.

Solution:

The Coverage Indicator (and all other details which are not calculated on the Fac Retrocession in all the tabs) from the inward cession should be copied to the linked Fac retrocession.

Problem:

Not allowed to create reinstatement transaction on inward cession for which Fac retrocessions are linked.

Solution:

When an inward cession benefit is terminated the linked facultative retrocession should also be automatically terminated with the same transaction.

Any retros created through the RPO should be terminated when the RPO is run to pick up the termination transaction of the inward benefit.

When the inward cession is reinstated then all the linked retros including the Fac retro should be automatically reinstated.

All details from the termination transaction should be reinstated and there should be no recalculation of any value including the ceded percentage.

Problem:

System abends when cessions are cancelled from partner tab of assumed business. 

Solution:

When an assumed business is terminated or cancelled with the option 'Existing Business Runs off' NOT selected then it should be possible to terminate and cancel the inward cessions linked to the business as on the date of recapture without abend.

In an environment where the system parameter ''Sum at Risk Standalone retrocessions only' system parameter is selected'.

The inward cessions may or may not have retrocessions attached- the cancellation/ termination should happen.
If there are retrocessions attached then the RPO should pick up the cancellation/ termination similar to any other type of termination.
No check for 'transfer to addenda periods' should be done when running the Cancel Cessions/ Terminate Cessions option through the order or from the business (Partners tab or Insured Period tab).

In an environment where the system parameter ''Sum at Risk Standalone retrocessions only' system parameter is NOT selected :

Once the inward cession is terminated the corresponding termination should happen on the linked retrocessions as on date of the inward cession termination.
No check for 'transfer to addenda periods' should be done when running the Cancel Cessions/ Terminate Cessions option through the order or from the business (Partners tab or Insured Period tab).

Problem:
Original Sum Insured field's value not getting populated for reinstatement transaction on Retrocession and Placement level Retrocession cessions.

Solution:

The value from the inward cession's Original Sum Insured field should be copied to the Retrocession cession and placement cessions when the RPO is run after a reinstatement and also to the Facultative retrocessions. The Reinstatement transaction should have the value populated from the corresponding Termination that has been reinstated.

Problem:

NB Basic commission not getting calculated from 2nd Month onward on Retrocession cession when renewal frequency is monthly.

Solution:

When the renewal frequency is not yearly or single and the initial commission basis is defined as divided across all periods in the first year then the initial commission should be considered as an annual value and then calculated for each renewal period in the first year based on the premium calculation frequency.

The same will apply to the Extra Commission also if the basis is same as Basic Commission or specifically selected with Divided Across all peridos in the first year for hte extra commissions.

Problem:

On the Retro Claim, the Notified Reinsurer Liability,  Claim Liability field, and ACI are calculating wrong amount, when a Calc. Rule is given on the SR condition of Inward Business.

Solution:

On a claim all details for the Notified Reinsurer Liability, Claim Liability field should be defaulted from the Benefit Sum Retroceded that has already been calculated using the SAR calculation rule.
The ACIs should be calculated by default using the ceded percentage and if the ceded percentage had been overridden on the inward claim then this ceded percentage should be used to calculate the ACIs using the amounts from the Decision Liability and Expenses tabs.
 

Problem:

The Ceded Percentage field is not updating correctly on the Inward cession, when the Cession is retroceded with a OCC having SAR decrement method. 

Solution:

 When the ceded percentage field on the cession is not explicitly overridden it should always be populated with the Ceded Factor.
This is the value that will be copied to the claim 'Ceded Percentage' field and used for the default recovery calculations.
This is applicable to both ceded and non ceded cessions irrespective of whether the retro SAR is calculated with a table or rule.

Problem:

The Ceded Percentage field is not updating correctly on the Inward cession, when the Cession is retroceded with a OCC having SAR decrement method. 

Solution:

Extend the Historical Claim function to non ceded claims also. Do not validate the Claim Event date when the Historical Claim flag is selected.

Problem:

Transaction number is not updating correctly when cessions are terminated from business and reinstatement transaction is created after backdated termination.

Solution:

When the cession benefits are cancelled / terminated from the business level the transaction number for the cancellation should be automatically created as the last used transaction number + 1. All the automatically created reversals of trasactions beyond the termination date should get the transaction number of the corresponding source transactions.

Problem:
All the ACI calculation on Retrocession cession for NB & Renewal transactions are correct. However, the ACI’s on Other transaction* for NB EX Mort Comm is incorrect.

Solution:

ACIs on commission for extra mortality premium (commissions on all extra premiums) should be calculated against the extra mortality premium that has been calculated for the period. When the transaction effective date is within another effective period then the pro rata premium for the exact number of days should be calculated and the commissions should be applied to the calculated premiums.

Problem:

Historical Claim Flag is not available on the Claim Detail Tab of Non Ceded Claim.

Solution:

For a claim that is linked to a cession where the ceded flag is not available:

Open up the flag historical claim.

When this flag is selected do not validate the claim event date to be within the cession active period.
The flag should be available for selection on manual and loader for all claim transactions when the claim is created the first time.

When an existing claim is referenced for change of status, this flag should be ignored and whether it is selected or not, the initial selection on the first claim status should continue.
 

Problem:

Net sum retained is calculated with negative sign and new retrocession ID is getting created for subsequent transactions when retrocession is on proportional basis.

Solution:

When the system parameter 'Method of Retrocession is Reinsured Proportionally in excess of Sum at Risk is selected:

 All Inwards Cessions included in the accumulation get a Stand Alone Individual Retrocession created with a Retro Sum at Risk being the ‘SAR Net Sum Retained’ value OR ‘Present Value Retained’ of the cession benefit (Retrocession Information tab), multiplied by the factor “Sum to be Retroceded/Total Exposure”. 

Problem:

The field names and order of columns on rejected file are not same as source input file.

Solution:

The order of the columns in the 'Test Values' and any reject file that is created should follow the same order as the input file irrespective of the mapping rules.

Problem:

Total sum retroceded amount is calculating incorrectly when the PP is linked through automatic assignment after STP is attached on AB in linked environment

Solution:

Whether the PP is automatically assigned or manually added the net sum retained should be calculated as the remaining sum to be retroceded after the STP/ QSR OCC has been applied and the sum after the retention should be the sum to be retroceded.

After tabbing to the next screen both the STP/ QSR OCC and the OCC that was linked to the PP should be listed.

If there is more than one valid PP found i.e if there is more than one PP that has the same matching reinsurer, benefit covered and insurance product then throw the message 'more than one valid PP found.'

There should be no validation of the retention and limits while finding the matching PP.

Problem:

On Facultative retrocession the Age fields (Adjusted issue age, Issue age, Transaction age) are not calculating.

Solution:

All age calculations on the facultative retrocession should be done based on the Age Calculation basis defined on the PM condition and the IO's date of birth
Any adjusted age that needs to be recalculated based on an age adjustment factor should use the age adjustment factor on the Fac Retrocession (which will be copied from the inward cession).

When the Age calculation basis is Original then the values from the inward cession should be copied to the Fac retrocession.

Problem:

Able to create retrocession with new PP for subsequent transactions on inward cession.

Solution:

Only when the system paramter 'Method of reinsurance is reinsured sequentially in excess of retention' is selected:

If a cession benefit has already been retroceded through a PP and any one of the OCCs on that PP are still active, then this cession benefit should not be picked up by any other PP.

First check if the previous transaction has the retroceded date set. If it has the flag set then the subsequent transaction should be picked up by the PP only if the PP has an OCC that is cancelled/ terminated. If the PP/ one or more OCCs linked to the PP that retroceded the previous transaction is still active, then the cession benefit transaction should not be picked up by the PP.

If it is valid, then skip this cession transaction and do not process the retrocession through the RPO that is part of this PP,

Problem:

The Total sum retroceded amount is calculating as '0' after running RPO for termination transactions other than lapse.

Solution:

The Total Sum Retroceded/ Net Sum Retained/ Unplaced Amount values should never be recalculated when a termination is processed.
All termination transactions should be processed by the RPO similar to how a lapse transaction is currently processed.

Problem:

System abends when running RPO for renewal transactions if the cession is terminated with ceded in error/setup error transactions.

Solution:

After a ceded in error/ setup in error/ cancelled from inception transaction and the cession benefit is reinstated then it should be possible to process all subsequent renewals through the RPO similar to any other renewal after a reinstatement.

Problem:

Retrocession is not created then also ceded percentage is calculated in a cession after running RPO when OCC is having retention corridor amount in limit condition.

Solution:

When the retention corridor is applied and therefore the entire SAR is retained then no calculation of ceded factor or ceded percentage should be done. The entire SAR should be considered as fully retained and the entire retention available should be considered as fully used.

Problem:
System got abends while running RPO for other transaction (Decreased) Ceded Percentage in negative values.

Solution:

The ceded percentage (and ceded factor) for each transaction should always be calculated as Retro SAR/ Sum at Risk.
The value should always be a percentage amount that is greater than 0 and less than 100.

Problem:

When unplaced amount is to be placed with Facultative treaty and the reinsurance start date lies within the closed ended treaty period the system gives validation message while attaching facultative treaty.

Solution:

When the system parameter 'Use Cession Reinsurance start date for Retrocession Processing' is selected:

Then always use the reinsurance start date of the cession when validating if the cession benefit can be retroceded to an OCC.
Even if the Fac OCC is closed ended and the benefit reinsurance start date of the benefit is outside the insured period of the OCC, if the reinsurance start date is within the insured period then the cession should be retroceded through the Fac OCC.

When the system parameter is not selected existing behaviour to remain.

Test with and without the system parameter.
Test scenario when the effective period of the transaction is outside the insured period of the OCC.
 

Problem:

RPO not working correctly while calculating the Unplaced Amount.

Solution:

For all cessions that have the first transactions as either Old Business or New Business: 

The RPO should calculate the accumulated SAR as on date of the RPO to calculate the remaining retention and then the retro sum at risk and the unplaced amount. When there is no change in the SAR then the retrocession transactions that are processed should be the same as the previous transaction. When there is a change in the SAR then the net sum retained should be recalculated based on the current accumulated SAR of the life, benefit and then calculate the retro SAR and the unplaced amount based on the new SAR. If there is no capacity on the OCC at the time of processing the RPO then the previous retention amount should remain and the sum to be retroceded beyond the OCC capacity should be unplaced.

Problem:

When the Ceded Percentage is overridden, on Running RPO with multiple OCC, the Retro Ceded Percentage is not correctly calculating and also on the Renewal the ceded Percentage is not updating on inward cession when RPO has run with multiple OCC.

Solution:

When the ceded percentage is overridden on the cession then on the retros calculate the ceded percentage on proportional basis using the automatically applied ceded factor on each OCC retrocession. The placement cessions ceded percentage should be the OCC retrocession ceded percentage * retrocessionaire share percentage.

When the cession is renewed without a change in the ceded percentage then copy the value from the previous transaction.

Problem:

RPO did not calculating the Retention, Retro SAR and Unplaced Amount Correctly when we have multiple policies on the same life

Solution:

When there are multiple policies on the same life and all are being picked up by the same RPO.

When all the cessions are being created as new business retrocession transactions for the first time i.e there is no existing cession on that life, benefit:

1. Sequence the cession transactions as per the reinsurance start date
2. When there are more than one transaction with the same reinsurance start date then use the sequence number to sequence them, the lowest number should be considered for retrocession first
3. Process the cessions in the sequenced order by accumulating the risk as the retros are created.
4. Once the retention is fully exhausted, the remaining sum at risk should be retroceded on the later sequenced transactions
5. Once the capacity is exhausted then for the later sequenced transactions all the amounts should be placed as an unplaced amount

When there is an existing cession transaction on that life, benefit:

When there is no change in the SAR on the subsequent transactions:
Copy the same values for net sum retained, net sum retroceded and unplaced for the subsequent transactions.

When there is a change in the SAR on the subsequent transactions:
Calculate the sum to be retroceded, and apply the existing available retention as on the transaction effective date of the cession benefit, if any, and the existing avalaible capacity, if any, to calculate the net sum retained and retro sum at risk and unplaced amounts.

Problem:

Duplicate IO's are creating for rejected Joint life records.

Solution:

When a cession with a joint life IO is rejected due to any reason the entire record should be rejected. No IOs should be created or updated.

When the joint life IO already exists or if the cession record is attempting to create a joint life IO with an already existing single life IO also no IO related record should be created when the record is rejected.

Problem:

User without access to Life and without assigned Access Code for Life is able to create accounting data in Life via SICS Server createWorksheet.

Solution:

User without access to Life and without assigned Access Code for Life should not be able to process any operation through the SICS Server. The security error messages similar to the online access should be thrown when this is attempted where the webservices has the user id as part of the input.
Similarly, a user without the access to P&C should not be allowed to perform any operation through the SICS Server in the Life environment.
 

Problem:

Incorrect Sum retroceded and Net sum retention amounts on subsequent transactions after running RPO on Reinstated cession.

Solution:

All transactions after a reinstatement should be considered independent of the termination and reinstatement. When there is no change in the SAR on the transaction after the reinstatement, i.e the SAR is the same as the SAR of the active transaction prior to the termination and reinstatement, then the retrocession details should remain the same as that active transaction.

When there is a change in the SAR, the retro SAR, net sum retained and the unplaced amount if any should be calculated as per the same logic that is applied on a cession where there has been no termination and reinstatement.

Problem:

Definition of disability field is not available in output pattern

Solution:

Include the field Definition of Disability (with the name as per the database column) available on the claim output pattern and cession output pattern

Name : Definition of Disability (name as per database column)
Type: Reference Data
Mandatory: No
Repeatable: No
Reference Data Class : Definition of Disability 00996

Problem:

Error message on cession loader is incorrect ,when a future date for 'benefit reinsurance date' is provided.

Solution:

For both manual and cessions created through the loader, when the Benefit Reinsurance Start date is later than the current date the error message ' Benefit Reinsurance start date cannot be a future date' should appear and the transaction should fail,

Problem:

System is not throwing any validation message on creating an Increase/Decrease Transaction with a future date. 

Solution:
 
When there is any Increase or Decrease transaction is done on a cession benefit and the effective date of the transaction is later than the end date of the current renewal effective period then the message LCH153 Renewal points exists which have been missed on this cession benefit. Do you want to continue?

On the loader, this message should be marked as No ONLY for Increase and Decrease transactions and the transaction should fail ONLY when the transaction type is Increase or Decrease.
This is applicable to both ceded and non ceded cessions.

Problem:

System is fully retroceding the fully Unplaced Old Business Transaction, on running RPO for a Increase Trasaction on the same cession.

Solution:

Only transactions that do not have the retrocede date set should be picked up by the RPO.
However, if there are subsequent transactions which have been picked up by the RPO then any previous transaction which does not have a retroceded date should be ignored.

Problem:

Error when running the  Multi GAAP Retrocession error and the calculation rule requires a value from the single accounts which do not exist.

Solution:

ONLY When the system parameter 'Period According To The Calendar Time' is selected :

Check whether the businesses that are included in the Multi GAAP Retrocession order as part of the Add Business option or List Business option have the Admin condition with the single accounts created.

If the business included does not have the single accounts listed then throw the error message 'Agreement <Id> has no Single Accounts. Therefore this business will not be included in this order' on saving the order and automatically flag the business as Included = No.

When the businesses are listed through the List Business option, on saving the order, each business that does not have the single accounts should be validated and flagged as Included = No in the order.

It should not be possible to select Include = Yes and save the order for any business where the Single Accounts are not created.

Problem:

Able to create facultative Retrocession on subsequent transactions on an inward cession which is fully retained by RPO.

Solution:

Where the cession transaction does not have the retroceded date / and or the retrocessions attached flag BUT it has the retroceded date and/ or the retrocessions attached flag and there is no amount in the remaining unplaced amount field then it should not be possible to attach a facultative retrocession- the option should be disabled on right click.

Problem:

System is allowing to take different currencies for retention and auto cover limit.

Solution:

When there is a mismatch between the retention, underlying top limit and autocover limits then the error message ' Limit Currencies must be the same as the Surplus Retention Currencies' should be thrown.

The message currently appears only when the Autocover limit currency is changed to be something other than the retention currency.

All retentions and autocover limits should be validated on the cession against the same currency or equivalent values.

Problem:

System is vanishing all data from the capped quota share retention window when not saving the limit condition and clicking on the previous button from retention corridor tab.

Solution:

Attachment option is not applicable for a Capped Quota Share type of business.
Therefore any value entered in the Limits tab should not be cleared when navigating back to the screen when clicking on the Previous buttons if the type of Limits is not 'Attachment'.

Problem:

Amount in remaining unplaced amount is not fully decreased even after Unplaced amount is fully decreased.

Solution:

The remaining unplaced amount should always be calculated as Unplaced Amount - Fac total Sum Retroceded.
When there is no value in the Unplaced Amount field or the value is 0, then there should never be a value in the Remaining unplaced amount field.

Problem:

Incorrect amont is updated on the retrocession tab when ran RPO for the reinstatement transaction

Solution:

Only when the system parameter 'Method of retrocession is reinsured sequentially in excess of retention' is selected.

When a reinstatement transaction is created on the inward cession and there is a retrocession linked to this cession with a full recapture transaction then always update the retroceded date on the cession transaction with the date of reinstatement. The same should be updated on the reinstatement created on the retrocession also.

The reinstatement should now never be picked up by the RPO.

If there is no retrocession linked to the inward cession then do not update the retroceded date.

Problem:

On an OCC, system is allowing to override Premium Calculation frequency on each child section, when Agreement Section has Calc. Frequency Original resulting in incorrect retroprocessing.

Solution:

When the PM condition on the OCC or placements on any section (agreement or child) is updated to a frequency other than Original then the user should get a warning message as below.

'The system has been configured for sequential reinsurance/ retrocession processing. The premium calculation frequency of the outward business should remain 'Original'. Any other value will result in incorrect outward cession processing'

The message should not appear for inward assumed business or when the system parameter mentioned above is not selected.

Problem:

Extra mortality commission is calculating incorrectly when there is change in SAR on the cession having half yearly renewal frequency

Solution:

Basic premium should be calculated for ceded cessions by applying the premium rate defined as an annualised value and dividing it as per the defined premium calculation frequency.
Extra mortality premium should be calculated on the already calculated basic premium,
Extra mortality commission should be calculated on the EM premium based on the definition on the Deduction condition for Extra premium commissions.

This calculation should be done for all transactions such as increase, decrease, other or renewals where the SAR is changed and the premiums are based on the SAR.

Problem:

Total Sum retroceded and Net sum retained are updating as ‘zero’ for lapse transaction.

Solution:

When the Reinstatement of the retros is not automatically created i.e when the linked retro is not inactive since the termination transaction has not been processed by the RPO, then the retroceded date should not be updated on the reinstatement transaction.

The RPO will need to run to pick up the termination, reinstatement and any subsequent active transactions.

When a lapse or any other termination is created , the values in the retrocession tab should remain as per the values from the transaction effective period within which the termination transaction falls.

Problem:

Subsequent transactions are creating incorrectly on Fac retrocession and on inward cession the fields 'Fac total sum retroceded' and 'Remaining Unplaced amount' are updating incorrectly.

Solution:

All fields on the Fac retrocession should be updated based on the corresponding inward transaction from which it was created.
Once the Fac retrocession/ retrocessions are created then the fields Fac total Sum retroceded and the Remaining Unplaced Amounts should be calculated and updated on the transaction (Total Unplaced - Fac total Sum Retroceded = Remaining Unplaced Amounts).

All fields that are to be calculated on the Fac retro transaction such as Retro SAR, ceded percentage should be updated on the Fac transaction.

All fields that are to be copied from the inward cession transaction such as Original Sum Insured. Cedent Retention, values in the Other tab etc should be copied from the linked inward cession transaction.

The Retroceded Date on the fac retro should be set based on the transaction effective date that created the fac retro transaction.

Problem:

On Income benefit per frequency Claims in decision liability tab The field Taxation Basis is not visible in edit and in view screen.

Solution:

The Reimbursed/ Source radio buttons that are applicable to interest and taxation should be visible always on the Decision liability tab in both view and edit mode for all sum reinsured types and benefits covered.

Problem:

SICS Abends with error message 'ORA-01427: single-row subquery returns more than one row' while loading claim on a policy which 2 Benefits with same insurance product.

Solution:

Always reference only the active cession effective period within which the claim event date falls in when a claim is to be created on the cession benefit.
It should never be possible to have two overlapping active effective periods with the same BC-IP on the cession.

Problem:

System is allowing to add additional benefit on a existing cession with overlapping effective periods.

Solution:

Even when one benefit on the cession is inactive, when another benefit with the same details (benefit covered, insurance product) is added to the same cession and the benefit reinsurance start date of this benefit falls within an active effective period of the inactive cession benefit, then the transaction should fail when the loader tries to add this benefit with the messaage 'A benefit with the same insurance product already exists on the cession...' answered as No and the benefit should not be added to the cession,
Manually, this message will be the existing confirmation message.

Problem:

System does not allow to delete the existing Loading factor while creating renewal or Reinstatement with update transaction.

Solution:

1. Enable the Delete Loading Factor option on the manual options when a loading is created/ edited on a subsequent transaction.
When deleted, the loading ACIs should be recalculated and removed from that transaction onwards. If the transaction effective date falls within an effective period, then the pro rata loading ACIs should be calculated

2. Allow adding a loading with a value of 0 (EM, permille, flat extra, age loading)
When this 0 value is added ignore the loading instead of giving an error message the message should be a confirmation message

When a permille or flat extra with a 0 value is created :
SYN000013 The Amount field must be greater than 0. The Loading will not be created. Do you want to continue?
When an extra mortality loading is created where the percentage is <101
SYN00005 The Amount field is smaller than its minimum allowable value (101). The Loading will not be created. Do you want to continue?

Online, the user will be allowed to select Yes and if Yes is selected then the loading should not be added to the transaction
When the user selects No, then the user should be forced to add a non 0 value/ a percentage greater than 100 to continue

Where the specific type of loading does not exist on the cession benefit already

In the loader the message should be by default answered as yes and the loading should not be created, effectively ignoring the loading that has been mapped.

Where a loading already exists with a value and a 0 value is loaded on a subsequent transaction:
When a value of 0 is loaded then the existing loading value should be reset to 0, the confirmation message should be thrown and the loading should now be deleted.
The ACIs should be recalculated based on this removed loading,

For any transaction where the loading value is changed, then the updated loading should be applied for that transaction as per the effective date of the transaction on pro rata basis.

Aim of function

The aim of the function is to be able to prevent the retrocessions from being created by the RPO if the ACIs are not calculated on the retrocessions

Business value for customers 

When the premium ACIs (and other ACIs that are dependent on the premium) are not created, the retrocession cession continues to be created without any ACIs.

It is also not possible to easily identify such retrocessions and ACIs cannot be added manually after the retrocession has been created.

If a retrocession cession is created without any ACIs it will result in discrepancies in the accounting process.

Now, it is possible to prevent creation of a retrocession cession when there are no ACIs created

System Parameters Affected

None

Existing functionality affected

A flag 'Create Retrocessions even if ACIs are not created' is now available on the RPO
This is selected by default

Where the OCC has premium rate lookup tables that have been defined such that the premium is to be calculated based on parameters available on the inward cession (eg: Smoker Status, Occupation Class, Occupation Code etc), then when the necessary value is not available on the inward cession, it will mean that the value will not be copied to the retrocession and therefore result in the Premium ACIs not being created.

When the above mentioned flag is selected and the inward cession does not have the necessary parameters for the retrocession ACIs to be created, then the cession will be listed in the failed assignments and the retros will not be created

Note: The current implementation is limited to only validating reference data values in the premium rate Lookup Tables on the OCC against the values available on the inward cessions. Any other calculations (such as missing Age values, missing inward cession ACIs for As Original or Retro Share of Original) will not be supported and the retrocession cessions will continue to be created without ACIs
 

Aim of function
The aim of this enhancement is to introduce a Retention Corridor to the Capped Quota Share retrocessions

Business value for customers
When a retention corridor is defined for a Capped Quota Share business, then when the sum to be retained is within the defined retention corridor, but exceeds the defined capped retention amount, the amount will be retained

System Parameters Affected

None

Existing functionality affected

Only when the system parameter 'Sum at Risk Reinsured Sequentially in excess of retention' is selected.

A new tab 'Retention Corridor' is available on a Capped Quota Share OCC

Only Monetary Amount will be considered, any value defined as a percentage will be informational.

When the sum to be retained as calculated by the RPO falls above the defined capped retention, but this is within the retention corridor that has been defined on the condition, then instead of the amount being Unplaced, this amount will be considered as retained.

Note: This retention corridor is applicable only to the first transaction that is retroceded and will not be considered when the subsequent transactions have changes in the SAR. Also, the retention corridor will not be accumulated and will be applied on only one cession benefit that has been processed sequentially.

Aim of function

The aim of the function is to be able to create proportional claims without a link to a cession benefit

Business value for customers

It could be possible that for some customers, the claims are handled independently and are interfaced from a separate claims system. To support handling of claims without the need for an already created cession / retrocession for recovery, it will now be possible to create a proportional claim by entering all the necessary details on the claim record itself

System Parameters Affected

None

Existing functionality affected

A new type of claim 'Standalone Proportional Claim' is now available
This claim can be created without the link to a cession

The claim loader now has an output pattern that is specific to a Standalone Proportional Claim where there will be no referencing to an inward cession

Note: The current implementation is limited to creating an inward proportional claim only. No retrocession claims or claim recovery is possible

Aim of function

The aim of the function is to use the current 'Extended Term' transaction to also reduce the term on a cession benefit, thereby creating the necessary reversals of account costing items where applicable

Business value for customers

When the term of a cession is reduced, then the existing transactions that had already been created with the account costing items should be reversed and adjusted as per the new benefit expiry date. This functionality will allow the user to create the necessary reversals and adjustments

System Parameters Affected

None

Existing functionality affected

The 'Extended Term' Amendment transaction on a cession benefit will now be applicable to reduce the term also

When the policy expiry date is to be updated as a backdated transaction then the effective date of the Extended Term Transaction will be equal to the new Benefit Expiry Date. All ACIs will be reversed and refunded based on the definition on the AC condition

Aim of function

The aim of the function is to prevent update in Underwriting year on a definite business

Business value for customers 

The business value for customers is that it will now not be possible to update the insured period start date and therefore change the underwriting year on the business

System Parameters Affected

New system parameter 'Prevent update of Insured Period Start date or Underwriting Year on a Definite Business' is now available under Business -> Insured Period

Existing functionality affected

When the above-mentioned system parameter is selected, then the user will not be able to change the insured period start date or underwriting year on a definite business.

Aim of function

The aim of this enhancement is to allow flexible reinstatement options where the benefit that has been terminated can be reinstated with terms and conditions that are different from the original cession benefit

Business value for customers 

Through this new type of reinstatement, the customer will be able to reinstate the terminated benefits from a specific date, up to a specific date and also, update the cession benefit with additional loadings or changes to the insured's occupation etc in the reinstatement transaction

System Parameters Affected

None

Existing functionality affected

A new type of Reinstatement transaction 'Reinstatement with Updates' is now available
When this transaction is created on a terminated cession the following functions are possible

1. The reinstatement may be created for specific effective periods only
2. It will be possible to update the details on the cession benefit such as SAR, loadings, occupation class etc on this transaction
3. When this reinstated transaction is picked up by the RPO the corresponding retrocession transactions will be processed based on the available retention and capacity as on the date of running the RPO, using the updated values on the reinstatement transaction

Aim of function

Improve UX of SICS Life Screens in Business and Cession areas.

The Term & IO Information Tab of Joint Life Cession & Retrocession is improved by proper alignment of all the fields and Creation of new tab named as Individual Specific life data. 

The Standalone Individual Retrocession creation screen is improved by proper alignment of All fields.

The Business Highlights Tab is improved by removing the General Group box under the General Tab. 

The Additional Scope (AS) condition of Business is improved by removing the Original Conditions Group box on the Original Condition Tab. 

Business value for customers

Improved Look & feel of SICS Life application.

System Parameters Affected

N/A

Existing functionality affected

N/A