报工≠打卡：5个数据断点排查清单（技术实现视角）

在制造执行系统（MES）或高级计划排程（APS）实践中，'报工'常被误认为仅是操作员点击提交的终端动作。但真实数据闭环依赖上游多层静态配置的精确性。本文以工程师视角，逐项拆解5个引发报工数据失真、成本偏差与计划脱节的技术断点，每项均提供可落地的验证逻辑与修复路径------所有操作均可通过API调用、数据库校验或前端配置界面完成，无需定制开发。

断点一：人员未绑定技能 → 工序匹配失效

技术本质 ：系统在排产阶段执行资源约束检查时，依赖person_skill表与process_requirement表的skill_code字段精确匹配（区分大小写、全字符一致）。名称相似但编码不同（如WELD-A vs WELD_A）将导致JOIN失败，任务进入'伪就绪'状态。

可验证行为：

报工页面任务正常显示，但提交后返回HTTP 200但status字段未更新，或progress字段卡在99%；

数据库查询：

复制代码

SELECT * FROM task_assignment WHERE person_id = 'xxx' AND process_id = 'yyy' AND skill_match_status = 'failed';

修复步骤：

进入人员管理模块，批量导入CSV，确保skill_code列值与工序模板中required_skill_code完全一致；
启用系统级校验开关：validate_skill_code_on_save = true，阻止编码格式非法保存。

断点二：工艺路线未同步扩展属性 → 成本归集断裂

技术本质 ：BOM物料由bom_item表驱动MRP运算，而报工后成本拆分依赖process_route_step表中的extended_attributes JSON字段（含energy_kwh、aux_materials、qc_checkpoints等键）。二者无自动同步机制。

可验证行为：

同一工序在BOM中配置了coolant: 1.2L，但报工完成后，cost_allocation_log表中该工序的aux_material_cost为NULL；

SQL比对：

复制代码

SELECT b.item_code, p.extended_attributes->>'aux_materials' FROM bom_item b JOIN process_route_step p ON b.process_id = p.id WHERE b.process_id = 'zzz'

修复步骤：

在工艺路线编辑器中，为每个工序节点手动补全extended_attributes JSON对象；
启用映射校验：配置bom_to_process_sync_rule，当BOM变更时触发告警而非自动覆盖。

断点三：生产日历未关联设备 → 负荷计算失真

技术本质 ：设备负载计算公式为：available_capacity = (calendar_working_hours × efficiency) − maintenance_downtime。若equipment表中calendar_id为空，系统默认使用default_24x7_calendar（ID=1），忽略班次与节假日。

可验证行为：

负载视图中某设备显示100%占用，但device_load_history表中actual_operating_hours日均仅8小时；

查询冲突：

复制代码

SELECT e.code, c.name, c.priority FROM equipment e LEFT JOIN calendar c ON e.calendar_id = c.id WHERE e.code = 'MCH-001';

修复步骤：

批量更新SQL：

复制代码

UPDATE equipment SET calendar_id = 'CAL-2024-WHITE' WHERE department = 'machining';

设置日历优先级：确保特殊日历（如CAL-2024-NATIONAL-HOLIDAY）priority > 1，高于标准日历。

断点四：主辅资源未完整绑定 → 报工可行性校验绕过

技术本质 ：系统在任务生成阶段仅校验主资源（main_equipment_id），辅资源（模具、夹具、专用技工）校验延迟至报工提交时触发。若process_template中aux_resources字段为空或JSON结构不合法，校验逻辑跳过。

可验证行为：

报工成功提交，但后续重排日志出现ERROR: no available mold for process 'CAST-01'；
检查模板：SELECT aux_resources FROM process_template WHERE code = 'CAST-01'; ------ 返回NULL或{}即为断点。

修复步骤：

在工序模板中补全aux_resources JSON，示例：

复制代码

{"molds": [{"code": "MOLD-A", "install_time_min": 15, "remove_time_min": 10}], "special_workers": ["TECH-203"]}；

更新所有引用该模板的工艺路线，触发route_version++强制刷新缓存。

断点五：计划下发与报工表结构未对齐 → 数据解析丢失

技术本质 ：Excel上传服务调用Apache POI解析时，按预设Schema校验字段：report_date需匹配yyyy-MM-dd正则，order_qty必须为BigDecimal类型。非规范输入触发静默截断（非抛异常）。

可验证行为：

上传含2024.10.01的文件，数据库report_log中parsed_qty为0且error_msg为空；
多次上传同一task_id文件，report_history表中仅保留最后一条记录（无累加标识）。

修复步骤：

后端启用强校验：在ReportUploadService中添加@Validated注解，对ReportDTO字段加@Pattern(regexp = "\\d{4}-\\d{2}-\\d{2}")；
前端增加实时提示：Excel模板下载页嵌入JS校验脚本，检测日期格式与数字字段合法性。

工程建议：以上5类问题均可沉淀为自动化巡检脚本。例如，每日凌晨执行SQL健康检查：
sql 复制代码
SELECT 'unbound_skill' AS issue_type, COUNT(*) FROM task_assignment ta
LEFT JOIN person_skill ps ON ta.person_id = ps.person_id AND ta.required_skill = ps.skill_code
WHERE ps.skill_code IS NULL AND ta.status = 'assigned';
将结果推送至企业微信机器人，实现技术债主动发现。