顯示包含「會計」標籤的文章。顯示所有文章
顯示包含「會計」標籤的文章。顯示所有文章

2013年9月27日星期五

自製記帳軟件 - 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 中的傳單介面中的分佈.


很累, 下回繼續...





2013年9月12日星期四

窮查理的普通常識


家有一老, 如有一寶.

逆向思考
看罷這本書, 就像與一位和藹可親而且學識淵博的長者詳談了十一次, 他的大度, 學養及看透世情的幽默, 讓我再三回味. 本書其實是作者十一篇演講稿的匯集, 作者的生平及他的朋友對他的評價, 每一篇都有特定主題, 像是第一講 "如何讓生活悲慘".  這個非常題目, 正正就是作者在書中反覆強調的逆向思考的真諦:

"曾經有個鄉下人說: 我只想知道我將來會死在什麼地方, 這樣我就可以永遠不去那裡" - P.102

跨領域技能
作者認為每個人, 不論是否專業人士, 都應不停吸收不同領域的知識. 首先他認為終身學習是一種對自己對家人及對社會負責任的行為, 因為這種態度可以令所有人遠離鐵錘人傾向, 而這種傾向是造成很多軟科學偏離現實並引致種種社會問題的根源. 如何可以避免成為鐵錘人的方法就是實行"拿來主義", 但是要避免意識形態的污染. 因為在作者眼中, 極端的意識形態是可以令人腦快速痿縮, 就算是聰明絕頂的人也不能幸免.

魯拉帕路薩效應
魯拉帕路薩效應是作者自創的新名詞, 意思是指有多種不同效應疊加, 然後這些效應都變得極大化. 這種效應可以使人成功, 也可以使人失敗, 端視這些是什麼效應. 我覺得這個效應很有趣, 也很真實. 在現代各種專業都分割的很細, 使我們在分析問題時有種見樹不見林的傾向, 我們喜歡找到一個唯一的簡單的原因來去解釋世事, 因為這樣我們就可以扮作智者, 去唬弄不明就裡的外行人. 然而世事的發生是因為多種效應共同發生的果. 這種追求優美的執著, 或許是物理學成功的負面效應, 然而在面對量子世界時(更不要提"絃論"), 物理學已經放棄了傳統思維.

經濟學及會計學
作者對這兩個學科的質疑與嘲諷, 貫穿了整本書. 作為一位會計從業人員, 看到作者視那些制定偏向管理層而忽視投資者的會計準則的會計師為"背叛者", 心頭確是有一刻不爽, 卻又無法不認同. 另一方面作者也對我畢生興趣 - 經濟學, 一一指出其十個缺憾. 如果你也對這兩個學科有興趣有感情, 書中的第八及第九講, 務必再三細讀.

本書滿載著一位成功而開明的長者充滿智慧的哲理, 而最可貴的是這些哲理根本就在我們大家的身邊, 能否領悟當中意義, 不在智商高低, 而是我們是否願意聆聽.


ISBN: 9789868685734
作者: 查里.蒙格 Charkes T. Munger
編者: 彼德,考夫曼 Peter Kaufman
譯者: 李繼宏等
出版: 城邦文化

2013年9月4日星期三

自製記帳軟件 - 思考


動機有了, 工具選了, 是時候思考想要的目標有幾多.  在思考時要將目標分為幾個類別, 並設定先後次序, 好讓自己不會在漫長的開發過程中迷失了. 

思辯
在這階段可以先不想電腦硬體及網絡設備, 因為這些都是金錢可以解決的問題. 要多花時間去細心思考的是如何將日常工作的流程在電腦內重現. 為此, 我有段時間真的自我閉關, 甚至學周伯通以自言自語來跟自己思辯, 只為解決一些在類比世界沒有但卻會在電腦世界發生的邏輯問題. 再一次, 香煙真是好伴侶... (香港政府忠告市民: 吸煙危害健康).

另一個需思考再思考的就是整個系統背後的 Database Schema. Schema 是什麼呢? 它就是讓資料庫管理軟件知道如何儲存你所輸入的資訊, 其關聯性及屬性. 如果以建築大廈作例子, 那 Schema 就是你系統中的建築藍圖. 即是當你設計一個 Schema 時, 你要想像及考慮到整個工作流程及如何達到目標, 換句話說這是 "商業邏輯"! 

Point of No Return
再用建築大廈來說明思考在設計 Database Schema 的重要, 因為 Database Schema 是沒有 Trial & Error 的機會, 而 P.N.R. 就在落實 Schema 前的那一刻. 想像一下你在設計一座住宅大廈的時候, 你會為未來的目標住客設計出適合他們生活習慣或品味的間隔, 睡房和廁所的數目, 廚房的位置, 客廳大小, 甚至樓高, 每方尺承重等等不同的屬性. 當藍圖落實後, 工程師及工人就可以開始根據你的藍圖來動工. 突然市場氣氛轉變, 然後老闆跟你說: "啊, 我們要將這大廈轉變為辦公大樓!" 

於是你叫停工序, 打開藍圖一一審視可修改之處 (在這裡"關聯式資料庳"再一次跟大廈結構很相似; 就是環環相扣, 是真真正正的 "牽一髮而動全身"). 但是你發現, 如果你修改A, 就必須改B, 而修改B, 就要把C也改掉. 如此類推直到修改最核心的部份為止. 然而當你修改最核心的部份, 就變成整個架構都要修改! 緊記的是, 當你的完成度越高, 要修改的東西就越多. 

在分析後你可能發現, 打掉重來可能是邏輯上最合理的辦法, 但往往因為經濟政治等問題而有所不能. 到最後你只能作一些小修小補, 甚至不惜潛建來達到目的. 這樣的成品出來之後不是失敗缺乏效益, 就是成了四不像. 

祖師爺
上圖是 Luca Pacioli (1445-1517) 的肖像. 在文藝復興時期這樣的肖像油畫對被繪者來說, 可說是一種非常高的榮譽. Pacioli 被譽為會計之父,  雖然他並非複式簿記的發明人, 但是他是第一個梳理複式簿記的流程, 規則並全面以阿拉伯數字論述其數學思想及出版的人, 因為其關於複式簿記的部份被獨立成書並暢銷歐洲各國, 促使歐洲揮別難於計算的羅馬數字, 擁抱我們現在日常所見的阿拉伯數字. 所以更被現代某些人說他是這個日漸資料化世界的奠基人! 

說說題外話, 在 Wikipedia 上的 Database Schema 題目有十一種不同語言版本, 亞洲的有韓文(非常簡短)及日文, 但是沒有中文. 為何會這樣的呢?


2013年9月1日星期日

自製記帳軟件 - 原因


"我要寫一個記帳軟件!" 
每當有人在大小討論區提出這樣的豪言壯語時, 周遭的網友大都會回問: "為什麼不買一個現成的?" 是啊, 坊間現成的記帳軟件已經發展的非常成熟而且價格相宜, 實在沒理由自己大費周張去寫的. 但是罐頭式的軟件也有它們的局限, 要不然市場上也不會有那麼多獨立的軟件公司提供客制化的記帳軟件.

獨一無二
每一間公司都是獨一無二的, 各有不同需要, 罐頭式記帳軟件雖然可以應付到大部份的工作要求, 但是去到枝末小節時, 它們的局限就會變得刺眼. 我親身體驗過, 記帳後還要用Microsoft Excel去做報表的苦況...

多人作業問題
記帳通常都是團隊分工的: 出單, 入單, 出納, 批核等等不同崗位都需要即時和系統溝通. 但是罐頭式記帳軟件通常都是單機版並以檔案形式儲存資料, 即是只能安裝在一台電腦之上, 那又如何多人共同作業呢. 雖然有些品牌有多推出多人版本, 但是它們通常是透過內聯網以檔案分享形式來達至多人作業. 這就帶出一個危機出來: 如果那個檔案損毀了怎麼辦? 如果是單機使用, 檔案損毀的機率是很低的, 但是在網絡中分享檔案, 其損壞的機率是高很多的. 電力或網絡不穩, 隨機的封包掉失, 客戶端突然斷聯等再加上單機本身已經有可能發生的故障, 這些都令檔案損毀的可能性大增.

版權成本
過去罐頭式記帳軟件都是沒有限制公司數目, 就好像Microsoft Excel一樣, 你喜歡建立多少檔案也可以. 但是幾年前開始, 有軟件公司已經改變這種授權方式, 每一套軟件都只能建立一定數量的公司, 如果多於此數則需要跟他們買額外的授權. 對於一般公司來說, 這並沒有什麼不便, 但是對於有提供簿記服務的會計樓, 這就會增加他們的營運成本.

當然還有很多其他的理由去支持編寫一套屬於自己的記帳軟件, 但我就不一一細數. 光是上述三點已經足夠讓我執意去完成這個"唐吉訶德"式的夢. 或許背後推動自己的是 "I Can! Can You?" 這種虛榮吧.