# Reverse calculation of tax using calculation type ‘H’.

We have come across a scenario for Retail POS industries where client deal only with MRP. The MRP is always with included GST tax.

We know how pricing procedure does work. It requires a base price and then tax will be calculated on the base price. As example, if base price is 2000 and tax is 28 %, then total amount will be {2000 + (2000*28%)} = 2560.

We have come across a requirement where users only want to enter the net value which is including tax amount and system has to calculate the tax amount and base amount separately. As example, user will only enter 2560. Now system will calculate 2000 as base price and 560 is tax amount. System will post the 2000 amount for revenue account and 560 for tax account.

The scenario is applicable for those industries, where user does not know the amount of base price and tax. They only enter the Maximum Retail Price (MRP) and tax percentage. Their expectation is like our smart SAP system will bring base amount and tax amount by itself. So, the basic requirement of the user is they only want to maintain condition record for the net amount and tax percentage. We have seen lot of customers are doing this by using a routine in pricing procedure, they write their code to do the calculation and modify the base amount according to the entered net amount and tax percentage.

As it is observed that this method is kind about reverse calculation. So normal pricing procedure steps will not work for the same. Here, let’s introduce a facility from SAP, where you can get the scenario without using any routine and any coding. Just a few changes in pricing procedure, can give the reverse calculation.

Before starting the changes, please view the blog post to understand how standard pricing procedure does work https://blogs.sap.com/2013/11/27/pricing-procedure-details-and-steps-in-sap-mm/

Changes in condition type for Tax. It is required to change the Calculation type for the tax condition type as ‘H’. Probably it is A in existing system. This calculation type ‘H’ allows system to do the reverse calculation of tax. Keep all other information same as it is.

Use access sequence as per your requirement for this above condition type.

Introduce a new condition type which would be reverse condition type of the tax condition type. This condition type is required to decrease the value of tax amount from the net amount. This condition type will carry exactly the same negative amount which is carried by above tax condition amount. The attributes of the condition type will be below:

Do not forget to mark this condition type as negative amount. It is recommended to use a simple access sequence (example only sales organization or sales organization/distribution channel) to maintain condition record for this condition type, as we just need to make the condition value as same as the tax condition value.

Introduce another new condition type as MRP price. This condition will be entered as net amount. With regards to this condition type, system will calculate the reverse calculation. The attribute of the condition type will be below:

Use access sequence as per your requirement for this above condition type to maintain the MRP (Net price including tax) for a particular material code.

Introduce another new condition type as base price. Value of this condition type will be calculated by system. So, it is just required to maintain the 100% as condition value in condition record for this condition type:

Please note: These all above condition types are just for example. If it is required to maintain some different attribute for any of above condition type, it is allowed to change the same.

Now include all these condition type in pricing procedure as below:

Please note these below inputs in pricing procedure (your steps can be different than displayed in the above screenshot):

1. The condition type for MRP always must be in top and mark this condition type statistical as this value will not affect your G/L account.
2. The main tax condition type (Calculation type is ‘H’) will be calculated always on the MRP condition value. You can mark this condition type as required based on your requirement. A correct account key will be assigned to fetch the correct Tax G/L account. Do not mark this condition type as statistical as this condition value will be hitting a Tax G/L account.
3. The reverse tax condition type will be always calculated on main tax condition value. The condition record of this condition type will be always as 100% of JOIG condition. Mark this condition type as statistical as this condition value will not be hitting any G/L account.
4. Then at last, insert the base price condition type (RR00) which is sum of the reverse tax value and the MRP value. Do not mark this condition type as statistical and assign an account key to determine the revenue account.

It is not required to explain rest other steps whereas all rest steps are same in general.

Now proceed to create a condition record for all these four condition types (ZMRP, JOIG, ZRMW and RR00).

Create condition record for ZMRP condition type as MRP:

Create condition record for JOIG condition type as tax:

Create condition record for ZRMW condition type as reverse of tax amount, so maintain it as 100 %:

Create condition record for RR00 condition type as 100 %, it will be calculated by system:

Now we are set. We just need to move on to create a sales order. Go to item condition tab:

Here is the result as expected and as explained in requirement. I think I do not need to explain the logic again :).

This is how the calculation type ‘H’ works for a certain scenario. Comments and suggestions are welcome.

### Assigned Tags

You must be Logged on to comment or reply to a post.

Hi Dibyendu,

Kindly let us know, how this can be achieved in manufacturing industries.

Thanks

Daman

Thanks Dibyendu for this post. it is really helpful.

Have you seen this same pricing functionality but having more than one tax? In Argentina, sales orders have VAT and perceptions as independent taxes. If I assign calc.type H to all of them, I assume they will not consider each  other to sum up 2560. Then, final value would be higher.

Regards,

Daniela

Hi Dibyendu

It's really a nice doc.

Thank you, Dibyendu.

It was very useful.

Excellent blog..!.. Dibyendu

Excellent....! Dibyendu..

Useful blog....