導入ERP系統不可避免或多或少都會需要進行客製工作, 這一篇將說明在Microsoft Dynamics NAV 2013進行客製的一些基本概念, 包括Dynamics NAV 2013的開發環境和其基本架構.
導入ERP系統, 無可避免的一定會面臨客製的需要, 不論是因為企業的商業流程需要, 或是因為表單欄位的增加或處理邏輯的不同, 都會需要新增表單、報表的功能或是修改表單、報表的欄位、處理邏輯.
有些顧問會堅持不要修改系統, 應該修改商業流程與邏輯來配合系統, 但, 這是ERP導入的理想境界, 大多數ERP系統導入專案或多或少都會需要客製.
尤其是由外國引進的ERP系統, 一定會有兩方面的客製需要:
1. 中文化, 雖然有些ERP系統自帶有中文版本, 事實上那是屬於客製範圍, 外國的ERP系統才不會那麼好心的提供中文版本, 除非市場大到提供中文版本有利可圖, 否則, 這是第一個要客製的功能. 也因此, 目前見到大多數國外的ERP系統, 會開發簡體中文版本或提供簡體中文的語言套件, 正體中文就沒有麼多, 大多數都是另外付費.
2. 本地化, 什麼是本地化? 例如台灣獨有的加值稅、統一發票處理, 以及勞健保等等人事薪資方面的處理, 這些都只有在台灣才會需要的功能, 就是本地化. 國外的ERP系統, 多半會找台灣的顧問公司來幫忙開發這些功能, 額外成為所謂本地化套件, 另外計算授權費.
為了完成客製化, ERP系統必需提供必要的開發工具, 例如SAP R3的ABAP/4, Oracle EBS以其Forms Developer和PL/SQL為開發工具, 有了開發工具才能在ERP系統內進行系統功能新增與修改的工作.
雖然, Microsoft Dynamics NAV 2013是Microsoft的ERP產品, 但其開發工具並不是用Microsoft VIsual Studio, 而是Dynamics NAV自有的C/SIDE開發環境及C/AL程式語言.
什麼是C/SIDE開發環境? 就是Microsoft Dynamics NAV 2013安裝完成後的那個"Microsoft Dynamics NAV 2013 Development Environment", 參見下圖:
C/SIDE是Client/Server Integrated Development Environment的縮寫, 是一個專屬於Dynamics NAV的整合式開發環境.
在畫面的左邊有好幾個物件(Object): Table、Page、Report、Codeunit、Query、XMLport、MenuSuite, 這些物件構成了Dynamics NAV的整個架構.
除了開發環境, Dynamics NAV也提供了一套程式語言C/AL, 即為Client/server Application Language的縮寫, 這是一套Object-Based的程式語言, 不是Obeject-Oriented程式語言, 為何稱之為Object-Based? Object-Based和Object-Oriented有何差異?
我們先談Object-Oriented, 例如在C#中, 我們可以運用已經存在的Object創建新的Object, 我們建立一個類別..
public classt books
{
public string ISBNCode;
public string BookName;
public string Publisher;
public int Price;
}
然後, 可以把這個類別用來宣告新的物件..
books myBooks = new books();
像這樣在程式中可以隨時宣新的物件的方法, 是Object-Oriented的特色.
但, Object-Based的C/AL就不能這麼做. 例如上圖(Dynamics NAV Development Environment)中, 第一個Object是Table, 其中TableID=18的物件名為"Customer”, 這是Dynamics NAV記錄客戶資料的基本資料表, 所有銷售訂單的相關客戶資料都參照這個Table, 在C/AL的語法規定裏, 我們不能像C#那樣用new語法建立一個新的物件.
因為在C/AL裏, 這些物件都各別參照到SQL Server NAV database的一個物件, 物件的新增都必需透過Dynamics NAV 2013的C/SIDE, 先在SQL Server資料庫中建好物件, 才能在C/AL中引用. 例如, 我們想在Customer Table中增加一筆記錄, 就直接寫下程式列:
Customer.INIT;
Customer.”No.” = 1234';
Customer.Name = “Simon Huang”;
Customer.INSERT;
這樣就行了, 不用new宣告, 直接把Table Object拿來使用就可以了, 所以稱之為Object-Based. 其實, C/AL受到Pascal語言的影響很多, 在語法結構上, 往往可以看到Pascal的影子.
現在, 我們回到Microsoft Dynamics NAV 2013的七個主要物件: Table、Page、Report、Codeunit、Query、XMLport、MenuSuite. 如果曾經在Dynamics NAV 2009版本上進行開發工作, 應該會知道Dynamics NAV 的物件是: Table、Form、Page、Report、Codeunit、Dataport、XMLport、MenuSuite, Dynamics NAV 2013少了Form和Dataport物件
, 但多了Query物件.
就技術層面來說, Form物件指的是Windows Form技術, 現在Dynamics NAV 2013取消掉Form物件, 是否代表Page成為Web Form? 可以這麼說, 但這麼說只對了一部份, 因為Page實質上是一個XML物件, 由一堆Controls、Properties、Triggers、Codes和Actions組成, 並不完全是我們熟悉的Web Forms技術.
另一方面, 我們曾說Dynamics NAV的物件都會照到SQL Server中的物件, 但實務上, 在SQL Server中, 我們只能看到Table物件存在, 其他物件, 是以XML資料型態存在一些Dynamics NAV的系統資料表的資料錄中, 只能過C/SIDE來進行管理.
如下圖是用SQL Server Management Studion打開NAV Database看到的一部份:
因為SQL Server資料庫中的物件清單, 並不能直接對應到C/SIDE中的物件, 我們不能直接在SQL Server中進行開發設計的工作, 然後再在Dynamics NAV的C/SIDE中叫用, 一定要在C/SIDE中開發完成再部署到SQL Server NAV Database中.
這種系統開發方式, 在很多國外的中大型ERP系統常見到, 這樣做的好處是資料庫無關, 但, 自從被Microsoft購併後, 明顯把Dynamics NAV和SQL Server綁在一起, 又不能用Visual Studio來進行系統開發, 這樣的系統架構, 可能造成額外的技術負擔.
Dynamics NAV 2013的七種物件說明如下:
- Table, 那一大堆儲存資料錄的各式資料表.
- Page, 就是用來顯示與維護資料的表單畫面.
- Report, 把Table及其衍生資料欄位內容以報表形式表現.
- Codeunit, 就是User-Defined Function/Procedure, 把有共同程式邏輯的Table Trigger、Page Control或Report Rule寫成公用函式, 以便公用, 不致重覆編程.
- Query, 類似資料庫的View, 可以建立Query把一個或多個Table的資料錄重新編製成方便查閱的方式展現, 以利Page、Report或XMLport運用.
- XMLport, 提供Dynamics NAV 2013資料庫與其他系統資料庫間資料互通, 例如CRM系統資料庫和Dynamics NAV資料庫整合, 互抛資料時, 可以運用XMLport將資料抛轉到CRM資料庫, 也可以接收CRM資料庫抛過來的資料錄.
- MenuSuite, 就是RoleTailered Client或Web Client視窗左邊的功能表, 我們可直接客製不同的功能表, 以配合不同的需要.
日後, 我們會在討論Dynamics NAV 2013的個各系統功能時, 說明如何使用C/SIDE及C/AL來進行客製, 這一篇就大致介紹Dynamics NAV 2013系統開發的幾個重要觀念.
