从 Fiori 启动时，SALV ALV 返回 ME52N 后为何不刷新？

2026-11-04数据小许

结论

问题很可能出在刷新时机。navigate_to_transaction 返回且 sy-subrc 为 0，只表示导航调用没有报告错误，不能证明用户已经完成 ME52N 编辑并返回。代码在导航调用后立即执行 me->zrefresh_data( )。如果 Fiori 场景中的导航不会像 SAP GUI 那样暂停当前处理流程，报表可能在用户编辑前就已刷新，用户返回后也没有再次读取数据。

代码中的时序

当前逻辑是：

CALL METHOD cl_lsapi_manager=>navigate_to_transaction
  EXPORTING
    transaction       = gc_param_tcode-tcode1
    parameters_setget = lt_parameters_nav[]
  EXCEPTIONS
    error             = 1
    not_supported     = 2
    OTHERS            = 3.

IF sy-subrc NE 0.
  RETURN.
ELSE.
  me->zrefresh_data( ).
ENDIF.

ELSE 分支在导航方法返回后立即执行，并不表示用户已从 ME52N 返回。SAP GUI 中的表现可能与 Fiori tile 启动时的导航和页面生命周期不同，因此不能根据 GUI 场景正常运行，就认定两种场景会在同一时点恢复 ABAP 处理。

处理方式

将“启动 ME52N”和“用户返回后刷新”分别放在两个时点处理：

检查当前 Fiori 导航方式是否提供返回后的回调或事件，并确认该机制确实会在用户结束编辑并返回后触发。
将重新读取采购申请数据和更新 ALV 的逻辑放到返回处理路径中，不要只放在 navigate_to_transaction 返回后的 ELSE 分支里。
如果当前导航方式没有返回回调，就调整交互流程，让报表在重新激活或用户明确返回时重新读取数据。具体触发点取决于报表运行方式和 Fiori 集成方式。
检查 zrefresh_data( ) 是否先重新查询数据，再更新 ALV 当前使用的数据源并触发显示刷新。只刷新旧内表或 ALV 显示对象，不会自动读取 ME52N 中刚保存的值。

目标流程可以用下面的伪代码表示。on_return_from_transaction 仅指实际运行环境提供的返回处理点，不是可直接调用的 SAP 方法名：

" 用户点击 hotspot 时启动 ME52N
me->navigate_to_me52n( lv_banfn ).

" 在确认用户返回报表的处理点执行
me->zrefresh_data( ).

不要将伪代码中的占位处理点直接视为 CL_LSAPI_MANAGER 的 API。应先核实当前 SAP 版本、启动方式以及导航 API 是否提供相应机制。

排查要点

在 navigate_to_transaction 调用前后记录执行顺序，并在 zrefresh_data( ) 查询前后检查采购申请数量，判断刷新是在编辑前还是编辑后发生。
确认 ME52N 中的修改已保存，并检查报表重新查询使用的采购申请编号是否与 hotspot 传入的 BANFN 一致。
分别检查数据查询、ALV 数据源更新和 ALV 显示刷新，找出哪一步仍在使用旧值。
分别通过 SAP GUI 和 Fiori tile 启动，比较返回后的 ABAP 处理路径。如果 Fiori 返回时没有重新进入原报表的处理逻辑，就需要使用该运行环境支持的恢复或重新加载机制触发刷新。

仅凭给出的代码，无法确定 CL_LSAPI_MANAGER=>NAVIGATE_TO_TRANSACTION 在当前 Fiori 配置中的具体返回机制，也无法确认 zrefresh_data( ) 是否已正确更新 SALV 数据源。应根据实际导航生命周期和刷新方法的调试结果判断。