酷播亮新聞
最棒的知識補給站

後台系統:庫存管理系統(2)

專為互聯網人打造的365天成長計劃,500門視頻課程隨便看,構建你的產品、運營知識體系。 查看詳情

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

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

一、採購

1、狀態

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

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

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

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

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

確認收貨: 到貨後,需要確認收貨,確認後才代表該採購完成。

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

2、詳細信息

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

二、調撥入庫

1、狀態

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

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

2、詳細信息

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

三、退貨入庫

1、狀態

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

2、詳細信息

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

補充:

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

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

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

此外,很多企業不僅僅有用於零售的倉庫,還有專門用於批量售賣的倉庫。 可能有的會合併起來一起管理,有的則會專門區分開來。 還有就是如何處理臨期、贈品等特殊貨品,也是需要考慮的。

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

歡迎補充!

相關閱讀

後台系統:庫存管理系統

 

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

題圖來自 Unsplash,基於 CC0 協議

如有侵權請來信告知:酷播亮新聞 » 後台系統:庫存管理系統(2)