大約在五月中旬，我終於鼓起勇氣去開發下一代的OACC。為什麼要鼓起勇氣呢？因為我知道這將會是一個浩大的工程，而且在其中也會有很多困難，不論是技術上及邏輯上的，要去克服。而最大的問題是，我有否這樣的一個決心呢？唔。。。
OACC的第一個版本是為我所工作的公司而編寫的，那次的開發很順利，速度也快。原因就在於我有很多數據在手，而且我也很熟悉自己公司的商業邏輯及需求。簡而言之，第一版的OACC是一個度身定造的軟件。
OACC第二版是在第一版的基礎上進行改良，加入很多泛用的功能，隱藏了第一版中為我司度身定造的特殊功能。其中，我花了很大氣力來實作Inventory的流程，FIFO，倉庫間的運轉與存量，引入Quotation，Purchase Order及Payment Terms。另方面亦加入了Aging Report及Bank Reconciliation等功能。
但是，這兩個版本的OACC都有一個先天性的問題，而這個問題糾結在我心中一直發酵，日夜在折磨著我。這個問題就是OACC並不是一個獨立的程式。這兩個版本的OACC都是使用Microsoft Access來開發User Interface，並使用Oracle MySQL作為後端Database。
當然，很多系統背後都是使用MySQL，SQL Server，Oracle SQL或MariaDB等，但是我的User Interface並不能在第一次使用時自動建立ODBC連線，使用者必須自己手動建立，雖然過程並不複雜，但是感覺就是不完美．可是，不完美在這裡卻代表了高靈活度．在設計OACC的EER時, 我自覺地只使用了INT，DECIMAL，DATE及VARCHAR等數種最基本的SQL Database資料形態．雖然只使用數種形態會浪費了Server上的儲存位元，但是可以大幅地提高OACC在不同品牌SQL Server之間的可移植性．
而使用Microsoft Access來開發User Interface使我糾結的原因在於：第一，前景不明；雖然在可見的將來Microsoft都不會放棄Access這成功的產品，但是要是有一天真的發生呢？那OACC將不可避免地被牽連．第二，單一平台；Microsoft Access發展了這麼長時間，Microsoft 從未如Excel或Word在其他平台上發布，在現在連Android都有了Microsoft Office Mobile的時候，Access依然缺席在其他平台之上．所以我決定使用另一種Program Language來開發下一代OACC, 雖然暫時心目中所想的是C#，但是這次休假我會好好去研究應該採用那一種Program Language．
除了這些問題外，最重要是我想做得更好，使OACC可應用的範圍更廣．這就帶出了另一個更重要更嚴肅的問題：到底OACC要走多遠．
Double Entry，Multi-Currency，Inventory，Aging，Bank Reconciliation，Cash Flow，Balance Sheet，Income Statement，Departmental Accounting，Financial Analysis及Investment Portfolio等等都已經在之前的兩個版本及另一個Database中實現了出來．那未來要走到那裡呢？Payroll，Human Resource, Group Companies Consolidation Statements，Customer Managing 如何實作這些都已經在心中成形，但是我還有一個更具野心卻未成形的想法，就是將Audit Procedure自動化．
將Audit Procedure自動化的困難有兩點：第一，Normalization; 第二，Flexibility．而這兩點是互相矛盾的．
關於Normalization的問題應該不難解決，只是我暫時未找到一個好的切入點．但是Flexibility則複雜得多．如果你也是從事會計行業的，就應該知道Accounting Standard的變化有多頻密，一年一小變，三年一大變．對Bookkeeping來說，很多這些的變化是可以置之不理，但是對Auditing來說，這些Standard就是生命的一部份．可對於一個Database來說，這些頻密的變化卻是非常要命的，因為經常地更改底層架構是不可能也不實際的．於是我要想出一個方法去應對．
”入數即核數 ”是一個夢想，縱使知道整個System的複雜度會因此而大幅提高，但我還是覺得值得的．
沒有留言:
發佈留言