Skip to Content

Dates and select options

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:


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.

For the second error, use a checkbox next to the select option to specify whether to use the select option in the data seletion.


You must be Logged on to comment or reply to a post.
  • 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.



  • 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



    • 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.

      • 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?


        • 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?

          • 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 🙂


          • 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.

  • 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!



      • 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 🙂


  • 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!

    • 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..

      • 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

  • 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 🙂



    • 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. 🙂

      • 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 😳 )


        • 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.

          • 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!


        • 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.

          • 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.

          • 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.



  • 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


    • 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! 🙂

  • 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.



  • 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.


      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.

  • Your simple solution is to be compared to the complex code to do the same with SELECT-OPTIONS:

    DATA sflight TYPE sflight.
    SELECT-OPTIONS s_fldate FOR sflight-fldate NO-EXTENSION.
      DATA(restriction) = VALUE sscr_restrict(
            opt_list_tab = VALUE #( ( name = 'L1' options = VALUE #( bt = 'X' ) ) )
            ass_tab      = VALUE #( ( name = 'S_FLDATE' kind = 'S' sg_main = 'I' op_main = 'L1' ) ) ).
          restriction = restriction
          OTHERS      = 1.
      IF sy-subrc <> 0.
        MESSAGE 'Something serious happened!' TYPE 'X'.
    • Ew... TABLES statement... ?

      And imagine how complex it was before VALUE was added to the language! Earlier today I was forced to change a key date parameter to a select-option. I died a little inside... ?