We’re experiencing a critical issue with our demand planning Fiori app in S/4HANA 1809. Multiple users from the S&OP team suddenly cannot access forecast data when they open the app. The error message just says “No authorization to display forecast data” without providing specific details.
I ran an SU53 trace for one affected user and saw authorization object S_TABU_DIS is being checked, but I’m not sure which PFCG role should contain this. The Fiori app worked fine until last week when we applied some security patches. Our entire S&OP cycle is now blocked because planners can’t view or update forecasts.
Has anyone encountered this specific authorization issue with the demand planning Fiori app? What roles need to be assigned to grant proper access to forecast data?
This is a classic case of incomplete authorization analysis after patching. Let me walk through the systematic resolution approach:
SU53 Trace Analysis:
First, have an affected user attempt to access forecast data in the Fiori app, then immediately run SU53 in their session. Document every failed authorization check - you mentioned S_TABU_DIS, but there are likely others like S_TABU_NAM (table name authorization) and potentially APO-specific objects if you’re using IBP. The SU53 output shows exactly which authorization objects, fields, and values are being checked. Export this to a spreadsheet for reference.
PFCG Role Configuration:
The standard role for demand planning is SAP_IBP_DEMAND_PLANNER (if using IBP) or SAP_APO_DEMAND_PLANNER (if using legacy APO). However, after your security patch, SAP likely introduced new authorization checks. Run transaction PFCG_TIME_DEPENDENCY to check if any time-dependent authorization profiles were affected by the patch date. Then use PFCG to compare your custom roles against the current SAP standard roles - transaction SU25 can help identify new authorization objects introduced by the patch.
Add these specific authorizations to your demand planning role:
S_TABU_DIS with DICBERCLS = appropriate table auth group
S_TABU_NAM for forecast-related tables (like /SAPAPO/FCST*)
S_SERVICE for OData service access
S_RFC for function modules used by the Fiori app
Fiori App Verification:
In transaction /UI2/FLPD_CUST, verify the catalog assignment for the demand planning app. The app should be in catalog SAP_IBP_BC_DEMAND_PLANNING_PC. Check that users have this catalog in their roles. Also verify the OData service activation - run /IWFND/MAINT_SERVICE and search for the demand planning service (typically /SAPAPO/IBP_DEMAND or similar). Ensure it’s active and the system alias is correctly configured.
The security patch likely introduced stricter authorization checks at multiple layers - backend ABAP authorizations, OData service level, and Fiori launchpad level. You need to address all three layers. After making role changes, have users log out and back in (or run transaction SU01 to reset their authorization buffer). This should resolve your S&OP cycle blockage.
This draft is based on general SAP S/4HANA knowledge. It has not been verified against your specific version and environment. Practitioners: verify the steps and share your experience below.
Check if the users have SAP_IBP_DEMAND_PLANNER role assigned. This role contains the necessary authorizations for forecast data access in the Fiori app. Also verify the catalog assignments in PFCG.
The SU53 trace showing S_TABU_DIS is a good starting point. This object controls table display authorization. After your security patches, the authorization defaults might have changed. I’d recommend running transaction SU53 immediately after the error occurs to capture the exact authorization object and field values being checked. Then compare the missing authorizations against what’s in your custom roles versus the standard SAP_IBP roles. Sometimes patches tighten security and expose gaps in custom role designs that worked before due to looser checks.
We had similar issues after patching. The problem was that our custom Z_DEMAND_PLANNING role was missing updated authorization objects introduced in the patch. Check SAP Note 2847329 which addresses Fiori authorization issues in 1809 after certain support packs.
Beyond the PFCG roles, verify the Fiori launchpad configuration. Sometimes the issue isn’t missing backend authorizations but rather the tile or target mapping configuration in the launchpad designer. Check transaction /UI2/FLPD_CUST and ensure the demand planning app has the correct semantic object and action assigned. Also validate that the OData service underlying the Fiori app has proper service activation in /IWFND/MAINT_SERVICE. I’ve seen cases where patches deactivate services that need manual reactivation.
Look into authorization object S_RFC as well. The Fiori app likely calls backend RFCs to retrieve forecast data, and if RFC authorizations are missing, you’ll get generic access denied errors. Check which function modules the app uses and ensure the roles have S_RFC with appropriate function group authorizations.