SAP MM / P2P Purchase Requisition Interview Questions

Purchase Requisition comes up in SAP MM / P2P interviews because it is one of the few areas where an interviewer can tell, in two questions, whether you have worked with the process or only read about it.

This page carries 8 reviewed SAP MM / P2P purchase requisition interview questions, each with a complete written answer and no sign-in required. The set breaks down into 1 foundational, 5 mid-level and 2 advanced questions, so you can start at the top for a first interview or skip ahead to the scenario-based items for a senior round.

The fastest way to use this page is to read the question, answer it yourself, and only then read the answer. The gap between your version and the written one is your actual revision list for purchase requisition.

8 Purchase Requisition questions with answers

easyPurchase Requisition

1. What is the purpose of purchase requisition document types in SAP MM, and how do they influence downstream processing?

Purchase requisition document types (e.g., NB, standard PR types) control number ranges, field selection, release strategy applicability, and permitted item categories. They determine whether a PR can be converted automatically to a PO or RFQ, restrict which document types can follow, and can be configured differently for stock vs. service requisitions, enabling business-specific approval and sourcing rules.
mediumPurchase Requisition

2. During hypercare of an Ariba integration project, sales order-driven procurement (third-party/drop-ship) records migrated from ECC are creating mismatched Ariba requisitions because SD-linked purchase requisition migration objects didn't carry over the sales order reference correctly. How do you troubleshoot this?

Check whether the migration object for purchase requisitions/third-party sales order items correctly mapped the SD document/item reference fields during load, since a broken link causes Ariba to treat the requisition as unrelated to the original sales order. Validate account assignment category 'C' (third-party) records specifically, as these carry SD linkage fields that standard PR migration templates sometimes omit. Reconcile a sample set against the source ECC sales orders to confirm the field mapping gap, then correct via migration object rework or manual field update before re-triggering Ariba synchronization.
mediumPurchase Requisition

3. In a Central Procurement hub scenario connected to multiple S/4HANA Public Cloud execution systems, sales order-driven third-party purchase requisitions from an SD-integrated execution system are not appearing in the central procurement worklist. How do you troubleshoot this?

Verify that the connected execution system's requisitions are correctly replicated to the Central Procurement hub via the standard SAP Cloud Integration/SOA middleware used for Central Procurement, and check whether third-party (item category S) requisitions are included in the replication filter scope, since some Central Procurement configurations exclude certain document types by default. Also confirm the execution system's requisition release status and account assignment, as unreleased or incomplete requisitions won't replicate to the central worklist.
mediumPurchase Requisition

4. During an S/4HANA Public Cloud migration, sales order-driven third-party purchase requisitions migrated via Migration Cockpit are missing the SD sales order reference (VBAP/VBEP linkage), causing procurement teams to lose traceability between the PO and originating sales order. How would you troubleshoot and fix this using the available migration objects and APIs?

Check whether the migration object used for purchase requisitions/POs includes the sales order and item fields required for third-party linkage; standard Migration Cockpit templates for PR/PO may not carry SD account assignment category 'C' references unless explicitly mapped. Review the staging table mapping for the sales document/item fields, confirm the API (e.g., migration object's OData-based service) supports writing this reference, and if not supported directly, plan a follow-up correction via API-based mass update or a custom migration object extension in LTMOM.
mediumPurchase Requisition

5. During a P2P migration to S/4HANA, purchase requisitions created for SD-driven third-party sales orders are migrating successfully via Migration Cockpit, but after a subsequent release upgrade the sales order reference on some migrated requisitions is lost, breaking third-party billing. How would you troubleshoot this?

Check whether the upgrade changed the migration object field mapping or LTMOM structure used for the SD-account-assignment fields (sales order/item) on the requisition, since these are often custom-mapped in LTMOM rather than standard. Compare pre- and post-upgrade object structures, re-test the affected migration object in a sandbox, and check if the upgrade introduced new mandatory fields that silently defaulted the SD reference. Validate against ACDOCA/BSEG only if billing postings are also affected, and confirm third-party PR-to-SO linkage tables still populate correctly.
mediumPurchase Requisition

6. After go-live, sales orders created for intercompany stock transfer are not triggering the expected Ariba purchase requisition flow in a hybrid SD-MM-Ariba landscape. What integration points would you check first?

Check the intercompany SD document flow to confirm the corresponding purchase requisition or PO is generated in MM per configured automatic PO creation settings, then verify whether that requisition is correctly flagged for Ariba sourcing/network transmission based on account assignment and material group mapping rules. Also review CIG/cloud integration gateway logs for message failures between S/4HANA and Ariba, since a broken mapping there commonly blocks the requisition from ever reaching Ariba despite successful SD document creation.
hardPurchase Requisition

7. Buyers across multiple purchasing groups report that certain fields on purchase requisitions are mandatory for one group but should be optional for another, yet the field selection is being applied globally. As the architect, how do you diagnose and resolve this?

Field selection in MM is typically controlled by field selection keys tied to document type, transaction, and sometimes account assignment category, not directly by purchasing group; purchasing group itself does not drive field status by standard design. I would investigate whether a custom field selection reference or a validation/user-exit was mistakenly scoped globally, review the field selection group assignments in the relevant document type configuration, and if group-based differentiation is truly required, implement it via a BAdI or field exit rather than misusing standard field selection.
hardPurchase Requisition

8. As solution architect, how would you design purchase requisition document types to support both self-service (employee) requisitions and centralized strategic sourcing requisitions across a multi-country S/4HANA rollout, considering downstream FI-AP posting consistency?

I'd define separate PR document types (e.g., self-service SSR vs strategic NB) with distinct number ranges, item category defaults, and release strategies tailored to each process, avoiding one-size-fits-all configuration. Self-service PRs would default to limited account assignment categories (cost center) with simplified release, while strategic PRs allow multiple account assignment and higher-value release paths. Across countries, I'd standardize document type field selection at a global template level but allow country-specific release strategy characteristics, ensuring GL account determination and tax code defaults remain consistent so FI-AP postings don't diverge by country despite differing PR document types.

Related topics

Next practice step