问题描述：

在使用F-53进行供应商付款清账操作时，模拟凭证（包括保存凭证）时出现如下的ABAP Down错误：

问题分析：

从报错内容看，我们首先看到报错的程序为SAPMF05A，这个程序财务顾问都熟悉，是财务模块的主程序，大部分的财务过账（如F-02）操作都是调用的这个程序。

另外，就是报错的原因是因为index小于等于0了，这对于数据库来说是不允许的，因为index只能大于0。

关于SAPMF05A这个程序，我们可以使用SE80查看开发对象，截图如下：

在这里我们也能看到这个程序会被哪些使用代码用到，如下图：

反过来，我们也可以通过SE93或者执行事务代码时来查看对应的程序，比如SE93查看F-02所对应的程序：

下图则是通过执行事务代码F-02，对任意一个字段按F1按钮，再点击“技术信息”按钮，从而查看事务代码所使用的程序。

接下来，我们通过ST22再进行分析，转到具体的程序代码，如下图操作：

这里看到了具体的程序行和程序名。

在这里相应的位置打断点，并继续操作F-53进行debug时，发现是因为内表kontab的索引index变为0导致的错误，而index的值来源于变量i，而变量i则是由ld_tabix-1得到的，ld_tabix来源于系统的索引值sy-tabix。

我们再找sy-tabix为何变为1，这个时候的思路是找一个没有报错的系统对比进行debug，比较在不同的系统里内表kontab的数据是否有不一致的地方。

第一个图是没有发生错误的系统内表kontab的值，第二个图则是有错误的系统内表kontab的值，再debug发现，对于无错误的系统，在对内表kontab执行loop循环时，因为kontab-shkzg（借贷方）为H，就直接结束了第一次循环，第二次循环时，sy-tabix（系统索引）已经变为了2，再减1变为了1，就不会出现索引为0的情况了。

那接下来就是看kontab的数据来源于哪里了，为什么到了这里字段kontab-shkzg为空了。

通过在主程序中搜索。

我们发现内表kontab是由postab赋值的，如下图：

通过上图发现，有一个增强（S4H900878是增强产生的请求号）把字段shkzg的赋值代码给注释掉了。这样终于找到了最终的原因。

然后通过SE01查看请求号S4H900878，发现是在今年2月5号做的一个增强。

总结：最近发现年纪大了，反而更想钻研技术了，说到底，程序还是一堆堆代码组成的，如果我们想用系统解决业务问题，对代码以及底层程序逻辑的理解是不可或缺的，不过这个时候查找程序的速度快了很多，这个过程和刚开始接触系统的时候去看程序有所不同，此时看系统代码会结合业务，更多的去研究系统的设计思路。毕竟不是专业的开发人员，这个过程写出来大家看到没多少时间，实际花费了2个多小时才搞定。标准程序还是尽量少写增强吧，一个是影响面太广，一旦出问题，就是比较大的问题，另外是出现问题也不好排查，基本就是靠debug（或者有比较完备的文档）去发现，然后去调整。