"No values found" in plant (location) during SC creation

[franz_feichtenschlager]

Hello SRM colleagues,

We made a system copy of our ECC 6.0 production environment and then linked our SRM 5.0 (server 5.5) development system to the new ECC 6.0 test copy. We are running the extended classic scenario.

Old setup:

ECCDEV <==> SRMDEV

New setup:

ECCTST <==> SRMDEV

We changed the logical system names from ECCDEV to ECCTST using BDLS. We also re-sent our product categories, plants, HR data and so on.

Problem:

When I create a shopping cart and want to search for the plant I receive message 'No values found'.

I did set the extended attributes to have a default plant with storage location.

Any pointers?

Thanks,

Franz

[former_member183819]

Hi franz

hope you might maintained extended attribute locations

since sc picks plant from org data only.

check bbp_locmap has your plant data.

run bbp_check_consistency report for your user for your sc and you may get error message if you dont inherirt the plant in org data

br

muthu

[franz_feichtenschlager]

Muthu,

I maintained the attributes and extended attributes and the plants were loaded into BBP_LOCMAP.

The consistency check brings me a warning about user not being a purchaser, but that should be OK.

Any other suggestions?

Thanks,

Franz

[former_member183819]

Hi

have you done post refresh SRM activities well. what and all you do. as you aware BDLS will not help you change logical ssytem.

double check logical system in extended attribute location data i.e palnt pointing to correct backend logical system.

T-Code: BD54.

br

muthu

[former_member183819]

Hi

have done all post refresh activities in SRM well. since your bdls will not help to change logical system in org structure.

T-Code: BD54. check ext attribute - points to correct logical system or not.\

br

muthu

[franz_feichtenschlager]

Muthu,

The external attributes point to my ECCTST system and BD54 only shows my 2 clients. ECCTST and SRMDEV.

Regards,

Franz

[former_member183819]

ok. can you do one thing delete the plant in extended attribute and try to reassign . note the down the BP number of plant no before you delete.

br

muthu

[franz_feichtenschlager]

Muthu,

Did that several times.

The BP number for the plant is each time the same (obviously).

Thanks,

Franz

[former_member183819]

hi no worry franz

double check bbp_loc_map your plant name w.r.t company code and your current logical system there or not.

moreover check u r comapny code in basic data and that is amtching with plant data or not.

or are you not all view any plant in the basic data?

bbp_read_attributes - fm

in/p u r user name, org 5xxxxx, iv_attr_single =wrk

are you geting any palnt no here or not.

br

muthu

[franz_feichtenschlager]

Muthu,

I believe I got a bit closer to the issue.

The system cannot find the backend purchasing group and/or backend purchasing Org.

I'll have to check the determination of the purchasing group.

When I run BBP_OM_DETERMINE_RESP_PGRP for US FRANZ I do receive the correct PGrp.

I'll have to dig a bit more and I believe there are quite a few forum entries with regards to PGrp determination.

Thanks for your efforts and if you have some 'easy' pointers with regards to the Pgrp finding, please shout.

Franz

[former_member183819]

Hi

for eg. if you order a cart for 001 product category . there might be responsible purchase group for this product category. this one will become as default purchase group while you create a cart.

in the purchase group configuration in organisation structure.

however organisation responsibility is mandataory

product category responsibility is not mandatory.

plz check it up.\

Serguei explained here.

br

muthu

[franz_feichtenschlager]

Muthu,

The issue is solved.

Someone defined our SRM system as target system for backend documents, thus the system found always our SRM purchasing group.

Customizing: Define backend system for product categories was set:

• material groups

ECCTST (source system) = OK

SRMDEV (target system) = WRONG.

Thanks for your replies.

Franz

[former_member183819]

Great!. Thanks for the updates. it might help SDN SRM community

br

muthu