仓库管理系统报表问题排查总结

延期了很久的定时任务+报表汇总不准确的问题，今天发现问题根源，在这里记录一下排查的过程和心得体会。

1. 根据产品经理给出的报表中有问题的商品去库里查，没有发现问题。
2. 当发现11月份数据没有的时候查了代码，发现从临时表到历史表的备份错误，做了修改。问题还没有完
3. 11月份报表不是一部分有问题而是全部都有问题，原因是由于备份删除策略导致过两个月一来一回将11月份详细数据删除，查无历史。
4. 今天排查问题，发现在修改单据的时候，出现了出库类型与库存变动类型记的不一致，导致报表根据类型汇总的时候同一个商品的不同出库类型计算有误。这个问题由来已久，问题总是在报表中发现，但是根源一直没有找到，只是在怀疑定时任务有问题或者绘制过程有问题。
5. 根据出库完成后并进行修改的单子来看在库存变动表中记录的类型与出库类型以及要统计的类型id部分对不上，不仅仅是日常出库，调拨出库，套餐出库都有类似的问题。
6. 在进行出库操作的时候这种错误就发生了，而在后期报表汇总的时候没有发现。
7. 经过修改将库存变动记录表的类型与出库表的类型设置一致应该没有问题。

那么现在来回想一下为什么会出现这个很久很久没有解决的问题
1. 出库类型之前有三类，后面由于需求变更，出库模块里面加了领用类型，这个领用类型包括这三类。同时报表也根据这些领用类型去分类汇总。
2. 在变更这些类型的时候没有考虑到对现有系统功能的影响，并且进行评估。
3. 同时原有的三种类型还是有自己的用处的，只是这些类型被混在了库存变动表里，替代了真正的领用类型导致由于修改单据出现某些特定的错误数据。

由此可以得出结论：
1. 在根据id去设置数据，获取数据，汇总数据的时候，类型变更需要提前进行技术评估,评估变更的影响，影响到了哪些模块和功能。
2. 开发人员应该更多的理解每一行代码什么意思，代表什么操作。整个代码块代表什么业务操作。每个业务操作有什么意义，这些比较复杂的业务操作都需要记录在代码注释里。
3. 开发人员应与产品经理，测试人员配合测试，对于每一轮测试，都有一个明确的测试目标，预期结果，结果验证的过程。测试过程中抓住主要矛盾，深入分析排查问题，对于已经确认没有问题的业务逻辑在排查过程中不应牵扯进入测试排查问题的环节。
4. 根据一个有问题的数据的入口，或者日志排查相应问题，不能空看代码，需要帮助的时候及时跟领导协调资源。