这个接口解决什么问题

在零售与分销业务的退换货链路里，「有退有发」订单的发货部分是供应链对账的关键证据。该接口从吉客云按发货时间增量拉取 tradeType=92 的退换货单发货明细，把物流名称、运单号、发货时间回写到企业 MySQL 的退换货对账表，支撑 BDS 对账系统完成核单与物流状态同步。

接口能力总览

API：jackyun.tradenotsensitiveinfos.list.get
所属系统：吉客云·奇门（JkyQM）
认证方式：吉客云开放平台 OAuth/AppKey 鉴权，在轻易云里通常通过「奇门网关适配器」统一托管凭证与签名。
请求方式：POST 表单/JSON，常见请求体包含 tradeType、startConsignTime、endConsignTime、modified_begin、modified_end、tradeNo、pageSize、pageIndex。
响应结构：JSON，外层 data 为订单列表，单订单对象含本文档罗列的 40+ 字段；goodsDetail、tradeOrderPayList 为数组，tradeOrderColumnExt 为自定义对象。
分页模式：pageIndex 从 0 开始，pageSize 默认 100；轻易云运行时会按返回 hasNext/总数自动翻页直至耗尽。
增量模式：以 startConsignTime/endConsignTime 按发货时间窗口拉取，常见默认步长 1 天；若按修改时间则 modified_begin/end 间隔不超过 7 天。

字段名	类型	含义	实战注意事项
tradeId	string	吉客云系统编码，主键	metadata.id 配置此字段，轻易云做幂等去重与 idCheck
tradeNo	string	订单编号，业务主键	metadata.number 配置此字段；与目标表 bill_no 匹配时需先确认业务规则用 tradeNo 还是 orderNo
orderNo	string	发货单单号	本策略回写场景中常以 orderNo 作为 source_after_no 关联 supplier_return_change
stockoutNo	string	出库单号	用于仓储侧对账与单据串联
checkTotal	float	对账金额	与财务收款核对，注意单位与精度
consignTime	datetime	发货时间	回写目标表 consign_time 核心字段
logisticName	string	物流公司名称	回写 send_logistic_name，建议结合物流主数据字典
mainPostid	string	运单号	回写 send_main_post_id，唯一性需校验
warehouseName	string	发货仓库	与仓库主数据对照，避免出现历史/作废仓库
billDate / isBillCheck	datetime/string	对账时间/状态	1 表示已对账，其他视为未对账
isDelete	string	删除标记	0=未删 1=已删，回写前必须过滤已删除单据
goodsDetail	array	商品明细	含商品编码、数量、金额，行级对账关键
tradeOrderPayList	array	支付详情	多支付方式场景要对账到 payment 字段
tradeOrderColumnExt	object	自定义扩展	不同企业结构不同，建议在轻易云字段映射器里做容错
customerName / buyerMemo	string	客户名/备注	注意 PII 脱敏后再回写 MySQL

在轻易云数据集成平台里，这类接口通常以「查询类适配器 + 数据回写 EXECUTE」的两段式策略落地：

适配器选型：选择吉客云·奇门适配器，配置 AppKey/Secret 与奇门网关地址，平台会自动处理签名与时间戳。
元数据建模：把 tradeId 配为 id、tradeNo 配为 number；增量变量用 {{LAST_SYNC_TIME}} 与 {{CURRENT_TIME}} 绑定到 startConsignTime/endConsignTime。
字段映射器：轻易云会自动把 logisticName→send_logistic_name、mainPostid→send_main_post_id、consignTime→consign_time 等映射写好，复杂字段 goodsDetail 可展开为子表或在 MySQL 侧落 JSON 列。
回写策略：下游 EXECUTE 策略以 orderNo/tradeNo 为 WHERE 条件更新 supplier_return_change 表，轻易云会按主键去重，避免重复回写。
调度与监控：crontab 设定按小时/日跑批，运行监控可看到分页进度与失败单据，便于断点续传。

坑 1：tradeType 写错导致查不到数据。真实场景里曾把 tradeType 写成 91（仅退货），结果拉不到发货部分。稳妥做法是在轻易云请求参数里固定 tradeType=92，并用「沙箱订单」做联调验证。
坑 2：分页未翻尽导致漏数。pageSize=100、返回 hasNext=true 时，如果配置里没启用自动分页就提交，会漏掉尾页。轻易云默认会翻页，但自定义脚本里若手动拼 pageIndex 容易翻车。
坑 3：modified_begin/end 间隔超过 7 天被服务端拒绝。稳妥做法是按天切片，每跑批只取 1 天窗口。
坑 4：运单号 mainPostid 为空仍回写。部分未发货/部分发货单据该字段为空，直接回写会让对账系统误以为已发货。务必在转换器里判空跳过。
坑 5：时区漂移导致增量窗口错位。consignTime 为本地时区字符串，存入 MySQL 时未转 UTC，下一次增量会重复拉同一批。

适用于「有退有发」类型退换货单的发货信息回写与对账场景，尤其是零售/分销企业需要把吉客云发货状态同步到自建 MySQL 对账表的链路。若业务仅有「纯退货」或「纯换货」，应改用 tradeType=90/91 的对应接口；若只需出库明细，应走库存域查询接口而非本接口。