Oracle Receivable AUTOINVOICE Concepts

AutoInvoice is a program that can be used to import and validate transaction

data from other financial systems from which one can create invoices, debit
memos, credit memos, and on-account credits. It rejects transactions with
invalid information to insure the integrity of the data. This fits well with in
Oracle ERP or to integrate with any third party application.
Top 10 reasons for using Auto Invoice
1. Powerful Interface Tool
2. Supports Oracle & Non-Oracle Systems
3. Import Large Amount of Data
4. Calculate or Import Tax
5. Group Lines & Invoices
6. Online Error Correction
7. 7 .Lines Validation
8. Derive GL Date
9. 9 .Import Flex fields
10. 10.Import or Derive Accounting Info
What
is
inside
AutoInvoice
AutoInvoice is a program set consists of 3 main programs. Each program will
have unique nature of work to do and they are called internally except Purge
program whose execution is derived on the setup otherwise ready to execute
stand alone.
Master(RAXMTR)
Import(RAXTRX)
Purge (RAXDEL)
1.

Auto
Invoice
Master
program
RAXMTR
Selects and marks records in the interface tables to be processed based on
the parameters the user entered and then calls the AutoInvoice Import
program. Auto Invoice Master program has no report output.
Gathers statistics, it means it gathers the stats on interface tables and set
the stats on certain indices on interface tables
Marks interface records for processing by marking request_id
Submits multiple workers for Parallel Processing by creating instances for
request.
2. Auto Invoice Import Program
Validates the selected record and creates transaction if it passes validation.
Any record that fails validation is left in the interface table with an error
code. Depending on the setup, related records may be rejected as well. This

program has an output file called Auto Invoice Execution report, which you
can view by clicking the View Report button in the Requests window.Working
of Auto invoice , Validates data, Inserts records, Deletes interface data Only
when system option purge set to Y
3. Auto Invoice Purge Program
Deletes records from the interface tables. If you set the Purge Interface Table
system option to No in Define System Option window, Auto Invoice does not
delete processed records from the interface tables after each run,and we
must submit Auto Invoice Purge Program periodically to clean up the
interface tables. This program only deletes transaction lines that have been
successfully imported.
Deletes
all
rows

Ra_interface_salescredits

where

interface_status
=P
Ra_interface_lines
Ra_interface_distributions

Oracle Receivables Auto Invoice program will be used to import and validate
Invoices. A custom feeder program is required to transfer data from the
Advantage extract files and populate the Auto Invoice interface tables
(RA_INTERFACE_LINES_ALL and RA_INTERFACE_DISTRIBUTIONS_ALL).If there
is need to run populate sales credit into RA_INTERFACE_SALESCREDITS_ALL
table. When run, AutoInvoice produces the AutoInvoice Execution Report and
the AutoInvoice Validation Report. Any entries which failed validation can be
reviewed in Oracle Receivables AutoInvoice Interface Exceptions window.
Depending on the error, changes may need to be made in Receivables, the
feeder program or the imported records in the interface tables.
How
Autoinvoice
Execution
works
Normally, Auto Invoice can be divided into three major phases, Pre-grouping:
here the validates all of the line level data takes place, Grouping: groups
lines based on the grouping rules and validates header level data,
Transfer :validates information that exists in Receivables tables
What
happen
when
AutoInvoice
run?
Once the Auto invoice Program gets called, the following activity takes place
is part of execution process. This can be analyzed by debug options.
Line, accounting, and sales credit information for each line populates 3
interface
tables
Lines
are
ordered
and
grouped
Tax
is
calculated
GL
date
is
determined
GL
accounts
are
assigned
using
Auto
Accounting
Tax, freight, commitments, and credit memos are linked to transaction lines

All
transactions
are
Validated lines are used to create the transaction

batched

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

AR_RECEIVABLE_APPLICATIONS_ALL

RA_INTERFACE_ERRORS_ALL
RA_CUSTOMER_TRX_ALL
RA_CUSTOMER_TRX_LINES_ALL
AR_PAYMENT_SCHEDULES_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
SLA Profile Options
Setting Profile Options:

The profile options listed above relate to data access and security and
impact how accounting is generated through SLA in R12.

SLA: Enable Subledger Transaction Security in GL

Use this profile option to combine subledger transactions security with data
access security for General Ledger responsibilities when drilling down to
multi-organization enabled subledger application. Transaction security in the
respective subledger application is always applied when drilling down from
subledger transactions to subledger journal entries.
SLA: Enable Data Access Security in Subledger
This profile option determines whether the General Ledger Access Set
security mechanism is applied for a subledger application responsibility when
viewing, reporting, or creating subledger journal entries associated with a
given ledger. The General Ledger Access Set security mechanism is always
applied for responsibilities associated with the General Ledger application.
The profile option enables you to combine data access security with
subledger transaction security and therefore control access to subledger
journal entries depending on the ledger to which they belong. For example,
you can implement a Multi-Org Security Profile that allows you to create
Oracle Receivables Invoices for two different operating units each associated
with different ledgers but restrict drill-down from the subledger transaction
to the associated subledger journal entry based upon the destination ledger
contained in the Access Set.
SLA: Additional Data Access Set
The SLA: Additional Data Access Set profile option, in conjunction with the
GL: Data Access Set profile option, controls which ledgers and balancing or
management segment values you can access when logging onto a
responsibility. If SLA: Enable Data Access Security in Subledgers is enabled
for the responsibility, you have access only to the ledgers and balancing or
management segment values included in the data access sets assigned to
the SLA: Additional Data Access Set and GL: Data Access Set profile options.

SLA: Allow Reports Journal Source Override

This profile option applies only to the following reports:
o Open Account Balances Listing
o Third Party Balances Report

Enable this option to change the Journal Source parameter during report
submission. If the option is set to No, then you cannot change the value
defaulted during report submission. For example:

o Should the general ledger data access set security be enforced when
generating accounting? For example, should journal entries be created if the
user does not have ledger clearance even if they may have multiorg access
to the operating unit?
o Should the transaction security model be applied when drilling down from GL?
For example, should the user be allowed to inquire on journal entries of
certain operating units if they do not have MO access, but have ledger
clearance?
o If there are secondary ledgers and data access set security is enforced in the
subledger module, then an additional data access set need
o Should the user be able to run certain reports across data from multiple
subledger applications?
Note : In Order to Populate the Interface Table we need to run to
Workflow Back Ground Process from the Application Administrator
Responsibility.