上一篇文章，整體介紹了倉庫管理系統的設計要點及所包含的模塊，而現在這篇文章，將從實際設計出發，詳述設計流程。

之前有說到過，入庫主要包括：采購、調撥、退貨入庫，而出庫包括銷售、調撥出庫。以下以入庫為例，詳細介紹在設計中各流程的狀態以及所需的信息。

一、采購

1、狀態

采購主要分為三個階段，提交前、提交后、收貨。而每個階段，都需要展示各自對應的狀態，以便于相關人員及時監控和追蹤。

提交前：填寫一個采購申請，通常都會包含很多商品，若填寫了又暫時不想提交，那就需要提供一個僅保存的功能，倉管員可以下次再進行編輯然后再提交；

提交申請/審核階段：基本上企業的倉庫都會有很多個，而采購通常都是集采，統一由專門的部門或人員負責。所以每個倉庫的負責人提交采購需求后，可能會存在一個審核的過程，審核通過后，采購員才會向供應商發起采購。需要注意的點如下所示：

• 需要考慮不同角色之間的權限，比如申請人和審核人之間的權限及頁面區別。倉庫和采購又是否在同一個系統中，若不是，系統之間需要進行哪些數據交互和傳遞；
• 采購員提交申請后，是否需要做消息通知，提醒審核人員及時審核，或者是否需要在頁面上直接展示審核人的聯系方式，若是比較著急的采購單，是否可以直接聯系審核人員；
• 申請被拒絕時，是否需要提供一個重新申請的入口；
• 在審核過程中，審核人員需要填寫哪些值，又有哪些值是可以修改的，修改后，又有哪些值需要返回給申請人員看到的；

等待收貨：該狀態下，是否允許退貨，以及是否需要物流信息，視需求而定；

確認收貨：到貨后，需要確認收貨，確認后才代表該采購完成。

• 分批收貨：在填寫采購單的時候，可能填寫了很多商品，數量也會比較多，但在實際送貨中，可能會分開來送貨，這就需要支持分批進行收貨了；
• 未到貨/缺貨：在收貨時，可能會出現某種商品少了一些，這就需要在收貨時進行標記，以便繼續追蹤。此時，需要考慮實際業務操作中可能存在的操作，例如下次補齊還是直接退款，或者是其他的什么情況。無論是進行哪種操作，都需要有操作記錄或說明，以便于財務對賬；
• 附件信息：在收貨時，考慮是否需要上傳一些單據圖片作為收貨憑證。（視相關部門需求而定）

2、詳細信息

是指采購單上需要展示的信息，主要包括商品信息、相關人員、以及所需編號。（視業務而定）

二、調撥入庫

1、狀態

具體會存在哪些狀態，還要看哪個倉庫為發起方。

• 發起方為收貨倉庫：則與上述采購流程相似，依然需要審核、收貨等狀態；
• 發起方為派貨倉庫：則入庫倉庫只需要直接等待收貨即可，無需顯示收貨前的狀態；

2、詳細信息

除了采購提到的信息外，還需要標明派貨倉庫。

三、退貨入庫

1、狀態

一般情況下，該種情況都是購買方發起的退貨申請，而在倉庫管理系統中，我們只需要能夠監控到是否已發貨、等待收貨即可。

2、詳細信息

主要包括銷售訂單信息、相關時間信息、退貨退款信息。

補充：

在實際的倉庫管理系統中，不同的企業會有不同的業務流程，那系統也就會隨之而改變了。

• 采購方式一：設置一個大庫作為備貨倉庫（無論是實體庫還是虛擬庫。當然，考慮到物流成本，一般貨不會先運到實體大庫，而是只設置一個虛擬倉庫用于管理備貨倉庫的庫存，當地方庫需要貨時，直接從供應商處發貨），當各地的小倉庫需要貨品時，直接從備貨倉庫拿貨（這里說的拿貨僅限于庫存上的增減）。這樣的話，從供應商采購何種商品以及采購多少數量就全部由大庫的管理員負責了，地方倉庫負責人只需要提交需求即可；
• 采購方式二：無備貨大庫，當地方倉庫提交需求時，采購人員再像供應商下訂單去采購。

兩種方式的區別就在于是否需要事先向供應商下單采購好貨品。當然，對于地方倉庫負責人而言，兩種方式在操作上并沒有太大的區別。

此外，很多企業不僅僅有用于零售的倉庫，還有專門用于批量售賣的倉庫?？赡苡械臅喜⑵饋硪黄鸸芾?，有的則會專門區分開來。還有就是如何處理臨期、贈品等特殊貨品，也是需要考慮的。

總之，系統功能和流程如何，都需要根據業務流程來決定。

歡迎補充！

相關閱讀

后臺系統：庫存管理系統

本文由 @姜蕁 原創發布于人人都是產品經理。未經許可，禁止轉載。

題圖來自 Unsplash，基于 CC0 協議