コンテンツにスキップ

共通マスタデータの設計(取引先・品目・組織・COA)

マスタ 作成・保守する場所 参照するモジュール 変えにくい点
仕入先 調達(Suppliers 作業領域) 調達、AP、支払、会社間 仕入先番号の採番、サイト割当の設計
顧客 AR(Customers)、受注 AR、受注、回収、会社間 アカウントとサイト(BU 固有)の分け方
品目 製品管理(品目マスタ組織) 調達、在庫、受注、原価、製造 ロット・シリアル管理、基本単位
組織 設定と保守(FSM、Rapid Implementation) すべて 元帳の 4 要素、BSV と法的エンティティの対応、利益センター BU
COA・階層 GL 全仕訳、財務レポート、EPM セグメント構成、利益剰余金勘定
カレンダー・通貨 GL・共通設定 GL、AP、AR、FA、PPM、在庫 期間の定義、レートタイプの運用
従業員・ユーザー HCM、Security Console 承認、経費、調達、PPM 上司階層、ロール付与の方式
銀行・口座 Cash Management、Payments AP の支払、AR の入金、経費 口座の用途と利用 BU
地理・事業所 → COA・カレンダー・通貨 → 法的エンティティ → 元帳 → BU → 参照データセット
→ 在庫組織・調達 BU など → 従業員 → 取引先(仕入先・顧客)・銀行口座 → 品目 → 残高・未決取引

取引先(仕入先・顧客)と TCA のパーティ

Section titled “取引先(仕入先・顧客)と TCA のパーティ”

仕入先(POZ_SUPPLIERS)も顧客アカウント(HZ_CUST_ACCOUNTS)も、PARTY_ID で HZ_PARTIES を参照します。名称はパーティ側にあります(POZ_SUPPLIERS_V が仕入先名にパーティ名を返すのはこのためです)。表の関係は 主要テーブルマップ にまとめています。

項目 仕入先 顧客
単位 全社で 1 件のヘッダ。住所は仕入先ごと、サイトは調達 BU ごと パーティ → 顧客アカウント → アカウントサイト(BU 固有)→ サイト用途(Bill-To など)
取引条件 サイトの支払条件など 顧客プロファイル(プロファイルクラスの既定値)
使える BU サイト割当で決まる アカウントサイトの BU で決まる
状態 Prospective/Spend Authorized アカウント・サイトの有効・無効
  • 名寄せの原則は「1 法人 1 パーティ」です。移行前に名寄せし、登録は重複チェックを通します(仕入先管理)。
  • テーブルの構造上は、同じパーティを仕入先と顧客アカウントの両方が参照できます。同一法人が仕入先と顧客を兼ねる場合の登録画面の挙動(既存パーティの再利用、重複チェックの対象)は、本章では確認できていません。公式ドキュメントと実機で確認し、移行では FBDI の入力でパーティの指定ができるかを先に検証してください。
  • 会社間取引では、法的エンティティごとに内部顧客(タイプは Internal)と仕入先を 1 つずつ割り当てます(会社間取引)。
  • 税登録番号など税務情報の持たせ方(日本のインボイス制度を含む)は 税 で確認します。

同じパーティを共有している取引先は、次の SQL で洗い出せます(列は Tables and Views で確認してから使います)。

仕入先と顧客アカウントの両方を持つパーティ(例)
SELECT hp.party_number,
hp.party_name,
s.segment1 AS supplier_number,
hca.account_number AS customer_account
FROM hz_parties hp
JOIN poz_suppliers s ON s.party_id = hp.party_id
JOIN hz_cust_accounts hca ON hca.party_id = hp.party_id
ORDER BY hp.party_name
  • 品目は品目マスタ組織で一度だけ定義し、在庫組織・品目組織へ割り当てます。マスタ組織は全社で 1 つにし、品目を取引する組織とは分けるのが推奨です(在庫組織と品目)。
  • 属性ごとに、マスタ組織で管理するか組織ごとに管理するかを決めます。ロット・シリアル管理や取引可否は、取引の発生後に変更できないものが多く、移行前に確定します。
  • 品目クラス(階層)とテンプレートで属性の既定値を配ります。品目コード体系、カテゴリ、基本単位と換算(単位クラス)を最初に決めます。
  • 調達の明細、受注、原価、製造がこの品目を参照します。品目の新規申請の統制には Product Hub を使えます(品目マスタ管理)。

組織(法的エンティティ・BU・在庫組織など)

Section titled “組織(法的エンティティ・BU・在庫組織など)”
  • 法的エンティティは 1 つの BSV に割り当て、BU は 1 つのプライマリ元帳と既定の法的エンティティを持ちます(エンタープライズ構造)。
  • 在庫組織は管理 BU・法的エンティティ・利益センター BU に紐づきます。原価組織が束ねられるのは、同じ法的エンティティ・利益センター BU・品目マスタ組織の在庫組織だけです。
  • 参照データセット(支払条件・取引タイプなど)の共有方針は、マスタを移行する前に決めます。
  • 稼働後に動かしにくいのは、元帳の COA・カレンダー・通貨、利益剰余金勘定、処理中の取引がある在庫組織の利益センター BU です。
  • COA のセグメント値は独立値セットで持ち、階層(ツリー)はバージョンと有効日で管理します。階層を変えたら残高キューブへ公開します(COA・元帳)。
  • 勘定や部門を追加するときの流れ(申請 → 承認 → 値の登録 → 階層への配置 → 公開 → EPM への反映)を、マスタの運用として決めます。
  • 値セットの Translatable は後から変更できません。日本語と英語を併用する可能性があれば最初に選びます(フレックスフィールド)。
  • 移行は FBDI の Import Segment Values and Hierarchies と Import Account Combinations を使います。
  • 会計カレンダーは元帳の期間を決め、AP・AR・FA・在庫などの会計期間は元帳のカレンダーに沿って各モジュールで開閉します。親会社と子会社でカレンダーが異なると、元帳セット・データ・アクセス・セット・Close Monitor を共通化できません。
  • 在庫組織の施設スケジュール(稼働日)や、固定資産の償却カレンダー・按分カレンダーは別の設定です。会計カレンダーとの対応を設計時に確認します。
  • 通貨とレートタイプ(Spot・Corporate・User・Fixed)は、会計方針として先に決めます。日次レートはスプレッドシート(ADFdi)、FBDI、Web サービスで取り込めます。取込が遅れると外貨取引の会計処理が止まるため、監視と代替手順(手入力)を決めておきます(参照タイプ・プロファイル・共通マスタ)。
  • ユーザーは人レコードと一緒に作るのが基本です(Manage Users、HCM Data Loader、Hire an Employee)。承認者の決定は HCM の上司・ジョブ・職位に、調達エージェントの登録や購買依頼者の BU は人レコードに依存します(セキュリティの基本、承認ワークフロー)。
  • HCM を導入しない場合も、人レコードを作るか、上司をどう持つかを先に決めます。PPM のタイムカードや経費も、人(担当者)のデータが前提です。
  • 銀行・支店・口座は、CM と Payments で管理します。支払元の内部口座と、仕入先・顧客・従業員の外部口座は別の管理です(設定項目は 現金管理 で確認)。
  • 日本の銀行・支店は、全銀ファイルを Upload Banks, Branches, and Accounts で取り込めます。銀行コードは 4 桁、支店番号は 3 桁、預金種目が必須です(AP の全体像)。
  • 仕入先の銀行口座の FBDI は作成のみで、更新には使えません。口座の変更は不正支払の典型的なリスクなので、変更の承認と履歴を統制の中心に置きます。

登録責任(データ・オーナー)と統制

Section titled “登録責任(データ・オーナー)と統制”
マスタ データ・オーナー(例) 統制のポイント 主な作成手段
仕入先 調達部門 登録依頼と承認、重複チェック、変更依頼の承認。銀行口座は経理が確認 画面、FBDI、REST
顧客 営業管理・債権管理 与信・請求条件は経理が承認 画面、FBDI(Import Trading Community Data in Bulk)
品目 製品管理・SCM 新品目要求の承認、属性管理レベルの固定 画面、FBDI(Item Import)
COA・階層 経理 申請・承認後に登録、公開、EPM への配信 画面、FBDI、EDM
組織構造 経理・IT 変更管理、構成パッケージで環境間を同期 FSM、Rapid Implementation
従業員・ユーザー 人事・IT 人事起点で作成、ロール付与は IT セキュリティ HCM Data Loader、Manage Users
銀行・口座 財務 登録者と承認者を分離、変更の監査 画面、全銀ファイル
通貨・レート 経理・財務 レートの取込と承認、取込の監視 スプレッドシート、FBDI、Web サービス

オーナーは「最新の事実を知っている人」と「責任を負う人」で決めます。登録者と承認者の分離、変更履歴(監査)、納税者番号のマスキングなどのアクセス制限、BU 単位のデータセキュリティを組み合わせます(セキュリティ設計)。

順 対象 前提 主な手段
0 設定(企業構造、COA の構造、カレンダー、通貨、参照データセット、税、セキュリティ) なし FSM、Rapid Implementation、構成パッケージ
1 COA の値・階層、勘定組合せ、日次レート、銀行・支店・内部銀行口座 0 FBDI、全銀ファイル、スプレッドシート
2 従業員、仕入先(ヘッダ → 住所 → サイト → サイト割当 → 連絡先)、銀行口座、顧客 0、1 HCM Data Loader、FBDI
3 品目と組織への割当 0(在庫組織など) FBDI(Item Import)
4 残高(GL 期首、在庫、固定資産) 1、3 FBDI
5 未決の取引(AP 未払、AR 未決済、未完了の PO・受注) 1、2、3 FBDI

詳細は 移行設計 と FSM を参照してください。構成パッケージは、移行先にだけあるレコードを削除せず、ユーザー・レベルのプロファイル値を移さない点に注意します。

パターン 正の置き場 連携の手段
A. Fusion を正にする Fusion ビジネスイベント、BIP の定期出力、BICC、REST で外部へ配信(ビジネスイベント)
B. 外部の MDM を正にする 外部 MDM FBDI・REST・OIC で Fusion へ登録。Fusion 側の画面登録は禁止または限定する
C. COA などのディメンションを EDM で管理 EDM 変更要求・承認を経て、Fusion GL と EPM の各アプリへ配信(EDM)
  • 正を 1 つにし、更新の方向を一方向にします。双方向にすると、採番とキーの衝突、更新の競合が起きます。
  • 外部システムのキーを Fusion のどの項目に保持するかを決めます。ビジネスイベントは重複・欠落・順不同が起こり得るため、冪等な受信と定期の突合が必要です。
  • 外部 MDM が採番する場合も、Fusion の採番方式(仕入先番号など)との関係を先に決めます。
  • 仕入先の変更を外部へ同期する専用サービス(Supplier Outbound Synchronization Service など)の提供有無と仕様は、本章では確認できていません。リリースにより異なるため、公式ドキュメントで確認してください。
  • 移行リハーサル:件数・キー重複・必須項目の欠けを、リハーサルごとに確認します。サイト割当のない仕入先サイト(仕入先管理 の SQL)や、重複したパーティを SQL で洗い出します。
  • 権限テスト:登録者と承認者の分離、BU ごとの見え方、人レコードのない担当者の扱いを業務シナリオで確認します。
  • 環境間の同期:設定マスタは構成パッケージで移し、マスタ本体は移行手段(FBDI など)で入れます。
同名のパーティの重複候補(名寄せの一次チェック)
SELECT hp.party_name, COUNT(*) AS party_count
FROM hz_parties hp
WHERE hp.party_type = 'ORGANIZATION'
GROUP BY hp.party_name
HAVING COUNT(*) > 1
ORDER BY party_count DESC
要件 標準で満たせること 足りないとき
仕入先の登録・承認 Supplier Registration、承認ルール、重複チェック 外部の与信・反社チェックの連携(OIC)
追加の管理項目 DFF・EFF VBS による画面の拡張
マスタの配信 ビジネスイベント、BIP の定期出力、BICC、REST OIC によるファイル・API の配信
品目の新規申請 Product Hub の新品目要求 外部の申請システムとの連携
環境間の設定同期 FSM の構成パッケージ なし

考え方は 標準機能とアドオンの考え方 を参照してください。

  • 対応試験:GL 模擬テスト(エンタープライズ構造、COA)、AP 模擬テスト・調達模擬テスト(仕入先、サイト割当)、AR 模擬テスト(顧客)、在庫模擬テスト(在庫組織と品目)。
  • 覚えること:仕入先ヘッダは全社 1 件でサイトは調達 BU 単位、顧客は TCA の階層(パーティ → アカウント → サイト → 用途)、品目マスタ組織、1 つの BSV は 1 つの法的エンティティ、元帳は 4 要素、作成は参照される側が先。
  • 判断ポイント:「この属性はマスタで持つか組織で持つか」「この変更は稼働後も可能か」。

本サイトは学習目的で個人が作成した非公式の教材であり、Oracle Corporation およびその関連会社とは関係ありません。内容の正確性は保証しません。最新の仕様・試験範囲は必ず公式ドキュメントと Oracle University の情報で確認してください。

模擬テストの問題は公開されている出題範囲(Exam Topics)と公式ドキュメントをもとに独自に作成したもので、実際の試験問題ではありません。

Oracle、Java、MySQL は Oracle Corporation およびその子会社、関連会社の米国およびその他の国における登録商標です。その他の製品名・会社名は各社の商標です。

© 2026 Fusion ERP 実装ラボ