Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 6 Current »

You specify a date rule in the Date Rules section of the Data Mart Model Submission window.

Dates in a date rule are relative dates, not absolute dates. These rules contain begin and end dates the PACE Concentration Engines use to calculate values. These values depend on the dates selected in the As Of section of the Data Mart Model Submission dialog box. Only the end date of a date rule is used for holdings, lot, ledger, and performance data. Both begin and end dates are used for cash flows and transactions data. For example, you can store yesterday's market value with the prior month end's performance returns, effective for yesterday's date. You configure yesterday's date in the As Of section. You use a current date rule for holdings and a prior month end rule for performance in the Ad hoc field of the Date Rules section.

There are several options for date rule selection. You can choose a single rule in the Ad hoc field. As Of dates are passed through date rules to determine effective dates for populating tables. For the current date rule, the As Of date and effective date are the same. However, such rules as 2 quarters back might operate on an As Of date of March 15, 2013 to produce an effective date of September 30, 2012.

You can also choose a previously set up date rule for one of your Mart schedules. Or choose a different rule for each Mart detail data type. You can select any date rule configured in PACE from the drop-down menu.

To populate your Position Details table with Cash Adjustment or Trade Adjustment fields, submit the Position Details model using a different ad hoc submit or schedule from the one that submits your Cash Flow Details and Trade Details tables. To calculate Cash Adjustment or Trade Adjustment fields in the Position Details table, use a date rule with a "from" date that differs from the "to" date. Data Mart sums all cash events or trades between those two dates to calculate total activity for the period as of the single effective date of the submit (the end of the period).

If you use this type of date rule with Cash Flow Details or Trade Details fields, Data Mart produces a row in the tables for every cash event or trade that occurs between the two dates. All rows will share the single effective date of the submit. This approach, applied day after day, produces increasing numbers of copies of the same cash events and trades. Eagle does not recommend this approach.

A better approach for daily use is to use a separate scheduled submission with its own single-date date rules to build cash flow details and trade details data one day at a time. Each day's data will have its own effective date. The need for a different type of date rule requires the use of a separate submit.

The Preliminary versus Final status indication and management process does not apply to the Business Dates table, or the Security Details and Issuer Details tables. These status flags, along with additional Data Mart status flags which support further granularity when describing the status of data built in the Data Mart, are established in the Fund Master table and are associated with the overall dmart_fund_id instance of entity-related Data Mart tables. Those tables like Business Dates that are not linked to particular entities do not have a Status indicator.

For more information on Status Flags, refer to Manage Mart Data Status.

About Build Selective Fields

The Build Selective Fields option has a number of significant benefits, such as selective back-filling. For example, when you add one or more new fields to a model that you have been populating for a while, you can use this option to populate values for the new fields only. Otherwise, you have to submit the model to populate every field of each row. When you re-populate fields that already have data values, the values are deleted and re-generated. This can lead to an unintended restatement of reported data values. Selective back-filling is faster than populating all of the model's fields and it avoids the unintended restatement of reported data values.

  • No labels