General Configuration Tips &
Tricks
I have found the items detailed below to be of benefit from
the perspectives of ease-of-use, maintenance, ease-of-upgrade and configuration
integrity.
Avoid using standard SAP configuration types in your
business production environment
Don't use any of the standard order types delivered by
SAP - except as a base for the new 'Z' order type that you create!
Using custom 'Z' types forces you to address all of the related configuration
due to the introduction of a new configuration type. It also helps you identify
configuration integration issues if you miss out required configuration in a
related application.
This approach forces you to investigate and address the new
configuration proactively. In some cases, the standard configuration may be
overwritten during upgrade, increasing upgrade complexity and risk. It's
also far easier to identify and work with what you have configured if you
exclusively adopt this approach (e.g. SAP provides a "display by contents"
function in all configuration tables where you can view only entries in a particular table
starting with 'z').
Clean up key configuration 'integration' tables
Certain tables drive integration functions between applications (e.g
between SD and MM). By cleaning out the entries that you don't use,
you force integration by literally seeing what 'breaks' after the cleanout
occurs. Try this before your detailed design phase - but after most
of the prototyping and mapping to SAP has been completed. I wouldn't
advise doing this to every table - the effort would take too long
and just doesn't have the same benefits across the entire application.
An example of an integration table is the Order Item Category determination
configuration in SD.
When deciding on a solution, try to choose configuration first over development
If you have a requirement that can be solved by either a custom
development or by SAP-provided configuration; pursue the configuration
solution first! Configuration tends to provide far more flexibility
in the long run, is supported by SAP and can be extended over time as SAP
adds new functionality to the function area.
We have a physical warehouse location, should we map it to a SAP Storage
Location or SAP Plant?
The generally better option here is to
choose to map your warehouse to the Plant level. I usually adopt
this option by default and only change the mapping under very
specific circumstances. A general rule is that a plant maps to a
specific, individual business address. Most of SAP's business
transaction functionality was originally targeted at plant level (e.g. SD
Replenishment orders).
Yes, it does imply additional material master
record maintenance and volumes (but that's what mass maintenance utilities
are for), but it sets a great base for flexibility in terms of new
business transaction functionality SAP may introduce or potential business
changes at that location in the future (e.g. warehouse gets sold off to
another company or new transactions take place at that location).
You can choose to map to storage
location, but you'll sacrifice some future flexibility. You may also
have to develop custom functionality to fill in for SAP functions which
operate more seamlessly at the plant level.
Don't pay for multiple SAP Sales Organizations with huge master data
volumes
Customers and materials are keyed off of Sales
Org, Distribution Channel and division. If you have determined that
you need multiple sales areas under a common sales org, it does not mean that a master
records need to be created for each sales area!
You can set up a "reference"
distribution channels & divisionsto which all the others are linked. This means you can create ONE
set of master data records and have configuration point all related sales
areas to that common data no matter which organization is being
processed in a given business transaction. Pricing and related
functions may still be defined at specific organization levels, using the
common master data.
|