The Oracle Applications Architecture is a framework for multi-tiered, distributed computing that supports Oracle Applications products. In this model, various servers or services are distributed among three levels, or tiers.
A tier is a logical grouping of services, potentially spread across more than one physical machine. The three-tier architecture that comprises an Oracle E-Business Suite installation is made up of the database tier, which supports and manages the Oracle database; the application tier, which supports and manages the various Applications components, and is sometimes known as the middle tier; and the desktop tier, which provides the user interface via an add-on component to a standard web browser.

Centralizing the Oracle Applications software on the application tier eliminates the need to install and maintain application software on each desktop client PC, and also enables Oracle Applications to scale well with an increasing load. Extending this concept further, one of the key benefits of using the Shared Application Tier File System model (originally Shared APPL_TOP) is the need to maintain only a single copy of the relevant Applications code, instead of a copy for every application tier machine.
The Desktop Tier
The client interface is provided through HTML for HTML-based applications, and via a Java applet in a Web browser for the traditional Forms-based applications.

In Oracle Applications Release 12, each user logs in to Oracle Applications through the E-Business Suite Home Page on a desktop client web browser. The E-Business Suite Home Page provides a single point of access to HTML-based applications, Forms-based applications, and Business Intelligence applications.
Once logged in via the E-Business Suite Home Page, you need not sign on again to access other parts of the system. Oracle Applications does not prompt again for user name and password, even when you navigate to other tools and products. Oracle Applications also retains preferences as you navigate through the system. For example, if you registered in the E-Business Suite Home Page that German is your preferred language, this preference carries over whether you access Forms-based or HTML-based applications.
The Forms client applet is a general-purpose presentation applet that supports all Oracle Applications Forms-based products, including those with customizations and extensions. The Forms client applet is packaged as a collection of Java Archive (JAR)
files. The JAR files contain all Java classes required to run the presentation layer of Oracle Applications forms.
The Application Tier
The application tier has a dual role: hosting the various servers and service groups that process the business logic, and managing communication between the desktop tier and the database tier. This tier is sometimes referred to as the middle tier.
Four servers or service groups comprise the basic application tier for Oracle Applications:

  • Web services
  • Forms services
  • Concurrent Processing server
  • Admin server

Note: In Release 12, the Web and Forms services are provided by  Oracle Application Server (OracleAS) 10g. They are no longer servers in the sense of being a single process, as was the case in previous Applications releases.  It is advisable to avoid using a mixture of different platforms on your application tier. This makes maintenance easier, since only one set of patches needs to be downloaded.

The Database Tier

The database tier contains the Oracle database server, which stores all the data maintained by Oracle Applications. The database also stores the Oracle Applications online help information.
More specifically, the database tier contains the Oracle data server files and Oracle Applications database executables that physically store the tables, indexes, and other database objects for your system. The database server does not communicate directly with the desktop clients, but rather with the servers on the application tier, which mediate the communications between the database server and the clients.

Maintaining Invoice and Credit Memo Transactions
In oracle Receivables transaction can be reviewed an updated after creation regardless of whether the transaction was created manually or imported using ‘Auto Invoice’.There are exceptions to this and some system options and profile options have to be set.

If the Allow change to printed transactions system option is ‘Yes’ you can update most of the transaction information, even if the transaction has been printed. However if there is activity against the transaction, you will not be able to make changes to many of the transaction attributes. Activity includes actions such as payments, credit memos, adjustments and including transactions on a consolidated billing invoice.

After your transactions have posted to your General Ledger, you can still update most of information. Receivables maintains a complete audit trail of all the posted changes you make to your accounting entries.

Receivable does not maintain an audit trail when you change a transaction that has not been posted.

Also what can be changed depends on various attribute settings on the transaction.
In addition to updating transactions, you may find the need to delete or void a transaction. Again, there are circumstances under which deleting or voiding a transaction can be accomplished.

Transaction Field Reference
When reviewing the tables, you will notice the tables indicate the field reference in down the left side of the table with the conditions going across the rows. Within the rows is the indication as to whether this field reference can be updated or not any exceptions that must be considered. By using these tables you will resolve many of your own issues as to why a user cannot update particular field on an invoice or credit memo.

When reviewing the update table you will note there are two sections, header and line levels.

Once you save the transaction, you cannot update the transaction number.

Additionally here are some profile options and system options that effect maintaining transactions.

System options can be set as follows

Setup/System/System Options/Trans and Customers Tab

Set allow change to printed transactions to Yes

Profile Options can be set as follows

Using the system administrator responsibility

Profile/System
Site level
Query in the field for the profile of choice. Some profile options that affect maintaining transactions are

AR: Update Due
AR: Change Customer on Transaction
Allow update existing sales credits
Sequential Numbering – Make the options is not null at all levels, has to contain a value at least one level.

Delete or Void Transactions
Deleting or voiding transactions can be accomplished depending on how your administrator has setup function security on you Oracle Receivables.
If the allow change to Printed Transactions system options is set to Yes and transactions have no activity against them, then the transaction have no activity against them, then the transactions can be removed by one of the following methods:
By delete record from the edit menu. This will delete invoice and any lines.
Invoice with rules cannot be deleted but you can create a credit memo and apply it to the invoice. The credit memo will create a credit entry offsetting the invoice debit entry.
Void the invoice by changing the invoice type in the Transaction window to a type with the Open Receivables and Post to GL options set to No. This will delete the payment schedule and cancel the distributions by removing the GL Date.
Delete the payment schedule by choosing incomplete button in Transaction window. This makes the invoice inaccessible for payment or crediting.

Maintaining Transactions Navigation
Navigate to the Transactions or the Transactions summary window:

Transactions/Transactions
Query the Transaction.
Change the transaction type to ‘void’ transaction type
Save

Transaction Table Information
Invoice : When an invoice is created the Header information is written to the RA_CUSTOMER_TRX_ALL table. Changes to any of the header information such as the customer invoice line information is written to RA_CUSTOMER_TRX_LINES_ALL, RA_CUST_TRX_LINE_GL_DIST_ALL, AR_PAYMENT SCHEDULES_ALL and RA_CUST_TRX_LINE_SALEREPS_ALL.

RA_CUST_TRX_LINES_ALL holds line details, what and how much is being invoices a nd what tax is applicable.
RA_CUST_TRX_LINES_GL_DIST_ALL stores information that need to be posted across General Ledger.
AR_PAYMENT_SCHEDULES_ALL keeps running totals of the Invoice amounts for line,tax and freight. Record both the original amounts and the amounts remaining.
RA_CUST_TRX_LINE_SALEREPS_ALL stores who get credited for the sale represented by the invoice.

Credit MemoCredit memos are stored in the same tables as the invoices. RA_CUSTOMER_TRX_ALL hold the credit memo header information similar to that of the invoice credit memo line information is t stored in RA_CUST_TRX_LINES_ALL, RA_CUST_TRX_LINE_GL_DIST_ALL, AR_PAYMENT SCHEDULES_ALL, AR_RECEIVABLE_APPLICATIONS_ALL
RA_CUSTOMER_TRX_LINES ALL holds credit memo line detail information.

AR_Receivable_Applicaitons_all- stores how much of the credit memo is applied

Revaluing Foreign Currency Balances
Asset and Liability accounts that are entered in foreign currencies must be revalued every period in accordance with FAS52 (Financial Accounting Standards). The Revaluation program adjusts the value of the balance sheet accounts based on current period exchange rates. It then generates revaluation journals with adjustments to the defined unrealized gain/loss account. The Revaluation program generates adjustments in the Functional Currency. If you have a Reporting Set of Books you must run revaluation once for each Primary and Reporting Set of Books. The Revaluation generates a revaluation batch containing a separate journal for each foreign currency. The revaluation batch automatically has its reversal period set to the next accounting period. When you run revaluation for the next accounting period, you must reverse and post the last accounting periods revaluation batch first.

You get to the Revalue balances form by following navigation path

Currency->Revaluation

Translating Foreign Currency BalancesThe Translation process translates actual and budget account balances to another currency in accordance FAS52. The translation program uses three different exchange rates: period-average, period end, and historical. The translation program translates asset and liability accounts using the period end exchange rate, ownership/stockholder equity accounts using the historical exchange rate, and revenue and expenses accounts using period average exchange rate. The period average exchange rate is the average rate of all daily rates across the entire accounting period.

The profile option GL: Owners equity transaction rule effects how ownership stockholders equity account balances are translated. If the profile option is set to PTD, the net activity accounts of the accounting period are translated, then added to the corresponding prior period balances. If the profile set to YTD the balances, not the activities are translated and the translated amounts are the YTD Balances. There is no need to add the balances to previous balances.

Navigation Currency-> Translation

Multiple Reporting Currencies
Multiple Reporting Currencies allows you to maintain accounting transactions in more than one functional currency. MRC is set up by creating one or more Reporting Set of Books.

MRC need if
Your company is located a member state of EMU and would like to report financial data, including transaction level data, in both your functional currency and the Euro.

You must regularly report financial data including transaction level data in more than one currency because your company is multinational.

MRC Works for following modules
Assets, CashManagment, Cost Management , General Ledger, Payables, Projects, Purchasing, Receivables.

MRC works differently depdning on whether you enter the transaction inn Oracle Subledger or Oracle GL. When you enter transaction in subledgers the accounting transactions are translated into the Reporting set of books as you enter the transaction. When you transfer to Oracle GL, you must transfer to both the primary set of books and the reporting set of books you should post the transferred subledgers accounting transactions to the primary set of books as well as to all reporting set of books.

When you enter transactions in GL, the journal entries entered in the Primary Set of Books are not translated immediately into any reporting Set of Books, when the Journal entries are posted
In the Primary Set of Books it will transferred to reporting Set of Books. In the reporting Set of Books you can post, revalue , translate and consolidate.

You can write off unapplied cash receipt balances. Receipt write off functionality is Provided to account for small overpayments that you do not intend to refund or maintain as unapplied amounts or On account balance.

With this function you can choose to write off an unapplied cash receipt amount within certain limits to a specific general ledger account. The write off amount is credited to this account such as miscellaneous revenue account, and no longer reflected as an unapplied amount on the receipt or on the customer account.

Receipt write offs do not change receipt amounts nor do they affect customer balances or general ledger cash account entries. Receipt write offs can be processed for cash receipts only.
You cannot write off amounts from miscellaneous receipts.

You can write off individual unapplied receipt amounts during receipt application or later, or any time using the application window. You can also write off balances of multiple receipts in mass
using the create receipt write off option.

Receipt Write-off Setup
The following information must be set up before you can process any receipt write-offs:

Receipts write off receivable activity

Define one or more receivable activities with an activity type of Receipt Write off. Each time an unapplied receipt amount is written off, a receipt write off type receivable activity must be selected. For Receipt write off receivable activities the GL Account source must be specified as Activity GL Account. Select a valid general ledger account number as the Activity GL Account. Select valid general ledger account number as the Activity GL Account. This account will be credited for the receipt write off amount. This account may represent a miscellaneous revenue account or expense account.

Navigation Setup – Receipts – Receivable Activities.

b) Receipt Write off user approval limits
Define approval limit ranges for document type Receipt write off for all users who will be allowed to write off unapplied receipt amounts. When you write off an unapplied receipt amount, Receivable uses approval limits that have a document type of Receipt Write off. You cannot write off an unapplied receipt amount that is outside your approval limit or outside the system Maximum Write off amount. You can only write off positive amounts; therefore Receipt write off from amount limits cannot be less than zero.

Navigations

Setup/Transaction/Approval Limits

Define the system level maximum write off amount for a single receipt in your functional currency. No users can write off unapplied receipt amounts that are greater than the system maximum even if their user limits allow it.

****** Therefore the system maximum overrides user approval limits when necessary user allows it. There fore the system maximum overrides user approval limits when necessary.

Navigation: Setup>System>System Options (T) Miscellaneous

c) How to Manually Write off Receipt Amounts

The manual receipt write off process gives you the flexibility to write off unapplied amounts when you enter and apply a receipt or later any time. You can enter multiple receipt write off lines in the Application window for a single receipt provided that the total write off amounts for the receipt does not exceed your receipt write off user approval limits or the system maximum write off user approval limit or the system maximum write off amount.

NOTE: When you write off an unapplied amount on a foreign currency receipt, Receivables uses the same exchange rate information from the original receipt for the write-off application record. If you adjust the exchange rate of a foreign currency receipt, Receivables reverses the write-off with the original exchange rate and then applies the new exchange rate to a new write-off application record. Receivables completes this process only if the converted amount does not exceed the user approval limit for receipt write-offs or the system Maximum Write-off Amount. If the converted amount exceeds either of these limits, then the write-off amount is left as an unapplied amount.

To manually write-off a receipt amount:

Navigation Receipts- Receipts or Receipt- Batches

Enter a new cash receipt or query an existing cash receipt.

Choose application button. (You cannot process receipt write offs using the Mass apply button)

Verify that the unapplied amount for the receipt is greater than zero.

In the Apply To field, select Receipt Write-off.

In the Amount Applied field (you may have to scroll to the right to see this field), enter the unapplied amount to
be written off. (Receivables validates the value you enter is less than or equal to the unapplied amount for the
receipt, is within your user write-off approval limit, and does not exceed the system Maximum Write-off Amount.)

In the Activity field, select a Receipt Write-off type receivables activity.

Save your work. The unapplied amount on the receipt should now be reduced by the write-off amount.

How to Write off Receipt Amounts in Mass

The automatic receipt write-off process gives you the ability to write-off multiple small unapplied receipt amounts with minimal manual intervention to individual receipt records. Unapplied amounts can be written-off based on amount or by percentage. When you submit the Automatic Receipt Write-off request, a concurrent program creates the write-off records.

Note: Always use the Generate Report Only option to preview the receipt amounts you want to write off before submitting the update. You can only reverse write-off receipt amounts by manually unapplying each receipt writeoff from the Applications window.

To create an automatic write-off:

Navigation
Create Receipt write off window
Control- >create receipt write off

In the Selection region, enter the currency of the receipts to write off. Receivables considers receipt amounts for write off only if they are in the same currency as entered here. The default value is your functional currency if the user write-off approval limit has been defined for the functional currency. You can change the default value to another currency.
Enter either an unapplied amount or unapplied amount percentage, or both. Although you can enter any amounts in these fields, Receivables will not select unapplied receipt amounts for write-off if they exceed the user write-off approval limits or system Maximum Write-off Amount.
– If you enter an unapplied amount, Receivables selects unapplied receipt amounts that are less than or equal to this value and that meet the other selection criteria.
– If you enter an unapplied percentage, Receivables determines the percentages of each unapplied receipt amount by dividing the unapplied amount by the original receipt amount and then selects unapplied receipt amounts that are a percentage smaller than or equal to the percentage entered and that meet the other selection criteria.
– If you enter both an unapplied amount and unapplied percentage, then each unapplied receipt amount must meet both the amount and percentage criteria. For example in figure 1, if the unapplied amount is set at $10.00 and the unapplied percentage is set at 20%, then following would apply:

Figure 1
Selected Not Selected
$10 receipt / $1.00 unapplied (10%) $10 receipt / $5.00 unapplied (50%)
$10 receipt / $2.00 unapplied (20%) $200 receipt / $15.00 unapplied (7.5%)
$200 receipt / $5.00 unapplied (2.5%)
$200 receipt / $10.00 unapplied (5%)

Specify a receipt date range, if desired.
WARNING: When date criteria is used, the logic of this program is to select only those receipts that have receipt dates within both the receipt date range and receipt general ledger date range specified.

Specify a receipt general ledger date range, if desired.
WARNING: Please exercise caution when setting receipt general ledger date ranges. When date criteria is used, the logic of this program is to select only those receipts that have receipt dates within both the receipt date range and receipt general ledger date range specified.

Specify a payment method, if desired.

Specify an individual customer name, if desired.

Specify an individual customer number, if desired.

Specify an individual receipt number, if desired.
In the Parameters Region, select a Receipt Write-off receivable activity. This field is optional when submitting the report and required when creating the write-offs.
Enter the apply date. This date is used as the apply date of the write-off application records.
Enter the GL Date. This date is used as the GL date of the write-off application records.

Enter comments, if desired. These comments are assigned to each write-off application record and can be viewed from the Applications window.

In the Options region, select one of the following options:

Generate Report Only: produces the Write-off Unapplied Receipt Balances: Pre Write-off Report, which lists the unapplied receipt amounts selected based on your criteria. Use this option to preview the write-off
results before running the option to create write-off amounts in mass.
– Create Write-off: submits the Automatic Receipt Write-off program (ARWRTCON ) that creates the write-off
application records and generates the Write-off Unapplied Receipt Balances: Write-off Report that lists the unapplied receipt amounts selected based on your criteria.
WARNING: Oracle highly recommends that you always use the Generate Report Only option first before submitting the update. There is no supported means for reversing receipt write-offs in mass. You can only reverse write-off receipt amounts by manually unapplying each receipt write-off  from the Applications window.
Choose the Submit button.

Reversing Receipt Write-offs
Like other payment applications, receipt write-off amounts can be reversed at any time and the write-off amount will
be added to the Unapplied total for the receipt. To reverse a receipt write-off, unapply the original write-off application by unchecking the Apply check box on the Applications window for the write-off amount.

To reverse a receipt write-off:
Navigate to the Receipts window (Receipts>Receipts or Receipts>Batches).

Query the existing cash receipt.

Choose the Applications button.

Uncheck the Apply box next to the receipt write-off application line you want to reverse.

Confirm that the write-off amount is added to the Unapplied total for the receipt.
Apply the unapplied amount, if desired.
Save your work.

Viewing Receipt Write-offs
Receipt write-off amounts are displayed with other receipt application lines. You can review the applications for a
receipt by querying the receipt from the Receipts or Receipts Summary options and then selecting the Applications
button. You can also drill down to receipt application information from the Account Details option by querying the receipt number as the Transaction number, then selecting the Activities button.
NOTE: At this time, receipt write-off amounts cannot be viewed from the Receipts form, Application Summary tabbed region. Receipt write-off application lines are omitted from this screen.
The accounting for receipt write-off amounts is included with the accounting for the receipt.

To review receipt write-off information:

Navigation

Receipts – Receipts or Receipts – Receipts Summary.

Query the receipt to view.

If you are in the Receipts window, choose the Applications button. If you are in the Receipts Summary window,choose Open, then choose the Applications button.

View the receipt write-off line(s) and amounts.

If you want to view accounting information for receipt write-offs, close the Applications window to return to the Receipts window.

Choose View Accounting from the Tools Menu. View the detail accounting lines for the receipt in the form of a balanced accounting entry. The receipt write-off amounts display as credits with a line type of ‘Other Receipt Application’ for the account that was defined for the Receipt Write-off receivable activity selected. You should also see that the write-off amount was initially included in the Unapplied line type amounts.

If you want to view the detail accounting as t-accounts, select the T Accounts button.

Accounting for Receipt Write-offs
As a cash receipt is entered, general ledger entries are created for each step in the process. Therefore, to explain the entries for a receipt write-off, you need to first understand the entries for receipts in general.
If a receipt is initially saved as unidentified (a customer is not selected), then the following entries are made:
DR Cash
CR Unidentified
However, most cash receipts are not saved before the customer is identified; therefore the following entries are
typically the initial accounting entries created for a receipt:
DR Cash
CR Unapplied
As you apply the receipt, entries are made to move the money from Unapplied to Applied (Receivable).
For example, if a $100 receipt is entered and applied in full, the following entries are made:
DR Cash 100
CR Unapplied 100
DR Unapplied 100
CR Receivable 100
When a receipt write-off is processed, the money is moved from Unapplied and put to the account defined for the
Receipt Write-off receivable activity selected.
For example, if a $100 receipt is entered and $95 is applied and $5 is written off, then the following entries are made:
DR Cash 100
CR Unapplied 100
DR Unapplied 95
CR Receivable 95
DR Unapplied 5
CR Write-off 5
If you later decide to reverse the write-off, then the following additional entries are made:
DR Write-off 5
CR Unapplied 5

Receipt Write-off Table Information
Receipt write-off amounts are stored in Oracle Receivables like other receipt application rows. Following is a description of each table that is updated when a cash receipt is entered. Only the

AR_PAYMENT_SCHEDULES_ALL
AR_RECEIVABLE_APPLICATIONS_ALL
AR_DISTIRBUTIONS_ALL

AR_CASH_RECEIPTS_ALL: One record is created per cash receipt. Receipt write-off amounts do not impact
the values in this table. However, Oracle Receivables assigns a status to each receipt based on how it is
applied. So it is important to understand how statuses are assigned and how receipt write-offs are
considered in assigning these statuses. Available statuses are: Applied (APP), Unidentified (UNID), Unapplied (UNAPP), and Reversed (REV). If the receipt is reversed (regardless of how it was applied), then the status REV is used. If any portion of the receipt is unapplied (regardless of how the rest of the receipt is applied), then the status UNAPP is used. If a customer has not yet been assigned to the receipt, then UNID is used. And if the receipt is applied in full, that includes applications to debit and credit items, as well as on
account and receipt write-off amounts, then the status APP is used. Other relevant columns for receipts include those described in Figure 2:

Figure 2

Cash_receipt_id Unique identifier of receipt (primary key)
Receipt_number Cash receipt number, not necessarily unique
Amount Amount of the payment
Currency_code Currency code assigned to the receipt
Receipt_date Date of receipt
Type CASH
Confirmed_flag Y or N
Pay_from_customer Identifier of the customer for this receipt

AR_CASH_RECEIPT_HISTORY_ALL: One record is created for each life cycle of a receipt. For example, a
typical receipt (applied or unapplied) will have one row with a status of CLEARED. If a receipt has been
reversed, then it will have two rows with statuses of: CLEARED and REVERSED. Automatic receipts can
have additional rows depending upon the confirmation levels required. So an automatic receipt could have
three rows with statuses of: APPROVED, CONFIRMED, and REMITTED. Other relevant columns for
receipts include these described in Figure 3:
Figure 3
Cash_receipt_history_id Unique identifier of the cash receipt history record
(primary key)
Cash_receipt_id Unique identifier of receipt, although multiple rows
can have the same cash_receipt_id
Amount Receipt amount in currency assigned to the receipt
Acctd_amount Receipt amount in your functional currency
First_posted_record_flag Y – when this is the first row that has been posted
Gl_date The general ledger date used to debit the CASH
account_code_combination_id
Account_code_combination_id Code representing the CASH account that will be
debited (and possibly credited) for the row
Current_record_flag Indicates which row is the current one for the cash
receipt (Y or N)
Reversal_gl_date The general ledger date used to credit the CASH
account_code_combination_id. It also signifies that
this row of the receipt has been reversed.
Posting_control_id Receivables posting batch identifier. –3 designates
10
unposted rows, a positive number designates posted
rows.
Reversal_posting_control_id Receivables posting batch identifier for the reversal
of the row. –3 designates an unposted reversal, a
positive number designates a posted reversal.
– AR_PAYMENT_SCHEDULES_ALL: One record is created per cash receipt to reflect the overall status of the
receipt. Oracle Receivables updates this table each time activity occurs for a receipt. All cash receipts are
identified with a class of PMT. When a receipt is applied or written-off, the amount is updated to the
amount_applied column and reduces the amount_due_remaining. When a receipt is completely applied
(includes write-offs), Oracle Receivables changes the status from open (OP) to closed (CL). Unapplied, on
account, and unidentified amounts are included in the amount_due_remaining and the receipt will not close
until these amounts are applied. All receipt amounts are stored as negative numbers in this table. Additional
AR_PAYMENT_SCHEDULES_ALL records can be created for receipts when debit memo reversals or
chargebacks are created. Other relevant columns for receipts include these described in Figure 4:
Figure 4
Payment_schedule_id Unique identifier for the payment schedule row
(primary key)
Amount_due_original Amount of the payment (negative)
Amount_due_remaining Sum of unapplied, on account, and unidentified
amounts in the receipt currency or the payment
amount minus applied and receipt write-off amounts
(negative)
Acctd_amount_due_remainin
g
Amount_due_remaining in your functional currency
(negative)
Status OP for open, CL for closed. A closed receipt is one
that is fully applied.
Class PMT
Customer_id Identifier of the customer for this receipt
Cash_receipt_id Unique identifier of receipt, although multiple rows
can have the same cash_receipt_id
Gl_date_closed The accounting date on which the schedule was
closed. The default value for open rows is ‘31-DEC-
4712’.
Amount_applied Sum of applied and receipt write-off amounts
(negative)
Trx_number Cash receipt number, not necessarily unique
Trx_date The transaction date of the row
– AR_RECEIVABLE_APPLICATIONS_ALL: One record is created for every type of transaction processed on a receipt. This table is essentially an audit trail of all accounting entries for your cash and credit memo receipt
applications. A row is written in this table for each time you select the Apply or Unapply button – regardless
of whether you manually save the changes – they are always stored here. Each row includes the amount
applied, status, accounting flexfield information, and a posting control id. Possible statuses include applied
(APP), unapplied (UNAPP), on account (ACC), unidentified (UNID), and receipt write-off (ACTIVITY). For
example, if you write-off a $1.00 unapplied amount, two rows will be created: UNAPP for -$1.00 and
ACTIVITY for $1.00.
There are two kinds of applications (CASH and CM – for credit memo applications) stored in this table and
designated by application_type. Credit memo lines applied with a receipt are stored in this table with the
other applications for the receipt. Other relevant columns for receipts include these described in

Receivable_application_id Unique identifier of the receivable application row
(primary key)
Amount_applied Total amount of the line in the receipt’s currency.
This includes line amounts, tax, freight, and finance
charges. Write-off amounts are included here as
well.
Acctd_amount_applied_from Amount_applied in your functional currency
Status APP, UNAPP, ACC, UNID, and ACTIVITY (receipt
write-offs)
Gl_date Date this application row will post to the general
ledger
Code_combination_id General ledger account number code combination id
Payment_schedule_id Identifies the cash receipt or credit memo being
applied
Cash_receipt_id Unique identifier of receipt, although multiple rows
can have the same cash_receipt_id
Applied_customer_trx_id Identifies the transaction being paid / reversed
Applied_customer_trx_line_id Identifies the line of the transaction being paid /
reversed
Customer_trx_id Identifier of the credit memo being applied
Gl_posted_date Date this row was posted to the general ledger
Postable Y or N to indicate whether the row is postable to the
general ledger
Posting_control_id Receivables posting batch identifier. –3 designates
unposted rows, a positive number designates posted
rows.
Confirmed_flag Null or Y for confirmed receipts
AR_DISTRIBUTIONS_ALL: A record is created in this table for the general ledger distributions information
generated by the different steps in the life cycle of a cash receipt. This includes distributions based on the
rows for the receipt in the AR_CASH_RECEIPT_HISTORY_ALL and
AR_RECEIVABLE_APPLICATIONS_ALL tables. Each row includes the amounts to be debited or credited in
both the receipt and functional currency, general ledger code combination id, source table, and source type.
The source_table indicates which table the row is created from: CRH for
AR_CASH_RECEIPT_HISTORY_ALL and RA for AR_RECEIVABLE_APPLICATIONS_ALL. The
source_type reflects the type of activity, such as CASH (for the initial debit to Cash for the receipt), REC for
applied amounts, UNAPP for unapplied amounts, ACC for on account amounts, and ACTIVITY for receipt
write-off amounts. Other relevant columns for receipts include these described in Figure 6:
Figure 6
Line_id Unique identifier for each row in this table
Source_id Identifier of the row source from the foreign table. Represents
the cash_receipt_history_id from
AR_CASH_RECEIPT_HISTORY_ALL or the
receivable_application_id from
AR_RECEIVABLE_APPLICATIONS_ALL (primary key).
12
Source_table Indicates the origin of the row in the table that was used to
create this distribution line: CRH for
AR_CASH_RECEIPT_HISTORY_ALL and RA for
AR_RECEIVABLE_APPLICATIONS_ALL (primary key)
Source_type Represents the type of general ledger account for which the
distribution is created. The source_type varies based on the
source_table. For Cleared and Reversed rows in
AR_CASH_RECEIPT_HISTORY_ALL, this value is CASH.
For rows in AR_RECEIVABLE_APPLICATIONS_ALL, the
value in this table is the same as the status in that table except
for APP rows. APP status rows get a value of REC in this
table. (ACTIVITY rows are created in both tables for receipt
write-offs.) (primary key)
Code_combination_id The general ledger account the distribution is created for
Amount_dr Debit amount of the journal entry in receipt currency
Amount_cr Credit amount of the journal entry in receipt currency
Acctd_amount_dr Debit amount of the journal entry in your functional currency
Acctd_amount_cr Credit amount of the journal entry in your functional currency

11i and R12

In 11i the field ‘bank_account_id’ acts as a relation key between the AP_CHECKS_ALL and AP_BANK_ACCOUNTS_ALL tables.

In 12 i the same field is no longer is used in ‘AP_CHECKS_ALL’ table.

In 12 i where ‘CE_BANK_ACCT_USE_ID’ is acts as a relation between ‘CE_BANK_ACCT_USES_ALL’ and ‘AP_CHECKS_ALL’

Highlights of release 12i

A single responsibility to access and transact on multiple organizations.
A single ledger to manage multiple currencies.
Ledger sets to manage accounting processes across ledger.
Centralized rules engines for tax, accounting and Intercomapny.
Centralized trading partners i.e Suppliers, Banks, First Party legal entities.
Simplified reporting via XML Publisher and DBI.
Netting across trading partners.