Documente Academic
Documente Profesional
Documente Cultură
6 Votes
Oracle workflow is also a database application as many other application of Oracle, which
means that it also utilizes database tables as the basis of its operation. Behind its very pleasant
and user-friendly GUI, Its the database tables which store every piece of information
regarding the attributes, functions, process, messages you create while designing a workflow.
If you really want to know Workflow and discover how it works, you have to understand its
table structures.
In this article, I have covered the tables which got affected, when you create or modify a
workflow process. However it doesnt include the tables which capture information at run
time when you run a workflow. I have taken the PO Approval Workflow (POAPPRV) for
example purpose.
1] WF_ITEM_TYPES:
The wf_item_types table contains one record for each item_type created. The eight character
name of the item_type represents the Internal Name of the item. It also functions as the
primary key for this table. Some key columns are:
NAME: It is a mandatory field. It represents the internal name of the item type.
CUSTOM_LEVEL: Level of user who last updated the row. Again a mandatory field.
Workflow Item Type Display Name and description can be found in WF_ITEM_TYPES
_TL table. Also check the view WF_ITEM_TYPES_VL.
ITEM_TYPE: Internal name for the item type that owns the attribute. A mandatory
field.
There are three fields to hold a default value, but only one of them will be populated for any
item attribute, depending upon the datatype. For example, if you create an item attribute with
a datatype of Number, and then supply a default value, that value would be stored in the
number_default field.
The format field stores information about a format mask that should be applied to number
or date values, and the subtype field contains SEND or RECEIVE. The Translation
table is WF_ITEM_ATTRIBUTES_TL and the related view is
WF_ITEM_ATTRIBUTES_VL.
3] WF_ACTIVITIES:
This table stores the definition of an activity. Activities can be processes, notifications,
functions or folders. A process activity is a modeled workflow process, which can be included
as an activity in other processes to represent a sub-process. A notification activity sends a
message to a performer. A functions activity performs an automated function that is written as
a PL/SQL stored procedure. A folder activity is not part of a process, but it provides a means
of grouping activities. Some key columns are:
ITEM_TYPE: Internal name for the Item Type that owns the message.
VERSION: It is used to support multiple versions of the same process running at the
same time. The version number works in concert with the begin_date and
end_date fields, to ensure that only one version of any activity is active at any given
time. By versioning, the previously launched processes retain the process definition
that was in force at the time they were launched.
TYPE: The type field is the way that the individual types of activities can be
distinguished. There are five valid values found in the type field: FUNCTION,
NOTICE, EVENT, PROCESS, and FOLDER.
FUNCTION: For function activities only, the field is used to store the name of the
PLSQL procedure that the Workflow Engine should call to implement the function.
MESSAGE: For notification activities only, the field called message will be
populated. In these cases, it will contain the internal name of the message that the
notification will deliver.
TYPE: This field refers to the datatype of the values that the attribute will contain.
1
2 SELECT *
WF_ACTIVITY_ATTRIBUTES
3 FROM
WHERE ACTIVITY_ITEM_TYPE='POAPPRV'
4 AND ACTIVITY_NAME
='GET_NOTIFICATION_ATTRIBUTE'
5 AND ACTIVITY_VERSION
=
(SELECT
VERSION
6
7 FROM WF_ACTIVITIES
WHERE ITEM_TYPE='POAPPRV'
8
AND NAME
='GET_NOTIFICATION_ATTRIBUTE'
9 AND TRUNC(SYSDATE) BETWEEN TRUNC(BEGIN_DATE) AND
1 TRUNC(NVL(END_DATE,SYSDATE))
0 );
11
5] WF_ACTIVITY_ATTR_VALUES:
This table used to track values contained in activity attributes. This table is identical in
purpose to wf_item_attribute_values except it holds values for activity attributes instead of
item attributes. Each row includes the process activity id and the associated value for the
attribute. The interesting thing about this table is that it uses the process_activity_id to
identify the activity to which the attribute is attached. The same activity can be inserted into a
process more than one time, so the only way to uniquely identify the node to which this
attribute is attached is to use the process_activity_id.
1 SELECT * FROM WF_ACTIVITY_ATTR_VALUES WHERE NAME='NTF_USER_NAME';
6] WF_MESSAGES:
The messages that are associated with notifications are stored in this table. Each message,
which is uniquely identified by the combination of item_type and message_name (stored in
the fields type and name) receives a single record in the wf_messages table. The actual
text of the message is stored only in its localization table (wf_messages_tl). They can found in
the body and html_body fields.
1
2
3
4
5
7] WF_MESSAGE_ATTRIBUTES:
This table contains message attribute definitions. Each message may have zero or more
message attributes. Message attributes define additional information that is to be sent to, or
received from the user. These attributes can be used as tokens in the subject or body of a
message template to place variables values into the message at runtime.
1
2
3
4
8] WF_PROCESS_ACTIVITIES:
A process is a sequence of activities performed in a pre-determined order. When you create a
process definition in the Workflow Builder by dragging various notifications and functions
into the process window, the records created by the Builder are stored into this table.
1 SELECT * FROM WF_PROCESS_ACTIVITIES
2 WHERE PROCESS_ITEM_TYPE='POAPPRV'
='APPROVE_PO_SUB_PROCESS';
3 AND PROCESS_NAME
9] WF_ACTIVITY_TRANSITIONS:
The flow of a process from node to node as indicated by the transition arrows is not saved in
the wf_process_activities table. Instead this information is stored in this table.
A transition is defined by three discrete pieces of information: the node where the arrow
begins, the node toward which the arrow points, and the result which, when returned by the
beginning node, causes the transition to be followed. Not surprisingly, it is those three fields
which are the most important fields in this table: from_process_activity,
to_process_activity, and result_code. The values stored in from_process_activity and
to_process_activity are numbers which represent the instance_id of the records from
wf_process_activities from which and to which the transition is moving.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
SELECT *
FROM WF_ACTIVITY_TRANSITIONS
WHERE FROM_PROCESS_ACTIVITY =
(SELECT INSTANCE_ID
FROM WF_PROCESS_ACTIVITIES
WHERE PROCESS_ITEM_TYPE='POAPPRV'
AND PROCESS_NAME
='APPROVE_PO_SUB_PROCESS'
AND INSTANCE_LABEL
='START'
AND PROCESS_VERSION
=
(SELECT MAX(PROCESS_VERSION)
FROM WF_PROCESS_ACTIVITIES
WHERE PROCESS_ITEM_TYPE='POAPPRV'
AND PROCESS_NAME
='APPROVE_PO_SUB_PROCESS'
AND INSTANCE_LABEL
='START'
)
)
AND TO_PROCESS_ACTIVITY =
(SELECT INSTANCE_ID
FROM WF_PROCESS_ACTIVITIES
WHERE PROCESS_ITEM_TYPE='POAPPRV'
AND PROCESS_NAME
='APPROVE_PO_SUB_PROCESS'
AND INSTANCE_LABEL
='IS_DOCUMENT_APPROVED'
AND PROCESS_VERSION
=
(SELECT MAX(PROCESS_VERSION)
FROM WF_PROCESS_ACTIVITIES
WHERE PROCESS_ITEM_TYPE='POAPPRV'
AND PROCESS_NAME
='APPROVE_PO_SUB_PROCESS'
AND INSTANCE_LABEL
='IS_DOCUMENT_APPROVED'
)
);
1
2
3
4
5
6
7
SELECT *
FROM WF_LOOKUP_TYPES_TL
WHERE ITEM_TYPE='POAPPRV'
AND LOOKUP_TYPE='PO_POAPPRV_APPROVE_ACTION';
SELECT * FROM WF_LOOKUPS_TL
WHERE LOOKUP_TYPE='PO_POAPPRV_APPROVE_ACTION';
Filed under Apps Tables, Oracle Workflow Tagged with oracle workflow tables,
WF_ACTIVITIES, WF_ACTIVITY_ATTRIBUTES, WF_ACTIVITY_ATTR_VALUES,
WF_ACTIVITY_TRANSITIONS, WF_ITEM_ATTRIBUTES, WF_ITEM_TYPES,
WF_LOOKUPS_TL, WF_LOOKUP_TYPES_TL, WF_MESSAGES,
WF_MESSAGE_ATTRIBUTES, WF_PROCESS_ACTIVITIES
16 Votes
Here is a brief description of the key tables in Oracle Inventory.
Table
MTL_PARAMETERS
MTL_SYSTEM_ITEMS_B
MTL_ITEM_STATUS
MTL_UNITS_OF_MEASURE_TL
MTL_ITEM_LOCATIONS
MTL_ITEM_CATEGORIES
Description
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
(MASTER_ORGANIZATION_ID) and costing
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_B and
MTL_SYSTEM_ITEMS_TL. Translations table
(MTL_SYSTEM_ITEMS_TL) holds item
Description and Long Description in multiple
languages.
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 set.
MTL_CATEGORIES_B
MTL_CATEGORY_SETS_B
MTL_DEMAND
MTL_SECONDARY_INVENTORIES
MTL_ONHAND_QUANTITIES
MTL_TRANSACTION_TYPES
MTL_MATERIAL_TRANSACTIONS
MTL_ITEM_ATTRIBUTES
MTL_ITEM_CATALOG_GROUPS_B
MTL_ITEM_REVISIONS_B
MTL_ITEM_TEMPLATES_B
MTL_DESCRIPTIVE_ELEMENTS
MTL_DESCR_ELEMENT_VALUES
ORG_ACCT_PERIODS
TRANSACTION_SOURCE_TYPE_ID that is
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,
TRANSACTION_ACTION_ID,
TRANSACTION_SOURCE_TYPE_ID,
TRANSACTION_SOURCE_ID and
TRANSACTION_SOURCE_NAME describe what
the transaction is and against what entity it was
performed.
This table stores information on item attributes.
Each
row in the table corresponds to an attribute. The
table stores the attribute name, the corresponding
user-friendly 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
organizations.
MTL_CUSTOMER_ITEMS
MTL_SYSTEM_ITEMS_INTERFACE
MTL_TRANSACTIONS_INTERFACE
MTL_ITEM_REVISIONS_INTERFACE
MTL_ITEM_CATEGORIES_INTERFACE
MTL_DESC_ELEM_VAL_INTERFACE
MTL_DEMAND_INTERFACE
MTL_INTERFACE_ERRORS
Filed under Apps Tables, Oracle Inventory Tagged with Key Inventory tables, MTL Tables,
Oracle Inventory
5 Votes
PA_TASKS
PA_TASK_TYPES
PA_TRANSACTION_INTERFACE_ALL
PA_TRANSACTION_SOURCES
PA_IMPLEMENTATIONS_ALL
PA_ACTION_SETS
PA_ACTION_SET_LINES
PA_ACTION_SET_TYPES
PA_AGREEMENTS_ALL
PA_AGREEMENT_TYPES
PA_BILL_RATES_ALL
PA_BUDGETS
PA_BUDGET_LINES
PA_BUDGET_TYPES
PA_CLASS_CATEGORIES
PA_CLASS_CODES
Description
It stores the highest units of work defined in Oracle
Projects.
It contains assets information defined for capital
projects.
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 processing.
It contains user-defined subdivisions of project work.
It stores implementation-defined classifications of
task.
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, etc.
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
agreements.
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.
PA_EVENTS
PA_EVENT_TYPES
PA_EXPENDITURES_ALL
PA_EXPENDITURE_CATEGORIES
PA_EXPENDITURE_ITEMS_ALL
PA_EXPENDITURE_TYPES
PA_PERIODS_ALL
PA_RBS_DENORM
PA_RBS_ELEMENTS
PA_RESOURCES
PA_ROLE_LISTS
PA_SCHEDULES
Filed under Apps Tables, Oracle Projects Tagged with apps tables, Key project tables, Oracle
Projects
GL Tables
January 11, 2011 Leave a comment
4 Votes
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 form.
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
information.
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 entry.
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.
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
row.
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
8 Votes
FND_SECURITY_GROUPS:
Stores information about security groups used to partition data in a Service Bureau
architecture.
FND_SEQUENCES:
Stores information about the registered sequences in your applications.
FND_TABLES:
Stores information about the registered tables in your applications.
FND_TERRITORIES:
Stores information for countries, alternatively known as territories.
FND_USER:
Stores information about application users.
FND_VIEWS:
Stores information about the registered views in your applications.
Filed under AOL, Apps Tables Tagged with FND Tables, Oracle AOL, Oracle Apps
5 Votes
Each row includes the purchasing, receiving, invoice, tax, classification, and general
information.
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.
AP_SUPPLIER_SITES_ALL:
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
information.
AP_INVOICES_ALL:
An invoice can have one or more invoice distribution lines and can have one or more
scheduled payments.
AP_INVOICE_LINES_ALL:
An invoice line should contain all the attributes that are present on the physical or
electronic invoice presented by the supplier.
AP_INVOICE_DISTRIBUTIONS_ALL:
There is one row for each invoice distribution and a distribution must be associated
with an invoice.
AP_INVOICE_PAYMENTS_ALL:
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.
AP_PAYMENT_SCHEDULES_ALL:
AP_PAYMENT_HISTORY_ALL:
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
payment.
AP_BATCHES_ALL:
It contains summary information about invoices you enter in batches if you enable the
Batch Control Payables option.
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.
AP_CHECKS_ALL:
There is one row for each payment you issue to a supplier or refund received from a
supplier.
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.
AP_HOLDS_ALL:
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.
Your Oracle Payables application does not pay invoices that have one or more
unreleased holds recorded in this table.
AP_BANK_ACCOUNTS_ALL:
There is one row for each bank account you define and each bank account must be
affiliated with one bank branch.
AP_BANK_ACCOUNT_USES_ALL:
It stores information for the internal and external bank accounts you define in Oracle
Payables and Oracle Receivables applications.
AP_CARDS_ALL:
It stores information about the corporate credit cards issued to your employees by your
corporate credit card providers.
AP_TRIAL_BALANCE:
Filed under Apps Tables, Payables Tagged with account payables, AP, apps tables, Oracle
Apps, Oracle E-Business Suite
3 Votes
Filed under Apps Tables, Receivables Tagged with AR, AR Tables, Oracle Receivables
25 Votes
HZ(TCA) tables in Oracle Receivables
This article describes few important HZ tables in AR and their relationships with each other.
HZ_PARTIES:
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 is
PARTY_ID.
Few Important Columns are
HZ_PARTY_SITES:
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_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
table.
HZ_LOCATIONS:
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
CITY: City
STATE: State
HZ_CUST_ACCOUNTS:
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.
HZ_CUST_ACCT_SITES_ALL:
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
HZ_CUST_SITE_USES_ALL:
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
CUST_ACCT_SITE_ID: Identifier for the customer account site. Foreign key to the
HZ_CUST_ACCT_SITES_ALL table
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.
HZ_CUSTOMER_PROFILES:
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 the
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
HZ_CUST_PROFILE_CLASSES:
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.
HZ_PARTY_RELATIONSHIPS:
The HZ_PARTY_RELATIONSHIPS table stores information about relationships between
parties.