Answer:: Question: What Are The Key Benefits of Forms Personalization Over Custom - PLL?

Question: What are the key benefits of forms personalization over custom.pll?
Answer: Multiple users can develop forms personalization at any given point in
time.
It is fairly easy to enable and disable forms personalization.
–>A programmer is not required to do simple things such as hide/disable fields
or buttons.
–>Provides more visibility on customizations to the screen.
Question: Tell me some limitations of forms personalization when compared to
CUSTOM.pll?
Answer:
–>Can’t create record group queries, hence can’t implement LOV Query
changes.
–>Can’t make things interactive, i.e. can’t have a message box that gives
multiple choices for example Proceed or Stop etc.
Question: How can you import invoices into Oracle Receivables?

Answer:
You can either use AutoInvoice by populating tables RA_INTERFACE_LINES_ALL,

RA_INTERFACE_DISTRIBUTIONS_ALL &
RA_INTERFACE_SALESCREDITS_ALL.Alternately you may decide to use API
ar_invoice_api_pub.create_single_invoice for Receivables Invoice Import.
Question: In OA Framework, once your application has been extended by substitutions, is

it possible to revert back to remove those substitutions?
Answer: yes, by setting profile option “Disable Self-Service Personal%” to Yes, keeping
in mind that all your personalizations will get disabled by this profile option. This profile
is also very useful when debugging your OA Framework based application in the event of
some error. By disabling the personalization via profile, you can isolate the error, i.e. is
being caused by your extension/substitution code or by Oracle’s standard functionality.
Question: For a PL/SQL based concurrent program do you have to issue a commit at the
end?
Answer: The concurrent program runs within its own new session. In APPS, the default
database setting enforces a commit at the end of each session. Hence no explicit
COMMIT is required.
Question: What is the difference between running Gather Stats and “Program –
Optimizer[RGOPTM]” in Oracle General Ledger?
Answer: “Gather Stats” will simply gather the stats against existing tables, indexes etc.
However Gather Stats does not create any new indexes. But “Program –
Optimizer[RGOPTM]” can create indexes on GL_CODE_COMBINATIONS, provided
accounting segment has the indexed flag enabled,
Question: How do you know if a specific Oracle patch has been applied in apps to your
environment?
Answer: Use table ad_bugs, in which column bug_number is the patch number.
SELECT bug_number ,to_char(creation_date, ‘DD-MON-YYYY HH24:MI:SS’) dated
FROM apps.ad_bugs
WHERE bug_number = TRIM(’&bug_number’) ;
Question: How to make concurrent program end with warning?
Answer: If the concurrent program is of type PL/SQL, you can assign a value of 1 to the
“retcode” OUT Parameter. For a Java Concurrent program, use the code similar to below
ReqCompletion lRC; //get handle on request completion object for reporting status IRC
= pCpContext.getReqCompletion(); lRC.setCompletion(ReqCompletion.WARNING,
“WARNING”);
Question: Which table is used to provide drill down from Oracle GL into sub-ledger?
Answer: GL_IMPORT_REFERENCES
Question: You have just created two concurrent programs namely “XX PO Prog1″ &
“XX PO Prog2″. Now you wish to create a menu for Concurrent Request submission
such that only these two Concurrent Programs are visible from that Run Request menu.
Please explain the steps to implement this?
Answer:
a) Define a request group, lets say with name “XX_PO_PROGS”
b) Add these two concurrent programs to the request group “XX_PO_PROGS”
c) Define a new Form Function that is attached to Form “Run Reports”
d) In the parameter field of Form Function screen, enter

REQUEST_GROUP_CODE=”XX_PO_PROGS”
REQUEST_GROUP_APPL_SHORT_NAME=”XXPO”
TITLE=”XXPO:XX_PO_PROGS” e) Attach this form function to the desired menu.
Question: Which responsibility do you need to extract Self Service
Personalizations?
Answer:Functional Administrator
Question: Can you list any one single limitation of Forms Personalization
feature that was delivered with 11.5.10
Answer:You can not implement interactive messages, i.e. a message will give
multiple options for Response. The best you can get from Forms
Personalization to do is popup up Message with OK option.
Question: This is a very tough one, almost impossible to answer, but yet I will ask. Which
Form in Oracle Applications has most number of Form Functions?
Answer: “Run Reports”. And why not, the Form Function for this screen has a parameter
to which we pass name of the “Request Group”, hence securing the list of Concurrent
Programs that are visible in “Run Request” Form. Just so that you know, there are over
600 form functions for “Run Reports”
Question: How will you migrate Oracle General Ledger Currencies and Sets of Books
Definitions from one environment to another without Keying? Will you use FNDLOAD?
Answer: FNDLOAD can not be used in the scenario. You can use migrator available in
“Oracle iSetup” Responsibility
Question: How can an end-user be given control to run a script developed by a developer,
given that an end user will never have access to apps password (and rightly so)?
Answer: This script can be attached to a Concurrent Program via a concurrent program
executable. The user will then be given access to this Concurrent Program.
Question: But how will the end user or Oracle Apps make this script run every 10hours
daily?
Answer: A concurrent program can be scheduled to run at desired intervals. The schedule
is defined at the time of submission.
Question: What are the basic steps when defining a concurrent program?
Answer: Broadly speaking there are three steps when developing a concurrent program in
Oracle Apps Step 1. Make Oracle Apps identify the executable Step 2. Provide a handle
to the executable by means of defining a concurrent program Step 3. Make this
concurrent program accesible to selected users via their responsibility.
11. What is Set of Books? What are the four conditions when you change
your SOBs?SOB is of 2 types – Primary and Reporting.Primary SOB - All
transactions are with functional Currency
12. What is an Invoice?

AR invoice is a document sent to the customer with details like, Bill-to
customer code, product code, qty sent, price, currency, credit terms, tax details,
etc. Based on this invoice, customer will make payment to the company and the
same is applied against the invoice. AP invoice is the document received from
the supplier and contains information such supplier details, product code, qty,
price and tax details. This invoice is entered in the AP module and payment is
made to the supplier against this invoice.
There are 2 types of invoices-
1. Periodic 2. Milestone
Also, Invoice is an information sheet which a company sends to the buyer

along with the good. It explains the details of the goods in the shipment and
also the prices. Invoices can contain all sorts of data regarding the shipment and
goods depending on the company and product.
13. Can you disable budgetary control for a set of books?
You can, however existing encumbrances are not cleared from the feeder
systems. Therefore it is not recommended. If you do change the budgetary
control options for an existing set of books, you must do two things for the
change to be reflected.
–Run the Period Map Maintenance concurrent request, it must complete

successfully.
–Exit Oracle Applications and restart. You must completely exit the
application…it is not sufficient to select Sign on again from the Oracle
Applications Special menu.
14. Is there a limit to the number of periods in a budget year or how many
years a budget can span?
There is no limit for the budget. One can define budgetary control for n number
of years however, one year can have maximum of 60 fiscal periods.
15. Why don’t my Detail budgets roll up to my Master budget?

Detail budgets do not automatically roll up to the master budget. The GL uses
summary accounts to maintain master/detail budget relationships between
them.
16. I was able to post a budget journal to a closed period, why?

Yes, a budget journal can be posted to any period that is in an open budget year
for that budget. This is regardless of the status of that period. The budget
journal is not linked with your accounting period. Once you have open the
budget period then you can book budget journal for that whole period.
17. How many ‘Current’ budgets can you have?

For each set of books, you can have only one current budget at any point in
time. The only distinction between a ‘current’ and an ‘open’ budget is that the
current budget defaults into the budget field on several budget-related forms. It
can be replaced however by any ‘open’ budget in the field.
18. What is a funding budget?
Funding budget is a budget against which accounting transactions are checked

for available funds when budgetary control is enabled for your set of books.
Funding Budgets are approved budgets.Two types of budgets are there in
Oracle Apps: 1- Fund 2- Plan.
Fund budget create the Budget Journal but plan budget used only for planning.
Fund budget requires journal entries, and is assigned to a summary template or
account range in the budget org, where the funds check level is set at Absolute
or Advisory. It is the assignment that makes it a ‘funding budget’; it is not done
at the budget definition level.
19. Why is my budget requiring budget journals?

At the set of books level that option is not enabled? This would happen when
the budget itself is defined to require budget journals. This is done at the budget
definition level.
20. Why can’t I inquire on my budget amounts from INQUIRE/BUDGETS
navigation path?
The Budget Inquiry form (GLXIQBUD) is used to perform inquiries about
master and detail budgets. GL compares summary balances between your
master and detail budgets, and checks for budget variances and violations. This
form only looks at summary accounts. To inquire on detail accounts you must
use the navigation INQUIRE/ACCOUNTS, and choose the ‘budget’ amount
type.
21. If I delete my budget org, will the budget amounts be deleted?

No, the amounts will be same. Deleting the budget organization does not
remove the budget amounts from the GL_BALANCES table.
22. Can I update/adjust an existing account range in my budget

organization?
Yes you can update an existing account range in Budget Organization.
23 How many times can a budget be purged?

Budget can be purged only one time.
24. Why is there no value in the REQUEST_ID column of

GL_BUDGET_INTERFACE for rows with data that failed to be uploaded
by the Budget Spreadsheet Upload program?
You are trying to open the next budget year. After navigating to the form and
querying the budget, you notice the [Open Next Year] button is grayed out. You
find that Account code combinations are not being added to the Budget
Organization.
25. Why don’t my Detail budgets roll up to my Master budget?
Detail budgets do not automatically roll up to the master budget. The GL uses
summary accounts to maintain master/detail budget relationships between
hierarchy levels. Summary templates are defined so that accounts in your lower
level detail budgets roll up into the same summary accounts as the detail
accounts in your controlling master budget. A common misconception is that
the detail budgets somehow roll up to the master budget by definition, this is
not true. You must actually budget to a detail account in the master budget; this
then serves as the controlling amount for the detail budgets. Master/Detail
budgets are used in the budgeting process to control Authority and identify
budgets that exceed control limits. They are not intended for reporting
purposes.
26. I was able to post a budget journal to a closed period, why?

A budget journal can be posted to any period that is in an open budget year for
that budget. This is regardless of the status of that period (closed, opened, or
future enterable).
27. Why don’t my budget amounts appear on my FSG?
To include budgets (encumbrances or currencies) in a FSG report, your report

definition must specify a row set of column set that has control values specified
in the Balance Control options. In the report definition itself, you associate
budget names with the control values that are assigned to the row or column
set.
Questions: How many types of Invoices in Oracle Account Payables

1)Standard Invoice
2)Debit Memo
3)Credit Memo
4)Withholding tax invoice5)PO Default
6)Prepayment Invoice
7)Expansive Reports
8)Recoring Invoices
9)mixed Invoices
Prepayment Invoice: Whenever we want make payments to the suppiler in advace that
time,we create this prepayment invoice and we will make the payment.
Credit Memo,Debit Memo:Both invoices are got -ve amount,and adjusted against
standard invoice.
Credit memo will be created, when ever suppiler giving discount.
Debit Memo will be created,if buyer is going to deduct the amount.
Question :How many key flexfields are there in Payables?
Answer: 0 (No key flexfields in PO,AP)
Question: Name few Account Payables Tables
AP_INVOICES_ALL
AP_INVOICE_DISTRUBUTIONS_ALL
AP_PAYMENTS_ALL
AP_PAYMENT_SCHEDULES_ALL
AP_INVOICE_PAYMENTS_ALLAP_TERMS_ALL
AP_TERM_LINES_ALL
AP_CHECKS_ALL
AP_CHECK_FORMATS
AP_HOLDS_ALL
Question: What is 2 way , 3 way and 4 way matching?
While creating the purchase order,we will mention the match approval level at
shippments
we will have 3 types
1)two way: PO & Invoice quantities must match with in the tolerance before the
corresponding invoice can be paid.
2)three way: PO, Receipt and invoice quantities must match with in the tolerance before
the corresponding invoice can be paid.3)four way: PO, Receipt, Inspection and invoice
quantities must match with in the tolerance before the corresponding invoice can be paid
What is a Hold? Explain the types of Hold
Invoice holds:If invoice is not approve then that invoice will be keeping under hold
status.By selecting holds button in invoice form,we can see the hold details.
Select * from ap_hold_all
Which interface tables are used for Invoice Import , give the important columns?
BASE TABLES:
AP_INVOICES_ALL
AP_INVOICE_PAYMENTS_ALL
AP_PAYMENT_SCHEDULES_ALL
AP_INVOICE_DISTRUBUTIONS_ALLAP_INVOICES_INTERFACE COLUMNS:
Invoice_id
Invoice_num
Po_number
vendor_id
vendor_num
vendor_site_id
vendor_site_code
invoice_amount
Ap_invoice_lines_interface columns:
Invoice_id
Invoice_line_id
line_number
line_type_lookup_codeamount
po_header_id
po_number
po_line_id
po_line_number
po_line_location_id
po_shipment_num
po_distrubution_id
po_distrubution_num
Inventory_item_id
Flow of Accounting Information:
If you are using Oracle Order Entry (without customizations), no accounting information
is available until you run AutoInvoice. You pass the transactions to Oracle Receivables
using the Receivables Interface. You then run AutoInvoice which creates the actual
transactions and uses AutoAccounting to derive the segment values for the GL Accounts.
If you are using Oracle Projects the account segment values are derived by a Projects’
process also called AutoAccounting and passed as values to Oracle Receivables via the
Streamline process, also using AutoInvoice. Whether you are manually entering your
receipts or processing them through AutoLockbox, the accounting information is
automatically determined by Oracle Receivables when you create and apply the receipts
(not when it is still a “QuickCash” batch). The values used are based on the setup values
for the bank where the receipts were deposited and the invoices they are paying.
Tips:
1. Always run the General Ledger Interface using the starting date of the period through
the last day of the period. This is applicable no matter when you are running the process
or if you know you will never have activity for that date, since sometimes the system uses
dates other than the dates you expect.
2. Depending on which patches you have applied, you may or may not see the Unposted
Items Report. If this report does run, always check each page to ensure that you have no
items that could not be passed to the General Ledger. If anything besides headings
appears, work with your IT department to resolve (since this is usually caused by a bug).
Verify that the amounts in the General Ledger Interface Report are reasonable and that
the debits equal the credits.
General Ledger Interface:When you invoke the General Ledger Interface process, you
initiate multiple programs that:
Finds all of the records for the period you specified that have not yet been passed to the
General Ledger;
Determines if the debits equal the credits;
Passes the data to GL for editing; and
Marks the records as having been passed (so they will not pass twice).
If you have specified that you want the Journal Import to also run, this process verifies
that the individual segments and combinations of segments are valid. Only when the
Journal Import completes successfully are the Journals available for posting.
3. Verify that the Journal Import has a status of “SUCCESS.” If not, you had a problem
that will need to be resolved or none of the items in the batch will be available for
posting. Generally you have a problem if an account was valid when the activity was
created, as you know, you cannot save with invalid values but, someone has since
disabled either a segment or the combination. An example of this is your Accounts
Receivable account that may have been valid when the invoice was originally created but
it is not longer valid, and a receipt was just applied against it. When you apply a receipt
to an invoice it always causes an offsetting entry against the original Accounts Receivable
account.
Should this occur, then
1. Re-enable the segment or combination;
2. Re-run the Journal Import (in GL — be sure to include the applicable id);
3. Create a manual journal entry (also in GL) to move the activity from the bad account to
the proper account (this is my one exception to never creating manual journal entries);
and
4. Re-disable the segment or combination.
By making the corrections in this way you are able to keep your GL in sync with your AR
activity and you have an audit trial of what you did to make the correction. You have the
option to correct in the Import Corrections form (in GL), but you lose the audit trail of
what you did and why. Note what you did and why and storing the notes in a handy
binder so you will be prepared when the auditors ask why you did what you did.
Journal Entries Reports: The Journal Entries reports are the best way to verify the
actual accounting for Oracle Receivables’ activities and the only way to view the
accounting for the foreign currency gains and losses. There are actually four reports that
give you varying levels of details regarding the journal entries you will be creating or
have already created. These reports may be run at anytime before or after you run the
General Ledger Interface. Your options are: Detail by Account (very large), Summary by
Account, Detail by Category (also large) and Summary by Category.
Tip: Run the Summary by Category and review to insure that there are no invalid or
illogical accounts, prior to running the General Ledger Interface. If you find funny
accounts, you can correct or create offsetting entries prior to posting. Run the Detail by
Category (just for that category and account) to see which specific activities used the
funny account. Correct the activity if possible. If not possible (i.e., adjustment), create an
offsetting entry using the proper account.
Tip: If you run this report for Unposted Items only, you must leave the Posted Date range
blank or nothing will appear on the report.
Period Close Procedures:
Tip:Never have more than one AR period open at one time. There have been problems
with entries appearing partially in one period and partially in another. Also, you may
accidentally enter activities in a period other than the period you intended.Create a
checklist to insure that you always know where you are and what you have to do next, so
you will not forget anything.Balance your AR activity to the Aging:Old Aging Balance
—–(Aged Trial Balance – 7 Buckets by Account)
Also balance your AR activity to your GL activity using the Journal Entries Report –
Summary by Category and the Account Analysis report (in GL). Note any manual journal
entries that used “your” accounts.
_____________________________________________
+ New Invoices ——-Transaction Register
+ Debit Memos ——- Transaction Register

+ Chargebacks ——–Transaction Register
- Credit Memos —— Transaction Register
- Receipts Applied —- Unapplied Receipts Register
+/- Adjustments ——Adjustment Register
- Items Not Aged —– Invoice Exceptions Report
____________________________________
New Aging Balance — Aged Trial Balance – 7 Buckets by Account
or Unidentified (Receipt Class)
CR : AR (from the invoice)
When you unapply a receipt, the accounting is just the opposite of the application
accounting. You debit the AR account for the original invoice and credit the unapplied
account based on the current unapplied account for the Receipt Class:
DR : AR (from the invoice)
CR : Unapplied (Receipt Class)
When you reverse a receipt, you have two possible options: re-open the invoices you
previously paid or create a debit memo for the amount of the reversed payment. If you re-
open the invoices, the system offsets the accounts used when you originally applied the
payment (from the invoice and the cash account). Note that this process also impacts the
unapplied account.
DR : Unapplied (Receipt Class)
: AR (from the invoice)
CR : Cash (Receipt Class)

: Unapplied (Receipt Class)
If you create a debit memo, you credit the original cash account but debit the Accounts
Receivable Account for the Debit Memo type you selected. You may override the
Accounts Receivable account when you enter the payment reversal.
DR : AR (Transaction Type – may override)
Chargebacks: You create Chargebacks when you are applying cash to close the original
invoice and create a new invoice for the amount that the customer short paid. By
definition, there is a one to one relationship between a Chargeback and the original
invoice. You need to set up values for Chargebacks in 3 places: Receivables Activity
where you specify the “wash” account used when creating a Chargeback. Transaction
Types where you specify the default AR account. A Memo Line (”Chargeback Line”) is
seeded by Oracle but it is just used for the line description when you print the
Chargeback and has no accounting impact. The Accounts Receivable account for the new
invoice is based on the Accounts Receivable account for the Chargeback but you may
override it at entry item. Oracle credits the Accounts Receivable account for the original
invoice (note that these two accounts may be different).
In the Category of Adjustment:DR : Chargeback Adjustment (Receivables Activity)
CR :
unapplied account.

CR :
AutoAccounting : AutoAccounting a very powerful setup feature that tells Oracle

Receivables how to determine the individual segment values for your Transactions
(invoices, debit memos, credit memos, chargebacks and commitments) using the rules
that you specify. You may use this feature when creating Transactions manually or
through AutoInvoice. The types of accounts impacted by AutoAccounting include:
- (Accounts) Receivable
- Revenue
- Tax
- Freight
- Unearned Revenue (for deferred revenue recognition)
- Unbilled Receivable (for deferred receivables recognition)

- AutoInvoice Clearing (for problems with extended amount)
- Possible sources of this information are the values you set up for the following:
- Transaction Types
- Salesreps
- Standard Lines (Items or Memo Lines)
- Taxes
- And/or hard coded values.
You may get one segment value for one type of account from a different place than for
another. See Appendix 1 for an example of a typical AutoAccounting setup.
You can use a similar worksheet to test the setup of your AutoAccounting rules. List your
Accounting Flexfield segments in the left column. For each type of account select the
source of each segment (based on the list of available sources) and fill in that box. Test
your theory by listing what all the setup accounts would be for a Transaction Type,
Salesrep, Item, Tax and Memo Line. Then use a white-board and fill in each segment, for
each type of account, with the values from each of the related sources. Verify that the
combinations are actually valid, if not, redesign how they will be set up or redefine your
AutoAccounting rules. Once you are satisfied with the results, enter your
AutoAccounting rules into your test system and start creating manual invoices. Verify
that you have not created invalid account values as the defaults.
Tip: I prefer to assign all segments to sources versus using hard coded values. This seems
more flexible for future changes.
Invoices: When you create an invoice either through AutoInvoice or manually, you take
advantage of AutoAccounting to provide the default Accounting Flexfield values. For
manual invoices you have the option to override the default values.
For a standard Invoice:
DR : AR (AutoAccounting – may override)
CR : Revenue (AutoAccounting – may override)
:Tax (AutoAccounting – may override)
:Freight (AutoAccounting – may override)

You may also create invoices with special accounting and invoicing rules that allow you
to defer revenue recognition for the percentage and number of periods that you specify.
The following is an example of an invoice created with deferred revenue recognition for
$12,000 split evenly over 12 periods:
For invoices with deferred revenue: a) When first created:

DR : AR (AutoAccounting – may override) 12000
CR :Unearned Revenue (AutoAccounting) 1000
DR : Unearned Revenue (AutoAccounting) 12000
CR : Revenue (AutoAccounting – may override) 1000
b) For each of the next 11 periods:
CR : Revenue (AutoAccounting) 1000
If you are using deferred revenue recognition, you need to run the revenue recognition
process for each period (Run Revenue Recognition) and runs automatically as part of the
General Ledger Interface.
Tip: To reduce the time it takes to close the period, run Revenue Recognition prior to the
time when you are actually closing (e.g., the night before the close). This will process the
majority of the updates prior to the actual close. Recurring Invoices (Transaction Copy)
are treated like regular invoices, except they have different GL dates. Once you have
created an invoice copy, it really is just another invoice with different dates.
Debit Memos: Debit memos work just like standard invoices (you even create them on
the same forms) — taking advantage of AutoAccounting but with overridable segments.
If you defined Memo Lines for use with your debit memos, they will provide the default
accounting segments if you have set up AutoAccounting to use Standard Lines values for
your Revenue accounts.
Credit Memos And On Account Credits: There are two types of credit memos: credit
memos that you create to offset an individual invoice are called “Credit Memos.” Credit
memos that impact a customer’s account but are not initially tied to a specific invoice are
called “On-Account Credits.” On-account credits may be tied to invoice(s) using the
Receipts Applications window, at any time. The accounting for Credit Memos usually
offsets the applicable accounts from the original invoice (if you set your System Profile
option AR: Use Invoice Account For Credit Memo to “Yes”). Credit memos and on-
account credits that are created using AutoInvoice take advantage of AutoAccounting
and/or hard coded values. You may override the default values if you are entering
manually.
Credit Memo tied to an invoice:

DR : Revenue (from the related invoice – may override)
: AR (from the related invoice – may override)
: Tax (from the related invoice – may override)
CR : Freight (from the related invoice – may override)
On-account credits take advantage of AutoAccounting and Standard Lines (Memo Lines)
depending on how you set up your AutoAccounting rules for the default credit and debit
GL Accounts. You may override the default values at entry time if you are entering
manually.
DR : Revenue (Memo Line – may override)
CR : AR (AutoAccounting – may override)
When you apply an on-account credit to invoice(s), you debit the credit account you used
when you created the on-account credit. The Accounts Receivable account for the invoice
being offset is credited. You may not override these values.
DR : AR (from the On-Account Credit)
Cash Receipts (Excluding Miscellaneous Receipts): The accounting for receipts,

except for Miscellaneous Receipts, is totally controlled behind the scenes by Oracle
Receivables. The GL Accounts are determined by the values you defined in Receipt Class
for the batch. NOTE: You have one Cash, Unapplied, On-Account, Unidentified, Earned
Discount and Unearned Discount account for each bank and class, which does not allow
you to split the Unapplied, etc. accounts for the applicable cost center or division. You
may set up different values for each bank and class that you use (especially important for
the cash account). Or, you may share the GL Accounts for multiple bank accounts (i.e.,
the unapplied and discount accounts). The key accounts are: – Your cash account (the
default debit account for that bank account);
Tip: Often AP and AR share the same bank account but it is helpful to use a different but
sequential GL account for each. This eases the reconciliation but you can roll together for
FSG reporting.
- Your unapplied payments account (the default used until you match the payment to an
invoice);
- Your on-account account (used to account for pre-payments until you apply them to
invoice(s));
- Your unidentified account (used for receipts where you do not know which customer
sent the receipt);
Tip: Often companies use the same GL Account for unapplied, on-account and
unidentified. This is fine as long as: the account is not used for anything else and it is not
an Accounts Receivable or cash account.
- Your earned and unearned discount accounts (used when a client pays invoices in
accordance with the early payment terms. These are also often the same. Earned
discounts are for payments made within the discount terms, unearned discounts are paid
after the discount term but are allowed anyway.
When you match a receipt to an invoice, the cash account (debit) defaults from the
Receipt Class for the Receipt batch. The Accounts Receivable account (credit) defaults
from the invoice that is being paid. NOTE: Even if you instantly match a payment to an
open invoice, Oracle still creates credits and debits to the unapplied account.
Payment applied to an invoice without discount terms:DR : Cash (Receipt Class):

Unapplied (Receipt Class)CR : Unapplied (Receipt Class)
Payment applied to an invoice with discount terms:
: Discount (Receipt Class)
When you leave a receipt as unapplied:
When you apply unapplied, on-account or unidentified receipts, the accounting is

determined by the original status. The accounts used are based on the accounts you
currently are using for the Receipt Class. The Accounts Receivable account still comes
from the invoice.
On-Account (Receipt Class)or Unidentified (Receipt Class)

unapplied account.
CR :
For unidentified receipts:
CR : Unidentified (Receipt Class)
When you identify a receipt is as a pre-payment or deposit:
CR : On-Account (Receipt Class)

from the invoice.
unapplied account.

CR :
CR : AR (from the original invoice)

DR :
In the Category of Adjustment (AR):
In the Category of Chargeback:
CR : Chargeback Adjustment (Receivables Activity)
In the Category of Chargeback (AR):CR :

In the Category of Trade Receipts:
CR :
Miscellaneous Receipts: Miscellaneous Receipts are any receipts that are not for open
receivables. Examples include Cobra payments, T-shirt sales, utility refunds, and returns
on investments. Due to the nature of this activity, you may need to credit any account
within the chart of accounts. The Distribution Window in the Receipts form allows you to
do just that. You may run into an Account Security Rule set up to restrict usage of
accounts by application. If you find that you may not use an account that you need, work
with your System Administrator to change the Account Security Rules. You may pre-
define the credit accounts that you usually use to speed entry (using Receivables Activity)
but you also have the flexibility to override the values at entry time. You also have the
ability to split a single receipt into multiple accounts (you may also pre-define those
accounts using Distribution Sets). If you will always be splitting the accounts, you should
define a Distribution Set. A distribution set is a name and one or more GL Accounts and
percentages that you define. You must create a Receivable Activity that refers to the
Distribution Set. When you enter Miscellaneous Receipts, you refer to the Receivables
Activities that you defined above. However, you may override the default GL Accounts,
the individual segments, the percentages and/or the amounts. The cash account used
defaults based on the Receipt Class for the bank you specified on the Batch Screen, and
you may not override or view the value.
DR : Cash (Receipt Class)
CR : Miscellaneous Account(s) (Receivables Activity or Distribution Set – may override)
In the Category of Trade Receipts (AR):
CR : AR (from the original invoice)
Receivable Adjustments: Receivable Adjustments are generally write-offs, or changes

to the invoice balance due for over- or under-payment by the customer, or the addition of
finance charges. Pre-define commonly used adjustment types using the Receivables
Activity form. This speeds entry, but you may override the default values as you enter the
adjustments. NOTE: Always define a GL Account and not a Distribution Set when you
define Receivable Activities for adjustments.Tip: When entering an adjustment, never
use an Accounts Receivable Account. Oracle Receivables already automatically offsets
the AR account for the invoice being adjusted and you will create a wash entry.
A Receivables Adjustment is always applied to a specific invoice so it impacts the

Accounts Receivable account for that invoice. Receivables adjustments may either be
positive (debit AR, and increase the invoice balance) or negative (credit AR and decrease
the invoice balance). Examples include:
Add a finance charge (note that this is a positive adjustment that increases the balance
due):
CR : Finance Charges (Receivables Activity – may override)
Reduce the freight amount:

DR : Freight (Receivables Activity – may override)
You may use AutoAdjustments to perform mass cleanup of open invoices and on-
account credits. The Accounts Receivable account credited is the Accounts Receivable
account for the transaction. The account debited is based on the Receivables Activity you
select when you submit the AutoAdjustment process. Note that ALL adjustments made
during this process will use that exact same “write off” account even if the original
invoices are for different companies, or cost centers. This may be a consideration in
determining if you can actually utilize AutoAdjustments, or if you want to run multiple
passes of AutoAdjustment by Transaction Type and Adjustment Activity.
Foreign Currency Gains and Losses: Transactions that are not in your base currency
may cause gains or losses to occur due to fluctuations in the exchange rates. This is
automatically accounted for by Oracle Receivables. When you enter the Transaction, the
applicable exchange rate for the date you enter it is stored with the transaction. When you
enter the related receipt the applicable exchange rate for the date you enter the receipt is
stored with the receipt. The gain or loss is determined based on the difference in the value
of the money (in your base currency) between when the invoice was created and when
the receipt was created. The gain and loss accounts are derived based on the values in
your System Options and how you set up Flexbuilder. Note that most companies use the
default setup for Flexbuilder. Note that there is no gain or loss if you apply an adjustment
since both the adjustment and the invoice use the same rate. You can predict Gains and
Losses using the Projected Gains/Losses Report. You can only view the gain/loss
accounting activity by running the Journal Entries Report.
Write-off the invoice balance:DR : Cost of Doing Business (Receivables Activity – may
override)
Loss – now worth less:

DR : Cash (Receipt Class at the receipt rate)
: Unapplied (Receipt Class at the receipt rate)
: Loss (System Options – difference between the invoice and receipt values)
Gain – now worth more:
CR : AR (from the invoice at the invoice rate)

: Gain (System Options – difference between the invoice and receipt values)
CR : AR (from the invoice at the invoice rate)
:Unapplied (Receipt Class at the receipt rate)
AutoAccounting : AutoAccounting a very powerful setup feature that tells Oracle

Receivables how to determine the individual segment values for your Transactions
(invoices, debit memos, credit memos, chargebacks and commitments) using the rules
that you specify. You may use this feature when creating Transactions manually or
through AutoInvoice. The types of accounts impacted by AutoAccounting include:
- (Accounts) Receivable
- Revenue
- Tax
- Freight
- Unearned Revenue (for deferred revenue recognition)
- Unbilled Receivable (for deferred receivables recognition)
- AutoInvoice Clearing (for problems with extended amount)
- Possible sources of this information are the values you set up for the following:
- Transaction Types
- Salesreps
- Standard Lines (Items or Memo Lines)
- Taxes
- And/or hard coded values.
You may get one segment value for one type of account from a different place than for
another. See Appendix 1 for an example of a typical AutoAccounting setup.
You can use a similar worksheet to test the setup of your AutoAccounting rules. List your
Accounting Flexfield segments in the left column. For each type of account select the
source of each segment (based on the list of available sources) and fill in that box. Test
your theory by listing what all the setup accounts would be for a Transaction Type,
Salesrep, Item, Tax and Memo Line. Then use a white-board and fill in each segment, for
each type of account, with the values from each of the related sources. Verify that the
combinations are actually valid, if not, redesign how they will be set up or redefine your
AutoAccounting rules. Once you are satisfied with the results, enter your
AutoAccounting rules into your test system and start creating manual invoices. Verify
that you have not created invalid account values as the defaults.
Tip: I prefer to assign all segments to sources versus using hard coded values. This seems
more flexible for future changes.
Invoices: When you create an invoice either through AutoInvoice or manually, you take
advantage of AutoAccounting to provide the default Accounting Flexfield values. For
manual invoices you have the option to override the default values.
For a standard Invoice:
DR : AR (AutoAccounting – may override)
CR : Revenue (AutoAccounting – may override)
:Tax (AutoAccounting – may override)
:Freight (AutoAccounting – may override)
You may also create invoices with special accounting and invoicing rules that allow you
to defer revenue recognition for the percentage and number of periods that you specify.
The following is an example of an invoice created with deferred revenue recognition for
$12,000 split evenly over 12 periods:
For invoices with deferred revenue: a) When first created:

DR : AR (AutoAccounting – may override) 12000
CR :Unearned Revenue (AutoAccounting) 1000
CR : Revenue (AutoAccounting – may override) 1000
b) For each of the next 11 periods:
CR : Revenue (AutoAccounting) 1000
If you are using deferred revenue recognition, you need to run the revenue recognition
process for each period (Run Revenue Recognition) and runs automatically as part of the
General Ledger Interface.
Tip: To reduce the time it takes to close the period, run Revenue Recognition prior to the
time when you are actually closing (e.g., the night before the close). This will process the
majority of the updates prior to the actual close. Recurring Invoices (Transaction Copy)
are treated like regular invoices, except they have different GL dates. Once you have
created an invoice copy, it really is just another invoice with different dates.
Debit Memos: Debit memos work just like standard invoices (you even create them on
the same forms) — taking advantage of AutoAccounting but with overridable segments.
If you defined Memo Lines for use with your debit memos, they will provide the default
accounting segments if you have set up AutoAccounting to use Standard Lines values for
your Revenue accounts.
Credit Memos And On Account Credits: There are two types of credit memos: credit
memos that you create to offset an individual invoice are called “Credit Memos.” Credit
memos that impact a customer’s account but are not initially tied to a specific invoice are
called “On-Account Credits.” On-account credits may be tied to invoice(s) using the
Receipts Applications window, at any time. The accounting for Credit Memos usually
offsets the applicable accounts from the original invoice (if you set your System Profile
option AR: Use Invoice Account For Credit Memo to “Yes”). Credit memos and on-
account credits that are created using AutoInvoice take advantage of AutoAccounting
and/or hard coded values. You may override the default values if you are entering
manually.
Credit Memo tied to an invoice:
DR : Revenue (from the related invoice – may override)
: AR (from the related invoice – may override)
: Tax (from the related invoice – may override)
CR : Freight (from the related invoice – may override)
On-account credits take advantage of AutoAccounting and Standard Lines (Memo Lines)
depending on how you set up your AutoAccounting rules for the default credit and debit
GL Accounts. You may override the default values at entry time if you are entering
manually.
DR : Revenue (Memo Line – may override)
CR : AR (AutoAccounting – may override)
When you apply an on-account credit to invoice(s), you debit the credit account you used
when you created the on-account credit. The Accounts Receivable account for the invoice
being offset is credited. You may not override these values.
DR : AR (from the On-Account Credit)
Cash Receipts (Excluding Miscellaneous Receipts): The accounting for receipts,

except for Miscellaneous Receipts, is totally controlled behind the scenes by Oracle
Receivables. The GL Accounts are determined by the values you defined in Receipt Class
for the batch. NOTE: You have one Cash, Unapplied, On-Account, Unidentified, Earned
Discount and Unearned Discount account for each bank and class, which does not allow
you to split the Unapplied, etc. accounts for the applicable cost center or division. You
may set up different values for each bank and class that you use (especially important for
the cash account). Or, you may share the GL Accounts for multiple bank accounts (i.e.,
the unapplied and discount accounts). The key accounts are: – Your cash account (the
default debit account for that bank account);
Tip: Often AP and AR share the same bank account but it is helpful to use a different but
sequential GL account for each. This eases the reconciliation but you can roll together for
FSG reporting.
- Your unapplied payments account (the default used until you match the payment to an
invoice);
- Your on-account account (used to account for pre-payments until you apply them to
invoice(s));
- Your unidentified account (used for receipts where you do not know which customer
sent the receipt);
Tip: Often companies use the same GL Account for unapplied, on-account and
unidentified. This is fine as long as: the account is not used for anything else and it is not
an Accounts Receivable or cash account.
- Your earned and unearned discount accounts (used when a client pays invoices in
accordance with the early payment terms. These are also often the same. Earned
discounts are for payments made within the discount terms, unearned discounts are paid
after the discount term but are allowed anyway.
When you match a receipt to an invoice, the cash account (debit) defaults from the
Receipt Class for the Receipt batch. The Accounts Receivable account (credit) defaults
from the invoice that is being paid. NOTE: Even if you instantly match a payment to an
open invoice, Oracle still creates credits and debits to the unapplied account.
Payment applied to an invoice without discount terms:DR : Cash (Receipt Class):

Unapplied (Receipt Class)CR : Unapplied (Receipt Class)
Payment applied to an invoice with discount terms:
: Discount (Receipt Class)
When you leave a receipt as unapplied:
When you identify a receipt is as a pre-payment or deposit:
CR : On-Account (Receipt Class)

from the invoice.

or Unidentified (Receipt Class)
unapplied account.

CR :
unapplied account.
CR :
Useful AR Tables Informations

March 7, 2009 · 5 Comments
Hello Friends , here is some of quite commonly used AR ( receivables )tables and their
usage. There are many other tables also in AR but here i am putting only few commonly
used tables. for other table if needed we can dig furthur. Let go through below article and
let me know if it useful.
1- RA_CUSTOMER_TRX_ALL
2- RA_CUSTOMER_TRX_LINES_ALL
3- RA_CUST_TRX_LINE_GL_DIST_ALL
4- AR_PAYMENT_SCHEDULES_ALL
5- AR_RECEIVABLES_TRX_ALL
6- AR_RECEIVABLE_APPLICATIONS_ALL
RA_CUSTOMER_TRX_ALL
This table stores invoice, debit memo, commitment, and credit memo header information.
Each row includes general invoice information such as customer, transaction type, and
printing instructions. You need one row for each invoice, debit memo, commitment, and
credit memo you create in Oracle Receivables. Invoices, debit memos, credit memos, and
commitments are all distinguished by their transaction types stored in
RA_CUST_TRX_TYPES_ALL. If you entered a credit memo,
PREVIOUS_CUSTOMER_TRX_ID stores the customer transaction identifier of the
invoice you credited. In the case of on account credits, which are not related to any
invoice at creation, PREVIOUS_CUSTOMER_TRX_ID is null. If you created an invoice
against a commitment, Oracle Receivables stores the customer transaction identifier of
the commitment in INITIAL_CUSTOMER_TRX_ID, otherwise it is null.
COMPLETE_FLAG stores ’Y’ for Yes and ’N’ for No to indicate if your invoice is
complete. When you complete an invoice, Oracle Receivables creates your payment
schedules and updates any commitments against this invoice. Before an invoice can be
completed, it must have at least one invoice line, revenue records must exist for each line
and add up to the line amount, and a sales tax record must exist for each line.
Required Columns:
SOLD_TO_CUSTOMER_ID,
SOLD_TO_SITE_USE_ID,
BILL_TO_CUSTOMER_ID,
BILL_TO_SITE_USE_ID,
SHIP_TO_SITE_USE_ID,
PRINTING_OPTION,
PRINTING_PENDING,
TERM_ID,
REMIT_TO_ADDRESS_ID,
PRIMARY_SALES_REP_ID, and
INVOICE_CURRENCY_CODE
are required even though they are null allowed. The primary key for this table is
CUSTOMER_TRX_ID.
RA_CUSTOMER_TRX_LINES_ALL
This table stores information about invoice, debit memo, credit memo, and commitment
lines. For example, an invoice can have one line for Product A and another line for
Product B. You need one row for each line. Invoice, debit memo, credit memo, and
commitment lines are distinguished by the transaction type of the corresponding
RA_CUSTOMER_TRX_ALL record.Also, credit memos are required to have a value in
PREVIOUS_CUSTOMER_TRX_LINE_ID, except on account credits which are not
related to specific invoices/invoice lines at creation time, will not have values in this
column. QUANTITY_ORDERED stores the amount of product ordered.
QUANTITY_INVOICED stores the amount of product invoiced. For invoices entered
through the window, QUANTITY_ORDERED and QUANTITY_INVOICED must be
the same. For invoices imported through AutoInvoice, QUANTITY_ORDERED and
QUANTITY_INVOICED can be different. If you enter a credit memo,
QUANTITY_CREDITED stores the amount of product credited. UOM_CODE stores the
unit of measure code as defined in MTL_UNITS_OF_MEASURE.
UNIT_STANDARD_PRICE stores the list price per unit for this transaction line.
UNIT_SELLING_PRICE stores the selling price per unit for this transaction line. For
transactions imported through AutoInvoice, UNIT_STANDARD_PRICE and
UNIT_SELLING_PRICE can be different. DESCRIPTION, TAXING_RULE,
QUANTITY_ORDERED, UNIT_STANDARD_PRICE,UOM_CODE, and
UNIT_SELLING_PRICE are required even though they are null allowed. LINE_TYPE
differentiates between the different types of lines that are stored in this table. LINE points
to regular invoice lines that normally refer to an item. TAX signifies that this is a tax line.
The column LINK_TO_CUST_TRX_LINE_ID references another row in this table that
is the invoice line associated with the row of type TAX. FREIGHT works the same way
as TAX but there you can have at most one FREIGHT type l ine per invoice line of type
LINE. You can also have one line of type FREIGHT that has a null
LINK_TO_CUST_TRX_LINE_ID (and this is referred to as header level freight).
CHARGES works just like the LINE type. A line_type of ’CB’ is created for a
Chargeback line. For every row in this table that belongs to a complete transaction (where
RA_CUSTOMER_TRX.COMPLETE_FLAG = Y), there must be at least one row in the
table RA_CUST_TRX_LINE_GL_DIST (which stores accounting information), even for
non–postable transactions. The primary key for this table is
CUSTOMER_TRX_LINE_ID.
RA_CUST_TRX_LINE_GL_DIST_ALL
This table stores the accounting records for revenue, unearned revenue and unbilled
receivables for each invoice or credit memo line. Each row includes the GL account and
the amount of the accounting entry. The AMOUNT column in this table is required even
though it is null allowed. You need one row for each accounting distribution. You must
have at least one (but you can have multiple) accounting distributions for each invoice or
credit memo line. Oracle Receivables uses this information to post the proper amounts to
your general ledger. If your invoice or credit memo has a transaction type where Post to
GL is set to No, Oracle Receivables assigns Null to GL_DATE. If your AutoAccounting
is unable to complete your general ledger default accounts using the AutoAccounting
rules you define, incomplete general ledger accounts are stored in
CONCATENATED_SEGMENTS. If you are importing a transaction through
AutoInvoice and the general ledger date of your transaction is in a closed accounting
period, AutoInvoice uses the general ledger date of the first open accounting period and
stores the original general ledger date in ORIGINAL_GL_DATE. ACCOUNT_CLASS
defines which type of distribution row you are on. The ACCOUNT_CLASS REC
represents the receivable account and is for the total amount of the invoice. There can be
at most two REC rows. One that has a ACCOUNT_SET_FLAG set to Y and the other
has ACCOUNT_SET_FLAG set to N. Use LATEST_REC_FLAG to join to the later of
the two rows. ACCOUNT_SET_FLAG is Y if this row is part of an account set. An
account set is a set of rows that represent a model distribution. Account sets are used for
invoices with rules. The rows represent how the actual distribution rows should be
created and what percentage of the actual distribution should be allocated to each
account. For invoices with rules, the distributions are not created when the invoice is
initially created. Instead, the invoices are created when the Revenue Recognition program
is run. The primary key for this table is CUST_TRX_LINE_GL_DIST_ID.
AR_PAYMENT_SCHEDULES_ALL
This table stores all transactions except adjustments and miscellaneous cash receipts.
Oracle Receivables updates this table when activity occurs against an invoice, debit
memo, chargeback, credit memo, on account credit, or receipt. Oracle Receivables groups
different transactions bythe column CLASS. These classes include invoice (INV), debit
memos(DM), guarantees (GUAR), credit memos (CM), deposits (DEP),chargebacks
(CB), and receipts (PMT). Transaction classes determine which columns in this table
Oracle Receivables updates when a transaction occurs, and whether a transaction relates
to either the RA_CUSTOMER_TRX_ALL table or the
AR_CASH_RECEIPTS_ALLtable. AR_PAYMENT_SCHEDULES_ALL joins to the
RA_CUSTOMER_TRX_ALL table for non–payment transaction entries such as the
creation of credit memos, debit memos, invoices, chargebacks, or deposits.
AR_PAYMENT_SCHEDULES_ALL uses the foreign key CUSTOMER_TRX_ID to
join to the RA_CUSTOMER_TRX_ALL table for these transactions.
AR_PAYMENT_SCHEDULES_ALL joins to the AR_CASH_RECEIPTS_ALL table for
invoice–related payment transactions using the foreign key CASH_RECEIPT_ID. When
a receiptis applied, Oracle Receivables updates AMOUNT_APPLIED, STATUS and
AMOUNT_DUE_REMAINING. STATUS changes from ’OP’ to ’CL’for any transaction
that has an AMOUNT_DUE_REMAINING value of 0(Zero).
ACTUAL_DATE_CLOSED and GL_DATE_CLOSED are populated with the date of the
latest transaction. For a receipt, the amount due remaining includes on account and
unapplied amounts. Oracle Receivables stores debit items such as invoices, debit memos,
chargebacks, deposits, and guarantees as positive numbers in the
AMOUNT_DUE_REMAINING and AMOUNT_DUE_ORIGINAL columns. Credit
items such as credit memos and receipts are stored as negative numbers. In Release 10,
receipts can be confirmed or not confirmed as designated by the CONFIRMED_FLAG
column. The sum of the AMOUNT_DUE_REMAINING column for a customer for all
confirmed payment schedules reflects the current customer balance. If this amount is
negative, then this column indicates the credit balance amount currently available for this
customer. For invoices with split terms, one record is created in
RA_CUSTOMER_TRX_ALL and one record is stored in
AR_PAYMENT_SCHEDULES_ALL for each installment. In
AR_PAYMENT_SCHEDULES_ALL, DUE_DATE and AMOUNT_DUE_REMAINING
can differ for each installment of a split term invoice. Each installment is differentiated
by the TERMS_SEQUENCE_NUMBER column.
If you create a debit memo reversal when you reverse a receipt, Oracle Receivables
creates a new payment schedule record for the debit memo and fills in
REVERSED_CASH_RECEIPT_ID with the CASH_RECEIPT_ID of the receipt that
was reversed. Oracle Receivables creates a new payment schedule record when you
create a chargeback in the Receipts window. ASSOCIATED_CASH_RECEIPT_ID is the
cash receipt of the payment you entered when you created the chargeback in this window.
GL_DATE_CLOSED indicates the general ledger date on which your transaction was
closed.
This column identifies which transactions Oracle Receivables selects when it displays
current and overdue debit items in the aging reports. The aging reports also utilize the
current balances in AMOUNT_DUE_REMAINING to display outstanding amounts for
current and overdue debit items. ACTUAL_DATE_CLOSED gives the date on which
you applied a payment or credit to an open transaction that set
AMOUNT_DUE_REMAINING to 0 for that transaction. Oracle Receivables uses
ACTUAL_DATE_CLOSED to determine which transactions to include when you print
statements. The primary key for this table is PAYMENT_SCHEDULE_ID, which
identifies the transaction that created the row.
RA_CUSTOMER_TRX_ALL
This table stores invoice, debit memo, commitment, and credit memo header information.
Each row includes general invoice information such as customer, transaction type, and
printing instructions. You need one row for each invoice, debit memo, commitment, and
credit memo you create in Oracle Receivables. Invoices, debit memos, credit memos, and
commitments are all distinguished by their transaction types stored in
RA_CUST_TRX_TYPES_ALL. If you entered a credit memo,
PREVIOUS_CUSTOMER_TRX_ID stores the customer transaction identifier of the
invoice you credited. In the case of on account credits, which are not related to any
invoice at creation, PREVIOUS_CUSTOMER_TRX_ID is null. If you created an invoice
against a commitment, Oracle Receivables stores the customer transaction identifier of
the commitment in INITIAL_CUSTOMER_TRX_ID, otherwise it is null.
COMPLETE_FLAG stores ’Y’ for Yes and ’N’ for No to indicate if your invoice is
complete. When you complete an invoice, Oracle Receivables creates your payment
schedules and updates any commitments against this invoice. Before an invoice can be
completed, it must have at least one invoice line, revenue records must exist for each line
and add up to the line amount, and a sales tax record must exist for each line.
Required Columns:
SOLD_TO_CUSTOMER_ID,
SOLD_TO_SITE_USE_ID,
BILL_TO_CUSTOMER_ID,
BILL_TO_SITE_USE_ID,
SHIP_TO_SITE_USE_ID,
PRINTING_OPTION,
PRINTING_PENDING,
TERM_ID,
REMIT_TO_ADDRESS_ID,
PRIMARY_SALES_REP_ID, and
INVOICE_CURRENCY_CODE
are required even though they are null allowed. The primary key for this table is
CUSTOMER_TRX_ID.
RA_CUSTOMER_TRX_LINES_ALL
This table stores information about invoice, debit memo, credit memo, and commitment
lines. For example, an invoice can have one line for Product A and another line for
Product B. You need one row for each line. Invoice, debit memo, credit memo, and
commitment lines are distinguished by the transaction type of the corresponding
RA_CUSTOMER_TRX_ALL record.Also, credit memos are required to have a value in
PREVIOUS_CUSTOMER_TRX_LINE_ID, except on account credits which are not
related to specific invoices/invoice lines at creation time, will not have values in this
column. QUANTITY_ORDERED stores the amount of product ordered.
QUANTITY_INVOICED stores the amount of product invoiced. For invoices entered
through the window, QUANTITY_ORDERED and QUANTITY_INVOICED must be
the same. For invoices imported through AutoInvoice, QUANTITY_ORDERED and
QUANTITY_INVOICED can be different. If you enter a credit memo,
QUANTITY_CREDITED stores the amount of product credited. UOM_CODE stores the
unit of measure code as defined in MTL_UNITS_OF_MEASURE.
UNIT_STANDARD_PRICE stores the list price per unit for this transaction line.
UNIT_SELLING_PRICE stores the selling price per unit for this transaction line. For
transactions imported through AutoInvoice, UNIT_STANDARD_PRICE and
UNIT_SELLING_PRICE can be different. DESCRIPTION, TAXING_RULE,
QUANTITY_ORDERED, UNIT_STANDARD_PRICE,UOM_CODE, and
UNIT_SELLING_PRICE are required even though they are null allowed. LINE_TYPE
differentiates between the different types of lines that are stored in this table. LINE points
to regular invoice lines that normally refer to an item. TAX signifies that this is a tax line.
The column LINK_TO_CUST_TRX_LINE_ID references another row in this table that
is the invoice line associated with the row of type TAX. FREIGHT works the same way
as TAX but there you can have at most one FREIGHT type l ine per invoice line of type
LINE. You can also have one line of type FREIGHT that has a null
LINK_TO_CUST_TRX_LINE_ID (and this is referred to as header level freight).
CHARGES works just like the LINE type. A line_type of ’CB’ is created for a
Chargeback line. For every row in this table that belongs to a complete transaction (where
RA_CUSTOMER_TRX.COMPLETE_FLAG = Y), there must be at least one row in the
table RA_CUST_TRX_LINE_GL_DIST (which stores accounting information), even for
non–postable transactions. The primary key for this table is
CUSTOMER_TRX_LINE_ID.
RA_CUST_TRX_LINE_GL_DIST_ALL
This table stores the accounting records for revenue, unearned revenue and unbilled
receivables for each invoice or credit memo line. Each row includes the GL account and
the amount of the accounting entry. The AMOUNT column in this table is required even
though it is null allowed. You need one row for each accounting distribution. You must
have at least one (but you can have multiple) accounting distributions for each invoice or
credit memo line. Oracle Receivables uses this information to post the proper amounts to
your general ledger. If your invoice or credit memo has a transaction type where Post to
GL is set to No, Oracle Receivables assigns Null to GL_DATE. If your AutoAccounting
is unable to complete your general ledger default accounts using the AutoAccounting
rules you define, incomplete general ledger accounts are stored in
CONCATENATED_SEGMENTS. If you are importing a transaction through
AutoInvoice and the general ledger date of your transaction is in a closed accounting
period, AutoInvoice uses the general ledger date of the first open accounting period and
stores the original general ledger date in ORIGINAL_GL_DATE. ACCOUNT_CLASS
defines which type of distribution row you are on. The ACCOUNT_CLASS REC
represents the receivable account and is for the total amount of the invoice. There can be
at most two REC rows. One that has a ACCOUNT_SET_FLAG set to Y and the other
has ACCOUNT_SET_FLAG set to N. Use LATEST_REC_FLAG to join to the later of
the two rows. ACCOUNT_SET_FLAG is Y if this row is part of an account set. An
account set is a set of rows that represent a model distribution. Account sets are used for
invoices with rules. The rows represent how the actual distribution rows should be
created and what percentage of the actual distribution should be allocated to each
account. For invoices with rules, the distributions are not created when the invoice is
initially created. Instead, the invoices are created when the Revenue Recognition program
is run. The primary key for this table is CUST_TRX_LINE_GL_DIST_ID.
AR_PAYMENT_SCHEDULES_ALL
This table stores all transactions except adjustments and miscellaneous cash receipts.
Oracle Receivables updates this table when activity occurs against an invoice, debit
memo, chargeback, credit memo, on account credit, or receipt. Oracle Receivables groups
different transactions bythe column CLASS. These classes include invoice (INV), debit
memos(DM), guarantees (GUAR), credit memos (CM), deposits (DEP),chargebacks
(CB), and receipts (PMT). Transaction classes determine which columns in this table
Oracle Receivables updates when a transaction occurs, and whether a transaction relates
to either the RA_CUSTOMER_TRX_ALL table or the
AR_CASH_RECEIPTS_ALLtable. AR_PAYMENT_SCHEDULES_ALL joins to the
RA_CUSTOMER_TRX_ALL table for non–payment transaction entries such as the
creation of credit memos, debit memos, invoices, chargebacks, or deposits.
AR_PAYMENT_SCHEDULES_ALL uses the foreign key CUSTOMER_TRX_ID to
join to the RA_CUSTOMER_TRX_ALL table for these transactions.
AR_PAYMENT_SCHEDULES_ALL joins to the AR_CASH_RECEIPTS_ALL table for
invoice–related payment transactions using the foreign key CASH_RECEIPT_ID. When
a receiptis applied, Oracle Receivables updates AMOUNT_APPLIED, STATUS and
AMOUNT_DUE_REMAINING. STATUS changes from ’OP’ to ’CL’for any transaction
that has an AMOUNT_DUE_REMAINING value of 0(Zero).
ACTUAL_DATE_CLOSED and GL_DATE_CLOSED are populated with the date of the
latest transaction. For a receipt, the amount due remaining includes on account and
unapplied amounts. Oracle Receivables stores debit items such as invoices, debit memos,
chargebacks, deposits, and guarantees as positive numbers in the
AMOUNT_DUE_REMAINING and AMOUNT_DUE_ORIGINAL columns. Credit
items such as credit memos and receipts are stored as negative numbers. In Release 10,
receipts can be confirmed or not confirmed as designated by the CONFIRMED_FLAG
column. The sum of the AMOUNT_DUE_REMAINING column for a customer for all
confirmed payment schedules reflects the current customer balance. If this amount is
negative, then this column indicates the credit balance amount currently available for this
customer. For invoices with split terms, one record is created in
RA_CUSTOMER_TRX_ALL and one record is stored in
AR_PAYMENT_SCHEDULES_ALL for each installment. In
AR_PAYMENT_SCHEDULES_ALL, DUE_DATE and AMOUNT_DUE_REMAINING
can differ for each installment of a split term invoice. Each installment is differentiated
by the TERMS_SEQUENCE_NUMBER column.
If you create a debit memo reversal when you reverse a receipt, Oracle Receivables
creates a new payment schedule record for the debit memo and fills in
REVERSED_CASH_RECEIPT_ID with the CASH_RECEIPT_ID of the receipt that
was reversed. Oracle Receivables creates a new payment schedule record when you
create a chargeback in the Receipts window. ASSOCIATED_CASH_RECEIPT_ID is the
cash receipt of the payment you entered when you created the chargeback in this window.
GL_DATE_CLOSED indicates the general ledger date on which your transaction was
closed.
This column identifies which transactions Oracle Receivables selects when it displays
current and overdue debit items in the aging reports. The aging reports also utilize the
current balances in AMOUNT_DUE_REMAINING to display outstanding amounts for
current and overdue debit items. ACTUAL_DATE_CLOSED gives the date on which
you applied a payment or credit to an open transaction that set
AMOUNT_DUE_REMAINING to 0 for that transaction. Oracle Receivables uses
ACTUAL_DATE_CLOSED to determine which transactions to include when you print
statements. The primary key for this table is PAYMENT_SCHEDULE_ID, which
identifies the transaction that created the row.
AR_RECEIVABLES_TRX_ALL
This table links accounting information with your Receivables Activities. Possible types
of activities include Adjustment, Miscellaneous Cash, and Finance Charges. If your type
is Miscellaneous Cash, you can associate either a distribution set or a standard accounting
flexfield to your Receivables Activity. Oracle Receivables uses one row for each activity.
You use your receivables activities to speed receipt entry and generate finance charges.
The other types of activities that were valid in release 9 and no longer valid in Release 10
were converted (as part of the upgrade) such that the actual accounting flexfield
CODE_COMBINATION_ID is stored in the table instead of the
RECEIVABLES_TRX_ID. In Release 9, all of these references were in
AR_BATCH_SOURCES; they are now in
AR_RECEIPT_METHOD_ACCOUNTS_ALL. The primary key for this table is
RECEIVABLES_TRX_ID.
AR_RECEIVABLE_APPLICATIONS_ALL
This table stores all accounting entries for your cash and credit memo applications. Each
row includes the amount applied, status, and accounting flexfield information. Possible
statuses of your applications include APP, UNAPP, ACC, and UNID. You use this
information to determine the applications of your payments or credit memos.
CONFIRMED_FLAG is a denormalization from AR_CASH_RECEIPTS_ALL.If the
cash receipt is not confirmed, the applications of that receipt are not reflected in the
payment schedule of the transaction it is applied against. There are two kinds of
applications: CASH and CM (for credit memo applications). This is stored in the column
APPLICATION_TYPE.
CASH applications represent applications of a cash receipt. When a cash receipt is

initially created, a row is created in this table that has a status of UNAPP for the amount
of the cash receipt. Each subsequent application creates two rows – one with a status of
APP for the amount being applied to the invoice and one with status UNAPP for the
negative of the amount being applied. Ifyou reverse a cash application, a row with status
APP with the inverse amount of the original application (i.e. the negative of the original
application amount) is created. The corresponding UNAPP rows is alsocreated which will
have a positive amount (the same amount as the application being reversed). For
example: UNAPP 100 creation of a$100 cash receipt APP 60 application of $60 of this
cash receipt UNAPP –60 this row takes away (debits) unapplied APP –60 reversal of the
$60 application UNAPP 60 this rows puts back(credits) unapplied The sum of the
AMOUNT_APPLIED column for CASH applications should always equal the amount of
the cash receipt. CM applications, on the other hand, do not have rows of status UNAPP.
They only use rows with a status of APP. CASH_RECEIPT_ID stores the cash receipt
identifier of the receipt you entered. Oracle Receivables concurrently creates a record of
this receipt in the AR_CASH_RECEIPTS_ALL table.
This column is null for a credit memo application. CODE_COMBINATION_ID stores

valid Accounting Flexfield segment value combinations that will be credited in the
General Ledger when this application is posted. A negative value in
AMOUNT_APPLIED becomes a debit. The STATUS of a receivable application
determines which flexfield account Oracle Receivables uses. For example, if you enter a
cash receipt of $500 as Unidentified, Oracle Receivables creates a record in
theAR_RECEIVABLE_APPLICATIONS_ALL table with AMOUNT_APPLIED = 500
and STATUS = ’UNID’. Oracle Receivables uses the foreign key
CODE_COMBINATION_ID to associate this payment with the Unidentified flexfield
account. CUSTOMER_TRX_ID, CASH_RECEIPT_ID, and
PAYMENT_SCHEDULE_ID identify the transaction that you are actually applying.
APPLIED_CUSTOMER_TRX_ID and APPLIED_PAYMENT_SCHEDULE_ID identify
the invoice or credit memo that receives the application. For example, if you apply a
receipt against an invoice, Oracle Receivables creates a record in the
AR_RECEIVABLE_APPLICATIONS_ALL table. The CASH_RECEIPT_ID and the
PAYMENT_SCHEDULE_ID of this record identify the receipt you are applying.
APPLIED_PAYMENT_SCHEDULE_ID and APPLIED_CUSTOMER_TRX_ID for this
record belong to the invoice that is receiving the application. If you apply a credit memo
against the invoice, Oracle Receivables creates a record in the
AR_RECEIVABLE_APPLICATIONS_ALL table that has theCUSTOMER_TRX_ID
and the PAYMENT_SCHEDULE_ID of the credit memo you are applying. The
APPLIED_PAYMENT_SCHEDULE_ID and the APPLIED_CUSTOMER_TRX_ID of
this record belong to the invoice that is receiving the application. If you combine an on
account credit and a receipt, Oracle Receivables creates a record in the
AR_RECEIVABLE_APPLICATIONS_ALL table.
The PAYMENT_SCHEDULE_ID and the CASH_RECEIPT_ID of this record identify

the receipt. The APPLIED_PAYMENT_SCHEDULE_ID and the
APPLIED_CUSTOMER_TRX_ID of this record identify the on account credit that you
are combining with the receipt. The primary key for this table is
RECEIVABLE_APPLICATION_ID, which uniquely identifies the transaction that
created the row.
Hello friends, in AR (Account receivables ) or TCA ( Trading community

architecture ) , we usually comes across two common terms, party and
customer. though both link each other still there are always confusion, here i
trying to sort out the difference, hope this will be helpful
Points differentiates a Party and Customer which is as follows
Party
a) Prospective Customer and more relevant for CRM Purposes

b) No Business Transactions involved (Sales Order, Sales Invoice, Debit Memo, Credit
Memo, Receipt etc.,)
c) A Party does not have account but have Sites
d) A Party can exist without Customer Record
e) A Party Record will not have record in following tables
HZ_CUST_ACCOUNTS
HZ_CUST_ACCT_SITES_ALL
HZ_CUST_SITE_USES_ALL
HZ_CUST_ACCOUNT_ROLES
HZ_CUST_ACCT_RELATE_ALL
Customer
a) A Customer which is used both in CRM as well as in OM,Financials or any other
module.
Example (A Sales Order in OM or Invoice in Receivables cannot be created without
creating a Customer record for the Party).
b) A Business Transaction like a Sales Order, Invoice,Debit Memo,Credit Memo,Receipt
can be created.
c) A Customer will have account and as well as Sites.
d) A Party record is must to create a Customer Record linked through party_id.
e) A Customer Record will have records in following tables
HZ_CUST_ACCOUNTS
HZ_CUST_ACCT_SITES_ALL
HZ_CUST_SITE_USES_ALL
HZ_CUST_ACCOUNT_ROLES
HZ_CUST_ACCT_RELATE_ALL
with reference to party_id column.
Run the Party and Customer Diagnostic Report to know more about the table
information.
Important Note:
————————
For Example Party ‘A’ has ‘B’ and ‘C’ two Customer accounts and party ‘X’ has ‘Y’ and
‘Z’ two customer accounts. If you want to merge Customer Accounts ‘B’ and ‘C’ with ‘Y’
and ‘Z’, then first we need to perform Party merge and then perform the customer merge.
It operates on the simple logic, First Parent records need to be merged before merging the
child records

Answer:: Question: What Are The Key Benefits of Forms Personalization Over Custom - PLL?

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

Answer:: Question: What Are The Key Benefits of Forms Personalization Over Custom - PLL?

Uploaded by

Copyright:

Available Formats

Question: What are the key benefits of forms personalization over custom.pll?

Question: How can you import invoices into Oracle Receivables?

You can either use AutoInvoice by populating tables RA_INTERFACE_LINES_ALL,

Question: In OA Framework, once your application has been extended by substitutions, is

SELECT bug_number ,to_char(creation_date, ‘DD-MON-YYYY HH24:MI:SS’) dated

WHERE bug_number = TRIM(’&bug_number’) ;

Question: How to make concurrent program end with warning?

a) Define a request group, lets say with name “XX_PO_PROGS”

b) Add these two concurrent programs to the request group “XX_PO_PROGS”

c) Define a new Form Function that is attached to Form “Run Reports”

d) In the parameter field of Form Function screen, enter

12. What is an Invoice?

Also, Invoice is an information sheet which a company sends to the buyer

13. Can you disable budgetary control for a set of books?

–Run the Period Map Maintenance concurrent request, it must complete

15. Why don’t my Detail budgets roll up to my Master budget?

16. I was able to post a budget journal to a closed period, why?

17. How many ‘Current’ budgets can you have?

Funding budget is a budget against which accounting transactions are checked

19. Why is my budget requiring budget journals?

21. If I delete my budget org, will the budget amounts be deleted?

22. Can I update/adjust an existing account range in my budget

23 How many times can a budget be purged?

24. Why is there no value in the REQUEST_ID column of

26. I was able to post a budget journal to a closed period, why?

To include budgets (encumbrances or currencies) in a FSG report, your report

Questions: How many types of Invoices in Oracle Account Payables

Question :How many key flexfields are there in Payables?

Answer: 0 (No key flexfields in PO,AP)

Question: Name few Account Payables Tables

Question: What is 2 way , 3 way and 4 way matching?

What is a Hold? Explain the types of Hold

Flow of Accounting Information:

Should this occur, then

1. Re-enable the segment or combination;

4. Re-disable the segment or combination.

Period Close Procedures:

+ New Invoices ——-Transaction Register

+ Debit Memos ——- Transaction Register

- Credit Memos —— Transaction Register

- Receipts Applied —- Unapplied Receipts Register

+/- Adjustments ——Adjustment Register

- Items Not Aged —– Invoice Exceptions Report

New Aging Balance — Aged Trial Balance – 7 Buckets by Account

or Unidentified (Receipt Class)

CR : AR (from the invoice)

DR : AR (from the invoice)

CR : Unapplied (Receipt Class)

DR : Unapplied (Receipt Class)

: AR (from the invoice)

CR : Cash (Receipt Class)

DR : AR (Transaction Type – may override)

CR : Cash (Receipt Class)

In the Category of Adjustment:DR : Chargeback Adjustment (Receivables Activity)

CR : AR (from the invoice)

DR : AR (from the invoice)

CR : Unapplied (Receipt Class)

DR : Unapplied (Receipt Class)

: AR (from the invoice)

: Unapplied (Receipt Class)

DR : AR (Transaction Type – may override)

CR : Cash (Receipt Class)

In the Category of Adjustment:DR : Chargeback Adjustment (Receivables Activity)