# 台桌主数据（GetSiteTables）

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

## 基本信息

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

## 请求参数

| 参数名 | 类型 | 示例值 | 说明 |
|--------|------|--------|------|
| `showStatus` | int | `0` | 展示状态（0=全部） |
| `virtualTableType` | int | `-1` | 虚拟桌类型（-1=全部） |
| `page` | int | `1` | 页码（从 1 开始） |
| `limit` | int | `100` | 每页条数（最大 100） |

## 响应字段（共 25 个）

| # | 字段名 | 类型 | 示例值 |
|---|--------|------|--------|
| 1 | `id` | int | 2791964216463493 |
| 2 | `audit_status` | int | 2 |
| 3 | `charge_free` | int | 0 |
| 4 | `self_table` | int | 1 |
| 5 | `create_time` | string | '2025-07-15 17:52:54' |
| 6 | `is_rest_area` | int | 0 |
| 7 | `light_status` | int | 2 |
| 8 | `show_status` | int | 1 |
| 9 | `site_id` | int | 2790685415443269 |
| 10 | `site_table_area_id` | int | 2791963794329671 |
| 11 | `table_cloth_use_time` | int | 1863727 |
| 12 | `table_cloth_use_Cycle` | int | 0 |
| 13 | `virtual_table` | int | 0 |
| 14 | `table_name` | string | 'A1' |
| 15 | `table_price` | float | 0.0 |
| 16 | `table_status` | int | 1 |
| 17 | `areaName` | string | 'A区' |
| 18 | `siteName` | string | '朗朗桌球' |
| 19 | `tableStatusName` | string | '空闲中' |
| 20 | `appletQrCodeUrl` | string | 'https://pc-we.ficoo.vip/rootwww/prodwx38a48dd2bc3c1642?e... |
| 21 | `only_allow_groupon` | int | 2 |
| 22 | `delay_lights_time` | int | 0 |
| 23 | `order_delay_time` | int | 0 |
| 24 | `temporary_light_second` | int | 0 |
| 25 | `is_online_reservation` | int | 2 |

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

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

| 字段名 | 类型 |
|--------|------|
| `order_id` | int |

## 详细字段分析

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

结论：
台桌列表.json 是典型的 “台桌维表（维度表）”，为后续所有流水（台费、助教、打折等）提供 site_table_id → 台号/区域/配置 的主数据。

二、记录级字段明细（逐字段）

以下字段均针对 siteTables 数组中的单条记录。

1. 主键 / 门店 / 区域基础字段

id

类型：int

唯一性：71 条记录各不相同。

含义：台桌主键 ID。

关联：

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

与 助教流水.json 中的 site_table_id 一致；

与 台费打折.json 中 tableProfile.id 一致。

作用：这是“台”的全系统唯一标识，是各类流水表引用的核心外键。

site_id

类型：int

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

含义：门店 ID。

关联：

与各个流水表、siteProfile.id 一致，本数据全部属于“朗朗桌球”这一家门店。

siteName

类型：string

当前值：全部为 "朗朗桌球"。

含义：门店名称快照，冗余字段，配合 site_id 使用。

site_table_area_id

类型：int

唯一性：14 个不同值。

含义：门店维度的“台桌区域 ID”。

关系：

同一个 site_table_area_id 对应一个唯一的 areaName（1:1）。

在其它 JSON（例如台费流水里的 tableProfile.site_table_area_id）中也存在同样的 ID，用于在门店内统一识别区域。

areaName

类型：string

枚举（本门店实际值）：

"A区"（18 台）

"B区"（15 台）

"补时长"（7 台）

"C区"（6 台）

"麻将房"（5 台）

"VIP包厢"（4 台）

"斯诺克区"（4 台）

"K包"（3 台）

"666", "M7", "k包活动区"（各 2 台）

"TV台", "M8", "发财"（各 1 台）

含义：区域名称，用于前台展示和区域维度管理。

结构特征：

site_table_area_id 与 areaName 一一对应；

有些区域名（如“补时长”“666”）本身就带业务含义（补时专用、特殊台）。

2. 台桌自身属性字段

table_name

类型：string

唯一性：71 条记录 71 个不同值。

示例："A1" ~ "A18", "B1" ~ "B6", "S1" ~ "S4", "VIP1", "VIP2", "VIP3", "VIP5", "TV台", "M7", "M8", "666", "888", "发财", "常乐", "幸会(纯k)", "董事办", "补时长"、"补时长2"…"补时长7"，"大包", "小包" 等。

含义：台号/台名称，用于前台操作界面展示，也出现在小票和各种流水中的 ledger_name 或 tableName 字段。

table_price

类型：float

当前观测：全部为 0.0。

含义（结构角度）：

设计上应为“台的基础单价”字段（例如按小时或按局单价）；

本门店实际上没有在台列表中配置单价，台费单价来自别处（如计费策略、时段价格表），因此这里统一为 0。

结论：这是一个“预留但未在本门店使用”的价格字段，真实计费规则在其他地方。

virtual_table

类型：int，枚举。

当前值：全部为 0。

含义（推测）：

0：物理台（实体存在的桌）；

1：虚拟台（组合计费或逻辑台，如合台、补钟虚拟台等）。

说明：尽管存在“补时长*”这类功能性台，但字段上仍标记为 0，说明系统是通过“特殊命名 + 台费计费逻辑”来实现补时，而没有使用 virtual_table=1。

self_table

类型：int，枚举。

当前值：全部为 1。

含义（推测）：

1：“本门店自有台”，非共享或外部配置；

0：可能预留用于联营/非自有台等场景，本门店未出现。

结构意义：标记台桌归属类型，未来可用于区分自营台与其他来源台。

is_rest_area

类型：int，枚举。

当前值：全部为 0。

含义（推测）：

0：正常计费区域；

1：休息区，可能不参与计费或有不同计费逻辑。

本门店未使用此区分。

3. 状态与展示控制相关字段

table_status

类型：int，枚举。

当前分布：

1：64 条，对应 tableStatusName = "空闲中"

2：2 条，对应 tableStatusName = "使用中"

3：5 条，对应 tableStatusName = "暂停中"

明确映射关系：

1 → 空闲中

2 → 使用中

3 → 暂停中

含义：台当前运行状态，真实反映某一时刻台的占用/暂停情况。

tableStatusName

类型：string，枚举。

当前值：

"空闲中"

"使用中"

"暂停中"

含义：table_status 的中文名称，仅为展示用途。

light_status

类型：int，枚举。

当前分布：

2：70 条

1：1 条

含义（结合命名推断）：

该字段是台灯/灯光状态开关位：

1：开灯/可控；

2：关灯/关闭状态。

当前导出时刻大部分台灯处于关闭状态（2），只有一张台为 1。

该字段与智能硬件（开关台灯）联动使用。

delay_lights_time

类型：int

当前值：全部为 0。

含义（推测）：台灯熄灭延迟时间（单位多半是秒或分钟），用于结账后延时关灯。

本门店未启用延迟关灯功能（全部为 0）。

temporary_light_second

类型：int

当前值：全部为 0。

含义（推测）：临时点灯时长（秒），例如手动临时开灯一段时间。

本门店未使用。

show_status

类型：int，枚举。

当前分布：

1：68 条，台名例如 "A1"..."A18", "B1"...，普通台以及多数补时长台；

2：3 条，台名为 "大包", "大包麻将房", "小包"。

含义（推测）：

1：正常在前台“开台列表”中展示；

2：不在常规开台列表展示，仅用于特殊用途（比如线上预约专用、单独套餐房间等）。

与 is_online_reservation 有明显配合（见下）。

audit_status

类型：int，枚举。

当前值：全部为 2。

含义（结合命名惯例）：

2：已审核/已启用；

其他值（未出现）可能用于“待审核/驳回”等状态。

当前门店所有台桌配置均处于已审核状态。

charge_free

类型：int，枚举。

当前值：全部为 0。

含义（推测）：

0：正常计费；

1：免单/常免台（不计费或特殊场景）。

本门店没有配置免单台。

show_status 已说明，不再赘述。

order_delay_time

类型：int

当前值：全部为 0。

含义（推测）：订单层面允许的“自动延时时长”（例如到点后自动延长多少时间继续计费）。

本门店未使用此功能。

4. 线上预约 / 团购限制字段

is_online_reservation

类型：int，枚举。

当前分布：

2：69 条

1：2 条（台名为 "大包", "小包"）

含义（结合值分布推断）：

1：允许线上预约（可在小程序/线上平台预约这张台）；

2：不允许线上预约。

结构特征：

只有“大包”“小包”被标记为可线上预约，且它们的 show_status = 2，说明这两张台可能主要通过线上预约，而非普通前台开台列表。

only_allow_groupon

类型：int，枚举。

当前值：全部为 2。

含义（结合命名推断）：

1：仅允许团购/券预约使用（团购专用台）；

2：不限制，只要满足其他条件即可使用。

当前门店没有设置“仅限团购使用”的台桌，所有台都标记为 2。

appletQrCodeUrl

类型：string

特征：

每张台一个独立的 URL，结构类似：
https://pc-we.ficoo.vip/rootwww/prodwx38a48dd2bc3c1642?env=prod&type=1&id=<table_id>&siteId=<site_id>

id 参数就是当前台的 id，siteId 为门店 ID。

含义：小程序二维码 URL。
一般用于：

打印二维码贴在台上，顾客扫码可呼叫服务、查看账单或发起线上预约；

员工也可通过小程序快捷开台。

5. 台呢使用相关字段

table_cloth_use_time

类型：int

当前分布：

共有 69 个不同值；

范围：0 ~ 2137840。

含义（结合命名和数值特征）：

台呢使用累计时长，单位极大概率为“秒”：

例如 1863727 秒 ≈ 517 小时，符合“台呢累计使用时长”的量级。

用于提醒更换/保养台呢。

结构上：这是一个不断累加的计数器，每次开台会增长对应秒数。

table_cloth_use_Cycle

类型：int

当前值：全部为 0。

含义（推测）：

台呢使用周期阈值，例如达到某个秒数后提醒更换；

0 表示未配置该阈值。

本门店尚未设置自动提醒周期，只记录使用时长。

6. 其他通用字段

create_time

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

当前数据：

71 条记录，有 44 个不同的时间点；

多数台在 2025-07-16 这一时段集中创建，少数在 2025-07-15/2025-10-31。

含义：台桌配置的创建时间或最近一次创建/复制时间。

三、与其它 JSON 的字段级关联关系（结构视角）

仅从字段结构和命名角度说明，不做数值层面的比对。

1. 与《台费流水.json》（台费使用记录）

关键关联字段：

台桌列表.id ↔ 台费流水中的 site_table_id

台桌列表.table_name ↔ 台费流水中的 ledger_name（或 tableName）

台桌列表.site_table_area_id ↔ 台费流水里的 tableProfile.site_table_area_id

台桌列表.areaName ↔ 台费流水里的 tableProfile.site_table_area_name

site_id、tenant_id 在两表保持一致。

结构关系：

台桌列表 提供静态的“台属性/区域属性/可用性配置”；

台费流水 提供动态的“台使用时段 + 台费金额拆分”；

两者通过 site_table_id 构成事实表–维度表关系。

2. 与《台费打折.json》（台费调账/打折记录）

关键关联字段：

台桌列表.id ↔ 台费打折中的 site_table_id（或 tableProfile.id）

table_name ↔ tableProfile.table_name

site_table_area_id / areaName ↔ tableProfile.site_table_area_id / site_table_area_name

结构关系：

台费打折记录中的 tableProfile 实际上就是对“台桌列表”中某一行台的快照；

所有与台相关的打折，都可以回溯到 id 对应的台配置记录。

3. 与《助教流水.json》

关键关联字段：

台桌列表.id ↔ 助教流水中的 site_table_id

table_name ↔ 助教流水中的 tableName

site_id、tenant_id 保持一致。

结构关系：

助教服务是附着在具体台或包厢上的；

助教流水 中记录“某助教在某张台上服务的时段和金额”，通过 site_table_id 与台桌配置联动；

可以从结构上做到“按台/按区域统计助教服务情况”。

4. 与其它门店维度类 JSON（如门店信息等）

site_id、siteName 与各个 JSON 中的 siteProfile.id、shop_name一致；

台桌列表 是门店维度下的子实体表，与“门店档案”存在 1:N 关系（一个门店多张台）。

四、从结构关系角度额外能看出的重要线索

台桌列表在整个模型中是核心“维度表”

所有与“台”相关的流水（台费、助教、台费打折等）都通过 site_table_id 引用这里；

字段设计同时覆盖了：基础属性（name/area）、运营状态（table_status）、显示控制（show_status）、线上能力（is_online_reservation、only_allow_groupon）、硬件联动（light_status 与灯控系统）、耗材寿命管理（table_cloth_use_time）。

补时长相关的台是通过“命名 + 区域 + 计费规则”实现的，不是通过 virtual_table 字段

有一组台名字直接叫“补时长*（补时长、补时长2...补时长7）”，区域名也叫“补时长”；

但 virtual_table=0、charge_free=0、self_table=1，说明系统把它们当成普通台，只是在业务逻辑层面赋予“补时台”含义（结构上可注意这一点，用于后续建模时区分）。

线上预约房间与普通台桌在结构上的差异由 show_status + is_online_reservation 组合表达

普通台：show_status=1、is_online_reservation=2；

大/小包：show_status=2、is_online_reservation=1；

结构上的含义是：

普通台：主要由现场前台打开使用，不对外提供线上预约；

大/小包：主要通过线上预约入口使用，不在常规“开台列表”出现。

这在后续做结构分析或建模时，可以用两个字段组合出“台的业务角色”。

所有台处于 audit_status=2，说明当前配置已经“生效”

若未来有台处于 audit_status≠2 的情况，这将意味着该台尚未投入使用；

台费流水中不会引用未审核的台，这点从结构上可以推断出系统的约束逻辑。

台呢使用字段为“维护维度”提供结构钩子

table_cloth_use_time（累计秒数）+ table_cloth_use_Cycle（阈值）构成一个完整的“耗材寿命管理”结构；

本门店仅记录累积使用时长，还未设置“提醒更换周期”，但结构已经预留完备。

价格字段在台列表中未启用，说明计费策略是“另起表管理”

table_price=0 且台费实际单价在 台费流水.json 的 ledger_unit_price 中体现；

这说明系统采用：
“台的物理属性 + 区域属性”在本表；
“实时价格/活动价/时段价”在独立计费策略表；
台费流水则记录计费策略的执行结果（ledger_unit_price、ledger_amount）。

这一点在结构设计上非常明确，对后续做模型时需要把“台列表”和“计价策略”分开看。

综上，20251110_043250_台桌列表.json 从结构上完整刻画了门店所有台桌的静态属性和部分实时状态，并通过 id 字段在全系统范围内作为“台”的唯一主键，被台费、助教、打折等多类流水反复引用。它是整个非球科技门店模型中的核心基础维表之一。