Oracle EBS Flexfield

ページ内目次

　基本
　セグメント
　セグメント追加
　 DFF（記述的Flexfield）
　コンテキスト作成
　従属バリューセット

🧑‍💼 Oracle Flexfieldの基本

Oracleでは、ビジネスに合わせた機能拡張を可能にする「Flexfield（フレックスフィールド）」という機能があります。これを使うことで、Oracleの標準的な機能に自社のビジネス要件に合わせたフィールドを追加できます。大きく分けて、Key Flexfield と Descriptive Flexfield の2種類があり、それぞれに特徴があります。

🏷️ 1. Key Flexfield（キー・フレックスフィールド）

Key Flexfield は、Oracleが提供する標準的なフィールドで、特定のビジネスプロセスに関連する情報を格納します。例えば、会計科目（会計コード）などがこれに該当します。この種のフィールドは、他のOracleモジュールとも共有されるため、企業全体で統一的に使用されます。

主な特徴 ✨

ビジネスプロセスに必須で、他のモジュールと共有される。
属性（フィールド）の内容は変更可能ですが、ビジネスロジック上、必要な項目が決まっていることが多い。
会計フレックスフィールド（例えば、General Ledger用の会計科目）は代表的な例です。

📝 2. Descriptive Flexfield（記述型フレックスフィールド）

Descriptive Flexfield は、より柔軟なカスタマイズが可能なフィールドで、特定のビジネスの要求に応じて自由に作成できます。必要であれば使用できますが、必ずしも全てのユーザーが利用しなければならないわけではありません。

主な特徴 ✨

業務ごとに柔軟にカスタマイズ可能で、使用は任意。
例えば、製品やサービスに関連する情報など、企業独自の情報を追加する際に使用されます。

🌍 3. Global Descriptive Flexfield（グローバル記述型フレックスフィールド）

Oracleでは、特定の国や地域向けに特化したローカライズ製品を提供しており、これに伴ってGlobal Descriptive Flexfieldも用意されています。これらは主にブラジルやアルゼンチンなど、税制が複雑な国向けの要件をサポートします。グローバル記述型フレックスフィールドは、これらの特定の地域向けに必要な情報を管理するために使われます。

⚙️ Key Flexfieldのセットアップ方法

次に、実際にKey Flexfieldを設定する方法を見ていきましょう。

Key Flexfieldの場所を特定する 🧐
- 責任範囲：「Receivables」などの担当モジュールに関連する設定画面を開きます。
- 「セットアップ」→「ファイナンシャル」→「Flexfields」→「Key Flexfields」へと進みます。
ここから、実際にKey Flexfieldの設定を行います。
会計フレックスフィールドの設定 🏦
- 「会計フレックスフィールド」を選択します。このフィールドは、主に企業の「勘定科目」などを管理するために使用されます。
- 会計フレックスフィールドでは、セグメントの区切り（例えば、ハイフン「-」やピリオド「.」）を設定できます。これにより、コードの視認性が向上し、管理が容易になります。
重要な設定項目 🔧
- フレックスフィールドの凍結: 設定が完了したら、「Freeze Flexfield」を選択して設定を確定します。これにより、定義内容が固定され、今後の変更が反映されます。
- クロスバリデーション: 特定の勘定科目コードが無効な取引を防ぐためのルール設定ができます。例えば、「経費科目」として設定されたコードに「収益科目」の取引を登録できないようにするなど、整合性を保つために役立ちます。
- 動的挿入の許可: 新しいコードの組み合わせを後から追加できる設定です。これを有効にしておくと、必要に応じて新しいコードを作成できるため、柔軟性が高まります。

⚠️ 設定後の注意点

フレックスフィールドに変更を加えたら、必ず**「Freeze」**して変更内容を確定し、コンパイルする必要があります。
クロスバリデーションルールを設定することで、不正なデータ入力を防ぐことができます。
動的挿入を有効にすると、新しい取引が発生した際にコードが自動的に作成されるため、柔軟に対応できます。

📚 まとめ

Key Flexfieldは、業務全体に関わる重要なデータを管理するためのフィールドで、標準的な操作においては必須となります。
Descriptive Flexfieldは、柔軟にカスタマイズ可能なフィールドで、ビジネスに合わせて任意で使用できます。
Global Descriptive Flexfieldは、特定の地域や国向けの税制要件に対応するために使用されます。

🧑‍💼 Key Flexfield: 会計フレックスフィールドの詳細

前回のレッスンでKey FlexfieldとDescriptive Flexfield、そしてGlobal Descriptive Flexfieldの違いを学びましたが、今回は実際の会計フレックスフィールドについて詳しく見ていきましょう。会計フレックスフィールドは、企業の勘定科目を管理するために重要な役割を果たします。

🏦 会計フレックスフィールドの構造

まず、会計フレックスフィールドの基本的な構造を見ていきます。会計フレックスフィールドは、コード組み合わせ（Code Combination）として知られ、これが企業の勘定科目表の基礎を成します。以下が、私の使用しているレジャーに関連する会計フレックスフィールドのセグメント構成です。

セグメント1：会社（Company）
- 通常、最初のセグメントは「会社」であり、バランスを取るために使用されます。すべての借方と貸方はこのセグメントを基準にしてバランスが取られます。
セグメント2：部門（Department）
- 部門セグメントは、いくつかの企業ではコストセンターとして使用されることもあります。部門ごとのコストを管理するために重要な役割を果たします。
セグメント3：自然勘定（Account）
- これは、自然勘定セグメントと呼ばれ、例えば売掛金、買掛金、現金、売上などのアカウントが含まれます。
セグメント4：サブアカウント（Sub Account）
- サブアカウントセグメントは、細かい分類をするために使用されます。
セグメント5：製品（Product）
- 製品ラインやその他の商品関連の情報を管理するためのセグメントです。

🧐 欠けているセグメントについて

この会計フレックスフィールド構造には、将来的にビジネスの成長に対応できるような拡張性が欠けていると感じます。特に、次の2つのセグメントが欠けていると考えています。

プロジェクトセグメント（Project Segment）
- プロジェクトごとの費用や請求書を管理するためには、プロジェクトセグメントが必要です。これがないと、プロジェクト単位での会計管理ができません。
将来の拡張用セグメント（Future Segment）
- 企業が成長するにつれて、追加のセグメントが必要になる可能性があります。例えば、新しいビジネス部門や新しい国への進出を考えると、将来的な拡張のためのセグメントを予め設けておくことが重要です。

⚙️ 会計フレックスフィールドの設定

会計フレックスフィールドを正しく設定するためには、フレックスフィールド・クオリファイアを使って、各セグメントの役割を明確にする必要があります。以下、各セグメントにどのようにクオリファイアを設定するかを説明します。

1. 会社セグメント（Company Segment）

このセグメントは「バランシングセグメント」として設定する必要があります。これにより、Oracleは借方と貸方をこのセグメントに基づいてバランスさせます。

2. 部門セグメント（Department Segment）

部門セグメントはコストセンターとして設定されることが多いです。これにより、部門ごとのコスト管理がしやすくなります。

3. 自然勘定セグメント（Natural Account Segment）

これは、売掛金、買掛金、現金など、各種アカウントに関連するセグメントです。Oracleでは、これを「自然勘定」として特定します。

4. サブアカウント（Sub Account）

特に設定しない場合もありますが、細かい分類を管理するために使用されます。

🔒 セキュリティ設定とクロスバリデーション

会計フレックスフィールドには、セキュリティやクロスバリデーションの設定も重要です。

セキュリティの有効化：会計フレックスフィールドにおいて、セキュリティを有効にすることで、特定の責任範囲のユーザーだけが特定のアカウントや部門にアクセスできるように制限できます。
クロスバリデーション：異なるアカウントや部門の不正な組み合わせを防ぐためのルール設定です。例えば、特定の部門では特定のアカウントにしか取引を登録できないようにすることができます。

🛠️ セグメントサイズとバリューセット

各セグメントのサイズ（例えば、会社セグメントのコードが2桁など）は、バリューセットという設定によって制御されます。バリューセットは、各セグメントの入力規則や最大長さを設定するために使用されます。

例えば、会社セグメントのコードは最大2桁として設定されていますが、これでは将来的に会社数が増える際に制約となります。こうした制限を緩和するためには、バリューセットの設定を変更する必要があります。

💡 まとめ

会計フレックスフィールドは、企業の勘定科目を管理するための基本的な枠組みであり、正しいセグメントの設定が重要です。
プロジェクトセグメントや将来の拡張用セグメントなどを予め設定しておくことで、将来的な成長に対応できます。
各セグメントには、フレックスフィールド・クオリファイアを設定することが重要であり、セキュリティ設定やクロスバリデーションでデータの整合性を保つことができます。
セグメントのサイズやバリューセットは、企業の将来的な要件に合わせて適切に設定する必要があります。

📘 セグメントの追加

このレッスンでは、**会計フレックスフィールド（Accounting Flexfield）**に新しい「会社」コード（セグメント）を追加する方法を、ステップバイステップで学びます。

いきなり難しそうに聞こえるかもしれませんが、実はとてもシンプルな作業です。

🧭 ステップ1：現在の会社コードを確認

まず、既に登録されている「会社」セグメントを確認します。

ナビゲーション（GLモジュール）
セットアップ > 財務 > 会計フレックスフィールド > セグメント
※このステップはGLユーザー向けなので、今はざっくりと把握でOKです。
現状確認
コード「03」と「05」は存在しており、「04」が空いているのを発見。
→ 新しく取得したシカゴの事業所用に「04」を追加することに決定！

🧱 ステップ2：値セット（Value Set）に新しい値を追加

📌 値セットとは？

セグメントで選択できる**コード一覧（リスト）**を管理する仕組みです。

🔍 ナビゲーション手順

（今回はReceivablesの責任者メニューからアクセス）

セットアップ > 財務 > フレックスフィールド > キーフレックスフィールド > 値
表示方法を Value Set に変更
使用中の値セット名（例：Operations Company）を入力して検索

➕ ステップ3：会社コード「04」を追加

「新規作成（New）」をクリック
コード：04
名称：Chicago Operations
保存方法：
- Ctrl + S または
- フロッピーディスクのアイコンをクリック

💡 冗談：「Ctrl + Sは“Jesus saves”と同じくらい大切」と講師は冗談を言っていました😄

🔁 ステップ4：バリューセット階層のコンパイル

保存すると、Oracleが自動でバックグラウンドで処理を開始
メッセージ：「Submitted request to compile value set hierarchy」
- これは新しい値を反映するための「コンカレントプログラム」が動いたことを意味します
View > Requestsからステータスを確認
→ ステータスが「Completed」になれば完了！

🧙‍♂️ ステップ5：Chart of Accounts に新会社が表示される！

処理が完了すると、Chart of Accounts画面で…

✅ **Chicago Operations（04）**が選べるようになります！

🔄 応用：他のセグメント（部門など）にも同じ手順を使える

「会社」セグメントだけでなく、**部門（Department）**など他のセグメントにも同じ方法で値を追加できます。
例えば、999 - Orders という部門を追加すると、ユーザーが迷った時に選ばれる「その他」的な選択肢として機能することもあります（※使い方に注意が必要です）。

🛡️ 補足：セキュリティルールと制限

値を追加しても、責任範囲（Responsibility）ごとのセキュリティルールで、あるユーザーからは見えないこともあります。
このような制限は「セキュリティルール（Security Rules）」や「クロスバリデーションルール」で管理されます。

🧩 Descriptive Flexfield（DFF）とは？

DFF（記述的フレックスフィールド）は、Oracle EBSの画面に独自の項目（フィールド）を追加できる仕組みです。これにより、アプリケーション全体をカスタマイズせずに、業務に合わせた拡張が可能です。Oracleはこれを「ノンカスタマイズで柔軟に対応できる」点として強調しています。

🤔 なぜDFFが必要なの？（使用例）

たとえば、アメリカの部門が使っていて「取引がどのサブ部門に関連しているか」を記録したいけれど、標準の入力項目には存在しないとします。
その場合にDFFを使って「サブ部門」項目を追加することで、追跡やレポート作成が可能になります。

🔎 DFFの見分け方

画面上で[ ]（角括弧）で囲まれた箇所がDFFです。
たとえば、取引画面で「Invoice Transaction Flexfield」や「Line Transaction Flexfield」と表示される部分など。
取扱い注意なDFFもあるので、特に「請求インターフェース系」は慎重に扱いましょう。

🛠 DFFの作成手順（概要）

以下のような流れでDFFを作成します。

🔁 ステップ①：DFFセグメントの編集画面を開く

ナビゲーションパス：
Receivables責任者メニュー → Setups → Financials → Flexfields → Descriptive → Segments

例：
「Invoice Line Information」というタイトルのDFFを編集する場合、検索して開きます。

🧊 ステップ②：フリーズを解除する

最初は編集がグレーアウト（無効）になっています。
→「Freeze Flexfield Definition」のチェックを外すことで編集可能になります。

⚠ Oracleから「既存データへの影響に注意」の警告が出ますが、新規項目なら問題ありません。

➕ ステップ③：新しいセグメント（項目）を追加

例：

項目	値
番号	10（5ずつ空けるのが推奨）
名前	Product Sub Code
属性（Attribute）	Attribute15（下から使うのが推奨）

🔸 補足：Attributeは内部テーブルでデータを保存する列のこと。
Attribute1から順にOracleが使うことがあるので、Attribute15など下の番号から使用したほうがパッチの影響を避けられます。

⚙ ステップ④：項目の設定

セグメントの設定画面で以下のように調整します：

Required（必須）チェックを外す：全てのトランザクションに入力を強制しないため
**Display Size（表示サイズ）**を調整：例えば「10文字」

✅ ステップ⑤：保存 → フリーズ → コンパイル

保存（Save）
再度「Freeze Flexfield」にチェック
コンパイル（Compileボタンをクリック）

Oracleが自動で生成・登録処理を行います。
※リクエスト画面で「Flexfield Generator」が完了しているか確認可能。

📏 バリューセット（入力値の制限）の追加

現在のままでは、ユーザーが自由に入力できてしまうため、**入力値を制限するリスト（バリューセット）**を追加します。

🧱 ステップ①：バリューセットを作成

DFFセグメント画面内で「Value Set」をクリックし、以下の設定：

項目	値
名前	XX_PRODUCT_SUB_CODE
説明	Product subcode
データタイプ	Char（文字）
サイズ	10
数字のみ入力	チェックする（必要なら）
検証タイプ	Independent

🗃 ステップ②：値のリストを登録

ナビゲーションパス：
Setups → Financials → Flexfields → Validation → Values

作成した「XX_PRODUCT_SUB_CODE」に対して、以下のように値を追加：

値	意味
00001	製品コードA
11111	製品コードB
22222	製品コードC

📋 結果：リスト表示されるDFF

トランザクション画面のDFFで、リストから選べるようになります！
→ ユーザーが誤入力するリスクが大幅に減ります。

🧠 Context（文脈）とは？

Oracle EBSでは、DFFに「Context（文脈）」という仕組みがあります。これは、国や事業単位ごとに異なるDFF項目を切り替えて表示できる非常に便利な機能です。

例えば：

アメリカ：郵便番号を追跡する「County（郡）」項目が必要
ブラジル：税コードを記録する「Tax Code」項目が必要
日本：取引先の漢字名を記録したい

こういった国ごとのニーズを1つのFlexfieldの中で整理できる仕組みが Context です。

🔥 Contextが必要な理由

❌ 問題点：Global Data Elementsだけでは限界がある

DFFで使える「Attribute」は数に限りがあります（通常15個など）。
全ての国や部署の要件を詰め込むと、項目が足りなくなる。
他国向けの項目が他の国のユーザーにも表示されてしまい、混乱を招く。

✅ 解決策：Contextで項目を国別に整理

アメリカ向けContext：US
ブラジル向けContext：BR
日本向けContext：JP

このように文脈ごとにDFFを切り替えることで、「必要な人にだけ必要な項目を表示」できるようになります。

🏗 Contextの作成手順（概要）

🔁 ステップ①：コンテキストの追加

DFFセグメント設定画面を開く（例：Invoice Line Information）。
画面上部の「Context Field Values」に値を追加。
- 例：US, BR, JPなど。

➕ ステップ②：Contextごとのセグメントを作成

各Contextに応じて必要なセグメントを定義：

US → Product County
BR → Tax Code
JP → Furigana（ふりがな）

それぞれのセグメントで使用する属性（Attribute）番号はContextごとに重複しても問題なし。

📌 補足：
Contextが違えば、同じAttribute番号（例：Attribute11）をそれぞれ別の目的で使えます。

👁 ステップ③：Context選択を「表示」する

設定画面で「Context Field」を**表示（Display）**にしておかないと、ユーザーが画面で選べません。

💡 補足： 表示せずに使いたい場合は、「プロファイルオプション」や「別フィールド」から自動的に判定する仕組みを作る必要があります（上級編）。

🧊 ステップ④：保存 → Freeze → Compile

変更後は必ず以下を実行：

Save（保存）
Freeze（フリーズにチェック）
Compile（コンパイル）

→ システムが再構築してくれます。

💡 画面での見え方（例）

請求明細（Invoice Line）画面でDFFを開くと…

通常は全ユーザーに「Global Data Elements」が表示される。
Context表示を有効にすると、ユーザーが自分の国に応じたContextを選択できる。
- 例：USを選ぶと「Product County」だけが表示される
- BRを選ぶとブラジル専用項目だけが表示される

これにより、不要な項目は一切見えなくなり、入力ミスや混乱を防止できます。

🚨 Context未使用によるリスク

他国向けの項目が表示されてしまい、ユーザーが意味も分からず選択してしまう。
入力ミス → レポートが乱れる → システム全体に悪影響
トレーニングの手間が増え、定着しない

❗ユーザーは「何も考えずに最初に出てきた選択肢を選んで保存する」ことが多いです。
→ だからこそ、Contextを使って「不要な情報を非表示にすること」が重要です。

💡 従属（依存）バリューセット

従属バリューセット（Dependent Value Set）について学びます。
これは ある値を選んだ結果、次に選べる値が変わる という構造です。実務でもよく使われます。

📘 ステップバイステップで整理

🔧 1. 従属バリューセットの基本構造

例：

「製品サブコード（Product Sub Code）」を先に選ぶ
その内容に応じて「製品地域（Product Region）」の候補が変わる

🧱 2. 独立バリューセット（先に選ぶ方）の作成

例：
以下の「サブコード」を作成（すでに作成済みと仮定）

コード	説明
000	US用サブコード
111	Brazil用
222	UK用
333	China用

🧩 3. 従属バリューセットの作成（Product Region）

Oracleで新しいバリューセットを作成
名前：Product Region - Dependent on Subcode
Validation Typeを Dependent にする
依存元（Independent）のバリューセットとして「Product Sub Code」を選ぶ
値の最大長さは10など、自由に設定

✍️ 4. 従属バリュー（値）の登録

それぞれのサブコードごとに、選べる地域を登録します。例えば：

サブコード	地域（Region）
000	US
111	Brazil
222	UK
333	China

🔎 補足：
この関係は「1対多」も可能です（例：111→Brazil, Argentinaなど）。
必ずしも「1対1」である必要はありません。

💻 5. フィールドの表示設定と再コンパイル

必ず「Freeze（固定化）」→「Compile（コンパイル）」 を忘れずに
「Context Value」などが表示されていることも確認
表示されていないと、選択できなくなります（バグではない）

🧪 6. 実際の挙動（ユーザー視点）

画面で確認すると：

「Product Sub Code」に 000 を選ぶと、次のフィールド「Product Region」には US だけが選択可能
111 を選ぶと Brazil が表示される
333 を選ぶと China …というように動作する

🎁 おまけ知識：従属バリューセットの用途

商品分類：カテゴリ → サブカテゴリ（例：PC → モニター、マウスなど）
国 → 地域
組織 → 部門

など、現実の業務にもよくある「選択肢が変わる」パターンで使われます。

前の記事：Oracle EBS コンカレント

次の記事：Oracle EBS Role-Based Access Control（RBAC）入門