We implemented a custom BAdI (BADI_MRP_STOCK_ADJUST) for MRP Live to adjust safety stock calculations based on seasonal demand patterns. The BAdI executes successfully and we can see the adjusted values being written to custom tables during MRP runs. However, our MRP reporting dashboard shows stale data - it takes 15-20 minutes for the updated planning results to appear in the Fiori analytical apps.
METHOD if_badi_mrp_stock~adjust_safety_stock.
lv_adjusted = iv_safety_stock * get_seasonal_factor( ).
INSERT INTO zmrp_adjustments VALUES ( ... ).
ENDMETHOD.
The MRP Live engine shows correct results immediately in transaction MD04, but reports lag significantly. We suspect there’s a buffer or commit issue with how BAdI changes integrate with the analytics layer. Has anyone dealt with delayed reporting after implementing MRP BAdIs? The planning team needs real-time visibility for production decisions.
I tried adding COMMIT WORK but it actually caused a runtime error - looks like you can’t use explicit commits inside BAdI implementations in this context. The error message said something about update task conflicts. Is there a different approach?
The issue is that MRP Live uses asynchronous update tasks for performance reasons. Your BAdI changes are committed in an update task that runs separately from the main MRP process. The analytical layer queries the database before the update task completes. On 1909, there’s a parameter in customizing (transaction OMDI) called MRP_LIVE_UPDATE_MODE - change it from ‘A’ (asynchronous) to ‘S’ (synchronous) for your plant. This forces immediate commits but impacts MRP performance. We made this change for critical planning plants and it solved the reporting lag, though MRP runs take about 10% longer now.
The MRP_LIVE_UPDATE_MODE parameter helped reduce the lag to under 5 minutes, which is acceptable for now. Still investigating the analytics extraction schedule as a potential additional factor.
Before you switch to synchronous mode across the board, consider that the 10% performance hit can become significant in plants with thousands of materials. An alternative is to implement a custom refresh mechanism for the analytical layer. Use the BAdI exit point to trigger a buffer invalidation call for the affected materials. This way you keep async updates but force the analytics cache to refresh for changed materials only. Check if your Fiori apps use CDS views with buffering enabled - that’s often the culprit for stale data in analytics.