# 团购核销记录（GetSiteTableUseDetails）

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

## 基本信息

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

## 请求参数

| 参数名 | 类型 | 示例值 | 说明 |
|--------|------|--------|------|
| `siteId` | int | `2790685415443269` | 门店 ID |
| `offlineCouponChannel` | int | `0` | 线下券渠道（0=全部） |
| `startTime` | string | `"2026-02-01 08:00:00"` | 查询起始时间 |
| `endTime` | string | `"2026-02-13 08:00:00"` | 查询结束时间 |
| `page` | int | `1` | 页码（从 1 开始） |
| `limit` | int | `100` | 每页条数（最大 100） |
| `queryType` | int | `1` | 查询类型（1=默认） |

## 响应字段（共 43 个）

| # | 字段名 | 类型 | 示例值 |
|---|--------|------|--------|
| 1 | `tableName` | string | 'A17' |
| 2 | `tableAreaName` | string | 'A区' |
| 3 | `siteName` | string | '朗朗桌球' |
| 4 | `goodsOptionPrice` | float | 0.0 |
| 5 | `id` | int | 2957924029615941 |
| 6 | `order_trade_no` | int | 2957858167230149 |
| 7 | `table_id` | int | 2793003705192517 |
| 8 | `site_id` | int | 2790685415443269 |
| 9 | `tenant_id` | int | 2790683160709957 |
| 10 | `operator_id` | int | 2790687322443013 |
| 11 | `operator_name` | string | '收银员:郑丽珊' |
| 12 | `order_settle_id` | int | 2957922914357125 |
| 13 | `ledger_name` | string | '全天A区中八一小时' |
| 14 | `ledger_group_name` | string | '' |
| 15 | `ledger_unit_price` | float | 29.9 |
| 16 | `ledger_count` | int | 3600 |
| 17 | `ledger_amount` | float | 48.0 |
| 18 | `order_pay_id` | int | 0 |
| 19 | `create_time` | string | '2025-11-09 23:35:57' |
| 20 | `is_delete` | int | 0 |
| 21 | `promotion_activity_id` | int | 2957858166460101 |
| 22 | `promotion_coupon_id` | int | 2798727423528005 |
| 23 | `is_single_order` | int | 1 |
| 24 | `order_coupon_id` | int | 2957858168229573 |
| 25 | `order_coupon_channel` | int | 1 |
| 26 | `ledger_status` | int | 1 |
| 27 | `promotion_seconds` | int | 3600 |
| 28 | `coupon_origin_id` | int | 2957858168229573 |
| 29 | `table_charge_seconds` | int | 3600 |
| 30 | `offer_type` | int | 1 |
| 31 | `coupon_money` | float | 48.0 |
| 32 | `tenant_table_area_id` | int | 2791960001957765 |
| 33 | `assistant_promotion_money` | float | 0.0 |
| 34 | `assistant_service_promotion_money` | float | 0.0 |
| 35 | `table_service_promotion_money` | float | 0.0 |
| 36 | `goods_promotion_money` | float | 0.0 |
| 37 | `reward_promotion_money` | float | 0.0 |
| 38 | `recharge_promotion_money` | float | 0.0 |
| 39 | `salesman_user_id` | int | 0 |
| 40 | `salesman_name` | string | '' |
| 41 | `salesman_role_id` | int | 0 |
| 42 | `sales_man_org_id` | int | 0 |
| 43 | `coupon_code` | string | '0107892475999' |

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

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

| 字段名 | 类型 |
|--------|------|
| `assistant_service_share_money` | float |
| `assistant_share_money` | float |
| `coupon_sale_id` | int |
| `good_service_share_money` | float |
| `goods_share_money` | float |
| `member_discount_money` | float |
| `recharge_share_money` | float |
| `table_service_share_money` | float |
| `table_share_money` | float |

## 详细字段分析

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

二、记录级字段逐项说明（共 43 个）

我按业务逻辑分组说明：台桌 / 门店维度、订单与关联 ID、金额与时间字段、券字段、促销拆账字段、状态字段、操作员/销售字段等。

1. 台桌 / 门店维度字段

tableName

类型：string

示例："A7", "A11", "B1", "斯1", "麻1" 等。

含义：本次使用券所关联的 球台名称/台号。

关联：对应台桌列表中的 table_name / table_no，通过 table_id 进一步关联。

tableAreaName

类型：string

观测值（枚举）："A区", "B区", "斯诺克区", "麻将房"。

含义：该球台所属的 台区名称。

关联：与台区配置中的 area_name 含义一致，与团购套餐定义中的 table_area_name 一致。

table_id

类型：int

含义：球台 ID。

关联：

对应“台桌列表”表中的 id 字段。

用于联表确定该记录具体是哪一张桌。

table_charge_seconds

类型：int（秒）

示例：3600, 7200, 10800, 14400，以及一些非整小时值如 10247, 7168 等。

含义：本次结算中该球台总计计费的秒数（整台的台费计费时间）。

结构特点：

当券完全覆盖整个台的时长时，table_charge_seconds 通常 = ledger_count。

当台上有多种计费组合（比如部分时间是券，部分时间是正常计时）时，table_charge_seconds 可能大于 ledger_count 和 promotion_seconds。

siteName

类型：string

观测值：全部为 "朗朗桌球"。

含义：门店名称，冗余展示用。

site_id

类型：int

含义：门店 ID，与其它 JSON 中一致。

关联：

与“团购套餐定义”、“助教流水”、“台费流水”、“门店销售记录”等文件中的 site_id 完全一致，用于统一按门店过滤。

tenant_id

类型：int

含义：租户/品牌 ID。

特点：全表值相同，说明所有记录属于同一租户。

tenant_table_area_id

类型：int

观测值（枚举，4 个值）：

2791960001957765（占 164 条）

2791960521691013（19 条）

2791961347968901（16 条）

2791962314215301（1 条）

含义：租户级台区分组 ID，表示当前使用券的台桌所属的区域组合。

关联：

与“团购套餐定义”中的 tenant_table_area_id_list 对应（那边是字符串形态，这里是数值形态），表明该券只能在某些台区组合上使用。

结构作用：用于校验券的适用台区与实际台桌是否匹配。

2. 订单与关联 ID 类字段

id

类型：int

含义：本条“团购套餐流水”记录的 主键 ID。

作用：唯一标识一条券使用到台费上的记录。

order_trade_no

类型：int

含义：订单交易号，和其它消费明细（台费、商品、助教、团购）共用的订单主键。

关联：

与“小票详情”、“台费流水”、“助教流水”等的 order_trade_no 一致，用于将同一笔结账中的所有子项目关联起来。

order_settle_id

类型：int

含义：结算单 ID（小票结账主键）。

关联：

与“小票详情”中的 orderSettleId 相对应。

与“结账记录”中的结算 ID 一致。

order_pay_id

类型：int

观测：部分记录为 0，部分为非零 ID。

含义（推测）：

指向支付记录表中的支付流水 ID。

当为 0 时，可能表示该券使用记录在导出范围内未能联到具体支付记录（或为非现金支付方式）。

order_coupon_id

类型：int

观测：200 条记录全部唯一。

含义：订单中“券使用记录”的 ID。

结构特点：

与 coupon_origin_id 当前完全相等，可以视作同一主键在不同上下文中的命名方式。

与“平台验券记录”或“券核销记录”表中的主键对应。

coupon_origin_id

类型：int

观测：200 条记录全唯一，数值与 order_coupon_id 完全一致。

含义（推测）：

平台/上游系统中的券记录主键 ID，“券来源 ID”。

系统中通过这个 ID 能从平台验券记录中查到券的完整来源信息（来源平台、活动等）。

promotion_activity_id

类型：int

观测：200 条记录全部不重复。

含义（推测）：团购/促销活动 ID。

对应平台或内部促销活动的主键，每个活动通常绑定一个或多个具体套餐（promotion_coupon_id）。

promotion_coupon_id

类型：int

观测：9 个不同值。

含义：团购套餐定义 ID。

关联：

与 20251110_043255_团购套餐.json 中的 id 字段一一对应，即：

团购套餐流水.promotion_coupon_id = 团购套餐定义.id。

通过这个字段可以知道：当前这条券使用的是哪一种团购套餐配置。

order_coupon_channel

类型：int，枚举。

观测值：1（181 条）、2（19 条）。

含义（推测）：

券渠道类型，例如：

1：渠道 A（某平台/来源）；

2：渠道 B（另一个平台/来源或内部券）。

具体对应的渠道需要看系统配置，但可以确定这是“券渠道枚举”。

3. 金额与时间相关字段（本表的核心）
3.1 金额字段（券抵扣金额）

ledger_unit_price

类型：float

观测值（枚举）：29.9, 39.9, 59.9, 69.9, 11.11, 128.0 等。

含义：对应台费的标准单价，单位元/小时（从数值来看是类似29.9/小时这种定价）。

作用：配合 ledger_count 用于计算这一条券在台费层面对应的金额（理论上应接近 = 单价 × 秒数/3600）。

ledger_count

类型：int（秒）

观测值：以 3600, 7200 为主，也有 6429, 3047, 3568 等不整小时的数值。

含义：按此次优惠实际计算的“核销秒数”。

结构观察：

大部分记录满足：ledger_count = promotion_seconds（即券定义的标准时长）。

少数记录中 ledger_count 与 promotion_seconds 略有差异（比如 3047 秒 vs 3600 秒），说明券实际核销到本次台费的时间略少于券 nominal 时长（可能是台上实际计费情况导致，不推断原因，只确认结构现象）。

ledger_amount

类型：float

观测值（部分）：48.0, 96.0, 116.0, 68.0, 58.0 等，少数为 2 位小数（如 49.09, 44.85）。

含义：本次券实际冲抵台费的金额。

结构关系：

绝大部分记录中，ledger_amount 与下方的 coupon_money 完全相等。

少量记录中出现小数（例如 49.09），说明在“单价×时间”的换算中产生了非整数金额，并以实际换算结果为准。

coupon_money

类型：float

观测值（枚举）：48.0, 68.0, 58.0, 96.0, 116.0, 288.0。

含义：本次核销时，这张券在门店侧对应的金额额度（“可抵扣金额”）。

结构关系：

按 promotion_coupon_id 聚合可以看到：同一种套餐对应固定的 coupon_money 和固定的 promotion_seconds，例如：

某套餐 ID → 全部记录 promotion_seconds = 3600 且 coupon_money = 48.0。

某套餐 ID → promotion_seconds = 7200 且 coupon_money = 96.0 或 116.0 等。

因此可以认为：每种团购套餐在实际使用时，对应一个固定的“抵扣时长 + 金额组合”，只是在定义表中 coupon_money 没有填，实际金额是在流水里体现。

promotion_seconds

类型：int（秒）

观测值（枚举）：3600, 7200, 14400。

含义：团购套餐定义的“标准时长”（券本身标称的可用时长）。

结构关系：

每一个 promotion_coupon_id 对应一个固定值：

部分套餐是 1 小时（3600）、部分是 2 小时（7200）、部分是 4 小时（14400）。

与“团购套餐定义”中的 duration 字段一致：两个表通过 promotion_coupon_id / id 关联后，可以验证 promotion_seconds = duration。

goodsOptionPrice

类型：float

观测：全部为 0.0。

含义（按命名推测）：商品规格价格，用于商品类促销分摊时使用。

当前在“团购套餐流水”中未被实际使用。

goods_promotion_money

类型：float

观测：全部为 0.0。

含义：本次券使用中，分摊到“商品”部分的促销金额。

当前数据中，所有团购券都只用于抵扣台费，没有用来抵扣商品，因此该字段为 0。

table_service_promotion_money

类型：float

观测：全部为 0.0。

含义：本次券使用中，分摊到“台费服务费”部分的促销金额。

当前样本中，促销金额都在 ledger_amount 中体现，该字段未单独拆出。

assistant_promotion_money

类型：float

观测：全部为 0.0。

含义：分摊到“助教服务”的促销金额。

当前场景下，团购券只与台费相关，未涉及助教的金额抵扣。

assistant_service_promotion_money

类型：float

观测：全部为 0.0。

含义：进一步细分助教服务的促销金额。

当前未使用。

reward_promotion_money

类型：float

观测：全部为 0.0。

含义：本次促销中，属于“奖励金/积分抵扣”的金额。

当前没有使用此维度的促销。

recharge_promotion_money

类型：float

观测：全部为 0.0。

含义：来自“充值类优惠”的分摊金额（例如储值赠送部分）。

当前所有数据为 0，但结构上已经预留了“多来源促销金额分摊”的能力。

小结（金额结构）：

核心金额在 ledger_amount 与 coupon_money 上，其他几个 xxx_promotion_money 字段为不同业务子模块预留，目前数据未用。

ledger_unit_price + ledger_count + promotion_seconds + coupon_money 四者构成了“券抵扣时长和金额”的结构关系，而不涉及任何盈利分析。

4. 券本身的标识字段

coupon_code

类型：string

观测：每条记录唯一，类似 "0107892475999" 这样的券码。

含义：团购券券码，核销时扫描/录入的字符串。

关联：

与平台验券记录表中的 coupon_code 完全一致，通过该字段可以串起“平台 → 核销 → 台费流水”全链路。

offer_type

类型：int，枚举。

观测值：全部为 1。

含义（推测）：优惠类型。

在券适用多个优惠方式的系统中，一般用来区分“满减/折扣/代金券/套餐券”等。

当前全部为 1，说明本门店使用的团购券全部属于同一类型（例如“套餐券”）。

5. 业务状态与标志字段

ledger_status

类型：int，枚举。

观测值：全部为 1。

含义（推测）：流水状态。

1：正常有效；

其他可能值（未在本数据中出现）可能表示“作废/撤销/未生效”等。

当前导出时，仅包含状态为 1 的正常使用记录。

is_single_order

类型：int，枚举。

观测值：1（199 条）、0（1 条）。

含义（推测）：是否单独作为一条订单行。

1：以独立条目方式进行结算（绝大部分记录如此）。

0：嵌在某种组合结算中（仅 1 条异常记录）。

is_delete

类型：int，枚举。

观测值：全部为 0。

含义：逻辑删除标志：

0：正常；

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

当前时间范围内没有删除过的团购套餐流水记录。

6. 操作员 / 销售员相关字段

operator_id

类型：int

观测：所有记录相同，均为某一员工 ID。

含义：执行本次核销/结算操作的 操作员 ID。

关联：可以与员工档案表中的 id 对应（当前导出中员工表未单独给出，但风格和其它表一致）。

operator_name

类型：string

观测：全部为 "收银员:郑丽珊"。

含义：操作员名称（包含角色说明），与 operator_id 对应的冗余展示字段。

salesman_user_id

类型：int

观测：全部为 0。

含义：营业员/业务员用户 ID。

当前所有团购套餐流水都未指定独立的营业员。

salesman_name

类型：string

观测：全部为空字符串 ""。

含义：营业员姓名。

salesman_role_id

类型：int

观测：全部为 0。

含义：营业员角色 ID。

sales_man_org_id

类型：int

观测：全部为 0。

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

以上 4 个销售相关字段在当前门店的团购套餐使用中都未启用，仅作为结构预留。

7. 其他字段

ledger_name

类型：string

示例："全天A区中八一小时", "B区桌球一小时", "中八、斯诺克包厢两小时" 等。

含义：台费侧关联的“团购项目名称”（记账名）。

结构上通常来源于团购套餐定义的 package_name，或由系统在创建活动时生成。

ledger_group_name

类型：string

观测：全部为空字符串。

含义（推测）：团购项目所属的“记账分组名称”（例如“团购台费”“团购包厢”等）。

当前门店未对团购项目做进一步分组。

create_time

类型：string（时间），格式 YYYY-MM-DD HH:MM:SS

含义：本条团购套餐使用流水创建时间（即券核销时间，或与结账时间接近）。

用法：可用于按时间范围过滤团购使用记录。

三、与其他 JSON 之间的结构关系（字段级）

仅从字段角度，团购套餐流水的关联关系可以浓缩为几条主线：

与团购套餐定义（20251110_043255_团购套餐.json）

关键字段：

promotion_coupon_id ↔ 团购套餐定义表的 id

由此可获得：

套餐名称 package_name

套餐标准时长 duration

套餐适用台区 table_area_name / tenant_table_area_id_list

每日可用时间段 start_clock/end_clock/add_start_clock/add_end_clock

同时本流水中的 promotion_seconds 与定义表中的 duration 在结构上是一致的。

与“订单/小票”相关表

通过以下字段建立关联：

order_trade_no：订单号 → 将这张券使用记录与同一笔订单中的台费、助教、商品等明细串联起来。

order_settle_id：结算单 ID → 对应小票详情、结账记录中的主键。

order_pay_id：支付记录 ID → 对应支付记录表中的流水（若非 0）。

这样可以从一个订单角度看到：台费、券抵扣、实付方式等整体结构。

与台桌维度 / 台区配置

table_id ↔ 台桌表 id：确定具体是哪一张桌。

tableAreaName ↔ 台区配置的区名。

tenant_table_area_id ↔ 团购套餐定义中的 tenant_table_area_id_list：

套餐定义允许使用的台区组合；

流水记录表示实际使用时所在的台区组合；

结构上可用于校验“是否在允许区域内使用”。

与平台券 / 验券记录表（未在本问题中展开）

coupon_code：平台券码 → 对应平台验券记录中的同名字段。

coupon_origin_id / order_coupon_id：

当前数据中二者完全相等，可视作平台券记录主键；

在平台券表中，一般会记录来源平台、原始套餐 ID、是否已使用等信息。

通过这两个字段，可以完整追踪券从“购买 → 核销 → 记账”整个过程。

与门店/租户维度

tenant_id、site_id、siteName：

与其它所有 JSON 一致，保证所有表可以在多门店部署下按品牌/门店维度统一过滤。

四、结构层面的重要线索（非盈利/非大数据分析）

从字段设计和数据现状，可以归纳出这些结构性信息：

这一张表是“券 → 台费”的专用流水表
通过字段命名（siteTableUseDetailsList、table_charge_seconds、ledger_unit_price 等）可以看出：

它专门描述“团购券/平台券使用在台费上的明细”；

与助教、商品、充值等促销虽然共享同一套促销拆账字段（xxx_promotion_money），但在当前数据中都为 0，说明本门店这类券只用于抵扣台费，不用于其它业务模块。

时长结构：区分“券时长”和“整台时长”

promotion_seconds：套餐定义的标准时长（券自身的时间权益）。

ledger_count：此次券实际核销的时间秒数（可能等于也可能略小于 promotion_seconds）。

table_charge_seconds：本次结算中该台整体计费秒数（可能大于券时长，因为有部分未被券覆盖）。

这种三层区分，为之后做“券覆盖率”、“券部分抵扣”、“超出部分正常计费”等逻辑提供了结构基础，但你要求不做数值分析，在此只保留结构描述。

金额结构：核心金额集中在两字段

ledger_amount：券在本次台费中实际抵扣的金额。

coupon_money：本次核销时该券对应的金额额度（几乎与 ledger_amount 一致）。

其他 assistant_promotion_money、goods_promotion_money、reward_promotion_money 等字段全部为 0，说明当前门店仅使用了最简单的“整券抵扣台费”的结构，但设计上已经支持更复杂的多业务分摊。

状态结构：启用/删除/有效在其他表中，而本表只保留“正常流水”

本表有 ledger_status / is_delete / is_single_order 等状态位：

ledger_status 全为 1，说明导出的都是正常状态的券使用记录；

is_delete 全为 0，说明没有被逻辑删除；

is_single_order 只有一条为 0，其余为 1，绝大部分券使用是以独立条目方式挂靠到订单上。

类似于团购套餐定义中的 is_enabled、effective_status，但本表只承接“已经发生”的流转结果，不承载定义层面的上下架逻辑。

渠道和活动维度已经结构化独立出来

promotion_activity_id、promotion_coupon_id、order_coupon_channel 三个字段，将券使用从三个维度刻画：

活动维度（来自哪个团购活动）；

套餐维度（使用的是哪个套餐定义）；

渠道维度（来自哪个平台/渠道）。

这种设计使得将来只要联上“活动表”“渠道配置表”，就可以从多维视角审视券的使用结构，而无需改动流水表结构本身。

整体来看，20251110_043302_团购套餐流水.json 是“团购套餐定义 + 台费流水 + 平台券核销”之间的中间桥接表，它用一条记录，把 某张券、某个套餐配置、某个订单、某张桌、某段时间、某个金额 绑在一起。
