实施指南
既有流程不能改时，合同系统怎么适配：字段前置与外部审批链
企业既有的填表习惯和审批系统往往动不了，合同系统要去适配。两个常见做法：把台账字段前置成抽取加确认，以及把审批编排交回外部费控或 OA 系统，以及各自的边界和风险。
- 作者
- Zico 团队
- 发布
约 7 分钟阅读
结论
选型阶段谈的是功能覆盖，实施阶段暴露的往往是另一类问题：企业已有的填表习惯、已有的审批系统动不了，而合同系统默认自己是流程的主人。两边都不让步，项目就停在这里。
可动的一方通常是合同系统。下面两件事来自实际实施：一件是把台账字段从审核之后移到上传之时，用抽取加确认替代手工补录；另一件是把审批该怎么走交回企业原来的费控系统，合同系统只负责把合同内容送进那条链路。两件事都始于某一家客户的特殊要求，但都不应该以一次性代码收尾。
| 现状 | 通常的做法 | 适配的做法 |
|---|---|---|
| 业务在上传时填一遍，审核后还要按台账口径再填一遍 | 培训业务部门认真填，或由法务事后补录 | 上传即抽取字段，人核对而不是手填 |
| 字段前置后，协商阶段改了金额或付款方式 | 靠经办人记得回头改字段 | 提交前做一次字段与正文的一致性校对 |
| 涉资金的审批必须走企业自研的费控系统 | 在合同系统里重建一套审批矩阵 | 由费控系统返回审批链，合并进合同系统的审批节点 |
| 不涉资金的审批走协同平台自带 OA | 让员工记住两套入口分别在哪 | 两条链路都从合同系统发起，入口只有一个 |
同一份合同，字段为什么要填两遍
非诉合同的常见走法是：业务把合同传上来，填完表单提交审核；法务审完之后，再由人按台账口径把当事人、金额、期限、付款节点这些字段补进去。同一份合同的同一批信息，在流程的两端各录了一次。
出现这种重复有它的来由。表单字段是给业务看的，问的是这单要干什么；台账字段是给法务和财务看的，问的是这份合同在账上长什么样。两套口径不一样，系统就干脆把它们放在流程的两头，各填各的。
为什么不能靠「让业务填仔细点」解决
法务、财务这类中台部门在合同流程里处在中段，业务部门在两端。任何让业务多填一遍的设计，落地时都会被绕开：要么填得潦草，要么拖着不提交，最后仍然由法务补齐。所以少填一遍不是体验层面的优化，它直接决定台账的完整度和准确度。
这也是不少企业在协同平台自带的合同能力之外另找系统的原因。平台侧的表单能力通常是通用的，改不动字段出现的时机；而字段什么时候出现、由谁确认，恰恰是这类需求的核心。
把字段移到前面：抽取加确认
可行的做法是让字段在上传那一刻就产生，但不由人打字产生。合同上传后由系统抽取台账需要的字段，带置信度呈现，经办人做的是核对与更正，不是从零录入。审核开始时台账已经是填好的状态，审核通过即可进入审批，中间不再插入一道补录。
- 业务上传合同正文，同时填写业务侧必须由人说明的少量信息。
- 系统抽取当事人、金额、期限、付款节点等台账字段，逐项给出置信度。
- 经办人逐条核对，改掉抽错的，补上抽不到的，确认后进入审核。
- 法务审核合同实质内容，此时台账字段已经在位，不再单列一道补录工作。
- 提交审批前，系统把当前版本正文与已确认的字段再比一次，不一致的逐条提示。
信息抽取本身是已可用的能力，存量合同批量入库走的也是同一条路径：抽取结果带置信度，允许人工校正。区别只在于触发时机，一个是历史数据迁移时批量跑，一个是新合同进来时即时跑。
前置之后：终版一换，字段就可能错
字段前置解决了重复录入，同时引入一个新问题。审核和协商会产生新版本：对方回稿替换了正文，金额谈下来了，付款方式从一次性改成分期。字段是在第一版确认的，如果没有任何机制回看，台账就会停在旧数字上，而且这种错不会当场暴露，往往到对账或者履约提醒的时候才发现。
处理办法是在提交审批之前加一次校对：把当前版本的正文与此前确认过的字段做一次比对，对不上的逐条列出来，指明是哪个字段、正文里现在写的是什么。经办人可以按提示改字段，也可以在确认后照原样提交，系统记录这次确认。
为什么是提示，不是强制拦截
合同业务里，字段与正文对不上并不总是错误。框架合同的总金额本来就待定，补充协议只改其中一条而其余沿用主合同，这些情况下提示是噪音。强制拦截会把例外变成阻塞，逼着经办人找绕开的办法，最终连真正的错配也一起被绕过去了。提示加留痕的组合更稳：判断交给人，证据留给审计。
评估这类能力时可以直接问两个问题：校对发生在提交审批之前还是之后，以及用户选择照原样提交时，这次选择有没有被记录下来。前者决定错配能不能在进入审批链之前拦住，后者决定事后复盘时能不能定位到是谁在什么时候放行的。
审批不一定要由合同系统编排
集团内部有两套甚至更多审批系统是常态。涉及花钱的走自研费控或预算系统，不涉及花钱的走协同平台自带的 OA，两套系统各有各的规则与历史。合同大部分涉及资金，于是新上的合同系统正好撞在这条分界线上。
这时有两条路。一条是在合同系统里按费控的规则重建一套审批矩阵，代价是同一套规则维护两份，费控那边调整一次，这边就要跟着改一次，不同步就会出现两个系统给出不同审批人的情况。另一条是承认审批规则的归属不在合同系统，由费控系统按合同类型、部门、金额等要素返回一条审批链，合同系统把这条链合并到自己的审批节点上执行。
| 事项 | 由谁决定 | 合同系统这一侧做什么 |
|---|---|---|
| 审批规则：什么合同该谁批、批几级 | 企业原有的费控或 OA 系统 | 传入合同要素，接收返回的审批链 |
| 审批人身份：链上的人对应到谁 | 协同平台的组织架构 | 按同一套目录解析，不另建通讯录 |
| 被审批的内容与全程留痕 | 合同系统 | 承载正文、版本、字段与审批意见，可追溯可导出 |
这条路的前提
两边的人员身份必须能对上。企业整体在同一个协同平台的组织架构之下，外部系统返回的审批人才能被解析成合同系统里的同一个人；如果两侧各有一套账号体系且没有映射关系，返回的链路落不了地，得先解决身份问题再谈审批对接。
另一个要确认的是失败时怎么办。外部系统没有返回、返回的审批人已离职、返回的链路为空，这几种情况都要有明确的降级方式，通常是转入合同系统自己配置的兜底审批链并通知管理员，而不是让合同停在一个没有下一步的状态里。
定制怎么不变成一次性代码
上面两件事都起于单个客户的特殊要求，一个要求字段别填两遍，一个要求审批别在这里编排。这类要求放在合同管理的通用功能清单里都排不上号，但它们恰恰是项目能不能上线的关键。问题在于怎么收尾：做成给这家客户的分支代码，下一家提类似要求时从头再来；做成配置项，则这一次的实施变成产品的一项能力。
判断标准是这次改动能不能被表达成配置。字段在什么时候出现、由谁确认、校对发生在哪一步，这些是流程配置；审批链来自内部规则还是外部系统返回，可以是审批节点的一种类型而不是一段特判逻辑。能表达成配置的就沉淀下来，表达不了的才是真正的定制开发，按人天计费。
对采购方而言，这个问题比功能清单更能区分供应商。清单上的条目大同小异，而实施期遇到的都是清单里没有的事。
这篇的两段出自我们自己的实施，立场先声明：Zico 把这类要求当作要收进配置的能力处理，而不是给单个客户留一份分支代码。这只是我们的做法，不构成对其他产品的判断，上面那个问题请对每一家供应商都问一遍。