Microsoft MB-330 (Dynamics 365 Supply Chain Management Functional Consultant Associate)1-10

UAT 用のテスト ケース記録は、まずBPM にアップロードして業務プロセス別に整理します。
Microsoft Learn では、BPM ライブラリを Azure DevOps と同期すると、テスト ケースとテスト手順を Azure DevOps に自動作成できると説明されています。
その後、Azure DevOps 側でテスト計画とテスト スイートを作成し、実行対象のテスト ケースを整理します。
テスト ケースを手動作成したり、Git と同期したりする必要はありません。
なお、Dynamics 365 for Finance and Operations は現在、財務と運用アプリとして説明されます。
ユーザー受け入れテストの作成と自動化 – Finance & Operations | Dynamics 365

FIFO などの在庫評価方法は、製品の原価計算フィールドではなく品目モデル グループで指定します。
倉庫ごとに価値と数量を確認し、倉庫単位で FIFO 原価計算を行うには、保管分析コード グループでサイトおよび倉庫を物理的・財務的に追跡する必要があります。
Microsoft Learn でも、品目モデル グループは品目消費の計算方法を決定し、保管分析コード グループは製品トランザクションで使用される保管分析コードを決定すると説明されています。
なお、Dynamics 365 for Finance and Operations は現在、財務と運用アプリとして説明されます。
リリース済み製品マスターの基本設定の完了 – Supply Chain Management | Dynamics 365

倉庫へのリリース時にピッキング作業を自動作成するには、ウェーブ テンプレートでウェーブ作成の自動化を有効にし、さらに倉庫へのリリース時にウェーブを処理するを有効にします。
Microsoft Learn では、ウェーブ作成の自動化は注文が倉庫にリリースされたときにウェーブを自動作成し、リリース時の処理はウェーブを自動処理して作業を作成すると説明されています。
定期バッチやテンプレート選択だけでは即時の自動作業作成には不十分です。
したがってC が正解です。
ウェーブ テンプレート – Supply Chain Management | Dynamics 365

期間テンプレートは、供給スケジュールなどで需要と供給を期間ごとに分割表示するために使用されます。
今回の設定では方向が後向きのため、現在日から過去方向に期間が計算されます。
また、月の行は期間数が3で、明細行の作成が無効になっているため、3か月分を月ごとに分けず、計算日より前の1つのバックログ行として表示します。
したがって、見通し期間の開始日は2020年7月31日になり、月と営業日は1つのバックログ行にまとめられます。
供給スケジュール – Supply Chain Management | Dynamics 365

ベンダーのWebサイトから品目を選択し、その選択内容を正しい価格で購買依頼明細に反映する要件には、外部カタログを使用します。
外部カタログはPunchOut調達でベンダーサイトの商品選択を購買依頼へ戻すための機能です。
また、特定の従業員に依頼者一覧を表示させるには、誰が誰の代理で購買依頼を作成できるかを制御する購買依頼権限を構成します。
購買ポリシーや支出レビュー担当者、購買グループはこの依頼者表示の権限制御には直接対応しません。
したがって、1つ目はExternal catalogs、2つ目はpurchase requisition permissions が正解です。
パンチアウト e-procurement の外部カタログの使用 – Supply Chain Management | Dynamics 365

Dynamics 365 for Finance and Operations は旧称で、現在は用途に応じて Dynamics 365 Finance や Dynamics 365 Supply Chain Management などとして提供されています。
カテゴリ階層では、物理的な製品は有形として分類し、サービスなど物理在庫を持たないものは有形として分類しません。
手荷物仕分けハードウェアは新しい物理製品なので、新しいカテゴリ ノードを作成して有形として分類を選択します。
一方、サービス契約は物理的な在庫品ではないため、既存のサービス系カテゴリ ノードに追加し、有形として分類をクリアします。
したがって、上記の組み合わせが正解です。
カテゴリ階層を使用した製品の分類 – Supply Chain Management | Dynamics 365

Dynamics 365 for Finance and Operations は旧称で、現在は主に Dynamics 365 Finance や Dynamics 365 Supply Chain Management として機能別に提供されています。
輸送管理で Vendor1 から小売店へ配送する輸送業者を構成する場合、配送区間に基づく運賃計算が必要になるため、走行距離ベースの評価エンジンを使用する評価プロファイルを選択します。
また、ベンダーからの配送に対して輸送業者と運賃計算条件を関連付ける必要があるため、輸送業者の構成はベンダー、輸送業者、評価プロファイルを使用します。
積荷や出荷単位ではなく、Vendor1 に対する輸送業者と評価プロファイルの関連付けを定義することが要件に合致します。
評価プロファイル – Supply Chain Management | Dynamics 365

着荷の概要では、まず到着概要フォームを開くことで入庫予定の転送オーダー明細を確認します。
次に到着を開始すると、対象明細から品目到着仕訳帳が作成されます。
その後、必要に応じて仕訳帳明細を更新し、到着仕訳帳を転記して登録状態にします。
最後に転送オーダーの受領を転記することで、倉庫への受入処理が完了します。
したがって、開始、更新、到着仕訳帳転記、転送オーダー受領転記の順序が正しいです。
着荷の概要 – Supply Chain Management | Dynamics 365

発注量より多く入庫するケースは購買側の過剰配送として扱います。
そのため、購買注文明細行の Delivery 設定で過剰配送の許容割合を構成します。
通知を確認するには、対象の購買注文明細行で製品を登録し、製品受領書を転記して実際の受領数量を反映させます。
販売注文や転送オーダーの処理では、ベンダーからの過剰受領通知の検証にはなりません。
したがって、発注書の過剰配送設定と購買受領処理を選択します。
発注書に対する製品受領書 – Supply Chain Management | Dynamics 365

この要件は距離や所要時間ではなく、出発地と到着地の組み合わせに対して一律料金を割り当てるものです。
したがって、ポイントツーポイント エンジンを使用して開始場所と終了場所に基づく料金を設定します。
重量や数量などの段階別条件は不要なため、空のブレーク マスターを使う構成が適切です。
走行距離エンジンや輸送時間エンジンは、距離・時間に応じて料金を計算する場合に使うため、このケースには合いません。
したがってB が正解です。
輸送管理エンジン – Supply Chain Management | Dynamics 365