SAP SD销售凭证全解析：从订单到发票的完整链路

刚接触 SAP SD 模块的时候，我最容易犯的错就是把“销售凭证”四个字理解成一张销售订单。实际上，在 SAP 系统里，销售凭证是一个覆盖面非常大的概念，它既包括询价、报价，也包括销售订单、合同、交货单，甚至退货、发票在广义上也跟这套凭证体系挂钩。很多新顾问第一次去客户现场，被业务人员一句“我的销售凭证怎么打不出来”问懵，就是因为没搞清楚销售凭证到底指哪一个层级、哪一类单据。

这篇文章我打算把 SAP 销售凭证从头到尾捋一遍：什么是销售凭证，凭证里分了哪几个层次，从创建订单到交货、开发票，系统背后是怎么串起来的，以及我这些年实际踩过的一些坑。内容偏实操，适合刚做 SD 顾问、企业内部 SAP 运维，以及做系统集成的开发同学参考，看完之后你至少能看懂一张销售订单的数据从哪来、到哪去，也能自己排查一些最常见的凭证问题。

1. 销售凭证到底是什么：三个层级撑起一张单

很多人第一次打开 VA03 看销售订单，都会被屏幕上密密麻麻的页签吓到。其实 SAP 把一张销售凭证拆成了三个业务层级：抬头、行项目、计划行。理解这三个层级，销售凭证就理解了七成。

1.1 抬头、行项目、计划行分别管什么

我给新同事讲这块的时候，喜欢拿点菜打比方：抬头就是这桌宴席的基本信息，比如桌号、请客的人、开席时间；行项目就是菜单上的每一道菜；计划行则是每道菜什么时间端上桌、要准备几份。三层分开管理，业务上才能做到不同粒度、不同控制。

先看抬头层。抬头保存的是整张单据都适用的数据，比如售达方、送达方、付款方、订单类型、销售组织、分销渠道、产品组、订单原因、客户采购订单号、请求交货日期等。这些字段决定了一张单子的“出身”和“基本走向”，同时也是权限、单据流、文本确定的入口。

再看行项目层。每个行项目对应一个具体物料或服务，核心字段包括物料号、数量、单位、价格、工厂、装运点、项目类别、可用性检查组、要货日期等。行项目有一套独立的合作伙伴功能，比如某个物料要送到不同收货方，就是通过行项目里的送达方来控制的。很多业务异常都出在这一层：项目类别不对、工厂没维护、价格取不到。

最后是计划行层。计划行只存在于“需要交货”的项目中，它记录具体交多少、什么日期交、从哪个装运点走。一个行项目可以拆出多个计划行，分批发货在系统里的体现就是计划行拆分。它同时还参与可用性检查、需求传递和交货安排。

我做了个简单的字段对应表，方便收藏：

还有一个容易忽略的点：销售凭证里的客户其实都来自 BP（业务伙伴）。现在新安装的 S/4HANA 系统基本都用 BP 替代了传统的客户主数据。售达方、送达方、付款方这些角色都是从 BP 角色派生出来的。如果你发现某张销售凭证自动带出的送达方不对，先别急着改订单，去查 BP 的角色分配，问题往往出在主数据侧。

1.2 凭证类型与项目类别的选择逻辑

凭证类型是销售凭证的“身份证”。SAP 标准系统里预先配置了很多类型：OR 是标准订单，TA 是询价，QT 是报价，RE 是退货，CR 是贷项凭证，合同也有对应的类型。每类凭证自己的号码段、字段状态、合作伙伴确定过程、文本确定过程和项目类别确定规则都不一样。企业一般会复制标准类型，自定义一套 Z 开头的类型，避免跟标准配置冲突。

项目类别比凭证类型更容易被忽略，但它的重要性一点不低。项目类别决定了一个行项目在后续流程里的“待遇”：标准项目、免费项目、退货项目、文本项目、服务项目等。比如一张销售订单里既卖实物商品，又收运费，运费那一行往往就是单独的项目类别。项目类别错了，后续交货、开票的复制控制可能全错，价格也可能会被当成免费货物处理。

实操中最常见的问题是：凭证类型和项目类别组合不匹配，导致订单保存不了，或者保存了之后不能创建交货单。这种情况下先确认销售凭证类型里维护的“项目类别确定”条目是否覆盖了当前行项目类别，再看复制控制里的交货类型是否配置正确。修改凭证类型不能直接改标准类型，正确做法是复制一个新的 Z 类型，再把业务需要的功能一项项配进去。

2. 创建销售凭证的实务要点：从 VA01 到 ATP

销售凭证的创建入口是 VA01，修改是 VA02，查看是 VA03。这三个事务代码是 SD 顾问的“三件套”，熟练程度基本决定了做事效率。这一章我挑三个最关键的实操点展开：订单录入技巧、可用性检查、定价。

2.1 最常用的三个事务代码和录入技巧

VA01 刚进去会先要求输入订单类型、销售组织、分销渠道、产品组，然后才进入凭证录入界面。这里有个很多人不习惯的地方：这些组织数据一旦保存后是录在凭证里的，不是画面上的临时参数。换销售组织录单，报价单、订单、交货单都要重新选，千万别搞混。

录行项目的时候，很多人喜欢一个个字段敲，效率很低。其实可以用“按参考创建”的功能，从报价单、合同甚至另一张订单直接复制生成。复制的时候可以选择复制抬头和行项目的哪些内容，比如价格、条件记录、文本、合作伙伴都能带过来。运维工作量大时，我一般先教会业务用户用这个功能，起码能省一半录单时间。

还有一个小技巧：如果客户经常把采购订单号写错，导致后续对账对不上，可以在 VA02 里把客户采购订单号字段设置为必输。位置在销售凭证抬头“销售”页签，有些企业的字段状态会自动带出来。字段必输不代表不能改，但能减少一大类“单子存在却找不到采购订单号”的扯皮问题。

为什么不建议随便去 VA02 改历史订单？因为销售凭证一旦参与后续交货、开票，就和交货单、发票形成了单据流。直接改历史数量、价格，后续单据却不会自动跟着变，最后开票数量跟发货数量对不上，账都平不掉。真需要改，应当评估后续单据是否要冲销、是否要重新过账，这个顺序一定不能乱。

2.2 可用性检查（ATP）到底是怎么算的

可用性检查是销售凭证走向执行环节前最关键的一道卡口。它回答一个问题：客户要的数量，你确认能交吗？

SAP 里 ATP（Available to Promise）的计算逻辑并不复杂，核心公式可以理解为：可用量 = 工厂库存中非限制库存 + 计划内的收货数量 - 计划内的发货数量。计划收货包括采购订单、生产订单、计划订单；计划发货包括销售订单、交货单、预留。系统按物料、工厂、可用性检查范围去跑这个逻辑，跑完的结果就展示在订单行项目上。

查看可用性最常用的两个入口是 MD04（库存/需求清单）和 MD07（物料可用性概览）。MD04 偏向逐笔需求来源，MD07 更偏向直观的总量监控。热词里有人提到“sap md07”，其实就是用来做 ATP 汇总和过量承诺判断的。对于有大量订单、经常插单的行业，MD07 基本每天都要看。

最让业务崩溃的一种情况是：明明仓库有货，订单 ATP 却不通过。这种问题九成出在库存类型上。SAP 库存分为非限制使用、质检、冻结等类型，ATP 常规只计算非限制库存。如果一批货还在质检状态，或者还没做 311/321 之类的转储过账，仓库眼里“有货”，系统 ATP 就是不肯认。排查的时候先打开物料主数据的工厂/存储视图确认库存状态，再跑 MB52 对一下数量，基本就清楚了。

如果客户非常着急，销售订单行项目上其实可以临时选择“不检查可用性”。但我通常不建议业务人员轻易这么用，因为一旦跳过检查，交货执行时容易被真实库存打脸。我自己处理紧急插单时，会把“手工确认交货日期”和“可用性检查不通过”两条线同时抛给销售和计划，让他们签字确认后再跳过，避免事后扯皮。

2.3 销售凭证上的价格是怎么来的

销售凭证上的价格不是业务人员手敲出来的，而是系统按定价过程自动算出来的。定价过程由销售凭证类型和客户/物料主数据共同决定，取数的顺序包括：基础价格、客户折扣、物料折扣、运费、税等。

条件记录用 VK11 维护，维护在客户、物料、价格有效期这些维度上。价格维护好之后，新建销售凭证时系统会按“定价日期”取当天的生效条件。VK12 可以很方便地按条件类型看所有有效期内的价格记录，适合做月度批量查询和调价前检查。

有一个经典问题：销售报价单转成订单后，价格变了。先检查条件记录是否被修改过，再查报价单和订单的定价日期是否一致。如果两个凭证跨月，条件记录跨月调整，订单自然会取到新价格。特别提醒：报价单和订单建议一张张对着查，不要批量去改价格，否则后续发票金额和客户确认过的报价对不上，财务会很头疼。

销售凭证里还经常出现“免费货物”——比如买十送一，在行项目上用促销项目类别实现，价格取到的条件记录是免费的。这类行项目虽然价格为 0，但会参与库存和交货数量，开票时也不会生成收入。配置的时候要确保免费项目的定价过程不会意外取到其他价格条件，不然“免费”变“收费”，业务就会出现大问题。

3. 销售凭证的后半程：交货、发货与开票

订单创建完成只是业务的起点。销售凭证要在系统里形成闭环，必须跟交货单、发货过账、开票串起来。这一段单据流，是 SD 和 MM、FI 交互最频繁的地方。

3.1 从销售订单到交货单

交货单的创建入口是 VL01N，输入装运点、装载日期等条件后，系统自动根据订单行项目生成交货项目。交货单和销售订单是两种不同的凭证类型，它们之间靠“复制控制”关联。复制控制决定了创建交货单时，哪些字段从订单带过来，哪些重新计算。

实际业务中，一个销售订单行项目如果数量很大、交期不同，往往会拆成多个交货单。拆的关键在于计划行拆分：一张订单一个计划行数量 100，VL01N 里交货 40，剩下 60 还能再交一次。这个能力很有用，但也带来一个麻烦：订单的已交货数量、未交数量必须分别核对清楚。可以用 VL06O 之类的清单去汇总，否则销售内勤很容易漏交。

如果企业上了 EWM，交货单生成之后还要继续做仓库侧的入库、出库、拣配任务，流程会再多一层。但底层的复制逻辑大同小异，核心还是“销售订单是需求源头，交货单是执行载体”。

再补充一个热词里有人问过的场景：VL02N 进入后，怎么禁用“删除项目”的按钮，或者把它隐藏。这个问题其实涉及权限和屏幕控制两个方面。最简单的方式是给操作人员分配没有删除交货行项目权限的角色，用授权对象“V_VL02N_”配合活动“删除”来控制。要是权限怎么分都分不干净，那就只能做增强，在程序 PBO 里动态修改按钮的激活属性。我自己的经验是：如果只是防止误删，先用权限控制最稳，改程序是最后手段，因为会影响所有用户，而且升级后可能被覆盖。

3.2 发货过账与开票

交货单做好之后，仓库做拣配、发货。VL02N 里输入实际发货数量，过账发货（PGI），系统会生成物料凭证，移动类型一般是 601（发货），库存从这里真正减少。同时生成会计凭证，把销售成本结转出去，这部分成本科目在 FI 那边通过 OBYC 配置。

发货过账前，务必核对“实际发货数量”和订单数量、交货数量是否一致。我听过的翻车案例：仓库过账时把数量多录了一个零，订单还没开票，库存已经穿仓，最后靠一笔红字物料凭证才补救回来。如果物料启用了序列号管理，发货过账时还需要逐条录入序列号，漏录会导致过账不成功，这也是很多制造企业上线后集中爆发的问题。

发货过账后才进入开票环节。VF01 是单张开票，VF04 是集中开票，可以根据交货单、销售订单、甚至退货单生成销售发票。开票过账后，系统确认销售收入、应收账款，同时把会计凭证传到 FI。这里的核心原则是：先发货，后开票。如果订单上有开票冻结（比如信用冻结、价格冻结），要先在对应环节解除冻结，否则 VF01 根本找不到可选单据。

经常有人分不清 SD 发票和 FI 发票。SD 的销售发票由 VF01/VF03 处理，业务含义是给客户开的应收单；FI 那边还有 MIRO 这种供应商发票校验，处理的是应付。热词里提到的“sap 有发票过账凭证但打不开发票号”，如果用户主动说“过账凭证”，那多半是 FI 侧的问题；如果用户说“销售发票打不开”，才往 VF03 和 SD 凭证类型上排查，这个方向别搞反。

3.3 凭证流是什么，为什么排查都要看它

整个销售凭证体系里，我最想让人记住的一个词是“单据流”（Document Flow）。它把同一笔业务从询价、报价、订单、交货、发货、开票，到后续的会计凭证全部串成一条线。VA03 打开一张销售订单，菜单“环境 -> 显示单据流”，就能看到这张订单后面挂了几张交货单、几张发票、各自状态如何。

凭证流在排查问题时的价值非常大。比如客户说“我这张订单没开发票”，不用去列表里翻，看凭证流就知道发票到底有没有生成、是不是已经过账。比如发货单数量跟订单差了一些，凭证流里能看到对应关系。每一笔后续单据都有“完整/不完整”的状态标记，不完整日志会直接提示缺了什么字段，比如缺少装运点、缺少合作伙伴，这些就是单据卡在某个环节的根因。

复制控制和不完整日志经常一起出现。复制控制决定了一张订单能否复制成交货单、能否复制成发票，也决定复制时哪些字段要重新取、哪些字段直接继承。如果某个交货单一直创建不了，首先检查复制控制里的“交货类型”和“项目类别”组合是否存在，然后看不完整日志里报什么错。记住这个排查顺序，能省很多泡论坛找帖子的时间。

4. 常见问题排查与独家避坑

做 SAP 这么多年，我最大的感受是：真正难的不是标准操作，而是系统异常出现后怎么快速定位。这一章整理几个跟销售凭证强相关的典型问题，都是我实际上线、运维时遇到过的。

4.1 销售订单保存不了，或者保存后看不到字段

销售订单保存报错的常见原因有三个维度：主数据、权限、增强。主数据问题集中在客户、物料、价格主数据上，典型报错是“客户 XX 没有为销售区域 XX 定义”，这类问题去 XD01/XD02 补销售范围视图就行。权限问题用事务代码 SU53 查看授权检查失败记录，比在 SUIM 里头猜快得多。增强问题则要看程序执行到哪一步报错，常见的 User Exit 和 BAdI 会写在代码里，运行时看 ST22 短转储，或者打开 SLG1 应用日志看有没有业务异常。

还有一种情况是订单保存成功，但界面上某些字段“消失”了。这通常是字段状态组控制的结果。客户主数据“销售”视图里分配了字段状态组，销售凭证类型又定义了哪些字段可输入、必输或隐藏。如果用户说“这个字段上次还能填，今天填不了了”，先检查是不是主数据被修改了字段状态组，别急着去做程序增强。

4.2 可用性检查与库存对不上的排查思路

前面提过，库存有但 ATP 不过，先看库存类型。这节再补充一个常见坑：销售订单里维护了“可用性检查范围”，但物料主数据 MRP3 视图里的检查规则没配好，系统根本没有对该物料做可用性检查。这种情况下订单数量多少都能过，但到了交货环节才发现库存不足，非常被动。排查方法是：VA03 看行项目“可用性检查”的字段值，再对着物料主数据 MRP3 视图、以及后台“ATP 检查规则”确认检查范围。

还有一种系统层面的坑：物料凭证过账失败后，物料被锁住，导致后续订单保存和交货过账都卡住。热词里有人提到“sap migo 检查导致物料锁定”，这个场景在 MM 侧常见，但 SD 侧也会遇到因为凭证过账失败导致物料锁定的连锁问题。先用事务代码 SM12 查看锁条目，确认哪个用户、哪张凭证持有了锁，处理完异常再释放或等待系统自动释放，不要直接重启服务器，那会把脏锁也带起来。

4.3 发票过账成功，但 VF03 打不开发票号

销售发票过账后，理论上用 VF03 输入发票号就能查看。打不开的原因，我碰到的集中在三类。第一类是凭证类型不对，比如用户拿 FI 的发票号码去 VF03 里查，自然查不到。第二类是权限不足，用户角色里缺少对发票查看的授权，这类问题 SU53 一看就知道。第三类是发票类型或公司代码的号码范围被修改，导致前台界面显示的号码和实际存储不一致，这种情况要查后台“销售凭证 -> 销售支持 -> 发票 -> 定义发票类型”的号码段配置。

如果用户描述里包含“有发票过账凭证但打不开发票号”，那还要多问一句：这个“发票”是销售侧的 VF03，还是采购侧的 MIRO。两个模块处理关系账款，一个管应收一个管应付，弄混了排查方向会走很多弯路。这一点在金税、对账那些场景里尤其重要。

4.4 销售凭证相关的增强与接口

做集成开发的人最关心的是怎么通过接口创建销售凭证。传统方式是用 BAPI_SALESORDER_CREATEFROMDAT2，这个 BAPI 至今仍是外部系统创建标准订单的主流入口。用它的关键是报文结构要完整：抬头数据（SALES_HEADER_IN）、行项目数据（SALES_ITEM_IN）、计划行数据（SALES_SCHEDULE_IN），缺一个都会导致创建失败。调用完成后记得 COMMIT，否则数据过不去。

下面是一个最简的 ABAP 调用片段，方便理解报文结构：

DATA: ls_header LIKE bapisdhd1, lt_items TYPE TABLE OF bapisditm, lt_partner TYPE TABLE OF bapiparnr, lt_return TYPE TABLE OF bapiret2. ls_header-doc_type = 'OR'. ls_header-sales_org = '1000'. ls_header-distr_chan = '01'. ls_header-division = '01'. APPEND INITIAL LINE TO lt_items ASSIGNING FIELD-SYMBOL(<item>). <item>-material = 'MAT0001'. <item>-target_qty = '10'. CALL FUNCTION 'BAPI_SALESORDER_CREATEFROMDAT2' EXPORTING sales_header_in = ls_header * sales_header_inx = ls_header_inx IMPORTING salesdocument = lv_salesdoc TABLES sales_item_in = lt_items return = lt_return. IF sy-subrc = 0 AND NOT lv_salesdoc IS INITIAL. CALL FUNCTION 'BAPI_TRANSACTION_COMMIT'. ENDIF.

这段代码只是骨架，生产环境还要加 header_inx 控制更新范围、错误日志收集、幂等处理等逻辑。特别提醒：外部系统连续调用 BAPI 时报“重复创建”，多半是因为接口没有做重复请求拦截。传进来的客户采购订单号、外部系统订单号等字段，应当先做查重再创建，否则客户侧发一次重试，SAP 里就可能多出几张一模一样的订单。

除了 BAPI，SD 的增强点也是销售凭证扩展的重头。最常用的还是 MV45AFZZ（User Exit，改订单保存前逻辑）和 SD_SALES_DOCUMENT_MAINTAIN（BAdI，比 User Exit 更灵活）。做价格、数量、文本的二次校验时，优先考虑这两个增强点。如果企业已经在往 S/4HANA 和 BTP 方向走，以后更可能用 OData API 来创建和查询销售凭证，但底层的数据结构、凭证状态机基本不变，所以把标准凭证模型吃透，仍然是做接口开发的前提。

我个人带新人时，最后一定会让他们做一件事：找一张真实的销售订单，用 VA03 打开，一行行看抬头、行项目、计划行，看价格构成，再点开凭证流，追到交货单、发票和会计凭证。走通这一遍，销售凭证在你脑子里就不再是一个模糊的概念，而是一张能画出全貌的地图。很多年后你排查问题，靠的就是脑子里这张地图，而不是没完没了的搜索引擎。