一卡通在每家公司都存在，不仅含考勤机，还会有门禁，订餐，食堂消费等。我们公司采用的是厦门舒特科技的一卡通系统，前后用了好几年了。

在我之前，一卡通的功能主要启用了考勤和消费这两大模块。

1、考勤机是每个子公司都有相应设备，员工每天上下班刷卡，然后每个区域子公司的人事部考勤同事开始每周排队，一人分一天下载考勤数据。如果所有人一起下载考勤数据的话，就会因为数据量巨大而导致网络堵塞，说到底是公司的小型VPN太差。

2、消费数据是由IT维护人员负责，每个月不定时IT维护人员会去下载所有区域的消费机的脱机数据，在月初的时候在一卡通系统里导出所有公司所有员工的消费数据，差不多会有十几万笔，再在Excel里做成汇总表，然后把这些数据发到公司一卡通的QQ群里供人事部同事下载人工导入HR系统。而月初的“补贴”也是由IT维护人员必做的不能忘记的一项工作。

然后，就以上这么点工作，敢接的，能接的人不多，坑实在是太多了，能说道的事情也太多了。

我认为公司一卡通系统有几个缺陷：

1、考勤数据都要由人事部轮流时间去人工下载再导入，而且经常因为账号卡死在里面而发生其他人没办法进去的情况。没办法实现自动下载和自动导入，增加了人工成本，IT 在其中的价值基本的不到体现；这其中主要的原因还是因为一卡通设备的问题。

2、消费机的数据整理全部都是IT来做，从管理上和安全要求来说，IT是不应该去直接接触数据的。耗费太多的时间和精力去整理这些数据，做着毫无价值和意义的事情。

自从今年3月份开始接手以来到现在，我逐渐摸通了一卡通系统的很多门道。既然之前信息化部门的头头造了这么多孽，我自然不能没有规划，一直想方设法把IT做的事情分到人事部门去做。

但这过程中我需要解决是写一个程序，让人事部可以自己自由查询消费数据，能够在程序上导出来汇总表。然后我再写一个可以自动发“补贴”的定时作业。

一、查询程序

因为对后台程序的数据库结构了解不多，但我还是懂得了消费表是哪张表，以及其他相关人员，设备等表。

于是我把查询消费表的功能写成了一个存储过程，通过传入时间和区域参数来查询消费记录。

还有汇总表的计算，因为要很长时间，所以我把计算功能做成一个存储过程，并用一张表存储计算结果：

然后，通过C#快速开发出一个查询程序出来，功能相对简单，但通过在Sql Server上做一个版本控制的存储过程，一旦我有修改程序，我就更新新的版本，之前的版本就自动失效，避免出现旧程序被使用的情况：

程序界面简单，如下：

二、设定自动排程计算每月消费汇总表

由于做成了存储过程，所以用排程去执行它就可以了！

三、自动发放补贴

PS：说到“补贴”，我就想笑。其实只是员工工资预支600元而已。

但做到自动发放补贴这里就比较艰难了。

因为发放补贴是要排除掉离职和非公司的人员，而且一卡通系统并不是执行标准的存储过程，而是把sql语句写到程序中了，所以根本不知道它是怎么执行的哪些表。

虽然我知道更新哪张表哪个字段可以实现发放补贴，但这样会有风险，因为我并不知道其中更多的逻辑。

打电话给舒特科技公司，告之说这个数据库规格书是要钱的！（顿时心中一万匹草泥马奔腾过）

后打算用Sql Server Profiler连接后台数据库，哪知道提示说：

我不知道公司信息管理部领导当初购买一卡通系统的时候到底是想的什么，居然还在用这么原始的系统存在！！后台数据库用的是sql server 2000，实在无力吐槽了！

于是我只好安装Sql Server 2008的Profiler工具，成功连接上系统，在里面做跟踪，经过大量的分析，总算知道了“发放补贴”这一逻辑：

里面使用大量的临时表，诸如这类语句：

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

于是有了这些逻辑，接下来发放补贴的存储过程就好办多了：

此存储过程没有任何的参数传入，也自动过滤掉了不能发放补贴的所有部门！

设定排程工作，限定在每个月的1号凌晨跑，从此一劳永逸解决了我手工发放补贴的艰难动作！

一卡通的事情耗费了我不少的时间。主要是没有任何的数据库规格书，而且对很多的技术根本没法掌握得到。由此可以想到如果系统在立项和实施的时候，IT部门如果不介入或者专业度不够，很多文档如果没有提供，那未来要维护起来是多么的可怕，就是专门给后人挖坑和造虐的！想想现在的加密系统，不就是一个大坑吗？！