Procurement from OCI catalog - Create purchase requisition advanced

[former_member690103]

Hello all,

I want to create extended procurement from an OCI catalog in Firoi Launchpad using the Create Purchase Requisition advanced app. After I pass the catalog data back to Launchpad I get error messages:

I have checked all existing notes and also checked the OCI parameters. The GUI transaction returns the catalog data cleanly, but the fiorized transaction in the Launchpad does not.

The Self-Service Procurement function should not be used in this context at the moment.

Can someone help?

Best regards,

Christian

[gebguy00]

Hi,

We have exactly the same issue for which we created a SAP incident and which is still under investigation.

The strange thing is that in our case, this error only pops-up for 1 specific vendor.

SAP proposed to check these SNotes, however these are old notes and are already on our system :

2212416 - OCI catalog unable to return to application
2555948 - Checkout from Catalog result in Internal Server Error 500

2082290 - ITS HTML Control: oci integration improvements

Guy

[former_member690103]

ello Guy,

thanks for your anaswer. If checked the notes, but the first two notes are to old for our system and the last one we chacked allredy but it doesnt help.

Best regards,

Christian

[leilane_castro]

Interesting topic. We have a very similar problem here (on ECC, using WEBGUI, and on S4, using FIORI App for Purchasing Requisition. If you folks have any news, please share with us. Thanks.

[gebguy00]

Hi, In our case, SAP debugged a punchout which is working and the one which isn't and then compared the debug results.

It turned out the issue was in the punchout configuration at the vendor's side :

"It is due to the configuration of the OCI catalog. The session to which AS ABAP instance is routed is controlled via sap-contextid.

This is missing in the header and is instead delivered in the payload of the HTTP POST. However, the payload is not evaluated by WebDispatcher(WD), only the header.

No session is found in the header, so the request is treated as a new request and routed to the server with the least load. Why we always end up with the wrong instance here is of course extremely unlucky with the load balancing strategy of the WD.

We also tested this without LB, i.e. only via the WD, in order to be able to rule out the LB as a source of error. The behavior is always the same, the context ID is always supplied in the payload instead of in the header."