Oracle Apps Tables

GL_SETS_OF_BOOKS stores information about the sets of books you define in your Oracle General Ledger application. Each row includes the set of books name, description, functional currency, and other information. This table corresponds to the Set of Books form.

GL_IMPORT_REFERENCES stores individual transactions from subledgers that have been summarized into Oracle General Ledger journal entry lines through the Journal Import process. You can specify the journal entry sources for which you want to maintain your transaction’s origin by entering ’Yes’ in the Import Journal References field of the Journal Sources form.

For each source that has Import Journal References set to ’Yes’, Oracle General Ledger will populate GL_IMPORT_REFERENCES with one record for each transaction in your feeder system.

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. Each row in this table has a corresponding inverse row in which the from and to currencies are switched.

For example, if this table contains a row with a from_currency of YEN, a to_currency of CND, a conversion_type of Spot, and a conversion_date of January 1, 1997, it will also contain a row with a from_currency of CND, a to_currency of YEN, a conversion_type of Spot, and a conversion_date of January 1, 1997.

In general, this row will contain a rate that is the inverse of the matching row. One should never insert directly into this table. They should instead insert into the DAILY_RATES_INTERFACE table. Data inserted into the GL_DAILY_RATES_INTERFACE table will be automatically copied into this table.

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 journalline. STATUS is ’U’ for unposted or ’P’ for posted.

GL_PERIODS stores information about the accounting periods you define using the Accounting Calendar form. Each row includes the start date and end date of the period, the period type, the fiscal year, the period number, and other information. There is a one–to–many relationship between a row in the GL_PERIOD_SETS table and rows inthis table.

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. This table corresponds to the Journals window of the Enter Journals form.STATUS is ’U’ for unposted, ’P’ for posted. Other statuses indicate that an error condition was found.CONVERSION_FLAG equal to ’N’ indicates that you manually changed a converted amount in the Journal Entry Lines zone of a foreign currency journal entry. In this case, the posting program does not re–convert your foreign amounts. This can happen only if your user profile option MULTIPLE_RATES_PER_JE is ’Yes’. BALANCING_SEGMENT_VALUE is null if there is only one balancing segment value in your journal entry. If there is more than one, BALANCING_SEGMENT_VALUE is the greatest balancing segmentvalue in your journal entry.

GL_JE_BATCHES stores journal entry batches. Each row includes the batch name, description, status, running total debits and credits, and other information. This table corresponds to the Batch window of the Enter Journals form. STATUS is ’U’ for unposted, ’P’ for posted, ’S’ for selected, ’I’ for in the process of being posted. Other values of status indicate an error condition. STATUS_VERIFIED is ’N’ when you create or modify an unposted journal entry batch.

The posting program changes STATUS_VERIFIED to ’I’ when posting is in process and ’Y’ after posting is complete.

GL_BALANCES stores actual, budget, and encumbrance balances for detail and summary accounts. This table stores functional currency, foreign currency, and statistical balances for each accounting period that has ever been opened.

ACTUAL_FLAG is either ’A’, ’B’, or ’E’ for actual, budget, or encumbrance balances, respectively. If ACTUAL_FLAG is ’B’, then BUDGET_VERSION_ID is required. If ACTUAL_FLAG is ’E’, then ENCUMBRANCE_TYPE_ID is required.

GL_BALANCES stores period activity for an account in the PERIOD_NET_DR and PERIOD_NET_CR columns. The table stores the period beginningbalances in BEGIN_BALANCE_DR and BEGIN_BALANCE_CR.

An account’s year–to–date balance is calculated as BEGIN_BALANCE_DR – BEGIN_BALANCE_CR + PERIOD_NET_DR – PERIOD_NET_CR.Detail and summary foreign currency balances that are the result of posted foreign currency journal entries have TRANSLATED_FLAG set to ’R’, to indicate that the row is a candidate for revaluation.

For foreign currency rows, the begin balance and period net columns contain the foreign currency balance, while the begin balance and period net BEQ columns contain the converted functional currency balance.Detail foreign currency balances that are the result of foreign currency translation have TRANSLATED_FLAG set to ’Y’ or ’N’. ’N’ indicates that the translation is out of date (i.e., the account needs to be re–translated). ’Y’ indicates that the translation is current.

Summary foreign currency balances that are the result of foreign currency translation have TRANSLATED_FLAG set to NULL. All summary account balances have TEMPLATE_ID not NULL. The columns that end in ADB are not used. Also, the REVALUATION_STATUS column is notused. 

GL_CODE_COMBINATIONS stores valid account combinations foreach Accounting Flexfield structure within your Oracle General Ledgerapplication. Associated with each account are certain codes and flags,including whether the account is enabled, whether detail posting ordetail budgeting is allowed, and others.Segment values are stored in the SEGMENT columns. Note that eachAccounting Flexfield structure may use different SEGMENT columnswithin the table to store the flexfield value combination. Moreover, the SEGMENT columns that are used are not guaranteed to be in any order.The Oracle Application Object Library table FND_ID_FLEX_SEGMENTS stores information about which column in this table is used for each segment of each Accounting Flexfieldstructure. Summary accounts have SUMMARY_FLAG = ’Y’ and TEMPLATE_ID not NULL. Detail accounts have SUMMARY_FLAG = ’N’ and TEMPLATE_ID NULL.

AR_RECEIVABLES_TRX_ALLThis table links accounting information with your ReceivablesActivities. Possible types of activities include Adjustment,Miscellaneous Cash, and Finance Charges. If your type is MiscellaneousCash, you can associate either a distribution set or a standardaccounting flexfield to your Receivables Activity. Oracle Receivablesuses one row for each activity. You use your receivables activities tospeed receipt entry and generate finance charges. The other types ofactivities that were valid in release 9 and no longer valid in Release 10were converted (as part of the upgrade) such that the actual accountingflexfield CODE_COMBINATION_ID is stored in the table instead of theRECEIVABLES_TRX_ID. In Release 9, all of these references were inAR_BATCH_SOURCES; they are now inAR_RECEIPT_METHOD_ACCOUNTS_ALL. The primary key for thistable is RECEIVABLES_TRX_ID.

AR_RECEIVABLE_APPLICATIONS_ALLThis table stores all accounting entries for your cash and credit memoapplications. Each row includes the amount applied, status, andaccounting flexfield information. Possible statuses of your applicationsinclude APP, UNAPP, ACC, and UNID. You use this information todetermine the applications of your payments or credit memos.CONFIRMED_FLAG is a denormalization fromAR_CASH_RECEIPTS_ALL.

 If the cash receipt is not confirmed, theapplications of that receipt are not reflected in the payment schedule ofthe transaction it is applied against. There are two kinds of applications:CASH and CM (for credit memo applications). This is stored in thecolumn APPLICATION_TYPE.

CASH applications represent applications of a cash receipt. When a cash receipt is initially created, a row is created in this table that has a status of UNAPP for the amount ofthe cash receipt. Each subsequent application creates two rows – onewith a status of APP for the amount being applied to the invoice andone with status UNAPP for the negative of the amount being applied. Ifyou reverse a cash application, a row with status APP with the inverseamount of the original application (i.e. the negative of the originalapplication amount) is created. The corresponding UNAPP rows is alsocreated which will have a positive amount (the same amount as theapplication being reversed). For example: UNAPP 100 creation of a$100 cash receipt APP 60 application of $60 of this cash receiptUNAPP –60 this row takes away (debits) unapplied APP –60reversal of the $60 application UNAPP 60 this rows puts back(credits) unapplied The sum of the AMOUNT_APPLIED column forCASH applications should always equal the amount of the cash receipt.CM applications, on the other hand, do not have rows of status UNAPP.They only use rows with a status of APP. CASH_RECEIPT_ID stor esthe cash receipt identifier of the receipt you entered. Oracle Receivablesconcurrently creates a record of this receipt in theAR_CASH_RECEIPTS_ALL table.

This column is null for a credit memo application. CODE_COMBINATION_ID stores valid Accounting Flexfield segment value combinations that will be credited in theGeneral Ledger when this application is posted. A negative value inAMOUNT_APPLIED becomes a debit. The STATUS of a receivableapplication determines which flexfield account Oracle Receivables uses.For example, if you enter a cash receipt of $500 as Unidentified, OracleReceivables creates a record in theAR_RECEIVABLE_APPLICATIONS_ALL table withAMOUNT_APPLIED = 500 and STATUS = ’UNID’. Oracle Receivables

uses the foreign key CODE_COMBINATION_ID to associate thispayment with the Unidentified flexfield account. CUSTOMER_TRX_ID,CASH_RECEIPT_ID, and PAYMENT_SCHEDULE_ID identify the transaction that you are actually applying.APPLIED_CUSTOMER_TRX_ID and APPLIED_PAYMENT_SCHEDULE_ID identify the invoice or credit memo that receives the application. For example, if you apply a receiptagainst an invoice, Oracle Receivables creates a record in theAR_RECEIVABLE_APPLICATIONS_ALL table. The CASH_RECEIPT_ID and the PAYMENT_SCHEDULE_ID of this record identify the receipt you are applying.APPLIED_PAYMENT_SCHEDULE_ID and APPLIED_CUSTOMER_TRX_ID for this record belong to the invoice that is receiving the application. If you apply a credit memo against the invoice, Oracle Receivables creates a record in the AR_RECEIVABLE_APPLICATIONS_ALL table that has theCUSTOMER_TRX_ID and the PAYMENT_SCHEDULE_ID of the creditmemo you are applying. The APPLIED_PAYMENT_SCHEDULE_IDand the APPLIED_CUSTOMER_TRX_ID of this record belong to theinvoice that is receiving the application. If you combine an on accountcredit and a receipt, Oracle Receivables creates a record in t heAR_RECEIVABLE_APPLICATIONS_ALL table.

The PAYMENT_SCHEDULE_ID and the CASH_RECEIPT_ID of this recordidentify the receipt. The APPLIED_PAYMENT_SCHEDULE_ID and theAPPLIED_CUSTOMER_TRX_ID of this record identify the on accountcredit that you are combining with the receipt. The primary key for thistable is RECEIVABLE_APPLICATION_ID, which uniquely identifies thetransaction that created the row.

RA_CUST_TRX_LINE_GL_DIST_ALLThis table stores the accounting records for revenue, unearned revenueand unbilled receivables for each invoice or credit memo line. Each rowincludes the GL account and the amount of the accounting entry. TheAMOUNT column in this table is required even though it is nullallowed.

You need one row for each accounting distribution. You musthave at least one (but you can have multiple) accounting distributionsfor each invoice or credit memo line. Oracle Receivables uses thisinformation to post the proper amounts to your general ledger. If yourinvoice or credit memo has a transaction type where Post to GL is set toNo, Oracle Receivables assigns Null to GL_DATE.

If your AutoAccounting is unable to complete your general ledger defaultaccounts using the AutoAccounting rules you define, incompletegeneral ledger accounts are stored in CONCATENATED_SEGMENTS.If you are importing a transaction through AutoInvoice and the general

ledger date of your transaction is in a closed accounting period,AutoInvoice uses the general ledger date of the first open accountingperiod and stores the original general ledger date inORIGINAL_GL_DATE. ACCOUNT_CLASS defines which type ofdistribution row you are on.

The ACCOUNT_CLASS REC represents the receivable account and is for the total amount of the invoice. Therecan be at most two REC rows. One that has a ACCOUNT_SET_FLAGset to Y and the other has ACCOUNT_SET_FLAG set to N. UseLATEST_REC_FLAG to join to the later of the two rows.ACCOUNT_SET_FLAG is Y if this row is part of an account set. Anaccount set is a set of rows that represent a model distribution. Accountsets are used for invoices with rules. The rows represent how the actualdistribution rows should be created and what percentage of the actualdistribution should be allocated to each account.

For invoices with rules, the distributions are not created when the invoice is initiallycreated. Instead, the invoices are created when the Revenue Recognitionprogram is run. The primary key for this table is CUST_TRX_LINE_GL_DIST_ID.

 

AR_PAYMENT_SCHEDULES_ALLThis table stores all transactions except adjustments and miscellaneouscash receipts. Oracle Receivables updates this table when activity occursagainst an invoice, debit memo, chargeback, credit memo, on accountcredit, or receipt. Oracle Receivables groups different transactions bythe column CLASS. These classes include invoice (INV), debit memos(DM), guarantees (GUAR), credit memos (CM), deposits (DEP),chargebacks (CB), and receipts (PMT).

Transaction classes determine which columns in this table Oracle Receivables updates when atransaction occurs, and whether a transaction relates to either theRA_CUSTOMER_TRX_ALL table or the AR_CASH_RECEIPTS_ALLtable. AR_PAYMENT_SCHEDULES_ALL joins to theRA_CUSTOMER_TRX_ALL table for non–payment transaction entriessuch as the creation of credit memos, debit memos, invoices,chargebacks, or deposits.

AR_PAYMENT_SCHEDULES_ALL uses the foreign key CUSTOMER_TRX_ID to join to theRA_CUSTOMER_TRX_ALL table for these transactions.AR_PAYMENT_SCHEDULES_ALL joins to the AR_CASH_RECEIPTS_ALL table for invoice–related payment

transactions using the foreign key CASH_RECEIPT_ID. When a receiptis applied, Oracle Receivables updates AMOUNT_APPLIED, STATUSand AMOUNT_DUE_REMAINING. STATUS changes from ’OP’ to ’CL’for any transaction that has an AMOUNT_DUE_REMAINING value of0.

ACTUAL_DATE_CLOSED and GL_DATE_CLOSED are populatedwith the date of the latest transaction. For a receipt, the amount dueremaining includes on account and unapplied amounts. OracleReceivables stores debit items such as invoices, debit memos,chargebacks, deposits, and guarantees as positive numbers in theAMOUNT_DUE_REMAINING and AMOUNT_DUE_ORIGINALcolumns. Credit items such as credit memos and receipts are stored asnegative numbers. In Release 10, receipts can be confirmed or notconfirmed as designated by the CONFIRMED_FLAG column. The sumof the AMOUNT_DUE_REMAINING column for a customer for allconfirmed payment schedules reflects the current customer balance. Ifthis amount is negative, then this column indicates the credit balanceamount currently available for this customer. For invoices with splitterms, one record is created in RA_CUSTOMER_TRX_ALL and onerecord is stored in AR_PAYMENT_SCHEDULES_ALL for eachinstallment. In AR_PAYMENT_SCHEDULES_ALL, DUE_DATE andAMOUNT_DUE_REMAINING can differ for each installment of a splitterm invoice. Each installment is differentiated by theTERMS_SEQUENCE_NUMBER column.

If you create a debit memo reversal when you reverse a receipt, Oracle Receivables creates a newpayment schedule record for the debit memo and fills inREVERSED_CASH_RECEIPT_ID with the CASH_RECEIPT_ID of thereceipt that was reversed. Oracle Receivables creates a new paymentschedule record when you create a chargeback in the Receipts window.ASSOCIATED_CASH_RECEIPT_ID is the cash receipt of the paymentyou entered when you created the chargeback in this window.GL_DATE_CLOSED indicates the general ledger date on which yourtransaction was closed.

This column identifies which transactions Oracle Receivables selects when it displays current and overdue debititems in the aging reports. The aging reports also utilize the currentbalances in AMOUNT_DUE_REMAINING to display outstandingamounts for current and overdue debit items.ACTUAL_DATE_CLOSED gives the date on which you applied apayment or credit to an open transaction that setAMOUNT_DUE_REMAINING to 0 for that transaction. Oracle

Receivables uses ACTUAL_DATE_CLOSED to determine whichtransactions to include when you print statements. The primary key forthis table is PAYMENT_SCHEDULE_ID, which identifies the transactionthat created the row.

RA_CUSTOMER_TRX_ALLThis table stores invoice, debit memo, commitment, and credit memoheader information. Each row includes general invoice informationsuch as customer, transaction type, and printing instructions. You needone row for each invoice, debit memo, commitment, and credit memoyou create in Oracle Receivables.

Invoices, debit memos, credit memos,and commitments are all distinguished by their transaction types storedin RA_CUST_TRX_TYPES_ALL. If you entered a credit memo,PREVIOUS_CUSTOMER_TRX_ID stores the customer transactionidentifier of the invoice you credited. In the case of on account credits,which are not related to any invoice at creation,PREVIOUS_CUSTOMER_TRX_ID is null. If you created an invoiceagainst a commitment, Oracle Receivables stores the customertransaction identifier of the commitment inINITIAL_CUSTOMER_TRX_ID, otherwise it is null.COMPLETE_FLAG stores ’Y’ for Yes and ’N’ for No to indicate if yourinvoice is complete.

When you complete an invoice, Oracle Receivablescreates your payment schedules and updates any commitments againstthis invoice. Before an invoice can be completed, it must have at leastone invoice line, revenue records must exist for each line and add up tothe line amount, and a sales tax record must exist for each line.SOLD_TO_CUSTOMER_ID, SOLD_TO_SITE_USE_ID,BILL_TO_CUSTOMER_ID, BILL_TO_SITE_USE_ID,SHIP_TO_SITE_USE_ID, PRINTING_OPTION, PRINTING_PENDING,TERM_ID, REMIT_TO_ADDRESS_ID, PRIMARY_SALES_REP_ID, andINVOICE_CURRENCY_CODE are required even though they are nullallowed. The primary key for this table is CUSTOMER_TRX_ID.

 

RA_CUSTOMER_TRX_LINES_ALLThis table stores information about invoice, debit memo, credit memo,and commitment lines. For example, an invoice can have one line forProduct A and another line for Product B. You need one row for eachline. Invoice, debit memo, credit memo, and commitment lines aredistinguished by the transaction type of the correspondingRA_CUSTOMER_TRX_ALL record.

Also, credit memos are required tohave a value in PREVIOUS_CUSTOMER_TRX_LINE_ID, except onaccount credits which are not related to specific invoices/invoice lines atcreation time, will not have values in this column.QUANTITY_ORDERED stores the amount of product ordered.QUANTITY_INVOICED stores the amount of product invoiced. Forinvoices entered through the window, QUANTITY_ORDERED andQUANTITY_INVOICED must be the same.

For invoices imported through AutoInvoice, QUANTITY_ORDERED andQUANTITY_INVOICED can be different. If you enter a credit memo,QUANTITY_CREDITED stores the amount of product credited.UOM_CODE stores the unit of measure code as defined inMTL_UNITS_OF_MEASURE. UNIT_STANDARD_PRICE stores the listprice per unit for this transaction line. UNIT_SELLING_PRICE storesthe selling price per unit for this transaction line. For transactionsimported through AutoInvoice, UNIT_STANDARD_PRICE andUNIT_SELLING_PRICE can be different. DESCRIPTION,TAXING_RULE, QUANTITY_ORDERED, UNIT_STANDARD_PRICE,UOM_CODE, and UNIT_SELLING_PRICE are required even thoughthey are null allowed.

LINE_TYPE differentiates between the different types of lines that are stored in this table. LINE points to regular invoicelines that normally refer to an item. TAX signifies that this is a tax line.The column LINK_TO_CUST_TRX_LINE_ID references another row inthis table that is the invoice line associated with the row of type TAX.FREIGHT works the same way as TAX but there you can have at mostone FREIGHT type l ine per invoice line of type LINE. You can alsohave one line of type FREIGHT that has a null LINK_TO_CUST_TRX_LINE_ID (and this is referred to as header levelfreight). CHARGES works just like the LINE type. A line_type of ’CB’ iscreated for a Chargeback line. For every row in this table that belongs toa complete transaction (where RA_CUSTOMER_TRX.COMPLETE_FLAG = Y), there must be at leastone row in the table RA_CUST_TRX_LINE_GL_DIST (which storesaccounting information), even for non–postable transactions. Theprimary key for this table is CUSTOMER_TRX_LINE_ID.

AP_PAYMENT_SCHEDULES_ALLAP_PAYMENT_SCHEDULES_ALL contains information aboutscheduled payments for an invoice. You need one row for each time youintend to make a payment on an invoice. Your Oracle Payablesapplication uses this information to determine when to make paymentson an invoice and how much to pay in an automatic payment batch.Values for HOLD_FLAG may be ’Y’ to place a hold on the scheduledpayment, or ’N’ not to do so. Values for PAYMENT_STATUS_FLAGmay be ’Y’ for fully paid payment schedules, ’N’ for unpaid scheduledpayments, or ’P’ for partially paid scheduled payments. For convertedrecords, enter a value for AMOUNT_REMAINING.

AP_HOLDS_ALLAP_HOLDS_ALL contains information about holds that you or yourOracle Payables application place on an invoice. For non–matchingholds, there is one row for each hold placed on an invoice. For matchingholds, there is one row for each hold placed on an invoice–shipmentmatch. An invoice may have one or more corresponding rows in thistable. Your Oracle Payables application does not pay invoices that haveone or more unreleased holds recorded in this table.This table holds information referenced by the Invoice Holds window.In the strictest sense, AP_HOLDS_ALL has no primary key. It ispossible for your Oracle Payables application to place a certain type ofhold on an invoice, then release it, then place another hold of the sametype (if data changes before each submission of Approval), which wouldresult in a duplicate primary key. But for practical purposes, theprimary key is a concatenation of INVOICE_ID, LINE_LOCATION_ID,and HOLD_LOOKUP_CODE.

AP_AE_LINES_ALLAn accounting entry line is an entity containing a proper accountingentry with debits or credits both in transaction currency as well asfunctional currency along with an account and other referenceinformation pointing to the transaction data that originated theaccounting entry line. An accounting entry line is grouped with otheraccounting entry lines for a specific accounting entry header. Any suchgroup of accounting entry lines should result in balanced entries in thefunctional currency.

AP_AE_HEADERS_ALLAn accounting entry header is an entity grouping all accounting entrylines created for a given accounting event and a particular set of books.An accounting entry header can either be transferred over to GL or notat all. That is, either all its accounting entry lines are transferred or noneat all. The transferred to GL status is marked in the

GL_TRANSFER_FLAG. Possible values for GL_TRANSFER_FLAG areY, N, or E. Y indicates that the accounting entry header has beentransferred to GL. N indicates that the accounting entry header has notbeen transferred to GL due to 2 possible reasons: either the transferprocess has not run or it has run but the accounting entry had anaccounting error on it. E indicates that an error was encountered duringthe transfer to GL process.

AP_INVOICES_ALLAP_INVOICES_ALL contains records for invoices you enter. There isone row for each invoice you enter. An invoice can have one or moreinvoice distribution lines. An invoice can also have one or morescheduled payments.An invoice of type EXPENSE REPORT must relate to a row inAP_EXPENSE_REPORT_HEADERS_ALL unless the record has beenpurged from AP_EXPENSE_REPORT_HEADERS_ALL. Your OraclePayables application uses the INTEREST type invoice for interest that itcalculates on invoices that are overdue. Your Oracle Payablesapplication links the interest invoice to the original invoice by insertingthe INVOICE_ID in the AP_INVOICE_RELATIONSHIPS table.

AP_INVOICE_DISTRIBUTIONS_ALLAP_INVOICE_DISTRIBUTIONS_ALL holds the distribution lineinformation that you enter for invoices. There is a row for each invoicedistribution. A distribution line must be associated with an invoice. Aninvoice can have multiple distribution lines.Your Oracle Payables application automatically creates rows in this tablewhen: 1) you choose a distribution set at the invoice level 2) you importexpense reports 3) you match an invoice to a purchase order or receipt; ituses information from the matched purchase order or receipt 4) youimport invoices via the Open Interface Import process 5) you select toautomatically calculate tax 6) you select to automatically dowithholding.Each invoice distribution line has its own accounting date. When youaccount for an invoice, your OraclePayables application createsaccounting events, accounting entry headers and accounting entry linesfor those distribution lines that have accounting dates included in theselected accounting date range for the Payables Accounting Process.The accounting entries can then be transferred over to General Ledgerby running the Transfer to General Ledger process which creates journalentries. Values for POSTED_FLAG may be Y for accounteddistributions or N for distributions that have not been accounted.Values for ACCRUAL_POSTED_FLAG maybe Y if distribution has beenaccounted and system is set up for accrual basis accounting or N ifeither distribution has not been accounted or accrual basis accounting isnot used.

Values for CASH_POSTED_FLAG may be Y if distribution has beenaccounted and system is set up for cash basis accounting, N if eitherdistribution has not been accounted or system is not set up for cash basisaccounting or P if distribution has been partially accounted in the cashset of books.The MATCH_STATUS_FLAG indicates the approval status for thedistribution. Values for the MATCH_STATUS_FLAG can be null or Nfor invoice distributions that Approval has not tested or T fordistributions that have been tested or A for distributions that have beentested and approved.Invoice distributions may be interfaced over/from Oracle Assets orOracle Projects. Your Oracle Payablesapplication sets theASSETS_ADDITION_FLAG to U for distributions not tested by OracleAssets; Oracle Assets then adjusts this flag after it tests a distribution for assignment as an asset.

To avoid the same invoice distribution beinginterfaced to both Oracle Projects and Oracle Assets, you must interfaceany project–related invoice distribution to Oracle Projects before you caninterface it to Oracle Assets. If the project–related invoice distribution ischarged to a capital project in Oracle Projects, Oracle Projectssets theASSET_ADDITION_FLAG to P when the PA_ADDITION_FLAG is setto Y, Z or T. Oracle Assets only picks up invoice distributions with theASSET_ADDITION_FLAGset to U and if project–related, with thePA_ADDITION_FLAG set to Y, Z, or T. PA_ADDITION_FLAG tracksthe status of project–related supplier invoice distribution lines andexpense report distribution lines.

For supplier invoice distributionsentered via Oracle Payables, the PA_ADDITION_FLAGis set to N if thedistribution is project–related, otherwise it is set to E and it is updatedby Oracle Projects when the distribution is processed by the OracleProjects Interface Supplier Invoiceprocess. Oracle Projects sets thePA_ADDITION_FLAG to Y or Z after the item is successfully processed,or may be set to a rejection code if the line is rejected during transfer toOracle Projects; see QuickCodes listing for all the errors. You mustcorrect the rejection reason an try to retransfer the line. For supplierinvoice adjustment lines interfaced from OracleProjects to OraclePayables (which must net to zero with another line), the value for thePA_ADDITION_FLAG is set to T. For expense report distributionsinterfaced from Oracle Projects to Oracle Payables via Invoice Import,this value is set to N. This row is never picked up by the InterfaceSupplier Invoices process based on theAP_INVOICES.INVOICE_TYPE_LOOKUP_CODE = EXPENSEREPORT. For expense report adjustment lines interfaced from OracleProjects to Oracle Payables which net to zero with another line, this

value is set to T. Both lines are associated with the original invoice bythe Oracle Projects Interface Expense Reports to AP process.Values for the ENCUMBERED_FLAG are as follows: Y indicates aregular distribution that has been successfully encumbered by Payables;W indicates a regular distribution that has been encumbered in advisorymode even though insufficient funds existed; H indicates a regulardistribution that has not been encumbered because it was put on hold;Nor null indicates a regular line that has not been encumbered becauseit has not been looked at yet; D is the same as Y for a reversaldistribution line; X is the same as W for a reversal distribution line; P isthe same as H for a reversal distribution line; R indicates a line to beignored by encumbrance and approval code because neither the originalnor the reversal distributions were looked at and they offset each otherso, they can be ignored.

HR_ORGANIZATION_UNITS holds the definitions that identify business groups and the organization units within a single business group. Additional information about classifications and information types for each organization is held in HR_ORGANIZATION_INFORMATION.

HR_ALL_POSITIONS_F is the datetracked table holding position definitions. A position is defined as the unique occurrence of a job in one organization. There can be many different positions that share the same JOB_ID and ORGANIZATION_ID, but each position is uniquely identified by the POSITION_ID and by the NAME. The position nameis a concatenation of flexfield segments stored in the PER_POSITION_DEFINITIONS table.

HR_OPERATING_UNITS is a view based on HR_ORGANIZATION_UNITS andHR_ORGANIZATION_INFORMATION that returns information about operating units.

HRI – Human Resources IntelligenceHXC – Oracle Time and LaborHXT – Oracle Time and Labor RulesIBA – iMarketingIBC – Oracle iContentIBE – iStoreIBP – Bill Presentment & PaymentIBU – iSupportIBY – iPaymentICX – Oracle Self-Service Web ApplicationsIEB – Oracle Interaction BlendingIEC – Oracle Campaign Plus

IEM – Oracle eMail CenterIEO – Call Center TechnologyIES – ScriptingIEU – Oracle Universal Work QueueIEX – Oracle CollectionsIGC – Commitment AdministrationIGF – Student Systems Fin AidIGI – Oracle International Public Sector FinancialsIGS – Oracle Student SytemsIGW – Oracle Grants ProposalIMC – Oracle Customers OnlineIMT – Oracle iMeetingINV – Oracle InventoryIPA – CRL Financials ProjectsIPD – Oracle Product Development ExchangeISC – Supply Chain IntelligenceITG – Oracle Internet Procurement Enterprise ConnectorJA – Asia/Pacific LocalizationsJE – European LocalizationsJG – Regional LocalizationsJL – Latin America LocalizationsJTF – CRM FoundationJTM – Oracle CRM Mobile FoundationJTS – Oracle CRM Self Service AdministrationME – Maintenance, Repair & OverhaulMFG – Oracle ManufacturingMRP – Oracle Master Scheduling/MRPMSC – Oracle Advanced Supply Chain PlanningMSD – Oracle Demand PlanningMSO – Oracle Constraint Based OptimizationMSR – Oracle Risk OptimizationMWA – Mobile ApplicationsODQ – Oracle Data QueryOE – Oracle Order EntryOFA – Oracle AssetsOKB – Oracle Contracts for SubscriptionsOKC – Oracle Contracts CoreOKE – Oracle Project ContractsOKI – Oracle Contracts IntelligenceOKL – Oracle Lease ManagementOKO – Oracle Contracts for SalesOKR – Oracle Contracts for Rights

OKS – Oracle Contracts Service ModuleOKX – Oracle Contracts IntegrationONT – Oracle Order ManagementOPI – Operations IntelligenceOTA – Oracle Training AdministrationOZF – Funds & BudgetsOZP – Trade PlanningOZS – Oracle iClaimsPA – Oracle ProjectsPAY – Oracle PayrollPER – Oracle Human ResourcesPJI – Oracle Project IntelligencePJM – Oracle Project ManufacturingPMI – Process Mfg IntelligencePN – Oracle Property ManagerPO – Oracle PurchasingPOA – Purchasing IntelligencePOM – Oracle ExchangePON – Oracle SourcingPOS – Internet Supplier PortalPQH – Oracle Public Sector HRPQP – Oracle Public Sector PayrollPRP – Oracle ProposalsPSA – Public Sector ApplicationsPSB – Oracle Public Sector BudgetingPSP – Oracle Labor DistributionPV – Partner Relationship ManagementQA – Oracle QualityQOT – Oracle QuotingQP – Oracle PricingQRM – Oracle Risk ManagementRG – Application Report GeneratorRHX – Oracle Advanced Planning FoundationRLA – Oracle Release Management Integration KitRLM – Oracle Release ManagementSHT – Applications Shared TechnologySSP – Oracle SSPSYSADMIN – System AdministrationVEA – Oracle AutomotiveVEH – Oracle Automotive Integration KitWIP – Oracle Work in ProcessWMS – Oracle Warehouse Management System

WPS – Oracle Manufacturing SchedulingWSH – Oracle ShippingWSM – Shop Floor ManagementXDP – Oracle ProvisioningXLA – Oracle Common Accounting ModulesXNB – Oracle eBusiness BillingXNC – Oracle Sales for CommunicationsXNI – Oracle Install Base IntelligenceXNM – Marketing for CommunicationsXNP – Oracle Number PortabilityXNS – Oracle Service for CommunicationsXTR – Oracle TreasuryZFA – Oracle Financial AnalyzerZSA – Oracle Sales Analyzer