论文部分内容阅读
自从高等教育实行收费制度以来,学生收费一直是高校财务部门的一项复杂、繁重的工作。这里我们找来了一个功能强大、方便实用并且可扩充性和可移植性均高的高校学生收费模型设计案例，希望可以给大家一些启示。
目前投入使用的大部分学校收费平台设计方案中实体模型中的各实体比较分散和孤立，没有一条主线将其串联起来，同时系统分析和设计中对收费平台中的业务分析不够透彻。因此我们需要设计一个较为通用的能够将收费平台的各业务串在一起的核心业务实体模型，该模型必须要具有较好的兼容性，为了将来系统应用的推广，必须能够很好的处理各种学校的不同的收费需求，对新业务能够方便的进行扩充。
1 系统设计目标
高校学生收费系统主要是本着方便用户，简化收费过程，严格控制收费的各个环节，提供高效、安全、智能化的收费管理这些考虑，而特别推出的符合高校学生收费特点和要求的平台软件，旨在将财务人员从繁琐的计算和记录活动中解放出来，从而提供财务部门的整体管理水平。
1) 通过对高校收费业务全面和透彻地分析，构建高校收费平台的核心业务实体模型，使其可以作为通用的模型来解决高校收费平台的各种业务需求，甚至可以作为其它收费平台的参考模型。
2) 采用当今最流行的工作平台、工作模式、开发工具和开发技术, 开发出具有良好的先进性、适应性、安全可靠性、易重用性、可移植性好的软件系统。
3) 根据学生收费相关信息的数据特点，设计出能处理批量事务、大量数据和良好的并发性、高性能的服务端。
4) 设计出布局美观合理、易操作、易使用、响应速度快、有良好的错误提示功能，良好的交互功能的客户端软件。
2 核心业务分析
高校学生收费系统的核心业务就是收费, 其它功能都是用于辅助收费而设计的。可以这样描述一个学生在这个系统中的一个生存周期：
1) 学生入校时，学生在收费系统中被建立了一条记录；
2) 学生在校期间，系统在每学年开始时都为学生产生该学年的应收费用；
3) 随后，学生通过各种方式和途径进行缴费，可能是银行托收、现金，也可能是学校发放的奖金或者银行贷款等，缴纳的费用可能超出，也可能不够。同时，因为学生调换专业、休学等情况的发生，应收费用本身也可能需要进行调整，这些就导致了欠费、退费和帐单调整等业务；
4) 学生离校时，当帐务结清后，学生在本系统中被注销成为历史信息，系统提供对学生的各种缴费信息的查询。
纵观这个过程，我们可以抽象出几个实体，包括：
用户——存放学生基本信息；
账号——存放学生资金；
帐单——促使学生产生缴费行为的对象。
其中，用户和账号由于是1对1的关系，可以合并成为一个实体，即帐户。
3 模型实体设计
1)帐户实体设计
一般情况下，学生入学时，系统会在学生信息表中为学生新建一条学生信息记录，而学生资金表用于记录学生当前各种资金类型对应的余额，相应信息记录是在学生缴费过程中逐步插入的。表结构如下：
a) 学生信息表说明：
* 学生ID：用于唯一标识学生的身份。
* 资金余额：学生资金中各种类型资金余额的累加。
b) 学生资金表说明：
* 资金类型：可能包括银行扣款、银行贷款、现金、奖学金等。
2) 帐单实体设计
一般情况下，系统会为每个学生在每学年开始的时候产生一条帐单，每条帐单对应多条明细，详细说明帐单的组成。帐单中的费用项目关系为：应收费用 = 减免费用 + 实收费用 + 未结清费用。表结构如下：
3.3.3业务记录设计
每笔帐务业务记录和销帐业务记录均对应1条或多条资金编号记录，每条销帐业务记录对应1条或多条销帐业务明细。表结构如下：
* 操作员：受理此次业务的操作员编号。
* 销帐流水：此次业务收入的资金对应以后销帐时销帐记录的流水号。
* 撤单流水号：此业务受理记录以后被撤销时填入对应撤销业务受理记录的受理编号。
4 系统核心业务实现
系统核心业务主要是指出帐、缴费、销帐、银行托收和托收返回处理业务。
1) 出帐
每个学年开始的时候，指根据系统中设置的收费标准，计算出帐年每个学生各种帐单科目的应收费用，生成学生帐单明细，然后对明细进行汇总生成学生帐单。
2) 缴费
系统认为缴费就是用户(学生)从各种不同的途径支付的费用，体现的是各种不同的类型的资金余额的变化，缴费的过程首先是产生帐务业务和资金变化记录，然后是对学生资金记录和学生记录余额的影响。所以，系统中对现金缴费、学校银行贷款发放、奖学金发放等都可以按照该统一的模式进行处理，只不过业务代码不同而已。
3) 销帐
销帐的过程是在帐户资金余额发生了变化并且该学生存在未结清帐单的情况下，或者是该学生产生了新的未付帐单并且该帐户有可用资金的情况下，利用帐户中的资金对该学生的未结清费用进行帐务销帐的过程。(对未结清帐单销帐；记录相应销帐业务记录、销帐明细和资金变化记录)。
销帐的操作有两种不同的情况：一种是出帐后利用帐户中的资金余额对新产生的帐单进行扣费，这种销帐是对全体学生都需要进行的可以称之为批量销帐；另外一种是系统发生了某种缴费业务，如：银行托收成功返回、缴纳现金、贷款发放、奖学金发放导致帐户余额增加，同时该学生存在未结清帐单，这是需要对该学生进行销帐操作，这种销帐是对单个学生进行的，可以称之为单笔销帐。
4) 银行托收
出帐并且进行了批量销帐操作后，如果学生仍有未结清帐单，此时将帐单进行加锁操作(设置帐单为托收状态)，同时将学生的欠费金额，身份证号码，银行帐户等信息发送给托收银行，由银行从学生在银行的帐户上进行扣费操作。
5) 托收返回处理
一定的时间间隔后，银行返回托收扣费结果给学校，系统对扣费结果进行循环遍历，对每一笔扣费记录按照缴费类似的处理方式将银行托收扣减费用打入到学生帐户中(记录帐务业务记录和资金变化记录，更新学生资金信息和帐户的资金余额信息)，同时调用单笔销帐进行销帐操作，并且对帐单进行解锁操作。
5 结束语
系统以帐户(学生)为核心，以资金流作为设计的基调，按照进、销、存系统的设计思想作为系统核心模型的设计思想，系统提供的功能也是从为学生提供服务出发的。这种模型保证了系统的高度可扩展性和可用性。在目前可预期的范围内，业务的变化在现有的框架内基本都是可以实现，不需要从系统底层的结构上做改动就能满足新业务的实现。
但随着高校的不断发展，学生收费相关的一些标准和政策也会随之发生变化。系统主要是从设计的总体上进行把握，对于随后的详细设计和编码阶段及系统实施阶段等的影响没有进行全面的考虑。
1) 没有考虑以后可能不是按年进行收费的情况。
目前系统实现的是按年出帐，这只是符合目前高校的实际收费情况。
2) 没有考虑对滞纳金的支持。
如果学校对指定期限未缴清帐单费用会收取滞纳金，则需要考虑在帐单中增加滞纳金项目，这个是本设计模型中需要完善的地方。
目前投入使用的大部分学校收费平台设计方案中实体模型中的各实体比较分散和孤立，没有一条主线将其串联起来，同时系统分析和设计中对收费平台中的业务分析不够透彻。因此我们需要设计一个较为通用的能够将收费平台的各业务串在一起的核心业务实体模型，该模型必须要具有较好的兼容性，为了将来系统应用的推广，必须能够很好的处理各种学校的不同的收费需求，对新业务能够方便的进行扩充。
1 系统设计目标
高校学生收费系统主要是本着方便用户，简化收费过程，严格控制收费的各个环节，提供高效、安全、智能化的收费管理这些考虑，而特别推出的符合高校学生收费特点和要求的平台软件，旨在将财务人员从繁琐的计算和记录活动中解放出来，从而提供财务部门的整体管理水平。
1) 通过对高校收费业务全面和透彻地分析，构建高校收费平台的核心业务实体模型，使其可以作为通用的模型来解决高校收费平台的各种业务需求，甚至可以作为其它收费平台的参考模型。
2) 采用当今最流行的工作平台、工作模式、开发工具和开发技术, 开发出具有良好的先进性、适应性、安全可靠性、易重用性、可移植性好的软件系统。
3) 根据学生收费相关信息的数据特点，设计出能处理批量事务、大量数据和良好的并发性、高性能的服务端。
4) 设计出布局美观合理、易操作、易使用、响应速度快、有良好的错误提示功能，良好的交互功能的客户端软件。
2 核心业务分析
高校学生收费系统的核心业务就是收费, 其它功能都是用于辅助收费而设计的。可以这样描述一个学生在这个系统中的一个生存周期：
1) 学生入校时，学生在收费系统中被建立了一条记录；
2) 学生在校期间，系统在每学年开始时都为学生产生该学年的应收费用；
3) 随后，学生通过各种方式和途径进行缴费，可能是银行托收、现金，也可能是学校发放的奖金或者银行贷款等，缴纳的费用可能超出，也可能不够。同时，因为学生调换专业、休学等情况的发生，应收费用本身也可能需要进行调整，这些就导致了欠费、退费和帐单调整等业务；
4) 学生离校时，当帐务结清后，学生在本系统中被注销成为历史信息，系统提供对学生的各种缴费信息的查询。
纵观这个过程，我们可以抽象出几个实体，包括：
用户——存放学生基本信息；
账号——存放学生资金；
帐单——促使学生产生缴费行为的对象。
其中，用户和账号由于是1对1的关系，可以合并成为一个实体，即帐户。
3 模型实体设计
1)帐户实体设计
一般情况下，学生入学时，系统会在学生信息表中为学生新建一条学生信息记录，而学生资金表用于记录学生当前各种资金类型对应的余额，相应信息记录是在学生缴费过程中逐步插入的。表结构如下：
a) 学生信息表说明：
* 学生ID：用于唯一标识学生的身份。
* 资金余额：学生资金中各种类型资金余额的累加。
b) 学生资金表说明：
* 资金类型：可能包括银行扣款、银行贷款、现金、奖学金等。
2) 帐单实体设计
一般情况下，系统会为每个学生在每学年开始的时候产生一条帐单，每条帐单对应多条明细，详细说明帐单的组成。帐单中的费用项目关系为：应收费用 = 减免费用 + 实收费用 + 未结清费用。表结构如下：
3.3.3业务记录设计
每笔帐务业务记录和销帐业务记录均对应1条或多条资金编号记录，每条销帐业务记录对应1条或多条销帐业务明细。表结构如下：
* 操作员：受理此次业务的操作员编号。
* 销帐流水：此次业务收入的资金对应以后销帐时销帐记录的流水号。
* 撤单流水号：此业务受理记录以后被撤销时填入对应撤销业务受理记录的受理编号。
4 系统核心业务实现
系统核心业务主要是指出帐、缴费、销帐、银行托收和托收返回处理业务。
1) 出帐
每个学年开始的时候，指根据系统中设置的收费标准，计算出帐年每个学生各种帐单科目的应收费用，生成学生帐单明细，然后对明细进行汇总生成学生帐单。
2) 缴费
系统认为缴费就是用户(学生)从各种不同的途径支付的费用，体现的是各种不同的类型的资金余额的变化，缴费的过程首先是产生帐务业务和资金变化记录，然后是对学生资金记录和学生记录余额的影响。所以，系统中对现金缴费、学校银行贷款发放、奖学金发放等都可以按照该统一的模式进行处理，只不过业务代码不同而已。
3) 销帐
销帐的过程是在帐户资金余额发生了变化并且该学生存在未结清帐单的情况下，或者是该学生产生了新的未付帐单并且该帐户有可用资金的情况下，利用帐户中的资金对该学生的未结清费用进行帐务销帐的过程。(对未结清帐单销帐；记录相应销帐业务记录、销帐明细和资金变化记录)。
销帐的操作有两种不同的情况：一种是出帐后利用帐户中的资金余额对新产生的帐单进行扣费，这种销帐是对全体学生都需要进行的可以称之为批量销帐；另外一种是系统发生了某种缴费业务，如：银行托收成功返回、缴纳现金、贷款发放、奖学金发放导致帐户余额增加，同时该学生存在未结清帐单，这是需要对该学生进行销帐操作，这种销帐是对单个学生进行的，可以称之为单笔销帐。
4) 银行托收
出帐并且进行了批量销帐操作后，如果学生仍有未结清帐单，此时将帐单进行加锁操作(设置帐单为托收状态)，同时将学生的欠费金额，身份证号码，银行帐户等信息发送给托收银行，由银行从学生在银行的帐户上进行扣费操作。
5) 托收返回处理
一定的时间间隔后，银行返回托收扣费结果给学校，系统对扣费结果进行循环遍历，对每一笔扣费记录按照缴费类似的处理方式将银行托收扣减费用打入到学生帐户中(记录帐务业务记录和资金变化记录，更新学生资金信息和帐户的资金余额信息)，同时调用单笔销帐进行销帐操作，并且对帐单进行解锁操作。
5 结束语
系统以帐户(学生)为核心，以资金流作为设计的基调，按照进、销、存系统的设计思想作为系统核心模型的设计思想，系统提供的功能也是从为学生提供服务出发的。这种模型保证了系统的高度可扩展性和可用性。在目前可预期的范围内，业务的变化在现有的框架内基本都是可以实现，不需要从系统底层的结构上做改动就能满足新业务的实现。
但随着高校的不断发展，学生收费相关的一些标准和政策也会随之发生变化。系统主要是从设计的总体上进行把握，对于随后的详细设计和编码阶段及系统实施阶段等的影响没有进行全面的考虑。
1) 没有考虑以后可能不是按年进行收费的情况。
目前系统实现的是按年出帐，这只是符合目前高校的实际收费情况。
2) 没有考虑对滞纳金的支持。
如果学校对指定期限未缴清帐单费用会收取滞纳金，则需要考虑在帐单中增加滞纳金项目，这个是本设计模型中需要完善的地方。