# 台费流水（GetSiteTableOrderDetails）

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

## 基本信息

| 属性 | 值 |
|------|-----|
| 接口路径 | `Site/GetSiteTableOrderDetails` |
| 完整 URL | `https://pc.ficoo.vip/apiprod/admin/v1/Site/GetSiteTableOrderDetails` |
| 请求方法 | `POST` |
| Content-Type | `application/json` |
| 鉴权方式 | Bearer Token（`Authorization` 头） |
| ODS 对应表 | `table_fee_transactions` |
| 分页方式 | `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 |
| `isSaleManUser` | int | `0` | 是否销售员用户（0=全部） |
| `page` | int | `1` | 页码（从 1 开始） |
| `limit` | int | `100` | 每页条数（最大 100） |

## 响应字段（共 39 个）

| # | 字段名 | 类型 | 示例值 |
|---|--------|------|--------|
| 1 | `siteProfile` | object | {'id': 2790685415443269, 'org_id': 2790684179467077, 'sho... |
| 2 | `id` | int | 2957924029058885 |
| 3 | `order_trade_no` | int | 2957858167230149 |
| 4 | `site_id` | int | 2790685415443269 |
| 5 | `tenant_id` | int | 2790683160709957 |
| 6 | `member_id` | int | 0 |
| 7 | `operator_id` | int | 2790687322443013 |
| 8 | `operator_name` | string | '收银员:郑丽珊' |
| 9 | `order_settle_id` | int | 2957922914357125 |
| 10 | `ledger_unit_price` | float | 48.0 |
| 11 | `ledger_name` | string | 'A17' |
| 12 | `ledger_count` | int | 3600 |
| 13 | `ledger_amount` | float | 48.0 |
| 14 | `order_pay_id` | int | 0 |
| 15 | `create_time` | string | '2025-11-09 23:35:57' |
| 16 | `is_delete` | int | 0 |
| 17 | `site_table_id` | int | 2793003705192517 |
| 18 | `site_table_area_id` | int | 2791963794329671 |
| 19 | `tenant_table_area_id` | int | 2791960001957765 |
| 20 | `is_single_order` | int | 1 |
| 21 | `ledger_start_time` | string | '2025-11-09 22:28:57' |
| 22 | `ledger_end_time` | string | '2025-11-09 23:28:57' |
| 23 | `ledger_status` | int | 1 |
| 24 | `site_table_area_name` | string | 'A区' |
| 25 | `real_table_charge_money` | float | 0.0 |
| 26 | `used_card_amount` | float | 0.0 |
| 27 | `adjust_amount` | float | 0.0 |
| 28 | `real_table_use_seconds` | int | 3600 |
| 29 | `coupon_promotion_amount` | float | 48.0 |
| 30 | `service_money` | float | 0.0 |
| 31 | `member_discount_amount` | float | 0.0 |
| 32 | `last_use_time` | string | '2025-11-09 23:28:57' |
| 33 | `salesman_name` | string | '' |
| 34 | `salesman_user_id` | int | 0 |
| 35 | `salesman_org_id` | int | 0 |
| 36 | `mgmt_fee` | float | 0.0 |
| 37 | `fee_total` | float | 0.0 |
| 38 | `start_use_time` | string | '2025-11-09 22:28:57' |
| 39 | `add_clock_seconds` | int | 0 |

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

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

| 字段名 | 类型 |
|--------|------|
| `activity_discount_amount` | float |
| `order_consumption_type` | int |
| `real_service_money` | float |

## 详细字段分析

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

二、记录级字段拆解与说明
1. 顶层 / 分页相关

code（在数组元素上）

类型：int

枚举：当前仅出现 0。

含义：接口调用状态，0 表示成功。

data.total

类型：int

含义：本次查询条件下台费流水总条数（3813），用于分页计算。

data.siteTableUseDetailsList

类型：array

含义：台费流水记录列表，每个元素即一次台费使用记录。

2. 主键 / 订单维度字段

这些字段用来把台费流水和订单、小票、支付等其他表关联在一起。

id

类型：int

唯一性：每条记录一个独立值。

含义：台费流水记录主键（事实表主键）。

order_trade_no

类型：int

唯一性：本文件中每条记录一个值（200 条全不重复）。

含义：订单交易号，是整笔订单的主编号。

关联：

与其它 JSON（如 助教流水、小票详情、门店销售记录）中的同名字段一致，用于把 同一订单下的台费、助教、商品等多条明细串联。

order_settle_id

类型：int

唯一性：每条记录一个值（200 条全不重复）。

含义：结算单号/结账 ID，对应一次结账操作。

关联：

与“小票详情.json”中的 orderSettleId 对应；

与（若存在）结账记录表的主键对应。

order_pay_id

类型：int

含义：订单支付记录 ID。

关联：

对应“支付记录.json”中的 id 或 relate_id（视模型而定），用于追踪这条台费最终对应哪一条支付流水。

tenant_id

类型：int

观测：所有记录值相同（2790683160709957）。

含义：租户/品牌 ID。本文件所有记录都属于同一租户。

关联：与所有其它 JSON 中的 tenant_id 一致，用于跨表做“商户维度”的过滤。

site_id

类型：int

观测：所有记录相同（2790685415443269）。

含义：门店 ID，本次数据全部来自同一门店（朗朗桌球）。

关联：

与 siteProfile.id 一致；

与其它表（助教流水、销售记录等）中的 site_id 对应，保证“门店维度”一致。

3. 台桌维度字段

这些字段描述“哪一张台、在哪个区域”。

site_table_id

类型：int

唯一性：约 45 个不同值。

含义：球台 ID。

关联：

对应“台桌列表”中的 id（当前导出文件中有一类与之对应的台桌配置表）。

用于精确确定具体是哪个台。

ledger_name

类型：string

示例值："A1"、"A2"、"A3"、"A4"、"A5"、"A7"、"A8"、"A9"、"A10"、"S1" 等。

含义：台号名称，实际展示给员工/顾客看的桌台编号。

备注：与 site_table_id 一一对应，是桌台维表中的名称字段冗余到流水里的快照。

site_table_area_id

类型：int

唯一性：10 个左右的不同值。

含义：门店内“台桌区域” ID（站在门店物理布局的角度）。

关联：

对应“门店台桌区域配置表”的主键；

与 site_table_area_name 搭配使用。

tenant_table_area_id

类型：int

唯一性：与 site_table_area_id 数量相同，也是 10 个值。

含义：租户维度的台桌区域 ID（品牌层面的同一类区域）。

关联：

对应租户层面的“区域维表”，支持多门店共享同一套区域配置。

site_table_area_name

类型：string

枚举（本数据中观测值）：

"A区"（144 条）

"B区"（21 条）

"斯诺克区"（17 条）

"麻将房"（6 条）

"C区"（5 条）

"K包", "VIP包厢"（各 2 条）

"666", "TV台", "M8"（各 1 条）

含义：台桌区域的名称，用于门店表现和区域统计。

4. 会员维度与相关字段

member_id

类型：int

观测：

多数为 0（180 条），表示散客/非会员。

少量为非 0 的 10 个不同 ID。

含义：门店/租户内的会员 ID。

关联：

与“会员档案.json（tenantMemberInfos）”内的 id 对应（有部分 ID 完全匹配，部分会员可能不在当前导出页）。

用于将台费流水关联到具体哪位会员。

member_discount_amount

类型：float

观测：

大多数为 0.0；

少量为正值，如 376.87、259.16、151.98、253.02、108.16 等。

含义：由会员权益产生的优惠金额，例如会员折扣、会员价等。

特点：

在部分记录中 ledger_amount = real_table_charge_money = member_discount_amount，说明该台费完全通过会员权益抵扣，记录在此字段，同时仍保留原价。

used_card_amount

类型：float

观测：当前样本全部为 0.0。

含义（推测）：储值卡/次卡直接抵扣到台费的金额。

说明：字段已预留，但在本时间范围内台费未通过“卡余额”支付，或该信息不在此表体现。

5. 时间与时长相关字段
5.1 时间点

create_time

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

含义：这条台费流水记录的创建时间，通常接近结账时间。

start_use_time

类型：string

含义：台开始使用的时间（实际开台时间）。

特点：在数据中，与 ledger_start_time 完全相同（见下）。

last_use_time

类型：string

含义：最后使用/操作时间。

特点：

大多数情况下与 ledger_end_time 只差 1 秒；

可以理解为“真实最后一次计时上报的时间”。

ledger_start_time

类型：string

含义：台账上的计费起始时间。

关系：

当前数据中 ledger_start_time == start_use_time，说明起算时刻与开台时间一致。

ledger_end_time

类型：string

含义：台账上的计费结束时间。

关系：

和 last_use_time 多数情况下相差 1 秒（last_use_time 比它晚 1 秒），说明计费结束时间经系统截断处理，而 last_use_time 是最后事件时间。

5.2 时长（秒）

ledger_count

类型：int

含义：台账记录的计费秒数，计费用秒数（应收时长）。

特点：

大部分记录中 ledger_count 等于 real_table_use_seconds，少数记录差 1 秒（对齐问题）。

为 0 的少数记录（6 条），对应 real_table_use_seconds 也为 0。

real_table_use_seconds

类型：int

含义：实际使用的总秒数（系统真实统计的使用时长）。

关系：

与 ledger_count 基本一致（只有 +1 秒的偏差），可以认为 ledger_count 是基于它做的计费截断结果。

当两者均为 0 且 is_single_order = 0 时，表示这条记录只是占位/关联记录，并未产生真实使用和收费（例如合单场景或转移）。

add_clock_seconds

类型：int

含义：加钟秒数，在原有使用基础上追加的时长。

观测：

绝大部分记录为 0；

少数为 2400（40 分钟）、4200（70 分钟）等 60 的倍数。

说明：加钟逻辑为分钟级别，字段用于记录累计加钟时长。

6. 金额与优惠拆分字段

这些字段共同描述“台费原价金额”和各类优惠/调整后的分解。

ledger_unit_price

类型：float

示例值：48.0、58.0、68.0、88.0、98.0、116.0 等。

含义：台费结算时设置的 每小时单价/计费单价。

用途：与 ledger_count 共同决定原始应收额。

ledger_amount

类型：float

含义：按单价与计费时长计算出的原始应收台费金额。

近似关系：ledger_amount ≈ ledger_unit_price × ledger_count / 3600，考虑到四舍五入会有小数差。

real_table_charge_money

类型：float

含义：台费中实际向顾客收取的金额（现金/实付维度，未含券方承担或内部调账的那一部分）。

特点：

有的记录值为 0，说明该台费完全由券或内部调账承担，没有直接收取现金；

有的记录 real_table_charge_money = ledger_amount，说明没有外部优惠，顾客按原价买单。

coupon_promotion_amount

类型：float

观测：

常见值：48.0、96.0、116.0、68.0、136.0、144.0... 等；

有大量记录值等于整小时单价或其整数倍。

含义：由优惠券/活动/团购（平台/门店促销）承担的优惠金额，直接抵扣在台费上。

特点：当 real_table_charge_money = 0 且该字段为 ledger_amount 时，说明整笔台费是由券促销全额承担。

member_discount_amount

上文已说明，这里补充与金额的结构关系：

功能：表示由会员折扣或会员权益承担的那部分金额。

特殊场景：

有些记录中 ledger_amount = real_table_charge_money = member_discount_amount，从结构上看，是“原价计费 + 会员承担 + 仍记录为台费收入”的一种设计（系统内部体现为会员权益消耗）。

adjust_amount

类型：float

观测：

多数是 0.0；

少数为正值，如 120.0、148.15、14.16、24.18...。

含义：调整金额/调账金额，用于将台费金额转移或冲减到其它项目，或手工调整。

特点：

部分记录中 ledger_amount 全部通过 adjust_amount 抵消（real_table_charge_money = 0，coupon_promotion_amount = 0，adjust_amount = ledger_amount），说明这笔台费被完全调账到其他地方（例如包厢统一计费，或计入套餐）。

used_card_amount

类型：float

当前样本全为 0.0。

含义：由储值卡、次卡等“卡内余额”抵扣的金额。

说明：字段设计已预留，但本段时间内台费没有通过储值卡扣款，或者卡扣款在其他表体现。

service_money

类型：float

当前样本全为 0.0。

含义（推测）：门店用于记录“服务费/成本/分成金额”的字段，类似助教流水里的 service_money。

说明：当前门店未启用此字段结算台费。

mgmt_fee

类型：float

当前样本全为 0.0。

含义（推测）：管理费字段，用于未来支持“台费附加管理费/服务费”的功能。

当前未启用。

fee_total

类型：float

当前样本全为 0.0。

含义：各种附加费用（如管理费、服务费）合计值。

说明：和 mgmt_fee 一样，目前作为预留字段，没有实际使用。

从结构上看，台费金额被拆成多个维度：

原始应收：ledger_amount

实际收现：real_table_charge_money

券促销承担：coupon_promotion_amount

会员承担：member_discount_amount

调账：adjust_amount

卡扣款：used_card_amount（当前为 0）

各字段合起来，描述一条台费从“原始计费”到“谁来承担”这一系列拆分，非常细颗粒度，但这里不做金额计算和盈利分析，仅从结构上说明。

7. 操作员 / 营业员相关字段

operator_id

类型：int

含义：操作员 ID，负责开台/结账的员工账号 ID。

关联：与员工/账号体系中的用户 ID 对应（与助教账号的 user_id 属于同一种 ID 体系）。

operator_name

类型：string

含义：操作员姓名（冗余字段），便于直接阅读，不必再联表员工档案。

salesman_name

类型：string

当前样本全部为空字符串。

含义：业务员/营业员姓名，如果台费有单独提成员工，这里记录归属人。

当前门店未启用该字段做提成归属。

salesman_user_id

类型：int

当前全为 0。

含义：营业员的用户 ID（与 salesman_name 搭配）。

salesman_org_id

类型：int

当前全为 0。

含义：营业员所属机构/部门 ID。

8. 状态 / 标记类字段

ledger_status

类型：int，枚举。

观测：全部为 1。

含义（推测）：

1：正常已结算台费；

其他值（例如 0 未结算、2 作废）在当前数据未出现，但从命名看属于状态位。

is_single_order

类型：int，枚举。

观测：1（194 条）、0（6 条）。

含义（推测）：

1：该台费记录对应的是一个独立计费单元（单独结算的桌费）；

0：非独立结算条目，可能依附于其他订单（如合并结账、占位记录、转单/转台的中间记录）。

特点：is_single_order = 0 的记录中，ledger_count 和 real_table_use_seconds 为 0，说明没有实际使用与收费，是一种结构性的“占位/关联”记录。

is_delete

类型：int，枚举。

观测：全部为 0。

含义：逻辑删除标志：

0：未删除（有效记录）；

1：已逻辑删除（从界面隐藏，历史保留）。

当前导出时间段没有被标记删除的台费记录。

9. 门店信息快照

siteProfile

类型：object（字典）

观测：所有记录的 siteProfile 内容相同。

内部字段包括（概略）：

id（门店 ID，与 site_id 相同）

org_id（所属组织 ID）

shop_name（门店名称，如“朗朗桌球”）

full_address、address

longitude、latitude

tenant_site_region_id、tenant_id

一些门店级配置（例如自动开灯、WiFi、客服二维码、营业状态等）

含义：当前门店的完整档案快照，冗余到流水表中，便于报表直接读取而无需再联表门店档案。

三、与其它 JSON 的结构关联关系（从字段层面）

只从字段层面梳理，不做数值层面的分析：

与“助教流水.json”

关联键：

order_trade_no、order_settle_id：同一订单下，台费流水与助教流水共享同一交易号和结算号，可以一起还原某次消费包含“台费 + 助教”的组合明细。

site_id、tenant_id：门店与租户维度一致。

结构上：两者都是“事实表”，分别记录“台使用”和“助教服务”，共享同一套订单系统与支付系统。

与“小票详情.json”

关联键：

order_settle_id ↔ 小票详情中的 orderSettleId；

order_trade_no ↔ 小票中的订单号。

结构线索：

小票层面是顾客看到的整笔账单；台费流水是其中“台费项目”的拆解结果（含时长、单价、优惠明细）。

与“会员档案.json（会员信息）”

关联键：

台费流水中的 member_id ↔ 会员档案中的 id（tenant_member_id）。

用途：

可以从台费流水倒推出是哪个会员在该台消费；

再通过会员档案看其手机号、姓名、卡状态等。

与“台桌列表/台桌配置.json”

关联键：

site_table_id ↔ 台桌列表的 id；

site_table_area_id ↔ 门店台桌区域配置表；

tenant_table_area_id ↔ 租户层面区域配置表。

用途：

支持按台、按区域统计使用时长与台费占用情况；

结合 ledger_name 和 site_table_area_name 做场地运营维度分析（结构上可行，这里不做数值分析）。

与“支付记录.json”

关联键：

order_pay_id ↔ 支付记录中的 ID/关联 ID。

结构线索：

可从支付记录看付款方式（现金/二维码/微信/支付宝/卡扣等），与本表的 real_table_charge_money、used_card_amount 等金额字段拼接成完整支付结构。

与“门店销售记录/库存变动.json”

虽然台费不是库存商品，但在整体订单结构中，台费与商品销售在“订单主表”上共享 order_trade_no 和 order_settle_id，结构上处于同一个“结账事件”下。

四、本表在整体模型中的结构角色（从字段设计角度的线索）

从字段设计和关联关系可以看出：

siteTableUseDetailsList 是标准的“台费事实表”

每条记录 = 一段台使用时长结算快照；

通过主键 id 唯一标识；

通过 site_table_id/site_table_area_id 关联台桌维度；

通过 order_trade_no、order_settle_id 关联订单与小票；

通过 member_id 关联会员；

通过 operator_id 关联操作员。

金额拆分字段非常细：

ledger_amount（原始应收），real_table_charge_money（实收现金），coupon_promotion_amount（券促销承担），member_discount_amount（会员承担），adjust_amount（调账），used_card_amount（卡扣），mgmt_fee/fee_total（预留管理费）。

说明在“台费”这一单类目上，系统已经设计为支持按承担主体拆分金额，用于对接多种优惠渠道与内部对账，但当前门店部分字段尚未启用（如 mgmt_fee、used_card_amount、service_money）。

时间与时长字段区分了“计费时间”和“真实时间”：

real_table_use_seconds 与 ledger_count 基本一致，但仍保留两个字段，说明系统刻意区分“真实使用时长”和“计费时长”；

last_use_time 与 ledger_end_time 相差 1 秒左右，说明系统既保留了事件时间，也保留了计费截断时间。

状态/标志字段为后续扩展留了空间：

ledger_status、is_single_order、is_delete 在当前数据中值单一或高度偏向某个值，说明系统支持更多状态，但当前门店只是处于相对简单的使用方式（几乎全部是正常未删除的台费记录，少量非独立订单占位记录）。

区域与桌台配置两级 ID（site_table_area_id / tenant_table_area_id）说明：

区域体系既有门店维度 ID，又有租户维度 ID，这为将来多门店统一配置区域，或者跨门店统计同类型区域的运营情况做了结构铺垫。

总的来说，台费流水.json 在结构上已经非常“规范化”：它作为台费的事实表，通过一系列 ID 字段与会员、门店、台桌、订单及支付等多张表关联，并在单条记录层面拆分了时长与金额的各个组成部分。这些都是后续做联表分析、建模和数据对齐时非常关键的结构信息。