饿了么美团开放平台接入

jcc123 的个人博客 / 1 / 3 / 创建于 4年前 / 更新于 4年前

最近在做一个外卖平台订单的接入，跳了好多个坑～～这里做个简单的记录，欢迎交流

一要解决的问题

1 运营问题

门店有三个终端

自有开发的收银系统
饿了么收银系统
美团收银系统

解决方案：将三端统一为一端

2 数据问题

有三份数据

1 自有平台的订单数据（买了什么，消耗多少物料等）
2 饿了么订单数据（买了什么，消耗多少物料等）
3 美团订单数据（买了什么，消耗多少物料等）
解决方案：将美团饿了么订单数据接入自有平台

二外卖开放平台调研

饿了么美团分别有对应的开放平台，来为商家提供支持

饿了么：

要对外提供服务的可申请平台应用或者企业应用

自有门店或连锁门店可申请个人应用

中间趟了几个大坑，最后申请的是个人应用，接口什么的都一样
饿了么入口 : open.shop.ele.me/openapi 登录弹窗下方有一个切换” 商家账号登录 “

美团：

在美团外卖开放平台申请注册即可
美团对接流程：developer.waimai.meituan.com/home/…

三数据对接

外卖平台的商品可填入一个叫sku编码的字段，可在这里做文章，与自有平台的商品一一对应。

1 商品的对接

2 订单的对接

注意：

外卖平台的商品数据结构录入时，要有选择的有倾向的将结构保持为可与自有平台商品结构对应起来，规则定下来后，不可改变
外卖适配成自有订单后，在前台显示用户所购商品，要和外卖平台的所购商品显示一致

三架构设计

1 外卖平台->自有平台

外卖订单进来后，先进入redis队列，根据算法，可将对应门店的订单，推送到相应的redis队列。多个门店可以使用同一个，或者不同的队列，但要保证，一个门店推送的队列是同一个（防止订单状态流转错误）。

2 自有平台->外卖平台

自有平台操作外卖订单比如，退单，退款等

对于自有平台->外卖平台也可直接请求外卖平台接口进行操作，这里做成异步，队列消费完成后，再通知前端，操作行为完成。因为运营人员也可直接在外卖平台的后台操作退款退单等，这时就是走外卖平台->自有平台同步订单状态到自有平台的流程，保持外卖操作的一致性。

四业务设计

对于外卖订单的适配，订单状态的流转是非常重要的。一个是自有平台的订单状态，另外一个是外卖平台一方的订单状态。这里对订单状态的流转做个说明。

1 模型关系

外卖平台适配成自有平台的订单order（数据源从waimai_order中取出，展示给前端）,记录外卖的源数据到waimai_order中，将order和waimai_order做个对应。

2 订单状态流转

order状态字段

state表示订单状态 已支付，已接单，制作中，制作完成，配送中，订单完成，退款中，退款完成，部分退款 ,订单取消等

waimai_order状态字段

state 表示外卖推送的订单状态，可参考饿了么推送的订单状态
order_state 记录 order 退款中之前的订单状态，在运营人员发生操作行为后，恢复order状态至该状态（比如，自有平台的订单状态为制作中，此时用户申请退单order state流转为退款中，商家拒绝退款，恢复order state 状态为制作中。

实际开发时，可参考饿了么推送的订单状态（饿了么推送的订单状态节点，比较清晰），将其作为基准，美团推送的订单状态转换成和饿了么一样的，记录在 waimai_order的 state中

饿了么推送的订单状态预览

开发中比较重要的几个订单状态节点，实现下列的订单状态流转，主流程的可正常运行

`waimai_order`推送状态	对应 `order` 状态	说明
订单生效(type=10)	未入库	用户支付
商户接单(type=12)	`已支付`	一分钟后的延迟队列，防止用户一分钟之内取消的订单入库
订单被取消(type=14)	不会入库	用户一分钟之内取消的订单不入库
订单置为无效(type=15)	不会入库	用户一分钟之内取消的订单不入库
订单强制无效(type=17)	`退款成功`	商家取消订单
订单已完成(type=18)	`订单完成` `部分退款（美团专有）`	美团用户确认送达之前申请过部分退款，订单状态为`部分退款`
用户申请取消(type=20)	`退款中`	用户点击确认送达之前，申请取消订单，饿了么全取消，美团可申请部分取消,记录退款中之前的状态至`waimai_order`的`order_state`中
用户撤回取消(type=21)	`已支付`，`已接单`，`制作中`，`制作完成`，`配送中`	从`waimai_order`的`order_state`中恢复订单状态
门店拒绝取消(type=22)	`已支付`，`已接单`，`制作中`，`制作完成`，`配送中`	从`waimai_order`的`order_state`中恢复订单状态
门店同意取消(type=23)	`已支付（美团专有）`，`已接单（美团专有）`，`制作中（美团专有）`，`制作完成（美团专有）`，`配送中（美团专有）`，`退款成功`	美团部分取消的情况下，从`waimai_order`的`order_state`中恢复订单状态，否则订单状态为`退款成功`
用户申请退单(type=30)	`退款中`	用户点击确认送达之后，饿了么可申请`一次`退款，美团可申请`两次`退款
用户取消退单(type=31)	`订单完成` `部分退款（美团专有）`	对于美团的第二次申请退款，然后取消退单的时候，订单状态为`部分退款`
门店拒绝退单(type=32)	`订单完成` `部分退款（美团专有）`	对于美团用户申请过一次`部分退款`，订单状态为`部分退款`
门店同意退单(type=33)	`退款成功` `部分退款`	饿了么退一次，要么是 `退款成功` ，要么是`部分退款`。美团可以申请两次第一次`部分退款`，第二次`退款成功`
配送员待取餐(type=53)	`制作完成`	`order`中的`rider_state`会同步配送的实时状态，可根据此联合判断
配送员已到店(type=54)	`制作完成`	`order`中的`rider_state`会同步配送的实时状态，可根据此联合判断
配送员配送中(type=55)	`配送中`	`order`中的`rider_state`会同步配送的实时状态，可根据此联合判断
配送成功(type=56)	`配送中`	`order`中的`rider_state`会同步配送的实时状态，可根据此联合判断

五风险点

必须保证外卖平台商品通过sku编码对应自有平台商品（如果不需要商品的对应，此条可忽略，实现的时候，去除改规则，但自己研发系统很可能不仅仅是为了订单的同步，商品的同步很可能也在考虑之中），增加了运营的人为风险（可通过商家上架操作流程化降低风险）。
系统崩溃外卖接单风险（可通过多终端备用降低风险）。

六需注意的问题

1、美团确认送达之前用户操作申请退款后，在等待商家处理结果时，用户还可以操作确认送达按钮。此时自有平台的订单状态还应为退款中，拒绝之后，订单状态流转为订单完成（或部分退款用户之前申请过一次退款），同意之后,订单状态流转为退款成功(或部分退款用户之前申请过一次退款)。
2、上面的退款成功可能会有疑惑，为什么用户取消订单，同意后，也是退款成功，不应该是取消订单吗。这需要，根据自有的业务进行定义，用户支付完成后，进行的订单取消或退款，统一定义为退款成功
3、对于优惠的计算，饿了么，可对比 shopPrice和 price的不同，是否参加优惠,userPrice是用户看到的价格，shopPrice是该商品商家实际收入（具体多看看文档，其他人遇到的价格问题）。美团就比较坑了。。。它只有一个字段price，订阅前后表示的不一样，不订阅表示折扣价格，订阅表示原价，为什么不两个一起返回来呢？。