第一篇:第三方业务对接校园一卡通系统申请书
华南理工大学校园一卡通
编号:
第三方业务对接校园一卡通系统申请书
信息网络工程研究中心(信息办公室):
现因我单位所负责开展的 业务的需求,现申请对接校园一卡通系统:
一、业务功能简介:
二、对接目标需求:
三、项目对接负责人及联系方式:
姓名:
单位任职: 联系电话:
联系邮箱:
是否可行?请贵单位讨论决定!
申请单位:
(领导签字盖章)
申请日期:
****年**月**日
========以下为信息网络工程研究中心(信息化办公室审核意见)=========
****年**月**日 华南理工大学校园一卡通
编号:
附:第三方业务对接校园一卡通系统的工作流程
第三方业务的学校相关管理部门提出“对接申请”确定对接可行性N放弃Y签订双方“业务协作方式确认书”启动相关建设工作 华南理工大学校园一卡通
编号:
第三方业务协作方式确认书
单位(商户)自主接入设备清单:
1、2、 单位(商户)职责范围:
1、2、 一卡通接入设备清单:
一卡通职责范围:
实施方案概述及设备签收清单:(含设备标签)
申请单位承诺:
1、本协作确认书内容仅限应用于当前申请项目,申请单位不得私自复作他们,否则一卡通系统有权关闭对当前项目的支持并向学校汇报,所造成的后果由申请单位自行负责!
2、单位(商户)领导签字(盖章):
确认日期:
****年**月**日
第二篇:校园一卡通业务操作手册
附件1:
交易码:7720 交易名称:校园卡签约管理
交易功能描述:
通过校园卡签约管理交易,将建行借记卡与浙大校园卡相匹配(撤消等),使建行卡作为浙大校园卡的划转指定帐户(撤消指定账户)。
交易界面:
7720签约、撤消、冻结、解冻
栏位说明:
输入交易码7720,单位编号18006,单位名称:浙江大学,分别输入学生学号(若老师来签约此项不需输入)、学生姓名、身份证号、校园卡号,处理方式有签约申请、签约冻结、签约撤消、签约解冻(冻结、解冻一般不用),将客户账号刷卡进入,输入密码。
授权:不需授权
注意事项:
需由客户本人前来办理,必须出示校园卡、身份证件,柜员必须
核对是否同一人名下。
交易码:7721 交易名称:校园卡签约查询
交易功能描述:查询校园卡签约的内容。
交易界面: 7721签约查询
栏位说明:
输入交易码7721,单位编号18006,单位名称:浙江大学,分别输入学生学号、学生姓名、身份证号、校园卡号、客户账号。注意:以上要素不必全输,输入其中一项即可查询相关信息,但要注意名字相同的情况。
授权:不需授权
注意事项:
需由客户本人前来办理,必须出示校园卡、身份证件,柜员必须核对是否同一人名下。
交易码:7722 交易名称:校园卡交易流水查询
交易功能描述:
查询个人交易明细流水。
交易界面:
7722校园卡交易流水查询
栏位说明:
输入交易码7722,单位编号18006,单位名称:浙江大学,将客户账号输入,输入查询起始日期及终止日期。
授权:不需授权
注意事项:
需由客户本人前来办理,必须出示校园卡、身份证件,柜员必须核对是否同一人名下。
交易码:7723 交易名称:校园卡日终对账
交易功能描述:
日终对账交易可查询、核对某一天的账务情况,由主办行用于第二天对账,采用辅助账户,对账后将款项划入浙江大学对公账户。
交易界面:
7723网点第二天对账(采用辅助账户归集,需对账后划账)
栏位说明:
交易码输入7723,单位编号输入18006,单位名称输入浙江大学。
授权:不需授权
第三篇:校园一卡通系统设计论文
1校园一卡通系统架构
校园一卡通系统不但具有身份认证、消费管理等功能,而且还应该与学校内部的信息管理系统统一起来,使用共同的数据中心平台和数据库,实现与其它信息管理系统的互通。为此,校园一卡通系统的建设应该包含相关的身份认证系统、数据交换系统、综合门户系统、第三方系统接口等内容。系统架构采用三级平台结构:数据中心作为一级平台;银行、财务等各管理中心作为二级平台;各应用系统为三级平台。其中,一级平台是信息共享和数据交换的核心;二级平台实现银行系统、校内卡务管理中心、各终端机的互连互通,完成用户的各种银行业务和信息管理功能;三级平台完成与校园卡相关的各种应用功能。
2校园一卡通系统设计原则
安全性是校园一卡通系统设计过程中应考虑的最重要原则。该原则可以通过技术和管理等方面的手段,保证系统的安全、可靠运行。具体内容包括IC卡、读卡终端、应用服务器等硬件设备,以及数据的网络传输、存储、管理等运行机制。此外,在设计过程中还应密切注意科技的发展,不断采用新的安全标准对系统进行评估,保证系统的安全性需求。开放性是校园一卡通系统设计时需要考虑的另一个重要原则。在设计上应规划出多种不同的标准及非标准的接口,以供如图书管理系统、财务管理系统等第三方应用系统接入,接口规范可以根据学校的需要提供一种或多种,如应用程序动态接口、Web-Service等。
3校园一卡通系统详细设计
3.1数据库平台选择
在数据库平台的选择过程中可以从不同角度来考虑。如考虑到稳定性,可以使用当前性能最为稳定的Oracle10g数据库。如考虑性价比,可以使用性价比较高的SQLServer数据库。操作系统同样也可以从不同角度来考虑。性能稳定的有UNIX,性价比较高的有LINUX,与SQLServer数据库搭配较好的有WindowsServer系列操作系统。
3.2转储数据方案设计
对系统要转储的数据表是否转储、保留天数、转储方式(全量、增量),转储后是否删除原始数据等这些参数进行配置。考虑到学生放假问题,则系统规定原始表至少要保存6个月的数据。转储时间可分为自动设置和手动设置两种。
3.3系统安全体系设计
系统架构采用三级平台结构,涉及到的网络结构类型有多种,如校园网、VLAN虚拟局域网、RS-485总线网等。因此,在设计过程中需要从数据存储、数据通讯、系统密钥、网络访问、应用系统等多方面采取相应的安全措施,保证系统的安全运行。
3.4第三方接入方案
一卡通系统作为数字化校园的重要组成部分,它的主要功能之一就是信息管理。因此,必须为第三方应用软件提供标准、统一的接口。第三方应用软件与一卡通系统对接后,可以实现信息的统一管理、工作的协同进行以及信息的同步处理。对接时可以采用基于TCP/IP网络来传输数据。应用软件可以使用应用服务层、Web-Service层提供的多种接口实现,如数据库视图映射、协议通讯包、Web-Service应用、传统DLL接口、卡操作接口等。
3.5系统运行结构设计
系统运行特点是采用电子钱包的方式,在运行过程中支持的运行模式有两种:脱机模式、联机模式。这种系统运行结构设计方式灵活,可以为移动式收费提供技术支持。设计有终端设备的权限集中控制管理功能,从而保证终端设备在接入时具有相应的合法性。具体实现是通过数据通讯网关,7*24小时不间断地对联机终端设备进行数据采集,从而保证数据的可靠性和安全性。
3.6一卡通系统对突发事件的处理方案
为了使一卡通系统数据库在突然发生故障时,能够在第一时间恢复数据,保证数据的一致性和完整性,在系统设计过程中应充分考虑相关数据容错处理方案。具体实现法可采用诸如中心数据库双机热备、异地数据库NAS备份、二级缓存机制等措施。
4结束语
校园一卡通系统作为数字化校园的核心应用项目,能够实现全校范围内信息的互联互通,多种信息的共享。该系统不仅具有消费功能,还具有完备的信息管理功能。它的投入使用必将为提高学校数字化生活水平和信息化管理水平起到极大的促进作用。
第四篇:校园一卡通系统项目合作协议书
甲方:_________
乙方:_________
甲乙双方就_________校园一卡通系统项目合作经友好协商达成如下协议:
第一条 合作主题
甲乙双方就_________校园一卡通系统项目经过深入交流与协商,双方均同意建立密切的合作伙伴关系,以统一的市场形象来为学校提供服务。
第二条 费用分担
(1)项目前期的运作及投标费用全部由甲方承担。
(2)项目实施过程中网络布线费用由甲方负责,系统安装,调试以及培训所产生的费用由乙方负责。
第三条 甲乙双方的权利和义务
甲方的权利和义务:
(1)甲方承诺乙方为_________校园一卡通系统项目的唯一合作伙伴。
(2)甲方负责与_________之间的协调工作。
(3)甲方负责全部工程款的回收。
(4)甲方对乙方的付款方式另行协商。
(5)甲方一旦中标_________校园一卡通系统项目,甲方将坚决执行本合作协议并坚决执行后续所签订的项目合同。
(6)甲方有权利在项目中获得相应部分的回报。
乙方的权利和义务:
(1)乙方承诺甲方为_________校园一卡通项目系统集成的唯一合作伙伴。
(2)负责提供_________校园一卡通系统项目解决方案。
(3)负责提供_________校园一卡通系统项目相关软件以及硬件设备。
(4)负责系统的安装,调试,用户的操作人员培训。
(5)负责_________校园一卡通系统项目中软硬件产品的售后服务及技术支持。
(6)甲方一旦中标_________校园一卡通系统项目,乙方将坚决执行本合作协议并坚决执行后续所签订的项目合同。
(7)乙方有权利在项目中获得相应部分的回报。
第四条 技术保密协议
乙方所提供产品的知识产权归乙方所有,甲方在未征得乙方书面同意的前提上,不得将技术资料泄露给与本部门无关的人员及单位;乙方校园一卡通的技术使用范围仅限于甲乙双方合作的项目,未经乙方同意,不得使用于其他项目。如违反上述协议内容,乙方将保留追究甲方法律责任的权利。
第五条 运作方式
甲乙双方联合对_________校园一卡通系统项目进行投标,甲方负责商务方面的洽谈,乙方负责一卡通相关产品及全面的技术支持服务。
第六条 违约责任
甲方违约责任:
(1)甲方保证在_________校园一卡通系统项目中乙方为甲方唯一合作伙伴,如甲方与其他任何公司进行合作,均视为违约行为,乙方有权追究甲方的责任,并对由于甲方违约造成的损失进行索赔,直至追究甲方的法律责任。
(2)所有涉及到一卡通系统相关技术方面的问题,以乙方提供的技术方案为准,甲方不能单方面进行任何改动,所有技术相关的内容的改动必须经过乙方书面同意。如果甲方擅自做出任何改动或承诺,所造成的全部损失由甲方独立承担。
(3)所有应付款项必须按照协议比例及时转到乙方账户下(_________每次付款后的二至三个工作日内),以便乙方及时开展工作,如果因甲方转账不及时而造成的任何损失由甲方独立承担。
(4)甲方如果有任何违反本协议第三项关于甲方权利和义务约束中的任一条款,既视为违约,乙方有权利追究甲方的责任,并对由于甲方造成的损失进行索赔,直至追究甲方的法律责任。
乙方违约责任:
(1)乙方保证在_________校园一卡通系统项目中甲方为乙方唯一合作伙伴,如乙方与其他任何公司进行合作,均视为违约行为,甲方有权追究乙方的责任,并对由于乙方违约造成的损失进行索赔,直至追究乙方的法律责任。
(2)项目所需技术方案由乙方独立提供,相关技术问题由乙方技术人员负责解决,如果因乙方无法满足学校要求所造成的全部损失由乙方独立承担。
(3)乙方保证能在_________校园要求的时间内完成所有工作,如果因为乙方技术或设备等问题造成工期延长,所造成的损失由乙方独立承担。
(4)乙方如果有任何违反本协议第三项关于乙方权利和义务约束中的任一条款,既视为违约,甲方有权利追究乙方的责任,并对由于乙方造成的损失进行索赔,直至追究乙方的法律责任。
第七条 利润分成另行协商。
第八条 合作期限
项目实施完成后本协议书自动失效。
第九条 其他约定
本协议未尽事宜,由本协议双方另行协商,并通过书面方式提交。本协议的附件为本协议的有效部分,同本协议具有同等的法律效力。
如因_________方面所造成任何项目变动,甲乙双方协商解决相关事宜。
甲方(盖章):_________乙方(盖章):_________
代表(签字):_________代表(签字):_________
_________年____月____日_________年____月____日
第五篇:多企业一卡通对接方案
多企业一卡通机具对接方案
为实现目前保定移动公司对多企业一卡通系统能够接入其他厂家机具的要求,提供以下方案。
方案一:由平台方提供卡结构、机具接入接口。由第三方机具厂家按照此标准进行定制开发、生产。
特点:形成保定移动一卡通标准,以此标准定制的机具都可接入平台。并且对于定制功能的实现,各个厂家的机具都可以按照标准来做,所有厂家都能按照相同的业务流程来定制。也就是说出了各个厂家机具的外观、质量等不相同外,对于功能上相对统一。
方案二:由各个厂家提供卡片结构、机具接入接口。由我公司负责按照提供的结构、接口进行对接。
特点:可以尽快的上线,并随着系统运营的过程中,升级系统,就可以实现对第三方厂商机具的接入。开发难度较高。因为各个厂家从业务流程到实现方式一定不尽相同,所以需要更多的沟通,更多的相互妥协。
问题:目前各个厂商标准不尽相同,在对接上只能实现大家所共通的,也就是最为基本功能的实现。另外在对接上由于标准的不同,也可能存在第三方公司和我方公司都需要进行开发工作。
需要现有机具厂商提供以下产品参数调试:
1.卡片结构:
即关于Mifare1卡(M1)卡的扇区内卡片结构,或封装后的卡片读写接口,用于平台开户使用,应用于第三方厂商所开发的专用机具。
2.通讯协议
包括两方面:
1)下行协议(即参数下载)对于机具内所需要的参数下载协议,以及参数说明。(例如:时间参数的下载,参数使用BCD码)
2)上行协议(即流水协议)对机具内所需上传的流水协议,以及流水字段的说明。(例如:流水字段中包括 账号、消费时间、消费金额 等)
3.业务流程
以第三方卡结构、通讯协议下的业务流程介绍,以方便在同平台接入时,功能实现上或有冲突性,可以在业务流程上提前发现,以沟通协商解决方案。
按以上要求提供相关资料!
第三方机具对接具体需求