AR

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.
A part of AR ( Account Receivables ) Interview Questions – Technical & Functional. This is next
part. do share your feedback and thoughts
Conversion is a process by which we transfer legacy data from temporary tables to base tables.
Interfaces also does the same but is a daily process and most of the interfaces are automated by
scheduling. Example:AutoInvoice. Conversition is on time process this is before instlation, and
interface every time process we can run any time.Conversion is a process by which we transfer
legacy data from temporary tables to base tables. Interfaces also does the same but is a daily
process and most of the interfaces are automated by scheduling. Example:AutoInvoice.
Conversition is on time process this is before instlation, and interface every time process we can
run any time.
How many reporting currencies can be attached to Primary Set of Books?
We can have a total of 8 SOB’s (including the Primary SOB). Therefore, we can have 7
Reporting SOB.
What are Different types of transactions in AR?
There are 7 type of transactions in AR-
Invoice,
Debitmemo,
Creditmemo,
Chargeback,
Deposits,
Guarenty, and
Bills Recivable.
What is the use of lockboxes?

AutoLockbox (or Lockbox) is a service that commercial banks offer corporate customers to
enable them to outsource their accounts receivable payment processing. An AutoLockbox
operation can process millions of transactions a month. AutoLockbox eliminates manual data
entry by automatically processing receipts that are sent directly to your bank. You specify how
you want this information transmitted and Receivables ensures that the data is valid before
creating QuickCash receipt batches.
Steps for lock box are :
1. The first step involves reading and formatting data from your bank file into AutoLockbox
tables.
2. The second step involves submitting the validation program which checks data in the
AutoLockbox tables for compatibility with Receivables.
3. Once data is validated, it is transferred into QuickCash tables. At this point, you can optionally
query your receipts in the QuickCash window and change how they will be applied before
submitting the final step,
4. Post QuickCash. Submitting Post QuickCash updates your customer’s balances.
What are the interface tables used for ar invoices, customers, receipts for conversion
process?
Customer interface tables:
Ra_customer_interface
ra_contant_phones_interface
ra_customer_banks_interface
ra_customer_profiles_interface
ra_cust_pay_method_interface
Invoice interface tables:
ra_interface_lines_all
ra_interface_sales_credits
ra_interface_distributions
Following are the Validation for Autoinvoice:
1- AR Transaction Type Validation : Check if the Transaction type provided in data file is
defined in AR transaction types(RA_CUST_TRX_TYPES_ALL)
2- Transaction Batch Source Validation: Check if the source provided in data file is defined in
AR transaction Batch source (RA_BATCH_SOURCES_ALL).
3- Invoice Currency Validation: Check if the currency provided in data file is defined in AR
Currency (FND_CURRENCIES).
4- Customer Validation: Check if the Bill to Customer Number, Ship to Customer Number, Bill
to Custom Location, Ship to Customer Location provided in the data file is defined in AR
Customer(ra_customers).
5- Primary Sales Representative Validation: Sales representative number to be hardcode to “-3”

for “No Sales Credit.”
6- Term Name : Check if the Term name provided in the data file is defined in Payment terms
(RA_TERMS)
7- Validate Sales Credit Type : Sales Credit to hardcode to “Quota Sales Credit”
8- Inventory Item Validation: Check if the Item provided in data file is defined in Inventory
Items (MTL_SYSTEM_ITEMS).
9- Unit of Measurement validation: Check if the UOM provided is defined in

MTL_UNITS_OF_MEASURE Table
10- Invoice Tax Code Validation : Check if the Tax Code provided in data file is defined in
AR_VAT_TAX_ALL_B Table.
11- Invoice GL Date Validation : Check if the GL Data of provided invoices is in open
period.Used ARP_UTIL.IS_GL_DATE_VALID API to validate.
Following are the base tableshz_parties
hz_cust_accounts
hz_cust_acct_sites_all
hz_cust_sit_use_all
hz_party_sites
hz_locations
hz_party_site_uses
hz_customer_profiles
hz_organization_profiles
hz_person_profiles
What is Auto Invoicing? Explain?

Auto Invoicing is a process of Importing Invoice related information from External / Internal
Sources.External will be your business Legacy Systems like Main Frame / AS400 or Non Oracle
ERP systems like SAP / JDE or From Custom Oracle Applications. The data is placed into
Interface tables and from there either from Application or from PL/SQL , you can call Auto
Invoice Concurrent request to validate and transfer data into AR Transaction tables. The data
from these tables can be seen when queries from Transaction Screens. Auto Invoicing is a
process of creating an invoice automatically in AR when a sales order has been shipped and
closed. This process is triggered by a concurrent request ‘AUTO INVOICE MASTER
PROGRAM’. Auto invoicing is used to import the AR invoices direclty into the AR module.
What is AUTO Accounting what are the steps for setting up auto accounting?
Auto Accounting is a mechnism for generating defualt accounting flexfields for revenue ,
receivables, frieght and tax based on the other parameters associated with the invoice you are
entering.. since auto accounting looks at the following tables to get the data so please set/define
the following depending upon your requirement.
1.Salesrep.
2.Transaction Types.
3.Standard Lines.
4.Taxes.
5.Customer bill-to-site
Receivables uses the Auto Accounting rules to determine the GL Accounts that you Enter
manually or import using Auto invoice. Receivables creates the Default accounts for the
Receivable, revenue, Freight, Tax, Unerned revenue, Finance charges, Unbilled receivables,
Bills receivables, and Auto invoice Clearing Accoutns.You need to define these accoutns before
you start entering the transactions in AR. However, you can overide these accounts during the
Transaction Entry in AR.Setup Autoaccounting:AR>Setup>Transactions>AutoAccountingSelect
the Type of the accoutn you wish to define the auto accoutning.In the Segments Block:Choose
the segment for which you wish to assign the Auto accounting.Choose the Table Name : Sales
Rep, Trxn Type, Site, Std Lines.If you wish to use a Default Constant value, then enter the value
in the Constant Field.
What are the standard concurent programs for auto invoice interface and customer
interfaces?
Autoinvoice Import Program — for auto invoice program
Customer Interface Master Conc Program –> for Customer Interface
AR Complete Cycle (hoping that GL is already implemented)Define Transaction SetupsDefine

Receipt and Receipt Application SetupsDefine CustomerCreate an InvoiceCreate a ReceiptApply
Receipt to InvoiceReview Customer balances (Collections). The BASIC process of Receivables
involves the following:
1. Creation of Customer Invoices.
3. Remittance fo the same to the bank.
How do we segregate debit & credit transactions in Receivables and where we will do it?
Basically the debit and credit transaction are classified by the transaction class.
Whether we are defining customer in AR? If it is in AR then how are we placing the order
and how the shipment will be done?
Customers and the associated information is stored in TCA structure, which is shared across All
oracle application modules. If you add a customer in AR, it gets stored TCA underlying tables.
When you want to create an Order in Order Management, the customer LOV displays data from
Record Group that is created on TCA tables.
The basic Oracle ERP data model is the single Data model shared (integrated) by multiple
application. The owner of the creation of customer is the AR schema and is shared by other
application such as OM. These are usually called as shared entities (Supplier,Partners,Items etc)
How To Close Periods In AR?

After raising transactions and receiving the RECEIPT amount, transfer the all TRANSATIONS
and RECEIPTS to the GENERAL LEDGER. And then only close the PERIOD in AR.
Explain about Party and Customer in AR?
Party could be a person or an organization which has no business relation with your entreprise, if
you establish a sales relation with a department in a party then that particular department is your
customer.
AutoInvoice is a program that can be used to import and validate transaction data
from other financial systems from which one can create invoices, debit memos, credit
memos, and on-account credits. It rejects transactions with invalid information to
insure the integrity of the data. This fits well with in Oracle ERP or to integrate with
any third party application.
Top 10 reasons for using Auto Invoice
1. Powerful Interface Tool

2. Supports Oracle & Non-Oracle Systems
3. Import Large Amount of Data
4. Calculate or Import Tax
5. Group Lines & Invoices
6. Online Error Correction
7. Lines Validation
8. Derive GL Date
9 .Import Flex fields
10. Import or Derive Accounting Info
What is inside Auto Invoice

Auto Invoice is a program set consists of 3 main programs. Each program will have
unique nature of work to do and they are called internally except Purge program
whose execution is derived on the setup otherwise ready to execute stand alone.
Master (RAXMTR)
Import (RAXTRX)
Purge (RAXDEL)
1. Auto Invoice Master program RAXMTR

Selects and marks records in the interface tables to be processed based on the
parameters the user entered and then calls the AutoInvoice Import program. Auto
Invoice Master program has no report output.
•Gathers statistics, it means it gathers the stats on interface tables and set the stats on
certain indices on interface tables
•Marks interface records for processing by marking request_id
•Submits multiple workers for Parallel Processing by creating instances for request.
2. Auto Invoice Import Program Validates the selected record and creates transaction
if it passes validation. Any record that fails validation is left in the interface table with
an error code. Depending on the setup, related records may be rejected as well. This
program has an output file called Auto Invoice Execution report, which you can view
by clicking the View Report button in the Requests window. Working of Auto
Invoice, Validates data, Inserts records, Deletes interface data Only when system
option purge set to ‘Y’
3. Auto Invoice Purge Program Deletes records from the interface tables. If you set
the Purge Interface Table system option to No in Define System Option window, Auto
Invoice does not delete processed records from the interface tables after each run,and
we must submit Auto Invoice Purge Program periodically to clean up the interface
tables. This program only deletes transaction lines that have been successfully
imported.
Deletes all rows where interface_status =‘P’
• Ra_interface_lines
• Ra_interface_distributions
• Ra_interface_salescredits
Oracle Receivable’s Auto Invoice program will be used to import and validate
Invoices. A custom feeder program is required to transfer data from the Advantage
extract files and populate the Auto Invoice interface tables
(RA_INTERFACE_LINES_ALL and RA_INTERFACE_DISTRIBUTIONS_ALL).If
there is need to run populate sales credit into
RA_INTERFACE_SALESCREDITS_ALL table. When run, AutoInvoice produces
the AutoInvoice Execution Report and the AutoInvoice Validation Report. Any
entries which failed validation can be reviewed in Oracle Receivables’ AutoInvoice
Interface Exceptions window. Depending on the error, changes may need to be made
in Receivables, the feeder program or the imported records in the interface tables.
How Autoinvoice Execution works

Normally, Auto Invoice can be divided into three major phases, Pre-grouping: here
the validates all of the line level data takes place, Grouping: groups lines based on the
grouping rules and validates header level data, Transfer :validates information that
exists in Receivables tables
What happen when AutoInvoice run?

Once the Auto invoice Program gets called, the following activity takes place is part
of execution process. This can be analyzed by debug options.
Line, accounting, and sales credit information for each line populates 3 interface
tables
Lines are ordered and grouped
Tax is calculated
GL date is determined
GL accounts are assigned using Auto Accounting
Tax, freight, commitments, and credit memos are linked to transaction lines
All transactions are batched
Validated lines are used to create the transaction
How Data is flowing?

Select, insert and update and delete take place on certain tables once it is logged out.
Selects
– RA_INTERFACE_LINES_ALL
– RA_INTERFACE_DISTRIBUTIONS_ALL
– RA_INTERFACE_SALESCREDITS_ALL
Updates/Insert
– RA_INTERFACE_ERRORS_ALL
– RA_CUSTOMER_TRX_ALL
– RA_CUSTOMER_TRX_LINES_ALL
– AR_PAYMENT_SCHEDULES_ALL
– AR_RECEIVABLE_APPLICATIONS_ALL
Inserts
– RA_INTERFACE_ERRORS_ALL
AutoInvoice Exception Handling

Records that fail validation are called ‘Exceptions’. Exceptions stay in Interface
Tables which is RA_INTERFACE_ERRORS_ALL. Errors can be corrected in the
Exception Handling window. Once corrections are made, Auto invoice must be
resubmitted. Records that pass validation get transferred to Receivables tables
AutoInvoice Exception Handling Windows

-Interface Exception window displays exception messages associated with all invalid
records
-Interface Lines window displays records that fail validation, provides an error
message and can be used to correct the errors
-The Line Errors windows displays errors associated with a specific line, and can only
be opened from Interface Lines window
-Interface Exceptions window displays Interface Id, Exception Type, Error Message
and Invalid Value associated to the error
-Data cannot be edited in this window, but error can be viewed and corrected by
clicking the Details button
-Error Message and Column name with invalid data are displayed in the Message
column, and the invalid value that needs to be corrected is displayed in the Invalid
Value column
Flow of Accounting Information:
If you are using Oracle Order Entry (without customizations), no accounting information is
available until you run Auto Invoice. You pass the transactions to Oracle Receivables using the
Receivables Interface. You then run Auto Invoice which creates the actual transactions and uses
Auto Accounting 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 Auto
Accounting and passed as values to Oracle Receivables via the Streamline process, also using
Auto Invoice. Whether you are manually entering your receipts or processing them through Auto
Lockbox, the accounting information is automatically determined by Oracle Receivables when
you create and apply the receipts (not when it is still a “Quick Cash” 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 :
In the Category of Adjustment:DR : Chargeback Adjustment (Receivables Activity)
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)

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)

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)

or Unidentified (Receipt Class)
CR :


Data flow for Order-to-Cash cycle
Hello friends, here we are having one of the contribution from “Devendra Gulve” , very precise
and useful explaination on O2C cycle. hope this be helpful to you.
For more details please visit http://functionalguy.blogspot.com
1. Order Entry
This is first stage, When the order is entered in the system, it creates a record in order headers
and Order Lines table.
 Enter header details: Once you enter details on the order header and save it or move it to
lines, record goes to one table oe_order_headers_all
o No record exists in any other table for this order till now.
 Enter Line details for this order: Enter different item numbers, quantity and other details
in line tab. When the record gets saved, it goes to one table. Order header details will be
linked with line details by order HEADER_ID.
2. Order Booking
This is next stage, when Order is booked then the Flow status changed from Entered to Booked.
At this stage, these below table get affected.
 oe_order_headers_alL
 oe_order_lines_all
 wsh_delivery_details
 wsh_delivery_assignments
*In shipping transaction form order status remains “Ready to Release”.
At the same time, Demand interface program runs in background and insert into inventory tables
mtl_demand.
3. Reservation
This step is required for doing reservations SCHEDULE ORDER PROGRAM runs in the
background and quantities are reserved. Once this program get successfully get completed, the
mtl_demand and mtl_reservations table get updated.
4. Pick Release
Pick Release is the process of putting reservation on on-hand quantity available in the inventory
and pick them for particular sales order.
Pick release can be done from ‘Release Sales Order’ form or ‘Pick release SRS’ program can be
scheduled in background. In both of these cases all lines of the order gets pick released
depending on the Picking rule used. If specific line/s needs to be pick release it can be done from
‘Shipping Transaction form. For this case Pick Release is done from ‘Release Sales Order’ form
with Pick Confirm=NO.
Once pick release is done these are the tables get affected:
 If step 3 is not done then MTL_RESERVATIONS gets updated now.

 wsh_new_deliveries
 MTL_TXN_REQUEST_HEADERS
 MTL_TXN_REQUEST_LINES
 Mtl_material_transactions_temp
 MTL_SERIAL_NUMBERS_TEMP
 MTL_SERIAL_NUMBERS
*In shipping transaction form order status remains “Released to Warehouse” and all the material
still remains in source sub-inventory. We need to do Move Order Transaction for this order. Till
this no material transaction has been posted to MTL_MATERIAL_TRANSACTIONS
5. Pick Confirm/ Move Order Transaction
Items are transferred from source sub-inventory to staging Sub-inventory. Here material
transaction occurs.
Order line status becomes ‘Picked’ on Sales Order and ‘Staged/Pick Confirmed’ on Shipping
Transaction Form.
 MTL_MATERIAL_TRANSACTIONS_TEMP
 oe_order_lines_all
 MTL_MATERIAL_TRANSACTIONS
 mtl_transaction_accounts
 MTL_ONHAND_QUANTITIES
* This step can be eliminated if we set Pick Confirm=YES at the time of Pick Release
6. Ship Confirm
Here ship confirm interface program runs in background. Data removed from
wsh_new_deliveries.
The items on the delivery gets shipped to customer at this stage.

oe_order_lines_all
 WSH_SERIAL_NUMBERS
 mtl_transaction_interface
 mtl_material_TRANSACTIONS
 mtl_transaction_accounts
 mtl_demand, MTL_reservations
 MTL_ONHAND_QUANTITIES
7. Enter Invoice
After shipping the order the order lines gets eligible to get transferred to
RA_INTERFACE_LINES_ALL. Workflow background engine picks those records and post it
to RA_INTERFACE_LINES_ALL. This is also called Receivables interface, that mean
information moved to accounting area for invoicing details. Invoicing workflow activity transfers
shipped item information to Oracle Receivables. At the same time records also goes in the table
RA_INTERFACE_SALESCREDITS_ALL which hold details of sales credit for the particular
order.
ra_interface_lines_all (interface table into which the data is transferred from order management)
Then Auto-invoice program imports data from this table which get affected into this stage are
receivables base table. At the same time records goes in ra_customer_trx_all and
ra_customer_trx_lines_all
8. Complete Line
In this stage order line level table get updated with Flow status and open flag.
oe_order_lines_all
9. Close Order
This is last step of Order Processing. In this stage only oe_order_lines_all table get updated.
These are the table get affected in this step.

oe_order_lines_all
oe_order_HEADERS_all

AR

Uploaded by

Document Information

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

AR

Uploaded by

Copyright:

Available Formats

1- RA_CUSTOMER_TRX_ALL

The PAYMENT_SCHEDULE_ID and the CASH_RECEIPT_ID of this record identify the

How many reporting currencies can be attached to Primary Set of Books?

What are Different types of transactions in AR?

There are 7 type of transactions in AR-

What is the use of lockboxes?

4. Post QuickCash. Submitting Post QuickCash updates your customer’s balances.

Invoice interface tables:

Following are the Validation for Autoinvoice:

5- Primary Sales Representative Validation: Sales representative number to be hardcode to “-3”

9- Unit of Measurement validation: Check if the UOM provided is defined in

What is Auto Invoicing? Explain?

Customer Interface Master Conc Program –> for Customer Interface

AR Complete Cycle (hoping that GL is already implemented)Define Transaction SetupsDefine

How To Close Periods In AR?

Explain about Party and Customer in AR?

Top 10 reasons for using Auto Invoice

1. Powerful Interface Tool

6. Online Error Correction

9 .Import Flex fields

10. Import or Derive Accounting Info

What is inside Auto Invoice

1. Auto Invoice Master program RAXMTR

How Autoinvoice Execution works

What happen when AutoInvoice run?

How Data is flowing?

AutoInvoice Exception Handling

AutoInvoice Exception Handling Windows

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

+ 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

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)

: Unapplied (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)

CR : Cash (Receipt Class)

: Unapplied (Receipt Class)

DR : AR (Transaction Type – may override)

CR : Cash (Receipt Class)

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

- Unearned Revenue (for deferred revenue recognition)

- Unbilled Receivable (for deferred receivables recognition)

- AutoInvoice Clearing (for problems with extended amount)