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

作者：合同吴彦祖

上一篇写完以后，有朋友问我：

合同管理系统，不就是上传一份文件，找几个人审批，审批完成以后存起来吗？

这个理解不能说错。

因为很多企业第一次买合同系统，最急着解决的就是这三件事：合同别再躺在个人电脑里，审批别再追着领导跑，法务查文件时别再翻半天柜子。

上传、审批、归档，确实能解决问题。

但它解决的，只是一份合同最容易被看见的那一段。

一份合同真正开始，往往早于审批。

业务先找到合作方，确认主体和资质，选择合同类型，寻找模板，谈判条款，准备附件。合同审批通过以后，还要用印、签署、付款、交付、验收、续签；合作中途发生变化，还会出现补充协议、中止、解除、责任人交接和档案借阅。

如果系统只管中间那几天的审批，前面的材料仍在微信里，后面的履约仍在Excel里，那么企业只是把一段流程搬到了线上，并没有把合同管起来。

这也是为什么，谈合同系统的“基本功能”，不能看首页放了多少菜单，也不能看演示时能不能点出一条绿色的审批线。

真正的判断标准只有一个：

一份合同从产生到结束，能不能始终留在同一条管理链上。

一、所谓基本功能，不是功能少，而是闭环不能断

“基本”这个词很容易让人误会。

有人把它理解成低配版，认为模板、审批和归档是基本功能，转办、驳回、履约、变更、台账已经属于高级能力。

也有人按使用频率来划分：每天都用的是基本功能，偶尔才发生的解除、移交和借阅，可以以后再做。

这两种分法都有问题。

基本功能并不是“最常用的几个按钮”，而是维持合同生命周期完整所必需的能力。一个环节平时用得少，不等于它不重要。

灭火器平时也很少用，但不能因为一年没着火，就把它从楼道里搬走。

合同解除、审批撤回、人员交接也是一样。顺利的时候，它们没有存在感；一旦事情发生，系统没有对应入口，业务就只能回到线下处理。线下处理完以后，系统里的合同还保持着旧状态，企业从此多出两套事实。

一套写在合同和聊天记录里。

一套留在系统页面里。

这才是最麻烦的地方。

不妨先把一套基本合同系统应该承担的事情摊开来看：

合同阶段应具备的基本能力必须回答的问题
签约准备相对方、签约主体、资质、合同分类、模板、标准条款和业务表单和谁签、由谁签、签什么、依据什么签？
起草与修改模板起草、空白起草、上传对方合同、附件管理、修改留痕、历史版本、基础协同和文本比对当前审的是哪一份，合同是怎样改成现在这样的？
合同审批流程匹配、串并行审批、同意、驳回、退回、转办、加签、撤回、终止和重新提交现在轮到谁处理，出现问题以后回到哪里，责任是否留痕？
用印与签署用印申请、印章控制、线下签署、电子签署、签署顺序、签署状态和生效文件确认谁盖的章、谁签的字，最后生效的是不是审批通过的版本？
履约管理收付款计划、交付、验收、服务任务、到期提醒、履约证据和异常记录合同签完以后，双方有没有按照约定执行？
变化处理补充协议、变更、中止、恢复、终止、解除、作废和争议记录合同发生变化以后，原来的计划和责任怎样调整？
档案管理编号、归档、原件、借阅、归还、历史合同导入和文件查询正式合同在哪里，谁拿走过，历史资料能不能找到？
台账与控制查询、统计、提醒、角色权限、数据权限、文件权限和操作日志谁能看、能看什么，管理者怎样掌握整体情况？

这八组能力，并不是八座彼此独立的小岛。

相对方信息要进入合同，合同金额要生成付款计划，审批通过的版本要进入签署，签署完成的文件要进入归档，合同变更又要影响后续履约。

前一步产生的数据，必须成为后一步工作的依据。

这才叫闭环。

写到这里，可能有人会问：

道理都明白了，如果一家企业现在就想搭一套基础合同系统，难道还要从第一张表、第一条审批流开始开发吗？

不需要。

在梳理这类产品时，我在Gitee上发现了一套开源合同管理系统。从公开数据来看，它是同类项目中Star数量最多的一个；从功能设计来看，也更贴近企业真实的合同管理场景。

从项目公开资料来看，它不是一张停留在纸面上的产品原型，而是提供了完整源码和部署说明的合同管理项目。项目覆盖合同起草、模板管理、审批流转、合同编号、在线编辑和合同台账等核心能力，也支持通过OnlyOffice进行在线文档编辑。

换句话说，如果一家企业当前最迫切的需求，是先把散落在电脑、聊天软件和共享盘里的合同收回来，把起草、审批和台账建立起来，那么没有必要再从零开发一遍。

有需要的读者可以直接下载项目源码，准备相应的运行环境和数据库，再按照仓库中的说明完成配置和部署。这样至少可以先搭起一套能够运行的基础合同系统，不必从第一张表、第一条流程重新开发。

如果企业有自己的技术团队，还可以直接在这套底座上调整表单、流程、页面和业务规则。对于想研究合同系统产品结构的产品经理和开发者，它也提供了一份可以实际运行、可以打开代码查看的参考，而不是停留在几张功能清单上。

肇新合同管理系统（开源版）
项目地址：https://gitee.com/fanhuibin1/zhaoxin-contract
读者可自行下载源码，并根据仓库README和部署文档尝试本地或服务器部署。

这类开源项目的价值，在于把起草、审批、在线编辑和合同台账这些基础能力做成了一套可以实际运行的参考。企业可以先了解系统怎样组织合同数据和业务流程，再决定直接使用、继续开发，还是选择其他产品，而不必只根据几张功能清单作出判断。

当然，能够下载和部署，不等于不需要技术评估。准备正式用于生产环境以前，企业仍然要根据自己的服务器环境、数据安全要求、维护能力和业务制度，判断项目是否适合直接使用。

但这仍然只回答了基础问题。能部署一套基础合同系统，与能解决大型多门店零售企业的全部问题，并不是一回事。

从公开功能来看，这个开源版本首先解决的是“合同能不能进入一个系统，形成基本管理闭环”。当企业进一步遇到跨部门深度协同、复杂文件比对、加盟门店管理、动态权限、财务和快递对接、灵活数据视图以及AI预审时，就需要在这个底座上继续升级。

这个边界必须讲清楚。

对使用者来说，开源项目的意义并不是把所有问题说成已经解决，而是提供一个不用从零开始解决第一个问题的选择。

基本功能解决的，是合同能不能被完整地管起来。

至于合同进入复杂企业以后管得够不够深，那是下一层问题。

二、合同不是从提交审批的那一刻才出生

很多系统把“新建合同”设计成上传文件、填写名称、选择审批人。

看起来很简洁。

但业务真正开始签一份合同时，脑子里想的并不是这三个字段。

他先要确认合作方是谁，营业执照和授权是否有效；再确认使用哪一个签约主体，属于采购、租赁、装修还是服务合同；有企业模板就从模板起草，没有模板就上传对方发来的合同；涉及项目、门店或者主合同的，还要把它们关联起来。

这些工作统称为签约准备。

准备做不好，后面的审批只会变成一场大型补资料运动。

法务发现主体名称不对，退回。

财务发现付款条件没填，退回。

负责人发现缺少报价依据，再退回。

系统看起来流程严谨，实际上大家只是在用审批节点替前面的信息缺口擦屁股。

所以，一套基本合同系统首先要管理三类东西。

第一类是签约对象，包括我方主体、合同相对方、联系人和必要资质。

第二类是签约依据，包括合同类型、企业模板、标准条款、项目资料和相关附件。

第三类是业务信息，包括合同金额、期限、收付款安排、履约事项以及合同之间的关联关系。

准备完成以后，才进入起草。

起草也不等于系统里必须有一个华丽的在线编辑器。

企业可能从标准模板生成合同，也可能上传一份Word文件，还可能像上一篇说的那样，直接收到合作方发来的PDF或者扫描件。基本系统要做的，是允许不同来源的合同进入同一套管理过程，并且知道哪一份是当前正文，哪些是附件，哪一版已经作废。

合同修改以后，要保留历史版本和修改人；业务与法务需要交换意见时，要有基本评论和协同记录；两个版本之间存在差异时，要能做基础文本比对。

所以，基础协同和基础比对也属于基本能力。

它们未必一开始就能处理所有复杂格式，也未必能支持十几个人跨企业反复谈判，但一套合同系统至少不能让合同每修改一次，就重新掉回邮件、微信和共享盘。

否则，审批人看到的只是最后一份文件，却不知道它从哪里来，也不知道前面的意见处理过没有。

三、转办、驳回和撤回，当然都算基本功能

合同进入审批以后，最简单的流程只有两个按钮：同意和拒绝。

现实世界没有这么简单。

审批人收到合同，发现这件事不应该由自己判断，需要交给另一名负责人，这是转办。

法务发现材料不齐，希望经办人补充以后重新提交，这是驳回。

某个专业问题需要临时增加一个人参与判断，这是加签。

经办人刚提交就发现传错了文件，希望趁流程没有结束先拿回来，这是撤回。

这些都不是高级功能，而是正常流程必然会出现的分支。

问题在于，很多系统虽然有这些按钮，却没有把动作背后的责任关系讲清楚。

转办不是抄送。

抄送只是让另一个人知道这件事，原审批人的任务和责任仍然存在；转办则是把当前处理任务交给另一个人，系统必须记录由谁转给谁、为什么转、转办以后谁负责作出决定。

驳回也不等于流程结束。

有些驳回是退回发起人补正，修改后从头审批；有些是退回上一个节点，只重新处理局部问题；还有些企业允许审批人选择退回到指定环节。系统需要明确驳回目标、重新提交路径，以及前一轮意见和版本是否继续保留。

退回和拒绝也不是一回事。

退回通常意味着“这份合同现在还不能批，改完再来”；拒绝则更接近“这件事不应继续”。如果所有异常动作最后都只显示一个红色的“未通过”，管理者就无法判断，到底是材料问题、条款问题，还是业务本身被否决。

撤回解决的是发起人主动纠错。

但撤回必须有边界。合同已经完成审批、已经用印或者已经发起电子签以后，能不能继续撤回，处理方式显然不能一样。系统既要允许业务纠错，也不能让一条正式记录被无声地抹掉。

此外，还有串行、并行、或签、会签、条件分支、代理审批、流程终止和重新提交。

名称听起来很多，挖到底都在回答三件事：

现在由谁决定？

出现例外时，合同去哪里？

作出决定的人和过程，能不能在以后被还原？

审批系统真正的价值，不是让一根线从左边顺利跑到右边。

而是这根线中途拐弯、后退、换人甚至停下来的时候，企业仍然知道发生了什么。

四、审批通过，不代表合同已经生效

企业内部审批结束，只能说明企业同意签这份合同。

它还没有回答一个最现实的问题：合同到底签了没有？

线下签署时，需要申请用印、选择印章、确认盖章份数、记录领用和归还，再把双方盖章后的正式文件传回系统。

电子签署时，需要确认签署主体、签署人、签署顺序、签署位置和签署状态。有人拒签、超时或者身份验证失败，系统还要知道流程停在了哪里。

不管采用哪一种方式，最终都要形成一份明确的生效文件。

这份文件不能只是附件列表里最新上传的那个PDF。

系统要说得清楚，它对应哪一次审批，双方什么时候签完，是否已经生效，后来有没有作废或者被新版本替代。

用印、签署和正式版本确认，因此都属于基本功能。

如果系统审批做得很漂亮，签署环节却只留一句“线下处理”，最关键的证据仍然断在系统外面。

企业以为自己完成了数字化，真正发生纠纷时，大家还是要问经办人：最后盖章那份到底在哪？

五、合同签完以后，管理才进入时间维度

审批和签署管理的是一个结果。

履约管理面对的却是一段时间。

三年租期要按月付款，一批设备要分批交付，一项装修工程要经过多个验收节点，一份服务合同还可能每个季度提交成果。

合同签署完成的那一天，只是这些事情共同的起点。

因此，基本系统不能只保存合同总金额，还要允许建立收款、付款、交付、验收和其他履约计划。

每一项计划至少要有责任人、计划时间、完成状态和证明材料。临近到期时要提醒，发生逾期时要留下异常，实际完成以后要能回到合同查看证据。

履约不是给合同旁边增加几个待办事项。

它是在回答：合同里写下的承诺，后来有没有真的发生。

合同发生变化以后，事情会更复杂。

双方签了补充协议，付款金额变了，原付款计划要不要调整？

项目暂停，履约任务是否继续催办？

合同提前解除，尚未执行的计划如何关闭，已经支付的款项是否涉及退款？

负责人离职，未完成的任务和材料交给谁？

这就是为什么变更、中止、恢复、终止、解除和交接，也属于合同的基本能力。

它们不是合同之外新开的一条流程，而是在改变原合同后续应该怎样执行。

如果变更只是重新上传一份补充协议，系统里的金额、期限、付款和履约仍然保持原样，那么系统保存了新文件，却继续按照旧合同办事。

这种系统，资料是全的，事实却是错的。

六、归档不是把文件放进一个文件夹

合同履行过程中，文件会越来越多。

审批稿、签署稿、补充协议、付款凭证、验收材料、往来函件、解除证明，都可能属于同一份合同。

档案管理的第一件事，是让这些文件回到正确的合同下面，并且区分它们的性质。

第二件事，是管理正式档案本身。

合同编号怎样生成，电子文件保存在哪里，纸质原件有几份，什么时候归档，谁借走过，是否按时归还，这些都需要记录。

第三件事，是接住历史。

企业上线系统的那一天，并不是企业第一次签合同的那一天。旧系统、共享盘和档案柜里已经存在大量有效合同，它们可能仍在付款、履约或者等待续签。

如果新系统只管理上线以后新签的合同，管理者看到的台账天然就是残缺的。

所以历史合同、相对方、文件和必要履约数据的导入，也是一套基本系统走向正式使用时必须考虑的问题。

归档之后还要能查。

按合同名称、编号、相对方、金额、类型、负责人、签署时间和状态查询，是最基础的台账能力；到期、付款和履约提醒，让人知道哪些合同需要处理；统计和导出，则帮助管理者掌握数量、金额和进度。

与此同时，合同不能因为进入台账，就变成所有人都能打开的公共文件。

谁能看到哪一份合同，谁能查看金额，谁能下载正文，谁能借阅原件，谁能修改基础信息，都要受到角色、组织和业务关系的控制。重要操作还要留下日志。

台账、查询、提醒、权限和日志，因此不是合同流程之外的后台功能。

它们决定了合同进入系统以后，能不能被找到、被使用，也能不能被安全地使用。

七、判断一个合同系统，不能只数功能菜单

写到这里，一套基本合同系统的轮廓已经比较清楚了。

它要覆盖准备、起草、审批、签署、履约、变化、归档和台账。

但市场上并不缺少菜单齐全的系统。

有些系统左侧导航栏长得惊人，合同起草、审批、签署、履约、归档一个不少，真正使用时仍然会断。

原因也不复杂。

功能虽然在，数据没有接起来。

判断一套系统是否形成基本闭环，可以不听销售人员讲多少名词，只看四件事。

第一，合同对象是不是同一个。

从起草到归档，系统管理的应该始终是同一份合同，而不是每到一个阶段就重新建一条记录、重新上传一次文件。

第二，状态能不能连续变化。

审批中、待签署、履行中、已变更、已解除和已归档，不应该由不同人员在不同表格里各写一遍，而应该随着业务动作自然推进。

第三，责任能不能跟着合同走。

现在由谁审批、谁签署、谁付款、谁验收、谁保管原件，任何时点都应该找得到责任人。人员变化以后，未完成事项还要能够交接。

第四，证据能不能回到过程。

审批意见、历史版本、签署文件、履约材料和变更依据，不能只证明“最后完成了”，还要能还原“当时为什么这样处理”。

对象不断，状态不断，责任不断，证据不断。

做到这四点，功能才不是摆设。

八、基本系统有了，为什么还要继续升级？

现在再回答开头的问题。

转办算不算基本功能？

算。

驳回、退回、撤回、加签算不算？

算。

履约、变更、解除、归档、台账和权限算不算？

也都算。

因为少了它们，一份合同就无法在系统中完整走完自己的生命周期。

但基本功能齐全，不等于系统已经能够适应所有企业。

当一份合同只经过两三个人，基础评论和版本记录可能已经够用；当业务、法务、财务、区域和合作方反复修改十几轮，协同方式就必须升级。

当文件都是标准Word，基础文本比对可以发现差异；当企业面对大量对方合同、扫描件、盖章PDF和最终签署版，比对对象和准确性就必须升级。

当企业只有一套内部组织，按部门授权可以解决大部分问题；当直营网点、加盟商、区域和多个签约主体同时存在，门店与权限模型就必须升级。

当合同只有几百份，固定台账和人工录入尚能维持；当合同数量持续增长，字段抽取、风险预审、灵活数据视图和AI能力就必须进入业务过程。

当付款在财务系统、纸质文件在快递系统、审批待办在办公平台时，合同系统还必须具备连接外部系统的能力。

所以，合同系统的升级，不是把基本功能推倒重来。

它是在完整生命周期底座之上，让系统进一步协同化、数据化、智能化、可配置，并能够连接企业真实的经营系统。

基础合同系统解决的是：合同能不能在线管起来。

面向复杂经营的合同系统还要解决：当组织更复杂、合同更多、变化更快以后，企业能不能继续把合同背后的经营关系连起来。

我是合同吴彦祖。

下一篇，继续来讲讲，今天的零售合同系统，到底应该长成什么样。