SAP物料主数据表结构详解：MARA/MARC/MARD等透明表速查

做SAP的人迟早要跟物料主数据打交道。不管你是ABAP开发要按物料号捞数据，还是MM顾问在MM01/MM02里配视图，最终回车之后数据落到的都是那一串透明表。我第一次用ST05跟踪一次MM02保存时，看到MARA、MARC、MARD、MBEW、MVKE一大批表被UPDATE，才真正明白物料主记录不是一个“记录”，而是被拆成好几张按组织维度拆开的表。这篇把我这些年查物料主数据表结构的经验整理一下，主要给ABAP开发同学参考，MM模块顾问也可以拿来当字典用。

1. 物料主数据为什么不能塞进一张表里

1.1 数据模型的“组织维度”设计逻辑

很多刚接触SAP的人会疑惑：物料主数据不就一个物料号加一堆属性吗，为什么不在表里存一行完事？这个疑问的根源，是拿关系型数据库的单表思维去套SAP的复杂业务架构。

SAP里物料主数据天然带着多个组织维度。一个物料编号背后，有全局层面的基本数据，比如物料类型、物料组、基本计量单位；有工厂层面的数据，比如MRP类型、安全库存、采购组、生产相关参数；有存储地点层面的数据，比如每个库位的库存数量；还有销售组织层面的数据，比如销售状态、项目类别组、定价组；再加上评估范围层面的会计数据，比如价格控制、标准价、移动平均价。

这些维度组合起来，形成了一棵“物料-工厂-存储地点-销售组织-评估范围”的层级树。如果全部塞进一张表，行数会爆炸不说，权限控制和字段配置也会乱套。比如A工厂的MRP参数和B工厂完全独立，但物料基本数据是共用的，如果硬拼在一行，A工厂的MRP维护人员就得同时面对B工厂的字段。SAP的解法是拆表，让每个组织层级的数据各回各家，再通过物料号把逻辑串起来。

1.2 从MM01的视图看表结构

打开事务码MM01创建物料时，屏幕上出现的是“基本数据”、“工厂数据”、“销售数据”、“采购数据”、“MRP”、“会计”、“成本”等视图。这里要建立第一个关键认知：MM01的“视图”不是数据库视图，而是业务视图；真正落数据的是物理透明表。一个业务视图可能对应一张表，也可能对应多张表。

以最常用的场景为例，我用一张表来对应关系，这是ABAP开发定位表结构时的最基本参照：

这个表我在项目里用了很久，基本覆盖80%的物料主数据开发场景。定位字段时先想清楚“这个字段属于哪个业务视图”，再顺着视图找表，比盲目翻表结构快得多。

1.3 对ABAP开发和MM顾问的实际影响

对ABAP开发来说，理解拆表逻辑最直接的价值是写查询时不漏数据、不多JOIN。比如你要做一张物料库存报表，只知道物料号，但程序里要按工厂过滤，这时候你得先判断MARC有没有这个工厂的记录，再决定去MARD取库存。如果直接拿MARA JOIN MARD，没维护工厂数据的物料会被JOIN掉，数据就少了。

对MM顾问来说，理解表结构有助于配置物料类型和屏幕字段控制。物料类型在配置里决定了哪些视图可选、哪些字段必输，背后就是MARA和MARC上那一串状态字段在起作用。你改了一个物料类型的字段参考，屏幕上显示的东西就会变，因为系统在按配置去控制MARA/MARC字段的可维护属性。

2. 核心透明表结构与关键字段速查

2.1 MARA：一张根表管全局

MARA是物料主数据的根表，一个物料号在MARA里有且只有一条记录。它存的是跨工厂、跨销售组织都共用的基础属性，ABAP报表里只要涉及物料主数据，基本都要先碰这张表。

我挑几个高频字段，按实际使用频率说明：

这里有个经验：MARA虽然有删除标记LVORM，但在很多项目里，物料不会真正物理删除，只会打删除标记。做任何列表输出时，除非业务明确要求，否则都要把MARA-LVORM = 'X'的数据排除掉，否则接口和报表会带出一堆历史垃圾物料。

2.2 MARC：工厂层的“作战参数”

MARC是物料在工厂维度的数据表，主键是MATNR+WERKS。同一物料在不同工厂就是不同行，这是SAP支持多工厂管理的基础。

MARC里存放的字段，用业务话术来说就是“这个物料在这家工厂怎么管”。MRP相关字段全在这张表上，比如：

一个容易踩的坑是：MARC没有库存数量字段。很多人写报表时想在MARC里找库存，找不到。库存数量在MARD（按存储地点）、MCHB（按批次）里。MARC存的是策略和参数，不是数量。分清这一点，能少走很多弯路。

2.3 MARD：库存地点维度的数据

MARD的主键是MATNR+WERKS+LGORT，记录物料在每一个存储地点的库存数量和状态。

字段名比较有规律，前面是库存类型，后面是数量。常见的：

如果你的物料启用了批次管理，情况会复杂一点。启用批次后，实际批次的库存明细在MCHB表里，而MARD中的LABST等字段仍然存在，但会变化。做报表时如果只看MARD，偶尔会出现和MCHB对不上的情况，这时候要判断业务用的是哪一层的数据。标准做法是：启用了批次管理的物料，明细以MCHB为准；没启用批次的，直接用MARD。

另外，MARD不一定每个物料都有记录。一个物料在某个工厂有主记录MARC，但不一定在某个库位有MARD记录；只有维护了存储地点视图，才会有对应行。写程序时不要假设“MARA有记录，MARD一定有记录”。

2.4 MBEW与MVKE：会计与销售的组织化数据

MBEW是物料评估数据表，主键是MATNR+BWKEY（评估范围）+BWTAR（评估类型）。默认情况下，评估范围等于工厂，所以大多数时候你可以把它理解成“工厂+评估类型”维度的会计数据。

MBEW里最重要的几个字段：

做财务集成报表时，评估类BKLAS和价格控制VPRSV是两个必查字段。评估类决定了物料过账时找哪个总账科目，一旦配置错，MM收货过账会直接报错。

MVKE则是销售组织维度的表，主键是MATNR+VKORG+VTWEG。它存的是物料在某个销售组织、分销渠道下的销售参数，比如：

MVKE最常见的使用场景是销售订单创建时找默认的物料定价组和科目分配组。如果你在SD模块做增强，经常要根据VKORG+VTWEG从MVKE取参数。

2.5 三个常用辅助表：MAKT、MARM、MLAN

除了上面四张主表，还有几张表在开发中出镜率极高。

MAKT是物料描述表，主键是MATNR+SPRAS。多语言环境的报表基本都要JOIN它来取物料描述。字段很简单：MAKTX短描述、MAKTX_UC大写短描述。需要注意：描述不只存在于MAKT，MVKE也有一行销售描述，但绝大多数报表取的是MAKT，因为它是全局描述。

MARM是单位换算表，主键是MATNR+MEINH替代单位。字段主要有UMREZ分子、UMREN分母、EANNR条码等。做采购、库存单位换算的程序，必须处理MARM，否则会碰到“基本单位是KG，采购单位是吨”时金额和数量对不上的问题。

MLAN是物料税务数据表，主键是MATNR+ALAND国家/地区+TATYP税种。每个国家可以设置不同的税务类型和税码，做外贸相关报表时可能会用到。

3. ABAP读取物料主数据的实操方法

3.1 用F1+ST05定位任何字段的落表位置

很多新手拿到需求“取物料的某个字段”，第一反应是去SE11翻表。但物料主数据字段太多，几十张表挨个翻效率太低。我的习惯是三步定位：

第一步，打开MM03或MM02，把光标放到目标字段上按F1，然后点“技术信息”，看数据元素和字段名。这个操作能告诉你字段在屏幕上的技术名称，比如要查“物料组”，F1会显示MARA-MATKL；查“MRP类型”，F1会显示MARC-DISMM。

第二步，如果F1返回的是结构名而不是透明表名，说明屏幕字段可能是视图结构，不一定直接对应物理表。这时候再用ST05开启SQL跟踪，在MM02里保存一次数据，ST05会完整显示所有被UPDATE的表和字段。这一招对于搞清屏幕字段最终落在哪张表，比SE11快得多。

第三步，根据ST05的结果，去SE11里打开目标表，用“字段”搜索定位具体字段，看它有没有外键、域、转换例程，再决定SELECT怎么写。

这三步组合下来，基本没有找不到的物料主数据字段。

3.2 典型读取代码与JOIN陷阱

假设业务需求是“按物料号+工厂+存储地点，读取基本数据、工厂数据、库存数量和物料描述”，我一般这么写：

SELECT a~matnr, a~mtart, a~matkl, t~maktx, b~werks, b~dispo, b~dismm, b~eiskz, c~lgort, c~labst, c~insme FROM mara AS a INNER JOIN makt AS t ON t~matnr = a~matnr AND t~spras = @sy-langu INNER JOIN marc AS b ON b~matnr = a~matnr INNER JOIN mard AS c ON c~matnr = b~matnr AND c~werks = b~werks INTO TABLE @DATA(lt_data) WHERE a~matnr IN @s_matnr AND b~werks = @lv_werks AND c~lgort = @lv_lgort.

这段代码有三个关键点：

第一，MAKT一定要用sy-langu过滤，不然一个物料五种语言的描述全出来了。如果报表要在不同语言环境切换，也可以用sy-langu动态取语言。

第二，MARA和MARC的JOIN条件只放MATNR，因为MARC按工厂拆行。如果你在WHERE里写了工厂等于某值，却没用INNER JOIN MARC，而是用LEFT JOIN，会出来一堆工厂不匹配的空行，数据翻倍。

第三，MARD的JOIN必须带上WERKS，因为同一物料在不同工厂不同库位都有独立记录。很多新人在这一步漏掉WERKS条件，造成库存记录重复。

如果输入参数只有物料号，没有工厂，我建议先分开查询：先用MARA和MAKT取基本数据，再按需求单独循环取MARC、MARD、MBEW、MVKE，不要一把梭把所有表JOIN起来。否则物料只要缺了一个工厂记录，整行就丢了。

3.3 用BAPI和BDC读写物料主数据

直接UPDATE透明表修改物料主数据，在任何成熟项目里都是大忌。修改物料主数据优先用BAPI_MATERIAL_SAVEDATA，它支持创建和修改一套接口。

简单示例：

DATA: ls_headdata TYPE bapi_material, lt_return TYPE TABLE OF bapiret2, lt_extension TYPE TABLE OF bapi_te_mara, ls_extension TYPE bapi_te_mara. ls_headdata-material = '10000010'. ls_headdata-industry_sector = 'M'. ls_headdata-matl_type = 'ROH'. ls_headdata-base_uom = 'KG'. ls_headdata-matl_group = '001'. CALL FUNCTION 'BAPI_MATERIAL_SAVEDATA' EXPORTING headdata = ls_headdata TABLES return = lt_return extensionin = lt_extension. CLEAR ls_extension. ls_extension-mara = 'ZZCUSTFIELD'. " 自定义增强字段 ls_extension-value = 'ABC'. APPEND ls_extension TO lt_extension. IF NOT lt_return IS INITIAL. DATA(lv_error) = abap_false. LOOP AT lt_return INTO DATA(ls_return) WHERE type = 'E'. lv_error = abap_true. ENDLOOP. IF lv_error = abap_true. ROLLBACK WORK. ELSE. CALL FUNCTION 'BAPI_TRANSACTION_COMMIT' EXPORTING wait = 'X'. ENDIF. ENDIF.

这里有个细节：BAPI_MATERIAL_SAVEDATA不负责提交，需要再调BAPI_TRANSACTION_COMMIT。调了BAPI不调COMMIT，数据不会进表，但也不会报错，这个坑我见不少人踩过。另外，如果想修改自定义增强字段，可以用EXTENSIONIN传入，但不能直接改BAPI标准结构，这是SAP扩展接口的标准玩法。

BDC更适合批量改屏幕字段，比如用SHDB录制MM02的修改过程，把一批物料循环执行。但BDC不像BAPI有完整的RETURN消息，出错时是隐藏的，需要写日志。建议能用BAPI就用BAPI，BDC只作为BAPI覆盖不足时的补充。

3.4 性能优化和批量处理

物料主数据表是大表，尤其是MARC、MARD，千万级别都很常见。写查询时要注意几点：

第一，避免SELECT *。物料主数据表字段几十上百个，全字段SELECT会把网络传输和内存开销拉爆。明确要哪几个字段就取哪几个。

第二，按主键矩阵查询。物料主数据的查询天然适合用“物料号+工厂+库存地点+销售组织”这种组合做条件，尽量在WHERE里带上主键字段。如果输入物料号范围很大，建议分批处理，比如每500个物料号一个批次，避免单条SQL太重。

第三，能用批量BAPI就不要单条循环。比如从外围系统批量创建物料，用BAPI_MATERIAL_SAVEDATA一条条调，效率极低。更合理的做法是看业务场景，改造成批量数据处理或直接用IDoc接口。

4. 物料主数据增强：加字段、加屏幕、加逻辑

4.1 数据表增强：Append Structure的正确姿势

业务经常要往物料主数据里加自定义字段，比如加一个“物料责任人”、“质检等级”、“产地证明编号”。SAP不支持直接改标准表结构，但允许通过“追加结构”（Append Structure）扩展。

操作路径是SE11，输入表名MARA，点击“附加结构”按钮，创建以Z或Y开头的追加结构，在里面添加自定义字段。这里有几个强制规范：

字段名必须用Z或Y开头，这是SAP命名规范，避免和标准字段冲突。 追加结构只能加字段，不能删改标准字段。 搭建追加结构时，要考虑在哪个组织层级挂载。比如Z字段只有工厂维度有意义，就加到MARC；如果全局字段就加到MARA；如果是销售组织维度就加到MVKE。

很多人误以为给MARA加了追加字段，屏幕上的MM01/MM02就会自动出现输入框。实际上不是这样。数据表增强只解决了“存储”问题，没有解决“界面”问题。要在MM01/MM02/MM03的屏幕上看到并维护这个字段，还需要做屏幕增强。

4.2 MM01/MM02/MM03屏幕增强的基本思路

给物料主数据事务代码加新屏幕，标准的做法是借助增强工具把自定义子屏幕挂到标准事务里。具体路径大致是：

先在函数组里创建一个子屏幕，屏幕里放自定义字段。然后通过事务码SMOD/CMOD或BADI/隐式增强的方式，把这个子屏幕嵌到MM01/MM02/MM03的Tab标签页里。在PBO时把数据从表读出来填充到屏幕字段，在PAI时把屏幕值写回主数据表。

不同版本SAP的增强入口有差异，经典做法是使用BADI或者用户出口，近几年也有S/4HANA里的自定义字段工具。但底层逻辑都一样：屏幕字段要跟表字段之间做数据搬运，搬得不全就是这个字段永远显示不了。

我个人的建议是：屏幕增强这类改动，尽量做成独立的增强项目，并且详细记录增强点和字段映射。因为升级或迁移系统时，这些增强点很容易被覆盖，没有文档的话，回头查起来相当痛苦。

4.3 保存逻辑增强与用户出口注意事项

除了加字段，还经常要在物料保存时做校验。比如“某个工厂创建物料时，物料描述不允许包含特定字符”。这属于保存逻辑增强。

SAP在物料主数据保存流程里提供了增强点，可以通过隐式增强在保存前追加校验。实现时要注意：不要在增强点里写死业务规则，要配置化，否则不同工厂不同物料类型的需求变化会让你改到怀疑人生。

另外，增强一方面要避免把标准程序改坏，另一方面要记得处理报错。如果校验失败，要向用户抛出明确的消息，并且终止保存。这里的返回类型必须是E，不能只打W警告，否则用户能看到提示但还是保存成功，后患无穷。

5. 常见问题排查与避坑实录

5.1 前导零：MATNR的转换例程

物料号在SAP内部存储时有前导零，显示时根据域MATN1自动去掉。比如物料号在数据库里是'000000000100000010'，屏幕上显示是'10000010'。

ABAP程序里最常见的问题是把屏幕输入的物料号直接拿去SELECT，发现查不到，因为没补齐前导零。正确做法是使用转换例程：

DATA: lv_matnr TYPE matnr. lv_matnr = '10000010'. CALL FUNCTION 'CONVERSION_EXIT_MATN1_INPUT' EXPORTING input = lv_matnr IMPORTING output = lv_matnr.

反向显示输出用CONVERSION_EXIT_MATN1_OUTPUT。如果嫌麻烦，直接在SELECT条件里让系统自动处理，比如屏幕字段如果已经定义成MATNR类型，系统会自动转换；但用字符串拼查询条件时，一定要手动调用转换例程。

5.2 “明明有记录却查不到”

这个问题的原因通常有几种：

第一种，JOIN条件错了。前面说了MARC和MARD的组织维度，少带一个WERKS就可能导致数据翻倍或丢失。

第二种，前导零没处理。外部系统传进来的物料号是字符串，不是MATNR类型，SAP不会自动补零，查询自然为空。

第三种，把删除标记数据全过滤了。有时候业务需要看历史物料，你却条件里写了LVORM EQ ''，结果去年打删除标记的物料全消失。问题排查时先看看是不是这个过滤条件多写了。

第四种，看了错误的表。比如税码在MLAN，去MARA里找肯定没有；评估类的某个扩展字段可能在行业扩展表里，不在MBEW主表。这时候就得回到F1+ST05定位法，重新确认落表位置。

5.3 删除标记的三个层级

物料主数据的删除标记要区分清楚，我做报表时候吃过亏。

MARA-LVORM是全局删除标记。置位后，这个物料在所有组织维度都被视为删除。 MARC-LVORM是工厂级删除标记。置位后，只是这个工厂不再使用该物料，其他工厂不受影响。 MARD-LVORM是存储地点级删除标记。置位后，只是这个库位不再使用该物料。

很多时候用户只在MM02里删了某个工厂的物料数据，MARA-LVORM并没有置X。如果报表逻辑只判断MARA-LVORM，就会出现“明明该工厂已经不用这个物料了，报表里还能查出来”的现象。正确的做法是：按组织维度判断，查询MARC时同时检查MARC-LVORM和MARA-LVORM。

5.4 BAPI明明提示成功，数据却没保存

这是一个非常头疼的问题，我排查过好几次，原因基本都是COMMIT没做。BAPI_MATERIAL_SAVEDATA执行成功后会返回消息，但数据还处于“逻辑锁定”的数据库事务中，如果不调用BAPI_TRANSACTION_COMMIT，事务在程序结束时回滚，数据就没了。

另一种情况是BAPI返回了警告或错误，但错误没有按TYPE='E'去判断。有些错误类型是'A'或'X'，只判断E会漏掉。最安全的做法是遍历RETURN表，只要TYPE不是S和I，都当异常处理。

还有一种情况是被增强拦住了。比如保存前校验有未清采购订单或未清生产订单，增强点抛了异常，BAPI返回错误。这时候要去看增强逻辑和错误消息ID，不能盲目重试。

5.5 评估类与科目确定相关的小坑

物料主数据会计视图里的评估类BKLAS，决定了物料过账时去OBYC配置里找哪个总账科目。这个字段选错，MM收货、发料、库存转移都可能报“科目确定错误”。

这里有个ABAP开发容易忽略的点：评估类型（BWTAR）和评估类（BKLAS）是两码事。评估类型是在MBEW上按“分割评估”拆分的，比如外购和自产同一物料，用不同BWTAR区分；而评估类BKLAS决定的是会计科目。有些字段，比如价格控制、标准价，是按BWTAR分开维护的；但评估类可能是全局或按其它维度维护。弄清楚这个区别，做物料成本相关报表时才能取对数据。

如果程序里要取物料成本，建议直接从MBEW取VERPR或STPRS，而不是自己东拼西凑。MBEW里存的是系统维护好的当前价格，直接用它做金额计算最稳。

我在实际项目里最常用的组合还是那套：F1定位字段、ST05看落表、SE11看结构，然后才去写SELECT。刚开始被MARC的MRP字段和MBEW的价格字段绕晕过，后来总结出“视图-组织维度-表”这条链路，再复杂的物料主数据需求也能按图索骥。如果你也在做物料主数据相关开发，强烈建议拿一个不常改动的物料，把MM01里各视图都维护一遍，再用SE16仔细看每张表的记录，配合ST05实操一遍，印象比背十遍文档都深。