Skip to Content

Self-Service Procurement in SAP ECC 6.0 (ME21n) instead of SRM

Jul 12, 2017 at 03:19 PM


avatar image

Has anyone implemented the Self-Service Procurement functionalities in ECC 6.0 instead of SRM? We would like to implement this functionality because moving into S/4 Hana is not yet relevant for us (I believe S/4 Hana has this functionality built-in).

I am sandboxing this so that we would use ME21n transaction. ME21n is modified with Screen Personas and complemented by approval workflow/Fiori Approve PO app. The UI would look something like this:

So far I've come across with a few questions that I would be grateful to receive any help with. The actual question is marked in bold to make it easier to read:

1. How to add user's Cost Center and other account assignment data like in SRM? As we are procuring only from catalogs without material numbers, we do not populate any material master data. This makes account assignment a little bit more complicated. What would be a smart way to build default values for account assignment when using multiple catalogs with different Material Groups? Especially we would like to have user's Cost Center defaulted into the PO and link it to affect how G/L Account is populated. G/L Account can be defaulted per Material Group but we would also like to have Cost Center info populated somehow.

2. How to build Buy on Behalf functionality in ME21n? In SRM there is a Buy on Behalf functionality. What would be a good way to build similar functionality in ECC so that items would be delivered to a different person than the one who created the PO?

3. How to allow purchasing only from one vendor catalog? In ME21n there can be only one vendor per PO. Javascript can be used in Screen Personas to make sure that the user buys only from one vendor's catalog, but is there a better solution?

4. What are the relevant parameters for OCI catalogs in ECC? Many of the parameters used in SRM are obsolete in ECC. Many catalogs work out of the box with same parameter values as in SRM but it would be helpful to understand which parameters actually are being used in ECC.

Furthermore: is there a good way to catch the HTML code that is being returned into the system from the vendor catalog? I think many vendor catalogs use a redirect without any delay when returning catalog items and it is almost impossible to view the HTML source by mouse clicking manually. There must be some tool that allows you to catch the HTML source for previous pages? Edit: I was able to solve this by disabling javascript in Firefox browser right before catalog return.

With smiles and Sunshine,

Matti Hokkanen

fprnq.png (11.7 kB)
10 |10000 characters needed characters left characters exceeded
* Please Login or Register to Answer, Follow or Comment.

1 Answer

Ram Burugu Jul 19, 2017 at 02:22 AM

Matti, your question cuts across several skill sets- MM, SRM, Javascript etc. I will attempt in whatever way I can contribute and hope other community members can comment on other topics.

My first question is, have you explored developing a Fiori App for this purpose, you can get have more control on designing your UI. For instance, you can adapt the UI from Sales Order Create Fiori App and replace the backend services with Purchase Order create OData services, you will have a nice shopping cart experience.

1) Cost Center and Account Assignment:

You can get the cost center for the user from their HR profile and display it on the UI for user's information.

Account Assignments - Is there a scenario where your users should be given an option to edit the default account assignment? If not, you can have the account assignment determined in the background, this way you have one less thing to worry about the UI for account assignments,

Coming to how to determine the G/L, I am not sure if there is a standard config exists, but if it doesn't exist, you can take a classic xref approach(SM30) or BPRF+ which gives you more flexibility and easy to use UI to maintain the mapping.

2) The field that captures the actual buyer is the "requestor", you can use that field to capture the original Buyer. I am not sure if you want to drive the Delivery address or also some Reporting; if reporting consider that this field is a free form attribute unlike "created by" which is validated against user-id. You can get the Delivery address from HR info types or ReFX.

3) Restricting the Vendor, several options - you can implement a search-help user-exits, default the vendor and change screen attribute to display only from a user-exit etc. There are really several options. If you are doing a Fiori App, you can do it more gracefully.

4) Are there any standards these vendor portals follow such as punch-outs, cXML etc? I am guessing you need to expose a HTTP endpoint on your system for the vendor to call, in this case you create a ODATA service or build your custom HTTP handler in SICF. ODATA could be too restrictive to accept the vendor response, your custom handler could be a good way.

Show 1 Share
10 |10000 characters needed characters left characters exceeded

Thank you for your invaluable answer Ram! Indeed these questions cut through several skill sets, yet you managed to provide valuable input for all of them! I had not considered Fiori as a UI for this but it makes perfect sense. We do not have much Fiori developer experience in house but will definitely look into this with a developer. Will have to look into how the catalog call and return will work with Fiori. Although we can easily live with the Screen Personas UI also. I will summarize the most likely solutions I will use for these issues based on how I understood your suggestions:

1. As there probably is no standard solution, we will get the Cost Center from table: PA0001-KOSTL and create a z-table in SM30 or BRFPlus for account pairing&assignment. We have implemented a similar z-table for SRM before. Yes, we do need to enable users to change this default value and cannot only do it in the background processing.

2. For a Buy on Behalf functionality I think we will just go with header text fields. We can live with the delivery address behind a plant, which the user can change. So the actual goods receiver can be marked in a header text in our case. The field EKPO-AFNAM (Requisitioner) seems to be a plain text field with no functionality behind. So we would need to program all the functionality from user selection into changing the delivery address & goods receiver info for printouts & messages. I think we can live with the header text solution for this unless the requisitioner field has some functionality behind that is not enabled in our system.

3. Yes we will use abap code for restricting the vendor in search help user exit. We will also need to modify how the data is returned to PO from catalogs in function module: WSI_IMPORT_DATA. I think it might be wiser to import also Purch. Org., Purch Group and Company Code data from this FM instead of defaulting them behind user profile.

4. I was able to solve the problem about catalog return data. With Firefox developer tools you can catch&modify the return values by disabling javascript right before returning from the catalog. I can also have a look at how and which parameter values are used in OCI calls from fm WSI_IMPORT_DATA. If someone has information about the parameters used by ECC in SPRO > Materials Management > Purchasing > Environment Data > Web Services: ID and Description, it would be great if these could be shared. For SRM these parameters are well documented but I have not found out any documentation about which parameters are used by ECC and how.

Thanks once again for your input! I will wait for a little while for other possible solutions before accepting your answer as the correct one! I think quite many companies are interested in similar catalog solutions and it's good to have some documented ideas for future use!