元旦三天假期，實現一個電商退單管理系統【一】

1、背景

        某電商快速發展，每日發單量比較大，購買電商ERP進行進銷存管理。但每日退貨也有幾百單甚至更多，電商ERP系統對訂單管理駕輕就熟，處理效率很是高，但對於退貨流程管理卻相對比較簡單，只是一個簡單的錄入查詢，沒法對退單進行全生命週期監控。淘寶、拼多多等平臺客戶發起退貨請求，退貨單到底有沒有返回到倉庫，中間可能出現不少意外狀況，如快遞丟單、客戶壓根沒有退、超時等多種狀況，更有部分客戶因購買過程不順心，退貨選擇退回空包、或者隨便放些別的東西等。

        電商老闆向ERP廠商提出該部分需求，但願能追蹤退貨流程，對快遞和客戶進行分析查詢，對因快遞公司責任形成的，須要向快遞公司索賠。但電腦ERP相對成熟穩定，廠商不肯爲某一個電商而更改他們的系統。同時該退貨系統與ERP關聯性不大，遂電商老闆計劃創建一個獨立的系統進行退貨流程管理。

2、需求分析

        系統首先獲取預退貨清單，該清單能夠由客服錄入，也能夠經過各種電商平臺接口獲取，而後快遞單退回入庫時，經過掃碼槍掃碼入庫，入庫單號與預退貨單進行匹配，若是匹配成功，則進入拆包檢驗流程，倉庫對拆包結果上傳，能夠正常完結該訂單，也能夠錄入拆包異常緣由，如退回空包、寄回貨物不對等。

        最後，由客服人員對訂單進行確認關閉或導出異常賠付清單。對於長期未匹配成功的訂單自動進入超時訂單，客服能夠將超時訂單設置爲協商不退貨，或丟包。電商管理人員須要登陸後臺，查詢各種報表，對快遞公司和退貨頻物品，退貨成功率等進行考察，進一步提高產品銷售空間，減小沒必要要的支出，提高利潤。整個流程以下圖：

根據以上需求，將整個系統分紅幾個部分：

（一） 倉庫電腦端，負責對退貨入庫的訂單進行掃碼，提交到服務器，並打印當日流水給快遞員，防止後期索賠糾紛。

（二） 接口端，負責將倉庫掃碼結果接收入庫。該部分業務邏輯儘可能簡單，只須要對錯單、重複單等進行額外的判斷後，直接入退貨表便可。

（三） 後臺服務，負責預退貨單與退貨單進行匹配、丟包單與入庫單匹配、將超過必定時間的預退貨單置爲超時等後臺任務。

（四） 後臺管理系統WEB端，倉庫管理員對入庫單拆包檢驗結果進行錄入，客服負責預退貨單採集錄入、拆包正常訂單完成歸檔、異常訂單查詢導出、賠付信息錄入、超時訂單處理等。電商公司管理人員則能夠登陸查詢各種統計報表，進行決策分析。

3、技術框架

 （一）倉庫電腦端，因爲須要監聽掃碼槍輸入，確定須要寫一個後臺服務或托盤程序，看着倉庫裏的幾臺windows操做系統，C#確定最拿手了，決定使用wpf寫一個監聽程序，與服務端進行通信。數據暫存在本地sqlite數據庫。原本想研究一下SQL Server Compact的，微軟的幫助文檔寫的真心混亂，網上資料也比較少，趕時間就用了SQLite。咱們知道SQLite默認是沒有用戶認證的，之前寫android時曾經研究過一個sqlcipher，能夠實現用戶認證，保護本地數據安全。 

（二）接口端，因爲工期很是緊，加之需求變化可能比較多，服務端我用了PHP，使用thinkphp框架，之前寫的一個簡單的權限管理能夠直接拿來用，爲了趕時間，業務邏輯、數據庫curd所有放到controller裏了，沒有用model。從網上下的bootstrap模板繼續用。

（四）後臺服務，客戶服務器在阿里雲，是一臺centos服務器，tp的定時任務感受像是假的。決定用springboot寫一個jar包，扔到服務器上後臺刷時鐘。

（五）後臺WEB端，與接口服務共用，用的tp3.2。controller+view所有搞定。重複造了很多輪子。

（六）數據庫，使用輕量級mysql，數據庫建模使用powerdesign。

嗯，差很少了，就用了這麼多技術，客戶不須要手機端，不然我還能夠賣弄一下野生程序員MIS全棧能力。

WPF

 

4、界面預覽

客戶端登陸

客戶端選擇快遞

客戶端掃碼監聽界面

WEB後臺首頁

預退貨單管理界面 

已完結訂單統計查詢

丟包單統計查詢