Configuring Output Determination Procedures and Condition Records for SD Documents
Learn how output determination procedures, access sequences, and condition records combine to select the correct output type for sales orders, deliveries, and billing documents.
Explanation
Output determination in classic SD works on the same condition technique used in pricing, but the outcome is a message (NAST entry) rather than a price. Each output type (for example order confirmation, delivery note, invoice print) is defined with control data specifying the default transmission medium, partner function, program/form or Smart Form/Adobe form assignment, and time of dispatch (immediately, via batch job, or on save). Output types are grouped into an output determination procedure, and each document type (sales order type, delivery type, billing type) is assigned exactly one procedure through configuration. Within the procedure, output types are sequenced with requirements (routines that decide whether a type is even considered, for example only propose an invoice print if the billing document is not cancelled) and an access sequence that points to condition tables. Condition tables define the key combination used to find a condition record: common keys include sales organization, document type, customer, or a combination such as sales org plus customer plus output type. Condition records are maintained per key combination and store the actual partner (who receives the output), medium (print, fax, EDI, email, XML), and timing. When a document is created or changed, the output determination procedure runs during save processing. The system evaluates each output type in sequence: it checks the requirement routine, then searches condition records using the access sequence from most specific to least specific key. The first successful match creates a NAST record (message record) for that output type, storing the determined partner, medium, and timing, and this becomes the actual output that either triggers immediately or waits for a background job. A critical implementation decision is where to put the granularity of condition records. Overly generic records (for example a single record for all customers) reduce maintenance but eliminate flexibility for customer-specific print layouts or communication channels. Overly granular records increase maintenance overhead and risk of missed setups for new customers. A common pattern is to maintain a general fallback condition record with medium print, and add customer-specific override records only where a customer requires EDI or a specific form. Document flow visibility matters here: the output records created for a sales order are visible in the order's output/messages screen, for deliveries in the delivery output screen, and for billing documents in the invoice output screen. Consultants must know that output determination executes independently at each document level; an order output does not automatically propagate to the delivery or invoice - each document type has its own procedure and its own condition records, though many implementations intentionally reuse similar output types across documents for consistency. In S/4HANA, the classic NAST-based output determination continues to function for these document categories in many implementations, though SAP has introduced the newer Business Rule Framework plus / output management framework as a strategic direction for certain object types (billing documents in particular). Whether a given system uses classic or the newer framework depends on release, deployment model, and explicit migration activity, so this must be verified per system rather than assumed.
Real project scenario
A distribution company configured a delivery output procedure so that all deliveries default to a packing list print via a local printer, but delivveries for a set of key EDI-enabled customers needed an additional despatch advice message sent electronically. The consultant added a customer-specific condition record combining sales organization, shipping point, and customer number, layered above the generic fallback record, and set the EDI output type's medium to distribution via IDoc so the despatch advice generated automatically during delivery confirmation without manual intervention.
Common mistakes
• Assigning the wrong output determination procedure to a document type, causing no output types to ever be considered. • Maintaining condition records only at a generic level, so customer-specific requirements silently fall back to the wrong medium. • Not defining a requirement routine, causing an output type to be proposed even when it should not apply (for example proposing invoice print output on a cancelled billing document). • Assuming an output determined at sales order level will automatically also apply at delivery or billing level. • Forgetting to test with multiple key combinations, so an access sequence never reaches the fallback condition record because a more specific but incorrect record matches first.
Best practices
• Keep a documented mapping of output type to document type to determination procedure for audit and troubleshooting. • Maintain a generic fallback condition record for every output type to avoid missing outputs for new customers. • Use requirement routines to prevent irrelevant outputs (for example suppressing print output for cancelled documents). • Coordinate output type medium choices with the partner's actual capability (EDI-ready customers should not default to print only). • Review condition record key granularity periodically as customer base and channel mix evolve.
Interview angle
Interviewers often probe whether a candidate understands that output determination reuses the pricing condition technique conceptually but produces message records (NAST) rather than price conditions, and whether the candidate can explain the access sequence search logic from most specific to generic key combination, plus how requirement routines gate output type proposal.