New Condition type for PO

[Former Member]

Hi,

I'm trying to summarize an issue I've raised earlier in another discussion:

We need to maintain a new condition type for a PO.

I've maintained it via tran. M/06.

I've assigned it to a Schema (via tran. M/08) with account key 'VST' (or a new one).
The value for this condition type X is entered manually in the PO itself (since it's not a fixed value, and we don't use 'materials') and is % based on net value of item.
I've assigned a value 'Y' for the new condition type X in a specific PO #A.
Now, in the MIRO stage for PO #A, the amount 'Y' is not captured anyway for the correct GL account.
What am I missing?

Actually I have two kinds of conditions: one should be registered always upon IR to a specific GL account 'G'.

The other one should be registered upon IR to the same GL account as for the main item (in our case, based on the material group).

How can it be configured?

Thanks a lot!!.

Limor

[ajitkumar]

if you are using a Freight type condition with accruals, it may not show up in MIRO but only in MIGO.

[Former Member]

Actually, our FI team informed us that we don't use accruals.

Can we use some kind of a combination that will allow posting only upon MIRO?

[Former Member]

Hi Limor,

Evaluated Reciept  Settlement (ERS)

Prerequisite-

Evaluated receipt settlement should be flagged in the purchase order item.

The vendor must be flagged as being subject to ERS in the vendor master record.

The goods receipt must refer to a purchase order.

Goods-receipt-based Invoice Verification must be defined for the purchase order item.

A tax code should have maintained in the purchase order item properly.

Regards,

Sanjeet Kumar

[Former Member]

Thanks Sanjeet.

How does the ERS exactly solves the situation I've described provided that we have numerous tax codes, each one registered to a different GL account upon IR?

[tejyadav]

Have you assigned G/L to this account key 'VST' in OB40

[Former Member]

Actually now I can see that maybe 'VST' is not the correct choice.

In OB40, for VST, I can specify a fixed GL acount only per Tax Code (V1, V0 etc.), that is relevant only for VAT. isn't it? This is the Tax Code that is chosen in the PO, in the "Invoice" tax, right?

What if I have a condition type that is not Tax code related?

[tejyadav]

I think since you are using T-code M/06 & M/08 for this settings, You should use proper Account key for Prizing & Maintain the G/L in OBYC,

Account Key 'VST' is used for Tax Procedures in OBYZ

[Former Member]

Thanks Tej

Sure, OBYC...

Now, how do you suggest to implement the 2 ways in OBYC:

1. A fixed GL account for tax code T1.

2. A variable tax code T2 based on the mat. group in the PO itam.

Thanks a lot in advance.

[BijayKumarBarik]

Hi,

Why you are creating new condition type and what is real business requirements?

1st decide where you want new condition type? In MM pricing procedure(M/08) or Tax procedure(OBYZ)

If new condition type is in MM pricing procedure,then you need to assign your account key to G/L account in OBYc t.code.If new condition type is in TAX procedure,then you need to assign your account key to G/L account in OB40 t.code.

Again you are saying about capturing tax in two tax codes, then use   program RFUMSV50 for

deferred tax code concept where you have two tax codes, check link for details:

http://scn.sap.com/thread/1910027

Regards,

Biju K

[Former Member]

Thanks a lot Biju and Ajit.

Biju, I've read the thread you've attached but still confused

I will try to elaborate:

The implementation has to take place for company codes in India according to the complicated tax system.

In the PO, the buyer should choose, say 3 tax codes: VAT, Service tax and Education tax.

For each tax code there is a % which is not a fixed one but determined manually by the buyer.

The PO item condition should be something like this:

Net price              1000 $

ZVAT    20 % >>> 200 $

ZSER    10% >>>  100 $

ZEDU      5% >>>   50  $

Now, the requirement is to have the correct amounts registered only upon IR to different GL accounts, depending on the tax code.

For example:

GL VENDOR - 1350 $

GR/IR account    1000 $

GR/IR account   200 $  (same account as for item)

Service tax account   100 $

Education account       50$

Is it possible?

If so, please advice how to achieve it .

Is it possible to use existing tax codes?

How do I have the automatic postings in the IR?

Will the user be able to see the different tax codes and amounts in the IR?

Thanks so much!

[prabhu_sundararaman2]

Hi,

You are having the scenario of service tax with VAT, which is quite a normal one.

For this, you need just a single tax code; and for this tax code, you have to maintain dummy condition records in fv11. I presume you are using TAXINN procedure. what is the need for 3 different tax codes?

When you maintain the condition type settings properly, you should be able to specify the rates in PO manually.

After posting GR, when you do IV, system will automatically take up service tax, education cess and VAT for posting, as per your a/c determination settings.

Regards

Prabhu         

.

[Former Member]

Thanks Prabhu         .

The need for 3 tax codes (actually in India there are something like 8 diefferent tax codes) is in order to distinguish between the different GL accounts upon IR. (As I mentioned, some of the tax codes have a specific GL account and some share the same GL account as the main item).

Apart from that, the users wish to have the amounts of each tax code in the PO layout.

I will appreciate some more guideness

[Former Member]

Ragarding your queastions about TAXINN procedure: we're not implementing country version India. Can we still use this procedure?

[prabhu_sundararaman2]

Hi Limor,

Are you talking about inventorized(non-deductible) and setoff(deductible) conditions?

Inventorised conditions are posted to material(stock) account whereas setoff condition is posted to a separate G/L, as per our choice.

For eg. for some POs, service tax may have to be inventorised; for some other POs, it would be setoff.

If that is the scenario,then you need to have 2 sets of condition types as below:

Service Tax Conditions (Setoff)

JSRT    A/P Service Tax 

JEC3    A/P ECS for ST

JSEP    A/P  She cess ST

For the above, use your own account key VST ; make sure you have marked the key VST as deductible.

Service Tax Conditions (Inventorised)

JSV2 IN:Service Tx ND

JEC4 IN EduCes on Ser Tx ND

JSE2 In S&HE Cess on ser ND

For this one, use your SAP std. account key NVV.

Now, depending upon your tax sceanario (inventorised/setoff), you have to create suitable tax codes in ftxp and also appropriate tax condition records in fv11

Does that clarify your queries?

Regards

Prabhu

[prabhu_sundararaman2]

Hi,

You have not implemented CIN?

Then I wonder how one can handle the duty & tax scenarios in India?

I think you should take the help of a CIN consultant and do the necessary settings required for India.

Otherwise, things will not work.

Regards

Prabhu

[Former Member]

Dear Prabhu,

Thank you so much for your detailed answers!

As you can imagine, I'm not from India, but since we have to provide service to the Indian team I had to learn something about the Indian tax system...

Obviously I have read about the CIN, and as far as I understood, the implementation is a very complicated one that involves not only major changes in MM, but also in SD and FI, isn't it?

Since we want to limit ourselves to the MM/FI, we tried to avoid the CIN implementation.

Then, I've thought to stick to the standard schemas and condition types maintenance that SAP provides (tran. M/06 and M/08).

I thought that customizing the new condition types (as mentioned above) and allocating them to a new schema ZIN001 along with OBYC definitions will provide the wanted solution.

Maybe I was too optimistic...

Can you point me to the explanation, why the solution I have proposed is not adequate?

As far as I've checked, the new condition types do appear in PO, I can maintain the correct % and the total is obviously calcualted properly.

The problem lies 'only' within the IR stage...

Isn't there a way to treat those new condition types as, say, freight or insurance and to post them to the correct GL account upon IR?

Hope I didnt wear you out too much...

Thanks,

Limor