URGENT - Unable to transfer an approved SC to R3 as a PO - PLEASE HELP

[Former Member]

Dear all,

I have created the first ever shopping cart in a new brand new client. The business process requirement is such that when a shopping cart is approved, it should be transmitted to the backend R3 system as a PO.

In config, I've set the config object "DEFINE Objects in Backend System (PURCH REQS, RESERVATIONS, PURC Orders), I have set "Always Reservation for mt type subject to Inventory Management" for int Proc and set "Purchase Order if item data is complete else Purch Req" for ext proc.

As far as I can see, my test shopping cart is complete. In "check status" the cart is approved but showing transmission errors.

When I look at the cart details using t-code BBP_PD, the messages/alert section the Message Text reads "Shopping cart &1 (Purch Requisition & 2) : &3 &4

The error message is ME217 External number assignment not defined for document type ECPO.

ECPO is the internal PO doc type in SRM and I have set has a same doc type and number range in R3 as a external doc type.

Question.

Why is the system trying to create a Requisition in the backend when in config I have set the create PO for external procurement. Is this bacause the vendor is still showing Preferred and not fixed in the shopping cart?

I vaguley remenber somebody telling me that to if a PO has to be the follow on document after cart approval, the vendor must be fixed is this right? If so, how can one fix the vendor in the cart to enable backend transmission.

Please help as I need to create a backend PO urgently.

Thanks,

[yann_bouillut · Accepted solution]

Hi Grace,

to convert prefered to fixed vendor in the SC, you have to do it in a badi.

Here is the code to converts prefered to fixed vendor.

method IF_EX_BBP_DOC_CHANGE_BADI~BBP_SC_CHANGE .

Constants : c_vendor type BBP_PDS_PARTNER-PARTNER_FCT

value '00000019',

c_preferred_vend type BBP_PDS_PARTNER-PARTNER_FCT

value '00000039'.

Data : ls_partner type BBP_PDS_PARTNER.

*Read Table it_partner into ls_partner With key PARTNER_FCT = c_vendor.

*

*If sy-subrc NE 0.

Loop at it_partner into ls_partner

where PARTNER_FCT Eq c_preferred_vend.

Move c_vendor To Ls_partner-PARTNER_FCT.

Modify it_partner from ls_partner index sy-tabix.

Endloop.

*Endif.

et_partner[] = it_partner[].

ET_ORGDATA[] = IT_ORGDATA[].

ET_ITEM[] = IT_ITEM[].

ES_HEADER = IS_HEADER.

ET_ACCOUNT[] = IT_ACCOUNT[].

*break ybo

*IT_PARTNER

*ET_PARTNER[]

endmethod.

Kind regards,

Yann

[Former Member · Accepted solution]

Hi Yann,

Which badi shoud this code be coded into?

[Former Member · Accepted solution]

Yann,

Are you also saying that the reason my shopping cart is trying to convert to a req is because the vendor is set as preferred and not fixed?

Thanks

[yann_bouillut · Accepted solution]

Hi Grace,

Badi is BBP_DOC_CHANGE_BADI.

No i am just giving you the code to convert prefered vendor to fixed vendor in SC.

Kind regards,

Yann

[yann_bouillut · Accepted solution]

Hi Grace,

What scenario are you using ? extended classic scenario or classic one ?

If classic scenario and you are using non catalog items, prefered vendor has to be converted in fixed vendor.

Here the badi code is usefull.

If extended classic scenario and non catalogue items, the prefered vendor can be converted in fixed vendor :

- automatically in SC through the badi code

- manuelly in the SRM PO : go to PO change mode and convert the preferred to fixed vendor.

The PO will then be COMPLETE and be duplivcated in R/3.

NB : in ECS scenario, define object in backend is not usefull...

However, the error message is focused on number range configuration.

You have to investigate your number range AND transation type.

Kind regards,

Yann

Message was edited by: Yann Bouillut

[Former Member · Accepted solution]

Yann,

OK, thanks.. i will implement the badi and code and try creating another SC.

Does anybody know why my cart is trying to create as a req when as far as I can see its complete apart from the vendor been set as preferrd and not fixed?

Thanks,

Grace

[yann_bouillut · Accepted solution]

Hi Grace,

Are you saying , you are using classic scenario (PO in R/3 only ) ?

If yes, prefered vendor is the cause why PO is not created and system try to create a PR.

Kind regards,

Yann

[Former Member · Accepted solution]

Yann,

ours is a classic scenario implementation, SRM 4.0, ECC 5.

Yes the message is pointing to a number range issue. This is what is confusing me, we do not need to maintain a number range for requisitions.. our processes and SRM follow-on documents config is such, that approved/completed shopping carts should automatically transfer to the backend as POs.

I have checked and verified our PO number ranges in SRM & ECC, they both check out. in SRM the number range for ECPO is 8000000000 to 8999999999 and set as internal. The number range in ECC for ECPO is also 8000000000 to 8999999999 and set to external. So i donot understand why the system should ask for a req number range.

Grace

[yann_bouillut · Accepted solution]

Hi Grace,

Prefered supplier means that your SC in INCOMPLETE.

Therefore, system cannot create R/3 PO.

Therefore, system try to create R/3 PR.

As you didn't maintain R/3 PR number rnage, you get this error message !

Kind regards,

Yann

Message was edited by: Yann Bouillut

[Former Member · Accepted solution]

Yann,

I have implemeted the badi you suggested in your previous post with the code supplied.

I am still getting the same error message in BBP_PD, pointing to a missing external requisition number range. As far as I can see, the vendor is no longer set as preferred in the shopping cart via check status.

Questions

Why is SRM still trying to create an Req in the backend when it should be creating a PO as specified in config. I thought that the ca is complete when the vendor is fixed, any ideas?

Where can I look in the system (tables) to verify that the badi implemented is cworking correctly.

Any help will be greatly appreciated, as this is an urgent requirement.

Thanks.

Grace

[yann_bouillut · Accepted solution]

Hi Grace,

To check if vendor is a preferred or not, you can look at BBP_PD, select your SC and go to item level...

If your supplier is now a fixed vendor and the system is still trying to create a PR instead of a PO, then the issue comes from another origin :

1- in define follow-on document configuration point, please confirm that you didn't enter a "*" for both purchasing group and material group else PR is created instead of a PO

2- Message 334 (enter info record) configured in R/3 prevent PO to be created and PR creation is selected.

Kind regards,

Yann

[Former Member · Accepted solution]

Yann,

I have verified our config for follow on docs and can confirm that purchasing groups are listed by number(100, 200, 300 etc etc) and material gropus have an * against under the product category column.

Yannn let me have your email address sothat I cam mail you the BBP_PD listing so that you can review it may be able to spot something odd.

Thanks,

Grace

[yann_bouillut · Accepted solution]

Hi Grace,

yannbouillut@yahoo.fr

Kind regards,

Yann

[yann_bouillut · Accepted solution]

Hi Grace,

After executing BBP_PD for your SC, go to partner section in the first page.

Partner function 039 is prefered vendor

else fixed vendor

Kind regards,

Yann

[Former Member · Accepted solution]

Yann,

I have resent this to you.

I have checked the vendor section in BBP_PD, the partner function is set to 0000019. I take it this is fixed vendor right?

Thanks,

Grace

[yann_bouillut · Accepted solution]

Hi Grace,

Yes it is

Kind regards,

Yann

[yann_bouillut · Accepted solution]

Grace,

Give me your email address as i didn't receive your mail (but i receive daily tons of emails )

Kind regards,

Yann

[yann_bouillut · Accepted solution]

Ok received

[yann_bouillut · Accepted solution]

Hi Grace,

Message ME 217 is "External number assignment not defined for document type &".

Your configuration for number range and document type is not correct !!

Below, an extract of the code where this message is used :

Prüfen externe Nummernvergabe -

-

---

*

IF IM_T161-NUMKE EQ SPACE.

MESSAGE E217 WITH IM_T161-BSART.

ENDIF.

You can check directly in table T161

Enter your ECPO in BSART field and check that your configuration is correct

Kind regards,

Yann

Message was edited by: Yann Bouillut

[Former Member · Accepted solution]

Hi Grace:

Make sure you have defined in SPRO

Define Number Ranges for Shopping Carts and Follow-on Documents ( For SC, PO, RQ)

also defined

Define Number Ranges per Backend System for Follow-on Documents (PO,RQ,RS)

Once you have done this make sure you defined RQ as the external number range for Document type ECPO in the backend. ("define document type for PR or PO's.

Also like Yann mentioned you can find out if it is a preferrd vendor or a fixed vendor from BBP_PD. 39 is preferred vendor and 19 is fixed.

Hope this helps.

Thanks

Sundeep

[Former Member · Accepted solution]

Sandeep & Yann,

I have verified my config of follow on number ranges for our one backend system plus number ranges forbackend follow-on documents. All checked out and I have aligned them in the R3 system.

I have mentioned, we DOn NOT WANT or NEED to create an external number range for REQS, because we will never be in a situation where he have an incomplete cart..all carts will be approved and completed in SRM one way or the other and thus should transfer to R3 as POs. Our config for backend objects facilitates this.

I implemnented BBP_CHANGE_DOC_BADI to fix the vendor. In bbp_pd, the vendor partner function for all my carts is 19, which means that the badi is working as intended.

I did something further to test things and prove that the cart was complete in SRM. I created the external req number range in the R3 system just to see if the req will be transfered "complete", although this is not what we really want as you know.

When I created a new text cart, set a vendor the cart was ordered and approved. The the cart was transfrerred as a req. The req itself when displayed in R3 was completed with a fixed vendor! and I was able to create a ECPO based PO (external number assignment, by adoptingthe req in the PO. So this shows that the cart was complete in SRM anyway, so a PO should have been created!.

So if anyone has any ideas on how I can transfer a completed cart to R3 as a PO, please tell me how to.

Regards,

Grace

[yann_bouillut · Accepted solution]

Hi Grace,

I guess you already check in table T160M that R/3 message 334 (class 06)did not prevent Po creation.

You can set message from E to W and test again.

Else, i think it is time to debug from SRM...

Kind regards,

Yann

[Former Member · Accepted solution]

Hi Grace,

SRM is creating PR or PO depending on:

- SRM customizing (ex: always external proc + PR if incomplete, PO if complete)

- the interpretation of SC data by R/3.

IF your SC is considered complete by SRM (but with a fixed vendor and not a preferred vendor) the system will check if it can create a PO in R/3.

For this, each item will request a META_INTERPRETE_DATA to R/3, asking if it can create a PO. If R/3 considers this data as incomplete, it will reply to create a PR.

Usual cases of R/3 PR creation instead of PO:

- prefered vendor in SRM (and not a fixed one)

- custom checks in user exits in R/3

- error messages in R/3 (ex: O6 334 In the case of a fixed vendor, please enter info record)

- ...

To debug without debuging into R/3, you can try the following:

- use BADI DETERMINE_TARGET_OBJECT and force PO creation

- so the system will always try to create a PO

- R/3 won't create the PO (for the same reason as in META_INTERPRETE_DATA), and will raise an error in SRM

- finally you get the real error in application monitor (SC --> backend application errors)

If you don't want to use the BADI DETERMINE_TARGET_OBJECT, you can let the standard, but then you must set a break point in META_INTERPRETE_DATA during SC transfer, and change the returned value to force PO creation (in item table, there is a field like OBJ_TO_GENERATE that must have value 3 or 2 for PO).

Last option: do continue the debug of META_INTERPRETE_DATA into R/3 to see why R/3 says to generate a PR and not a PO.

Rgds

Christophe

[Former Member · Accepted solution]

Christophe,

Thanks you your contribution.

We tried out all your suggestions. We have attempted to debug all the way into R3, but are having problems debugging when it calls a function at the R3 logical system.

Question

Is it possible to step into a function module in another logical system?

We have also tried and implemented note number 140846, and we are still unable to transfer our approved/completed carts to R3 as POs.

Could it be down to a PO number range issue?

I am happy to send you screen dumps of all number range related config in both SRM and R3 if you wish, maybe you will be able to spot something there.

Regards,

Grace

[Former Member · Accepted solution]

Grace,

to continue the debug in R/3 you must use a dialog user in this RFC destination.

To avoid debugging, you can try my proposal with the BADI to force SRM create a PO and bypass R/3 wills.

You can send your screen shots, but your main problem is not the nb range, but the generation of a PR instead of a PO, as you already stated.

Rgds

Christophe

[Former Member · Accepted solution]

Christophe,

You are suggetinting we implement BADI DETERMINE_TARGET_OBJECT, can you please confirm the badi name and where its to be mplemented from. We cannot find it in SRM.

Also can you please provide us theappropraite code to use for this BADI.

Thanks,

Grace

[Former Member · Accepted solution]

Path for SRM 4.0:

SPRO --> Supplier Relationship Management --> SRM Server --> Business Add-Ins (BAdIs) --> Shopping Carts and Requirement Items --> Determine Target Object in BE System.

BADI name is BBP_TARGET_OBJECTS.

Method name is DETERMINE_TARGET_OBJECTS.

You then place the ID for the target object in the field ITEM_DATA-OBJ_TO_GEN. There are the following IDs:

ID Meaning

1 Reservation

2 Purchase requisition

3 Purchase order

Rgds

Christophe

[Former Member · Accepted solution]

Hi Grace !

I know you encountered this problem in 2006, but could you tell me what solution you finally found ?

In our SRM system, we have just implemented Support Packages, and we have exactly the same problem as yours...

Thanks in advance,

Regards,

Marianne Oliva

[Former Member]

Yann,

I ahve sent you the email.

Regards,

Grace

[yann_bouillut]

Hi Grace,

I did not receive your email yet...

Can you please resend it ?

Kind regards,

Yann