P. 1
Work Flow Po

Work Flow Po

|Views: 34|Likes:
Published by Bhargi111
Work Flow Oracle Apps PO Purchase Order
Work Flow Oracle Apps PO Purchase Order

More info:

Published by: Bhargi111 on Mar 17, 2013
Copyright:Attribution Non-commercial

Availability:

Read on Scribd mobile: iPhone, iPad and Android.
download as DOCX, PDF, TXT or read online from Scribd
See more
See less

02/08/2014

pdf

text

original

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, It‟s the database tables which store every piece of information regarding the attributes, functions, process, m essages 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 doesn ‟t 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 o f 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. PROTECT_LEVEL: Level at which the data is protected. A mandatory field. CUSTOM_LEVEL: Level of user who last updated the row. Again a mandatory field. WF_SELECTOR: It stores the name of the PL/SQL procedure which implements selector function. This is an optional field. PERSISTENCE_TYPE: Indicates whether item type is temporary or permanent. PERSISTENCE_DAYS: Number of days until purge if persistence is temporary. Workflow Item Type Display Name and description can be found in WF_ITEM_TYPES _TL table. Also check the viewWF_ITEM_TYPES_VL.

1 SELECT * FROM WF_ITEM_TYPES WHERE NAME='POAPPRV'; 2 SELECT * FROM WF_ITEM_TYPES_TL WHERE NAME='POAPPRV'; 3 SELECT * FROM WF_ITEM_TYPES_VL WHERE NAME='POAPPRV';
2] WF_ITEM_ATTRIBUTES: This table stores definitions of attributes associated with a process. The entries in this table correspond to the “Attributes” subheading in the Workflow Builder. An item attribute works like a variable which can hold values that are specific to the process instance or which may change at run time. Some key columns are:

   

ITEM_TYPE: Internal name for the item type that owns the attribute. A mandatory field. NAME: Internal name of the attribute. A mandatory field. SEQUENCE: Order of the attribute within the message TYPE: Each item attribute is assigned a datatype, such as “Character”, “Number”, or “Date”. 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.

1 SELECT * FROM WF_ITEM_ATTRIBUTES WHERE ITEM_TYPE='POAPPRV' AND NAME='PO_DESCRIP TION'; 2 SELECT * FROM WF_ITEM_ATTRIBUTES_TL WHERE ITEM_TYPE='POAPPRV' AND NAME='PO_DESC RIPTION'; 3 SELECT * FROM WF_ITEM_ATTRIBUTES_VL WHERE ITEM_TYPE='POAPPRV' AND NAME='PO_DESC RIPTION';
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. NAME: Internal name for the activity. VERSION: It is used to support multiple versions of the same process running at the same time. The version number works in concert wit h 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”. RERUN: Determines if activity is rerun during looping. EXPAND_ROLE: Determines how many roles are required to respond to a notification activity. 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. RESULT_TYPE: If you intend to model transitions in a process based upon values returned by an activity node, then the expected results must be predefined by supplying a lookup type, which is stored in this field. ICON_NAME: Name of activity icon used in process window. 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. ERROR_PROCESS: Workflow process to run in case of an error. ERROR_ITEM_TYPE: Name of item type to execute in case of error. RUNNABLE_FLAG: Flag (Y or N) to indicate if activity is runnable. FUNCTION_TYPE: Indicates whether function type is pl/sql or internal. The Translation table is WF_ACTIVITIES_TL and the related view is WF_ACTIVITIES_VL.

To join this table to the wf_activities tables you must join all three of these fields to their corresponding fields in that table. and VARCHAR2. Some key columns are:        ACTIVITY_ITEM_TYPE: Item type the activity is associated with ACTIVITY_NAME: Internal name of the activity ACTIVITY_VERSION: Version of the activity NAME: Internal name of the attribute SEQUENCE: Order of the attribute within the message TYPE: This field refers to the datatype of the values that the attribute will contain. 4] WF_ACTIVITY_ATTRIBUTES: This table defines attributes which behave as parameters for an activity. and version of the activity. LOOKUP. name. FORM. type of attribute. Activity attributes are only used by function activities. and the format used by the activity. Examples of valid attribute types are DATE. 6 7 SELECT * FROM WF_ACTIVITIES_VL WHERE ITEM_TYPE='POAPPRV' AND NAME='FIND_APPROVE R'. The Translation table is WF_ACTIVITY_ATTRIBUTES_TL and the related view is WF_ACTIVITY_ATTRIBUTES_VL. VALUE_TYPE: Defines if the default is a constant or a reference to an item attribute. DOCUMENT. Notice that the table requires three fields just to identify to which activity the attribute is attached: the item_type. . 3 4 SELECT * FROM WF_ACTIVITIES_TL WHERE ITEM_TYPE='POAPPRV' 5 AND NAME='FIND_APPROVER'. Each row includes the associated activity. ITEMATTR.1 SELECT * FROM WF_ACTIVITIES WHERE ITEM_TYPE='POAPPRV' 2 AND NAME='FIND_APPROVER'.

Each message. so the only way to uniquely identify the node to which this attribute is attached is to use the process_activity_id.01 SELECT * 02 FROM WF_ACTIVITY_ATTRIBUTES 03 WHERE ACTIVITY_ITEM_TYPE='POAPPRV' 04 AND ACTIVITY_NAME 05 AND ACTIVITY_VERSION 06 07 08 09 (SELECT VERSION FROM WF_ACTIVITIES WHERE ITEM_TYPE='POAPPRV' AND NAME ='GET_NOTIFICATION_ATTRIBUTE' ='GET_NOTIFICATION_ATTRIBUTE' = 1 AND TRUNC(SYSDATE) BETWEEN TRUNC(BEGIN_DATE) AND TRUNC(NVL(END_DATE. They can found in the “body” and “html_body” fields. Each row includes the process activity id and the associated value for the attribute. 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 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. 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.SYSDATE 0 )) 11 ). . 6] WF_MESSAGES: The messages that are associated with notifications are stored in this table. The actual text of the message is stored only in its localization table (wf_messages_tl). 1 SELECT * FROM WF_ACTIVITY_ATTR_VALUES WHERE NAME='NTF_USER_NAME'.

Message attributes define additional information that is to be sent to. or received from the user. 3 4 SELECT * FROM WF_MESSAGES_TL 5 WHERE TYPE='POAPPRV' AND NAME='NOTIFY_BUYER'. 7] WF_MESSAGE_ATTRIBUTES: This table contains message attribute definitions. Each message may have zero or more message attributes. .1 SELECT * FROM WF_MESSAGES 2 WHERE TYPE='POAPPRV' AND NAME='NOTIFY_BUYER'. 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.

='APPROVE_PO_SUB_PROCESS'. The values stored in “from_process_activity” and “to_process_activity” are numbers which represe nt the instance_id of the records from wf_process_activities from which and to which the transition is moving. Instead this information is stored in this table. and “result_code”. the node toward which the arrow points. causes the transition to be followed. 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. Not surprisingly.1 SELECT * FROM WF_MESSAGE_ATTRIBUTES 2 WHERE MESSAGE_TYPE='POAPPRV' 3 AND MESSAGE_NAME 4 AND NAME 8] WF_PROCESS_ACTIVITIES: A process is a sequence of activities performed in a pre-determined order. it is those three fields which are the most impor tant fields in this table: “from_process_activity”. when returned by the beginning node. ='NOTIFY_BUYER' ='BUYER_DISPLAY_NAME'. and the result which. 1 SELECT * FROM WF_PROCESS_ACTIVITIES 2 WHERE PROCESS_ITEM_TYPE='POAPPRV' 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. A transition is defined by three discrete pieces of information: the node where the arrow begins. 01 SELECT * . “to_process_activity”.

) (SELECT INSTANCE_ID FROM WF_PROCESS_ACTIVITIES WHERE PROCESS_ITEM_TYPE='POAPPRV' AND PROCESS_NAME AND INSTANCE_LABEL AND PROCESS_VERSION ='APPROVE_PO_SUB_PROCESS' ='START' = (SELECT MAX(PROCESS_VERSION) FROM WF_PROCESS_ACTIVITIES WHERE PROCESS_ITEM_TYPE='POAPPRV' AND PROCESS_NAME AND INSTANCE_LABEL ) ='APPROVE_PO_SUB_PROCESS' ='START' 17 AND TO_PROCESS_ACTIVITY = (SELECT INSTANCE_ID FROM WF_PROCESS_ACTIVITIES WHERE PROCESS_ITEM_TYPE='POAPPRV' AND PROCESS_NAME AND INSTANCE_LABEL AND PROCESS_VERSION ='APPROVE_PO_SUB_PROCESS' ='IS_DOCUMENT_APPROVED' = (SELECT MAX(PROCESS_VERSION) FROM WF_PROCESS_ACTIVITIES WHERE PROCESS_ITEM_TYPE='POAPPRV' AND PROCESS_NAME AND INSTANCE_LABEL ) ='APPROVE_PO_SUB_PROCESS' ='IS_DOCUMENT_APPROVED' 10] WF_LOOKUP_TYPES_TL & WF_LOOKUPS_TL: Wf_lookup_types_tl is the table used to set up the types of results expected from Workflow activities like functions and notifications. it holds the groupings of the result_codes – the names you see in the Workflow Builder as the names of the Lookups.02 FROM WF_ACTIVITY_TRANSITIONS 03 WHERE FROM_PROCESS_ACTIVITY = 04 05 06 07 08 09 10 11 12 13 14 15 16 18 19 20 21 22 23 24 25 26 27 28 29 30 ). This table does not contain the actual result values. Wf_lookups_tl is the table that stores the component values that comprise a lookup_type. .

and serial controls. inter-organization options. WF_LOOKUP_TYPES_TL. locator. lot.1 SELECT * 2 FROM WF_LOOKUP_TYPES_TL 3 WHERE ITEM_TYPE='POAPPRV' 4 AND LOOKUP_TYPE='PO_POAPPRV_APPROVE_ACTION'. etc. WF_LOOKUPS_TL. ORACLE WORKFLOW TAGGED WITH ORACLE WORKFLOW TABLES.WF_ITEM_TYPES.WF_PROCESS_ACTIVITIES Key Tables in Oracle Inventory JULY 16. WF_ACTIVITY_TRANSITIONS. WF_ACTIVITIES. for each organization defined in Oracle Inventory. 5 6 SELECT * FROM WF_LOOKUPS_TL 7 WHERE LOOKUP_TYPE='PO_POAPPRV_APPROVE_ACTION'.WF_ACTIVITY_ATTRIBUTES. Table MTL_PARAMETERS Description It maintains a set of default options like general ledger accounts. WF_ACTIVITY_ATTR_VALUES. 2011 4 COMMENTS Here is a brief description of the key tables in Oracle Inventory. WF_MESSAGE_ATTRIBUTES. FILED UNDER APPS TABLES. costing method. WF_MESSAGES. WF_ITEM_ATTRIBUTES. Each organization’s item .

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

and the category.assignment. this table stores the item. an item can be assigned to either many or only one category in that category set. A category set is a categorization scheme for a group of items. It contains the entity definition for category sets. MTL_CATEGORIES_B This is the code combinations table for item categories. MTL_CATEGORY_SETS_TL table holds translated Name and Description for Category Sets. depending on the Multiple Assignments Allowed attribute value in a given category set definition. An item may be assigned to only one category within a category set. STRUCTURE_ID identifies the flexfield structure associated with the category set. This table stores demand and reservation information used in Available To Promise. however. MTL_CATEGORIES_TL table holds translated Description for Categories. MLS is implemented with a pair of tables: MTL_CATEGORIES_B and MTL_CATEGORIES_TL. Items always may be assigned to multiple category sets. Items are grouped into categories within the context of a category set to provide flexible grouping schemes. Category Sets now support multilingual category set name and description. However. Planning and MTL_CATEGORY_SETS_B MTL_DEMAND . the category set. MLS is implemented with a pair of tables: MTL_CATEGORY_SETS_B and MTL_CATEGORY_SETS_TL. Item categories now support multilingual category description. Items may be assigned to different categories in different category sets to represent the different groupings of items used for different purposes.

It is maintained as a stack of receipt records. USER_DEFINED_FLAG will distinguish the two. There are three major row types stored in the table: Summary Demand rows. and Reservation Rows. This table stores a record of every material transaction or cost update performed in Inventory. indicating a list of valid places where this item will physically exist in inventory. TRANSACTION_SOURCE_ID and TRANSACTION_SOURCE_NAME describe what the transaction is and MTL_ONHAND_QUANTITIES MTL_TRANSACTION_TYPES MTL_MATERIAL_TRANSACTIONS . i. The table also stores the TRANSACTION_ACTION_ID and TRANSACTION_SOURCE_TYPE_ID that is associated with each transaction type. etc. 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.other Manufacturing functions. The columns TRANSACTION_TYPE_ID.e. It stores quantity on hand information by control level and location. TRANSACTION_ACTION_ID. which are consumed by issue transactions in FIFO order.. raw material. finished goods. TRANSACTION_SOURCE_TYPE_ID. MTL_SECONDARY_INVENTORIES This is the definition table for the subinventory. A subinventory is a section of inventory. Records are inserted into this table either through the transaction processor or by the standard cost update program. It contains seeded transaction types and the user defined ones. Subinventories are assigned to items (in a many to one relationship). Open Demand Rows.

MTL_ITEM_CATALOG_GROUPS_B MTL_ITEM_REVISIONS_B MTL_ITEM_TEMPLATES_B MTL_DESCRIPTIVE_ELEMENTS MTL_DESCR_ELEMENT_VALUES ORG_ACCT_PERIODS . When an item is defined a starting revision record is written out to this table. It stores the descriptive element values for a specific item. It stores the descriptive element definitions for an item catalog group. An item catalog group consists of items that can be described by the same set of descriptive elements or item properties. This is the definition table for item templates. Descriptive elements are defining properties used to describe in the catalog group. It stores revision levels for an inventory item. When an item is associated with a particular item catalog group. This is the code combinations table for item catalog groups. one row per descriptive element (for that catalog group) is inserted into this table. MTL_ITEM_ATTRIBUTES This table stores information on item attributes. the item inherits the descriptive elements for that group which then behave like additional item attributes. and the kind of validation enforced on the attribute.against what entity it was performed. When an item is associated with an item catalog group. so every item will at least have one starting revision. The table stores the attribute name. 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. the corresponding user-friendly name seen by the users. It holds the open and closed financial periods for organizations. Each row in the table corresponds to an attribute.

. engineering items and purchasing items before loading this information into Oracle Inventory. receipts etc. It temporarily stores the definitions for inventory items. It is the interface point between nonInventory applications and the Inventory demand module. MTL TABLES. Each record can be defined at one of the following levels: Customer. 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. issues. The customer item definition is organization independent. ORACLE INVENTORY TAGGED WITH KEY INVENTORY TABLES. It allows calling applications to post material transactions (movements. Address Category. to Oracle Inventory transaction module.MTL_CUSTOMER_ITEMS It stores customer item information for a specific customer. This table temporarily stores data about inventory item assignments to category sets and categories before loading this information into Oracle Inventory. It stores errors that occur during the item interface process reporting where the errors occurred along with the error messages. 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 temporarily stores revision levels for an inventory item before loading this information into Oracle Inventory. 2011 1 COMMENT Here is a brief description of the key tables in Oracle Projects. and Address. Records inserted into this table are processed by the Demand Manager concurrent program. ORACLE INVENTORY Key Tables in Oracle Projects JULY 9.

It stores valid project status codes. It stores details of all Assignments for a project. Implementationdefined responsibilities or positions assigned to employees on projects are stored here. It stores implementationdefined project classifications that supply default information and PA_PROJECT_ASSETS_ALL PA_PROJECT_ASSIGNMENTS PA_PROJECT_CLASSES PA_PROJECT_ROLE_TYPES PA_PROJECT_STATUSES PA_PROJECT_TYPES_ALL . It contains the class codes of class categories that are used to classify projects. It contains assets information defined for capital projects.Table PA_PROJECTS_ALL Description It stores the highest units of work defined in Oracle Projects.

requirements. It stores implementationdefined classifications of task. PA_TASK_TYPES PA_TRANSACTION_INTERFACE_ALL PA_TRANSACTION_SOURCES PA_IMPLEMENTATIONS_ALL PA_ACTION_SETS . It stores action set templates as well as action sets belonging to an object. It stores implementationdefined sources of imported transactions originating in an external system. PA_TASKS It contains userdefined subdivisions of project work. It contains information about the configuration of an Oracle Projects installation. such as projects.drive some project processing. It is an interface table to import transactions from external sources into Oracle Projects.

Implementationdefined classifications of customer agreements. It stores detail lines of project and task budgets.etc. PA_ACTION_SET_LINES It stores action set lines that belong to an action set or an action set template. It stores attributes of action set types. It contains implementationdefined classifications of types of budgets used for PA_ACTION_SET_TYPES PA_AGREEMENTS_ALL PA_AGREEMENT_TYPES PA_BILL_RATES_ALL PA_BUDGETS PA_BUDGET_LINES PA_BUDGET_TYPES . Information about bill rates and markups of standard bill rate schedules. It has customer contracts that serve as the basis for work authorization. It stores budgets information.

Groups of expenditure items incurred by employees or organizations for an expenditure period. PA_CLASS_CATEGORIES It stores implementationdefined categories for classifying projects. It stores implementationdefined values within class categories that can be used to classify projects.different business purposes. PA_CLASS_CODES PA_EVENTS PA_EVENT_TYPES PA_EXPENDITURES_ALL . It stores entries assigned to tasks that generate revenue and/or billing but are not directly related to expenditure items. It stores implementationdefined classifications of events.

This table stores normalized resource breakdown structure information. Implementationdefined periods against which project performance is measured. Implementationdefined classifications of expenditures charged to projects and tasks. This table stores the RBS element information and the parent-child relationship. It contains resources used in budgeting PA_EXPENDITURE_ITEMS_ALL PA_EXPENDITURE_TYPES PA_PERIODS_ALL PA_RBS_DENORM PA_RBS_ELEMENTS PA_RESOURCES . It contains the smallest units of expenditure charged to projects and tasks.PA_EXPENDITURE_CATEGORIES Implementationdefined groupings of expenditure types by type of cost.

Here are few important tables in each category. Budgeting tables: GL_BUDGET_TYPES: Stores information about budget types. description. PA_SCHEDULES FILED UNDER APPS TABLES. GL_JE_HEADERS: Stores journal entries. short name. PA_ROLE_LISTS It stores lists of roles defined with the system. „STANDARD‟. status. Th is table corresponds to the first window of the Consolidation Mappings form. the number of periods per fiscal year. and other information. This table corresponds to the Journal Sources form. and other information. Each row includes the period type name. GL_DAILY_BALANCES: Stores daily aggregate balances for detail and summary balance sheet accounts in sets of books with average balances enabled. GL_CODE_COMBINATIONS: Stores valid account combinations for each Accounting Flexfield structure within your Oracle General Ledger application. GL_PERIOD_SETS: Stores the calendars you define using the Accounting Calendar form.and project summary amounts. Conversion and consolidation tables: GL_CONSOLIDATION: Stores information about your consolidation mappings. and other information. GL_JE_LINES: Stores the journal entry lines that you enter in the Enter Journals form. It replaces the GL_DAILY_CONVERSION_RATES table. Oracle General Ledger supports only one budget type. This table corresponds to the Account Ranges window of the Transfer Consolidation Data form. GL_CONSOLIDATION_ACCOUNTS: Stores the account ranges that you enter when you consolidate balances using the Transfer Consolidation Data form. KEY PROJECT TABLES. running total debits and credits. Therefore. There is a one-to-many relationship between journal entry batches and journal entries. calendar. this table always contains only one row. description. It also displays calendar schedules. ledger currency. Each row in this table includes the associated batch ID. Journal Tables: GL_JE_BATCHES: Stores journal entry batches. Each row includes a mapping‟s ID. Each row includes the batch name. Period Tables: GL_PERIODS: Stores information about the accounting periods you define using the Accounting Calendar form. GL_DAILY_RATES: Stores the daily conversion rates for foreign currency transactions. It stores the rate to use when converting between two currencies for a given conversion date and conversion type. ORACLE PROJECTS GL Tables JANUARY 11. GL_JE_CATEGORIES: Stores journal entry categories. Each row in this table stores the associated journal entry header ID. . the journal entry name and description. Each row includes the category name and description. 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. and other information. and the debits or credits associated with the journal line. It displays the schedule details for requirements and assignments. ORACLE PROJECTS TAGGED WITH APPS TABLES. the line number. 2011 LEAVE A COMMENT GL Tables General Ledger tables can be grossly classified into following 5 categories. Each journal entry in your Oracle General Ledger application is assigned a source name to indicate how it was created. There is a one-to-many relationship between journal entries and journal entry lines. description. GL_PERIOD_TYPES: Stores the period types you define using the Period Types form. period type. chart of accounts. Each row includes the ledger or ledger set name. GL_JE_SOURCES: Stores journal entry source names and descriptions. and other information about the journal entry. the associated code combination ID. You need one row for each consolidation mapping you define. name.

and then deletes the rows in this table that it used. according to its work shift. FND_CURRENCIES: Stores information about currencies. FND_DESCRIPTIVE_FLEXS: Stores setup information about descriptive flexfields. Each row includes the currency assigned to the account and the entry code for the account. Whenever you start Journal Import from the Import Journals form. Each row includes a name and description of the concurrent program. FND_DATABASE_INSTANCES: Stores instance specific information. FND_DATABASES: It tracks the databases employed by the eBusiness suite. GL. a row is inserted into this table for each source and group id that you specified. When Journal Import completes. FND_FLEX_VALUES: Stores valid values for key and descriptive flexfield segments. GL_BUDGET_INTERIM: It is used internally by Oracle General Ledger applications to post budget balances to the GL_BALANCES table. FND_DOCUMENTS: Stores language-independent information about a document. GL TABLES. FND_CONCURRENT_PROCESSORS: Stores information about immediate (subroutine) concurrent program libraries. GL_INTERFACE_CONTROL: It is used to control Journal Import execution. FND_ATTACHED_DOCUMENTS: Stores information relating a document to an application entity. FND_CONCURRENT_QUEUE_SIZE: Stores information about the number of requests a concurrent manager can process at once. This table stores information about the database that is not instance specific. You insert rows in this table and then use the Import Journals window to create journal batches. FND_CONCURRENT_PROGRAMS: Stores information about concurrent programs. The entry code is either „E‟ for entered or „C‟ for calculated. 2010 1 COMMENT Key FND Tables in Oracle Application Here there are few key FND tables that we use in our AOL queries. FND_CONCURRENT_REQUESTS: Stores information about individual concurrent requests. FND_APPLICATION_TL: Stores translated information about all the applications registered with Oracle Application Object Library. FILED UNDER APPS TABLES. FND_CONCURRENT_PROCESSES: Stores information about concurrent managers. FND_FLEX_VALUE_SETS: . FND_CONC_REQ_OUTPUTS: This table stores output files created by Concurrent Request. FND_CONCURRENT_PROGRAMS_TL: Stores translated information about concurrent programs in each of the installed languages. Interface Tables: GL_INTERFACE: It is used to import journal entry batches through Journal Import. ORACLE APPS Key FND Tables in Oracle Application SEPTEMBER 4.GL_BUDGET_ASSIGNMENTS: Stores the accounts that are assigned to each budget organization. GENERAL LEDGER TAGGED WITH GENERAL LEDGER. Every database has one or more instance. The budget posting program updates the appropriate budget balances in GL_BALANCES based on the rows in this 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. This table corresponds to the Account Assignments window of the Define Budget O rganization form. it deletes these rows from the table. FND_APPLICATION: Stores applications registered with Oracle Application Object Library. FND_EXECUTABLES: Stores information about concurrent program executables. Each row includes one fiscal year‟s worth of budget amounts for an account. FND_DESCRIPTIVE_FLEXS_TL: Stores translated setup information about descriptive flexfields. Rows are added to this table whenever you run the budget posting program. FND_CONCURRENT_QUEUES: Stores information about concurrent managers. FND_APP_SERVERS: This table will track the servers used by the E-Business Suite system. FND_CONCURRENT_REQUEST_CLASS: Stores information about concurrent request types.

FND_PROFILE_OPTIONS: Stores information about user profile options. FND_RESP_FUNCTIONS: Stores security exclusion rules for function security menus. AP_INVOICE_LINES_ALL: It contains records for invoice lines entered manually.PARTY_ID. to link the party record in TCA. tax. and the first form that it uses. Each row includes the name and description of the responsibility. APPS TABLES TAGGED WITH FND TABLES. to link the address record in TCA. receiving. and general information. FND_REQUEST_GROUPS: Stores information about report security groups.Stores information about the value sets used by both key and descriptive flexfields. . Each row includes the supplier reference. 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. FND_RESPONSIBILITY: Stores information about responsibilities. 2010 2 COMMENTS Few Important AP Tables AP_SUPPLIERS:                 This table replaces the old PO_VENDORS table. It stores information about your supplier site level attributes. FND_TABLES: Stores information about the registered tables in your applications. FND_MENUS_TL: Stores translated information about the menus in FND_MENUS. An invoice can have one or more invoice distribution lines and can have one or more scheduled payments. FND_REQUEST_SETS: Stores information about report sets. ORACLE APPS Few Important AP Tables SEPTEMBER 4. and/or associated tax/freight/miscellaneous charges invoiced from a supplier. Each row includes the purchasing. invoice. generated automatically or imported from the Open Interface. There is a row for unique combination of supplier address. There is one row for each invoice you enter. FND_RESPONSIBILITY_TL: Stores translated information about responsibilities. An invoice can have one or more invoice lines. AP_SUPPLIER_SITES_ALL: This table replaces the old PO_VENDOR_SITES_ALL table. ORACLE AOL. The supplier address information is not maintained in this table and is maintained in TCA. FILED UNDER AOL. and values that identify the main menu. purchasing. FND_MENUS: It lists the menus that appear in the Navigate Window. service(s). AP_INVOICES_ALL: It contains records for invoices you enter. FND_TERRITORIES: Stores information for countries. the application it belongs to. FND_SECURITY_GROUPS: Stores information about security groups used to partition data in a Service Bureau architecture. as determined by the System Administrator when defining responsibilities for function security. and general information. operating unit and the business relationship that you have with the supplier. FND_MENU_ENTRIES: Stores information about individual entries in the menus in FND_MENUS. FND_VIEWS: Stores information about the registered views in your applications. Security exclusion rules are lists of functions and menus inaccessible to a particular responsibility. FND_LANGUAGES: Stores information regarding languages and dialects. An invoice line represents goods (direct or indirect materials).LOCATION_ID. It stores information about your supplier level attributes. FND_USER: Stores information about application users. Oracle Purchasing uses this information to determine active suppliers. invoice. alternatively known as territories. FND_SEQUENCES: Stores information about the registered sequences in your applications. The supplier name. The reference to the internal identifier of address in TCA will be stored in AP_SUPPLIER_SITES_ALL. classification.

PAYABLES TAGGED WITH ACCOUNT PAYABLES. For matching holds. It also stores the maturity history for future dated payments. There is one row for each payment you issue to a supplier or refund received from a supplier.ORACLE E-BUSINESS SUITE AR Tables:A Diagrammatic Relation AUGUST 3.                              An invoice line should contain all the attributes that are present on the physical or electronic invoice presented by the supplier. i. AP_BANK_ACCOUNTS_ALL: It contains information about your bank accounts. AP_CHECKS_ALL: It stores information about payments issued to suppliers or refunds received from suppliers. there is one row for each hold placed on an invoice-shipment match. ORACLE APPS. APPS TABLES. AP_HOLDS_ALL: It contains information about holds that you or your Oracle Payables application place on an invoice. There is one row for each batch of invoices you enter. Oracle Payables application stores the supplier name and bank account name for auditing purposes. AP. 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. Your Oracle Payables application uses this information to group together invoices that one person entered in a batch. Your Oracle Payables application does not pay invoices that have one or more unreleased holds recorded in this table. AP_INVOICE_PAYMENTS_ALL: It contains records of invoice payments that you made to suppliers. AP_PAYMENT_SCHEDULES_ALL: This table stores information about scheduled payment information on invoices. Oracle Payables application also stores address information for all payments. Oracle Payables application updates this table when you confirm an automatic payment batch. 2010 LEAVE A COMMENT AR Tables:A Diagrammatic Relation . When you void a payment. Oracle Payables application uses this information to record payments you make to suppliers or refunds you receive from suppliers. FILED UNDER APPS TABLES. For non-matching holds. AP_INVOICE_DISTRIBUTIONS_ALL: It holds the distribution information that is manually entered or system-generated. Any time a payment is cleared or uncleared. AP_PAYMENT_HISTORY_ALL: It stores the clearing/unclearing history for payments. becomes negotiable. once the future dated payment matures. An invoice may have one or more corresponding rows in this table. there is one row for each hold placed on an invoice. An invoice can have multiple distributions. If you enable Batch Control. in case either one is changed after you create the payment. There is one row for each bank account you define and each bank account must be affiliated with one bank branch. a row is inserted into this table for the payment. There is one row for each invoice distribution and a distribution must be associated with an invoice. enter a manual payment. AP_TRIAL_BALANCE: It contains denormalized information about invoices and payments posted to the accrual set of books. AP_BATCHES_ALL: It contains summary information about invoices you enter in batches if you enable the Batch Control Payables option. 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.e. or process a Quick payment. your Oracle Payables inserts an additional payment line that is the negative of the original payment line. each invoice must correspond to a record in this table. The table contains a row for each future dated payment.

The primary key for this table is PARTY_ID. Few Important Columns are   LOCATION_ID: Unique identifier for this location COUNTRY: Country code from the TERRITORY_CODE column in the FND_TERRITORY table . FILED UNDER APPS TABLES. PARTY_ID: Identifier for the party. 2010 9 COMMENTS HZ(TCA) tables in Oracle Receivables This article describes few important HZ tables in AR and their relationships with each other. This table provides physical location information about parties (organizations and people) and customer accounts. Few Important Columns are       PARTY_SITE_ID: Party site identifier.A Diagrammatic Relation between AR Tables Click in the photo to have a better view. 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. LOCATION_ID: Identifier for the party site. Organization. Foreign key to the HZ_LOCATIONS table. The primary key for this table is PARTY_SITE_ID. HZ_LOCATIONS: The HZ_LOCATIONS table stores information about a delivery or postal address such as building number. and directions to a location. One location can optionally be used by one or more parties. The primary key for this table is LOCATION_ID. ORACLE RECEIVABLES HZ tables in Oracle Receivables JULY 1. street address. ADDRESSEE: Addressee information. One party can optionally have one or more party sites. PARTY_SITE_NAME: User-defined name for the site. RECEIVABLES TAGGED WITH AR. PARTY_SITE_NUMBER: Party site number. HZ_PARTY_SITES: The HZ_PARTY_SITES table links a party (HZ_PARTIES) and a location (HZ_LOCATIONS) and stores location-specific party information. Group or Relationship. postal code. Foreign key to the HZ_PARTIES table. AR TABLES. 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 HZ_CUST_SITE_USES_ALL table also stores operating unit identifier. and a professional account for a consulting practice. Customer account sites are addresses. Since a party can have multiple customer accounts. for example Bill-To. I for internal customers. N for other customer account sites. This table is a child of the HZ_CUST_ACCT_SITES_ALL table. Ship-To. this table might contain several records for a single party. and customer account sites for one customer account can belong to multiple operating units. R for revenue generating external customers. One customer account can have multiple customer account sites. with the foreign key CUST_ACCT_SITE_ID. The primary key for this table is PROFILE_CLASS_ID. an individual person can establish a personal account. and Statements. where the deploying company does business with its customers. Foreign key to the HZ_CUST_ACCOUNTS table. HZ_CUST_SITE_USES_ALL: The HZ_CUST_SITE_USES_ALL table stores business purposes assigned to customer account sites. HZ_PARTY_RELATIONSHIPS: The HZ_PARTY_RELATIONSHIPS table stores information about relationships between parties. Foreign key to the HZ_CUST_ACCT_SITES_ALL table SITE_USE_CODE: Business purpose assigned to customer site account. Each customer account site can have one or more purposes. SHIP_TO_FLAG: Indicates if this is a Ship-To site.        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 HZ_CUST_ACCOUNTS: The HZ_CUST_ACCOUNTS table stores information about customer accounts . The primary key for this table is CUST_ACCOUNT_ID. for customer accounts. The primary key for this table is SITE_USE_ID. 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. or business relationships that the deploying company establishes with a party of type Organization or Person. and Statements. . For example. MARKET_FLAG: Indicates if this is a Marketing site. though the HZ_CUST_ACCT_SITES_ALL table itself stores the operating unit for customer account sites. ACCOUNT_NUMBER: Account Number CUSTOMER_TYPE: Receivables lookup code for the CUSTOMER_TYPE attribute. CUSTOMER_CLASS_CODE: Customer class identifier HZ_CUST_ACCT_SITES_ALL: The HZ_CUST_ACCT_SITES_ALL table stores all customer account sites across all operating units. Few Important Columns are    CUST_ACCOUNT_PROFILE_ID: Unique identifier of this customer profile CUST_ACCOUNT_ID: Identifier for the Customer Account. The characteristics specified in this table can be used as default characteristics for similar customer accounts. Few Important Columns are      CUST_ACCOUNT_ID: Customer account identifier PARTY_ID: A foreign key to the HZ_PARTY table. A profile class defined in the HZ_CUSTOMER_PROFILE_CLASSES table can be used to provide default values for the attributes in this table. Foreign key to the HZ_CUST_ACCOUNTS table PARTY_SITE_ID: Identifier for a party site. PRIMARY_FLAG: Indicates if this site is the primary site for this customer account. Few Important Columns are     SITE_USE_ID: Site use identifier CUST_ACCT_SITE_ID: Identifier for the customer account site. Y for the primary customer account site. 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. The primary key for this table is CUST_ACCOUNT_PROFILE_ID. Market. STATUS: Indicates whether the profile is active or inactive 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. such as Bill-To. Foreign key to the HZ_PARTY_SITES table BILL_TO_FLAG: Indicates if this is a Bill-To site. family account. This table focuses on business relationships and how transactions are conducted in the relationship.

You're Reading a Free Preview

Download
scribd
/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->