Oracle R12 eBtax Solution Design

Page

1 of 7

Oracle R12 eBtax Solution Design

Table of Contents

Document Modifications (Since User Approval) Summary Business Requirements & Solution Approach Key Design Considerations Assumptions Solution Matrix Testing Scenarios Action Items

Page

2 of 7

Oracle R12 eBtax Solution Design

Summary
This document defines the functional design required to implement E-Business Tax with Taxware Geo and Rate file for Calculating Taxes on Order to Cash & Procure to Pay Transactions.

Business Requirements & Solution

Requirement: Ability to calculate sales tax for California drop shipments only. But system should be flexible to be able to add on other states as needed. Solution: The current Tax Rules accommodate Tax applicability for the state of CA. In future if Client wants to change or extend its tax rules to other states then Tax Rules will be modified to accommodate new state. However the Regime to Rate setup will remain the same. Requirement: Ability to look up and apply sales tax based on the sales tax rate in effect for the city where the product was shipped to (NOT bill to). Solution: Tax Rules were defined based on Ship To for State / County and City (CA State Only) Requirement: Ability to apply current sales tax rate in effect (as determined by SBOE) as of the billing date. Solution: Client has purchased the Geography and Tax Jurisdictions from the ADP Inc., called as Taxware. As part of system maintenance Client IT should upload Jurisdiction and Tax Rate file updates from ADP periodically may be monthly or quarterly and keep the tax rates latest. Requirement: Sales tax rates must be current at all times, as reported by SBOE. Ability to change with minimal programming effort. Solution: As part of system maintenance Client IT should upload Jurisdiction and Tax Rate file updates from ADP periodically may be monthly or quarterly and keep the tax rates latest. Requirement: Sales tax should be applied to product purchase price less discount (the net amount after discount). Ability to change rules for future states if needed. Solution: Tax will be applied to product purchase price less discount (the net amount after discount). Ability to change rules for future states will have to be done by changing the Tax Rules as when Client wants to do so. Requirement: System to validate customer city/county name that gets downloaded from website. Solution: XML Interface downloads the file sent by the website and will upload the State County and City information in the customer address. Requirement: If tax rate differs between website and Oracle, as I understand, system will put order on hold. Need ability to see which orders are on hold. OR if possible post the difference to a designated sales tax adjustment account. Solution: A Decision has been made by Client that Oracle calculated Tax will be considered for Tax Filing purposes. Any penny differences will be dealt with. (Srini pls paste the email decision) Requirement: Manually - If balance is a liability, must pay to SBOE, if balance is a receivable, write it off. Solution: This can be done by running auto adjustment in Receivables module. Requirement: Manual CM and DM transactions - system should be able to reverse or add sales tax when entering CM and DM if sales tax was applied on the original invoice. Solution: This is standard functionality in Oracle Receivables

Page

3 of 7

Oracle R12 eBtax Solution Design

Requirement: Manual Invoices ability to allow sales tax calculation where appropriate (ship to address CA) and if type of sales is Retail (sales to end user). Solution: The Web order interface tags the Web Customer with a WEBORDER Classification. EBTax Calculates taxes only on Web Order Customers only. Requirement: Ability to charge sales tax on any future new customers that may not have sales tax exemption (not within Weborders transactions) with minimal programming effort. Solution: Since we were asked to calculate taxes for Web Customer we have configured the rules accordingly. However for non-web customers users can manually add the taxes Requirement: Sales Tax collected/refunded should be posted to account number 100.0000.212026.00000.000.00000. Solution: This was handled accordingly Reporting Requirement Ability to provide Sales Tax Report by State to satisfy reporting and supporting documentation. Sales Tax report should include the following information: Invoice Number Invoice Date Customer Name Taxable Revenue (include CM and DM) Non Taxable Revenue (include all other customers outside of Weborders) Sales Tax Collected/refunded Sales Tax Rate Ship to City Ship to County Subtotal by County Subtotal by State

And Ability to select by date range (must tie to GL Revenue accounts and sales tax postings). Solution: Currently being worked out. Effect & Requirement on Other Modules Purchasing I dont recall the decision?? Allow for sales tax calculation?? If Yes Sales Tax to be calculated on CA delivery address only. Ability to calculate tax for future new locations within CA and out of state. See AP when to apply tax.

Accounts Payable Sales Tax should only be applied to goods (Inventory and Service excluded) delivered to CA only (currently locations are 225 Gateway, 201 Gateway, and Anaheim, CA). Sales Tax rate to be applied should be based on the delivery address ex. 225/201 Gateway = San Mateo County sales tax rate, Anaheim = Orange County. Ability to calculate tax for future new locations within CA and out of state with minimal effort.

Page

4 of 7

Oracle R12 eBtax Solution Design

Solution: Per direction from Susan we are not changing any P2P rules which were decided during Original Implementation

Approach
Taxware Geo/ Rate File would be uploaded into ZX Tax Rate Interface Tables after doing Mandatory prerequisite setups are complete. Tax Rules will be configured to accommodate the Business Requirements as specified in the above section A Custom / Discoverer Report will be designed to meet the Reporting requirement based on assessing if the default discoverer views are satisfactory.

Key Design Considerations

Client was implemented using Oracle Business Accelerator (OBA). OBA always does Operating Unit Owner Context Party Tax profile as Legal Entity subscription. This assumption was done by OBA considering all the Operating Units under one Legal Entity will have the same tax setup. This setup cannot be undone. What does this mean in business sense? I.e. All Operating units under Client Legal Entity will by default get the proposed eBTax setup applied automatically because of above option. Example Legal Entity = Client Inc., (United States) Operating Unit 1 = Client US (currently there is only one OU for Client Legal Entity) In Future if Client plan to setup a new OU under the Client Inc. Legal Entity Operating Unit 2 = Peoria (This OU name is fictitious) Peoria also will get the Client Inc. (Legal Entity) tax rules applicable by default because of the above tax option chosen by Operating Unit Owner Context Party Tax Profile. Why are we discussing this Option? From Design perspective we want Client know all options available under the current setup. It is always assumed that every Legal Entity has one Tax Regime and Tax Setups applicable under current operating unit defaults to other (new) operating units irrespective of how many operating units will the Client Inc. LE has.

Assumptions
This design assumes that the following statements are true: 1. Susan has decided that the Procure to Pay Transaction Taxes will not be changed. Hence the requirements give in the above section will NOT be considered. 2. Report design - Oracle Discoverer will be evaluated to see if the Tax Report can be accomplished. If discoverer views doesnt accommodate then a custom XML Report will be defined

Page

5 of 7

Oracle R12 eBtax Solution Design

3. All Tax Rules are designed with current requirements into consideration and future scalability. However certain times if future organization requirement changes then the tax rules will have to be re-evaluated. However the setups can remain unchanged

Solution Matrix
# Requirement Calculate Use 1 Tax P2P PO AP Description Tax Can be manually over written Tax Can be manually over written Tax CA USE Tax Factor Product Type Geography Ship to Registration Service 2 Purchases P2P Sales Tax should not apply Tax Can be manually over written = = Equal Conditions Services CA Registered

PO AP

APST

Inventory Purchases P2P

PO AP

Purchasing item category = Inventory Tax Can be manually over written

APST

Product Type Geography Ship to Product Inventory Linked Product Category Registration

= <> = = =

Services CA Purchasing item category = Inventory Exempt Not Registered

O2C STATE Sales 3 Tax COUNTY Sales Tax City Sales Tax

OM AR

Tax Can be manually over written

STATE COUNTY CITY

Geography Ship to Account

Equal Equal

CA 100.4700.410100.00000.000.0 00.000

Page

6 of 7

Oracle R12 eBtax Solution Design

Testing Scenarios
Test Scenarios for Testing Taxware Rate File Integration and EBTax Setups Test Scenario # WEB Order CA Vendor - Check for 1 State County and City Taxes WEB Order NON - CA Vendor - Check 2 for State County and City Taxes WEB Order CA Vendor Freight & Misc. - Check for State County and 3 City Taxes WEB Order NON - CA Vendor Freight and Misc. - Check for State County 4 and City Taxes Create Manual AR invoice ex- AR 5 Transaction Type Invoice Type Create Manual AR invoice ex- Web 6 Order Invoice Type Create PO and match it to AP invoice ( P2P taxes should apply) Goods PO 7 and Services PO Create Inventory PO and match it to AP invoice ( P2P taxes NOT should 7 apply) Goods PO and Services PO Check for overlapping of P2P and 8 Taxware Taxes 9 Tax Accounting on O2C side 10 Tax Accounting on P2P side 11 Tax Accounting for Use Tax Invoices Validate Customer Address - enter Wrong City / county name 13 Create a non web order in OM and 14 interface to AR for CA state Create a non web order in OM and 15 interface to AR for non-CA state Web Order Tax validations: Check for Taxes between Web order and Oracle at header and line level 15 Web Order with Discount information - Tax should calculate on Net amount 16 after discount Check for Customer Address fields on Web order XML file to make sure 17 everything is populated No No Yes Yes No No No No Yes Yes OM No No AR Yes Yes PO No No AP No No Tax Yes Yes PO or OM 2100943 2100944 AR or AP Expected Results Result Taxes should apply Passed Taxes should NOT apply Passed NA Taxes should NOT apply NA Taxes should NOT apply No No No Yes No No No No No No NA NA 102108 No No NA NA NA No No NA NA NA No Yes NA NA NA No Yes NA NA NA No Yes NA NA Yes 102106 102107 Passed Passed 102109 10068 10069 Passed Taxes should apply Passed P2P taxes should Apply Passed P2P taxes should NOT Apply Passed Passed Passed Passed Passed Web Order Tax rules should not apply Accounting Accounting Accounting System should throw geography error. User has to manually correct the Geography info to match with Master Geography Taxes should NOT apply Taxes should NOT apply 2100943 Passed Website and Oracle Tax should match - Client to decide on what to be done in these scenarios Tax should calculate on Net amount after discount

Freight NOT Taxable for CA State

Passed Passed

AMG., Inc. 2100943

Passed Passed

NA

NA

NA

NA

NA

Passed Passed Passed

Appropriate CA taxes should appl

Page

7 of 7