CN101236627A

CN101236627A - 一种轨道交通票务的帐务系统

Info

Publication number: CN101236627A
Application number: CNA2008100336267A
Authority: CN
Inventors: 顾伟华; 赵时旻; 毕湘利; 应名洪; 朱沪生; 周芳; 冯娟
Original assignee: Shanghai Shentong Rail Transit Research & Consulting Co Ltd
Current assignee: Shanghai Shentong Rail Transit Research & Consulting Co Ltd
Priority date: 2008-02-15
Filing date: 2008-02-15
Publication date: 2008-08-06

Abstract

本发明提供一种轨道交通票务的帐务系统，包括数据库模块、数据处理模块，所述数据处理模块包括清分预处理模块、清分模块、及终处理模块；所述清分预处理模块包括前置信息交换模块、段信息生成模块；所述清分模块包括清分主模块、交通卡打包转发模块、异常处理模块、清分规则模块；所述终处理模块包括对帐模块、可疑帐务处理模块、报表生成模块、结算模块。本发明揭示的轨道交通票务的帐务系统，可依据清分规则将运营收益合理地清分给相关的收益方。

Description

一种轨道交通票务的帐务系统

【技术领域】

本发明涉及一种清分处理系统，尤其涉及一种轨道交通票务的帐务系统。

【背景技术】

随着世界经济和科技的不断发展，全球城市轨道交通已进入了新一轮发展阶段。在布局上，实现从“单线建设”，向多层次、立体化、综合性的“网络化”建设转变；在功能上，实现以了智能化、信息化为标志的大客流、大线网、大交易量的智能管理系统。

城市轨道交通智能管理系统的发达程度，不仅成为市民日常出行的重要交通工具先进性的表征，更是体现城市综合竞争力的基础，对国民经济的发展，乃至“和谐社会”的建设，将起着越来越大的作用。目前我国的城市轨道交通的系统、设施及其产业，已从局部大城市的点布设，向中等城市和网面的布设转变，形成了产业雏形；已成为全球增长最快、最大的区域性市场。截至2006年年底，我国的上海、北京、广州、深圳等10个城市已拥有轨道交通运营里程504.63公里(上海到2007年底累计建成230公里)。到2020年，全国将有近25个城市要建设总长1500公里的轨道交通，其中上海将建成18条线，总里程970公里；到2050年，我国总建设里程可达5000公里，总投资估算将超过8000亿元。

在我国网络化、智能化的城市轨道交通的快速、规模化的建设与发展背景下，呈现出巨大的现实和潜在的城市轨道交通市场。

然而，现有的轨道交通的帐务系统还依然是自动售检票线路中央系统对于交易明显的处理主要是以统计为主，即对于票款收入、运营收益、客流情况等主要以累加为主，其特点是数据统计方式简单，数据量小。

随着网络化运营的启动，对于交易数据的处理主要是根据清分规则将运营收益合理地清分给相关的收益方，针对不同的线路、车站和区间进行票款收入、客流统计分析，原有的线路帐务处理系统不能提供这样的数据处理要求。

【发明内容】

本发明的目的是提供一种轨道交通票务的帐务系统，该帐务处理系统可依据清分规则将运营收益合理地清分给相关的收益方。

为了实现上述目的，本发明提供一种轨道交通票务的帐务系统，包括数据库模块、数据处理模块，所述数据处理模块包括清分预处理模块、清分模块、及终处理模块；所述清分预处理模块包括前置信息交换模块、段信息生成模块；所述清分模块包括清分主模块、交通卡打包转发模块、异常处理模块、清分规则模块；所述终处理模块包括对帐模块、可疑帐务处理模块、报表生成模块、结算模块；所述前置信息交换模块用于接收自线路中央发送来的交易明细数据，并将交易明细数据存入数据库模块；所述段信息生成模块用于将所述交易明细数据归类划分，实时地将交易明细数据划分成多个子集；所述清分规则模块用于生成清分规则，清分主模块通过该清分规则进行数据清分；所述清分主模块与所述数据库模块、交通卡打包转发模块、异常处理模块、清分规则模块连接，按上述段信息生成模块生成的子集读取前置信息交换模块入库的交易明细，按所述清分规则模块生成的清分规则进行清分、统计；所述交通卡打包转发模块用于将交通卡交易数据打包转发交通卡公司；异常处理模块用于当系统发生异常时对异常数据进行处理；所述终处理模块与所述清分主模块连接，获取所述清分主模块清分得出的数据。

作为本发明的一种优选方案，所述数据处理模块还包括银行划帐单发送模块；所述银行划帐单发送模块与所述结算模块连接。

作为本发明的一种优选方案，所述数据处理模块还包括查询余额模块，该查询余额模块与所述结算模块连接。

作为本发明的一种优选方案，所述数据库模块包括帐务处理数据库模块及历史数据库模块。

作为本发明的一种优选方案，所述数据处理模块还包括超期数据导入模块，其将超期数据明细插入历史数据库模块，插入成功的数据明细形成可疑帐调整明细写入帐务处理数据库模块。

作为本发明的一种优选方案，所述清分主模块为系统常驻进程。

作为本发明的一种优选方案，所述终处理模块为日终处理模块，处理每日的帐务。

作为本发明的一种优选方案，所述清分规则模块生成清分比例表。

作为本发明的一种优选方案，对于清分比例表扫描处理，将清分比例表设为内存表，数据库启动时将数据导入内存，清分处理时对于清分比例表的扫描在内存中操作。

作为本发明的一种优选方案，同一时刻，对于单个交通卡的每次使用只有一条清分比例信息；同一时刻，清分比例表分为当前数据表和历史数据表，当前数据表为cache表，历史数据表为普通表；当前数据表中保存当前版本与预置版本的清分比例，历史数据表中保存所有版本的清分比例；清分处理时，首先判断交易时间是否小于当前数据表中的当前版本的清分比例的启用时间，如果小于直接写入超期的可疑数据明细，由后续的超期数据明细处理模块对这部分数据明细进行清分。

与现有技术相比，本发明揭示的轨道交通的帐务系统，可依据清分规则将运营收益合理地清分给相关的收益方。同时，其采用并发处理机制，保证了系统具备横向扩展能力；按段的数据清分处理理念减少了数据库输入输出，提高得清分处理的能力；通过内存表、临时表的使用，有效地减少数据库输入输出；提高了清分功能的高效性，大大提高了系统的容错能力；实时地收益、客流数据清分，为快速的运营组织调度，提供了最及时准确地依据。本发明综合的运用内存表技术、中间件技术、负载均衡技术，并且对系统的处理结构和逻辑进行合理的设计，对轨道交通网络化运营的海量数据的复杂处理提供了一套高效、稳定的账务处理系统。

【附图说明】

图1为本发明轨道交通帐务系统的模块图。

附图标记说明：

1、数据库模块；

21、清分预处理模块；211、段信息生成模块；212、前置信息交换模块；

22、清分模块；220、清分主模块；221、交通卡打包转发模块；222、异常处理模块；223、清分规则模块；

23、日终处理模块；231、对帐模块；232、可疑帐务处理模块；233、报表生成模块；234、结算模块；

24、银行划帐单发送模块；

25、查询余额模块。

①、前置信息交换步骤；②、段信息生成步骤；③、清分主模块读取前置交换步骤入库的交易明细；④、交通卡打包转发步骤；⑤、异常处理步骤；⑥、清分规则生成步骤；⑦、日终处理步骤；⑧、银行划帐单发送步骤。

【具体实施方式】

以下结合附图及实施例对本发明做具体介绍。

请参阅图1，本发明介绍了一种轨道交通票务的帐务系统，该帐务处理系统依据清分规则、将运营收益合理地清分给相关的收益方。该系统包括数据库模块1、数据处理模块，所述数据处理模块包括清分预处理模块21、清分模块22、日终处理模块23、银行划帐单发送模块24、及查询余额模块25。

所述清分预处理模块21包括前置信息交换模块212、段信息生成模块211。所述前置信息交换模块212用于接收自线路中央发送来的交易明细数据，并将交易明细数据存入数据库模块1；所述段信息生成模块211用于将所述交易明细数据归类划分，实时地将交易明细数据划分成多个子集。

所述清分模块22包括清分主模块220、交通卡打包转发模块221、异常处理模块222、清分规则模块223。所述清分规则模块223用于生成清分规则，清分主模块220通过该清分规则进行数据清分；所述清分主模块220为系统常驻进程，其与所述数据库模块1、交通卡打包转发模块221、异常处理模块222、清分规则模块223连接，按上述段信息生成模块211生成的子集读取前置信息交换模块212入库的交易明细，按所述清分规则模块223生成的清分规则进行清分、统计；所述交通卡打包转发模块221用于将交通卡交易数据打包转发交通卡公司；异常处理模块222用于当系统发生异常时对异常数据进行处理。

所述日终处理模块23包括对帐模块231、可疑帐务处理模块232、报表生成模块233、结算模块234；日终处理模块23与所述清分主模块220连接，获取所述清分主模块220清分得出的数据。

银行划帐单发送模块24、及查询余额模块25与所述结算模块234连接。结算模块234结算后形成银行划帐单，通过银行划帐单发送模块24发送到银行，实现业主收益资金的划拨。查询余额模块25用以实现余额查询的功能。

为使清分进一步合理，数据库模块1包括帐务处理数据库模块、历史数据库模块、超期数据导入模块，超期数据导入模块将超期数据明细插入历史数据库模块，插入成功的数据明细形成可疑帐调整明细写入帐务处理数据库模块。

清分规则模块223生成清分比例表。对于清分比例表扫描处理，将清分比例表设为内存表，数据库启动时将数据导入内存，清分处理时对于清分比例表的扫描在内存中操作。同一时刻，对于单个交通卡的每次使用只有一条清分比例信息，避免了打开数据库游标所耗费的CPU时间；同一时刻，清分比例表分为当前数据表和历史数据表，当前数据表为cache表，历史数据表为普通表；当前数据表中保存当前版本与预置版本的清分比例，历史数据表中保存所有版本的清分比例，这样处理可以减小当前数据表中的数据量；清分处理时，首先判断交易时间是否小于当前数据表中的当前版本的清分比例的启用时间，如果小于直接写入超期的可疑数据明细，由后续的超期数据明细处理模块对这部分数据明细进行清分，不影响正常的清分流程。

清分处理首先对交易数据包按包数量(包数量可以通过系统参数表设置的方式进行动态配置)进行分段，而后由独立的进程首先对每段数据进行清分统计处理，然后由其它独立的进程对按段的汇总数据再次汇总，形成按日的汇总统计数据。对于公务票、计次票和纪念票等涉及票卡账户信息更新的交易数据首先记录交易数据明细，而后由独立的进程读出交易数据明细并更新票卡账户。

清分中心的数据库模块1中按日建立公共交通卡售卡/储值明细表、公共交通卡出口明细表、单程票售票明细表、单程票出口明细表，并且只保留最近几天的数据明细，在数据库模块1中保存180天的数据明细，清分处理中将数据明细按交易日写入各明细表，从而判断重复交易数据，对于超期交易数据明细(交易时间超过清分中心设定的正常处理时间之前的交易数据明细)，直接写入可疑数据明细表。在数据库模块1中有独立的进程将超期流水按交易日写入各数据明细表，判断出重复交易数据明细，将其它正常的交易数据形成可疑帐调整明细，而后按可疑帐调整的流程处理这部分交易数据明细。

对于中间数据结果集的入库，即按段的统计信息的更新通过内存中的临时表实现，一段数据统计完毕，一次提交，减少数据库输入输出。

本发明的账务处理系统的具体流程为：

步骤①、前置信息交换模块212接收自线路中央发送来的交易明细数据，并将交易明细数据存入数据库模块1；

步骤②、段信息生成模块211将所述交易明细数据归类划分，实时地将交易明细数据划分成多个子集；

步骤③、所述清分主模块220按上述段信息生成模块211生成的子集读取前置信息交换模块212入库的交易明细；

步骤④、所述交通卡打包转发模块221将交通卡交易数据打包转发交通卡公司；

步骤⑤、当系统发生异常时，异常处理模块222对异常数据进行处理；

步骤⑥、所述清分规则模块223生成清分规则，清分主模块220通过该清分规则进行数据清分；

步骤⑦、日终处理模块23与所述清分主模块220连接，获取所述清分主模块220清分得出的数据；

步骤⑧、结算模块234结算后形成银行划帐单，通过银行划帐单发送模块24发送到银行，实现业主收益资金的划拨。另外，查询余额模块25通过结算模块234更新数据，实现余额查询的功能。

以上实施例仅用以说明而非限制本发明的技术方案。如，日终处理模块23可以为其他特定时间区间的处理模块，处理其他特定时间区间内的数据。另外，本发明不仅可以使用于轨道交通的账务处理中，还可以用于其他交通的账务处理，甚至非交通行业的账务处理。不脱离本发明精神和范围的任何修改或局部替换，均应涵盖在本发明的权利要求范围当中。

Claims

1、一种轨道交通票务的帐务系统，包括数据库模块、数据处理模块，其特征在于：

所述数据处理模块包括清分预处理模块、清分模块、及终处理模块；

所述清分预处理模块包括前置信息交换模块、段信息生成模块；所述清分模块包括清分主模块、交通卡打包转发模块、异常处理模块、清分规则模块；所述终处理模块包括对帐模块、可疑帐务处理模块、报表生成模块、结算模块；

所述前置信息交换模块用于接收自线路中央发送来的交易明细数据，并将交易明细数据存入数据库模块；所述段信息生成模块用于将所述交易明细数据归类划分，实时地将交易明细数据划分成多个子集；

所述清分规则模块用于生成清分规则，清分主模块通过该清分规则进行数据清分；所述清分主模块与所述数据库模块、交通卡打包转发模块、异常处理模块、清分规则模块连接，按上述段信息生成模块生成的子集读取前置信息交换模块入库的交易明细，按所述清分规则模块生成的清分规则进行清分、统计；所述交通卡打包转发模块用于将交通卡交易数据打包转发交通卡公司；异常处理模块用于当系统发生异常时对异常数据进行处理；

所述终处理模块与所述清分主模块连接，获取所述清分主模块清分得出的数据。

2、如权利要求1所述的帐务处理系统，其特征在于，所述数据处理模块还包括银行划帐单发送模块；所述银行划帐单发送模块与所述结算模块连接。

3、如权利要求1所述的帐务处理系统，其特征在于，所述数据处理模块还包括查询余额模块，该查询余额模块与所述结算模块连接。

4、如权利要求1所述的帐务处理系统，其特征在于，所述数据库模块包括帐务处理数据库模块及历史数据库模块。

5、如权利要求4所述的帐务处理系统，其特征在于，所述数据处理模块还包括超期数据导入模块，其将超期数据明细插入历史数据库模块，插入成功的数据明细形成可疑帐调整明细写入帐务处理数据库模块。

6、如权利要求1或2或3或4或5所述的帐务处理系统，其特征在于，所述清分主模块为系统常驻进程。

7、如权利要求1或2或3或4或5所述的帐务处理系统，其特征在于，所述终处理模块为日终处理模块，处理每日的帐务。

8、如权利要求1或2或3或4或5所述的帐务处理系统，其特征在于，所述清分规则模块生成清分比例表。

9、如权利要求8所述的帐务处理系统，其特征在于，对于清分比例表扫描处理，将清分比例表设为内存表，数据库启动时将数据导入内存，清分处理时对于清分比例表的扫描在内存中操作。

10、如权利要求9所述的帐务处理系统，其特征在于，同一时刻，对于单个交通卡的每次使用只有一条清分比例信息；同一时刻，清分比例表分为当前数据表和历史数据表，当前数据表为cache表，历史数据表为普通表；当前数据表中保存当前版本与预置版本的清分比例，历史数据表中保存所有版本的清分比例；清分处理时，首先判断交易时间是否小于当前数据表中的当前版本的清分比例的启用时间，如果小于直接写入超期的可疑数据明细，由后续的超期数据明细处理模块对这部分数据明细进行清分。