Fact-checked by Grok 2 weeks ago

IDoc

IDoc, short for Intermediate Document, is a standard and format developed by for the electronic exchange of business data, enabling seamless communication between SAP systems and external applications or non-SAP systems. It serves as an intermediate container for transaction data, , and control data, facilitating processes such as (EDI) and Application Link Enabling (ALE) to automate business transactions like order processing, invoicing, and inventory updates. Introduced as part of and evolving through versions since the early 1990s, IDoc has become a cornerstone of SAP's capabilities, supporting both inbound and outbound data flows with robust error handling and status tracking. At its core, an IDoc consists of three main record types: a single control record that holds administrative details such as sender and receiver information (stored in database table EDIDC), multiple data records that encapsulate the actual business payload in hierarchical segments (stored in table EDIDD), and multiple status records that monitor the IDoc's processing lifecycle (stored in table EDIDS). Segments within data records define the structure, with SAP providing predefined basic types for common scenarios—such as ORDERS for purchase orders—while allowing custom extensions for specialized needs. This modular design ensures flexibility, as IDocs can be generated, processed, and monitored using SAP transactions like WE02 for viewing and BD87 for reprocessing. IDocs are integral to SAP's ecosystem, particularly in (ERP) environments, where they enable or batch across distributed systems without custom programming for each point. occurs via SAP's Implementation Guide (IMG) under the IDoc Interface/ALE section, supporting conversions to other formats like XML or EDI standards for broader . With built-in monitoring tools for and performance optimization—such as packet sizing for efficient transmission—IDocs ensure reliable and compliance in global operations.

Overview

Definition and Purpose

IDoc, short for Intermediate Document, is a standardized data format designed for the electronic exchange of business data between SAP systems and external non-SAP systems, as well as within distributed SAP environments. It serves as a container for structured application data, facilitating seamless integration without direct dependency on the underlying communication protocols. The primary purposes of IDoc include enabling (EDI) for interactions with external trading partners and Application Link Enabling (ALE) for distributing data across multiple instances in a loosely coupled manner. Through these mechanisms, IDoc automates key business transactions such as purchase orders, invoices, and the synchronization of like customer or material records, reducing manual intervention and errors in cross-system processes. Key benefits of IDoc lie in its standardization of data representation within the ecosystem, which promotes consistency and reusability across applications. It achieves syntax independence by serving as an intermediate layer that can be mapped to various external EDI standards, such as or ANSI X12, allowing flexibility in interfacing with diverse partner systems. Additionally, IDoc primarily supports asynchronous exchange modes, accommodating high-volume batch transfers efficiently. Common use cases illustrate IDoc's practical role, such as outbound transmission of purchase orders (using types like ORDERS) from an system to a supplier's non-SAP platform for , or inbound receipt of shipment confirmations (via DESADV) to update and status automatically. These scenarios enhance efficiency by streamlining document flows between buyers and vendors.

History and Development

IDoc was introduced in 1995 with release 3.0 as a core component of SAP's (EDI) capabilities, designed to standardize the exchange of business data between SAP systems and external partners. This format addressed the growing need for reliable integration with non-SAP systems, enabling asynchronous transfer of structured documents such as invoices, purchase orders, and material masters. At launch, several hundred standard IDoc types were shipped, providing predefined structures for common business transactions based on international EDI standards like . Over the years, IDoc evolved to support 's expanding ecosystem, shifting from primarily external EDI integrations to broader application scenarios. ALE technology, introduced alongside IDoc in R/3 3.0, enabled seamless internal communication between distributed instances without custom programming. A key milestone occurred in 1998 with the release of 4.0B, which introduced IDoc record type 3 for enhanced processing capabilities. This refinement extended IDoc's utility to asynchronous data distribution across landscapes, improving scalability for multinational enterprises. Subsequent updates in Enterprise and early versions refined IDoc processing, including improved error handling and performance optimizations. In the Central Component () era, starting around 2004, IDoc gained support for XML serialization, enabling easier mapping to web-based services and hybrid integrations. This allowed IDocs to be transformed into XML format for outbound transmission or inbound parsing, bridging legacy EDI with modern APIs. By the mid-2010s, as SAP transitioned to S/4HANA in 2015, IDoc retained its role as a robust legacy standard for B2B and system-to-system exchanges, despite the introduction of alternatives like OData services for real-time APIs. Adaptations for cloud environments, such as integration with and hybrid setups, ensured IDoc's continued relevance, with ongoing enhancements to handle high-volume data flows in distributed architectures. A significant milestone is the proliferation of standard IDoc types, exceeding several hundred by the early 2000s and growing to support diverse industries, with SAP maintaining across releases. By 2025, IDoc's ecosystem includes adaptations for cloud-native integrations, such as via Suite, though SAP's clean core strategy encourages new developments to use event-driven architectures and APIs while continuing to support IDocs for existing scenarios.

Technical Structure

Control Record

The control record functions as the administrative header of an IDoc, encapsulating essential for its unique identification, processing direction, and routing within systems. It adheres to a fixed structure known as EDI_DC40, which is uniformly applied across all IDoc types to ensure consistent handling independent of the content. This record is stored in the database table EDIDC, where each entry corresponds to a single IDoc instance. Key fields in the EDI_DC40 structure provide the necessary details for IDoc management and transmission. The IDoc number (DOCNUM) serves as a generated sequentially from the number range EDIDOC. The message type (MESTYP) and IDoc type (IDOCTYP) define the semantic and structural purpose of the IDoc, respectively. Creation details are captured in the date (CREDAT) and time (CRETIM) fields, automatically populated by the system upon generation. The direction (DIRECT) indicates whether the IDoc is outbound (value 1) or inbound (value 2), influencing the subsequent processing path. Partner-related fields are pivotal for routing, linking the IDoc to configured entities such as and partner profiles. These include the sender (SNDPOR), sender partner type (SNDPRT, e.g., "LS" for logical system or "KU" for ), sender partner number (SNDPRN), receiver (RCVPOR), receiver partner type (RCVPRT), and receiver partner number (RCVPRN). Mismatches in these fields against configurations can prevent successful processing. The following table summarizes select key fields from the EDI_DC40 structure, highlighting their roles:
Field NameDescriptionExample Value
DOCNUMUnique IDoc identifier0000000000123456
MESTYP type defining business semanticsORDERS
IDOCTYPIDoc type specifying ORDERS05
DIRECT direction (1 = outbound, 2 = inbound)1
SNDPORSender port nameSAPP01
SNDPRTSender partner typeLS
SNDPRNSender partner numberP01CLNT100
RCVPOR port nameECOSIO
RCVPRT partner typeKU
RCVPRN partner number10000254
CREDATCreation date20251111
CRETIMCreation time143022
These fields collectively enable the system to route the IDoc via predefined ports (e.g., file or ) and partner profiles, ensuring delivery to the intended recipient. For instance, in an outbound ORDERS IDoc for transmission, the control record might specify the sender's logical system (SNDPRN as "P01CLNT100") and a file port (RCVPOR as "FILEPORT"), directing the IDoc to an external EDI subsystem.

Data Records

The data records constitute the core payload of an IDoc, forming its hierarchical body through a series of segments that establish parent-child relationships to represent structured application data. These records are stored in the database table EDID4, which holds the content for IDocs from release 4.0 onward, enabling the transmission of business information such as order details or material master data in a tree-like format. Each record is defined by key s including the type (SEGNAM), which identifies the specific format (for example, E1EDK01 for a header ), the level (HLEVEL, a two-digit numeric indicating the depth in the ), the parent number (PSGNUM) for linking child segments, and a variable-length (SDATA) up to characters to accommodate the actual content. The number (SEGNUM) further tracks the sequential position within the IDoc. This allows segments to encapsulate related s, ensuring flexibility in representing complex business s. The hierarchical arrangement supports up to 99 levels of nesting, as determined by the HLEVEL field's capacity, facilitating deep structures for multifaceted data exchanges. Segments within an IDoc type are classified as mandatory, optional, or conditional, with these attributes defined during the of the IDoc type using transaction WE30 (IDoc Type Editor), which outlines the permissible segments, their sequence, and repetition rules. Data mapping to these segments occurs during IDoc generation, where application data from modules is transferred via Business Application Programming Interfaces (BAPIs) or dedicated function modules that align source fields to segment structures, often using direct field-to-field mapping for standard elements. Qualifiers within segments—special fields that act as switches—enable conditional inclusion of subfields or related segments, allowing dynamic content based on business rules without altering the overall IDoc type.

Status Records

Status records in IDoc processing are stored in the database table EDIDS and provide a chronological of the IDoc's lifecycle, including each processing step, associated timestamps, and the users involved in status updates. These records track the progression of an IDoc from creation through transmission and application integration, capturing both successful advancements and any encountered issues. Each entry includes essential details such as the IDoc number (DOCNUM), the (STATUS), a descriptive text for the (STATXT), the segment number affected if applicable (SEGNUM), the date and time of the change (LOGDAT and LOGTIM), the user name (), and a sequential counter (COUNTR) to order the changes. The , a two-digit numeric value, indicates the specific state of the IDoc at that point; for example, 03 signifies that outbound has been successfully passed to the , while 51 denotes an during inbound application posting due to issues in the document content. codes are categorized by direction: those from 00 to 49 apply to outbound IDocs, reflecting stages like generation, transmission, and confirmation receipt, whereas codes 50 to 99 pertain to inbound IDocs, covering receipt, syntax validation, and posting outcomes. This structured logging allows for a clear sequence of events, with each new appending to the existing history generated automatically by ALE (Application Link Enabling) services during outbound or inbound workflows. The primary purpose of status records is to facilitate auditing, , and by maintaining a verifiable trail of IDoc handling, enabling administrators to issues back to specific steps, users, or timestamps for . In practice, these records support by highlighting problematic statuses, such as those indicating or application errors, which can then be addressed through targeted reprocessing or corrections. Multiple status entries per IDoc accumulate over its lifecycle, providing a comprehensive without a fixed upper limit imposed by the system, though practical processing typically results in a manageable number of updates.

IDoc Types

Basic Types

Basic types represent the standard IDoc formats provided by for exchanging data in common business scenarios, defining the overall structure including segments, data fields, and their formats. These types are created and maintained within the system using WE30, which allows viewing the of segments and associated rules. Examples include ORDERS05, used for sales orders to transmit details such as order items, pricing, and delivery information, and CREMAS04, employed for to synchronize supplier records across systems. Standard basic types are categorized by their functional purpose: master data types handle the distribution of foundational business objects, such as for material master data, which includes attributes like descriptions, units of measure, and classifications; transactional types support operational processes, for instance for invoice exchange, capturing billing details, taxes, and payment terms; and system message types facilitate control and confirmation flows, like ALEAUD01 for Application Link Enabling audit confirmations to verify data receipt and processing status. Each type incorporates predefined segments with rules specifying mandatory fields, data lengths, and validation logic to ensure consistency during data transfer. As of 2025, these basic types continue to be supported in , with periodic updates to segments for evolving standards. These basic types evolve across SAP releases to accommodate new requirements and enhancements, with versions building upon prior ones to add fields or improve compatibility. For example, the ORDERS type progressed from ORDERS02 to ORDERS05, introducing additional segments for advanced features like configuration data and improved error handling. delivers several hundred such standard basic types to cover a wide range of integration needs. While basic types provide the core structure, they can be extended for specific customizations without altering the originals.

Extension and Custom Types

Extensions in IDoc allow organizations to adapt standard basic types by adding custom segments without modifying the original SAP-delivered structures, ensuring and maintainability. To create an extension, users access transaction WE30 in the system, enter a customer-specific name (typically starting with Z or Y in the customer ), select the "Extension" option, and link it to an existing basic type. The system then displays the basic type's structure in a , where new s can be inserted at appropriate positions using the "Create Segment" function under the Edit menu; these segments must be defined beforehand in transaction WE31, the segment editor, which allows specification of fields, data elements, and qualifiers for the custom data. Custom segments added via extensions follow naming conventions such as Z1IDOC for the segment type, incorporating fields tailored to specific business needs while preserving the hierarchical integrity of the original type. Attributes like minimum and maximum segment occurrences, as well as whether the segment is required, are configurable during extension creation to align with data exchange requirements. This approach enables incremental enhancements, such as appending regional compliance data to a standard type. For scenarios requiring entirely new structures not based on SAP basics, custom IDoc types are developed from scratch using WE30 by selecting the "Basic type" option and defining the full hierarchy of segments without linking to a predecessor. In WE31, each segment is built with its fields, including mandatory elements like segment type and position, to form a complete, self-contained IDoc type suitable for unique interfaces, such as proprietary data formats in specialized integrations. Transport requests are created via the Organizer to manage these developments across systems. IDoc types and their extensions maintain release independence through version management, where each release supports one of a basic type or extension, identified by the last two digits for types and three for segments. A successor must incorporate all elements of its predecessor plus at least one new component, such as an additional field or segment, and requires the prior to be released before creation; this ensures and controlled evolution across software updates. Released s cannot be altered, promoting stability in production environments. Best practices for extensions and custom types emphasize their use in addressing industry-specific or regional requirements, such as extending the INVOIC02 basic type with custom segments to include additional fields like tax numbers (e.g., STCD1 to STCD5 from KNA1) for in jurisdictions with unique fiscal reporting needs. Developers should prioritize minimal changes to avoid impacting standard processing, test extensions thoroughly using transaction WE19, and document custom elements for ongoing maintenance.

Processing Flows

Outbound Processing

Outbound processing in refers to the generation and transmission of IDocs from a sending system to external partners or other systems via ALE (Application Link Enabling). This process is typically triggered through three main mechanisms: change pointers for changes, output determination using the NAST ( Status) framework for transactional documents, or direct programmatic calls from applications. Change pointers track modifications in tables, such as materials or customers, and a scheduled program like RBDMIDOC evaluates these changes to initiate IDoc creation for specific message types. In contrast, output determination via NAST checks predefined conditions in application documents (e.g., sales orders) and uses the RSNAST00 program to process output records, invoking function modules like IDOC_OUTPUT_ORDERS to prepare the IDoc data. Direct calls, often used in custom developments or ALE scenarios without message control, invoke the MASTER_IDOC_DISTRIBUTE function module to pass application data directly to the IDoc interface. The core steps begin with the application layer retrieving and formatting data from relevant database tables into IDoc segments, adhering to the predefined IDoc type structure. The ALE service layer then assembles the full IDoc by creating the control record (EDIDC) with metadata like IDoc type, message type, sender, and receiver details; populating data records (EDIDD) with the formatted segments; and initializing status records (EDIDS) to track processing stages, starting with status 01 (IDoc generated). The MASTER_IDOC_DISTRIBUTE function module orchestrates this assembly and distribution, generating one or more communication IDocs if serialization or multiple recipients are involved, and updating statuses to 03 (data passed to port) upon successful handoff. Port-specific conversions may occur next, such as transforming the IDoc into a flat file format for non-RFC ports or preparing it for RFC calls, based on configurations in transaction WE21. Transmission occurs asynchronously by default to ensure non-blocking application performance, utilizing transactional RFC (tRFC) for reliable delivery across systems or queued RFC (qRFC) for ordered, guaranteed processing in high-volume scenarios. The IDoc is dispatched via the configured to the , with updates to 30 (ready for dispatch) or 16 ( in dispatch) depending on success. For example, creating a in the (Sales and Distribution) module can trigger an ORDERS IDoc through NAST output determination, where the application data populates segments like E1EDK01 (header) and E1EDP01 (item), which is then distributed to a vendor's EDI via an . This flow ensures and throughout the outbound journey.

Inbound Processing

Inbound processing in SAP systems involves the reception, validation, and integration of IDocs from external sources into the application's database, enabling automated data exchange for business transactions. IDocs arrive through configured inbound ports, such as transactional (tRFC) ports for real-time transfers or file ports for , where the sending system pushes the IDoc data to the receiver. Upon reception, the system stores the IDoc in the database and assigns an initial status of (IDoc added). The inbound function module, determined by the process code in the partner profile ( WE20), is then triggered to handle validation and posting. The core steps of inbound processing begin with a syntax check to verify the IDoc's structural integrity against its defined type, ensuring segments and fields conform to the basic type or extension specifications. If valid, data conversion occurs if required, applying rules to map or transform external data formats to -compatible structures, often using generated conversion programs for fields like dates or currencies. Next, the application update phase posts the processed data to the relevant , typically via a standard function (e.g., IDOC_INPUT_ORDERS for sales orders) or BAPI calls to create or update business objects like purchase orders. Finally, status records are updated to reflect outcomes, such as 53 for successful posting or 51 for application errors, with the function returning the application document number on success. For integration, synchronous inbound processing is available using function modules like IDOC_INBOUND_SYNCHRONOUS, allowing immediate response without queuing, suitable for scenarios requiring instant . To handle high volumes, can be configured using programs like RBDAPP01 with server groups to distribute IDoc loads across multiple dialog work processes for improved throughput. A representative example is the INVOIC02 IDoc type for electronic , where an incoming IDoc from a system undergoes inbound processing to validate invoice details, convert any external qualifiers (e.g., E1EDKA1 segments for partner identification), and post entries to via the IDOC_INPUT_INVOIC_FI function module, updating financial records and generating payment proposals.

Configuration and Integration

Ports and Partner Profiles

In systems, ports serve as the communication endpoints for IDoc transmission, defining the technical method by which IDocs are sent to or received from external systems or partners. Ports are configured using transaction WE21, where administrators select the port type and specify relevant parameters such as directories, destinations, or HTTP settings to enable reliable data exchange. This setup ensures that IDocs are formatted and routed appropriately based on the target system's requirements, supporting both synchronous and asynchronous processing flows. Several port types are available to accommodate different transmission methods. The Transactional (tRFC) port, commonly used for SAP-to-SAP integrations, leverages destinations for guaranteed delivery and error handling in asynchronous scenarios. File ports facilitate exchanges with non-SAP systems by specifying inbound and outbound directories on the operating system, along with file naming conventions and optional triggering mechanisms via shell scripts. XML-HTTP ports enable web-based transmission, supporting content types like text/xml or application/x-sap.idoc, and can incorporate protocols for enhanced compatibility with or cloud services. Security for these ports, particularly tRFC and XML-HTTP types, is managed through associated destinations, which configure via user credentials, Secure Network Communications (SNC), or other secure protocols to protect . Partner profiles, maintained via transaction WE20, establish the logical mappings between business partners—such as logical systems (), vendors (), or customers ()—and specific IDoc message types, ensuring tailored processing for each relationship. These profiles include outbound parameters like the assigned receiver port, packet size (recommended between 10 and 200 IDocs to optimize and avoid overload), output mode (immediate or collected), and the basic or extended IDoc type with segment release versions. Inbound parameters complement this by defining codes for application handling, along with options for syntax checks and error notifications. Permitted agents and rules can also be specified to route workflows or alerts during processing issues. A practical example involves configuring a for (EDI) with an external vendor: in WE21, a named "EDI_FILE" is created with outbound directories for IDoc generation and inbound paths for receipt, secured via . This is then linked in the partner profile (WE20) for partner ID "VENDOR001" (type LI), where outbound parameters set a packet size of 50 IDocs for message type ORDERS, enabling efficient batch transmission without overwhelming the external system.

Message Types and Process Codes

In SAP systems, types serve as logical identifiers for the documents or events exchanged via IDocs, linking the structural definition of an IDoc type (basic or extension) to specific application es. They abstract the underlying , allowing the system to route and IDocs based on semantics rather than technical structure. types are maintained using WE81, where users define short names (up to 3 characters) and descriptions for standard or custom types. Representative examples include ORDERS (used for outbound purchase orders or inbound sales orders) and CREMAS, used for vendor master data distribution; these types ensure that the IDoc content aligns with corresponding SAP modules like or . By associating a type with an IDoc type via WE82, the system establishes a mapping that triggers appropriate inbound or outbound handling during runtime. Process codes provide the functional for executing IDoc processing logic, assigning specific modules to handle inbound or outbound messages tied to a given message type. For inbound processing, transaction WE42 is used to create or maintain process codes, which encapsulate attributes such as the processing type (e.g., direct module call) and error handling routines; each code points to an inbound module that interprets the IDoc and posts it to the application, such as creating orders or updating master records. Transaction WE57 further refines this by assigning the module directly to the combination of message type and IDoc type, ensuring precise execution; for instance, the module IDOC_INPUT_ORDERS processes ORDERS message types arriving via IDocs. Outbound process codes, configured in WE41, similarly link to output modules like IDOC_OUTPUT_ORDERS for generating IDocs from application events. This assignment decouples the from the IDoc interface, allowing modular extensions or customizations without altering core structures. In Application Link Enabling (ALE) scenarios, the distribution model governs the inter-system flow of message types, specifying which messages are distributed between logical systems to avoid unnecessary transmissions. Maintained via transaction BD64, the model consists of views that define sender-receiver relationships, message types, and filters (e.g., by company code or plant); it generates partner profiles automatically and supports filtering to optimize data exchange in distributed landscapes. For example, an administrator might model the ORDERS type to flow outbound from a central system to branch offices, ensuring only relevant purchase orders are sent based on predefined criteria. A practical illustration is the ORDERS message type, which is commonly linked to the ORDERS05 basic IDoc type for structuring customer data and associated with inbound process code ORDE, invoking the IDOC_INPUT_ORDERS function module to create or change sales orders in the receiving system. This integration exemplifies how message types, process codes, and distribution models collaborate to enable seamless, event-driven data interchange across environments.

Transactions and Tools

Monitoring and Display Transactions

Transaction WE02 allows users to display IDocs based on various selection criteria such as , creation date, type, or details, supporting filters for inbound and outbound processing. It provides access to control records (stored in table EDIDC), records (stored in table EDIDD), and records (stored in table EDIDS), enabling detailed inspection of IDoc structure and processing history. For example, users can select an IDoc and drill down into its components to view sender/receiver information, data, and updates. Transaction WE05 functions similarly to WE02, generating lists of IDocs matching specified criteria, such as by direction (inbound or outbound) or time period, and allowing inspection of individual records. It is particularly useful for batch overviews, where users apply filters to retrieve summaries of IDoc volumes or statuses across a range. WE07 provides IDoc statistics and aggregated lists to analyze processing volumes, such as counts by message type, partner, or status over defined periods. This transaction supports volume analysis by displaying metrics like total IDocs processed, success rates, and error distributions, aiding in performance monitoring. BD87 offers a status overview of IDocs with advanced filtering options for errors, specific message types, or partners, allowing users to view and select IDocs for further actions like reprocessing. It groups IDocs by status and direction, providing a consolidated view for inbound and outbound monitoring. SM58 monitors transactional RFC (tRFC) queues, which are critical for IDoc outbound transmission, displaying queued entries with status details like "Transaction Recorded" or errors to identify transmission bottlenecks. ST22 lists ABAP runtime errors and short dumps, useful for investigating IDoc-related failures by filtering dumps associated with IDoc processing functions or modules. These tools can reference error resolution processes, such as analyzing dumps during IDoc handling.

Testing and Development Transactions

The testing and development of IDocs in systems relies on specific transactions that enable the , , , and validation of IDoc structures and processes without impacting environments. These tools are essential for developers to build custom IDoc types, data exchanges, and verify functionality during the phase. Transaction WE19 serves as the primary test tool for both inbound and outbound IDoc . It allows users to create new IDocs manually, copy existing ones as templates, segment data, and the full flow, including reprocessing failed IDocs for purposes. For instance, developers can modify fields, trigger inbound to post data to the application, or test outbound generation from changes, ensuring compatibility before deployment. This transaction supports tests by replicating real-world scenarios, such as invalid data formats, without generating actual transmissions. For developing custom IDoc structures, transactions WE30 and WE31 provide dedicated editors. WE31 is the editor, where developers define individual s by specifying fields, data elements, and their attributes, such as mandatory status or qualifiers; these s form the building blocks of IDocs and are automatically integrated into the upon creation. WE30, the IDoc type editor, enables the assembly of these s into hierarchical basic or extension IDoc types, allowing the specification of sequences, minimum and maximum occurrences, and version dependencies to match requirements. Together, these transactions facilitate the extension of standard IDocs or the creation of entirely new types for bespoke integrations. Transaction WE60 generates comprehensive documentation for IDoc types, aiding in development and . By entering an IDoc type, it produces a detailed report—including segment structures, field descriptions, hierarchy diagrams, and syntax rules—in formats like print or download, which is crucial for understanding complex types during testing or for external partner specifications. This tool ensures that developers can verify the completeness of custom definitions against standard documentation. To test master data distribution specifically, transactions BD10 and BD11 are used for outbound and inbound scenarios, respectively. BD10 triggers the outbound of , such as , by generating IDocs based on selected criteria like material numbers, simulating the ALE () to verify message types and partner profiles without full system replication. BD11 handles inbound testing by processing received IDocs to create or update application documents, like material masters, allowing developers to confirm and posting logic in a controlled manner. These transactions are particularly useful for validating change pointer mechanisms in synchronization.

Output Determination

NAST Overview

NAST, or Output Determination and Control, is a central table in systems that stores output messages generated in response to business events, such as the creation of sales orders or purchase . These messages represent instructions for generating and dispatching document outputs, capturing details like the application object , output type, and processing status. The configuration of NAST relies on several key components, including condition records maintained through transaction NACE, which define the rules for when outputs are triggered based on criteria like document type or customer data. Output types, such as BA00 for confirmations, specify the nature of the output, while control elements determine the (e.g., or ) and timing (e.g., immediate or upon saving the document). NAST primarily manages traditional outputs like printing, faxing, and emailing of business documents, but it is extensible to support electronic formats through custom configurations. In SAP S/4HANA, although a new Output Management framework based on Business Rules Framework plus (BRF+) exists for enhanced output handling, NAST continues to be the primary mechanism for IDoc triggering, supporting both EDI and ALE scenarios where the new framework offers only partial IDoc compatibility. Introduced as a core feature in SAP R/3, it has been integral to modules such as Sales and Distribution (SD) and Materials Management (MM) for controlling document communications across the enterprise. IDocs represent one possible output medium handled via NAST.

IDoc Triggering via NAST

In SAP systems, IDoc triggering via NAST involves configuring output types to link application documents with IDoc messages for electronic data interchange (EDI). This setup is performed using transaction NACE, where an output type (such as ZORD for sales orders) is defined and assigned the program RSNASTED along with the form routine EDI_PROCESSING for transmission medium 6 (EDI). The output type is further associated with a specific IDoc message type (e.g., ORDERS) and basic type (e.g., ORDERS05) via transaction WE82, such as IDOC_OUTPUT_ORDERS. Condition records in transaction NACE or VV11 specify partners, medium 6, and dispatch timing, enabling automatic determination based on document attributes like sales organization or customer. The processing flow begins when an application event, such as saving a business document, triggers output determination, creating an entry in the NAST table if conditions are met. For transmission medium 6, the system calls the RSNASTED program, which executes the EDI_PROCESSING routine to validate the NAST record and invoke the ALE service via the master IDoc distribution function module (MASTER_IDOC_DISTRIBUTE). This generates the outbound IDoc, populates it with document data, and dispatches it to the partner profile defined in WE20, where port and RFC destination settings determine the transmission method. If using ALE distribution, medium A may be selected instead, routing through ALE_PROCESSING in RSNASTED to respect distribution models in BD64. Timing of IDoc generation is controlled by the dispatch time field in NAST condition records, supporting flexible execution. Option 1 enables periodic processing via a scheduled RSNAST00 job that scans NAST for unprocessed entries and delegates EDI cases to RSNASTED; option 3 or 4 triggers immediate execution upon document save, ideal for real-time EDI. This mechanism allows multiple outputs per document, such as simultaneous print and EDI transmissions, by defining multiple condition records for the same output type with varying media or partners. A representative example is processing in transaction VA01, where an output type like ZORD (configured for medium 6 and dispatch time 4) determines upon saving the order, creating a NAST entry that immediately triggers an ORDERS05 IDoc via EDI_PROCESSING. The IDoc carries details to an external partner, facilitating automated order confirmation exchange.

Error Handling

Error Types and Status Codes

IDoc processing in SAP systems employs a standardized set of status codes to indicate the progress and outcome of document handling, with codes ranging from 00 to 99. Outbound IDocs, which are generated and sent from the SAP system, typically use statuses 00-49, while inbound IDocs, received from external systems, use 50-99. These codes help identify the stage at which processing halted or succeeded, particularly in error scenarios. Syntax errors in IDocs arise from structural or formatting issues, such as invalid segments, incorrect hierarchy, or unidentifiable data elements, preventing further processing. For outbound IDocs, status 26 specifically denotes an error during the syntax check, often due to segments that cannot be identified or hierarchical violations in the IDoc . issues, including mismatched field lengths or invalid character sets, can also trigger syntax-related s, sometimes reflected in status 29 for outbound ALE processing where the detects inconsistencies. Inbound syntax errors similarly result in status 60, indicating a in structural validation upon receipt. Application errors occur when the IDoc content is syntactically valid but cannot be posted to the target application due to issues, such as missing or validation failures. A common example is status 51 for inbound IDocs, signaling that the application document was not posted, often because required data like customer records or material details is absent or inconsistent. For outbound scenarios, similar posting issues in the receiving system may manifest as status 40, where the application document is not created. Communication errors involve failures in data transfer mechanisms, such as configuration problems or connection issues. In outbound processing, status 02 indicates an error passing data to the , typically due to misconfigured settings or access denials. 03 marks data successfully passed to the , but subsequent send failures—often from or tRFC problems—may leave the IDoc in this state without advancement. 12 confirms dispatch to the external system, though underlying communication disruptions can prevent confirmation. ALE errors pertain to issues in the Application Link layer, which manages distributed exchange. Status 56 for inbound IDocs signifies that the document was added to the database but contains errors detectable by ALE , such as mismatches or model violations. Additional ALE-related codes include status 65 for inbound errors in processing and status 29 for outbound ALE failures, often linked to or setup problems.

Reprocessing and Resolution

Reprocessing failed IDocs in systems involves identifying errors, correcting underlying issues, and retrying the processing either manually or automatically to ensure successful data exchange. The primary tools for this are transaction BD87, which allows reprocessing based on specific statuses, and WE19, which enables editing of IDoc data before resubmission. These methods focus on inbound and outbound IDocs that have reached error statuses, such as 51 for application errors in inbound processing. The standard process begins with analysis using transactions like WE02 or BD87 to display IDoc details, including status records and error messages, which reveal the failure points. Once the root cause is identified—often through application logs (transaction SLG1) or ABAP runtime errors via ST22—corrections are made to the source data, partner profiles, or application configurations. For manual reprocessing, BD87 is executed by entering the IDoc number, message type, or time range; IDocs are selected and processed directly, updating their status upon success. In WE19, an existing IDoc is copied as a template, edited as needed (e.g., modifying segments), and then submitted for standard inbound or outbound processing to generate a new IDoc instance. Automation enhances efficiency for high-volume environments by scheduling background jobs with standard SAP programs. For inbound IDocs in status 51, program RBDMANIN posts the documents without manual intervention; RBDMANI2 allows manual selection for reprocessing. Outbound IDocs in error (e.g., status 03 transitioning to 12) use RBDMOIND, while RBDAPP01 handles inbound IDocs waiting in status 64. These programs are scheduled via transaction SM36 as periodic jobs, such as hourly runs, to retry failed IDocs automatically. Additionally, integration can trigger alerts as work items for error statuses, notifying users via Business Workflow for prompt resolution. Best practices include regular monitoring with BD87 to prevent backlog accumulation and archiving obsolete error IDocs using program RBDARCHIVE to maintain system performance. should prioritize ST22 for dump details and application logs for contextual errors, ensuring corrections address systemic issues rather than isolated retries.

References

  1. [1]
    IDoc Overview - SAP Help Portal
    Purpose. This document will define what an Idoc is and provide a brief overview on IDoc structures and component parts.
  2. [2]
    IDoc Administration | SAP Help Portal
    IDoc (Intermediate Document) is the standard SAP format for sending messages (transaction data, master data, control data). You can use IDocs to send this data ...
  3. [3]
    SAP IDoc - The most important FACTS! simply explained
    IDoc Versions / Record Types. Current: Release 4.X (= record type 3) since June 1998 with SAP R/3 Enterprise Edition 4.0B Older versions: 3.0, 3.1, 2.0, 2.1 ...
  4. [4]
    IDoc (Intermediate Document) interface connectivity - SAP Help Portal
    An IDoc is an intermediate document that you use to send and receive business documents between your SAP application servers and other servers.
  5. [5]
    IDoc (Intermediate Document) interface connectivity - SAP Help Portal
    An SAP IDoc is a data container that exchanges data using ALE processes, used to send and receive business documents between SAP and other servers.<|control11|><|separator|>
  6. [6]
    IDoc Interface/ALE - SAP Help Portal
    The IDoc interface exchanges business data with an external system. The IDoc interface consists of the definition of a data structure, along with processing ...
  7. [7]
    Integration of Sales and Returns with External Buyers Using IDocs
    IDocs are used for electronic exchange of documents between suppliers and buyers, enabling increased automation and efficiency in sales and returns.
  8. [8]
    ALE,IDOC | SAP Help Portal
    IDOCs uses ALE and EDI to deliver the data to the receiving system. If the data needs to be exchanged between two SAP systems, then IDOC uses ALE technology .
  9. [9]
    Application Link Enabling (ALE) - SAP Help Portal
    Applications are integrated by synchronous and asynchronous communication rather than by a central database. Application Link Enabling has three layers ...
  10. [10]
    https://help.sap.com/docs/SAP_CUSTOMER_RELATIONSHIP_MANAGEMENT/08f9b4a63de3499c9db2c787967e83f1/457feb5368740e5be10000000a174cb4.html
  11. [11]
    Receiving Vendor Confirmations via EDI - SAP Help Portal
    The system checks dates at schedule line level. The confirmed dates are compared with any existing delivery dates from delivery schedule lines of the purchase ...
  12. [12]
    Overview of IDocs - IBM
    Several hundred IDocs are shipped with each SAP R/3 system version 3.0. ALE and EDI interfaces use functionally equivalent IDocs; however, they differ in ...
  13. [13]
    SAP Versions Release and History of Evolution - Stechies
    SAP R/3 Version Releases ; SAP R/3 EnterpriseEdition 3.0, 1995 ; SAP R/3 EnterpriseEdition 4.0B, Jun-1998 ; SAP R/3 EnterpriseEdition 4.3 ; SAP R/3 Enterprise ...
  14. [14]
    Sending IDOC as XML (Outbound API) - SAP Community
    This blog post will give you the overview to use IDOC as XML. Introduction: IDOC is a standard data structure used in SAP applications to transfer data.
  15. [15]
    IDocs in SAP S/4HANA: The Differences to SAP ECC 6.0 - ecosio
    Aug 7, 2025 · IDocs remain the standard format for data exchange in SAP S/4HANA · The IDoc structure has been updated in S/4HANA · The INVOIC02 IDoc has 37 ...Missing: 3.0 | Show results with:3.0
  16. [16]
    Fields in the IDoc Control Record | SAP Help Portal
    ### Summary of IDoc Control Record Fields
  17. [17]
    EDI_DC40: Understand the SAP IDoc Control Record - ecosio
    Aug 7, 2025 · ... EDI_DC40 follows a uniform structure across all IDoc types and is stored for each IDoc in table EDIDC. Before looking in detail at control ...Partner profile · Control record EDI_DC40 · EDI_DC40 for inbound IDocs
  18. [18]
    IDOC STRUCTURE - SAP Help Portal
    This is referred to as the Control record. All control record data is stored in EDIDC table. 2) The Application Data - Which contains the data like employee ...
  19. [19]
    SAP Table EDID4 - IDoc Data Records from 4.0 onwards - LeanX
    EDID4 (IDoc Data Records from 4.0 onwards) is a standard table in SAP R\3 ERP systems. Below you can find the technical details of the fields that make up ...
  20. [20]
    IDoc Basics For Functional Consultants - SAP Community
    Dec 31, 2012 · IDoc is an SAP object that carries data of a business transaction from one system to another in the form of electronic message.
  21. [21]
    reg : IDOC data mapping - SAP Community
    Jun 29, 2007 · The IDoc gets created by an ALE function module moving fields from BAPI structures directly to segment fields of same name.how can IDOC_DATA populated in the Function moduleAIF: Is there a FM/Method to map idoc to bapi - SAP CommunityMore results from community.sap.com
  22. [22]
    How will you get IDOC qualifiers and their actions... - SAP Community
    May 9, 2013 · To get IDOC qualifiers and their actions, we will take example of ORDERS05. Step1: Go to Transaction code WE30. Enter ORDERS05 in the Obj. Name.
  23. [23]
    EDIDS Table in SAP | Status Record (IDoc) Table & Fields List
    A table contains several fields and some of the fields will be key fields. SAP EDIDS Table Fields structure. Field, Note, Data Element, Domain. MANDT, Client ...
  24. [24]
    IDoc Statuses List - SAP Help Portal
    IDoc statuses include successful outbound (03, 12), IDoc being processed (01, 30), ALE errors (02, 04, 05, 25, 29), and inbound errors (51, 56, 60, 61, 63, 65, ...
  25. [25]
    IDoc Types for Inbound Messages (SD) - SAP Help Portal
    Inbound IDoc types include Inquiry (ORDERS01-05), Sales order (ORDERS01-05), Sales order change (ORDCHG ORDERS01-05), Delivery order (DELORD ORDERS03-04), and ...
  26. [26]
    IDOC CREMAS04 for vendor master data - SAP Community
    Feb 6, 2024 · If I map the vendor master XML message to IDOC CREMAS message type CREMAS04, will the IDOC CREMAS04 itself be enough to create or update the vendor master data ...Idoc CREMAS04. E1LFBWM - SAP CommunityDifference between CREMDM04 Idoc and CREMAS04 IdocMore results from community.sap.com
  27. [27]
    SAP IDoc tutorial - SAP Zero to Hero
    Feb 22, 2019 · Basic type present as type of business transaction, there are two types of basic type (Master data and Transaction basic types). Master data
  28. [28]
    EDI SAP IDoc Standard | SAP Message Types List - CData Arc
    Below is a list of commonly used IDoc messages listed with their EDIFACT and X12 counterparts. This list is only a guide and there is no official mapping.
  29. [29]
    IDoc Types and Segment Definitions
    SAP AG has defined several hundred IDoc types and a large number of segment types. A sending program must construct an IDoc of a given type in accordance with ...
  30. [30]
    SAP IDoc Tutorial: Improving Inbound and Outbound Data Exchange
    Sep 14, 2023 · IDocs are based on EDI standards, like ANSI X12 and EDIFACT; IDocs are independent of both sending and receiving systems, whether navigating SAP ...
  31. [31]
    Enhancing a Basic Type | SAP Help Portal
    ### Summary: Enhancing Basic IDoc Types Using WE30
  32. [32]
    Steps to create custom IDOC | SAP Help Portal
    Our first approach will be to understand the transaction FBS1 and identify the mandatory and minimum fields require for posting accruals by transaction FBS1.
  33. [33]
    Version Creation and Release Procedure | SAP Help Portal
    The following development objects in the IDoc interface can be release-specific, that is, they can exist in different versions: Basic types. Enhancements.Missing: independence | Show results with:independence
  34. [34]
    Invoice Idoc: how to integrate tax fields KNA1-STCD1 - STCS5
    Apr 12, 2023 · I am struggeling to include the customer tax fields from KNA1-STCD1 - STCD5 into INVOIC idocs. I would have expected to have them in the standard idoc, but ...Solved: Enhancement for IDOC - SAP CommunityExtended Idoc - User exit for delivery VL01 and Invoice VF01More results from community.sap.com
  35. [35]
    ALE (Application Linking and Enabling) - SAP Help Portal
    The change pointer technique is used to initiate the outbound process automatically when master data is created or changed. A standard program, RBDMIDOC, is ...
  36. [36]
    Message Control (Customer System, Outbound) - SAP Help Portal
    If one of the conditions is met, the system generates the determined message as a new record ("NAST record") in the NAST table, and passes it to the IDoc ...
  37. [37]
    Outbound Processing (SAP Library - IDoc Interface/Electronic Data ...
    Here, the application generates an IDoc which is transferred to the IDoc interface via the function module MASTER_IDOC_DISTRIBUTE. The IDoc interface can ...
  38. [38]
    Process Of idoc creation | SAP Help Portal
    IDocs are usually created in a four step process: · a.retrieving the data · b. converting it to IDoc · c.format, adding a control record · d. delivering the IDoc to ...<|control11|><|separator|>
  39. [39]
    https://help.sap.com/saphelp_snc700_ehp01/helpdata/en/dc/6b7e7943d711d1893e0000e8323c4f/content.htm
  40. [40]
    Configuring the Port and Partner Profile - SAP Help Portal
    To receive the inbound IDocs, you must first define a port and a partner profile. All three interfaces can use the same port and the same partner.
  41. [41]
    Inbound data flow in ALE and inbound Idoc status records
    Here you will see in general terms how Idoc data is handled when it is received from another system for posting to the application tables.
  42. [42]
    Configuring Process codes for Inbound Idocs in SAP - SAP Help Portal
    Steps to configure Inbound Idoc are as below :. At first , we have to create an Inbound function module which will be triggered in the receiving system on ...Missing: official | Show results with:official
  43. [43]
    IDoc Inbound Processing - SAP Help Portal
    To use IDoc inbound processing, you must first perform the following steps: Define or select a file port for transporting the file. Optionally, you can also ...Missing: official | Show results with:official
  44. [44]
    https://help.sap.com/docs/SUPPORT_CONTENT/srm/3362936569.html
  45. [45]
    Implementation of Inbound Processing - SAP Help Portal
    A function module called by the ALE layer to process the inbound IDoc. An SAP Business Workflow task with objects and events for error handling. ALE table ...
  46. [46]
    IDOC_INBOUND_ASYNCHRON...
    Aug 1, 2017 · We are creating an IDOC through a program using the FM 'IDOC_INBOUND_ASYNCHRONOUS'. We are using this because we want the program to continue, without waiting ...sync and asynch processing of incoming idocs - SAP Communityinbound IDOC proceesing with Workflow - SAP CommunityMore results from community.sap.comMissing: synchronous | Show results with:synchronous
  47. [47]
    Increasing performance of idoc inbound processing - SAP Help Portal
    The purpose of this wiki is to help you increase your idoc inbound processing performance through the utilization of certain key reports and parameters.Missing: official | Show results with:official<|control11|><|separator|>
  48. [48]
    Inbound Processing of IDocs Received - SAP Help Portal
    The system first determines an IDoc segment of type E1EDKA1 using the qualifier (E1EDKA1-PARVW)LF (vendor) or RS (invoicing party). The system then determines ...
  49. [49]
    INVOIC IDoc processing of Intercompany billing (IV...
    Apr 25, 2021 · To test the inbound process FM: 'IDOC_INPUT_INVOIC_FI', just use SE19 with Inbound FM and check the box of 'Call in debugging mode'. And do ...
  50. [50]
    Creating Port Definition for SAP Integration Suite, Managed ...
    A port is the communication channel through which IDocs are sent. The port describes the technical link between the sending and receiving systems.
  51. [51]
    File Port Type: Maintaining the Port Definition - SAP Help Portal
    Choose SAP Menu Tools IDoc Interface/ALE Administration Runtime Settings Port Maintenance (WE21). · Position the cursor on File and choose . · Enter the name of ...
  52. [52]
    Maintain Ports in IDoc Processing - SAP Help Portal
    Access the activity using the following transaction: Transaction Code: WE21 · On the Ports in IDoc processing screen, select the Transactional RFC folder in the ...
  53. [53]
    Port Type XML-HTTP Maintaining the Port Definition - SAP Help Portal
    Choose SAP Menu Tools ALE and EDI Administration Runtime Settings Port Maintenance (WE21). Place the cursor on XML-HTTP and choose . Enter a name for the port ...
  54. [54]
    https://help.sap.com/docs/SUPPORT_CONTENT/abap/3353524067.html
  55. [55]
    Creating an Outbound Partner Profile - SAP Help Portal
    ... IDoc Interface/ALE Administration Runtime Settings Partner Agreement (WE20). Position the mouse on your partner in the required partner type node. Choose in ...
  56. [56]
    https://help.sap.com/docs/SAP_NETWEAVER_702/fe1a4b276c551014b24d80fe2b500e38/b134ab1cd8e44562b0fee9524c638cca.html
  57. [57]
    ALE IDOCS - SAP Help Portal
    ALE enables SAP systems to communicate, and IDOCs are the messages exchanged, acting as containers for application data.
  58. [58]
    Creating an Inbound Process Code (SAP Library - SAP Help Portal
    Example: An inbound ORDERS IDoc, containing a customer's purchase order, creates a customer order in the receiving SAP System. Here the application object ...
  59. [59]
    ALE and IDocs - SAP Help Portal
    This is the home page of ALE and IDoc technology. Overview ALE,IDOC: a short introduction to ALE and EDI, followed by a FAQ about IDocs.
  60. [60]
    XI Transaction Codes - SAP Help Portal
    Monitoring. WE02 -> Idoc display. WE05 -> Idoc list. WE07 -> Idoc statistics. SM58 -> QRFC (SOMETIMES idocs coluld not leave the SAP sending system)
  61. [61]
    Monitor IDocs (ALE) - SAP Help Portal
    To monitor the IDoc (ALE message) status, use transaction BD87 ( Select IDocs). To display IDocs, use transaction WE02 ( IDoc List). In case of errors in the ...Missing: WE05 | Show results with:WE05
  62. [62]
    SM58 - Transactional RFC - SAP Help Portal
    Transaction code SM58 is used to check the transactional rfc job logs for whichever chain that are running in the system.
  63. [63]
    ABAP Dump Analysis (ST22) - SAP Help Portal
    ABAP Dump Analysis (ST22) lists ABAP runtime errors and short dumps. Access it via transaction code ST22, and use selection criteria to list errors.Missing: IDoc | Show results with:IDoc
  64. [64]
    Testing Exception Handling - IDoc Interface/ALE - SAP Help Portal
    1. Choose SAP menu → Tools → IDoc Interface/ALE ® Test Environment → Test Tools (WE19). Choose Existing IDoc as the template for the test and enter the number ...
  65. [65]
    IDoc handling by example of classification - SAP Help Portal
    In transaction WE30, several segment types are assigned to the IDoc-type. According to the structure of the data, hierarchical structures can be maintained.
  66. [66]
    Sending IDocs to an External System | SAP Help Portal
    If you have an SAP system available, then you can generate a header file of the IDoc directly from transaction WE60 ( Documentation on IDoc Types). Was ...
  67. [67]
    [PDF] Master Data Governance for Material - SAP Help Portal
    Test creation of IDOC XML. 1. Generate the IDoc-XML for material using the transaction BD10. 2. Check the newly generated IDocs using transaction WE02 or BD87.
  68. [68]
    whats is the use of BD11? - SAP Community
    Jan 8, 2008 · BD11 is used to read the IDOC and creates application document in inbound system both are different in functionality reward for useful inputs.
  69. [69]
    SAP ABAP Transaction Code BD11 (Get Material) - SAP Datasheet ...
    Transaction Code, BD11 ; Transaction Description, Get Material ; Transaction Type ...
  70. [70]
    Output Determination in Inventory Management (IM) - SAP Help Portal
    In the update task the output records from internal table XNAST are written in DB table NAST. Table NAST is linked to table MSEG through the object key.
  71. [71]
    NAST Based Output Management - SAP Help Portal
    A sample output management configuration via the transaction code NACE is as shown below: Create a new output type for Billing Area (V3).
  72. [72]
    Defining Output Types - SAP Help Portal
    The following diagram shows that for order messages the output type BA00 (order confirmation) was defined with condition access (that is to say the message ...
  73. [73]
    Output Condition Records | SAP Help Portal
    Select a particular medium for output. Specify the time at which you would like the output to be sent. Store the language in which you want the documents be ...Missing: NACE | Show results with:NACE
  74. [74]
    Output management in S/4HANA - SAP Community
    17 jul 2024 · NAST is a central component in SAP for managing and controlling the output of documents. It is part of the SAP Output Control framework and is ...
  75. [75]
    Outbound via Message Control | SAP Help Portal
    ### Summary: IDoc Triggering via NAST
  76. [76]
    https://userapps.support.sap.com/sap/support/knowledge/en/3198153
  77. [77]
    Output Processing | SAP Help Portal
    During output determination, the output recipients are determined from the partners listed in the document. In other words, the partner function is used to ...
  78. [78]
    Process Output types through program | SAP Help Portal
    The Message Status Record (table NAST) contains information about when to start processing programs and which parameters are used. When the processing program ...
  79. [79]
    SAP IDoc Status Overview - Output and Input - munich enterprise
    The SAP IDoc status describes the state of an IDoc at a defined time. The status for outbound IDocs has a value range between 01 and 49. The status for incoming ...
  80. [80]
    1813697 - EDI: Syntax error in IDoc (segment cannot be identified)
    IDoc gets the status 26 with the error message: EDI: Syntax error in IDoc (segment cannot be identified) Message no. E0078.
  81. [81]
    3198153 - IDocs in Status 29 with error：Partner profile not active
    IDocs Fail in Status 29. The status text is "EDI: Partner profile not active" Message no. E0333 "Image/data in this KBA is from SAP internal systems, sample ...
  82. [82]
    SAP iDoc Status Codes (Ultimate Guide)
    Mar 7, 2022 · To view iDoc statuses, first go to transaction we02 or we05 and fill in the selection parameters to filter iDocs. Then, go to the status record ...<|control11|><|separator|>
  83. [83]
    2571039 - IDoc in status 51 Application document not posted
    IDOCs are stuck and cannot be processed, example IDOC in status 51 Application document not posted.
  84. [84]
    Log and Traces -Transactions - SAP Help Portal
    a) Can be used to detect and correct errors in our SAP system and its Environment. b) SAP application servers record events and problem in system logs. c) Every ...
  85. [85]
    ST22 - ABAP Runtime Error - SAP Help Portal
    ST22 - ABAP Runtime Error. Transaction code ST22 is used to lists the ABAP dumps generated in the system, we can restrict for a date, user as required.<|control11|><|separator|>