SAP Interview Questions

Go-live questions test composure, prioritisation and communication. Use STAR, and show that you worked inside the cutover plan and its go/no-go checkpoints rather than improvising alone.

• Situation: for example, “During our S/4HANA go-live, the open purchase order load failed validation for 18 percent of records, eight hours before the business was due to start transacting.”
• Task: fix the load without pushing the go/no-go decision or compromising data accuracy.
• Action:
  1. Raised it immediately in the cutover war room with a clear impact statement: how many records, which plants, what happens if they are missing on Monday.
  2. Read the Migration Cockpit error messages and grouped them. Most failures came from materials not extended to a new plant and suppliers missing purchasing organisation data.
  3. Agreed a fix with the data owners: extend the materials (MM01 or a mass upload) and the supplier data in BP, then reload only the failed records.
  4. Reconciled counts and PO values against the legacy extract and obtained business sign-off before the checkpoint.
  5. Logged the issue, workaround and decision in the cutover tracker.
• Result: “All open POs were loaded and signed off two hours before the checkpoint, and go-live went ahead on schedule.”

Finish with the lesson: for example, adding plant-extension checks to the pre-load validation and running one more mock cutover with a full production-like data set. Interviewers like hearing that mock cutovers and rollback plans exist precisely for moments like this.

Note: Mention who you escalated to and when; a good cutover story shows you respected the decision process, not that you heroically fixed everything alone.

This question checks whether you can protect a clean, maintainable system while keeping the business on side. Show empathy first, then evidence, then a clear decision path.

1. Understand the real need. Ask what problem the user is trying to solve, not what screen they want. Often the request copies the old legacy process rather than the underlying requirement.
2. Demonstrate the standard option. Show the process working in a sandbox or starter system. For example, a request for a custom purchase order approval program can usually be met with a release strategy configured on value, plant and purchasing group, approved through ME29N or a Fiori approval app.
3. Make the cost of custom visible. Explain build and test effort, upgrade risk, extra support and how it conflicts with a clean core approach, in plain business terms.
4. Offer middle ground. Configuration, key-user extensibility (custom fields or logic), a released BAdI, or a small side-by-side extension on SAP BTP may close the gap without modifying the core.
5. Escalate transparently if needed. If you still disagree, take both options to the design authority or process owner with a recommendation, and document the decision.

Example: “The procurement head wanted a Z workflow for PO approvals. I demonstrated a three-level release strategy in the sandbox and showed it met the audit need. We agreed to use standard and added one custom field through key-user extensibility for the budget code. It saved about six weeks of development.”

Note: Do not present yourself as someone who always says no; show that you said yes to the requirement and found the cheapest sustainable way to meet it.

Finance teams live by closing calendars, so interviewers want to see urgency, a structured fix and prevention. Keep the story tight and quantify the time pressure.

• Situation: for example, “At the March year-end close (fiscal year variant V3, April to March), collective settlement of production orders in CO88 failed for about 300 orders on day two of the close.”
• Task: clear the errors so CO and FI could report on day four as planned.
• Action:
  1. Pulled the settlement log and grouped the messages. Most orders pointed to a receiver cost centre that had been locked for actual postings after a reorganisation.
  2. Confirmed the correct receivers with the controller rather than guessing, then updated the cost centre master (KS02) and the settlement rules where needed.
  3. Re-ran settlement in test mode, checked results, then ran it live and reconciled work-in-process and variances with the costing team.
  4. Kept the finance controller updated at fixed times so they could plan the rest of the close.
• Result: “Settlement completed within the day and the close finished on schedule.”
• Prevention: added a pre-close checklist step to validate settlement receivers and posting periods (OB52 for FI, MMPV for MM), and proposed moving close tasks into a closing cockpit so dependencies and owners were visible.

Other good examples include GR/IR accounts not clearing, a foreign currency revaluation (FAGL_FCV) producing unexpected results, or depreciation runs failing. The structure is the same: triage, correct root cause, controlled rerun, reconcile, prevent.

Note: Show that you tested the fix before running it live; in closing, a rushed second error is worse than a short delay.

Fit-to-standard sits at the heart of SAP Activate's Explore phase. This question tests facilitation skills and the ability to steer users toward SAP best practices without alienating them.

1. Prepare well. Study the relevant SAP Best Practices scope items (for example BD9, Sell from Stock) and configure a starter or sandbox system with realistic company data such as Indian GST tax codes, local plants and real material names.
2. Set the ground rules. Open by explaining the goal: adopt standard unless there is a genuine business reason not to. Agree that every gap will be recorded and assessed, not rejected in the room.
3. Demonstrate end to end. Walk through the full process, not individual screens. Users often discover that a standard step removes several manual steps from their old system.
4. Ask “why”. When someone says “we need this report exactly as before”, ask what decision it supports. The need often maps to a standard report or Fiori app.
5. Classify gaps. Record each as fit, fit with configuration, or gap, and for gaps note business impact, frequency and options. Park debates rather than letting one topic consume the session.
6. Close the loop. Share the backlog, get the process owner to prioritise it and review decisions in the next workshop.

Example: “The sales team wanted their old order entry screen. After seeing the Fiori sales order app with default values and output automation, they agreed to standard. Out of 42 requested changes, we built only 6.”

Note: Name the process owner as the decision maker; interviewers want to hear that you facilitated the decision rather than imposing it.

Master data problems are among the most common real-world SAP issues. A strong answer quantifies the damage, fixes the data and, most importantly, fixes the process that created it.

• Situation: for example, “Audit found two duplicate payments to the same supplier because it existed under three different BP numbers, created by different plants.”
• Task: recover the money, clean up the duplicates and stop it recurring.
• Action:
  • Ran a duplicate analysis on supplier data using strong keys such as PAN, GSTIN and bank account, and found about 180 likely duplicates.
  • Worked with procurement and accounts payable to agree a surviving record for each case, moved open items and blocked the duplicates for posting and purchasing rather than deleting them.
  • Raised recovery with the supplier for the duplicate payment.
  • Fixed the process: central creation by a master data team, mandatory PAN or GSTIN, a duplicate check at creation and an approval workflow. In larger landscapes this is where SAP Master Data Governance (MDG) fits.
  • Added a monthly data quality report on duplicates and incomplete records.
• Result: “We recovered the payment, reduced the active supplier count by 12 percent and had no duplicate payments in the following year.”

A material master example works just as well, such as a wrong MRP type or lot size in the MRP views causing excess purchase requisitions. The same structure applies: impact, clean-up, root cause, governance.

Note: Stress ownership: master data quality is a business responsibility, and good consultants help set up the ownership model, not just run clean-up scripts.

Hypercare questions check whether you can bring order to chaos. Show a triage system, fast feedback loops and clear exit criteria.

1. Triage by business impact. Define priorities up front: P1 means a critical process is stopped, such as no invoicing, no shipping or no payments; P2 is a workaround available; P3 is a question or cosmetic issue. Fix P1s first, regardless of who shouts loudest.
2. Categorise every ticket. Typical buckets are authorisation (checked with SU53 and fixed in PFCG roles), training or “how do I” questions, data errors, configuration defects, interface failures and performance. The bucket often reveals a pattern, for example 30 percent of tickets being missing authorisations.
3. Fix patterns, not just tickets. One role correction can close fifty tickets. Publish short job aids and FAQs for recurring questions, and use key users as first-line support on the floor.
4. Monitor proactively. Check failed IDocs (WE02, reprocess in BD87), short dumps (ST22), failed background jobs (SM37) and business KPIs such as orders created and invoices posted, so you spot issues before users report them.
5. Run a daily war room. Review open P1 and P2 items, owners and ETAs, and share a simple status note with leadership.
6. Agree exit criteria. For example, no open P1 for two weeks and ticket volume below an agreed level before handing over to the support team.

Example: “We received 600 tickets in the first two weeks. Grouping them showed 40 percent were access issues from three roles. After fixing those roles and running two refresher sessions, daily tickets fell from 90 to 15 within ten days.”

Note: Always mention how you communicated; users tolerate early problems when they can see issues being handled.

Interviewers ask this to test honesty and ownership. Pick a real but recoverable incident, own your part clearly and focus on what you learned.

• Situation: for example, “I moved a pricing procedure change for a new discount condition. Next morning, intercompany billing documents started failing with pricing errors.”
• Immediate response:
  • Acknowledged it straight away with the support lead instead of waiting to be sure it was my change.
  • Confirmed the cause from the billing error log and the transport log in STMS: a dependent condition table and access sequence sat in a separate transport that had not been imported.
  • Agreed with the change board to fix forward by importing the missing transport, since SAP transports cannot simply be undone; a reversal would itself need a new corrective transport.
  • Reprocessed the failed billing documents and confirmed with finance that postings were correct.
• Root cause: transports were released separately and the quality system test had not covered intercompany billing.
• Changes afterwards:
  • Grouped related objects into one transport or defined an explicit import sequence.
  • Added intercompany and other cross-company scenarios to the regression test pack.
  • Used change management tooling (such as ChaRM in Solution Manager or SAP Cloud ALM) to track dependencies, plus peer review before release.
• Result: “Billing was restored within three hours and we had no sequencing incidents after that.”

Note: Avoid stories where someone else is to blame; the strongest answers show calm ownership, a quick fix and a process improvement that protects the whole team.

SAP's strength is integration, so cross-module problems are common. This question tests whether you look at the end-to-end process and collaborate rather than defend your own module.

1. Describe the symptom and impact. For example, “After a new product line went live, billing documents were created but not released to accounting, so revenue and receivables were understated and customers were not invoiced on time.”
2. Trace the document flow. Use the sales order document flow (VA03) and the billing document (VF03) to see where the chain breaks. The accounting status and error message pointed to revenue account determination.
3. Bring the right people together. The SD consultant owned the new material account assignment group, while the FI consultant owned revenue account determination in VKOA. Neither had the full picture alone.
4. Fix and recover. Added the missing VKOA entries, tested in quality with a full order-to-cash cycle, then released the blocked billing documents to accounting using VFX3 and reconciled with finance.
5. Prevent a repeat. Added an end-to-end integration test script for every new product line or sales organisation, and a checklist of cross-module settings (account determination, profit centre derivation, tax codes) for the change team.

Example result: “About 1,200 invoices worth roughly ₹4 crore were released within a day, and we had no similar issue in later product launches.”

Other good stories include MM movement types posting to the wrong G/L accounts because of OBYC settings, or a new plant missing its profit centre assignment.

Note: Highlight the collaboration: a shared root-cause session between module teams is often the real turning point in these stories.

This is a technical troubleshooting story for ABAP developers and technical consultants. Show that you measured before changing code and that you understood why the fix worked.

1. Reproduce and measure. Get the exact selection criteria and runtime from users, then run the program with the runtime analysis tool (SAT) and an SQL trace (ST05). These show whether time goes into database access or ABAP processing.
2. Look for classic causes:
   • SELECT statements inside a LOOP, causing thousands of database round trips.
   • SELECT * or selections that do not use the primary key or an index.
   • Nested loops on large standard internal tables, which grow quadratically.
   • FOR ALL ENTRIES with an empty driver table, which selects every row in the table.
3. Fix the design. Replace repeated selects with a single join or a CDS view so HANA does the work (code pushdown), read only needed fields, use sorted or hashed internal tables for lookups, and move heavy runs to background jobs, with parallel processing if necessary.
4. Verify. Compare output with the old version for several selections and compare runtime in the quality system with production-like data volume.
5. Prevent a repeat. Add ABAP Test Cockpit (ATC) performance checks to code review.

Example: “A stock ageing report took 45 minutes and often timed out in dialog mode. ST05 showed 200,000 single selects on MSEG inside a loop. I replaced them with one join on the S/4HANA material document data, used a hashed table for material lookups, and the runtime dropped to under three minutes.”

Note: Name the tools you used; SAT and ST05 in an answer immediately signal hands-on experience.

Audit questions test integrity and structured remediation. Show that you took the finding seriously, separated real risks from noise and fixed the design rather than just removing access in a panic.

• Situation: for example, “The statutory auditor flagged that 25 users could both create or change suppliers and run the payment program, a classic procure-to-pay SoD conflict.”
• Analyse properly. Get the rule set used, rerun the analysis with SAP GRC Access Control (Access Risk Analysis) or SUIM reports, and check each conflict at the transaction and authorisation-object level. Some “conflicts” are display-only access and are false positives.
• Remediate by design.
  • Split roles in PFCG so supplier maintenance (BP in the supplier role) and payment execution (F110) sit in different roles held by different people.
  • Remove unused access, using usage data to show what people actually run.
  • Where a small team cannot split duties, define a documented mitigating control, such as a monthly review of supplier bank changes signed off by a manager.
  • Use firefighter or emergency access IDs, with logging and review, for rare urgent needs.
• Agree timelines. Share a remediation plan with the auditor and process owners, and track it to closure.
• Prevent recurrence. Add SoD checks before any new access is provisioned and run quarterly user access reviews with business owners.
• Result: “Real conflicts fell from 25 users to 2, both covered by mitigating controls, and the point was closed in the next audit cycle.”

Note: Stay non-defensive in the story; saying you thanked the auditor and used the finding to improve role design comes across well.

The integrated computer-based system known as ERP, or enterprise resource planning software, is used to efficiently manage a company's resources. It handles workflows and ensures efficient information flow across diverse departments in an organization or firm.

ERP has the following variants:

• SAP
• JD Edwards, (now acquired by Oracle)
• Baan
• PeopleSoft (now acquired by Oracle)
• Siebel
• Windows Dynamics

Following are the various SAP modules:

• FI (Financial Accounting)
• CO(Controlling)
• EC (Enterprise Controlling)
• TR(Treasury)
• IM (Investment Management)
• HR (Human Resource)
• SD (Sales and Distribution)
• MM (Materials Management)
• PM (Plant Maintenance)
• PP (Production Planning)

Meta Data: Metadata is facts about other data. It provides information on the data or MetaObjects' structure.

Master Data: This Data is key business information like Customer information, Employee, Materials, etc. This is more like reference data for

Transaction Data: This is data related to day-to-day transactions.

NetWeaver, known as SAP Web Application Server, can run all of the mySAP suite's products because NetWeaver is an integrated technology platform (SAP WEBAs).

NO. Although SAP is an application, it uses databases that are offered by other vendors, like Oracle, SQL Server, and others.

You can only work on a maximum of six sessions for one client at a time.

A transaction in the context of SAP is a set of logically related dialogue stages.

A dataset is a simple collection of data, usually presented in a table. The application server processes the data sets in sequential order. In SAP, they are used for file handling.

Although it's a pretty multi-functional software, it does have the following setbacks:

• It can be highly expensive
• It is a complex software and requires highly trained staff to operate it
• It takes a long time to implement it.
• Its interface can be quite complex.
• New versions are rolled out quite frequently. Therefore, a trained professional is generally needed to maintain the software.

Domain: It specifies and defines attributes. Examples of these are length, type, and possible value range.

Data Element: It acts as an intermediate object between domain and table type.

The baseline date is usually the date from which the payment terms apply. It usually acts as the basis for determining the permitted cash discount or if the invoice is due. Usually, it is the document date on the invoice but can also be the date of entry or the posting date from the ledger.

Following are the standard stages of payment run in SAP:

• Entering of parameters- Includes entering vital information like company codes, vendor accounts, payment methods, etc.
• Proposal scheduling- A proposal is sent for the invoices to be paid.
• Payment booking- Booking of the actual payments into the ledger.
• Printing of payment forms- The last stage of the payment run is where you schedule the printing of the payment forms.

SAP ABAP is the programming language used to customize, generate forms, and generate reports within SAP. SAP basis is the administration module of SAP that controls code changes, upgrades, database administration, and network configuration.

Systems Applications and Products in Data Processing is the abbreviation for SAP. It is a German company that was established in 1972 by Wellenreuther, Hopp, Hector, Plattner, and Tschira

SAP is the name of the company, as well as its ERP product.

SAP is the market leader in ERP. SAP had more than 140,000 installations worldwide as of 2010, more than 25 industry-specific business solutions, and more than 75,000 clients in 120 nations.

Variables are parameters of a query set in the parameter query definition and are not filled with values until the queries are entered into the workbooks.

There are three phases of data mining

• Initial investigation
• Model building
• Deployment

Data Component: It is a bridge between a domain and a table type.

Domain: It specifies characteristics like length, type, and potential value range

A period of time called LUW is used to describe when database records are modified, either by commit or rollback.



The TCP/IP protocol is used by the SAP gateway process to communicate with the clients.

SAP S/4HANA is SAP's current-generation ERP. It is not simply ECC on a faster database: the data model, user experience and several processes were rebuilt around SAP HANA.

Other changes worth mentioning:

• New Asset Accounting is mandatory, and the Material Ledger is always active for inventory valuation.
• SD credit management is replaced by SAP Credit Management (FIN-FSCM).
• Output management can use a new BRF+ based framework.
• Many aggregates are no longer stored because HANA calculates totals on the fly.

Also explain why it matters commercially. SAP's mainstream maintenance for ECC ends in 2027, with optional extended maintenance to 2030, so most SAP customers are converting or planning to. S/4HANA is available on-premise and as S/4HANA Cloud Private Edition or Public Edition.

Note: For module-specific follow-ups, refer to the SAP Simplification List for your target release, which documents every functional and technical change.

The enterprise structure defines how a business is modelled in SAP. It is configured under Enterprise Structure in SPRO (Definition, then Assignment) and is very hard to change after go-live, so it is designed early in the Explore phase.

• Client: the highest level, a self-contained unit within an SAP system with its own master and transaction data. Settings can be client-independent (for example ABAP programs) or client-specific (most configuration).
• Company code: the smallest unit for which a complete set of legal financial statements is produced. Each company code has a currency, chart of accounts and fiscal year variant; an Indian company typically uses V3 (April to March).
• Controlling area: the unit for management accounting. One controlling area can cover several company codes (set up in OKKP).
• Plant: an operational location such as a factory, warehouse or branch where materials are produced, stored or distributed. Defined in OX10 and assigned to exactly one company code in OX18.
• Storage location: a subdivision of a plant where stock is physically kept, for example raw material store or finished goods store.
• Purchasing organisation: negotiates conditions with suppliers. It can be plant-specific, company-specific or cross-company (central procurement) depending on assignment.
• Sales organisation: responsible for selling and for liability to customers; assigned to one company code. Combined with a distribution channel and division, it forms a sales area, which controls pricing, partners and reporting.
• Shipping point: the location that processes outbound deliveries, assigned to plants.

A simple example: company code 1000 (India entity) with plants in Pune and Chennai, each with raw material and finished goods storage locations, one central purchasing organisation and a sales organisation for domestic sales.

Note: Interviewers often ask which unit is the “legal” one (company code) and which is the “operational” one (plant); keep that distinction crisp.

Procure-to-pay (P2P) links MM with FI. A strong answer names each step, the transaction and the accounting impact.

1. Purchase requisition (ME51N): an internal request for materials or services, created manually or automatically by MRP. No accounting entry.
2. Source determination: the system proposes a supplier using purchasing info records (ME11), source lists (ME01) or outline agreements. For new items, buyers may send requests for quotation (ME41), enter quotations (ME47) and compare prices (ME49).
3. Purchase order (ME21N): the legal document sent to the supplier. A release strategy can require approval, done in ME29N or collectively in ME28. Still no accounting entry, though commitments can be recorded in CO.
4. Goods receipt (MIGO, movement type 101): stock increases and an accounting document is posted: debit inventory, credit the GR/IR clearing account. For consumables with account assignment, the debit goes to the cost centre or order.
5. Invoice verification (MIRO): the supplier invoice is matched with the PO and goods receipt (three-way match). Posting debits GR/IR, credits the supplier account and posts tax, such as input GST in India. Price differences go to the stock account or a price difference account depending on price control.
6. Payment (F110 automatic payment program, or F-53 for a manual payment): clears the supplier's open item against the bank.

Useful supporting transactions: ME2N (POs by number), ME23N (display PO), MB52 (warehouse stock), MR11 (maintain GR/IR clearing account) and F.13 (automatic clearing).

Also mention that the GR/IR account is a key month-end control: open balances show goods received but not invoiced, or invoiced but not received.

Note: If you are asked about services, mention service entry sheets (ML81N in classic MM, or the Fiori service entry sheet apps in S/4HANA).

Order-to-cash (O2C) spans SD, logistics execution and FI. Each step creates a document linked to the previous one, visible in the document flow.

1. Pre-sales (optional): inquiry (VA11) and quotation (VA21).
2. Sales order (VA01): captures customer, material, quantity, price and delivery date. Key functions run here: pricing through the condition technique (condition types, access sequences, pricing procedure), availability check (ATP), credit check and determination of shipping point and route.
3. Outbound delivery (VL01N, or VL10 for collective processing): created from the order when goods are due to ship.
4. Picking and packing: performed in the delivery or through warehouse management or EWM.
5. Post goods issue (VL02N): reduces stock with movement type 601 and posts debit cost of goods sold, credit inventory. Ownership passes to the customer.
6. Billing (VF01, or VF04 for the billing due list): creates the invoice. The accounting document debits the customer and credits revenue and output tax, such as output GST in India. Revenue G/L accounts are determined through VKOA.
7. Incoming payment (F-28): clears the customer's open item against the bank account.

Display transactions such as VA03 (sales order) and VF03 (billing document) show the full document flow, which is the fastest way to trace where a process stopped.

Variants worth knowing: returns (return order, return delivery, credit memo), third-party orders where the supplier ships directly, and consignment. If a billing document does not reach accounting, it can be released with VFX3 once the cause is fixed.

Note: Linking each SD step to its FI posting is what separates a strong answer from a list of transaction codes.

In S/4HANA, the Business Partner (BP) is the single, mandatory entry point for maintaining customers and suppliers, using transaction BP or Fiori apps. The older XD01 and XK01 style transactions redirect to BP.

• General data such as name, address, tax numbers and bank details is stored once per business partner (table BUT000 and related tables).
• BP roles add the context-specific data. Common roles: FLCU00 (FI customer, company code data), FLCU01 (customer, sales area data), FLVN00 (FI supplier) and FLVN01 (supplier, purchasing data).
• Groupings control number ranges, similar to the old account groups.
• Relationships link partners, for example a contact person to an organisation.

Customer-Vendor Integration (CVI) keeps the BP synchronised with the classic customer and vendor tables (KNA1, KNB1, KNVV and LFA1, LFB1, LFM1). This matters because many SD, MM and FI programs still read those tables. When you create a BP with a customer role, CVI creates or updates the customer record automatically.

For a brownfield conversion from ECC, CVI is a mandatory preparation step: every existing customer and vendor must be converted to a BP before the technical conversion. Typical activities:

1. Clean data first: remove obsolete records and fix missing mandatory fields, addresses and tax numbers.
2. Map account groups to BP groupings and align number ranges, often keeping the same numbers.
3. Run the synchronisation using the synchronisation cockpit (MDS_LOAD_COCKPIT) and resolve errors.

Benefits include one address and bank record for a party that is both customer and supplier, consistent data across modules and a modern data model for Fiori and integration.

Note: CVI conversion errors are one of the most common delays in S/4HANA brownfield projects, so start data cleansing early.

FI (Financial Accounting) covers external, legal reporting; CO (Controlling) covers internal management accounting such as cost centres, orders, product costing and profitability. In S/4HANA they share one data model.

• Universal Journal: FI and CO postings are stored in one line-item table, ACDOCA. A single document carries the G/L account, company code, cost centre, profit centre, segment and other dimensions, so FI and CO are reconciled by design and the old reconciliation ledger is no longer needed.
• Cost elements are G/L accounts: in ECC they were separate master records (KA01, KA06). In S/4HANA they are maintained in the G/L account master (FS00) by choosing the G/L account type “primary costs or revenue” or “secondary costs” and a cost element category.
• Controlling area: the company codes whose costs are managed together are assigned to a controlling area (OKKP).

Primary cost elements represent costs that come from outside the company and are posted through FI, for example salaries, electricity or raw material consumption. Category 1 is used for primary costs, and 11 for revenues.

Secondary cost elements exist only inside CO and are used to move costs between CO objects. Common categories are 21 (internal settlement), 41 (overhead rates), 42 (assessment) and 43 (internal activity allocation).

Example flow:

1. An electricity invoice is posted in FB60 to a utilities G/L account with the maintenance cost centre. This is a primary cost, visible in FI and on the cost centre.
2. At month-end, an assessment cycle (run in KSU5) allocates maintenance costs to production cost centres using a secondary cost element of category 42.
3. Production cost centres charge activities to production orders, which are later settled to inventory or variances.

Note: A common trap: a primary cost posting in FI fails if the account is a cost element and no CO object is given, unless a default account assignment (OKB9) is set.

Both are Controlling objects used for internal reporting, but they answer different questions: a cost centre asks “what did this area cost?”, while a profit centre asks “how much profit did this area make?”.

How they work together: every cost centre is assigned to a profit centre in its master record, so any cost posted to a cost centre automatically carries a profit centre. Materials carry a profit centre in the material master, so logistics postings such as goods issues and billing also derive one. Profit centres roll up to segments for segment reporting.

Design principles:

• Start from management reporting needs: ask how leaders want to see costs and profits.
• Cost centres should follow areas of responsibility, where one person can be held accountable.
• Profit centres should represent units whose profitability is actually measured and discussed. Too many creates noise and allocation effort; too few hides performance.
• Both require a standard hierarchy that contains every master record. The cost centre standard hierarchy is maintained in OKEON.
• Use validity dates and avoid reusing numbers for different meanings, because history remains attached to the object.

Example: a retail company might create cost centres for store operations, marketing and head office IT, and profit centres for each region, such as North and South, so regional P&L can be reported directly from the Universal Journal.

Note: If a question mentions balance sheet reporting by profit centre, bring up document splitting in the new G/L, which is required for it.

SAP PP (Production Planning) turns demand into planned supply and then into executed production. The discrete manufacturing flow is the one interviewers usually expect.

1. Master data: material master with MRP and work scheduling views, bill of materials (CS01), work centres (CR01), routing (CA01) and production version (C223), which links a BOM with a routing and is effectively required in S/4HANA.
2. Demand: planned independent requirements from forecasts or sales plans (MD61) and customer requirements from sales orders.
3. MRP: in S/4HANA, MRP Live (MD01N) runs on HANA. It nets demand against stock and open supply, explodes the BOM and creates planned orders for in-house production and purchase requisitions for bought-in parts. Results are reviewed in the stock/requirements list (MD04).
4. Conversion: planned orders are converted into production orders (CO40 individually, CO41 collectively), or production orders are created directly in CO01.
5. Release: the order is released (in CO02 or automatically), which allows goods movements and confirmations. Availability of components is checked.
6. Goods issue of components: MIGO with movement type 261, or automatically through backflushing at confirmation.
7. Confirmation (CO11N): records yield, scrap and activities such as machine and labour time. This posts activity costs to the order.
8. Goods receipt of the finished product: MIGO with movement type 101 against the order, or automatically with the final confirmation.
9. Period-end: variance calculation (KKS2) and settlement (KO88 for one order, CO88 collectively) move the order balance to inventory or price differences. The order is then technically completed.

Process industries use process orders (COR1) with master recipes instead of routings, and high-volume production may use repetitive manufacturing.

Note: Linking each PP step to its costing impact, such as activity postings on confirmation and settlement at period-end, shows real integration understanding.

The material master is the central record for everything a company buys, makes, stores or sells. Its data is split into views, and each view is stored at a specific organisational level, so the same material can have different settings per plant or sales area.

Other views include Classification, Plant/Storage data, Quality Management and Warehouse Management.

Material type (for example ROH raw material, HALB semi-finished, FERT finished product, HAWA trading goods) controls which views are allowed, the number range and whether quantity and value are updated. The valuation class in the Accounting view drives automatic account determination, and price control (S for standard price, V for moving average price) determines how inventory is valued.

Key transactions: MM01 (create), MM02 (change), MM03 (display), MM60 (material list), MMSC (extend to storage locations) and MM17 (mass maintenance).

Note: Many errors in MM and SD, such as a material “not maintained for plant”, simply mean a view was not extended to that organisational level.

A Fiori app is a web application built in layers. Knowing each layer helps you explain the design and troubleshoot problems.

1. Fiori Launchpad (FLP): the browser-based entry point, opened in the backend with /UI2/FLP. Apps appear as tiles grouped into spaces and pages. Tiles and target mappings come from business catalogues, which are assigned to users through PFCG roles. Launchpad content is maintained with tools such as the Launchpad Designer (/UI2/FLPD_CUST) or the newer content manager.
2. UI layer (SAPUI5): the app's front end is written in SAPUI5, SAP's JavaScript framework. Apps are either freestyle (fully custom UI code) or built with SAP Fiori elements, which generate standard floorplans such as List Report, Object Page, Analytical List Page, Overview Page and Worklist from metadata and annotations.
3. OData service: the UI talks to the back end through OData (V2 or V4) services exposed by SAP Gateway. Classic services are built in the Service Builder (SEGW) and activated in /IWFND/MAINT_SERVICE. Gateway can be deployed embedded in S/4HANA or on a separate hub.
4. Back-end logic and data: in S/4HANA, modern services are defined with ABAP CDS views and the ABAP RESTful Application Programming Model (RAP), where behaviour definitions handle create, update and actions, and UI annotations drive Fiori elements.

To find standard apps, use the SAP Fiori Apps Reference Library. It lists each app's required business catalogue, role, OData service and supported releases.

Troubleshooting tips: tile missing usually means a role or catalogue assignment issue; “service not found” means the OData service is not activated; data errors can be investigated in /IWFND/ERROR_LOG and the browser developer tools.

Note: Prefer Fiori elements over freestyle for standard CRUD and list scenarios; it is faster to build and stays consistent with SAP's design guidelines.

SAP HANA is an in-memory, column-oriented database that also acts as an application platform. Its speed comes from several design choices working together.

• In-memory data: the working data set is held in RAM, so reads avoid slow disk access.
• Columnar storage: each column is stored contiguously. Analytical queries read only the columns they need, and scanning one column is very cache-friendly for modern CPUs.
• Compression: columns use dictionary encoding, where each distinct value is stored once and rows hold small integer references. Repetitive business data such as plant, currency or status compresses heavily, which means more data fits in memory and less has to be scanned.
• Parallel processing: operations are split across many cores and use vectorised (SIMD) instructions.
• Code pushdown: calculations run inside the database through SQL, CDS views or calculation views instead of pulling rows into the application server. This is why S/4HANA could remove many totals tables and calculate aggregates on the fly.

How writes work: compressed, sorted columns are expensive to modify, so each column table has two parts:

1. The main store, which is read-optimised and highly compressed.
2. The delta store, which is write-optimised. New inserts and updates go here first, and queries read main plus delta together.

Periodically, a delta merge (usually triggered automatically) builds a new main store that includes the delta changes, then clears the delta. Small, frequently updated tables can use the row store instead.

Durability: although data lives in memory, HANA writes redo logs for every committed transaction and takes regular savepoints (every five minutes by default) to disk. After a restart, it loads the last savepoint and replays the logs. High availability and disaster recovery are usually provided by HANA System Replication.

Note: If asked about a slow HANA table, mention checking whether the delta store has grown very large because merges are not happening.

Core Data Services (CDS) views are data models defined in source code on top of database tables or other views. They add business meaning through annotations, associations and access control, and they execute in SAP HANA, which pushes processing down to the database.

@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: 'Open sales orders'
define view entity ZI_OpenSalesOrder
  as select from I_SalesOrder as SO
  association [0..1] to I_Customer as _Customer
    on SO.SoldToParty = _Customer.Customer
{
  key SO.SalesOrder,
      SO.SalesOrderType,
      SO.SoldToParty,
      _Customer
}
where SO.OverallSDProcessStatus <> 'C'

Why they matter in S/4HANA:

• Virtual Data Model (VDM): SAP delivers thousands of CDS views in layers: basic and interface views (prefix I_), composite views, and consumption views (C_) built for specific apps or reports. Standard Fiori apps and embedded analytics run on them.
• Annotations drive behaviour: @Analytics for analytical queries, @UI for Fiori elements layouts, @Semantics for amounts, currencies and units.
• Associations define relationships that are joined only when used, which keeps queries lean.
• Access control is defined in a separate DCL role (define role), so authorisation checks apply automatically when the view is read.
• RAP: in the ABAP RESTful Application Programming Model, CDS views form the data model for transactional apps and OData services.

Practical points: CDS views are developed in ABAP Development Tools for Eclipse, not in SE11. Since ABAP 7.55, CDS view entities (define view entity) are the recommended form and replace the older DDIC-based views that needed an SQL view name. For a clean core, build on SAP's released CDS views, which are stable across upgrades, rather than reading tables directly.

Note: Understanding the I_ and C_ layers and knowing how to find released views is a strong signal in S/4HANA developer interviews.

SAP provides several ways to add custom logic to standard programs without modifying SAP code. From oldest to newest:

• User exits: empty form routines in SAP includes, mainly in SD, for example USEREXIT_SAVE_DOCUMENT_PREPARE in include MV45AFZZ for sales orders. Technically these are modifications of SAP objects, so they need object registration and extra care at upgrades.
• Customer exits: predefined hooks managed with SMOD (view the enhancement) and CMOD (create a project and activate it). Types include function exits (called with CALL CUSTOMER-FUNCTION), screen exits and menu exits.
• Classic BAdIs: object-oriented exits defined in SE18 and implemented in SE19. They support multiple implementations and filters, for example by country.
• New (kernel) BAdIs: part of the Enhancement Framework, organised in enhancement spots and called with GET BADI and CALL BADI. They are faster than classic BAdIs and are SAP's preferred mechanism.
• Enhancement points and sections: implicit enhancement points exist automatically at places such as the start and end of every form, function module and method. Explicit points and sections are placed by SAP in the code. They allow code to be inserted without a modification key, but they are tightly coupled to SAP code and should be used sparingly.
• Business Transaction Events (BTEs): FI-specific hooks managed in FIBF.

In S/4HANA, SAP adds a clearer extensibility model aligned with the clean core approach:

• Key user extensibility through Fiori apps for custom fields and custom logic.
• Developer extensibility using ABAP Cloud, restricted to released APIs and released BAdIs.
• Side-by-side extensions on SAP BTP that talk to S/4HANA through APIs and events.

Good practice is to prefer configuration, then key user or released extension points, and to treat modifications as a last resort.

Note: To find a classic BAdI in a transaction, a common trick is setting a breakpoint in CL_EXITHANDLER=>GET_INSTANCE; for new BAdIs, search the code for GET BADI.

An internal table is a dynamic, in-memory array of rows with the same structure, used to hold and process data read from the database during a program run.

TYPES: BEGIN OF ty_stock,
         matnr TYPE matnr,
         werks TYPE werks_d,
         lgort TYPE lgort_d,
         labst TYPE labst,
       END OF ty_stock.

DATA lt_stock TYPE SORTED TABLE OF ty_stock
              WITH NON-UNIQUE KEY matnr werks.

SELECT matnr, werks, lgort, labst
  FROM mard
  WHERE werks = @lv_plant
  INTO TABLE @lt_stock.

LOOP AT lt_stock INTO DATA(ls_stock) WHERE matnr = lv_matnr.
  " optimised: uses the sorted key, no full scan
ENDLOOP.

Good practices interviewers look for:

• Choose the table type by access pattern: nested loops on large standard tables are a classic performance problem.
• Use modern syntax: inline declarations (DATA(...)), constructor expressions (VALUE #( )) and table expressions such as lt_stock[ matnr = lv_matnr werks = lv_plant ], which raise CX_SY_ITAB_LINE_NOT_FOUND if no row exists.
• Secondary keys let one table support several fast access paths.
• Avoid SELECT inside loops; read in one go with joins or FOR ALL ENTRIES, and always check that the driver table is not empty before FOR ALL ENTRIES, otherwise every row is selected.
• Use field symbols or references when changing rows in large loops to avoid copying.

Note: A quick rule: hashed for lookups by full key, sorted for partial-key or range access, standard for everything small or sequential.

Integration choices depend on whether the exchange must be synchronous, how much data moves, what the partner system supports and how errors should be handled.

Middleware: most landscapes route integrations through a platform rather than point-to-point. SAP's current offering is SAP Integration Suite on BTP (Cloud Integration, API Management, prebuilt integration packages); many on-premise landscapes still run SAP Process Orchestration. Non-SAP middleware such as MuleSoft or Boomi is also common.

Useful transactions: WE20 (partner profiles), WE21 (ports), WE02 or WE05 (IDoc monitoring), BD87 (reprocess IDocs), SM59 (RFC destinations), /IWFND/MAINT_SERVICE (activate OData services).

How to choose:

• Need an immediate answer, such as a price or availability check? Use OData or RFC.
• High-volume business documents that must not be lost? Use IDocs or asynchronous messaging with retries.
• Cloud applications and clean core? Use SAP's released APIs, listed on the SAP Business Accelerator Hub, and events.

Note: Always mention monitoring and error handling; an integration design without a reprocessing plan is incomplete.

SAP Activate is SAP's implementation framework for S/4HANA and cloud solutions. It combines three elements: SAP Best Practices (pre-configured, documented business processes called scope items), guided configuration tools, and an agile-friendly methodology. Each phase ends with a quality gate.

1. Discover: understand the value of the solution, explore trial systems and build a business case and high-level roadmap.
2. Prepare: set up the project: scope, governance, team, plan and standards. Provision the starter or sandbox system and plan data migration and testing strategies.
3. Explore: run fit-to-standard workshops, where SAP Best Practices processes are demonstrated and compared with business needs. Gaps and required settings are captured in a backlog, and designs for WRICEF objects (workflows, reports, interfaces, conversions, enhancements, forms) are prepared.
4. Realize: configure and build in short sprints, with regular show-and-tell reviews. Run unit, integration and user acceptance testing, and perform mock data migration loads.
5. Deploy: final preparation for go-live: end-user training, cutover rehearsals, production data load, go/no-go decision, go-live and hypercare support.
6. Run: operate and continuously improve the solution, adopt new innovations and plan upgrades.

Difference from ASAP: ASAP (Project Preparation, Business Blueprint, Realization, Final Preparation, Go-Live and Support) was largely waterfall. The blueprint phase documented requirements, often starting from a blank sheet, before building. SAP Activate starts from working best-practice processes in a system (fit-to-standard rather than fit-gap from scratch), encourages iterative delivery and standard adoption, and is designed for both cloud and on-premise deployments.

The methodology, with task lists and accelerators by product and deployment type, is published in SAP's Roadmap Viewer.

Note: In interviews, link a phase to your own role, for example “In Explore I ran P2P fit-to-standard workshops, and in Realize I configured release strategies and supported SIT.”

These are the three main transition paths from SAP ECC to S/4HANA. The choice shapes the whole programme, so interviewers expect you to explain the trade-offs, not just the definitions.

Greenfield typically uses the SAP S/4HANA Migration Cockpit (the Migrate Your Data app) to load data. It offers the cleanest system and fastest adoption of new functionality, but requires the most business change and training.

Brownfield follows a defined path:

1. Run the SAP Readiness Check to see impacted simplification items, add-ons and custom code.
2. Run the Simplification Item Check (report /SDF/RC_START_CHECK) and resolve blocking items.
3. Complete prerequisites such as Customer-Vendor Integration for business partners.
4. Adapt custom code using ABAP Test Cockpit (ATC) checks for S/4HANA readiness and remove unused code.
5. Run the technical conversion with the Software Update Manager (SUM), using the Database Migration Option (DMO) if the source database is not HANA.
6. Complete finance data migration and post-conversion steps.

Selective data transition is usually delivered with specialist tools and services, such as SAP's Data Management and Landscape Transformation offerings or partner tools. It offers flexibility but adds project complexity.

How to decide: consider the fit of current processes, the amount of custom code, the need for history, the number of systems to consolidate, timelines and budget.

Note: Avoid calling brownfield “just a technical upgrade”; finance, business partner and custom code changes make it a full project.

SAP HCM is SAP's classic on-premise HR system, while SAP SuccessFactors is its cloud human capital management suite and the strategic direction for HR.

SuccessFactors modules: Employee Central (core HR system of record), Employee Central Payroll, Recruiting, Onboarding, Performance and Goals, Compensation, Succession and Development, and Learning. Companies can adopt talent modules first while keeping core HR on-premise, which is known as a talent hybrid model, or move core HR to Employee Central and keep payroll on-premise (core hybrid).

Integration with S/4HANA:

• Organisational data such as cost centres flows from S/4HANA to Employee Central, so employees are assigned to valid cost objects.
• Employee data flows from Employee Central to S/4HANA, where it is needed for processes such as travel expenses, time recording, project staffing and payroll postings.
• SAP provides prebuilt integration packages that run on SAP Integration Suite, which reduces custom integration work.
• Payroll results post to finance in S/4HANA for G/L and cost centre accounting.

Roadmap context: SAP's strategic HR solution is SuccessFactors. Mainstream maintenance for SAP HCM on ECC ends in 2027, while the on-premise “SAP HCM for SAP S/4HANA” option is supported until 2040 for customers who are not ready to move to the cloud.

Note: For HR roles, mention Indian payroll specifics such as PF, ESI, professional tax and TDS when discussing payroll; it shows practical local awareness.

Clean core means keeping the ERP system as close to SAP standard as possible and extending it only through stable, upgrade-safe interfaces. The goal is that upgrades and innovations can be adopted quickly because custom code does not break when SAP changes its internals.

Deployment options for S/4HANA:

• On-premise: customer-managed, full functional scope and full freedom to modify, which also means full responsibility for upgrades.
• S/4HANA Cloud Private Edition: a single-tenant system run by SAP (or a hyperscaler on SAP's behalf), with near on-premise scope and flexibility. It is the core of the RISE with SAP offering, which bundles the software subscription, infrastructure, technical operations and tools such as SAP BTP credits and process-insight tools into one contract.
• S/4HANA Cloud Public Edition: multi-tenant software as a service with standard best-practice processes and regular upgrades delivered by SAP. Only released extension options are allowed, so clean core is enforced. Midsize companies often buy it through GROW with SAP.

How to keep the core clean:

1. Adopt standard processes through fit-to-standard, and challenge every custom request.
2. Use key user extensibility for custom fields, logic and forms.
3. Use developer extensibility (ABAP Cloud), which allows only released APIs, CDS views and BAdIs.
4. Build larger or separate apps side by side on SAP BTP, connected through released APIs and events.
5. Integrate with released APIs from the SAP Business Accelerator Hub instead of reading or writing tables directly.
6. For existing custom code, measure usage (for example with the ABAP call monitor, SCMON), retire what is unused, and use ATC checks to move the rest towards released interfaces.

Clean core also covers data quality, standard integration and disciplined operations, not only code.

Note: Interviewers often ask how you would handle a requirement that standard cannot meet; a good answer walks through the extension options in the order above.

Every inventory-related goods movement or invoice must post to the right G/L accounts without the user entering them. MM automatic account determination does this using a chain of settings maintained in OBYC.

1. Movement type (for example 101 goods receipt, 201 issue to cost centre, 261 issue to production order) points to a value string.
2. The value string lists the transaction or event keys that the movement posts to.
3. For each key, the system finds the G/L account using the chart of accounts, the valuation grouping code (which groups valuation areas with the same settings), the account modifier (for some keys) and the valuation class from the material master Accounting view.

Common transaction keys:

• BSX: inventory (stock) account.
• WRX: GR/IR clearing account.
• GBB: offsetting entry for inventory postings, split by account modifier, for example VBR for consumption, VAX and VAY for cost of goods sold, and BSA for initial stock entry.
• PRD: price differences, used mainly for materials with standard price.
• KDM: exchange rate differences.
• UMB: revaluation gains and losses.

Examples:

• Goods receipt for a purchase order (101): debit BSX inventory, credit WRX GR/IR.
• Invoice receipt (MIRO): debit WRX GR/IR, credit the supplier's reconciliation account; any difference against a standard price goes to PRD.
• Goods issue to a cost centre (201): debit GBB with modifier VBR (consumption), credit BSX.

The valuation class must be allowed for the material type (configured in OMSK). Account determination can be checked with the simulation in OMWB before posting. SD has a similar concept for revenue accounts in VKOA.

Note: A typical interview follow-up is “why did this goods receipt post to the wrong account?”; answer by walking the chain from movement type to valuation class.