解析运输系统 之二

运输公司常常要求我们的系统能够提供一些实时查询的功能，方便他们跟踪客户的货物。例如，客户的某一票货现在在哪辆车上，车大概到了什么地方，是否可以准时到达。而我们的设计则不能直接发映出这些功能，运输公司跟客户交接用的是托运单，司机则拿的是配载单，上面列有详细的货物信息。我们的方案基本能满足他们的需求，但做起来就发现问题多多。

首先，托运单和配载单是多对多的关系，如果你直接去建立他们之间的关系，无疑会复杂化实现。采取折衷的方案会更好，我们把配载单的明细记录和托运单的明细记录进行关系，形成多对一的关系，间接解决了前在提到的多对多关系。再把每次配载的数量写到托运单明细记录中，记录已经配载了多少数量，而不直接关系到配载单明细。

其次，当托运单被配到多辆车上的时候，其状态难以跟踪。一票货被安排在三辆车上，他们的发车时间也许不一样，甚至都不在同一天，到达时间也存在同样的问题。那么在第一辆车开始启程的时候，托运单的状态是否发生变化呢？第一辆车到达的时候呢？好吧，我们只采用最后一辆车的状态来触发托运单的状态，问题又来了：你怎么知道哪一辆车是最后一辆呢？最后我们只好采用最初级的办法，在车辆状态发生变化的时候，判断托运单的每个配载单车辆是否都已经完成了此次状态的变化。都完成了，才改变托运单的状态，否则不做变化。

第三，干线运输完成之后的送货/提货。如果是客户自提，这还好办。送货就麻烦了，一票货分三次运到，运输公司为了减少仓库成本，会送三次货给客户。我们的系统如何处理呢？最后我们决定不处理，由用户自行保管每次送货的收条，送货后再签收回单。当然，这实在不是个好办法，更好的方案可能是由系统根据每次送到的数量生成一张送货单，运输公司打印出来拿着去送货。我们这么做的原则是：如果需求不确定或没有很好的方案，宁可暂时不做也不要乱做。

第四，运输公司的客户对回单的及时性要求很高。运输公司往往在收到回单后用EMS快递回来，然后与客户进行结算。要知道，一旦业务量大，EMS的费用会直线上升。本来我也不想处理这个问题，因为我始终不清楚为什么传真就不行？后来我们决定用附件来解决这个问题，运输公司在各个分站点放置一部扫描仪，把回单扫描进电脑再上传到系统里，他们的客户就可以马上看到回单的影印件，在月底结算的时候再对一次原件。运输公司就可以在月底的时候把一个月的回单打包让自己的车辆拉回来，不再存在EMS费用。

第五，运输公司发货的时候常常会搞错托运单的内容，他们也解释不清楚原因到底在哪。有时候客户都已经收货了，托运单的内容还是要改。这个需求太奇怪了，我们唯一可以做的就是把原来的业务流程开放出一个入口，让用户随时可以修改托运单的内容。这个需求严重影响到我们分析问题的严谨性和逻辑性，真想让这个需求去见鬼！嘿嘿，怕是鬼见了也发愁。

第六，第七。。。问题多得数不过来。每次的需求分析都是在斗智斗勇，不容易哇！

推荐阅读：
解析运输系统 之一.
解析运输系统 之三。
解析运输系统 之四.