最近在做一個外賣平臺訂單的接入，跳了好多個坑～～這裡做個簡單的記錄，歡迎交流
一 要解決的問題
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 協議》，轉載必須註明作者和本文連結