This section provides a brief description of each Receivables setup step. Some of the operations listed are optional, but you should perform the required steps in the order shown to be sure that your system is set up properly.
Step 1 Define Your Set of Books (Required)
You need to define at least one set of books before you can implement and use Receivables. A set of books includes an accounting calendar, a functional currency, and an Accounting Flexfield structure.
If you previously defined your set of books in the Setting Up Oracle Applications Set of Books section while setting up a different Oracle Applications product, proceed to the next step.
If you have not defined your set of books, see: Defining Sets of Books to complete the following steps:
    • Define your Accounting Flexfield
    • Define your Calendar Period Types
    • Define your Calendar Periods
    • Define your Currencies
    • Define your Accounting Flexfield Combinations (Optional)
    • Define your Set of Books
    • Assign your Set of Books to a Responsibility
    • Define your Daily Conversion Rate Types
    • Define your Daily Rates (Optional)
You specify which set of books your Receivables installation uses in the System Options window.
Additional Information: If you use the Oracle Applications Multiple Organization Support feature, you can use multiple sets of books for one Receivables installation.
Step 2 Decide How to Use the Account Generator (Required)
The Account Generator ensures that Receivables substitutes the correct balancing segment values when you generate finance charges or post exchange rate gains and losses to your general ledger. You need to review the default process that Receivables uses to see if it meets your accounting requirements. You can optionally customize the Account Generator for each set of books that you have defined.
Step 3 Define Your System Items Flexfield Structure (Required)
Proceed to the next step if you previously defined your System Items Flexfield while setting up another Oracle Applications product.
If you have not installed Oracle Inventory or Oracle Order Entry and you want to record and report your item information, you need to define your System Items Flexfield.
All Oracle products that reference items share the System Item Flexfield and support multiple segment implementation. The system provides a seeded System Item Flexfield for you (Code = ‘MSTK’). You must define a structure for this flexfield rather than creating a new flexfield.
Once you have defined your System Item Flexfield structure, you need to specify your Item Flexfield profile options.
Set the OE: Item Flexfield profile option at the site level to specify the System Item Flexfield structure you want to use. Set this to ‘System Items,’ which is the System Item Flexfield structure you have just defined.
Next, set your AR: Item Flexfield Mode profile option to choose your preferred method of entry for this flexfield within Receivables. This default value is concatenated segment entry. Refer to Step 37 for details on how to set up profile options.
Step 4 Define Your Organizations (Required)
Proceed to sub step 3, Specify your Item Validation Organization Profile Option, if you have previously defined your organizations while setting up another Oracle Applications product.
1. Define Organization
You need to define at least one organization to use Receivables. This organization lets you use the inventory forms in Receivables if you do not have Oracle Inventory installed.
2. Define Organization Parameters
You must define the control options and account defaults for your organization before you can define items or perform any transactions. You must assign a unique short code to your organization and use this code to identify the organization with which you want to work.
3. Specify your Item Validation Organization
You need to set the OE: Item Validation Organization profile option to the organization of the Inventory Organization whose item master you want to use.
If you defined your organization in step 1, set the profile option to this organization. Otherwise, select an organization from the list of values.
Refer to Step 37 for details on how to set up profile options.
4. Define Items
Once you have set up your Item Flexfield and chosen your Item Validation Organization, you can optionally define your items in the Items window. Proceed to the next step if you have previously defined your items while setting up another Oracle Applications product.
Step 5 Define Your Territory Flexfield (Optional)
You can use Territory Flexfields for reporting purposes. Receivables provides a default structure for your Territory Flexfield. You can associate Territory Flexfields with salespeople, invoices, commitments, and customer business purposes.
Proceed to the next step if you do not want to define Territory Flexfields.
Step 6 Define Sales Tax Location Flexfield Structure (Required, Default)
Receivables uses the customer shipping address to determine the sales tax rate on transactions for all customers in the country you define in the Systems Option window as your home country. Proceed to the next step if you are not charging your customers tax based on their shipping address.
The seeded Sales Tax Location Flexfield structures are as follows:
    • Country
    • State and City
    • Province and City
    • City
    • Province
    • State, County and City
Proceed to sub-step four if you are planning to use one of the seeded structures, otherwise begin with sub step one.
Attention: If you use a Sales Tax Location Flexfield that contains a segment other than country and wish to set up a flexible address format for your home country, every component in your Sales Tax Location Flexfield structure must also exist in your flexible address style for that country.
Sub-step one through sub-step three briefly describe how you can create a customized Sales Tax Location Flexfield structure if none of the seeded structures meet your taxing requirements. For detailed information on customizing your Sales Tax Location Flexfield
1. Define Value Sets
Receivables provides several value sets which are used with the seeded Sales Tax Location Flexfield structures. You will either use these for your customized structure or create your own.
2. Define Key Flexfield Structure
Query ‘Sales Tax Location Flexfield’ in the Title field of the Key Flexfield region. Receivables provides a six seeded Sales Tax Location Flexfield structures. You need to create a new customized structure if you do not wish to use any of the seeded structures. You should not simply modify a seeded structure.
3. Define Descriptive Flexfield Context
After defining your customized Sales Tax Location Flexfield structure, you need to define customized contexts for the following descriptive flexfields in the Descriptive Flexfield Segments window:
    • Tax Rates Flexfield: This flexfield appears in the Review Sales Tax Rates window.
    • Item Exception Rate Assignment Flexfield: This flexfield pops up in the Tax Rate field of the Item Tax Rate Exceptions window.
    • Item Exception Rate Location Flexfield: This flexfield pops up in the Location field of the Item Tax Rate Exceptions window.
    • Exempt Regions Flexfield: This flexfield pops up in the Location field of the Tax Exemptions window.
    • Override Sales Tax Rates Flexfield: This field pops up in the Override field of the Tax Locations and Rates window.
4. Define Key Flexfield Segment Qualifiers
Verify that the Tax Account and Exemption qualifiers are set at the correct level for your needs. The Tax Account qualifier determines at which level of your location flexfield you will assign tax accounts. The Exemption qualifier determines at which level the Receivables tax engine will create automatic exemptions.
5. Define Tax Locations and Rates
Enter and maintain locations for each segment of your Sales Tax Location Flexfield structure and assign tax rates to each location. Receivables uses Tax locations to validate your customers’ shipping address and to determine the proper tax amount. You can either use the sales Tax Rate Interface program to load locations and tax rates or manually enter them in the Tax Locations and Rates window.
Step 7 Set Up Flexible Address Formats (Optional)
If the standard address format (Country, Address Line 1-4, City, State, Postal Code, Province and County) suits your business needs, you do not need to use the flexible address formats feature.
Alternatively, you can associate address styles with countries to enable you to enter addresses in country specific formats throughout Receivables. This lets you enter addresses in the style most appropriate to the country in which you or your customers conduct business. Receivables also offers the functionality to perform country specific validation upon entry of addresses.
To implement flexible address formats, you need to assign an address style to a country in the Maintain Countries and Territories window.
Receivables provides the following address styles:
    • Japanese
    • Northern European
    • Southern European
    • South American
    • United Kingdom/Asia/Australasia
You can also create your own address styles and validation rules by defining alternative descriptive flexfield structures.
Proceed to the next step if you are planning to use one of the seeded address styles. For detailed information on how to define your own address styles,
Step 8 Maintain Countries and Territories (Optional)
You can view all countries and territories within your system in the Maintain Countries and Territories window.
Use the address style field to assign address styles to countries if you wish to use the Flexible Address Formats feature.
You can identify which countries are part of the European Union (EU) by entering a VAT Member State Code against these countries. The Receivables European Sales Listing report uses this information to produce a listing of all sales to customers in European Community member states other than your own.
Step 9 Define Your Transaction Flexfield Structure (Optional)
Proceed to the next step if you are not using AutoInvoice.
If you are using AutoInvoice, you need to define your Transaction Flexfields to uniquely identify imported transactions. Because Transaction Flexfields are unique, you can also use them to link and reference other transaction lines.
If you are using AutoInvoice, the Line and Invoice Transaction Flexfields are mandatory. When you define your Invoice Transaction Flexfield, you must use the same structure that you used for your Line Transaction Flexfield, but only include those segments that refer to header-level information.
The Link-to and Reference Transaction Flexfields refer to the structure you define for your Invoice Transaction Flexfield, but can be optionally defined if you want to create a customized form that displays your Link-to and Reference Transaction Flexfield.
Define the structure, segments, and values for your Transaction Flexfield in the Descriptive Flexfield Segments window. Execute a query on the Title field. You can define your Line Transaction Flexfield, Link-to Transaction Flexfield, Reference Transaction Flexfield and Invoice Transaction Flexfield here.
Suggestion: If you want to query your Transaction Flexfield, you may want to update the Transaction Flexfield information for previously entered transactions.
We advise that you create indexes on your Transaction Flexfield columns if you want to query Transaction Flexfield information in your invoice headers and lines. Additionally, without indexes the validation portions of the AutoInvoice program can be slow. For complete information about defining Transaction Flexfield indexes,
Step 10 Define Your AutoCash Rule Sets (Optional)
If you are using AutoCash, you need to define your AutoCash rule set before defining your system parameters or customer profiles classes. AutoCash rules determine the sequence of application methods Receivables uses when automatically applying receipts to open debit and credit items.
Step 11 Define Your QuickCodes (Optional)
Receivables provides several default QuickCodes. These are used throughout Receivables to provide validated default values and list of values choices. You can add or update these to customize your list of values and speed data entry. For example, you can define additional freight carriers that are used by your business.
Below is a list of all user updatable QuickCodes types:
    • Account Status
    • Address Categories
    • Adjustment Reason
    • Approval Type
    • Business Purposes for a Customer Address
    • Canadian Provinces
    • Collector Actions
    • Collector Follow Up Action
    • Credit Memo Reason
    • Credit Rating for Customers
    • Customer Class
    • Customer Credit Risk
    • Customer Relationship Type
    • Customer Response Reason
    • Define Freight Carriers
    • Demand Class
    • FOB (free on board)
    • Invoice Reason
    • Job Titles for Customer Contact
    • Mandatory Field Prompt for Message Dictionary
    • Possible Outcomes of a Customer Call
    • Reverse Payment Reason
    • Special Instructions
    • Tax Exemption Reason
    • Tax Rate Exception Reason
    • Tax Types
    • Titles For Contact Persons at Customer Sites
    • Type of Data to Include in a Specific Bucket
    • Types of Communication Used in Contacting Customers
    • Types of Documentation to Send to Customers with this Relationship to Primary Customer
    • Types of Messages
    • Types of Standard text usage
Step 12 Define Your AutoInvoice Line Ordering Rules (Optional)
If you are using AutoInvoice, you need to specify how you want to order and number your transaction lines after they have been grouped into invoices, debit memos, and credit memos. Receivables provides many attributes that you can use to define your line ordering rules.
Step 13 Define Your AutoInvoice Grouping Rules (Optional)
If you are using AutoInvoice, you need to specify how you want to group transaction lines. In order for transaction lines to be part of one transaction, certain attributes must be identical. Receivables provides many attributes that you can use to define your grouping rules.
Step 14 Define Your System Options (Required)
Define your accounting, discount, tax, and invoice system options to control how Receivables works. For example, you can determine whether to charge your customers Sales Tax or Value Added Tax (VAT). If you choose Sales Tax, Receivables supports location based Sales Tax for your home country only. You also define your default (i.e. home) country in the System Options window.
You can also specify a default Application Rule Set in the System Options window. An Application Rule Set determines how Receivables reduces the balance due for debit items and their associated charges when you apply payments in the Applications window or by using Post QuickCash. Receivables only uses this rule set if none is assigned to the debit item’s transaction type.
You can update the Default Country in this window at install time, provided you have not entered any customer addresses.
Attention: If you will be using flexible address formats to enter and validate your customer address information, we recommend that you implement the seeded Sales Tax Location Flexfield structure, Country – No Validation. Alternatively, if you use a Sales Tax Location Flexfield that contains a segment other than country and wish to set up a flexible address format for your home Country, every component in your Sales Tax Location Flexfield structure must also exist in your flexible address style for that country.
Below is a list of optional system options. All other system options are required. No default values are provided.
    • AutoCash Rule Set
    • Tax Registration Number
    • Accounting Flex Tuning Segment
    • System Items Tuning Segment
    • Territory Tuning Segment
    • SQL Trace
    • Purge Interface Tables
    • Unallocated Revenue Account*
* Required if your Accounting Method is Cash Basis.
Attention: If you use the Oracle Applications Multiple Organization Support feature, you need to perform this step for each of your operating units. For more information about multiple organizations, refer to the Multiple Organizations in Oracle Applications manual.
Step 15 Define Your Payment Terms (Required, Default)
You must specify the payment terms to associate with your invoices, debit memos and commitments to determine your customer’s payment schedule. You can also include tiered discounts for early payment. Receivables provides a predefined payment term, ’30 NET’.
Step 16 Define Your Accounting Rules (Optional)
If you want to recognize revenue over multiple accounting periods, you must define accounting rules. Receivables lets you define as many accounting rules as you want. If you use an accounting rule, you must associate it with an invoicing rule. Invoicing rules determine when to book your receivables. Receivables provides two invoicing rules: ‘Bill in Advance’ and ‘Bill in Arrears’.
When you use accounting rules, you also need to define the appropriate periods to which your rule refers. You enter these periods in the Calendar window and they must refer to the same period type as your accounting rule. For example, if you are using an accounting rule that recognizes revenue monthly from Jan-93 through Jun-93, you must define periods from Jan-93 through Jun-93 where the period type is ‘Month.’ These periods must be defined in the same calendar as your accounting periods.
Attention: If you have an accounting period type that is not ‘Month’ and you use AutoInvoice with Oracle Order Entry, you should update the Period field for the predefined IMMEDIATE accounting rule to the same period as your accounting period type.
Step 17 Open Your Accounting Periods (Required)
Maintain the accounting periods to control transaction entry, receipt application, and posting. Receivables provides the following period statuses: Not Opened, Future, Open, Close Pending, and Closed.
Step 18 Define Your AutoAccounting (Required)
Define all of your AutoAccounting account structures that Receivables uses. Receivables creates default revenue, receivables, freight, tax, suspense, unbilled revenue, and unearned revenue accounts based on the information you enter for your AutoAccounting structures.
Attention: If you use the Oracle Applications Multiple Organization Support feature, you need to perform this step for each of your operating units. For more information about multiple organizations, refer to the Multiple Organizations in Oracle Applications manual.
Step 19 Set up Cash Basis Accounting (Optional)
If you are not using the Cash Basis accounting method, you can skip this step.
If you are using the Cash Basis method of accounting, you must perform various steps in addition to setting your Accounting Method system option to ‘Cash Basis’. For more information,
One of the steps to set up Cash Basis Accounting requires that you define transaction types. Transaction types are discussed in more detail in the next step.
Step 20 Define Your Transaction Types (Required, Default)
Define the transaction types that you assign to your invoices, debit memos, commitments, chargebacks, credit memos, and on-account credits. Receivables uses transaction types to default payment term, account, tax, freight, creation sign, posting, and receivables information. Receivables provides two predefined transaction types: ‘Invoice’ and ‘Credit Memo’.
Attention: If you use the Oracle Applications Multiple Organization Support feature, you need to perform this step for each of your operating units. For more information about multiple organizations, refer to the Multiple Organizations in Oracle Applications manual.
Step 21 Define Your Transaction Sources (Required, Default)
Define the transaction sources that you will assign to your invoices, debit memos, commitments, credit memos, and on-account credits. Receivables uses transaction sources to control your transaction and transaction batch numbering, to specify your default transaction type, and to select validation options for imported transactions. Before you can define a transaction source for your invoices, you must define transaction sources for your credit memos. Receivables provides the following predefined transaction sources: ‘MANUAL-OTHER’, ‘DM Reversal,’ and ‘Chargeback’.
Attention: If you use the Oracle Applications Multiple Organization Support feature, you need to perform this step for each of your operating units. For more information about multiple organizations, refer to the Multiple Organizations in Oracle Applications manual.
Step 22 Define Your Collectors (Required, Default)
Define collectors to assign to your customers through credit profile class assignments. You can use the customer account review windows and collection reports to alert your collectors of their customer’s past due items. Receivables provides a single collector called ‘DEFAULT.’
Step 23 Define Your Adjustment Approval Limits (Required)
Assign adjustment approval limits to each user to control adjustments made to invoices, debit memo, and chargebacks. Receivables lets you assign approval limits by currency. These limits are used in the Adjustments, Approve Adjustments, and Receipts windows.
Step 24 Define Your Remittance Banks (Required)
Proceed to the next step if you have already defined your remittance banks in Oracle Payables.
Define all of the banks and bank accounts you use to remit your payments. You can define as many banks and bank accounts as you want, but each bank account must refer to one currency. Receivables requires that you enter a cash account for each bank account.
Step 25 Define Your Distribution Sets (Optional)
Define distribution sets if you have non-invoice related transactions and you want to use a predefined revenue distribution set. To speed data entry, revenue distribution sets can also be assigned to receivables activities with a type of Miscellaneous Cash.
Step 26 Define Your Receivables Activities (Required)
You must define receivables activities to link accounting information to your adjustments, finance charges, and miscellaneous cash transactions.
Step 27 Define Your Receipt Classes (Required)
Define receipt classes to specify whether receipts are created manually or automatically. For manual receipts, you can specify whether to automatically remit it to the bank and/or clear your accounts. For automatic receipts, you can specify a remittance and clearance method, and whether receipts using this class require confirmation.
Step 28 Define Your Payment Methods (Required)
Define the payment methods to assign to your receipt classes. When you define your payment methods, you must enter a receipt class, remittance bank information, and the accounts associated with your payment receivables type. You can also specify accounts for confirmation, remittance, factoring, bank charges, and short-term debt.
Step 29 Define Your Receipt Sources (Required)
Define the receipt sources that you assign to receipts. When you define a receipt source, you can enter a default receipt class and payment method.
Attention: If you use the Oracle Applications Multiple Organization Support feature, you need to perform this step for each of your operating units. For more information about multiple organizations, refer to the Multiple Organizations in Oracle Applications manual.
Step 30 Define Your Aging Buckets (Optional)
You can define additional aging buckets to use when aging your receivables. Aging buckets are used by the Customer Aging window, statements, and the Credit Snapshot and Aging reports. Aging buckets can include pending adjustments, items that are past due, not past due, current, due in the future, and in dispute.
Step 31 Define Your Statement Cycles (Optional)
If you want to send your customers statements, define statement cycles and statement dates. The dates you associate with each statement cycle are the dates for which you plan to generate statements for your customers. You can then assign statement cycles to your customers in the Customer Profile Classes window.
Step 32 Define Your Statement Messages (Optional)
To customize your statements with personal messages, define statement messages. These messages automatically print on the bottom of your statements. Use the Print Statements window to assign statement messages and submit statements for printing.
Step 33 Define Your Dunning Letters (Optional)
To send your customers dunning letters to inform them of past due items and finance charges, define dunning letters. Receivables provides three predefined letters named ‘STANDARD1’ through ‘STANDARD3’ and ten user definable letters named ‘USER1’ through ‘USER10’. You can customize each dunning letter by printing variables that are specific to each customer. These variables can be included in the text of the letter. Dunning letters must also be grouped into dunning letter sets (see Step 34).
Step 34 Define Your Dunning Letter Sets (Optional)
If you want to send your customers dunning letters, you must define dunning letter sets. Dunning letter sets let you combine a sequence of dunning letters into one group and increase the severity of each letter that you send. You can assign dunning letter sets to your customers in the Customer Profile Classes window. Receivables provides one letter set named ‘STANDARD,’ which includes the three STANDARD letters described in the previous step.
Step 35 Define Your Territories (Optional)
If you have defined your Territory Flexfield and want to create customized reports, you can define your Territory Flexfield combinations. Receivables lets you assign Territory Flexfields to salespeople, invoices, and customer business purpose.
Step 36 Define Your Salespeople (Required, Default)
Define the salespeople you assign to your invoices, debit memos, and commitments to allocate sales credits. If you do not want to assign sales credits to a transaction, you can enter ‘No Sales Credit’.
Attention: If you use the Oracle Applications Multiple Organization Support feature, you need to perform this step for each of your operating units. For more information about multiple organizations, refer to the Multiple Organizations in Oracle Applications manual.
Step 37 Define Your Profile Options (Required)
For each Receivables application, specify values for your personal profile options. Profile options determine default values for some Receivables operations, how Receivables processes data control and control which actions a user can perform. Your system administrator determines which profile options you can choose.
You can use the Personal Profile Values window to set profile options only at the user level. System administrators use the System Profile Values window to set profile options at the site, application, responsibility, and user levels. Receivables defaults all profile options at the site level.
Step 38 Define Your Tax Codes and Rates (Required)
If your Tax Method in the System Options window is set to ‘VAT’, you should enter the tax codes and tax rates you want Receivables to use when calculating tax for your transactions. Tax codes can be assigned to customers, customer site uses, and standard memo lines.
If your Tax Method in the System Options window is set to ‘Sales Tax’, you must define at least one tax code with a type of ‘Location’ in the Tax Codes and Rates window. Receivables will use this tax code to calculate your location based tax. Enter a name for your location tax code, enter a type of ‘Location,’ and a tax account. This account cannot be updated once you have committed your change. You can, however, enter additional ‘Location’ tax codes for different date ranges.
For either Tax Method, you may wish to set up an ‘International’, zero-rated tax code to assign to foreign addresses.
Attention: If you use the Oracle Applications Multiple Organization Support feature, you need to perform this step for each of your operating units. For more information about multiple organizations, refer to the Multiple Organizations in Oracle Applications manual.
Step 39 Define Your Customer Profile Classes (Required, Default)
You must define customer profile classes to categorize your customers based on credit, payment terms, statement cycles, automatic receipt, finance charge, dunning, and invoicing information. When you initially set up your customers, you assign each customer to a profile class. To customize the profile class for a specific customer, use the Customer Profile Classes window. Receivables provides the predefined customer profile class ‘DEFAULT’.
Step 40 Define Your Customers (Required)
Proceed to the next step if you have already defined your customers while setting up another Oracle Applications product.
You must define your customers and customer site uses to enter transactions and receipts in Receivables. When you enter a new customer, you must enter the customer’s name, profile class and number (if automatic customer numbering is set to No). You can enter addresses, contacts, site uses and telephone numbers for your customers. You will be required to enter all the components of your chosen Sales Tax Location Flexfield when entering customer addresses in your home country. You define your Sales Tax Location Flexfield and home country in the System Options window.
Step 41 Define Your Remit-To Addresses (Required)
Define remit-to addresses to inform your customers where to send their payments. Associate each remit-to address with one or more state, country and postal code combinations. For example, if you want your customers in California and Nevada to send their payments to a specific address, enter the remit-to address and associate the states CA and NV with this address. Remit-to addresses are assigned based on the bill-to address on the transaction.
If you do not wish to set up a remit-to address for each location, you can set up one remit-to address with a default assignment. This will be used for all locations or for any locations that do not have specific location assignments.
To set up a default remit-to address, enter the remit-to address, navigate to the assignment region then, using the list of values in the Country field, select ‘Default Value’. Move to the next field and select the ‘DEFAULT’ state from the list of values. Then save your record. Remit-To Addresses.
Suggestion: It is a good idea to set up a default remit-to address, even if you have other remit-to addresses defined, because Receivables can use this address if the bill-to location on the transaction is not covered by any other remit-to address assignment. This may happen, for example, when you use new customers.
Attention: If you use the Oracle Applications Multiple Organization Support feature, you need to perform this step for each of your operating units. For more information about multiple organizations, refer to the Multiple Organizations in Oracle Applications manual.
Step 42 Define Your Customer Relationships (Optional)
If you want to restrict receipt application to related customers only, define relationships between your customers and set the system option ‘Allow Payment of Unrelated Invoices’ to No. When you create relationships, customers can also apply invoices to related customer commitments. Receivables lets you define one way and reciprocal relationships between your customers.
Step 43 Define Your Customer Banks (Optional)
If you want to create automatic receipts, you need to define your customer banks and bank accounts. With automatic receipts, Receivables transfers funds directly from your customer’s bank to your remittance bank on the receipt maturity date.
Step 44 Define Your Lockboxes (Optional)
To use the AutoLockbox program to automatically record receipts from your banks, define your lockboxes. For each lockbox, enter the lockbox number, bank name, batch source, bank account, bank origination number and cash account.
Step 45 Define Your Transmission Format (Optional)
To use the AutoLockbox program, define your transmission file format. A transmission format is required to successfully import receipt information from your bank into Receivables. Receivables provides two standard transmission formats that you can modify: Default and Convert.
Step 46 Define Your Receipt Programs (Optional)
To use the Automatic Receipts feature, define the receipt programs you will use to send paper and electronic documents to your customers and remittance banks.
Step 47 Define Your Unit of Measure Classes (Optional)
Proceed to the next step if you have already defined your units of measure classes while setting up another Oracle Applications product.
Use the Units of Measure Classes window to define and update groups of units of measure with similar characteristics (for example, Volume or Length). A class consists of a base unit of measure and other assigned units of measure. Use this window to define the base unit of measure for each class.
Step 48 Define Your Units of Measure (Required, Default)
Proceed to the next step if you have already defined your units of measure while setting up another Oracle Applications product.
Use the Units of Measure window to define one or more units of measure. Each item that you define in Receivables must have a primary unit of measure that you will have defined in this window. The number of units of measure that you define in this window depends on the variety of physical characteristics of your organization’s inventory.
Step 49 Define Your Standard Memo Lines (Optional)
To enter predefined lines for debit memos, on-account credits and invoices, define standard memo lines. When you define your standard memo lines, you can specify whether a line is for charges, freight, line, or tax. Receivables also lets you define one chargeback and one debit memo reversal line.
Attention: If you use the Oracle Applications Multiple Organization Support feature, you need to perform this step for each of your operating units. For more information about multiple organizations, refer to the Multiple Organizations in Oracle Applications manual.
Step 50 Define Your Item Tax Rate Exceptions (Optional)
To assign special tax rates to items shipped to specific addresses, define your item exceptions for specific Location Flexfields. In order for Receivables to use these exception rates, you should not assign tax codes to your customers or their site uses.
Step 51 Define Your Tax Exemptions (Optional)
To partially or fully exempt your customers or items from specific tax rates, define customer and item tax exemptions.
Attention: If you use the Oracle Applications Multiple Organization Support feature, you need to perform this step for each of your operating units. For more information about multiple organizations, refer to the Multiple Organizations in Oracle Applications manual.
Step 52 Define Document Sequences (Optional)
By assigning unique numbers to documents, you can account for each transaction you enter and the document that accompanies it.

To enable sequential numbering, set the Sequential Numbering profile option to either ‘Always’ or ‘Partially Used’. You must then define and assign categories and sequences for each transaction type, payment method, adjustment, and finance charge activity that you use.

More and more companies are doing business globally, and taking advantage of the operations and tax benefits that can be achieved by running operations throughout the world. These companies have multiple operating units and organizations around the world. When goods are shipped or received, the financial ownership through these organizations does not necessarily follow the physical movement of goods. Oracle Applications support three main logistics needs of global organizations – Central Distribution, Central Procurement and Drop Ship.
  • Central Procurement (P2P)
  • Central Distribution (IR ISO)
  • Drop Ship
    1.  External (O2C)
     2. Internal (O2C)
A corporation manages its global operations in various countries through a network of subsidiaries, separate legal entities, licensees and several associated label franchisee. This complex network of operations is necessitated to take care of local legal and fiscal environment, which prevail in each of those countries.
Consider the below example:
Vision Operations (V1) is based in USA. It has a 100 % owned subsidiary company called Vision Asia (VA). VA in turn has two subsidiaries – Vision Japan (VJ) and Vision China (VC). VJ has manufacturing facilities in Osaka (O1) and distribution center at Tokyo (T1). Due to tax advantages, V1 sources all the goods from china through VJ. Though the financial transactions between V1 and VC are routed through VJ, logistic movement of goods takes place directly between V1 and VC.
Continuing the above example, Vision Operations (V1) has another subsidiary company called Vision Singapore (VS), 100 % that it owns. Individual plants procure components from their own suppliers. VS centralizes all the commodity (like steel, Aluminum etc.,) procurement needs of Vision Operations across Overview of Intercompany Invoicing 1 world and procures the material on behalf of all VJ and its subsidiary plants and places purchase orders on its suppliers. However, material is directly shipped from the suppliers to all the manufacturing plants.

Fig1
A key requirement for the global implementation of Oracle applications in such a complex business environment is the ability to process “intercompany transactions,” where one business unit (across OUs)invoices another for transfer of goods and services. Often these intercompany transactions involve transactions related to general expenses, funds transfer, salary transfers, asset transfers, royalty payments and product transfers.
For example, the organization structure depicted in figure 1 can be modeled in Oracle applications as depicted in Figure 2.

Following are the key implementation points you need to look into:
  • Understand the corporation business entities and the relationship between them. Identify selling-shipping relationships and procuring-receiving relationships.
  • Understand Oracle multi org structure and the building blocks in data structure.
  • Breakup the business relationships into manageable process flow and map it to various entities in Oracle applications.
Maintaining Invoice and Credit Memo Transactions
In oracle Receivables transaction can be reviewed an updated after creation regardless of whether the transaction was created manually or imported using ‘Auto Invoice’.There are exceptions to this and some system options and profile options have to be set.

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

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

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

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

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

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

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

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

System options can be set as follows

Setup/System/System Options/Trans and Customers Tab

Set allow change to printed transactions to Yes

Profile Options can be set as follows

Using the system administrator responsibility

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

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

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

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

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

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

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

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

AR_Receivable_Applicaitons_all- stores how much of the credit memo is applied

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

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

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

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

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

Receipts write off receivable activity

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

Navigation Setup – Receipts – Receivable Activities.

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

Navigations

Setup/Transaction/Approval Limits

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

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

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

c) How to Manually Write off Receipt Amounts

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

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

To manually write-off a receipt amount:

Navigation Receipts- Receipts or Receipt- Batches

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

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

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

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

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

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

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

How to Write off Receipt Amounts in Mass

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

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

To create an automatic write-off:

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

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

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

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

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

Specify a payment method, if desired.

Specify an individual customer name, if desired.

Specify an individual customer number, if desired.

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

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

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

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

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

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

Query the existing cash receipt.

Choose the Applications button.

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

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

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

To review receipt write-off information:

Navigation

Receipts – Receipts or Receipts – Receipts Summary.

Query the receipt to view.

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

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

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

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

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

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

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

AR_PAYMENT_SCHEDULES_ALL
AR_RECEIVABLE_APPLICATIONS_ALL
AR_DISTIRBUTIONS_ALL

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

Figure 2

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

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

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

Steps to Perform India localization in R12
The following table lists setup steps required for India localization.