How do I pass a select-options to importing parameter of FM: CHANGEDOCUMENT_READ_HEADERS

[kmdarunday]

Hi,

I have below code for select-options:

 S_UDATE FOR CDHDR-UDATE OBLIGATORY, "Change Date
 S_UTIME FOR CDHDR-UTIME,            "Change Time

Now I want to use FM: CHANGEDOCUMENT_READ_HEADERS to retrieve details from table CDHDR but how do I pass my select-options s_udate and s_utime to importing parameters date_of_change and time_of_change of this FM. I am passing 'VERKBELEG' to objectclass and <lfs_vbeln>-vbeln (from my select from table vbak) TO objectid.

OR instead of the FM, would it be possible to select directly from CDHDR and CDPOS?

SELECT a~objectid,
       b~tabkey
  FROM cdhdr AS a
  INNER JOIN cdpos AS b
  ON a~objectclas = b~objectclas
  AND a~objectid  = b~objectid
  AND a~changenr  = b~changenr
  INTO TABLE @DATA(lt_changelogs)
  FOR ALL ENTRIES IN @lt_vbeln
  WHERE a~objectclas = 'VERKBELEG'
  AND a~objectid     = @lt_vbeln-vbeln "this does not have the same length so I am unable to activate the code
  AND a~udate        IN @s_udate
  AND a~utime        IN @s_utime
  AND b~fname        = 'LPRIO'.

[DominikTylczyn]

Hello kmdarunday

Read the function's documentation - you can use DATE_OF_CHANGE, TIME_OF_CHANGE, DATE_UNTIL and TIME_UNTIL to read change documents created in a specified time window.

I don't think there is a function to read change document headers with creation date select-options.

Why don't you select from the CDHDR table directly?

Best regards

Dominik Tylczynski

[kmdarunday]

Hi Dominik,

I think my question wasn't clear, I know how to use it for single input, but not for select-options. How do I pass the select-options, I can't simply just pass the low values since the high values will not be considered.

[DominikTylczyn]

kmdarunday I don't think there is a function to read change document headers with select-options on creation date.

Why don't you select from the CDHDR table directly?

[kmdarunday]

Dominik, cdhdr-objectid and vbak-vbeln do not have the same length, how do I use vbak-vbeln in the where clause?

SELECT a~objectid,
       b~tabkey
  FROM cdhdr AS a
  INNER JOIN cdpos AS b
  ON a~objectclas = b~objectclas
  AND a~objectid  = b~objectid
  AND a~changenr  = b~changenr
  INTO TABLE @DATA(lt_changelogs)
  FOR ALL ENTRIES IN @lt_vbeln
  WHERE a~objectclas = 'VERKBELEG'
  AND a~objectid     = @lt_vbeln-vbeln "this does not have the same length so I am unable to activate the code
  AND a~udate        IN @s_udate
  AND a~utime        IN @s_utime
  AND b~fname        = 'LPRIO'.

[DominikTylczyn]

kmdarunday

CDHDR-OBJECTID stores a key to the changed object. In case of sales order changes (VERKBELEG change object), the key is a sales order number. Of course CDHDR-OBJECTID is longer than a sales order number because change document are used for man different objects with different key lengths.

You can change the definition of lt_vbeln-vbeln to data element CDOBJECTV. This way the lengths will be the same.

[FredericGirod]

I never understand how it could works to have two select option for date & time.

If I enter 01-apr to 04-apr and 5pm01min what will be the time area of the selection ?

If I enter <> 01-apr and <> 04-apr <> from 2pm to 4pm ??

[sergiorecasens]

Hi,

The parameters 'DATE_OF_CHANGE' and 'TIME_OF_CHANGE' of the FM CHANGEDOCUMENT_READ_HEADERS accepts only a single value, not a range/select-options.

You must call your FM for every entry of the S_UDATE and S_UTIME ranges table. I.e.:

LOOP AT <select-option name> ASSIGNING <lfs_sel>.
  
  CALL FUNCTION CHANGEDOCUMENT_READ_HEADERS
    EXPORTING 
       i_date_of_change = <lfs_sel>-low.
       i_date_until = <lfs_sel>-high.

ENDLOOP.

[kmdarunday]

How does this work for the high values? and the range itself? from low to high?

[sergiorecasens]

Hi,

Check my updated answer.

Thanks,

Sergio

[DominikTylczyn]

sergiorecasens That will work for only very simple select options e.g. won't work for single value exclusions. Besides this way you put selection inside a loop, which is not a good practice from performance stand point. Better to select directly from CDHDR.

I liked how you updated your answer - you must have read SAP Q&A: How to post a perfect question to get a perfect answer ;))

[DominikTylczyn]

frdric.girod Putting date and time into separate fields as opposed to a timestamp was a terrible design decision indeed.

[FredericGirod]

dominik-tylczynski I always prefer to use parameters for time/date interval, to avoid exclusion, complex entries

[matt]

frdric.girod I do that too, as do most reports in standard SAP. As far as I'm concerned a select option for a date range is usually an error. The consultant might say "I want a select option for the date", but what they mean is "I want a range". I always push back.

I wrote about it here: https://blogs.sap.com/2014/02/07/dates-and-select-options/