黑河市all《看潮企业管理软件》项目开发到第15个功能模块——工序统计的时候，我的第一反应其实挺简单的：这不就是写几条带SUM和COUNT的SQL，再把数字丢到报表页面上吗？可真上手做完4-3这个子任务才发现，工序统计最花精力的地方根本不在写代码，而在业务口径的对齐、重复数据的防护、统计边界的划分，以及一个数字从车间流转卡一路变成管理层看板的过程中，到底要经过哪些变形。这篇文章会把我在这个模块里的完整思路拆开来讲，包括怎么设计表、怎么写统计SQL、怎么和前端配合做下钻，以及实测时踩过的那几个坑。适合正在做企业管理类软件项目的开发者看，也适合企业内部要做生产统计报表的同事参考，里面所有SQL和设计思路都是可以直接抄到项目里改一改就用的那种。
1. 工序统计模块要解决什么问题：先理清业务边界
1.1 工序统计的源头不是一张报表，而是一线报工数据
很多人提到“统计”就想到月底做报表，但生产制造型企业里的工序统计，发生在每一天的每一道工序上。生产部门先把生产工单下发到车间，车间按工艺路线拆成多道工序，比如下料、机加、焊接、组装、检验，每一道工序做完之后，操作工要在系统里做“报工”，也就是登记这批活干了多少件、合格多少件、报废多少件、用了多少工时。等到这些报工数据积累起来，工序统计才有东西可以统计。
所以工序统计模块的核心任务，是把这些零散的报工记录按“工单、工序、时间、班次”等维度汇总，变成管理动作能用的数字。在《看潮企业管理软件》这个项目里，前14个模块已经把基础资料、订单管理、生产计划、物料领用这些环节打通了，工序统计排在第15个模块，算是把生产执行层真正闭合起来。没有这一环，管理人员只看到计划下达了，却不知道现场到底干到哪一步，也不知道哪个工序废品率异常，生产进度全靠电话问。
做4-3这个子任务时，前面阶段已经搭好了报表框架和基本查询，我的工作重心是两件事：一是把统计口径从头到尾重新校准一遍，二是把汇总数据到明细数据的穿透查通。从表面看这是纯功能开发，从内部看其实是在解决一个“数据如何变成决策依据”的问题，这也是为什么这个模块归在“编程与数学”系列课程下面——统计本来就是数学在生产管理里最直接的一种应用形式。
1.2 工序统计要覆盖的口径：产量、工时、质量、进度
工序统计不是简单地把所有报工数量加在一起，而是有不同的观察维度，每个维度服务的决策对象都不一样。整理成一张表能看得更清楚：
| 统计口径 | 核心指标 | 数据来源 | 主要用途 |
|---|---|---|---|
| 产量口径 | 完工数量、报工数量、工序完成量 | 报工表中的报工数量字段 | 判断生产进度是否正常，是否达到计划产量 |
| 工时口径 | 累计工时、单件工时、标准工时达成率 | 报工表中的实际工时字段 | 核算人工效率、评估工序能力、支撑计件工资 |
| 质量口径 | 合格数量、报废数量、合格率、报废率 | 报工表中的合格数和报废数 | 定位质量异常工序，分析缺陷集中在哪个环节 |
| 进度口径 | 计划完成率、剩余数量、在制积压量 | 报工表关联生产计划表的计划数量 | 掌握每张工单的执行状态，决定是否调整排产 |
这个表格看起来很简单，但它决定了后端查询条件和前端展示框架的设计。比如管理人员问“今天产量怎么样”，系统不能只返回一个总产量数字，而要拆到工序，否则他无法判断是否某个瓶颈工序拖了后腿。再比如质量管理员关心的是“哪个工序报废率高”，那前端展示时就必须同时显示合格率和报废数量，而不是只给他一张流水账式的报工列表。
这正好引出一个统计模块设计时的普遍原则：先从管理问题出发，反推需要什么指标，再去设计数据结构和统计逻辑。如果只盯着已有的报工字段，能输出一堆无用的报表，真正回答不了业务问题，这属于典型的“从数据到指标”，方向反了。
1.3 工序统计里的“数学”体现在哪里
标题里带了“编程与数学”，很多人以为是学习微积分、线性代数，其实工序统计里用到的数学并没那么高深，更多是统计学的思维。最核心的就是“口径”两个字——分子是什么、分母是什么，必须定义清楚。计算合格率，分子是合格数量，分母是报工数量还是报工数量减去未完检验数量？这两个口径算出来的数可能差两个百分点，如果不提前确认，后面所有报表都会错得莫名其妙。
还有平均数思维。管理人员经常会问“某个工序平均工时是多少”，很多人直接拿总工时除以报工次数，但正确做法是总工时除以合格数量，或者总工时除以报工数量。区别在于：一个有返工、报废的工序，单单计算平均每次报工耗时毫无意义，因为一次报工可能是500件也可能是5件。这个“加权平均”的思想不算难，但代码实现时最容易带偏，后面我会专门讲这一段。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 数据模型设计：把车间纸质记录变成能计算的表结构
2.1 计划表和报工表必须分开设计
做工序统计不能只盯着报工表，还要把生产计划表一起纳入模型。道理很简单，想统计“完成率”，就必须知道“计划量”。有些项目图省事，把计划数量和实际完成数量放在同一张表里，结果计划一旦调整，历史报工数据跟着受污染，统计结果就乱套了。
我的做法是保留两张核心表：
- 工序计划表（process_plan）：保存工单下每个工序的计划信息，包括计划数量、计划开始时间、计划结束时间、当前状态。
- 工序报工表（process_report）：保存现场每一笔报工流水，包括工单号、工序、报工数量、合格数量、报废数量、工时、操作工、设备、班次、报工时间。
两张表通过工单号加工序编号关联。这样设计最大的好处是职责清晰：计划表解决“应该做多少”的问题，报工表解决“实际做了多少”的问题，统计时如果要算完成率，动态关联两张表即可。即使计划调整了，也只是计划表里的数字变化，不会影响已经记录下来的报工事实。
报工表在数据库里的大致结构如下：
sql复制CREATE TABLE process_report (
id BIGINT PRIMARY KEY AUTO_INCREMENT,
report_batch_no VARCHAR(40) NOT NULL COMMEN