SAP Delivery Classes: Deep Dive with Real-World Data Scenarios

Understanding SAP Delivery Classes is fundamental for any SAP professional dealing with data dictionary objects, especially transparent tables. This classification dictates how data in a table behaves during critical system operations like transport, client copy, upgrade, and installation. A correct delivery class ensures data integrity and system stability. Let's delve into what delivery classes are, their types, and a real-world scenario demonstrating their importance.

What are SAP Delivery Classes?

In SAP, a delivery class is an attribute assigned to transparent tables in the ABAP Dictionary. It specifies the type of data stored in the table and, more importantly, controls the table's transportability, behavior during client copy, and how it's treated during system upgrades or installations. It's a crucial setting that defines the lifecycle management of a table's contents.

Types of Delivery Classes and Their Impact

SAP defines several delivery classes, each with specific characteristics:

• A (Application Table): This is the most common type for master data, transaction data, and organizational data. Data in 'A' tables is typically client-specific and owned by the customer. It is fully transportable and copied during client copies by default.
• C (Customizing Table): Used for tables containing customizing data. While technically also application data, 'C' tables are intended for system configuration settings. Their contents are generally transportable and client-specific. They are included in client copies based on customizing settings.
• L (Table for Storing Temporary Data): These tables store temporary data, often created during runtime. Their contents are generally not transported and are usually empty after a client copy. Examples include application logs or worklists.
• G (Customizing Table, Protected against SAP Upgrades): Similar to 'C' tables but with a key difference during upgrades. Data in 'G' tables is protected against being overwritten by SAP during an upgrade or import of a new release. This is vital for customer-specific customizing that should not be affected by standard SAP changes.
• E (Control Table, Protected against SAP Upgrades): These are SAP's own control tables (system tables). Like 'G' tables, their contents are protected during upgrades, ensuring that SAP's standard configurations are preserved. Customers generally don't modify these tables directly.
• S (System Table): Used for SAP system tables that contain crucial control information. Their data is directly maintained by SAP and critical for system functionality. They are generally not transported by customers and handled by SAP during upgrades/installations.
• W (Workload Table): This class is rarely used by customers and is primarily for internal SAP purposes related to workload management.

The choice of delivery class directly influences how your data is treated during system landscapes, ensuring that the right data moves or stays put when needed.

Real Case Scenario: Customizing Table vs. Application Table

Imagine you are developing a custom module in SAP that requires storing two types of data:

1. User-defined status definitions: A list of statuses (e.g., 'New', 'In Progress', 'Completed') that an administrator can configure and maintain. These statuses are part of the system's configuration.
2. Transaction data for a custom approval process: Records detailing each approval request, including requester, date, current status, etc. This is dynamic, transactional data.

Problem:

If you create both tables with delivery class 'A' (Application Table) and transport them from Development (DEV) to Quality (QAS) and then to Production (PRD):

• The status definitions (which are customizing) would be transported with every data transport, potentially overwriting environment-specific settings.
• The transaction data (which should stay within its respective client/system) would also be copied during a full client copy operation, leading to unwanted historical data in target systems or data loss if not handled carefully during refresh.

Solution using Correct Delivery Classes:

To handle this correctly, you would define two transparent tables:

1. For User-defined Status Definitions:

Create table Z_STATUS_DEF with Delivery Class 'C' (Customizing Table).

This ensures:

• Status definitions can be maintained in DEV and properly transported to QAS and PRD using customizing transports.
• During a client copy from PRD to QAS, you can selectively exclude customizing tables if you want to retain QAS-specific customizing, or include them if you want a full configuration refresh.

2. For Transaction Data for Approval Process:

Create table Z_APPROVAL_TRANS with Delivery Class 'A' (Application Table).

This ensures:

• Transaction data generated in PRD stays in PRD.
• During a client copy from PRD to QAS, this data will be copied by default, providing realistic test data, which is often desired for application tables in QA environments. If only configuration is needed, you might perform a profile-based client copy excluding application data.

This distinction is crucial for maintaining a clean and functional SAP landscape.

Code Snippets: Checking and Defining Delivery Class

1. Checking a Table's Delivery Class in SE11

You can easily check the delivery class of any table in transaction SE11 (ABAP Dictionary). Enter the table name and navigate to the "Delivery and Maintenance" tab.

2. Sample ABAP Dictionary Table Definition (Pseudo Code for Illustration)

When you create a table in SE11, you explicitly set the delivery class.

*   Example for a Customizing Table (Z_STATUS_DEF)
*   Transaction: SE11 -> Create Table -> Delivery and Maintenance Tab
*   Delivery Class: C (Customizing Table, data is maintained by customer, transports via Customizing Request)
*   Data Browser/Table View Maint.: Display/Maintenance Allowed (e.g., via SM30)

*   Example for an Application Table (Z_APPROVAL_TRANS)
*   Transaction: SE11 -> Create Table -> Delivery and Maintenance Tab
*   Delivery Class: A (Application Table, data is maintained by end-users, transports via Workbench Request for structure only)
*   Data Browser/Table View Maint.: Display/Maintenance Allowed (e.g., via custom report or program)
        

3. Retrieving Delivery Class Programmatically (ABAP)

You can retrieve the delivery class of a table at runtime using ABAP.

DATA: lv_tablename TYPE tabname,
      ls_dd02l     TYPE dd02l.

lv_tablename = 'Z_APPROVAL_TRANS'. " Replace with your table name

SELECT SINGLE *
  FROM dd02l
  INTO CORRESPONDING FIELDS OF ls_dd02l
  WHERE tabname = lv_tablename.

IF sy-subrc = 0.
  WRITE: / 'Table Name:', ls_dd02l-tabname.
  WRITE: / 'Delivery Class:', ls_dd02l-clbuffer. " CLBUFFER stores the delivery class
ELSE.
  WRITE: / 'Table', lv_tablename, 'not found or no delivery class information.'.
ENDIF.
        

Conclusion

The SAP delivery class is a seemingly small attribute with significant implications for data management and system landscape operations. Choosing the correct delivery class for your custom tables ensures proper data handling during transports, client copies, and upgrades, thereby contributing to the robustness and maintainability of your SAP system. Always consider the nature and lifecycle of the data when defining your table's delivery class.