cancel
Showing results for 
Search instead for 
Did you mean: 

Classic PO to R/3

Former Member
0 Kudos

Hi Jay,

I have opened a new thread....

Scenario-

1. MM PR (R/3 4.7) populated manually in EPRTRANS and then pushed to SRM bidding (SRM 4.0)..

2. In SRM the classic scenario has been deployed..

3. It is creating the PO once the bid is accepted but this PO is not pushed to the backend system..

Error in BBP_PD :

Message Text Shop.. cart &1 (PO &2) :3

Argument 1 SC#

Argument 2 2000### (Backend PO)

Arguemnt 3 ME155 Req.1#### 0010 (R/3 PR)

not selectable

Could you forward me the OSS notes regarding this issue..

Regards

Manoj

Message was edited by: manoj anakapalli

Accepted Solutions (1)

Accepted Solutions (1)

Former Member
0 Kudos

Hello Manoj,

here is OSS note 674281 (46C SP47 or 470 SP18):

"You create a requirement coverage request via the enhanced order scenario in the SRM and transferred to the R/3 Backend. For this purchase requisition a value or quantity- commitment is set up. If you now try to create a purchase order from the SRM, the system displays error message ME155: 'Requisition & & not selectable'.

With that, SRM is not able to reduce the commitments generated in the Backend."

What is your R/3 release ?

It seams that you activated commitments for PR in R/3. So when SRM sends the PO, it can not reduce this commitment.

Apply this note to correct this R/3 bug.

Rgds

Christophe

Former Member
0 Kudos

Hi Christopher,

Thank you for your reply...

i went thru the OSS note 674821 and our R3 version is 470

and looks like we are already on SP 21 and the note has been applied. but we are still getting these errors..

So on the R3 side what are these commitments and how do we deactivate them...

or is there any other way to work around this problem..

Regards

Manoj

Former Member
0 Kudos

Manoj,

If your R/3 SP level is ok, then the commitment is not the reason for you.

You should debug the process in SRM:

- break point in META_PO_CREATE.

- Go into last call in SRM, just when it calls BAPI_PO_CREATE1 with R/3 470 RFC destination,

- change the RFC destination with another one using a dialog user

- continue the debug in R/3

- set a break point at instruction "message"

- wait for ME 155 (could be called in ME_CREATE_PO_ITEM after PERFORM set_schedule_data(sapmm06e) USING eket)

Rgds

Christophe

Former Member
0 Kudos

Hi Chris,

Tryin to debug from the WEB browser..

the last call in SRM was 'META_BAPI_DISPATCH' (( WANT TO MAKE SURE IF THIS IS THE RIGHT ONE))))

in this we can see it calling the Logical System ((IS THIS WHERE you want us to change the RFC destination with another one using a dialog user)))

And if followed till that point can we debug R3 from the web browser itself...

Please Confirm

Regards

Manoj

Former Member
0 Kudos

Manoj,

You are not so far.

META_BAPI_DISPATCH will retrieve the FM used to create a PO in your R/3 470. Then go deaper.

Then this dynamic FM name is called.

And later in this FM, there is an RFC call to R/3.

Change the RFC destination at this moment.

If this RFC destination is using a dialog user, you should swith to R/3 in a transparent way.

For the web brower, try it.

Don't be affraid...

Rgds

Christophe

yann_bouillut
Active Contributor
0 Kudos

-

Message was edited by: Yann Bouillut

Former Member
0 Kudos

Hi,

We are using the Classic scenario to create a backend PO.. i.e once we accept the bid it should automatically create a PO in the R3 system...

I am aware that

In the extended classic scenario, you can transfer PR from R/3 to your SRM via RFCs, do the sourcing (Bidding in our case)in SRM, create a local SRM PO and transfer this PO to your R/3 with an RFC - BAPI call. (BAPI_PO_CREATE1)

Is this similar when we are using the Classic scenario also..

Regards

Manoj

Former Member
0 Kudos

Hi Manoj,

At the real end here are the main differences between classic & ECS in your sourcing scenario via Bidding Engine:

- you have an "intermediate" local PO in SRM, which is the master PO against slave R/3 PO

- you are using BE so you don't really use SOS determination in SOCO, otherwise the SOS are searched locally and not in R/3.

Rgds

Christophe

Former Member
0 Kudos

Hi Chris,

We actually sovled the problem...

this was more a config issue..

The PR doc type was not attached to the PO doc type and for that reason the PR coming in from the R/3 system is not going out as the particular PO doctype as these PO and PR doctypes are not commited..

Thanks

Manoj A.

Answers (2)

Answers (2)

yann_bouillut
Active Contributor
0 Kudos

Hi Manoj,

Is note 799253 relevant for your case ?

Regards,

Yann

Former Member
0 Kudos

Yann,

note 799253 solves problem for sending R/3 PR to SRM (which is working in this case),

not sending PO back to R/3.

Rgds

Christophe

yann_bouillut
Active Contributor
0 Kudos

Salut Christophe

Yes you right...

Yann

Former Member
0 Kudos

Hi Manoj

Do check up in Tx. RZ20 (CCMS monitor) for the error message, why this PO is not transferred to R/3.

Regards

Vangala Reddy

Former Member
0 Kudos

Hi Vangala,

i checked for the PO error messages..

It says its the backend application error..

so how can i resovle this issue..

Regards

Manoj

Message was edited by: manoj anakapalli