这一篇学到了订单系统，但并不是 OMS 订单中心的概念，只是一些订单的逻辑，OMS 这边感觉自己还不太能理解。原型链接
https://xd.adobe.com/view/1a2124f2-4f52-4ff7-592e-b45eba66d5a1-6c10/ 朴朴作为生鲜到家的业务类型，订单系统相对来说比较简单，首先是不用拆单，当然这只是基于我的观察而言，并不能断言内部业务是怎么处理的。之前说过，曾经看到过拆单是为了更好的履单，而朴朴的业务模式是前置仓模式，不存在分仓发货，30 分钟到家无需根据商品类别分开打包，虽有预售商品但是是和普通商品一起送达，所以可以推测不需要拆单。其订单逻辑也是比较经典的，没有太特殊的地方。
大体上需要记录的信息就是这么多，朴朴的商品特征（生鲜商品没有太多种类的 SPU，SPU 展示可以显得商品品类更丰富）使得它是以 SPU 为单位销售商品的，所以这里只记录了 SPU 没有记录 SKU，当然由于还没具体学习商品管理系统，所以也可能说的不对。
朴朴没有会员体系，所以下单时是没有会员系统参与的，下单时首先经过风控系统检验，是否为恶意下单，比如经常下单后取消的账号，恶意刷单的账号等，应该被列入黑名单特殊处理。通过风控系统后获取一系列信息，此处需要校验一次库存，此时订单为待付款状态，同时锁定库存。
这里也要说一下经典的何时减库存的问题。两种方式：下单减库存和付款减库存，缺点是前者有可能会导致恶意下单，后来者无法付款；后者则是可能导致超卖，实际库存不够，影响购物体验。现在一般的操作都是下单锁定库存，给出一定的支付时间，超时则会取消订单。如果是抢购类的活动，比如天猫双十一之类的，那么就可能是付款减库存，约定俗成“先到先得”。
朴朴应该也是下单锁定库存，给出 10 分钟付款时间，十分钟后未付款则订单取消，释放库存，支付成功则扣减库存，库存系统则生成销售出库单。这里如果出现多次支付后取消订单的用户，根据风控级别也可以设定这部分用户为付款减库存，避免恶意下单的风险。
那么在点击支付以后，还是要再次验证一下库存和营销系统，防止出错及活动过期。支付成功，此时订单为备货中状态。
此时仓库开始分拣订单并进行打包（如果是预约订单则到达约定时间开始拣货）打包好以后订单进入待配送状态。自建物流接单后进入配送中流程，送达用户手里后，是由配送员点击完成配送，用户无需也不能操作。
如果没有进入售后流程，那么一段时间后，订单关闭，不能再对此订单进行操作。
根据我的体验，实际上就是可以在货物配送之前的任何一个阶段取消订单，备货中也可能出现仓库实际库存不足，导致客服电话联系顾客主动提起退货或换货。开始配送以后，如有实际需求，应该也可以联系客服取消订单，如果地址不明确，配送员无法联系到顾客的情况下，订单系统也会作退货退款处理（由于已经有实际商品出库，并需要作退货入库，所以后台应是退货退款），在顾客这边会视作订单取消。
在收到货品以后，可以通过联系客服提出退货退款，或者顾客在评价中对商品的质量表示疑问，客服会主动联系顾客提出仅退款作为补偿。
这边的售后实际上我并没有都体验过，由于没有过缺货或换货的需求，所以这里只是基于普通购物流程的推想。
朴朴在 app 上面其实没有售后的入口，我想一方面可能是对商品质量、供应链和打包配送服务比较自信，不太会出现太多售后问题，而如果真的有问题的话，由于生鲜商品占大头，真的有质量问题的话已经无必要取货重新入库，可能实际退货的场景也很少。
那么实际的业务逻辑还是如图所示，在客服与顾客沟通中任意一方提出售后，由客服创建工单，退货、换货或补货。此时如果是换货或补货也要和仓储确认是否有对应的库存。换货出库或补货出库其实和销售出库差不多，但是没有实际的银行流水产生，换货出库单和补货出库单其价格是记录在关联的主订单中的，换货入库和退货入库也是差不多饿，但是也同样是没有金额变动，一般来说换做价格差不多的商品也不会要求顾客补差价。
那么如果是换货入库或者退货入库，也都要仓库检验商品是否还能再次销售，可以的话则入库继续销售，否则就报损出库（仅退款也是报损出库）
在学习的时候看到有人用这种映射表的方式来表示状态机，感觉比较清晰。这其实算是图表方式来简要表达一个订单大致的正向和逆向流程。
在这里把销售订单、退换补订单区分开，销售订单关联的退换补订单标记出来，在订单详情中互相关联显示
，并显示该订单关联的工单。相对于之前做的客服系统来说，这里补充了一些细节字段。
这个模拟朴朴的系统越做还是越觉得缺少实际业务的指导来做还是挺难的，尤其是不光没有具体业务指导，连这个业务都没接触过。虽然有很多不足，不过也还是学到了不少东西，希望等接触到具体业务时可以有一些茅塞顿开的感觉。下一个系统应该是会学着做一个营销系统。