Output Not Triggered For Sales Order Or Delivery
Output failing to trigger on a sales order or delivery is almost always a condition record or requirement routine problem in the output determination procedure, not a print or interface fault. Check whether a condition record exists for the output type at the correct key combination, whether the procedure is assigned to the document type, and whether a partner function or field the access sequence depends on is actually filled on the document.
This page covers order confirmation, delivery note, packing list, dispatch advice and similar output types failing to generate or failing to leave the system after the sales order or outbound delivery is saved. It walks through the condition-technique failure points in the classic NAST-based output determination, the transmission-layer failures that look identical from the business side, and the newer BRF+ based output management equivalents.
Published 16 Sept 2026· 1,134 words
The business symptom
The warehouse says the delivery note or packing list never printed. The customer says they never received the order confirmation email. Someone in customer service reopens the delivery and the shipping notification field is blank where a green light usually appears. Sometimes it is intermittent - output goes out for most orders from a plant but not for one customer, or it worked last week and stopped this week with no config change anyone remembers making. Occasionally the complaint is the opposite of missing output: the same invoice or delivery note printed twice, which is a different failure in the same mechanism and gets reported alongside it.
The configuration behind it
- No condition record exists for the output type at the key combination the access sequence needs (document type, sales organization, partner function). This is the single most common cause and is pure data, not config.
- A condition record exists but the requirement routine attached to it evaluates to false for this document - it may test for a specific transmission medium, a specific document type, or a field that is blank on this particular order.
- The output determination procedure is not assigned to the sales document type or delivery type, or the output type's control record in that procedure has the wrong transmission medium, partner function, or time setting for how the business expects it to fire.
- The partner function required by the condition record (ship-to, sold-to) is missing on the document, or is present but has no email address, fax number, or output device maintained against the chosen communication method.
- Processing time is set to a scheduled job rather than immediate, and the periodic background job that processes pending output records is not scheduled, has stopped, or is running with a variant that excludes this document.
- The output record was created successfully (status green) but the transmission layer failed downstream - dead SMTP node, inactive IDoc partner profile or port, printer device not found - which looks like a determination failure but is not one.
- The output type is flagged as not repeatable and has already been sent once, so a second attempt is silently suppressed by design.
- A field the access sequence reads is blank on the document because the item is incomplete - missing shipping point, plant, or route means the condition record, even if it exists, is never found.
- On output-management architectures that use action definitions and rule-based determination instead of classic condition technique, the action definition for the application object type is missing or its rule does not return a result.
What to check
- Open the order or delivery and check the output tab (Extras, Output) to see whether the output type is listed at all and what its status is.
- If the output type does not appear, run the output determination analysis from the same menu path - it traces every access step and shows which access failed to find a record.
- In NACE, confirm the output determination procedure is assigned to the document type and check the control record for that output type: transmission medium, partner function, dispatch time.
- In VV13, display the condition record for the output type at the expected key combination and confirm it is not expired, deleted, or scoped to a different key than the one on this document.
- Check the partner tab on the document for the communication data (email, fax, printer) tied to the partner function the condition record requires.
- If a NAST-style record exists but nothing was delivered, check WE02 or WE05 for the IDoc, SOST for the email queue, SP01 for the spool request, and SM37 for the background job that processes pending output.
How to prove it in the data
Pull the output records for the specific order or delivery number from table NAST filtered on object key, output type, and status field. A record with a red or error status confirms determination succeeded but transmission failed; no record at all confirms determination itself never fired, pointing back to the condition record or requirement routine. Comparing the retry count field against a working document for the same customer isolates whether this is a one-off or systemic failure.
Resolution path
Missing condition record is a data fix: create it with VV11 at the correct key combination and reprocess the document's output. A requirement routine returning false incorrectly for a valid scenario is a config and possibly ABAP fix - it needs review of the routine logic and a transport once corrected, it is not something to patch document by document. Procedure assignment or control record errors in NACE are config changes requiring a transport through the landscape; do not fix them only in the affected client. Missing partner communication data (no email, no device) is master data, correctable in the customer or vendor master directly. A stalled scheduled job for output processing is a basis action - reschedule or restart the job, and check why it stopped rather than only restarting it once. Transmission-layer failures (dead IDoc port, SMTP outage, printer offline) belong to basis or interface teams and are unrelated to SD configuration even though they present identically to the business.
The fix people try first (and why it fails)
The reflex is to manually reprocess or repeat the output from the document, or to create a condition record with the broadest possible key (no partner function restriction, no document type restriction) just to make it fire. Manual reprocessing hides why the automatic determination failed and the same document category will fail again next time. A too-broad condition record fires output for scenarios it was never meant to cover, producing duplicate order confirmations, printed delivery notes for return orders, or emails to the wrong partner function, which then becomes its own incident.
Whose problem this is
SD functional consultant owns the condition technique, procedure assignment, and requirement routine review. Basis owns the background job and interface layer (SMTP, IDoc ports, printer queues). Handover note should state the document number, output type, whether a NAST record was created and its status, and which access step failed in the determination analysis, so the receiving team does not repeat the same trace.
Related SAP objects
Reviewed pages this object connects to in the ERPClimb knowledge graph.
Source: ERPClimb — https://erpclimb.com/sap-functional-issues/output-not-triggered-for-the-sales-order-or-deliveryERPClimb is an independent platform and is not affiliated with SAP SE. Reference pages are written and reviewed by SAP consultants for learning and troubleshooting.