自製記帳軟件 - Voucher 實體到虛疑

說了Schema, 說了Datatype, 是應該開始便用 MySQL Workbench 來實作的了. 但在這之前, 還是讓我說說一些邏輯上的東西吧. 為什麼還要說個不停? 因為這是關係到 Database Normalization 啊, 說的是系統的成與敗啊, 所以還是讓我說吧.

資訊

上圖是一張很平凡的 Payment Voucher (這個字太多不同的中文譯名, 所以我乾脆用回英文算了), 其中包含了很多資訊, 每一項資訊都有特定的功能, 有些是可以再用的, 有些則否. 在設計 Schema 時, 我們必須想清楚什麼是最核心的最不可或缺的資訊. 而在複式簿記 (Double Entry Bookkeeping) 之中, "日期 (Date)", "詳細 (Description)", "賬目 (Account)", "借方金額 (Debit Amount)" 及 "貸方金額 (Credit Amount)" 就是最不可或缺的五項資訊. 只要有了這五項資訊, 就是用 Microsoft Excel 來作記錄, 再加上善用 Sort 及 Filter 功能, 大家都可以輕鬆完成一盤會計賬目. 當然用 Microsoft Excel 來造賬, 出現錯誤的機會是很高的. 這並不是因為它本身有什麼程式缺憾, 而是因為人手參與的頻率與程度太高. 而記帳軟件其中的一個面向就是要盡量減少人手參與, 這是在設計 Schema 及 User Interface 時要多加留心的.

複式簿記流程

在繼續之前, 還是要略略說說複式簿記的流程. 首先會計人員在取得原始憑據後或某些特定事件發生或達到某個日期後, 會根據不同性質而開立不同的傳票, 並在傳票上列明事項日期, 詳細, 借方及(或)貸方賬目與金額, 涉事人員或公司. 在一天結束後將該所有當天的傳票, 匯整成日誌並結算借貸雙方的金額. 日誌上的借貸雙方的金額必須相等方何再轉錄到分賬內.

手民之誤

或許你會說所有資料不都是人手輸入的, 所以免除手民之誤是個不可能的任務. 可我們不是要免除, 而是要減少, 而且是盡量減少! 那如何作才可以減少 Human Error 呢? 答案就是限制同樣的資料以人手輸入的次數. 換句話說, 就是有效地善用已經輸入的資料. 在複式簿記的實作中, 有很多的資料都是重複, 像是"傳票類型", "賬目", "客戶", "供應商", "員工", "產品", "物品"等的名稱與編號. 這些重複性的資訊, 我們應該獨立建造屬於它們的資料表 (Table), 以待日後可以容易選取使用及設計查詢 (Query). 這部份我們日後會慢慢的涉獵到, 現在先按下不表.

資料類型

之前說過的五項主要資料是 "日期", "詳細", "賬目", "借方金額" 及 "貸方金額", 但是為了有效地解讀賬冊, 光有他們是不夠的. 於是我們還要加上如上一段所列的資訊. 資訊有了一大堆, 但是我們還要把它們分類. 基本我們可以把它們分成三類:

Basic Data (基本資料類型): 包括 "日期", "詳細", "傳票類型", "客戶/供應商" 及 "員工"

Transaction Data (交易資料類型): 包括 "賬目", "借方金額" 及 "貸方金額"

Additional Transaction Data (輔助交易資料類型): 包括 "產品" 或 "物品", 及其單價和數量

上述三類資料類型, 即代表著三個獨立的資料表. 下圖顯示了這三種類型在 OrangeAcc 中的傳單介面中的分佈.

很累, 下回繼續...