公司消费一卡通“变法”记
一卡通在每家公司都存在，不僅含考勤機，還會有門禁，訂餐，食堂消費等。我們公司采用的是廈門舒特科技的一卡通系統(tǒng)，前后用了好幾年了。
在我之前，一卡通的功能主要啟用了考勤和消費這兩大模塊。
1、考勤機是每個子公司都有相應設備，員工每天上下班刷卡，然后每個區(qū)域子公司的人事部考勤同事開始每周排隊，一人分一天下載考勤數(shù)據(jù)。如果所有人一起下載考勤數(shù)據(jù)的話，就會因為數(shù)據(jù)量巨大而導致網(wǎng)絡堵塞，說到底是公司的小型VPN太差。
2、消費數(shù)據(jù)是由IT維護人員負責，每個月不定時IT維護人員會去下載所有區(qū)域的消費機的脫機數(shù)據(jù)，在月初的時候在一卡通系統(tǒng)里導出所有公司所有員工的消費數(shù)據(jù)，差不多會有十幾萬筆，再在Excel里做成匯總表，然后把這些數(shù)據(jù)發(fā)到公司一卡通的QQ群里供人事部同事下載人工導入HR系統(tǒng)。而月初的“補貼”也是由IT維護人員必做的不能忘記的一項工作。
然后，就以上這么點工作，敢接的，能接的人不多，坑實在是太多了，能說道的事情也太多了。
我認為公司一卡通系統(tǒng)有幾個缺陷：
1、考勤數(shù)據(jù)都要由人事部輪流時間去人工下載再導入，而且經(jīng)常因為賬號卡死在里面而發(fā)生其他人沒辦法進去的情況。沒辦法實現(xiàn)自動下載和自動導入，增加了人工成本，IT 在其中的價值基本的不到體現(xiàn)；這其中主要的原因還是因為一卡通設備的問題。
2、消費機的數(shù)據(jù)整理全部都是IT來做，從管理上和安全要求來說，IT是不應該去直接接觸數(shù)據(jù)的。耗費太多的時間和精力去整理這些數(shù)據(jù)，做著毫無價值和意義的事情。
自從今年3月份開始接手以來到現(xiàn)在，我逐漸摸通了一卡通系統(tǒng)的很多門道。既然之前信息化部門的頭頭造了這么多孽，我自然不能沒有規(guī)劃，一直想方設法把IT做的事情分到人事部門去做。
但這過程中我需要解決是寫一個程序，讓人事部可以自己自由查詢消費數(shù)據(jù)，能夠在程序上導出來匯總表。然后我再寫一個可以自動發(fā)“補貼”的定時作業(yè)。
一、查詢程序
因為對后臺程序的數(shù)據(jù)庫結構了解不多，但我還是懂得了消費表是哪張表，以及其他相關人員，設備等表。
于是我把查詢消費表的功能寫成了一個存儲過程，通過傳入時間和區(qū)域參數(shù)來查詢消費記錄。
還有匯總表的計算，因為要很長時間，所以我把計算功能做成一個存儲過程，并用一張表存儲計算結果：
然后，通過C#快速開發(fā)出一個查詢程序出來，功能相對簡單，但通過在Sql Server上做一個版本控制的存儲過程，一旦我有修改程序，我就更新新的版本，之前的版本就自動失效，避免出現(xiàn)舊程序被使用的情況：
程序界面簡單，如下：
二、設定自動排程計算每月消費匯總表
由于做成了存儲過程，所以用排程去執(zhí)行它就可以了！
?
三、自動發(fā)放補貼
PS：說到“補貼”，我就想笑。其實只是員工工資預支600元而已。
但做到自動發(fā)放補貼這里就比較艱難了。
因為發(fā)放補貼是要排除掉離職和非公司的人員，而且一卡通系統(tǒng)并不是執(zhí)行標準的存儲過程，而是把sql語句寫到程序中了，所以根本不知道它是怎么執(zhí)行的哪些表。
雖然我知道更新哪張表哪個字段可以實現(xiàn)發(fā)放補貼，但這樣會有風險，因為我并不知道其中更多的邏輯。
打電話給舒特科技公司，告之說這個數(shù)據(jù)庫規(guī)格書是要錢的！（頓時心中一萬匹草泥馬奔騰過）
后打算用Sql Server Profiler連接后臺數(shù)據(jù)庫，哪知道提示說：
我不知道公司信息管理部領導當初購買一卡通系統(tǒng)的時候到底是想的什么，居然還在用這么原始的系統(tǒng)存在！！后臺數(shù)據(jù)庫用的是sql server 2000，實在無力吐槽了！
于是我只好安裝Sql Server 2008的Profiler工具，成功連接上系統(tǒng)，在里面做跟蹤，經(jīng)過大量的分析，總算知道了“發(fā)放補貼”這一邏輯：
里面使用大量的臨時表，諸如這類語句：
IF OBJECT_ID('tempdb..#Subsidy') IS NULL
?BEGIN
? SELECT A.Person_ID,Person_No,Person_Name,Card_No,Dept_No, Dept_Name,Subsidy_Fund,Subsidy_Fund[PriTime_Fund], Subsidy_Fund[Use_Fund],Subsidy_Fund[Fact_Fund],Person_Name[Type_Name], ? Birthday[Subsidy_Date],Person_No[Type_No],0[Data_Type],A.Person_ID[ID_KEY],Cast(0 as bit)[Is_OnlySubsidy]
? INTO #Subsidy
? FROM ST_Person A
? LEFT JOIN ST_Department C ON C.Dept_ID=A.Dept_ID
? LEFT JOIN ST_Card B ON B.Person_ID=A.Person_ID
? WHERE 1<>1
END
ELSE
? TRUNCATE TABLE #Subsidy
于是有了這些邏輯，接下來發(fā)放補貼的存儲過程就好辦多了：
此存儲過程沒有任何的參數(shù)傳入，也自動過濾掉了不能發(fā)放補貼的所有部門！
設定排程工作，限定在每個月的1號凌晨跑，從此一勞永逸解決了我手工發(fā)放補貼的艱難動作！
?
一卡通的事情耗費了我不少的時間。主要是沒有任何的數(shù)據(jù)庫規(guī)格書，而且對很多的技術根本沒法掌握得到。由此可以想到如果系統(tǒng)在立項和實施的時候，IT部門如果不介入或者專業(yè)度不夠，很多文檔如果沒有提供，那未來要維護起來是多么的可怕，就是專門給后人挖坑和造虐的！想想現(xiàn)在的加密系統(tǒng)，不就是一個大坑嗎？！
轉載于:https://www.cnblogs.com/saper/p/5625289.html
總結
以上是生活随笔為你收集整理的公司消费一卡通“变法”记的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： Java: String.split(.
- 下一篇： 设计模式之禅读书笔记