eebus-docs/项目开发/软件功能/后台系统功能设计.md

title	mdate	mdevice	doc_id	date
后台系统功能设计	2026-03-19 15:26:46	lazy的MacBook Air	2d7921bcb33d47768945bb8f8d9a8e08	2026-03-18 15:27

后台系统设计

1. 账号体系

1.1 用户设计

初始设计五种用户类型，分别为永东注册用户、内部员工、员工家属、代理商、认证机器

• 注册用户 对象：购票、旅游、演唱会等方式引导注册的用户。对应现有的 【永东友】用户 入口：App、小程序 主要权限：浏览、购票、订单、管理个人信息

• 内部员工 对象：永东工作人员，对应不同的功能组（检票、售票）和部门（站务部） 入口：后台系统、检票 App、司机 App 主要权限：根据各部门的职责进行灵活配置，内部员工具有创建员和管理员工家属的权限

• 员工家属 对象：内部员工的家属，需要与员工绑定，由员工账号进行注册和内容变更 入口：内部系统员 主要权限：浏览和申请员工家属福利。

• 代理商 对象：系统认证的代理商。主代理商由系统负责代理商管理的职能账号进行注册，子代理商由主代理商进行注册和管理。 入口：内部系统代理商通道 主要权限：代理商模块、购票模块、管理子代理账号（增删改子代理账号，并限制可创建账号的最大数量）。最终权限需要由永东进行确认

• 认证机器 对象：经过永东认证的设备，如自动售卖机、TVM 机等，需要绑定机器账号、机器码、所属部门等相关信息。系统必须还有机器管理的页面，建议由电脑部负责进行统一管理。 入口：对应的部署程序以及初始运行的账号。 主要权限：用机器运行的程序对应的账号作为权限设置。例如通过创建机器角色来赋予其主要权限。

1.2 权限设计

• 功能：每一个 API 对应一个功能，每个功能必须在后台系统进行登记
• 功能包：由系列的功能组成，绑定的是功能 IDs
• 角色：根据职能来决定其可使用使用的功能包（功能包 IDs）
• 用户：一个用户可以绑定多个角色（角色 IDs）

2. 站点和线路设计

2.1 城市和地区设计

• 区分城市和地区。解决港人对内地城市传统惯性认知。每个站点均需要绑定城市和地区。

内地习惯为【市-区/县-站】，香港习惯为【市/县/区-站】，例如佛山市，港人习惯为佛山、南海、顺德并列。

• 站点绑定。站点必须绑定真实的经纬度坐标，同时可绑定城市和地区两套规则。
• 站点二维码。每个站点均可生成二维码，利用二维码实现扫一扫快捷购票功能。即默用户在扫码时默认使用该站点作为搜票的起点。

2.2 口岸

强化口岸属性，口岸属于线路的必选点，需要跟线路进行强绑定。

快捷购票的需要，在自助机上已经默认设置了购票起点的位置，终点直接指向口岸即可选择班次 口岸需要每个时段对汇入汇出的客流进行统计 通过购票/上车和到达口岸的时间，对班次进行调度优化

2.3 线路

• 线路关联站点（IDs），通过站点的排序来形成线路
• 线路必须绑定口岸 ID，通过【线路-班次】实现对口岸客流统计
• 一条线路只关联一个口岸
• 线路具备【基础价】属性，这个基础价将会在线路的所有班次中应用。线路基础价由站点区间计价得出。

3. 排班设计

3.1 班次

班次包含线路（线路 ID）、时间信息、站点序列（站点 IDs）、站点属性、可售票数、票价策略（策略 IDs）、售票状态等关键信息。

• 线路：线路是班次的基础载体，在常规班车运营中，一条线路会有多个班次生成。
• 班次号：用于标识班次，有固定的名称规则。
• 时间信息：班次的发车时间、区间时间（到站时间和区间时长）、到达时间（到达口岸/终点站时间和时长）
• 站点序列：从线路获得的关联站点集合，具有前后顺序（可以理解为站点数组）。
• 站点属性：同一站点在不同的班次具有独立属性，可单独设置如站点上（可售票）/下车属性、放票数量等。对于班次来说，【班次站点】是【站点】对象的一个映射，每个班次均会对所经过的【站点】做一次拷贝，并重新赋予新的信息，因此会有【班次--站点】对照表。
• 可售票数：在排班时预设的对外供给的票数
• 票价策略：每个班次均从【线路】中获得一个基础票价，用于日常对外定价。票价策略是设定票价上/下浮调整、实施时间、实施时长等的开关。一个班次可以应用多个策略，最终票价则由【后台计价】程序根据策略进行叠加计算。
• 售票状态：班次的售票开关。排班后确定班次信息才可以开放售票。后期可以通过【售票状态】和【可售票数】来分时段放票。

3.2 排班

排班一般分为固定排班和加班两种情况。

• 固定排班：根据运营线路每天固定时间点创建班次。目前永东在香港部分，各线路大概 20 分钟一班车，始发站发车时间相对固定。
• 加班：基于监测数据对某条线路进行加开班次。可以理解为线路的支援班次。一般会根据过去 2-3 天的监测统计结果，决定是否对该班次进行加班。加班车不一定从线路的始发站发出，它将由站务通过统计数据发起，并指定发车站点和发车时间，由车务部服务派发车辆和司机。

偶尔会出现临时加班的情况，一般发生在大型活动或大型节假日，口岸处出现大量乘客，这时才需要当天紧急加班。能否成功加班，视车务部是否能调出司机和车辆而定。

3.3 排班操作

排班操作分为单班排班、单日排班、一键排班三种操作。以下操作均针对【单条线路】的排班设计。

• 单班排班。按照排班的要求，排单个班次，包含上述【班次】中所有的信息。

单班排班可以使用【单班模板】对连续多日的这个班次进行统一应用，实现快捷排班。

• 单日排班。针对每天固定的班次记录，进行整体排班。如周一至周五，该线路每天固定 40 班，可以实现工作日每天覆盖排班。

单日排班可以结合【单日模板】对指定日期（整天）或连续多日进行快捷排班。

3.4 排班模板

• 单班模板。针对线路某个班次设定模板，该模板可以赋予某天或多天的这个班次。
• 单日末班。针对线路某天所有的排班设定的模板，该模板可以生成该线路的全天排班。

3.5 排班模板制作和应用

• 单班模板制作。选择某个班次，将该班次直接转换为单班模板。
• 单日模板制作。选择完成排班的某天，将这天所有的排班记录转为模板。
• 模板管理。独立的排班模板管理工具和界面。
• 模板使用技巧。单班模板可以根据某个时段的某一班车进行应用，如高峰期的某一辆班车。单日模板可以针对工作日、休息日、大型节假日进行创建和设定。使用排班模板可以实现类似【一键排班】功能。

排班模板与线路关联。

3.6 加班操作

• 加班监测。加班监测会在【站务 App】上完成所有的监测和信息流转，后台将会根据统计数据和加班阈值进行加班提醒。
• 快捷加班。在需要加班的班次条目上，增加【加班】操作，直接复制该班次信息，并按【加班命名规则】自动递增班次号，指定上车站点等操作。

加班将会联动站务监测、排班调度、派车等过个业务。系统已经考虑增加站务、车务的信息化应用，加班的复杂过程和前置工作量将会大量缓解。