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.
Look these table also
AR_CASH_RECEIPTS_ALL
AR_MISC_CASH_DISTRIBUTIONS_ALL
AR_CASH_RECEIPTS
AR_MISC_CASH_DISTRIBUTIONS
A typical Lockbox transmission contains various different records,
each with relevant data. Controls are provided at each level to ensure
that the transmission was successful and to verify that the count and
dollar amounts are consistent with what the bank indicated. These
controls are at the transmission, Lockbox, batch and receipt levels. The
records also contain information such as your bank account (by Lockbox)
and the details for the receipts the bank received. The Lockbox may be
used for checks, wires and any other receipts that you receive. You
define what the data from the bank will look like and how you will use
it.
