A flexfield is a field made up of sub–fields, or segments. There are two types of flexfields: key flexfields and descriptive flexfields. A key flexfield appears on your form as a normal text field with an appropriate prompt. A descriptive flexfield appears on your form as a two–character–wide text field with square brackets [ ] as its prompt. When opened, both types of flexfield appear as a pop–up window that contains a separate field and prompt for each segment. Each segment has a name and a set of valid values. The values may also have value descriptions.
KFF, DFF, Structure, Segemnt, Value, Value Set, Value Description, Aliases, Rules, Groups, Security.

Key Flexfields
Most organizations use ”codes” made up of meaningful segments (intelligent keys) to identify general ledger accounts, part numbers, and other business entities. Each segment of the code can represent a characteristic of the entity. For example, your organization might use the part number PAD–NR–YEL–8 1/2×14” to represent a notepad that is narrow–ruled, yellow, and 8 1/2” by 14”. Another organization may identify the same notepad with the part number ”PD–8×14–Y–NR”.
Both of these part numbers are codes whose segments describe a characteristic of the part. Although these codes represent the same part, they each have a different segment structure that is meaningful only to the organization using those codes.
The Oracle Applications store these ”codes” in key flexfields. Key flexfields are flexible enough to let any organization use the code scheme they want, without programming. When your organization initially installs Oracle Applications, you and
your organization’s implementation team customize the key flexfields to incorporate code segments that are meaningful to your business. You decide what each segment means, what values each segment can have, and what the segment values mean. Your organization can define rules to specify which segment values can be combined to make a valid complete code (also called a combination). You can also define relationships among the segments. The result is that you and your
organization can use the codes you want rather than changing your codes to meet Oracle Applications’ requirements.
For example, consider the codes your organization uses to identify general ledger accounts. Oracle Applications represent these codes using a particular key flexfield called the Accounting Flexfield. One organization might choose to customize the Accounting Flexfield to include five segments: company, division, department, account, and project. Another organization, however, might structure their general ledger account segments differently, perhaps using twelve segments instead of five. The Accounting Flexfield lets your Oracle General Ledger application accommodate the needs of different organizations
by allowing them to customize that key flexfield to their particular business usage.
Descriptive Flexfields
Descriptive flexfields provide customizable ”expansion space” on your forms. You can use descriptive flexfields to track additional information, important and unique to your business, that would not otherwise be captured by the form. Descriptive flexfields can be context sensitive, where the information your application stores depends on other values your users enter in other parts of the form. A descriptive flexfield appears on a form as a single–character, unnamed field enclosed in brackets. Just like in a key flexfield, a pop–up window appears when you move your cursor into a
customized descriptive flexfield. And like a key flexfield, the pop–up window has as many fields as your organization needs.
Each field or segment in a descriptive flexfield has a prompt, just like ordinary fields, and can have a set of valid values. Your organization can define dependencies among the segments or customize a descriptive flexfield to display context–sensitive segments, so that different segments or additional pop–up windows appear depending on the values you enter in other fields or segments.

  1. KFF & DFF
  2. Structure, Segment & Qualifier
  3. Value (Parent, Group, Hirearchy & Qualifier) , Value Description & Value Set
  4. Security Rule, Cross-Validation & Alias
  5. Accounting Flexfield (Chart of Account & Account Generator processes)
SELECT fu.user_name “User Login”, fu.description “Role Description”,
fu.start_date “Login Start Date”, fu.end_date “Login End Date”,
fu.email_address “E-Mail Associated”, fu.employee_id “Employee Id”,
ppf.employee_number “Employee Number”, ppf.full_name “Full Name”,
hou.NAME “Business Group”,
fr.responsibility_name “Responsibility Associated”,
fur.start_date “Association Start Date”,
fur.end_date “Association End Date”
FROM apps.fnd_user fu,
apps.per_all_people_f ppf,
apps.hr_all_organization_units hou,
apps.fnd_user_resp_groups_all fur,
apps.fnd_responsibility_tl fr
WHERE ppf.person_id = fu.employee_id
AND hou.organization_id = ppf.business_group_id
AND ppf.effective_end_date = TO_DATE (’31/12/4712′, ‘DD/MM/RRRR’)
AND fu.user_id = fur.user_id
AND NVL (fur.end_date, SYSDATE + 1) > SYSDATE
AND fur.responsibility_id = fr.responsibility_id
AND fr.responsibility_name LIKE ‘%XXXX%’ – Replace with appropriate OU Qualifier
AND fr.LANGUAGE = ‘US’
ORDER BY fu.user_name, fr.responsibility_name
Select a.bank_account_name, a.bank_account_num, a.iban_number, a.bank_account_type,
a.currency_code, a.bank_account_name_alt, a.org_id, a.creation_date,
b.bank_name, b.bank_branch_name, b.bank_num , b.eft_swift_code,
b.address_line1, b.address_line2, b.city, b.county, b.state, b.zip,
b.country, c.vendor_id,d.vendor_name,d.segment1 AS SUPPLIER_NUM
from apps.ap_bank_accounts_all a,
apps.ap_bank_branches b,
apps.ap_bank_account_uses_all c,
apps. PO_VENDORS d
where a.org_id=xxxx
AND a.bank_branch_id = b.bank_branch_id
AND a.bank_account_id = c.external_bank_account_id
AND c.vendor_id=d.vendor_id
 AND c.end_date IS NULL
Select a.order_number Sales_Order, d.trx_number IC_AR_INVOICE, e.INVOICE_NUM IC_AP_INVOICE, g.segment1 PO_NUMBER,
b.ordered_item, b.invoice_interface_status_code,
b.invoiced_quantity, b.flow_status_code
From apps. oe_order_headers_all a,
     apps. oe_order_lines_all b,
     apps. HR_ALL_ORGANIZATION_UNITS c,
     apps. RA_CUSTOMER_TRX_ALL d,
     apps. AP_INVOICES_ALL e,
     apps. OE_DROP_SHIP_SOURCES f,
     apps. PO_HEADERS_ALL g
Where
b.header_id = a.header_id
AND f.LINE_ID = b.line_id
AND d.org_id=c.organization_id
AND a.order_number=’10090178′ //SO number
AND c.name LIKE ‘XXX%UK%’ //Operating unit
AND d.ct_reference= to_char(a.order_number)
AND e.INVOICE_NUM = d.trx_number
AND f.po_header_id=g.po_header_id
Below simple code can be used to check reason for invoices rejected by  Payables Open Interface Import.
Select aii.Invoice_num , air.PARENT_TABLE, air.REJECT_LOOKUP_CODE, air.parent_id
From apps. AP_INTERFACE_REJECTIONS air,
apps. AP_INVOICE_LINES_INTERFACE aili,
apps. AP_INVOICES_INTERFACE aii
WHere aii.invoice_id=aili.invoice_id
AND  aili.invoice_id=air.parent_id
AND aii.Invoice_num = ‘Invoice Number’