Ⅰ 電子商務系統設計
電子商務系統包括：電子商務系統應具有廣告宣傳、咨詢洽談、網上訂購、網上支付、電子賬戶、服務傳遞、意見征詢、業務管理等各項功能，我們公司用的是上海威博的，他們就包括這些。
Ⅱ 訂單整理設計
針對訂單系統領域劃分
核心域：下單、支付
通用域：用戶管理、支付路由、紅包、優惠券
支撐域：履約（運營服務、供應鏈發貨）、售後（開發票、退款、結算、收入）
（1）訂單DDD
（2）事務一致性 TCC
（3）狀態管理：狀態機
由於訂單系統屬於交易系統的中間樞紐環節，所皮陪局有業務邏輯會比較復雜，調用方比較多。
├── interface ## 用戶介面層
│ └── assembler
│ ├── dto
│ ├── facade
├── application ## 應用層
│ └── event
│ │ └── publish
│ │ └── subscribe
│ ├── service
├── domain ## 領域層
│ └── aggregate1
│ │ └── entity
│ │ └── event
│ │ └── repository
│ │ └── service
│ ├── aggregate2
├── infrastructure ## 基礎層
│ └── api
│ └── driver
│ └── eventbus
│ └── mq
事務一致性實現 -
[[Seate]]
[[rocketmq事務一致性]]
訂單狀態：訂單子狀態（訂單主狀態燃讓、貨物狀態、交易狀態）
要點一：分清主次
訂單狀態：訂單主狀態、子狀態（貨物狀態、交易狀態）
主表子表：訂單主表、子表
查詢介面：精粒度介面（狀態查詢）、中精度介面（基本信息查詢）、細精度介面（外部查詢）
消息通知：胖消息（瘦消息+查詢）、瘦消息
復雜查詢增加查詢域亂碼：不過違背了（單一職責原則）
要點二：是否拆單？視情況而定
1、京東拆單：京東建設了拆單服務以倉庫維度進行拆單
2、拆彈增加了支付的復雜度（需要多單合並支付）
要點三：退款場景支付
紅包、優惠券均攤到sku上（使用銀行家四捨五入演算法拆分）
如何系統地理解「交易平台」？
Ⅲ 簡談訂單管理系統(OMS)
訂單管理系統即處理訂單的系統，主要管理訂單的輸入，處理，輸出。其在一般電商系統中或在有交易功能的系統中，都是核心系統/功能之一，有一定的復雜度；但是雖然復雜，並不代表理解起來困難。
關於商品的文章裡面，我們已經從商品的輸入、維護、輸出的流程來介紹了商品系統，那訂單也一樣，我們本文把訂單看成一個流程即訂單流來理解。
訂單系統會與購物車、商品系統，營銷系統、會員系統、支付系統、物流系統、倉庫系統、財務系統、內容系統，具體請看示例圖：
1. 購物車 ：個人認為是訂單的起點，商品會被加入購物車，然後會被提交
2. 商品系統： 在提交訂單頁面會看到該訂單所包含的商品信息，例如商品名稱、所購買數量、價格、售後信息等
3. 營銷系統： 會顯示商品是否優惠信息，例如滿減、優惠券
4. 會員系統： 會顯示該會員是否有基於會員等級的折扣信息(如淘寶的88會員)，或是否有可抵扣金額的會員點數(如京豆)；會顯示該會員下面的收貨地址信息、也會顯示該會員下面是否有充值卡、運費券等。
5. 倉庫系統： 基於收貨地址信息顯示發貨倉庫，自提地點等，並且訂單最終會流轉到該系統進行發貨操作。
6. 支付系統 ：顯示支付方式(如貨到付款、在線支付等)、並且在支付的時候計算該會員實際應付的金額，以及顯示銀行卡信息等。
7. 物流系統： 顯示配送時間、配送方式、運費等，並且在訂單發貨後會顯示實際的配送路徑。
8. 財務系統： 顯示開票信息等，在訂單完成後會生成發票。
9. 內容系統： 顯示訂單留言等
個人認為訂單的輸入(亦可稱之為來源)可分為內部和外部兩種方式：
1. 內部： 即自建商城傳輸過來的訂單；
a. 自建商城的訂單系統涉及的其他系統比較多，基本上上圖所示的系統都涉及到了。
b. 自建商城訂單在訂單創建時有著更多的判斷邏輯，如是否需要事先拆單的、優惠信息是否可用、商品庫存是否滿足要求、會員是否正常等
c. 內部訂單由於存在支付的動作，所以會有多出待付款，待評價這2個狀態，
d. 內部訂單由於涉及支付和營銷，所以對訂單系統的並發能力、負載能力以及支付能力有相當高的要求，每一步都不允許出錯，一旦出錯就意味著營業額的損失和用戶的流失。
e. 訂單數據計算和處理的要求更高，商品多少金額，優惠了多少金額，抵扣了多少金額，實付多少金額等都需要准確計算，在財務報表內能夠清晰展示。
2. 外部： 即第三方系統傳輸過來的訂單，一般代表性的就是分銷訂單，如供應商的訂單系統會接收外部系統的訂單，
a. 第三方系統傳輸的訂單，由於訂單比較獨立，所以涉及的相關系統會少很多。
b. 第三方訂單在訂單接收時主要判斷傳輸方是否有資格，商品是否上架狀態，庫存是否滿足，收貨人信息是否完整等。
c. 由於該類訂單相對來說不需要很高的實時性(意思是該類訂單對於消費者來說已經付款了，現在只是後端處理)，所以對介面負載性能等要求相對就沒有那麼高。
d. 訂單數據處理方面，一般都是線下核對賬單，線下結算款項，所以主要在數據記錄和處理的准確性方面有很高要求。
以上就是訂單的輸入，接下來我們聊訂單的處理。
個人認為主要有3種處理方式：
1. 流轉處理
在訂單系統內，系統會對訂單進行各種邏輯規則判斷，判斷後就會根據業務規則分發訂單，可簡單看示例圖：
基本上訂單的流轉處理是秒級，甚至是毫秒級就能處理完畢的，不能處理的或者處理失敗的都會把訂單歸類到異常訂單。
下面是訂單各狀態的流程圖：
2. 發貨處理
訂單一般流轉到倉庫進行發貨操作，發貨後倉庫會把物流信息回傳到訂單系統，訂單系統接收消息後會對訂單進行發貨：
a. 如果是內部訂單則訂單狀態直接改變(消費者端也會同步看到訂單狀態變化)；
b. 如果是外部訂單則會通過介面告訴第三方系統該訂單的物流信息；
3. 特殊情況處理
在特殊情況下，就需要對訂單進行人工處理，例如訂單無法流轉到下一級、訂單有備注等。人工處理的結果可能是跟消費者協商後讓其退款，也可能是手動的傳輸訂單等。
1. 內部訂單：
內部訂單的完成並不在發貨後就完成，一般來說在客戶接收到訂單商品後即算完成。但是對不同類型的商城有所區別：
a. 自營商城：一般客戶收貨後就完成訂單，例如京東。
b. 非自營商城：客戶需要自己點擊確認收貨或經過一段時間後系統自動確認收貨。
2. 外部訂單：
外部訂單系統訂單一般在發貨後就算完成。
1. 在我們設計訂單系統的時候應該先思考下公司業務類型和邏輯，理清業務上訂單流的起止。理清後從訂單源頭開始設計訂單系統：
a. 如果是自建商城類的那麼訂單模塊會涉及到其他系統，需要與其他系統的產品經理(如多人)去討論，如何讓訂單系統與他們負責的系統進行對接；如果是供應鏈類型的訂單系統，則需要考慮如何讓訂單能夠從外部順利傳輸到系統，是我們提供統一標準的API呢還是我們去各自對接第三方系統等等。
b. 考慮輸入方式後，我們就要依據公司業務運營方式來考慮訂單的處理邏輯，訂單進入系統後如何 讓系統自動處理訂單，依據什麼規則；同時也要考慮對異常訂單的處理。
c. 在考慮好訂單處理邏輯後，就要考慮如何輸出訂單，是直接輸出給WMS還是會再輸出給其他ERP等等。由於是自動化的輸出，也就要考慮與其他系統的對接方式。
d. 最後，我們就要用把公司業務代入到系統內，看看是否能行程閉環，是否還有欠缺或者是否遺漏了細節等。
2. 訂單管理系統涉及的其他系統比較多，所以在系統設計上應該具有獨立性、拓展型和准確性，獨立性代表訂單系統的維護或者異常不會影響到其他系統；拓展型代表訂單系統在以後增加功能的時候方便快捷；准確性是指訂單數據涉及到財務方面，所以應該嚴謹和准確。
3. 後台系統訂單頁面的設計：
a. 訂單列表頁面的設計
根據公司業務需要來設計列表頁展示的數據和布局，以及篩選查詢的關鍵欄位，具體可看示例圖：
b. 訂單詳情頁的設計
訂單詳情頁一般來說是模塊化的展示設計，訂單基礎信息、商品信息、物流信息、支付信息等都需要有所區分，這樣設計有利於詳情快速查看以及在系統研發的過程中讓開發小哥哥不容易搞錯哦，具體可看示例圖：
c. 訂單規則設計
訂單規則根據業務的大小有簡單和復雜，所以具體需要看業務規模。如果公司現階段剛起步，則訂單規則可直接寫進訂單系統；如起步有一段時間了或者發展比較快，則可事先就開發好訂單規則模塊，以後有新的訂單規則直接通過運營人員設置即可，更加的方便和更快速的適應業務的發展。
Ⅳ 如何從0到1進行電商訂單系統的搭建
搭建電商訂單系統，你可漏悄兄以在大平台上開個店，也可以借用一些雲平台付費開店，當然如果你有開發團隊，也可以自己開發搭建出一個電商訂單系統出來。
1、在主流平台上開店鋪
比如淘寶、天貓、京東、拼多多、當當等，外貿則在亞馬遜、速賣通等平台。
2、藉助雲平台開店
比如在微盟等雲平台上開個店鋪，利用雲平台提供的系統進行運營。返襲
3、自建電商平台
找專業系統開發公司自建電商平台，自己有開發團隊，也可以自己開發系統。
我這里著重講下自建電商平台，如何從0到1進行搭建：
1、開發系統或購買系統
開發系統首先要選用開發語言，市面上主流的有JAVA、PHP、.NET等；資料庫選型主要有MsSQL、MySQL、Oracle等。
選好了開發語言和資料庫類型，我們來看下B2C電商系統主要包含運跡哪些功能是需要開發的。所謂B2C就是商家自營銷售商品給終端客戶，主要模塊包含：系統配置、商品管理、會員管理、訂單管理，營銷管理、庫存管理、內容管理、財務管理、數據報表。
（如果是直接購買的電商系統，請忽略這一步）
2、購買伺服器或空間
伺服器用於存放你的電商系統和資料庫文件
3、購買域名
域名可以給客戶訪問，或用於介面調用
4、域名備案
國家規定域名都需要備案
5、系統部署
將開發或購買好的電商系統部署到伺服器上
6、域名解析
將域名解析到伺服器上
7、申請在線支付
申請微信支付、支付寶等第三方在線支付賬號，集成到電商系統裡面
8、其它
如果使用的是小程序，則必須申請SSL證書，才能調用介面
這些搭建完後，你就可以在系統後台去配置各種參數和內容了。
Ⅳ 如何自己做一個訂單管理系統
自己做訂單管理系統的方法如下：
一、設計思路
首先，先明確訂單相關的業務流程，設計要保證每個流程環環相扣。在這個基礎上，為了能從【采購訂單入庫】，到【簽訂發貨】，再到後續的【財務收付款對賬】，整個的流程一氣呵成，再對財務單獨收付款部分進行功能設計，以幫助我們實現一站式管理。
4、庫存管理：簡化流程，解決進銷存難題。庫存管理包括庫存出庫、庫存檔點、實際庫存三部分，其核心是確保與訂單相關的業務流程（銷售+客戶+財務+產品+庫存+采購），把每個流程推得動、用得了。
5、財務管理：財務明細分析，明朗徹底。采購訂單若是現結清，系統自動生成付款單待辦，由財務去結款；若是月結，則會在固定時間提醒財務去付款；銷售發貨若是現結清，系統會自動生成回款單待辦，由財務去核對入賬賬目，若是月結，固定時間提醒財務收款。
Ⅵ 訂單系統：看似簡單的「訂單售後」，背後竟隱藏這么多的設計細節
訂單的售後類型可分為退款、退貨退款及換貨。下面分別說明各類型的售後申請。
單純的退款一般發生在用戶支付後，訂單還未發貨的中間過程，此時用戶可申請僅退款。用戶申請退款後，系統直接校驗通過，不需要人工審核干預，系統直接進行支付通道的原路退款。
用戶申請退款時，可選擇需要退款的商拿衫品及數量，即支持用戶申請全部貨物退款，也可以申請部分貨物退款。用戶需要選擇退款原因，退款原因由後台系統提供。單純性退款的原因一般為型號/參數選錯、不想要了等原因。申請退款的頁面根據用戶選擇退款的商品及數量，自動計算退款金額。如果用戶申請的的是整單貨物全部退款，此時退款金額包含了商品金額+運費金額。優惠券、積分抵扣等各類優惠減免的費用是不會退還的。
商家發貨後，無論用戶是否收到貨物都可以申請退貨退款。退貨退款一般需要經過商家後台的人工審核，用戶方能退回貨物，系統在進行原路退款。
用戶申請退貨退款時，同樣需要選擇退貨的商品及數量，系統支持整單貨物全部退貨退款，也支持部分貨物退貨退款。系統根據用戶選擇退貨的商品，計算退款金額，運費與各類優惠金額不執行退款，系統僅退還商品金額。退貨退款時，用戶也需要選擇退貨原因，退貨原因一般為後台定義並提供給前端系統。退貨的原因一般為：型號/參數選錯，質量問題，參數與商品描述不符、其他原因等幾種原因類型。申請退貨退款時，用戶還需要上傳商品照片（用於商家確認貨物是否損壞）。用戶申請退貨時，系統還支持用戶填寫退貨說明的備注信息，用於和商家溝通，方便商家審核盡快給出審核結果。
用戶收到貨物，如果對貨物質量不滿意，可申請換貨。換貨申請提交後，需要經過商家的審核，審核同意後用戶寄回貨物，商家重新發貨。
用戶申請換貨時，同樣需要選擇商品及數量，支持貨物全部退換和部分退換。選擇換貨原因，換貨原因一般為後台系統定義並提供。常見的換貨原因為：型號選錯/參數選錯、質量問題、參數與商品描述不符、其他原因。申請換貨，用戶需要上傳貨物的照片（無圖無真相）。
單純退款用戶提交申請後，系統生成退款售後工單，此類售後退款不需要經過系統審核，系統直接予以原路退款。若用型敏坦戶申請的是整單退款，則退款金額包含商品金額+運費，不退款優惠金額及其他抵扣金額。
1、買家填寫信息，提交退貨退款申請，系統生成退貨售後工單。
2、商家通過管理後台審核退貨工單，審核時商家可以根據實際情況收取用戶一定的服務費（需要與買家溝通），從而修改退款金額。若審核通過則進入下一步，若審核不通過，則換貨流程終止。審核不通過，商家可以通過後台編輯不通過原因，告知買家不通過的原因。
3、買家寄回貨物，買家可以通過商城預約快遞上門取件（商城與第三方快遞服務商完成技術對接），完成貨物退回。
4、貨物寄回後，系統根據商家審核後的退款金額，執行原路退款。
1、買家填寫信息，提交換貨申請，系統生成換貨售後工單。
2、商家通過管理後台審核換貨工單，審核通過進入下一步，審核不通過換貨終止；
3、家寄回貨物，買家可以通過商城預約快遞上門取件（商城與第三方快遞服務商完成技術對接），完成貨物退回。
4、商家收到貨物，進行退貨入庫，挑選商品重新發貨
5、買家收到貨物，確認收貨，換貨流程正常結束，完成換貨。
每一步的售後操作都會產生一個對應的狀態，下面分別說明各類型售後的狀態。
買家填寫信息，提交退款申請後，生成退款售後單，流程進入待退款狀態，系統執行退款後，工單變更為已完成狀態。
1、買家填寫信息，提交退貨申請後，生產退貨售後工單，工單進入待審核狀態。
2、商家通過後台審核，審核通過，工單則進入待退貨狀態。
3、買家通過商城發貨寄回貨物，工單則進入待退款狀態。
4、系統進行原路退款，工單則進入已完成狀態。
1、買家填寫信息，提交換貨申請後，生成換貨售後工單，工單進入待審核狀態。
2、商家通過後台審核，審核通過，工單則進入待退貨狀態。
3、買家通過商城發貨寄回貨物，工單則進入待換貨狀態。
4、商卜桐家挑選貨物重新發貨，工單則進入換貨中狀態。
5、買家收到貨物，確認收貨，工單則進入已完成狀態。
在前台商城，售後工單的展示一般分為售後列表展示和售後詳情頁展示。
售後列表頁展示所有的售後工單，列表頁的售後單支持按售後類型、售後申請時間、售後狀態等條件進行篩選，支持按售後編號、訂單編號搜索售後工單。售後類型包含全部、退款、退貨退款和換貨。售後申請時間為一個日期時間段。售後狀態包含全部、待審核、審核通過、審核拒絕和已完成。
售後列表展示的信息主要包含：店鋪名稱、商品標題、商品規格、商品圖片、商品數量、退款金額（換貨不展示）、售後類型（退款/退貨/換貨））、售後狀態（待審核/審核通過/審核拒絕/已完成）、售後申請時間、售後編號、訂單編號等。大家可以根據自己實際業務需求進行展示。
售後詳情頁展示售後工單的完整信息，向用戶展示了售後商品信息、售後工單信息、售後流程、甚至商家信息等。
商品信息包含申請售後的商品名稱、規格、數量、圖片，各商品申請的退款金額，該工單商品累計退款金額。售後工單信息包含申請售後時間、售後編號、訂單編號、售後類型、售後原因、售後單狀態。售後流程清晰的向用戶展示該筆售後工單需要經過的流程步驟、以及每一步的時間節點，每一步操作後訂單所處的當前狀態。商家信息則展示店鋪名稱、商家的聯系方式、與商家的溝通記錄等內容。
退貨、換貨類的售後單詳情頁還應展示退貨、換貨的快遞方式、快遞單號及物流軌跡信息。物流軌跡信息可通過與第三方快遞服務商（如快遞100）進行技術介面對接，抓取物流軌跡信息。
平台作為連接商家與買家的紐帶，應努力為買家與商家之間搭建一個有效溝通的橋梁。售後處理的中間過程，免不了有很多需要溝通的事宜。平台方可以根據自己的資源與實際開發情況為買家與商家之間提供以下溝通渠道：
1、平台展示商家的有效聯系方式、聯系人或地址信息。
2、鼓勵商家將售後、售前咨詢的問題整理成FAQ問題腳本，供買家查閱。
3、平台為商家與買家提供在線客服等溝通工具，方便商家與買家能夠實時的在線交流，提高溝通的效率。在溝通的過程中，能夠支持買家與商家選擇特定的售後單、訂單發起進行溝通，提升溝通的質量與效率。
售後服務作為訂單履約服務的重要一環，各電商平台都很重視訂單的售後服務，盡可能的降低用戶售後的操作門檻、盡可能快速的解決用戶的售後問題。無論是在售後的流程、售後的操作、售後的溝通上，各電商平台都應為用戶提供良好的售後服務體驗。線上流量已進入存量維護環節，各電商平台都應重視老用戶的訂單履行體驗。做好售後服務，為留住存量用戶，提升用戶復購貢獻一份力量。
有關訂單系統的前台設計目前已經基本完結，後續再與大家討論分享有關訂單系統的後台設計。
Ⅶ 電商訂單系統設計原理主要用了什麼技術
電子商務系統的總體結構設計是在系統體系結構的基礎上，針對企業電子商務的目標，界定系統的外部邊界和介面，刻畫系統的內部成及其相互關系，明確目標系統的各個組成部分、各個組成部分的作用及其相互關系。 系統總體結構設計包括如下內容： 1．確定系統的外部介面 通過分析，將電子商務系統與其外部環境區分開來，從而使總體設計有一個明確的范圍。系統與其外部環境的介麵包括以下方面： （1）與企業合作夥伴之間的介面； （2）與企業內部既有信息系統的介面； （3）與交易相關的公共信息基礎設施之間的介面； （4）其他介面如態爛，如企業與政府或其他機構之間的介面。 2．確定系統的組成結構 系統組成結構主要說明目標系統內部的組成部分，以及系統內部與外部環境的相互關系。 方法： 隨著Internet技術的發展，人們的日常生活已經離不開網路。未來閉陪社會人們的生活和工作將越來越依賴於數字技術的發展，越來越數字化、網路化、電子化、虛擬化。電子商務也隨著網路的發展日益和人們的生活貼近。本設計嘗試用ASP在網路上架構一個動態的電子商務網站，以使每一位顧客不用出門在家裡就能夠通過上網來輕松購物。在本設計中，我主要完成了後台功能的實現，實現了登錄功能，圖書管理，圖書分類管理，訂單管理，用戶管理等功能。 本文中所做的主要工作如下： (1)簡單介紹了電子商務，分析了電子商務的現狀； (2)介紹了IIS+ASP系統的一般原理； (3)闡述整個系統的系統結構及工作原理；分析了系統實現中的特殊性、難點和重點； (4)分析並解決實現中的若干技術問題； 附： 方案設計主要依靠設計者的經驗，作出技術和結構的選擇，並以有組織的文檔反映，作為與客戶交流論證方案，交付系統開發人員實施的依據，方案設計的基礎是業務環境說明書。業務環境說明書重新組織系統需求，給出解決方案的業務運作方式。在系統需求相對簡單時不一定需要，如果系統需求較為復雜時，以文字和圖表的方式系統地說明業務環境可以使系統需求更加清楚，業務環境說明書可以採用三種文檔結構。 * 業務流程圖：業務流程圖描述企業的業務在新系統中如何運作，說明新系統的業務運作模式如何解決客戶的要求，指出客戶的業務流程因為新系統的應用而作出那些更改。業務流程圖是一種直觀的工具，向客戶解釋新系統的作用，徵求使用者的配合與支持，能提高新系統的實際效能。 * 操作規程說明：相對於業務流程圖這種較高層概括的文檔，普通用戶可能更需要一份詳細的操作規程說明，以便更好地理解系統的功能與使用。操作規程說明以易被最終用戶理解的詞語描述，避免使用過分專業的詞語。操作規程說明仍屬於高層設計文檔，不是最終的操作步驟說明。操作規程說明規定了系統活動的框架， * 處理流程圖 ： 細化操作規程中描述的活動，由事件和處理流組成。事件是活動開始的條件，處理是活動中的具體工作。處理流程圖的描述層次接近詳細設計。以客戶在網上購貨為例，最後一步是確認付款，操作規程說明只需簡單地說明：「客戶檢查付款額後確認」，處理流程圖的說明比較詳細，激發活動的事件是客戶按下「付額」按鈕，處理是付款總額從資料庫中統計出來，顯示在瀏覽器上，最後由客戶按「確認」按鈕確認。 當前普遍採用對象技術描述復雜的應用結構，電子商務系統一般用Java,EJB,CORBA等對象技術實現，在系統設計階段，編制業務環境書時採用面向對象分析和設計方法可以提高實施階段的效率。業務環境說明書中的設計文檔完成後，召開第二次項目會議，在會上以圖表的形式向客戶和項目開發人員介紹系統設計的概貌。著重與客戶討論兩個問題，檢查系統設計是否滿足客戶需求： 系統設計在多大程度上解決了用戶的需求？是否准確地實現了客戶的期望，既沒有過分簡單化，也沒有過分復雜化。 系統設計的功能范圍是否包含了用戶提出的所有需求？ 應用開發人員參加項目會議，可以更好地了解客戶的業務環境與方案設計的總體結構，與客戶和系統設計者直接交談，減少溝通的誤差，提高效渣漏率。 IBM為電子商務系統定義了一套完整的電子商務應用框架，基於三層次體系結構集成企業核心系統與互聯網服務，多層次結構使企業內部應用系統無需作重大更改，通過與互聯網伺服器的連結就可以在互聯網上提供服務，實現電子商務系統的目標。 基於電子商務應用框架的電子商務系統體系結構共有八個主要部分。直接支持應用程序運行的模塊有六個：客戶端、網路連接、互聯網伺服器、應用邏輯、中間連接件、核心數據與應用，其餘兩個模塊安全性和系統管理與這六個模塊都有關聯，系統設計者可相對獨立地設計安全性體系和系統管理體系，在應用程序運行支持模塊的實現中加入相應的技術與處理。安全性和系統管理的效率是系統的整體性效果，應用系統運行的每一個環節都能影響系統總體的安全性和可管理性。
Ⅷ 業務梳理-電商-訂單管理模塊
Java工程師知識樹
訂單中心是一個電商後台系統的樞紐，在這訂單這一環節上需要讀取多個模塊的數據和信息進行加工處理，並流向下一環節；因此訂單模塊對一電商系統來說，重要性不言而喻。
同時，訂單是一個公司生存甚至盈利的核心，而電商系統中的訂單系統則是支撐訂單處理的載體，因此訂單系統的設計則十分重要。
要了解訂單系統，首先我們要從訂單系統的信息架構上去認識訂單系統，從而對訂單系統建立整體認知；
定義：為適應組織分工的需求和提升效率，系統將整個交易業團如務流程拆分成若干個可控的環節。
1.在訂單過程中進行安全校驗，主要是為了檢測用戶是否在黑名單上，用戶購買行為是否正常等，當檢測到不正常時終止下單；
2.從商品中心獲取塌轎啟商品信息（SKU，規格，價格等）
3.從營銷中心獲取商品，訂單促銷信息（優惠券,促銷活動）,判斷是否滿足優惠條件，計算出優惠金額。
4.在會員中心獲取會員權益，例如平台抵扣積分，優惠券折扣條件等。
5.在調度中心檢驗銷售層庫存，按照調度規則鎖定區域庫存。
6.根據拆單規則（商家，倉庫，訂單類型等）將訂單拆分成若干個子訂單，根據運費模板計算運費，根據商品金額，運費，優惠金額計算應付金額（實付款）。
定義：是指在實際銷售中將訂單的優惠去分攤到每一件SKU中去結算。
訂單實付金額=商品金額（SKU金額總計）+運費-總優惠金額
總優惠金額=促銷活動優惠金額+優惠券優惠金額+虛擬幣抵扣金額
按照商品比例分攤。
案例：
訂單中有甲乙兩店的商品A、B、C、D、E 包郵。商品A，D參加跨店滿200減40的活動（活動1），商品B，C參加滿100減10的活動（活動2）另外用戶還使用了100元現金券。
訂單優惠金額=40+10+100=150元.
依據優惠分攤原則：則各項的優惠金額為：
定義：為了方便訂單的發貨與結算，系統依據一定的規則（物流、倉庫等因素）將用戶訂單拆分成若干個發貨單。
不同店鋪：在電商平台類架構下，由於商品歸屬權不同，涉及財務結算和物流發貨的問題，需要根據店鋪歸屬問題對訂單進行拆單。例如淘寶，天貓的商品在下單時會將訂單根據不同店鋪進行拆分成若干個子訂單。
不同倉庫：若同一訂單分散在不同倉庫，則應按照倉庫歸屬進行拆分訂單。當一件商品在多個倉庫有貨時，應根據物流的區域的時效選擇倉庫進行拆單。
不同品類：由於商品的屬性不同一樣會產生拆單需求，例如易碎品需要特殊包裝，超大物品（鋼琴，座椅）需要單獨包裝。有些商品不能放在一起，同樣需要拆單。
物流因素：不同物流公司對單個包裹的重量或體積都有特殊要求，需要根據帆洞SKU的毛重和體積來計算包裹的總重量和體積，超出物流公司限制的也需要拆單。
商品價值：根據商品價值需要拆單的主要涉及海淘和跨境的商品；國家對每筆跨境訂單有單次限額，對年度跨境商品訂單總金額也有限制，當單次購買金額超過限制金額時，也需要對訂單進行拆單。
訂單正向流程相對常規，業務雖然從商品中心，物流，會員，倉庫，內容等各大模塊進行數據交互，但涉及的業務邏輯易於理解，所以難度並不大。
但在訂單逆向流程中，業務流程和邏輯則相對復雜。因為在訂單正向流程中，每一個環節都有可能觸發逆向訂單任務流；而在訂單正向任務流中，每一個子環節上的商品在後台出庫發貨流程中所處的具體節點不一致，所以不同節點觸發的訂單逆向流程的處理規則則有差異。
定義：訂單逆向流程是為了解決在訂單流程中出現的退貨退款的業務流程。在前端訂單狀態下，各個環節都有觸發的可能，而訂單的不同節點觸發訂單逆向流程的處理方式不同。訂單觸發訂單逆向流程，可以按照主體與客體劃分，可分為用戶端觸發和商家端觸發兩種。
1. 待付款取消訂單
說明：待付款訂單取消訂單分為兩種情況：
在待付款訂單狀態下，取消訂單無需客服審核。流程圖如下：
2. 待發貨取消訂單
說明：在待發貨訂單狀態下取消訂單時，此時應根據訂單此時所在的節點作出處理。
由於訂單在支付完成後，發貨單可能已經推送至WMS，甚至已經交接發貨，狀態未及時回傳更新。為避免貨款兩失，要先暫停訂單出庫，在調度中心查詢訂單是否推送至倉庫。
若尚未推送至倉庫，則停止推送至倉庫；若已經推送至倉庫，則去wms中心去攔截，攔截成功則暫停出庫。
3. 待收貨/交易成功退貨
說明：在用戶提交退貨申請後，需經過客服審核。審核通過則回到原有狀態，審核通過後則進入退貨流程並告知用戶退回地址及收件信息，此時進入退貨流程。系統生成退貨入庫單，當倉庫收貨後，進行退款。
在待收貨狀態下平台設計者仍需考慮退貨是否全退的問題。當SKU全退時，原訂單則中止進入交易關閉狀態。當訂單中發生部分退貨時，原訂單的狀態不變，維持待收貨或交易成功狀態，同時退貨的部分生成交易售後訂單。剩餘未退貨部分仍然允許申請售後。
注意：在訂單流程逆向流程中，涉及到財務數據的處理時 ，為了保證財務數據的真實性及可追溯性（這與會計數據的處理原則有關，具體問下會計或者財務同學），都不能直接在原訂單狀態下修改，因此在設計訂單逆向流程時應注意這一點。
Ⅸ 基礎平台設計-訂單系統（一）
在互聯網公司里，都會涉及到中台管理端，或被稱OSS，或稱Console。它主要承擔的職責是對底層的基礎模塊、數據等進行可視化，便於管理端的業務操作人員更加簡單、高效、便捷的處理事務。本文重點介紹【訂單系統】的框架結構、流程、狀態機扭轉、欄位設計，作為【訂單系統】系列文章的開篇。
訂單系統處於承上啟下的關鍵位置
1.1、 對於用戶端，如APP、小程序、PC等，用戶對訂單的增刪改查（查詢訂單、確認訂單、取消訂單、支付衡亮純訂單等等），均需要向訂單系統發出請求並由其來完成對應的操作。
1.2、 對於底層公共服務，如用戶系統（用戶的基礎鍵隱信息，如姓名、昵稱、手機號等）、交易系統（微信支付、支付寶支付）、消息系統（向用戶觸達消息，APP PUSH、簡訊、彈窗等）。則聽令於訂單系統的調遣，協助訂單系統完成閉環流程。
1.3、 另外。咐咐不同類型的訂單涉及的相關模塊也不盡一致。如電商類訂單，則必然涉及商品模塊；為了營銷目的而產生的各類優惠券，也會屬於訂單的一個屬性。當然，訂單必不可少是是發起訂單的主體，也就是用戶，所以與用戶模塊息息相關。
訂單系統可簡可繁，隨著業務的處在不同的階段，訂單系統也會隨之發生改變。從流程上看，一般可以認為基礎的流程有4大塊：訂單創建、訂單支付、訂單確認、訂單完成/關閉。
以下通過幾類常見互聯網商品的訂單，展示訂單的流程及狀態機扭轉：
2.1、虛擬商品（如會員卡、在線課程、名師咨詢等）
2.2、實物商品（涉及物流，商家發貨、買家確認等）
一筆訂單涉及到的欄位，基本上可以由下述腦圖概述完整。一般我們考慮：用戶信息、商品信息、支付信息、狀態信息、促銷信息、配送信息、時間信息等。
我們在設計時，可引入中台的概念，做好欄位拓展，如【 訂單渠道 】。這樣，即使後續業務越來越多，從一開始設計的訂單系統，通過訂單渠道進行區分，也可大大的對不同業務進行兼容和拓展。