I have a ABAP Function Module that calls a Smart Form.
It passes variables to the Smart Form interface parameters.
I suspect while passing parameters one of the parameter - date or amount - is passing in the wrong format.
When I run the program (F8) with the debugger, the Smart Form interface page opens, I fill the values and on hitting F8 the program crashes - Program Terminated.
System does not show any exceptions or any hints to why the program failed.
The Function Module has an Exception, surprisingly it's not raised.
Looks like the error is while passing
ip_amt variable or
So how do I pinpoint the issue?
CALL FUNCTION gv_formname
* ARCHIVE_INDEX =
* ARCHIVE_INDEX_TAB =
* ARCHIVE_PARAMETERS =
CONTROL_PARAMETERS = gv_control_parameters
* MAIL_APPL_OBJ =
* MAIL_RECIPIENT =
* MAIL_SENDER =
OUTPUT_OPTIONS = gv_output_options
USER_SETTINGS = 'X'
IP_NAME = ip_name
IP_CDATE = ip_cdate
IP_AMOUNT = ip_amt
* DOCUMENT_OUTPUT_INFO =
* JOB_OUTPUT_INFO =
* JOB_OUTPUT_OPTIONS =
FORMATTING_ERROR = 1
INTERNAL_ERROR = 2
SEND_ERROR = 3
USER_CANCELED = 4
OTHERS = 5
IF sy-subrc <> 0.
MESSAGE ID SY-MSGID TYPE SY-MSGTY NUMBER SY-MSGNO
WITH SY-MSGV1 SY-MSGV2 SY-MSGV3 SY-MSGV4.
Why is the program causing a dump when Others exception should have handled this error?
Issue is with
ip_amt TYPE PC207-BETRG.
p_amt is a packed decimal field and entering numbers like 1,00 or 1.00 or 1 terminates in an error.
What kind of number format is the system expecting for
The amount parameter in smartform and program calling smartform having same type: PC207-BETRG. Still the system is causing a type mismatch while FM call. Why?
The type of runtime error,
CALL_FUNCTION_CONFLICT_TYPE, is a pretty good hint at what could be the problem.
It means that one of the variables (or literals) you use as parameters in your
CALL FUNCTION is not the same type as declared for the parameter of the function module. The type safety of function module parameters can not be checked at activation time, because not even the name of the function module is known at activation time. So the check has to happen at runtime.
In this case, the runtime error says that one of them is a
P LENGTH 8 while the other is a
P LENGTH 7. No, these are not convertible to each other in the context of a function call. Function calls are very picky about type safety. So check which type is used for that parameter in the interface of your print form, and make sure that the variable in the program is of the exact same type. The best strategy is usually to copy&paste the type from the interface declaration of the SMARTFORM to the DATA statement in your program. If you don't have control over the
DATA ip_amt declaration, then a workaround can be to declare a local variable of the same type as the
IP_AMOUNT import parameter, copy the value of
ip_amt to that local variable, and use the local variable as the function module parameter (simple copy operations are a lot laxer than function call parameters).
For why the function module doesn't just raise a
sy-subrc exception code in this case: That's because it's too early for that. Exceptions can only be risen during the execution of the function module (via the
RAISE keyword). But this error condition here occurs because it's not even possible to call the function module in the first place.