You are on page 1of 16

Oracle R12 Apps Tables

Oracle R12 Apps Tables

Key Tables in Oracle Inventory
Here is a brief description of the key tables in Oracle Inventory.



It maintains a set of default options like general

ledger accounts; locator, lot, and serial controls,
inter-organization options, costing method, etc. for
each organization defined in Oracle Inventory. Each
organizations item master organization
organization (COST_ORGANIZATION_ID) are
maintained here.
This is the definition table for items. This table holds
the definitions for inventory items, engineering
items, and purchasing items. The primary key for an
item is the INVENTORY_ITEM_ID and
ORGANIZATION_ID. Therefore, the same item can
be defined in more than one organization. Items now
support multilingual description. MLS is
implemented with a pair of tables:
MTL_SYSTEM_ITEMS_TL. Translations table
(MTL_SYSTEM_ITEMS_TL) holds item
Description and Long Description in multiple
This is the definition table for material status codes.
Status code is a required item attribute. It indicates
the status of an item, i.e., Active, Pending, Obsolete.
This is the definition table for both the 25-character
and the 3-character units of measure. The
base_uom_flag indicates if the unit of measure is the
primary unit of measure for the uom_class. Oracle
Inventory uses this table to keep track of the units of
measure used to transact an item.
This is the definition table for stock locators. The
associated attributes describe which subinventory this
locator belongs to, what the locator physical capacity
is, etc.
This table stores inventory item assignments to











categories within a category set. For each category

assignment, this table stores the item, the category
set, and the category. Items always may be assigned
to multiple category sets. However, depending on the
Multiple Assignments Allowed attribute value in a
given category set definition, an item can be assigned
to either many or only one category in that category
This is the code combinations table for item
categories. Items are grouped into categories within
the context of a category set to provide flexible
grouping schemes. Item categories now support
multilingual category description. MLS is
implemented with a pair of tables:
table holds translated Description for Categories.
It contains the entity definition for category sets. A
category set is a categorization scheme for a group of
items. Items may be assigned to different categories
in different category sets to represent the different
groupings of items used for different
purposes. An item may be assigned to only one
category within a category set, however.
STRUCTURE_ID identifies the flexfield structure
associated with the category set. Category Sets now
support multilingual category set name and
description. MLS is implemented with a pair of
MTL_CATEGORY_SETS_TL table holds translated
Name and Description for Category Sets.
This table stores demand and reservation information
used in Available To Promise, Planning and other
Manufacturing functions. There are three major row
types stored in the table: Summary Demand rows,
Open Demand Rows, and Reservation Rows.
This is the definition table for the subinventory. A
subinventory is a section of inventory, i.e., raw
material, finished goods, etc. Subinventories are
assigned to items (in a many to one relationship),
indicating a list of valid places where this item will
physically exist in inventory.
It stores quantity on hand information by control
level and location. It is maintained as a stack of








receipt records, which are consumed by issue

transactions in FIFO order. The quantity on hand of
an item at any particular control level and location
can be found by summing
TRANSACTION_QUANTITY for all records that
match the criteria.
It contains seeded transaction types and the user
defined ones. USER_DEFINED_FLAG will
distinguish the two. The table also stores the
associated with each transaction type.
This table stores a record of every material
transaction or cost update performed in Inventory.
Records are inserted into this table either through the
transaction processor or by the standard cost update
program. The columns TRANSACTION_TYPE_ID,
the transaction is and against what entity it was
This table stores information on item attributes. Each
row in the table corresponds to an attribute. The table
stores the attribute name, the corresponding userfriendly name seen by the users, and the kind of
validation enforced on the attribute.
This is the code combinations table for item catalog
groups. An item catalog group consists of items that
can be described by the same set of descriptive
elements or item properties. When an item is
associated with an item catalog group, the item
inherits the descriptive elements for that group which
then behave like additional item attributes.
It stores revision levels for an inventory item. When
an item is defined a starting revision record is written
out to this table, so every item will at least have one
starting revision.
This is the definition table for item templates. It
contains the user-defined name
(TEMPLATE_NAME) and description
(DESCRIPTION) ONLY for backward compatibility.
You can use a template to set certain item attributes.
It stores the descriptive element definitions for an

item catalog group. Descriptive elements are defining

properties used to describe in the catalog group.
It stores the descriptive element values for a specific
item. When an item is associated with a particular
item catalog group, one row per descriptive element
(for that catalog group) is inserted into this table.
It holds the open and closed financial periods for
It stores customer item information for a specific
customer. Each record can be defined at one of the
following levels: Customer, Address Category, and
Address. The customer item definition is
organization independent.
It temporarily stores the definitions for inventory
items, engineering items and purchasing items before
loading this information into Oracle Inventory.
It allows calling applications to post material
transactions (movements, issues, receipts etc. to
Oracle Inventory transaction module.
It temporarily stores revision levels for an inventory
item before loading this information into Oracle
MTL_ITEM_CATEGORIES_INTERFACE This table temporarily stores data about inventory
item assignments to category sets and categories
before loading this information into Oracle Inventory.
This table temporarily stores descriptive element
values for an item that is associated with an item
catalog group before loading this information into
Oracle Inventory.
It is the interface point between non-Inventory
applications and the Inventory demand module.
Records inserted into this table are processed by the
Demand Manager concurrent program.
It stores errors that occur during the item interface
process reporting where the errors occurred along
with the error messages.

Key Tables in Oracle Projects

Here is a brief description of the key tables in Oracle Projects.


It stores the highest units of work defined in Oracle

It contains assets information defined for capital
It stores details of all Assignments for a project.
It contains the class codes of class categories that are
used to classify projects.
Implementation-defined responsibilities or positions
assigned to employees on projects are stored here.
It stores valid project status codes.
It stores implementation-defined project classifications
that supply default information and drive some project
It contains user-defined subdivisions of project work.
It stores implementation-defined classifications of
PA_TRANSACTION_INTERFACE_ALL It is an interface table to import transactions from
external sources into Oracle Projects.
It stores implementation-defined sources of imported
transactions originating in an external system.
It contains information about the configuration of an
Oracle Projects installation.
It stores action set templates as well as action sets
belonging to an object, such as projects, requirements,
It stores action set lines that belong to an action set or
an action set template.
It stores attributes of action set types.
It has customer contracts that serve as the basis for
work authorization.
Implementation-defined classifications of customer
Information about bill rates and markups of standard
bill rate schedules.
It stores budgets information.
It stores detail lines of project and task budgets.
It contains implementation-defined classifications of
types of budgets used for different business purposes.
It stores implementation-defined categories for
classifying projects.
It stores implementation-defined values within class
categories that can be used to classify projects.


It stores entries assigned to tasks that generate revenue

and/or billing but are not directly related to
expenditure items.
It stores implementation-defined classifications of
Groups of expenditure items incurred by employees or
organizations for an expenditure period.
Implementation-defined groupings of expenditure
types by type of cost.
It contains the smallest units of expenditure charged to
projects and tasks.
Implementation-defined classifications of
expenditures charged to projects and tasks.
Implementation-defined periods against which project
performance is measured.
This table stores normalized resource breakdown
structure information.
This table stores the RBS element information and the
parent-child relationship.
It contains resources used in budgeting and project
summary amounts.
It stores lists of roles defined with the system.
It displays the schedule details for requirements and
assignments. It also displays calendar schedules.
Filed under Apps Tables, Oracle Projects Tagged with apps tables, Key project tables, Oracle

GL Tables
GL Tables
General Ledger tables can be grossly classified into following 5 categories. Here are few
important tables in each category.

Ledgers Tables:
GL_LEDGERS: Stores information about the ledgers defined in the Accounting Setup
Manager and the ledger sets defined in the Ledger Set form. Each row includes the ledger or
ledger set name, short name, description, ledger currency, calendar, period type, chart of
accounts, and other information.
GL_CODE_COMBINATIONS: Stores valid account combinations for each Accounting
Flexfield structure within your Oracle General Ledger application.

Period Tables:
GL_PERIODS: Stores information about the accounting periods you define using the
Accounting Calendar form.
GL_PERIOD_SETS: Stores the calendars you define using the Accounting Calendar

GL_PERIOD_TYPES: Stores the period types you define using the Period Types form.
Each row includes the period type name, the number of periods per fiscal year, and other

Journal Tables:
GL_JE_BATCHES: Stores journal entry batches. Each row includes the batch name,
description, status, running total debits and credits, and other information.
GL_JE_HEADERS: Stores journal entries. There is a one-to-many relationship between
journal entry batches and journal entries. Each row in this table includes the associated
batch ID, the journal entry name and description, and other information about the journal
GL_JE_LINES: Stores the journal entry lines that you enter in the Enter Journals form.
There is a one-to-many relationship between journal entries and journal entry lines. Each
row in this table stores the associated journal entry header ID, the line number, the
associated code combination ID, and the debits or credits associated with the journal line.
GL_JE_SOURCES: Stores journal entry source names and descriptions. Each journal
entry in your Oracle General Ledger application is assigned a source name to indicate how it
was created. This table corresponds to the Journal Sources form.
GL_JE_CATEGORIES: Stores journal entry categories. Each row includes the category
name and description.

Conversion and consolidation tables:

GL_CONSOLIDATION: Stores information about your consolidation mappings. Each
row includes a mappings ID, name, description, and other information. This table
corresponds to the first window of the Consolidation Mappings form. You need one row for
each consolidation mapping you define.
GL_CONSOLIDATION_ACCOUNTS: Stores the account ranges that you enter when
you consolidate balances using the Transfer Consolidation Data form. This table
corresponds to the Account Ranges window of the Transfer Consolidation Data form.
GL_DAILY_RATES: Stores the daily conversion rates for foreign currency transactions.
It replaces the GL_DAILY_CONVERSION_RATES table. It stores the rate to use when
converting between two currencies for a given conversion date and conversion type.
GL_DAILY_BALANCES: Stores daily aggregate balances for detail and summary
balance sheet accounts in sets of books with average balances enabled.

Budgeting tables:
GL_BUDGET_TYPES: Stores information about budget types. Oracle General Ledger
supports only one budget type, STANDARD. Therefore, this table always contains only one
GL_BUDGET_ASSIGNMENTS: Stores the accounts that are assigned to each budget
organization. Each row includes the currency assigned to the account and the entry code for
the account. The entry code is either E for entered or C for calculated. This table
corresponds to the Account Assignments window of the Define Budget Organization form.
GL_BUDGET_INTERIM: It is used internally by Oracle General Ledger applications to
post budget balances to the GL_BALANCES table. Rows are added to this table whenever
you run the budget posting program. The budget posting program updates the appropriate
budget balances in GL_BALANCES based on the rows in this table, and then deletes the
rows in this table that it used.

Interface Tables:
GL_INTERFACE: It is used to import journal entry batches through Journal Import. You
insert rows in this table and then use the Import Journals window to create journal batches.

GL_INTERFACE_CONTROL: It is used to control Journal Import execution. Whenever

you start Journal Import from the Import Journals form, a row is inserted into this table for
each source and group id that you specified. When Journal Import completes, it deletes
these rows from the table.
GL_BUDGET_INTERFACE: It is used to upload budget data into your Oracle General
Ledger application from a spreadsheet program or other external source. Each row includes
one fiscal years worth of budget amounts for an account.
Filed under Apps Tables, General Ledger Tagged with General Ledger, GL, GL
Tables, Oracle Apps

Key FND Tables in Oracle Application

Key FND Tables in Oracle Application

Here there are few key FND tables that we use in our AOL queries.
Stores applications registered with Oracle Application Object Library.
Stores translated information about all the applications registered with Oracle Application
Object Library.
This table will track the servers used by the E-Business Suite system.
Stores information relating a document to an application entity.
Stores information about concurrent managers.
Stores information about immediate (subroutine) concurrent program libraries.
Stores information about concurrent programs. Each row includes a name and description
of the concurrent program.
Stores translated information about concurrent programs in each of the installed languages.
Stores information about concurrent managers.
Stores information about the number of requests a concurrent manager can process at once,
according to its work shift.
Stores information about individual concurrent requests.
Stores information about concurrent request types.
This table stores output files created by Concurrent Request.
Stores information about currencies.
It tracks the databases employed by the eBusiness suite. This table stores information about

the database that is not instance specific.

Stores instance specific information. Every database has one or more instance.
Stores setup information about descriptive flexfields.
Stores translated setup information about descriptive flexfields.
Stores language-independent information about a document.
Stores information about concurrent program executables.
Stores valid values for key and descriptive flexfield segments.
Stores information about the value sets used by both key and descriptive flexfields.
Stores information regarding languages and dialects.
It lists the menus that appear in the Navigate Window, as determined by the System
Administrator when defining responsibilities for function security.
Stores translated information about the menus in FND_MENUS.
Stores information about individual entries in the menus in FND_MENUS.
Stores information about user profile options.
Stores information about report security groups.
Stores information about report sets.
Stores information about responsibilities. Each row includes the name and description of
the responsibility, the application it belongs to, and values that identify the main menu, and
the first form that it uses.
Stores translated information about responsibilities.
Stores security exclusion rules for function security menus. Security exclusion rules are lists
of functions and menus inaccessible to a particular responsibility.
Stores information about security groups used to partition data in a Service Bureau
Stores information about the registered sequences in your applications.
Stores information about the registered tables in your applications.
Stores information for countries, alternatively known as territories.

Stores information about application users.

Stores information about the registered views in your applications.

Few Important AP Tables

Few Important AP Tables

This table replaces the old PO_VENDORS table.

It stores information about your supplier level attributes.

Each row includes the purchasing, receiving, invoice, tax, classification, and general
Oracle Purchasing uses this information to determine active suppliers.

The supplier name, legal identifiers of the supplier will be stored in TCA and a
reference to the party created in TCA will be stored in AP_SUPPLIERS.PARTY_ID, to
link the party record in TCA.

This table replaces the old PO_VENDOR_SITES_ALL table.

It stores information about your supplier site level attributes.

There is a row for unique combination of supplier address, operating unit and the
business relationship that you have with the supplier.

The supplier address information is not maintained in this table and is maintained in
TCA. The reference to the internal identifier of address in TCA will be stored in
AP_SUPPLIER_SITES_ALL.LOCATION_ID, to link the address record in TCA.

Each row includes the supplier reference, purchasing, invoice, and general

It contains records for invoices you enter.

There is one row for each invoice you enter.

An invoice can have one or more invoice distribution lines and can have one or more
scheduled payments.

It contains records for invoice lines entered manually, generated automatically or

imported from the Open Interface.

An invoice can have one or more invoice lines.

An invoice line represents goods (direct or indirect materials), service(s), and/or

associated tax/freight/miscellaneous charges invoiced from a supplier.

An invoice line should contain all the attributes that are present on the physical or
electronic invoice presented by the supplier.

It holds the distribution information that is manually entered or system-generated.

There is one row for each invoice distribution and a distribution must be associated
with an invoice.

An invoice can have multiple distributions.


It contains records of invoice payments that you made to suppliers.

There is one row for each payment you make for each invoice and there is one
payment and one invoice for each payment in this table.

Oracle Payables application updates this table when you confirm an automatic
payment batch, enter a manual payment, or process a Quick payment.

When you void a payment, your Oracle Payables inserts an additional payment line
that is the negative of the original payment line.

This table stores information about scheduled payment information on invoices.


It stores the clearing/unclearing history for payments.

It also stores the maturity history for future dated payments.

The table contains a row for each future dated payment, once the future dated
payment matures, i.e. becomes negotiable.

Any time a payment is cleared or uncleared, a row is inserted into this table for the

It contains summary information about invoices you enter in batches if you enable
the Batch Control Payables option.

There is one row for each batch of invoices you enter.

If you enable Batch Control, each invoice must correspond to a record in this table.

Your Oracle Payables application uses this information to group together invoices
that one person entered in a batch.

It stores information about payments issued to suppliers or refunds received from


There is one row for each payment you issue to a supplier or refund received from a

Oracle Payables application uses this information to record payments you make to
suppliers or refunds you receive from suppliers.

Oracle Payables application stores the supplier name and bank account name for
auditing purposes, in case either one is changed after you create the payment. Oracle
Payables application also stores address information for all payments.

It contains information about holds that you or your Oracle Payables application
place on an invoice.

For non-matching holds, there is one row for each hold placed on an invoice. For
matching holds, there is one row for each hold placed on an invoice-shipment match.
An invoice may have one or more corresponding rows in this table.

Your Oracle Payables application does not pay invoices that have one or more
unreleased holds recorded in this table.

It contains information about your bank accounts.

There is one row for each bank account you define and each bank account must be
affiliated with one bank branch.

It stores information for the internal and external bank accounts you define in Oracle
Payables and Oracle Receivables applications.

It stores information about the corporate credit cards issued to your employees by
your corporate credit card providers.

It contains denormalized information about invoices and payments posted to the

accrual set of books.
Filed under Apps Tables, Payables Tagged with account payables, AP, apps tables, Oracle
Apps, Oracle E-Business Suite

AR Tables:A Diagrammatic Relation

AR Tables:A Diagrammatic Relation

A Diagrammatic Relation between AR Tables

HZ tables in Oracle Receivables

HZ(TCA) tables in Oracle Receivables
This article describes few important HZ tables in AR and their relationships with each other.
The HZ_PARTIES table stores basic information about parties that can be shared with any
relationship that the party might establish with another party. The primary key for this table
Few Important Columns are

PARTY_ID: Party identifier

PARTY_NUMBER: Unique identification number for this party

PARTY_NAME: Name of the party

PARTY_TYPE: The party type can only be Person, Organization, Group or

The HZ_PARTY_SITES table links a party (HZ_PARTIES) and a location
(HZ_LOCATIONS) and stores location-specific party information. One party can optionally
have one or more party sites. One location can optionally be used by one or more parties.
The primary key for this table is PARTY_SITE_ID.
Few Important Columns are

PARTY_SITE_ID: Party site identifier.

PARTY_ID: Identifier for the party. Foreign key to the HZ_PARTIES table.

LOCATION_ID: Identifier for the party site. Foreign key to the HZ_LOCATIONS
PARTY_SITE_NUMBER: Party site number.
PARTY_SITE_NAME: User-defined name for the site.

ADDRESSEE: Addressee information.

The HZ_LOCATIONS table stores information about a delivery or postal address such as
building number, street address, postal code, and directions to a location. This table
provides physical location information about parties (organizations and people) and
customer accounts. The primary key for this table is LOCATION_ID.
Few Important Columns are

LOCATION_ID: Unique identifier for this location

COUNTRY: Country code from the TERRITORY_CODE column in the

ADDRESS1: First line for address

ADDRESS2: Second line for address

ADDRESS3: Third line for address

ADDRESS4: Fourth line for address

CITY: City

POSTAL_CODE: Postal Code

STATE: State

ADDRESS_KEY: Derived key that facilitates fuzzy searches

The HZ_CUST_ACCOUNTS table stores information about customer accounts , or business
relationships that the deploying company establishes with a party of type Organization or
Person. This table focuses on business relationships and how transactions are conducted in
the relationship. Since a party can have multiple customer accounts, this table might
contain several records for a single party. For example, an individual person can establish a
personal account, family account, and a professional account for a consulting practice. The
primary key for this table is CUST_ACCOUNT_ID.
Few Important Columns are

CUST_ACCOUNT_ID: Customer account identifier

PARTY_ID: A foreign key to the HZ_PARTY table.

ACCOUNT_NUMBER: Account Number

CUSTOMER_TYPE: Receivables lookup code for the CUSTOMER_TYPE attribute. I

for internal customers, R for revenue generating external customers.

CUSTOMER_CLASS_CODE: Customer class identifier

The HZ_CUST_ACCT_SITES_ALL table stores all customer account sites across all
operating units. Customer account sites are addresses, for customer accounts, where the
deploying company does business with its customers. One customer account can have
multiple customer account sites, and customer account sites for one customer account can

belong to multiple operating units. The primary key for this table is CUST_ACCT_SITE_ID.
Few Important Columns are

CUST_ACCT_SITE_ID: Customer site identifier

CUST_ACCOUNT_ID: Identifier for a customer account. Foreign key to the

PARTY_SITE_ID: Identifier for a party site. Foreign key to the HZ_PARTY_SITES
BILL_TO_FLAG: Indicates if this is a Bill-To site.
SHIP_TO_FLAG: Indicates if this is a Ship-To site.

MARKET_FLAG: Indicates if this is a Marketing site.

The HZ_CUST_SITE_USES_ALL table stores business purposes assigned to customer
account sites, for example Bill-To, Ship-To, and Statements. Each customer account site can
have one or more purposes. This table is a child of the HZ_CUST_ACCT_SITES_ALL table,
with the foreign
key CUST_ACCT_SITE_ID. The HZ_CUST_SITE_USES_ALL table also stores operating
unit identifier, though the HZ_CUST_ACCT_SITES_ALL table itself stores the operating
unit for customer account sites. The primary key for this table is SITE_USE_ID.
Few Important Columns are

SITE_USE_ID: Site use identifier

CUST_ACCT_SITE_ID: Identifier for the customer account site. Foreign key to the

SITE_USE_CODE: Business purpose assigned to customer site account, such as BillTo, Market, and Statements.

PRIMARY_FLAG: Indicates if this site is the primary site for this customer account.
Y for the primary customer account site. N for other customer account sites.
The HZ_CUSTOMER_PROFILES table stores information about the credit characteristics
of a single customer account or a customer account site or a party. A profile class defined in
HZ_CUSTOMER_PROFILE_CLASSES table can be used to provide default values for the
attributes in this table. The primary key for this table is CUST_ACCOUNT_PROFILE_ID.
Few Important Columns are

CUST_ACCOUNT_PROFILE_ID: Unique identifier of this customer profile

CUST_ACCOUNT_ID: Identifier for the Customer Account. Foreign key to the


STATUS: Indicates whether the profile is active or inactive

The HZ_CUST_PROFILE_CLASSES table stores information about the credit
characteristics that are common across a group of customer accounts. The characteristics
specified in this table can be used as default characteristics for similar customer accounts.
The primary key for this table is PROFILE_CLASS_ID.

The HZ_PARTY_RELATIONSHIPS table stores information about relationships between