ARES資通電子報

技術交流

有了新方法還需要舊觀念嗎?

文 - ERP達人

ERP 系統當中有許多的交易檔,都與庫存帳息息相關,比如驗收入庫則庫存增加,銷售出貨則庫存減少。

記得20幾年前 DOS 的時代,老是為了電腦系統上的庫存量正確性大傷腦筋,因為當一筆出貨交易完成更新以後,又要再做數量的修改,就必須加舊減新。若再加上同時又修改了料號,則計算邏輯就更複雜了,這樣的程式撰寫方式又被稱為 On-line Update 。為了解決技術上的難題,大家就創造了 Batch Update 的方式,也就是出貨單 key-in 完畢存檔的時候,並不去 Update 庫存主檔,必需在 User 按了過帳的時候才批次更新庫存。這樣解決了程式的難度問題、 DB Commit / Rollback 的技術問題、以及 DB Performance 的問題。

時至今日,20年過去了,現有國內多數 ERP 系統廠商,卻仍停留在20年前,僅僅把資料庫 Database 當作儲存資料的地方而已。仍沿襲舊的做法繼續採取批次過帳的方式。

這樣的方式有哪些問題呢?

  1. 庫存即時性的問題,必需按 「 過帳 」 ( 或稱「 確認 」或稱「 核准 」) 才會更新庫存,庫存不即時。
  2. 疊床架屋的問題,假如出貨通知單 ( 或稱「備貨單」) 可為 Locking 庫存用,則未過帳的出貨單顯然是重覆的單據。
  3. 操作便利性的問題,假如過完帳後要修改資料,則必須過帳還原,而往往在過帳還原的時候庫存被不當的搶走,或還原的時候造成庫存不足,而必須採取其他補庫存的特殊奇怪作業。


是什麼新方法可以解決程式的難度問題? DB Commit / Rollback 的技術問題?以及DB Performance 的問題?答案很簡單,運用 DB的Trigger 功能。

  1. 程式的難度問題, DB Trigger 可以分開處理 Insert / Update / Delete 的程式碼。
  2. DB Commit / Rollback 的技術問題,程式只要控制出貨單的 Master / Detail 就好了,只有在出貨單被 Commit 成功, Trigger 才會被執行,所以不需要擔心資料寫入一半的問題。
  3. DB Performance 的問題,使用 Trigger 則它的所有資料處理都在 DB Server 上完成,可徹底解決 DB Performance 的問題。

總而言之,過了20年,都已有了新方法、新工具,是不是應該放棄舊的觀念與做法才算聰明!