Skip to end of metadata
Go to start of metadata

Purpose

The purpose of this page is to clarify the functionality of tax jurisdiction in SD.

Overview

In the following sections you will find information about the Customizing in SD and FI, Tax determination in the Sales document and Releasing to accounting.

Customizing in FI and SD

Customizing in FI

SPRO -> Financial Accounting -> Financial Accounting Global settings ->Tax on Sales/Purchases -> Basic settings 

  • Access Sequences
  • Define Condition Types
  • Define Procedures

The tax procedures are similar to SD pricing procedures. They contain all tax conditions that could appear in the SD document.

Examples:

  • TAXUS
  • TAXUSJ
  • TAXUSX

The Tax jurisdictions are necessary in countries were they are activated. Technically speaking:

  • The country has a Tax procedure assigned in transaction OBBG (field T005-KALSM)
  • If this Tax procedure has entries in transaction OBCO (table TTXD), then the country is relevant for Tax jurisdiction

It means that sales documents raised in this country should have:

  1. Tax jurisdiction conditions in pricing procedure
  2. The ship-to party should have tax jurisdiction in master data. In case of export, and the ship-to party has not tax jurisdiction, then a default should be set in transaction OBCL (see KBA 1672122)

Customizing in SD

The pricing procedure must include the trigger condition and the tax conditions. In this sample, in US: trigger condition UTXJ, tax conditions JR1, JR2, JR3, JR4

Examples:

  • RVAJCA Standard - CA /With Jur.Code    \  _ tax jurisdiction values calculated internally from FTXP

  • RVAJUS Standard - USA /With Jur.Code  /
 
  • RVAXUD Standard - USA /with Jur. ext.  \ _ tax jurisdiction values calculated by external tax system (Vertex, Sabrix, Taxware, etc.)
  • RVAXUS Standard - USA /with Jur. ext.  /

Trigger condition

Trigger condition is defined in V/06.

The purpose of trigger condition is only to set the tax code. The tax value will be build by conditions JR1, JR2, JR3, JR4.

 UTXJ is the trigger condition used in US. It is calculated on item level. In external calculation (from external tax system) it has value formula 300 assigned the pricing procedure. It is triggered in function Pricing.

Trigger conditions UTXD and UTXE are used in external tax calculation. Both conditions must be used together in the pricing procedure (for technical reasons). Condition UTXD has value formula 500 and condition UTXE has value formula 501. They are triggered only by FM PRICING_COMPLETE. The RFC is called only once per document. This is called the MaxTax procedure (developed by FI), and it is supposed to be faster.

 

Tax jurisdiction conditions

Tax jurisdiction conditions JR1, JR2, JR3, JR4 must be defined both in SD and in FI.

In SD the condition JR1 does not have access sequence. The amounts of conditions come from FI.

 

Determination of the amounts in a sales document

  1. Tax jurisdiction code is copied from the ship-to party or from OBCL
  2. Tax jurisdiction conditions are included in xkomv in form XKOMV_AUFBAUEN_STEUERN
  3. The system determines the tax jurisdiction amounts
  • from FTXP (in case of internal calculation)
  • from value formula 300 or 500 (in case of external calculation)

 

Relevant source code in Pricing

Note that after XKOMV_AUFBAUEN_STEUERN (LV61AA57), the base value and condition value are not determined yet.

The amount, base value and condition value are determined in XKOMV_BEWERTEN.

Inside XKOMV_BEWERTEN, the system determines the tax jurisdiction amounts

  • from FTXP (in case of internal calculation)
  • from value formula 300 or 500 (in case of external calculation)

Internal calculation

External Calculation

  • Formula 300 (FV64A300) is executed at item level.
  • Formula 500 (FV64A500) is executed at header level (Header -> Conditions) in the MaxTax procedure.
  • The RFC is only triggered by value formula 300 or 500. The value formulas 301, 302, etc. only retrieve values from the results determined by formulas 300 and 500.

Obs.: For external tax calculation it is recommended that the rate is maintained as 100% in FTXP.

Debug:

  1. Check what is the value formula assigned to the relevant tax jurisdiction condition. For example, tax jurisdiction condition XR1 is assigned to value formula 301 (FV64A301) in the pricing procedure.
  2. Set a breakpoint in the statement “call function 'GET_TAX_RESULTS_FOR_301_306‘”
  3. Create the SD document or update the pricing with pricing type ‘G’ (which redetermines the tax conditions), for example.
  4. Check the call stack. The values returned by GET_TAX_RESULTS_FOR_301_306  are only ‘effective’ when the value formula (FV64A301 in this example) is called by form XKOMV_KWERT_ERMITTELN.

Another way to debug:

  1. SE24
  2. Class CL_XTAX_RULES_RFC, Method RFC_CALCULATE_TAXES_DOC
  3. Set a Breakpoint at ‘call function 'RFC_CALCULATE_TAXES_DOC'

If condition control (technical field KSTEU) is ‘F’ or ‘H’, the external tax system is NOT called.

Note 1043372 changes KSTEU in the base formula so that the external tax system could be called.

Releasing to Accounting

Closer look at error message FF805

Set a watchpoint where the error message is issued and check structures BSEG and BSET.

In FI, BSEG contains line items and BSET contains the tax lines. If this structure does not contain a tax line, it is either because the condition has base value zero or is completely missing in SD.

There is a note (1255945) about how to create pure tax documents but it is very, very rare. This note clears xauto in SD and forward to FI. If xauto is cleared, the FI checks are not performed.

We could also check XACCIT when AC_DOCUMENT_CREATE is called.

Relevant fields:

  • TAXIT if it is a tax line.
  • TXJCD (different per level), TXJDP (the generic), TXJLV (the level)
  • XACCCR-FWBAS contains the base value.

Obs. 1: the trigger condition is never added to XACCIT

Obs. 2: the account determination for tax conditions is performed in FI

Example of XACCIT passed to FI with Tax jurisdiction:

Export cases with Tax Jurisdiction

The standard system behavior regarding the tax jurisdiction code for export cases has been changed with the following notes:

  • 1628962 - Export with invalid tax jurisdiction
  • 1768395 - Export with invalid tax jurisdiction (1)
  • 1809374 - Export with invalid tax jurisdiction (2)
  • 1899214 - Export with invalid tax jurisdiction (3)
  • 2016058 - Export with invalid tax jurisdiction (4)
  • 2095331 - Export with invalid tax jurisdiction (5)

After all these notes are implemented (via SNOTE or delivered in Support Package), the default tax jurisdiction code from OBCL is used in all export cases (instead of the ship-to party tax jurisdiction code) as a result of the corrections.

This data is transfered to the interface for the external tax system. Within this interface it is decided that for this default tax jurisdiction code, no call to the external tax system is needed as this business would always lead to a zero percentage rate.

In case another behavior is preferred (to not use this default tax jurisdiction code for these export processes) then you could use program MV45AFZZ for the order process and program RV60AFZZ for the invoice process. Consulting Note 2016990 has an example of a modification for export cases between US and Canada. Consider SAP Notes 83020 and 381348 in this regard.

Related Content

Related SAP Notes

SAP Note 392696: R/3 Tax Interface Configuration Guide

SAP Note 1899214: Export with invalid tax jurisdiction (3)

SAP Note 419124: Export billing document with tax jurisdictions 

5 Comments

  1. Hi Kelly,

    We in our project have a requirement from client to replace vertex with internal SAP R/3 configuration as they dont want to continue with vertex because of cost and minimal business in US,Canda.

    Now while searching the config guide + development required(if any) I could not find a specific guide for

    required IMG steps and others to set 

    up internal tax jurisdiction for SD/MM/FI transactions (without using

    external tax software"

    Can you confirm me whether your wiki would cover the MM part as well for determination of tax rate using jurisdictions in US and Canada without using vertex  OR, its only the wiki is applicable for FI+SD set-up. If not - is there any doc for MM part ?

    I also have some open points if you can address:

    1.For Cost Center PO how to maintain the TAX Rate through condition record ? Initially we were thinking whether we should use material+jurisdiction code ( negative point on this is cost centre based PO wont have mat master)combination

    or,Vendor + jurisdiction code combination

     

    2.How to identify the TAX Rate as we found and also you concurred that in US the tax rate is varying with different combinations from region to region ( e.f California) -how to handle this dynamic combination for fetching tax rate.

    Also we believe for 'same' juridction code but fo rdifferent postal codes tax rates vary in US ? how do we handle(SET-UP) that in ECC

     

    3.In case of standard SAP PO defaults the plant jurisdiction code instead of vendor master jurisdiction code.We are not sure whether tax derivation should always be based on vendor jurisdiction code - if yes, then how defaulting to vendor jur code can be done ?

    a.so we are not sure if this always be vendor jurisdiction code and

    b.if yes - then how to default this , is there any user exit or, customization known ?

     

    4.As we know in ECC we would have to maintain condition record with rate for 'All' jurisdiction codes that currently present in vertex - So we are thinking is there any way to maintain in bulk / uplaod than maintaining manually one by one as this would be a tedious task.

     

    5.Should we use 'TAXUSJ' only as tax procedure in ECC for replacement of vertex or, a custom tax procedure would have to be created.

     

    6.in US teh jurisdiction codes are of 10 char but in ECC standard in TAXUSJ its 9 char ? should we use 10 char only by setting up as below:

    The main difference between the Tax Jurisdiction Code between the standard and Vertex is for Std US Tax jurisdiction code consists of 9 digits

     

    County Code(2) + State code (3) + ZIP Code (4)

     

    whereas for Vertex there is an extra digit denoting City /Town at the end i.e. 10 digits.

     

    This can be manually overridden by making it 0 .

     

    7.how will the tax rate changes update will happen after go-live? is there a way to automate ?

     

    8.manual maintenance in ECC - for initial and delta ,

    in either case is there any upload / auto-change possible ?

     

    Regards,

    Chandan Roy Choudhury

     

  2. Anonymous

    A very well written article. Great Job!

  3. Former Member

    Excellent detailed explanation,  Kelly Ynoue. Well done.

    Question: DYK whether SAP released any enhancement for Customer and material tax classification on inter-company billing? Note 10560 states no User Exit existed by then...

    "customer or material tax classification to be determined with Country of Ship-to instead of Country of Departure...modification in the programs FV45PFAP and FV45PF0M. No user exit exists here yet."... Note: 10560.

    Thank you. 

  4. Former Member

    Thanks for the useful documentation, this is exactly what people are looking for.

    Not the theoretical article, but high value technical article.

  5. Excellent article ! very helpful (smile)