Tax Jurisdiction

Download as pdf or txt
Download as pdf or txt
You are on page 1of 13

Tax jurisdiction

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

You might also like

pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy