SAP ECC6.0 : Proper customer table creation...

Editor: I will not touch SE11's EVENT MODIFICATION under Table Maintenance Generator. I will probably do it at a later period.

Every company have their own customize development guidelines for customer table developments. Specific naming convention and specific type of data declaration. All this are part and puzzle of development team rules. Unfortunately, I observed that this doesn't really help much when it comes down to gist of realization of what fields should be included into a customize table. I emphasized here about what fields should be used because we are only, as usual, informed which fields will be required by our functionals. Essentially they only want to see and use that particular fields. However what of other additional fields that is required for your proper development? This entry, I want to share with you of my experience in customize table development.

A proper customized table as required by functionals should always has the following structure:(I did not purposely come out with this recommendation because of ECC6, I'd practiced doing this since 4.6c. Moreover, this practice was passed it down from one of my seniors who is now in Singapore!)

MANDT (this is to tell which data belongingto which client)

KEY FIELD 1 - CHECK TABLE (it can be your required field)

KEY FIELD 2 - CHECK TABLE (it can be your required field)

...

KEY FIELD n

non key field 1 - CHECK TABLE (it can be your required field)

non key field 2 - CHECK TABLE (it can be your required field)

...

non key field n

CHECKBOX 1 (optional)

...

CHECKBOX n

CREATED ON

CREATED AT

CREATED BY

CHANGED ON

CHANGED AT

CHANGED BY

Observed those additional fields especially CREATED ON until CHANGED BY fields. Those fields will help your user to especially keep track of line data's accountability. With these fields users are able to monitor who at a certain period created this or update the line item. This can be important when it comes to troubleshooting and determination of responsibility and safety (compromised?). It may not be as important but there may be expectation that this fields can be made use in future (who knows) to be use part of report filtering.

Yes, you may not need to do this, because at the SE16, you can view your CHANGE LOG feature. This feature is only guaranteed if your customized table had its "Changed Log" checked at Technical Attributes in SE11. So it is still fine that those additional fields are put in. As i said, you might never know when an executive or someone from the department comes over to you and ask "Who change the table's data?". So credibility on this part plays a great deal!.

Though now we had moved from 4.6c to ECC6, SE11 had made several changes which included a new feature called 'Enhancement'. You can actually regulate your customize program whether the next developer can change the fields, specific fields, or cannot change the customize program at all. Look it up, my friend. You won't miss it because everytime you activate your customized table, there will always be a WARNING message telling you that this table is not set for certain enhancement!.

is sky the limit... proper customized table