資料的流向

 公司的基本資料分兩種， 一種是貨物的資料， 另一種是貨物流向的資料。  

我所說的資料主要是流向的資料。  從收貨到出貨。 這種資料最好的資料庫是 QB.  當然， 現在還有 Shpfy。  但是公司的 QB 設計是很粗糙的。  所謂粗糙就是， 裡面既沒有 U/M, 甚至沒有 批號。  這個公司總共三個單位， 一個業務， 一個會計， 一個倉庫。  卻有三個貨物流向的資料庫。  我這個資料庫是很鬆散的定義， 因為倉庫所有的其實只是 明細表格而已。  雖說是電子的， 但畢竟不是資料庫。  我現在這樣說是因為容易一點吧。  

我始終覺得公司的貨物流向資料是從收貨開始。  因為我們會從工廠得到一個 貨物明細。  上面有 U/M 和批號。  雖說這些不會進入 QB 或者 Shpfy, 但是倉庫是會留下來的。  他們收貨的紀錄是一個 十年以上不間斷的紀錄。  

如果公司以後還要把系統升級， 勢必要把這十年由下來的資料作整理。  我最近在做的就是簡單的 把這十年的資料合併在一起。   這裡面有兩個資料我想要用 一個是批號， 另一個是 郵寄追蹤號碼。  

我曾經試著追蹤過 批號的路線。  發現收貨的當下， 批號就不見了， 因為不會放在 QB 裡。  只會在倉庫的明細表裡。  批號第二次出現在任何地方， 是在發貨的時候， 撿貨的時候要記錄下貨物的批號時，才再次出現。  

我修改了 Request list 和 撿貨明細。  我很希望我可以把這兩個明細表和 合併後的收貨資料連在一起。  撿貨明細需要批號， Request list 需要知道收貨明細進貨了沒， 如果進貨了， Request list 需要可以自動記錄。  

我把這寫下來是為了理清自己的想法。