14 Legal Entity Consolidation

The reporting entity may be a part of an Insurance Company that consists of multiple legal entities such as parent or child entities (subsidiaries) under its name. Users can select the entity for which processing must be done. In addition, whether a ‘Solo’ or ‘Consolidation’ execution must be done using the Run Execution screen. However, if it is executed using RRF execution then these options must be set up using the rule ‘Capital Consolidation Level Selection’ in the process 'CAPITAL_CONSOLIDATION’.

CAPITAL_CONSOLIDATION is the first process to be added in all the Runs defined through Run Rule Framework except the ones for the staging data population. Run Management screen selects this process by default.

ATTENTION:   

All the following sections are applicable also to Stage and Results on Hive.

Topics:

·        Run Parameters Assignment

·        Consolidation Procedures

·        Types of Consolidation

·        Consolidation Activities

·        Legal Entity Tables

·        FSI Intracompany Policy Table

·        Populating Legal Entity Tables

·        Populating FSI Intracompany Tables

Run Parameters Assignment

Run Management Framework in the product allows the reporting Insurance Company to define and execute a Run by selecting a combination of parameters capital computation.

The rule ‘Run Definition User Defined Run Param Assignment’ is used to assign the run parameters in case of a run executed through the Run Rule Framework. However, if the execution is through Run Management, the parameters are populated based on the run defined in the run definition screen.

Consolidation Procedures

The Consolidation procedures are as follows:

·        Combine items of assets, liabilities, equity, income, expenses, and cash flows of the parent with those of its subsidiaries.

·        Offset (eliminate) the carrying amount of the investment of the parent in each subsidiary and the equity portion of the parent of each subsidiary (IFRS 3 Business Combinations explain how to account for any related goodwill).

·        Eliminate in full intragroup assets and liabilities, equity, income, expenses, and cash flows that relate to transactions between entities of the group (profits or losses resulting from intragroup transactions that are recognized in assets, such as inventory and fixed assets, are eliminated in full).

In the preceding list, the first and third points are partly handled in the consolidation process, second is accounting idea output, which is provided in General Ledger as a part of Stage General Ledger data inputs

Types of Consolidation

The types of Consolidation are as follows:

·        Simple Aggregation: Aggregate across entities without any elimination.

·        Full Consolidation: Aggregate and eliminate intra group transactions.

·        Proportionate Consolidation: Aggregate and eliminate intra group transactions and balances reflecting consolidation percentage owned by parents in a subsidiary.

Consolidation Activities

Scope of Consolidation is the list of Entities that participate in consolidation. Legal Entity Structure is looked through the Organization Structure Dimension. This stores the parent-child relationship and is stored only once. When moving the data, Legal Entity can move related entities to the processing or reporting area. The legal structure is finalized once, and this structure only stores one parent-child relationship.

This is the Data Flow diagram of Legal Entity consolidation activities.

Figure 77: Legal Entity Consolidation Data Flow

Legal Entity Tables

This section provides information about Insurance Legal Entity population tables in the Oracle Insurance Data Foundation application and step-by-step instructions to use this section.

Topics:

·        About Legal Entity Dimension Tables

·        About Legal Entity T2T (Result Tables) 

About Legal Entity Dimension Tables

Legal Entity Dimension table name and its description is as follows.

The mapping details for the Legal Entity Dimension table is as follows.

About Legal Entity T2T (Result Table)

Legal Entity T2T table name and its description is as follows.

The mapping details for the Legal Entity T2T is as follows.

FSI Intracompany Policy Table

This chapter details the FSI Intracompany Policy table in the Oracle Insurance Data Foundation application.

Topics:

·        About Intracompany Policy Table

·        Criteria to Qualify as an Intracompany Policy Transaction

·        Analyze Different Policy Transaction Scenarios to Qualify as an Intracompany Policy Transaction

·        Run-enabled and Non-Run-enabled Tables

·        Consolidation Procedures in the Intracompany Policy Table

·        About FSI Intracompany Policy T2T (Result Table)

About Intracompany Policy Table

The Intracompany Policy table is the Policy table that records the transactions between the legal entities of a company. In the Intracompany Policy table, to record the transactions between the companies belonging to the same group structure, the intercompany policy transactions (the policy transactions between the companies belonging to the different group structures) must be excluded.

Criteria to Qualify as an Intracompany Policy Transaction

To exclude an intercompany policy transaction from the Intracompany Policy table, the F_INTRAGROUP_EXP_IND flag is used in the Fact Common Policy Summary table. If the F_INTRAGROUP_EXP_IND flag is set to Y, it indicates that the two companies belong to the same organizational structure and the corresponding policy transactions are then included in the Intracompany Policy Entity. The remaining transactions are not considered as intracompany transactions.

Now, the policy transaction must qualify these two criteria to be included as an Intracompany Policy transaction in the Intracompany Policy table:

·        Both companies (the Policy issuing Entity and Party) must belong to the same organization group structure.

·        The Party must be a Beneficiary of the Policy.

When the two criteria are met by a policy transaction, only then in the Fact Common Policy Summary table, the F_INTRAGROUP_EXP_IND flag is set to Y; and the policy transaction is added as a record in the FSI_INTRA_COMPANY_POLICY table.

Analyze Different Policy Transaction Scenarios to Qualify as an Intracompany Policy Transaction

There are different scenarios to analyze a policy transaction between two companies. This analysis decides whether the policy transaction qualifies as an Intracompany Policy transaction.

The policy transaction scenarios are explained using these tables:

·        Life Insurance Contracts table:

§       Stage Life Insurance Contracts (STG_LIFE_INS_CONTRACTS): This table consists of the Policy issuing Entity and the issued Policy ID.

§       Fact Common Policy Summary (FCT_COMMON_POLICY_SUMMARY): This table consists of the Policy issuing Entity, issued Policy ID, and the Intracompany Policy Flag.

·        Party Insurance Policy Role Map (FCT_PARTY_INS_POLICY_ROLE_MAP): This table consists of the list of Parties mapped to the issued Policy as a Party Role (Beneficiary, Agent, Underwriter, and so on).

·        Organization Structure Dimension (DIM_ORG_STRUCTURE): This table is used to determine whether the Policy issuing Entity and its Party have the same Parent or the same organization group structure. When the Policy issuing Entity and its Party are a part of the same organization group structure, it is called as Intracompany.

The policy transaction scenarios are as follows:

·        Scenario 1: When the Policy issuing Entity and its Party belongs to the same organization group structure, and the Party Role is a Beneficiary, then the Intracompany Policy flag is set to Y.

Figure 78: Policy Transaction scenario 1

In illustration Scenario 1, observe the following:

a.     In the Stage Life Insurance Contracts table, refer to Policy1. A is the Policy issuing Entity, which owns Policy1.

b.     Verify whether the Party associated with the Policy1 is a Beneficiary or not. Refer to the Party Insurance Policy Role Map table. The V_PARTY_INSURANCE_POLICY_ROLE column lists the Party Roles associated with Policy1. Two Party Roles are associated with Policy1, namely, A1 and B1. A1 is a Beneficiary, however, B1 is an Underwriter as depicted in the V_PARTY_INSURANCE_POLICY_ROLE column.

c.     Refer to the DIM_ORG_STRUCTURE table to see if the Beneficiary and the Policy issuing Entity are a part of the same organization group structure. As highlighted in the illustration, A1 associated with the Beneficiary and the Entity A is a part of the same organization group structure. Therefore, the Intracompany group structure flag is set to Y.

d.     Therefore, in the Fact Common Policy Summary table, the Intracompany Policy Flag (F_INTRAGROUP_EXP_IND) column value is set to Y.

Therefore, this Policy contract between these two companies is included in the Intracompany Policy table.

·        Scenario 2: When the Policy issuing Entity and its Party belongs to the same organization group structure, and the Party Role is not a Beneficiary, then the Intracompany Policy flag is set to N.

Figure 79: Policy Transaction scenario 2

In illustration Scenario 2, observe the following:

a.     In the Stage Life Insurance Contracts table, refer to Policy1. A is the Policy issuing Entity, which owns Policy1.

b.     Verify whether the Party associated with the Policy1 is a Beneficiary or not. Refer to the Party Insurance Policy Role Map table. The V_PARTY_INSURANCE_POLICY_ROLE column lists the Party Roles associated with Policy1. Two Party Roles are associated with Policy1, namely, A1 and B1. A1 is a Beneficiary, however, B1 is an Underwriter as depicted in the V_PARTY_INSURANCE_POLICY_ROLE column.

c.     Refer to the DIM_ORG_STRUCTURE table. The Party B1 and Entity A are a part of the same organization group structure. Therefore, the Intracompany group structure flag is set to Y.

d.     However, the Party Role is an Underwriter. As a result, in the Fact Common Policy Summary table, the Intracompany Policy Flag (F_INTRAGROUP_EXP_IND) column value is set to N.

Therefore, the Policy transactions between these two companies are excluded from the Intracompany Policy table.

·        Scenario 3: When the Party Role is a Beneficiary, and the Policy issuing Entity and its Party belongs to different organization group structures, then the Intracompany Policy flag is set to N.

Figure 80: Policy Transaction scenario 3

In illustration Scenario 3, observe the following:

a.     In the Stage Life Insurance Contracts table, refer to Policy2. B is the Policy issuing Entity, which owns Policy2.

b.     Verify whether the Party associated with the Policy2 is a Beneficiary or not. Refer to the Party Insurance Policy Role Map table. The V_PARTY_INSURANCE_POLICY_ROLE column lists the Party Roles associated with Policy2. Two Party Roles are associated with Policy2, namely, C1 and C2. C1 is an Agent and C2 is a Beneficiary as depicted in the V_PARTY_INSURANCE_POLICY_ROLE column.

c.     Refer to the DIM_ORG_STRUCTURE table to see if the Beneficiary and the Policy issuing Entity are a part of the same organization group structure. As highlighted in the illustration, C2 associated with the Beneficiary and Entity B are a part of the different organization group structures. Therefore, the Intracompany group structure flag is set to N.

d.     Therefore, in the Fact Common Policy Summary table, the Intracompany Policy Flag (F_INTRAGROUP_EXP_IND) column value is set to N.

The Policy transactions between these two companies are not intracompany and therefore, not added to the Intracompany Policy table.

Run-enabled and Non-Run-enabled Tables

These are the descriptions for the Run-enabled and Non-Run-enabled tables:

·        Run-enabled tables: The Oracle Insurance Data Foundation Execution Run can be executed any number of times per day with each unique Run SKey for data movement in the Run-enabled tables.

·        Non-Run-enabled tables: The Oracle Insurance Data Foundation Sourced Run can be executed once per day for Data Movement from Staging Area to Results Area for Non-Run SKey tables.

NOTE:   

The records that enter the FSI_INTRA_COMPANY_POLICY table must not be entered into any other Run-enabled tables. The process mentioned for the Intracompany identification and consolidation will not be as expected unless processing or reporting application refers and reflect the same as required in the application-specific metadata. The same principle also applies to customized metadata.

Consolidation Procedures in the Intracompany Policy Table

The supported Consolidation procedures applicable to the Intracompany Policy tables are as follows:

·        Simple Aggregation

·        Full Consolidation

·        Proportionate Consolidation

This is a use case representation for the Consolidation procedure types:

Figure 81: Use case for the Consolidation procedure types

The pictorial representation is explained in the following sections.

Simple Aggregation

In a Simple Aggregation consolidation procedure, all the account transactions in an entity are aggregated. The entity can be a Parent or Child.

The following logic is used for a Simple Aggregation consolidation procedure:

1.     Identify the list of entities to be added based on the organization structure.

In the illustration, see the DIM_ORG_STRUCTURE table. For the consolidation of Entity A, the child entities are A, B, C, D, and E. 

2.     Aggregate both the Accounts and the General Ledger transactions. The aggregation of the General Ledger transactions is the addition of General Ledgers of the entities in the list.

In the illustration, see the Stage Life Insurance Contracts or Fact Common Policy Summary table and the Sum Insured column. Add the Sum Insured amount of the entities A, B, C, D, and E. The total amount is 15000 for the Simple Aggregation in Entity A.

3.     This process does not identify intragroup transactions. As a result, intragroup transactions are also included.

Full Consolidation

In a Full Consolidation procedure, all the account transactions in an entity are aggregated and the Intergroup transactions are eliminated. This is repeated for each entity involved and the results are added.

The following logic is used for a Full Consolidation procedure:

1.     Identify the list of entities to be added based on the organization structure. 

In the illustration, see the DIM_ORG_STRUCTURE table. For the consolidation of Entity A, the child entities are A, B, C, D, and E.

2.     Aggregate both the Accounts and the General Ledger transactions.

In the illustration, see the Stage Life Insurance Contracts or Fact Common Policy Summary table and the Sum Insured column. Add the Sum Insured amount of the entities A, B, C, D, and E. The total amount is 15000.

3.     Exclude all the Intragroup transactions.

In the illustration, see the FSI Intracompany Policies table. The transaction between the entities A and A1 is considered as an intragroup transaction. Therefore, exclude the Sum Insured of Entity A (Sum Insured=1000) from the total amount. The new total amount is 14000 for Full Consolidation in Entity A.

4.     Repeat steps 2 and 3 for each entity.

Proportionate Consolidation

In a Proportionate Consolidation procedure, the account transactions for each Entity (performing Simple Aggregation) are added. To this, the share of profits and expenses in the Entity, where the entity holds the stake are added. Then the Intergroup transactions are eliminated.

The following logic is used for a Proportionate Consolidation procedure:

1.     Identify the list of entities to be added based on the organization structure.

In the illustration, see the DIM_ORG_STRUCTURE table. For the consolidation of Entity A, the child entities are A, B, C, D, and E.

2.     When one entity holds a stake in another entity, follow these steps:

§       When the Balance Sheet is prepared for the Parent entity, follow these steps:

i.       Multiply each of the Account and the General Ledger transaction with the percentage that the Parent entity holds as a stake in the Child entity.

In the illustration, see the Shareholding Percentage of Entity ID table. Entity A holds a 100% stake in A, B, C, and D, and a 50% stake in E. Therefore, the resultant amounts are 1000, 2000, 3000, 4000, and 2500 respectively.

ii.     Aggregate the Accounts and the General Ledger transaction results from the previous step.

The summation of the amount from the previous step is 12500.

§       When the Balance Sheet is prepared for the Child entity, follow these steps:

i.       Multiply each of the Account and the General Ledger transaction with the percentage that the Child entity holds as a stake in its own company.

ii.     Aggregate the Accounts and the General Ledger transaction results from the previous step.

3.     Exclude all the intragroup transactions.

In the illustration, see the FSI Intracompany Policies table. The transaction between the entities A and A1 is considered as an intragroup transaction. Therefore, exclude the Sum Insured of Entity A (Sum Insured=1000) from the amount in the previous step. The new total amount is 11500 for the Proportionate Consolidation in Entity A.

About FSI Intracompany Policy T2T (Result Table)

The FSI Intracompany Policy T2T and its description are as follows.

The T2T mapping details for the FSI Intracompany Policy are as follows.

Populating Legal Entity Tables

This section provides information about populating the Legal Entity tables.

Deploying Legal Entity Tables on Hive

All RDBMS related Result tables can also be deployed on Hive (Stage and Results). Deploy the Hive T2Ts using the Rules Run Framework. For more information, see the Rules Run Framework section in the Oracle Financial Services Advanced Analytical Applications Infrastructure User Guide Release 8.1.2.0.0.

NOTE:   

In general, Stage and Result tables are also supported in Hive. However, there are some exceptions. For a list of tables that are not supported in Hive, see List of Unsupported T2Ts

Populating Legal Entity Dimension Tables

Follow this SCD process to populate data into a Dimension table:

NOTE:   

You can also follow this SCD process to populate data into any Hive-related Dimension table.

1.     To populate data into a Dimension table, execute the SCD batch. For a detailed procedure, see the Slowly Changing Dimension (SCD) Process.

2.     To check the SCD batch execution status of a Dimension table, follow the procedure Check the Execution Status of the SCD Batch.

3.     To verify log files, and check the error messages (if any), follow the procedure Verify Log Files and Check Error Messages.

Populating Legal Entity T2T Result Table

Follow this T2T process to populate data into any T2T Result table:

NOTE:   

Only RDBMS T2Ts can be executed using the PMF.

1.     To populate data into any T2T Result table, execute the PMF process for that T2T. For a detailed procedure, see the following sections:

a.     Prerequisites for loading T2T.

b.     Select the Run Parameters and Execute the Run.

2.     To check the T2T execution status and verify the log files of any Result table, follow the procedure in the Verify the Run Execution section.

3.     To check the error messages, if any, follow the procedure in the Check Error Messages section.

Populating FSI Intracompany Tables

This section provides information about populating the FSI Intracompany tables.

Deploying FSI Intracompany Policy Table on Hive

All RDBMS related Result tables can also be deployed on Hive (Stage and Results). Deploy the Hive T2Ts using the Rules Run Framework. For more information, see the Rules Run Framework section in the Oracle Financial Services Advanced Analytical Applications Infrastructure User Guide Release 8.1.2.0.0.

NOTE:   

In general, Stage and Result tables are also supported in Hive. However, there are some exceptions. For a list of tables that are not supported in Hive, see List of Unsupported T2Ts

Populating FSI Intracompany Policy T2T Result Table

Follow this T2T process to populate data into any T2T Result table:

NOTE:   

Only RDBMS T2Ts can be executed using the PMF.

1.     To populate data into any T2T Result table, execute the PMF process for that T2T. For a detailed procedure, see the following sections:

a.     Prerequisites for loading T2T.

b.     Select the Run Parameters and Execute the Run.

2.     To check the T2T execution status and verify the log files of any Result table, follow the procedure in the Verify the Run Execution section.

3.     To check the error messages, if any, follow the procedure in the Check Error Messages section.