ERP 系統當中有許多的交易檔，都與庫存帳息息相關，比如驗收入庫則庫存增加，銷售出貨則庫存減少。
記得20幾年前 DOS 的時代，老是為了電腦系統上的庫存量正確性大傷腦筋，因為當一筆出貨交易完成更新以後，又要再做數量的修改，就必須加舊減新。若再加上同時又修改了料號，則計算邏輯就更複雜了，這樣的程式撰寫方式又被稱為 On-line Update 。為了解決技術上的難題，大家就創造了 Batch Update 的方式，也就是出貨單 key-in 完畢存檔的時候，並不去 Update 庫存主檔，必需在 User 按了過帳的時候才批次更新庫存。這樣解決了程式的難度問題、 DB Commit / Rollback 的技術問題、以及 DB Performance 的問題。
時至今日，20年過去了，現有國內多數 ERP 系統廠商，卻仍停留在20年前，僅僅把資料庫 Database 當作儲存資料的地方而已。仍沿襲舊的做法繼續採取批次過帳的方式。
有哪些問題呢？
- 庫存即時性的問題，必需按 「 過帳 」 ( 或稱「 確認 」或稱「 核准 」) 才會更新庫存，庫存不即時。
- 疊床架屋的問題，假如出貨通知單 ( 或稱備貨單) 可為 Locking 庫存用，則未過帳的出貨單顯然是重覆的單據。
- 操作便利性的問題，假如過完帳後要修改資料，則必須過帳還原，而往往在過帳還原的時候庫存被不當的搶走，或還原的時候造成庫存不足，而必須採取其他補庫存的特殊奇怪作業。
是什麼新方法可以解決程式的難度問題？ DB Commit / Rollback 的技術問題？以及DB Performance 的問題？答案很簡單，運用 DB的Trigger 功能。
- 程式的難度問題， DB Trigger 可以分開處理 Insert / Update / Delete 的程式碼。
- DB Commit / Rollback 的技術問題，程式只要控制出貨單的 Master / Detail 就好了，只有在出貨單被 Commit 成功， Trigger 才會被執行，所以不需要擔心資料寫入一半的問題。
- DB Performance 的問題，使用 Trigger 則它的所有資料處理都在 DB Server 上完成，可徹底解決 DB Performance 的問題。
總而言之，過了20年，都已有了新方法、新工具，放棄舊的觀念與做法才算聰明！
