Application Development Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
cancel
Showing results for 
Search instead for 
Did you mean: 

HR_READ_INFOTYPE Question ...

Former Member
0 Kudos

Hi ABAPers,

Hopefully one of you can help me with a simple question ... at least it seems simple. I'm using the function module in my code to do a simple comparison of dates. I have a parameter called zkeydate, that accepts date as the input. For example, if I input 05/01/1998, zkeydate will have the value 19980501

When I call the function module:

CALL FUNCTION 'HR_READ_INFOTYPE'

EXPORTING

TCLAS = 'A'

PERNR = zpernr

INFTY = '0000'

BEGDA = '18000101'

ENDDA = '99991231'

  • BYPASS_BUFFER = ' '

  • LEGACY_MODE = ' '

IMPORTING

SUBRC = zsubrc

TABLES

INFTY_TAB = temp_pa0000

  • EXCEPTIONS

  • INFTY_NOT_FOUND = 1

  • OTHERS = 2

The begda field in temp_pa0000 has the date listed as 11998050. Obviously it's throwing off my comparison.

If anyone has run into this problem and may know the issue, please advise.

Thanks,

Meezy

1 ACCEPTED SOLUTION

Former Member
0 Kudos

hi meezy,

Please check your data declaration for the field ZKEYDATE, it should be referencing a data type with type DATUM preferably SY-DATUM if it is a report selection screen.

If it is a field in a dialog screen, then there is a field in the attributes of the screen field (when you double click on it) for reference data type, it might be character right now, please ensure it is DATUM (or the like).

This should resolve the issue, because all date fields (referencing sy-datum e.g.) are stored internally in YYYYMMDD format.

Cheers,

Aditya

5 REPLIES 5

Former Member
0 Kudos

hi meezy,

Please check your data declaration for the field ZKEYDATE, it should be referencing a data type with type DATUM preferably SY-DATUM if it is a report selection screen.

If it is a field in a dialog screen, then there is a field in the attributes of the screen field (when you double click on it) for reference data type, it might be character right now, please ensure it is DATUM (or the like).

This should resolve the issue, because all date fields (referencing sy-datum e.g.) are stored internally in YYYYMMDD format.

Cheers,

Aditya

0 Kudos

Hi Aditya,

My parameter definition does reference sy-datum.

The problem is, when it does the comparison:

zkeydate = 19980501

temp_pa0000-begda = 11998050

The function module seems to shift the date around one character.

Thanks,

Mike

0 Kudos

Hi there,

Now I think I see the problem.

Do you have a command for moving any data records into temp_pa0000 structure? If so, that might be causing the shift in the structures because of mismatch of fields.

Please perform an explicit

MOVE zkeydate TO temp_pa0000-begda ... instead of MOVE <structute> TO temp_pa0000 (if you are doing that).

Best would be to put a break point OR watchpoint on when temp_pa0000-begda value changes .... this would give you a better insight into whats corrupting the field.

Cheers,

Aditya

Edited by: Aditya Laud on Feb 1, 2008 12:54 PM

0 Kudos

Hi,

It looks like the issue is happening when the data is returned to the table the function module is using. If you take a look at my code, you see that temp_pa0000 is the table the function module is using:

CALL FUNCTION 'HR_READ_INFOTYPE'

EXPORTING

TCLAS = 'A'

PERNR = zpernr

INFTY = '0000'

BEGDA = '18000101'

ENDDA = '99991231'

  • BYPASS_BUFFER = ' '

  • LEGACY_MODE = ' '

IMPORTING

SUBRC = zsubrc

TABLES

INFTY_TAB = temp_pa0000

  • EXCEPTIONS

  • INFTY_NOT_FOUND = 1

  • OTHERS = 2

.

loop at temp_pa0000.

if temp_pa0000-begda <= zkeydate and temp_pa0000-endda >= zkeydate.

append temp_pa0000 to i_pa0000.

endif.

endloop.

Thanks,

Meezy

0 Kudos

Did you check the declaration of temp_pa0000? It should be declared like the infotype structure P0000 and not the table PA0000.

HR_READ_INFOTYPE will always return to the structure definition, not the infotype table definition.

Best Regards,

Chris H.