Data Relationship Management Version Life Cycle

Most organizations use Oracle Data Relationship Management on a cyclical basis that matches their operational or reporting calendar. Within each calendar period, the use of Data Relationship Management follows a predictable pattern:

1. A new Data Relationship Management Working version is created as a copy of the Finalized version from the previous period. The new version may contain multiple hierarchies (for example, for the chart of accounts, the organization structure, and the product structure).

2. Changes are made to the Working version. Validations are automatically performed as users enter or modify hierarchy data.

3. If necessary, bulk changes to hierarchy data are performed using Action Scripts.

4. Near the reporting period deadline, the version status is changed to Submitted and changes are no longer permitted. Validations are performed to ensure the integrity of the data. Compares can be used to identify differences between the current version and the previous Finalized version.

5. When data integrity is assured, the version status is changed to Finalized and no further changes are permitted.

6. The version status for the previous reporting period may be changed from Finalized to Expired, and the version is stored for possible future use in historical analyses or as an audit record.

7. Exports are performed from the Finalized version to send hierarchy data to participating systems. After all exports are complete and have been loaded to the destination systems, all participating systems have consistent hierarchical data as a basis for the period end reporting process.

Existing organizational workflow constraints can be enforced by Data Relationship Management:

• Business rules might require that all new cost centers be approved by Corporate Treasury. In this case, a property can be added to indicate approval, and no nodes are exported to other systems until the property is changed to approved. Corporate Treasury can be granted access to update only the indicator property. A property query can also be defined to identify indicator nodes.

• Business processes might require that all hierarchy updates be redirected to a dedicated group responsible for implementing such updates. Following review and approval, changes can be entered into a flat file for bulk loading via Action Scripts into Data Relationship Management. This automated approach can significantly reduce potential typing errors.

• More complex business processes that involve the coordination of multiple user inputs and approval before committing changes can be handled using change requests.

Other tasks that are performed on an irregular basis:

• New hierarchies can be established to support an expansion in scope of the participating systems. Hierarchies can be imported from an external source or can be directly created within Data Relationship Management.

• Hierarchies may need to be restructured to comply with changing business needs. Separate versions can be used to isolate these modifications from other production versions used for exporting to subscribing systems.

• Using the Blender feature, newly imported or restructured data in different versions can be combined into the same version with other existing production data.