1. 未完成项目日志到底在记什么：一个常被忽略的检查机制
在销售与分销（SD）模块里做后台配置的人，几乎都见过这条菜单路径：Sales and Distribution → Basic Functions → Log of Incomplete Items → Define Incompletion Procedure for Sales Documents。翻译过来就是“销售和分销 → 基础功能 → 未完成项目日志 → 定义不完整过程”。很多顾问第一反应是：“哦，就是定义订单保存时的必填字段检查嘛。”实际远不止这么简单。
未完成项目日志（Log of Incomplete Items）的本质，是一套附着在单据上的“完整性状态看板”。用户在 VA01 里创建销售订单，保存时系统会拿后台定义好的检查规则，逐项核对抬头、项目、计划行上的关键字段。缺了什么，就往日志里写一条；单据状态会带上“未完成”标记；后续交货、开票环节也能明显感觉到它的存在。比如你建了一张标准销售订单，但没填“装运条件”，订单照样能保存，可等你去做交货单时，系统可能就提示缺这个字段，单子卡在半路。这就是未完成日志在背后做的事。
这套机制最容易被低估的地方是：它不只是“保存时弹几个提示”，而是订单到现金全链路中一道真实的质量闸门。我见过不少项目，订单执行人员每天早上用事务代码 V.02 拉未完成销售订单清单，哪张缺采购订单号、哪张缺交货日期，一目了然；补完字段再保存，日志里的记录自动清掉，流程继续往下走。所以“定义不完整过程”不是可有可无的后台项，它直接决定了单据能不能顺畅流转，也决定了业务团队有没有一个结构化的工具去做订单质量监控。
这套完整性检查分三条线：销售单据一套过程，外向交货单一套过程，开票单据一套过程。它们结构完全一致，只是检查对象和字段范围不同。标题里这条 IMG 路径对应的就是销售单据这条线，事务代码是 OV56。把这一条线彻底弄懂，另外两条线基本就是照葫芦画瓢。
1.1 从一个真实场景理解它的价值
假设你们公司的业务员创建销售订单时经常不填“客户采购订单号”。在没配置未完成日志的情况下，单子安静地保存了，没人发现异常。等到发货后财务要开票，发现客户账单上的采购订单号对不上，或客户坚持说“我没下过这个单”，才回头翻订单——这时候排查成本已经很高了。
配置了未完成日志之后，同一张订单保存时，系统可能直接给出警告：“客户采购订单号缺失”，并把缺失记录写进日志。单子可以保存，但会出现在 V.02 的未完成清单里。销售内勤每天看这个清单，打电话催业务员补号，问题在发货前就解决了。这个差别，就是“事后救火”和“事中提示”的差别。
1.2 检查对象与三层配置入口
未完成日志检查的对象不是某个孤立字段，而是单据三个层级上的数据：
- 抬头层：比如售达方、客户采购订单号、销售组织、销售渠道等。
- 项目层：比如物料编号、物料描述、交货工厂、装运条件、数量、价格等。
- 计划行层：比如计划交货日期、已确认数量等。
每个层级有各自的业务含义，配置时选错了层级，检查就不会生效，或者会在错误的地方报错。例如“客户采购订单号”通常挂在抬头层，你把它配到项目层，系统检查时找不到对应字段，这条规则等于白配。
三条业务线对应三个配置入口。销售单据入口就是本文标题里的“Define Incompletion Procedure for Sales Documents”，事务代码 OV56；交货单有单独的入口，开票单据也有单独的入口。三者共用同一套设计思想，所以先把销售单据这条线吃透，另外两条只是字段集不同。
2. 先从入口认门：OV56 与配套路径怎么分工
进 SPRO 后台看图，很多人会把“Log of Incomplete Items”下面几个节点搞混，因为名字太像了。这里先把它拆清楚。
2.1 三个配置入口的对应关系
| 配置节点 | 常见事务代码 | 适用范围 |
|---|---|---|
| Define Incompletion Procedure for Sales Documents | OV56 | 销售单据：标准订单、询价、报价、退货等 |
| Define Incompletion Procedure for Deliveries | OV57 | 外向交货单 |
| Define Incompletion Procedure for Billing Documents | OV58 | 开票单据 |
路径前缀都一样，都是“Log of Incomplete Items”节点下，区别只在最后一段说明。配置销售订单时一定选 Sales Documents，别手滑配到 Delivery 那边去了，我见过顾问在项目里把销售订单要检查的字段配到交货单过程里，结果交货单疯狂提示缺物料号，销售订单却什么都没发生。这类问题排查起来很耗时间，因为表面现象五花八门。
2.2 不完整过程怎么跟单据类型绑定
定义了过程不等于生效。销售单据类型配置（事务代码 VOV8，也就是 Define Sales Document Types）里有一个字段叫“未完成过程/Incompletion Procedure”，你要把 OV56 里维护好的过程编号填进去。系统在建单、改单时，按“单据类型 → 不完整过程 → 逐条检查规则”这个链条执行。交货单、开票单据也是同样的绑定逻辑，只不过在各自的单据类型配置界面里。
这里有几个项目习惯建议从一开始就建立：
- 先把三个事务代码和对应的适用范围整理成一张表，发给项目里的业务方和测试人员。很多人分不清“未完成项目日志”到底是订单的还是交货的，给一张对照表能省下不少答疑时间。
- 不要直接修改 SAP 预置的标准过程。标准过程是经过验证的模板，直接改会污染标准配置，也对后续升级和问题排查不利。我习惯复制出一个以 Z 开头的自有过程，在上面调整。
- 配置完一定要去前台验证，而不是只在后台看配置界面。未完成日志最终是给用户用的，V.02 清单、VA02 里的日志入口、VL02N 和 VF02 里的提示，这些界面都要实际走一遍。
提示：销售单据类型配置里“未完成过程”这个字段一旦留空，该类型单据就完全不执行未完成日志检查。有些项目为了图省事，把不常用的单据类型留空，表面是不做检查，实际上是让质量闸门失效。除非业务方明确接受，否则不建议留空。
3. 配置不完整过程的完整动作：复制、拆组、定字段、挂单据类型
进入 OV56 后，第一步是理解这个界面的结构：左边或上面是“不完整过程”清单，每个过程是一个代码加一段描述；双击进入过程后，会看到一排排的配置行，每行代表一条检查规则。整个配置动作可以拆成四步。
3.1 复制标准过程，还是新起炉灶
我的建议是：复制。进入 OV56，选中标准过程（例如系统里针对标准销售订单的那条过程），复制出一个新编号，比如 ZA01，描述写成“标准订单未完成检查（自定义）”。这么做的好处是：标准过程里的组结构、常用字段、需求编号都经过验证，你只需要在复制结果上做加减法，风险小得多。
从空白新建不是不行，但你要对着字段目录一个个查 F4 帮助，还要自己设计组结构，非常容易漏掉关键字段。SAP 的未完成字段目录很大，漏掉“装运条件”“交货工厂”这类基础字段，后续交货环节就会反复出问题。
复制时记得把描述改成项目自己的内容，并放进传输请求（Transport Request）统一管理。很多新手在这步忽略传输，直接在开发机甚至生产机上改配置，要么后续被覆盖，要么完全没有可追溯性，出问题时连“什么时候改的、谁改的”都查不到。
3.2 一列配置行里到底填什么：组、字段、层级、消息类型
进入某条过程的维护界面，你会看到若干列，每一列都对应一个关键决策。我习惯把它们理解成四个问题：
| 配置列 | 要回答的问题 | 说明 |
|---|---|---|
| 组（Group） | 这条检查属于哪个业务域？ | 例如客户信息组、物料信息组、装运信息组。组主要用于日志展示时按业务域归类，也方便配置时查找 |
| 字段（Field） | 检查哪个字段？ | 通过 F4 从字段目录选择，例如 BSTKD（客户采购订单号）、MATNR（物料编号）、VSBED（装运条件） |
| 层级（Level） | 在单据的哪一层检查？ | 通常是抬头、项目、计划行。同一个字段在不同层级含义不同 |
| 消息类型（Message Type） | 字段缺失时给什么反馈？ | 信息、警告、错误等，下文专门讲 |
另外还有一个容易忽略的列：需求（Requirement）。它决定这条检查在什么业务条件下才执行。例如某条需求编号表示“仅当项目类别为 XX 时才检查”，这在有特殊单据场景的项目里特别有用。
看到这里你应该明白，不完整过程本质上是一张规则表。每个字段配不配、配在哪一层、缺了之后给什么反馈、什么情况下才执行，四个问题都答对了，这张配置才是可用的。
3.3 消息类型与需求的选择逻辑
消息类型是整个配置里最需要思考的部分。它大致可以分成几档：
- 仅记录：字段缺失时写入未完成日志，但保存过程完全不打扰用户。适合“最好有但非强制”的信息类字段。
- 信息提示：保存时弹一条信息，单据正常保存，日志记录。
- 警告：保存时弹警告，用户可以忽略并保存，但单据会被标记为未完成。
- 错误：保存时直接阻止，不补字段就存不了单。
有一套简单的取舍逻辑：真正影响下游流程的字段才值得设成错误。缺失后导致交货单建不了、开票建不了、定价算不了，这种字段设错误；只是“业务希望有”但一时拿不到，设警告；纯粹为了以后查询方便，仅记录就够了。你把不该拦的字段设成错误，订单录入效率立刻下降；你把该拦的字段设成信息，问题只是后移到了交货或开票环节，而且更难发现。
需求（Requirement）解决的是“不同场景不同规则”的问题。比如免费赠品订单不需要客户采购订单号，退货订单不需要装运条件，这些差异化需求都应该通过需求条件实现。标准过程里自带的需求编号是有说明的，复制后一定要逐条看一遍，对照你们项目里的单据类型和项目类别配置。不要图省事把需求条件删掉，删掉意味着无条件检查，会误伤特殊业务。
3.4 挂到销售单据类型上才算生效
过程维护完，回到销售单据类型配置（VOV8），找到标准订单类型（通常是 OR），在“未完成过程/Incompletion Procedure”字段填入 ZA01，保存。之后建一张测试订单，故意不填客户采购订单号、不填装运条件、不填计划交货日期，看系统是否按你配置的级别给出提示和日志记录。
一个容易被忽略的动作：每种要用的单据类型都要分别验证，包括退货单、赠品单、询价单、报价单。不同单据类型可能挂接不同的不完整过程，也可能共用同一个过程但业务场景差异很大。你只测标准订单是不够的，至少要给每一类需要管控的单据类型建一条测试数据。
4. 运行那一刻发生了什么：从保存订单到日志落库
配置讲完，把运行侧的完整链路走一遍。很多“为什么我配置了没反应”的问题，都是因为对运行机制理解不透。
4.1 保存时系统做了什么
用户在 VA01/VA02 里录入销售订单，点保存。系统按以下顺序执行不完整检查：
- 根据单据类型找到绑定的不完整过程。
- 逐行读取检查规则。
- 先判断需求条件是否满足。如果不满足，直接跳过这行。
- 如果满足，读取对应层级的字段值。
- 字段为空或不符合要求，则按该行消息类型生成反馈，并写入未完成项目日志。
- 同时在单据状态表里更新“未完成”标志。
这里要特别强调一个容易误解的点：未完成日志不是一张静态的流水表，它是随单据保存、修改动态刷新的。你补上缺失字段再次保存，系统会重新跑一遍完整的检查；满足条件的记录会被自动清掉。所以它更像是单据当前状态的“健康检查报告”，而不是历史记录台账。
4.2 用户怎么看未完成日志：V.02 与单据内查看
日常使用侧有几个查看入口：
- 事务代码 V.02：列出所有未完成销售订单。这是最常用的批量入口，适合销售内勤做每日巡检。选中某行，可以直接跳到 VA02 补字段，也可以先查看具体缺了什么。
- VA02 修改界面中，通过菜单“环境 → 显示未完成日志”（具体菜单位置随系统版本略有差异）打开当前单据的日志。适合单张单据排查。
- 交货单的未完成状态在 VL02N 操作界面中体现，开票单据的未完成状态在 VF02 操作界面中体现，各自也有对应的清单入口。
日志内容本身按组展示，告诉你在哪个业务域、缺哪个字段、消息级别是什么。例如“装运信息组 → 装运条件缺失，警告”。这种结构化的展示，正是你在后台把字段按组分好的直接收益：组设计得好，业务人员看日志时，一眼就能判断问题落在客户信息、物料信息还是装运信息。
4.3 补完字段后的闭环
模拟一次完整闭环：业务人员建标准订单时没填客户采购订单号，保存时系统警告，订单保存成功，V.02 清单里能看到它。打开未完成日志，显示“客户信息组 → 客户采购订单号缺失”。业务人员进入 VA02，填上采购订单号，保存。系统重跑检查，该行通过，日志记录清除。再次打开 V.02，这张单已经不在未完成清单里了。
很多新手会试图去后台表里直接删未完成日志记录，这是完全错误的方向。后台表删了，只要字段还是空的，下次保存又会生成。正确做法永远是补字段，不是删日志。这个认知如果不在项目初期传达到位，后面会有不少人跟你反馈“日志删不掉”“清单一直有脏数据”。
5. 真实项目中遇到的高频坑位和我的配置习惯
最后这部分是纯实战经验。配置手册里一般不会写这些，但你在项目里几乎一定会碰到。
5.1 “错误级别字段”太多会导致什么
我见过不止一个项目，业务方一口气列了二十多个“必填项”，全部设成错误级别。结果订单录入员每保存一张单要面对十几个报错弹窗，录入效率断崖式下降，抱怨四起，最后不得不重新开会把字段降级。教训很直接：错误级别是稀缺资源，能不能设成错误，应该拿“缺失后下游流程会不会断”来衡量，而不是拿“业务觉得这个字段重要”来衡量。
可以做这样一个判定顺序：
- 缺了这个字段，交货单能不能正常创建并过账？
- 缺了这个字段，开票能不能正常创建？
- 缺了这个字段，会不会影响定价、库存可用性、信用检查等核心逻辑？
- 四问都答“不影响”，那它最多设警告或仅记录。
如果字段对下游影响确实很大，但业务暂时就是填不了，我建议保留警告级别，同时把 V.02 未完成清单纳入日常监控。这样既保留质量闸门，又不至于把录入端彻底卡死。
5.2 需求条件被无视的隐患
复制标准过程时，标准行里自带了一些需求条件。很多人复制后不去读需求说明，直接保留或删除。有两个典型场景：
一是某些需求条件限定“仅当项目类别为 XX 时检查”，但你复制后没有对照自己项目的项目类别配置，导致检查在赠品行上误触发。二是你删掉了某条需求条件，变成无条件检查，结果退货单也被迫填客户采购订单号，业务跑来找你“退货单为什么要求填这个”。
正确的做法是上线前把过程里每条需求编号的说明逐条过一遍，对照项目里的单据类型和项目类别清单。如果确实需要新的检查条件，请开发评估在需求例程里做增强，这是扩展未完成日志能力的标准方向。新增条件属于开发工作，要排计划、要测试，别当成普通后台配置随手做。
5.3 固定检查清单
分享一套我每做一个与销售订单相关配置时都会跑一遍的清单：
- 确认每一类销售单据类型都挂接了正确的未完成过程，没有留空。
- 对照业务方给出的“必填字段矩阵”，检查过程里是否覆盖了所有关键字段。
- 明确每个字段的消息级别，与业务方逐条确认哪些是“下游阻断型必填”，哪些是“提醒型建议填写”。
- 用各单据类型分别建测试单据，故意缺字段，验证日志记录和消息反馈符合预期。
- 补全字段再次保存，确认日志清除、未完成清单刷新。
- 查看 V.02 线上清单，确认业务方能看到统一入口。
- 全部配置变更放入传输请求，并在测试环境回归后再搬到生产。
这套清单做完，绝大部分与未完成项目日志相关的返工都能避免。
还有一个日常习惯值得分享
我在项目里都会推荐客户把 V.02 未完成订单清单纳入销售内勤的每日晨会检查项。未完成日志本质上是一个流程质量信号，它不会自己消失，只会等人工补数。每天花十分钟梳理一遍，很多订单卡壳问题都能在交货之前解决，而不是拖到开票环节才炸出来。真正用好了这个配置，业务团队会觉得“这个功能很有用”；用不好，它只会变成一堆没人看的警告弹窗。配置本身不复杂，复杂的是想清楚每一条规则背后，到底想守住哪一道质量关口。
