一、背景

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

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

二、需求分析

        系統首先獲取預退貨清單，該清單可以由客服錄入，也可以通過各類電商平臺介面獲取，然後快遞單退回入庫時，通過掃碼槍掃碼入庫，入庫單號與預退貨單進行匹配，如果匹配成功，則進入拆包檢驗流程，倉庫對拆包結果上傳，可以正常完結該訂單，也可以錄入拆包異常原因，如退回空包、寄回貨物不對等。

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

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

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

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

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

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

三、技術框架

 （一）倉庫電腦端，由於需要監聽掃碼槍輸入，肯定需要寫一個後臺服務或托盤程式，看著倉庫裡的幾臺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

四、介面預覽

客戶端登入

客戶端選擇快遞

客戶端掃碼監聽介面

WEB後臺首頁

預退貨單管理介面 

已完結訂單統計查詢

丟包單統計查詢

&n