社区生鲜店财务出纳：支付流水核对工具——POS 流水和渠道账单各贴一块，按金额加时间窗配对，只输出没配上对的

你是给社区生鲜连锁做单文件工具的编码代理。请做一个浏览器直接
打开就能用的 HTML 单文件工具：「支付流水核对器」，给出纳做 POS
流水与支付渠道账单的核对。全部运算在浏览器本地完成，不请求任何
外部资源——财务数据不出本机。

数据输入（两块粘贴区，支持从各系统导出的 CSV/表格直接粘贴）：
- A 区：POS 系统流水的当日或当月导出：时间 / 金额 / 支付
  方式 / 单号
- B 区：支付渠道账单导出（微信 / 支付宝 / 美团任选其一）：
  时间 / 金额 / 交易状态
- 粘贴后先做列映射：让用户指认哪列是时间、哪列是金额、
  哪列是支付方式——两边系统的表头名不统一，不许假设

匹配规则：
- 主键 = 金额 + 支付方式；时间窗 ±【默认 10 分钟】可调
  ——POS 交易时间与渠道记账时间存在系统性偏差，窗口
  就是为此留的
- 窗口内唯一候选：自动配对
- 窗口内多个候选（同额同支付方式很常见）：不自动配，
  列入「需人工」——宁可人看，不许猜
- 退款（负向金额）独立成池单独匹配，不和正向混
- 时间接近但金额不符的：列「疑似区」，标出差额，不定性
  （可能是部分退款或改价，人工判断）

输出三张表 + 一行汇总：
1. 仅 POS 有：时间 / 金额 / 单号——方向是「钱去哪了」：
  未到账、撤单、渠道延迟
2. 仅渠道有：时间 / 金额——方向是「哪来的」：店外收款、
  私人收款码、系统漏单——这张表的问题更严重
3. 需人工 + 疑似区：合并列出，附建议核查动作一句话
- 汇总行：总笔数 / 总金额 / 未配对率

工程要求：
- 支持把未配对清单导出 CSV（下月对账时先导入上月未平项，
  自动消掉已到账的）
- 页面内不留存数据，刷新即清——敏感数据的默认姿势是
  不保存

禁止事项：
- 不内置「自动判断哪边是对的」——工具只配对，不裁决
- 不猜配对：规则不满足就进人工区，任何自动补配都不做
- 不上后端、不做云同步、不加统计埋点——出现任何一个
  都算这个工具失败

为什么这样写

三方对账的劳动结构是「九成机械加一成判断」：绝大多数 流水能严丝合缝对上，人真正的价值花在那对不上的几笔。 让规则引擎把机械的九成吃掉、人只看机器配不上的部分， 是人机分工的正确切线——肉眼配对的真正风险不是慢， 是人疲劳之后「看起来差不多」就放过，放过的那笔就是洞。

「多候选不自动配」是整条最重要的工程约束。时间窗内 两笔同额交易在社区店下午太常见（连续两单都是 18.80）， 自动配必然产生错配，而错配的对账结果是「平了」——比 不平更危险，因为没有人再看它。规则卡死「唯一候选才配」， 把所有模糊性显式推给人，工具的结论才是可信的。

两张未配对表的方向性是设计出来的：仅 POS 有的指向 「钱没到」，找渠道；仅渠道有的指向「单没进系统」， 找店里——后者严重得多，私人收款码或漏单意味着内控 缺口。表分开，处理的紧迫感就分开了，混在一张表里 只能按金额排序，方向信息全部丢失。

本地运算是财务底线也是这条工具的生存前提：全店收款 流水贴进任何在线工具，等于把收款明细交给第三方。 单文件、纯浏览器、刷新即清——这个约束不是功能，是 边界；突破它的「云同步版」再方便也不能做。

变量

本条提示词无待填变量；【时间窗 ±10 分钟】在工具设置区 内可调，按本店网络与渠道实际情况定。