Skip to content

Introduction to the Process Data Model

Background

In the process settings, the Process Data Model (PDM) defines a subset of accounts or accounts/categories on which to collect, submit and process the data. The PDM is based on accounts and categories, and so these structures must already be set up in CCH Tagetik’s dimensions.

Elements of the Process Data Model

The Process Data Model is based on the following elements:

  • accounts, or the subject of data collation
  • steps of the process on which to collect account data
  • categories containing the classification and segmentation of the data on accounts
  • measures, or custom dataset fields
  • the process’s data model, or the accounts/categories involved in data collection, specific behaviour and exceptions that govern the entry of data on the process.

Process Data Model definition

Setting up the process’s data model involves defining the following elements:

  • Accounts or accounts/categories that collect/do not collect data on the process (e.g. if you want to exclude accounts included in a certain node of accounts).
  • The editability rights of accounts on specific types of data and on the categories associated with them, when they need to be different from the default behaviours.
  • The steps on which to set, for example, any blocks on intercompany declarations for specific accounts not belonging to intercompany matching cockpits.
  • The control groups included in the process and those excluded from it, from among those that the system automatically relates to the process during its deployment.
  • Any custom Analytical Workspace measures to be included in the process.

Default PDM and custom data models

A default PDM, called $PDM, is related to every process. If the default PDM does not fully meet the functional needs of the project, custom PDMs can be created. In particular, this is useful for associating subgroups of accounts with specific entities/entities and consolidation scenarios/periods.

Process Data Model organisation

The order in which PDMs are inserted determines the order in which they are run within the system. If there are general PDMs and PDMs with exceptions and overrides, the order in which the PDMs is created must go from the most generic to the most specific because, if the data processing of a generic PDM follows that of a specific PDM, the rules of the specific PDM may be overwritten.

If several PDMs are managing different accounts, it is advisable to set up a custom PDM by account, rather than make changes to the $PDM.