最近在做一個外賣平臺訂單的接入,跳了好多個坑~~這裡做個簡單的記錄,歡迎交流
一 要解決的問題
1 運營問題
門店有三個終端
- 自有開發的收銀系統
- 餓了麼收銀系統
- 美團收銀系統
解決方案:將三端統一為一端
2 資料問題
有三份資料
- 1 自有平臺的訂單資料(買了什麼,消耗多少物料等)
- 2 餓了麼訂單資料(買了什麼,消耗多少物料等)
- 3 美團訂單資料(買了什麼,消耗多少物料等)
解決方案:將美團餓了麼訂單資料接入自有平臺
二 外賣開放平臺調研
餓了麼美團分別有對應的開放平臺,來為商家提供支援
餓了麼:
要對外提供服務的可申請平臺應用
或者企業應用
自有門店或連鎖門店可申請個人應用
中間趟了幾個大坑,最後申請的是個人應用
,介面什麼的都一樣
美團:
在美團外賣開放平臺申請註冊即可
三 資料對接
外賣平臺的商品可填入一個叫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
狀態至該狀態。
實際開發時,可參考餓了麼
推送的訂單狀態
(餓了麼推送的訂單狀態節點,比較清晰) ,將其作為基準
,美團
推送的訂單狀態
轉換成和餓了麼一樣
的,記錄在 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
,訂閱前後表示的不一樣,不訂閱表示折扣價格,訂閱表示原價,為什麼不兩個一起返回來呢?。
本作品採用《CC 協議》,轉載必須註明作者和本文連結