Configuring Output Determination: Types, Procedures, and Processing Routines

Explanation

Configuring output determination follows the same structural pattern as pricing because both use the condition technique, but the objects and their purpose differ. The building blocks are: output types, condition tables, access sequences, determination procedures, and partner function relevance, plus the processing routines that actually generate the document. An output type (e.g., BA00 order confirmation, LD00 delivery note, RD00 invoice, ZINV for a custom invoice variant) defines default properties: which partner function it targets by default (sold-to, ship-to), the default transmission medium (print, fax, email, EDI, external send), whether it can be sent multiple times, and which processing program/form combination renders it. Configuration typically starts by copying a standard output type as a reference to preserve proven behavior, then adjusting the partner function, medium, and program/form assignment. Condition tables define the key fields used to find condition records — commonly sales organization, document type, and customer, though additional fields like sold-to partner or sales district can be added for finer control. An access sequence lists condition tables in priority order, so the system tries the most specific combination first (e.g., sales org + customer) and falls back to more generic combinations (e.g., sales org + document type) if no specific record exists. The determination procedure ties everything together: it lists which output types are relevant for a given sales document type, delivery type, or billing type, in what sequence, and whether a requirement (a routine controlling whether the output type is even considered) must be satisfied. This procedure is then assigned to the relevant document type in customizing, similar to how a pricing procedure is assigned to a sales area and document type combination. Once configuration exists, business users maintain condition records specifying, for a given output type and key combination, which partner receives the output, through which medium, and (for print) which printer or output device, or (for email) whether a cover text or attachment format applies. When a document is saved, output determination runs, matches condition records, and creates output records referencing the resolved medium and processing routine. Processing routines connect an output type to an actual print program and form (SAPscript, Smart Form, or Adobe Form). For print media, the program formats and sends data to a spool request. For email, the program builds message text and attaches a rendered document, often as PDF via Adobe Document Server. For EDI, the program typically triggers IDoc generation, handing off to the ALE/EDI subsystem for external transmission — this is a critical integration point with logistics partners and EDI middleware. Timing matters: output can be configured for immediate processing at document save, or for collection into a background job (transaction-driven mass processing) that processes a batch of pending output records at a scheduled time. Collected processing is common for invoices sent in nightly batches to reduce print server load and support consolidated mail runs, while immediate processing suits order confirmations that customers expect promptly. A frequent configuration decision point is whether a requirement routine should suppress an output type under certain conditions — for example, not producing a delivery note output for return deliveries, or suppressing an invoice output for credit memos below a threshold. These routines require coordination with development since they are custom ABAP logic evaluated during determination.

Code example

* Illustrative pseudo-logic for a requirement routine controlling output type relevance* (actual implementation is done via a custom routine assigned in the determination* procedure step, not written directly here) FORM output_requirement_101.  " Example intent: suppress order confirmation output (BA00)  " for internal intercompany sales document types  IF vbak-auart = 'ZIC1'.    sy-subrc = 4. " condition not fulfilled, output type skipped  ELSE.    sy-subrc = 0. " condition fulfilled, output type considered  ENDIF.ENDFORM.

Real project scenario

An industrial equipment distributor needed delivery notes to print automatically at the correct warehouse printer based on the shipping point, while invoices for EDI-enabled customers had to trigger IDoc generation instead of print. The team built a condition table combining shipping point and output type for delivery notes with printer determination, and configured a separate output type for EDI-relevant billing documents with a processing routine that generated an IDoc through the standard message control interface, coordinating closely with the EDI middleware team on segment mapping.

Common mistakes

• Copying an existing output type without renaming and reassigning the processing routine, causing conflicts with standard SAP objects during upgrades. • Setting up condition tables that are too generic (e.g., only sales organization), causing unwanted default outputs for customers who should be excluded. • Forgetting to assign the determination procedure to the actual document type, so output determination silently never triggers. • Using immediate processing for high-volume billing runs, overloading the print/spool system during month-end. • Not coordinating requirement routine logic with the ABAP team, leading to routines that block output types unintentionally for edge-case document types.

Best practices

• Always copy standard output types with a new custom key (Z-namespace) rather than modifying SAP-delivered types directly. • Design condition tables with the minimum necessary specificity to avoid unintended output suppression or duplication. • Separate print-based and EDI-based output types clearly, even if they represent the same business document, to avoid processing routine conflicts. • Use collected/background processing for high-volume billing runs to protect spool and print infrastructure. • Document requirement routines and their business intent clearly, since they are easy to overlook during later troubleshooting.

Interview angle

Expect questions on how the condition technique applies to output management versus pricing, what an access sequence and determination procedure do in this context, and how processing routines connect output types to actual forms. Candidates should be able to explain the difference between immediate and collected output processing and when each is appropriate.