Your SlideShare is downloading. ×
0
Oracle receivables
Oracle receivables
Oracle receivables
Oracle receivables
Oracle receivables
Oracle receivables
Oracle receivables
Oracle receivables
Oracle receivables
Oracle receivables
Oracle receivables
Oracle receivables
Oracle receivables
Oracle receivables
Oracle receivables
Oracle receivables
Oracle receivables
Oracle receivables
Oracle receivables
Oracle receivables
Oracle receivables
Oracle receivables
Oracle receivables
Oracle receivables
Oracle receivables
Oracle receivables
Oracle receivables
Oracle receivables
Oracle receivables
Oracle receivables
Oracle receivables
Oracle receivables
Oracle receivables
Oracle receivables
Oracle receivables
Oracle receivables
Oracle receivables
Oracle receivables
Oracle receivables
Oracle receivables
Oracle receivables
Oracle receivables
Oracle receivables
Oracle receivables
Oracle receivables
Oracle receivables
Oracle receivables
Oracle receivables
Oracle receivables
Oracle receivables
Oracle receivables
Oracle receivables
Oracle receivables
Oracle receivables
Oracle receivables
Oracle receivables
Oracle receivables
Oracle receivables
Oracle receivables
Oracle receivables
Oracle receivables
Oracle receivables
Oracle receivables
Oracle receivables
Oracle receivables
Oracle receivables
Oracle receivables
Oracle receivables
Oracle receivables
Oracle receivables
Oracle receivables
Oracle receivables
Oracle receivables
Oracle receivables
Oracle receivables
Oracle receivables
Oracle receivables
Oracle receivables
Oracle receivables
Oracle receivables
Oracle receivables
Oracle receivables
Oracle receivables
Oracle receivables
Oracle receivables
Oracle receivables
Oracle receivables
Oracle receivables
Oracle receivables
Oracle receivables
Oracle receivables
Oracle receivables
Oracle receivables
Oracle receivables
Oracle receivables
Oracle receivables
Oracle receivables
Oracle receivables
Oracle receivables
Oracle receivables
Oracle receivables
Oracle receivables
Oracle receivables
Oracle receivables
Oracle receivables
Oracle receivables
Oracle receivables
Oracle receivables
Oracle receivables
Oracle receivables
Oracle receivables
Oracle receivables
Oracle receivables
Oracle receivables
Oracle receivables
Oracle receivables
Oracle receivables
Oracle receivables
Oracle receivables
Oracle receivables
Oracle receivables
Oracle receivables
Oracle receivables
Oracle receivables
Oracle receivables
Oracle receivables
Oracle receivables
Oracle receivables
Oracle receivables
Oracle receivables
Oracle receivables
Oracle receivables
Oracle receivables
Oracle receivables
Oracle receivables
Oracle receivables
Oracle receivables
Oracle receivables
Oracle receivables
Oracle receivables
Oracle receivables
Oracle receivables
Oracle receivables
Oracle receivables
Oracle receivables
Oracle receivables
Oracle receivables
Oracle receivables
Oracle receivables
Oracle receivables
Oracle receivables
Oracle receivables
Oracle receivables
Oracle receivables
Oracle receivables
Oracle receivables
Oracle receivables
Oracle receivables
Oracle receivables
Oracle receivables
Oracle receivables
Oracle receivables
Oracle receivables
Oracle receivables
Oracle receivables
Oracle receivables
Oracle receivables
Oracle receivables
Oracle receivables
Oracle receivables
Oracle receivables
Oracle receivables
Oracle receivables
Oracle receivables
Oracle receivables
Oracle receivables
Oracle receivables
Oracle receivables
Oracle receivables
Oracle receivables
Oracle receivables
Oracle receivables
Oracle receivables
Oracle receivables
Oracle receivables
Oracle receivables
Oracle receivables
Oracle receivables
Oracle receivables
Oracle receivables
Oracle receivables
Oracle receivables
Oracle receivables
Oracle receivables
Oracle receivables
Oracle receivables
Oracle receivables
Oracle receivables
Oracle receivables
Oracle receivables
Oracle receivables
Oracle receivables
Oracle receivables
Oracle receivables
Oracle receivables
Oracle receivables
Oracle receivables
Oracle receivables
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Oracle receivables

5,094

Published on

Upgrade consideration for AR in R12 EBS

Upgrade consideration for AR in R12 EBS

Published in: Technology
1 Comment
5 Likes
Statistics
Notes
  • http://www.dbmanagement.info/Tutorials/Oracle_EBS.htm
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
No Downloads
Views
Total Views
5,094
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
538
Comments
1
Likes
5
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. ORACLE RECEIVABLESRelease 12 Upgrade Considerations
  • 2. 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
  • 3. 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
  • 4. NEW AND CHANGED FEATURES FOR BALANCEFORWARD BILLING Balance Forward Billing provides enhanced billing options that replace the consolidated billing functionality of prior releases with a more complete and flexible solution.
  • 5. 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
  • 6. 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
  • 7. 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
  • 8. BALANCE FORWARD BILLING SETUP ANDPROCESS 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
  • 9. BALANCE FORWARD BILLING SETUPDEFINE 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.
  • 10. BALANCE FORWARD BILLING SETUPDEFINE 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
  • 11. BALANCE FORWARD BILLING SETUPDEFINE 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
  • 12. BALANCE FORWARD BILLING SETUPCUSTOMER 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
  • 13. BALANCE FORWARD BILLING SETUPACCOUNT & 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
  • 14. BALANCE FORWARD BILLING SETUPACCOUNT LEVEL BILL EXAMPLE Bill Level Use Use Primary Bill-To Ignore
  • 15. BALANCE FORWARD BILLING SETUPSITE LEVEL BILL EXAMPLE Bill Level Ignore Use Use
  • 16. 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”
  • 17. BALANCE FORWARD BILLING PROCESSENTER 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
  • 18. BALANCE FORWARD BILLING PROCESSIMPORTED 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
  • 19. BALANCE FORWARD BILLING PROCESSCREATING 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
  • 20. BALANCE FORWARD BILLING PROCESSGENERATING BILL LOGIC
  • 21. 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
  • 22. BALANCE FORWARD BILLING PROCESSGENERATE 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
  • 23. BALANCE FORWARD BILLING PROCESSCONFIRM 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
  • 24. SUMMARY BALANCE FORWARD BILL EXAMPLE
  • 25. DETAIL BALANCE FORWARD BILL Balance and Summary information All lines for each invoice
  • 26. BALANCE FORWARD BILLING PROCESSBPA 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
  • 27. BALANCE FORWARD BILLING PROCESSDISABLE 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
  • 28. BALANCE FORWARD BILLING PROCESSCHANGE 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
  • 29. BALANCE FORWARD BILLINGDEPENDENCIES 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
  • 30. BALANCE FORWARD BILLINGFUNCTIONAL 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
  • 31. BALANCE FORWARD BILLINGFUNCTIONAL UPGRADE SCRIPT  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
  • 32. BALANCE FORWARD BILLINGFUNCTIONAL UPGRADE SCRIPT  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.
  • 33. 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
  • 34. 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
  • 35. 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
  • 36. CREDIT CARD CHARGEBACK BENEFITS Reduce costs by automating the credit card chargeback process
  • 37. 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
  • 38. CREDIT CARD CHARGEBACK PROCESS 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
  • 39. CREDIT CARD CHARGEBACK PROCESSRECEIVE 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
  • 40. CREDIT CARD CHARGEBACK PROCESSRECEIVE 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 $25Notify achargebackof $25 Vendor
  • 41. CREDIT CARD CHARGEBACK PROCESSRECORD 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)
  • 42. CREDIT CARD CHARGEBACK PROCESSVALIDATE CREDIT CARD CHARGEBACK The vendor can either:  Acknowledge the credit card chargeback or  Prove the credit card chargeback to be invalid
  • 43. CREDIT CARD CHARGEBACK PROCESSVALIDATE CREDIT CARD CHARGEBACK Vendor acknowledges the credit card chargeback • Credit the invoice by creating a credit memo – DR Revenue $25 – CR Receivables $25 Vendor
  • 44. CREDIT CARD CHARGEBACK PROCESSVALIDATE CREDIT CARD CHARGEBACK 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 $25Agree thatchargebackwas invalid Credit Card Company
  • 45. CREDIT CARD CHARGEBACK SETUP SETUP Create Receivables Activity of type Credit Card Chargeback
  • 46. 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
  • 47. 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
  • 48. LEGAL ENTITY MODEL No direct relationship Bank Legal Entity X OU Account Inv Org BG Ledger PrimaryInv Org = Inventory OrganizationOU = Operating UnitBG = Business Group
  • 49. 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
  • 50. 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
  • 51. 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
  • 52. 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
  • 53. LEGAL ENTITY DESCRIPTIONDEFAULTING 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
  • 54. LEGAL ENTITY DESCRIPTIONDEFAULTING 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 Entitys 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
  • 55. LEGAL ENTITY DESCRIPTIONDEFAULTING 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
  • 56. 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
  • 57. LEGAL ENTITY SETUP AND AUTOMATEDPROCESS 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
  • 58. LEGAL ENTITY SETUPUPDATE 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.
  • 59. LEGAL ENTITY SETUPUPDATE 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.
  • 60. 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
  • 61. LEGAL ENTITY PROCESS - AUTOINVOICE 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
  • 62. LEGAL ENTITY PROCESS - AUTOINVOICE 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
  • 63. 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
  • 64. LEGAL ENTITY PROCESS – MANUALTRANSACTION  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.
  • 65. LEGAL ENTITY PROCESS – ON ACCOUNTCREDIT 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
  • 66. 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
  • 67. 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
  • 68. LEGAL ENTITY PROCESS – CLAIM LEDEFAULTING Legal Bank Receipt Entity Account Method Non-Invoice Receipt Claim Header Invoice Claim Receipt Resolution Application LE Default Invoice Data Flow Claim
  • 69. 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?
  • 70. 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
  • 71. 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)
  • 72. RECEIVABLES E-BUSINESS TAX INTEGRATIONKEY 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.
  • 73. E-BUSINESS SUITE TAX PRIOR TO RELEASE12 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
  • 74. E-BUSINESS SUITE TAX INTEGRATION12.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
  • 75. ARCHITECTURE OF A TAX LINE IN E-BUSINESSTAX 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.)
  • 76. 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
  • 77. 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%
  • 78. 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
  • 79. MIGRATING OF TAX CODES AND TAX GROUPCODES 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
  • 80. 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)
  • 81. USE OF TAX CLASSIFICATIONS INRECEIVABLES 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.
  • 82. 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
  • 83. 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.)
  • 84. RECEIVABLES SPECIFIC TAX SETUPS Receivables Specific Tax Setups:  System Options  Customer  Transaction type  Receivables activity  Standard memo lines
  • 85. 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
  • 86. 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
  • 87. 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
  • 88. 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
  • 89. ADJUSTMENTS, RECEIPT DISCOUNTS, ANDRECOVERABLE 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.
  • 90. 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
  • 91. 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
  • 92. 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.
  • 93. 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
  • 94. 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
  • 95. 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
  • 96. IMPLEMENTATION CONSIDERATIONS  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.
  • 97. 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
  • 98. 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
  • 99. 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
  • 100. SUBLEDGER ACCOUNTING IN RECEIVABLESOVERVIEW  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
  • 101. SUBLEDGER ACCOUNTING IN RECEIVABLESBENEFITS  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
  • 102. SUBLEDGER ACCOUNTING IN RECEIVABLESPROCESS 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.
  • 103. SUBLEDGER ACCOUNTING IN RECEIVABLESPROCESS 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
  • 104. SUBLEDGER ACCOUNTING INRECEIVABLES PROCESS ONLINECREATE 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
  • 105. SUBLEDGER ACCOUNTING IN RECEIVABLESSETUP 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
  • 106. SUBLEDGER ACCOUNTING INRECEIVABLES SETUP LEDGERSAND 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
  • 107. SUBLEDGER ACCOUNTING IN RECEIVABLESSETUP SOURCES FOR ACCOUNTINGDEFINITIONSInvoice Event Class Entered Amount Operating Unit Customer Name Transaction Type Revenue Account PO Number Currency Tax Code Item Salesperson Invoice Number
  • 108. SUBLEDGER ACCOUNTING INRECEIVABLES SETUP PREDEFINEDEVENT CLASSES/TYPES Event Class* Event Types Create Invoice Update Create Credit Memo Update Create Receipt Update Reverse *Event Class = Receivables Document
  • 109. SUBLEDGER ACCOUNTING IN RECEIVABLESSETUPAR PREDEFINED EVENT CLASSES/TYPESEvent Class Event Journal Definition Assignment TypeAdjustments All Adjustments – Default AccrualBills Receivable All Bills Receivables – Default AccrualChargeback All Chargeback – Default AccrualCredit Memo All Credit Memo – Default AccrualDebit Memo All Debit Memo – Default AccrualDeposit Memo All Deposit Memo – Default AccrualGuarantee All Guarantee – Default AccrualInvoices All Invoices – Default AccrualMisc Receipt All Misc Receipt – Default AccrualReceipt All Receipt – Default Accrual
  • 110. SUBLEDGER ACCOUNTING INRECEIVABLES SETUP ANATOMY OFA 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
  • 111. SUBLEDGER ACCOUNTING INRECEIVABLES SETUP JOURNALLINE 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
  • 112. SUBLEDGER ACCOUNTING INRECEIVABLES SETUP ACCOUNTDERIVATION 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
  • 113. SUBLEDGER ACCOUNTING IN RECEIVABLESSETUP JOURNAL LINE DEFINITION OFINVOICES The Journal Line Definition is comprised of:  Journal Line Types (JLT)  Line Descriptions  Account Derivation Rules (ADR)
  • 114. SUBLEDGER ACCOUNTING INRECEIVABLES SETUP ASSIGNING THEJLD 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
  • 115. SUBLEDGER ACCOUNTING IN RECEIVABLES SETUPASSIGNING THE AAD TO THE SLAM  Subledger Accounting Methods Form  Application Accounting Definitions (AAD) are assigned to Subledger Accounting Methods
  • 116. SUBLEDGER ACCOUNTING IN RECEIVABLES SETUPASSIGNING 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
  • 117. SUBLEDGER ACCOUNTING IN RECEIVABLES SETUPPREDEFINED 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
  • 118. SUBLEDGER ACCOUNTING INRECEIVABLES PROCESS INVOICEACCOUNTING 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 Revenue $200 CR Revenue $200 CR Tax $ 10 CR Tax $ 10 CR Tax $ 20 CR Tax $ 20 CR Freight $ 30 CR Freight $ 30
  • 119. SUBLEDGER ACCOUNTING IN RECEIVABLESPROCESS MULTI-FUND RECEIVABLESACCOUNTING 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
  • 120. SUBLEDGER ACCOUNTING IN RECEIVABLESPROCESSADJUSTMENT 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
  • 121. SUBLEDGER ACCOUNTING IN RECEIVABLESPROCESS RECEIPT APPLICATIONACCOUNTING $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 *
  • 122. SUBLEDGER ACCOUNTING IN RECEIVABLESPROCESS RECEIPT APPLICATIONACCOUNTING $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 Revenue $100 CR Revenue $100 CR Tax $ 5 CR Tax $ 5 CR Tax $ 10 CR Tax $ 10 CR Freight $ 15 CR Freight $ 15 CR Adjustment -$ 10 CR Adjustment -$ 10 CR Adjustment -$ 20 CR Adjustment -$ 20
  • 123. IMPLEMENTATION CONSIDERATIONS Accounting Configurations Subledger Transactions Journal Entries GL Journal Accounting Entries Program and Balances Accounting Subledger Events Balances Journal Entry Setup Receivables SLA
  • 124. 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
  • 125. OBSOLESCENCE AND REPLACEMENT OFFEATURES 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
  • 126. OBSOLESCENCE AND REPLACEMENT OFFEATURES DESCRIPTION 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
  • 127. OBSOLESCENCE AND REPLACEMENT OFFEATURES DESCRIPTION  Trade Accounting  Provided a way to handle customer deductions and overpayments  Replaced by Deductions Management, using Trade Accounting and Credit Management
  • 128. OBSOLESCENCE AND REPLACEMENT OFFEATURES DESCRIPTION  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
  • 129. OBSOLESCENCE AND REPLACEMENT OFFEATURES DESCRIPTION  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
  • 130. OBSOLESCENCE AND REPLACEMENT OFFEATURES DESCRIPTION  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
  • 131. OBSOLESCENCE AND REPLACEMENT OFFEATURES DESCRIPTION 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
  • 132. OBSOLESCENCE AND REPLACEMENT OFFEATURES DESCRIPTION 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
  • 133. OBSOLESCENCE AND REPLACEMENT OFFEATURES 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
  • 134. TRANSITION TO NEW FEATURESCOLLECTIONS 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
  • 135. TRANSITION TO NEW FEATURESCOLLECTIONS WORKBENCH - MENUAND 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
  • 136. TRANSITION TO NEW FEATURESCOLLECTIONS 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.
  • 137. TRANSITION TO NEW FEATURESCOLLECTIONS WORKBENCH - DUNNINGREPRINT  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
  • 138. TRANSITION TO NEW FEATURES BILLSRECEIVABLE  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  For more information:  If you plan to transition to Bills Receivable before or after the upgrade, review the white paper: “Oracle Receivables Bills of Exchange Obsolescence”
  • 139. TRANSITION TO NEW FEATURES TRADEACCOUNTING  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  For more information:  “E-Business Suite Solutions for Deduction Management, An Oracle White Paper Release 11i.10”
  • 140. TRANSITION TO NEW FEATURESCUSTOMER STANDARD FORM  What changed:  Old Standard customer forms replaced by HTML UI  Updates to Customer Profile Class form  Required steps:  No actions required
  • 141. TRANSITION TO NEW FEATURESTAX 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
  • 142. TRANSITION TO NEW FEATURESTAX 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
  • 143. TRANSITION TO NEW FEATURESSUBLEDGER 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
  • 144. TRANSITION TO NEW FEATURESCOGS 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
  • 145. TRANSITION TO NEW FEATURESAR CUSTOMER SUPPLIER NETTING  What changed:  AR Customer Supplier Netting Report retired  Replaced by centralized, automated netting feature  Required steps:  Setup AP/AR Netting
  • 146. TRANSITION TO NEW FEATURESON 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
  • 147. TRANSITION TO NEW FEATURESCONSOLIDATED 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
  • 148. 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
  • 149. CENTRALIZED PAYMENT PROCESSDESCRIPTION Common Engine for Payment Transactions Oracle Payables Oracle Financial Receivables Oracle Institutions Oracle Order Payments Management Credit Card Processors Other Oracle Modules
  • 150. CENTRALIZED PAYMENT PROCESSDESCRIPTION  Leverages Oracle Payments Funds Capture  Oracle Payments stores external bank accounts and payment information  Centralized data encryption  Centralized processing for automatic payment method
  • 151. CENTRALIZED PAYMENT PROCESSDESCRIPTION  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
  • 152. CENTRALIZED PAYMENT PROCESSSETUP 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
  • 153. CENTRALIZED PAYMENT PROCESS SETUPCREATE 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”
  • 154. CENTRALIZED PAYMENT PROCESSPROCESS 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
  • 155. CENTRALIZED PAYMENT PROCESS ERRORHANDLING The Correct Funds Transfer Error form is used for:  Credit Card and Bank Account Transfer errors  Error Handling for automatic payments
  • 156. CENTRALIZED PAYMENT PROCESS SETUPCUSTOMER‟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
  • 157. IMPLEMENTATION CONSIDERATIONS  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
  • 158. 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
  • 159. AUTOMATED REFUNDS DESCRIPTION  Automate refund process for non-credit card transactions  Leverage AP workflow approval  AP transacts refunds via Oracle Payments
  • 160. 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
  • 161. AUTOMATED REFUNDS SETUP RECEIVABLESACTIVITY  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.
  • 162. AUTOMATED REFUNDS SETUP TRANSACTIONSOURCES  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
  • 163. AUTOMATED REFUNDS SETUP TRANSACTIONSOURCES  No user interaction is needed.  Create credit memos via Auto Invoice  Refunds are automated  View refund status in AP workbench
  • 164. AUTOMATED REFUNDS PROCESSAPPLICATIONS 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
  • 165. AUTOMATED REFUNDS PROCESSNEW 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
  • 166. AUTOMATED REFUNDS PROCESS VIEWREFUND STATUS  Use Refund Status to view the refund status in AP  Refund status is not applicable for credit card refund
  • 167. IMPLEMENTATION CONSIDERATIONS  Oracle Payables  Automated refund for non-credit card transactions
  • 168. 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
  • 169. 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
  • 170. AP/AR NETTING BENEFITS Increase user productivity and effectiveness with more automation and integration
  • 171. AP/AR NETTING PROCESS ACCESS You can now access forms for creating and updating:  Netting Batches  Netting Agreements
  • 172. 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
  • 173. 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
  • 174. 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
  • 175. DAILY REVENUE DESCRIPTION  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
  • 176. DAILY REVENUE DESCRIPTION  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)
  • 177. DAILY REVENUE DESCRIPTION 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
  • 178. DAILY REVENUE DESCRIPTIONR11i vs. R12 revenue distributionsExample: 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
  • 179. 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
  • 180. 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)
  • 181. DAILY REVENUE PROCESS CREATE INVOICELINE  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
  • 182. IMPLEMENTATION CONSIDERATIONS  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
  • 183. 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
  • 184. 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
  • 185. 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.
  • 186. 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
  • 187. REVENUE CONTINGENCIES SETUP ANDPROCESS 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
  • 188. REVENUE CONTINGENCIES SETUP POLICYTHRESHOLD 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
  • 189. REVENUE CONTINGENCIES SETUPSEEDED 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
  • 190. REVENUE CONTINGENCIES SETUPCONTINGENCY 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
  • 191. REVENUE CONTINGENCIES SETUP CREATERULES  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
  • 192. REVENUE CONTINGENCIES PROCESSCONTINGENCY ASSIGNMENT PROCESS Assign Contingencies Evaluate assignment rules Create invoice line Assign contingencies if criteria is met Is the revenue Defer Revenue if policy contingenciesFeeder Systems such met? Yes existas Order NoManagement and Recognize RevenueService 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
  • 193. REVENUE CONTINGENCY PROCESSMANAGE 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
  • 194. IMPLEMENTATION CONSIDERATIONS  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
  • 195. 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
  • 196. COGS AND REVENUE MATCHINGDESCRIPTION  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.
  • 197. COGS AND REVENUE MATCHING BENEFITS  Automate the synchronization of the Revenue and COGS recognition  Obsolescence of Receivables‟ COGS and Revenue Matching report
  • 198. COGS AND REVENUE MATCHING PROCESSCOGS RECOGNITION No user interaction is needed in AR.
  • 199. IMPLEMENTATION CONSIDERATIONS  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
  • 200. 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
  • 201. 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
  • 202. 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
  • 203. RECEIVABLES & MULTI-ORG ACCESSCONTROL 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
  • 204. RECEIVABLES & MULTI-ORG ACCESSCONTROL  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
  • 205. RECEIVABLES & MULTI-ORG ACCESSCONTROL  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
  • 206. 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
  • 207. 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
  • 208. MULTI-ORG ACCESS CONTROL REPORTINGPROCESS  Submit reports  The reports that can run for all operating units in the user‟s security profile are listed in the notes for this slide.

×