综合管理系统概要设计
系统设计-概要设计
行衡量。
03
并发用户数
系统能够同时处理的用户请求数 量，反映了系统的并发处理能力
。
02
吞吐量
系统在单位时间内处理请求的能力， 通常以每秒请求数（RPS）或每秒
事务数（TPS）来衡量。
04
资源利用率
系统资源（如CPU、内存、磁盘 等）的使用情况，通常以百分比
设计清晰、易用的导航结构，帮助用户快速定位和浏览所 需信息。
动画与过渡效果
适当运用动画和过渡效果，增加界面的趣味性和互动性。
响应式设计
确保界面在不同设备和屏幕尺寸下均能良好显示和使用， 提高用户体验的一致性。
06
系统安全设计
身份认证与授权管理
用户名/密码认证
采用强密码策略，定期更换密码，并 限制登录尝试次数以防止暴力破解。
负载均衡与容错机制
负载均衡
通过合理的分配请求到多个服务器 上，使得每个服务器都能够得到充 分利用，避免出现单点故障和资源
浪费。
超时控制
当系统中某个节点出现故障时，能 够自动切换到其他可用节点上继续 提供服务，保证系统的可用性和稳
定性。
容错机制
通过构建服务器集群来提高系统的 可用性和扩展性，当某个节点出现 故障时，其他节点可以接管其工作 负载。
02
需求分析
功能需求
用户管理
包括用户注册、登录、信息修 改、权限管理等功能。
数据管理
包括数据的增删改查、数据备 份恢复等功能。
报表能。
系统集成
支持与其他系统的集成，如OA 、ERP等。
非功能需求
性能需求
系统应满足一定的响应时间、吞吐量、并发 用户数等性能指标。
酒店管理系统概要设计说明书
酒店管理系统概要设计说明书酒店管理系统概要设计说明书1.引言1.1 目的本文档旨在详细说明酒店管理系统的概要设计，包括系统的整体架构、功能需求、非功能需求等内容，以便开发团队能够清晰地了解系统的设计要求和实现方式。
1.2 范围本文档适用于酒店管理系统的设计和开发，涉及系统的各个方面，包括前台管理、客房管理、餐饮管理、财务管理等。
2.系统概述2.1 系统功能酒店管理系统主要包括以下功能：- 前台管理：包括客户预订、入住办理、退房结算等功能；- 客房管理：包括客房信息管理、客房状态管理、维修保养等功能；- 餐饮管理：包括餐厅预订、点餐、食材库存管理等功能；- 财务管理：包括账务结算、财务报表等功能；- 数据分析：根据系统数据进行统计分析，提供决策依据。
2.2 系统架构酒店管理系统采用分层架构，将系统分为展示层、业务逻辑层和数据访问层三个层次。
展示层负责与用户交互，业务逻辑层负责实现系统的各项功能，数据访问层负责与数据库进行数据交互。
3.功能需求说明3.1 前台管理3.1.1 客户预订- 允许客户通过系统进行客房预订；- 提供客房查询功能，根据客户需求筛选合适的客房；- 允许客户选择入住日期和离店日期，并预订记录。
3.1.2 入住办理- 前台人员通过系统办理客户入住手续；- 根据客户预订记录分配客房，并记录客房使用信息。
3.1.3 退房结算- 前台人员通过系统办理客户退房手续；- 根据客房使用信息计算客户的费用，并结算清单。
3.2 客房管理3.2.1 客房信息管理- 提供客房信息的录入和维护功能；- 包括客房编号、客房类型、客房价格等信息。
3.2.2 客房状态管理- 根据客房使用情况更新客房状态；- 包括客房是否空闲、是否需要维修等状态。
3.3 餐饮管理3.3.1 餐厅预订- 允许客户通过系统进行餐厅预订；- 提供餐厅座位查询功能，根据客户需求筛选合适的座位。
3.3.2 点餐- 允许客户通过系统进行餐点的点餐；- 根据客户的点餐信息订单。
学校综合管理系统建设方案
学校综合管理系统建设方案一、引言随着社会的进步和发展，学校的规模和复杂性也日益增加，传统的管理方式已经无法满足学校的需求。
为了提高学校的综合管理水平和效率，我们需要建立一套完善的学校综合管理系统。
二、系统需求分析1. 信息管理：学校需要建立统一的信息平台，实现学籍管理、成绩管理、教师管理、课程管理等功能，以便学校能够更好地掌握学生和教师的信息。
2. 教务管理：学校需要建立教务管理系统，包括课程表编排、选课管理、考试管理等功能，方便学校管理课程和教学进度。
3. 资产管理：学校需要建立资产管理系统，包括设备、图书馆资源等资产的管理和调配，方便学校对资产的追踪和使用情况的监控。
4. 基础设施管理：学校需要建立基础设施的管理系统，包括教室、实验室等的预约和使用管理，方便学校对基础设施的协调和管理。
5. 网络管理：学校需要建立网络管理系统，包括网络设备的管理和维护、网络安全的监控和防护，保证学校网络的稳定和安全。
三、系统架构设计学校综合管理系统的架构包括前端展示层、中间逻辑层和后端数据层。
前端展示层用于用户界面的展示和交互，中间逻辑层用于处理用户请求和调用后端数据层的接口，后端数据层用于保存数据和提供数据访问接口。
四、系统开发学校综合管理系统的开发可以采用敏捷开发的方式，将系统需求分解为多个小任务，并分别进行开发和测试。
同时，要注重系统的可扩展性和稳定性，避免系统任何一个组件的故障影响整个系统的运行。
五、系统集成与测试在系统开发完成后，需要进行系统的集成和测试。
集成测试可以分为逐层测试和整体测试两个阶段，逐层测试主要测试系统各个组件的功能和稳定性，整体测试主要测试系统在整个流程中的协调性和性能。
六、系统部署与上线完成系统集成和测试后，需要将系统部署到学校的服务器上，并正式上线使用。
在部署过程中要注意系统的安全性和可用性，保证系统能够长期稳定地运行。
七、用户培训与支持对于学校综合管理系统的用户，需要进行培训和支持。
基于MVC模式的企业综合管理系统的设计与实现
基于MVC模式的企业综合管理系统的设计与实现基于MVC（Model-View-Controller）模式的企业综合管理系统（Enterprise Resource Planning System，简称ERP系统）的设计和实现，是一种常见的软件开发方法。
该模式将系统划分为三个主要模块：模型（Model）、视图（View）和控制器（Controller），分别负责处理业务逻辑、用户界面和用户输入。
在设计和实现基于MVC模式的ERP系统时，需要按照以下步骤进行：1.确定系统需求：首先，要明确企业需要综合管理的范围和功能，例如销售、采购、库存、财务、人力资源等。
通过与企业相关部门的沟通，了解业务流程和数据需求。
2.设计模型层：模型层是ERP系统的核心，负责处理数据和业务逻辑。
该层包括数据库设计、数据模型的建立以及业务逻辑的实现。
根据系统需求，将业务数据抽象为实体对象，并建立相应的数据库表结构。
3.设计视图层：视图层负责呈现用户界面和显示数据。
根据业务需求，设计用户界面，包括菜单、表单、报表等。
视图层与模型层通过控制器进行交互，以获取数据并显示给用户。
4.设计控制器层：控制器层负责处理用户输入和业务逻辑的调度，将用户的操作转化为对模型的操作。
根据业务需求，设计相应的业务逻辑，例如数据的增删改查、流程的处理等。
控制器层与视图层和模型层进行交互，以实现用户界面和业务逻辑的整合。
5.实现系统功能：根据模型层、视图层和控制器层的设计，进行具体的编码和实现。
模型层需要实现数据访问和业务逻辑处理的方法，视图层需要实现用户界面的显示和数据的展示，控制器层需要实现用户输入的处理和业务流程的调度。
6. 进行测试和调试：完成系统的编码后，进行测试和调试，确保系统能够正常运行。
测试包括功能测试、性能测试、安全性测试等。
根据测试结果，修复系统中的问题和bug。
7.部署和维护系统：完成测试和调试后，将系统部署到实际运行环境中，并进行系统的维护和更新。
管理系统概要设计说明书
概要设计说明书1.引言1.1编写目的本测量审核信息管理系统项目是设计一个信息平台，方便客户进行测量审核申请和回送请求，方便管理人员进行申请的审核和样品的发送。
本阶段已在系统的需求分析的基础上，对信息管理系统做概要设计。
主要解决了实现该系统需求的程序模块设计问题。
包括如何把该系统划分成若干个模块、决定各个模块之间的接口、模块之间传递的信息，以及数据结构、模块结构的设计等。
在以下的概要设计报告中将对在本阶段中对系统所做的所有概要设计进行详细的说明。
在下一阶段的详细设计中，程序设计员可参考此概要设计报告，在概要设计对信息系统所做的模块结构设计的基础上，对系统进行详细设计。
在以后的软件测试以及软件维护阶段也可参考此说明书，以便于了解在概要设计过程中所完成的各模块设计结构，或在修改时找出在本阶段设计的不足或错误。
1.2项目背景本项目（信息管理系统）是由 XX委托，由 XX 负责开发。
信息管理系统将由两部分组成：置于前台的客户申请程序，以及置于后台管理人员的数据库服务器。
1.3定义1.3.1专门术语SQL SERVER系: 统服务器所使用的数据库管理系统（ DBMS）。
SQL: 一种用于访问查询数据库的语言。
事务流：数据进入模块后可能有多种路径进行处理。
主键：数据库表中的关键域。
值互不相同。
外部主键：数据库表中与其他表主键关联的域。
ROLLBACK: 数据库的错误恢复机制。
1.3.2缩写系统：若未特别指出，统指本信息管理系统。
SQL: Structured Query Language（结构化查询语言）。
ATM: Asynchronous Transfer Mode （异步传输模式）。
1.4参考资料2.任务概述2.1目标2.2运行环境该系统建设信息平台，数据库服务器、应用服务器之间应该通畅可靠。
系统要求可靠、稳定、查询效率高。
操作系统平台： windows2003 、 windows xp 、 win 7数据库平台： sql server 2008开发软件：visual studio 2010运行平台：开发完成将网站放到装有 IIS的服务器上，客户端用 IE 或者其他浏览器即可2.3需求概述为方便客户进行测量审核申请，需要开发一个信息管理系统，客户可以在线查看所有测量仪器的名称及各项参数，在线填写申请表，提交申请，查看自己的账号信息，物流状态。
高校综合管理系统的设计与开发
高校综合管理系统的设计与开发随着高校教育的发展和需求的增加，高校综合管理系统已经成为了大多数高校的必备系统，不仅能更好地协调学校内部的事务，还能够改善办公效率和服务质量。
本文旨在对高校综合管理系统的设计和开发进行探讨。
一、系统需求分析1. 基本功能要求高校综合管理系统需要包括学籍管理、课程安排、教师管理、学生管理、考试管理、成绩管理、图书馆管理、财务管理、资源共享、信息发布等多个子系统。
2. 业务流程分析在需求分析中，需要明确每个子系统的业务流程，如学籍管理包括学生注册、学生信息修改、学籍资料维护等，课程安排包括选课、预约、取消预约等。
在进行业务流程分析时，需要考虑实用性和易操作性，确保系统的可用性和用户体验。
3. 系统安全要求高校综合管理系统中包含大量的学生、教师等重要信息，系统应具备严密的安全机制，确保数据安全、可靠性和完整性。
因此，系统必须设有权限管理、数据备份和安全日志等功能，以保障系统的安全运行。
二、系统设计1. 前端设计系统前端旨在提供简洁、直观、易于操作的用户界面，便于用户获取所需信息。
系统前端设计需要考虑不同终端的适配性，确保用户能够在不同的设备上访问系统，并提供友好的用户体验。
高校综合管理系统的后端设计主要考虑数据管理和业务逻辑，确保系统数据的稳定性和业务逻辑的正确性。
后端需要使用可扩展的框架，如Java、Python等，保证系统具有优异的抗压能力和可扩展性。
三、系统开发高校综合管理系统的开发要注重实际应用和用户需求，保证系统的可用性、可靠性和易用性。
开发中应遵循模块化、标准化、可重用的设计原则，以便扩展和维护。
同时，开发过程中需要严格遵守安全性规范，以确保系统不被黑客攻击或非法入侵。
四、系统测试与维护系统测试是系统开发过程中的重要环节。
通过测试，可以发现系统的缺陷和错误，并及时进行修复。
测试应尽可能多地覆盖不同的场景和用例，确保系统的性能和稳定性。
维护是系统开发的长期过程，系统维护需要根据实际需求和使用情况进行升级、维护和修复，以确保系统的正常运行。
教务管理系统(概要设计及详细设计)
概要设计说明书1。
总体设计1。
1 需求规定教务管理系统可分为学生信息管理系统和教师管理信息系统，系统开发的整体任务是实现学校教师和学生信息管理的系统化、规范化、自动化和智能化，从而达到提高学校管理效率的目的。
本阶段目的在于明确系统的数据结构和软件结构，此外总体设计还将给出内部软件和外部系统部件之间的接口定义，各个软件模块的功能说明，数据结构的细节以及具体的装配要求。
1。
2 运行环境软件基本运行环境为Windows XP环境。
1.3 基本设计概念和处理流程概要说明书的目的在于明确系统的数据结构和软件结构,设计外部软件和内部软件的接口，说明各个软件模块的功能说明，数据结构的细节等.系统的总体处理流程如图1—1所示：图1-1 系统的总体处理流程1.4 系统体系结构用一览表及框图的形式说明本系统的系统元素（各层模块、子程序、公用程序等）的划分，扼要说明每个系统元素的标识符和功能，分层次地给出各元素之间的控制与被控制关系。
教务管理系统选择操作基础维护 教学管理 报表统计选择操作 选择操作班级信息维护课程信息维护 学生选课 课表查询 成绩输入打印成绩单学生信息维护 教师信息维护本系统的体系架构如图1-2所示：图1—2 系统体系架构本系统体系结构大致可以定义为：客户机层上的表示层主要是通过Struts框架实现的，由显示视图产生一个请求。
请求被ActionServlet（控制器）接收，它在struts-config.xml文件中寻找请求的URI，找到对应的Action类后，Action类执行相应的业务逻辑。
Action类执行建立在模型组件基础上的业务逻辑，模型组件是和应用程序关联的。
一旦Action类处理完业务逻辑，它把控制权返回给ActionServlet，Action类提供一个键值作为返回的一部分，它指明了处理的结果。
ActionServlet使用这个键值来决定在什么视图中显示Action的类处理结果.当ActionServlet把Action类的处理结果传送到指定的视图中，请求的过程也就完成了。
概要设计实例
概要设计实例(总26页) -CAL-FENGHAI.-(YICAI)-Company One1-CAL-本页仅作为文档封面，使用请直接删除XXX系统概要设计说明书版本历史目录引言..................................................... 错误!未定义书签。
编写目的............................................. 错误!未定义书签。
项目背景............................................. 错误!未定义书签。
定义................................................. 错误!未定义书签。
参考资料............................................. 错误!未定义书签。
2 总体设计方案.......................................... 错误!未定义书签。
基本设计思想......................................... 错误!未定义书签。
系统整体设计......................................... 错误!未定义书签。
物理部署架构 ....................................... 错误!未定义书签。
系统的层次模型 ....................................... 错误!未定义书签。
创新项目............................................... 错误!未定义书签。
用户管理模块 ......................................... 错误!未定义书签。
系统参数模块 ......................................... 错误!未定义书签。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
综合信息化管理系统概要设计1.概述1.1.编写目的本文档是根据《矾石沟煤矿调研需求说明》内列出的各项功能需求进行全面分析并准确表达出用户的需求。
并且不拘泥与矾石沟煤矿，对大多数煤矿企业具有适应性。
本文档是为了确切地表达出系统的每项需求，并做为设计的基础，为软件设计人员提供明确的指导方向，并为软件的功能测试提供测试依据。
1.2.读者对象本《系统需求说明书》的预期读者是：➢部门经理➢技术部经理➢项目组所有人员➢测试组人员1.3.术语和缩写1.4.参考资料2.应用现状分析：二十世纪九十年代以来，随着以计算机技术为代表的信息技术在企业的经营、管理、设计和制造中得到日益广泛深入的应用，世界煤炭工业的大公司和发达国家的煤炭生产企业在技术发展和自身竞争需求的推动下，迅速由生产过程自动化向企业信息化转变，对扩大经营规模并有效控制经营成本，提升企业的核心竞争力起到巨大的推动作用。
目前，在世界煤炭工业的大公司和发达国家的煤炭生产企业中，企业信息化水平已经达到相当高的程度。
通过企业信息化建设，改进了企业的生产工艺和流程，极大地提高了生产效率，为企业生产经营中的信息获取、存储、处理、传输等创造了条件，为企业扩大经营并有效控制经营成本提供了有力的技术手段。
我国煤炭企业的信息化建设起步并不晚，但信息化水平与其他行业相比相对较低。
企业信息化系统的开发和应用绝大部分任然停留在重复的单项开发和单项应用的水平上，形成了一个个的“信息孤岛”；部分企业建立了计算机网络，但大多数也只是空网，没有充分发挥其效用，即使有部分应用也是各自独立，各子系统之间没有共享数据。
目前，很少有煤炭企业建成完善的管理信息系统，只有少数企业初步实现了基本的应用系统集成，建成了管理信息系统雏形。
3.系统业务流程分析3.1.组织机构3.1.1.部门管理部门基础信息注册，树形结构维护。
3.1.2.管理岗位职位信息注册，职能描述。
3.1.3.人员信息登记人员基础信息维护，属性根据各系统内容增加。
3.2.权限管理3.2.1.系统权限设置可以根据一定的代码规则，设置权限，为系统添加需要控制的权限集。
这部分主要为了提高开发效率，是在程序开发完成后对系统进行权限定义，由程序员开发和管理。
1、设置权限对象可以根据系统设置权限对象，用来对系统所有的权限功能进行描述和管理。
2、设置对象的所有操作权限，用来添加对象的管理。
3、对这些权限对象进行维护，使其能够满足系统新开发要求。
3.2.2.定义权限集可以定义权限集，做为一些权限的集合，用于方便授权。
3.2.3.权限授予1、可以直接授予某个人一些权限。
2、可以授予某个人一些权限集。
3、可以授予某个部门一些权限集，用于其部门人员直接继承。
3.2.4.业务实现方式3.3.审批流程3.3.1.审批流程管理自定义审批流程，对审批流程进行管理。
流程设计可分为两部分：一、开发人员使用复杂表单审批（带有特定表数据，如：采购计划，等属于特定系统的表有联系）：1、开发人员根据需要定义一个流程，流程完成后提供其启动方法，使开发人员可以后台调用方法启动该流程。
流程启动方法要可以和待审批的对象数据进行关联，以便流程完成后能够修改标识，证明申请是否通过了审核。
（如：StarProcess(流程ID，对象名称，对像ID，状态属性)可以用这个方法启动）2、流程完成后，根据启动方法提供的信息，改变对象的状态属性值，要在申请人登录时给予提示，查阅过后，停止提示。
二、开发人员使用简单流程审批（不是特定系统表内容，如文件审批，资料上传审批等只提供附件…）：流程生成后可以自动返回入口地址的链接，开发人员将其设定到特定位置使用。
用于程序开发过程中流程已定的审批过程。
三、用户自定义流程：用户自定义流程后可以放到开发预留位置，用户自由使用。
3.3.2.审批者定义1、特定人员：审批流程指定到具体人员。
2、指定人员范围：流程设定时，由于申请人员不同，下一审批人员不固定，可能是一个或多个人时，可以预定义一个该审批节点的人员范围，让申请人到时自行选择。
3、绝对岗位：把审批节点的审批权限指定到某个特定岗位上（岗位是唯一的），该审批权限根据岗位显示，而与该岗位的人不绑定。
4、相对岗位：相对岗位也就是相对于某个(些)人员的上级岗位。
比如部门经理就是一个相对岗位，如果有三个部门就会有三个部门经理，他们只管辖自己的部门。
当不同的部门人员提出申请时，其对应的部门经理是不同的，这就是相对岗位的用法。
3.3.3.审批流程分析一、审批流程设计要求1、审批流程采用统一独立架构，需要审批的单据与通用架构挂接2、审批针对单据，不针对单据的行3、审批主表记录审批对应的单据ID、所处步骤、最后一次审批时间、待审批有效期、是否完成等等4、审批明细表记录每次审批对应ID、所处步骤、审批人、审批时间、审批意见等5、审批设置表设置每一审批步骤涉及的角色、审批有效期、审批跳转、否决跳转、超期跳转等6、审批校验表防止管理员直接从后台修改审批记录二、审批流程的步骤1、每个审批流程可以设置任意多个步骤。
2、步骤的编号不代表次序，可随意跳转。
3、每一步骤可设置有效期，按天计算，也可以不设。
4、每个步骤有3个响应机制：批准、退回、超时，三种情况分别设置跳转至下一步的步骤编号。
5、最后一步设置完成标志。
三、审批动作1、审批动作有3种：通过、退回与取消2、动作编号1~49表示通过，可根据需要任意设置名称，如“同意”、“批准”、“已办理”、“已付款”等等。
3、动作编号50~99表示退回，可根据需要任意设置名称，如“不同意”、“退回”、“否决”等等。
4、动作编号100表示作废，申请被作废后不能修改，也不能做其它操作。
5、每个审批界面，可以分别选取部分审批动作供用户选择。
6、动作编号101代表超时响应，由系统自动处理。
四、审批与授权1、只有经过授权，用户才可以进行审批操作2、授权有三要素，只取其一，不叠加。
按优先顺序排列分别是：项目、组织（部门）、角色。
3、用户被授予某个项目，即具有该项目的审批权；被授予某个组织，即具有该组织的审批权；被授予某个角色，即拥有该角色的权限。
4、每个用户只属于一个部门，但可以管辖多个部门与多个项目，拥有多个角色。
用户属于的部门与被授予的部门是完全不同的两个概念。
5、组织是分级的，除最高级别为公司（法人）外，其余组织都有其上级部门。
6、项目只有一级，但项目归属于某一组织，可以为某级部门，也可以是公司级。
五、审批流程的类型审批流程类型可定义，可按类型维护审批流程。
1、审批流程分为三个类型：普通型、委托代办型、项目型2、普通型按申请人所属部门，逐级向上审批。
3、委托代办型先经过申请人所属部门，然后按委托部门，逐级向上审批。
4、项目型先经过项目负责人，再按项目所属部门，逐级向上审批。
六、审批流程的跳转方式1、跳转方式分为两种：指定跳转、弹性跳转2、指定跳转即明确指明下一步的步骤编号，比如在第2步上，设置通过后跳转至第3步，退回则跳转至第0步（未提交状态）。
3、弹性跳转更为灵活，可以根据不同条件设置不同的跳转步骤。
七、关于逐级审批的处理1、每一审批步骤都可以设置部门级别2、逐级审批所处的部门级别，如果高于审批步骤设置的级别，则自动跳过，如果低于，则依次补足。
3、例：某公司财务部下设会计部、成本部、IT部三个部门，公司为1级，财务部为2级，成本部为3级。
人力资源部为2级，未设下级部门。
设置的审批步骤为：第一步级别为3级，第二步级别为2级，第三步级别为1级。
则成本部职员甲的报销申请，第一步正好是3级；人力资源部职员乙的报销申请，则自动跳过第一步，直接进入第二步。
如果某员工处于第4级部门，则经过第一步时，自动补上所属第4级部门的审批流程，然后再到第3级部门审批，一步经过两级部门。
4、流程设定审批的相对职位和绝对职位。
八、会签1、会签指的是在同一审批步骤上，有多个角色或部门，必须全部签署才能通过，但签署没有先后次序要求。
2、会签的多个角色或部门，跳转设置必须相同，系统将取最后一个签署的跳转设置为默认跳转方式。
3.4.票据管理3.4.1.票据定义1.票据类别：（1）增加票据类型：对新印制的票据进行票据类型添加（2）删除票据类型：对已不再用的票据进行票据类型删除（删除时要备份以前票据的数据信息，删除其对应的票据属性）（3）修改票据类型：修改已有票据类型名称（4）票据查找：建立票据属性、票据表时使用2.票据属性：（5）增加票据属性：对票据要记录的属性进行添加，（6）删除票据属性：对不需要记录的票据属性进行删除（7）修改票据属性：对已有票据的属性进行票据修改（8）查询票据属性：对已有票据属性进行查找3.4.2.票据发放票据流通包括票据填写，票据在各部门的审核到票据的最终处理结果。
1.票据的下发和领取煤炭销售票的下发，领取确认后，才可以发放出去，2.出票票据发放，是对开据票据的电子版记录。
是票据流通的起始点。
3.收票票据在各部门对票据的内容审核，部门留存票据的其中一联。
3.4.3.票据核查1.查询：按票据单号查询票据状态、最后处理结果；按操作者（部门）查询审批中的票据；按某一条件查询所有符合条件的票据。
转到查询页面。
Eg：通过操作者、时间、票据种类等条件查询，查看一天内发送了运煤单。
2.统计：统计某一操作者（部门）一定时期内，经手的票据量，金额总值与实际金额比较。
3.4.4.权限管理对票据种类的建立，票据的发放，票据流通，票据校核以及查看都需要各自不同的操作权限。
与人员模块连接。
3.5.人力资源管理3.5.1.人事管理一、在职人员1、部门树级管理，所有级别可自由添加。
2、人员可拖动修改部门，人员属性可自由添加，查询条件可自由组合，级别下内容可自由添加。
现只记录几个基本属性：职工代码，、、部门、职称、职务、学历（第一学历、最高学历）。
二、死亡人员1、退休死亡——>通知工会(上系统后，自动处理，不用通知)2、工作死亡，相应通知家属及善后工作，见取回资料三、终止合同签定协议终止合同、终止再续四、退休管理人事部通知到可退休人员——相关人员提出审请（，书面审请）——人事部添写相关表格内容——劳动局——退休批准。
退休工资在养老保险内容中。
员工信息维护：3.5.2.薪资管理薪资核算公式定义，公式与部门人员绑定，各部门有独立的薪资核算方式，职位的独立核算方式，及核算后的调整。
3.5.3.招聘管理空缺职位人才招聘一般过程及简历管理（与档案管理有联系）。
3.5.4.培训管理培训管理主要制定配训计划，计划中包括培训的主要内容、目标人群等详见取回的相关资料，另一部分培训为上级下达的培训通知.。
一、自定培训一般培训管理培训需求提出，审批，培训计划制定，人员安排，培训过程跟踪，考核结束，培训成绩录入，培训反馈。