用途：识别那些“上线后才发现模型表达不了”的高风险点
| 难点 |
为什么难 |
设计要点 |
| 拆单与合单 |
一份需求按供应商/交期拆分，多份需求合并下单 |
单据关系用多对多关系表 + 来源链路，禁止单一 parent_id |
| 订单变更 |
数量、价格、交期变更后需保留原值与生效版本，并同步供应商与财务 |
变更单模型（原值/新值/审批/生效时间），PO 版本化 |
| 配额分配 |
多供应商比例执行、缺货回退、事后回补 |
配额独立对象 + 累计执行台账 + 回退规则 |
| 多币种与汇率 |
取值时点、汇兑损益、报表口径 |
契约里固定汇率来源与时点，凭证侧处理损益 |
| 阶梯价与返利 |
价格依赖累计量/金额，结算跨期 |
计费规则引擎化，保留计算过程快照 |
| 预算控制 |
占用/释放/超预算例外、跨期与组织维度 |
预算占用与释放要跟随单据生命周期，避免“占而不用” |
| 目录 vs 协议 vs 临时价 |
取价优先级与可解释性 |
明确优先级链并在下单时展示“命中了哪条规则” |
| 部分收货与分批开票 |
累计量控制、剩余可开票量 |
行级“已收/已检/已开票”三套累计量 |
| 服务类与无实物采购 |
没有收货环节，验收即履约 |
用验收单/工时确认替代 GR，匹配规则分支 |
| 寄售与 VMI |
消耗前所有权与应付确认时点 |
库存属性与结算触发分离建模 |
| 供应商协同 |
确认、发货、对账、异议都在外部发生 |
门户 + 消息回执 + 超时策略，状态以平台为权威 |
| 围标与关联风险 |
需要跨供应商特征比对 |
报价文件指纹、账户/联系人/设备/IP 关联分析 |
| 合规审计 |
每一笔要能回答“谁、何时、依据什么” |
全链路留痕、快照冗余、不可篡改的审批记录 |
| 历史数据可解释 |
组织、物料、价格都会变 |
单据保存关键主数据快照，不依赖当前值反推 |
- 单据要能表达“部分”和“多次”：部分收货、分批开票、多次付款、多轮报价——绝大多数返工来自把“部分”当成“一次性”。
- 规则要可解释：取价、配额、审批路由、容差判定，都要能在界面上回答“为什么是这个结果/价格/审批人”。
- 历史要自证：单据上的关键字段（价格、税率、组织、供应商信息）做快照冗余，避免“当前主数据变了，历史单据说不清”。
- 变更用覆盖更新：一旦供应商或财务质疑“当初不是这个价”，无据可查。
- 状态由多方共写：采购、仓库、财务、供应商门户都能改状态，最终没人能解释当前状态。
- 把特例写进代码分支：目录采购、寄售、服务采购各来一套私有字段，模型迅速碎片化。
| 误区 |
修正 |
| 单据关系用单一 parent_id |
用关系表支持多对多与拆分合并 |
| 变更用覆盖更新 |
变更单模型保留原值、新值与生效时间 |
| 取价规则散在代码分支 |
规则集中并可解释（命中哪条协议、哪个阶梯） |
| 主数据当前值反推历史 |
单据保存关键字段快照 |
- 主流 ERP 采购模块（信息记录、确认控制、容差码、评估响应）文档
- 《Purchasing and Supply Chain Management》（Lysons & Farrington）