比如一次维护过程中，客户方发现了一次大问题，系统执行成品标准标准更新时，出现异常的WIP 标准成本调整差异，发生的总额约1000多万。其症状也是让人莫明其妙：

1）物料为当时已完工的但未关闭的任务上的装配件。
2）物料更新前的标准成本与冻结成本一致，更新后系统新的冻结成本也未发生变化。按照系统的原理，此时不应该出现成本更新差异。物料更新前的标准成本与冻结成本不一致的，出现成本更新差异也不是正常更新前后的差额。
3）任务上发生的更新差异，有相当于将成品装配件成本从零成本更新到现有成本时的差异，有的将成品装配件成本从现有成本时更新到零成本的差异，也有数据为（旧成本*2-新成本），金额为现有任务上数量*现有标准成本差异。
4）成本更新只产生了任务上的WIP差异，未产生库存上的成本更新差异。

如此奇怪的问题，我从所未遇。在分析了各种可能出错的情况后，我认为，这种错误不应是个别用户操作引发的，应是系统性的程序出错。经反复检查，多次测试后，终于发现，错误是由一个客户化的成本更新程序引发的，程序运行时，在后台写表时，成本表的某个字段被错误写入，从而引起数据紊乱。在对客户化程序进行修正之后，问题就自然解决。

当然，大胆假设的难度有点大，这源于日常工作经验的点滴积累，正所谓厚积薄发。

四、从全局性出发，处理问题要干净利落，不留尾巴。

系统的维护看似简单，实际上考验着对系统的全面认识。一个问题处理不当，可能会引发其他的问题，问题处理得不完整，当时可能没什么反应，但可能在后续的时间内暴露出其他的问题。ERP不是信息孤岛，各数据之间是相互集成，相互关联，所以处理问题时，要通盘考虑，这个数据与各模块的关联，与各数据的影响，后续影响等，一定要将问题处理得干净利落，不留尾巴。

我们处理一个问题，至少要考虑以下几点：

1）问题发生的原因是什么？
2）问题如何解决？
3）相关的引发的问题如何解决？
4）如何从源头上避免问题再度发生。

下面经一个库存科目定义错误引发的账务错误为例，说明处理方案。

比如：库存科目定义出错，将资产类科目定义成了费用类科目，造成的后果：库存模块产生了大量错误会计分录，并已传送到总账接口，子库科目设置也未更改。