Scenario-Based SAP Interview Questions

I would show one process end to end. Today a sales person checks stock in one sheet, billing is typed into the accounts tool and stock is updated later, so numbers rarely match. In SAP, the sales order checks availability, the delivery reduces stock, and billing posts revenue and the customer receivable automatically. Management sees real-time stock and margin, GST invoices are consistent, and month-end closing takes days instead of weeks.

I first understand the real need behind the request, such as speed of entry or seeing a specific field. Then I show the standard Fiori app or transaction with personalisation, variants and layout options. If the gap still matters, I record it in the backlog with business value, and suggest a clean option such as a custom field or a small BTP app. I document the decision so the steering committee can approve or reject the effort.

I confirm impact and scope quickly: which users, company codes and transaction or app, and the exact error message with its message number. I try to reproduce in production with my display access or in quality with similar data. I check recent transports, period status, authorizations and system logs. I update the ticket and stakeholders every set interval, apply a workaround if possible, fix the root cause through proper change control, and write a short RCA.

I assess process quality, custom code, data volume, history needs, timeline and organisational change appetite. If processes are outdated, there is heavy custom code and they want to adopt best practices, greenfield fits. If processes work well, the timeline is tight and history is important, brownfield conversion is cheaper and faster. If they need to merge company codes or move only some units, selective data transition fits. I back the advice with a readiness check and custom code analysis.

I route every change through a change request process: description, business value, effort, impact on timeline and testing. Changes that are mandatory for go-live, such as legal needs, are prioritised; nice-to-haves move to a post go-live release. I show the steering committee a clear impact view so decisions are made by the right people. This protects the go-live date while still capturing valid requirements in the backlog.

I check the import log in STMS to confirm the request was imported without errors (return code 0 or 4). Then I confirm the change was saved in the right request and client, and whether it was client-specific customizing that needs a client copy or import into the specific QAS client. I also check for missing dependent transports, such as a new field or table that the configuration relies on, and object locks in another request.

I check what runs at that time: background jobs in SM37, active work processes in SM50 or SM66, and the workload monitor ST03N for response time breakdown between database, CPU and wait time. If heavy batch jobs overlap with peak dialog use, I reschedule them. If one report dominates, I trace it with ST12 or SQL trace ST05. I also check HANA memory and expensive statements with the DBA Cockpit or HANA cockpit.

First I measure usage with ABAP Call Monitor (SCMON) or usage procedure logging to find dead code, which is often 40 to 60 percent and can be retired. Then I run the ABAP Test Cockpit with S/4HANA readiness checks to find code affected by simplifications. Remaining objects are fixed, replaced by standard functions, or redesigned as clean extensions. The custom code migration app helps track progress, and the plan is part of the conversion timeline.

I discuss downtime-optimized approaches in SUM such as downtime-optimized DMO and near-zero downtime technology, where most migration and data conversion run while the system is still live and only delta changes are processed during the final window. I also plan archiving to reduce data volume, several mock conversions to measure timing, a tested reconciliation of key financial and stock figures, and a rollback plan. The final choice balances cost against allowed downtime.

I check whether the user's business role contains the business catalog that holds the app, and whether that role is assigned and active in SU01 or PFCG. Then I confirm the tile is placed on a space and page assigned to the role or that the user can find it in app search. If the tile shows but fails, I check that the OData service is active and that the user has the back-end authorization. Clearing the launchpad cache can also help.

I ask the user to run SU53 right after the error, which shows the failed authorization check, including object and missing value. I compare it with their roles in SU01. If the access is valid for their job, I raise an access request through the approved process so the security team adds the correct role, rather than giving direct access. I also check segregation of duties rules before approval.

For SAP GUI transactions I can use transaction variants and screen variants (SHD0) to hide, default or make fields display-only, then assign a variant transaction code. For many documents, field status groups or field selection settings in customizing control required, optional or suppressed fields. For Fiori apps, key users can use adapt UI to hide fields. I choose the option that does not modify SAP code.

I open the browser developer tools to see failing network calls and the HTTP code. Then in the back end I check /IWFND/ERROR_LOG on the gateway and /IWBEP/ERROR_LOG on the back end for the service error, ST22 for dumps, and SU53 for missing authorizations. I confirm the OData service is activated in /IWFND/MAINT_SERVICE and the ICF nodes are active in SICF. Finally I clear the cache and test again.

I would create three company codes, one per legal entity, because each needs separate legal financial statements. The two Indian codes use INR, an Indian chart of accounts version with GST, and an April to March fiscal year. The Dubai code uses AED with UAE VAT and usually a January to December year. All three can share one controlling area if group reporting needs common cost accounting and settings allow it.

I check the customer's sales area data in BP, such as pricing procedure indicator, price group and price list, and the material's sales data, such as material pricing group. Then I check condition records for the customer and material in the relevant condition types and validity dates. Finally I run the pricing analysis inside the sales order to see which condition was found and why others were skipped.

I first stop the risk: block duplicates for payment and posting and reconcile open items. Then I clean the data by merging or archiving duplicates. Long term, I enforce duplicate checks on PAN, GSTIN and bank account in BP creation, use a central governance process such as SAP Master Data Governance or an approval workflow, restrict who can create suppliers, and run monthly duplicate reports for audit.

I decide whether it is a new plant or a new storage location in an existing plant, based on valuation, GST registration and MRP needs. If it is a plant, I create and assign it to the company code, purchasing and sales organizations, set up storage locations, extend material masters to the plant, update shipping points, pricing, tax and number ranges, and adjust roles and interfaces. Then I test procure to pay and order to cash for the site.

I would match the module to their background and interest. Commerce, accounting or CA students fit FICO. Supply chain, mechanical or operations graduates fit MM, PP or EWM. Those who like selling processes fit SD. Coders fit ABAP or Fiori development, and system-oriented people fit Basis or security. I would also suggest first learning S/4HANA basics, then one module deeply, plus integration with its neighbour modules.

I would discuss embedded EWM in S/4HANA for scanner-based putaway, picking and packing with strategies and storage bin control, and decentral EWM if the warehouse is very large or must run independently. For simpler sites, inventory management with storage locations and Stock Room Management may be enough. The choice depends on volume, complexity, automation and budget.

I look at their HR roadmap, payroll complexity, local legal needs such as Indian statutory payroll and PF rules, current customizations, cloud policy and timeline. SuccessFactors gives modern talent processes and quarterly innovation, and SAP's strategy favours it. On-premise HCM for S/4HANA suits companies needing deep payroll control on-premise. A hybrid with Employee Central and existing payroll is often a step-by-step path.

For operational KPIs I would start with embedded analytics: standard analytical Fiori apps and custom analytical queries on CDS views, which show live data. For management dashboards with charts and drill-down, I would connect SAP Analytics Cloud live to S/4HANA. If they need to combine data with non-SAP sources or long history, I would add SAP Datasphere. This avoids extracting data unnecessarily.

I read the full message, which usually names the transaction key, chart of accounts and valuation class, for example account determination for entry BSX not possible. I check the material's valuation class in the accounting view and OBYC settings for that key and valuation grouping. If the configuration is missing for a new valuation class or plant, I add it in development, test, and transport. Often the master data is the real issue.

Status 51 means application error. I open the IDoc in WE02, read the status message, and check the data segments, for example an unknown customer material number, missing partner function or invalid pricing. I correct master data or mappings, then reprocess the IDoc with BD87. If many fail, I find the common cause, inform the sender if the data is wrong, and add monitoring alerts.

It is usually blocked because of tolerance limits, for example price or quantity differences between PO, goods receipt and invoice, or a manual payment block. I check the blocking reason on the invoice. After the buyer confirms the price or quantity or the goods receipt is posted, the invoice is released with MRBR or the Release Blocked Invoices app. Tolerance keys are configured in OMR6.

I would expose a released sales order API, such as the OData Sales Order API, through SAP Integration Suite with authentication, mapping and error handling. The e-commerce site calls it synchronously for order creation and gets the order number. Stock and price updates flow back through APIs or events. I would add idempotency keys to avoid duplicates, monitoring with alerts, and a retry queue for failures.

A growing GR/IR balance means goods receipts without invoices, invoices without goods receipts, or quantity and price differences that were never cleared. I analyse open items by PO with standard reports, follow up with buyers and suppliers, post missing documents, and use the GR/IR clearing transaction MR11 for small differences after approval. At month end, GR/IR regrouping with F.19 or the S/4HANA app shows correct balance sheet presentation.

In S/4HANA I would first try key user extensibility with the Custom Fields app, which adds the field to the database, Fiori UI, CDS views and APIs without code. If logic is needed, I use the Custom Logic app or a released BAdI. Only if these do not cover the case would I use classic enhancement such as a screen enhancement in ME21N. I document the choice for upgrade safety.

I check ST22 for the dump details, program, line and call stack. TIME_OUT means a dialog step exceeded the allowed run time (rdisp/max_wprun_time). I see if users ran it with very wide selections, and advise background execution as an immediate workaround. Then I trace the code with ST05 and SAT in quality with similar data, fix inefficient selects or loops, and move the fix through transports.

I combine ATC results with usage data from SCMON or UPL so unused objects are removed first. For used objects I fix mandatory findings first, such as removed tables, changed field lengths like the 40-character material number, and syntax errors. Performance and best-practice findings come later. I group similar fixes, use quick fixes in ADT where possible, and track progress with the custom code migration app.

I would not allow direct table access because it breaks clean core and security. I would check the SAP Business Accelerator Hub for a released OData API or event that covers the data. If none exists, I would build a custom CDS-based RAP service using released objects in the S/4HANA system and expose it through a communication arrangement, then call it from BTP through destinations with proper authentication.

I would write a report that selects open orders using a CDS view or ABAP SQL with proper filters, formats the data to the agreed layout, and writes the file to an application server directory or sends it through SAP Integration Suite. I would add a selection screen with variants, logging with the application log (SLG1), error notifications, and schedule it in SM36 or Application Jobs. Testing covers volume and format checks.

I would add a lock object in SE11 on the table key and call the generated ENQUEUE function before changing data and DEQUEUE after saving, so the second user gets a lock message. I also check that the update happens in one logical unit of work with proper COMMIT WORK. In RAP-based apps, managed locking and ETag handling solve this automatically.

Users can first check the table settings, because many fields are available but hidden. If the field exists in the service but not the UI, a key user can use Adapt UI or a developer can add an app variant or annotation extension. If the field does not exist, the Custom Fields app can add it and enable it for the app. A custom app is the last option.

I check that workflow items are actually assigned to the user in the inbox, using workflow logs in SWIA or the Manage Workflows app. Then I confirm the user has the My Inbox app role and back-end authorization, the OData services for the task gateway are active, and the task definitions are registered for the inbox scenario. Substitution rules and outdated cache can also hide items.

I would analyse transaction usage with ST03N and the Fiori Apps Recommendations report to map transactions to standard Fiori apps. Then I design business roles per job with spaces and pages, activate apps in waves starting with high-volume users, keep SAP GUI for HTML tiles for transactions without apps, train key users, and collect feedback. Custom apps are built only where real gaps remain.

I would first check if a standard Fiori app on mobile meets the need, since Fiori is responsive. For offline use, I would consider SAP Build apps or the SAP Mobile Services on BTP. The app would call a released OData API or a custom RAP service through BTP destinations with secure authentication. I would design for limited connectivity, data sync and simple screens.

I check the browser console and network calls for errors, then the gateway error logs. Upgrades often change the SAPUI5 version, so I look for deprecated controls or APIs, and check if the back-end service or CDS view changed. I test in quality with the UI5 support assistant, fix deprecated code, update the manifest's minimum UI5 version, and redeploy. Regular upgrade testing prevents surprises.

I show them their launchpad layout and the few apps they need, how to search apps, use filters and save views, and how list report and object page work together. I compare one familiar transaction with its Fiori app side by side. A short quick reference guide and a follow-up after a week usually build confidence, and their feedback helps improve role design.

I first confirm both systems have the same transport version of the program using version comparison. Then I compare the data itself, because test data, client settings and customizing differ between systems. I check selection screen defaults, user parameters such as company code, authorization-based filtering in CDS access control, and currency or unit conversion. Debugging with the same input on both systems usually shows the difference quickly.

I check the sales order for incompleteness, credit block or delivery block in the header or schedule line, and whether the requested delivery date and confirmed quantity exist after availability check. Then I check shipping point determination, the item category's delivery relevance and the delivery type copy control. VL10 or the delivery due list shows the log of why an order was not selected, which usually points to the exact reason.