京寵展信息指南
1054
2023-02-23
訂單管理系統(tǒng)流程圖（如何自己做一個訂單管理系統(tǒng)）
本篇文章給大家談?wù)?a target="_blank" href="http://m.bai1xia.com/news/tags-14359.html"style="font-weight:bold;">訂單管理系統(tǒng)流程圖，以及如何自己做一個訂單管理系統(tǒng)對應(yīng)的知識點，希望對各位有所幫助，不要忘了收藏本站喔。
今天給各位分享訂單管理系統(tǒng)流程圖的知識，其中也會對如何自己做一個訂單管理系統(tǒng)進行解釋，如果能碰巧解決你現(xiàn)在面臨的問題，別忘了關(guān)注本站，現(xiàn)在開始吧！
關(guān)于商品的文章里面，訂單管理系統(tǒng)流程圖我們已經(jīng)從商品的輸入、維護、輸出的流程來介紹了商品系統(tǒng)，那訂單也一樣，訂單管理系統(tǒng)流程圖我們本文把訂單看成一個流程即訂單流來理解。
訂單系統(tǒng)會與購物車、商品系統(tǒng)，營銷系統(tǒng)、會員系統(tǒng)、支付系統(tǒng)、物流系統(tǒng)、倉庫系統(tǒng)、財務(wù)系統(tǒng)、內(nèi)容系統(tǒng)，具體請看示例圖：
1.? 購物車 ：個人認為是訂單的起點，商品會被加入購物車，然后會被提交
2.? 商品系統(tǒng)： 在提交訂單頁面會看到該訂單所包含的商品信息，例如商品名稱、所購買數(shù)量、價格、售后信息等
3.? 營銷系統(tǒng)： 會顯示商品是否優(yōu)惠信息，例如滿減、優(yōu)惠券
4.? 會員系統(tǒng)： 會顯示該會員是否有基于會員等級的折扣信息(如淘寶的88會員)，或是否有可抵扣金額的會員點數(shù)(如京豆)；會顯示該會員下面的收貨地址信息、也會顯示該會員下面是否有充值卡、運費券等。
5.? 倉庫系統(tǒng)： 基于收貨地址信息顯示發(fā)貨倉庫，自提地點等，并且訂單最終會流轉(zhuǎn)到該系統(tǒng)進行發(fā)貨操作。
6.? 支付系統(tǒng) ：顯示支付方式(如貨到付款、在線支付等)、并且在支付的時候計算該會員實際應(yīng)付的金額，以及顯示銀行卡信息等。
7.? 物流系統(tǒng)： 顯示配送時間、配送方式、運費等，并且在訂單發(fā)貨后會顯示實際的配送路徑。
8.? 財務(wù)系統(tǒng)： 顯示開票信息等，在訂單完成后會生成發(fā)票。
9.? 內(nèi)容系統(tǒng)： 顯示訂單留言等
個人認為訂單的輸入(亦可稱之為來源)可分為內(nèi)部和外部兩種方式：
1.? 內(nèi)部： 即自建商城傳輸過來的訂單；
a.? 自建商城的訂單系統(tǒng)涉及的其他系統(tǒng)比較多，基本上上圖所示的系統(tǒng)都涉及到了。
b.? 自建商城訂單在訂單創(chuàng)建時有著更多的判斷邏輯，如是否需要事先拆單的、優(yōu)惠信息是否可用、商品庫存是否滿足要求、會員是否正常等
c.? 內(nèi)部訂單由于存在支付的動作，所以會有多出待付款，待評價這2個狀態(tài)，
d.? 內(nèi)部訂單由于涉及支付和營銷，所以對訂單系統(tǒng)的并發(fā)能力、負載能力以及支付能力有相當高的要求，每一步都不允許出錯，一旦出錯就意味著營業(yè)額的損失和用戶的流失。
e.? 訂單數(shù)據(jù)計算和處理的要求更高，商品多少金額，優(yōu)惠了多少金額，抵扣了多少金額，實付多少金額等都需要準確計算，在財務(wù)報表內(nèi)能夠清晰展示。
2. ? 外部： 即第三方系統(tǒng)傳輸過來的訂單，一般代表性的就是分銷訂單，如供應(yīng)商的訂單系統(tǒng)會接收外部系統(tǒng)的訂單，
a.? 第三方系統(tǒng)傳輸?shù)挠唵?，由于訂單比較獨立，所以涉及的相關(guān)系統(tǒng)會少很多。
b.? 第三方訂單在訂單接收時主要判斷傳輸方是否有資格，商品是否上架狀態(tài)，庫存是否滿足，收貨人信息是否完整等。
c.? 由于該類訂單相對來說不需要很高的實時性(意思是該類訂單對于消費者來說已經(jīng)付款了，現(xiàn)在只是后端處理)，所以對接口負載性能等要求相對就沒有那么高。
d. 訂單數(shù)據(jù)處理方面，一般都是線下核對賬單，線下結(jié)算款項，所以主要在數(shù)據(jù)記錄和處理的準確性方面有很高要求。
以上就是訂單的輸入，接下來我們聊訂單的處理。
個人認為主要有3種處理方式：
1. 流轉(zhuǎn)處理
在訂單系統(tǒng)內(nèi)，系統(tǒng)會對訂單進行各種邏輯規(guī)則判斷，判斷后就會根據(jù)業(yè)務(wù)規(guī)則分發(fā)訂單，可簡單看示例圖：
基本上訂單的流轉(zhuǎn)處理是秒級，甚至是毫秒級就能處理完畢的，不能處理的或者處理失敗的都會把訂單歸類到異常訂單。
下面是訂單各狀態(tài)的流程圖：
2. 發(fā)貨處理
訂單一般流轉(zhuǎn)到倉庫進行發(fā)貨操作，發(fā)貨后倉庫會把物流信息回傳到訂單系統(tǒng)，訂單系統(tǒng)接收消息后會對訂單進行發(fā)貨：
a.? 如果是內(nèi)部訂單則訂單狀態(tài)直接改變(消費者端也會同步看到訂單狀態(tài)變化)；
b.? 如果是外部訂單則會通過接口告訴第三方系統(tǒng)該訂單的物流信息；
3. 特殊情況處理
在特殊情況下，就需要對訂單進行人工處理，例如訂單無法流轉(zhuǎn)到下一級、訂單有備注等。人工處理的結(jié)果可能是跟消費者協(xié)商后讓其退款，也可能是手動的傳輸訂單等。
1. 內(nèi)部訂單：
內(nèi)部訂單的完成并不在發(fā)貨后就完成，一般來說在客戶接收到訂單商品后即算完成。但是對不同類型的商城有所區(qū)別：
a. 自營商城：一般客戶收貨后就完成訂單，例如京東。
b. 非自營商城：客戶需要自己點擊確認收貨或經(jīng)過一段時間后系統(tǒng)自動確認收貨。
2. 外部訂單：
外部訂單系統(tǒng)訂單一般在發(fā)貨后就算完成。
1.? ?在我們設(shè)計訂單系統(tǒng)的時候應(yīng)該先思考下公司業(yè)務(wù)類型和邏輯，理清業(yè)務(wù)上訂單流的起止。理清后從訂單源頭開始設(shè)計訂單系統(tǒng)：
a. 如果是自建商城類的那么訂單模塊會涉及到其他系統(tǒng)，需要與其他系統(tǒng)的產(chǎn)品經(jīng)理(如多人)去討論，如何讓訂單系統(tǒng)與他們負責(zé)的系統(tǒng)進行對接；如果是供應(yīng)鏈類型的訂單系統(tǒng)，則需要考慮如何讓訂單能夠從外部順利傳輸?shù)较到y(tǒng)，是我們提供統(tǒng)一標準的API呢還是我們?nèi)ジ髯詫拥谌较到y(tǒng)等等。
b. 考慮輸入方式后，我們就要依據(jù)公司業(yè)務(wù)運營方式來考慮訂單的處理邏輯，訂單進入系統(tǒng)后如何 讓系統(tǒng)自動處理訂單，依據(jù)什么規(guī)則；同時也要考慮對異常訂單的處理。
c. 在考慮好訂單處理邏輯后，就要考慮如何輸出訂單，是直接輸出給WMS還是會再輸出給其他ERP等等。由于是自動化的輸出，也就要考慮與其他系統(tǒng)的對接方式。
d. 最后，我們就要用把公司業(yè)務(wù)代入到系統(tǒng)內(nèi)，看看是否能行程閉環(huán)，是否還有欠缺或者是否遺漏了細節(jié)等。
2.? ?訂單管理系統(tǒng)涉及的其他系統(tǒng)比較多，所以在系統(tǒng)設(shè)計上應(yīng)該具有獨立性、拓展型和準確性，獨立性代表訂單系統(tǒng)的維護或者異常不會影響到其他系統(tǒng)；拓展型代表訂單系統(tǒng)在以后增加功能的時候方便快捷；準確性是指訂單數(shù)據(jù)涉及到財務(wù)方面，所以應(yīng)該嚴謹和準確。
3.? 后臺系統(tǒng)訂單頁面的設(shè)計：
? ? a. 訂單列表頁面的設(shè)計
根據(jù)公司業(yè)務(wù)需要來設(shè)計列表頁展示的數(shù)據(jù)和布局，以及篩選查詢的關(guān)鍵字段，具體可看示例圖：
? ? ?b. 訂單詳情頁的設(shè)計
訂單詳情頁一般來說是模塊化的展示設(shè)計，訂單基礎(chǔ)信息、商品信息、物流信息、支付信息等都需要有所區(qū)分，這樣設(shè)計有利于詳情快速查看以及在系統(tǒng)研發(fā)的過程中讓開發(fā)小哥哥不容易搞錯哦，具體可看示例圖：
? ? c. 訂單規(guī)則設(shè)計
訂單規(guī)則根據(jù)業(yè)務(wù)的大小有簡單和復(fù)雜，所以具體需要看業(yè)務(wù)規(guī)模。如果公司現(xiàn)階段剛起步，則訂單規(guī)則可直接寫進訂單系統(tǒng)；如起步有一段時間了或者發(fā)展比較快，則可事先就開發(fā)好訂單規(guī)則模塊，以后有新的訂單規(guī)則直接通過運營人員設(shè)置即可，更加的方便和更快速的適應(yīng)業(yè)務(wù)的發(fā)展。
選商品 → 加入購物車 → 確認購買（訂單結(jié)算） → 付款 → 等發(fā)貨 → 等物流送貨 → 貨到手簽收。
但是對于電商系統(tǒng)的來說，處理流程就復(fù)雜了。
舉例一點，比如任意的一處理節(jié)點，消費者都可能發(fā)起取消訂單，所以我們需要在某個地方設(shè)立訂單攔截，避免在取消了訂單的情況下發(fā)貨，保護成本。
通過分析后，做了以下業(yè)務(wù)流程圖。但暫未涉及到退貨（訂單的逆向流程）、ODS-訂單分發(fā)，VIS-供應(yīng)鏈，EBS-財務(wù)系統(tǒng)。
需要注意的是：
訂單生成的時候，需要進行對庫存進行一個占用操作，預(yù)先扣減。避免其它消費者同時下單時，最終訂單商品總數(shù)與庫存量不一致。
訂單生成了，需要去付款，才能走下一步的流程。超過期限未支付，需要把訂單占用的庫存復(fù)原回去。
訂單下行涉及到以下系統(tǒng)：
OMS：訂單管理系統(tǒng)。
WMS：倉儲管理系統(tǒng)。
TMS：運輸(物流)管理系統(tǒng)。
暫定地，在下行TMS物流配送前，設(shè)一個訂單-，在這之前取消的訂單，可以走取消訂單流程。一旦在這之后，視為已經(jīng)開始出貨，消費者想發(fā)起取消訂單，只能等收貨之后走退貨流程了。這是為了平臺/商家運費成本來考慮，如果是包郵的情況下更是如此。
當然，也有一些其它的平臺，是可以在物流層進行攔截的。這就需要商家與消費者協(xié)調(diào)運費的問題了。
在做訂單流程這一塊，參考了很多大神的文章，還有各種開源的商城軟件，都過于理論化，實操性不強，對于新手來說沒有一個實操的axure原型講解，都是在用流程圖告訴大家退款售后有哪些步驟，但是沒有一個具體的案例來分析。相信我，你是不可能一上來就做到像很多文章里寫得很完美訂單管理系統(tǒng)的，況且文章中連原型圖都沒有。其實，即使是天貓和京東，在售后方面也是有取舍的，設(shè)定好規(guī)則才能讓系統(tǒng)跑通，而不是說能夠應(yīng)付所有的異常情況。在設(shè)計之前，要考慮很多看似基礎(chǔ)，卻需要重視的規(guī)格，比如訂單管理系統(tǒng)流程圖：
1.是否支持部分退款，部分退貨？
2.是否支持換貨？
3.是否支持多次申請退款/退貨？
4.如果在售中時申請退款被拒絕了，還可不可以申請售后？
5.部分退款時，自動收貨時間到了怎么辦？如果退款申請拒絕了，訂單狀態(tài)怎么繼續(xù)走？
我這些只是舉例了冰山一角，對于訂單管理的確有很多異常分支情況和用戶錯誤操作。那我在這里既然說要用案例具體去講訂單的逆向流程，我就先要規(guī)定好我們商城的訂單規(guī)則：
1.待發(fā)貨前可以申請一次退款，發(fā)貨后可以申請一次售后（退貨/退款）
2.一筆訂單多種商品只能分開申請退款，不支持對訂單申請退款，意思是有一種商品時就是全退，有多種商品時就是只能部分申請退款。
3.訂單中暫不含優(yōu)惠券，只包括運費，在待發(fā)貨時部分退款，最后一筆申請會退運費；在已發(fā)貨后申請售后就不再退運費，其他原因走人工客服
以上就是我對訂單的設(shè)置的前提條件，有了前提條件，我再去跟技術(shù)評審，就讓他們心里也感覺到靠譜一些，畢竟第一次的時候他們提出了很多漫無邊際，非常離譜但是也會出現(xiàn)的異常情況，一開始得時候我真的很苦惱，后來才發(fā)現(xiàn)是我沒有設(shè)定規(guī)則，沒有規(guī)則，技術(shù)同學(xué)當然怕出現(xiàn)出現(xiàn)異常情況程序不知道怎么跑了。
用戶端訂單頁面
關(guān)于訂單的具體流程我就不多講了，大家都知道的，待付款，待發(fā)貨，待收貨，交易成功，待評價，那我們先來看看我是如何對訂單設(shè)置布局的
圖片所展示的，一筆訂單分為商品操作欄，交易狀態(tài)欄和操作欄，對于商品操作欄我是分開的，所以一筆訂單有多種商品時在申請退款的時候，一定是單個申請的；交易狀態(tài)欄是合并在一起的，這是對訂單整體進度的狀態(tài)顯示，在部分退款時顯示的訂單狀態(tài)；最后操作欄在確認收貨前都是合并在一起的，對整個訂單的簽收，當狀態(tài)為交易成功時，則會顯示商品的評價入口。
那么這里就涉及這三塊的狀態(tài)和操作功能的切換，我們先來看一下 退款單過程狀態(tài) 對商品操作欄的顯示影響
我前面有講，當處于待發(fā)貨狀態(tài)時，商品操作入口為“申請退款”；當已發(fā)貨后，商品操作就為“申請售后”，那退款單的狀態(tài)先去影響了商品操作欄的顯示。具體的細分狀態(tài)我在圖片中已經(jīng)詳細列出來了，包括異常情況該如何處理。
在看完退款單對商品操作的影響后，再來看看退款單對訂單狀態(tài)的影響，注意，退款單與訂單是多對一的關(guān)系，退款單和商品也是多對一的關(guān)系，所以才會有申請一次退款被拒絕了，還可以申請一次售后（退款/退貨）。下圖是 退款單結(jié)果狀態(tài) 對訂單狀態(tài)的影響
可以看出來每一種訂單都有部分和全部兩種影響，這里要注意，全部并不是一次對訂單提交的退款申請，而是查看到訂單中是不是所有商品都有退款單，并且都有結(jié)果。通過這樣表格的分析整理，會很清晰理解訂單狀態(tài)隨退款單的變化。
用戶端退款單界面
前面講了訂單頁面中訂單狀態(tài)的變化，具體的訂單詳情我就不做過多說明了，因為大家參考其他網(wǎng)站也可以很直觀的看到，接下來看退款管理的界面
根據(jù)我之前的設(shè)置的退款規(guī)則，這里的退款單一定是一種商品一個退款單（可能包含多件，因為規(guī)定申請退款是不能選擇退款數(shù)量，要么全退，要么客服聯(lián)系，因為后臺可以修改退款金額）。退款單分為兩種，僅退款和退貨退款，在待發(fā)貨時只能申請僅退款，在發(fā)貨后可以選擇申請退款或者是申請退貨，但是只有一次機會！
這里很多人就會說我不考慮用戶體驗問題，首先我想說京東一上來退款退貨規(guī)則也不完善，當然發(fā)展到今天他仍然還有很多不好的地方，當用戶的退貨申請被拒絕了你作為用戶怎么辦？京東的客服什么時候上線過，那個時候你只能網(wǎng)上發(fā)發(fā)牢騷。商城是從0到1，訂單模塊第一版的計劃就是用戶能下單，能退款，能退貨。至于為什么用戶不能一次申請所有商品的退款，為什么不能設(shè)置一種商品的退貨數(shù)量等，后期會加上批量選擇退款商品，設(shè)置退貨數(shù)量等，不斷優(yōu)化退款和退貨的流程圖。
這篇文章很適合產(chǎn)品新人來了解基礎(chǔ)的退款退貨的原型圖設(shè)計，畢竟這里不包含優(yōu)惠券，沒有拆單，也沒有調(diào)倉等等，所以大家看了文章覺得還可以的點個贊~不喜勿噴
這里就沒有展示具體的詳情頁面，所以可以底下留言找我要原型圖~ 關(guān)于訂單管理系統(tǒng)流程圖和如何自己做一個訂單管理系統(tǒng)的介紹到此就結(jié)束了，不知道你從中找到你需要的信息了嗎 ？如果你還想了解更多這方面的信息，記得收藏關(guān)注本站。 訂單管理系統(tǒng)流程圖的介紹就聊到這里吧，感謝你花時間閱讀本站內(nèi)容，更多關(guān)于如何自己做一個訂單管理系統(tǒng)、訂單管理系統(tǒng)流程圖的信息別忘了在本站進行查找喔。
本文目錄一覽：
簡談訂單管理系統(tǒng)(OMS)
訂單管理系統(tǒng)即處理訂單訂單管理系統(tǒng)流程圖的系統(tǒng)，主要管理訂單的輸入，處理，輸出。其在一般電商系統(tǒng)中或在有交易功能的系統(tǒng)中，都是核心系統(tǒng)/功能之一，有一定的復(fù)雜度；但是雖然復(fù)雜，并不代表理解起來困難。關(guān)于商品的文章里面，訂單管理系統(tǒng)流程圖我們已經(jīng)從商品的輸入、維護、輸出的流程來介紹了商品系統(tǒng)，那訂單也一樣，訂單管理系統(tǒng)流程圖我們本文把訂單看成一個流程即訂單流來理解。
訂單系統(tǒng)會與購物車、商品系統(tǒng)，營銷系統(tǒng)、會員系統(tǒng)、支付系統(tǒng)、物流系統(tǒng)、倉庫系統(tǒng)、財務(wù)系統(tǒng)、內(nèi)容系統(tǒng)，具體請看示例圖：
1.? 購物車 ：個人認為是訂單的起點，商品會被加入購物車，然后會被提交
2.? 商品系統(tǒng)： 在提交訂單頁面會看到該訂單所包含的商品信息，例如商品名稱、所購買數(shù)量、價格、售后信息等
3.? 營銷系統(tǒng)： 會顯示商品是否優(yōu)惠信息，例如滿減、優(yōu)惠券
4.? 會員系統(tǒng)： 會顯示該會員是否有基于會員等級的折扣信息(如淘寶的88會員)，或是否有可抵扣金額的會員點數(shù)(如京豆)；會顯示該會員下面的收貨地址信息、也會顯示該會員下面是否有充值卡、運費券等。
5.? 倉庫系統(tǒng)： 基于收貨地址信息顯示發(fā)貨倉庫，自提地點等，并且訂單最終會流轉(zhuǎn)到該系統(tǒng)進行發(fā)貨操作。
6.? 支付系統(tǒng) ：顯示支付方式(如貨到付款、在線支付等)、并且在支付的時候計算該會員實際應(yīng)付的金額，以及顯示銀行卡信息等。
7.? 物流系統(tǒng)： 顯示配送時間、配送方式、運費等，并且在訂單發(fā)貨后會顯示實際的配送路徑。
8.? 財務(wù)系統(tǒng)： 顯示開票信息等，在訂單完成后會生成發(fā)票。
9.? 內(nèi)容系統(tǒng)： 顯示訂單留言等
個人認為訂單的輸入(亦可稱之為來源)可分為內(nèi)部和外部兩種方式：
1.? 內(nèi)部： 即自建商城傳輸過來的訂單；
a.? 自建商城的訂單系統(tǒng)涉及的其他系統(tǒng)比較多，基本上上圖所示的系統(tǒng)都涉及到了。
b.? 自建商城訂單在訂單創(chuàng)建時有著更多的判斷邏輯，如是否需要事先拆單的、優(yōu)惠信息是否可用、商品庫存是否滿足要求、會員是否正常等
c.? 內(nèi)部訂單由于存在支付的動作，所以會有多出待付款，待評價這2個狀態(tài)，
d.? 內(nèi)部訂單由于涉及支付和營銷，所以對訂單系統(tǒng)的并發(fā)能力、負載能力以及支付能力有相當高的要求，每一步都不允許出錯，一旦出錯就意味著營業(yè)額的損失和用戶的流失。
e.? 訂單數(shù)據(jù)計算和處理的要求更高，商品多少金額，優(yōu)惠了多少金額，抵扣了多少金額，實付多少金額等都需要準確計算，在財務(wù)報表內(nèi)能夠清晰展示。
2. ? 外部： 即第三方系統(tǒng)傳輸過來的訂單，一般代表性的就是分銷訂單，如供應(yīng)商的訂單系統(tǒng)會接收外部系統(tǒng)的訂單，
a.? 第三方系統(tǒng)傳輸?shù)挠唵?，由于訂單比較獨立，所以涉及的相關(guān)系統(tǒng)會少很多。
b.? 第三方訂單在訂單接收時主要判斷傳輸方是否有資格，商品是否上架狀態(tài)，庫存是否滿足，收貨人信息是否完整等。
c.? 由于該類訂單相對來說不需要很高的實時性(意思是該類訂單對于消費者來說已經(jīng)付款了，現(xiàn)在只是后端處理)，所以對接口負載性能等要求相對就沒有那么高。
d. 訂單數(shù)據(jù)處理方面，一般都是線下核對賬單，線下結(jié)算款項，所以主要在數(shù)據(jù)記錄和處理的準確性方面有很高要求。
以上就是訂單的輸入，接下來我們聊訂單的處理。
個人認為主要有3種處理方式：
1. 流轉(zhuǎn)處理
在訂單系統(tǒng)內(nèi)，系統(tǒng)會對訂單進行各種邏輯規(guī)則判斷，判斷后就會根據(jù)業(yè)務(wù)規(guī)則分發(fā)訂單，可簡單看示例圖：
基本上訂單的流轉(zhuǎn)處理是秒級，甚至是毫秒級就能處理完畢的，不能處理的或者處理失敗的都會把訂單歸類到異常訂單。
下面是訂單各狀態(tài)的流程圖：
2. 發(fā)貨處理
訂單一般流轉(zhuǎn)到倉庫進行發(fā)貨操作，發(fā)貨后倉庫會把物流信息回傳到訂單系統(tǒng)，訂單系統(tǒng)接收消息后會對訂單進行發(fā)貨：
a.? 如果是內(nèi)部訂單則訂單狀態(tài)直接改變(消費者端也會同步看到訂單狀態(tài)變化)；
b.? 如果是外部訂單則會通過接口告訴第三方系統(tǒng)該訂單的物流信息；
3. 特殊情況處理
在特殊情況下，就需要對訂單進行人工處理，例如訂單無法流轉(zhuǎn)到下一級、訂單有備注等。人工處理的結(jié)果可能是跟消費者協(xié)商后讓其退款，也可能是手動的傳輸訂單等。
1. 內(nèi)部訂單：
內(nèi)部訂單的完成并不在發(fā)貨后就完成，一般來說在客戶接收到訂單商品后即算完成。但是對不同類型的商城有所區(qū)別：
a. 自營商城：一般客戶收貨后就完成訂單，例如京東。
b. 非自營商城：客戶需要自己點擊確認收貨或經(jīng)過一段時間后系統(tǒng)自動確認收貨。
2. 外部訂單：
外部訂單系統(tǒng)訂單一般在發(fā)貨后就算完成。
1.? ?在我們設(shè)計訂單系統(tǒng)的時候應(yīng)該先思考下公司業(yè)務(wù)類型和邏輯，理清業(yè)務(wù)上訂單流的起止。理清后從訂單源頭開始設(shè)計訂單系統(tǒng)：
a. 如果是自建商城類的那么訂單模塊會涉及到其他系統(tǒng)，需要與其他系統(tǒng)的產(chǎn)品經(jīng)理(如多人)去討論，如何讓訂單系統(tǒng)與他們負責(zé)的系統(tǒng)進行對接；如果是供應(yīng)鏈類型的訂單系統(tǒng)，則需要考慮如何讓訂單能夠從外部順利傳輸?shù)较到y(tǒng)，是我們提供統(tǒng)一標準的API呢還是我們?nèi)ジ髯詫拥谌较到y(tǒng)等等。
b. 考慮輸入方式后，我們就要依據(jù)公司業(yè)務(wù)運營方式來考慮訂單的處理邏輯，訂單進入系統(tǒng)后如何 讓系統(tǒng)自動處理訂單，依據(jù)什么規(guī)則；同時也要考慮對異常訂單的處理。
c. 在考慮好訂單處理邏輯后，就要考慮如何輸出訂單，是直接輸出給WMS還是會再輸出給其他ERP等等。由于是自動化的輸出，也就要考慮與其他系統(tǒng)的對接方式。
d. 最后，我們就要用把公司業(yè)務(wù)代入到系統(tǒng)內(nèi)，看看是否能行程閉環(huán)，是否還有欠缺或者是否遺漏了細節(jié)等。
2.? ?訂單管理系統(tǒng)涉及的其他系統(tǒng)比較多，所以在系統(tǒng)設(shè)計上應(yīng)該具有獨立性、拓展型和準確性，獨立性代表訂單系統(tǒng)的維護或者異常不會影響到其他系統(tǒng)；拓展型代表訂單系統(tǒng)在以后增加功能的時候方便快捷；準確性是指訂單數(shù)據(jù)涉及到財務(wù)方面，所以應(yīng)該嚴謹和準確。
3.? 后臺系統(tǒng)訂單頁面的設(shè)計：
? ? a. 訂單列表頁面的設(shè)計
根據(jù)公司業(yè)務(wù)需要來設(shè)計列表頁展示的數(shù)據(jù)和布局，以及篩選查詢的關(guān)鍵字段，具體可看示例圖：
? ? ?b. 訂單詳情頁的設(shè)計
訂單詳情頁一般來說是模塊化的展示設(shè)計，訂單基礎(chǔ)信息、商品信息、物流信息、支付信息等都需要有所區(qū)分，這樣設(shè)計有利于詳情快速查看以及在系統(tǒng)研發(fā)的過程中讓開發(fā)小哥哥不容易搞錯哦，具體可看示例圖：
? ? c. 訂單規(guī)則設(shè)計
訂單規(guī)則根據(jù)業(yè)務(wù)的大小有簡單和復(fù)雜，所以具體需要看業(yè)務(wù)規(guī)模。如果公司現(xiàn)階段剛起步，則訂單規(guī)則可直接寫進訂單系統(tǒng)；如起步有一段時間了或者發(fā)展比較快，則可事先就開發(fā)好訂單規(guī)則模塊，以后有新的訂單規(guī)則直接通過運營人員設(shè)置即可，更加的方便和更快速的適應(yīng)業(yè)務(wù)的發(fā)展。
erp系統(tǒng)操作流程圖
erp系統(tǒng)操作流程圖如下：
ERP系統(tǒng)各個模塊包括：銷售管理模塊，采購管理模塊，MRP物料需求分析模塊，生產(chǎn)工序管理，生產(chǎn)制造管理，條碼管理，財務(wù)應(yīng)收管理，財務(wù)應(yīng)付管理，財務(wù)總賬管理，售后管理，客戶關(guān)系管理，文檔管理，運輸管理，手機移動管理等內(nèi)容。
全部管理流程以訂單為中心，展開進行數(shù)據(jù)流轉(zhuǎn)，為管理者提供數(shù)據(jù)依據(jù)，同時掌握企業(yè)管理數(shù)據(jù)內(nèi)容，方便管理者隨時隨地的做出正確決策。此ERP企業(yè)管理系統(tǒng)流程的內(nèi)容，適合中小企業(yè)的管理。
ERP系統(tǒng)是為企業(yè)員工及決策層提供決策手段的管理平臺，經(jīng)過發(fā)展已成為重要的現(xiàn)代企業(yè)管理理論，是一個實施企業(yè)流程再造的重要工具，其核心思想是供應(yīng)鏈管理。
它從供應(yīng)鏈范圍去優(yōu)化企業(yè)的資源，優(yōu)化了現(xiàn)代企業(yè)的運行模式，反映了市場對企業(yè)合理調(diào)配資源的要求。它對于改善企業(yè)業(yè)務(wù)流程、提高企業(yè)核心競爭力具有顯著作用。
ERP是針對物資資源管理（物流）、人力資源管理（人流）、財務(wù)資源管理（財流）、信息資源管理（信息流）集成一體化的企業(yè)管理軟件。
電商訂單模塊的思維導(dǎo)圖分析
從用戶/消費者角度出發(fā)，從購物到完成，主要經(jīng)過以下的流程：選商品 → 加入購物車 → 確認購買（訂單結(jié)算） → 付款 → 等發(fā)貨 → 等物流送貨 → 貨到手簽收。
但是對于電商系統(tǒng)的來說，處理流程就復(fù)雜了。
舉例一點，比如任意的一處理節(jié)點，消費者都可能發(fā)起取消訂單，所以我們需要在某個地方設(shè)立訂單攔截，避免在取消了訂單的情況下發(fā)貨，保護成本。
通過分析后，做了以下業(yè)務(wù)流程圖。但暫未涉及到退貨（訂單的逆向流程）、ODS-訂單分發(fā)，VIS-供應(yīng)鏈，EBS-財務(wù)系統(tǒng)。
需要注意的是：
訂單生成的時候，需要進行對庫存進行一個占用操作，預(yù)先扣減。避免其它消費者同時下單時，最終訂單商品總數(shù)與庫存量不一致。
訂單生成了，需要去付款，才能走下一步的流程。超過期限未支付，需要把訂單占用的庫存復(fù)原回去。
訂單下行涉及到以下系統(tǒng)：
OMS：訂單管理系統(tǒng)。
WMS：倉儲管理系統(tǒng)。
TMS：運輸(物流)管理系統(tǒng)。
暫定地，在下行TMS物流配送前，設(shè)一個訂單-，在這之前取消的訂單，可以走取消訂單流程。一旦在這之后，視為已經(jīng)開始出貨，消費者想發(fā)起取消訂單，只能等收貨之后走退貨流程了。這是為了平臺/商家運費成本來考慮，如果是包郵的情況下更是如此。
當然，也有一些其它的平臺，是可以在物流層進行攔截的。這就需要商家與消費者協(xié)調(diào)運費的問題了。
B2C商城的訂單退款和售后流程——axure原型圖詳解
前一段時間接到任務(wù)訂單管理系統(tǒng)流程圖，要做一個B2C訂單管理系統(tǒng)流程圖的官方商城，自有品牌的，基于前面的電商經(jīng)驗，其他模塊很快上手，唯獨訂單模塊困擾訂單管理系統(tǒng)流程圖了訂單管理系統(tǒng)流程圖我好久，尤其是訂單的退貨退款和售后流程，與訂單的正向流程密切相關(guān)，什么時候該展示什么數(shù)據(jù)，什么功能，退款單的狀態(tài)對訂單狀態(tài)的影響等等，接下來我將用axure原型圖一一講解。在做訂單流程這一塊，參考了很多大神的文章，還有各種開源的商城軟件，都過于理論化，實操性不強，對于新手來說沒有一個實操的axure原型講解，都是在用流程圖告訴大家退款售后有哪些步驟，但是沒有一個具體的案例來分析。相信我，你是不可能一上來就做到像很多文章里寫得很完美訂單管理系統(tǒng)的，況且文章中連原型圖都沒有。其實，即使是天貓和京東，在售后方面也是有取舍的，設(shè)定好規(guī)則才能讓系統(tǒng)跑通，而不是說能夠應(yīng)付所有的異常情況。在設(shè)計之前，要考慮很多看似基礎(chǔ)，卻需要重視的規(guī)格，比如訂單管理系統(tǒng)流程圖：
1.是否支持部分退款，部分退貨？
2.是否支持換貨？
3.是否支持多次申請退款/退貨？
4.如果在售中時申請退款被拒絕了，還可不可以申請售后？
5.部分退款時，自動收貨時間到了怎么辦？如果退款申請拒絕了，訂單狀態(tài)怎么繼續(xù)走？
我這些只是舉例了冰山一角，對于訂單管理的確有很多異常分支情況和用戶錯誤操作。那我在這里既然說要用案例具體去講訂單的逆向流程，我就先要規(guī)定好我們商城的訂單規(guī)則：
1.待發(fā)貨前可以申請一次退款，發(fā)貨后可以申請一次售后（退貨/退款）
2.一筆訂單多種商品只能分開申請退款，不支持對訂單申請退款，意思是有一種商品時就是全退，有多種商品時就是只能部分申請退款。
3.訂單中暫不含優(yōu)惠券，只包括運費，在待發(fā)貨時部分退款，最后一筆申請會退運費；在已發(fā)貨后申請售后就不再退運費，其他原因走人工客服
以上就是我對訂單的設(shè)置的前提條件，有了前提條件，我再去跟技術(shù)評審，就讓他們心里也感覺到靠譜一些，畢竟第一次的時候他們提出了很多漫無邊際，非常離譜但是也會出現(xiàn)的異常情況，一開始得時候我真的很苦惱，后來才發(fā)現(xiàn)是我沒有設(shè)定規(guī)則，沒有規(guī)則，技術(shù)同學(xué)當然怕出現(xiàn)出現(xiàn)異常情況程序不知道怎么跑了。
用戶端訂單頁面
關(guān)于訂單的具體流程我就不多講了，大家都知道的，待付款，待發(fā)貨，待收貨，交易成功，待評價，那我們先來看看我是如何對訂單設(shè)置布局的
圖片所展示的，一筆訂單分為商品操作欄，交易狀態(tài)欄和操作欄，對于商品操作欄我是分開的，所以一筆訂單有多種商品時在申請退款的時候，一定是單個申請的；交易狀態(tài)欄是合并在一起的，這是對訂單整體進度的狀態(tài)顯示，在部分退款時顯示的訂單狀態(tài)；最后操作欄在確認收貨前都是合并在一起的，對整個訂單的簽收，當狀態(tài)為交易成功時，則會顯示商品的評價入口。
那么這里就涉及這三塊的狀態(tài)和操作功能的切換，我們先來看一下 退款單過程狀態(tài) 對商品操作欄的顯示影響
我前面有講，當處于待發(fā)貨狀態(tài)時，商品操作入口為“申請退款”；當已發(fā)貨后，商品操作就為“申請售后”，那退款單的狀態(tài)先去影響了商品操作欄的顯示。具體的細分狀態(tài)我在圖片中已經(jīng)詳細列出來了，包括異常情況該如何處理。
在看完退款單對商品操作的影響后，再來看看退款單對訂單狀態(tài)的影響，注意，退款單與訂單是多對一的關(guān)系，退款單和商品也是多對一的關(guān)系，所以才會有申請一次退款被拒絕了，還可以申請一次售后（退款/退貨）。下圖是 退款單結(jié)果狀態(tài) 對訂單狀態(tài)的影響
可以看出來每一種訂單都有部分和全部兩種影響，這里要注意，全部并不是一次對訂單提交的退款申請，而是查看到訂單中是不是所有商品都有退款單，并且都有結(jié)果。通過這樣表格的分析整理，會很清晰理解訂單狀態(tài)隨退款單的變化。
用戶端退款單界面
前面講了訂單頁面中訂單狀態(tài)的變化，具體的訂單詳情我就不做過多說明了，因為大家參考其他網(wǎng)站也可以很直觀的看到，接下來看退款管理的界面
根據(jù)我之前的設(shè)置的退款規(guī)則，這里的退款單一定是一種商品一個退款單（可能包含多件，因為規(guī)定申請退款是不能選擇退款數(shù)量，要么全退，要么客服聯(lián)系，因為后臺可以修改退款金額）。退款單分為兩種，僅退款和退貨退款，在待發(fā)貨時只能申請僅退款，在發(fā)貨后可以選擇申請退款或者是申請退貨，但是只有一次機會！
這里很多人就會說我不考慮用戶體驗問題，首先我想說京東一上來退款退貨規(guī)則也不完善，當然發(fā)展到今天他仍然還有很多不好的地方，當用戶的退貨申請被拒絕了你作為用戶怎么辦？京東的客服什么時候上線過，那個時候你只能網(wǎng)上發(fā)發(fā)牢騷。商城是從0到1，訂單模塊第一版的計劃就是用戶能下單，能退款，能退貨。至于為什么用戶不能一次申請所有商品的退款，為什么不能設(shè)置一種商品的退貨數(shù)量等，后期會加上批量選擇退款商品，設(shè)置退貨數(shù)量等，不斷優(yōu)化退款和退貨的流程圖。
這篇文章很適合產(chǎn)品新人來了解基礎(chǔ)的退款退貨的原型圖設(shè)計，畢竟這里不包含優(yōu)惠券，沒有拆單，也沒有調(diào)倉等等，所以大家看了文章覺得還可以的點個贊~不喜勿噴
這里就沒有展示具體的詳情頁面，所以可以底下留言找我要原型圖~ 關(guān)于訂單管理系統(tǒng)流程圖和如何自己做一個訂單管理系統(tǒng)的介紹到此就結(jié)束了，不知道你從中找到你需要的信息了嗎 ？如果你還想了解更多這方面的信息，記得收藏關(guān)注本站。 訂單管理系統(tǒng)流程圖的介紹就聊到這里吧，感謝你花時間閱讀本站內(nèi)容，更多關(guān)于如何自己做一個訂單管理系統(tǒng)、訂單管理系統(tǒng)流程圖的信息別忘了在本站進行查找喔。
版權(quán)聲明：本文內(nèi)容由網(wǎng)絡(luò)用戶投稿，版權(quán)歸原作者所有，本站不擁有其著作權(quán)，亦不承擔(dān)相應(yīng)法律責(zé)任。如果您發(fā)現(xiàn)本站中有涉嫌抄襲或描述失實的內(nèi)容，請聯(lián)系我們jiasou666@gmail.com 處理，核實后本網(wǎng)站將在24小時內(nèi)刪除侵權(quán)內(nèi)容。
相關(guān)文章
