構成可能な計算のベスト・プラクティス

構成可能な計算を操作する際には、次のベスト・プラクティスを使用します。

計算の概念

計算を作成するための最も重要な概念は次のとおりです:

データ・ブロック
基本のスクリプト形式
ボトムアップ計算とトップダウン計算
ブロック・モードとセル・モード

データ・ブロック

次の図は、サンプル・アプリケーションのデータ・ブロックを示します。

密ディメンションの保管済メンバーがデータ・ブロックを構成します。前述のサンプル・アプリケーションのブロック・サイズは、2 (SalesおよびCash) x 8バイト= 16バイトです。
疎ディメンション・メンバーの一意の組合せがインデックスを構成し、データ・ブロックをポイントします。前述のサンプル・アプリケーションには、合計で2 (Actual, Budget) x 2 (FY17, FY18) x 2 (Jan, Feb) = 8インデックスがあります。

Essbaseブロック・ストレージ・オプション(BSO)データベースでは、ブロックが密ディメンションの保管済メンバーを構成します。Financial Consolidation and Closeでは、デフォルトでは、勘定科目が唯一の密ディメンションです。

この例では、勘定科目ディメンションは密であり、1977の保管済メンバーがあります。これは、単一のBSOデータベース・コンソールのブロックに1977個のセルがあり、それぞれが勘定科目メンバーを表すことを示します。

バイト単位のブロック・サイズは次のようになります:

ブロック・サイズ(バイト) = 勘定科目の保管済メンバーの数 * 8
ブロック・サイズ(バイト) = 1977 * 8 = 15,816バイト

ノート: データベース・プロパティを表示するには、Calculation Managerで「アクション」、「データベース・プロパティ」の順に選択します。

データ・ブロック作成時のベスト・プラクティス

データ・セルへの書込みが行われる構成可能な計算を実行する場合、データをデータベースに書き込むためには、データ・ブロックが存在している必要があります。

データ・ブロックは、保管された疎および密ディメンション・メンバーの組合せです。

保管された疎ディメンションの組合せごとに個別のデータ・ブロックが作成されます。密ディメンションの複数のメンバーは、1つのブロックに相当します。

構成可能な計算を作成する場合、状況によっては、計算結果を保管して欠落しているデータに関する問題を解決するために、追加ブロックを作成する必要があります。

「ブロックの自動作成」オプションを有効化すると、欠落しているブロックを自動的に作成できます。構成可能な計算用のブロックの自動作成の有効化を参照してください。

構成可能な計算でボトムアップ処理を使用する場合、データ・ブロックを手動で作成するか、データ・ブロックがすでに存在することを確認する必要があります。

次のいずれかの方法を使用して、データ・ブロックを手動で作成できます。

データ・ロード・プロセス中にデータを割り当てます。たとえば、単一の密メンバー交差に「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 Input。コードでは、ML_HFM_Calcとともに疎メンバー・アンカーとして次のパスを取る必要があります。

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

ただし、これに対して#MISSINGが返されます。

回避策1:

回避策2:

ClearEmptyBlocksルールのガイドライン

ClearEmptyBlocksビジネス・ルールは、空のデータ・ブロックのコンソール・キューブのスカベンジに役立ちます。空のデータ・ブロックは、次の一環として生成されることがあります:

空のブロックを生成するオンデマンド・ルールの実行。たとえば、@CREATEBLOCK関数を使用すると、生成された空のデータ・ブロックがその後使用されない可能性があります。
#MISSINGの割当からくる思われる、TOPDOWN計算に起因するブロック・リークの可能性がある挿入ポイント・コード(たとえば、FCCS_20)。@CALCMODE(BOTTOM UP)を使用するかわりに、疎アンカーを使用しています。
Financial Consolidation and Closeシステム計算

ClearEmptyBlocksルールを実行するための推奨プラクティス

ベスト・プラクティスは、スクリプトの開発フェーズで、オンデマンド・ルール/挿入ポイントのテストを完了した後にルールを実行することです。ClearEmptyBlocksルールは、開発中の計算の実行前後にブロック統計を測定するのに役立ちます。
本番フェーズでは、特定の年の通年の連結を終了した後にルールを実行します。

EPM自動化スクリプトは、毎週末の業務時間終了後に実行するようスケジュールできます:

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

ノート: このアクティビティのスケジュールは、日次メンテナンス・サイクルで少なくとも3、4時間の間隔を維持する必要があります。

基本のスクリプト形式

次の図は、計算スクリプトの形式のサンプルを示しています。

構成可能な計算の記述

次の図は、連結プロセスの「現地通貨」タブの構成可能な計算ルールを示しています。

次の図は、連結プロセスの「現地通貨」タブの対応する構成可能な計算ルールを示しています。

構成可能な計算は、次の3つのカテゴリのデータが関与する、カスタマイズされた計算の実行に役立ちます:

未換算データ: エンティティ通貨 + (FCCS_Entity InputまたはFCCS_Entity Consolidation)
換算済データ: 親通貨 + (FCCS_Entity InputまたはFCCS_Entity Consolidation)
消去済データ: 親通貨 + FCCS_Elimination

通貨と連結の組合せを理解し、挿入位置とも呼ばれる正しい構成可能な計算ルール・テンプレート内に構成可能な計算を記述することが重要です。

例として、FCCS_30_After Opening Balance Carry Forward_Translatedは、FCCSのデフォルト換算およびFX計算で、FCCS_30で特別な注意が必要なデータがすでに処理されている場合にのみ使用することが想定されています。

構成可能な計算の記述の例

ブロック作成の問題の例および同じ計算を解決するための様々なアプローチについて考えてみます。

ユース・ケース:

2つの勘定科目に値を追加します: 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の勘定科目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などの条件付き計算の制限を適用できません。
交差の上方にゼロのデータ・ブロックを手動で導入するには、回避策が必要です。

アプローチ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メンバーに前のブロックが存在しない場合、計算の結果は表示されません。
交差の上方にゼロのデータ・ブロックを手動で導入するには、回避策が必要です。

アプローチ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: 疎メンバー・ブロックおよびボトムアップ計算の使用

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が疎ディメンションであるデータ・ソースであるため、これは疎計算です。
メンバー・ブロックの計算はボトムアップで実行されます。
FCCS_Managed Dataはこの計算のソースです。結果のブロックは、データ・ブロックがソースに存在する場合にのみ、FCCS_Other Dataに作成されます。
計算の右側にディメンション間演算子は必要ありません。
この割当ての左側にディメンション間演算子が存在するため、計算をボトムアップとして明示的に指定する必要があります。

ブロック・モードとセル・モードの計算

ブロック・モード: (デフォルト・モード)この計算モードでは、Essbaseはブロック内のセルをグループ化し、各グループのセルを同時に計算します。
ブロック計算モードは高速ですが、結果のデータの正確性を確保するために、ブロック内のデータの依存関係を慎重に検討する必要があります。
セル・モード: この計算モードでは、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の子の合計です
2月 - Sales Synergiesは、Returns and Allowancesの子の合計に20%を乗算したものです
残りの月 - Sales Synergiesは、Returns and Allowancesの子の合計に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の子の合計です

2月 - Sales Synergiesは、Returns and Allowancesの子の合計に20%を乗算したものです

残りの月 - Sales Synergiesは、Returns and Allowancesの子の合計に前の期間の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を使用して勘定科目を削除します
ボトムアップ処理
@LEVおよび@CURRMEMBERのかわりに、ブール@ISLEVを使用します
パフォーマンスが90%向上しました

顧客Bのユース・ケース

目的 - 一部のソース・エンティティからターゲット・エンティティにデータを移動します
データが計算されていませんでした
パフォーマンスは低く、3.5時間でした

顧客B - スクリプトの例

顧客B - スクリプトの改善

コピーを使用してターゲット・ブロックを作成します
計算はトップダウンのままです
1つのターゲット・カスタム・ディメンション・メンバーに対してのみ計算を実行します
スクリプトを汎用にするには@LIKEを使用します
時間が3.5時間から数分に短縮されました

顧客Cのユース・ケース

ユーザー・インタフェースから入力されたFCCS_Closing_Balance_Inputに基づいて増減を再分類します
パフォーマンスは低く、15分でした

顧客C - スクリプトの例の続き

顧客C - スクリプトの改善

制限されたメンバーをFIXから削除します
ボトムアップ処理
エッジ・ケースをチェックします
共通ケースを最初にチェックします。
パフォーマンスが40%向上しました

顧客Dのユース・ケース

Hyperion Financial Management、データ・ソースML_HFMから取得したデータを再分類し、ML_HFM_Calcデータ・ソース・メンバーに保存します
パフォーマンスは低く、単一期間で24時間でした
ブロックが期待どおりに作成されていなかったため、データは結合されていませんでした

顧客D - スクリプトの例

顧客D - スクリプトの改善

勘定科目密ディメンションで@ISMBRチェックを使用するのではなく、@REMOVEを使用して勘定科目を削除します
ボトムアップ処理
@LEVおよび@CURRMEMBERのかわりに、ブール@ISLEVを使用します
パフォーマンスが90%向上しました

顧客Eのユース・ケース

連結メソッドが現在の期間で変更され、以前の期間のすべての累積CTAおよび消去処理を削除する必要がありました
パフォーマンスは低く、90分でした

顧客E - スクリプトの改善

ターゲットでData_Inputを使用して、FCCS_Intercompany_Eliminationsへの書込みに関する検証エラーを回避します
期末残高入力のある走査ICPメンバーでボトムアップを使用します
時間が90分から11分に短縮されました

ベスト・プラクティスのサマリー

ボトムアップ処理
勘定科目密ディメンションで@ISMBRチェックを使用するのではなく、@REMOVEを使用して勘定科目を削除します
@LEVおよび@CURRMBRのかわりに、ブール@ISLEVを使用します
制限されたメンバーをFIXから削除します
アンカーによる方法が機能しない場合は、コピーを使用してターゲット・ブロックを作成します
1つのターゲット・カスタム・ディメンション・メンバーに対してのみ計算を実行します
スクリプトを汎用にするには@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指定します。ボトムアップ処理は複数のブロックに関係し、疎ディメンションは1つのブロックを定義します。
同じ計算を実行する場合、UDA勘定科目へのFIX指定と組み合せることでユーザー定義属性(UDA)が最適に処理されます。
次の例は、指定したすべてのUDAが、資産/負債/資本勘定科目タイプで定義されていることを前提としています。
FCCS_Net Incomeを基準にしたレベル0の勘定科目ディメンション・メンバーをFIX指定します
パフォーマンスを向上させるため、@LEVを使用してメンバーのレベルを計算するかわりにブール関数を使用します
ブール関数@ISDESCを使用して、メンバーが子孫かどうかを確認します。これは常にリーフ・メンバーです。

例: UDAに基づいた期末残高入力へのデータ入力と増減の計算

IF条件を使用する最善の方法

IFを使用して条件文を作成する一般的な例を次に示します。この例では、1月に特定のプロセスを実行しますが、他の月については別の操作を行います。計算が次のように作成されている場合、1月が常に最初にチェックされるため、1月以外のすべての期間ではチェックが12回行われた後、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を使用した書換え

12の期間のうち11がIF句を使用して実行された後に条件分岐から抜けるようにIF文を書き換えることができます。1月のみがELSE句で1回実行されます。

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"で空のブロックを作成し、そのブロックを使用してすべての計算を実行します。たとえば、製品カスタム・ディメンションに1000件のカスタム・メンバーが含まれている場合は、@"No Product"という1つのブロックを作成し、"No Product"をFIX指定して、ボトムアップ処理を使用できます。システムでは製品ディメンションの1000メンバー全件をループする必要はなく、合計値の"Total Product"を使用できるので、全体的なパフォーマンスが向上します。

次の例は、計算スクリプトのサンプルを示しています。

ボトムアップ処理を使用したFCCS_10メンバー・ブロックの計算

@CALCMODE(BOTTOMUP)を使用して、メンバー・ブロックの計算をまとめます。
FIXメンバーが計算全体で同じである場合は、複数のFIX...ENDFIXの計算を1つの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を計算して、再分類を試みる必要があります。