四川航空直销对账系统的设计与实现

航空直销对账系统的设计与实现 璟20XX11月中图分类号：TP311.UDC分类号：004.航空直销对账系统的设计与实现作 者 姓 名 璟 学 院 名 称 软件学院 指 导 教 师 小林 答辩委员会主席 XXX 教授申 请 学 位 工程硕士 学 科 专 业 软件工程 学位授予单位 理工大学 论文答辩日期 20XX12月 Design and Implementation of Sichuan Airlines direct reconciliation systemCandidate Name： ChenJing School or Department:Software SchoolFaculty Mentor:ZhaoXiaolin Chair, Thesis Committee：Prof. XXX Degree Applied:Master of Engineering Major： Software EngineeringDegree by: Beijing Institute of TechnologyThe Date of Defence： Dec,2014XX航空直销对账系统的设计与实现 理工大学研究成果声明本人重声明：所提交的学位论文是我本人在指导教师的指导下进行的研究工作获得的研究成果。尽我所知,文中除特别标注和致的地方外,学位论文中不包含其他人已经发表或撰写过的研究成果,也不包含为获得理工大学或其它教育机构的学位或证书所使用过的材料。与我一同工作的合作者对此研究工作所做的任何贡献均已在学位论文中作了明确的说明并表示了意。特此申明。 签 名： 日期：关于学位论文使用权的说明本人完全了解理工大学有关保管、使用学位论文的规定,其中包括：学校有权保管、并向有关部门送交学位论文的原件与复印件；学校可以采用影印、缩印或其它复制手段复制并保存学位论文；学校可允许学位论文被查阅或借阅；学校可以学术交流为目的,复制赠送和交换学位论文；学校可以公布学位论文的全部或部分容学位论文在解密后遵守此规定。 签 名： 日期： 导师签名： 日期：66 / 74摘要本文所研究并实现的直销对账系统用于航空运输业,以销售数据配置及管理自动化对账处理对账结果调整的三个核心业务为主线,能够及时地、高效地对来自直销系统、银行支付公司的明细数据进行核对,确保会计核算的正确性,从而避免销售损失、提高用户满意度,还能通过排查错误原因提出对直销系统的优化建议。本系统以java技术为基础,以Eclipse为开发工具,以MySql作为底层数据库,按照系统需求分析、系统设计、系统实现、系统测试部署的思路进行设计与实现。系统包含了数据收集、数据转换、数据对比、数据展示等功能。本系统需要从不同的异构系统中抓取、分析、对比数据,并且数据量较大、对对账结果的实时性要求较高,因此如何保证系统有足够的灵活性、可扩展性、高可用性是其难点。首先,采取模块化开发方式,将功能模块划分为：基础设置模块、系统管理模块、数据收集模块、数据转换模块、数据对比模块以及对账结果展示模块等。其次,遵循面向对象的设计思想,采用SSHStruts、Spring、Hibernate开源框架,保证系统松耦合、可扩展。系统试运行后表明：实现了预期的建设目标,在节约人力成本、提升工作效率、降低工作差错方面取得了良好的应用效果,目前已在航空财务部门中正式投产运行。关键词： 航空运输；会计核算；对比数据；SSH。 ABSTRACTDirect reconciliation system is studied and implemented in this paper for the air transport industry, with sales data configuration and management - automated reconciliation processing - three core business reconciliation result adjustment as the main line, timely, efficient for comes from direct system, bank the detail data check, ensure the accuracy of accounting in order to avoid losses, sales, improve user satisfaction, but also through the causes of error optimization of the recommendations put forward to direct the investigation system.The system is based on Java technology, using Eclipse as the development tool, uses MySql as the database, according to the system demand analysis, system design, system implementation, system testing deployment ideas for design and implementation. The system includes data collection, data conversion, data comparison, data display and other functions.The system needs to grasp, from different heterogeneous systems analysis, comparative data, real-time requirements and a large amount of data, for reconciliation results is higher, so how to ensure that the system has sufficient flexibility, scalability, high availability is one of the difficulties. Firstly, adopt modularization mode, the function module is divided into: basic setting module, system management module, data collection module, data conversion module, data comparison module and the reconciliation results display module etc. Secondly, following the idea of object-oriented design, using SSH open source framework, to ensure the system loosely coupled, extensible.The test result of the system shows that: to realize the expected goal of building, and achieved good application effect in saving manpower cost, improve work efficiency, reduce working errors, now in the Sichuan aviation Finance Department formally put into operation.Key Words：Air transport; accounting; data correlation; SSH.目录第1章绪论11.1 研究背景11.2 研究目的与意义11.3 研究现状21.4 研究容21.5 本文的组织结构3第2章系统需求分析42.1 系统总体功能目标42.2 面向的用户群体42.3 基础原理及业务需求综述52.4系统功能模块划分82.4.1通用业务需求92.4.2数据获取业务102.4.3数据处理业务102.4.4基础业务112.5 系统用户需求122.5.1 所有用户132.5.2系统管理员132.5.3 对账业务管理员142.5.4 机器人172.5.5 对账操作员182.6 非功能需求212.6.1 对用户重要的属性212.6.2 对建设者重要的属性222.7本章小结22第3章系统设计233.1 系统架构设计233.1.1 逻辑架构视图233.1.2 开发架构视图243.1.3 数据架构视图283.2系统功能模块设计293.2.1自动收集数据模块293.2.2自动转换数据模块303.2.3自动对账模块333.3系统界面设计353.4系统数据库设计353.4.1 数据库环境说明353.4.2 数据库的命名规则353.4.3 逻辑设计353.4.4 物理设计363.5 本章小结41第4章系统实现424.1 实现环境424.2 系统主界面424.3 系统工具424.3.1 外部数据源424.3.2 用户管理444.4 配置管理464.4.1 对账数据配置464.4.2 对账业务配置484.4.3 对账操作员管理504.5 对账业务524.5.1 对账结果处理524.5.2 手工对账功能554.6 本章小结56第5章系统测试与部署575.1 测试环境575.2 系统的测试595.2.1功能测试595.2.2性能测试625.3 本章小结62结论63参考文献64致66第1章 绪论1.1 研究背景航空以下简称川航成立于1986年9月19日,1988年7月14日正式开航。从成立至今,航空已经安全飞行25年,连续盈利16年。受益于中国经济的不断增长,川航十二五规划的目标是建成百架飞机、千亩土地、万人企业、产值翻番的大平台,走多枢纽网络型发展道路,成为最受西南区域主流市场欢迎,全国最具特色化服务竞争优势,员工热爱的航空公司。目前,川航已经拥有空中客车飞机84架,为国最大的全空客机队航空公司。要在航空运输业中形成竞争力,必须做好安全、服务两个方面的工作。由于川航增长快速,各类业务的数据量也增加巨大,因此川航近年来非常重视信息系统的建设,尤其重视拥有核心竞争力的自主研发软件项目建设,以更有效地达到安全、效益、服务两个方面的工作目标。1.2 研究目的与意义本次选题的航空直销对账系统,是根据机票直销业务定制的综合性系统。主要通过相关数据采集、数据比对、异常情况预警等功能,监控票款回笼情况,以及通过灵活报表输出功能满足财务人员对公司机票直销情况的统计。即可以提高财务人员对大量数据进行结算分析的工作效率,又可以降低人工进行数据分析的差错率。本研究的意义主要体现在如下4个方面：1节约人力成本：即依托信息系统对成熟的业务流程进行优化,达到更佳的人力资源投入。2提升工作效率：利用信息系统可以自动化处理数据的特性,提高工作人员的效率。3降低错误风险：利用信息系统稳定、快速的特性,减少人工劳动差错,提高数据处理频度。4提升旅客服务满意度：通过比人工劳动更高效的信息系统可以及时发现支付差错问题,间接提高旅客服务满意度。以上4个方面的详细量化指标,请参阅2.1系统总体功能目标章节。1.3 研究现状川航已经建成自己的首个机票直销,即B2C机票直销。财务人员采用手工方式对销售数据进行核对。伴随电子商务技术的不断进步,川航也不断细分直销业务,先后建成了呼叫中心销售系统、大客户销售系统、手机直销系统、福利优免票管理系统等。支持的银行支付公司也多达10多家。由于销售单据的大幅增长,财务人员非常需要信息系统帮助进行直销对账工作。本文就是在此基础上开展直销对账系统的研究。1.4 研究容本文的主要研究容如下：一是对直销对账系统进行需求分析。首先与业务部门高层进行交流,确定量化的系统总体功能目标,作为今后系统验收的标准；然后确定用户群体,收集业务需求,明确业务流程；最后对需求进行分析,把需求细化到每个系统用例。二是对直销对账系统进行详细设计。在系统设计原则的基础上进行系统架构设计,用不同的视图表述系统架构。随后进行系统界面原型设计,用更直观的界面原型图片印证业务人员、开发人员对需求的理解是一致的。最后进行系统的数据库设计,给出系统设计的E-R图以及数据库表。三是系统的实现。系统实现是软件生命周期的一个重要阶段,是在系统需求分析、系统总体设计以及功能模块的设计基础上进行编程开发,并以核心代码和代表性界面为成果来介绍系统的功能实现。四是系统的测试。系统的测试是软件生命周期的最后一个阶段,通过设计测试实例来执行相应程序,从而发现系统中存在的某些系统缺陷与错误。1.5 本文的组织结构本文分为六个部分,容组织结构如下：第一部分：绪论。主要介绍本文的课题来源、研究背景、研究目的与意义以及研究容的论述。第二部分：系统需求分析。介绍系统的总体功能目标、面向的用户群体、功能模块划分、需求用例、非功能需求。第三部分：系统设计。包括架构设计、界面设计、数据库设计。第四部分：系统实现。按照模块化设计的思想,分功能模块介绍系统实现的各项功能,并给出实现界面。随后介绍系统的运行软硬件环境。第五部分：系统测试与部署。包括系统的功能测试、性能测试以及系统的部署情况。第六部分：结论。总结全文,给出本文所进行的工作,并总结不足之处,对下一步的研究进行展望。第2章 系统需求分析本章对直销对账系统的需求进行了详细描述,包括建设目标、用户群体、业务需求、非功能性需求、用户需求五个方面。2.1 系统总体功能目标直销对账系统建设的目标是：1节约人力成本：目前每天通过直销系统售出的电子客票有44000,每月约有1320000电子客票。若假设每天都需要对比各类直销数据、共有20类直销数据、对比单类直销数据需耗时60分钟,估算每天需要投入20个工时专门从事该工作。若有系统支持自动完成数据对比工作,可以节省大概3个人。2提升工作效率：财务人员目前每次需要花费5分钟时间从各类系统下载直销明细数据,那么每月仅仅在数据获取这一块就会花费掉1-2个工时。若用程序代替人工,这部分工作将会在每天的夜间由系统自动进行,然后完成对账工作,并在翌日直接生成报表,大大提升工作效率。3降低错误风险：目前的人工方式势必在数据匹配对比过程中会存在或发生一定的错误,而通过程序基本上可以杜绝不必要的数据对比错误。另外,采用系统后,可以把每周1次的对账频度提高到每天1次,大大降低资金差错风险。4提升旅客服务满意度：如果旅客已经付款但直销系统没有给旅客出票,就会造成旅客不能出行,降低旅客满意度。通过比人工劳动更高效的信息系统可以及时发现此类问题,间接提高旅客服务满意度。2.2 面向的用户群体1财务部销售收入室会计2财务部国际业务室会计3财务部销售收入分管领导4市场部直销业务分管领导2.3 基础原理及业务需求综述机票直销类系统都有一个共同点：实现了在线支付功能。其实,直销对账工作是伴随在线支付而产生的,目的是为了监控在线支付业务的差错。如图2.1所示的经典在线支付流程,保障了在线交易基本的安全性。如：直销系统生成待支付表单,避免了用户伪造应付金额；用户直接把支付卡号、密码提交给银行,避免了直销系统获取用户敏感信息；银行把支付结果分别通知用户、直销系统,避免单方面伪造支付结果等。在线支付流程如图2.1所示：图2.1 在线支付流程图上述支付流程虽然较完善,但因为一些异常情况会导致支付差错。如：1.用户在银行完成了支付,但因为网络故障,银行没有把支付结果告知直销系统,就会导致机票没有订购好；2.直销系统自身有bug,导致待支付表单中的应付金额错误,造成损失。目前财务人员对账工作流程图2.2所示：图2.2 当前人工对账流程首先从直销系统获取数据,数据容如表2.1所示：表2.1从直销系统获取的数据支付订单号支付金额订单状态交易日期GSB1800已出票2013-10-01GSB2650未出票2013-10-01GSB31200已出票2013-10-02GSB41000已出票2013-10-02GSB5900已出票2013-10-03GSB7850已出票2013-10-03然后从银行支付公司获取的数据,数据如表2.2所示：表2.2 从银行获取的示例数据支付订单号银行支付金额支付状态支付日期GSB1800已支付2013-10-01GSB2650已支付2013-10-01GSB31200已支付2013-10-02GSB41000未支付2013-10-02GSB5910已支付2013-10-03GSB6720已支付2013-10-03将这两个数据进行手工对比,结果如表2.3所示：表2.3 对账结果示例数据支付订单号金额银行金额支付日期对账结果GSB18008002013-10-01正确GSB26506502013-10-01错误：未出票GSB3120012002013-10-02正确GSB4100010002013-10-02错误：未支付GSB59009102013-10-03错误：支付金额不对GSB67202013-10-03错误：直销系统无数据GSB78502013-10-03错误：银行无数据为解决支付差错问题,财务部需要及时地将直销系统数据、银行支付公司数据进行数据匹配,从而检查销售数据是否正确,资金收入是否完整。在理解了当前业务流程后,确定了今后有对账系统支持的优化流程,如图2.3所示：图2.3 优化后的对账业务流程2.4系统功能模块划分本文按照软件工程的思想,采用模块化设计方法,自顶向下进行设计,因此,本文需要按照系统要求以及业务部门要求进行模块划分。同时,通过面向对象设计实现可拆装性,提高系统的通用性,本系统功能划分如表2.4所示。表2.4 系统功能划分业务类别业务需求通用业务需求登录退出修改密码用户管理权限管理数据获取业务数据获取数据处理业务数据匹配数据调整基础业务系统查询功能自动生成报表功能数据人工补录功能2.4.1通用业务需求登录使用本系统的用户应该首先登录系统,通过认证后方可继续使用其它功能。为规管理,应使用员工号作为登录名；为保证账号安全,登录密码应符合一定的复杂度要求。密码按照手册规定的复杂程度应为6位及6位以上,必须包含数字,字母,特殊符号的其中两种,且在登录时必须输入验证码。退出登录用户可以通过关闭程序,退出系统使用。再次使用,必须重新登录。修改密码用户可以修改自己的密码。为保证安全,修改密码时必须提供当前密码,并且密码输入框不显示明文。用户可以在门户系统修改自己的密码,修改后可用新密码登录本系统。用户管理管理员可以对系统的用户进行新增、修改、密码重置、停用操作。权限管理管理员可以针对不同的用户分配不同的权限。即国会计只能操作国销售数据和报表,而国际会计只能操作国际销售数据和报表。2.4.2数据获取业务数据获取系统需通过接口从支付公司、银行、自动导入电子客票的支付数据和退款数据,并保存在数据库中。自动导入程序在每天晚上凌晨进行。具体的支付公司、银行、包括如下：支付公司：易宝、快钱、银联、支付宝、汇付、财付通银行：工商银行、农业银行、招商银行、中国银行数据：B2B平台,B2C平台,海外B2C财务结算系统另外,财务结算系统每日会将电子客票的支付数据和退款数据存于服务器上,需要对账系统自行抓取,用于数据处理业务。2.4.3数据处理业务数据匹配系统所涉及的电子客票对账数据分为支付数据和退款数据两大模块,两个模块的数据匹配方法相同。功能如图2.4所示：图2.4 功能示意图数据匹配方法：银行/支付公司与通过银行订单号、交易日期、金额进行匹配；财务结算系统与通过票号、交易日期、金额票面价/机建/燃油、航段进行匹配。保险公司数据与保险统计报表通过票号、保单金额进行匹配.系统在设定的时间将获取到多方数据按照以上的数据匹配方法进行自动匹配。完成匹配后,将无法匹配的客票进行提示,并能导出无法匹配的客票报表。无法匹配的情况包括：金额不匹配、航段不匹配、单边账情况等。数据调整针对以上出现无法匹配的提示信息,对账人员可以点击提示信息,进入不匹配客票的详细查看页面,对数据源以及不匹配原因进行检查,并就不匹配的对账结果,根据实际客票情况,可进行适当的手工修改调整。修改完毕后,由对账人员手工再次对无法匹配的客票进行匹配工作,并将匹配完成的正确信息自动录入数据库。同时,系统需要记录系统自动匹配和对账人员手工调整的所有操作日志。2.4.4基础业务系统查询功能对账人员通过日期、电子客票票号、银行订单号等查询条件查询到每电子客票的对账日志记录,包括自动匹配记录和人工进行修改调整的记录。对账人员通过日期、电子客票票号、银行订单号等查询条件可以在不匹配统计列表页对特定的客票进行查询,查询结果包括客票相关数据源,客票匹配情况,客票操作情况。自动生成报表功能系统定时生成固定格式的每种支付方式下的三报表报表样板见附件一：固定报表样表供对账人员自行下载。支付方式包括：易宝、快钱、银联、支付宝、支付宝快捷支付、支付宝无线支付、汇付、财付通、工商银行网银支付、工商银行信用卡支付、农业银行网银支付、农业银行信用卡支付、招商银行网银支付、招商银行信用卡支付。数据人工补录功能系统提供数据获取监控功能,对账人员可以通过该功能知道当前每种数据源是否已通过接口获取完毕。对于获取失败和漏获取的情况,通过导入报表等形式进行人工数据补漏,并且在补漏后通过对账人员选择进行重新的数据匹配。灵活报表功能系统根据以上的对账规则得出对账结果,用户可以根据自己的需要选择查询结果显示容,并通过输入日期时间段,查询得到需要的报表。2.5 系统用户需求用户需求如表2.5所示：表2.5 用户需求表用户角色用例优先级所有用户登录系统高退出登录高系统管理员注册用户高修改用户操作权限高注销用户高查看操作日志中外部数据源管理低机器人执行数据收集任务低执行数据转换任务中执行对账业务高对账操作员发起人工对账任务高查询对账结果高删除对账结果高对账差错处理高查看对账结果明细高下载源数据中导出对账结果中查询报表中导出报表中调账高对账业务管理员查看外部数据源低配置对账业务低配置转换数据业务低配置核对业务低分配对账操作员低2.5.1 所有用户用户角色用例如图2.5所示：图2.5 系统用户用例图2.5.2系统管理员用户角色用例如图2.6所示：图2.6 系统管理员用例图2.5.3对账业务管理员用户角色用例如图2.7所示：图2.7 对账业务管理员用例图查看外部数据源需求如表2.6所示：表2.6 外部数据源用例名称查看外部数据源执行者对账业务管理员用例描述通过此功能查看外部对帐源的数据接口前置条件系统管理员已经新增外部数据源执行结果可管理外部数据接口主要过程进入查看数据数据接口功能展示外部对账源数据接口列表,展示所有可用外部对账源数据接口业务规则外部对账源提供的数据下载地址需为FTP协议。下载文件格式限定为为csv、txt、xls、xml、json等数据文件。涉及实体外部数据源：数据源类型B2C、B2B、航线销售、保险、银行、第三方,数据源名称、数据源接口地址、文件存储类型、是否为多个文件、本地存储路径、获取文件频率、数据典型结构。配置对账业务需求如表2.5所示：表2.5 配置对账业务用例名称配置对账业务执行者对账业务管理员用例描述定义、管理对账义务规则,供对账机器人对账使用。前置条件系统管理员已经新增外部数据源执行结果可管理对账业务规则。主要过程配置对账业务功能包括配置转换数据业务功能与配置核对业务功能。配置转换数据业务,具体功能参见配置转换数据业务用例。配置核对业务,具体功能参见配置核对业务用例。配置完成后,转换数据业务规则与核对业务规则将应用到转换机器人、对账机器人自动对账功能中。记录操作日志。涉及实体外部数据源：数据源类型B2C、B2B、航线销售、保险、银行、第三方,数据源名称、数据源接口地址、文件存储类型、是否为多个文件、本地存储路径、获取文件频率、数据典型结构。转换数据业务规则：外部数据源、转换数据列、对应外部数据源文件列、对应规则、转换规则、转换数据频率。核对业务规则：起始数据源、目标数据源、匹配数据列、核对数据列、展示数据列、核对规则、核对频率等。配置转换数据业务需求如表2.7所示：表2.7 配置转换数据业务用例名称配置转换数据业务执行者对账业务管理员用例描述定义转换数据业务规则,规定对账机器人转换对账数据源文件的转换原则。前置条件系统管理员已经新增外部数据源执行结果成功录入转换数据业务规则,并可对其进行管理使用频度较低,主要在新加入对账源时使用主要过程进入配置转换数据业务功能。展示转换数据业务规则列表。点击新增规则,进入新增规则页面,跳转到4。选择外部数据源,判断该数据源是否已经被配置到其他业务规则,如果已经配置到其他转换数据规则,跳转到异常4.1,通过则继续执行。添加转换数据列可多个,包括数据列名称、对应外部数据源文件列名可选多个、对应规则如转义、校验、修改规则。设置转换数据频率。点击保存,保存成功。记录操作日志。分支过程可对已有的转换规则进行修改或删除,点击修改、删除功能时,先校验转换数据机器人是否已经使用该规则转换过源数据,是则跳转到异常,否则可修改或删除转换规则。异常过程提示所选数据源已经被使用到其他转换规则中,不能被重复转换。提示继续修改或删除转换规则会造成前后数据错误,如果继续将删除已有转换数据。业务规则一个数据源只允许存在于一个转换数据规则中。已经转换过数据的转换规则不允许随意修改或删除,若必须修改,则需删除之前对账数据涉及实体外部数据源：数据源类型B2C、B2B、航线销售、保险、银行、第三方,数据源名称、数据源接口地址、文件存储类型、是否为多个文件、本地存储路径、获取文件频率、数据典型结构。转换数据业务规则：外部数据源、转换数据列、对应外部数据源文件列、对应规则、转换规则、转换数据频率。用户操作日志：时间、登录名、操作退出登录、关键ID、摘要、客户端IP配置核对业务需求如表2.8所示：表2.8 配置核对业务用例名称配置核对业务执行者对账业务管理员用例描述定义数据核对业务规则,规定对账机器人进行数据核对时的业务规则。前置条件已配置转化数据规则执行结果成功录入转换数据业务规则,并可对其进行管理使用频度较低,主要在新加入对账源时使用主要过程进入配置核对业务功能。展示核对业务规则列表。点击新增规则,进入新增规则页面,跳转到4。选择核对业务类型支付核对、退款核对、销售日报核对、保险核对添加起始数据源B2C、B2B,添加目标数据源支付、航线、保险公司。根据选择数据源的数据转换规则展示可核对列。添加须匹配数据列可多个,包括起始源数据列、目标源数据列、匹配规则。添加须核对数据列可多个,包括起始源数据列、目标源数据列、核对规则。设置数据源核对规则如订单号值相同的行要进行累加设置核对数据频率。点击保存,保存成功。记录操作日志。分支过程可对已有的核对规则进行修改或删除,点击修改、删除功能时,先校验核对数据机器人是否已经使用该规则核对过数据,是则跳转到异常,否则可修改或删除规则。异常过程提示继续修改或删除核对规则会造成前后数据错误,如果继续将删除已有核对结果数据。业务规则起始数据源可按分配多个数据源,各数据源的的数据将累加核对。目标数据源可按分配多个数据源,各数据源的的数据将累加核对。匹配数据列规定按什么原则进行数据匹配,核对数据列规定要根据匹配规则对什么数据进行核对。涉及实体外部数据源：数据源类型B2C、B2B、航线销售、保险、银行、第三方,数据源名称、数据源接口地址、文件存储类型、是否为多个文件、本地存储路径、获取文件频率、数据典型结构。转换数据业务规则：外部数据源、转换数据列、对应外部数据源文件列、对应规则、转换规则、转换数据频率。核对业务规则：起始数据源、目标数据源、匹配数据列、核对数据列、展示数据列、核对规则、核对频率等。用户操作日志：时间、登录名、操作退出登录、关键ID、摘要、客户端IP分配对账操作员需求如表2.9所示：表2.9 分配对账操作员用例名称分配对账操作员执行者对账业务管理员用例描述定义并分配对账操作员,不同对账操作员只能查看与处理其操作围的账目数据。前置条件无执行结果成功分配对账操作员,并可对其进行管理使用频度较低,主要在系统初始化及添加对账操作员时使用主要过程进入分配对账操作员功能。展示对账操作员列表。点击新增操作员,进入新增页面。系统展示所有系统用户及其已有的对账权限,可进行点选及多选选择用户后进入选择对账权限页面,系统展示所有以配置的对账规则,供管理员进行选择点击保存,系统验证该对账业务权限是否已经适配给该用户,如果已经分配,跳转到异常6.1,如果没有分配,则将管理权限分配给相关用户,并提示分配成功。记录操作日志。分支过程可对已有的人员的业务权限进行修改或删除异常过程提示该用户已经分配了该对账权限。业务规则一个用户可拥有多个对账业务的处理权限。涉及实体操作员权限：用户名、对账权限列表。对账权限：核对数据围、查看数据围、管理数据等级查看、管理、删除。用户操作日志：时间、登录名、操作退出登录、关键ID、摘要、客户端IP。2.5.4机器人用户角色用例如图2.8所示：图2.8 机器人用例图以上三类型机器人,也就是自动程序。该程序通过计时器触发执行数据处理工作。其详细的模块、流程设计请参考3.2系统功能模块设计章节。2.5.5对账操作员用户角色用例如图2.9所示：图2.9 对账操作员用例发起人工对账任务需求如表2.10所示：表2.10 人工对账任务需求用例名称发起人工对账任务执行者对账操作员用例描述用户手动点击按钮发起对账操作任务前置条件已取得对账操作员权限,对账源数据未能自动获取或者该渠道不提供自动数据源获取服务执行结果获得对账结果报表使用频度较高主要过程由该操作员手工上传该渠道源对账数据文件到系统,上传步骤参见分支1.1,上传错误文件格式转到异常1.1源数据已上传或者存在与系统之后,点击对账按钮由系统进行即时对账操作,对账文件容格式错误转到异常2.1点击对账按钮后,则返回对账结果查询页面,等待对账执行结果,正常情况下等待5-10分钟,将会看到查询页面显示已完成对账的对账记录分支过程上传源数据：对账操作员选择需要手动对账渠道类别,查看是否存在源数据如果源数据存在,先删除已有源数据最后上传该渠道类别源数据异常过程1.1 上传文件格式不符,将给予异常提示2.1 文件容格式错误,应给出明确错误提示3.1 对账结果等待超过15分钟以上,需要给出异常提示,提示用户联系系统管理员业务规则对应业务的对账操作员只能进行所属渠道业务的对账操作对账源数据上传如果源数据存在,必须先删除已有源数据,再进行上传文件格式支持txt、xml、xls、xlsx、csv文件名要求标识出该数据源时间如果文件为压缩包形式,则请使用.zip、.rar格式的压缩包对账操作为异步对账,等待时间限制不超过15分钟涉及实体文件上传：对账类别、对账时间、上传文件路径、上传时间文件容：日期、电子客票票号、银行订单号、对账状态、票面价、税费、机建、燃油、保险等查询对账结果需求如表2.11所示：表2.11 查询对账结果用例名称查询对账结果执行者对账操作员用例描述对账操作员对对账结果进行查询前置条件已经生成过对账结果或者正在进行对账执行结果根据查询条件,正确显示出对账结果列表使用频度高主要过程根据业务要求,选择或输入查询条件,可以通过对账状态字段分别查询已完成对账和正在对账中的记录根据查询条件点击查询按钮进行查询操作显示出查询结果列表已完成对账的记录结果可以通过点击查看明细数据,参见用例4.4.5,正在对账中的记录则需要等待其完成对账后才能查看明细分支过程异常过程查询条件填写格式错误时,应给出明确错误提示2.2 查询结果为空时,应提示没有符合查询条件的对账结果业务规则权限：对应业务操作员仅能查看自己权限的对账结果查询结果：结果的对账记录是按对账任务时间显示只有已完成对账的任务记录才能查看明细对账数据涉及实体查询条件：对账类别支付,退款、渠道类别、对账时间、数据日期、对账状态查询结果：对账类别支付,退款、渠道类别、对账时间、数据日期、对账状态、对账结果对账差错处理需求如表2.12所示：表2.12 对账差错处理用例名称对账差错处理执行者对账操作员用例描述对账操作员可以对对账未成功的对账结果进行差错调整处理前置条件已进行对账操作,并且对账结果无法完全匹配执行结果对无法匹配数据进行备注调整,重新再匹配使用频度高主要过程通过用例4.4.2查询出对账结果列表,对账状态为匹配失败的则表示对账出现差错需要处理点击该条匹配失败的记录进入不匹配客票的明细查询页面查找明细数据中不匹配对数据源以及不匹配原因进行检查,判断错误原因：收集数据失败转换数据失败对账失败根据实际客票情况,在确定数据不匹配的原因之后,进行处理收集数据失败则需要手动上传源数据,重新进行手动对账操作,转到分支1.1；转换数据失败则需要排查失败原因,处理后重新启用数据转换机器人的服务,转到分支1.2；对账失败同理也是根据具体失败原因作出相应的处理；分支过程匹配失败原因确定为收集数据失败：表示源数据获取失败,则需要进入用例人工对账任务,重新上传源数据之后再开始对账操作匹配失败原因确定为转换数据失败：则需要手动执行机器人转换数据的用例,并检查是否转换成功,再进行手动对账异常过程查询过程中,输入格式不正确,应给出错误提示业务规则对应业务操作员只能调整所属渠道类别的对账结果涉及实体对账结果查询：对账类别支付,退款、渠道类别、对账时间、数据日期、对账状态查询结果：对账类别支付,退款、渠道类别、对账时间、数据日期、对账状态、对账结果、对账失败原因2.6 非功能需求2.6.1 对用户重要的属性安全性需求系统运行于Intranet,运行在公用服务器上。安全性需求包括金额,票号,银行订单号等均属于级别。系统密码需加密存放。系统所涉及的数据如外泄,会对公司的销售造成影响,严重的话甚至致使整个收益降低。因此要保证经过授权的人才能使用系统。使用人员全部是公司部人员。外部人员不能访问系统。可扩展性需求系统在数据量上会持续增长,目前直销平台每天出票数约为44000,初步估计每年按照20%的增长,预计未来3年每天最多出票数会达到52800。且随着业务产品的丰富化,数据的多样性会越发的复杂,故系统规模会不断扩大。由于系统涉及数据量比较大,需要业务部门根据数据情况,不定时进行数据归档保存工作。归档的数据可较方便的进行查询。互操作性需求在系统投入运行后的并发用户量不多,且多数时候是对数据读访问,并发写入数据的几率不大。无需考虑事务性处理。对于系统中涉及到金额的数据,需保留两位小数,其他数据均为整数。对于查询操作,如果长时间无法显示统计结果需提供一定的进度提示或取消操作。系统与多个系统有联系。系统需要定时异步的从对应的系统中获取需要的数据。健壮性需求系统保持5*8小时可用,不在这段时间进行停机维护。2.6.2 对建设者重要的属性可维护性需求每个类、函数、变量均保证有准确易懂的声明注释,且在函数部的关键步骤要添加注释。整体代码注释量比例不低于10%。系统需要调用多个系统的数据接口。还需要访问数据库,因此需要将该信息写入到配置文件中,以便开发或运维人员灵活配置。系统对账、报表业务复杂、灵活,需要做到动态可配置,适应以后业务需求的变化该系统在公司部使用,且授权用户登录名和密码是通过门户进行验证。该系统在公司部使用,但不同的用户管理的资料不同,所以需要分权限进行操作,不仅需要对授权用户的页面访问权限进行控制,还需要对其访问的数据进行限制。可重用性在开发阶段建议把各模块中公用的功能点提取出来封装到公用组件中,以方便使用和修改。可测试性需要记录系统登录用户的操作日志。并记录系统同步日志。可以对这些日志进行查询。用户利用登录账号,可以查询到该账号的系统使用情况。应记录操作日志和系统错误日志。操作日志：操作时间、操作人、进行的操作、数据摘要、IP地址。系统错误日志：发生时间、模块名、数据摘要、错误详细信息。2.7本章小结本章首先对所实现的系统进行总体功能目标研究,按照一定的划分原则进行功能模块的划分,然后对系统进行业务分析,最后进行系统数据流程分析。第3章 系统设计本章按照架构设计界面设计数据库设计的思路进行,重点进行系统架构的搭建、界面的功能设计以及数据库的概念设计、逻辑设计。3.1 系统架构设计3.1.1 逻辑架构视图逻辑架构如图3.1所示：图3.1 逻辑架构图从上图可以明确看出,系统被划分为两大类子系统,分别是与用户交互的子系统和与程序交互的子系统,而在外部数据系统中包括了快钱,招行,保险,财付通,支付宝等外部数据接口或文件服务。在与用户交互子系统中,细分出了电子客票对账和报表系统两个子系统,这两个子系统实现了用户进行电子客票对账的业务操作流程以及对帐结果的报表汇总处理。电子客票对账主要功能职责：用户管理：对用户权限,角色进行管理。对账配置管理：负责对账业务的对账数据,对账规则,对账操作员等容进行管理。手工对账：实现人工对账业务的功能。结果查询：负责对账结果的查询,以及结果调整等功能。灵活报表系统主要功能职责：负责对账结果的汇总统计,并根据用户需求生成灵活报表以供用户查询以及下载。在与程序交互的子系统中,划分了数据收集、数据转换、业务对账三大子系统程序,实现了用户需求中机器人角色功能。数据收集子系统主要功能职责：通过FTP文件工具等方式,对接其他外部数据系统,收集获取外部源数据文件。数据转换子系统主要功能职责：对经过数据收集子系统获取到的源数据文件根据业务配置规则进行转换。对账业务子系统主要功能职责：对经过转换后的数据进行业务对账操作,并将最后对账结果存储在数据库中。3.1.2 开发架构视图根据对逻辑架构的分析、设计,综合考虑,将项目划分为五个工程开发,分别为：直销对账：管理站点Web工程获取数据机器人：自动程序Java工程转换数据机器人：自动程序Java工程对账机器人：自动程序Java工程直销对账组件：逻辑业务组件Java工程 直销对账直销对账开发架构如图3.2所示：图3.2 直销对账开发架构图获取数据机器人获取数据机器人开发架构如图3.3所示：图3.3 获取数据机器人开发架构图转换数据机器人转换数据机器人开发架构如图3.4所示：图3.4 转换数据机器人开发架构图-对账机器人对账机器人开发架构如图3.5所示：图3.5 对账机器人开发架构图直销对账组件直销对账组件如图3.6所示：3.6 直销对账组件开发架构图3.1.3数据架构视图数据架构如图3.7所示：图3.7 数据架构图持久化存储方案如表3.1所示：表3.1存储方案表数据名称存储方案生产数据库DataCheck估算每月会有20万笔数据,数据量较大。因此：1.保留1.5年的数据,过期数据每月自动清除。2.根据业务围,不同的数据表划分到不同的数据文件存储。3.详细表设计,将在后续的数据库设计阶段体现。临时数据库DataCheckTemp该库仅仅保留中间过程的临时数据。因此：1.系统保证完成对账后,就删除临时数据。2.不需要对该数据库进行备份。3.详细表设计,将在后续的数据库设计阶段体现。系统日志数据库ScalBTSLog按照：30种类对账业务、每个对账业务会产生20个操作日志、每天都要操作1次来进行估算,每年的数据量不超过21900条数据,数据量较少,因此：1.可保留3年数据,过期数据每年手动清除；2.详细表设计,将在后续的数据库设计阶段体现。数据库备份文件1.备份文件除在本机保存外,还应异地保存。2.定时备份,详情参考数据同步与复制策略。对账源数据1.以平面文件形式,保存在目录下。2.定时从各个业务应用系统获取,但由于各个系统不同,因此本次开发要保证灵活性、可扩展性,详情请参考需求说明书。错误日志1.以平面文件形式,保存在目录之外。2.日志根目录下,每月一个子目录,其中包含每天一个的日志文件。3.运维巡检可以删除6个月前的日志。调试日志1.以平面文件形式,保存在目录之外。2.日志根目录下,包含每天一个的日志文件。3.运维巡检可以删除5天前的日志。3.2 系统功能模块设计系统功能模块如图3.8所示：系统功能模块自动收集数据模块自动转换数据模块自动对账模块图3.8 系统功能模块3.2.1自动收集数据模块自动收集数据模块的主要工作是从各个业务应用系统获取供对账使用的数据原文件。从需求我们知道,直销对账系统要处理的数据种类有：直销订单数据来自川航B2C、支付交易数据来自工行、银联等支付公司、保险单数据来自保险公司等。由于这些数据源文件是不同公司开发、提供的,因此需要设计通用、稳定的程序来执行收集数据任务。自动收集数据流程如图3.9所示：图3.9 自动收集数据流程图3.2.2自动转换数据模块不同的数据源文件格式容均不相同,如：1.银联是xml格式、工行是txt格式空格作分隔符、B2C是excel；2.银联数据中,第二列不是银行支付金额,而是支付状态；3.工行数据中,第一列不是支付订单号,而是支付日期；4.银联下载的支付金额单位是分,工行是元；5.银联表示已支付的值是1001！工行表示已支付的值是支付成功已清算；6.银联的支付日期数据格式20091001。工行的支付日期数据格式2009-10-01,支付时间格式12:12,并且是两列数据；为了能够顺利进行后续的对账业务,需要对每种数据源的格式、转换规则进行配置,然后利用自动转换模块对源数据进行转换。接口IReadFromFile定义了一个ReadLine方法,目的是每次从元数据文件读取一行数据,其输出结果是按照数据列或分隔符拆分好的字符串数组。然后开发了具体实现该接口的三个类,分别从Excel、Text、XML文件读取数据。读取数据文件类如图3.10所示：图3.10 读取数据文件类图对于包含已经拆分好数据列的字符串数组,还要进行必要的数据转换。为此,定义了数据列转换规则,如表3.2所示：表3.2 数据列转换规则类型格式说明直接引用