Skip to Content
author's profile photo Former Member
Former Member

Problem with PARAMETERS in report.

Hi,

I have made a report that should update ZASS (Cost Price).

Anyway:

I have filled the i_condtab correctly but when I use

parameter: p_file(100) type c obligatory.

then I get a error message in i_errortab telling me:

"Object & of class & and language & does not exist".

call function 'Z_GUI_CONDITION_SAVE_ZASS'

tables

i_cond = i_condtab

i_error = i_errortab.

Why does it seem to have problem with parameters?

PS. Another report is als using the function 'Z_GUI_CONDITION_SAVE_ZASS with PARAMETERS and with no problem...

//MA

Add a comment
10|10000 characters needed characters exceeded

Assigned Tags

Related questions

4 Answers

  • Best Answer
    author's profile photo Former Member
    Former Member
    Posted on Jan 28, 2005 at 09:08 AM

    Martin,

    The problem with the code is NOT in this code.

    However to understand what happens you must be aware of ONE difference between having parameters (or select options) inside a program or not.

    When you have them, SAP generates a screen (selection-screen) for it.

    Now i asume that inside the function module 'Z_GUI_CONDITION_SAVE_ZASS' there is a reference to a screen (maybe dynamically). Most likely by using parameters the expected reference is not there and it is replaced by a reference to your selection screen.

    Since such a selection screen is not known to the object (in fm Z_GUI_CONDITION_SAVE) the error for a missing object is given. If i interpret the name of function module, i assume that it is used to save certain information of a screen dynamically. Your selection screen will not be one of them.

    So as previous gents have suggested, we really would like to know what's inside that function module. But maybe this gives you a clue on the matter.

    Regards,

    Rob.

    Add a comment
    10|10000 characters needed characters exceeded

    • Former Member Former Member

      Hello Martin,

      You have said in your earlier replies that you use the PARAMETERS <i>later on</i>. So I had assumed that you do not need them for this FM.

      Just thought of a few more things that you could try out...

      1. Call the Z-Function in the event AT SELECTION-SCREEN, instead of in Start-OF-Selection.

      2. Try to use a normal screen instead of a selection-screen. This should be fairly easy as long as you do not have any SELECT-OPTIONS on your selection screen. But even if you do, it requires only a little amount of coding.

      Regards,

      Anand Mandalika.

  • Posted on Jan 27, 2005 at 12:31 PM

    Hi Martin,

    How we 'd help you ?- you're talking about <b>Customer</b> functions and tables (<b>Z</b>_) !

    -> so the only chance is to debug the fm 'Z_GUI_CONDITION_SAVE_ZASS' .

    e.g. set an watch-point to a field of i_errortab.

    regards Andreas

    Add a comment
    10|10000 characters needed characters exceeded

  • author's profile photo Former Member
    Former Member
    Posted on Jan 28, 2005 at 11:28 AM

    Hi Martin,

    I'm a bit blind, but the next would help too.

    The error 616 from errorclass SF is solely used by the following program objects:

    Function module DOKU_OBJECT_EXIST (Used in CATT and in development class SLDBV),

    Function module DSYS_SHOW (consequetive usage),

    Function module DSYS_EXIST (consequetive usage),

    Program SAPLDSYK.

    Actually the error occurs, because of a program/function/screen/... object NO entry was found in table DOKIL (index of DOKHL) or DOKHL (documents). Whenever we create objects, we also create some documentation when we enter descriptions and so (that's why SAP always requires you to fill the description).

    Now to your problem (the example with GUI_UPLOAD did help a bit).

    Most likely an object reference to a screen is required somewhere inside Z_GUI_CONDITION_SAVE. Most likely this reference is picked up dynamically in Z_GUI_CONDITION_SAVE and it is picked from the active screen (propably using a form of C function).

    When using such a function it can lead to these kind of problems. Inside the GUI_UPLOAD also C functions are called:

    DATA: OCX_SUPPORT TYPE I, ITS_SUPPORT TYPE I, RETURN.

    CLEAR RETURN.

    CALL 'C_GUI_SUPPORT'

    ID 'FEATURE' FIELD 'OCX_SUPPORT'

    ID 'VALUE' FIELD OCX_SUPPORT.

    IF OCX_SUPPORT = 1.

    CALL 'C_GUI_SUPPORT'

    ID 'FEATURE' FIELD 'ITS'

    ID 'VALUE' FIELD ITS_SUPPORT.

    IF ITS_SUPPORT = 1.

    RETURN = 'X'.

    ENDIF.

    ENDIF.

    You should test if the above code is sufficient as REPLACEMENT for your GUI_UPLOAD alternative. However i think it is not, because most likely the previous programmer has dicovered a way to obtain the last screen dynamically and uses it to do whatever needs to be done.

    As you can see, the problem is NOT in the code you show us, but in the code of Z_GUI_CONDITION_SAVE.

    It might be very large, but we ONLY need the calls of function modules, of methods and of direct C-Calls. Please provide that information or i am unable to help you (since i'm now in the area of guessing what might all be wrong).

    Regards,

    Rob.

    Add a comment
    10|10000 characters needed characters exceeded

  • author's profile photo Former Member
    Former Member
    Posted on Jan 28, 2005 at 04:02 PM

    Martin,

    Now i understand.

    The function module Z_GUI_CONDITION_SAVE is using a function module that actually is build to handle inbound IDoc's of type COND_A01 and COND_A02.

    The input and output parameters of IDOC_INPUT_COND_A are standardized and are used in the ALE layer of SAP, actually connected to a partner (transaction WE20) and in there connected to an inbound message and in there connected to an operation code (transaction WE42) an in the operation code this function module is set up.

    In such a way automatic IDoc inbound handling can be set up.

    Now that is the normal proces and your function module Z_GUI_CONDITION_SAVE does try to do the same. Internally for handling IDoc types COND_A01 and COND_A02 what SAP really does is to call the various transaction related to updating conditions in the system.

    Such a call is ALLWAYS a dialog call and there this posses a problem. If by any chance your supplied data contains invalid or incomplete data, those transactions will generate either errors or warnings. Also i believe that updating condition records also calls dialog screens.

    Now i'm no expert in condition records so the following is an assumption:

    If updating condition records calls a dialog screen, where more details must be supplied AND the calling program simply call the internal stack to find out what data was entered on that dialog screen, your problem is then caused by the fact, that your selection screen takes the place of the dialog screen.

    No how to resolve this.

    - First make sure that there is a distinct difference between PBO and PAI handling in your report. So just before calling function Z_GUI_CONDITION_SAVE you put: END-OF-SELECTION.

    - Get rid of the GUI_UPLOAD (in your example).

    - Modify the Z_GUI_CONDITION_SAVE program by changing the way IDOC_INPUT_COND_A is called:

    CALL FUNCTION 'IDOC_INPUT_COND_A'

    DESTINATION 'NONE'

    EXPORTING ...

    IMPORTING ...

    TABLES ...

    EXCEPTIONS

    COMMUNICATION_FAILURE = 1 MESSAGE MSG_TEXT

    SYSTEM_FAILURE = 2 MESSAGE MSG_TEXT

    WRONG_FUNCTION_CALLED = 3

    OTHERS = 4.

    What does this do? This will call the specific IDoc function module in it's own program context and thus preventing the problem.

    Regards,

    Rob.

    Add a comment
    10|10000 characters needed characters exceeded

    • Former Member Former Member

      Hi Martin,

      Yes it is possible that the update does not take place.

      You then need to ADD a 'COMMIT WORK' (or 'COMMIT WORK AND WAIT' if you need to check the data directly after the call) in to the Z_GUI_CONDITION_SAVE function module.

      If that is not possible (because other program's might have trouble with that), simply write a wrapper function module (with RFC flag enabled) that will call internally the Z_GUI_CONDITION_SAVE and after finish do the commit work there.

      Regards,

      Rob.

Before answering

You should only submit an answer when you are proposing a solution to the poster's problem. If you want the poster to clarify the question or provide more information, please leave a comment instead, requesting additional details. When answering, please include specifics, such as step-by-step instructions, context for the solution, and links to useful resources. Also, please make sure that you answer complies with our Rules of Engagement.
You must be Logged in to submit an answer.

Up to 10 attachments (including images) can be used with a maximum of 1.0 MB each and 10.5 MB total.