構成済み ER コンポーネントを検査して、ランタイムの問題を回避する

構成された電子レポート (ER)形式とモデル マッピングは、デザイン時に検証できます。 この検証中は、実行エラーやパフォーマンスの低下などの実行時の問題を防ぐために、整合性チェックが実行されます。 チェックによって検出されるすべての問題について、問題のある要素のパスが提供されます。 一部の問題については、自動修正を利用できます。

既定では、検証は、前述の ER コンポーネントを含む ER 構成に対して、次の場合に自動的に実行されます。

• ER 構成の新しい バージョン を Microsoft Dynamics 365 Finance のインスタンスに インポート します。
• 編集可能な ER 構成の状態を ドラフト から 完了 に変更します。
• 新しい基本バージョンを適用することにより、編集可能な ER 構成を リベース します。

この検証を明示的に実行することもできます。 次の 3 つのオプションのいずれかを選択し、指定されている手順に従います:

• オプション 1:

  1. 組織管理 > 電子申告 > コンフィギュレーションの順に移動します。
  2. 左側のペインにある構成ツリーで、ER 形式または ER モデル マッピング コンポーネントを含む目的の ER 構成を選択します。
  3. バージョン クイック タブで、選択した ER 構成の目的のバージョンを選択します。
  4. アクション ペインで、検証を選択します。

• オプション 2、ER 形式の場合:

  1. 組織管理 > 電子申告 > コンフィギュレーションの順に移動します。
  2. 左側のペインにある構成ツリーで、ER 形式のコンポーネントを含む目的の ER 構成を選択します。
  3. バージョン クイック タブで、選択した ER 構成の目的のバージョンを選択します。
  4. アクション ウィンドウで、デザイナーを選択します。
  5. 形式デザイナー ページのアクション ペインで、検証 を選択します。

• オプション 3、ER モデル マッピングの場合:

  1. 組織管理 > 電子申告 > コンフィギュレーションの順に移動します。
  2. 左側のペインにある構成ツリーで、ER モデル マッピング コンポーネントを含む目的の ER 構成を選択します。
  3. バージョン クイック タブで、選択した ER 構成の目的のバージョンを選択します。
  4. アクション ウィンドウで、デザイナーを選択します。
  5. モデルからデータ ソースへのマッピング ページのアクション ペインで、デザイナー を選択します。
  6. モデル マッピング デザイナー ページのアクション ペインで、検証 を選択します。

構成をインポートするときに検証をスキップするには、次の手順に従います。

1. 組織管理 > 電子申告 > コンフィギュレーションの順に移動します。
2. 構成ページ、アクション ウィンドウ、構成タブ、詳細設定グループで、ユーザー パラメーターを選択します。
3. インポート後に構成を検証 オプションを いいえ に設定します。

バージョンの状態を変更またはリベースするときに検証をスキップするには、次の手順に従います。

1. 組織管理 > 電子申告 > コンフィギュレーションの順に移動します。
2. 構成ページ、アクション ウィンドウ、構成タブ、詳細設定グループで、ユーザー パラメーターを選択します。
3. 構成状態の変更時およびリベース時に検証をスキップ オプションを はい に設定します。

ER では、次のカテゴリを使用して、整合性チェック検査をグループ化します:

• 実行可能性 – 実行時に発生する可能性がある重大な問題を検出する検査。 これらの問題は、ほとんどが エラー レベルです。
• パフォーマンス – 構成済み ER コンポーネントの非効率な実行を引き起こす可能性のある問題を検出する検査。 これらの問題は、ほとんどが 警告 レベルです。
• データの整合性 – データ損失または実行時の問題を引き起こす可能性のある問題を検出する検査。 これらの問題は、ほとんどが 警告 レベルです。

検査の一覧

次の表は、ER が提供する検査の概要を示します。 これらの検査の詳細については、最初の列のリンクを使用して、この記事の関連するセクションを参照してください。 これらのセクションでは、ER が検査を提供するコンポーネントのタイプと、問題を防ぐために ER コンポーネントを再構成する方法について説明します。

型変換

ER は、データ モデル フィールドのデータ型が、そのフィールドのバインドとして構成する式のデータ型と互換性があるかどうかをチェックします。 データ型に互換性がない場合、ER モデル マッピング デザイナーに検証エラーが表示されます。 エラー メッセージは、ER が A 型の式を型 B のフィールドに変換できないことを示しています。

次の手順は、この問題がどのように発生するかを示しています。

1. ER データ モデルと ER モデル マッピング コンポーネントの構成を同時に開始します。

2. データ モデル ツリーで、 X という名前のフィールドを追加し、データ型として [整数 ] を選択します。

   

3. モデル マッピング デザイナーの、データ ソース ペインで、計算済みフィールド タイプのデータ ソースを追加します。

4. 新しいデータソースに Y と名前を付けて、式 INTVALUE(100) を含むように構成します。

5. X を Y にバインドします。

6. データ モデル デザイナーで、X フィールドのデータ型を 整数 から Int64 に変更します。

7. 検証 を選択して、モデル マッピング デザイナー ページで編集可能なモデル マッピング コンポーネントを検査します。

   

8. 検証 を選択して、構成 ページで選択した ER 構成のモデル マッピング コンポーネントを検査します。

   

9. 検証エラーが発生することに注意してください。 このメッセージは、Y データ ソースの INTVALUE(100) 式が返す 整数 タイプの値を、Int64 タイプの X データ モデル フィールドに格納できないことを示しています。

次の図は、警告を無視し、実行 を選択して、モデル マッピングを使用するように構成された形式を実行した場合に発生するランタイム エラーを示しています。

自動解決

この問題を自動的に修正するオプションはありません。

手動解決

オプション 1

データ モデル フィールドのデータ型を変更して、そのフィールドのバインド用に構成した式のデータ型と一致するようにデータ モデル構造を更新します。 前の例では、 X フィールドのデータ型を 整数に戻します。

オプション 2

データ モデル フィールドにバインドするデータ ソースの式を変更して、モデル マッピングを更新します。 前の例では、 Y データ ソースの式を INT64VALUE(100) に変更します。

タイプの互換性

ER は、書式要素のデータ型が、その書式要素のバインドとして構成する式のデータ型と互換性があるかどうかをチェックします。 データ型に互換性がない場合は、ER 操作デザイナーで検証エラーが発生します。 受信するメッセージは、構成された式をデータ ソースへの現在の書式要素のバインドとして使用できないことを示します。これは、式が、型 B の現在の書式要素でサポートされているデータ型の範囲を超えるデータ型 A の値を返すからです。

次の手順は、この問題がどのように発生するかを示しています。

1. ER データ モデルと ER 形式コンポーネントの構成を同時に開始します。

2. データ モデル ツリーで、 X という名前のフィールドを追加し、データ型として [整数 ] を選択します。

3. 形式構造ツリーで、数値 タイプの形式要素を追加します。

4. 新しい形式要素 Y に名前を付けます。数値タイプ フィールドで、データ型として 整数 を選択します。

5. X を Y にバインドします。

6. 形式構造ツリーで、Y 形式要素のデータ型を 整数 から Int64 に変更します。

7. 検証 を選択して、形式デザイナー ページで編集可能な形式コンポーネントを検査します。

   

8. 検証エラーが発生することに注意してください。 メッセージは、構成済みの式が Int64 値のみを受け入れることができることを示しています。 したがって、整数 タイプの X データ モデル フィールドの値を Y 形式要素に入力することはできません。

自動解決

この問題を自動的に修正するオプションはありません。

手動解決

オプション 1

数値 形式要素のデータ型を変更して、その要素のバインドに対して構成された式のデータ型と一致するように、形式構造を更新します。 前の例では、X 書式要素の数値型の値を整数に戻します。

オプション 2

から model.X に式をに変更して、INT64VALUE(model.X) 形式要素の形式マッピングを更新します。

構成要素の欠落

ER は、編集可能な ER コンポーネントが構成するデータ ソースのみがバインド式に含まれているかどうかを確認します。 編集可能な ER コンポーネントが存在しないデータ ソースを含むバインドごとに、ER 操作デザイナーまたは ER モデル マッピング デザイナーで検証エラーが発生します。

次の手順は、この問題がどのように発生するかを示しています。

1. ER データ モデルと ER モデル マッピング コンポーネントの構成を同時に開始します。

2. データ モデル ツリーで、 X という名前のフィールドを追加し、データ型として [整数 ] を選択します。

   

3. モデル マッピング デザイナーの、データ ソース ペインで、計算済みフィールド タイプのデータ ソースを追加します。

4. 新しいデータソースに Y と名前を付けて、式 INTVALUE(100) を含むように構成します。

5. X を Y にバインドします。

6. モデル マッピング デザイナーの、データ ソース ペインで、Y データ ソースを削除します。

7. 検証 を選択して、モデル マッピング デザイナー ページで編集可能なモデル マッピング コンポーネントを検査します。

   

8. 検証エラーが発生することに注意してください。 メッセージは、X データ モデル フィールドのバインドに Y データソースを参照するパスが含まれているが、このデータ ソースは見つからないことを示しています。

自動解決

バインドの解除 を選択して、欠落したデータ ソース バインドを削除することで、この問題を自動的に修正します。

手動解決

オプション 1

X データ モデル フィールドのバインドを解除して、存在しない Y データ ソースを参照しないようにします。

オプション 2

モデル マッピング デザイナーのデータ ソース ペインで、Y データ ソースを再度追加します。

FILTER 関数による式の実行可能性

組み込みの FILTER ER 関数を使用して、アプリケーション のテーブル、ビュー、またはデータ エンティティにアクセスします。 この関数は、1 つの SQL 呼び出しを行って、必要なデータをレコードの一覧として取得します。 この関数の引数として Record リスト 型のデータ ソースを使用して、呼び出しのアプリケーション ソースを指定します。 ER は、 FILTER 関数で参照するデータ ソースに対して直接 SQL クエリを確立できるかどうかを確認します。 直接クエリを確立できない場合、ER モデル マッピング デザイナーに検証エラーが表示されます。 エラー メッセージは、 FILTER 関数を含む ER 式を実行時に実行できないことを示しています。

次の手順は、この問題がどのように発生するかを示しています。

1. ER モデル マッピング コンポーネントの構成を開始します。

2. Dynamics 365 for Operations \ テーブル レコード タイプのデータ ソースを追加します。

3. 新しいデータ ソースに Vendor と名前を付けます。 [ テーブル ] フィールドで、 VendTable を選択して、このデータ ソースが VendTable テーブルを要求するように指定します。

4. 計算済フィールド タイプのデータ ソースを追加します。

5. 新しいデータ ソースに FilteredVendor と名前を付けて、式 FILTER(Vendor, Vendor.AccountNum="US-101") を含むように構成します。

6. 検証 を選択して、モデル マッピング デザイナー ページで編集可能なモデル マッピング コンポーネントを検査し、FILTER(Vendor, Vendor.AccountNum="US-101") データ ソースの 式を照会できることを確認します。

7. 計算済フィールド タイプの入れ子になったフィールドを追加して、Vendor データ ソースを変更し、トリムされた仕入先番号を取得します。

8. 新しい入れ子になったフィールドに $AccNumber と名前を付けて、式 TRIM(Vendor.AccountNum) を含むように構成します。

9. 検証 を選択して、モデル マッピング デザイナー ページで編集可能なモデル マッピング コンポーネントを検査し、FILTER(Vendor, Vendor.AccountNum="US-101") データ ソースの 式を照会できることを確認します。

   

10. Vendor データ ソースには、FilteredVendor データソースの式を直接 SQL ステートメントに変換できない 計算済フィールド タイプの入れ子になったフィールドが含まれているため、検証エラーが発生することに注意してください。

次の図は、警告を無視し、実行 を選択して、モデル マッピングを使用するように構成された形式を実行した場合に発生するランタイム エラーを示しています。

自動解決

この問題を自動的に修正するオプションはありません。

手動解決

オプション 1

計算済フィールド タイプの入れ子になったフィールドを Vendor データ ソースに追加するのではなく、$AccNumber の入れ子になったフィールドを FilteredVendor データ ソースに追加し、式 TRIM(FilteredVendor.AccountNum) を含むように構成します。 この方法を使用すると、SQL レベルで FILTER(Vendor, Vendor.AccountNum="US-101") 式を実行し、後で入れ子になった $AccNumber フィールドを計算できます。

オプション 2

FilteredVendor データ ソースの式を FILTER(Vendor, Vendor.AccountNum="US-101") から WHERE(Vendor, Vendor.AccountNum="US-101") に変更します。 この変更ではすべてのレコードがフェッチされ、メモリ内の必要なレコードが選択されるため、大量のデータを含むテーブル (トランザクション テーブル) の式は変更しないでください。 したがって、この方法ではパフォーマンスが低下する可能性があります。 詳細については、WHERE ER 関数 を参照してください。

GROUPBY データ ソースの実行可能性

GROUPBY データ ソースは、クエリ結果をレコードのグループに分割します。通常は、各グループに対して 1 つ以上の集計を実行します。 すべての GROUPBY データ ソースを、データベース レベルまたはメモリ内で実行するように構成できます。 GROUPBY データ ソースをデータベース レベルで実行するように構成すると、ER は GROUPBY データ ソースが参照するデータ ソースへの直接 SQL クエリを作成できるかどうかを確認します。 ER で直接クエリを作成できない場合、ER モデル マッピング デザイナーに検証エラーが表示されます。 エラー メッセージは、構成された GROUPBY データ ソースを実行時に実行できないことを示しています。

次の手順は、この問題がどのように発生するかを示しています。

1. ER モデル マッピング コンポーネントの構成を開始します。

2. Dynamics 365 for Operations \ テーブル レコード タイプのデータ ソースを追加します。

3. 新しいデータ ソースに Trans という名前を 付けます。[ テーブル ] フィールドで、 VendTrans を選択して、このデータ ソースが VendTrans テーブルを要求するように指定します。

4. Group by タイプのデータ ソースを追加します。

5. 新しいデータ ソースに GroupedTrans と名前を付けて、次のように構成します:

   • グループ化するレコードのソースとして Trans データ ソースを選択します。
   • 実行場所 フィールドで クエリ を選択し、このデータ ソースをデータベース レベルで実行することを指定します。

   

6. [ 検証 ] を選択して、[ モデル マッピング デザイナー ] ページで編集可能なモデル マッピング コンポーネントを確認し、構成 された GroupedTrans データ ソースに対してクエリを実行できることを確認します。

7. 計算済フィールド タイプの入れ子になったフィールドを追加して、Trans データ ソースを変更し、トリムされた仕入先番号を取得します。

8. 新しいデータ ソースに $AccNumber と名前を付けて、式 TRIM(Trans.AccountNum) を含むように構成します。

   

9. [ 検証 ] を選択して、[ モデル マッピング デザイナー ] ページで編集可能なモデル マッピング コンポーネントを確認し、構成 された GroupedTrans データ ソースに対してクエリを実行できることを確認します。

   

10. Trans データ ソースには、GroupedTrans データソースの呼び出しを直接 SQL ステートメントに変換できない 計算済フィールド タイプの入れ子になったフィールドが含まれているため、検証エラーが発生することに注意してください。

次の図は、警告を無視し、実行 を選択して、モデル マッピングを使用するように構成された形式を実行した場合に発生するランタイム エラーを示しています。

自動解決

この問題を自動的に修正するオプションはありません。

手動解決

オプション 1

計算済フィールド タイプの入れ子になったフィールドを Trans データ ソースに追加するのではなく、GroupedTrans データ ソースの GroupedTrans.lines 項目に、$AccNumber の入れ子になったフィールドを追加し、式 TRIM(GroupedTrans.lines.AccountNum) を含むように構成します。 この方法では、SQL レベルで GroupedTrans データ ソースを実行し、後で入れ子になった フィールド$AccNumber 計算できます。

オプション 2

GroupedTrans データ ソースの 実行場所 フィールドの値を クエリ から メモリ内 に変更します。 この変更ではすべてのレコードがフェッチされ、メモリ内のグループ化と集計が行われるため、大量のデータ (トランザクション テーブル) があるテーブルの値は変更しないでください。 したがって、この方法ではパフォーマンスが低下する可能性があります。

JOIN データ ソースの実行可能性

JOIN データ ソースは、関連するフィールドに基づいて 2 つ以上のデータベース テーブルのレコードを組み合わせたものです。 すべての JOIN データ ソースを、データベース レベルまたはメモリ内で実行するように構成できます。 データベース レベルで実行するように JOIN データ ソースを構成すると、ER は、データ ソースが参照するデータ ソースに対して直接 SQL クエリを作成できるかどうかを確認します。 ER が少なくとも 1 つの参照先データ ソースへの直接 SQL クエリを作成できない場合、ER モデル マッピング デザイナーに検証エラーが表示されます。 エラー メッセージは、構成された JOIN データ ソースを実行時に実行できないことを示します。

次の手順は、この問題がどのように発生するかを示しています。

1. ER モデル マッピング コンポーネントの構成を開始します。

2. Dynamics 365 for Operations \ テーブル レコード タイプのデータ ソースを追加します。

3. 新しいデータ ソースに Vendor と名前を付けます。 [ テーブル ] フィールドで、 VendTable を選択して、このデータ ソースが VendTable テーブルを要求するように指定します。

4. Dynamics 365 for Operations \ テーブル レコード タイプのデータ ソースを追加します。

5. 新しいデータ ソースに Trans という名前を 付けます。[ テーブル ] フィールドで、 VendTrans を選択して、このデータ ソースが VendTrans テーブルを要求するように指定します。

6. 計算済フィールド タイプのデータソースを Vendor データソースの入れ子になったフィールドとして追加します。

7. 新しいデータ ソースに FilteredTrans と名前を付けて、式 FILTER(Trans, Trans.AccountNum=Vendor.AccountNum) を含むように構成します。

8. Join タイプのデータ ソースを追加します。

9. 新しいデータ ソースに JoinedList と名前を付けて、次のように構成します:

   1. Vendor データ ソースを、結合するレコードの最初のセットとして追加します。
   2. Vendor.FilteredTrans データ ソースを、結合するレコードの 2 番目のセットとして追加します。 タイプとして INNER を選択します。
   3. 実行 フィールドで クエリ を選択し、このデータ ソースをデータベース レベルで実行することを指定します。

   

10. 検証 を選択して、モデル マッピング デザイナー ページで編集可能なモデル マッピング コンポーネントを検査し、構成済み JoinedList データ ソースを照会できることを確認します。

11. Vendor.FilteredTrans データ ソースの式を FILTER(Trans, Trans.AccountNum=Vendor.AccountNum) から WHERE(Trans, Trans.AccountNum=Vendor.AccountNum) に変更します。

12. 検証 を選択して、モデル マッピング デザイナー ページで編集可能なモデル マッピング コンポーネントを検査し、構成済み JoinedList データ ソースを照会できることを確認します。

    

13. Vendor.FilteredTrans データ ソースの式を直接 SQL 呼び出しに変換できないため、検証エラーが発生することに注意してください。 さらに、直接 SQL 呼び出しでは、JoinedList データソースに対する呼び出しを、直接 SQL ステートメントに変換することはできません。

    

次の図は、警告を無視し、実行 を選択して、モデル マッピングを使用するように構成された形式を実行した場合に発生するランタイム エラーを示しています。

自動解決

この問題を自動的に修正するオプションはありません。

手動解決

オプション 1

警告が示すように、 Vendor.FilteredTrans データ ソースの式を WHERE(Trans, Trans.AccountNum=Vendor.AccountNum) から FILTER(Trans, Trans.AccountNum=Vendor.AccountNum)に戻します。

オプション 2

JoinedList データ ソースの 実行 フィールドの値を クエリ から メモリ内 に変更します。 この変更ではすべてのレコードがフェッチされ、結合がメモリ内で行われるため、大量のデータを含むテーブル (トランザクション テーブル) の値は変更しないでください。 したがって、この方法ではパフォーマンスが低下する可能性があります。 検証の警告によって、このリスクが通知されます。

FILTER 関数 対 WHERE 関数の優先度

組み込みの FILTER ER 関数を使用して、アプリケーション のテーブル、ビュー、またはデータ エンティティにアクセスします。 1 つの SQL 呼び出しを行って、必要なデータをレコードの一覧として取得します。 WHERE 関数は、指定されたソースからすべてのレコードをフェッチし、メモリ内でレコード選択を行います。 どちらの関数も、 引数として Record リスト 型のデータ ソースを使用し、レコードを取得するためのソースを指定します。 ER は、 WHERE 関数で参照するデータ ソースに対して直接 SQL 呼び出しを確立できるかどうかを確認します。 直接呼び出しを確立できない場合、ER モデル マッピング デザイナーで検証警告が発生します。 受信するメッセージは、効率を向上させるために、WHERE 関数の代わりに FILTER 関数を使用することを推奨しています。

次の手順は、この問題がどのように発生するかを示しています。

1. ER モデル マッピング コンポーネントの構成を開始します。

2. Dynamics 365 for Operations \ テーブル レコード タイプのデータ ソースを追加します。

3. 新しいデータ ソースに Trans という名前を 付けます。[ テーブル ] フィールドで、 VendTrans を選択して、このデータ ソースが VendTrans テーブルを要求するように指定します。

4. 計算済フィールド タイプのデータソースを Vendor データソースの入れ子になったフィールドとして追加します。

5. 新しいデータ ソースに FilteredTrans と名前を付けて、式 WHERE(Trans, Trans.AccountNum="US-101") を含むように構成します。

6. Dynamics 365 for Operations \ テーブル レコード タイプのデータ ソースを追加します。

7. 新しいデータ ソースに Vendor と名前を付けます。 [ テーブル ] フィールドで、 VendTable を選択して、このデータ ソースが VendTable テーブルを要求するように指定します。

8. 計算済フィールド タイプのデータ ソースを追加します。

9. 新しいデータ ソースに FilteredVendor と名前を付けて、式 WHERE(Vendor, Vendor.AccountNum="US-101") を含むように構成します。

10. 検証 を選択して、モデル マッピング デザイナー ページで編集可能なモデル マッピング コンポーネントを検査します。

    

11. 検証の警告は、FilteredVendor および FilteredTrans データソースに対して WHERE 関数ではなく FILTER 機能を使用することを推奨しています。

    

自動解決

修正 を選択して、このタイプの検査の 警告 タブにあるグリッドに表示されるすべてのデータ ソースの式で、WHERE 関数を FILTER 関数に自動的に置き換えます。

または、グリッドから警告を 1 つ選択し、[修正を選択] をクリックします。 この場合、式は、選択した警告がメンションするデータ ソースでのみ自動的に変更されます。

手動解決

WHERE 関数を FILTER 関数に置き換えて、検証グリッド内のすべてのデータ ソースの式を手動で調整します。

ALLITEMSQUERY 関数 対 ALLITEMS 関数の優先度

組み込みの ALLITEMS と ALLITEMSQUERY ER 関数は、指定したパスに一致するすべての項目を表すレコードの一覧から成るフラット化された レコード リスト の値を返します。 ER は、 ALLITEMS 関数が参照するデータ ソースへの直接 SQL 呼び出しを確立できるかどうかを確認します。 ER が直接呼び出しを確立できる場合は、ER モデル マッピング デザイナーで検証警告が発生します。 受信するメッセージは、効率を向上させるために、ALLITEMS 関数の代わりに ALLITEMSQUERY 関数を使用することを推奨しています。

次の手順は、この問題がどのように発生するかを示しています。

1. ER モデル マッピング コンポーネントの構成を開始します。

2. Dynamics 365 for Operations \ テーブル レコード タイプのデータ ソースを追加します。

3. 新しいデータ ソースに Vendor と名前を付けます。 [ テーブル ] フィールドで、 VendTable を選択して、このデータ ソースが VendTable テーブルを要求するように指定します。

4. 計算済みフィールド タイプのデータ ソースを追加して、複数の仕入先のレコードを取得します。

5. 新しいデータ ソースに FilteredVendor と名前を付けて、式 FILTER(Vendor, OR(Vendor.AccountNum="US-101",Vendor.AccountNum="US-102")) を含むように構成します。

6. 計算済みフィールド タイプのデータ ソースを追加して、フィルターされたすべての仕入先のトランザクションを取得します。

7. 新しいデータ ソースに FilteredVendorTrans と名前を付けて、式 ALLITEMS(FilteredVendor.'<Relations'.'VendTrans.VendTable_AccountNum') を含むように構成します。

8. 検証 を選択して、モデル マッピング デザイナー ページで編集可能なモデル マッピング コンポーネントを検査します。

   

9. 検証警告が発生することに注意してください。 このメッセージでは、FilteredVendorTrans データ ソースに ALLITEMS 関数の代わりに ALLITEMSQUERY 関数を使用することを推奨しています。

   

自動解決

修正 を選択して、このタイプの検査の 警告 タブにあるグリッドに表示されるすべてのデータ ソースの式で、ALLITEMS 関数を ALLITEMSQUERY 関数に自動的に置き換えます。

グリッドで 1 つの警告の行を選択し、[選択項目を修正] を選択します。 この場合、式は、選択した警告がメンションするデータ ソースでのみ自動的に変更されます。

手動解決

この問題を解決するには、検証グリッドに記載されているすべてのデータ ソースの式を手動で調整します。 ALLITEMS 関数をALLITEMSQUERY 関数に置き換えます。

空リストの場合を考慮する

ER 形式またはモデル マッピング コンポーネントを構成して、レコード リスト タイプのデータ ソースのフィールド値を取得することができ ます。 ER は、呼び出したデータ ソースにレコードが含まれていない場合 (つまり、データが空の場合) がデザインで考慮されているかどうかを確認します。 このチェックにより、存在しないレコードのフィールドから値がフェッチされたときの実行時エラーを防ぐことができます。

次の手順は、この問題がどのように発生するかを示しています。

1. ER データ モデル、ER モデル マッピング、ER モデル マッピング コンポーネントの構成を同時に開始します。

2. データ モデル ツリーで、 Root3 という名前のルート項目を追加します。

3. レコード リスト タイプの入れ子になった項目を追加して、Root3 項目を変更します。

4. 新しい入れ子になった項目 Vendor に名前を付けます。

5. 次の方法で Vendor 項目を変更します:

   • 文字列 タイプの入れ子になったフィールドを追加し、Name と名前を付けます。
   • 文字列 タイプの入れ子になったフィールドを追加し、AccountNumber と名前を付けます。

   

6. モデル マッピング デザイナーの、データ ソース ペインで、Dynamics 365 for Operations \ テーブル レコード タイプのデータ ソースを追加します。

7. 新しいデータ ソースに Vendor と名前を付けます。 [ テーブル ] フィールドで、 VendTable を選択して、このデータ ソースが VendTable テーブルを要求するように指定します。

8. 全般 \ ユーザー入力パラメーター タイプのデータ ソースを追加し、ランタイム ダイアログ ボックスで仕入先アカウントを検索します。

9. 新しいデータ ソースに RequestedAccountNum と名前を付けます。 ラベル フィールドに、仕入先番号 を入力します。 [ 操作データ型名 ] フィールドで、既定値の [説明] をそのまま使用します。

10. 計算フィールド型のデータ ソースを追加して、ユーザーが照会するベンダーをフィルター処理します。

11. 新しいデータ ソースに FilteredVendor と名前を付けて、式 FILTER(Vendor, Vendor.AccountNum=RequestedAccountNum) を含むように構成します。

12. 次の方法で、構成されたデータ ソースにデータ モデル項目をバインドします:

    • FilteredVendor を Vendor にバインドします。
    • FilteredVendor.AccountNum を Vendor.AccountNumber にバインドします。
    • FilteredVendor.'name()' を Vendor.Name にバインドします。

    

13. 形式構造ツリーで、次の項目を追加して、仕入先の詳細を含む送信ドキュメントを XML 形式で生成します:

    1. Statement ルート XML 要素を追加します。

    2. Statement XML 要素の場合は、入れ子になった Party XML 要素を追加します。

    3. Party XML 要素の場合は、次の入れ子になった XML 属性を追加します:

       • 氏名
       • AccountNum

14. 次の方法で、形式要素を指定されたデータ ソースにバインドします:

    • Statement\Party\Name 形式要素を model.Vendor.Name データ ソース フィールドにバインドします。
    • Statement\Party\AccountNum 形式要素を model.Vendor.AccountNumber データ ソース フィールドにバインドします。

15. 検証 を選択して、形式デザイナー ページで編集可能な形式コンポーネントを検査します。

    

16. 検証エラーが発生することに注意してください。 メッセージは、 リストが空の場合、実行時に、構成済みの Statement\Party\Name と model.Vendor に対してエラーがスローされる可能性があることを示しています。

    

次の図は、警告を無視し、実行 を選択して形式を実行し、存在しない仕入先のアカウント番号を選択した場合に発生するランタイム エラーを示しています。 要求されたベンダーが存在しないため、 model.Vendor リストは空です (つまり、レコードが含まれません)。

自動解決

[ 警告 ] タブのグリッドで選択した行に対して、[ バインド解除] を選択します。 このアクションにより、 Path 列が指す書式要素からバインドが自動的に削除されます。

手動解決

オプション 1

Statement\Party\Name 形式要素をmodel.Vendorデータ ソース項目にバインドします。 実行時に、このバインドは model.Vendor データ ソースを最初に呼び出します。 model.Vendorが空のレコード リストを返すと、入れ子になった書式要素は実行されません。 したがって、この形式構成に対して検証警告は発生しません。

オプション 2

Statement\Party\Name 形式要素のバインドを model.Vendor.Name から FIRSTORNULL(model.Vendor).Name に変更します。 更新されたバインドは、model.Vendor タイプの データ ソースの最初のレコードを、レコード タイプの新しいデータ ソースに条件付きで変換します。 この新しいデータ ソースには、同じセットのフィールドが含まれています。

• model.Vendor データ ソースに使用可能なレコードが少なくとも 1 つある場合、そのレコードのフィールドには、model.Vendor データ ソースの最初のレコードのフィールドの値が設定されます。 この場合、更新されたバインドは仕入先名を返します。
• それ以外の場合は、作成されたレコードのすべてのフィールドは、そのフィールドのデータ型の既定値が設定されます。 この場合は、文字列 データ型の既定値として空白文字列を返します。

したがって、Statement\Party\Name の形式要素が、FIRSTORNULL(model.Vendor).Name 式にバインドされても、検証の警告は発生しません。

オプション 3

model.Vendor型の データ ソースがレコードを返さない場合に、生成されたドキュメントに入力されたデータを明示的に指定する場合 (この例では使用できないテキスト)、Statement\Party\Name 書式要素のバインドを model.Vendor.Name から IF(NOT(ISEMPTY(model.Vendor)), model.Vendor.Name, "Not available") に変更します。 式 IF(COUNT(model.Vendor)=0, model.Vendor.Name, "Not available") を使用することもできます。

その他の考慮事項

検査では、別の潜在的な問題についても警告が表示されます。 既定では、Statement\Party\Name および Statement\Party\AccountNum 形式の要素をmodel.Vendor型の データ ソースの適切なフィールドにバインドする場合、それらのバインドを実行し、そのリストが空でない場合は、model.Vendor データ ソースの最初のレコードの適切なフィールドから値を取得します。

Statement\Party 形式要素をmodel.Vendorデータ ソースにバインドしない場合、Statement\Party 要素は、フォーマットの実行中にmodel.Vendorデータ ソースのすべてのレコードを反復処理しません。 代わりに、生成されたドキュメントには、レコード リストの最初のレコードからの情報のみが入力されます (そのリストに複数のレコードが含まれている場合)。 この問題を解決するには、 Statement\Party 要素を model.Vendor データ ソースにバインドします。

FILTER 関数による式の実行可能性 (キャッシュ)

アプリケーション テーブル、ビュー、またはデータ エンティティにアクセスするには、 FILTER や ALLITEMSQUERY など、いくつかの組み込みの ER 関数を 1 回の SQL 呼び出しで実行し、必要なデータをレコードの一覧として取得します。 レコード リスト 型のデータ ソースをこれらの関数の引数として使用して、呼び出しのアプリケーション ソースを指定します。 ER は、これらの関数のいずれかで参照するデータ ソースへの直接 SQL 呼び出しを確立できるかどうかを確認します。 データ ソースを キャッシュ済みとしてマークしたために ER が直接呼び出しを確立できない場合、ER モデル マッピング デザイナーに検証エラーが表示されます。 このメッセージは、これらの関数のいずれかを含む ER 式を実行時に実行できないことを示しています。

次の手順は、この問題がどのように発生するかを示しています。

1. ER モデル マッピング コンポーネントの構成を開始します。

2. Dynamics 365 for Operations \ テーブル レコード タイプのデータ ソースを追加します。

3. 新しいデータ ソースに Vendor と名前を付けます。 [ テーブル ] フィールドで、 VendTable を選択して、このデータ ソースが VendTable テーブルを要求するように指定します。

4. 全般 \ ユーザー入力パラメーター タイプのデータ ソースを追加し、ランタイム ダイアログ ボックスで仕入先アカウントを検索します。

5. 新しいデータ ソースに RequestedAccountNum と名前を付けます。 ラベル フィールドに、仕入先番号 を入力します。 [ 操作データ型名 ] フィールドで、既定値の [説明] をそのまま使用します。

6. 計算フィールド型のデータ ソースを追加して、ユーザーが照会するベンダーをフィルター処理します。

7. 新しいデータ ソースに FilteredVendor と名前を付けて、式 FILTER(Vendor, Vendor.AccountNum=RequestedAccountNum) を含むように構成します。

8. 構成済み Vendor データ ソースをキャッシュとしてマークします。

   

9. 検証 を選択して、モデル マッピング デザイナー ページで編集可能なモデル マッピング コンポーネントを検査します。

   

10. 検証エラーが発生することに注意してください。 このメッセージは、FILTER 関数が、キャッシュされた Vendor データ ソースに適用できないことを示しています。

次の図は、警告を無視し 実行 を選択して、形式を実行した場合に、発生するランタイム エラーを示しています。

自動解決

この問題を自動的に修正するオプションはありません。

手動解決

オプション 1

Vendor データ ソースから キャッシュ フラグを削除します。 FilteredVendor データ ソースは実行可能になりますが、VendTable テーブルが参照する Vendor データ ソースには、FilteredVendor データ ソースが呼び出されるたびにアクセスされます。

オプション 2

FilteredVendor データ ソースの式を FILTER(Vendor, Vendor.AccountNum="US-101") から WHERE(Vendor, Vendor.AccountNum="US-101") に変更します。 この場合、VendTable テーブルが参照する ベンダー データ ソースには、 Vendor データ ソースの最初の呼び出し時にのみアクセスされます。 ただし、レコードの選択はメモリ内で行われます。 したがって、この方法ではパフォーマンスが低下する可能性があります。

バインドの欠落

ER 形式コンポーネントを構成する場合、基本 ER データ モデルは ER 形式の既定のデータ ソースです。 構成された ER 形式を実行すると、基本 モデルの既定のモデル マッピング によってデータ モデルにアプリケーション データが入力されます。 編集可能な形式の既定のモデル マッピングとして現在選択されているモデル マッピングのデータ ソースにバインドされていないデータ モデル項目に書式要素をバインドすると、ER 形式デザイナーに警告が表示されます。 実行時にこのタイプのバインドを実行することはできません。実行可能な形式が、バインドされた要素にアプリケーションデータを埋めることができないためです。 したがって、実行時にエラーが発生します。

次の手順は、この問題がどのように発生するかを示しています。

1. ER データ モデル、ER モデル マッピング、ER モデル マッピング コンポーネントの構成を同時に開始します。

2. データ モデル ツリーで、 Root3 という名前のルート項目を追加します。

3. レコード リスト タイプの新しい入れ子になった項目を追加して、Root3 項目を変更します。

4. 新しい入れ子になった項目 Vendor に名前を付けます。

5. 次の方法で Vendor 項目を変更します:

   • 文字列 タイプの入れ子になったフィールドを追加し、Name と名前を付けます。
   • 文字列 タイプの入れ子になったフィールドを追加し、AccountNumber と名前を付けます。

   

6. モデル マッピング デザイナーの、データ ソース ペインで、Dynamics 365 for Operations \ テーブル レコード タイプのデータ ソースを追加します。

7. 新しいデータ ソースに Vendor と名前を付けます。 [ テーブル ] フィールドで、 VendTable を選択して、このデータ ソースが VendTable テーブルを要求するように指定します。

8. 全般 \ ユーザー入力パラメーター タイプのデータ ソースを追加し、ランタイム ダイアログ ボックスで仕入先アカウントについて照会します。

9. 新しいデータ ソースに RequestedAccountNum と名前を付けます。 ラベル フィールドに、仕入先番号 を入力します。 [ 操作データ型名 ] フィールドで、既定値の [説明] をそのまま使用します。

10. 計算フィールド型のデータ ソースを追加して、ユーザーが照会するベンダーをフィルター処理します。

11. 新しいデータ ソースに FilteredVendor と名前を付けて、式 FILTER(Vendor, Vendor.AccountNum=RequestedAccountNum) を含むように構成します。

12. 次の方法で、構成されたデータ ソースにデータ モデル項目をバインドします:

    • FilteredVendor を Vendor にバインドします。
    • FilteredVendor.AccountNum を Vendor.AccountNumber にバインドします。

    メモ

    Vendor.Name データ モデル フィールドはバインド解除されたままです。

    

13. 形式構造ツリーで、次の項目を追加して、ユーザーが照会するベンダーの詳細を含む XML 形式の送信ドキュメントを生成します。

    1. Statement ルート XML 要素を追加します。

    2. Statement XML 要素の場合は、入れ子になった Party XML 要素を追加します。

    3. Party XML 要素の場合は、次の入れ子になった XML 属性を追加します:

       • 氏名
       • AccountNum

14. 次の方法で、形式要素を指定されたデータ ソースにバインドします:

    • Statement\Party 形式要素を model.Vendor データ ソース項目にバインドします。
    • Statement\Party\Name 形式要素を model.Vendor.Name データ ソース フィールドにバインドします。
    • Statement\Party\AccountNum 形式要素を model.Vendor.AccountNumber データ ソース フィールドにバインドします。

15. 検証 を選択して、形式デザイナー ページで編集可能な形式コンポーネントを検査します。

    

16. 検証警告が発生することに注意してください。 このメッセージは、 model.Vendor.Name データ ソース フィールドが、形式で使用するように構成したモデル マッピングのどのデータ ソースにもバインドされていないことを示します。 したがって、Statement\Party\Name 形式要素が実行時に入力されず、ランタイム例外が発生する可能性があります。

    

次の図は、警告を無視し 実行 を選択して、形式を実行した場合に、発生するランタイム エラーを示しています。

自動解決

この問題を自動的に修正するオプションはありません。

手動解決

オプション 1

model.Vendor.Name データ ソース フィールドにバインドを追加して、構成済みモデル マッピングを変更します。

オプション 2

Statement\Party\Name 形式要素のバインドを削除することで、構成済みの形式を変更します。

リンクされていないテンプレート

テンプレートを使用して送信ドキュメントを生成するように ER 形式コンポーネントを 手動で 構成する場合は、Excel\File 要素を手動で追加し、必要なテンプレートを編集可能なコンポーネントの添付ファイルとして追加して、追加された Excel\File 要素で、その添付ファイルを選択する必要があります。 このプロセスを使用すると、追加された要素が実行時に選択したテンプレートに入力されることを示します。 フォーマット コンポーネントのバージョンを 下書き 状態で構成する場合は、編集可能なコンポーネントにいくつかのテンプレートを追加し、 Excel\File 要素の各テンプレートを選択して ER 形式を実行できます。 このプロセスを使用すると、実行時にさまざまなテンプレートがどのように入力されるかを確認できます。 Excel\File 要素で選択されていないテンプレートがある場合、ER フォーマット デザイナーは、状態が下書きから完了に変わると、それらのテンプレートが編集可能な ER 形式コンポーネント バージョンから削除されることを警告します。

次の手順は、この問題がどのように発生するかを示しています。

1. ER 形式コンポーネントの構成を開始します。

2. 形式構造ツリーで、Excel\File 要素を追加します。

3. 追加した Excel\File 要素の場合、Excel ブック ファイル A.xlsx を添付ファイルとして追加します。 ER パラメーター で構成されているドキュメント タイプを使用して、ER 形式テンプレートのストレージを指定します。

4. Excel\File 要素の場合、別の Excel ブック ファイル B.xlsx を添付ファイルとして追加します。 ブック ファイル A に使用したのと同じドキュメントの種類を使用します。

5. Excel\File 要素で 、ブック ファイル A を選択します。

6. 検証 を選択して、形式デザイナー ページで編集可能な形式コンポーネントを検査します。

   

7. 検証警告が発生することに注意してください。 このメッセージは、ブック ファイル B.xlsx がコンポーネントにリンクされていないこと、および構成バージョンの状態が変更された後に削除されることを示します。

自動解決

この問題を自動的に修正するオプションはありません。

手動解決

Excel\File 要素にリンクされていないテンプレートをすべて削除して、構成済みの形式を変更します。

未同期形式

Excel テンプレートを使用して送信ドキュメントを生成するように、ER 形式コンポーネントを 構成 する場合は、Excel\File 要素を手動で追加し、必要なテンプレートを編集可能なコンポーネントの添付ファイルとして追加して、追加された Excel\File 要素で、その添付ファイルを選択できます。 この方法では、追加された要素が実行時に選択したテンプレートに入力されることを示します。 追加した Excel テンプレートを外部で設計したため、編集可能な ER 形式には、追加されたテンプレートに含まれていない Excel 名が含まれている可能性があります。 ER 形式デザイナーでは、ER 書式要素のプロパティと、追加された Excel テンプレートに含まれていない名前の間に不整合が発生した場合に警告が表示されます。

次の手順は、この問題がどのように発生するかを示しています。

1. ER 形式コンポーネントの構成を開始します。

2. 形式構造ツリーで、Excel\File 要素 Report を追加します。

3. 追加した Excel\File 要素の場合、Excel ブック ファイル A.xlsx を添付ファイルとして追加します。 ER パラメーター で構成されているドキュメント タイプを使用して、ER 形式テンプレートのストレージを指定します。

   重要

   追加した Excel ブックに名前 ReportTitle が含まれていないことを確認してください。

4. Excel\Cell 要素 Title を Report 要素の入れ子になった要素として追加します。 Excel の範囲 フィールドに、ReportTitle を入力します。

5. 検証 を選択して、形式デザイナー ページで編集可能な形式コンポーネントを検査します。

   

6. 検証警告が発生することに注意してください。 メッセージは、名前 ReportTitle が、使用している Excel テンプレートのシート Sheet1 に存在しないことを示しています。

   

自動解決

この問題を自動的に修正するオプションはありません。

手動解決

オプション 1

テンプレートから欠落している Excel 名を参照する要素をすべて削除して、構成済の形式を変更します。

オプション 2

Excel テンプレートをインポートすることで、編集可能な ER 形式を 更新 します。 編集可能な ER 形式の構造は、インポートされた Excel テンプレートの構造と 同期されます 。

その他の考慮事項

ビジネス ドキュメント管理 のテンプレート エディターで ER テンプレートと形式構造を同期する方法については、ビジネス ドキュメント テンプレートの構造の更新 を参照してください。

未同期テンプレート形式

Word テンプレートを使用して送信ドキュメントを生成するように、ER 形式コンポーネントを構成 する場合は、Excel\File 要素を手動で追加し、必要な Word テンプレートを編集可能なコンポーネントの添付ファイルとして追加して、追加された Excel\File 要素で、その添付ファイルを選択できます。

この方法では、追加された要素が実行時に選択したテンプレートに入力されることを示します。 追加した Word テンプレートを外部でデザインするため、編集可能な ER 形式には、追加されたテンプレートに含まれていない Word コンテンツ コントロールへの参照が含まれている場合があります。 ER 形式デザイナーでは、ER 書式要素のプロパティと、追加された Word テンプレートに含まれていないコンテンツ コントロールの間に不整合が発生した場合に警告が表示されます。

この問題がどのように発生するかを示す例については、編集可能な形式を構成して概要セクションを非表示にする を参照してください。

自動解決

この問題を自動的に修正するオプションはありません。

手動解決

オプション 1

検証の警告で言及されている書式要素から 削除された 数式を削除して、構成された形式を変更します。

オプション 2

必要なタグを関連する Word コンテンツ コントロールに 追加 して、Word テンプレートを変更します。

既定のマッピングなし

Missing バインディング検査を実行すると、その検査された形式の結合が、関連するモデル マッピング コンポーネントの結合と照らし合わせて評価されます。 複数の ER モデル マッピング構成を Finance インスタンスにインポートでき、各構成に該当するモデル マッピング コンポーネントが含まれている場合があります。 既定の構成として 1 つの構成を選択する必要があります。 それ以外の場合、検査対象の ER 形式を実行、編集、または検証しようとすると、例外が発生します。 次のメッセージが表示されます："<モデル名 (ルート記述子)> データモデルには、<コンマで区切られた複数の構成名に対応する複数のモデルマッピングが存在します>。" 構成の 1 つを既定として設定してください。"

この問題がどのように発生したか示す例、および修正方法については、単一のモデル ルートへの複数の派生マッピングの管理 を参照してください。

ヘッダーまたはフッターのコンポーネントの設定不整合

Excel テンプレートを使用して送信ドキュメントを生成するために ER 形式コンポーネントを構成する 場合、Excel ブックのワークシートの上部にヘッダーを入力するために Excel\ヘッダーのコンポーネントを追加できます。 ワークシートの下部にフッターに入力するために Excel\フッターのコンポーネントを追加することもできます。 追加するすべての Excel\Header または Excel\Footer コンポーネントについて、コンポーネントが実行されるページを指定するには、 ヘッダー/フッターの外観 プロパティを設定する必要があります。 1 つのシート コンポーネントに対して複数の Excel\ヘッダーまたは Excel\フッターのコンポーネントを構成でき、および Excel ワークシートの異なるタイプのページで異なるヘッダーまたはフッターを生成できるので、ヘッダー/フッターの外観プロパティの特定の値に対して、1 つの Excel\ヘッダーまたは Excel\フッターのコンポーネントを構成する必要があります。 ヘッダー/フッターの外観プロパティの特定の値に対して複数の Excel\Header または Excel\Footer コンポーネントを構成すると、検証エラーが発生し、"ヘッダー/フッター (<コンポーネントの種類: ヘッダーまたはフッター>) に一貫性がありません" というエラー メッセージが表示されます。

自動解決

この問題を自動的に修正するオプションはありません。

手動解決

オプション 1

不整合な Excel\ヘッダーまたは Excel\フッター コンポーネントのいずれかを削除して、構成済み形式を変更します。

オプション 2

不整合な Excel\ヘッダーまたは Excel\フッター コンポーネントのいずれかに対してヘッダー/フッター外観 プロパティの値を変更します。

ページ コンポーネントの設定における不整合

Excel テンプレートを使用して送信ドキュメントを生成するように ER フォーマット コンポーネントを構成した場合、生成されたドキュメントに ER の数式を使用してページ付けするための Excel\ページ コンポーネントを追加できます。 Excel\コンポーネントを追加するたびに、入れ子になった範囲コンポーネントを多数追加しても、以下の構造に準拠することができます:

• 入れ子になった最初の Range コンポーネントでは、 レプリケーション方向 プロパティを [レプリケーションなし] に設定できます。 生成されたドキュメントでページ ヘッダーを作成するには、この範囲を使用します。
• レプリケーション方向のプロパティが縦に設定されている場合、他の多くのネストされた範囲コンポーネントを追加することができます。 生成されたドキュメントを入力するには、これらの範囲を使用します。
• 最後に入れ子になった Range コンポーネントでは、 レプリケーション方向 プロパティを [レプリケーションなし] に設定できます。 この範囲を使用して、生成されたドキュメントにページ フッターを作成し、必要な改ページを追加します。

設計時に ER フォーマット デザイナーで ER フォーマットのこの構造に従わない場合は、次のようなエラー メッセージで検証エラーが発生します: 「複数のレプリケーションのない範囲コンポーネントがあります。 不要なコンポーネントを削除します。

自動解決

この問題を自動的に修正するオプションはありません。

手動解決

オプション 1

一貫性のない Excel\範囲 コンポーネントのレプリケーション方向プロパティを変更して、設定されたフォーマットを変更します。

ORDERBY 関数による式の実行可能性

組み込みの ORDERBY ER 関数を使用して、 レコード リスト 型の ER データ ソースのレコードを並べ替えます。 データ ソースを関数の引数として指定します。

ORDERBY関数の引数を指定して、アプリケーション テーブル、ビュー、またはデータ エンティティのレコードを並べ替えます。 この関数を使用すると、1 つのデータベース呼び出しを行って、並べ替えられたデータをレコードの一覧として取得します。 呼び出しのアプリケーション ソースを指定する関数の引数として 、レコード リスト 型のデータ ソースを使用します。

ER は、 ORDERBY 関数で参照するデータ ソースへの直接データベース クエリを確立できるかどうかを確認します。 ER が直接クエリを確立できない場合、ER モデル マッピング デザイナーで検証エラーが発生します。 受信するメッセージは、ORDERBY 関数を含む ER 式を実行時に実行できないことを示しています。

次の手順は、この問題がどのように発生するかを示しています。

1. ER モデル マッピング コンポーネントの構成を開始します。

2. Dynamics 365 for Operations \ テーブル レコード タイプのデータ ソースを追加します。

3. 新しいデータ ソースに Vendor と名前を付けます。 [ テーブル ] フィールドで、 VendTable を選択して、このデータ ソースが VendTable テーブルを要求するように指定します。

4. 計算済フィールド タイプのデータ ソースを追加します。

5. 新しいデータ ソースに OrderedVendors と名前を付けて、式 ORDERBY("Query", Vendor, Vendor.AccountNum) を含むように構成します。

   

6. 検証 を選択して、モデル マッピング デザイナー ページで編集可能なモデル マッピング コンポーネントを検査し、OrderedVendors データ ソースの式を照会できることを確認します。

7. 計算済フィールド タイプの入れ子になったフィールドを追加して、Vendor データ ソースを変更し、トリムされた仕入先番号を取得します。

8. 新しい入れ子になったフィールドに $AccNumber と名前を付けて、式 TRIM(Vendor.AccountNum) を含むように構成します。

9. 検証 を選択して、モデル マッピング デザイナー ページで編集可能なモデル マッピング コンポーネントを検査し、Vendor データ ソースの式を照会できることを確認します。

   

10. ベンダー データ ソースに集計フィールド型の入れ子になったフィールドが含まれているため、検証エラーが発生していることに注意してください。 この入れ子になったフィールドでは、 OrderedVendors データ ソースの式を直接データベース ステートメントに変換することはできません。 検証エラーを無視し、 実行 を選択してこのモデル マッピングを実行した場合も、実行時に同じエラーが発生します。

自動解決

この問題を自動的に修正するオプションはありません。

手動解決

オプション 1

計算フィールド タイプの入れ子になったフィールドを Vendor データ ソースに追加する代わりに、$AccNumber の入れ子になったフィールドを FilteredVendors データ ソースに追加し、式 TRIM(FilteredVendor.AccountNum) を含むようにフィールドを構成します。 この方法を使用すると、データベース レベルで ORDERBY("Query", Vendor, Vendor.AccountNum) 式を実行でき、後で入れ子になった フィールド$AccNumber 計算できます。

オプション 2

FilteredVendors データ ソースの式を ORDERBY("Query", Vendor, Vendor.AccountNum) から ORDERBY("InMemory", Vendor, Vendor.AccountNum) に変更します。 大量のデータを含むテーブル (トランザクション テーブル) の式は変更しないでください。この変更では、すべてのレコードがフェッチされ、メモリ内の必要なレコードが並べ替えられます。 したがって、この方法ではパフォーマンスが低下する可能性があります。

廃止されたアプリケーション コンポーネント

ER モデル マッピング コンポーネントまたは ER 形式コンポーネントを設計する場合は、データベース テーブル、クラスのメソッドなど、ER でアプリケーション成果物を呼び出すように ER 式を構成できます。 Finance バージョン 10.0.30 以降では、参照されるアプリケーション成果物がソース コードで古い形式としてマークされたときに警告するように ER を構成できます。 この警告は、通常、古い成果物が最終的にソース コードから削除されるため便利です。 成果物の状態に関する通知を受け取ると、ソース コードから削除される前に、編集可能な ER コンポーネントで古い成果物を使用できなくなる可能性があります。 このアクションは、実行時に ER コンポーネントから既存以外のアプリケーション成果物を呼び出す際のエラーを防ぐのに役立ちます。

編集可能な ER コンポーネントの検査中に、アプリケーション成果物の古い属性の評価を開始するには、[機能管理] ワークスペースの [電子レポート データ ソースの古い要素を検証する] 機能を有効にします。 廃止された属性は、現在、次のタイプのアプリケーション コンポーネントに対して評価されています:

• データベース テーブル
  • テーブルのフィールド
  • テーブルのメソッド
• アプリケーション クラス
  • クラスのメソッド

次の図は、DEL_Email アプリケーション テーブルの古い CompanyInfo フィールドが、構成済の company データ ソースを使用してデータ モデル フィールドにバインドされている場合に発生する、検証警告を示しています。

自動解決

この問題を自動的に修正するオプションはありません。

手動解決

廃止されたアプリケーション コンポーネントを参照するデータ ソースへのすべてのバインドを削除して、構成済みのモデル マッピングまたは形式を変更します。

追加リソース

ALLITEMS ER 関数

ALLITEMSQUERY ER 関数

INT64VALUE ER 関数

INTVALUE ER 関数

FILTER ER 関数

WHERE ER 関数

JOIN データ ソースを使用して、ER モデル マッピングで複数のアプリケーション テーブルからデータを取得する

電子申告形式の実行をトレースしてパフォーマンスの問題をトラブルシューティング

ビジネス ドキュメント管理の概要

• 生成されたレポートの Word コンテンツ コントロールを非表示にする

• 単一のモデル ルートへの複数の派生マッピングの管理