資料庫要保存每次入庫的商品數量以及該批次商品的成本
出庫的時候要按照先進先出的原則 ,記錄每次出庫的數量和對應的成本
如果出庫的時候是多個批次的庫存一起出庫, 還計算綜合成本
我目前是設計成 一個父子表, 主表記錄剩余數量,
從表記錄每次出入庫的數量和改批次的成本
出庫的時候 查詢剩余數量不為0的入庫記錄, 然后回圈取出合適數量的記錄,計算成本, 然后在從表里插入一條出庫的記錄,并扣除已有的入庫記錄中的剩余數量.
總感覺這樣計算不合理, 有大佬們來指點下嗎 ?
uj5u.com熱心網友回復：
入庫是一個表，庫存是一個表，出庫也是一個表。具體參考WMS系統。uj5u.com熱心網友回復：
入庫的時候寫入入庫表，屬性就是那些供應商、商品名、數量、什么的。，同時寫入庫存表中，因為是有相同產品不同批次的，出庫也一樣，寫入庫存表，再寫出庫表； 庫存表要有個狀態是表示出庫還是入庫，盤點能找出來。
uj5u.com熱心網友回復：
分開存，出庫，入庫，庫存。這個沒什么問題。其實具體要看你們業務。
比如你的先進先出，你的多批次出入庫等等。都是業務上的規則。
根據業務產生模型和資料庫表。
uj5u.com熱心網友回復：
這里只能說一下，為什么出庫和入庫要分開。因為出庫，可能需要關聯入庫的批次id。
你要體現出你從哪個入庫批次出的。
并且有些erp還具有 無批次出庫。也就是隨便掃碼出庫，不關心先進先出的出庫順序。
所以光談論怎么建表是很空洞的。
要結合具體業務
uj5u.com熱心網友回復：
我們之前還有鎖定庫存和預出庫的概念。鎖定庫存也就是，今天下了出庫指令，但是實際還沒有出庫。
這個時候，你需要保證下次出庫時，這個數量是夠出庫的。
而不是 2個出庫指令同時出現，結果因為第一個出了，導致剩余數量不夠第二次出庫。
預出庫是其實歡訓沒入庫。
但是預計可能過兩天就貨到了入庫。
那么這個時候，他可以先下一個出庫指令，預計在第三天或者之后出庫。
所以這都是看業務邏輯的。
uj5u.com熱心網友回復：
合適不合適別問我們，請咨詢專業會計他們如何計算成本的，至于扣除數量，俺們是不扣的，俺們一般只是在批次記錄子表增減修訂。
只有實際盤存才真正轉結數量
uj5u.com熱心網友回復：
出入庫肯定要分開的，入庫數量肯定不能減的，這是原始記錄，你減掉了事后怎么對賬？減只能減庫存，入庫同步增加庫存，出庫同步減少庫存，且要記好出庫資訊。這樣即使庫存不準，也可以通過出入庫的記錄來校準。其實可以參考具體出入庫的紙質單據，分析一下哪些是原始資料，哪些是計算資料，原始資料都要單獨建表保存。uj5u.com熱心網友回復：
這其實跟“資料庫”沒啥關系。這是 UML 或者是 Class 表達問題，更是一個領域模型問題。要去企業看看最基本的賬本，要學管理學，要在實際的帳簿上幾張。千萬別拿著一點編程知識想當然。至少帳簿分為兩種。一種是總分類賬，它記錄剩余數量和剩余金額；另一種是明細賬，它記錄每一筆“獨立事件”的發生數量、發生金額、過賬剩余數量、過賬剩余金額。實際上這兩種之間也沒有什么“主-從”關系，而是通過核算的 Key 關聯的。比如說“庫存-商品342423-......其它核算科目”跟“進貨-商品342423-......其它核算科目”與“出貨-商品342423-......其它核算科目”的 Key 是存在關聯的，但是你不能說后兩者跟前者是“主-從”關系。實際上跟商品相關的客戶大類還有至少30個以上，而你只知道3個，對企業商品管理流程的知識所知到的還只有不到十分之一。
資料庫不過是存資料的地方。在資料庫表上面有好幾個層次，決定了不管你用不用關系資料庫（或者是 NoSql 資料庫），用記憶體，文本檔案，或者別的什么，你都要懂得同樣的領域模型。寫出領域模型的 UML 圖，Class 代碼。而更關鍵地是去實際拿企業的帳簿實習一段時間
uj5u.com熱心網友回復：
在實際企業中，由于各類生產經營活動中都需要快速獲得一些時間相關的資訊，所以通常要“日清月結”。例如庫存要隨時獲得每一天的剩余數量和剩余金額，因為生產經營時隨時要頻繁查詢指定日期的進貨成本、銷售成本、庫存成本、優惠折扣成本、給銷售員傭金成本、應付而未付的費用等等等等。你把一堆東西一股腦地扔在“庫存表”里，這就成了集中的一個大垃圾。你需要忘記“資料庫”這種低級的計算機領域的東西，眼中有業務領域的事務作為隱喻，先把業務領域知識搞明白高透，按照業務領域的一千多年的習慣體系去理解流程、建你的表。盡量避免按照想當然的“資料庫”去本末倒置地去處理業務。uj5u.com熱心網友回復：
跟商品相關的客戶大類還有至少30個以上 --> 跟商品相關的企業管理核算科目大類還有至少30個以上轉載請註明出處，本文鏈接：https://www.uj5u.com/net/22846.html
標籤：C#