智慧校园校园一卡通解决方案.doc

《智慧校园校园一卡通解决方案.doc》由会员分享，可在线阅读，更多相关《智慧校园校园一卡通解决方案.doc（112页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、智慧校园校园一卡通解决方案1.1.1. 系统总体设计本项目将结合学校的实际需求，为学校打造新一代校园一卡通平台，进一步提高校园的管理、服务和决策的效率及水平。本方案一卡通的特点： 以软件架构而不是以硬件设备为中心的校园一卡通系统； 实现软硬分离、可集成多家厂商设备的校园一卡通系统； 用户自主生成和管理密钥的一卡通系统； 大集中模式的校园一卡通系统； 插件式管理的校园一卡通系统； 容错化设计的校园一卡通系统； 引入通讯中间件的校园一卡通系统； 集中式监控中心的校园一卡通系统； 实现数据分析和挖掘的校园一卡通系统；1.1.1.1. 设计原则本系统建设过程中遵循了以下原则： 实用性：校园一卡通系统应

2、充分体现大学内部管理的模式和特点，各应用系统的开发，应做到功能完善、使用方便、切合实际、运作高效； 先进性：一卡通系统的建设要立足于当今世界先进且有发展前途的技术，由此实现的系统能随着未来信息技术的发展而不断平滑升级； 可管理性：一卡通系统通过数千个终端机具来实现管理和服务功能，其管理难度大、维护成本高，系统必需从整体架构上、从具体功能上保证降低管理难度、降低维护成本、降低人员依赖，采用集中管理模式、图形化管理和监控工具，方便管理维护、出现故障能快速准确的定位问题； 开放性：一卡通系统将随着学校业务发展而不断更新，基于性价比、厂商风险等因素考虑，系统必需采用开放的架构、开放的平台、开放的产品，

3、提供完备的文档资料和接口程序，开放数据结构、学校掌握密钥和算法、选择国标和开放的行业标准、支持多种硬件，系统建成后学校可自行扩展升级、自主决定采购多种品牌的终端设备等； 安全性：系统涉及资金，身份等重要的信息，应采用严格的分级管理技术，管理人员、查询人员分级按权限操作；采用多层体系架构，单层次出现故障，系统可继续运行较长时间；系统运行中间层次、中间环节不能保留敏感数据，以避免财务风险；一旦系统恢复正常运行，系统能够自动切换，无需人工干预；对于脱机运行（手持设备等）的设备，系统需要提供有效措施保障师生利益；提供审计功能，对于操作人员的各项操作进行审计； 扩展性：系统在容量和功能上不仅能满足目前用

4、户的需求，而且也易于扩展以保障用户今后的扩容和升级，如：卡片结构扩展、新增收费模式、增加信息点等，利用Web查询支持模块和Internet网，实现远程快速查询； 可靠性：考虑到用卡场所情况复杂，系统必须针对交易的每个环节提供增强可靠性的措施，包括卡片可靠性设计、终端可靠性设计、布线和网络通讯可靠性设计、应用和数据库可靠性设计等全系列设计，确保系统在脱机状态下的可靠性高及在联机状态下的实时性强的要求，以及大规模并发交易情况下系统的稳定、高效和可靠性要求，避免单点故障。 保密性：系统设计上既充分考虑信息资源的共享，也实现了信息资源的保护和隔离，针对不同的应用和不同的网络通信环境，采取不同的措施，包

5、括用户安全性、数据安全性、运行安全性等。要求系统对数据传输进行加密传输，保证数据能在各个节点之间进行安全通信，保证数据传输的安全性，并且保证所采用的加密技术不可逆。 协调性：考虑到校园一卡通的金融特性和实时交易的特点，系统采取数据集中的架构以保证数据传递的及时性、数据的可靠性和唯一性，便于账目结算和数据准确。 前瞻性：系统管理平台在整体规划设计、各项技术性能指标以及采用设备产品上，既体现了现实的需求，又充分考虑了项目工程的未来发展，为后期建设留有充分发展的余地。1.1.1.2. 总体框架考虑到本系统核心为实时交易系统的特点，系统需采用多层体系架构，各层次接口清晰简单，易维护、易扩展。下图为一卡

6、通的整体框架：1.1.1.2.1. 一卡通核心平台一卡通核心平台是系统管理的核心，它形成了校园一卡通系统的骨干。在业务上，它实现了客户管理、商户管理、资金结算、交易处理等核心功能，是整个系统的交易和管理中心；在技术上，它实现了系统管理、系统容错、系统监控等功能，是整个系统的调度和控制中心。它支撑和管理着各个一卡通应用系统的运行，并保证了新的应用系统的快速扩展和部署。一卡通核心平台主要包括基础平台（客户管理、卡务管理、商户结算、现金充值、补贴发放、密钥管理、管理中心、报表管理、标准管理），监控中心（异常采集、异常分析、异常展示）三大内容。1.1.1.2.2. 一卡通数据库平台一卡通数据库平台集中

7、管理和存储所有数据，主要包括两大类信息： 基础信息：客户信息CIF、身份信息IIF、公共信息PIF； 动态信息：账户信息AIF、交易信息TIF。一卡通数据库保证了数据的一致性、完整性和及时性，最大限度地实现了信息共享。1.1.1.2.3. 一卡通应用系统一卡通应用系统是建立在核心管理平台和核心数据库之上的多个以校园卡为媒介的应用系统，主要分为四种类型： 金融消费类。主要用于处理校内的各种消费服务、圈存转帐等与现金有关的服务项目，比如餐饮收费、浴室收费、医疗收费、圈存转帐等； 身份识别类。一卡通系统中以校园卡进行电子身份认证，用以判断卡片的合法性和有效性。可应用在门禁、图书借阅、通道控制、校门出

8、入、考勤、会议签到、考试监管、学校老生指纹报道等重要场所； 信息服务类。通过多种信息渠道（网络、电话、短信），为持卡人提供校园卡的账户信息、消费数据等查询服务，为持卡人提供校园卡的挂失、转账等自助服务，为管理者提供金融数据、认证数据的分析。 流程接口类。主要用于与图书馆、财务等第三方系统对接，实现了以校园卡为媒介的流程整合。各应用系统相当于校园一卡通系统的前台部分，而核心管理平台则是其后台部分。各应用系统主要借助于各种终端设备（POS机、多媒体设备等），负责各种服务信息的数据接收和初步验证，所有数据都通过通讯平台发送到后台核心管理平台进行处理和保存。1.1.1.3. 技术架构一卡通系统根据各个

9、子系统不同的业务特点，分别选择了B/S、C/S架构。1.1.1.3.1. C/S设计【多层技术架构图】 架构组成n 业务调度中心(BCC) ：业务通信平台的接入，业务优先级调度，业务提交和结果返回，多类型推送消息的支持；n 业务处理单元(BU) ：后台数据库的连接管理，业务处理模块(BP)的集成，具体业务处理模块的调用；n 一个业务调度中心（BCC）和多个业务处理单元（BU）组成一个业务处理组件，多个业务处理组件组成一个后台处理系统，以支持并发和容错。 架构特点n 架构基于通信平台DRTP和CPACK交换技术；n 架构采用集中并发处理技术和分布式部署技术；n 架构和业务的独立，程序员只需要关注

10、具体的业务逻辑实现；n 架构采用了容错技术，可避免单点应用故障；n 架构支持其他客户端以客户方式接收数据，如各类监控接收程序；n BCC平台无关，BU除数据库连接部分外也与平台无关；n 架构支持优先级调度和各优先级可配置的LIFO或FIFO调度策略。上图清晰的表明，本系统是构架在通讯中间件上的集中交易系统，是当前一卡通领域唯一满足学校要求的整体解决方案，与传统一卡通“就餐系统加补丁”的系统有着本质的区别，其独特的优势主要体现在如下几方面： 集中模式n 数据集中：除了在后台的数据库中，中间任何过程包括前置业务层、通讯中间件、应用服务器都不保留任何业务数据；n 交易集中：所有业务逻辑处理全部集中在

11、后台的应用服务器完成，中间过程因为没有数据支撑不能进行业务处理；n 管理集中：业务开启和关闭、业务参数、运行监控等全部在后台集中进行。 软硬分离：通过标准的设备驱动封装，使本系统可以兼容多厂商的终端设备，彻底摆脱了传统一卡通系统中只能采购固定厂商设备的尴尬； 多层集群：图中表明，终端设备并不是象传统一卡通厂商那样绑定固定的“工作站485卡”模式，而是寻找智能的“通讯平台”。通讯中间件具有集群功能、且和传统一卡通的“工作站实际上就是服务器，因为其保留了完整的业务数据、进行完整的业务处理”不同，通讯中间件不保留业务数据，因此通讯中间件可以相互接管，即使一台甚至多台（只要由1台不停机）通讯中间件宕机

12、，整个系统依然可稳定的运行。这个独特的架构可以给学校带来如下好处： 可维护性高：集中架构只需要维护中心数据库和业务系统，再配备本方案中强大的监控中心，通过图形化界面管理，使得整个系统可维护行得到了极大的增强； 可扩展性强：简单的业务扩展只需要新增相应的硬件设备，复杂的业务扩展也只需要在管理中心进行数据库和业务逻辑升级即可； 更安全可靠：由于实现了集中模式，整个系统不存在单点故障、不存在操作人员改帐的财务风险，使整个系统非常安全、稳定和可靠； 运营成本低：n 统一的后台管理，避免了分布式数据管理的风险和投入；n 图形化监控中心，使整个系统运行状态一览无余，发现问题主动报警使管理人员能够在第一时间

13、准确定位，不需要传统一卡通系统要求的“每个食堂一名联络员”，从而最大限度的节约了人力成本。1.1.1.3.2. B/S设计对于部分B/S架构的子系统，我们采用了主流的跨平台的J2EE架构，该通用架构特点不再熬述。1.1.1.4. 积木式设计1.1.1.4.1. 设计思路一卡通不同的业务系统，就如同一个个完整的电脑插件，需要的时候，“插”到一卡通核心平台上，扩展其应用；在不需要的时候，可方便的从一卡通核心平台上“拔”下来，停止相关应用。同时，一卡通核心平台提供通用标准接口，第三方系统可按照通用标准接入；也可按照与第三方约定标准，采用定制标准接口接入第三方系统。 1.1.1.4.2. 选配方法一卡

14、通只需要采用基础平台，与任何一个或多个内容（这些内容包括：监控中心、金融消费类子系统、身份识别类子系统、信息服务类子系统、流程整合类子系统）进行组合，即可建成扩展功能或应用的快速升级。1.1.1.5. 并发性设计一卡通业务系统核心在业务处理过程，可将不同的业务处理封装成独立的业务处理单元，业务单元之间彼此独立，互不影响。这些不同封装而成的业务单元，可按需分配组合成不同的业务群。业务群与业务群可以相同，也可以不同。这些组合而成的业务群，部署在不同应用服务器上，通过业务调度中心统筹进行调度不同的业务处理单元进行业务处理。下图为并发性的实现示意图。1121.1.2. 系统功能方案一卡通系统的核心是应

15、用软件建设，而应用软件最终体现在设计的业务功能模块在多大程度上满足设计目标、设计原则的要求。结合同行教训和国内外的成功案例，结合在学校调研中各部门的意见和建议，我们设计了如下的功能结构：基于构件化思路开发的校园一卡通系统已经形成了功能完备的标准化功能模块库，完全覆盖了学校的实际需求，其中许多功能模块客户目前尚使用不到，另外一些模块尽管名称和客户要求的类似、一致，但是功能已经远远超越了传统一卡通的范畴，还有一些功能进行了更加合理的部署可能进行了功能合并、功能拆分等。1.1.2.1. 基础平台一卡通基础平台是整个“校园一卡通系统”的核心，集中保存一卡通的业务数据，集中处理一卡通的联机交易，集中管理

16、一卡通的核心业务，在整个系统中的地位至关重要。由于一卡通核心管理平台将承担了整个一卡通的核心业务处理，所以其功能设计必须足够强大、体系结构必须足够灵活，主要功能描述如下：1.1.2.1.1. 客户管理概述凡是享受本系统提供的业务功能的个人都是本系统的客户,由于种种原因，存在同一客户在本系统中开设多个不同用途的账户，但出于管理的原因希望通过某种途径能够把这些账户关联起来，为此系统为每个持卡人开设了系统唯一的客户号（即人员编号）。整个客户信息将参照国标、部标及我国4大银行对客户信息的设计经验，结合高校的实际需要进行集成，提炼成为标准的客户信息（CIF），供整个一卡通系统使用。详细功能主要包括以下三

17、大子模块：l 客户类别管理提供客户类别查询、增删改的操作；客户的类别一般直接参照校园的人员类别定义。l 客户信息管理提供客户信息查询操作。提供客户信息增删改的操作。提供客户信息批量导入的操作；导入信息通过系统提供的固定格式的Excel文档收集。提供对导入的客户信息进行查询、修改、删除操作，提供导入的客户信息的审核操作；只有审核通过的客户信息才会从临时表转移到一卡通的客户信息表中。l 银行卡绑定提供客户、银行卡信息对应关系批量导入的操作；导入信息通过系统提供的固定格式的Excel文档收集。提供客户、银行卡信息对应关系批量导入的操作；导入信息通过系统提供的固定格式的Excel文档收集。 提供客户、

18、银行卡信息对应关系的查询、增删改的操作。1.1.2.1.2. 商户管理概述拥有设备运营权并可结算的组织，我们成为商户；对于商户中最小的独立核实个体，我们称为叶子商户，每个叶子商户都归其父商户管理；因此，商户管理中一个重要的内容是收集和整理一卡通运营体系中涉及的商户，设备和商户的关系。详细功能主要包括以下两大子模块：l 商户信息管理提供商户信息查询操作。提供商户信息增删改的操作；支持商户信息以树型结构展现；支持对收费商户按照营业的百分比收取佣金，支持收费商户对特定人群收取搭伙费。提供所有商户通用的餐次设置操作；分为早餐、中餐、晚餐、夜餐。提供每个商户个性的餐次设置操作；分为早餐、中餐、晚餐、夜餐

19、，当某个商户进行了个性的餐次设置，其分餐报表将以该设置的时间段统计为准。l 设备商户关系管理提供设备与商户之间相关联的信息查询操作。提供设备与商户之间相关联信息的增删改的操作；本操作通过树型关系图完成。提供设备与商户之间相关联信息的批量导入的操作；导入信息通过系统提供的固定格式的Excel文档收集。提供设备与商户之间相关联信息提供客户、银行卡信息对应关系的查询、修改、删除的操作，提供导入设备与商户之间相关联信息的审核操作；只有审核通过的设备商户关系才会从临时表转移到一卡通的设备商户关系表中。1.1.2.1.3. 卡务管理概述系统支持卡的分类、分级管理，大类包括教师卡、学生卡等可学校根据需要自行

20、扩展，细类如教师卡可细分为教授、外籍教师、普通教师等，也可根据需要灵活扩展。该部分涉及到师生的切身利益，需要从卡片设计上考虑新生、丢卡后过渡、临时人员收取费策略、完全脱机使用而不能透资等特殊需求，以及脱机下如何最大程度的保护师生利益等。另外，还提供功能卡，专用于授权维护、脱机终端的管理等。详细功能主要包括以下四大子模块：l 日常卡务管理提供卡片的发行操作。提供卡片批量发行操作。提供匿名卡（没有客户信息）的发行操作。提供卡片内容对换的操作。提供卡片挂失、解挂的操作。提供卡片冻结、解冻的操作。提供卡片回收在发行操作，该功能只用于匿名卡的管理。提供卡片丢失后补办的操作。提供卡片销户的操作。提供卡片充

21、值的操作。提供卡片现金支取的操作。提供卡信息更新的操作，卡信息更新包括三种情况：更新卡内的基本信息、更新卡的有效期、更新卡内余额。提供卡片密码修改操作。提供手工调账的操作，当发现借方和贷方发生账务错误时，由操作员手工调整借贷账务，使两者保持一致。提供交易的冲正操作，当交易异常时，提供该交易流水的冲正。提供开户的卡冲操作。提供充值的冲正操作，当充值金额有误差时，提供该比充值流水冲正。提供交易冲正的操作，当POS机操作人员操作失误或者打卡金额有误差时，提供该笔消费流水冲正。提供手工方式补写圈存流水的操作，当未能提供银行圈存交易导致银行对账出现单边账的情况。l 账务信息查询提供查询持卡人交易流水的操

22、作。提供查询持卡人交易账户交易流水的操作。l 卡库不平处理提供卡库不平的平账操作，该操作处理由于设备流水丢失原因造成的卡库不平。l POS流水管理提供POS流水批量导入操作，该操作针对POS机流水不能正常自动收集至系统时；导入信息通过系统提供的固定格式的Excel文档收集。提供对导入的流水信息进行查询、修改、删除操作，提供导入的流水信息的审核操作；只有审核通过的流水信息才会从临时表转移到一卡通的流水信息表中。1.1.2.1.4. 拍照制卡概述对于一卡通上需要印刷员工的个性化照片，目前业界普遍采用的方法式手动操作拍摄、手动手机照片、手动编码照片文件、手动核对照片和人的对应关系，使用很不方便，比如

23、： 容易出错，需要手工记录每个拍照者的工号、拍照顺序号，其对应次序一个都不能错，否则会引来无穷后患。 效率低下，拍摄需要手动按动快门，拍照完成后需要手工拔插相机的USB线，就是说照片传输也拍照过程不能同时进行，如果要去照片必须停止拍照，假设拍摄一个员工、取照片这个动作能够在2分钟完成，按照每1万人计算，需要的时间2万分钟400小时！基于拍照工作将成为未来的一卡通管理结算中心的日常工作，对于这个工作的一“点”效率提高，将极大的影响未来系统的可用性。详细功能目前专用数码拍照系统主要包含如下功能： 自动数据采集及把需要拍照的人员信息从包括EXCEL、DBF、RDMS等中自动对应转换出来（转换关系可以

24、有业务人员自行设置） 通过鼠标自动拍摄、自动转存照片到PC 照片处理对于不满意的可以从拍摄、照片进行裁减、编辑（旋转、放大等） 照片保存到集中的数据库中，便于全企业共享 对于确认的照片，可以选择立即打印出一卡通卡 照片批量和零星导出功能 照片查询功能1.1.2.1.5. 现金充值概述考虑到师生习惯，在卡片使用集中的地方提供人工充值功能，系统可支持现金、支票、经费本三种充值模式，并能配合银行、学校的现金管理制度，提供解款功能等。充值终端将根据实际情况据实部署。现金充值大致分为联机充值和脱机充值两种，联机充值的好处就是充值的过程实时联机，安全并且结算更准确；脱机充值好处在于网络异常情况下仍然可以工

25、作，缺点是安全性差，脱机充值的数据如果不能及时回传的情况下会出现操作员解款和系统对账不一致，另外也可能出现充值的人员利用脱机数据少缴现金。目前我们鼓励联机充值，对于采用脱机充值的方案不承担风险。在该一卡通项目中，我们建议采用联机充值方式，因其在充值的过程中是实时联机的，能保证充值的安全并且准备结算。详细功能主要包括：l 采用联机交易。l 支持充值的冲正。l 支持三种二级科目的充值收款。l 支持USB通讯。l 支持RS232通讯。1.1.2.1.6. 补贴发放概述补助发放子系统能实现学校内部补助发放电子化的应用需求。由于校园一卡通系统的建设，在学校内部可以实现“一卡在手，走遍校园”，通过卡可以进

26、行各种消费，比如就餐、超市购买物品、医院看病等等，由于以往学校发放补助都是现金方式，涉及到跨部门审批、现金发放，所以补助发放的工作量大、周期长，而利用一卡通平台实现教职工补助发放能大大减轻工作量。在本项目中，补助发放系统主要实现学校对教职工的伙食补助的发放，未来学校如有新的补助发放内容，可在系统中自定义设置，不需要另外进行开发。详细功能主要包括：l 在多媒体自助机上查询和领取补助。l 查询补助流水。l 提供补助信息导入模板（Excel文件），通过批量导入功能导入补助信息。l 提供导入补助信息的查询、修改、删除功能。l 对确认的补助信息进行下发功能。l 提供补助下发后领取状态的查询。1.1.2.

27、1.7. 报表管理概述按照现行财务准则设计，用来反映一卡通运营中的经济内容。一卡通系统中所有涉及账务交易的数据都体现在该报表中，通过该报表，管理者和财务人员不但可以在宏观上清晰的了解一卡通沉淀资金量、商户的总营业额、系统运营中的盈亏情况等，而且各个参与者的账务情况，可以根据报表进行一卡通财务数据往来。下表是该章节涉及到的专业术语解释：专业术语名称内容描述备注会计科目是对会计对象具体内容进行分类核算的类目。会计科目分类对会计对象的具体内容加以科学分类，进行分类反映和监督的一种方法，是进行会计核算的起点。按其反应的经济内容分为：资产类科目、负债类科目、所有者权益类科目、成本类科目、损益类科目。按其

28、隶属关系分为总账科目（一级科目），明细科目（二级科目、三级科目）。资产类科目（仅本系统）流动资产内容的汇总，包括：现金（1001）、银行存款（1002）、应收票据（1121）。其中，应收票据（1121）又细分为：支票（112101）和经费本（112102）。负债类科目（仅本系统）流动负债内容的汇总，包括：卡户存款（2001）、卡户押（2002）、个人存款（2003）、商户收入（2004）、充值商户存款（2005）。损益类科目（仅本系统）各类业务收入、各类业务支出等内容的汇总，包括：营业外收入（6001）、手续费收入（6002）、佣金收入（6003）、搭伙费收入（6004）、卡成本费收入（600

29、5）、退卡盈余收入（6006）、卡折旧费收入（6007）、营业外支出（6201）、商户提成支出（6202）。记账原则（仅本系统）账户的左方为“借方”，右方为“贷方”。资产类科目的增加记借方发生额，减少记贷方发生额；损益类支出的增加记借方发生额，减少记贷方发生额。负债类科目的增加记贷方发生额，减少记借方发生额；损益类收入的增加记贷方发生额，减少记借方发生额。记账算法（仅本系统）资产类余额和损益类支出的余额方向在借方，符合等式：期末借方余额=期初借方余额+借方发生额贷方发生额其中负债类和损益类收入的余额发生方向在贷方，符合等式：期末贷方余额=期初贷方余额+贷方发生额借方发生额记账定律（仅本系统）有

30、借必有贷，借贷平衡。记账日期一卡通系统的脱机应用环境中，发生的交易流水被收集至系统并入账的日期。发生日期一卡通系统中，交易发生的日期。详细功能一卡通结算系统体系结构示意图本模块主要包括以下三大子模块：l 结算报表提供对每天系统内科目的期初、期末、变化情况进行统计。下表是对结算报表中科目的描述：序号科目名科目说明类别1库存现金（1001）充值、卡片成本、卡片押金、补助发放、充值商户存款等交易所获取现金的汇总。资产类科目2银行存款（1002）圈存等交易所获取银行转账金额的汇总。资产类科目3应付票据（1121）充值、卡片成本、卡片押金、补助发放、充值商户存款等交易所获取票据的汇总。该一级科目由支票（

31、112101）和经费本（112102）两个二级科目组成。资产类科目4卡户存款（2001）持卡人账户余额的汇总。负债类科目5卡户押金（2002）系统管理的交易收费配置中交易所收取费用的汇总。持卡人办理卡片时所存放的押金的汇总。负债类科目6个人存款（2003）虚拟钱包余额的汇总。负债类科目7商户收入（2004）应付给商户金额的汇总。负债类科目8营业外收入（6001）因为卡库不平时（库金额大于卡金额的情况），所做的卡片销户、卡库平衡（以卡为准）操作所带来的账户收入。损益类科目（收入）9手续费收入（6002）系统管理的交易收费配置中交易所收取费用的汇总。损益类科目（收入）10佣金收入（6003）商户管

32、理的浮动费率设置中配置后所收取的费用的汇总。损益类科目（收入）11搭伙费收入（6004）系统管理的交易收费配置中交易所收取费用的汇总。损益类科目（收入）12卡成本费收入（6005）持卡人办理卡片时所缴纳的卡成本费的汇总。损益类科目（收入）13退卡盈余收入（6006）卡片回收时，不退还卡内金额的汇总（只对不记名临时卡有效）。损益类科目（收入）14营业外支出（6201）卡库不平（卡金额大于库金额的情况），并且卡片销户是以卡为准退，销户后的该卡片上传的流水且入账的所形成的金额的汇总。损益类科目（支出）提供按照上传流水来统计每天商户营业情况的报表，作为财务和商户进行账务结算的直接依据和标准。提供按照发

33、生流水来统计商户下POS机流水汇总的报表，供商户参考，但并不作为商户结算标准。提供按照分餐时间段来统计每天商户营业情况的报表，作为商户内部对账的依据。 提供操作员每天的收取的现金和票据需要汇总的报表，作为核对当天账务的依据。 提供以摘要（交易种类）和交易次数来反应各科目发生额变化的报表。l 当日报表提供当日的商户营业情况表、操作员票据现金报表，由于这些数据并没有结算（每天凌晨，系统自动清算），因此只作为参考数据。l 资金划拨提供商户数据解款的操作。实现说明描述：计帐法1：资产类的增加记借方发生额，减少记贷方发生额；损益类支出的增加记借方发生额，减少记贷方发生额。计帐法2：负债类的增加记贷方发生

34、额，减少记借方发生额；损益类收入的增加记贷方发生额，减少记借方发生额。计算方法1：资产类余额和损益类支出的余额方向在借方，符合等式：期末借方余额=期初借方余额+借方发生额贷方发生额计算方法2：其中负债类和损益类收入的余额发生方向在贷方，符合等式：期末贷方余额=期初贷方余额+贷方发生额借方发生额定律：有借必有贷，借贷平衡。下表是对科目余额表中科目数据的部分描述：序号参数名参数说明类别示例1库存现金（1001）充值、卡片成本、卡片押金、补助发放、充值商户存款等交易所获取现金的汇总。资产类科目比如：该科目期初借方余额为“900”元，“20090209”的现金交易中只有张三充值了100元的，则该天的报

35、表中该科目期末借方余额为“1000”元，因为借方发生额为“100”。2银行存款（1002）圈存等交易所获取银行转账金额的汇总。资产类科目比如：该科目期初借方余额为“900”元，“20090209”只发生了张三的圈存交易，圈存金额为50元，则该天的报表中该科目期末借方余额为“950”元，因为借方发生额为“50”。3应付票据（1121）充值、卡片成本、卡片押金、补助发放、充值商户存款等交易所获取票据的汇总。该一级科目由支票（112101）和经费本（112102）两个二级科目组成。资产类科目比如：该科目期初借方余额为“900”元，“20090209”只发生了张三的补助发放交易（以经费本的形式），补助

36、发放金额为200元，则该天的报表中该科目期末借方余额为“1100”元，因为借方发生额为“200”。4卡户存款（2001）持卡人账户余额的汇总。负债类科目比如：该科目期初贷方余额为“900”元，“20090209”只发生了张三的充值交易，充值金额为100元，则该天的报表中该科目期末贷方余额为“1000”元，因为贷方发生额为“100”。比如：该科目期初贷方余额为“900”元，“20090209”只发生了张三的现金支取交易，支取金额为50元，则该天的报表中该科目期末贷方余额为“850”元，因为借方发生额为“50”。5卡户押金（2002）系统管理的交易收费配置 中交易所收取费用的汇总。持卡人办理卡片时

37、所存放的押金的汇总。负债类科目比如：该科目期初贷方余额为“900”元，“20090209”只发生了张三的办卡交易（需要缴纳卡押金），卡押金为20元，则该天的报表中该科目期末贷方余额为“920”元，因为贷方发生额为“20”。比如：该科目期初贷方余额为“900”元，“20090209”只发生了张三的退卡交易（需要退还卡押金），卡押金为20元，则该天的报表中该科目期末贷方余额为“880”元，因为借方发生额为“20”。6个人存款（2003）虚拟钱包余额的汇总。负债类科目比如：该科目期初贷方余额为“900”元，“20090209”只发生了张三的转账交易（将虚拟钱包金额转出去），转账金额为50元，则该天的

38、报表中该科目期末贷方余额为“850”元，因为借方发生额为“50”。7商户收入（2004）应付给商户金额的汇总。负债类科目比如：该科目期初贷方余额为“9000”元，“20090209”只发生了一卡通消费500元（并都进入商户的账户），则该天的报表中该科目期末贷方余额为“9500”元，因为贷方发生额为“500”。8充值商户存款（2005）充值商户存款中存入金额的汇总。负债类科目9营业外收入（6001）因为卡库不平时（库金额大于卡金额的情况），所做的卡片销户、卡库平衡（以卡为准）操作所带来的账户收入。损益类科目（收入）比如：该科目期初贷方余额为“900”元，“20090209”只发生了张三的退卡操作

39、，退还卡中金额45元（库金额为50元），则该天的报表中该科目期末贷方余额为“905”元，因为贷方发生额为“5”。10手续费收入（6002）系统管理的交易收费配置 中交易所收取费用的汇总。损益类科目（收入）假设：配置了所有卡片在发行时只收取5元的手续费。 比如：该科目期初贷方余额为“900”元，“20090209”只发生了张三的发卡操作，则该天的报表中该科目期末贷方余额为“905”元，因为贷方发生额为“5”。11佣金收入（6003）商户管理的 浮动费率设置中配置后所收取的费用的汇总。损益类科目（收入）假设：配置了收取某个商户1的佣金，当月收入超过10000元时收取。 比如：该科目期初贷方余额为“

40、900”元，“20090301”该商户上月的营业额为20000元，则该天的报表中该科目期末贷方余额为“1100”元，因为贷方发生额为“200”。12搭伙费收入（6004）系统管理的交易收费配置 中交易所收取费用的汇总。损益类科目（收入）假设：配置了所有卡片在消费时收取5元的搭伙费。 比如：该科目期初贷方余额为“900”元，“20090209”只发生了张三的100元消费（并都进入商户的账户），则该天的报表中该科目期末贷方余额为“905”元，因为贷方发生额为“5”。13卡成本费收入（6005）持卡人办理卡片时所缴纳的卡成本费的汇总。损益类科目（收入）假设：配置了所有卡片在发卡时收取20元的成本费。

41、 比如：该科目期初贷方余额为“900”元，“20090209”只发生了张三的发卡操作，则该天的报表中该科目期末贷方余额为“920”元，因为贷方发生额为“20”。14退卡盈余收入（6006）卡片回收时，不退还卡内金额的汇总（只对不记名临时卡有效）。损益类科目（收入）假设：当制度要求所有不记名临时卡在退卡时不退卡内金额。 比如：该科目期初贷方余额为“900”元，“20090209”只发生了张三的退卡操作（不记名临时卡），卡内余额为5元，则该天的报表中该科目期末贷方余额为“905”元，因为贷方发生额为“5”。需要说明的是，如果此时张三的库余额大于卡余额，比如为8元，则将有3元进入营业外收入的科目中；

42、如果此时张三的库余额小于卡余额，则需要进行坏卡登记的操作。15营业外支出（6201）卡库不平（卡金额大于库金额的情况），并且卡片销户是以卡为准退，销户后的该卡片上传的流水且入账的所形成的金额的汇总。损益类科目（支出）假设：全局参数配置了流水过期日期为10天。 比如：该科目期初借方方余额为“900”元，张三在“20090209”销户（卡净额50元，库金额45元，销户时退卡金额50元），在“20090210” 上传了张三发生在“20090201”消费的流水（5元），并入账，则在“20090210”的报表中该科目期末借方余额为“905”元，因为借方发生额为“5”。16商户提成支出（6202）充值商户

43、存款中给商户提成金额的汇总。损益类科目（支出）示例：收入和结算金额的计算假如：商户A下只有一个POS机，命名为POS001，20090301开始正式启用，截至20090303所发生的流水如下表；流水号POS机发生日期记账日期金额备注001POS00120090301200903011.0流水当天发生，当天入账002POS00120090301200903012.0流水当天发生，当天入账003POS00120090301200903023.0流水当天发生，第二天入账004POS00120090301200903034.0流水当天发生，第三天入账005POS00120090302200903025

44、.0流水当天发生，当天入账006POS00120090302200903026.0流水当天发生，当天入账007POS00120090303200903037.0流水当天发生，当天入账008POS00120090303200903038.0流水当天发生，当天入账根据流水数据，我们选择开始日期“20090301”、结算日期“20090301”，所得到的商户结算表POS报表应该如下：商户名称交易日期设备名称交易次数收入支出结算金额A20090301POS001200903013.003.0其中“20090301”的收入应该是流水号为“001”、“002”的累计；其中“20090301”的结算金额也应

45、该是流水号为“001”、“002”的累计；根据流水数据，我们选择开始日期“20090301”、结算日期“20090302”，所得到的商户结算表POS报表应该如下：商户名称交易日期设备名称交易次数收入支出结算金额A20090301POS001200903016.003.020090302POS0012009030211.0014.0其中“20090301”的收入应该是流水号为“001”、“002”、“003”的累计，“20090302”的收入应该是流水号为“005”、“006”的累计；其中“20090301”的结算金额应该是流水号为“001”、“002”的累计，“20090302”的结算金额应该是流水号为“003”“005”、“006”的累计；根据流水数据，我们选择开始日期“20090301”、结算日期“20090303”，所得到的商户结算表POS报表应该如下：商户名称交易日期设备名称交易次数收入支出结算金额A20090301POS0012009030110.003.020090302POS0012009030111.0014.020090303POS0012009030215.0019.0其中“20090301”的收入应该是流水号为“001”、“002”、“003”、“004”的累计，“20090302”的收入应该是流