ERP MDA UML 有夠笨跟真正笨中間是什麼!!

ERP MDA UML 有夠笨跟真正笨中間是什麼!!

以下的笨問題

有個現代聰明人

用更笨的方法提出更笨的看法

看完如有不良反應請自行就醫


文章來源::
http://myblog-erp.blogspot.com/search/label/%E7%B3%BB%E7%B5%B1%E6%9E%B6%E6%A7%8B


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


文-楊振源

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

=========================================
>我最討厭這些人將 Unix 時代 講成 Dos 時代
>你知道當時就是 Unix / AS400 / Novell
>Dos 是前端展現工具之一
>我們當時也有些用終端機
>我們 20年前的架構 Unix/IBM AIX/HP-UX
>今天大潤發還是覺得他很好用
==========================================

記得20幾年前 DOS 的時代，
老是為了電腦系統上的庫存量正確性大傷腦筋，
因為當一筆出貨交易完成更新以後，
又要再做數量的修改，就必須加舊減新。
若再加上同時又修改了料號，
則計算邏輯就更複雜了，
這樣的程式撰寫方式又被稱為 On-line Update 。

============================================
>領料 有無更改料號都是
>加 更改前 料號數量
>減 更改後 料號數量
>拜託大大你麼聰明
>為何故意裝糊塗
>這樣騙學生不好
============================================

為了解決技術上的難題，大家就創造了 Batch Update 的方式，也就是出貨單 key-in 完畢存檔的時候，並不去 Update 庫存主檔，必需在 User 按了過帳的時候才批次更新庫存。這樣解決了程式的難度問題、 DB Commit / Rollback 的技術問題、以及 DB Performance 的問題。
時至今日，20年過去了，現有國內多數 ERP 系統廠商，卻仍停留在20年前，僅僅把資料庫 Database 當作儲存資料的地方而已。仍沿襲舊的做法繼續採取批次過帳的方式。

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

1. 庫存即時性的問題，必需按 「 過帳 」
( 或稱「 確認 」或稱「 核准 」)
才會更新庫存，庫存不即時。

==============================
>拜託大大你麼聰明
>為何故意裝糊塗
>你是把敲單當成流程跑完補上系統
>哪有還在敲單
>都沒確認都沒審核就過帳
>一有敲單就過帳
>這是 On-Line ??
>拜託大大你麼聰明
>為何故意裝糊塗
>這樣騙學生不好
===============================

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年，都已有了新方法、新工具，是不是應該放棄舊的觀念與做法才算聰明！