DATA definition: TYPE or ?

Was hoping to find some guidelines on this but didn't see any specific suggestions.

When you define variables, do you use a data element or table and field name as type? For example:

DATA: lv_werks TYPE vbap-werks.

or

DATA: lv_werks type werks_d ?

(And it always gets me that WERKS is a structure. :) )

I lean towards the first option, especially when defining internal tables for SELECT. Obviously SAP can change the assigned data element in a standard table, so reference like vbap-werks prevents from a possible type error. But I'm wondering if there are any other factors to consider. What do you use and why?

Related questions

8 Answers

Looks like someone screwed up early with structure WERKS and it was too late to do anything about it afterwards!

I use the second. Irrational I know, but I just don't "like" the first. However, semantically

DATA werks TYPE vbap-werks.

has more contextual meaning than

DATA werks type werks_d.

If the variable is only used in the context of the sales document item plant, then you should probably use the first, but call the variable sales_doc_item_plant (although I think we can be forgiven using werks instead of plant, since werks is so widely understood). I guess the idea is that if for some utterly strange reason, a VBAP plant became a different thing from a MARC plant, your program is safe.

If the meaning is more it just being the plant, then use the second. All very minor stuff and I don't think it really matters (obviously, because I prefer the "wrong" one). Of course

SELECT SINGLE werks FROM vbap INTO @data(sales_doc_item_plant) WHERE ...

Alert Moderator

Add comment

Good point on "where used", I haven't thought about it. Our guidelines didn't have any rules on that (well, they were written by me and I have no clue, as you see :) ). But I'm also wondering if some kind of overhead could be involved. And I agree, it's really minor thing but I just realized I do something and I don't even know why.

1) Whenever I create a report or transaction that suppose to work with the existing or standard objects (sales orders, purchase requisitions, etc. ) then I always use the reference to table and field specific to the development, so for sales orders vbap-werks, for purchase orders eban-werks and so on. The reason behind is that then I'm sure that when I will link this field to a screen field or to ALV then I will have correct F1/F4 help, input help and translation.

2) When I create new objects then I use two ways:

If I have a Z-table behind, then I do the same like in point 1) but instead of using standard Data Elements I create often new ones, for better translation for example.

In case I don't store anything in DB but I just do some functions then I create a type or structure inside FG or class and later on I reference the type stored there, for example data: plant type zcl_whatever=>t_data-plant. In this case whenever I need change I do it only in one place.Of course if I would need to display this field somewhere then I would create data element first and I would reference it inside the class / FG.

Alert Moderator

Add comment

Thanks for a reply! This sounds like my approach as well. I don't have any reasonable explanation for it though, :) But it looks like there is really no "right" or "wrong" way of doing it in general, just different situations and personal preferences.

Well, either way this has been an educational thread for me. Thanks for sharing!

I mostly use the data element directly as it's more obvious to me what the type is. The only exception is when I define an output table type for an ALV, because in my experience using the structure works better for value helps in generated field catalogs.

The argument of the data element changing in the structure definition works in both ways by the way. Maybe your code only works if the type does not change when the structure changes, depending on the use case (other than select propably).

(Also using the structure in the type definition introduces an additional hard dependency on the structure type which might be less visible than the data element especially if it's the structure of a database table. That is if you are using package interfaces...)

Add comment

I also believe in using the simplest (read: most elementary) option. So it's data element for me too.

Like others, I tend to go for inline declarations too.

I disagree with Tarun's argument about where-used, IMHO this unnecessarily narrows the scope. Within the same component one developer may reference VBAP-WERKS and another T001W-WERKS instead - after all this is the origin of Plant.

Alert Moderator

Add comment

Sometimes I find myself doing the same. After getting burned a few times (like with WERKS) when "owls are not what they seem", I started to prefer <table-field> option just to avoid any issues. But when it's a more generic variable then I look for a data element. I guess that makes sense... At least that's what I'm telling myself. :)