做SD顾问的朋友应该都遇到过这种场景：业务在VA01里新建了一张销售订单，仓促保存完就把单据编号甩给物流；到了VL01N做交货单的时候，系统提示找不到装运点，开票前又发现付款条件没维护。结果一张订单来来回回补改，交付周期硬生生被拖了两三天。这种问题在业务量大的时候尤其恼人——明明录单时顺手填一下就能解决的事，偏偏要等到后道环节才暴露。
SAP其实早就给了标准方案，就是配置里这条路径：Sales and Distribution（销售和分销）→ Basic Functions（基础功能）→ Log of Incomplete Items（未完成项目日志）→ Define Incomplete Log，也就是"定义未完成日志"。简单说，它可以给销售订单、交货单、开票凭证这类业务单据做一套"体检"，关键字段没填的时候，单据一保存就提示你、标记你，而不是等问题在下一个环节爆雷。这篇文章我从业务原理讲到完整配置步骤，再分享几个亲测有效的排错技巧，适合正在做SD模块配置的顾问、实施人员，以及被订单数据质量折腾够呛的流程负责人。
1. 未完成项目日志到底在解决什么问题
1.1 一个常见业务场景：漏填字段引发的返工链
之前有个制造型企业的项目，用户天天抱怨"订单明明保存了，为什么后面不让交货"。我拉了一批问题订单做分析，发现大多数是同一个原因：销售助理录单时，把"装运条件"这个字段留空了。订单保存那会儿系统没有任何反应，但后面物流计划员做交货单时，系统就是要拿这个字段去决定装运点和运输路线。字段为空，交货单自然创建不成功，只能回过头来找销售改单。
这就是典型的"录单时少填一个字段、流程后被放大了好几倍"的返工链。类似的问题还发生在售达方为空、采购订单号缺失、付款条件未维护这些场景上。与其靠事后沟通和人工提醒，不如在数据入口就设一道关卡——这正是未完成项目日志（Log of Incomplete Items）的核心价值：在单据保存或后续使用前，系统按预设规则检查关键字段，发现缺失就立即标记，让问题在源头暴露。
1.2 功能定位：相当于给每张单据配了一张体检表
拿体检来打比方会很好理解。未完成日志的配置，就是给每类业务单据制定一份"体检表"：先确定查哪个单据（销售凭证还是交货单），再确定分哪几个部分查（抬头数据、行项目数据），最后确定每个部分具体查哪些字段（客户、物料、装运条件）。
具体到SAP配置里，结构从上到下分成四层：
- 对象类型（Application）：业务单据的大类，比如销售凭证、交货单、开票凭证。
- 检查号（Check Number）：一份完整的检查规则编号，通常以Z开头自定义。
- 检查组（Group）：把同一层面的检查字段归到一组，比如抬头组、行项目组、装运组。
- 检查字段（Field）：组里实际要检查的字段，例如售达方、物料号、付款条件。
这个四层结构在后面对应的配置界面里也完全一致。理解了这个模型，就明白为什么有些订单保存后状态栏会出现一个"未完成"的小标记——因为体检表上至少有一项没达标。
1.3 配置入口与适用范围
配置菜单的标准路径是：
IMG（Project Reference）→ Sales and Distribution（销售和分销）→ Basic Functions（基础功能）→ Log of Incomplete Items（未完成项目日志）→ Define Incomplete Log（定义未完成日志）
习惯用事务代码的话，常见入口是OVL1（销售凭证）、OVL2（交货单）、OVL3（开票凭证），不同系统版本略有差异。我个人的习惯是记OVL1，因为它跳转最快；如果记不住，直接走SPRO导航最稳妥。
适用范围上别只盯着销售订单。交货单创建时缺装运点、开票凭证缺付款方，同样可以通过未完成日志来卡控。尤其SAP S/4HANA项目里，这套逻辑和ECC基本相同，学会了直接平移使用。
2. 配置前的概念热身与方案选型
2.1 三个必懂参数：级别、状态组、消息编号
真正动手配置之前，建议先把三个参数搞明白，否则在界面里会一直犯嘀咕。
第一个是"级别"（Level）。它决定字段缺失时的严重程度。行业内一般按两类理解：一类是错误级，字段为空时单据不允许保存或明确提示必须补齐；另一类是警告级，单据可以保存，但会被标记为未完成。不同版本界面上显示的编号可能不太一样，关键是先分清"这种缺失是否影响后续流程"，再决定选哪个级别。
第二个是"状态组"（Status Group）。它更像一个分类维度，把不同的缺失原因归到同一组里，方便后续在报表里按组统计、按组筛选。比如001是基础数据缺失，002是订单信息缺失，003是发货信息缺失。
第三个是"消息编号"（Message Number）。每个检查字段可以挂一个消息号，消息号在系统消息表里对应一段文本。用户点开未完成日志的时候，看到的"缺少客户采购单号"这类提示，就是通过消息号取出来的。中文项目里建议把消息文本统一维护成中文，否则用户看到的可能是英文甚至乱码。
2.2 检查号命名与自定义方案建议
不要直接在SAP标准的检查号上改，这是我的第一个建议。标准检查号随系统发布，升级或传输时容易被覆盖，而且你改了标准内容，其他顾问根本不知道。自定义检查号请务必用Z开头，比如ZSD01、ZDEL01，一眼就能认出是项目自定义，也方便后续传输管理。
另外要考虑一个对象类型下是否需要多套检查方案。比如销售凭证对象，有的公司对标准订单特别严格，要求所有关键字段都必填；对退货单则宽松很多，只查客户和退货原因。如果你也有类似需求，可以配置多个检查号，在业务上形成"不同单据类型走不同检查规则"的效果。标准单据类型和检查号的映射规则，可以在配置里进一步关联，实操中先把检查号建清楚，后面映射就顺了。
2.3 哪些字段值得放进检查清单
这是整个配置里最见功力的地方，不是把所有字段都挂上去就完事。字段挂太多，录单员被各种弹窗搞得心烦意乱，效率直线下降；挂太少，等于形同虚设。
我一般建议先拉三张清单，对应三个单据环节：
- 销售订单（VA01）重点查：售达方、送达方、客户采购单号、付款条件、装运条件、行项目物料、订单数量、要求交货日期。
- 交货单（VL01N）重点查：装运点、装运条件、接收方、实际交货数量、拣配库存地点。
- 开票凭证（VF01）重点查：付款方、开票数量、计税/免税标记、应收科目。
每个清单定好后，再按"缺了会卡流程"还是"缺了能补但影响效率"来定级别。前者设错误级，比如售达方为空，后面根本没法走流程；后者设警告级，比如客户采购单号，后面可以再找业务补。
3. 从IMG到测试闭环：完整配置步骤
3.1 第1步：进入"定义未完成日志"界面
打开SPRO，按路径找到"定义未完成日志"，或者直接用事务代码OVL1。进入后看到的界面左侧是一棵对象类型树，树根下有销售凭证、交货、开票等节点。初次看到一个空荡荡的列表别慌——你要做的是新增一条检查规则，而不是在标准规则上瞎点。
我的建议是先把标准规则看一遍再动手。默认情况下，SAP已经为这些对象类型预置了检查规则，里面挂了很多标准字段。读懂标准规则，比从零开始要快得多，也能避免漏掉关键的检查项。
3.2 第2步：创建检查号并定义检查组
选中"销售凭证"对象类型，点"新条目"，输入检查号ZSD01，填上描述，比如"销售订单完整检查-自定义"，保存后就生成了一个空壳检查号。
这个空壳还没有任何内容，需要双击进入下一层界面，去定义检查组。组是按业务层面拆的，我通常建四个组：
- 001 抬头数据（Header Data）
- 002 行项目数据（Item Data）
- 003 装运数据（Shipping Data）
- 004 开票数据（Billing Data）
每个组创建时注意勾选"激活"标志。不激活的组相当于没配，检查不会执行。很多顾问在这里踩坑，建了组但忘了激活，后面怎么测都测不出来。
3.3 第3步：为组分配字段并设定属性
选中某个组，双击进入字段分配界面。点"新条目"后，系统会弹出可检查字段的候选项，可以通过搜索帮出来找字段。
拿"001 抬头数据"举例，通常可以挂这几个字段：
- 售达方（客户编号）：级别建议选错误级，因为这个字段缺失，订单基本属于无效单。
- 客户采购单号：级别建议选警告级，允许后续补充。
- 付款条件：级别建议选错误级，开票时依赖很强。
- 国际贸易条款/贸易条件：视公司业务定，出口业务建议警告级。
给每个字段设定级别之后，别忘了分配状态组和消息编号。状态组按你项目里的统一编码填，消息编号可以先用标准编号，后面再统一维护中文文本。
行项目组和装运组、开票组也是同样的操作。行项目组里，物料号设错误级，交货日期设警告级；装运组里，装运条件设错误级；开票组里，是否计税和付款方设错误级。
全部维护完保存，系统会提示纳入一个传输请求。这个传输请求建议同项目其他配置一起走，避免零散的请求号污染传输队列。
3.4 第4步：端到端验证
配置保存只是第一步，必须做一轮完整的业务验证。我的验证方法很固定：
- 用VA01创建一张销售订单，故意不填售达方，保存看系统反应。
- 再建一张订单，故意不填客户采购单号，保存后看是否提示"警告、标记未完成"。
- 保存订单后，通过菜单"环境→未完成项目日志"打开日志，确认缺失的字段被正确列出。
- 回到VA02把缺的字段补上，再次保存，确认未完成状态自动消失。
如果测试结果完全符合预设级别，说明配置成功。如果发现"订单都保存了，状态也没标记"，那多半不是检查号的问题，而是后面第5章要讲的消息开关没打开。
4. 关键参数与业务逻辑深入解读
4.1 错误级与警告级：取舍背后是流程策略
很多团队在配置时都喜欢一律设错误级，觉得越严格越好。但上线之后往往被录单员吐槽"下个单跟闯关一样"。这里有一个关键认知：未完成日志管的是单据数据完整性标记，字段状态组管的才是屏幕录入必输性，两者职责不同。
我把级别选择的策略总结成一句话："卡流程的设错误级，能补单的设警告级"。举个例子：售达方缺失意味着不知道客户是谁，后续所有环节都没法做，这个必须错误级；客户采购单号缺失，仓库不关心，财务也不关心，只是采购对账时可能需要，这个设警告级足够了。把级别当成业务流程的风险等级来定义，而不是IT人员的一刀切，常见分歧基本都能化解。
另外要注意错误级和字段状态组的叠加效应。如果一个字段在销售订单类型的字段状态组里已经被设为"必输"，那即使未完成日志里设的是警告级，用户录入时仍然会被屏幕拦截。这不是配置冲突，而是两层控制叠加了。跟业务沟通时，要把这两件事讲清楚，别让用户以为系统出了问题。
4.2 状态组在报表和批量处理中的价值
状态组这个参数容易被忽略，因为它不影响用户操作，只影响后续的数据分析视角。但在项目上线后的持续运维里，状态组特别有用。
假设你设置了三个状态组：001基础数据、002订单信息、003发货信息。那么运行未完成报表时，可以按组汇总，一眼看出"上周的未完成订单里，80%都是发货信息缺失"。这个数据可以直接指导业务流程改善——是物流计划没做，还是装运条件本身没定义好。更精准地，你还可以用状态组做条件筛选，把某一类未完成订单单独拉出来批量处理，不用在一个大列表里翻来翻去找。
配置状态组的编码规则建议项目组内统一，不要东一个编码西一个编码。我一般会在方案文档里把001/002/003的含义写清楚，让负责报表开发的同事后面有据可依。
4.3 消息编号：用户看到的第一手反馈
用户对未完成日志的直观感受，全部来自消息文本。有些项目里消息文本是英文，业务同事打开日志一脸懵，然后又把问题丢回IT。为了避免这种情景，配置完成后建议顺手做一次消息文本核对。
具体做法是在事务代码SE91里找到对应的消息类和消息号，检查消息文本是否准确、有没有乱码。如果不满意，可以维护自定义消息文本，写成大白话，比如"采购订单号未维护，请补充，用于后续采购对账"。用户看到这样的提示，不用问就知道该干什么。
这里分享一个细节：消息文本尽量写动词+对象+原因，不要只写"字段缺失"四个字。缺失谁都看得出来，但缺了有什么影响、该找谁补，才是用户真正需要的信息。
5. 常见问题与排错实录
5.1 配置了检查字段，订单却不提示
这是被问得最多的一个问题，而且90%的情况不是检查规则配错了，而是"消息开关"没打开。在销售凭证类型定义（VOV4维护）里，有一个控制不完整日志消息的参数，与其"消息显示方式"相关。如果这个参数的值设成了不显示消息，那么就算你检查规则配得再严，用户保存订单时也看不到任何弹窗，状态栏可能也没有明显的标记。
排查时按这个顺序来：
- 确认检查号已激活、组已激活。
- 确认字段确实分配到了组下面、级别确实保存了。
- 检查销售凭证类型里的不完整消息参数是否允许显示。
- 重新登录系统再试，排除缓存干扰。
5.2 级别是警告级，为什么保存还是被拦截
前面提到过，字段状态组和未完成日志是两套控制逻辑。如果屏幕上的字段状态组把某个字段设成了"必输"，录单时不填这个字段，根本无法保存；而警告级只是事后标记，两者叠加就是"明明配了警告级还是保存不了"的原因。
收到这种反馈，先别急着怀疑未完成日志配置，打开字段状态组的配置界面查一下这个字段的必输属性。常见的是"付款条件"这类字段，既被业务要求设为必输，又被未完成日志设了警告级，结果谁也没做错，但用户感觉很混乱。解决办法是统一策略：字段状态组决定录入时是否强制填写，未完成日志决定保存后是否跟踪提醒，两个地方不要重复设同一个字段的硬性卡控。
5.3 未完成日志里出现了重复或过期数据
配置调整是每天都有可能发生的事，但有一个容易被忽略的后果：对历史单据，未完成状态不会自动重新计算。比如你今天把"内部订单号"从警告级升级成了错误级，历史订单如果缺少这个字段，并不会立刻全部弹出来，只有单据下一次被修改保存时才可能触发重新检查。
如果需要立刻刷新历史订单的未完成状态，可以用标准工具或报表重新采集、重新评估。处理前先把单据清单导出来看看，确认是真实缺数据还是配置调整引入的存量积压。我见过一个项目上线半年后才集中补一次未完成状态，结果一堆历史数据冒出来，业务部门差点被吓到。这种事最好提前跟业务负责人打招呼，做一次集中清理方案。
最后再分享几个实战体会
最近一次给客户做订单质量优化，我把重点完全放在了未完成日志上，而不是又去搞什么用户出口。配置本身不到半天就完成了，真正花时间的反而是跟业务团队一起确定检查清单和级别的过程。中间有件事印象很深：业务负责人一开始把二十几个字段全列进了必查清单，觉得多查总比漏查强；等我把每个字段的缺失后果列在表上，一条条过，最后真正留下的只有七八个。道理很简单——检查功能是给流程护航的，不是给录单增加负担的。
这个小功能，建议所有做SD模块的朋友都认真看一遍标准配置里已有字段，你会发现很多你的业务场景根本不需要写增强，标准功能已经想得很周到了。真正好的配置，往往不是搞得多复杂，而是把系统的标准功能用到位。
