采购订单行删除校验与钉钉提醒：单一策略深度实战

这个策略解决什么问题

采购订单行被频繁删除，但没人盯。某制造企业上线新系统后，业务部门反馈「行数据老对不上」，根因往往不是录入错，而是订单行在采购、变更、关闭环节被反复删改。这类异常如果没人及时看见，会污染下游结算与对账。

本策略把 MySQL 中采购订单行删除次数的统计结果，作为治理的「探针」：超过阈值就通过钉钉机器人把消息推到指定群或人，触发人工介入。源端是 MySQL 的统计查询，目标端是钉钉的工作通知（群机器人 / 指定用户）。整套链路借助轻易云数据集成平台（Qeasy）落地，私有化部署。

数据流向与字段映射

数据流向：MySQL（统计源） → 轻易云（查询 + 拼装） → 钉钉（消息送达）。

源端关键 SQL 片段（脱敏后）：

• 关联表：采购订单头/行/物料/行扩展属性。
• 过滤条件：行已审核、单据创建日期 ≥ 起始日、限定工厂集合、删除失败标记非 Y、关闭状态非 Y。
• 输出：行级删除累计次数 times。
• 分页：limit :limit offset :offset，由轻易云绑定占位符，避免 SQL 注入风险。

中间层与目标端：当 times > 30 时，调用钉钉 topapi/message/corpconversation/asyncsend_v2，把 msgKey=sampleMarkdown 的 Markdown 消息按 userIds 推送。

字段对照表：

在轻易云上如何配置

1. 源平台 MySQL：选「WebAPI / select / POST」，主参数 main_params 与主 SQL 中的 :limit、:offset 一一对应；开启 idCheck，避免重复推送。
2. 目标平台钉钉：选「WebAPI / execute / POST」，路径 topapi/message/corpconversation/asyncsend_v2，字段 robotCode、userIds、msgKey、msgParam 按规范填入。
3. 消息拼装：msgParam 用 _function CONCAT(...) 现拼 Markdown，now() 取数据库时间，文案里写明「超 30 条暂不自动处理，请人工排除」，避免值班同学误解为系统已自动修复。
4. 私有化注意：机器人 Code 与 userIds 都在私有化租户内配置，不要硬编码在脚本里，统一在轻易云的「连接凭证」中管理，便于轮换。

实施步骤

阶段一：增量起点

• 把 SQL 起始日定为业务上线日，如 po_create_date >= '2025-01-01'，避免历史脏数据一次性灌进提醒，造成「狼来了」。
• 工厂白名单先收敛到当前在用的 2~3 个，后续新增再补，避免误推。

阶段二：全量触发

• 业务平稳后，把 SQL 改成「近 N 天增量窗口」或按 update_time 滚动，配合分页参数控制单次数据量。
• 阈值（30）先和业务对齐，是经验值，不是真理；后续按误报率调整。

阶段三：调度频率

• 源端 cron：5 14,15,16,17 * * *（下午整点后第 5 分钟）。
• 目标端 cron：10 14,15,16,17 * * *（比源端晚 5 分钟，确保统计已落地）。
• 避开业务高峰（如 9:00、14:00 的开单高峰），降低对源库压力。

踩坑复盘

• SQL 占位符忘记绑定：直接把字符串拼进 :limit，触发语法错误或全表扫描。稳妥做法是让轻易云做参数绑定，主参数与占位符严格一一对应。
• 阈值定死导致误报：30 是起点，不是终点。建议在轻易云里把阈值做成可配置参数，业务跑两周后再校准。
• 钉钉 userIds 写死：人员离职后消息发给空账号。典型应对是把 userIds 集中放在轻易云的「编码映射」里，统一维护、定期同步。
• 源端与目标端 cron 同分钟并发：源还没查完，目标就开始推，结果推送了「0 条」。两个 cron 错开 5 分钟，是这次项目里最朴素也最有效的修法。
• Markdown 文案歧义：「已处理」和「请人工排除」一字之差，值班同学的反应完全不同。文案必须明确「这是提醒，不是自动处置」。

适用场景与不适用场景

适用：采购订单行有频繁删改、单据量大、人盯不过来；需要轻量级治理探针，不做业务回写。不适用：要做「自动锁单」「行级回滚」这类强业务动作；阈值需动态学习、需关联多源数据做因果分析的复杂场景。