[4315] in sapr3-soft
Re: Should we transition to SAP?
daemon@ATHENA.MIT.EDU (Hognoxious)
Thu Oct 21 09:45:11 1999
To: sapr3-soft@MIT.EDU
Date: 21 Oct 1999 08:41:07 -0500
From: Hognoxious <hognoxious@my-deja.com>(by way of SAP Moderator <sap-request@realtimeusa.com>)
Message-Id: <7un55j$8p@nexus.netconcepts.com>
Bit of a big and general question!
Firstly, be sure of the difference between customizing (controlling the
system by entries in special tables) enhancemnts (create your own
programs etc), modifications (changing a standard program).
There is a mantra "thou shalt not change standard SAP". This is often
repeated by those who wish to appear knowledgeable. A lot depends on
whether you are creating a new program, table etc (which is OK to do) or
actually hacking around with an existing one. Many people don't
understand the difference. For example, none of the following is a
modification to standard SAP: creating a new access sequence for
pricing, using a custom program to load price conditions, creating a new
authorization object. These are *not* modifications. And yet I have
heard alleged experts say that they are.
I would not say *don't* ever modify standard SAP; sometimes it really
does need to be done. Just that you should weigh the issues, and there
must be a strong case, the "don't do it" should win if the case isn't
proven. Also there are plenty of userexits (blank subroutines) where it
is totally acceptable to put your own code. That is what they're there
for. Of course if you do stupid things in them, you'll cause problems,
but this is true of C, JAVA, or a chainsaw.
As for flexibility, in my experience if standard SAP can't do it with
relatively minor tweaks (customization aside), then 9 times out of 10 it
isn't a good idea to do it anyway.
And if you only take note of one thing, let it be this: Don't try and
build a copy of your legacy systems in SAP.
