Configuring Third-Party Sales: Item Category, Schedule Line, and Requisition Determination
Explains the configuration mechanics behind third-party sales including item category determination, schedule line category control settings, purchase requisition item category linkage, and account assignment category in the resulting purchase order.
Explanation
Configuring third-party sales requires coordinated settings across SD and MM configuration areas, since the process spans both modules by design. The starting point is item category determination: the system uses a table-driven lookup based on sales document type, item category group (from the material master, typically an item category group used specifically to flag third-party materials), item usage, and the higher-level item category (blank for a standalone line). This determination points to the appropriate third-party item category. It is possible to configure a manual alternative item category so users can switch a line between third-party and standard processing when business rules allow it, but this should be tightly controlled since it changes the entire downstream document flow. The item category itself carries billing relevance settings that control whether billing is based on the order quantity, delivery quantity, or (for third-party) the purchasing document quantity. Critically, the item category for third-party sales typically has billing relevance set so that the system looks to the purchase order history (goods receipt or invoice receipt quantities) rather than a delivery document. This is what makes third-party items skip delivery processing entirely in the classic scenario. At the schedule line level, the schedule line category determines whether a requisition is automatically created. The key configuration flag on the schedule line category indicates that this schedule line type triggers purchase requisition creation, and a linked field specifies the item category to be used in the generated purchase requisition (an MM-side item category that flags the requisition line as relevant to third-party/sales-order stock). This cross-module field is what actually creates the link: when the sales order is saved, the system calls the requisition creation logic using this configuration, populating the requisition with the material, quantity, delivery date, and a reference back to the sales order and item number. On the MM side, the resulting purchase requisition, when converted to a purchase order, carries an account assignment category that ties procurement costs and goods receipt processing to the originating sales order line. This account assignment ensures that when invoice verification posts the vendor invoice, the system can update the value and quantity information visible from the sales order's purchase order history, which billing relies on to create the customer invoice. Several configuration decisions affect downstream behavior. First, whether billing is invoice-receipt-based or goods-receipt-based is a copy control and item category setting decision; project teams must decide this jointly with finance, since invoice-receipt-based billing usually gives more accurate margin recognition but can delay billing until the vendor invoice is processed. Second, requisition release strategies (as governed by MM release procedure configuration) may force manual approval steps before the requisition becomes a purchase order, which affects overall order-to-cash cycle time and needs to be communicated to sales operations. Third, in scenarios with partial deliveries or partial invoices from the vendor, the item category and copy control configuration must correctly handle multiple partial billing documents against a single sales order line, which requires careful testing of quantity and value proration. Testing this configuration end-to-end (from item category determination through requisition creation, PO conversion, statistical goods receipt or invoice receipt, and finally customer billing) is essential before go-live, because a single misconfigured field, such as an incorrect item category on the schedule line category's requisition link, can silently prevent requisitions from being created at all, leaving sales orders stuck with no procurement action and no visible error to the order-entry user.
Real project scenario
During an S/4HANA implementation for a distributor, the project team configured a new item category group for a newly onboarded third-party product line. They copied an existing item category but forgot to update the schedule line category's requisition item category link, resulting in schedule lines that saved successfully but never generated purchase requisitions. Procurement only discovered the gap when customers called asking why orders placed days earlier had not shipped, prompting the team to build a daily exception report comparing open third-party sales order lines against requisition existence.
Common mistakes
• Copying an existing item category or schedule line category without verifying every control field, especially the requisition creation flag and MM item category link, resulting in silent process failures. • Failing to align billing relevance (order-based vs invoice-receipt-based vs goods-receipt-based) with the finance team's revenue recognition expectations, causing disputes after go-live. • Not setting up or communicating MM release strategy thresholds, so requisitions sit unapproved and sales teams assume the process is broken. • Ignoring partial delivery and partial invoice scenarios during testing, leading to billing quantity mismatches discovered only in production.
Best practices
• Maintain a configuration comparison checklist between the new and template item category/schedule line category whenever copying settings for a new third-party material scenario. • Agree explicitly with finance whether billing should be invoice-receipt-based or goods-receipt-based before configuring copy control, and document the decision for audit purposes. • Build a reconciliation report early in the project that flags third-party sales order lines with no corresponding purchase requisition or purchase order, to catch configuration or master data gaps quickly. • Include partial delivery and partial invoice test cases in the SD-MM-FI integration test script rather than only testing the simple one-to-one quantity scenario.
Interview angle
A common configuration-focused question asks candidates to describe exactly how a sales order schedule line results in a purchase requisition, testing whether they understand the specific linkage field on the schedule line category rather than giving a vague answer about 'SD-MM integration.' Strong candidates also explain the billing relevance distinction between delivery-based and purchase-order-history-based billing, since this is a frequent point of confusion for people who have only worked with standard sales processing.