第1回 問題集（全般）

正解: A. A. Assisted Setup

正解の根拠・詳細解説

支援設定（Assisted Setup）は、Business Central が用意するガイド付きウィザードの一覧ページで、「会社の設定」「承認ワークフローの設定」「Outlook 連携」「データ移行」などを順を追って構成できる。新規会社では会社名・住所・ロゴ、基準通貨、会計年度の開始日、銀行口座といった最低限のパラメータを対話形式で入力していくため、どのセットアップページにどの項目があるかを知らなくても初期構築が完了する。混同しやすいのが Configuration Worksheet と RapidStart Services で、これらは導入コンサルタントがテーブル単位で設定値やマスタを一括移送するためのツール群であり、ウィザードで利用者を案内する仕組みではない。実務上の注意として、会計年度の開始日や基準通貨は稼働後の変更が非常に困難なため、ウィザードの段階で確定させておく必要がある。

正解: A. A. Configuration Package

正解の根拠・詳細解説

コンフィグレーションパッケージ（Configuration Package）は、移行対象のテーブル（得意先・仕入先・品目など）と、その中で実際に使うフィールドだけをパッケージ定義に登録し、Excel または XML のテンプレートとして書き出す機能。旧システムのデータをそのテンプレートに貼り付けてインポートすると、値はいったんパッケージ内の中間テーブル（コンフィグレーションパッケージレコード）に取り込まれ、「検証」でエラー行を確認・修正したうえで「適用（Apply）」して初めて本テーブルへ書き込まれる。この二段階構造により、不正データがそのまま本番マスタを汚染することを防げる点が最大の利点である。実務上の要点は処理順（Processing Order）で、記帳グループや番号シリーズなど参照先のマスタを先に適用しないと、得意先や品目の適用時に検証エラーが多発する。支援設定は単一会社の初期パラメータを案内するウィザードであり、大量マスタの一括投入には使わない。

正解: A. A. Configuration Worksheet

正解の根拠・詳細解説

コンフィグレーションワークシート（Configuration Worksheet）は、導入プロジェクトで設定・移行すべきテーブルを一覧化し、進捗を管理するための作業台となるページ。行には「エリア」「グループ」「テーブル」という行タイプがあり、業務領域ごとに階層構造で整理できる。各テーブル行には担当者（Responsible ID）、対象レコード件数、割り当てるコンフィグレーションパッケージコードなどを設定でき、ワークシートから直接パッケージを作成してテンプレートを書き出す運用が可能。つまり「何をどの順で設定するか」の計画と、「実際にデータを流し込む」実行が同じ画面でつながる点が特徴。記帳設定（Posting Setup）は取引の転記先 G/L 勘定を決める会計設定であり、番号シリーズは採番、次元組み合わせは分析軸の入力制御と、いずれも導入タスクの進捗管理とは目的が異なる。

正解: A. A. Number Series

正解の根拠・詳細解説

番号シリーズ（Number Series）は、シリーズコードごとに開始番号・終了番号・増分・警告番号を持つ「番号シリーズ行」を定義する仕組みで、行に開始日を設定すれば年度別に採番体系を切り替えることもできる。定義したシリーズは、販売＆債権設定、購買＆債務設定、在庫設定、一般会計設定などの各セットアップページで、見積・受注・請求書・入金仕訳といった文書種別ごとに割り当てる。「デフォルト番号」を有効にすると新規伝票を開いた時点で自動採番され、「手動番号」を有効にすると利用者が任意の番号を入力できるため、旧システムからの移行伝票にも対応できる。実務では未記帳伝票用と記帳済伝票用（記帳請求書番号など）を別シリーズにするのが一般的だが、監査上、番号を一致させたい場合は同じシリーズを指定する。記帳グループは転記先勘定の決定であり、採番とは無関係。

正解: A. A. User Profile（Role Center含む）

正解の根拠・詳細解説

プロファイル（ユーザープロファイル）は、サインインしたユーザーに表示されるロールセンター（Role Center）ページを決める設定で、経理担当・受注処理担当・事業主といった職務ごとに、必要な KPI キュー、アクションタイル、レポートリンク、インサイトの構成が用意されている。プロファイル単位で「ページのカスタマイズ」を行うと、フィールドの表示・非表示やアクションの配置をそのロールに属する全ユーザーへ一括で反映でき、ユーザーごとに個別調整する手間が省ける。試験で頻出の区別は、権限セット（Permission Set）が「何ができるか」というデータアクセス権を制御するのに対し、プロファイルは「何が見えるか」という UI 構成を制御するという点。両者は独立しているため、プロファイルを変更しても権限は一切変わらず、逆に権限がなければロールセンターに配置されていても該当機能は開けない。

正解: A. A. Permission Set

正解の根拠・詳細解説

権限セット（Permission Set）は、テーブルデータ・テーブル・ページ・レポート・コードユニット・XMLport・クエリといったオブジェクト単位に、読み取り（R）・挿入（I）・変更（M）・削除（D）・実行（X）の各権限を割り当てた集合体。各権限は「はい」「間接（Indirect）」「空欄」から選択でき、間接は「そのオブジェクトを直接操作はできないが、許可された他のオブジェクト経由でなら実行される」という意味を持つ。記帳処理のコードユニットが利用者に代わって G/L エントリを書き込むようなケースは、この間接権限で表現される。SUPER などシステム標準の権限セットは編集できないため、実務ではコピーして自社用のセットを作成し、複数のセットを組み合わせてユーザーに割り当てる。番号シリーズやプロファイルは権限を制御する仕組みではなく、次元は分析軸の付与機能である。

正解: A. A. Security Filter

正解の根拠・詳細解説

セキュリティフィルター（Security Filter）は、権限セットのテーブルデータ権限の行に対して条件式を設定し、そのユーザーが読み取り・更新できるレコードを行レベルで絞り込む機能。たとえばグローバル次元 1 コードに特定の部門値を指定すれば、そのユーザーには当該部門の仕訳やエントリしか見えなくなり、他部門の金額は一覧にも集計にも現れない。権限セット自体は「どのテーブルやページを操作できるか」というオブジェクト単位の粒度しか持たないため、「同じテーブルの中の一部の行だけ」を制御したい要件はセキュリティフィルターでしか満たせない点が重要な違いである。実務上の注意として、フィルター条件はデータ読み取りのたびに評価されるため、キーが張られていないフィールドを条件にすると性能が劣化しやすい。また、フィルターは権限セット単位で効くため、フィルターなしの権限セットが別途割り当てられていると制限が実質的に無効化される。

正解: A. A. Security Group

正解の根拠・詳細解説

セキュリティグループ（Security Group）は、Microsoft Entra ID（旧 Azure AD）のグループ、または Business Central 内で定義したグループにユーザーをまとめ、そのグループに対して権限セットを割り当てる仕組み。個々のユーザーに権限セットを付け替える運用では、入社・異動・退職のたびに設定漏れが生じやすいが、グループへの所属を変更するだけで権限が切り替わるため、統制と運用負荷の両面で有利になる。注意点として、Business Central の権限は加算方式であり、ユーザーに直接割り当てた権限セットとグループ経由の権限は合算される。したがって権限を減らしたい場合は、グループから外すだけでなく個人への直接割り当ても解除しなければならない。セキュリティグループは以前のバージョンで使われていたユーザーグループ（User Group）を置き換えた機能であり、現行の権限管理はこちらに統一されている。

正解: A. A. Security Auditing（Change Log）

正解の根拠・詳細解説

変更ログ（Change Log）は、まず変更ログ設定ページで監視対象のテーブルとフィールドを選び、挿入・変更・削除のどの操作を記録するかを指定したうえで「変更ログ有効化」をオンにして機能する。記録された内容は変更ログエントリとして、日時・実行ユーザー ID・テーブル・フィールド・変更前の値・変更後の値の形で蓄積され、内部統制や監査証跡、不正調査の根拠として利用される。重要な制約は、有効化した時点以降の変更しか記録されず過去に遡れないこと、そして対象を広げすぎるとエントリが爆発的に増えて性能とストレージを圧迫することである。そのため実務では、得意先の与信限度額、銀行口座番号、記帳グループ、権限設定といった影響の大きいフィールドに絞って有効化するのが定石。承認ワークフローは変更を事前に承認させる予防的統制であり、事後に何が起きたかを追跡する変更ログとは統制の性質が異なる。

正解: A. A. Report Layout（Word/RDLCレイアウト）

正解の根拠・詳細解説

Business Central のレポートは、データを取得する「データセット」（AL のレポートオブジェクト）と、見た目を定義する「レイアウト」が分離されている。そのため同じデータセットに対して、RDLC レイアウト（Visual Studio の Report Designer で編集）、Word レイアウト（Word 上で差し込みフィールドを配置）、さらに新しいバージョンでは Excel レイアウトを併存させられる。実務では標準レイアウトをコピーしてカスタムレイアウトを作成し、レポートレイアウト選択のページでどのレイアウトを使うかを指定する。加えて、販売請求書や購買注文書のような文書については、レポート選択（Report Selection）ページで文書種別ごとに使用するレポート自体を切り替える。使い分けの目安は、ロゴ差し替えや文言修正のように利用者側で保守したい変更は Word レイアウト、複雑な集計や条件付き表示、精密なページ制御が必要な場合は RDLC レイアウトである。

正解: A. A. Job Queue

正解の根拠・詳細解説

ジョブキュー（Job Queue）は、実行したいオブジェクトの種類（レポートまたはコードユニット）と ID、実行する曜日、開始・終了時刻、実行間隔（分）などをジョブキューエントリに設定し、ステータスを「準備完了」にすることで動作する。処理はバックグラウンドセッションとして実行されるため、利用者の画面を占有せず、夜間や業務時間外にまとめて走らせることができる。典型的な用途は、仕訳バッチの一括記帳、原価調整、銀行明細やレート情報の定期取込、経営者向けレポートの定時送信、承認通知メールの送信などである。エラーが発生した場合は設定された最大試行回数まで再実行され、それでも失敗するとエントリが停止するため、稼働監視と再開の運用手順を決めておく必要がある。また同一処理のエントリを重複登録すると二重記帳につながるため、登録内容の棚卸しも実務上の重要な管理項目となる。

正解: A. A. Copilot and agent capabilities の有効化設定

正解の根拠・詳細解説

Copilot や自律型エージェントを使うには、管理者が「Copilot とエージェント機能」の管理ページで、対象となる機能を個別に有効化する必要がある。ここでは販売明細の提案、マーケティングテキストの生成、銀行勘定調整の照合提案、受注受付エージェントといった機能ごとにアクティブ／非アクティブを切り替えられるため、業務上必要なものだけを段階的に開放できる。プレビュー段階の機能や、環境が置かれたリージョンの外で処理が行われる機能については、テナント管理者が Business Central 管理センターでデータ移動に関する同意を別途行う必要がある点も押さえておきたい。さらにエージェントは専用のエージェントユーザーとして動作し、その操作範囲は割り当てた権限セットで制御されるため、有効化と同時に「どこまで触らせるか」の設計が欠かせない。番号シリーズ、セキュリティフィルター、品目追跡はいずれも生成 AI の有効化とは無関係な設定である。

正解: A. A. Dimension（次元）

正解の根拠・詳細解説

次元（Dimension）は、勘定科目コードの桁数を増やすことなく分析軸を追加するための仕組み。次元コード（例：部門、プロジェクト、地域）と、その配下の次元値を定義し、仕訳行や伝票行に付与すると、記帳時に次元セット ID として各エントリに保存される。定義した次元のうち 2 つは一般会計設定でグローバル次元として登録でき、エントリテーブルに専用フィールドを持つため、リストの絞り込みや財務諸表のフィルターを高速に処理できる。それ以外は伝票行に列として表示できるショートカット次元や通常の次元として扱う。次元を使えば「部門別×プロジェクト別」といった多軸分析が可能になり、勘定科目を部門ごとに枝番で増殖させる必要がなくなるのが本質的な利点である。実務上の注意点として、グローバル次元は稼働後の変更に大掛かりな再設定と既存エントリの再割り当てを伴うため、導入時に慎重に選定しなければならない。

正解: A. A. Dimension Combination（次元組み合わせ）

正解の根拠・詳細解説

次元組み合わせ（Dimension Combination）は、2 つの次元の交差ごとに制限の有無を指定するマトリクス設定で、「制限なし」「制限あり（Limited）」「ブロック（Blocked）」の三つの状態を取る。ブロックに設定した組み合わせは、その 2 つの次元を同時に入力すること自体が拒否される。制限ありにした場合は、次元値組み合わせのページで許可した値のペアだけが入力可能となり、たとえば「管理部門にはこの製造プロジェクトは使わせない」といった業務ルールを入力段階で強制できる。これにより、存在しない部門×プロジェクトの組み合わせで記帳され、後から分析データを手作業で補正する事態を防げる。なお、混同しやすいのが「その次元を必ず入力させる」制御で、これは次元組み合わせではなく、デフォルト次元の値の記帳（Value Posting）を「コード必須」に設定することで実現する。記帳グループや番号シリーズは分析軸の入力制御には関与しない。

正解: A. A. Default Dimension（デフォルト次元）

正解の根拠・詳細解説

デフォルト次元（Default Dimension）は、G/L 勘定、得意先、仕入先、品目、固定資産、従業員といったマスタレコードごとに既定の次元値を紐付けておく設定で、伝票行や仕訳行でそのマスタを選択した瞬間に次元値が自動的に入力される。各デフォルト次元の行には「値の記帳（Value Posting）」があり、空欄なら自由入力、「コード必須」ならその次元の入力を必須化、「同一コード」なら指定した値のみ許可、「コードなし」ならその次元の使用を禁止、と入力ルールまで制御できる点が重要である。複数のマスタから異なる既定値が同時に流れ込む場合は、デフォルト次元優先順位（Default Dimension Priority）で、伝票の発生元を表すソースコードごとにどのテーブルの値を優先するかを決める。これにより手入力の削減とデータ品質の担保を同時に実現でき、次元運用の中核となる設定になっている。

正解: A. A. Posting Group（記帳グループ）

正解の根拠・詳細解説

記帳グループ（Posting Group）は、「誰との取引か」「何の取引か」に応じて転記先の G/L 勘定を自動決定する仕組みで、大きく三系統に分かれる。第一に得意先記帳グループ・仕入先記帳グループは、売掛金や買掛金といった残高勘定を決める。第二に在庫記帳グループは、在庫記帳設定において場所（ロケーション）との組み合わせで在庫勘定や仕掛品勘定を決める。第三に一般事業記帳グループ（取引相手の属性）と一般製品記帳グループ（品目やサービスの属性）の交差が一般記帳設定を構成し、売上高・売上原価・仕入・値引などの損益勘定を決定する。消費税についても同様に、VAT 事業記帳グループと VAT 製品記帳グループの交差で VAT 記帳設定が定まる。導入時に最も頻発するトラブルは、このマトリクスに未設定の組み合わせが残っており、記帳時に組み合わせが存在しない旨のエラーで処理が止まるケースである。

正解: A. A. General Ledger Setup（会計年度設定）

正解の根拠・詳細解説

会計年度は、会計期間（Accounting Periods）のページで「年度の作成」を実行し、開始日・期間の数・期間の長さ（1 か月なら 1M など）を指定して一括生成する。生成された最初の期間には「新会計年度」のフラグが立ち、これが年度の区切りとして年次締めや損益振替の判断に使われる。この会計年度の定義は、支援設定の会社設定ウィザードや一般会計設定と併せて、稼働前に必ず済ませておくべき初期セットアップの一部であり、期間が存在しないと記帳日の妥当性検証や年次処理が行えない。他の選択肢はいずれも目的が異なり、コンフィグレーションパッケージはマスタデータの一括移行、番号シリーズは文書の採番、次元組み合わせは分析軸の入力制御を担う。実務上の注意として、締めた期間には終了フラグが立ち、決算整理仕訳は年度末日の翌日と混同されないよう「決算日」として入力することで、通常の取引と区別して集計できる。

正解: A. A. サンドボックスはテスト用で本番データに影響を与えない

正解の根拠・詳細解説

サンドボックス環境は、本番環境とは別に作成される独立した環境であり、データベース・拡張機能・設定のいずれも本番から分離されている。本番のコピーを取り込んで現実に近いデータで検証することもできるが、そこで行った記帳や設定変更が本番へ反映されることは一切ない。用途は、AL による拡張機能の開発とテスト、アップグレード前の動作確認、新しい業務プロセスの試行、コンフィグレーションパッケージの適用リハーサル、権限設計の検証など幅広い。サンドボックスは Business Central 管理センターから作成でき、拡張機能からの外部 HTTP 呼び出しが既定でブロックされるなど、事故を防ぐための安全側の既定値も用意されている。「本番環境と完全に同一でデータも共有される」という選択肢は分離という前提そのものを否定する記述で、この誤解のまま操作すると本番データを破壊する事故につながるため注意が必要である。

正解: A. A. 管理者がアプリの管理ページからインストールを承認する必要がある

正解の根拠・詳細解説

AppSource で公開されている拡張機能は、管理者が「拡張機能の管理」ページ、または Business Central 管理センターや AppSource の画面から明示的にインストール・承認して初めて利用可能になる。インストール時には、そのアプリがアクセスするテーブルや外部サービスへの通信について同意を求められるため、一般ユーザーの操作だけで勝手に導入されることはなく、これがテナントを守るガバナンスの要となっている。インストール後はアプリに含まれる権限セットが自動的に取り込まれるが、ユーザーへの割り当ては別作業として必要になる点を忘れやすい。実務では、本番へ入れる前にサンドボックスで検証し、既存の拡張機能とのオブジェクト競合や業務影響、アンインストール時のデータ保持挙動を確認しておくのが定石である。また拡張機能は環境（テナント）単位で管理されるため、複数会社を運用している環境では全社に影響が及ぶ点も考慮する必要がある。

正解: A. A. Premiumには製造・サービス管理機能が含まれる

正解の根拠・詳細解説

Business Central のライセンスは機能範囲で明確に段階分けされている。Essentials は財務会計、販売・購買、在庫管理、プロジェクト（ジョブ）、倉庫管理、リレーションシップ管理など、標準的な基幹業務を一通り含む。Premium はこの Essentials の全機能に加えて、製造（部品表、生産オーダー、能力所要量計画）とサービス管理（サービスオーダー、サービス品目、サービス契約）が利用できる上位ライセンスである。Team Member は軽量ライセンスで、データの閲覧、自分に関する情報の更新、承認の実行、時間シートの入力など限定的な操作に制限される。運用上の重要な制約として、同一テナント内で Essentials と Premium を混在させることはできず、いずれかに統一する必要がある。したがって「Essentials に財務機能が含まれない」「Team Member が全機能にフルアクセス可能」「Essentials は閲覧専用」という記述はいずれも誤りである。

正解: A. A. Company Information

正解の根拠・詳細解説

会社情報（Company Information）ページは、その会社そのものの属性を保持するマスタ的な設定ページで、社名、住所、電話番号、メールアドレス、ロゴ画像、事業者登録番号や VAT 登録番号、自社の銀行口座情報、出荷元住所などを登録する。ここに入力した値は販売請求書や購買注文書などの帳票ヘッダーへ自動的に差し込まれ、電子文書やレポートの発行元情報としても使われるため、記載内容の誤りはそのまま取引先に届く帳票の誤りになる。実務でよく使われる項目にシステムインジケーターがあり、これを設定すると画面上部に会社ごとの色と文言が表示され、本番会社とテスト会社を見分けられるので、誤って本番で作業してしまう事故を防げる。一般会計設定は丸め処理や許容記帳日付範囲、グローバル次元といった会計処理ルールを定義するページであり、会社の属性情報とは役割が異なる。

正解: A. A. マスタデータと初期残高を一括投入する

正解の根拠・詳細解説

RapidStart（コンフィグレーションパッケージ）を用いた移行の主目的は、稼働開始時点で必要なマスタデータと開始残高を一括で投入することにある。マスタは得意先、仕入先、品目、勘定科目表、次元値、記帳グループなどで、開始残高は一般仕訳の行としてパッケージに取り込み、相手勘定に開始残高用の勘定を置いて記帳するのが典型的な手順である。ここで実務上の重要な勘所は、得意先・仕入先の残高を合計額だけで入れてはいけないという点で、未決済の請求書単位（期日と文書番号を持つ明細）で投入しないと、稼働後に入金消込や支払消込ができなくなる。在庫も同様に品目仕訳のプラス在庫で数量と単価を投入し、在庫の G/L 側金額と一致させる必要がある。権限の一括設定は権限セットやセキュリティグループ、レポートレイアウトの変更はレイアウト管理の領域であり、移行ツールの用途ではない。

正解: D. D. Hybrid Deployment（旧称含む）

正解の根拠・詳細解説

オンプレミスの Dynamics NAV や Business Central を稼働させたまま、クラウド版の Business Central へデータを複製し、検証しながら段階的に移し替えていく展開形態がハイブリッド展開である。クラウド移行ツールで接続を構成すると、オンプレミス側のデータがクラウドのテナントへ複製され、移行先の環境では移行済みデータが読み取り専用の状態で並行稼働する。この状態で帳票やレポート、拡張機能の動作を確認し、問題がなければカットオーバーとしてクラウド側を正式な業務システムに切り替える。一括で切り替える方式に比べ、業務停止時間を短くでき、検証期間を長く取れるのが利点である。なお選択肢にあるインテリジェントクラウドは、この連携によって実現される体験の呼称として使われる語であり、展開形態そのものを問われた場合はハイブリッド展開が答えとなる。コンフィグレーションパッケージと RapidStart Services はテーブル単位でデータを投入する導入ツールで、環境間の継続的な複製は行わない。

正解: A. A. 入力の都度繰り返す設定作業を省略できる

正解の根拠・詳細解説

一般仕訳テンプレート（General Journal Template）は仕訳の種類を定義する器で、使用するページ、記帳用レポート、ソースコード、既定の番号シリーズ、定期仕訳かどうかといった性質を保持する。その配下に置くバッチ（Batch）は、テンプレートを担当者別・拠点別・用途別に分割した作業単位で、既定の相手勘定タイプと相手勘定番号、番号シリーズ、記帳日などをあらかじめ持たせられる。この仕組みにより、たとえば毎日の現金出納であれば相手勘定に現金勘定を既定値として設定しておけば、入力のたびに勘定やソースコードを打ち直す必要がなくなる。さらに実務上大きいのは排他性で、複数の担当者が同じ種類の仕訳を扱っていても、バッチが分かれていれば互いの未記帳行が混ざらず、他人の行を巻き込んで記帳してしまう事故を防げる。セキュリティフィルターの生成や次元組み合わせの検証、レイアウトの更新はいずれも仕訳テンプレートの機能ではない。

正解: A. A. Permission SetとSecurity Filter

正解の根拠・詳細解説

部門単位の閲覧制限は、権限セットとセキュリティフィルターを組み合わせて初めて成立する。まず権限セットで「どのテーブルやページを読み書きできるか」というオブジェクト単位の権限を与え、そのうえで権限セット内のテーブルデータ権限の行にセキュリティフィルター（たとえばグローバル次元 1 コードを特定の部門値に限定する条件）を設定することで、同じテーブルの中の対象レコードだけに絞り込む。権限セットだけではそのテーブルの全レコードが見えてしまい、逆にセキュリティフィルターは権限セットの行に付随する設定なので単独では存在できないため、両者は必ずセットで機能する。実務上の注意点が二つあり、一つは権限が加算方式であるため、フィルターの付いていない別の権限セットが同じユーザーに割り当たっていると制限が実質的に無効化されること。もう一つは、エントリを次元で絞るにはその次元がグローバル次元として登録されている必要があることである。

正解: A. A. Business Central管理センター

正解の根拠・詳細解説

Business Central 管理センター（Admin Center）は、テナント管理者が環境そのもののライフサイクルを管理するためのポータルである。ここで行える主な操作は、本番環境およびサンドボックス環境の作成・コピー・名称変更・削除、アップデートの適用スケジュールの確認と延期、データベースのポイントインタイム復元、環境ごとのアプリ管理、Application Insights によるテレメトリ接続、障害や更新に関する通知の受信者管理、サポート要求の起票などである。押さえるべき区別は、管理センターが扱うのは環境のインフラ的な管理であり、会社情報や会計設定、権限の割り当てといった業務上の設定は各環境の中の Business Central クライアントで行うという点。したがってコンフィグレーションワークシート、一般会計設定、会社情報はいずれも環境の内部にある業務設定ページであり、環境自体の作成や削除には使えない。

正解: A. A. Create Company from Template/Copy

正解の根拠・詳細解説

Business Central では会社（Company）が会計データを分ける単位であり、勘定科目表、番号系列、支払条件、承認の設定といった構成情報も会社ごとに保持されます。新しい法人や事業体を立ち上げるたびにこれらをゼロから設定し直すのは手間がかかるうえ、設定の食い違いが後の比較や集計を難しくします。既存の会社を複製して新会社を作る方法をとれば、運用実績のある構成をそのまま雛形として引き継ぎ、税率や銀行口座など個別に異なる部分だけを直せば済みます。複製の際は、構成だけを引き継ぐのか取引データまで含めるのかを意識して選ぶことが大切で、本番運用中の会社を元にする場合は特に注意が要ります。なお構成パッケージはExcelを介して設定データを書き出し・取り込みする仕組みで、別のテナントや環境へ設定を移したい場合に使い分けます。

正解: A. A. Account Category（アカウントカテゴリ）

正解の根拠・詳細解説

勘定カテゴリ（Account Category）と勘定サブカテゴリは、G/L 勘定を資産・負債・資本・収益・売上原価・費用といった大分類と、その配下の任意の小分類に割り当てる仕組み。これを設定しておくと、勘定科目表に新しい勘定を追加した場合でも、貸借対照表や損益計算書、ロールセンターに表示される財務 KPI やキャッシュフロー分析に自動的に正しい区分で反映される。サブカテゴリには財務報告上の表示順やキャッシュフロー計算書での扱いを紐付けられるため、勘定を増やすたびに財務レポート（勘定表スキーマ）の定義を手作業で直す必要がなくなり、レポートの保守負荷を大きく下げられる点が実務上の価値である。記帳グループは取引の転記先勘定を決める設定、次元は分析軸の付与、番号シリーズは文書の採番であり、いずれも財務諸表上の分類や表示順序を決める機能ではない。

正解: A. A. Customer Posting Group

正解の根拠・詳細解説

得意先記帳グループ（Customer Posting Group）は得意先マスタに割り当てる分類で、その得意先との取引が総勘定元帳のどの勘定に振り替わるかを決める。中核は売掛金勘定であり、販売請求書を記帳すると、明細レベルの得意先元帳エントリが作られると同時に、この記帳グループが指す売掛金勘定へ G/L エントリが立つため、補助元帳と総勘定元帳の整合が自動的に保たれる。同じ記帳グループには前受金勘定、支払割引の借方・貸方勘定、支払時の端数調整勘定、利息や督促手数料の勘定なども定義されており、入金消込や督促の処理でもこれらが参照される。実務では、国内向け・海外向け・関係会社向けのように得意先を区分し、貸借対照表上で売掛金残高を別勘定として把握したい場合に記帳グループを分けるのが定石である。仕入先記帳グループは買掛側、在庫記帳グループは在庫資産勘定を決めるもので、対象が異なる。

正解: A. A. General Posting Setup（一般記帳設定）

正解の根拠・詳細解説

一般記帳設定（General Posting Setup）は、一般事業記帳グループ（国内・海外・関係会社など取引相手側の属性）と一般製品記帳グループ（製品・サービス・諸掛など販売購買する対象側の属性）という二つの軸のマトリクスで構成され、その交差ごとに売上高、売上原価、仕入、売上値引・仕入値引、在庫調整、諸掛などの損益系勘定を定義する。理解の要は役割分担で、販売請求書を記帳したとき、貸借対照表側の売掛金勘定は得意先記帳グループが決め、損益計算書側の売上高勘定はこの一般記帳設定が決める。なお在庫記帳グループは在庫という資産勘定を決める設定であり、損益側を決めるのは一般製品記帳グループなので混同しないよう注意したい。導入時によくある障害は、このマトリクスに未設定の交差が残っていて、その組み合わせの取引を記帳しようとした瞬間にエラーで止まるケースである。

正解: A. A. VAT Posting Setup

正解の根拠・詳細解説

VAT 記帳設定（VAT Posting Setup）は、VAT 事業記帳グループ（国内課税・輸出免税・域内取引など取引相手側の税務属性）と VAT 製品記帳グループ（標準税率・軽減税率・非課税など販売購買対象側の税務属性）の交差ごとに、VAT 識別子、税率、VAT 計算タイプ（通常 VAT、リバースチャージ VAT、全額 VAT など）、および売上 VAT 勘定・仕入 VAT 勘定を定義する。伝票を作成すると、取引先マスタ由来の事業側グループと品目マスタ由来の製品側グループが行に自動で入り、その交差から税率と転記先勘定が決まるため、担当者が税率を手入力する必要がない。この二軸構造により、同じ商品でも相手が国内か輸出かで税の扱いを自動的に切り替えられる。税率改定時は、既存の設定行の税率を直接書き換えると過去伝票の再計算や訂正処理に影響が出るため、新しい製品記帳グループと設定行を追加するか、VAT 税率変更ツールを使って切り替えるのが安全である。

正解: A. A. Bank Reconciliation（銀行勘定照合）

正解の根拠・詳細解説

銀行勘定調整（Bank Reconciliation）は、銀行から取り込んだ取引明細（銀行明細のインポート、または手入力）を調整ワークシートに並べ、Business Central 側で記帳済みの銀行元帳エントリと突き合わせる処理である。金額・日付・摘要をもとに自動照合を実行し、残ったものを担当者が手作業で対応付ける。銀行側にしか存在しない明細、たとえば振込手数料、受取利息、自動引き落としなどは、その場で仕訳を起票して銀行元帳に反映させる。すべてが対応付き、調整後の残高が銀行の残高証明と一致した時点で調整を記帳すると、対象の銀行元帳エントリに明細番号と照合済みの状態が書き込まれ、次回以降の照合対象から自動的に外れる。この一連の流れによって、帳簿上の預金残高が実際の口座残高と一致していることを継続的に保証できる。VAT 明細書は税務申告用の集計、キャッシュフロー予測は将来の資金繰り、固定資産仕訳は資産取引の記帳であり、いずれも実残高との照合とは目的が異なる。

正解: A. A. Cash Flow Forecast（キャッシュフロー予測）

正解の根拠・詳細解説

キャッシュフロー予測（Cash Flow Forecast）は、複数のデータソースから将来の入出金見込みを集約し、現預金残高がどう推移するかを示す機能である。取り込めるソースは、未消込の売掛金（得意先元帳の期日ベース）、未消込の買掛金、まだ記帳されていない販売受注や購買注文、固定資産の取得予定と売却予定、G/L 予算、そして手入力のキャッシュフロー収入・支出などで、これらを一つのタイムラインに並べて資金の過不足を可視化する。運用手順としては、キャッシュフロー予測カードでソースごとにキャッシュフロー勘定を割り当て、予測を再計算すると、チャートやロールセンターのキュー、Power BI レポートに反映される。関連機能として支払遅延予測を併用すれば、期日どおりに入金されない可能性の高い請求書を織り込んだ、より現実的な見通しを立てられる。銀行勘定調整は過去実績の照合であり、将来の予測を行う機能ではない点が明確な対比になる。

正解: A. A. Depreciation Book（償却帳簿）

正解の根拠・詳細解説

償却帳簿（Depreciation Book）は、減価償却の計算ルールと G/L 連携の方針を定義する帳簿であり、固定資産に紐付けて使う。帳簿側では、既定の償却方法、取得・償却・処分・売却損益などを総勘定元帳に連携するかどうか（統合設定）、金額の丸め処理、期中取得時の扱いなどを設定する。個々の資産と帳簿の組み合わせは固定資産償却帳簿で管理し、そこに償却方法（定額法、定率法など）、償却開始日、耐用年数または償却終了日、取得価額、残存価額といった資産固有の情報を持たせる。設計上とくに重要なのは、一つの固定資産に複数の償却帳簿を割り当てられる点で、会計上の帳簿と税務上の帳簿で異なる償却方法を並行して管理し、それぞれ別の償却額を算出できる。固定資産記帳グループは転記先勘定を決める設定、固定資産仕訳は取引を記帳する手段であり、償却ルールそのものを保持するのは償却帳簿である。

正解: A. A. FA Posting Group

正解の根拠・詳細解説

固定資産記帳グループ（FA Posting Group）は、建物・機械装置・車両・工具器具備品といった資産の種類ごとに、取得原価勘定、減価償却累計額勘定、減価償却費勘定、処分時の売却益勘定と売却損勘定、評価減や修繕費の勘定などをまとめて定義する設定である。固定資産カードの償却帳簿行にこの記帳グループを割り当てておくと、減価償却の計算と記帳、資産の売却や除却を実行したときに、それぞれの取引タイプに対応する G/L 勘定へ自動的に振り替わり、固定資産元帳と総勘定元帳の整合が保たれる。実務でよく採られる設計は、貸借対照表上の表示区分に合わせて記帳グループを分けることで、これにより資産種類別の取得原価と償却累計額を勘定残高だけで把握でき、注記作成の負担も軽くなる。得意先記帳グループは売掛側、VAT 記帳設定は消費税、次元組み合わせは分析軸の入力制御であり、固定資産の転記先とは関係しない。

正解: A. A. FA Journal

正解の根拠・詳細解説

固定資産仕訳（FA Journal）は、取得、減価償却、評価減、評価増、処分といった固定資産固有の取引タイプを指定して記帳する専用の仕訳で、行では対象の固定資産番号、償却帳簿コード、固定資産記帳タイプ、日付、金額を入力する。ここで押さえるべき使い分けは、償却帳簿の G/L 統合がオンになっている帳簿への記帳は固定資産 G/L 仕訳（FA G/L Journal）を使い、税務専用の帳簿など G/L 統合をオフにしている帳簿への記帳はこの固定資産仕訳を使う、という点である。前者は固定資産元帳と総勘定元帳の両方にエントリを作り、後者は固定資産元帳にのみエントリを作る。この分離があるため、会計上の帳簿では総勘定元帳と連動させつつ、税務上の帳簿では総勘定元帳を汚さずに別の償却計算を並行管理できる。一般仕訳や販売仕訳、品目仕訳はそれぞれ対象取引の種類が異なり、固定資産固有の記帳タイプは扱えない。

正解: A. A. G/L Budget

正解の根拠・詳細解説

G/L 予算は、予算名ごとに勘定・期間・次元の組み合わせで金額を保持する仕組みである。予算名を分けられるため、当初予算、修正予算、楽観シナリオと悲観シナリオといった複数の版を同時に持ち、比較することができる。各予算には最大四つの予算次元を割り当てられるので、部門別、プロジェクト別、地域別といった軸で予算を編成し、実績と同じ切り口で対比できる。入力はマトリクス形式の画面で直接行うほか、Excel へ書き出して編成し直し、取り込む運用も広く使われている。作成した予算は、財務レポート（勘定表スキーマ）の列定義で予算金額を参照するよう設定することで、実績と並べて差異と差異率を表示できるようになる。キャッシュフロー予測は資金繰りの見込み、配分キーは仕訳金額の按分、繰延テンプレートは収益・費用の期間配分を担う機能であり、予算実績対比そのものを提供するものではない。

正解: A. A. Allocation（配分・割当）

正解の根拠・詳細解説

配分（Allocation）は定期仕訳の機能として実装されており、定期一般仕訳の行を選んで配分の画面を開き、配分先の勘定と次元、および配分の基準（配分率、配分数量、配分金額）を設定する。記帳すると、元の仕訳行の金額がこの配分行の比率に従って自動的に分割され、複数の勘定や部門、プロジェクトへ同時に計上される。典型的な用途は、本社家賃、水道光熱費、共通システム利用料といった共通費を、面積比や人員比で各部門へ按分するケースで、部門別損益を実態に即して把握するために欠かせない処理である。配分の設定は定期仕訳の行に保存されるため、毎月同じ按分を繰り返す場合も一度定義すれば再利用でき、按分率を変更したい年度替わりのタイミングだけ見直せばよい。繰延テンプレートは一件の収益や費用を複数期間へ配分する機能、連結は子会社データの合算であり、いずれも部門按分とは目的が異なる。

正解: A. A. Recurring Journal（定期仕訳）

正解の根拠・詳細解説

定期仕訳（Recurring Journal）は、一般仕訳テンプレートの定期タイプを使い、各行に定期処理方法と定期処理頻度（1M や 1D のような日付式）を設定して使う。記帳しても行は消えず、次回の記帳日が設定した頻度に従って自動的に繰り上がるため、毎月同じ仕訳を一から作り直す必要がなくなる。実務上重要なのが定期処理方法の選択で、固定は毎回同じ金額を記帳し、可変は記帳後に金額がクリアされて毎回入力し直し、残高は指定した勘定の残高を全額振り替えて残高をゼロにする、という違いがある。さらに、これらに戻し処理を組み合わせた方法を選ぶと、記帳した翌日付で自動的に逆仕訳が起こされるため、期末の未払計上と翌期首の戻し入れといった処理を自動化できる。ここに配分機能を組み合わせれば、定額の共通費を毎月自動で部門按分することも可能になる。固定資産仕訳、品目仕訳、購買仕訳はいずれも対象取引の種類を表すもので、繰り返し入力の効率化を目的とした仕組みではない。

正解: A. A. Consolidation（連結処理）

正解の根拠・詳細解説

連結処理（Consolidation）は、子会社（事業単位）の G/L エントリを親会社側の連結用会社へ取り込み、合算して連結財務諸表を作成する機能である。前提として、各子会社の G/L 勘定に連結借方勘定と連結貸方勘定を設定し、親会社の勘定科目表へのマッピングを定義しておく必要がある。取り込み時には、勘定ごとに指定した連結換算方法（平均レート、期末レート、historical レートなど）に従って外貨建ての子会社データを親会社の基準通貨へ換算し、生じた換算差額を指定の勘定へ計上する。取り込み対象は同一データベース内の別会社でもよいし、ファイル経由で別データベースの会社から取り込むこともできる。また事業単位ごとに連結持分比率を設定できるため、完全子会社ではない会社の按分取り込みにも対応する。会社間記帳（Intercompany Posting）は関係会社間の個々の取引を相互の帳簿へ転記する仕組みであり、財務諸表を合算する連結とは別の機能である点が区別のポイント。

正解: A. A. Intercompany Posting（関連会社間記帳）

正解の根拠・詳細解説

会社間記帳（Intercompany Posting）は、グループ内の各社に会社間パートナーコードを定義し、得意先・仕入先マスタにそのパートナーを紐付けることで成立する。あわせて会社間用の勘定科目表と次元をマッピングしておくと、送信側で入力した伝票の金額が受信側の正しい勘定へ着地する。取引は会社間送信トレイと受信トレイを経由し、受信側の担当者が内容を確認して受け入れると、相手会社に対応する購買請求書や仕訳が自動生成される仕組みになっている。この仕組みの本質的な価値は、同じ取引を両社でそれぞれ手入力する二重作業をなくし、金額や日付の食い違いによって連結時に消去差額が発生するのを防げる点にある。連結（Consolidation）は各社の財務諸表を親会社側で合算する処理であり、個々の取引を相互の帳簿に転記する会社間記帳とは適用されるレイヤーが異なるため、両者の区別は試験でも問われやすい。

正解: A. A. Currency Exchange Rate（為替レート）

正解の根拠・詳細解説

為替レート（Currency Exchange Rate）は、通貨コードごとに開始日付を持つ行として登録され、為替レート額と相対為替レート額の組み合わせで換算率を表す。この二つの値で表現することにより、一単位あたりだけでなく百単位あたりのような建値にも対応できる。伝票や仕訳を記帳すると、その記帳日以前で最も新しい開始日のレートが自動的に適用され、外貨金額から現地通貨（LCY）金額が算出される。さらに、外貨建ての得意先残高・仕入先残高・銀行残高については、期末に為替レート調整のバッチを実行することで期末レートによる再評価が行われ、生じた為替差損益が設定した勘定へ計上される。実務上よくある落とし穴はレートの登録漏れで、この場合エラーにはならず過去の古いレートがそのまま適用されてしまうため、外部サービスからの自動更新を設定するか、月次で登録状況を点検する運用が欠かせない。

正解: A. A. Additional Reporting Currency（追加報告通貨）

正解の根拠・詳細解説

追加報告通貨（Additional Reporting Currency）を一般会計設定で指定すると、以降に記帳されるすべての G/L エントリに、現地通貨（LCY）の金額と並行して、その通貨で換算した金額が同時に記録されるようになる。これにより、親会社への報告やグループ標準通貨での財務諸表を、その都度換算し直すことなく即座に出力できる。設定を有効にした時点で既存エントリを追加報告通貨で再計算するバッチが実行され、換算によって生じた差額は指定した残高調整用の勘定へ計上される。注意すべきは、この設定の変更や解除が全エントリに波及する大掛かりな処理である点で、導入時に方針を確定しておくべきである。単に外貨建ての取引を扱いたいだけであれば、通貨コードと為替レートを設定すれば足り、追加報告通貨まで有効にする必要はない。繰延テンプレートは期間配分、配分キーは按分、固定資産仕訳は資産取引の記帳であり、いずれも二重通貨での記録とは無関係である。

正解: A. A. Payment Terms（支払条件）

正解の根拠・詳細解説

支払条件（Payment Terms）は、期日計算の欄に日付式を設定することで、伝票日付から支払期日を自動算出する仕組みである。たとえば当月末を表す式に一か月を加える形で設定すれば、月末締め翌月末払いという日本で一般的な条件を表現できる。あわせて割引期日計算と割引率を設定すると、一定期日までに支払われた場合の早期支払割引を自動判定でき、入金消込の際に割引額が支払割引勘定へ自動的に計上される。支払条件は得意先・仕入先マスタに既定値として登録され、伝票作成時にそこから引き継がれるが、個別の取引条件がある場合は伝票単位で上書きできる。混同されやすい支払方法（Payment Method）は、銀行振込や現金といった決済手段の分類であって期日計算は一切行わないため、両者の役割の違いを明確に理解しておく必要がある。

正解: A. A. Payment Method（支払方法）

正解の根拠・詳細解説

支払方法（Payment Method）は、銀行振込、現金、小切手、口座振替、クレジットカードといった実際の決済手段を分類するコードで、得意先・仕入先マスタや個々の伝票に設定する。単なる分類にとどまらない実務上重要な機能が相手勘定の指定で、支払方法に相手勘定タイプと相手勘定番号を設定しておくと、その支払方法を付けた請求書を記帳した時点で売掛金や買掛金を経由せず、直接その勘定へ計上される。現金販売のように請求と決済が同時に発生する取引を、一度の記帳で完結させたい場合に有効な設定である。また支払方法は、支払仕訳から電子決済ファイルを出力する際に、どの支払を対象に含めるかを絞り込む条件としても利用される。支払期日の計算ルールを決めるのはあくまで支払条件であり、支払方法ではない点を取り違えないよう注意したい。

正解: A. A. Reminder Terms（リマインダー条件）

正解の根拠・詳細解説

督促条件（Reminder Terms）は得意先マスタに割り当てる督促ルールで、その配下に督促レベルを段階的に定義する構造になっている。各レベルには、期日超過から督促を発行するまでの猶予期間、前回の督促からどれだけ経過したら次を出すかという期日計算、督促手数料、追加手数料、そして督促状に印字する冒頭文と結び文を設定できる。この段階構造により、一回目は丁寧な案内、二回目は手数料を付けた通知、三回目はより強い文面といった具合に、督促の強度を自動的に引き上げていく運用が可能になる。督促を作成すると督促ヘッダーと明細が生成され、記帳すると手数料が得意先元帳と総勘定元帳に計上される。なお遅延利息そのものの計算はファイナンスチャージ条件が担うため、督促条件は「いつ・何回・どの文面で催促するか」を管理する機能だと整理しておくと、両者を混同せずに済む。

正解: A. A. Finance Charge Terms

正解の根拠・詳細解説

ファイナンスチャージ条件（Finance Charge Terms）は、支払期日を過ぎた売掛金に対して課す遅延利息や手数料の計算ルールを定義する設定である。主な設定項目は、利率とその対象期間（何日あたりの利率か）、計算方式、最低金額、追加手数料、猶予期間などで、計算方式には期間中の日次平均残高を基準にする方式と、期日超過している残高そのものを基準にする方式がある。ここで算出された金額はファイナンスチャージメモとして発行され、記帳すると得意先元帳に新たな債権として計上されるため、以後は通常の売掛金と同様に回収管理の対象となる。督促条件（Reminder Terms）が催促状を出すタイミングと文面を管理するのに対し、ファイナンスチャージ条件は課す金額そのものを算出するという役割の違いがあり、実務ではこの二つを組み合わせて債権回収プロセス全体を設計する。

正解: A. A. Cost Accounting（コスト会計）

正解の根拠・詳細解説

コスト会計（Cost Accounting）は、総勘定元帳とは別の軸で原価を管理する管理会計向けの機能領域で、コストタイプ（原価の科目）、コストセンター（原価が発生した部門）、コストオブジェクト（原価を負担する製品やプロジェクト）という三つの構成要素でデータを保持する。運用の流れは、まず G/L エントリをコスト仕訳へ転送し、そのうえで配賦のルールを定義して、間接部門に集まった費用を配賦基準に従って製造部門や製品へ振り替えるというものである。配賦基準には固定比率のほか、金額や数量といった実績値に連動する動的な基準も指定でき、補助部門から製造部門へ、さらに製造部門から製品へという段階的な配賦も定義できる。総勘定元帳の数値を一切変更せずに管理会計視点の分析を行える点が本機能の最大の価値であり、固定資産や銀行勘定調整、連結はいずれも扱う業務領域が異なる。

正解: A. A. Deferral Template（延期テンプレート）

正解の根拠・詳細解説

繰延テンプレート（Deferral Template）は、一括で計上した収益や費用を、あらかじめ定義したスケジュールに沿って複数の会計期間へ自動的に振り分ける仕組みである。テンプレートには、いったん金額を受け入れる貸借対照表側の繰延勘定、計算方法（定額配分、期間ごとの均等配分、日数按分、ユーザー定義など）、開始日の起算方法、配分する期間数などを設定する。品目や G/L 勘定、リソースのマスタに既定の繰延テンプレートを紐付けておけば、販売請求書や購買請求書の行でそのマスタを選んだ時点で繰延スケジュールが自動生成され、必要に応じて行ごとに金額や日付を手修正することもできる。記帳すると初回に全額が繰延勘定へ入り、以後スケジュールに従って各期の損益勘定へ順次振り替えられる。年間保守契約や年払いのサブスクリプション料金を月割で費用化する場面が代表的な用途である。

正解: A. A. Prepayment（前受金管理）

正解の根拠・詳細解説

前払・前受（Prepayment）機能は、販売受注や購買注文の段階で、出荷や検収より前に代金の一部または全部を請求・授受するための仕組みである。受注ヘッダーまたは各明細行に前払率を設定して前払請求書を発行し記帳すると、金額は売上高ではなく一般記帳設定で指定した前受金勘定に計上され、得意先元帳には債権として立つ。その後に実際の出荷を行い最終請求書を記帳すると、既に請求済みの前払分が自動的に差し引かれ、前受金勘定が取り崩されると同時に売上高が計上される。この二段構えにより、代金は受け取っているが役務や商品の提供が済んでいないという状態を、会計上正しく表現できる。繰延テンプレートは既に発生した収益・費用を期間配分する機能であり、収益認識のタイミングを扱う点は似ているが、前払は入金が取引に先行するケースの管理を目的とする点で異なる。

正解: A. A. 年度末締め処理（Close Income Statement）

正解の根拠・詳細解説

年度末の締めは二段階で行う。まず会計期間のページで年度の締めを実行して対象の会計年度を終了状態にし、続いて損益計算書の締め（Close Income Statement）のバッチを実行する。このバッチは、対象年度の収益・費用の各勘定残高を相殺する仕訳行を生成し、相手勘定として指定した繰越利益の勘定へ振り替える。生成される仕訳の記帳日は決算日と呼ばれる特殊な日付で、年度最終日に決算日の印を付けたものとして扱われるため、年度最終日に発生した通常取引と決算整理仕訳が混ざらず、締め前後の財務諸表を正しく表示できる。バッチは仕訳行を生成するだけで自動記帳までは行わないので、内容を確認したうえで記帳する運用になる。なお貸借対照表側の勘定はこの処理では残高がゼロにならず、そのまま翌期へ繰り越される点も押さえておきたい。

正解: A. A. General Journal Batch（仕訳バッチ）

正解の根拠・詳細解説

仕訳バッチ（General Journal Batch）は、一般仕訳テンプレートの配下に置かれる作業単位で、同じ種類の仕訳をまとめて入力し、一括で記帳するための入れ物である。バッチには既定の相手勘定タイプと相手勘定番号、番号シリーズ、記帳番号シリーズ、理由コード、貸借差額の自動補完の可否といった設定を持たせられるため、入力の手間とミスを同時に減らせる。実務でとくに効果が大きいのは担当者ごとにバッチを分ける運用で、同じテンプレートを複数人が同時に使っていても、バッチが分かれていれば他人の未記帳行を巻き込んで記帳してしまう事故を防げる。また承認ワークフローを仕訳バッチ単位で申請・承認できるため、入力担当者と承認者を分離した内部統制も構築しやすい。番号シリーズは採番、記帳グループは転記先勘定の決定、次元組み合わせは分析軸の入力制御であり、いずれも仕訳のグループ化を担う仕組みではない。

正解: A. A. General Journal Template

正解の根拠・詳細解説

一般仕訳テンプレート（General Journal Template）は仕訳の型を定義するもので、種類（一般、販売、購買、入金、支払、資産、会社間など）、使用するページ、記帳時に使用するレポート、ソースコード、理由コード、定期仕訳かどうかといった性質を保持する。種類を指定することで業務に合った画面と機能が提供され、たとえば支払の種類なら支払仕訳のページが開き、電子決済ファイルの出力アクションが使えるようになる。またテンプレートで指定したソースコードが記帳時に自動で付与されるため、後から G/L 登録やナビゲート機能を使って「そのエントリがどの業務プロセスから発生したのか」を追跡でき、監査対応でも有用である。テンプレートの下には複数のバッチを作成できるので、同じ業務を担当者別や拠点別に分けて運用できる。定期仕訳はテンプレートの種類の一つであり、固定資産仕訳や品目仕訳は対象取引が固定された別種の仕訳である。

正解: A. A. VAT Rate Change Tool

正解の根拠・詳細解説

VAT 税率変更ツール（VAT Rate Change Tool）は、税率改定に伴って、マスタや未処理の伝票に設定されている VAT 製品記帳グループや一般製品記帳グループを、新しいグループへ一括で置き換えるためのツールである。手順としては、まず新しい税率を持つ VAT 製品記帳グループと VAT 記帳設定を作成し、次にツールの変換設定で「変換元グループから変換先グループへ」という対応表を定義する。そのうえで、品目、リソース、G/L 勘定、未記帳の販売受注・購買注文といった対象ごとに変換の可否を指定して実行する。ツールは変換ログを残すため、どのレコードがいつ変換されたかを後から確認でき、テスト的に実行して影響範囲を事前に把握することもできる。実務上の注意点は、部分出荷済みで新旧の税率が混在しうる伝票の扱いで、これらは一括変換の対象から外し、個別に確認しながら処理するのが安全である。

正解: A. A. 承認金額の閾値や仕訳種別に応じて条件分岐できる

正解の根拠・詳細解説

Business Central のワークフローは、「どのイベントが起きたら」「どのような条件のときに」「どう応答するか」という三要素を持つステップを並べて構成され、承認要求の送信はその応答の一つとして定義される。条件はワークフローステップのイベント条件としてフィルター形式で指定できるため、仕訳行の金額が一定額を超える場合だけ承認を必須にする、特定の仕訳テンプレートや文書タイプに限定して適用する、といった柔軟な分岐が可能である。誰が承認するかは承認ユーザー設定で決め、直属の上長へ回す、承認チェーンを順にたどる、特定の承認者へ直接回すといった型を選べる。さらに承認ユーザー設定には販売金額や購買金額の承認上限を設定できるため、上限を超える申請は自動的により上位の承認者へ回る。したがって「全仕訳に一律に適用される」「VAT 仕訳にのみ適用できる」「固定資産仕訳には設定できない」という記述はいずれも誤りである。

正解: A. A. Payment Journal Export（電子決済ファイル出力）

正解の根拠・詳細解説

支払仕訳（Payment Journal）で仕入先支払の提案を実行すると、支払期日や早期支払割引の期限をもとに、支払対象となる未払請求書が自動的に仕訳行として起こされる。内容を確認したうえで支払のファイル出力を実行すると、銀行が定める形式の電子決済ファイルが生成され、これをインターネットバンキングへ取り込むことで一括振込を行える。前提条件として、銀行口座に支払エクスポート形式（銀行のインポート・エクスポート設定で定義したデータ交換定義）を割り当て、仕入先マスタに振込先の銀行口座情報を登録しておく必要がある。出力した内容は振替の登録簿に記録されるため、いつ何を送金データとして出したかを後から追跡できる。銀行勘定調整は出金後に口座の実残高と帳簿を突き合わせる工程であり、支払データそのものを作成するのは支払仕訳の役割である。

正解: A. A. VAT Statement（VAT報告書）

正解の根拠・詳細解説

VAT 明細書（VAT Statement）は、行ごとに行タイプ（勘定合計、VAT エントリ合計、合計行、説明）を指定して申告書の構造を組み立てる定義表である。VAT エントリ合計の行では、対象とする VAT 事業記帳グループと VAT 製品記帳グループ、集計する金額の種類（課税標準額か VAT 額か）、売上か仕入かの区分を指定することで、記帳済みの VAT エントリから該当する金額を自動集計する。さらに合計行を使えば、課税売上高、仕入税額控除、差引納付額といった申告書上の集計項目を組み上げられる。作成した明細書はプレビューで期間ごとの数値を確認でき、申告後は VAT 決済の計算と記帳の処理によって、売上 VAT 勘定と仕入 VAT 勘定の残高を未払 VAT 勘定へ振り替え、申告済みのエントリを締める運用が一般的である。キャッシュフロー予測や固定資産記帳グループは税務申告とは無関係の機能である。

正解: A. A. FA Reclassification Journal

正解の根拠・詳細解説

固定資産再分類仕訳（FA Reclassification Journal）は、ある固定資産に計上されている取得原価や償却累計額を、全部または一部だけ別の固定資産へ移し替えるための専用仕訳である。行には移動元と移動先の固定資産番号、償却帳簿コード、移動する割合または金額を入力し、取得原価・償却累計額・評価減といったどの要素を移すかを個別に指定できる。代表的な用途は、建設仮勘定として一つの資産に集約していた金額を、完成時に建物や設備といった複数の資産へ分割する場面、部門異動に伴って資産の次元や記帳グループを変更する場面、複数の資産を一つに統合する場面などである。移動先の資産が別の固定資産記帳グループを持っていれば、結果として計上先の G/L 勘定も切り替わる。取得や償却を記帳するだけの固定資産仕訳では資産間の振り替えはできず、一般仕訳では固定資産元帳側の内訳を正しく移せないため、この専用仕訳が用意されている。

正解: A. A. Calculate Depreciation

正解の根拠・詳細解説

減価償却の計算（Calculate Depreciation）は、対象の償却帳簿と計算基準となる減価償却日を指定して実行するバッチ処理である。各固定資産の償却帳簿に設定された償却方法、償却開始日、耐用年数、取得価額、残存価額、前回の償却日をもとに当該期間の償却額を自動計算し、結果を仕訳行として生成する。生成先は帳簿の G/L 統合の設定によって決まり、統合がオンなら固定資産 G/L 仕訳へ、オフなら固定資産仕訳へ書き出されるため、内容を確認してから記帳する。固定資産クラスや部門でフィルターをかけられるので、月次で対象資産だけを処理する運用も容易である。実務上の注意点として、期中に取得した資産は償却開始日を起点に計算されるため、取得日と償却開始日を取り違えると初年度の償却額がずれる。また記帳日を誤ると二重償却や期ずれが生じるので、月次クローズの手順に組み込んで管理するのが望ましい。

正解: A. A. Bank Account Posting Group

正解の根拠・詳細解説

銀行口座記帳グループ（Bank Account Posting Group）は銀行口座カードに割り当てる分類で、その口座を通じた入出金が総勘定元帳のどの預金勘定へ計上されるかを決める。入金仕訳や支払仕訳で勘定タイプに銀行口座を選んで記帳すると、口座単位の明細である銀行元帳エントリが作成されると同時に、この記帳グループが指す G/L 勘定へ振り替えられるため、口座別の残高管理と総勘定元帳上の預金残高が常に一致する。実務では、口座ごとに勘定を分けて管理したい場合は記帳グループも口座ごとに作成し、複数口座をまとめて一つの預金勘定で管理したい場合は同じ記帳グループを共有させる、という設計判断を行う。得意先記帳グループは売掛、仕入先記帳グループは買掛、在庫記帳グループは在庫資産と対象の補助元帳が異なるだけで、補助元帳の明細を総勘定元帳の特定勘定へ結びつけるという設計思想はいずれも共通している。

正解: A. A. Purchase VAT（仕入VAT）の自動仕訳設定

正解の根拠・詳細解説

仕入請求書に対する VAT の自動計算は、VAT 記帳設定の各行に仕入 VAT 勘定を設定しておくことで機能する。購買伝票の行には、仕入先マスタ由来の VAT 事業記帳グループと品目マスタ由来の VAT 製品記帳グループが自動的に入り、その交差にある設定行から適用税率と転記先勘定が決まる仕組みである。記帳すると、税抜金額は費用または在庫の勘定へ、VAT 額は仕入 VAT 勘定へと自動的に振り分けられ、同時に VAT エントリが作成される。この VAT エントリが VAT 明細書における申告額集計の元データとなり、控除対象の仕入税額として扱われる。なお VAT 計算タイプに全額 VAT を指定すれば、輸入時に税額のみを計上するような特殊なケースにも対応できる。売上側の VAT は同じ設定行にある売上 VAT 勘定が使われるため、仕入 VAT と売上 VAT は同一の VAT 記帳設定内の異なる勘定という関係にある。

正解: A. A. Allow Posting From/To（記帳許可期間）

正解の根拠・詳細解説

一般会計設定の記帳許可開始日と記帳許可終了日に期間を設定すると、その範囲外の記帳日を持つ伝票や仕訳は記帳の時点で拒否される。月次や年次の締めが完了した期間を閉じておくことで、確定済みの決算数値が後から動いてしまう事故を確実に防げる。この設定で実務上とくに重要なのは、ユーザー単位で上書きできるという点である。ユーザー設定に個別の記帳許可期間を登録すると、そのユーザーには一般会計設定の値ではなく個人向けの設定が優先して適用されるため、たとえば一般の担当者は締め後の記帳を一切できないようにしつつ、経理責任者だけは修正記帳を行える、といった運用が実現できる。番号シリーズは文書の採番、次元組み合わせは分析軸の入力制御、セキュリティフィルターはレコード単位のアクセス制限であり、いずれも記帳日の制限とは無関係である。

正解: A. A. Dimension Set ID

正解の根拠・詳細解説

Business Central では、仕訳行や伝票行に付与した複数の次元値の組み合わせを次元セットエントリというテーブルに一意の組として登録し、その組を指し示す整数値が次元セット ID である。記帳されたエントリ側にはこの ID だけを保持させ、実際にどの次元にどの値が入っていたかという内訳は、共有された次元セットエントリを参照して取得する設計になっている。同じ組み合わせが再び使われた場合は既存の ID が再利用されるため、次元を何個使ってもエントリのレコードが肥大化せず、大量データでも性能を保てるのが利点である。この設計により、以前のバージョンで存在した使用できる次元数の構造的な制限が解消された。ただし、リストのフィルターや財務レポートで高速に絞り込みたい次元については、グローバル次元として登録してエントリテーブルの専用フィールドを使うのが実務上の定石である。

正解: A. A. 得意先/仕入先カードのPayment Terms

正解の根拠・詳細解説

支払条件は階層的に引き継がれる仕組みになっている。まずマスタである得意先カードや仕入先カードに設定した支払条件コードが既定値となり、伝票を新規作成した時点でヘッダーへコピーされ、記帳の際にそのヘッダーの値が得意先元帳・仕入先元帳のエントリへ書き込まれて支払期日が確定する。したがって、その取引先に対して継続的に標準とは異なる条件を適用したいのであればマスタ側を変更するのが正しく、単発の取引だけ条件を変えたい場合は伝票ヘッダー上で上書きすればよい。ここで注意すべきなのは、マスタを変更しても既に作成済みの伝票や記帳済みのエントリには遡って反映されないという点で、進行中の伝票がある場合は個別に見直す必要がある。会社情報は自社の属性、一般会計設定は会計処理ルール、番号シリーズは採番を担う設定であり、取引先ごとの支払条件を保持する場所ではない。

正解: A. A. Retained Earnings G/L Account（繰越利益勘定）の指定

正解の根拠・詳細解説

損益計算書の締め処理では、収益・費用の各勘定残高を相殺する仕訳行を生成する際に、その相手勘定として繰越利益の勘定を指定する。この勘定は貸借対照表の資本の部にあらかじめ用意しておく必要があり、指定を誤って損益計算書側の勘定を選んでしまうと、当期純利益が資本へ振り替わらず、翌期の開始残高に正しく引き継がれない。押さえておきたい仕組みとして、Business Central では貸借対照表の勘定を明示的に繰り越す処理は存在せず、残高はそのまま累積し続ける。年度の区切りは、決算日という特殊な日付で締め仕訳を記帳することによって表現され、この決算日を含めない期間で集計すれば損益勘定の残高がゼロになり、含めれば元の実績が見えるという形になっている。VAT 記帳設定、銀行口座記帳グループ、コスト会計はいずれも繰越利益の振替先を決める設定ではない。

正解: A. A. Bank Reconciliation（自動マッチング機能）

正解の根拠・詳細解説

銀行勘定調整は、銀行が発行する明細と会計システム上の入出金仕訳を突き合わせ、差異の原因を明らかにする業務です。件数が多い、あるいは口座が複数にわたると、1件ずつ目視で照合する方法では時間がかかり、金額は合っているのに日付や摘要が微妙に違うといったケースを見落としやすくなります。Business Central の銀行勘定調整では、銀行明細を取り込んだうえで自動マッチングを実行すると、金額・日付・取引先などの一致度をもとに候補を突き合わせ、確度の高いものを自動で対応付けます。担当者は一致しなかった明細と確度の低い候補だけを確認すればよくなり、限られた時間を例外処理に集中させられます。銀行明細を電子データで取り込む仕組みを併用すれば、口座が増えても作業量が比例して増えにくくなります。

正解: A. A. Customer Posting Group

正解の根拠・詳細解説

得意先カードに設定する得意先記帳グループ（Customer Posting Group）は、その得意先との取引が総勘定元帳のどの売掛金勘定へ振り替わるかを決める必須項目である。販売請求書を記帳すると、補助元帳の明細である得意先元帳エントリと、総勘定元帳の売掛金への G/L エントリが同時に作成されるため、両者の残高は常に一致する。この項目が空欄のままだと、記帳しようとした時点で記帳グループが指定されていない旨のエラーとなり、伝票を処理できない。実務では、国内向け・海外向け・関係会社向けのように売掛金の残高を区分して把握したい場合に、記帳グループを分けて設計する。品目カテゴリは品目の分類、リソースグループは人員や機械の分類、固定資産記帳グループは固定資産取引の転記先を決める設定であり、いずれも得意先取引の自動仕訳先を決める役割は持たない。

正解: A. A. Sales Price（販売価格表）

正解の根拠・詳細解説

販売価格は、同じ品目でも「誰に、いつ、どれだけ買うか」によって異なる単価を自動適用するための仕組みである。適用対象には特定の得意先、共通の条件を共有する得意先価格グループ、すべての得意先といった区分があり、それぞれに開始日と終了日、最低数量、通貨コード、単位コードを組み合わせて条件を定義する。伝票行で品目を選択すると、得意先・日付・数量・通貨に合致する条件のうち最も有利な単価が自動的に適用されるため、担当者が価格表を確認して手入力する必要がなく、値付けのばらつきも防げる。新しいバージョンでは価格表（Price List）に統合され、販売価格と行割引を同じ価格表の行として管理し、価格表単位で下書きから有効へステータスを切り替えたり、承認を挟んだりできるようになった。仕入価格は購買側の同等機能、品目追跡はロット・シリアル管理、品目チャージは付帯費用の配分であり、目的が異なる。

正解: A. A. Purchase Price（仕入価格表）

正解の根拠・詳細解説

仕入価格は、同じ品目でも仕入先ごとに異なる単価を自動適用するための仕組みで、仕入先コード、開始日と終了日、最低数量、通貨コード、単位コード、バリアントコードといった条件の組み合わせで単価を定義する。購買伝票の行で品目と仕入先が確定すると、条件に合致する仕入価格が自動的に単価欄へ反映されるため、担当者が見積書を都度参照する必要がなくなり、発注時の単価入力ミスも減らせる。この単価はそのまま原価計算にも影響し、記帳すると品目元帳エントリと原価エントリを通じて在庫評価額および売上原価へ反映される。販売価格と同様、新しいバージョンでは価格表に統合され、仕入価格と仕入行割引を同じ枠組みで管理できるようになっている。品目チャージは付帯費用を原価へ配分する仕組み、代替品設定は欠品時の代替提案であり、いずれも単価の自動決定を担う機能ではない。

正解: A. A. Line Discount（行割引）

正解の根拠・詳細解説

行割引（Line Discount）は、伝票の一行ごとに割引率を適用する仕組みで、品目と得意先（または得意先割引グループ、すべての得意先）、最低数量、適用期間、通貨といった条件の組み合わせで割引率をあらかじめ定義しておく。伝票行に品目と数量を入力すると、条件に合致する割引率が自動的に行へ入り、行金額から差し引かれる。とくに特徴的なのは、数量が閾値を超えたときに割引率が上がる数量割引を表現できる点で、まとめ買いを促す価格政策をシステム側で自動的に適用できる。記帳した際に割引額を売上値引などの別勘定として計上するか、正味金額だけを売上高に立てるかは、販売＆債権設定の割引記帳の設定によって決まる。請求書割引が伝票全体の合計に対して一律にかかるのに対し、行割引は行単位で品目ごとに異なる率をかけられる点が本質的な違いである。

正解: A. A. Invoice Discount（請求書割引）

正解の根拠・詳細解説

請求書割引（Invoice Discount）は、伝票全体の合計金額の規模に応じて一律の割引率を適用する仕組みである。得意先には請求書割引コードを割り当て、そのコードに対して「通貨ごとに、合計が最低いくらを超えたら何パーセント割り引くか」という段階表を登録しておく。伝票の合計が確定すると、条件に合致する割引率が求められ、割引対象となる行へ按分される形で計算される。ここで実務上重要なのが品目側の請求書割引の対象という設定で、これをオフにした品目は割引計算の母数から除外されるため、値引を認めない商品を同じ伝票に混在させることができる。また、割引額を別勘定として建てるかどうかは販売＆債権設定の割引記帳の設定で決まる。行割引が品目ごとの単価政策であるのに対し、請求書割引は取引全体の規模に報いる仕組みという位置づけであり、両者は併用できる。

正解: A. A. Sales Quote（販売見積）

正解の根拠・詳細解説

販売見積（Sales Quote）は、受注として確定する前段階で、価格・数量・納期・支払条件などを得意先に提示するための文書である。重要なのは、見積の段階では在庫の引き当ても会計上の記帳も一切行われないため、在庫数量にも財務諸表にも影響しないという点で、だからこそ複数案を作成して比較する使い方ができる。得意先が承諾したら受注として作成する操作を実行することで、見積の内容がそのまま販売受注へ変換され、元の見積は記帳済み見積として保存される。この変換により再入力による転記ミスがなくなり、見積から受注、出荷、請求までの一連の文書が相互にリンクされて追跡できるようになる。また、まだ得意先マスタに登録していない相手に対しては見込客（連絡先）宛てに見積を作成し、受注化のタイミングで得意先へ変換することも可能である。販売請求書やクレジットメモは記帳を伴う文書であり、提示段階の文書ではない。

正解: A. A. Blanket Sales Order（一括受注）

正解の根拠・詳細解説

一括受注（Blanket Sales Order）は、長期契約などで合意した品目、総数量、単価を一つの文書として登録し、そこから実際の出荷のたびに個別の販売受注を切り出していくための仕組みである。一括受注の行には合意した総数量を入れておき、今回出荷する分だけを出荷数量の欄に入力して受注を作成すると、その数量分の販売受注が生成され、一括受注側には出荷済み数量が累積して残数量が管理される。これにより、契約総量に対してどこまで消化したかを一つの画面で追跡でき、契約単価も自動的に各受注へ引き継がれるため、都度の価格確認や入力ミスがなくなる。なお一括受注そのものは在庫の引き当ても記帳も行わない点は押さえておきたい。販売見積は提示段階の文書、返品オーダーは返品処理、直送は物流の形態であり、いずれも継続契約の分割出荷を管理する仕組みではない。

正解: A. A. Drop Shipment（直送）

正解の根拠・詳細解説

直送（Drop Shipment）は、商品が自社の倉庫を一切経由せず、仕入先から得意先へ直接発送される取引形態である。手順としては、販売受注の行に直送の印を付け、購買側で直送の要求から対象の販売受注行を取り込んで購買受注を作成することにより、販売受注行と購買受注行が相互にリンクされる。このリンクが存在するため、購買側で入荷を記帳すると同時に販売側の出荷も記帳され、在庫は帳簿上通過するだけで数量としては積み上がらない。会計的には仕入と売上、および売上原価が同時に計上されるので、粗利は正しく認識される。実務上の利点は、倉庫の保管費や荷役の手間を省き、納期も短縮できる点にある。特別発注（Special Order）も受注に紐付けて発注を起こすという点は共通しているが、こちらは商品がいったん自社倉庫に入荷してから改めて出荷される点が決定的に異なる。

正解: A. A. Special Order（特別発注）

正解の根拠・詳細解説

特別発注（Special Order）は、通常は在庫として持たない品目や、特定の受注専用に調達する品目について、その販売受注に紐付けた購買受注を起こす仕組みである。販売受注の行で特別発注の印と購入先を指定し、購買側の要求ワークシートなどから購買受注を作成すると、双方の行がリンクされて調達と受注の対応関係が保たれる。直送との決定的な違いは物流経路にあり、特別発注では商品がいったん自社の指定した保管場所へ入荷し、そこで検品や梱包を行ってから得意先へ出荷される。そのため入荷から出荷までの間は自社の在庫として計上され、倉庫での受入処理と出荷処理も通常どおり発生する。この違いから、品質確認や同梱が必要な商材、複数の仕入先から届いた商品をまとめて発送したい場合には特別発注を、最短で届けたく自社で触る必要がない場合には直送を選ぶ、という使い分けになる。

正解: A. A. Item Charge（品目チャージ）

正解の根拠・詳細解説

品目チャージ（Item Charge）は、運賃、関税、保険料、検査費用といった商品本体の価格以外に発生した費用を、対象品目の原価へ上乗せするための仕組みである。購買請求書や販売伝票にタイプが品目チャージの行を追加し、その行から品目チャージの割当を開いて、どの入荷行や出荷行にいくら配分するかを、均等配分、金額按分、重量按分、容積按分といった方法で指定する。記帳すると費用は単なる経費勘定に落ちるのではなく、対象品目の品目元帳エントリの原価に加算されるため、在庫評価額とその商品を販売したときの売上原価に正しく反映される。この処理を行わないと、輸入諸掛が大きい商材では粗利が実態より高く見えてしまい、値付けの判断を誤る原因になる。実務でよくある失敗は割当を忘れたまま記帳しようとするケースで、未割当の品目チャージが残っていると記帳時にエラーとなる。

正解: A. A. Item Substitution（代替品設定）

正解の根拠・詳細解説

代替品（Item Substitution）は、品目カードから登録する代替関係のマスタで、欠品や廃番の際に提示できる代わりの品目をあらかじめ定義しておくものである。販売受注の行で在庫が不足している品目を入力すると代替品が存在する旨の通知が表示され、代替品の一覧から選ぶことで行の品目を差し替えられる。登録時には相互利用可能かどうかの設定があり、これを有効にすると A から B、B から A の双方向で代替関係が成立するため、両方向を個別に登録する必要がなくなる。また代替が発生した理由をコードとして記録しておけば、どの品目でどのような事情の代替が多いかを後から分析し、在庫政策の見直しにつなげられる。実務上の価値は、欠品を理由とした失注を防ぎつつ、代替提案の判断を担当者個人の記憶や経験に依存させない点にある。品目チャージは付帯費用の配分、特別発注は受注に紐付いた調達であり、代替提案の機能ではない。

正解: A. A. Sales Return Order（販売返品オーダー）

正解の根拠・詳細解説

販売返品オーダー（Sales Return Order）は、得意先からの返品について、物の受け入れである返品入荷と、代金の返金すなわち債権の取り消しであるクレジットメモを、一つの文書で一体的に管理するための伝票である。記帳すると、返品入荷によって商品が在庫へ戻ると同時に、クレジットメモによって得意先元帳の債権が減額される。単独の販売クレジットメモでも金額の取り消し自体はできるが、返品オーダーには記帳済み文書の行を取り込んで戻す機能があり、元の記帳済み販売請求書や出荷の行をそのまま取り込めるため、当初の単価・割引・次元・原価を引き継いだ正確な取り消しができる。この点が実務上の大きな差で、単独のクレジットメモで手入力すると原価が当初の実際原価とずれ、在庫評価が歪むおそれがある。また返品オーダーは返品理由コードの記録や、入荷と返金を分けた部分処理にも対応している。

正解: A. A. Shipping Agent（運送業者）

正解の根拠・詳細解説

運送業者（Shipping Agent）は、実際に配送を担当する運送会社をコードとして登録するマスタである。業者ごとに配送状況照会用のインターネットアドレスを設定しておくと、出荷に入力した貨物追跡番号から追跡ページを直接開けるようになり、問い合わせ対応が効率化される。さらに各運送業者の配下には運送業者サービスを定義でき、翌日配達便や通常便といったサービス区分ごとに配送所要日数を日付式で設定できる。この所要日数は納期回答の計算に使われ、得意先が指定した希望納期から逆算して出荷日を求めたり、出荷日から到着予定日を算出したりする処理に反映される。配送方法（Shipment Method）は自社便か店頭引き取りかといった引き渡し条件の分類であり、どの業者に運搬を依頼するかを表す運送業者とは保持している情報の性質が異なる。

正解: A. A. Shipment Method（配送方法）

正解の根拠・詳細解説

配送方法（Shipment Method）は、商品をどのような条件で引き渡すかを表す分類コードで、自社便配送、店頭引き取り、宅配便といった区分のほか、貿易取引ではインコタームズに基づく引き渡し条件を登録するのが一般的である。得意先・仕入先マスタに既定値として設定しておくと伝票ヘッダーへ引き継がれ、請求書や納品書、輸出入に関わる帳票へ印字される。この情報は、運賃と危険負担をどちらが負うかという商取引上の合意を示すものであるため、単なる表示項目にとどまらず、発生した運賃を品目チャージとして原価に加えるべきかどうかの判断材料にもなる。運送業者（Shipping Agent）が「どの会社が運ぶか」を表すのに対し、配送方法は「どういう条件で引き渡すか」を表すという役割の違いを押さえておきたい。支払条件は支払期日の計算、直送は物流経路の形態であり、引き渡し条件の分類ではない。

正解: A. A. Sales Document Approval Workflow（販売文書承認ワークフロー）

正解の根拠・詳細解説

一定金額を超える販売注文に上長の事前承認を求めたいという要件は、承認ワークフローで実現します。Business Central では、まず承認ユーザーの設定で申請者と承認者の関係や、その承認者が単独で承認できる金額の上限を定義し、そのうえで販売文書の承認ワークフローを有効にします。担当者が販売見積や販売注文から承認申請を行うと、文書の状態が承認待ちに変わり、承認が下りるまで転記できなくなります。金額が承認者の上限を超える場合は、階層をたどってさらに上位の承認者へ回される仕組みです。行割引や品目代替は価格や供給に関する設定であって統制の仕組みではないため、金額に応じて承認を必須にする要件は満たせません。承認の履歴が文書に残るため、内部統制上の証跡としても機能します。

正解: A. A. Item Category（品目カテゴリ）

正解の根拠・詳細解説

品目カテゴリ（Item Category）は親カテゴリを指定することで階層構造を組める分類の仕組みで、上位カテゴリに設定した内容が配下のカテゴリへ継承されるため、新しい品目を登録する際の初期値を統一できる。とくに実務で効くのがカテゴリに品目属性（色、サイズ、素材、規格など）を割り当てられる点で、属性値を条件に品目を検索・絞り込みできるようになり、数千点規模の品目を扱う卸売や小売では商品選択の効率が大きく向上する。レポート側では、カテゴリ別の売上高、粗利、在庫回転率を集計する軸として利用でき、品目単位では見えない商品群ごとの傾向を把握できる。品目チャージは付帯費用を原価へ配分する仕組み、単位は数量の換算、棚番は倉庫内の保管位置であり、いずれも品目を分類してレポートや検索を効率化する目的の設定ではない。

正解: A. A. Item Tracking（品目トラッキング）

正解の根拠・詳細解説

品目追跡（Item Tracking）は、品目追跡コードを品目カードに割り当てることで有効になる。追跡コード側では、シリアル番号とロット番号のそれぞれについて、入庫時に番号の入力を必須とするか、出庫時に必須とするか、既存の番号のみを許可するかといった条件を細かく制御できるため、「入荷時にロットを採番し、出荷時には必ずロットを指定させる」といった運用をシステム側で強制できる。伝票行から品目追跡行を開いて番号と数量を入力し記帳すると、品目元帳エントリに番号が紐付き、以後は追跡の画面から「このロットをどの仕入先から入荷し、どの得意先へ出荷したか」を上流方向にも下流方向にもたどれるようになる。食品や医薬品のリコール対応、機器のシリアル別保証管理が代表的な用途である。有効期限を併せて管理すれば、期限の近いものから優先して出庫させる運用も実現できる。

正解: A. A. Unit of Measure（単位）

正解の根拠・詳細解説

品目には基本単位（Base Unit of Measure）を一つ定義し、それを 1 とした換算係数によって箱やパレットといった単位を追加登録する。在庫数量は常に基本単位に換算して保持されるため、箱単位で購入して個単位で販売するような運用でも在庫の整合が崩れない。品目カードには販売単位と購買単位を指定でき、伝票を作成すると用途に応じた既定の単位が自動的に入るので、担当者が毎回換算を意識する必要がなくなる。実務でとくに注意すべきなのが換算係数の誤登録で、たとえば 1 箱 12 個のものを 10 個と登録してしまうと、以降のすべての取引で在庫数量も原価も狂ってしまい、稼働後に気づいても既存エントリへ遡って修正できないため復旧が極めて厄介になる。品目追跡はロット・シリアル管理、棚番は保管位置、品目カテゴリは分類であり、単位の換算を担う設定ではない。

正解: A. A. Transfer Order（移動オーダー）

正解の根拠・詳細解説

移動オーダー（Transfer Order）は、ある保管場所から別の保管場所へ在庫を移すための専用文書で、出庫元と入庫先の保管場所に加えて、輸送中の状態を表す通過用の保管場所を指定するのが特徴である。出庫を記帳すると在庫は出庫元から輸送中の保管場所へ移り、入庫を記帳すると輸送中から入庫先へ移るという二段階の処理になる。この輸送中という状態を持つことが本機能の要点で、拠点間の輸送に日数を要する場合でも、モノが現在どこにあるかを常に帳簿上で把握でき、在庫がどの拠点にも計上されない空白期間が生じない。また移動経路を設定しておけば、運送業者と所要日数から入庫予定日を自動計算できる。品目再分類仕訳でも保管場所の変更自体は可能だが、こちらは即時に属性を付け替えるだけで輸送中の状態を持たないため、物理的な輸送を伴う拠点間移動には移動オーダーを使う。

正解: A. A. Advanced Warehousing（Bin管理）

正解の根拠・詳細解説

保管場所カードには倉庫機能を段階的に有効化するチェックボックス群があり、棚番を必須にすると倉庫内の保管位置単位で在庫を管理できるようになる。さらに入荷・出荷・入庫・出庫の各処理を必須とし、誘導入庫・ピックを有効にすると、倉庫入荷、倉庫入庫、出庫、倉庫出荷といった独立した倉庫文書を経由する高度な倉庫管理となり、販売受注や購買受注の記帳と現場の倉庫作業が明確に分離される。この構成では、棚番タイプ、棚番ランキング、棚番の容量制限、棚番内容の設定に基づいて、システムが格納先の棚番やピッキング元の棚番を自動的に提案するため、作業者は指示に従うだけでよく、教育コストと誤出荷を同時に減らせる。基本的な倉庫管理では棚番を使えても倉庫文書を介さない簡易な運用にとどまるため、多品種かつ大量出荷の現場では高度な倉庫管理が選択される。

正解: A. A. Physical Inventory（実地棚卸）

正解の根拠・詳細解説

実地棚卸（Physical Inventory）の標準的な流れは、実地棚卸仕訳で実地棚卸の計算を実行し、対象の品目と保管場所ごとに現在のシステム上の在庫数量を行として自動生成することから始まる。次に棚卸リストを出力して現場で実際の数量を数え、その結果を実地棚卸数量の欄へ入力する。システムがシステム数量との差を自動計算し、記帳すると差異分だけプラス在庫またはマイナス在庫の品目元帳エントリが作成され、同時に在庫調整の G/L エントリも計上されるため、帳簿在庫と実在庫、さらに総勘定元帳の在庫金額が一致する。棚番管理を行っている倉庫では、倉庫実地棚卸の仕組みを使って棚番単位で数え、その結果を品目側へ反映させる。実務上の重要な注意点は、棚卸の最中に入出庫を記帳すると数え漏れや二重計上が生じるため、対象範囲の取引を一時的に凍結する運用ルールを併せて定めることである。

正解: A. A. Item Reclassification Journal

正解の根拠・詳細解説

品目再分類仕訳（Item Reclassification Journal）は、在庫の総数量を変えずに、その在庫が持つ属性だけを付け替えるための仕訳である。行には元の保管場所・棚番・バリアント・次元と、変更後の値を並べて入力し、記帳すると元の属性でマイナス、新しい属性でプラスの品目元帳エントリが対で作成される結果、総量は変わらないまま内訳だけが移動する。品目追跡を使っている場合は、ロット番号やシリアル番号、有効期限の付け替えにもこの仕訳を用いる。移動オーダーとの使い分けが実務では重要で、輸送中の状態を管理する必要がある拠点間の物理的な移動には移動オーダーを、同一倉庫内での棚替えや属性の登録誤りを訂正する即時の付け替えには再分類仕訳を使う。実地棚卸仕訳は数量そのものの差異を調整するための仕訳であり、属性の付け替えには使えない。

正解: A. A. Jobs（プロジェクト管理）

正解の根拠・詳細解説

プロジェクト管理（Jobs）は、案件単位で計画と実績を突き合わせ、収益性を追跡するための機能領域である。構造は階層的で、プロジェクトの下にプロジェクトタスクを置き、各タスクに計画行として予算と請求予定を持たせ、実績はプロジェクト仕訳や購買請求書、タイムシートからの消費として積み上がっていく。扱えるタイプは品目、リソース（工数）、G/L 勘定（外注費や経費）の三種類で、モノ・ヒト・カネが混在する案件でも一元的に原価と売価を管理できる。請求方法も柔軟で、実費請求、固定価格、進行に応じた分割請求といった契約形態に合わせて計画行の種類を使い分ける。決算時には仕掛の計算によって未完了案件の収益認識を調整する。リソースは工数の提供能力そのものを管理するマスタ、製造は生産オーダーの領域であり、案件単位の予実管理を担うのはプロジェクト管理である。

正解: A. A. Job Task（プロジェクトタスク）

正解の根拠・詳細解説

プロジェクトタスク（Job Task）は、一つのプロジェクトを工程やフェーズ、成果物といった単位に分解して管理するための行構造である。各タスクにはタスク番号と説明のほかタスクタイプを設定でき、明細行に加えて見出しや合計、開始合計・終了合計を組み合わせることで、プロジェクトの中に階層と小計を作れる。これにより、プロジェクト全体だけでなく工程単位でも予算と実績を比較でき、どの工程で採算が悪化しているかを特定できる点が実務上の価値である。計画行も実績の記帳もすべてタスクに紐付くため、集計の切り口が最初から用意されていることになる。さらにタスクごとに仕掛計算の対象とするかどうかを制御できるので、社内負担の工程と顧客請求する工程を分けて扱える。計画行は予算の中身、プロジェクト仕訳は実績の記帳、仕掛計算は決算時の収益認識処理であり、いずれもタスクという器の中で機能する。

正解: A. A. Job Planning Line（プロジェクト計画行）

正解の根拠・詳細解説

プロジェクト計画行（Job Planning Line）は、タスクごとに「何をどれだけ使う予定か」「いくらで請求する予定か」を登録する行で、最大の特徴は行タイプとして予算、請求可能、その両方のいずれかを指定できる点にある。予算のみの行はコスト計画としてだけ扱われて請求対象にならず、請求可能のみの行は原価を伴わずに請求だけを計画し、両方を指定した行は消費と請求の双方に使われる。この区別によって、社内で負担する作業と顧客に請求する作業を明確に分離できる。行には品目、リソース、G/L 勘定のいずれかのタイプを指定し、数量、原価単価、売価単価を入力することで、計画段階での原価総額と収益総額、したがって想定粗利が算出される。実績が積み上がるにつれて計画との差異が表示されるため、採算悪化を早期に検知できる。請求段階では計画行から販売請求書を作成できるので、請求漏れの防止にもつながる。

正解: A. A. Job Journal（プロジェクト仕訳）

正解の根拠・詳細解説

プロジェクト仕訳（Job Journal）は、プロジェクトに対して実際に発生した資材の消費、リソースの工数、経費を記帳するための専用仕訳である。行にはプロジェクト番号とタスク番号、タイプ（品目・リソース・G/L 勘定）、数量、原価単価、売価単価を入力し、記帳するとプロジェクト元帳エントリが作成される。品目タイプの行を記帳すると実際に在庫が減り、リソースタイプの行はリソース元帳にも記録されるため、在庫管理や稼働管理と自然に連動し、同じ情報を二度入力する必要がない設計になっている。また計画行から仕訳行を生成する機能があるので、計画どおりに実施した工程は効率よく実績化できる。工数については、タイムシートで記録し承認を経てからプロジェクト仕訳へ流し込む運用が一般的で、承認された工数のみが原価になるという統制を効かせられる。計画行は予定、仕訳は実績という役割分担を押さえておきたい。

正解: A. A. Job WIP（仕掛工事）計算

正解の根拠・詳細解説

プロジェクト仕掛（Job WIP）の計算は、決算時点でまだ完了していないプロジェクトについて、既に発生した原価と既に請求した金額との間のズレを調整し、財務諸表へ適切に反映するための処理である。プロジェクトカードに設定した仕掛計算方式（原価価値、売上原価、売価、完成基準など）に従って、当期に認識すべき収益と繰り延べるべき原価を算出し、その結果を仕掛の仕訳として総勘定元帳へ記帳する。この処理があることで、原価だけが先行して費用計上されて利益が過少に見える、あるいは前倒しで請求した分だけが売上に立って利益が過大に見える、といった期間損益の歪みを防げる。プロジェクトが完了した時点で完了処理を行い、計上済みの仕掛を戻して最終的な損益を確定させる。計画行は予算、タスクは構造、リソースグループは要員の分類であり、いずれも決算時の収益認識調整を担う機能ではない。

正解: A. A. Resources（リソース管理）

正解の根拠・詳細解説

リソース（Resources）は、社員やコンサルタントといった人的資源、あるいは機械や車両などの設備を、品目とは別のマスタとして管理する仕組みである。各リソースには直接原価単価、間接費率、そこから算出される単位原価、および単位売価を設定でき、プロジェクトやサービス、販売伝票で工数を計上した際に原価と収益の両方が自動的に計算される。さらにリソースには稼働可能容量をカレンダー単位で登録できるため、計画された作業量と対比することで稼働率や過負荷を可視化し、要員計画の判断材料にできる。工数の実績はタイムシートで記録し、承認を経てプロジェクト仕訳やリソース仕訳へ反映される。品目が在庫として持てるモノを扱うのに対し、リソースは在庫として持てないサービス提供能力を扱うという点が本質的な違いであり、役務提供を主とする業種ではリソースが売上の中心を担う。

正解: A. A. Resource Group（リソースグループ）

正解の根拠・詳細解説

リソースグループ（Resource Group）は、スキル、役割、部門といった観点で複数のリソースをまとめる分類である。グループ単位で原価単価や売価単価を設定できるため、「この職種の単価は一律いくら」という価格政策を個々の要員に依存せず適用でき、担当者が交代しても見積や請求の条件が変わらないという安定性が得られる。また計画の段階では、誰が担当するかを確定させずにグループ単位で工数を計画・予約しておき、実施が近づいてから具体的なリソースを割り当てるという運用ができるため、要員調整の柔軟性が高まる。容量についてもグループに属するリソースの合計として把握できるので、部門全体の負荷を見ながら新規案件の受注可否を判断できる。プロジェクトタスクはプロジェクトの分解構造、品目カテゴリは品目の分類、棚番は保管位置であり、いずれもリソースをまとめる仕組みではない。

正解: A. A. Approval Workflow（承認ワークフロー）

正解の根拠・詳細解説

承認ワークフロー（Approval Workflow）は Business Central のワークフロー基盤の上に構築されており、購買請求書、販売受注、仕入先カード、仕訳バッチなど多様な対象に適用できる。仕組みとしては、承認要求の送信というイベントを起点に、金額の閾値や文書タイプ、特定のフィールド値といった条件で対象を絞り込み、応答として承認要求の作成と通知の送信を行う。誰が承認するかは承認ユーザー設定で決まり、直属の上長へ回す、承認チェーンを順にたどる、特定の承認者へ直接回すといった型を選択できる。実務上とくに重要なのは、承認待ちの文書はステータスが承認保留中となり、記帳や内容の変更がロックされる点で、これにより承認前に処理が進んでしまう事故を構造的に防げる。通知は情報を伝えるだけの仕組みで処理を止める力を持たないため、統制をかけたい場面では承認ワークフローが必要になる。

正解: A. A. Notification（通知）

正解の根拠・詳細解説

Business Central の通知には性質の異なるものがある。一つは画面上部に表示されるインラインの通知で、与信限度額の超過や過去の未払残高の存在といった状況を、担当者が伝票を編集しているまさにその場で知らせ、判断を促す。もう一つは承認ワークフローと連動した通知で、承認要求が回ってきたことや、承認・却下されたことを、アプリ内の通知エントリやメールで関係者に届ける。受け取り方は通知設定で制御でき、対象ユーザーごとにメールで受け取るかアプリ内で受け取るか、即時に受け取るか日次でまとめて受け取るかを選べる。ここで押さえておきたいのは、通知はあくまで気づきを与える仕組みであり、それ自体が処理を止める力は持たないという点である。処理を確実に止めて統制をかけたい場合は、承認ワークフローによって文書のステータスをロックする必要がある。

正解: A. A. Document Management（Incoming Documents）

正解の根拠・詳細解説

受信文書（Incoming Documents）は、取引先から届いた紙や PDF の請求書・領収書を Business Central に取り込み、業務データと紐付けて保管する機能である。ファイルをアップロードするか、取り込み用に設定したメールアドレス宛ての添付ファイルを取得すると受信文書のレコードが作成され、そこから購買請求書などの伝票を直接作成できる。作成した伝票や記帳後のエントリには元の受信文書へのリンクが残るため、後から仕訳を見て「この金額の根拠となった原本はどれか」をその場で開いて確認でき、監査対応や取引先からの問い合わせ対応にかかる時間を大幅に短縮できる。逆に記帳済みのエントリ側から、まだ原本が紐付いていないものを探す機能もあるため、添付漏れの検出にも使える。受信文書はステータスで処理状況を管理するので、届いた請求書の処理漏れも防止できる。

正解: A. A. OCR Service（光学文字認識サービス）

正解の根拠・詳細解説

OCR サービスは、受信文書として取り込んだ請求書の画像や PDF を外部の文字認識サービスへ送信し、取引先名、請求書番号、日付、金額、税額、明細といった項目を構造化されたデータとして読み取って返してもらう仕組みである。返ってきたデータは受信文書に反映され、そこから購買請求書を自動生成できるため、手入力の工数と転記ミスを大きく削減できる。運用上の要点は仕入先の特定にあり、読み取られた取引先名や登録番号をもとに既存の仕入先マスタと突き合わせるため、対応関係を一度設定しておくと以降の認識精度と自動化率が上がる。また読み取り結果は担当者が確認・修正してから記帳する前提であり、完全な無人化ではなく人のチェックを組み込む設計が現実的である。Power Automate は業務フローの自動化、Power BI は可視化のためのサービスであり、文字認識そのものを行うものではない。

正解: A. A. Email Setup（SMTP/Outlook連携設定）

正解の根拠・詳細解説

Business Central からメールを送信するには、まずメールアカウントを登録する必要がある。選択肢としては、サインインしているユーザー自身の Microsoft 365 アカウント、部門などで使う共有メールボックス、あるいは SMTP サーバーを利用する方法がある。登録したアカウントはメールシナリオの割り当てによって用途ごとに使い分けられ、たとえば販売請求書の送付は営業用の共有アドレスから、督促状は経理用のアドレスから送る、といった振り分けが可能になる。これにより、顧客宛ての正式な文書が担当者個人のアドレスから送られてしまう事態を避けられる。送信したメールは記録として残るため、対象の文書からいつ誰に送ったかを後から確認できる。なお受信側については、受信文書の取り込み用に専用アドレスを設定する仕組みが別途用意されている。プロジェクトタスク、リソースグループ、品目カテゴリはいずれもメール送受信の前提設定とは無関係である。

正解: A. A. Power BI

正解の根拠・詳細解説

Business Central は Power BI 向けのコンテンツと API による接続を備えており、財務・販売・在庫といった業務データを Power BI に取り込んでダッシュボードやレポートとして可視化できる。作成したレポートは Business Central のロールセンターや各リストページの Power BI パーツに埋め込めるため、担当者は別のツールへ切り替えることなく、いま見ているリストの文脈に沿った分析を参照できる。この連携の本質的な価値は、標準のレポート機能では扱いにくい複数会社の横断集計、長期の時系列トレンド、他システムのデータとの突き合わせ、そして対話的なドリルダウン分析を実現できる点にある。Power Automate は業務フローの自動化、Power Apps はカスタムアプリの作成、Excel 連携は表計算上でのデータ編集と、同じ Power Platform でもそれぞれ担う役割が明確に異なる。

正解: A. A. Power Automate

正解の根拠・詳細解説

Power Automate は Business Central 用のコネクタを備えており、レコードの作成や変更、承認要求の発生といった出来事をトリガーとして、Teams への通知、メール送信、SharePoint への保存、他システムの API 呼び出しといった一連の処理を自動実行できる。とくに承認まわりでは、Business Central 標準のワークフローに代えて Power Automate のフローを承認処理として使う構成が用意されており、承認者は Teams や Outlook 上のカードから、Business Central を開くことなく承認・却下を行える。これにより承認の待ち時間が短縮され、外出中やリモート勤務でも業務が滞らない。設計上の注意点は、フローが失敗すると承認が止まったままになりうることで、失敗時の通知と再実行の運用をあらかじめ組み込んでおく必要がある。Power BI は可視化、Power Apps はアプリ作成、OCR は文字認識であり、業務フローの自動化を担うのは Power Automate である。

正解: A. A. Power Apps

正解の根拠・詳細解説

Power Apps は、Business Central のコネクタを通じてデータを読み書きするカスタムアプリを、ほとんどコードを書かずに作成できるサービスである。典型的な用途は、配送ドライバーが現場で納品を確認するアプリ、倉庫担当がタブレットで棚卸数量を入力するアプリ、営業が訪問先で在庫と価格だけを照会するアプリなど、標準画面ほどの多機能さは不要だが特定の作業に最適化された入力・参照手段が欲しい場面である。標準のモバイルアプリが Business Central の画面をそのまま提供するのに対し、Power Apps では業務に必要な項目だけに絞った独自の画面を設計できる点が決定的な違いになる。またアプリからの操作も Business Central 側の権限とビジネスロジックを経由するため、権限設定を回避して不正なデータが入り込むことはない。Power BI は可視化、Power Automate はフローの自動化を担うサービスである。

正解: A. A. Edit in Excel（Excelで編集）

正解の根拠・詳細解説

Excel で編集（Edit in Excel）は、リストページの内容を Excel ブックとして開き、その中で値を修正して発行し直すことで、変更内容を Business Central へ書き戻せる機能である。単なるエクスポートとの決定的な違いは、ブックに専用のアドインが組み込まれており、Business Central へ再接続して更新を送信する点にある。書き戻しの際は Business Central 側の入力検証とビジネスロジックが働くため、不正な値はエラーとして拒否され、画面から入力した場合と同じ整合性が保たれる。大量のマスタを一括で修正したい場合や、価格の見直しを表計算上で検討しながら反映したい場合に効果が大きい。実務上の注意点として、フィルターをかけた状態で開くと対象がその範囲に限定されること、そして書き戻せるのは行の値の更新が中心で、テーブルの構造や集計項目を Excel 側で変えても反映されないことを理解しておく必要がある。

正解: A. A. Account Schedule（アカウントスケジュール）

正解の根拠・詳細解説

勘定表スキーマ（Account Schedule、新しいバージョンでは財務レポート）は、行定義と列定義を組み合わせて独自の財務諸表や分析資料を作成する機能である。行定義では、対象とする G/L 勘定や勘定カテゴリ、他の行を参照する合計式、比率を求める数式などを行ごとに設定し、必要な階層と小計を組み立てる。列定義では、当期実績、前期実績、予算、増減額、増減率、累計といった列の性質を指定でき、比較レポートを自由に構成できる。この二つを掛け合わせることで、貸借対照表や損益計算書はもちろん、部門別の管理会計資料や KPI 一覧まで、プログラムを書かずに作成できる。さらに次元でフィルターすれば、同じ定義を部門別やプロジェクト別に切り替えて出力することも可能である。作成したレポートはロールセンターに配置して常時参照したり、Excel へ書き出して加工したりできる。

正解: A. A. Word Report Layout

正解の根拠・詳細解説

Word レポートレイアウトは、レポートのデータセットの項目を差し込みフィールドとして Word 文書に配置し、その文書をレイアウトとして使用する仕組みである。標準レイアウトをダウンロードして Word で開き、ロゴの差し替え、フォントや文言の変更、項目の並べ替えを行ってから再びアップロードすれば、カスタムレイアウトとして利用できる。RDLC レイアウトの編集が Visual Studio の Report Designer を必要とするのに対し、Word レイアウトは業務担当者が使い慣れたツールで編集できるため、請求書や納品書の体裁変更のように頻度が高く軽微な修正を、開発者の手を借りずに自社で完結できる点が最大の利点である。一方で、複雑な集計、条件による表示の切り替え、細かなページ制御が求められる帳票では RDLC のほうが適している。勘定表スキーマは財務レポートの定義、Excel で編集はデータ編集の機能であり、帳票レイアウトの仕組みではない。

正解: A. A. Copilotによる販売注文作成支援

正解の根拠・詳細解説

Business Central の Copilot には、受け取った注文メールなどの自然言語のテキストから、該当する品目と数量を推定して販売受注の行を組み立てる支援機能が用意されている。仕組みとしては、テキスト中の商品名や型番、数量の記述を解析し、品目マスタの品目名や説明、さらに得意先固有の品番やバーコードを保持する品目参照と突き合わせて候補を提示する。担当者は提示された行を確認し、必要に応じて修正したうえで採用するため、最終的な判断と責任は人が持つ設計になっている。これによって、メールやファイルで届く非定型の注文を手作業で転記する時間を短縮しつつ、品番の取り違えも減らせる。実務では、得意先が使っている独自の呼称や品番を品目参照として登録しておくほど候補の精度が上がる。OCR は画像から文字を読み取る技術であり、テキストの意味を解釈して受注行を組み立てる機能ではない。

正解: A. A. Copilotによる銀行勘定照合の支援

正解の根拠・詳細解説

銀行勘定調整における Copilot の支援は、取り込んだ銀行明細の各行について、摘要・金額・日付をもとに対応する銀行元帳エントリや未消込の得意先・仕入先エントリの候補を提示し、対応先が見つからない行についてはどの G/L 勘定へ計上すべきかを提案するというものである。従来は担当者が摘要の文字列を目で追いながら一件ずつ突き合わせていた部分が自動化されるため、月次の照合作業にかかる時間を大きく削減できる。ここで重要なのは、Copilot はあくまで候補を提示するにとどまり、採用するかどうかは担当者が確認して決定するという点で、提案を無条件にそのまま記帳する運用にすべきではない。またこの機能を利用するには、管理者が Copilot 機能の有効化をあらかじめ行っている必要がある。OCR は文字認識、Power Apps はアプリ作成であり、いずれも照合候補の推定を担う機能ではない。

正解: A. A. Agent（エージェント機能）

正解の根拠・詳細解説

エージェント機能は、Copilot のように人の操作を補助するのではなく、与えられた業務プロセスを人に代わって自律的に進める点に特徴がある。代表例が販売受注エージェントで、注文の問い合わせメールを受け取ると、得意先の特定、品目と数量の解釈、在庫と価格の確認、見積や受注の作成、そして得意先への返信までを一連の流れとして実行する。設計上の要点は統制で、エージェントは専用のエージェントユーザーとして動作し、割り当てられた権限セットの範囲でしか操作できないほか、どの段階で人の確認を挟むかを構成できるため、重要な判断は必ず人が承認するという運用を組める。実行された処理は履歴として残るので、何がどのように自動処理されたかを後から検証できる。通知は情報を伝えるだけの仕組み、プロジェクトタスクは案件の分解構造、リソースグループは要員の分類であり、いずれも自律的に業務を遂行するものではない。

正解: A. A. データクレンジング（移行前検証）

正解の根拠・詳細解説

データ移行の成否は、移行ツールの操作そのものよりも、投入する元データの品質でほぼ決まる。データクレンジングでは、重複した得意先や品目の名寄せ、既に廃止して今後使わないマスタの除外、コード体系の統一（全角と半角の混在、桁数、前ゼロの扱い）、必須項目の欠落の補完、そして参照先の整合性（伝票で使う記帳グループや支払条件のコードが移行先に存在するか）などを、投入前に洗い出して修正する。この工程を省くと、コンフィグレーションパッケージの適用時に大量の検証エラーが発生して手戻りになるばかりか、エラーにならずに取り込まれてしまった不正なデータが稼働後に運用トラブルとして表面化する。実務では、いきなり本番へ流さずサンドボックスで試験投入し、件数と合計金額を移行元と突き合わせて検証するのが定石である。仕掛計算や勘定表スキーマ、Power BI 連携は移行前のデータ品質確保とは無関係の作業である。

正解: A. A. Business Central用データ移行ツール（QuickBooks用等）

正解の根拠・詳細解説

Business Central には、特定の会計システムからの移行を想定した専用のデータ移行機能が用意されており、支援設定のデータ移行ウィザードから移行元を選んで実行する。専用ツールの利点は、移行元の項目と Business Central 側の項目との対応があらかじめ定義されている点にあり、汎用のコンフィグレーションパッケージのようにテーブルとフィールドの対応を一から設計する必要がなく、書き出したファイルを指定するだけでマスタや残高を取り込める。そのぶん柔軟性は低く、標準の対応表から外れる独自項目や特殊な残高の持ち方は結局コンフィグレーションパッケージで補うことになるため、実務では両者を併用するのが現実的である。いずれの方法を採る場合でも、取り込み後に件数と合計金額を移行元と突き合わせる検証は欠かせない。プロジェクト仕訳や品目再分類仕訳は日常業務の記帳を行う仕訳であり、移行のためのツールではない。

正解: A. A. Change Log（変更ログ）

正解の根拠・詳細解説

変更ログは、記録した変更を変更ログエントリというテーブルに蓄積し、いつ・誰が・どのテーブルのどのフィールドを・どの値からどの値へ変更したかを一件ずつ保持する。挿入や削除については、レコード全体が追加あるいは削除された事実も記録される。エントリはユーザー、日付、テーブル、変更の種類で絞り込んで検索でき、特定のレコードに紐づく履歴だけを追うこともできる。またエントリは通常の操作では編集できず、削除も専用の削除処理を通してしか行えないため、証跡としての信頼性が担保されている。実務でこの機能が真価を発揮するのは、得意先の振込先口座が誰かに書き換えられていないかといった不正の検知や、この金額はいつから間違っていたのかというミスの原因調査の場面である。通知は事象の伝達、勘定表スキーマは財務レポートの定義、リソースグループは要員の分類であり、変更の証跡を残す機能ではない。

正解: A. A. Posted Document再印刷/再送信

正解の根拠・詳細解説

Business Central では、記帳した時点で伝票は記帳済み販売請求書などの記帳済み文書として保存され、内容を変更できない不変の記録となる。そのため得意先から再発行を求められた場合は、この記帳済み文書を開いて印刷し直すか、PDF として保存するか、メールで送信し直せばよく、同じ内容の請求書を作り直す必要はない。文書番号も当初のまま維持されるので、取引先側の管理番号との対応関係も崩れない。実務でよく併用されるのが、メール送信時に PDF を自動添付する機能と、レポート選択で文書種別ごとに使用する帳票を切り替えておく設定である。なお記載内容そのものを訂正したい場合は、再印刷ではなく訂正の機能でクレジットメモを起こして取り消し、正しい内容で改めて請求するという手順を踏む。この不変性があるからこそ、記帳済み文書は監査上の証跡として機能する。

正解: A. A. Personalization（個人設定）

正解の根拠・詳細解説

個人設定（Personalization）は、利用者自身が自分の画面だけを調整する機能で、フィールドや列の表示・非表示、位置の入れ替え、アクションの配置変更、ファクトボックスの開閉、ロールセンター上のパーツの並べ替えなどを、管理者や開発者に依頼することなくその場で行える。変更内容はそのユーザーのその画面にのみ保存され、他のユーザーの表示には一切影響しない。ここで押さえておきたいのが上位階層の存在で、プロファイル単位のページのカスタマイズは管理者がロール全体の既定の見え方を定義するものであり、個人設定はその土台の上に重ねて適用される。行き過ぎて画面が使いづらくなった場合は、個人設定をクリアして既定の状態へ戻せる。プロファイルは役割単位の画面構成、セキュリティフィルターと権限セットはアクセス制御であり、いずれも個人が見た目を調整するための機能ではない。

正解: A. A. Business Central モバイルアプリ

正解の根拠・詳細解説

Business Central のモバイルアプリは、スマートフォンやタブレット向けに最適化された公式クライアントで、ブラウザ版とまったく同じデータに、同じ権限設定のもとでアクセスする。画面はデバイスの大きさに合わせて自動的に再構成され、電話帳からの発信や、カメラで撮影した画像をそのまま受信文書や品目の写真として添付するといった、モバイル端末ならではの機能も利用できる。典型的な用途は、外出先での承認処理、顧客訪問時の在庫と価格の照会、経費領収書の撮影と登録、KPI の確認などである。Power Apps で作る独自アプリとの違いは、モバイルアプリが Business Central の画面をそのまま提供するのに対し、Power Apps は必要な機能だけを切り出した専用画面を設計する点にあり、幅広い業務を汎用的に扱うなら公式アプリ、単一の作業に特化させるなら Power Apps という使い分けになる。

正解: A. A. 環境（Environment）内の会社（Company）

正解の根拠・詳細解説

Business Central のテナントは環境（Environment）という単位に分かれ、その環境の中に複数の会社（Company）を作成できる。環境は本番かサンドボックスかという区分、データベース、インストールされた拡張機能、更新の適用スケジュールを持つ器であり、会社はその中で帳簿を分ける単位である。したがって法人ごとに勘定科目表、記帳グループ、番号シリーズ、取引データは完全に独立する一方、同じ環境に属する会社は同じ拡張機能とバージョンを共有することになる。ユーザーの権限セットは会社を指定して割り当てられるため、特定の会社の帳簿だけを操作させるといった制御も可能である。実務で重要なのは、拡張機能を導入する判断が環境全体に及ぶという点で、一社のためだけに入れたアプリも同じ環境の他の会社に影響しうるため、影響範囲をサンドボックスで確認してから本番へ適用するべきである。

正解: A. A. Sandbox Refresh（サンドボックス更新）

正解の根拠・詳細解説

Business Central 管理センターでは、本番環境のコピーからサンドボックス環境を作成でき、既存のサンドボックスについても本番の最新データで作り直す形で更新できる。これにより、実データに近い状態で拡張機能の検証、アップグレードの事前確認、設定変更の影響評価、担当者のトレーニングといった作業を行える。重要な前提として、この操作はサンドボックス側のデータを本番のもので置き換えるため、そのサンドボックスで進めていた作業内容は失われる。したがって、検証中の設定やテストデータは事前に退避するか、コンフィグレーションパッケージとして書き出しておく必要がある。またコピーされた環境では、外部へのメール送信や外部連携が誤って実行されないよう、接続まわりの設定を見直すのが実務上の作法である。環境のバックアップと復元は障害時の復旧を目的とした別の機能であり、テスト環境を最新データで作り直すこととは用途が異なる。

正解: A. A. Application Insights（テレメトリ）

正解の根拠・詳細解説

Business Central は Azure Application Insights へテレメトリを送信でき、管理センターで環境ごとに接続を設定すると、サインイン、ページの表示、レポートの実行、拡張機能の動作、ジョブキューの実行結果、データベースのロックや長時間クエリといった出来事が、構造化されたイベントとして蓄積される。これをクエリで検索・集計することにより、どの処理が遅いのか、どの拡張機能がエラーを出しているのか、いつどのような操作が集中しているのかを、事実に基づいて把握できる。これによって性能問題や障害の原因調査を憶測に頼らず進められるようになる点が最大の価値である。運用ではアラートを設定し、ジョブキューの失敗率や記帳エラーの急増を検知して能動的に対応する使い方も一般的である。Power BI は業務データの可視化、Power Automate はフローの自動化であり、システム自体の稼働状況を収集する仕組みではない。

正解: A. A. Job Queue Entries（ジョブキューエントリ）一覧

正解の根拠・詳細解説

ジョブキューエントリの一覧は、その環境で登録されているバックグラウンド処理を一望し、管理するためのページである。各行には実行するオブジェクト、実行する曜日と時間帯、実行間隔、そして現在のステータス（準備完了、保留、処理中、エラー、完了）が表示されるため、想定どおり動いているものと止まっているものをその場で判別できる。行を開けばエラーメッセージや最終実行日時を確認でき、原因を修正したうえで再び準備完了に戻して再開させたり、一時的に保留にして止めたりする操作も一覧から行える。実務上の運用ポイントは二つあり、一つはエラーで停止したエントリが自動では復旧しないため、定期的に一覧を点検する手順を業務に組み込むこと、もう一つは同じ処理を重複して登録しないよう定期的に棚卸しすることである。変更ログは変更の証跡、勘定表スキーマは財務レポートの定義、リソースグループは要員の分類であり、バックグラウンド処理の管理には使えない。

正解: B. B. Resource

正解の根拠・詳細解説

Business Centralの販売・購買文書の明細行には「種類」列があり、品目のほかにリソース、勘定科目、固定資産などを選択できる。清掃や設置作業のように、モノではなく人や機械が提供する作業を計上する場合は、リソースマスタを登録して行の種類にリソースを指定する。リソースには単位（時間など）、原価、単価を設定できるため、作業時間の数量と金額を明細として管理でき、計上するとリソース元帳に実績が記録されて消費や収益性の分析が可能になる。プロジェクト管理機能とも連携しやすい。Aの勘定科目行でも金額を直接総勘定元帳に記帳することはできるが、数量や単価としての管理、作業実績の蓄積ができないため、サービスを継続的に販売する用途には向かない。Cの品目カテゴリは品目を分類するための設定、Dのビン設定は倉庫内の保管場所を管理する設定であり、いずれも販売行に計上するマスタではない。