JSR JAVA SPECIFICATION REQUEST Language

import org.compiere.util.DB;
import org.compiere.util.EMail;
import org.compiere.model.MClient;
import org.compiere.model.MUser;
import org.compiere.model.MPayment;

String check = null;
/*
if ( !A_OldValue.equals("DR") || !A_Value.equals("IP"))
{
check = "不是草稿變準備中....";
A_Tab.setValue("Description",check);
}
*/

MClient m_client = MClient.get (A_Ctx);
if (m_client==null || m_client.getAD_Client_ID() == 0)
{
check = "client 讀取失敗...";
A_Tab.setValue("Description",check);
}
if (check==null)
{
if (m_client.getSMTPHost() == null || m_client.getSMTPHost().length() == 0)
{
check = "郵件伺服器讀取失敗...";
A_Tab.setValue("Description",check);
}
}

A_Tab.setValue("Description","Before:............"+ check);

String docNo = (String)A_Tab.getValue("DocumentNo");
if (docNo==null0)
{
docNo = "(文件編號 : 讀取失敗)";
A_Tab.setValue("Description",docNo);
}
MUser m_from = new MUser(A_Ctx, new Integer(G_AD_User_ID).intValue(),null);
MUser m_to = new MUser (A_Ctx, new Integer(G_AD_User_ID).intValue(), null); // ??

String from_Name = null;
String to_Name = null;

if (m_from != null && m_from.getName() != null)
from_Name = m_from.getName();

if (m_to !=null && m_to.getName() != null)
to_Name = m_to.getName();

if (from_Name==null)
from_Name = "(寄送人: 讀取失敗)";
if (to_Name==null)
to_Name = "(收件人 : 讀取失敗)";

String message = "敬愛的主管 " + to_Name +
"\n " + from_Name +
"\n 已經將文件備妥, 敬請務必簽核" +
"\n 文件編號 : " + docNo +
"\n Thanks 感謝你對公司的用心 \n 祝你闔家平安 !!";
String subject = "AfterSave : " + from_Name;

A_Tab.setValue("Description",m_from +" "+ m_to +" "+ subject +" "+ message + " " + m_from.getEMail() +" " + m_to.getEMail() );
//m_client.testEMail();

利用電腦結算成本，這也是導入 Smart ERP的主要目的

利用電腦結算成本，這也是導入 Smart ERP的主要目的??

用人工也可節成本!!
算成本算正確很不簡單!!
因為 BOM 會更改
因為 用料會替用
但是結構對就不會困難
很多公司成品完成無法入庫??
是因為領料不齊全無法入庫??
是生產線已產出
品保已經檢驗
產品已入成品區!!!!
為何沒領料單可以生產??
是線邊倉沒有自動化以倒沖帳自動提領用料 ??
是 BOM 與 批次用料不相同 ??
是 沒有設立 批次用料標准 ??
是 沒有設立 批次替代料申請流程 ??


因完全依照 Smart ERP的作業流程，並未做太多個案修改 ， 這不僅減少公司軟體費用的支出，更對於系統導入過程及後來資料維護上，都減少很多不必要的困擾 。

　　整個上線過程中許多令人感動的點滴，其中之一就是當 USER遇到問題時，張總經理常說：「先聽聽顧問怎麼說」，他總是在員工面前極力支持顧問師。再者，無論電腦化出現任何問題，他亦總會說：顧問師請您儘量教我們的員工，我相信他們亦是很Smart。

　　目前達佛羅已能利用電腦結算成本，這也是導入 Smart ERP的主要目的。透過雙方願意充份溝通並共同解決問題，相信導入ERP是可以創造出最佳的e化效益 。

ERP 這種關聯圖示大腦與身體的關連

這種關聯圖示大腦與身體的關連

大家都知道有關連

但是如何關連

用什麼關連


http://www.ares.com.tw/ArgoERP/img/b2_01l.jpg

ERP 核心技術轉移顧問

商業軟體 ERP 導入顧問 用經驗告訴你 如何避開 現有 ERP 的限制
開源軟件 技術轉移顧問 用經驗告訴你 如何修正 現有 ERP 的限制

我是 ADempiere/Compiere 核心技術轉移顧問
Skype: ADempiere/Compiere

例如::

開帳時的試算表:
將"庫存"改成"開帳庫存"
借: 開帳庫存
貸: xx

開帳時的盤點載入其出明細:
再將"盤盈(虧)"改成"開帳庫存"
借: 庫存
貸: 開帳庫存

因此就有正確的庫存明細帳
但是還要在 開帳之後將
盤點的對應會計科目改回"盤盈(虧)"

但這是不道德的
明知有開帳的盤點
為何不加一個開帳的單據類別
用開帳類別去對應"開帳庫存"

明明是系統的問題
顧問還自認他很偉大可以避開系統限制...

ERP 大師不一定會用對 SQL

ERP 大師不一定會用對 SQL

ERP 大師不一定會用對 SQL


if (client.isUseASP())
ASPFilter =
" AND ( AD_Tab_ID IN ( "
// Just ASP subscribed tabs for client "
+ " SELECT t.AD_Tab_ID "
+ " FROM ASP_Tab t, ASP_Window w, ASP_Level l, ASP_ClientLevel cl "
+ " WHERE w.ASP_Level_ID = l.ASP_Level_ID "
+ " AND cl.AD_Client_ID = " + client.getAD_Client_ID()
+ " AND cl.ASP_Level_ID = l.ASP_Level_ID "
+ " AND t.ASP_Window_ID = w.ASP_Window_ID "
+ " AND t.IsActive = 'Y' "
+ " AND w.IsActive = 'Y' "
+ " AND l.IsActive = 'Y' "
+ " AND cl.IsActive = 'Y' "
+ " AND t.ASP_Status = 'S') " // Show
+ " OR AD_Tab_ID IN ( "
// + show ASP exceptions for client
+ " SELECT AD_Tab_ID "
+ " FROM ASP_ClientException ce "
+ " WHERE ce.AD_Client_ID = " + client.getAD_Client_ID()
+ " AND ce.IsActive = 'Y' "
+ " AND ce.AD_Tab_ID IS NOT NULL "
+ " AND ce.AD_Field_ID IS NULL "
+ " AND ce.ASP_Status = 'S') " // Show
+ " ) "
+ " AND AD_Tab_ID NOT IN ( "
// minus hide ASP exceptions for client
+ " SELECT AD_Tab_ID "
+ " FROM ASP_ClientException ce "
+ " WHERE ce.AD_Client_ID = " + client.getAD_Client_ID()
+ " AND ce.IsActive = 'Y' "
+ " AND ce.AD_Tab_ID IS NOT NULL "
+ " AND ce.AD_Field_ID IS NULL "
+ " AND ce.ASP_Status = 'H')"; // Hide



求求你 快快改 這樣用好不好 !!

+ " EXISTS ( " -- 只要顯示要隱藏的頁籤
// + show ASP exceptions for client
+ " SELECT * "
+ " FROM ASP_ClientException ce "
+ " WHERE ce.AD_Client_ID = " + client.getAD_Client_ID()
+ " AND ce.IsActive = 'Y' "
+ " AND ce.AD_Tab_ID = AD_Tab.AD_Tab_ID "
+ " AND ce.AD_Field_ID IS NULL "
+ " AND ce.ASP_Status = 'S') " // Show

+ " NOT EXISTS (" -- 不要顯示要隱藏的頁籤
// minus hide ASP exceptions for client
+ " SELECT * "
+ " FROM ASP_ClientException ce "
+ " WHERE ce.AD_Client_ID = " + client.getAD_Client_ID()
+ " AND ce.IsActive = 'Y' "
+ " AND ce.AD_Tab_ID = AD_Tab.AD_Tab_ID "
+ " AND ce.AD_Field_ID IS NULL "
+ " AND ce.ASP_Status = 'H')"; // Hide

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

ERP 2010 預測：開源ERP難有大作為

近日，一篇名為《2010 預測：開源ERP難有大作為》在網上流傳頗為廣泛。該文認為，開源軟體最後都難免走向商業化運作的道路。畢竟追求利潤是商人的根本目的。進而，該 文作者認為：“現在很多企業都是拿’開源’作為一個炒作的手段。企業推出一個軟體的時候，先通過開源的手段積累一定的客戶數量。而隨著SaaS軟體的日趨 成熟，商業性質的開源ERP軟體會脫去其神聖的外衣，走SaaS軟體的發展道路。”
　　面對於這樣的質疑，近幾年來一直從事開源ERP研發的恩信科技公司CEO劉有濤發表了反駁的觀點。
　　從必死到難有大作為
　　劉有濤表示：“類似的質疑每年都有，只不過以前的聲音更刺耳，以往這個時候我聽到的淨是開源ERP必死，今年溫和多了，變成開源ERP難有大作為了。”
　　談起作為，劉有濤給出了一組數位：“截止到2009年10月1日，恩信科技開源ERP已經有200萬的下載量，企業安裝用戶80萬家，成功使用 的企業用戶至少12萬家，ERP實施成功率超過15%，已大大超過目前國內ERP軟體實施成功率;目前已有3000多家軟體企業在恩信科技開源ERP基礎上在自行做二次開發，而且已簽約加盟的合作夥伴超過50家，這些鬆散的、緊密的合作夥伴在本地為無數的行業客戶創造了巨大的價值，同時也賺取了巨大的利潤;上百家高校、培訓機構用開源ERP軟體做教材自行培訓學生實戰能力，簽約高校加盟合作夥伴的已超過20家，這些高校合作夥伴通過開源ERP幫助學生在 校期間就能實現與企業的資訊化、軟體公司的開發工作近距離接觸，提高了就業能力，同時，這些學生走上工作崗位，更能為企業最低成本的建立資訊化平臺。”
　　基於這些數字，劉有濤問了一個問題：“這些算不算作為呢?”
　　而談起開源ERP對整個ERP產業的促進作用，劉有濤還有一肚子的話要說。
　　開源ERP的價值
　　在不少人眼中，開源還只是局限在Linux上。單以Linux而論，Linux這個當年芬蘭大學生帶頭開發的系統，在今天已經演變成為了紅帽、Ubuntu、 紅旗、中標軟等在內的上千個Linux發行版。因此，單以Linux而論，開源作業系統是大有作為的，但推廣開來，開源作業系統之上的開源應用，也是在作 為的嗎?
　　對此，劉有濤算了一筆帳：“在恩信科技沒有推廣開源ERP 之前，ERP主打產品的價格至少為30萬元以上，現在國內號稱一流的ERP廠商已經將主打產品降到3萬元上下，國外的壟斷巨頭也降到10萬元上下，這難道 不是開源ERP反壟斷的功勞嗎?這又算不算有作為?”
　　劉有濤認為：“這些評論實際上和Sun被Oracle收購等大事件有很大關係。Sun被收購之後，直接導致了Java和MySQL這樣的開源支 撐軟體前途未蔔。”但劉有濤接下來表示：“我個人認為，無論Sun這家公司何去何從，類似於Java和MySQL這樣的開源軟體都會繼續發展下去。這源於 開源軟體深厚的群眾基礎，在這一點上，開源軟體有點象電影’魔鬼終結者’中的天網那樣，一但打開就將永遠無法關閉。”
　　劉有濤進而介紹說：“開源軟體的前途往往與開源軟體貢獻廠商的前途並無關係，這就象脫離了恩信公司，恩信ERP也可能在用戶和開源愛好者的支持 下繼續發展下去。”
　　而談起開源ERP向SaaS轉變這一問題時，劉有濤認為：“開源軟體的生命力決定著它也處在一個變革的狀態之中，象恩信在2009年就推出了雲 計算ERP軟體服務，這些創新業務保證了恩信科技的健康成長。”
　　無論是開源增值服務還是雲計算ERP服務，都繼承了把軟體當服務的關鍵要素。由此看來，開源與SaaS，在提供服務的角度上存在著共通的地方。 同時，開源與SaaS又都不意味著完全免費，因此二者在未來完全可能走向融合。但另一方面，開源與SaaS 之間，又存在著差異性，所以並不能說誰完全代替誰。
即將過去的2009年，對於開源ERP是跌宕起伏的一年。一方面，以恩信科技等為首的企業將開源ERP推向新一輪的高潮。另一方面，由於開源軟體最 大的貢獻者Sun被收購，無疑是向開源軟體市場扔下了一顆重型的炮彈，讓開源軟體的使用者無所適從。在此情況下，2010年開源軟體將何去何從？
Sun收購事件意味著開源軟體難逃商業化命運
誰是開源軟體最大的貢獻者？這個答案是無庸質疑的。Sun公司開發的Java平臺是最大的開源平臺。在這個平臺上開發出了很多免費的和商業的軟體。 但是，2009年4月20日卻傳來一個令人吃驚的消息。就在這一天，甲骨文公司宣佈將以74億美元的價格收購Sun公司。這個事件再一次證明，開源軟體最 後都難免走向商業化運作的道路。畢竟追求利潤是商人的根本目的。
歷史往往有驚人的相似。類似的事情很早就已發生。比如最早Linux等作業系統也都是開源的。用戶不僅可以免費使用，而且還可以在原有功能的基礎來 進行自定義開發。
其中，紅帽的Linux作業系統無疑是最成功的產品。可惜的是，沒有幾年時間，當積累到一定的用戶數量之後，也被商業化包裝了。現在和微 軟的作業系統一樣，需要收費。只是價格沒有微軟那麼高而已。
從這一個個事件中，我們可以得出一個結論。現在很多企業都是拿“開源”作為一個炒作的手段。
企業推出一個軟體的時候，先通過開源的手段積累一定的客戶數量。而且軟體開源、免費，往往意味著企業不用為軟體的漏洞買單。
這也在很大程度上降低軟體的測試成本，有很多用戶可以為企業進行免費地測試。等用戶數 量達到一定規模的時候，其軟體本身也已經比較完善，此時再通過商業化包裝推向市場，無論是軟體發展者，還是包裝者，都可以從中獲取很大的商業價值。
所以， 開源－商業化包裝成為一款成功的商業化軟體無法擺脫的命運。畢竟天下沒有免費的午餐。只要是商人，都會追求利潤。
開源軟體的運作或許會走SaaS的道路
國內開源ERP軟體也有不少。比如全球第一家開源ERP企業Cmpiere在國內也設有分支機搆，再如北京恩信創業也憑藉著開源ERP軟體進入到信 息化管理軟體領域。那麼，這些企業又是靠什麼來盈利的呢？
難道他們真的有如此善心，虧本為企業免費開發軟體？
天下沒有免費的午餐，這是一個真理。這些從事開源軟體設計、開發的企業，在招募人才的時候可不是免費的。
企業仍然要為員工買單、為設備買單。如果沒 有收入來源，企業都將難以維持生計。因此，軟體雖然是開源的，但是企業仍然有利潤來源。這個利潤來源就是服務與二次開發。
眾所周知，ERP系統不像其他辦公軟體那麼簡單。對於大部分企業來說，即使他們擁有一個ERP軟體，但是如果沒有專業的顧問進行實施的話，企業也很難取得成功。也就是說，此時即使企業免費地擁有一款ERP軟體，但對於企業來說，就好像只有汽車沒有駕駛員，只能夠當作擺設，而不能夠帶來任何的價值。
為此，企業要部署好ERP系統，必然要尋找專業的實施顧問來負責企業EPR系統的實施。通過軟體提供商推薦顧問，無疑是不錯的選擇。因為他們瞭解這個公司的 產品與設計流程。軟體公司雖然免費提供軟體，但是卻可以從系統實施服務那裏取得不錯的收益。
還有一點需要提醒的是，開源ERP軟體無論在功能上，還是業務邏輯上，總是與商業軟體之間存在一定的差距。
如果往好的方面想，由於軟體本身是開源的，免費為企業所用，由於資金、技術等方面的限制，無論在設計還是測試上，都沒有商業軟體那樣完善、嚴謹。
所以，出現漏洞或者功能不夠完善也是可以接受的。如果往壞的方面想，難道企業在這方面真的沒有一點惡意嗎？
因為軟體不完善或者存在一定Bug，企業要使用這款軟體的話，則必須進行大量的二次開發。
二次開發可不是免費的，企業必須要為其買單。不可否認的是，在二次開發的功能上，有不少是因為企業自身的個性需求來決定的。由於軟體本身功能不足或者缺陷只 占其中一部分。
從中我們可以看出，從事開源軟體發展、推廣的企業，其利潤來源主要是服務，其中包括ERP系統實施、維護服務和系統二次開發的服務。其實這種商業推 廣的模式與現在比較流行的SaaS（軟體即服務）運作模式非常相似。
因此，筆者大膽預測，或許在不久的將來，帶有一定商業性質的開源ERP軟體會脫去其神 聖的外衣，走SaaS軟體的發展道路。
商業軟體就是商業軟體，何必再套上一件開源的大衣呢？
開源ERP領域難有大的前途
雖然現在市場上的很多開源軟體，大部分是批著開源軟體外衣的商業軟體。
但是，隨著國內開發人員不斷增多，開源意識增強，筆者相信，
一些小型開源軟體 仍然會層次不窮地出現。
比如郵件系統、OA系統、看板系統等，由於其設計、開發難度不大，參與的人數也不用很多，故其在國內仍然會有一定的發展。
但是筆者認為，其發展範圍可能只限於小型的管理軟體或者辦公軟體。因為其不需要十分嚴格的組織與業務邏輯，
大部分情況下，可能幾個人花幾個月時間就可以開發出一套小型管理軟體。
但如果要開發ERP這種大型資訊化管理軟體，筆者認為開源軟體是很難有大作為的。
即使面對中小型企業的ERP軟體，其背後的 業務邏輯仍然是非常複雜的。
無論是後臺資料表，還是業務流程，都是數以萬計的。如果沒有嚴格的組織、嚴密的測試，同時大量開發人員的參與，很難設計開發出一個比較完善的ERP系統。
即使號稱全球第一大的開源ERP產品Ccmpiere其功能仍然有很大的限制，如物料需求計畫等都沒有實現，所以更像是一個進銷存系統和財務管理系統的結合產品。從功能與技術角度來說，遠遠沒有達到一個ERP系統所要求的程度。
所以，開源軟體如果想在ERP領域內發展，會遇到很大的阻礙。最大的阻礙就是開發成本問題。除非走商業化道路，通過服務來獲取利潤，彌補軟體發展成 本，否則很難有進一步的發展。
從以上分析可以看出，2010年，筆者並不看好開源ERP軟體發展。
筆者相信，由於商人的本質，當開源ERP軟體積累到一定用戶，
功能上也比較完善 時，必然走向商業化道路。
只是各家走的道路可能會不同，要麼像紅帽靠出售軟體使用權來收費；
要麼像恩信通過實施服務或者二次開發來收費。
不過無論走哪一條 道路，都無疑從一定程度上偏離開源軟體的本質，
走上商業化發展的道路。