Technical Perspective on Accounts Receivable Receipts Storage
Cathy Lavender
Technical Specialist Oracle
ORACLE
Objective
I will explain receipt application types, which
tables are involved in the storage of receipts,
including record formats, how the tables are related
to one another, and what happens when you
reverse/reapply receipts.
You will understand the purpose of the Cash
Receipt History tables, and how your approval
process can increase the volume of records on
these.
I will explain the effect on invoices when receipts
are applied, and what contributes to higher record
count volumes on the Receivable Applications
tables.
You will see examples of applications of receipts
including Unidentified, Unapplied, and On
Account transactions.
Using this information will help you predict and
plan appropriate table sizing.
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
There are two types of Receipts.
Miscellaneous Receipts – For non
invoice related receipts
Regular Receipts – For invoice related
receipts
Source of Receipts
There are 3 ways of bringing receipts into your
system.
Regular Receipt Entry
Lockbox involves using a batch job to
input your receipts onto an interim table,
which becomes the input to the Quick
Cash Posting batch job.
Quick Cash provides a way to enter
receipts into an interim table that becomes
input to your Quick Cash Posting job.
This provides an extra step to the approval
process before the Receipts are entered
into the main AR_CASH_RECEIPTS
table
Quick Cash Posting reads an interim table
of Cash Receipts and processes the data
by creating receipt transactions on
AR_CASH_RECEIPTS.
Receipt Application Types
There are four application types:
Unidentified – This is a receipt that has
been entered, but not identified to a
particular customer. Status is UNID.
Unapplied – This is a receipt that has
been associated with a particular
customer, but hasn’t been associated with
any transactions. Status is UNAPP.
On Account – This is a receipt that is put
on account for the customer. Status is
ACC.
Applied – This is a receipt that has been
applied to a particular transaction. Status
is APP.
Paper ##/ Page 1
 Technical Perspective on Accounts Receivable Receipts Storage

Approval Controls NOTE: for an invoice with rules, a transaction is

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
also created to the Unearned/Unbilled account.
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

An invoice is identified by its

CUSTOMER_TRX_ID. This is a generated
number.

RA_CUSTOMER_TRX. stores invoice, debit

memo, commitment, and credit memo header
information. Each row includes general invoice
information such as customer number, transaction
type, and printing instructions.

Invoice line information is stored on

RA_CUSTOMER_TRX_LINES and is joined to
RA_CUSTOMER_TRX by the customer_trx_id.

Distributions are stored on

RA_CUST_TRX_LINE_GL_DIST. This table
stores the accounting records for revenue, unearned
revenue and unbilled receivable for each invoice or
credit memo line. Each row includes the GL
account and the amount of the accounting entry.
The General Ledger account is identified by a
code_combination_id.

The code_combination_id can be expanded to its

segments’ components by joining it to the
GL_CODE_COMBINATIONS table.

Values in each of the segments on this table are

stored in fields segment1, segment2, segment3
using as many segments as you have defined for
your key accounting flexfield for your set of books

For reasons of simplicity this paper will refer to the

code_combination_id instead of the expanded
segments

The AR_PAYMENT_SCHEDULES table stores

summary information on all transactions. When an
invoice/debit memo/credit memo is created the
following accounts are affected:

Debit to Receivables for the amount of the

invoice/debit memo/credit memo.

Credit to Revenue for the amount of the

invoice/debit memo/credit memo.

Technical Perspective on Accounts Receivable Receipts Storage Page 2

 Technical Perspective on Accounts Receivable Receipts Storage

Invoices and Debit Memos

When an invoice is created and completed, these are the tables involved:

TABLE REASON FOR USE RELATIONSHIPS

AR_PAYMENT_SCHEDULES Summary of Invoice/Debit Memo
DM/Credit Memo CM
RA_CUSTOMER_TRX Header information for
Invoice/DM/CM
One record per Invoice/DM/CM
contains both TRX_NUMBER
and CUSTOMER_TRX_ID
One record per Invoice/DM/CM
contains both TRX_NUMBER
and CUSTOMER_TRX_ID.

RA_CUSTOMER_TRX_LINES One record for each line on Records are tied to

Invoice DM/CM RA_CUSTOMER_TRX by the
customer_trx_id
RA_CUST_TRX_LINE_GL_DIST One record for each distribution This table is tied to
for each line on each Invoice RA_CUSTOMER_TRX_LINES
/DM/CM by customer_trx_id and
customer_trx_line_id
On a typical transaction you will
receive a record for account_class
= REC and a record for each line
of line_type line with an
account_class of REV, and for
tax lines an account_class of
TAX and for freight lines an
account_class of FRT.
Total of REV + TAX + FRT =
REC
RA_CUST_TRX_LINE_SALESREPS Header information for This table is tied to
Invoice/DM/CM RA_CUSTMER_TRX_LINES
by customer_trx_id and
customer_trx_line_id

Technical Perspective on Accounts Receivable Receipts Storage Page 3

Cash Receipt Storage ON AR_RECEIVABLE_APPLICATIONS

When a receipt is entered, thru the Enter Receipts UNID +100

Form (ARXPOWER) , several tables are updated.
The initial receipt is created on UNID -100
AR_CASH_RECEIPTS,
AR_CASH_RECEIPT_HISTORY, UNAPP +100
AR_PAYMENT_SCHEDULES,
AR_DISTRIBUTIONS and UNAPP -100
AR_RECEIVABLE_APPLICATIONS. Each
receipt and identification step results in rows being ACC +100
created on AR_RECEIVABLE_APPLICATIONS
table to provide the required accounting entries. ACC -100
An example of the transactions created:
APP +100
Initial receipt
(Note that all the above entries are stored with the
DR Cash 100 opposite signs.)

CR UNID 100 When they are passed to General Ledger:

(It is not necessary to always create a receipt as DR CASH 100

Unidentified, If you know the customer, you would
create it as Unapplied) CR UNID 100

Choose Customer DR UNID 100

DR UNID 100 CR UNAPP 100

CR UNAPP 100 DR UNAPP 100

Putting on Account CR APP 100 (This is for the

receivable account of the invoice)
DR UNAPP 100
Reversals
CR ACC 100
When reversing a receipt the rows are in effect
Take off account and place on an invoice duplicated with the opposite sign, on the
AR_RECEIVABLE_APPLICATIONS table. On
DR ACC 100 AR_PAYMENT_SCHEDULES and
AR_CASH_RECEIPTS the original transaction is
CR APP 100 updated to reflect the applications.

AR_CASH_RECEIPTS would contain one row for On AR_CASH_RECEIPTS status is changed to

100 REV, and there are several updates to
AR_PAYMENT_SCHEDULES.
AR_CASH_RECEIPT_HISTORY would contain
one row for 100 On AR_PAYMENT_SCHEDULES following a
reversal, the Cash Receipt row is closed with no
AR_DISTRIBUTIONS would contain one row for amount due remaining, and the Invoices that
100 application was made to, will have its
applied_amount backed out, and remaining balance
reset.

Paper ##/ Page 4

 Technical Perspective on Accounts Receivable Receipts Storage

For the invoice on AR_PAYMENT_SCHEDULES

before application of cash:
Application of Receipts to Invoices
Amount_due_original 250
On AR_PAYMENT_SCHEDULES for the original
entry of Cash: Amount_due_remaining 100

Amount_due_original -100 Amount_applied 0

(note that this is stored as a
negative on the cash row) Amount_credited -250

Amount_due_remaining -100 After application of cash:

Amount_applied 0 Amount_due_original 250

After application to an invoice Amount_due_remaining 0

Amount_due_original -100 Amount_applied 100

(note how it is stored as a positive number)
Amount_due_remaining 0
Amount_credited -250
Amount_applied -100 (note that this is stored as a negative number)

……………………………………………………………………………………………………………………

AR_CASH_RECEIPTS – One row per cash receipt is created:

Cash receipt_id Identifier of cash receipt

Amount Amount of the payment entry
Currency
Receipt_date
Status APP, UNID, ACC, UNAPP
Type MISC or CASH
Receipt_number Cash receipt number, usually check number
Confirmed_flag Y or N
Pay_from_customer Identifier of the customer

Technical Perspective on Accounts Receivable Receipts Storage Page 5

 Technical Perspective on Accounts Receivable Receipts Storage

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 Identifier of the cash receipt history
Cash_receipt_id Foreign key to AR-CASH_RECEIPTS
Status One of the following:
APPROVED, CONFIRMED, REMITTED, CLEARED, REVERSED
First_posted_record_flag Y – when this is the first row that has been posted
Gl_date The gldate that is used when debiting the
account_code_combination_id (CASH)
Current_record_flag Indicates which row is the current one for the cash receipt id (Y or N)
Reversal_gl_date This is the gl_date that is used to credit the
account_code_combination_id. It also signifies that this row has been
reversed
Posting_control_id Receivables posting batch identifier. –3 means that it is not posted, a
positive number means that it has been posted
Reversal_posting_control_id -3 means it has not been posted. This should be null if the
reversal_gl_date is null
Acctd_amount This is the amount in the functional currency
Amount Amount in transaction currency. It indicates the amount for this step
of the life cycle of the receipt. Most of the amounts will be similar to
the original amount of the cash receipt but the cleared amount might
be different from the remitted, due to any charges the bank took
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 One of the following: CASH, CONFIRMATION, REMITTANCE, FACTOR,

SHORT_TERM_DEBT, BANK_CHARGES and represents the account for which
the distribution is being posted.

Amount_dr Amount of the debit journal entry

Amount_cr Amount of the credit journal entry.

Acctd_amount_dr Functional currency

Acctd_amount_cr Functional_currency

Technical Perspective on Accounts Receivable Receipts Storage Page 6

 Technical Perspective on Accounts Receivable Receipts Storage

AR_PAYMENT_SCHEDULES
Payment_schedule_id Identifies the payment schedule row

Amount_due_original Original amount of the transaction

Amount_due_remaining Original amount of the transaction, minus the applications

Status OP for open, CL for closed. A closed receipt is one that is fully
applied. A closed invoice/debit memo is one whose
amount_due_remaining has become zero.

Class PMT for payment, INV for invoice, DM for debit memo, CM for
credit memo

Customer_id Identifies the customer associated with this item.

Cash_receipt_id Identifies the Payment

Gl_date_closed The accounting date on which the schedule was closed. Default value
for open ones are ‘31-DEC-4712’

Amount_applied Amount applied to an item. This is important on the invoice/debit

memo rows on this table. It reflects the application of a receipt. On
payment records it is stored as a negative. On records where the
receipt is applied, such as an invoice, the field is stored as a positive.

Trx_number The transaction number, such as the invoice or receipt number.

Trx_date The transaction date of the row.

Gl_date

Acctd_amount_due_remaining Amount due in the functional currency

Technical Perspective on Accounts Receivable Receipts Storage 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 don’t have rows of status UNAPP. Credit Memos only show a status of APP

Receivable_application_id Identifies the receivable application

Amount_applied Total amount of the application including line, tax, freight and
receivables’ charges.

Gl_date

Code_combination_id Gl code combination

Status Status will show UNAPP, APP, UNID, ACC

Payment_schedule_id Identifies the receipt or the credit memo being applied.

Cash_receipt_id Identifies the cash receipt being applied.

Applied_customer_trx_id Identifies the invoice being applied to.

Applied_customer_trx_line_id Identifies the line of the invoice the application applies to.

Customer_trx_id Identifies the debit item or credit memo being applied

Gl-posted_date Date the application was posted.

Postable Y or N flag to indicate whether the item is postable to the General

Ledger

Posting_control_id Receivables posting batch identifier. –3 indicates it has not been

posted. A positive number indicates it has.

Acctd_amount_applied_from Amount of the source converted to base (functional) currency.

Confirmed_flag This is null or Y when the cash receipt is confirmed.

Paper ##/ Page 8

 Technical Perspective on Accounts Receivable Receipts Storage

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 Amount Payment Applied Cash GL_date Posting
Type Applied Schedule Id Payment Receipt Id Control Id
Schedule Id
UNID 1.98 Payment Null Cash receipt receipt_date -3
schedule id id
of the
receipt

If we were to change the UNIDENTIFIED to UNAPPLIED, these would be the entries (in total):
Application Amount Payment Applied Cash GL_date Posting
Type Applied Schedule Id Payment Receipt Id Control Id
Schedule Id
UNID 1.98 Payment Null Cash receipt receipt_date -3
schedule id id
of the
receipt
UNID -1.98 Payment Null Cash receipt todays date -3
schedule id id
of the
receipt
UNAPP 1.98 Payment Null Cash receipt todays date -3
schedule id id
of the
receipt

Technical Perspective on Accounts Receivable Receipts Storage Page 9

 Technical Perspective on Accounts Receivable Receipts Storage

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 on–account

If we were to place the UNAPPLIED, On Account These would be the entries (in total)
GL_date Application Amount Payment Applied Cash Receipt Posting
Type Applied Schedule Id Payment Id Control Id
Schedule Id
Receipt_date UNID 1.98 Payment Null Cash receipt -3
schedule id id
of the receipt

Take the application off of Unidentified and place on Unapplied

Todays date UNID -1.98 Payment Null Cash receipt -3
schedule id id
of the receipt
Todays date UNAPP 1.98 Payment Null Cash receipt -3
schedule id id
of the receipt
Take the application off Unapplied and place On Account
Todays date UNAPP -1.98 Payment Null Cash receipt -3
schedule id id
of the receipt
Todays date ACC 1.98 Payment -1 Cash receipt -3
schedule_id id
of the receipt

Technical Perspective on Accounts Receivable Receipts Storage Page 10

 Technical Perspective on Accounts Receivable Receipts Storage

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)
If customer is unknown, place on Unidentified
Application Amount Payment Applied Cash Receipt GL_date Posting
Type Applied Schedule Id Payment Id control id
Schedule Id

.UNID 1.98 Payment Null Cash receipt receipt_date -3

schedule id id
of the receipt

Take off Unidentified to place on Unapplied

UNID -1.98 Payment Null Cash receipt todays date -3
schedule id id
of the receipt
UNAPP 1.98 Payment Null Cash receipt todays date -3
schedule id id
of the receipt

Take off Unapplied to place On Account

UNAPP -1.98 Payment Null Cash receipt todays date -3
schedule id id
of the receipt
ACC 1.98 Payment -1 Cash receipt todays date -3
schedule id id
of the receipt

Take off On Account to place against an invoice

ACC -1.98 Payment -1 Cash receipt todays date -3
schedule id id
of the receipt
APP 1.98 Payment Payment Cash receipt todays date -3
schedule id schedule id id
of the receipt of the
invoice

Here is an example of a receipt entered, with the customer chosen, specific application
chosen..
Application Amount Payment Applied Cash Gl_date Posting
Type Applied Schedule Id Payment Receipt Id Control Id
Schedule Id
UNAPP 1.98 Payment Null Cash receipt todays date -3
schedule id id
of the receipt
UNAPP -1.98 Payment Null Cash receipt todays date -3
schedule id id
of the receipt
APP 1.98 Payment Payment Cash receipt todays date -3
schedule id schedule id id
of the receipt of the invoice

Technical Perspective on Accounts Receivable Receipts Storage Page 11

 Technical Perspective on Accounts Receivable Receipts Storage

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 Amount Payment Applied Cash GlDate Posting
Type Applied Schedule Id Payment Receipt Id Control Id
Schedule Id
UNAPP 1.98 Payment Null Cash receipt todays date -3
schedule id id
of the
receipt
UNAPP -1.98 Payment Null Cash receipt todays date -3
schedule id id
of the
receipt
APP 1.98 Payment Payment Cash receipt todays date -3
schedule id schedule id id
of the of the
receipt invoice

Reversal Entries
Application Amount Payment Applied Cash GlDate Posting
Type Applied Schedule Id Payment Receipt Id Control Id
Schedule Id
UNAPP -1.98 Payment Null Cash receipt Todays date -3
schedule id id
of the
receipt
UNAPP +1.98 Payment Null Cash receipt Todays date -3
schedule id id
of the
receipt
APP -1.98 Payment Payment Cash receipt Todays date -3
schedule id schedule id id
of the of the
receipt invoice
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 Amount Payment Applied Cash Gl_date Posting
Type Applied Schedule Id Payment Receipt Id Control Id
Schedule 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

Technical Perspective on Accounts Receivable Receipts Storage Page 12

Note that the receipt has been applied to 3 invoices with the invoice payment_schedule_id’s 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 Amount Payment Applied Cash Gl_date Posting
Type Applied Schedule Id Payment Receipt Id Control Id
Schedule 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_id’s 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.

Paper ##/ Page 13

 Technical Perspective on Accounts Receivable Receipts Storage
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
Technical Perspective on Accounts Receivable Receipts Storage
Cash receipt id 12345, cash_receipt_history_id
9989, amount = 15.90, acctd_amount = 10.00,status
= remitted
Cash receipt id 12345, cash_receipt_history_id
9999, amount 15.00, factor_discount_amount .90,
acctd_amount 9.50,acctd_factor_discount_amount
= .50, status = cleared
Table AR_DISTRIBUTIONS contains the
distribution rows associated with each history row.
In the case of a normal (no bank charges) cash
receipt, there will be one row on this table,
containing the appropriate amount_dr, and,
acctd_amount_dr values.
In the case of the rows which map to the history
row with the bank charges, there will be a row for
the appropriate bank charge, with the amount_cr
and acctd_amount_cr populated with the bank
charge, a row for the cash as an amount_dr,
acctd_amount_dr , and a row for the remittance
with the amont_cr and acctd_amount_cr filled in.
The total of the bank charge row, and the
remittance row will equal the cash row. The
original history row, will only have a remittance
row associated with it, because the only purpose of
the additional cash and bank charges row are to
account for the bank charges.
When we post receipts to general ledger, we mark
the AR_CASH_RECEIPT_HISTORY, and
AR_RECEIVABLE_APPLICATIONS tables by
updating the posting_control_id and the
gl_posted_date. The Unposted Report will show
the Amount fields from these tables. If there is an
out of balance problem in the log from the run, and
it indicates a problem with the out of balance
DR_acctd and CR_acctd, this is referring to the
acctd_amount and acctd_factor_discount_amount
fields on the history table. This is usually a
currency conversion/rounding/, truncating a
decimal place problem.
Page 14
 Technical Perspective on Accounts Receivable Receipts Storage

Summary ABOUT THE AUTHOR

You have seen the different application types that Cathy Lavender is a Technical Specialist with
are involved with receipts, and which tables are Oracle Worldwide Customer Support in the
updated and added to when receipts are applied, Accounts Receivable and Account Payable
unapplied, and reversed. Financial Products arena.
You have seen the rows that are created on the AR-
CASH_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 isn’t 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.

Technical Perspective on Accounts Receivable Receipts Storage Page 15