what is the relevancy of BBPCO idoc?

[sap_2605]

Dear SAP gurus,

We're using SRM server 550 (SP08) with extended classic scenario. From the documentation I know that the PO will be created in R/3 using a BAPI which is BAPI_PO_CREATE (our backend is 4.6C). So I think if the PO is created using BAPI then the commitment will be created as per standard PO in R/3.

Then why do we still need BBPCO as an outbound idoc from SRM side to go to R/3 side? Wouldnt PO created by BAPI_PO_CREATE creating commitment as well?

Please enlight.

Best regards,

John.

[yann_bouillut]

Hi,

You don't need BBPCO

As you said, the PO is replicated into the backend . Thus commitment is created.

The BBPCo is useful for standalone scenario where no PO is created in the backend thsu no commitment without this message type.

I am also using ECs with SRM50 and ECC60.

Kind regards,

Yann

[sap_2605]

Hi Yann,

Thanks for your quick reply. I ask this question because I got a very weird situation. We are using Extended Classic with SRM server 550 (SP08) and R/3 4.6C. So if the PO is approved by the last approver it should ALWAYS replicated to backend.

However we got some cases where the PO is not replicated. And for such POs, we see that idoc BBPCO is being sent from SRM. So we notice that if the PO is going to R/3 no BBPCO sent and if it is not going to R/3 then BBPCO is sent. So if what you said is correct, thus I think SRM thought that for these PO, standalone scenario applied, so rather than transferring the PO, BBPCO is being sent. But how is it possible? We already maintained that the product category * then the backend is set to the R/3. So it should NEVER be standalone, and we dont use any BADI related to the backend definition and transfer.

Based on our observation, this kind of thing usually happen if we generate PO from the accepted bid. But this bid should come from bidding invitation created from Shopping Cart (thru Sourcing Application). Even this would not ALWAYS happen, as we copied the SC into a new SC, push it to Sourcing, create bidding invitation and then accept bid and generate PO and now it is working. So we are really blank why does it happen in the first place.

Do you have any idea?

Thanks in advance.

John.

[yann_bouillut]

Hi,

In the ECS scenario, i do no use the BBPCO in my ALE.

I would suggest you to remove the BBPCO message type from your ALE distribution.

Kind regards,

Yann

[sap_2605]

Hi Yann,

We have tried that as well, and still the problem persist, but now the BBPCO in SRM side getting an error message as no outbound profile exist. So SRM still persisten in sending the BBPCO instead of the PO.

Best regards,

John

[Former Member]

Hi

In your case, Do you want Commitment to get created or not in the R/3 system ?

<u>Instead of removing BBPCO message type from ALE Distribution, try the follwoing SAP OSS Notes -></u>

Note 786854 - Modification note in order to deactivate commitments

Note 702994 - PO: Commitment IDoc is sent too often

Note 700810 - Purchase order: Commitment is not set up

Note 396631 - Commitment is not created

Do let me know.

Regards

- Atul

[sap_2605]

Hi Atul,

We are using Extended Classic, and as what Yann said, BBPCO should not be sent. But in our case, BBPCO is sent, and the PO is not replicated to backend. Can you give me a clue on which part of configuration that we make wrong?

Note that this is not ALWAYS happen, and sometimes the same product, product/category can have the different result (sometimes it goes to backend, sometimes it is not).

Best regards,

John

[Former Member]

Dear John,

We are experiencing the same problem as you with BBPCO idoc. Have you resloved it yet? If so how did you you resolve it?

Regards

Lebo

[sap_2605]

Hi Pedzi,

We have raised this to SAP. The reason why BBPCO is being sent is that the item is not considered to be sent to backend. Thus BBPCO is being sent as SRM not expecting the PO to be replicated to backend. You can check whether your PO should go to backend or not by checking in BBP_PD. Go to your PO item and then search "subtype". If the subtype is "EP" then the PO will go to backend and BBPCO will not be generated. If it is blank then it will NOT go to backend.

In our case, there is a bug from SAP, as the PO is not having "EP" though the SC is having one. We have applied notes 1082817 and it is working fine now.

Hope this can help you....

John.