Is there a means to add selection-fields and additional check-routines to ME28?

[BaerbelWinkler]

Many years ago (in 2004) program RM06EF00 (TCode ME28) was copied to a Z-version in order to add a select-option for EKKO-ERNAM. Only the main program was copied, so, the Z-copy then contained all the original SAP-Includes. Later, more selection-fields were added for a custom field and the MRP Group to restrict the selection even further. In addition, a completely new check-routine was implemented, including Memory IDs, a modification of the SAP-program and the call to a Z-Function module. The Upgrade to NW 7.50 with EHP6 made some more copying of code from RM06EF00 into the Z-version necesary. All in all, obviously not an ideal situation, to say the least!

I now have the requirement to "just" add one more field to the selection-screen, which - ideally - should also show up in the output list. This is where things get "interesting": the Z-program still writes a simple list with several lines per entry, while the standard program creates an ALV-output. The code to generate the output is somewhat elusive as it doesn't live in the Z-copy and I haven't been able to find it in one of the many includes either, yet (but haven't looked too closely for it either).

When I test the Z-program, it displays the old list, but when I go back to the selection-screen, I end up in RM06EF00, so there's something off with the internal process flow.

I already searched SAP Community and did find some blog posts offering some pointers of how to add fields to the ALV-output (here from joao.sousa2) and enhancing ME35K (here by abijith.chandrap). Neither mentions how to add more select-options to restrict the selection and I'm also not sure if our additional check can be implemented via an enhancement.

Does anybody have some pointers of which route to take (apart from just going ahead and making the situation worse by adding yet another select-option and accompanying logic to the Z-program)?

We are on NW 7.50 SP 22

Thanks much and cheers

Bärbel

[FredericGirod]

Hi Bärbel,

and what about doing a simple debug when the ALV is on the screen, and look at the Call Stack.

You probably see how ALV is processed, and from where.

I am unable to run this transaction on my system, but there is something looks like an ALV in the function ME_REP_START_VIA_TABLE_MANAGER. (it is little bit difficult without running the trans.)

Fred

[BaerbelWinkler]

Hi Fred,

thanks for your comment - I'll try with debugging next.

I already tried - briefly - via SAT to identify what's happening differently in the SAP-program as compared to our Z-version, but nothing jumped out. The ALV-output isn't my biggest concern, I'd actually like to get rid of the Z-program but then the special logic added there will need to somehow find its way into the standard program.

Cheers

Bärbel

[ChristianGünter · Accepted solution]

Hi Bärbel,

what we often do to fulfill such requirements is to add an implicit enhancement implementation at the end of the report. With this mechanism it's possible do add further select options and parameters to standard selection screen 1000. There are two caveats to this solution. First, you have to assign the text manually, because one cannot add the selection text to programs textpool without modification. Second the new select-option isn't statically know in the report. Therefore we need a means to share data between the report and the place where the filter should be applied to avoid dirty assigns.

In this case I'd add an enhancement like this:

  SELECT-OPTIONS: s_ernam FOR ekko-ernam.

INITIALIZATION.  
  %_s_ernam_%_app_%-text = 'Created by'.
  zcl_rm06ef00_enh=>set_ernam( REF #( s_ernam[] ) ).

Whereas ŻCL_RM06EF00_ENH is as simple container for the new select-option.

CLASS zcl_rm06ef00_enh DEFINITION  PUBLIC  FINAL  CREATE PUBLIC .   

PUBLIC SECTION.  
CLASS-METHODS:  set_ernam  IMPORTING  ir_ernam TYPE REF TO data.   
CLASS-METHODS:  get_ernam  RETURNING  VALUE(r_result) TYPE REF TO data.   

PRIVATE SECTION.  
CLASS-DATA:  r_ernam TYPE REF TO data. 
ENDCLASS.

CLASS zcl_rm06ef00_enh IMPLEMENTATION.   

METHOD set_ernam.  
r_ernam = ir_ernam.  
ENDMETHOD.   

METHOD get_ernam.  
r_result = r_ernam.  
ENDMETHOD. 

ENDCLASS.

Then we need a place to apply the filter. In this case, as pointed out by the above mentioned blog, it's BAdI ME_CHANGE_OUTTAB_CUS does the job for ALV output. There you can access the select-option and implement according filter logic.

IF im_struct_name = 'MEREP_OUTTAB_PURCHDOC_REL'.  
TYPES: tr_ernam TYPE RANGE OF ekko-ernam.
DATA(ernam) = zcl_rm06ef00_enh=>get_ernam( ).
FIELD-SYMBOLS: <s_ernam> TYPE tr_ernam.
IF ernam IS BOUND.
ASSIGN ernam->* TO <s_ernam>.
ASSERT sy-subrc = 0.

" Add logic to filter CH_OUTTAB according to select-options...  ENDIF.

ENDIF.

Unfortunately the BAdI isn't processed for classical list display. Therefore we could add similar logic in implicit enhancements in selpa_check_kopf(sapfm06l) for header fields or selpa_check_pos(sapfm06l) for item fields.

Hope this gives you a few pointers. Looking forward to your solution.

Christian

[BaerbelWinkler · Accepted solution]

christian.guenter

Hi Christian,

thanks for your answer which definitely provides some "food for thought".

Please correct me if I'm wrong, but this will only work for fields already available in EKKO as ERNAM is and it applies the restrictions shortly before the output is generated, so may get a lot of unneeded data to begin with and only then discard it?

The other restrictions already in place in our Z-program unfortunately need line item related data from EKPO, MARA and MARC which is retrieved with a SELECT...ENDSELCT construct and sets a deletion flag to delete entries from internal XEKKO if none of the line-items fits the selection-criteria. This logic is currently included in the middle of START-OF-SELECTION. And it's the place in the code where I'd need to apply the change if we keep doing this as we did before.

And then there's also the rather involved additional check logic applied in our Z-program via which releases are rejected due to some involved determinations.

Looks as if we'll need some disucssions with the users if this additional logic is still used/needed before we do something (too) drastic!

Cheers

Bärbel

[ChristianGünter · Accepted solution]

"Please correct me if I'm wrong, but this will only work for fields already available in EKKO as ERNAM"

It's not necessary that the field exists in EKKO. While implementing the filter logic it's possible to implement any kind of logic and then based on that logic discard the entries not fitting.

"...it applies the restrictions shortly before the output is generated, so may get a lot of unneeded data to begin with and only then discard it?"

Yes that's right. That's another major drawback of this approach. And AFAIK there's no non-modifying solution to overcome this.

"The other restrictions already in place in our Z-program unfortunately need line item related data from EKPO, MARA and MARC which is retrieved with a SELECT...ENDSELCT construct and sets a deletion flag to delete entries from internal XEKKO if none of the line-items fits the selection-criteria. This logic is currently included in the middle of START-OF-SELECTION. And it's the place in the code where I'd need to apply the change if we keep doing this as we did before.

And then there's also the rather involved additional check logic applied in our Z-program via which releases are rejected due to some involved determinations."

I think it should be possible to reimplement that logic in the above mentioned places. At least as far I understood.

Cheers Christian

[BaerbelWinkler · Accepted solution]

christian.guenter

Hi Christian,

here is an update about our deliberations. After looking at your suggestion and what we have already implemented in another system making use of the BaDI, we concluded that it would be a fairly large effort to go that way in this case. Had we only been faced with the task to restrict the selection further, we may have gone down that route, but because we also have fairly involved other logic in the Z-program which couldn't easily - if at all - be moved into the BaDI implementation, we decided against using it.

As an aside: a colleague hunted down the most likely place, where the decision of which output to use gets made:

In LMEREPI06

    re_category = c_cat_unsupported.<br>
    CASE im_service.<br>

....

  * purchasing documents - release<br>      WHEN 'RM06EF00'.<br>        re_category = c_cat_purchdoc_rel.

So, given that SAP works with literals for IM_SERVICE there, not much of a chance to influence the behaviour from outside all of this logic.

Thanks much again for your feedback which I'm sure will be helpful for others even if we won't make use of it for our particular issue!

Cheers

Bärbel