Think SAP is bug free? Not really

By | December 12, 2012 | Tricks | 1,254 | 3

Recently, I was working on getting the Handling Unit (HU) details. The purpose of getting the details was to print it on a output. I faced quite a grief because of a simple stupid bug in standard SAP code.

Preface

Customer wanted to display the HU tree structure in the printed output on the Packing List. This HU tree is very nice and easy to understand. Since I didn’t want to write a logic to get the details from the underlying table VEKP and VEPO and building up a tree myself, I started debugging the screen to find a clue.

Handling Unit tree

FM to display

After a while, I found out that the FM V51P_HU_CONTENS can be used to generate the HU tree the way I needed for me to display in the output. I need to pass the higher level HU numbers to the FM to be able to generate the tree output. The higher level HU numbers can be easily selected from VEKP where UEVEL is not populated.

HU tree display - initial version

 
  TYPE-POOLS: vsep.
  DATA: lt_venum TYPE vsep_t_venum.
  DATA: lt_overall_cont TYPE vsep_t_humv4.
  DATA: lt_ivekp TYPE vsep_t_ivekp.
* 
   SELECT venum
      INTO TABLE lt_venum
      FROM vekp
      WHERE vpobjkey = ls_dlv_delnote-hd_gen-deliv_numb
      AND   uevel EQ space
      and   status ne '0060'.
*
    CALL FUNCTION 'V51P_HU_CONTENS'
      EXPORTING
        it_venum       = lt_venum
      IMPORTING
        et_overal_cont = lt_overall_cont
        et_ivekp       = lt_ivekp
      EXCEPTIONS
        error_occured  = 1
        OTHERS         = 2.
    IF sy-subrc <> 0.
      PERFORM PROTOCOL_UPDATE.
    ENDIF.
 

Problem

The output was generated from the delivery. The output timing was Process immediately. Whenever the output is process immediately, System holds the work process till it generates the output. This may not be the ideal in all cases, but it would be required when someone is waiting for the actual hard copy to finish the job.

For most of the time, Delivery was able to successfully save without any issue. For very few instances, when users were doing something different while creating the HU and attaching it to Delivery, it was going into update terminate without saving the delivery data as well as generating the output – OUCH!

The dump analysis (ST22) pointed me to a code which is part of the standard code. I thought this is something interesting and happening within somewhere Delivery save. But by looking at the Call stack, it was apparent that the issue is in the FM V51P_HU_CONTENS in my output driving program.

Advertisement

Runtime Error in HU Tree generation

The error was coming from the include program LV51PF32 because, a field-symbol was not yet assigned. By looking carefully, it comes out as the SY-SUBRC EQ 0 is happening after the use of the FIELD-SYMBOL – a simple stupid mistake. For those few instances, the table GT_XVEKP is not getting the HU details and field symbol remains unassigned. Thus produces a run-time error, leads to a update terminate – without saving Delivery information. Lot of grief..!

HU Tree error code location

Solution

After a lot of debugging and using Google translate to understand the comments, I found out a FM which I can call before the FM V51P_HU_CONTENS to make sure that all internal tables are filled properly & field symbols are assigned.

HU tree display - without dump

 
  TYPE-POOLS: vsep.
  DATA: lt_venum TYPE vsep_t_venum.
  DATA: lt_overall_cont TYPE vsep_t_humv4.
  DATA: lt_ivekp TYPE vsep_t_ivekp.
*
  SELECT venum
    INTO TABLE lt_venum
    FROM vekp
    WHERE vpobjkey = ls_dlv_delnote-hd_gen-deliv_numb
    AND   uevel EQ space
    and   status ne '0060'.
*
  data: ls_flags type V51P_SELECT_FLAGS.
  ls_flags-ADD_AND_EXP = 'X'.
  ls_flags-MORE_HUS = 'X'.
  ls_flags-COMPL_HIST = 'X'.
  ls_flags-CREATE_V51VP = 'X'.
  CALL FUNCTION 'V51P_FILL_GT'
    EXPORTING
      IS_FLAGS               = ls_flags
      IT_VENUM               = lt_Venum
   EXCEPTIONS
     HU_LOCKED              = 1
     NO_HU_FOUND            = 2
     FATAL_ERROR            = 3
     OTHERS                 = 4
            .
  IF sy-subrc <> 0.
      PERFORM PROTOCOL_UPDATE.
  ENDIF.
 
*
  CALL FUNCTION 'V51P_HU_CONTENS'
    EXPORTING
      it_venum       = lt_venum
    IMPORTING
      et_overal_cont = lt_overall_cont
      et_ivekp       = lt_ivekp
    EXCEPTIONS
      error_occured  = 1
      OTHERS         = 2.
  IF sy-subrc <> 0.
    PERFORM PROTOCOL_UPDATE.
  ENDIF.
 

Closing

You might say that it is a valid error as it could find the HU details in the header table. I agree with you, but instead of ending the processing in short dump, it should have raised Exception or at least moved the SY-SUBRC check before accessing the field symbols. We all know that we have to pay extra attention while using the field-symbols, but seems someone didn’t pay much of attention.

Have you ran into similar issues? Share your story.

Like It? Share!!

Don't miss an Update

Naimesh Patel{221 articles}

I'm SAP ABAP Consultant for more than a decade. I like to experiment with ABAP especially OO. I have been SDN Top Contributor.
Follow :

Explore all of his 221 articles.

Load comments

3 Comments

  • priyanka

    Hi Naimesh,

    I am workng on generating the Bill of lading , Can you plz share me at high level , what t-code to be used to generate nd some basic knowledge.. plz

  • Pooja

    Hi Naimesh,

    Your blog is really nice and helpful. I follow it regularly. So, saw your this post and thought of sharing one issue I have came across few days back.
    I have came across an issue in a function module RP_FILL_WAGE_TYPE_TABLE. I was trying to read an infotype 0008 locked record. But the function module was returning me PBWLA table with duplicate entries for some of the wage types, which logically should not happen as Infotype 0008 has time constraint 1.

  • Kesav

    Nice catch Naimesh,

    I really enjoyed it. :-)

Comments on this Post are now closed. If you have something important to share, you can always contact me.