Data Synchronization: Data Synchronization is a process in which some setup data would be synchronized, and this would be more important when you are working in oracle application development/implementation project. The equally important that AOL data Migration takes place necessary to synchronize the data across databases instance during
  • Installations (New desc. flex field creations etc)
  • Upgrades (Apps upgrade etc)
  • Maintenance (Value set changes etc)

FNDLOAD is one and only oracle solution. It can be defined as a concurrent program that can move Oracle Applications data between database and text file representations. Or this can be defined as FNDLOAD can download data from an application entity into an editable text file, which can be uploaded to another database.

Working of FNDLOAD: Conversion between database format and text file format is specified by a configuration file. Oracle does provide configuation file and it is important to just pass the configuration file name and then just call the loader and leave everything .

These are the extensive list which can be done through FNDLOAD

  • Concurrent Programs, Executables
  • Request Groups, Request Sets
  • Profile Options
  • Key and Descriptive Flexfields
  • Menus and Responsibilities
  • Forms and Form Functions
  • Attachments
  • Messages
  • Value Sets and Values
  • Lookup Types
  • User Responsibilities
  • Printer Definitions
  • FND Dictionary
  • Help Configuration
  • Document Sequences
  • Concurrent Manager Schedules

Advantages using FNDLOAD are :

  • Because downloaded data is stored in a text file, version administration is possible
  • No learning curve.
  • Fully supported and recommended by Oracle
  • Capture the migrations in a file and use it during installations, clones etc. to migrate in batch
  • Pin-point when something happened and where (database) easily
  • Your AOL data migration process is now simplified and streamlined.


  • Applications patching mechanisms use FNDLOAD heavily – possibility of negative impact is not zero
  • UPLOAD_MODE=REPLACE only for menus
  • No validation against migrating database/instance sensitive data

Syntax : To use FNDLOAD, the following syntax is needed.
FNDLOAD apps/appspwd 0 Y mode configfile datafile entity [parameter1…..]

  • The mode is either DOWNLOAD or UPLOAD.
  • The configfile is the file that Fndload needs to download on upload data.
  • The data file is the output file, in which the downloaded data is written
  • The entity is the entity you want to download,

Modes of Operation:Two modes .. Upload and Download…
1. Example of download:

FNDLOADapps/pwd 0 Y DOWNLOAD ${FND_TOP}/patch/115/import/afcpprog.lct myfile.ldt \ PROGRAM CONCURRENT_PROGRAM_NAME= concurrent_program_short_name> APPLICATION_SHORT_NAME=

2. Example of Upload

FNDLOAD apps/pwd 0 Y UPLOAD ${FND_TOP}/patch/115/import/afcpprog.lct myfile.ldt - CUSTOM_MODE=FORCE undocumented parameter

FNDLOAD Load Options:

  1. Application level OR single entity level download: Download all the profile options of Inventory or just the INV: Default Primary UOM
  2. Entire OR Partial upload of a data file: Upload the entire myfile.ldt or just a single enity indicated by - and mode UPLOAD or UPLOAD_PARTIAL
    Entity name required for UPLOAD_PARTIAL mode
  3. Custom mode force update : To override Oracle’s upload algorithm and update the custom AOL data regardless, use CUSTOM_MODE= FORCE
    UPLOAD_MODE= REPLACE (only for menus)
  4. Support for NLS uploads : NLS data uploads for translated columns are supported, use UPLOAD_MODE= NLS

Config File Location: By default Oracle delivers most of configuration files you can use to download certain entities.

1. Configuration files with extension .lct
On Unix - all the configuration files are in $FND_TOP/patch/115/import directory
On Unix – Oracle also places the original configuration files in $FND_TOP/admin/import directory
2. Data files with extension .ldt

  • The config files (.lct) are delivered and maintained by Oracle.
  • It has entity definitions, parent-child relationships and user input parameters identified by :NAME
  • Downloading a parent automatically downloads all children - e.g. Concurrent Program download
  • The data files (.ldt) have both entity definition and the data
  • It also shows the version and the location of the config file (.lct) that was used
  • Without the config file, data file is useless
  • Without the data file, config file is meaningless
  • Key files: .lct and .ldt
  • You must run the FNDLOAD as apps user not as applsys or any other, otherwise you will receive Ora-6550
  • Both are easily readable, editable and portable
  • DO NOT MODIFY Oracle’s .lct files
  • Use your favorite editor (I would suggest Textpad or Editplus) to manipulate only the .ldt files but be cautious about data type, length, delimiter placements etc.
  • Use the log file outputs or .ldt file contents creatively for quick file comparisons and answer questions faster (Why can’t I access that? What is that profile option name, value and level? What is the value set used for that DFF segment attribute10 etc.)
  • Partial string searches (which value set has Priority “something” in its where clause? etc)

Sample Script Code:

1 - Printer Styles
FNDLOAD apps/apps@seed115 O Y DOWNLOAD $FND_TOP/patch/115/import/afcppstl.lct file_name.ldt STYLE PRINTER_STYLE_NAME=”printer style name”

2 - Lookups
FNDLOAD apps/apps@seed115 O Y DOWNLOAD $FND_TOP/patch/115/import/aflvmlu.lct file_name.ldt FND_LOOKUP_TYPE APPLICATION_SHORT_NAME=”prod” LOOKUP_TYPE=”lookup name”

3 - Descriptive Flexfield with all of specific Contexts
FNDLOAD apps/apps@seed115 O Y DOWNLOAD $FND_TOP/patch/115/import/afffload.lct file_name.ldt DESC_FLEX P_LEVEL=?COL_ALL:REF_ALL:CTX_ONE:SEG_ALL? APPLICATION_SHORT_NAME=”prod” DESCRIPTIVE_FLEXFIELD_NAME=”desc flex name” P_CONTEXT_CODE=”context name”

4 - Key Flexfield Structures
FNDLOAD apps/apps@seed115 O Y DOWNLOAD $FND_TOP/patch/115/import/afffload.lct file_name.ldt KEY_FLEX P_LEVEL=?COL_ALL:FQL_ALL:SQL_ALL:STR_ONE:WFP_ALL:SHA_ALL:CVR_ALL:SEG_ALL? APPLICATION_SHORT_NAME=”prod” ID_FLEX_CODE=”key flex code” P_STRUCTURE_CODE=”structure name”

5 - Concurrent Programs
FNDLOAD apps/apps@seed115 O Y DOWNLOAD $FND_TOP/patch/115/import/afcpprog.lct file_name.ldt PROGRAM APPLICATION_SHORT_NAME=”prod” CONCURRENT_PROGRAM_NAME=”concurrent name”

6 - Value Sets
FNDLOAD apps/apps@seed115 O Y DOWNLOAD $FND_TOP/patch/115/import/afffload.lct file_name.ldt VALUE_SET FLEX_VALUE_SET_NAME=”value set name”

7 - Value Sets with values
FNDLOAD apps/apps@seed115 O Y DOWNLOAD $FND_TOP/patch/115/import/afffload.lct file_name.ldt VALUE_SET_VALUE FLEX_VALUE_SET_NAME=”value set name”

8 - Profile Options
FNDLOAD apps/apps@seed115 O Y DOWNLOAD $FND_TOP/patch/115/import/afscprof.lct file_name.ldt PROFILE PROFILE_NAME=”profile option” APPLICATION_SHORT_NAME=”prod”

9 - Requset Group
FNDLOAD apps/apps@seed115 O Y DOWNLOAD $FND_TOP/patch/115/import/afcpreqg.lct file_name.ldt REQUEST_GROUP REQUEST_GROUP_NAME=”request group” APPLICATION_SHORT_NAME=”prod”

10 - Request Sets
FNDLOAD apps/apps@seed115 O Y DOWNLOAD $FND_TOP/patch/115/import/afcprset.lct file_name.ldt REQ_SET APPLICATION_SHORT_NAME=”prod” REQUEST_SET_NAME=”request set”

11 - Responsibilities
FNDLOAD apps/apps@seed115 O Y DOWNLOAD $FND_TOP/patch/115/import/afscursp.lct file_name.ldt FND_RESPONSIBILITY RESP_KEY=”responsibility

12 - Menus
FNDLOAD apps/apps@seed115 O Y DOWNLOAD $FND_TOP/patch/115/import/afsload.lct file_name.ldt MENU MENU_NAME=”menu_name”

13 – Forms/Functions
FNDLOAD apps/apps@seed115 0 Y DOWNLOAD $FND_TOP/patch/115/import/affrmcus.lct file_name.ldt FND_FORM_CUSTOM_RULES The Upload syntax for all styles: FNDLOAD apps/apps@seed115 0 Y UPLOAD $FND_TOP/patch/115/import/affrmcus.lct file_name.ldt

14. User/Responsibilities
FNDLOAD apps/apps@seed115 0 Y DOWNLOAD @FND:patch/115/import/afscursp.lct file_name.ldt FND_USER Then UPLOAD FNDLOAD apps/apps@seed115 0 Y UPLOAD [UPLOAD_PARTIAL] @FND:patch/115/import/afscursp.lct file_name.ldt FND_USER []


Flexfields in Order Entry/Shipping

Depending on your system's setup, Oracle Order Entry/Shipping may use some or all of the following key flexfields provided by other Oracle products. Order Entry/Shipping also provides the Pricing Attributes descriptive flexfield to capture information specific to product pricing.

Key Flexfields
1. Accounting (Oracle General Ledger): Defining your Accounting key flexfield is part of setting up your sets of books.
2. Item Catalogs (Oracle Inventory): If you make entries for items in a standard industry catalog or if you want to group items according to certain descriptive elements, you need to configure this flexfield. Even if you do not use item cataloguing, you must enable at least one segment of this flexfield and compile it before you define your items.
3. Item Categories (Oracle Inventory): You must set up this flexfield before you define items because all items must be assigned to categories.
4. Sales Orders (Oracle Inventory):Use the Sales Orders key flexfield to differentiate sales order transactions that Order Entry/Shipping interfaces to Oracle Inventory. You must define this flexfield before placing demand or reservations in Order Entry/Shipping. The profile option OE: Source Code defaults the source code you use in the third flexfield segment.
5. Sales Tax Location (Oracle Receivables): Use this flexfield to charge your customers for tax based on their shipping addresses.
6. Stock Locators (Oracle Inventory): If you want to track items by a specific aisle or row, use this key flexfield to capture additional information about inventory stock locators. If you use this flexfield, you must set the OE: Inventory Stock Location profile option.
7. System Items (Oracle Inventory): Before you define items, set up this flexfield in order to record and report item information. The OE: Item Flexfield profile option needs to be set.
8. Territory (Oracle Receivables): The Territory flexfield can be associated with salespeople, invoices, and customer site addresses. Use it to record and report territory information.

Descriptive Flexfields
1. Pricing Attributes (Oracle Order Entry/Shipping): Pricing attributes modify an item's price without requiring that you create a new item. For example, you sell computer software and the price of the software is different depending on the number of users. You define a pricing attribute called 'Number Of Users'. When you enter an order line, the Pricing Attributes flexfield opens a window to capture the number of users. Oracle Order Entry/Shipping uses this information along with the item and unit of measure to derive the item list price.
The Pricing Attributes descriptive flexfield contains 15 user-definable flexfield segments to be used as pricing attributes. Once defined, the attributes can be used in the lines block of the Sales Orders window, the Line Options window, the Shipment Schedules window, the lines block of the Price Lists window, and the Item Groups window in Oracle Order Entry/Shipping; and in the Services and Renew Service windows in Oracle Service.
2. Delivery Line (Oracle Order Entry/Shipping): The Delivery Line descriptive flexfield, which is available on the Ship Confirm Delivery Special menu, displays a window that you create in which you can define additional delivery line information. The Delivery Line descriptive flexfield contains 20 user-definable flexfield segments to be used as delivery line attributes.
3. Industry Information (Oracle Release Management): If your system includes Oracle Release Management, you can use this flexfield to record industry-specific data for an order line.

Order Entry/Shipping

Order Entry/Shipping Setup

Order Entry/Shipping provides several features that enable you to set up your system and begin processing order information. You must define business policies, such as how you classify your orders, as well as various control features.

Step 1 Flexfields
Define key and descriptive flexfields to capture additional information about orders and transactions. Flexfields in Order Entry/Shipping.

Step 2 Inventory Organizations
Define inventory organizations (warehouses), organization parameters, subinventories, and picking rules in Oracle Inventory. Overview of Inventory Structure and Defining Picking Rules.

You must define at least one item validation organization and at least one organization that acts as an inventory source for orders fulfilled internally. If you plan to drop ship some orders, you must also define at least one logical organization for receiving purposes. Your item validation organization can be the same as your inventory source or your logical receiving organization, but you cannot use one organization for all three purposes. See: Drop-ship Order Flow.

Step 3 Profile Options
Define profile options to specify certain implementation parameters, processing options, and system options. Order Entry/Shipping Profile Options.

Step 4 Invoicing
Define Receivables invoicing information, including payment terms, invoicing and accounting rules, transaction types, AutoAccounting parameters, territories, and invoice sources.

Payment Terms,

Invoices with Rules,

Transaction Types,


Territories, and Invoice Batch Sources.

Step 5 Salespersons
Define information on your sales representatives. Salespersons.

Step 6 Tax
Define tax features, such as codes, rates, exceptions, and exemptions. Overview of Tax.

Step 7 QuickCodes
Define QuickCodes that provide custom values for many lists of values used throughout Order Entry/Shipping. Defining Order Entry/Shipping QuickCodes.

Step 8 Freight Charges and Carriers
Define freight charges and freight carriers to specify on orders. Defining Freight Charges and Defining Freight Carriers.

Step 9 Order Cycles
Define order processing flows to meet different order type requirements. Defining Cycle Actions, Defining Cycle Results, Assigning Cycle Action Results, and Defining Order Cycles.

Step 10 Order Number Sources
Define order number sources for automatic numbering of orders. Defining Order Number Sources.

Step 11 OrderImport Sources
Define sources for importing orders into Order Entry/Shipping. Defining OrderImport Sources.

Step 12 Security Rules
Define security rules to prevent users from adding, updating, deleting, and cancelling order or return information beyond certain points in your order cycles. Use the rules Order Entry/Shipping provides, which prevent data integrity violations, or create your own. Defining Security Rules.

Step 13 Units of Measure
Define the units of measure in which you supply items. Defining Units of Measure.

Step 14 Item Information
Define item information, including item attribute controls, categories, and statuses. Defining Item Attribute Controls, Defining Categories, and Defining Item Status Codes.

Step 15 Items
Define the items that you sell, as well as container items. Overview of Item Setup and Control.

Step 16 Configurations
Define the configurations that you sell. Creating a Bill of Material.

Note: Before you set up configurations, define the OE: Included Item Freeze Method profile option. Oracle Order Entry/Shipping Profile Options.

Step 17 Pricing
Define price lists for each combination of item and unit of measure that you sell. Optionally, you can define pricing rules and parameters to add flexibility. Overview of Pricing and Enabling Parameters.

Step 18 Customer Classes
Define customer profile classes. Defining Customer Profile Classes.

Step 19 Customers
Define information on your customers. Entering Customers.

Step 20 Agreements
Define binding or non-binding customer agreements. You can assign pricing, accounting, invoicing, and payment terms to each agreement. Customer Agreements.

Step 21 Standard Value Rule Sets
Define standard value (defaulting) rules for order information to help you enter orders quickly and accurately. Defining Standard Value Rule Sets.

Step 22 Order Types
Define order types to classify orders and returns. For each order type, you can assign a default price list, standard value rule set, approval actions, payment terms, and freight terms. Defining Order Types.

Step 23 Discounts
Define discounts to allow price adjustments based on customer agreements, order types, purchase order numbers, specific products, or specific customers. Before you define discounts, enable your Pricing Attributes descriptive flexfield in the Enable Parameters window. Discounts.

Step 24 Credit Checking
Define your credit checking rules. Automatic Credit Checking of Orders, Defining Credit Check Rules, and Defining Sales Credit Types.

Step 25 Holds
Define automatic holds to apply to orders and returns. Defining Holds.

Step 26 Notes
Define standard documents to attach automatically to orders and returns. Defining Note Categories and Defining Notes in Advance.

Step 27 Shipping Documents
Define groups of shipping documents that print automatically to specified printers when you confirm shipments. Choosing Printers for Shipping Documents and Defining Document Sets.
Step 28 Release Sequence Rules
Define the order in which picking lines are released. Defining Release Sequence Rules.

Step 29 Release Rules
Define and save picking criteria that can be used when running Pick Release. Creating Release Rules.

Step 30 Pick Slip Grouping Rules
Define grouping rules to determine how released picking lines are grouped onto pick slips. Defining Pick Slip Grouping Rules.

Step 31 Container-Load Relationships
Define the relationship between container items and load items to specify which items can be contained within other items. Defining Container-Load Relationships.

Step 32 Shipping Parameters
Define default Shipping parameters. Defining Shipping Parameters.


Accounting For Oracle Receivables

Flow of Accounting Information:
- If you are using Oracle Order Entry (without customizations), no accounting information is available until you run AutoInvoice. You pass the transactions to Oracle Receivables using the Receivables Interface. You then run AutoInvoice which creates the actual transactions and uses AutoAccounting to derive the segment values for the GL Accounts. If you are using Oracle Projects the account segment values are derived by a Projects’ process also called AutoAccounting and passed as values to Oracle Receivables via the Streamline process, also using AutoInvoice.

- Whether you are manually entering your receipts or processing them through AutoLockbox, the accounting information is automatically determined by Oracle Receivables when you create and apply the receipts (not when it is still a "QuickCash" batch). The values used are based on the setup values for the bank where the receipts were deposited and the invoices they are paying.

General Ledger Interface:
- You pass accounting information from Oracle Receivables to Oracle General Ledger using the General Ledger Interface. If you have properly set up Oracle Receivables, you should never have to create manual journal entries in your General Ledger and the two systems should always be in sync.

- When you invoke the General Ledger Interface process, you initiate multiple programs that:
Finds all of the records for the period you specified that have not yet been passed to the General Ledger;
1. Determines if the debits equal the credits;
2. Passes the data to GL for editing; and
3. Marks the records as having been passed (so they will not pass twice).

- If you have specified that you want the Journal Import to also run, this process verifies that the individual segments and combinations of segments are valid. Only when the Journal Import completes successfully are the Journals available for posting.

1. Always run the General Ledger Interface using the starting date of the period through the last day of the period. This is applicable no matter when you are running the process or if you know you will never have activity for that date, since sometimes the system uses dates other than the dates you expect.
2. Depending on which patches you have applied, you may or may not see the Unposted Items Report. If this report does run, always check each page to ensure that you have no items that could not be passed to the General Ledger. If anything besides headings appears, work with your IT department to resolve (since this is usually caused by a bug).
Verify that the amounts in the General Ledger Interface Report are reasonable and that the debits equal the credits.
3. Verify that the Journal Import has a status of "SUCCESS." If not, you had a problem that will need to be resolved or none of the items in the batch will be available for posting. Generally you have a problem if an account was valid when the activity was created, as you know, you cannot save with invalid values but, someone has since disabled either a segment or the combination. An example of this is your Accounts Receivable account that may have been valid when the invoice was originally created but it is not longer valid, and a receipt was just applied against it. When you apply a receipt to an invoice it always causes an offsetting entry against the original Accounts Receivable account.
Should this occur, then
1. Re-enable the segment or combination;
2. Re-run the Journal Import (in GL -- be sure to include the applicable id);
3. Create a manual journal entry (also in GL) to move the activity from the bad account to the proper account (this is my one exception to never creating manual journal entries); and
4. Re-disable the segment or combination.
By making the corrections in this way you are able to keep your GL in sync with your AR activity and you have an audit trial of what you did to make the correction. You have the option to correct in the Import Corrections form (in GL), but you lose the audit trail of what you did and why. Note what you did and why and storing the notes in a handy binder so you will be prepared when the auditors ask why you did what you did.

Journal Entries Reports: The Journal Entries reports are the best way to verify the actual accounting for Oracle Receivables’ activities and the only way to view the accounting for the foreign currency gains and losses. There are actually four reports that give you varying levels of details regarding the journal entries you will be creating or have already created. These reports may be run at anytime before or after you run the General Ledger Interface. Your options are: Detail by Account (very large), Summary by Account, Detail by Category (also large) and Summary by Category.

Tip: Run the Summary by Category and review to insure that there are no invalid or illogical accounts, prior to running the General Ledger Interface. If you find funny accounts, you can correct or create offsetting entries prior to posting. Run the Detail by Category (just for that category and account) to see which specific activities used the funny account. Correct the activity if possible. If not possible (i.e., adjustment), create an offsetting entry using the proper account.
Tip: If you run this report for Unposted Items only, you must leave the Posted Date range blank or nothing will appear on the report.

Period Close Procedures:

Tip:Never have more than one AR period open at one time. There have been problems with entries appearing partially in one period and partially in another. Also, you may accidentally enter activities in a period other than the period you intended.
Create a checklist to insure that you always know where you are and what you have to do next, so you will not forget anything.
Balance your AR activity to the Aging:

Old Aging Balance -----(Aged Trial Balance - 7 Buckets by Account)
+ New Invoices -------Transaction Register
+ Debit Memos ------- Transaction Register
+ Chargebacks --------Transaction Register
- Credit Memos ------ Transaction Register
- Receipts Applied ---- Unapplied Receipts Register
+/- Adjustments ------Adjustment Register
- Items Not Aged ----- Invoice Exceptions Report
New Aging Balance --- Aged Trial Balance - 7 Buckets by Account

Also balance your AR activity to your GL activity using the Journal Entries Report - Summary by Category and the Account Analysis report (in GL). Note any manual journal entries that used "your" accounts.

Accounting Details
The GL Accounts may or may not appear on the form (depending on what you are doing) but almost every activity you perform has an accounting impact. In order to understand this impact it is necessary to know:
1) what accounts are impacted by each transaction;
2) what are the related set ups;
3) what you may change and/or override and what is out of your control.

AutoAccounting : AutoAccounting a very powerful setup feature that tells Oracle Receivables how to determine the individual segment values for your Transactions (invoices, debit memos, credit memos, chargebacks and commitments) using the rules that you specify. You may use this feature when creating Transactions manually or through AutoInvoice. The types of accounts impacted by AutoAccounting include:
- (Accounts) Receivable
- Revenue
- Tax
- Freight
- Unearned Revenue (for deferred revenue recognition)
- Unbilled Receivable (for deferred receivables recognition)
- AutoInvoice Clearing (for problems with extended amount)
- Possible sources of this information are the values you set up for the following:
- Transaction Types
- Salesreps
- Standard Lines (Items or Memo Lines)
- Taxes
- And/or hard coded values.

You may get one segment value for one type of account from a different place than for another. See Appendix 1 for an example of a typical AutoAccounting setup.
You can use a similar worksheet to test the setup of your AutoAccounting rules. List your Accounting Flexfield segments in the left column. For each type of account select the source of each segment (based on the list of available sources) and fill in that box. Test your theory by listing what all the setup accounts would be for a Transaction Type, Salesrep, Item, Tax and Memo Line. Then use a white-board and fill in each segment, for each type of account, with the values from each of the related sources. Verify that the combinations are actually valid, if not, redesign how they will be set up or redefine your AutoAccounting rules. Once you are satisfied with the results, enter your AutoAccounting rules into your test system and start creating manual invoices. Verify that you have not created invalid account values as the defaults.
Tip: I prefer to assign all segments to sources versus using hard coded values. This seems more flexible for future changes.

Invoices: When you create an invoice either through AutoInvoice or manually, you take advantage of AutoAccounting to provide the default Accounting Flexfield values. For manual invoices you have the option to override the default values.
For a standard Invoice:
DR : AR (AutoAccounting - may override)
CR : Revenue (AutoAccounting - may override)
:Tax (AutoAccounting - may override)
:Freight (AutoAccounting - may override)

You may also create invoices with special accounting and invoicing rules that allow you to defer revenue recognition for the percentage and number of periods that you specify. The following is an example of an invoice created with deferred revenue recognition for $12,000 split evenly over 12 periods:

For invoices with deferred revenue: a) When first created:
DR : AR (AutoAccounting - may override) 12000
CR :Unearned Revenue (AutoAccounting) 1000
DR : Unearned Revenue (AutoAccounting) 12000
CR : Revenue (AutoAccounting - may override) 1000

b) For each of the next 11 periods:
DR : Unearned Revenue (AutoAccounting) 1000
CR : Revenue (AutoAccounting) 1000

If you are using deferred revenue recognition, you need to run the revenue recognition process for each period (Run Revenue Recognition) and runs automatically as part of the General Ledger Interface.

Tip: To reduce the time it takes to close the period, run Revenue Recognition prior to the time when you are actually closing (e.g., the night before the close). This will process the majority of the updates prior to the actual close.
Recurring Invoices (Transaction Copy) are treated like regular invoices, except they have different GL dates. Once you have created an invoice copy, it really is just another invoice with different dates.

Debit Memos: Debit memos work just like standard invoices (you even create them on the same forms) -- taking advantage of AutoAccounting but with overridable segments. If you defined Memo Lines for use with your debit memos, they will provide the default accounting segments if you have set up AutoAccounting to use Standard Lines values for your Revenue accounts.

Credit Memos And On Account Credits: There are two types of credit memos: credit memos that you create to offset an individual invoice are called "Credit Memos." Credit memos that impact a customer’s account but are not initially tied to a specific invoice are called "On-Account Credits." On-account credits may be tied to invoice(s) using the Receipts Applications window, at any time. The accounting for Credit Memos usually offsets the applicable accounts from the original invoice (if you set your System Profile option AR: Use Invoice Account For Credit Memo to "Yes"). Credit memos and on-account credits that are created using AutoInvoice take advantage of AutoAccounting and/or hard coded values. You may override the default values if you are entering manually.

Credit Memo tied to an invoice:
DR : Revenue (from the related invoice - may override)
: AR (from the related invoice - may override)
: Tax (from the related invoice - may override)
CR : Freight (from the related invoice - may override)

On-account credits take advantage of AutoAccounting and Standard Lines (Memo Lines) depending on how you set up your AutoAccounting rules for the default credit and debit GL Accounts. You may override the default values at entry time if you are entering manually.

DR : Revenue (Memo Line - may override)
CR : AR (AutoAccounting - may override)

When you apply an on-account credit to invoice(s), you debit the credit account you used when you created the on-account credit. The Accounts Receivable account for the invoice being offset is credited. You may not override these values.
DR : AR (from the On-Account Credit)
CR : AR (from the invoice)

Cash Receipts (Excluding Miscellaneous Receipts): The accounting for receipts, except for Miscellaneous Receipts, is totally controlled behind the scenes by Oracle Receivables. The GL Accounts are determined by the values you defined in Receipt Class for the batch.
NOTE: You have one Cash, Unapplied, On-Account, Unidentified, Earned Discount and Unearned Discount account for each bank and class, which does not allow you to split the Unapplied, etc. accounts for the applicable cost center or division.
You may set up different values for each bank and class that you use (especially important for the cash account). Or, you may share the GL Accounts for multiple bank accounts (i.e., the unapplied and discount accounts). The key accounts are:
- Your cash account (the default debit account for that bank account);

Tip: Often AP and AR share the same bank account but it is helpful to use a different but sequential GL account for each. This eases the reconciliation but you can roll together for FSG reporting.
- Your unapplied payments account (the default used until you match the payment to an invoice);
- Your on-account account (used to account for pre-payments until you apply them to invoice(s));
- Your unidentified account (used for receipts where you do not know which customer sent the receipt);
Tip: Often companies use the same GL Account for unapplied, on-account and unidentified. This is fine as long as: the account is not used for anything else and it is not an Accounts Receivable or cash account.
- Your earned and unearned discount accounts (used when a client pays invoices in accordance with the early payment terms. These are also often the same. Earned discounts are for payments made within the discount terms, unearned discounts are paid after the discount term but are allowed anyway.

When you match a receipt to an invoice, the cash account (debit) defaults from the Receipt Class for the Receipt batch. The Accounts Receivable account (credit) defaults from the invoice that is being paid.
NOTE: Even if you instantly match a payment to an open invoice, Oracle still creates credits and debits to the unapplied account.

Payment applied to an invoice without discount terms:
DR : Cash (Receipt Class)
: Unapplied (Receipt Class)
CR : Unapplied (Receipt Class)
: AR (from the invoice)

Payment applied to an invoice with discount terms:
DR : Cash (Receipt Class)
: Unapplied (Receipt Class)
: Discount (Receipt Class)
CR : Unapplied (Receipt Class)
: AR (from the invoice)

When you leave a receipt as unapplied:
DR : Cash (Receipt Class)
CR : Unapplied (Receipt Class)

When you identify a receipt is as a pre-payment or deposit:
DR : Cash (Receipt Class)
CR : On-Account (Receipt Class)

For unidentified receipts:
DR : Cash (Receipt Class)
CR : Unidentified (Receipt Class)

When you apply unapplied, on-account or unidentified receipts, the accounting is determined by the original status. The accounts used are based on the accounts you currently are using for the Receipt Class. The Accounts Receivable account still comes from the invoice.
DR : Unapplied (Receipt Class)
On-Account (Receipt Class)
or Unidentified (Receipt Class)
CR : AR (from the invoice)

When you unapply a receipt, the accounting is just the opposite of the application accounting. You debit the AR account for the original invoice and credit the unapplied account based on the current unapplied account for the Receipt Class:
DR : AR (from the invoice)
CR : Unapplied (Receipt Class)

When you reverse a receipt, you have two possible options: re-open the invoices you previously paid or create a debit memo for the amount of the reversed payment. If you re-open the invoices, the system offsets the accounts used when you originally applied the payment (from the invoice and the cash account). Note that this process also impacts the unapplied account.

DR : Unapplied (Receipt Class)
: AR (from the invoice)
CR : Cash (Receipt Class)
: Unapplied (Receipt Class)

If you create a debit memo, you credit the original cash account but debit the Accounts Receivable Account for the Debit Memo type you selected. You may override the Accounts Receivable account when you enter the payment reversal.
DR : AR (Transaction Type - may override)
CR : Cash (Receipt Class)

Chargebacks: You create Chargebacks when you are applying cash to close the original invoice and create a new invoice for the amount that the customer short paid. By definition, there is a one to one relationship between a Chargeback and the original invoice. You need to set up values for Chargebacks in 3 places: Receivables Activity where you specify the "wash" account used when creating a Chargeback. Transaction Types where you specify the default AR account. A Memo Line ("Chargeback Line") is seeded by Oracle but it is just used for the line description when you print the Chargeback and has no accounting impact. The Accounts Receivable account for the new invoice is based on the Accounts Receivable account for the Chargeback but you may override it at entry item. Oracle credits the Accounts Receivable account for the original invoice (note that these two accounts may be different).

In the Category of Adjustment:
DR : Chargeback Adjustment (Receivables Activity)
CR :

In the Category of Adjustment (AR):
DR :
CR : AR (from the original invoice)

In the Category of Chargeback:
DR :
CR : Chargeback Adjustment (Receivables Activity)

In the Category of Chargeback (AR):
DR : AR (from the chargeback - you may override)
CR :

In the Category of Trade Receipts:
DR : Cash (Receipt Class)
CR :

In the Category of Trade Receipts (AR):
DR : Unapplied (Receipt Class)
CR : AR (from the original invoice)
: Unapplied (Receipt Class)

Miscellaneous Receipts: Miscellaneous Receipts are any receipts that are not for open receivables. Examples include Cobra payments, T-shirt sales, utility refunds, and returns on investments. Due to the nature of this activity, you may need to credit any account within the chart of accounts. The Distribution Window in the Receipts form allows you to do just that. You may run into an Account Security Rule set up to restrict usage of accounts by application. If you find that you may not use an account that you need, work with your System Administrator to change the Account Security Rules.
You may pre-define the credit accounts that you usually use to speed entry (using Receivables Activity) but you also have the flexibility to override the values at entry time. You also have the ability to split a single receipt into multiple accounts (you may also pre-define those accounts using Distribution Sets).
If you will always be splitting the accounts, you should define a Distribution Set. A distribution set is a name and one or more GL Accounts and percentages that you define. You must create a Receivable Activity that refers to the Distribution Set.
When you enter Miscellaneous Receipts, you refer to the Receivables Activities that you defined above. However, you may override the default GL Accounts, the individual segments, the percentages and/or the amounts. The cash account used defaults based on the Receipt Class for the bank you specified on the Batch Screen, and you may not override or view the value.

DR : Cash (Receipt Class)
CR : Miscellaneous Account(s) (Receivables Activity or Distribution Set - may override)

Receivable Adjustments: Receivable Adjustments are generally write-offs, or changes to the invoice balance due for over- or under-payment by the customer, or the addition of finance charges. Pre-define commonly used adjustment types using the Receivables Activity form. This speeds entry, but you may override the default values as you enter the adjustments. NOTE: Always define a GL Account and not a Distribution Set when you define Receivable Activities for adjustments.

Tip: When entering an adjustment, never use an Accounts Receivable Account. Oracle Receivables already automatically offsets the AR account for the invoice being adjusted and you will create a wash entry.

A Receivables Adjustment is always applied to a specific invoice so it impacts the Accounts Receivable account for that invoice. Receivables adjustments may either be positive (debit AR, and increase the invoice balance) or negative (credit AR and decrease the invoice balance). Examples include:

Add a finance charge (note that this is a positive adjustment that increases the balance due):
DR : AR (from the invoice)
CR : Finance Charges (Receivables Activity - may override)

Reduce the freight amount:
DR : Freight (Receivables Activity - may override)
CR : AR (from the invoice)

Write-off the invoice balance:
DR : Cost of Doing Business (Receivables Activity - may override)
CR : AR (from the invoice)

You may use AutoAdjustments to perform mass cleanup of open invoices and on-account credits. The Accounts Receivable account credited is the Accounts Receivable account for the transaction. The account debited is based on the Receivables Activity you select when you submit the AutoAdjustment process. Note that ALL adjustments made during this process will use that exact same "write off" account even if the original invoices are for different companies, or cost centers. This may be a consideration in determining if you can actually utilize AutoAdjustments, or if you want to run multiple passes of AutoAdjustment by Transaction Type and Adjustment Activity.

Foreign Currency Gains and Losses: Transactions that are not in your base currency may cause gains or losses to occur due to fluctuations in the exchange rates. This is automatically accounted for by Oracle Receivables. When you enter the Transaction, the applicable exchange rate for the date you enter it is stored with the transaction. When you enter the related receipt the applicable exchange rate for the date you enter the receipt is stored with the receipt. The gain or loss is determined based on the difference in the value of the money (in your base currency) between when the invoice was created and when the receipt was created. The gain and loss accounts are derived based on the values in your System Options and how you set up Flexbuilder. Note that most companies use the default setup for Flexbuilder. Note that there is no gain or loss if you apply an adjustment since both the adjustment and the invoice use the same rate. You can predict Gains and Losses using the Projected Gains/Losses Report. You can only view the gain/loss accounting activity by running the Journal Entries Report.

Gain - now worth more:
DR : Cash (Receipt Class at the receipt rate)
: Unapplied (Receipt Class at the receipt rate)
CR : AR (from the invoice at the invoice rate)
: Unapplied (Receipt Class at the receipt rate)
: Gain (System Options - difference between the invoice and receipt values)

Loss - now worth less:
DR : Cash (Receipt Class at the receipt rate)
: Unapplied (Receipt Class at the receipt rate)
: Loss (System Options - difference between the invoice and receipt values)
CR : AR (from the invoice at the invoice rate)
:Unapplied (Receipt Class at the receipt rate)


Exam: 1Z0-200 - [7]

Daily Business Intelligence (DBI)

- Out-of-the-box reporting and analysis application that enables senior managers and executives to see relevant, accurate and timely information using self-service overview pages.
- DBI overview page is designed for a particular functional, management responsibility. Managers can drill down from the summarized information on each page to detailed reports or to specific transactions in underlying applications, e.g. the Profit and Loss page is designed for a profit centre manager. his page summarizes profit and loss information using the Revenue, Expenses and Operating margin KPIs.
- DBI architecture simplifies the reporting process and ensures the managers are looking the most accurate and up-to-date data.
- DBI only updates the data that has changes since the last refresh.

Overview Page: An overview page is designed to meet the needs of a particular responsibility.
Responsibilty: Is designed for a particular business function or user such as Expense Manager.
Region: A region is a unique set of information on a page.
5 types of regions in DBI are:
1. Table,
2. Graph,
3. Parameter,
4. KPI, and
5. Links
KPI: A KPI is a business metric used for reporting such as Revenue or Operating margin. Managers can use KPIs to compare and judge their performance.

* DBI setup steps need to be performed before using an overview page.
- DBI provides cross-enterprise functionality that is not available as part of standard Oracle reports.

Technical Componets of DBI-

1. Single Oracle Instance: DBI resides in a single instance, which is same as transactional instance. Which reduces the need for a separate maintenance and administration team and optimize reporting performance.
- Materialized views and incremental refresh capabilities enable DBI to summarize a large amount of data efficietly.

2. E-Business Suite Tables: Changes in E-Business suite tables are reflected in DBI whenever incremental request set is run.

3. Base Summary tables and Materialized Views: Used to store summarized DBI data thats serve as the source of the data on each page.

4. Metadata: Used to define the complex relationship between the dimensions, responsibilities, menus, request sets, KPIs, pages, and reports. Metadata is predefined and can not be modified.

5. Rendering technology: Used to render the pages based on the data that is defined in the base summaries, materialized views, and the metadata layer.

6. Request Set generator: Enables to create initial and incremental request sets for each page using the definitions in the metadata layer. The generated request sets include all of the concurrent programs that you need to load or refresh a page.

Common Dimensions:
- A dimension defines a hierarchical relationship between data. YOu can use dimesions to view data at different level of details.
- Dimensions can be either flat or recursive.
1. Flat Dimension: Can be hierarchical but does not display the hierarchy between items.
2, Recursive Hierarchy: Displays a hierarchy between items.
- Each page has a dimesion that is considered the primary dimension. It determines which values are compared in the KPI region.
- Common DBI dimensions are:
1. Currency Dimension
2. Organization Dimension
3. Item Dimension
4. Person Dimension
5. Sales Group Dimension
6. Operating Unit Dimension
7. Time Dimension
8. Inventory Organization Dimension

1. Currency Dimension: Flat dimension that allows to see financial data across all organization units in a common currency. This dimension is populated based on the currencies and daily exchange rates that are defined in Oracle General Ledger.

2. Organization Dimension: Flat dimension that defines the hierarchical relationship between organizations in an enterprise.

Exam: 1Z0-200 - [1]

Overview of 11i E-Business Suite

Multi-tiered distributed computing- various servers distributed among multiple levels, or tiers.

Server: A process or a group of processes that run on a single machine and provide a particular functionality.

Tier: A logical grouping of services, spread across more than one physical machine.
- Database Tier: Supports and manages Oracle database.
- Application Tier: Manages various application components.
- Desktop Tier: Provides user interface via add-on components to a standard web browser e.g. JInitiator or a Java Applet.

- Nodes work closely together in a cluster. Each tier may consists of one or more nodes and each node can potentially accomdate more than one tier. This may be done for simplicity of administration or to maximise performance by reducing network traffic.

Form-based Desktop Tier:
- Single point of access.
- Forms client applet + Oracle JInitiator.
- Forms Client Applet: Presentation applet that supports all form-based products. It is a collection of JAR files, contains all Java classes required to run the presentation layer of Oracle Application Forms.
- Oracle JInitiator: Forms Client Applet must run within JVM or Desktop client. Instead of using browser's JVM, JInitiator component allows use of Oracle JVM. JInitiator is used as a ActiveX component on Windows machine.
- JInitiator is only invoked when a user choose access functions that require it, e.g. running a form.
- Form Client Applet and commonly used JAR files are downloaded from the web server at the beginning of client's first session. Less commonly JAR files are downloaded as needed. Downloaded JAR files are locally cached for future sessions which eliminates network traffic.
- All updates to JAR files are installed on Application tier and downloaded to the client automatically.
- Select "Show Console" on "Basic" JInitiator tab, to see downloading of JAR files.

Application Tier:
- Manage communication between desktop tier and database server.
- Hosts various servers that process the business logic.
- Oracle 9iAS provides technology used on the application tier, Six servers comprises the application tier for Oracle Applications-
1. Web Server
2. Forms Server
3. Reports Server
4. Discoverer Server ( optional)
5. Concurrent Processing Server
6. Admin Server

Load Balancing: Application tier supports load balancing among many of its servers.
- Load Balancing provides higher availability, fault tolerance, reliablity and optimum scalability.
- Load Balancing is typically used to spread the load accross multiple web servers where load may vary significantly.

Web Server: Oracle HTTP Server (Appache), additional components are-
- Web Listener
- Java Servlet Engine
- Java Server Page (JSP)

- Web Listener accepts HTTP requests for particular URLs.
- If possible, web server services the request itself, if page referenced by the URL needs advanced processing, Listener passes the request to servlet engine which contacts database server as needed.

Self-Service Applications ( HTML- Based):
- Do not use Oracle Forms for interface.
- Pages designed in JavaScript and pure HTML.
- Dynamically generates HTML by executing Java code.
- Use Metadata dictionary for flexible layout.
- OAF(Oracle Application Framework) is development plateform for HTML-based applications.

Components of OAF are-

1. BC4J(Business Component for Java): BC4J is included in Oracle JDeveloper and used to create Java business components for representing business logic. Also provides mechanism for mapping relational tables to Java objects and allows separation of application business logic from user interface.

2. AOL/J: Supplies the security and provides OAF with its connection to database server and with application specific functionality e.g. Flexfields.

Java Servlet access with HTML based application-

1. User clicks a hyperlink of a function from browser.
2. Browser makes URL request to web listener.
3. Web Listener contacts JServ where it runs a JSP.
4. JSP obtains contents from application tables (through using MataData dictionary) to construct the HTML page.
5. Resulting HTML page is passed back to browser.

Forms Server:
- Oracle Application forms and associated run-time engine is hosted at form server.
- Mediates communication between desktop client and database server.
- Form server caches data and provides it to the client as needed.
- 3 protocols used by Form server-
1. Standard HTTP
2. Secure HTTPS

* Form server communicate with database server using Oracle Net

- Automatic load balancing among multiple form servers
- Metric server act as a single point of co-ordination for all form server requests.
- Metric is located on one application server. Metric clients, located on other application servers
periodically send load information to metric server.

Reports Server:
- Web Listener contacts the report server through reports Web CGI which allows the user to run reports and see output.
- Master Report server receives initial request and distribute it to one of the other report servers, depending upon the load each can handle.

Discoverer Server:
- An ad-hoc query, reporting analysis and publishing tool that allows user to gain immediate access to information from data marts, data warehouses and OLTP systems.
- Report builders and analysts can easily create, modify and execute ad-hoc queries and reports.
- Casual users can navigate through pre-defined reports and graphs via business views that hide complexity of underlying structures.
- Discoverer hides the complexity of database, presenting it through an intuitive, easy-to-understand interface.
- It complements the report server, allows user to perform projections based on possible changes.

Discoverer End User Layer:
- Key to provide ease of use to underlying data in Oracle Applications' database. It is a layer of metadata located in application database, separated from actual Applications' data.
- 3 components to access the End User Layer-
1. Discoverer Administrator Edition
2. Discoverer Plus
3. Discoverer Viewer

Concurrent Processing Server:
- Feature that allows non-interactive and potentially long runnig functions to be executed effeciently alongside interactive operations.
- To ensure that resource intensive concurrent processing operations do not interface with interactive operations, they can run on a specialised concurrent processing server.
- When a concurrent request is submitted, a row is inserted into a database table specifying the program to be run. A concurrent manager then reads requests from this table and starts associated concurrent program.

Concurrent Managers:
- Acts as a job scheduling and execution system.
- It is itself an executable registered as a program and

Exam: 1Z0-200 - [2]

Oracle Database Administration
  • Oracle Database Architecture
  • Oracle RAC - setup, troubleshooting & Migration
  • Backup and Recovery
  • Upgrades & Migrations
Oracle Database Performance Tuning

Oracle Database Cloud  
  • Oracle Cloud Architecture, ,DBaaS
  • Cloud Migration
Oracle Exadata
  • Architecture & Features
  • On Premise to Oracle on Cloud Migration
Oracle Database Security

Oracle GoldenGate


Fundamentals of Multi-Org

Fundamentals of Multi-Org

Fundamentals of Flexfields

Fundamentals of Flexfields

A flexfield is a field made up of sub-fields, or segments. A flexfield appears on your form as a pop-up window that contains a prompt for each segment. Each segment has a name and a set of valid values. There are two types of flexfields: key flexfields and descriptive flexfields.

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/2x14" 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-8x14-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. See: the Oracle General Ledger User's Guide.

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.
For example, consider the Additions form you use to define an asset in your Oracle Assets application. This form contains fields to capture the "normal" information about an asset, such as the type of asset and an asset number. However, the form does not contain specific fields for each detail about a given asset, such as amount of memory in a computer or lifting capacity of a forklift. In this case, having all the potentially-needed fields actually built into the form is not only difficult, it is undesirable. Because while one organization may have computers and forklifts as assets, another organization may have only computers and luxury automobiles (and no forklifts) as assets. If the form contained built-in fields for each attribute of a forklift, for example, an organization with no forklifts would find those fields to be both unnecessary and a nuisance because a user must skip them to enter information about another type of asset. In fact, fields for forklift information would be cumbersome whenever a user in any organization tries to enter any asset that is not a forklift.
Instead of trying to contain all possible fields for assets information, the Additions form has a descriptive flexfield that you can customize to capture just the information your organization needs about your assets. The flexfield structure can depend on the value of the Asset Category field and display only those fields (segments) that apply to the particular type of asset. For example, if the asset category were "desk, wood", your descriptive flexfield could prompt for style, size and wood type. If the asset category were "computer, hardware", your flexfield could prompt for CPU chip and memory size. You can even add to the descriptive flexfield later as you acquire new categories of assets.
The Enter Journals window in the Oracle General Ledger applications is another example of a form that includes descriptive flexfields to allow organizations to capture additional information of their own choosing. Each block contains a descriptive flexfield as its last field. You might use these to store additional information about each journal entry, such as a source document number or the name of the person who prepared the entry.

Benefits of Flexfields: Flexfields provide you with the features you need to satisfy the following business needs:
1. Customize your applications to conform to your current business practice for accounting codes, product codes, and other codes.
2. Customize your applications to capture data that would not otherwise be tracked by your application.
3. Have "intelligent fields" that are fields comprised of one or more segments, where each segment has both a value and a meaning.
4. Rely upon your application to validate the values and the combination of values that you enter in intelligent fields.
5. Have the structure of an intelligent field change depending on data in your form or application data.
6. Customize data fields to your meet your business needs without programming.
7. Query intelligent fields for very specific information.

What is the distinction between flexfields and application features?
Flexfields, while they are a major feature of the Oracle Applications as a whole, are merely a mechanism to provide many application features. Key flexfields provide a flexible way for the Oracle Applications to represent objects such as accounting codes, part numbers, job descriptions, and more. For example, the Accounting Flexfield is a feature that uses a key flexfield to represent accounting codes throughout most of the Oracle Applications. Similarly, descriptive flexfields provide a flexible way for the Oracle Applications to provide customizable "expansion space" in forms, as well as a way to implement context-sensitive fields that appear only when needed. Both types of flexfield let you customize Oracle Applications features without programming.

Basic Flexfields Concepts

- A segment is a single sub-field within a flexfield. You define the appearance and meaning of individual segments when customizing a flexfield. A segment is represented in your database as a single table column.

- For a key flexfield, a segment usually describes a particular characteristic of the entity identified by the flexfield. For example, you can have a key flexfield that stores part numbers. The key flexfield can contain the part number PAD-YEL-NR-8 1/2x14, which represents a yellow, narrow ruled, 8 1/2" x 14" note pad. Each section in the part number, separated by a hyphen, describes a characteristic of the part. The first segment describes the object, a note pad, the second segment describes the color of the object, yellow, and so on.

- Note that we also refer to the fields in a descriptive flexfield pop-up window as segments even though they do not necessarily make up meaningful codes like the segments in key flexfields. However, they do often describe a particular characteristic of the entity identified elsewhere on the form you are using.

Values, Validation and Value Sets:
- Your end user enters a segment value into a segment while using an application. Generally, the flexfield validates each segment against a set of valid values (a "value set") that are usually predefined. To "validate a segment" means that the flexfield compares the value a user enters in the segment against the values in the value set for that segment.
- You can set up your flexfield so that it automatically validates segment values your end user enters against a table of valid values. If your end user enters an invalid segment value, a list of valid values appears automatically so that the user can choose a valid value.
- You can think of a value set as a "container" for your values. You choose what types of values can fit into your value set: their length, format, and so on.
- A segment is usually validated, and usually each segment in a given flexfield uses a different value set. You can assign a single value set to more than one segment, and you can even share value sets among different flexfields. For most value sets, when you enter values into a flexfield segment, you can enter only values that already exist in the value set assigned to the segment.

- A flexfield structure is a specific configuration of segments. If you add or remove segments, or rearrange the order of segments in a flexfield, you get a different structure.
- You can define multiple segment structures for the same flexfield (if that flexfield has been built to support more than one structure). Your flexfield can display different prompts and fields for different end users based on a data condition in your form or application data. Both key and descriptive flexfields may allow more than one structure.
- In some applications, different users may need a different arrangement of the segments in a flexfield (key or descriptive). Or, you might want different segments in a flexfield depending on, for example, the value of another form or database field.
- Your Oracle General Ledger application, for example, provides different Accounting Flexfield (Chart of Accounts) structures for users of different sets of books. The Oracle General Ledger application determines which flexfield structure to use based on the value of the GL Set of Books Name user profile option.

Planning Flexfields: Just as for implementing any new application, planning is by far the most important (and probably the most time-consuming) phase of implementing flexfields, so you should give it careful thought. The planning phase can be broken into smaller, though still interrelated, steps:
1. Decide which flexfields to implement
2. Learning about a specific flexfield
3. Planning the structure
4. Planning the segments
5. Planning the segment validation
6. Planning to use additional features
7. Documenting your plan

Suggestion: We recommend that you plan your flexfields as completely as possible, including your potential segment values, before you even begin to define them using Oracle Applications forms. Once you begin using your flexfields to acquire data, you cannot change them easily. Changing a flexfield for which you already have data may require a complex conversion process.

Decide which flexfields to implement: Oracle Applications products rely on some key flexfields as central parts of the applications, so you must set up these key flexfields. For example, while the Oracle General Ledger products use only the Accounting Flexfield key flexfield, almost every Oracle Applications product uses the Accounting Flexfield for some part of its processing. So, you must almost always set up the Accounting Flexfield, especially if you have more than one of the Oracle Applications at your site. In addition, many Oracle Applications products such as Oracle Inventory and Oracle Purchasing use the System Items Flexfield (Item Flexfield). Other Oracle Applications use various key flexfields for various purposes, and defining those flexfields is usually mandatory for a particular application.

- While most Oracle Applications products require that you set up particular key flexfields, many descriptive flexfields are optional. You need only set up optional descriptive flexfields for forms where you want to capture business data not otherwise captured by the form fields.

Learning about a specific flexfield: Because each key and descriptive flexfield has a different purpose, you should be sure to understand the purpose and requirements for the flexfield you want to define. Some flexfields, particularly the Accounting Flexfield, have restrictions on how you can define them. Most descriptive flexfields simply provide a certain number of segment columns you can use for whatever you need to fill your organization's needs.

- Defining your flexfield is easy once you have completed and documented your planning stage. You use Oracle Applications setup forms to define your flexfield.

Define your value sets: Depending on exactly how you want to validate your segments, you may spend 10-30 minutes defining each value set (roughly one value set per segment, or fewer if you plan to share value sets or do not plan to use value sets for certain segments).
Note that you do not define your actual values at this point; rather, you are simply defining the containers for your values.

Define your segment structures: This is the main part of defining a flexfield, and includes defining structure titles, segment prompts, segment order, and segment display sizes. Depending on the number of structures and segments you have, you may spend 20-90 minutes per flexfield.

Define your values, if necessary: Depending on exactly how you want to validate your segments, you may spend anywhere from 1-3 minutes defining each independent or dependent value in an Oracle Applications form. If you have legacy systems, you may need to build a program to import your legacy values into Oracle Applications tables.

Define additional features, if necessary: If you plan to use additional features such as cross-validation rules or flexfield value security, you define those additional features at this point.

Data Entry and Ongoing Maintenance: Data entry consists of using your applications for your day-to-day operations. For key flexfields, you may want to predefine the complete codes (combinations of segment values) you want to allow your users to enter.

- As your organization's needs change, you will need to perform ongoing maintenance of your flexfields. For example, you may need to define new flexfield structures or disable old structures. You may also need to add new values or cross-validation rules or value security rules.

Intelligent Key: An intelligent key is a code made up of sections, where one or more parts may have meaning. An intelligent key "code" uniquely identifies an object such as an account or a part or a job. Intelligent keys are useful in applications because they are usually easier for a user to remember and use than a unique number. For example, a part number of PAD-YEL-11x14 is much easier to remember than a unique part number of 57494. However, unique ID numbers are easier to maintain in a relational database application because only one column is required for the ID number, while multiple columns would be required for an intelligent key (one for each section or segment of the code). The Oracle Applications use key flexfields to represent intelligent keys with unique ID numbers. That is, an end user sees and works with an easy-to-remember intelligent key code, while the Oracle Applications only need to store a hidden unique ID number in most tables.

Attention: Throughout this guide we use the "Part Number Key Flexfield" in our examples and graphics. We use this example because it helps to illustrate the uses and behaviors of key flexfields without requiring any specialized accounting, human resources, or manufacturing knowledge. However, there is no actual "Part Number Key Flexfield" in the Oracle Applications, and you should not confuse it with the System Items Flexfield (Item Flexfield) used by many Oracle Applications products such as Oracle Inventory.

Combination: A combination is a particular complete code, or combination of segment values that makes up the code, that uniquely identifies an object. For example, each part number would be a single combination, and if you had ten parts you would define ten combinations. A valid combination is simply a combination that may currently be used (that is, it is not out of date or disabled).

- Note that many of the Oracle Applications products (and their documentation) do not necessarily refer to key flexfield combinations as "combinations". They may refer to combinations using the name of the entity or the key flexfield itself. For example, Oracle Assets uses a key flexfield called the "Asset Key Flexfield" and refers to one of its combinations as "an asset key" or "an asset key flexfield". In another example, Oracle General Ledger and other Oracle Applications products generally use the term "account" or "GL account" to refer to combinations of the Accounting Flexfield.

Combinations Table: Each key flexfield has one corresponding table, known as the combinations table, where the flexfield stores a list of the complete codes, with one column for each segment of the code, together with the corresponding unique ID number (a code combination ID number or CCID) for that code. Then, other tables in the application have a column that stores just the unique ID for the code. For example, if you have a part number code, such as PAD-YEL-11x14, the "Parts" combinations table stores that code along with its ID, 57494. If your application allows you to take orders for parts, you might then have an "Orders" table that stores orders for parts. That "Orders" table would contain a single column that contains the part ID, 57494, instead of several columns for the complete code PAD-YEL-11x14.

Flexfield Qualifier: A flexfield qualifier identifies a particular segment of a key flexfield.
Usually an application needs some method of identifying a particular segment for some application purpose such as security or computations. However, since the a key flexfield can be customized so that segments appear in any order with any prompts, the application needs a mechanism other than the segment name or segment order to use for segment identification. Flexfield qualifiers serve this purpose. You can think of a flexfield qualifier as an "identification tag" for a segment.

For example, your Oracle General Ledger product needs to be able to identify which segment in the Accounting Flexfield contains balancing information and which segment contains natural account information. Since you can customize the Accounting Flexfield so that segments appear in any order with any prompts, Oracle General Ledger needs the flexfield qualifier to determine which segment you are using for natural account information. When you define your Accounting Flexfield, you must specify which flexfield qualifiers apply to which segments.
Other applications, such as Oracle Human Resources, also use flexfield qualifiers. Oracle Human Resources uses flexfield qualifiers to control who has access to confidential information in flexfield segments.
A segment qualifier identifies a particular type of value in a single segment of a key flexfield. In the Oracle Applications, only the Accounting Flexfield uses segment qualifiers. You can think of a segment qualifier as an "identification tag" for a value. In the Accounting Flexfield, segment qualifiers can identify the account type for a natural account segment value, and determine whether detail posting or budgeting are allowed for a particular value.
It is easy to confuse the two types of qualifiers. You should think of a flexfield qualifier as something the whole flexfield uses to tag its pieces, and you can think of a segment qualifier as something the segment uses to tag its values.

Types of Key Flexfield Forms: Key flexfields appear on three different types of application form:
1. Combinations form
2. Foreign key form
3. Range form
These form types correspond to the types of tables that contain key flexfield data.

1. Combinations form: A combinations form is a form whose only purpose is to maintain key flexfield combinations. The base table of the form is the actual combinations table. This table is the entity table for the object (a part, or an item, an accounting code, and so on). The form contains hidden fields for each segment column in the table, as well as displayed fields for the concatenated segment values (the combination) and any other fields (and columns) that the entity requires. A combinations form is sometimes also called a maintenance form.

Foreign key form: A foreign key form is a form whose underlying base table contains only one or two columns that contain key flexfield information. The purpose of a foreign key form often has very little to do with the key flexfield itself, and that the key flexfield appears on the form is essentially incidental. For example, if you have a key flexfield that represents a part number, you would use the combinations form to define new parts and maintain existing part numbers. You would then have many foreign key forms that you use to manipulate your parts. You might have a form where you take orders for parts, another form where you receive parts, and yet another form where you ship parts. The fact that your part number happens to be a key flexfield is not important to your taking orders for your parts.

Range form:
- A range form displays a range flexfield, which is a special pop-up window that contains two complete sets of key flexfield segments. A range flexfield supports low and high values for each key segment rather than just single values. Ordinarily, a key flexfield range appears on your form as two adjacent flexfields, where the leftmost flexfield contains the low values for a range, and the rightmost flexfield contains the high values. A user would specify a range of low and high values in this pop-up window. For example, you might choose a range of part numbers for which you want to run a report.

- The range form uses a special table as its base table. This table contains one or more (usually two) columns for each segment column that appears in the combinations table. However, these columns do not necessarily contain actual segment values, and a row in the table does not necessarily contain actual valid combinations. Usually this table contains two columns for each segment, called SEGMENTn_LOW and SEGMENTn_HIGH (where n is the segment column number), that store the range of values for each segment.

- In Oracle Applications, we use a key flexfield range to help you specify cross-validation rules for key flexfield combinations.

- Some forms use a variation of a range flexfield to capture information for each key flexfield segment that is not necessarily a segment value. For example, the form might capture a "Yes" or "No" value for each segment (the Assign Function Parameters form displays a pop-up flexfield window where you choose Yes or No to specify whether you want to assign a value to each particular segment).

Dynamic insertion: Dynamic insertion is the insertion of a new valid combination into a combinations table from a form other than the combinations form. If you allow dynamic inserts when you set up your key flexfield, a user can enter a new combination of segment values using the flexfield window from a foreign key form. Assuming that the new combination satisfies any existing cross-validation rules, the flexfield inserts the new combination into the combinations table, even though the combinations table is not the underlying table for the foreign key form.

- For some key flexfields, dynamic inserts may not be allowed. Sometimes it may not make sense for an application to allow a user to be able to create a new combination from any form other than the combinations form. For example, a user should not be able to create a new part while taking an order for parts using an Enter Orders form; the application should restrict the creation of new part numbers to authorized users using a Create Parts form.

- Dynamic inserts may not be technically possible for some key flexfields. If the combinations table contains mandatory columns that are not maintained by the flexfield, dynamic inserts would not be possible. If the combinations table contains mandatory non-flexfield columns, such as a "unit of measure" column, the flexfield would not be able to complete the entire row in the combinations table from the foreign key form (because the base table of the foreign key form is not the combinations table). The flexfield does maintain the CCID column.

- Generally there is only one, if any, combinations form for a given key flexfield. In some applications, there may not be a combinations form. In these cases, you would use dynamic inserts to create new combinations.

Overview of Values and Value Sets:
Oracle Application Object Library uses values, value sets and validation tables as important components of key flexfields, descriptive flexfields, and Standard Request Submission. This section helps you understand, use and change values, value sets, and validation tables.
When you first define your flexfields, you choose how many segments you want to use and what order you want them to appear. You also choose how you want to validate each of your segments. The decisions you make affect how you define your value sets and your values.
You define your value sets first, either before or while you define your flexfield segment structures. You typically define your individual values only after your flexfield has been completely defined (and frozen and compiled). Depending on what type of value set you use, you may not need to predefine individual values at all before you can use your flexfield.
You can share value sets among segments in different flexfields, segments in different structures of the same flexfield, and even segments within the same flexfield structure. You can share value sets across key and descriptive flexfields. You can also use value sets for report parameters for your reports that use the Standard Request Submission feature.
Because the conditions you specify for your value sets determine what values you can use with them, you should plan both your values and your value sets at the same time. For example, if your values are 01, 02 instead of 1, 2, you would define the value set with Right-Justify Zero-fill set to Yes.
Remember that different flexfields may have different requirements and restrictions on the values you can use, so you should read information for your specific flexfield as part of your value planning process. For example, the Accounting Flexfield requires that you use certain types of value sets.

Planning Values and Value Sets: To plan values and value sets:
1. Choose a format for your values. Choosing Value Formats.
2. Decide whether your segment should have a list of values. Decide What Your User Needs.
3. Choose an appropriate validation type for your segment. Choosing a Validation Type for Your Value Set.
4. Consider using values that group neatly into ranges so that using range-based features (value security, value hierarchies, and so on) will be easier. Plan Values to Use Range Features.
5. Plan both values and descriptions as appropriate.
6. Plan any value hierarchies, cross-validation rules, value security rules, and so on as appropriate.

Defining Values and Value Sets
1. Prerequisites
- Plan your flexfield structures and segments.
- Thoroughly plan your values and value sets. Planning Values and Value Sets.

2. To define values and value sets:
1. Navigate to the Value Sets window.
2. Define your value set. Defining Value Sets.
3. Define your values. Defining Segment Values.

Relationship Between Independent and Dependent Values: Independent and dependent value sets have a special relationship. While you can have the same dependent values for any of your independent values, the meanings (or descriptions) - as well as any segment qualifier values, enabled/activation information and descriptive flexfield data for that value - of the dependent values depend on which of the independent values you choose in the prior independent segment.

You must set up your independent-dependent value sets carefully using the following sequence: - Create your independent value set first
- Create your dependent value set, specifying a default value
- Define your independent values
- Define your dependent values

When you define each of your independent values, Oracle Applications automatically creates a default dependent value that goes with your independent value. For example, the previous diagram shows a default value of zero (0). If for some reason you create a dependent value set after your independent value set has values, you must manually create a default value in your dependent set for each of your independent values, since each independent value must have a default dependent value. If necessary, create your default dependent values manually using the Segment Values form (you also use this form to create all dependent values other than the default value). You must create at least one dependent value for each independent value, or else your user will be unable to enter segment value combinations in the flexfield. However, we recommend that you carefully follow the above order for creating your value sets so that you never have to create default dependent values manually, since manually creating default dependent values is both tedious and error-prone.

"Dependent" Values with Table Validation: Flexfields uses a special mechanism to support table-validated segments whose values depend on the value in a prior segment (a different mechanism from that used for independent value sets with dependent value sets). You can use flexfield validation tables with a special WHERE clause (and the $FLEX$ argument) to create value sets where your segments depend on prior segments. You can make your segments depend on more than one segment (cascading dependencies). However, you cannot use parent value/child value features with these value sets, nor can you use this mechanism with the Accounting Flexfield.

Parent and Child Values and Rollup Groups :Only Oracle General Ledger and Oracle Public Sector General Ledger use these features, and only with the Accounting Flexfield. Parent and child value sets have a relationship different from the relationship between independent and dependent values.
- You can use a rollup group to identify a group of parent values for reporting or other application purposes. You assign key flexfield segment values to rollup groups.

Implementing Table-Validated Value Sets:
Table-validated value sets let you use your own application tables as value sets for flexfield segments and report parameters instead of the special values tables Oracle Applications provides. You need not enter each value manually using the Segment Values window. Value sets you base on validation tables can be similar to Independent value sets, where values in your Table type value sets are independent of the values in all other segments. Or, depending on how you define your validation table's WHERE clause, they can depend on one or more previous segments in your flexfield.
In general, you should use a validation table if you want a key or descriptive flexfield segment, or report parameter, to use values that your application already requires or maintains for other application purposes. Using a validation table then lets you avoid maintaining two copies of the same values (one in your application's table and the other in Oracle Application Object Library's tables).
You can use many advanced features with your table-validated value sets. You can use validation tables for flexfield segments or report parameters whose values depend on the value in a prior segment. You use flexfield validation tables with a special WHERE clause (and the $FLEX$ argument) to create value sets where your segments depend on prior segments. You can make your segments depend on more than one segment, creating cascading dependencies. You can also use validation tables with other special arguments to make your segments depend on profile options or field values.
If you want to make use of key flexfield features such as rollup groups and parent-child relationships, you can store the child values in your validation table, but you should use the Segment Values windows Oracle Applications provides to add or define the parent values and rollup groups.

Implementing a validation table:
1. Create or select a validation table in your database. You can use any existing application table, view, or synonym as a validation table. Defining Your Validation Table.
2. Register your table with Oracle Application Object Library (as a table). You may use a non-registered table for your value set, however. If your table has not been registered, you must then enter all your validation table information in this region without using defaults.
3. Create the necessary grants and synonyms. Creating Grants and Synonyms for Your Table.
4. Define a value set that uses your validation table. Defining Value Sets.
5. Define your flexfield structure to use that value set for a segment. You can use the same table for more than one value set, using different SQL WHERE clauses to limit which values are used for flexfield and report parameter validation. For example, if you wish to validate different segments against different rows of the same table, you would use the same table twice but select different rows of the table for each value set by using different SQL WHERE clauses.

Warning: You should not use any WHERE clause and/or ORDER BY clause at all for a value set you intend to use with the Accounting Flexfield.

In general, you may use a WHERE clause and/or an ORDER BY clause for validation tables you intend to use with key flexfields other than the Accounting Flexfield.

Attention: If you need a complex SQL clause to select your values from a table, you should instead first define a view over the table which selects the rows you need, and then define the value set over the view.
WHERE Clauses and Bind Variables for Validation Tables for detailed information on using WHERE clauses with special bind variables.

Using hidden ID columns with value sets: If you specify a hidden ID column in addition to your value column, the flexfield saves your hidden ID value, instead of the value from the value column, in the segment column (in your ATTRIBUTEnn column or SEGMENTnn column) of the underlying flexfield table.
Generally, you use value sets with hidden ID columns only for report parameters. You would not normally use them for most key flexfields. In fact, most key flexfields prevent you from using a value set with a hidden ID column by not displaying those value sets in the list of values you use to assign a value set to a segment.

Attention: You should not specify a hidden ID column for value sets you use with your Accounting Flexfield or most other key flexfields.

- If you specify a hidden ID column in addition to your value column, the report parameter window passes your hidden ID value, instead of the value from the value column, to your report.
- Table validated value sets using the "Standard Date" or "Standard DateTime" formats cannot use the ID column.

- Using multiple tables in a single value setFor value sets that use multiple tables, you should always include the table aliases with your all your column names. You must enter the column name directly, since your list of values cannot retrieve any column names for a "table name" that is not a registered single table. For example, you might enter: f.column_name

- For value sets that use multiple tables, you can and should leave the Table Application field blank, since it is effectively ignored in this case. You enter the table names and aliases you want in the Table Name field. Then, you enter the Value Column and Description Column column names directly, with table aliases, since your list of values cannot retrieve any column names for a "table name" that is not a registered single table.

- Displaying additional columns in your list of valuesYou can design your value set to display several columns in the segment value or report parameter value list of values, and these columns may be in different tables. If all your columns exist in the same table, you simply list the additional columns in the Additional Columns field. If your columns exist in different tables, you must specify more than one table name in the Table Name field. You should always use table names or aliases with your column names for your Additional Columns and WHERE clause.
Finally, you can enter the names of the extra columns you want, with their table aliases, in the Additional Columns field. You can specify column widths to display.

- In some cases you may want to use a SQL expression instead of specifying a single column name. For example, you may want to use a DECODE statement instead of a simple column name, such as:
DECODE(FORM.FORM_NAME, 'OEDEOR', 'Enter Orders', 'Not available')

- You can also use message names as alias names; this functionality allows for ease of translation of column titles. The syntax for using a message name as an alias name is:
E_FLAG "APPL=;NAME="(width)

Cross-Validation Rules A key flexfield can perform automatic cross-validation of segment values according to rules your organization defines when you customize the key flexfield. You can use cross-validation to closely control the creation of new key flexfield combinations, and you can maintain a consistent and logical set of key flexfield combinations that you need to run your organization.

What is Cross-Validation?
Cross-validation (also known as cross-segment validation) controls the combinations of values you can create when you enter values for key flexfields. A cross-validation rule defines whether a value of a particular segment can be combined with specific values of other segments. Cross-validation is different from segment validation, which controls the values you can enter for a particular segment.
You use cross-validation rules to prevent the creation of combinations that should never exist (combinations with values that should not coexist in the same combination). For example, if your organization manufactures both computer equipment and vehicles such as trucks, you might want to prevent the creation of "hybrid" part numbers for objects such as "truck keyboards" or "CPU headlights".

Planning Your Descriptive Flexfield: When you are planning your flexfields, you should consider the following questions and their corresponding decisions:
1. Do you want to capture information that is not otherwise captured by the form? If yes, you define this descriptive flexfield. If no, you need not define this descriptive flexfield at all.
2. Do you want to capture the same information every time, regardless of what other data appears in the form? If yes, you need to define global segments.
3. Do you want to capture certain information sometimes, depending on what other data appears in the form? If yes, you need to define context-sensitive segments.
4. If you want context-sensitive segments, do you want to have the form automatically determine which descriptive flexfield structure to display based on the value of a field somewhere on the form? If yes, you need to define a reference field (note that some descriptive flexfields do not provide reference fields).
5. If you want context-sensitive segments, do you want to have the user determine which descriptive flexfield structure to display by choosing a value in a field inside the pop-up window? If yes, you need to define a context field.
6. How do you want to break down reporting on your descriptive flexfield data? If you want to report on your data by certain criteria or sub-entities, such as account number or project or region, you may want to consider making that sub-entity a distinct segment, rather than combining it with another sub-entity, so that you can categorize and report on smaller discrete units of information.
7. How often does your organization change? This would affect how you set up your values. For example, if you disable old cost centers and enable new ones frequently, you would "use up" cost center values quickly. You would therefore want to use a larger maximum size for your cost center value set so that you can have more available values (for example, you have 999 available values for a 3-character value set instead of 100 available values for a 2-character value set).
8. Do you want to require a value for each segment?

Descriptive Flexfield Concepts:
- Descriptive flexfield segmentsDescriptive flexfields have two different types of segments, global and context-sensitive, that you can decide to use in a descriptive flexfield structure.
A global segment is a segment that always appears in the descriptive flexfield pop-up window, regardless of context (any other information in your form). A context-sensitive segment is a segment that may or may not appear depending upon what other information is present in your form.

- Context-sensitive segmentsIf you have context-sensitive segments, your descriptive flexfield needs context information (a context value) to determine which context-sensitive segments to show. A descriptive flexfield can get context information from either a field somewhere on the form, or from a special field (a context field) inside the descriptive flexfield pop-up window. If the descriptive flexfield derives the context information from a form field (either displayed or hidden from users), that field is called a reference field for the descriptive flexfield.

- A context field appears to an end user to be just another segment, complete with its own prompt. However, a context field behaves differently from a normal flexfield segment (either global or context-sensitive). When a user enters a context value into the context field, the user then sees different context-sensitive segments depending on which context value the user entered. You define a context field differently as well. You use a context field instead of a reference field if there is no form field that is a suitable reference field, or if you want your user to directly control which context-sensitive segments appear.

- A context-sensitive segment appears once the appropriate context information is chosen. The context-sensitive segments may appear immediately if the appropriate context information is derived from a form field before the user enters the descriptive flexfield.

- For a descriptive flexfield with context-sensitive segments, a single "structure" consists of both the global segments plus the context-sensitive segments for a particular context field value. That is, a structure consists of all the segments that would appear in the pop-up window at one time (after the structure has been chosen).

Planning Your Key Flexfield: Your first step in planning your key flexfields is to determine which key flexfields your Oracle Applications product requires. You should also determine the purpose of the key flexfield, as well as the number and length of its available segment columns ( Key Flexfields in Oracle Applications). You should also note whether your key flexfield allows more than one structure, and determine if you do indeed need to define more than one structure. For example, the System Items Flexfield (Item Flexfield) supports only one structure.

- Those key flexfields that allow multiple structures may use different mechanisms to determine which structure a user sees. For example, the Accounting Flexfield uses multiple structures if you have multiple sets of books with differing charts of accounts. Your forms determine which Accounting Flexfield structure to display by using the value of the GL_SET_OF_BOOKS_ID profile option associated with your current responsibility. Other key flexfields may have a field built into the form that allow a user to essentially choose which structure appears.

- You should decide on the number, order and length of your segments for each structure. You must also choose how to validate each segment. See: Overview of Values and Value Sets.
When you are planning your flexfields, you should consider the following questions and their corresponding decisions:

1. How do you want to break down reporting on your key flexfield data? If you want to report on your data by certain criteria or sub-entities, such as account number or project or region, you may want to consider making that sub-entity a distinct segment, rather than combining it with another sub-entity, so that you can categorize and report on smaller discrete units of information.

2. How often does your organization change? This would affect how you set up your values. For example, if you disable old cost centers and enable new ones frequently, you would "use up" cost center values quickly. You would therefore want to use a larger maximum size for your cost center value set so that you can have more available values (for example, you have 1000 available values for a 3-character value set instead of 100 available values for a 2-character value set).

3. Do you want to require a value for each segment?