分包结算乱，乱在"依据"不在一个地方
工程公司上了点规模，分包结算就会开始出问题。但问题通常不是"算不清"，而是算的依据散在几个人手里：
- 工程量在项目部施工员手里——施工日记、验收单、手机里的现场照片；
- 合同与单价在商务或预算员手里——一份 Excel 合同台账，版本还不止一个；
- 付款在财务手里——银行流水加老板签字；
- 工人和工资在班组长手里——一张花名册、一沓签收条。
于是结算就靠三样东西撑着：对账会、回忆、以及"上次给到哪了"。由此长出来的坑，几乎每家都能对上号：
- 重复结算、漏结：同一个变更增项，两个月经手人对了一遍，或者干脆谁都没记；
- 超付：合同额和已付金额没人实时算，付到 90% 才发现还有质保金要留；
- 量说不清：班组长说干了这些，项目部说只认这些，缺中间那道"验收确认"的书面留痕；
- 实名对不上：检查要看进场人员实名登记，翻出来的花名册和现场人数不一致，证件过期的也没人管；
- 代付工资没凭证链：钱是付了，但要说明付给了谁、哪个月、什么依据，得去翻微信。
这一篇讲的是：用 Inkwell AI 构建器把这一条链搭成一个可用的业务模块——分包队建档 → 人员实名登记 → 月度工程量登记 → 项目部验收 → 结算单核定 → 付款与质保金 → 代付工资。不讲抽象的"数字化转型"，只讲表怎么建、页面给谁用、上线前查什么。
先定六个设计决定，再动手建表
用 AI 构建器搭这类模块，最容易犯的错是"一次把字段想全然后开建"。分包结算的字段很多，但真正决定这个模块好不好用的，是下面六个设计决定。先把它们定下来，字段自然就长出来了。
决定一：主数据立三档，不要拍平在一张表里
分包队伍 → 班组 → 人员是三级结构，不是三个字段。
- 分包合同档案：一个合同一行，合同号设唯一约束（同一合同号录第二遍会被拦住）。合同额、质保金比例、付款条件、开工完工日期都在这里。
- 分包队伍档案：队伍名称、统一社会信用代码、负责人与联系电话、合作状态。
- 班组档案：挂在队伍下面，一个队伍可以有多个班组（木工、钢筋、混凝土……）。
- 人员实名档案：挂在班组下面，姓名、身份证号（唯一约束）、工种、证件类型与有效期、进场日期、退场日期。
为什么非要拆开？因为后面所有的统计口径都从这里来——"某队伍在场多少人"、"某工种证件到期几人"、"某班组本月结了多少量"。拍平在一张表里，这些问法全都要重新做一遍。
决定二："应做"和"实际"必须分表
这是整个模块最关键的一条。
- 合同单价清单（子表，挂在合同下）管"合同上约定的单价"：项目名称、单位、单价、工程量上限、备注。
- 月度工程量登记管"这个月实际干了多少"：登记期间、班组、项目名称（引合同单价清单的选项）、数量、现场照片附件。
两张表分开，才有办法一眼看出超合同量和合同外增项——这两件事恰恰是结算争议的两个主要来源。如果合成一张表，一边录单价一边录数量，超量就永远发现不了。
决定三：结算单只做汇总，不接受手填金额
结算单不应该是"录进去的一张单"，而应该是"算出来的一张单"。
- 结算单（主表）：结算期间、分包合同（引用）、结算总额、质保金留存、本次应付、状态。
- 结算明细（子表）：一行对应一条已验收的工程量，带来源登记单编号、数量、合同单价、金额。
金额由"数量 × 合同单价"算出来，人不能直接改总价。要改总价，只能回去改依据——改量、改单价（走变更单）、或退掉验收。这一条在实操里能挡掉绝大多数"事后翻账"。
决定四：状态用数据字典集中维护，字典先定
一份工程量登记要走的状态是固定的：填报 → 班组确认 → 项目部验收 → 商务核定 → 已进结算，中间允许"退回重填"。
这些状态值不要写在表里当文字用，而是放进数据字典统一维护（见 数据字典：管好下拉选项的统一口径）。好处很实在：以后要加一个"监理复核"环节，改字典一处，列表筛选、看板统计、移动端标签全都跟着变，不用逐张表去改。同一份字典还能管"工种""证件类型""付款方式""退场原因"。
顺序建议：先定字典，再建表。 反过来做，等于给自己留一次返工。
决定五：钱的部分单独开流水表，只增不改
结算之外，凡是"钱动了"的记录都要独立成表，并且只允许新增行，不允许改历史行：
- 付款流水：付款日期、收款方、付款方式、金额、对应结算单、凭证附件；
- 工资代付流水：人员、所属月份、金额、签收凭证、经办人；
- 质保金台账：合同、应留金额、已释放金额、可释放日期。
写错了怎么办？红冲：另起一行写负数冲抵，原行保留。这样任何时点回看都能还原"当时是怎么记的"，也才有资格去跟分包队对账。
决定六：合同外的一切，都必须有变更单号
增项、零星用工、材料代购、工期顺延——凡是不在原合同单价清单里的，都先走变更单，拿到变更单号，才允许进入工程量登记和结算。
这一条看着像流程洁癖，实际上是这个模块最有价值的地方：它把"口头答应了、年底一起算"变成"当场有个号"。年底结算时争议会少一大半。
从现有 Excel 起步，而不是从空表起步
大多数工程公司手里已经有可用的原始数据：一份分包合同台账、一份班组花名册。别急着在系统里从零敲。
做法是：把这两份表整理成规范的两张 Sheet（列名一行、不留合并单元格、日期统一格式），用 Excel 一步建模块 生成初版底表，再让 AI 构建器按上面六个决定补关系——拆队伍/班组/人员三级、加合同单价子表和工程量登记表、把状态值抽到数据字典。
这样起步的好处是：第一次上线就有真实数据可看，验收环节也容易让项目部接受——他们打开就能看到自己队的人。
页面按角色分，不要做一张"什么都能干"的大表
同一个模块，五种人打开的需求完全不同。按角色给不同入口，是这个模块能不能推下去的关键。
劳务员 / 班组长：只填"今天的人和活"
- 人员进场登记：姓名、身份证号、工种、证件照片（用文件上传作为附件）。重复的身份证号会被唯一约束拦住。
- 每日出勤或计件数量登记：选日期、选班组、填数量、拍现场照片。
班组长不需要看单价、不需要看别的队伍的量。所以这个页面的权限要收窄到"本条线的数据"，由 角色与权限配置 按数据范围控制。
项目部施工员：只做"验收"这一件事
打开就是一列待办：哪个班组、哪个月、报了多少量、照片几张。三个动作——通过、退回并写原因、转商务核定。
验收环节是整个模块的关口。它必须留三样东西：谁验的、什么时候验的、凭什么验的（照片与备注）。这三样齐了，"量说不清"的问题才算真解决。
商务 / 造价员：单价与变更的把关人
- 合同单价清单维护：只允许商务改，且改动留审计记录；
- 变更单：增项先建号；
- 结算单核定：看汇总、看明细来源、确认质保金留存比例后提交审批。
财务：付款与质保金
- 付款待办：按已核定的结算单付款，付款流水关联结算单；
- 质保金台账：哪些到期可释放、已释放多少；
- 代付工资登记：人员、月份、金额、签收凭证。
财务这个角色最忌讳"看到一堆数字但不知道依据"。所以每个金额旁边都要能点开看来源单据——这也是为什么前面坚持"结算单不受手填金额"。
项目经理 / 老板：一张分包成本看板
四个数就够用：合同额、已结算、已付款、未付余额，再加一个质保金留存。
分维度看：按分包队、按项目、按月份。这些数全部由底表算出来，不需要谁额外填表——这决定了这个看板会长期有数据，而不会三个月后变成空壳。
四类自动化：把"靠人记"的部分交给系统
模块建好只是有了表；让它真正省事的，是下面四类自动化。这四类都能直接在 AI 构建器里配出来，不需要写代码。
一、审批流：把金额分级卡住
用平台的工作流能力，给两条链配审批：
- 变更单审批：按变更金额分级——小额由项目商务确认，超过阈值升到公司层。
- 结算单审批：核定后进入审批，按结算金额走不同层级。
审批节点的条件、审批人、抄送人都可以在 工作流可视化编辑器 里配。分级阈值不要照搬别家，按企业自有的授权制度定，写进流程说明里。
二、数据流规则：让数字自己走
数据流规则是"条件一满足，某张表的某个字段就自动变"。在分包结算里，四条最有用：
- 工程量登记验收通过 → 汇总进当期结算单明细，金额自动算出；
- 付款流水新增 → 自动累加该合同的已付金额 / 未付余额；
- 结算单核定完成 → 自动按比例算出质保金应留金额，写进质保金台账；
- 人员证件有效期临近 → 自动标记状态，进入提醒清单。
配好之后，看板上的数字不需要人去"更新一下"，它本来就是实时算出来的。
三、定时任务：每月那几件固定事
用 工作流与定时任务 按 Cron 配四件固定事：
- 每月固定日生成"上月结算待办"，推给各项目部施工员；
- 每月出一次分包成本汇总，发给项目经理与财务；
- 质保金可释放日期前若干天提醒商务（提前天数按企业自有标准定）；
- 人员证件到期前提醒劳务员安排换证。
定时任务跑完有执行记录，跑没跑、成功没成功，可以直接查——比"我以为它发了"可靠。
四、审计日志：谁改了价、谁退了验收
单价被改、结算金额被调、验收被退回、付款被红冲——这类动作必须留痕。平台的审计日志会记录操作人、时间与操作内容，可以按模块查询和导出（见 AI 监控与审计日志）。
这一条的实际价值往往不在内部管理，而在对账与争议：分包队来问"这笔怎么少算了"，能当场翻出那条记录的来龙去脉，比谁记性好都管用。
移动端：真正需要手机的是现场，不是办公室
分包结算里最需要手机的三个动作，全都发生在工地：
- 进场登记——劳务员拿着手机，对着新来的人现场录入，证件照片直接拍；
- 量登记——班组长在楼层里填当天的数量、拍两张现场照片；
- 验收——施工员在楼上就能点"通过"或"退回"，不用回板房开电脑。
PC 上建好的模块会同步出现在手机端工作台，字段、权限、状态一致，不需要单独做一套手机页面（用法参见 移动端使用指南）。这一点对分包模块尤其重要：如果班组长必须回办公室才能报量，这套东西一周之内就会被微信群替代。
管理层那侧的手机用途不一样——老板在手机上看的是一页分包成本汇总，不会去点明细。
上线前要查的九条
模块做好不等于能用。这份清单建议在上线前逐条过一遍，每条都对应一个真实会出事的地方。
- 唯一约束是否生效：同合同号、同身份证号录第二遍，是否真的被拦住。这是数据干净的地基。
- 状态能不能退回：验收被退回后，班组长能否重新填报，退回后旧数据是否还挂在结算里。
- 单价改不改得动：非商务角色能不能改单价；能改的话，是否有审批与留痕。
- 结算金额能不能被手改：找一个结算单试着直接改总价，改得动就说明第四条设计决定没落地。
- 已付/未付算得对不对：抽三份合同，用付款流水手算一遍，和系统显示的未付余额对上。
- 数据范围收得够不够：用一个班组长的账号登录，确认看不到别的队伍的量和单价。
- 提醒真的发出去了：把定时任务手动跑一次，看通知发给谁、内容对不对、手机上收不收得到。
- 存量数据怎么进：在建项目的合同、班组名单、未结清量，用 Excel 导入一次，导入后回看总数对不对。
- 发布预检过一遍：用 模块的测试与发布 的预检流程跑一次，挂好菜单、确认移动端已同步、确认角色授权。
第 4、5、6 三条最常被跳过，也最容易在上线后第一个月出问题。它们不是技术问题，是设计有没有落地的问题。
之后可以怎么延伸
这个模块天然有两条延伸路：
横向接成本——分包结算只算清了"付出去的钱"。把材料与零星用工的台账接上，才看得清一个项目的完整成本。材料与用工那部分见 工程项目材料与用工：两个台账管住项目成本；现场的过程记录（施工日报、安全检查、隐患整改）见 工地施工台账。三篇讲的是一条线上的三段，不重复：材料用工讲"投进去多少"，本篇讲"结出去多少"，施工台账讲"每天发生了什么"。
纵向接财务——分包应付是公司应收应付的一部分。结算单核定、付款流水齐了之后，可以向上汇总到 应收应付，形成对分包队的往来账；项目维度再往上有 项目台账 管进度与投入。
人员维度也有一条：自有员工的人事档案与外部班组人员的实名档案是两回事，不必混在一张表里。自有员工走 员工档案与人事异动，外部班组人员留在本篇的人员实名档案中，退场即归档。
这个方案不做什么
把边界说清楚，比把能力说大更有用。以下这些，这个模块不做：
- 不做人脸识别、不做门禁闸机等硬件对接：实名登记是"录入 + 证件照片附件 + 唯一约束"的台账形态，不做活体识别与闸机联动。若企业已有门禁系统，进场数据仍需人工登记或在门禁侧另行对接。
- 不做工资银行卡批量代发：只登记"付了多少、付给谁、哪个月、有什么凭证"，真正的银行代发仍在银行侧完成。
- 不做图纸算量、不做工程量自动测量：量由人填报、由项目部验收，系统负责把依据留全。BIM 取值、图纸算量这类能力不在本方案范围。
- 不做税务申报与发票开具：与发票相关的动作放在财务系统里，本模块只提供结算与付款的依据数据。
- 不代替属地监管平台的实名制上报：各地对进场人员实名、工资专户、报表格式的要求不同，具体口径与时限以属地主管部门要求为准，本模块负责把内部台账记清，不承诺自动对接外部监管系统。
最后说一句实在话：这套东西的价值不在"多了一个系统"，而在于年底对账的时候，双方都能指着同一份记录说话——量是谁报的、谁验的、按哪个单价算的、付到哪一步了。这四句话能答清楚，分包结算就基本不乱了。