批量導入是B端后臺產品中常用的一大功能，看起來簡單但是實際上做起來卻能夠發(fā)現(xiàn)里面的坑有很多。作者結合自己的實戰(zhàn)經驗，與大家分享自己當時從0到1的設計過程，希望對你有所幫助。

批量導入是B端后臺產品中非常常見的功能，乍看簡單，但實際做起來才發(fā)現(xiàn)里面的坑著實不少。筆者根據自己的工作經歷，記錄整理了當時從0到1的設計過程。內容較長，耐心看完，相信你一定會有所收獲！

一、業(yè)務分析

在開始任何B端產品的功能設計前，都需要先分析這個功能對應的業(yè)務場景以及想解決的業(yè)務問題。

批量導入也不例外，一般導入功能都出現(xiàn)在需要單次錄入大批量數據的后臺產品中。根據不同的場景會有不同的應用，需要結合用戶特征來一起分析，它們共同決定了導入功能的軟件功能流程和基本邏輯，例如：

1. 導入的數據是“新增”還是“覆蓋”？（即系統(tǒng)中已有數據的情況下，本次導入是在其后添加數據，還是完全覆蓋系統(tǒng)已有的數據）
2. 存在錯誤數據時，是忽略錯誤數據允許正常數據導入，還是全部打回重新導入？
3. 錯誤數據如何提示和處理，是在線修改，還是導出excel讓客戶修改后重新導入？
4. ······

這些都是在業(yè)務分析階段就需要思考的事情！

二、導入流程

導入功能大致可以分為3個環(huán)節(jié)

1. 導入指引：讓用戶了解怎樣使用導入功能，并給出一份模板文件；
2. 導入文件：上傳文件，并校驗錯誤數據；
3. 結果反饋：讓用戶知道本次導入的結果&影響。

其中2是最麻煩最復雜的一環(huán)，因為除了常規(guī)的文件類型和數據格式校驗外，部分B端產品可能還會有一些業(yè)務上的限制，需要考慮到導入的數據與現(xiàn)有的業(yè)務規(guī)則是否沖突，如果存在沖突，要以何種形式告知用戶哪些數據異常、要如何處理。

三、功能設計

3.1導入指引

3.1.1導入指引

如果導入過程并不復雜，只需要給出下載模板和上傳文件的入口即可；如果流程比較長，需要給出一條明確的步驟指引。

3.1.2模板說明

對于一些重要的系統(tǒng)要求或者是不易察覺的設置，需要在表頭上進行說明，引導用戶正確的填寫數據。

3.2導入文件

3.2.1 導入進度

根據導入數據的規(guī)模和校驗規(guī)則的復雜程度，需要考慮不同的上傳進度提示。（這些最好提前與研發(fā)人員溝通好）

• 如果一般情況下上傳數據少，校驗規(guī)則也比較簡單，耗時短，可以給一個輕量的加載圖標；
• 如果單次導入的數據量大，或者校驗規(guī)則比較復雜，需要較長的時間，可以給一個上傳進度條。在這種情況下，導入任務可以設置成異步處理，即允許用戶關閉當前導入窗口，使用軟件的其他功能模塊。

3.2.2 文件解析和數據逐行校驗

一般導入文件的校驗分為兩個過程：

1）文件格式校驗

在寫入數據前，首先會校驗文件的基本格式是否符合規(guī)范，如果不符合則需提示用戶檢查上傳的文件并重新上傳。一般會有如下規(guī)則：

• 文件類型：支持的文件類型，如excel文件；
• 文件大?。菏欠癯鲆?guī)定的文件大小，如2M；
• 表頭：是否與模板一致；
• 行數：是否超過規(guī)定的上傳上限，比如最多允許導入1000行記錄，但上傳的文件有2000條記錄

2）數據內容校驗

文件校驗通過后，就開始校驗逐行表格中的數據內容，一般包括數據格式和業(yè)務規(guī)則的檢驗：

• 數據格式：字段的數據類型、長度，比如某個數量字段，用戶填了文字；
• 業(yè)務規(guī)則：記錄重復、不同字段之間的運算關系、主從邏輯判斷等；（比較復雜，會在文章末尾中的案例中提供示例參考）

3.3 導入結果反饋

1）導入結果

反饋用戶本次導入的結果狀態(tài)。

• 一般“覆蓋”導入（即導入的數據會覆蓋系統(tǒng)原有數據），對于錯誤數據，都是全部攔截并進行報錯提示；
• “新增”導入（即導入的數據會在系統(tǒng)原有數據基礎上進行新增），一般都只允許正常數據導入，錯誤數據到出修改，這樣可以方便用戶快速定位到錯誤的字段上。

2）錯誤數據修改

導入失敗的數據可以支持單獨導出，并在excel中對異常字段進行特別標注，也需附上“錯誤原因”。（也有文章提過部分情況下可以讓用戶在線修改，但個人認為這種方式并不好，因為對于由同一個錯誤引起的大量異常數據，修改效率很低。如果考慮批量編輯功能，開發(fā)成本又會變得很高）

3）導入歷史（非必須）

部分特殊情況還需要記錄導入歷史，方便后續(xù)查看。

四、分析案例

4.1 產品介紹

一款面向小微企業(yè)&個體工商戶的ERP進銷存管理軟件，幫助他們實現(xiàn)業(yè)務的數字化管理。（說人話就是，倒買倒賣的中間商每天向哪個供應商買了哪些商品？又向哪個客戶賣了哪些商品？倉庫里現(xiàn)在又還有哪些貨、數量多少？······

成千上萬個商品在不同時間、不同客戶、不同供應商中積累的價格、數量、金額等信息是海量的，光靠腦子不可能記得住，更不用說去分析一個周期內的銷售額、利潤！因此軟件就是幫助這些中間商記錄商品流通過程中的信息數據，更好地掌握生意狀況）

4.2 需求背景

我是一名批發(fā)商，上次向某個供應商訂了一批貨，這次供應商把貨送了過來，還附了一張單據（可能是電子單據，也可能是紙質單據，不同供應商給的單據格式也不一樣，如下圖所示），你確認沒問題后，把這批貨搬進倉庫，然后把這個單據錄到系統(tǒng)中，一個個選擇商品肯定太麻煩了，于是你希望有一個導入功能，幫你把這些數據批量處理掉。

4.3 業(yè)務背景

這里提兩個比較重要的概念，方便讀者更好的理解下面的分析過程。

1）商品唯一性標識

商品條碼一般是商品的唯一標識，由商品國際物品編碼協(xié)會賦予，包含該物品的生產國、制造廠家、商品名稱、生產日期、類別、日期等許多信息，在商品流通有廣泛的應用。（簡單來說就是你去便利店買東西結賬，店員用掃碼槍“嘀”的那塊地方，如下圖）

但是對于部分行業(yè)，流通的商品大多是非標品，例如茶葉、部分食品、五金件等，也沒有條碼的概念，只能通過一定的規(guī)則（通常是商品名稱）去標識一個唯一的商品。

而我們軟件定位是泛行業(yè)的軟件，所以商品條碼是商品最高級的唯一標識，卻又不是一個必要信息。除此之外，商品名稱&規(guī)格組合也是一個商品的唯一標識，不可重復。

2）單位

商品單位容易理解，計量商品的標準量，如個、件、箱、米等。值得注意的是，部分商品在實際業(yè)務中可能同時存在多個單位，例如300ml罐裝的可樂，1“瓶”3元，論“箱”（1箱=24瓶）銷售時，1“箱”70元，即同一商品不同單位之間存在換算關系，所以這些商品在商品管理上略微復雜，導入功能設計上也需要考慮到這種情況。

4.4 分析過程

1）用戶分析

在過往的用戶調研中，我們發(fā)現(xiàn)用戶大多是四十左右的中年人，文化水平普遍偏低，對于大篇幅的文字說明都不太敏感，可能導入出錯的概率會比較高。因此除了功能框架層設計上要簡單清晰，還要強化對異常情況的處理提示，讓用戶一眼就知道導入失敗原因在哪以及如何處理。

2）業(yè)務場景分析

進貨場景下，可能同時會進一些新商品和舊商品（即軟件中沒有/已有的商品資料），進新商品會新建商品資料，進舊商品會更新庫存數量，綜合考慮決定“商品名稱”和“數量”為必填字段，其他為非必填字段；另外導入數據規(guī)模上，產品介紹有提到軟件面向的是小微企業(yè)主，他們的進貨規(guī)模根據調研結果，單次大多不超過100個sku，所以導入限制在200~1000行數據就足夠了。

3）可能出錯情況

由于新舊商品同時存在，因此要考慮的難點除了舊商品與已有商品資料的沖突，還有建立新商品資料的業(yè)務規(guī)則沖突。需要分別窮盡所有的出錯情況，并根據出錯場景，來決定哪些需要軟件自動處理這些錯誤，哪些需要導出讓用戶確認修改這些錯誤。

分析到這里，差不多一個完整的導入功能流程就呼之欲出了。

4.6 功能流程圖

4.7 原型設計&說明

這里就不貼原型了，網上資源多的是。主要講講其中的核心部分：數據內容的逐行校驗與提示。

由于公司保密制度規(guī)定非常嚴格，無法把PRD全部貼上來，這里簡單提幾個可能的業(yè)務規(guī)則校驗供大家參考：

• 不同供應商品名：系統(tǒng)商品資料存在這個條碼，但對應的商品名稱不同（比如一罐可口可樂，供應商A叫“可口可樂”，你錄到系統(tǒng)里也命名為“可口可樂”，但你這次又從供應商B那里進了這個商品，他給你的單據上顯示名稱為“可口可樂300ml”）
• 舊商品新單位：商品條碼、名稱與系統(tǒng)一致，但該商品沒有此單位
• 運算關系沖突：多個字段之間存在運算關系，但用戶上傳的數據不符合計算邏輯，比如單價*數量≠金額
• ······

值得注意的是，上面提到的業(yè)務規(guī)則校驗，并不是所有都要當錯誤處理，有些可以讓程序自動處理，提高用戶的產品體驗。