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.