不十分なルール設計のチェック
正しい結果と最適なパフォーマンスを確保するには、ベスト・プラクティスとして、計算が実行されるディメンションおよびメンバーを常に指定します。
連結ルールのパフォーマンスを最適化するには、計算の範囲を必要なディメンションとメンバーに制限する必要があります。必要なディメンションとメンバーを計算に追加しない場合、可能性があるすべてのメンバーの組合せに対してルールが実行されます。たとえば、次のサンプル・ルールでは、カスタム・ディメンション・メンバーNo Department
に対してのみ計算を実行する必要があります。ソースにディメンション・メンバーを追加すると、No Department
に対してのみルールを実行することで、実行が高速になります。
ルールのソース(勘定科目ディメンション)の複数の保管済メンバーのチェック
連結ルールのソースにある多数のレベル0の保管済勘定科目が単一の宛先勘定科目にリダイレクトされた場合、パフォーマンスが低下する可能性があります。そのようなシナリオでは、保管済データ・ストレージを含むプレース・ホルダー勘定科目メンバーを作成し、FCCS_110 (単一通貨アプリケーション)またはFCCS_30 (複数通貨アプリケーション)に挿入ルールを記述して、子の金額をそこにリダイレクトすることをお薦めします。その後で、動的な親のかわりに連結ルールのソースでプレース・ホルダー勘定科目を使用して、ルールの実行を高速化できます。
ユース・ケース: 構成可能な連結ルールをデプロイした後のパフォーマンス問題の解決
この例では、100個のP/L勘定科目(Acc_001からAcc_100)が、アプリケーションの多数のP/L勘定科目の1つである動的な親Retained Earnings Current
の下に存在すると想定しています。次の図を参照してください。
次の図は、参照を通してRetained Earnings Current
をソースとして直接的または間接的に使用するルールを示しています。
前述の間接参照では、Retained Earnings Current
のすべてのレベル0の子はTotal Equity
の下にあるため、間接的にソースに含まれます。
ルール定義を変更し、リダイレクト・スクリプトを追加してルールの実行を高速にするには、次の手順が必要です:
Retained Earning_Memoという名前のメモ勘定科目をFCCS_BalanceSheetの下に作成します。集計演算子を無視(~)に設定し、データ・ストレージを「保管」に設定します。他のすべてのプロパティは、動的な親のプロパティと同じになります。次の図に示すように、Retained Earning_Memoプレース・ホルダー勘定科目は、Retained Earnings Currentの値を保持します。
SET HYBRIDBSOINCALCSCRIPT NONE;// Use with Hybrid environments only. FIX("FCCS_Entity Input", "Parent Currency", "Opening Balance", @RELATIVE("FCCS_Total Data Source", 0), @RELATIVE("FCCS_Intercompany Top", 0)) "Retained Earning_Memo" ( @CALCMODE(BOTTOMUP); @SUM(@RELATIVE("FCCS_Retained Earnings Current", 0) AND @LIST(@UDA("Account", "REVENUE") OR @UDA("Account", "LIABILITY") OR @UDA("Account", "EQUITY") OR @UDA("Account", "SAVED ASSUMPTION"))) - @SUM(@RELATIVE("FCCS_Retained Earnings Current", 0) AND @LIST(@UDA("Account", "EXPENSE") OR @UDA("Account", "ASSET"))); ) ENDFIX
次の図は、このユース・ケースの推奨事項を実装した後のルールを示しています。
次の図は、このユース・ケースの推奨事項を実装した後のルールを示しています。