ZQYY.FQ-ETL/docs/api-reference/endpoints/assistant_service_records.md

助教服务流水（GetOrderAssistantDetails）

自动生成于 2026-02-13 | 数据来源：本地 JSON 样本

基本信息

属性	值
接口路径	AssistantPerformance/GetOrderAssistantDetails
完整 URL	https://pc.ficoo.vip/apiprod/admin/v1/AssistantPerformance/GetOrderAssistantDetails
请求方法	POST
Content-Type	application/json
鉴权方式	Bearer Token（Authorization 头）
ODS 对应表	assistant_service_records
分页方式	page + limit（最大 100）
时间范围	需要（startTime / endTime）

请求参数

参数名	类型	示例值	说明
siteId	int	2790685415443269	门店 ID
startTime	string	"2026-02-01 08:00:00"	查询起始时间
endTime	string	"2026-02-13 08:00:00"	查询结束时间
IsConfirm	int	0	是否已确认（0=全部）
page	int	1	页码（从 1 开始）
limit	int	100	每页条数（最大 100）

响应字段（共 64 个）

#	字段名	类型	示例值
1	assistantNo	string	'27'
2	nickname	string	'泡芙'
3	levelName	string	'初级'
4	assistantName	string	'何海婷'
5	tableName	string	'S1'
6	siteProfile	object	{'id': 2790685415443269, 'org_id': 2790684179467077, 'sho...
7	skillName	string	'基础课'
8	id	int	2957913441292165
9	order_trade_no	int	2957784612605829
10	site_id	int	2790685415443269
11	tenant_id	int	2790683160709957
12	operator_id	int	2790687322443013
13	operator_name	string	'收银员:郑丽珊'
14	order_settle_id	int	2957913171693253
15	ledger_name	string	'27-泡芙'
16	ledger_group_name	string	''
17	ledger_unit_price	float	98.0
18	ledger_count	int	7592
19	ledger_amount	float	206.67
20	order_pay_id	int	0
21	create_time	string	'2025-11-09 23:25:11'
22	is_delete	int	0
23	assistant_team_id	int	2792011585884037
24	assistant_level	int	10
25	ledger_start_time	string	'2025-11-09 21:18:18'
26	ledger_end_time	string	'2025-11-09 23:24:50'
27	is_single_order	int	1
28	order_assistant_id	int	2957788717240005
29	site_assistant_id	int	2946266869435205
30	order_assistant_type	int	1
31	ledger_status	int	1
32	site_table_id	int	2793020259897413
33	projected_income	float	168.0
34	is_not_responding	int	0
35	income_seconds	int	7560
36	user_id	int	2946266868976453
37	trash_applicant_id	int	0
38	trash_applicant_name	string	''
39	is_trash	int	0
40	trash_reason	string	''
41	real_use_seconds	int	7592
42	add_clock	int	0
43	returns_clock	int	0
44	is_confirm	int	2
45	member_discount_amount	float	0.0
46	manual_discount_amount	float	0.0
47	service_money	float	0.0
48	person_org_id	int	2946266869336901
49	last_use_time	string	'2025-11-09 23:24:50'
50	salesman_name	string	''
51	salesman_user_id	int	0
52	salesman_org_id	int	0
53	coupon_deduct_money	float	0.0
54	skill_id	int	2790683529513797
55	start_use_time	string	'2025-11-09 21:18:18'
56	tenant_member_id	int	0
57	system_member_id	int	0
58	skill_grade	int	0
59	service_grade	int	0
60	composite_grade	float	0.0
61	sum_grade	float	0.0
62	get_grade_times	int	0
63	grade_status	int	1
64	composite_grade_time	string	'0001-01-01 00:00:00'

新增字段（相对本地 JSON 样本）

以下字段在最新 API 响应中出现，但本地 JSON 样本中不存在：

字段名	类型
assistantTeamName	string
real_service_money	float

详细字段分析

以下内容迁移自旧版 assistant_service_records-Analysis.md，包含字段的业务含义、枚举值、跨表关联等详细说明。

二、记录级字段完整清单与说明

下面按逻辑分组来讲字段。数据类型和枚举值，是根据导出数据实际值推断出来的。

1. 订单与关联 ID 类字段

这些字段主要用来跟其他表做关联（订单、支付、会员、助教档案等）：

id

类型：int

含义：本条助教流水记录的主键 ID（流水唯一标识）。

作用：在系统内部唯一定位这一条助教服务记录。

order_trade_no

类型：int

含义：订单交易号，整个订单层面的编号。

关联：

与台费流水、门店销售记录、团购套餐流水等表中的同名字段是一致的，用于把 同一笔订单下的各类消费明细（台费/商品/助教/套餐）串起来。

order_settle_id

类型：int

含义：订单结算 ID，相当于“结账单号”的内部主键。

关联：

与小票详情中的 orderSettleId 对应。

正常情况下也应对应结账记录表中的结算主键（本次导出结账记录为空，但字段设计明显就是用来关联的）。

order_assistant_id

类型：int

含义：订单中“助教项目明细”的内部 ID。

作用：如果订单里有多条助教项目（比如换助教、多个时间段），此字段唯一标识这一条助教明细。

order_assistant_type

类型：int，枚举。

观测值：1 和 2。

含义（推测）：

1：常规助教服务（主课/基础课）。

2：附加类助教服务（如“附加课”），和字段 skillName 的值相对应（本数据里，skillName 有 “基础课”和“附加课” 两类）。

实际含义以系统内部配置为准，但可以确定是 助教服务类型枚举。

order_pay_id

类型：int

含义：关联到“支付记录”的主键 ID。

作用：可以和支付记录中的 id / relate_id 等字段对应，找到这条助教服务对应的支付流水。

tenant_id

类型：int

含义：租户/品牌 ID；你这份数据中是固定值（同一个商户）。

关联：全库所有表都有，作为“商户维度”的过滤键。

site_id

类型：int

含义：门店 ID，本数据中指“朗朗桌球”这一家门店。

关联：

与其他所有 JSON 中的 site_id 一致，用于判断记录属于哪家门店。

与内嵌的 siteProfile.id 一致。

site_assistant_id

类型：int

含义：门店维度的助教 ID。

关联：

在 助教账号1/2.json 中，字段 id 就是这个 site_assistant_id。

即：助教流水.site_assistant_id = 助教账号.id → 这是助教档案的外键。

user_id

类型：int

含义：助教对应的“用户账号 ID”（系统级用户）。

关联：

在助教账号表中有同名字段 user_id，与这里完全一致。

一般是登录账号的主键，区别于 site_assistant_id（岗位/角色 ID）。

person_org_id

类型：int

含义：助教所属“人事组织/部门 ID”。

关联：

在助教账号表中同样存在 person_org_id 字段，值完全一致。

用来做人员组织维度的归属，如“朗朗桌球-助教部”。

assistant_team_id

类型：int

含义：助教所属团队 ID。

特点：当前数据中所有记录都是同一个 team_id。

关联：

在助教账号表中有 team_id 字段，对应相同值。

此字段常用于排班/团队统计。

tenant_member_id

类型：int

含义：商户维度会员 ID（门店/品牌内的会员主键）。

观测值：有不少为 0，表示非会员；非零时与会员档案中的 id 一致。

关联：

**会员档案（tenantMemberInfos）**中的 id = 此处的 tenant_member_id。

用来联表查出对应会员的基本资料。

system_member_id

类型：int

含义：系统级会员 ID（全集团统一 ID）。

观测：大部分非 0 记录，对应会员档案中的 system_member_id。

关联：

会员档案中的 system_member_id 字段。

说明：system_member_id 把一个会员在不同门店/不同卡种的账号串起来；tenant_member_id 则是本商户的那一条记录。

skill_id

类型：int

含义：助教服务“课程/技能”ID。

观测：当前数据中只有一个技能 ID（同一类“基础课/附加课”）。

关联：应对应某个“课程/技能配置表”的主键（你这次导出里没见那个表）。

2. 助教维度字段

这些字段描述“是哪位助教、什么级别、属于哪个组”等：

assistantNo

类型：string

含义：助教编号，例如 "27"。

关联：在助教账号表里也有 assistant_no 字段，对应工号/编号。

assistantName

类型：string

含义：助教姓名，如“何海婷”“胡敏”等。

备注：和助教账号档案里的 real_name 一致。

nickname

类型：string

含义：助教对外昵称，如“佳怡”“周周”“球球”等。

说明：从数据看，这个 nickname 是“助教昵称”，不是顾客昵称（容易混淆）。

关联：在很多小票、商品名里，会把 “编号-昵称” 组合使用（如 ledger_name = "2-佳怡"）。

assistant_level

类型：int，枚举。

观测值与 levelName 对应关系（从数据中直接推出来）：

8 → levelName = "助教管理"（管理角色）

10 → "初级"

20 → "中级"

30 → "高级"

说明：这是助教级别的数值编码，对应助教账号表中的 level 字段。

levelName

类型：string

含义：助教等级名称，与 assistant_level 一一对应（初级/中级/高级/助教管理）。

备注：属于展示用的冗余字段。

assistant_team_id

已在上一节说明（团队 ID）。

skillName

类型：string

观测值："基础课" 或 "附加课"。

含义：当前这条助教服务所对应的“课程/技能名称”。

当 order_assistant_type = 1 时，多为“基础课”。

当 order_assistant_type = 2 时，为“附加课”。

skill_grade

类型：int

观测：全为 0。

含义（推测）：顾客对“技能表现”的评分（整数或打分等级）。

当前数据中还未产生评分记录，所以都是默认值 0。

service_grade

类型：int

观测：全为 0。

含义（推测）：顾客对“服务态度”的评分。

composite_grade

类型：float

观测：全为 0.0。

含义：综合评分（例如技能+服务加权后的平均分），当前数据没有实际评分。

sum_grade

类型：float

观测：全为 0.0。

含义：累计评分总和（可能用于计算平均分），当前为 0。

get_grade_times

类型：int

观测：全为 0。

含义：该条记录对应的评价次数（或该助教被评价次数快照）。

grade_status

类型：int，枚举。

观测：全为 1。

含义（推测）：评价状态，比如：

1 = 未评价/正常；

其他值可能表示“已评价”“屏蔽”等，当前数据没有别的值，具体含义需要系统配置表。

composite_grade_time

类型：string（时间）

观测：全为 "0001-01-01 00:00:00"。

含义（推测）：最近一次评价时间/综合评分更新时间。现在都是默认“无效时间”。

3. 桌台 / 门店维度字段

tableName

类型：string

含义：助教服务所在的球台名称（如 "A17"、"S1"）。

关联：

与台桌列表中的 table_name / table_no 对应（通过 site_table_id）。

site_table_id

类型：int

含义：球台 ID。

关联：

对应台桌列表中的 id 字段，表示具体是哪一张桌。

siteProfile

类型：object

含义：门店信息快照，包括 id、shop_name、address 等，和其他 JSON 里的 siteProfile 一致。

作用：冗余门店信息，方便查看（而不是每次都联表看门店档案）。

4. 时间 / 时长相关字段 4.1 时间点（字符串时间）

create_time

类型：string，格式 YYYY-MM-DD HH:MM:SS

含义：这条助教流水记录创建时间（一般接近结算/下单时间）。

start_use_time

类型：string

含义：助教实际开始服务时间。

特点：正常情况下与 ledger_start_time 相同。

last_use_time

类型：string

含义：最后一次使用（实际服务）时间。

特点：正常结束时与 ledger_end_time 相同；如果服务还未真正开始或立即结束，开始/结束时间可能相同。

ledger_start_time

类型：string

含义：台账层面记录的开始时间。

说明：与 start_use_time 在当前数据中完全一致，可以视为“计费起始时间”。

ledger_end_time

类型：string

含义：台账层面的结束时间。

说明：与 last_use_time 一致，可以视为“计费结束时间”。对于 real_use_seconds = 0 的记录，开始和结束时间相同，说明只是预约/录入，并未实际服务。

4.2 时长（秒）

这几个字段单位都是“秒”。

income_seconds

类型：int

含义：计费秒数 / 应计收入对应的时间。

特点：

值基本是 60 的倍数（2700、3600、7200、10800 等），即按分钟整点计费的秒数。

用这个字段配合 ledger_unit_price 计算应计金额（原价或折扣价）。

real_use_seconds

类型：int

含义：实际使用时长（秒）。

特点：

大多数情况下，real_use_seconds ≈ ledger_count（有少量 ±1 秒差）。

对于还没真正消费的记录，该值为 0，表示“已预约/已排钟但还没消耗”。

ledger_count

类型：int

含义：台账记录的计时总秒数。

特点：

正常结束的记录中，与 real_use_seconds 基本一致。

可以理解为“本条助教服务真正消耗的总时长（秒）”。

add_clock

类型：int（秒）

观测值：多为 0，有少量为 240, 300, 420, 600, 900, 2400, 2700, 3600, 32400 等。

含义（推测）：加钟秒数，即在原有预约/服务基础上临时追加的时长。

说明：值均为 60 的倍数（分钟级加钟），如 600 秒=10 分钟。

returns_clock

类型：int（秒）

观测：全部为 0。

含义（推测）：退钟秒数（取消加钟或提前结束退回的时间）。

当前数据里没有退钟场景，所以全为 0，但字段设计已经预留。

5. 金额与折扣相关字段

ledger_unit_price

类型：float

含义：助教服务 标准单价（通常是标价：每小时、每节课的单价）。

特点：如 98.0、108.0、190.0 等。

ledger_amount

类型：float

含义：按标准单价计算出来的应收金额（近似 = ledger_unit_price × income_seconds / 3600）。

说明：从数据看，这个金额对应“按原价计费”的金额，未扣除各种优惠。

projected_income

类型：float

含义：实际结算计入门店的金额（已经考虑折扣、卡权益、券等后的结果）。

从数据：projected_income 明显低于 ledger_amount，说明中间有折扣，但折扣的明细并不全由下面几个字段体现（很多是卡权益内生折扣）。

coupon_deduct_money

类型：float

观测值：大多数为 0.0，有少量记录为 195.73、431.1 等。

含义：由“优惠券/代金券/团购券”等 直接抵扣到这条助教服务上的金额。

说明：

当 >0 时，表明这一条助教服务使用了券抵扣了这么多金额。

与平台验券记录 / 团购套餐流水中的券相关字段联动。

manual_discount_amount

类型：float

观测：全部为 0.0。

含义：收银员手动给予的减免金额（人工改价）。

当前导出时间段内暂未出现手动打折的情况。

member_discount_amount

类型：float

观测：全部为 0.0。

含义：由会员卡折扣产生的优惠金额。

说明：尽管字段里是 0，但实际折扣可能已经体现在 projected_income 与 ledger_amount 的差额中，这里只是未单独拆出。

service_money

类型：float

观测：全部为 0.0。

含义（推测）：用于记录与助教结算的金额（平台预留的“成本/分成”字段）。

当前数据中未启用这个机制，所以全为 0。

6. 状态 / 标志字段

ledger_status

类型：int，枚举。

观测：全部为 1。

含义（推测）：助教流水记录状态：

1：正常有效。

其他值（例如 0、2）可能对应“未结算”“已作废”等，当前数据未出现。

is_confirm

类型：int，枚举。

观测：全部为 2。

含义（推测）：确认状态，例如：

1：待确认；

2：已确认 / 已完成。

从全部为 2 推断：导出时选的是已经确认的流水。

is_single_order

类型：int，枚举。

观测：全部为 1。

含义（推测）：是否单独订单：

1：本助教服务作为单独订单结算（或单独拆项）。

0：与其他项目（台费、商品）一起打包在综合订单里。

当前门店显然采用“助教单独结算”的模式，故全为 1。

is_not_responding

类型：int，枚举。

观测：全为 0。

含义（推测）：是否存在“爽约/未响应”情况：

0：正常；

1：有爽约等异常情况。

当前时间段没有记录被标记为爽约。

is_trash

类型：int，枚举。

观测：全为 0。

含义：是否已废除/作废：

0：正常有效；

1：已废除（对应“助教废除.json”里的记录）。

一旦为 1，一般会配合 trash_reason 等字段，并在“助教废除”表中有对应记录。

is_delete

类型：int，枚举。

观测：全为 0。

含义：逻辑删除标志。

0：未删除；

1：已删除（逻辑删除，历史保留）。

和 is_trash 不同：is_trash 表示业务上的“废除”，is_delete 表示系统级删除。

7. 会员/顾客维度（在本表中的影子）

system_member_id / tenant_member_id

已在“关联 ID 类字段”里说明：

system_member_id 对应会员在整个系统的唯一 ID；

tenant_member_id 对应当前租户中的会员 ID（会员档案的主键 id）。

注意：这份助教流水里没有直接出现“顾客姓名”字段，只通过这两个 ID 与会员档案、储值卡等表关联。

8. 员工 / 销售人员相关字段

salesman_name

类型：string

含义：关联的“营业员/销售员姓名”，用于提成归属。

观测：本数据中多数为空字符串，说明助教流水没有配置单独的营业员。

salesman_user_id

类型：int

含义：营业员用户 ID。

观测：多为 0，代表未指定。

salesman_org_id

类型：int

含义：营业员所属组织/部门 ID。

观测：多为 0。

operator_id

类型：int

含义：操作员 ID（录入/结算这条助教服务的员工）。

关联：可与员工/账号表对应（本次导出未单独给员工表，但其他 JSON 里多处出现该 ID）。

operator_name

类型：string

含义：操作员姓名，与 operator_id 一起使用，便于直接阅读。

user_id

已在“关联 ID 类字段”说明：助教的系统用户 ID，与助教账号表中的 user_id 一致。

person_org_id

同样在上文说明：助教所属人事组织 ID。

9. 作废 / 废除相关字段

这几个字段在当前数据中值都为 0 或空串，但从命名可以看出专门用于记录“助教废除”的信息，与 助教废除.json 表配合使用。

trash_applicant_id

类型：int

含义：提出废除申请的员工 ID（通常是操作员/管理员）。

当前数据全为 0，因此短期内没有发生废除操作。

trash_applicant_name

类型：string

含义：废除申请人姓名。

trash_reason

类型：string

含义：废除原因（文本说明），例如“顾客取消”“录入错误”等。

当前数据为空字符串，说明当前导出时间段没有被废除的助教流水记录。

10. 其他字段

ledger_group_name

类型：string

观测：全部为空字符串。

含义（推测）：助教项目所属的“计费分组/套餐分组名称”，例如某种助教套餐或业务组名称。

目前未被实际使用。

三、助教流水与其它 JSON 的关键关系（从字段角度再强调一下）

虽然你这次提问重点是字段本身，但从字段设计可以看出它在整个系统里的“位置”，这里简要点一下（不做数值分析）：

与助教账号（助教账号1/2.json）

site_assistant_id ↔ 助教账号表的 id

user_id ↔ 助教账号表的 user_id

assistant_team_id ↔ 助教账号表的 team_id

person_org_id ↔ 助教账号表的 person_org_id

assistant_level ↔ 助教账号表的 level

说明：助教流水是“事实表”，助教账号是“维表”。

与会员档案（会员档案.json）

system_member_id ↔ 会员档案中的 system_member_id

tenant_member_id ↔ 会员档案中的 id

说明：通过这两个字段可以追溯到哪个会员预约/购买了这次助教服务。

与台桌（台桌列表.json）

site_table_id ↔ 台桌表中的 id

tableName ↔ 台桌表中的 table_name/table_no

说明：标记助教服务在哪张桌上进行。

与订单/小票（小票详情.json / 结账记录.json）

order_trade_no、order_settle_id 与其它消费明细（台费、商品、套餐流水）共享，构成一次订单下的不同子项目。

小票详情中的 orderSettleId 与这里的 order_settle_id 对应。

与支付/退款（支付记录.json / 退款记录.json）

order_pay_id 对应支付记录中的 ID 或 relate_id。

支付记录通过 relate_type 区分是订单支付还是其他业务（如充值）；这里的助教流水对应的是订单类支付。

与助教废除（助教废除.json）

当 is_trash = 1 时，对应的废除详情（原因、废除时间等）会记录在“助教废除.json”里。

字段 trash_reason、trash_applicant_id/name 就是废除信息在当前流水记录中的快照。