In the Oracle API Availability, here is note for Availability in Oracle cash Management.

Bank Statement

Bank Statements Open Interface: Before reconciliation of transactions against a bank statement, information about the statement needs to be entered into the Cash Management system. If the bank provides this information in a flat file, the open interface is used to load the data. Data is loaded by programs written in SQL loader; one program for each type of file provided. The Oracle interface tables to be populated are CE_STATEMENT_HEADERS_INT_ALL, containing header information about the bank statement, and CE_STATEMENT_LINES_INTERFACE, containing the statement line information. The header file contains one record for every account in the bank statement.
Reconciliation
Receipts and payments originating in non-Oracle systems can be reconciled in the Cash Management system using the Reconciliation open interface. However, the open interface view, CE_999_INTERFACE_ V, and open interface package, CE_999_PKG, provided by Oracle, need to be customized first. The Cash Management program automatically retrieves the necessary information from the open interface view for matching statement lines. (The Reconciliation Open Interface is not run as a separate program.)

Normally, the CE_999_INTERFACE_V is defined as a view to the legacy application’s database, and implemented to show all open interface transactions and their status. The view should include available transactions as well as reconciled transactions to bank statements that have not been purged or archived. The CE_999_PKG needs to be customized to access the non-oracle database, lock all transactions and perform any clearing functions so that the open transactions are in sync in both the Oracle and legacy databases. Once the view and package are modified and complete, the Reconciliation program is ready to be run. The reconciliation can be done automatically or manually, as required.

Auto reconciliation: The auto reconciliation program is used to automatically reconcile any bank statement in Oracle Cash Management, assuming the bank statement has been imported into the Cash Management system (a different version of this program does the import of the bank statement, if required). Once the reconciliation program is run, the auto reconciliation Execution Report is reviewed to identify any reconciliation errors that need to be corrected. This report is produced automatically, or can be run, whenever needed.

Manual reconciliation: Manual reconciliation can be used to reconcile any bank statement, whether imported or entered manually. In addition, new bank statement lines can be created while reconciling transactions, as well as update the reconciliation information for a previously manually-or automatically-reconciled statement

Cash Forecasting
Cash forecasting is a planning tool that helps in anticipating the flow of cash in and out of the business, allowing the projection of cash needs and evaluating the company’s liquidity. The Cash Management Forecasting Open Interface allows the utilization of external sources of data as cash inflow and outflow data for flexible cash forecasting.

Two cash forecast source transaction types, Open Interface Inflow and Open Interface Outflow, allow inclusion of external application transaction sources for cash forecasting. Having two separate source transaction types for external source transactions gives an easy way to indicate whether the transaction source consists of cash receipts (inflow) or disbursements (outflow). The Forecasting Open Interface collects cash flow amounts from the external systems, and the Cash Forecasting module summarizes and calculates the data to be included in the cash forecasts along with other Oracle Applications data.

Overview
Auto Lockbox is a service that commercial banks offer corporate customers to enable them to outsource their accounts receivable payment processing. Auto Lockbox eliminates manual data entry by automatically processing receipts that are sent directly to your bank. You can also use Auto Lockbox for historical data conversion. For example, you can use Auto Lockbox to transfer receipts from your previous accounting system into Receivables. Auto Lockbox ensures that the receipts are accurate and valid before transferring them into Receivables.

Benefit of auto lockbox

• Eliminates manual data entry
• Streamlines the application of receipt to outstanding transactions
• Effectively manages cash flow by reducing turnover for converting checks into cash

When can I use lockbox

• apply receipt to outstanding invoice
• import historical receipt data
• auto lockbox report , such as the post quick cash Execution Report, are a good tool to reconcile auto lockbox receipt with the bank transmission

What is inside the lockbox process

This consist of 3 steps process, viz

1. Import: During this step, Lockbox reads and formats the data from your bank file into interface table AR_PAYMENTS_INTERFACE_ALL using a SQL *Loader script.

2. Validation: The validation program checks data in this interface table for compatibility with Receivables. Once validated, the data is transferred into QuickCash tables (AR_INTERIM_CASH_RECEIPTS_ALL and AR_INTERIM_CASH_RCPT_LINES_ALL) . At this point, you can optionally query your receipts in the QuickCash window and change how they will be applied before submitting the final step, Post QuickCash.

3. Post QuickCash: This step applies the receipts and updates your customer’s balances.

Process Flow
Here is schematic data flow and process flow of lockbox process

Set Up
These are the Normal Set Required for Auto lockbox. This is part of AR Set up:

• Define Banks
  • Define Remittance Bank with Account use Internal where checks from customer are deposited.
• Define Receipt Class
  • Define a Receipt class to determine the required processing steps for receipts to which you assign payment methods with this class.
• Define Payment Methods
  • Define a payment method with all receipt accounts.
• Define Receipt Source
  • Define Receipt Batch Source and attach receipt class, payment method and remittance bank account information to the Receipt Source.
• Define Lockbox
  • Define Lockboxes to use the Receivables Autolockbox program.
• Define Transmission Format
  • Define the Transmission Format which Auto Lockbox uses when importing data into Receivables.
• Define AutoCash Rule Set
  • autocash rule sets determine how a quickcash receipt is applied to open debit items.
  • enter a sequence for automatiocally applying receipts
  • select one or more autocash rules for receipt application from the list of autocash Rule options
  • Define AutoCash Rule Sets to determine the sequence of rules that Post
  • QuickCash uses to update Customer’s account balances.
• Control file
  • Create a control file which is used by SQL * Loader to import the data into interface table and it is placed in the directory $AR_TOP/bin
• Data file
  • data are kept into directory $AR_TOP/bin

This is in continuation to API’s availability,Here are the API’s availability in AP.

Credit Card Transaction Processing

• Manual Credit Card Entry: A form is available for entry through the Oracle Payables application.
• Credit Card Transaction Interface Table: This process loads transaction data from the credit card issuer (American Express, Diner’s Club, MasterCard and Visa) into Oracles AP module. Oracle Payable then uses this data to confirm transactions with employees. Once the transactions have been approved the credit card transaction lines are imported into Payables Open Interface using the Credit Card Invoice Interface Summary program. The credit card transactions are then available for final import to Oracle Payables where the transactions become invoices.

Creating Invoices
In Oracle Payables four methods are available for entering an invoice into the system.

• Manual Invoice Entry: Two methods for manual invoice entry exist. Using Oracle Payables system Invoice Workbench which includes the Invoice Batches window and Distribution window users can enter complex invoices, and invoices requiring online validation. In addition this functionality is useful in processing invoices that require special attention such as immediate payment.
• The second method of manual invoice entry, Invoice Gateway, is used when entering high volumes of invoices. Generally these invoices do not require online validation or defaulting of accounting information. After entering invoices using the gateway, the invoice import must be run, at that time validation and defaulting is performed. This method of entry can be used in lieu of invoice interfaces. Although, using the gateway can accomplish similar results to that found with an interface process, manual entry is no substitute.
• Automatic Invoice Creation: Oracle Payables provides functionality to produce periodically recurring invoices. This functionality may be used to substitute manual invoice entry or the payables open interface. In the case of recurring invoices that would normally come from an external system choosing to setup a recurring invoice formula may be an alternative.
• Using Payables Open Interface: Choose this method for processing large volumes of invoices that originate in external system. Additionally, this process is useful in handling employee expense reports generated through self-service applications, expense reports entered by the Payables Department, invoices for employee credit card expenses, Oracle Projects billing and time and expenses, and EDI invoices transferred from the Oracle EDI gateway.

Purchase Order Matching

Oracle Payables can be implemented without Oracle Purchasing, to allow this several purchasing tables are installed initially which must be populated using custom interfaces. Only two-way matching is available when data is loaded using the interface method. Two-way approval verifies that purchase order and invoice information match within your tolerances as follows: Quantity billed on the purchase order shipment is less than or equal to Quantity ordered on the purchase order shipment. Invoice price on the purchase order shipment is less than or equal to Purchase order price on the purchase order shipment.
Receipts can only be matched in an install that also includes Oracle Purchasing.
The only method for interfacing data into the purchasing tables described in this section is through a customized interface from an external source. Note: Interfacing this information is not supported by Oracle.

• Loading PO_HEADERS: Each record in this table represents a purchase order, which is an order for goods or services from a single supplier. Each purchase order may have multiple lines (PO_LINES). In addition, each blanket purchase order may have multiple blanket releases (PO_RELEASES), which release an amount from the blanket.
• Loading PO_LINES: Each record in this table represents a purchase order line, which identifies the items and unit price for the goods ordered on a purchase order. Each purchase order line may have multiple shipments (PO_LINE_LOCATIONS).
• Loading PO_LINE_LOCATIONS: Each record in this table represents a purchase order line, which identifies the items and unit price for the goods ordered on a purchase order. Each purchase order line may have multiple shipments (PO_LINE_LOCATIONS).
• Loading PO_DISTRIBUTIONS/PO_DISTRIBUTIONS_AP_V: Each record in this table/view represents a purchase order distribution, which identifies the account charged for the items on a purchase order shipment.
• Loading PO_RELEASES: Each record in this table represents a blanket release for a purchase order. A blanket release may create multiple shipments.
• Loading AP_INVOICES/AP_INVOICE_DISTRIBUTIONS: Each purchase order shipment can be matched to multiple invoices(AP_INVOICES), and a single invoice may be matched to multiple purchase order shipments. When you match an invoice to a purchase order shipment, Payables creates an invoice distribution AP_INVOICE_DISTRIBUTIONS) from each purchase order distribution on the shipment. When you match an invoice to a single purchase order distribution, Payables creates a single invoice distribution from the purchase order distribution.

Vendor Interface

Existing and new vendors must be loaded into the Oracle Payables application to support payables activities. Two methods may be used to enter vendors into Oracle Applications, manual entry and direct loading using a customized loader program.

• Manual Vendor Loading: Use the Enter Vendor window. Using this functionality vendor header information as well as vendor site information can be entered.
• Vendor Interface: When interfacing vendors into Oracle Applications two tables must be loaded the PO_VENDORS and PO_VENDOR_SITES_ALL. The vendor table contains all header information and the site table contains information about each the vendor locations such as “ship to” and “bill to”. Using this method makes sense when the volume of new vendors is large. Note: Interfacing this information is not supported by Oracle.
• Those who are in 11.5.10 they will find yet another method ie by interface.
  You have to Load data into the staging tables first ie.AP_SUPPLIERS_INT - Supplier Information
  AP_SUPPLIER_SITES_INT - Supplier Sites Information ,AP_SUP_SITE_CONTACT_INT - supplier Contact details This uses Vendor ID, Vendor Site Code to relate the contacts to specific vendor. Once data get loaded three interface program should be kicked out which is as
  • Supplier Open Interface Import.
  • Supplier Sites Open Interface Import
  • Supplier Site Contacts Open Interface Import

This is in continuation to API’s availability,Here are the API’s availability in AR.

Invoices

• Manual Entry and Updating: Manual entry or update of invoices requires the user to have access to the Oracle Application’s Accounts Receivable module and specifically the Enter Invoices form. You can enter and update invoices for valid customers. AR uses AutoAccounting to create the revenue accounting combination based on the invoice line information.
• AutoInvoice Interface: AutoInvoice interface provides a mechanism for transferring large volumes of invoices, credit memos, debit memos, and on-account credits from third-party and legacy systems into Receivables. Information is loaded into the RA_INTERFACE_LINES_ALL (which stores information about each interface line imported) and RA_INTERFACE_SALESCREDITS_ALL (containing the sales credit information) tables then imported into the Oracle Applications by the AutoInvoice Import process.You can also refer my old post for autoinvoice details.

Receipts

• Manual Entry and Updating: Manual entry or update of receipts requires the user to have access to the Oracle Application’s Accounts Receivable module and specifically the Enter Receipts form. You can enter and update receipts for open and future accounting periods.
• AutoLockbox Interface: AutoLockbox interface provides a mechanism for transferring large volumes of payments from bank files or third party systems into Receivables. Information is loaded into the AR_PAYMENTS_INTERFACE_ALL table then imported into the Oracle Applications by the AutoLockbox Import process.
  The AR_PAYMENTS_INTERFACE_ALL table stores imported lockbox information that has not been validated. AutoLockbox creates one row in this table for each record in a transmission. When the validation step of AutoLockbox is run, Oracle Receivables transfers the information from the AR_PAYMENTS_INTERFACE_ALL tables to the AR_INTERIM_CASH_RECEIPTS_ALL and AR_INTERIM_CASH_RCPT_LINES_ALL tables.

Customers

• Manual Entry and Updating: Manual entry or update of customers requires the user to have access to the Oracle Application’s Accounts Receivable module and specifically the Enter Customers form. You can enter and update customers, multiple customer addresses (sites), and multiple contact(s) for each address.
• Customer Interface: The customer interface provides a mechanism for transferring large volumes of customers from third party and legacy systems into Receivables. Information is loaded into the RA_CUSTOMER_INTERFACE, RA_CONTACT_PHONES_INTERFACE, RA_CUSTOMER_PROFILES_INTERFACE, RA_CUSTOMER_BANKS_INTERFACE, and RA_CUST_PAY_METHOD_INTERFACE tables then imported into the Oracle Applications by the Customer Import process.
• TCA API’s: The customer information can also be loaded into application by TCA API’s.

Sales Tax Rates

• Manual Entry and Updating: Manual entry or update of sales tax data requires the user to have access to the Oracle Application’s Accounts Receivable module and specifically the Tax Locations and Rates form. You can enter and update location and rate information through this form.
• Sales Tax Rate Interface: The Sales Tax Rate Interface lets you load sales tax records into your Oracle Receivables application from your sales tax feeder system. Information is loaded into the AR_TAX_INTERFACE table then imported into the Oracle Applications by the Sales Tax Rate Interface process.
  The AR_TAX_INTERFACE table is used to import location, postal code and sales tax rate information into Oracle Receivables. Rows are inserted in this table and then the Sales Tax Interface Program is run to create records in AR_LOCATION_VALUES and AR_LOCATION_RATES. Each row can define a new location and assign to it multiple postal code and effectively date ranges, and each range may have an optional sales tax rate.

Tax Vendor Extension

Oracle provides a Tax Vendor Extension to integrate external tax calculation programs with the Oracle Application’s Accounts Receivable module. This extension allows you to provide for complex tax calculation requirements while retaining the full power of Receivables to create and store other tax data. The tax extension is called whenever a tax rate is calculated by the Receivables Tax Engine.

 

This is in continuation to my last post API’s availability. Here are the some keynotes on the API’s availability in GL.

Budget Upload
Oracle Applications provides four methods for adding budgeting transactions, Application Desktop Integrator (ADI) Budget Wizard, manual entry through the application forms, journal import and budget import.

• ADI: ADI is a spreadsheet-based application that allows the user to format data inside a Microsoft Excel spreadsheet and then upload into Oracle Applications. ADI uses Budget Wizards and Budget Templates to simplify the data entry. In addition, ADI is delivered as standard functionality, as opposed to a custom interface that would require additional development, maintenance and upgrade consideration.
• Manual Entry and Updating: Manual entry requires the user to have access to the Oracle Application’s General Ledger module and specifically the enter budget amounts forms for your accounts to replace any existing budget balances. You can enter budget amounts for each account in the budget organization one-by-one, or you can use worksheet mode to enter budgets for several accounts at once. Budget rules enable you to distribute budget amounts for all periods.
• Budget Interface: Budget interface provides a mechanism for transferring large numbers of budget data from a third-party budget source system to your General Ledger application Budget Interface table. Once you load your budget information into the Budget Interface table, you can run Budget Upload to post your budget data into your General Ledger application. Budget Upload uses the Budget Interface table GL_BUDGET_INTERFACE to upload budget information. The Budget Interface table is organized in such a manner that provides a column for each budget period in your current open fiscal year in addition to account and other relevant information on a single budget line.
• GL Interface: GL Interface is another option for uploading large numbers of budget data from a third-party budget source. With this option the source must provide a file that mimics the layout found in the GL_INTERFACE table. The process for uploading a budget through the journal import process is similar to that found using budget interface functionality. The most significant difference is found in the format of the budget record. Here the record is formatted in such a way that each budget line provides an amount for a single budget period within the open fiscal year. Consequently, assuming a fiscal year has twelve periods, a full fiscal year budget for one account would require twelve individual lines to be processed to produce a budget across the full year.

Importing Journals

• Manual Entry and Updating: Manual entry requires the user to have access to the Oracle Application’s General Ledger module. After accessing enter journals form the user is presented with a choice of either entering a new journal or searching an existing journal for update. On a new journal the user can choose to overwrite default information found in header by selecting choices from the drop-down list, in some cells the data is free form and others the default information cannot be changed. The bottom area of the form also known as the journal line detail is used to enter amount, account information and journal line description.
• ADI: Journal Wizard is functionality provided with ADI that allows you to create journal entries using Excel, then upload them into Oracle GL. With ADI the Wizard generates the journal entry template to match the systems configuration. Therefore, in certain cases where the volume is not excessively large this method may be used to format and upload journal entries to Oracle GL. In addition, ADI is delivered as standard functionality, as opposed to a custom interface that would require additional development, maintenance and upgrade consideration.
• GL Interface: Use journal import to load large numbers of journal transactions from third-party systems such as payroll, accounts payable and accounts receivables systems. When using the journal import functionality standard and statistical type journals can be processed. In cases where migration from an older system to Oracle GL is taking place, GL Interface can be used to facilitate the process.

Loading Daily Rates

When using General Ledger’s Multiple Reporting Currencies feature, your daily rates are used to convert your primary set of books’ journals to the appropriate reporting currencies when the journals are copied to your reporting sets of books. Your daily rates must be defined before you post journals in your primary set of books. To load daily currency rate information two options are available, manual entry using the Daily Rates form or direct loading through the GL_DAILY_RATES_INTERFACE table.
You should take a note, normally one currency exchange rate is used for all set of books throughout the organization therefore preventing out-of-balance issues especially in the case of intercompany transactions.

• Manual Currency Rate Input: This option is used primarily when data volumes are small and updates occur on a monthly intervals. In most cases the data is extracted from the internet or another source and someone is required to calculate a month average then enter the values into the system, using the daily rates form in the Oracle GL application.
• Automatic Currency Rate Loading: Depending on the frequency and number of currencies used throughout the business, the volume may become too much to handle through a manual entry process. Additionally, choosing this option makes daily updates more practical and accurate. Several services provide daily currency rate information that can be transferred to Oracle GL. Once the file is received the data is upload into the GL_DAILY_RATES_INTERFACE and subsequently a trigger moves the data into a production table.

The GL_DAILY_RATES_INTERFACE is the interface table used to create, update, and delete daily conversion rates. This table should be used to load rates into the GL_DAILY_RATES table.

Generating Intercompany Transactions

The Global Intercompany System (GIS) provides a central location for subsidiaries to enter intercompany transactions, those occurring between set of books. Furthermore, the process is built in such a manner that an entry requires approval from the sender and receiver prior to the transaction posting. With this process transaction amounts, dates, and currencies are confirmed by both subsidiaries and subsequently producing more accurate results.

The process provides three mechanisms for entering transactions, manual, automatic transaction line generation and import transactions through the GIS open interface table GL_IEA_INTERFACE. The main factor for choosing which option to use is mainly based on data volume and integration with external systems.

• Manual Intercompany Transaction Input: Use the Enter Intercompany Transactions window to enter, update, approve, reject or mark transactions for deletion. This process is convenient for quick entry and correction of entries that may have been interfaced in larger batches.
• Automatic Transaction Line Generation: Using predefined AutoAccounting rules establishing chart of account relationships between GIS senders and receivers, GIS can automatically generate code combinations and amounts for any code combination of the following: sender clearing, receiver distribution, and receiver clearing transaction lines.
• Intercompany Transaction Import: GIS provides the Open Interface to handle high volumes of intercompany transactions and integration with external systems. The AutoAccounting rules are applicable to transactions entering GIS through the open interface….[]..

Here is note on one of most efficient tool used in Oracle application. It is Auto Invoice, most industry accepted tool in Oracle apps.

 

What is Auto Invoice??

Auto Invoice is a tool that can be used to import and validate transaction data from other financial systems from which one can create invoices, debit memos, credit memos, and on-account credits. It rejects transactions with invalid information to insure the integrity of the data.

Where its fits 

 This fits well with in Oracle ERP or to integrate with any third party application< ?xml:namespace prefix ="" o />

 

What Module data can be integrated?

• Oracle Order Management
• Oracle Project Accounting
• Oracle services

 

To make fully functional  what else required

• Loader program
• Validation program

Top 10 reasons for using Auto Invoice

 

1. Powerful Interface Tool

2. Supports Oracle & Non-Oracle Systems

3. Import Large Amount of Data

4. Calculate or Import Tax

5. Group Lines & Invoices

6. Online Error Correction

7 .Lines Validation

8. Derive GL Date

9 .Import Flex fields

10.Import or Derive Accounting Info

 

 

What is inside AutoInvoice

 

AutoInvoice is a tool consists of 3 main programs. Each program will have unique nature of work to do and they are called internally except Purge program whose execution is derived on the setup otherwise ready to execute stand alone.

§         Master (RAXMTR)

§         Import (RAXTRX)

§         Purge (RAXDEL)

 

1.       Auto Invoice Master program RAXMTR

Selects and marks records in the interface tables to  be processed based on the parameters the user entered and then calls the AutoInvoice Import program. Auto Invoice Master program has no report output.

 

•Gathers statistics, it means it gathers the stats on interface tables and set the stats on certain indices on interface tables

•Marks interface records for processing by marking request_id

•Submits multiple workers for Parallel Processing by creating instances for request.

 

2.       Auto Invoice Import Program Validates the selected record and creates transaction if it passes validation. Any record that fails validation is left in the interface table with an error code. Depending on the setup, related records may be rejected as well. This program has an output file called Auto Invoice Execution report, which you can view by clicking the View Report button in the Requests window.

 

• Workhorse of Auto invoice
• Validates data
• Inserts records
• Deletes interface data
• Only when system option purge set to ‘Y’

 

3.       Auto Invoice Purge Program Deletes records from the interface tables. If you set the Purge Interface Table system option to No in Define System Option window, Auto Invoice does not delete processed records from the interface tables after each run,and we must submit Auto Invoice Purge Program periodically to clean up the interface tables. This program only deletes transaction lines that have been successfully imported.

•Deletes all rows where interface_status =‘P’

•Ra_interface_lines

•Ra_interface_distributions

•Ra_interface_salescredits

 

How to start

 

As discussed above, oracle Receivable’s Auto Invoice program will be used to import and validate Invoices.

 

A custom feeder program is required to transfer data from the Advantage extract files and populate the Auto Invoice interface tables (RA_INTERFACE_LINES_ALL and RA_INTERFACE_DISTRIBUTIONS_ALL).If there is need to run populate sales credit into RA_INTERFACE_SALESCREDITS_ALL table.

 

When run, AutoInvoice produces the AutoInvoice Execution Report and the AutoInvoice Validation Report.

Any entries which failed validation can be reviewed in Oracle Receivables’ AutoInvoice Interface Exceptions window. Depending on the error, changes may need to be made in Receivables, the feeder program or the imported records in the interface tables.

 

 

 

 

 

 

 

 

 

 

How Autoinvoice Execution works

Normally, Auto Invoice can be divided into three major phases

 

• Pre-grouping: here the validates all of the line level data takes place
• Grouping: groups lines based on the grouping rules and validates header level data
• Transfer :validates information that exists in Receivables tables

 What happen when Auto invoice run

 

Once the Auto invoice Program gets called, the following activity takes place is part of execution process. This can be analyzed by debug options.

 

• Line, accounting, and sales credit information for each line populates 3 interface tables
• Lines are ordered and grouped
• Tax is calculated
• GL date is determined
• GL accounts are assigned using Auto Accounting
• Tax, freight, commitments, and credit memos are linked to transaction lines
• All transactions are batched
• Validated lines are used to create the transaction

 How Data is flowing

Select, insert and update and delete take place on certain tables once it is logged out.

Selects

            – RA_INTERFACE_LINES_ALL

            – RA_INTERFACE_DISTRIBUTIONS_ALL

            – RA_INTERFACE_SALESCREDITS_ALL

 

Updates/Insert

            – RA_INTERFACE_ERRORS_ALL

            – RA_CUSTOMER_TRX_ALL

            – RA_CUSTOMER_TRX_LINES_ALL

            – AR_PAYMENT_SCHEDULES_ALL

            – AR_RECEIVABLE_APPLICATIONS_ALL

Inserts

            – RA_INTERFACE_ERRORS_ALL

 

 

AutoInvoice Exception Handling

 

Records that fail validation are called ‘Exceptions’

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

AutoInvoice Exception Handling Windows

• Interface Exception window displays exception messages associated with all invalid records
• Interface Lines window displays records that fail validation, provides an error message and can be used to correct the errors
• The Line Errors windows displays errors associated with a specific line, and can only be opened from Interface Lines window
• Interface Exceptions window displays Interface Id, Exception Type, Error Message and Invalid Value associated to the error
• Data cannot be edited in this window, but error can be viewed and corrected by clicking the Details button
• Error Message and Column name with invalid data are displayed in the Message column, and the invalid value that needs to be corrected is displayed in the Invalid Value column

 

Next post, I would summarize more information for Transaction Flexfield,Grouping , profile options and parameter setting.