合肥市轨道交通公共信息服务平台（电子票务及营销系统）升级改造项目用户需求书

合肥市轨道交通公共信息服务平台（电子票务及营销系统）升级改造项目用户需求书目录1.项目概述 11.1项目背景 11.2项目目标 11.3建设范围 11.4项目进度要求 21.5关联系统关系图 31.6相关定义 41.7项目总则 42.现状描述 102.1业务现状 102.2信息化现状 103.总体要求 103.1项目实施原则 103.2总体技术要求 123.2.1软件技术架构 123.2.2系统性能指标 133.2.3系统可靠性指标 133.2.4运行环境要求 143.2.5数据管理要求 143.2.6集成技术要求 153.2.7系统安全要求 153.3总体设计要求 194.管理标准化需求 194.1工作范围 194.2工作内容 204.2.1方案设计与规划 204.2.2管理职责与岗位 204.2.3管理流程标准化 204.2.4数据标准化 214.2.5IT技术标准化 214.3工作要求 225.详细功能需求 225.1统一支付平台 225.1.1统一支付开放平台 225.1.2清结算中心 225.1.3风控管理系统 235.1.4统计分析 235.1.5APP客户端 245.2电子票卡 245.2.1票种定义及业务规则 245.2.2电子票管理 255.2.3电子储值票 255.2.4电子票购票 265.2.5电子票团购 265.2.6电子票激活及使用 275.2.7自动退款 285.2.8开票管理 285.2.9票卡退票 285.2.10我的卡包 285.2.11销售订单管理 285.2.12对账报表 295.2.13小程序销售端 295.3营销管理平台 295.3.1活动管理 295.3.2奖品管理 305.3.3活动模板管理 305.3.4白名单功能 305.3.5统计分析 305.3.6第三方营销活动 305.4权益平台 315.4.1出行权益产品管理 315.4.2出行权益产品配置 315.4.3权益票券发放管理 325.4.4分销渠道管理 325.4.5权益分销管理 325.4.6权益核销管理 325.4.7交易对账管理 325.4.8乘车优惠 335.4.9碳积分权益体系建设 355.4.10合肥轨道会员积分体系建设 355.4.11与外部系统对接 365.4.12数据报表需求 365.4.13合肥轨道会员电子形象 375.5广告管理平台 375.5.1内容发布客户端 375.5.2广告投放功能 375.5.3广告管理功能 375.5.4报表功能 375.5.5个人广告销售功能 385.5.6广告资源展示及意向下单功能 385.5.7程序化广告对接 385.6升级迭代功能 385.6.1APP风控管理 385.6.2优化消息推送机制 395.6.3申诉模块优化 395.6.4APP电子商城优化 395.6.5出行模块 405.7外联系统改造 405.8招商管理 406.项目实施内容 406.1项目启动 416.2需求调研 416.3管理标准化 416.4方案设计 416.5开发设计 416.6安装配置 426.7自测试与联调 426.8实施与部署 436.9初始化与数据迁移 436.10系统上线试运行 446.11系统初步验收 446.12最终验收 456.13系统运维移交 457.代码管理及小程序要求 457.1版本控制 457.2代码规范与发布要求 467.3第三方小程序跳转与H5集成 468.实施管理要求 478.1项目组织要求 478.1.1办公场所说明 478.1.2项目组 478.1.3组织人员要求 478.1.4项目组管理要求 488.2项目管理要求 498.3项目例会制度 498.4设计联络制度 498.5实施考核要求 519.项目交付成果 529.1项目过程成果 529.2项目科研成果 5310.项目评审与验收 5410.1项目验收的组织机构 5410.2验收标准 5410.3阶段成果评审与确认 5410.4初步验收 5410.5最终验收 5510.5.1验收文档 5510.5.2辅件配合 5510.6维保期验收 5511.项目维保要求 5511.1维保期 5511.2长期服务 5812.项目报价 591.项目概述1.1项目背景2022年中国城市轨道交通协会发布《中国城市轨道交通绿色城轨发展行动方案》，提出：城轨出行占比提升行动，要求各城轨运营公司积极响应并参加城市绿色出行创建行动，培育城轨交通绿色出行文化，贯彻科学有效的轨道交通管理制度，完善城轨交通绿色出行服务体系，最大程度地吸引更多乘客选择城轨交通出行，充分发挥城轨交通在城市公共交通中的骨干作用，系统提升城市轨道交通网络客流水平，增加城轨交通乘客出行量和轨道覆盖通勤出行的比例。截至2024年12月，合肥轨道已开通运营线路6条，运营里程突破200公里，线网总客流突破21亿人次。为争取早日实现行业战略目标，合肥轨道交通集团拟构建以轨道官方APP为入口，通过发行地铁电子计次、期限、权益票、优惠票等票种，切实降低乘客出行成本；通过新增营销工具功能，通过活动等方式增强乘客APP深度互动；加强平台的商业化能力，包括广告、招商、TOD等，满足轨道交通数字化转型要求。通过开展本项目，针对运营特点，挖掘数据价值，寻找数据流量的变现模式，同时达到切实降低乘客出行成本，提升乘客服务质量，增强民众地铁出行意愿，提升公共交通出行率的目的。1.2项目目标通过升级改造合肥市轨道交通公共信息服务平台，打造统一支付平台，实现多元化票卡、多支付、多优惠、多形态出行支付体系，丰富乘客出行支付选择；整合合肥轨道现有商业数字化资源，加强企业文化宣传，使其成为体现合肥轨道运营服务、使命担当以及展示良好形象的重要窗口；结合城轨行业信息化发展进程，不断优化轨道交通数字化资源运营（含合肥轨道官方APP）运营模式，为未来实现流量变现，提升轨道交通数字化商业价值创造条件。1.3建设范围鉴于合肥市轨道交通运营管理现状以及公司整体数字化战略，拟升级改造合肥市轨道交通公共信息服务平台，实现电子票卡、营销、广告、权益、碳积分、招商管理等数字化运营功能改造。本期项目的实施范围包括系统建设主要内容（含管理标准化、需求分析、总体设计与详细设计、系统软件开发及集成、移动端开发与集成、定制化开发编码与测试、运行环境部署、接口集成、系统上线、功能培训、质保、合同期内的运行维护等）。总体上，本项目将整体升级改造合肥市轨道交通公共信息服务平台，建设内容主要包括但不限于：原有合肥轨道APP功能模块全量迁移：用户管理、扫码乘车、出行服务、新闻咨询、广告服务等所有功能模块（包含原有数据及日志）。统一支付平台：实现统一支付接入及开放、清结算、风控管理、乘车优惠等内容。电子票卡管理：实现电子票卡定义、发行、购票、激活、退款、核销、对账等功能。广告管理：实现广告发布、投放、管理、报表管理、程序化广告对接。营销管理：实现活动管理、奖品管理、活动模板管理、白名单、统计分析。权益平台：实现权益产品管理、权益发放、分销、核销、对账，实现碳积分、轨道会员规则管理、计算、获取、兑换等。外部系统改造：包括互联网票务平台相关内容改造等。招商管理：建立地铁招商平台。系统正式及测试环境在合肥轨道城轨云平台部署（包含合肥轨道APP系统迁移）。在本项目建设范围内的其他业务管理需求。1.4项目进度要求本次项目计划在招标完成后正式启动，初步拟定于2025年9月启动，暂定2025年10月完成原型搭建，2025年12月核心系统的建设并测试上线，暂定在2026年6月份进行项目的初步验收，2026年12月进行最终验收。为能有效的控制项目的质量，现将各阶段任务进度初步分解如下（具体进度计划将根据实际工期与最终中标单位进行协商调整，按照项目计划，以双方确认的调研与需求分析报告为基准开展后续的一系列工作）。序号内容开始时间完成时间1项目启动2025年9月2025年9月2需求调研2025年9月2025年9月3管理标准化2025年9月2025年9月4方案设计与原型搭建2025年9月2025年9月5开发集成与测试2025年9月2025年11月6测试上线运行2025年11月2025年11月7联试联调2025年11月2025年11月8上线试运行2025年12月2026年6月9初步验收2026年6月2026年6月10最终验收2026年12月2026年12月11维保期2026年12月2029年12月投标人应在投标文件中根据本工程项目进度要求提供详细的计划表（初步计划供参考使用）。在工程实施阶段，招标人若提供本项目工期修订计划，投标人应根据最新工期计划修订实施工期计划表，并按合同规定报招标人确认。招标人有权调整实施周期，投标人须无条件响应并不得因此提出任何费用要求。投标人必须和招标人达成一致才可以根据实际情况修订满足最终实施周期目标的工程进度表。如遇不可抗力或其他客观因素导致工期延误，则由甲乙双方协定对项目计划做相应的调整顺延。1.5关联系统关系图1.6相关定义本文中所描述的招标人、建设方、合肥轨道，指的是合肥市轨道交通集团有限公司。本文中所描述的投标人、实施方、施工方，指的是中标单位。云平台涉及安全生产网、内部管理网、外部服务网三张网。具体介绍如下：安全生产网:用于承载城市轨道交通一线生产及调度人员服务运营生产类业务应用系统的计算机网络。内部管理网:用于承载城市轨道交通运营管理、企业管理、建设管理、资源管理等面向企业内部用户服务的业务应用系统的计算机网络。外部服务网:用于承载城市轨道交通乘客服务类等面向外部或公众用户服务的计算机网络。1.7项目总则（1）本用户需求书适用于本项目的统一的整体方案，包括提供配套咨询服务、配套系统软件与硬件的采购与安装，相关基础环境的搭建与安装，定制化开发设计（含接口设计）、设计联络、编码、测试、试运行、验收、人员培训、培训文档编撰以及维保期内的系统缺陷的纠正和维护等。（2）本用户需求书是对本项目的系统功能、运行要求、系统接口、供货范围、责任范围、系统集成、技术服务、项目管理和协调、质量控制、安装、调试和验收等的具体规定和要求。（3）本用户需求书是本项目的技术要求和准则，是投标人编制技术部分的依据。投标人应对用户需求书中要求的所有货物和服务投标，不能只对其中一种或几种货物和服务投标。（4）本用户需求书并未对一切用户需求细节做出规定，也未充分引述有关标准和规范的条文，投标人应保证提供符合本用户需求书和符合国家有关工业标准要求、国家有关信息安全等强制性标准的货物和服务。投标人应充分调研了解招标人的需求，积极配合招标人细化功能需求。对于功能需求不详尽之处，投标人可以在投标文件中予以补充。投标人采用的软件产品功能并不以本用户需求书为唯一依据，投标人可以结合所用软件产品对本用户需求书的部分功能需求提出优化方案。（5）软件产品应按照本用户需求书及国家和地方规定的标准和规范进行设计和实施。若在设计和实施中应用的某项标准或规范在本用户需求书中没有规定，则投标人应详细说明其所采用的标准和规范，并提供该标准或规范的完整中文资料给招标人。只有当其采用的标准和规范是国际公认的、惯用的，且等于或优于本技术要求书的要求时，此标准或规范才能为招标人所接受。（6）投标人提供的文件，均应使用国际单位制（SI）。所有交换文件、工程图纸及相互通讯，均应使用中文。不论在合同谈判及签约后的工程建设期间，中文是主要的工作语言。（7）招标人在设计、开发、实施过程中对于投标人实施方案的确认（包括软件产品各模块配置、功能描述、范围界定及工作流程等的确认），不代表招标人将为投标人采用的产品方案承担责任。招标人可安排人员参与软件产品的安装与调试工作，但不承担任何责任，投标人应对全部软件产品的供货、检验和质量等负全部责任。（8）投标人应完全保证所供货物的安全可靠性、合理性、完整性和优良性。无论是否经过招标人确认，投标人都应无条件对所供货物中的缺陷、不足和与合同不符的地方进行修改、补充或更换，而不增加任何费用。（9）如招标人在投标人采用的信息系统运行期间发现投标人所实施的系统不满足本用户需求书的技术条款，招标人有权要求投标人修改或增加，为此引起的一切费用由投标人负责。（10）合同签订前后，投标人都应按照招标人规定的要求提供其所需的设计资料，并按招标人实施和设计进度要求随时修正。（11）投标人不能在所开发的系统中驻留后门程序。（12）项目以成熟中间件产品组合为基础，结合具体需求进行定制开发及集成相对应功能模块的方式进行实施，以缩短项目实施周期，降低项目实施的风险。投标人应对总体目标需求进行详细深入的分析，充分考虑工程实施过程中各种变化的可能，并将其费用考虑在总报价范围内；在项目实施过程中，由于投标人考虑不周，而向招标人提出的相关要求将不予考虑其费用。（13）本用户需求书所有条款的解释权属于招标人。（14）投标人须承担在建设及维保期过程中按招标人要求进行的系统升级、设备更新（投标人投资部分）的费用。（15）投标人必须承诺，如本项目中标，将在合肥设立固定的项目机构和维修服务机构，配备足够的技术人员做好售后服务。（16）投标人应对本用户需求书中所有条款必须逐条对应、明确答复和提出详细的技术建议，详细写明参数、规格和方案内容:投标方案中的产品技术规格应不低于本用户需求书的要求。（17）投标人必须承诺，如本项目中标，在项目实施期间，若因其技术过失、系统缺陷、管理不当延误工期、违反法律、引发事故，对招标人或其自身造成损失，投标人应负全责并承担所有相关费用。（18）投标人在投标时需充分考虑到项目执行时与合肥轨道城轨云平台、ACC平台、互联网票务平台、第三方支付平台、其他相关平台接口配合工作，并将相关的配合费用包含在合同总价中。（19）投标人在系统试运行前需完成APP的开发测试并完成在苹果、安卓市场及鸿蒙系统的上线发布，相关费用包含在合同总价中。（20）投标人针对本项目开发完成的应用软件、制定的技术标准及相关所有技术文件，其知识产权归招标人所有，投标人必须按招标人的要求及时提供包括应用软件设计文档、源代码、接口协议、软件使用手册、维护手册、以及包括数据结构、流程等软件详细设计及硬件设计在内的完整的技术文件。（21）招标人对本用户需求书范围内的任何需求调整均包含在合同总价中。（22）对于项目的设计、验收，在项目期间（包含维保期内），投标人需按招标人的要求组建专家评审组，按招标人需求组织相关专家评审会议，涉及的专家评审费用、差旅费用等相关费用由投标人支付。（23）投标人建设的系统能保证7x24小时不间断运营。（24）在项目实施阶段，招标人保留对项目范围进行调整的权利。投标人实施的软件架构能够满足硬件的自由扩充，当招标人根据实际运营需求增加硬件时，系统应满足在不改变后台控制系统的情况下，仅通过硬件管理软件可以扩充硬件资源。无论项目范围有无变化，投标人应保证整个系统的性能和功能，并得到招标人的认可。（25）项目合同期内（含维保期），投标人在每次系统版本更新发布后，投标人负责在测试环境、正线运营线路环境测试系统的各类功能，并须提供主流型号手机供测试使用（包括但不限于：安卓、IOS、鸿蒙等），涉及各类票种的购买、刷闸等测试产生的所有正线交易费用，由投标人自行承担，该部分的费用已包含在合同总价款内。（26）投标人负责所有的新线接入开发，且需要保证多版本同时在线实施，正线测试版本的系统可以同时在新线和已运营线路贯通性使用。（27）为保证合肥轨道APP账号及所含信息的连续性，投标人负责与互联网票务平台系统的接口实施，并配合完成账号及所含信息的同步工作。（28）投标人在项目周期（含运维期）内应根据招标人运营需求配合实现各类营销活动，该项费用已包含在合同总价中。（29）项目执行期间和维保期内，与原有APP集成商、互联网票务平台沟通协调费用、接口费用等相关费用，由投标人承担，包含在合同总价中。（30）维保期内在5.详细功能需求内需求的优化升级，投标人承诺不涉及费用增加。（31）合肥轨道城轨云平台提供测试上线运行起2年内，主备互联网专线（不同运营商），主专线不小于200M，备专线不小于200M。（32）保障本项目在合肥轨道云平台（包括但不限于：主中心、灾备中心、测试中心等）顺利完成部署其应用。如本项目系统在合肥轨道云平台（包括但不限于：主中心、灾备中心、测试中心等）部署过程中涉及软件等相关资源的采购，以满足云平台部署、应用及接入要求，相关费用由投标人承担，包含在合同总价内。（33）投标人需充分考虑如本项目执行期间和维保期内，合肥轨道云平台未完成建设（包括但不限于：主中心、灾备中心、测试中心等），投标人须在项目终验、维保期结束及招标人提出的相关节点无条件按照招标人要求将本项目相关系统、软件、源代码及源代码开发环境等部署至合肥轨道云平台（包括但不限于：主中心、灾备中心、测试中心等），同时完成相关历史数据的迁移、系统功能的验证测试、主备切换测试等，并出具相关测试报告，相关费用包含在合同总价中。（34）本项目部署在珠江路控制中心城轨云，本项目的竣工验收工作先行开展，验收通过后开始三年的维保期。待线网指挥中心城轨云建成，投标人完成合肥轨道本项目相关系统主备中心的部署、测试、数据迁移等相关工作。主备中心平稳运行6个月后，开展本项目部署在线网指挥中心城轨云的项目竣工验收工作（包含主备功能及测试中心）。（35）本需求书中5.详细功能需求内功能具体实现方式以《合肥市轨道交通公共信息服务平台升级改造项目详细设计方案》文档为准。（36）本需求书中涉及的所有项目代码开发工作，必须严格遵循第7章《版本控制与代码要求》的相关规定。开发单位需建立本地化代码控制机制（如GitLab），确保代码的版本管理、权限控制、变更记录、备份恢复、规范化注释及符合国家标准的文档编制等要求，确保项目具备良好的可维护性、可追溯性与可扩展性，满足后续城轨云平台的二次开发与运维管理需求。（37）软件著作权归属：本项目执行过程中（含开发、测试、部署、维保期内优化升级等所有阶段）由投标人根据招标人需求、指令及确认的设计方案所独立或合作开发完成的所有软件（包括但不限于源代码、目标代码、相关文档、界面设计、数据库结构等）、模块、功能及其衍生产品，其完整的、无瑕疵的著作权（包括但不限于发表权、署名权、修改权、复制权、发行权、出租权、信息网络传播权、翻译权等）及相关知识产权均永久性、排他性地归属于招标人（合肥市轨道交通集团有限公司或其指定单位）所有。投标人承诺在项目各阶段（包括但不限于验收、移交、维保期结束等节点），按招标人要求无条件、完整地提交与上述软件相关的所有源代码、开发文档、技术文档、设计文档、接口文档、数据库脚本、编译环境说明等必要材料，并配合招标人办理软件著作权登记及其他相关知识产权登记手续，相关费用已包含在合同总价中。除非经招标人书面明确同意，投标人不得将为本项目开发的软件（或其任何部分）用于其他任何项目或目的，亦不得向任何第三方披露、许可或转让。投标人仅拥有为履行本合同项下义务所必需的、非独占的、不可转让的使用权。若投标人在投标或项目实施中使用了其拥有知识产权的现有软件或组件（非为本项目专门开发），投标人须在投标文件中明确列出，并承诺授予招标人针对本项目的、永久的、免费的、不可撤销的、全球范围内的使用权（包括运行、展示、复制、修改、集成、分发等为实现本项目目的所必需的一切权利），确保招标人使用本项目成果不受任何第三方权利限制。若因此产生任何知识产权纠纷或费用，由投标人承担全部责任。（38）本项目在合肥城轨云环境部署时，须完整保留并迁移合肥轨道APP二期的全部功能和数据，包括但不限于合肥管理台、出行、IPIS等模块。迁移范围应覆盖测试环境和生产环境，确保在城轨云上运行的APP二期系统与原有平台在功能、性能、接口及数据上做到无缝对接与平滑切换，并在部署完成后提供详细的验证报告和迁移回滚方案。（39）SSL证书需求：为保障系统数据传输安全，本项目需配置部署SSL证书，要求如下：​类型：泛域名SSL证书，覆盖*.及其所有同级子域名有效期：自项目上线起满3年；到期前60天，投标人需完成证书更新、部署测试，提交更新报告。​合规性：符合国家信息安全标准，具备权威CA认证，兼容主流浏览器及移动操作系统，无安全警告。​部署维护：负责证书在珠江路、线网指挥中心城轨云环境的安装调试；维保期内证书问题2小时响应、4小时修复。​配套保障：强制启用HTTPS（HTTP自动跳转），每月至少1次证书安全扫描，提交监测报告。（40）对文中提的“可”，“支持”，“需”等字眼，均按照要具体实现相应功能理解，招标人明确可以不实现的除外。2.现状描述2.1业务现状合肥轨道现有的官方APP于2018年12月上线使用。截至2025年2月底，注册用户量约650万，日活用户量约25万人，日均进站量占比约25.6%。2.2信息化现状合肥城市轨道交通ACC二期工程主要包括：ACC二期、互联网票务平台，于2024年底上线。系统平台随线网云平台建设系统运行环境调整为云架构，LC系统在线网云平台模式下去节点化，LC功能由清分中心ACC二期实现，整合传统AFC结算清分系统与外网结算清分系统等。包含清分中心ACC二期、ACC一期、互联网票务系统数据迁移及为后续线路AFC系统提供接入能力。ACC二期工程按照近远期25条线规模设置，日均客运量约148万人次。合肥市轨道交通ACC二期用于轨道交通各条线路之间，与城市通卡、银联及其他相关系统之间的收益清算、交易数据的整体处理及统计分析，并具备对轨道交通各线路AFC系统整体运营管理的功能。互联网票务平台自2018年逐步完成传统售检票到互联网+自动售检票系统的转型升级，开通手机扫码移动支付购票、二维码及银联云闪付过闸功能，2022年实现第三方渠道二维码（支付宝、微信）过闸，并具备与第三方支付机构的票务清分清算功能，实现互联网+AFC。支持全线网自动售票机具备手机扫码支付购票功能，自动检票机具备二维码及银联云闪付过闸功能，半自动售票机可处理非现金购票及过闸业务，互联网支付平台具备与第三方支付平台联网，支持移动支付介质（或其它支付介质）在轨道交通网中的使用及关联的资金清算、交易数据的整体处理及统计分析，并具备对轨道交通各线路AFC系统整体运营管理的功能。3.总体要求3.1项目实施原则项目要求以成熟的中间件和技术架构为基础，结合具体需求进行定制和二次开发的方式进行实施，参考微服务架构标准。业务驱动项目实施以提供业务实现为首要因素。应从合肥轨道公司业务实际需要出发，保证在系统实施后能提高工作效率。安全性技术平台必须要符合《中华人民共和国网络安全法》、《GB∕T22239-2019信息安全技术网络安全等级保护基本要求》、《中华人民共和国个人信息保护法》、《中华人民共和国数据安全法》、《关键信息基础设施安全保护条例》等国家法律法规的信息安全管理要求和设计规范。保障关键信息的加解密保存，系统数据完整，防止信息被非法修改。集成性系统具有良好的集成性，与原合肥轨道APP二期项目相关系统平台集成。禁止异构数据库模式的部署，禁止使用投标人自己研发的中间层平台进行代码研发与部署。可扩展性平台采用分布式微服务架构，系统有良好的可扩展性，可以根据业务需求进行水平扩展或垂直扩展，以满足日益增长的用户量和业务需求。(水平扩展：增加服务器数量，线性扩充系统性能；垂直扩展：提升单机处理能力。)开放性系统实现通过标准或通用的接口向外部提供数据和功能的实现，且对接口有安全性的保护控制。系统应符合开放的原则，充分考虑各种业务需求有机结合，建立完善的系统整体构架，可与外部系统进行通讯并可提供标准的接口。既能实现业务需求，还可以完成数据交换、信息共享功能。系统架构须符合国家信息安全、招标方标准和国际主流技术标准，开放性好，便于系统的升级维护、以及与各种信息系统进行集成。可伸缩性要求在不用修改系统架构的情况下，通过增加或增强相应的设备即可实现系统功能的扩展实现。系统统一各个层次管理规范，统一数据结构、数据表达方式、数据访问方式。系统须提供通用的组件实现，能够减少重复开发工作，保证产品和项目的质量，有利于系统的扩展。在统一的数据环境下集成化开发各个模块，模块的划分应独立于当前的组织机构，各个模块之间的数据交换是结构化的、公用的，最大限度消除冗余和不一致。冗余性通过在系统中引入冗余组件，当某个组件发生故障时，其他组件可以接管其功能，避免系统中断。3.2总体技术要求3.2.1软件技术架构系统软件架构设计满足“数据自主、技术自主、风险可控”的基本原则。1.架构要求：整体上软件架构应合理，支持未来的系统升级改造。支持分布式集群架构，具备弹性扩容能力、支持负载均衡，支持服务统一部署、统一规划、统一更新、统一维护等。集群管理要考虑应用部署要简单，硬件资源利用率要高。采用的技术框架和中间件通用领先、使用维护门槛低，架构设计标准原则为编码简单、配置简单、部署简单，能独立部署。2.体系架构：基础平台采用分布式微服务架构实现，对于业务管理模块要求采用多层B/S结构的方式进行架构设计。3.开发框架：软件采用主流框架开发设计实现，支持产品模块级的源代码开放，须提供平台封装的开发框架、具体软件开发环境及相关技术资料并提供培训服务。4.后端技术采用JAVA等主流开发语言开发。5.数据库应充分考虑采用读写分离、分库分表、内存数据库等技术，以保证系统的整体性能和可靠性。5.平台（系统）部署在合肥轨道城轨云环境。6.系统可随业务的发展和变化而调整，要具备较强的开放性和扩展性，各项技术指标要标准化。7.应支持包括不限于：H5、微信小程序、微信公众号、支付宝小程序等第三方平台对接。8.使用Android、IOS、鸿蒙OS的原生开发框架完成APP的基线功能，让移动应用获得最优的用户体验与性能。3.2.2系统性能指标要求实施单位所提出的系统架构方案必须达到以下技术性能指标：系统并发数要求管理后台系统主要用户为集团公司内部业务管理人员，用户总数＞100人，系统支持并发用户数100人，在线用户1000人；APP注册用户量1500万、日活数目标100万人次/日，系统满足每日不少于400万笔二维码车票客流处理能力，并发数支持不低于2000个并发用户。2.在使用负荷最高时，单台服务器的性能在如下范围内：CPU最大使用率（<80%）；内存最大使用率（<80%）。（使用率=（已使用/总量）×100%）3.在正常使用期间，单台服务器的性能在如下范围内：服务器CPU平均负荷率≤50%，服务器内存平均负荷率≤50%。（CPU（内存）平均负荷率=CPU（内存）使用率/时间）4.所有系统在最大并发用户的情况下，及项目所采用硬件配置环境下，进行典型操作（如乘车展码、首页、出行、列车动态、行程记录、购买操作）等操作时，系统用户交互时间小于1秒，信息录入、修改型简单事务平均响应时间小于2秒，如存在超时情况的投标人必须提出合理解析，且得到招标人的认可。5.各类固定统计报表下载及可视化报表刷新每次系统执行运算的时间小于5秒。6.系统最高负荷持续时间不超过1小时。系统运行中不能出现响应性下降或内存溢出等情况。在合同期内保障核心指标满足要求，配合第三方评测单位整改。3.2.3系统可靠性指标系统可靠性应达到如下要求：1、系统能实现系统主机、操作系统、网络、数据库7×24小时平稳运行。2、业务的可用性应达到：99.9%。（可用性=系统运行时间/(系统运行时间+系统停机时间)）3、MTBF（平均故障间隔）>2000小时。（总的运行时间除以（重大故障次数+严重故障次数））4、MTTR（平均修复时间）<1小时。（总的故障时间除以（重大故障次数+严重故障次数））5、系统实现服务集群方式，单台设备故障不影响业务进行，实现故障恢复不中断业务服务。备份级别采用数据级备份。6、负载均衡：系统能够合理地将请求分配到不同的服务器节点，避免某个节点负载过重而导致性能下降。3.2.4运行环境要求投标人系统需要能支持以下的运行环境：1.支持运行在主流的服务器上；2.服务器操作系统：操作系统需具备足够的稳定性，不出现系统宕机问题。3.数据库：MySQL、Oracle、人大金仓、达梦等主流据库。4.编码：UTF-8、UTF8MB4。5.浏览器：后台管理系统PC端支持windows、macOS等操作系统环境下的Chrome、360、火狐、搜狗、edge等主流浏览器。6.移动端需支持安卓、IOS、鸿蒙OS系统等移动设备（包括但不限于手机等）运行，市面主流手机型号均可安装使用。3.2.5数据管理要求1、数据的准确性：数据需求能真实反映业务需求。2、数据的及时性：满足数据更新、传输、交互等及时性要求。3、数据的一致性：元数据在系统间、系统内不同模块间保持一致。4、数据的唯一性：项目实施应对系统/模块间的信息（数据）流进行分析，要保持信息（数据）的定义和属性的唯一性和一致性。5、如涉及历史数据的清理、转换和导入，需提出合理可行的方案。6、必须对数据录入和导入进行规范性校验；数据录入界面符合易操作性的要求。7、从初始化开始，系统的数据必须真实、有效，所有的测试数据必须清除。3.2.6集成技术要求投标人提供与现有合肥轨道APP平台的衔接方案、升级发布方案，不对现有APP运营和使用造成不良影响。投标人需承诺在项目实施阶段，制定详细的系统对接方案。基于分布式微服务架构进行设计，系统须提供多层次的应用开发接口，所有的功能基于软件产品集成组件的方式进行函数化或者过程化，为进一步的应用开发提供接口基础。系统接口要求如下：接口参考既有项目实现规范，对集成的接口标准、参数要求等内容须符合招标人公司企业应用集成规范和标准的规范要求。本项目范围内，按照招标人公司企业应用集成规范和标准的要求，需封装到服务管理平台上的接口服务，由投标人统一进行封装和发布。3.2.7系统安全要求需求、设计、开发、测试、上线各阶段安全建设项对照三级等保条款：需求阶段：信息安全策略、风险评估报告；设计阶段：安全设计说明书、日志审计方案；开发阶段：代码安全检查、依赖漏洞扫描；测试阶段：渗透测试、环境安全隔离；上线阶段：安全监控、应急预案演练。（一）身份鉴别系统密码策略按以下要求开发和配置：1.建议8位以上，数字+字母大小写+特殊字符；2.登录失败次数大于5次时应账户锁定15分钟，配置登录超时策略，登录后30分钟无操作自动退出，需重新输入用户名跟口令；同时页面提供用户提醒；3.有定期更换密码的模块策略；4.在控制台保存和输入账户密码的数据传输过程中采用有效的加密算法对用户信息进行加密，确保在网络抓包时，数据包中不会出现明文信息；5.系统平台在进行用户注册、登录时应该对用户注册、登录的信息进行审核，依照一些特定的标识如手机号、邮箱、企业微信等进行绑定，避免系统账户被恶意注册。为了便于识别用户来源，对用户注册时需添加相应标识，以区分内部用户注册和外部用户注册。（二）访问控制（含外部用户）用户创建，用户权限分配：1.系统需要能够创建用户、能够给对应的用户分配一些相应的权限的功能模块。比如：等保经常要求系统要有3个用户：系统管理员、安全管理员、审计管理员，三个管理员分别拥有相应的权限；2.开发建立合理的权限分配系统，将系统操作的每个动作进行权限命名并分类，有详细的权限分配表单，并有选择框能够为用户进行权限的选择。3.外部用户只能在受控范围内使用系统功能，不具备用户创建、用户权限分配等系统配置相关管理功能的权限。（三）安全审计系统需要有操作日志、登录日志等日志留存、日志上传功能模块：1.系统平台需要有模块能够记录留存日志（6个月），存放系统的日志，方便后期上传到日志审计；2.系统后台需要有整套的用户行为审计策略，记录每个用户进行了哪些操作，比如：登录、点击查看了哪个模块、修改了哪个参数，再比如管理员账户今日在某个时间点创建了一个新用户，并进行了赋权操作等；3.系统平台需要对特定重大的安全性操作进行标记。比如今日某个用户进行了删除另一个用户的操作，此操作需要标记标红；4.系统平台的日志模块需要有一键导出功能，能够将日志导出到本地路径；5.系统平台的日志模块需要有按时、按需进行日志内容的打包备份，设置备份路径，可以设置一个时间比如一周定期将日志内容保存到所设置的路径下；6.系统如有用到用户注册功能，需构建合理的审核机制对用户注册信息进行审核，避免系统用户被恶意注册。（四）入侵防范1.系统在建设时需采取相关代码规范，以尽可能避免SQL、XSS注入漏洞；2.系统在建设上需使用正版且稳定的数据库、中间件，避免盗版或者旧版的数据库、中间件在后期会被漏扫工具识别出高危漏洞；3.系统在建设完成后，需进行漏洞扫描，解决系统建设完成后存在的系统漏洞问题，发现漏洞及时处理，保证系统无安全漏洞后上线；4.系统在部署到服务器上之前，需对服务器进行安全漏洞排查，及时更新系统补丁，确保服务器环境无中高危安全漏洞后再进行系统的安装与部署；5.系统在部署到服务器上后，需进行安全测试，为服务器安装招标方要求的主机版杀毒软件，并进行测试，测试系统和杀毒软件的兼容性，保证二者兼容；6.系统在开发阶段中，需严格摸排各端口使用情况，需关闭或者限制用不到的端口，避免因为多余端口开放所导致的安全入侵事件发生；7.系统在开发到建设完成后，投标方需摸排此系统需要用到的各项服务，制定服务清单，在部署到服务器上时，对照服务清单进行服务的开放，对于一些用不到的服务，在不影响业务正常运行的前提下将其停止；（五）恶意代码防范系统在建设完成部署到服务器上时，需要保证服务器环境的安全性，需要为服务器安装招标方要求的主机版本杀毒软件，并对系统和杀毒软件的兼容性进行测试，保证二者兼容；（六）数据完整性1.系统需要添加SSL证书，采用更安全的、保密性更高的https协议，禁止使用http协议；2.系统开发过程中有数据传输和存储的需求时强制需要用到有效的加密算法，保证数据不被篡改和非授权访问。（七）数据备份恢复1.系统开发建设时需提供数据本地备份模块，能够将系统平台的日志数据、用户数据、配置数据等特殊数据以某种格式保存；2.系统开发建设时需要有异地实时备份相关功能模块的考虑，确保系统平台的部分或者全部数据能够利用通信网络实时备份至备份场地；3.系统需要有定期备份的相关功能模块，能够设置定期异地备份时间；4.系统在开发建设完成，并通过测试上线后，需要保留副本和系统调试的相关数据；5.系统在建设完成上线部署时，要求进行热冗余部署，确保系统不会出现单点故障问题。（八）剩余信息保护1.系统在开发建设时，前后端代码中不要出现敏感信息注释；2.需确保系统在对用户信息等敏感信息进行传输、记录、短暂存储后进行缓存的清除或释放。（九）个人信息保护1.系统开发建设时，应严格按照最小采集要求，需仅采集和保存业务必需的用户个人信息，降低出现个人信息泄露的风险；2.系统在开发建设和测试阶段，需确保未授权访问行为不会出现，采取合理的手段禁止未授权访问；3.系统开发建设时，需采取合理的手段避免用户的个人信息被盗用、挪用、下载等，并对此类行为进行监测、预警和记录，以便风险溯源。4.用户敏感数据（如人脸信息）存储需加密，密钥由甲方独立管理。（十）安全等级保护从进场到维保期结束（维保期结束当年的12月31日）前投标方需配合招标方通过本系统的信息系统安全等级保护三级测评，每年开展渗透测试，并在规定期限内完成网络安全问题整改，提供整改报告。整改费用包含在总价内不收取额外费用。3.3总体设计要求为保障关键业务场景（如电子票购票、支付、核销、优惠活动等）的用户体验与系统交互一致性，平台需遵循以下总体设计要求：（一）关键流程设计绘制覆盖核心业务流程的用户旅程图，明确用户在不同场景下的行为路径与交互节点；制作对应的流程图与交互原型图，体现系统响应与页面跳转的完整链路；旅程图需覆盖从用户进入平台、选择票种、支付下单、领取核销、参与优惠等全过程。（二）界面与交互设计标准明确各终端（APP、微信小程序、H5）的界面风格与交互逻辑，确保风格统一、体验一致；定义核心交互要素的反馈机制（如按钮点击反馈、加载动画、错误提示）；设置关键性能指标：如点击响应时间≤1秒、页面加载时间≤3秒；制定界面适配标准，确保在主流设备与不同分辨率下显示无误，包括适配比例、字体、图标大小等规范。（三）原型与流程说明提供完整的原型设计文件（可为Axure、墨刀等工具格式），覆盖所有主要功能页面；对原型中重要交互节点，提供流程说明文档，标注用户行为与系统反馈的对应关系；在需求文档中嵌入关键界面效果图示例，用于支持后续开发理解与实现。（四）用户反馈机制建立用户反馈采集方案，包括在线问卷、埋点数据分析、点击热力图等方式；反馈机制应覆盖购票流程、支付体验、核销便捷性、优惠使用感受等维度；提供反馈数据的归集与分析周期建议（如每月分析优化一次）。4.管理标准化需求4.1工作范围管理办法编制：对现有的管理办法、工作标准制度进行补充，包括但不限于管控流程梳理、数据标准梳理、体系制度梳理等。对缺少的管理办法进行编制补充。包括但不限于《合肥市轨道交通公共信息服务平台升级改造项目管理办法》等相关文件。管控标准：梳理明确本项目所涉及业务范围的管控模式、管控重点以及相应的组织、职责、岗位、人员标准。业务标准：梳理明确本项目所涉及业务范围的业务管理流程、作业标准等。数据标准：制定明确本项目所涉及的业务范围的业务数据标准定义、编码原则制定、数据物理模型定义等工作。IT技术标准：制定明确本项目相关的技术平台产品标准、IT技术架构标准、基础架构标准、集成标准、数据交换标准、系统操作标准等。4.2工作内容4.2.1方案设计与规划结合合肥市轨道交通集团有限公司信息化战略和合肥轨道交通数字运营管理业务要求及轨道交通运营子公司、资源子公司、投发子公司等主管部门、子公司的需求，通过借鉴国内轨道交通企业数字化运营管理和信息化建设实践，提出公司数字运营管理平台总体信息化建设体系和方案，实现对公司数字化运营整体解决方案的规划和项目实施的指导作用。4.2.2管理职责与岗位结合合肥市轨道交通集团有限公司发展和现状，充分借鉴实施方丰富的行业经验、行业实践以及方法论，对涉及本项目范围内的业务管控模式、管控重点、管理职责划分、岗位和人员定义进行合理审视和诊断，对合肥轨道交通数字运营管控模式、管理职责、岗位进行梳理、优化和调整，提出可改进和优化的建议供招标人参考。4.2.3管理流程标准化围绕上述业务范围，针对合肥市轨道交通集团有限公司具体实际制定合肥轨道交通数字运营管理平台可实现的业务流程，具体以设计联络会为准：业务流程架构定义：定义本项目业务范围的业务流程分级结构，制定流程清单和层次，以及每个业务模块各级流程之间、与其他业务模块流程之间的连接关系，包括连接节点定义、输入输出定义等。流程详细描述：详细定义和描述业务模块各级流程适用业务范围、业务执行描述、流程归属、涉及的部门、职责、岗位、操作等内容。流程步骤说明：详细描述业务模块每个流程的活动（步骤）名称、活动描述、活动执行职责、岗位、活动之间输入输出、活动作业规范等内容。流程关键数据定义：详细业务流程中涉及的关键业务数据内容，包括主数据项定义、数据关键属性、数据来源、数据流向等。目标流程定义：结合上述流程描述内容，找出本项目可实现程度以及现有业务流程之间的差距并进行差异分析，有针对性地提出未来目标改进流程，并提出可实现的建议方案和措施。4.2.4数据标准化围绕上述业务范围，制定业务数据标准。参考其他地铁公司的编码体系，根据合肥市轨道交通集团有限公司的实际情况，完善外部建设项目管理编码体系。4.2.5IT技术标准化制定本项目范围内的信息平台产品标准、IT技术架构标准、集成标准、数据交换标准、系统操作标准等，包括但不限于以下内容：管控标准：明确本项目所涉及业务范围的管控模式、管控重点以及相应的组织、职责、岗位标准。业务标准：明确本项目所涉及业务范围的业务管理流程、工作标准。数据标准：完成本项目所涉及的业务范围的业务数据标准定义、编码规则制定、等工作。IT技术标准：制定本项目相关的技术平台产品标准、IT技术架构标准、基础架构标准、集成标准、数据交换标准、系统操作标准等。需求变更与版本控制标准：明确需求收集、变更评审、优先级排序、确认通知及版本发布的各环节流程；列出变更事项记录的模板和会议纪要的格式；规定产品原型验证周期和用户调研反馈机制，以便在产品开发过程中进行迭代优化。 提供需求变更申请、评审记录和版本发布日志的标准模板。4.3工作要求1.前期需求调研，开展对合肥轨道交通数字运营管理部门的调研工作，掌握数字运营管理现状与工作基础，理清当前相关部门的职责分工、工作流程等，为构建合肥轨道交通数字运营管理体系奠定基础。2.辅助完善合肥轨道交通数字运营管理体系供业务部门参考，包括并不限于：合肥轨道交通数字运营管理办法（主要包括组织机构与责任体系、运营管理、营销、广告工作程序、统计以及相关常用表格文件等）。5.详细功能需求5.1统一支付平台为后期票卡营销需要，本期需要在APP后端构建自己独立的支付体系，支持APP客户端乘车码支付、电子商城等功能。5.1.1统一支付开放平台建立统一支付开放平台，接入各大第三方支付平台，实现与各支付渠道（包括且不限于银联、微信、支付宝）的对接，为乘客提供便捷、多样化的支付服务体验。统一支付开放平台主要包括四大模块，分别为用户子系统、账户子系统、支付子系统、管理台子系统。1.用户子系统提供用户管理、绑卡管理、支付密码管理以及实名认证管理等；2.账户子系统提供账户类型管理、子账户管理管理等；3.支付子系统提供支付路由管理、支付通道管理、联机交易管理等；4.管理台子系统提供用户权限管理、系统参数配置、交易流水查询等。5.1.2清结算中心中心实现商户（商城、乘车码）与第三方支付系统的自动化对账功能，通过支付体系的全生命周期跟踪，实现对接每一个支付结算的全流程管理，并生成对帐结果以便于管理者的数据清算处理，以至产生相应的数据报表。1.记账子系统，包括会计体系、会计科目管理、会计科目增改废、会计科目作废、会计科目查询、财务报表等。2.对账管理，包括交易类型汇总查询、对账结果查询、对账明细查询、渠道对账单明细、渠道对账单统计、手工对账。3.账务管理，包括手工调账、商户支付流水查询、商户账户余额变动查询、商户账户管理、内部账户明细查询、商户账户明细查询、内部账户管理。4.针对合肥轨道APP与与第三方支付平台，信息交互过程中（生码请求，行程推送、扣款请求等），存在交互失败或无返回结果的信息，具备间隔n毫秒（时间可配置），重新发送功能。同时针对信息交易失败的结果，需在合肥轨道APP增加相应监控报警。5.1.3风控管理系统运用信息技术对风险进行管控，从而对风险进行识别、分析、评估、预警，识别并制订对应的风险管控策略，处理现实的或者潜在的风险，控制并降低风险所带来的不利影响。可对各类乘车码支付、互联网票务消费、充值交易数据进行统计、分析行为特征，系统能够自动识别恶意交易，对符合风控要求的账户需要进行黑名单管理。可通过数据收集、规则管理及案件处理等功能模块促进移动互联网业务在事前、事中及事后风险控制管理。风控管理主要包括黑白名单的管理、灰名单管理、风险控制规则管理、支持实时、非实时交易监控、风险报表等。具备对反欺诈机构下发报文的处理及反馈能力，业务包括账号或交易的止付冻结和查询等。乘客主动在支付渠道的应用中进行解绑操作后，需要支付渠道反馈解绑信息到统一支付平台（乘客存在单边或者未完行程时，限制其在合肥轨道APP和第三方支付渠道APP内解约或者更换支付渠道）。支付代扣渠道垫资未偿还或用户协议不存在等情况禁止展码功能。5.1.4统计分析实现客户信息、消费信息、客户端模块使用情况、设备信息的统计分析，以统计图表形式展示。5.1.5APP客户端可提供多种支付方式（包括但不限于银联、支付宝、微信）以供用户选择支付渠道，支持通过APP业务支撑系统对不同业务的支付方式进行配置。支持银联支付渠道升级改造。5.2电子票卡为支持合肥地铁日常票务运营高频、紧急需求，丰富乘客出行对多形态票种的需求，以及合肥地铁对节假日等特殊节日的票卡营销形态，因此在本期建设中需要增加电子票卡系统建设要求。合肥地铁APP应支持电子计次票、电子期限票、电子储值票票种定义及规则配置、展示、销售、支付、展码、激活、核销、计价、退票等操作。实现票种规则定义、计费、后台核销、后台激活、后台退票等功能。电子票卡后期可针对不同的支付渠道，做不同的时间段进行优惠策略等规则。5.2.1票种定义及业务规则合肥地铁官方APP应新增包括且不限于：期限票、计次票、储值票，并支持使用兑换码的形式，即用户可通过合肥轨道APP兑换电子计次票、电子期限票、电子储值票、优惠抵扣券。电子票票种的定义及业务规则在设计联络阶段确定，在项目执行期间和质保期内，任何票种的增加、修改涉及的本项目相关费用，包含在合同总价中。票种的定义及业务规则，不限于规则说明、目标用户、车票有效期、购票规则、车票激活及使用、票务规则、退款规则、激活有效期、票卡有效期及异常事务、账户风险管控等。所有电子票需支持双离线模式，支持通过配置，设置各类电子票的双离线模式的开启和关闭支持各类电子票信息配置管理，用户票券的使用查询、核销记录查询等支持各类电子票票面图、价格、次数、有效期、使用说明等内容的配置调整。计次票券：有效期内，乘客使用乘车权益券可享当次行程免费乘车，按行程次数扣减对应权益券；计时票券：有效期内，多次乘坐地铁（例如：7天11次乘车）。5.2.2电子票管理电子票管理相关规则在设计联络阶段确定，在项目执行期间和质保期内，电子票管理功能优化涉及的本项目相关费用，包含在合同总价中。支持对电子计次票、计期票商品管理，包括配置成本价、电子票售价、商品详情、购买协议、商品库存、单人购买数量限制、是否可退款等内容信息，电子票支持上传票面图片，可以配置。系统支持电子票状态管理，包括上架、下架、审核等。上架才允许在APP界面上进行展示、购买等。支持电子票乘客事务处理，行程补登、行程推送、单边扣款等相关功能。合肥轨道APP需把相关乘车扣款、电子票购买、退票、退款相关记录数据，同步推送至互联网票务平台，满足互联网票务平台数据查询需求。5.2.3电子储值票电子储值票（电子钱包）应设立用户电子钱包账户，供用户在合肥轨道APP上使用。电子储值票初始可用余额为0，可通过参数配置初始余额。应支持乘客通过APP线上充值并完成支付，卡内余额设上限X元，X可通过后台管理台配置。支持电子储值票的开通、使用、失效状态查询、余额查询等。电子储值票在线充值时按原价充值，乘客使用电子储值票乘车时享受N折优惠，折扣优惠可通过参数灵活设置。电子储值票储值账户的金额仅限于在乘车码上使用。系统应支持储值票卡乘车折扣等功能。电子票管理台可配置乘客在APP端当天、当月充值的总金额度、总笔数，退款仅支持原路退回，防止乘客利用充值余额能退款的规则进行恶意操作。电子储值票（电子钱包）账户，可通过参数配置充值N元赠送X元。优先使用用户本金余额，本金余额使用完毕使用赠送金额。本金余额与赠送金额提现规则可配置。5.2.4电子票购票包括但不限于以下：（1）支持电子票上架管理、库存维护、订单查询、退款。（2）电子票的购票和充值方式应支持包含现有的主流支付方式，包括但不限于合肥轨道现已支持的第三方支付渠道以及未来新增的支付渠道接入。（3）应提供销售订单管理功能。支持查询用户购买的所有订单状态、订单详情内容等信息，包括正逆向的所有状态的订单。（4）用户可购票的票种、售价及相关电子票业务规则可通过管理台进行参数化灵活配置，商品售卖支持总库存限制、单人购买数量限制，均可通过管理台进行参数化设置。（5）点击商品，可查询商品详情、购买协议等内容，便于乘客了解相关须知类信息。（6）用户可购买单张或多张电子票（可通过参数配置），若乘客重复购买电子票或已有激活的电子票，再次购买电子票时，需弹窗提醒乘客有可用电子票。5.2.5电子票团购支持大批量采购电子票卡（计期票、计次票等）功能，在已采购的列表中可针对具体某张电子票卡发放给具体乘客的手机号码上。该号码需要为该乘客注册的手机号码，若该号码未注册，系统模块给该手机号码注册，该手机号码用户后期可通过验证码方式在合肥地铁官方APP上进行实名注册后可使用该票卡。同时须满足相关功能需求，包括但不限于以下：（1）通过大批量采购电子票的相关登记信息，关联购买人群，实现批量给指定人群合肥轨道APP账户发送购买的电子票卡或对电子储值票进行充值；（2）供购买入口、信息登记入口，实现大批量采购信息登记。（3）针对计次票、期限票、优惠抵扣卷等非充值电子票的大批量采购，支持通过兑换码形式，对大批量指定用户进行发放。（4）针对电子储值票的大批量采购，通过对电子储值票账户充值形式实现，但需要区分大批量采购充值金额与普通充值金额，做区分存储。大批量采购充值、退款规则可通过参数配置，通过参数调整充值金额及是否允许退款。5.2.6电子票激活及使用主要功能包括并不限于以下内容：（具体内容在设计联络阶段确认，由投标人提供具体业务规则及方案。）电子票的使用规则可配置，（电子票的具体使用规则在设计联络阶段确定，在项目执行期间和质保期内，电子票使用规则的修改，都包含在合同总价中。）已经购票的电子票卡应在规定的范围内进行激活，实现激活规则可配置，系统将基于激活规则做激活有效期的判断。乘客在APP已购票卡列表总选择需要激活的票卡，激活功后，票卡方可使用。电子票激活时弹出提示页面，页面包含使用说明、卡券规则、电子发票开票规则等，需乘客阅读确认后方可激活。可以同时激活多张不同类型的电子票，激活时需弹出相关提示让乘客确认，告知乘客存在权益重合情况，可通过管理台配置电子票展示优先顺序规则（展示顺序规则包括但不限于以下：剩余有效期短的优先展示；剩余次数少的优先展示；按照可配置的顺序展示各类电子票），且支持手动切换电子票。电子票激活后，若乘客有多张可用的电子票，优先选择展示何种电子票的规则可配置。如存在即将失效电子票需提前弹窗提醒乘客过期时间，提醒时间可通过参数配置多条提醒（例如提前7天、5天、3天，进行提醒电子票即将过期）。未激活的电子票失效时间为N（精确到秒），即购票时间往后顺延N时间是失效时间，N可通过管理台参数灵活配置。电子票的使用以进站时间为准，在有效期结束时间内进站的，出站不限制有效期，可放行出站。5.2.7自动退款未激活的票卡在规定期限内未激活，并且未开具电子发票，系统自动进行退款操作，系统应按原路进行退款。未激活的电子票失效时间为通过参数任意配置。5.2.8开票管理应支持开具数电发票功能。5.2.9票卡退票应提供票卡退票功能。电子票的退票、退款规则包括但不限于以下内容：（电子票退票、退款规则在设计联络阶段确定，在项目执行期间和质保期内，电子票退卡、退款规则的修改涉及的相关费用，都包含在合同总价中。）应提供票卡退票退款功能，如乘客存在超过N日（N做为参数可通过管理台配置）未激活使用的电子票，系统支持自动原路退还票款。未使用的票卡在业务平台规则允许的范围内，应支持人工触发退款，预留售票管理台人工退款系统，用户端可申请退款，管理后台审核通过后可发起对款流程，操作成功后，系统应按原路进行退款。未激活且未过期的电子票，支持乘客手动申请退票，系统原路退款。如超过N日（N作为参数可通过管理台配置）内未激活的电子票，系统自动原路退款。5.2.10我的卡包提供我的卡包功能入口，应支持在我的卡包中查看相应的票券，包括票券状态、票券详情、核销使用记录。应支持在个人中心查看电子储值票是否开通、电子储值票余额。5.2.11销售订单管理应提供电子票卡销售订单管理功能。支持查询用户购买的所有订单状态、订单详情内容等信息，包括正逆向的所有状态的订单。应提供电子储值票卡的管理功能。支持查询开通用户数、储值金额、剩余金额、储值卡消费记录等。5.2.12对账报表应提供对账报表功能，包括但不限于：应提供电子票购票订单报表（包括购买及退款）、储值卡充值明细报表，以满足业务统计、清结算需要，具体报表需求以运营提报的报表需求模板为准并且系统上线后应满足对账报表格式调整需求。。5.2.13小程序销售端开发对应合肥轨道微信、支付宝、抖音小程序，包括但不限于：电子票卡（电子计次票、电子期限票）售卖，APP专题专栏展示，优惠活动等，可显示已经购买的票卡列表，激活时输入对应APP的手机号码，完成激活后，在APP的我的票卡列表上可以看到该电子票卡。5.3营销管理平台支持个性化推荐，引入用户画像与内容标签管理机制，为不同用户、内容标签等进行营销活动推送。支持按照不同的活动模板配置多个活动，包括但不限于：大转盘、答题和登录送电子票活动等（具体内容以设计联络确定为准）。根据每个活动不同的业务逻辑，支持配置对应活动的页面样式、奖品、活动规则等，配置好的活动支持生成H5链接，投放至合肥轨道APP，用户点击活动H5链接即可参与活动。5.3.1活动管理为运营人员提供基于卡券发行、广告投放的营销活动管理工具，活动平台需提供用户授权管理、活动模板基本信息配置、活动页面图片素材配置、活动任务配置、题库配置、白名单用户配置、活动上下架管理、运营活动数据报表等。增加专属活动板块：在APP内定期推出各类营销活动如优惠购票、积分抽奖、打卡赢奖品等，并通过消息推送等方式及时告知用户，提高用户参与度；APP内设置线下活动报名入口，支持扫码参与、在线预约等功能。具体实现：开发活动报名系统，与地铁站内二维码、宣传海报等相结合。活动类型包括但不限于：任务送券类活动（用户注册送券、用户乘车送券、达标自动送券）、问答类活动（答题活动）、抽奖类活动（大转盘抽奖活动）。奖品支持：电子套票、电子单程票、商户券等。5.3.2奖品管理支持奖品的管理，内容包括产品的创建及维护、产品库存管理、产品上下架、统计分析等。产品兑换情况统计分析。5.3.3活动模板管理1.大转盘活动模板。管理台支持大转盘活动配置，支持自定义活动名称、有效期、活动礼品（不超过6个），活动应支持关联合肥轨道APP电子票，活动在合肥轨道APP中参与，乘客登录合肥轨道APP后可直接参与活动。2.答题活动模板。管理台支持答题活动配置，支持自定义活动名称、有效期、答题奖品，活动应支持关联合肥轨道APP电子票，活动在合肥轨道APP中参与，乘客登录合肥轨道APP后可直接参与活动。3.领取电子票、优惠券活动模板。管理台支持活动配置，支持自定义活动名称、有效期、活动背景页，活动支持关联合肥轨道APP电子票，可限制电子票活动总数量、单日限额、单月限额、单用户限额。4.调查问卷配置模板（具体以设计联络会为准）。5.年度账单配置模板（具体以设计联络会为准）。6.至少5套以上通用活动H5配置模板（具体以设计联络会为准）。5.3.4白名单功能应支持开放活动给白名单用户，白名单支持新增、删除、查看、批量导入、编辑等。5.3.5统计分析应支持开对活动营销效果的统计分析，输出不同类型报表。5.3.6第三方营销活动预留第三方营销活动接口，支持多场景联合营销，如单车权益叠加、停车场优惠、与景区合作推出热门景点推荐、线路规划门票预定、语音讲解、住宿酒店、地道风味。通过吸引商家入打造合肥轨道文旅一体化新形势，极大方便外地游客，带来极佳体验感。5.4权益平台出行权益平台提供配置功能，权益票券可以在“合肥轨道”APP或其他APP发放，乘客可登录合肥地铁官方APP在“我的卡包”中可查询到相关权益，乘车时可以用合肥地铁官方APP的二维码乘坐合肥轨道，行程结束后，根据地铁票价规则优先抵用乘车权益，乘车权益不能覆盖乘客票价的再从个人账户中扣款。5.4.1出行权益产品管理平台提供权益产品管理功能，包括产品的创建及维护、产品库存管理，产品上下架。支持配置包括但不限于以下4种权益产品：计次票券、计时票券、折扣票券、面额票券：计次票券：有效期内，乘客使用乘车权益券可享当次行程免费乘车，按行程次数扣减对应权益券；计时票券：有效期内，多次乘坐地铁（例如：7天11次乘车）；折扣票券：可享受折扣券折扣优惠，按行程次数扣减对应权益券（如7折乘车券）；面额票券：有效期内，可用面额券抵扣对应车资，少补多不退；5.4.2出行权益产品配置出行权益平台提供配置功能，支持权益卡券参数配置:卡券名称、种类、有效期、乘车时段、券面样式、使用说明、最低支付金额、支持支付方式等。行程结束支付乘车费用时，如有以上优惠券时自动使用，同时持有多种优惠票券时，由系统后台控制，优先使用最优惠票券核销（按优惠后金额计算），优惠后须支付金额相等时则选择最近到期的票券核销。系统后台可灵活设置“权益票券”面值/次数，形成权益包，例如，内含11次乘车权益的“畅行卡”或内含5张2元乘车优惠券的10元权益金。权益票券可以在合肥地铁官方APP或其他APP发放，但需要在“合肥轨道”APP进行核销。5.4.3权益票券发放管理支持手机号发券，接口方式或批量上传手机号发券：按照模板导入xlsx文件。支持兑换码导出，批量生成导出兑换码，在合肥地铁官方APP兑换页面输入兑换码领券，每个兑换码限领取一次。支持发券记录查询，输入条件查询发券历史记录。5.4.4分销渠道管理提供对分销渠道进行统一管理，具体包括：（1）可查询分销渠道基本信息；（2）可查询分销渠道出行权益产品订购信息、发放、核销等信息；（3）配置卡券发放的接口接入参数。5.4.5权益分销管理提供分销商管理、产品分销分配、分销配额管理、分销订单管理、分销退货、分销结算等。5.4.6权益核销管理提供用户权益账户管理、权益卡包服务、权益核销交易服务等功能。（1）权益账户管理：为每个用户创建权益账户；（2）用户权益卡包服务：提供APP权益卡包中权益记录查询、权益状态、权益核销记录查询等服务；（3）对权益使用进行核销，提供权益核销交易服务支持。5.4.7交易对账管理交易对账管理功能最终在设计联络阶段确定，在项目执行期间和质保期内，交易对账管理功能优化都包含在合同总价中。需实现的功能包括但不限于以下：提供出行权益交易对账、结算功能。交易字段中增加优惠金额的字段，记录优惠券抵扣券的金额，实现与APP交易对账。实现与数字票务系统对账。由投标人提供具体出行权益交易对账、结算功能等业务规则及方案。实现与APP交易对账。实现与数字票务系统对账。对账方式和对账结果，差异处理等。5.4.8乘车优惠乘车优惠相关规则包括但不限于以下内容：（乘车优惠的具体规则在设计联络阶段确定，在项目执行期间和质保期内，乘车优惠规则的修改涉及的相关费用，都包含在合同总价中。）（一）累计优惠累计规则管理可配置。支持规则的新增、编辑、删除功能。新增时允许按不同的票卡类型进行配置。新增时允许按不同的移动应用APP进行配置。编辑票价分阶梯累计优惠规则。删除票价分阶梯累计优惠规则。实现包括不限于：订单查询、计费管理、统计报表功能。订单查询功能修改，支持查询对累计优惠订单信息查询。修改计费模块，实现分阶梯的累计优惠。新增累计优惠相关报表。支持按照乘客乘坐总金额、乘坐总公里、乘坐次数等统计优惠区段，不同累计区段可单独设置优惠规则。合肥轨道APP展示乘客达标情况、可享受优惠，根据客户达标情况，提供相应乘车优惠。（二）时段优惠时段优惠的规则管理可配置。支持规则的新增、编辑、删除功能。新增时允许按不同的票卡类型进行配置。新增时允许按不同的移动应用APP进行配置。编辑票价分时段优惠规则。删除票价分时段优惠规则。实现包括不限于：计费管理、统计报表等功能。修改计费模块，实现按时段优惠规则。新增按时段优惠相关报表。（三）日期优惠日期优惠的规则管理可配置，支持规则的新增、编辑、删除功能。新增按日期优惠规则，支持分票种、指定日期范围内，可以多个日期范围，设置折扣类型（百分比、固定金额）、优惠周期（天、周、月、活动期内）、优惠次数（1次、不限次数、自定义次数）、生失效时间、超时扣罚是否参与优惠、单边超期是否参与优惠、优惠描述。设置每月的指定日期（每月1号等）、允许配置多条日期优惠。新增时允许按不同的票卡类型进行配置。新增时允许按不同的移动应用APP进行配置。编辑票价分日期优惠规则。删除票价分日期优惠规则。实现包括不限于：计费管理、统计报表等功能。修改计费模块，修改计费模块，实现按日期优惠计费。新增按日期优惠相关报表。（四）站点优惠站点优惠的规则管理可配置，支持规则的新增、编辑、删除功能。新增按站点优惠规则，支持采编多个进站站点、出站站点，需支持按单个进站或出站站点优惠、进站指定站点和出站指定站点优惠。需至少配置以下参数：折扣站点、支持进出站方式（进站、出站、进出站）、折扣开始时间、折扣结束时间、设置折扣类型（百分比、固定金额）、优惠周期（天、周、月、活动期内）、优惠次数（1次、不限次数、自定义次数）、生失效时间、超时扣罚是否参与优惠、单边超期是否参与优惠、优惠描述。允许配置多条站点优惠。新增时允许按不同的票卡类型进行配置。新增时允许按不同的移动应用APP进行配置。编辑票价分站点优惠规则。删除票价分站点优惠规则。实现包括不限于：计费管理、统计报表等功能。修改计费模块，修改计费模块，实现按站点优惠。新增按站点优惠相关报表。（五）线路优惠线路优惠的规则管理可配置，支持规则的新增、编辑、删除功能。新增按线路优惠规则，支持单条线路、多条线路，在指定线路内进出实现相应的优惠。需至少配置以下参数：折扣站点、支持进出线路方式（进、出）、折扣开始时间、折扣结束时间、设置折扣类型（百分比、固定金额）、优惠周期（天、周、月、活动期内）、优惠次数（1次、不限次数、自定义次数）、生失效时间、超时扣罚是否参与优惠、单边超期是否参与优惠、优惠描述。允许配置多条线路优惠。新增时允许按不同的票卡类型进行配置。新增时允许按不同的移动应用APP进行配置。编辑票价分线路优惠规则。删除票价分线路优惠规则。实现包括不限于：计费管理、统计报表等功能。修改计费模块，修改计费模块，实现按线路优惠。新增按线路优惠相关报表。（六）多乘多送多乘多送规则管理可配置。支持规则的新增、编辑、删除功能。新增时允许按不同的票卡类型进行配置。新增时允许按不同的移动应用APP进行配置。编辑票价多乘多送优惠规则。删除票价多乘多送优惠规则。实现包括但不限于：计费管理、统计报表功能。修改计费模块，实现多乘多送优惠。新增多乘多送相关报表。支持按照乘客乘坐总金额、乘坐总公里、乘坐次数，统计达到标准区间，赠送相应乘车次数。建立用户积分功能，根据乘客累计积分，乘客通过积分完成电子票兑换。5.4.9碳积分权益体系建设1.碳积分规则碳积分可通过乘客绿色出行里程来计算，计算规则可配置。规则可进行动态调整积分计算比例或是数量，例如在活动期间积分可以乘以1.5倍或是每次乘车可以直接赠送N积分等。2.碳积分计算乘客每次完成行程后，里程数据会被转化为相应的碳积分值。根据规则完成计算后，系统会将所得的碳积分实时累加到用户的个人碳积分账户中，从而激励用户持续采取低碳出行方式。3.碳积分管理碳积分排行榜。每日24点后，自动更新当前碳积分排行榜，并按月度、季度、年度等时间节点，设置碳积分冠军榜等，并进行可视化展示，强化乘客通过轨道出行获取碳积分的成就感。碳积分查询。乘客可以查询自己的积分总数和明细，以及快到期的积分数量。4.碳积分兑换碳积分按一定兑换规则兑换成迪仔豆，兑换规则可配置。5.4.10合肥轨道会员积分体系建设以迪仔豆为核心，建立具备分等级的迪仔豆的对应及管理体系，例如“金豆、银豆、铜豆、绿豆”，“绿豆”对应绿色出行，其他颜色对应不同类型的营销活动（具体设计以设计联络会为准）。1.迪仔豆兑换可以通过迪仔豆兑换电子乘车券、合肥地铁文创产品、TOD营销商品、地铁商户产品等。为增加用户每天活跃度，可以设置迪仔豆的兑换具体期限。例如，将兑换期限设置为90天，当用户超过90天未使用合肥地铁官方APP进行兑换，兑换权限将自动取消。具体期限可配置。支持用迪仔豆兑换包括但不限于合肥轨道文创及个人广告产品、租赁住房房租优惠券，支持设置兑换规则，后台可设置每月文创及个人广告兑换数量、兑换时间等。2.迪仔豆获取迪仔豆获取渠道多元化，包括但