计量支付模块

计量支付是智慧建设平台中的一个业务模块。我们的目标很明确：让用户每期只填完成的工程量，由平台计算费用，生成整套计量支付报表，再进入相应的付款审批流程。

我负责业务和产品设计，并带领研发团队自研合同清单导入。要把这个目标做成，既要算准清单里的每一笔金额，也要处理业务方长期沿用的计算方法和工作习惯。

SWT 清单导入零误差

自动计量的前提，是系统里有一份完整、准确的合同清单。每个清单项目对应什么工程内容、综合单价由哪些费用组成，都要能够与当期填报的工程量对应。

SWT 是深圳建设工程电子招投标中使用的商务报价数据交换文件。我们当时对接的用户，大多通过斯维尔造价软件导出这类文件。

我希望直接从这份报价数据建立合同清单。与我们当时拿到的 Excel 清单相比，这些 SWT 文件保留了更完整的工程层级和价格组成。把这些信息带进系统，后续计量才能沿用合同中的清单和计价关系，也能减少二次整理、手工转录造成的差异。

我们曾找斯维尔讨论合作。对方当时也在研究这项能力，但反馈导入后的清单仍有计算误差。我们的要求是一分钱误差都不能有，于是由我带领研发团队进行自研。

我把 SWT 文件的层级结构在浏览器中展开，沿着单位工程、分部分项工程逐层分析，确认文件中的哪部分内容对应哪类业务数据，哪些字段构成综合单价，再把这些对应关系讲清楚，交给研发实现解析与计算。

最终，合同清单可以完整导入平台，金额核对没有一分钱误差。在这个过程中，我们还发现了业主部分历史合同中原本存在的造价计算错误。

完整导入价格组成，还解决了另一个问题：这一期的规费应该算多少。

规费涉及社会保险、住房公积金等费用，逐个核算大量工人的缴纳情况，很难支撑每期计量。项目现场有一种简化做法：整体进度完成 30%，就支付 30% 的规费。但整体进度比例不能准确反映当期完成工作的人工费构成。

我利用合同清单中保留的人工计价信息，把当期完成工程量与对应的人工费组成关联，让系统准确核算本期人工费，进而完成当期规费计算。

这项自研能力把造价计取要求落实到了每期计量中。用户不需要按整体进度比例估算规费，清单中的价格组成也真正参与了后续计算。

算准金额之后，申请还要进入对应的付款流程。合同类型、工程所处阶段和款项性质，都会改变需要填写的表单、参与审核的人和流转路径。

我将施工合同与服务合同的付款业务分成五类：

例如，施工进度款先围绕《支付月统计表》逐级审核，之后再填写拨款与付款审批表单；服务款的流程则由服务单位与业主方完成，不照搬施工款中的监理、造价咨询审核环节。

同一个单位会参与多个项目、多个合同段，同一类岗位也可能由不同的人承担。“监理工程师”不能只是流程图上的一个名称，必须对应到当前合同段实际有权审核的人。

平台通过岗位确定流程办理人，通过角色分配功能权限。监理单位还需要获得对应施工合同段的授权，后续流程才能选择到相应审核人员。

在计量支付设计中，我把业务分工与平台的项目、合同段、岗位关系对应起来，明确申请在哪个范围内流转、由谁处理。

审批流也按业务要求设置了审核约束：支持跨节点驳回，省去逐级退回的操作，但申请重新提交后仍需按流程完成审批。

查看施工进度款的审批路径

预付款扣回方式不一致，不能只当作一个兼容几种算法的设计问题。面对长期按既有习惯工作的政府客户，前期如果没有把业务理解透，即使口头上达成一致，也很容易在开发后因为理解偏差反复修改。

我深入学习了计量支付涉及的造价知识，围绕费用组成和预付款扣回规则逐项研究，推演不同的计算方法。在这些具体问题上，我对规则和计算细节的掌握，甚至比客户方的造价工程师更深入。

我把问题、计算差异和调整依据准备充分，再选择合适的时机，把相关人员组织到一起。能从业务本身讲清楚问题所在、为什么要调整，以及调整后该怎样办理，才让对方信服我的判断，我们也因此较快达成了共识。

共识形成后，我再理顺线下流程，把确认的规则落实到产品中；对于需要并行处理的不同计算方法，则通过系统兼容，保持业务的连续性。

截至 2021 年，已有 40 个施工合同段通过平台申请工程款，54 个服务合同段申请服务款。

上线后，我继续跟进迁改合同“总价下浮”等新增需求，处理不同合同条件带来的计量问题。合同清单的准确导入、按期费用计算与多方审批，共同支撑了这套业务的持续运行。