ESS/MSS customization

[vmadhuvarshi_]

Hello Friends,

I'm working on customization on ESS/MSS business packages and in this process I've went through many blogs, SDN posts, some Wiki pages and JDI/NWDI Cookbook in SAP Note 872892. I found that every source of information points to modifying the SAP supplied content and doing it again while importing a new Service Pack, instead of making a so called 'Z' copy as in R/3 ABAP and doing the modification in that while leaving the SAP content intact.

What is the reason for this? Is there something that I've overlooked and it is indeed possible to copy SAP supplied business content and do the modifications while leaving the originals unaltered or am I asking too much?

Please guide me.

Thanks,

Vishwas.

[Former Member]

Hi Vishwas Madhuvarshi,

Actually you can Customize directly the SAP Provided Content, but when you want that Content Back you cannot get it, to Get it Back you need to Reinstall the Business Packages, instead of that you copy the Content Provided by SAP in to your custom folder according to your Naming Conventions like 'Z', and do the modifications to this Content without losing the original Content.

I Hope This Might Have Cleared your Doubt.

Regards,

Sharma.

[vmadhuvarshi_]

Bhargava,

I understand that I can copy the content and do the modifications. I want to know why is this not standard SAP strategy as in R3. In R3 it is not advisable to modify the SAP supplied code and if need be, we go the 'Z' transaction way while leaving the SAP code intact specifically to preserve the custom code in event of upgrades. Further, there are customer-exits and BADIs available to implement customer enhancements.

Say, I rename and customize one ESS DC and the original DC is being referenced by other Dcs. How do I take care of the dependencies? Is this the reason to modify the SAP standard code?

Thanks,

Vishwas.

[Former Member]

Hi,

the reason is simple.

imagine tht u r customizing for a small organization(i mean relatively small)

and they dont want all the content provided by SAP

lets say, they dont require the travel and expenses , or they want to add their own functionality or they want some of the things or links to be removed,

in such cases we got to modify the SAP provided content

and yes, we have to take care of the dependencies.

Regards,

Satya

[Uppal]

I assume multiple reasons , since Its easier that way , to change the std. codes. than copy and modify.

-It doesn't helps , since if a new SP comes , you any way have to copy & then re-modify your z - Dc's manually ( create new track , SC etc ) and or else You'll skip the new features of the SP , may be the z - feature you added is now direct avl. from SAP.

-In case you make z Dc's you have to make z- FPM Application in & road-map FPM Views in PCD with- road-map events in self service administrator and over that change again in back end customizations with new path , service etc.

-We always have an option either restore the entire Track or your modfs. and since we keep note via Activities and in DTR of the changes.

-The DTR meta-data modifications + codes changes comparison tool dosen;t helps much , it helps being in the std.

-Referencing Dc's is another problems , as you said & may probs. comes here and manual effort to fix , and need to know where all its referenced.

-And , many personalization ( ctl- rt. click ) remains , what I saw in our case , after an upgrade to the new SP , as we do them in std. ones only.If we again think here as well a z-scenario it will be hard.

More reasons may be SAP can give us !

Thanks ,

Uppal