Top 20 SAP Interview Questions (With Answers)

A transparent table maps directly to a single database table with the same name and structure. It is the most common table type in SAP and can be accessed directly via SQL or Open SQL. A pooled table is stored in a table pool that contains multiple logical tables in one physical database table. Pooled tables are used for small, frequently accessed data like screen parameters and temporary values. You cannot use native SQL to join pooled tables.

Why interviewers ask this: It tests whether you understand the database layer of SAP, not just the ABAP language.

BAPI (Business Application Programming Interface): Standard, stable SAP-delivered methods for accessing SAP business objects. BAPIs are remote-function-call-enabled and are the preferred way to integrate SAP with external systems. They cannot be modified.

User Exit: SAP-delivered empty subroutines (FORM routines in includes) that you fill with custom code. They are older enhancement technology and not recommended for new development.

BAdI (Business Add-In): Object-oriented enhancement framework. Multiple implementations can coexist. BAdIs are the modern replacement for User Exits and are preferred for all new enhancements in S/4HANA.

When to use: Use BAPIs for integration. Use BAdIs for enhancement of standard SAP processes. Avoid User Exits in new projects — migrate them to BAdIs when possible.

An internal table is an ABAP data structure that stores multiple rows of data in memory — similar to a temporary table. The three types are:

• Standard table: Sequential access via index. Best for small-to-medium datasets where you process records in order.
• Sorted table: Always maintained in sorted order by key. Binary search is automatic. Best for datasets where you frequently search by key.
• Hashed table: Hash-based key lookup. Fastest for large tables when you always access by unique key. No index access, no loops by index.

Choosing the wrong table type is a common performance issue in SAP systems.

A field symbol is like a pointer — it references an existing data object in memory rather than creating a copy. When you assign a field symbol to an internal table row, modifying the field symbol directly modifies the table row. This avoids the overhead of copying data and is significantly faster for large internal tables.

A work area is a copy of a row. Changes to the work area must be explicitly written back to the table using MODIFY. Field symbols (using ASSIGNING) are preferred over work areas (using INTO) when performance matters.

Common causes: division by zero, accessing beyond the end of an internal table, type mismatch in assignment, SELECT that returns more rows than expected into a single work area, and time-limit exceeded for long-running programs.

To debug: go to transaction ST22 (ABAP Dump Analysis), find the dump by program name and timestamp, read the exception class and error description, check the line number in the source code, and reproduce in debug mode (transaction SE80 or use /H for debugger). For performance-related dumps, use SM50/SM66 (work process monitoring) and SE30 (ABAP runtime analysis).

The P2P cycle covers the end-to-end procurement process:

1. Purchase Requisition (PR) — internal request for materials/services
2. Request for Quotation (RFQ) — sent to vendors
3. Vendor Quotation — vendor responds with price
4. Purchase Order (PO) — formal order sent to selected vendor
5. Goods Receipt (GR) — material received, inventory updated (MIGO)
6. Invoice Verification (IV) — vendor invoice matched against PO and GR (MIRO)
7. Payment — processed by Finance (FI) via payment run (F110)

The 3-way match (PO + GR + Invoice) is the core control mechanism that prevents fraudulent or incorrect payments.

A standard PO is a one-time order for specific materials or services at agreed prices and quantities. It closes when the ordered quantity is delivered.

A blanket PO (also called a Framework Order or Contract in SAP) covers multiple deliveries over a time period with a total value limit rather than a fixed quantity. It's used for repeat purchases or service contracts where the exact schedule isn't known upfront. Goods receipts and invoice posting happen against the blanket PO until the value limit is reached or the contract expires.

A movement type is a three-digit code that determines what kind of inventory movement is being recorded. It controls which accounts get posted, which fields are required, and how stock values are updated.

Common movement types:

• 101: Goods receipt against Purchase Order
• 201: Goods issue to Cost Center
• 261: Goods issue to Production Order
• 301: Transfer posting between plants
• 501: Receipt without Purchase Order (free receipt)
• 601: Goods issue for delivery (Sales)

The O2C cycle is the complete sales process:

1. Inquiry — customer asks about product/price
2. Quotation — sales provides formal pricing
3. Sales Order (VA01) — customer confirms, stock reserved
4. Delivery (VL01N) — goods picked, packed, posted for goods issue
5. Goods Issue (VL02N) — stock reduced, ownership transfers
6. Billing (VF01) — invoice created, accounting entry posted
7. Payment — customer pays, cleared in FI

Each step creates a document and a link (document flow) that you can trace via VA03 → Display → Document Flow.

A condition type is a pricing element in SAP SD — for example, PR00 (base price), K007 (customer discount), MWST (tax), or VPRS (cost). Each condition type defines how the value is calculated (percentage, fixed amount, quantity-based) and where it comes from (condition records, calculation).

Pricing determination: When a sales order is created, SAP uses the pricing procedure (assigned via sales area + customer pricing procedure + document pricing procedure) to determine which condition types apply in which sequence. For each condition type, SAP searches for a condition record in a defined access sequence — checking key combinations from most specific (customer + material) to least specific (price list + material group). The first matching record wins.

SAP ECC (Enterprise Central Component) is the previous generation — built for traditional relational databases with row-based storage. It has a complex data model with redundant aggregated tables (like BSEG, KONV).

SAP S/4HANA runs exclusively on the SAP HANA in-memory database with columnar storage. Key differences: simplified data model (Universal Journal in Finance eliminates many aggregate tables), real-time analytics without separate data warehouses, Fiori UI replaces traditional SAPGUI transactions, and significantly faster processing for large datasets. All new SAP implementations must use S/4HANA — ECC mainstream maintenance ends in 2027.

(Model answer structure — adapt to your own experience)

"In a client project, an ABAP report was producing incorrect cost centre allocations for about 8% of records. I started by reproducing the issue in a test environment with the same data. I used the ABAP debugger to trace the SELECT logic and discovered a WHERE clause that used OR conditions — which caused incorrect records to be included when both cost centre and plant were provided. The fix was restructuring the SELECT to use explicit parentheses around OR conditions. I then built a test case covering all four combinations of inputs to prevent regression. The fix reduced the error rate to zero. I also added a comment in the code explaining why the parentheses matter — it's easy for someone to simplify that logic later and reintroduce the bug."

Key elements: specific situation, methodical debugging process, root cause identified, fix implemented, regression prevented.

First, I try to understand the business reason behind the requirement — sometimes clients ask for something specific when what they actually need is a business outcome that SAP standard can achieve differently. If after understanding the requirement there's still a genuine gap, I evaluate options in this order: (1) configuration, (2) BAdI/enhancement, (3) custom development. I document the gap analysis, present the options with pros/cons and impact on future upgrades, and let the client make an informed decision. I always discourage modifying SAP standard code directly — it creates upgrade headaches and is unsupported by SAP.