Problem with PARAMETERS in report.

[Former Member]

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

[andreas_mann3]

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

[Former Member]

Hi,

Let me provide you with an full example:

REPORT ZIMPORT_CONDITIONS_ZASS_3.

*parameter: p_nada(100) type c obligatory default 'TEST'.

data: wa_cond type zgui_condition.

data: i_condTab type table of zgui_condition with header line.

data: i_errorTab type table of zgui_cond_error with header line.

START-OF-SELECTION.

wa_cond-KSCHL = 'ZASS'.

wa_cond-VKORG = 3000.

wa_cond-WERKS = 3100.

wa_cond-MATNR = '000000000000150062'.

wa_cond-CURCY = 'NOK'.

wa_cond-PRICE = '1.38'.

wa_cond-DATAB = sy-datum.

wa_cond-DATBI = '99991231'.

append wa_cond to i_condtab.

clear wa_cond.

call function 'Z_GUI_CONDITION_SAVE_ZASS'

tables

i_cond = i_condtab

i_error = i_errortab.

loop at i_errortab.

write: / i_errortab-matnr,

i_errortab-status(200).

endloop.

write: 'DONE'.

So.... if I uncomment the parameters line the it will give me an error in the i_errortab. The update still works but it's not nice to have this error message.

Any ideas ?

//Martin

[Former Member]

Hello Martin,

I really doubt if your issue can ever be totally understood, because as Andreas had mentioned, you are working only with custom objects. None of the FMs, structures and Tables would be available in our system.

But I guess we make some guesses...

1. Why do you want to have the parameters when you don't seem to be using it anyways?

2. Is the FM <b>Z_GUI_CONDITION_SAVE_ZASS</b> RFC enabled? If not, then why don't you have the EXCEPTIONS ?

3. What is the code of the FM <b>Z_GUI_CONDITION_SAVE_ZASS</b>?

Regards,

Anand Mandalika.

[Former Member]

Hi,

Yes, this is a Customer Function (some consultats did this some time ago... now it's my turn to reuse this function.)

1. I use the parameters later on.

I just can't understand why it doesn't work with the parameter stuff...

Is it possible that some coding inside the Z_GUI_CONDITION_SAVE_ZASS freaks out if I use parameters in my report.... sounds strange...

//Martin

//MA

[Former Member]

Hi,

It is beyond my imagination why the FM would fail when you use the parameters statement. And that when you do not even use the value of the PARAMETERS in the FM call.

Is the code of the FM too big to post here ? If it isn't, then we might try to see what's wrong...

Regards,

Anand Mandalika.

[RichHeilman]

What is the code in the function module.

Regards,

Rich Heilman

[Former Member]

Sorry, It's just too big to be posted.

Maybe I can fix this in some other way...it's so very strange problem here.....

//Martin

[Former Member]

Hi Martin,

It is always difficult to diognize a custom program unless the code is there.

But let me try a couple of things here.

What is your parameter for? I don't see any line to tell how it is used to call the function module.

The first thing I will check in this situation is if the your parameter data is converted into external or internal format(depending on whether the Z function call expects it in external or internal). Because when you fill in the i_condtab in your code, you are using the internal format of material code, but I don't know if that is the same way when you are uploading the file and the file has material number in external format.

Please verify that and let me know if I am on the right track.

Srinivas

[Former Member]

Hi Martin.

I'm just trying to catch up here on the post.

Have you tried going through with the debugger to see where exactly the error is coming up in 'Z_GUI_CONDITION_SAVE_ZASS'?

If you comment out the function call giving you the error and uncomment the parameter call will you still get that error?

[ChristianFi]

Considering the errormessage I would assume that a message is populated within the function module which is not maintained properly in table T100.

At least this is what I get from class & language does not exist.

Christian

[Former Member]

Gentlemen,

I found something.

(The function module reads error log from T001... but it not its fault.)

Setting the breakpoint at the very first line in my report and type this:

sy-msgid --> SF

sy-msgno --> 616

sooo... what does this mean ?

Why is the report giving these kind of errors when having this FM in my code ?

//Martin

[ChristianFi]

If you look in table T100 you will find the message you have described in your previous email.

Have you checked if there are message statements in the function module and if they are maintained?

Christian

[Former Member]

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.

[Former Member]

Gentlemen.

Rob, you are on something here...

Parameters work if i first call FM = 'GUI_UPLOAD'

But if I comment the GUI_UPLOAD then I will get an error again....

//Martin

REPORT ZIMPORT_CONDITIONS_ZASS_3.

parameter: p_file(100) type c obligatory default '
ma\ma\ma_test.txt'.

data: begin of i_ascii occurs 0,

line(250) type c,

end of i_ascii.

data: wa_cond type zgui_condition.

data: i_condTab type table of zgui_condition with header line.

data: i_errorTab type table of zgui_cond_error with header line.

data: l_price type MBEW-VERPR.

data:l_file type string.

l_file = p_file.

START-OF-SELECTION.

wa_cond-KSCHL = 'ZASS'.

wa_cond-VKORG = 3000.

wa_cond-WERKS = 3100.

wa_cond-MATNR = '000000000000150062'.

wa_cond-CURCY = 'NOK'.

wa_cond-PRICE = '1.38'.

wa_cond-DATAB = sy-datum.

wa_cond-DATBI = '99991231'.

append wa_cond to i_condtab.

clear wa_cond.

• Get file

call function 'GUI_UPLOAD'

exporting

filename = l_file

tables

data_tab = i_ascii

exceptions

file_open_error = 1

file_read_error = 2

no_batch = 3

gui_refuse_filetransfer = 4

invalid_type = 5

no_authority = 6

unknown_error = 7

bad_data_format = 8

header_not_allowed = 9

separator_not_allowed = 10

header_too_long = 11

unknown_dp_error = 12

access_denied = 13

dp_out_of_memory = 14

disk_full = 15

dp_timeout = 16

others = 17.

.

call function 'Z_GUI_CONDITION_SAVE'

tables

i_cond = i_condtab

i_error = i_errortab.

loop at i_errortab.

write: / i_errortab-matnr,

i_errortab-status(200).

endloop.

write: 'DONE'.

[Former Member]

Hello Martin,

Albeit silly, there's one idea that I've got. Just see if it makes sense.

REPORT ZIMPORT_CONDITIONS_ZASS_3.
parameter: p_file(100) type c obligatory default '\mamama_test.txt'.

data flag_first_time type flag value 'X'.

at selection-screen output.
  if flag_first_time eq 'X'.
    clear flag_first_time.
    perform condition_save.
  endif.  


START-OF-SELECTION.


FORM CONDITION_SAVE.

  data: wa_cond type zgui_condition,
        i_condTab type table of zgui_condition with header line,
        i_errorTab type table of zgui_cond_error with header line.
        
  wa_cond-KSCHL = 'ZASS'.
  wa_cond-VKORG = 3000.
  wa_cond-WERKS = 3100.
  wa_cond-MATNR = '000000000000150062'.
  wa_cond-CURCY = 'NOK'.
  wa_cond-PRICE = '1.38'.
  wa_cond-DATAB = sy-datum.
  wa_cond-DATBI = '99991231'.
  
  append wa_cond to i_condtab.
  clear wa_cond.
  
  call function 'Z_GUI_CONDITION_SAVE'
  tables
  i_cond = i_condtab
  i_error = i_errortab.
  
  loop at i_errortab.
    write: / i_errortab-matnr,
    i_errortab-status(200).
  endloop.

ENDFORM.

I knwo this is a work-around kind of solution, but since we are unable to see the code of the Function M<odule, I guess this code would solve your problem. If it is solved, don't forget clicking the Yellow Star for all those who tried to help you.

Regards,

Anand Mandalika.

[Former Member]

Hello,

It doesn't give me an error any more

But .... in the real report I need the values from the PARAMETERS.

Now It seems to run before the selection screen is shown..

//Martin

[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.

[Former Member]

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.

[Former Member]

Rob, your code didn't work.

Provide you with some code...

//Martin

function z_gui_condition_save.

perform check_data tables i_cond. "* Cleanup data

loop at i_cond.

refresh: i_edidc,

i_edidd.

perform build_idoc_edidc tables i_edidc. " * Build iDoc control record

perform build_idoc_edidd tables i_edidd " * Build iDoc data records

i_cond.

perform process_idoc tables i_edidc " * Process iDoc

i_edidd

i_cond

i_error.

endloop.

endfunction.

*******

form process_idoc tables i_edidc structure edidc

i_edidd structure edidd

i_cond structure zgui_condition

i_error structure zgui_cond_error.

data:

l_input like bdwfap_par-inputmethd,

l_mass like bdwfap_par-mass_proc,

l_result like bdwf_param-result,

l_appvar like bdwf_param-appl_var,

l_update like bdwfap_par-updatetask,

l_call like bdwfap_par-calltrans,

i_edids like edids occurs 0 with header line,

i_return like bdwfretvar occurs 0 with header line,

i_serial like bdi_ser occurs 0 with header line.

• Call iDoc inbound processing

call function 'IDOC_INPUT_COND_A'

exporting

input_method = l_input

mass_processing = l_mass

importing

workflow_result = l_result

application_variable = l_appvar

in_update_task = l_update

call_transaction_done = l_call

tables

idoc_contrl = i_edidc

idoc_data = i_edidd

idoc_status = i_edids

return_variables = i_return

serialization_info = i_serial

exceptions

wrong_function_called = 1

others = 2.

• Get message

select single *

from t100

into corresponding fields of t100

where sprsl eq sy-langu

and arbgb eq sy-msgid

and msgnr eq sy-msgno.

check sy-subrc eq 0.

• Update error table

move-corresponding i_cond to i_error.

i_error-status = t100-text.

append i_error.

clear i_error.

endform. " process_idoc

[Former Member]

Did the suggestions mentioned not work either?

[Former Member]

Sorry, I don't have any idea why this would happen.

But if this helps, when I run into these kinds of things I usually start tracing through the program until I hit the part of the code producing the error and see if that shines a light on anything.

Also, Is that function called anywhere else in any other programs that work correctly? Specifically looking for ones that use parameters? That's something else I would try - see if I could find an already working example and go from there.

[Former Member]

Oh yes, that's a good idea - to look for the programs where this FM <i>does</i> work <i>without problems</i>.

You must certainly try that out...

[nablan_umar]

Reading thru all this thread, I think the error comes from function module 'IDOC_INPUT_COND_A'. You probably populated wrongly the parameters that you pass to this function module.

[Former Member]

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.

[Former Member]

That a shiny solution, Rob.

Just out of curiosity, it's possible the function Z_GUI_CONDITION_SAVE is used by other programs. Would that fix you are recommending affect them?

[Former Member]

Hi Jason,

No it would not. It is only intended to let the program run in it's own workspace (and thus not see other screens from either caller or other processes).

Regards,

Rob.

[Former Member]

Rob,

The Error disappear. But now it will not update my ZASS condition any more.

There is no error in IDOC_INPUT_COND_A.

There is no error at all!

//Martin

Message was edited by: Martin Andersson

[Former Member]

Hello Martin,

Just to remind you, you have been getting quite a lot of replies to your query, which means that a lot people are trying to solve your problem. Could be kind enough to reward them for their effots by clicking the Yellow Start for the answers that have helped you ?

Regards,

Anand Mandalika.

[Former Member]

Have you traced through the program to the point of the update to see what's going on?

Is the data you are passing into the function correct/complete?

[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.