SAP SD / O2C Sales Documents Interview Questions

Interviewers use sales documents to test depth rather than coverage: the follow-up question is almost always "why does the system behave that way?", and that is where prepared answers usually run out.

Foundational and intermediate coverage of SAP SD Sales Documents: the header-item-schedule line structure, document type configuration, copy control, and how these determinants drive document flow across the order-to-cash process in ECC and S/4HANA.

This page carries 13 reviewed SAP SD / O2C sales documents interview questions, each with a complete written answer and no sign-in required. The set breaks down into 3 foundational, 5 mid-level and 5 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.

If you can handle every question here without hesitating, sales documents is unlikely to be what costs you an SAP SD / O2C interview — and the same reasoning pattern transfers to the neighbouring topics linked at the bottom of this page.

13 Sales Documents questions with answers

easySales Documents

1. What is the business purpose of the Inquiry document type (IN) in the SAP sales cycle, and does it create any commitments in MM or affect stock?

An Inquiry (IN) is a customer's request for information on prices, delivery dates, or availability, without any legal obligation. It is a pre-sales document that has no impact on MM stock, does not consume ATP by default, and does not create requirements transfer. It can be copied into a Quotation, providing traceability and reporting on the lead-to-order pipeline without triggering procurement or production activities.

easySales Documents

2. What is material (product) substitution in SD order processing, and how is it configured to work within specific sales document types?

Material substitution replaces an entered material with another material or automatically proposes alternatives during order entry, using material determination (condition technique, transaction VB11/VB12) with condition tables and substitution reasons (e.g., automatic, manual, or with warning). It is activated per sales document type via the procedure assigned in item category and document type customizing, and substitution reasons control whether the system substitutes automatically, warns, or proposes a listbox of alternatives.

easySales Documents

3. What is the purpose of a delivery block versus a billing block on a sales order, and at what levels can each be set?

A delivery block prevents subsequent delivery creation and is set at header or schedule line level (e.g., credit hold, incomplete data), controlled via VOV8/VD05 settings. A billing block prevents invoice creation and is typically set at header or item level, often used for pricing review or contract approval. Both are maintained in table VBUK/VBUP status fields and can be automatic (via order type/credit management) or manual.

mediumSales Documents

4. A make-to-order sales order item is saved successfully despite missing an MTO-critical field—the requested ship-to plant override needed for correct production order determination—and the production order later pulls the wrong plant. How would you diagnose why the incompletion procedure did not catch this, and how would you correct it?

First check whether the ship-to plant override field is even part of the incompletion procedure assigned to the sales document's item category and status group; many custom fields are not included by default and must be explicitly added via the incompletion procedure structure (VUA fields) for the relevant status group. Also verify the field is not being defaulted from customer master or sales area data, masking the omission, and confirm the incompletion check occurs at item level, not just header, since plant determination is item-driven. Fix by adding the field to the appropriate incompletion procedure group, retesting via VA02 save, and ensuring the field updates before requirement transfer to avoid the production order picking the wrong plant.

mediumSales Documents

5. In a Make-to-Order (MTO) scenario, how would you configure the incompletion procedure for a Quotation to ensure that critical MTO-relevant fields like the requested delivery date and configuration data are captured before the quotation can be released for order creation?

Assign an incompletion procedure to the Quotation document type and relevant item categories via OVA2, including fields such as requested delivery date (VBAK-VDATU), configurable material characteristics, and quantity. Set the status group to block subsequent processing (e.g., saving or follow-up document creation) until completed. For MTO, ensure configuration data completeness is checked at item level so downstream requirements transfer and production order creation are not triggered with incomplete specifications.

mediumSales Documents

6. When configuring number ranges for a new sales document type that must be visible in a Fiori app for order creation, what configuration steps and constraints must be validated?

Define or reuse a number range interval in VN01 (internal or external), assign it to the sales document type in VOV8, and ensure the interval does not overlap with existing ranges to avoid duplicate-key errors. For Fiori apps like Create Sales Order, verify the OData service exposes the document type and that the number range year-independence setting matches business needs. Also confirm authorization objects for number range maintenance are assigned since Fiori apps rely on backend config, not separate ranges.

mediumSales Documents

7. In a make-to-order scenario integrating with production, how do sales-related blocks (delivery block, billing block) interact with the incompletion procedure to prevent premature downstream processing?

The incompletion procedure flags missing mandatory fields (e.g., planned delivery date, requirement class data) and can automatically set a delivery or billing block if configured in the incompletion log status group. Even if the order is technically complete, manual or automatic blocks set at header/item level via status control tables prevent delivery creation or invoicing until released, ensuring MTO-specific data like production order linkage is verified before goods movement.

mediumSales Documents

8. A customer contract for annual pricing agreements is being created, but users report the system won't let them save without a valid end date and target quantity. How would you analyze and address this using the incompletion procedure?

Check the incompletion procedure assigned to the contract document type (usually via header incompletion group linked in VUAK/OVA2 config) which likely has contract validity end date and target value/quantity as mandatory fields for document type CQ or WK1. Review the incompletion log via the order to identify the missing fields, and either populate them or, if the business requires open-ended contracts, remove those fields from the incompletion procedure or make them conditionally mandatory based on contract type.

hardSales Documents

9. You need to design a free-of-charge delivery process for promotional samples that must still consume ATP and update requirements planning, but must not create billing documents. What architecture would you propose?

Use a dedicated order type (e.g., FD or custom) with item category that has pricing relevance suppressed but availability check and TOR flags active (via schedule line category CN or similar), and requirement class configured to generate independent requirements so MRP is aware of the demand. Copy control from any reference document should route to a delivery-only flow (VTLA) without linking to billing (no entry in VTFA for that item category), or billing relevance flag set to blank/not relevant so invoice creation is structurally impossible while goods movement and requirement visibility remain intact.

hardSales Documents

10. As a lead architect, walk through how you would design and govern incompletion procedure assignment across inquiry, quotation, and sales order document types in a lead-to-order cycle, including how status groups differentiate fields that block saving versus fields that only block subsequent processing (like delivery or billing).

You'd define separate incompletion procedures per document type/item category combination in VUAA/VUAAB configuration, assigning fields to status groups that determine blocking behavior: some fields (e.g., pricing date) block save entirely if flagged in the procedure header status group, while others (e.g., shipping point) only populate the incompletion log and block later delivery/billing creation without preventing save. Governance means mapping business-critical fields progressively stricter from inquiry (loose) to quotation (moderate) to order (strict, including ATP/date fields), reviewed via VA05/V.02 incompletion worklists.

hardSales Documents

11. You are designing the global sales document type strategy for a multi-country S/4HANA rollout that must support standard orders across both make-to-stock and make-to-order flows without proliferating document types per country. What architectural approach would you take?

Favor a limited set of global standard order types (e.g., OR-based variants) differentiated by item category and schedule line determination logic rather than country-specific document types, using country/plant-dependent customizing (partner determination, tax, output) driven by condition tables rather than new document types. Use item category group on the material to branch MTS versus MTO flows automatically, and reserve new document types only for genuinely different business processes (e.g., consignment, returns), keeping copy control and pricing procedures centrally governed to minimize maintenance and support global template consistency.

hardSales Documents

12. Walk through the end-to-end process design for configuring scheduling agreements with forecast and JIT delivery schedules feeding MM/PP, including the document type control settings that differentiate forecast versus JIT delivery schedules and how these affect requirements transfer timing.

Scheduling agreement document type control defines whether the agreement carries forecast delivery schedules (planning-level, longer horizon, less firm) or JIT delivery schedules (short-term, firm, triggered typically by customer JIT calls via IDoc/EDI). Item category and schedule line category settings determine requirements transfer behavior: forecast schedules feed MRP as planning demand with a wider firm/trade-off zone, while JIT schedules generate immediate, firm requirements often bypassing further planning runs. The architect must align delivery schedule split (correction delivery schedule vs immediate) and requirement class settings so forecast delivery updates don't double-count against already-firmed JIT quantities, and configure the customer's EDI/IDoc profile to correctly update both schedule types without overwriting each other.

hardSales Documents

13. From an end-to-end design perspective, how do Quantity Contracts and Value Contracts differ in document type configuration, and what governs how release orders are created and tracked against them?

Quantity Contracts (e.g., CQ) track a committed quantity per material and generate release orders that reduce open quantity via document flow, using copy control (VTAA) that transfers quantities but redetermines pricing. Value Contracts (e.g., WK1) track a monetary value target, often using a value contract item category with assortment module (product hierarchy or material group), where release orders draw down the value rather than quantity. Both rely on contract-specific document types with distinct update controls, cumulative value/quantity fields on the contract item, and copy control rules governing release order creation.

Next practice step

Practice with Interview AI Take a mock test

SAP SD / O2C Sales Documents Interview Questions

13 Sales Documents questions with answers

1. What is the business purpose of the Inquiry document type (IN) in the SAP sales cycle, and does it create any commitments in MM or affect stock?

2. What is material (product) substitution in SD order processing, and how is it configured to work within specific sales document types?

3. What is the purpose of a delivery block versus a billing block on a sales order, and at what levels can each be set?

5. In a Make-to-Order (MTO) scenario, how would you configure the incompletion procedure for a Quotation to ensure that critical MTO-relevant fields like the requested delivery date and configuration data are captured before the quotation can be released for order creation?

6. When configuring number ranges for a new sales document type that must be visible in a Fiori app for order creation, what configuration steps and constraints must be validated?

7. In a make-to-order scenario integrating with production, how do sales-related blocks (delivery block, billing block) interact with the incompletion procedure to prevent premature downstream processing?

8. A customer contract for annual pricing agreements is being created, but users report the system won't let them save without a valid end date and target quantity. How would you analyze and address this using the incompletion procedure?

9. You need to design a free-of-charge delivery process for promotional samples that must still consume ATP and update requirements planning, but must not create billing documents. What architecture would you propose?

11. You are designing the global sales document type strategy for a multi-country S/4HANA rollout that must support standard orders across both make-to-stock and make-to-order flows without proliferating document types per country. What architectural approach would you take?

12. Walk through the end-to-end process design for configuring scheduling agreements with forecast and JIT delivery schedules feeding MM/PP, including the document type control settings that differentiate forecast versus JIT delivery schedules and how these affect requirements transfer timing.

13. From an end-to-end design perspective, how do Quantity Contracts and Value Contracts differ in document type configuration, and what governs how release orders are created and tracked against them?

Related lesson

Related topics

Next practice step