# 台费优惠记录（GetTaiFeeAdjustList）

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

## 基本信息

| 属性 | 值 |
|------|-----|
| 接口路径 | `Site/GetTaiFeeAdjustList` |
| 完整 URL | `https://pc.ficoo.vip/apiprod/admin/v1/Site/GetTaiFeeAdjustList` |
| 请求方法 | `POST` |
| Content-Type | `application/json` |
| 鉴权方式 | Bearer Token（`Authorization` 头） |
| ODS 对应表 | `table_fee_discount_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） |

## 响应字段（共 20 个）

| # | 字段名 | 类型 | 示例值 |
|---|--------|------|--------|
| 1 | `tableProfile` | object | {'id': 2793020259897413, 'tenant_id': 2790683160709957, '... |
| 2 | `siteProfile` | object | {'id': 2790685415443269, 'org_id': 2790684179467077, 'sho... |
| 3 | `id` | int | 2957913441881989 |
| 4 | `adjust_type` | int | 1 |
| 5 | `applicant_id` | int | 2790687322443013 |
| 6 | `applicant_name` | string | '收银员:郑丽珊' |
| 7 | `create_time` | string | '2025-11-09 23:25:11' |
| 8 | `is_delete` | int | 0 |
| 9 | `ledger_amount` | float | 148.15 |
| 10 | `ledger_count` | int | 1 |
| 11 | `ledger_name` | string | '' |
| 12 | `ledger_status` | int | 1 |
| 13 | `operator_id` | int | 2790687322443013 |
| 14 | `operator_name` | string | '收银员:郑丽珊' |
| 15 | `order_settle_id` | int | 2957913171693253 |
| 16 | `order_trade_no` | int | 2957784612605829 |
| 17 | `site_id` | int | 2790685415443269 |
| 18 | `site_table_id` | int | 2793020259897413 |
| 19 | `tenant_id` | int | 2790683160709957 |
| 20 | `tenant_table_area_id` | int | 2791961347968901 |

## 详细字段分析

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

这个 JSON 是“台费打折 / 台费调整流水表”。每条记录不是“台的使用记录”，而是 在台费基础上追加的一条“金额调整记录”，用来记录某个订单、某张台在台费上的手工打折/减免金额。

二、记录级字段拆解与说明

以下字段说明全部针对 taiFeeAdjustInfos 里的单条记录。

为方便理解，先给出字段列表：

关联与主键类：id, order_trade_no, order_settle_id, tenant_id, site_id, site_table_id, tenant_table_area_id

台桌 / 门店快照：tableProfile, siteProfile, ledger_name

金额与数量：ledger_amount, ledger_count

申请 / 操作信息：adjust_type, applicant_id, applicant_name, operator_id, operator_name, create_time

状态标记：ledger_status, is_delete

1. 主键与订单关联字段

id

类型：int

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

含义：台费打折 / 调整流水主键 ID。

作用：在“台费调账表”中唯一标识一条折扣/调账操作。

order_trade_no

类型：int

唯一性：本文件中 200 条记录出现 195 个不同的值（有少数订单有多条调整记录）。

含义：订单交易号。

关联：

与 台费流水.json、助教流水.json、小票详情.json 中的同名字段一致，用于把这一条“台费调整”挂接到某笔订单上。

order_settle_id

类型：int

唯一性：本页记录中每条都有自己的 order_settle_id。

含义：结算单/小票 ID。

关联：

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

与其他消费流水（台费、助教、商品）中 order_settle_id 一致，作为同一次结账的统一主键。

tenant_id

类型：int

当前值：全部为同一个 ID（例如 2790683160709957）。

含义：租户/品牌 ID。

作用：标识记录属于哪一个商户（同一个“非球科技”租户）。

site_id

类型：int

当前值：全部为同一值（例如 2790685415443269）。

含义：门店 ID，本批数据全部为同一家门店（朗朗桌球）。

关联：

与 siteProfile.id 一致；

与其它 JSON 中的 site_id 一致，用于保证门店维度对齐。

site_table_id

类型：int

当前有约 50 个不同值。

含义：台桌 ID。

关联：

与 台费流水.json 中的 site_table_id 一致；

与“台桌列表”/台桌配置表中的 id 对应，表明是哪一张台发生了打折/调账。

tenant_table_area_id

类型：int

当前有约 13 个不同值。

含义：租户维度的“台桌区域 ID”。

关联：

与台桌区域配置表对应，帮助从区域维度分析打折分布（结构上可用）。

2. 台桌与门店快照字段

tableProfile

类型：object（字典）

键包括：

id：台桌 ID（与 site_table_id 对应）

tenant_id：租户 ID

tenant_name：租户名称（当前为空字符串）

siteName：站点/门店名（当前为空字符串，门店名在 siteProfile.shop_name 中）

table_name：台号（如 "S1", "VIP1", "A10" 等）

site_table_area_id：门店内区域 ID

site_table_area_name：区域名（如 "斯诺克区", "VIP包厢", "A区" 等）

area_type_id：区域类型 ID（当前为 0，未使用）

table_price：台的基础单价（当前为 0.0，不在这里维护）

ewelink_client_id：智能硬件 ID（当前为空）

charge_free：是否免单标识（当前为 0）

含义：折扣发生时，对应台桌的配置信息快照。

siteProfile

类型：object

内容与其他文件保持一致，包括：

门店 ID、组织 ID、门店名称、门店头像、电话、地址、经纬度、营业状态、标签等。

含义：门店信息快照，用于报表时直接读取，无需再联门店档案。

ledger_name

类型：string

当前观测：全部为空字符串（200 条记录所有值均为 ''）。

含义（推测）：

设计上应该用于记录“调账项目名称”或“打折原因描述”（例如某种优惠规则名称），但当前门店并未使用该字段。

结论：结构上是预留字段，目前这家门店的台费打折没有填写名称，信息集中在金额层面。

3. 金额与数量字段

ledger_amount

类型：float

当前记录：共有 182 个不同的数值，典型值如：

96.0（5 条）

120.0（4 条）

75.33、144.0、8.18、35.51、69.0、100.0 等

含义（关键点）：

通过与 台费流水.json 做对比，可以明确：

对于某个 order_trade_no，在台费流水中有：

ledger_amount = 原始应收台费金额；

adjust_amount = 台费调账金额；

在台费打折表中：

对应同一个 order_trade_no 的 ledger_amount = 台费流水中的 adjust_amount。

例如（真实数据）：

某订单：

台费流水：ledger_amount = 203.44, adjust_amount = 101.72, real_table_charge_money = 101.72

台费打折：ledger_amount = 101.72

说明：这一条台费打折记录的金额，正是该订单在台费上被减免/调账的金额。

结论：
在本表中，ledger_amount 表示 “台费调账/减免金额”，不是使用时长对应的原价，而是“被调整掉”的那一部分金额。

ledger_count

类型：int

当前观测：全部为 1（200 条所有记录）。

含义：

这里不是“秒数”，而是“调整次数/条数”的量化，目前固定为 1，表示“一次调账事件”。

即：本表中的“计数”是按条计，不是按时间计。

与台费流水中的 ledger_count（计费秒数）完全不同含义。

4. 申请与操作相关字段

adjust_type

类型：int，枚举字段。

当前观测：全部为 1。

含义（根据文件含义 + 命名 + 数据）：

文件名是“台费打折”，字段名为“调整类型”，当前所有记录都是 1，即“台费打折/台费减免”这一种调整类型。

推测枚举含义可能类似：

1：台费打折/减免；

其他值（未出现）：可能用于“台费转移”、“误操作恢复”等其它调整类型。

结论：
当前门店仅使用了 adjust_type = 1 这一种类型，对应台费打折/减免；其他类型未在本数据出现。

applicant_id

类型：int

当前观测：全部为同一个 ID，例如 2790687322443013。

含义：打折/调账申请人 ID。

作用：记录谁发起了这次台费调整。
本时段内所有调整均由同一位员工发起。

applicant_name

类型：string

当前观测：全部为同一个字符串，如："收银员:郑丽珊"。

含义：申请人姓名（带角色描述），为 applicant_id 的冗余显示字段。

operator_id

类型：int

当前观测：全部与 applicant_id 相同。

含义：实际执行调账操作的操作员 ID。

说明：这段时间内，“申请人”和“操作员”是同一个人。

operator_name

类型：string

当前观测：全部与 applicant_name 相同。

含义：操作员姓名。

create_time

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

唯一性：200 条记录中有 171 个不同时间点，有些时间点有多条记录（比如同一时刻对不同台/订单进行多次调整）。

含义：台费调整记录的创建时间，即打折操作被执行的时间戳。

说明：与台费流水中的 create_time（结算时间）相互配合，可以还原调整发生于结账之前还是之后。

5. 状态与删除标记

ledger_status

类型：int，枚举字段。

当前观测：

值为 1 的记录：195 条

值为 0 的记录：5 条

结合数据特征：

某些订单有多条打折记录，其中：

旧记录 ledger_status = 0

最新一条 ledger_status = 1

同一 order_trade_no 下，ledger_status = 0 的记录在台费流水的 adjust_amount 中不再生效，只保留 ledger_status = 1 对应的金额。

推测枚举含义：

1：生效调整（当前有效的台费打折 / 调账记录）；

0：已失效/被覆盖的调整记录（历史记录、已撤销或被后续调账覆盖）。

结论：
ledger_status 是“调整记录自身的状态”，用于区分历史打折记录和当前有效的那条。

is_delete

类型：int，枚举字段。

当前观测：全部为 0。

含义：逻辑删除标志：

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

1：已逻辑删除（后台标记删除）。

当前时间段没有逻辑删除的调整记录，但表结构已经预留这个标志。

三、与其它 JSON 的关联关系（从结构与字段角度）
1. 与台费流水（20251110_035011_台费流水.json）

关联字段：

order_trade_no：两表共有

order_settle_id：两表共有

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

site_table_id：指向同一张台

结构关系：

对于某个订单 order_trade_no = X：

台费流水表（siteTableUseDetailsList）里有一条记录：

ledger_amount：原始应收台费金额；

adjust_amount：在这条台费上调账/减免的金额；

real_table_charge_money：顾客实际付的台费（不含券承担部分）。

台费打折表（taiFeeAdjustInfos）里有一条或多条记录：

ledger_amount = 对应台费流水中的 adjust_amount（生效那条折扣）。

ledger_status = 1 的记录是“当前有效”的调账金额；0 的记录是旧的、不再生效的历史打折记录。

用法（结构角度）：

台费流水给出 时长 + 原始台费 + 各种金额拆分（含 adjust_amount）；

台费打折表给出 是谁、何时、以哪种类型（adjust_type）发起了这笔调账，调了多少金额；

两表通过 order_trade_no（或 order_settle_id + site_table_id）做一对一 / 一对多关系，从而完整还原“这笔台费折扣从哪来”的结构链条。

2. 与台桌配置 / 区域配置

site_table_id ↔ 台桌配置表的 id；

tableProfile.table_name ↔ 台桌配置表中的 table_name；

tableProfile.site_table_area_id、tableProfile.site_table_area_name ↔ 门店台桌区域维表；

tenant_table_area_id ↔ 租户层面的区域维表。

结构线索：

台费打折可以按“区域”和“台号”两个维度归集（结构上可行），例如统计“斯诺克区”发生过多少次台费调整操作，这里先停留在结构层面，不做数值统计。

3. 与门店信息（siteProfile）

siteProfile.id ↔ site_id

内含门店名称、地址、经纬度等，与其它 JSON 里的 siteProfile 一致。

结构线索：

若多门店数据放在一起，siteProfile 冗余在每条记录中，可以直接按门店维度进行分组，而无需再去门店档案表查名称。

4. 与员工/账号体系

applicant_id / operator_id 与账号体系中的用户 ID 对应（与助教账号 user_id 属于同一 ID 空间）。

applicant_name / operator_name 为相应的姓名快照。

结构线索：

后续可以按员工维度统计“某收银员进行了多少次台费打折、调整金额是多少”，这是结构上天然支持的（本门店当前全部折扣都由同一人发起）。

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

从字段设计可以看出：

taiFeeAdjustInfos 是专门用于“台费调账/打折”的事实表

它不记录时长，只记录金额和操作人；

与台费流水表形成一对一/一对多的“主表+子操作表”关系；

通过 order_trade_no + site_table_id 等字段和台费流水紧密联动。

金额语义与台费流水的“adjust_amount”强绑定

台费流水中 adjust_amount 字段本身只是一个“结果值”；

台费打折表里，用 ledger_amount 再详细记录每一次调整，且补充了操作人、操作时间、状态（ledger_status）、类型（adjust_type）等信息。

也就是说：台费流水里的 adjust_amount 实际上是台费打折表中 ledger_amount 的汇总结果（在结构上是一致的）。

状态字段把“历史折扣记录”和“当前有效折扣”分离

通过 ledger_status 区分有效和失效的调整记录，允许同一订单多次修改折扣；

表明系统设计上支持“反悔/覆盖折扣”的业务流程。

adjust_type 为将来扩展预留空间

虽然当前所有记录都是 1（台费打折），但从命名看，可以扩展到其它类型调整，如台费转移、误操作修正等。

结构上已经清晰区分“调整类型”，便于将来拆分不同业务路径。

ledger_count 固定为 1，清晰地把“台费使用时长”和“台费调整次数”分离

台费使用时长在台费流水表中、单位是秒；

台费打折只管“第几次调整”，不和时间绑定，避免混淆。

五、小结（本文件的结构重点）

20251110_035908_台费打折.json 记录的是 台费层面的“打折 / 调账”流水，不是台的使用流水。

每条记录核心信息包括：

调账金额：ledger_amount（即台费流水中的 adjust_amount）

订单关联：order_trade_no、order_settle_id

台桌定位：site_table_id + tableProfile.table_name

区域维度：tenant_table_area_id + tableProfile.site_table_area_name

操作人维度：applicant_id/applicant_name、operator_id/operator_name

时间维度：create_time

状态与类型：ledger_status（有效/失效）、adjust_type（当前仅为台费打折）

从结构关系来看，它与 台费流水 做的是金额层面的一一校对，通过 adjust_amount ↔ ledger_amount 的关系，把“原始台费金额”和“实际负担方（顾客/券/内部调账）”这条链路闭合起来；同时也为后续从“员工/时间/区域”维度审计台费打折行为提供了完整的结构基础，而不涉及任何盈利或经营分析。
