Useful AR Tables Informations

Hello Friends, here is some of quite commonly used AR ( receivables )tables and their
usage. There are many other tables also in AR but here i am putting only few commonly
used tables. For other table if needed we can dig furthur. Let go through below article and
let me know if it useful.

1- RA_CUSTOMER_TRX_ALL

2- RA_CUSTOMER_TRX_LINES_ALL

3- RA_CUST_TRX_LINE_GL_DIST_ALL

4- AR_PAYMENT_SCHEDULES_ALL

5- AR_RECEIVABLES_TRX_ALL

6- AR_RECEIVABLE_APPLICATIONS_ALL

RA_CUSTOMER_TRX_ALL

This table stores invoice, debit memo, commitment, and credit memo header information.
Each row includes general invoice information such as customer, transaction type, and
printing instructions. You need one row for each invoice, debit memo, commitment, and
credit memo you create in Oracle Receivables. Invoices, debit memos, credit memos, and
commitments are all distinguished by their transaction types stored in
RA_CUST_TRX_TYPES_ALL. If you entered a credit memo,
PREVIOUS_CUSTOMER_TRX_ID stores the customer transaction identifier 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 invoice
against a commitment, Oracle Receivables stores the customer transaction identifier of
the commitment in INITIAL_CUSTOMER_TRX_ID, otherwise it is null.
COMPLETE_FLAG stores ’Y’ for Yes and ’N’ for No to indicate if your invoice is
complete. When you complete an invoice, Oracle Receivables creates your payment
schedules and updates any commitments against this invoice. Before an invoice can be
completed, it must have at least one invoice line, revenue records must exist for each line
and add up to the line amount, and a sales tax record must exist for each line.
Required Columns:
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, and
INVOICE_CURRENCY_CODE
are required even though they are null allowed. The primary key for this table is
CUSTOMER_TRX_ID.

RA_CUSTOMER_TRX_LINES_ALL

This table stores information about invoice, debit memo, credit memo, and commitment
lines. For example, an invoice can have one line for Product A and another line for
Product B. You need one row for each line. Invoice, debit memo, credit memo, and
commitment lines are distinguished by the transaction type of the corresponding
RA_CUSTOMER_TRX_ALL record.Also, credit memos are required to have a value in
PREVIOUS_CUSTOMER_TRX_LINE_ID, except on account credits which are not
related to specific invoices/invoice lines at creation time, will not have values in this
column. QUANTITY_ORDERED stores the amount of product ordered.
QUANTITY_INVOICED stores the amount of product invoiced. For invoices entered
through the window, QUANTITY_ORDERED and QUANTITY_INVOICED must be
the same. For invoices imported through AutoInvoice, QUANTITY_ORDERED and
QUANTITY_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 in MTL_UNITS_OF_MEASURE.
UNIT_STANDARD_PRICE stores the list price per unit for this transaction line.
UNIT_SELLING_PRICE stores the selling price per unit for this transaction line. For
transactions imported through AutoInvoice, UNIT_STANDARD_PRICE and
UNIT_SELLING_PRICE can be different. DESCRIPTION, TAXING_RULE,
QUANTITY_ORDERED, UNIT_STANDARD_PRICE,UOM_CODE, and
UNIT_SELLING_PRICE are required even though they are null allowed. LINE_TYPE
differentiates between the different types of lines that are stored in this table. LINE points
to regular invoice lines 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 in this 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 most one FREIGHT type l ine per invoice line of type
LINE. You can also have one line of type FREIGHT that has a null
LINK_TO_CUST_TRX_LINE_ID (and this is referred to as header level freight).
CHARGES works just like the LINE type. A line_type of ’CB’ is created for a
Chargeback line. For every row in this table that belongs to a complete transaction
(where RA_CUSTOMER_TRX.COMPLETE_FLAG = Y), there must be at least one
row in the table RA_CUST_TRX_LINE_GL_DIST (which stores accounting
information), even for non–postable transactions. The primary key for this table is
CUSTOMER_TRX_LINE_ID.

RA_CUST_TRX_LINE_GL_DIST_ALL

This table stores the accounting records for revenue, unearned revenue and unbilled
receivables for each invoice or credit memo line. Each row includes the GL account and
the amount of the accounting entry. The AMOUNT column in this table is required even
though it is null allowed. You need one row for each accounting distribution. You must
have at least one (but you can have multiple) accounting distributions for each invoice or
credit memo line. Oracle Receivables uses this information to post the proper amounts to
your general ledger. If your invoice or credit memo has a transaction type where Post to
GL is set to No, Oracle Receivables assigns Null to GL_DATE. If your AutoAccounting
is unable to complete your general ledger default accounts using the AutoAccounting
rules you define, incomplete general 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 accounting period and
stores the original general ledger date in ORIGINAL_GL_DATE. ACCOUNT_CLASS
defines which type of distribution row you are on. The ACCOUNT_CLASS REC
represents the receivable account and is for the total amount of the invoice. There can be
at most two REC rows. One that has a ACCOUNT_SET_FLAG set to Y and the other
has ACCOUNT_SET_FLAG set to N. Use LATEST_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. An
account set is a set of rows that represent a model distribution. Account sets are used for
invoices with rules. The rows represent how the actual distribution rows should be
created and what percentage of the actual distribution should be allocated to each
account. For invoices with rules, the distributions are not created when the invoice is
initially created. Instead, the invoices are created when the Revenue Recognition program
is run. The primary key for this table is CUST_TRX_LINE_GL_DIST_ID.
AR_PAYMENT_SCHEDULES_ALL
This table stores all transactions except adjustments and miscellaneous cash receipts.
Oracle Receivables updates this table when activity occurs against an invoice, debit
memo, chargeback, credit memo, on account credit, 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 a transaction occurs, and whether a transaction relates
to either the RA_CUSTOMER_TRX_ALL table or the
AR_CASH_RECEIPTS_ALLtable. AR_PAYMENT_SCHEDULES_ALL joins to the
RA_CUSTOMER_TRX_ALL table for non–payment transaction entries such 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 the RA_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, STATUS
and AMOUNT_DUE_REMAINING. STATUS changes from ’OP’ to ’CL’for any
transaction that has an AMOUNT_DUE_REMAINING value of 0(Zero).
ACTUAL_DATE_CLOSED and GL_DATE_CLOSED are populated with the date of
the latest transaction. For a receipt, the amount due remaining includes on account and
unapplied amounts. Oracle Receivables stores debit items such as invoices, debit memos,
chargebacks, deposits, and guarantees as positive numbers in the
AMOUNT_DUE_REMAINING and AMOUNT_DUE_ORIGINAL columns. Credit
items such as credit memos and receipts are stored as negative numbers. In Release 10,
receipts can be confirmed or not confirmed as designated by the CONFIRMED_FLAG
column. The sum of the AMOUNT_DUE_REMAINING column for a customer for all
confirmed payment schedules reflects the current customer balance. If this amount is
negative, then this column indicates the credit balance amount currently available for this
customer. For invoices with split terms, one record is created in
RA_CUSTOMER_TRX_ALL and one record is stored in
AR_PAYMENT_SCHEDULES_ALL for each installment. In
AR_PAYMENT_SCHEDULES_ALL, DUE_DATE and
AMOUNT_DUE_REMAINING can differ for each installment of a split term invoice.
Each installment is differentiated by the TERMS_SEQUENCE_NUMBER column.

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

This column identifies which transactions Oracle Receivables selects when it displays
current and overdue debit items in the aging reports. The aging reports also utilize the
current balances in AMOUNT_DUE_REMAINING to display outstanding amounts for
current and overdue debit items. ACTUAL_DATE_CLOSED gives the date on which
you applied a payment or credit to an open transaction that set
AMOUNT_DUE_REMAINING to 0 for that transaction. Oracle Receivables uses
ACTUAL_DATE_CLOSED to determine which transactions to include when you print
statements. The primary key for this table is PAYMENT_SCHEDULE_ID, which
identifies the transaction that created the row.

AR_RECEIVABLES_TRX_ALL

This table links accounting information with your Receivables Activities. Possible types
of activities include Adjustment, Miscellaneous Cash, and Finance Charges. If your type
is Miscellaneous Cash, you can associate either a distribution set or a standard accounting
flexfield to your Receivables Activity. Oracle Receivables uses one row for each activity.
You use your receivables activities to speed receipt entry and generate finance charges.
The other types of activities that were valid in release 9 and no longer valid in Release 10
were converted (as part of the upgrade) such that the actual accounting flexfield
CODE_COMBINATION_ID is stored in the table instead of the
RECEIVABLES_TRX_ID. In Release 9, all of these references were in
AR_BATCH_SOURCES; they are now in
AR_RECEIPT_METHOD_ACCOUNTS_ALL. The primary key for this table is
RECEIVABLES_TRX_ID.
AR_RECEIVABLE_APPLICATIONS_ALL
This table stores all accounting entries for your cash and credit memo applications. Each
row includes the amount applied, status, and accounting flexfield information. Possible
statuses of your applications include APP, UNAPP, ACC, and UNID. You use this
information to determine the applications of your payments or credit memos.
CONFIRMED_FLAG is a denormalization from AR_CASH_RECEIPTS_ALL.If the
cash receipt is not confirmed, the applications of that receipt are not reflected in the
payment schedule of the transaction it is applied against. There are two kinds of
applications: CASH and CM (for credit memo applications). This is stored in the column
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
of the cash receipt. Each subsequent application creates two rows – one with a status of
APP for the amount being applied to the invoice and one with status UNAPP for the
negative of the amount being applied. Ifyou reverse a cash application, a row with status
APP with the inverse amount of the original application (i.e. the negative of the original
application amount) is created. The corresponding UNAPP rows is alsocreated which will
have a positive amount (the same amount as the application being reversed). For
example: UNAPP 100 creation of a$100 cash receipt APP 60 application of $60 of this
cash receipt UNAPP –60 this row takes away (debits) unapplied APP –60 reversal of the
$60 application UNAPP 60 this rows puts back(credits) unapplied The sum of the
AMOUNT_APPLIED column for CASH 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 stores the cash receipt
identifier of the receipt you entered. Oracle Receivables concurrently creates a record of
this receipt in the AR_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 the
General Ledger when this application is posted. A negative value in
AMOUNT_APPLIED becomes a debit. The STATUS of a receivable application
determines which flexfield account Oracle Receivables uses. For example, if you enter a
cash receipt of $500 as Unidentified, Oracle Receivables creates a record in
theAR_RECEIVABLE_APPLICATIONS_ALL table with AMOUNT_APPLIED = 500
and STATUS = ’UNID’. Oracle Receivables uses the foreign key
CODE_COMBINATION_ID to associate this payment 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 receipt against an invoice, Oracle Receivables creates a record in the
AR_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 credit memo you are applying. The
APPLIED_PAYMENT_SCHEDULE_ID and the APPLIED_CUSTOMER_TRX_ID of
this record belong to the invoice that is receiving the application. If you combine an on
account credit and a receipt, Oracle Receivables creates a record in the
AR_RECEIVABLE_APPLICATIONS_ALL table.

The PAYMENT_SCHEDULE_ID and the CASH_RECEIPT_ID of this record identify

the receipt. The APPLIED_PAYMENT_SCHEDULE_ID and the
APPLIED_CUSTOMER_TRX_ID of this record identify the on account credit that you
are combining with the receipt. The primary key for this table is
RECEIVABLE_APPLICATION_ID, which uniquely identifies the transaction that
created the row.