Page Comparison

This section describes at a high level how the Entity Build process generates data for derived entities. 

About Entity Build Fields

The entity build process involves defining Entity Build fields. Entity Build fields must be built for each field that may be included in a report.

For example, a Quantity field is used in reports. How is this field calculated for a composite?

You would create an Entity Build field called Quantity and define it as a Sum. When the Entity Build process is run, all of the Entity Build fields are calculated. The Quantity Entity Build field would sum the quantity fields from each of the portfolios within the entity to create a new number. When the Quantity field is added to the report, and a Composite entity is included in the report, it retrieves the information based on the value in that Quantity Entity Build field.

In addition to Sum, Entity Build fields may also be calculated using an aggregation of Average or Weighted Average. The Sum aggregation is commonly used on fields such as Market Value, Quantity, Par Value, and Accrued Interest. The Weighted Average aggregation is commonly used on fields such as Unit Cost Value, Rate, and Yield. The Average aggregation is also available, although it is not widely used.

Review the following important guidelines so that the Entity Build Process is done correctly:

• You must have Entity Build Field Attributes (EBFAs) to build an Entity. At least one EBFA must exist to begin the build process.
• Normally, you build records in the POSITION_DETAIL table, but you may use other tables. For Sub-Porfolios that you configure to additionally build cash activity, the process builds records to the CASH_ACTIVITY table. 
• Only build EBFAs that are numerical; the result is an Average, Weighted Average, or Sum.
• Do not build off of fields like indexing records, such as POSITION_DETAIL_ID or CASH INT (if the build is for Sub-Portfolios that include cash).

For general information, see "Working with Entity Build Field Attributes" in the General Reporting Reference Guide. 

In summary, the Uploader loads the data into the Position, Position Detail, CASH_ACTIVITY tables for the portfolios. Then the entity build process creates the Position and Position Detail records for the Composites, Aggregates, and Sub-portfolios. It can also generate cash activity records for the sub-portfolios. These numbers are pre-calculated and ready to use in reports. Thus the Entity Build fields should be built based on the reporting needs, although this is, of course, based on what is available from the fields that are populated by the Uploader.

About the Entity Build Flag for Entities

The Entity Build Flag determines how to handle cases in which one fund does not have available data for a particular date. You can allow or prevent builds based on partial data. 

For example, a composite contains three portfolios: Portfolio A, Portfolio B, and Portfolio C. During a particular upload, Portfolios A and B have data for that effective date, but Portfolio C does not. The Entity Build Flag provides you with two choices. The composite for that effective date can be built without Portfolio C, or the composite is not created for that date at all.

The Entity Build Flag field is set up in the Inventory of Fields. Assuming that you add it within the field group for the respective policy, you can access it from Portfolio Data Center in the entity's Entity Details section during the setup or editing of an entity. If a value of Y or NULL is present in this field, then the composite is built with the available portfolios. If a value of N is present in this field, then the composite is not built. 

About the Entity Build Mode of Process System Parameter

An example of Derived Entities is a Composite made up of another Composite. The Entity Build engine expects underlying entity data to exist. Therefore, it is up to you to run the Entity Builds in the correct order to ensure the underlying Composites were built before building the highest level of Composites.

For example:

If COMP A is composed of COMP B, and COMP B is composed of PORT 1 and PORT 2, then you must run the Entity Build for COMP B before you can run it for COMP A.

The Entity Build engine enables you to manage this process. It provides greater ease of use as the structure of an entity universe increases in complexity (COMPS of COMPS of COMPS, and so on). Using the previous example, submitting the build for COMP A builds automatically COMP B in the process.

The system enables you to control the mode in which the Entity Build operates. The control is set at the environment level as a System Parameter. The sys_item for the Entity Build Mode of process is 71 and it is stored in the PACE_SYSTEM table.

If you set the entry to 1, it automatically rebuilds underlying entities. If you set the entry to 0, it does not rebuild underlying entities and just uses the data that already exists for the underlying entities. By default, upgrades of Eagle's data management solution default the value to 1 in order to ensure the engine works as it is currently designed. For more information, see and Manage System Parameters.

About Entity Build Engine Optimizations

The system optimizes the Entity Build engine processing time in two ways:

• Reduces the number of connections used by the engine. This reduces any extra connections used by the engine when querying for information relevant to the build processes such as entity build attribute details, entity and entity detail information,, and holdings data. Connection reduction allows for additional Data Management processing to use available connections across the system.
• Generate a single query for the retrieval of position detail data for all underlying constituent entities of a given entity being built. This ensures that only one query is used to select holdings data across all three entities.