Skip to Content

Just a little note about a couple of common errors:

This is not rocket science ABAP programming.

But it does show how even the very basics can be mishandled. As ever, when developing, think about what is happening with the data in your variables. And always be prepared to challenge any spec of requirement, by leading the requester through the consequences.

What the user asks for and what the functional consultant requests are not always what they need!

ERROR 1: Using a select-option when you need a date range

If you want a start date and end date, it is a mistake to use a select option. It’s a mistake often made by functional consultants as well. I’ve even challenged functional guys and they’ve insisted “no, I want a select option”. When I’ve taken them through the requirement, they realise that they don’t actually want a select option, they want a date range.

The reason it’s a mistake is that the structure of a select option (an internal table with header line) is:

SIGN OPTION LOW HIGH

That means the user can enter all sorts of weird and wonderful combinations of selections, ranges and exclusions – and your code won’t be able to handle it properly. What will you do if the user enters?

I BT 01.01.2014 31.01.2014

I BT 01.01.2013 31.01.2013

E EQ 02.01.2014

The user wants January 2013 and 2014, but not the second of January. But many date handling and validation routines, will fail with this selection. The user doesn’t get what they expect.

ERROR 2: Mishandling an empty selection

Not infrequently, the specification will ask for special handling of an empty selection – something like “if the select is blank, then select nothing”. This is also a mistake. An empty select option in standard SAP throughout the SAP system means “select everything”. If you follow the functional consultants request, you’ve broken the expected functionality for the user.

So what’s the solution?

Far better (and what most SAP programs do, where they really just want a start and end date) is to simply use:

PARAMETERS: start TYPE d, end TYPE d.

This solution satisfies the actual requirement 99% of the time, and makes your program behave in an expected way.

To report this post you need to login first.

31 Comments

You must be Logged on to comment or reply to a post.

  1. Venkat B

    Hi Matthew,

    Yes you are right for dates every functional consultent has to be clear what they want and Technical consultent has to analize the scenario.

    Thanks for sharing this information regarding date.

    Regards,

    Venkat.

    (0) 
  2. Avirat Patel

    Hi Matt,

    Thank you for the knowledge addition..

    Is it happen only with custom development ?

    What happen if we supply dates in standard sap transaction.

    I have not tried it(specific) up till now but after reading this document

    I am looking forward for the result what happen if we supply values

    accordingly….

    -Avirat

    (0) 
    1. Matthew Billingham Post author

      It depends how the programmer has developed it! But if you look at the older standard reports in ECC modules, you’ll see they often have start date and end date as parameters.

      Sometimes it’s right to use a select option – but you need to be aware of the implications.

      (0) 
      1. nabheet madan

        Hi Matthew

        We can have same type of restictions in select options via select option of what a person should be allowed to select.

        Basically why i am making this point is tommorow if some things need to be changed in selection criteria for example i want a data from 01.Jan-2014 to 01-Jan-2015 excluding 20-Aug-2014 data(an example) then i think if we have parameters we will need to make lot of changes. Had we use select option we will haev to just play with the restrictions.

        What do you think?

        Nabheet

        (0) 
        1. Matthew Billingham Post author

          As I said: Sometimes it’s right to use a select option – but you need to be aware of the implications.

          The point is that what is often wanted is a date range and what validation routines expect is a date range. What is given is a date select option.

          I’ve seen code like: SELECT data FROM dbtable WHERE fromdate gt s_date-low and todate le s_date-high.

          That is the point of this blog. If you want people to have all the flexibility of select options and they understand all the things they can do with them – that’s great. But if you really just want a start date and an end date and the functionality of your program is written to expect that, then don’t use select-options. Use parameters.

          Do you see now?

          (0) 
          1. nabheet madan

            I agree i have also seen code like these and to be honest when i started my career in ABAP i use to do like the one you mentioned πŸ˜‰

            In case a simple range is needed parameter will be a good choice…while dealing with dates/quantities/amount i try to extra careful πŸ™‚

            Nabheet

            (0) 
          2. Manish Kumar

            I have seen serious abuse of TVARVC table. They create a select-option variable zconfig, and logic doesn’t care about SIGN and OPTION.

            All it does is to store output types in LOW, and hardcoded values to be used in HIGH.

            So a single TVARVC variable gets used as a replacement of CASE statement block. 😑

            Where-used search for a particular TVARVC variable is not as easy as a where-used list of custom config table.

            (0) 
  3. Bruno Esperança

    Hi Matthew!

    I was curious about what the result would be, so I just tried it and it worked. I was thinking that the problem would be that the conditions would be joined with an “OR” operator. And “something or not something” usually returns everything, but that didn’t happen. It actually worked as intended!

    Best,

    Bruno

    (0) 
      1. Bruno Esperança

        Hi Suhas!

        Basically I wrote a very small program with a select options for a date and then a select to vbak with that date for the document’s date.

        Then executing the program I entered the dates in the select options like Matthew suggested, and from the select I got all the documents in the first month of ’13, the first month of ’14, excluding the Jan-2-’14, as expected.

        I can share the code if you’d like!

        Best πŸ™‚

        Bruno

        (0) 
  4. Alexandre Dambrowski

    Hi Matthew and guys,

    For this case, instead of use “PARAMETERS: start TYPE d, end TYPE d.”, I prefer to use a SELECT-OPTIONS with its addition “NO-EXTENSION”.

    It’s a fast and easy way, that has the same result, but using only a variable/structure.

    As any other programming language, we could do something, using many different ways.

    Best regards from Brazil!

    Alexandre B. Dambrowski

    PS: Sorry about my English mistakes!

    (0) 
    1. Matthew Billingham Post author

      That nearly works. But not quite. E.g.

      I NB 01.01.2013 02.01.2013 gives you all dates before 01.01.2013 and after 02.01.2013.

      I GT 01.01.2013 gives you all dates after 01.01.2013

      To get it to work fully, you’d need to start using the modification functions for select options. Two parameters is much simpler.

      Just goes to show that even with what seems to be basic, there are subtleties that need to be thought about..

      (0) 
      1. Alexandre Dambrowski

        I agree! πŸ™‚

        Developer can not just be a code writer!

        We need to analyze and to find the best way to do what really is necessary!

        Best regards from Brazil!

        Alexandre B. Dambrowski

        (0) 
  5. Suhas Saha

    Hello Matt,

    Thankfully most of the functional consultants i had worked with had lil’ bit technical acumen (some could debug & troubleshoot). So for the cases you have mentioned they usually suggested to have From-To dates.

    I did it by –

    1. Select options with NO-EXTENSION,
    2. 2 parameters with From & To dates.

    Any specific reason you did not mention the NO EXTENSION addition?

    I now see why you did not mention the NO-EXTENSION addition πŸ™‚

    BR,

    Suhas

    (0) 
    1. Matthew Billingham Post author

      I must confess that I did use the no-extension approach in my early years. But then my obsessive nature kicked in and I realised that it wasn’t rock solid safe. πŸ™‚

      (0) 
      1. Stuart Gregory

        I’m confused,

        Using NO-EXTENSION gave me a date range IBT2014020420170104, and the SAP UI made sure that the low value was not higher than the high value.

        Where is the harm in using that as a date range?

        (sorry if I’m missing something obvious, it is Friday 😳 )

        Stuart.

        (0) 
        1. Matthew Billingham Post author

          Switch the I to an E. Or you can also have ILT20140204 both of which can destroy the logic if the specification is FROM_DATE to TO_DATE.

          There’s no simple way of enforcing low less than high and range is inclusive of low to high.

          (0) 
          1. Stuart Gregory

            Thanks!

            I hadn’t realised turning off the extensions still lets you alter the range parameters on a right-click of F2.

            I wonder why it’s called “No extension” rather than something sensible like “No multiples”.

            Thanks again!

            Stuart.

            (0) 
      2. Shai Sinai

        Hi,

        You may solve this “safety” issue quite easily:  Use FM SELECT_OPTIONS_RESTRICT to restrict the select-option to I BT only.

        (0) 
        1. Matthew Billingham Post author

          You could. Or even more simply you could use two parameters! That’s the point – simplicity. Why use a function module and a select option when two parameters does the trick and that is what SAP often do.

          (0) 
          1. Shai Sinai

            I agree that Simplicity is important.

            However, in this case (of two parameters) you’ll have to design the selection screen line (SELECTION SCREEN BEGIN OF LINE, COMMENT, etc.) and implement the validation check (Start date is before end date) by yourself.

            I’m not sure it is simpler.

            (0) 
            1. Suhas Saha

              I have used Date-From & Date-To as two separate parameters without the fancy selection-screen design (SELECTION SCREEN BEGIN OF LINE, COMMENT, etc.).

              And putting a “<=” in the PAI of the selection-screen is not a big deal either.

              I will always prefer the 2 parameters (for the date range requirements) over SELECT_OPTIONS_RESTRICT, personal choice.

              BR,

              Suhas

              (0) 
  6. Glen Simpson

    Hi Matt

    I think it’s important to be very clear about when it is ok to use select-options for dates and when it isn’t.

    It’s perfectly fine to use a select-option if the data you are selecting contains a *single* date field (such as a “created on” field) and you want to find records with a date that matches your select-option criteria.

    Select-options do not work, however, if the data you are selecting contains *multiple* validity date range fields (such as “valid_from” and “valid_to” fields) and you want to find records with a date range that matches your select-option criteria.

    Select-options were designed to match single fields within a record, not multiple fields that are logically linked.

    Kind Regards

    Glen

    (0) 
    1. Matthew Billingham Post author

      What you’ve encountered there is that they say they need select options, but really they don’t understand that they don’t. Not much you can do for those who won’t be taught! πŸ™‚

      (0) 
  7. pankaj jain

    What i feel that whenever you required to use GT or LT type of conditions in your query for date its good to use parameter instead of select-option.

    Regards,

    Pankaj 

    (0) 
  8. Neil Devonshire

    To be fair this is a potential problem with all select options, given the “union of the greens minus the union of the reds” behavior.
    I’m not 100% convinced.

    (0) 
  9. Matthew Billingham Post author

    The point is that in custom developments (but not so much in standard SAP report), a date range is implemented via a select-option, when the actual requirement is a From and a To date. You even see it in the code like

    SELECT…. BETWEEN s_date-low AND s_date-high

    Which is obviously wrong, since if the user enters other patterns, it just won’t work as expected.

    Sure, you can run into the same problem with other types, but it’s not so common. If you haven’t already, I suggest you read the preceding comments.

    (0) 

Leave a Reply