公文管理系统分析与设计报告.docx
- 文档编号:30268300
- 上传时间:2023-08-13
- 格式:DOCX
- 页数:31
- 大小:687.78KB
公文管理系统分析与设计报告.docx
《公文管理系统分析与设计报告.docx》由会员分享,可在线阅读,更多相关《公文管理系统分析与设计报告.docx(31页珍藏版)》请在冰豆网上搜索。
公文管理系统分析与设计报告
公文管理系统
1系统概述
背景和意义
目前由于企事业单位收到的、以及下发的文件都是纸质形式,不便于公文接受单位对公文进行电子化存档、查询、调用等,影响文件使用效率。
另外纸质文件在下发时,呈几何级数增长的文件复印量,造成了纸张的大量浪费。
随着电子化办公迅速在各机关、企事业单位普及,在电脑上编制公文已成为机关工作人员的首选方式。
大量公文在编辑时已经是电子化的,这为电子化公文管理创造了便利条件。
随着网络带宽的不断提高,在线办公已成为发展趋势,公文完全可以电子化方式存放在服务器上,在数据库等计算机信息系统的支持下,对公文处理的各种信息进行收集、整理、存储、检索、统计和传播,随时可供文件使用单位调阅。
如今的企事业单位,每次公文下发,从公文复印、下发通知到下属单位来领取文件,整个过程将耗费很多的人力、物力、财力。
同时纸质的公文,在下属单位再次复印传阅,整个过程纸张用量巨大。
使用电子化公文管理系统后,将带来很多好处:
(1)大大提高办公效率,公文发送只需电脑上的一个操作,各基层单位可登陆系统,即时查阅公文,节约了时间、金钱。
(2)提高公文的利用效率。
公文的分类检索,将提高查询,方便了公文的使用。
(3)实现公文制作的全称监控,加强内部公文流转速度和质量。
此外,对于在办公室工作的人来说,每天的公文收发是非常繁琐的。
目前大部分单位仍然是采用手工抄写来完成这些繁琐的事务。
在公务繁忙时,常常有公文登记的遗漏,去向不明,甚至明明记得经过手,却找不到了的现象,现在好了,有了电子化的“公文管理系统”它可以协助我们有条不紊地处理所有的事务。
主要模块分为来文处理和发文处理:
(1)通过对整个过程的分步处理,可以让我们清楚地了解整个工作的进展情况
(2)系统的模糊查询功能可以让我们清楚地查询到所有符合条件的文件。
(3)方便的多用户权限功能让我们更加安全有效管理好所有文件的记录,让我们充分享受到自动化无纸办公给您带来的轻松和乐趣。
2系统分析
2.1组织机构
2.2业务流程
2.2.1流程描述
2.2.1.1定义
i.公文
公司的公文是公司在经营管理过程中所形成的具有法定效力和规范体式的公务文书,是传达贯彻公司精神与政策,发布规章制度,施行管理措施,请示和答复问题,指导、布置和商洽工作,报告情况,交流经验的重要工具
常用公文种类:
一、决议。
经会议讨论通过的重要决策事项,用“决议”。
二、决定。
对重要事项或重大行动作出安排,用“决定”。
三、公告。
向内外宣布重要事项或者法定事项,用“公告”。
四、通告。
在一定范围内公布应当遵守或周知的事项,用“通告”。
五、通知。
发布规章和行政措施,转发上级机关、同级机关和不相隶属机关的公文,批转下级机关的公文,要求下级机关办理和需要周知或共同执行的事项,任免和聘用干部,用“通知”。
六、通报。
表扬先进,批评错误,传达重要精神、交流重要情况,用“通报”。
七、报告。
向上级机关汇报工作、反映情况、提出建议,用“报告”。
八、请示。
向上级机关请求指示、批准,用“请示”。
九、批复。
答复下级机关的请示事项,用“批复”。
十、条例。
用于制定规范工作、活动和行为的规章制度,用“条例”。
十一、规定。
用于对特定范围内的工作和事务制定具有约束力的行为规范,用“规定”。
十二、意见。
对某一重要问题提出设想、建议和安排,用“意见”。
十三、函。
不相隶属机关之间相互商洽工作、询问和答复问题,向有关主管部门请求批准等,用“函”。
十四、会议纪要。
记载、传达会议议定事项和主要精神,用“会议纪要”。
ii.会签
会签是撰拟公文的过程中,主办单位主动与有关单位协商并核签的一种办文程序,一般当公文的内容涉及本单位的多个部门或与其他单位有关时,需要进行会签。
会签根据对象的不同分为内部会签和外部会签。
内部会签用于与本单位内部的各有关部门进行协商并核签;外部会签用于与外单位的有关部门进行协商并核签;二者的性质相同,但处理形式不同。
2.2.1.2发文管理
提供一套完善的电子公文发文流转环境。
在发文的起草、审签、会签、核稿、签发、编号、发出、归档等流转过程中,系统详细记录其流转情况,在流转的过程中相关部门(人员)没有及时处理时,系统发送短信息提示这些人员。
起草人员可以根据自身办公的流程,对系统管理中的流程管理模块进行灵活设置。
发文管理的主要功能需求如下:
●公文起草:
系统应该采用基于B/S的公文编辑工具,使得用户不需要在客户端安装任何软件就能对公文进行起草和编辑。
编辑工具应提供近似于流行的Word的常用编辑、排版功能。
公文起草根据公文种类,选用设置好的模板,以Word方式进行编辑。
●提醒:
公文流转到办理人员处,可以以手机短信、即时消息等方式提醒,加快公文办理的速度,提高办公效率。
●公文查询、导出:
为办公室实时跟踪公文运转提供强大的支撑。
对全部公文按任意条件查询,并将查询结果按时间排序(默认查询条件为近一月内文件),并可按excel格式保存和加工利用。
●公文办理:
公文办理的常用语如“同意”、“不同意”可以预先设置好,实现选择输入。
对于办理人员身份信息签名、签发日期等信息系统在使用人认可后自动输入,减少办理人员文字输入工作量。
●退回功能:
在公文送出后,遇到公文办理人员不能办理或公文发错对象,可以退回,返回到上一节点,重新选择办理人员。
●痕迹保留:
对公文的修改,保留历次的修改痕迹。
系统保留文件的两个版本,一个是保留痕迹的版本,另外一个是最终定稿的版本。
●催办:
所有参与公文流转的办理人员(包括拟稿人)都可以随时看到公文的办理状态,提示公文停留时间,系统可以自动对滞留的公文进行催办,也可以随时进行人工催办。
催办的方式可以是手机短信、即时消息等手段。
可以列表显示全部滞留办理的公文并支持打印输出,以便公文管理部门定期通报有关公文办理情况。
●文号管理:
系统对发文文号进行统一管理,避免重号、错号等错误的发生。
●公文打印:
公文在流转过程中,随时可以根据用户权限对公文进行打印。
●公文归档:
公文在办理以后,随时可以进行归档,添加有关归档信息。
●用户IP绑定:
对需要签名的领导级用户,要求用户名和计算机的IP绑定,以防用户名在其它计算机上被盗用。
●印章、红头管理:
系统应提供对印章、红头的统一管理,在发文套红、盖章时根据用户的权限、所在部门自动调用相应的印章和红头。
2.2.1.3收文管理
收文管理提供一套完善的电子公文收文流转环境。
在收文的登记、拟办、批办、分发、办理、传阅、归档等流转过程中,系统详细记录其流转情况。
收文的流转过程可以预先设定好,如果需要改变,根据办公室的意见,系统管理员对流程进行修改。
在流转过程中需要相关部门(人员)处理时,系统发送消息提示这些人员。
收文管理的主要功需求能如下:
●收文登记:
对电子来文提取来文信息,自动完成收文登记;对纸质来文需要打字输入收文登记信息,如来文标题、文号、发文部门等,形成收文登记表,同时还可以对文件进行扫描、然后进行文字修改。
●公文流转:
电子收文在工作流引擎的驱动下进行全过程的电子流转,可以按缺省流程流转、选择的流转、手工流转等多种方式;纸质公文运转的同时,办理人员应录入相关的处理信息,并可以以图形方式查看流转的状态。
●提醒功能:
公文流转到办理人员处,可以以手机短信、即时消息等方式提醒,加快公文办理的速度,提高办公效率。
●公文查询、导出功能:
为办公室适时跟踪公文运转提供强大的支撑。
对全部公文按任意条件查询,并将查询结果按时间排序(默认查询条件为近一月内文件),并可按excel格式保存和加工利用。
●公文办理:
用户可以直接输入办理意见,公文办理的常用语如“同意”、“不同意”可由用户预先设置,实现自动输入。
对于办理人员身份信息如签名、签发日期等,系统在用户确认后自动输入,减少办理人员文字输入工作量。
●退回功能:
在公文送出后,遇到公文办理人员不能办理或公文发错对象,可以退回,返回到上一节点,重新选择办理人员。
●文号管理:
系统对收文文号进行统一管理,避免重号、错号等错误的发生。
。
●公文打印:
公文在流转工程中,随时可以对公文进行打印。
●公文归档:
公文在办理以后,随时可以进行归档,添加有关归档信息。
●催办:
有参与公文流转的办理人员都可以随时看到公文的办理状态,提示公文停留时间,系统可以自动对滞留的公文进行催办,也可以随时进行人工催办。
催办的方式可以是手机短信、即时消息等手段。
对全部滞留办理的公文列表显示,并支持打印输出,以便公文管理部门定期通报有关公文处理情况。
●用户IP绑定:
对需要签名的领导级用户,要求用户绑定计算机的IP,以防签名在其它计算机上被盗用。
2.2.1.4收发文统计查询(日志记录)
公文查询应用面向对象为全区的使用人员,权限相对较低。
设计重点应体现在操作的方便、灵活性上。
系统应提供自定义的查询方式,用户可以根据自身需求,定制查询条件,使返回的结果更为准确。
并可以显示各单位全年公文办理的工作量等数据分析功能。
2.2.2业务流程泳道图
发文流程
拟稿:
一般由办公室文员拟稿(包括发文类型、标题、日期、主题词、发文部门、拟稿人、主送、文号、密级、紧急程度、正文、附件、审批人等),是公文管理的第一道程序。
核稿:
拟稿人所在的部门的部门负责人,对公文进行审核的业务过程。
建议在发文流程管理定义核稿的负责人为部门负责人,在实际公文流转中,确定实际的部门负责人。
审核:
一般指办公室审核,即对部门完成核稿的公文进行审核的业务过程。
审核过程中,基本上可以确定发文的密级、保密期限、主题词、发送方式等(若密级属于非公开或限定)。
会稿:
一般是多部门会稿,建议采用并行步骤,本步骤一般情况下可略过。
收文流程
拟办:
对收到的公文进行办理意见的填写以及流程的选择。
拟办的操作可设置代理人或关联人。
批办:
对收到的公文进行办理批示意见的填写,一般可设置为并行步骤。
建议事先在关联人设置为该步骤的负责人设置关联人,负责人只须填写相关意见,至于收文的继续流转交由关联人去做。
阅办:
对收到的公文进行阅读批示意见的填写并提交通过/退回意见。
若设置为并行步骤,则各负责人只需填写意见,由归并点负责人填写意见和提交通过/退回意见后再进入下一步流程。
承办,该操作类似阅办。
归档:
对流转完毕的收文进行归档。
只有拥有公文归档模块权限的用户才能进行公文归档。
归档后的收文不能在公文归档模块中直接再发送,需要到收文发送模块进行收文补发。
会签
2.3数据流程图
顶层数据流图
0层数据流图
24数据字典
2.4.1数据项
数据项编号:
X01
数据项名称:
发文编号
类型:
字符型
长度:
11
数据项编号:
X02
数据项名称:
发文部门
类型:
字符型
长度:
4
数据项编号:
X03
数据项名称:
文件字号
类型:
字符型
长度:
20
数据项编号:
X04
数据项名称:
文件标题
类型:
字符型
长度:
50
数据项编号:
X05
数据项名称:
主题词
类型:
字符型
长度:
200
数据项编号:
X06
数据项名称:
文件类别
类型:
字符型
长度:
4
取值:
命令|决定|公告|通知|通告|议案|报告|请示|意见|函|会议纪要
数据项编号:
X07
数据项名称:
文件密级
类型:
字符型
长度:
4
取值:
普通|机密|绝密
数据项编号:
X08
数据项名称:
加急
类型:
字符型
长度:
4
取值:
特急|紧急|一般
数据项编号:
X09
数据项名称:
份数
类型:
数值型
长度:
3
小数字:
0
取值范围:
1—999
数据项编号:
X10
数据项名称:
拟稿部门
类型:
字符型
长度:
4
数据项编号:
X11
数据项名称:
拟稿人
类型:
字符型
长度:
8
数据项编号:
X12
数据项名称:
拟稿时间
类型:
日期型
长度:
8
数据项编号:
X13
数据项名称:
公司领导1
简述:
发文时会签的领导
类型:
字符型
长度:
10
数据项编号:
X15
数据项名称:
审稿人
简述:
发文时进行审核的相关部门(人员)
类型:
字符型
长度:
8
数据项编号:
X16
数据项名称:
主送
类型:
字符型
长度:
100
数据项编号:
X17
数据项名称:
抄送
类型:
字符型
长度:
100
数据项编号:
X18
数据项名称:
存档时间
类型:
日期型
长度:
8
数据项编号:
X19
数据项名称:
收文编号
类型:
字符型
长度:
20
数据项编号:
X29
数据项名称:
公司领导2
简述:
收文时阅批的领导
类型:
字符型
长度:
8
数据项编号:
X30
数据项名称:
部门人员
简述:
收文时进行阅办处理的相关部门(人员)
类型:
字符型
长度:
8
数据项编号:
X31
数据项名称:
拟办意见
类型:
字符型
长度:
200
数据项编号:
X32
数据项名称:
附注
类型:
字符型
长度:
100
数据项编号:
X33
数据项名称:
处理时间
类型:
日期型
长度:
8
数据项编号:
X34
数据项名称:
处理结果
类型:
字符型
长度:
200
2.4.2数据流
数据流编号:
D1
数据流名称:
收文登记单
简述:
接收收文处理的情况
数据流来源:
公司办公室秘书输入
数据流去向:
收文登记处理功能
数据流组成:
收文编号+发文部门+文件字号+文件标题+主题词+文件类别+文件密级+加急+份数+收到时间+登记时间
数据流编号:
D2
数据流名称:
阅办后收文登记单
简述:
领导阅批后相关部门阅办后的收文登记单
数据流来源:
领导和相关部门(人员)
数据流去向:
存档处理功能
数据流组成:
收文编号+文件编号+发文部门+文件字号+文件标题+主题词+文件类别+文件密级+加急+份数+收到时间+登记时间+登记人+公司领导2+部门人员+拟办意见+领导批示+附注
数据流编号:
D3
数据流名称:
下发处理后登记单
简述:
返回处理结果后的登记单
数据流来源:
相关部门(人员)
数据流去向:
收文台账
数据流组成:
收文编号+文件编号+发文部门+文件字号+文件标题+主题词+文件类别+文件密级+加急+份数+收到时间+登记时间+公司领导2+部门人员+部门人员+拟办意见+领导批示+附注+处理时间+处理结果
数据流编号:
D4
数据流名称:
发文登记单
简述:
发文时的情况
数据流来源:
办公室秘书输入
数据流去向:
发文登记处理功能、相关部门(人员)。
数据流组成:
发文编号+文件编号+发文部门+文件字号+文件标题+主题词+文件类别+文件密级+加急+份数+拟稿部门+拟稿时间
数据流编号:
D5
数据流名称:
审核后的发文登记单
简述:
包含审核、会签处理的发文登记单
数据流来源:
发文登记处理功能、相关部门(人员)、公司领导
数据流去向:
发行处理功能
数据流组成:
发文编号+发文部门+文件字号+文件标题+主题词+文件类别+文件密级+加急+份数+拟稿部门+拟稿时间+登记人+公司领导1+审稿人
数据流编号:
D6
数据流名称:
发行处理后登记单
简述:
包含发行处理信息的登记单
数据流来源:
审核处理功能
数据流去向:
秘书
数据流组成:
发文编号+发文部门+文件字号+文件标题+主题词+文件类别+文件密级+加急+份数+拟稿部门+拟稿时间+公司领导1+审稿人+主送+抄送+抄报+下发时间
2.4.3数据存储
数据存储编号:
F1
数据存储名称:
收文数据库
简述:
收文的收文编号、文件编号等信息,保存未存档收文信息。
数据存储结构:
收文编号+发文单位+文件字号+文件标题+主题词+文件类别+文件密级+加急+份数+收到时间+登记时间+公司领导2+部门人员+拟办意见+领导批示+附注+处理时间+处理结果+存档时间
结果关键词:
收文编号
相关的处理:
P1,P2,P3,P4,P9
数据存储编号:
F2
数据存储名称:
收文查询数据库
简述:
收文信息查询,暂时保存未存档和已经存档收文信息。
数据存储结构:
收文编号+发文单位+文件字号+文件标题+主题词+文件类别+文件密级+加急+份数+收到时间+登记时间+公司领导2+部门人员+拟办意见+领导批示+附注+处理时间+处理结果+存档时间
关键词:
收文编号
相关的处理:
P4,P9
数据存储编号:
F3
数据存储名称:
收文存档数据库
简述:
保存已经存档收文信息
数据存储结构:
收文编号+发文单位+文件字号+文件标题+主题词+文件类别+文件密级+加急+份数+收到时间+登记时间+公司领导2+部门人员+拟办意见+领导批示+附注+处理时间+处理结果+存档时间
关键词:
收文编号
相关的处理:
P4
数据存储编号:
F4
数据存储名称:
发文数据库
简述:
发文的发文编号、文件编号等信息,保存未存档发文信息。
数据存储结构:
发文编号+文件编号+发文单位+文件字号+文件标题+主题词+文件类别+文件密级+加急+份数+拟稿部门+拟稿时间+登记人+公司领导1+公司领导2+公司领导3+审稿人1+审稿人2+审稿人3+签发人+主送+抄送+抄报+下发时间+存档时间
结果关键词:
发文编号
相关的处理:
P5,P5,P7,P8,P10
数据存储编号:
F5
数据存储名称:
发文查询数据库
简述:
发文信息查询,暂时保存未存档和已经存档发文信息
数据存储结构:
发文编号+发文单位+文件字号+文件标题+主题词+文件类别+文件密级+加急+份数+拟稿部门+拟稿时间+公司领导1+审稿人+主送+抄送+抄报+下发时间+存档时间
关键词:
发文编号
相关的处理:
P8,P10
数据存储编号:
F6
数据存储名称:
发文存档数据库
简述:
保存已经存档发文信息
数据存储结构:
发文编号+发文单位+文件字号+文件标题+主题词+文件类别+文件密级+加急+份数+拟稿部门+拟稿时间+公司领导1+审稿人+主送+抄送+抄报+下发时间+存档时间
关键词:
发文编号
相关的处理:
P8
2.4.4外部实体
外部实体名称
描述
相关部门
1发文时需要多个部门会签,需要这些部门的主任审阅、盖章
2收文登记后,需要其他部门来共同处理公文的内容
领导(主任)
1审核公文、分发公文
2查阅归档了的公文
文员(秘书)
1拟稿
2收文
公文档案
归档后的公文进行存储的数据库
3系统设计
3.1功能结构图设计
3.2数据库设计
3.2.1数据库概念设计
ER图:
公文
通知消息
员工和部门
全局ER图
关系模型:
公文(编号,文件字号,文件标题,文件类别,文件密级,加急,主题词,发文时间,公文内容,附件,拟稿人,审稿人,批办人),拟稿人、审稿人、批办人等均为员工编号,为外键;
员工(员工编号,员工姓名,所属部门,职位);
通知消息(消息编号,类型,发送人,对应公文号,消息内容),对应公文号为外键;
部门(部门编号,部门名称);
审稿(公文编号,审稿人编号,审稿日期,再审编号),再审编号为外键;
批办(公文编号,批办人,日期,批办意见);
发送接收(消息编号,公文编号,员工编号,类型,日期)
3.2.2数据库逻辑设计
(1)公文数据表(documents):
序号
字段
数据类型
能否为空
说明
1
doc_id
Char(11)
否
主键
2
doc_wordID
Varchar(20)
否
文件字号
3
doc_title
Char(50)
否
公文标题
4
doc_level
char(4)
否
公文密级(取值为普通,机密,绝密),默认为普通
5
doc_hurry
Char(4)
否
加急(取值为特急,紧急,一般),默认为一般
6
doc_keywords
Char(200)
否
主题词,可以为多个,以逗号分隔
7
doc_date
datetime
否
发文时间
8
doc_context
text
否
发文内容
9
doc_appendix
Char(100)
可
上传的附件地址
10
doc_applierID
Char(7)
否
拟稿人编号,外键,参照员工表的员工编号(具有某种职务)
11
doc_checkerID
char(7)
可
审查人ID,外键,参照员工表的员工编号(具有某种职务)
12
doc_doID
char(7)
否
批办人ID,外键,参照员工表的员工编号(具有某种职务)
(2)员工表(workers):
序号
字段
数据类型
能否为空
说明
1
worker_id
char(7)
否
主键,员工ID
2
worker_name
Varchar(20)
否
员工姓名
3
woker_department
Char(4)
否
所属部门
4
worker_status
char(8)
否
职位(文秘,主任,审稿人,批办人等)
(3)通知消息表(notes):
序号
字段
数据类型
能否为空
说明
1
note_id
char(11)
否
主键,消息编号
2
note_type
Varchar(8)
否
消息类型(退回,催办)
3
note_sender
Char(7)
否
消息发送人,外键
4
note_docID
char(11)
否
针对什么公文发送的消息
5
note_contex
text
否
消息具体内容
(4)部门表(departments):
序号
字段
数据类型
能否为空
说明
1
dep_id
char(4)
否
主键,部门编号
2
dep_name
Varchar(20)
否
部门名称
(5)审稿表(check_docs):
序号
字段
数据类型
能否为空
说明
1
doc_id
char(11)
否
主键,公文编号,外键
2
checker_id
char(7)
否
主键,审稿人编号,外键
3
check_date
datetime
否
审稿日期
4
recheck_checkerid
char(7)
可
再审人编号,外键
(6)批办表(do_docs):
序号
字段
数据类型
能否为空
说明
1
do_docid
char(11)
否
主键,公文编号,外键
2
do_woker
char(7)
否
主键,批办人,外键
3
do_date
datetime
否
批办日期
4
do_suggest
varchar(200)
可
批办意见
(7)发送接收表(send_receive):
序号
字段
数据类型
能否为空
说明
1
note_id
char(11)
否
主键,消息编号
2
doc_id
char(11)
否
主键,公文编号
3
woker_id
char(7)
否
主键,员工编号
4
SR_type
char(4)
否
发送:
表示是一条发送消息,woker_id把关于doc_id的消息note_id发送出去
接收:
表示一条接收消息,worker_id接收到关于doc_id的消息note_id
3.3代码设计
1.发文编号
收文编号的代码采用复合码,并用11位字符表示。
设计方案如下图所示。
XX XXXXXX
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 公文 管理 系统分析 设计 报告