共通マスタデータの設計(取引先・品目・組織・COA)
マスタの全体像と依存関係
Section titled “マスタの全体像と依存関係”| マスタ | 作成・保守する場所 | 参照するモジュール | 変えにくい点 |
|---|---|---|---|
| 仕入先 | 調達(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 など → 従業員 → 取引先(仕入先・顧客)・銀行口座 → 品目 → 残高・未決取引マスタ別の設計
Section titled “マスタ別の設計”取引先(仕入先・顧客)と 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_accountFROM 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_idORDER BY hp.party_name品目(品目マスタ組織)
Section titled “品目(品目マスタ組織)”- 品目は品目マスタ組織で一度だけ定義し、在庫組織・品目組織へ割り当てます。マスタ組織は全社で 1 つにし、品目を取引する組織とは分けるのが推奨です(在庫組織と品目)。
- 属性ごとに、マスタ組織で管理するか組織ごとに管理するかを決めます。ロット・シリアル管理や取引可否は、取引の発生後に変更できないものが多く、移行前に確定します。
- 品目クラス(階層)とテンプレートで属性の既定値を配ります。品目コード体系、カテゴリ、基本単位と換算(単位クラス)を最初に決めます。
- 調達の明細、受注、原価、製造がこの品目を参照します。品目の新規申請の統制には Product Hub を使えます(品目マスタ管理)。
組織(法的エンティティ・BU・在庫組織など)
Section titled “組織(法的エンティティ・BU・在庫組織など)”- 法的エンティティは 1 つの BSV に割り当て、BU は 1 つのプライマリ元帳と既定の法的エンティティを持ちます(エンタープライズ構造)。
- 在庫組織は管理 BU・法的エンティティ・利益センター BU に紐づきます。原価組織が束ねられるのは、同じ法的エンティティ・利益センター BU・品目マスタ組織の在庫組織だけです。
- 参照データセット(支払条件・取引タイプなど)の共有方針は、マスタを移行する前に決めます。
- 稼働後に動かしにくいのは、元帳の COA・カレンダー・通貨、利益剰余金勘定、処理中の取引がある在庫組織の利益センター BU です。
COA・値セット・階層
Section titled “COA・値セット・階層”- COA のセグメント値は独立値セットで持ち、階層(ツリー)はバージョンと有効日で管理します。階層を変えたら残高キューブへ公開します(COA・元帳)。
- 勘定や部門を追加するときの流れ(申請 → 承認 → 値の登録 → 階層への配置 → 公開 → EPM への反映)を、マスタの運用として決めます。
- 値セットの Translatable は後から変更できません。日本語と英語を併用する可能性があれば最初に選びます(フレックスフィールド)。
- 移行は FBDI の Import Segment Values and Hierarchies と Import Account Combinations を使います。
カレンダー・通貨
Section titled “カレンダー・通貨”- 会計カレンダーは元帳の期間を決め、AP・AR・FA・在庫などの会計期間は元帳のカレンダーに沿って各モジュールで開閉します。親会社と子会社でカレンダーが異なると、元帳セット・データ・アクセス・セット・Close Monitor を共通化できません。
- 在庫組織の施設スケジュール(稼働日)や、固定資産の償却カレンダー・按分カレンダーは別の設定です。会計カレンダーとの対応を設計時に確認します。
- 通貨とレートタイプ(Spot・Corporate・User・Fixed)は、会計方針として先に決めます。日次レートはスプレッドシート(ADFdi)、FBDI、Web サービスで取り込めます。取込が遅れると外貨取引の会計処理が止まるため、監視と代替手順(手入力)を決めておきます(参照タイプ・プロファイル・共通マスタ)。
従業員・ユーザー
Section titled “従業員・ユーザー”- ユーザーは人レコードと一緒に作るのが基本です(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 単位のデータセキュリティを組み合わせます(セキュリティ設計)。
作成・移行の順序
Section titled “作成・移行の順序”| 順 | 対象 | 前提 | 主な手段 |
|---|---|---|---|
| 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 を参照してください。構成パッケージは、移行先にだけあるレコードを削除せず、ユーザー・レベルのプロファイル値を移さない点に注意します。
外部 MDM・EDM との連携
Section titled “外部 MDM・EDM との連携”| パターン | 正の置き場 | 連携の手段 |
|---|---|---|
| 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 など)の提供有無と仕様は、本章では確認できていません。リリースにより異なるため、公式ドキュメントで確認してください。
実装・テストのポイント
Section titled “実装・テストのポイント”- 移行リハーサル:件数・キー重複・必須項目の欠けを、リハーサルごとに確認します。サイト割当のない仕入先サイト(仕入先管理 の SQL)や、重複したパーティを SQL で洗い出します。
- 権限テスト:登録者と承認者の分離、BU ごとの見え方、人レコードのない担当者の扱いを業務シナリオで確認します。
- 環境間の同期:設定マスタは構成パッケージで移し、マスタ本体は移行手段(FBDI など)で入れます。
SELECT hp.party_name, COUNT(*) AS party_countFROM hz_parties hpWHERE hp.party_type = 'ORGANIZATION'GROUP BY hp.party_nameHAVING COUNT(*) > 1ORDER BY party_count DESC標準とアドオンの境界
Section titled “標準とアドオンの境界”| 要件 | 標準で満たせること | 足りないとき |
|---|---|---|
| 仕入先の登録・承認 | Supplier Registration、承認ルール、重複チェック | 外部の与信・反社チェックの連携(OIC) |
| 追加の管理項目 | DFF・EFF | VBS による画面の拡張 |
| マスタの配信 | ビジネスイベント、BIP の定期出力、BICC、REST | OIC によるファイル・API の配信 |
| 品目の新規申請 | Product Hub の新品目要求 | 外部の申請システムとの連携 |
| 環境間の設定同期 | FSM の構成パッケージ | なし |
考え方は 標準機能とアドオンの考え方 を参照してください。
試験対策ポイント
Section titled “試験対策ポイント”- 対応試験:GL 模擬テスト(エンタープライズ構造、COA)、AP 模擬テスト・調達模擬テスト(仕入先、サイト割当)、AR 模擬テスト(顧客)、在庫模擬テスト(在庫組織と品目)。
- 覚えること:仕入先ヘッダは全社 1 件でサイトは調達 BU 単位、顧客は TCA の階層(パーティ → アカウント → サイト → 用途)、品目マスタ組織、1 つの BSV は 1 つの法的エンティティ、元帳は 4 要素、作成は参照される側が先。
- 判断ポイント:「この属性はマスタで持つか組織で持つか」「この変更は稼働後も可能か」。
公式ドキュメント
Section titled “公式ドキュメント”- Oracle Supplier Model(26D)
- Supplier Sites and Supplier Site Assignments(26D)
- Item Master Organizations(26C)
- Business Units(26D)
- Reference Data Sets and Sharing Methods(26D)
- Primary Ledgers, Secondary Ledgers, and Reporting Currencies(26D)
- Guidelines for Creating Conversion Rate Types(26D)
- HZ_PARTIES(Tables and Views)
本サイトは学習目的で個人が作成した非公式の教材であり、Oracle Corporation およびその関連会社とは関係ありません。内容の正確性は保証しません。最新の仕様・試験範囲は必ず公式ドキュメントと Oracle University の情報で確認してください。
模擬テストの問題は公開されている出題範囲(Exam Topics)と公式ドキュメントをもとに独自に作成したもので、実際の試験問題ではありません。
Oracle、Java、MySQL は Oracle Corporation およびその子会社、関連会社の米国およびその他の国における登録商標です。その他の製品名・会社名は各社の商標です。
© 2026 Fusion ERP 実装ラボ