Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
Cathy Lavender
Technical Specialist Oracle
ORACLE
Objective
Source of Receipts
Introduction
Knowing what is involved in the storage of receipts
and their activity against the invoice tables will aid
you in implementing and designing your systems.
This will also assist in diagnosing data problems
and will shorten resolution time from Oracle
Worldwide Customer Support because you will be
able to provide support detailed information to help
resolve your issues.
Reversals and Re-applications of receipts
contribute additional volume of rows on your
applications tables.
Accounting control procedures, such as remittance
and cash clearing approvals can contribute to an
increase in the volume of transactions created on
your history tables.
Types of Receipts
Applied This is a receipt that has been
applied to a particular transaction. Status
is APP.
Receipts
For
non
Approval Controls
You can determine whether Remittance creation
will be required, and whether you will be using a
Cash clearing process. These additional approval
processes contribute to the generation of rows on
AR_CASH_RECEIPT_HISTORY
and
AR_DISTRIBUTIONS tables. A new transaction
will be created for each step in the approval
process.
About Invoices
Paying an invoice
When a receipt is received against an invoice, the
net effect of the receipt is to:
Debit Cash DR for the amount of the receipt
Credit Receivable CR account of the
invoice for the amount of the receipt
Page 2
RELATIONSHIPS
AR_PAYMENT_SCHEDULES
RA_CUSTOMER_TRX
RA_CUSTOMER_TRX_LINES
RA_CUST_TRX_LINE_GL_DIST
Page 3
ON AR_RECEIVABLE_APPLICATIONS
UNID
+100
UNID
-100
UNAPP
+100
UNAPP
-100
ACC
+100
ACC
-100
APP
+100
Initial receipt
DR Cash 100
CR UNID 100
(Note that all the above entries are stored with the
opposite signs.)
When they are passed to General Ledger:
DR CASH
Choose Customer
DR UNID
DR UNID 100
CR UNAPP 100
Putting on Account
CR UNID
CR UNAPP
DR UNAPP
CR APP
100
100
100
100
100
100 (This is for the
receivable account of the invoice)
DR UNAPP 100
CR ACC 100
Take off account and place on an invoice
DR ACC 100
CR APP 100
AR_CASH_RECEIPTS would contain one row for
100
AR_CASH_RECEIPT_HISTORY would contain
one row for 100
AR_DISTRIBUTIONS would contain one row for
100
Reversals
When reversing a receipt the rows are in effect
duplicated with the opposite sign, on the
AR_RECEIVABLE_APPLICATIONS table. On
AR_PAYMENT_SCHEDULES and
AR_CASH_RECEIPTS the original transaction is
updated to reflect the applications.
On AR_CASH_RECEIPTS status is changed to
REV, and there are several updates to
AR_PAYMENT_SCHEDULES.
On AR_PAYMENT_SCHEDULES following a
reversal, the Cash Receipt row is closed with no
amount due remaining, and the Invoices that
application was made to, will have its
applied_amount backed out, and remaining balance
reset.
Amount_due_original
250
Amount_due_remaining
100
Amount_due_original
-100
(note that this is stored as a
negative on the cash row)
Amount_applied
Amount_credited
-250
Amount_due_remaining
-100
Amount_applied
Amount_due_original
250
Amount_due_remaining
-100
Amount_due_remaining
Amount_applied
-100
Amount_applied
100
(note how it is stored as a positive number)
Amount_credited
-250
(note that this is stored as a negative number)
Amount
Currency
Receipt_date
Status
Type
MISC or CASH
Receipt_number
Confirmed_flag
Y or N
Pay_from_customer
Page 5
AR_CASH_RECEIPT_HISTORY
This table contains the steps for the life cycle of a receipt. Each row represents one step. The status field tells
you which step the receipt has reached.
Cash_receipt_history_id
Cash_receipt_id
Status
First_posted_record_flag
Gl_date
Current_record_flag
Indicates which row is the current one for the cash receipt id (Y or N)
Reversal_gl_date
Posting_control_id
Reversal_posting_control_id
Acctd_amount
Amount
AR_DISTRIBUTIONS table is used to store the different steps in the applications life cycle
Line_id
Unique key
Source_id
Cash_receipt_history_id
Code_combination_id
This is the account that we create the journal entry for. Example Cash, or Cash
clearing
Source_type
Amount_dr
Amount_cr
Acctd_amount_dr
Functional currency
Acctd_amount_cr
Functional_currency
Page 6
AR_PAYMENT_SCHEDULES
Payment_schedule_id
Amount_due_original
Amount_due_remaining
Status
Class
PMT for payment, INV for invoice, DM for debit memo, CM for
credit memo
Customer_id
Cash_receipt_id
Gl_date_closed
The accounting date on which the schedule was closed. Default value
for open ones are 31-DEC-4712
Amount_applied
Trx_number
Trx_date
Gl_date
Acctd_amount_due_remaining
Page 7
AR_RECEIVABLE_APPLICATIONS is used to store all accounting entries for your cash and credit
memo applications. Each row includes the amount applied, status, and accounting flexfield information.
Possible statuses include APP, UNAPP, ACC, and UNID. You use this information to determine the
applications of your payments or credit memos. There are two kinds of applications: CASH and CM (for credit
memo applications), which is stored in the Application_type. Credit Memos basically become part of the pot
when included in the application of a receipt. The balance of the credit memo is included with the receipt
amount as the amount available to apply to invoices/debit memos.
Credit Memo applications dont have rows of status UNAPP. Credit Memos only show a status of APP
Receivable_application_id
Amount_applied
Gl_date
Code_combination_id
Gl code combination
Status
Payment_schedule_id
Cash_receipt_id
Applied_customer_trx_id
Applied_customer_trx_line_id
Customer_trx_id
Gl-posted_date
Postable
Posting_control_id
Acctd_amount_applied_from
Confirmed_flag
Application Samples
The number of records created on AR_RECEIVABLE_APPLICATIONS will differ depending on the
transaction For example:
UNIDENTIFIED One record is written to AR_RECEIVABLE_APPLICATIONS (in total)
Application
Type
Amount
Applied
Payment
Schedule Id
Applied
Payment
Schedule Id
Cash
Receipt Id
GL_date
Posting
Control Id
UNID
1.98
Payment
schedule id
of the
receipt
Null
Cash receipt
id
receipt_date
-3
If we were to change the UNIDENTIFIED to UNAPPLIED, these would be the entries (in total):
Application
Type
Amount
Applied
Payment
Schedule Id
Applied
Payment
Schedule Id
Cash
Receipt Id
GL_date
Posting
Control Id
UNID
1.98
Payment
schedule id
of the
receipt
Null
Cash receipt
id
receipt_date
-3
UNID
-1.98
Payment
schedule id
of the
receipt
Null
Cash receipt
id
todays date
-3
UNAPP
1.98
Payment
schedule id
of the
receipt
Null
Cash receipt
id
todays date
-3
Page 9
Receipt Applications
When a receipt is initially created, a row is created in this table that has a status of UNAPP, or UNIDENTIFIED
for the amount of the cash receipt. Each subsequent application creates two rows one with a status of APP for
the amount which is being applied to the invoice and one with status UNAPP or UNID for the negative of the
amount which is being applied. If you reverse an application of cash, a row with status APP with the inverse
amount of the original application (the negative of the original application amount) is created. The
corresponding UNAPP rows are also created which will have a positive amount (the same amount as the
application being reversed).
The sum of the amount_applied column should always equal the amount of the cash receipt.
Unapplied changed to onaccount
If we were to place the UNAPPLIED, On Account These would be the entries (in total)
GL_date
Application
Type
Amount
Applied
Payment
Schedule Id
Applied
Payment
Schedule Id
Cash Receipt
Id
Posting
Control Id
Receipt_date
UNID
1.98
Payment
schedule id
of the receipt
Null
Cash receipt
id
-3
UNID
-1.98
Payment
schedule id
of the receipt
Null
Cash receipt
id
-3
Todays date
UNAPP
1.98
Payment
schedule id
of the receipt
Null
Cash receipt
id
-3
UNAPP
-1.98
Payment
schedule id
of the receipt
Null
Cash receipt
id
-3
Todays date
ACC
1.98
Payment
schedule_id
of the receipt
-1
Cash receipt
id
-3
Page 10
Receipt Applications
Here is an example of an unidentified receipt,followed up by choosing a customer, and then placing the receipt
on account, and finally applying to an invoice. NOTE: (It is not necessary to first place the receipt as
UNIDENTIFIED, this is just an example)
Amount
Applied
Payment
Schedule Id
Applied
Payment
Schedule Id
Cash Receipt
Id
GL_date
Posting
control id
.UNID
1.98
Payment
schedule id
of the receipt
Null
Cash receipt
id
receipt_date
-3
-1.98
Payment
schedule id
of the receipt
Null
Cash receipt
id
todays date
-3
UNAPP
1.98
Payment
schedule id
of the receipt
Null
Cash receipt
id
todays date
-3
-1.98
Payment
schedule id
of the receipt
Null
Cash receipt
id
todays date
-3
ACC
1.98
Payment
schedule id
of the receipt
-1
Cash receipt
id
todays date
-3
-1.98
Payment
schedule id
of the receipt
-1
Cash receipt
id
todays date
-3
APP
1.98
Payment
schedule id
of the receipt
Payment
schedule id
of the
invoice
Cash receipt
id
todays date
-3
Here is an example of a receipt entered, with the customer chosen, specific application
chosen..
Application
Type
Amount
Applied
Payment
Schedule Id
Applied
Payment
Schedule Id
Cash
Receipt Id
Gl_date
Posting
Control Id
UNAPP
1.98
Payment
schedule id
of the receipt
Null
Cash receipt
id
todays date
-3
UNAPP
-1.98
Payment
schedule id
of the receipt
Null
Cash receipt
id
todays date
-3
APP
1.98
Payment
schedule id
of the receipt
Payment
schedule id
of the invoice
Cash receipt
id
todays date
-3
Page 11
Reversals duplicate all the original entries with the opposite signs.
An example You will see the original entries, followed by the additional entries created for the reversal. The
reversal entries have the opposite signs of the original entries
Original Entries
Application
Type
Amount
Applied
Payment
Schedule Id
Applied
Payment
Schedule Id
Cash
Receipt Id
GlDate
Posting
Control Id
UNAPP
1.98
Payment
schedule id
of the
receipt
Null
Cash receipt
id
todays date
-3
UNAPP
-1.98
Payment
schedule id
of the
receipt
Null
Cash receipt
id
todays date
-3
APP
1.98
Payment
schedule id
of the
receipt
Payment
schedule id
of the
invoice
Cash receipt
id
todays date
-3
Reversal Entries
Application
Type
Amount
Applied
Payment
Schedule Id
Applied
Payment
Schedule Id
Cash
Receipt Id
GlDate
Posting
Control Id
UNAPP
-1.98
Payment
schedule id
of the
receipt
Null
Cash receipt
id
Todays date
-3
UNAPP
+1.98
Payment
schedule id
of the
receipt
Null
Cash receipt
id
Todays date
-3
APP
-1.98
Payment
schedule id
of the
receipt
Payment
schedule id
of the
invoice
Cash receipt
id
Todays date
-3
RE-APPLICATIONS remove applications of receipts from one set of invoice to others. This is an example of
one invoice, payment schedule id 306, which has 1.01 applied to it. We will remove this application.
Original
Application
Type
Amount
Applied
Payment
Schedule Id
Applied
Payment
Schedule Id
Cash
Receipt Id
Gl_date
Posting
Control Id
UNAPP
1.98
100
Null
10178
01-JAN-98
9878
UNAPP
-1.98
100
Null
10178
01-JAN-98
9878
APP
1.01
100
306
10178
01-JAN-98
9878
APP
.87
100
309
10178
01-JAN-98
9878
APP
.10
100
399
10178
01-JAN-98
9878
Page 12
Note that the receipt has been applied to 3 invoices with the invoice payment_schedule_ids of 306,309,399.
The receipt is fully applied, and it has been posted.
In the next month, we will take the applications off of the original invoice, and apply it to two others. Notice
that these applications have not been posted yet.
These are the additional entries.
Application
Type
Amount
Applied
Payment
Schedule Id
Applied
Payment
Schedule Id
Cash
Receipt Id
Gl_date
Posting
Control Id
APP
-1.01
100
306
10178
05-FEB-98
-3
APP
.60
100
148
10178
05-FEB -98
-3
APP
.41
100
101
10178
05-FEB -98
-3
Assume todays date is 05-FEB-98. In the example, we took the payment off the invoice with
payment_schedule_id 306, and applied it to two other invoices with payment_schedule_ids of 148 and 101.
These have todays gl_date and they are not yet posted. There is no effect on the AR_CASH_RECEIPT, or
AR_CASH_RECEIPT_HISTORY tables.
Balancing Transactions
From time to time, you may see Receipts on your
Unposted Report. First make sure that you have
recently run an Accounts Receivable to General
Ledger transfer. It is possible that these receipts
were entered after the last posting run, and if you
are just running the Unposted Report, alone by
itself, it just indicates that these rows need to be
posted.
When the Debits and Credits on the report do not
balance, it is an indication that something is wrong
with the transactions. Here are a few hints on
what to look for.
The amount of a receipt is stored on
AR_CASH_RECEIPTS.
This same amount is
stored
in
the
amount
field
on
AR_CASH_RECEIPT_HISTORY in the initial
row. The acctd_amount field stores the receipt
amount in the functional currency. If your home
currency is USD and your receipt is in Canadian
Dollars, the Amount field will be in Canadian
dollars, and the acctd_amount field will be in US
dollars.
The total amount of the unapplied rows on
AR_RECEIVABLE_APPLICATIONS
should
equal
the
amount
on
the
AR_CASH_RECEIPT_HISTORY table for the
row on the history table that the application record
is
associated
with.
The
acctd_amount_applied_from total of the Unapplied
rows on AR_RECEIVABLE_APPLICATIONS
should = the total of the acctd_amount field on the
history table for the history row that the
applications are associated with. The association is
done thru the cash_receipt_history_id on both
tables.
When you have multiple steps in the cash
application approval process, such as cash clearing,
there will be more than one row on
AR_CASH_RECEIPT_HISTORY.
This will
usually be done for bank charges. When bank
charges are included in the clearing of cash, the
amount of the charges is stored in the
factor_discount_amount,
and
acctd_factor_discount_amount fields. The total of
the factor_discount_amount field plus the amount
fields on the row on the history table, will equal the
total of the amount row on the previous row for
that cash receipt on the history table.
For example,
on AR_CASH_RECEIPT_HISTORY
Page 14
Summary
You have seen the rows that are created on the ARCASH_RECEIPT_HISTORY table and how your
approval processes, such as remittance approval,
and cash clearing can contribute to additional rows
being created for each approval step.
I have given you examples of the transactions that
are created on tables when receipts are first created
as Unidentified, Unapplied, and either placed On
Account or Applied against invoices.
As you can see the largest number of transactions
are created on the
AR_RECEIVABLE_APPLICATIONS table.
Since the minimum number of transactions that are
generated for a receipt, are at least two, you want to
keep this in mind when sizing the table.
You see that reversals virtually double the number
of rows in a transaction. If you expect to
experience a large quantity of returned checks, and
your applications involve one receipt to many
invoices, you want to allow extra space on your
table to handle these reversals.
If you have a procedure where you always load
your receipts in as unidentified, and then in an
additional step, choose the customers, you want to
allow for at least 2 extra rows per receipt.
When you enter a receipt, you receive the original
Unapplied row, and then a row for each invoice
you Apply. If you use the reapply form to take the
receipt off UNAPP and then APP to each invoice,
you will be creating two rows on the table with
each application to each invoice. You would save
space by applying to all invoices once at receipt
time.
The more approval steps that you include in your
Cash process, such as remittance, and cash
clearing, the more rows that will be created on your
History tables. If there isnt a need for this level of
control, due to condensed approval processes,
which could be the result of downsizing, you may
no longer need these extra steps, and they can
greatly reduce your number of transactions.
So, knowing where the rows are created and at
what time, will enable you to size your tables
correctly. Knowing what is stored where will help
you trouble shoot when you have problems.
Page 15