中文字幕无码av不卡一区,亚洲综合AV永久无码精品一区二区,黑人巨大白妞出浆,黄色高清无码免费看,久久久久免费精品国产,久久无码人妻丰满熟妇区毛片,欧美日韩国产综合草草,久久福利网站,亚洲一区二区三区中文字幕在线,av国内精品久久久久影院

對于大型商家來說，與各平臺的合作錯綜復雜，需要一個邏輯清晰的自營訂單系統進行管理，筆者在本文分析了自營訂單系統的業務邏輯。

當前各大電商平臺競爭不斷，各有各的標準，各有各的玩法，這對于供貨的商家來說其實是一個很大的挑戰。

當然，對于一些小的商家（例如在淘寶開一個淘寶店）而言，工作人員也就幾個人，工作并未細致分工，內部運營還是比較好管理的。

但是對于一些大型的商家來說，往往不單單與一個平臺合作，而是與各大平臺皆有合作，且體量龐大，內部人員眾多，分工細致明確。這樣就需要依附于各大平臺搭建起自己內部的管理系統，便于內部運營管理。

對于這類因為入駐各大電商平臺搭建起來的運營管理系統，其實分為很多域。例如，與各大電商平臺供應相關對應的：商品系統，庫存系統，價格系統，營銷系統；與各大電商交易相關對應的：訂單系統，客服系統，財務系統，結算系統。當然，這些系統可能不單單用于對接各大電商平臺，有可能還服務于商家自主的線下平臺，或者其他銷售渠道。

今天分享的是，訂單中心，或者稱之為“自營訂單（區別于各大電商平臺的平臺銷售訂單）”，是商家與各電商平臺交易的核心紐帶，是商家交易后運營的起點與樞紐。其結構大致如下，這里分為三塊來簡單分析：信息翻譯，正向業務，逆向業務。

信息翻譯

“自營訂單”是商家交易后運營的起點與樞紐，而“信息翻譯”則是自營訂單的起點。

為什么單獨列出這一項，主要有兩個原因：

1. 各平臺語言不一致，內部與外部的語言不一致，人員適應需要成本；
2. 各平臺語言不一致，內部與外部的語言不一致，后續系統適應需要成本。

信息翻譯涉及的內容很多，基本包含交易履約環節的所有信息。

正向業務：分為拉取與推送

• （拉?。┯唵蜗嚓P信息：訂單基本信息，會員信息，支付信息，商品信息，收貨信息，優惠信息等；
• （拉?。┙Y算相關信息：銷售平臺分賬信息，優惠分賬信息，支付平臺分賬信息等；
• （推送）履約相關信息：發貨信息，物流明細等；
• （拉取）履約相關信息：確認收貨信息。

逆向業務：分為拉取與推送

• （拉取）請求相關信息：退貨請求，換貨請求，僅退款請求等；
• （拉取/推送）請求調度信息：同意退貨，拒絕退貨，同意退款，拒絕退款，顧客寄貨/上門攬件，投訴制裁等；
• （拉?。┙Y算相關信息：退款結算信息等。

這些信息多種多樣，并且各平臺語言不一，所需要耗費的工作繁復復雜。雖說看上去并沒有什么業務價值，卻是后續所有業務流轉的源頭。

正向業務

我將正向業務分為了兩個大的模塊；

1. 正向交易調度；
2. 其他調度（包含，履約調度，結算調度，財務調度）；

為什么這么分，其實也沒什么意思；就是簡單的前置條件，交易調度之后，其他調度才可開始，其他調度內部之間可并行執行，或者說交叉執行。

1. 正向交易調度

這里可能存在一個問題，各電商交易平臺已經完成交易管理，支付管理了。

為什么還要做一個“正向交易調度”呢，“正向交易調度”做的是什么呢？

“正向交易調度”做的主要內容是同步的管理商家內部的核心資源（主要是指庫存），盡量保證商家內部的核心資源與各銷售平臺保持一致。

為什么要做這件事呢？

主要原因是：盡量保證商家內部的核心資源與各銷售平臺保持一致，能夠較為實時有效的了解各平臺的銷售情況，了解核心資源的消耗情況，作為運營調整的基本依據。

這里的這里簡單舉一個例子：

假設公司參與了一個京東平臺的預售活動，顧客付完定金，公司肯定得做庫存保留，顧客付尾款的時候才能保證有貨，防止其他渠道占貨，所以需要內部同步的管理庫存。

因為各平臺是隔離的，整個銷售過程由平臺接管，所以供各平臺銷售的庫存是各平臺獨占的；所以有同學會問，這種情況下，不會存在其他渠道占貨情況。

可問題是其他渠道真的想占貨的時候，想從京東平臺拉貨回來到其他平臺售賣時，不知道京東銷售到底占了多少貨，還剩余多少，那就肯定不知道能從京東拉多少貨給其他平臺。

當然，這里的核心資源主要就是“庫存”，商家這么做還有一個核心的目的：運營智能化，能夠知道各平臺銷售情況，庫存剩余情況，做到庫存的動態智能分配。

另外，還有一種情況，部分商家為充分售賣貨品，因為無法實時和平臺聯通管理庫存，會虛高供給庫存。例如，商品A總庫存實際就100個，結果商家同時給天貓供貨70個，兩個平臺加起來就有140個。這種情況下，就需要較為實時監控銷售情況，保證能夠及時作出調整。

2. 其他調度

1)履約調度

銷售訂單的履約相關涉及的內容很多，包含了“發貨履約”、“安裝履約”、“發票履約”等核心調度。但一般商家主要只涉及“發貨履約”，那這里核心說下發貨履約。

當前各大平臺與商家合作模式中，關于發貨履約的方式也多種多樣，大致可分為四類：

1. 如京東一樣，使用京東物流上門取件發貨；
2. 天貓菜鳥一樣的平臺，分配第三方承運商上門取件發貨（各平臺都存在這種模式）；
3. 商家自主聯系承運商發貨；
4. 商家自有物流，自主發貨。

平臺根據各類發貨模式，發起不同調度流程，例如：

• 上門取件發貨的模式，下發分揀、出倉指令，等待快遞員上門攬件；
• 自主聯系承運商情況，下發下發分揀、出倉指令的同時，會連通快遞公司api下快遞單；
• 自主發貨的，可能就下發給自己的物流系統一個整體指令，由物流系統完成后續的履約過程。
• 調度過程中，“自營訂單”還承載著一個商家與外部平臺聯通的角色，互通對應的履約過程信息，以供用戶在各電商平臺查詢，以及商家內部查詢與處理。

2)財務調度

“自營訂單”是訂單運營操作，履約操作的軸心；聯系著內部與外部平臺，同樣也聯系著內部各系統。

在財務流程中，公司記賬往往比較繁復復雜，記賬節點多，觸發事件不一，如：

1. 一般公司銷售訂單支付完成后，公司未收到貨款，公司就會記錄應收賬款；這個時候，“自營訂單”就聯通了銷售平臺與內部財務系統；
2. 商品出庫時，需要記錄商品賬；這過程中，“自營訂單”就聯通了內部倉庫系統與內部財務系統；
3. 顧客確認收貨時，又會記錄一次賬款往來；同理，是聯通銷售平臺與內部財務結算系統。

這些節點的調度，都是由“自營訂單”作為軸心來調度串聯各業務環節。

3）結算調度

又如結算流程，這里可能涉及兩塊：

1. 商家與銷售平臺的結算；
2. 可能還涉及與更上游的供應商結算。

商家與上游供應商結算，往往是周期性的，但周期內哪些訂單應該結算；仍然是基于一定的業務節點的，這里的調度，也是由“自營訂單”作為軸心來調度串聯各業務環節。

商家與電商平臺結算，來得更為直觀，因為對應的結算往往是實時分賬，這就涉及分賬結算的調度。

具體各平臺是以哪個節點為分賬結算點，結算貨款如何撥付，后續如何對賬，“自營訂單”都會參與其中，或是作為調度的軸心，或是數據的提供者。

逆向業務

當前各大電商平臺的逆向服務，可簡單分為三類（部分公司還存在修改訂單，保險理賠，安裝維修等業務，這些流程較為偏僻，大部分商家不涉及，暫時不做分析）：

1. 退貨退款請求：無論何種原因，顧客退回貨物，商家退回貨款。
2. 僅退款請求：貨物存在一定瑕疵，顧客要求補償部分貨款。貨物仍屬于顧客。
3. 換貨請求：換貨請求較為復雜，指的是貨物置換，不涉及款項。商家與顧客雖然不涉及款項，但商家內部處理時，還是涉及新單、舊單的內部換算。因為可能存在換貨前后的商品sku是不一致的，尤其是穿戴類商品，更換顏色、更換尺寸的情況。

逆向流程中，分模塊其實是比較難的，因為各流程相互交叉，這里先按照主次強行分為兩塊：

1. 核心模塊，請求調度過程，管理商家&用戶&平臺三者之間的相互溝通，以此為整個逆向模塊的引擎來推動逆向業務的推進與完成。
2. 在請求調度過程中，同時延伸內部的“逆向交易調度”“逆向履約調度”“逆向結算調度”“逆向財務調度”。

但由于兩塊交互太過密切，用三張簡單圖進行介紹：

退貨請求調度簡略圖（實際過程太復雜，這里只是簡略畫圖）

僅退款請求調度簡略圖（實際過程太復雜，這里只是簡略畫圖）

換貨請求調度簡略圖（實際過程太復雜，這里只是簡略畫圖）

這些過程有兩個特點：

1. 商家處理內容復雜；且操作人員角色繁多，涉及客服，物流，倉庫；每個商家操作的節點，往往又都涉及后續的調度；
2. 各平臺往往是偏用戶而壓商家，所以這些過程中，商家需要更為細致，往往需要添加各類監控預警機制。

逆向業務中流程看似繁復，梳理時，需要注意主次，然后逐步分析即可。

1. 把握核心軸心-請求調度。梳理清楚商家&平臺&用戶三者在流程中的角色，完成整體流程的串聯。
2. 分析每個節點，商家的工作任務，后續任務，然后聯通請求調度各節點與各類交易、履約、財務、結算之間的調度。
3. 完成整體分析梳理。

以上只是個人針對商家端內部“訂單中心”搭建的簡單業務分析。

當然，因為這個系統終究還是屬于中臺或者后臺系統，真正要去搭建這個系統，就需要先把流程梳理完成后，逐步提煉抽象，最終形成比較完備的產品分析方案，逐步實施。

另外，公司一般是逐步與各平臺合作，銷售量來看的話，也可能是逐步增加的。所以，產品的搭建也是步步為營，很多操作可能一開始就是在電商提供的開放平臺上操作的，內部人工聯通；待到商家系統搭建完成后，再逐步切換到內部系統。

本文由 @JOJO_004 原創發布于人人都是產品經理，未經許可，禁止轉載

題圖來自 Unsplash，基于 CC0 協議