O2C：受注から出荷・請求・入金まで
プロセスの全体像
Section titled “プロセスの全体像”OM 受注入力 → 価格 → 提出（与信・承認）→ スケジュール（GOP）→ 引当 → 出荷依頼在庫 → ピック → 出荷確認（出荷通知を OM へ）原価管理 → 出荷の原価計算OM → 請求明細の作成（Create Billing Lines）AR → AutoInvoice → 請求書 → 送付 → 収益認識原価管理 → 収益行の取込 → 売上原価の認識AR → 入金 → 消込 → 回収会計 → SLA（Create Accounting）→ GL- 受注入力・価格計算：OM で受注を作ります（外部からの取込も可）。Pricing が価格を、Fusion Tax が税を計算します
- 提出：検証、与信チェック（Receivables）、承認（設定した場合）を通ります
- スケジュール：GOP が出荷元と出荷予定日を決めます（Create Scheduling）
- 引当：在庫を予約します（Create Inventory Reservation）
- 出荷：ピックと出荷確認で在庫を払い出し、出荷通知が OM に戻ります
- 出荷の原価計算：出荷の在庫取引が原価管理で原価計算されます
- 請求明細の作成：OM が請求明細を作り、AR に渡します（Create Billing Lines）
- 請求書の作成：Import AutoInvoice が請求書を作り、結果が OM に戻ります
- 送付と収益認識：請求書を送付し、収益スケジュール規則に従って Recognize Revenue を実行します
- 売上原価の認識：認識済みの収益の割合に応じて、売上原価を認識します
- 入金と消込：入金を作り、請求書に消し込みます
- 回収：未回収の債権を督促・回収戦略で管理します
- GL 転記：AR と原価管理の補助元帳仕訳を GL へ転送し、転記します
| ステップ | 担当モジュール | 主な画面・API・ジョブ | 作られるデータ |
|---|---|---|---|
| 1〜2 | OM、Pricing、Receivables（与信） | Create Order、FBDI の Import Sales Orders、REST の salesOrdersForOrderHub、Credit Reviews | DOO_HEADERS_ALL → DOO_LINES_ALL → DOO_FULFILL_LINES_ALL、与信のケースフォルダ |
| 3 | GOP | Create Scheduling、Collect Planning Data | 出荷元（倉庫）、出荷予定日 |
| 4 | 在庫 | Create Inventory Reservation | INV_RESERVATIONS（DEMAND_SOURCE_TYPE_ID = 2、SOURCE_FULFILLMENT_LINE_ID） |
| 5 | 在庫（出荷） | Create Shipping、Create Pick Wave、Confirm Pick Slip、Ship Confirm | 出荷、ピック・スリップ、在庫の払出取引、出荷通知 |
| 6 | 原価管理 | Create Cost Accounting Distributions | 出荷の原価配分 |
| 7〜8 | OM、AR | Create Billing Lines、Import AutoInvoice、Notify Feeder System of Receivables Transactions | RA_INTERFACE_LINES_ALL → RA_CUSTOMER_TRX_ALL、RA_CUSTOMER_TRX_LINES_ALL、RA_CUST_TRX_LINE_GL_DIST_ALL、AR_PAYMENT_SCHEDULES_ALL |
| 9 | AR | Print Receivables Transactions、Recognize Revenue | 収益の配分（ACCOUNT_CLASS = REV） |
| 10 | AR、原価管理 | Import Revenue Lines、Create Cost Accounting Distributions（COGS 認識） | 収益行、売上原価の配分、認識割合 |
| 11〜12 | AR、CM | 手入力、Process Receipts Through Lockbox、Create Automatic Receipts、AutoApply／AutoCash、督促 | AR_CASH_RECEIPTS_ALL、AR_RECEIVABLE_APPLICATIONS_ALL |
| 13 | SLA、GL | Create Accounting（Transfer to General Ledger）、GL での転記 | XLA_EVENTS → XLA_AE_HEADERS → XLA_AE_LINES → GL_IMPORT_REFERENCES → GL_JE_LINES |
モジュール間の連携ポイント
Section titled “モジュール間の連携ポイント”与信（OM → AR の Credit Management）
Section titled “与信（OM → AR の Credit Management）”- トリガー：受注の提出。承認の直前と、請求先顧客など支払に関わる変更でも再実行されます
- 渡るデータ：与信チェックの依頼。結果は承認番号・有効期限・承認額です。利用可能額は「与信限度額 − 未決済残高 − 未消化の与信承認額」で計算します
- 仕組み：パラメータ Activate Credit Check on Order Submit と Credit Check Failure at Order Submit。失敗すると、受注全体が Credit Review Pending になるか、失敗した明細だけに保留が付きます。与信担当が Credit Reviews（ケースフォルダ）で承認・却下します
- 会計：なし。未決済残高は AR の残高から計算されるため、入金の消込が遅れると与信枠に影響します
約束と引当（OM → GOP・在庫）
Section titled “約束と引当（OM → GOP・在庫）”- トリガー：オーケストレーションのステップ Create Scheduling と Create Inventory Reservation
- 渡るデータ：要求日・倉庫・品目・顧客・出荷方法 → 出荷元・出荷予定日。続いて引当（予約）
- 仕組み：GOP は割当セット → ソーシングルール → ATP ルールの順に評価します。Supply Chain Search は収集済みの計画データが前提なので、Collect Planning Data を定期実行し、品目の変更後は再収集します。引当は INV_RESERVATIONS に記録され、品目の Reservable と引当可能数量で決まります
- 会計：なし。引当は数量の予約で、在庫の移動は出荷確認まで起きません
出荷（在庫 → OM、在庫 → 原価管理）
Section titled “出荷（在庫 → OM、在庫 → 原価管理）”- トリガー：出荷確認（Ship Confirm）
- 渡るデータ：出荷数量・ロット・シリアルと、出荷通知（shipment advice）。在庫の払出取引は原価管理へ
- 仕組み：Create Shipping → ピック・ウェーブ → ピック確認 → 出荷確認。出荷通知で Wait for Shipment が完了し、請求のステップに進みます。出荷確認には、出荷の例外の解決・ロットとシリアルの記録・全明細のピック済みが必要です
- 会計：出荷の在庫取引は、原価管理の原価計算と SLA を経て仕訳になります（OM と在庫管理は仕訳を作りません）
出荷の原価計算と売上原価の認識（在庫・AR → 原価管理）
Section titled “出荷の原価計算と売上原価の認識（在庫・AR → 原価管理）”- トリガー：出荷の在庫取引の完了。売上原価は、AR または Revenue Management での収益認識
- 渡るデータ：出荷の原価。続いて、最終会計済みの収益行
- 仕組み：Create Cost Accounting Distributions が出荷の原価を計算します。売上原価の認識では、BU ごとに Import Revenue Lines（パラメータは、ワーカー数・取込基準日・開始日）を実行し、続けて Create Cost Accounting Distributions を COGS 認識のプロセッサ付きで実行します。認識割合は「認識済みの収益 ÷ 収益の合計」で、収益行を通じて出荷明細と対応づけます
- 会計：売上原価の取引日は、収益行の会計日です。その期間がクローズ済みなら、次のオープン期間に認識されます。確認は Review Cost Accounting Distributions（認識割合・参照タイプ・参照番号・原価日）と Analyze Product Gross Margins で行います
| 受注の種類 | 売上原価の認識 |
|---|---|
| 出荷のみ（ship-only） | 出荷時に 100%。プロファイル Use Order Line Close Date for Cost of Goods Sold Recognition で、受注明細のクローズ日基準にもできます |
| 出荷と請求（ship-and-bill） | 照合した請求書の収益の認識割合に応じて |
| 請求のみ（bill-only） | 出荷がないので売上原価なし。収益は Analyze Product Gross Margins で確認 |
| 社内ドロップシップ | 顧客側の BU で Trade Sales Issue（公式の説明） |
請求と収益認識（OM → AR）
Section titled “請求と収益認識（OM → AR）”- トリガー：出荷確認後の Create Billing Lines（ステップ 500）。完了は Wait for Billing（ステップ 600）
- 渡るデータ：請求明細。受注明細は取引タイプ Invoice、返品明細は Credit Memo です。取引フレックスフィールドに受注番号・明細が入り、INTERFACE_LINE_ATTRIBUTE5 がフルフィルメント明細 ID です
- 仕組み：RA_INTERFACE_LINES_ALL → Import AutoInvoice（検証 → グルーピング → 転送）→ Notify Feeder System of Receivables Transactions が結果を OM に返します。拒否された明細は Manage AutoInvoice Lines で直し、Save and Run AutoInvoice で再実行します
- 会計：税は Fusion Tax、既定の勘定は AutoAccounting が決めます。収益は請求規則（In Advance／In Arrears）、収益スケジュール規則、収益の条件で認識時点が変わります
入金と消込（AR → CM・Payments）
Section titled “入金と消込（AR → CM・Payments）”- トリガー：入金の作成（手入力、ロックボックス、自動入金）
- 渡るデータ：入金と、請求書・デビットメモ・チャージバックへの消込。未消込・前受・未確認の入金も残ります
- 仕組み：Process Receipts Through Lockbox（取込 → 検証 → 転記）、Create Automatic Receipts と Create Automatic Remittances、AutoApply（AutoMatch）→ AutoCash → 適用例外ルール。消込方法が By Matching の入金は、CM の銀行明細照合で消込（Cleared）になります
- 会計：入金と消込は別の会計イベントです。AR → GL の照合は Prepare Receivables to General Ledger Reconciliation で行います
返品（OM → 受入 → AR・原価管理）
Section titled “返品（OM → 受入 → AR・原価管理）”- トリガー：返品オーダー（RMA）。明細に ReturnOrderGenericProcess が割り当たります
- 渡るデータ：返品の受入（RMA 番号で受入通知）と、クレジットメモの請求明細
- 仕組み：受入 → 検査 → 格納。受入が OM に伝わると、返品明細は Awaiting Receiving から Awaiting Billing に進み、Import AutoInvoice でクレジットメモ（取引タイプ Credit Memo 固定）ができます
- 会計：売上の取消は AR のクレジットメモです。在庫の戻しと売上原価の取消は、受入と原価管理で処理されます。返品の原価は、原価プロファイルの設定で決まります。元の受注に紐づく返品（Referenced RMA）は元の出荷の実際原価、紐づかない返品（Unreferenced RMA Receipt）は既存の品目原価か RMA 受注の価格を選びます（粗利分析と原価の会計連携）
ドロップシップとバック・ツー・バック（OM → 調達・SCO）
Section titled “ドロップシップとバック・ツー・バック（OM → 調達・SCO）”- ドロップシップ：GOP がソーシングルールで仕入先を選び、Supply Chain Financial Orchestration から購買依頼組織を取得して Procurement に購買依頼を送ります（パラメータ Preparer for Procurement）。仕入先が顧客へ直送し、Supplier Portal で ASN を登録すると、受入で論理的な受入が作られます。Financial Orchestration が財務フローを実行し、原価管理が受入会計と原価計算を行い、OM は ASN を出荷確認として扱って AR が顧客に請求します
- バック・ツー・バック：GOP が受注に供給を予約し、Supply Chain Orchestration が供給オーダー（購買・製造・移動）を作ります。供給は出荷まで受注に引当てられ、INV_RESERVATIONS の BACK_TO_BACK_FLAG で区別できます
- 会計：購買側の受入会計・原価計算と、販売側の AR 請求の両方が動きます。会社間の財務フローの仕訳は、設定により変わります（要確認）
シナリオ A：出荷のみ、入金まで
Section titled “シナリオ A：出荷のみ、入金まで”販売 100,000 円（税抜）、原価 60,000 円、消費税 10% の例です。
| 時点 | 補助元帳 | 借方 | 貸方 |
|---|---|---|---|
| 出荷確認 | 原価管理 | 売上原価 60,000 | 在庫 60,000 |
| 請求書の完了 | Receivables | 売掛金 110,000 | 売上 100,000、仮受消費税 10,000 |
| 入金の作成 | Receivables | 現金（入金方法の勘定） 110,000 | 未消込入金 110,000 |
| 請求書への消込 | Receivables | 未消込入金 110,000 | 売掛金 110,000 |
振込手数料を差し引いた入金は、適用例外ルールの修正（Adjustment）で、差額を手数料などの活動勘定に計上して売掛金を消し込みます。
シナリオ B：収益を繰り延べる出荷・請求
Section titled “シナリオ B：収益を繰り延べる出荷・請求”検収条件付きなど、収益の認識を後にずらす場合です。
| 時点 | 補助元帳 | 借方 | 貸方 |
|---|---|---|---|
| 出荷確認 | 原価管理 | 繰延売上原価 60,000 | 在庫 60,000 |
| 請求書の完了 | Receivables | 売掛金 110,000 | 前受収益 100,000、仮受消費税 10,000 |
| 収益の認識（Recognize Revenue） | Receivables | 前受収益 100,000 | 売上 100,000 |
| 売上原価の認識（収益の 100% を認識した場合） | 原価管理 | 売上原価 60,000 | 繰延売上原価 60,000 |
収益の 50% だけ認識した場合は、売上原価も 50%（30,000）だけ認識します。上の「繰延売上原価」は、売上原価の認識を後ろにずらす構成の典型例として置いた勘定で、Fusion の標準の勘定名・勘定導出は公式ドキュメントで確認できていません（要確認。実装では SLA の会計方法のルールと勘定の設計で決めます）。認識の日付は、収益明細の会計日（出荷のみの受注は出荷日）で、クローズ済みの期間なら次の未クローズ期間に計上されます（26B）。
シナリオ C：返品とクレジットメモ
Section titled “シナリオ C：返品とクレジットメモ”| 時点 | 補助元帳 | 借方 | 貸方 |
|---|---|---|---|
| クレジットメモの完了 | Receivables | 売上 100,000、仮受消費税 10,000 | 売掛金 110,000 |
| 返品の受入 | 受入・原価管理 | 在庫の戻し | 売上原価の取消（金額は原価プロファイルの設定、勘定は要確認） |
会計イベントと GL への転送
Section titled “会計イベントと GL への転送”| 補助元帳 | 主な会計イベント | 作られるきっかけ |
|---|---|---|
| Receivables | 取引（請求書・クレジットメモ）、入金、修正がそれぞれ別のエンティティ | Import AutoInvoice、入金・消込、修正の承認 |
| 原価管理 | 出荷・返品の原価、売上原価の認識 | Create Cost Accounting Distributions |
| 受入会計 | ドロップシップの受入、返品の受入 | Create Receipt Accounting Distributions |
いずれも Create Accounting で補助元帳仕訳を作り、GL へ転送します。月末は、売上原価の認識が収益に連動するため、Receivables → 原価管理 → GL の順にクローズします（在庫と原価・会計、AR の期間締め）。
組織・マスタの前提
Section titled “組織・マスタの前提”| 前提 | 設定する場所 | 欠けたときの症状 |
|---|---|---|
| 受注の BU、販売利益センター BU（使う場合） | エンタープライズ構造、OM パラメータ | 受注の BU が選べない。税・原価・AR の BU が想定と違う |
| 出荷元の在庫組織、品目検証組織 | 在庫組織、Item Validation Organization | 品目が検索できない。子組織の Reservable が読まれず引当されない |
| 品目属性（Customer Ordered、Customer Orders Enabled、Reservable、Invoice Enabled） | Product Management | 受注に出せない、引当されない、請求されない |
| GOP のデータ収集、ATP ルール、ソーシングルール | GOP | 輸送日数が 0 日になる。make の供給オーダーが作られない |
| オーケストレーション・プロセスと割当ルール | OM | 明細が進まない。請求ステップがない |
| 顧客（パーティ、アカウント、請求先・出荷先サイト）と参照データ・セット | AR の顧客、TCA | サイトが使えない。送付先住所が決まらず AutoInvoice が拒否する |
| 与信プロファイル・与信限度（単一通貨・顧客アカウント単位） | Credit Management | 与信チェックが通らない。通貨違いで計算が合わない |
| 取引タイプ、取引ソース、支払条件、AutoAccounting | AR の設定 | AutoInvoice の拒否、勘定が導出できない |
| 原価組織・原価帳簿・原価方法、COGS 認識の設定 | 原価管理 | 出荷の原価が計算されない。売上原価が認識されない |
| 会計期間（OM・在庫・AR・原価・GL） | 各カレンダー | 出荷確認や会計がエラーになるか、次の期間に計上される |
実装・テストのポイント
Section titled “実装・テストのポイント”よくある不整合と原因
Section titled “よくある不整合と原因”| 症状 | 主な原因 | 確認先 |
|---|---|---|
| 明細が Awaiting Billing のまま止まる | Import AutoInvoice の拒否、未実行。Notify Feeder System of Receivables Transactions の未実行 | RA_INTERFACE_ERRORS_ALL、Manage AutoInvoice Lines。通知は再実行する |
| 引当されない | 品目の Reservable、資材ステータス、引当可能数量、品目検証組織 | INV_RESERVATIONS を LEFT JOIN で調べる（引当・出荷・返品） |
| 与信で止まる | 与信限度、通貨、未決済残高、未消化の承認額 | Credit Reviews、ケースフォルダ |
| 受注と請求書の税額が違う | 受注の税と請求書の税は別に計算される | 公式トピック Make Sales Order Tax and Invoice Tax the Same、税の設定 |
| 出荷料金が請求書で課税されない | 既定では、出荷料金は請求書ヘッダーの運賃にまとめられ、課税されない | Integration Algorithm for Sales Order Charges、サービス・マッピング |
| 出荷確認できない | 出荷の例外、ロット・シリアルの未記録、未ピックの明細 | 出荷の例外の一覧 |
| 売上原価が認識されない | 収益が未認識、Import Revenue Lines 未実行、出荷の原価が未処理 | Review Cost Accounting Distributions、Analyze Product Gross Margins |
| 売上原価の期間が想定と違う | 収益行の会計日が基準。期間がクローズ済みなら次の期間 | 収益行の会計日、原価と AR の期間 |
| 未消込入金が残る | 顧客・請求書を特定できない、AutoApply のしきい値 | 未確認・未消込の入金の一覧 |
| 請求書は会計済みだが GL にない | 転送なし、または GL で未転記 | SLA のステータス列（SLA の追跡） |
| 照合 | 左 | 右 |
|---|---|---|
| 出荷と請求 | 出荷確認済みのフルフィルメント明細の数量・金額 | AR の請求書明細（INTERFACE_LINE_ATTRIBUTE5 で対応） |
| 受注と請求の金額・税 | 受注の合計と税額 | 請求書の合計と税額 |
| 売掛金 | Receivables to General Ledger Reconciliation（Prepare Receivables to General Ledger Reconciliation、財務カテゴリ Accounts Receivable） | GL の売掛金 |
| 売上原価と収益 | 売上原価の認識割合 | 収益の認識割合 |
| 在庫の払出 | 出荷確認の在庫取引 | 原価管理の原価配分（在庫と原価・会計） |
結合テストのシナリオ
Section titled “結合テストのシナリオ”- 標準（出荷基準）：受注 → 与信 → 引当 → 出荷 → 請求 → 入金 → GL。各段の件数・金額・ステータスを確認する
- 部分出荷とバックオーダー：フルフィルメント明細が分割され、請求も分割される
- 与信失敗：2 つのパラメータの設定で、受注全体が止まる場合と明細だけ止まる場合を確認し、承認・却下まで通す
- 引当失敗：在庫なし、資材ステータス、再引当
- 変更・取消：出荷前・出荷後・請求後の数量変更と、処理制約の効き方
- 返品：RMA → 受入 → クレジットメモ → 在庫の戻しと原価（元の受注に紐づく返品と、紐づかない返品の両方）
- 収益の繰延：In Advance、In Arrears、収益の条件と、売上原価の連動
- 税：受注の税額と請求書の税額（端数処理、インボイス制度の記載事項を含む）
- 入金：ロックボックス（一致と不一致）、手数料の差引、過入金と返金
- ドロップシップ・バック・ツー・バック：購買・受入・請求までの一連
- 期間またぎ：出荷月・請求月・収益認識月が異なる取引と、締めの順序
追跡 SQL
Section titled “追跡 SQL”BIP のデータモデルで、受注番号などで 1 件に絞って実行します。受注から引当は 引当・出荷・返品、止まった受注は オーケストレーション、SLA から GL は SLA の追跡 の SQL を使います。
SELECT h.source_order_number, l.display_line_number, f.fulfill_line_number, f.status_code, trx.trx_number, trl.line_number AS trx_line_number, trl.extended_amount, ps.amount_due_original, ps.amount_due_remainingFROM doo_headers_all h JOIN doo_lines_all l ON l.header_id = h.header_id JOIN doo_fulfill_lines_all f ON f.line_id = l.line_id LEFT JOIN ra_customer_trx_lines_all trl ON trl.interface_line_attribute5 = TO_CHAR(f.fulfill_line_id) LEFT JOIN ra_customer_trx_all trx ON trx.customer_trx_id = trl.customer_trx_id LEFT JOIN ar_payment_schedules_all ps ON ps.customer_trx_id = trx.customer_trx_idWHERE h.submitted_flag = 'Y'AND h.source_order_number = :P_ORDER_NUMBERORDER BY l.display_line_number, f.fulfill_line_number, trl.line_number-- 他のソースの請求明細と区別するため、INTERFACE_LINE_CONTEXT の値も環境で確認する-- 分割払の請求書は、債権の残高の行が複数になるSELECT ra.receivable_application_id, ra.status, -- 消込・未消込などの状態。値は環境で確認する ra.amount_applied, cr.receipt_number, cr.amount AS receipt_amountFROM ar_receivable_applications_all ra LEFT JOIN ar_cash_receipts_all cr ON cr.cash_receipt_id = ra.cash_receipt_idWHERE ra.applied_customer_trx_id = :P_CUSTOMER_TRX_IDORDER BY ra.receivable_application_id請求書の明細と配分を一緒に集計すると、金額が重複します。明細・配分・消込は別のクエリで確かめます。
標準とアドオンの境界
Section titled “標準とアドオンの境界”| 要件 | 標準の手段 | アドオンにする場合 |
|---|---|---|
| 外部の受注の取込（EC・EDI） | FBDI の Import Sales Orders、REST の salesOrdersForOrderHub、B2B メッセージング | OIC で変換・連携を作る |
| 受注・請求への独自項目 | 拡張フレックスフィールド、サービス・マッピング | 統合アルゴリズム、Order Management Extensions（Groovy） |
| 与信の判定 | Credit Management の与信プロファイル・限度・スコアリング | 標準で足りない場合に限り、拡張と OIC で補う（要確認） |
| 出荷作業の外部化 | 外部フルフィルメント連携（コネクタ・ルーティング） | 外部の WMS 側の開発 |
| 請求書の様式・送付 | BI Publisher のテンプレート、Print Receivables Transactions、メール・XML | 独自帳票は BIP で作る |
| 月末締めの請求 | 残高繰越請求（Create Balance Forward Bill） | 原則不要 |
| 売上原価の認識時点 | COGS 認識、プロファイル Use Order Line Close Date for Cost of Goods Sold Recognition | ロジックは標準。変えられるのは設定と勘定ルール |
| 銀行の入金データ | ロックボックス、ORA_ZENGIN_LOCKBOX | 銀行固有の形式は伝送フォーマットで追加する |
DB に直接書くアドオンは作れません。外部処理が必要なら REST・FBDI・ビジネスイベントを経由します（標準機能とアドオンの考え方）。
試験対策ポイント
Section titled “試験対策ポイント”- 対応する試験は、受注（1Z0-1077-26）、AR（1Z0-1056-26）、在庫（1Z0-1073-26）、原価管理（1Z0-1074-26）です。受注、AR、在庫 の模擬テストで確認してください。ほかの試験は 模擬テスト一覧 にあります。
- 判断ポイントの例です。
- ShipOrderGenericProcess は、スケジュール・引当・出荷依頼・出荷待ち・請求明細・請求待ちの 6 ステップ（100〜600）
- 請求連携のジョブは Import AutoInvoice と Notify Feeder System of Receivables Transactions。返品の請求は Credit Memo 固定
- 与信チェックの 2 つのパラメータと、利用可能額の計算式
- 引当は INV_RESERVATIONS で、受注の DEMAND_SOURCE_TYPE_ID は 2
- AutoInvoice は検証 → グルーピング → 転送の 3 段階。インタフェース表は 5 つ
- 売上原価の認識は、収益の認識割合に連動する。Import Revenue Lines の後に Create Cost Accounting Distributions
- クローズは Receivables → Cost Management → General Ledger の順
- 入金の消込は AutoApply → AutoCash → 適用例外ルールセット。入金区分の消込方法は 3 種類
公式ドキュメント
Section titled “公式ドキュメント”- How Order-to-Cash Works in Order Management（26C）
- Overview of Setting Up Credit Check（26C）
- Get Things Moving Again in Oracle Receivables（26C）
- How the Reserve, Pick, and Confirm Shipments Process Works（26C）
- How AutoInvoice Processes Data During Import（26C）
- Cost of Goods Sold Recognition（26B）
- Create Cost Accounting Distributions（26C）
- Oracle Fusion Revenue Management Integration（26B）
- Use SQL to Query Order Management Data（26C）
- Tables and Views for Financials（26D）
本サイトは学習目的で個人が作成した非公式の教材であり、Oracle Corporation およびその関連会社とは関係ありません。内容の正確性は保証しません。最新の仕様・試験範囲は必ず公式ドキュメントと Oracle University の情報で確認してください。
模擬テストの問題は公開されている出題範囲（Exam Topics）と公式ドキュメントをもとに独自に作成したもので、実際の試験問題ではありません。
Oracle、Java、MySQL は Oracle Corporation およびその子会社、関連会社の米国およびその他の国における登録商標です。その他の製品名・会社名は各社の商標です。
© 2026 Fusion ERP 実装ラボ