变更这件事，麻烦的从来不是「改」，而是「事后说不清」
工地上的变更是常态：业主改个门位、图纸和现场对不上、地下挖到未标注的管线、材料临时用别的牌号代用。真正常见的麻烦是下面这几件：
- 口头通知，事后补单。 现场一句「先这么干」，等结算时凭记忆补变更单，数量、部位、原因都成了回忆，说不清就只能让。
- 单据散在三处。 一张变更单，技术员手里有草稿、监理手里有确认单、造价员电脑里有 Excel 计算表，凑在一起才发现对不上号。
- 批没批、谁批的查不到。 单子到底走到哪一步、谁退回的、退回理由是什么，全在微信聊天记录里，翻起来靠运气。
- 时限没人盯。 多数施工合同会写「逾期未办理视为放弃计量」之类的条款（具体以所签合同约定为准），现场忙着赶工，等想起来已经过了提出时限。
- 年底结算凑不齐依据。 结算期一到，要按合同把所有已批准变更汇总成一份依据清单，才发现漏的漏、重的重、审定额和报审额混在一起。
这些现象不是哪个项目运气差，而是过程数据没有落在一个地方。下面这套搭法只做一件事：把「提出来—批下来—算进去」这条线做成系统里的记录，让每个环节都查得到、对得上。
先分清两件事：设计变更和现场签证
在系统里这两类要分表建账，这是整套方案最关键的一个决定。
- 设计变更通常由设计方或业主发起，影响图纸与工程量，往往有正式的变更编号和设计文件。
- 现场签证是现场实际发生后确认的工作量或费用，比如临时支护加固、二次搬运、夜间施工、清障排水，依据是监理或业主在事发现场签认的事实。
混在一张表里的后果很实际：按类型统计时统计不出来；审批人拿着「设计变更」的标准去批一张「临时排水签证」；外部审计问「你们的签证依据是什么」，翻不出对应的现场记录。
分开建两张主表、共用同一套状态与审批逻辑，比事后在备注里区分要省事得多。
底表怎么设计：五张表，别把一切都塞进一张变更单
1. 变更/签证主表（一张单一行）
主表的字段决定后面所有统计能不能做，几个关键设计是：
- 两个编号字段。 内部流水号（系统生成、唯一）用来防重复录入；外部正式编号（业主或设计给的那个号）等拿到再补。两者不要合并成一个字段——很多项目是「先内后外」，合并了就会出现「有号无单」的脏数据。
- 类型走数据字典。 设计变更 / 现场签证 / 技术核定 / 材料代用，这四项在平台的数据字典里集中维护一次（数据字典就是下拉选项的统一口径库，改一处、所有页面同步生效），避免同一类变更被写成四五种叫法，后面按类型筛选就筛不干净。
- 影响金额分三档，不要一个字段反复覆盖。 报审金额（承包方提的）、初审金额（造价核过一遍）、审定金额（最终认可）。很多企业只留一个「变更金额」，结果越改越糊涂，谁也说不清哪个数是最终数。
- 状态固定几态。 草稿 → 待审 → 已批准 → 实施中 → 已纳入结算 → 驳回 / 作废。一次定死，不要靠备注描述进度。
- 是否影响工期单独一个标记。变更和工期顺延往往是两笔账，串在一个字段里，索赔时就说不清。
- 事项描述 + 提出单位 + 提出日期 + 部位。 部位建议引用单位工程/楼层作为选项，而不是自由文本。
2. 明细子表（一根单多行）
变更单下面的量化部分拆成子表：部位、清单项、单位、数量、单价、金额、计算式说明。这样一张变更单可以同时包含几个部位、几个清单项，而主表不用为每个部位复制一遍。
主表不要存「已结算金额」。 这个数在结算那边算，主表存一份就会和结算记录重复计数，越到后期差得越多。
3. 附件登记（一附件一行）
附图、现场照片、计算书、会议纪要、监理确认单，都在平台的附件能力里上传（文件上传与存储，支持本地与对象存储两种方式），同时在附件登记子表里记一行：名称、类型、上传人、上传时间、对应部位。
为什么不用一个大字段塞几个文件名？因为审计和结算真正要问的是「这张签证有没有现场照片、照片是谁什么时候拍的」，一附件一行才回答得了。
4. 审批意见子表（只增不改）
每次流转都留一行：节点、审批人、结论、意见、时间。审批流本身由平台的工作流可视化编辑器配置和驱动，执行过程自动留痕；但审批结论里真正关键的几句话（「同意，按初审金额结算」「不同意，属合同范围内」），建议单独落到意见子表里，方便结算时连同单据一起导出。
5. 结算依据清单（批准后自动生成）
这是把变更和结算接起来的那张表：变更单号、类型、审定金额、关联合同、关联分包合同、拟纳入结算期次、是否已纳入。
它不该靠人手工汇总——每批准一张变更单，就自动生成一行待纳入记录，结算期到了直接按清单核对，漏项一眼能看见。这一步靠平台的数据流规则实现（数据流规则＝在保存、审批通过这类事件发生时自动执行的数据变换），后面「自动化」一节展开。## 页面怎么用：四个角色，四个入口
同一批数据，四个角色关心的东西完全不同。页面按角色分，比做一个「功能齐全」的大表单更好用。
项目技术员（提出人）
- 新建变更单/签证单：填部位、原因、事项、影响，传现场照片和附图，存草稿随时续填。
- 「我提的单」列表：按状态看自己提的单走到哪一步了、被谁退回、退回理由是什么。
- 提交流程就走审批流，不需要知道后面有几个人审。
项目技术负责人 / 监理（审核人）
- 「待我审批」是日常主入口：左边是单据与附件，右边是审批按钮与意见框。
- 审核人最需要的是能核对：现场照片、附图、部位描述、合同依据四处能并排看，比在一堆邮件附件里翻要快。
- 退回必须填意见（这条建议做成必填），退回理由是后面整改和追责的唯一线索。
造价 / 商务（核量与计价）
- 「变更签证台账」是核心页面：按合同、单位工程、类型、状态、时间多维筛选，导出就用这个视图的筛选结果。
- 审定金额维护权限只给造价和商务，其他人看得到、改不了。
- 「已批准未纳入结算」清单：结算期前的必备清单，避免漏项。
财务 / 项目负责人（看数）
- 汇总页按合同、按单位工程、按月看变更累计金额与待纳入金额；
- 超阈值清单：单个变更超一定金额的单独列出（阈值按企业内部授权制度定，不同企业差别很大，不要照着别家的数设）。
自动化：让系统帮着盯三件事
人工盯不住的部分交给规则。平台这边有三类可用：
1. 审批流（分级授权）
变更金额必须分级审批——小额项目内批、大额上报公司，这是多数工程企业的内控要求。用工作流按「审定金额或报审金额区间」配分支节点，走哪条路由系统判断，不用提出人自己挑。
配置时一个经验：先按企业现有授权制度把阈值抄下来，再配流程，不要反过来让制度去迁就流程。
2. 数据流规则（批准之后的连锁动作）
- 审批通过 → 自动写入结算依据清单一行（单号、审定金额、关联合同、待纳入期次）；
- 审批通过且「影响工期」标记为是 → 给项目负责人发一条通知，提醒进入工期顺延的书面流程；
- 驳回 → 通知提出人并带上驳回意见；
- 审定金额与报审金额差额超过阈值 → 打标提示，结算对账时重点看。
这些都不需要有人记得去做，规则在保存和审批通过时自动跑。
3. 定时任务（周期性清单）
用平台的工作流与定时任务配两条周期任务：
- 待批超期清单：每周一次，列出「已提交但超过 N 天未完成审批」的单据，推给造价和项目负责人。N 按企业自己的管理要求定，系统只负责把超期的挑出来。
- 月末签证汇总：每月固定日期把当月新批准的变更签证汇总成一条通知，附金额合计，作为月度成本例会的材料。
4. 审计日志
金额、状态、关联合同这类字段的每次改动都会留下操作记录（谁、什么时候、改前改后）。结算争议或外部审计时，这份记录比任何说明都有用。
移动端怎么配合
变更签证的现场性很强，手机端是主战场，不是补充：
- 现场提出：技术员在部位现场拍照片、填一条签证草稿，事由和部位就是当下的，不用回办公室再回忆。
- 现场审批：监理和项目负责人在待办里直接看照片、点同意或退回并写意见。
- 进度查询：老板在工地上问「那张签证批了吗」，手机上能直接查。
PC 端建好的模块会自动出现在移动端工作台，不需要单独再搭一套页面。
有一条边界要说清楚：现场没信号时，系统不能保证离线填写和回连后自动同步。所以现场按老办法做纸质签认、拍照留存，回到有网络的环境再补录进系统，纸质原件照常归档——系统记录的是「已确认的事实」，不是替代现场签认。真要做到断网可用，需要单独评估。
上线前查什么
这套东西能不能用住，取决于上线前这几项：
- 状态字典一次定死。 六七个状态足够，别中途加；中途加会让已录数据的历史状态分叉。
- 编号规则 + 唯一约束。 内部流水号设唯一约束，防止同一份单据被两个人各录一遍。
- 金额单位统一。 全部用元还是全部用万元，定下来别混；三档金额字段名称写清「报审/初审/审定」。
- 审批阈值与内控制度对齐。 先拿 3～5 张真实历史变更单跑一遍流程，确认分支走对了再全员开。
- 历史在办单据怎么迁。 建议只迁「已批准但还没纳入结算」的；已结算完的只迁金额汇总或扫描件归档，不逐条补录。
- 权限先配后开。 审定金额只有造价与财务可改；提出人不能改自己的状态。权限按角色配好，参考角色与权限配置。
- 必填项按类型区分。 现场签证要求必须有现场照片和监理确认件；设计变更要求必须有变更文件或图纸。两类用不同的必填规则。
- 结算依据清单与结算口径对齐。 清单里的字段要能和结算单直接对应，否则导入结算还得手工对一遍。
- 移动端真机验一遍。 用真手机提交一张带照片的单据，走完整流程看能不能跑通。
- 数据字典与合同台账、分包台账的选项对齐。 单位工程名称、合同编号这几项如果各模块写法不一致，汇总就对不上。## 之后怎么延伸
变更签证只是项目成本这条线上的一个环节，跑顺之后通常会往两个方向接：
- 往合同走：变更的最终依据是合同条款与合同金额。把变更单通过跨模块引用关联到合同台账里，就能看到「这份合同的原始金额多少、累计变更多少、现在总额多少」，续签或索赔时不用重新翻卷。
- 往结算走：审定金额进分包结算，对下把变更工作量算给分包队，对上向业主申报，同一份审定数往两头走，避免一份单子两个数。
- 往资料走：变更批准后往往要出新版图纸或技术文件，用受控文档管理把新版发布出去、旧版作废、要求相关人阅读确认，避免现场还拿着旧图施工。
- 往现场记录走：签证的原始事实往往记在施工日志和监理记录里，和工地施工台账对上日期和部位，争议时能互相印证。
- 往项目总账走：把变更累计金额汇到项目台账，一个项目赚没赚、变更贡献了多少，一张表能看出来。
这些页面不用一次全建。先把变更签证这一条线跑通、把单据养起来，再逐条接出去；一次铺太多模块，往往哪个都用不深。
不做什么：这套东西的边界
说清楚边界，比夸大能力更省事：
- 不做工程量自动计算。 图纸识别、BIM 量算、自动套定额不在这个方案的范围内。变更工程量仍由造价人员按合同计量规则核定，系统负责把数量、单价、计算式和依据记录下来，让这个数可查、可追溯。
- 不做电子签章与印章硬件对接。 签字盖章走线下，扫描件上传归档；系统记录的是「这份文件存在、谁传的、什么时候传的」，不承担签章真实性的核验。
- 不替企业判断变更是否成立。 这属于合同解释和现场判断，由监理、业主和合同条款决定。系统只记录结论、依据和过程。
- 不内置法定的时限与授权阈值。 提出时限、签认时限、分级审批金额，各企业、各项目合同约定差异很大，一律以所签合同和内部制度为准，系统里只做提醒和分支，不给默认值。
- 不做「零变更」「工期不延误」这类结果承诺。 系统能让变更查得到、追得回、对得上，但改不改、延不延是现场和合同的事。
- 不逐条补录纸质历史单据。 往年已结算的变更签证按项目扫描归档，需要时能查到即可；从头补录的代价通常远大于收益。
一句话记住这套搭法
两类单据分表建、三档金额不覆盖、批准即入结算清单、超期系统自己挑。 把这四件事做到，变更签证这条线就不会在年底结算时反过来咬人——单据在系统里，依据在附件里，过程在日志里，钱在结算清单里。