请假系统文档

2024-05-16

请假系统文档(精选12篇)

篇1:请假系统文档

泉州通政企业请假制度(TZ-2011-07-01)

为了加强我公司的经营管理,规范员工的请假制度,特规定如下:

1、请假种类和假期待遇

员工因故缺勤,必须请假。请假分:病假、事假、丧假、婚假、公假等。

A、病假:病假无薪,员工因病请假,需出示医院证明,应按正常请假手续办理申请。

B、事假:事假无薪且须提前申请。每次请假一般不得超过3天(含3天),特殊情况除外。如员工因事请假,工作安排好后,必须经部门主管批准。按请假程序办理,未经批准擅自离岗者,按旷工处理。旷工者一天扣罚3天工资。

C、临时假:上班时间一律不得请假外出(生病除外),如确属有要事须请假外出,须经过主管同意,并补写请假条。

D、丧假:在公司任职满一年的员工,倘若直系亲属去世,可以享有2天有薪(标准工资)丧假,直系亲属指:父母、配偶、子女。

E、公假:元旦、清明、五

一、端午、中秋节各放假1天,国庆节放假3天,春节放假7天。

假期待遇说明:每月请假超过3天(含3天)者,每超过一天除扣除当天工资外,同时扣一天的带薪假(即周日),超过两天则扣除当月全部带薪假(即请假4天扣5天工资,请假5天就扣除5天+所有周日的工资)。员工非因公负伤治疗休息,按事假处理。病假或春节放假期间经部门主管审核公司领导批准后,请假超过3天不予处罚,病假需提供县级医院以上的病历证明,公司对病历内容给予保密,对伪造病历证明的一经查实,将给予严厉处罚。

2、请假程序和办法

A、员工请假,需提前一天填写请假单,经部门经理审批后提交行政人事部。请假一天由部门经理审批,2天内由总经理助理审批,2天以上由总经理审批。

B、部门经理请假由总经理助理审批。

C、电力门市星期

六、日轮休,原则上不得连续2天以上(含2天),超过要请假,按请假制度处理。

D、电话或者他人代办请假一律不批,特殊情况除外。

本附则的解释权归泉州通政企业。本附则自2011年7月1日期作为通政企业管理制度的附件试运行。

泉州通政企业

2011-7-01

总经理:

篇2:请假系统文档

全体员工:

为了方便公司人员管理,做好考勤制度,现规定公司员工请假、调休都要提前到办公室领取请假条填写,并且由规定的各领导签字确认,然后在交回办公室留底,作为考勤的凭证。今后如果没有请假条或提前请假一律算旷工。

篇3:请假系统APP的开发及应用

1.1 任务框架

请假系统虽然不是大型系统, 但其任务框架五脏俱全, 而且涉及到服务器、客户端的信息交互, 多客户端的协作和配合。以浙江旅游职业学院为例, 学生请假, 需要班主任、辅导员、系支部书记、院领导等多级签字, 因此该系统由以下几部分组成[1]。

1.1.1 学生端。

根据需要可设以下几项功能:“填写假单”“显示记请假记录”“修改密码”“关闭退出”和“故障申报”等。在“填写假单”一页, 可根据需要设“假单类型”“请假原因”“起止日期”“起止节次”和“上传证明文件”等。而“上传文件”可以另起一页, 一般有“选择图片”“根据要求编辑图片”“上传”“取消返回”等。如何编辑压缩图片是开发难点。

1.1.2 审核端。

主要分设“显示未批准假单”“显示批准假单”“统计各班级请假情况”等。这3项功能点击后都会列表形式显示记录, 该列表的每一行数据都需要提供“审核”按钮, 点击审核按钮跳入新的一页或者弹出窗口, 之后选择“通过”“不通过”“删除该申请”等。

1.1.3 系统维护端。

一般会设有“增加班级”“增加新学生”“编辑学生信息”“文件夹维护”等。而增加班级时, 根据数据库的不同, 需要导入到系部数据库和班级数据库, 有时学生的信息变动时, 一般会涉及到修改班主任信息和班级名称信息等。

1.2 需要用到的开发平台

3个端、不同的功能模块都需要一一实现, 这个过程中需要用到不同的开发平台和工具。笔者采用了VS2005和Eclipse, 前者用于服务器端网页的设计和响应客户端代码的编写, 后者是Android版开发需要的。当然当前VS有更高的版本2015, 笔者习惯用2005这个版本, 读者可以根据自己需要选用。Eclipse虽然也有替代工具, 比如Android Studio (简称AS) , 但笔者也是因为最早习惯了Eclipse, 还没有使用AS。VS2015可以同时开发安卓和苹果版, 有兴趣可以试用一下。

1.3 数据库的建设

以上交互都需要有数据支撑, 因此学生的基础数据库如何建设。笔者采用了3个数据库:全系的数据库、分班级的数据库、请假记录数据库。全系的数据库是为了方便学生登录用的, 学生只需要输入学号和密码, 即可以登录到学生端中。如果分班级存放数据, 显然还需要选择班级, 这从服务角度来讲, 是不够便捷的。分班数据库是为了以后扩展系统功能预设的。请假记录数据库目前采用的是自动序列ID为关键索引的, 因为要考虑到不同的学生会有多次请假的情况, 因此不能用学号或姓名作为关键索引。在数据库建设过程, 遇到了比较现实的难题是, 技术员得到的数据往往是Excel格式的, 这可能与日常办公采用Excel做表格有关。单位提供给技术员的数据也不一定严格按照格式排列;还有如何把每一届的数据自动导入到数据库中 (当然如果直接采用Excel作为数据库也可以, 无须导入到Access) , 需要维护端开发一个专门的工具。笔者利用VS2005开发出维护端的单机版工具, 方便建设数据库, 远程上传批量的学生信息数据。请假记录数据库里可以根据需要, 包含如下内容:ID、姓名、学号、性别、电话、系部、班级、请假原因、请假类型、起止日期、一级Pass、二级Pass和三级Pass等, 一般还需要记录上传该数据的IP地址和时间。而证明文件的保存, 目前采取的是按照学年、班级建设文件夹, 证明文件存放在对应班级的目录下, 而证明文件的名称以学号加上传的时间为唯一识别名称, 并同时记录到请假记录数据库中。

1.4 网站的搭建

该系统是C/S (客户端/服务器) 的交互模式, 因此离不开网站的搭建, 可利用单位自己的服务器存放服务器端文件, 也可以根据需要搭建服务器。有些单位考虑到网站安全, 禁止学生上传自己的图片, 担心部分同学恶意上传带有病毒代码的图片, 这也限制了该系统的应用和推广。笔者目前采用自己搭建服务器, 租用了阿里巴巴 (之前的万网) 的空间。

1.5 不同类型的应用端

三方 (学生、审核、维护) 都通过向服务器发送数据和从服务器接收数据。这三方目前可以开发为不同类型的客户端, 即网页版、安卓版、苹果版、电脑单机版等。

首先, 网页版的开发。笔者采用了VS2005作为开发平台, 具体是采用了VB.NET, 文件是aspx格式, 其主要核心的编码是数据库的访问、增删等。其次, 苹果版的开发。开发苹果版有3种选择, 一是购买苹果电脑, 在MAC系统上利用XCODE开发苹果APP;二是在Windows操作系统上, 用QEMU加载苹果MAC的镜像iso, 虚拟一个苹果系统的环境;三是利用VS2015开发。但个人开发的苹果APP需要上传到苹果的store商店, 经过审核后才可以放在商店上供用户下载, 而且技术员要付款99美元。再次, Android版的开发。相对苹果的APP, 安卓APP几乎是免费的, 其无需购买专用的电脑, 其开发平台Eclipse或AS可以免费使用, 用平台开发的软件也是可以免费安装, 无需上传和审核, 也无需付费, 虽然从技术员的角度看, 有专利被侵犯的潜在可能, 但从应用角度来看, 无疑是方便的[2]。笔者目前主要开发的是安卓版和网页版。具体技术细节, 限于篇幅, 无法一一给出, 在开发过程中, 可能会涉及到xml文件的布局, 证明文件的上传、页面间如何带参数跳转和返回、登录页面与服务器的数据交互、本地图片的预览和选择、大量数据的上传、电话的拨打以及uses-permission权限的设定等这些问题。最后, Windows单机版。为方便维护和审核, 也可以考虑设计Windwos单机版, 如维护数据、与计算机上的数据库交互等。

2 应用实践中遇到的问题

目前很多工作都转移到手机上操作, 10.00~16.67cm大小的屏幕, 需要实现之前1 024×768像素电脑上的功能, 需要有一个良好的页面布局, 否则使用者将因为难用而放弃。从应用反馈来看, 主要遇到如下问题:1网页版要考虑到手机上左右手操作的习惯;2优先选择的功能要放在突出的位置;3平面设计问题, 使用Eclipse做xml界面设计时拖放比较麻烦, 为业界所诟病;4学生在使用时, 发现无法登陆, 这可能与数据导入时有遗漏有关;5学生的密码忘记, 维护方需要查询后发短信提供;6学生无法上传尺寸超过规定的照片, 但手机上又无法编辑大小时, 作为审核的老师, 还是需要学生提供纸质的证明, 当前很多APP需要认证身份时, 都需要申请人拍照上传, 这个过程中因相机像素比较大, 势必需要压缩图片;7误操作造成的删除需要, 学生有删除权限吗, 还是审核端有删除权限;8按照单位的统计需要, 还要把学生的旷课统计进去, 这似乎与请假系统无关, 但如果不能提供旷课统计, 似乎请假系统的应用效果也打了折扣。因此, 还需要增加一个专门供学习委员上传旷课学生数据的“学习委员端”。

3 结语

通过开发本系统, 不仅在技术上对一个完整的系统框架有了更清晰的认识, 也对学生的管理工作如何提供更加便捷的服务有了全新的体会, 同时也发现当前手机操作系统的不同给技术员带来了很多苦恼, 不仅要开发网页版, 还要根据客户需要开发安卓版、苹果版, 甚至Windows Mobile版, 当然网页版是最通用的, 任何操作端只要有浏览器都可以使用。但使用的体验和提供的服务功能可能不同。

今后将根据使用的反馈不断完善该系统, 在此基础上不断开发更多的服务系统, 让管理过程中遇到的各种困难和问题, 都能够借助技术的力量变得更加便捷、更加人性化。这样不仅可以提高管理效率, 也可以提高科技管理意识, 让使用的双方都能体验到公正高效的管理模式。

参考文献

[1]王兴晶.Visual Basic.NET数据库开发典型实例[M].北京:电子工业出版社, 2002:181.

篇4:请假系统文档

【关键词】信息化改革;简化步骤;一站式管理

一、我国民办高校请假系统中存在的缺陷

(一)制度上权职不清,请假流程混乱

权职不清。一部分学校将学生课程请假审批的权限交由任课教师,辅导员并不能第一时间掌握本专业学生的请假情况,而有的学校正相反,将权限直接下发给辅导员,任课教师根本不知道自己课上有多少学生请假,也不知道他们的具体请假时间、姓名和所在专业。因为教务课程平台与学生管理平台并没有实现资源共享,辅导员在网上可以查询学生请假情况并审批而任课教师依旧看不到。

学生请假流程的混乱。因为无法实现平台间的资源共享,学生在网上申请课程假之后还必须通过请假条或者其他方式将请假信息交于任课教师,否则即使在上网批准通过,其申请的假期依然不能核准,也就是说学生要申请两次,既在网上向辅导员或任课教师申请一次,然后再通过其他方式向另一方申请一次。这其中一旦有一个环节出错,不但学生无法正常请假,还会造成任课教师与专业辅导员之间工作上的冲突。

(二)缺乏专业人员参与管理

民办高校普遍缺少信息管理人才,即使拥有网络技术部门,所能处理的问题也只是停留在简单的技术层面,很多人员无法胜任信息管理工作。有的学校根据自身条件成立了以高级领导为核心的专门工作组,但是其中拥有专业知识的领导却是少之又少,这就使得一旦学生请假系统出现问题只能求助于校外方的帮助,若是问题处理不及时还会出现业务瘫痪。

(三)信息数据孤岛问题严重

在高校信息化建设中数据孤岛问题突出,不同部门间的数据信息不能共享,设计、管理、生产的数据不能进行交流,数据出现脱节。数据孤岛迫使信息需要重复多次的输入,大量的冗长、垃圾信息导致信息交流的一致性无法保证,从而降低了产品的工作效率,增加了错误量。现在由于请假流程中没有明确规定教学、社区公寓和学生管理之间相互联系的权责,在功能设置上自然也不会去特意实现请假信息数据共享,因此数据孤岛问题是请假流程混乱的必然结果。

二、请假系统的改进方法

若想针对请假系统中的现有缺陷进行改进必须从管理制度和系统功能两个方面入手。

(一)管理制度上的改进措施

管理制度方面的改进可分为两部分:

第一,认清权责,保证流程的准确性和时效性。通过制度一系列的规章制度,完善学校的请假制度,简化、优化原有的课程假和外出阶段假的流程。[1]具体流程优化方法如下:

1.课程假的优化。

学生申请课程假可登陆手机微信系统或学工系统自助请假。不再需要任课教师或辅导员审批,但申请课程假的时间和申请原因会被自动编辑为微信推送给该课程的任课教师和辅导员且每申请一节课程假会自动扣除该生本门课程相应的分数。若扣满全部平日成绩分数则本门课程不再有平日成绩且该生本门课程不可再申请请假。

2.外出阶段假的优化。

外出阶段假细化为一般阶段假和特殊阶段假两种。

学生申请一般阶段假,需要先通过手机微信平台或学工系统填写请假信息并提出申请。辅导员通过计算机终端或手机平台接收请假申请并进行审批。辅导员拥有的特定的给假权限,超过特定给假权限天数的申请,系统自动生成为辅导员与学院领导共同核准,既辅导员审批通过后,还需学院领导审批请假才可生效。

普通阶段假生效期间产生的课程一律按课程假计算。每节课扣除相应的平日成绩。

超过三天的普通阶段假系统会自动将请假信息推送给请假学生家长,方便家长监督。

特殊阶段假是指因为特殊重大疾病、家中发生变故、自然灾害或因为其他不可抗力而必须请假且不涉及休学的情况。特殊阶段假的申请和审批流程需要注意以下几点:

(1)申请特殊阶段假的学生同申请一般阶段假的学生相同,需要先通过手机微信平台或学工系统填写请假信息并提出申请。

(2)申请特殊阶段假的学生在进入微信平台或学工系统填写请假信息时要注意必须点选特殊阶段假选项才能够申请特殊阶段假。

(3)特殊阶段假请假原因模块不可随意填写,只能从备选的选项中点选。包括:重大疾病、家庭变故、自然灾害、其他四个选项。

(4)当申请结束后,请假信息会自动推送给辅导员,由其审批。

(5)特殊阶段假审批通过后,请假信息自动推送给任课教师和家长。

(6)若在请假中或事后返校提交材料时发现请假内容不实,辅导员可实时操作取消其特殊阶段假。

(7)学生返校后需到辅导员处销假。

第二,在权责清晰的前提下安排专人负责学生请假的管理工作。这里的专人指的是系统专业技术人员和管理人员两种。系统技术人员负责系统的开发、升级、测试工作。管理人员负责系统平日维护,功能操作和数据管理工作。两种专业人才可以重合,但不能有其他部门的人员兼职,以免造成权责混乱。

(二)系统功能上的改进措施

首先是实现移动端实时请假功能。在学生管理系统下建立一个微信公众平台并申请一个服务号,作为后台管理辅导员和教师的微信帐号,只要学生和家长只要关注教师的微信账号就使用本系统。[2]

在微信公众平台内建立子系统,子系统主要用于管理、发布和统计用户的相关信息以及请假信息。该子系统的具体功能如下:

1.用户管理。

主要是针对学生和家长,学生和家长要使用本系统必须先关注本系统的服务号。后台管理子系统根据学生和家长的信息进行配对和管理,一个学生最多配对两个家长,同时用于统计学生请假次数、理由和管理学生外出位置、路线等并生成图表以供教师和家长查询。

2.教师管理。

主要用于教师管理和监督学生的请假要求、监督学生的所在位置和外出路线、查询统计的学生请假的相关信息。

3.学生请假子系统。

系统主要用于学生的请假申请、到校销假功能。

4.家长监督系统。

主要用于家长对请假学生外出位置、路线的监督。学生到家后家长可通过系统确认学生到家以及查询学生请假历史记录等。

5.学生干部协助子系统。

主要用于教师指定的学生干部确认学生到校情况。

随着智能手机和通信网络的迅速发展,我们可以通过移动端和PC的联网避免学生乱请假、假请假、请假后缺少监管、外出没有跟踪定位、学校与家长沟通不足等情况的发生。[3]

其次是建立更加细致的分类请假功能。通过分析可发现高校在校生请假的主要类型一般可分为三种:

1、学生在家中因为某种原因需要请假,一般表现为推迟回校时间;

2、学生在校中因为某种原因需要请假外出,但是不回家,一般会当天回学校。

3、学生在校中因为某种原因需要请假回家。

我们根据请假类型可以设计出不同的流程方案并按照方案逐个实现相应的功能。

针对第一种类型可得出的系统设计流程方案是:

1、家长通过系统提交请假要求,并填写请假的理由以及开始和结束日期、时间。

2、辅导员通过手机平台或者学工系统平台收到请假申请信息,然后根据实际状况对申请进行核准。(辅导员权限只有7天,超过7天的假期不予批准。)

3、当辅导员核准结束后,任课老师、家长和学生都会收到一份信息推送。推送内容包括该生的请假开始和结束时间、请假理由。

4、学生回到学校后,经过宿舍门禁系统确认,才可以通过系统销假。

5、辅导员收到销假请求后并通过门禁系统确认请假学生是否在校,若在校则为学生销假。

6、系统自动将学生销假成功的信息发送给任课教师和家长。

针对第二种类型可得出的系统设计流程方案是:

1、学生通过系统提出请假要求,并填写请假的理由以及开始和结束日期、时间。

2、辅导员收到学生申请并作出核准。

3、任课老师和家长接收到请假请求推送(包括请假的理由和时间开始结束时间。)

4、学生回校时间结束前一小时收到信息提示,提醒学生回学校。

5、学生到学校后,经过宿舍门禁系统确认,才可以通过系统销假。

6、辅导员收到销假请求后并确认请假学生是否在校,若在校则为学生销假。

7、系统自动将学生销假成功的信息发送给任课教师和家长。

针对第三种类型可得出的系统设计流程方案是:

1、学生通过系统提出请假要求,并填写请假的理由以及开始和结束日期、时间。

2、辅导员收到学生申请并作出核准。(只能审核权限范围内的申请,若超过权限范围内的天数系统自动生成需两级审批状态,并将请假信息发送给院领导,由院领导和辅导员同时审批方可生效。)

3、审批通过后请假信息自动给任课老师和家长。

4、家长确定学生到家后通过系统确认学生已到家。并预报学生什么时候回校。

5、系统发送信息给辅导员告知学生已到家和学生回校时间。

6、学生返校后,经过宿舍门禁系统确认,才可以通过系统销假。

7、辅导员收到销假请求后并通过系统确认请假学生是否在校,若在校则为学生销假。

8、系统自动将学生销假成功的信息发送给任课教师和家长。

再次是建立跨平台、跨部门联网功能,防止信息孤岛。将学生请假系统中的信息与其他平台,既学生管理平台、教务系统平台、公寓管理平台和微信服务平台共享。让请假系统不再是某个系统下的次级功能而成为与其他平台拥有交互功能的平行系统。平台与平台之间可实现互相信息传送,实时数据更替。

参考文献:

[1]陈炜,王玮.学生事务与管理服务中的流程优化---以北京大学“三大典礼”的组织与服务为例[J]. 高校辅导员,2012,(12)

[2]王靖娜.Android的学生考勤管理系统设计与开发[J].现代电子技术,2014,(4)

篇5:请假系统文档

班主任签字:

家 长 签字:

备注: 此请假条由保卫处保管,学生返校时做好销假记录,学期结束

后交由政教处存档。

中果园小学年月日

中果园小学学生请假条

班学生因请假天,由其监护人带回家,特此证明,请保卫处予以放行。

班主任签字:

家 长 签字:

备注: 此请假条由保卫处保管,学生返校时做好销假记录,学期结束

后交由政教处存档。

篇6:请假系统文档

…….大学:

今有我部……(…证号:…..)同志欲与贵校…..班….同学结秦晋之好,将于……年…月…日请假回家进行结婚典礼,情况属实,特此证明,望准假。

单位名称

篇7:请假审批系统实现

用户类型有四个:学生,班主任,院长,学校

学生信息来字数据库tb_StudentInfo表 学生注册:

输入用户名和密码后登录系统

学生登录成功后看到以下界面

菜单栏

点击“填写请假单”

填写请假信息

提交请假申请

提交成功后给出提示

点击”已完成的申请”,查看已完成的申请

点击“审批中的申请”,查看正在申请的申请

点击”查看详情”

看到假条的详细信息

只要假条审批没有完全结束,申请者都是可以“撤销的“

点击“退回的申请”,看到被退回的

点击”个人资料”,可以修改个人资料

点击”修改密码”

点击右上方的“退出系统”,则退出系统

班主任登陆:

班主任看到的界面:

点击”带审批的申请”,看到学生提交的请假申请

“查看详情”

同意,拒绝请假申请 拒绝需填写理由:

点击“已审批的申请”

看到所有审批过得申请 班主任还可以进行学生信息管理,新增学生信息

小红星*代表必须填写

修改或删除改行的学生信息

删除前会有提示

个人资料和密码修改与前面的类似

院长登陆:

登陆成功后进入页面,看到的导航菜单

点击“待审批的申请” 看到的信息为:班长任已经审批过得申请

“查看详情”

已审批的申请

个人资料,修改密码与上面的类似

学校登陆:与院长登陆一样

数据库设计: 数据库名LeaveSystem 有四张表

tb_Leave

请假信息表,用于存放请假信息

tb_ProcessStatus 请假流程信息表,用来记录被退回的申请 tb_StudentInfo 学生信息表,存放学生信息

tb_UserInfo 用户信息表,用于班主任,院长,学校信息

tb_Leave

表中的字段

[Id] 字段编号

,[StuNo] 学号,[Dormitory] 宿舍,[LeaveReason] 请假原因,[Destination] 目的地

,[DestinationPhone] 目的地电话,[StartTime] 出发时间,[EndTime] 返校时间,[DayNumber] 天数,[PersonalPhone] ,[HomeTelephone]

个人联系电话 家庭联系电话

,[Created] 提交时间,[ProcessId] 请假单号

,[TecApproval] 班主任是否同意,[TecOpinions] 班主任意见,[DepartApproval] 院长,[DepartOpinions] 院长意见,[SchoolApproval] 学校,[SchoolOpinions] 学校意见 ,[IsRecall] 申请人是够撤销

tb_ ProcessStatus 表中的字段

[Id] 自动编号

,[ProcessId] 请假单号

,[ApprovalStatus] 审批状态,[Approves] 审批人,[Remark]

[Id] 自动编号

,[StuNo] 学号(登陆时的用户名),[Name] 姓名,[Department] ,[Profession] ,[Gender]

院系 专业 备注

tb_ StudentInfo 表中的字段

,[ClassName] 班级

性别

,[Phone] 电话,[Email] 邮箱

,[Passwrd] 登陆密码

tb_ User 表中的字段

[Id] 自动编号,[UserId] 用户Id ,[UserName] 姓名,[Passwrd] 密码,[RoleType] 用户类型,[Phone] 电话 ,[Email] 邮箱

Tb_User初始化数据

篇8:请假系统文档

随着企业社会生产方式的不断深化,工作的流程化也随之而来。但是现代企业的业务范围分布广泛,这样各部门之间为了统一和协调工作,需要大量的文档工作,降低了企业的工作效率,这时办公自动化的需求显得更加迫切。而工作流的产生为此类问题提供了一个解决平台。工作流就是业务过程的部分或整体在计算机应用环境下的自动化,主要解决的是在多个参与者之间按照某种预定的规则传递文档、信息或任务的过程自动进行,从而实现某个预期的业务目标[1,2]。系统结合单位的实际工作情况,应用工作流技术来实现无纸化请假,提供效率,降低成本。文章以学生请假审批系统的详细设计与实现为背景,介绍了工作流技术的实现方法。

1 系统需求分析

本系统主要是做一个基于工作流的软件案例实训系统。该软件案例实训系统主要有3部分需求:课程教学模块、项目案例教学模块、学生请假模块。通过课程教学模块,可以让用户查看到提供与教学计划相应的课程,还可以学习到与软件工程有关的知识与技能;在项目案例教学这个模块,主要由教师来负责项目案例教学器的运转,教师通过教学器可以自定义项目流程,发布项目案例等,用户登录该系统之后可以查看到其中的项目案例;在学生请假这个模块主要是方便用户请假,用户登录系统后,在网页上填写自己的请假单,就可以让上级看到请假人的申请,并对该申请做出相应的处理。该系统的实现主要是为了提高教学质量,同时也为学校的管理工作提供方便。鉴于篇幅,本文中只讨论请假审批子系统的设计与实现过程。

2 系统功能模块设计

请假审批,需要请假的人先在网页上填写请假单,该申请会按照流程定义自动转向上级审批;请假审批模块主要用于任课老师对学生添加的请假申请单进行同意或驳回,同意则转到系主任审批,驳回则直接结束;院长可以对系主任审批过的请假单再次进行审批,同意或驳回,同意则请假成功,否则请假失败,请假流程结束;而请假统计主要是系统自动按条件(时间或用户)统计用户的请假天数等,其系统功能模块图如图1所示。

3 数据库设计

关系数据库物理结构设计的任务包括:确定数据库文件的名称及其所含字段的名称、数据类型和宽度。确定各数据库文件所需建立的索引,在什么字段上建立索引等。

根据该系统所需实现的功能模块设计,系统所需要的数据库应该包括用户信息表、请假单信息表、菜单信息表、角色信息表。数据库主要用于保存和管理个人资料和信息数据。

用户信息表 包括用户的姓名、性别、登录名、登录密码、备注等基本信息,它的主键是用户ID,外键是上级ID和角色ID。

请假单信息表 该表是学生填写请假单时要填写的一些基本信息,包括请假单ID、用户ID、起始时间、终止时间、当前状态、请假类型、请假事由等信息。它的主键是请假单ID,外键是用户ID。

菜单信息表 该表主要记录菜单的名称,包括菜单ID、上级菜单ID、菜单名称、URL和描述等信息。它的主键是菜单ID,外键是上级菜单ID。

角色信息表 该表主要记录每个角色的名称以及分配的相应的角色。

4 系统功能的具体实现

4.1 工作流的流程设计与实现

4.1.1 流程定义

Windows Workflow Foundation支持基本的工作流模式:顺序工作流(Sequential)、状态机工作流(State Machine)、数据岛工作流(Data-Driven)。这里主要介绍顺序工作流和状态机的工作流。

顺序工作流提供了一系列有组织的步骤,一般情况下,步骤是逐一执行的。可能有的步骤需要等待某些时间的发生才可以继续执行,但通常情况下顺序工作流一般用于无需人工干预的操作。而状态机工作流提供了一系列的状态,工作流从初始状态开始,到终止状态结束。2个状态之间定义行为进行过渡。通常情况下,状态机工作流对事件做出反应,事件的发生将会使状态发生改变[3]。

状态机工作流的好处在于它可以定义状态,定义工作流如何从一个状态到另外一个状态。当外面的事件发生时,状态机的工作流可以移到不同的状态。外部行为可以是宿主程序引发工作流的内部事件,也可以是宿主程序编程实现的下一个状态,也可以利用SetState Activity移动到下一个状态,该工作流适用于该请假系统[4]。

学生请假流程是学生提交申请请假表单信息(请假类型、事由、请假时间等)。如果请假在3天之内,只需要任课教师审批,如果请假天数在3天以上5天之内,则需任课老师和系主任审批;如果请假天数在5天以上,则需要任课老师、系主任、院长都审批。这个请假流程有些过程需要暂时中止,并等待其他过程的开始,需要与人交互来完成,所以是状态机的工作流。

4.1.2 流程的启动

流程定义完成后,在系统启动(网站第一次被访问)时自动启动工作流并加载持久化到数据库中的工作流实例,主要代码如下:

//加载持久化服务

SqlWorkflowPersistenceService sqlWorkflowPersistenceService = new SqlWorkflowPersistenceService(XGD.QingJia.Entity.DBAccess.ConnectiongString);

workflowRuntime.AddService(sqlWorkflowPersistenceService);

workflowRuntime.StartRuntime();

//加载持久化的工作流

foreach(SqlPersistenceWorkflowInstanceDescription desc in workflowRuntime.GetService<SqlWorkflowPersistenceService>().GetAllWorkflows())

{ workflowRuntime.GetWorkflow(desc.WorkflowInstanceId);}

4.2 流程运行的设计与实现

本部分主要提供定制好的工作流业务过程的运行环境,对于系统的最终环境来说不可见,其主要包括实例化及执行过程模型、与外部资源交互、维护运行环境内部各种数据信息、协调各种检查数据和恢复重启数据等[5,6]。

该系统的运行流程图如图2所示。

4.3 请假审批模块的实现

该模块主要完成请假管理:

(1) 学生进行请假,首先进行请假表单的填写,然后根据请假的天数等待上级进行审批。即开始一个工作流实例,根据输入的条件在流程中运行,其代码如下[7]:

public static Guid 开始一个请假流程(XGD.QingJia.Entity.请假单 qjData)

{

Dictionary<string, object> inputParameters = new Dictionary<string, object>();

inputParameters.Add("QjData", qjData);

WorkflowInstance instance

= WorkFlowMgr.CurrentWorkflowRuntime.CreateWorkflow(typeof(XGD.QingJia.Wor

Flow.QingJiaWorkFlow), inputParameters);

instance.Start();

return instance.InstanceId;

}

(2) 任课老师或系主任可以对具体的请假单做“同意”或“拒绝”操作,当任课老师同意后,如果请假在3~5天内,还需要系主任审批,否则请假单流程完成,请假完成;任课老师拒绝则结束请假流程实例,请假失败。系主任对具体的请假单做“同意”或“拒绝”操作同理。其关键代码如下:

protected override ActivityExecutionStatus Execute(ActivityExecutionContext executionContext)

{

XGD.QingJia.Entity.请假单 qjd = XGD.QingJia.BLL.请假单Service.Get请假单By请假单ID(this.WorkflowInstanceId);

if (qjd == null)

{throw new Exception("流程数据尚未创建,请先添加InitialActivity初始化数据。");}

qjd.结果 = 同意或拒绝;

XGD.QingJia.BLL.请假单Service.Update请假单(qjd);

return ActivityExecutionStatus.Closed;

}

(3) 当请假单被审批完成后,一个流程实例自动结束,在结束的时候,系统会自动更新数据库中的请假结果。

其代码如下:

{

XGD.QingJia.DataExChangeService.QingJiaEventArgs args = (XGD.QingJia.DataExChangeService.QingJiaEventArgs)e;

QjData.结果 = args.QjData.结果;

}

5 结 语

工作流技术是计算机应用领域的一个新的研究热点,对工作流技术进行深入研究,对于提高我国企业的信息化程度、运行效率以及竞争力都有着重要的意义。本文以请假审批系统的开发为背景,探讨了基于工作流的软件设计和实现过程。本系统的研发是一次有益的尝试,为企事业推广基于工作流的请假系统提供了一定的参考依据,并对提高企事业信息化带来积极的意义。

摘要:现代企业的业务分配范围很广泛,各部门之间的统一和协调工作需要大量文档,企业工作效率降低。工作流的产生,为此类问题提供了解决的平台。在此提出了基于工作流技术的请假审批方法,讨论了基于工作流的请假审批系统的设计过程,包括需求分析、系统功能模块设计以及工作流引擎的设计。在开发过程中用Work flow作为工作流引擎,SQLServer 2005作为后台数据库,系统开发环境选用Visual Studio 2008。

关键词:请假审批,系统设计,工作流引擎,SQL Server 2005

参考文献

[1]闫炜,马柯,杨照.基于工作流技术的办公自动化系统设计与实现[J].西安工程大学学报,2009,23(3):104-107.

[2]李涛,朱一凡.基于.Net的工作流管理系统设计[J].计算机工程与设计,2005,26(10):2798-2801.

[3]龚红萍.基于WF工作流的Asp.Net程序设计[J].软件导刊,2009,8(10):17-19.

[4]王志晓,吕林涛,闫文耀.基于Asp.Net技术和工作流模型的网上审批系统[J].计算机工程,2004,30(17):83-85.

[5]杨利国.基于WF工作流技术研究及应用[J].武汉理工大学学报,2008(4):19-28.

[6]牛玉军.基于Web的工作流管理系统的研究[D].大庆:大庆石油学院,2005.

篇9:文档管理系统入门

文档管理系统可以将制作的文档转换成电子格式,并加以组织管理,让需要这些文档的人更容易获取它们,从而减少文档数量。虽然早期文档管理系统被认为是只有大企业才享用得了的“奢侈品”,但如今有所降低的软硬件价格让几乎所有企业都能够获得文档管理系统的好处。

实际上,文档管理系统是由许多不同部分组成的网络;虽然起初看起来可能很复杂,但实际用起来其实很容易。

数据分两种类型:结构化数据(如数据库信息)和非结构化数据(如纸质文档)。文档管理系统让企业能够安全地捕获、转送、存储、管理和归档非结构化数据。虽然纸质文档是一种最常见的非结构化数据,但文档管理系统还可以存储和组织各种电子内容,如微软Office文件、传真、照片、音频、视频、PDF文档和网上内容。

文档管理系统可以进而让企业能够管理非结构化数据:把非结构化数据存储在单一存储库中,并按照“关键号”(如客户号码或员工ID)把这类数据联系起来。这对制作大量文档的企业来说特别重要,比如律师事务所或房地产公司。然后,只有授权用户直接通过文档管理系统,或通过企业的一个或多个应用软件,才可以访问文档。

文档管理系统不仅有助于安全地管理文件,还可以大幅降低运营成本,提高纸张文档和电子内容管理的效率。

由于以下诸多好处,文档管理系统还让企业能够迅速获得投资回报:

·降低了存储和检索纸质文档和电子内容方面的成本。

·减小了物理和数字存储空间。

·提高了整个企业的运营效率。

·增强了电子内容和纸质文档的安全性。

·增强了万一遇到灾难时的业务连续性(BC)能力。

·改进了法规遵从。

下面是文档管理系统的最基本的组成部分,通常通过企业的数据网络联系起来。请记住:仅仅根据纸质文档生成数字文件还不够;支持文档的存储、组织、安全、访问和及时处置也必不可少:

1、文档扫描仪是将纸质文件转换成数字格式的入口点,可以借助独立扫描仪、数字发送扫描仪或多功能打印机(MFP)来完成这种转换工作。市面上有大小、形状和速度不一的扫描仪,甚至还有专门针对特定应用环境(如支票处理)的扫描仪,所以与供应商一起确保:你选择的扫描方案最合适自己的需要。

2、文档捕获和索引软件与你的扫描和计算机系统协同运行,以简化捕获过程,并且确保存储的文档可以轻松找到。主要有三种捕获方式可供考虑:

设备捕获(Device Capture)要求用户在扫描文档期间对文档进行分类和命名,并且在企业内部执行文件命名标准,以此简化管理过程。

Zonal光学字符识别(OCR)让用户能够为他们最常用的表格和发票创建模板。通过简化数据的存储位置,ZonalOCR能够自动提取数据,识别文件,并将该信息发送到文档管理系统,从而减少手动工作量和错误。然后,用户可以搜索自己所需的具体文档,确信系统会返回正确的信息。

分布式捕获(Distributed Capture)把扫描和捕获设备放在纸张和数据进入企业的不同点。通过使用廉价的台式扫描仪、网络连接扫描仪和多功能打印机将文档馈送到系统文件,你就可以最大限度地提高投资回报,并且实现“无纸”办公环境。

3、文档管理软件又叫作企业内容管理软件,它是任何文档管理解决方案的核心部分。通过该软件,你就能减少电子文档的重复,实现高效检索,管理对系统中所存储的任何文档或内容的安全访问,从而确保只有授权用户才可以访问任何文件。由于每个文档都进行了存储和索引,现在对用户来说,企业的数据触手可及。此外,可以从企业内外安全地访问这些数据——为远程办公或经常去别的地方出差的那些人提供了灵活性。

4、当然,数据存储设备是存放文档的地方。贵企业的存储策略应该取决于贵企业的规模和性质;由于如今有众多存储系统可以使用,应该与供应商一起选择最适合自己需要的存储系统。另外别忘了备份系统,保护贵企业远离灾难性故障或主存储系统丢失。

你在为文档管理系统的这每一个组成部分考虑选择方案时。要注意适合、整合和兼容性等问题。购买的软件在硬件上可以很顺畅地运行吗?是否有专门的软件或硬件可能特别适合贵企业的特定业务?贵企业采用的索引策略在今后几年会不会很好地满足贵企业的需要,还是很快就跟不上贵企业的发展势态?在投入成本之前,务必要确信整个系统能够很好地协同运行。

篇10:OA系统数据整合:请假管理

OA行业发展至今,已经远远超过了传统意义上的“无纸化办公”,或“办公自动化”等老概念所描述的应用。新兴的OA系统在智能性、整合性应用上已经取得了突破性的进展,这时行业已经找到一个更贴切的词语来替代OA,那就是“协同”。

(中国软件网讯)OA行业发展至今,已经远远超过了传统意义上的“无纸化办公”,或“办公自动化”等老概念所描述的应用。新兴的OA系统在智能性、整合性应用上已经取得了突破性的进展,这时行业已经找到一个更贴切的词语来替代OA,那就是“协同”。

关于“协同”,具体来说包括四大类:人员的协同、流程的协同、数据的协同、资源的协同,构成了企业完整的经营管理活动。其中数据的协同是当前OA系统的应用重点,也就是华天动力最新提出的工作流2.0,其含义是:不但要实现OA系统内部的数据整合,又实现OA系统和其他业务系统之间的数据整合,消除信息孤岛,减少重复工作。

说到OA系统的数据整合,其实这些年来厂商和用户一直在热烈探讨,却缺乏实践案例。为了填补这个空白,最近华天动力发布了一系列数据整合方面的案例,包括借款与报销、预算与费用等,这次我们看到的是一个关于请假管理方面的数据整合应用。

简单的请假管理流程,为什么还要进行数据整合呢?在华天动力OA办公系统中,请假单可以直接关联请假人的请假历史。无论这个请假记录是保存在OA系统中,还是HR系统中,都可以自动提取过来,为审批人提供决策依据,一项小的改进可以大大提升工作的便利性。

如下图一所示,是大连富强企业集团在华天动力OA系统中使用的“病假请假申请单”,申请人在填写这个表单的时候,能够直接看到自己一年内的请假历史。这些数据来自于OA系统内部,是对以往审批完成的请假单的汇总,根据这个请假历史,申请人就可以更合理的安排自己的假期。

南京苏欣三采软件科技有限公司

Tel: 025-66915810

Fax: 025-83676150 E-mail:suxinsancai@163.com Http:

地址:南京建邺区新安江街80号西堤国际西堤坊6-602

图一:OA系统内部请假数据关联

而如下图二所示,这是上海利众集团在华天动力OA系统中使用的“员工请假申请单”,这张表单主要用于由申请人给自己的下属提交请假申请。申请人在填写申请单时,只要输入员工的工号,系统就会自动从HR系统中提取该员工的姓名、部门、职务,同时该员工的所有请假记录也被提取过来,一目了然,为申请人和审批人提供了准确的参考。

图二:OA系统外部请假数据关联

显然,OA系统自动从系统内、外提取请假记录,直接显示在申请单上,对审批人来说是非常有用的。比如人事部经理在审批一个请假单的时候,发现某员工近期频繁的请病假,那么到底是该员工真的生病了,还是另有原因呢?他可以找来该员工的主管了解情况,如果真的是生病了,就建议员工好好检查一下;如果是另有原因,就调查一下到底是怎么回事,以便及时解决问题,防止突发事件。

可以想象,如果申请单上没有员工的请假历史记录,那么审批人就要完全靠自己的脑袋去记忆了,想起来了还好,想不起来可能就做出了错误的审批,掩盖了问题。当一个公司有几百、几千、甚至几万人的时候,再好的脑袋恐怕也靠不住了。

可见,OA系统的数据整合并非石破天惊的应用,而是解决了企业中点点滴滴的实际问题。这种应用就像水泥一样,用来抹平、粘合石头和砖块之间的缝隙,让大厦更加牢固,让企业更加健康。

南京苏欣三采软件科技有限公司

Tel: 025-66915810

Fax: 025-83676150 E-mail:suxinsancai@163.com Http:

篇11:请假系统文档

信息时代信息安全保护的最常用的手段就是数据加密技术。传统方式下的加解密的系统和程序是运行在操作系统用户态,在这种方式下,每次访问文件都要手动进行加解密工作,很可能会因为用户的误操作引起机密数据的泄漏。同时,又必须要求正常用户使用程序时,程序是以明文形式存放在磁盘上的,基于这种需求,要在操作系统的内核态对数据进行透明加解密[1]处理。

透明加解密:是指在对电子文档进行保护的过程中,是一种相对用户终端透明的文档加密技术,用户几乎感觉不到加解密过程的存在。在实际应用中,它具有两个层面的意思:

(1)强制加解密,只要定义了保护范围,加解密过程不用用户参与判断是否需要加解密。

(2)在用户使用过程中,与正常使用过程没有区别。所以说,加解密过程透明。

加解密文件系统(如微软的NTFS中的EFS[2],Encryption File System)的数据处理要安排在文件系统的驱动层,文件系统能够以文件或目录的形式访问文件。文件系统能够对加密范围进行灵活控制,但是系统的设计与实现比较复杂。

2 工作原理和框架结构

应用程序对磁盘上文件的操作是由Win32子系统调用相应进程进行操作。首先到达I/O管理器,I/O管理器接受到相应的请求后,首先检查所访问数据是否在高速Cache中,若是在高速Cache中,则I/O子系统构造FastI/O直接从缓存中进行数据存取工作;若不在缓存中,则需要构造IRP[3,4](I/O Request Package),然后再发往文件系统驱动,并把本次访问的数据加入高速Cache中。所以,文件系统[5]过滤驱动程序是通过两组操作请求接口处理应用程序的请求:一组是Fast I/O调用函数Fast Dispatch,另一组是普通的IRP的分发函数Dispatch。然后构造输入输出请求包IRP进行该请求的描述,顺次向下传递,先到达文件系统驱动,经由存储设备驱动、底层驱动处理完毕。顺次把结果向上返回,经由I/O管理器、Win32子系统把结果返回给发出请求的应用程序,至此,对文件的操作请求执行完毕。文件系统响应I/O请求的控制流程如图1所示。

Windows NT的I/O管理器是可扩展结构,支持分层驱动模型,所以,可以在I/O管理器与文件驱动之前,或者文件系统与磁盘驱动之间插入按照需求开发的某种功能驱动。

Windows NT内核操作系统的驱动模型采用分层结构,如图2所示。为了便于分层管理创建了设备对象(FDO,FiDO)、驱动程序对象等数据结构。驱动程序根据自己的需要能够创建多个设备对象,对相应的I/O请求进行处理时,采用从相应设备栈的顶部向下传递的方式,在每一层通过调用相应设备关联的驱动程序处理相应请求。分层驱动程序模型中的匿名设备对象FiDO(过滤设备对象)是有驱动程序构建,并允许它附着在另一个设备对象上。这样,I/O管理器在传递IRP时,先检查是否有附着的匿名设备对象;如果有,就先传递IRP给相应的匿名设备对象,经过过滤驱动程序处理再发给真正的目标设备对象。因此,过滤驱动程序可以设置在文件系统设备对象的上面。这样就能优先获得I/O的IRP请求,能够起到对原始请求进行预处理、修改等作用,从而达到最终目的。

Windows NT内核的操作系统(Windows 2000、Windows XP、Windows 2003)的驱动模型WDM(Windows prive model)具有层次化的结构。

在这种结构中,每一层的驱动依次处理I/O请求包(IRP I/O Request package),过滤驱动的原理是通过插入过滤驱动层截获上层驱动发往下层驱动的IRP,对驱动之间传输的数据进行相应的操作。

3 关键技术

3.1 数据加解密

3.1.1 加密算法的选择

在进行加密算法选择时,根据自己的使用特点来确定。一般在进行大量数据加密时,为了提高加密速度,采用对称加密算法。在进行文件读写时,数据被分成很多块,文件系统会产生很多个IRP_MJ_READ请求或者IRP_MJ_WRITE请求,如果采用分组算法必须考虑分组对齐问题。因为Windows读文件时不一定是按顺序的。对于文件的长度在加密时要考虑是否是文件的最后一页,决定了写成功的长度IoStatus.Information是否等于请求的长度。若是,通常情况下会小于请求长度Write.Length;在进行解密时在不需要考虑这个问题。

3.1.2 在文件系统过滤驱动的IRP_MJ_WRITE分派函数进行加密

流程如下:

(1)判断IRP的读写方式,只处理以下几种IRP_NO-CACHE、IRP_PAGING_IO、IRP_SYNCHRONOUS_PAGING_IO。

(2)根据文件路径和类型决定是否需要进行加密,不需要则直接把IRP往下层传,否则执行加密过程。

(3)得到Windows传下来的数据缓冲地址,在内核中分配连续页作为新的缓冲区用来保存数据。

(4)用3DES加密算法对新的缓冲区中的数据加密。

(5)设置完成例程,将IRP原来的参数作为完成函数的上下文环境变量。

(6)调用IoCallDriver把密文向下层驱动传,写入硬盘。

(7)在完成例程中设置IRP的MdlAddress及UserBuffer;返回成功。

数据解密过程与此相同。

3.2 数据读操作

数据读操作的IRP类型为IRP_MJ_READ.IRP_MJ_READ的分发例程处理步骤如下所述:

其中IsMyFlags()用于判断IRP->Flags是否为高速缓存中的IRP请求。Get Address From MDL()函数返回MDL结构在缓冲区的内存地址。

3.3 数据写操作

数据写操作的IRP类型为IRP_MJ_WRITE.IRP_MJ_WR-ITE分发例程的处理步骤如下所述:

同数据读操作时一样,Is MyFlags()用于判断IRP->Flags是否为高速缓存中的IRP请求。对数据的加密实现是通过分配新的数据缓冲区,对新分配的数据的内存中的数据加密来实现的。从而避免了进行在加密时同时有数据访问导师数据不一致产生错误。最后要恢复irp->MdlAddress的值避免上层组件访问产生错误。

3.4 特殊类型文件的处理

Microsoft Word操作的文件(后缀名为doc)无法使用上文所述方法进行处理(也即通过在IRP-MJ-READ时解密IRP-MJ-WRITE时加密)。Microsoft Word为了保证文件可靠性,在打开文件后自动生成.tmp临时文件。在该文档关闭前把对文件的全部修改保持到此文件中。因此IRP-MJ–WRITE能接收到的是后缀名为.tmp的文件,影响对文件进行加密处理;通过对截获到的文件进行重命名操作来解决此类问题。

4 结语

实现数据安全存储是在实施数据存取的同时实现的,即实现了透明加解密的处理。该方法是基于文件系统过滤驱动技术,能够运用于基于NT技术的所有操作系统,包括:Windows 2000、Windows XP等。实现了FAT32、NTFS、CDFS等格式文件的加解密处理。

参考文献

[1]FARID H.Detecting Hidden Messages Using Higher-OrderStatistical Models[C].IEEE International Conference on Im-ages Processing.Rochester,New York,USA,September 22-25,2002:905-908.

[2]Wright C P,Dave J,Zadok E.Cryptographic file system sper-formance:what you don’t know can hurt you[A].Securityin Storage Work shop,2003.SISW’03[C].Proceedings ofthe Second IEEE International 31231 Oct.2003.

[3]Oney Walter.Programming the Microsoft window s driver mod-el[M].Redmond,Wash.:Microsoft Press,2003.

[4]Mark E Russinovich,David A Solomon.Microsoft windows in-ternals fourth edition[M].RedmondWash:Microsoft Press,2005.

[5]武安河.Windows 2000/XP WDM设备驱动程序开发[M].第2版.北京:电子工业出版社,2005:35-60.

[6]驱动程序开发网技术社区.文件系统(过滤)驱动程序开发[DB/OL].http://bbs.driverdevelop.com/thread.php?fid-39.html,2008,3.

篇12:让系统默认搜索支持PDF文档

Foxit PDF IFilter是Foxit pdf工作室推出的一款搜索插件,用户并不需要使用Foxit pdf阅读器即可使用该插件。下载并安装Foxit PDF IFilter以后,在控制面板中找到“索引选项”一项(若用户的控制面板中无法找到此项,可以选择界面上方的“查看方式/小图标”显示全部选项)。接下来点击“修改”按钮(如图1),选择自己存放PDF文档所在的分区,确认之后关闭“索引位置”对话框。

如果用户没有固定存放PDF文档的分区,可以忽略此步,但由于系统为所有的磁盘分区建立索引需要耗费太长的时间,因此建议大家将自己的PDF文档都保存在同一个分区下。

再返回“索引选项”对话框,依次打开“高级/高级选项”对话框,并切换到“文件类型”选项卡,找到“pdf”扩展名的项目,将该项目设置为“为属性和文件内容添加索引”(如图2)。

设置完成后关闭“索引选项”,当用户在该分区下的Windows窗口的搜索框中以某个关键词执行搜索操作时,很快就可以搜索到内容符合搜索条件的PDF文档了。

上一篇:2017年江苏省人力资源服务从业人员资格考核复习资料下一篇:安监局2021年依法行政工作总结