14 KiB
助教撤销记录（GetAbolitionAssistant）
自动生成于 2026-02-13 | 数据来源：本地 JSON 样本
基本信息
| 属性 | 值 |
|---|---|
| 接口路径 | AssistantPerformance/GetAbolitionAssistant |
| 完整 URL | https://pc.ficoo.vip/apiprod/admin/v1/AssistantPerformance/GetAbolitionAssistant |
| 请求方法 | POST |
| Content-Type | application/json |
| 鉴权方式 | Bearer Token（Authorization 头） |
| ODS 对应表 | assistant_cancellation_records |
| 分页方式 | page + limit（最大 100） |
| 时间范围 | 需要（startTime / endTime） |
请求参数
| 参数名 | 类型 | 示例值 | 说明 |
|---|---|---|---|
startTime |
string | "2026-02-01 08:00:00" |
查询起始时间 |
endTime |
string | "2026-02-13 08:00:00" |
查询结束时间 |
siteId |
int | 2790685415443269 |
门店 ID |
page |
int | 1 |
页码（从 1 开始） |
limit |
int | 100 |
每页条数（最大 100） |
响应字段（共 13 个）
| # | 字段名 | 类型 | 示例值 |
|---|---|---|---|
| 1 | siteProfile |
object | {'id': 2790685415443269, 'org_id': 2790684179467077, 'sho... |
| 2 | createTime |
string | '2025-11-09 19:23:29' |
| 3 | id |
int | 2957675849518789 |
| 4 | siteId |
int | 2790685415443269 |
| 5 | tableAreaId |
int | 2791963816579205 |
| 6 | tableId |
int | 2793016660660357 |
| 7 | tableArea |
string | 'C区' |
| 8 | tableName |
string | 'C1' |
| 9 | assistantOn |
string | '27' |
| 10 | assistantName |
string | '泡芙' |
| 11 | pdChargeMinutes |
int | 214 |
| 12 | assistantAbolishAmount |
float | 5.83 |
| 13 | trashReason |
string | '' |
详细字段分析
以下内容迁移自旧版
assistant_cancellation_records-Analysis.md，包含字段的业务含义、枚举值、跨表关联等详细说明。
- 门店相关字段 1.1 siteProfile
类型：对象（Object）
含义：门店信息快照。
结构：包含以下子字段（26 个左右）：
id：门店 ID（与其他 JSON 中的 site_id 一致）。
org_id：组织 ID（总部/品牌组织）。
shop_name：店名，如“朗朗桌球”。
avatar：门店头像图片 URL。
business_tel：门店电话。
full_address：详细地址。
address：简化地址描述。
longitude / latitude：经纬度。
tenant_site_region_id：区域行政编码。
tenant_id：租户 ID（品牌商户 ID）。
auto_light：是否自动控灯（0/1 枚举）。
attendance_distance：考勤打卡范围。
wifi_name / wifi_password：WiFi 账号和密码。
customer_service_qrcode / customer_service_wechat：客服二维码、微信号。
fixed_pay_qrCode：固定收款码。
prod_env：环境标记（测试/生产等）。
light_status / light_type / light_token：灯控相关配置。
site_type：门店类型枚举。
site_label：门店标签（如“A”）。
attendance_enabled：是否启用考勤（0/1）。
shop_status：门店状态（1=营业等）。
特点：
与其他 JSON 中的 siteProfile 完全同构，是冗余的门店信息快照。
真正的主键是 siteProfile.id，且与同记录的 siteId 一致。
1.2 siteId
类型：整数（long）
观测：所有记录均为同一值 2790685415443269。
含义：门店 ID，即该废除记录所在门店。
关联：
与 siteProfile.id 一致。
与其他 JSON 中所有 site_id 字段相同（同一门店的数据）。
- 台桌维度字段
这几个字段描述废除发生在哪张桌、哪个区域。
2.1 tableId
类型：整数（long）
含义：球台/桌子的 ID。
关联：
对应 “台桌列表.json” 中的 id 字段。
用于定位具体哪一张台桌上发生了助教废除。
2.2 tableName
类型：字符串（string）
示例值：
"C1", "C2", "B9", "VIP1", "A4", "666", "董事办", "补时长5", "Ｍ1" 等。
含义：台桌名称/编号，供人阅读。
关系：
与台桌列表中的 table_name 或 table_no 文本一致。
作为冗余字段存在，即使不联表也能看出是哪个桌。
2.3 tableAreaId
类型：整数（long）
示例：2791963816579205 等。
含义：台桌所在区域 ID。
关联：
应对应“区域配置表”的主键（本次导出未包含该表）。
与其他 JSON 中出现的 tableAreaId（比如台费流水、助教流水里的区域字段）是一致的。
2.4 tableArea
类型：字符串（string）
示例值：
"C区", "B区", "A区", "VIP包厢", "K包", "补时长", "666"。
含义：台桌所属区域名称。
说明：
用于展示和报表分区。
与 tableAreaId 一起从“区域维表”中可以查出区域层级信息（本次数据未导出该表）。
- 助教维度字段
反映是哪一个助教被废除。
3.1 assistantOn
类型：字符串（string）
观测值（本次 15 条记录中）：
'2', '4', '9', '16', '23', '27', '52', '15', '99'
含义：助教编号（工号/序号）。
说明：
虽然是字符串，但内容上是纯数字，实际是编号，不是业务金额。
与 助教流水.json 中的 assistantNo 字段是一致的。
与“助教账号1/2.json” 中的 assistant_no 字段相同，用于识别哪位助教。
枚举性质：
在当前门店范围内，assistantOn 实际上是枚举集合（有限个编号）。
具体编号-姓名的映射关系在“助教账号”表中定义，不在本文件中。
3.2 assistantName
类型：字符串（string）
观测值（本次 15 条中）：
'佳怡'、'璇子'、'周周'、'球球'、'泡芙'、'婉婉'、'小柔'、'七七'、'Amy'
含义：助教姓名/对外展示名称。
关系：
与“助教账号”档案中的 real_name / nickname 对应。
与 助教流水.json 里的 assistantName 字段一致。
注意：
这是被废除的那位助教，不是顾客姓名。
- 时间与时长字段 4.1 createTime
类型：字符串（string），格式 YYYY-MM-DD HH:MM:SS
示例："2025-11-09 19:23:29"
含义：这条“助教废除记录”被创建的时间，即系统正式记录“废除”操作的时刻。
与其他时间字段关系：
在 助教流水.json 里有 create_time / ledger_start_time / ledger_end_time 等，本字段通常会落在这些时间点之后，表示在某次服务计时过程后发生了废除操作。
数据特征：
所有记录都有非空时间，精确到秒。
4.2 pdChargeMinutes
类型：整数（int）
示例值：214, 10800, 3602, 3600, 2379, 14400, 10605, 10608, 10611, 0 等。
含义（结构层面）：
“已发生的计费时长（分钟）”，即这次助教服务在被废除前已经累计了多少分钟。
特点：
单位是“分钟”，不是秒。
绝大部分是较大的整数（如 10800 分钟这样的数字，显然系统里有异常/默认值，具体业务含义要结合上下文看，这里只从字段命名和类型说明）。
也有 0 的情况，表示发生废除时尚未有有效计费时间产生（例如刚排钟就撤销）。
与其他字段的关系（结构层面推断，不做业务结论）：
这类字段很可能用于后续计算“应退时长”或“扣费时长”。
对应 助教流水 里关于 real_use_seconds、income_seconds 的记录，可用来判断“废除时已经消耗了多少时间”。
- 金额字段 5.1 assistantAbolishAmount
类型：浮点数（float）
示例值：
5.83, 570.0, 108.06, 190.0, 71.37, 392.0, 465.44, 318.24, 318.33, 以及 0.0。
含义（结构层面）：
与“助教废除”关联的金额字段。字面上是“助教废除金额”。
可以理解为本次废除操作对应的一笔金额数值（是扣除、退还、补差，由业务规则决定，这里不做盈利/收益分析）。
特点：
为浮点数，单位为元。
存在 0 值，表示这条废除记录没有产生额外金额变动（纯记录操作）。
可能的用途（从字段角色角度，而不是结论）：
后续在账务模块中，可以用 assistantAbolishAmount 这类字段与其他表（如退款记录、余额变更记录）进行金额对账和逻辑匹配。
- 废除原因字段 6.1 trashReason
类型：字符串（string）
当前数据观测：所有 15 条记录都是空字符串 ""。
含义：
用于记录“废除原因”的文本描述，例如“顾客临时有事取消”“录入错误”“更换助教”等。
特点：
可为空字符串，说明系统允许不填原因。
从结构上看，这是一个自由文本字段，不是枚举，不会做严格约束。
与其他字段的关系：
当配合 is_trash（在 助教流水.json 中）使用时，trashReason 可以为那条流水提供“为什么被废除”的说明。
本表专门记录“废除事件”的列表，因此 trashReason 是这张表记录的重要附加信息。
三、字段之间的结构关系与外部关联
虽然本文件字段不多，但从字段设计可以看出它在整个系统中的位置。这里只从“字段结构”和“关联键”的角度说明，不做业务/盈利分析。
- 与门店表 / 全局维度的关系
siteId 与 siteProfile.id 一致，且与其他 JSON 中的 site_id 一致。
说明：这是典型的“门店维度外键 + 冗余快照”设计：
siteId 作为外键；
siteProfile 作为冗余快照，方便直接展示店名、地址等。
- 与台桌列表（台桌列表.json）的关系
对应关系：
tableId ↔ 台桌列表中的 id
tableName ↔ 台桌列表中的 table_name / table_no
tableAreaId ↔ 台桌列表中的 area_id（通过区域表可以进一步找到区域名称）
tableArea ↔ 台桌列表中的 area_name
结论（结构层面）：
助教废除.json 中关于桌台的四个字段，是对“台桌维度”信息的引用 + 冗余快照。
当用 tableId 去联查台桌列表时，可以获取更多静态信息（如台费设置、是否可预约等），本文件只保留了最基础的桌号和区域。
- 与助教档案 / 助教流水的关系
对助教的标识字段：
assistantOn ↔ 助教流水中的 assistantNo ↔ 助教账号中的 assistant_no
assistantName ↔ 助教流水中的 assistantName ↔ 助教账号中的姓名字段
结构上的含义：
助教废除.json 可以看作是“助教服务流水”的一个特殊子集：只记录被废除的部分。
在 助教流水.json 中，存在字段 is_trash、trash_reason 等，它们从主流水视角记录“此条流水已经被废除”这一状态。
在 助教废除.json 中，則以“废除事件”为主视角，列出每一次废除操作的明细（在哪张桌、哪个助教、多少分钟、金额多少）。
需要注意的结构事实：
助教废除.json 里 没有 订单号类字段（例如 order_trade_no、order_assistant_id），因此如果要从“废除事件”反查到具体哪一条助教流水，目前只能通过组合条件关联，例如：
相同门店 siteId；
相同助教 assistantOn + assistantName；
相同台桌 tableId / tableName；
相近时间（createTime 对应助教流水的 create_time/ledger_end_time 附近）。
这说明系统在设计时，把“废除事件”作为独立表存储，但没有在导出中包含可直接联表的订单 ID。结构上就导致“硬外键”缺失，只能做“软匹配”。
- 与资金/账户类表的潜在关系（结构层面）
关键金额字段：
assistantAbolishAmount 是本表唯一金额字段。
结合字段命名和位置，可以推断结构关系：
如果废除操作产生金额变动（例如退还部分费用或扣除违约金），那么在：
退款记录.json 中可能有对应一笔退款记录；
余额变更记录.json 中可能有对应一条会员卡余额变动（若退到卡里）。
这些表中不会直接有 assistantAbolishAmount 字段，但会有金额字段 + 关联 ID，结构上可能通过金额和时间进行逻辑匹配。
需要强调：
这里只指出“这个字段在系统里承担的是一个‘金额变量’的角色”，不做盈利/损益层面的任何分析或结论。
四、本表本身暴露出的结构性线索
清晰的单一职责 助教废除.json 不包含订单号、支付信息、会员信息等字段，只保留：
门店/桌台维度；
助教维度；
时间、分钟数；
一个金额字段；
文本原因字段。 说明这个表的设计就是“专门记录助教废除事件”的事件表，倾向于作为运营日志或审计用途，而不是主结算表。
软外键的设计取向
没有 order_trade_no、order_settle_id 等硬外键字段。
需要通过“时间 + 助教 + 桌台”的组合条件与 助教流水、订单/结算 进行软关联。
在迁移或对接新系统时，如果希望建立强外键，建议在新结构中给废除表补充 order_assistant_id 或 order_trade_no 之类的字段，以便直接关联。
分钟与秒的混用
pdChargeMinutes 单位是“分钟”；
在 助教流水.json 中，同类字段如 income_seconds / real_use_seconds 是“秒”。 结构层面说明：系统在不同接口/表中用了不同的时间单位。 在做结构统一或数据建模时，最好统一为一个单位（全部转为秒或全部转为分钟），否则容易出现比较/汇总混乱。
废除原因文本未被使用但结构预留完备
当前 15 条记录中，trashReason 全部为空，说明实际运营中并没有强制填写原因。
但结构上预留了这个字段，将来如果要做“废除原因统计”或“内部稽核”，无需修改结构，只要要求前台填写即可。
数量很少但字段完整
当前总记录数只有 15 条，但已经有完整的门店、桌台、助教、时长、金额、原因字段。
说明设计不是临时补的，而是参照完整流水表（助教流水）设计的一张配套表，只是当前时间范围内“废除事件”确实不多。