核准原則範例

下列範例說明應用程式、維度、節點類型和階層集層級的核准原則，並示範如何使用各種原則設定值來處理核准。

範例 1：應用程式層級核准原則

首先，請審視一個簡單的範例，其中顯示核准如何根據基本層級來運作。在此範例中，有一個應用程式層級的核准原則指出至少要有兩位「總帳控管」群組的人員必須核准會計科目表的所有變更。

表格 25-1 範例 1：應用程式層級原則設定值

Fusion GL 應用程式 維度 節點類型 階層集
原則 A
  • 核准群組：總帳控管
  • 方法：平行
  • 必要的總計：2 個核准者
 科目維度 「科目」節點類型 「科目」階層集

「總帳控管」群組由 Barry、Julie 和 Jane 組成。Tom 是 Fusion GL 應用程式的擁有者。

核准工作流程：

  1. Mark 提交新增科目和更新成本中心描述的要求。
  2. 由於是平行核准方法，因此要求會被傳送給「總帳控管」群組的所有三位成員進行核准。
  3. Julie 核准要求。
  4. Barry 核准要求。
  5. 由於符合原則需求，因此要求被確定。

範例 2：死結呈報

現在，我們要再度審視同一個範例，不過，Barry 和 Jane 目前已經調離「總帳控管」群組。

表格 25-2 範例 2：死結呈報原則設定值

Fusion GL 應用程式 維度 節點類型 階層集
原則 A
  • 核准群組：總帳控管
  • 方法：平行
  • 必要的總計：2 個核准者
 科目維度 「科目」節點類型 「科目」階層集

「總帳控管」群組只由 Julie 組成。Tom 是 Fusion GL 應用程式的擁有者。

核准工作流程：

  1. Mark 提交新增科目和更新成本中心描述的要求。
  2. 核准要求傳送給 Julie。
  3. Julie 核准要求。

    雖然原則要求「總帳控管」群組的兩位核准者，但 Julie 是該群組的唯一人員。由於沒有更多的核准者以符合原則需求，因此導致死結。結果，要求被呈報給具有應用程式的資料管理員 權限的使用者。由於 Tom 是應用程式的擁有者，因此他的擁有者 權限包含資料管理員 權限。

  4. 要求被呈報給 Tom。
  5. Tom 核准要求。
  6. 由於符合原則需求，因此要求被確定。

範例 3：維度層級循序核准原則

接下來，我們要審視維度層級的循序類型原則。在此範例中，Josh 必須核准要求，接著是 Frank 核准要求，最後是「會計」群組的某個人員核准要求。

表格 25-3 範例 3：維度層級循序原則設定值

應用程式 維度 節點類型 階層集
Planning 應用程式

科目維度

原則 A
  • 核准群組：Josh、Frank、會計
  • 方法：循序
  • 必要的總計：3 個群組
 「科目」節點類型 「科目」階層集

「會計」群組由 James 和 Heather 組成。

核准工作流程：

  1. Mark 提交移動 3 個科目的要求。
  2. 核准要求傳送至 Josh。
  3. Josh 核准要求。
  4. 核准要求傳送至 Frank。
  5. Frank 核准要求。
  6. 核准要求傳送至「會計」群組 (James 和 Heather)。
  7. Heather 核准要求。
  8. 由於符合原則需求，因此要求被確定。

範例 4：節點類型和階層集層級核准原則

當應用程式和維度層級的核准原則套用至所有要求動作時，僅會針對特定的要求動作套用節點類型和階層集層級的原則。節點類型的原則僅套用於新增或刪除節點或更新節點特性的要求。階層集的原則僅套用至可在階層集中插入、移除、移動，或重新排列節點，或者可更新節點關係特性的要求。

為了說明這些原則，我們將審視作為範例的兩個要求，該範例同時具有節點類型和階層集的原則。第一個要求更新節點特性，因此僅套用節點的原則。第二個要求新增科目，這將會同時影響節點類型和階層集，因此將套用兩個原則。

表格 25-4 範例 4：節點類型和階層集層級原則設定值

應用程式 維度 節點類型 階層集
Planning 應用程式

科目維度

「科目」節點類型

原則 A
  • 核准群組：會計、TaxUsers
  • 方法：平行
  • 每一群組一個核准：True

「科目」階層集

原則 B
  • 核准群組：EssAdmins
  • 方法：平行
  • 每一群組一個核准：False
  • 必要個數總計：5 個核准

有關這些要求的部分額外的背景：

  • 「會計」群組由 James 和 Heather 組成。
  • TaxUsers 群組由 Brian、Jane 和 Rachel 組成。
  • EssAdmins 群組包含 7 個管理員 (從 EssAdmin1 到 EssAdmin7)。

首先，我們要審視更新節點特性的要求。節點特性更新只會受到節點類型上的原則影響。

要求 1 核准工作流程：

  1. Mark 提交更新 3 個科目描述的要求 (節點特性更新)。
  2. 核准要求傳送至會計和 TaxUsers 群組。

    註：

    由於節點特性更新不會影響階層集，因此 EssAdmins 群組不會取得核准要求。
  3. James 核准「會計」群組的要求。
  4. Rachel 核准 TaxUsers 群組的要求。
  5. 由於符合原則需求，因此要求被確定。

接下來，我們要審視第二個要求，這次是新增節點。和前面相同，由於要求動作會新增節點，因此會套用節點類型的原則。不過，對於此要求還會套用階層集的原則，因為新增動作會在階層式視點中建立插入動作。

要求 2 核准工作流程：

  1. Mark 提交新增 3 個新科目的要求。
  2. 核准要求傳送至會計和 TaxUsers 群組。
  3. 因為階層式視點中的新增動作還會在階層集中建立插入動作，因此核准要求還會被傳送至 EssAdmins 群組。
  4. James 核准「會計」群組的要求。

    註：

    因為 James 具有節點類型 (而不是階層集) 的隱含參與者 (讀取) 權限，因此他必須在「要求檢查程式」中核准要求。請參閱原則和權限。
  5. Rachel 核准 TaxUsers 群組的要求。

    註：

    因為 Rachel 具有節點類型 (而不是階層集) 的隱含參與者 (讀取) 權限，因此她必須在「要求檢查程式」中核准要求。請參閱原則和權限。
  6. 5 位 Essbase 管理員核准要求。

    註：

    因為 EssAdmins 群組具有階層集的隱含參與者 (讀取) 權限，因此他們還會被授予節點類型的隱含參與者 (讀取) 權限。他們可以開啟檢視和瀏覽階層集，以核准要求。請參閱原則和權限。
  7. 由於符合原則需求，因此要求被確定。

範例 5：啟用核准擴充

如果啟用核准原則擴充，具有檢視中任何資料物件之參與者 (寫入) 存取權的核准者就可以在核准之前修改要求。

在此範例中，在內含下列三個應用程式視點的維護檢視中提出要求：General Ledger、Planning 及 Consolidation。每個應用程式都有一個應用程式層級的核准原則，並且啟用了 GL 和 Planning 原則的擴充。

表格 25-5 範例 5：核准擴充

General Ledger 應用程式 Planning 應用程式 Consolidation 應用程式
GL 核准原則
  • 核准群組：Josh (GL 管理員)

    註：

    Josh 具有 Planning 應用程式的參與者 (寫入) 權限。
  • 方法：循序
  • 必要個數總計： 1
  • 啟用擴充？是
 Planning 核准原則
  • 核准群組： Julie (Planning 管理員)

    註：

    Julie 具有 Consolidation 應用程式的參與者 (寫入) 權限。
  • 方法：循序
  • 必要個數總計： 1
  • 啟用擴充？是
 Consolidation 核准原則
  • 核准群組：會計
  • 方法：循序
  • 必要個數總計： 1
  • 啟用擴充？否

核准工作流程：

  1. Mark 提交在 General Ledger 應用程式中新增成本中心的要求。
  2. 核准要求傳送給 GL 管理員 Josh。
  3. Josh 藉由新增 Planning 應用程式成本中心，然後核准 GL 應用程式的要求來擴充要求。
  4. 因為 Josh 新增了 Planning 應用程式節點，因此啟用了 Planning 核准原則並將核准要求傳送給 Planning 管理員 Julie。
  5. Julie 藉由新增 Consolidation 應用程式成本中心，然後核准 Planning 應用程式的要求來進一步擴充要求。
  6. 啟用了 Consolidation 核准原則並將核准要求傳送給「會計」群組。
  7. 「會計」群組的成員 Barry 核准 Consolidation 應用程式的要求。因為未啟用 Consolidation 原則擴充，因此 Barry 無法進一步擴充要求。
  8. 符合所有核准原則需求後，即會確認要求並新增這三個應用程式成本中心。