這段時間裏，我開始在Open Source ERP投注一些心力研究，也花點時間在Open Source ERP社群閒逛，有些現象看了有點心得，就來把自己的心得寫一寫。
我必須要先說明，我沒有針對誰或那家公司講，純粹就個人發現的情況來分享心得。
既然Open，就要能接受不同的聲音與不同的想法，但是，請不要做人身攻擊。
也請不要陷入對立狀態的言詞中。
首先，台灣地區在推Open Source ERP的公司或個人，和原來的Open Source ERP社群間，不是完全沒有關係，再不然就是很少很少有聯絡。
似乎，台灣就消失在Open Source ERP社群裏。
但，對岸的Open Source活力比起台灣要更為盛行百倍、千倍、萬倍。
很多Open Source ERP社群裏，可以看到簡體中文化的專案在進行，但繁體中文化卻沒人來召集。
而我更看到台灣地區很多公司在推動Open Source ERP的手法，實際上只是在找管道用Open Source ERP來賺錢。
台灣地區早期在推動Open Source ERP的先驅們的做法是賣硬體送Open Source ERP，再加贈導入上線顧問服務時數。
因為，Open Source ERP不能收費？
這真的是誤會大了。
其實，Open Source ERP在台灣地區推動的兩大問題點在：
ERP產業主要是賣顧問導入服務，不論軟體授權費有多貴，一家公司導入ERP系統所付出的費用當中，顧問服務費永遠會佔40%到60%的費用。
這顧問費包括：系統安裝設定、流程設計、客製設計及教育訓練等等服務事項。
如果拿多數Open Source ERP遵守的GPL授權來看，只有在客製設計的程式部份，如果有第三方請求，就要把Source開放給請求者參考。
至於系統安裝設定、流程設計、客製設計(非程式的部份)及教育訓練，想收費多少就看本事有多少，這些都不是GPL在規範的。
GPL只規範了Source的來源、利用及再分享而已。
所以，一些Open Source法律案件，其實重點都在沒有把自己研究開發的新程式碼開放分享，因而觸犯GPL授權。
因此，必須要問：某個台灣軟體公司在Open Source ERP裏寫了支統一發票及稅務管理系統，要不要分享這個系統的Source？
要！那有這麼"笨"的公司把自己公司的生存命脈交給別人去賺錢的呢？
所以，Open Source ERP到了台灣就變成Close Source ERP了。
而且，是關起門來做些犯法的事(侵犯GPL)，拿Open Source ERP去改又不公開，向客戶說些什麼不收費不要講。
搞得幫客戶導入ERP系統成了上不了台面的事。
那...怎麼做才是正事？
要繁體中文化是嗎？去申請專案，然後在專案中改，改好成為語言套件(模組)給大家用，有興趣的人也可以參與專案一起改。
要統一發票功能是嗎？去申請專案，在專案中提交規格與開發程式，寫好給大家用，有興趣的程式設計師也可以一起來開發。
那....這樣能夠靠Open Source ERP賺什麼錢？
系統安裝設定、流程設計、客製設計及教育訓練，這些合法能賺的錢為什麼不賺？
顧問計費一天多少現大洋的錢為什麼不能賺？
付出一些心力去搞好Open Source ERP的本地化功能，然後能運用來幫End User，把原來的軟體授權費用在更需要的Domain Know-how上。
或許有人會說台灣的中小企業老闆才不會那麼好心付顧問費。
我只能說，對這種短視近利的企業，花再多錢導入ERP系統也是枉然。
也因此，在近期內我會和iDempiere社群討論開繁體中文化專案及本地化功能專案，期待有四方大德能共襄盛舉。
simon581923提到：
一些Open Source法律案件，其實重點都在沒有把自己研究開發的新程式碼開放分享，因而觸犯GPL授權。因此，必須要問：某個台灣軟體公司在Open Source ERP裏寫了支統一發票及稅務管理系統，要不要分享這個系統的Source？
要！那有這麼"笨"的公司把自己公...(恕刪)
這真的是對 Open Source(GPL)天大的誤會
看來得跟賽大當面談談了...呵
jacky1122提到：
這真的是對 Open Source(GPL)天大的誤會
看來得跟賽大當面談談了...呵
歡迎Jacky老大以PO文方式分享對Open Source ERP的看法，至於當面談談，不如公開把想法提出來，這樣才能讓更多的人來參與討論。
但是，我必須要說，我的重點完全不是GPL，而是在台灣推動Open Source ERP的情況真的感覺有些上不了台面的事，問有沒有那家公司使用Open Source ERP，抱歉，你找不到那家公司會很高興的宣稱導入Open Source ERP而且很成功的。
多半都是，躲躲藏藏...連個成功案例都不敢講。
有成功案例，就講吧！
iT邦幫忙MVPsimon581923提到：
對 Open Source ERP 的看法，...，我的重點完全不是GPL
呵...ERP不是個人擅長的
只是對 GPL 有些涉略
也作過幾個 Open Source 的中文化
既然 GPL 完全不是賽大的重點
那大概用不上小弟了
jacky1122提到：
GPL 完全不是賽大的重點
那大概用不上小弟了
Jacky老大謙虛了，其實你可把GPL的觀念寫一篇PO文來給大家明白明白...
我覺得問題在學界的推廣...
我聽說 某新店 ERP 大公司就推協助學生考證照~
推廣的效果, 和業界可以介接...
當然 User 就變多, 討論也多...
deanya提到：
問題在學界的推廣...
這的確是主因
但各大專院校對 Open Source 的應用或教學一直沒太大興趣
(其實有些教師對 Open Source 也不熟，自然無從教起)
所幸託經濟景氣一直沒起色
已有許多企業與大專院校相對重視起 Open Source
jacky1122提到：
但各大專院校對 Open Source 的應用或教學一直沒太大興趣
主要針對ERP這塊,當初畢業專題一開始老師有找我們做過這個,那時用Oracle的ERP
問題是光導入費用就不少了,更不用說裡面一堆財務相關的專有名詞
後來找免費版做幾個月就放棄,老師自己也放棄了
主要: 1.費用太昂貴
2.中文化有太多專有名詞要去一個一個找,你說找會計的學生做,問題是不同科系,除非有 一定利益,不然對方有為何要幫呢?
3.中文化後對於學校是免費提供給企業,對於老師而言只有一個名聲,企業也不會找老師去當顧問,畢竟牽涉到付費軟體
不過不知前幾大的學校或是會計專門的學校有沒有在做也不清楚
只能說現在的老師和學生都太混了，我們那個年代只要是資管系畢業的學生，出來業界混個幾年，都可以當ERP的顧問。
cdfu提到：
我們那個年代...出來業界混個幾年，都可以當ERP的顧問。
...
請問大大是哪個年代?!
跟泰大差不多的年代....
比潛大還晚一些...
ted99tw提到：
比潛大還晚一些...
我是在甲骨文的年代......(躺著也會中槍??)
我用 ASP.NET MVC 寫會計系統
參考資料之混亂 (目前會計相關文件收集到 169MB)
就快腦死了
會計系統完整OpenSource的時間可能會再延後
因為我沒寫完
http://www.player.idv.tw/prog/index.php/%E6%9C%83%E8%A8%88%E7%B3%BB%E7%B5%B1
博碩那本"財務會計這樣做！用Excel完成的專業會計系統"
買之前也高估了
整本簡直是在講Excel
而非講會計系統的細節
Open Source ERP是泰大的構想
他要開始的話, 我等有人先規劃好, 先寫出sample後
再看情況參與
因為我手邊也沒有多的主機
所以可能用VM的方式之後在家弄吧?
player提到：
財務會計這樣做！用Excel完成的專業會計系統"
會計系統目前沒看過書本有講的,除了ERP有用到會計
剩下都公司自己內部開發的吧
會計本身就很龐大了,之前朋友去職訓局學會計課程,光看記帳,財會,結稅那些就很混亂了
他那還只是考丙級證照......
更深入的還有得學,後來跟他一起去請教以前在四大會計事務所做過認識的人
才發覺會計是門很深的學問,光證照就不少張了,更不用說一堆要學的書籍
真的要做出這種完整的會計系統,那很多會計事務所早就找人做了
個人要做頂多也只能做出部份功能
Open Source的授權有好幾種
GPL, LGPL, MIT 這些,都沒有禁止商業應用
但是GPL有Open Source的傳染性
如果使用GPL的東西, 你如果修改了它, 則有再次OpenSource的義務
但是如果只是引用, 而無任何修改行為, 則只要註明出處即可
有些C++的OpenSource甚至是引用它的Code免費
但是如果要直接用它預先編譯好的dll檔到你的專案裡轉散佈出去的話
則需要付費
所以付費與否要看該套件的授權相關文件而定
player提到：
Open Source ERP是泰大的構想
先別管 open source 了
你有聽過賽大嗎
player提到：
Open Source ERP是泰大的構想
原來泰大的D槽也都是Open Source啊....(仰天長嘆)
先別管誰是誰了
open source是什麼啊，美味蟹堡送的公仔嗎...
大家可能搞錯方向了，會計對資訊人員來說，難在那時該用哪個科目，但那是會計的事，我們資訊人員是要讓會計人員方便的把會計規則設定進系統裡，而不是去了解會計規則，這是兩回事。
cdfu提到：
是要讓會計人員方便的把會計規則設定進系統裡，而不是去了解會計規則，這是兩回事。
讚
但是會計要會如此 [分類對應技能] 就是不簡單了
所以我才會照書的方式去改寫
保留
會計科目 <-> 會計類別
的對應關係
會計科目, 編號自訂
但會計類別的編號按 IFRS 的方式改為 1, 2, 4, 6 碼
報表依會計類別去算, 會計科目只用在分類帳與日記帳時顯示
可是明明資產分類有一套公式化的標準
可是我收集的資料卻還沒有到那邊
只先收集到各種折舊的計算公式
cdfu提到：
我們資訊人員是要讓會計人員方便的設進系統裡
player提到：
所以我才會照書的方式去改寫
保留
會計科目 <-> 會計類別
的對應關係會計科目, 編號自訂
但會計類別的編號按 IFRS 的方式改為 1, 2, 4, 6 碼
報表依會計類別去算, 會計科目只用在分類帳與日記帳時顯示可是明明資產分類有一套公式化的標準
可是我收集的資料卻...(恕刪)
感覺樓歪了一下又被扶正
資料收集了,沒有專門會計人員幫忙整合,還是要花很多時間自行整理了
不過會計的公式好像非常多,聽我那朋友說光背公式就花很久,每天都要花不少時間去計算
考試時還要靠運氣,如果運到要用公式的題目還是很慘
之前收集的計算公式
都是基於4碼的會計科目編號
自定編號是超過4碼的號碼
那種4碼系統要統計, 只要取最前面的4碼去分類就好了
(無奈收集的資料不能用)
IFRS的資料也是按年份去分的
證期會還沒打算要採用的新文件, 我是還沒抓, 不然文件會更多
反正照書寫的
傳票只有1種, 借貸由傳票明細裡去寫; 一堆自轉傳票(轉帳)的功能通通都還沒寫
沖帳採手動填寫沖帳碼到傳票明細, 目前不考慮做自動沖帳
過帳採月結方式, 選年月後, 將整個月份一起過帳 (其它過帳方式不考慮, 免得寫到太複雜)
player提到：
的話, 我等有人先規劃好, 先寫出sample後
再看情況參與
程式設計師要去學稅務....那對他是有點難度了,念完都可以去考張會計師的牌了..
而且每家公司的狀況不同，是需要客製的。
當然開發這些東西如果是公司..那他也是需要成本的....不放出來可以理解的
但是你還是需要遵守規範..
那個會計系統
最初是一本Access的書, 而且有先跟原作者打過招呼, 並取得他同意我改寫成 ASP.NET MVC的版本
至於公司要用的
在那之前有先寫過一個簡易版(只有記帳功能)
但是沒人要用
後來大約花了1年多的時間去收集相關資料
而且在寫新版之前
已經先跟公司內說過
由於我非會計人員, 這東西就算日後寫得出來, 也很難一個人維護下去
所以會把會計系統的部份切開弄成OpenSource
日後讓有興趣的人參與維護 (不限制任何目的的改作與運用)
反正也不是全部公開, 與會計系統無關或是過於客制化的部份, 應該是不會公開了
而且要用的人, 也必需自己寫登入與帳號管理相關的Code才能用
因為開發環境在
Visual Studio 2012 Pro + SQL Server 2012 + Crystal Reports
所以沒有這些軟體的人, 也沒辦法參與
所以目前就真的只有我一個人在寫
我從多年前, 就陸續整理寫過的東西慢慢 Open Source
但是都是片段的程式碼 (為了避免踩到侵權地雷, 不會公開整個專案的Code)
所以要程式上有一定程度的人
才能用
那本 Access的書, 他的光碟的 Access的檔案是加密過的
原本是我是到圖書館借的, 大約1年多後, 向原作者聯絡, 買到那本絕版書
我還找過MDE解密工具破解過
不然之前連資料表的欄位定義都抓不出來
後來再把該Access裡的VBA巨集通通解出來原始程式
但是因為我要改寫, 所以那些VBA巨集就不幫他公開了
player提到：
我還找過MDE解密工具破解過
不然之前連資料表的欄位定義都抓不出來
後來再把該Access裡的VBA巨集通通解出來原始程式
但是因為我要改寫, 所以那些VBA巨集就不幫他公開了
以你這樣的開發環境..我都不太想碰了..更何況是一般的使用者.....
以我這麼多年的經驗來說..我還是會有一點點的私心...
但我能放的就放...資訊這條路真的是不歸路啊...
你有看過那幾個行業過幾年後他之前學的技能幾乎沒用的...
就屬資訊業是其中一個...
所以我學的能放就放...
如果你很快都會.....算你厲害
如果你學了還是不會..那我幫不了你
如果不涉及改寫的話
引用前會看原始版本的授權方式
沒有先註明的話
通常會先連絡原作者取得授權
如果涉及改寫的話
會盡可能把改寫過後的版本
也公開Code
以符合OpenSource的精神的延續性
那本Access的會計系統的書, 書附光碟是加密後的 mde檔, 雖然書上有一些關於 mde 檔的VBA的Code與資料表的設定
可是Access卻沒辦法打開設計模式 (資料表與VBA的部分全部都因為加密而被隱藏)
先取得原作者同意改寫後
才找破解MDE的工具去反轉, 不然要看著書的內容, 全部手動重新Keyin一份, 會做到吐血吧?
反正有很多的逆向工程的工具
也不是什麼秘密了
用Google就可以找到一堆了
當年還在DOS 3.x時期, 就破解過 BASIC 的加密儲存過了
要不是磁片都發霉光了, 一堆收藏品都飛了
不然就可以拿那些BASIC的程式改寫了 (以前收集過一堆用BASIC寫的小遊戲)
Flash或Java如果沒用上混淆器的話
也沒有秘密可言了
以前的加密在現在來看根本是加心酸的
BASIC .. 看出來你也是老人了
過幾年這些都會變沒用的...
除非 像COBOL這個怪咖 .....現在銀行還有人在用..再不改...會出事的...
好厲害，我花了三天找不到的專案，連老外都說沒有的專案，海綿寶居然找到了。
可是...似乎停擺了的專案。
那，就看海綿寶寶和泰大的神功再世，恩同再造....
iT邦幫忙MVPantijava提到：
中秋節
是指明年中秋節嗎...
我可以負責....監工....
那個....泰大，請先在D槽開個新專案....
還有....海綿寶寶，請在水母田裡種下中文化的水母吧....
翻議的部份
我幫不上忙
如果有需要到改Code的部份
再找我
可以幫忙把ascii code改成uni code嗎...
把ascii code改成uni code ?
那個不是用 Notepad++ 去把Code的檔案打開
選編碼後
再存檔
就好了?
看到海棉寶寶挖出來的網址 https://translations.launchpad.net/aderp/trunk/+lang/zh_TW 是 ADempiere ERP 系統訊息翻譯專案，才回想到當初自己有翻譯一部分
我想 iDempiere 與 Compiere 以及 ADempiere 都算是同宗，應該翻譯檔內容可以互通
想要中文化只要弄清楚做法，接著就只是要花很多時間處理了
以前研究 Compiere 時有寫一些資料 如何自己動手將 Compiere ERP & CRM 作中文化
只是不知道當時的處理架構在目前的 iDempiere 系統是否還能適用
再來就是如何做出適合台灣的會計課目要用來做系統開帳的
在 ADempiere 有人寫了小工具程式 adempiereAcctEdit 來編輯處理
而 iDempiere 剛找到網址 iDempiereAcctEdit 希望可以使用
希望以上資訊對各位有幫助
或許有人會說台灣的中小企業老闆才不會那麼好心付顧問費。
我只能說，對這種短視近利的企業，
花再多錢導入ERP系統也是枉然。
對這種短視近利的[導入顧問]
導入就是 : 用不是為你而寫的軟體需要 [引用,借用,迂迴,造假,補入] 這就是導入
導入本來就不應該收費
因為[導入顧問] 要用 : [誘拐][引導] 去用不是為你而寫的軟體
導入本來就不應該收費
來，請跟我唸十遍...
阿伯大不收費。
阿伯大不收費。
阿伯大不收費。
阿伯大不收費。
阿伯大不收費。
阿伯大不收費。
阿伯大不收費。
阿伯大不收費。
阿伯大不收費。
阿伯大不收費。
好...廣告完畢....謝謝各位收看。
感謝
導入都是用了不是為你量身訂製的程式
因此
免費導入讓你知認識 iDempiere
增加畫面 不需改 SourceCode 是[導入] :: 不收費
增加報表 不需改 SourceCode 是[導入] :: 不收費
需要客製化 SourceCode 的技術轉移 [才收費]
所以是交補習費學客製化開發技術，然後附送 ERP 基礎平台導入免費，然後補習費是計時制且有最低時數門檻，可以增加不能減少?
最好很長 先生:
[ 然後附送 ERP 基礎平台導入免費 ] 學英語不一定要參加補習班
人的立場與人的背景會決定你是否會很辛苦
如果是一個 [潛在客戶] 沒付費沒簽約前,
他會得到 ERP 導入免費, 免費 設定, 加減畫面,
....先上線完成再談要不要[技術轉移]
如果是一個 [潛在競爭者]...就會完全不同
人的立場與人的背景會決定你是否會很辛苦
albertachen提到：
免費導入讓你知認識 iDempiere
增加畫面 不需改 SourceCode 是[導入] :: 不收費
增加報表 不需改 SourceCode 是[導入] :: 不收費
需要客製化 SourceCode 的技術轉移 [才收費]
好樣的阿伯大...
不客製完全不收費...
不改原始程式碼不收費...
很抱歉...我還有一家子要養，不陪您了，一路好走...謝謝！
哪是我的收費方式沒有技術轉移就不收費
[一個完全依賴你的客戶是一種責任也是一種榮耀]
賽大你可以自己決定你要不要收費
希望阿伯大可以多分享說明這三個 ERP 具體上能滿足或達不到哪些產業的業務需求
相信會有更多的人嘗試與認識
bestlong提到：
具體上能滿足或達不到哪些產業的業務需求
畫面是給客戶敲資料的介面
根本不牽涉商業邏輯
商業邏輯寫 Rule Script 給 Rule Engine ( Groovy )
講得出來的都可以寫得出來
沒有不能用的行業
企業流程就是一連串的 ［拋轉］［檢核］ 的條件設定
智商太低就不要太勉強,智商太高也不需要做
教10次不會的就不要［智商太低就不要太勉強］
教3次會的剛剛好
教1次就會的不會繼續做（智商太高也不需要做］
albertachen提到：
畫面是給客戶敲資料的介面
根本不牽涉商業邏輯
商業邏輯寫 Rule Script 給 Rule Engine ( Groovy )
講得出來的都可以寫得出來
沒有不能用的行業
企業流程就是一連串的 ［拋轉］［檢核］ 的條件設定
您說的這些已經是到了客製(或者說二次開發)的範圍
這些 ERP平台的基礎功能，能談談不在客製範圍並且已成熟的部份嗎?
對不起
你將 ERP 流程設定 規則引擎設定 驗證引擎設定 流程引擎設定 都當客制化
不改 Source Code 都不能稱為客製化
沒有[侵入式]醫療
就不是客製化
對客製化定義可能需要去
當過 PeopleSoft / SAP / Oracle ERP 導入顧問
才會有一點認知
albertachen提到：
對不起
你將 ERP 流程設定 規則引擎設定 驗證引擎設定 流程引擎設定 都當客制化
不改 Source Code 都不能稱為客製化
沒有[侵入式]醫療
就不是客製化
對不起
並不是我認為那些都是客製化
任何的客製化的範圍都是系統供應商來界定的
沒提供技術文件，客戶不會知道有哪些參數可以解決問題
就算真的簽約付錢後看到了，客戶也不一定能理解不是嗎?
看來，我若想多了解還是只能自己慢慢去看官版文件了
本來，談Open Source ERP只是個想把ERP的觀念傳遞分享給資淺的IT人，讓IT人有機會得到一點點實務經驗上的分享。
可惜自己的道行不夠深厚，被帶到談收不收費的事情上去了。
我認為Open Source ERP談的不是一家兩家公司的事，而是談Over All的事。
眼界有多寬，世界就有多廣。
我想我該少說些話，多做些事。
所以，對於阿伯大，我就不再回應了。
過兩天，會把ERP中BOM的觀念寫篇分享文，到時再請各位指教。
無論如何，我希望重點是在...Open Source ERP確實有一套基礎可運作的系統在，可惜的是國內完全沒有發揮Open Source的精神。
也因此，我想這是可以開闢的一塊天地，透過Open Source ERP分享ERP的實務經驗，同時把國內的Open Source ERP環境重新建立成真正符合Open Source精神的環境。
目標明確了就進擊吧
加油
有需要支援的地方可以提出
或許可以抽空參與幫忙
iThome鐵人賽
看影片追技術