如何判断SAP对象是否包含主数据或事务数据

Great question! Let’s break down practical, field-independent ways to distinguish these two data types in SAP—no special labeled fields required.

First, Core Definitions to Anchor Your Judgment #

Before diving into criteria, let’s align on the basics:

• Master Data: Static, long-lived reference data that underpins business processes. It’s reused across transactions and rarely changes (only when core attributes like a customer’s address or material’s unit of measure are updated).
• Transaction Data: Dynamic, event-driven data that records specific business activities. It’s created as processes execute, changes frequently tied to process updates, and is often archived after a set retention period.

Key Criteria to Tell Them Apart #

1. Purpose & Usage in Business Processes #

• If the object acts as a reference for creating other objects, it’s master data. For example:
  • A Material Master (MM01) is required to create purchase orders (ME21N) or sales orders (VA01) → master data.
  • A Customer Master (XD01) is referenced in every sales order or invoice sent to that customer → master data.
• If the object records a specific business action or event, it’s transaction data. Examples:
  • Goods Receipt (MIGO) logs when materials are received into stock → transaction data.
  • Billing Document (VF01) records an invoice sent to a customer → transaction data.

2. Change Frequency & Lifespan #

• Master data is updated infrequently. You’ll only see changes when critical attributes need adjustment (e.g., updating a vendor’s payment terms). It’s kept long-term as a foundational record.
• Transaction data is created constantly as business operations run. Even when modified (like updating a sales order quantity), changes tie directly to process tweaks. It’s often archived after months/years once it’s no longer needed for active processes.

3. SAP Standard Table Naming Patterns #

SAP follows consistent table naming conventions that give away data type:

• Master data tables typically start with identifiers like MARA (material general data), KNA1 (customer general data), or LFA1 (vendor general data). These are "header" tables for core reference objects, usually with a single unique key (e.g., MATNR for materials, KUNNR for customers).
• Transaction data tables often start with VBAK (sales order header), EKPO (purchase order item), or MKPF (material document header). They use composite keys (e.g., VBELN + POSNR for sales order items) to uniquely track each transaction line.

4. Transaction Code Context #

Look at the T-code used to maintain the object:

• Master data is managed via "maintenance" T-codes like MM01 (create material), XD01 (create customer), or FK01 (create vendor)—these are for setting up reference data, not executing processes.
• Transaction data is created via process-focused T-codes like VA01 (create sales order), ME21N (create purchase order), or MIGO (goods receipt)—these directly tie to completing a business process step.

Quick Litmus Test #

Stuck on a specific object? Ask yourself:

Is this data defining something that gets reused across transactions, or is it recording a one-time (or repeat) business action?

• If it’s a definition → master data.
• If it’s an action record → transaction data.

内容的提问来源于stack exchange，提问作者Bruno