FinMES202603_ex.md 15 KB
两天台账排查逻辑与案例总结
1. 这次排查覆盖了哪些对象
这两天实际排查的对象，分成 5 类：
半成品收发存原表
YDM_BC_INITIAL / YDM_BC_INLIST / YDM_BC_OUTLIST半成品中间表
CX_YDM_BC_INITIAL / CX_YDM_BC_INLIST / CX_YDM_BC_OUTLIST成品收发存原表
YDM_ZC_INITIAL / YDM_ZC_INLIST / YDM_ZC_OUTLIST / YDM_ZC_STOCKTAKINGLIST成品中间表
CX_YDM_ZC_INITIAL / CX_YDM_ZC_INLIST / CX_YDM_ZC_OUTLIST月报与接口
- 热轧月报：
HOT_PRODUCTION_MES_RZ - 加工月报：
HOT_PRODUCTION_MES_JG - 判定表：
QCM_ZG_JUGDE_APPLY - 接口日志：
CX_TO_MES_LOG - 提单表：
YDM_ZC_BILL_M / YDM_ZC_BILL_C / YDM_ZC_LOADVEHICLE_MAT
- 热轧月报：
这 5 类对象里，最容易混淆的是：
- 原表
YDM_*：更像“当前业务真实源头” - 中间表
CX_*：更像“给校验/接口/月报使用的结果表” DataValidationResult：只是某一时点的校验快照，不代表当前库里实时值
所以排查时第一原则是：
永远先分清“是原表错了，还是 CX 表错了，还是校验结果只是旧快照”。
2. 核对的基本公式
2.1 半成品/成品跨月连续性
最常用的判断公式是：
本月期初 = 上月期初 + 上月入库 - 上月出库 (+ 调差)
其中：
半成品常用：
- 期初：
YDM_BC_INITIAL - 入库：
YDM_BC_INLIST - 出库：
YDM_BC_OUTLIST
- 期初：
成品常用：
- 期初：
YDM_ZC_INITIAL - 入库：
YDM_ZC_INLIST - 出库：
YDM_ZC_OUTLIST - 调差：
YDM_ZC_STOCKTAKINGLIST
- 期初：
2.2 月报和台账对比
月报不是直接跟“成品量”比，而是要先明确过程口径。
这次已经确认过一类典型问题：
- 有些第三方是直接拿
PROD_WEIGHT - 但系统过程实际用的是
PROD_WEIGHT - NVL(LC_WEIGHT, 0)
所以月报类问题第二原则是：
先确认“月报值的生成公式”，再谈是不是对不上。
3. 标准排查流程
后面再遇到类似问题，建议固定按下面 8 步走。
第 1 步：先确认问题是“哪一层”报出来的
先看报错来自哪里：
DataValidationResult- 第三方接口校验
- 人工 Excel 对账
- 月报和台账比对
这一步的目的，是避免把“汇总口径问题”误当成“明细错误”。
第 2 步：先做月度总额复核
先按物料或全口径聚合，确认差多少。
例如：
202601 -> 202602成品只差0.020t202603 -> 202604成品差2支 / 3.969t
这一步只回答一个问题：
到底是“大面积错”，还是“少数几条炉号造成的总差”。
第 3 步：再下钻到炉号
总额确认后，一定要立刻切到炉号级。
因为物料级报错里，常见会混进：
- 改判
- 换物料编码
- 红冲
- 月末 0 支尾重
- 同炉号跨工序迁移
这些问题在物料级看起来像“差了很多”，但炉号级一拆就能分出：
- 真错
- 改判
- 历史残留
第 4 步：同一炉号同时看原表和 CX 表
每个异常炉号至少要看 2 套数据：
原表
YDM_*中间表
CX_*
这一步的目的是把问题分型成：
- 原表错，CX 只是抄过去
- 原表已经对了，但 CX 还是旧值
- 原表没有，CX 多了
- 原表有，CX 漏了
第 5 步：看是不是“改判/换物料编码”
这一类在这次排查里占比很高。
表现形式通常是：
- 同一个炉号
- 上月在物料 A
- 下月或同月出库在物料 B
如果炉号本身是平的，只是物料变了，那通常不应该按“库存错误”处理，而应该按：
改判说明
第 6 步：看是不是“重复插入”
这次也遇到过非常典型的重复灌数：
- 原表应有 1 条
CX里被插了 4 次
这种问题最明显的特征是：
- 原表和业务逻辑都解释不出来这么大的数
- 同一炉号、同一月份、同一数量重量，
CX里出现多条
第 7 步：确定该改哪一层
这个很重要。
不是所有问题都该改原表。
判断规则：
- 原表正确，CX 错：改
CX - 原表月份挂错：改原表，必要时同步
CX - 属于改判：不改库存，出说明
- 属于月报算法问题：改过程逻辑或月报结果，不改收发存
第 8 步：修完以后一定复核
修完至少做 3 次复核：
- 行级是否对平
- 物料汇总是否对平
- 相关校验过程重跑后是否符合预期
4. 这次遇到的典型错误类型与案例
下面把这两天碰到的典型问题，按类型整理。
4.1 期初带错
典型案例：半成品 202601 -> 202602
涉及炉号：
A26010132A26010135A26010139C26010317
问题表现：
2026-01期末和2026-02期初对不上- 这 4 个炉号在
202602的YDM_BC_INITIAL被写成了“上月入库量” - 不是“上月期末量”
例如：
A26010132
- 1 月实际期末：
1支 / 1.48吨 - 2 月期初却写成：
64支 / 97.188吨
最终处理：
- 修
202602的YDM_BC_INITIAL - 再核
202601 -> 202602 -> 202603 -> 202604
经验结论：
如果某月期初恰好等于上月某类入库，而不是上月期末，优先怀疑期初生成逻辑错把“入库承接”当成“结存承接”。
4.2 原表已改正，CX 还停留在旧值
典型案例：TQ9618310507410B
涉及炉号：
A26010109A26010113A26010120A26010132A26010135A26010139C26010317
问题表现：
- 当前原表已经改正
- 但
CX_YDM_BC_*里还是旧数据 - 导致
check_material_balance或DataValidationResult继续报错
处理方式：
- 不回头再改原表
- 直接把
CX按当前原表同步
经验结论：
先看“现在的原表”是不是已经对了，再决定要不要动源表。很多时候问题只是结果表没刷新。
4.3 重复插入
典型案例：TQ0218312001410B
涉及炉号：
A25070249A25070271A25080210
原表应有：
A25070249：1支 / 1.305吨A25070271：1支 / 1.646吨A25080210：2支 / 3.213吨
CX_YDM_BC_OUTLIST 实际却是每条 4 次：
A25070249：4行 / 4支 / 5.220吨A25070271：4行 / 4支 / 6.584吨A25080210：4行 / 8支 / 12.852吨
处理方式：
- 保留最早 1 条
- 删除后面 3 条重复数据
经验结论：
同一炉号、同一月份、同一数量重量重复出现时，不要先怀疑业务，先怀疑 CX 持久化被重复执行。
4.4 改判/换物料编码
典型案例 1：TQ9618310507410B 与 TQ9618312007410B
表现：
- 同一批炉号
2026-02在TQ9618312007410B2026-03期初挂到了TQ9618310507410B
这类问题在物料级会表现为：
- 一个物料突然多
- 另一个物料突然少
但炉号级看是平的，只是物料变了。
这种情况更适合：
- 出“改判说明”
- 不按普通库存错账处理
典型案例 2：TD0719312307411B
涉及炉号：
C26010494
历史 CX 快照里：
TD0719312307411B表面剩5支 / 12.618吨- 同炉号又有
TQ5612412301411B出库5支 / 12.618吨
这就是典型“同炉号跨物料改判”。
经验结论：
只要同一炉号跨物料迁移且炉号级自平，优先归类为改判，不要急着补期初。
4.5 尾重
典型案例 1：成品 A22070051
问题：
202601期末到202602期初只差0.020吨
最后处理：
- 在
YDM_ZC_STOCKTAKINGLIST补了一条202601调差 - 重量
-0.02 - 后来又把规格调整成正确的
533.8x24.5
典型案例 2：TB8818212001411C
涉及炉号：
A25050280
原始情况：
- 期初：
1支 / 2.258吨 - 负入库：
-1支 / -2.095吨 - 导致期末形成
0支 / 0.163吨尾重
处理方式：
- 把负入库重量改成和期初一致
-2.095 -> -2.258
经验结论：
只差零点几吨、支数为 0 的，优先按尾重处理。
4.6 红冲导致跨月不平
典型案例：成品 A25100221、A25100033
表现：
202603没有期初、没有入库- 但出现了
800806负出库红冲
例如：
A25100221
2026-03出现800806 = -1支 / -2.265吨- 会把库存冲回成
1支 / 2.265吨 - 但
202604期初没承接
A25100033
202602本来已清零202603又有800806 = -1支 / -1.704吨- 又被冲回
1支 / 1.704吨 202604也没承接
经验结论：
没有期初、没有入库，不代表不可能有库存。只要有负出库红冲，就可能把历史库存冲回来。
4.7 月份挂错
典型案例：TQ4577615272411B / C26030094
问题：
- 月报里
2026-03该有24支 / 23.233吨 CX_YDM_BC_INLIST里只有12支 / 11.393吨
后来追到原表发现：
- 另一半
12条 / 11.84吨被挂在了202604 - 实际应属于
202603
处理方式：
- 把原表
YDM_BC_INLIST那12条的BAL_YEAR_MONTH202604 -> 202603
- 再同步
CX
处理后：
- 月报
72.867 - 台账
72.867 - 对平
经验结论：
如果差值能完整在相邻月份找到，优先怀疑 BAL_YEAR_MONTH 挂错，而不是重量算错。
4.8 月报来料重量算法错误
典型案例：加工月报 TQ9618310507203B
问题表：
HOT_PRODUCTION_MES_JG- 来源过程：
MES_CX_JG_ZXNEW_HAND
异常表现：
mate_weight只有2~3吨prod_weight却有90~125吨steel_waste被算成3900%
根因：
- 过程用的是
mate_weight = sum(qcm.input_weight) + 接箍重量 - 但这批
G工序记录里，QCM_ZG_JUGDE_APPLY.INPUT_WEIGHT大量为 0 - 结果只剩接箍重量
后来按你的业务逻辑核定：
前一道工序的成品量 = 下一道工序的投料量
示例：
A24120546
D 工序合计：
ACT_COUNT = 76ACT_WEIGHT = 94.992
G 工序当前：
ACT_COUNT = 76ACT_WEIGHT = 99.307INPUT_WEIGHT = 0
所以应补：
G.INPUT_WEIGHT = 94.992
对应月报重算：
- 原
MATE_WEIGHT = 2.509 - 改后
MATE_WEIGHT = 94.992 + 2.509 = 97.501 - 原
STEEL_WASTE = 3958.0311 - 改后
STEEL_WASTE = 101.8523
最后处理：
- 改了
QCM_ZG_JUGDE_APPLY - 同时改了
HOT_PRODUCTION_MES_JG - 并做了可回滚备份
经验结论：
月报“来料重量很离谱”时，不要直接改结果表，先追来源公式。
4.9 接口重复接收与提单异常
典型案例：KHFT260325016
日志顺序：
GetYdmZcBillDateBillRevokeGetYdmZcBillDate
另外核到：
- 两次
GetYdmZcBillDate的SOCKET_PARMER - 除
planStartTime / planEndTime外，其余完全一致 - 也就是同一张提单被重复推送了一次
同时还发现：
- 提单主表曾出现过两条
- 明细只有 25 条，不是重复 50 条
BillClose传参里的炉号和库里的JUDGE_STOVE_NO对不上YDM_ZC_BILL_C.LOADVEHICLE_FLAG还有 14 支没同步成已装车
经验结论：
接口问题一定要同时看：接口日志、主表、明细表、装车表、代码匹配字段。只看一张表很容易误判。
5. 如何判断“该补数据”还是“该出说明”
后面再碰到问题，可以直接按下面判断。
应该补数据
满足以下任一：
- 原表月份挂错
CX重复插入CX漏同步- 尾重非常明确，且能精确落到一条记录
- 红冲/调差值能明确定位到某行
不建议直接补数据
满足以下任一：
- 同炉号跨物料改判
- 月报来源逻辑本身不对
- 当前原表已经查不到来源，只剩历史快照
- 只能看出总差，无法落到具体炉号和具体行
应该出说明
满足以下任一：
- 炉号级平衡，只是物料编码变了
- 外部按物料汇总报错，但内部按炉号级不算错
- 第三方校验口径和系统口径不一致
6. 一个实战排查模板
后面你自己核某个问题，可以直接照这个顺序：
先写下问题对象
物料、合同、月份、报错内容先做月度总额对账
期初 + 入库 - 出库 (+ 调差) = 期末再拆到炉号
找出差异是哪些炉号造成的同时查原表和
CX判断是以下哪类：
- 期初带错
- 原表已改，
CX未同步 - 重复插入
- 改判
- 尾重
- 红冲
- 月份挂错
- 月报算法问题
- 接口重复或字段错配
决定处理方式：
- 改原表
- 改
CX - 改月报来源表
- 仅出说明
修完后复核：
- 行级
- 炉号级
- 物料级
- 校验结果
7. 可直接复用的 SQL 思路
下面不是最终 SQL，只是核对时最常用的模式。
7.1 查某物料某月原表入出
select *
from ydm_bc_inlist t
where t.bal_year_month = '202603'
and t.material_no = '物料编码';
select *
from ydm_bc_outlist t
where t.bal_year_month = '202603'
and t.material_no = '物料编码';
7.2 查某炉号 1-4 月全链路
select 'INITIAL' src, t.bal_year_month, t.material_no, t.judge_stove_no,
t.act_count, t.act_weight
from ydm_bc_initial t
where t.judge_stove_no = '炉号'
union all
select 'INLIST', t.bal_year_month, t.material_no, t.judge_stove_no,
t.act_count, t.act_weight
from ydm_bc_inlist t
where t.judge_stove_no = '炉号'
union all
select 'OUTLIST', t.bal_year_month, t.material_no, t.judge_stove_no,
t.act_count, t.act_weight
from ydm_bc_outlist t
where t.judge_stove_no = '炉号';
7.3 查原表和 CX 是否一致
做法不是只比汇总，而是至少比：
- 月份
- 物料
- 炉号
- 合同
- 支数
- 重量
如果汇总一样但明细不一样，后面还是会炸。
8. 这次已经被验证过的经验
最后把这两天最有用的结论压成几句话，后面很好用。
先看炉号，再看物料。
很多“物料不连续”，其实是炉号改判。先看原表，再看
CX。
很多问题只是结果表旧了，不是源头错了。尾差优先看调差和红冲。
尤其是0支 非0吨，十有八九不是正常库存。月报不要直接拿结果说话。
先搞清楚是从哪张判定表、按什么公式写出来的。接口问题一定要串日志、代码、数据库。
只看其中一块，很容易得出错结论。
9. 当前还值得继续追的点
截至当前，这几类仍然属于“后续可以继续排查”的方向：
当前库里完全没有、但外部说有的数据
例如某些销售结算接口物料月报有值、原表当前查不到来源的数据
例如曾遇到的TQ5612510601412B改判链跨了多个月、当前只剩历史快照的数据
这类问题的共同点是：
不能只靠当前原表，还要追历史快照、过程、接口源表。
10. 一句话版总结
这两天所有问题，归根到底都是下面几类：
- 承接错
- 月份挂错
CX没同步CX重复插入- 红冲/尾重
- 改判
- 月报公式取错来源
- 接口重复推送或匹配字段不一致
只要后面排查时固定坚持：
先总额、再炉号、再原表/CX 对照、最后再决定改数据还是出说明
大多数问题都能很快定位清楚。