预算执行与经费审批网络管理系统详细设计说明书样本.doc

资料内容仅供您学习参考，如有不当或者侵权，请联系改正或者删除。

预算执行与经费审批网络管理系统
详细设计说明书V1.0

人员
时间
备注
编写
于洋、 姜永英、 黎猛

审核
陈长清

1引言 4
1.1编写目的 4
1.2背景 4
1.3定义 5
1.4参考资料 5
2程序系统的结构 5
3审核/批管理模块 13
3.1程序描述 13
3.2功能 13
3.3性能 14
3.3.1时间特性要求 14
3.3.2可靠性 14
3.3.3灵活性 14
3.4输人/出项 14
3.5流程逻辑 16
3.6接口 16
4信息查询模块 18
4.1程序描述 18
4.2功能 18
4.3性能 19
4.3.1时间特性要求 19
4.3.2易用性 19
4.3.3实时性 19
4.4输人/出项 19
4.5接口 22
5偿还管理模块 25
5.1程序描述 25
5.2功能 25
5.3性能 26
5.3.1时间特性要求 26
5.3.2实时性 26
5.4输人/出项 26
5.5流程逻辑 29
5.6接口 31
6基本信息管理模块 33
6.1程序描述 33
6.2功能 33
6.3性能 34
6.3.1时间特性要求 34
6.3.2易用性 34
6.3.3实时性 34
6.4输人/出项 35
6.5流程逻辑 36
6.6接口 36

1引言
1.1编写目的
在前一阶段( 概要设计说明书) 中, 已解决了实现该系统需求的程序模块设计问题。包括如何把该系统划分成若干个模块、 决定各个模块之间的接口、 模块之间传递的信息, 以及数据结构、 模块结构的设计等。在以下的详细设计报告中将对在本阶段中对系统所做的所有详细设计进行说明。在本阶段中, 确定应该如何具体地实现所要求的系统, 从而在编码阶段能够把这个描述直接翻译成用具体的 程序语言书写的程序。主要的工作有: 根据在《预算执行与货币化操作管理系统需求分析说明书》中所描述的数据、 功能、 运行、 性能需求, 并依照《预算执行与货币化操作管理系统概要设计说明书》所确定的处理流程、 总体结构和模块外部设计, 设计软件系统的结构设计、 逐个模块的程序描述( 包括各模块的功能、 性能、 输入、 输出、 算法、 程序逻辑、 接口等等) .
在下一阶段的时候, 设计人员能够在概要设计的基础上进行详细设计。在以后的系统维护的阶段也能够参考概要设计, 以便对系统更好的维护。
1.2背景
开发软件名称: 预算执行与货币化操作管理系统
项目任务提出者:
项目开发者: 华中科技大学
用户:
实现软件单位: 华中科技大学
项目与其它软件, 系统的关系:
(1) 服务器
CPU : 1G以上
内存: 1G( 推荐: 1G以上)
硬盘: 1G以上
光驱: DVD
监视器-VGA 或更高分辨率: 分辨率至少为 1,024x768 像素
操作系统: Windows
数据库: SQL Server 企业版
(2) 支持软件
操作系统: Windows Server SP1, Windows Server SP2。
数据库: Microsoft SQL Server Enterprise, Microsoft SQL Server Express, 或是Microsoft SQL Server Developer。
系统使用Microsoft Visual S 开发, 必须运行在所要求的硬件和软件平台上。
1.3定义
IPO图: 在计算机领域IPO是指结构化设计中变换型结构的输入( Input) 、 加工( Processing) 、 输出( Output) 。IPO图是对每个模块进行详细设计的工具, 它是输入加工输出(INPUT PROCESS OUTPUT)图的简称, 它是由美国IBM公司发起并完善起来的一种工具。
1.4参考资料
预算执行与货币化操作管理系统需求说明书V1.0
预算执行与货币化操作管理系统概要设计说明书V1.0
预算执行与货币化操作管理系统数据库设计说明书V1.0
2程序系统的结构
本项目将采用分层设计和装配件设计思想, 结合局域网采用客户/ 服务器( C/S) 结构。整个系统建立在Windows操作系统平台之上, 采用基于.NET2.0装配件的分布式应用结构实现整个系统, 并将整个系统分为客户端－应用服务器－数据库服务器三层, 其中后台数据库系统采用Microsoft SQL Server 。基于分布式架构的优势, 在后续的功能扩展中能够根据需要方便地将后台数据库系统移植到其它数据库上。客户使用客户端程序即可完成所有操作。
采用了.NET Remoting技术, 客户端经过获取服务器端的IP地址和注册的唯一的端口号, 访问通道以获得服务端对象, 再经过( Server Proxy) 代理解析为客户端对象。这就提供一种可能性, 即以服务的方式来发布服务器对象。远程对象代码能够运行在服务器上( 如服务器激活的对象和客户端激活的对象) , 客户端就是经过这种方式, 使用服务器端为其提供的服务。
本系统的主要目的是对以单位为服务对象的财务管理环境中, 对预算计划提交、 预算上报审核、 经费结算报销、 借还款以及科目进行全方位的数字化管理。实现普通用户的预算上报请求、 财务人员审核预算上报信息、 财务人员进行预算上报科目管理、 结算报销经费按预置的流程和审批权限进行流转等功能。系统的整体功能结构图如图2-1所示:
预算执行与货币化操作管理系统
审批/核管理
借款管理
检查用户审核/批权限
财务审核预算
财务审核请求
领导审批请求
发出借款请求
偿还管理
发送直接报销或偿还请求
执行借款请求
执行直接报销请求
执行现金偿还请求
添加报销金额相关信息
判断信息的合法性
上报管理
上报预算相关信息
向服务器发送报销提示
信息查询
查询所有开支方式
查询所有采购方式
查询所有年度信息
查询所有部门信息
查询部门下科室信息
查询预算的相关信息
查询借款的相关信息
查询报销的相关信息
查询审核/批相关信息
交互管理
上报操作完成提示
财务审核操作完成提示
审核经过操作完成提示
数据库管理
备份数据库
还原数据库
清除所有一级预算信息
获取备份文件列表
基本信息管理
增删改科目相关信息
增删改部门相关信息
增删改部门科室相关信息
增删改年度相关信息
增删改开支方式相关信息
用户权限管理
角色信息管理
用户信息验证

图 2.1 系统功能结构图
由图2-1可知, 本系统中我们所涉及到的功能之模块主要有九个部分, 即: 审核/批管理、 借款管理、 信息查询、 偿还管理、 上报管理、 交互管理、 数据库管理、 基本信息管理和用户权限管理 。而在实现这些功能模块时, 我们所关心的主要业务实体有五个部分: 预算信息、 用户信息、 请求信息、 报销信息和借款信息。根据前面的概要设计和数据库设计说明书, 我们对这五大业务实体进行概念抽象, 得到在实现系统业务需求过程中, 五大业务实体相关的类图和她们之间的交换关系类图。由于借款信息相对简单, 这里未对其进行单独的详细说明, 其余的类图如下所示:
1、 预算相关信息类图: 主要负责处理用户提交预算上报的相关业务, 包括预算明细, 预算支付方式、 预算年限、 预算类型和预算的审核等级。具体情况如下图2.2所示:

图 2.2 预算相关信息类图
2、 用户相关信息类图: 主要负责处理用户相关信息管理业务, 包括用户基本信息、 用户角色和角色权限相关信息管理。具体情况如下图2.3所示:

图 2.3 用户相关信息类图
3、 请求信息类图: 主要负责处理用户提交报销直接发放、 偿还报销请求的相关业务。主要包括请求的基本信息、 请求处理的状态、 请求所需的审核/批次数和请求所需的用户权限等相关信息。具体情况如下图2.4所示:

图 2.4 请求相关信息类图
4、 报销信息类图: 主要负责报销相关信息相关业务。包括报销明细、 报销类型、 报销支付方式、 报销提请的用户和报销请求。具体情况如下图2.5所示:

图 2.5 报销相关信息类图
5、 审核/批日志类图: 记录系统审核/批等相关信息的记录, 包括预算、 预算状态和用户等相关信息。具体情况如下图2.6所示:

图 2.6 审核/批日志类图
6、 报销日志类图: 记录报销过程的相关日志信息, 包括报销、 借款、 预算、 请求和用户等相关信息。具体情况如下图2.7所示:

图 2.7 报销日志信息类图
3审核/批管理模块
3.1程序描述
审核/批管理模块主要是处理预算上报后, 财务部门的审核。部门科室上报直接发放报销和偿还报销请求后, 经过财务部门审核后, 由领导对相应的上报请求进行审批, 最后由财务部门审核执行等一系列过程。
3.2功能
审核/批管理模块主要包括检查用户审核/批权限、 财务审核预算、 财务审核请求、 领导审批请求等。具体功能如下图3.1所示:
审核/批管理模块
检查用户审核权限
财务审核预算
财务审核请求
领导审批请求

图 3.1 审核/批管理模块
3.3性能
3.3.1时间特性要求
系统的速度要在用户可接受的范围内, 但考虑到需要实时检测服务器的可用性, 对资源实时搜索的速度能够有较低的要求。
3.3.2可靠性
系统要有较高的可靠性, 可恢复性。
3.3.3灵活性
系统要有良好的接口, 以适应增加资源平台, 增加资源类型, 增加相关的资源获取功能的需求; 并留有服务器接口, 适应对以后实现服务器功能的需要; 同时系统还需要具有跨平台功能。
3.4输入/出项
根据上面的模块功能结构图, 表示出该模块各个功能的输入/出项。具体情况如下图:
1、 检查用户审核/批权限: 系统根据操作用户的ID号, 和待审核/批请求的ID号, 检测该用户是否具有审核/批该请求的权限, 并返回查询结果。具体IPO图如下图3.2所示:
模块功能名称: 检查用户审核/批权限
输入: 用户输入自己的id号和请求id号。
处理: 根据用户的ID号和待审核请求的ID号, 分别重用户表和请求表中查询两者的权限。
输出: 用户是否具有审核/批权限
数据表: user_info、 user_type_info中根据user_id查询用户user_check_authority, 在request_info中根据request_id查询request_approve_needcount。
图 3.2 检查用户的审核/批权限IPO图
2、 财务审核预算: 由于在实际业务中, 预算信息只需要经过财务部门的审核即可, 不要上部门领导的审批。因此, 当部门科室的用户上报预算提请时, 只需要经过财务部门的操作人员的审核即可对该预算信息进行裁决。具体情况如下图3.3所示:
模块功能名称: 财务审核预算
输入: 操作用户的ID号, 预算的ID号和预算是否经过审核信息。
处理: 记录待审核预算在审核前的状态信息, 对预算请求进行审核, 并记录用户审核后的状态。将操作用户的ID号, 预算请求的前后状态和预算本身等信息存储在approve_log表中。
输出: 提示信息
数据表: 在budget_info中查询预算的处理前状态, 改变budget_state_info中预算状态, 并将处理结果存储在approve_log表中
图 3.3 财务审核预算IPO图
3、 财务审核请求: 处理实际业务中部门科室用户上报的直接发放报销请求和偿还报销请求。具体情况如下图3.4所示:
模块功能名称: 财务审核请求
输入: 请求ID号, 审核人的ID号, 审核是否经过及设定需要几级审批。
处理: 根据请求的ID号, 和是否经过审核信息, 修改request_info、 request_state_info表状态相关信息。在request_approve_log表格中记录审核人ID号, 审核结果和需要几级审批等相关信息。
输出: 提示信息
数据表: 相关数据表request_info、 request_state_info、 request_approve_log和request_approve_needcount_info表
图 3.4 财务审核请求IPO图
4、 领导审批请求: 当请求经过财务部门审核后, 需要根据财务部门操作人员设定的请求所需的审批级别, 由相应级别的领导依次审批, 最终记录审批结果。具体情况如下图3.5所示:
模块功能名称: 领导审批请求
输入: 请求ID号, 审核人的ID号, 请求是否经过审批
处理: 根据请求的ID号, 和是否经过审核信息, 修改request_info、 request_state_info表状态相关信息。在request_approve_log表格中记录审核人ID号, 审批结果。
输出: 提示信息
数据表: 相关数据表request_info、 request_state_info、 request_approve_log和request_approve_needcount_info表。
图 3.6 领导审批请求IPO图
3.5流程逻辑
审核/批管理模块的流程图如下图3.7所示:

图 3.7 审核/批管理模块流程图
3.6接口
审核/批管理模块主要接口定义在IBudgetApprove.cs中, 其中定义的方法简单介绍如下:
/// <summary>
/// 判断某用户是否对某请求有审批权限
/// </summary>
/// <param name="request_id">用户ID</param>
/// <param name="user_id">请求ID</param>
/// <returns>有则返回true</returns>
public bool IHaveApprveAuth(string request_id, string user_id);
/// <summary>
/// 财务审核预算
/// </summary>
/// <param name="budget_id">被审核预算ID</param>
/// <param name="user_id">审核人ID</param>
/// <param name="isapproved">是否经过审核</param>
/// <returns>操作是否成功</returns>
public bool FBudgetApprove(string budget_id, string user_id, bool isapproved);
/// <summary>
/// 领导审批请求
/// </summary>
/// <param name="request_id">请求ID</param>
/// <param name="user_id">审批人ID</param>
/// <param name="isapproved">是否经过审批</param>
/// <returns>操作是否成功</returns>
public bool RequestApprove(string request_id, string user_id, bool isapproved);
/// <summary>
/// 财务审核请求
/// </summary>
/// <param name="request_id">请求ID</param>
/// <param name="user_id">审核人ID</param>
/// <param name="isapproved">是否经过审核</param>
/// <param name="request_approve_needcount">设定需要几级审批</param>
/// <returns>操作是否成功</returns>
public bool FRequestApprove(string request_id, string user_id,bool isapproved, string request_approve_needcount);
/// <summary>
/// 财务审核报销请求
/// </summary>
/// <param name="pay_log_id">报销请求ID</param>
/// <param name="user_id">审核人ID</param>
/// <param name="isapproved">是否经过审核</param>
/// <param name="budget_approve_needcount">设定需要领导审批等级</param>
/// <returns>操作是否成功</returns>
public bool PayRequestFApprove(string pay_log_id, string user_id,bool isapproved, string budget_approve_needcount);
/// <summary>
/// 财务审核借款请求
/// </summary>
/// <param name="pay_log_id">报销请求ID</param>
/// <param name="user_id">审核人ID</param>
/// <param name="isapproved">是否经过审核</param>
/// <param name="budget_approve_needcount">设定需要领导审批等级</param>
/// <returns>操作是否成功</returns>
public bool BorrowRequestFApprove(string borrow_id, string user_id,bool isapproved, string budget_approve_needcount)
4信息查询模块
4.1程序描述
信息查询模块主要是根据各种用户的权限, 为各种权限的用户提供相应范围内的信息查询功能。
4.2功能
信息查询模块的功能如下图4.1所示:
信息查询模块
查询所有开支方式
查询所有年度信息
查询预算的相关信息
查询报销的相关信息
查询
所有采购方式

查询部门下科室信息
查询所有部门信息
查询借款的相关信息
查询审核批相关信息

图 4.1 信息查询模块功能结构图
查询部门下科室相关信息包括: 查询所有部门信息和查询某部门下所有科室信息;
查询预算相关信息包括: 查询所有预算信息、 根据年度ID、 科目ID、 部门科室ID、 开支方式ID、 采购方式ID、 预算状态ID、 是否经过所有审批和是否已执行等相关信息对预算信息进行查询;
查询借款相关信息包括: 根据是否经过所有审批审核、 是否已执行和是否还清查询借款信息, 查询某人借款信息, 查询某人可查看的所有借款信息, 查询部门科室的借款信息和查询某借款中为偿还金额;
查询报销的相关信息包括: 查询某预算下的报销信息, 查询报销请求的物品信息, 查询待执行的报销信息, 查询某人的报销信息, 查询部门科室下的报销信息, 经过请求ID查询报销ID, 查询某人可查看的报销信息, 查询拥有某审批权限的所有用户信息和查询报销金额总和;
查询审核/批相关信息包括: 判断某用户是否对请求有领导审批权限, 查询需要某用户财务审核的报销信息, 查询需要某用户领导审批的报销信息, 查询需要某用户财务审核的预算信息, 查询需要某用户财务审核的借款请求信息, 查询需要某用户领导审批的借款请求信息, 查询所有预算需审批级数, 查询所有请求需审批级数, 查询某预算的审批日志和查询某条请求的审批日志。
4.3性能
4.3.1时间特性要求
查询模块作为用户经常使用的模块, 对时间特性的要求较高。在本系统中, 我们经过索引和视图的方法尽量提高数据库查询的效率。
4.3.2易用性
查询模块经过提供灵活智能的查询功能, 使用户能够而且快速的获取其所感兴趣的内容。
4.3.3实时性
由于系统具有三个客户端同时在运行。因此, 系统的数据必然经常变化。系统在设计时, 经过委托的方法使各个客户端之间能够实时的交互, 使得用户在查询数据时, 能够得到实时数据。
4.4输入/出项
根据上面的模块功能结构图, 表示出该模块各个功能的输入/出项。具体情况如下图:
1、 查询所有开支方式: 查询所有开始方式相关信息。具体IPO图如下图4.2所示:
模块功能名称: 查询所有开支方式
输入:无。
处理: 查询系统提供的所有开支方式。
输出: 所有开支方式列表。
数据表:
pay_method_info 开支方式
图 4.2 查询所有开支方式IPO图
2、 查询所有采购方式: 查询所有采购方式相关信息。具体IPO图如下图4.3所示:
模块功能名称: 查询所有采购方式
输入:无。
处理: 查询系统提供的所有开支方式。
输出: 所有采购方式列表。
数据表:
purchase_method_info 采购方式。
图 4.3 查询所有采购方式IPO图
3、 查询所有年度信息: 查询所有年度相关信息。具体IPO图如下图4.4所示:
模块功能名称: 查询所有年度信息
输入:无。
处理: 查询系统提供的所有年度信息。
输出: 所有年度信息列表。
数据表:
budget_range_info 年度信息。
图 4.4 查询所有年度信息IPO图
4、 查询部门信息: 查询所有部门信息。具体IPO图如下图4.5所示:
模块功能名称: 查询所有部门信息
输入:无。
处理: 查询系统提供的所有部门信息。
输出: 所有部门信息列表。
数据表:
department_info 部门信息。
图 4.5 查询部门信息IPO图
5、 查询部门下科室信息: 根据用户提供的部门ID号, 查询部门下的科室信息。具体IPO图如下图4.6所示:
模块功能名称: 查询部门下科室信息
输入:部门ID号。
处理: 根据用户提供待查询部门的ID号, 查询对应部门下所有科室信息。
输出: 对应部门下所有科室信息列表。
数据表:
department_info 部门信息
图 4.6 查询部门下科室信息IPO图
6、 查询特定状态下的预算信息: 根据用户提供的待查询预算状态, 查询满足状态要求的所有预算信息。具体IPO图如下图4.7所示:
模块功能名称: 查询特定状态预算信息
输入:预算状态ID号。
处理: 根据用户提供待查询预算状态ID号, 查询该状态下的所有预算信息。
输出: 待查询状态所有预算信息列表。
数据表:
budget_info 预算信息
budget_item_info 预算明细
budget_range_info 预算年度
budget_state_info 预算状态
pay_method_info 开支方式
图 4.7 待查询状态的预算信息IPO图
7、 查询特定部门特定状态的预算信息: 根据用户提供的待查询部门, 待查询预算状态信息, 查询满足要求的所有预算信息。居停IPO图如下图4.8所示:
模块功能名称: 查询特定状态、 特定部门预算信息
输入:预算状态ID号, 部门ID号。
处理: 根据用户提供待查询预算状态ID号和待查询部门ID号, 查询该状态下的所有预算信息。
输出: 待查询状态所有预算信息列表。
数据表:
budget_info 预算信息
budget_item_info 预算明细
budget_range_info 预算年度
budget_state_info 预算状态
pay_method_info 开支方式
department_info 部门科室
图 4.8 查询特定部门特定状态预算信息IPO图
8、 查询借款信息: 根据是否经过所有审核/批, 是否已执行, 是否还清查询借款相关信息。具体IPO图如下图4.9所示:
模块功能名称: 查询特定借款信息
输入:是否经过所有审核/批, 是否已执行, 是否还清。
处理: 根据用户提供是否经过所有审核/批, 是否已执行, 是否还清信息, 查询该状态下的所有预算信息。
输出: 待查询状态所有借款信息列表。
数据表:
borrow_info 借款
is_allapproved_info 是否经过全部审批
is_allpayback_info 是否全部偿还清
图 4.9 查询借款信息IPO图
9、 查询某人借款信息: 根据用户提供的用户ID号, 查询该用户的借款信息。具体IPO图如下图4.10所示:
模块功能名称: 查询某人借款信息
输入:待查询的用户ID号。
处理: 根据用户提供的待查询用户ID号, 查询该用户的借款信息。
输出: 待查询状态所有借款信息列表。
数据表:
borrow_info 借款
is_allapproved_info 是否经过全部审批
is_allpayback_info 是否全部偿还清
user_info 用户信息
图 4.10 查询某用户借款信息IPO图
10、 查询某预算下的报销信息: 根据用户提供的预算ID号, 查询该预算下的所有报销信息。具体IPO图如下图4.11所示:
模块功能名称: 查询某预算下的报销信息
输入:待查询的预算ID号。
处理: 根据用户提供的预算ID号, 查询该预算下的所有报销信息。
输出: 待查询报销信息列表。
数据表:
pay_log 报销记录
pay_item_info 报销明细
budget_info 预算信息
budget_item_info 预算详细信息
图 4.11查询某预算下的报销信息IPO图
11、 查询某部门科室的报销信息: 根据用户提供的部门ID号, 查询该部门下的所有报销信息。具体IPO图如下图4.12所示:
模块功能名称: 查询某部门下的报销信息
输入:待查询的部门ID号。
处理: 根据用户提供的部门ID号, 查询该部门下的所有报销信息。
输出: 待查询报销信息列表。
数据表:
pay_log 报销记录
pay_item_info 报销明细
department_info 部门科室
图 4.12查询某部门科室的报销信息IPO图
12、 查询需要某用户领导审批的借款请求信息: 根据领导ID号, 查询需要该领导审批的借款信息。具体IPO图如下图4.13所示:
模块功能名称: 查询需要某用户领导审批的借款请求信息
输入:待查询领导ID号。
处理: 根据用户提供的领导ID号, 查询需要该领导审批的借款信息。
输出: 待查询借款请求信息列表。
数据表:
pay_log 报销记录
pay_item_info 报销明细
user_info 部门科室
borrow_info 借款信息
图 4.13查询需要某用户领导审批的借款请求信息IPO图
4.5接口
查询管理模块主要接口定义在IBudgetApprove.cs中, 其中定义的方法简单介绍如下:
/// <summary>
/// 查询特定状态预算
/// </summary>
/// <param name="budget_state_id">预算状态ID</param>
/// <returns>查询到的数据集</returns>
public DataSet IGetBudgetInfoByState(string budget_state_id);
/// <summary>
/// 查询特定部门科室特定状态的预算
/// </summary>
/// <param name="budget_state_id">预算状态ID</param>
/// <param name="department_id">部门科室ID</param>
/// <returns>查询到的数据集</returns>
public DataSet IGetBudgetInfoByStateDepartment(string budget_state_id, string department_id);
/// <summary>
/// 得到所有科目
/// </summary>
/// <returns>查询到的科目数据集</returns>
public DataSet IGetBudgetType();
/// <summary>
/// 得到特定一级科目下的所有二级科目
/// </summary>
/// <param name="budget_type_parentid">一级科目ID</param>
/// <returns>查询到的二级科目数据集</returns>
public DataSet IGetBudgetSubType(string budget_type_parentid);
/// <summary>
/// 得到所有开支方式
/// </summary>
/// <returns>查询到的开支方式数据集</returns>
public DataSet IGetPayMethod();
/// <summary>
/// 得到所有采购方式
/// </summary>
/// <returns>查询到的采购方式数据集</returns>
public DataSet IGetPurchaseMethod();
/// <summary>
/// 得到所有年度信息
/// </summary>
/// <returns>查询到的年度数据集</returns>
public DataSet IGetBudgetRange();
/// <summary>
/// 得到所有部门信息
/// </summary>
/// <returns>查询到的部门信息数据集</returns>
public DataSet IGetAllDeptPName();
/// <summary>
/// 得到部门下所有科室信息
/// </summary>
/// <param name="department_pid">部门ＩＤ</param>
/// <returns>查询到的科室数据集</returns>
public DataSet IGetDeptNameByPId(string department_pid);
/// <summary>
/// 查询预算信息
/// </summary>
/// <param name="budget_range_id">年度ID</param>
/// <param name="budget_type_id">科目ID</param>
/// <param name="department_id">部门科室ID</param>
/// <param name="pay_method_id">开支方式ID</param>
/// <param name="purchase_method_id">采购方式ID</param>
/// <param name="budget_state_id">预算状态ID</param>
/// <param name="allapproved">是否经过所有审批</param>
/// <param name="isfullinfo">是否查询完整信息</param>
/// <returns>查询到的预算信息数据集</returns>
public DataSet IGetBudgetInfo(string budget_range_id, string budget_type_id, string department_id,string pay_method_id, string purchase_method_id, string budget_state_id,bool allapproved, bool isfullinfo);
/// <summary>
/// 查询借款信息
/// </summary>
/// <param name="borrow_id">借款ID</param>
/// <returns>查询到的借款信息数据集</returns>
public DataSet IGetBorrowFullInfo(string borrow_id);
/// <summary>
/// 查询某人可查看的所有借款信息
/// </summary>
/// <param name="budget_id">预算ID</param>
/// <param name="user_id">用户ID</param>
/// <returns>查询到的借款信息数据集</returns>
public DataSet IGetBorrowFullInfoAuth(string budget_id, string user_id);
/// <summary>
/// 查询部门科室借款信息
/// </summary>
/// <param name="department_id">部门科室ID</param>
/// <param name="is_allpayback">是否还清</param>
/// <returns>查询到的借款信息数据集</returns>
public DataSet IGetBorrowFullInfoByDept(string department_id, bool is_allpayback);
/// <summary>
/// 查询部门科室的借款信息
/// </summary>
/// <param name="department_id">部门科室ID</param>
/// <param name="is_allapproved">是否经过所有审批</param>
/// <param name="is_executed">是否已执行</param>
/// <param name="is_allpayback">是否还清</param>
/// <returns>查询到的借款信息数据集</returns>
public DataSet IGetBorrowFullInfoByDept(string department_id, bool is_allapproved, bool is_executed, bool is_allpayback);
/// <summary>
/// 查询某人的报销信息
/// </summary>
/// <param name="is_cashpay">是否是直