Requirement routine in pricing

[Former Member]

Hi all,

I have a below requirement in pricing

Only if order reason = XXX in the sales order header, certains tax condition types should be determined in the pricing condition - sales order.If order reason = YYY, then those tax condition types should not come in the pricing condition - sales order

How to achieve this? creating new routine and assigning as a requirement in pricing procedure will work? after what are the other ways to achive this

Regards

Mano

[Former Member]

Hi all,

The requirement is not to bring a new tax condition type in the order.The requirement is to put some conditions and if that condition is met,certain tax condition types(existing) should not be determined in the order

Regards

Mano

[Lakshmipathi]

How system should behave in case of Ship To differs at line item level in which case, obviously, the tax structure should be different.  Though already members have indicated, I would also stress that this is not a Best Practice. 

G. Lakshmipathi

[former_member182378]

Mano,

Is your customer currently already paying this tax? In other words, is the order entry staff inputting a tax condition type with value in the SAP orders that qualify for this tax?

And now they want this automated (with the help of pricing condition technique)

TW

[VeselinaPeykova]

Completely agree with Jelena, charging taxes is a serious matter, so before you consider implementing such changes, I believe you need to perform more research, gather client's requirements and involve your FICO colleagues in the whole discussion.

What you describe looks a bit like a legal requirement.

Did you discuss with the legal consultant how these special taxes should be treated according to the local legislation, how postings should look like, what reports your client should present to the authorities, how these taxes should be shown on the documents given to the end customer? Is this only valid for standard OTC scenario? What about direct FI postings? What about CR/DR, invoice corrections, what about purchasing process?

Have you checked if there is a localization package available for this country, are there SAP partner addons covering this functionality? If there are such, you will not need to reinvent the wheel again.

[former_member182378]

Veselina,

You have touched upon some interested points, and tried to tackle this in a holistic approach.

legal consultant how these special taxes should be treated according to the local legislation,

What do you mean by "how these should be treated"?

Added - sometimes, in an offshore model, the customer, Finance department, is instructed by the law of the land about the criteria (for an order reason, you need to pay tax), this is then this comes to the analyst. So, there might not be a lot of business background supplied to the analyst, but change is valid (validated) and needs to be done, in the tax structure. So about idea of changing tax...this becomes (out of his/her control) redundant.

TW

Message was edited by: TW Typewriter

[VeselinaPeykova]

These tax conditions look a bit special to me.

How they should be shown in the annual report, which every company submits to the government?

Do they need to submit a separate report for these taxes? If yes - in what format, how often?

Where these taxes should be posted (accounts)?

How these special tax conditions should be printed on the customer documents (I assume that the percentages are different, maybe a reason code needs to be printed why tax deviates from the standard one)? In some countries you have a predefined layout for invoices, approved by the government, and you cannot deviate much from it, so this could be already explained in details in the law itself.

[Former Member]

Hi Mangalagi ,

Any reasons why you are using order reason to trigger your Tax , generally we do this with Tax classification of customer and Tax classification in material master .

     I agree with Sumit , there is no need to create Routine rather add Order reason in your pricing table . But I  will look forward to understand the business scenario , as its difficult to control tax from Order reason. We would also like to know why this can not be achieved by Tax classification of customer and Tax classification of Material.

.

[Jelena]

For taxes it seems very, very wrong to use something custom like that. If it was some custom discount / surcharge then sure, but taxes - not a good idea. This could easily turn into a legal compliance issue for both seller and customer.

[former_member184771]

Hi Mangalagi,

Why you are thinking of routine? It can be be done simply by adding a new key combination in you condition table i.e. order reason and the same was available in standard pricing field catalog too.

For that you need to create a new condition table with key: order reason along with all required key combination with business in V/03.

Assign the same to relevant access sequence (i.e. V/07) and finally to you required tax condition type (i.e. V/06).

Now Maintain the Pricing condition record with required order reason along with other keys combination.

Example: VAT - condition Type: ZVAT should come when order reason is A

And CST - condition Type: ZCST should come when order reason is B

Now maintain VK11

ZVAT - Maintain Order Reason : A + sales org 1000 = 5%

ZCST - Maintain Order Reason : B + sales org 1000 = 14.5%

Now in VA01 when you put order reason A & B respective condition type will come along with the values.

Hope this will solve you issue.

Many Thanks.

Sumeet Sah

[former_member233130]

Hello,

If those tax conditions exist in your PP,you can achieve this by a routine as you asked.You can find header and item order reasons in "komp-komk" structures.

Hope helps.