今年下半年公司一个比较重要的项目开发完成，并上线了。在项目上线时，各种期初数据的处理的问题也随之而来，由于此次系统上线涉及到了财务管理模块和进销存模块，在上线初期就如何处理期初数据，我们就进行过讨论，一种方案是录入期初单据，然后按照现在系统处理期初单据的逻辑进行处理，另外一种处理方式针对此次用户的特点
将以前的期初处理逻辑进行一些修改将期初单据单独进行处理。
由于当时时间紧迫，第一种方式应该是最理想而且对后来数据正确性和系统维护都非常有利的一种方式，但是由于工作量比较大而选择了放弃。无奈采取了第二种方式将
期初的单据进行了导入，结果到了月底要进行月结的时候发现以前对期初单据的处理有问题，这样会导致报表的数据出现错误，无法准备反映出公司的正确的财务，销售，收入数据，于是只得紧急进行修改，将以前对期初单据的特殊处理都取消掉，并且进行重算。暂时算是将数据对上了，但是月结后发现数据又出现了问题，问题出在上个月的期末没有进行正确的调整，由于期初单据处理方式的改变，上月的历史期末也要进行处理，因此月结仍然会出错。
最后我们发现，由于我们当时在系统上线初期，对期初单据的业务处理的失误，导致后面的连锁反应的发生，如果我们在初期就将期末校对正确，并要求将期初单据完整的录入并且校对正确，让期初单据的处理按照系统已有的逻辑来处理。后面就不会有这么三番五次的校对和调整了。其实这样花费的时间远大于一次搞定的时间。而且手动在后台调整或者将期初单据在系统原有逻辑上做处理，有很大的风险，比如漏掉了一些处理细节，人为在后台调整数据后，反算或者反月结后又要更新回去等等一系列的问题。。。
此次的经验和教训告诉我们对于期初单据的处理一定要慎重，系统上线的期初最后通过系统前台的功能来实现，尽量不直接更新后台数据。