AP_INVOICES_ALL

AP_INVOICES_ALL contains records for invoices you enter. There is one row for each invoice you enter.
An invoice can have one or more invoice distribution lines. An invoice can also have one or more
scheduled payments. 
An invoice of type EXPENSE REPORT must relate to a row in AP_EXPENSE_REPORT_HEADERS_ALL
unless the record has been purged from AP_EXPENSE_REPORT_HEADERS_ALL. Oracle Payables
application uses the INTEREST type invoice for interest that it calculates on invoices that are overdue. It
links the interest invoice to the original invoice by inserting the INVOICE_ID in the
AP_INVOICE_RELATIONSHIPS table.

AP_HOLDS_ALL
AP_HOLDS_ALL contains information about holds that you or your Oracle Payables place on an invoice.
For non-matching holds, there is one row for each hold placed on an invoice. For matching holds, there is
one row for each hold placed on an invoice-shipment match. An invoice may have one or more
corresponding rows in this table. Your Oracle Payables application does not pay invoices that have one or
more unreleased holds recorded in this table.

In the strictest sense, AP_HOLDS_ALL has no primary key. It is possible for your Oracle Payables
application to place a certain type of hold on an invoice, then release it, then place another hold of the
same type (if data changes before each submission of Payables Invoice Validation), which would result in
a duplicate primary key. But for practical purposes, the primary key is a concatenation of INVOICE_ID,
LINE_LOCATION_ID, and HOLD_LOOKUP_CODE.

AP_HOLD_CODES
AP_HOLD_CODES contains information about hold codes and release codes that is placed on an
invoice.

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

Examples of when your Oracle Payables application automatically creates rows 

in this table include the following: 
1. You choose a distribution set at the invoice header level.
2. You match an invoice line to a purchase order or receipt. The system uses information from the
matched purchase order or receipt to create the distributions.
3. You match a credit or debit memo to an invoice.
4. You generate charge distributions (tax, freight, misc.) from allocation rules.
5. You apply a prepayment or unapply a prepayment.
6. Payables automatically withholds tax.
7. Payables creates an interest invoice.

Value for Posted_flag is Y for accounted distribution and N for not-accounted distributions.

Invoice distributions can be interfaced over/from Oracle Assets or Oracle Projects. Your Oracle Payables
application sets the ASSETS_ADDITION_FLAG to U for distributions not tested by Oracle Assets; Oracle
Assets then adjusts this flag after it tests a distribution for assignment as an asset. To avoid the same
invoice distribution being interfaced to Oracle Project and Oracle Assets, you must interface any project-
related invoice distribution to Oracle Projects before you can interface it to Oracle Assets. If a project-
related invoice distribution is charged to a capital project in Oracle Projects, Oracle Projects sets the
ASSETS_ADDITION_FLAG to P when the PA_ADDITION_FLAG is set to Y, Z, or T. Oracle Assets only
picks up invoice distributions with the ASSET_ADDITION_FLAG set to U, and if project-related, with the 
PA_ADDITION_FLAG set to Y, Z, or T. PA_ADDITION_FLAG tracks the status of project-related supplier
invoice distributions and expense report distributions. For supplier invoice distributions entered via
Oracle Payables, the PA_ADDITION_FLAG is set to N if the distribution is project-related, otherwise it is
set to E, and it is updated by Oracle Projects when the distribution is processed by the Oracle Projects
Interface Supplier Invoice process. Oracle Projects sets the PA_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 to Oracle
Projects. See Payables Lookup Listing for all the errors. You must correct the rejection reason and try to 
retransfer the line. For supplier invoice adjustment distributions interfaced from Oracle Projects to Oracle
Payables (which must net to zero with another distribution), the value for the PA_ADDITION_FLAG is set
to T.

AP_INVOICE_PAYMENTS_ALL contains records of invoice payments that you made to suppliers. There
is one row for each payment you make for each invoice. There is one payment and one invoice for
each payment in this table. Your 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 application inserts an additional payment line that is the negative of the
original payment line. 
.
Values for POSTED_FLAG may be 'Y' for accounted payments or 'N' for unaccounted payments. Values
for ACCRUAL_POSTED_FLAG may be 'Y' for accounted payments or 'N' for unaccounted payments
under accrual basis accounting; values for CASH_POSTED_FLAG may be 'Y' for accounted payments or
'N' for unaccounted payments under cash basis accounting.
.
For manual payments and Quick payments, this table corresponds to the Select Invoices window in the
Payment workbench.
IBAN_NUMBE VARCHAR (40 International bank account number. Used internationally to uniquely
R 2 ) identify the account of a customer at a financial institution. During bank
entry, the system validates the value to ensure that it is a valid IBAN.

AP_PAYMENT_SCHEDULES_ALL
AP_PAYMENT_SCHEDULES_ALL contains information about scheduled payments for an invoice. 
Values for HOLD_FLAG may be 'Y' to place a hold on the scheduled payment, or 'N' not to do so. Values
for PAYMENT_STATUS_FLAG may be 'Y' for fully paid payment schedules, 'N' for unpaid scheduled
payments, or 'P' for partially paid scheduled payments. For converted records, enter a value for
AMOUNT_REMAINING.

AP_ACCOUNTING_EVENTS_ALL
This table stores all the accounting events and their details. For ex- an invoice may have 3 accounting
events.
Name Datatype Length Mandatory Comments
ACCOUNTING_EVENT_I NUMBER (15) Yes Accounting event identifier
D
EVENT_TYPE_CODE VARCHAR (30) Yes Type of event
2
ACCOUNTING_DATE DATE Yes Accounting date for accounting entries for this event
EVENT_NUMBER NUMBER (15) Yes Accounting event number for a given document (e.g. Invoice #101 may
have 3 accounting events associated with it, the event number acts as
a sequence for Invoice #101)
EVENT_STATUS_CODE VARCHAR (30) Yes Indicates the state of the accounting entries for the accounting event
2
SOURCE_TABLE VARCHAR (30) Yes Table where event originating document resides. Possible values are
2 AP_INVOICES or AP_CHECKS
SOURCE_ID NUMBER (15) Yes Primary key for document originating the current event. Depending on
the value for source_table it will contain either invoice_id or check_id
AP_INV_SELECTION_CRITERIA_ALL
AP_INVOICE_SELECTION_CRITERIA_ALL stores the criteria that a payment batch uses to select
invoices for payment.
Some columns –
Checkrun_name Payment batch name
CHECK_DATE  Date of payment (ie: Payment Date on Payment Batches window)
BANK_ACCOUNT_NAME
PERIOD_NAME
PAY_THRU_DATE
HI_PAYMENT_PRIORITY  Highest payment priority of invoices to select
LOW_PAYMENT_PRIORITY  Lowest payment priority of invoices to select
STATUS  Status of completion of a batch
ORG_ID NUMBER (15) Organization identifier
CHECKRUN_ID NUMBER (15) Payment batch identifier

AP_SELECTED_INVOICES_ALL
AP_SELECTED_INVOICES_ALL is a temporary table that stores information about invoices selected for
payment in a payment batch. Oracle Payables application inserts into this table after you initiate a
payment batch.
There will be one row for each invoice that Payables selects for payment in the current payment batch.
When you build payments in a payment batch, your Oracle Payables application uses information in this
table to create rows in AP_SELECTED_INVOICE_CHECKS. Information from this table appears in the
Modify Payment Batch window.

AP_SELECTED_INVOICE_CHECKS_ALL is a temporary table that stores payment information during a

payment batch. This table is populated when you build payments in a payment batch.

Table Foreign Table Foreign Key Column

AP_SELECTED_INVOICE_CHECKS_A AP_SELECTED_INVOICE_CHECKS_ALL.CHECKRUN_NAME
AP_INV_SELECTION_CRITERIA_
LL
ALL
AP_SELECTED_INVOICE_CHECKS_A AP_SELECTED_INVOICE_CHECKS_ALL.CHECK_ID
AP_CHECKS_ALL
LL
AP_SELECTED_INVOICE_CHECKS_A AP_SELECTED_INVOICE_CHECKS_ALL.VENDOR_ID
PO_VENDORS
LL
AP_SELECTED_INVOICE_CHECKS_A AP_SELECTED_INVOICE_CHECKS_ALL.VENDOR_SITE_ID
PO_VENDOR_SITES_ALL
LL
AP_SELECTED_INVOICE_CHECKS_A AP_SELECTED_INVOICE_CHECKS_ALL.CURRENCY_CODE
FND_CURRENCIES
LL
AP_SELECTED_INVOICE_CHECKS_A AP_SELECTED_INVOICE_CHECKS_ALL.EXTERNAL_BANK_ACCOUNT
AP_BANK_ACCOUNTS_ALL
LL _ID
AP_SELECTED_INVOICE_CHECKS_A AP_SELECTED_INVOICES_ALL.PAY_SELECTED_CHECK_ID
AP_SELECTED_INVOICES_ALL
LL
AP_SELECTED_INVOICE_CHECKS_A AP_SELECTED_INVOICES_ALL.PRINT_SELECTED_CHECK_ID
AP_SELECTED_INVOICES_ALL

AP_AE_HEADERS_ALL
An accounting entry header is an entity grouping all accounting entry lines created for a given
accounting
event and a particular set of books. An accounting entry header can either be transferred over to GL or
not at all. That is, either all its accounting entry lines are transferred or none at all. The transferred to GL
status is marked in the GL_TRANSFER_FLAG. Possible values for GL_TRANSFER_FLAG are Y, N, or
E. Y indicates that the accounting entry header has been transferred to GL. N indicates that the
accounting entry header has not been transferred to GL due to 2 possible reasons: either the transfer
process has not run or it has run but the accounting entry had an accounting error on it. E indicates that
an error was encountered during the transfer to GL process.
Name Datatype Length Mandatory Comments
AE_HEADER_ID NUMBER (15) Yes Accounting entry header identifier
ACCOUNTING_EVENT_ID NUMBER (15) Yes Accounting event identifier
SET_OF_BOOKS_ID NUMBER (15) Yes Set of books identifier
AE_CATEGORY VARCHAR (30) Yes Accounting entry category. The possible values come from
2 GL_JE_CATEGORIES and are: Purchase Invoices, Payments,
Reconciled Payments
CROSS_CURRENCY_FLAG VARCHAR (1) Yes Indicates whether this accounting entry header has accounting
2 entry lines with different entered currencies. This is used by the GL
Transfer program to set the journal category to Cross Currency to
enable GL to create the balancing journal line
PERIOD_NAME VARCHAR (15) Yes Accounting period name
2
ACCOUNTING_DATE DATE Yes Accounting date
GL_TRANSFER_FLAG VARCHAR (1) Yes Indicates whether accounting entry header has been successfully
2 transferred to GL. Possible values are Y, N, E
ACCOUNTING_ERROR_CODE VARCHAR (30) Accounting entry header level error code that was encountered
2 during the Payables Accounting Process
GL_TRANSFER_ERROR_COD VARCHAR (30) Accounting entry header level error code that was encountered
E 2 during the Payables Transfer to GL Process
GL_REVERSAL_FLAG VARCHAR (1) Indicates to GL that the journal should be flagged a reversal
2 journal. Not used by AP
TRIAL_BALANCE_FLAG VARCHAR (1) Y indicates that the accounting entry lines associated with this
2 header record were inserted in the AP_LIABILITY_BALANCE table.

AP_AE_LINES_ALL

It contains accounting entry with debits or credits both in transaction currency as well as
functional currency along with an account. An accounting entry line is grouped with other accounting
entry lines for a specific accounting entry header. Any such group of accounting entry lines should result
in balanced entries in the functional currency.

BANKS-

AP_BANK_BRANCHES
AP_BANK_BRANCHES contains information about the bank branches you define when you set up your
banks. One bank branch may have multiple bank accounts.

AP_BANK_ACCOUNTS_ALL
AP_BANK_ACCOUNTS_ALL contains information about your bank accounts. You need one row for each
bank account you define. Each bank account must be affiliated with one bank branch. When you initiate
an automatic payment batch, enter a manual check, or create a Quick payment, you can select a bank
account that you define in this table.

AP_CHECK_STOCKS_ALL stores information about payment documents you defined for bank
accounts. You need one row for each payment document you use to create payments for a supplier. Each
record in this table must be associated with a bank account. Each bank account corresponds with zero or
more rows in this table. When you initiate a payment batch, record a manual payment, or create a Quick
payment, you can select a payment document that you defined in this table. For a payment document you
use to create automatic payments, DISBURSEMENT_TYPE_LOOKUP_CODE
must be 'COMPUTER GENERATED' or 'COMBINED.'
For manual payments, it must be 'RECORDED' or 'COMBINED.'
.
Your Oracle Payables application updates the LAST_DOCUMENT_NUM when you create payments in
an automatic payment batch, enter a manual payment, or create a Quick payment.

AP_CHECKS_ALL stores information about payments issued to suppliers or refunds received from
suppliers. You need one row for each payment you issue to a supplier or refund received from a supplier.
Your Oracle Payables application uses this information to record payments you make to suppliers or
refunds you receive from suppliers. Your 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. Your
Oracle Payables application stores address information for all payments. If you allow changes to the
supplier payment address on manual payments or Quick payments, your Oracle Payables application
maintains the new address information in this table. Your Oracle Payables application uses
BANK_ACCOUNT_NUM, BANK_NUM, and BANK_ACCOUNT_TYPE for the supplier's bank information
when you use the Electronic payment method. Your Oracle Payables application stores a dummy value
for CHECK_STOCK_ID for refunds, thus, CHECK_STOCK_ID should not be treated as a foreign key to
AP_CHECK_STOCKS_ALL in the case of refunds.

AP_PAYMENT_HISTORY_ALL
AP_PAYMENT_HISTORY_ALL stores the clearing/unclearing history for payments. It also stores the
maturity history for future dated payments. The table contains a row for each future dated payment, once
the future dated payment matures, i.e. becomes negotiable. Any time a payment is cleared or uncleared,
a row is inserted into this table for the payment. The values for TRANSACTION_TYPE can be PAYMENT
MATURITY, PAYMENT CLEARING, or PAYMENT UNCLEARING. Each row in this table also has the
accounting status for the maturity, clearing or unclearing event.