SAP NACE Explained With Real Example
Output Determination -Complete Guide for Every Consultant

A Condition Table defines the combination of fields SAP uses to search for a condition record. Think of it as the columns in a spreadsheet that SAP looks up. For SD output, SAP delivers standard condition tables like Table 1 (Sales Organisation + Distribution Channel + Customer) and Table 2 (Sales Organisation + Customer). The table determines the "key" -what combination of data from the document SAP will use to find the matching condition record. For Suraj Electronics: the condition table uses Sales Org 1000 + Distribution Channel 10 + Customer C-1001 as the search key. If a condition record exists for exactly this combination, SAP finds it and knows output should be triggered.

The Access Sequence defines the order in which SAP searches the condition tables -from most specific to least specific. It answers: if no record is found for the most specific combination, what should SAP try next? For output type BA00 (order confirmation), the access sequence might be: Step 10 -search Table 1 (Sales Org + Dist Channel + Customer). Step 20 -if nothing found, search Table 2 (Sales Org + Customer). Step 30 -if still nothing found, search Table 5 (Sales Org only). SAP searches Step 10 first. If a condition record exists for Suraj Electronics specifically, it is found immediately. If not, SAP falls back to the next step. This waterfall logic is the heart of the condition technique -general-to-specific or specific-to-general depending on configuration.

The Output Type is the central configuration object -it defines everything about one specific output: the name (e.g. BA00 for order confirmation), the description, the default medium (1=Print, 5=External Send/Email, 6=EDI), the timing (immediately on save, or in a background job), the partner function (SP=Sold-to, BP=Bill-to, SH=Ship-to), and the print program and form name. For Suraj Electronics order confirmation BA00: Medium = 5 (email), Timing = 4 (send immediately), Partner = SP (sold-to party). The output type also holds the processing routine -the ABAP function module that packages the document data and passes it to the output channel. This is the object that connects business intent ("send an order confirmation") to technical execution ("run program RVADOR01 with form RVORDER01").

The Output Procedure is an ordered list of output types assigned to a specific document type. It tells SAP: when processing a sales order of type OR (standard order), which output types should be checked? The procedure V10000 for sales orders contains BA00 (order confirmation), BA01 (order confirmation to interco partner), and potentially custom output types. The procedure is assigned to the document type in configuration. When SAP saves a sales order, it loops through every output type in the procedure and runs the condition technique (access sequence → condition table → condition record) for each one. If a condition record is found, the output is triggered. This is why adding a new output type to a procedure immediately activates it for all new documents of that type.

The SD consultant, Kavita Sharma, opens T-code NACE. The initial screen shows all available applications -V1 (Sales), V2 (Shipping), V3 (Billing), EF (Purchase Orders), WA (Goods Movements), RD (FI Documents), and others. Each application is a separate output determination area with its own output types, procedures, and condition records. Kavita selects V1 (Sales) and clicks Output Types. She can see the standard output type BA00 (Order Confirmation) is already defined in the system from SAP standard delivery. She will now configure it to send email for Sira Garments' sales orders.

In the BA00 output type configuration, Kavita sets: Default Values tab -Transmission Medium = 5 (External Send / Email). Time = 4 (Send immediately when document is saved -for urgent order confirmations this is critical; setting 3 would mean "send at end of day batch"). Partner Functions tab -Partner Function SP (Sold-to Party) is the default recipient. This means the email goes to the email address maintained in customer master KNA1 under the AD_SMTPADR communication field. Processing Routines tab -Program: RVADOR01, FORM Routine: ENTRY_NEU, Form: RVORDER01 (SAPscript layout set for order confirmation). In S/4HANA this is often replaced with a SmartForm or Adobe Interactive Form but the concept is identical. The form RVORDER01 is what determines how the PDF looks when it reaches the customer.

The output type configuration in NACE tells SAP HOW to send the output. The condition record tells SAP WHEN -for which customers/sales orgs the output should fire. Without a condition record, NACE will never trigger BA00, even if it is perfectly configured. Kavita opens VV11 (Create Output Condition Records for Sales). She selects output type BA00 and condition table "1" (Sales Org + Dist Channel + Customer). She enters: Sales Org = 1000, Dist Channel = 10, Customer = ALL (or a specific customer range), Medium = 5 (Email), Language = EN, Date/Time = 4 (Immediate). She saves the record. Now every time a sales order for Sales Org 1000 / Dist Channel 10 is saved, SAP finds this condition record and triggers the BA00 email output.

Kavita checks that BA00 is in the output procedure for document type OR (standard order). In NACE → V1 → Procedures → she opens procedure V10000. BA00 must be listed with Requirement = blank (always check) or a specific requirement routine number if conditional logic applies. The procedure V10000 is then assigned to document category C (Sales Order) via T-code V/30 (Sales: Output for Sales Documents → Assign Procedures to Document Types). She confirms OR is mapped to V10000. Now the chain is complete: OR document type → procedure V10000 → output type BA00 → access sequence 0001 → condition table 1 → condition record for Sales Org 1000 + Dist Channel 10 → email via RVADOR01.

Kavita creates a test sales order in VA01 for customer C-1001 in Sales Org 1000. After saving, she opens the order in VA02 / VA03 and navigates to Extras → Output → Header → Edit. The output screen shows BA00 with status green (processed successfully) and medium 5 (email). She can see the email address it was sent to (from the customer master). If the status shows a yellow warning or red error, she clicks the Processing Log button -this shows the exact error message from the output processing routine, whether it was a missing email address on the customer master, a missing SAPscript form, or an SMTP configuration issue. The NAST table (SE16N → NAST) stores every output message for every document with its status, processing time, and error text.

In NACE, the MM consultant Rajesh Pillai navigates to application EF (Purchasing). The standard output type NEU (New PO -Erstdruck in German, hence NEU) handles the initial print of a purchase order. Unlike SD's BA00 which fires once on order creation, NEU is designed to fire on the first save and also when the PO is changed and a new version must be sent. Rajesh opens NEU in the Output Types screen and reviews: Default Medium = 1 (Print). He needs to create two separate condition records -one for local vendors with medium 1 (print) and one for international vendors with medium 5 (email). The output type itself stays the same. Only the condition record medium field differs between the two vendor groups.

MM output condition records are maintained via T-code MN04 (Create PO condition records) or from within ME21N via Messages tab. Rajesh creates two condition records for NEU: Record 1 -Purchasing Org = 1000, Vendor range = domestic Indian vendors (country IN), Medium = 1 (Print), Output Device = LP01 (local printer), Timing = 3 (background job at night). Record 2 -Purchasing Org = 1000, Vendor range = international vendors (country not IN), Medium = 5 (Email), Timing = 4 (immediate send). The access sequence for NEU searches by Purchasing Org + Vendor first, then falls back to Purchasing Org only. Because Rajesh has set up records at Purchasing Org + Country level, the system correctly differentiates domestic from international vendors and sends the right output channel for each.

The output procedure for purchasing documents is assigned in SPRO: Materials Management → Purchasing → Messages → Output Control → Assign Output Schema to Purchasing Document Types. The standard procedure for POs is RMBEF1. Rajesh verifies that NEU is in procedure RMBEF1 and the procedure is assigned to document type NB (standard PO). He also checks that the requirement field for NEU in the procedure is blank -meaning it fires for all POs. If a requirement routine number is set (e.g. routine 101), the system only triggers NEU when that ABAP routine returns TRUE. To manually trigger or resend PO output, the T-code is ME9F (Message Output for Purchase Orders). This is equivalent to VA02 output screen in SD -consultants use ME9F to resend failed outputs, change the output medium, or reprint specific POs.

A crucial MM NACE concept is the difference between NEU (new PO) and NEUM (PO change notice). When a buyer changes delivery date or quantity on an existing PO in ME22N, the vendor needs to receive an amended PO -not just a new print of the original. The output type NEUM is designed specifically for this: it fires only when specific fields on the PO are changed (quantity, delivery date, price, plant). The relevant change fields are configured in the output type's Change Fields tab. Rajesh configures NEUM to trigger when MENGE (quantity), EINDT (delivery date), or NETPR (net price) changes. This means vendors automatically receive a "PO Amendment" document by email whenever these fields change in ME22N, with the changed values highlighted in the form layout.

In NACE the FI consultant Deepa Nair navigates to application RD (FI Documents). The output type MAHN (from German Mahnung = reminder) controls dunning letter output. Unlike SD's BA00 which fires when a document is saved, MAHN is triggered by the dunning run program F150 -it does not fire automatically on document posting. The MAHN output type configuration in NACE defines: the print program (RFKORD10 for dunning letters), the SAPscript form (F150_DUNN_01 for level 1, F150_DUNN_02 for level 2, F150_DUNN_03 for level 3), and the output medium. Deepa sets medium = 5 (email) for all three levels and assigns the correct form to each dunning level in the Dunning procedure configuration.

The dunning procedure is configured in SPRO: FI → AR → Business Transactions → Dunning → Dunning Procedure → Define Dunning Procedures. Deepa creates dunning procedure Z001 for Raj Pharma with three levels. Level 1 -triggered 7 days after due date. Grace days = 0. Interest = No. SAPscript form = F150_DUNN_01 (polite payment reminder text). Level 2 -triggered 21 days after due date. Interest = Yes (1.5% per month). Form = F150_DUNN_02 (firm notice with interest calculation). Level 3 -triggered 45 days after due date. Always dun = Yes (dun even if paid). Interest = Yes (2%). Form = F150_DUNN_03 (final demand with legal action warning). Each level links to the MAHN output type, and the form is swapped automatically based on the dunning level reached.

The dunning procedure Z001 must be assigned to each customer master record that should receive dunning letters. Deepa uses T-code FD02 (Change Customer Master -Company Code Data) → Correspondence tab → Dunning Procedure field. She sets Z001 for all overdue customers. The Dunning Block field is important: if a customer has an ongoing dispute, the AR team sets a dunning block here to prevent letters from being sent while the dispute is resolved. The dunning recipient (the contact person who receives the email) comes from the customer's contact person linked to communication type DUNN in the customer master. If this contact is not maintained, the dunning email fails with "no recipient found" even if NACE is perfectly configured -another common go-live issue.

The dunning letters are generated by the F150 dunning program, which is run periodically (typically weekly or daily). F150 scans all open customer items, compares due dates to today's date, identifies which dunning level applies, generates the MAHN output via NACE, and creates dunning history entries in table MHNK. The process: Step 1 -F150 Parameter Run (set dunning date, company code, customers). Step 2 -F150 Dunning Proposal (system shows all customers it will dun and at what level -review before finalising). Step 3 -F150 Release (final confirmation, output is generated and sent). The dunning proposal step is critical -always review before releasing because errors in this step can lead to sending incorrect letters to customers who have already paid, damaging the business relationship.

In NACE, application WA (Inventory Management / Goods Movements) controls output for material documents -the documents created by MIGO (goods receipt, goods issue, transfer posting). The output type WE01 is the standard GR slip. The MM consultant Vijay Kumar opens WE01 in NACE → WA → Output Types and configures: Default Medium = 1 (Print), Timing = 1 (print immediately on MIGO save -critical for warehouse operations where the packer needs the slip before the goods are moved to storage). Print Program = RSNAST00 (standard output processing program), Form Routine = ENTRY_NEU, SAPscript Form = WA_SLIP (the GR slip layout showing material number, quantity, storage location, vendor, and PO reference).

WA condition records are maintained from within SPRO: MM → Inventory Management → Output Determination → Maintain Output Condition Records -or alternatively via the NACE condition record maintenance. The key fields for WA condition records are typically Movement Type + Plant. Vijay creates a condition record: Movement Type = 101 (GR against PO), Plant = 1000 (Chennai plant), Medium = 1 (Print), Output Device = WH01 (warehouse printer near the GR dock), Timing = 1 (immediate). He also creates a separate record for movement type 122 (return to vendor) with output type WE03 (return slip) so the warehouse team always has a printed document for reversals. Without these condition records, MIGO saves will complete successfully but no slips will print -the warehouse team will have no paper trail.

When a GR slip fails to print (printer offline, paper jam, network error), the warehouse team needs to reprint it. The T-code for this is MB90 (Output for Inventory Documents -equivalent to ME9F for POs and VA02 output screen for sales orders). In MB90, the user selects the material document number, the output type WE01, and clicks Process. The output is resent to the printer. Vijay trains the warehouse supervisor to use MB90 for reprints. For bulk reprocessing of failed outputs across all modules, a Basis admin can use T-code RSNAST00 as a report to reprocess NAST records with status error. The NAST table is the universal output status table -one row per output message per document, with fields VSTAT (processing status: 0=not processed, 1=successfully processed, 2=error) and VSZTP (output time).

SE16N → Table NAST → filter on KAPPL + OBJKY (document number). If NO record exists: the output type never fired. Root cause is either (a) output type not in procedure, (b) procedure not assigned to document type, or (c) no condition record exists for this document's key combination. If a record EXISTS: go to Check 2.

If VSTAT = 1: output was sent successfully. If the customer/vendor still did not receive it, check the email address in ADSMTP field of the NAST record. If VSTAT = 2: output processed but error occurred. Go to VA02 / ME9F / MB90 → Output screen → Processing Log to see the exact error message. Common errors: "No email address", "Form not found", "Spool request creation failed". If VSTAT = 0: output is queued but not yet processed -check the timing field and whether the background job for output processing (RSNAST00 job) has run.

If NAST has no record, use VV13 (display SD output condition records) to verify a condition record exists for the exact document's Sales Org + Customer combination. If no record found at that level, check if a more general record exists (Sales Org only). Use MN06 for MM PO condition records. If no condition record at any level: create one in VV11 / MN04. The most common root cause of "output never fires" on a new customer or vendor is a missing condition record.

NACE → Application → Procedures → find the procedure (e.g. V10000) → verify the output type (e.g. BA00) is in the list. Then V/30 to verify procedure V10000 is assigned to document type OR. If the output type was added after go-live, it only affects new documents created after the assignment -existing documents are not retroactively updated. For MM: check SPRO → MM → Purchasing → Messages → Assign Output Schema to Document Types for NEU in procedure RMBEF1.