满足什么样的条件，可以向客户发货呢？可能不同的企业会有不同的答案。为了提高系统的灵活性，在设计的时候，系统分析师就需要考虑各种可能的情况。然后在系统中设置相关的选项，让用户根据实际情况来选择。

笔者今天就围绕这个话题，谈谈在订单系统设计的时候，如何从细节出发，做好相关的发货控制。主要的界面如下：

基本原则

在实际工作中，往往客户不同、订单不同会有不同的交付规则。为此在设计的时候，可以从客户角度或者订单角度出发，来做好订单发货的控制。笔者这里从订单角度来谈谈相关的发货控制。

在系统设计的时候，分析师可以考虑在订单窗口上，设置一个“交付规则”的列表框，如上图所示。然后在这列表框中列出各种可能的交付规则。再在后台设计相关的控制程序。如此的话，在生成发货单的时候，就可以根据相关的规则来进行控制。这么处理的好处，就是可以提高系统的灵活性。用户可以根据企业的实际情况，来选择合适的交付规则，做好出货的控制。

交付规则的细节

笔者在日常工作中，发现订单发货主要可以分为两类，一类是先付款后交货，即“预付款订单”这里需要注意，即使像大家卖手机的时候，看起来好像是一手交钱、一手交货，其实两者仍然有先后的顺序。大家需要先去交钱开好发票之后，销售人员才会给你拿货。为此这也是一种预付款订单的形式。只是其时间隔的比较短而已。第二类就是先发货后付款。大部分生产企业都是采用的这种方式。

如上图所示，交付规则中有“有效”、“强制”、“完成行”、“手工”、“完成订单”、“收款以后”等几种交付规则。可以说，这几乎涵盖了目前企业所采用的发货控制手段。笔者现在给各位读者分析一下，这些交付规则后面所对应的控制逻辑。

“有效性”控制指的是库存控制。也就是说，当用户选择这个交付规则之后，在发货的那个时点必须保证仓库中有足够的货可以出。如果没有足够库存的话，则系统就不能够根据这张订单来生成发货单。在系统设计时，这个交付规则所需要关注的重点就是需要检查库存的数量并于订单数量进行比较。

“完成行”与“完成订单”这两个规则与生产模块相关联。在设计中，销售订单往往有两条线。一条是与客户相关，包括订单的发货、订单的收款等等。另外一条线就是跟企业内部相关，包括根据订单来生成生产计划、采购计划、入库计划等等。由于销售订单跟企业的生产计划挂钩，为此在销售订单中就能够反映出某张订单的完工情况。如现在有一张销售订单，里面可能有五个产品。根据产品的数量、生产部门的计划、以及客户的交期的不同，其完工时间也有所不同。此时就出现一个新的问题。在交货的时候，是按产品来交货，还是按订单来交货？如果是前者的话，那么只要某个产品完工之后，就可以发货，这就是“完成行”的概念。而如果需要整张订单一起交货(如出于运输或者情况方面的考虑)，那么就需要整张订单都完成之后才能够生成发货单，这就是“完成订单”的概念。这是从生产计划的角度考虑。另外有时候在系统设计时，也有一种简单的方法，即将此与库存数量挂钩。“完成行”就表示只要部分产品有库存即可，此时系统会对有库存的产品生成发货单。而如果选择“完成订单”的话，则跟前面的有效性规则一致了，必须确保整个订单的产品有足够的库存才能够发货。在系统设计时，虽然后面的实现方法比较简单，但是笔者并不建议这么做。因为这容易产品的误发。如现在可能有A、B两个客户都要某个产品。而A客户的订单先下。此时如果只根据库存数量来判断的话，则向B客户发货的产品很可能是原先准备给A客户的。为此这么设计就会引起误解。所以笔者建议，在设计这个交付规则的时候，后台最好是跟生产模块挂钩，而不仅仅根据库存数量来考虑。

“收款以后”指的就是预付款订单。上面讲到过，销售订单设计时有两条线，其中一条就是跟客户付款有关。收款以后这个交付规则的含义就是客户要先付完款（可能只是一部分），然后企业才能够发货。此时系统分析师在设计的时候，就需要让系统在发货之前去判断这张订单客户的付款情况。如果客户按规定交付了货款（即在财务模块有这张订单的付款记录），则允许生成发货单。否则的话，系统就不允许发货，并发出相关的警告。

“强制”这个交付规则就相对简单了。如果用户选择这个交付规则的话，根据销售订单来生成发货单，在后台就不会做相关的控制。即不会管库存数量、订单的完成情况与客户付款情况。一般强制规则只用在系统测试与实施的初期。由于系统刚上线的时候，基础数据还不怎么准确。所以允许用户进行强制出货。而强制出货带来的一个明显的负面效应，就是在仓库的帐面上会有负数库存。显然这是一种明显的错误。为了系统实施的需要，一般在设计时都需要有这个规则。等到系统完善之后，用户可以根据自己的情况采取其他严格的控制条件。

发货控制中的细节

在系统设计时，除了要实现如上这些交付规则的后台控制之外，下面这些细节的内容也有助于提高系统的可用性。

第一个是客户交付规则与订单交付规则的关系。有时候会根据客户设置不同的交付规则。如某些客户经过企业评估之后，认为其信用不好。此时企业就会要求这个客户必须先付款然后才能够发货。也就是说，这个客户的交付规则是“付款以后交货”。此时为了管理方便，用户会在客户级别上设置交付规则。这个设计跟上面的订单级别设计类似。而笔者这里要强调的是，如何将客户的交付规则与订单的交付规则统一起来。如在销售订单的时候需要输入客户的信息，那么这个订单的交付规则就可以从客户信息那边自动带过来。然后需要考虑的问题是，这个交付规则业务员能否改呢？通常情况下，如果这个交付规则需要专业的人员才能够更改。如企业的信用部门或者销售经理才有权进行更改。此时就涉及到权限的限制。为此如何将客户的交付规则与订单的交付规则统一起来，并在订单级别上做好相关的权限设计，这是系统分析师在设计时要全面考虑的内容。

第二个需要注意的内容是，一家企业往往不需要用到所有的交付规则。如像一般超市，采用的就是“收款以后”这种交付规则。而生产企业可能会采用“完成行”或者“收款以后”两种交付规则。在系统设计的时候，为了提高系统的灵活性，需要将各种交付规则都考虑进去。但是同时需要设置一个开关，让企业选择哪些交付规则是可用的。否则的话，一点这个下拉列表，这么多交付规则出来容易搞晕。所以在设计的时候，可以考虑让用户自己去选择可用的交付规则，屏蔽掉不用的交付规则。

第三个细节问题是“默认的交付规则”。企业往往会有一种主要的交付规则。为了提高工作的效率，要能够在订单与客户级别上设置默认的交付规则。