ほとんどの組織は、業務カレンダまたはレポート・カレンダと一致する循環基準でOracle Data Relationship Managementを使用します。各カレンダ期間内では、Data Relationship Managementは予測可能なパターンに従って使用されます。
Data Relationship Managementの新規の「処理中」バージョンが以前の期間の「ファイナライズ済」バージョンのコピーとして作成されます。新規バージョンには、複数の階層(勘定体系、組織構造および製品構造用など)が含まれる場合があります。
「処理中」バージョンに対する変更が行われます。ユーザーが階層データを入力または変更する際に検証が自動的に実行されます。
必要に応じて、アクション・スクリプトを使用して階層データのバルク変更が実行されます。
レポート期間の最終期限の間際に、バージョン・ステータスが「送信済」に変更され、これ以上の変更は許可されなくなります。データの整合性を確保するために検証が実行されます。比較を使用して、現在のバージョンと以前の「ファイナライズ済」バージョン間の差異を識別できます。
データの整合性が確保されると、バージョン・ステータスが「ファイナライズ済」に変更され、これ以上の変更は許可されなくなります。
以前のレポート期間のバージョン・ステータスは「ファイナライズ済」から「期限切れ」に変更されている場合があり、バージョンは将来的に履歴分析で使用されたり監査レコードとして使用される可能性があるために格納されます。
階層データを参加システムに送信するために「ファイナライズ済」バージョンからのエクスポートが実行されます。すべてのエクスポートが完了し、宛先システムにロードされた後、期末のレポート・プロセスの基準となる一貫した階層データがすべての参加システムに行き渡ります。
Data Relationship Managementによって既存の組織ワークフロー制約を適用できます。
ビジネス・ルールにより、企業の財務部が新規コスト・センターをすべて承認する必要がある場合があります。この場合、承認を示すプロパティを追加し、プロパティが承認済に変更されるまではノードを他のシステムにエクスポートできないようにすることができます。企業の財務部には、インジケータ・プロパティのみを更新するアクセス権を付与できます。プロパティ問合せを定義してインジケータ・ノードを識別することもできます。
ビジネス・プロセスにより、すべての階層の更新を、このような更新の実装を担当する専用グループにリダイレクトする必要がある場合があります。レビューと承認の後、アクション・スクリプトを介してData Relationship Managementへバルク・ロードするために変更をフラット・ファイルに入力できます。この自動方式により、潜在的な入力エラーを大幅に軽減できます。
複数のユーザー入力の調整や変更のコミット前の承認が含まれるより複雑なビジネス・プロセスは、変更要求を使用して処理できます。
不定期に実行されるその他のタスク:
参加システムの範囲内における拡張をサポートするための新規階層を確立できます。階層を外部ソースからインポートしたり、Data Relationship Management内で階層を直接作成できます。
変化するビジネス上のニーズに対応するために階層の再構築が必要な場合があります。個別バージョンを使用して、サブスクライブ・システムへのエクスポート用として使用される他の製品バージョンからこれらの変更を分離できます。
ブレンダ機能を使用すると、様々なバージョンで新しくインポートまたは再構築されたデータを他の既存の本番データとともに同じバージョンに結合できます。