승인 정책 예

다음 예에서는 애플리케이션, 차원, 노드 유형 및 계층 세트 레벨의 승인 정책을 설명하고 다양한 정책 설정을 사용하여 승인이 처리되는 방법을 보여줍니다.

예 1: 애플리케이션 레벨 승인 정책

먼저 기본 레벨의 승인 진행 방식을 보여주는 간단한 예를 살펴보겠습니다. 이 예에는 GL 관리 그룹에서 2명 이상이 계정 차트에 대한 모든 변경사항을 승인해야 한다는 것을 명시한 애플리케이션 레벨의 승인 정책이 있습니다.

표 29-1 예 1: 애플리케이션 레벨 정책 설정

Fusion GL 애플리케이션 차원 노드 유형 계층 세트
정책 A
  • 승인 그룹: GL 관리
  • 방법: 병렬
  • 필요한 총 승인 수: 승인자 2명
 계정 차원 계정 노드 유형 계정 계층 세트

GL 관리 그룹은 Barry, Julie, Jane으로 구성되어 있습니다. Tom은 Fusion GL 애플리케이션의 소유자입니다.

승인 워크플로우는 다음과 같습니다.

  1. Mark는 계정을 추가하고 비용 센터 설명을 업데이트하는 요청을 제출합니다.
  2. 승인 방법이 병렬이므로 승인을 위해 GL 관리 그룹의 세 구성원 모두에게 요청이 전송됩니다.
  3. Julie가 요청을 승인합니다.
  4. Barry가 요청을 승인합니다.
  5. 정책 요구사항이 충족되고 요청이 커밋됩니다.

예 2: 교착 상태 에스컬레이션

이제 동일한 예를 다시 살펴보는데 이번에는 Barry 및 Jane이 GL 관리 그룹에서 전출되었습니다.

표 29-2 예 2: 교착 상태 에스컬레이션 정책 설정

Fusion GL 애플리케이션 차원 노드 유형 계층 세트
정책 A
  • 승인 그룹: GL 관리
  • 방법: 병렬
  • 필요한 총 승인 수: 승인자 2명
 계정 차원 계정 노드 유형 계정 계층 세트

GL 관리 그룹에는 Julie만 있습니다. Tom은 Fusion GL 애플리케이션의 소유자입니다.

승인 워크플로우는 다음과 같습니다.

  1. Mark는 계정을 추가하고 비용 센터 설명을 업데이트하는 요청을 제출합니다.
  2. 승인 요청이 Julie에게 전송됩니다.
  3. Julie가 요청을 승인합니다.

    정책에 따라 GL 관리 그룹에서 2명의 승인자가 승인해야 하지만 해당 그룹에는 Julie만 있습니다. 이런 경우 정책 요구사항을 충족시킬 승인자가 없으므로 교착 상태가 발생합니다. 따라서 애플리케이션에 대한 데이터 관리자 권한이 있는 사용자에게로 요청이 에스컬레이션됩니다. Tom이 애플리케이션 소유자이므로 Tom의 소유자 권한에는 데이터 관리자 권한이 포함되어 있습니다.

  4. 요청이 Tom에게 에스컬레이션됩니다.
  5. Tom이 요청을 승인합니다.
  6. 정책 요구사항이 충족되고 요청이 커밋됩니다.

예 3: 차원 레벨 순차 승인 정책

다음에는 차원 레벨의 직렬 유형 정책을 살펴보겠습니다. 이 예에서는 Josh, Frank 그리고 마지막으로 회계 그룹의 사용자 순으로 요청을 승인해야 합니다.

표 29-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: 노드 유형 및 계층 세트 레벨 승인 정책

애플리케이션 및 차원 레벨의 승인 정책은 모든 요청 작업에서 적용되지만 노드 유형 및 계층 세트 레벨의 정책은 특정 요청 작업에만 적용됩니다. 노드 유형에 대한 정책은 노드를 추가 또는 삭제하거나 노드 등록정보를 업데이트하는 요청에만 적용됩니다. 계층 세트에 대한 정책은 계층 세트에서 노드를 삽입, 제거, 이동 또는 순서 재지정하거나 노드 관계 등록정보를 업데이트하는 요청에만 적용됩니다.

이러한 원칙을 설명하기 위해 노드 유형 및 계층 세트 둘 다에 대한 정책이 있는 예에서 2개의 요청을 살펴보겠습니다. 첫번째 요청은 노드 등록정보를 업데이트하므로 노드 세트에 대한 정책만 적용됩니다. 두번째 요청은 계정을 추가하며, 이 작업은 노드 유형과 계층 세트 둘 다에 영향을 주므로 두 정책이 모두 적용됩니다.

표 29-4 예 4: 노드 유형 및 계층 세트 레벨 정책 설정

애플리케이션 차원 노드 유형 계층 세트
Planning 애플리케이션

계정 차원

계정 노드 유형

정책 A
  • 승인 그룹: 회계, TaxUser
  • 방법: 병렬
  • 그룹당 하나의 승인: True

계정 계층 세트

정책 B
  • 승인 그룹: EssAdmin
  • 방법: 병렬
  • 그룹당 하나의 승인: False
  • 필요한 총 승인 수: 승인자 5명

이러한 요청에 대한 몇 가지 추가 배경 정보는 다음과 같습니다.

  • 회계 그룹은 James 및 Heather로 구성되어 있습니다.
  • TaxUser 그룹은 Brian, Jane, Rachel로 구성되어 있습니다.
  • EssAdmin 그룹에는 7명의 관리자가 있습니다(EssAdmin1 - EssAdmin7).

먼저 노드 등록정보 업데이트 요청을 살펴보겠습니다. 노드 등록정보 업데이트는 노드 유형에 대한 정책의 영향만 받습니다.

요청 1 승인 워크플로우는 다음과 같습니다.

  1. Mark가 세 개의 계정 설명을 업데이트하도록(노드 등록정보 업데이트) 요청을 제출합니다.
  2. 승인 요청이 회계 및 TaxUser 그룹으로 전송됩니다.

    주:

    노드 등록정보 업데이트는 계층 세트에 영향을 주지 않으므로 EssAdmin 그룹은 승인 요청을 받지 않습니다.
  3. James가 회계 그룹에 대한 요청을 승인합니다.
  4. Rachel이 TaxUser 그룹에 대한 요청을 승인합니다.
  5. 정책 요구사항이 충족되고 요청이 커밋됩니다.

다음으로는 노드를 추가하는 두번째 요청을 살펴보겠습니다. 이전과 마찬가지로, 요청 작업이 노드를 추가하므로 노드 유형에 대한 정책이 적용됩니다. 그러나 이 요청의 경우 추가 작업은 계층 기반 뷰포인트에서 삽입 작업을 생성하므로 계층 세트에 대한 정책도 적용됩니다.

요청 2 승인 워크플로우는 다음과 같습니다.

  1. Mark는 새 계정 3개를 추가하는 요청을 제출합니다.
  2. 승인 요청이 회계 및 TaxUser 그룹으로 전송됩니다.
  3. 계층 기반 뷰포인트의 추가 작업은 계층 세트의 삽입 작업도 생성하므로 승인 요청이 EssAdmin 그룹으로도 전송됩니다.
  4. James가 회계 그룹에 대한 요청을 승인합니다.

    주:

    James는 노드 유형에 대한 암시적 참가자(읽기) 권한은 있으나 계층 세트에 대해서는 없으므로 요청 검사기에서 요청을 승인해야 합니다. 정책 및 권한을 참조하십시오.
  5. Rachel이 TaxUser 그룹에 대한 요청을 승인합니다.

    주:

    Rachel은 노드 유형에 대한 암시적 참가자(읽기) 권한은 있으나 계층 세트에 대해서는 없으므로 요청 검사기에서 요청을 승인해야 합니다. 정책 및 권한을 참조하십시오.
  6. Essbase 관리자 5명이 요청을 승인합니다.

    주:

    EssAdmins 그룹에는 계층 세트에 대한 암시적 참가자(읽기) 권한이 있으므로 노드 유형에 대한 암시적 참가자(읽기) 권한도 부여되어 있습니다. 뷰를 열고 계층 세트를 찾아 요청을 승인할 수 있습니다. 정책 및 권한을 참조하십시오.
  7. 정책 요구사항이 충족되고 요청이 커밋됩니다.

예제 5: 강화가 사용으로 설정된 승인

승인 정책에서 강화가 사용된 경우 요청 뷰의 데이터 객체에 대한 참가자(쓰기) 액세스 권한이 있는 승인자가 승인 전에 요청을 수정할 수 있습니다.

이 예제에서는 세 개의 애플리케이션, 즉 General Ledger, Planning 및 Consolidation의 뷰포인트가 있는 유지관리 보기에서 요청을 작성합니다. 각 애플리케이션에는 애플리케이션 레벨의 승인 정책이 있으며, GL 및 Planning 정책에는 강화가 사용으로 설정되어 있습니다.

표 29-5 예제 5: 강화를 사용하여 승인

General Ledger 애플리케이션 Planning 애플리케이션 Consolidation 애플리케이션
GL 승인 정책
  • 승인 그룹:Josh(General Ledger 관리자)

    주:

    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. 모든 승인 정책의 정책 요구사항이 충족되면 요청이 커밋되고 세 개의 애플리케이션 모두에 비용 센터가 추가됩니다.