餓了麼美團開放平臺接入

jcc123發表於2020-04-18

最近在做一個外賣平臺訂單的接入,跳了好多個坑~~這裡做個簡單的記錄,歡迎交流

一 要解決的問題

1 運營問題

門店有三個終端

  • 自有開發的收銀系統
  • 餓了麼收銀系統
  • 美團收銀系統

解決方案:將三端統一為一端

1

2 資料問題

有三份資料

  • 1 自有平臺的訂單資料(買了什麼,消耗多少物料等)
  • 2 餓了麼訂單資料(買了什麼,消耗多少物料等)
  • 3 美團訂單資料(買了什麼,消耗多少物料等)
    解決方案:將美團餓了麼訂單資料接入自有平臺

1

二 外賣開放平臺調研

餓了麼美團分別有對應的開放平臺,來為商家提供支援

餓了麼

要對外提供服務的可申請平臺應用或者企業應用

自有門店或連鎖門店可申請個人應用

中間趟了幾個大坑,最後申請的是個人應用,介面什麼的都一樣

美團

在美團外賣開放平臺申請註冊即可

三 資料對接

外賣平臺的商品可填入一個叫sku編碼的欄位,可在這裡做文章,與自有平臺的商品一一對應。

1 商品的對接

1

2 訂單的對接

1

注意:

  • 外賣平臺的商品資料結構錄入時,要有選擇的有傾向的將結構保持為可與自有平臺商品結構對應起來,規則定下來後,不可改變
  • 外賣適配成自有訂單後,在前臺顯示使用者所購商品,要和外賣平臺的所購商品顯示一致

三 架構設計

1 外賣平臺->自有平臺

外賣訂單進來後,先進入redis佇列,根據演算法,可將對應門店的訂單,推送到相應的redis佇列。多個門店可以使用同一個,或者不同的佇列,但要保證,一個門店推送的佇列是同一個(防止訂單狀態流轉錯誤)。

1

2 自有平臺->外賣平臺

自有平臺操作外賣訂單比如,退單,退款等

1

對於自有平臺->外賣平臺也可直接請求外賣平臺介面進行操作,這裡做成非同步,佇列消費完成後,再通知前端,操作行為完成。因為運營人員也可直接在外賣平臺的後臺操作退款退單等,這時就是走外賣平臺->自有平臺同步訂單狀態到自有平臺的流程,保持外賣操作的一致性。

四 業務設計

對於外賣訂單的適配,訂單狀態的流轉是非常重要的。一個是自有平臺的訂單狀態,另外一個是外賣平臺一方的訂單狀態。這裡對訂單狀態的流轉做個說明。

####1 模型關係
外賣平臺適配成自有平臺的訂單order(資料來源從waimai_order中取出,展示給前端),記錄外賣的源資料waimai_order中,將orderwaimai_order做個對應。

1

####2 訂單狀態流轉

order狀態欄位

  • state表示訂單狀態 已支付已接單製作中製作完成配送中訂單完成退款中退款完成部分退款 ,訂單取消

waimai_order狀態欄位

  • state 表示外賣推送的訂單狀態,可參考餓了麼推送的訂單狀態
  • order_state 記錄 order 退款中之前的訂單狀態,在運營人員發生操作行為後,恢復order狀態至該狀態。

實際開發時,可參考餓了麼推送的訂單狀態(餓了麼推送的訂單狀態節點,比較清晰) ,將其作為基準美團推送的訂單狀態轉換成和餓了麼一樣的,記錄在 waimai_orderstate

餓了麼推送的訂單狀態預覽

1

開發中比較重要的幾個訂單狀態節點,實現下列的訂單狀態流轉,主流程的可正常執行

waimai_order推送狀態 對應 order 狀態 說明
訂單生效(type=10) 未入庫 使用者支付
商戶接單(type=12) 已支付 一分鐘後的延遲佇列,防止使用者一分鐘之內取消的訂單入庫
訂單被取消(type=14) 不會入庫 使用者一分鐘之內取消的訂單不入庫
訂單置為無效(type=15) 不會入庫 使用者一分鐘之內取消的訂單不入庫
訂單強制無效(type=17) 退款成功 商家取消訂單
訂單已完成(type=18) 訂單完成 部分退款(美團專有) 美團使用者確認送達之前申請過部分退款,訂單狀態為部分退款
使用者申請取消(type=20) 退款中 使用者點選確認送達之前,申請取消訂單,餓了麼全取消,美團可申請部分取消,記錄退款中之前的狀態至waimai_orderorder_state
使用者撤回取消(type=21) 已支付已接單製作中製作完成配送中 waimai_orderorder_state中 恢復訂單狀態
門店拒絕取消(type=22) 已支付已接單製作中製作完成配送中 waimai_orderorder_state中 恢復訂單狀態
門店同意取消(type=23) 已支付(美團專有)已接單(美團專有)製作中(美團專有)製作完成(美團專有)配送中(美團專有)退款成功 美團部分取消的情況下,從waimai_orderorder_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、對於優惠的計算,餓了麼,可對比 shopPriceprice的不同,是否參加優惠,userPrice是使用者看到的價格,shopPrice是該商品商家實際收入(具體多看看文件,其他人遇到的價格問題)。美團就比較坑了。。。它只有一個欄位price,訂閱前後表示的不一樣,不訂閱表示折扣價格,訂閱表示原價,為什麼不兩個一起返回來呢?。

本作品採用《CC 協議》,轉載必須註明作者和本文連結

NOT IS BECAUSE I WANT TO WRITE,
BUT I WANT TO INCREASE,
SO I GO TO WRITE~~

相關文章