多门店零售合同系统系列之五

作者：合同吴彦祖

晚上九点多，法务收到一条合同系统通知。

一份新门店合同上传了新的协同版本。

系统记录得很清楚：

第六版。

上传人是合作方法务，上传时间是晚上九点零七分，属于第三轮合同协同。

第五版还在。

前两轮的评审意见也都在。

谁提出过解除条款的问题，谁要求调整付款条件，哪些意见已经解决，哪些人已经确认，系统全部保存得清清楚楚。

所以，这里不存在文件找不到的问题，也不存在大家分不清哪个是第五版、哪个是第六版的问题。

法务真正面对的是另一个问题。

对方上传第六版时，只留下一句话：

“已按照上一轮意见修改，请确认。”

法务打开合同。

三十多页。

新的公司水印，新的页眉，重新调整过的页码，正文看起来与第五版几乎一样。

对方到底接受了哪些意见？

有没有把已经谈妥的条款重新改回去？

除了解决上一轮提出的问题，还修改了哪些没有说明的内容？

付款、免租期、门店范围和违约责任有没有发生变化？

系统知道这是一份新版本。

但法务真正需要知道的，是这个新版本究竟新在哪里。

这才是合同谈到第五版、第六版以后，合同比对要解决的问题。

一、版本管理知道这是第六版，比对才知道第六版改了什么

在完整的合同系统里，所有版本本来就应该被统一管理。

第五版什么时候形成，第六版是谁提交，分别属于哪一轮协同，当前审批使用哪一版，最后签署的是哪一版，这些都可以记录得清清楚楚。

可版本号只回答了一个问题：哪份文件更新。

它回答不了另一个更重要的问题：更新的文件发生了什么变化。

第三方合同每谈一轮，系统里就可能形成一个新版本。

法务提出修改，双方在系统中形成第一轮处理版本；对方不接受，继续在协同中上传反馈版本；财务发现付款条件有问题，再进入下一轮；盖章前，对方还可能提交调整过签署页和格式的新版本。

版本多并不反常。

合同本来就是双方一点点谈出来的。

真正麻烦的是，每回来一个新版本，法务都要重新面对几十页正文。

如果从头看一遍，前面已经确认过的大量内容被重复审查。

如果只看对方声称修改的地方，又无法保证对方没有在其他位置顺手改动。

财务和已经审批过的人也面临同样的问题。

不给他们看，合同已经变化，他们不能继续为原来的意见负责。

让他们重新审一遍，整个审批过程又被拖回原点。

所以，版本管理并没有失效。

版本管理已经回答了每一版从哪里来、由谁提交、属于哪一轮协同。

它还需要与文档比对连接起来，把两个系统版本之间的变化直接摆到人面前。

二、合同不是只在协同时需要比对，而是要连续过三道关

很多人提到合同比对，首先想到的是法务谈判。

对方发回一个新版本，法务拿它与上一版比较，看看意见有没有落实。

这当然是最常见的场景。

但合同不会在协同结束以后突然停止变化。

协同谈完了，还要提交审批；审批被退回以后，还可能再次修改；所有人都同意了，合同还要生成盖章文件，甚至从电子文档变成扫描件。

每向前走一步，企业都需要确认一件事：眼前这份合同，还是不是刚才同意的那一份。

因此，一套真正进入合同系统的比对能力，至少要守住三道关。

合同阶段应该比较什么要解决的问题
协同阶段当前协同版本与上一版本，也可以从历史版本中任选两版对方是否落实本轮意见，有没有修改其他已经谈妥的内容
审批阶段当前送审版本与上一次送审或上一业务版本审批人这次面对的合同发生了哪些变化，原来的判断是否仍然有效
盖章归档阶段最终盖章版与审批确认版本实际准备签署、已经盖章归档的正文，是否仍是全体审批人同意的内容

第一道关发生在协同页面。

第五版是双方上一轮确认的结果，第六版是对方刚刚上传的新版本。法务可以默认比较相邻两版，也可以根据谈判过程，选择第三版与第六版，查看几轮协同累积下来究竟改了多少。

协同中的版本不能只有一个先后顺序。

系统还要告诉用户，谁上传了这一版，产生在哪一轮协同，当时处理的是哪些意见。这样法务看到一处变化时，才能回到这轮讨论中判断，它是双方谈出来的结果，还是对方没有说明的额外修改。

第二道关发生在审批页面。

合同进入审批以后，审批人不应该再去版本中心找文件，也不应该先下载两版合同，再使用外部工具检查。

审批页面应当直接提供“与上一版本比对”。

审批人打开当前合同，既能阅读完整正文，也能马上知道本次送审版与上一版之间新增了什么、删除了什么、修改了什么。

如果合同被驳回后重新提交，系统默认拿本次送审版本与驳回前的送审版本比较。前面的审批人重新收到待办时，不必把几十页合同再审一遍，也不会只凭发起人一句“已经按照意见修改”继续同意。

第三道关发生在盖章和归档以前。

审批通过，不代表后来拿去盖章的文件一定没有变化。

对方可能重新生成PDF，业务可能补充签署日期，也可能因为线下沟通又调整了一句话。如果系统只检查“有没有上传盖章件”，却不核对盖章件与审批确认版本，前面所有审批就可能同意的是A，最后真正签下来的却是B。

所以，最终盖章版进入系统以后，还要与审批确认版本再比一次。

这一关不是继续谈判。

它是在确认企业最后签署和归档的，正是前面所有人共同作出决定的那份合同。

三、比对入口必须长在业务页面里

比对发生在三个阶段，入口也不能只放在一个独立的“智能文档比对”菜单中。

协同人员需要在协同版本列表里比。

审批人需要在审批页面里比。

档案或印章人员需要在盖章文件核验页面里比。

他们使用的是同一套比对能力，但不会为了完成工作，先离开当前合同，再到另一个模块重新寻找文件。

在协同页面，用户点开第六版，系统默认把第五版放在它旁边，同时允许从版本列表中重新选择比较对象。

在审批页面，系统已经知道当前送审版和上一业务版本，可以直接显示“与上一版本比对”，不再要求审批人手动选两次。

在盖章页面，系统一边展示准备归档的最终文件，一边明确告诉用户，本次核验所采用的基准是哪个审批确认版本。

这时，版本列表不能只有“版本一、版本二、版本三”。

至少还要让人看见版本的上传人、上传时间、产生阶段、所属协同轮次，以及它与哪些版本已经完成过比对。

系统先把版本关系说明白，再把两个已经存在的PDF交给比对组件。

文件不需要下载。

也不需要重新上传。

【截图位置1：三个业务页面中的比对入口】

建议组合展示：协同版本列表中的版本比对、审批页面中的“与上一版本比对”、盖章归档页面中的“与审批确认版比对”。

四、一次完整的比对，应该让用户完成六件事

法务在协同页面选择第五版和第六版。

这时，一套完整的软件才真正开始工作。

第一件事，是确认比较对象。

页面要把原文档和新文档的名称、版本号和来源摆清楚。用户在点击开始以前，就应该知道自己正在拿哪两版合同作比较。

第二件事，是设置比对规则。

真实的合同经常带着公司水印、固定页眉和页脚。如果每页都重复出现的公司名称、地址和页码被当成正文变化，真正重要的条款差异就会被淹没。

因此，用户应当能够选择是否忽略页眉页脚，设置页眉和页脚所占的页面范围，并根据文件情况决定是否去除水印。

第三件事，是看到任务进度。

几十页PDF的识别和比对需要时间。页面不能在用户点击以后毫无反应，而要显示当前状态、处理进度和预计剩余时间。即使用户暂时离开，任务也应当在后台继续执行。

【截图位置2：比对设置与任务进度】

建议展示：原始文件、新文件、忽略页眉页脚、页眉页脚范围、去除水印，以及任务实时进度。

第四件事，是把两份合同真正放在一起读。

比对结果页可以分成三个区域：左边是原文档，中间是新文档，右边是差异列表。

新增内容用一种颜色标出，删除内容用另一种颜色标出。用户点击“上一处”或“下一处”，两份合同同步滚动到对应位置，不必在两边来回寻找同一句话。

【截图位置3：三栏比对结果页面】

建议使用真实结果页：左侧原文档、中间新文档、右侧差异列表，并保留上一处、下一处、页码跳转、连续滚动和同轴滚动等操作。

第五件事，是处理差异。

右侧列表要告诉用户一共发现多少处变化，其中多少处新增、多少处删除、多少处已经忽略。用户可以只看新增或者只看删除，也可以把纯格式、页码等无须继续关注的差异标记为忽略。

对某一处变化需要说明时，还可以留下备注。

忽略并不是删除结果。

它只是告诉后来的人，这处变化已经看过，确认不影响合同判断。

第六件事，是留下结果。

比对完成以后，系统保存HTML格式的结果，用户可以随时回到页面继续查看；需要下载、传阅或者归档时，还可以导出Word报告。报告中不仅要保留差异标记，还要写清比较的是哪份原文档、哪份新文档、何时完成，以及一共发现多少处差异。

至此，一个比对任务才算真正结束。

它不是点一下按钮，然后给人看一张花花绿绿的图片。

它是一套从选择版本、设置规则、等待处理，到阅读、处置和保存差异的完整工作台。

讲到这里，也先给正在处理合同的法务同事留一个可以直接使用的入口。

山西肇新科技官网提供了一个免费在线文档比对工具，不需要注册，打开网页、上传两份PDF，就可以直接发起比对。对于只是偶尔需要核对两个合同版本的人来说，不必先购买系统，也不必先完成一套复杂部署，就能把最费眼睛的找不同工作先交给工具。

如果合同不方便上传到网络，我这里还有一套可以在个人电脑上使用的免费客户端版本。它不需要另外部署OCR模型，文件在自己的电脑上完成处理，比对结果也保存在本地，更适合对文件保密和本地留存有要求的法务人员。

有需要的朋友可以留言。后面我也会单独写一篇文章，把客户端到哪里下载、怎样安装、怎样完成第一次比对讲清楚。

先想办法把法务从几十页合同里逐字寻找不同的苦活中解放出来。

五、真正进入合同系统以后，同一组版本不能反复计算

上午，法务已经比较过第五版和第六版。

下午，合同进入审批，审批人又点击了“与上一版本比对”。

如果系统再次把同样两份文件送去识别和计算，不但浪费时间和算力，还可能形成两个相互独立的任务记录。

到了晚上，另一个审批人打开合同，系统再算第三遍。

这就不是合同系统，只是在几个页面上重复安装了同一个比对按钮。

正确的做法，是让比对结果跟着版本组合保存。

第五版与第六版第一次完成比对以后，系统记录这两份文件、所采用的比对设置、任务状态和完整结果。

后来无论是协同人员、审批人还是档案人员，只要查看的仍然是同一组版本，并且比对规则没有变化，系统就直接打开已经完成的结果，不再重复提交任务。

只有文件内容发生变化、重新形成了版本，或者用户改变了页眉页脚、水印处理等比对规则，系统才需要生成新的比对任务。

这意味着一条合同记录中，还应当保存自己的比对历史。

哪两个版本比过，什么时候比的，任务是否完成，耗时多久，发现多少处新增和删除，报告存在哪里，都能从合同下面重新找到。

比对任务因此不再属于某一个操作人。

法务发起的结果，审批人可以继续看；审批阶段已经核验过的版本，后面的人员不必再算；几个月以后回看合同，也能知道当时依据的是哪一次结果。

一组版本，一份结果，多处使用。

这既节省计算，也避免同一件事在协同、审批和归档阶段得到三套互不关联的答案。

【截图位置5：合同下的比对历史】

建议展示：比较版本、任务ID、状态、开始与完成时间、分析耗时、差异数量、查看结果和下载报告。若同一版本组合已有结果，页面应直接进入历史结果。

六、比对结果要回到合同流程，而不是停在工具页面

第五版与第六版一共发现二十三处差异。

十八处新增，五处删除。

法务沿着差异列表往下看，发现对方确实补充了乙方信息，也按照上一轮意见修改了解除条款。

但在付款条款中，“验收合格后”几个字也被删掉了。

这处变化没有出现在对方的说明里。

在协同阶段，法务需要带着这次比对结果继续讨论。

到了审批阶段，审批人需要看到这处变化以及后续处理结果，再决定是否同意。

如果最后盖章版与审批确认版仍然存在正文差异，档案人员则不能只点一下“归档”，而要把合同重新交给相关人员确认。

比对组件负责找出差异。

合同系统负责决定差异出现以后，工作怎样继续。

两者连在一起，合同比对才不再是一座孤岛。

从技术上看，这种连接可以通过API提交任务，再把进度和结果嵌入合同页面；也可以根据企业自己的界面规范，对结果页进行定制。

但对用户来说，背后的集成方式并不重要。

他只需要在当前正在办理的合同里，看见正确的版本、已经保存的结果和下一步应该处理的事情。

七、盖章版是扫描件时，还要补上OCR这最后一段路

协同和审批阶段使用的通常是电子PDF。

到了最终盖章环节，企业收到的却可能是扫描件。

扫描页本质上是一张图片，没有能够直接读取的文字层。要拿它与审批确认版本比较，需要OCR先识别页面内容，再把识别结果送入比对。

这项能力尤其适合最后一道核验。

因为企业此时关心的已经不是对方愿不愿意修改，而是印章下面的那份正文，究竟有没有偏离审批通过的版本。

不过，OCR识别不能代替原件。

扫描模糊、印章遮挡、数字相近，都可能造成识别误差。金额、期限、主体名称等关键差异，仍然需要回到原始页面由人确认。

OCR帮助企业把几十页人工核对缩小到少数可疑位置。

最后作出判断的，仍然是看过原件的人。

八、管住最终版本，靠的是一条连续的比对链

法务看完第五版与第六版的结果，把付款条件的额外变化重新放回协同。

对方确认是修改时误删，随后上传第七版。

第七版与第六版完成比对，差异只剩下付款条件的恢复。

合同随后进入审批。

审批人直接查看已经保存的版本结果，没有重新计算，也没有从头再读三十页正文。

审批通过以后，最终盖章版又与审批确认版本完成最后一次核验。

这一次，没有发现正文变化。

合同终于归档。

从第五版到第六版，是协同中的谈判核验。

从修改版到送审版，是审批人的责任核验。

从审批确认版到最终盖章版，是企业签署前的底线核验。

每一道关口都在比。

但同一组版本，只比一次，结果被保存下来，供后面的业务继续使用。

所以，企业所谓“管住最终版本”，不是给最后一个文件贴上“最终版”三个字。

而是让合同每次发生变化以后，都有一个可以重新确认的依据；让协同、审批和盖章看到的是同一条版本链，而不是各管一段、各比一次。

版本管理告诉企业，现在走到哪一版。

合同比对告诉企业，这一版究竟改了什么。

结果复用则让所有参与者，始终站在同一份事实之上继续工作。

三件事连在一起，最后盖下印章的那份合同，才真正是企业同意签署的合同。

我是合同吴彦祖。

下一篇，我们换一个零售行业更加特殊的问题：加盟门店并不属于总部组织，合同为什么仍然要围绕门店管理？