合同改了五六版系统怎样管住最终签署版本多门店零售合同系统系列之五作者合同吴彦祖晚上九点多法务收到一条合同系统通知。一份新门店合同上传了新的协同版本。系统记录得很清楚第六版。上传人是合作方法务上传时间是晚上九点零七分属于第三轮合同协同。第五版还在。前两轮的评审意见也都在。谁提出过解除条款的问题谁要求调整付款条件哪些意见已经解决哪些人已经确认系统全部保存得清清楚楚。所以这里不存在文件找不到的问题也不存在大家分不清哪个是第五版、哪个是第六版的问题。法务真正面对的是另一个问题。对方上传第六版时只留下一句话“已按照上一轮意见修改请确认。”法务打开合同。三十多页。新的公司水印新的页眉重新调整过的页码正文看起来与第五版几乎一样。对方到底接受了哪些意见有没有把已经谈妥的条款重新改回去除了解决上一轮提出的问题还修改了哪些没有说明的内容付款、免租期、门店范围和违约责任有没有发生变化系统知道这是一份新版本。但法务真正需要知道的是这个新版本究竟新在哪里。这才是合同谈到第五版、第六版以后合同比对要解决的问题。一、版本管理知道这是第六版比对才知道第六版改了什么在完整的合同系统里所有版本本来就应该被统一管理。第五版什么时候形成第六版是谁提交分别属于哪一轮协同当前审批使用哪一版最后签署的是哪一版这些都可以记录得清清楚楚。可版本号只回答了一个问题哪份文件更新。它回答不了另一个更重要的问题更新的文件发生了什么变化。第三方合同每谈一轮系统里就可能形成一个新版本。法务提出修改双方在系统中形成第一轮处理版本对方不接受继续在协同中上传反馈版本财务发现付款条件有问题再进入下一轮盖章前对方还可能提交调整过签署页和格式的新版本。版本多并不反常。合同本来就是双方一点点谈出来的。真正麻烦的是每回来一个新版本法务都要重新面对几十页正文。如果从头看一遍前面已经确认过的大量内容被重复审查。如果只看对方声称修改的地方又无法保证对方没有在其他位置顺手改动。财务和已经审批过的人也面临同样的问题。不给他们看合同已经变化他们不能继续为原来的意见负责。让他们重新审一遍整个审批过程又被拖回原点。所以版本管理并没有失效。版本管理已经回答了每一版从哪里来、由谁提交、属于哪一轮协同。它还需要与文档比对连接起来把两个系统版本之间的变化直接摆到人面前。二、合同不是只在协同时需要比对而是要连续过三道关很多人提到合同比对首先想到的是法务谈判。对方发回一个新版本法务拿它与上一版比较看看意见有没有落实。这当然是最常见的场景。但合同不会在协同结束以后突然停止变化。协同谈完了还要提交审批审批被退回以后还可能再次修改所有人都同意了合同还要生成盖章文件甚至从电子文档变成扫描件。每向前走一步企业都需要确认一件事眼前这份合同还是不是刚才同意的那一份。因此一套真正进入合同系统的比对能力至少要守住三道关。合同阶段应该比较什么要解决的问题协同阶段当前协同版本与上一版本也可以从历史版本中任选两版对方是否落实本轮意见有没有修改其他已经谈妥的内容审批阶段当前送审版本与上一次送审或上一业务版本审批人这次面对的合同发生了哪些变化原来的判断是否仍然有效盖章归档阶段最终盖章版与审批确认版本实际准备签署、已经盖章归档的正文是否仍是全体审批人同意的内容第一道关发生在协同页面。第五版是双方上一轮确认的结果第六版是对方刚刚上传的新版本。法务可以默认比较相邻两版也可以根据谈判过程选择第三版与第六版查看几轮协同累积下来究竟改了多少。协同中的版本不能只有一个先后顺序。系统还要告诉用户谁上传了这一版产生在哪一轮协同当时处理的是哪些意见。这样法务看到一处变化时才能回到这轮讨论中判断它是双方谈出来的结果还是对方没有说明的额外修改。第二道关发生在审批页面。合同进入审批以后审批人不应该再去版本中心找文件也不应该先下载两版合同再使用外部工具检查。审批页面应当直接提供“与上一版本比对”。审批人打开当前合同既能阅读完整正文也能马上知道本次送审版与上一版之间新增了什么、删除了什么、修改了什么。如果合同被驳回后重新提交系统默认拿本次送审版本与驳回前的送审版本比较。前面的审批人重新收到待办时不必把几十页合同再审一遍也不会只凭发起人一句“已经按照意见修改”继续同意。第三道关发生在盖章和归档以前。审批通过不代表后来拿去盖章的文件一定没有变化。对方可能重新生成PDF业务可能补充签署日期也可能因为线下沟通又调整了一句话。如果系统只检查“有没有上传盖章件”却不核对盖章件与审批确认版本前面所有审批就可能同意的是A最后真正签下来的却是B。所以最终盖章版进入系统以后还要与审批确认版本再比一次。这一关不是继续谈判。它是在确认企业最后签署和归档的正是前面所有人共同作出决定的那份合同。三、比对入口必须长在业务页面里比对发生在三个阶段入口也不能只放在一个独立的“智能文档比对”菜单中。协同人员需要在协同版本列表里比。审批人需要在审批页面里比。档案或印章人员需要在盖章文件核验页面里比。他们使用的是同一套比对能力但不会为了完成工作先离开当前合同再到另一个模块重新寻找文件。在协同页面用户点开第六版系统默认把第五版放在它旁边同时允许从版本列表中重新选择比较对象。在审批页面系统已经知道当前送审版和上一业务版本可以直接显示“与上一版本比对”不再要求审批人手动选两次。在盖章页面系统一边展示准备归档的最终文件一边明确告诉用户本次核验所采用的基准是哪个审批确认版本。这时版本列表不能只有“版本一、版本二、版本三”。至少还要让人看见版本的上传人、上传时间、产生阶段、所属协同轮次以及它与哪些版本已经完成过比对。系统先把版本关系说明白再把两个已经存在的PDF交给比对组件。文件不需要下载。也不需要重新上传。四、一次完整的比对应该让用户完成六件事法务在协同页面选择第五版和第六版。这时一套完整的软件才真正开始工作。第一件事是确认比较对象。页面要把原文档和新文档的名称、版本号和来源摆清楚。用户在点击开始以前就应该知道自己正在拿哪两版合同作比较。第二件事是设置比对规则。真实的合同经常带着公司水印、固定页眉和页脚。如果每页都重复出现的公司名称、地址和页码被当成正文变化真正重要的条款差异就会被淹没。因此用户应当能够选择是否忽略页眉页脚设置页眉和页脚所占的页面范围并根据文件情况决定是否去除水印。第三件事是看到任务进度。几十页PDF的识别和比对需要时间。页面不能在用户点击以后毫无反应而要显示当前状态、处理进度和预计剩余时间。即使用户暂时离开任务也应当在后台继续执行。第四件事是把两份合同真正放在一起读。比对结果页可以分成三个区域左边是原文档中间是新文档右边是差异列表。新增内容用一种颜色标出删除内容用另一种颜色标出。用户点击“上一处”或“下一处”两份合同同步滚动到对应位置不必在两边来回寻找同一句话。第五件事是处理差异。右侧列表要告诉用户一共发现多少处变化其中多少处新增、多少处删除、多少处已经忽略。用户可以只看新增或者只看删除也可以把纯格式、页码等无须继续关注的差异标记为忽略。对某一处变化需要说明时还可以留下备注。忽略并不是删除结果。它只是告诉后来的人这处变化已经看过确认不影响合同判断。第六件事是留下结果。比对完成以后系统保存HTML格式的结果用户可以随时回到页面继续查看需要下载、传阅或者归档时还可以导出Word报告。报告中不仅要保留差异标记还要写清比较的是哪份原文档、哪份新文档、何时完成以及一共发现多少处差异。至此一个比对任务才算真正结束。它不是点一下按钮然后给人看一张花花绿绿的图片。它是一套从选择版本、设置规则、等待处理到阅读、处置和保存差异的完整工作台。讲到这里也先给正在处理合同的法务同事留一个可以直接使用的入口。山西肇新科技官网提供了一个免费在线文档比对工具不需要注册打开网页、上传两份PDF就可以直接发起比对。对于只是偶尔需要核对两个合同版本的人来说不必先购买系统也不必先完成一套复杂部署就能把最费眼睛的找不同工作先交给工具。如果合同不方便上传到网络我这里还有一套可以在个人电脑上使用的免费客户端版本。它不需要另外部署OCR模型文件在自己的电脑上完成处理比对结果也保存在本地更适合对文件保密和本地留存有要求的法务人员。有需要的朋友可以留言。后面我也会单独写一篇文章把客户端到哪里下载、怎样安装、怎样完成第一次比对讲清楚。先想办法把法务从几十页合同里逐字寻找不同的苦活中解放出来。五、真正进入合同系统以后同一组版本不能反复计算上午法务已经比较过第五版和第六版。下午合同进入审批审批人又点击了“与上一版本比对”。如果系统再次把同样两份文件送去识别和计算不但浪费时间和算力还可能形成两个相互独立的任务记录。到了晚上另一个审批人打开合同系统再算第三遍。这就不是合同系统只是在几个页面上重复安装了同一个比对按钮。正确的做法是让比对结果跟着版本组合保存。第五版与第六版第一次完成比对以后系统记录这两份文件、所采用的比对设置、任务状态和完整结果。后来无论是协同人员、审批人还是档案人员只要查看的仍然是同一组版本并且比对规则没有变化系统就直接打开已经完成的结果不再重复提交任务。只有文件内容发生变化、重新形成了版本或者用户改变了页眉页脚、水印处理等比对规则系统才需要生成新的比对任务。这意味着一条合同记录中还应当保存自己的比对历史。哪两个版本比过什么时候比的任务是否完成耗时多久发现多少处新增和删除报告存在哪里都能从合同下面重新找到。比对任务因此不再属于某一个操作人。法务发起的结果审批人可以继续看审批阶段已经核验过的版本后面的人员不必再算几个月以后回看合同也能知道当时依据的是哪一次结果。一组版本一份结果多处使用。这既节省计算也避免同一件事在协同、审批和归档阶段得到三套互不关联的答案。六、比对结果要回到合同流程而不是停在工具页面第五版与第六版一共发现二十三处差异。十八处新增五处删除。法务沿着差异列表往下看发现对方确实补充了乙方信息也按照上一轮意见修改了解除条款。但在付款条款中“验收合格后”几个字也被删掉了。这处变化没有出现在对方的说明里。在协同阶段法务需要带着这次比对结果继续讨论。到了审批阶段审批人需要看到这处变化以及后续处理结果再决定是否同意。如果最后盖章版与审批确认版仍然存在正文差异档案人员则不能只点一下“归档”而要把合同重新交给相关人员确认。比对组件负责找出差异。合同系统负责决定差异出现以后工作怎样继续。两者连在一起合同比对才不再是一座孤岛。从技术上看这种连接可以通过API提交任务再把进度和结果嵌入合同页面也可以根据企业自己的界面规范对结果页进行定制。但对用户来说背后的集成方式并不重要。他只需要在当前正在办理的合同里看见正确的版本、已经保存的结果和下一步应该处理的事情。七、盖章版是扫描件时还要补上OCR这最后一段路协同和审批阶段使用的通常是电子PDF。到了最终盖章环节企业收到的却可能是扫描件。扫描页本质上是一张图片没有能够直接读取的文字层。要拿它与审批确认版本比较需要OCR先识别页面内容再把识别结果送入比对。这项能力尤其适合最后一道核验。因为企业此时关心的已经不是对方愿不愿意修改而是印章下面的那份正文究竟有没有偏离审批通过的版本。不过OCR识别不能代替原件。扫描模糊、印章遮挡、数字相近都可能造成识别误差。金额、期限、主体名称等关键差异仍然需要回到原始页面由人确认。OCR帮助企业把几十页人工核对缩小到少数可疑位置。最后作出判断的仍然是看过原件的人。八、管住最终版本靠的是一条连续的比对链法务看完第五版与第六版的结果把付款条件的额外变化重新放回协同。对方确认是修改时误删随后上传第七版。第七版与第六版完成比对差异只剩下付款条件的恢复。合同随后进入审批。审批人直接查看已经保存的版本结果没有重新计算也没有从头再读三十页正文。审批通过以后最终盖章版又与审批确认版本完成最后一次核验。这一次没有发现正文变化。合同终于归档。从第五版到第六版是协同中的谈判核验。从修改版到送审版是审批人的责任核验。从审批确认版到最终盖章版是企业签署前的底线核验。每一道关口都在比。但同一组版本只比一次结果被保存下来供后面的业务继续使用。所以企业所谓“管住最终版本”不是给最后一个文件贴上“最终版”三个字。而是让合同每次发生变化以后都有一个可以重新确认的依据让协同、审批和盖章看到的是同一条版本链而不是各管一段、各比一次。版本管理告诉企业现在走到哪一版。合同比对告诉企业这一版究竟改了什么。结果复用则让所有参与者始终站在同一份事实之上继续工作。三件事连在一起最后盖下印章的那份合同才真正是企业同意签署的合同。我是合同吴彦祖。下一篇我们换一个零售行业更加特殊的问题加盟门店并不属于总部组织合同为什么仍然要围绕门店管理