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 2 Next »

Some notes about audit logging follow:

  • There are no PACE OLAP reports or Query Tool views that interact with these tables. However, the tables are supported through Advanced Reporting.
  • Clients should note that, due to the optional nature of this function, there is some configuration work necessary to use this function.
  • Use of this function could result in the writing of a large volume of data and storage of that data in the database. Clients are encouraged to consider return audit requirements, internal data retention policies, and database sizing prior to enabling the audit logging function.
  • Eagle PACE has a data archive tool that can be used to manage the size of the tables. Due to the fact that each client has unique policies regarding data retention, Eagle does not provide a standard archiving rule for this information.
  • If enabled, the audit logging process takes place regardless of the setting for error logging. This means that you can use audit logging with the error logging set to production levels (that is, you do not have to set error logging to level 10 to get the full audit details). Conversely, you cannot control the audit logging process by altering the log levels. This is by design.
  • This function tracks all data processed by the dynamic mutual fund engine. This means that, if a fund has daily records (as is required typically to operate the system), the process tracks the audit records daily. There are no filtering options at this time. For example, a user cannot configure this feature to log audit data only on a month end or distribution date basis.
  • Be aware that this process writes a significant amount of data. The process also deletes and rewrites (refreshes) records if a user reruns an analysis for the same fund and date combination. Optimal processing can be achieved with shortterm audits analyzed on a semi frequent basis.
  • For example, you can log and analyze a 1-month return every month as a test for potential issues. This results in 31 days of data per fund, per month. This is contrasted with a suboptimal practice (for example) of logging a 10-year return every day. This could result in the logging of 36,500 audit records every day for every fund. While this practice is certainly supported (you can enable audit logging for any return period) it is not recommended as a best practice. Some best practices might include:
  • Run a 6-month analysis at month end for any fund that hits its fiscal midyear. For example, if there are several funds with a FYE of September 30, their fiscal midyear is March 31. On March 31, run a 6-month analysis for all September FYE funds.
  • Run a 12-month analysis at month end for any fund that has a fiscal year-end that month.
  • If auditors require proof for a long-term period (such as a 10-year audit), run an ad hoc analysis for the sole fund for which an analysis is needed.
  • If a vast majority of funds have the same fiscal year-end, consider doing a year-to-date analysis at each quarter-end.
  • The Audit Daily fields can be used with standard dynamic mutual fund fields. (A report can have both types of fields.) Although both fields display a return in the report, only the audit fields log time-series data.
  • You can have more than one Audit Daily field in a Performance Analysis report.
  • The audit daily fields support the various return options on that field type (such as pre tax and post tax, and loads and redemption fees). In addition, they work in conjunction with the price-type overrides.
  • When you create a Dynamic Mutual Fund Returns field with a Category of Audit Daily or Audit Summary, the field does not support the Gross (Use Ratio) and Net Waiver (Use Ratio) processing options.
  • No labels