表 1 提案單需求類別分析統計表 年度 類別 79 80 81 82 83 84 85 86 87 88 89 90 91 需要變更資料結構 3 1 1 4 2 10 3 4 0 0 0 0 0 規則變動 4 5 2 5 15 5 1 2 5 1 1 2 0 配合其他系統 4 0 1 1 1 3 2 1 0 1 5 0 2 新增需求功能 9 11 21 26 8 7 8 6 3 2 1 2 6 報表內容調整 12 5 17 11 13 8 0 2 1 2 3 1 2 其他需求修改 5 7 8 5 3 3 4 2 2 3 1 1 1 資料處理 2 6 6 6 1 1 0 0 0 1 0 0 0 自提系統改善 3 15 11 8 6 7 2 0 1 1 1 1 0 其他單位支援 0 3 2 2 1 1 1 0 0 0 0 0 2 合計 42 53 69 68 50 45 21 17 12 11 12 7 13
薪資管理系統 的再生與繼往開來
詹雪梅
國立清華大學計算機與通訊中心校務資訊組
[email protected]
摘要
網路與電腦的普及，傳統應用系統的設計與 技術受到衝擊與考驗，本校自民國 75 年起即開始 校務 行政電腦化業務 ，早期的大 型 封閉 式 主機 HP3000 與網連式(Network)資料庫，隨著業務的持 續增長與用戶層面的擴增，已面臨瓶頸 ，考量軟 硬體的維護與成本，與圖形視窗介面的應用趨勢， 及因應網際網路時代的來臨，遂於民國 87 年起開 始規劃進行汰換主機、系統轉型等事宜。 本人首先將負責的各項系統之歷年來的需求 提案單，加以分類統計，作成問題點分析。利用 系統轉型，資料庫、程式介面可全面換新之時機， 從改革資料庫結構、檢討流程、及將作業規則表 格化等重點著手，徹底改善系統，期使新一代系 統功能更趨完善。新系統工程已完成，選出其中 最具代表性的薪資管理系統作為簡介，以它的再 生案例，說明如何繼承往昔所有業務效能之持續 運作，同時也為未來拓展應用鋪下便利之路。 關鍵詞：校務行政，薪資管理。1. 薪資管理系統
本系統作業範圍廣泛，只要是校內人員屬於 薪資所得之金額發放，皆屬其範疇，包含教職員 工薪資、計畫薪資、契約工薪資、各類鐘點費、 考績及晉級、調薪追加、年終獎金、年節獎金、 不休假加班費、各類補助費、各類代扣款、所得 扣繳與申報、銀行轉帳及帳號管理．．．等子系 統。 一般人會認為學校人員單純，薪資發放應屬 易事，然而不幸的是，本校研究計畫眾多，受薪 人員領域廣泛，包括專任教師、兼任教師、教官、 職技員、工友、契約工、博士後研究員 、助理、 學生、計畫專案人員、聘僱人員、退休人員等。 不同的所得人編號，擷取不同的人事資料來 源；不同的體制，產生不同的給薪標準；不同的 所得性質，採用不同的扣繳標準；不同的身份， 決定不同的代扣撥款來源；不定期的補助或獎金， 可能併月薪或獨立機動放款．．．等等因素，建 造出本系統如網狀般的複雜性，處理上的困難度 很難被一般人所理解。2. 提案單制度
本組自發展校務資訊系統以來，對於系統的 開發與維護，一直採用提案單制度，業務單位如 因環境因素、政策法令的變動，需要修改系統， 或是業務上有新增功能之需求，均須先填寫『系 統需求改善提案單』，向本組提出申請，經本組進 行需求評估後，再核定是否實行。 本人自民國 79 年 9 月開始承接薪資管理系 統，將歷年來的提案單作一統計歸類如表 1。3. 提案單 需求類別分析
3.1 需 要 變 更 資 料 結 構 薪資系統中的資料檔案，以「個人薪資明細」 為最主要，其檔案結構示意圖如圖 2。 先人建設之資料架構，有如傳統房屋建築模 式般，必須預先建置好幾房幾廳的規模 ，一個房 間供一個房客使用。為了未來的擴展性 ，初期大 部分都會先預置幾個空房，雖然有點浪費空間， 但對於往後有新加入房客的需求時，暫時提供了 即時住房的便利性。例如：圖 2 中之 CRED1 、 CRED2 、 SAL-BANK-CRED3 、SAL-BANK-CRED4 等資料項目，就是 預留給銀行貸款使用的例子。 對於資料結構的修改，資料庫大部分都會有 管理工具可進行整個資料重建，資料量的多寡會 影響執行的難易，但最困擾的部分是整建過程後 接續的程式修改工程，要在系統中一一檢視程式 是否需要修正，及真正對指令進行編輯，全靠人 力，別無他法可取代。薪資系統的歷史悠久，資 料量龐大，衍生的系統功能眾多，集所有不利條 件於一身，沒有人會願意經常去更動結構。 上列的建屋架構，等住宿率達到滿點時，當 時採取的應變措施是清理不用房間的房客，以新 房客遞補該房，例如：圖 2 中之 SAL-RET_INO， 原本是退休保險費，因自 81 年 2 月後就沒有發生 代扣事實，所以轉為給退休撫恤金使用 。此法雖 然暫時解決問題，但是對於資料的追蹤 ，卻無法 提供忠實的參考史實。 民國 84 至 86 年間，因全民健保開辦，又值 銀行貸款業務興盛，薪資代扣業務順勢而生，期 間增加了不少數項代扣款項，如：公務人員健保 費、勞工健保費、退休撫恤金、離職儲金、中興 銀行貸款、台灣銀行貸款、退休撫恤金貸款、北 院房租費、宿舍管理費、汽機車停車費 、法院扣 款．．．等。 系統原本的資料架構與應變措施，最終還是 無法承載，最後一途仍是－房屋重建，重新配置 空間。然而空間的擴充永遠不及未來需求的變化， 這段期間還是數度修改檔案結構，加上每次都不 可避免的程式修改工程，著實付出相當大的維護 成本。 3.2 作 業 規 則 變 動 作業規則的變動，大致上可分為兩類，一是 發放所得的計算，一是代扣款項的計算。從表 1 中可觀察出每年幾乎都有因規則變動而需修改程 式的提案單，其中九成都是與所得稅法有關。早 期的設計，均是在程式中寫下所有的計算法則， 寫下一堆 If … Else … 指令與設定扣繳稅率值， 當變更稅法或是調整稅率時，就要由程式人員來 修正所有相關程式。在 If … Else … 指令篩選的過 程中，經常暗藏危機，如果沒有謹慎閱讀程式， 檢查邏輯，常會遺漏一些特殊因子，當問題發生 時，程式人員就有承擔責任的風險。 最顯著的例子是：教官原則上所得免申報， 但其適用範圍僅限於統一薪俸、專業加給、交通 津貼、子女教育補助費，其餘的津貼則一律要申 報扣繳。開發初期，教官因無他項津貼 ，業務單 位沒有告知但書，直到問題浮出檯面，才引發一 個人薪資明細 A001 095 03 33390 21920 0 0 0 ．． B002 095 03 50190 44290 8440 0 0 ．． ． ． ． ．薪資系統資料庫
SAL-MEDICINE 醫 藥 費 SAL-NGAS 瓦 斯 費 SAL-PHONE 電 話 費 SAL-WATER 水 費 SAL-DEBIT 借 支 SAL-HOUSE-CRED 公教貸款 SAL-URGE-CRED 急難貸款 SAL-ERAN 所 得 稅 SAL-INR (公保)眷保費 OTHER-SUB1 其他代扣款 84.5.1 OTHER-SUB2 宿舍管理費 84.5.1 OTHER-SUB3 收回房租津貼 OTHER-SUB4 房 租 費 84.4.25 SAL-HEALTH (公)健保費 84.3.10 SAL-HEALTHB (勞)健保費 84.4.18 SAL-BANK-CRED1 85中銀貸款 85.3.21 SAL-BANK-CRED2 86中銀貸款 86.5.20 SAL-BANK-CRED3 83中銀貸款 84.5.1 SAL-BANK-CRED4 退撫金貸款 86.4.17 SAL-HIRE-SAV 離職儲金 86.1.19 PER-NO 人事編號 YEAR 年 度 MONTH 月 份 SAL-BASIC 統一薪俸金額 SAL-WORK-AID工作補助金額 SAL-MGR 主管加給金額 SAL-HOUSE 房租津貼 SAL-REP-MON 實物代金 SAL-TRAFFIC 交通津貼 SAL-AID 課稅之補發金額 OTHER-SAL 免稅之補發款 SAL-SUBSIDY 核能加給 81.2.17 SAL-ACHELP (公)互助費 SAL-BCHELP (工)互助費 SAL-DEPSIT 公教儲蓄存款 SAL-ELEC 電 費 SAL-INDPD 法院扣款 84.11.21 SAL-RET-INO 退休撫恤金 84.6.20 SAL-INSURE 公 保 費 SAL-INW 勞 保 費 ． ．． ． ． ． ． ．． ． ． ． 圖 2 舊系統檔案結構示意圖場爭議。 3.3 配 合 其 他 系 統 在整合的校務資訊系統中 ，薪資系統屬於下 游端系統，常常需要擷取利用各項上游端系統提 供的資訊來檢核或產製自己的資料。例如：人事 系統提供的教職員工資料，及教務系統提供的學 生資料等，用來檢核個人身分狀況的正確性；事 務系統提供的水、電、瓦斯費等，用來轉入個人 薪資明細資料，作為代扣款項的依據。薪資系統 與其他系統之資料關聯，參考圖 3。 下游端系統能夠正 確 擷 取 上游端系統的資 料，全仰賴遵守上游端系統資料的規範，當上游 端系統資料結構有變化或來源處有異動時，下游 端系統必須連帶地一併修正，才能維持系統原本 正常的運作。像這類配合其他系統的提案需求總 是無法避免，也是無法拒絕的，尤其在各系統紛 紛轉型期間，與上游端系統的切換、銜接，總是 絡繹不絕。 資料在整合體系中，最怕遇到的事是上游端 業務單位遺忘與下游端業務單位的關係，常常總 是等到下游端業務單位在線上作業處理時，發現 異常訊息，才恍然獲知上游端業務有變動，此時 才緊急提出修改需求，這種迫切任務如履薄冰、 危如累卵，是非常難受的考驗。 3.4 報 表 內 容 調 整 報表的問題永遠是本系統中最難克服的部 分，無法永久固定格式，也不能用他法取代。 由於請款必定要有憑證以開立傳票，對於非 費用性之發放款，印領清冊成為標準之附件依據。 本校請款支付流程如圖 4，由流程得知，製表的單 位是出納組，也是本系統的需求提案者 ，但對所 提出的報表提案，往往沒有完全的決策權，常會 因為審查單位的人或事異動，而被迫要求修改報 表規格，難以配合的層面涉及太廣，長久以來一 直很難突破。 薪資管理系統 事務資料庫 契約工月薪 契約工考績 教職員宿舍資料庫 房租/管理費資料 房租補助費資料 教務資料庫 學籍資料 所系資料 其他代扣款資料 其他鐘點費資料 其他補助費資料 個人醫藥費資料 計畫年終獎金資料 旅遊補助費資料 計畫基本資料 年節獎金資料 人事資料庫 個人基本資料 個人現職資料 服務單位資料 個人離退資料 職稱代號資料 職稱歸屬資料 個人兼任資料 兼任職稱資料 個人等級資料 學務資料庫 齋舍基本資料 房間基本資料 住宿狀況資料 系統資料 外宿生資料 個人款項明細資料 個人薪等記錄資料 個人給薪來源記錄 個人扣繳稅率資料 個人年終獎金參考 個人考績晉級參考 個人參與計畫資料 個人薪資基本資料 薪資資料庫 計畫基本資料 款項代號資料 作業批號資料 給薪來源資料 計稅類別資料 計稅細則資料 薪資等級表 ．．．．． HARP HP3000 個人保險及健保資料 眷屬(公軍)健保資料 眷屬(勞)健保資料 個人考績資料 考核等第代號資料 個人未休假天數資料 個人休假補助費資料 人事資料庫 鐘點薪代號資料 教師鐘點明細資料 個人扣薪資料 個人退撫金資料 個人離職儲金資料 退撫金貸款資料 共用資料庫 交銀活儲帳號 學期代號資料 存摺摘要資料 水費資料 電費資料 瓦斯費資料 CCXP 每 日 轉 檔 獎助學金資料庫 獎助學金資料 工讀金資料庫 工讀金資料 事務資料庫 圖 3 薪資管 理系統關聯圖(93 年 9 月版)
3.5 其 他 早期的系統開發，並沒有全面思考完整的作 業程序應備的相關功能，當處理程序中臨時有一 環節出錯時，就只能直接對資料庫進行資料緊急 救援的處理。本人承接系統後，慢慢發現系統中 的瑕疵，自行利用空檔，逐一補足系統缺失的功 能，所以表 1 中之“資料處理”與“自提系統改 善”類別的次數出現左偏峰現象。
4. 資料庫 改革
鑑於昔日資料結構變更提案單的痛苦經驗， 及因應未來會不斷新增的需求量，以規畫具有高 彈性的資料庫為原則，儘量降低未來檔案結構會 變動的衝擊性，將原本的系統架構全面檢討改進， 以「個人薪資明細」檔案為例，結構變更為「個 人款項明細」，示意圖如圖 5。 新結構的設計觀念，繼前 3.1 節觀點所述，就 像是摒除傳統房屋預定幾房的建築模式 ，改用一 屋一房的活動屋，不用預先留置空房，當有房客 要進住時，隨時再加掛活動屋即可，而連結每一 活動屋的關鍵點就是所謂的索引鍵值。 舊架構中，以每一記錄代表每一個體每個月 所有的收支相關資料，以資料項目名稱的不同代 表每一種款項，對於搜尋資料時可馬上展開陳列 是其方便性，但卻有資料項目無法彈性 擴充的缺 失。 新架構中，以每一串記錄代表每一個體每個 作業批次點所有的收支相關資料，以每一資料項 目中的款項代號值，代表每一種性質的款項名稱， 所以每一個體之記錄串的記錄數目不盡相同。對 於搜尋資料時，必須連結款項代號的對 照表，才 能解釋出款項的意義，雖然有些不便，但在新系 統 SQL 資料庫中，這類事件是很容易解決的事。 自 90 年 8 月新系統上線改用新結構後，需要 變更資料結構的需求提案單已降至為零，這是改 革成功的實證。5. 作業規則表格化
以 3.2 節所言，對於所得稅扣繳，在新系統中 改善的作法是將作業規則表格化，將一些變動因 子改以資料表方式建立。 首先將薪資按性質與受薪人身分別分為幾大 計稅類別，如：教職員工薪資、助理薪資、契約 工薪資、學生薪資、各類鐘點費、年終獎金、各 類補助費等，建立成「計稅類別資料表」如下： 類別 類別名稱 免預扣最大所得額 免預扣最大稅額 個人款項明細 A001 09503 010 33390 Y 1 ．． B002 09503 010 50190 Y 1 ． A001 09503 020 21920 Y 1 B002 09503 020 44290 Y 1 ． ． B002 09503 030 8440 N A001 09503 A10 835 N ． ．薪資系統資料庫
PER_NO 人事編號 PROC_YM 作業批號 PROC_CODE 款項代號 PROC_AMT 款項金額 TAX_FLG 課稅別 SIGN_TYPE 收支別 ACT_DATE 維護日期 ACT_TIME 維護時間 ACT_USER 維護者 ． ．． ． ． ． 款項代號對照表 010 統一薪俸 ．． 020 學術、專業加給 030 主管加給 A10 公保費 ． 圖 5 新系統檔案結構示意圖 PROC_CODE 款項代號 PROC_DESCRIBE款項名稱 ACT_DATE 維護日期 ACT_TIME 維護時間 ACT_USER 維護者 請款單位 表冊 出納組 協助建檔 請款單位 建檔 出納組 轉入資料 出納組 印表 印領清冊 審查單位 審核簽証 會計室 開立傳票 出納組 支票 匯款轉帳 圖 4 請款支付流程1 教職薪資 33333 2000 2 助理薪資 33333 2000 3 學生薪資 99999 2000 4 年終獎金 33333 2000 5 各類鐘點費 33333 2000 然後依計稅類別分別建立其下特殊款項的扣 繳稅率，集合成「計稅細則資料表」如下： 計稅類別 款項代號 款項說明 扣繳率 1 011 統一薪俸補發 0.06 1 014 統一薪俸晉級差額 0.06 1 021 專業加給補發 0.06 1 024 專業加給晉級差額 0.06 另外依據稅捐處每月所得扣繳申報規定，建 立「扶養親屬扣繳稅額表」如下： 所得等級 0 人 1 人 2 人 3 人 4 人 5 人 ．． 66001~66500 4330 3520 2720 0 0 0 0 66501~67000 4390 3590 2790 0 0 0 0 67001~67500 4460 3650 2850 2050 0 0 0 並提供外國人士(例如：外僑、大陸人士)固定 扣繳稅率的輸入，建立「個人扣繳稅率資料表」 如下： 計稅類別 人事編號 姓名 扣繳率 2 B020 庫馬克 0.1 5 B261 馬西 0.1 1 E371 朱創新 0.2 對於免稅部分，以人員性質制定「免稅職別 與款項代號資料表」如下： 職別 款項代號 款項說明 教官 010 統一薪俸 教官 011 統一薪俸補發 教官 014 統一薪俸晉級差額 以所得性質，在「個人款項明細資料」中的 課稅別資料項目區分為免稅或課稅，如下： 學號 作業批號 款項代號 款項名稱 金額 課稅別 934301 09506 911 獎學金 15000 N 940101 09506 913 工讀金 2400 Y 最後應用系統中之『計算稅額』作業功能， 匯集當次作業批號點的所有收入，參考上列各項 資料表的規則設定，計算出應繳之稅額。演算法 則簡略摘要如下： ♦ 若「個人款項明細資料」符合免稅範圍 (「免 稅職別與款項代號資料表」)，更新課稅別資料 項目='N' ♦ 以作業批號取得個人計稅類別 A ♦ 讀取個人扶養親屬人數 ♦ 讀取「個人款項明細資料」，計算課稅別資料項 目=’Y’之總所得 B ♦ 檢查「個人扣繳稅率資料表」，有無符合計稅類 別 A： Ÿ 若有： 總稅額 = (總所得 B) x 個人扣繳稅率 Ÿ 若無： If (總所得 B) <= 免預扣最大所得額 then 總稅額 = 0 else 特定稅率所得 C = Sum( 「個人款項明細」符 合「計稅細 則資料表」計稅類 別 A 下所列款項代 號之所得額) 特定稅率所得稅 CT = Sum( 「個人款項明細」符 合「計稅細 則資料表」計 稅類 別 A 下所列款項代 號之所得額 * 「計稅細則資料表」 計 稅類別 A 下所列款項之扣繳稅率) 一般所得稅 DT = [(總所得 B) – (特定稅率所得 C)] 再對 照「扶養親屬人數扣繳稅額表」求得之 稅額 總稅額 = CT + DT If 總稅額 <= 免預扣最大稅額 then 總稅額 = 0 雖然要建立很多規則表格 ，初期工程不易， 但對於目前中央財政窘困，經常調整稅收藉以增 加財源的時代，這種可以由用戶隨時調整或新增 作業規則內容，而不用再修改程式的方法，無疑 是個很好的對應之策，對我們程式人員來說，不 僅減少維護工作，也免於承擔責任的風險。
6. 流程改善
6.1 資 料 源 建 立 View 屬於下游端的薪資系統，必須要遵循上游端 系統資料的規範，才能正確擷取利用各項上游端 的資訊。在轉型期間，由於各系統規格重新規劃， 仍在不斷研析修改中，資料定義尚未能明確訂立， 此時類似虛擬 Table 的 View 就扮演著很重要的角 色，它本身並沒有存放真正的資料，只是儲存實 際參考資料的定義，當系統對 View 讀取資料時， 透過 View 的定義解釋，才會抓取實際 Table 的資 料。 新薪資系統的開發，皆以 View 作為擷取管 道，不管實際資料是來自原本舊系統的資料，還 是已上線的新系統資料，或是數個 Table 資料項目 的結合體，只要修改調整 View 的定義，即可切換 源頭，配合其他系統的運作，而不需再對程式作 任何修正。 6.2 處 理 程 序 標 準 化在 3.5 節中曾提及往昔的系統開發並沒有全面 思考完整的作業程序，導致發生事變時 ，沒有應 變措施，只能直接對資料庫進行緊急處理。這樣 的處理模式，最怕的是資料庫處理不當後的追究 責任歸屬。 以圖 4 請款支付流程為例，標準的資料轉入 作業，應列示錯誤清單，對轉入的資料加以篩選 檢核，並解釋錯誤原因。對於資料轉入有誤，欲 重新再處理時，亦應提供資料復原相關程序。 另外對於類似的作業程序，儘可能變為共用 模組型態，以減少程式維護工程，例圖 6 左半部 為舊系統各種款項發放流程，由於每種款項的明 細資料檔案名稱與規格不同，從第一道建檔程序 至最後的銀行轉帳程序，均須量身訂作 ，不可被 他人再利用，但圖 6 右半部新系統的各種款項發 放流程，經由資料轉入作業程序，將各種款項變 成同一的檔案規格，使統一標準模組－銀行轉帳 程序，不用撰寫即可套用。今年恰逢本校駐校銀 行改組與他行合併，銀行轉帳規格變動 ，更彰顯 出新系統流程改善後的優異之處。 6.3 提 供 通 用 匯 入 匯 出 管 道 學校經常有很多臨時性的集體扣款或發放 款，想要依附在薪資下支出，例如颱風賑災捐款、 研究獎勵金等，由於性質單純，只是金額的收入 或支出差異，與款項名目的不同而已，為了業務 執行上的方便與彈性，於是提供了通用的匯入匯 出管道作業。委託單位只要能夠提供符合通用匯 入格式之資料，出納組即可依據轉入資料，處理 後續的款項轉帳程序。對於匯出管道，則是製訂 統一的簡易印領清冊格式，提供報表表頭名稱自 訂性，使性質相近的報表，可直接套用。 6.4 程 式 流 程 改 變 在應用系統與資料庫分散於不同主機的架構 中，網路傳輸速率與流暢度，變成影響系統好壞 的主要因素之一。 在程式撰寫中要有某些觀念的改變，例如讀 取資料，應避免像傳統方式一樣，將所要參考的 資料全部讀入應用程式中再處理，應該儘量在擷 取資料的 SQL 指令中，建立好參考資料間的關聯 性，並設定資料條件篩選範圍，使應用系統與資 料庫主機間的 I/O 次數與資料流量減少。同理，對 大量資料的異動，亦應善用 SQL 集體處理指令來 取代以前逐筆處理的方式。
