发现有两个HR的后台定时任务出现dump，日志表示，是PYXX_READ_PAYROLL_RESULT产生了类型冲突的异常CX_SY_DYN_CALL_ILLEGAL_TYPE。
日志标题部分：
类别 ABAP 编程错误
运行时错误 PERFORM_CONFLICT_TYPE
异常 CX_SY_DYN_CALL_ILLEGAL_TYPE
ABAP 程序 SAPLHRPAY99_IMPEXP
应用程序组件 PY-XX
错误分析文本：
An exception has occurred which is explained in more detail below. The exception is assigned to class 'CX_SY_DYN_CALL_ILLEGAL_TYPE' and was no caught in procedure "PYXX_READ_PAYROLL_RESULT" "(FUNCTION)", nor was it propagated by a RAISING clause. Since the caller of the procedure could not have anticipated this exception, the current program was terminated. The reason for the exception is: The FORM call "IMPORT_RESULT" is incorrect: The actual parameter (number 2) has a different data type in the PERFORM than requested by FORM "IMPORT_RESULT" in program "%_T000VU".
代码行：
PERFORM import_result IN PROGRAM (subroutine_pool-name)
USING key
payroll_result "第二个参数
import_subrc
pcl2_version_number
typepool_version_number
IF FOUND.
函数PYXX_READ_PAYROLL_RESULT是一个用于获取工资的函数。在Google搜索了半天，不得解法。查阅函数文档，可以得知：
You can use this module to generically read a complete payroll result, that is for all country versions, from file PCL2 or from the puffer. In doing so, the payroll result is transferred to the PAYROLL_RESULT parameter. In the calling system, this must be classified as a complex structure according to the 'PAYxx_RESULT' dictionary structure. xx is the ISO code for the country in question (Exception: for the international part only, use PAY99_RESULT).
原来，PAYROLL_RESULT参数是动态类型的。问题发生在，最初的开发者只考虑了clusterid为"CN"即中国时的情况，把它定义为PAYCN_RESULT类型。而当系统推广到海外的时候，CN的结构类型已经不再使用，程序应当使用不同的结构来接收输出结果。
比如，当输入参数中的clusterid = 'RG'（英国）时，就应当定义参数payroll_result参数的类型为PAYGB_RESULT，这样就不会产生类型冲突的错误了。
看来有时候文档比Google更加直接有效。我们不应该因为文档的阅读难度而放弃查阅...如果有搜索到本文的读者，请和我一起记住这个教训:)
2018.06.27补充：对于有多个国家的工资核算结果的情况，可以从表t52relid获得相应的PAYROLL_RESULT参数类型，通过定义通用类型的方式解决问题，参考该问答：Is there any suitable function module to retrive cluster TCRT and CRT data