MB-820 試験問題 6
アプリで新しく開発された機能をテストするために、単体テスト関数を記述する予定です。
関数を記述するには、テスト コードユニットを作成する必要があります。
テスト コードユニットに使用するプロパティを選択する必要があります。
要件が満たされていることを確認するには、どのプロパティを使用する必要がありますか?
関数を記述するには、テスト コードユニットを作成する必要があります。
テスト コードユニットに使用するプロパティを選択する必要があります。
要件が満たされていることを確認するには、どのプロパティを使用する必要がありますか?
MB-820 試験問題 7
PageType プロパティを RoleCenter に設定してページを作成します。
ページのさまざまなセクションを移動します。
ページに機能を追加する必要があります。
何をすべきでしょうか?
ページのさまざまなセクションを移動します。
ページに機能を追加する必要があります。
何をすべきでしょうか?
MB-820 試験問題 8
ケーススタディ 1 - Contoso 社
背景
Contoso 社は製造業の販売会社です。複数の国/地域に子会社があり、それぞれが独自のローカライズを行っています。子会社は互いにデータ独立している必要があります。Contoso 社は、外部のビジネス パートナーを利用して、一部の製造品目の下請けを管理しています。Contoso 社にはさまざまな部門があり、部門間でデータ セキュリティが必要です。
現在の環境
Contoso 社では、財務、販売、購買、倉庫、製造プロセスの主要な ERP として Business Central online を使用しています。同社には、Business Central Web アプリケーションと外部アプリケーションを使用する従業員がいます。同社では、カスタムの外部モバイル アプリを開発中です。
IT 部門とそのパートナーは、機能がネイティブで利用できない会社の要件を満たすためにカスタム拡張機能をインストールしました。
Contoso, Ltd. は、顧客やパートナーが提供する外部サービスとやり取りします。さまざまなアプリケーションが、Business Central から公開される SOAP および OData エンドポイントとやり取りします。
Contoso 社の外部ビジネス パートナーは、新しい下請け注文の詳細を受信し、受信した各下請け注文の予定リリース日を送信するための REST API を公開しました。
Contoso, Ltd. はテナントの監視を有効化しておらず、アプリの内部テレメトリがありません。
さまざまな部門の要件を満たすためにカスタム レポートを作成する必要があります。
テナント管理
Contoso, Ltd. には、次のテナント管理の考慮事項があります。
IT部門
IT 部門には、パフォーマンスの問題を防ぎ、起こりうる異常を検出するためにテナントを監視する機能が必要です。
IT 部門は、Azure Application Insights と Log Analytics を使用して、取り込まれたテレメトリ信号を検査する予定です。
すべてのテナントのアップグレードは、Microsoft によって自動的に処理されます。IT 部門は、更新プログラムの可用性やテナント関連の通知をチェックしません。
IT 部門は、Business Central 管理センターからのテナント関連通知の受信を構成していません。
外部ビジネスパートナー
外部ビジネス パートナーは、ビジネス プロセスを監視するために、Contoso, Ltd. 用に作成されたアプリケーションにカスタム テレメトリを追加する必要があります。
アプリケーションのカスタム テレメトリ信号は、パートナーのテレメトリでのみ表示される必要があります。
石鹸
Contoso 社は、統合に SOAP プロトコルを使用しないことを計画しています。
Contoso 社は、外部アプリケーションが Business Central SOAP エンドポイントを使用しているかどうかを検出できる必要があります。
問題
Business Central テナントは、夜間に Microsoft によって新しいメジャー バージョンにアップグレードされます。
ユーザーから、Contoso, Ltd. の拡張機能の 1 つがテナントから消えたという報告がありました。IT 部門は、拡張機能がまだ公開されていることを確認しました。
カスタムモバイルアプリケーションの要件
Contoso 社は、次の要件を満たすカスタム モバイル アプリケーションを作成する予定です。
従業員は、ERP からアイテムの詳細をリアルタイムで確認し、製造プロセス中に発生した問題を報告するために、このアプリを使用する必要があります。
アーカイブされた問題を処理するには、AL 拡張機能を作成する必要があります。
モジュールを実装するときは、Business Central 開発ガイドラインに従う必要があります。
問題情報の報告と追跡を行うためのモジュールを実装する必要があります。このモジュールを Issue Management と呼ぶことにします。モジュールは PostIssue というメソッドを公開する必要があります。
時間の経過とともにコードの変更が必要になります。
問題管理プロセスは、次の 2 つの拡張機能に分割する必要があります。
問題ベース: メイン拡張
ISSUE EXT: ISSUE BASE からの依存関係を持つ 2 番目の拡張
ISSUE BASE 拡張機能のバージョン 1.0.0.0 では、IssueTotal という名前のグローバル Decimal 変数を含む Issue テーブルを作成する予定です。
ISSUE BASE 拡張機能のバージョン 1.0.0.0 では、次のように定義された説明フィールドを持つ Issue Category という名前のテーブルを定義する予定です。
ISSUE BASE 拡張機能で定義された Issue テーブルには、次のように定義された Clone プロシージャが含まれています。
ISSUE EXT 拡張では、Issue テーブルの tableextension オブジェクトを作成します。
Issue テーブルの tableextension オブジェクトは、IssueTotal: Decimal 変数にアクセスする必要があります。
数週間使用した後、説明フィールドとクローン手順は不要になったため削除する必要があることがわかりました。
ISSUE BASE 拡張機能の新しいバージョンでは、新しい Issue Type テーブルを作成します。以前の古い Issue Category テーブルから新しい Issue Type テーブルにデータを 1 行ずつ移動する必要があります。大量のデータを移動する必要があるため、DataTransfer オブジェクトを使用して Upgrade コードユニットを記述する必要があります。
IT 部門は、カスタムの問題テーブルを公開するためのカスタム API を作成します。API は、問題を新しいテーブルにコピーするためのアクションを提供します。アクションは次のように定義されます。
Contoso, Ltd. は、アイテムの詳細をモバイル アプリケーションに公開するために、Business Central で API を作成する必要があります。
API は、業務時間中に使用される場合、本番環境への影響を最小限に抑える必要があります。
API は Get 操作のみをサポートする必要があります。
問題のデバッグ
Business Central の ISSUE BASE 拡張機能のユーザーが問題を報告します。
この問題をデバッグするために、次の構成のスナップショット デバッグが有効化されました。
デバッグがトリガーされていないことがわかります。
下請け業務におけるビジネスパートナーとの統合
Contoso, Ltd. は、ビジネス パートナーが提供する外部 API に Business Central を接続する必要があります。これは、パートナーが販売需要を満たすために新しい下請け注文の詳細を送信したり、送信された各注文の予定リリース日を受信したりするために使用されます。統合の要件は次のとおりです。
ビジネス パートナーは、基本認証で保護された REST API を提供します。API にアクセスするための資格情報は Contoso, Ltd. と共有されます。
下請け注文を送信するための API は、指定されたエンドポイントに認証された POST リクエストを送信することによって呼び出す必要があります。
各下請け注文の注文番号と予定リリース日を取得するための API は、次の JSON で応答します。
各注文番号を取得する必要があります。
過去 7 日間にテナント内で不要な Web サービス呼び出しがあったかどうかを確認する必要があります。
どの 2 つの KQL クエリを使用する必要がありますか? それぞれの正解は完全なソリューションを示します。
注意: 正しい選択ごとに 1 ポイントが付与されます。
背景
Contoso 社は製造業の販売会社です。複数の国/地域に子会社があり、それぞれが独自のローカライズを行っています。子会社は互いにデータ独立している必要があります。Contoso 社は、外部のビジネス パートナーを利用して、一部の製造品目の下請けを管理しています。Contoso 社にはさまざまな部門があり、部門間でデータ セキュリティが必要です。
現在の環境
Contoso 社では、財務、販売、購買、倉庫、製造プロセスの主要な ERP として Business Central online を使用しています。同社には、Business Central Web アプリケーションと外部アプリケーションを使用する従業員がいます。同社では、カスタムの外部モバイル アプリを開発中です。
IT 部門とそのパートナーは、機能がネイティブで利用できない会社の要件を満たすためにカスタム拡張機能をインストールしました。
Contoso, Ltd. は、顧客やパートナーが提供する外部サービスとやり取りします。さまざまなアプリケーションが、Business Central から公開される SOAP および OData エンドポイントとやり取りします。
Contoso 社の外部ビジネス パートナーは、新しい下請け注文の詳細を受信し、受信した各下請け注文の予定リリース日を送信するための REST API を公開しました。
Contoso, Ltd. はテナントの監視を有効化しておらず、アプリの内部テレメトリがありません。
さまざまな部門の要件を満たすためにカスタム レポートを作成する必要があります。
テナント管理
Contoso, Ltd. には、次のテナント管理の考慮事項があります。
IT部門
IT 部門には、パフォーマンスの問題を防ぎ、起こりうる異常を検出するためにテナントを監視する機能が必要です。
IT 部門は、Azure Application Insights と Log Analytics を使用して、取り込まれたテレメトリ信号を検査する予定です。
すべてのテナントのアップグレードは、Microsoft によって自動的に処理されます。IT 部門は、更新プログラムの可用性やテナント関連の通知をチェックしません。
IT 部門は、Business Central 管理センターからのテナント関連通知の受信を構成していません。
外部ビジネスパートナー
外部ビジネス パートナーは、ビジネス プロセスを監視するために、Contoso, Ltd. 用に作成されたアプリケーションにカスタム テレメトリを追加する必要があります。
アプリケーションのカスタム テレメトリ信号は、パートナーのテレメトリでのみ表示される必要があります。
石鹸
Contoso 社は、統合に SOAP プロトコルを使用しないことを計画しています。
Contoso 社は、外部アプリケーションが Business Central SOAP エンドポイントを使用しているかどうかを検出できる必要があります。
問題
Business Central テナントは、夜間に Microsoft によって新しいメジャー バージョンにアップグレードされます。
ユーザーから、Contoso, Ltd. の拡張機能の 1 つがテナントから消えたという報告がありました。IT 部門は、拡張機能がまだ公開されていることを確認しました。
カスタムモバイルアプリケーションの要件
Contoso 社は、次の要件を満たすカスタム モバイル アプリケーションを作成する予定です。
従業員は、ERP からアイテムの詳細をリアルタイムで確認し、製造プロセス中に発生した問題を報告するために、このアプリを使用する必要があります。
アーカイブされた問題を処理するには、AL 拡張機能を作成する必要があります。
モジュールを実装するときは、Business Central 開発ガイドラインに従う必要があります。
問題情報の報告と追跡を行うためのモジュールを実装する必要があります。このモジュールを Issue Management と呼ぶことにします。モジュールは PostIssue というメソッドを公開する必要があります。
時間の経過とともにコードの変更が必要になります。
問題管理プロセスは、次の 2 つの拡張機能に分割する必要があります。
問題ベース: メイン拡張
ISSUE EXT: ISSUE BASE からの依存関係を持つ 2 番目の拡張
ISSUE BASE 拡張機能のバージョン 1.0.0.0 では、IssueTotal という名前のグローバル Decimal 変数を含む Issue テーブルを作成する予定です。
ISSUE BASE 拡張機能のバージョン 1.0.0.0 では、次のように定義された説明フィールドを持つ Issue Category という名前のテーブルを定義する予定です。
ISSUE BASE 拡張機能で定義された Issue テーブルには、次のように定義された Clone プロシージャが含まれています。
ISSUE EXT 拡張では、Issue テーブルの tableextension オブジェクトを作成します。
Issue テーブルの tableextension オブジェクトは、IssueTotal: Decimal 変数にアクセスする必要があります。
数週間使用した後、説明フィールドとクローン手順は不要になったため削除する必要があることがわかりました。
ISSUE BASE 拡張機能の新しいバージョンでは、新しい Issue Type テーブルを作成します。以前の古い Issue Category テーブルから新しい Issue Type テーブルにデータを 1 行ずつ移動する必要があります。大量のデータを移動する必要があるため、DataTransfer オブジェクトを使用して Upgrade コードユニットを記述する必要があります。
IT 部門は、カスタムの問題テーブルを公開するためのカスタム API を作成します。API は、問題を新しいテーブルにコピーするためのアクションを提供します。アクションは次のように定義されます。
Contoso, Ltd. は、アイテムの詳細をモバイル アプリケーションに公開するために、Business Central で API を作成する必要があります。
API は、業務時間中に使用される場合、本番環境への影響を最小限に抑える必要があります。
API は Get 操作のみをサポートする必要があります。
問題のデバッグ
Business Central の ISSUE BASE 拡張機能のユーザーが問題を報告します。
この問題をデバッグするために、次の構成のスナップショット デバッグが有効化されました。
デバッグがトリガーされていないことがわかります。
下請け業務におけるビジネスパートナーとの統合
Contoso, Ltd. は、ビジネス パートナーが提供する外部 API に Business Central を接続する必要があります。これは、パートナーが販売需要を満たすために新しい下請け注文の詳細を送信したり、送信された各注文の予定リリース日を受信したりするために使用されます。統合の要件は次のとおりです。
ビジネス パートナーは、基本認証で保護された REST API を提供します。API にアクセスするための資格情報は Contoso, Ltd. と共有されます。
下請け注文を送信するための API は、指定されたエンドポイントに認証された POST リクエストを送信することによって呼び出す必要があります。
各下請け注文の注文番号と予定リリース日を取得するための API は、次の JSON で応答します。
各注文番号を取得する必要があります。
過去 7 日間にテナント内で不要な Web サービス呼び出しがあったかどうかを確認する必要があります。
どの 2 つの KQL クエリを使用する必要がありますか? それぞれの正解は完全なソリューションを示します。
注意: 正しい選択ごとに 1 ポイントが付与されます。
MB-820 試験問題 9
ホットスポットに関する質問
ある企業は、失敗した顧客明細メールのトレースを送信するために、カスタム テレメトリ トレース信号を設定しています。
次の各文について、正しい場合は「はい」を選択してください。そうでない場合は「いいえ」を選択してください。
注意: 正しい選択ごとに 1 ポイントが付与されます。
ある企業は、失敗した顧客明細メールのトレースを送信するために、カスタム テレメトリ トレース信号を設定しています。
次の各文について、正しい場合は「はい」を選択してください。そうでない場合は「いいえ」を選択してください。
注意: 正しい選択ごとに 1 ポイントが付与されます。
MB-820 試験問題 10
ケーススタディ 2 - アルペンスキーハウス
会社概要
アルペンスキーハウスは、ホテル、レストラン、店舗を所有・運営する会社です。
現在、当社では以下のソフトウェアとインターフェースを使用しています。
- ホテルの客室を管理するためのプロパティ管理ソフトウェア（PMS）
- 売上請求書を生成し、発注書を作成するオンプレミス会計ソフトウェア
- レストランや店舗が必要な情報を取得できるようにする API レストランや店舗では、POS (販売時点管理) デバイス用のスタンドアロン ソフトウェアを使用しています。毎日、POS 端末は販売データのテキスト ファイルを生成し、そのファイルをサーバー フォルダーに保存します。アカウント アシスタントは、システムで処理できるように、そのファイルを現在のソフトウェア テーブルに手動でインポートする必要があります。
ゼネラルマネージャーは、部門マネージャーから毎月数件のレポートを受け取りますが、レポートの作成には時間がかかりすぎます。
計画された改善
同社は、会社全体を管理するために、別のシステムから Business Central Online に移行しています。
同社は、API を使用してさまざまなシステム間で情報を取得または共有することで、各部門の効率を向上させることを計画しています。
購買に関わる各部門は、購買リクエストを自動的かつ簡単に行える必要があります。各部門は ERP 管理システム全体にアクセスする必要はありません。
技術仕様
アルペンスキーハウスでは、計画されている改良のためにいくつかの拡張部分の開発が必要です。
すべての拡張機能を開発するには、Business Central 設計パターンを使用する必要があります。
アルペンスキーハウスは次のページを開発する必要があります。
- 拡張機能を初めてインストールするときに必要な情報を提供するために、ウィザードのような複数のステップのダイアログで複数の構成を提供するページ
- 関連情報と追加情報を含むページを表示する部門固有のロール センター ページ IT 部門は、Power BI を使用して部門情報を分析する予定です。最適なパフォーマンスを提供するようにデータベースを構成する必要があります。
部門固有の要件
ハウスキーピング部門
ハウスキーピング部門では、効率を高め、データ入力エラーを回避するために、次のことが必要です。
- Business Centralオンラインの関連領域へのナビゲーションを最小限に抑え、関連情報を表示するハウスキーピングロールセンター
- ルームエンティティに関する追加情報を表示するために新しいルームページに埋め込むページ
- ハウスキーピングチームが客室の問題情報を入力するための「客室インシデント」というテーブル
- 拡張機能に接続するハウスキーピングキャンバスアプリ
- 部門では、RoomsAPI という新しい API ページを備えた拡張機能の開発が必要です。
- ハウスキーピング チームは RoomsAPI を使用して、部屋の詳細を公開したり、作業完了時に更新したり、キャンバス アプリから修理通知を提供したりします。
- このカスタム API ページは、Rooms という名前のカスタム テーブルを公開し、ID を 50000 にする必要があります。テーブルは PMS から更新できる必要があります。PMS チームは、カスタム API に接続するためのエンドポイントを認識している必要があります。
- 開発者は API ページに次の詳細を提供します。
- 拡張機能は Business Central オンラインで公開する必要があり、すべてのホテルの部屋を含む「部屋リスト」という名前のリスト ページを含める必要があります。
- この拡張機能のインストールまたは更新は、次の要件を満たす必要があります。
o 一部の Web サービスは自動的に公開する必要があります。
o 指定されたアプリケーションのメタデータのバージョンは、AL 言語で取得する必要があります。o タスクを実行するために必要なコードは、アプリケーションの他の部分からアクセスできません。
部屋のインシデント テーブル情報には、次のフィールドが含まれている必要があります。
- インシデントエントリ: 増分番号
- 部屋番号: 部屋表の部屋
- 事故発生日: 作業日
o ルーム インシデント テーブルのテーブル定義では、ハウスキーピング チームが新しいレコードを挿入するときにインシデントの日付が自動入力される必要があります。o インシデントの日付の値は、Business Central オンライン クライアントで構成された作業日である必要があります。
- ステータス: インシデントのステータスを識別するための次のオプションが含まれます。
o オープン: ルームインシデントが作成されたとき
o 進行中: 誰かが修理作業を開始したとき
o クローズ: インシデントが解決されたとき
- インシデント終了日: 自動更新フィールド (ステータスが「終了」になると、フィールドは作業日で更新されます)
- インシデントの説明: テキスト
- 画像: メディアデータタイプ
o 保存された画像はメニューアクションからダウンロード可能である必要があります。
o ダウンロード アクションを含むルーム インシデント ページを開発する必要があります。
部門固有の要件
レストランとショップ
- 効率を高めるために、新しいシステムでは、POS 端末の API を使用して、レストランや店舗から生成されたデータを直接管理する必要があります。
- 会社では、POS 端末 API から情報を読み取るために、ジョブ キューから呼び出されるコードユニットが必要です。
- POS端末情報はPOS情報というテーブルに保存され、IDを持つ必要があります。
50100、ページ上で編集可能。
- アカウント マネージャーには、プロセスを手動で実行するためのオプションがページのメニューに必要です。
- POS 端末から受信した情報を分析するには、次のものが必要です。
- 情報をPower BIにエクスポートするためのticketAPIというカスタムAPI
- データベースのパフォーマンスを向上させるための読み取りスケールアウト機能の使用
部門固有の要件
購買部門と不適合処理
購買部門では、仕入先から受け取った商品の不適合を記録するために、Business Central オンラインで新しいエンティティが必要です。エンティティは次のように設定する必要があります。
- 不適合エンティティには 2 つのテーブルが必要です。
共通情報を含むoaヘッダー
o 不適合な受領品目の詳細が記載された1行以上の行
- エンティティには、情報を保存するために、「不適合」という名前のページと「不適合行」という名前のサブページが必要です。
数量の誤りや品質の問題のある発注書を受け取った場合、企業はシステム内に不適合文書を作成する必要があります。文書には次の情報を含める必要があります。
o 不適合番号: このフィールドを管理し、次の機能を使用するには、Business Central オンラインの番号シリーズ テーブルを使用する必要があります。
o 英数字の値
o 番号の一部として「NC」と年を含む数値形式。例: NC24-001
- 不適合日: 作成日のみ保存
- ベンダー番号: 商品を発送したベンダーの番号を保存します。会社のベンダーのみを含める必要があります。
- オーナー: 会社で定義された従業員のコード
- 受領番号：以下の条件を満たす必要があります。
o 既存の領収書番号であること
o ベンダー番号フィールドに示されているベンダーから受け取る
- コメント: 品質の問題を説明するために、リッチテキストと画像を含むコメントを含めることができます。
- ステータス: 次のような不適合ステータスが含まれます。
o 開く
o 通知済み
o 閉鎖
- 行には次の詳細が含まれている必要があります。
o 商品番号: 受領した商品（既存の在庫商品のみ）
o 説明: アイテムの説明
o 数量: 不適合数量
- 不適合タイプ:
o 品質
o 数量
o 配達日
不適合のシリアル番号と、不適合を作成できる期間は、ユーザーが変更できるように、構成テーブルと対応するページに記載されている必要があります。
ホットスポットに関する質問
POS 端末 API を読み取るには、コードユニットを作成する必要があります。
コード セグメントをどのように完了する必要がありますか? 回答するには、回答領域で適切なオプションを選択します。
注意: 正しい選択ごとに 1 ポイントが付与されます。
会社概要
アルペンスキーハウスは、ホテル、レストラン、店舗を所有・運営する会社です。
現在、当社では以下のソフトウェアとインターフェースを使用しています。
- ホテルの客室を管理するためのプロパティ管理ソフトウェア（PMS）
- 売上請求書を生成し、発注書を作成するオンプレミス会計ソフトウェア
- レストランや店舗が必要な情報を取得できるようにする API レストランや店舗では、POS (販売時点管理) デバイス用のスタンドアロン ソフトウェアを使用しています。毎日、POS 端末は販売データのテキスト ファイルを生成し、そのファイルをサーバー フォルダーに保存します。アカウント アシスタントは、システムで処理できるように、そのファイルを現在のソフトウェア テーブルに手動でインポートする必要があります。
ゼネラルマネージャーは、部門マネージャーから毎月数件のレポートを受け取りますが、レポートの作成には時間がかかりすぎます。
計画された改善
同社は、会社全体を管理するために、別のシステムから Business Central Online に移行しています。
同社は、API を使用してさまざまなシステム間で情報を取得または共有することで、各部門の効率を向上させることを計画しています。
購買に関わる各部門は、購買リクエストを自動的かつ簡単に行える必要があります。各部門は ERP 管理システム全体にアクセスする必要はありません。
技術仕様
アルペンスキーハウスでは、計画されている改良のためにいくつかの拡張部分の開発が必要です。
すべての拡張機能を開発するには、Business Central 設計パターンを使用する必要があります。
アルペンスキーハウスは次のページを開発する必要があります。
- 拡張機能を初めてインストールするときに必要な情報を提供するために、ウィザードのような複数のステップのダイアログで複数の構成を提供するページ
- 関連情報と追加情報を含むページを表示する部門固有のロール センター ページ IT 部門は、Power BI を使用して部門情報を分析する予定です。最適なパフォーマンスを提供するようにデータベースを構成する必要があります。
部門固有の要件
ハウスキーピング部門
ハウスキーピング部門では、効率を高め、データ入力エラーを回避するために、次のことが必要です。
- Business Centralオンラインの関連領域へのナビゲーションを最小限に抑え、関連情報を表示するハウスキーピングロールセンター
- ルームエンティティに関する追加情報を表示するために新しいルームページに埋め込むページ
- ハウスキーピングチームが客室の問題情報を入力するための「客室インシデント」というテーブル
- 拡張機能に接続するハウスキーピングキャンバスアプリ
- 部門では、RoomsAPI という新しい API ページを備えた拡張機能の開発が必要です。
- ハウスキーピング チームは RoomsAPI を使用して、部屋の詳細を公開したり、作業完了時に更新したり、キャンバス アプリから修理通知を提供したりします。
- このカスタム API ページは、Rooms という名前のカスタム テーブルを公開し、ID を 50000 にする必要があります。テーブルは PMS から更新できる必要があります。PMS チームは、カスタム API に接続するためのエンドポイントを認識している必要があります。
- 開発者は API ページに次の詳細を提供します。
- 拡張機能は Business Central オンラインで公開する必要があり、すべてのホテルの部屋を含む「部屋リスト」という名前のリスト ページを含める必要があります。
- この拡張機能のインストールまたは更新は、次の要件を満たす必要があります。
o 一部の Web サービスは自動的に公開する必要があります。
o 指定されたアプリケーションのメタデータのバージョンは、AL 言語で取得する必要があります。o タスクを実行するために必要なコードは、アプリケーションの他の部分からアクセスできません。
部屋のインシデント テーブル情報には、次のフィールドが含まれている必要があります。
- インシデントエントリ: 増分番号
- 部屋番号: 部屋表の部屋
- 事故発生日: 作業日
o ルーム インシデント テーブルのテーブル定義では、ハウスキーピング チームが新しいレコードを挿入するときにインシデントの日付が自動入力される必要があります。o インシデントの日付の値は、Business Central オンライン クライアントで構成された作業日である必要があります。
- ステータス: インシデントのステータスを識別するための次のオプションが含まれます。
o オープン: ルームインシデントが作成されたとき
o 進行中: 誰かが修理作業を開始したとき
o クローズ: インシデントが解決されたとき
- インシデント終了日: 自動更新フィールド (ステータスが「終了」になると、フィールドは作業日で更新されます)
- インシデントの説明: テキスト
- 画像: メディアデータタイプ
o 保存された画像はメニューアクションからダウンロード可能である必要があります。
o ダウンロード アクションを含むルーム インシデント ページを開発する必要があります。
部門固有の要件
レストランとショップ
- 効率を高めるために、新しいシステムでは、POS 端末の API を使用して、レストランや店舗から生成されたデータを直接管理する必要があります。
- 会社では、POS 端末 API から情報を読み取るために、ジョブ キューから呼び出されるコードユニットが必要です。
- POS端末情報はPOS情報というテーブルに保存され、IDを持つ必要があります。
50100、ページ上で編集可能。
- アカウント マネージャーには、プロセスを手動で実行するためのオプションがページのメニューに必要です。
- POS 端末から受信した情報を分析するには、次のものが必要です。
- 情報をPower BIにエクスポートするためのticketAPIというカスタムAPI
- データベースのパフォーマンスを向上させるための読み取りスケールアウト機能の使用
部門固有の要件
購買部門と不適合処理
購買部門では、仕入先から受け取った商品の不適合を記録するために、Business Central オンラインで新しいエンティティが必要です。エンティティは次のように設定する必要があります。
- 不適合エンティティには 2 つのテーブルが必要です。
共通情報を含むoaヘッダー
o 不適合な受領品目の詳細が記載された1行以上の行
- エンティティには、情報を保存するために、「不適合」という名前のページと「不適合行」という名前のサブページが必要です。
数量の誤りや品質の問題のある発注書を受け取った場合、企業はシステム内に不適合文書を作成する必要があります。文書には次の情報を含める必要があります。
o 不適合番号: このフィールドを管理し、次の機能を使用するには、Business Central オンラインの番号シリーズ テーブルを使用する必要があります。
o 英数字の値
o 番号の一部として「NC」と年を含む数値形式。例: NC24-001
- 不適合日: 作成日のみ保存
- ベンダー番号: 商品を発送したベンダーの番号を保存します。会社のベンダーのみを含める必要があります。
- オーナー: 会社で定義された従業員のコード
- 受領番号：以下の条件を満たす必要があります。
o 既存の領収書番号であること
o ベンダー番号フィールドに示されているベンダーから受け取る
- コメント: 品質の問題を説明するために、リッチテキストと画像を含むコメントを含めることができます。
- ステータス: 次のような不適合ステータスが含まれます。
o 開く
o 通知済み
o 閉鎖
- 行には次の詳細が含まれている必要があります。
o 商品番号: 受領した商品（既存の在庫商品のみ）
o 説明: アイテムの説明
o 数量: 不適合数量
- 不適合タイプ:
o 品質
o 数量
o 配達日
不適合のシリアル番号と、不適合を作成できる期間は、ユーザーが変更できるように、構成テーブルと対応するページに記載されている必要があります。
ホットスポットに関する質問
POS 端末 API を読み取るには、コードユニットを作成する必要があります。
コード セグメントをどのように完了する必要がありますか? 回答するには、回答領域で適切なオプションを選択します。
注意: 正しい選択ごとに 1 ポイントが付与されます。
