구성 가능 계산 모범 사례

구성 가능 계산으로 작업하는 경우 이러한 모범 사례를 사용합니다.

계산 개념

계산을 생성하는 데 필요한 필수 개념입니다.

데이터 블록
기본 스크립트 형식
BottomUp과 TopDown 계산 비교
블록과 셀 모드 비교

데이터 블록

다음 그림은 샘플 애플리케이션의 데이터 블록을 보여 줍니다.

밀집 차원의 저장된 멤버가 데이터 블록을 구성합니다. 위 샘플 애플리케이션의 블록 크기는 2(판매 및 현금) x 8바이트 = 16바이트입니다.
고유한 희소 차원 멤버 조합이 INDEXes를 구성하고 데이터 블록을 가리킵니다. 위 샘플 애플리케이션에는 총 2(실제, 예산) x 2(FY17, FY18) x 2(1월, 2월)= 8개의 인덱스가 있습니다.

Essbase BSO(Block Storage Option) 데이터베이스에서 블록은 밀집 차원의 저장된 멤버를 구성합니다. Financial Consolidation and Close에서 기본적으로 계정은 유일한 밀집 차원입니다.

이 예에서 계정 차원은 밀집이며 1977개의 저장된 멤버가 있습니다. 단일 BSO Database Consol의 블록에 1977개의 셀이 있음을 나타내며, 각 셀은 계정 멤버를 나타냅니다.

바이트 단위의 블록 크기는 다음과 같습니다.

블록 크기(바이트) - 계정에 저장된 멤버 수 * 8
블록 크기(바이트) = 1977 * 8 = 15,816바이트

참고: 데이터베이스 등록정보를 보려면 Calculation Manager에서 작업, 데이터베이스 등록정보를 순서대로 선택합니다.

데이터 블록 생성 모범 사례

데이터 셀에 기록하는 구성 가능 계산이 실행되는 경우 데이터를 데이터베이스에 기록하려면 데이터 블록이 있어야 합니다.

데이터 블록은 저장된 희소 및 밀집 차원 멤버의 조합입니다.

저장된 희소 차원 조합마다 별도의 데이터 블록이 생성됩니다. 밀집 차원의 멤버는 하나의 블록과 동일합니다.

구성 가능 계산을 생성하는 경우 계산된 결과를 저장하고 누락된 데이터에 대한 이슈를 해결하기 위해 추가 블록을 생성해야 할 수도 있습니다.

블록 자동 생성 옵션을 사용하여 누락된 블록이 시스템에서 자동으로 생성되도록 할 수 있습니다. 구성 가능 계산 블록 자동 생성 사용을 참조하십시오.

구성 가능 계산에서 상향식 처리를 사용하는 경우 데이터 블록을 수동으로 생성하거나 데이터 블록이 이미 있는지 확인해야 합니다.

다음 방법 중 하나를 사용하여 데이터 블록을 수동으로 생성할 수 있습니다.

데이터 로드 프로세스 중 데이터를 지정합니다. 예를 들어 단일 밀집 멤버 교차점에 "Zero"를 쓰고 블록 생성 후 "#missing"을 써서 "Zero"를 지웁니다.
Essbase DATACOPY 명령을 사용합니다. 이 명령을 사용하면 누락된 셀을 포함한 소스의 모든 블록이 대상에 복사됩니다. 하지만 이 방법은 잠재적으로 불필요한 블록을 생성하여 연결 프로세스 속도를 저하시킬 수 있습니다.

블록 자동 생성을 사용할 시기

블록 자동 생성은 구성 가능 계산 중에 누락된 블록을 생성하기 위해 제공되는 설정입니다.

이 설정은 잠재적인 블록 알고리즘을 사용하여 전체 데이터베이스에서 블록이 있는지 검색하고, 블록이 없는 경우 누락된 블록을 적절하게 생성하기 때문에 성능에 큰 영향을 미칩니다.

다른 블록 생성 기술이 적합하지 않다고 확신하는 경우에만 이 설정을 사용하십시오.

@CALCMODE(BOTTOMUP) 함수(삽입 지점에서 사용된 경우)와 블록 자동 생성은 상호 배타적입니다.

@SHIFT 및 @PRIOR 함수의 타겟 데이터 블록 생성

계산 스크립트에서 @SHIFT 또는 @PRIOR 함수를 사용하는 경우, 계산을 실행하려면 타겟 데이터 블록이 있어야 합니다. 타겟 데이터 블록이 다른 계산 또는 데이터 로드의 일부로 존재하거나, @CREATEBLOCK 함수를 사용하여 생성해야 합니다.

예제 사용 사례:

실제, FY16, P12, ML_HFM에 데이터가 있습니다. Oracle Hyperion Financial Management에서 데이터를 추출하고 있으며 실제, FY16, P1, ML_HFM에 로드되지 않았습니다. 이전 연도의 P12 기간에서 데이터를 검색해야 하며, 당기 역분개 항목을 실제, FY17, P1, ML_HFM_Calc에 반영해야 합니다.

계산 스크립트는 다음과 같습니다.

분개가 게시되지 않았습니다(P13의 "FCCS_Journal 입력"). 이 코드는 "ML_HFM_Calc"를 희소 멤버 앵커로 사용하여 다음 경로를 사용할 것으로 예상됩니다.

@SHIFT("P12"->"ML_HFM", -1, @CHILDREN("Years"));

그러나 이 코드는 #MISSING을 반환합니다.

해결 방법 1:

해결 방법 2:

ClearEmptyBlocks 규칙 가이드라인

ClearEmptyBlocks 비즈니스 규칙은 빈 데이터 블록의 연결 큐브를 검색하는 데 도움이 됩니다. 빈 데이터 블록은 다음 작업의 일부로 생성될 수 있습니다.

빈 블록을 생성하는 주문형 규칙 실행. 예를 들어 @CREATEBLOCK 함수를 사용하면 생성된 빈 데이터 블록이 사용되지 않을 수 있습니다.
@CALCMODE(BOTTOM UP) 대신 희소 앵커를 사용하여 #MISSING 지정에서 TOPDOWN 계산으로 인한 블록 누출이 있을 수 있는 삽입 지점 코드(예: FCCS_20)
Financial Consolidation and Close 시스템 계산

권장되는 ClearEmptyBlocks 규칙 실행 방법

스크립트가 개발 단계에 있을 때 주문형 규칙/삽입 지점 테스트를 완료한 후 규칙을 실행하는 것이 가장 좋습니다. ClearEmptyBlocks 규칙은 개발 중인 계산을 실행하기 전과 후의 블록 통계를 측정하는 데 도움이 됩니다.
프로덕션 단계에서 지정된 연도에 대한 전체 연도 연결을 완료한 후에 규칙을 실행합니다.

EPM Automate 스크립트는 주말마다 근무 시간 이후에 실행되도록 스케줄링할 수 있습니다.

call epmautomate runbusinessrule ClearEmptyBlocks Scenario ="<Scenario>" Year = "<Particular Year>"
Period = "ILv10Descendants(YearTotal)"
call epmautomate restructurecube Consol

참고: 이 활동 스케줄은 일별 유지관리 주기와 3~4시간 이상의 간격을 유지해야 합니다.

기본 스크립트 형식

다음 그림은 샘플 계산 스크립트 형식을 보여 줍니다.

구성 가능한 계산 작성

다음 그림은 [연결 프로세스 현지 통화] 탭에서 구성 가능한 계산 규칙을 보여 줍니다.

다음 그림은 [연결 프로세스 현지 통화] 탭에서 해당하는 구성 가능한 계산 규칙을 보여 줍니다.

구성 가능한 계산을 사용하면 다음 세 가지 데이터 범주를 포함하는 사용자 정의된 계산을 수행할 수 있습니다.

환산되지 않은 데이터: 엔티티 통화 + (FCCS_Entity Input 또는 FCCS_Entity Consolidation)
환산된 데이터: 상위 통화 + (FCCS_Entity 입력 또는 FCCS_Entity 연결)
제거된 데이터: 상위 통화 + FCCS_Elimination

삽입 지점이라고도 하는 올바른 구성 가능한 계산 규칙 템플리트에서 구성 가능한 계산을 작성하려면 통화 및 연결 조합을 이해하는 것이 중요합니다.

예를 들어 FCCS_30_After Opening Balance Carry Forward_Translated는 FCCS 기본 변환 및 FX 계산이 이미 FCCS_30에서 특별한 주의가 필요한 데이터를 처리한 경우에만 사용해야 합니다.

구성 가능한 계산 예제 작성

블록 생성 문제의 예와 동일한 계산을 해결하는 서로 다른 접근 방식을 고려하십시오.

사용 사례:

FCCS_Managed Data, FCCS_Mvmts_NetIncome, FCCS_Local GAAP 및 No Product에 로드된 두 계정, Warehouse_Stock과 Showroom_Stock의 값 추가
FCCS_Other Data, FCCS_Mvmts_NetIncome, FCCS_Local GAAP 및 No Product의 Account Inventory_Stock에 계산 결과 저장
FCCS_10 구성 가능한 계산 사용

접근 방식 1: 멤버 블록 없음 사용(앵커)

1.   FIX ("FCCS_Entity Input", "Entity Currency")
2.      FIX ("FCCS_Other Data", "FCCS_Mvmts_NetIncome", "FCCS_No Intercompany", "No Product",
"FCCS_Local GAAP")
3.      " Inventory_Stock " = "FCCS_Managed Data"->" Warehouse_Stock " + "FCCS_Managed Data"->
"Showroom_Stock ";

4.      ENDFIX
5.      ENDFIX

이 접근 방식의 단점:

밀집 계산입니다(Inventory_Stock이 왼쪽에 있는 계정임을 고려). 계산이 올바르게 작성되었지만, FCCS_Other Data에 이전 블록이 없고 결과를 보유할 연계된 다른 FIX 멤버가 없으면 계산 결과가 표시되지 않습니다.
조건부 계산 제한 사항(예: IF..ELSE..ENDIF)을 적용할 수 없습니다.
위의 교차점에 0개의 데이터 블록을 수동으로 도입하려면 해결 방법이 필요합니다.

접근 방식 2: 밀집 멤버 블록 사용(앵커)

1.   FIX ("FCCS_Entity Input", "Entity Currency")
2.      FIX ("FCCS_Other Data", "FCCS_Mvmts_NetIncome", "FCCS_No Intercompany", "FCCS_No Intercompany",
"FCCS_Local GAAP")

3.      " Inventory_Stock "(
4.      "FCCS_Managed Data"->" Warehouse_Stock " + "FCCS_Managed Data"->" Showroom_Stock ";
5.      )
6.      ENDFIX
7.      ENDFIX

이 접근 방식의 단점:

밀집 계산입니다(Inventory_Stock 멤버 블록이 계정이기 때문). 계산이 올바르게 작성되었지만, FCCS_Other Data에 이전 블록이 없고 연계된 다른 FIX 멤버가 없으면 계산 결과가 표시되지 않습니다.
위의 교차점에 0개의 데이터 블록을 수동으로 도입하려면 해결 방법이 필요합니다.

접근 방식 3: 희소 멤버 블록 사용(앵커)

1.   FIX ("FCCS_Entity Input", "Entity Currency")
2.      FIX ("FCCS_Mvmts_NetIncome", "FCCS_No Intercompany", "No Product", "FCCS_Local GAAP")
3.      "FCCS_Other Data" (
4.      " Inventory_Stock " = "FCCS_Managed Data"->" Warehouse_Stock " + "FCCS_Managed Data"->
"Showroom_Stock ";

5.      )
6.      ENDFIX
7.      ENDFIX

이 접근 방식의 장점:

FCCS_Other Data 멤버 블록이 희소 차원인 데이터 소스이므로 이는 희소 계산입니다. 계산 결과 블록이 생성됩니다.

이 접근 방식의 단점:

교차 차원 연산자가 사용되므로 멤버 블록 계산이 하향식으로 실행됩니다.

접근 방식 4: 희소 멤버 블록 및 BottomUp 계산 사용

1.   FIX ("FCCS_Entity Input", "Entity Currency")
2.      FIX ( "FCCS_Mvmts_NetIncome", "FCCS_No Intercompany", "No Product", "FCCS_Local GAAP")
3.      "FCCS_Managed Data"(@CALCMODE(BOTTOMUP);
4.      "FCCS_Other Data"-> "Inventory_Stock " = " Warehouse_Stock " + " Showroom_Stock "; 5.        )
6.      ENDFIX
7.      ENDFIX

이 접근 방식의 장점:

FCCS_Managed Data 멤버 블록이 희소 차원인 데이터 소스이므로 이는 희소 계산입니다.
멤버 블록 계산이 BottomUp을 실행합니다.
FCCS_Managed Data는 이 계산의 소스입니다. 소스에 데이터 블록이 있는 경우에만 FCCS_Other Data에 결과 블록이 생성됩니다.
계산의 오른쪽에 cross-dim 연산자가 필요하지 않습니다.
이 지정의 왼쪽에 cross-dim 연산자가 있으므로 명시적으로 계산을 BottomUp으로 지정해야 합니다.

블록과 셀 모드 계산 비교

BLOCK 모드: (기본 모드) 이 계산 모드에서는 Essbase가 블록 내의 셀을 그룹화하고 동시에 각 그룹의 셀을 계산합니다.
블록 계산 모드는 빠르지만, 결과 데이터가 정확한지 확인하려면 블록 내 데이터 종속성을 신중하게 고려해야 합니다.
CELL 모드: 이 계산 모드에서 Essbase는 아웃라인을 기반으로 하는 계산 순서에 따라 각 셀을 순차적으로 계산합니다.
셀 계산 모드가 더 느린 이유는 명백합니다. 그러나 데이터 종속성과 관련된 경우 정확한 결과를 보장합니다.
Essbase는 공식을 컴파일할 때 다음 메시지와 비슷한 공식의 실행 모드를 설명하는 메시지를 애플리케이션 로그 파일에 인쇄합니다.

Formula on member Profit % will be executed in CELL and TOPDOWN mode.

Essbase는 다음과 같은 함수를 사용하지 않는 한, 공식을 계산하는 동안 블록 모드를 사용합니다.

@ANCEST
@CURRMBR
@ISMBR on a dense member
@MDANCESTVAL
@MDPARENTVAL
@MDSHIFT
@NEXT
@PARENT
@PARENTVAL
@PRIOR
@SANCESTVAL
@SPARENTVAL
@SHIFT
@XWRITE

블록 모드를 수동으로 유도하려면 @CALCMODE(BLOCK)를 사용합니다. 밀집 블록에 데이터 종속성이 없는지 확인합니다.

블록 모드의 예

월을 기준으로 다음 계산을 수행합니다.

1월 - Sales Synergies는 Returns and Allowances의 1차 하위 합계입니다.
2월 - Sales Synergies는 Returns and Allowances 의 1차 하위 합계에 20%를 곱한 값입니다.
나머지 달 - Sales Synergies는 Returns and Allowances의 1차 하위 합계에 10%를 곱한 값입니다.

블록 모드

1.   FIX ("FCCS_Entity Input", "Entity Currency")
2.      FIX ("Sales Synergies", "FCCS_No Intercompany", "FCCS_Managed Data", "No Product", "FCCS_Local GAAP")
3.      "FCCS_Mvmts_NetIncome" (
4.      IF (@ISMBR("Jan"))
5.      @SUM(@Children("Returns and Allowances"));
6.      ELSEIF (@ISMBR("Feb"))
7.      @SUM(@Children("Returns and Allowances")) * 0.2;
8.      ELSE
9.      @SUM(@Children("Returns and Allowances")) * 0.1;
10.     ENDIF
11.     )
12.     ENDFIX
13.     ENDFIX

셀 모드와 유도된 블록 모드 비교

월을 기준으로 다음 계산을 수행합니다.

1월 - Sales Synergies는 Returns and Allowances의 1차 하위 합계입니다.

2월 - Sales Synergies는 Returns and Allowances의 1차 하위 합계에 20%를 곱한 값입니다.

나머지 달 - Sales Synergies는 Returns and Allowances의 1차 하위 합계에 이전 기간의 Sales Synergies를 더한 값입니다. 전체 결과에 10%를 곱합니다.

셀 모드

1.   FIX ("FCCS_Entity Input", "Entity Currency")
2.      FIX ("Sales Synergies", "FCCS_No Intercompany", "FCCS_Managed Data", "No Product", "FCCS_Local GAAP")
3.      "FCCS_Mvmts_NetIncome" (
4.      IF (@ISMBR("Jan"))
5.      @SUM(@Children("Returns and Allowances"));
6.      ELSEIF (@ISMBR("Feb"))
7.      @SUM(@Children("Returns and Allowances")) * 0.2;
8.      ELSE
9.      (@SUM(@Children("Returns and Allowances")) + @PRIOR("Sales Synergies")) * 0.1;
10.     ENDIF
11.     )
12.     ENDFIX
13.     ENDFIX

블록 모드

1.   FIX ("FCCS_Entity Input", "Entity Currency")
2.      FIX ("Sales Synergies", "FCCS_No Intercompany", "FCCS_Managed Data", "No Product", "FCCS_Local GAAP")
3.      "FCCS_Mvmts_NetIncome" (@CALCMODE(BLOCK);
4.      IF (@ISMBR("Jan"))
5.      @SUM(@Children("Returns and Allowances"));
6.      ELSEIF (@ISMBR("Feb"))
7.      @SUM(@Children("Returns and Allowances")) * 0.2;
8.      ELSE
9.      (@SUM(@Children("Returns and Allowances")) + @PRIOR("Sales Synergies")) * 0.1;
10.     ENDIF
11.     )
12.     ENDFIX
13.     ENDFIX

고객 A 사용 사례

분개 조정을 기반으로 손익계산서 계정의 FDMEE에서 로드된 관리형 데이터를 계산된 다른 데이터 소스 멤버로 재분류합니다.
성능이 느림: 1년 동안 180분

고객 A - 스크립트 예제

고객 A - 스크립트 개선

계정 밀집 차원에서 @ISMBR 검사를 사용하는 대신, @REMOVE를 사용하여 계정을 제거합니다
BottomUp 처리
@LEV 및 @CURRMEMBER 대신, 부울 @ISLEV를 사용합니다
성능이 90% 향상됨

고객 B 사용 사례

목표 - 일부 소스 엔티티에서 타겟 엔티티로 데이터 이동
데이터가 계산되지 않음
성능이 느림 - 3.5시간

고객 B - 스크립트 예제

고객 B - 스크립트 개선

복사를 사용하여 타겟 블록 생성
계산은 그대로 TopDown 상태 유지
계산은 하나의 타겟 사용자정의 차원 멤버에서만 수행
@LIKE를 사용하여 스크립트를 일반화합니다
3.5시간에서 몇 분으로 시간이 단축됨

고객 C 사용 사례

사용자 인터페이스를 통해 입력된 FCCS_Closing_Balance_Input을 기반으로 이동 재분류
성능이 느림 - 15분

고객 C - 스크립트 예제 계속

고객 C - 스크립트 개선

FIX에서 제한된 멤버를 제거합니다
BottomUp 처리
에지 사례를 확인합니다
일반 사례를 먼저 확인합니다.
성능이 40% 향상됨

고객 D 사용 사례

Hyperion Financial Management, 데이터 소스 ML_HFM에서 가져온 데이터를 재분류하고 ML_HFM_Calc 데이터 소스 멤버에 저장
성능이 느림 - 단일 기간 동안 24시간
블록이 예상대로 생성되지 않았으므로 데이터가 결합되지 않음

고객 D - 스크립트 예제

고객 D - 스크립트 개선

계정 밀집 차원에서 @ISMBR 검사를 사용하는 대신, @REMOVE를 사용하여 계정을 제거합니다
BottomUp 처리
@LEV 및 @CURRMEMBER 대신, 부울 @ISLEV를 사용합니다
성능이 90% 향상됨

고객 E 사용 사례

현재 기간의 연결 방법이 변경되어, 이전 기간의 모든 누적 CTA와 제거 처리를 제거하려고 함
성능이 느림 - 90분

고객 E - 스크립트 개선

FCCS_Intercompany_Eliminations에 쓰기와 관련된 검증 오류를 방지하려면 타겟에서 Data_Input 사용
마감 잔액 입력이 있는 이동 ICP 멤버에서 BottomUp 사용
시간이 90분에서 11분으로 단축됨

모범 사례 요약

BottomUp 처리
계정 밀집 차원에서 @ISMBR 검사를 사용하는 대신, @REMOVE를 사용하여 계정을 제거합니다
@LEV 및 @CURRMBR 대신, 부울 @ISLEV를 사용합니다
FIX에서 제한된 멤버를 제거합니다
앵커 접근법이 효과가 없는 경우, 복사를 사용하여 타겟 블록을 생성합니다
계산은 하나의 타겟 사용자정의 차원 멤버에서만 수행
@LIKE를 사용하여 스크립트를 일반화합니다
자동 블록 생성 방지
에지 사례를 확인합니다
일반 사례를 먼저 확인합니다.

성능 향상을 위한 모범 사례

Essbase 여러 번 경유

FIX 문이 규칙에서 사용될 때마다 각 FIX는 데이터베이스에 대한 개별 경유를 트리거합니다. 성능을 위해서는 개별 FIX 문이 너무 많이 포함되지 않도록 하여 Essbase로 여러 번 경유하는 것을 방지하는 것이 가장 좋습니다.

예 - Essbase 여러 번 경유

FIX("Entity Currency", "FCCS_Entity Input", …..)
        FIX("FCCS_Data Input", … )
                //Calculations;
        ENDFIX
        
        FIX("FCCS_Other Data", … )
                //Calculations;
        ENDFIX

ENDFIX

예: IF...ENDIF를 사용하여 여러 번 경유하는 것을 방지하는 제안된 변경사항

FIX("Entity Currency", ...)
        FIX( @List("FCCS_Data Input", "FCCS_Other Data"), … )
                "FCCS_Entity Input"( @CALCMODE(BOTTOMUP);
                        IF(@ISMBR("FCCS_Data Input")
                                //Calculations for "FCCS_Data Input";
                        ELSE                    
                                //Calculations "FCCS_Other Data";
                        ENDIF   
                )
        ENDFIX
ENDFIX

예: 멤버 블록을 사용하여 여러 번 경유하는 것을 방지하는 제안된 변경사항

FIX("Entity Currency", ...)
        FIX( @List("FCCS_Data Input", "FCCS_Other Data"), … )
                "FCCS_Entity Input"( @CALCMODE(BOTTOMUP);
                        IF(@ISMBR("FCCS_Data Input")
                                //Calculations for "FCCS_Data Input";
                        ELSE                    
                                //Calculations "FCCS_Other Data";
                        ENDIF   
                )
        ENDFIX
ENDFIX

예: Essbase로 여러 번 경유하는 원인이 되는 여러 개별 중첩 FIX 문

FIX("FCCS_Elimination")
        FIX("No Movement")
                Fix(@Relative("ICP_Category",0))
                "Custom_Elimination" (
                        "InterSales"="Other_InterAcct"->"FCCS_Intercompany Eliminations";
                )
                ENDFIX  /*Intercompany*/
        ENDFIX  /*Movement*/
 ENDFIX  /*Consolidation*/

예: 여러 번 경유하는 것을 방지하도록 재작성

FIX ("FCCS_Elimination",@Relative("ICP_Category A",0), "No Movement")
        "Custom_Elimination" ( @CALCMODE(BOTTOMUP);
                "640102" = "WA_Intercompany Account"->"FCCS_Intercompany Eliminations";
        )
ENDFIX

제한된 멤버에 작성

이 예에서는 "FCCS_Intercompany Eliminations" > "FCCS_Eliminations" > "Mvmts_NewBusiness"를 "Data Input" > "FCCS_Eliminations" > "Mvmts Reclass"로 재분류한다고 가정하겠습니다.

"FCCS_Intercompany Eliminations"는 데이터 소스 차원의 제한된 멤버이므로 이 멤버에서 FIX를 사용하려고 하면 시스템에서 오류를 반환합니다.

시스템에서 하향식 처리를 사용하도록 강제 적용하는 다음 명령문을 작성할 수 있습니다.

예: 하향식 처리를 사용한 제한된 멤버 작업

FIX("Data Input", … ) 
        "FCCS_Elimination" (
                 "Mvmts_Reclass" = -1 * "FCCS_Intercompany Eliminations"->"Mvmts_NewBusiness" ; 
        )               
ENDFIX

예: 상향식 처리를 사용하여 명령문 재작성

FIX("FCCS_IntercomanyEliminations", "Mvmts_NewBusiness", … )
        "FCCS_Elimination" ( @CALCMODE(BOTTOMUP);
                 "Mvmts_Reclass"->"Data Input" = -1 * "Mvmts_NewBusiness" ; 
        )               
ENDFIX

이 예에서는 "FCCS_Intercompany Eliminations"에 FIX가 있으나 멤버 블록의 "Data Input"으로 대체하며 시스템에서 검증 중 오류를 반환하지 않습니다.

마감 잔액 입력에 데이터를 입력하고 UDA에 따라 이동 계산

아래 예에서는 마감 잔액 입력을 특정 이동 멤버로 이동한다고 가정하겠습니다. 다음 요구사항을 사용하여 사용자정의 계산을 작성할 수 있습니다.

상향식 처리를 위해 희소 차원 멤버 조합에 FIX를 사용해야 합니다. 상향식 처리는 블록과 관련이 있으며 희소 차원은 블록을 정의해야 합니다.
UDA(사용자 정의 속성) 계정에서 FIX와 함께 UDA가 가장 잘 처리되어 동일한 계산을 수행해야 합니다.
아래 예에서는 지정된 모든 UDA가 ASSET/LIABILITY/EQUITY 계정 유형에 정의되어 있다고 가정해야 합니다.
FCCS_Net Income에 상대적인 레벨 0 계정 차원 멤버에 FIX를 사용해야 합니다.
성능을 높이기 위해 @LEV를 사용하여 멤버 레벨을 계산하는 대신에 부울 함수를 사용해야 합니다.
부울 함수 @ISDESC를 사용하여 멤버가 항상 리프 멤버인지 확인해야 합니다.

예: 마감 잔액 입력에 데이터를 입력하고 UDA에 따라 이동 계산

IF 조건을 사용하는 가장 좋은 방법

다음은 IF를 사용하여 조건문을 작성하는 경우의 일반적인 예입니다. 이 예에서는 1월에 특정 프로세스를 수행하고 다른 월에는 다른 작업을 수행하려고 합니다. 계산이 아래와 같이 작성되면 시스템이 1월이 아닌 모든 기간에 대해 12번 확인을 수행합니다. 시스템은 항상 1월을 먼저 확인한 후 ELSE 절로 진행하기 때문입니다.

예: IF 문

FIX ("Entity Currency", "FCCS_Entity Input" … )
        "Mvmt_Increase01" ( @CALCMODE(BOTTOMUP);
                IF(@ISMBR("Jan"))
                                "FCCS_ClosingBalance_Input" - @PRIOR("FCCS_ClosingBalance_Input"->                   "Dec", 1, @RELATIVE("Years", 0));
                ELSE
                                "FCCS_ClosingBalance_Input" - "FCCS_TotalOpeningBalance";
                ENDIF
        )
ENDFIX

예: NOT IF를 사용하여 다시 작성

IF 절을 사용하여 12개 기간 중 11개 기간이 실행된 후 조건 분기를 벗어나도록 IF 문을 재작성할 수 있습니다. 1월만 ELSE 절에서 한 번 실행됩니다.

FIX ("Entity Currency", "FCCS_Entity Input", …)         
        "FCCS_ClosingBalance_Input"(@CALCMODE(BOTTOMUP);
        IF (NOT @ISMBR("Jan"))
                "Mvmt_Increase01" = "FCCS_ClosingBalance_Input" - "FCCS_TotalOpeningBalance";
        ELSE
                IF(NOT @ISMBR(@MEMBERAT(@CHILDREN("Years"),1)))
              "Mvmt_Increase01" = "FCCS_ClosingBalance_Input" - "FCCS_ClosingBalance_Input"->"Dec"->            @MEMBER(@PREVSIBLING(@CURRMBR("Years")));
                  ENDIF;
         ENDIF;
        )
ENDFIX

확장 차원이 포함된 최상위 사용자정의 멤버 시스템 계산 옵션 사용

사용자가 정의하는 사용자정의 차원의 경우 서비스 관리자는 성능 향상을 위해 모든 레벨 0 멤버 대신 사용자정의 차원의 최상위 멤버를 사용하여 시스템 계산을 처리하도록 선택할 수 있습니다. 옵션이 적용되는 특정 사용자정의 차원을 선택할 수 있습니다. 시스템 계산을 참조하십시오.

확장 차원 환경을 사용하는 경우 사용자정의 최상위 멤버를 사용해도 성능이 저하되지 않도록 엔티티 입력 및 엔티티 통화 데이터를 기반으로 하는 연결의 시작 부분 "NoCustomX"에 빈 블록을 생성하고 해당 블록을 사용하여 모든 계산을 수행할 수 있습니다. 예를 들어, 제품 사용자정의 차원에 1,000개의 사용자정의 멤버가 있는 경우 하나의 블록 @"No Product"를 생성하고 "No Product"에 FIX를 사용하고 상향식 처리를 사용할 수 있습니다. 그러면 시스템이 제품 차원의 1,000개 멤버를 모두 순환하지 않아도 되며, 전체 성능을 향상시키기 위해 합계 값에 "제품 합계"를 사용할 수 있습니다.

다음 예에서는 계산 스크립트 샘플을 보여줍니다.

상향식 처리를 사용하여 FCCS_10 Member Blocks 계산

@CALCMODE(BOTTOMUP)를 사용하여 멤버 블록 계산을 조합합니다.
FIX 멤버가 여러 계산에서 동일한 경우 여러 FIX...ENDFIX의 계산을 단일 FIX...ENDFIX로 조합합니다.

단일 계산인 경우 FIX 내에서 FIX를 사용하지 마십시오.

다음 예에서는 하향식 처리를 사용하여 계산을 실행한 후 오른쪽 쿼리 처리를 향상시키기 위해 상향식 처리를 사용하는 수정된 예를 보여줍니다.

예: 하향식 처리를 사용하여 FCCS_20 C1_Validation 실행
구성 가능 계산 예 C1 하향식

예: 상향식 처리를 사용하여 FCCS_20 C1_Validation 실행

계산 종속성

구성 가능 계산(삽입 지점) 및 주문형 규칙에서 계산을 수행할 때 엔티티 간의 종속성을 피해야 합니다. 계산에서 엔티티 A의 값을 참조하려고 하며 엔티티 A가 아직 계산되지 않은 경우 엔티티 A에는 값이 없습니다.

예를 들어 "엔티티 A" > "ICP_B" > "엔티티 통화"(소스)에서 "엔티티 B" > "ICP_A" > "엔티티 통화"(대상)로 데이터를 재분류하려는 경우 엔티티 A와 엔티티 B 둘 다 병렬로 계산되기 때문에 엔티티 A(소스)의 데이터가 계산될 수 없어 해당 데이터가 사용 불가능할 수 있습니다.

이 경우에는 먼저 엔티티 A를 계산한 다음 종속 엔티티 B를 계산하여 재분류를 시도해야 합니다.