Skip to Content
Technical Articles

Getting the basics right – Creating the perfect config table (Part 1, The Table)

When we build our own development we are frequently required to create config tables ourselves and it’s easy enough to create something adequate in SE11.  But with the correct settings a custom config table can integrate seamlessly into the standard SAP config tasks.

By a config table I mean a table of mainly static values that is configured and transported through the system landscape.  Here we’ll use an example of a new config table with three fields; Sending Country (Domain LAND1), Receiving Plant (Domain WERKS), Surcharge Flag.  Country and plant is the key.

So, into transaction SE11 to create the table.

Give the table a name and description that fit your local development standards.

On the Delivery and maintenance tab,

Delivery class – C, obviously this is a config table after all.  This is used in client copy (particularly if you choose the config-only profile) and while setting values other than C can stop a table being transportable, setting it does not force the table to be so.

Data Browser/Table View Maint. – Set it to ‘Display/Maintenance Allowed’, as once we’ve created this config table we’re assuming someone will want to put some settings in it.

Defining the Fields

I’ve created three new data elements (ZLAND1 with domain LAND1, ZWERKS with domain WERKS and ZSUR_FLAG with domain BOOLE) for my three fields.  We could use standard data elements but in this example I need specific texts to describe the fields.


Foreign keys are import at this point.  If when I generate my maintenance dialog I want the fields to be validated against a check table then I need to define a foreign key.  Also, the foreign key will define the search help for the field.

Click the Foreign key button image and if the domain for the field includes a check table this will be proposed for the foreign key.


Because I’ve used standard domains with check tables defined I simply accept the proposal and repeat for each field.


Technical settings


Switch on buffering as this is a table with data that changes infrequently.

Set the checkbox for Log data changes.  This means that if the parameter rec/client is set the change history of your table contents will get recorded.

Before you activate your table, set the enhancement category.  Use menu Extras -> Enhancement Category…


For a config table such as this the setting has little meaning, so ‘Cannot Be Enhanced’ will do.  It’s worth setting as otherwise warning messages are generated every time the table is activated.

Maintenance generator


Authorization Group.  Always use a meaningful authorisation group, by which I mean don’t use &NC&.  In CRM there are over 2000 and in ERP over 9000 tables delivered with the &NC& authorisation class (check TDDAT if you don’t believe me).  If you use &NC& you will unavoidably have to give authorisation to all of these tables.  And your security team won’t like that.  If your config table relates closely to some existing standard config use the same class as that table, or use a customer created class.  It’s not necessary to create hundreds of classes, one for each module or workstream is usually enough.

Function Group.  I would always make the function group the same as the table name; no need to create it first the generator will do this for you.  It is possible to use the same function group for multiple tables, but offers little benefit and less flexibility.  Never use a function group containing manually created function modules as regenerating the maintenance modules can delete elements of your manual function modules.

Recording routine.  This is the key to integrating the table into the transport landscape (which, as it’s a config table we’re keen to do).  Set this to ‘Standard recording routine’.  This will mean that if the client is set for ‘automatic recording of changes’ your config changes will be captured in a transport, and also that if the client is set for no config changes your table will be display only.  If this section is greyed out it is because the table has been assigned to package $TMP, the system is smart enough to know that if you can’t transport the table definition you should not be able to transport the contents.


So, there’s our config table defined, and can be maintained in transaction SM30.


What we have is a table with a look and feel consistant with SAP-delivered config and fully integrated into the transport system.  From here we can use other techniques to further integrate our tables with SAP-delivered config.

You must be Logged on to comment or reply to a post.
  • Thanks for the series, usefull tips and explanations about why certain things are done.

    The empty authorization group is interpreted as &NC& by the views and table browsers. “NC” means “not classified”… so it does not make sense to generate a maintenance dialog for a table if the data in it is still “meaningless”. Same goes for views! Thanks for mentioning that.

    Regarding the table logging, and that these config tables are predestined for being transported in most cases, it also makes sense to activate the “recclient” parameter in the STMS transport profile to the same value as the “rec/client” parameter in the system profiles.

    This records the table logging entry at import, as the original source system of the development may vary, or even not be available anymore.


  • Another VERY useful feature when creating custom tables is the ability to use events via the maintenance dialog (to edit entries or for all sorts of other reasons). I’m sure it’s an old feature, but I only came across it recently and love it to death now!
  • Thank you for this great guide. If only I could had it a couple of years ago!

    What do you think would be ‘the perfect way’ to provide in-system documentation for users on such a config table?
    I suppose it should be a custom IMG structure (tr SIMGH) with documented nodes. It will look exactly like SPRO then. For example transaction SALE. What do you think?