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.

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 ro