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

作者：合同吴彦祖

前六篇，我们一直围绕多门店零售企业的合同管理展开。

一份合同怎样从经营现场进入系统，怎样完成草拟和审批，怎样让法务、财务、业务甚至外部人员一起协同，怎样通过版本比对确认最终签署文本，又怎样按照区域、城市和门店把合同准确归集起来，前面已经逐步讲清楚了。

写到这里，合同终于签完了。

但企业花钱的事情，才刚刚开始。

某家连锁企业采购了一批门店设备。

合同总额八十万元，第一笔预付款二十四万元，第二笔款项要等二十家门店完成安装验收后支付，剩余尾款则要等质保期开始以后再付。

合同审批时，供应商、收款账户、付款比例、付款条件、费用承担门店和终版合同都已经确认过了。

到了付款那一天，经办人打开财务系统，又把这些内容重新填了一遍。

供应商重新选择。

金额重新录入。

收款账户重新核对。

合同重新下载，再作为附件上传。

二十家门店怎样分摊费用，又重新整理了一张表。

合同系统里有一套数据。

财务系统里又生出一套数据。

两套数据刚建立时看起来完全一样，合同一旦变更，事情就开始失控。

供应商换了收款账户，合同系统已经审批通过，财务系统还保留着旧账户。

两家门店取消采购，合同金额已经调减，原来的付款单却还在继续流转。

财务最终完成支付，合同系统仍然显示“待付款”，法务和业务只好再次向财务确认。

两套系统都在认真工作。

同一笔钱，却被管理了两遍。

本文来自一个真实的财务系统对接项目，但讨论的并不是某个品牌的接口怎么调用。

真正的问题是：一套多门店合同系统，怎样把合同约定、付款办理、实际支付和门店费用接成同一条业务链。

一、先把需求摆到桌面上：这套系统到底要解决什么

合同系统与财务系统对接，最容易被简化成一句话：合同审批通过后，把数据推送过去。

这句话只说了数据从哪里出发，却没有说它后来怎样回来，也没有说合同变化以后怎么办。

从真实业务看，企业需要的并不是一个推送按钮，而是下面这套完整关系。

业务现场的问题合同系统应当提供的能力用户应该在哪里看到
合同数据在财务系统重新填写让合同系统中的合同、相对方、终版文件和付款计划能够被财务系统调用合同系统的合同详情、财务系统的付款申请单
不知道应该从哪一笔付款开始申请从合同系统的付款计划节点进入财务系统发起付款合同系统的付款计划区域
财务系统已经付款，合同系统仍显示待付款将财务系统的付款进度和支付结果回写合同系统合同系统的付款节点和付款汇总
总部签约，却不知道费用落在哪家门店将财务系统的费用分摊结果回写并关联门店合同系统的付款明细和门店合同费用
合同系统中的付款计划或收款账户变更后两边不一致变更审核通过后，将新数据同步至财务系统合同系统的变更记录和同步状态
合同解除了，财务系统中的原付款申请仍在运行暂停合同系统中的未完成计划，并联动财务系统中的付款申请单合同系统的解除流程和付款计划状态
跨系统失败后只能找技术人员查日志建立独立的同步记录和异常处理入口数据同步中心

这张表决定了软件最后应该长成什么样。

它不能只在后台藏着几个接口。

合同经办人、法务、财务和门店管理人员，都应该在自己处理业务的页面上看见这条连接。

二、合同详情里，首先要有一块真正能用的付款区域

合同审批完成以后，经办人再次打开合同详情，不能只看到合同金额和一个“已付款”字段。

页面中应当有独立的付款计划区域。

最上方先说明这份合同一共约定多少钱，已经申请多少，实际支付多少，还有多少尚未支付。

下面按照合同约定列出每一个付款节点：第几期、计划付款日期、付款金额、付款对象、收款账户、付款条件、费用承担门店以及当前状态。

某个付款节点要求“二十家门店完成设备验收”，验收材料和履约记录就应当直接关联在这个节点下面。

条件尚未满足时，系统提醒经办人还缺什么。

条件已经满足时，节点上出现“发起付款”的入口。

用户不需要先离开合同，再去财务系统里猜应该选择哪一份合同。

付款从哪份合同、哪一个节点产生，在发起的第一刻就已经确定。

【截图位置1：合同详情中的付款计划区域】

建议展示：合同总额、计划付款、已申请、已支付和剩余金额，以及每一期的金额、时间、付款条件、收款账户、承担门店、履约依据、所关联的财务系统付款申请单和同步状态。

三、合同审批通过后，同步的不是一个编号，而是完整付款依据

付款计划可能来自经办人填写，也可能先由AI从合同正文中识别，再由人工复核。

无论通过哪种方式形成，它都不能在合同审批还没结束时，就成为财务付款的正式依据。

只有合同审批通过、终版文本确定、付款计划确认生效以后，系统才把完整付款计划推送到财务系统。

推送内容不应只有合同编号和总金额。

合同主体、相对方、合同期间、付款对象、收款账户、每期金额、付款时间、付款条件、关联门店和终版电子合同，都是后续财务办理需要核对的依据。

每个付款节点还要保存对应的跨系统标识、同步时间和同步状态。

这样，用户才能知道这期计划有没有送到财务系统，对方接收的是哪个版本，失败以后是否已经重新处理。

企业真正需要的不是“接口调用成功”五个字。

而是合同页面上那一期付款，确实已经在财务系统中找到了自己的位置。

四、从合同进入财务系统，不是换个地方再填一遍

第二期付款条件满足以后，经办人点击“发起付款”。

财务系统打开的应当是与这份合同、这个付款节点已经建立关系的办理入口。

财务人员在财务系统的付款申请单中，可以关联查看合同系统保存的合同基础信息和正式签署版本；需要合同附件时，可以一键取得终版电子合同，而不是再让业务人员从电脑里找一份文件上传。

付款办理所需的合同依据已经存在，用户只补充本次费用申请真正新增的信息。

从财务系统的付款申请单，也能够返回合同系统中的原合同。

财务人员如果对付款条件有疑问，可以直接查看合同正文、付款计划和履约材料，不必在聊天软件里向业务人员重新索要。

这才叫关联。

不是合同系统把一堆字段扔过去，从此不再过问。

而是两边的用户都能沿着同一笔业务找到对方保存的依据和结果。

五、付款结果回来以后，合同页面应该长什么样

经办人提交了三十二万元的付款申请，并不代表财务最终已经支付三十二万元。

申请可能仍在审批。

也可能被驳回。

还可能只批准一部分，或者拆成两次支付。

所以，合同页面不能只有“未付款”和“已付款”两个状态。

合同系统中的每个付款节点，至少要分开显示计划金额、申请金额、实付金额和剩余金额，并关联财务系统中产生的一张或多张付款申请单。

财务系统受理以后，将付款申请单编号和办理进度返回合同系统。

付款完成以后，财务系统再将实际支付金额、支付时间和支付结果回写到合同系统的原付款节点。

如果一笔计划分三次支付，三次记录分别保留，不能用最后一次结果覆盖前两次。

如果财务系统生成了租金等费用的分摊明细，也应当将这份分摊结果回写到合同系统，并继续关联区域、城市和门店。

总部看到整份合同的付款情况。

区域负责人看到辖区门店承担的费用。

门店管理人员从某家门店出发，也能反查这笔费用来自哪份合同、哪一期付款。

六、供应商和门店档案，也不能让两套系统各建一遍

合同付款要准确，首先要保证双方说的是同一个供应商、同一个收款账户和同一家门店。

真实项目中，往来基础档案和门店编码需要从财务系统同步到合同系统。

合同经办人选择供应商时，系统根据名称匹配统一社会信用代码、法人、地址等信息；涉及门店时，继续使用财务系统中已经维护的门店编码和名称。

合同系统不应擅自为一个新供应商生成财务编码。

如果业务提交的相对方在财务系统中还不存在，系统可以形成“待新增往来档案”明细，交由有权限的人员完成财务建档和编码维护，再同步回来使用。

这看起来只是基础资料同步。

实际上，它决定了合同系统中的付款计划、财务系统中的付款申请单，以及财务系统回写的费用分摊结果能不能准确对应。

名字相似，不代表是同一个法律主体。

门店简称一样，也不代表是同一家经营网点。

跨系统管理最怕的，不是没有数据，而是两边都有数据，却没有共同身份。

七、合同变更以后，财务信息必须跟着变

设备安装期间，两家门店取消采购，合同金额和第二期付款计划需要调整。

经办人在合同系统中发起付款计划变更。

这次修改仍然要经过审核。

审核通过以前，它只是一个待确认方案，不能直接覆盖已经生效的付款依据；审核通过以后，新的付款计划再同步到财务系统。

供应商、收款账户、门店和付款计划等财务相关信息发生变化，也要遵守同样的原则。

先完成合同变更审核，再同步更新财务系统。

合同系统还要在合同变更页面列出受到影响的付款计划，以及与这些计划关联的财务系统付款申请单。

尚未申请的计划可以按照新约定调整。

财务系统中已经发起但尚未支付的付款申请单，需要进入复核，由有权限的人决定修改、撤回还是继续。

已经完成的付款不能删除。

历史记录必须保留当时依据的合同版本、付款计划和实际结果。

合同解除或作废时，未完成的付款计划还要暂停，已完成部分由经办人和财务确认，相关状态再同步到财务系统。

对接最难的从来不是第一次把数据送过去。

而是合同后来变了，两边仍然知道哪些内容应该更新，哪些历史不能改写。

【截图位置3：合同变更对付款计划和财务系统付款申请单的影响】

建议展示：合同系统中变更前后的金额、付款计划、供应商、账户和门店差异，受影响的财务系统付款申请单，以及待同步、待复核、已完成等处理状态。

八、新系统上线，历史合同和待付款不能集体失忆

新合同系统上线那一天，企业不会突然只剩下第二天才签的合同。

大量合同以前已经在原有财务系统中完成审批。

有些已经付款，有些在财务系统中还有待支付单据，有些仍在按照多年租赁计划持续分期。

如果新系统只接收上线以后的合同，法务和财务仍然要长期维护两套台账。

因此，初始化时需要把原来在财务系统中审批的历史合同同步到合同系统，把财务系统中尚未支付的单据和原有付款计划接续过来，并保留已有付款状态。

这不是把所有数据再复制一遍。

而是在确定的切换时间点上，回答清楚三件事：哪些合同已经存在，哪些钱已经支付，哪些责任还没有结束。

同步完成以后，合同系统中的历史合同能够继续关联财务系统中的原付款单据，未完成的付款计划能够继续向后办理，已经完成的付款也不会被误认为还要再付一次。

一套系统是否真正上线，不看登录页面什么时候开放。

要看旧业务能不能从那一天开始，完整地接到新业务上。

九、最后还要有一个所有人看得懂的同步中心

跨系统对接一定会失败。

供应商尚未建档。

收款账户审核没有完成。

门店编码无法匹配。

合同变更已经通过，财务系统却暂时没有接收成功。

这些问题不能只留在服务器日志里，等业务人员发现数据不一致以后再去找技术人员。

合同系统需要单独的数据同步中心。

页面按照历史合同、财务系统待付款单据、合同系统付款计划、往来档案和合同变更等类型记录每一次同步，显示同步方向、同步时间、当前状态和异常原因，并支持查询和导出。

合同详情和付款节点上，也要显示与当前业务有关的同步状态。

能够自动恢复的任务继续重试。

需要人工处理的档案缺失、账户冲突和门店匹配问题，则明确告诉管理员应该处理什么。问题解决以后，从失败的那一步继续，不要求经办人重新发起整份合同。

具体能够同步哪些字段、回写哪些状态，最终仍然受外部财务系统开放接口的范围约束。

产品设计不能假装外部系统什么都能提供。

但接口边界需要由产品和技术处理，不能把一句“接口不支持”直接扔给业务人员。

十、真正的对接，是一笔钱能够从合同出发，再回到合同

第二期付款最终完成。

经办人从合同付款节点进入财务系统，没有重新寻找供应商和终版合同。

财务人员从财务系统的付款申请单，看到了合同系统提供的合同依据、付款条件和门店验收材料。

支付完成以后，财务系统将实付金额、付款时间和费用分摊结果，回写到合同系统原来的付款节点。

后来有人打开这份合同，不需要再向财务询问，就能回答：合同约定怎样付，已经申请多少，实际支付多少，由哪些门店承担，还有多少尚未支付。

有人从长风街店出发，也能看到这家门店承担了多少设备费用，再沿着费用记录回到原合同。

这才是合同系统与财务系统真正形成连接。

不是把一组字段从A系统搬到B系统。

也不是在合同页面上增加一个“推送成功”的绿色标记。

而是让合同系统中的合同依据和付款计划、财务系统中的付款申请和实际支付，以及回到合同系统的门店分摊和后续变更，始终围绕同一笔业务相互解释。

一个按钮只能完成一次推送。

一条来回走得通的数据链，才能管住一份合同从应付到实付的全过程。

我是合同吴彦祖。

下一篇继续讨论合同审批后的签署过程：电子签和纸质签署是两条不同的路，合同系统应该怎样把它们都管起来？