Skip to Content
Author's profile photo Marcin Pciak

Do you really know everything about typing?

I was
wondering quite long how my blog should touch the topic I want to discuss.
Should I start from the basics and introduce the developer step by step to data
types or maybe go straight for more advanced topics. Finally I decided that all
the basics most of us already know and I add no value to the current contents
of SAP documentation which cover elementaries quite well. It also mentions a
bit about the complex typing but there is no real example which would
truly convince me for using it neither showing the power which sits behind the
scenes. This is what I will try to feed the developer with. So please a have a
comfortable sit and be prepared to start using this technique after reading the


*Nested, deep and flat*

This term usually
goes with structures and tables. Nested structure have other structure as a component. We
define such structure like

Here the address
component is a structure itself. So the +gs_user
+structure looks like:



The basic
rule for addressing the components of gs_address is
<structure_name>-<substructure_name>-<component>. It
therefore adds another level of addressing the actual components. What we gain
in exchange is now we can address whole address
at once as a whole substructure. We will focus on that later.

Before I go
further I want you to be aware that *deep*
structure is just the one whose any component (even this nested one) have
dynamic type (string, xstring, table type, reference type). In contrary any
structure which doesn’t fulfill this requirement is a *flat *structure. So the structure can be flat yet nested. In our example gs_user is such structure. If we change component street or +name +to be of type string
it would be then a deep nested structure. I hope you get the difference.


*Same level grouping

Apart from
including whole structures as the components we can use +include to group our components under one name.+

We will use
same structure +gs_address +which
definition we already have above. Now we will use this structure to include its
definition within components of +gs_user.+

By doing so,
we no longer have +nested+ structure.
All the components are now on the same depth level. To prove that go to
debugger and see its definition:


* 1) For every month
  DO 12 TIMES.
*– first determine month bounds
    g_month_start = ‘2008’.
    g_month_start+4(2) = g_month = sy-index.
    g_month_start+6(2) = ’01’.
        day_in            = g_month_start
        last_day_of_month = g_month_end.

  • 2) Select distinct organizational assignment for employee within the month
  •    (might have several records so choose only one)

    SELECT DISTINCT pernr orgeh FROM pa0001
                                INTO (g_pernr,gs_year_data-orgeh)
                                     WHERE begda <= g_month_end
                                       AND endda >= g_month_start.

  • 3) Get components of gs_year_data only for this month

      CONCATENATE ‘PER’ g_month INTO g_comp_name. “PER01, PER02, PER03…
*– get PERXX component
      ASSIGN COMPONENT g_comp_name OF STRUCTURE gs_year_data TO .

  • 5) Collect all data under one organizational key

      COLLECT gs_year_data INTO gt_year_data.


FORM calculate_capacity USING i_month_start TYPE d
                              i_month_end   TYPE d
                              i_pernr       TYPE persno
                     CHANGING cs_perxx_data TYPE ts_data.

  DATA l_capacity TYPE bsgrd.

  • 4) Select distinct capacity for the employee
  •    (might have several records so choose only one)

  SELECT DISTINCT bsgrd FROM pa0008 INTO l_capacity
                       WHERE pernr = i_pernr
                         AND begda +and cx_perrxx_data I was able to address the components with their old names (headcount, capacity), not the new ones (headcount_01, capacity_12 etc). It gave me the opportunity to “hide” the caller’s original type and
pass only relevant part to the procedure. If I passed whole line of +gt_year_data +I would receive every time
bunch of data which I am not interested in within certain context. i.e. I don’t
need to pass fields for March if I am doing calculation for February. Also the
key fields are irrelevant here.

advantage is that typing formal parameter cs_perxx_data
like that, I make my subroutine more “open” to external calls. I am no
longer worried whether the actual parameter passed to subroutine is part of
larger structure or not, neither if it has the correct key fields. I am
therefore not tight to pass only specific type of structure so I make my
subroutine more “generic” in terms of the reusability.


The interesting thing is that I could make my ts_year_data definition like

…which would result in making my structure gs_year_data nested.

. +At the same time I am able to address “groups” of components using gs_year_data-perXX. So nothing really changes in terms of addressing components compared to non-nested grouped structure.The only change is that in this case +perXX +means a substructure and in the previous one a group. Therefore I am still able to use the same calcuation procedure and +COLLECT +statement as the components are flat and all non-key fields are numeric.


One step further in grouping

Just before
final conclusion comes I want to show one you one more thing. I if need another
“layer” of grouping i.e. to calculate mean values for all the months
for each of the basic fields i.e

    • Mean for March for headcount = ( January headcount +
      February headcount + March headcount ) / 3 etc
    • Mean for February for capacity= ( January capacity +
      February capacity ) / 2
    • Mean for March for capacity = ( January capacity +
      February capacity + March capacity ) / 3 etc

I would
therefore only change my original definition to:


…and would
receive another level of grouping. First one would be DATA or MEAN, then would
go PERXX, then components themselves HEADCOUNT and CAPACITY. This little change in definition still allows me to use calculate_capacity subroutine. I would
only have to change this line to address DATA
or +MEAN +grouping

Meanwhile I
can write some procedure which still would accept two structures namely +IS_DATA +(only for evaluation) and CS_MEAN (for real calculation) both of
type +ts_data. +This way we keep
working only on the basic structures and don’t have to worry whether it is a
part of something bigger or not.



For some standard tables SAP is using something similar called repetitive structures i.e for table
PA0008. These is just a bunch of components with same subsequent suffixes
LGAXX, BETXX, ANZXX, EINXX, OPKXX where XX is b/w 01-40, but there is no usage
of INCLUDE STRUCTURE there. So in fact we are not able to work with these
components as a group, rather they have to be treated individually. For this
purpose we have to use ASSIGN COMPONENT or ASSIGN…INCREMENT in conjunction
with DO loop or just using DO…VARYING. This is however not so convenient way
of working with whole structure. If you are interested more on these kind of
structures please refer SAP documentation.



Summing up
our deliberations there is a huge advantage of grouping repetitive components
within structure. Not only they become more reusable but also they give us the
feeling that our final structure consists of smaller elements logically grouped
rather than loosely defined non-connected components. If you mastered in
include structures you can create highly reusable procedures not only intended
for usage of one program still providing highly specialized service. So next
time before you start developing your report stop for a moment and think over
if this concept can  be somehow implemented in it. I am sure you will benefit from
using it soon.


Didn’t feed you hunger?

Want to see
how to implement this concept in ABAP Dictionary or how to create such things dynamically? If so, stay tuned for
next knowledge release.

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Former Member
      Former Member
      I did not know you could do that. Thank you.
      Author's profile photo Durairaj Athavan Raja
      Durairaj Athavan Raja
      Thanks. Today i learnt something new in ABAP. "RENAMING WITH SUFFIX" is something never even heard of before. Thanks again.
      Author's profile photo Pablo Casamayor
      Pablo Casamayor
      Clear and concise.
      Thanks for sharing.
      Author's profile photo Former Member
      Former Member
      interesting primer on some not so obvious ABAP statements and how they can be implemented in the real world. i want to learn more.
      Author's profile photo Marcin Pciak
      Marcin Pciak
      Blog Post Author
      Thank you all Guys. I will surely keep extending this topic. Cheers
      Author's profile photo Kenneth Moore
      Kenneth Moore
      Very good blog and interesting.  However, you should always do an authorization check when accessing HR tables!
      Author's profile photo Marcin Pciak
      Marcin Pciak
      Blog Post Author
      Yes, I agree with you. Employee Master Data are sensintive one so this should be treated with special care. We can use standard functions like HR_READ_INFTY to extract these data providing authorization check. Anyhow the intention of the blog was to introduce the developer with this special way of typing, that's why I used direct query approach. Nevertherless I totally agree with. Thanks for the comments.
      Author's profile photo Thien Pham Minh
      Thien Pham Minh
      Thanks for sharing this. Very good thinking
      Author's profile photo Ankur Godre
      Ankur Godre
      Hey there,

      Quite intersting blog, it was like reading between the lines. Structures & Types being used in almost all programs however, you presented a different perspective to the usage...Keep blogging ...

      Author's profile photo Steve Oldner
      Steve Oldner
      Saw this in SAP's code just the other week.  Thanks for the explanation.
      Author's profile photo Former Member
      Former Member
      I think my approach would be to use a nested table rather than a repetetive structure, as you can loop through rows without having to construct component names in your logic, and the data definition is probably less cumbersome.
      Author's profile photo Marcin Pciak
      Marcin Pciak
      Blog Post Author
      Nested table would be a different component then nested structure or included one, wouldn't it? As long as you don't need to hold table within table but same level data I think this approach is worth using it.