保留原银行终态及依据,以恢复轮次绑定材料、候选和独立性;最终取消重验并原子消费批准、释放占用和记录审计。新增增量迁移、HTTP 回归及数据库保护。 验证:78 个迁移、HTTP 72 组、既有浏览器 7 组、数据库约束 9 组通过;7 个变异均被抓住。服务端首跑 4470 通过、6 失败、1 跳过,补齐 BIFF8 测试依赖后相关 146 项通过,未重跑完整套件。 限制:inline 主会话自查不等于独立复核,独立复核待完成;界面未完成,不能单独部署;真实回单待验。新恢复界面留待 S8,S4 另批,整体借款功能尚未完成验收。本次仅本地提交,不推送、不部署、不查询生产。
12 KiB
公司借款台账与本金归还
2026-09-17 实施接续
用户明确要求借款尽快完成,沿本PRD与design既有个人出借人/CNY本金范围推进本地T1–T4,取代此前暂缓实施的优先级;不扩大为利息、备用金或通用付款。真实资料、余额和账户仍须正式录入核实,本地只用合成样例。风险与独立复核在交付/上线前保持未完成,不通过读取生产密钥或重跑旧恢复为本地开发解阻。
Goal
让财务能按已核实凭据查清公司向个人借入的未还本金,并完成申请、独立审批、网银付款、回单留存和业务本金核销。OA管理业务台账及付款证据,代账系统负责原负债科目记账,不把借款还本变成费用报销。
Background
- 用户提出历史两笔借入合并一次归还的真实需求;聊天提供的历史日期、金额和“本年无借还”尚未由本任务核验原始凭据,不据此创建真实余额或付款。
- 当前代码仅有reimbursement/travel_order付款来源(
server/prisma/schema.prisma:273);创建依赖已有来源单,不支持自由填收款人金额的通用付款申请。 - 建行制单用途/备注按报销生成(
server/src/services/paymentOrderXls.js:158);通用审批配置也只有既有五类业务(server/src/routes/workflowDefinitions.js:9)。回单OCR及人工核对范围须显式适配,不能只改备注。 - 本task于2026-09-17获准规划,独立于报销收尾任务,status=planning。先处理08-23恢复关键遗留及09-05到期治理;本次不是实施、真实资料录入或付款授权。
Scope
首期仅个人出借人(可为股东、非员工)的公司借入本金台账和人民币本金归还,沿现有建行付款支持范围;一张还款申请关联同一公司、同一出借人、同币种的一条或多条已确认借款,对应一笔银行付款。支持部分偿还,不建设任意用途的通用付款平台。
Requirements
R1 历史及后续借入登记
财务登记出借人、公司主体、借入本金、实际到账日期、协议/确认资料、原入账凭证及核对截止时点。历史登记与当前收款分开,不产生虚假的新增现金流。余额未经财务与代账确认时只能标待核实,不能用于还款;已在系统外偿还的本金须有依据并单列确认,不能重复冲减。出借人不必是员工,银行资料沿现有加密/授权查看/审计要求。
R2 余额与还款申请
列表区分未还本金、已占用待付款额、可申请额及核对截止日期,资料覆盖不全时不得回答“已结清”。财务选择借款及本次分配金额,正数、两位小数且合计等于付款额;不得跨公司/出借人/币种合并。并发申请不能超额,已付、取消及有银行在途的状态必须分别处理。
R3 有权且独立的审批
财务创建并提交,复用付款批次的经理/CEO独立复核作为首期还款审批,不再加一套重复通用审批链。审批人须在职、有明确业务角色及权限,排除制单/提交人和出借收款人对应的OA身份;身份不清或无人可批则阻止提交,不用admin通配兜底、不靠临时虚建员工绕过。对出借人的OA身份关联必须确认并留痕,执行时重验,不按姓名猜测。
R4 付款与回单证据
审批只占用额度,不减少未还本金。财务在网银实际付款,用途为“还款”,短备注按借款年份/本金语义生成,受现有银行长度校验;详细原借款对应关系留在OA,不硬塞进银行备注。原件可先留存,但金额、币种、付款/收款账户、交易成功状态及唯一身份不满足时不得登记已付。
复用现有回单核对的自动匹配/人工例外边界,显式支持新付款来源;真实样本适配未验证前不能宣称新来源自动识别可用。OCR不清或不可用时,原件留存、经办录入、独立人员复核不能伪称机器核实或银行验真;明确失败、受理中、账户/金额不符及重复交易不得靠普通理由放行。独立人工复核继续排除收款人和提案人。
R5 核销、异常与会计交接
只有符合既有付款登记证据门禁并由财务明确登记成功时,才在同一事务内占用交易身份、核销分配本金并更新付款事实;同一请求重试幂等,跨批次/跨报销复用交易拒绝。确认失败或未发起银行付款的取消可释放额度;银行状态未知/在途时不能直接释放后重付。付款已登记后的错误处置保留原事实,另审纠错,不删除或覆盖记录。
付款成功与代账记账分开,记录凭证编号/记账确认及材料交接,不由OA自动生成会计分录。材料包括原借入凭证、协议/确认书、余额核对、审批及还款回单;本金不要求费用发票,不进入费用报销统计或费用预算。关键材料按适用访问权限留存,历史余额/分配不得无审计改写。
Acceptance Criteria
-
AC1:合成历史两笔借入可登记并确认余额;未确认/重复登记/无凭据不进入还款,历史录入不被统计成当天新增收款。
-
AC2:同一出借人两笔借款合并一笔付款、部分偿还正确;超额、跨主体/出借人/币种、重复提交和并发占用均拒绝或幂等,金额用精确小数。
-
AC3:财务不能自审,收款人即使持CEO/manager或多角色也不能批准自己的还款;无合格审批人、身份关联缺失/变动拒绝,无管理通配旁路。
-
AC4:审批/导出/上传回单均不会单独减少本金;处理中保持占用,确定失败/安全取消释放,明确成功登记与分配核销原子完成,数据库异常整体回滚。
-
AC5:正确回单可匹配新来源,错金额/账户/币种、失败/受理、同额歧义、重复交易、晚到版本及人工自审分别受阻;真实样本未覆盖的自动识别仍明确待验。
-
AC6:付款完成可追到原借款分配和会计交接状态;余额查询标明截止/核对状态,不把OA无记录说成银行无还款,不把本金计入费用。
-
AC7:报销/差旅既有付款、独立复核、制单、回单和权限回归通过;PC/手机沿既有交互,机密字段默认脱敏,普通员工不能读全台账。
-
AC8:迁移与回退影响、独立只读复核、恢复风险处置和发布前条件完整;本地合成通过不替代真实银行接受性或部署,真实录入/付款另批。
-
AC9(对账,design 3.1/3.3):制单导出与银行提交尝试分别落表并关联;提交清单须经独立复核;确认失败只计未作废附件,但作废的成功或处理中回单仍按事实阻断;确认失败按批次冻结快照核对,出借员工离职不阻断;一条指令的终态不能推定其他提交已结束。
-
AC10(失败归属,3.1):存在同金额候选时,确认失败须有已复核、写明覆盖哪些指令的失败归属;未确认时保持占用。
-
AC11(银行终态释放,3.2;2026-10-07 补充:同一指令的终态事实可了结该指令此前的处理中回单,其他提交不能代替;最终取消释放的事务须重验全部条件,并与新提交、晚到回单串行;终态证据与付款回单分开存放,作废或被替换后不能继续作为依据):每次已登记提交均有能唯一定位指令、经独立复核的终态证据,且无未解决的成功或处理中事实,才可转
confirmed_not_paid并释放;对账单、截图、时间依据与等待期均不能单独放行;释放后禁止再导出。 -
AC12(人工确认未提交,3.2a,用户 2026-10-06 确认支持):全部证据加两名不同的独立复核人,转
confirmed_not_submitted,记录与页面标为人工确认;人员不足或材料缺失时继续占用。 -
AC13(冻结,3.5):冻结按原因记录;拦截新申请及其他在途申请的复核与导出,不拦事实登记;误报经独立复核关闭不补记;证据不确定继续冻结;全部原因关闭才解冻。
-
AC14(晚到成功,3.4):只增不改并标记原结论被推翻;按冻结快照与历史审批核对;覆盖已释放与已确认失败未释放;逐笔先处理占用冲突再按差额结清,余额列待追回;补记不生成可导出指令,整笔超额也完整记录;同一交易不能两次使用。
-
AC15(追回,3.5):凭到账证据经独立复核登记,支持部分追回;仅登记不解冻;本期不支持冲抵。
-
AC16(存量):历史批次保留已知的导出次数,新增“历史导出汇总”标明已知与待核实信息;它不是一次真实导出或银行提交,不能据此放行额度;上线前须核实生产存量(S0)。
-
AC17(补证恢复,SR1–SR3;方案已批准,后端验证见 implement):已确认失败或未付款且本金仍全部占用时,可补充有效证据并重新独立复核;原结论与依据不可改,旧证据/复核可追溯;恢复不得重开付款、导出或改变本金,不适用于已释放/已结清、成功事实或 Q6 人工未提交。
-
AC18(恢复批准有效性,SR2–SR4;后端验证见 implement):材料、核验版本、提交清单、归属或同额候选变化使旧恢复批准失效;新建再撤回、换回同一流水号、撤回/驳回恢复均不能复活旧批准或回退原释放依据;补证后能重新送审,不永久卡死;当前复核人合格且与全部相关经办身份独立。
-
AC19(最终恢复释放,SR3–SR5;后端验证见 implement):确认与最终取消均满足 S3 全部条件及等待期;最终事务重验最新恢复批准与证据,释放、取消、消费批准、审计原子且幂等;与证据/提交/核验/候选变化确定性交错时不错误释放;成功事实转对账、未知继续占用。PC/手机完整操作与真实银行接受性分别验收。
Out of Scope
- 不处理利息、工资/分红、员工向公司借备用金、资本金、债转股、机构借款、外币、退款或债务冲销。
- 不做银行直连、流水自动导入、AI自然语言财务问答、自动会计凭证/税务、跨系统重复审批或全量ERP。
- 不伪造报销单承载本金,不改现有报销一单一笔付款规则,不解冻其他低频模块,不引入新视觉设计体系。
- 不索取聊天中的完整账号或真实凭证,不读取/轮换生产密钥,不沿用旧恢复/部署/真实付款授权。
Test Plan
真实Fastify路由与隔离PostgreSQL覆盖AC1–AC6的正反例、并发和事务回滚;前端沿现有Vitest/Playwright以合成财务、审批人、收款人和普通员工验证PC/手机权限/动作/余额状态。跨业务重复交易与报销回归单列;仅云端响应可在合成测试中替换,不用预签身份替代正式认证全链。执行端承担软件验证,不让用户制造真实还款来代测。
Current Status
T1–T4本地合成实施已完成,AC1–AC4、AC6–AC7有本地证据;AC5真实样本及AC8独立/恢复/发布条件保留开放。精确回执见implement顶部。2026-09-27 已随 70af0c6b 上线(借款迁移已应用);生产是否已有真实还款待核实,不声称真实银行接受或真实批次已通知。2026-10-05 同模型只读复核报出阻断 B1(在途还款被出借人维护卡死)与回单批次归属缺陷,处理进展见 implement 顶部;真实还款验收在其收口前不得进行。
Planning Status(历史时点,已由顶部实施接续替代)
本task已形成PRD/design/implement待审方案,本日追加源码消费者地图与T1–T4技术切片,无产品实现。实际借款余额、收款账户、审批人资格及银行样本属于录入/上线前的证据门禁,不把聊天转述视作已核实。08-23关键恢复及09-05治理的准入判断见09-08顶部优先级表;未取得本task方案实施批准前不得start。无必须现在向用户索取的秘密或真实资料。