リストに関連する Planual のルール
1.05-01 命名規則
階層には、階層の名前を示す文字とレベルを示す数字を先頭に付ける必要があります (例: P1 Product Category、P2 Product Family、P3 Products)。 リストの先頭に「L」を追加する必要はありません。
relatedToRule
bestPracticesArticles
1.05-02 常にコードを使用する
コードを使用すると、リストの読み込みと使用がより効率的になるため、常にリスト用のコードを用意するように努めてください。 これは番号付きリストの場合に特に重要です。
exception
| 1.05-02a 静的な非階層リスト | 単純な静的リスト (Yes/No など) の場合はコードがなくても問題ありませんが、その場合でも Y と N をコードとして使用できます。 |
1.05-03 リスト プロパティの使用は避ける
| リスト プロパティはライン アイテムと同様に動作しますが、計算方式 (Polaris のみ) や計算負荷といった、ブループリント インサイトは備えていません。最適なパフォーマンスとモデルの監査のしやすさを維持するため、式にリスト プロパティを使用することは避けてください。代わりに、モジュール内のライン アイテムを使用して、計算を一元化し、シンプルに保ちます。 対象となるエンジン: Classic Hyperblock と Polaris |
exception
| 1.05-03a モジュール ライン アイテムを参照する | 次の例外が使用される場合は、監査証跡を有効に保つために、可能な限り式を通じてモジュール ライン アイテムを参照してください。 |
| 1.05-03b 番号付きリスト (及び関連アクション) | 割り当てアクションと関連フィルターにはリスト プロパティが必要です。 |
| 1.05-03c エクスポート | リスト プロパティはエクスポート ラベルとして使用できます。 |
| 1.05-03d 条件付きページ ナビゲーション | リスト プロパティは、リスト内の選択内容に応じてさまざまなダッシュボードへのナビゲーションを容易にするうえで必要です。 |
| 1.05-03e 依存ドロップダウン | リスト プロパティはドライバーと依存リストを作成するために必要です。 |
bestPracticesArticles
1.05-04 番号付きリストのコードをインポートまたは生成する
| 番号付きリストでは、各アイテムの表示名が時間の経過とともに変化する可能性があり、かつ一意である必要もないため、各アイテムに一意のコードが必要となります。コードがないリストでは、インポート時のデータ マッピングが大幅に困難になり、FINDITEM のようなルックアップ関数を使用することもできなくなります。エンド ユーザーが作成アクションや割り当てアクションによってアイテムを追加する場合、自動化プロセスの一環としてコードを自動的に生成して割り当てるコード作成アクションを、必ずその後のプロセスに組み込んでください。 対象となるエンジン: Classic Hyperblock と Polaris |
exception
| 1.05-04a プロパティの組み合わせ | ソースにコードがない場合は、プロパティの組み合わせを使用する必要があります。 これはインポートに時間がかかり、コードなしで使用するのがより困難になるため、可能であれば避けてください。 |
relatedToRule
bestPracticesArticles
1.05-05 可能であれば表示名プロパティをリスト形式にする
| 番号付きリストの表示名プロパティはテキスト形式ではなくリスト形式にしてください。これにより効率性の向上、ライン アイテムの節約、テキスト フィールド数の最小化、マッピングの簡素化が実現されます。ただし、この目的のためだけに別のリストを作成することは推奨されていません。可能であれば既存のリストを使用してください。 対象となるエンジン: Classic Hyperblock と Polaris |
1.05-06 最終的な親にはトップ レベルのみを使用する
通貨コード、True/False (インジケーター)、または複合リストの子ではなく、合計が必要なリストにのみトップ レベルを使用します。
bestPracticesArticles
1.05-07 大きなフラット リストではトップ レベルを使用しない
大きなリストではトップ レベルの計算は分割できないため、リストが大きくなるにつれて計算効率が下がっていきます。 本当に合計が必要かどうかを検討してください。合計が必要な場合は、中間の親「合計」を追加して計算を効率化するか、SUM を使用して検証のために集計してください。
bestPracticesArticles
1.05-08 不規則なリストではなく複合リストを使用する
複合リストは柔軟性と計算の効率性が高いため、可能な限り階層の「バランス」を保つようにしてください。
exception
| 1.05-08a 会計レポート又は財務レポートの階層のチャート | 会計レポート又は財務レポートの階層のチャートは、非複合リストの有効な使用法です。 |
bestPracticesArticles
1.05-09 General Lists にプレースホルダーを作成する
プレースホルダーを追加して General Lists を整理し、General Lists の下部にサブセットとライン アイテム サブセットを追加します。 これにより、「Applies To」(適用先) でサブセットとライン アイテム サブセットを参照するときに、それらを簡単に区別できるようになります。 プレースホルダー リストには絵文字を使用しても問題ありません。
relatedToRule
1.05-10 リストは決して削除せず、毎日のようにリストを再読み込みしない
リストをクリアして再読み込みすると、モデル内の構造上の変更が増加し、モデルが保存される可能性が高くなります。これによってインポート時間が長くなります。 また、効率を高めるために事前に割り当てられたメモリ ブロックも削除されます。値を更新するには、削除して再読み込みするのではなく、一意のキーを使用してください。また、どのレコードがインポートされたかを把握できるように、データ ソースに TRUE フィールドを追加することも検討してください。
bestPracticesArticles
1.05-11 リストのコード内に数値または日付を埋め込まない
日付と値は「データ」であるため、コードの一部にしないでください。 これらの要素をコードに追加すると、通常はリストのサイズが大幅に増加し、その結果モデル サイズが増大してパフォーマンスが低下します。
bestPracticesArticles
1.05-12 式を使用してリストのプロパティを導出する
リストのコードに基づいて属性を導出できます。値の計算はテキスト フィールドの保存よりも効率的です。
bestPracticesArticles
1.05-13 フラット リストを使用してメタデータを (システム モジュールに) 保存する
データ ハブには階層を作らないでください。これらはメインのプランニング モデルにのみ適用してください。
