移行設計のベストプラクティス（順序・検証・照合）

移行の成否は FBDI の操作よりも設計で決まります。「何を」「どこまで」「どの順で」「何をもって正しいとするか」を、取込を始める前に決めます。
範囲は 設定・マスタ・残高・未決トランザクション に絞り、履歴の全件移行は原則しません。残高を補助簿と GL のどちらに持たせるかを決め、二重計上を避けます。
順序は 依存関係 で決まります。組織・COA → 取引先・品目 → 残高 → 未決トランザクションの順に、参照される側を先に作ります。
検証は 件数 → 金額 → 補助簿と GL の一致 の 3 段です。リハーサルを重ね、所要時間・エラー率・照合結果を毎回記録します。
性能は 分割と並列 で作ります。上限や移行中の設定変更は公式ブログの推奨例を出発点にし、自分の環境で実測して決めます。

このページには、公式ドキュメントや公式ブログで確認した事項と、移行プロジェクトで一般的に使われる進め方（方法論）が混ざっています。方法論には「例」「一般的に」と添え、Oracle が定めた手順とは区別しています。公式ブログの数値（GL は 2023 年 9 月、AP は 2025 年 7 月の公開）は対象リリースが明記されていないため、設計に使う前に自分の環境で確認してください。

全体像

設計で決める 6 つのこと

設計項目	決めること	成果物
範囲と方針	何を移行し、何を移行しないか。基準日、履歴の持ち方	移行方針書、移行対象一覧
クレンジングとマッピング	データの整え方。旧コードから Fusion の値への対応	マッピング定義書、コード変換表
移行順序	何を先に入れるか	移行順序表
検証と照合	何をもって正しいとするか	検証計画、照合シート
リハーサルとカットオーバー	何回、どの規模で練習するか。本番の段取り	リハーサル計画、手順書
性能	ファイルの分割、並列数、所要時間	実行計画

流れは次のとおりです。リハーサルで同じ流れを繰り返し、手順と時間を固めてから本番に進みます。

範囲・方針の決定
 → 抽出・クレンジング → マッピング（変換）→ テンプレートの CSV 生成
 → ロード・インポート → 検証・照合 → エラーの修正・再実行
 （ここまでをリハーサルで繰り返す）
 → 本番カットオーバー → 稼働後の確認（ハイパーケア）

担当は分けます。抽出とクレンジングはデータの持ち主、変換・取込・エラー分析は移行チーム、照合の確認と Go/No-Go の判断は業務側とプロジェクトの責任者です。FBDI の手順は FBDI、自動化は erpintegrations を参照してください。

範囲と方針

結論：稼働初日から業務を続けるのに必要なものだけを移します。

種類	範囲の考え方	例
設定	移行ではなく、設定として環境間で移す	元帳、BU、COA、支払条件（FSM）
マスタ	稼働後に使うものだけ。無効・長期未使用は移さない	有効な取引先・顧客・品目
残高	基準日時点の残高。必要な期間だけ	GL 期首残高、在庫の手持数量、固定資産
未決トランザクション	未完了のものだけ	AP 未払請求書、AR 未決済、未完了の購買オーダー、未出荷の受注
履歴	原則移さない。参照は旧システムの保管や分析基盤で	完了済みの取引明細

方針として、先に次を決めます。

基準日：たとえば月末（期末）に切り替えると、期首残高を旧システムの期末試算表と照合しやすくなります。
履歴の年数：公式ブログは GL について「残高 2 年分、仕訳 1 年分」の変換を推奨しています（2023 年 9 月）。法定の保存期間や分析の要件は別の話なので、経理・監査と合意します。
補助簿と GL の持ち方（二重計上の回避）：AP の未払請求書や AR の未決済は、補助簿に取り込んで会計処理すると GL に仕訳として載ります。そこへ GL の期首残高で買掛金・売掛金などの統制勘定をそのまま入れると、二重になります。代表的な方法は、GL の期首残高から補助簿が持つ統制勘定の分を除き、その分は補助簿の会計処理で GL に載せることです。会計方針で変わるため、方法を移行方針書に書いて経理責任者と合意します。
FBDI で移せないデータ：AP の前払請求書は FBDI テンプレートで作れません（26D 時点）。仕入先銀行口座の FBDI は作成のみで、更新には使えません。別の手段（REST・スプレッドシート）か手作業かを決めます。
切替方式：全拠点を一斉に切り替えるか、拠点・機能ごとに段階的に切り替えるか。旧システムとの並行稼働の期間も決めます。

クレンジングとマッピング

クレンジング

旧データを次の観点で点検します。重複（同じ取引先の複数コード）、無効・休眠データ、必須項目の欠け、桁と文字種（全角・半角、機種依存文字）、日付・数値の形式、通貨の小数桁（円は小数なし）。
直すのはデータの持ち主です。移行チームは「ルールとエラー一覧」を出し、直したデータを次のリハーサルの抽出に反映します。変換ルールで直すなら、ルールを記録して再現できるようにします。
取引先の名寄せは移行前に済ませます（仕入先管理）。

マッピング定義

項目ごとに「旧システムの項目 → 変換ルール → 移行先（テンプレートのシートと列、またはインタフェース表の列）」を定義します。移行先の列は、公式のテンプレートとインタフェース表の定義から引きます。
COA（旧勘定 → 新 COA）：対応を 1 対 1、多対 1（統合）、1 対多（分割）に分けます。1 対多は金額の按分ルールが要ります。決めずに進めると、期首残高が合いません。変換ルールごとに、旧残高の合計と新残高の合計が一致することを確認します（COA・元帳）。
コード変換表：取引先コード、支払条件、BU、税区分、通貨、単位などを新旧の対応表にします。FBDI に入れるのは Fusion に設定済みの名称・コードです。たとえば AP の請求書では、ソース（SOURCE）は定義済みの値と一致させる必要があり、OPERATING_UNIT と ORG_ID を両方入れて食い違うとリジェクトされます。
旧キーの保持：旧システムの伝票番号や取引先コードを Fusion のどの項目に残すかを決めます。AP の請求書番号は、同じ取引先の中で重複するとリジェクトされるため、旧システムで重複がないかを事前に確認します。

識別子と命名の規約

「どのファイルが、どの実行で入ったか」を後から追えるようにします。

識別子	使う場所	決め方の例
ファイル名	UCM の zip、importBulkData の `FileName`	`<対象>_<リハーサル回>_<日付>_<連番>.zip`（例：`ApInvoices_R2_20261015_01.zip`）
Import Set・Invoice Group（AP）	Import Payables Invoices のパラメータ	Import Set は要求ごとに一意にする。並列にするときは Invoice Group でも分ける（AP のブログ）
Group ID（GL）	Import Journals、インタフェース表の GROUP_ID	ファイルごとに一意にする（公式ブログ）。型はテンプレートで確認

移行順序と依存関係

結論：参照される側を先に作ります。次は代表的な順序です。

段階	対象	主な手段（インポート・プロセス）	先に必要なもの
0 設定	企業構造、COA の構造と値セット、カレンダー、通貨、参照データセット、支払条件、税、セキュリティ	FSM、Rapid Implementation、構成パッケージ	なし
1 COA と為替	COA の値・階層、勘定組合せ、日次為替レート	FBDI（Import Segment Values and Hierarchies、Import Account Combinations、Import and Calculate Daily Rates）	0
2 取引先・従業員	仕入先（ヘッダ → 住所 → サイト → サイト割当 → 連絡先）、仕入先銀行口座、顧客、従業員	FBDI（Import Suppliers ほか、Import Supplier Bank Accounts、Import Trading Community Data in Bulk）。従業員は HCM Data Loader	0、1
3 品目	品目、組織への割当	FBDI（Item Import）	0（在庫組織など）
4 残高	GL 期首残高、在庫の手持数量、固定資産	FBDI（Import Journals、Create Inventory Transactions、Post Mass Additions）	1、3
5 未決トランザクション	AP 未払請求書、AR 未決済と未消込入金、未完了の購買オーダー、未出荷の受注	FBDI（Import Payables Invoices、Import AutoInvoice、Process Receipts Through Lockbox、Import Orders）。受注は OM の取込	1、2、3
6 稼働後の連携	日次の取込など継続的な連携	importBulkData、OIC	稼働

対象ごとのテンプレートとインポート・プロセスの一覧は FBDI とデータ移行の全体像にあります。この表で押さえるのは順序です。

同じ段階の中は並行できます（仕入先と顧客など）。守るのは、段階をまたぐ依存です。
AP の請求書は、請求 BU から使えるサイトを持つ仕入先、勘定組合せ、取込できる状態の期間（GL 日付）が前提です。明細に購買オーダー番号を付けるなら、購買オーダーが先に必要です。
仕入先は子データまで順に取り込みます（仕入先管理の表）。サイト割当が漏れると、BU から使えません。
方針 3 の方法をとるなら、GL の期首残高（段階 4）は統制勘定を除いた分とし、統制勘定の残高は未決トランザクション（段階 5）の会計処理で GL に載せます。
順序の誤りはリハーサルでエラーとして現れます。表は「リハーサルで確かめた順序」に更新します。

検証と照合

結論：3 段で確認し、合格基準はリハーサルで決めてから本番に臨みます。

3 段の検証

段	確認すること	主な根拠
件数	旧システムの抽出件数＝意図的な除外＋取込成功＋未解決のリジェクト	ロードのログ、インポートの出力、本表の件数
金額	通貨別の合計、GL は借方合計と貸方合計、取引先・顧客別の残高が旧システムと一致する	抽出ファイルと CSV の合計、本表の集計（SQL・OTBI）
補助簿と GL	補助簿の残高が GL の統制勘定の残高と一致する	Prepare Payables／Receivables to General Ledger Reconciliation の照合レポート

これに 業務確認 を加えます。移行した請求書で支払処理を回す、移行した未決済に入金を消し込むといった業務シナリオを画面で通し、数字が合うだけでなく業務を続けられることを確認します。

補助簿と GL の照合

AP と AR は、統制勘定に財務カテゴリ（Accounts Payable／Accounts Receivable）を割り当てたうえで、Prepare Payables to General Ledger Reconciliation／Prepare Receivables to General Ledger Reconciliation を実行し、照合レポートで差を見ます（AP の設定と期間締め、AR の期間締めと GL 照合）。
在庫や固定資産も、補助簿の合計が GL の対応勘定と一致することを確認します。使う照合レポートは各モジュールのガイドで確認します。
GL に取り込んだ仕訳は、公式ブログの方法で、ソース別・バッチ別・期間別・仕訳別の合計を元データと照合します。差があれば、元データの仕訳行と勘定組合せを比べて掘り下げます。
期間ごとに「取込 → 転記 → 照合」を済ませてから期間を閉じ、次の期間を開きます（GL のブログ）。

差異の扱い

差異は原因で分類し、1 件ずつ記録します。

分類	例	対処
意図した差	移行対象外としたデータ、変換ルールによる丸め	根拠を記録し、承認を得る
データ品質	リジェクトが未解決、重複番号の付け替え漏れ	修正して再取込（FBDI のエラー処理）
設定・準備	期間がクローズ、勘定組合せがない、為替レート未登録	設定を直して再取込
二重・漏れ	統制勘定の二重計上、取込漏れ	方針と手順を見直し、リハーサルでやり直す

端数と為替の許容差は、あらかじめ決めます。外貨の残高は換算レートで差が出るため、基準日のレートを先に登録し、旧システムのレートと比べておきます。

リハーサル計画

結論：リハーサルは、手順・時間・データ品質・照合方法の 4 つを本番の前に確かめるためのものです。

回	目的	対象データ	終了基準（例）
1 回目	手順・マッピング・順序の確認。エラーの洗い出し	一部（代表的な BU・元帳など）	最後まで流せる。エラーの原因を分類できた
2 回目	全件での件数・金額の照合、所要時間の実測、業務確認	全件	差異を説明できる。時間が本番の枠に収まる見込み
3 回目（ドレスリハーサル）	本番と同じ時間割・体制・手順書で通す。Go/No-Go の練習	全件（直近の抽出）	手順書どおり時間内に完了し、合格基準を満たす

回数と規模は例です。案件の規模と複雑さで決めます。運用のポイントは次のとおりです。

毎回きれいな状態から始める：環境のリフレッシュ（T2T など）で、設定だけを入れた環境の状態に戻します。移行先は 7 日に 1 回までなど、回数と所要時間に制約があるため、環境計画に組み込みます（環境管理）。
設定をそろえる：設定データを本番の想定と同じにします（Gold 環境から構成パッケージで反映）。設定が違うと、エラーが出ない、または本番だけで出ます。
測るものを決める：工程別の所要時間（抽出・変換・ロード・インポート・検証・会計処理・転記）、件数、エラー率と原因別の内訳、手戻り件数、照合の差異、手作業の有無。
手順書を育てる：ジョブ名・パラメータ・ファイル名・実行順を書き、実行ログと突き合わせて直します。本番は手順書の再現にします。投入・監視・ログ取得を erpintegrations のスクリプトにすると、手順のばらつきが減ります。
外部への影響を止める：メール通知や支払ファイルの送信が外に出ないようにします（リフレッシュ後の確認項目は環境管理のページ）。

カットオーバー計画

結論：本番は「戻せない」前提で計画し、Go/No-Go を取込の前後に置きます。T は切替日です。

T-数週間  移行方針・手順書の承認、リハーサルの完了、Go/No-Go 基準の合意
T-1 週間  設定データの最終反映、マスタ変更の凍結、為替レート・期間の準備
T-1 日    手順書・体制・連絡網の最終確認、権限・接続・ジョブの準備
T 日      旧システムの入力停止 → 最終抽出 → 変換 → ロード・インポート（順序どおり）
          → 検証・照合 → Go/No-Go の判定 → ユーザー開放 → 定期ジョブ・連携の有効化
T+ 稼働後 ハイパーケア（日次の照合・問い合わせ・エラー対応）→ 初回の月次締め

Go/No-Go の基準を数値で決める：件数・金額の差異、未解決のリジェクト、照合レポートの差異、業務確認の結果。判定者と判定の時刻も決めます。
戻し方を決める：本番はリフレッシュの移行先にできないため、取込済みのデータを環境ごと元に戻すことは前提にできません。取消ややり直しの可否はオブジェクトごとに違います。「戻れない点」を決め、それより前に判定します。現実的な備えは、旧システムを一定期間残し、緊急時に業務を続けられるようにすることです。
本番の準備を手順書に入れる：
- 期間：移行対象の期間をオープンし、期間ごとに取込・転記・照合を済ませてから閉じる
- 為替レート：基準日のレートを登録する
- 通知と外部連携：移行中は、承認通知、取引先へのメール、支払ファイルの送信を止め、稼働時に有効化する
- 定期ジョブ：日次の取込、Create Accounting、転記、支払などを本番で登録する
- 移行用に変えた設定：採番、検証ルール、承認などを、戻すものと戻さないものに分ける（後述）
- 権限：移行用ユーザーとロールを付与し、稼働後に見直す
稼働後を決める：抽出後から稼働までに旧システムで発生した取引の扱い（凍結、または差分ファイルで追加）、ハイパーケアの期間と窓口、未解決のリジェクトの管理、旧システムの参照期間と廃止の条件。

性能（分割と並列）

結論：ファイルを分け、同じ工程の中で並列に流します。並列の上限は環境で決まるため、リハーサルで実測します。

取込	分割の単位	並列を分ける識別子	公式の目安
GL 仕訳（Import Journals）	ソース・元帳・期間ごとにファイルを分ける	Group ID（ファイルごとに一意）	1 ファイル 100 万件以下。元帳・ソース・Group ID ごとに最大 20 並列（ESS の容量による）
AP 請求書（Import Payables Invoices）	類似の請求書を同じバッチにまとめる	Import Set と Invoice Group	BU・Import Set・Import Group ごとに最大 20 ジョブ（環境による）
調達の取込（Playbook の例）	1 回の取込の件数とサイズ	—	1 回 10 万件まで（または同時 5 本まで）、ZIP 250 MB 以下、ファイル 1 GB 以下

GL と AP の目安は公式ブログ（GL：2023 年 9 月、AP：2025 年 7 月）、調達の目安は Integration Playbook の記載です。ほかの取込は各 FBDI ガイドで確認します。

GL のファイルは Excel ではなく CSV で作ります（GL のブログ）。
工程は直列に進みます（ロード → インポート → 検証 → 会計処理 → 転記）。並列にするのは同じ工程の中です。いちばん遅い工程が全体の時間を決めるため、工程別に実測して重点的に分割します。
避けること：同じ元帳・ソースで All Group Id の Import Journals を同時に複数投入する。Invoice Validation と Invoice Approval を並列で走らせる。同じ購買オーダーに照合する請求書を、並列のバッチに分ける（AP のブログ）。
事前準備として、GL では Optimize Journal Import Performance（権限 General Ledger Technical Administration、My Oracle Support の Doc ID 2559114.1）を実行し、インターフェース表を Purge Interface Tables で整理します。AP のブログは、移行前の表の統計情報の収集と、Create Accounting の処理単位（SLA の Processing Unit size）の調整も挙げています。
並列の上限は ESS の同時実行数で決まり、同じジョブどうしの非互換でブロックされることもあります（ESS の「依存関係と非互換性」）。
所要時間は「工程別の実測 ÷ 並列数」で見積もり、余裕を持たせて本番の枠を決めます。

移行中に変える設定

公式ブログが「移行の前に変える」と挙げている設定です。

対象	設定	移行中の扱い	出典（公式ブログ）
GL	勘定の組合せ検証ルール（Cross-Validation Rules）	無効にする	GL（2023 年 9 月）
GL	仕訳の採番（Sequencing）	無効にする（転記の実行時間に影響する）	GL
GL	予算管理（Budgetary Control）	管理予算が未定義なら無効にする	GL
GL	AutoPost	ソースと元帳で有効にする。元帳ごとに転記の優先度を設定する	GL
GL	会計期間	Future-Enterable または Open（転記は Open が必要）。1 期間ずつ開ける	GL
AP	ドキュメント採番	無効にする（ギャップレス採番は 1 件ずつの処理になる）	AP（2025 年 7 月）
AP	Calculate Tax During Import	N にする（税計算は Invoice Validation で行う）	AP
AP	承認	請求書ソース単位で承認不要にする手順がある（My Oracle Support の KB21351）	AP

これらは移行が終わったら戻すものが大半です。戻す・戻さないを決め、カットオーバー手順書に入れます。検証ルール・採番・承認は、戻し忘れると稼働後の統制に穴があきます。

移行設計書の目次例

次の 15 章を出発点に、案件に合わせて増減します。

目的・範囲・前提：目的、対象、基準日、移行しないもの
移行方針：履歴の持ち方、補助簿と GL の持ち方、切替方式、FBDI で移せないデータ
移行対象一覧：オブジェクト・手段・件数・担当・依存先（全体像の例）
移行順序と依存関係：段階、前提、並行できる範囲
データ品質：クレンジングの規則、除外条件、責任分担
マッピング定義：項目、COA の新旧対応、コード変換表、旧キー
オブジェクト別の移行方式：テンプレート、インポート・プロセス、パラメータ、ファイル名・識別子の規約
環境・権限・ツール：環境計画、移行用ユーザーとロール、自動化の構成
検証・照合計画：件数・金額・補助簿と GL、業務確認、合格基準、差異の分類
リハーサル計画：回数、目的、評価項目、終了基準
カットオーバー計画：凍結、手順書、Go/No-Go、戻し方、体制・連絡網
性能設計：分割、並列数、所要時間、移行中の設定変更と復元
エラー処理と再実行：リジェクトの修正、パージ、再投入のルール
稼働後の対応：ハイパーケア、差分移行、旧システムの扱い
リスクと課題、承認：リスク一覧、判断が必要な事項、承認者

コード例

マッピング定義書（AP 請求書の抜粋）

移行先の列名は、AP のインタフェース表（AP_INVOICES_INTERFACE、AP_INVOICE_LINES_INTERFACE）の公式定義にある名前です。旧システムの項目名は架空です。

No,移行先（テーブル.列）,旧システムの項目,変換ルール,備考
1,AP_INVOICES_INTERFACE.OPERATING_UNIT,拠点コード,コード変換表 BU_MAP で Fusion の BU 名へ,ORG_ID も入れる場合は食い違うとリジェクト
2,AP_INVOICES_INTERFACE.SOURCE,（なし）,固定値 External,Source の参照タイプに定義済みの値
3,AP_INVOICES_INTERFACE.VENDOR_NUM,取引先コード,新旧対応表で Fusion の取引先番号へ,取引先の移行を先に完了する
4,AP_INVOICES_INTERFACE.VENDOR_SITE_CODE,支払先コード,新旧対応表で Fusion のサイトコードへ,サイト割当済みの BU のものだけ
5,AP_INVOICES_INTERFACE.INVOICE_NUM,伝票番号,そのまま。同一取引先内の重複は事前に検出して付け替え,重複は取込でリジェクト
6,AP_INVOICES_INTERFACE.INVOICE_DATE,伝票日付,YYYY/MM/DD に整形,
7,AP_INVOICES_INTERFACE.INVOICE_AMOUNT,伝票金額,通貨の小数桁に合わせる（円は 0 桁）,明細の合計と一致させる
8,AP_INVOICES_INTERFACE.GL_DATE,計上日,基準日以前の期間の日付,期間がオープンまたは将来入力可であること
9,AP_INVOICE_LINES_INTERFACE.DIST_CODE_CONCATENATED,旧勘定・部門,COA 対応表で新 COA の組合せへ,1 対多の勘定は按分ルールを別紙で定義

照合シート

件数と金額を同じ形式で並べます。差異は「抽出 − 除外 − 本表 − 未解決リジェクト」です（値は架空）。

対象,単位,抽出,除外,CSV,本表,未解決リジェクト,差異,判定
AP 請求書（件数）,JP01 営業単位,812,12,800,800,0,0,OK
AP 請求書（金額 JPY）,JP01 営業単位,265400000,3100000,262300000,262300000,0,0,OK
GL 期首残高（借方合計）,JP プライマリ元帳,1840000000,0,1840000000,1840000000,0,0,OK
GL 期首残高（貸方合計）,JP プライマリ元帳,1840000000,0,1840000000,1840000000,0,0,OK

補助簿と GL の残高を SQL で比べる

AP の未払残高（補助簿側）と、GL の買掛金勘定の残高（GL 側）を出す例です。BI Publisher のデータモデルで実行します。テーブルと列は BI Publisher の SQL 実践の例に合わせています。実行前に、列の意味を Tables and Views で確認してください。

SELECT aia.org_id,
       aia.invoice_currency_code,
       COUNT(*)                  AS invoice_count,
       SUM(sch.amount_remaining) AS open_amount
FROM   ap_invoices_all aia
       JOIN (SELECT apsa.invoice_id,
                    SUM(apsa.amount_remaining) AS amount_remaining
             FROM   ap_payment_schedules_all apsa
             GROUP  BY apsa.invoice_id) sch
         ON sch.invoice_id = aia.invoice_id
WHERE  aia.org_id            = :P_BU_ID
AND    aia.cancelled_date    IS NULL
AND    aia.gl_date          <= :P_CUTOFF_DATE   -- 基準日まで
AND    sch.amount_remaining <> 0                -- 未払（一部払いの残・クレジットメモを含む）
GROUP  BY aia.org_id, aia.invoice_currency_code
ORDER  BY aia.invoice_currency_code

SELECT SUM(NVL(gb.begin_balance_cr, 0) - NVL(gb.begin_balance_dr, 0)
         + NVL(gb.period_net_cr, 0)    - NVL(gb.period_net_dr, 0)) AS ap_balance
FROM   gl_balances gb
       JOIN gl_ledgers           gl  ON gl.ledger_id            = gb.ledger_id
       JOIN gl_code_combinations gcc ON gcc.code_combination_id = gb.code_combination_id
WHERE  gb.ledger_id     = :P_LEDGER_ID
AND    gb.period_name   = :P_PERIOD_NAME
AND    gb.actual_flag   = 'A'
AND    gb.currency_code = gl.currency_code
AND    gcc.segment3     = :P_AP_ACCOUNT          -- 例：買掛金の勘定科目（セグメントの位置は COA の設計による）

使い方の注意です。

補助簿側は、移行の直後（支払の前）に実行します。支払や消込の後は、残額が変わります。
円建ての行どうしを比べます。外貨建ては換算後の金額で別に照合します。
買掛金は貸方残高なので、GL 側は貸方から借方を引いています。
差が出たら、Prepare Payables to General Ledger Reconciliation の照合レポートで、期間・勘定・取引の順に掘り下げます。

カットオーバー手順書（抜粋）

手順書は「誰が・いつ・何を・何を確認して次へ進むか」を 1 行にします（時刻・担当・件数は架空）。

No,予定時刻,作業,担当,前提,完了確認,所要（分）
10,T 日 20:00,旧システムの取引入力を停止,旧システム担当,Go 承認,入力画面の閉鎖を確認,15
20,T 日 20:30,最終データの抽出,旧システム担当,10 完了,抽出件数と合計を照合シートに記録,60
30,T 日 21:30,仕入先と顧客のロード・インポート,移行担当,20 完了,リジェクト 0 件,90
40,T 日 23:00,GL 期首残高のロード・インポート・転記,移行担当,30 完了,借方・貸方の合計が一致,60
50,T+1 日 00:00,AP 未払請求書のロード・インポート・検証・会計処理,移行担当,40 完了,件数・金額が一致,120
60,T+1 日 02:00,補助簿と GL の照合,経理担当,50 完了,差異 0 または承認済みの説明,60
70,T+1 日 03:00,Go/No-Go の判定,責任者,60 完了,基準を満たす,30
80,T+1 日 03:30,ユーザー開放と定期ジョブの有効化,移行担当,70 Go,ジョブが予定どおり起動,30

落とし穴とベストプラクティス

補助簿と GL の両方に同じ残高を入れ、買掛金・売掛金などの統制勘定が二重になる。
旧勘定の 1 対多の分割（按分）を後から決め、期首残高が合わなくなる。
仕入先のサイト割当や勘定組合せなど、参照先が揃う前にトランザクションを流し、大量のリジェクトを出す。
リハーサルをサンプルだけで 1 回で終え、全件の所要時間とエラー率が本番まで分からない。
本番でもやり直せると考える。本番はリフレッシュで戻せない。
移行用に変えた設定（採番・検証ルール・承認など）を、稼働前に戻し忘れる。
件数だけを照合し、金額や補助簿と GL の一致を見ない。
期間をまとめてオープンし、取込・転記・照合・クローズの順を崩す。
為替レートを基準日までに登録せず、外貨の残高が合わない。

ベストプラクティスは次のとおりです。

管理表を 1 つにする：移行対象一覧、マッピング、順序、照合シートを 1 つにまとめ、リハーサルのたびに更新します。
照合の SQL と手順を先に固定する：結果を見てから基準を決めると、合格基準が甘くなります。リハーサルの前にレビューします。
直す責任と期限を割り当てる：データの持ち主である業務部門に、クレンジングの責任と期限を決めます。
日本固有の項目を漏らさない：適格請求書の登録番号など、日本の制度に関わる項目は、持ち方を公式の日本向けドキュメントで確認し、移行対象に含めます（税）。

試験対策ポイント

実装試験では、移行は独立した大項目というより、各モジュールの中で「取込手段の選択」「依存関係」「取込エラーの対応」「残高の照合」として問われます（出題テーマの目安です）。

GL 模擬テスト：仕訳の取込（Group ID・AutoPost・期間のステータス）、Rapid Implementation
AP 模擬テスト：請求書の取込手段、AP と GL の照合（Implementing Accounts Payable Balances）
AR 模擬テスト：顧客 → 未決済の順、AutoInvoice、ロックボックス
調達模擬テスト・在庫模擬テスト：仕入先の取込順序、品目と在庫取引

覚えておくことです。

FBDI は「ロード」と「インポート（業務ごとのプロセス）」の 2 段階
順序は参照される側が先：設定 → COA・勘定組合せ → 取引先・品目 → 残高 → 未決トランザクション
仕入先は「ヘッダ → 住所 → サイト → サイト割当 → 連絡先」の順
補助簿と GL の照合には、統制勘定の財務カテゴリ（Accounts Payable／Accounts Receivable）と Prepare … Reconciliation が要る
AP の前払請求書は FBDI テンプレートで作れず、仕入先銀行口座の FBDI は作成のみ（26C・26D の公式ガイド時点）

公式ドキュメント

次の資料は、このページでは中身を確認していません。必要に応じて直接お読みください。

同じブログのシリーズにある固定資産向けの記事（High Volume Data Migration Considerations for Fixed Assets）
AP のブログが案内する Cloud Customer Connect のホワイトペーパー「Oracle Cloud ERP Data Migration Recommendations and Best Practices」
My Oracle Support（要ログイン）の Doc ID 2559114.1、Doc ID 2442750.1（Correct Import Errors Spreadsheet）、KB21351。ブログの記載から ID を引いたものです