ICS 35.240.15
CCS L67
团
体 标 准
T/HEBQIA 265—2024
智慧校园一卡通综合管理系统设计规范
Design specification of smart campus card integrated management system
2024 - 06 - 20 发布
2024 - 06 - 20 实施
河北省质量信息协会 发 布
T/HEBQIA 265—2024
目 次
前言 .................................................................................. II
1 范围 ................................................................................. 1
2 规范性引用文件 ....................................................................... 1
3 术语和定义 ........................................................................... 1
4 缩略语 ............................................................................... 1
5 原则 ................................................................................. 2
5.1 智能性 ........................................................................... 2
5.2 安全性 ........................................................................... 2
5.3 可实施性 ......................................................................... 2
5.4 开放性和可扩展性 ................................................................. 2
5.5 可维护性 ......................................................................... 2
6 系统总体架构 ......................................................................... 2
6.1 系统架构设计要求 ................................................................. 2
6.2 系统架构 ......................................................................... 3
6.3 物理部署方式 ..................................................................... 3
7 系统功能要求 ......................................................................... 4
7.1 核心系统 ......................................................................... 4
7.2 应用系统 ......................................................................... 7
7.3 系统运维管理 .................................................................... 12
8 系统性能要求 ........................................................................ 13
8.1 系统容量 ........................................................................ 13
8.2 系统运行处理能力 ................................................................ 13
8.3 系统运行环境 .................................................................... 13
8.4 系统资金清算 .................................................................... 14
8.5 系统特性 ........................................................................ 14
I
T/HEBQIA 265—2024
前 言
本文件按照 GB/T 1.1-2020《标准化工作导则
起草。
第 1 部分：标准化文件的结构和起草规则》的规定
请注意本文件的某些内容可能涉及专利。本文件的发布机构不承担识别专利的责任。
本文件由河北赫烁科技有限公司提出。
本文件由河北省质量信息协会归口。
本文件起草单位：河北赫烁科技有限公司。
本文件主要起草人：高福盛、牛立明、赵更新、崔金龙、袁长青。
II
T/HEBQIA 265—2024
智慧校园一卡通综合管理系统设计规范
1
范围
本文件规定了智慧校园一卡通综合管理系统设计规范的原则、系统总体架构、系统功能要求和系统
性能要求。
本文件适用于智慧校园一卡通综合管理系统设计规范。
2
规范性引用文件
下列文件中的内容通过文中的规范性引用而构成本文件必不可少的条款。其中，注日期的引用文件，
仅该日期对应的版本适用于本文件；不注日期的引用文件，其最新版本（包括所有的修改单）适用于本
文件。
3 GB/T 22239 信息安全技术 网络安全等级保护基本要求
术语和定义
下列术语和定义适用于本文件。
3.1
智慧校园一卡通综合管理系统 smart campus card integrated management system
通过移动互联网技术，以关联系统、核心系统、应用系统、终端和介质为架构，涵盖消费、圈存、
缴费、水控、门禁、请假、宿舍、门锁、报修和公众号管理等功能，实现学校对教职工和学生全方位管
理的系统。
注：本文件以下简称系统。
4
缩略语
下列缩略语适用于本文件。
4G——第四代移动通信技术（The 4th Generation Mobile Communication Technology）
5G——第五代移动通信技术（The 5th Generation Mobile Communication Technology）
AIX——AIX操作系统（Advanced Interactive eXecutive）
B/S——浏览器/服务器模式（Browser/Server）
CAN——控制器局域网总线（Controller Area Network）
CPU——中央处理器（Central Processing Unit）
J2EE——Java 2平台企业版（Java 2 Platform Enterprise Edition）
HTTP——超文本传输协议（Hyper Text Transfer Protocol）
IC——集成电路（Integrated Circuit）
ID——身份标识号（Identity Document）
IP——网际互连协议（Internet Protocol）
M1——狭义货币（Narrow Money）
MAC——消息鉴别码（Message Authentication Code）
1
T/HEBQIA 265—2024
MD5——信息-摘要算法（Message-digest Algorithm 5）
MQ——消息队列（Message Queue）
NFC——近场通信（Near Field Communication）
PC——个人计算机（Personal Computer）
POS——销售终端（Point of Sale）
RAID——分布式奇偶校验的独立磁盘结构（Redundant Array of Independent Disks）
Redis——远程字典服务（Remote Dictionary Server）
RJ45——注册插孔（Registered Jack 45）
RS232——异步传输标准接口（Recommended Standard 232）
SAAS——软件运营服务（Software as a Service）
TCP——传输控制协议（Transmission Control Protocol）
TCP/IP——传输控制协议/因特网互联协议（Transmission Control Protocol/Internet Protocol）
URL——统一资源定位系统（Uniform Resource Locator）
WEB——全球广域网（World Wide Web）
5 原则
5.1 智能性
5.1.1 系统通讯应依托内部网，采用专网，应用有线和无线相结合的通讯方式，实现卡、二维码、人
脸识别在身份认证、消费、移动互联中的三大基本功能。
5.1.2
系统的建设应采用智能卡技术、互联网技术、软件技术和安全技术，消除地域的限制。
5.2
安全性
5.2.1
系统应符合 GB/T 22239 规定的网络安全等级共性化保护要求。
5.2.2
系统的建设应保证学校、商户、用户的资金安全。
5.3
可实施性
系统的建设应适应不断变化的学校的规模和管理模式，与其他系统进行良好对接，实现一卡通用和
资源共享。
5.4
开放性和可扩展性
系统的建设应采用“1个核心系统+N个应用子系统”的模式。核心系统建立后，所有公共信息应一
次建立，向所有子系统开放，其他系统不用重复建立。
5.5
可维护性
系统的建设应考虑系统维护的简便、快捷和成本，特别是一致性管理和维护。
6 系统总体架构
6.1 系统架构设计要求
6.1.1 系统应采用 SAAS 架构设计，支持云平台和单客户两种部署模式，支持多客户、多级权限体系
管理。
2
T/HEBQIA 265—2024
6.1.2
系统应包括核心系统和应用系统。
6.1.3
系统应支持对称、非对称两种密钥管理体系，保证系统中卡片、通讯、数据存储等环节的安全。
6.1.4
系统应支持在线和脱机两种交易模式，以在线交易为主，系统可手动或自动切换到脱机模式。
6.1.5
系统应支持 M1、CPU、金融 IC 卡、NFC 手机、二维码、人脸等多种支付介质。
6.1.6
系统应采取复式会计记账方式，会计科目可自定义，与财务系统实现无缝对接，资产负债表应
清晰地反映系统财务状况。
6.2
系统架构
智慧校园一卡通综合管理系统架构可参考图1。
图 1
智慧校园一卡通综合管理系统架构
6.3
物理部署方式
3
T/HEBQIA 265—2024
6.3.1
在校园网中，资金数据传输应采用独立专网进行，普通数据传输应采用虚拟专网进行，保证一
卡通资金数据安全。
6.3.2 中心机房与楼栋之间，应采取光纤布线方式。
6.3.3 所有系统接入核心系统，应经过防火墙隔离。
6.3.4 系统前置服务器与银行系统之间应通过专线连接，保证与银行系统对接安全。
6.3.5 应部署在集中场合的消费终端，采用 CAN 专用网络进行数据传输。
7 系统功能要求
7.1 核心系统
7.1.1 密钥管理
应实现系统内需要的所有证书/密钥的注入、生成、导出、备份、恢复、更新和销毁。
7.1.2 证卡管理
7.1.2.1 应具有管理客户信息的功能，同一主卡可以绑定多张副卡，可查看绑定的副卡。
7.1.2.2 应支持配置管理中可对人员信息进行脱敏设置，至少包括人员编号、姓名、证件号码、银行
卡号、手机号码、账户地址、邮箱等字段的脱敏设置。
7.1.2.3
应具有在线更新卡功能，可更新个人编号（即学号），更新卡类型，更新消费次限额，更新
消费次限额、日限额，以及限额更新的验证。
7.1.2.4
应具有客户登录密码、消费密码重置功能。
7.1.2.5
应具有对校园卡用户身份、人员类型、账户信息和不同介质状态等卡务管理数据的综合查询
功能。
7.1.2.6
应支持纯 B/S 方式交互，包括卡片数据读写操作等，保障系统管理及维护的便捷性和访问的
时效性。
7.1.2.7
卡务管理操作可以根据对校园卡账户的多种条件组合查询结果批量执行。
7.1.2.8
应支持师生办理个人业务时，人脸识别自动调取个人信息进行人工或自助业务办理。
7.1.2.9
应具有编辑客户信息的功能，可编辑卡类型、编辑次消费限额、编辑日消费限额等信息。
7.1.2.10
应具有批量发卡的功能，密钥、发卡和打印可批量操作，密钥灌装、发卡及证卡打印操作一
体化，可以同时对不少于两个部门的、多人进行操作。
7.1.2.11
应具有自动发卡功能，系统选择数据信息，并下发制卡指令，由发卡机自动发卡。
7.1.2.12
应具有批量挂失、销户的功能。
7.1.2.13
应具有消费失效期设置功能。
7.1.2.14
应具有人脸比对功能，上传人脸照片，用于和手机、消费机等终端设备端取得的人脸照片时
进行基准比对。
7.1.3 运营管理
7.1.3.1 应具有扩展钱包的功能，支持 5 个以上在线账户、5 个以上脱机预授权钱包。
7.1.3.2 应具有查看“系统允许脱机金额”信息的功能。
7.1.3.3 应具有设置支付渠道的开启、停用的功能，可编制相应支付渠道参数配置值。
7.1.3.4 应具有生成二维码的功能。
7.1.3.5 应具有设置“电子账户参数”参数值的功能。
4
T/HEBQIA 265—2024
7.1.3.6
应具有商户综合管理功能，可提供商户账户开立与撤销、支付终端配置、账户管理、口令重
置、交易查询、结算对账、生成导出静态收款二维码等。
7.1.3.7
水控模式可同时支持用户刷卡、扫码（用水码、三方支付码、校园码）或无卡输密码方式用
水。
7.1.3.8
应具有收费设置功能，可设置每生每天取水额度，超过设置额度后按照正常水价收费。
7.1.3.9
应具有设置消费限额功能，支持用户灵活设置消费限额和消费时长，防止消费结束后遗忘取
卡造成损失。
7.1.3.10 应支持刷卡和账号密码扣费方式。
7.1.3.11 应支持预约模式，学生通过手机 APP 进行浴室预约，只有预约成功才可进行淋浴消费。
7.1.4 资金清算
7.1.4.1 应支持明细查询，使用微信、支付宝、银联等第三方原生付款码支付后，交易明细表中可体
现用户校园身份信息的个人编号、姓名、部门。
7.1.4.2
消费机脱机时，可形成支付二维码，包括金额、终端编号、时间等信息，用户可使用手机扫
码支付。
7.1.4.3
商户报表可以按照查询日期，查询每天商户交易明细汇总数据，包括子商户报表，了解商户
每日收益。
7.1.4.4 应支持多收款账号、多商户管理。
7.1.5 数据分析
数据分析应基于校园卡数据进行深度挖掘分析，提供多个维度为卡中心、后勤、学生处、财务处部
门服务。
7.1.6
数据交换
数据交换应部署在系统的前置服务器，负责与校内不同部门、不同通信方式应用的接入。
7.1.7
集中监控
集中监控应为终端设备提供统一的监视和控制系统，并为采集服务提供人机交互界面。
7.1.8 聚合支付
7.1.8.1 应具有报表功能，一张报表中可体现聚合支付中包含的所有的支付方式的相应报表。
7.1.8.2 支持当前主流的微服务及 J2EE 技术架构体系模式。
7.1.8.3 支持国密 SM31)、SM42)等加密签名算法。
7.1.8.4 应具有通过“聚合支付-明细报表”查看支付明细的功能，支持手机终端通过公众号相应功能
查看消费明细。
7.1.8.5
应支持脱机交易的风险控制管理，支持系统级、终端级、个人级三级控制。
7.1.8.6
应具有副卡管理功能，一个用户可拥有一张主卡，同时可以领取多张副卡。
7.1.8.7
应支持学号、卡类别、密码、消费限额等信息后台更新，消费终端自动登卡处理。
7.1.8.8
应支持根据设置不同的功能业务流程，记录业务处理过程中的状态，便于异常发生时流程的
断点续传和日志记录。
1)
SM3 是中华人民共和国政府采用的一种密码散列函数标准。
2)
SM4 是中华人民共和国政府采用的一种分组密码标准。
5
T/HEBQIA 265—2024
7.1.8.9
系统软件应与批量发卡机硬件配合，完成用户卡的批量制作，中间过程无需人为干预，信息
准确，速度快。
7.1.8.10
应具有自动化业务处理的功能。
7.1.8.11
应支持银联标准二维码、微信及支付宝等原生付款码直接消费支付，具有实名认证功能。
7.1.8.12
应支持统一结算、对账系统，可在一张报表中统计各种支付渠道的交易、对账情况；支持不
同校区分别设置三方支付资金归集的银行账户。
7.1.8.13 可为不同的餐饮承包商或终端设备生成固定收款码。
7.1.9 虚拟卡管理
7.1.9.1 虚拟卡管理应实现虚拟卡电子账户生成、虚拟卡充值、虚拟卡支付、虚拟卡身份识别，以及
相关的数据报表和查询等功能。
7.1.10 能力开放
7.1.10.1 应给第三方系统开放核心接口权限，支持为第三方系统开放入口、用户、数据等资源，分配
系统中提供的各大类接口，构建多方协作、资源共同分享的服务系统。
7.1.10.2
应具有系统管理能力，包括接入者账号权限、配置不同加密方式（支持国密 SM4）、配置
签名方式（支持 MD5 和国密算法 SM3）、IP 白名单地址（支持多 IP 绑定）。
7.1.10.3
开发者（合作者）可在系统查看系统对外开放申请的服务接口及接口描述、申请调用后的审
核状态。经审核后，开发者（合作者）可查看已申请服务接口信息，包含服务接口简介、接入示例以及
相关实例。
7.1.10.4
应支持管理员在管理页面直接为开发者（合作者）分配接口及权限授权/授禁，可视化操作、
所见即所得。
7.1.10.5
应支持合作者和管理者两种视图模式，管理者视图首页可展示已注册合作者、合作者调用数
据（今日使用最多接口、今日最活跃接口、接口耗时等）等。
7.1.10.6
应具有开放系统角色管理服务入口的功能，包含角色列表信息查询、添加角色、角色编辑、
角色删除等角色管理服务。
7.1.10.7
应具有开放系统操作员管理服务入口，包含操作员列表查询、编辑操作员身份信息、操作员
密码、操作员角色、操作员状态、添加操作员等服务。
7.1.10.8
应支持管理开放系统内封装的接口管理服务，包含查询接口列表、添加接口、接口编辑服务，
为了便于系统管理员接口管理维护，列表应显示接口名称、接口简介、接口 URL、接口入参示例等信
息。
7.1.10.9
应支持开放系统接口分类管理服务入口，为三方系统对接服务，以满足对接需要，包含查询
接口分类列表，列表可显示接口分类名称、接口分类编码、启用状态等信息，支持添加接口分类、编辑
接口分类服务。
7.1.10.10
应具有开放系统接入系统管理服务入口的功能，包含查询接入者信息，可显示接入者账号、
名称、邮箱、Client ID、Secret ID、签名方式、签名密钥、加密方式、IP 地址、前置接入等信息，便于
接入系统管理，同时可编辑接入系统、添加接入系统等，可编辑接入者邮箱、Token 有效期3)、选择签
名方式、选择加密方式、IP 地址等综合服务管理。
7.1.10.11
应具有为三方接入系统分配接口功能，包含查询接口、添加接口分配，为合作者提供接口
分配，让合作者具有调用接口能力，支持从接口菜单中选择对应的联动接口，完成接口分配。
3)
Token 的有效期可以根据不同的应用场景和安全需求而有所不同。
6
T/HEBQIA 265—2024
7.1.10.12
应支持接口克隆，管理者使用原有服务接口快速创建同类接口，可控制同样业务接口入参
与出参的字段不同。
7.1.11 人脸识别
7.1.11.1 应支持同时接入多种人脸识别算法，支持按算法设置不同的参数组。
7.1.11.2 应支持接入多种类型的人脸识别终端。
7.1.11.3 应支持多介质认证管理，可对用户和应用统一认证授权。所有介质关联同一账户，实现统一
管理、权限管控等内容，实现卡、码、脸、密码等多种介质身份统一管理。
7.1.11.4
应支持从三方系统同步用户照片，支持 WEB 或 HTML5 应用自助上传照片，用户照片采集
后根据不同算法提取人脸特征，支持活体检测。
7.1.11.5
为保证人脸照片的安全性，导出的人脸图片可添加水印。
7.1.11.6
应支持照片批量上传、批量审核，支持人员黑名单管理和生物特征值管理。
7.1.11.7
对新生的入学资格及照片应支持联网二次审查支持以人名搜图、以图搜人等查询功能，可上
传人脸照片由系统自动比对搜索，筛选并显示出与其相似度较高的记录照片，以相似度排序展示并关联
通行记录。
7.1.11.8
应支持用户照片采集后根据不同算法提取人脸特征，可根据业务系统设置自动更新下发人员
特征，支持向各业务系统推送人脸识别记录，支持活体检测，可有效防御纸质照片、电子照片、视频、
面具等作弊方式。
7.1.11.9
应具有不合格人脸库稽核的功能，可汇总展示当前系统内对应算法下的不合格人脸库，稽核
维度包括：人脸不全、多个人脸、相似人脸照、人脸模糊、亮度不符、人脸照检测失败、提取特征码失
败等。
可展示全校师生的基本信息及其所有使用中的介质，可打开用户详情展示用户及每个介质的详细信息，
包括用户人脸照、虚拟卡、介质变更日志记录（包括对所有师生的人脸照、二维码、实体卡的所有的操
作）。
7.1.12
移动服务管理
移动服务管理功能模块包括用户管理、角色管理、公众号功能管理、公众号角色类型授权管理、微
信消息模板管理、手机号白名单授权管理、学生管理、充值管理、通告管理、白名单/黑名单访问管理、
数据分析服务、移动商户管理、移动用户管理等。
7.2 应用系统
7.2.1 消费管理
7.2.1.1 应支持人员信息脱敏、消费数据统计查询、终端信息查询、终端内已下发的有效人脸信息数
量查询、交易记录上传记录查询。
7.2.1.2
应具有消费模式（码、卡、脸）、餐别定额设置。
7.2.1.3
应支持本地退款（可选择刷卡、扫码、人脸识别等退款认证方式）。
7.2.1.4
应支持设备音量调节、屏幕亮度调节、商户静态码展示。
7.2.1.5
应具有校园实体卡刷卡支付、校园二维码扫码支付、校内人脸支付等支付功能。
7.2.1.6
消费机正常工况下应采取联机工作模式，交易数据实时上传至系统；网络故障时支持脱机工
作模式，恢复联机后交易数据及时上传至系统。
7.2.1.7
应支持可选以太网、4G/5G、WIFI 等多种通信方式，支持以太网和 4G/5G、WIFI 自动切换模
式，优先使用以太网，检测到以太网连接中断即自动切换至 4G/5G、WIFI 连接。
7
T/HEBQIA 265—2024
7.2.1.8
应支持限制单个支付终端的可消费人员身份类型，可设置单个校园卡账户的单次、单日支付
额度限制，支持按额度进行小额免密支付、验证交易密码支付和禁止支付。
7.2.1.9 应支持数字人民币、银联码、各个银行码、微信、支付宝原生码聚合支付。
7.2.1.10 应具有后备电池续航功能，标称值如下：
a) 电池容量：5500 mAh；
b) 续航时间：3 h～5 h。
7.2.1.11 通过 2 个 RJ45、1 个 RS232 和 2 个 USB2.0 接口，可进行通信。
7.2.1.12 设备通讯方式支持 TCP/IP 有线通讯，支持蓝牙、WiFi、4G、5G 等无线通讯。
7.2.2 圈存管理
7.2.2.1 应具有银行卡的注册、签约、解约、换卡等功能，并支持对账、转账查询等。
7.2.2.2 应支持网银、微信、支付宝、云闪付转款功能，支持脱机钱包转款、圈存补领款功能。
7.2.2.3 应具有自助圈存、挂失、改密、查询等功能。
7.2.2.4 应具有自助转账、自动转账、签约解约、对账、网银转账提供通信转发的功能。
7.2.3 缴费管理
7.2.3.1 应支持管理员审批，支持账单缴费和自助缴费两种模式。
7.2.3.2 应支持大型数据库、支持 Linux4)或 Unix5)、WINDOWS、AIX6)等操作系统。
7.2.3.3 应支持跨系统的部署。同时可兼容校内现有用户体系（如统一身份认证系统）且提供独立的
用户体系（校外用户）的管理。
7.2.3.4
应支持退款管理，用户发起退款申请流程，管理员审批后生效，支持原路退款。
7.2.3.5
应具有票据管理的功能，可设置开票权限，收费部门和财务部门可根据操作权限，打印相应
收费项目的票据，支持不同格式的票据，可提供票据格式设计。
7.2.3.6
应支持导入缴费名单，账单推送至用户手机端，包括网费充值、电费充值、自助缴费、图书
馆欠缴费、党费、校友捐赠等生活缴费服务。
7.2.3.7
应支持包括查询缴费收费模型、名单导入类模型、通用类模型、报名费类模型、会议费类模
型、场景收费类模型。
7.2.3.8 应支持多种支付渠道，可选网银、微信、支付宝、云闪付、电子校园卡等方式缴费。
7.2.4 水控管理
7.2.4.1 应支持 DC 12 V～24 V 宽电压输入方式。
7.2.4.2 应支持刷卡消费、扫码消费、按键验证联机消费。
7.2.4.3 应支持防水键盘，包括数字键+功能键（标称按键寿命 80 万次～100 万次）。
7.2.4.4 应支持分辨率 128×64 的 2 英寸液晶屏，可显示二维码等。
7.2.4.5 应支持在线升级。
7.2.4.6 应支持 CAN 或 4G 通信方式。
7.2.4.7 应支持洗澡预约管理。
7.2.5 门禁管理
4) Linux，Linux Is Not UniX 的缩写，一般指 GNU/Linux，是一套使用和自由传播的类 Unix 操作系统，是一
个遵循 POSIX 的多用户、多任务、支持多线程和多 CPU 的操作系统。
5)
UNIX 系统是一个分时系统。
6)
AIX 是 IBM 基于 AT&T Unix System V 开发的一套类 UNIX 操作系统，运行在 IBM 专有的 Power 系列芯片设计
的小型机硬件系统之上。
8
T/HEBQIA 265—2024
7.2.5.1
应支持部门授权、组织机构授权、批量授权、导入授权等功能。
7.2.5.2
应具有授权管理的功能，系统自动生成授权名单给相应门禁。
7.2.5.3
应支持多种终端集成管理，集中授权、统一管控，包括门禁终端、通道闸机等。
7.2.5.4
应支持实名认证绑定下的电子校园卡二维码实现门禁、通道、考勤等识别功能。
7.2.5.5
应支持常开模式、首卡开门、多卡开门、多门互锁、反潜回等。
7.2.5.6
以下情况应具有报警功能：
a)
对于没有授权的卡、人脸、二维码，连续 5 次非法识别，系统记录日志并报警；
b)
系统对强制开门的情况进行记录并报警；
c)
控制器电压低于正常值的 85%，系统进行记录并报警。
7.2.5.7
应具有实时监控的功能，支持实时监控通行人员信息，包括姓名、学号、照片等。
7.2.5.8
应具有导入预约访客信息的功能，当被访人完成审批操作后，该访客将会接收到预约提醒推
送，系统提供 PC 端和移动端预约功能。访客审批之后，系统可将访客权限自动下发至人脸识别平板和
手持机中，支持在人脸通道上刷卡、刷脸、扫码（访客码）或手持机上刷卡、刷脸、扫码（访客码）刷
身份证（手持机）进行身份核验。
7.2.6 请假管理
7.2.6.1 应具有请假信息管理的功能，使用手机 APP 请假通过审批后，同步信息给所有门禁。
7.2.6.2 应具有请假查询功能，学生获准离校后，消息直接反馈班主任及学生家长，同时校内可通过
电子班牌或手机 APP 进行展示与查看，并关联宿舍归寝结果统计；发送消息内容包括请假时长、离校
时间、请假事由、审批人及其联系方式。
7.2.6.3
应具有信息推送的功能，请假到期以后，对于没有按时返校的学生，系统自动将请假未归信
息推送给辅导员（家长），并提醒学生返校。
7.2.7 宿舍管理
7.2.7.1 应具有管理值班员的功能，可查看、添加、删除值班员信息和排班等。
7.2.7.2 应具有添加房间类型、房间类型管理、 添加楼房地理位置、楼房地理位置管理、楼房登记、
楼房信息、新增楼房单元、楼房单元管理、添加房间信息、房间基本信息、房态图查看、添加床位信息、
房间床位信息、办理入住、入住信息、住宿信息导入、调房管理、迁出信息等功能。
7.2.7.3
应具有入住管理功能，可登记入住学生详细信息，以及支持批量导入新生入住信息操作。
7.2.7.4
应具有调宿管理功能，可对调宿学生调宿前与调宿后信息进行管理。
7.2.7.5
应具有退宿管理的功能，可对退宿学生信息与退宿记录进行统一管理。
7.2.7.6
应具有迁出管理的功能，可对迁出学生信息与迁出记录进行统一管理。
7.2.7.7
应支持对学校的基础信息管理，包括但不限于校历信息、组织机构信息、专业信息、班级信
息、教职工信息、宿舍资源信息、学生信息。
7.2.7.8
应支持班/年级管理，对学生班/年级信息进行统一管理。
7.2.7.9
应支持建立具备层级关系的房间住宿资源，可建立包括但不限于以下层级：校区、园区、楼
栋、单元、层、房间、床位。
7.2.7.10
应支持为楼栋设置住宿学生性别；支持设置房间用途、类型、床位数、标签、面积；支持设
置房间示意图；支持零星和批量设置床位标签；支持相关数据的导出。
7.2.7.11
应支持按照楼栋权限（包括但不限于系统管理员、校区管理员、园区管理员、楼栋管理员、
楼层管理员）和院系权限（包括但不限于学院书记、学工处、辅导员）灵活配置相应的管理角色。
7.2.7.12
应支持设置公寓预分方案，方案包括但不限于：按学年、是否允许学院二次预分、是否允许
学生自选宿舍、启用日期、资源回收日期，以及预分的学生范围。
9
T/HEBQIA 265—2024
7.2.7.13
应支持假期留校，可设定假期留校计划，设定假期留校申请或登记的起止时间。
7.2.7.14
应支持按照校区、园区、楼栋等条件进行查询，展示校区、园区的区域概况，包括但不限于：
园区数、楼栋数、房间数、床位总数、空床位数、入住人数。
7.2.7.15
应支持入住、调宿、退缩功能，包括但不限于床位对调、房间对调、批量调宿、毕业生批量
退宿。
7.2.7.16
应支持非学生人员的临时住宿安排。
7.2.7.17
应支持卫生检查和纪律检查，可分别设置卫生和纪律检查项，可设置检查频次。
7.2.7.18
应支持学生预警提醒。可设置预警等级和预警规则，根据学生每日考勤情况和在寝/离寝时
长自动生成预警名单，并推送给管理员。
7.2.7.19
应支持统计预警学生数量，对晚归、夜不归宿等异常行为进行展示。
7.2.7.20
应支持混寝房间统计。对于同一个宿舍住的不同学院的学生，支持统计混合宿舍中的各个学