盘点ERP开发的那点事-业务流和数据流

        在和朋友聊天说起开发的事，都在讨论ERP流程问题，抱怨客户要求多，需求变更太快了，跟不上节奏。回想过去的工作，我也做了不少ERP的开发工作。

        我这里的ERP可能还比较LOW，销售、采购、库存、应收应付等，感觉做了很多工作，也做了很多抽象，确实是没有一个软件是能完全搬到其他企业去应用的，或多或少的修改和配置。个人认为ERP能代表一个企业的运营方式和策略，没有两个企业是完全相同的，哪怕是两个分公司也不能完全相同，所以，ERP总会有很多新鲜的需求，等待这产品和程序员去挖掘需求和创新。

        这几天好好总结了一下ERP的共性，个人认为抓住两条线：

        第一是业务流。ERP就是管理业务数据而设计的系统，对于销售企业来说，管理应收和考核销售业绩起到了非常重要的作用。从销售单的创建到最后达成交付，整个环节涉及到采购库存等等。通常情况下，开发企业都是用工作流实现单据的审批功能。除了单据走工作流之外，ERP最关键就是处理好业务之间的约束，让单据之间能“协作”工作，形成一个完整的闭环业务处理流程。

        一般来说，销售-采购-仓储都有固定的业务关系，只是一些细节上不同企业有些不同。例如有些销售的行为，需要对在库的商品做截留，为自己的销售准备充足的库存。而采购是为管控库存而设计的，在库存控制上，不同商品不同策略都有不同的参数，但是采购有一定的流程和周期，在急需库存的情况下，并不能短时间内满足销售库存。所以，很多销售就想截留一些库存为自己的销售单做准备。若是涉及到生产部分，那么采购的难度就更大了，生产有周期，采购也有周期，还有一些特殊原材料的采购问题等等，导致销售更加坚定截留库存的情况。

        对于截留库存的需求，很多产品都把这个需求安排在库存上，在库存中另外增加属性把这部分库存从仓库账上虚拟扣减或者另存，导致库存出现了虚低的情况。几个朋友都在说，在库存中为销售单开辟一个空间保存这些库存，销售达成交付的时候，就把这部分库存用掉。

        从业务角度来说，这个是销售行为，不管是软件还是线下都不应该让仓库承担这个工作；从公司资金流转的角度说，这样的行为也不利于资金的周转。企业的目标是为了赚钱，如果截留的库存，正好是另外一个销售单要用，原来的销售单的交期可能比较长，可以等待下次采购回来，而着急的销售单却因为截留了库存而无法出仓，导致不能满足后来的销售需求。从销售角度看，销售员确实需要知道目前的可用库存。为了满足上述的几个需求点，可以在销售中建立一个虚拟库存，可用库存-仓库库存-虚拟库存，这样就完美解决所有的需求点。虚拟库存其实就是销售单的需求数量，一旦这个销售单终止或者完成，这个虚拟库存就会因终止而自动减少，也没有额外的代码来处理虚拟库存的数量。

        对于采购角色，则需要关注销售的需求和库存的变化，根据采购周期和生产周期等，制定合适的采购计划，与供应商保持畅通且良好的沟通，直接或者间接为销售服务。

        从上述例子，可以看出几个环节之间的约束和关系，这种业务流也是比较传统和固定的，细节就不讨论了。这种约束关系，我认为可以通过消息的发布和订阅来处理，配合工作流，在关键的审批流程增加消息发布的动作，让关注这些环节的功能订阅相关消息而制定应对的措施，不要通过直接代码来建立业务之间的联系。加入，一个企业根本不考虑采购的管理，只上了销售功能，通过消息的解耦，可以轻松去掉采购模块的部署。仓库与采购，可以通过配置的方式让入库动作成为“完成”采购的一个桥梁，而这种配置，就是接下来要说明的第二点数据流的管理。

        第二是数据流。业务流的处理的多种多样、复杂多变的，目前还没有一个很好的办法能通用解决这个问题，但是数据流的管理还是相对固定和简单的。这里说的数据流，指的是单据中数量的流转问题，例如采购计划-采购单-到货入库这样的环节，本质上，就是下一个步骤从上一个步骤中流转单据中的“数量”。

        例如制定采购计划，采购A产品100个。采购员在与供应商沟通后，只能采购到90个，在实际业务中，供应商可能分多次供货，才能完成供货90个的需求。这里引申的问题就比较多了：

        1、采购计划算不算完成，后续要不要继续采购或者说超过一定周期，需要重新制定采购计划；

        2、采购单是否付款，要么没有先发货还没有付款，要么付了部分款，要么全款，那么没到货的款怎么处理，如果分开发货，最后一批供应商没货可发了，这样的情况怎么处理，在报表中怎么体现？

        往往程序设计，就会把上下游的单据都查出了关联计算一下。我们再做一个假设，采购单的下游还不仅仅有到货，还有直接退货的怎么办？从财务角度讲完成的采购就是产生应付，退货就产生应收，相互可以对冲。换一个思路，把流转的数量从原来单据中扣减掉，那么是不是就变得简单了呢？我们在单据明细中设计必须有几个字段，例如Code,Qty,Leave,对应是产品编码，数量，剩余量。当明细创建的时候，Qty=Leave。如果有下游单据产生，则胡响应扣减Leave的数量。例如采购计划100个A产品，实际采购90个，那么采购计划中的A数据则为 A，100,10。可以直接从采购计划中知道完成了90，而不需要去关联查询采购单；同样，有88个到货，其中2个退货，分别产生到货单88和退货单2，这个时候的采购明细为A，90,0。财务产生2张凭证，90个的应付和2个的应收。至于财务要支付给供应商多少钱，可以在结算的时候统一合并计算就可以了，无需没张单针对性支付款项，除非合同约定到货支付，我们这里讨论的都是非到货支付的情况。

        上述例子，往往程序员会在采购单的代码中加入扣减采购计划的数量的代码，到货单扣减采购单的数量。其实这些动作都是一样的，可以开发一个组件来完成数量的扣减。但是，一旦抽象这个动作，那么就要考虑一下单据之间解耦的问题。这里需要设计一个完整的体系，干脆把业务表单的生成、修改、审核（配合工作流）、扣减都封装起来，对单据建模，每个单据都有共性、特性和标识，再建立一个表单关系模型，搭建表单之间的数据流关系，由扣减数量的组件来解析并执行。

        经过上述改造之后，一般创建单据和数据流转，在实际开发中就不需要再添加代码处理了，都放在基类和工具类中配合完成，大大增加程序开发的重用性和稳定性，且制定了一套开发规则：不管任何单据，都围绕着财务开展，符合财务规则，在复杂的ERP，也能从两条线索中找到规律。

        做ERP确实很多变数，可以加入表单定制功能，可以解决字段差异问题；加入工作流可以解决流程审批问题；加入消息机制，可以联动单据之间的协作；加入数量扣减组件，可以解耦上下游之间的数据逻辑；加入缓存可以提高业务单据的响应速度；加入分布式锁可以解决资源冲突的问题。。。。。。，ERP不需要高深的技术，只需要简单使用的就足够了。从开发的角度讲能大大降低代码量，就能提高开发效率，降低开发成本。

        在做开发框架的时候，也充分考虑到了上述的问题和开发了解决办法的相关代码。程序员只要考虑业务处理代码，再也不用考虑一些常规和简单的代码。做开发也是为了加快交付，而不是为了炫技术，把思路和线索理清楚，且有一个好的开发框架，能应对各种变数，在开发和维护阶段均能很好的完成任务。