Base Tables In AP

Base tables:
As told earlier once the data is validated will get updated in the base tables, and is considered as the data which is in the base table is accurate and used in many ways. (Reporting..etc..)
Base Tables in Ap and Po:
The base tables in AP are as follows:

1) AP_INVOICES_ALL 

2) AP_INVOICE_PAYMENTS_ALL 

3) AP_INVOICE_DISTRIBUTIONS_ALL 

4) AP_PAYMENT_SCHEDULES_ALL 

5)AP_PAYMENT_HISTORY_ALL
 
6)AP_CHECKS_ALL 

7) AP_HOLDS_ALL

 
8) AP_AE_LINES_ALL

 
9) AP_AE_HEADERS_ALL

 

1) 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. Your Oracle Payables application uses the INTEREST type invoice for interest that it calculates on invoices that are overdue. Your Oracle Payables application links the interest invoice to the original invoice by inserting the INVOICE_ID in the AP_INVOICE_RELATIONSHIPS table.

2) AP_INVOICE_PAYMENTS_ALL

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.


 3) AP_INVOICE_DISTRIBUTIONS_ALL:

AP_INVOICE_DISTRIBUTIONS_ALL holds the distribution information that is manually entered or system-generated. There is one row for each invoice distribution. A distribution must be associated with an invoice. An invoice can have multiple distributions. Examples of when your Oracle Payables application automatically creates rows in this table include the following:
You choose a distribution set at the invoice header level.
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.
You match a credit or debit memo to an invoice.
You generate charge distributions (tax, freight, misc.) from allocation rules.
You apply a prepayment or unapply a prepayment.
Payables automatically withholds tax.
Payables creates an interest invoice.
When you account for an invoice, the Payables Accounting Process creates accounting events, accounting entry headers and accounting entry lines for those distributions that have accounting dates included in the selected accounting date range. The Transfer to General Ledger process can then transfer the accounting entries to General Ledger as journal entries. Values
for POSTED_FLAG are Y for accounted distributions or N for unaccounted 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.
This table corresponds to the Distributions window.

 

  
4)AP_PAYMENT_SCHEDULES_ALL

AP_PAYMENT_SCHEDULES_ALL contains information about scheduled payments for an invoice. You need one row for each time you intend to make a payment on an invoice. Your Oracle Payables application uses this information to determine when to make payments on 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 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.
.




5) 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. 




6) AP_CHECKS_ALL

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. 


7) AP_HOLDS_ALL

AP_HOLDS_ALL contains information about holds that you or your Oracle Payables application place on an invoice. For non–matching holds, there is one row for each hold placed on an invoice. For matching holds, there is one row for each hold placed on an invoice–shipment match. An invoice may have one or more corresponding rows in this table. Your Oracle Payables application does not pay invoices that have one or more unreleased holds recorded in this table. This table holds information referenced by the Invoice Holds window. 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 Approval), 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.

  

8) AP_AE_LINES_ALL

An accounting entry line is an entity containing a proper accounting entry with debits or credits both in transaction currency as well as functional currency along with an account and other reference information pointing to the transaction data that originated the accounting entry line. 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.

9)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.