說明：Java電商平臺-電商訂單系統全解析主要講解OMS的內容，設計，開發，架構等知識
今天分享將會分爲以下三個環節來闡述：
1.訂單系統的介紹
2.訂單系統的解構
3.垂直電商訂單系統設計思路
一、什麼是訂單系統？
訂單管理系統(OMS)是物流管理系統的一部分，通過對客戶下達的訂單進行管理及跟蹤，動態掌握訂單的進展和完成情況，提升物流過程中的作業效率，從而節省運作時間和作業成本，提高物流企業的市場競爭力。顧名思義，電商系統就是用戶、平臺、商戶等對於訂單的管控、跟蹤的系統，銜接着商品中心、wms、促銷系統、物流系統等，是電子商務的基礎模塊；
簡單地說訂單管理系統作爲整個電商的核心，管理着所有的交易進出，可以說沒有訂單系統電商就無法流暢地運轉；
一個好的訂單管理系統需要有很好地擴展性和流暢性，在一個電商產品從0-1的過程，訂單系統作爲其基礎模塊需要提前考慮到各系統的擴展，訂單系統如果在前期就能考慮到後面的擴展，相信對於電商的壯大會非常有幫助；
流暢性指的是整個交易鏈路需要很流暢，早期我司的訂單系統做的非常龐大，但是卻沒有考慮到流程的通暢性，導致連基礎的訂單流程都沒有辦法正常走下去，所以，在從0到1地做一套訂單系統時，需要有一些前瞻性，但落地時，以MVP去試錯；
二、訂單系統解構
訂單字段
訂單的主要信息包括支付信息 、配送信息、狀態信息、促銷信息、商品信息、用戶信息等；
支付信息：涉及支付的字段信息，主要包括支付方式、支付金額、訂單金額、優惠金額等；
促銷信息：涉及促銷的字段信息，主要包括優惠方式、優惠面額、折扣等；
商品信息：涉及訂單中的商品字段，主要包括商品名稱、單價、數量、所屬店鋪等；
時間信息：涉及訂單流轉中各個時間戳的字段，包括下單時間、支付時間、發貨時間、完成時間等
狀態信息：涉及訂單流轉中狀態變更的字段，主要包括訂單狀態、物流狀態及退款狀態等；
用戶信息：涉及用戶的信息，比如買家姓名、註冊手機號、收件人等信息；
配送信息：涉及訂單配送的基本信息，比如配送方式、物流單號等；
以上這些字段構成了訂單所需要的大部分信息；
2.訂單體系
訂單體系
可以從三個層面來了解電商的訂單管理體系，分別是用戶層、系統層和底層；
用戶層
這個比較好理解，就是用戶日常使用的功能和頁面，主要有訂單列表、訂單詳情和退款詳情等C端用戶購買時會使用到的頁面，系統層和底層模塊爲其提供支持；
系統層
在訂單管理體系中，和訂單最息息相關的交互系統主要有支付系統、訂單系統、倉儲系統；
1.支付系統
主要作用就是爲訂單提供支付支持，方便用戶使用各種支付方式進行支付，用戶支付後會將支付信息給到訂單系統；
2.訂單系統
作爲訂單管理體系的核心，起着至關重要的作用，在訂單系統中會生成訂單，審覈訂單，取消訂單，還涉及到複雜的訂單金額計算以及移庫操作；
倉儲系統：主要用來管理庫存以及發貨，訂單到達一定狀態後給到倉儲系統，用於管理對應訂單的打包、分揀、
備貨、出庫等；
底層模塊
主要包括商品、支付、用戶、營銷、訂單和消息等模塊，這些模塊共同組成了對上層業務、系統的支持；
大公司一般會將底層框架模塊化，比如商品，會構建對應的商品中心，代碼、數據庫等相對獨立，由商品中心開接口和soa，其他模塊需要使用商品中心相關功能的時候調取接口，這樣做的好處是使各個模塊底層相對獨立，便於管理及改動；
3.狀態機
狀態機
下面來說說狀態機，一般電商平臺用戶直觀能看到的狀態有上圖中列舉的幾個，包括待支付、待配送、待收貨、交易完成、退款中；
O2O沒有電商中龐大的倉儲系統，自然比電商的流程簡單些，我將從正流程分別從正流程和逆流程來介紹；
主流程
在電商中，無論是買家端還是賣家端，都會將交易主狀態分爲待付款、待發貨、待確認收貨、交易完成，但是買家端與賣家端的展示邏輯稍有不同；
在買家端，買家關心的狀態無非就那麼幾個，即待付款、待發貨、待收貨和待評價，所以淘寶並未像商家端那樣將全部的狀態一一羅列出，而是保留了買家最關心的狀態，保持整個買家端的簡潔性；
而賣家端中，主要解決的是商家效率的問題，所以在訂單列表中會將所有的狀態（即待付款、待發貨、已發貨、退款中、需要評價、交易完成、交易關閉）的訂單全部拉出，考慮到商家訂單較多的情況，出於對服務器查詢的考慮以及併發的考慮，增加了三個月內訂單與三個月前訂單的查詢區分；
首先說說待付款狀態，待付款狀態主要是買家下單但是沒有支付的情況，待付款狀態下淘寶的商家也可以進行一系列操作如改價等，買家也可以申請代付、批量操作；
待發貨，該狀態下會展示所有已支付，待發貨的訂單，淘寶目前支持的發貨方式主要有四種，在線下單、手填快遞單號、無紙化物流以及無需物流，操作配送之後交易狀態會變更爲待確認收貨，大型電商平臺已經採用無紙化發貨的形式進行發貨，即使用中端叫單，成功後會展示在已發貨（商家端）和待收貨（買家端）中；
待確認收貨，該狀態出於物流階段，一般會根據業務、活動等來設定自動確認收貨的時間，一般電商默認值是在發貨後的10天爲自動確認收貨時間，在雙十一、雙十二等節日，這個時間會延長到15天，另外海外購、天貓國際等海外購物的訂單自動確認時間也會相對較長，爲25天；
交易完成，該狀態由系統或者用戶觸發，在訂單確認收貨後，訂單狀態變更爲交易成功，此時系統會根據是否評價過判斷是否將訂單展示在買家端的待評價下來引導用戶對商家進行評價反饋；
退款/退貨流程
一般電商中訂單的逆流程主要分爲退款流程和退貨流程，這裏簡單地介紹下，後續會有專題來講述；
發貨前的逆流程
發貨前的狀態一般有待支付和待發貨兩個，待支付的訂單發起逆流程後無需商家確認，直接關閉訂單；
而待發貨的訂單發起後需要走商家的審覈，商家同意後訂單變爲交易關閉，觸發退款；
發貨後的逆流程
發貨後的逆流程主要包括待確認收貨和交易成功的逆流程；
大致分爲需要僅退款和退貨退款；
僅退款：未收到貨或與賣家協商同意後的申請，賣家同意後無需物流；
退貨退款：已收到貨需要退換的情況，賣家同意後需要走物流；
Po上我司的退款流程作爲後續專題的引子吧，敬請期待...
3、某垂直電商設計思路
筆者的公司屬於某個垂直行業的電商，主要以B2B轉單爲主，將線上的訂單轉給線下門店進行配送，所以暫時不涉及商品、庫存、倉庫等；
以下是我司的訂單流程，線上商家將訂單轉給線下門店，涉及的狀態有待派單、待支付、待接單、待配送、待轉賬和交易完成；
在設計主流程的時候並不複雜，根據業務場景進行設計即可，真正複雜的部分在訂單的逆流程與系統間的交互；
由於舊版的系統過於臃腫，沒有辦法在其上進行迭代，加之流程上有很多問題，所以打算從業務流程、系統框架、視覺設計等方面做個大改版，即解決用戶使用流程中的問題，也便於後期業務功能的實現；
生鮮電商狀態機
訂單系統的完整性離不開幾個部分，上次講訂單字段，各種字段信息組成了一個訂單詳情頁。如果將字段信息比喻成訂單系統的血液，那訂單狀態的切換就好比訂單系統靈活的神經，沒有訂單狀態之間的切換，就構成不了龐大的訂單系統，也滿足不了很多網購時各種情況。
訂單流程
訂單流程是指從訂單產生到完成整個流轉的過程，其中包括正想流程和逆向流程。正向流程就是一個正常的網購步驟：訂單生成-->支付訂單-->賣家發貨-->確認收貨-->交易成功。而逆向流程則是各種退款流程。
正向流程
訂單正向流程
整個訂單設計的流程其實是非常多的，接下來我們將從比較具體的描述一下各個環節下的實際情況：
訂單生成：用戶下單後，系統需要生成訂單，此時需要先獲取下單中涉及的商品信息，然後獲取該商品所涉及到的優惠信息，如果商品不參與優惠信息，則無此環節，接着獲取該賬戶的會員權益（這裏其實需要注意的是，優惠信息與會員權益是有區別的，就好比商品滿減是優惠信息，新人立減是會員權益。一個是針對商品，另一個是針對賬戶）。庫存扣減是指可銷售庫存數量-1，嚴格來講庫存扣減目前分爲兩種，一種是下單減庫存，另一種是付款減庫存；個人覺得中小創業者也許競爭者不比淘寶中的賣家，在電商這個存量市場，需要精細化的運營才能存活下來，如此說保證用戶體驗纔是根本，所以我這裏的觀點是生成訂單扣減庫存，這種做法會避免用戶支付成功商家卻沒貨的情況。然後計算運費，訂單生成成功。
支付訂單：用戶支付完訂單後，需要獲取訂單的支付信息，包括支付流水號，支付時間等。支付完訂單接着就是等商家發貨，但在發貨過程中，往往還有一種情況存在，很正常卻也比較複雜，就是訂單拆單。訂單拆單分兩種，一種是用戶挑選的商品來自於不同渠道（自營與商家，商家與商家），此時就需要拆分訂單，並分開結算，這裏還涉及父子訂單的說法，這裏不再贅述。另一種是在SKU層面上拆分訂單。不同倉庫，不同運輸要求的SKU，包裹重量體積限制等因素都需要將訂單拆分。比如商品A只在甲倉庫有，商品B又只在乙倉庫有，此時會將商品A與商品B拆分成兩個訂單。或者有些企業的做法是將商品A/B調撥到另外一個倉庫統一發貨，也方便了用戶。訂單拆單看起來簡單，其實裏面涉及到底層的系統支持，如你需要對每一個倉庫的貨品進行相對準確的盤點，且做到實時同步（涉及到倉庫精細化管理）；對商品進行準確分類與擺放；對商品信息記錄準確無誤等；這其中哪一模塊都是一個浩大的工程，PM一般進入一家公司都會在原有（半成品）的基礎上進行優化，大家不妨多思考一下底層業務，只有在底層做好精細化管理，才能支持線上豐富的用戶需求。
商家發貨：商家發貨過程也有一個標準化的流程。上面也有講到，訂單拆分時會涉及到倉庫間調撥，然後倉庫會對商品進行打單，揀貨，包裝，交接快遞配送。這套標準化流程如果優化好，也是一個大工程，這裏不再贅述，建議大家看看庫存與倉庫管理方面的書籍，詳細瞭解。
確認收貨：商家發貨後，就是等快遞配送了，訂單系統需要接入一些常用快遞企業的接口，方便用戶與商家在站內查詢快遞信息。
交易成功：收到貨後，不是一個服務的結束，相反是一個服務的開始。訂單系統需要在快遞被簽收後提醒用戶對商品做評價，這裏要注意，確認收到貨不代表交易成功，交易成功是指在收到貨X天的狀態，此時訂單不在售後的支持時間範圍內。到此，一個訂單的正向流程就算走完了。
目前我也沒有研究過，不過我的經驗告訴我訂單系統對售後訂單的處理並不比正產訂單少，身爲電商PM，我們的工作就是去優化這些流程，提高用戶粘性。本身售後訂單的出現，在某種程度上已經傷害到了用戶，如果流程還一團糟的話，我們根本沒有機會等到用戶的復購。
逆向流程
訂單逆向流程
一個電商的基本逆向流程如上圖所示，訂單的逆向流程複雜就在於它幾乎允許在正向流程的任何環節出現，有人會問，用戶未收到貨爲什麼還能退款，其實我們換爲思考，也很容易理解，假想你是用戶，買了一雙鞋子，付了款發了貨，正在美滋滋的等待收快遞，然後剛好路過一家鞋店看到剛買的同款鞋子大促銷，於是你就拿起手機點擊退款，買下了這雙促銷的鞋子。這種場景其實是很普通也很正常的用戶日常，所以我們的訂單系統就必須得支持用戶各種豐富的場景需求，也十分考驗PM的業務滲透能力，好在電商的先行者淘寶已經做了很多基礎建設和用戶教育，我們直接可以拿來套用，不過還是要根據各個公司的業務情況進行修改。
取消訂單：用戶提交訂單時，在跳轉至支付前直接退出，此時用戶原則上屬於取消訂單，因爲還未付款，則比較簡單，只需要將原本提交訂單時扣減的庫存補回即可。
支付失敗：用戶進行支付時退出，或者取消支付，我們將其列爲支付失敗狀態，此時處理同上，將扣減的庫存補回可銷售庫存即可。
付款後退款：用戶支付成功後，商家還未發貨，支持用戶申請退款，此時如果倉庫與客服是分離的，則需要先檢查倉庫是否已經發貨，若已發貨則應與客戶溝通是否可以收到貨後再進行退款，如果倉庫還未發貨，則可直接同意用戶退款。或者企業接入菜鳥物流，實行截件功能，不過這種操作還不成熟，成本會比較大，不適合中小創業型公司。
缺貨退款：用戶支付成功後，商家發貨時發現倉庫缺貨（如果提交訂單扣減庫存，則會減少缺貨情況，爲什麼是減少而不是避免？因爲倉庫管理商品時沒辦法做到100%精準，所以信息有時候會不準確，導致線上的可銷售庫存顯示有庫存而倉庫已經售空的狀態），則需要與用戶協商是否退款，這個流程訂單系統可以做到流程化，自動化，連接消息中心和倉庫管理系統去實現，難點在於消息的實時性。我就遇到過在淘寶買過一件上衣，一天過去了，商家跟我說沒貨了，我當時殺人的心都有了。
待收貨退款：這個問題目前還沒有特別完美的解決方法，商家發了貨之後，用戶還未收到貨，此時貨在路上。我曾經在一些交流羣裏提出過這個問題，大家的看法都不一樣，大體上分爲兩種做法。一種是用戶收到貨後重新寄回；另一種是用戶直接拒收包裹，包裹直接退回原地址；我個人傾向於第一種，第一種比較靈活，因爲用戶未收到貨就退款的原因一般與商品質量關係不大，所以如果允許用戶直接拒收退回，相當於商家需要承擔回退運費，而本身可能與商家並無太大關係。另外一個原因就是，有些商家發貨地址與退貨地址不在同個地方，不支持直接退回。儘管如此，在到處強調用戶體驗的今天，增加用戶的售後成本也是在消耗用戶對平臺的耐心，大家不妨去思考一下，有沒有更好的解決方法。
用戶拒收：同上
退貨退款：用戶收到貨後，想要申請售後，則此時需要提供讓用戶輸入售後原因，包括上傳憑證的功能，如果與商家協商無果，還需要增加平臺客服的入口，方便用戶進行申訴。而協商結果/申訴成功後直接觸發自動退款機制，退款後觸發消息通知，同時觸發交易關閉狀態，整個售後過程纔算結束。
我上面有好幾處都提到與消息中心的對接，消息的觸發等，其實這也算是訂單系統設計的一部分內容，稱之爲訂單推送，當訂單狀態機發生變化時，需要將對應的變化情況告知給相關人員以便了解當前訂單的情況，這也是訂單推送的作用。
訂單推送
訂單推送的觸發依賴於狀態機的改變，涉及到的信息包括：
· 推送對象（用戶，商家，倉庫）
· 推送方式（站內消息，push，短信，微信）
· 推送節點（狀態機）
本文主講訂單系統的核心模塊設計邏輯，訂單推送的具體設計就不再此處贅述。
最終數據庫設計如下：
訂單主表
CREATE TABLE `order_info` (
`order_id` bigint(20) unsigned NOT NULL AUTO_INCREMENT COMMENT '訂單自增id',
`order_number` varchar(32) DEFAULT NULL COMMENT '訂單號，唯一',
`order_source` varchar(255) DEFAULT NULL COMMENT '訂單來源，web,weixin,h5,android,ios',
`user_id` bigint(20) DEFAULT NULL COMMENT '所屬用戶ID',
`pay_type` varchar(16) DEFAULT NULL COMMENT '支付類型，alipay,weixin,un_know',
`pay_status` tinyint(2) unsigned DEFAULT '0' COMMENT '支付狀態；1，未付款；2，已付款, 3，線下付款，4 線下付款已收款',
`trade_status` tinyint(2) unsigned DEFAULT '0' COMMENT '交易狀態。0爲進行中, 1,已完成，2,爲取消交易',
`best_time` datetime DEFAULT NULL COMMENT '收貨人的最佳送貨時間',
`order_amount` decimal(12,2) DEFAULT NULL COMMENT '訂單金額',
`shipping_amount` decimal(12,2) DEFAULT NULL COMMENT '配送費用',
`pay_amount` decimal(12,2) DEFAULT NULL COMMENT '實付金額',
`trade_amount` decimal(12,2) DEFAULT NULL COMMENT '交易金額',
`order_time` datetime DEFAULT NULL COMMENT '訂單下單時間',
`pay_time` datetime DEFAULT NULL COMMENT '訂單支付時間',
`goods_shipping_time` datetime DEFAULT NULL COMMENT '商品出庫時間',
`confirm_receiving_time` datetime DEFAULT NULL COMMENT '確認收貨時間',
`outer_trade_no` varchar(48) DEFAULT NULL COMMENT '交易訂單號，比如支付寶給我平臺的訂單號',
`order_remark` varchar(255) DEFAULT NULL COMMENT '訂單備註',
`create_time` datetime DEFAULT NULL COMMENT '訂單創建時間',
PRIMARY KEY (`order_id`),
KEY `index_user_id` (`user_id`) USING BTREE
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='訂單的基礎信息表';
訂單明細表：
CREATE TABLE `order_item` (
`item_id` bigint(20) unsigned NOT NULL AUTO_INCREMENT COMMENT '主鍵',
`order_id` bigint(20) DEFAULT NULL COMMENT '訂單主表id,order_info表的order_id',
`order_number` varchar(32) DEFAULT NULL COMMENT '唯一訂單號',
`order_status` tinyint(4) DEFAULT NULL COMMENT '訂單項狀態，1爲已提交訂單，2爲取消訂單',
`user_id` bigint(20) unsigned DEFAULT '0' COMMENT '所屬用戶ID',
`remark` varchar(255) DEFAULT NULL COMMENT '訂單項備註，由用戶提交訂單前填寫',
`format_name` varchar(64) DEFAULT NULL COMMENT '商品規格名稱',
`goods_name` varchar(64) DEFAULT NULL COMMENT '商品名稱',
`goods_number` decimal(12,2) DEFAULT NULL COMMENT '商品的數量',
`goods_price` decimal(12,2) DEFAULT NULL COMMENT '商品的單價',
`goods_amount` decimal(12,2) DEFAULT NULL COMMENT '單項總金額',
`create_time` datetime DEFAULT NULL COMMENT '訂單創建時間',
PRIMARY KEY (`item_id`),
KEY `index_order_id` (`order_id`) USING BTREE,
KEY `index_buyer_id` (`user_id`),
KEY `index_format_id` (`format_name`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='訂單的明細表';
訂單日誌表：
CREATE TABLE `order_logs` (
`log_id` bigint(10) unsigned NOT NULL AUTO_INCREMENT COMMENT '主鍵，自動增加ID',
`user_id` bigint(20) DEFAULT NULL COMMENT '用戶ID',
`order_id` bigint(10) NOT NULL COMMENT '訂單ID，對應order_info中的Id',
`order_number` varchar(64) NOT NULL COMMENT '訂單號',
`order_description` varchar(128) DEFAULT NULL COMMENT '訂單日誌描述',
`create_time` datetime NOT NULL COMMENT '創建時間',
PRIMARY KEY (`log_id`),
UNIQUE KEY `unique_order_number` (`order_number`)
) ENGINE=InnoDB AUTO_INCREMENT=2 DEFAULT CHARSET=utf8mb4 COMMENT='訂單日誌記錄表';
支付日誌表:
CREATE TABLE `pay_logs` (
`log_id` bigint(10) unsigned NOT NULL AUTO_INCREMENT COMMENT '主鍵，自動增加ID',
`user_id` bigint(20) DEFAULT NULL COMMENT '付款的用戶ID',
`order_id` bigint(10) NOT NULL COMMENT '訂單ID，對應order_info中的Id',
`order_number` varchar(64) NOT NULL COMMENT '訂單號',
`order_amount` decimal(12,2) NOT NULL COMMENT '訂單金額',
`outer_trade_no` varchar(64) DEFAULT NULL COMMENT '外部訂單號，比如說支付寶交易訂單號',
`status` tinyint(4) DEFAULT NULL COMMENT '支付狀態，1爲支付成功，-1爲支付失敗',
`create_time` datetime NOT NULL COMMENT '創建時間',
PRIMARY KEY (`log_id`),
UNIQUE KEY `unique_order_number` (`order_number`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='付款日誌記錄表';
用戶取消訂單記錄表：
CREATE TABLE `order_cancel_logs` (
`id` bigint(20) unsigned NOT NULL AUTO_INCREMENT COMMENT '自動增加ID',
`user_id` bigint(20) DEFAULT NULL COMMENT '所屬買家',
`order_sn` bigint(64) DEFAULT NULL COMMENT '訂單標識，如果是單個就是item_id,如果是整個訂單就是orderId',
`trade_money` decimal(12,2) DEFAULT NULL COMMENT '處理的金額',
`current_money` decimal(12,2) DEFAULT NULL COMMENT '當前餘額',
`last_money` double(12,2) DEFAULT NULL COMMENT '最終餘額',
`remark` varchar(64) DEFAULT NULL COMMENT '備註',
`create_time` datetime DEFAULT NULL COMMENT '創建時間',
PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='用戶取消訂單記錄表';