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 ip_date
.
So how do I pinpoint the issue?
CALL FUNCTION gv_formname
EXPORTING
* 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
* IMPORTING
* DOCUMENT_OUTPUT_INFO =
* JOB_OUTPUT_INFO =
* JOB_OUTPUT_OPTIONS =
EXCEPTIONS
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.
ENDIF.
Why is the program causing a dump when Others exception should have handled this error?
Issue is with p_amt
field.
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 p_amt
?
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.