Release documentation - Life - Enhancements and requests

Problem:

Additional customizations for Life Universe will be added to the standard Life Universe.

Solution:

Include the three views mentioned below in our life universe database side

V_GRP_TRANSACTION_CODE

V_TRANSACTION_CODE

V_TRANSACTION_CODE_INWARD.

*The joins for these three views need to be created.

*Associated objects that are connected to these views must be created once joins are created.

Problem: Getting Division by Zero error while loading data for the views V_ACCT_PERIODS_BUILD & V_BOOK_PERIODS_BUILD.

Solution: Need to adjust the view script for both the views with condition as suggested.

Problem:

Missing retrocessionaire percentage field in the Life Universe reporting side.

Solution:

The retrocessionaire % field must be added to the Life Universe side.

Object Name: Retrocessionaire Percentage

SQL: CESSION_DETAIL_RETRO.RETROCESSIONAIRE_PER

Problem:

24.3 BOAC005_PAIRING & BO_REP_UNIT files generated via SICS Admin returning NULL and some garbage values respectively.

Solution:

The BOAC005_PAIRING & BO_REP_UNIT needs to be corrected for LIFE as per the script attached.

Problem:

The stored procedures BOAC007 & BOBU001 are not required and the supporting scripts SUPP001, SUP004, SUP005 & SUP006 have reference to BOAC_PC_FACT table which is not applicable for LIFE.

• Solution:
  The stored procedures BOAC007(hidden for FWD but should be retained for LIFE) & BOBU001 should be made hidden if possible since it is not required for LIFE.
  BOAC007 - is related to retrocession pairing and for LIFE it is a bit different than PC. (It should be retained for LIFE, but for FWD, it can be hidden.)
  BOBU001 - is again related to business limit and premium and it is not at all required in LIFE.
• For the supporting scripts SUP001, SUPP004, SUP005 & SUP006, we have reference to BOAC_PC_FACT, which is limited to PC only, instead for LIFE these supporting scripts should have reference to BOAC_LF_FACT, so we need to alter them and make the reference to BOAC_LF_FACT for LIFE.

Problem:

Solution:

Declination Reason:

Workaround:

Root Cause:

Extent of Impact:

Impact on Existing Data

Recovery Method for Existing Data Affected

Problem:

Solution:

Declination Reason:

Workaround:

Root Cause:

Extent of Impact:

Impact on Existing Data

Recovery Method for Existing Data Affected

Problem:

Separate Technical Worksheet not possible when Write-Off is created during Balance Pairing in Life

Solution:

When the system parameter ’ Include Realized Loss/Gain for FC revaluation’ is selected enable the system parameter ' Enable to system paramter 'Entry Code for Write Off'
When this is enabled it should list the entry codes that have been defined under the Entry Code sub category 'Other Deduction' for selection
When the balance pairing is done and there is an outstanding amount that can be written off then the write off technical worksheet should be automatically created with the write off entry code selected in the system parameters
The above is the same functionality as we have in P&C which should now be extended to Life

Problem:
RCPO on aggregation basis produces incorrect Claim ACI

Solution:

When there is a ceded paid status after a ceded outstanding status then the amount of Claim Reserve should be reduced to the amount of the loss ACI until there is no Claim Reserve left.
For every ceded paid transaction created after a Ceded Outstanding transaction create a reversal of the Claim Reserve ACI using the same entry code of the claim reserve ACI equal to the amount calculated under the Loss ACI of the Ceded Paid transaction until the Ceded Outstanding ACI = 0

When the reversal of the ceded outstanding status ACI is created on the Ceded paid status, initially retrieve the sign of the loss entry code. then negate this sign to obtain the opposite sign on claim reverse entry code on ceded paid status

Problem:

Performance issue on Find Cession Window

Solution:

When fetching cessions do not order by the policy number or cession id or cedent cession id or group scheme id which is provided as the search criteria before retrieving the cession

Problem:

'SAR for retrocession' amount with decimal places

Solution:

When the system parameter 'SAR in Decimals' is selected then the value in the field SAR for Retro cession should be displayed with the same number of decimals as defined in the system parameter similar to the other fields on the cession benefit

Problem:

When attach Fac OCC on the cession, the retention amount is updated in negative and the FAC fully placed amount is updated incorrect

Solution:
When the system parameter 'Retrocession Basiss : Sequential in excess of retention' is selected and the calculation frequency of the OCC is Original

When the RPO is run

Always sequence the cession benefit transactions as per the sequence number, the lowest number should be processed first. When there are inconsistent values (numeric, alpha numeric or same sequence number then the existing random logic can remain)

For each cession benefit transaction

Process the Net Sum Retained, Retro SAR and the Unplaced Amount as per existing functionality
When there is a value in the field Fac Total Sum Retroceded on the transaction that the RPO has picked up, then calculate the Retro SAR as MIN( SAR- Fac Total Sum Retroceded, available capacity) (Here it will mean that there will never be an amount that is retained since there is a Fac Total Sum Retroceded)
When the Unplaced Amount - Fac Total Sum Retroceded > 0 then update the field Remaining Unplaced Amount as Unplaced Amount - Fac Total Sum Retroceded

The amount in the Net Sum Retained should never be negative

Problem:

When placing unplaced share facultatively system is incorrectly throwing a validation error message that the relevant ACI is already booked

Solution:

If the increased SAR on a cession has resulted in an unplaced amount and this unplaced amount is being retroceded to an existing Fac Retrocession on a separate transaction where no ACIs exist or being adjusted to an existing transaction where the ACIs are in a released status then the transaction should be allowed without any validation error message irrespective of the accounted status of the previous ACIS

Only in a scenario where the increased SAR is being adjusted on an existing transaction and the ACIS on the existing transaction are included and being attempted to be recalculated should the message 'LCH279 Validation error as _The ACIs in the selected facultative retrocession are included in accounting. So adjusting to the transaction is not allowed -

Problem:

RPO processed retrocessions with incorrect retro SAR when System parameter 'Sequencing based on Policy number' is selected.

Solution:

When the system parameter Sequencing based on Policy Number is selected the calculation of the retro SAR should follow the same logic as when the system parameter 'Sequencing based on sequence number is selected'
Apply the same checks as introduced in SE-5263 when the system parameter Sequencing based on policy number is selected

Note: The business scenario here will be that there is only one cession benefit per cession
 

Problem:
System allows to select system parameters Sequencing based on policy number when Parameter Sequencing based on cession benefit sequencing number is selected and vice versa.

Solution:

 When the system parameter 'Sequencing Based on Policy number' is selected the system parameter 'Sequencing based on Sequence Number' should be disabled for selection and vice versa. Only one of the two system parameters should be allowed for selection

Problem:
Incorrect Messages on Cession creation, when cession is created with SAR more than the AB limit using Reinsurance Program.

Solution:

When the reinsurance program does not have enough capacity the message 'The amount <amount>, cannot be reinsured and will be unplaced' should be thrown. This message should also be listed in the result of the cession batch along with any other confirmation message that has been answered as yes.

Through the loader all other confirmation messages should be answered as Yes and listed

When the confirmation messages LCH252 are answered as Yes then the cession should be created only upto the maximum capacity defined on the treaty

When the confirmation message LCH252 is answered as No and the business is a P Auto with a Fac component then the entire SAR should be added on one cession and no additional cession should be created

When the reinsurance program does not have capacity i.e the final layer does not have enough capacity the message LCH253 will be thrown. 'the reinsurace program does not have capacity do you want to create the benefit upto the autocover limit'

When this message LCH253 is answered as yes then create the cession with the SAR upto the capacity of the last layer AB and then throw the message ' 'The amount <amount>, cannot be reinsured and will be unplaced'{}

If the user clicks on No to LCH253 then 'The amount <amount>, cannot be reinsured and will be unplaced' should be thrown

All messages should be listed in the loader

Problem:

Abend while running the RPO on reinstatement with update transaction when there is a Fac retro attached

Solution:

When there is a pure fac retro linked to the inward cession (with no treaty retros) then when there is a reinstatement with update transaction on the inward create the reinstatement with update transaction on the linked fac retro automatically (similar to an Other transaction)

Update the retroceded date on the inward cession benefit transaction with the Reinstatement From date of the reinstatement with update transaction

This transaction will now never be picked up by the RPO

If there is any change to the SAR on the inward cession or any loadings added in the reinstatement with update transaction then the change should be reflected on the Fac Retro similar to any other transaction where there was a change in the SAR

Problem:
On Renewing the Business, the new main currency is not updating if it is changed, through webservices.

Solution:
The currency that has been updated during the renewal process of the renew business webservice should be updated in the renewed insured period
 

Problem:

Incorrect ACI's calculation on retro claim when SAR calculation rule is defined on the OCC.

Solution:

When the RCPO is run always use the ceded percentage on the claim (that is copied from the cession benefit or entered on the claim) to calculate the retro ACIs
This is irrespective of whether the SAR calculation rule is available on the OCC or not. The ceded% is calculated on the cession benefit using the SAR for Retrocession amount- this ceded% should always be applied to all the ACIs on the inward claim when calculating the retro claim ACIs

Problem:

In Claim ACI's system allows to add an additional entry code's from same entry code sub category where defaulted entry codes are added.

Solution:

When there is any ACI on the inward claim that is part of the entry code sub category Loss then the RCPO should only use the value on this ACI to calculate the retro claim ACI using the ceded percentage. The value that is defaulted on the retro claim under Claim Liability should not be used to create the retro claim ACI.

If there is no ACI on the inward claim with an entry code under the entry code sub category Loss then use the Claim Liability on the retro claim to calculate the retro claim ACI using the entry codes as mapped in the calculation model

Any ACI on the inward claim that is not under the entry code sub category Loss should be created on the retro claim by applying the ceded percentage as per existing functionality

Similarly, if there is a value mapped with an ACI that is under the entry code sub category Claim Reserve, then do not automatically calculate any further ACI with the calc model entry code value

Problem:

Failed to calculate loading on premium& Commission

Solution:

When a business and the PM condition is created through webservices always default the Premium Basis as Sum Reinsured when the premium option is Fixed Premium Rate or Value (This is the solution on SE-3407)
When a rate table or multiple rate tables or PM Calculation rule are selected- the premium basis should always be defaulted to use the Sum Reinsured basis

For any Premium Basis the premium unit should always default to PerMille and the PremiumBasis should default to Sum Resinsured

Problem:

Ceded Percentage for Retention corridor is not updating when SAR is with in the Retention corridor limit of the OCC.

Solution:

In the field 'Ceded Percentage - Retention Corridor' show the ceded percentage when the SAR for Retrocession/ SAR is within the retention corridor and the SAR for Retrocession/ SAR is retained even though it is above the defined retention. The Ceded Percentage should be updated as SAR for Retrocession or SAR - Retention on the OCC / SAR for Retrocession or SAR

When there is a Sum at Risk calculation rule always use the value in the field SAR for Retrocession

When there is no SAR calculation rule then the value in the field SAR for Retrocession should be used if it has been defaulted from the Sum at Risk field (SAR = SAR for Retrocession) Else, use the value in the Sum at Risk Field.

This should be applicable for retrocessions and renewals and subseqeunt transactions also- this field should be recalculated on the subsequent transactions when the RPO picks up the cession benefit and the SAR for Retrocession has changed, but is still within the retention corridor. Else it should be copied from the previous transaction.
When there is a retrocession created then the ceded percentage should be calculated as per existing functionality but the value in the field Ceded Percentage- Retention Corridor should be copied from the previous transaction. No further calculations to this field will happen when there is a retrocession linked to the cession.
 

Problem:

When Business are created through webservices and with a Premium calculation rule the Premium basis is setting as NULL by default.

Solution:

When a business and the PM condition is created through webservices always default the Premium Basis as Sum Reinsured when the premium option is Fixed Premium Rate or Value (This is the solution on SE-3407)
When a rate table or multiple rate tables or PM Calculation rule are selected- the premium basis should always be defaulted to use the Sum Reinsured basis

Problem:

system is not referencing cession amount in our share flag on cession 2 for cession created through a reinsurance program

Solution:

 When the flag Cession Amount in Our Share is selected the ceded share % should be applied to the defaulted value on the field Sum at Risk

Problem:

 The AS condition is not updating on renewing though webservices, when the <copyBusinesscondition. > flag is defiend as false.

Solution:
The AS condition should always be copied to the renewed insured period irrespective of whether the <copyBusiness condition> flag is selected as yes or no

Problem:

On inward claims the field Benefit sum reinsured is updating with the value of Cession Sum at risk field.

Solution:

When there is a value on the field SAR for Retrocession on the inward cession transaction this value should be defaulted to the Benefit Sum Reinsured field on the inward claim that is created

Problem:

In find claim window option 'Proportional Standalone' is not available in the non-standalone retrocession configuration

Solution:

The option to create and find Proportional Standalone Claims should be available on all environements irrespective of the system parameter selection of Retrocession Basis
 

Problem:
System is not updating the Expiry Date or Benefit Term on the Cession created through loader with transaction code as OldBusiness and it is nonceded cession.

Solution:

For all transactions for Old Business when the cession is created manually or through the loader the benefit term should be updated from the mapped value and the the expiry date should be updated based on the benefit term. When the expiry date is mapped then it should be updated on the cession benefit and the benefit term should be calculated based on the expiry date. This is similar to New Business transactions that are loaded

Problem:

On the Cession renewal Order, system is listing all the sections of the business when list business is selected.
 

Solution:

When the option List Business is selected on the Cession Renewal Order list only the business insured periods and not the sections
 

Problem:

Abend with Cancel from inception transaction

Solution:
When an inward cession has a transaction of Cancel from Inception, Setup in Error or Ceded in Error then any linked retrocession should also be automatically cancelled from inception

This is applicable to any retrocession which is linked to any transaction on the inward cession even if the retrocession was attached to a later transaction

This is also applicable to all Facultative Retrocessions that are linked to the cession

Problem:

On Cession Loader system is not showing correct error message when Cession is Failed due to missing value of SAR decrement Reserve table.
 

Solution:

Similar to the online functionality, when the SAR Decrement table cannot be applied due to a missing parameter on the cession benefit then the error message that is displayed on the cession batch for the failed transaction should be the same as the online message
If it is a confirmation message the message should be answered as No. If the message is informational and does not allow the user to proceed further online, then the message should be answered with the OK and the record should fail

Eg: When the Decrement table has parameters such as Age and Elapsed Duration then when the age of the IO on the cession falls outside the parameters defined on the LUT the message ' 'Sum At Risk - No Row found in Table: INSULAR TABLE - AAXX16102024XXAA
for values:
Age = 87
Elapsed Duration = 0'.
 

Problem:

Retrocessionaire percentage is not calculated when we have SAR rule

Solution: 

Calculate the value on the field Retrocessionaire percentage on all the placements when the retrocession has been processed using the value on the field SAR for Retrocession similar to the scenario when the retros are processed using the value in the field Sum at Risk
Update the value in the Retrocessionaire percenatage on all the placements and also on all the placement claims when a claim is recovered

Problem:

 The Administration Condition is not updating though webservices when the elements are defined on the createLfBusiness on creation of a new Treaty.

Solution:

Similar to how the Admin condition is updated when the

<accountsCommonCondition> operation SOAP is executed by itself, the admin condtion should be updated when it is part of the Createlf business soap

Problem:

System is not throwing the validation message and creating/updating Claim Condition without the mandatory field defined through webservices.
 

Solution:

The same error messages that are applicable when updating the claim condition online manually should be applicable when creating or updating the condition through webservices

When the elements for field Claim Laibilility Basis and Remmitance Send are not defined for a non prop business, system should fail the SOAP to execute with the validation error same as online functionlity.
When the elements for field Remmitance Send are not defined for a Prop business, system should fail the SOAP to execute with the validation error same as online functionality.
 

Problem:

Decline claim doesn't reverse previous outstanding claim ACI

Solution:

Irrespective of the Declined Type (No refund, refund on pro rata basis ..etc) when a claim is set to a declined status and it has a Ceded Outstanding status prior to the declined status then the entire Ceded Outstanding ACI should be reveresed with the same entry code, but negated

Problem:

Retro SAR calculation wrong

Solution:

Problem:

Failed to upload transaction 'Reinstatement with Update' transaction

Solution:

Aim of function

Extend the SAR calculation rule to perform more complex calculations to calculate the SAR for Retrocession.

Business value for customers

Customers will be able to create more flexible SAR calculation rules where values within the cession benefit can be recalculated and then used to calculate the SAR for Retrocession. 

It will also be possible to refer to the Limits defined on the OCC and apply these limits to calculate the ceded percentage and then use the ceded percentage to process the retrocessions.

System Parameters Affected

New calculation rule in the System Parameters- > Business- > SAR Calculation rule

Existing functionality affected

A new type of calculation rule is now possible within the SAR Calculation Rule where various fields within the cession benefit can be calculated and updated while running the RPO and then these calculated values can be used to calculate the SAR for Retrocession value that will be considered for Retroprocessing.

Example:

The below calculation rule with the rule name defined with the update-<fieldname> , here update-deductible will calculate and populate the value on the cession's Deductible field: 

This calculated value which will be available in the Deductible field will now be applied to the main SAR calculation Rule (along with other calculation rules and values) to calculate the value that will be applied for retroprocessing and be updated on the SAR for Retrocession field of the cession benefit transactions:

Aim of Function

The aim of this enhancement is to be able to update the following business conditions on a non proportional business. 

Limits Condition

Premium Condition

Deductions Condition

Underwriters Estimates Condition

Business value for customers

Life Customers will be able to update the conditions on the Non Proportional Treaty through webservices as an update in the current insured period or after renewals of the treaties.

System Parameters Affected
None

Existing functionality affected

Update Claim Condition

Update Deduction Condition

Update Limit Condition

Aim of Function

The aim of this enhancement is to be able to create the following business conditions on a non proportional business. 

Limits Condition

Premium Condition

Deductions Condition

Claim Condition

Business value for customers

Life Customers will be able to create the conditions on the Non Proportional Treaty through webservices. 

System Parameters Affected
None

Existing functionality affected

Create Limits Condition

Create Premium Condition

 

Create Deduction Condition

Create Claim Condition

Aim of function

Use the Cut off Lower Limit conditions while processing retrocessions

Business value for customers

When the cession SAR falls below the recapture limit defined on the L condition the cession will be recaptured

System Parameters Affected

None

Existing functionality affected

On a Surplus OCC the values defined in the Limit Condition- > Cut Off Lower Limit field will be applied when the RPO is run and the cession benefit transaction will be recaptured when the SAR or the SAR for Retrocession on a subsequent transaction falls below the cut-off limits defined. 

The retrocession cession will continue to be picked up and processed by the RPO with the SAR = 0