Hi Leandro,
It's good to use standard data elements and domains but when they serve your purpose. If you use a standard data element, the labels would be inherited from it and you will not be able to change them. This can be a problem especially in cases where you have to display the fields on the screen. Having said that, even if you don't have screens on the field, the short description that you would see in SE11 for that field would be inherited from the standard data element and therefore may not present the true picture to the viewer. This may be under-rated or ignored but I do feel showing the correct short description makes a lot of sense. That's because if you have the correct short description for the field, you can understand quite a lot about the field's semantics just by looking at a table's structure. Yes, you can name your fields according to their semantics but it would look confusing if the field and its short description do not fit together.
Another limitation with using standard data elements and domains is that you can't change their data type. Many a times, we see data types of fields changing during a project. If you've used a custom data element/domain, it's easier to adopt the change.
Although I would agree that the more custom objects you have, more careful you have to be with the transport process, I would not suggest NOT creating custom data elements and domains purely for this reason.
I would recommend using standard data elements and domains for fields which are very generic in nature for e.g flags like True/False.
Yet another approach (or let's call it the middle path) is to create your custom data elements that use appropriate standard domains. This way you can have your own labels and texts but at the same you can reuse the standard domains. Of course, this would be applicable in cases where the standard domain's attributes (conversion routine, value range) meet your requirements.
Bluesky
