公文管理系统分析与设计报告设计.doc

1、 目录1 系统概述2背景和意义22 系统分析32.1 组织机构32.2 业务流程32.2.1 流程描述32.2.2 业务流程泳道图62.3 数据流程图824 数据字典102.4.1 数据项102.4.2 数据流132.4.3数据存储142.4.4 外部实体153 系统设计163.1 功能结构图设计163.2 数据库设计163.2.1 数据库概念设计163.2.2 数据库逻辑设计183.3 代码设计203.4 输入设计213.5 输出设计223.6 界面设计231 系统概述背景和意义目前由于企事业单位收到的、以及下发的文件都是纸质形式，不便于公文接受单位对公文进行电子化存档、查询、调用等，影响文

2、件使用效率。另外纸质文件在下发时，呈几何级数增长的文件复印量，造成了纸张的大量浪费。随着电子化办公迅速在各机关、企事业单位普及，在电脑上编制公文已成为机关工作人员的首选方式。大量公文在编辑时已经是电子化的，这为电子化公文管理创造了便利条件。随着网络带宽的不断提高，在线办公已成为发展趋势，公文完全可以电子化方式存放在服务器上，在数据库等计算机信息系统的支持下，对公文处理的各种信息进行收集、整理、存储、检索、统计和传播，随时可供文件使用单位调阅。如今的企事业单位，每次公文下发，从公文复印、下发通知到下属单位来领取文件，整个过程将耗费很多的人力、物力、财力。同时纸质的公文，在下属单位再次复印传阅，整

3、个过程纸张用量巨大。使用电子化公文管理系统后，将带来很多好处：（1） 大大提高办公效率，公文发送只需电脑上的一个操作，各基层单位可登陆系统，即时查阅公文，节约了时间、金钱。（2） 提高公文的利用效率。公文的分类检索，将提高查询，方便了公文的使用。（3） 实现公文制作的全称监控，加强内部公文流转速度和质量。此外，对于在办公室工作的人来说，每天的公文收发是非常繁琐的。目前大部分单位仍然是采用手工抄写来完成这些繁琐的事务。在公务繁忙时，常常有公文登记的遗漏，去向不明，甚至明明记得经过手，却找不到了的现象，现在好了，有了电子化的“公文管理系统”它可以协助我们有条不紊地处理所有的事务。主要模块分为来文处

4、理和发文处理：（1） 通过对整个过程的分步处理，可以让我们清楚地了解整个工作的进展情况（2） 系统的模糊查询功能可以让我们清楚地查询到所有符合条件的文件。（3） 方便的多用户权限功能让我们更加安全有效管理好所有文件的记录，让我们充分享受到自动化无纸办公给您带来的轻松和乐趣。2 系统分析2.1 组织机构2.2 业务流程2.2.1 流程描述2.2.1.1 定义i. 公文公司的公文是公司在经营管理过程中所形成的具有法定效力和规范体式的公务文书，是传达贯彻公司精神与政策，发布规章制度，施行管理措施，请示和答复问题，指导、布置和商洽工作，报告情况，交流经验的重要工具常用公文种类：一、决议。经会议讨论通过

5、的重要决策事项，用“决议”。二、决定。对重要事项或重大行动作出安排，用“决定”。三、公告。向内外宣布重要事项或者法定事项，用“公告”。四、通告。在一定范围内公布应当遵守或周知的事项，用“通告”。五、通知。发布规章和行政措施，转发上级机关、同级机关和不相隶属机关的公文，批转下级机关的公文，要求下级机关办理和需要周知或共同执行的事项，任免和聘用干部，用“通知”。六、通报。表扬先进，批评错误，传达重要精神、交流重要情况，用“通报”。七、报告。向上级机关汇报工作、反映情况、提出建议，用“报告”。八、请示。向上级机关请求指示、批准，用“请示”。九、批复。答复下级机关的请示事项，用“批复”。十、条例。用于

6、制定规范工作、活动和行为的规章制度，用“条例”。十一、规定。用于对特定范围内的工作和事务制定具有约束力的行为规范，用“规定”。十二、意见。对某一重要问题提出设想、建议和安排，用“意见”。十三、函。不相隶属机关之间相互商洽工作、询问和答复问题，向有关主管部门请求批准等，用“函”。十四、会议纪要。记载、传达会议议定事项和主要精神，用“会议纪要”。ii. 会签会签是撰拟公文的过程中，主办单位主动与有关单位协商并核签的一种办文程序，一般当公文的内容涉及本单位的多个部门或与其他单位有关时，需要进行会签。会签根据对象的不同分为内部会签和外部会签。内部会签用于与本单位内部的各有关部门进行协商并核签；外部会签

7、用于与外单位的有关部门进行协商并核签；二者的性质相同，但处理形式不同。2.2.1.2 发文管理提供一套完善的电子公文发文流转环境。在发文的起草、审签、会签、核稿、签发、编号、发出、归档等流转过程中，系统详细记录其流转情况，在流转的过程中相关部门（人员）没有及时处理时，系统发送短信息提示这些人员。起草人员可以根据自身办公的流程，对系统管理中的流程管理模块进行灵活设置。 发文管理的主要功能需求如下： l 公文起草：系统应该采用基于B/S的公文编辑工具，使得用户不需要在客户端安装任何软件就能对公文进行起草和编辑。编辑工具应提供近似于流行的Word的常用编辑、排版功能。公文起草根据公文种类，选用设置好

8、的模板，以Word方式进行编辑。 l 提醒：公文流转到办理人员处，可以以手机短信、即时消息等方式提醒，加快公文办理的速度，提高办公效率。 l 公文查询、导出：为办公室实时跟踪公文运转提供强大的支撑。对全部公文按任意条件查询，并将查询结果按时间排序（默认查询条件为近一月内文件），并可按excel格式保存和加工利用。 l 公文办理：公文办理的常用语如“同意”、“不同意”可以预先设置好，实现选择输入。对于办理人员身份信息签名、签发日期等信息系统在使用人认可后自动输入，减少办理人员文字输入工作量。 l 退回功能：在公文送出后，遇到公文办理人员不能办理或公文发错对象，可以退回，返回到上一节点，重新选择办

9、理人员。 l 痕迹保留：对公文的修改，保留历次的修改痕迹。系统保留文件的两个版本，一个是保留痕迹的版本，另外一个是最终定稿的版本。 l 催办：所有参与公文流转的办理人员（包括拟稿人）都可以随时看到公文的办理状态，提示公文停留时间，系统可以自动对滞留的公文进行催办，也可以随时进行人工催办。催办的方式可以是手机短信、即时消息等手段。可以列表显示全部滞留办理的公文并支持打印输出，以便公文管理部门定期通报有关公文办理情况。 l 文号管理：系统对发文文号进行统一管理，避免重号、错号等错误的发生。 l 公文打印：公文在流转过程中，随时可以根据用户权限对公文进行打印。 l 公文归档：公文在办理以后，随时可以

10、进行归档，添加有关归档信息。 l 用户IP绑定：对需要签名的领导级用户，要求用户名和计算机的IP绑定，以防用户名在其它计算机上被盗用。 l 印章、红头管理：系统应提供对印章、红头的统一管理，在发文套红、盖章时根据用户的权限、所在部门自动调用相应的印章和红头。 2.2.1.3 收文管理收文管理提供一套完善的电子公文收文流转环境。在收文的登记、拟办、批办、分发、办理、传阅、归档等流转过程中，系统详细记录其流转情况。收文的流转过程可以预先设定好，如果需要改变，根据办公室的意见，系统管理员对流程进行修改。在流转过程中需要相关部门（人员）处理时，系统发送消息提示这些人员。 收文管理的主要功需求能如下：

11、l 收文登记：对电子来文提取来文信息，自动完成收文登记；对纸质来文需要打字输入收文登记信息，如来文标题、文号、发文部门等，形成收文登记表，同时还可以对文件进行扫描、然后进行文字修改。 l 公文流转：电子收文在工作流引擎的驱动下进行全过程的电子流转，可以按缺省流程流转、选择的流转、手工流转等多种方式；纸质公文运转的同时，办理人员应录入相关的处理信息，并可以以图形方式查看流转的状态。 l 提醒功能：公文流转到办理人员处，可以以手机短信、即时消息等方式提醒，加快公文办理的速度，提高办公效率。 l 公文查询、导出功能：为办公室适时跟踪公文运转提供强大的支撑。对全部公文按任意条件查询，并将查询结果按时间

12、排序（默认查询条件为近一月内文件），并可按excel格式保存和加工利用。 l 公文办理：用户可以直接输入办理意见，公文办理的常用语如“同意”、“不同意”可由用户预先设置，实现自动输入。对于办理人员身份信息如签名、签发日期等，系统在用户确认后自动输入，减少办理人员文字输入工作量。 l 退回功能：在公文送出后，遇到公文办理人员不能办理或公文发错对象，可以退回，返回到上一节点，重新选择办理人员。 l 文号管理：系统对收文文号进行统一管理，避免重号、错号等错误的发生。 l 公文打印：公文在流转工程中，随时可以对公文进行打印。 l 公文归档：公文在办理以后，随时可以进行归档，添加有关归档信息。 l 催办

13、：有参与公文流转的办理人员都可以随时看到公文的办理状态，提示公文停留时间，系统可以自动对滞留的公文进行催办，也可以随时进行人工催办。催办的方式可以是手机短信、即时消息等手段。对全部滞留办理的公文列表显示，并支持打印输出，以便公文管理部门定期通报有关公文处理情况。 l 用户IP绑定：对需要签名的领导级用户，要求用户绑定计算机的IP，以防签名在其它计算机上被盗用。 2.2.1.4 收发文统计查询（日志记录）公文查询应用面向对象为全区的使用人员，权限相对较低。设计重点应体现在操作的方便、灵活性上。系统应提供自定义的查询方式，用户可以根据自身需求，定制查询条件，使返回的结果更为准确。并可以显示各单位全

14、年公文办理的工作量等数据分析功能。2.2.2 业务流程泳道图发文流程拟稿：一般由办公室文员拟稿（包括发文类型、标题、日期、主题词、发文部门、拟稿人、主送、文号、密级、紧急程度、正文、附件、审批人等），是公文管理的第一道程序。核稿：拟稿人所在的部门的部门负责人，对公文进行审核的业务过程。建议在发文流程管理定义核稿的负责人为部门负责人，在实际公文流转中，确定实际的部门负责人。审核：一般指办公室审核，即对部门完成核稿的公文进行审核的业务过程。审核过程中，基本上可以确定发文的密级、保密期限、主题词、发送方式等（若密级属于非公开或限定）。会稿：一般是多部门会稿，建议采用并行步骤，本步骤一般情况下可略过。

15、收文流程拟办：对收到的公文进行办理意见的填写以及流程的选择。拟办的操作可设置代理人或关联人。批办：对收到的公文进行办理批示意见的填写，一般可设置为并行步骤。建议事先在关联人设置为该步骤的负责人设置关联人，负责人只须填写相关意见，至于收文的继续流转交由关联人去做。阅办：对收到的公文进行阅读批示意见的填写并提交通过/退回意见。若设置为并行步骤，则各负责人只需填写意见，由归并点负责人填写意见和提交通过/退回意见后再进入下一步流程。承办，该操作类似阅办。归档：对流转完毕的收文进行归档。只有拥有公文归档模块权限的用户才能进行公文归档。归档后的收文不能在公文归档模块中直接再发送，需要到收文发送模块进行收文

16、补发。会签2.3 数据流程图顶层数据流图0层数据流图24 数据字典2.4.1 数据项数据项编号：X01数据项名称：发文编号 类型：字符型长度：11数据项编号：X02数据项名称：发文部门类型：字符型长度：4数据项编号：X03数据项名称：文件字号类型：字符型长度：20数据项编号：X04数据项名称：文件标题类型：字符型长度：50数据项编号：X05数据项名称：主题词类型：字符型长度：200数据项编号：X06数据项名称：文件类别类型：字符型长度：4取值：命令 | 决定 | 公告 | 通知 | 通告 | 议案 | 报告 | 请示 | 意见 | 函 | 会议纪要数据项编号：X07数据项名称：文件密级类型：字

17、符型长度：4取值：普通 | 机密 | 绝密数据项编号：X08数据项名称：加急类型：字符型长度：4取值：特急 | 紧急 | 一般数据项编号：X09数据项名称：份数类型：数值型长度：3小数字：0取值范围：1999数据项编号：X10数据项名称：拟稿部门类型：字符型长度：4数据项编号：X11数据项名称：拟稿人类型：字符型长度：8数据项编号：X12数据项名称：拟稿时间类型：日期型长度：8数据项编号：X13数据项名称：公司领导1简述：发文时会签的领导类型：字符型长度：10数据项编号：X15数据项名称：审稿人简述：发文时进行审核的相关部门（人员）类型：字符型长度：8数据项编号：X16数据项名称：主送类型：字

18、符型长度：100数据项编号：X17数据项名称：抄送类型：字符型长度：100数据项编号：X18数据项名称：存档时间类型：日期型长度：8数据项编号：X19数据项名称：收文编号 类型：字符型长度：20数据项编号：X29数据项名称：公司领导2简述：收文时阅批的领导类型：字符型长度：8数据项编号：X30数据项名称：部门人员简述：收文时进行阅办处理的相关部门（人员）类型：字符型长度：8数据项编号：X31数据项名称：拟办意见类型：字符型长度：200数据项编号：X32数据项名称：附注类型：字符型长度：100数据项编号：X33数据项名称：处理时间类型：日期型长度：8数据项编号：X34数据项名称：处理结果类型：字

19、符型长度：2002.4.2 数据流数据流编号：D1数据流名称：收文登记单简述：接收收文处理的情况数据流来源：公司办公室秘书输入数据流去向：收文登记处理功能数据流组成：收文编号+发文部门+文件字号+文件标题+主题词+文件类别+文件密级+加急+份数+收到时间+登记时间数据流编号：D2数据流名称：阅办后收文登记单简述：领导阅批后相关部门阅办后的收文登记单数据流来源：领导和相关部门（人员）数据流去向：存档处理功能数据流组成：收文编号+文件编号+发文部门+文件字号+文件标题+主题词+文件类别+文件密级+加急+份数+收到时间+登记时间+登记人+公司领导2+部门人员+拟办意见+领导批示+附注数据流编号：D3

20、数据流名称：下发处理后登记单简述：返回处理结果后的登记单数据流来源：相关部门（人员）数据流去向：收文台账数据流组成：收文编号+文件编号+发文部门+文件字号+文件标题+主题词+文件类别+文件密级+加急+份数+收到时间+登记时间+公司领导2+部门人员+部门人员+拟办意见+领导批示+附注+处理时间+处理结果 数据流编号：D4数据流名称：发文登记单简述：发文时的情况数据流来源：办公室秘书输入数据流去向：发文登记处理功能、相关部门（人员）。数据流组成：发文编号+文件编号+发文部门+文件字号+文件标题+主题词+文件类别+文件密级+加急+份数+拟稿部门+拟稿时间 数据流编号：D5数据流名称：审核后的发文登记

21、单简述：包含审核、会签处理的发文登记单数据流来源：发文登记处理功能、相关部门（人员）、公司领导数据流去向：发行处理功能数据流组成：发文编号+发文部门+文件字号+文件标题+主题词+文件类别+文件密级+加急+份数+拟稿部门+拟稿时间+登记人+公司领导1+审稿人数据流编号：D6数据流名称：发行处理后登记单简述：包含发行处理信息的登记单数据流来源：审核处理功能数据流去向：秘书数据流组成：发文编号+发文部门+文件字号+文件标题+主题词+文件类别+文件密级+加急+份数+拟稿部门+拟稿时间+公司领导1+审稿人+主送+抄送+抄报+下发时间2.4.3数据存储数据存储编号：F1数据存储名称：收文数据库简述：收文的

22、收文编号、文件编号等信息，保存未存档收文信息。数据存储结构：收文编号+发文单位+文件字号+文件标题+主题词+文件类别+文件密级+加急+份数+收到时间+登记时间+公司领导2+部门人员+拟办意见+领导批示+附注+处理时间+处理结果+存档时间结果关键词：收文编号相关的处理：P1，P2，P3，P4，P9数据存储编号：F2数据存储名称：收文查询数据库简述：收文信息查询，暂时保存未存档和已经存档收文信息。数据存储结构：收文编号+发文单位+文件字号+文件标题+主题词+文件类别+文件密级+加急+份数+收到时间+登记时间+公司领导2+部门人员+拟办意见+领导批示+附注+处理时间+处理结果+存档时间 关键词：收文

23、编号相关的处理：P4，P9数据存储编号：F3数据存储名称：收文存档数据库简述：保存已经存档收文信息数据存储结构：收文编号+发文单位+文件字号+文件标题+主题词+文件类别+文件密级+加急+份数+收到时间+登记时间+公司领导2+部门人员+拟办意见+领导批示+附注+处理时间+处理结果+存档时间关键词：收文编号相关的处理：P4数据存储编号：F4数据存储名称：发文数据库简述：发文的发文编号、文件编号等信息，保存未存档发文信息。数据存储结构：发文编号+文件编号+发文单位+文件字号+文件标题+主题词+文件类别+文件密级+加急+份数+拟稿部门+拟稿时间+登记人+公司领导1+公司领导2+公司领导3+审稿人1+审

24、稿人2+审稿人3+签发人+主送+抄送+抄报+下发时间+存档时间结果关键词：发文编号相关的处理：P5，P5，P7，P8，P10数据存储编号：F5数据存储名称：发文查询数据库简述：发文信息查询，暂时保存未存档和已经存档发文信息数据存储结构：发文编号+发文单位+文件字号+文件标题+主题词+文件类别+文件密级+加急+份数+拟稿部门+拟稿时间+公司领导1+审稿人+主送+抄送+抄报+下发时间+存档时间关键词：发文编号相关的处理：P8，P10数据存储编号：F6数据存储名称：发文存档数据库简述：保存已经存档发文信息数据存储结构：发文编号+发文单位+文件字号+文件标题+主题词+文件类别+文件密级+加急+份数+拟

25、稿部门+拟稿时间+公司领导1+审稿人+主送+抄送+抄报+下发时间+存档时间关键词：发文编号相关的处理：P82.4.4 外部实体外部实体名称描述相关部门 发文时需要多个部门会签，需要这些部门的主任审阅、盖章 收文登记后，需要其他部门来共同处理公文的内容领导（主任） 审核公文、分发公文 查阅归档了的公文文员（秘书） 拟稿 收文公文档案归档后的公文进行存储的数据库3 系统设计3.1 功能结构图设计3.2 数据库设计3.2.1 数据库概念设计ER图：公文通知消息员工和部门全局ER图关系模型：公文（编号，文件字号，文件标题，文件类别，文件密级，加急，主题词，发文时间，公文内容，附件，拟稿人，审稿人，批办

26、人），拟稿人、审稿人、批办人等均为员工编号，为外键；员工（员工编号，员工姓名，所属部门，职位）；通知消息（消息编号，类型，发送人，对应公文号，消息内容），对应公文号为外键；部门（部门编号，部门名称）；审稿（公文编号，审稿人编号，审稿日期，再审编号），再审编号为外键；批办（公文编号，批办人，日期，批办意见）；发送接收（消息编号，公文编号，员工编号，类型，日期）3.2.2 数据库逻辑设计（1） 公文数据表（documents）：序号字段数据类型能否为空说明1doc_idChar(11)否主键2doc_wordIDVarchar(20)否文件字号3doc_titleChar(50)否公文标题4doc

27、_levelchar(4)否公文密级（取值为普通，机密，绝密），默认为 普通5doc_hurryChar(4)否加急（取值为特急，紧急，一般），默认为 一般6doc_keywordsChar(200)否主题词，可以为多个，以逗号分隔7doc_datedatetime否发文时间8doc_contexttext否发文内容9doc_appendixChar(100)可上传的附件地址10doc_applierIDChar(7)否拟稿人编号，外键，参照员工表的员工编号（具有某种职务）11doc_checkerIDchar(7)可审查人ID，外键，参照员工表的员工编号（具有某种职务）12doc_doIDc

28、har(7)否批办人ID，外键，参照员工表的员工编号（具有某种职务）（2） 员工表（workers）：序号字段数据类型能否为空说明1worker_idchar(7)否主键，员工ID2worker_nameVarchar(20)否员工姓名3woker_departmentChar(4)否所属部门4worker_statuschar(8)否职位（文秘，主任，审稿人，批办人等）（3） 通知消息表（notes）：序号字段数据类型能否为空说明1note_idchar(11)否主键，消息编号2note_typeVarchar(8)否消息类型（退回，催办）3note_senderChar(7)否消息发送人，

29、外键4note_docIDchar(11)否针对什么公文发送的消息5note_contextext否消息具体内容（4） 部门表（departments）：序号字段数据类型能否为空说明1dep_idchar(4)否主键，部门编号2dep_nameVarchar(20)否部门名称（5） 审稿表（check_docs）：序号字段数据类型能否为空说明1doc_idchar(11)否主键，公文编号，外键2checker_idchar(7)否主键，审稿人编号，外键3check_datedatetime否审稿日期4recheck_checkeridchar(7)可再审人编号，外键（6） 批办表（do_doc

30、s）：序号字段数据类型能否为空说明1do_docidchar(11)否主键，公文编号，外键2do_wokerchar(7)否主键，批办人，外键3do_datedatetime否批办日期4do_suggestvarchar(200)可批办意见（7） 发送接收表（send_receive）：序号字段数据类型能否为空说明1note_idchar(11)否主键，消息编号2doc_idchar(11)否主键，公文编号3woker_idchar(7)否主键，员工编号4SR_typechar(4)否发送：表示是一条发送消息，woker_id把关于doc_id的消息note_id发送出去接收：表示一条接收消息

31、，worker_id接收到关于doc_id的消息note_id3.3 代码设计1. 发文编号收文编号的代码采用复合码，并用11位字符表示。设计方案如下图所示。X X X X X X X X X X X 顺序号 日 月份 年份如：20120417012.收文编号发文编号的代码采用复合码，并用11位字符表示，采用方案如下图所示。X X X X X X X X X X X 顺序号 日 月份 年份如：201204170023.用户IDX X X X X X X用户顺序号子部门号部门号如：RSKQ001 （表示人事部 考勤处 001号）3.4 输入设计公文正文：像文件编号、发文时间、登记时间等由系统自动填写，然后可以随用户修改。正文采用office插件，使得可以在MS office中直接编辑。收文登记单:发文登记单: 3.5 输出设计收文台账查询输出收文台账打印输出发文记录（台账）查询输出发文台账打印输出3.6 界面设计拟稿：催办（消息提醒）：