目前在做一个周期送的相关项目,现在碰到一些问题,我把我们现在的设计列一下,然后碰到的问题,看大家有没有好的办法。
前台条件,有订单 order ,订单所购买的商品 good ,对于订单按照周期送生成的 package ,一个 order 会有多个 package,一个 package 可能会有多件不同的商品。目前大体是按这种模式进行设计和处理的: 如何判断每个 package 的所属期数,因为周期送的话,配送时间是未知的,虽然是以一定的时间(星期或月或年)的纬度进行的周期,但是如果按周期时间进行累加的话,可能产生的实际配送时间与计算出来的时间有误差(比如计算出来的时间为节假日,暴雨)等原因会对于实际与送时间进行提前或延后。 目前我的想的法是,抽象出排期的概念,对于商品创建出比如 100 , 102 , 103 这种递加的,产生的 package 中包含了对应的商品和对应的排期,后期对于排期的配送时间进行维护,用于确认 package 的实际配送时间。一个 package 有多件商品,其中有一个主商品的定义,所有排期以它为准
目前碰到的问题: 1 、这种设计模式到后期扩展是否存在问题? 2 、因为周期送,会存在客户因特殊情况要求暂停配送或延至某天之后的有效配送时间进行配送。因为延期和暂停都是针对于未配送的所有配送单,哪么当达到延期后的时间点或恢复配送时会有问题。重新开始配送的 package 的配送期数和时间如何计算?目前的想法是,恢复配送后的算出第一次配送的配送时间点(有可能算不出来,就需要等)然后当有这个时间点的时候,再去计算下一张,直至算完。因为每个 package 的商品可能不一样,配送的排期数也可能不一样。
或者各位针对于这种模式有什么好的想法和思路吗?多谢各位!
1
just4test 2016-08-10 10:18:49 +08:00
简单。订单生成后创建第一个 package ,这个 package 有送货时间属性,可以修改;
package 送达后会创建下一个 package 。或者 order 没有更多 package 了, order 就完成了。 |
2
just4test 2016-08-10 10:21:43 +08:00
这个思路的小问题是如何定义送达。可能出现这样的意外:
物流报告已经送达,导致生成了新的 package ;但实际上尚未送达,或者用户对货品有异议,需要重发货品。这里就涉及退回新的 package ,并且重建刚刚已经完成的 package 的动作。 |