针对你在MF50删除计划订单时，调用MD_PLDORD_POST BADI的POST_AFTER_SAVE_MAN方法中无法查询到PLAF数据，但SE11中可见的问题，我整理了以下核心原因和验证方向：

1. 数据库事务的提交时机与隔离级别 #

这是最可能的核心原因：

• SAP处理计划订单删除时，实际的数据库修改（无论是物理删除还是逻辑状态更新）往往是在**异步更新任务（UPDATE TASK）**中执行的，而POST_AFTER_SAVE_MAN方法是在主程序的同步流程中触发的。此时更新任务尚未执行，数据库中的PLAF条目还未被修改，但你的BADI方法已经在尝试查询。
• 更关键的是，SAP默认使用可重复读（REPEATABLE READ）的数据库隔离级别：当前事务会保留一个事务开始时的数据库快照。如果删除操作已经在当前事务中执行（但未提交），你的SELECT语句会读取这个快照，看不到未提交的修改——但如果SE11是在另一个会话中打开的，它会读取数据库的最新状态（不在同一个事务内），所以能看到目标条目。
• 对比创建/编辑场景：这两种操作的数据库修改通常是同步执行的，或者BADI触发时机在修改提交后，因此SELECT能正常获取数据。

2. BYPASSING BUFFER的用法验证 #

你的SELECT语句语法是正确的，BYPASSING BUFFER确实会绕过ABAP的表缓冲，直接查询数据库。不过可以做两个快速验证排除其他小问题：

• 尝试补充UP TO 1 ROWS（虽然SINGLE已隐含该逻辑，但有时能避免隐含的语法坑）：

  SELECT plnum FROM plaf INTO @DATA(lv_plnum) 
         BYPASSING BUFFER 
         WHERE plnum = @im_plaf_new-plnum
         UP TO 1 ROWS.
  ENDSELECT.
  

• 在断点处确认im_plaf_new-plnum的实际值：确保参数传递没有问题，避免因字段为空或值错误导致WHERE条件不匹配。

3. 计划订单删除的逻辑类型 #

SAP中计划订单的删除可能是逻辑删除（设置删除标记，如字段loekz）而非物理删除：

• 如果是这种情况，你的SELECT语句没有过滤删除标记，理论上应该能查到条目，但可能在BADI触发时，删除标记还未被更新到数据库（还是更新时机的问题）。
• 可以在SE11中查看目标PLAF条目的loekz字段值，确认是否为逻辑删除；同时在BADI中尝试查询所有字段，看是否能获取到已标记删除的条目。

4. BADI触发时机的确认 #

查阅MD_PLDORD_POST BADI的官方文档：POST_AFTER_SAVE_MAN方法的“保存后”可能仅指ABAP层数据对象的保存，而非数据库事务提交。如果是这样，数据库的修改还在事务中未提交，导致当前事务的SELECT无法读取到最新状态。

快速验证方案 #

• 在BADI方法中临时加入COMMIT WORK（注意：仅用于测试，可能影响原有业务流程），然后再执行SELECT语句。如果能查询到数据，就可以确认是事务提交时机的问题。
• 查看MD_PLDORD_POST BADI是否有其他触发时机更晚的方法，确保数据库修改已经完成提交后再执行查询逻辑。

内容的提问来源于stack exchange，提问作者Ovidiu Pocnet