feat(corporate-bank-account-payment-order): 基于原模板生成建行制单
这个提交包含在:
@@ -59,14 +59,16 @@
|
||||
|
||||
### R4 银行制单导出
|
||||
|
||||
- 从符合状态与权限要求的付款批次生成与空白模板一致的 BIFF8 `.xls`。
|
||||
- 从符合状态与权限要求的付款批次生成与受控空白原模板视觉和结构一致的 BIFF8 `.xls`;不得重建一个仅字段相同但丢失列宽、行高、字体、底色、边框或对齐的工作簿。
|
||||
- 银行制单是推荐的效率工具而非付款完成硬门禁;旧快照、格式异常或人工付款场景仍可通过线下转账、上传回单和登记完成闭环,银行回单继续是银行渠道付款完成的证据门禁。
|
||||
- 新批次已复核、资料完整且尚未制单时,顶部主动作显示“下载银行制单”;首次制单后主动作切换为“上传银行回单”,重新下载进入“更多”。已经人工付款的用户可直接在回单区域上传,不被制单状态阻断。
|
||||
- 批次详情显示是否已生成制单;处理进度在未制单时显示“等待财务线下付款并上传回单”,制单后显示“已生成银行制单,等待付款完成并上传回单”。
|
||||
- 仅 `reviewed`(待财务付款)批次允许制单;`draft`、`failed`、`cancelled` 与 `executed` 均禁止制单。
|
||||
- `reviewed` 状态允许因文件丢失或本地操作失败重复导出,每次仍须填写原因并独立审计;重新下载前必须明确提示“重新下载不会作废之前的文件。如果上一份已在网银导入,请勿重复提交。”重复导出的业务字段必须来自同一冻结快照,不允许临时覆盖账号、金额或用途。
|
||||
- `executed` 后不得重新生成可导入网银的指令文件;付款归档依赖银行回单与付款台账,避免把归档需要和可重复付款指令混为一体。
|
||||
- 原样保留三个工作表、15 列顺序与表头;不得把格式伪装成 `.xls` 扩展名。
|
||||
- 原样保留三个工作表、15 列顺序与表头,以及原模板的列宽、表头/数据行行高、字体、加粗、底色、边框、对齐和换行;不得把格式伪装成 `.xls` 扩展名。
|
||||
- 仓库可提交一份经脱敏检查、仅含空白表头和预格式化空行的受控模板资产;运行时只读取该固定资产,不接受用户上传模板或请求指定路径。模板哈希漂移时制单失败关闭。
|
||||
- 模板预置数据行不足时,新行必须复制首个数据行的样式和行高;金额列仅覆盖为数值类型与 `0.00` 格式,不改变其他视觉属性。
|
||||
- 用途固定为“报销款”;客户方流水号由付款批次编号与三位行序号生成;备注写对应报销单编号;开户行名称取冻结快照;付款凭证号不进入制单。
|
||||
- 批次项必须使用显式、稳定且带唯一兜底键的排序,禁止依赖数据库自然顺序;同一批次重复导出时每项的行序号和客户流水号必须不变。
|
||||
- 客户方流水号由单一生成函数负责,并在写文件前校验长度、字符集和批次内唯一性;不允许静默截断或分散内联拼接。首轮验证若证明银行只接受纯数字,应只调整该生成函数与对应合同。
|
||||
@@ -74,20 +76,21 @@
|
||||
- 金额首版按数值写入并设置两位小数格式,必须无科学计数法和精度损失;若银行安全导入验证明确拒绝,再改为两位小数字符串。
|
||||
- 收款人名称、用途与备注中文不得乱码。
|
||||
- 收款方联行号首版固定留空;首次安全验证使用字符串 `01`、建行虚构账号和空联行号,覆盖真实生产主场景。跨行 `02` 与联行号留待支持非建行员工时另立增量任务。
|
||||
- 导出文件通过响应直接下载,不持久化到服务器存储,不进入 Git,不记录原始制单内容。
|
||||
- 导出文件通过响应直接下载,不持久化到服务器存储,不记录原始制单内容;只有脱敏空白模板资产可以进入 Git。
|
||||
- 完整账号只可通过子进程标准输入传给固定填充器,不得进入命令行参数、环境变量、日志或错误输出;生成的二进制只从标准输出返回,并设置明确的大小上限。
|
||||
- 导出使用独立权限、必填原因和逐次审计;审计只记录操作人、批次、笔数、合计金额及原因,不记录完整账号。
|
||||
- 旧快照批次、非银行渠道、缺少付款账户、缺少员工银行标识或账号、公司或员工银行不是建行的批次必须在导出前一次性列出不可制单原因。
|
||||
|
||||
### R5 本地与人工验证
|
||||
|
||||
- 使用合成数据生成 `.xls`,再用独立于生成器的解析器读回验证工作表、表头、字段类型、中文与金额。
|
||||
- 使用合成数据生成 `.xls`,再用独立解析验证工作表、表头、字段类型、中文、金额和模板视觉签名;至少覆盖列宽、行高、字体、加粗、底色、边框和对齐。
|
||||
- 独立解析器及版本必须进入可复现的测试环境,不能依赖某台开发机偶然安装的 `xlrd`。
|
||||
- 至少使用 Excel 或 WPS 人工打开一次,确认中文和账号显示。
|
||||
- 只有企业网银存在明确的“仅校验、不提交”环节时,才允许用完全虚构数据做最终格式确认;否则不进行生产网银试验。
|
||||
|
||||
### R6 依赖安全
|
||||
|
||||
- BIFF8 生成依赖必须在设计阶段确定受支持版本、来源、锁定和完整性校验方式。
|
||||
- BIFF8 生成依赖必须在设计阶段确定受支持版本、来源、锁定和完整性校验方式;CI 与生产镜像必须使用同一份带哈希的固定 Python requirements。
|
||||
- 不得静默接受已知高危依赖告警;若只能使用存在已知解析漏洞的版本,必须证明运行路径只生成、不解析不可信输入,并单独获得风险例外批准。
|
||||
|
||||
## Test Plan
|
||||
@@ -116,6 +119,7 @@
|
||||
- [ ] 未制单批次、已制单批次和人工付款路径均可按既定主动作/次动作继续,制单状态不是上传回单或登记付款完成的硬门禁。
|
||||
- [ ] 批次详情和处理进度能区分“未生成制单”与“已生成制单待回单”,便于观察实际使用覆盖率。
|
||||
- [ ] 授权财务人员填写原因后可下载符合模板的 BIFF8 `.xls`,下载行为留下脱敏审计。
|
||||
- [ ] Excel 打开生成文件时,原模板列宽、行高、字体、加粗、底色、边框、对齐和换行保持不变;超过三笔时新增行仍复制相同数据行样式。
|
||||
- [ ] 重新下载前展示重复付款风险原文;每次重导独立记录原因,但不会宣称旧文件已失效。
|
||||
- [ ] 只有 `reviewed` 批次可制单;同一 `reviewed` 批次可带新原因重导,其他四种状态均被明确拒绝。
|
||||
- [ ] 批次进入 `executed` 后无法重新生成银行制单,银行回单与付款台账仍可用于归档核验。
|
||||
@@ -126,6 +130,7 @@
|
||||
- [ ] 使用字符串 `01`、建行合成账号和空联行号完成本地验证;合成非建行项证明整批失败且不会生成部分文件。
|
||||
- [ ] 缺失资料或状态不合格时,页面一次性说明全部阻塞项及处理方式。
|
||||
- [ ] 自动化、本地人工打开和可选网银校验均使用合成数据,不触发真实付款。
|
||||
- [ ] 模板哈希漂移、Python 或固定依赖缺失、填充器失败时返回固定安全错误,stderr、日志和测试证据均不含完整账号或原始 payload,人工付款路径不受影响。
|
||||
|
||||
## Out of Scope
|
||||
|
||||
@@ -134,4 +139,4 @@
|
||||
- 首版支持多个同时启用的公司付款账户。
|
||||
- 非建行、跨行 `02`、联行号维护和混合银行批次制单。
|
||||
- 为历史付款批次补写或回填完整账号快照。
|
||||
- 将真实账号、模板业务数据或生成的制单文件提交到仓库。
|
||||
- 将真实账号、含业务数据的模板或生成的制单文件提交到仓库;经检查的脱敏空白模板资产除外。
|
||||
|
||||
在新工单中引用
屏蔽一个用户