Oracle receivables

ORACLE RECEIVABLES

Release 12 Upgrade Considerations

AGENDA
 Balance Forward Billing  Automated Refunds
 Credit Card Chargeback  AP/AR Netting
 Legal Entity  Daily Revenue
 eBusiness Tax  Revenue Contingencies
 Subledger Accounting in  COGS and Revenue
Receivables Matching
 Obsolescence and  Multi-Org Access Control
Replacement of Features
 Centralized Payment
Process

NEW AND CHANGED FEATURES FOR BALANCE
FORWARD BILLING
 Balance Forward Billing provides enhanced billing options that
replace the consolidated billing functionality of prior releases with
a more complete and flexible solution.

BALANCE FORWARD BILLING DESCRIPTION
 Generate bills based on new Billing Cycles
 Easily create daily, weekly, monthly, bi-monthly, quarterly, and
annual billings
 Bill on specific days of the month, or days of the week

 Choose to exclude weekends

 Consolidate billing activity at the level of customer Account
or Site
 Consolidated activity across account sites, or by each billing site
 Not all billing sites need to consolidate their invoices, or be
included in account level billing
 specific invoices can be excluded from the Bill

BALANCE FORWARD BILLING DESCRIPTION
 Enhanced viewing and printing
 Bill Presentment Architecture (BPA) configured formats provide a
more appealing layout that can be easily modified
 View the completed bill online

 Streamline processing with fewer programs to run and
maintain
 Three programs compared to five used by consolidated billing
feature

BALANCE FORWARD BILLING BENEFITS
 Increased flexibility provides billing consistent with business
practices and customer needs
 Expanded billing period definitions, varied levels of consolidation,
exclusion of specified invoices, unlimited print formats
 Clearer communication with the customer
 User views the balance forward bill online exactly as the customer
sees it
 Improved accuracy of Aging
 All invoices on the same bill have the same
due date, guaranteeing the individual
invoices will age simultaneously

BALANCE FORWARD BILLING SETUP AND
PROCESS
SETUP PROCESS

Define Manually Create Import
Billing Cycle Transactions Transactions

Define
Payment Term and
assign Billing Cycle
Run Generate
Balance Forward
Enable Bill Program
Balance Forward
Billing for Customer
Account or Site

Run BPA Run Confirm
Balance Forward Balance Forward
Print Program Bills Program

Automated process

BALANCE FORWARD BILLING SETUP
DEFINE BILLING CYCLE
 When setting up Balance Forward Billing:
 For Daily, choose how often and whether to use work days
only
 For Weekly, choose how often and day of week
 The form changes based on the Frequency you choose.

DEFINE BILLING CYCLE
 When setting up Monthly Balance Forward Billing Cycles:
 Choose the number of months to create bi-weekly, quarterly or bi-
annual billing
 Choose a specific date or multiple dates
 Choose to create exclude weekends

DEFINE PAYMENT TERM
 Billing Cycle is a new attribute of the Payment term
 A billing cycle must be assigned to the payment term to
process balance forward billing.
 Not updateable if the payment term has been used
 Cutoff Date information is setup on the billing cycle

CUSTOMER PROFILE CLASS
 The Profile Class tab includes:
 Ability to enable:
 Bill Level
 Account, Site

 Type

 Summary, Detail, Imported (if Level = Site)

 Payment Term
 Balance Forward (if Enabled), Non-Balance Forward (if not
enabled)
 Override Terms
 Default term can be updated

ACCOUNT & SITE PROFILE
 You must enable Balance Forward at Account and Site
Profile
 The Bill Level is set ONLY at the Account level
 Allow override of terms to exclude invoices from the bill

ACCOUNT LEVEL BILL EXAMPLE
Bill Level

Use
Use Primary Bill-To

Ignore

SITE LEVEL BILL EXAMPLE

Bill Level
Ignore Use
Use

ORACLE BPA RULES SETUP
 Rules for Balance Forward Bills use the Primary Data
Source of “Oracle Receivables Balance Forward”
 Use existing BPA templates or create your own
 For the same print formatting as Consolidated Bills, use the
attribute “Display Format”

BALANCE FORWARD BILLING PROCESS
ENTER TRANSACTION
 Payment Term defaults:
 from Site profile if Bill Level = Site
 from Account profile if Bill Level = Account

 Billing Date is derived from transaction date and billing cycle
 Due Date is derived from billing date and payment term
 Select non-Balance Forward term if Override Terms = Yes

IMPORTED TRANSACTIONS
 AutoInvoice derives the billing date
 Billing Date is a new mandatory grouping rule
 Billing Date value is mandatory if cycle = External

 Transaction API derives the billing date
 Billing Date value is mandatory if cycle = External
 Legacy Invoices must be imported with specific billing date
if the seeded “External” cycle is assigned to the payment
term
 Imported Billing Number feature used by OKL and legacy
systems is still supported and does not use the balance
forward programs

CREATING BILLS
 Generate Balance Forward Bills program
 Replaces Print Draft Consolidated Billing Invoices
 Replaces Print New Consolidated Billing Invoices

 Confirm Balance Forward Bill program
 Replaces Accept Consolidated Billing Invoices
 Replaces Reject Consolidated Billing Invoices

 BPA Balance Forward Print Program
 Replaces Reprint Consolidated Billing Invoices

GENERATING BILL LOGIC

BALANCE FORWARD BILLING USE CASES
 Case 1:
 Billing Cycle = 10th of every month
 Last Bill Generated = Dec 10, 2004
 Today‟s Run Date = Jan 12, 2005
 1 bill generated for Jan 10, 2005
 Case 2:
 Billing Cycle = 10th of every month
 Last Bill Generated = Dec 10, 2004
 Today‟s Run Date = Jan 8, 2005
 No bill generated
 Run date must be Jan 10, 2005 or later

GENERATE BILL PROGRAM
 Generate Balance Forward Bills Program Parameters:

 Choose Print Option
 Draft bill
 Final bill

 Print Output
 Default Yes calls the BPA Print Program
 Must be Yes to view online

 No, if plan to print later

 Specify Billing Cycle
 This limits customer and available payment terms to chose from

CONFIRM BILL
 Program Parameters for confirming a bill include:
 Confirm Option
 Accept
 Reject

 Concurrent Request ID
 ID from Generate Run
 Allows batch confirmation

 Required if no other parameters selected

 Use other parameters to limit the bills affected

SUMMARY BALANCE FORWARD BILL EXAMPLE

DETAIL BALANCE FORWARD BILL

Balance and
Summary information

All lines for
each invoice

BPA PRINT PROGRAM
 BPA Print Program:
 Can be initiated from Generate Program
 Print draft bills
 Print final bills

 Can be used to Reprint
 Select specific bill number, batch or customer

DISABLE PAYMENT TERMS
 To bill the existing invoices:
 Generate a final balance forward bill that picks up existing
transactions
 Change the payment term on all existing transactions to a non-
balance forward billing payment term
 To bill future invoices:
 Change the default payment term on the customer account
 Disable balance forward billing at the site

and change the default payment term

CHANGE PAYMENT TERMS
 Change the billing cycle for a customer by changing the
payment term on the customer profile
 Existing transactions with the old payment term, billing date,
and due date are picked up on the next bill run
 Transactions that do not have activity against them inherit the
Payment term, billing date, and due date from the new payment
term
 Transactions that have activity do not inherit the new payment
term, billing date, and due date

BALANCE FORWARD BILLING
DEPENDENCIES AND INTERACTIONS
 Oracle Bill Management
 This product provides the user interface and the customer
print format for all Balance Forward Bills
 It also provides the rules engine that determines what
print/display format will be used
 It delivers seeded rules that perform the same as the
consolidated billing functionality (summary vs. detail)
 Users can create new rules and print templates

FUNCTIONAL UPGRADE SCRIPT
 Theupgrade script runs automatically to update
consolidated billing proxima payment terms to billing
cycle terms
 It creates cycles based on the cut-off dates of existing
proxima terms
 It assigns them to the existing payment terms
 Balance forward billing payment terms cannot be assigned to
Transaction Types and customer Site Uses
 If a consolidated (proxima) term was assigned at these
levels prior to upgrade, the upgrade script will override the
assignment with a null value

 Enable Balance Forward Billing
 Checkbox is enabled at the account and site level for all validated
consolidated billing customers
 If payment term assigned to customer was not updated to billing
terms, Enable checkbox is null
 Bill Level
 Is set to Site level because consolidated billing was only done at
the site level.
 Users must update the customer record after

upgrade to create bills at the account level

 Type
 Not be changed by the script
 Detail or Summary values used by default print formats

 Customers with the Type of Imported not be included in the

upgrade
 Allow Override of Terms
 Not changed by the script
 Causes different functionality if default payment term is

overridden on an invoice
 If checked, payment term other than the default can be

assigned to an invoice.

CREDIT CARD CHARGEBACK DESCRIPTION
 What is a Credit Card Chargeback?
 A credit card chargeback takes place when:
 A credit card holder disputes a charge with the credit card company
 The credit card company issues a chargeback to the customer for

the disputed amount
 The credit card company notifies the vendor that they have issued

a chargeback to the customer

CREDIT CARD CHARGEBACK DESCRIPTION
Register that
the card
issuer has
Notify vendor that a issued the
chargeback has customer a
taken place chargeback
Vendor
Vendor

Request Issue
chargeback chargeback
Issue
Credit Card chargeback
Company

Customer
Customer
Request
chargeback

CREDIT CARD CHARGEBACK BENEFITS
 Reduce costs by automating the credit card chargeback
process

CREDIT CARD CHARGEBACK PROCESS
PROCESS

Receive
Credit Card Chargeback Create credit
Chargeback Yes
notification memo to credit
valid?
from card issuer invoice

No, Can prove that
the chargeback was
invalid
Find Receipt

Find Receipt

Subtract the amount of the
Reverses
credit card chargeback
from the application line The
Un-apply the
Generates Negative
credit card chargeback
Misc.
activity
Apply Negative Receipt
credit card chargeback Misc.
activity Receipt Restore the original
amount
on the application line

 The process to record a credit card chargeback
consists of three steps:
1. Receive Receipt
2. Record Credit Card Chargeback
3. Validate Credit Card Chargeback
 acknowledge the credit card chargeback or
 prove the credit card chargeback to be invalid

RECEIVE RECEIPT
Place • Create Invoice
order for – DR Receivables $100
$100 – CR Revenue $100
Customer • Receive Receipt
– DR Cash $100
– CR Unapplied $100
Notify • Apply to Invoice
receipt of – DR Unapplied $100
$100 – CR Receivables $100
Credit Card
Company

Vendor

RECEIVE RECEIPT
File • Un-apply the receipt
dispute – DR Receivables $25
for $25 – CR Unapplied $25
Customer • Apply the credit card
chargeback
– DR Unapplied $25
– CR Credit Card Chargeback
Credited $25
$25 • Misc. receipt is generated
Credit Card – DR Credit Card Chargeback
Company
$25
– CR Cash $25

Notify a
chargeback
of $25
Vendor

RECORD CREDIT CARD CHARGEBACK
 Chargeback Process for Vendor:
1. Find receipt
2. Un-apply the receipt
3. Decrease the value on the receipt application line to $75
4. Apply $25 to receipt activity „Credit Card Chargeback‟
(creates a negative misc. receipt of $25)

VALIDATE CREDIT CARD CHARGEBACK
 The vendor can either:
 Acknowledge the credit card chargeback or
 Prove the credit card chargeback to be invalid

 Vendor acknowledges the credit card chargeback

• Credit the invoice by creating a credit
memo
– DR Revenue $25
– CR Receivables $25
Vendor

 Vendor proves the chargeback to be invalid

• Un-apply the credit card chargeback
– DR Credit Card Chargeback $25
Prove that – CR Unapplied $25
chargeback • Misc. receipt is automatically reversed
was invalid Vendor – DR Cash $25
– CR Credit Card Chargeback $25
• Reapply the receipt
– DR Unapplied $25
– CR Receivables $25
Agree that
chargeback
was invalid
Credit Card
Company

CREDIT CARD CHARGEBACK SETUP
SETUP

Create
Receivables Activity
of type Credit Card
Chargeback

LEGAL ENTITY BACKGROUND
 Legal Entity identifies the legal owner of a debt or an
asset
 Oracle Applications did not have an object called Legal
Entity in 11i
 Different representations of Legal Entity throughout
Oracle Applications
 Ambiguous representations left the concept open to
misuse and misinterpretation
 R12.0 Legal Entity solution provides a centralized,
secure setup that is used across the E-Business Suite for
reporting and other legal compliance

LEGAL ENTITY MODEL
No direct
relationship

Bank
Legal Entity X OU
Account

Inv Org
BG

Ledger
Primary
Inv Org = Inventory Organization
OU = Operating Unit
BG = Business Group

LEGAL ENTITY BACKGROUND
 Trading Community Architecture (TCA) is used to model
Legal Entities
 Legal Entities are considered Parties
 First Party and Third Party Legal Entities are involved in a
transaction
 LE uptake pertains to the First Party Legal Entity only

LEGAL ENTITY DESCRIPTION
 Legal Entity information is available in all Receivables
Workbenches
 Receivables stamps each transaction and receipt header
with the Legal Entity
 The user may be required to select or update the Legal
Entity assignment
 Each transaction belongs to only one Legal Entity
 Assigning Legal Entity to all transactions enables tax
calculation, supporting the centralized tax solution

LEGAL ENTITIES AND ACCOUNTING
 Legal Accounting Environment Type: Exclusive
 Ledger records the accounting for one Legal Entity
 Ledger mapped to LE
Legal Entity Ledger

 Legal Accounting Environment Type: Shared
 Ledger records the accounting for more than one Legal Entity
 Balancing Segment Values
mapped to LE Legal Entity

 BSV = Balancing Segment Value Ledger
BSV

LEGAL ENTITIES AND SHARED ACCOUNTING
LE 1 LE 2

BSV 1 – 5 BSV 6 – 7
LE = Legal Entity
BSV = Balancing Segment Value
OU = Operating Unit
Ledger

OU 1 OU 2

DEFAULTING FOR TRANSACTIONS
 Exclusive vs. Shared Accounting Environment:
 Exclusive: Single Legal Entity (LE) assigned to Ledger
 LE derived from Operating Unit
 The LE value cannot be updated

 Shared: Legal Entities share the same Ledger
 Users must set up the hierarchy to derive LE
 The default LE can be updated by the user

DEFAULTING FOR TRANSACTIONS
 Legal Entity derivation hierarchy for transactions
 Transaction Type
 Batch Source

 Assigning a Legal Entity to a transaction type or batch
source is optional
 Only the Legal Entity's mapped to the Ledger associated
with the OU are available to assign
 User should chose only one layer in the hierarchy to
minimize set up replication

DEFAULTING FOR RECEIPTS
 Remittance or Internal Bank Account linked to Legal Entity
 Bank Account is assigned to Receipt Method
 Receipt Method is required on all receipts

Legal Bank Default LE
Entity Account

Receipt
Header
Receipt
Method

LEGAL ENTITY BENEFITS
 Effectively supports central initiative for legal compliance
and flexible business management
 Stamping identifies the owning legal entity on legal documents
accounted for in Oracle Applications
 Easily manages transactional data by legal entity
 Tracking data from the legal perspective enables detailed reporting
at legal entity, establishment, and registration level
 Accurately provides tax calculation for legal entity
 Assists with enforcement of tax calculation
and reporting for all jurisdictions

LEGAL ENTITY SETUP AND AUTOMATED
PROCESS
SETUP PROCESS

Update
Transaction AutoInvoice Assign LE to
Type LE Not Passed invoice line

Update Group lines
Transaction by LE
LE exist on Yes
Batch Source
Transaction
Type? Is LE Valid?

No
Shared Accounting No Create invoice
Environment Only
LE exist on Yes
Batch Source? Generate Error

No

User update
Automated LE value for lines
process

LEGAL ENTITY SETUP
UPDATE TRANSACTION TYPE
 Query Transaction Type
 Select Legal Entity value
 If the type of transaction typically indicates the owner of the
transaction, assign the Legal Entity to the transaction type
within each organization.

LEGAL ENTITY SETUP
UPDATE BATCH SOURCE
 Query transaction
 Batch Source
 Select Legal Entity value

 If the source of the transaction typically indicates the legal
owner of a transaction, then assign the Legal Entity to the
batch source within the organization.

LEGAL ENTITY PROCESS - AUTOINVOICE
 Importing invoices
 AutoInvoice assumes the LE is correct, if it is active
 If LE is not passed, AutoInvoice attempts to default the LE
 AutoInvoice Validation report displays “Invalid Legal Entity”
 If Legal Entity is not valid, or
 If Legal Entity cannot be determined

 User corrects errors via the Interface Lines
Forms

 After Import
 If the invoice can be incompleted, you can update the
defaulted value in a shared-accounting environments
 The invoice must have no activity, not be posted and not printed
 If System Option “Allow Change to Printed Transactions” is turned

on, Receivables still does not allow changes to LE
 If you change the LE value, the eTax engine recalculates
tax

 Importing Regular Credit Memos
 Credit memo LE should be same as LE of the original
invoice
 If feeder system does not pass LE, AutoInvoice stamps
credit memos with same LE of original invoice
 If LE is inactivated between invoice import and credit
memo import, the credit memo is created with the
inactive LE
 You cannot update a system stamped value
 Legal Entity is a new mandatory grouping rule

LEGAL ENTITY SETUP AND MANUAL PROCESS
SETUP PROCESS

Update Transaction Assign LE to
Type Enter Manual invoice Header
Transaction header

Update Transaction User continue
Batch Source invoice creation
LE exist
Yes
on Transaction
Type?
Shared Accounting
Environment Only
No

LE exist on Yes
Batch Source?
User assign LE
Automated No
process

LEGAL ENTITY PROCESS – MANUAL
TRANSACTION
 If an invoice is created manually, the default hierarchy
determines which LE is assigned to a transaction.
 If none is found, you must assign one before continuing to create
an invoice.
 The LE can be changed as long as the invoice is
incomplete.
 The standard rules for completing an invoice still pertain, except if
the invoice has been printed, the LE cannot be changed regardless
of the Allow Changes to Printed Invoices System Option.

LEGAL ENTITY PROCESS – ON ACCOUNT
CREDIT MEMOS
 The application of On-Account Credit Memos performs
much the same as in 11i
 Application must be to transactions in the same Operating
Unit
 Application across Legal Entities is allowed as long as all
transactions are of the same OU
 When cross-Legal Entity applications occur, SLA performs
inter-company accounting

LEGAL ENTITY PROCESS – BILLS RECEIVABLE
 Bills Receivables use same logic as transactions for
stamping the LE
 Manual Assignments are limited to transactions that are
stamped with the same LE as the BR
 LE is mandatory selection and batching criteria during Bills
Receivable Batching process
 If LE on the transactions are different, then multiple BR‟s are
created.
 If a BR is exchanged for another BR, they
must belong to the same LE

LEGAL ENTITY PROCESS - RECEIPTS
 All receipts inherit the LE from the bank account:
 Manual, Automatic, Lockbox and Post Quick Cash
Programs
 Refunds automatically inherit LE from the original receipt
 LE is mandatory selection and grouping criteria for
transaction during automated receipt batch creation
process
 Receipt application across Legal Entities is allowed if the
receipt and transactions are in same OU
 SLA performs inter-company accounting for cross-LE
receipt applications or cross-LE receipt clearing

LEGAL ENTITY PROCESS – CLAIM LE
DEFAULTING
Legal Bank Receipt
Entity Account Method

Non-Invoice Receipt
Claim Header
Invoice

Claim
Receipt
Resolution
Application
LE Default
Invoice
Data Flow Claim

IMPLEMENTATION CONSIDERATIONS
 Are there business flows in your organization that need a
centralized setup to be used across the E-Business Suite
for reporting and other legal compliance?

E-BUSINESS TAX
 Central application that manages the following for all E-
Business Suite products:
 Tax setups
 Enforcement of tax rules, regulations, and legislation

 Tax data

 Tax reporting

 Generic integration point for third-party tax products and
services (Taxware, Vertex, etc)

RECEIVABLES E-BUSINESS TAX INTEGRATION
KEY BENEFITS
 Centralized setup, maintenance, and reporting of tax.
 Centralized control over the applicability of tax and tax
rate(s) based on user-defined rules.
 Rapid adoption of new rates or rules based on changes
to local tax laws or rates using centralized setups and
included test utilities.
 Consistent taxation across Oracle products, operations,
and business lines.
 Open interface for integration to Taxware,
Vertex, or other vendors and products.

E-BUSINESS SUITE TAX PRIOR TO RELEASE
12
Payables
Receivables Other Applications

Tax
Tax Tax
Reporting
Reporting Reporting

Tax
Tax Data
Tax Engine
Data Engine DataRepository Engine
Repository Repository

Tax Partner
Tax Content Tax Services

E-BUSINESS SUITE TAX INTEGRATION
12.0
E-Business Suite

Transaction Data Transaction Tax Data

Oracle E-Business Tax
Tax Services Request Manager

Services
Content
Repository Tax Tax Tax
Content Determination Administration
Services Services Services

Record
Partner Tax Partner Tax
Repository
Content Services
Interface Interface

Tax Partner Tax Content Tax Services

ARCHITECTURE OF A TAX LINE IN E-BUSINESS
TAX
 Tax lines require all of the following:
 Tax Regime (UK VAT, US Sales Tax, etc.)
 Tax (UK VAT, US State Sales Tax, etc.)
 Tax Status (Standard, Zero Rated, Exempt)
 Tax Jurisdiction (UK VAT, Quebec PST, etc.)
 Tax Rate (0%, 5%, 10%, 17.5%, 30%, etc.)

EXAMPLE OF US SALES TAX IN 12.0
Operating
Tax Tax Tax Tax
Tax Unit Tax
Regime Jurisdiction Status Rate
Accounts
Flows
Optional Flows

Regime Tax Jurisdiction Status Rate Account
State California
US Sales
Sales State Sales Standard 7.25% 01.005.004.033
Tax
Tax Tax
County San Mateo
US Sales
Sales County Standard 1.0% 01.005.004.033
Tax
Tax Sales Tax
Belmont
US Sales City
City Sales Standard 0% 01.005.004.033
Tax Sales Tax
Tax

EXAMPLE OF UK VAT TAX IN 12.0
Operating
Unit Tax
Accounts

Tax Tax Tax Tax Recovery
Regime Tax
Jurisdiction Status Rate Rate

Flows
Optional Flows

Regime Tax Jurisdiction Status Rate Recovery
UK VAT UK VAT UK VAT Standard 17.5% 100%
UK VAT UK VAT UK VAT Reduced 8.0% 100%
UK VAT UK VAT UK VAT Zero Rated 00%
UK VAT UK VAT UK VAT Exempt 00%

MIGRATING TAXES FROM 11.5 TO 12.0
 Migrated tax setups:
 Tax Definition Hierarchy
 Tax Configuration Ownership

 AR Tax Defaulting Hierarchy

 AR Tax Codes/Groups

 Location Based Tax

 AR System Options for Tax

 Tax profiles

 Migrated Tax (Transactional) Data
 Invoice, Credit memo tax lines
 Associated adjustments and receipt discounts

MIGRATING OF TAX CODES AND TAX GROUP
CODES
Output Tax
Tax Codes Classification
Codes
AA, BB
Tax Rate – AA, BB, CC
Codes

Tax Group AA, BB, CC Tax Rule
Codes
– AA, BB, CC
– CC

USE OF TAX RATE CODES IN RECEIVABLES
 Tax rate codes correspond to 11.5 tax codes
 Specific numeric rate
 Link to GL accounts (within E-Business Tax)

 Assigned where a numeric rate is required for offline (non-
recoverable) tax calculations
 Receivable Activities (nonrecoverable adjustments, discounts,
misc receipts)

USE OF TAX CLASSIFICATIONS IN
RECEIVABLES
 Tax classifications are used to identify specific
(legacy) tax calculations
 Simple lookup code, contains no tax-specific settings
 Used to prompt or seed specific tax calculations for
transactional data in eBusiness Tax
 Transaction Lines form
 Memo Lines setup form
 Customer (TCA) setup
 Tax classifications are a legacy element – they
only exist for migrated taxes, not new or pure R12
tax setups.

SETTING UP NEW TAXES IN E-BUSINESS TAX
 Tax Configuration tab
 Tax Manager responsibility
 New tax definitions include:
 Jurisdiction, Regime, Status, Tax, and Tax Rate
 Tax rules (determine applicability of tax)

 Tax accounts

 Test your setups using the Tax Simulator

SETTING UP NEW TAXES IN E-BUSINESS TAX
 Set up on the Tax Configuration form:
 Tax Regimes ( UK VAT, US Sales Tax, etc.)
 Taxes ( UK VAT, US State Sales Tax, etc.)
 Tax Statuses (Standard, Zero Rated, Exempt, etc.)
 Tax Jurisdictions (UK VAT, Quebec PST, etc.)
 Tax Recovery Rates (100%, 50%, etc.)
 Tax Rates (0%, 5%, 10%, 17.5%, 30%, etc.)
 Tax Rules (Determine Tax Applicability, Place of Supply,
etc.)

RECEIVABLES SPECIFIC TAX SETUPS
 Receivables Specific Tax Setups:
 System Options
 Customer
 Transaction type
 Receivables activity
 Standard memo lines

SYSTEM OPTIONS
 Most of the tax setups that used to reside on the System
Options form have been migrated to the
E-Business Tax Product Options form.
 Options that now appear on the E-Business Tax Product
Options form include:
 Tax defaults
 Hierarchy information

 Rounding information

CUSTOMER TAX
 The Tax Profile tab includes Tax setups related to
specific customer accounts or sites, including:
 Tax rounding
 Registration
 Reporting
 Fiscal classification
 Customer exemption

TRANSACTION TYPE
 The tax classification field on the transaction lines form is
now optional
 When selected, the tax classification is defaulted on each
transaction line based on the migrated tax hierarchy
 The requirement for tax lines on the transaction is now
monitored by E-Business Tax so transactions without tax
lines will no longer raise errors when saved or completed

RECEIVABLES ACTIVITY
 Receivables Activities form
 The Tax Code on the previous versions of this form was
replaced with Tax Rate Code
 The numeric rate associated with this tax rate is used to calculate
non-recoverable taxes internally within Receivables.
 New multi-line area on the form where you can associate
the correct tax rates for each supported Legal Entity

ADJUSTMENTS, RECEIPT DISCOUNTS, AND
RECOVERABLE TAX
 Adjustments and Receipt Discounts are recoverable
when the receivable activity contains the following:
 Tax code source = „Invoice‟
 Recoverable checked

 When an adjustment or discount is recoverable,
Receivables calls E-Business Tax to:
 Prorate the activity between tax and lines
 Record the activity in the tax repository

 This means that recoverable activities decrease your tax
liability. Non-recoverable activities are not reflected in the
tax repository or your tax reporting.

STANDARD MEMO LINES
 Standard Memo Lines Form:
 Tax code is now Tax Classification
 May be defaulted on transaction lines based on your tax defaulting
hierarchy
 New Tax Product Category field
 Defaulted on your transaction lines and passed to E-Business Tax
during tax calculations
 Used to determine the correct taxes to apply and tax amounts due

LEGAL ENTITY AND SHIP TO
 Legal Entity is required on all transactions and receipts
 Defaulted from transaction type, batch source, organization
 Credit memos default legal entity from target transaction

 Adjustments assume legal entity from target transactions

 Receipts default legal entity from remittance bank account

 Ship to customer and address information can now be
recorded at the line-level
 Ship to is now an optional grouping rule for transactions
 A transaction can have multiple ship-to addresses

TRANSACTIONS AND MIGRATED TAXES
 No change to taxes migrated from previous releases
 Same rate as previously defined (now a tax rate code)
 Same tax accounts (migrated to E-Business Tax)
 Tax classification defaults on each line using hierarchy
 User can specify tax classification manually for each line
 Resulting tax calculation will be identical to pre-12.0
 Note: Tax calculation only occurs for migrated taxes if
the output tax classification is present on the invoice
line.

TRANSACTIONS AND MIGRATED TAXES:
KEY DIFFERENCES
 Transaction type no longer enforces existence of tax lines
on your transactions
 Presence or absence of tax classification does not dictate
tax calculations
 The ability to enter manual tax lines or modify existing tax
lines now controlled by E-Business Tax
 Credit Memos always use E-Business Tax for tax
calculations

TRANSACTIONS AND NEW TAXES
 New taxes are calculated based on:
 Applicability (tax rules) defined in E-Business Tax
 Content of the transaction in Receivables
 NOTE: Tax classification is not required or used for non-migrated
taxes
 Calculation is entirely hands-free

TRANSACTIONS AND MANUAL TAXES
 Tax Lines Form:
 Can be displayed from either the transaction header or
transaction lines forms
 Use to:
 Enter a manual tax line
 Override an existing tax line

 Manual tax lines now require the following information:
 Regime
 Tax

 Jurisdiction

 Status

 Rate

 E-Business Tax was designed around a robust and flexible
rule-based applicability feature.
 When properly configured, the E-Business Tax engine
should be able to determine the correct taxes based on
customer, location, item, or any combination of dozens of
other transaction attributes.
 The decision for the applicability of any given tax should
made during setup and testing, not during transaction entry.

SUBLEDGER ACCOUNTING OVERVIEW
 Rule-based accounting engine, toolset & repository
 Allows multiple accounting representations for a single
business event
 Common data model and UI across subledgers
 Supports all 11i functionality

SUBLEDGER ACCOUNTING BENEFITS
 Enable compliance with multiple legislative, industry or
geography requirements concurrently in a single instance
through configurable rules
 Increase transparency and enable full audit of the
transaction and accounting data through the new data
model
 Improve accounting reconciliation

SUBLEDGER ACCOUNTING IN RECEIVABLES
OVERVIEW
 Receivables predefines setup data to maintain R11i
functionality
 Default accounting that Auto Accounting creates is
interim accounting only. You must refer to SLA for
your accounting entries
 Receivables distribution is no longer your accounting. It is
used as a source for predefined accounting derivation rule
 SLA creates accounting and SLA transfers
accounting entries to GL
 Obsolete: General Ledger Interface concurrent program
 Obsolete: CCID Corrections Form

 New: Submit Accounting concurrent program

BENEFITS
 Multiple accounting representations
 Legal and Management reporting
 Accrual and Cash Basis accounting

 Multi-Fund Receivables accounting

 Infrastructure to support new feature:
 Line Level Cash Application

PROCESS SUBMIT ACCOUNTING PROGRAM
 Submit Accounting Program:
 Receivables concurrent program to create accounting
entries in SLA
 When you run Submit Accounting, the Revenue Recognition
program is automatically run before creating accounting
entries in SLA
 You can choose to create draft accounting or final
accounting.

PROCESS CREATE/VIEW ACCOUNTING
 You can create and view accounting entries from
Receivables transactions and receipts workbenches
 To create accounting for transactions, run the Submit
Accounting concurrent program
 To create accounting online go to Tools>„Create Accounting‟
on the transactions workbench or receipt workbench.
 To view accounting entries for a transaction, bring up the
transaction, and then go to Tools>View Accounting

SUBLEDGER ACCOUNTING IN
RECEIVABLES PROCESS ONLINE
CREATE ACCOUNTING
 Create Accounting form options:
 Create Final Accounting Post to GL
 Create Final Accounting

 Create Draft Accounting

 You can view draft accounting, which gives you the
flexibility to make changes before creating final
accounting.
 To view the accounting entries, bring up the
transaction, and then go to Tools>View Accounting
 Refer to SLA documentation for detailed information
on the Create Accounting parameters

SETUP
 No AR specific setup is required to continue using 11i
functionality
 Receivables has predefined the setup
 Resultant accounting is the same as in R11i
 The next few slides describe AR predefined setup

 To define your own SLA setup, please refer to SLA
documentation

RECEIVABLES SETUP LEDGERS
AND SLAMS
Ledger

Assigned to

Subledger Accounting Method

Assigned to

Application Accounting Definition

Assigned to

Event
Class & Type
Journal Lines Definitions

Assigned to

Journal Line Account
Line Type Description Derivation
Rules

SETUP SOURCES FOR ACCOUNTING
DEFINITIONS
Invoice Event Class
Entered Amount
Operating Unit Customer Name
Transaction Type Revenue Account
PO Number Currency Tax Code
Item
Salesperson
Invoice Number

RECEIVABLES SETUP PREDEFINED
EVENT CLASSES/TYPES
Event Class* Event Types

Create
Invoice
Update

Create
Credit Memo
Update

Create

Receipt Update

Reverse

*Event Class = Receivables Document

SETUP
AR PREDEFINED EVENT CLASSES/TYPES
Event Class Event Journal Definition Assignment
Type
Adjustments All Adjustments – Default Accrual
Bills Receivable All Bills Receivables – Default Accrual
Chargeback All Chargeback – Default Accrual
Credit Memo All Credit Memo – Default Accrual
Debit Memo All Debit Memo – Default Accrual
Deposit Memo All Deposit Memo – Default Accrual
Guarantee All Guarantee – Default Accrual
Invoices All Invoices – Default Accrual
Misc Receipt All Misc Receipt – Default Accrual
Receipt All Receipt – Default Accrual

RECEIVABLES SETUP ANATOMY OF
A JOURNAL ENTRY

Subledger Accounting Entry
Date: 10-Jan-2002 Description: Domestic invoice number A4576, issued Jan 5th 2002
Line Type Account Description Debit Credit
Receivable 01.1210.000 Paco Terremoto S.A. 5,600
Revenue 01.4110.000 Widgets X-123 5,000
Tax 01.5350.000 Domestic input VAT 600

Account Derivation
Journal Line Types Descriptions
Rules

RECEIVABLES SETUP JOURNAL
LINE TYPES
 Journal Line Types Setup:
 The Side field determines how Receivables will account for
the Line Type
 The Switch Debit/Credit field determines how negative
amounts will be handled
 Note that Transfer to GL is done in Summary

RECEIVABLES SETUP ACCOUNT
DERIVATION RULE
 Account Derivation Rules Setup:
 Account Derivation Rules determine which account to use
for the Journal Line Type for a particular transaction
 You can define your own:
 Subledger accounting methods
 Application Accounting Definitions

 Journal Line Definitions

 Journal Line Types

 Line Descriptions

 Account Derivation Rules

SETUP JOURNAL LINE DEFINITION OF
INVOICES
 The Journal Line Definition is comprised of:
 Journal Line Types (JLT)
 Line Descriptions
 Account Derivation Rules (ADR)

RECEIVABLES SETUP ASSIGNING THE
JLD TO THE AAD
 Application Accounting Definitions Form
 Journal Line Definitions (JLD) are assigned to the
Application Accounting Definition per Event Class or Event
Type
 Journal Line Definitions must be validated to enable
accounting

SUBLEDGER ACCOUNTING IN RECEIVABLES SETUP
ASSIGNING THE AAD TO THE SLAM

 Subledger Accounting Methods Form
 Application Accounting Definitions (AAD) are assigned to
Subledger Accounting Methods

ASSIGNING THE SLAM TO THE LEDGER

 The subledger accounting method is defined and shipped
by Oracle.
 This is indicated by the subledger accounting owner field which
shows Oracle.
 User defined subledger accounting methods show the user in the

subledger accounting owner field.
 There is a 1:1 relationship between a ledger and a SLAM.
 The Use Cash Basis Accounting flag should be disabled
when using an accrual SLAM

PREDEFINED SLAMS

 Standard Accrual
 Application Accounting Definition Name: Receivables Default
Accrual
 Standard Cash
 Application Accounting Definition Name: Receivables Default Cash
Basis Accounting Definition
 US Federal Accounting
 Application Accounting Definition Name: Multi-Fund Account
Receivables Accrual - Balancing Method

RECEIVABLES PROCESS INVOICE
ACCOUNTING
Item 1 $100
Tax $ 10
Freight $ 30
Item 2 $200
Tax $ 20
Total $360

11i Accounting R12 AR Default Accounting
DR Receivables $360 DR Receivables $360
CR Revenue $100 CR Revenue $100
CR Tax $ 10 CR Tax $ 10
CR Freight $ 30 CR Freight $ 30

PROCESS MULTI-FUND RECEIVABLES
ACCOUNTING

Item 1 $100 R12 AR Default Accounting
Tax $ 10 DR Receivables $100
Freight $ 30
DR Receivables $200
Item 2 $200
Tax $ 20 DR Receivables $ 10
DR Receivables $ 20
Total $360 DR Receivables $ 30
CR Revenue $100
CR Revenue $200
CR Tax $ 10
CR Tax $ 20
CR Freight $ 30

PROCESS
ADJUSTMENT ACCOUNTING

$60 LINE* Adjustment

11i Adjustment Accounting R12 Default Accounting
DR Write Off $ 60 DR Write Off $ 20
CR Receivables $ 60 DR Write Off $ 40
CR Receivables $ 20
CR Receivables $ 40

PROCESS RECEIPT APPLICATION
ACCOUNTING
$150 Receipt Application

Default Accrual Accounting

11i Receipt Accounting R12 Default Receipt Accounting
DR Unapp $150 DR Unapp $ 150
CR Receivables $ 50
CR Receivables $150 CR Receivables $100
CR Receivables $ 5
CR Receivables $ 10
CR Receivables $ 15
CR Receivables -$ 10 *
CR Receivables -$ 20 *

PROCESS RECEIPT APPLICATION
ACCOUNTING
$150 Receipt Application*

Default Cash Basis Accounting

11i CASH BASIS R12 CASH BASIS
DR Unapp $150 DR Unapp $ 150
CR Revenue $ 50 CR Revenue $ 50
CR Freight $ 15 CR Freight $ 15
CR Adjustment -$ 10 CR Adjustment -$ 10
CR Adjustment -$ 20 CR Adjustment -$ 20


Accounting
Configurations
Subledger
Transactions
Journal Entries
GL
Journal
Accounting Entries
Program and
Balances
Accounting Subledger
Events Balances
Journal Entry
Setup

Receivables SLA

OBSOLESCENCE AND REPLACEMENT OF
FEATURES DESCRIPTION
 Receivables‟ Collections Workbench
 Oracle Advanced Collections replaces the existing
workbench
 Work is pushed to the user
 Users work primarily within one main screen
 The Account Details and Activities forms are still available
for research by non-collector personnel

 Bills of Exchange
 Bills of exchange are financial instruments used primarily
outside of the USA
 Bills of exchange were originally implemented as a type of
receipt
 The Bills Receivable feature replaces the bills of exchange
functionality creating unique documents
 Bills Receivable has its own workbench

 Trade Accounting
 Provided a way to handle customer deductions and overpayments
 Replaced by Deductions Management, using Trade Accounting

and Credit Management

 Tax Setup and Reporting
 Receivables tax reports and setup are replaced with equivalent
functionality in Oracle E-Business Tax
 CCID Correction Form
 Provided a way to update invalid accounting before importing into
General Ledger
 Centralized Sub-Ledger Accounting draft accounting can be

corrected prior to interfacing with General Ledger, replacing need
for the corrections form

 COGS and Revenue Matching Report
 Report compared Revenue to potential COGS
 Replaced by COGS and Revenue Matching feature

 AR Customer Supplier Netting Report
 Report listed Payables and Receivables by customer
 Replaced by AP/AR Netting feature

 On Account Credit Memo Refund
 Manually initiate refund from On Account credit memo
 Functionality enhanced with direct integration to Oracle Payables

 Consolidated Billing
 Consolidated customer invoices into one monthly bill
 Replaced by more flexible Balance Forward Billing feature

 Customer Standard User Interface Redesign
 Redesigned as an HTML-based user interface
 Provides a more streamlined and intuitive customer data
management flow
 Customer data entry is coupled with data quality
management tools to maintain the integrity of customer data

 Late Charges functionality
 Enables you to create standard late charge policies that can
be assigned to customer accounts or account sites
 Flexible policy configurations include:
 Multiple interest calculation formulas
 Transaction and account balance thresholds

 Currency-level rate setups

FEATURES BENEFITS
 Improve functionality by aligning with mandated or generally
accepted business practices
 Reduce maintenance by providing centralized functionality
 Increase user productivity and effectiveness with more
automation, easier navigation and extended functionality

TRANSITION TO NEW FEATURES
COLLECTIONS WORKBENCH
 What changed:
 Forms removed or modified in Receivables
 Reports retired or modified in Receivables

 Required steps:
 Setup Oracle Advanced Collections
 For more information:
 “Migrating to Oracle Advanced Collections: An Overview for Oracle
Receivables Users” white paper

COLLECTIONS WORKBENCH - MENU
AND FORMS

 Items removed (menu and forms):
 Account Overview
 Aging Replaced with:
 Correspondence – Collector‟s Work Queue
– Collections
 Customer Accounts
– Search
 Customer Calls

 Scheduler

 Items changed (menu and program):
 Account Details modified as research tool
for non-collections users
 Dunning Letters program is now Historical
Dunning Letters only

COLLECTIONS WORKBENCH -
ACCOUNT DETAILS
 Account Details:
 Still exist in R12 to provide non-collector users the ability to perform
research.
 Are available directly from the Navigator, and can be used for
either transactions or receipts as it is today.
 Are still available from the transactions workbench when you select
Installments from the Tools/Action menu
 The Account Details form has been modified to remove
references to Dunning, and Call functionality.
 Dunning creation and history, and Call
functionality are now available in
Advanced Collections.

COLLECTIONS WORKBENCH - DUNNING
REPRINT
 Dunning Reprint allows printing of Historical Days Overdue
type dunning letters in the event of foreclosure or other legal
issues.
 The Program is called Dunning Letter Reprint-Historical
Receivables Only
 Items changed:
 Program name: Dunning Letter Reprint-Historical Receivables Only
 Output: Historical Receivables Days Overdue
Dunning letters

TRANSITION TO NEW FEATURES BILLS
RECEIVABLE
 What Changed:
 The System Option to enable Bills Receivable is removed,
Bills Receivable is automatically enabled
 Required Steps
 Setup for Bills Receivable
 If you have transitioned to Bills Receivable prior to

upgrading, no action is required
 If you plan to transition to Bills Receivable
before or after the upgrade, review the
white paper: “Oracle Receivables Bills
of Exchange Obsolescence”

TRANSITION TO NEW FEATURES TRADE
ACCOUNTING
 What Changed:
 System Option to Enable Trade Accounting is removed
 Deductions Management will automatically be enabled if you

setup Trade Management
 Required steps:
 If you upgraded to Deductions Management solution prior to
R12.0, no actions are required
 Setup Oracle Trade Management and Credit Management

 “E-Business Suite Solutions for Deduction
Management, An Oracle White Paper
Release 11i.10”

CUSTOMER STANDARD FORM
 What changed:
 Old Standard customer forms replaced by HTML UI
 Updates to Customer Profile Class form

 Required steps:
 No actions required

TAX SETUP AND CALCULATION
 What changed:
 Tax reports retired
 Tax setup removed from AR

 Oracle E-Business Tax provides all setup and calculation
functionality for tax

TAX REPORTING
 No longer in Receivables:  Supported in E-Business Tax:
 Tax Code Listing  Financial Tax Register
 Tax Exceptions Listing  Tax Received Report
 Tax Exempt Customer  Tax Reconciliation Report
report  Tax Register
 Tax Exempt Product  Tax-only: open invoices
Report report
 Tax Group Listing Report  US Sales Tax report for tax
 Sales Tax Listing partners
 Sales Tax Rate Interface
 TAX: Setup Verification
Report
 Tax Partner: AR Effective
Tax Rate Update

SUBLEDGER ACCOUNTING
 What changed:
 SLA draft Accounting provides a draft view of accounting prior to
posting
 Changes can be made to accounting setup, negating need for
CCID Corrections form
 Required steps:
 No action required if AutoAccounting is adequate
 setup SLA if you need more robust account creation functionality

than AutoAccounting

COGS AND REVENUE MATCHING
 What changed:
 Report removed
 Revenue Recognition triggers COGS recognition via API called by

Costing product
 Required steps:
 No action required in Receivables

AR CUSTOMER SUPPLIER NETTING
 What changed:
 AR Customer Supplier Netting Report retired
 Replaced by centralized, automated netting feature

 Required steps:
 Setup AP/AR Netting

ON ACCOUNT CREDIT MEMO REFUND
 What changed:
 Refund no longer creates miscellaneous receipt
 Interface to Payables via Oracle Payments will create refund

automatically
 Required steps:
 Setup refund Receivables Activity in AR
 Oracle Payments Setup

CONSOLIDATED BILLING
 What changed:
 Consolidated Billing creation and print programs retired
 New Balance Forward Billing feature

 Required steps:
 No Action required for existing consolidated billing
 Define Balance Forward Billing Cycles

 Assign Billing Cycle to Payment Terms

CENTRALIZED PAYMENT PROCESS
DESCRIPTION
Common Engine for Payment Transactions

Oracle
Payables

Oracle
Financial
Receivables
Oracle Institutions
Oracle Order Payments
Management Credit Card
Processors
Other Oracle
Modules

DESCRIPTION
 Leverages Oracle Payments Funds Capture
 Oracle Payments stores external bank accounts and
payment information
 Centralized data encryption
 Centralized processing for automatic payment method

DESCRIPTION
 R12 New prompt: “Receipt Method”
 AR “Payment Method” is renamed to “Receipt Method”
 Receivables‟ UI modified for payment attributes:
 Transactions Workbench
 Receipts Workbench

 Receipt Classes Setup forms

 Funds Transfer Error Handling Form

 Bills Receivables

 New Payment Details tab on Customer Standard form

SETUP AND PROCESS
SETUP PROCESS

Configure Funds
Capture Processing Method of creation:
(Oracle Payments) Auto Invoice
Create Invoice
Invoice API
Transaction Workbench

Create receipt classes
and receipt methods Method of creation:
(Oracle Receivables) Automatic Receipt
Create Receipt Receipts API
Prepayment API
Receipt Workbench
Assign receipt methods
and instruments to Oracle Payments
customer site or performs:
account Remittance
(1) Funds capture or
(Oracle Receivables) Processing
(2) Remittance file
creation

Automated process

CENTRALIZED PAYMENT PROCESS SETUP
CREATE RECEIPT CLASS/METHOD

 Create automatic receipt method:
1. Enter Automatic for Creation Method
 When a Creation Method of “Automatic” is selected
 A Remittance Method = “No Remittance” is not allowed
 The only values available for the Remittance Method are
Standard, Factoring, and Standard and Factoring
2. Enter Payment Method for funds transfer processing
 Note that this payment method has been defined in Oracle
Payments.
 Changes:
 Receipt Method was previously called Payment Method
 Payment Method under Funds Transfer Processing region was
previously called “Payment Type”

PROCESS INVOICE PAYMENT
 When you create an invoice, payment details are defaulted
from the customer setup
 You may overwrite the information.
 Select Instrument button invokes a new window in which
you can either:
 Select from an existing list of instrument numbers
 Create a new instrument number

CENTRALIZED PAYMENT PROCESS ERROR
HANDLING
 The Correct Funds Transfer Error form is used for:
 Credit Card and Bank Account Transfer errors
 Error Handling for automatic payments

CENTRALIZED PAYMENT PROCESS SETUP
CUSTOMER‟S PAYMENT DETAILS
 Use the Payments tab to:
 Assign primary Receipt Method for the customer
 Zoom in to Payment Instruments to view existing
instruments such as:
 Credit card
 Bank transfer accounts

 Zoom in to Payment Instruments to create new payment
instruments

 Oracle Payments
 New data model for customer accounts
 New data model for payment information

 Transaction Payment-Extension entity

 UI components

 Upstream products
 Interface key reference to transaction payment-extension entity

AUTOMATED REFUNDS DESCRIPTION
 Automate refund process for non-credit card transactions
 Leverage AP workflow approval
 AP transacts refunds via Oracle Payments

AUTOMATED REFUNDS SETUP AND PROCESS
SETUP PROCESS

Create credit memo Request
(Auto Invoice) Refund
Setup Receivables Process
Activity for „Refund‟

Oracle Payables
Refunds Refund
Setup Transaction Workflow approval
or On
Source: Receipt process
Account?
Handling for Credits

On account Workflow
remittance process
Create on account
credit
Fund Disbursement
(Oracle Payments)
Automated
process

AUTOMATED REFUNDS SETUP RECEIVABLES
ACTIVITY
 Refund activity type is applicable for automated non-credit
card refunds
 You must create a Receivables Activity with this Refund
type to process your automated AP refund.
 Credit Card Refund activity type is still available for credit
card refund only.

AUTOMATED REFUNDS SETUP TRANSACTION
SOURCES
 Set Receipt Handling for Credits to Refund in your
transaction source
 Applicable for both automated credit card refunds and
automated AP (non-credit card) refunds
 For credit card transactions, Receivables submit the
refund request to Oracle Payments directly
 For non-credit card transactions, Receivables
submits the refund request to AP, which in turn
submits the request to Oracle Payments
 Credit Card Refund has been replaced with Refund
for Receipt Handling for Credits

AUTOMATED REFUNDS SETUP TRANSACTION
SOURCES
 No user interaction is needed.
 Create credit memos via Auto Invoice
 Refunds are automated

 View refund status in AP workbench

AUTOMATED REFUNDS PROCESS
APPLICATIONS FORM
 To create manual refund, apply the receipt to Refund
 For Refund application, the button Refund Attributes is
enabled
 Click on this button to view and update your refund attributes

AUTOMATED REFUNDS PROCESS
NEW REFUND ATTRIBUTES FORM
 Refund Attributes:
 Customer Name
 Default
 Customer Number
 Refund Payment Method
 Customer Address
 Party Bank Account
 Delivery Channel
 Pay Alone
 Remittance Message 1,2,3

AUTOMATED REFUNDS PROCESS VIEW
REFUND STATUS
 Use Refund Status to view the refund status in AP
 Refund status is not applicable for credit card refund

 Oracle Payables
 Automated refund for non-credit card transactions

AP/AR NETTING DESCRIPTION
 AP/AR Netting automatically compares Payables to
Receivables and creates the appropriate transaction in each
system to net supplier invoices and customer invoices
 A receivables user can
 View netted receipt details directly from the receipt
 Create Netting Agreements and Netting Batches

 The AR Customer Supplier Netting Report has been retired

AP/AR NETTING BENEFITS
 Increase user productivity and effectiveness with more
automation and integration

AP/AR NETTING PROCESS ACCESS
 You can now access forms for creating and updating:
 Netting Batches
 Netting Agreements

AP/AR NETTING PROCESS ACCESSING
 After Querying a netted receipt, you can view details about
the batch by selecting AP/AR Netting from the Action menu
 Netted Receipts are created automatically by the AP/AR
Netting process
 You cannot update Netted Receipts from the Receipts
Workbench

DAILY REVENUE DESCRIPTION
 Daily Revenue enables accurate revenue distribution over
all accounting periods, including full and partial periods
 It fulfills stringent accounting standards introduced by the
US GAAP and SOX for recognizing revenue

 Example of a contract that spans from Jan 14th, 2006
through Apr 13th, 2006. We assume the accounting period
defined is Monthly.
 This contract spans across 4 accounting monthly periods as
illustrated below:
Jan Feb Mar Apr
|------|----------|------------|------|
1/14 2/1 3/1 4/1 4/13
 January and April are partial periods
 February and March are full periods

 Revenue accuracy is to the number of days in the
accounting period.
 Formula to calculate Daily Revenue Rate:

Total Revenue
Daily Rate =
Total Number of Days (for the entire duration)

 Example:
 Contract valid from 14-Jan-2006 to 13-Apr-2006 (90 days
total)
 Assume total revenue is $900
 Daily Rate = $900/90days = $10/day
 Revenue amount per accounting period is based on Daily
Revenue Rate

R11i vs. R12 revenue distributions
Example: 6 months service (17-Apr-2006 to 16-Oct-2006) at $600 total.
Calculated daily revenue rate: 600/183 = 3.28

GL Date Revenue R11i R12 Daily Rev. R12 Daily Rev. # of Days
Period Revenue All Periods Partial Periods
Apr 17 Month of Apr 100 45.91 45.91 14

May 17 Month of May 100 101.64 100.33 31

June 17 Month of Jun 100 98.36 100.33 30

July 17 Month of July 100 101.64 100.33 31

Aug 17 Month of Aug 100 101.64 100.33 31
Sept 17 Month of Sept 100 98.36 100.33 30

Oct 16 Month of Oct ----- 52.45 52.44 16

600 600 600 183

DAILY REVENUE SETUP AND PROCESS
SETUP PROCESS

Create accounting Create
rule with Create an invoice line accounting
Daily Revenue type With accounting rule.
(manual or imported)

View accounting

Is it No
daily revenue
rule?
Adjust accounting
Yes

Enter Rule
End Date Post accounting

Automated process

DAILY REVENUE SETUP ACCOUNTING RULES
 Two new accounting rule types have been added for Daily
Revenue:
 Daily Revenue Rate, All Periods. For this type, all periods use daily
revenue rate.
 Daily Revenue Rate, Partial Periods. For this type, partial periods

use daily revenue rate, full periods are prorated.
 Two existing accounting rule types have been renamed:
 Fixed Schedule (Previously named Fixed Duration)
 Variable Schedule (Previously named Variable Duration)

DAILY REVENUE PROCESS CREATE INVOICE
LINE
 Invoice line can be created via:
 Auto Invoice or Invoice API
 Transactions Workbench

 For the Daily Revenue rule, you must enter a Rule End
Date
 The Rule End Date must be on or after Rule Start Date

 General Ledger
 Define accounting periods in General Ledger
 Order Management, and Service Contracts
 Interface invoice lines to Receivables
 Default or assign Daily Revenue accounting rules onto sales order
lines or service lines

REVENUE CONTINGENCIES OVERVIEW
 US GAAP and SOX compliance for revenue recognition
 User definable revenue contingencies
 User definable assignment rules
 Enhanced RAM wizard or Revenue Adjustment API
 Increase security with restricted access

REVENUE CONTINGENCIES DESCRIPTION
 Automatically time revenue recognition in accordance with
the removal of Revenue Contingencies as required by US
GAAP and IAS
 Enhancements to Event Based Revenue Management
functionality
 Enabled for imported and manual transactions
 User definable contingencies. New UI in Receivables.

 User definable defaulting rules for contingencies assignment

 Support for parent-child (e.g. Product and Service)
relationship.

REVENUE CONTINGENCIES DESCRIPTION
 Pre-billing Customer Acceptance is supported by Order
Management, Service Contracts and Receivables
 Manage contingencies or revenue using Revenue
Accounting Module (RAM) wizard and API
 Revenue Managers Responsibility restricted access

REVENUE CONTINGENCIES SETUP AND
PROCESS
SETUP PROCESS
Assign Evaluate
Define policy Contingencies assignment rules
threshold
Create invoice line
Assign contingencies if
Define criteria is met
contingencies Is the
revenue Defer Revenue if
policy contingencies
Yes exist
met?
Define
defaulting rules No
Recognize Revenue
Assign Customer
Creditworthiness, Run Revenue Contingency
Extended Payment Analyzer to detect expired
Term, and/or contingencies
Refund
contingencies
Recognize revenue or
continue deferring revenue
Automated process

REVENUE CONTINGENCIES SETUP POLICY
THRESHOLD
 On the Revenue Policy form, you must setup a policy
for each operating unit:
 Select an Operating Unit
 Enter customer credit classifications
 Enter your company policy threshold

REVENUE CONTINGENCIES SETUP
SEEDED CONTINGENCIES
 Receivables seeds the contingencies
 You cannot update or delete seeded contingencies.
 You can duplicate the contingencies and modify the copy as

needed, or you can create new contingencies
 Receivables also seeds removal events
 You cannot delete, modify or create removal events
 Removal events available are: Contingency Expiration, Customer
Acceptance, Invoicing, Payment, and Proof of Delivery

REVENUE CONTINGENCIES SETUP
CONTINGENCY CODES/ID
R11i mapped to R12
Contingency Code ID Contingency Name
AR_ACCEPTANCE 2 Explicit Acceptance
AR_CUSTOMER_CREDIT 3 Customer
Creditworthiness
AR_COLLECTIBILITY 4 Doubtful Collectibility
AR_PAYMENT_TERM 5 Extended Payment Term
AR_CANCELLATION 7 Cancellation
AR_FISCAL_FUNDING 8 Fiscal Funding Clause
AR_REFUND 9 Refund
AR_FORFEITURE 10 Forfeitures
OKL_COLLECTIBILITY 12 Leasing Doubtful
Collectibility
13 Impaired Loans
LNS_IMPAIRED_LOAN

REVENUE CONTINGENCIES SETUP CREATE
RULES
 Define your assignment rules to meet your business needs
 Receivables does not seed any rule for revenue
contingency
 You must set up all rules using any of the seeded matching
criteria attributes

REVENUE CONTINGENCIES PROCESS
CONTINGENCY ASSIGNMENT
PROCESS

Assign Contingencies Evaluate
assignment rules
Create invoice line
Assign contingencies if
criteria is met
Is the
revenue Defer Revenue if
policy contingencies
Feeder Systems such met? Yes exist
as Order No
Management and Recognize Revenue
Service Contracts Assign Customer
Run Revenue Analyzer
Creditworthiness,
to detect expired
Extended Payment
contingencies
Term, and/or Refund
Manual Transactions
contingencies
Recognize revenue or
continue deferring
Automated process revenue

REVENUE CONTINGENCY PROCESS
MANAGE CONTINGENCIES
 The Revenue Accounting form is used to manage your
revenue
 To view your contingencies, go to Line Revenue
Contingencies region
 To expire or remove a contingency, set the Estimated
Expiration Date to today‟s date.
 You cannot:
 Add a new contingency
 Update contingency name

 Auto Invoice and Invoice API
 You may interface contingencies
 Auto Invoice or Invoice API default contingencies

 Manual transactions
 Receivables defaults contingencies
 Order Management, and Service Contracts
 Support Pre-billing Acceptance

COGS AND REVENUE MATCHING
DESCRIPTION
 Ensures that COGS and Revenue recognition occur
in the same accounting period
 Developed by Costing, Order Management and
Receivables. This TOI covers the Receivables part
 Receivables provides the ratio between earned and
unearned revenue to Costing
 Obsolescence of Receivables‟ COGS and Revenue
Matching report.
 For complete information on this feature, please
refer to Costing and Order Management
documentation.

COGS AND REVENUE MATCHING BENEFITS
 Automate the synchronization of the Revenue and COGS
recognition
 Obsolescence of Receivables‟ COGS and Revenue
Matching report

COGS AND REVENUE MATCHING PROCESS
COGS RECOGNITION
 No user interaction is needed in AR.

 Cost Management
 Performs COGS recognition (or Cost Accounting)
 Integrates with Receivables for revenue information

 Order Management
 Provides order and return information to Costing
 Integrates with Receivables for invoice creation

 Notifies Costing when an order is closed without billing

MULTI-ORG ACCESS CONTROL DESCRIPTION

Belgium Holland Denmark
OU OU OU

EMEA-1 EMEA-1 EMEA-1
Responsibility Responsibility Responsibility

Perform tasks for multiple operating
units without changing responsibilities

MULTI-ORG ACCESS CONTROL BENEFITS
 Improve efficiency
 Easily access transactions from different operating units
 Improve Shared Services operations

 Provide more information for decision making
 Global consolidated view of transactions across operating units
 Reduce Costs
 Cut down processing time

RECEIVABLES & MULTI-ORG ACCESS
CONTROL
 The Operating Unit field:
 Is mandatory
 Defaults from the value that has been set for profile MO:
Default Operating Unit
 Is attached to a list of values that lists all operating units that
you have access to
 Is not used with:
 Payment terms
 Aging bucket forms

CONTROL
 Multi-Org Access Control functionality is also available on
Transactions and Bills Receivables forms
 Sources are defined per operating unit
 The list of values for Source shows all Sources for the
operating units that exist for the user session

CONTROL
 Multi-Org Access Control functionality is also available on
the Receipts form.
 Receipt Methods have remittance banks, which are defined
per operating unit
 The list of values for Receipt Method shows all Receipt Methods
that have banks in the operating units that exist for the user
session

MULTI-ORG ACCESS CONTROL PROCESS
 You can submit Concurrent requests for all
operating units in the user session – or for a specific
operating unit that you select.
 You can select the operating unit from a list of
values that lists all the Operating Units to which you
have access.
 Many concurrent processes can run for all
operating units in your security profile, including:
 Auto Invoice
 Auto Receipt Creation

 Statements

 Revenue Contingency

MULTI-ORG ACCESS CONTROL REPORTING
 All reports can be submitted for just one operating unit
 Cross organization accounting reports can still be submitted
for a whole ledger
 These reports now run for all operating units to which you have
access when the reporting level is set to Ledger

Oracle receivables

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Destacado

Destacado (14)

Similar a Oracle receivables

Similar a Oracle receivables (20)

Más de Suresh Mishra

Más de Suresh Mishra (20)

Último

Último (20)

Oracle receivables