
Explanation:
ボックス 1: 1.0.0.0
アプリ ソリューションのバージョンを特定するときは、個々のコンポーネントを以前のバージョンに戻すことによって発生する意図しない問題を回避するために、すべての依存関係、エンティティ、およびユーザー インターフェイス コンポーネントを特定する必要があります。
ソリューションのバージョンの形式は、メジャー.マイナー.ビルド.リビジョンです。更新プログラムには、親ソリューションよりも大きいメジャー、マイナー、ビルド、またはリビジョン番号が必要です。たとえば、ベース ソリューション バージョン 3.1.5.7 の場合、小規模な更新はバージョン 3.1.5.8 になるか、わずかに重要な更新はバージョン 3.1.7.0 になる可能性があります。バージョン 3.2.0.0 は、より重要なアップデートとなる可能性があります。
ボックス 2: 20.11.1.1
シナリオ:
* 次のバージョン管理番号スキームを使用する必要があります。
- Major: アプリがパッケージ化された年の下 2 桁
- マイナー: アプリがパッケージ化された月を表す 2 桁の数字
- ビルド: アプリへの重要な変更を表すために増分される数値
- リビジョン: パッケージのインクリメントされたリビジョン
アプリケーションの新しいバージョンは、以前のバージョンのアプリを完全に置き換える必要があります。
参照:
https://docs.microsoft.com/en-us/powerapps/maker/common-data-service/update-solutions
トピック 2、Contoso, Ltd
これは事例研究です。ケーススタディの時間は個別に設定されていません。各ケースを完了したいだけの試験時間を使用できます。ただし、この試験には追加のケース スタディやセクションがある場合があります。指定された時間内にこの試験に含まれるすべての問題を完了できるように、時間を管理する必要があります。
ケース スタディに含まれる質問に答えるには、ケース スタディで提供されている情報を参照する必要があります。ケース スタディには、ケース スタディで説明されているシナリオに関する詳細情報を提供する資料やその他のリソースが含まれている場合があります。このケース スタディでは、各質問は他の質問とは無関係です。
このケース スタディの最後に、レビュー画面が表示されます。この画面では、試験の次のセクションに進む前に、回答を確認して変更を加えることができます。新しいセクションを開始すると、このセクションに戻ることはできません。
ケーススタディを開始するには
このケース スタディの最初の質問を表示するには、[次へ] ボタンをクリックします。質問に答える前に、左ペインのボタンを使用してケース スタディの内容を調べます。これらのボタンをクリックすると、ビジネス要件、既存の環境、問題ステートメントなどの情報が表示されます。質問に答える準備ができたら、[質問] ボタンをクリックして質問に戻ります。
バックグラウンド
現在の環境 概要
会社の運営は非常に非公式に管理されています。すべての製造プロセスを知っているのは、少数の長期従業員だけです。
会計システムと購買
* 同社にはクラウドベースの ERP/会計システムがあり、総勘定元帳、売掛金、買掛金モジュールを使用しています。現在のシステムには、製造現場または製造計画機能を処理するモジュールがありません。
※従業員情報は経理システム内のみで管理しております。情報へのアクセスは、プライバシー規制および会社のポリシーにより厳しく管理されています。
* すべての原材料の購入は、エンジニアリング プリントが作成されるときにエンジニアリング部門によって生成される部品表 (BOM) に基づいて行われます。
* 本社は Dynamics 365 Finance を使用しています。運用マネージャーは、Dynamics 365 Finance が少なくとも 5 年間は製造工場に実装されないと報告しています。
製造・企画
* Contoso, Ltd. が買収したプラントでは、Microsoft Excel ワークブックと Microsoft Word ドキュメントを使用して、販売パイプライン、見積回答の要求、および作業見積もりを追跡しています。ドキュメントは共有ネットワーク ドライブに保存されます。
* 印刷された設計図が誤って注文をまたいで使用されることがあります。これにより、やり直し、コスト超過、納期の遅れが発生します。
* 会社はジョブ トラベラー ドキュメントを使用して、実行する必要がある操作と特定のジョブ番号に必要な材料を詳述します。
販売
* 見積依頼は現在、セールス ログ ワークブックに保存されています。ワークブックには次の情報が含まれています。
※お客様リクエスト番号
* 顧客名
* 説明
* 販売の推定値
* 落札、紛失、入札なし、キャンセルの値を含む見積依頼 (RFQ) のステータス
※営業部長、営業担当者、見積者の氏名
※商品名
* 見積もりが顧客に送信された日付
* プロジェクトのおおよその開始日と終了日
* 受注した場合は受注日
* 当選した場合に割り当てられるジョブ番号
* 会社には見積もりを管理するための正式なプロセスがあります。正式なプロセスが実施されていても、人件費や材料の見積もりなど、必要なサポート ドキュメントが不足している販売見積もあります。同社は、正式なプロセスをアプリの一部として組み込みたいと考えています。
* 営業担当者は、販売が終了し、顧客の注文書を受け取ったときに、販売ログの RFQ のステータスを [受注] に設定しないことがよくあります。
※現在、販売ログの成約確率欄は、成約時100%、不成立時0%に設定されているため、正確な販売パイプラインと勝敗情報をレポートすることができません。
* 顧客がネットワーク ドライブにフォルダ システムを設定しても、現在のバージョンの販売見積の製造部門への引き渡しは改善されませんでした。
要件
解決
Microsoft Teams と Power Platform を使用するソリューションを作成する予定です。
Sales Log ブックを Common Data Service データベースに変換する必要があります。
各部門には個別の Teams チャネルがあります。従業員は、自分の部門のチャネルにのみアクセスできる必要があります。すべての従業員と経営陣は、一般的な企業チャネルへの読み取りアクセス権を持ちます。Teams サイトには、次のチャネルが含まれている必要があります。
販売
* 販売ダッシュボードは、販売チャネルに存在する必要があり、地域ごとの販売ノルマのアクティブな見積もり、販売パイプライン、および年初来の販売 KPI に関する情報が含まれている必要があります。
* すべてのセールス関連のドキュメントは、このチャネルのファイルの場所にあるフォルダーに保存する必要があります。ドキュメントのバージョン管理が有効になります。ドキュメントの最新の 10 バージョンを保存する必要があります。
製造業
* 月ごとのキャパシティ ヒート マップと、翌月に成立する可能性が高い予想売上を表示するダッシュボード。
* Job Setup テーブルから、顧客、開始日、および製品別に、すべての進行中のジョブの並べ替え可能なリスト。
※印刷された紙の図面は使用できません。図面は、製造チャネルのファイルの場所にあるフォルダーに保存する必要があります。
全般的
次のアプリを作成する必要があります。
時間追跡
モバイル デバイスで各従業員の時間を追跡するには、キャンバス アプリを作成する必要があります。アプリには次のものが含まれている必要があります。
* サインイン画面
* 従業員の週の時間エントリを一覧表示する画面
*従業員の現在の時間エントリを編集する画面
アプリは次の要件を満たす必要があります。
* アプリは、既存のオンプレミスの Microsoft SQL Server インスタンスにデータを保存する必要があります。
* 従業員は、アプリから自分のタイム トラッキング レコードにのみアクセスできる必要があります。
* 従業員は、各顧客ジョブの製造に費やされたすべての時間を記録する必要があります。
* 従業員は、当日と前日のタイム レコードのみを変更できる必要があります。
* 従業員は自分のバッジをスキャンしてチェックインおよびチェックアウトできる必要があります。各バッジには、従業員の名前と現在の写真が含まれています。
※全社員バッジにQRコードの付与が必要です。コードには従業員番号を含める必要があります。
* Job Traveler ドキュメントは PDF ドキュメントとして印刷し、ジョブ番号とタスク番号の UPC E バーコードを含める必要があります。バーコードは時間追跡アプリケーションで使用されます。
販売
Sales アプリは次の要件を満たす必要があります。
* すべてのセールス パイプラインと見積情報に簡単にアクセスできる中央の場所を提供し、見積書、見積書、エンジニアリング ドキュメントのすべてのバージョンを維持します。
* 現在アクティブなすべての見積もり、販売サイクルでのステータス、成約の可能性、推定製造日および設置日を、顧客、製品部門、ステータス、および営業担当者別に表示するダッシュボードを含めます。
* セールス ログ アプリは、セールス ライフサイクル中に必要な見積もりの完了とサポート資料に関連するプロセス標準を実施する必要があります。
* セールが成立すると、すぐに次のアクションを自動的に実行します。
* 連続したジョブ番号を生成します。
* 主要な販売情報を、製造で使用される Job Setup エンティティにコピーします。
* 販売が失われた場合は、[ステータス] フィールドを [紛失] に設定し、損失の理由をテキスト フィールドに入力する必要があります。説明フィールドの最後に理由を追加する必要があります。
* 従業員が顧客サイトにいても、販売ログを簡単に更新できるようにします。
製造・企画
アプリは次の要件を満たす必要があります。
* パイプラインの現在および今後の注文のキャパシティ リソース要件を計画および予測する機能を提供します。
* 紙のタイムシートを交換し、チェックイン、チェックアウト、休憩、および各ジョブ タスクに費やされた時間を追跡します。
*作業の実行中および設計図面の表示に経過した時間を記録します。
* ジョブ セットアップ エンティティは、そのデータを既存のオンプレミス SQL Server インスタンスに格納する必要があります。
* Job Traveler ドキュメントは、PDF ドキュメントとして生成し、Job Setup エンティティから印刷する必要があります。
問題
※お客様のリクエスト番号が分かりにくいレポートを使用しています。番号をシステム生成の連続番号に変更するように要求されます。
* オペレーション マネージャーは、ユーザーがタイム トラッキング アプリに誤ってサインインすることが多いと報告しています。オペレーション マネージャーは、従業員がバッジをスキャンしたら、タイム トラッキング アプリに従業員の写真を表示するように依頼します。
* ユーザーは、すべての画面から入力された 1 週間の合計時間を確認できるようにしたいと考えています。
* テスターは、自分のタイム エントリだけでなく、タイム トラッカー アプリでもタイム エントリを確認できると報告しています。さらに、既存の時間エントリを編集することもできます。