Custom fields are an extension of the PACE data model. Use custom fields to manipulate database field attributes when you create new fields. Custom fields are different than regular or database field attributes, which reference specific columns in the database.
...
On this page
| Table of Contents | ||
|---|---|---|
|
Click String.
You see the String drop-down menu.
Select the string type.
To evaluate the last letters in a value, use the right string. For use with substrings, you have to populate a start position and the number of letters to extract for the word part. For example, if you are looking for the value “Consumer Cyclicals,” you may evaluate for the word part “Cyc” by entering 10 as the start position and 3 for the number of letters to extract.
| Info |
|---|
The space between “Consumer” and “Cyclicals” is counted in determining the start position. |
Other Calculator Commands
...
Command
...
Function
...
=
...
Equal to
...
+
...
Add
...
-
...
Subtract
...
C
...
Clear
...
/
...
Divide
...
X
...
Multiply
...
.
...
Decimal
...
-
...
Negative
...
!=
...
Not equal to
...
<
...
Less than
...
>
...
Greater than
...
<=
...
Less than or equal to
...
>=
...
Greater than or equal to
...
(
...
Open parenthesis
...
)
...
Close parenthesis
...
0-9
...
Numbers
...
Check
...
Verify formula
...
AC
...
All clear
...
,
...
Comma. Separates values in a calculation.
...
In/Not In
...
Specifies the presence or absence of values. Allows multiple values using the comma. (Calculation and Inference fields only)
...
Like/Not Like
...
Specifies that the data must be like the text entered. Allows multiple values using the comma button. (Calculation and Inference fields only)
Entity Build Field Attributes
All entity build related field attributes are grouped under the Entity Build field category. These include field attributes defined as Entity Build and Advanced with a process of Entity build Position Table Columns.
Field Attributes Defined as Character Numeric
For any field attribute that is defined as character numeric, the OLAP engine converts the numeric value to a string, which retains the decimal precision before matching the value to the code value. The OLAP engine applies the field attribute’s precision, which is typically 0 for character numeric defined field attributes. Typically, you see this in ratings field attributes when adding a reference code to the Numerical Rating field.
Published Field Attributes
Published field attributes are available to additional report types. You can edit a published custom field attribute and select additional Report types from Make available to other Report types. These changes are saved in the database. You can also make published custom field attributes available to additional report types.
Field Attribute Mapping
Field attributes are mapped to report types. Field attributes with RPT_SUB_TYPE_INST values of zero in the REPORT_TYPE_FIELDS table of the Rules database are available for all subtypes of the corresponding report type value. The existence of these zero records has no impact on how reports run.
You can restrict certain field attribute types from certain report type and report component types. For example, you can make trades fields unavailable to Position reports, either by using the report rule or field rule maintenance window, or from the profile level filtering setting. This change prevents reporting scenarios that are known to cause either report failures or inconsistent report results.
Map Field Types
You can use the Map Field Types feature to make specific field attribute types available for various components of each report type. The scenarios and combinations which work correctly are scripted. You can apply tighter restrictions with this feature, disallowing specific scenarios that are mapped by default. You can allow additional combinations by mapping field type and report type combinations that are not mapped by default.
To open Map Field Types, right-click on the contents of the Fields folder on the Component tab and select Map Field Types.
This window has four main folders:
Fields. Used to select a specific custom field type, and specify which underlying field attribute types are included in it. For example, expand the Fields folder to display the list of custom field attributes. Select the Rollup Field type, and explode that folder to display the report types that can include rollup fields. Select the report type, such as positions single period, and use the Field Types check boxes in the right pane to select the field types that can be included in a rollup field created in a single period position report.
Others. Used to map field types for report types that do not fit into the typical structure of other report types. This folder contains the query tool.
Profiles. Maps field types to report types where the fields can be used in the profile-level filter feature. Because this filter feature, available in the Select Criteria tab in report profiles, is designed to be executed directly against the PACE report result set and is not as dynamic as the guideline filter feature, it is listed separately in the Map Field Types dialog box. The selections made to map field types to a report rule are not the same selections made to map field types to a report profile of the same report type.
Rules. Used to map field types to field rules, filter rules, range rules, and report rules. Expand the folder to display the rule types, and expand the Rule Type folder to display the report types that use the selected rule type. Select the check boxes to modify the map field types by selecting a report type. To restrict a field type from the selected rule and report type, deselect the check box next to that field type..
Field Type Limitations
The Cash Adjustment and Trade Adjustment custom field types have limited field types available to them by default in the Map Field Types feature. Cash Adjustment fields have only cash and security fields available in the formula editor of that field type. Trade Adjustment fields have only trade and security fields. You can override these default mappings.
Map Field Types Workflow
When you change Map Field Types settings, the change applies to all users.
If a specific field attribute was previously mapped to a report type, and that combination is later restricted by using the Map Field Types function, that field no longer appears as eligible. For example, a trades field is made available to multi period positions reports and you then use the map field types function to restrict trades fields from multi period positions report field rules. When you create a multi period positions report field rule, the Trades folder in the field attribute selector no longer appears. Those field types are no longer eligible for that component type.
If you add a trades field to a multi period positions field rule, and the map field types function is used later to restrict that combination, the trades field remains as part of the field rule created previously. Changes to the map field types settings do not impact components created and saved previously.
If a specific combination was restricted via the map field types function and you make a field attribute available to a report type that is restricted, you get a warning that you are about to map a restricted condition. You can choose to not publish the field to the restricted report type, or ignore the warning and proceed with the selected mapping. If you make the field available to more than one report type, only the restricted report types are listed in the warning message.
...
Map Field Types Database Information
The data that is maintained by the map field types feature is stored in primary tables:
Field Types. This table contains a record for each field attribute type in PACE, and drives the lists of field attribute types in the Map Field Types dialog box.
Context Types. This table contains information about each specific PACE reporting component type that is supported by the map field types feature.
The combinations that are mapped using the map field types feature are stored in two separate tables.
CONTEXT_REPORT_TYPES_FILTER. This table contains the relationships among report types and subtypes, and context types. This drives the folder structure that is displayed on the left side of the Map Field Types dialog box.
FIELD_TYPES_FILTER. This table contains the mappings among reports, contexts, and field types that are represented by the selected check boxes in the right half of the Map Field Types dialog box.
The full structure of these tables is shown in the tables that follow.
...
Field Attribute Type Table: Column
...
Description
...
INSTANCE
...
Unique record identifier.
...
FIELD_TYPE_SHORT
...
Short description of field attribute type.
...
FIELD_TYPE_LONG
...
Long description of field attribute type.
...
UPD_USER
...
The user who last updated the record.
...
UPD_DATETIME
...
Determines the last time the record was updated.
...
Component Type Table: Column
...
Description
...
INSTANCE
...
Unique record identifier.
...
CONTEXT_TYPE_SHORT
...
Short description of Reporting Context type.
...
CONTEXT_TYPE_LONG
...
Long description of Reporting Context type.
...
UPD_USER
...
The user who last updated the record.
...
UPD_DATETIME
...
Determines the last time the record was updated.
...
Field Types Filter Table in PACE Master Database: Column
...
Description
...
RPT_TYPE_INST
...
Unique record identifier.
...
RPT_SUB_TYPE_INST
...
Instance value from REPORT_SUB_TYPES table.
...
CONTEXT_INST
...
Instance value from CONTEXT_TYPES table.
...
FLD_TYPE_INST
...
Instance value from FIELD_TYPES table.
...
UPD_USER
...
The user who last updated the record.
...
UPD_DATETIME
...
Determines the last time the record was updated.
...
COLUMN_NAME
...
Not currently used.
...
Context Report Types Filter Table in PACE Master Database: Column
...
Description
...
INSTANCE
...
Unique record identifier.
...
CONTEXT_INST
...
Instance value from CONTEXT_TYPES table.
...
RPT_TYPE_INST
...
Instance value from REPORT_TYPES table.
...
RPT_SUB_TYPE_INST
...
Instance value from REPORT_SUB_TYPES table.
...
UPDATE_USER
...
The user who last updated the record.
...
UPDATE_DATE
...
Determines the last time the record was updated.
Custom Categories
You create custom categories for field attributes to determine how field attributes are displayed. You can organize the fields by indicator, database, table, or by category. You can also list the fields all in one folder in alphabetical order. Complete the following procedure to create custom categories.
...
From any Eagle window, click the Eagle Navigator button to access the Eagle Navigator.
...
Enter Codes in the Start Search text box.
...
Click the Codes(System Management Center) link to access the Codes window.
You see the Codes window.
...
From the Codes module, select the Field Category Code and add new code values. The short description holds a number and the long description holds the actual description, as follows:
Short description of 1 = Long description of “Accounting Data”
Short description of 2 = Long description of “Performance Measurement Data”
Short description of 3 = Long description of “Holdings Data”
Short description of 4 = Long description of “Security Master Data”
Short description of 5 = Long description of “Shared Data”
...
Open the Field Attributes module, under the Metadata category.
...
Assign a category to each field attribute. From the workspace, select just one grouping, or create a tree so that one grouping is designated as a main category and then one or more other categories are added as subgroups.
...
To customize the display, click Customize.
...
Select as many groupings as you want to create the grouping tree. Click OK to save your changes.
The resulting view is displayed in all other field rules until it is changed. If a field attribute is not assigned to a category, it appears under the category Unknown.
The field rule view is saved in the registry in the section HKEY_CURRENT_USER > Software > EagleSystems > Clients > EaglePACE > Settings > FieldsCtrlGroups. Category=Setting of 1, Indicator=Setting of 3, Database=Setting of 2 and Table=Setting of 4. This registry setting applies to the user.
...
Source-Specific and Relation Fields
You can run single period position reports related to source-specific fields used with Relation fields. If a single security was held long on one source and short in a second source, the positions yield two separate holdings in the reports results.
Custom Sorting on Code Value Sets
You create custom sort orders on code value data sets. This allows you to set up custom sort orders more easily based on code values and dictionary classifications. Complete the following procedure to set up a custom sort order.
In a report rule, add a field that is configured with a translation code.
Change the sort from default to custom.
Select the values in the order you want. You can reorder them at any time using drag and drop.
Click Done. Custom sorting is now set. To make changes to the order, double-click on the Custom cell.
Use the Sort column in the grouping rule to configure custom sorting for a translation code enabled field placed in a grouping rule.
Create Entity Cross Reference Fields
PACE allows you to store identifiers for how entities and clients are identified in other systems. You can include those references on any entity based PACE report.
A custom field called Entity Cross Reference allows data from the ENTITY_XREFERENCE table to be included in a PACE report. In the Entity XReference field, you can set up multiple code value sets to display varied XReference fields. For example, if you have multiple accounting systems sending data to PACE, you can create a field attribute for each entity identifier that is specific to each accounting system for display in a report.
Complete the following procedure to create Entity Cross Reference fields.
Create a new custom field attribute from the Entity XReference category. Enter a name in Name field, and any comment in the Comment field. Select 0 from the Precision drop down list.
Click Field Options and select the field options such as publishing and report mapping.
Enter a value for the Column and the Entity XReference Type.
Create an Entity Hierarchy
You can create composites of composites. When you create composites of composites, composite entities consisting of either composites or of portfolio entities are created. You can also enumerate composites. This allows you to direct the Reporting engine to look through the composites selected for a report, drilling through one composite to the underlying report composites. PACE supports the storing of hierarchy of entities as it stores the relationships between entities, which can be nested to any degree.
Entity Hierarchy functionality is supported in cash activity, cash balance, ledger activity, lot level position, position, and trade reports.
You do not have to run the entity build process for the composites on which they choose to report, they simply must include the composites in the report. You must select the option enumerate composites for the entity hierarchy functionality to work in a report.
...
Level 1: Company Level
...
Level 2: Branch Level
...
Level 3: Group Level
...
Level 4: Portfolio Level
...
Composite 1: All Composite
...
Composite 2: US Branch
...
Composite 4: US Equities
...
US Fund 1US Fund 2
...
Composite 5: US Fixed Income
...
US Fund 3US Fund 4
...
Composite 6: US Balanced
...
US Fund 1
...
Composite 3: European Branch
...
Composite 7: European Equities
...
EU Fund 1 EU Fund 2
...
Composite 8: European Fixed Income
...
EU Fund 3 EU Fund 4
Set Up the Entity Hierarchy Function
Before using Entity Hierarchy functionality, you must complete the procedure explained in this section. An internal code is added through the installation and upgrade scripts. The code has a short description of ELEVEL and a long description of IENTITY LEVEL. The code instance for this internal code is 10051. First, you must create code values to reference the level number of each composite:
Create code values under the Eagle PACE source. The code values must reflect the appropriate level. The short description is the level number. The long description is a descriptive name.
After creating the codes and code values, you create entity hierarchy fields. Return to General Reporting, and select Compose.
Select the report type you want to create.
From the Fields toolbox, select Entity Hierarchy Field.
You see the Entity Hierarchy Field dialog box.Complete the fields on the Entity Hierarchy Field dialog box as described in the following table.
...
Option
...
Description
...
Name
...
Enter a unique name.
...
Comments
...
Enter a descriptive comment.
...
Hierarchy Level
...
Select a Branch, Country, or Group hierarchy level.
...
Field Name
...
Select an Entity Field on which to base the Entity Hierarchy field.
Entity Hierarchy Fields
You create Entity Hierarchy fields based on entity fields from the Entity Table or on fields from the Entity Extension tables. You cannot create Entity Hierarchy fields based on fields from the Entity Characteristics table of the Rules database.
The Entity Hierarchy Custom fields can work with fields from the scrub tables, specifically, fields created on columns in the inventory of fields, from tables where the table was added to the inventory of tables with an indicator of ”e” is available.
The entity fields that appear in the Entity Hierarchy Field dialog box are those entity fields that were made available to that report type. Therefore, you might see certain fields while creating an entity hierarchy field for a position single period report that you would not see when creating an entity hierarchy field for a trades multi period report. Using the example above, an entity hierarchy field could be created using the Entity field of Entity ID, and assigning the hierarchy level of one.
You can use Entity Hierarchy fields in a field rule, although they lose much of their meaning in this position. You must create rollup fields of the field attributes in the field rule to see data for the composites at the top level. In the option Choose Entities and Dates, select Enumerate Composites.
You can run the report for the lowest or highest level of the hierarchy. The data returned is based on which entities the report is run. If you run the report for a portfolio, and the entity hierarchy fields are included in the report, then that entity hierarchy relationship is displayed in the result set.
...
The above example shows the entity hierarchy fields used to group the report. The top level of the report is the Company Entity ID, next is the Branch Entity ID, followed by the last level of composite, the Group Entity ID. Finally, you can drill down to the Entity ID of the portfolio and to the security level. You can see values returned at the composite level because there are rollup sums on the field attributes. The Entity Build process was not run for these composites.
Hierarchy Assumptions
If a fund (portfolio) is held by more than one composite, the data for the fund is duplicated for each relationship it has with other entities. For example, in Figure 119 on page 131, if US Fund 1 belonged to both US Equities and US Balanced the data for US Fund 1 would be displayed twice in the report.
The level numbers are relative to the funds for which the report is being run. In the Entity Hierarchy Grouping example above, if a report is run for US Branch and composites are enumerated, then the report is run for US Fund 1, US Fund 2, US Fund 3 and US Fund 4.
If a relationship chain has funds that are not in the list of funds used to run the report, then those relationship chains would be filtered out and not displayed in the report. In the Entity Hierarchy Grouping example above, if the report is run for US Equities, which contains US Fund 1, then the report does not display US Balanced, although US Fund 1 does also belong to US Balanced.
If relationship information does not exist on a particular level, then the relationship information is labeled Unknown.
This functionality does not support fetching details from the Entity Details table, such as percent of ownership and is intended only for composites.
Entity hierarchy fields are used as the grouping rule.
The option Enumerate Composites is selected.
Hierarchy Scenarios
The following table contains an example of hierarchy Entity IDs.
...
Level 1: Country
...
Level 2: Branch
...
Level 3: Group
...
Portfolio Level: Entity ID
...
Composite 1: EPDC1
...
Composite 2: EPDB1
...
Composite 4: EPDG1
...
Portfolio 1: EPDP1Portfolio 2: EPDP2
...
Composite 5: EPDG2
...
Portfolio 3: EPDP3Portfolio 4: EPDP4
...
Composite 3: EPDB2
...
Composite 6: EPDG3
...
Portfolio 5: EPDP5Portfolio 6: EPDP6
Hierarchy Reports
For all of the following example reports, the Enumerate Composites option is on. The only items that change in these examples are the entities for which the report is run. All of the appropriate fields in the field rule were rolled up to show data at the composite level. The entity build process was not run for these composites. The reports are set up as shown below.
...
This example shows a report run for EPDC1. This report receives data for EPDC1, EPDB1, EPDG1, EPDP1, EPDP2, EPDG2, EPDP3, EPDP4, EPDB2, EPDG3, EPDP5, and EPDP6. The Company Level is Company Entity ID, the Branch Level is Branch Entity Id, and the Group Level is Group Entity ID.
...
This example shows a report run for EPDG1. This report receives data for EPDC1, EPDB1, EPDG1, EPDP1, and EPDP2.
...
This example shows a report run for EPDP1. This report receives data for EPDC1, EPDB1, EPDG1, and EPDP1.
...
Other examples result in the following:
...
Run a report for EPDB2 – This report receives data for EPDC1, EPDB2, EPDG3, EPDP5, and EPDP6.
...
Run a report for EPDG2 – This report receives data for EPDC1, EPDB1, EPDG2, EPDP3, and EPDP4.
...
Run a report for EPDG3 – This report receives data for EPDC1, EPDB2, EPDG3, EPDP5, and EPDP6.
...
Run a report for EPDP1, EPDP2, EPDP3, EPDP4, EPDP5, and EPDP6 – This report receives data for EPDC1, EPDB1, EPDG1, EPDP1, EPDP2, EPDG2, EPDP3, EPDP4, EPDB2, EPDG3, EPDP5, and EPDP6.
...
Refer to the following sections for more information: