Q1.ある製造業では Dynamics 365 for Finance and Operations を新規導入し、稼働前にユーザー受け入れテスト (UAT) を行う予定です。
担当者はテスト ケースの記録を作成しました。
複数の環境をまたいでテストを調整するため、UAT を Microsoft Azure DevOps と連携させる必要があります。
UAT を完了させるには、ビジネス プロセス モデラー (BPM) と Azure DevOps を適切に構成しなければなりません。
実行すべき 3 つのアクションはどれですか?
各選択肢はそれぞれ完全な解決策を示します。
解答を見る
UAT 用に作成したテスト ケースの記録は、まず BPM にアップロードして業務プロセス単位に整理します。
次に BPM ライブラリを Azure DevOps と同期すると、テスト ケースとテスト手順が Azure DevOps 側へ自動生成されます。
その後、Azure DevOps で テスト計画とテスト スイートを作成し、実行対象のテスト ケースをまとめます。
テスト ケースを手動作成したり Git と同期したりする必要はないため、A・C・D が正解です。
なお Dynamics 365 for Finance and Operations は現在、財務と運用アプリとして案内されています。
ユーザー受け入れテストの作成と自動化 – Finance & Operations | Dynamics 365
Q2.ある卸売企業では、新しく取り扱う製品の在庫を FIFO の原則で評価する方針を検討しています。
この企業は複数のサイトを持ち、各サイトの下に複数の倉庫を構えています。
倉庫ごとに対象品目の価値と数量を把握できるようにする必要があります。
さらに、倉庫単位で FIFO 原価計算を適用しなければなりません。
原価計算に関する設定はどのように行えばよいですか?
解答を見る
FIFO などの在庫評価方法は、製品の原価計算フィールドではなく 品目モデル グループで指定します。
倉庫ごとに価値と数量を確認し、倉庫単位で FIFO 原価計算を行うには、保管分析コード グループで 在庫を倉庫別に物理的にも財務的にも追跡する構成を選びます。
品目モデル グループが品目消費の計算方法を決め、保管分析コード グループが製品トランザクションで使う保管分析コードを決めるためです。
したがって上記の組み合わせが正解です。
なお Dynamics 365 for Finance and Operations は現在、財務と運用アプリとして案内されています。
リリース済み製品マスターの基本設定の完了 – Supply Chain Management | Dynamics 365
Q3.ある物流拠点では、倉庫で製品をピッキングして出荷しています。
倉庫への自動リリースによって、倉庫側で作業がただちに生成されるようにしたいと考えています。
作業の自動作成を実現するには、ウェーブを適切に構成する必要があります。
何を行うべきでしょうか?
解答を見る
倉庫へのリリース時にピッキング作業を自動生成するには、ウェーブ テンプレートで ウェーブ作成の自動化を有効にし、あわせて 倉庫へのリリース時にウェーブを処理するを有効にします。
ウェーブ作成の自動化は注文が倉庫にリリースされた時点でウェーブを自動作成し、リリース時の処理はウェーブを自動的に処理して作業を作成します。
定期バッチへの割り当てやテンプレートの選択だけでは、即時の自動作業作成には不十分です。
したがって C が正解です。
ウェーブ テンプレート – Supply Chain Management | Dynamics 365
Q4.あるワイン卸売業者は、1か月以内に受注したワインのボトルを対象にリベート プログラムを用意しています。
10〜100 本の購入で 1 本あたり 5 ドル、101〜200 本の購入で 6 ドルが割り引かれます。
ワインはボトル単位でもケース単位でも購入できます。
この割引は、取扱いのあるすべての銘柄のワインに適用されます。
月末に正しいリベート金額が計上されるよう、ベンダー リベート契約を作成する必要があります。
解決策: リベート契約の測定単位リベート オプションで「完全一致」を選択します。
この解決策は目標を満たしていますか?
解答を見る
ワインはボトルとケースの両方で購入でき、リベートの数量区分はボトル数を基準にしています。
測定単位リベート オプションで 完全一致を選ぶと、購買明細の測定単位がリベート行の単位と厳密に一致した場合のみリベートが計算されます。
そのため、ケースで購入した注文はボトル基準のリベートに合致せず、正しい金額を集計できません。
異なる測定単位をまたいで数量を合算するには、完全一致ではなく単位換算を許す設定が必要です。
したがって、この解決策は目標を満たさず いいえが正解です。
ベンダー リベート – Supply Chain Management | Dynamics 365
Q5.ある企業では、Dynamics 365 Supply Chain Management に購買依頼 (purchase requisition) の機能を導入しようとしています。
シナリオごとに適切な購買依頼ソリューションを構成する必要があります。
それぞれのシナリオでは、どのソリューションを使用すべきですか?
解答を見る
ベンダーの Web サイトで品目を選び、その内容を正しい価格で購買依頼明細へ取り込む要件には External catalogs（外部カタログ）を使用します。
外部カタログは PunchOut 調達でベンダー サイトの商品選択を購買依頼へ戻す機能です。
また、特定の従業員に依頼者の一覧を表示させるには、誰が誰の代理で購買依頼を作成できるかを制御する 購買依頼権限を構成します。
購買ポリシーや支出レビュー担当者、購買グループは、この依頼者表示の権限制御には直接対応しません。
したがって上記の組み合わせが正解です。
パンチアウト e-procurement の外部カタログの使用 – Supply Chain Management | Dynamics 365
Q6.ある国際空港では Dynamics 365 for Finance and Operations を運用しています。
このたび、新しい手荷物仕分けハードウェアを調達しました。
このハードウェアと、そのサービス契約の両方を製品階層に追加する必要があります。
そのためにカテゴリ ノードを構成しなければなりません。
どのように設定すればよいでしょうか?
解答を見る
カテゴリ階層では、物理的な在庫を持つ製品は有形として分類し、サービスなど在庫を持たないものは有形として分類しません。
手荷物仕分けハードウェアは新規の物理製品なので、新しいカテゴリ ノードを作成して有形として分類を選択します。
一方、サービス契約は物理的な在庫品ではないため、既存のサービス系カテゴリ ノードに追加し、有形として分類をクリアします。
したがって上記の組み合わせが正解です。
なお Dynamics 365 for Finance and Operations は現在、財務と運用アプリとして案内されています。
カテゴリ階層を使用した製品の分類 – Supply Chain Management | Dynamics 365
Q7.Vendor1 から小売店まで製品を配送するための輸送業者を構成する必要があります。
この構成をどのように完了させればよいですか?
解答を見る
Vendor1 から小売店へ配送する輸送業者を構成する場合、配送区間に基づいて運賃を計算する必要があるため、走行距離ベースの評価エンジンを使用する評価プロファイルを選びます。
また、ベンダーからの配送に対して輸送業者と運賃計算条件を関連付けるため、輸送業者の構成では ベンダー、輸送業者、評価プロファイルの組み合わせを使用します。
積荷や出荷単位ではなく、Vendor1 に対する輸送業者と評価プロファイルの関連付けを定義することが要件に合致します。
したがって上記の設定が正解です。
評価プロファイル – Supply Chain Management | Dynamics 365
Q8.ある会社が新しい倉庫施設を立ち上げます。
着荷の概要（到着概要）を使って、転送オーダーの品目を受け入れる必要があります。
どのような順序でアクションを実行すればよいですか?
左の「選択肢」から必要な数を右の「回答エリア」へドラッグ（またはタップ）。回答エリア内でドラッグして順序を入れ替えられます。
- 到着仕訳帳を転記します。
- 品目到着仕訳帳を更新します。
- 転送オーダーの受領を転記します。
- 到着を開始します。
- 到着概要フォームを開きます。
- ここへドラッグ
解答を見る
着荷の概要では、まず 到着概要フォームを開いて入庫予定の転送オーダー明細を確認します。
次に 到着を開始すると、対象明細から品目到着仕訳帳が作成されます。
続いて必要に応じて品目到着仕訳帳を更新し、到着仕訳帳を転記して登録状態にします。
最後に転送オーダーの受領を転記することで、倉庫への受入処理が完了します。
したがって、フォームを開く、到着を開始する、更新する、到着仕訳帳を転記する、転送オーダーの受領を転記する、の順序が正しいです。
着荷の概要 – Supply Chain Management | Dynamics 365
Q9.ある会社は、ベンダーへ部品を発注しています。
このベンダーは、しばしば発注量を上回る数量の部品を出荷してきます。
受領したユニット数が発注したユニット数を 10 パーセント以上上回った場合は、承認マネージャーへ通知する必要があります。
通知用のワークフローはすでに用意されています。
実際に通知が生成されることを確認しなければなりません。
システムをどのように構成すればよいですか?
解答を見る
発注量を超えて入庫するケースは、購買側の 過剰配送として扱います。
そのため、発注書フォームの購買注文明細行 FastTab で過剰配送の許容割合を構成します。
通知が生成されることを確認するには、対象の購買注文明細行で製品を登録し、製品受領書を転記して実際の受領数量を反映させます。
販売注文や転送オーダーの処理では、ベンダーからの過剰受領の検証にはなりません。
したがって、発注書の過剰配送設定と購買受領処理の組み合わせが正解です。
発注書に対する製品受領書 – Supply Chain Management | Dynamics 365
Q10.あなたは、ある流通会社の物流マネージャーを務めています。
ニューヨーク市とコロラド州の間の輸送料金は、主要な運送会社から提示されています。
料金は集荷元の都市または地域ごとに一律で、次のとおりです。
ニューヨーク市 = 500 ドル。
コロラド州 = 450 ドル。
ニューヨーク市からコロラドまでの料金を算出するため、輸送管理を設定する必要があります。
何を行うべきでしょうか?
解答を見る
この要件は距離や所要時間ではなく、出発地と到着地の組み合わせに対して一律の料金を割り当てるものです。
そのため、ポイントツーポイント エンジンを使って開始場所と終了場所に基づく料金を設定します。
重量や数量による段階別の条件は不要なので、空のブレーク マスターを用いる構成が適切です。
走行距離エンジンや輸送時間エンジンは距離・時間に応じて料金を計算する場合に使うため、このケースには合いません。
したがって B が正解です。
輸送管理エンジン – Supply Chain Management | Dynamics 365