Oracle Financials

FNDLOAD

2007-11-27T23:58:00.000+05:30

Data Synchronization: Data Synchronization is a process in which some setup data would be synchronized, and this would be more important when you are working in oracle application development/implementation project. The equally important that AOL data Migration takes place necessary to synchronize the data across databases instance during

Installations (New desc. flex field creations etc)
Upgrades (Apps upgrade etc)
Maintenance (Value set changes etc)

FNDLOAD is one and only oracle solution. It can be defined as a concurrent program that can move Oracle Applications data between database and text file representations. Or this can be defined as FNDLOAD can download data from an application entity into an editable text file, which can be uploaded to another database.

Working of FNDLOAD: Conversion between database format and text file format is specified by a configuration file. Oracle does provide configuation file and it is important to just pass the configuration file name and then just call the loader and leave everything .

These are the extensive list which can be done through FNDLOAD

Concurrent Programs, Executables
Request Groups, Request Sets
Profile Options
Key and Descriptive Flexfields
Menus and Responsibilities
Forms and Form Functions
Attachments
Messages
Value Sets and Values
Lookup Types
User Responsibilities
Printer Definitions
FND Dictionary
Help Configuration
Document Sequences
Concurrent Manager Schedules

Advantages using FNDLOAD are :

Because downloaded data is stored in a text file, version administration is possible
No learning curve.
Fully supported and recommended by Oracle
Capture the migrations in a file and use it during installations, clones etc. to migrate in batch
Pin-point when something happened and where (database) easily
Your AOL data migration process is now simplified and streamlined.

Disadvantages:

Applications patching mechanisms use FNDLOAD heavily – possibility of negative impact is not zero
UPLOAD_MODE=REPLACE only for menus
No validation against migrating database/instance sensitive data

Syntax : To use FNDLOAD, the following syntax is needed.
FNDLOAD apps/appspwd 0 Y mode configfile datafile entity [parameter1…..]

The mode is either DOWNLOAD or UPLOAD.
The configfile is the file that Fndload needs to download on upload data.
The data file is the output file, in which the downloaded data is written
The entity is the entity you want to download,

Modes of Operation:Two modes .. Upload and Download…
1. Example of download:

FNDLOADapps/pwd 0 Y DOWNLOAD ${FND_TOP}/patch/115/import/afcpprog.lct myfile.ldt \ PROGRAM CONCURRENT_PROGRAM_NAME= concurrent_program_short_name> APPLICATION_SHORT_NAME=

2. Example of Upload

FNDLOAD apps/pwd 0 Y UPLOAD ${FND_TOP}/patch/115/import/afcpprog.lct myfile.ldt - CUSTOM_MODE=FORCE undocumented parameter

FNDLOAD Load Options:

Application level OR single entity level download: Download all the profile options of Inventory or just the INV: Default Primary UOM
Entire OR Partial upload of a data file: Upload the entire myfile.ldt or just a single enity indicated by - and mode UPLOAD or UPLOAD_PARTIAL
Entity name required for UPLOAD_PARTIAL mode
Custom mode force update : To override Oracle’s upload algorithm and update the custom AOL data regardless, use CUSTOM_MODE= FORCE
UPLOAD_MODE= REPLACE (only for menus)
Support for NLS uploads : NLS data uploads for translated columns are supported, use UPLOAD_MODE= NLS

Config File Location: By default Oracle delivers most of configuration files you can use to download certain entities.

1. Configuration files with extension .lct
On Unix - all the configuration files are in $FND_TOP/patch/115/import directory
On Unix – Oracle also places the original configuration files in $FND_TOP/admin/import directory
2. Data files with extension .ldt

The config files (.lct) are delivered and maintained by Oracle.
It has entity definitions, parent-child relationships and user input parameters identified by :NAME
Downloading a parent automatically downloads all children - e.g. Concurrent Program download
The data files (.ldt) have both entity definition and the data
It also shows the version and the location of the config file (.lct) that was used
Without the config file, data file is useless
Without the data file, config file is meaningless
Key files: .lct and .ldt
You must run the FNDLOAD as apps user not as applsys or any other, otherwise you will receive Ora-6550
Both are easily readable, editable and portable
DO NOT MODIFY Oracle’s .lct files
Use your favorite editor (I would suggest Textpad or Editplus) to manipulate only the .ldt files but be cautious about data type, length, delimiter placements etc.
Use the log file outputs or .ldt file contents creatively for quick file comparisons and answer questions faster (Why can’t I access that? What is that profile option name, value and level? What is the value set used for that DFF segment attribute10 etc.)
Partial string searches (which value set has Priority “something” in its where clause? etc)

Sample Script Code:

1 - Printer Styles
FNDLOAD apps/apps@seed115 O Y DOWNLOAD $FND_TOP/patch/115/import/afcppstl.lct file_name.ldt STYLE PRINTER_STYLE_NAME=”printer style name”

2 - Lookups
FNDLOAD apps/apps@seed115 O Y DOWNLOAD $FND_TOP/patch/115/import/aflvmlu.lct file_name.ldt FND_LOOKUP_TYPE APPLICATION_SHORT_NAME=”prod” LOOKUP_TYPE=”lookup name”

3 - Descriptive Flexfield with all of specific Contexts
FNDLOAD apps/apps@seed115 O Y DOWNLOAD $FND_TOP/patch/115/import/afffload.lct file_name.ldt DESC_FLEX P_LEVEL=?COL_ALL:REF_ALL:CTX_ONE:SEG_ALL? APPLICATION_SHORT_NAME=”prod” DESCRIPTIVE_FLEXFIELD_NAME=”desc flex name” P_CONTEXT_CODE=”context name”

4 - Key Flexfield Structures
FNDLOAD apps/apps@seed115 O Y DOWNLOAD $FND_TOP/patch/115/import/afffload.lct file_name.ldt KEY_FLEX P_LEVEL=?COL_ALL:FQL_ALL:SQL_ALL:STR_ONE:WFP_ALL:SHA_ALL:CVR_ALL:SEG_ALL? APPLICATION_SHORT_NAME=”prod” ID_FLEX_CODE=”key flex code” P_STRUCTURE_CODE=”structure name”

5 - Concurrent Programs
FNDLOAD apps/apps@seed115 O Y DOWNLOAD $FND_TOP/patch/115/import/afcpprog.lct file_name.ldt PROGRAM APPLICATION_SHORT_NAME=”prod” CONCURRENT_PROGRAM_NAME=”concurrent name”

6 - Value Sets
FNDLOAD apps/apps@seed115 O Y DOWNLOAD $FND_TOP/patch/115/import/afffload.lct file_name.ldt VALUE_SET FLEX_VALUE_SET_NAME=”value set name”

7 - Value Sets with values
FNDLOAD apps/apps@seed115 O Y DOWNLOAD $FND_TOP/patch/115/import/afffload.lct file_name.ldt VALUE_SET_VALUE FLEX_VALUE_SET_NAME=”value set name”

8 - Profile Options
FNDLOAD apps/apps@seed115 O Y DOWNLOAD $FND_TOP/patch/115/import/afscprof.lct file_name.ldt PROFILE PROFILE_NAME=”profile option” APPLICATION_SHORT_NAME=”prod”

9 - Requset Group
FNDLOAD apps/apps@seed115 O Y DOWNLOAD $FND_TOP/patch/115/import/afcpreqg.lct file_name.ldt REQUEST_GROUP REQUEST_GROUP_NAME=”request group” APPLICATION_SHORT_NAME=”prod”

10 - Request Sets
FNDLOAD apps/apps@seed115 O Y DOWNLOAD $FND_TOP/patch/115/import/afcprset.lct file_name.ldt REQ_SET APPLICATION_SHORT_NAME=”prod” REQUEST_SET_NAME=”request set”

11 - Responsibilities
FNDLOAD apps/apps@seed115 O Y DOWNLOAD $FND_TOP/patch/115/import/afscursp.lct file_name.ldt FND_RESPONSIBILITY RESP_KEY=”responsibility

12 - Menus
FNDLOAD apps/apps@seed115 O Y DOWNLOAD $FND_TOP/patch/115/import/afsload.lct file_name.ldt MENU MENU_NAME=”menu_name”

13 – Forms/Functions
FNDLOAD apps/apps@seed115 0 Y DOWNLOAD $FND_TOP/patch/115/import/affrmcus.lct file_name.ldt FND_FORM_CUSTOM_RULES The Upload syntax for all styles: FNDLOAD apps/apps@seed115 0 Y UPLOAD $FND_TOP/patch/115/import/affrmcus.lct file_name.ldt

14. User/Responsibilities
FNDLOAD apps/apps@seed115 0 Y DOWNLOAD @FND:patch/115/import/afscursp.lct file_name.ldt FND_USER Then UPLOAD FNDLOAD apps/apps@seed115 0 Y UPLOAD [UPLOAD_PARTIAL] @FND:patch/115/import/afscursp.lct file_name.ldt FND_USER []

Flexfields in Order Entry/Shipping

2007-11-26T09:47:00.000+05:30

Depending on your system's setup, Oracle Order Entry/Shipping may use some or all of the following key flexfields provided by other Oracle products. Order Entry/Shipping also provides the Pricing Attributes descriptive flexfield to capture information specific to product pricing.

Key Flexfields
1. Accounting (Oracle General Ledger): Defining your Accounting key flexfield is part of setting up your sets of books.
2. Item Catalogs (Oracle Inventory): If you make entries for items in a standard industry catalog or if you want to group items according to certain descriptive elements, you need to configure this flexfield. Even if you do not use item cataloguing, you must enable at least one segment of this flexfield and compile it before you define your items.
3. Item Categories (Oracle Inventory): You must set up this flexfield before you define items because all items must be assigned to categories.
4. Sales Orders (Oracle Inventory):Use the Sales Orders key flexfield to differentiate sales order transactions that Order Entry/Shipping interfaces to Oracle Inventory. You must define this flexfield before placing demand or reservations in Order Entry/Shipping. The profile option OE: Source Code defaults the source code you use in the third flexfield segment.
5. Sales Tax Location (Oracle Receivables): Use this flexfield to charge your customers for tax based on their shipping addresses.
6. Stock Locators (Oracle Inventory): If you want to track items by a specific aisle or row, use this key flexfield to capture additional information about inventory stock locators. If you use this flexfield, you must set the OE: Inventory Stock Location profile option.
7. System Items (Oracle Inventory): Before you define items, set up this flexfield in order to record and report item information. The OE: Item Flexfield profile option needs to be set.
8. Territory (Oracle Receivables): The Territory flexfield can be associated with salespeople, invoices, and customer site addresses. Use it to record and report territory information.

Descriptive Flexfields
1. Pricing Attributes (Oracle Order Entry/Shipping): Pricing attributes modify an item's price without requiring that you create a new item. For example, you sell computer software and the price of the software is different depending on the number of users. You define a pricing attribute called 'Number Of Users'. When you enter an order line, the Pricing Attributes flexfield opens a window to capture the number of users. Oracle Order Entry/Shipping uses this information along with the item and unit of measure to derive the item list price.
The Pricing Attributes descriptive flexfield contains 15 user-definable flexfield segments to be used as pricing attributes. Once defined, the attributes can be used in the lines block of the Sales Orders window, the Line Options window, the Shipment Schedules window, the lines block of the Price Lists window, and the Item Groups window in Oracle Order Entry/Shipping; and in the Services and Renew Service windows in Oracle Service.
2. Delivery Line (Oracle Order Entry/Shipping): The Delivery Line descriptive flexfield, which is available on the Ship Confirm Delivery Special menu, displays a window that you create in which you can define additional delivery line information. The Delivery Line descriptive flexfield contains 20 user-definable flexfield segments to be used as delivery line attributes.
3. Industry Information (Oracle Release Management): If your system includes Oracle Release Management, you can use this flexfield to record industry-specific data for an order line.

Order Entry/Shipping

2007-11-26T09:22:00.000+05:30

Order Entry/Shipping Setup

Order Entry/Shipping provides several features that enable you to set up your system and begin processing order information. You must define business policies, such as how you classify your orders, as well as various control features.

Step 1 Flexfields
Define key and descriptive flexfields to capture additional information about orders and transactions. Flexfields in Order Entry/Shipping.

Step 2 Inventory Organizations
Define inventory organizations (warehouses), organization parameters, subinventories, and picking rules in Oracle Inventory. Overview of Inventory Structure and Defining Picking Rules.

You must define at least one item validation organization and at least one organization that acts as an inventory source for orders fulfilled internally. If you plan to drop ship some orders, you must also define at least one logical organization for receiving purposes. Your item validation organization can be the same as your inventory source or your logical receiving organization, but you cannot use one organization for all three purposes. See: Drop-ship Order Flow.

Step 3 Profile Options
Define profile options to specify certain implementation parameters, processing options, and system options. Order Entry/Shipping Profile Options.

Step 4 Invoicing
Define Receivables invoicing information, including payment terms, invoicing and accounting rules, transaction types, AutoAccounting parameters, territories, and invoice sources.

Territories, and Invoice Batch Sources.

Step 5 Salespersons
Define information on your sales representatives. Salespersons.

Step 6 Tax
Define tax features, such as codes, rates, exceptions, and exemptions. Overview of Tax.

Step 7 QuickCodes
Define QuickCodes that provide custom values for many lists of values used throughout Order Entry/Shipping. Defining Order Entry/Shipping QuickCodes.

Step 8 Freight Charges and Carriers
Define freight charges and freight carriers to specify on orders. Defining Freight Charges and Defining Freight Carriers.

Step 9 Order Cycles
Define order processing flows to meet different order type requirements. Defining Cycle Actions, Defining Cycle Results, Assigning Cycle Action Results, and Defining Order Cycles.

Step 10 Order Number Sources
Define order number sources for automatic numbering of orders. Defining Order Number Sources.

Step 11 OrderImport Sources
Define sources for importing orders into Order Entry/Shipping. Defining OrderImport Sources.

Step 12 Security Rules
Define security rules to prevent users from adding, updating, deleting, and cancelling order or return information beyond certain points in your order cycles. Use the rules Order Entry/Shipping provides, which prevent data integrity violations, or create your own. Defining Security Rules.

Step 13 Units of Measure
Define the units of measure in which you supply items. Defining Units of Measure.

Step 14 Item Information
Define item information, including item attribute controls, categories, and statuses. Defining Item Attribute Controls, Defining Categories, and Defining Item Status Codes.

Step 15 Items
Define the items that you sell, as well as container items. Overview of Item Setup and Control.

Step 16 Configurations
Define the configurations that you sell. Creating a Bill of Material.

Note: Before you set up configurations, define the OE: Included Item Freeze Method profile option. Oracle Order Entry/Shipping Profile Options.

Step 17 Pricing
Define price lists for each combination of item and unit of measure that you sell. Optionally, you can define pricing rules and parameters to add flexibility. Overview of Pricing and Enabling Parameters.

Step 18 Customer Classes
Define customer profile classes. Defining Customer Profile Classes.

Step 19 Customers
Define information on your customers. Entering Customers.

Step 20 Agreements
Define binding or non-binding customer agreements. You can assign pricing, accounting, invoicing, and payment terms to each agreement. Customer Agreements.

Step 21 Standard Value Rule Sets
Define standard value (defaulting) rules for order information to help you enter orders quickly and accurately. Defining Standard Value Rule Sets.

Step 22 Order Types
Define order types to classify orders and returns. For each order type, you can assign a default price list, standard value rule set, approval actions, payment terms, and freight terms. Defining Order Types.

Step 23 Discounts
Define discounts to allow price adjustments based on customer agreements, order types, purchase order numbers, specific products, or specific customers. Before you define discounts, enable your Pricing Attributes descriptive flexfield in the Enable Parameters window. Discounts.

Step 24 Credit Checking
Define your credit checking rules. Automatic Credit Checking of Orders, Defining Credit Check Rules, and Defining Sales Credit Types.

Step 25 Holds
Define automatic holds to apply to orders and returns. Defining Holds.

Step 26 Notes
Define standard documents to attach automatically to orders and returns. Defining Note Categories and Defining Notes in Advance.

Step 27 Shipping Documents
Define groups of shipping documents that print automatically to specified printers when you confirm shipments. Choosing Printers for Shipping Documents and Defining Document Sets.
Step 28 Release Sequence Rules
Define the order in which picking lines are released. Defining Release Sequence Rules.

Step 29 Release Rules
Define and save picking criteria that can be used when running Pick Release. Creating Release Rules.

Step 30 Pick Slip Grouping Rules
Define grouping rules to determine how released picking lines are grouped onto pick slips. Defining Pick Slip Grouping Rules.

Step 31 Container-Load Relationships
Define the relationship between container items and load items to specify which items can be contained within other items. Defining Container-Load Relationships.

Step 32 Shipping Parameters
Define default Shipping parameters. Defining Shipping Parameters.

Accounting For Oracle Receivables

2007-11-15T13:28:00.000+05:30

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.

General Ledger Interface:
- You pass accounting information from Oracle Receivables to Oracle General Ledger using the General Ledger Interface. If you have properly set up Oracle Receivables, you should never have to create manual journal entries in your General Ledger and the two systems should always be in sync.

- 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;
1. Determines if the debits equal the credits;
2. Passes the data to GL for editing; and
3. 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.

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.
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)
________________________________________________
+ 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

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.

Accounting Details
The GL Accounts may or may not appear on the form (depending on what you are doing) but almost every activity you perform has an accounting impact. In order to understand this impact it is necessary to know:
1) what accounts are impacted by each transaction;
2) what are the related set ups;
3) what you may change and/or override and what is out of your control.

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)
: AR (from the invoice)

Payment applied to an invoice with discount terms:
DR : Cash (Receipt Class)
: Unapplied (Receipt Class)
: Discount (Receipt Class)
CR : Unapplied (Receipt Class)
: AR (from the invoice)

When you leave a receipt as unapplied:
DR : Cash (Receipt Class)
CR : Unapplied (Receipt Class)

When you identify a receipt is as a pre-payment or deposit:
DR : Cash (Receipt Class)
CR : On-Account (Receipt Class)

For unidentified receipts:
DR : Cash (Receipt Class)
CR : Unidentified (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 :

In the Category of Adjustment (AR):
DR :
CR : AR (from the original invoice)

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

In the Category of Chargeback (AR):
DR : AR (from the chargeback - you may override)
CR :

In the Category of Trade Receipts:
DR : Cash (Receipt Class)
CR :

In the Category of Trade Receipts (AR):
DR : Unapplied (Receipt Class)
CR : AR (from the original invoice)
: Unapplied (Receipt Class)

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)

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)

Write-off the invoice balance:
DR : Cost of Doing Business (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.

Gain - now worth more:
DR : Cash (Receipt Class at the receipt rate)
: 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)

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)
CR : AR (from the invoice at the invoice rate)
:Unapplied (Receipt Class at the receipt rate)

Exam: 1Z0-200 - [7]

2007-11-13T14:40:00.000+05:30

Daily Business Intelligence (DBI)

- Out-of-the-box reporting and analysis application that enables senior managers and executives to see relevant, accurate and timely information using self-service overview pages.
- DBI overview page is designed for a particular functional, management responsibility. Managers can drill down from the summarized information on each page to detailed reports or to specific transactions in underlying applications, e.g. the Profit and Loss page is designed for a profit centre manager. his page summarizes profit and loss information using the Revenue, Expenses and Operating margin KPIs.
- DBI architecture simplifies the reporting process and ensures the managers are looking the most accurate and up-to-date data.
- DBI only updates the data that has changes since the last refresh.

Overview Page: An overview page is designed to meet the needs of a particular responsibility.
Responsibilty: Is designed for a particular business function or user such as Expense Manager.
Region: A region is a unique set of information on a page.
5 types of regions in DBI are:
1. Table,
2. Graph,
3. Parameter,
4. KPI, and
5. Links
KPI: A KPI is a business metric used for reporting such as Revenue or Operating margin. Managers can use KPIs to compare and judge their performance.

* DBI setup steps need to be performed before using an overview page.
- DBI provides cross-enterprise functionality that is not available as part of standard Oracle reports.

Technical Componets of DBI-

1. Single Oracle Instance: DBI resides in a single instance, which is same as transactional instance. Which reduces the need for a separate maintenance and administration team and optimize reporting performance.
- Materialized views and incremental refresh capabilities enable DBI to summarize a large amount of data efficietly.

2. E-Business Suite Tables: Changes in E-Business suite tables are reflected in DBI whenever incremental request set is run.

3. Base Summary tables and Materialized Views: Used to store summarized DBI data thats serve as the source of the data on each page.

4. Metadata: Used to define the complex relationship between the dimensions, responsibilities, menus, request sets, KPIs, pages, and reports. Metadata is predefined and can not be modified.

5. Rendering technology: Used to render the pages based on the data that is defined in the base summaries, materialized views, and the metadata layer.

6. Request Set generator: Enables to create initial and incremental request sets for each page using the definitions in the metadata layer. The generated request sets include all of the concurrent programs that you need to load or refresh a page.

Common Dimensions:
- A dimension defines a hierarchical relationship between data. YOu can use dimesions to view data at different level of details.
- Dimensions can be either flat or recursive.
1. Flat Dimension: Can be hierarchical but does not display the hierarchy between items.
2, Recursive Hierarchy: Displays a hierarchy between items.
- Each page has a dimesion that is considered the primary dimension. It determines which values are compared in the KPI region.
- Common DBI dimensions are:
1. Currency Dimension
2. Organization Dimension
3. Item Dimension
4. Person Dimension
5. Sales Group Dimension
6. Operating Unit Dimension
7. Time Dimension
8. Inventory Organization Dimension

1. Currency Dimension: Flat dimension that allows to see financial data across all organization units in a common currency. This dimension is populated based on the currencies and daily exchange rates that are defined in Oracle General Ledger.

2. Organization Dimension: Flat dimension that defines the hierarchical relationship between organizations in an enterprise.

Exam: 1Z0-200 - [6]

2007-11-13T14:39:00.000+05:30

Fundamentals of Workflow & Alerts

Exam: 1Z0-200 - [1]

2007-11-13T14:38:00.001+05:30

Overview of 11i E-Business Suite

Architecture:
Multi-tiered distributed computing- various servers distributed among multiple levels, or tiers.

Server: A process or a group of processes that run on a single machine and provide a particular functionality.

Tier: A logical grouping of services, spread across more than one physical machine.
- Database Tier: Supports and manages Oracle database.
- Application Tier: Manages various application components.
- Desktop Tier: Provides user interface via add-on components to a standard web browser e.g. JInitiator or a Java Applet.

- Nodes work closely together in a cluster. Each tier may consists of one or more nodes and each node can potentially accomdate more than one tier. This may be done for simplicity of administration or to maximise performance by reducing network traffic.

Form-based Desktop Tier:
- Single point of access.
- Forms client applet + Oracle JInitiator.
- Forms Client Applet: Presentation applet that supports all form-based products. It is a collection of JAR files, contains all Java classes required to run the presentation layer of Oracle Application Forms.
- Oracle JInitiator: Forms Client Applet must run within JVM or Desktop client. Instead of using browser's JVM, JInitiator component allows use of Oracle JVM. JInitiator is used as a ActiveX component on Windows machine.
- JInitiator is only invoked when a user choose access functions that require it, e.g. running a form.
- Form Client Applet and commonly used JAR files are downloaded from the web server at the beginning of client's first session. Less commonly JAR files are downloaded as needed. Downloaded JAR files are locally cached for future sessions which eliminates network traffic.
- All updates to JAR files are installed on Application tier and downloaded to the client automatically.
- Select "Show Console" on "Basic" JInitiator tab, to see downloading of JAR files.

Application Tier:
- Manage communication between desktop tier and database server.
- Hosts various servers that process the business logic.
- Oracle 9iAS provides technology used on the application tier, Six servers comprises the application tier for Oracle Applications-
1. Web Server
2. Forms Server
3. Reports Server
4. Discoverer Server ( optional)
5. Concurrent Processing Server
6. Admin Server

Load Balancing: Application tier supports load balancing among many of its servers.
- Load Balancing provides higher availability, fault tolerance, reliablity and optimum scalability.
- Load Balancing is typically used to spread the load accross multiple web servers where load may vary significantly.

Web Server: Oracle HTTP Server (Appache), additional components are-
- Web Listener
- Java Servlet Engine
- Java Server Page (JSP)

- Web Listener accepts HTTP requests for particular URLs.
- If possible, web server services the request itself, if page referenced by the URL needs advanced processing, Listener passes the request to servlet engine which contacts database server as needed.

Self-Service Applications ( HTML- Based):
- Do not use Oracle Forms for interface.
- Pages designed in JavaScript and pure HTML.
- Dynamically generates HTML by executing Java code.
- Use Metadata dictionary for flexible layout.
- OAF(Oracle Application Framework) is development plateform for HTML-based applications.

Components of OAF are-

1. BC4J(Business Component for Java): BC4J is included in Oracle JDeveloper and used to create Java business components for representing business logic. Also provides mechanism for mapping relational tables to Java objects and allows separation of application business logic from user interface.

2. AOL/J: Supplies the security and provides OAF with its connection to database server and with application specific functionality e.g. Flexfields.

Java Servlet access with HTML based application-

1. User clicks a hyperlink of a function from browser.
2. Browser makes URL request to web listener.
3. Web Listener contacts JServ where it runs a JSP.
4. JSP obtains contents from application tables (through using MataData dictionary) to construct the HTML page.
5. Resulting HTML page is passed back to browser.

Forms Server:
- Oracle Application forms and associated run-time engine is hosted at form server.
- Mediates communication between desktop client and database server.
- Form server caches data and provides it to the client as needed.
- 3 protocols used by Form server-
1. Standard HTTP
2. Secure HTTPS
3. TCP/IP

* Form server communicate with database server using Oracle Net

- Automatic load balancing among multiple form servers
- Metric server act as a single point of co-ordination for all form server requests.
- Metric is located on one application server. Metric clients, located on other application servers
periodically send load information to metric server.

Reports Server:
- Web Listener contacts the report server through reports Web CGI which allows the user to run reports and see output.
- Master Report server receives initial request and distribute it to one of the other report servers, depending upon the load each can handle.

Discoverer Server:
- An ad-hoc query, reporting analysis and publishing tool that allows user to gain immediate access to information from data marts, data warehouses and OLTP systems.
- Report builders and analysts can easily create, modify and execute ad-hoc queries and reports.
- Casual users can navigate through pre-defined reports and graphs via business views that hide complexity of underlying structures.
- Discoverer hides the complexity of database, presenting it through an intuitive, easy-to-understand interface.
- It complements the report server, allows user to perform projections based on possible changes.

Discoverer End User Layer:
- Key to provide ease of use to underlying data in Oracle Applications' database. It is a layer of metadata located in application database, separated from actual Applications' data.
- 3 components to access the End User Layer-
1. Discoverer Administrator Edition
2. Discoverer Plus
3. Discoverer Viewer

Concurrent Processing Server:
- Feature that allows non-interactive and potentially long runnig functions to be executed effeciently alongside interactive operations.
- To ensure that resource intensive concurrent processing operations do not interface with interactive operations, they can run on a specialised concurrent processing server.
- When a concurrent request is submitted, a row is inserted into a database table specifying the program to be run. A concurrent manager then reads requests from this table and starts associated concurrent program.

Concurrent Managers:
- Acts as a job scheduling and execution system.
- It is itself an executable registered as a program and

Exam: 1Z0-200 - [2]

2007-11-13T14:37:00.000+05:30

Shared Entities and Integration

Fundamentals of Multi-Org

2007-11-13T14:36:00.000+05:30

Fundamentals of Multi-Org

Fundamentals of Flexfields

2007-11-13T13:35:00.000+05:30

Fundamentals of Flexfields

A flexfield is a field made up of sub-fields, or segments. A flexfield appears on your form as a pop-up window that contains a prompt for each segment. Each segment has a name and a set of valid values. There are two types of flexfields: key flexfields and descriptive flexfields.

Key Flexfields: Most organizations use "codes" made up of meaningful segments (intelligent keys) to identify general ledger accounts, part numbers, and other business entities. Each segment of the code can represent a characteristic of the entity. For example, your organization might use the part number PAD-NR-YEL-8 1/2x14" to represent a notepad that is narrow-ruled, yellow, and 8 1/2" by 14". Another organization may identify the same notepad with the part number "PD-8x14-Y-NR". Both of these part numbers are codes whose segments describe a characteristic of the part. Although these codes represent the same part, they each have a different segment structure that is meaningful only to the organization using those codes.

The Oracle Applications store these "codes" in key flexfields. Key flexfields are flexible enough to let any organization use the code scheme they want, without programming.

When your organization initially installs Oracle Applications, you and your organization's implementation team customize the key flexfields to incorporate code segments that are meaningful to your business. You decide what each segment means, what values each segment can have, and what the segment values mean. Your organization can define rules to specify which segment values can be combined to make a valid complete code (also called a combination). You can also define relationships among the segments. The result is that you and your organization can use the codes you want rather than changing your codes to meet Oracle Applications' requirements.

For example, consider the codes your organization uses to identify general ledger accounts. Oracle Applications represent these codes using a particular key flexfield called the Accounting Flexfield. One organization might choose to customize the Accounting Flexfield to include five segments: company, division, department, account, and project. Another organization, however, might structure their general ledger account segments differently, perhaps using twelve segments instead of five. The Accounting Flexfield lets your Oracle General Ledger application accommodate the needs of different organizations by allowing them to customize that key flexfield to their particular business usage. See: the Oracle General Ledger User's Guide.

Descriptive Flexfields: Descriptive flexfields provide customizable "expansion space" on your forms. You can use descriptive flexfields to track additional information, important and unique to your business, that would not otherwise be captured by the form. Descriptive flexfields can be context sensitive, where the information your application stores depends on other values your users enter in other parts of the form.
A descriptive flexfield appears on a form as a single-character, unnamed field enclosed in brackets. Just like in a key flexfield, a pop-up window appears when you move your cursor into a customized descriptive flexfield. And like a key flexfield, the pop-up window has as many fields as your organization needs.
Each field or segment in a descriptive flexfield has a prompt, just like ordinary fields, and can have a set of valid values. Your organization can define dependencies among the segments or customize a descriptive flexfield to display context-sensitive segments, so that different segments or additional pop-up windows appear depending on the values you enter in other fields or segments.
For example, consider the Additions form you use to define an asset in your Oracle Assets application. This form contains fields to capture the "normal" information about an asset, such as the type of asset and an asset number. However, the form does not contain specific fields for each detail about a given asset, such as amount of memory in a computer or lifting capacity of a forklift. In this case, having all the potentially-needed fields actually built into the form is not only difficult, it is undesirable. Because while one organization may have computers and forklifts as assets, another organization may have only computers and luxury automobiles (and no forklifts) as assets. If the form contained built-in fields for each attribute of a forklift, for example, an organization with no forklifts would find those fields to be both unnecessary and a nuisance because a user must skip them to enter information about another type of asset. In fact, fields for forklift information would be cumbersome whenever a user in any organization tries to enter any asset that is not a forklift.
Instead of trying to contain all possible fields for assets information, the Additions form has a descriptive flexfield that you can customize to capture just the information your organization needs about your assets. The flexfield structure can depend on the value of the Asset Category field and display only those fields (segments) that apply to the particular type of asset. For example, if the asset category were "desk, wood", your descriptive flexfield could prompt for style, size and wood type. If the asset category were "computer, hardware", your flexfield could prompt for CPU chip and memory size. You can even add to the descriptive flexfield later as you acquire new categories of assets.
The Enter Journals window in the Oracle General Ledger applications is another example of a form that includes descriptive flexfields to allow organizations to capture additional information of their own choosing. Each block contains a descriptive flexfield as its last field. You might use these to store additional information about each journal entry, such as a source document number or the name of the person who prepared the entry.

Benefits of Flexfields: Flexfields provide you with the features you need to satisfy the following business needs:
1. Customize your applications to conform to your current business practice for accounting codes, product codes, and other codes.
2. Customize your applications to capture data that would not otherwise be tracked by your application.
3. Have "intelligent fields" that are fields comprised of one or more segments, where each segment has both a value and a meaning.
4. Rely upon your application to validate the values and the combination of values that you enter in intelligent fields.
5. Have the structure of an intelligent field change depending on data in your form or application data.
6. Customize data fields to your meet your business needs without programming.
7. Query intelligent fields for very specific information.

What is the distinction between flexfields and application features?
Flexfields, while they are a major feature of the Oracle Applications as a whole, are merely a mechanism to provide many application features. Key flexfields provide a flexible way for the Oracle Applications to represent objects such as accounting codes, part numbers, job descriptions, and more. For example, the Accounting Flexfield is a feature that uses a key flexfield to represent accounting codes throughout most of the Oracle Applications. Similarly, descriptive flexfields provide a flexible way for the Oracle Applications to provide customizable "expansion space" in forms, as well as a way to implement context-sensitive fields that appear only when needed. Both types of flexfield let you customize Oracle Applications features without programming.

Basic Flexfields Concepts

Segment:
- A segment is a single sub-field within a flexfield. You define the appearance and meaning of individual segments when customizing a flexfield. A segment is represented in your database as a single table column.

- For a key flexfield, a segment usually describes a particular characteristic of the entity identified by the flexfield. For example, you can have a key flexfield that stores part numbers. The key flexfield can contain the part number PAD-YEL-NR-8 1/2x14, which represents a yellow, narrow ruled, 8 1/2" x 14" note pad. Each section in the part number, separated by a hyphen, describes a characteristic of the part. The first segment describes the object, a note pad, the second segment describes the color of the object, yellow, and so on.

- Note that we also refer to the fields in a descriptive flexfield pop-up window as segments even though they do not necessarily make up meaningful codes like the segments in key flexfields. However, they do often describe a particular characteristic of the entity identified elsewhere on the form you are using.

Values, Validation and Value Sets:
- Your end user enters a segment value into a segment while using an application. Generally, the flexfield validates each segment against a set of valid values (a "value set") that are usually predefined. To "validate a segment" means that the flexfield compares the value a user enters in the segment against the values in the value set for that segment.
- You can set up your flexfield so that it automatically validates segment values your end user enters against a table of valid values. If your end user enters an invalid segment value, a list of valid values appears automatically so that the user can choose a valid value.
- You can think of a value set as a "container" for your values. You choose what types of values can fit into your value set: their length, format, and so on.
- A segment is usually validated, and usually each segment in a given flexfield uses a different value set. You can assign a single value set to more than one segment, and you can even share value sets among different flexfields. For most value sets, when you enter values into a flexfield segment, you can enter only values that already exist in the value set assigned to the segment.

Structure:
- A flexfield structure is a specific configuration of segments. If you add or remove segments, or rearrange the order of segments in a flexfield, you get a different structure.
- You can define multiple segment structures for the same flexfield (if that flexfield has been built to support more than one structure). Your flexfield can display different prompts and fields for different end users based on a data condition in your form or application data. Both key and descriptive flexfields may allow more than one structure.
- In some applications, different users may need a different arrangement of the segments in a flexfield (key or descriptive). Or, you might want different segments in a flexfield depending on, for example, the value of another form or database field.
- Your Oracle General Ledger application, for example, provides different Accounting Flexfield (Chart of Accounts) structures for users of different sets of books. The Oracle General Ledger application determines which flexfield structure to use based on the value of the GL Set of Books Name user profile option.

Planning Flexfields: Just as for implementing any new application, planning is by far the most important (and probably the most time-consuming) phase of implementing flexfields, so you should give it careful thought. The planning phase can be broken into smaller, though still interrelated, steps:
1. Decide which flexfields to implement
2. Learning about a specific flexfield
3. Planning the structure
4. Planning the segments
5. Planning the segment validation
6. Planning to use additional features
7. Documenting your plan

Suggestion: We recommend that you plan your flexfields as completely as possible, including your potential segment values, before you even begin to define them using Oracle Applications forms. Once you begin using your flexfields to acquire data, you cannot change them easily. Changing a flexfield for which you already have data may require a complex conversion process.

Decide which flexfields to implement: Oracle Applications products rely on some key flexfields as central parts of the applications, so you must set up these key flexfields. For example, while the Oracle General Ledger products use only the Accounting Flexfield key flexfield, almost every Oracle Applications product uses the Accounting Flexfield for some part of its processing. So, you must almost always set up the Accounting Flexfield, especially if you have more than one of the Oracle Applications at your site. In addition, many Oracle Applications products such as Oracle Inventory and Oracle Purchasing use the System Items Flexfield (Item Flexfield). Other Oracle Applications use various key flexfields for various purposes, and defining those flexfields is usually mandatory for a particular application.

- While most Oracle Applications products require that you set up particular key flexfields, many descriptive flexfields are optional. You need only set up optional descriptive flexfields for forms where you want to capture business data not otherwise captured by the form fields.

Learning about a specific flexfield: Because each key and descriptive flexfield has a different purpose, you should be sure to understand the purpose and requirements for the flexfield you want to define. Some flexfields, particularly the Accounting Flexfield, have restrictions on how you can define them. Most descriptive flexfields simply provide a certain number of segment columns you can use for whatever you need to fill your organization's needs.

Defining:
- Defining your flexfield is easy once you have completed and documented your planning stage. You use Oracle Applications setup forms to define your flexfield.

Define your value sets: Depending on exactly how you want to validate your segments, you may spend 10-30 minutes defining each value set (roughly one value set per segment, or fewer if you plan to share value sets or do not plan to use value sets for certain segments).
Note that you do not define your actual values at this point; rather, you are simply defining the containers for your values.

Define your segment structures: This is the main part of defining a flexfield, and includes defining structure titles, segment prompts, segment order, and segment display sizes. Depending on the number of structures and segments you have, you may spend 20-90 minutes per flexfield.

Define your values, if necessary: Depending on exactly how you want to validate your segments, you may spend anywhere from 1-3 minutes defining each independent or dependent value in an Oracle Applications form. If you have legacy systems, you may need to build a program to import your legacy values into Oracle Applications tables.

Define additional features, if necessary: If you plan to use additional features such as cross-validation rules or flexfield value security, you define those additional features at this point.

Data Entry and Ongoing Maintenance: Data entry consists of using your applications for your day-to-day operations. For key flexfields, you may want to predefine the complete codes (combinations of segment values) you want to allow your users to enter.

- As your organization's needs change, you will need to perform ongoing maintenance of your flexfields. For example, you may need to define new flexfield structures or disable old structures. You may also need to add new values or cross-validation rules or value security rules.

Intelligent Key: An intelligent key is a code made up of sections, where one or more parts may have meaning. An intelligent key "code" uniquely identifies an object such as an account or a part or a job. Intelligent keys are useful in applications because they are usually easier for a user to remember and use than a unique number. For example, a part number of PAD-YEL-11x14 is much easier to remember than a unique part number of 57494. However, unique ID numbers are easier to maintain in a relational database application because only one column is required for the ID number, while multiple columns would be required for an intelligent key (one for each section or segment of the code). The Oracle Applications use key flexfields to represent intelligent keys with unique ID numbers. That is, an end user sees and works with an easy-to-remember intelligent key code, while the Oracle Applications only need to store a hidden unique ID number in most tables.

Attention: Throughout this guide we use the "Part Number Key Flexfield" in our examples and graphics. We use this example because it helps to illustrate the uses and behaviors of key flexfields without requiring any specialized accounting, human resources, or manufacturing knowledge. However, there is no actual "Part Number Key Flexfield" in the Oracle Applications, and you should not confuse it with the System Items Flexfield (Item Flexfield) used by many Oracle Applications products such as Oracle Inventory.

Combination: A combination is a particular complete code, or combination of segment values that makes up the code, that uniquely identifies an object. For example, each part number would be a single combination, and if you had ten parts you would define ten combinations. A valid combination is simply a combination that may currently be used (that is, it is not out of date or disabled).

- Note that many of the Oracle Applications products (and their documentation) do not necessarily refer to key flexfield combinations as "combinations". They may refer to combinations using the name of the entity or the key flexfield itself. For example, Oracle Assets uses a key flexfield called the "Asset Key Flexfield" and refers to one of its combinations as "an asset key" or "an asset key flexfield". In another example, Oracle General Ledger and other Oracle Applications products generally use the term "account" or "GL account" to refer to combinations of the Accounting Flexfield.

Combinations Table: Each key flexfield has one corresponding table, known as the combinations table, where the flexfield stores a list of the complete codes, with one column for each segment of the code, together with the corresponding unique ID number (a code combination ID number or CCID) for that code. Then, other tables in the application have a column that stores just the unique ID for the code. For example, if you have a part number code, such as PAD-YEL-11x14, the "Parts" combinations table stores that code along with its ID, 57494. If your application allows you to take orders for parts, you might then have an "Orders" table that stores orders for parts. That "Orders" table would contain a single column that contains the part ID, 57494, instead of several columns for the complete code PAD-YEL-11x14.

Flexfield Qualifier: A flexfield qualifier identifies a particular segment of a key flexfield.
Usually an application needs some method of identifying a particular segment for some application purpose such as security or computations. However, since the a key flexfield can be customized so that segments appear in any order with any prompts, the application needs a mechanism other than the segment name or segment order to use for segment identification. Flexfield qualifiers serve this purpose. You can think of a flexfield qualifier as an "identification tag" for a segment.

For example, your Oracle General Ledger product needs to be able to identify which segment in the Accounting Flexfield contains balancing information and which segment contains natural account information. Since you can customize the Accounting Flexfield so that segments appear in any order with any prompts, Oracle General Ledger needs the flexfield qualifier to determine which segment you are using for natural account information. When you define your Accounting Flexfield, you must specify which flexfield qualifiers apply to which segments.
Other applications, such as Oracle Human Resources, also use flexfield qualifiers. Oracle Human Resources uses flexfield qualifiers to control who has access to confidential information in flexfield segments.
A segment qualifier identifies a particular type of value in a single segment of a key flexfield. In the Oracle Applications, only the Accounting Flexfield uses segment qualifiers. You can think of a segment qualifier as an "identification tag" for a value. In the Accounting Flexfield, segment qualifiers can identify the account type for a natural account segment value, and determine whether detail posting or budgeting are allowed for a particular value.
It is easy to confuse the two types of qualifiers. You should think of a flexfield qualifier as something the whole flexfield uses to tag its pieces, and you can think of a segment qualifier as something the segment uses to tag its values.

Types of Key Flexfield Forms: Key flexfields appear on three different types of application form:
1. Combinations form
2. Foreign key form
3. Range form
These form types correspond to the types of tables that contain key flexfield data.

1. Combinations form: A combinations form is a form whose only purpose is to maintain key flexfield combinations. The base table of the form is the actual combinations table. This table is the entity table for the object (a part, or an item, an accounting code, and so on). The form contains hidden fields for each segment column in the table, as well as displayed fields for the concatenated segment values (the combination) and any other fields (and columns) that the entity requires. A combinations form is sometimes also called a maintenance form.

Foreign key form: A foreign key form is a form whose underlying base table contains only one or two columns that contain key flexfield information. The purpose of a foreign key form often has very little to do with the key flexfield itself, and that the key flexfield appears on the form is essentially incidental. For example, if you have a key flexfield that represents a part number, you would use the combinations form to define new parts and maintain existing part numbers. You would then have many foreign key forms that you use to manipulate your parts. You might have a form where you take orders for parts, another form where you receive parts, and yet another form where you ship parts. The fact that your part number happens to be a key flexfield is not important to your taking orders for your parts.

Range form:
- A range form displays a range flexfield, which is a special pop-up window that contains two complete sets of key flexfield segments. A range flexfield supports low and high values for each key segment rather than just single values. Ordinarily, a key flexfield range appears on your form as two adjacent flexfields, where the leftmost flexfield contains the low values for a range, and the rightmost flexfield contains the high values. A user would specify a range of low and high values in this pop-up window. For example, you might choose a range of part numbers for which you want to run a report.

- The range form uses a special table as its base table. This table contains one or more (usually two) columns for each segment column that appears in the combinations table. However, these columns do not necessarily contain actual segment values, and a row in the table does not necessarily contain actual valid combinations. Usually this table contains two columns for each segment, called SEGMENTn_LOW and SEGMENTn_HIGH (where n is the segment column number), that store the range of values for each segment.

- In Oracle Applications, we use a key flexfield range to help you specify cross-validation rules for key flexfield combinations.

- Some forms use a variation of a range flexfield to capture information for each key flexfield segment that is not necessarily a segment value. For example, the form might capture a "Yes" or "No" value for each segment (the Assign Function Parameters form displays a pop-up flexfield window where you choose Yes or No to specify whether you want to assign a value to each particular segment).

Dynamic insertion: Dynamic insertion is the insertion of a new valid combination into a combinations table from a form other than the combinations form. If you allow dynamic inserts when you set up your key flexfield, a user can enter a new combination of segment values using the flexfield window from a foreign key form. Assuming that the new combination satisfies any existing cross-validation rules, the flexfield inserts the new combination into the combinations table, even though the combinations table is not the underlying table for the foreign key form.

- For some key flexfields, dynamic inserts may not be allowed. Sometimes it may not make sense for an application to allow a user to be able to create a new combination from any form other than the combinations form. For example, a user should not be able to create a new part while taking an order for parts using an Enter Orders form; the application should restrict the creation of new part numbers to authorized users using a Create Parts form.

- Dynamic inserts may not be technically possible for some key flexfields. If the combinations table contains mandatory columns that are not maintained by the flexfield, dynamic inserts would not be possible. If the combinations table contains mandatory non-flexfield columns, such as a "unit of measure" column, the flexfield would not be able to complete the entire row in the combinations table from the foreign key form (because the base table of the foreign key form is not the combinations table). The flexfield does maintain the CCID column.

- Generally there is only one, if any, combinations form for a given key flexfield. In some applications, there may not be a combinations form. In these cases, you would use dynamic inserts to create new combinations.

Overview of Values and Value Sets:
Oracle Application Object Library uses values, value sets and validation tables as important components of key flexfields, descriptive flexfields, and Standard Request Submission. This section helps you understand, use and change values, value sets, and validation tables.
When you first define your flexfields, you choose how many segments you want to use and what order you want them to appear. You also choose how you want to validate each of your segments. The decisions you make affect how you define your value sets and your values.
You define your value sets first, either before or while you define your flexfield segment structures. You typically define your individual values only after your flexfield has been completely defined (and frozen and compiled). Depending on what type of value set you use, you may not need to predefine individual values at all before you can use your flexfield.
You can share value sets among segments in different flexfields, segments in different structures of the same flexfield, and even segments within the same flexfield structure. You can share value sets across key and descriptive flexfields. You can also use value sets for report parameters for your reports that use the Standard Request Submission feature.
Because the conditions you specify for your value sets determine what values you can use with them, you should plan both your values and your value sets at the same time. For example, if your values are 01, 02 instead of 1, 2, you would define the value set with Right-Justify Zero-fill set to Yes.
Remember that different flexfields may have different requirements and restrictions on the values you can use, so you should read information for your specific flexfield as part of your value planning process. For example, the Accounting Flexfield requires that you use certain types of value sets.

Planning Values and Value Sets: To plan values and value sets:
1. Choose a format for your values. Choosing Value Formats.
2. Decide whether your segment should have a list of values. Decide What Your User Needs.
3. Choose an appropriate validation type for your segment. Choosing a Validation Type for Your Value Set.
4. Consider using values that group neatly into ranges so that using range-based features (value security, value hierarchies, and so on) will be easier. Plan Values to Use Range Features.
5. Plan both values and descriptions as appropriate.
6. Plan any value hierarchies, cross-validation rules, value security rules, and so on as appropriate.

Defining Values and Value Sets
1. Prerequisites
- Plan your flexfield structures and segments.
- Thoroughly plan your values and value sets. Planning Values and Value Sets.

2. To define values and value sets:
1. Navigate to the Value Sets window.
2. Define your value set. Defining Value Sets.
3. Define your values. Defining Segment Values.

Relationship Between Independent and Dependent Values: Independent and dependent value sets have a special relationship. While you can have the same dependent values for any of your independent values, the meanings (or descriptions) - as well as any segment qualifier values, enabled/activation information and descriptive flexfield data for that value - of the dependent values depend on which of the independent values you choose in the prior independent segment.

You must set up your independent-dependent value sets carefully using the following sequence: - Create your independent value set first
- Create your dependent value set, specifying a default value
- Define your independent values
- Define your dependent values

When you define each of your independent values, Oracle Applications automatically creates a default dependent value that goes with your independent value. For example, the previous diagram shows a default value of zero (0). If for some reason you create a dependent value set after your independent value set has values, you must manually create a default value in your dependent set for each of your independent values, since each independent value must have a default dependent value. If necessary, create your default dependent values manually using the Segment Values form (you also use this form to create all dependent values other than the default value). You must create at least one dependent value for each independent value, or else your user will be unable to enter segment value combinations in the flexfield. However, we recommend that you carefully follow the above order for creating your value sets so that you never have to create default dependent values manually, since manually creating default dependent values is both tedious and error-prone.

"Dependent" Values with Table Validation: Flexfields uses a special mechanism to support table-validated segments whose values depend on the value in a prior segment (a different mechanism from that used for independent value sets with dependent value sets). You can use flexfield validation tables with a special WHERE clause (and the $FLEX$ argument) to create value sets where your segments depend on prior segments. You can make your segments depend on more than one segment (cascading dependencies). However, you cannot use parent value/child value features with these value sets, nor can you use this mechanism with the Accounting Flexfield.

Parent and Child Values and Rollup Groups :Only Oracle General Ledger and Oracle Public Sector General Ledger use these features, and only with the Accounting Flexfield. Parent and child value sets have a relationship different from the relationship between independent and dependent values.
- You can use a rollup group to identify a group of parent values for reporting or other application purposes. You assign key flexfield segment values to rollup groups.

Implementing Table-Validated Value Sets:
Table-validated value sets let you use your own application tables as value sets for flexfield segments and report parameters instead of the special values tables Oracle Applications provides. You need not enter each value manually using the Segment Values window. Value sets you base on validation tables can be similar to Independent value sets, where values in your Table type value sets are independent of the values in all other segments. Or, depending on how you define your validation table's WHERE clause, they can depend on one or more previous segments in your flexfield.
In general, you should use a validation table if you want a key or descriptive flexfield segment, or report parameter, to use values that your application already requires or maintains for other application purposes. Using a validation table then lets you avoid maintaining two copies of the same values (one in your application's table and the other in Oracle Application Object Library's tables).
You can use many advanced features with your table-validated value sets. You can use validation tables for flexfield segments or report parameters whose values depend on the value in a prior segment. You use flexfield validation tables with a special WHERE clause (and the $FLEX$ argument) to create value sets where your segments depend on prior segments. You can make your segments depend on more than one segment, creating cascading dependencies. You can also use validation tables with other special arguments to make your segments depend on profile options or field values.
If you want to make use of key flexfield features such as rollup groups and parent-child relationships, you can store the child values in your validation table, but you should use the Segment Values windows Oracle Applications provides to add or define the parent values and rollup groups.

Implementing a validation table:
1. Create or select a validation table in your database. You can use any existing application table, view, or synonym as a validation table. Defining Your Validation Table.
2. Register your table with Oracle Application Object Library (as a table). You may use a non-registered table for your value set, however. If your table has not been registered, you must then enter all your validation table information in this region without using defaults.
3. Create the necessary grants and synonyms. Creating Grants and Synonyms for Your Table.
4. Define a value set that uses your validation table. Defining Value Sets.
5. Define your flexfield structure to use that value set for a segment. You can use the same table for more than one value set, using different SQL WHERE clauses to limit which values are used for flexfield and report parameter validation. For example, if you wish to validate different segments against different rows of the same table, you would use the same table twice but select different rows of the table for each value set by using different SQL WHERE clauses.

Warning: You should not use any WHERE clause and/or ORDER BY clause at all for a value set you intend to use with the Accounting Flexfield.

In general, you may use a WHERE clause and/or an ORDER BY clause for validation tables you intend to use with key flexfields other than the Accounting Flexfield.

Attention: If you need a complex SQL clause to select your values from a table, you should instead first define a view over the table which selects the rows you need, and then define the value set over the view.
WHERE Clauses and Bind Variables for Validation Tables for detailed information on using WHERE clauses with special bind variables.

Using hidden ID columns with value sets: If you specify a hidden ID column in addition to your value column, the flexfield saves your hidden ID value, instead of the value from the value column, in the segment column (in your ATTRIBUTEnn column or SEGMENTnn column) of the underlying flexfield table.
Generally, you use value sets with hidden ID columns only for report parameters. You would not normally use them for most key flexfields. In fact, most key flexfields prevent you from using a value set with a hidden ID column by not displaying those value sets in the list of values you use to assign a value set to a segment.

Attention: You should not specify a hidden ID column for value sets you use with your Accounting Flexfield or most other key flexfields.

- If you specify a hidden ID column in addition to your value column, the report parameter window passes your hidden ID value, instead of the value from the value column, to your report.
- Table validated value sets using the "Standard Date" or "Standard DateTime" formats cannot use the ID column.

- Using multiple tables in a single value setFor value sets that use multiple tables, you should always include the table aliases with your all your column names. You must enter the column name directly, since your list of values cannot retrieve any column names for a "table name" that is not a registered single table. For example, you might enter: f.column_name

- For value sets that use multiple tables, you can and should leave the Table Application field blank, since it is effectively ignored in this case. You enter the table names and aliases you want in the Table Name field. Then, you enter the Value Column and Description Column column names directly, with table aliases, since your list of values cannot retrieve any column names for a "table name" that is not a registered single table.

- Displaying additional columns in your list of valuesYou can design your value set to display several columns in the segment value or report parameter value list of values, and these columns may be in different tables. If all your columns exist in the same table, you simply list the additional columns in the Additional Columns field. If your columns exist in different tables, you must specify more than one table name in the Table Name field. You should always use table names or aliases with your column names for your Additional Columns and WHERE clause.
Finally, you can enter the names of the extra columns you want, with their table aliases, in the Additional Columns field. You can specify column widths to display.

- In some cases you may want to use a SQL expression instead of specifying a single column name. For example, you may want to use a DECODE statement instead of a simple column name, such as:
DECODE(FORM.FORM_NAME, 'OEDEOR', 'Enter Orders', 'Not available')
or
DECODE(FORM.FORM_ID, 1234, 1234, NULL)

- You can also use message names as alias names; this functionality allows for ease of translation of column titles. The syntax for using a message name as an alias name is:
E_FLAG "APPL=;NAME="(width)

Cross-Validation Rules A key flexfield can perform automatic cross-validation of segment values according to rules your organization defines when you customize the key flexfield. You can use cross-validation to closely control the creation of new key flexfield combinations, and you can maintain a consistent and logical set of key flexfield combinations that you need to run your organization.

What is Cross-Validation?
Cross-validation (also known as cross-segment validation) controls the combinations of values you can create when you enter values for key flexfields. A cross-validation rule defines whether a value of a particular segment can be combined with specific values of other segments. Cross-validation is different from segment validation, which controls the values you can enter for a particular segment.
You use cross-validation rules to prevent the creation of combinations that should never exist (combinations with values that should not coexist in the same combination). For example, if your organization manufactures both computer equipment and vehicles such as trucks, you might want to prevent the creation of "hybrid" part numbers for objects such as "truck keyboards" or "CPU headlights".

Planning Your Descriptive Flexfield: When you are planning your flexfields, you should consider the following questions and their corresponding decisions:
1. Do you want to capture information that is not otherwise captured by the form? If yes, you define this descriptive flexfield. If no, you need not define this descriptive flexfield at all.
2. Do you want to capture the same information every time, regardless of what other data appears in the form? If yes, you need to define global segments.
3. Do you want to capture certain information sometimes, depending on what other data appears in the form? If yes, you need to define context-sensitive segments.
4. If you want context-sensitive segments, do you want to have the form automatically determine which descriptive flexfield structure to display based on the value of a field somewhere on the form? If yes, you need to define a reference field (note that some descriptive flexfields do not provide reference fields).
5. If you want context-sensitive segments, do you want to have the user determine which descriptive flexfield structure to display by choosing a value in a field inside the pop-up window? If yes, you need to define a context field.
6. How do you want to break down reporting on your descriptive flexfield data? If you want to report on your data by certain criteria or sub-entities, such as account number or project or region, you may want to consider making that sub-entity a distinct segment, rather than combining it with another sub-entity, so that you can categorize and report on smaller discrete units of information.
7. How often does your organization change? This would affect how you set up your values. For example, if you disable old cost centers and enable new ones frequently, you would "use up" cost center values quickly. You would therefore want to use a larger maximum size for your cost center value set so that you can have more available values (for example, you have 999 available values for a 3-character value set instead of 100 available values for a 2-character value set).
8. Do you want to require a value for each segment?

Descriptive Flexfield Concepts:
- Descriptive flexfield segmentsDescriptive flexfields have two different types of segments, global and context-sensitive, that you can decide to use in a descriptive flexfield structure.
A global segment is a segment that always appears in the descriptive flexfield pop-up window, regardless of context (any other information in your form). A context-sensitive segment is a segment that may or may not appear depending upon what other information is present in your form.

- Context-sensitive segmentsIf you have context-sensitive segments, your descriptive flexfield needs context information (a context value) to determine which context-sensitive segments to show. A descriptive flexfield can get context information from either a field somewhere on the form, or from a special field (a context field) inside the descriptive flexfield pop-up window. If the descriptive flexfield derives the context information from a form field (either displayed or hidden from users), that field is called a reference field for the descriptive flexfield.

- A context field appears to an end user to be just another segment, complete with its own prompt. However, a context field behaves differently from a normal flexfield segment (either global or context-sensitive). When a user enters a context value into the context field, the user then sees different context-sensitive segments depending on which context value the user entered. You define a context field differently as well. You use a context field instead of a reference field if there is no form field that is a suitable reference field, or if you want your user to directly control which context-sensitive segments appear.

- A context-sensitive segment appears once the appropriate context information is chosen. The context-sensitive segments may appear immediately if the appropriate context information is derived from a form field before the user enters the descriptive flexfield.

- For a descriptive flexfield with context-sensitive segments, a single "structure" consists of both the global segments plus the context-sensitive segments for a particular context field value. That is, a structure consists of all the segments that would appear in the pop-up window at one time (after the structure has been chosen).

Planning Your Key Flexfield: Your first step in planning your key flexfields is to determine which key flexfields your Oracle Applications product requires. You should also determine the purpose of the key flexfield, as well as the number and length of its available segment columns ( Key Flexfields in Oracle Applications). You should also note whether your key flexfield allows more than one structure, and determine if you do indeed need to define more than one structure. For example, the System Items Flexfield (Item Flexfield) supports only one structure.

- Those key flexfields that allow multiple structures may use different mechanisms to determine which structure a user sees. For example, the Accounting Flexfield uses multiple structures if you have multiple sets of books with differing charts of accounts. Your forms determine which Accounting Flexfield structure to display by using the value of the GL_SET_OF_BOOKS_ID profile option associated with your current responsibility. Other key flexfields may have a field built into the form that allow a user to essentially choose which structure appears.

- You should decide on the number, order and length of your segments for each structure. You must also choose how to validate each segment. See: Overview of Values and Value Sets.
When you are planning your flexfields, you should consider the following questions and their corresponding decisions:

1. How do you want to break down reporting on your key flexfield data? If you want to report on your data by certain criteria or sub-entities, such as account number or project or region, you may want to consider making that sub-entity a distinct segment, rather than combining it with another sub-entity, so that you can categorize and report on smaller discrete units of information.

2. How often does your organization change? This would affect how you set up your values. For example, if you disable old cost centers and enable new ones frequently, you would "use up" cost center values quickly. You would therefore want to use a larger maximum size for your cost center value set so that you can have more available values (for example, you have 1000 available values for a 3-character value set instead of 100 available values for a 2-character value set).

3. Do you want to require a value for each segment?

Fundamentals of System Administration

2007-11-13T00:19:00.000+05:30

Fundamentals of System Administration

What Is System Administration?

A System Administrator is a person responsible for controlling access to Oracle Applications and assuring smooth ongoing operation. Each site where Oracle Applications is installed needs a system administrator to perform tasks such as:

- Managing and controlling security. Decide which users have access to each application, and within an application, which forms, functions, and reports a user can access.

- Setting up new users. Register new Oracle Applications users, and give them access to only those forms, functions, and reports they need to do their jobs.

- Auditing user activity. Monitor what users are doing and when they do it. Choose who to audit and what type of data to audit.

- Setting user profiles. A user profile is a set of changeable options that affects the way Oracle Applications look and behave. A System Administrator can set user profile values at the site, application, responsibility, and user levels.

- Managing concurrent processing. Concurrent Processing is an Oracle Applications facility that lets long-running, data-intensive tasks run simultaneously with online operations, taking full advantage of multitasking and parallel processing. A System Administrator can monitor and control concurrent processing using a few simple forms.

System vs. Database Administrator:

Front end that users see and work with, and

Back end where data manipulation is performed.

The natural division between user applications and the underlying database structures results in two separate job functions: system administrator, and database administrator.
An Oracle Applications System Administrator administers the user interface or applications side of Oracle Applications.
An Oracle Database Administrator (DBA) administers the data that users enter, update, and delete while using Oracle Applications.

Define Oracle Applications users, and assign one or more responsibilities to each user.

Defining Application Users You allow a new user to sign-on to Oracle Applications by defining an application user. An application user has a username and a password. You define an initial password, then the first time the application user signs on, they must enter a new (secret) password.
When you define an application user, you assign to the user one or more responsibilities. If you assign only one responsibility, the user, after signing on, immediately enters an application.
If you assign two or more responsibilities, the user, after signing on, sees a window listing available responsibilities.

Responsibilities define Application Privileges A responsibility is a level of authority in Oracle Applications that lets users access only those Oracle Applications functions and data appropriate to their roles in an organization. Each responsibility allows access to:
- A specific application or applications, such as Oracle General Ledger or Oracle Planning.
- A set of books, such as U.S. Operations or German Sales or an organization, such as New York Manufacturing or New York Distribution.
- A restricted list of windows that a user can navigate to; for example, a responsibility may allow certain Oracle Planning users to enter forecast items, but not enter master demand schedule items.
- A restricted list of functions a user can perform. For example, two responsibilities may have access to the same window, but one responsibility's window may have additional function buttons that the other responsibility's window does not have.
- Reports in a specific application; as system administrator, you can assign groups of reports to one or more responsibilities, so the responsibility a user choose determines the reports that can be submitted.

Each user has at least one or more responsibilities and several users can share the same responsibility. A system administrator can assign users any of the standard responsibilities provided with Oracle Applications, or create new custom responsibilities.

Users Window

Use this window to define an application user. An application user is an authorized user of Oracle Applications and/or Oracle Self-Service Applications who is uniquely identified by an application username. Once defined, a new application user can sign on to Oracle Applications and access data through Oracle Applications windows.

Users Block

1. User Name : An application user enters this username to sign on to Oracle Applications.
The username must not contain more than one word.
You should use only alphanumeric characters ('A' through 'Z', and '0' through '9') in the username. Please note that you must limit your username to the set of characters that your operating system supports for filenames.
* It is recommended that you define meaningful usernames, such as the employee's first initial followed by their last name. Or, for a group account, you can define the application username so as to indicate the purpose or nature of the group account.

2. Password: Enter the initial password of an application user. An application user enters this password along with her or his username to sign on to Oracle Applications.
A password must be at least five characters and can extend up to 100 characters.
You should use alphanumeric characters ('A' through 'Z', and '0' through '9') in a password. All other characters are invalid. This window does not display the password you enter. After you enter a password, you must re-enter it to ensure you did not make a typing error.
If the application user already exists and the two entries do not match, the original password is NOT changed, and you navigate automatically to the next field.
If you are defining a new application user and the two entries do not match, you are required to enter the password again. For a new user, you cannot navigate to the next field until the two entries match.
The first time an application user signs on, they must change his or her password. If a user forgets their password, you can reassign a new password in this field.
As System Administrator, you can set an initial password or change an existing password, but you cannot access the user's chosen password.

3. Person, Customer, and Supplier : Use these fields to enter the name of an employee (person), customer, or supplier contact. Enter the last name and first name, separated by a comma, of the employee, customer, or supplier who is using this application username and password. Use the List of Values to select a valid name.

4. E-Mail/Fax : Enter the E-mail address and/or fax number for this user.

Password Expiration

1. Days : Enter the maximum number of days between password changes. A pop-up window prompts an application user to change her or his password after the maximum number of days you specify has elapsed.

2. Accesses :Enter the maximum allowed number of sign-ons to Oracle Applications allowed between password changes. A pop-up window prompts an application user to change her or his password after the maximum number of accesses you specify has elapsed.
Suggestion: We recommend that you require application users to make frequent password changes. This reduces the likelihood of unauthorized access to Oracle Applications.

Effective Dates

From/To: The user cannot sign onto Oracle Applications before the start date and after the end date. The default for the start date is the current date. If you do not enter an end date, the username is valid indefinitely.
- You cannot delete an application user from Oracle Applications because this information helps to provide an audit trail. You can deactivate an Oracle Applications user at any time by setting the End Date to the current date.
- If you wish to reactivate a user, change the End Date to a date after the current date, or clear the End Date field.

Responsibilities Block

Responsibility : Select the name of a responsibility you wish to assign to this application user. A responsibility is uniquely identified by application name and responsibility name.

From/To : You cannot delete a responsibility because this information helps to provide an audit trail. You can deactivate a user's responsibility at any time by setting the End Date to the current date.

If you wish to reactivate the responsibility for the user, change the End Date to a date after the current date, or clear the End Date.

Securing Attributes

Securing attributes are used by Oracle Self-Service Web Applications to allow rows (records) of data to be visible to specified users or responsibilities based on the specific data (attribute values) contained in the row.

- You may assign one or more values for any of the securing attributes assigned to the user. If a securing attribute is assigned to both a responsibility and to a user, but the user does not have a value for that securing attribute, no information is returned for that attribute.

- For example, to allow a user in the ADMIN responsibility to see rows containing a CUSTOMER_ID value of 1000, assign the securing attribute of CUSTOMER_ID to the ADMIN responsibility. Then give the user a security attribute CUSTOMER_ID value of 1000.

- When the user logs into the Admin responsibility, the only customer data they have access to has a CUSTOMER_ID value of 1000.

Attribute : Select an attribute you want used to determine which records this user can access. You can select from any of the attributes assigned to the user's responsibility.
Value : Enter the value for the attribute you want used to determine which records this user can access.

Defining a Responsibility

When you define a responsibility, you assign to it some or all of the components described below:
1. Data Group (required): A Data Group defines the mapping between Oracle Applications products and ORACLE IDs. A Data Group determines which Oracle database accounts a responsibility's forms, concurrent programs, and reports connect to.

2. Request Security Group (optional): A request security group defines the concurrent programs, including requests and request sets, that may be run by an application user under a particular responsibility.

3. Menu (required): A menu is a hierarchical arrangement of application functions (forms) that displays in the Navigate window. Menus can also point to non-form functions (subfunctions) that do not display in the Navigate window, but that define the range of application functionality available for a responsibility. Each responsibility is associated with a menu.

4. Function and Menu Exclusions (optional):A responsibility may optionally have function and menu exclusion rules associated with it to restrict the application functionality enabled for that responsibility.

Additional Notes About Responsibilities

- Predefined Responsibilities: All Oracle Applications products are installed with predefined responsibilities. Consult the reference guide for your Oracle Applications product for the names of those predefined responsibilities.
Additionally, instances of the major components that help define a responsibility (data groups, request security groups, menus, and functions) are predefined for Oracle Applications.

-Responsibilities and Request Security Groups: When a request group is assigned to a responsibility, it becomes a request security group.
From a standard submission form, such as the Submit Requests form, users can run only the reports, concurrent programs, and request sets that are in their responsibility's request security group.

- If you do not include the Submit Requests form on the menu for a responsibility, then you do not need to assign a request security group to the responsibility.

- If a request security group is not assigned to a responsibility, then users working under that responsibility cannot run any reports, request sets, or other concurrent programs from a standard submission form.

- Responsibilities and Function Security: Oracle Applications GUI-based architecture aggregates several related business functions into a single form. Parts of an application's functionality may be identified as individual Oracle Applications functions, which can then be secured (i.e., included or excluded from a responsibility).

Responsibilities Window

Use this window to define a responsibility. Each application user is assigned at least one responsibility. A responsibility determines if the user accesses Oracle Applications or Oracle Self-Service Web Applications, which applications functions a user can use, which reports and concurrent programs the user can run, and which data those reports and concurrent programs can access.

[ Responsibilities cannot be deleted. To remove a responsibility from use, set the Effective Date's To field to a past date. You must restart Oracle Applications to see the effect of your change. ]

Prerequisites:
- Use the Data Groups window to list the ORACLE username your responsibility's concurrent programs reference on an application-by-application basis.
- Use the Request Groups window to define the Request Group you wish to make available with this responsibility.
- Use the Menus window to view the predefined Menu you could choose to assign to this responsibility.

Responsibilities Block

An application name and a responsibility name uniquely identify a responsibility.

1. Responsibility Name: If you have multiple responsibilities, a pop-up window includes this name after you sign on.

2. Application : This application name does not prevent the user of this responsibility from accessing other applications' forms and functions if you define the menu to access other applications.

3. Responsibility Key: This is a unique name for a responsibility that is used by loader programs. Loaders are concurrent programs used to "load" such information as messages, user profiles and user profile values into your Oracle Applications tables. To help ensure that your responsibility key is unique throughout your system, begin each Responsibility Key name with the application short name associated with this responsibility.

4. Menu : The menu whose name you enter must already be defined with Oracle Applications.

5. Web Host Name : If your Web Server resides on a different machine from your database, you must designate the host name (URL) here. Otherwise, the Web Host Name defaults to the current database host server.

6. Web Agent Name : Enter the PL/SQL Agent Name for the database used by this responsibility. If you do not specify an Agent Name, the responsibility defaults to the agent name current at log-on.

7. Available From: A responsibility may be associated with only one applications system. Select between Oracle Self-Service Web Applications or Oracle Applications.

8. Effective Dates:

From/To : Enter the start/end dates on which the responsibility becomes active/inactive. The default value for the start date is the current date, and if you do not enter an end date, the responsibility is valid indefinitely.

You cannot delete a responsibility because its information helps to provide an audit trail. You can deactivate a responsibility at any time by setting the end date to the current date. If you wish to reactivate the responsibility, change the end date to a date after the current date, or clear the end date.

9. Data Group

Name/Application : The data group defines the pairing of application and ORACLE username.
Select the application whose ORACLE username forms connect to when you choose this responsibility. The ORACLE username determines the database tables and table privileges accessible by your responsibility. Transaction managers can only process requests from responsibilities assigned the same data group as the transaction manager.

10. Request Group

Name/Application :
If you do not assign a request security group to this responsibility, a user with this responsibility cannot run requests, request sets, or concurrent programs from the Submit Requests window, except for request sets owned by the user. The user can access requests from a Submit Requests window you customize with a request group code through menu parameters.

Function and Menu Exclusions Block

Define function and menu exclusion rules to restrict the application functionality accessible to a responsibility.

1. Type : Select either Function or Menu as the type of exclusion rule to apply against this responsibility.
- When you exclude a function from a responsibility, all occurrences of that function throughout the responsibility's menu structure are excluded.
- When you exclude a menu, all of its menu entries, that is, all the functions and menus of functions that it selects, are excluded.

2. Name : Select the name of the function or menu you wish to exclude from this responsibility. The function or menu you specify must already be defined in Oracle Applications.

Self-Service Applications Security

Oracle Self-Service Web Applications uses columns, rows and values in database tables to define what information users can access. Table columns represent "attributes" that can be assigned to a responsibility as Securing Attributes or Excluded Attributes. These attributes are defined in the Web Application Dictionary.
Securing Attributes : Use the List of Values to select valid attributes. You may assign any number of securing attributes to the responsibility.
Excluded Attributes : Use the List of Values to select valid attributes. You can assign any number of Excluded Attributes to a responsibility.

Defining a Request Security Group

Using Request Security:

- You use request security to specify the reports, request sets, and concurrent programs that your users can run from a standard submission form, such as the Submit Requests form.
- To set up request security, you define a request group using the Request Groups form. Using the Responsibilities form, you assign the request group to a responsibility. The request group is then referred to as a request security group.
- You can define a request group to contain single requests, request sets, or all the requests and request sets in an application.
- If you choose to include all the requests and requests sets in an application, the user has automatic access to any new requests and request sets (without owners) in the future.
- A request security group can contain requests and request sets from different applications. If you want to define request security groups that own requests from different applications, please refer to the discussion on Data Groups.

Individual Requests and Request Sets:

Reports or concurrent programs that are not included in a request security group on an individual basis, but that do belong to a request set included in a request security group, have the following privileges:
- Users cannot use the Submit Requests form to run single requests and request sets that are not in their responsibility's request security group.
- Users can, however, run request sets that contain requests that are not in their request security group, if the request set is in their request security group.

If you assign a request set, but not the requests in the set, to a request security group, the user: - cannot edit request information in the request set definition
- cannot stop specific requests in the set from running
- can edit the request set by deleting requests from it or adding other requests to it, only if the user is the assigned owner of the request set

The Request Security Groups figure illustrates the relationship between a request security group, application user, and a responsibility.

Data Groups: A data group is a list of Oracle Applications and the Oracle username assigned to each application. Each application in a data group must have a Oracle username assigned to it. An application may be listed only once in a data group.
An Oracle username and password allow access to an application's tables in an Oracle database. Each Oracle username in a data group determines the database tables and table privileges accessible by the corresponding application or applications.

Data Group's Purpose: Each responsibility has a data group associated with it. A data group serves two purposes:
1. It identifies the Oracle username that forms connect to when you select the responsibility.
2. Concurrent managers use a data group to match the application that owns a report or concurrent program (submitted by a user of the responsibility) with a Oracle username.

Data Group's structure There are four points concerning the makeup of any Data Group.
1. Within each data group, an application can be listed only one time.
2. Within each data group, an Oracle username can be paired with more than one application.
3. Within each data group, the application Application Object Library is automatically included.
- Application Object Library's Oracle username cannot be updated or deleted.
- Application Object Library owns the database tables that oversee concurrent processing and the standard submission of reports by any Oracle Application.
4. Within each data group, a Tool Oracle username can be associated with each application-Oracle username pair. If that application-Oracle username pair is chosen as the one for forms to connect to when the responsibility is selected, then the Tool Oracle username is relevant, and appears by default.

* To prevent users of a responsibility from connecting to the database using a Tool Oracle username, you can backspace over (erase) the default entry. You cannot select a Tool Oracle username associated with another application in the data group.

The Tool Oracle username identifies the database tables and privileges a user of the responsibility has when connecting to the database using an Oracle Tool, for example, SQL*Plus.
- When users of the responsibility select Oracle Tools window to run a tool that requires a database connection, the Tool Oracle Username appears as the default tool access Oracle - Username.
- Users do not need to enter an Oracle password to use the Oracle Username.

* The Oracle Tools window may not be available on your desktop platform.

* If the Oracle Tool is query-only, for example, Oracle Browser, you may assign an unrestricted Tool Oracle Username. If the Oracle Tool allows write privileges, you should assign a Tool Oracle Username that is restricted (read-only).

* Modifying data or table structures using an Oracle Tool, for example, SQL*Plus or SQL*Forms, may damage your data's integrity and is not supported by Oracle.

Request Groups: A request security group is the collection of requests, request sets, and concurrent programs that a user, operating under a given responsibility, can select from the Submit Requests window.

System Administrators:

- Assign a request security group to a responsibility when defining that responsibility. A responsibility without a request security group cannot run any requests using the Submit Requests window.
- Can add any request set to a request security group. Adding a private request set to a request security group allows other users to run that request set using the Submit Requests window.

Users:
- Can create their own private request sets using the Request Sets window. In a private request set, users can include only the requests you assign to their request security group.
- Cannot update another user's private request set using the Request Sets window.
- Cannot delete a private request set if it is assigned to a request security group.

Request Security Groups : When a request group is assigned to a responsibility, the request group is referred to as a request security group. Any user signed on under a responsibility can run the reports and concurrent programs contained in their responsibility's request security group.
The Submit Requests standard submission form displays a list of all the reports and programs in the current responsibility's request security group.

Request Sets:

1. There are significant differences between end user and System Administrator privileges when defining or editing request sets.

2. End users own the request sets they create An end user can create a request set by selecting reports, other request sets, or concurrent programs that are part of the report security group assigned to his or her responsibility.

3. When an end user creates a request set, the user automatically becomes the "owner" of the request set. Ownership is identified by the person's application username.

4. End users use the Request Set form to create a new request set, or to query and update any request sets they own. End users can only edit request sets they own.

5. We sometimes refer to a request set that an end user owns as a private request set. Private request sets are not automatically added to a request security group. That is, other users cannot access your private request sets using the Submit Requests window unless the System Administrator assigns that request set to a request security group.

6. Request sets owned by an end user are always available to that user, regardless of what responsibility the user is operating under. However, a standard submission form customized to display only reports in a request group using a code does not display private request sets.

7. When a user signs on to Oracle Applications, the user can run requests, request sets, and concurrent programs included in:
- their responsibility's request security group
- any request sets they own.

End User Benefits from Private Request Sets: Private request sets offer two main benefits to end users:

1. The request sets that users own are always available to them, regardless of which responsibility they are working under.
2. Users can create as many request sets as they want without adding request set choices to the list of standard submission concurrent programs that other users must select from.

User Profiles

- A user profile is a collection of changeable options that affect the way your applications run. Oracle Applications establishes a value for each option in a user's profile when the user logs on or changes responsibility. Oracle Applications provides these options so that you can alter the behavior of your applications to suit your own preferences.

- Oracle Applications uses a set of user profile options that are common to all the application products. In addition, each application product has its own unique set of user profile options.

- User profile options can be set at one or more of four levels: Site, Application, Responsibility, and User. Your system administrator can set default option values at any of these levels.

Basic Business Needs

Oracle Applications user profiles help you satisfy the following business needs. You should be able to:
- Set options that affect your application's behavior to your preference
- Modify product-specific variables that affect the functionality of your application to suit your business environment

Major Features

User Profile Hierarchy Oracle Applications treats user profile levels as a hierarchy, where User is the highest level of the hierarchy, followed by Responsibility, Application, and at the lowest level, Site. Each user profile option ordinarily exists at each level. For example, Oracle Applications provides a Site-level Printer option, an Application-level Printer option, and so on. Oracle Applications enforces the level hierarchy to ensure that a higher-level option value overrides a lower-level value. For example, if your Site-level Printer value is "New York", but your User-level Printer value is "Boston", you can be assured that your reports print to the Boston printer.

User Profile Options: Changeable options that affect the way your applications run.

User Profile Levels: User profile options exist at four different levels: Site, Application, Responsibility, and User levels. Oracle Applications treats user profile levels as a hierarchy, where User is the highest level of the hierarchy, followed by Responsibility, Application, and at the lowest level, Site. Higher-level option values override lower-level option values.

1. Site Level Site is the lowest profile level. Site-level option values affect the way all applications run at a given installation site.

2. Application Level Application is the profile level immediately above Site. Application-level option values affect the way a given application runs.

3. Responsibility Level Responsibility is the profile level immediately above Application. Responsibility-level option values affect the way applications run for all users of a given responsibility.

4. User Level User is the highest profile level and is immediately above Responsibility. User-level option values affect the way applications run for a given application user.

Determining User Profile Option Values Your system administrator can set values for user profile options at each profile level. Typically, your system administrator sets Site-level option values after installing Oracle Applications at a site. These Site-level option values apply until you or your system administrator changes them.

Oracle Applications derives a run-time value for each user's profile option based on the value set at the highest hierarchy level. For example, suppose your system administrator initially set your Printer option only at the Site and Responsibility levels. When you sign on to Oracle Applications, the Printer option assumes the value set at the Responsibility level, since it is the highest-level setting for that option. If you are not satisfied with that setting, you can set your own preference at the User-level, since your User-level setting overrides the Responsibility-level setting.

[Some option values can only be changed by the system administrator. You can view the value of such a user profile option, but you cannot modify that value. For example, you can view the value of the user profile option Concurrent:Request Priority, which is set at the User-level, but only your system administrator can modify its value for you]

If the default value of a user profile option at any level is inappropriate, your system administrator can change it at any time. Any change your system administrator makes takes effect as soon as you log on again or change responsibilities.

Setting Your Personal User Profile You can change a user profile option value using the Profile Values window. Using this window, you can display all your options and review the values your system administrator has set for them. You can also change those options that are updatable if you like. Changes you make to a User-level profile option take effect when you either change responsibilities or close and re-login into the application. If changes are made in character mode you must follow the same steps to apply the changes to applications running in GUI mode. Changes you make to your User-level options are still in force when you log in again.
If you never set your own User-level option values, your user profile options assume the Site-, Application-, Responsibility-, or User-level values your system administrator has set for them.

Function: A function is a part of an application's functionality that is registered under a unique name for the purpose of assigning it to, or excluding it from, a responsibility.
There are two types of functions: form functions, and non-form functions.
For clarity, we refer to a form function as a form, and a non-form function as a subfunction, even though both are just instances of functions in the database.

Defining a function: Form Function Block

Function : Users do not see this unique function name. However, you may use this name when calling your function programmatically. You should follow the naming conventions for functions.

User Function Name: Enter a unique name that describes your function. You see this name when assigning functions to menus. This name appears in the Top Ten List of the Navigator window.

Type : Type is a free-form description of the function's use. A function's type is passed back when a developer tests the availability of a function. The developer can write code that takes an action based on the function's type.
By convention, Oracle Applications form functions are registered with a type of FORM. A few, specialized functions that determine common form behaviors are registered with a type of UTIL.
Even if you do not register a form function with a type of FORM, Oracle Applications treats it as a form if you specify a valid Form Name/Application

Form
Form /Application
If you are defining a form function, select the name and application of your form.

Parameters : Enter the parameters you wish to pass to your function. Separate parameters with a space.
- For a form function, if you specify the parameter QUERY_ONLY=YES, the form opens in query-only mode. Oracle Application Object Library removes this parameter from the list of form parameters before opening the form in query-only mode.
- You can also specify a differnt form name to use when searching for help for a form in the appropriate help file. The syntax to use is:
HELP_TARGET = "alternative_form_name"
Your form name overrides the name of the form.
- Some Oracle Applications forms are coded to accept particular form parameters. For example, the Run Requests form accepts a TITLE parameter you can use to change the Run Requests window title. The syntax you should use is:
TITLE="appl_short_name:message_name"
where appl_shortname:message_name is the name of a Message Dictionary message.

[Warning: In general, System Administrators should not modify parameters passed to functions that are predefined as part of the Oracle Applications products. The few cases where function parameters may be modified by a System Administrator are documented in the relevant technical reference manual or product update notes.]

Web Regions: The fields in the Web regions are only required if your function will be accessed from Oracle Self-Service Web Applications. You do not need to enter any of these fields for SmartClient and Web-deployed Applications functions.

Host Name : The URL (universal resource locator) or address required for your function consists of three sections: the Host Name, Agent Name, and the HTML Call. The Host name is the IP address or alias of the machine where the Webserver is running.

Agent Name : The second section of your functions URL is the Oracle Web Agent. The Oracle Web Agent determines which database is used when running your function. Defaults to the last agent used.

HTML Call : The last section of your functions URL is the HTML Call. The HTML Call is used to activate your function. The function may be either a static web page or a procedure.

Secured : Secured is only required when your function is accessed by Oracle Workflow. Checking Secured enables recipients of a workflow E-Mail notification to respond using E-Mail.

Encrypt Parameters : Checking Encrypt Parameters adds a layer of security to your function to ensure that a user cannot access your function by altering the URL in their browser window. You must define Encryption Parameters when you define your function to take advantage of this feature.

Defining a Menu

Menus: Menus Window is used to define a new menu or modify an existing menu.
- A menu is a hierarchical arrangement of functions and menus of functions. Each responsibility has a menu assigned to it.
- A "full access" responsibility with a menu that includes all the functions in an application is predefined for each Oracle Applications product. As a System Administrator, you can restrict the functionality a responsibility provides by defining rules to exclude specific functions or menus of functions. In fact, we recommend that you use exclusion rules to customize a responsibility in preference to constructing a new menu hierarchy for that responsibility.
- If you cannot create the responsibility you need by applying exclusion rules, you may build a custom menu for that responsibility using predefined forms (i.e., form functions) and their associated menus of subfunctions. However, we recommend that you do not disassociate a form from its developer-defined menus of subfunctions.

Prerequisites
- Register your application with Oracle Application Object Library using the Applications window.
- Define any menus that you intend to call from your menu. Define the lowest-level submenus first. A submenu must be defined before it can be called by another menu.

* By calling submenus from your menu, you can group related windows together under a single heading on your menu. You can reuse your menu on other menus.

Menus Block Menu entries detail the options available from your menu.
Menu : Choose a name that describes the purpose of the menu. Users do not see this menu name.
User Menu Name : You use the user menu name when a responsibility calls a menu or when one menu calls another.

Menu Entries Block

Sequence : Enter a sequence number to specify where a menu entry appears relative to other menu entries in a menu. The default value for this field is the next whole sequence number.
A menu entry with a lower sequence number appears before a menu entry with a higher sequence number.

Attention: If you change sequence numbers or frequently insert and delete menu entries, carefully check the default value. This value may be a duplicate sequence number or an out of sequence number.
Suggestion: You cannot replace a menu entry sequence number with another sequence number that already exists. If you want to add menu entries to a menu entry sequence that uses only integers, carefully renumber your menu entries to a sequence range well outside the sequence range you want, ensuring that you do not use existing sequence numbers
Once you save this work, you can go back and renumber each entry to have the final sequence number you want.

Navigator Prompt : Enter a user-friendly, intuitive prompt your menu displays for this menu entry. You see this menu prompt in the hierarchy list of the Navigator window.
Suggestion: Enter menu prompts that have unique first letters so that power users can type the first letter of the menu prompt to choose a menu entry.

Submenu : Call another menu and allow your user to select menu entries from that menu.

Function : Call a function you wish to include in the menu. A form function (form) appears in the Navigate window and allows access to that form. Other non-form functions (subfunctions) allow access to a particular subset of form functionality from this menu.

Description : Descriptions appear in a field at the top of the Navigate window when a menu entry is highlighted.

Multiple Reporting Currencies

2007-11-12T16:39:00.000+05:30

Overview: The Multiple Reporting Currencies (MRC) feature allows you to report and maintain accounting records at the transaction level, in more than one functional currency. You do this by defining one or more reporting sets of books, in addition to your primary set of books. In your reporting sets of books, you maintain records in a functional currency other than your primary functional currency. You can set up multiple reporting sets of books and associate them with a primary set of books.
Your primary functional currency is the currency you use to record transactions and maintain your accounting data within Oracle Applications. The functional currency is generally the currency in which you transact most of your business and the one you use for legal reporting.
A reporting functional currency is a currency other than your primary functional currency for which you need to report accounting data. You must define a set of books for each of your reporting functional currencies.
When you enter transactions in Oracle Applications, they are converted, as needed, into your primary functional currency and each of your reporting functional currencies. You log into a reporting responsibility to inquire and report on transactions and account balances in your reporting functional currencies.

Oracle Applications Support for MRCThe following Oracle Applications support Multiple Reporting Currencies:
· General Ledger
· Payables
· Purchasing
· Receivables
· Cash Management
· Projects
· Assets
· Cost Management

[Cost Management amounts are converted to a specified reporting currency when you request a report. The converted amounts, however, are not stored in the Cost Management subledger. ]

When to Use MRC: MRC is specifically intended for use by organizations that must regularly and routinely report their transactions and financial results in multiple currencies, other than their primary functional currency. If you only need to report balances in a currency other than your primary functional currency, the General Ledger Translation feature is probably sufficient.
* MRC is not intended as a replacement for General Ledger's translation feature.

Typically, you should consider using MRC when:

1) You operate in a country whose unstable currency makes it unsuitable for managing your business. As a result, you need to manage your business in a more stable currency and still be able to report your transactions and account balances in the unstable local currency.

2) Your company is multinational, and you need to report financial information in a common functional currency other than that of the transaction or your primary functional currency.

3) You operate in a country that is part of the European Monetary Union (EMU), and you want to concurrently report in Euro in preparation for the pan-European currency.

MRC Features

1- Reporting Sets of Books: In Oracle Applications you record day-to-day business transactions in your organization's primary set of books or post transactions to the primary set of books from your subledgers. From the primary set of books, you can report your account balances in your primary functional currency.
To use MRC, you must define additional sets of books, called reporting sets of books, and associate them with a primary set of books. When defining a reporting set of books, you specify your reporting functional currency as the set of book's functional currency. This is the currency in which you want to inquire and report your transactions and account balances.
For example, assume your business is located in Canada. You use a primary set of books whose functional currency is Canadian Dollars (CAD), but you also need to inquire and report on your transactions and balances in U.S. Dollars (USD), since this is the functional currency of your parent organization. You define a reporting set of books with a functional currency of USD, then you associate this reporting set of books with your primary set of books.

[The full range of General Ledger functionality is available from a reporting set of books. You can post journals, revalue and translate balances, perform consolidations, query account balances, submit standard General Ledger reports, and define custom financial reports.]

2- Transaction-Level Conversion: When you enter transactions in Oracle Applications that support MRC, they are converted, as needed, into your primary functional currency and each of your reporting functional currencies, as follows:

Primary functional currency transactions: All transactions denominated in your primary functional currency are recorded in this currency. The transactions are also converted automatically to each of your reporting functional currencies.

Foreign currency transactions: Transactions denominated in a foreign currency are converted automatically to your primary set of books' functional currency and to each of your reporting functional currencies.

3- Subledger Transactions: When you enter transactions into the subledgers of Oracle Applications that support MRC, the transactions are converted to your reporting functional currencies at the time of original entry. The primary functional currency amounts and their associated reporting currency amounts are stored together in your subledgers. You must post subledger transactions to General Ledger in both the primary set of books and in each reporting set of books.
Since conversion occurs when the transactions are entered, your reporting currency amounts are always synchronized with your primary currency amounts.

4- General Ledger Journals: Journal entries that originate in General Ledger, such as manual journals, recurring journals, and MassAllocations, as well as journals that you import from sources other than Oracle Applications' subledgers, are converted to your reporting functional currencies when you post the journals in General Ledger in your primary set of books.
The converted journals are then copied from your primary set of books to each of the associated reporting sets of books. The converted journals must be posted separately in each reporting set of books.
The balances in your reporting sets of books will not be synchronized with the balances in the associated primary set of books until you:
- Post your subledger transactions to General Ledger from both your primary and associated reporting sets of books
- Post all journals in your primary set of books
- Post the converted journals in each of the associated reporting sets of books

Inquiry and Reporting in Multiple Currencies

Oracle Subledgers: When you enter transactions into the subledgers of Oracle Applications that support MRC, the transactions are converted to your reporting functional currencies at the time of original entry. As a result, your reporting currency information is immediately available for inquiry and reporting in the subledgers. Each inquiry or report that normally displays information in the primary functional currency can also be displayed in any of the associated reporting currencies. To do so, you log into a reporting responsibility, then view and report transactions in the reporting currencies associated with that responsibility.
You must post subledger transactions to General Ledger in both the primary set of books and in each reporting set of books. After you have posted the transactions, you can log into a General Ledger reporting responsibility, post the newly created journals, then report on the journals and the account balances of the associated reporting set of books.

Oracle General Ledger: For General Ledger journals, you must complete the posting process in both your primary set of books and each associated reporting set of books before you can report on the updated balances. Note that separate balances are updated for each set of books.

Before you can report on your updated balances, you must also post your subledger transactions to General Ledger from both your primary and associated reporting sets of books, and post the newly created journals in both your primary and associated reporting sets of books.
Each General Ledger report or inquiry that normally displays information in the primary functional currency can also be displayed in any of the associated reporting currencies. To inquire or report on the account balances of a reporting set of books, you log into the associated General Ledger reporting responsibility.
When you inquire on account balances in a reporting set of books, you can drill down to the subledger details (in your reporting functional currency) using General Ledger's standard drilldown features.

For reconciliation purposes, you can use the Financial Statement Generator (FSG) to create a custom comparison report that lists balances from your primary and reporting sets of books in separate columns. Use this report as the basis for reconciling your primary and reporting sets of books.

Euro Support: MRC allows Oracle Applications to support organizations that are transitioning from their national currency to the Euro:
Transition Period: If you currently use Oracle Applications, you can continue to maintain your current set of books in your national currency and use MRC to begin reporting transactions and financial results in the Euro. If you are implementing Oracle Applications for the first time, you can set up your primary set of books using Euro as the functional currency and use MRC to report transactions and financial results in your national currency.
Currency Conversion: MRC observes the fixed-rate relationships you defined between the Euro and EMU currencies, as well as the effective starting dates of those relationships, when converting transaction amounts to or from the Euro or EMU currencies. When converting amounts from your primary functional currency to your reporting functional currencies, MRC fully complies with the conversion guidelines established by the European Commission.

Setting Up MRCThe following table provides a summary of the steps you must follow to set up MRC in your applications. These steps are described in more detail in the next section.
Note: You must install MRC before you can begin the setup steps in this section. See: Oracle Applications Installation Manual for information about installing MRC.

Step Description

Step 1 Enable or define primary set of books :Set of Books window(General Ledger)
Step 2 Enable and/or define reporting currencies :Currencies window(General Ledger)
Step 3 Define reporting sets of books :Set of Books window(General Ledger)
Step 4 Assign reporting sets of books to primary set of books: Assign Reporting Sets of Books window(General Ledger)
Step 5 Define conversion options for each application: Conversion Options window(General Ledger)
Step 6 Define General Ledger conversion rules: GL Conversion Rules window(General Ledger) Step 7 Define reporting responsibilities : Responsibilities window(System Administrator)
Step 8 Assign reporting sets of books to reporting responsibilities : System Profile Values window (System Administrator)

* Daily rates are used to convert your primary set of book's transactions to the appropriate reporting currencies. If you do not currently maintain daily rates, you must do so when you implement MRC.

Step 1 - Enable or Define Primary Set of Books
If you currently use Oracle Applications, you must enable your set of books as the MRC primary set of books. If you are installing Oracle Applications for the first time, you must define your primary set of books.
Note: Your primary set of books is where you record your day-to-day business transactions in Oracle Applications. The primary set of books uses a specific chart of accounts, accounting calendar, and functional currency. For MRC purposes, the functional currency is always the primary functional currency.
For each set of books you use with MRC, you need to specify whether it is a primary or reporting set of books. This is done on the Set of Books window, using the Reporting Currency Options alternative region.

Step 2 - Enable and/or Define Reporting Currencies
To use MRC, you may need to enable and/or define additional currencies if the currency you want to use for a reporting set of books is not already enabled or does not appear in the list of predefined currencies. In addition, you need to enable and/or define any currencies you expect to use to enter transactions.

Primary Functional Currency: the currency you use to record transactions and maintain your accounting data within Oracle Applications. The primary functional currency is generally the currency in which you transact most of your business and the one you use for legal reporting.
Reporting Functional Currency: a currency other than your primary functional currency for which you need to report accounting data. For example, as of January 1, 1999, the new pan-European currency, the Euro, will become effective. If you need to report in the Euro currency, you will need a reporting set of books with the Euro as the functional currency. Therefore, you need to enable the EUR currency.
Transaction Currency: the currency in which a transaction originates. For example, if you are a Canadian organization and you trade with organizations located in Japan, you must enable the Japanese Yen if you will be issuing purchase orders, generating invoices, paying bills, and receiving payments in Yen.

Step 3 - Define Reporting Sets of Books
To use MRC, you must define reporting sets of books and associate them with your primary set of books.
A reporting set of books is a financial reporting entity that is associated with a primary set of books. The reporting set of books has the same chart of accounts and accounting calendar as the primary set of books, but usually has a different functional currency.
For example, assume that your company headquarters is located in Australia and that its primary functional currency is Australian Dollars (AUD). Assume also that you have one subsidiary each in Canada and Germany, both of which maintain a primary set of books in its local functional currency -- Canadian Dollars (CAD) for the Canadian subsidiary and Deutsche Marks (DEM) or the Euro (EUR) for the German subsidiary. Each subsidiary should maintain a reporting set of books in AUD, so it can analyze and report transactions using the parent's functional currency.
For each reporting set of books you define, you need to specify it as a reporting set of books on the Set of Books window, using the Reporting Currency Options alternative region.

Other Considerations:
1- If your primary set of books is defined as an average balances consolidation set of books, any associated reporting sets of books must also be defined as average balances consolidation sets of books.
2- If you use combined basis accounting with Oracle Payables, you will have two Payables sets of books (primary and secondary). One will be for accrual basis accounting and the other will be for cash basis accounting. If you want to report Payables transactions in your reporting currencies for each accounting basis, you must define a reporting set of books for each.
Other Set of Books Options Some set of books options, such as the chart of accounts and accounting calendar, must be the same in both your primary and reporting sets of books. For other set of books options, we specifically recommend or do not recommend that they be the same in both your primary and reporting sets of books. For still other set of books options, you set them in each reporting set of books depending on what features you want available in that reporting set of books.

Set of Books Options - Recommended Setting in Reporting Sets of Books
1- Functional Currency - Different from primary set of books unless you have a specific reason for using the same functional currency in both sets of books (see Note below)
2- Allow Suspense Reporting - Same as primary set of books.
3- Balance Intercompany Journals - Same as primary set of books.
4- Enable Average Balances - Same as primary set of books only if you want to inquire and report average balance transactions in your reporting currency.
5- Enable Journal Approval - Same as primary set of books only if you want journals created directly in your reporting set of books to be processed through your organization's approval hierarchy.
6- Enable Journal Entry Tax - Same as primary set of books. If it is not the same, you will not be able to view tax details when you inquire on journals in your reporting set of books.
7- Accounts - Same as primary set of books.
8- Average Balance Options: Consolidation Set of Books - Must be the same as primary set of books.
9- Enable Budgetary Control - You cannot enable for reporting sets of books.
10- Require Budget Journals - Same as primary set of books if you want to require that budget journals be used to enter budget amounts in your reporting set of books.

[ In some circumstances, you may want to use the same functional currency for both your primary and reporting sets of books. For example, for financial or currency management. You can apply different revaluation options in the primary and reporting sets of books, providing different financial information for each set of books.]

Step 4 - Assign Reporting Sets of Books to Primary Set of Books: Use the Assign Reporting Sets of Books window to assign each reporting set of books to its related primary set of books. Note the following rules:
1- You can assign up to eight reporting sets of books to a single primary set of books. Most organizations will find no need to assign more than three.
Caution: If you need to assign more than three reporting sets of books to a primary set of books, be aware that each additional assignment will have an incremental impact on your system's performance and disk space consumption.

2- You can assign the same reporting set of books to more than one primary set of books, provided they all have the same calendar and chart of accounts. You might want to do this if you need to consolidate transactions from multiple primary sets of books (with the same or different functional currencies) into the same reporting currency.

3- You cannot assign a primary set of books to another primary set of books, or to a reporting set of books.

4- If you use combined basis accounting in Oracle Payables, you only need to assign the related reporting set of books to your Payables primary set of books in this step. The relationship for the Payables secondary set of books will be made in the next step when you define the Payables conversion options.

To assign a reporting set of books to a primary set of books:
1. Navigate to the Assign Reporting Set of Books window.
2. Select your primary set of books from the list of values. The set of books' functional Currency, Chart of Accounts, and accounting Calendar will be displayed.
Note: Only those sets of books that have been defined as a primary set of books will be included in the list of values.
3. From the list of values in the Reporting Set of Books region, select the reporting set of books that you want to assign to the primary set of books. The reporting set of books' functional currency will be displayed.
Only those sets of books that have been defined as a reporting set of books will be included in the list of values.
4. Choose the Conversion Options button to define conversion options for each combination of Oracle Application and operating unit for which you want to convert transactions to your reporting functional currency for this reporting set of books.
5. Save your work.
6. Repeat the previous three steps for each reporting set of books you want to assign to the primary set of books.

Step 5 - Define Conversion Options for Each Application For each reporting set of books assignment you make, you must define conversion options for each combination of Oracle Application and operating unit for which you want to convert transactions to your reporting functional currencies. You can set conversion options for these applications:
· General Ledger
· Assets
· Payables
· Receivables
· Projects
· Purchasing

When you use Oracle Applications' Multiple Organizations feature with Payables, Receivables, Purchasing, or Projects, you need to define your MRC conversion options at the operating unit level.
For Assets, you define conversion options at the Asset Book level. For General Ledger, you define conversion options at the application level only.
Conversion options you can set include the reporting conversion type, the action to take when a conversion rate cannot be found, and the range of effective dates for which transactions should be converted to reporting currencies. Also, you need to set some application specific options, such as
Oracle Assets: specify the Asset Book (depreciation book).
Oracle Payables: optionally specify the AP Reporting Secondary Book if you use combined basis accounting.
General Ledger: specify GL Conversion Rules, which control journal conversion at the journal source and category level.

To assign conversion options to Oracle Applications:
1. From the Assign Reporting Set of Books window, choose the Conversion Options button. The Conversion Options window will appear, displaying your primary and reporting set of books information.
2. Select Operating Units/Books from the poplist.
3. In the region below the poplist, select the application for which you want to define conversion options.
4. Enter your operating units/books information.
5. Choose Conversion Options from the poplist. The Conversion Options alternative region will appear.
6. Enter your conversion options.
7. Save your work.

Operating Units/Books Information:
1- Operating Unit: For Payables, Receivables, Purchasing, or Projects, specify the operating unit for which your conversion options apply. This allows you to define different conversion options for each operating unit. Also, if you don't want an operating unit's transactions converted to your reporting currencies, you can choose to omit that operating unit when you define the conversion options for the related application.
2- Asset Book: For Assets, specify the asset depreciation book for which your conversion options apply. The asset depreciation book can be either a corporate book or a tax book. You can associate multiple asset depreciation books to a reporting set of books.

The asset depreciation book you specify must be linked to your primary set of books.
AP Reporting Secondary Book: For Payables, enter the AP Reporting Secondary Book if you use combined basis accounting and want your Payables secondary set of books transactions to be converted to your reporting currencies.

Conversion Options
1- Reporting Conversion Type: The conversion rate type MRC uses to retrieve exchange rates for converting transactions to your reporting currency. This differs from the conversion rate type you specify when you enter a transaction. Oracle Applications use the transaction conversion rate type to retrieve exchange rates for converting entered amounts from the transaction currency to your primary functional currency (alternatively, you can specify your own rate).
- You must enter a Reporting Conversion Type when defining conversion options for your subledger applications, such as Payables and Receivables.
- For General Ledger, the reporting conversion type is set for specific combinations of journal source/category on the GL Conversion Rules window.
- For the reporting conversion type, you can specify your own conversion rate type or choose one of the predefined rate types. To specify your own, you must first define it in General Ledger.

2- No Rate Action: Determines the action MRC should take if it cannot find a rate for converting transactions to your reporting functional currency, for the reporting conversion type as of the conversion date.

For General Ledger, the No Rate Action field is set for specific combinations of journal source/category on the GL Conversion Rules window.

You can select one of two options:
1- Report Error: If MRC cannot find an exchange rate for converting to the reporting functional currency, you will receive an error when you try to save the transaction.
2- Use Last Rate: If MRC cannot find an exchange rate for converting to the reporting functional currency, it retrieves the most recently entered exchange rate. If MRC cannot find a stored exchange rate, you will receive an error when you try to save the transaction.

- If you do not enter a value for the No Rate Action field, it defaults to Use Last Rate.

- When searching for the exchange rate, MRC will only look backwards the number of days specified in the profile option, MRC: Maximum Days to Roll Forward Conversion Rate. If you have not specified an entry for the profile option, MRC will search back as far as the first entered exchange rate.

3- Effective Dates -- From/To: The range of effective dates for which you want to convert transactions to your reporting functional currency for the specified:
- Application and operating unit for Receivables, Payables, Purchasing, and Projects
- Application and Asset Book for Assets
- Application only for General LedgerYou must enter a From date, which is the first date for which MRC will convert transactions.

* If you specify a To date for Assets or Projects, the Application will immediately stop converting transactions to your reporting currencies. This happens regardless of the To date you specify, even if it is a future date.

4- Changing Conversion Options: You cannot delete conversion options once you save them. You can, however, change some of them, depending on the application to which they apply:

a) All applications: You can change the effective dates any time. Note that the changes are effective immediately, but that they apply only to new transactions. The change has no effect on previously entered transactions.

* We strongly recommend you do not change effective dates once you begin using MRC. Changing the effective dates may result in inconsistent transaction amounts and balances in your reporting sets of books.

b) All applications except General Ledger: You can change the Reporting Conversion Type and the No Rate Action values any time. Note that the changes are effective immediately, but that they apply only to new transactions. The change has no effect on previously entered transactions.

c) Payables: You can change the AP Reporting Secondary Book. The change is effective immediately, but applies only to new transactions. The change has no effect on previously entered transactions.

* We strongly recommend you do not change the AP Reporting Secondary Book once you begin using MRC. Changing the AP Reporting Secondary Book may result in inconsistent transaction amounts and balances in your AP Reporting Secondary Book.

Step 6 - Define General Ledger Conversion Rules: When you use MRC with General Ledger, you need to define conversion rules in addition to the effective dates you specify for General Ledger's conversion options in the previous step. Conversion rules control journal conversion at the journal source/category level.
You can define conversion rules for all predefined journal sources except these:

a) Revaluation, Move/Merge, and Move/Merge Reversal -- MRC will not convert journals that have these journal sources. Instead, you need to run each of these processes in both your primary and reporting sets of books.

b) Receivables, Assets, Projects, AX Payables, and AX Receivables -- MRC converts transactions from these sources directly in the subledgers and stores the related reporting currency amounts in those subledgers.Note that GL Conversion Rules for the Payables and Purchasing journal sources are applied only to encumbrance journals. MRC will not convert actual journals that have these journal sources assigned.

To assign conversion rules to General Ledger:
1. From the Conversion Options window, select the Oracle General Ledger entry from the region below the poplist, then choose the GL Conversion Rules button.
2. Mark the Convert check box if you want journals with the specified journal source and category to be converted to your reporting currency. Leave the check box unmarked if you do not want journals with the specified journal source and category to be converted.
3. Enter the journal source and category for which you want to set conversion rules.
Note: You can enter a specific journal source or category or enter Other to select a source or category other than those you have specifically defined.
4. Select the Reporting Conversion Type and No Rate Action to use when converting journals with the specified journal source and category.
5. Save your work.

Journal Source/Category Combinations MRC uses the journal source and category combinations you define in your GL conversion rules to determine if a journal should be converted.

When you post journals in your General Ledger primary set of books, MRC notes each journal's source and category as it is posted. MRC then searches your defined conversion rules for a matching source and category combination. MRC searches the conversion rules in the following order, regardless of the order you entered the rules on the GL Conversion Rules window:

Search Order - Journal Source - Journal Category
1 - Specific source - Specific category
2 - Specific source - Other
3 - Other - Specific category
4 - Other - Other

If MRC finds a matching source/category combination, it notes the reporting currency type and checks to see if transactions with the identified source/category combination are to be converted. If they are to be converted, MRC converts the journal amount to the reporting currency and creates the converted journal in the reporting set of books. Otherwise, the journal is not converted and the next journal in the posting batch is processed.

* If MRC cannot find a matching source/category combination, or if you have not defined any GL conversion rules, the journal will not be converted.

Below are three examples that illustrate how journals are converted based on different conversion rules.

Example Assumptions -
Journal Source - Journal Category
Journal #1 - Manual - Adjustment
Journal #2 - Consolidation - Consolidation
Journal #3 - Manufacturing -Freight
Journal #4 - Spreadsheet - Adjustment
Journal #5 - Manufacturing - Labor Cost

Example 1

The following six conversion rules are defined:
Source ----------- Category - Convert ------ Result
Manual ----------Adjustment --Yes ---Journal #1 is converted, using the defined conversion options for this combination.
Consolidation --- Consolidation -- No --- Journal #2 is NOT converted.
Other --- Freight -- Yes --- Journal #3 is converted, using the defined conversion options for this combination. (i.e., All journals with category Freight are converted).
Spreadsheet --- Reclass -- Yes --- No journals in the example match this combination. (All journals with source Spreadsheet and Category Reclass are converted, using the defined conversion options for this combination.)
Spreadsheet --- Other -- No --- Journal #4 is NOT converted. (i.e., All journals with source Spreadsheet (except those with category Reclass) are NOT converted.)
Other --- Other -- Yes --- Journal #5 is converted, using the defined conversion options for this combination.

Example 2
The following three conversion rules are defined:
Source --- ------- Category -- Convert --- Result
Manufacturing --- Freight --No ---Journal #3 is NOT converted. (i.e., All journals with source Manufacturing and category Freight are NOT converted.)
Manufacturing --- Other -- Yes --- Journal #5 is converted. (i.e., All journals with source Manufacturing are converted, except those with category Freight.)
Other ---Other -- Yes --- Journals #1, 2, and 4 are converted, using the defined conversion options for this combination.

Example 3
The following two conversion rules are defined:
Source --- Category -- Convert --- Result
Manufacturing -- Freight -- No --- Journal #3 is NOT converted. (i.e., All journals with source Manufacturing and category Freight are NOT converted.)
Manufacturing --- Other -- Yes --- Journal #5 is converted. (i.e., All journals with source Manufacturing are converted, except those with category Freight.)

* In this example, Journals #1, 2, and 4 are NOT converted, since there is no conversion rule defined with a source of Other and a category of Other.

Changing Conversion Rules: You can delete General Ledger conversion rules at any time. You can also change a conversion rule as needed. For example, for any journal source/category combination, you can change the Convert option, Reporting Conversion Type, and No Rate Action value. Note that the changes are effective immediately, but that they apply only to new journals. The change has no effect on previously entered journals.

Step 7 - Define Reporting Responsibilities: You or your system administrator must define your organization's MRC reporting responsibilities before anyone uses MRC. The purpose of these reporting responsibilities is to provide the appropriate level of access your users need to perform their inquiry and reporting activities in your reporting currencies.

A responsibility is a level of authority in Oracle Applications that lets users access only those Oracle Applications functions and data appropriate to their role in an organization. Each responsibility allows access to a specific application or applications, a set of books, a restricted list of windows, a restricted list of functions, and reports in a specific application.

1- This step is generally performed by a system administrator.
2- The responsibilities you define in this step should be used for inquiry and reporting purposes only. Day-to-day activities, such as creating purchase orders or invoices, should be performed using your standard subledger responsibilities.
3- This step applies only to your Oracle Applications subledgers and not to General Ledger. For example, you may need to define a Payables reporting responsibility and a Purchasing reporting responsibility.
4- Oracle provides predefined MRC responsibilities as examples you can use to set up your organization's reporting responsibilities.

Responsibilities Window: Use the Responsibilities window to define your MRC reporting responsibilities.

When you define your reporting responsibilities, follow the guidelines below for completing the fields on the Responsibilities window:
Data Group Name: Select the name of the data group you defined earlier when you installed MRC.
Menu: Enter the name of the MRC menu for the product for which you are defining the reporting responsibility. To use the related predefined MRC menu, select the MRC menu for your product from the list of responsibilities. Pre-defined MRC menus are in the format _MRC_NAVIGATOR_GUI.
Most of the predefined product-specific MRC menus allow users to access only the product's inquiry functions and windows. For some products, other functions and windows are also accessible. For example, Assets users can run depreciation in both the primary and reporting sets of books.

* We strongly recommend that you use the predefined product-specific MRC menus provided by Oracle, rather than creating a custom menu. If you choose to create a custom menu, we suggest that you start by making a copy of the related predefined menu, then make any custom changes to the copy.
Your custom menu should not allow users to access any windows or functions that are not already included in the predefined MRC menu. Any other windows or functions you add to your custom menu will not function properly when accessed by users.

Request Group Name: Enter the name of the MRC request group for which you are defining the reporting responsibility. To use the related predefined MRC request group, select the request group from the list of values. Pre-defined MRC request groups are in the format MRC Programs .
The predefined MRC request groups allow users to access only those reports and programs that are appropriate to run when using an MRC reporting responsibility.
To use a custom request group, enter the name you gave to that request group when you defined it.

* We strongly recommend that you use the predefined MRC request groups provided by Oracle, rather than creating a custom request group. If you choose to create a custom request group, we suggest that you start by making a copy of the related predefined request group, then make any custom changes to the copy.

Your custom request group should not allow users to access any programs that are not already included in the predefined MRC request group. Any other programs you add to your custom request group will not function correctly when accessed by users. You can include any report in your custom request group, however, those reports which are not already included in the predefined request group will not display reporting currency amounts.

Step 8 - Assign Reporting Sets of Books to Reporting Responsibilities: You or your system administrator must assign a reporting set of books to each of the reporting responsibilities defined in the previous step. This ensures that anyone using the reporting responsibility has access to the correct subledger reporting currency amounts.

* This step is generally performed by a system administrator.

To create the association between a reporting responsibility and a reporting set of books, set the following two profile options to the reporting set of books name at the responsibility level for each of your reporting responsibilities:
- GL: Set of Books Name
- MRC: Reporting Set of Books

MRC Conversion Business Rules
When you enter transactions in Oracle Applications that support MRC, they are converted, as needed, into your primary functional currency and each of your reporting functional currencies, as follows:

1-Primary functional currency transactions: All transactions denominated in your primary functional currency are recorded in this currency. MRC converts the transactions automatically to each of your reporting currencies.
2- Foreign currency transactions: Transactions denominated in a foreign currency are converted automatically to your primary set of books' functional currency. MRC converts the transactions to each of your reporting currencies.MRC generally converts from the transaction currency to your reporting currencies. In some cases, MRC converts from the primary functional currency to your reporting currency. We discuss the reporting currency conversion rules in the next section.

Reporting Currency Conversion Rules Reporting currency conversion rules differ depending on whether the exchange rate relationship between a transaction and reporting currency is variable or fixed. When there is a variable relationship, the exchange rate between the two currencies fluctuates. When there is a fixed relationship, the exchange rate between the two currencies remains constant, having been fixed at a specific point in time.

* As of January 1, 1999, the national currencies of countries who are members of the European Monetary Union (EMU) will become another denomination of the Euro, the pan-European currency. Fixed exchange rates will be used between the Euro and each EMU currency.

Conversion Rounding: MRC rounds converted and accounted amounts using the same rounding rules used throughout Oracle Applications products. MRC also considers several factors that are a part of all the currencies predefined in Oracle Applications, including:
Currency Precision: the number of digits to the right of the decimal point used in regular currency transactions.
Extended Precision: the number of digits to the right of the decimal point used in calculations for the currency.
Minimum Accountable Unit: the smallest denomination used in the currency. Note that this might not correspond to the precision.

MRC Implementation Considerations:

1- Type of Installation: Different issues arise when you implement MRC for a new Oracle Applications installation versus enabling MRC after upgrading from an earlier version of Oracle Applications.

2- MRC Starting Dates: Determine appropriate dates to use for initializing account balances in your reporting sets of books and for entering back-dated subledger transactions.

3- Initializing Account Balances in Reporting Sets of Books: Initialize the beginning account balances in your reporting sets of books. You must also choose an initializing method.

4- Translation versus MRC: Discusses the differences between General Ledger's Translation feature and MRC.

1- Type of Installation: The initial release of MRC supports two specific types of installation:
A) Fresh Install: New customers who install Oracle Applications for the first time and enable MRC.
* For Oracle subledger applications that support MRC, you must enable MRC before entering any transactions in the subledgers. There is no such restriction for General Ledger.
B) Upgrade Scenario 1: Existing customers who upgrade from an earlier release of Oracle Applications, then enable MRC.

For Oracle subledger applications that support MRC, you must enable MRC in:
1- A new set of books or
2- A new operating unit in an existing set of books
before entering any transactions in the subledgers. There is no such restriction for General Ledger.

Following the initial release of MRC, a planned patch will support a second upgrade scenario:
C) Upgrade Scenario 2: Existing customers who upgrade from an earlier release of Oracle Applications, then enable MRC for an existing set of books or operating unit when there are open transactions in subledgers that support MRC.

* An open transaction is a subledger transaction whose accounting lifecycle has not been completed. For example, a receivables invoice for which you have not received payment from the customer, a payables invoice which you have not paid, or a project that has an open status.

Following the patch, a planned maintenance release for MRC will support a third upgrade scenario:
D) Upgrade Scenario 3: Existing customers who upgrade from an earlier release of Oracle Applications, enable MRC, and want to convert historical transaction amounts in their subledgers to their reporting currencies.

Notes:
1- For both Fresh Install and Upgrade Scenario 1, if you enter transactions in a subledger before enabling MRC, there will be open transactions when MRC is enabled. Any subsequent entries related to the open transactions (e.g., credit memos, receipts, payments, or project expenditure adjustments) that occur after MRC is enabled will not be converted to reporting currencies and may cause an error condition.
To avoid this situation, you must install the planned patch when it becomes available, then convert the open transactions to your reporting currencies.

2- If you are an existing customer upgrading from an earlier release of Oracle Applications and you have no open transactions in subledgers that support MRC, you can enable MRC for those subledgers without creating a new set of books or operating unit.

Warning: Do not reopen closed transactions if you have enabled MRC without creating a new set of books or operating unit.

2- MRC Starting Dates:
You need to determine appropriate dates for two important MRC starting dates:
1- Logical Effective Date: The date on which you initialize the account balances in your reporting sets of books.
2- From Date: The first date for which MRC will start converting transactions to your reporting functional currency. You enter the from date on the Conversion Options window.

* In determining which transactions or journals to convert, MRC compares the from date to the:
a) Transaction or journal date for Payables, Receivables, and General Ledger
b) Entered date for Purchasing, Assets, and Projects

When the from date precedes or is the same as the date being compared, MRC converts the transaction or journal.

1- Choosing a Logical Effective Date: Choosing a logical effective date is basically a business decision you must make for your organization. This decision is based primarily on your determination of when you want to start inquiring and reporting on transactions and balances in your reporting currencies.
It is recommended that you choose a logical effective date that falls on the first day of your first MRC period. In addition:
- Your first MRC period should be one for which you have not entered any transactions.
- Your first MRC period should be the first period of a quarter to ensure that the quarter-to-date reporting currency balances for the quarter in which you enable MRC are correct.
- If you use average balance processing and need to report average balances in your reporting sets of books, choose a logical effective date that is the first day of a fiscal year. This ensures that your period-average-to-date, quarter-average-to-date, and year-average-to-date reporting currency balances will be correct.

2- Choosing a From Date: Choosing an appropriate from date differs depending on the application for which you are setting the date. The considerations are the same for General Ledger, Payables, Receivables, and Purchasing. For Assets and Projects, the from date is determined automatically.

General Ledger, Payables, Receivables, and Purchasing and Assets: When setting the from date, you should choose a date that precedes the logical effective date and which is early enough to allow you to enter back-dated subledger transactions without adversely affecting the account balances in your reporting sets of books. We recommend that you choose a date that precedes the date of the first transaction in each application/operating unit (application only for General Ledger).

* Back-dated subledger transactions are those whose transaction dates precede the logical effective date.
If the from date is not sufficiently early, any back-dated transaction whose accounting date precedes the from date will not be converted by MRC to your reporting currencies.

Warning: Do not inquire or report on reporting currency balances from your subledgers for dates that fall in the intervening period between the from date and the logical effective date. Since the beginning balances in your reporting set of books will not yet be initialized, the reporting currency account balances will not be correct for this intervening period. However, the reporting currency amounts of any back-dated transactions that occur during the intervening period will be correct.

For Oracle Assets, the from date is set automatically at the time you assign the Assets conversion options on the Assign Reporting Set of Books window. MRC sets the from date to the Oldest Date Placed in Service value that you've entered in the Assets' System Controls window. You cannot update the from date.

3- Initializing Account Balances in Reporting Sets of Books: You must initialize the beginning balances in your reporting sets of books before you can inquire and report on account balances in your reporting currencies. The steps in this section explain how to initialize your account balances.

First MRC Period: The first accounting period for which you want to be able to report transactions and balances in your reporting currencies. You must enable MRC and initialize your reporting sets of books' beginning account balances before the first MRC period.

Initial Period: The accounting period preceding the first MRC period.
Note: During the process of initializing account balances in your reporting sets of books, you should not post any new journals.

Step 1 Post in the Primary Set of Books
We recommend that you post all outstanding transactions in your primary set of books at the end of the initial period. This includes posting:
(For Upgrade Scenarios 2 and 3) All subledger transactions to General Ledger.
Caution: Do not enter any new transactions in subledgers that support MRC until you complete setting up MRC.
All journals in General Ledger.Posting all outstanding transactions and journals ensures that the ending account balances in your primary set of books are up to date.

Step 2 Close the Initial Period in Primary Set of Books
In General Ledger, close the initial period in your primary set of books to ensure that new transactions will not update the account balances.

Step 3 Open the Initial Period in Reporting Sets of Books
Before you initialize account balances in the next step, make sure you have opened the initial period in General Ledger in your reporting sets of books.

Step 4 Initialize Balances
You can use several methods to initialize the balances in your reporting sets of books:
1- Translation & Consolidation: Translate the balances in your primary set of books then consolidate them into your reporting sets of books.
2- Import Beginning Balances: Use General Ledger's Journal Import feature to import your beginning balances from an external source.
3- Manual Journals: Use General Ledger's Enter Journals window to manually enter your beginning balances.

If you decide to use the translation and consolidation method to initialize your reporting sets of books' account balances, complete the three steps below for each reporting set of books:
1. Translate Balances.
Run General Ledger's Translation feature to convert balances from your primary functional currency to the appropriate reporting functional currency.
Suggestion: For convenience, you can translate your balances to all of your reporting currencies at the same time.

2. Consolidate to Reporting Set of Books.
Use General Ledger's Global Consolidation System to consolidate the translated balances from your primary set of books to your reporting set of books.

3. Post Consolidation Journals in your reporting set of books.
Posting the consolidation journals updates the balances in your reporting set of books.

Step 5 Close the Initial Period in Reporting Sets of Books
Close the initial period in your reporting sets of books. This is necessary before the initial period's ending balances can be used to create the beginning balances of your first MRC period.

Step 6 Opening the First MRC Period
For General Ledger, open the first MRC period in both your primary and reporting sets of books. This will automatically create your beginning account balances for the first MRC period.
In your subledgers that support MRC, open the first MRC period only in your primary set of books. The same period will be opened automatically in your reporting sets of books.

4- Translation versus MRC: General Ledger's translation feature is used to translate amounts from your functional currency to another currency at the account balances level. MRC converts amounts from your transaction currency to a reporting currency at the transactions level.

MRC is specifically intended for use by organizations that must regularly and routinely report their financial results in multiple currencies. MRC is not intended as a replacement for General Ledger's Translation feature. For example, an organization with a once-a-year need to translate their financial statements to their parent company's currency for consolidation purposes, but no other foreign currency reporting needs, should use General Ledger's standard translation feature instead of MRC.

Another benefit of MRC over General Ledger's Translation feature is that with MRC you can inquire and report on transaction amounts in your reporting currencies directly from your subledgers. Translation only applies to General Ledger -- it cannot be used to translate transaction amounts in your subledgers.

If you use MRC and have properly initialized your reporting set of book's balances, you can report directly from your reporting sets of books without running Translation. This is because the actual transaction amounts in your reporting sets of books have already been converted from your primary set of book's functional currency. As a result, the account balances of your reporting set of books are automatically maintained in your reporting currency.
For example, to consolidate a subsidiary that maintains a reporting set of books using your parent company's functional currency, you might simply consolidate the reporting set of books to your parent set of books, rather than translating, then consolidating the subsidiary's primary set of books.

Usually, when you compare the results of using amounts from your reporting set of books rather than translated primary set of book's amounts, there will be rounding differences in your accounts. Many of these differences arise because a reporting set of book's transaction amounts are converted using daily rates. Translation, however, uses period or historical rates to translate account balances.

Before you use your reporting set of book's amounts in lieu of translating your primary set of book's amounts, you need to understand and carefully consider:
- How MRC works.
- The country-specific accounting rules and regulations that govern your parent and subsidiary companies.

Note About Budget Balances: If you use MRC and need to report budget amounts in your reporting currency, you will need to translate the budget amounts in your primary set of books to your reporting currency.
For example, after translating budget amounts to your reporting currency, you can use FSG to create a budget variance report with three columns:
a) Translated budget amounts. Your FSG column set can draw these amounts directly from your primary set of books.
b) Reporting currency actual amounts. Your FSG column set can draw these amounts from your reporting set of books.
c) The variance between budget and actual, expressed in your reporting currency.

Receivables Tax

2007-11-12T16:15:00.000+05:30

You can set up Receivables to use one of three basic types of tax:

1- Value Added Tax (VAT),

2- US Sales Tax, or

3- Canadian Sales Tax.

VATValue Added Tax (VAT) is imposed on the supply of goods and services paid for by the consumer, but collected at each stage of the production and distribution chain. The VAT charged on a customer invoice is called Output Tax. Any VAT paid on a vendor invoice is called Input Tax. The amount due each period can be described as follows:
Amount Due = Output Tax - Input Tax

Receivables provides a comprehensive solution for VAT reporting using standard and country-specific reports.

Sales Tax: Sales tax in Receivables is based on the destination of the supply of goods or services. The calculation of sales rates is automatic, and is based on the state, county, city, and zip code of your customer's address and the tax rates assigned to each of these components. You can override any tax rate through customer and product exemptions and you can compile periodic sales tax returns using the US Sales Tax Report.
You can import address validation and sales tax rates from your tax vendor and use the Tax Vendor Extension to integrate external tax calculation programs with Receivables and Oracle Order Entry.

Canadian Sales Tax: Canadian sales taxes exist at both the federal and the provincial level. Sales tax at the federal level, which is referred to as Goods and Services Tax (GST), is standard across Canada. Some goods and services are exempt from GST.
Provincial Sales Tax (PST) is levied by each Canadian province except Alberta and the Territories. Each province has its own legislation which determines the PST rate and decides which goods and services are exempt from PST. The appropriate Provincial Sales Tax is based upon the destination of the goods or services, not their origin.

Country Specific VAT Reporting

In many countries, the standard VAT reports described in this book will cover your VAT reporting requirements.

Implementing Value Added Tax

VAT is imposed on the value added to goods or services at each stage of their supply. The VAT charged on a customer invoice is referred to as Output Tax. Any VAT paid on a vendor invoice is referred to as Input Tax.

The amount due each period can be described as follows:
Amount Due = Output Tax - Input Tax

Not all businesses are required to collect and remit Value Added Tax. To determine your legal obligations in the collection and reporting of Value Added Tax, seek the advice of a qualified tax professional.

[ If you use the Oracle Applications Multiple Organization Support feature, you need to perform this implementation for each of your operating units. For more information, refer to the Multiple Organizations in Oracle Applications manual.]

You can use the Implementation Wizard as a resource center to read online help for a setup activity and open the appropriate setup window and to see a graphical overview of setup steps. You can also document your implementation by using the Wizard to record comments for each step for future reference and review.

Major Features of VAT Receivables lets you control and automatically record VAT charges on your receivable invoices. Using Receivables you can:
- Control VAT using both the inventory item and destination country (item method).
- Optionally control VAT from your Revenue Account (account method).
- Automatically calculate VAT for domestic, import, and intra-EU taxed transactions.
- Automatically calculate and account for multiple VAT regimes, levying additional taxes such as Surcharges, Excise, and Sales Equalization taxes as required.
- Compile your periodic VAT returns using a comprehensive set of standard and country-specific VAT reports.
- Easily integrate your implementation of VAT with Oracle Order Entry, Oracle Sales and Marketing, and your legacy systems.
- Round VAT amounts at the Transaction Header or Line Level.
- Round VAT Amounts Up, Down, or Nearest, to a different precision and minimum accountable unit.
- Calculate inclusive or exclusive VAT Amounts.
- Print transactions inclusive or exclusive of VAT.
- Import transactions using AutoInvoice with inclusive or exclusive taxes.
- Allow VAT to be controlled in Receivables or your feeder system.
- Control changes in rate for any given tax code over time.
- Exempt customers and sites from VAT.
- Ensure that your VAT returns are complete.
- Manually defer Output Tax liability on unpaid invoices using the VAT Reconciliation Report.

Acquisition Tax: VAT on the acquisition of goods from a VAT Registered supplier in another EU member state will be zero-rated. The receiver must account for VAT as both Input and Output amounts at the VAT rate applicable for the same goods in the country that they are received, giving a net VAT liability of zero. Oracle Implements Acquisition tax with Oracle Payables using Offset Taxes.

Deferral: France, Italy and Russia allow the liability on Output VAT to be deferred until payment has been collected on certain transactions. This is referred to as "Cash accounting for VAT" and, if allowed, may be used in an accrual system.

Document Rounding: VAT amounts are typically calculated once per tax code within an invoice. Receivables controls tax codes at the document line, but allows VAT amounts to be rounded at the document header or line.

Domestic Transaction: Transactions between registered traders in the same EU (European Union) country. Domestic transactions have VAT charged on goods and services with different countries applying different VAT rates to specific goods and services.
EU: The European Union is a single European market where customs and tariff barriers between member states have been removed.

Input VAT: The tax charge on the receipt of taxable goods and services (e.g. tax on supplier invoices or expense items). Input VAT should be reported wherever you account for expenditures. Input VAT is usually deductible.

Intra-EU, Taxed Transactions: Transactions between non-registered traders in different EU (European Union) countries. VAT must be charged to customers within the EU if you do not know their VAT registration number. The destination country and inventory item controls which VAT rate to use.

Intra-EU, Zero-Rated Transactions: Transactions between registered traders in different EU (European Union) countries. An Intra-EU transaction is zero rated if and only if you know the customer's VAT registration number; otherwise, VAT must be charged on the invoice.

Japanese Consumption Tax: The Value Added Tax (VAT) paid on any expense (Input VAT) is usually recoverable against the VAT Charged on revenue (Output VAT). This ensures that VAT is not inflationary within a supply chain.

Natural Account: The segment of your accounting flexfield that you assign the qualifier 'Natural Account'. This segment indicates whether the Accounting Flexfield is an Asset, Liability, Equity, Revenue, or Expense account. In Receivables, the Natural Account typically identifies the Revenue account.

Non-Deductible Input VAT: The VAT amount paid on expense items that may not be reclaimed against Output VAT. Usually, all items purchased for a business are deductible. Certain high value purchases, (for example, luxury cars for an executive's spouse) may be considered non-deductible. For small companies, service or items of value to both the owner and business may be partially non-deductible.

Output VAT: The tax charge on the supply of taxable goods and services (e.g. tax on customer invoices or revenue items). Output VAT should be reported wherever you account for sales.
Recargo de Equivalencia: An additional tax levied in Spain on specific types of businesses. The rate of tax is related to the primary rate of VAT for the item sold.

Tax Engine: A collection of programs, user defined system parameters, and hierarchical flows used by Receivables to calculate tax.

VAT Classification: Each country classifies VAT into a small number of rates. Following are the five basic classes of VAT:
- Standard: The majority of transactions are classified at a Standard rate. In Europe, the Standard rate of VAT varies between 12-25%.
- Reduced: A lower rate of tax for specific goods or services. For example, within the EU, the reduced rate is applied to consumption of domestic fuel and power.
- Luxury: A higher than standard rate of tax, normally applied to a very limited set of goods or services.
- Zero: Zero-rated, gross sales are reported separately from exempt rated transactions.
- Exempt: Exempt from VAT. Gross sales are reported separately from zero-rated transactions.VAT Regime: A set of VAT rules and rates applicable to a well defined set or type of transactions. In Europe, the most common VAT regimes are Domestic, Import, and Inter-EC. However, many countries have additional regimes for special geographical regions or types of businesses.

Setup Checklist for Value Added Tax

Complete the following steps in the order shown to implement Value Added Tax in Receivables:
Step 1: Choose Tax Method for VAT Compliance
Step 2: Define Tax Codes and Rates
Step 3: Set Up Account Method VAT (optional)
Step 4: Set Up Tax Groups for Distance Sales (optional)
Step 5: Set Up Item Method VAT
Step 6: Choose a Sales Tax Location Flexfield Structure
Step 7: Define Tax Preferences
Step 8: Set Up Tax Defaults and Rules
Step 9: Assign a Default Application Rule Set
Step 10: Save System Options
Step 11: Define Tax Exemptions
Step 12: Define Transaction Types
Step 13: Define AutoAccounting for Tax
Step 14: Enable Calculation of VAT on Freight
Step 15: Define Tax Profile Options
Step 16: Define VAT Reconciliation Report Set

AutoInvoice Interface Tables

2007-11-11T17:39:00.000+05:30

1- RA_INTERFACE_LINES
2- RA_INTERFACE_SALESCREDITS
3- RA_INTERFACE_DISTRIBUTIONS
4- RA_INTERFACE_ERRORS

Receivables uses these tables to temporarily store transaction data from your original system. The fourth table, RA_INTERFACE_ERRORS is only used by AutoInvoice to store information about interface data that failed validation.

RA_INTERFACE_LINES

This table stores information about your transaction lines. AutoInvoice uses Transaction Flexfields to uniquely identify each transaction that you import into Receivables. AutoInvoice always uses the Line Transaction flexfield structure for both the Link-to and Reference information when importing invoices.

1- ACCOUNTING_ RULE_DURATION : Enter the accounting rule duration for this transaction. If LINE_TYPE = 'LINE' or you are passing header freight, and this transaction uses a variable duration accounting rule, you must enter a value in this column. If LINE_TYPE = 'TAX' ', 'CHARGES' or you are passing freight for a specific line, do not enter a value in this column. For credit memos and on-account credits, do not enter a value in this column.
Validation: Accounting periods must be defined for the duration of the accounting rule in GL_PERIODS and RA_INTERFACE_LINES.GL_DATE and RA_INTERFACE_LINES.RULE_START_DATE must be in a period that has a status of 'Open' or 'Future'. The value in this column must be a positive integer.
Destination: RA_CUSTOMER_TRX_LINES.ACCOUNTING_ RULE_DURATION

2- ACCOUNTING_ RULE_ID : Enter the accounting rule id for this transaction. If LINE_TYPE = 'LINE' or you are passing header freight, this column is optional. For invoice lines with rules, you must enter either a value in this column or in ACCOUNTING_RULE_NAME, depending on the value you entered for your batch source. If you entered a value in ACCOUNTING_RULE_NAME, AutoInvoice defaults a value in this column. If LINE_TYPE = 'TAX', 'CHARGES' or you are passing freight for a specific line, do not enter a value in this column. For credit memos, do not enter a value in this column; AutoInvoice uses the accounting rule from the transaction you are crediting.
Validation: Must exist in RA_RULES.RULE_ID and RA_RULES.TYPE = 'A' or 'ACC_DUR'. If LINE_TYPE = 'CHARGES', then this column must be null.
Destination: RA_CUSTOMER_TRX_LINES.ACCOUNTING_ RULE_ID

3- ACCOUNTING_ RULE_NAME : Enter the accounting rule name for this transaction. If LINE_TYPE = 'LINE' or you are passing header freight, this column is optional. For invoice lines with rules, you must enter either a value in this column or in ACCOUNTING_RULE_ID, depending on the value you entered for your batch source. If LINE_TYPE = 'TAX', 'CHARGES, or you are passing freight for a specific line, do not enter a value in this column. 7 For credit memos do not enter a value in this column. AutoInvoice uses the accounting rule from the transaction you are crediting.
Validation: Must exist in RA_RULES.NAME and RA_RULES.TYPE = 'A' or 'ACC_DUR'. If LINE_TYPE = 'CHARGES', then this column must be null.
Destination: None

4- ACCTD_AMOUNT : Do not enter a value. Receivables does not currently use this column.
Validation: None
Destination: None

5- AGREEMENT_ NAME : Enter the name of the customer agreement for this transaction. If LINE_TYPE = 'LINE', 'CHARGES' or you are passing header freight, this column is optional. Depending on the value you entered for your batch source, you can enter either a value in this column or in AGREEMENT_ID. For invoice lines against a commitment, AutoInvoice will default the agreement from the commitment if AGREEMENT_NAME and AGREEMENT_ID are null and a agreement exists for the commitment. If LINE_TYPE = 'TAX' or you are passing freight for a specific line, do not enter a value in this column. For credit memos, do not enter a value in this column, AutoInvoice uses the customer agreement from the transaction you are crediting.
Validation: Must exist in SO_AGREEMENTS.NAME
Destination: None

6- AGREEMENT_ ID : Enter the customer agreement id for this transaction. If LINE_TYPE = 'LINE', 'CHARGES' or you are passing header freight, this column is optional. Depending on the value you entered for your batch source, you can enter either a value in this column or in AGREEMENT_NAME. For invoice lines against a commitment, AutoInvoice will default the agreement from the commitment if AGREEMENT_NAME and AGREEMENT_ID are null and a agreement exists for the commitment. If LINE_TYPE = 'TAX' or you are passing freight for a specific line do not enter a value in this column. For credit memos, do not enter a value in this column, AutoInvoice uses the customer agreement from the transaction you are crediting.
Validation: Must exist in SO_AGREEMENTS.ID
Destination: None

7- AMOUNT : Enter the revenue amount for this transaction. If LINE_TYPE = 'LINE' and this transaction is neither a freight-only nor a tax-only line, you must enter a value in this column. If this transaction is a dummy line for freight-only or tax-only, do not enter a value in this column. AutoInvoice ignores any values you enter in this column if this transaction is a dummy line. If LINE_TYPE = 'TAX', a value must be entered in either this column or the tax_rate column. Any exemptions must be factored into either of the two columns. If LINE_TYPE = 'FREIGHT' and you are passing either header freight or freight for a specific line, you must enter a value in this column. If LINE_TYPE = 'CHARGES', do not enter a value in this column. If this line has AMOUNT_INCLUDES_TAX set to Yes, the sales credits and line amounts for this column must include tax. For credit memos and on-account credits, enter the credit amount for this transaction.
Validation: If LINE_TYPE = 'CHARGES', then this column must be null. AutoInvoice will correct revenue amounts that have the wrong currency precision.
Destination: If you are not using suspense, RA_CUSTOMER_TRX_LINES.REVENUE_ AMOUNT and RA_CUSTOMER_TRX_LINES. EXTENDED_AMOUNT. If you are using suspense, RA_CUSTOMER_TRX_LINES. REVENUE_AMOUNT.

8- AMOUNT_INCLUDES_TAX_FLAG : This column controls whether the amount for this transaction line includes tax. If this column is set to 'Y', this line is assigned to a tax inclusive tax code. If this is a tax group, this column should be null. AutoInvoice only uses this column if the tax code assigned to this line has Allow Override set to Yes for the Tax Inclusive calculation.
Validation: If this is a tax code and Allow Override is set to No, this should be equal to either the setting of the Amount Includes Tax option for this tax code or null. Additionally, if Allow Override is set to No the Amount Includes Tax flag at the line level must equal the Allow Override flag for this tax code.
Destination: RA_CUSTOMER_TRX_LINES.AMOUNT_ INCLUDES_TAX_FLAG

9- ATTRIBUTE1-15 : Enter the Descriptive Flexfield attribute information for this transaction. Descriptive Flexfield attributes allow you to store additional columns, the contents of which you define. These columns are optional.
Validation: None
Destination: RA_CUSTOMER_TRX_LINES.ATTRIBUTE1-15

10- ATTRIBUTE_ CATEGORY : Enter the Descriptive Flexfield category information for this transaction. Descriptive Flexfield categories allow you to store different categories of attributes. This column is optional.
Validation: None
Destination: RA_CUSTOMER_TRX_LINES.ATTRIBUTE_ CATEGORY

11- BATCH_SOURCE_ NAME : Enter the name of the batch source for this transaction. AutoInvoice uses your batch source to determine your transaction and batch numbering method and your AutoInvoice processing options. You must enter a value in this column.
Validation: Must exist in RA_BATCH_SOURCES.NAME and RA_BATCH_SOURCES.BATCH_SOURCE_TYPE = 'FOREIGN'
Destination: RA_BATCHES.BATCH_SOURCE_ID and RA_CUSTOMER_TRX.BATCH_SOURCE_ID

12- COMMENTS : Enter comments about this transaction. If LINE_TYPE = 'LINE', 'CHARGES' or you are passing header freight, this column is optional. If LINE_TYPE = 'TAX' or your are passing freight for a specific line, do not enter text in this column.
Validation: None
Destination: RA_CUSTOMER_TRX.COMMENTS

13- CONVERSION_ DATE : Enter the exchange rate date for this transaction. If you do not enter a date, AutoInvoice uses the transaction date as the default. If the currency of the transaction line is the same as the base currency, then leave this column null.
Validation: None
Destination: RA_CUSTOMER_TRX.EXCHANGE_DATE

14- CONVERSION_ RATE : Enter the exchange rate for this transaction. If CONVERSION_TYPE is User, you MUST enter a value in this column; otherwise do not enter a value. If the currency of the transaction is the same as the base currency, enter 'User' and set CONVERSION_RATE to 1.
Validation: If RA_INTERFACE_LINES.CONVERSION_TYPE = 'User' then this column must not be null; otherwise, it must be null.
Destination: RA_CUSTOMER_TRX.EXCHANGE_RATE

14- CONVERSION_ TYPE : Enter the exchange rate type for this transaction. If the currency of the transaction is the same as the base currency, enter 'User' and set CONVERSION_RATE to 1. You must enter a value in this column.
Validation: Must exist in GL_DAILY_CONVERSION_TYPES. CONVERSION_TYPE
Destination: RA_CUSTOMER_TRX.EXCHANGE_RATE_TYPE

15- CREDIT_METHOD_ FOR_ACCT_RULE: Enter the credit method for crediting a transaction which uses an accounting rule. Choices include PRORATE, LIFO, or UNIT. If this transaction is a credit memo against a transaction which uses an accounting rule and LINE_TYPE = 'LINE', 'CHARGES', or you are passing header freight, you must enter a value in this column. If LINE_TYPE = 'TAX' or you are passing freight for a specific line, do not enter a value in this column. AutoInvoice will ignore any value that you enter in this column. For on-account credits do not enter a value in this column.
Validation: Must be either 'PRORATE', 'LIFO', 'UNIT' or NULL
Destination: RA_CUSTOMER_TRX.CREDIT_METHOD_FOR_ RULES

16- CREDIT_ METHOD_FOR_ INSTALLMENTS : Enter the credit method for crediting a transaction that uses split payment terms. Choices include PRORATE, LIFO, or FIFO. If this transaction is a credit memo against a transaction that uses split payment terms and LINE_TYPE = 'LINE', 'CHARGES', or you are passing header freight, you may enter a value in this column. If you do not enter a value, AutoInvoice defaults to PRORATE. If LINE_TYPE = 'TAX' or you are passing freight for a specific line, do not enter a value in this column. AutoInvoice will ignore any value that you enter in this column. For on-account credits do not enter a value in this column.
Validataion: Must be either 'PRORATE', 'LIFO', 'FIFO' or NULL.
Destination: RA_CUSTOMER_TRX.CREDIT_METHOD_FOR_ INSTALLMENTS

17- CURRENCY_CODE : Enter the currency code for this transaction. You must enter a value in this column. For credit memos enter the currency code of the invoice you are crediting.
Validation: Must exist in FND_CURRENCIES.CURRENCY_CODE
Destination: RA_CUSTOMER_TRX.INVOICE_CURRENCY_ CODE and
AR_PAYMENT_SCHEDULES. INVOICE_CURRENCY_CODE

18- CUSTOMER_BANK_ ACCOUNT_ID : Enter the Bill-To customer bank account id for this transaction. If LINE_TYPE = 'LINE', 'CHARGES', or you are passing header freight, this column is optional. Depending on the value you entered for your batch source you can enter either a value in this column or in CUSTOMER_BANK_ACCOUNT_NAME. If you entered a value in CUSTOMER_BANK_ACCOUNT_NAME, AutoInvoice defaults a value in this column. If the payment method is of type 'Automatic', and this column is NULL, AutoInvoice will default a value for you. For more details on how AutoInvoice defaults and validates customer banks, see: Passing Payment Methods and Customer Bank Accounts. If LINE_TYPE = 'TAX' or you are passing freight for a specific line, do not enter a value in this column.
Validation: Must exist in AP_BANK_ACCOUNTS.BANK_ACCOUNT_ID. If the payment method is of type 'Manual', RA_INTERFACE_LINES.CUSTOMER_BANK_ ACCOUNT_ID must be NULL.
Destination: RA_CUSTOMER_TRX.CUSTOMER_BANK_ ACCOUNT_ID

19- CUSTOMER_BANK_ ACCOUNT_NAME : Enter the Bill-To customer bank account name for this transaction. If LINE_TYPE = 'LINE', 'CHARGES', or you are passing header freight, this column is optional. Depending on the value you entered for your batch source you can enter either a value in this column or in CUSTOMER_BANK_ACCOUNT_ID. If the payment method is of type 'Automatic' and this column is NULL, AutoInvoice will default a value for you. For more details on how AutoInvoice defaults and validates customer banks, see: Passing Payment Methods and Customer Bank Accounts. If LINE_TYPE = 'TAX' or you are passing freight for a specific line, do not enter a value in this column.
Validation: AP_BANK_ACCOUNTS.BANK_ACCOUNT_ NAME If the payment method is of type 'Manual', RA_INTERFACE_LINES.CUSTOMER_BANK_ ACCOUNT_NAME must be NULL.
Destination: None

20- CUSTOMER_TRX_ID : This column is used by AutoInvoice and should be left null. AutoInvoice defaults a value into this column using your grouping rules.
Validation: None
Destination: RA_CUSTOMER_TRX.CUSTOMER_TRX_ID, AR_PAYMENT_SCHEDULES.CUSTOMER_TRX_ ID, RA_CUSTOMER_TRX_LINES.CUSTOMER_TRX_ ID, and RA_CUST_TRX_LINE_GL_DIST.CUSTOMER_ TRX_ID.

21- CUST_TRX_TYPE_ID : Enter the transaction type id for this transaction. This column is optional, but depending on the value you entered for your batch source you must enter either a value in this column or in CUST_TRX_TYPE_NAME. If you entered a value in CUST_TRX_TYPE_NAME, AutoInvoice defaults a value in this column. For invoice lines against a commitment, AutoInvoice defaults the invoice transaction type from the transaction type of the commitment if CUST_TRX_TYPE_ID and CUST_TRX_TYPE_NAME are null. For credit memos you must enter the id of the credit memo transaction type which has been assigned to the transaction you are crediting.
Validation: Must exist in RA_CUST_TRX_TYPES.CUST_TRX_TYPE_ID
Destination: RA_CUSTOMER_TRX.CUST_TRX_TYPE_ID

22- CUST_TRX_ TYPE_NAME : Enter the transaction type name for this transaction. This column is optional, but depending on the value you entered for your batch source you must enter either a value in this column or in CUST_TRX_TYPE_ID. For invoice lines against a commitment, AutoInvoice defaults the invoice transaction type from the transaction type of the commitment if CUST_TRX_TYPE_ID and CUST_TRX_TYPE_NAME are null. For credit memos you must enter the name of the credit memo transaction type which has been assigned to the transaction you are crediting.
Validation: RA_CUST_TRX_TYPES.NAME
Destination: None

23- DESCRIPTION : This is a required column in AutoInvoice. Enter the description for this transaction.
Validation: None
Destination: RA_CUSTOMER_TRX_LINES.DESCRIPTION

24- DOCUMENT_ NUMBER : Enter the document number for this transaction. If LINE_TYPE = 'LINE', 'CHARGES', or you are passing header freight and the creation method for the sequence numbering of this transaction is Manual, you must enter a value in this column. If LINE_TYPE = 'LINE', 'CHARGES', or you are passing header freight and the creation method is Automatic, do not enter a value in this column. AutoInvoice will create a unique document number. If LINE_TYPE = 'TAX' or you are passing freight for a specific line, do not enter a value in this column.
Validation: Number must not already exist in Oracle Receivables
Destination: RA_CUSTOMER_TRX.DOC_SEQUENCE_VALUE

25- DOCUMENT_ NUMBER_ SEQUENCE_ID : This column is used by AutoInvoice and should be left null. AutoInvoice uses this column to store the document sequence id for this transaction.
Validation: None
Destination: RA_CUSTOMER_TRX.DOC_SEQUENCE_ID

26- EXCEPTION_ID : This column is used by AutoInvoice and should be left null. AutoInvoice defaults a value in this column when a tax exception occurs. If your transaction is a credit memo, AutoInvoice defaults the tax exemption id of the transaction you are crediting.
Validation: None
Destination: RA_CUSTOMER_TRX_LINES. ITEM_EXCEPTION_RATE_ID

27- EXEMPTION_ID : This column is used by AutoInvoice and should be left null. AutoInvoice defaults a value in this column when this transaction is partially or fully exempt from tax. For credit memos AutoInvoice defaults the tax exception id of the transaction you are crediting.
Validation: None
Destination: RA_CUSTOMER_TRX_LINES.TAX_EXEMPTION_ID

28- FOB_POINT : Enter the FOB point for this transaction. If LINE_TYPE = 'LINE', 'CHARGES', or you are passing header freight, this column is optional. If LINE_TYPE = 'TAX' or you are passing freight for a specific line, do not enter a value in this column. For credit memos do not enter a value in this column. AutoInvoice uses the FOB point from the transaction you are crediting.
Validation: Must exist in AR_LOOKUPS.LOOKUP_CODE and AR_LOOKUPS.LOOKUP_TYPE = 'FOB'. Must be less than or equal to 30 characters in length.
Destination: RA_CUSTOMER_TRX.FOB_POINT

29- GL_DATE : Enter the general ledger date for this transaction. The GL date determines the accounting period that you record this transaction to your general ledger. If the Post To GL option on the transaction type of the transaction being passed is set to No, the GL_DATE column should be NULL. If LINE_TYPE = 'LINE', 'CHARGES', and you are passing transactions without rules or you are passing header freight, this column is optional. If LINE_TYPE = 'LINE' and you are importing transactions with rules, do not enter a date in this column. If LINE_TYPE = 'TAX' or 'FREIGHT', do not enter a value in this column. For credit memos, AutoInvoice defaults to the date you run AutoInvoice, unless the transaction you are crediting is billed in arrears. In that case, AutoInvoice defaults to the GL date of the transaction you are crediting. For a more details on general ledger date, see: Determining Dates.
Validation: Must be in an open or future enterable accounting period and the period must exist in GL_PERIOD_STATUSES. If 'Post To GL' is set to No on the transaction type of the transaction being passed, column must be NULL.
Destination: RA_CUST_TRX_LINE_GL_DIST.GL_DATE

30- HEADER_ ATTRIBUTE1-15 : Enter Descriptive Flexfield attribute information. Descriptive Flexfield attributes let you store additional columns, the contents of which you define. If LINE_TYPE = 'LINE', 'CHARGES', or you are passing header freight, this column is optional. If LINE_TYPE = 'TAX' or 'FREIGHT', do not enter values in these columns.
Validation: None
Destination: RA_CUSTOMER_TRX.ATTRIBUTE1-15

31- HEADER_ ATTRIBUTE_ CATEGORY : Enter Descriptive Flexfield attribute category information which is shared between this transaction and other transactions. Descriptive Flexfield categories allow you to store different categories of attributes. If LINE_TYPE = 'LINE', 'CHARGES', or you are passing header freight, this column is optional. If LINE_TYPE = 'TAX' or you are passing freight for a specific line', do not enter values in these columns.
Validation: None
Destination: RA_CUSTOMER_TRX.ATTRIBUTE_CATEGORY

32-INITIAL_ CUSTOMER_TRX_ID : This column is used by AutoInvoice and should be left null. If this transaction is not a credit memo, AutoInvoice defaults a value into this column using RA_INTERFACE_LINES.REFERENCE_ LINE_ID.
Validation: None
Destination: RA_CUSTOMER_TRX.INITIAL_CUSTOMER_ TRX_ID

33- INTERFACE_LINE_ ATTRIBUTE1-15 : Enter the line Transaction Flexfield for this transaction. A Transaction Flexfield is a combination of attribute values which you use to uniquely identify this transaction in your original system. The reference value you enter here provides you with an audit trail from Receivables back to your original system. This is the primary key for RA_INTERFACE_LINES. You must enter values for enabled attributes. When you import transactions with multiple lines using AutoInvoice, only those columns from RA_INTERFACE_LINES.INTERFACE_LINE_ATTRIBUTE1-15 that have the same value for each of the lines will appear in the RA_CUSTOMER_TRX.INTERFACE_HEADER_ATTRIBUTE1-15 columns for any customizations.
Interface lines belonging to the same transaction are ordered by the following SQL clause: waybill_numbership_via asc, ship_date_actual desc The attributes of the first line from the ordered lines will appear in the header attributes.
If a transaction has only one line, then RA_CUSTOMER_TRX.INTERFACE_HEADER_ATTRIBUTE1-15 will be the same as RA_INTERFACE_LINES.INTERFACE_LINE_ATTRIBUTE1-15.
Validation: Must not already exist together with INTERFACE_LINE_CONTEXT in RA_CUSTOMER_TRX_LINES. INTERFACE_LINE_ATTRIBUTE1-15, INTERFACE_LINE_CONTEXT and all enabled attributes must have values.
Destination: RA_CUSTOMER_TRX.INTERFACE_HEADER_ ATTRIBUTE1-15 and RA_CUSTOMER_TRX_LINES.INTERFACE_LINE_ATTRIBUTE1-15

34- INTERFACE_LINE_ CONTEXT : This is a required column in AutoInvoice. Enter the context of the Line Transaction Flexfield entered in columns INTERFACE_LINE_ATTRIBUTE1-15. If you pass lines with global context, set this column to 'Global Data Elements'.
Validation: None
Destination: RA_CUSTMER_TRX_LINES.INTERFACE_LINE_ CONTEXT

35- INTERFACE_ LINE_ID : This column is used by AutoInvoice and should be left null. AutoInvoice defaults a value in this column using the RA_CUSTOMER_TRX_LINES_S sequence.
Validation: None
Destination: RA_CUSTOMER_TRX_LINES.CUSTOMER_TRX_LINE_ID

36- INTERFACE_ STATUS : This column is used by AutoInvoice and should be left null. If AutoInvoice sets this column to 'P' then the line has been transferred successfully.

37- INTERNAL_NOTES : Enter internal notes for this transaction. If LINE_TYPE = 'LINE', 'CHARGES', or you are passing freight header, this column is optional. If LINE_TYPE = 'TAX' or you are passing freight for a specific line, do not enter text in this column.
Validation: None
Destination: RA_CUSTOMER_TRX.INTERNAL_NOTES

38- INVENTORY_ ITEM_ID : Enter the inventory item id for this transaction. If LINE_TYPE = 'LINE', or 'CHARGES' this column is optional. Depending on the value you entered for your batch source you can enter either a value in this column or a combination of segment values in MTL_SYSTEM_ITEMS_SEG1-20. If you specify segments in your batch source, AutoInvoice defaults a value in this column. If LINE_TYPE = 'TAX' or 'FREIGHT', do not enter a value in this column. For credit memos do not enter a value in this column. AutoInvoice uses the value from the transaction you are crediting.
Validation: Must exist in MTL_SYSTEM_ITEMS.INVENTORY_ITEM_ID and MTL_SYSTEM_ITEMS.INVOICE_ENABLED_FLAG = 'Y'.
Destination: RA_CUSTOMER_TRX_LINES.INVENTORY_ITEM_ID

39- INVOICING_ RULE_ID : Enter the invoicing rule id for this transaction. If LINE_TYPE = 'LINE' or you are passing header freight, this column is optional. For invoice lines with rules, you must enter either a value in this column or in INVOICING_RULE_NAME, depending on the value you entered for your batch source. If you specify invoicing rule name in your batch source, AutoInvoice defaults a value in this column. If LINE_TYPE = 'TAX', 'CHARGES', or you are passing freight for a specific line, do not enter a value in this column. For credit memos do not enter a value in this column. AutoInvoice uses the invoicing rule from the transaction you are crediting.
Validation: Must exist in RA_RULES.RULE_ID and RA_RULES.RULE_ID = -2 or -3. If you enter an invoicing rule you must also enter an accounting rule. If LINE_TYPE = 'CHARGES' then this column must be null.
Destination: RA_CUSTOMER_TRX.INVOICING_RULE_ID

40- INVOICING_ RULE_NAME : Enter the invoicing rule name for this transaction. If LINE_TYPE = 'LINE' or you are passing header freight, this column is optional. For invoice lines with rules, you must enter either a value in this column or in INVOICING_RULE_ID, depending on the value you entered for your batch source. You can enter a value in this column or in INVOICE_RULE_ID. If LINE_TYPE = 'TAX', 'CHARGES' or you are passing freight for a specific line, do not enter a value in this column. For credit memos do not enter a value in this column. AutoInvoice uses the invoicing rule from the transaction you are crediting.
Validation: Must exist in RA_RULES.RULE_ID and RA_RULES.RULE_ID = -2 or -3. If you enter an invoicing rule you must also enter an accounting rule. If LINE_TYPE = 'CHARGES' then this column must be null.
Destination: None

41- LAST_PERIOD_ TO_CREDIT : For unit credit memos, enter the last period number from which you want to start crediting. If this transaction is a credit memo against a transaction which uses an accounting rule and LINE_TYPE = 'LINE', CREDIT_METHOD_FOR_ACCT_RULE = 'UNIT', or you are passing header freight, you may enter a value in this column. If LINE_TYPE = 'TAX' or you are passing freight for a specific line, do not enter a value in this column. AutoInvoice will ignore any value that you enter in this column.
Validation: Must be between 0 and the invoice's accounting rule duration (inclusive).
Destination: RA_CUSTOMER_TRX_LINES.LAST_PERIOD_TO_CREDIT

42- LAST_UPDATE_ LOGIN : This column is used by AutoInvoice and should be left null. AutoInvoice updates this column when it selects rows from the RA_INTERFACE_LINES table for processing.
Validation: None
Destination: None

43- LINE_NUMBER : This column is used by AutoInvoice and should be left null. AutoInvoice ignores any values passed in this column and always numbers the lines sequentially starting with the number 1 and in the order determined by the line ordering rule.

44- LINE_TYPE : Enter 'LINE', 'TAX', 'FREIGHT' or 'CHARGES' to specify the line type for this transaction. You must enter a value in this column. For credit memos enter the type of line you are crediting.
Validation: Must be 'LINE', 'TAX', 'FREIGHT' or 'CHARGES'
Destination: RA_CUSTOMER_TRX_LINES.LINE_TYPE

45- LINK_TO_LINE_ ATTRIBUTE1-15 : Enter the link to your Transaction Flexfield attribute values. If LINE_TYPE = 'LINE', 'CHARGES', or you are passing header freight, do not enter values in these columns. If LINE_TYPE = 'TAX' or you are passing freight for a specific line, you must enter a value. Use link to line attributes to associate this tax or freight line to another transaction line in RA_INTERFACE_LINES. All tax lines and freight for specific lines must be associated with a line that has a LINE_TYPE of 'LINE'. Enter the same combination of attribute values as the transaction to which you want to associate with. For credit memos applied to tax lines, you must use these columns to link your credit memo tax lines to your credit memo transaction. Similarly, for credit memos applied to freight lines you must also use these columns to link your credit memo freight line to your credit memo transaction. If you are applying a credit memo against a tax line which is linked to a transaction, you must enter a dummy credit memo transaction with a zero revenue amount and use these columns to link to your credit memo tax line. Similarly, if you are applying a credit memo against a freight line which is linked to a transaction, you must also enter a dummy credit memo transaction with a zero revenue amount and use these columns to link to your credit memo freight line.
Validation: The transaction that you link to must have a LINE_TYPE = 'LINE'. You can only link at most one freight line to another transaction. You cannot link a transaction that has a LINE_TYPE = 'LINE' or 'CHARGES' to another transaction.
Destination: None

46- LINK_TO_LINE_ CONTEXT : Enter the context name of the Transaction Flexfield data that you entered in RA_INTERFACE_LINES.LINK_TO_LINE_ATTRIBUTE1-15.
Validation: None
Destination: None

47- LINK_TO_LINE_ID : This column is used by AutoInvoice and should be left null. AutoInvoice defaults a value into this column using RA_INTERFACE_LINES.LINK_TO_LINE_ATTRIBUTE1-15 and RA_INTERFACE_LINES.LINK_TO_LINE_CONTEXT.
Validation: None
Destination: RA_CUSTOMER_TRX_LINES.LINK_TO_CUST_ TRX_LINE_ID

48- LOCATION_ SEGMENT_ID : This column is used by AutoInvoice and should be left null. AutoInvoice defaults a value into this column if you are crediting a sales tax line.
Validation: None
Destination: RA_CUSTOMER_TRX_LINES.LOCATION_ SEGMENT_ID

49- MEMO_LINE_ID : Enter the standard memo line id for this transaction. If LINE_TYPE = 'LINE', 'CHARGES', or you are passing header freight, this column is optional. Depending on the value you entered for your batch source you can enter either a value in this column or in MEMO_LINE_NAME. If you specify memo line name in your batch source, AutoInvoice defaults a value in this column. If LINE_TYPE = 'TAX' or you are passing freight for a specific line, do not enter a value in this column. For credit memos do not enter a value in this column. AutoInvoice uses the memo line from the transaction you are crediting.
Validation: Must exist in AR_MEMO_LINES.MEMO_LINE_ID
Destination: RA_CUSTOMER_TRX_LINES.MEMO_LINE_ID

50- MEMO_LINE_NAME : Enter the name of the standard memo line for this transaction. If LINE_TYPE = 'LINE', 'CHARGES', or you are passing header freight this column is optional. Depending on the value you entered for your batch source you can enter either a value in this column or in MEMO_LINE_ID. If LINE_TYPE = 'TAX' or you are passing freight for a specific line, do not enter a value in this column. For credit memos do not enter a value in this column. AutoInvoice uses the memo line from the transaction you are crediting.
Validation: Must exist in AR_MEMO_LINES.NAME
Destination: None

51- MOVEMENT_ID : This column is used to pass movement statistics that are tied to the shipment information and passed through AutoInvoice. Autoinvoice will populate the column RA_CUSTOMER_TRX_LINES.movement_id with RA_INTERFACE_LINES.movement_id and updates MTL_MOVEMENT_STATISTICS with transaction information (for example, customer_trx_id, batch_id, customer_trx_line_id).
Validation: None
Destination: RA_CUSTOMER_TRX_LINES.movement_id

52- MTL_SYSTEM_ ITEMS_SEG1-20 : Assign a System Item Flexfield value for each segment you enable in Receivables. For example, if you enable six System Item Flexfield segments, you must enter six values in columns MTL_SYSTEM_ITEMS_SEG1-6. Be sure to enter the correct segment value. For example, value '01' is not the same as '1'. If LINE_TYPE = 'LINE' or 'CHARGES', these columns are optional. Depending on the value you entered for your batch source you can enter either values in these columns or in INVENTORY_ITEM_ID. If LINE_TYPE = 'TAX' or 'FREIGHT', do not enter values in these columns. For credit memos do not enter values in these columns. AutoInvoice uses the values from the transaction you are crediting. For debit memos do not enter values in these columns.
Validation: Valid combination of System Item Flexfield segment values
Destination: None

53- ORG_ID : This column has been added for future Oracle Applications functionality and can be left null.
Validation: None
Destination: None

54- ORIG_SYSTEM_ BATCH_NAME : Enter the batch name for this transaction. This column is optional. AutoInvoice does not perform any validation on this column but uses the value entered when grouping transactions into invoices.
Validation: None
Destination: RA_CUSTOMER_TRX.ORIG_SYSTEM_BATCH_ NAME

55- ORIG_SYSTEM_ BILL_ADDRESS_ID : Enter the Bill-To customer address id for this transaction. This Bill-To customer address id is for the Bill-To customer you entered in ORIG_SYSTEM_BILL_CUSTOMER_REF or ORIG_SYSTEM_BILL_CUSTOMER_ID. If no default Remit_To Address has been specified, AutoInvoice uses the Bill-To address to determine the Remit-To address for the customer. AutoInvoice will not import transactions that have inactive addresses or addresses with an inactive Bill To business purpose. In addition, if the Remit-To address cannot be determined, AutoInvoice will reject the transaction. If LINE_TYPE = 'LINE', 'CHARGES', or you are passing header freight, this column is optional. Depending on the value you entered for your batch source you must enter either a value in this column or in ORIG_SYSTEM_BILL_ADDRESS_REF. If you specify the Bill-To customer address reference in your batch source, AutoInvoice defaults a value in this column. If LINE_TYPE = 'TAX' or you are passing freight for a specific line, do not enter a value in this column.
Validation: RA_INTERFACE_LINES.ORIG_SYSTEM_BILL_ ADDRESS_ID = RA_ADDRESSES.ADDRESS_ID and RA_INTERFACE_LINES.ORIG_SYSTEM_BILL_ CUSTOMER_ID = RA_CUSTOMERS.CUSTOMER_ID and RA_CUSTOMERS.CUSTOMER_ID = RA_ADDRESSES.CUSTOMER_ID and RA_ADDRESSES.ADDRESS_ID = RA_SITE_USES.ADDRESS_ID and RA_SITE_USES.SITE_USE_CODE = 'BILL_TO'
Destination: None

56- ORIG_SYSTEM_ BILL_ADDRESS_REF : Enter the Bill-To customer address reference from your original system. This reference is for the Bill-To customer you entered in ORIG_SYSTEM_BILL_CUSTOMER_REF or ORIG_SYSTEM_BILL_CUSTOMER_ID. The reference value you enter here provides you with an audit trail from Receivables back to your original system. If no default Remit_To Address has been specified, AutoInvoice uses the Bill-To address to determine the Remit-To address for the customer. AutoInvoice will not import transactions that have inactive addresses or addresses with an inactive Bill To business purpose. In addition, if the Remit-To address cannot be determined, AutoInvoice will reject the transaction. If LINE_TYPE = 'LINE', 'CHARGES', or you are passing header freight, this column is optional. Depending on the value you entered for your batch source you must enter either a value in this column or in ORIG_SYSTEM_BILL_ADDRESS_ID. If LINE_TYPE = 'TAX' or you are passing freight for a specific line, do not enter a value in this column.
Validation: RA_INTERFACE_LINES.ORIG_SYSTEM_BILL_ ADDRESS_REF = RA_ADDRESSES.ORIG_SYSTEM_REFERENCE and RA_INTERFACE_LINES.ORIG_SYSTEM_BILL_ CUSTOMER_REF = RA_CUSTOMERS.ORIG_SYSTEM_REFERENCE and RA_CUSTOMERS.CUSTOMER_ID = RA_ADDRESSES.CUSTOMER_ID and RA_ADDRESSES.ADDRESS_ID = RA_SITE_USES.ADDRESS_ID and RA_SITE_USES.SITE_USE_CODE = 'BILL_TO'
Destination: None

57- ORIG_SYSTEM_ BILL_CONTACT_ID : Enter the Bill-To contact id for this transaction. This Bill-To contact id must be for the Bill-To customer that you entered in ORIG_SYSTEM_BILL_CUSTOMER_REF or ORIG_SYSTEM_BILL_CUSTOMER_ID. If LINE_TYPE = 'LINE', 'CHARGES', or you are passing header freight, this column is optional. Depending on the value you entered for your batch source you can enter either a value in this column or in ORIG_SYSTEM_BILL_CONTACT_REF. If you specify the Bill-To customer contact reference in your batch source, AutoInvoice defaults a value in this column. If LINE_TYPE = 'TAX' or you are passing freight for a specific line, do not enter a value in this column.
Validation: RA_INTERFACE_LINES.ORIG_SYSTEM_BILL_ CUSTOMER_ID = RA_CONTACTS.CUSTOMER_ID and RA_INTERFACE_LINES.ORIG_SYSTEM_BILL_ CONTACT_ID = RA_CONTACTS.CONTACT_ID
Destination: RA_CUSTOMER_TRX.BILL_TO_CONTACT_ID

58-ORIG_SYSTEM_ BILL_CONTACT_REF : Enter the Bill-To contact reference from your original system. This reference is for the Bill-To customer that you entered in ORIG_SYSTEM_BILL_CUSTOMER_REF or ORIG_SYSTEM_BILL_CUSTOMER_ID. The reference value you enter here provides you with an audit trail from Oracle Receivables back to your original system. If LINE_TYPE = 'LINE', 'CHARGES', or you are passing header freight, this column is optional. Depending on the value you entered for your batch source you can enter either a value in this column or in ORIG_SYSTEM_BILL_CONTACT_ID. If LINE_TYPE = 'TAX' or you are passing freight for a specific line, do not enter a value in this column.
Validation: RA_INTERFACE_LINES.ORIG_SYSTEM_BILL_ CUSTOMER_ID = RA_CONTACTS.CUSTOMER_ID and RA_INTERFACE_LINES.ORIG_SYSTEM_BILL_ CONTACT_REF = RA_CONTACTS.ORIG_SYSTEM_REFERENCE
Destination: None

59- ORIG_SYSTEM_ BILL_CUSTOMER_ID : Enter the Bill-To customer id for this transaction. If LINE_TYPE = 'LINE', 'CHARGES', or you are passing header freight, this column is optional. Depending on the value you entered for your batch source you must enter either a value in this column or in ORIG_SYSTEM_BILL_CUSTOMER_REF. If you specify the Bill-To customer reference in your batch source, AutoInvoice defaults a value in this column. If LINE_TYPE = 'TAX' or you are passing freight for a specific line, do not enter a value in this column. For credit memos you must enter the Bill-To customer id or the Bill-To customer id of a related customer of the transaction you are crediting.
Validation: Must exist in RA_CUSTOMERS.CUSTOMER_ID
Destination: RA_CUSTOMER_TRX.BILL_TO_CUSTOMER_ID

60- ORIG_SYSTEM_ BILL_CUSTOMER_ REF : Enter a value you can use to uniquely identify this Bill-To customer in your original system. The reference value you enter here provides you with an audit trail from Oracle Receivables back to your original system. If LINE_TYPE = 'LINE', 'CHARGES', or you are passing header freight, this column is optional. Depending on the value you entered for your batch source you must enter either a value in this column or in ORIG_SYSTEM_BILL_CUSTOMER_ID. If LINE_TYPE = 'TAX' or you are passing freight for a specific line, do not enter a value in this column. For credit memos you must enter the Bill-To customer reference or the Bill-To customer reference of a related customer of the transaction you are crediting.
Validation: Must exist in RA_CUSTOMERS.ORIG_SYSTEM_REFERENCE
Destination: None

61- ORIG_SYSTEM_ SHIP_ADDRESS_ID : Enter the Ship-To customer address id for this transaction. If LINE_TYPE = 'LINE', 'CHARGES', or you are passing header freight, this column is optional. Depending on the value you entered for your batch source you can enter either a value in this column or in ORIG_SYSTEM_SHIP_ADDRESS_REF. If you specify the Ship-To address reference in your batch source, AutoInvoice defaults a value in this column. If LINE_TYPE = 'TAX' or you are passing freight for a specific line, do not enter a value in this column. For credit memos, do not enter a value in this column; AutoInvoice uses the Ship-To address from the transaction you are crediting.
Validation: RA_INTERFACE_LINES.ORIG_SYSTEM_SHIP_ ADDRESS_ID = RA_ADDRESSES.ADDRESS_ID and RA_INTERFACE_LINES.ORIG_SYSTEM_SHIP_ CUSTOMER_ID = RA_CUSTOMERS.CUSTOMER_ID and RA_CUSTOMERS.CUSTOMER_ID = RA_ADDRESSES.CUSTOMER_ID and RA_ADDRESSES.ADDRESS_ID = RA_SITE_USES.ADDRESS_ID and RA_SITE_USES.SITE_USE_CODE = 'SHIP_TO'
Destination: None

62- ORIG_SYSTEM_ SHIP_ADDRESS_REF : Enter a value you can use to uniquely identify this Ship-To customer address in your original system. The reference value you enter here provides you with an audit trail from Receivables back to your original system. If LINE_TYPE = 'LINE', 'CHARGES', or you are passing header freight, this column is optional. Depending on the value you entered for your batch source you can enter either a value in this column or in ORIG_SYSTEM_SHIP_ADDRESS_ID. If LINE_TYPE = 'TAX' or you are passing freight for a specific line, do not enter a value in this column. For credit memos do not enter a value in this column, AutoInvoice uses the Ship-To address from the transaction you are crediting.
Validation: RA_INTERFACE_LINES.ORIG_SYSTEM_SHIP_ ADDRESS_REF = RA_ADDRESSES.ORIG_SYSTEM_REFERENCE and RA_INTERFACE_LINES.ORIG_SYSTEM_SHIP_ CUSTOMER_ID = RA_CUSTOMERS.CUSTOMER_ID and RA_CUSTOMERS.CUSTOMER_ID = RA_ADDRESSES.CUSTOMER_ID and RA_ADDRESSES.ADDRESS_ID = RA_SITE_USES.ADDRESS_ID and RA_SITE_USES.SITE_USE_CODE = 'SHIP_TO'
Destination: None

63- ORIG_SYSTEM_ SHIP_CONTACT_ID : Enter the Ship-To contact id for this transaction. If LINE_TYPE = 'LINE', 'CHARGES', or you are passing header freight, this column is optional. Depending on the value you entered for your batch source you can enter either a value in this column or in ORIG_SYSTEM_SHIP_CONTACT_REF. If you specify the Ship-To contact reference in your batch source, AutoInvoice defaults a value in this column. If LINE_TYPE = 'TAX' or you are passing freight for a specific line, do not enter a value in this column. For credit memos, do not enter a value in this column. AutoInvoice uses the Ship-To contact from the transaction you are crediting.
Validation: RA_INTERFACE_LINES.ORIG_SYSTEM_SHIP_ CUSTOMER_ID = RA_CONTACTS.CUSTOMER_ID and RA_INTERFACE_LINES.ORIG_SYSTEM_SHIP_ CONTACT_ID = RA_CONTACTS.CONTACT_ID
Destination: RA_CUSTOMER_TRX.SHIP_TO_CONTACT_ID

64- ORIG_SYSTEM_ SHIP_CONTACT_REF : Enter a value you can use to uniquely identify this Ship-To contact in your original system. The reference value you enter here provides you with an audit trail from Receivables back to your original system. If LINE_TYPE = 'LINE', 'CHARGES', or you are passing header freight, this column is optional. Depending on the value you entered for your batch source you can enter either a value in this column or in ORIG_SYSTEM_SHIP_CONTACT_ID. If LINE_TYPE = 'TAX' or you are passing freight for a specific line, do not enter a value in this column. For credit memos, do not enter a value in this column. AutoInvoice uses the Ship-To contact from the transaction you are crediting.
Validation: RA_INTERFACE_LINES.ORIG_SYSTEM_SHIP_ CUSTOMER_ID = RA_CONTACTS.CUSTOMER_ID and RA_INTERFACE_LINES.ORIG_SYSTEM_SHIP_ CONTACT_REF = RA_CONTACTS.ORIG_SYSTEM_REFERENCE
Destination: None

65- ORIG_SYSTEM_ SHIP_CUSTOMER_ ID : Enter the Ship-To customer id for this transaction. If LINE_TYPE = 'LINE', 'CHARGES', or you are passing header freight, this column is optional. Depending on the value you entered for your batch source you can enter either a value in this column or in ORIG_SYSTEM_SHIP_CUSTOMER_REF. If you specify the Ship-To customer reference in your batch source, AutoInvoice defaults a value in this column. If LINE_TYPE = 'TAX' or you are passing freight for a specific line, do not enter a value in this column. For credit memos, do not enter a value in this column. AutoInvoice uses the Ship-To customer from the transaction you are crediting.
Validation: Must exist in RA_CUSTOMERS.CUSTOMER_ID
Destination: RA_CUSTOMER_TRX.SHIP_TO_CUSTOMER_ID

66- ORIG_SYSTEM_ SHIP_CUSTOMER_ REF : Enter a value you can use to uniquely identify this Ship-To customer in your original system. The reference value you enter here provides you with an audit trail from Receivables back to your original system. If LINE_TYPE = 'LINE', 'CHARGES', or you are passing header freight, this column is optional. Depending on the value you entered for your batch source you can enter either a value in this column or in ORIG_SYSTEM_SHIP_CUSTOMER_ID. If LINE_TYPE = 'TAX' or you are passing freight for a specific line, do not enter a value in this column. For credit memos, do not enter a value in this column. AutoInvoice uses the Ship-To customer from the transaction you are crediting.
Validation: Must exist in RA_CUSTOMERS.ORIG_SYSTEM_REFERENCE
Destination: None

67- ORIG_SYSTEM_ SOLD_CUSTOMER_ ID : Enter the Sold-To customer id for this transaction. If LINE_TYPE = 'LINE', 'CHARGES', or you are passing header freight, this column is optional. Depending on the value you entered for your batch source you can enter either a value in this column or in ORIG_SYSTEM_SOLD_CUSTOMER_REF. If you specify the Sold-To customer reference in your batch source, AutoInvoice defaults a value in this column. If LINE_TYPE = 'TAX' or you are passing freight for a specific line, do not enter a value in this column. For credit memos do not enter a value. AutoInvoice uses the Sold-To customer from the transaction you are crediting.
Validation: Must exist in RA_CUSTOMERS.CUSTOMER_ID
Destination: RA_CUSTOMER_TRX.SOLD_TO_CUSTOMER_ID

68- ORIG_SYSTEM_ SOLD_CUSTOMER_ REF : Enter a value you can use to uniquely identify this Sold-To customer in your original system. The reference value you enter here provides you with an audit trail from Receivables back to your original system. If LINE_TYPE = 'LINE', 'CHARGES', or you are passing header freight, this column is optional. Depending on the value you entered for your batch source you can enter either a value in this column or in ORIG_SYSTEM_SOLD_CUSTOMER_ID. If LINE_TYPE = 'TAX' or you are passing freight for a specific line, do not enter a value in this column. For credit memos do not enter a value, AutoInvoice uses the Sold-To customer from the transaction you are crediting.
Validation: Must exist in RA_CUSTOMERS.ORIG_SYSTEM_REFERENCE
Destination: None

69- PAYING_ CUSTOMER_ID : This column is used by AutoInvoice and should be left null. Please refer to the section on Automatic Receipts for details on how AutoInvoice determines the paying customer.
Validation: None
Destination: RA_CUSTOMER_TRX.PAYING_CUSTOMER_ID

70- PAYING_ CUSTOMER_ID : This column is used by AutoInvoice and should be left null.
Validation: None
Destination: RA_CUSTOMER_TRX.PAYING_CUSTOMER_ID

71- PAYING_SITE_ USE_ID : This column is used by AutoInvoice and should be left null.
Validation: None
Destination: RA_CUSTOMER_TRX.PAYING_SITE_USE_ID

72- PAYING_ SITE_USE_ID : This column is used by AutoInvoice and should be left null. Please refer to the section on Automatic Receipts for details on how AutoInvoice determines the paying site use.
Validation: None
Destination: RA_CUSTOMER_TRX.PAYING_SITE_USE_ID

73- PREVIOUS_ CUSTOMER_TRX_ID : This column is used by AutoInvoice and should be left null. For credit memos, AutoInvoice defaults a value into this column using RA_INTERFACE_LINES.REFERENCE_LINE_ID.
Validation: None
Destination: RA_CUSTOMER_TRX.PREVIOUS_CUSTOMER_ TRX_ID and
RA_CUSTOMER_TRX_LINES. CUSTOMER_TRX_ID

75- PRIMARY_ SALESREP_ID : Enter the primary salesperson id for this transaction. If LINE_TYPE = 'LINE', 'CHARGES', or you are passing header freight, and you entered Yes for the Require Salesreps system option, you must enter either a value in this column or in PRIMARY_SALESREP_NUMBER. Otherwise this column is optional. The value that you enter depends on the value you entered for your batch source. If you specify the primary salesrep id in your batch source, AutoInvoice defaults a value in this column. If LINE_TYPE = ''TAX' or you are passing freight for a specific line, do not enter a value in this column.
Validation: Must exist in RA_SALESREPS.SALESREP_ID
Destination: RA_CUSTOMER_TRX.PRIMARY_SALESREP_ID

76- PRIMARY_ SALESREP_NUMBER : Enter the primary salesperson number for this transaction. If LINE_TYPE = 'LINE', 'CHARGES', or you are passing header freight, and you entered Yes for the Require Salesreps system option, you must enter either a value in this column or in PRIMARY_SALESREP_ID. Otherwise this column is optional. The value that you enter depends on the value you entered for your batch source. If LINE_TYPE = 'TAX' or you are passing freight for a specific line, do not enter a value in this column.
Validation: Must exist in RA_SALESREPS.SALESREP_NUMBER
Destination: None

77- PRINTING_OPTION : Enter the printing option for this transaction. If LINE_TYPE = 'LINE', 'CHARGES', or you are passing header freight, this column is optional. AutoInvoice defaults to the printing option that you entered for this transaction type, if one was entered. If LINE_TYPE = 'TAX' or you are passing freight for a specific line, do not enter a value in this column.
Validation: Must exist in AR_LOOKUPS.LOOKUP_CODE and AR_LOOKUP.LOOKUP_TYPE = 'INVOICE_PRINT_OPTIONS'
Destination: RA_CUSTOMER_TRX.PRINTING_OPTION

78- PURCHASE_ORDER : Enter the purchase order number for this transaction. If LINE_TYPE = 'LINE', 'CHARGES', or you are passing header freight, this column is optional. If LINE_TYPE = 'TAX' or you are passing freight for a specific line, do not enter a value in this column. For credit memos do not enter a value in this column. AutoInvoice uses the purchase order number from the transaction you are crediting.
Validation: None
Destination: RA_CUSTOMER_TRX.PURCHASE_ORDER

79- PURCHASE_ ORDER_DATE : Enter the date of the purchase order for this transaction. If LINE_TYPE = 'LINE', 'CHARGES', or you are passing header freight, this column is optional. If LINE_TYPE = 'TAX' or you are passing freight for a specific line, do not enter a value in this column. For credit memos, do not enter a value in this column. AutoInvoice uses the purchase order date from the transaction you are crediting.
Validation: None
Destination: RA_CUSTOMER_TRX.PURCHASE_ORDER_ DATE

80- PURCHASE_ ORDER_REVISION : Enter the purchase order revision for this transaction. If LINE_TYPE = 'LINE', 'CHARGES', or you are passing header freight, this column is optional. If LINE_TYPE = 'TAX' or you are passing freight for a specific line, do not enter a value in this column. For credit memos, do not enter a value in this column. AutoInvoice uses the purchase order revision from the transaction you are crediting.
Validation: None
Destination: RA_CUSTOMER_TRX.PURCHASE_ORDER_ REVISION

81- QUANTITY : If this transaction is an invoice or credit memo line and LINE_TYPE = 'LINE' or you are passing header freight, this column is optional. For invoice lines, enter the number of units shipped. For credit memo lines, enter the number of units you are crediting. If you do not enter a value in this column, AutoInvoice uses AMOUNT as the extended amount for this transaction. If this transaction is a dummy line for either freight only or tax only, AutoInvoice ignores the value you enter in this column.
If this is a Credit Memo line and LINE_TYPE = 'LINE', CREDIT_METHOD_FOR.ACCT_RULE = 'UNIT' then this column is mandatory.
For Debit Memos, if LINE_TYPE = 'CHARGES', set quantity to 1.
If LINE_TYPE = 'TAX' or you are passing freight for a specific line, do not enter a value in this column.
For Credit Memos, if LINE_TYPE = 'CHARGES', set quantity to 1 or -1.
Validation: For Debit Memos lines with LINE_TYPE = 'CHARGES', quantity must be 1. For Credit Memo lines with LINE_TYPE = 'CHARGES', this column must be 1 or -1. For Credit Memo lines with LINE_TYPE = 'LINE' and CREDIT_METHOD_FOR_ACCT_RULE = 'UNIT' then this column must not be null.
Destination: RA_CUSTOMER_TRX_LINES.QUANTITY_ INVOICED if this transaction is an invoice line. RA_CUSTOMER_TRX_LINES.QUANTITY_ CREDITED if this transaction is a credit memo line.

82- QUANTITY_ ORDERED : Enter the original number of units ordered for this transaction. If LINE_TYPE = 'LINE', 'CHARGES', or you are passing freight for a specific line, this column is optional. If LINE_TYPE = 'TAX' or you are passing freight for a specific line, do not enter a value in this field. For credit memos, do not enter a value in this column. AutoInvoice uses the quantity ordered from the transaction you are crediting.
Validation: None
Destination: RA_CUSTOMER_TRX_LINES.QUANTITY_ ORDERED

83- REASON_CODE : Enter the reason code for this transaction. If LINE_TYPE = 'LINE', 'CHARGES', or you are passing header freight, this column is optional. Depending on the value you entered for your batch source you can enter either a value in this column or in REASON_CODE_MEANING. If you specify the reason code meaning in your batch source, AutoInvoice defaults a value in this column. If LINE_TYPE = 'TAX' or you are passing freight for a specific line, do not enter a value in this column. For credit memos and on-account credits this column is optional.
Validation: Must exist in AR_LOOKUPS.LOOKUP_CODE. This lookup type is either INVOICING_REASON or CREDIT_MEMO_REASON
Destination: RA_CUSTOMER_TRX_LINES.REASON_CODE and

84- RA_CUSTOMER_TRX.REASON_CODE : REASON_CODE_ MEANING
Enter the meaning of the reason code for this transaction. If LINE_TYPE = 'LINE', 'CHARGES', or you are passing header freight, this column is optional. Depending on the value you entered for your batch source you can enter either a value in this column or in REASON_CODE. If LINE_TYPE = 'TAX' or you are passing freight for a specific line, do not enter a value in this column. For credit memos and on-account credits this column is optional.
Validation: Must exist in AR_LOOKUPS.MEANING. This lookup type is either INVOICING_REASON or CREDIT_MEMO_REASON
Destination: None

85- RECEIPT_METHOD_ ID : Enter the payment method id for this transaction. If LINE_TYPE = 'LINE', 'CHARGES', or you are passing header freight, this column is optional. Depending on the value you entered for your batch source you can enter either a value in this column or in RECEIPT_METHOD_NAME. If you specify the payment method name in your batch source, AutoInvoice defaults a value in this column. AutoInvoice always defaults the payment method using the following hierarchy:
1. primary receipt method of the parent primary bill-to site
2. primary receipt method of the parent customer
3. primary receipt method of the bill-to site
4. primary receipt method of the bill-to customer
If LINE_TYPE = 'TAX' or you are passing freight for a specific line, do not enter a value in this field.
Validation: Must exist in AR_RECEIPT_METHODS.RECEIPT_METHOD_ ID and must belong to the bill-to customer or the parent. Additionally, the payment method must have at least one bank account in the same currency as the transaction or have its' Receipts Multi-Currency flag set to Yes.
Destination: RA_CUSTOMER_TRX.RECEIPT_METHOD_ID

86- RECEIPT_METHOD_NAME : Enter the name of the payment method for this transaction. If LINE_TYPE = 'LINE', 'CHARGES', or you are passing header freight, this column is optional. Depending on the value you entered for your batch source you can enter either a value in this column or in RECEIPT_METHOD_ID. If LINE_TYPE = 'TAX' or you are passing freight for a specific line, do not enter a value in this field.
Validation: Must exist in AR_RECEIPT_METHODS.NAME and must belong to the bill-to customer or the parent.
Destination: None

87- REFERENCE_LINE_ ATTRIBUTE1-15 : If LINE_TYPE = 'LINE', 'CHARGES', or you are passing header freight, and this transaction is a credit memo, you must enter either the Transaction Flexfield of the transaction line you are crediting in these columns or the RA_CUSTOMER_TRX_LINES.CUSTOMER_TRX_LINE_ID of the transaction you are crediting in RA_INTERFACE_LINES.REFERENCE_LINE_ID. Otherwise, do not enter values in these columns. If LINE_TYPE = 'TAX' and this transaction is a credit memo, you must enter either the Transaction Flexfield of the tax line you are crediting in these columns or the RA_CUSTOMER_TRX_LINES.CUSTOMER_TRX_LINE_ID of the transaction tax line you are crediting in RA_INTERFACE_LINES.REFERENCE_LINE_ID. Otherwise, do not enter values in these columns. If LINE_TYPE= 'FREIGHT' and this transaction is a credit memo, you must enter either the Transaction Flexfield of the freight line you are crediting in these columns or the RA_CUSTOMER_TRX_LINES.CUSTOMER_TRX_LINE_ID of the transaction freight line you are crediting in RA_INTERFACE_LINES.REFERENCE_LINE_ID. Otherwise, do not enter values in these columns. For on-account credits do not enter values in these columns.
Validation: Must exist in RA_CUSTOMER_TRX_LINES.INTERFACE_LINE_ATTRIBUTE1-15 or RA_INTERFACE_LINES.INTERFACE_LINE_ ATTRIBUTE1-15
Destination: None

88- REFERENCE_LINE_ CONTEXT : Enter the context name of the Transaction Flexfield data entered in RA_INTERFACE_LINES.REFERENCE_LINE_ATTRIBUTE1-15. You must enter a value in this column if you entered values in RA_INTERFACE_LINES.ATTRIBUTE1-15.
Validation: Must exist in: RA_CUSTOMER_TRX_LINES.INTERFACE_LINE_CONTEXT or RA_INTERFACE_LINES.INTERFACE_LINE_ CONTEXT
Destination: None

89- REFERENCE_LINE_ ID : If LINE_TYPE = 'LINE', 'CHARGES', or you are passing header freight, and this transaction is a credit memo, you must enter the RA_CUSTOMER_TRX_LINES.CUSTOMER_TRX_LINE_ID of the transaction line you are crediting in this column or the Transaction Flexfield in REFERENCE_LINE_ATTRIBUTE1-15. Otherwise, do not enter a value. If LINE_TYPE = 'LINE' and this transaction is an invoice against a commitment, you must enter the RA_CUSTOMER_TRX_LINES. CUSTOMER_TRX_LINE_ID of the commitment line you are referencing. If LINE_TYPE= 'TAX' and this transaction is a credit memo, you must enter the RA_CUSTOMER_TRX_LINES.CUSTOMER_TRX_LINE_ID of the tax line you are crediting in these columns or the Transaction Flexfield in REFERENCE_LINE_ATTRIBUTE1-15. Otherwise, do not enter a value in this column. If LINE_TYPE = 'FREIGHT' and this transaction is a credit memo, you must enter the RA_CUSTOMER_TRX_LINES.CUSTOMER_TRX_LINE_ID of the freight line you are crediting in these columns or the Transaction Flexfield in REFERENCE_LINE_ATTRIBUTE1-15. Otherwise, do not enter a value in this column. For on-account credits, do not enter a value in this column.
Validation: Must exist in RA_CUSTOMER_TRX_LINES.CUSTOMER_TRX_LINE_ID.
Destination: RA_CUSTOMER_TRX_LINES.PREVIOUS_ CUSTOMER_TRX_LINE_ID if this transaction is a credit memo. Otherwise, RA_CUSTOMER_TRX_ LINES.INITIAL_CUSTOMER_TRX_LINE_ID

90- RELATED_BATCH_ SOURCE_NAME : Enter the name of the batch source of the document to which this transaction is related. If LINE_TYPE = 'LINE', 'CHARGES', or you are passing header freight, this column is optional. Depending on the value you entered for your batch source you can enter a value in this column and the related transaction number in RELATED_TRX_NUMBER. Or, you can enter the related customer transaction id in RELATED_CUSTOMER_TRX_ID. If LINE_TYPE = 'TAX' or you are passing freight for a specific line, do not enter a value in this column. For credit memos and on-account credits do not enter a value in this column.
Validation: RA_INTERFACE_LINES.RELATED_BATCH_ SOURCE_NAME = RA_BATCH_SOURCES.NAME and RA_INTERFACE_LINES.RELATED_TRX_ NUMBER = RA_CUSTOMER_TRX.TRX_NUMBER and RA_BATCH_SOURCES.BATCH_SOURCE_ID = RA_CUSTOMER_TRX.BATCH_SOURCE_ID
Destination: None

91- RELATED_ CUSTOMER_TRX_ ID : Enter the customer transaction id of the document to which this transaction is related. If LINE_TYPE = 'LINE', 'CHARGES', or you are passing header freight, this column is optional. Depending on the value you entered for your batch source you can enter a value in this column. Or, you can enter the related transaction number in RELATED_TRX_NUMBER and the related batch source name in RELATED_BATCH_SOURCE_NAME. If LINE_TYPE = 'TAX' or you are passing freight for a specific line, do not enter a value in this column. For credit memos and on-account credits do not enter a value in this column.
Validation: Must exist in RA_CUSTOMER_TRX.CUSTOMER_TRX_ID
Destination: RA_CUSTOMER_TRX.RELATED_CUSTOMER_ TRX_ID

92- RELATED_TRX_ NUMBER : Enter the document number to which this transaction is related. If LINE_TYPE = 'LINE', 'CHARGES', or you are passing header freight, this column is optional. Depending on the value you entered for your batch source you can enter a value in this column and the related batch source name in RELATED_BATCH_SOURCE_NAME. Or, you can enter the related customer transaction id in RELATED_CUSTOMER_TRX_ID. If LINE_TYPE = 'TAX' or you are passing freight for a specific line, do not enter a value in this column. For credit memos and on-account credits do not enter a value in this column.
Validation: RA_INTERFACE_LINES.RELATED_BATCH_ SOURCE_NAME = RA_BATCH_SOURCES.NAME and RA_INTERFACE_LINES.RELATED_TRX_ NUMBER = RA_CUSTOMER_TRX.TRX_NUMBER and RA_BATCH_SOURCES.BATCH_SOURCE_ID = RA_CUSTOMER_TRX.BATCH_SOURCE_ID
Destination: None

93- REQUEST_ID : This column is used by AutoInvoice and should be left null.
Validation: None
Destination: The REQUEST_ID column in RA_CUSTOMER_TRX, RA_CUSTOMER_TRX_LINES, RA_CUST_TRX_LINE_GL_DIST, AR_PAYMENT_SCHEDULES, AR_RECEIVABLE_APPLICATIONS, AR_ADJUSTMENTS and RA_CUST_TRX_LINE_SALESREPS.

94- RULE_START_DATE : Enter the date that you want to start the accounting rule for this transaction. If LINE_TYPE = 'LINE' or you are passing header freight, this column is optional. If you specify Specific Date in your accounting rule do not enter a value in this column. If LINE_TYPE = 'TAX', 'CHARGES', or you are passing freight for a specific line, do not enter a value in this column. For credit memos do not enter a value in this column. Please refer to the Deriving Dates section for a more details on rule start date.
Validation: None
Destination: RA_CUSTOMER_TRX_LINES.RULE_START_ DATE

95- SALES_ORDER : Enter the sales order number for this transaction. If LINE_TYPE = 'LINE', 'CHARGES', or you are passing header freight, this column is optional. If LINE_TYPE = 'TAX' or you are passing freight for a specific line, do not enter a value in this column. For credit memos do not enter a value in this column. AutoInvoice uses the sales order number from the transaction you are crediting.
Validation: None
Destination: RA_CUSTOMER_TRX__LINES.SALES_ORDER

96- SALES_ORDER_ DATE : Enter the date of the sales order for this transaction. If LINE_TYPE = 'LINE', 'CHARGES', or you are passing header freight, this column is optional. If LINE_TYPE = 'TAX' or you are passing freight for a specific line, do not enter a value in this column. For credit memos do not enter a value in this column. AutoInvoice uses the sales order date from the transaction you are crediting.
Enter the date of the revenue order for this transaction. If LINE_TYPE = 'LINE', 'CHARGES', or you are passing header freight, this column is optional. If LINE_TYPE = 'TAX' or you are passing freight for a specific line, do not enter a value in this column. For credit memos do not enter a value in this column. AutoInvoice uses the revenue order date from the transaction you are crediting.
Validation: None
Destination: RA_CUSTOMER_TRX_LINES.SALES_ORDER_ DATE

97- SALES_ORDER_LINE : Enter the sales order line number for this transaction. If LINE_TYPE = 'LINE', 'CHARGES', or you are passing header freight, this column is optional. If LINE_TYPE = 'TAX' or you are passing freight for a specific line, do not enter a value in this column. For credit memos do not enter a value in this column. AutoInvoice uses the sales order line number from the transaction you are crediting.
Validation: None
Destination: RA_CUSTOMER_TRX_LINES.SALES_ORDER_ LINE

98- SALES_ORDER_ REVISION : Enter the sales order revision for this transaction. If LINE_TYPE = 'LINE', 'CHARGES', or you are passing header freight, this column is optional. If LINE_TYPE = 'TAX' or you are passing freight for a specific line, do not enter a value in this column. For credit memos do not enter a value in this column. AutoInvoice uses the sales order revision from the transaction you are crediting.
Validation: None
Destination: RA_CUSTOMER_TRX_LINES.SALES_ORDER_ REVISION

99- SALES_ORDER_ SOURCE : Enter the source of the sales order for this transaction. If LINE_TYPE = 'LINE', 'CHARGES', or you are passing header freight, this column is optional. If LINE_TYPE = 'TAX' or you are passing freight for a specific line, do not enter a value in this column. For credit memos do not enter a value in this column. AutoInvoice uses the source of the sales order from the transaction you are crediting.
Validation: None
Destination: RA_CUSTOMER_TRX_LINES.SALES_ORDER_ SOURCE

100- SALES_TAX_ID : This column is used by AutoInvoice and should be left null. For credit memos, AutoInvoice defaults to the sales tax id of the transaction you are crediting.
Validation: None
Destination: RA_CUSTOMER_TRX_LINES.SALES_TAX_ID

101- SET_OF_BOOKS_ID : Enter the set of books id for this transaction. You must enter a value in this column.
Validation: Must exist in AR_SYSTEM_PARAMETERS.SET_OF_BOOKS_ID
Destination: RA_CUSTOMER_TRX.SET_OF_BOOKS_ID

102- SHIP_DATE_ ACTUAL : Enter the shipment date for this transaction. If LINE_TYPE = 'LINE', 'CHARGES', or you are passing header freight, this column is optional. If LINE_TYPE = 'TAX' or you are passing freight for a specific line, do not enter a value in this column. For credit memos do not enter a value in this column. AutoInvoice uses the shipment date from the transaction you are crediting.
Validation: None
Destination: RA_CUSTOMER_TRX.SHIP_DATE_ACTUAL

103- SHIP_VIA : Enter the ship via code for this transaction. If LINE_TYPE = 'LINE', 'CHARGES', or you are passing header freight, this column is optional. If LINE_TYPE = 'TAX' or you are passing freight for a specific line, do not enter a value in this column. For credit memos do not enter a value in this column. AutoInvoice uses the ship via code from the transaction you are crediting.
Validation: ORG_FREIGHT_CODE = RA_INTERFACE_LINES.SHIP_VIA and ORG_FREIGHT.ORGANIZATION_ID = (Your Organization ID) RA_INTERFACE_LINES.SHIP_VIA must be less than or equal to 25 characters in length.
Destination: RA_CUSTOMER_TRX.SHIP_VIA

104- TAX_CODE : Enter the tax code for this tax line.
If LINE_TYPE = 'LINE', 'CHARGES', or 'FREIGHT', do not enter a value in this column. If LINE_TYPE = 'TAX', this column is mandatory. For credit memos, AutoInvoice defaults the tax code from the transaction you are crediting.
Validation: Must exist in AR_VAT_TAX.TAX_CODE
Destination: None

105- TAX_EXEMPT_FLAG : If LINE_TYPE = 'LINE', this column is optional. The value you enter here controls how a line is taxed. Enter 'E' if you want AutoInvoice to exempt an invoice line that would normally be taxed and your system option 'Use Customer Exemptions' is set to Yes. If you enter 'E' you must enter a value for TAX_EXEMPT_REASON_CODE or TAX_EXEMPT_REASON_CODE_MEANING depending on your batch source option. Enter 'R' if you want AutoInvoice to force tax on an invoice line, ignoring any exemption certificates that may be on file. Enter 'S' if you want tax to be calculated as per the normal procedures set up in Receivables For all other line types, do not enter a value in this column. For credit memos, do not enter a value in this column.
Validation: Must exist in AR_LOOKUPS.LOOKUP.CODE Lookup type is TAX_CONTROL_FLAG
Destination: RA_CUSTOMER_TRX_LINES. TAX_EXEMPT_FLAG

106- TAX_EXEMPT_ NUMBER : Enter the tax exempt number for this transaction. If LINE_TYPE = 'LINE' and tax_exempt_flag = 'E', then you may enter a value in this column. Otherwise, do not enter a value in this column. For all other line types, do not enter a value in this column. For credit memos, do not enter a value in this column.
Validation: None
Destination: RA_CUSTOMER_TRX_LINES. TAX_EXEMPT_NUMBER

107- TAX_EXEMPT_ REASON_CODE : Enter the tax exempt reason code for this transaction. If LINE_TYPE = 'LINE' and tax_exempt_flag = 'E', then depending on your batch source option, Memo Reason, you must enter a value in this column or in TAX_EXEMPT_REASON_CODE_MEANING. If you specify a tax exempt reason code meaning in your batch source, AutoInvoice defaults the code in this column. For all other line types, do not enter a value in this column. For credit memos do not enter a value in this column.
Validation: Must exist in AR_LOOKUPS.LOOKUP.CODE Lookup type is TAX_REASON
Destination: RA_CUSTOMER_TRX_LINES. TAX_EXEMPT_REASON_CODE

108- TAX_EXEMPT_ REASON_CODE _MEANING : Enter the tax exempt reason code meaning for this transaction. If LINE_TYPE = 'LINE' and tax_exempt_flag = 'E', then depending on your batch source option, Memo Reason, you must enter a value in this column or in TAX_EXEMPT_REASON_CODE. Otherwise, do not enter a value in this column. For all other line types, do not enter a value in this column. For credit memos do not enter a value in this column.
Validation: Must exist in AR_LOOKUPS.MEANING. Lookup type is TAX_REASON
Destination: None

109- TAX_PRECEDENCE : Enter the precedence number for this tax line. This column is used to compute tax compounding.
If LINE_TYPE = 'LINE', 'CHARGES', or 'FREIGHT', do not enter a value in this column. If LINE_TYPE = 'TAX' and you allow compound tax, you can enter a value in this column. Otherwise do not enter a value. If you are passing freight for a specific line, do not enter a value in this column. For credit memos AutoInvoice defaults the tax precedence from the transaction you are crediting.
Validation: None
Destination: RA_CUSTOMER_TRX_LINES.TAX_ PRECEDENCE

110- TAX_RATE : Enter the tax rate for this tax line.
If LINE_TYPE = 'LINE', 'CHARGES', or 'FREIGHT', do not enter a value in this column. If LINE_TYPE = 'TAX', you must enter a value either in this column or the AMOUNT column. Any exemptions for the tax lines must be factored into the tax rate.
Validation: None
Destination: RA_CUSTOMER_TRX_LINES.TAX_RATE

111- TERM_ID : Enter the payment term id for this transaction. If LINE_TYPE = 'LINE', 'CHARGES', or you are passing header freight, this column is optional. Depending on the value you entered for your batch source you must enter either a value in this column or in TERM_NAME. If you specify term name in your batch source, AutoInvoice defaults a value in this column. If LINE_TYPE = 'TAX' or you are passing freight for a specific line, do not enter a value in this column. For credit memos and on-account credits do not enter a value in this column.
Validation: Must exist in RA_TERMS.TERM_ID
Destination: RA_CUSTOMER_TRX.TERM_ID

112- TERM_NAME : Enter the name of the payment term for this transaction. If LINE_TYPE = 'LINE', 'CHARGES', or you are passing header freight, this column is optional. Depending on the value you entered for your batch source you must enter either a value in this column or in TERM_ID. If LINE_TYPE = 'TAX' or you are passing freight for a specific line, do not enter a value in this column. For credit memos and on-account credits do not enter a value in this column.
Validation: Must exist in RA_TERMS.NAME
Destination: None

113- TERRITORY_ID : Enter the territory id for this transaction. If LINE_TYPE = 'LINE', 'CHARGES', or you are passing header freight, this column is optional. Depending on the value you entered for your batch source you can enter either a value in this column or a combination of territory segment values in TERRITORY_SEGMENT1-20. If you specify the combination of territory segment values in your batch source, AutoInvoice defaults a value in this column. If LINE_TYPE = 'TAX' or you are passing freight for a specific line, do not enter a value in this column. For credit memos do not enter a value in this column. AutoInvoice uses the territory from the transaction you are crediting.
Validation: Must exist in RA_TERRITORIES.TERRITORY_ID
Destination: RA_CUSTOMER_TRX.TERRITORY_ID

114- TERRITORY_ SEGMENT1-20 : Assign a Territory Flexfield value for each segment you enable in Receivables. For example, if you enable six Territory Flexfield segments, you must enter six values in columns TERRITORY_SEGMENT1-6. Be sure to enter the correct segment value. For example, value '01' is not the same as '1'. If LINE_TYPE = 'LINE', 'CHARGES', or you are passing header freight, these columns are optional. Depending on the value you entered for your batch source you can enter either values in these columns or in TERRITORY_ID. If LINE_TYPE = 'TAX' or you are passing freight for a specific line, do not enter values in these columns. For credit memos do not enter values in these columns. AutoInvoice uses the territory from the transaction you are crediting.
Validation: Valid combination of Territory Flexfield segment values from RA_TERRITORIES Destination: None

115- TRX_DATE : Enter the transaction date for this transaction.
If TRX_TYPE = 'LINE', 'CHARGES', or you are passing header freight, this column is optional. If this transaction is an invoice or debit memo line, you can enter the invoice date. If this transaction is a credit memo line, you can enter the credit memo date. If this transaction is an invoice line and uses an Arrears Invoice invoicing rule, do not enter a value in this column.
If you do not enter a transaction date, AutoInvoice uses the general ledger date for invoice and debit memo lines. For credit memo lines, AutoInvoice uses the following hierarchy: credit memo general ledger date, and the general ledger date for the invoice's receivable distribution or the date on the Submit Requests window, whichever is later.
When child invoices are created against a commitment, AutoInvoice ensures that the child invoice's transaction date falls between the commitment's start and end dates.
If TRX_TYPE = 'TAX' or you are passing freight for a specific line, do not enter a value in this column.
Validation: None
Destination: RA_CUSTOMER_TRX.TRX_DATE

116- TRX_NUMBER : Enter the number for this transaction. If TRX_TYPE = 'LINE', 'CHARGES', or you are passing header freight, and your batch source has Automatic Invoice Numbering set to No, you must enter a value in this column. If TRX_TYPE = 'LINE', 'CHARGES', or you are passing header freight, and your batch source has Automatic Invoice Numbering set to Yes, do not enter a value in this column. AutoInvoice inserts a unique number in this column. If TRX_TYPE = 'TAX' or you are passing freight for a specific line, do not enter a value in this column.
Validation: Must not already exist in RA_CUSTOMER_TRX.TRX_NUMBER and RA_CUSTOMER_TRX.BATCH_SOURCE_ID
Destination: RA_CUSTOMER_TRX.TRX_NUMBER and
AR_PAYMENT_SCHEDULES.TRX_NUMBER

117- UOM_CODE : Enter the unit of measure code for this transaction. If LINE_TYPE = 'LINE' and the line has an item you must enter either a value in this column or in UOM_NAME. If this a freight-only line, a tax-only line, or a line with no item, this column is optional. If LINE_TYPE = 'LINE' and you are passing a dummy line for either a tax-only or freight-only line, AutoInvoice ignores what you enter here. If LINE_TYPE = 'TAX', 'CHARGES', or you are passing freight for a specific line, do not enter a value in this column. For credit memos do not enter a value in this column. AutoInvoice uses the unit of measure from the transaction you are crediting.
Validation: Must exist in MTL_UNITS_OF_MEASURE.UOM_CODE. If Line_type = 'CHARGES', then this column must be null.
Destination: RA_CUSTOMER_TRX_LINES.UOM_CODE

118- UOM_NAME : Enter the unit of measure name for this transaction. If LINE_TYPE = 'LINE' and the line has an item you must enter either a value in this column or in UOM_CODE. If this a freight-only line, a tax-only line, or a line with no item, this column is optional. If LINE_TYPE = 'LINE' or you are passing header freight, and you are passing a dummy line for either a tax-only or freight-only line, AutoInvoice ignores what you enter here. If LINE_TYPE = 'TAX', 'CHARGES', or you are passing freight for a specific line, do not enter a value in this column. For credit memos do not enter a value in this column. AutoInvoice uses the unit of measure from the transaction you are crediting.
Validation: Must exist in MTL_UNITS_OF_MEASURE.UNIT_OF_ MEASURE. If LINE_TYPE = 'CHARGES' then this column must be null.
Destination: None

119- UNIT_SELLING_ PRICE : Enter the selling price per unit for this transaction. If LINE_TYPE = 'LINE', 'CHARGES', or you are passing header freight, this column is optional. If you do not enter a value in this column, AutoInvoice defaults to the amount in RA_INTERFACE_LINES.AMOUNT as the extended amount for this transaction. If LINE_TYPE = 'LINE' or you are passing header freight, and you are passing a dummy line for either a tax-only or freight-only line, AutoInvoice ignores what you enter here. If LINE_TYPE = 'TAX' or you are passing freight for a specific line, do not enter a value in this column.
Validation: None
Destination: RA_CUSTOMER_TRX_LINES.UNIT_SELLING_ PRICE

120- UNIT_STANDARD_ PRICE : Enter the standard price per unit for this transaction. If LINE_TYPE = 'LINE', 'CHARGES', or you are passing header freight, this column is optional. If LINE_TYPE = 'TAX' or you are passing freight for a specific line, do not enter a value in this column. For credit memos do not enter a value in this column. AutoInvoice uses the unit standard price from the transaction you are crediting.
Validation: None
Destination: RA_CUSTOMER_TRX_LINES. UNIT_STANDARD_PRICE

121- USSGL_ TRANSACTION_ CODE : Enter the transaction code for this transaction. If this transaction is linked to another transaction, you must enter the same transaction code as the one to which it is linked. This column is optional.
Validation: Must be a valid transaction code as defined in your value set for this flexfield.
Destination: RA_CUSTOMER_TRX_LINES.USSGL_TRANSACTION_CODE

122- USSGL_ TRANSACTION_ CODE_CONTEXT : This column is not currently used by AutoInvoice.
Validation: None
Destination: None

123- VAT_TAX_ID : This column is used by AutoInvoice and should be left null. If you enter a value in TAX_CODE, AutoInvoice defaults a value in this column.
For credit memos AutoInvoice defaults to the VAT tax id of the transaction you are crediting.
Validation: None
Destination: RA_CUSTOMER_TRX_LINES.VAT_TAX_ID

124- WAYBILL_NUMBER : Enter the waybill number for this transaction.
If LINE_TYPE = 'LINE', 'CHARGES', or you are passing header freight, this column is optional.
If LINE_TYPE = 'TAX' or you are passing freight for a specific line do not enter a value in this column.
For credit memos do not enter a value in this column. AutoInvoice uses the waybill number from the transaction you are crediting.
Validation: None
Destination: RA_CUSTOMER_TRX.WAYBILL_NUMBER

RA_INTERFACE_SALESCREDITS

This table stores sales credit information for your transactions. This table must be populated if your AutoAccounting is set up to derive segment values based on the salesrep. If AutoAccounting does not depend on salesrep, then the value you enter in the Require Salesrep field of the System Options window and Allow Sales Credits field in the Transaction Sources window will determine whether you must enter sales credit information. See: AutoAccounting and Defining Receivables System Options.
If you are importing invoices, debit memos and on account credits and your system option requires salesperson, you must provide sales credit information, regardless of the value entered in the Allow Sales Credit field for your transaction batch source.
If you are importing credit memos and your system option requires that you enter a salesperson, you can provide sales credit information. If you do not provide sales credit information, AutoInvoice uses sales credit information from the invoice you are crediting. If the invoice you are crediting does not have sales credit information, AutoInvoice creates a 100% 'No Sales Credit' line for this invoice. This sales credit line is then used to determine the sales credit amount for the credit memo.
Regardless of the type of transaction you are importing, if your system option does not require salesperson, but your transaction batch source allows sales credits, you can provide sales credit information. AutoInvoice will validate it and pass this information with your transaction. If your system option does not require salesperson and your transaction batch source does not allow sales credits, do not provide sales credit information. AutoInvoice ignores any values that you pass.

1- ATTRIBUTE1-15 : Enter the Descriptive Flexfield attribute information for this sales or revenue credit assignment. Descriptive Flexfield attributes allow you to store additional columns, the contents of which you define. These columns are optional.
Validation: None
Destination: RA_CUST_TRX_LINES_SALESREPS. ATTRIBUTE1-15

2- ATTRIBUTE_ CATEGORY : Enter the Descriptive Flexfield category information for this sales credit assignment. Descriptive Flexfield categories allow you to store different categories of attributes. This column is optional.
Validation: None
Destination: RA_CUST_TRX_LINE_SALESREPS.ATTRIBUTE_CATEGORY

3- INTERFACE_LINE_ ATTRIBUTE1-15 : Enter the same Transaction Flexfield for the transaction with which you want to associate this sales or revenue credit assignment. The values you enter here provide you with an audit trail from Receivables back to your original system. You must enter a value for each attribute you enabled.
INTERFACE_LINE_ CONTEXT
Enter the context name of the Transaction Flexfield data that you entered in RA_INTERFACE_SALESCREDITS. INTERFACE_LINE_ATTRIBUTE1-15. You must enter a value.
Validation: None
Destination: None

4- INTERFACE_LINE_ID : This column is used by AutoInvoice and should be left null. AutoInvoice defaults a value into this column using RA_INTERFACE_SALESCREDITS.INTERFACE_LINE_ ATTRIBUTE1-15.
Validation: None
Destination: RA_CUST_TRX_LINE_SALESREPS.CUSTOMER_TRX_LINE_ID

5- This column is used by AutoInvoice and should be left null. AutoInvoice defaults a value into this column using the sequence RA_CUST_TRX_LINE_SALESREPS_S.
Validation: None
Destination: RA_CUST_TRX_LINE_SALESREPS.CUST_TRX_ LINE_SALESREP_ID

6- INTERFACE_STATUS : This column is used by AutoInvoice and should be left null.
Validation: None
Destination: None

7- LAST_UPDATE_ LOGIN : This column is used by AutoInvoice and should be left null. AutoInvoice updates this column when it selects rows from the RA_INTERFACE_SALESCREDITS table for processing.
Validation: None
Destination: None

8- REQUEST_ID : This column is used by AutoInvoice and should be left null.
Validation: None
Destination: None

9- SALES_CREDIT_ AMOUNT_SPLIT : Enter the sales credit amount for this salesperson. This column is optional. Depending on the value you entered for your batch source you must enter either a value in this column or in SALES_CREDIT_PERCENT_SPLIT. If you specify the sales credit percent in your batch source, AutoInvoice defaults a value in this column.
Validation: If the sales credit for this sales credit assignment is of type Quota, the sum of sales credit amounts for a transaction must equal the amount of the transaction.
Destination: RA_CUST_TRX_LINE_SALESREPS. REVENUE_AMOUNT_SPLIT if the sales credit type is Quota. RA_CUST_TRX_LINE_SALESREPS. NON_REVENUE_AMOUNT_SPLIT if the sales credit type is not Quota.

10- SALES_CREDIT_ PERCENT_SPLIT : Enter the sales credit percent for this salesperson. This column is optional. Depending on the value you entered for your batch source you must enter either a value in this column or in SALES_CREDIT_AMOUNT_SPLIT. If you specify the sales or revenue credit amount in your batch source, AutoInvoice defaults a value in this column.
Validation: Your sales or revenue credit percent must be between 0 and 100, and if sales credit type is Quota, the sales credit percentage for a transaction must sum to 100.

11- SALES_CREDIT_ TYPE_ID : Enter the id of the sales credit type for this sales credit assignment. This column is optional. Depending on the value you entered for your batch source you must enter either a value in this column or in SALES_CREDIT_TYPE_NAME. If you specify the sales credit type name in your batch source, AutoInvoice defaults a value in this column.
Validation: Must exist in SO_SALES_CREDIT_TYPES.SALES_CREDIT_ TYPE_ID

Destination: None

12- SALES_CREDIT_ TYPE_NAME : Enter the name of the sales credit type for this sales credit assignment. This column is optional. Depending on the value you entered for your batch source you must enter either a value in this column or in SALES_CREDIT_TYPE_ID.
Validation: Must exist in SO_SALES_CREDIT_TYPES.NAME
Destination: None

13- SALESREP_ID : Enter the salesperson id for this sales credit assignment. This column is optional. Depending on the value you entered for your batch source you must enter either a value in this column or in SALESREP_NUMBER. If you specify the salesperson number in your batch source, AutoInvoice defaults a value in this column.
Validation: Must exist in RA_SALESREPS.SALESREP_ID
Destination: RA_CUST_TRX_LINE_SALESREPS.SALESREP_ID

14- SALESREP_NUMBER : Enter the salesperson number for this sales credit assignment. This column is optional. Depending on the value you entered for your batch source you must enter either a value in this column or in SALESREP_ID.
Validation: Must exist in RA_SALESREPS.SALESREP_NUMBER
Destination: None

RA_INTERFACE_DISTRIBUTIONS

If you do not use AutoAccounting, you must enter accounting distributions for your transactions. Otherwise, AutoInvoice does not require you to enter accounting distributions for your transactions.
If your accounting distributions are for transactions that use accounting rules, you must enter the percentages, but not the amounts. If you enter the amounts, AutoInvoice will ignore those values.
If your accounting distributions are for transactions that do not use accounting rules, you can enter either the percentages or amounts, depending on the value you entered for your batch source. If you enter an amount, AutoInvoice requires that the distribution amounts sum to the amount of the transaction. If you enter a percent, AutoInvoice requires that the distribution percentages sum to 100 for each account class that you pass.
Distributions is this table are linked to the appropriate transaction lines in the ra_interface_lines via the transaction flexfield. Though the distribution for 'REC' account class is at the invoice level, it may be linked to any transaction line of the invoice in ra_interface_lines. AutoInvoice will then correctly transfer all distributions to RA_CUST_TRX_LINE_GL_DIST.

1- ACCOUNT_CLASS : Enter the account class for this accounting distribution. AutoInvoice uses the account class you enter here to determine the type of account you are supplying for this accounting distribution. You must enter a value for this column.
Validation: Must be either 'REV', 'FREIGHT', 'TAX', 'REC', 'CHARGES', 'UNBILL', or 'UNEARN'. If the transaction uses the 'Advance Invoice' invoicing rule, do no enter 'UNBILL' in this column. If the transaction uses the 'Arrears Invoice' invoicing rule, do not enter 'UNEARN' in this column.
Destination: RA_CUST_TRX_LINE_GL_DIST. ACCOUNT_CLASS

2- ACCTD_AMOUNT : This column is optional. If you enter 'AMOUNT' for your batch source option 'Revenue Account Allocation', then AutoInvoice will accept whatever is passed in this column without validation. If this column is null, then AutoInvoice will compute the accounted amount for this distribution line.
Validation: None
Destination: None

3- AMOUNT : Enter the amount for this accounting distribution. If this accounting distribution is for a transaction that does not use an accounting rule and depending on the value you entered for your batch source, you must enter either a value in this column or in PERCENT. If you specify the percent in your batch source, AutoInvoice computes the value in this column. Do not enter a value in this column if this accounting distribution is for a transaction which uses an accounting rule or if this distribution is a receivables ('REC') account. If this distribution is for a receivables account, you must enter 100 in RA_INTERFACE_DISTRIBUTIONS.PERCENT.
If this line has AMOUNT_INCLUDES_TAX set to Yes, the sales credits and line amounts for this column must include tax.
Validation: If this transaction does not use an accounting rule, the sum of all distribution amounts for this transaction of a given line type must equal the amount for the transaction. AutoInvoice corrects amounts that have incorrect currency precision.
Destination: RA_CUST_TRX_LINE_GL_DIST.AMOUNT

4- ATTRIBUTE1-15 : Enter the Descriptive Flexfield attribute information for this accounting distribution. Descriptive Flexfield attributes allow you to store additional columns, the contents of which you define. These columns are optional.
Validation: None
Destination: RA_CUST_TRX_LINE_GL_DIST.ATTRIBUTE1-15

5- ATTRIBUTE_ CATEGORY : Enter the Descriptive Flexfield category information for this accounting distribution. Descriptive Flexfield categories allow you to store different categories of attributes. This column is optional.
Validation: None
Destination: RA_CUST_TRX_LINE_GL_DIST. ATTRIBUTE_CATEGORY

6- CODE_ COMBINATION_ID : Enter the code combination id of the Accounting Flexfield for this accounting distribution. This column is optional. Depending on the value you entered for your batch source you must enter either a value in this column or a combination of segment values in SEGMENT1-30. If you specify the combination of segment values in your batch source, AutoInvoice defaults a value in this column.
Validation: Must exist in GL_CODE_COMBINATIONS. CODE_COMBINATION_ID
Destination: RA_CUST_TRX_LINE_GL_DIST. CODE_COMBINATION_ID

7- COMMENTS : Enter comments about this accounting distribution. This column is optional.
Validation: None
Destination: RA_CUST_TRX_LINE_GL_DIST.COMMENTS

8- INTERFACE_ DISTRIBUTION_ID : This column is used by AutoInvoice and should be left null. AutoInvoice defaults a value into this column using the sequence RA_CUST_TRX_LINE_GL_DIST_S. This is the primary key for RA_INTERFACE_DISTRIBUTIONS.
Validation: None
Destination: RA_CUST_TRX_LINE_GL_DIST. CUST_TRX_LINE_GL_DIST_ID

9- INTERFACE_LINE_ ATTRIBUTE1-15 : Enter the same Line Transaction Flexfield for the transaction with which you want to associate this accounting distribution. You must enter a value for each attribute you enabled for the Line Transaction Flexfield.
Validation: None
Destination: None

10- INTERFACE_LINE_ CONTEXT : This is a required column in AutoInvoice. Enter the context of the Line Transaction Flexfield entered in columns INTERFACE_LINE_ATTRIBUTE1-15.
Validation: If you pass lines with global context set this column to 'Global Data Elements'
Destination: RA_CUSTOMER_TRX_LINES>INTERFACE_LINE_CONTEXT

11- INTERFACE_LINE_ID : This column is used by AutoInvoice and should be left null. AutoInvoice defaults a value into this column using INTERFACE_LINE_ATTRIBUTE1-15 and INTERFACE_LINE_CONTEXT.
Validation: None
Destination: RA_CUST_TRX_LINE_GL_DIST. CUSTOMER_TRX_LINE_ID

12- INTERFACE_STATUS : This column is used by AutoInvoice and should be left null.
Validation: None
Destination: None

13- LAST_UPDATE_ LOGIN : This column is used by AutoInvoice and should be left null. AutoInvoice updates this column when it selects rows from the RA_INTERFACE_DISTRIBUTIONS table for processing.
Validation: None
Destination: None

14- PERCENT : Enter the percent for this accounting distribution. If this accounting distribution is for a transaction that does not use an accounting rule and depending on the value you entered for your batch source, you must enter either a value in this column or in AMOUNT. If you specify the amount in your batch source, AutoInvoice defaults a value in this column. If this accounting distribution is for a transaction which uses an accounting rule, you must enter a value in this column.
Validation: The sum of all accounting distribution percentages for a transaction must sum to 100 for an account class.
Destination: RA_CUST_TRX_LINE_GL_DIST.PERCENT

15- REQUEST_ID : This column is used by AutoInvoice and should be left null.
Validation: None
Destination: None

16- SEGMENT1-30 : Enter an Accounting Flexfield value to each segment you enable in Receivables. For example, if you enable six Accounting Flexfield segments, you must enter six values in columns SEGMENT1-6. Be sure to enter the correct segment value. For example, value '01' is not the same as '1'.
Depending on the value you entered for your batch source, you must enter either a combination of segment values in these columns or a value in CODE_COMBINATION_ID.
Validation: Valid combination of Accounting Flexfield segment values must exist in GL_CODE_COMBINATIONS.
Destination: None

RA_INTERFACE_ERRORS

This table stores information about interface data that failed validation. The information in this table will be used to generate the AutoInvoice Validation report. AutoInvoice identifies all errors for each transaction line, thus reducing multiple validation and correction cycles. For more information, see: AutoInvoice Reports.

1- INTERFACE_ LINE_ID : If both INTERFACE_SALESCREDIT_ID and INTERFACE_DISTRIBUTION_ID are null, then the row in RA_INTERFACE_LINES associated with this INTERFACE_LINE_ID failed validation.
Validation: None
Destination: None

2- INTERFACE_ SALESCREDIT_ID : If this column is not null, then the row in RA_INTERFACE_SALESCREDITS associated with this INTERFACE_SALESCREDIT_ID failed validation.
Validation: None
Destination: None

3- INTERFACE_ DISTRIBUTION_ID : If this column is not null, then the row in RA_INTERFACE_DISTRIBUTIONS associated with this INTERFACE_DISTRIBUTION_ID failed validation.
Validation: None
Destination: None

4- INVALID_VALUE : The invalid value that failed validation displays in this column, if applicable.
Validation: None
Destination: None

5- LINK_TO_LINE_ID : This column displays the INTERFACE_LINE_ID of the line to which this line that failed validation is linked. For example, you have a tax line that fails and is linked to an invoice line that fails. In this case, the column stores the INTERFACE_LINE_ID of the invoice line.
Validation: None
Destination: None

6- MESSAGE_TEXT : The message text is stored in this column.
Validation: None
Destination: None

Customer Interface Tables

2007-11-11T02:06:00.000+05:30

Customer Interface Table Descriptions and Validation

1- RA_CUSTOMERS_INTERFACE
This table stores customer, address, and business purpose information. You do not have to enter values in this table if you do not want to import customers, addresses, or business purposes.

1- ADDRESS1 through 4: Enter the address for your customer in these four columns. You can enter up to four lines of an address.
Validation: If you enter a value in ORIG_SYSTEM_ADDRESS_REF, you must enter a value in ADDRESS1. For multiple rows with the same address reference, insert values in address 1-4.
Destination:
1- RA_ADDRESSES.ADDRESS1,
2- RA_ADDRESSES.ADDRESS2,
3- RA_ADDRESSES.ADDRESS3,
4- RA_ADDRESSES.ADDRESS4

2- CITY STATE PROVINCE COUNTY POSTAL_CODE COUNTRY: Enter the city, state, province, county, and postal code for this customer's address. You must enter values that have already been defined in AR_LOCATION_VALUES if Address Validation is set to 'Error' and you are calculating sales tax. You must do this for each address component on which your tax location flexfield structure is based.

If Address Validation is set to 'No Validation' and you pass a value that does not exist in AR_LOCATION_VALUES, Customer Interface inserts this value into AR_LOCATION_VALUES.
You must always enter a value for Country.
Validation: The county must exist in FND_TERRITORIES.
Destination:
RA_ADDRESSES.CITY,
RA_ADDRESSES.STATE,
RA_ADDRESSES.PROVINCE,
RA_ADDRESSES.COUNTY
RA_ADDRESSES.POSTAL_CODE,
RA_ADDRESSES.COUNTRY

3- ADDRESS_KEY: This column is not currently used by Customer Interface.

4- BILL_TO_ORIG_ ADDRESS_REF: Enter the Bill-To location that you want to associate with the Ship-To address on this record.
Validation: You can enter a value only if the SITE_USE_CODE column in this record is 'Ship-To'. Also, the Bill-To address must exist for this customer or any related customers.
Destination: RA_SITE_USES.BILL_TO_SITE_USE_ID

5- CUSTOMER_ ATTRIBUTE_ CATEGORY: Enter Descriptive Flexfield category information. These columns are optional.

6- ADDRESS_ ATTRIBUTE_ CATEGORY
7- SITE_USE_ ATTRIBUTE_ CATEGORY
Validation: None
Destination:
RA_CUSTOMERS.ATTRIBUTE_CATEGORY,
RA_ADDRESSES.ATTRIBUTE_CATEGORY,
RA_SITE_USES.ATTRIBUTE_CATEGORY

8- CUSTOMER_ ATTRIBUTE_1 to 15: Enter Descriptive Flexfield information. These columns are optional.

9- ADDRESS_ ATTRIBUTE_1 to 15
10- SITE_USE_ ATTRIBUTE_1 to 25
Validation: None
Destination:
RA_CUSTOMERS.ATTRIBUTE1 to 15,
RA_ADDRESSES.ATTRIBUTE1 to 15,
RA_SITE_USES.ATTRIBUTE1 to 25

10- CUSTOMER_ CATEGORY_CODE: Enter a category to categorize your customer. Use customer categories that you previously defined in the QuickCodes window. This column is required.
Validation:
AR_LOOKUPS.LOOKUP_CODE where LOOKUP_TYPE = 'CUSTOMER_CATEGORY'
Destination: RA_CUSTOMERS.CUSTOMER_CATEGORY_ CODE

11-CUSTOMER_ CLASS_CODE: Enter the customer class for this customer. Use customer classes that you previously defined in the QuickCodes window. This column is optional.
Validation:
AR_LOOKUPS.LOOKUP_CODE where LOOKUP_TYPE = 'CUSTOMER CLASS'
Destination: RA_CUSTOMERS.CUSTOMER_CLASS

12-CUSTOMER_KEY: This column is not currently used by Customer Interface.

13-CUSTOMER_NAME: Enter the name of your customer. This column is required.
Validation:
The same customer reference cannot have different customer names within this table.
Destination: RA_CUSTOMERS.CUSTOMER_NAME

14- CUSTOMER_ NUMBER: Enter this customer's number.
Validation: Must be null if you are using Automatic Customer Numbering. Must exist if you are not using Automatic Customer Numbering. This value must be unique within RA_CUSTOMERS.
Destination: RA_CUSTOMERS.CUSTOMER_NUMBER

15- CUSTOMER_STATUS: Enter the status of this customer. This column is required.
Validation: Must equal 'A' for Active or 'I' for Inactive.
Destination: RA_CUSTOMERS.STATUS

16- CUSTOMER_TYPE: Enter 'Internal' or 'External' to indicate customer type for this customer. This column is optional.
Validation: AR_LOOKUPS.LOOKUP_CODE where LOOKUP_TYPE = 'CUSTOMER_TYPE' Multiple rows with the same customer reference must have the same customer type.

17- CUST_TAX_CODE SITE_USE_TAX_ CODE: Enter the tax code that you want to assign to this customer or business purpose, depending on the column you choose. You must use tax codes that you previously defined in the Tax Codes and Rates window. These columns are optional.
Validation: Must exist in AR_VAT_TAX.
Destination: RA_CUSTOMERS.TAX_CODE RA_SITE_USES.TAX_CODE

18- CUST_TAX_ EXEMPT_NUM: This column is not currently used by Customer Interface and must be left blank.
Validation: None
Destination: None

19- CUST_TAX_ REFERENCE: Enter the tax registration number for this customer. This column is optional.
Validation: None
Destination: RA_CUSTOMERS.TAX_REFERENCE

20- CUST_SHIP_ VIA_CODE SITE_SHIP_ VIA_CODE: Enter the freight carrier you want to assign to this customer or business purpose, depending on the column you choose. Use freight carriers that you previously defined in the Freight Carriers window. This column is optional.
Validation: Must exist in ORG_FREIGHT.
Destination: RA_CUSTOMERS.SHIP_VIA, RA_SITE_USES.SHIP_VIA

21- CREATED_BY:Enter the user id that is creating this row. This column is required.
Validation: None
Destination: None

22- CREATION_DATE: Enter the system date. This column is required.
Validation: Must be a valid date format.
Destination: None

23- DEMAND_ CLASS_CODE: Enter the demand class for this address. Use demand classes that you previously defined in the Demand Classes window. This column is optional.
Validation: Must exist in FND_COMMON_LOOKUPS
Destination: RA_SITE_USES.DEMAND_CLASS_CODE

24- INSERT_UPDATE_ FLAG: Specify whether you are inserting a new record or updating an existing record. This column is required.
Validation: 'I' for insert or 'U' for update.
Destination: None

25- INTERFACE_STATUS: This column is used by Customer Interface and should be left null. The Customer Interface program updates this column with all error messages that apply to this interface record. If an interface record has several problems, the Customer Interface program updates this column with multiple error codes.

26- LOCATION: Enter a shorthand name for this business purpose. You use this value to quickly refer to a business purpose during data entry.
Validation: If automatic site numbering is set to No, you must enter a value in this column. If not, do not enter a value. Values for this column must be unique.
Destination: RA_SITE_USES.LOCATION
[Attention: This column is not updatable.]

27- LOCATION_CCID: This column is used by Customer Interface and should be left null. Customer Interface stores the code combination id of valid addresses in this column.
Validation: None
Destination: None

28- LAST_UPDATED_ BY: Enter the user id that is updating this row. This column is required.
Validation: None
Destination: None

29- LAST_UPDATE_ DATE: Enter the system date. This column is required.
Validation: Must be a valid date format.
Destination: None

30- LAST_UPDATE_ LOGIN: Enter the login id. This column is optional.
Validation: None
Destination: None

31- LANGUAGE: Enter the language used by this customer site. This column is optional.
Validation: Must exist in FND_LANGUAGES.NLS_LANGUAGE
Destination: RA_ADDRESSES.LANGUAGE

32- MESSAGE_ TEXT: This column is used by Customer Interface and should be left null.
Validation: None
Destination: None

33- ORIG_SYSTEM_ ADDRESS_REF: Enter a value you can use to uniquely identify this address in your original system.
This column forms part of the primary key for RA_CUSTOMERS_INTERFACE. The primary key is a combination of ORIG_SYSTEM_CUSTOMER_REF, ORIG_SYSTEM_ADDRESS_REF, and SITE_USE_CODE.
To enter multiple addresses for a customer, enter multiple records in RA_CUSTOMERS_INTERFACE with identical customer information, but with different address information.
This column is required if you are either inserting or updating address information.
Validation: Must not already exist in RA_ADDRESSES for insert. Must already exist in RA_ADDRESSES for update.
Destination:RA_ADDRESSES.ORIG_SYSTEM_REFERENCE

34- ORIG_SYSTEM_ CUSTOMER_REF: Enter a value that uniquely identifies this customer in your original system.
This column forms part of the primary key for RA_CUSTOMERS_INTERFACE. The primary key is a combination of ORIG_SYSTEM_CUSTOMER_REF, ORIG_SYSTEM_ADDRESS_REF, and SITE_USE_CODE.
If you are entering a new customer, you must also enter a customer level profile in RA_CUSTOMER_PROFILES_INTERFACE. This column is required.
Validation: Must not exist in RA_CUSTOMERS for insert. Must exist in RA_CUSTOMERS for update. The same customer reference cannot have different customer names within this table. Inserts for this column must be unique.
Destination: RA_CUSTOMERS.ORIG_SYSTEM_REFERENCE

35- ORIG_SYSTEM_ PARENT_REF: Enter the original system reference of the related customer, if there is one. If you enter a value in this column, the system checks RA_SYSTEM_PARAMETERS.CREATE_RECIPROCAL_FLAG to determine whether the application should automatically create the reciprocal relationship. If RA_SYSTEM_PARAMETERS.CREATE_RECIPROCAL_FLAG is set to 'Y', the system creates an additional, opposite entry in RA_CUSTOMER_RELATIONSHIPS. This column is optional.
Validation: Must exist in RA_CUSTOMERS. ORIG_SYSTEM_REFERENCE. Multiple rows with the same customer reference must have the same ORIG_SYSTEM_PARENT_REF.
Destination: Inserts into RA_CUSTOMER_RELATIONSHIPS. CUSTOMER_ID select CUSTOMER_ID from RA_CUSTOMERS where ORIG_SYSTEM_ REFERENCE = RA_CUSTOMERS_INTERFACE. ORIG_SYSTEM_PARENT_REF.

36- PRIMARY_SITE_ USE_FLAG: Enter 'Y' or 'N' to indicate whether this is the primary business purpose. Enter a value in this column only if the INSERT_UPDATE_FLAG is 'Y' and you enter a value in ORIG_SYSTEM_ADDRESS_REF.
Validation: Must have only one primary business purpose for each usage (Bill-To, Ship-To, etc.). Must be null, 'Y,' or 'N'. Mandatory when inserting an address and must be null when the record is for updating purposes. Not updateable.
Destination: RA_SITE_USES.PRIMARY_FLAG

37- REQUEST_ID: This column is used by Customer Interface and should be left null.

38- SITE_USE_CODE: Enter the business purpose for this customer's address. Use business purposes you previously defined in the Receivables QuickCodes window with a QuickCode type of 'Business purposes for a customer address.'
This column forms part of the primary key for RA_CUSTOMERS_INTERFACE. The primary key is a combination of ORIG_SYSTEM_CUSTOMER_REF, ORIG_SYSTEM_ADDRESS_REF, and SITE_USE_CODE.
If you enter a value in ORIG_SYSTEM_ ADDRESS_REF, you must enter a value in this column. To enter multiple business purposes for an address, enter multiple records in RA_CUSTOMERS_INTERFACE with identical customer and address information, but with different site uses. You can only assign one type of business purpose to each address.
Validation: Must equal a value in AR_LOOKUPS. LOOKUP_CODE where LOOKUP_TYPE = 'SITE_USE_CODE'. This column must be null if you are updating PRIMARY_SITE_USE_FLAG, LOCATION, SITE_SHIP_VIA_CODE, SITE_USE_TAX_CODE or SITE_USE_TAX_REFERENCE. Inserts for this column must be unique.
Destination: RA_SITE_USES.SITE_USE_CODE

39- SITE_USE_TAX_ EXEMPT_NUM: This column is not currently used by Customer Interface and must be left blank.
Validation: None
Destination: None

40- SITE_USE_TAX_ REFERENCE: Enter the tax registration number for this site. This column is optional.
Validation: None
Destination: RA_SITE_USES.TAX_REFERENCE

41- VALIDATED_FLAG: This column is used by Customer Interface and should be left null.
Destination: RA_CUSTOMERS.CUSTOMER_TYPE

42- WARNING_TEXT: This column is not currently used by Customer Interface.

43- RA_CUSTOMER_PROFILES_INTERFACE: This table stores customer profile information. If you are entering a new customer in RA_CUSTOMERS_INTERFACE, you must either pass a customer profile class that already exists or customer profile values. You do not have to enter values in this table if you are not entering a new customer or assigning customer profile information to customer addresses.

ACCOUNT_STATUS: Enter the status of this customer's account. Use account statuses you previously defined in the Receivables QuickCodes window with a QuickCode type of 'Account Status.' This column is optional.
Validation: AR_LOOKUPS.LOOKUP_CODE where LOOKUP_TYPE = 'ACCOUNT_STATUS'
Destination: AR_CUSTOMER_PROFILES.ACCOUNT_STATUS

44- ATTRIBUTE_ CATEGORY , AMOUNT_ ATTRIBUTE_ CATEGORY: Enter Descriptive Flexfield category information. These columns are optional.
Validation: None
Destination: AR_CUSTOMER_PROFILES. ATTRIBUTE_CATEGORY AR_CUSTOMER_PROFILE_AMOUNTS. ATTRIBUTE_CATEGORY

45- ATRIBUTE 1 through 15 AMOUNT_ ATTRIBUTE 1 through 15: Enter Descriptive Flexfield information. These columns are optional.
Validation: None
Destination: AR_CUSTOMER_PROFILES. ATTRIBUTE1 through 15 AR_CUSTOMER_PROFILE_AMOUNTS. ATTRIBUTE1 through 15

46- AUTO_REC_INCL_ DISPUTED_FLAG: Specify whether to include debit items that have been placed in dispute when you create automatic receipts for your customers. Defaults to No if null.
Validation: Must equal 'Y' (Yes) or 'N' (No)'. Mandatory when profile class is null.
Destination: AR_CUSTOMER_PROFILES.AUTO_REC_ INCL_DISPUTED_FLAG

47- AUTOCASH_ HIERARCHY_NAME: Enter the AutoCash Rule set to assign to this customer. Use AutoCash Rules sets that you previously defined in the AutoCash Rule Sets window.
Validation: Must exist in AR_AUTOCASH_HIERARCHIES. Mandatory when no profile class specified.
Destination: AR_CUSTOMER_PROFILES. AUTOCASH_HIERARCHY_ID

48- AUTO_REC_MIN_ RECEIPT_AMOUNT: Enter the minimum receipt amount that must be specified for this customer when you create automatic receipts in this currency. This column is optional.
Validation: None
Destination: AR_CUSTOMER_PROFILE_AMOUNTS. AUTO_REC_MIN_RECEIPT_AMOUNT

49- CHARGE_ON_ FINANCE_ CHARGE_FLAG: Specify whether you want to compound interest for this customer.
Validation: Must equal 'Y' (Yes) or 'N' (No). Required if INTEREST_CHARGES is set to 'Y' and no profile class is specified. Do not enter a value if INTEREST_CHARGES is null or set to 'N'.
Destination: AR_CUSTOMER_PROFILES.CHARGE_ON_ FINANCE_CHARGE_FLAG

50- CLEARING_DAYS: Enter the number of clearing days for this customer profile.
Validation: Must be an integer greater than or equal to zero.
Destination: AR_CUSTOMER_PROFILES.CLEARING_DAYS

51-COLLECTOR_NAME: Enter the collector assigned to this customer profile.
Validation: Must be unique in AR_COLLECTORS and STATUS = 'A' (Active). Mandatory when no profile class specified.
Destination: AR_CUSTOMER_PROFILES.COLLECTOR_ID (derived from CUSTOMER_NAME)

52- CREATED_BY: Enter the user id that is creating this row. This column is required.
Validation: None
Destination: None

53- CREATION_DATE: Enter the system date. This column is required.
Validation: Must be a valid date format.
Destination: None

54- CREDIT_BALANCE_ STATEMENTS: Specify whether to send statements to customers with credit balances.
Validation: Must equal 'Y' (Yes) or 'N' (No) Must be 'N' when STATEMENTS = 'N.' Mandatory when no profile class specified. Mandatory when STATEMENTS = Yes. Must be null when STATEMENTS is null.
Destination: AR_CUSTOMER_PROFILES.CREDIT_BALANCE_STATEMENTS

55- CREDIT_HOLD: Specify whether to put a hold on your customer's credit.
Validation: Must equal 'Y' (Yes) or 'N' (No)'.
Destination: AR_CUSTOMER_PROFILES.CREDIT_HOLD

56- CREDIT_RATING: Enter the credit rating for this customer. Use credit ratings you previously defined in the Receivables QuickCodes window using the QuickCode Type 'Credit rating for customers.' This column is optional.
Validation: AR_LOOKUPS.LOOKUP_CODE where LOOKUP_TYPE = 'CREDIT_RATING'
Destination: AR_CUSTOMER_PROFILES.CREDIT_RATING

57- CURRENCY_CODE: Enter a currency code to define customer profile amounts for this customer. Use currency codes previously defined in the Currencies window. Regardless of the value stored in INSERT_UPDATE_FLAG, Customer Interface always inserts and updates customer profile amount values you pass in this table. You must enter a value if any one of the following columns have values:
INTEREST_RATE
MIN_DUNNING_AMOUNT
MIN_DUNNING_INVOICE_AMOUNT
MIN_FC_BALANCE_AMOUNT
MIN_FC_INVOICE_AMOUNT
MIN_STATEMENT_AMOUNT
OVERALL_CREDIT_LIMIT
TRX_CREDIT_LIMIT
Validation: Must exist in FND_CURRENCIES. Mandatory when a profile amount value is populated. (Profile amount columns are listed above.)
Destination: AR_CUSTOMER_PROFILE_AMOUNTS. CURRENCY_CODE

58- CUSTOMER_PROFILE_CLASS_NAME: Enter the name of the customer profile class you want to assign to this customer or Bill-To address.
If you enter a value in this column, the system will use the profile values associated with this customer profile class. However, you can override these default values by passing new values in the appropriate columns. This column is optional.
If you do not enter a value in this column you must enter values in the following columns:
COLLECTOR_NAME
CREDIT_BALANCE_STATEMENTS
CREDIT_CHECKING
AUTO_REC_INCL_DISPUTED_FLAG
DISCOUNT_TERMS
DUNNING_LETTERS (if 'Y', you must also enter a value in DUNNING_LETTER_SET_NAME)
INTEREST_CHARGES (if 'Y', you must also enter values in INTEREST_PERIOD_DAYS and CHARGE_ON_FINANCE_CHARGE_FLAG.)
STATEMENTS (if 'Y', you must also enter a value in STATEMENT_CYCLE_NAME.)
TOLERANCE
TAX_PRINTING_OPTION
OVERRIDE_TERMS
GROUPING_RULE_NAME
Validation: Must equal AR_CUSTOMER_PROFILE_CLASSES. NAME and STATUS = 'A' (Active)
Destination: AR_CUSTOMER_PROFILES. CUSTOMER_PROFILE_CLASS_ID (derived from CUSTOMER_PROFILE_CLASS_NAME)

59- DISCOUNT_TERMS, CREDIT_CHECKING, DUNNING_LETTERS, INTEREST_CHARGES, STATEMENTS: Specify whether to allow discounts, check credit, send dunning letters, charge interest or and send statements.
Validation: Must equal 'Y' (Yes) or 'N' (No). Mandatory when no profile class specified.
Destination: AR_CUSTOMER_PROFILES.DISCOUNT_TERMS AR_CUSTOMER_PROFILES.CREDIT_CHECKING
AR_CUSTOMER_PROFILES. DUNNING_LETTERS
AR_CUSTOMER_PROFILES. INTEREST_CHARGES AR_CUSTOMER_PROFILES.STATEMENTS

60- DISCOUNT_ GRACE_DAYS: Enter the number of days after the discount date that this customer can still take discounts.
Validation: Number must be non-negative (must be >=0). Must be null when DISCOUNT_TERMS is null or 'No'.
Destination: AR_CUSTOMER_PROFILES.DISCOUNT_ GRACE_DAYS

61- DUNNING_LETTER_ SET_NAME: Enter the dunning letter set to associate with this customer. Use dunning letters that you previously defined in the Dunning Letter Sets window.
Validation: Must exist in AR_DUNNING_LETTER_SETS. Mandatory when DUNNING_LETTERS is Yes. Must be null when DUNNING_LETTERS is No or null.
Destination: AR_CUSTOMER_PROFILES.DUNNING_ LETTER_SET_ID (derived from DUNNING_LETTER_SET_NAME)

62- GROUPING_ RULE_NAME: Enter the grouping rule to assign to this customer. Use grouping rules you previously defined in the Grouping Rules window.
Validation: Must exist in RA_GROUPING_RULES. Mandatory when no profile class is specified.
Destination: AR_CUSTOMER_PROFILES.GROUPING_ RULE_ID (derived from GROUPING_RULE_NAME)

63- INTERFACE_STATUS: This column is used by Customer Interface and should be left null. The Customer Interface program updates this column with all error messages which apply to this interface record. If an interface record has several problems, the Customer Interface program updates this column with multiple error codes which are described later in this section.
Validation: None
Destination: None

64- INSERT_ UPDATE_FLAG: Enter a value to indicate whether you are inserting a new record or updating an existing record.
Regardless of the value you enter in this column, you cannot insert or update profile information in the following columns:
CURRENCY_CODE,
AUTO_REC_MIN_RECEIPT_AMOUNT,
INTEREST_RATE,
MAX_INTEREST_CHARGE,
MIN_DUNNING_AMOUNT,
MIN_DUNNING_INVOICE_AMOUNT,
MIN_FC_BALANCE_AMOUNT,
MIN_FC_INVOICE_AMOUNT,
MIN_STATEMENT_AMOUNT,
OVERALL_CREDIT_LIMIT,
TRX_CREDIT_LIMIT,
AMOUNT_ATTRIBUTE_CATEGORY and
AMOUNT_ATTRIBUTE1 through AMOUNT_ATTRIBUTE15.
If you are tying to insert new profile amount information, Customer Interface will automatically insert this information even if this column is set to 'U.' For example, if you want to update the tax printing option value for a record that you have already inserted and at the same time enter a new currency code for this customer profile, enter 'U' in this column. Customer Interface will automatically update the tax printing option value and automatically insert the new currency code.
This column is required.
Validation: I' for insert, 'U' for update
Destination: None

65- INTEREST_ PERIOD_DAYS: Enter the number of days to which the interest rate refers.
Validation: Number must be positive. Mandatory when INTEREST_CHARGES is Yes. Must be null when INTEREST_CHARGES is No or null.
Destination: AR_CUSTOMER_PROFILES.INTEREST_ PERIOD_DAYS

66- INTEREST_RATE: Enter the interest rate to charge this customer for this currency. This column is optional.
Validation: None
Destination: AR_CUSTOMER_PROFILE_AMOUNTS. INTEREST_RATE

67- LAST_UPDATED_ BY: Enter the user id that is updating this row. This column is required.
Validation: None
Destination: None

68- LAST_UPDATE_ DATE: Enter the system date. This column is required.
Validation: Must be a valid date format.
Destination: None

69- LAST_UPDATE_ LOGIN: Enter the login id. This column is optional.
Validation: None
Destination: None

70- MAX_INTEREST_ CHARGE: Enter the maximum amount of interest to charge this customer in this currency for each invoice. This column is optional.
Validation: None
Destination: AR_CUSTOMER_PROFILE_AMOUNTS. MAX_INTEREST_CHARGE

71- MIN_DUNNING_ AMOUNT: Enter the minimum amount in this currency that must be past due for this customer before you select these customers for dunning. This column is optional.
Validation: None
Destination: AR_CUSTOMER_PROFILE_AMOUNTS. MIN_DUNNING_AMOUNT

72- MIN_DUNNING_ INVOICE_AMOUNT: Enter the minimum invoice amount in this currency that must be past due for this customer before you select these customers for dunning. This column is optional.
Validation: None
Destination: AR_CUSTOMER_PROFILE_AMOUNTS. MIN_DUNNING_INVOICE_AMOUNT

73- MIN_FC_BALANCE_ AMOUNT: Enter the minimum customer balance that you require before you charge this customer finance charges for past due items in this currency. This column is optional.
Validation: None
Destination: AR_CUSTOMER_PROFILE_AMOUNTS. MIN_FC_BALANCE_AMOUNT

74- MIN_FC_INVOICE_ AMOUNT: Enter the minimum invoice balance that you require before you charge this customer finance charges for past due items in this currency. This column is optional.
Validation: None
Destination: AR_CUSTOMER_PROFILE_AMOUNTS. MIN_FC_INVOICE_AMOUNT

75- MIN_STATEMENT_ AMOUNT: Enter the minimum outstanding balance in this currency that this customer must exceed in order for the system to generate a statement. This column is optional.
Validation: None
Destination: AR_CUSTOMER_PROFILE_AMOUNTS. MIN_STATEMENT_AMOUNT

76- ORIG_SYSTEM_ CUSTOMER_REF: Enter the value that represents the customer or Bill-To site for which you are inserting or updating customer profile information.
Validation: For insert, this customer reference must exist in RA_CUSTOMERS or be successfully validated in RA_CUSTOMERS_INTERFACE. For update, this customer reference must exist in RA_CUSTOMERS.
Destination: AR_CUSTOMER_PROFILES.CUSTOMER_ID (Derived from ORIG_SYSTEM_CUSTOMER_REF)

77- ORIG_SYSTEM_ ADDRESS_REF: Enter the value that represents the customer Bill-To address for which you are inserting or updating customer profile information. An active Bill-To business purpose must be associated with this address.
Validation: For insert, this address reference must exist in RA_ADDRESSES or be successfully validated in RA_CUSTOMERS_INTERFACE. For update, this address reference must exist in RA_ADDRESSES.
Destination: AR_CUSTOMER_PROFILES.SITE_USE_ID (derived from ORIG_SYSTEM_ADDRESS_REF)

78- OVERALL_ CREDIT_LIMIT: Enter the total amount of credit to give to this customer in this currency. This column is optional.
Validation: TRX_CREDIT_LIMIT and OVERALL_CREDIT_ LIMIT must both be filled in, or both be null. TRX_CREDIT_LIMIT may not be greater than the OVERALL_CREDIT_LIMIT.

79- OVERRIDE_TERMS: Specify whether you want to be able to enter payment terms that are different from the payment term you enter in STANDARD_TERM_NAME.
Validation: Must equal 'Y' (Yes) or 'N' (No). Mandatory when no profile class is specified.
Destination: AR_CUSTOMER_PROFILES.OVERRIDE_TERMS

80- PAYMENT_ GRACE_DAYS: Enter the number of days you will allow this customer's receipt to be overdue before you will initiate collection action.
Validation: Number must be non-negative (must be >=0).
Destination: AR_CUSTOMER_PROFILES.PAYMENT_ GRACE_DAYS

81- PERCENT_ COLLECTABLE: Enter the percentage of this customer's account balance that you expect to collect regularly. This column is optional.
Validation: Must be between 0 to 100.
Destination: AR_CUSTOMER_PROFILES.PERCENT_ COLLECTABLE

82- REQUEST_ID: This column is used by Customer Interface, and should be left null.
Validation: None
Destination: None

83- RISK_CODE: Enter the risk code for this customer. Use risk codes you previously defined in the QuickCodes window with a QuickCode type of 'Customer credit risk.' This column is optional.
Validation: AR_LOOKUPS.LOOKUP_CODE where LOOKUP_TYPE = 'RISK_CODE'
Destination: AR_CUSTOMER_PROFILES.RISK_CODE

84- STANDARD_ TERM_NAME: Enter the standard payment terms for this customer. Use payment terms that you previously defined in the Payment Terms window. This column is optional.
Validation: Must exist in RA_TERMS. Must have a unique value. Mandatory when no profile class is specified.
Destination: AR_CUSTOMER_PROFILES.STANDARD_ TERMS. (derived from STANDARD_TERM_NAME)

85- STATEMENT_ CYCLE_NAME: Enter the statement cycle to associate with this customer. Use statement cycles that you previously defined in the Statement Cycles window.
Validation: Must exist in AR_STATEMENT_CYCLES. Must be null when STATEMENTS is No or null. Mandatory when STATEMENTS is Yes. Must have a unique value.
Destination: AR_CUSTOMER_PROFILES.STATEMENT_ CYCLE_ID (derived from STATEMENT_CYCLE_NAME)

86- TAX_PRINTING_ OPTION: Enter a tax printing option to indicate how you want to print tax information for this customer's invoices.
Validation: AR_LOOKUPS.LOOKUP_CODE where LOOKUP_TYPE = 'TAX_PRINTING_OPTION'. Mandatory when no profile class specified.
Destination: AR_CUSTOMER_PROFILES. TAX_PRINTING_OPTION

87- TOLERANCE: Enter the percent over the credit limit that this customer can exceed before you will act.
Validation: Must be between -100 and 100. Mandatory when no profile class specified.
Destination: RA_CUSTOMER_PROFILES.TOLERANCE

88- TRX_CREDIT_ LIMIT: Enter the amount of credit for each order that you want to give to this customer in this currency.
Validation: TRX_CREDIT_LIMIT and OVERALL_CREDIT_ LIMIT must both be filled in, or both be null. TRX_CREDIT_LIMIT may not be greater than the OVERALL_CREDIT_LIMIT.
Destination: AR_CUSTOMER_PROFILE_AMOUNTS. TRX_CREDIT_LIMIT

89- VALIDATED_FLAG: This column is used by Customer Interface, and should be left null.
Validation: None
Destination: None
Destination:
AR_CUSTOMER_PROFILE_AMOUNTS. OVERALL_CREDIT_LIMIT

RA_CONTACT_PHONES_INTERFACE
This table stores telephone numbers for customers, addresses and contacts as well as contacts for customers and addresses. You do not have to enter values in this table if you do not want to pass telephone or contact information.

1- CONTACT_ ATTRIBUTE_ CATEGORY,
PHONE_ ATTRIBUTE_ CATEGORY: Enter Descriptive Flexfield category information. These columns are optional.
Validation: None
Destination: RA_CONTACTS.ATTRIBUTE_CATEGORY RA_PHONES.ATTRIBUTE_CATEGORY

2- CONTACT_ ATTRIBUTE 1 through 25, PHONE_ ATTRIBUTE 1 through 15: Enter Descriptive Flexfield information. These columns are optional.
Validation: None
Destination: RA_CONTACTS.ATTRIBUTE1 through 25

3- CONTACT_ FIRST_NAME: Enter the contact's first name. This column is optional.
Validation: None
Destination: RA_CONTACTS.FIRST_NAME

4- CONTACT_ JOB_TITLE: Enter the job title or responsibility for this contact. Use contact job titles that you previously defined in the QuickCodes window. This column is optional.
Validation: AR_LOOKUPS.LOOKUP_CODE where LOOKUP_TYPE = 'JOB_TITLE'
Destination: RA_CONTACTS.JOB_TITLE.

5- CONTACT_ LAST_NAME: Enter the contact's last name. If ORIG_SYSTEM_CONTACT_REF is filled in, then you must enter a value in this column. Otherwise, this column is optional.
Validation: None
Destination: RA_CONTACTS.LAST_NAME

6- CONTACT_TITLE: Enter the title for this contact. This column is optional.
Validation: AR_LOOKUPS.LOOKUP_CODE where LOOKUP_TYPE = 'CONTACT_TITLE'
Destination: RA_CONTACTS.TITLE

7- CREATED_BY: Enter the user id that is creating this row. This column is required.
Validation: None
Destination: None

8- CREATION_DATE: Enter the system date. This column is required.
Validation: Must be a valid date format.
Destination: None

9- INTERFACE_STATUS: This column is used by Customer Interface and should be left null. The Customer Interface program updates this column with all error messages that apply to this interface record. If an interface record has several problems, the Customer Interface program updates this column with multiple error codes.

10- INSERT_ UPDATE_FLAG: Enter a value to indicate whether you are inserting a new record or updating an existing record. This column is required.
Validation: 'I' for insert, 'U' for update.
Destination: None

11- LAST_UPDATED_ BY: Enter the user id that is updating this row. This column is required.
Validation: None
Destination: RA_PHONES.ATTRIBUTE1 through 15

12- LAST_UPDATE_ DATE: Enter the system date. This column is required.
Validation: Must be a valid date format.
Destination: None

13- LAST_UPDATE_ LOGIN: Enter the login id. This column is optional.
Validation: None
Destination: None

14- ORIG_SYSTEM_ CUSTOMER_REF: Enter a value that you can use to uniquely identify this customer in your original system.
Validation: Must equal RA_CUSTOMERS.ORIG_SYSTEM_ REFERENCE for update. If you are entering either contact or telephone information, you must enter a value in this column.
Destination: RA_CUSTOMERS.ORIG_SYSTEM_REFERENCE

15- ORIG_SYSTEM_ ADDRESS_REF: Enter a value that you can use to uniquely identify this address in your original system.
If this column is null, the phone or contact that you enter refers to the customer.
Validation: Must equal RA_ADDRESSES.ORIG_SYSTEM_ REFERENCE for update. If you are entering information that refers to an address, such as a contact or telephone, then you must enter a value in this column.
Destination: RA_ADDRESSES.ORIG_SYSTEM_REFERENCE

16- ORIG_SYSTEM_ CONTACT_REF: Enter a value that you can use to uniquely identify this contact in your original system.
This column forms part of the primary key for RA_CONTACT_PHONES_ INTERFACE. The primary key is a combination of ORIG_SYSTEM_CONTACT_REF and ORIG_SYSTEM_TELEPHONE_ REF.
To enter a contact for a customer, do not enter a value in ORIG_SYSTEM_ ADDRESS_REF.
If you are entering a contact for a specific address, then enter values in both ORIG_ SYSTEM_CUSTOMER_REF and ORIG_SYSTEM_ADDRESS_REF.
Validation: Must equal RA_CONTACTS.ORIG_SYSTEM_ REFERENCE for update. If you are entering contact information or information that refers to a contact, such as a telephone number assigned to a contact, you must enter a value in this column.
Destination: RA_CONTACTS.ORIG_SYSTEM_REFERENCE

17- ORIG_SYSTEM_ TELEPHONE_REF: Enter a value that you can use to uniquely identify this telephone in your original system.
This column forms part of the primary key for RA_CONTACT_PHONES_ INTERFACE. The primary key is a combination of ORIG_SYSTEM_CONTACT_REF and ORIG_SYSTEM_TELEPHONE_REF.
To enter a telephone for a customer, do not enter values in ORIG_SYSTEM_ADDRESS_REF or ORIG_SYSTEM_CONTACT_REF.
To enter a telephone for a specific address, enter values in ORIG_SYSTEM_CUSTOMER_REF and ORIG_SYSTEM_ADDRESS_ REF.
To enter telephones for a specific contact, enter values in ORIG_SYSTEM_CUSTOMER_REF, ORIG_SYSTEM_CONTACT_REF, and ORIG_SYSTEM_ADDRESS_REF, if the contact is associated with an address.
Validation: Must equal RA_PHONES.ORIG_SYSTEM_ REFERENCE. Mandatory when specifying telephone information.
Destination: RA_PHONES.ORIG_SYSTEM_REFERENCE

18- REQUEST_ID: This column is used by Customer Interface and should be left null.

19- TELEPHONE: Enter the telephone number for the customer, address, or contact.
Validation: Mandatory when specifying telephone information (for example, if ORIG_SYSTEM_TELEPHONE_REF is filled in).
Destination: RA_PHONES.PHONE_NUMBER

20- TELEPHONE_ AREA_CODE, TELEPHONE_ EXTENSION: Enter the area code or extension for the telephone number, depending on the column you choose. These columns are optional.
Validation: None
Destination: RA_PHONES.AREA_CODE RA_PHONES.EXTENSION

21- TELEPHONE_TYPE: Enter the type of telephone number such as General, Fax, or Telex. Use telephone types that you previously defined in the QuickCodes window with a QuickCode type of 'Types of communication used in contacting customers.'
Validation: AR_LOOKUPS.LOOKUP_CODE where LOOKUP_TYPE = 'COMMUNICATION_TYPE.' Mandatory when specifying telephone information (for example, if ORIG_SYSTEM_TELEPHONE_REF is filled in).
Destination: RA_CONTACTS.PHONE_TYPE

22- VALIDATED_FLAG: This column is used by Customer Interface and should be left null.

RA_CUSTOMER_BANKS_INTERFACE
This table stores bank information for a customer or for a specific Bill-To address. You do not have to enter values in this table if you do not want to insert or assign customer bank information. If you associate an automatic payment method to a customer or a customer's Bill-To business purpose, you must enter a bank account for this customer.

1- ATTRIBUTE_ CATEGORY: Enter Descriptive Flexfield category information. This column is optional.
Validation: None
Destination: AP_BANK_ACCOUNT_USES.ATTRIBUTE_ CATEGORY

2- ATTRIBUTE 1 through 15: Enter Descriptive Flexfield information. This column is optional.
Validation: None
Destination: AP_BANK_ACCOUNT_USES.ATTRIBUTE 1 through 15

3- BANK_ ACCOUNT_NUM, BANK_ACCOUNT_ CURRENCY_CODE: Enter the account number or currency code for this bank account, depending on the column you choose. This number must be unique within a bank branch.
Validation: If the bank account already exists, do not enter a value. If the bank account does not exist, you must enter a value.
Destination: AP_BANK_ACCOUNT.BANK_ACCOUNT_NUM AP_BANK_ACCOUNTS.CURRENCY_CODE

4- BANK_ACCOUNT_ INACTIVE_DATE: Enter the date that this bank account becomes inactive. This column is optional.
Validation: Must be a valid date format.
Destination: AP_BANK_ACCOUNTS.INACTIVE_DATE

5- BANK_ACCOUNT_ DESCRIPTION: Enter a description for this bank account. This column is optional.
Validation: None
Destination: AP_BANK_ACCOUNTS.DESCRIPTION

6- BANK_ ACCOUNT_CHECK_ DIGITS: Enter the number this bank account prints on checks. This column is optional.
Validation: None
Destination: AP_BANK_ACCOUNT.CHECK_DIGITS

7- BANK_ ACCOUNT_NAME: Enter the bank account name to assign to this customer or Bill-To address. Use the Banks window to define banks and bank accounts for your customers. If the bank account has not already been defined, Customer Interface will try to create it in AP_BANK_ACCOUNTS. This column is required.
Validation: Must exist in AP_BANK_ACCOUNTS or, if it does not exist, values must exist for BANK_ACCOUNT_CURRENCY_CODE, BANK_ACCOUNT_NUM, BANK_NAME, and BANK_BRANCH_NAME.
Destination: AP_BANK_ACCOUNTS.BANK_ACCOUNT_ NAME

8- BANK_NAME, BANK_ BRANCH_NAME: Enter the name of the bank or bank branch for the account you are inserting. If the bank account does not exist, you must enter a value.
Validation: BANK_NAME together with BANK_BRANCH_NAME must be unique. If the bank account already exists, do not enter a value. Bank_Branch_Name is mandatory when the bank account is not defined.
Destination: AP_BANK_ACCOUNTS.BANK_NAME AP_BANK_BRANCHES.BANK_BRANCH_NAME

9- BANK_NUMBER: Enter the number of the bank associated with the bank account.
Validation: Must be unique. If the bank account already exists, do not enter a value. If the bank account does not exist, this column is optional.
Destination: AP_BANK_BRANCHES.BANK_NUMBER

10- BANK_NUM: Enter the number of the bank branch associated with the bank account you are inserting.
Validation: Must be unique. If the bank account already exists, do not enter a value. If the bank account does not exist, this column is optional.
Destination: AP_BANK_BRANCHES.BANK_NUM

11- BANK_BRANCH_ DESCRIPTION: Enter a description for this bank branch. This column is optional.
Validation: None
Destination: AP_BANK_BRANCHES.DESCRIPTION

12- BANK_BRANCH_ ADDRESS 1 through 4: Enter the street address, city, county, state, postal code, or province for this bank branch. These columns are optional.
BANK_ BRANCH_CITY
BANK_ BRANCH_COUNTY
BANK_ BRANCH_STATE
BANK_ BRANCH_ZIP
BANK_ BRANCH_PROVINCE
Validation: None
Destination: AP_BANK_BRANCHES.ADDRESS_LINE1-3
AP_BANK_BRANCHES.CITY
AP_BANK_BRANCHES.STATE
AP_BANK_BRANCHES.ZIP
AP_BANK_BRANCHES.PROVINCE

13- BANK_ BRANCH_COUNTRY: Enter the country for this bank branch. This column is optional.
Validation: Must exist in FND_TERRITORIES.TERRITORY_CODE.
Destination: AP_BANK_BRANCHES.COUNTRY

14- BANK_ BRANCH_PHONE : Enter the telephone number or telephone area code for this bank branch. These columns are optional.
BANK_ BRANCH_ AREA_CODE
Validation: None
Destination: AP_BANK_BRANCHES.PHONE
AP_BANK_BRANCHES.AREA_CODE

15- BANK_BRANCH_EFT_USER_NUMBER: Enter the Electronic Funds Transfer user id. This column is optional.
Validation: None
Destination: AP_BANK_BRANCHES.EFT_USER_NUMBER

16- BANK_ACCOUNT_ ATT_CATEGORY : Enter Descriptive Flexfield category information. These columns are optional.
BANK_ BRANCH_ ATT_CATEGORY
Validation: None
Destination: AP_BANK_ACCOUNTS.ATTRIBUTE_ CATEGORY AP_BANK_BRANCHES.ATTRIBUTE_CATEGORY

17- BANK_ACCOUNT_ ATTRIBUTE 1 through 15, BANK_ BRANCH_ ATTRIBUTE 1 through 15: Enter Descriptive Flexfield information. These columns are optional.
Validation: None
Destination: AP_BANK_ACCOUNTS.ATTRIBUTE1 through 15 AP_BANK_BRANCHES.ATTRIBUTE1 through 15

18- CREATED_BY: Enter the user id that is creating this row. This column is required.
Validation: None
Destination: None

19- CREATION_DATE: Enter the system date. This column is required.
Validation: Must be a valid date format.
Destination: None

20- END_DATE: Enter the date that this bank account becomes inactive. This column is optional.
Validation: End Date cannot be before the start date. Customers can be assigned to multiple bank accounts as long as there is no overlapping date range. Must be a valid date format.
Destination: AP_BANK_ACCOUNT_USES.END_DATE

21- INTERFACE_STATUS: This column is used by Customer Interface and should be left null. The Customer Interface program updates this column with all error messages that apply to this interface record. If an interface record has several problems, the Customer Interface program updates this column with multiple error codes.
Validation: None
Destination: None

22- LAST_UPDATED_ BY: Enter the user id that is updating this row. This column is required.
Validation: None
Destination: None

23- LAST_UPDATE_ DATE: Enter the system date. This column is required.
Validation: Must be a valid date format.
Destination: None

24- LAST_UPDATE_ LOGIN: Enter the login id. This column is optional.
Validation: None
Destination: None

25- ORIG_SYSTEM_ CUSTOMER_REF: Enter the value that represents the customer for which you are inserting bank information. This column is required.
Validation: The customer reference must exist in RA_CUSTOMERS or be successfully validated in RA_CUSTOMERS_INTERFACE.
Destination: AP_BANK_ACCOUNT_USES.CUSTOMER_ID (derived from ORIG_SYSTEM_CUSTOMER_REF)

26- ORIG_SYSTEM_ ADDRESS_REF: Enter the value that represent the customer address for which you are inserting bank information. An active Bill-To business purpose must be associated with this address. This column is required only if you want to insert bank information for a specific Bill-To address.
Validation: For insert, the address reference must exist in RA_ADDRESSES or be successfully validated in RA_CUSTOMERS_INTERFACE (derived from ORIG_SYSTEM_CUSTOMER_REF)
Destination: AP_BANK_ACCOUNT_USES.CUSTOMER_SITE_USE_ID

27- PRIMARY_FLAG: Indicates whether this is the primary bank account for this customer or Bill-To address. This column is required.
Validation: Enter 'Y' or 'N.' Only one primary bank account can exist at either the customer level or address level.
Destination: AP_BANK_ACCOUNT_USES.PRIMARY_FLAG

28- REQUEST_ID: This column is used by Customer Interface, and should be left null.
Validation: None
Destination: None

29- START_DATE: Enter the starting date that this bank account becomes active. This column is required.
Validation: End Date cannot be before the start date. Customers can be assigned to multiple bank accounts as long as there is no overlapping date range. Must be a valid date format.
Destination: AP_BANK_ACCOUNT_USES.START_DATE

30- VALIDATED_FLAG: This column is used by Customer Interface, and should be left null.
Validation: None
Destination: None

RA_CUST_PAY_METHOD_INTERFACE
This table stores payment method information for a customer or for a specific Bill-To address. If you associate an automatic payment method to a customer or a customer's Bill-To address, a bank account must exist for this customer. You do not have to enter values in this table if you do not want to assign a payment method to a customer. You cannot insert payment methods using Customer Interface. You must use the Payment Methods window to create new payment methods.

1- ATTRIBUTE_ CATEGORY, ATTRIBUTE 1 through 15: Enter Descriptive Flexfield category information. This column is optional.
Validation: None
Destination: RA_CUST_RECEIPT_METHODS. ATTRIBUTE_CATEGORY
RA_CUST_RECEIPT_METHODS.ATTRIBUTE 1 through 15

2- CREATED_BY: Enter the user id that is creating this row. This column is required.
Validation: None
Destination: None

3- CREATION_DATE: Enter the system date. This column is required.
Validation: Must be a valid date format.
Destination: None

4- END_DATE: Enter the date that this payment method becomes inactive. This column is optional.
Validation: Customers can be assigned to multiple payment methods as long as there is no overlapping date range. Must be a valid date format.
Destination: RA_CUST_RECEIPT_METHODS.END_DATE

5- INTERFACE_STATUS: This column is used by Customer Interface and should be left null. The Customer Interface program updates this column with all error messages that apply to this interface record. If an interface record has several problems, the Customer Interface program updates this column with multiple error codes.
Validation: None
Destination: None

6- LAST_UPDATED_ BY: Enter the user id that is updating this row. This column is required.
Validation: None
Destination: None

7- LAST_UPDATE_ DATE: Enter the system date. This column is required.
Validation: Must be a valid date format.
Destination: None

8- LAST_UPDATE_ LOGIN: Enter the login id. This column is optional.
Validation: None
Destination: None

9- ORIG_SYSTEM_ CUSTOMER_REF: ATTRIBUTE 1 through 15: Enter the value that represents the customer for which you are inserting a payment method. This column is required.
Validation: The customer reference must exist in RA_CUSTOMERS or be successfully validated in RA_CUSTOMERS_INTERFACE.
Destination: RA_CUST_RECEIPTS_METHODS. CUSTOMER_ID (derived from ORIG_SYSTEM_CUSTOMER_REF)

10- ORIG_SYSTEM_ ADDRESS_REF: Enter the value that represents the customer address for which you are inserting a payment method. An active Bill-To business purpose must be associated with this address. This column is required only if you are inserting a payment method for a specific Bill-To address.
Validation: This address reference must exist in RA_ADDRESSES or be successfully validated in RA_CUSTOMERS_INTERFACE.
Destination: RA_CUST_RECEIPT_METHODS.SITE_USE_ID (derived from ORIG_SYSTEM_ADDRESS_REF)

11- PAYMENT_ METHOD_NAME: Enter the name of the payment method that you want to assign to this customer or Bill-To address. This column is required.
Validation: Must exist in AR_RECEIPT_METHODS.
Destination: RA_CUST_RECEIPTS_METHODS. RECEIPT_METHOD_ID (derived from PAYMENT_METHOD_NAME)

12- PRIMARY_FLAG: Enter 'Y' or 'N' to indicate whether this is the primary payment method for this customer or Bill-To address. This column is required.
Validation: Only one primary payment method can exist at either the customer level or Bill-To address level.
Destination: RA_CUST_RECEIPTS_METHODS. PRIMARY_FLAG

13- REQUEST_ID: This column is used by Customer Interface and should be left null.
Validation: None
Destination: None

14-START_DATE: Enter the starting date that this payment method becomes active. This column is required.
Validation: Customers can be assigned to multiple payment methods as long as there is no overlapping date range. Must be a valid date format.
Destination: RA_CUST_RECEIPT_METHODS.START_DATE

15- VALIDATED_FLAG: This column is used by Customer Interface and should be left null.
Validation: None
Destination: None