1.诉求

前阵子，公司入职了一名采购同事张三，他来请教我关于SAP系统使用的问题。张三想要知道某家供应商在过去一年中的实际的发货数据，用来分析数据，谈判供应商的年度降价。

许多年前张三用过SAP系统，现在基本都忘记怎么用了，都还给老师了。有人给了他一个事务代码Transaction Code(缩写T-code)的列表，里面包含了许多条指令。张三看得云里雾里的，不知道该怎么用，于是来向我询问如何从系统中获取相关的数据。

其实我也不知道该如何入手，因为我没有这方面的业务需求，也就没有从系统中查询过相关的资料。既然问到我了，我就当作是对自己的一次小测验，看看能否从现有的T-code中找到他想要的数据。

2.思路

当我们想要从系统中获取数据的时候，先要搞清楚具体的需求是什么？以张三的案子为例，他需要的是在一段时间内实际发生的出货数据。首先我们会想到采购订单，是否可以从中找到想要的信息呢？

这是一个思路，可以尝试一下。在SAP的T-code中，代码ME2L是根据供应商查询采购凭证，在输入了供应商号码(vendor number)和时间范围后，系统提供的报表里面并没有我要的数据，这是通过对订单信息的交叉检验后得出的结论。

为什么会这样说？虽然在ME2L的表格中有一个字段是Document date，但是在随机抽查了一个订单后发现，这个日期和实际的发货日期并不相符。在仔细确认后发现，所谓的Document date是创建订单的日期，所以它不是我们想要的信息。

写到这里就要吐槽SAP了，数据库中的一些字段（也叫属性）没有详细的解释说明，只能靠用户自己慢慢摸索。

既然第一条路没有走通，那就要尝试其他的方法了。

3.求解

如果是想要出货的数据，那么可以试试和出货相关的T-code，比如VL06I是用于监控交货情况，还可以查看历史记录，支持对交货单进行筛选和排序。

当我进入了VL06I的界面后，看到了最后一行的List Inbound Deliveries的选项框。

点击进入以后，我们会看到一个许多选择框的界面。对于初次使用的人来说，突然看到许多的选项会感到迷茫，不知道该做些什么。

其实这里是一个筛选场景，我们可以根据自己的需要，设定Filter的条件。例如我们可以选择收货的仓库，也就是Receiving Point(PT)，这里使用了缩写。

SAP在设计属性字段名的时候是不是有些随心所欲了？比如Shipping Point没有用缩写，但是后面的Receiving就缩写了，好像也没有一个统一的标准。

在Time Data这里有Delivery Date的选项，我们可以试着输入想要查询的日期，看看出来的结果是否如我设想的那样，是供应商的发货日期。

另外我们还能输入供应商的信息Vendor，这可以进一步缩小筛选的范围，否则系统会把所有的数据全部拉出来，可能因为内存不足导致报错。为了避免这种情况，我们需要尽可能地提供精确的筛选条件，缩短运算时间，给系统减负。

在缩小了搜索范围后，数据检索的速度明显加快，几秒钟后就能筛选出特定供应商、在某段时间内的发货记录。

需要注意的是，我们需要点击Item Viem来获取完整的信息，包括了订单号（Purch.Doc.）、物料号码（Material）、出货数量（Dlv.qty）和出货日期（Deliv.date）。再一次的，这里的字段用了许多的缩写，如果不清楚某个字段的涵义，需要把光标移动到该字段上方，查看它的完整名称。

仅是知道了字段的名称还不够，我们需要搞清楚它到底是什么意思，因为在不同的数据表中，SAP使用了不同的名称来定义同一个属性。

为什么会发生这种情况？我的猜想是SAP历经了数十年的发展演化，许多的程序员根据自己的理解在设计数据库，所以就形成了现在的情况。

统一这些标准可能会是一个大工程，可能会引起麻烦，而且必要性不是很强。用户在操作了一段时候后，也会摸清楚这里面的门道，仅是增加了一些学习成本，问题不大。

回到案例之中，出货日期（Deliv.date）是否就是我们想要寻找的字段？这需要进一步地验证。

想要了解这点，有一个先决条件和两种可能性。先决条件是ASN，它是供应商在出货以后创建了Advanced Shipping Notice（ASN），如果没有做，我们在VL06I中是无法找到出货的记录的。

上图左数第一个的“Delivery”就是Inbound Delivery Number（The number that uniquely identifies the delivery）。

订单有两种可能性，首先是已经出货的，目前状态是在运输途中。我们可以在事务代码MD04中查看。MD04是一个非常重要的T-code，它是MRP的核心代码，用于实时查看物料的库存、需求及供应信息。

如果我们在MD04中看到了Inbound Delivery Number，就说明该订单目前正在运输途中，是已经出货，但未入库。通常情况下，创建Inbound Delivery Number的日期就是出货日期，因为供应商是在发货以后立即创建ASN的。

其次是已经出货的，并且已经入库。如果我们在MD04中没有看到Inbound Delivery Number，大概率该订单是已经入库了。完成收货以后的订单是不会出现在MD04界面上的。

此时，我们可以在查询收货的T-code，比如MB51中核对订单号、物料号码和数量，确认该订单是否已经入库。我们可以核对供应商的发货资料和日期，确认VL06I中的出货日期（Deliv.date）与实际出货日期是否相符。

在完成了对以上两种情况的确认后，我们能确信出货日期（Deliv.date）就是供应商的实际出货的日期。当我们对SAP中的字段名称和背后的计算逻辑有疑问时，需要验证假设。

有人可能会说了，“遇到不懂的时候，直接问别人不是更快嘛”。这样的确是省事，同样也失去了自己探索系统的乐趣，要知道“师父领进门，修行在个人”。许多时候我们就是在学习摸索中成长，提高自己对于系统底层逻辑的理解。

总结一下，只要敢探索，SAP也没那么复杂。张三的SAP查询案例，恰是大多数人面对系统时的缩影 —— 手握T-code列表却无从下手，习惯性依赖“有人教”。

但恰恰是“没人教”的困境，成了探索SAP的最佳起点：从明确查询数据的需求，到“试错”、转向其他方法，再到验证结果，每一步摸索都在拆解SAP的“复杂表象”。

SAP的字段缩写不统一、历史迭代留下的逻辑差异，或许会增加初期学习成本，但这并非不可逾越的门槛。就像案例中，即便没有相关业务经验，通过“定需求→试路径→验结果”的思路，依然能找到解决方案。

而这个过程中收获的，远不止“拿到数据”—— 更会摸清 SAP“按业务场景设计功能”的底层逻辑，理解字段背后的业务含义，比如 ASN与入库状态的关联。

不管是什么ERP系统，它们的运行逻辑都不复杂，只需要花点时间搞懂就可以。我看到一些用户不敢上手尝试，默认系统上线时的参数都是对的，没有自己的理解。

这样做计划无异于刻舟求剑，很难保证最后的结果是正确的。“怕出错”、“没人带”可能是经常遇到的情况，这也绝不是不会使用系统的藉口。毕竟，SAP的价值从不是“等着别人教”，而是在自己的摸索中，逐渐成为能驾驭系统的问题解决者。

阅读原文：点击这里