门店库存预警页面上，华东地区的一批商品刚被标记为缺货。运营人员追查时发现，问题并不局限于几家门店，同一批次的商品还分布在多个仓库，相关补货建议、调拨申请和预警记录都需要重新计算。此时若写一段程序，逐家门店读取库存、逐条计算、逐条更新，处理范围虽然很广，速度和结果却未必可靠。把这种局面放进《仙剑奇侠传》，很容易想到赵灵儿的地裂天崩，一次出招，大片区域同时受到影响。ABAP 里没有名叫地裂天崩的语句，也没有按一下就能安全修改整套业务数据的万能函数。但若把这招理解为「先圈定受影响区域，再对区域内大量对象施加同一种规则」，ABAP 确实有相应的技术组合。它由三个动作构成，利用数据库的集合运算找出范围，利用业务对象或受控接口执行批量变更，利用后台作业分批完成并记录结果。真正值得研究的不是一次能打中多少条数据，而是怎样保证每一条命中的数据都改得对、改得稳、查得清。地裂天崩的第一个关键是地面从哪里裂开。业务程序也必须有清晰的边界。库存预警的范围可以由公司代码、工厂、物料、批次和统计时点共同确定。少一个条件，程序可能把正常库存也纳入；多一个错误条件，急需处理的门店又会漏掉。我们通常把这一阶段叫作确定候选集。候选集只是待检查的对象，并不等同于最终允许修改的对象，因为后续还要检查权限、状态、并发变化以及业务规则。设想我们维护一张自有的库存变化汇总表ZT_STOCK_DELTA，其中保存工厂、物料、变化数量和业务日期。下面的 ABAP SQL 片段展示如何在数据库侧按工厂与物料汇总数量。表名和字段名代表这个案例中的自有模型，落地时需要按实际数据结构调整。SELECT