现状与缺口
当前采购应付体系是两层、且现金被刻意排除在付款链路之外：
| 层级 | 月结 | 现金（现状） |
|---|---|---|
| 单据层 | 产品单据 有金额，无余额 | 同上，无单张单据余额 |
| 汇总层 | 采购对账（供应商+期间），余额 可付款核销 | 对账时强制 余额=0（第 63–65 行） |
| 明细层 | 应付明细 有「月结入账」+ 付款记录 | 无「现结入账」，也不写付款明细 |
| 付款入口 | OutMoneyDocumentAdd + Ajax OMDAdd | 硬编码 类别='月结'，现金不可选 |
Case "OMDAdd" '新增付款返回
...
SADArray=Easp.db.RT("采购对账","类别='月结' And 余额<>0 And ID="&ID,"ID,供应商,对账期间,余额")
销售侧已有完整参照：出货单库.余额 + 现金单据 / 现金明细 + CashDocumentAdd.asp（按单号逐笔核销）。
采购侧没有对应结构，现金在对账汇总时被“归零”，等于假定现金已结清，无法做单据级核销。
推荐方案：镜像销售现结模型（按 产品单据 核销）
「现金单据」在业务上对应 产品单据（采购入库/采购退货，采购=True），结款方式仍取自关联的 采购单库.结款方式。
需要新增/扩展的数据结构
1. 产品单据（改表，核心）
| 字段 | 类型 | 说明 |
|---|---|---|
余额 | 货币 | 现金类单据待付余额；审核后初始化为 金额 |
付款 | 布尔 | 余额清零后置 True，对标 出货单库.收款 |
初始化时机建议：PurchaseInAudit.asp 审核通过时，若 采购单库.结款方式='现金'，则 余额=金额。
取消审核、作废、改金额等场景需联动回滚（与销售侧作废现金收款逻辑类似）。
2. 现金单据 / 现金明细（扩展复用，推荐）
不必新建平行表，扩展现有表 类别 即可（销售已是 类别='出货单'）：
现金单据 — 增加类别值：
类别 = '采购入库'/'采购退货'（或统一'采购单据'）
现金明细 — 增加关联字段（二选一）：
| 方案 | 做法 | 优劣 |
|---|---|---|
| A（推荐） | 新增 关联单号（存 产品单据.内部单号），类别 区分业务 | 语义清晰，不影响现有出货报表 |
| B | 复用 出货单号 字段存内部单号 | 改表少，但字段名误导、报表易混 |
明细字段与销售侧对齐：进出类别、金额、交易账户、交易日期、外部单号、备注 等。
3. 资金明细（已有，补类别）
销售用 类别:现结收款，采购侧新增：
类别:现结付款（方向:付，方向值:-1）
OutMoneyDocumentAdd.asp 里月结付款已用 类别:月结付款，可对称扩展。
4. 预收预付（已有，按需）
若现金付款支持「预付款」核销，沿用 OutMoneyDocumentAdd 里预付款写法，业务类型:预付款，备注:应付核销。
5. 采购对账 / 应付明细（逻辑调整，非必须新表）
现金汇总记录可保留（统计用），但需改语义：
- 方案甲：现金仍进
采购对账，余额 = Sum(未付清产品单据.余额)，不再写死为 0 - 方案乙：现金完全不进
采购对账，只在单据层管理（改动大，与现有对账单统计脱节）
推荐方案甲，与月结共用列表，但付款入口分开。
应付明细 对现金可选：
- 不写「月结入账」（保持现状）
- 或新增
进出类别='现结付款'，便于OutMoneyDetail.asp统一查流水（非必须）
需要改动的业务模块（工作量分布）
flowchart LR
subgraph 数据层
A[产品单据 +余额/付款]
B[现金单据/明细 扩展类别]
C[资金明细 现结付款]
end
subgraph 入口
D[PurchaseInAudit 审核初始化余额]
E[新页面 采购现结付款 4~5个]
F[Ajax 选单接口]
end
subgraph 联动
G[OutMoneyManage 现金余额汇总]
H[作废/退审/撤销对账]
I[Home/权限菜单]
end
D --> A
E --> B
E --> A
E --> C
F --> E
G --> A
H --> A
| 模块 | 改动内容 | 复杂度 |
|---|---|---|
PurchaseInAudit.asp | 审核/取消审核时维护 余额；已有改结款方式逻辑需联动 | 低 |
新建 PurchaseCashDocument*.asp（4~5 页） | 基本复制 CashDocument*.asp，替换选单/回写逻辑 | 中（量大但模式成熟） |
Ajax.asp | 新增 PMCDAdd 类接口：按内部单号查 余额<>0 的现金采购单 | 低 |
OutMoneyManage.asp | 第 63–65 行改为汇总未付余额；列表现金行可显示余额、开放明细 | 中 |
ProductDocumentManage.asp | 作废前检查 余额/已付款；冲销时回滚 | 中 |
PurchaseReturn*.asp | 退货单金额为负，余额符号、核销方向需单独处理 | 中 |
撤销对账 Case "Del" | 若现金已付款，需拦截（对标月结「已有付款不可撤销」） | 中 |
权限 VUP | 新增 501xx 段权限码 | 低 |
两种实现路径对比
路径 A：单据级核销（推荐，符合「单独核销」）
- 核销粒度：
产品单据.内部单号（每张入库/退货单） - 对标：销售
CashDocumentAdd→出货单库 - 新增数据结构：
产品单据2 字段 +现金明细1 关联字段 +现金单据新类别值 - 新增页面：约 4~5 个
.asp - 评估：中等偏上（6/10）
难点不在算法，而在联动面多：审核、作废、退货负数、部分付款、预付款、撤销对账的一致性。
路径 B：仅在 采购对账 层开放现金付款（轻量）
- 改
OutMoneyManage第 63–65 行：现金.余额 = 金额（不置 0） - 改
Ajax OMDAdd：允许类别='现金' - 改
OutMoneyDocumentAdd：现金也可选 - 无需新表，约 3~5 处 SQL/页面修改
- 评估：低（3/10）
但只能按供应商+期间汇总付款，无法指定「哪张入库单」，不满足「单据单独核销」。
综合评估
| 维度 | 路径 A（单据级） | 路径 B（汇总级） |
|---|---|---|
| 是否符合「单独核销」 | 是 | 否 |
| 新增表/字段 | 2~3 处 | 0 |
| 新增页面 | 4~5 个 | 0~1 个 |
| 改动现有页面 | 6~8 个 | 3~5 个 |
| 与销售架构一致性 | 高 | 低 |
| 测试场景 | 多（部分付、退审、退货、重对账） | 少 |
| 整体复杂度 | 中高 | 低 |
建议
若目标是**「哪张采购入库单付了多少、还剩多少」**，应走路径 A，直接复用销售现结架构，核心增量是：
产品单据增加余额、付款现金明细增加关联单号（或等价字段）+ 扩展类别- 一套
PurchaseCashDocument*.asp付款页面 OutMoneyManage现金余额从「写死 0」改为「汇总未付单据余额」
若只需**「某供应商本期现金应付还能付多少」**，路径 B 几天内可完成，但做不到单张单据核销。
需提前确认的业务规则（影响实现细节）
- 付款时机：采购审核后即可付，还是必须等本期
采购对账完成？（销售是送货单「已对账」后才收现） - 核销粒度：按
产品单据（入库单）还是按采购单库（采购单）？ - 采购退货：退款是冲减应付余额，还是走独立收款/红字付款流程？
- 现金是否进
采购对账汇总：仅统计，还是付款也必须通过对账记录？
这些规则定下来后，路径 A 的实现边界会更清晰；需要的话我可以按你选定的规则出一版具体字段设计和改表 SQL 草案。