生鲜配送供应链系统_杭州生鲜配送系统之升鲜宝_对生鲜配送系统的，销售订单，采购订单，出库单，入库单的一些思考_15382353715
从事系统开发接近10多年了，在这十几年中，经过很多系统的洗礼，接触与深入过不同的系统功能结构，从以前在珠三角到后面的长三角，直至现在全国各地开发与实施系统，心里总是隐隐约约地觉得系统软件的流程就是那么多，但是感觉软件功能的界限虽然很清楚，功能明确，但是大部分软件已经沦为为了软件而软件的系统。研究很多软件的数据库表设计后，发现表还是那些表，但是很难让取舍。要么流程过长，要么各个模块之间的联系非常紧密，逻辑性非常严格 。一步没有进行下去，后面就没法操作系统，数据就没法进行下去了。
现在就销售订单、采购订单、出库单、入库单，这四个单据针对生鲜配送行业进行说明一下。生鲜配送行业讲究简单、直接。这个行业的软件，有一点重要的特点，就是不要需要转弯，一条直线走下去。这样才能最省事省力的。一些行业从事人员，经常向我反应，现在市面上的软件的流程太长了，不太适应生鲜配送行业，数据只停留在系统层面上，为了把一个数据做准确，需要花费很多精力。
eg:
有些软件只停留软件设计，停留在办公室层面上，这样做的结果，就是数据是可以做准，但是实际使用起来，根本不是那么回事。让使用者没处诉苦，因为系统演示的时候，数据是可以做准确的，签合同的时候，也是准确的，
各种报表，各种图表图，都看起来很漂亮，但是实际使用起来，就不是那么回事了。只好认倒霉了。
现在的农副产品流通软件，我认为软件要尽可能简单，流程尽可能要直接，业务功能尽可能要单一。链条要尽可能短。 以销售订单与销售出库单为例，说明一下传统软件与现在软件要求的对比与数据库表设计
传统软件是这样的
功能流向是这样的:
销售订单---->销售发货通知单----->销售出库----->生成销售发票（红字与蓝字）-------------->形成应收账款
表设计是这要的
1.销售订单主表
2.销售订单明细表
3.发货通知单主表
4.发货通知单明细表
5.出库单主表
6.出库单明细表
7.发票单主表
8.发票单明细表
9.客户退货单主表
10.客户退货单明细表
总共用10 个表才能输助完成这样的销售订单的相关功能。而且流程非常长。导致生鲜配送等相关的快销品行业使用起来，有点繁琐。不通畅。
现在软件要求
销售：
业务流程 销售订单新增 ------------------->销售订单发货--------------------------->销售订单发票（红字与蓝字）--------------------->形成客户应收
表设计是这要的
1.销售订单主表
2.销售订单明细表
3.销售订单退货主表
4.销售订单退货明细表
就是把销售订单与销售出库一一对应起来，在一条直线上面，销售订单一产生，那么要销售出库的预出库数据也出来了，至于最后实际出库数据是多少，以当时的数据为准。那么有人会问出库单怎么统计呢。一下子反应不过来了，其实我自己也有时候反应不过来。
我认为要解决这个问题，要针对生鲜配送行业的现实业务场景出发，这样，就可以了很好的解决这个问题。我们把出库单、入库单二个传统必须的单据，分一个界限来区分。标准是这个出库单据有没有产生应收或者应付账款，有没有形成收入与支出。这样的话，就很容易设计软件的功能，我把出库单、入库单分成与外部客户联系和与外部供应商联系的一部分，另外一部分就是公司内部的单据交换。比如领用出库单，报损出库单，调拔出库单等等这类似的单据。这样我们统计的时候，就可以明确与细分了，软件设计也简单了。哈哈。
这样我们统计销售收入的时候，我们只需要统计销售订单主表与销售订单明细表和销售退货订单主表与销售退货订单明细表了。跟出库单没有任何关系了。如果我们要统计出库单情况，我们就可以统计销售出库单与出库单里面一些数据就可以了。这样就很明确了。
采购：
由销售订单转化为采购预订单-------------------->形成真实的采购订单--------------------------->采购入库订单-------------------------->形成供应商应付账款
这样需要的表设计为：
采购订单主表 （采购订单单号、供应商名称、预采购金额 、采购金额、采购入库金额）
采购订单明细表 （采购订单单号、商品名称、规格 、预采购数量、预采购单价、采购数量、采购单价、采购入库数量、入库单价） 等主要字段。 这样设计下来就非常直观与明了。因为生鲜配送行业。直来直去比较好。
客户今天要的东西，今天不发货，明天就可能不需要了，所以不存在，今天的货，明天补单的情况，重新生成一单，或者说在原单据上面做标记就好了。不需要把业务逻辑做成那么复杂。现在的软件把流程做的非常复杂，看起来数据非常严谨，结果软件公司自己的
业务人员遇到实际情况都不知道数据是如何流转的。
