Vendor and Account Assignment Issues

[Former Member]

Hi All,

Iam Working in ECS SRM 5.0,

When We are trying to creat SC, we are getting following errors :

1.Vendor 0000100029 not intended for purch. org. (Item Sourcing Strategy & Plan Consulting )

SOS is automatically assiged to particular product ID thru Purchasing Contract (Purchasing Contract created locally).Vendor is assigned to the Purchasing Contract.Vendor is properly mapped to the respective Purchasing Organization as recored in the table BBPM_BUT_FRG0061.Purchasing Contract is also mapped to the same Purchasing Organization of Vendor.

2.Account 50011 requires an assignment to a CO object (Item Sourcing Strategy & Plan Consulting )

2.1 Error in account assignment for item 1

Account assignment Categories and G/L Acc. are properly maintained and activated in SRM for each Product Category. same values for G/L Acc. and Acc.Assignment Categories are maintained in R/3. In R/3 when we checked in the tables SKA1,SKB1 & SKAT all these entries are maintained properly.

In our project Scenario we don't require CO Component only AP Component is Configured for our Business Requirement.

Full points will be rewarded for the solution.

(sgirishkumar2000@yahoo.com)

[Former Member]

Hi

<u><b>Please go through this -></b></u>

<i><u>Please implement following SAP OSS Notes -></u></i>

<b>Note 1026168 - Vendor &1 not intended for purch. org. &2</b>

[ This is caused due to a program error. The reason for this error is, purchasing organization and purchasing group are always assigned at header level and in this case SRM is passing the item guid to determine the backend purchasing organization and purchasing.group. The header guid should be passed instead. ]

<b>Q 3: Why does the system issue message KI 235 - 'Account & requires an assignment to a CO object'?</b>

<u><b>Answer -></b></u>

<u>--> In SRM, you always have to post to a G/L account and to a CO object. Exceptions: Direct material scenario - account assignment occurs in the OLTP regardless of what was previously entered in SRM. For external requirements, the primary system is the OLTP from which the demand is issued and sent to SRM. In this case, account assignment changes are not allowed in SRM because this would lead to inconsistencies (in follow-on documents as well) when compared to the primary system.

--> In /OBA5, you can suppress the message or define it as a warning message. Since only error messages are transferred to SRM (BBP_PD 047), the message then no longer is issued in SRM. Do not consult the FI/CO team when implementing the changes.</u>

(<u><b>See related SAP Consulting Notes - Release-Independent</b></u>

<b>Note 815849 - FAQ: Account assignment system response</b>)

<u>Hope this will definitely help. Do let me know.</u>

Regards

- Atul

[Former Member]

HI Atul,

Thanks for ur reply..

For the CO Object Error Still Iam facing the same Problem.

Can u send me the Complete steps which i have to do in the SRM side and also if possible can u send the R/3 settings also.

But in my Project there is no Controlling only WBS Element is considered.

In my Scenario we r creating Account Assignment categories as service wise for each G/L Accounts.

For this iam getting the Error.

Help me out from this Issue..

Thanks

Girish

[Former Member]

Hi Atul,

First of all Thanks for ur Reply. I was awarded u the Points.

I have solved the CO object Issue.

As per ur response we have implemented the SAP Notes, but still iam getting the same error saying that "Vendor is not Intended to Purchasing Organization".

Help me out from this Issue, its an Urgent Requirement.

Thanks

Girish

[Former Member]

Hi Raju,

It seems the Purchase organization data was not mentioned when the vendor was created.

Check the details of the P.Org in "Manage Business Partners" link for that vendor.

or you can use BBPMAININT.

In Vendor Data tab the P.Org and the P.O currency needs to be maintained. Also you have to maintain the back end system and the vendor responsible in the back end system.

Also check whether the vendor concerned is maintained in the VENMAP table.

If this data is maintained then there won't be any issue.

Hope this will resolve your query. Clarifications are welcome.

Rgds,

Teja