2026-09-12 一卡通消费记录上传变更记录

变更结论

Android 消费流程已接入新开普一卡通 UploadBusinessRec。正金额扣款完整成功后，程序按实际钱包交易拆分记录、先写入独立本地队列，再由现有后台同步任务上传；原业务系统接口 C 保持不变。

配置

• WebService 地址继续读取一卡通设置中的现有 URL，本次没有改用临时地址。
• AppID 由一卡通设置读取，未配置时默认 48。
• 新增可配置的科目代码 AccCode，未配置时默认 219。
• TermID 已作为一卡通设置中的独立可输入项，未配置时默认 1012；第二台设备需配置为 1013。
• 上传不再回退或复用基础设置中的设备编号。
• 已安装设备中若 MMKV 已保存旧 AppID，旧值会继续生效，需要在一卡通设置页明确改为 48。
• CompType、FindOrder 属于 Windows Change 读写卡配置，本次不作为 UploadBusinessRec 参数发送。

DTO 与 SOAP

• 现场读取 ProxyWebService.asmx?WSDL 后，上传请求改为严格按照 59 字段 PROXY_BusinessDTO 的名称、类型和 sequence 顺序输出。
• Windows 成功报文确认消费业务使用 BusinessType=1、MealID=1；原 Android 临时值 BusinessType=0 会被服务端以 retResult=-13、非法的业务类型 拒绝，现已修正。
• CardSN 传整数持卡序号；成功报文中的 TradeCardType 同样取持卡序号。页面输入的 CPU 卡类别 8 没有出现在该次成功 DTO 中。
• 卡应用序列号转换为 DTO 的无符号长整型 ASN；成功样本 AA030000026D60992AB9 对应 2668795341488。可选字段 Cardsnr、CardMac、OppzwDate、KeyB 按成功报文发送 xsi:nil。
• 当前 ASN 的最低半字节处理由这一张卡的成功报文反推，已经固化回归测试，但仍需使用第二张不同卡应用序列号复核，避免把单样本规律误当成厂商通用规则。
• TAC 按 32 位无符号十进制只写入 TAC；负的 Java long 位模式会先转换到 0～4294967295。
• OPDT 保持实际消费时间；CollectDT、ResetDT、CreateDT 使用本次发起上传的时间；Description 固定为厂商成功样本中的协议文本“上机支出”。
• DTO 内 RetMessage 保留 Windows 请求中的 79 个空格占位；顶层 retMessage 继续发送 xsi:nil，retResult 发送 0。
• 删除现场 DTO 中不存在的 rtn；顶层继续保留 WSDL 定义的 retMessage、retResult 占位参数。
• 补贴钱包和主钱包分别形成记录，钱包余额、消费计数、PSAM 流水号和 TAC 不合并。
• PSAM 卡号继续使用现有十六进制到无符号十进制转换结果。

返回判断

• HTTP、空响应、SOAP Fault 和 XML 解析异常均判定失败。
• 正常 SOAP 响应以现场 WSDL 的 UploadBusinessRecResult 布尔值为主结果，并读取 retResult。
• 服务端明确返回 false 属于业务字段或配置拒绝，保留 retMessage 且禁止后台自动重试；不再使用旧的 rtn > 100 规则。
• retMessage 优先作为结果详情，兼容 msg。

本地队列

• consumption_records.db 从版本 2 升级为版本 3，新增 onecard_upload_records。
• 使用 order_no + segment_index 唯一约束，避免同一订单同一钱包分段重复入队。
• 单条成功后独立出队；网络失败不阻塞同批其他记录并按退避策略重试，明确业务拒绝不自动重试。
• 每批最多 50 条、每轮最多两批；上传失败不会回滚卡片扣款，也不会重新扣卡。

手动重传修复

• 单笔和“全部上传”会把 PENDING 或明确 FAILED 且 result_uncertain=0 的记录重新置为 PENDING，清理旧错误和租约并立即调度；历史尝试次数保留。
• RESULT_UNKNOWN 或 result_uncertain=1 继续禁止手动和自动盲目重传，必须先核对服务端是否已入账。
• 手动操作实际没有激活任何安全可重传记录时，不再误提示“已开始上传”，改为提示“没有可安全重传的记录，请核对上传结果”。
• “全部上传”继续使用点击时冻结的业务表 rowid 和一卡通表 id 高水位，点击后新进入列表的订单不属于本轮。

自动化验证

• 使用 Corretto JDK 8 执行 :app:testDebugUnitTest --rerun-tasks：185 个测试通过，0 failure、0 error、0 skipped。
• 新增 SQLite 真机回归测试，覆盖“明确失败可手动重传”“结果不确定保持阻断”“全部上传不越过点击高水位”，共 3 个用例全部通过。
• 使用 Corretto JDK 8 执行 :app:assembleDebug：构建成功。
• git diff --check：通过。
• Debug APK：app/build/outputs/apk/debug/app-debug.apk，约 64 MB。
• APK SHA-256：ca4c30c837fb22eb7bad168692cf7cb30cfab623f0c3ece6aedb74aba69a6e16。

现场验证与后续

• 订单 CAFA20260912134143E3DD2B 的旧 16 字段请求返回 XML 第 454 列格式错误；改为现场 WSDL DTO 后，服务端已完成反序列化并明确返回 retResult=-13、非法的业务类型。
• Windows 测试程序的成功 SOAP 原文已经取得，底层结果为 UploadBusinessRecResult=true、retResult=100、retMessage=上传记录成功。Android DTO 适配层已按该样本修正，并增加真实样本回归测试。
• 2026-09-12 18:52，Android 真机对订单 CAFA20260912134143E3DD2B 执行“上传未完成项”，只重传一卡通流水，没有再次扣卡；服务端返回 UploadBusinessRecResult=true、retResult=100、retMessage=上传记录成功，耗时 372 ms。
• 真机数据库已将该一卡通子记录从 FAILED 更新为 UPLOADED，尝试次数由 2 增至 3；业务通道仍为 UPLOADED。页面随后显示 0/0 页 · 共 0 单，该订单已自动移出待上传列表。
• 需要用 1012、1013 两台终端各完成至少一笔主钱包上传；有补贴卡时再验证跨钱包两条记录。
• 仍需要在一卡通数据库确认记录进入正常消费表，并核对重复提交是去重、覆盖还是重复入库；新安装默认开关继续保持关闭，本次现场设备已明确开启。

设备数据恢复记录

• 旧版 Gradle 的 connectedDebugAndroidTest 在测试结束阶段执行了目标应用卸载，导致应用私有数据库与 MMKV 配置被清空；后续禁止在生产设备上再次运行该任务，真机验证改为手动安装 APK 和定向执行测试包。
• 已重新安装最终 Debug APK，并依据测试前数据库快照和设备公共日志恢复 5 条历史主记录；关键订单 CAFA20260912134143E3DD2B 的扣款流水、一卡通子任务及上传状态已完整恢复并完成成功补传。
• 已恢复现场确认的业务地址 http://10.19.10.200/、设备编号 001、消费模式，以及一卡通 URL、AppID=48、TermID=1012、AccCode=219 和消费流水上传开关；定向恢复测试执行 OK (1 test) 后只卸载测试包，主应用仍在。
• 最终数据库 PRAGMA integrity_check 返回 ok；主表 5 条、一卡通子表 1 条，子表终态为 UPLOADED 且无失败信息。

Windows 实机操作记录

• 操作环境：通过 ToDesk 连接 Windows 电脑，连接一卡通读卡器并放置测试卡；操作时间为 2026-09-12 15:23～15:36。
• 卡片标识：读卡器显示 UID/CardSN 为 92071FC9；账号 29373、卡号 1705827、持卡序号 2、卡类型 8、卡状态 241、卡应用序列号 AA030000026D60992AB9。
• 扣款前读卡：总额 60964、现金余额 381、现金消费计数 76、补贴余额 0、补贴消费计数 0。
• 实际消费：使用 Windows 测试程序输入消费额 1 分、钱包 0、消费时间 2026-09-12 15:23:30，只点击一次“消费”；程序提示“消费成功”。
• 消费回执：PSAM 卡号 166715196755、PSAM 卡脱机交易序号 40、交易验证码/TAC 1535333204。
• 扣款后读卡：总额 60964、现金余额 380、现金消费计数 77、补贴余额 0、补贴消费计数 0；余额减少 1 分且计数增加 1，和本次单次消费一致。
• WebService 连接：Windows 测试程序连接 http://10.128.1.19/WebService/Newcapec.eCard.ProxyWebService.asmx 成功。
• Windows 配置核对：测试目录 Desktop\\Change 中的 Change.set 为 AppID=48、AccCode=219、CompType=0、FindOrder=12；与当前 Android 约定一致，初次上传返回 -1 不能归因于这四项配置缺失。
• 本次上传参数：TermID 1012、账号 29373、卡号 1705827、持卡序号 2、钱包 0、卡类型 8、总额 60964、余额 380、消费额 1、消费计数 77、管理费 0，并使用上述 PSAM/TAC、卡应用序列号和消费时间。
• 初次上传操作：所有字段逐项核对后，点击一次“消费记录上传”；Windows 测试程序返回“上传消费记录失败”，返回值 -1。该次操作没有再次扣款。
• 抓取结果：Charles 已启动录制，但没有出现该内网请求的 POST；Windows trace.txt 经核对是 Bus Hound 的 USB 抓取文件，不是 WebService 日志。当前推断为测试程序绕过系统代理，或在 HTTP 发送前已返回 -1，尚不能据此确认 SOAP 正确字段。
• 抓包补充操作：在 Charles 中配置本地端口 9999 反向代理到 10.128.1.19:80 并启用请求断点；测试程序地址第一次修改时误将新地址追加在旧地址之后，因此此前的“连接成功”不属于代理链路验证。随后断开旧 WebService、清空地址栏，但测试程序退出，未形成可信的代理请求样本。
• 第二次上传尝试：为截取报文再次点击一次“消费记录上传”，程序仍立即返回 -1，Charles 中仍无对应 POST；该次没有再次消费或扣卡。由于测试程序当时仍使用旧连接对象或处于未初始化状态，该结果不能作为服务端再次拒绝的证据。
• 用户总数诊断：测试程序重启后，在尚未重新建立本地 WebService 对象时，“获取用户总数”显示失败并出现 -2。同一时间从开发机直接向原始地址发送只读 GetCustomerCount SOAP 请求，使用 AppID=48，服务器正常返回 26200。因此这次 -2 不是 Charles 或一卡通服务器不可用造成的，而是 Windows 测试程序本地连接状态未初始化。
• 代理恢复：Windows 系统代理已在 Charles 中关闭；反向代理配置只监听 127.0.0.1:9999，不会影响测试程序恢复后的原始 10.128.1.19 地址。
• 原始流水复测：Windows 测试程序重新打开 WebService 后，“获取用户总数”成功返回 26200。随后重新填写最早一笔真实消费：TermID 1012、账号 29373、卡号 1705827、持卡序号 2、钱包 0、卡类型 8、总额 60964、余额 380、消费额 1、消费计数 77、管理费 0、PSAM 卡号 166715196755、PSAM 脱机交易序号 40、TAC 1535333204、卡应用序列号 AA030000026D60992AB9、消费时间 2026-09-12 15:23:30。2026-09-12 16:46 点击一次“消费记录上传”，程序仍返回失败 -1；本次没有再次消费或扣卡。
• 成功上传复核：将终端编号从误填的 01012 修正为 1012，将卡应用序列号补全为 AA030000026D60992AB9，并将消费时间修正为标准格式 2026-09-12 15:23:30；其余字段保持上述真实流水值不变。2026-09-12 16:58 只点击一次“消费记录上传”，等待约 20 秒后测试程序提示“上报消费记录成功！”，显示 Web服务返回值：100 和“上报记录成功”。本次仅上传历史流水，没有再次消费或扣卡。
• 用户再次验证：随后用户使用同一组完整字段再次点击“消费记录上传”，测试程序同样提示成功。该现象说明测试程序和服务端接受了这组字段，但仅凭客户端提示不能判断服务端对重复流水是去重、覆盖还是重复入库，需要在一卡通数据库中按卡号、消费计数、TAC 和消费时间核对最终落库条数。
• 成功提交内容：WebService http://10.128.1.19/WebService/Newcapec.eCard.ProxyWebService.asmx、AppID 48、TermID 1012、账号 29373、卡号 1705827、持卡序号 2、钱包 0、卡类型 8、总额 60964、余额 380、消费额 1、消费计数 77、管理费 0、PSAM 卡号 166715196755、PSAM 脱机交易序号 40、TAC 1535333204、卡应用序列号 AA030000026D60992AB9、消费时间 2026-09-12 15:23:30。
• Charles 反向代理验证：Windows 端 Charles 以本地端口 9999 反向代理到 10.128.1.19:80，测试程序临时改连 http://127.0.0.1:9999/WebService/Newcapec.eCard.ProxyWebService.asmx。2026-09-12 17:16:59 点击只读“获取用户总数”后，Charles 成功捕获 SOAP POST，服务端返回 HTTP 200 OK，证明抓包链路有效。
• 成功 SOAP 样本：2026-09-12 17:19:20 使用上述完整历史流水再次点击一次“消费记录上传”；Charles 捕获到发往 /WebService/Newcapec.eCard.ProxyWebService.asmx 的 POST，耗时约 330 ms、会话大小约 2.72 KB、HTTP 状态 200 Complete。测试程序同时提示“上报消费记录成功！”，WebService 返回值 100。本次仍仅上传历史流水，没有再次消费或扣卡。
• 成功请求头：POST /WebService/Newcapec.eCard.ProxyWebService.asmx HTTP/1.1、Content-Length: 1933、Content-Type: text/xml; charset=utf-8、SOAPAction: "http://NewCap.com/NewCapecWebService/UploadBusinessRec"、Accept: text/xml、Host: 10.128.1.19、User-Agent: Microsoft-ATL-Native/7.00。
• 成功业务响应：HAR 原文确认 SOAP 结构中 UploadBusinessRecResult=true、retMessage=上传记录成功、retResult=100；此前根据测试程序弹窗记录的“上报记录成功”不是底层 SOAP 原文，现已纠正。
• 抓包噪声说明：HAR 中其余搜狗输入法、Microsoft 和 NVIDIA 请求返回的 503 与一卡通无关；目标 UploadBusinessRec 是唯一的一卡通消费 POST，状态为 HTTP 200 OK。
• 当前结论：完整 HAR、请求原文和响应原文已经传回开发机并归档；Android 请求已逐项比对并按成功样本修正，真实样本单测和 Debug 构建均已通过。

成功抓包证据

• Android 真机成功日志与数据库终态：evidence/2026-09-12-android-onecard-upload-success.txt。
• 原始 HAR：evidence/2026-09-12-onecard-upload-success.har，SHA-256 041acd650f26a52c5df71ce89cd19d50fabfa884b13789a3d32f3ed845b46220。
• 完整 HTTP 请求头与 SOAP 请求：evidence/2026-09-12-onecard-upload-success-request.txt。
• 完整 HTTP 响应头与 SOAP 响应：evidence/2026-09-12-onecard-upload-success-response.txt。
• 归档只复制原始 HAR，没有修改其内容；两个文本文件直接从 HAR 中目标 UploadBusinessRec 条目提取。

Git 边界

本次未执行暂存、提交、推送、拉取、分支切换或其他 Git 写操作；未修改用户已有的 .superpowers/ 未跟踪目录。