Function Module Input Change

[Former Member]

Hello,

        I am presently working on a function module where the input of the existing function module was only one material number, but the current requirement is to create a new function module which would replicate the features of the existing FM and at the same time, should take more than one ( say maximum100 values ) value as input.

       One option would be to collect the user's input in the form of a table i.e T_MATNR instead of I_MATNR which used to take only 1 value as input. To support this, all the functions, read statements, move statements would have to be looped where every value of T_MATNR is fetched into the existing I_MATNR field. This reduces the code change which is generally required, but I was wondering what would be the performance impact of implementing something like this?

       Is there any other way to implement this requirement without actually using loops?

  Any pointers on this would be appreciated.

Thanks & Regards,

Alice D' Souza.

[wa_ramaekers]

Hello Alice,

I am afraid at some point you will have to use a loop, this should not be to bad for the performance if you don't do any selections on the database.

If you have to address the database I would suggest you use a range for matnr (e.g. ranges_matnr a table type) .  You can use this range as a select-option in your sql statements. So first collect all data into internal tables and than do the loops for processing the data. Take into consideration using field-symbols instead of workareas.

I hope this answer helps a little bit.

Kind Regards,

Wiel Ramaekers

[Former Member]

Hi Alice,

Are u fetching any data from table based on MATNR value?

If yes then do not put the select query inside Loop. I would suggest to select all data before loop and then read it inside loop.

Regards,

Sudeesh Soni

[Former Member]

Hello Alice,

loops entail generally negative impacts performance, but in your case (max. 100 values) there is no problem to use them.

I would appreciate somthing like a MOVE TO or a READ INTO statement.

Regards,

Alexander

[matt]

If you proceed as follows, you won't have to change any code that calls the function module already.

Change your i_matnr (single material number) to be optional. Add another optional parameter of i_matnrs, which is an internal table of material numbers.

Define an internal table (materials) in your function module of type internal table of material numbers. Insert this code at the start of your function module.

IF i_matnr IS NOT INITIAL.

  INSERT i_matnr INTO TABLE materials.

ELSE.

  materials = i_matnrs.

ENDIF.

Modify the rest of the code so that it efficiently works with materials, instead of the single i_matnr. Without seeing that code, it's impossible to say whether you'll need to loop, or if their are bulk table options.

[Former Member]

Yes, Matthew. I was considering of doing something similar to this. Most of the code which is present in the existing function module looks something like this.

1. SELECT SINGLE *

    FROM mara

    INTO CORRESPONDING FIELDS OF t_tableone

   WHERE matnr EQ i_matnr.

2.  MOVE i_matnr TO t_tableone-matnr.

    APPEND t_tableone.

3. SELECT SINGLE zsomething

    FROM somethingelsetable

    INTO e_template

   WHERE matnr EQ i_matnr.

4. CALL FUNCTION 'SOMETHING'

    EXPORTING

      p_matnr_in    = i_matnr

    IMPORTING

     ,,,

     ...

5.   SELECT *

      FROM marm                                         

      INTO CORRESPONDING FIELDS OF TABLE t_tabletwo        

     WHERE matnr EQ i_matnr.

6.  READ TABLE t_tabletwo WITH KEY matnr = i_matnr           

                                                         meinh = something              

       BINARY SEARCH.

7.  SELECT A

    FROM mast

    INTO t_sthg

      UP TO 1 ROWS

   WHERE matnr EQ i_matnr

     AND werks EQ space

     AND sthg EQ somevalue

     AND sthg EQ somevalue

  ENDSELECT.

8.

CALL FUNCTION 'SOMETHING'

          EXPORTING

            i_matnr                    = e_structure-somefield

            i_sthg                      = e_structure-somefield

            i_sthg                      = e_structure-somefield

            IMPORTING

            .....

            .....

9.

MOVE:     t_something-somefield TO t_something-somefield,

               t_something-somefield TO t_usomething-somefield,
                i_matnr            TO t_something-matnr.

                APPEND t_something.

I see that in some of these cases, esp in SELECT statements, we can replace EQ with IN to make sure that we can accommodate all the material numbers. Is this a correct way to proceed for SELECT statements?

Also, I observe that loop is inevitable in a few places of code, would this impact the performace greatly?

I have given a few snippets of how the existing function module looks like, could you guide me on how the changes in the 9 points mentioned can be implemented in the enhanced FM considering the increase in material numbers which are provided as input.

Any pointers on these will be greatly appreciated.

Regards,

Alice. 

[matt]

Definitely bundle up the selects to "select into table". You should also think about how you can maybe utilise some INNER JOINS so that you can get most of the data you need in one select.

You may have to refactor the logic to get the data processed optimally.

Also...

Don't use a table, sort it, then read with BINARY SEARCH - use a SORTED (or better) a HASHED table. These kinds of tables have only been part of the ABAP language for 14 years, but for some reason people don't like to use them.

Don't use SELECT ... UP TO 1 ROWS. It's pointless and needlessly complex. The SQL optimizer changes it to a SELECT SINGLE.

[Former Member]

Hello Matthew,

              When I create the new FM, I would like to know how and where I could declare the T_MATNR ( table of input material numbers ) or i_matnrs ( which should take more than 1 matnr as input ). The current FM has an import parameter I_MATNR LIKE MARA-MATNR.

               I would want the user to input many more MATNR's at the same time when they are executing the FM.

• One, can I somehow include this in the list of import parameters which would provide such an option? Like a parameter which is an internal table of material numbers. ( If ok, where can I declare this and how should I declare this as, so that the code reuse is maximum? ) Is this even possible?
• Or can I declare this directly as T_MATNR in the "tables" tab of the FM. This should be a type of ( MARA- MATNR, if I am not wrong) But what extra do I have to do so that it can take several inputs on the FM execution screen when I run it?

[matt]

I suggest you research data dictionary table types. For most purposes it's better to use those as IMPORTING/EXPORTING/CHANGING function module parameters than using TABLEs parameter with a flat type.

[Former Member]

I was considering of doing something similar to this. Most of the code which is present in the existing function module looks something like this. 

1. SELECT SINGLE *

    FROM mara

    INTO CORRESPONDING FIELDS OF t_tableone

   WHERE matnr EQ i_matnr.

2.  MOVE i_matnr TO t_tableone-matnr.

    APPEND t_tableone.

3. SELECT SINGLE zsomething

    FROM somethingelsetable

    INTO e_template

   WHERE matnr EQ i_matnr.

4. CALL FUNCTION 'SOMETHING'

    EXPORTING

      p_matnr_in    = i_matnr

    IMPORTING

     ,,,

     ...

5.   SELECT *

      FROM marm                                         

      INTO CORRESPONDING FIELDS OF TABLE t_tabletwo        

     WHERE matnr EQ i_matnr.

6.  READ TABLE t_tabletwo WITH KEY matnr = i_matnr           

                                                         meinh = something              

       BINARY SEARCH.

7.  SELECT A

    FROM mast

    INTO t_sthg

      UP TO 1 ROWS

   WHERE matnr EQ i_matnr

     AND werks EQ space

     AND sthg EQ somevalue

     AND sthg EQ somevalue

  ENDSELECT.

8.

CALL FUNCTION 'SOMETHING'

          EXPORTING

            i_matnr                    = e_structure-somefield

            i_sthg                      = e_structure-somefield

            i_sthg                      = e_structure-somefield

            IMPORTING

            .....

            .....

9.

MOVE:     t_something-somefield TO t_something-somefield,

               t_something-somefield TO t_usomething-somefield,
                i_matnr            TO t_something-matnr.

                APPEND t_something.

I see that in some of these cases, esp in SELECT statements, we can replace EQ with IN to make sure that we can accommodate all the material numbers. Is this a correct way to proceed for SELECT statements?

Also, I observe that loop is inevitable in a few places of code, would this impact the performace greatly?

I have given a few snippets of how the existing function module looks like, could you guide me on how the changes in the 9 points mentioned can be implemented in the enhanced FM considering the increase in material numbers which are provided as input.

Any pointers on these will be greatly appreciated.

Regards,

Alice. 

[Former Member]

Hello all,

          I was wondering if I could get some input on this:

              When I create the new FM, I would like to know how and where I could declare the T_MATNR ( table of input material numbers ) or i_matnrs ( which should take more than 1 matnr as input ). The current FM has an import parameter I_MATNR LIKE MARA-MATNR.

               I would want the user to input many more MATNR's at the same time when they are executing the FM.

• One, can I somehow include this in the list of import parameters which would provide such an option? Like a parameter which is an internal table of material numbers. ( If ok, where can I declare this and how should I declare this as, so that the code reuse is maximum? ) Is this even possible?
• Or can I declare this directly as T_MATNR in the "tables" tab of the FM. This should be a type of ( MARA- MATNR, if I am not wrong) But what extra do I have to do so that it can take several inputs on the FM execution screen when I run it?

[Former Member]

I'm posting MB1A when I'm getting error is posting only possible in periods 2006/12 and 2006/11 in company code 1000. give me suggestion...

Regards

Rajesh

[Mohamed_Mukhtar]

Hello Rajesh,

This error is because of posting periods are not opened for current period.Check the posting periods in MMRV and open it.

Thanks