项目名称：财务管理系统（OA）
项目介绍
该项目是一个OA系统，第二版本改为SAAS系统。主要用于公司经费的申请，将线下的流程变为线上。减低企业成本。打个比方说
A用户请假：
线下情况：A用户拿请假单，A用户去找领导申请，发现领导不在，走不了,这下就麻烦了
线上情况：A用户线上申请，领导收到通知，同意申请。
一 项目框架搭建
spring+springMVC+mybaties+activiti+mysql+maven+redis+前端（easyui）
二 技术选型
spring+springMVC的好处：
- springMVC的结构层次分明：视图，模型，控制器
- Spring MVC非侵入性特征：业务逻辑代码与框架本身是相分离
- 控制反转：松耦合,对象依赖的其它对象会通过被动的方式传递进来，而不是这个对象自己创建或者查找依赖对象（尽量使用组合，少使用继承）.
- AOP: 允许通过分离应用的业务逻辑与系统级服务（如：事务管理，缓存，操作日志）进行内聚性的开发。
- 轻量级开发框架
- 可定制的handler mapping和view resolution：Spring提供从最简单的URL映射，到复杂的、专用的定制策略。
- 可定制的绑定(binding)和验证(validation):比如将类型不匹配作为应用级的验证错误，这可以保证错误的值。再比如本地化的日期和数字绑定等等。
- 强大而直接的配置方式：将框架类和应用程序类都能作为JavaBean配置，支持跨多个context的引用，例如，在web控制器中对业务对象和验证器validator)的引用。
MyBatis
- 代码松耦合，简快开发难度。
- 小巧并且简单易学，减低开发成本。
- 灵活，不会对应用程序或者数据库的现有设计强加任何影响，SQL写在XML里，从程序代码中彻底分离，降低耦合度，便于统一管理和优化，并可重用。
- 提供映射标签，支持对象与数据库的ORM字段关系映射,功能丰富，可以满足企业开发复杂设计。
- 提供XML标签，支持编写动态SQL语句。
是一个灵活的DAO层解决方案。对性能的要求很高，或者需求变化较多的项目，如互联网项目，MyBatis将是不错的选择。
maven
- jar 包管理，防止jar之间依赖起冲突
- 使用私有服务器，统一开发jar包，防止版本冲突和避免从中央服务器下载。
- 方便管理项目报告，生成站点，管理JAR文件，等等。例如：项目开发中第三方jar引用的问题，开发过程中合作成员引用的jar版本可能不同，还有可能重复引用相同jar的不同版本，使用maven关联jar就可以配置引用jar的版本，避免冲突。
- Maven会自动将你要加入到项目中的jar包导入，不仅导入，而且还会将该jar包所依赖的jar包都自动导入进来。
- 借助Maven可以以规范的方式下载jar包，因为所有的知名框架或第三方工具的jar包已经按照统一的规范存放到了Maven的中央仓库中。
- 可借助Maven将一个项目拆分成多个工程，利于分工协作。而且模块之间还是可以发送消息的。
activiti
- 原生支持spring
- 支持分离运行时和历史数据
- 数据持久化(mybatis)
- 更好的业务过程控制
- 学习成本低，各种资料丰富，是主流的流程框架
- 免费开源
MySQL
- 可以处理拥有上千万条记录的大型数据；
- 支持常见的SQL语句规范；
- 可移植行高，安装简单小巧；
- 良好的运行效率，有丰富信息的网络支持；
- 调试、管理，优化简单（相对其他大型数据库）
- 本人有MySQL集群和主从设计经验,以及表设计，索引设计，分区设计，搜索引擎选择经验
redis
当初设计的时候有2重方案，redis和memcached，最终选出redis，是因为对比功能发现memcached是redis的子集，而且redis是内存数据库，访问速度非常快，而且本人也有reidis集群和主从设计经验。
优点
- 速度快，读写性能优异,因为数据存在内存中，类似于HashMap，HashMap的优势就是查找和操作的时间复杂度都是O(1)
- 支持丰富数据类型，支持string，list，set，sorted set，hash
- 支持事务，操作都是原子性
- 丰富的特性：可用于缓存，消息，按key设置过期时间，过期后将会自动删除
- 支持数据持久化，支持AOF和RDB两种持久化方式
- 支持主从复制，主机会自动将数据同步到从机，可以进行读写分离。
easyui
- 快速开发，减少项目的开发周期，从而节省项目成本
- 功能丰富和强大
- 网络上的学习资源多，社区活跃
- 非常适合进行web的快速开发
三 在项目中责任
01 项目整体构建和对项目规划的技术选型
技术选型略过（上面已经讲了），主要j将项目的整体构建
层次结构
aop（系统级服务：作用分离应用的业务逻辑与系统级服务）
举例：操作日志的纪录
core（后改为分布式模块开发）
bean（ 类的基本属性,扩展属性放到query中）
controller（action层,调用service,控制url的访问）
dao（底层数据访问接口）
query（查询对象，相当于对bean的扩展,比如对象的序列化和分页）
service（服务，事务的控制,调用的是dao层，后期改为调用bll层）
(后期添加bll层,多个dao的组合功能的接口，service不调用dao,而是调用bll，好处是功能和事务分离，提高接口的重用性和灵活性)
common
工具类
项目初始化类
公共服务（如消息推送,文档在线预览,文件上传和下载,任务调度，流程公共接口等）
exception（如数据访问层异常处理,自定义异常等）
interceptor（包含所有拦截器的设计，比如用户登录拦截器，流程处理器拦截器,js和静态资源的拦截器（url拦截器））
plugin（插件的管理：如分页插件）
resourceView（自定义视图解析器）
web（对web操作的工具类管理和session的管理）
02 项目的进度把控（个人认为这是最重要的）
- 产品原型设计（集团提供），需求文档编写，开需求会议，立项文档确认
- 文档编写：和需求人员一起明确确定
- 需求会议：明确需求对应的功能，功能对应的表结构设计，以及提供开发周期预估
- 影响项目进度的因素及解决办法
- 不断有新需求插入
- 01确定产品的方向：如果不明确产品的方向，会导致数据库表结构的大改动。
- 案例：用户职位设计
- 最初我们设计是一个用户表，一个员工表（职位），一个部门表，当时没有考虑到流程导致流程开发阶段需要对表结构进行改动
- 后来设计：用户表，部门表，用户部门关系（实际职位，流程执行）
- 表结构的改动是影响是最大的，因为这次改动，我们花了一周实际去修改代码和重新测试，相当于浪费了一周时间
- 版本控制
- ceo版本上面急功近利，在版本管理期间添加需求进来，这个时候你一定要认真估算新需求的时间，对于不影响进度的可以适当添加进来，如果是重大改动的,预估时间解决不了的一定需要提出来，一起开个会，明确造成的影响，怎么解决方案（招人，外包，延迟开发时间），如果实在这个版本解决不了，那么只能放到下一个版本中。
- 不断调整需求逻辑
- 这种情况我们遇到过，这是产品经理没有理清需求造成的，找出的后果就是 开发和测试感觉自己好忙、好累、疲于应对开发中出现的各种问题。
- 解决方法：对产品一定要认真分析，不断和对方沟通，明确各个细节，提出各种问题出来。最后最重要的是立项文档确认后发邮件给双方一起确定方案。规划书一起签字明确功能和版本周期。这样即使后期对方要改动，责任明确，不会造成责任迷糊，双方推卸责任
- 开发阶段：这个时候需求，产品已经明确了，这个时候只需要认真把控版本进度（不考虑人员离职问题）
- 每天早上跟进项目进度。
- 多鼓励队伍成员。
- 对于队伍中能力差的成员，多次鼓励，帮他（她）想些方法，莫要责备，责备可能会打击成员积极性，情况循环恶劣， 我队伍中就有这么一个人，早上汇报进度的时候，他不说话，要么就是左右言你，当时我就生气了，直接责备，后来他离职了。
03 项目的表设计
因为内容太多，直接放到下面将
四 表的设计（只涉及一些关键字段）
01系统模块
用户模块
userInfo：用户表
- UserID：用户id, 主键自增长
- LoginID：账号, 登录使用
- Password：密码, 登录使用
- CreateBy：创建者id, 用于操作记录
- CreateDate：创建日期, 用于操作记录
- ModifyDate：修改日期, 用于操作记录
- ModifyBy：修改者id , 用于操作记录
loginlog：登录日志表（后期不用，日志直接写在日志文件中）
功能：用于记录登录日志
- ID ,主键自增长
- UserID ,用户id,记录谁登录
- LoginIP , 登录IP,记录登录的客户端
- LoginTime , 登录时间,记录登录的客户端时间
loginStatus:登录状态表（后期没用，后期使用redis来保存用户的会话，key为登录的cookie+UserID）
- UserID : 用户id
- LoginTime : 登录时间
- LoginState: 登录状态
- LastUpdateTime : 最近登录时间
- LoginIP : 登录ip
- SessionID : 用户sessionID
功能：当用户A在c1客户端登录时候，同时用户A在c2客户端登录,提示c1客户端，你已经在别的地方登录，并强制跳转登录页面
客户端：相同IP
相同浏览器
不同浏览器
不同IP
实现：c2登录，判断UserID对应的纪录LoginState是否为登录，
是：
判断IP是否相同：
是：
判断浏览器是否相同：
是：提示c2客户端，用户已经登录，禁止c2登录
否：c2登录，修改UserID的LoginState=false,并新增一条纪录否：
否：新增一条纪录
如果是修改false，并新增一条纪录，
拦截器实现：任何.do的url请求，都去判断下对应sessionID和IP的LoginState是否为false,是的话直接跳转登录页面userCompanyManager ：用户组织表
ID ：主键ID
UserID ：用户id
CompanyID ：公司ID
userinfoDepartmentInfo ：用户部门职位表
UserID ：用户id
PositionID ： 流程职位ID
PositionTrueID ：职位真实ID
DepartmentID ：部门id
userPasswordHistory ：用户历史密码表
ID ：id
UserID ：用户id
Password ：登录密码
部门模块
departMent:部门表
功能：部门是一颗树结构
DepartmentID：部门id
ParentID：部门父id
DepartmentType：节点类型（一级部门，二级部门）
FullDepartmentName：部门全称
PrivilegeID2：权限id(部门的操作权限ID)
PrivilegeID：权限id(部门的查看权限ID)
DepartmentCode：部门编码
DepartmentNameAbbreviation：部门名称缩写
DepartmentType2：所属类型(如：如果该部门是二级部门，该所属类型是一级部门)
DepartmentNode：节点属性（open,closed）
departMentDepartmentNameRelation :部门与部门名称关系表（相当于部门的数据字典）
功能：维护部门名称和部门编码的一一对应关系
ID ：主键自增长
DepartmentName：部门名称（会有一个对应的编码）
DepartmentCode：部门编码
DepartmentType：所属类型
菜单模块
menu：菜单表
MenuID：菜单id
Title：标题
ParentID：父id
PageUrl：页面url
Sequence：显示顺序
IsLeaf：叶子节点0否1是
IconName：图标
PrivilegeID：权限id
功能：显示用户的左侧菜单，树结构
功能模块
sysFunction： 功能表（关联菜单表）
FunctionID：功能id
Name：功能名称
MenuID：菜单id
IsActive：是否有用0否1是
PrivilegeID：权限id
Sequence：显示序列
功能：显示菜单下的功能, 设置某些页面的操作功能权限,打个比方说，A用户在用户管理页面有删除用户功能，B用户没有
角色模块
sysRole:系统角色表
ID : 主键自增长
RoleID：角色id
RoleName：角色名称
IsActive：是否有用0否1是
提供给用户设置角色，和部门职位不挂钩，方便灵活给用户配置权限
科目模块
account:科目表
AccountID：科目id
ParentID：科目父id
AccountName：科目名称
FullAccountName：科目全称
IsActive：是否激活 0不激活，1激活
IsDelete：是否删除 0没删除，1删除
PrivilegeID2：权限id(操作权限,判断用户是否可以操作对应的科目的数据)
PrivilegeID：权限ID(查看权限,判断用户是否可以查看对应的科目的数据)
AccountType：科目级别
功能：显示科目
权限模块
privilege：权限表
PrivilegeID：权限id，主键自增长
Type：权限类型
功能：记录权限ID的自增长userPrivilegeTemp ：用户权限临时表
UserID：用户id 主键
PrivilegeID：权限id 主键
功能：记录用户登录后的，获取的用户权限全部放到这个表里。当用户再次获取权限的时候直接从这个表获取userRole ：用户角色表
UserID：用户id ，主键
RoleID：用户角色id，主键
功能：记录用户和角色的关联关系excludePrivilege ：禁止权限表
UserID：用户id，主键
PrivilegeID：权限id，主键
功能：记录用户不能使用的权限extraPrivilege ：额外权限表
UserID：用户id，主键
PrivilegeID：权限id，主键
功能：记录用户一般权限
rolePrivilege ：角色权限表
RoleID：角色id，主键
PrivilegeID：权限id，主键
功能：记录角色对应的权限
数据字典模块
datadictionarymain ：数据字典主表
GroupID：组ID 主键,自增长
Title：数据字典名称
datadictionarydetail ：数据字典明细表
ItemID：数据字典明细ID,主键,自增长
Value：数据字典明细值
Sequence：序号，排序使用
Param：参数(参数是json类型)
GroupID：组ID
流程模块
flowTask ：流程记录表，记录流程的每个操作
ID ：主键ID
taskID ：任务ID，
taskDefinitionKey ： 任务节点
assignee ：当前审批人，
operationDepartID ： 操作部门ID
positionID ：流程职位id
positionTrueID ： 真实职位ID
createTime ：流程审批时间
state ：审批意见
comment ： 审批备注
proceedingApplicationMainID ：被审批的申请单主表ID
flowType ：流程类型
companyID ：操作人公司id
processInstanceId ：流程实例ID
executionId ：流程执行ID
processDefinitionId ：流程定义ID
nextTaskDefinitionKey ：下一个任务节点
wf_hi_rejectrecord ：多级驳回记录表
ID ：主键ID
fromTaskID ：驳回人任务ID
toTaskID ：被驳回人重新提交的任务ID
fromTaskDefinitionKey ：驳回人节点
toTaskDefinitionKey ：被驳回人节点
fromAssignee ：驳回人
toAssignee ：被驳回人
rejectTime ：驳回时间
resubmitTime ：被驳回人重新提交时间
rejectIsDone ：驳回是否处理（默认处理：1，未处理0），针对连续驳回设计
processInstanceId ：流程实例ID
executionId ：流程执行ID
processDefinitionId ：流程定义ID
proceedingApplicationMainID ：申请单主表ID
功能： A -->B---C--D--E，当E驳回给C，C驳回给A，A重新提交，直接提交给C，C提交直接给E
实现：当前提交时同意：通过processDefinitionId和rejectIsDone=0查看是否有记录，有就获取最后一条U，更新U.rejectIsDone=1,流程跳到给节点
autoApprove ：记录自动审批信息
ID ：主键自增长
Message：批注
UserID：用户ID
TaskDefinitionKey：任务节点ID
ProcessInstanceId：流程实例ID
功能：记录正在审批的流程的自动审批情.
实现:
同意审批：如果流程实例ID和任务节点ID，查看是否有对应的纪录，有：copy该记录作为新增记录，没有就新增记录，
驳回审批：删除流程实例ID对应的所有记录
流程审批结束：删除流程实例ID对应的所有记录
flowParam ：流程参数表
Id：主键自增长
ProceedingApplicationMainID：申请单主表（ProceedingApplication）的ID
ClassName：申请单的对应的类名
OperationUserID：申请单对应的操作人ID
ApplicationPeopleID：申请单对应的申请人ID
OperationDepartmentID：申请单对应的操作人的部门ID
ApplicationDepartmentID：申请单对应的申请人的部门ID
FlowType：流程类型
FlowParams：流程非开始节点的参数，按照map的json方式存储
StartParams：流程开始节点的参数
DynamicParams：动态参数，按照map的json方式存储：非流程)
ProcessInstanceId：流程实例ID
Version：版本号，每次重新提交，修改流程参数的时候，版本号+1，流程参数的获取是最新版本参数功能：记录流程在审批过程中，动态修改的流程参数。
实现：只记录正在执行的流程参数，当流程执行完，删除该记录，并将该记录放到flowParamHistory。
将数据分为活跃数据和不活跃数据。
flowParamHistory ：流程参数历史表
Id：流程参数id
ProceedingApplicationMainID：申请单主表ProceedingApplication的的ID
ClassName：申请单的对应的类名
OperationUserID：申请单对应的操作人ID
ApplicationPeopleID：申请单对应的申请人ID
OperationDepartmentID：申请单对应的操作人的部门ID
ApplicationDepartmentID：申请单对应的申请人的部门ID
FlowType：流程类型
FlowParams：流程非开始节点的参数，按照map的json方式存储
StartParams：流程开始节点的参数
DynamicParams：动态参数，按照map的json方式存储：非流程)
ProcessInstanceId：流程实例ID
Version：版本号，每次重新提交，修改流程的时候，版本号+1，流程参数的获取是最新版本参数
ProcessID：流程ID
以下是流程设计的主要表：
审批关系：审批是按部门和部门流程职位来
打个比方说：差旅费申请流程
部门申请--》部门负责人（流程职位）---》财务专员---》财务主管。
设计的好处：审批不需要指定的人，只要指定部门流程职位的人，这样当相应部门负责人离职的，流程审批不需要改动下面五个表的关系：
- 1 通过Type和DepartmentID在processDepartmentRelate表中找到唯一一条ProcessID
- 2 ProcessID在processy，processProcessOrganizationMainRelate的关联表可以获取唯一一条ProcessProcessOrganizationMainRelateID
- 3 ProcessProcessOrganizationMainRelateID在processOrganizationmain,processOrganizationDetail关联出流程组织树
这个是当初和技术总监一起商量的，我的当初的设计是3个表
流程与部门的关联表（通过Type，DepartmentID，确定ProcessID），Process表（ProcessID），流程组织树表（ProcessID，主键ID，部门ID）
后来不知道怎么变成5个表，但是这样的设计是讨论后确定(分析方向在灵活性方面,具体的我就忘了)
案例
ProcessID=1对应的流程组织树
12
11
6（审批部门的部门ID）
2（申请部门的部门ID）
1
5
4
processDepartmentRelate ：流程与部门的关联表
ProcessDepartmentRelateID：流程与系统组织的关联表ID，主键
ProcessID：流程id
Type ：类型
DepartmentID ：部门id
process ：流程表
ProcessID：流程id(主键自增长)
Type：流程类型
Name：流程名称processProcessOrganizationMainRelate ：流程与流程组织主表的关联表
ProcessProcessOrganizationMainRelateID：主键
ProcessID：流程id
ProcessOrganizationMainID：流程组织主表id
processOrganizationmain ：流程组织主表
ProcessOrganizationMainID：流程组织主表id
Name：名称processOrganizationDetail ：流程组织明细表
ID：主键id
ProcessOrganizationMainID：流程组织主表id
ParentID：父id
ProcessOrganizationDetailID：流程组织明细id
Remarks：备注
消息模块
unReadMessage ：未读的消息表
MessageID：消息ID
FromUserID：消息源
ToUserID：消息目的地
MessageTitle：消息标题
MessageContent：消息内容
MessageType：消息类型?
IsRead：是否读过：（1是，0否）
ReadDate：读消息的时间
IsSend：是否发送过（1是，0否）
CompanyID：公司ID
messageHistory ：消息历史表
MessageID：消息ID
FromUserID：消息源
ToUserID：消息目的地
MessageTitle：消息标题
MessageContent：消息内容
MessageType：消息类型
CreateDate：创建日期
ReadDate：读消息的时间
DeleteDate：删除日期
CompanyID：公司ID
readMessage ：已读消息表
MessageID：消息ID
FromUserID：消息源
ToUserID：消息目的地
MessageTitle：消息标题
MessageContent：消息内容
MessageType：消息类型
CreateDate：创建日期
CompanyID：公司ID
ReadDate：读消息的时间userMessage ：用户消息表
UserID：用户ID 主键
NewMessage：是否发生消息（1发送，0不发送）
Remark：备注
CompanyID：公司ID
功能：用户向客户端发送消息
发生消息的时候：往这个用户消息表新增（没有对应的UserID）或者修改（有对应的UserID）一条记录,NewMessage=0
循环访问这个表，当UserID对应的NewMessage=0时，unReadMessage表ToUserID=UserID，IsSend=0的所有记录发送给客户端用户（前端页面循环访问）,
并修改unReadMessage表ToUserID=UserID的IsSend=0
附件模块
fileUpload ：附件上传表
ID ：主键自增长
UploadNO：上传批次号
FileID：文件id
UploadFileName：上传文件名
UploadDate：上传日期
FileType：文件类型
SavePath：保存路径
FileSuffix：文件后缀
Sequence：排序
fileUploadTemp ：附件上传临时表
ID：主键自增长
FileID：文件ID
CreateDate：创建时间
SavePath：保存路径
Size：文件大小
ErrorCount：文件转换错误次数
ErrorMessage：失败消息（json,key=消息内容，value=失败次数）
功能：用于附件上传后的在线预览的转换（队列形式转换上传附件，转换成功就从该表删除，转换失败）
02业务模块（只列一小部分）
activityScheme ：活动方案表
ID ：主键
ActivitySchemeID ：活动方案ID
MakeActivityPeople ：经办人
MakeActivityPeopleID ：经办人ID
SchemeName ：方案名称
ActivityDate ：活动时间
ActivityContent ：活动内容
SumPeople ：多少人
Remarks ：备注
FileID ：文件ID
ActivityScope ：动活范围
Money ：金额
AccountID ：科目ID
ResidueBudget ：剩余预算
applicationBuy ：申购表
ID ：主键
ApplicationBuyID ：申购ID
ProceedingName ：事项名称
ProceedingType ：事项类别
UseTime ：使用时间
State ：状态
Remarks ：备注
Money ：金额
IsBorrow ：是否借款：1是0否)
AccountID ：科目ID
ResidueBudget ：剩余预算applicationBuydetail ：申购单物品明细表
ID ：主键
ApplicationBuyDetailID ：申购单物品明细ID
ApplicationBuyID ：申购申请表ID
ItemID ：物品编码
Name ：物品名称
ModelNumber ：型号
Price ：单价
Number ：数量
Money ：礼品金额
Purpose ：用途
Remarks ：备注
DetailSupplierID ：申购单物品明细与供应商关联IDapplicationBuySupplierRelation ：申购单物品明细与供应商表
ID 主键
ApplicationBuyID ：申购申请表ID
ItemID ：物品ID
SupplierID ：供应商ID
SupplierCode ：供应商编码
IsChoose ：是否选择（0：否，1：是）
ItemInformation ：商品信息
Link ：商品链接
Superiority ：优势
Price ：单价
DetailSupplierID ：申购单物品明细与供应商关联IDBankAccount ：银行账户表
ID ：主键
BankAccount ：账号
Payee ：账号对应的单位
DepositBank ：开户行
BankAccountType ：账户类型
IsActive ：是否激活 0不激活，1激活
IsDelete ：是否删除 0没删除，1删除
CreateDate ：创建者日期
CreateBy ：创建者id
ModifyDate ：修改日期
ModifyBy ：修改者id
Remarks ：备注
CompanyID ：公司ID
BankAccountUnitID ：账号对应的单位ID,可以是用户ID，公司名称，银行名称
borrowMoneyApplication ：借款申请表
ID ：主键
BorrowMoneyApplicationID ：借款申请表ID
BorrowMoneyType ：借款类型
RepaymentDate ：还款日期
GatheringType ：收款方式
GatheringAccount ：收款账号
Remarks ：备注
ProceedingApplicationID ：事项申请ID
Money ：金额
ProceedingID ：申请编码
AccountID ：科目ID
ResidueBudget ：剩余预算businessEntertainment ：业务招待表
ID ：主键
BusinessEntertainmentID ：业务招待表ID
BusinessEntertainmentDate ：日期
CountPeople ：人数
BusinessEntertainmentType ：招待的单位或职位
StandardMoney ：招待标准：每人)
BusinessEntertainmentAddr ：招待地址
Remarks ：备注
Money ：金额
AccountID ：科目ID
ResidueBudget ：剩余预算
cashier ：出纳表
ID ：主键
SqNumbers ：申请单编码
ReimbursementID ：费用报销编码
AccountID ：科目id
ProceedingType ：事项类型
Money ：金额
DepartmentID ：部门ID
ApplicationPeopleID ：申请人ID
ApplicationDate ：资金申请时间
State ：状态： 0未申请，1申请中，2审批中,3拒单，4通过')
CompleteTime ：完成时间
PositionID ：流程职位ID
CompanyID ：公司ID
ResidueBudget ：剩余预算
ReimbursementMoney ：报销金额
ReimbursementDate ：报销日期
PaymentBankID ：付款银行ID
ProceedingExplain ：摘要说明
Remarks ：备注
GatheringAccount ：收款账号compact ：合同表
ID ：主键
CompactID ：合同ID
CompactName ：合同名称
CompactType ：合同类别
CompactNum ：同合编号
ACompanyName ：甲方公司名称
BCompanyName ：乙方公司名称
ThirdCompanyName ：第三方公司名称
CompactMoney ：合同价款
IsTaxAfter ：是否含税：1是0否)
IsBudget ：是否在预算内：1是0否)
PayType ：支付方式
IsInvoice ：是否提供发票：1是0否)
CompactBeginTime ：合同起始日期
CompactEndTime ：合同失效日期
FileID ：文件ID
Remarks ：备注
Money ：金额
AccountID ：科目ID
ResidueBudget ：剩余预算costdetails ：费用明细表
ID ：主键ID
CostdetailsID ：费用明细ID
ProceedingID ：申请编码
Type ：事项
StartAndEndTime ：起止时间
StartAndEndLocation ：起止地点
Money ：金额
Remarks varchar：2000) DEFAULT NULL,
StartAddress ：起点
EndAddress ：终点
TravelTools ：出行工具
gift ：礼品
ID ：主键
GiftId ：礼品ID
WinItemID ：获奖礼品表ID
ItemID ：物品编码
GiftName ：礼品名称
Unit ：单位
UnitPrice ：单价
GiftMoney ：礼品金额
GiftNum ：数量
Purpose ：用途
ModelNumber ：型号
Remarks ：备注groupBuild ：团建表
ID ：主键
GroupBuildID ：团建表ID
SumPeople ：参与人数
LeaderID ：参与领导的ID
ActivityDate ：活动时间
ActivityAddr ：活动地址
Reason ：存在的问题原因分析
Question ：存在的问题
Content ：活动举办的形式及内容
Purpose ：活动的目的
HowTodoFromPurpose ：如何确保活动达成目的
HowTodoFromAssess ：如何进行可量化、可衡量之有效评估
Money ：金额
AccountID ：科目ID
ResidueBudget ：剩余预算item ：物品
ID ：主键
ItemID ：物品编码
SupplierID ：供应商编码
Name ：物品名称
ModelNumber ：型号
Price ：单价
IsActice ：是否激活（1是0否）
IsDelete ：是否删除（1是0否）
Remarks ：备注
CreateBY ：创建者
CreateDate ：创建日期
ModifyDate ：修改日期
ModifyBy ：修改者itemSupplierRelation ：物品表与供应商的关联表
ID 主键
ItemID ：供应商编码
SupplierID ：供应商编码
ItemInformation ：商品信息
Link ：商品链接
Superiority ：优势mbudget ：月预算费用表
MBudgetID ：预算费用id
DepartmentID ：部门id
AccountID ：科目id
Remarks ：备注
MonthMoney ：月预算金额
Month ：x月的预算
Year ：x年的预算
CreateDate ：创建日期
CreateBy ：创建者id
ModifyDate ：修改日期
ModifyBy ：修改者id
CompanyID ：公司idproceedingApplication ：事项申请表
ID ：主键
ProceedingApplicationID ：事项申请ID
ProceedingID ：事项ID
ApplicationTime ：申请时间
ApplicationPeopleID ：申请人ID
ApplicationPeopleName ：申请人姓名
ApplicationDepartmentName ：申请部门名称
ApplicationDepartmentID ：申请人部门ID
CompanyID ：公司Id
PositionID ：申请岗位ID
FileID ：上传文件id
BusinessType ：业务类别：1事项申请，2事项报销,3借款类型，4预算调整，5预算调整申请，6资金管理)
ApplicationType ：申请类别：编码来自数据字典groupID=11)
ProceedingType ：事项类型（对申请类型的补充，比如申请类型是借款申请，借款申请的子类型是日常借款，编码来自数据字典groupID=5，18，2）
State ：状态： 0申请中，1审批中,3拒单，4通过')
CompleteTime ：完成时间
Money ：金额
Remarks varchar：2000) DEFAULT NULL,
IsActive ：是否激活：1激活，0 没有激活)
IsDelete ：是否删除（1是0否）
CreateDate ：创建日期
CreateBy ：创建者id
ModifyDate ：修改日期
ModifyBy ：修改者id
PositionTrueID ：操作人真实职位ID
OperationDepartID ：操作人部门ID
AccountID ：科目ID
功能：是所有申请单的主表（优化活跃数据，优化主表和明细表）proceedingApproval ：事项审批
ID ：主键
ProceedingApprovalID ：事项审批id
ResponsiblePeopleID ：经办人ID
ResponsiblePeopleName ：经办人姓名
Money ：金额
Content ：内容
Purpose ：用途
Result ：事项效果评估/结果说明
IsBorrow ：是否借款：1是0否)
AccountID ：科目ID
ResidueBudget ：剩余预算reimbursementPayment ：报销付款表
ID ：主键
ReimbursementID ：报销付款ID
ApplicationID ：申请编码
GatheringPeople ：收款人/单位
GatheringAccount ：收款账号
ReimbursementDate ：报销日期
Money ：付款金额
CostAccount ：费用科目
GatheringType ：收款方式
ResidueBudget ：剩余预算
ProceedingExplain ：摘要说明
IsInvoice ：是否有发票
ExpectedDateInvoice ：预计收到发票日期
Remarks ：备注
ReimbursementMoney ：报销金额
InvoiceType ：发票类型
depositBank varchar：1000) DEFAULT NULL,
ResidueBudgetReimbursementMoney ：剩余可报销
IsNewCostDetails ：是否是新的费用明细
ProcessType ：流程类型reimbursementPaymentInvoice ：报销付款发票信息表
ID ：主键
ReimbursementPaymentInvoiceID ：发票ID
ProceedingID ：事项ID
InvoiceDate ：发票时间
InvoiceCode ：发票代码
InvoiceNumber ：发票号码
InvoicePartyName ：开票方名称
TaxpayerID ：开票方纳税人识别码
InvoiceContent ：发票内容
InvoiceType ：发票类别
Remarks ：备注
remittanceHistory ：打款历史记录表
ID ：主键
bankAccount ：银行账号
bankAccountUnit ：银行账号对应的单位
depositBank ：开户行
createBy ：创建者ID
createDate ：创建时间
operationDepartID ：操作部门ID
companyID ：公司ID
supplementaryBudget ：预算调整正式表
SupplementaryBudgetID ：追加预算id
DepartmentID ：部门id
AccountID ：科目id
Applicantid ：申请人ID
CompanyID ：公司id
PositionID ：流程职位id
Money ：金额
State ： // 状态 0未申请，1申请中，2审批中,3拒单，4通过
ApplicationDate ：申请时间
Month ：追加预算的月份
Year ：追加预算的年份
Remarks varchar：2000) DEFAULT NULL,
CreateBy ：创建者id
CreateDate datetime DEFAULT NULL,
ModifyBy ：修改者id
ModifyDate ：修改者id
SupplementaryBudgetCode ：预算调整申请编码
FileID ：上传文件IDsupplementaryBudgetApplication ：预算调整申请表
SupplementaryBudgetID ：追加预算id
SupplementaryBudgetCode ：预算调整申请编码
FileID ：上传文件ID
DepartmentID ：部门id
AccountID ：科目id
Applicantid ：申请人ID
Money ：金额
State ： // 状态 0未申请，1申请中，2审批中,3拒单，4通过
ApplicationDate ：申请时间
CompanyID ：公司id
PositionID ：流程职位idID
Month ：追加预算的月份
Year ：追加预算的年份
Remarks varchar：2000) DEFAULT NULL,
CreateBy ：创建者id
CreateDate datetime DEFAULT NULL,
ModifyBy ：修改者id
ModifyDate ：修改者idsupplier ：供应商
ID 主键
SupplierID ：供应商ID
SupplierName ：供应商名称
SupplierCode ：供应商编码
SupplierRatepayingCode ：供应商纳税识别号
SupplierBank ：供应商开户行
SupplierTelephone ：供应商联系电话
SupplierAddr ：供应商地址
SupplierBusinessType ：供应商经营种类
Remarks ：备注
IsActice ：是否激活（1是0否）
IsDelete ：是否删除（1是0否）
CreateBy ：创建者
CreateDate ：创建日期
ModifyDate ：修改日期
ModifyBy ：修改者
travelbusiness 差旅费申请单
ID ：主键
TravelBusinessID ：差旅费申请单ID
TravelBusinessDate ：出差日期
TravelBusinessAddr ：出差地址
TravelBusinessReason ：出差理由
IsBorrowMoney ：是否借款：1是0否)
Money ：金额
AccountID ：科目ID
ResidueBudget ：剩余预算travelcostdetails ：差旅报销费用明细表
ID：主键
ProceedingID ：申请编码
TravelCostdetailsID ：费用明细ID
Type ：事项
PeopleID ：出差人
StartTime ：开始时间
EndTime ：终止时间
Days ：天数
Standard ：标准
Money ：金额
Address ：出差地点
Remarks ：备注
AddressID ：出差地点IDybudget ：
YBudgetID ：年预算费用id
DepartmentID ：部门id
AccountID ：科目id
Remarks ：备注
YearMoney ：年预算金额
Year ：x年的预算
CreateDate ：创建日期
CreateBy ：创建者id
ModifyDate ：修改日期
ModifyBy ：修改者id
CompanyID ：公司id
TotalSum ：合计
TotalUsedSum ：累计使用合计
RemainingBudget ：剩余预算
winitem ：获奖礼品表
ID ：主键
WinItemID ：获奖礼品表ID
ItemID ：商品id
OfferPeopleID ：数据提供人ID
AuditPeopleID ：数据审核人ID
StatisticsPeopleID ：数据统计人ID
FileID ：文件ID
GiftId ：礼品ID
Remarks ：备注
Money ：金额
AccountID ：科目ID
ResidueBudget ：剩余预算
其他表（因为太多，就不列了）
5 功能设计
登录模块
- 按公司分，不同的用户登录后看到的数据不同。
- 同一个用户不同同时登录多个浏览器，确保只能登录一个浏览器，当有第二个人同时登陆同一个账户，前一个人的账户要被踢出。
- 用户登录的缓存设计（redis的键设计），如果用户有登录，那么一定时间内，关闭浏览器，在打开浏览器,用户跳过登录。
菜单模块
1 菜单的树形展示，菜单和功能的curd
角色模块
- 角色的curd
- 角色权限（菜单和功能，团队，科目）的设置和分配
部门模块
1部门的curd
科目模块
- 科目的curd
- 科目excel导出
用户模块
- 用户的curd
- 用户权限设置
- 用户岗位设置
- 用户银行账户设置
流程配置模块
流程的curd
数据字典模块
数据字典curd
流程审批模块
- 流程审批需要跨越多个部门或者公司。
- 对同一个流程节点可以有多个人审批，但只能有一个人审批过了，跳过下一个节点。
- 流程的自动审批。打个比方说,流程审批节点如下fa--fb---fc--fa--fd。当流程执行到fc时，fc同意后，下一个节点自动审批，进入到fd。
- 流程的批量审批。领导可以对多个申请的流程进行批量审批。
- 流程的多级驳回
- 流程审批过程中，动态修改流程参数
业务模块
业务模块都是一些经费申请，有些情况比较复杂，举个情景说下。
1填写申购申请单。（申请100双鞋,流程审批）,
申请结果
申请成功：跳转到报销付款申请
申请失败：从新发起申请或者抛弃该申请单（通知该用户）
2报销付款申请
2.1情况一：多次报销（每次报销50双鞋）
2.2情况二：一次报销（报销100双鞋）
申请结果
申请成功：跳转到资金管理（这里出纳会给钱的）
申请失败：从新发起申请或者抛弃该申请单（通知该用户）
3资金管理
申请结果：
申请成功：领钱
申请失败：从新发起申请或者抛弃该申请单（通知该用户）
1填写借款申请单。（申请100元,流程审批）,
申请结果
申请成功：跳转到资金管理
申请失败：从新发起申请或者抛弃该申请单（通知该用户）
2资金管理
申请结果：
申请成功：领钱100元
申请失败：从新发起申请或者抛弃该申请单（通知该用户）3报销付款申请
2.1情况一：多次还钱（每次还50）
2.2情况二：一次还钱（还100）
申请结果
申请成功：跳转到资金管理（这里出纳会收钱的）
4资金管理
2.1情况一：核算用户没还完（还差50元）,将申请单跳转到2，循环直到还清
2.2情况二：核算用户已还完，申请结束