2015年9月26日星期六

老鬼的眼光




今天好像大家突然關心起香港未來棟樑的發展前景. 但問題不是我們有沒有這樣的物質環境去培育下一代的創新精神, 而是我們這些上一代的老鬼眼光夠不夠遠去帶領下一代.

台灣在十多年前, 還在電腦領域上領先所有華文地區, 但在今天台灣竟然連網上付款都弄不好! 這不是技術問題, 而是法規問題. 台灣政府就是怕一旦把政策開的太寬太廣, 會被對岸的政府及商人淹沒. 但這只是口中的說詞, 他們其實要保護的是那些銀行. 可是未見其利, 先見其害. 網上付款元祖 PAYPAL 決定退出台灣本土的 P2P 市場, 即是如你是台灣人, 想經 PAYPAL 付款與另一台灣人, 現在已經是不可能的.

在一個十三億人的市場旁去維持一個二千萬人或甚至七百萬人的相對獨立市場, 其實就好像唐吉訶德的行為一樣荒唐可笑!

說回老鬼的眼光, 嗯, 我們其實好對不起下一代. 現在已經完全是電腦時代的當下, 我們竟然不去吹捧一些本土的IT ICON, 而只是一味地叫人考試考試, 專業專業... 然而考試不是罪, 專業才是原罪. 因為大部份這些非硬科學專業, 其實只是商人的工具, 或減低社會交易費用的工具. 我曾經說過所有減低社會交易費用的工作, 都必然會被社會壓低其本身的費用, 因為這些工作本身就是社會的交易費用. 而沒有壟斷權力的工作, 必然地會被其他更可減少社會交易費用的工作取代.

這裡我想介紹一個國內的網站, 她內裡的文章會叫很多香港人汗顏. 拜託, 不要再自吹自擂什麼我們有國際視野了, 我們其實早已經目光如豆.

http://36kr.com/

2015年9月9日星期三

香港 GROUPON 變形記


這是百份之一百的真人真事...

話說八月中時, 我太太在 GROUPON 買了點東西, 但要八月三十一才可以到位於銅鑼灣的取貨點拿取. 於是我在當日趁回公司之便順手去一轉取貨啦.

去到當然要先取籌排隊等服務, 我便取出我的 "枕頭書" 開始裝作有文化, 也順道掩飾一下自己的大肚子.

"B049, B049 2號櫃台"

終於到我了, 於是我蓋上手上的枕頭後走向2號COUNTER. 嘩, 抬頭一看乖乖不得了, 櫃台後竟然站著一個正妹店員, 心想今天真LUCKY.

去到櫃台前站好, 弄一弄自己又濕又油的頭髮後, 與正妹的對答終於展開了. (以下對話是以廣東話進行, 為了保持香港獨有的韻味, 我就不白話文化了)

正妹: 先生, B049喎

我: B049囉

正妹: B 0 4 9 ?!

我: 係我啦, 嗱你自己看飛嘞.

於是她把那一小包東西交到我手上, 然後我就開始根據太太的指示拆開包裝, 仔細檢驗貨品有無破損.

在檢查好, 我當然好有禮貌地向她說句: "THANK YOU" 啦, 並施施然把那包東西收好到背包內.

但是從她的眼神中, 我看到一絲恐懼, 一絲嘔心, 一絲厭惡, 簡單地說, 她根本將 "變態佬" 三個字寫在雙眼之中...

以下就是我替太太取的貨品. 作為一位有婦之夫, 替太太取點東西, 有什麼好大驚小怪的?!
















2015年7月17日星期五

Job Management DB 設計詳解之不解釋三


Various Job Performance Reports



Add Job



Add Client

2015年7月8日星期三

Job Management DB 設計詳解之不解釋二



Legal Entities Report by Position



Reg Address Service Client Report
& Non-Reg Address Client Report


Time Sheet Function and Report for Individual Staff with Free Period Range Selection



Legal Entities and Related Bank Details List and Export Function





自己看, 不解釋

2015年6月29日星期一

Job Management DB 設計詳解之不解釋


這是十天前...

這是八天前...

這是兩天前...

不解釋!

哈哈
!


2015年6月21日星期日

Job Management DB 設計詳解之四: Client 的其他資料

(最後設計或有修改)

上一篇說了 Client 的基本資料, 這篇就會說 Client 的詳細資料. 在上圖中, 你會發現主版只 CLIENT 一個選項, 其他資料都分門別類放到不同的分頁中.


第一個分頁: NAME

Date of Change: 名稱變更生效日期
Name: 歐洲語系的新名字
CJK Name:  非歐洲語系的新名字
Job Code: 有關名稱變更的 Job


第二個分頁: CONTACT ADDRESS

CONTACT ADDRESS 是 CLIENT 真正的聯絡地址
Address Line 1-3 : 地址
Telephone 1-2 : 電話
Fax 1-2 : 傳真
Email: 電郵地址
Website: 網址
Nation/Area: 國家/地區.


第三個分頁: REG ADDRESS

REG ADDRESS 是 CLIENT 的註冊地址

From: 生效日期
To: 失效日期
Address Line 1-3 : 地址
Nation/Area: 國家/地區
Telephone 1-2 : 電話
Fax 1-2 : 傳真
Job Code: 有關REG ADDRESS的 Job


第四個分頁: DIRECTOR

Director: 董事名稱, 從LEGAL ENTITIES中選擇
Appoint Date: 委任日期
Dismiss Date: 解任日期
Remark: 備註
Job Code: 有關董事委/解任的 Job


第五個分頁: YEAR ENDED

Date of Change: 年結變更生效日期
Day: 年結日
Month: 年結月
IRD Code: 稅局Accounting Code
Job Code: 有關年結變更的 Job


第六個分頁: CO SEC

CoSec: 公司秘書名稱, 從LEGAL ENTITIES中選擇
Appoint Date: 委任日期
Dismiss Date: 解任日期
Remark: 備註
Job Code: 有關公司秘書委/解任的 Job


第七個分頁: BANK


Bank: 銀行名稱, 從BANK中選擇
Account Number: 戶口號碼
Primary?: 是否主戶口
Job Code: 有關開設/關閉銀行戶口的 Job


第八個分頁: ARAP


ARAP: 應收應付方名稱, 從ARAP中選擇
Job Code: 有關開設/關閉銀行戶口的 Job


有關 SHAREHOLDER 的, 請留意下一篇

2015年6月20日星期六

Job Management DB 設計詳解之三: Client & Job

(最後設計或有修改)

來到第三篇, 開始進入比較實質的階段, 就是 Client 及 Job 的詳細解說. 

Client 在這裡的定意就是 "向其提供服務的法人/組織" , 而 Job 就是其中所提及的 "服務". 因此, 沒有 Client 就沒有 Job. 


CLIENT BASIC EDITOR


CLIENT BASIC EDITOR  可以作為新增修改 Client 基本資料, 共有九個 Field:

Code:  CLIENT 的編碼, 不可重複, 如果留白, 系統會自己補號
CI #: 有限公司註冊編號
Incorporate Date: 有限公司成立日期
BR# (Part 1): 商業登記証號碼
BR# (Part 2): 商業登記証的分行編號, 預設000
Commenced Date: 開業日期
In-Charge: 負責職員
Status: 狀態
Rate: 評價
Remark: 備註


JOB EDITOR


JOB EDITOR 有十九個Field 及四個分頁. 十九個Field分別是:

Client: 選擇應對的CLIENT
Code: JOB 的編碼, 不可重複, 如果留白, 系統會自己補號
Firm: 選擇提供服務的公司
In-Charge Partner: 選擇一位 Partner級的Staff
Audit/B.Keep/Co Sec/Tax/Other: Job的屬性, 只能選其中之一
Type (Other): 只當Other屬性為 "Yes" 時才會開啟
Scheduled Start: 預計開始日
Scheduled End: 預計完成日
Actual Start: 實際開始日
Actual End: 實際完成日
Payment Status: 付款狀態
Status: JOB 狀態
Year: JOB涉及的年份
Year End Date: 財務年度終結日
Job Closed: 完成狀態

四個分頁分別是:

Progress: 分頁內容不可修改

Remark: JOB的備註,可修改

Remark: JOB的MEMBER,可修改

Remark: JOB的BUDGET,可修改
註: 系統會加總這分頁的所有記錄並用在所有相關REPORT/FORM之中






2015年6月19日星期五

Job Management DB 設計詳解之二: Basic Information

(最後設計或有修改)

為了增加這個 Job Management DB 的環境適應能力, 所以我把資料分成數個種類, 而這篇會講解 Basic Information


第一個是: AR/AP MANAGER



AR/AP MANAGER 主要存放 AR/AP 的聯絡資料, 如名稱, 地址等, 但不包括 CLIENT. 這個做是希望這些基本資料可以跨 CLIENT 使用, 即是如果 CLIENT A & CLIENT B 都有一個AR/AP 叫 ABC TRADING LIMITED 時, 那 USER 就不用重複輸入這些基本資料.

AR/AP MANAGER 有九個 Field:

Code:  AR/AP的編碼, 不可重複, 如果留白, 系統會自己補號
Name: 歐洲語系的名字
CJK Name:  非歐洲語系的名字
Address Line 1-3 : 地址
Nation/Area: 國家/地區
Tel: 電話
Department/Attn.: 部門/聯絡人

這些 AR/AP 主要出現在 <CLIENT INFO REGISTER - AR/AP> 版面



及 <AR/AP CONFIRMATION MANAGER> 版面




第二個是: BANK MANAGER


BANK MANAGER 主要存放 BANK 的聯絡資料, 如名稱, 地址等, 但不包括 CLIENT. 這個做是希望這些基本資料可以跨 CLIENT 使用, 即是如果 CLIENT A & CLIENT B 都有一個 BANK 叫 ABC BANK 時, 那 USER 就不用重複輸入這些基本資料.

BANK MANAGER 有九個 Field:

Code:  BANK的編碼, 不可重複, 如果留白, 系統會自己補號
Name: 歐洲語系的名字
CJK Name:  非歐洲語系的名字
Address Line 1-3 : 地址
Nation/Area: 國家/地區
Tel: 電話
Department/Attn.: 部門/聯絡人

這些 AR/AP 主要出現在 <CLIENT INFO REGISTER - BANK> 版面


及 <BANK CONFIRMATION MANAGER> 版面



第三個是: NATION/AREA


NATION/AREA 主要存放不同國家/地區的名稱資料, 使 USER 不用重複輸入這些基本資料.

NATION/AREA MANAGER 有三個 Field:

Alpha-3e:  ISO Alpha-3e 國家地區的編碼
Name: 歐洲語系的名字
A.K.A: 其他通稱

這些 NATION/AREA 會出現在很多不同的版面, 基本上你看到 NATION/AREA Field 就是他們



第四個是: IRD ACCOUNTING CODE


基本上你不會看到他們出現在其他的地方, 但系統用他們來自動填上 <JOB> 版面 的 SCHEDULED DATE OF ENDING (只限於 AUDIT, BOOK KEEPING 及 TAX)



第五個是: TITLE



TITLE 存放不同稱謂資料, 使 USER 不用重複輸入這些基本資料

暫時我只讓他們出現在 <CLIENT CONTACTS REGISTER> 之中




第六個是: LEGAL ENTITIES


LEGAL ENTITIES 主要存放那些 SHAREHOLDER/DIRECTOR/CO SEC 的基本資料, 如名稱, ID號碼等, 但不包括 CLIENT. 這個做是希望這些基本資料可以跨 CLIENT 使用, 即是如果 CLIENT A & CLIENT B 都有一個 DIRECTOR 叫 CHAN DAI MAN 時, 那 USER 就不用重複輸入這些基本資料.

LEGAL ENTITIES 有九個 Field:

Name: 歐洲語系的名字
CJK Name:  非歐洲語系的名字
Type : Corporate/Person
HKID1: 身份証括號的字元 (當Type是Person才可輸入)
HKID2: 身份証括號的字元 (當Type是Person才可輸入)
Passport: 護照號碼 (當Type是Person及HKID1&2為空時才可輸入)
CI#: CI / BR 號碼 (當Type是Corporate時才可輸入)
Nation/Area: 國藉

這些 AR/AP 主要出現在 <CLIENT INFO REGISTER - DIRECTOR> 版面


 <CLIENT INFO REGISTER - CO SEC> 版面


及 <SHAREHOLDER REGISTER> 版面



第七個是: LEGAL ENTITIES ADDRESS


LEGAL ENTITIES 主要存放那些 SHAREHOLDER/DIRECTOR/CO SEC 的地址, 每一個LEGAL ENTITIES都可以用數個地址, 但系統的預設都是使用最新DATE OF CHANGE的那一個地址記錄.





2015年6月18日星期四

Job Management DB 設計詳解之一: Type Settings

(最後設計或有修改)

為了增加這個 Job Management DB 的環境適應能力, 所以我把資料分成數個種類. 首先來說說最基本的 "TYPE"

第一個是: DOCUMENT TYPE


DOCUMENT TYPE 有四個 Field :

Code: 文件種類的編碼, 不可重複
Description: 文件種類的名稱/扼要陳述, 可重複
IRD Doc? Yes/No, 判別該文件種類屬不屬稅局文件

這個DOCUMENT TYPE 主要出現在 <CLIENT DOCUMENT RECORD MANAGER> 版面



第二個是: JOB STATUS TYPE


JOB STATUS TYPE 有兩個 Field :
Code: 工作階段的編碼, 不可重複
Description: 工作階段的名稱/扼要陳述, 可重複

這個JOB STATUS TYPE 主要出現在 <JOB MANAGER> 版面


第三個是: JOB PROGRESS TYPE


JOB PROGRESS TYPE 有兩個 Field : 

Code: 工作進度的編碼, 不可重複
Description: 工作進度的名稱/扼要陳述, 可重複

這個JOB PROGRESS TYPE 主要出現在 <JOB PROGRESS RECORD MANAGER> 版面


第四個是: CLIENT STATUS TYPE


CLIENT STATUS TYPE 有兩個 Field : 

Code: CLIENT狀態的編碼, 不可重複
Description: 狀態的名稱/扼要陳述, 可重複

這個CLIENT STATUS TYPE 主要出現在 <CLIENT EDITOR> 版面



第五個是: OTHER SERVICE TYPE


CLIENT RATE TYPE 有兩個 Field : 

Code: CLIENT RATE種類的編碼, 不可重複
Description: RATE種類的名稱/扼要陳述, 可重複

這個CLIENT RATE TYPE 主要出現在 <CLIENT EDITOR> 版面




第六個是: OTHER SERVICE TYPE


OTHER SERVICE TYPE 有兩個 Field : 

Code: 其他服務的編碼, 不可重複
Description: 其他服務的名稱/扼要陳述, 可重複

這個OTHER SERVICE TYPE 主要出現在 <JOB MANAGER> 版面, 但要選了OTHER後才會准許更改.


第七個是: PAYMENT STATUS TYPE

PAYMENT STATUS TYPE 有一個 Field : 

Code: 付款階段的編碼, 不可重複
這個 PAYMENT STATUS TYPE 主要出現在 <JOB MANAGER> 版面.



第八個是: SHARE TYPE



SHARE TYPE 有兩個 Field : 

Code: 股份種類的編碼, 不可重複
Description: 股份種類的名稱/扼要陳述, 可重複

這個SHARE TYPE 主要出現在 <SHAREHOLDER MANAGER> 版面


第九個是: SUNDRY TYPE



SUNDRY TYPE 有兩個 Field : 

Code: 雜項消費的編碼, 不可重複
Description: 雜項消費的名稱/扼要陳述, 可重複

這個SUNDRY TYPE 主要出現在 <STAFF SUNDRY EXPENSE RECORDER> 版面



第十個是: VIA TYPE


VIA TYPE 有兩個 Field : 

Code: 途徑種類的編碼, 不可重複
Description: 途徑種類的名稱/扼要陳述, 可重複

這個 VIA TYPE 主要出現在 DOCUMENT, BANK CONFIRMATION, 及AR/AP CONFIRMATION 等版面