Technical Perspective On Accounts Receivable Receipts

Technical Perspective on Accounts Receivable Receipts Storage
Cathy Lavender
Technical Specialist Oracle
ORACLE
Objective
Source of Receipts
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.
There are 3 ways of bringing receipts into your

system.
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.
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 hasnt 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.
Types of Receipts
Applied This is a receipt that has been
applied to a particular transaction. Status
is APP.
There are two types of Receipts.

Miscellaneous
invoice related receipts
Receipts
For
non
Regular Receipts For invoice related

receipts
Paper ##/ Page 1
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
NOTE: for an invoice with rules, a transaction is

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.
Page 2
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
One record per Invoice/DM/CM

contains both TRX_NUMBER
and CUSTOMER_TRX_ID
RA_CUSTOMER_TRX
Header information for

Invoice/DM/CM
One record per Invoice/DM/CM

contains both TRX_NUMBER
and CUSTOMER_TRX_ID.
RA_CUSTOMER_TRX_LINES
One record for each line on

Invoice DM/CM
Records are tied to

RA_CUSTOMER_TRX by the
customer_trx_id
RA_CUST_TRX_LINE_GL_DIST
One record for each distribution

for each line on each Invoice
/DM/CM
This table is tied to

RA_CUSTOMER_TRX_LINES
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

Invoice/DM/CM
This table is tied to

RA_CUSTMER_TRX_LINES
by customer_trx_id and
customer_trx_line_id
Page 3
Cash Receipt Storage
ON AR_RECEIVABLE_APPLICATIONS
When a receipt is entered, thru the Enter Receipts

Form (ARXPOWER) , several tables are updated.
The initial receipt is created on
AR_CASH_RECEIPTS,
AR_CASH_RECEIPT_HISTORY,
AR_PAYMENT_SCHEDULES,
AR_DISTRIBUTIONS and
AR_RECEIVABLE_APPLICATIONS. Each
receipt and identification step results in rows being
created on AR_RECEIVABLE_APPLICATIONS
table to provide the required accounting entries.
An example of the transactions created:
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:
(It is not necessary to always create a receipt as

Unidentified, If you know the customer, you would
create it as Unapplied)
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.
Paper ##/ Page 4
For the invoice on AR_PAYMENT_SCHEDULES

before application of cash:
Application of Receipts to Invoices
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
-100
After application of cash:
Amount_applied
Amount_due_original
250
On AR_PAYMENT_SCHEDULES for the original

entry of Cash:
After application to an invoice

Amount_due_original
-100
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)
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
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
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
Page 6
AR_PAYMENT_SCHEDULES
Payment_schedule_id
Identifies the payment schedule row
Amount_due_original
Original amount of the transaction
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
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
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
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
Take the application off of Unidentified and place on Unapplied

Todays date
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
Take the application off Unapplied and place On Account

Todays date
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)
If customer is unknown, place on Unidentified

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
Take off Unidentified to place on Unapplied

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
Take off Unapplied to place On Account

UNAPP
-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
Take off On Account to place against an invoice

ACC
-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.
Paper ##/ Page 13
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.
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.
For example,
on AR_CASH_RECEIPT_HISTORY
Page 14
Summary
ABOUT THE AUTHOR
You have seen the different application types that

are involved with receipts, and which tables are
updated and added to when receipts are applied,
unapplied, and reversed.
Cathy Lavender is a Technical Specialist with

Oracle Worldwide Customer Support in the
Accounts Receivable and Account Payable
Financial Products arena.
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

Technical Perspective On Accounts Receivable Receipts

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Technical Perspective On Accounts Receivable Receipts

Uploaded by

Copyright:

Available Formats

Technical Perspective on Accounts Receivable Receipts Storage

I will explain receipt application types, which

There are 3 ways of bringing receipts into your

You will understand the purpose of the Cash

Regular Receipt Entry

Receipt Application Types

There are two types of Receipts.

Regular Receipts For invoice related

Paper ##/ Page 1