Oracle Application – General Interview (Technical – Functional Questions)


Oracle Applications / Financials – General Questions for interview or to increase overall awareness on some of the concepts you already aware and worked upon. this is terms as refreshing some of those.

Oracle Application – General Interview (Technical – Functional Questions)

What are different period types?
You use accounting period types to define your accounting calendar. Different Accounting Periods are-
  • General Ledger Periods (attached to Set of Books),
  • Purchasing Periods (Operating Unit Specific),
  • Cost Periods (Inventory Organization Specific),
  • AP Periods, and
  • AR Periods

If it is accounting period types, you can define your own period types to use in addition to the General Ledger standard period types Month, Quarter and Year. You use these period types when you define the accounting calendar for your organization. However the year type should be either Calendar or Fiscal. We have different Period types-

1) 13 Month (13 Month Calendar with An Adjusting Period).

2) Annual.

3) Monthly.

4) Quarterly.

5) Semi Monthly.

6) Weekly.

What types of invoices are there in AP and AR?

Types of Invoices are:

Standard
Credit Memo
Debit Memo
Expenses Report
Prepayment
Mixed

AWT (Automatic Withholding Tax Invoice)

Interest Invoice

PO Default

Quick Match

Mixed

Recurring Invoice

Arrears Invoice

Advance Invoice

Guarantee

Charge Back

Deposit

What is the difference between cross-validation rules and security-rules?

Cross validation rules prevent all the responsibilities/users entering invalid account combinations. Security rules are attached to specific responsibilities to prevent using few of the segment values for a segment. Cross Validation Rule: Rules that define valid combinations of segment values a user can enter in an account. Cross-validation rules restrict users from entering invalid combinations of account segment values. Security Rule: It determines the accounting transaction user can view at different levels of hierarchy, such as at Site Level –>Application Level –> Responsibility Level –> User level. Cross Validation Rule applies across the chart of account where Security Rule is applicable at Responsibility Level or User Level. Cross Validation Rules are meant for defining the set of combinations that are excluded from the global set whereas Security Rules are to restrict Users/Responsibilities. Cross-Validation Rules are to control the certain code combinations. Security Rules are to control the certain segment values.

How many ways can you enter a journal in GL?

1. Manual entry 2. Subledger Entry 3. Spreadsheet Entry 4. Recurring Entry 5. Mass Allocation

What is a recurring invoice?

Recurring Invoice is a type of invoice which occurs at definite intervals of time. The best example for a recurring invoice is Rent paid to the Owner.

What are the general setup steps for AP, AR, and GL?

For GL:

1. Define Chart of Accounts2. Define Calendar
3. Define Currency
4. Create Set of Books
For AP:
1. Define Suppliers (Creditors)

2. Invoice

3. Look up codes

4. Selection of Set of Books

5. Payment Terms

6. Financial & Payable Options

7. Define Banks

For AR:

1. Flexifield

2. System Options

3. Payment Terms

4. Open period

5. Auto Accounting

6. Transaction Type

7. Transaction Source

How do we integrate AP or AR to GL ?

There is a program in payables to transfer AP to GL is “payables transfer to general ledger” GL is like AR->GL<-AP, AR and AP both transfer the data in GL. AR Contains all Invoices/Receipts /CM/DM and same way AP also have AP Vouchers. Yes, there is a clear Integration of AP/AR with GL.

The integration is like this: all the accounting created in subledgers (AP/AR) are transferred to Gl. The journal created from AP/AR are clearly identified in GL according to their batch names and journal names.
What is the difference between GL date and GL posted date in GL ?
GL date is the date used to determine the correct accounting period for your transactions where as the GL posting date is the date when the journal entry is posted the GL. GL date is the date used to determine the correct accounting period for your transactions where as the GL posting date is the date when the journal entry is posted the GL, also Called Transaction Date & Posted Date.

In GL there is no org id. So how can we differentiate the data different operating units when no other modules are given ?

HR data is at business group level. GL Data is differentiated based on set of books id. AP and AR data is mostly at operating unit level. Inventory, BOM, WIP data is at inventory organization level. In the gl_sets_of_books we have the set_of_books_id column. This column is enough to differentiate between one operating unit with the other. If you see the multiorg structure of Oracle Apps modules, we’ll see that GL is setup at set of books level. Now you generally won’t get data at OU level. OU data sums up at a higher SOB level. Please follow the below structure if you want more clarification top->bottom HR org->SOB->OU->inventory org

At what stage, the subledger data is posted to GL?

When Transactions are completed in subledgers data may be posted to GL Basically after entering the transactions, report will be taken to verify the transactions. In case, if approval is needed, it is approved after verifying the transactions. Once you are sure that the transactions are correct, the same can be posted to GL. Once it is posted, most of the information for the posted transaction can not be modified in the subledger. In case of any wrong entry, you need to follow the reversal procedure. Practically, the verification of transactions are done only during the initial stages after implementation. Once the system becomes stable, it is not followed strictly. Note: Make sure that GL period is open for the transaction GL date. Close all the periods in subledger after you reconciled all your transactions. Once you close the period, sweep program will run and all the un-posted and future entries will be transferred to next open period. Once this is done run the GL Transfer program and Journal import programs to complete the transaction transfer process. Once this is done you will find un-posted journal entries in GL you can post the same or reverse the same if you find something is missing. GL periods should also been opened and the GL period should be closed at the last.

Why cant interest rates are set uniquely supplier wise in payables module, whereas interest rate is applied to all suppliers the same rate?

Terms and conditions differ with each supplier.

What is FSG and its use?

Financial Statement Generator is a powerful report building tool for Oracle GL. FSG is used by the management for the decision making in the financial sector of the firm or an enterprise.

Uses of FSG :1. Generate financial reports such as income statements and balance based upon the data in your GL.
Note: If you have average balance processing enabled in your set of books, you can report on functional, foreign–entered, or translated average balances.
2. Define your reports with reusable report objects, making it easy to create new reports from the components of reports you’ve already defined. 3. Design custom financial reports to meet specific business needs.
4. Print as many reports as you need simultaneously.
5. Print the same report for multiple companies, cost centers, departments in the same report request.

6. Schedule reports to run automatically.

7. Produce ad-hoc reports whenever you need them.

8. Print reports to tab-delimited files for easy import into client-based spreadsheet programs. In addition, you can use the Report Wizard feature of Applications Desktop Integrator to design and submit your financial reports, as well as view the results, directly from a spreadsheet. 9. Define segment value security rules to restrict financial information contained in FSG report output generated by specific users and responsibilities. Note: To apply segment value security rules, the profile option FSG: Enforce Segment Value Security must be enabled

Explain ADI and its features?

ADI means application desktop integrator. It is a excel file which allows you to transfer the data pertaining to General Ledger, Fixed Assets and Budget to oracle apps and allows to run a request. ADI functionality provides an alternative to users who prefer to load information directly from Microsoft Excel rather than using the Oracle user interface. It should read Oracle Interface Programs (batch jobs) rather than Oracle User Interfaces. Broadly following are the feature / elements of ADI

1. Journal Wizard

2. Budget Wizard

3. Report Wizard.

4. Account Hierarchy Editor.

5. Analysis Wizard.

6. Request Center

ADI allows users take advantage of many of the data-entry shortcuts of a spreadsheet, such as copying and pasting cells, dragging and dropping ranges of cells and using formulas to calculate journal line amounts. ADI validates the data entered against the accounts, security rules and reference information that are defined in the General Ledger (GL).

What is EDI and its functions?

EDI – Electronic Data Interchange, to send the data to another server/destination via EDI server.E-Commerce Gate Way is the one of the Module in Oracle Apps. EDI (Electronic Data Interchange) is way of exchanging the Business documents like Sales Order, Invoice, PO etc., between two business entities in agreed standard format like ASCII X12 format. In oracle application, business documents may be referred as 850POI (purchase order Inbound), 810INO (Invoice Outbound) etc.. There are several third party sources are available which may be use in mapping of several documents from Oracle Format to X12 and vice versa. Some of them like Sterling Commerce, Klein Schmidt…. EDI is a toll where in whenever the customer is sending the PO it gets saved in this toll, again when the supplier after supplying the material will send an invoice through EDI, wherein the EDI of the customer will match the PO with the invoice and the invoice will get processed automatically, in case if it is not matching it will be in the error sheet

Shivmohan Purohit

Advertisements

Oracle Receivables Accounting – Overview


Accounting For Oracle Receivables

 

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)

CR : Cash (Receipt Class)

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 :

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)

CR : Cash (Receipt Class)

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 :

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:

DR : Unearned Revenue (AutoAccounting) 1000

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)

CR : AR (from the invoice)

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:

: Unapplied (Receipt Class)

: Discount (Receipt Class)

CR : Unapplied (Receipt Class)

: AR (from the invoice)

 

 

 

When you leave a receipt as unapplied:

CR : Unapplied (Receipt Class)

 

 

 

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.
DR : Unapplied (Receipt Class)
On-Account (Receipt Class)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)

CR : Cash (Receipt Class)

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 :

 

For unidentified receipts:

CR : Unidentified (Receipt Class)

 

 

 

When you identify a receipt is as a pre-payment or deposit:

CR : On-Account (Receipt Class)

 

 

 

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.
DR : Unapplied (Receipt Class)
On-Account (Receipt Class)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)

CR : Cash (Receipt Class)

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 :

 

For unidentified receipts:

CR : Unidentified (Receipt Class)

 

 

 

: AR (from the invoice)

 

 

 

 

 

 

 

 
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)

: Unapplied (Receipt Class)

 

 

 

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

DR : AR (from the invoice)

CR : Finance Charges (Receivables Activity – may override)

Reduce the freight amount:
DR : Freight (Receivables Activity – may override)
CR : AR (from the invoice)
 

 

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)   

 

 

CR : AR (from the invoice)

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:

: Unapplied (Receipt Class at the receipt rate)

CR : AR (from the invoice at the invoice rate)

: Unapplied (Receipt Class at the receipt 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
DR : Unearned Revenue (AutoAccounting) 12000

CR : Revenue (AutoAccounting – may override) 1000

b) For each of the next 11 periods:

DR : Unearned Revenue (AutoAccounting) 1000

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)

CR : AR (from the invoice)

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:

: Unapplied (Receipt Class)

: Discount (Receipt Class)

CR : Unapplied (Receipt Class)

: AR (from the invoice)

 

 

 

When you leave a receipt as unapplied:

CR : Unapplied (Receipt Class)

 

 

 

When you identify a receipt is as a pre-payment or deposit:

CR : On-Account (Receipt Class)

 

 

 

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.
DR : Unapplied (Receipt Class)
On-Account (Receipt Class)or Unidentified (Receipt Class)

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)

CR : Cash (Receipt Class)

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 :

 

For unidentified receipts:

CR : 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)

CR : Cash (Receipt Class)

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 :

: AR (from the invoice)

Data flow for Order-to-Cash cycle


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
    • 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
  • wsh_delivery_assignments
  • wsh_delivery_details
  • 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
  • wsh_delivery_details
  • wsh_delivery_assignments
  • MTL_ONHAND_QUANTITIES
  • MTL_SERIAL_NUMBERS_TEMP
  • MTL_SERIAL_NUMBERS

* 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_delivery_details
  • WSH_SERIAL_NUMBERS
  • mtl_transaction_interface
  • mtl_material_TRANSACTIONS
  • mtl_transaction_accounts
  • mtl_demand, MTL_reservations
  • MTL_ONHAND_QUANTITIES
  • MTL_SERIAL_NUMBERS_TEMP
  • MTL_SERIAL_NUMBERS

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

 You will get the details of column values getting updated at different stages and table joins information at http://functionalguy.blogspot.com/2008/05/data-flow-for-order-to-cash-cycle.html

devendra gulve — Expert’s page – click here

special Thanks TO dEVENDRA gULVE ( http://functionalguy.blogspot.com/2008/05/data-flow-for-order-to-cash-cycle.html )

Thanks – Shivmohan Purohit

Oracle Receivables – FAQ , Interview Questions ( Functional & Technical)


 

Oracle Receivables – FAQ , Interview Questions ( Functional & Technical) 

Hello Friends, As part of putting Oracle Application Interview Questions for various modules, here i am putting Receivables , most of them are quite functional and link with Oracle Receivables features, still it is good to learn and know for a technical developer to get overall understanding. do share your feedback n thoughts. 

What is MRC and what is its use?
The Multi Reporting Currency Feature allows you to report and maintain records at the transaction level in more than one functional currency. You can do by defining one or more set of books in addition to primary set of books.
 

 

 

Accointing for invoice in advance
a) Receivable A/c …………………Dr.
To Unearned revenue a/c

(when we raise the invoice with invoicing rule as advance)

b) Unearned Revenue A/c ………….. Dr.
To Revenue A/c
(when we receive the payment, the number of journal entry (b) is depend upon the accounting rules which can be fixed or variable)

Accounting for invoice in arrear

a) Unbilled receivable a/c ………………..Dr.

To Revenue a/c

(when we receive the payment of unbilled invoice, the number of journal entry (a) is depend upon the accounting rules which can be fixed or variable))

b) Receivable a/c …………………….Dr.
To Unbilled receivable a/c
(when we raise the invoice, with invoicing rule arrear)

 

What is the use of Transaction Flexfield in Autoinvoice ?
Transaction Flexfield actually identifies the the uniqueness among the Multiple lines of a single Invoice
 

 

What are value sets?
Value sets are the defined as list of possible values for a specific purpose. These are assigned to flexfields. These are the only possible values to be choosen from. This eliminates the data entry errors.
Value set is a set of possible values.

There are 8 value set types:

1.Dependent

2.Independent

3.Table

4. None

5.Pair

6.Translatable Dependent

7.Translatable Independent

8. Special

Describe the main tables involved in AR, and what is the data stored in them?
RA_BATCHES_ALL — Information about Transaction BATCHES RA_CUSTOMER_TRX_ALL — Header information about Transaction
RA_CUSTOMER_TRX_LINES_ALL — Lines information about Transaction

RA_CUST_TRX_LINE_GL_DIST_ALL – Distribution information about Transaction

RA_CUST_TRX_LINE_SALESREPS_ALL — Sales representative of Transaction Information

AR_PAYMENT_SCHDULES_ALL – Information about Payment Schedules

AR_APPLICATION_PAYABLES_ALL

RA_INTERFACE_ERRORS – Errors in AutoInvoice Interface Data

RA_INTERFACE_LINES_ALL – Use this table to enter Header and Lines information in AutoInvoice Interface program

RA_INTERFACE_DISTRIBUTIONS_ALL – Distribution Table in AutoInvoice Interface program

RA_INTERFACE_SALESCREDITS_ALL – Sales Credits information in AutoInvoice Interface

 

 

What do you mean by HZ_ in customer tables?
HZ stands for Human Zone(HZ_). Anytihing which is related to the human like Customer profiles, their accounts, locations, relationships are stored in these tables only. From release 11i TCA came into picture in Accounts Recievable module, where oracle has grouped all the customer information at one place. Most important tables in TCA are-
HZ_PARTIES,

HZ_CUST_ACCOUNTS_ALL,

HZ_CUST_ACCT_SITES_ALL,

HZ_CUST_SITE_USES_ALL,

HZ_LOCATIONS,

HZ_PARTY_SITES,

HZ_PARTY_SITE_USES,

HZ_CONTACT_POINTS. few to name.

What is the difference between _all, _tl, _vl, _v tables in Oracle Apps ? Also name various other table suffix.
_ALL : Table holds all the information about different operating units. Multi-Org environment. You can also set the client_info to specific operating unit to see the data specific to that operating unit only.
_TL are tables corresponding to another table with the same name minus the _TL. These tables provide multiple language support. For each item in the table without _TL there can be many rows in the _TL table, but all with different values in the LANGUAGE column.

_B these are the BASE tables. They are very important and the data is stored in the table with all validations. It is supposed that these table will always contain the perfect format data. If anything happens to the BASE table data, then it is a data corruption issue.

_F these are date tracked tables, which occur in HR and Payroll. For these there are two date columns EFFECTIVE_START_DATE and EFFECTIVE_END_DATE which together with the PK identifies a row uniquely. The date intervals cannot overlap. Many think they are Secured data. Guess someone from Oracle confirms.

_V tables are the views created on base tables _VL are views for multi language tables which combines the row of the base table with the corresponding row of the _TL table where the LANGUAGE = USERENV(’LANG’).

_S are sequences, used for finding new values for the primary key of a table.

_A are Audit Shadow Tables

_AVN and _ACN are Audit Shadow Views (when data was changed, and with what values)

How many Flex fields are there in AR and what are they?

Required Key Flex fields:
1. Territory Flex field
2. Sales Tax Location flex field

Optional Key Flex fields:

1. Transaction flex field (requied only if Auto Invoicing is enabled)

2. System Items Flex field (If Inventory or OM is installed this should be defined there. other wise, it should be set up in AR).

 

 

 

Batch sources control the standard transaction type assigned to a transaction and determine whether Receivables automatically numbers your transactions and transaction batches. You can define two types of transaction batch sources-Manual and Imported

 

What is the importance of Batch Source set up in AR ?

 

 

Happy Go Daddy Customer!
 
 
 

 

 

 

Explain Accounting for invoice in Advance and Arrears.

 

 

How is the balance of an invoice derived ?