712 lines
19 KiB
Markdown
712 lines
19 KiB
Markdown
# 退款流水（GetRefundPayLogList）
|
||
|
||
> 自动生成于 2026-02-13 | 数据来源：实时 API
|
||
|
||
## 基本信息
|
||
|
||
| 属性 | 值 |
|
||
|------|-----|
|
||
| 接口路径 | `Order/GetRefundPayLogList` |
|
||
| 完整 URL | `https://pc.ficoo.vip/apiprod/admin/v1/Order/GetRefundPayLogList` |
|
||
| 请求方法 | `POST` |
|
||
| Content-Type | `application/json` |
|
||
| 鉴权方式 | Bearer Token（`Authorization` 头） |
|
||
| ODS 对应表 | `refund_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 |
|
||
| `page` | int | `1` | 页码（从 1 开始） |
|
||
| `limit` | int | `100` | 每页条数（最大 100） |
|
||
|
||
## 响应字段（共 32 个）
|
||
|
||
| # | 字段名 | 类型 | 示例值 |
|
||
|---|--------|------|--------|
|
||
| 1 | `tenantName` | string | '朗朗桌球' |
|
||
| 2 | `siteProfile` | object | {'id': 2790685415443269, 'org_id': 2790684179467077, 'sho... |
|
||
| 3 | `id` | int | 3089577798995141 |
|
||
| 4 | `site_id` | int | 2790685415443269 |
|
||
| 5 | `tenant_id` | int | 2790683160709957 |
|
||
| 6 | `pay_sn` | int | 0 |
|
||
| 7 | `pay_amount` | float | -8.0 |
|
||
| 8 | `pay_status` | int | 2 |
|
||
| 9 | `pay_time` | string | '2026-02-10 23:41:06' |
|
||
| 10 | `create_time` | string | '2026-02-10 23:41:06' |
|
||
| 11 | `relate_type` | int | 1 |
|
||
| 12 | `relate_id` | int | 3089548319804869 |
|
||
| 13 | `is_revoke` | int | 0 |
|
||
| 14 | `is_delete` | int | 0 |
|
||
| 15 | `online_pay_channel` | int | 0 |
|
||
| 16 | `payment_method` | int | 4 |
|
||
| 17 | `balance_frozen_amount` | float | 0.0 |
|
||
| 18 | `card_frozen_amount` | float | 0.0 |
|
||
| 19 | `member_id` | int | 0 |
|
||
| 20 | `member_card_id` | int | 0 |
|
||
| 21 | `round_amount` | float | 0.0 |
|
||
| 22 | `online_pay_type` | int | 0 |
|
||
| 23 | `action_type` | int | 2 |
|
||
| 24 | `refund_amount` | float | 0.0 |
|
||
| 25 | `cashier_point_id` | int | 0 |
|
||
| 26 | `operator_id` | int | 0 |
|
||
| 27 | `pay_terminal` | int | 1 |
|
||
| 28 | `pay_config_id` | int | 0 |
|
||
| 29 | `channel_payer_id` | string | '' |
|
||
| 30 | `channel_pay_no` | string | '' |
|
||
| 31 | `check_status` | int | 1 |
|
||
| 32 | `channel_fee` | float | 0.0 |
|
||
|
||
## 详细字段分析
|
||
|
||
> 以下内容迁移自旧版 `refund_transactions-Analysis.md`，包含字段的业务含义、枚举值、跨表关联等详细说明。
|
||
|
||
2. 记录内容类型（这份 JSON 实际记录的是什么）
|
||
|
||
从字段组合和数值特征看，每条记录代表：
|
||
|
||
“一笔已发生的退款支付流水（资金层面的退款交易）”
|
||
|
||
特点：
|
||
|
||
pay_amount 全为负数（例如 -12.0, -44000.0, -3000.0），很明显是“钱从店里流出”的方向。
|
||
|
||
pay_status 全为 2，结合支付记录推测是“退款/完成状态”（至少表示“已处理完成”）。
|
||
|
||
action_type 全为 2，极大概率是“退款动作类型”的枚举。
|
||
|
||
relate_type 只出现 2 与 5，对应两类不同业务：一种是“消费类”，一种是“充值/储值类”（具体含义依赖系统配置，但肯定是区分不同业务来源）。
|
||
|
||
这份“退款记录”是 资金维度 的退款流水，不是“业务维度”的退款单（比如没记录退款原因、操作备注等）。业务上的退款原因应从对应的订单、充值记录或其他业务表中去追踪。
|
||
|
||
二、字段逐一说明（含数据类型 & 枚举推断）
|
||
|
||
下面按功能分组，对每个字段说明其含义、类型，是否枚举，以及这些记录中实际出现的取值。
|
||
|
||
1. 门店 / 租户维度字段
|
||
tenantName
|
||
|
||
类型：string
|
||
|
||
示例："朗朗桌球"
|
||
|
||
含义：租户（商户）名称。
|
||
|
||
特点：本文件中固定为“朗朗桌球”，完全冗余于 siteProfile.shop_name。
|
||
|
||
作用：方便直接在流水中看到店名，无需再查门店档案。
|
||
|
||
tenant_id
|
||
|
||
类型：int
|
||
|
||
示例：2790683160709957
|
||
|
||
含义：租户/品牌 ID，全系统维度标识该商户。
|
||
|
||
特点：本文件中所有记录相同。
|
||
|
||
作用：
|
||
|
||
作为所有门店数据的“租户分区键”；
|
||
|
||
与其他 JSON 中同名字段一致，用来确认“同一商户”。
|
||
|
||
site_id
|
||
|
||
类型：int
|
||
|
||
示例：2790685415443269
|
||
|
||
含义：门店 ID。
|
||
|
||
特点：本文件中所有记录相同（单门店）。
|
||
|
||
作用：
|
||
|
||
关联其他数据表中同一门店的数据；
|
||
|
||
与 siteProfile.id 一致，是 siteProfile 的主键。
|
||
|
||
siteProfile
|
||
|
||
类型：object
|
||
|
||
含义：门店信息快照，结构与其他 JSON 中的 siteProfile 完全一致。包含字段包括但不限于：
|
||
|
||
id：门店 ID（= site_id）；
|
||
|
||
shop_name：店名；
|
||
|
||
full_address / address：地址；
|
||
|
||
longitude / latitude：经纬度；
|
||
|
||
business_tel：电话；
|
||
|
||
一系列门店配置项（灯控、考勤、营业状态等）。
|
||
|
||
作用：
|
||
|
||
为每条退款记录附带一份当时的门店元信息；
|
||
|
||
提供冗余信息，避免联表查询门店档案。
|
||
|
||
2. 退款流水主键与关联业务字段
|
||
id
|
||
|
||
类型：int
|
||
|
||
示例：2955202296416389
|
||
|
||
含义：本条 退款流水 的唯一 ID。
|
||
|
||
特点：
|
||
|
||
每条记录一个不同的长整型 ID，疑似雪花 ID 或类似分布式 ID。
|
||
|
||
作用：作为退款记录表主键，内部检索用。
|
||
|
||
relate_type
|
||
|
||
类型：int（枚举）
|
||
|
||
当前取值：{2, 5}
|
||
|
||
含义：本退款对应的“业务类型”。
|
||
|
||
结合支付记录的 relate_type 推测：
|
||
|
||
1（在支付记录中存在）：某类订单支付（可能是结账单支付）。
|
||
|
||
2：另一类业务，比如“台费/商品类消费单”或“综合订单”；在退款记录中有多条。
|
||
|
||
5：通常用来标记“储值/充值类业务”，这里的几条金额很大，形态上很像“退充值款”。
|
||
|
||
结构作用：
|
||
|
||
不直接指向某张表，而是先告知“这是哪种业务”，再配合 relate_id 确定具体业务记录。
|
||
|
||
relate_id
|
||
|
||
类型：int
|
||
|
||
示例：2948246513454661
|
||
|
||
含义：本次退款关联的业务 ID。
|
||
|
||
对于 relate_type = 2：应该对应某个订单/结算的主键；
|
||
|
||
对于 relate_type = 5：应该对应某条充值记录或储值业务记录的主键。
|
||
|
||
特点：
|
||
|
||
同一个 relate_id 可能对应多条退款流水（例如先退 88.33，又退 0.67，对应两个不同撤销动作，都关联到同一 relate_id）。
|
||
|
||
与其他 JSON 的关系：
|
||
|
||
在“支付记录”中也有 relate_type + relate_id 组合，含义一致：指向业务实体；
|
||
|
||
本文件里的退款流水和“支付记录”是通过“共同指向同一业务实体”来间接关联，而不是直接指向支付记录。
|
||
|
||
3. 时间字段
|
||
create_time
|
||
|
||
类型：string，格式为 "YYYY-MM-DD HH:MM:SS"
|
||
|
||
示例："2025-11-03 15:36:19"
|
||
|
||
含义：本条退款流水在系统内创建时间。
|
||
|
||
特点：
|
||
|
||
当前数据中，create_time 与 pay_time 完全相同，说明系统在退款发生时立刻生成流水记录。
|
||
|
||
如果未来有“申请退款-审核-执行”流程，create_time 有可能偏早。
|
||
|
||
pay_time
|
||
|
||
类型：string，格式同上
|
||
|
||
示例："2025-11-03 15:36:19"
|
||
|
||
含义：退款在支付渠道层面实际发生的时间。
|
||
|
||
特点：
|
||
|
||
当前数据中与 create_time 一致，可以视为“退款完成时间”。
|
||
|
||
结构提示：
|
||
|
||
保留 create_time 和 pay_time 两个字段，说明系统设计上区分“记录生成时间”与“渠道交易时间”。如果引入异步处理，二者可能就会出现差异。
|
||
|
||
4. 金额相关字段
|
||
pay_amount
|
||
|
||
类型：float
|
||
|
||
示例：-12.0, -44000.0, -3000.0, -0.67 等
|
||
|
||
含义：本次退款的 资金变动金额。
|
||
|
||
特征很重要：
|
||
|
||
全部为负数，绝对值就是退款金额。
|
||
|
||
表示“从门店账户流出的金额”（相对于支付记录中的正数进账）。
|
||
|
||
结构意义：
|
||
|
||
这份“退款记录.json”在设计上没有专门用 refund_amount 存实际退款额，而是直接用 pay_amount < 0 表示退款金额大小。
|
||
|
||
这点对之后做数据抽取/ETL 很重要：判断退款金额只看 pay_amount 的负数；refund_amount 字段在当前实现中并未使用。
|
||
|
||
refund_amount
|
||
|
||
类型：float
|
||
|
||
当前全部为：0.0
|
||
|
||
含义（推测）：
|
||
|
||
设计上本应显示“实际退款金额”（正数），与 pay_amount 配合使用；
|
||
|
||
但在目前实现里，系统只用了 pay_amount 表示金额，并没有填充这个字段。
|
||
|
||
在当前数据中的状态：
|
||
|
||
可以视为“保留字段/未启用”。
|
||
|
||
balance_frozen_amount
|
||
|
||
类型：float
|
||
|
||
当前：全部 0.0
|
||
|
||
含义（推测）：
|
||
|
||
涉及会员储值卡退款时，暂时冻结的余额金额；
|
||
|
||
用于一些“先冻结后解冻/退款”的逻辑。
|
||
|
||
当前数据状态：
|
||
|
||
所有退款记录的 member_id / member_card_id 都是 0，对应的冻结金额自然也是 0；
|
||
|
||
说明这 11 笔退款都不是“退到会员卡余额”，而是对普通支付渠道（例如刷卡）的退款。
|
||
|
||
card_frozen_amount
|
||
|
||
类型：float
|
||
|
||
当前：全部 0.0
|
||
|
||
含义：与上一个类似，偏向“某张卡的被冻结金额”，也与会员卡/储值账户相关。
|
||
|
||
状态同上：本数据中未发生“卡冻结退款”。
|
||
|
||
round_amount
|
||
|
||
类型：float
|
||
|
||
当前：全部 0.0
|
||
|
||
含义（推测）：
|
||
|
||
舍入金额/抹零金额；
|
||
|
||
在某些场景下，如果退款金额存在四舍五入等调整，会单独记录到这个字段。
|
||
|
||
当前未使用。
|
||
|
||
channel_fee
|
||
|
||
类型：float
|
||
|
||
当前：全部 0.0
|
||
|
||
含义（推测）：
|
||
|
||
第三方支付渠道对本次退款收取的手续费；
|
||
|
||
正常应该在“通道成本核算”里用到。
|
||
|
||
当前数据中没有任何通道手续费记录（可能通道不收手续费，或者手续费隐藏在其他费用内）。
|
||
|
||
5. 支付方式 / 渠道相关字段
|
||
|
||
结合“支付记录.json”一起看，更容易理解这些字段的结构设计。
|
||
|
||
payment_method
|
||
|
||
类型：int（枚举）
|
||
|
||
当前取值：仅 4
|
||
|
||
在“支付记录.json”中出现的取值有：2、4。
|
||
|
||
含义（推测）：
|
||
|
||
支付/退款的 方式类型：
|
||
|
||
2：某种线上支付渠道（很可能是微信）；
|
||
|
||
4：另一种支付方式（很可能是银行卡 POS 或现金），当前这批退款全是 4，说明都是同一支付方式的退款。
|
||
|
||
具体枚举值定义要以“非球科技”系统文档为准，但可以确定是“支付方式枚举”。
|
||
|
||
online_pay_channel
|
||
|
||
类型：int（枚举）
|
||
|
||
当前：全部 0
|
||
|
||
在“支付记录.json”里同样全部为 0。
|
||
|
||
含义（推测）：
|
||
|
||
线上支付的 渠道编号，例如：
|
||
|
||
0：线下/默认渠道；
|
||
|
||
其他值（如 1,2）可能分别代表微信、支付宝等。
|
||
|
||
当前门店的退款记录全部为 0，说明这 11 笔退款要么是线下渠道，要么系统没有区分线上子渠道。
|
||
|
||
online_pay_type
|
||
|
||
类型：int（枚举）
|
||
|
||
当前：全部 0
|
||
|
||
含义（推测）：
|
||
|
||
在线退款的类型：
|
||
|
||
0：原路退回；
|
||
|
||
其他值（如果存在）可能代表“退到余额”、“退到其他银行卡”等。
|
||
|
||
当前数据中未出现其他值，说明门店的退款都是默认策略（很可能就是原路退回）。
|
||
|
||
pay_terminal
|
||
|
||
类型：int（枚举）
|
||
|
||
当前：全部 1
|
||
|
||
含义（推测）：
|
||
|
||
退款所使用的 终端类型：
|
||
|
||
1：前台收银端；
|
||
|
||
其他值可能为：小程序、自助机、后台管理系统等。
|
||
|
||
本文件中所有退款都来自同一种终端类型。
|
||
|
||
pay_config_id
|
||
|
||
类型：int
|
||
|
||
当前：全部 0
|
||
|
||
含义（推测）：
|
||
|
||
支付配置 ID，例如商户在“非球科技”内配置的某一条支付通道（某个微信商户号、银联通道）的主键。
|
||
|
||
当前数据未填（可能全部走默认配置），因此都是 0。
|
||
|
||
channel_payer_id
|
||
|
||
类型：string
|
||
|
||
当前：全部为空字符串 ""
|
||
|
||
含义（推测）：
|
||
|
||
支付渠道侧的 payer ID，例如微信 openid、银行卡号掩码等。
|
||
|
||
当前数据未使用（可能系统没回写或导出时屏蔽了）。
|
||
|
||
channel_pay_no
|
||
|
||
类型：string
|
||
|
||
当前：全部为空字符串 ""
|
||
|
||
含义（推测）：
|
||
|
||
第三方支付平台的交易号（如微信支付单号、支付宝交易号等）。
|
||
|
||
当前为空：要么是通道未返回，要么导出接口没带出这部分数据。
|
||
|
||
6. 会员关联字段
|
||
member_id
|
||
|
||
类型：int
|
||
|
||
当前：全部 0
|
||
|
||
含义：
|
||
|
||
租户内部的会员 ID（对应会员档案中的某个主键）。
|
||
|
||
当前状态：
|
||
|
||
这 11 笔退款中没有任何一笔标记了会员 ID，说明是“非会员退款”或退款没绑定到会员档案。
|
||
|
||
member_card_id
|
||
|
||
类型：int
|
||
|
||
当前：全部 0
|
||
|
||
含义：
|
||
|
||
关联的会员卡账户 ID（对应“储值卡列表”或“会员档案”中的某一张卡）。
|
||
|
||
当前状态：
|
||
|
||
没有记录任何“退到某张会员卡”的情况；
|
||
|
||
结合 balance_frozen_amount = 0、card_frozen_amount = 0，可以确定当前导出时间范围的退款全部是对外部支付渠道的退款，没有会员卡内部余额的退款。
|
||
|
||
7. 状态标志字段
|
||
pay_status
|
||
|
||
类型：int（枚举）
|
||
|
||
当前：全部 2
|
||
|
||
在“支付记录.json”中同样只有值 2。
|
||
|
||
含义（推测）：
|
||
|
||
支付/退款状态枚举：
|
||
|
||
1 可能为“待支付/处理中”；
|
||
|
||
2 为“已完成”（支付成功 / 退款完成）。
|
||
|
||
鉴于所有支付、退款记录导出时都已经完成，因此本文件中只有 2。
|
||
|
||
is_revoke
|
||
|
||
类型：int（枚举）
|
||
|
||
当前：全部 0
|
||
|
||
含义（推测）：
|
||
|
||
是否撤销型退款/撤销原支付：
|
||
|
||
0：正常退款；
|
||
|
||
1：撤销类型操作。
|
||
|
||
当前为 0，说明所有记录按“正常退款”处理，而不是“支付撤销”这类特殊类型。
|
||
|
||
is_delete
|
||
|
||
类型：int（枚举）
|
||
|
||
当前：全部 0
|
||
|
||
含义：逻辑删除标志。
|
||
|
||
0：未删除；
|
||
|
||
1：已删除（逻辑上标记删除，但记录仍存在）。
|
||
|
||
当前数据中所有退款记录都处于“未删除”状态。
|
||
|
||
check_status
|
||
|
||
类型：int（枚举）
|
||
|
||
当前：全部 1
|
||
|
||
含义（推测）：
|
||
|
||
审核状态：
|
||
|
||
1：已审核/通过；
|
||
|
||
其他值可能表示“待审核/审核拒绝”等。
|
||
|
||
结构意义：
|
||
|
||
说明系统设计上支持“退款需审核”的流程，但当前导出时这些记录已经审过。
|
||
|
||
action_type
|
||
|
||
类型：int（枚举）
|
||
|
||
当前：全部 2
|
||
|
||
含义（推测）：
|
||
|
||
行为类型：
|
||
|
||
1：支付；
|
||
|
||
2：退款；
|
||
|
||
或类似的“资金动作类型”。
|
||
|
||
结合：
|
||
|
||
支付记录并没有此字段，退款记录有 action_type=2；
|
||
|
||
再加上 pay_amount<0，基本可以确定这是“退款动作”的枚举标识。
|
||
|
||
8. 其他操作相关字段
|
||
cashier_point_id
|
||
|
||
类型：int
|
||
|
||
当前：全部 0
|
||
|
||
含义（推测）：
|
||
|
||
收银点 ID，例如前台 1、前台 2、自助机等。
|
||
|
||
当前数据中未区分具体收银点，统一为 0。
|
||
|
||
operator_id
|
||
|
||
类型：int
|
||
|
||
当前：全部 0
|
||
|
||
含义：
|
||
|
||
执行该退款操作的操作员 ID。
|
||
|
||
当前全部为 0，说明：
|
||
|
||
要么系统没有记录具体操作员；
|
||
|
||
要么导出接口未把这个信息带出（但字段已预留）。
|
||
|
||
三、与其它 JSON 文件的关联关系（结构层面）
|
||
|
||
从字段角度，退款记录.json 与其它数据之间主要有以下关联：
|
||
|
||
与门店/租户：
|
||
|
||
tenant_id ↔ 所有 JSON 中的 tenant_id；
|
||
|
||
site_id ↔ 所有 JSON 中的 site_id；
|
||
|
||
siteProfile 内部的 id、tenant_id 与上述字段一致。
|
||
→ 说明：退款记录明确挂在“朗朗桌球”这个门店下，与其它消费、库存、助教等记录在同一数据域。
|
||
|
||
与支付记录（支付记录.json）：
|
||
|
||
两者都拥有：
|
||
|
||
relate_type + relate_id：指向同一个业务实体（订单、充值等）；
|
||
|
||
payment_method、online_pay_channel：同一套支付方式枚举；
|
||
|
||
pay_amount、pay_status、pay_time：结构一致。
|
||
|
||
差异：
|
||
|
||
支付记录的 pay_amount 为正数（进账），退款记录的 pay_amount 为负数（出账）；
|
||
|
||
退款记录多了一些退款专用字段：refund_amount、balance_frozen_amount、card_frozen_amount、is_revoke、online_pay_type、channel_fee 等。
|
||
|
||
结构性结论：
|
||
|
||
支付记录 = 资金正向流入流水；
|
||
|
||
退款记录 = 资金反向流出流水；
|
||
|
||
通过 同一个 relate_type + relate_id 指向同一业务主单，从而把“支付”和“退款”绑定在同一个订单/充值实体之上。
|
||
|
||
与订单/充值等业务表：
|
||
|
||
relate_type 通知你“这是哪种业务”，relate_id 是那种业务表里的主键。
|
||
|
||
在已导出的 JSON 中，对应的业务表大致为：
|
||
|
||
relate_type = 2 → 多数对应“订单类业务”（例如结账记录、小票详情、消费明细）；
|
||
|
||
relate_type = 5 → 多数对应“充值类业务”（对照余额变更记录、充值记录）。
|
||
|
||
虽然我们在当前导出中没拿到完整的充值记录明细，但这两字段的存在，已经把退款挂在“业务主单”的坐标上了。
|
||
|
||
与会员体系：
|
||
|
||
通过 member_id、member_card_id 理论上可以关联到：
|
||
|
||
会员档案（会员档案.json）；
|
||
|
||
储值卡列表（储值卡列表.json）；
|
||
|
||
余额变更记录（余额变更记录.json）。
|
||
|
||
当前这批数据里二者均为 0，说明这 11 笔退款完全与会员卡无关，是纯支付渠道层面的退款。
|
||
|
||
结构意义：
|
||
|
||
一旦未来有“退到储值卡”的场景，member_id/member_card_id 会出现非 0 值，进而通过上述表串联起“资金退款 → 会员余额变更 → 卡账户状态”。
|
||
|
||
四、结构层面的额外重要线索（不涉及金额分析）
|
||
|
||
正/负号决定资金方向：
|
||
|
||
退款记录并没有用一个单独的“类型字段 + 正数金额”来描述退款，而是直接用 pay_amount 为负，配合 action_type=2 表示“退款”。
|
||
|
||
对后续数据对接/迁移很关键：判断“是支付还是退款”，不能只看 pay_status，而是要同时看 action_type + pay_amount 的符号。
|
||
|
||
业务实体与资金流水是一对多关系：
|
||
|
||
两条记录中 relate_id 相同但 id 不同的情况，意味着同一业务单可以产生多笔退款（例如分批退）。
|
||
|
||
这也解释了为什么系统用 relate_type + relate_id 来指业务，而“支付 record ID / 退款 record ID”本身只是在资金流水表内唯一。
|
||
|
||
退款文件是资金维，不含任何“原因类字段”：
|
||
|
||
没有“退款原因”、“备注”、“操作人姓名”等文本字段；
|
||
|
||
“是否审核通过”、“是否撤销”等只通过状态位表示；
|
||
|
||
说明系统将“业务解释”留给业务表（订单/充值），这里只关心钱动了多少、从哪儿来、到哪儿去。
|
||
|
||
会员退款与普通退款在结构上是统一模型：
|
||
|
||
即使当前数据里没有会员退款记录，字段已经预留了：
|
||
|
||
member_id / member_card_id；
|
||
|
||
balance_frozen_amount / card_frozen_amount；
|
||
|
||
online_pay_type 等。
|
||
|
||
一旦发生“退到余额/退到会员卡”的场景，这份结构可以无缝承载，不需要变更表结构。
|
||
|
||
审核流程是结构预留但未复杂使用：
|
||
|
||
有 check_status 字段，也有 is_revoke，表明系统支持“审核 + 撤销”这类管理流程。
|
||
|
||
当前导出数据中全部为 check_status=1、is_revoke=0，说明：
|
||
|
||
要么店内流程简单，退款都直接通过；
|
||
|
||
要么导出只包含“已审核通过的记录”。
|
||
|
||
与支付记录共用枚举体系：
|
||
|
||
payment_method、online_pay_channel、pay_terminal、relate_type 等枚举字段，与支付记录完全共用。
|
||
|
||
这一点对于你后续构建统一的资金流水视图很关键：可以把支付记录和退款记录 union 在一起，通过这些枚举和正负金额，就能得到一张统一的资金流水大表。
|