EBTax Design Considerations - CLIENT

Santosh Kumar
Oracle R12 Functional Consultant Email santosh@roverresources.com Phone 501 288 9089

Agenda
CLIENT US Operations CLIENT US Organizational Structure Key Tax Requirements How to Map Requirements into Solution? Available Options / TDFS Evaluation How to restrict Usage Tax applicability Options Proposed

CLIENT US Operations
CLIENT has 29 locations (located in 15 States) in the US and files State tax returns in 21 States In many locations, a customer may pick up the material at Clients location or it may be delivered to their office/warehouse. Multi Org Structure for US operations consists of a Ledger US Operations and 4 Operating Units

Distribution

Taxable Customers OU Ltd. (300) Plants Exempt Customers (as they do not remit Sales Tax) OU Inc. (400) OU Inc. (450) OU Inc. (550)

For all the above OUs US Location based tax is applicable and needs to be configured in the system.

How EBTax Determines Applicability

EBTax Calculates Taxes based on Configuration of Tax Rules.

The Tax Rules consists of Tax Determination Factors (TDFS) and Tax Condition Sets (TCS). If the conditions specified in the TDF Sets are met then EBTax will calculate Tax on Transactions (ex:- on Sales Orders (Estimated Tax) & AR Invoices (Actual Tax) A TDFS will be configured based on CLIENT s Requirements which would be chosen from the Oracle Pre-Defined Qualifiers NO CUSTOM QUALIFIERS ARE ALLOWED Any EBTAX Solution should revolve around the Pre-Defined Qualifiers as Tax Engine reads only them.

Examples of TDFS and TCS

TDFS can be defined in E-Business Tax Based on the following four Pre-Defined Qualifiers:
Places Tax for CLIENT US operations should apply in 21 States Process O2C / P2P Transactions Ex:- Sales Orders, Invoices etc Product CLIENT has Product Specific Exemptions. Ex- Item Exemptions etc Parties CLIENT have any party specific Requirement

Examples of TDFS and TCS

Limitations on defining TDFS / TCS Oracle Suggests not to define more than 10 Conditions on a Tax Rule because of Performance Issues There are no Tax Determining Factors available on Order Management. Refer Note - 955242.1 Enhancement Request 9036865 for future Release

Key Solution Design Considerations

The following factors were evaluated for design:

Geography - CLIENT is Registered in 21 states Hence Tax should be calculated for Customers in these 21 States only Processes / Parties - Only CLIENT Ltd. OU-300 Customers Transactions are Taxable. OU Inc. (400) / OU Inc. (450) / OU Inc. (550) OU Customers are Exempt from Tax. Place of Supply - CLIENT US can ship to Customer Locations or Customer can pick at CLIENT Locations.

Solution Dependent Questions / Points

Tax on Sales Orders is Estimated Tax Does CLIENT considers Tax to be Calculated on Sales Orders? Does CLIENT sends Pro-forma invoices to customers during the shipping process along with Shipping documents? If CLIENT sends Pro-forma Invoice to customers along with Shipping documents does Pro-forma invoice includes Sales Tax? How Does Tax printed on Kaycans Invoice is it in Summary or Detail?

Proposed Solution

After careful evaluation the following applicable TDFS was considered to be proposed:
Tax Zones Document Subtype to specify a Transactions as Taxable or not? Product Category Buffer to be used for tax rule flexibility

Each will Transaction will carry a Value for Column Document Subtype TDF are not available in the Order Entry Hence estimated Tax will not apply on Sales Orders but

Condition1: If ship to state is one of the 21 states - solved Condition2: Is tax applicable for this OU customers ex:300 - yes else specific customer applicable - GCO Condition3: For non 300 OU specific customer evaluation ? check if customer site level taxable DFF value is "Y".

Solution Design Approach GCO vs OU - Information

What is GCO ? When to use GCO Pros One Configuration with multiple Regime Subscriptions Ex - is is assumed that GCO is used when All operating units under Legal Entity - CLIENT US operation will have same tax applicability - Can use Seeded Sales Tax Interface as this interface is always pointed to Global Configuration Owner - Refer SR # 3-4637207011

Solution Design Approach GCO vs OU - Information

Cons Tax Rate Load Difficult to distinguish the Tax applicability between multiple operating units Seeded TDF might not meet CLIENT s Requirement In most cases we need to rely on custom code to populate the tax applicability - especially if Tax is driven based on Sales Orders EX- Configuring Tax Requirements to Application patching will have direct impact on the Custom code.

Solution Design Approach GCO vs OU - Information

Pros - Configuration Maintained at OU Level. - Each OU can have its own Taxability Rules and Definitions - Flexible and easy to differentiate with other OUs in terms of System Configuration

Cons Cannot use seeded Sales Tax Interface as this interface is always pointed to Global Config Owner - Refer SR # SR 3-4637207011 Custom Tax rate upload / updates - this method will be achieved by direct updates and inserts into Base Tables - Most of the Customer use this process too.

Solution Design Approach GCO vs OU - Information

Cons One Regime with multiple Regime Subscriptions and Regime to Rate Flow for Each OU in specific Application patching will have direct impact on the Custom code. Requirement: for OUs 450 etc - all customers are non Taxable. CLIENT wants flexibility to apply tax to the Customers when circumstances need for tax applicability. Existing customers - One time Customer Site Conversion to populate Party Fiscal Classification (which is a TDFS in EBTax) New Customer - add the party Fiscal Classifications ( Train the Customer Setup Group on how to use this)

Thank You