リスト

リストに関連する Planual のルール

階層には、階層の名前を示す文字とレベルを示す数字を先頭に付ける必要があります  (例: P1 Product Category、P2 Product Family、P3 Products)。 リストの先頭に「L」を追加する必要はありません。

命名規則の推奨事項

コードを使用すると、リストの読み込みと使用がより効率的になるため、常にリスト用のコードを用意するように努めてください。 これは番号付きリストの場合に特に重要です。

リスト プロパティはライン アイテムと同じですが、多くの制限があるため、シンプルにして計算用の場所を 1 か所にしてください (例: Module.Line Item)。

データ ハブとピーク時のパフォーマンス

番号付きリストで作成アクションか割り当てアクションを使用している場合は、別のプロセスの一部として「コード作成」アクションを組み込んでみてください。

階層管理
データ ハブ:目的とピーク時のパフォーマンス

番号付きリストの表示名プロパティはテキスト形式ではなくリスト形式にしてください。これにより効率性の向上、ライン アイテムの節約、テキスト フィールド数の最小化、マッピングの簡素化が実現されます。 ただし、この目的のためだけに別のリストを作成することは推奨されていません。可能であれば既存のリストを使用してください。

通貨コード、True/False (インジケーター)、または複合リストの子ではなく、合計が必要なリストにのみトップ レベルを使用します。

トップ レベル アイテムと親階層

大きなリストではトップ レベルの計算は分割できないため、リストが大きくなるにつれて計算効率が下がっていきます。 本当に合計が必要かどうかを検討してください。合計が必要な場合は、中間の親「合計」を追加して計算を効率化するか、SUM を使用して検証のために集計してください。

トップ レベル アイテムと親階層

複合リストは柔軟性と計算の効率性が高いため、可能な限り階層の「バランス」を保つようにしてください。

バランスが取れている階層とそうでない階層

プレースホルダーを追加して General Lists を整理し、General Lists の下部にサブセットとライン アイテム サブセットを追加します。 これにより、「Applies To」(適用先) でサブセットとライン アイテム サブセットを参照するときに、それらを簡単に区別できるようになります。 プレースホルダー リストには絵文字を使用しても問題ありません。

リストをクリアして再読み込みすると、モデル内の構造上の変更が増加し、モデルが保存される可能性が高くなります。これによってインポート時間が長くなります。 また、効率を高めるために事前に割り当てられたメモリ ブロックも削除されます。値を更新するには、削除して再読み込みするのではなく、一意のキーを使用してください。また、どのレコードがインポートされたかを把握できるように、データ ソースに TRUE フィールドを追加することも検討してください。

データ ハブ:目的とピーク時のパフォーマンス
リスト内の事前割り当てとモデルのパフォーマンスへの影響

日付と値は「データ」であるため、コードの一部にしないでください。 これらの要素をコードに追加すると、通常はリストのサイズが大幅に増加し、その結果モデル サイズが増大してパフォーマンスが低下します。

データ ハブ:目的とピーク時のパフォーマンス

リストのコードに基づいて属性を導出できます。値の計算はテキスト フィールドの保存よりも効率的です。

データ ハブ:目的とピーク時のパフォーマンス

データ ハブには階層を作らないでください。これらはメインのプランニング モデルにのみ適用してください。