Skip to main content

Legal

Tax & Accounting

Trade & Supply

Risk & Fraud

News & Media

Books

Developers

Topics

ONESOURCE Indirect Tax Integration for SAP Global Next - FAQs

What is the Thomson Reuters response to items/topics brought up bySAP inOSS Notes 1497956 and 1738657?

Thomson Reuters Support Promise

Thomson Reuters works closely with our customers to ensure our products work seamlessly with their environment.
The ONESOURCE Indirect Tax Integration for SAP is built, maintained, and owned by Thomson Reuters Tax & Accounting Indirect Tax. The business unit has a dedicated group of SAP Business Systems Analysts, ABAP Programmers, and Quality Assurance personnel who have built this product. We follow SAP best practices, development standards, and strive to minimize the impact this solution will have on your SAP environment. With any 3rd party Add-On in SAP, the vendor providing the solution is responsible for support of that Add-On. In case of an issue with the ONESOURCE Indirect Tax Integration for SAP, please submit a support ticket by opening a new case in Customer Center.

Tax Business Process Certification vs. ABAP Add-On Certification

SAP, for US, CA, and PR provides a business process certification for the jurisdiction based tax interface (TAX-US-R3). When reviewing the certification test scenarios, you can judge yourself of the scope and limited coverage of use cases of this certification. Business Process specific certifications are the exception of solution certifications performed by SAP -a majority of solutions are certified via the ABAP Add-On certification; a technical type of certification provided by SAP, which ensures the vendor's provided solutionfollows SAP best practices, development and support standards. Thomson Reuters Global Next interface for SAP has been designed and built taking these requirements into account. It is our intention to pass SAP's ABAP Add-On certification with our solution, and we are working with SAP on resolving the few areas where the current solution isn't confirming to SAP standards.

SAP Notes 1497956 and 1738657

These two notes have been brought to our attention by customers, prospects, and partners from time to time. Most notably each time SAP changes the note triggering awareness of it. Note 1497956 was originally released on 08/11/2010 and note 1738657 on 07/05/2012. They outline SAP standpoint on supporting tax calculations outside US, CA, and PR via an external tax system.
Note 1497956 lists several statements by SAP about issues that possibly could be a risk for a customer using a solution other than SAP's standard condition based tax approach (outside US, CA, PR) or the jurisdiction based interface for US, CA, PR. For each area SAP commented on, please find an explanation provided by our Thomson Reuters SAP Product Management team:
1) The SAP system relies on the so-called SAP Tax Code, the Tax System does not. E.g. depending on the tax code many tax decisions are made and the tax code is derived by many applications or even entered or overridden by the user because the user knows - and there is no other information - how certain cases are to be taxed. The SAP Tax Code carries properties which are important for the tax calculation and for reporting and those properties are leveraged by the SAP system.
TR Response:
 The Global Next tax interface embraces the SAP use of the tax code. We use the tax code to trigger the tax call to Determination, and once a tax calculation has been made we return a SAP Tax Code and Account Key combination back to SAP to be assigned to the SAP transaction to ensure that posting to the G/L and all downstream processes work seamlessly. The tax codes used with Global Next are setup in SAP with all their usual properties, except a tax rate. This ensures proper reporting and downstream processing, while at the same time removing the burden to maintain tax rates in SAP and creating new tax codes each time a rate changes. This ensures that customers don't run out of SAP tax codes due to the two-digit limitation on tax codes.
2) If you use systems <> SAP's ERP, you also will have to enhance them but they might use a different technology to use a Tax system (e.g. in CRM).
TR Response:
 While SAP provides a jurisdictional tax interface in CRM and SRM they do not warrant that taxes are calculated equally across all systems due to limitations in each systems solution provided by SAP. Thomson Reuters is aware of the need to have tax interfaces for our customers in all of SAP's products, and we are working towards that goal in our long-term planning.
3) Currency Handling in Tax System might be different from SAP Standard. Currencies, exchange rates and some master data have to be maintained twice.
TR Response:
 While there are known gaps in our current Suite of Solutions we are working on closing these gaps. Our over 150 customers have been able to manage and we have been able to provide adequate workarounds. We know this is a priority for our customers. Our designs will take into consideration that the ERP system should be the leading source of currency and exchange rates, as for other master data we provide means to integrate them seamlessly via SOAP technology if a customer desires to do so to ensure they are accurate in both systems all the time.
4) Performance: The Tax System would have to be called for more Tax Calculations and Updates and would significantly increase the number of Tax System Calls and the workload for the Tax System. The Tax System should be able to handle this (Scalability, etc.).
TR Response:
 Our technology scales well with our customers' needs. We have some of the largest clients with millions of transactions per month.
5) Tax Calculations and Tax Updates (Tax System) which are not done if external Tax Calculation (US, CA, PR) is used in SAP Standard because they are not required for US, CA and PR e.g. for discounts (payment, offsetting), Tax in process like purchase orders not invoiced, etc. but they are required for other countries. Modifications of the SAP Standard might be required to get this to work and you might run into performance issues because more data would have to be read, etc. to support this somehow.
TR Response:
 This is a speculative statement. Thomson Reuters has proven that our technology doesn't adversely impact a client's deployment. In contrary to this statement, our customers frequently request and require tax calculations where SAP doesn't provide them in their solution as they see that as a GAP within SAP.
6) Tax calculation is usually not done per item but per tax rate in SAP but not by the Tax Engine. If SAP changed it, it would be even questionable from a legal perspective.
TR Response:
 This statement is misleading by SAP as it makes an assertion that the way an external tax system calculates tax might not be legal. Our tax solutions have withstood reviews of some of the largest corporations, as well as been reviewed by many auditors around the world. The tax calculations done in Determination follow each country's legal requirements. We then return taxes to SAP by SAP Tax Code and Account Key, ultimately providing the exact same indicators in SAP as SAP native would.
7) Some data might be needed for the Tax Engine but might not be available in the application.
TR Response:
 Our solution is built with flexibility in mind. The Global Next Flexible Field Mapper allows a tax business analyst to add tax relevant data elements to the tax interface call without the need of ABAP programming or technical skills. In addition we provide extensive options in the tax engine to model, test, and build the most complex tax policies corporations might have. All without the need of extensive access sequence, condition table, and user-exit coding in SAP.
8) In SAP Standard the so-called tax code is used for tax calculations without using the Tax System for many countries. At some points in the coding the country or Tax System customizing is explicitly checked to make some decisions and modifications might be necessary to change this.
TR Response:
 The tax decisions and process are done in Determination, SAP becomes the source of the relevant data, but is no longer used to make the decisions. By building the Global Next solution outside of SAP's tax process and jurisdiction based tax interface we have eliminated this dependency on SAP country specific code.
9) Down Payments, Down Payment Requests.
TR Response:
 It is not clear what SAP tries to state here. For US, CA, and PR these processes aren't supported by SAP via the jurisdictional interface, resulting in a GAP for customers in industries where down payments are common. The Global Next solution enables Down Payments and adheres to country specific applications of down payments and cash discounts based on configurations.
10) Tax postings or other postings or other scenarios are not known in the Tax System and might not be really supported by Tax System.
TR Response:
 The Thomson Reuters Global Next solution is focused on the core SD, MM, and FI processes within ECC 6.0. We are aware that there are some other areas where tax calculations are needed such as with Travel Management, FI-CA, etc. We are working closely with our customers in addressing their specific needs in these areas. The Global Next product was designed to be able to be extended to other SAP areas without major rewrites.
11) Tax filing processes (Advance Return for Tax on Sales/Purchases, EC Sales List, etc.).
TR Response:
 Since the Global Next integration uses standard SAP tax codes and posts them back to SAP with the tax results these downstream processes can be run within SAP just like they can when using native SAP.
12) Tax audit in particular for countries which require audit files which include VAT related data and other data (e.g. Standard Audit File Tax by OECD)
TR Response:
 This assertion does not seem clear. As for audit and filing of taxes; Global Next uses standard SAP tax codes allowing the running of SAP's audit and filing processes such as transaction code F.12 and creating the standard audit files.
13) Tax Reporting including nota fiscal (Brazil)
TR Response:
 The tax engines purpose isn't to provide the Nota Fiscal, but rather to calculate the appropriate taxes. By returning all the tax details, including tax relevant data needed during the Nota Fiscal issuance, our solution will ensure that the Nota Fiscal can be generated within SAP via the standard processes provided by SAP.
14) Follow-up processes which rely on SAP tax codes (e.g. deferred tax, Input tax from parked documents e.g. report RFPUMS00, Analyze GR/IR Clearing Accounts and Display Acquisition Tax e.g. report RFWERE00, Partially Exempt Organizations also called PEO Solution, SAPF104, etc.)
TR Response:
 This is indeed a tricky area as SAP isn't consistent in their design and use of the tax code and tax rate of that tax code. In some processes SAP will use the tax code and rate as stored in the general ledger account posting, in other areas SAP goes back to the tax code master data. This is quite inconsistent and has required Thomson Reuters to evaluate all areas relevant to downstream processing and apply solutions specific to each area that can coexist with SAP process. We are committed to addressing these areas and have been working with our customers to identify them.

Further questions

For additional questions please open a Software Support Ticket which will be routed to the Product Manager for the SAP Integrations.

This article applies to:

  • PRODUCT: ONESOURCE Indirect Tax
  • Sub Product: SAP