Tax jurisdiction code determination in PO

You activate the tax handling with tax jurisdiction codes in FI Customizing (transaction OBCO).

In the standard system during the creation of a purchase order, the system consideres the following sources for the tax jurisdiction code: Reference item, request for quotation, contract, plant, the account assignment object. During this process, the system overwrites the respective preceding value in this list. If, for example, you have maintained a tax jurisdiction code with the account assignment object for a purchase order item, this entry “wins” as opposed to the entry in the plant table. Besides this, the tax jurisdiction code can be entered manually.

If you use the function from Note 493515, also the tax jurisdiction code from the delivery address can be taken into account.

Tax Code Determination in PO

In the standard system, the system consideres the following sources for the tax code (in this sequence):

  • Reference item,
  • Contract,
  • RFQ,
  • Info record.
  • It can also be entered manually.

Furthermore, the tax code can be automatically determined via the condition technique.For the determination of the tax code via the condition technique, condition type NAVS with assigned access sequence 003 is available in the standard system. Please note that NAVS condition type is available in Purchasing–>Conditions–>Define Price Determination Process–>Define Condition Types in MM configuration and is not in FI node of configurations where you configure tax procedure.

If required, you can create a diffrent condition table and and an access sequence and link them before assigning it to the condition NAVS. With Transactions MEK1/MEK2, depending on tax indicators (material, plant, account assignment, origin) you can define different tax codes in the condition tables.

In principle, you can assign this access sequence also to other condition types. The tax code is only transferred to the purchase order if the condition type is of class ‘D’ (taxes). If there are several condition types of this class in the condition schema, then the first condition schema which contains a tax code has priority.

In one of my scenario, the tax code of the destination country was applicable. Standard SAP takes the destination country from the plant which is logical. But in this case user was manually changing the delivery address to another country and  the system in such cases fails to determine the tax code. So a routine was created in VOFM in Requirements –>Pricing with the following codes and maintained it in the access sequence. The Code was capturing the event of manual Delivery Address Change while creating the PO and then  replacing the system determined country code by the country code in the changed delivery address.

form kobed_901.

  DATA : lv_var1 TYPE char50 VALUE ‘(SAPLMMDA)ADDR1_DATA-COUNTRY’.
 FIELD-SYMBOLS : <fs1> TYPE any.
*
 ASSIGN (lv_var1) to <fs1>.
 if <fs1> is ASSIGNED and
    not <fs1> is INITIAL.
 komk-land1 = <fs1>.
 endif.
 sy-subrc = 0.

endform.
* Prestep
form kobev_901.
 sy-subrc = 4.
 check: komk-kunnr ne komk-knrze.
 sy-subrc = 0.
endform.

In case of any issues in automatic tax determination, please refer to OSS Notes 21040, 566002 and 531835.

Relevant SAP help can be reffered at: http://help.sap.com/saphelp_46c/helpdata/en/e0/5f3275e24bd111950d0060b03c6b76/content.htm

Plants abroad and tax jurisdiction code

The plants abroad solution was only developed for countries WITHOUT tax jurisdiction codes. The setting for plants abroad is carried out at client level and is consequently also active for countries with TXJCD.As a result, terminations, error messages and inconsistencies may occur on the database.

In the standard system, you cannot combine countries with tax jurisdiction code and plants abroad in one client in releases prior to Release 4.7. For special developments in earlier relesaes refer to Note 332499.

The Plants Abroad functionality was designed for small producing plants in European Union. From a technical point of view it is possible to make it work for Non-European countries too.

Plants Abroad in a mixed landscape of Tax Jurisdiction Codes and VAT is not supported. Reason for that is that the tax handling under Tax Jurisdiction Codes is completely different than the handling under VAT.

Normally we have different legal systems and different legal requirements in Non-European countries. Thus, from a legal point of view, the best solution is to use different company codes instead of Plants Abroad.
You can refer to note 51361 in this regard.

User Exits for Release Strategy in SAP MM

During the individual release for purchase requisitions, the user exit is called in function module ME_REL_STRATEGIE_EBAN, in the overall release, it is called in function module ME_REL_GENERAL_STRATEGY_EBAN.
(Enhancement M06B0002, EXIT_SAPLEBND_001, ZXM06U13)

During the release for purchase orders the user exit in function module ME_REL_STRATEGIE_EKKO is called, in releases > 3.1X in program MM06EF0S_STRATEGIE_CEKKO (Enhancement M06E0004, EXIT_SAPLEBND_002, ZXM06U22).
The data is available in the user exit in structure I_CEBAN or I_CEKKO. The transfer from this structure to the calling program runs using structure E_CEBAN or E_CEKKO. In the user exit, I_CEBAN must be copied to E_CEBAN or I_CEKKO must be copied to E_CEKKO anywhere in the user exit, for example E_CEBAN = I_CEBAN.

Report RCCLZUOB for testing classification object consistency.

The program checks whether all allocations of the selected class type have a master data object.

E.g.: class type 001.    Are there classifications for a material, that does no longer exist in table MARA ?

Note:

1. The program is executed in test mode, if selection parameter DELETE = space.
2. Missing objects are displayed.
3. If there are unnecessary classifications, these records are deleted in the database tables INOB, KSSK, AUSP.
4. Depending on the number of classified objects, the program may have a long runtime !

Deletion of Release Strategies in SAP MM

In tables T16FK, T16FV, T16FS, T16FC and T16FG, there may be entries from previous Customizing settings (for example, old release groups) that were indeed deleted from Customizing, but not deleted from the tables.

This creates an inconsistency.

To eliminate the inconsistency, proceed as follows:
Make all the deleted release settings in Customizing again, save them, and then delete them in the following sequence:

1. Delete the release strategies
2. Delete the release indicators
3. Delete the release codes
4. Delete the release group
5. Delete the class (Transaction CL02), if a new one was created for the new release strategy.

Then use transaction SE16 to check whether the entries in the tables mentioned above were deleted.
Execute the report in Customizing (transaction OMGQCK or OMGSCK) and ensure that the system does not display any red traffic lights.

Also refer to Note 350703.

You can use report RCCLZUOB to check the consistency.

Overall Release strategy does not trigger sometimes

You can simulate yourself whether the release strategy will get determined or not in transaction CL30 by inputting the values you have used in your purchasing document.

If you use item fields such as Plant, Material Group, etc. in the overall release strategy, the fields will be aggregated to header level for the purpose of release strategy determination.

For example, supposed you have used Plant as one of your characteristics. If all items do not belong to the same plant then the relase strategy will not be found unless you have maintained a blank value as one of your allowed values for the characteristic Plant. If all items belong to the same plant then that plant is aggregated to the header; if one or more is different then a blank is aggregated to the header.  Similarly If, for example, item 10 of a purchase requisition contains material group 001 and item 20 contains material group 002, the material group is set to BLANK for the strategy determination. See note 47089.

This becomes a challenge particularly if different strategies are there for different requirements and for each strategies you are using overall release strategy for example.You have to use the same set of characteristics for each strategies. If for one particular strategy, plant is not a required release criteria then you have to maintain a blank as mentioned earlier in this post.

If you are maintaining a blank characteristic and still release strategy is not getting determined, please go through the SAP Note 754178 – Release strategy not found for blank characterisitic and apply if required.

Taxes on sales/purchases – Plants abroad

For Plants Abroad functionality please Keep the following in mind for tax calculation schemas:

The company code can only work with the tax calculation schema assigned to the country of the company code.Using more than one tax calculation schemas within one company code is not possible at this time.

Modification solution “Plants abroad” allows you to assign plants from different countries to one company code.
This results in additional requirements for the character of the tax calculation schema for this company code as well as the character of the tax calculation schema for the countries of those plants assigned to this company code.

If A is the country of company code X that plants in countries B, C,D… are assigned to, either of the situations below is possible:

Alternative 1

– One tax schema TAXEUR for countries A, B, C, D, ….
– You define a general tax schema TAXEUR that includes tax specifics for countries A, B, C, D, …
– You must define all tax codes (with country assignment) required in these countries.

Alternative 2

– Different tax schemas for countries A, B, C, D, …
– Example:
– Country A -> Tax schema TAXA
– Country B -> Tax schema TAXB

– All tax codes for country A are defined in tax schema TAXA.
– In tax schema TAXA, all tax codes are defined for those countries required for acquisitions or deliveries to plants abroad assigned to company code X (with country assignment).
– When K3 is a tax code for country B that is required in a plant assigned to company code A:
Tax code K3 is defined in tax schema TAXB.
Tax code K3 must also be defined in tax schema TAXA (with country assignment country B), but the definition of tax code K3 must be the same in tax schema TAXA as it is in tax schema TAXB.

Recommendation

– SAP advises giving your tax schema the character outlined in Alternative 1.

Background information:

– For a shipment from Plant So the advice was to best detox drink it during detox only. B in country B, SD finds tax code s of the tax schema assigned to country B.
– Tax code s is transferred from the SD to the FI application.
– The FI application interprets tax code s with the tax schema assigned to country A of company code A.
– It must be ensured that the following is true for countries A and B when using different tax schemas:

   When s is a tax code used in plant B,
– Definition of tax code s in tax schema TAXA
= Definition of tax code s in tax schema TAXB

Changes to the interface

The possible entries pushbutton allows you to restrict the tax country.

The system checks during document entry whether the tax country is unique in the document. Only the following exceptions are permitted:

For incoming payments with tax adjustment for cash discounts, more than one tax country is allowed, but only one for each automatically generated cash discount item.
Plant stock transfers from SD across national borders are permitted because a cash discount adjustment is not necessary (simple G/L account postings).
The following programs were enhanced with a selection option for tax country (this field is only visible if “Plants abroad” is active):
RFUMSV00
RFASLM00
RFASLD11
RFASLD12
RFWERE00
RFUSVB10

The program for sales/purchases tax returns (RFUMSV00) was enhanced with the option of displaying or printing values in reporting currency (country currency) instead of local currency.

Further notes

Further information is available in “FI General Topics.”

The following release notes describe “Plants abroad” for SD/MM – Declarations to the authorities in the EU – plants abroad:

MM : MMM_PUR_40A_WIA

Intra-EU trade statistics: 40A_FT_GOV_WIA

SD: SD_40_WIA

Plants Abroad functionality in SAP

In releases prior to 4.0A, All plants assigned to a company code must be assigned to the same country, the country of the company code.’Correct taxation procedures and INTRASTAT processing can only be carried out if this requirement is fulfilled. For each company code, the taxation procedure for exactly one country is supported, the country of the company code. The same applies to trade statistics processing.

As of Release 4.0A, ‘Plants abroad’ are supported in SAP.

You can find this function under the menu path Financial Accounting -> Global Settings -> Financial Accounting -> Tax on Sales/Purchases -> Basic Settings -> Plants Abroad

Here you need to activate plants Abroad and maintain VAT registration number for plants abroad.

This functionality affects the FI, MM, and SD application components. You can use Plants Abroad to handle tax issues for companies that have VAT registration numbers in more than one country for example a Belgian company code has not only a Belgian VAT registration number but also a German VAT registration number without having a company code in Germany but a warehouse (i.e a plant) instead. Plants Abroad ensures that the correct value-added tax (VAT) registration number prints on sales and purchasing documents, calculates the right tax, handles stock transfers, and conducts tax and Intrastat reporting correctly. The plants abroad functionality allows you to assign plants from different countries to one company code.

Having a foreign VAT number has also consequences like if a company has a foreign VAT number then it also needs to file VAT return/European Sales Listings/Intrastat returns in that specific country. In order to achieve this, in SAP appropriate customizing is needed.

You can create tax codes in FTXP, where you need to complete the field “reporting country” in the properties of the new tax code. This means that you can use this tax code for the new VAT registration number/new reporting country.

You can assign this tax code to 2 different tax procedures: namely the local tax procedure or TAXEUR. More information can be found on OSS notes:

  • Oss note 63103: Explains logic regarding tax procedures if you are using plants abroad
  • Oss note 1085758: Customizing for stock transports
  • If you activate plants abroad then this will be activated for all company codes within one client. You can deactivate for certain company code this functionality which is of course described in the OSS note 850566: deactivate plants abroad for a particular company code
  • Another important OSS note is 850566 whic deals with F4 help for PA w/ MIRO, FB60, FB70 for comp code without PA 

INTRASTAT

For Intrastat, you need to maintain the Intrastat ID numbers. Most of the time when a company has a foreign VAT registration number in another country, it needs also to file Intrastat returns. In order to run the Intrastat returns for that specific reporting country, you need to maintain some master data relating to the company. You need to enter these data in transaction OBY6 – click on additional details. In the middle of the screen you will see the field Intrastat number ID. Please complete this field. You need to enter your VAT registration number here.

You also need to set up a new pricing procedure and condition types (WIA). Regarding this process you can find more information on SAP website.
 
The activation of plants abroad has also consequences for the VAT report (RFUMSV00 program). Here you need to enter/activate additional parameters which are the following:

  • Reporting country / tax return country
  • Country currency instead of local currency

Some useful details can also be had at: http://wiki.sdn.sap.com/wiki/display/ERPFI/Plants+Abroad

and also at: http://scn.sap.com/people/praveen.kumar109/blog/2008/12/17/eu-tax-reporting-with-plants-abroad-functionality

Deleting a condition type

Deleting a condition type is only possible in a document if it is permitted for the condition type in configuration. If you are unable to delete the condition, please ensure that the “Delete” indicator is checked in the Condition type configuration under the section “Changes which can be made”