做SD顧問的朋友應該都遇到過這種場景業(yè)務在VA01里新建了一張銷售訂單倉促保存完就把單據(jù)編號甩給物流到了VL01N做交貨單的時候系統(tǒng)提示找不到裝運點開票前又發(fā)現(xiàn)付款條件沒維護。結果一張訂單來來回回補改交付周期硬生生被拖了兩三天。這種問題在業(yè)務量大的時候尤其惱人——明明錄單時順手填一下就能解決的事偏偏要等到后道環(huán)節(jié)才暴露。SAP其實早就給了標準方案就是配置里這條路徑Sales and Distribution銷售和分銷→ Basic Functions基礎功能→ Log of Incomplete Items未完成項目日志→ Define Incomplete Log也就是定義未完成日志。簡單說它可以給銷售訂單、交貨單、開票憑證這類業(yè)務單據(jù)做一套體檢關鍵字段沒填的時候單據(jù)一保存就提示你、標記你而不是等問題在下一個環(huán)節(jié)爆雷。這篇文章我從業(yè)務原理講到完整配置步驟再分享幾個親測有效的排錯技巧適合正在做SD模塊配置的顧問、實施人員以及被訂單數(shù)據(jù)質(zhì)量折騰夠嗆的流程負責人。1. 未完成項目日志到底在解決什么問題1.1 一個常見業(yè)務場景漏填字段引發(fā)的返工鏈之前有個制造型企業(yè)的項目用戶天天抱怨訂單明明保存了為什么后面不讓交貨。我拉了一批問題訂單做分析發(fā)現(xiàn)大多數(shù)是同一個原因銷售助理錄單時把裝運條件這個字段留空了。訂單保存那會兒系統(tǒng)沒有任何反應但后面物流計劃員做交貨單時系統(tǒng)就是要拿這個字段去決定裝運點和運輸路線。字段為空交貨單自然創(chuàng)建不成功只能回過頭來找銷售改單。這就是典型的錄單時少填一個字段、流程后被放大了好幾倍的返工鏈。類似的問題還發(fā)生在售達方為空、采購訂單號缺失、付款條件未維護這些場景上。與其靠事后溝通和人工提醒不如在數(shù)據(jù)入口就設一道關卡——這正是未完成項目日志Log of Incomplete Items的核心價值在單據(jù)保存或后續(xù)使用前系統(tǒng)按預設規(guī)則檢查關鍵字段發(fā)現(xiàn)缺失就立即標記讓問題在源頭暴露。1.2 功能定位相當于給每張單據(jù)配了一張體檢表拿體檢來打比方會很好理解。未完成日志的配置就是給每類業(yè)務單據(jù)制定一份體檢表先確定查哪個單據(jù)銷售憑證還是交貨單再確定分哪幾個部分查抬頭數(shù)據(jù)、行項目數(shù)據(jù)最后確定每個部分具體查哪些字段客戶、物料、裝運條件。具體到SAP配置里結構從上到下分成四層對象類型Application業(yè)務單據(jù)的大類比如銷售憑證、交貨單、開票憑證。檢查號Check Number一份完整的檢查規(guī)則編號通常以Z開頭自定義。檢查組Group把同一層面的檢查字段歸到一組比如抬頭組、行項目組、裝運組。檢查字段Field組里實際要檢查的字段例如售達方、物料號、付款條件。這個四層結構在后面對應的配置界面里也完全一致。理解了這個模型就明白為什么有些訂單保存后狀態(tài)欄會出現(xiàn)一個未完成的小標記——因為體檢表上至少有一項沒達標。1.3 配置入口與適用范圍配置菜單的標準路徑是IMGProject Reference→ Sales and Distribution銷售和分銷→ Basic Functions基礎功能→ Log of Incomplete Items未完成項目日志→ Define Incomplete Log定義未完成日志習慣用事務代碼的話常見入口是OVL1銷售憑證、OVL2交貨單、OVL3開票憑證不同系統(tǒng)版本略有差異。我個人的習慣是記OVL1因為它跳轉最快如果記不住直接走SPRO導航最穩(wěn)妥。適用范圍上別只盯著銷售訂單。交貨單創(chuàng)建時缺裝運點、開票憑證缺付款方同樣可以通過未完成日志來卡控。尤其SAP S/4HANA項目里這套邏輯和ECC基本相同學會了直接平移使用。2. 配置前的概念熱身與方案選型2.1 三個必懂參數(shù)級別、狀態(tài)組、消息編號真正動手配置之前建議先把三個參數(shù)搞明白否則在界面里會一直犯嘀咕。第一個是級別Level。它決定字段缺失時的嚴重程度。行業(yè)內(nèi)一般按兩類理解一類是錯誤級字段為空時單據(jù)不允許保存或明確提示必須補齊另一類是警告級單據(jù)可以保存但會被標記為未完成。不同版本界面上顯示的編號可能不太一樣關鍵是先分清這種缺失是否影響后續(xù)流程再決定選哪個級別。第二個是狀態(tài)組Status Group。它更像一個分類維度把不同的缺失原因歸到同一組里方便后續(xù)在報表里按組統(tǒng)計、按組篩選。比如001是基礎數(shù)據(jù)缺失002是訂單信息缺失003是發(fā)貨信息缺失。第三個是消息編號Message Number。每個檢查字段可以掛一個消息號消息號在系統(tǒng)消息表里對應一段文本。用戶點開未完成日志的時候看到的缺少客戶采購單號這類提示就是通過消息號取出來的。中文項目里建議把消息文本統(tǒng)一維護成中文否則用戶看到的可能是英文甚至亂碼。2.2 檢查號命名與自定義方案建議不要直接在SAP標準的檢查號上改這是我的第一個建議。標準檢查號隨系統(tǒng)發(fā)布升級或傳輸時容易被覆蓋而且你改了標準內(nèi)容其他顧問根本不知道。自定義檢查號請務必用Z開頭比如ZSD01、ZDEL01一眼就能認出是項目自定義也方便后續(xù)傳輸管理。另外要考慮一個對象類型下是否需要多套檢查方案。比如銷售憑證對象有的公司對標準訂單特別嚴格要求所有關鍵字段都必填對退貨單則寬松很多只查客戶和退貨原因。如果你也有類似需求可以配置多個檢查號在業(yè)務上形成不同單據(jù)類型走不同檢查規(guī)則的效果。標準單據(jù)類型和檢查號的映射規(guī)則可以在配置里進一步關聯(lián)實操中先把檢查號建清楚后面映射就順了。2.3 哪些字段值得放進檢查清單這是整個配置里最見功力的地方不是把所有字段都掛上去就完事。字段掛太多錄單員被各種彈窗搞得心煩意亂效率直線下降掛太少等于形同虛設。我一般建議先拉三張清單對應三個單據(jù)環(huán)節(jié)銷售訂單VA01重點查售達方、送達方、客戶采購單號、付款條件、裝運條件、行項目物料、訂單數(shù)量、要求交貨日期。交貨單VL01N重點查裝運點、裝運條件、接收方、實際交貨數(shù)量、揀配庫存地點。開票憑證VF01重點查付款方、開票數(shù)量、計稅/免稅標記、應收科目。每個清單定好后再按缺了會卡流程還是缺了能補但影響效率來定級別。前者設錯誤級比如售達方為空后面根本沒法走流程后者設警告級比如客戶采購單號后面可以再找業(yè)務補。3. 從IMG到測試閉環(huán)完整配置步驟3.1 第1步進入定義未完成日志界面打開SPRO按路徑找到定義未完成日志或者直接用事務代碼OVL1。進入后看到的界面左側是一棵對象類型樹樹根下有銷售憑證、交貨、開票等節(jié)點。初次看到一個空蕩蕩的列表別慌——你要做的是新增一條檢查規(guī)則而不是在標準規(guī)則上瞎點。我的建議是先把標準規(guī)則看一遍再動手。默認情況下SAP已經(jīng)為這些對象類型預置了檢查規(guī)則里面掛了很多標準字段。讀懂標準規(guī)則比從零開始要快得多也能避免漏掉關鍵的檢查項。3.2 第2步創(chuàng)建檢查號并定義檢查組選中銷售憑證對象類型點新條目輸入檢查號ZSD01填上描述比如銷售訂單完整檢查-自定義保存后就生成了一個空殼檢查號。這個空殼還沒有任何內(nèi)容需要雙擊進入下一層界面去定義檢查組。組是按業(yè)務層面拆的我通常建四個組001 抬頭數(shù)據(jù)Header Data002 行項目數(shù)據(jù)Item Data003 裝運數(shù)據(jù)Shipping Data004 開票數(shù)據(jù)Billing Data每個組創(chuàng)建時注意勾選激活標志。不激活的組相當于沒配檢查不會執(zhí)行。很多顧問在這里踩坑建了組但忘了激活后面怎么測都測不出來。3.3 第3步為組分配字段并設定屬性選中某個組雙擊進入字段分配界面。點新條目后系統(tǒng)會彈出可檢查字段的候選項可以通過搜索幫出來找字段。拿001 抬頭數(shù)據(jù)舉例通?？梢話爝@幾個字段售達方客戶編號級別建議選錯誤級因為這個字段缺失訂單基本屬于無效單?？蛻舨少弳翁柤墑e建議選警告級允許后續(xù)補充。付款條件級別建議選錯誤級開票時依賴很強。國際貿(mào)易條款/貿(mào)易條件視公司業(yè)務定出口業(yè)務建議警告級。給每個字段設定級別之后別忘了分配狀態(tài)組和消息編號。狀態(tài)組按你項目里的統(tǒng)一編碼填消息編號可以先用標準編號后面再統(tǒng)一維護中文文本。行項目組和裝運組、開票組也是同樣的操作。行項目組里物料號設錯誤級交貨日期設警告級裝運組里裝運條件設錯誤級開票組里是否計稅和付款方設錯誤級。全部維護完保存系統(tǒng)會提示納入一個傳輸請求。這個傳輸請求建議同項目其他配置一起走避免零散的請求號污染傳輸隊列。3.4 第4步端到端驗證配置保存只是第一步必須做一輪完整的業(yè)務驗證。我的驗證方法很固定用VA01創(chuàng)建一張銷售訂單故意不填售達方保存看系統(tǒng)反應。再建一張訂單故意不填客戶采購單號保存后看是否提示警告、標記未完成。保存訂單后通過菜單環(huán)境→未完成項目日志打開日志確認缺失的字段被正確列出?；氐絍A02把缺的字段補上再次保存確認未完成狀態(tài)自動消失。如果測試結果完全符合預設級別說明配置成功。如果發(fā)現(xiàn)訂單都保存了狀態(tài)也沒標記那多半不是檢查號的問題而是后面第5章要講的消息開關沒打開。4. 關鍵參數(shù)與業(yè)務邏輯深入解讀4.1 錯誤級與警告級取舍背后是流程策略很多團隊在配置時都喜歡一律設錯誤級覺得越嚴格越好。但上線之后往往被錄單員吐槽下個單跟闖關一樣。這里有一個關鍵認知未完成日志管的是單據(jù)數(shù)據(jù)完整性標記字段狀態(tài)組管的才是屏幕錄入必輸性兩者職責不同。我把級別選擇的策略總結成一句話卡流程的設錯誤級能補單的設警告級。舉個例子售達方缺失意味著不知道客戶是誰后續(xù)所有環(huán)節(jié)都沒法做這個必須錯誤級客戶采購單號缺失倉庫不關心財務也不關心只是采購對賬時可能需要這個設警告級足夠了。把級別當成業(yè)務流程的風險等級來定義而不是IT人員的一刀切常見分歧基本都能化解。另外要注意錯誤級和字段狀態(tài)組的疊加效應。如果一個字段在銷售訂單類型的字段狀態(tài)組里已經(jīng)被設為必輸那即使未完成日志里設的是警告級用戶錄入時仍然會被屏幕攔截。這不是配置沖突而是兩層控制疊加了。跟業(yè)務溝通時要把這兩件事講清楚別讓用戶以為系統(tǒng)出了問題。4.2 狀態(tài)組在報表和批量處理中的價值狀態(tài)組這個參數(shù)容易被忽略因為它不影響用戶操作只影響后續(xù)的數(shù)據(jù)分析視角。但在項目上線后的持續(xù)運維里狀態(tài)組特別有用。假設你設置了三個狀態(tài)組001基礎數(shù)據(jù)、002訂單信息、003發(fā)貨信息。那么運行未完成報表時可以按組匯總一眼看出上周的未完成訂單里80%都是發(fā)貨信息缺失。這個數(shù)據(jù)可以直接指導業(yè)務流程改善——是物流計劃沒做還是裝運條件本身沒定義好。更精準地你還可以用狀態(tài)組做條件篩選把某一類未完成訂單單獨拉出來批量處理不用在一個大列表里翻來翻去找。配置狀態(tài)組的編碼規(guī)則建議項目組內(nèi)統(tǒng)一不要東一個編碼西一個編碼。我一般會在方案文檔里把001/002/003的含義寫清楚讓負責報表開發(fā)的同事后面有據(jù)可依。4.3 消息編號用戶看到的第一手反饋用戶對未完成日志的直觀感受全部來自消息文本。有些項目里消息文本是英文業(yè)務同事打開日志一臉懵然后又把問題丟回IT。為了避免這種情景配置完成后建議順手做一次消息文本核對。具體做法是在事務代碼SE91里找到對應的消息類和消息號檢查消息文本是否準確、有沒有亂碼。如果不滿意可以維護自定義消息文本寫成大白話比如采購訂單號未維護請補充用于后續(xù)采購對賬。用戶看到這樣的提示不用問就知道該干什么。這里分享一個細節(jié)消息文本盡量寫動詞對象原因不要只寫字段缺失四個字。缺失誰都看得出來但缺了有什么影響、該找誰補才是用戶真正需要的信息。5. 常見問題與排錯實錄5.1 配置了檢查字段訂單卻不提示這是被問得最多的一個問題而且90%的情況不是檢查規(guī)則配錯了而是消息開關沒打開。在銷售憑證類型定義VOV4維護里有一個控制不完整日志消息的參數(shù)與其消息顯示方式相關。如果這個參數(shù)的值設成了不顯示消息那么就算你檢查規(guī)則配得再嚴用戶保存訂單時也看不到任何彈窗狀態(tài)欄可能也沒有明顯的標記。排查時按這個順序來確認檢查號已激活、組已激活。確認字段確實分配到了組下面、級別確實保存了。檢查銷售憑證類型里的不完整消息參數(shù)是否允許顯示。重新登錄系統(tǒng)再試排除緩存干擾。5.2 級別是警告級為什么保存還是被攔截前面提到過字段狀態(tài)組和未完成日志是兩套控制邏輯。如果屏幕上的字段狀態(tài)組把某個字段設成了必輸錄單時不填這個字段根本無法保存而警告級只是事后標記兩者疊加就是明明配了警告級還是保存不了的原因。收到這種反饋先別急著懷疑未完成日志配置打開字段狀態(tài)組的配置界面查一下這個字段的必輸屬性。常見的是付款條件這類字段既被業(yè)務要求設為必輸又被未完成日志設了警告級結果誰也沒做錯但用戶感覺很混亂。解決辦法是統(tǒng)一策略字段狀態(tài)組決定錄入時是否強制填寫未完成日志決定保存后是否跟蹤提醒兩個地方不要重復設同一個字段的硬性卡控。5.3 未完成日志里出現(xiàn)了重復或過期數(shù)據(jù)配置調(diào)整是每天都有可能發(fā)生的事但有一個容易被忽略的后果對歷史單據(jù)未完成狀態(tài)不會自動重新計算。比如你今天把內(nèi)部訂單號從警告級升級成了錯誤級歷史訂單如果缺少這個字段并不會立刻全部彈出來只有單據(jù)下一次被修改保存時才可能觸發(fā)重新檢查。如果需要立刻刷新歷史訂單的未完成狀態(tài)可以用標準工具或報表重新采集、重新評估。處理前先把單據(jù)清單導出來看看確認是真實缺數(shù)據(jù)還是配置調(diào)整引入的存量積壓。我見過一個項目上線半年后才集中補一次未完成狀態(tài)結果一堆歷史數(shù)據(jù)冒出來業(yè)務部門差點被嚇到。這種事最好提前跟業(yè)務負責人打招呼做一次集中清理方案。最后再分享幾個實戰(zhàn)體會最近一次給客戶做訂單質(zhì)量優(yōu)化我把重點完全放在了未完成日志上而不是又去搞什么用戶出口。配置本身不到半天就完成了真正花時間的反而是跟業(yè)務團隊一起確定檢查清單和級別的過程。中間有件事印象很深業(yè)務負責人一開始把二十幾個字段全列進了必查清單覺得多查總比漏查強等我把每個字段的缺失后果列在表上一條條過最后真正留下的只有七八個。道理很簡單——檢查功能是給流程護航的不是給錄單增加負擔的。這個小功能建議所有做SD模塊的朋友都認真看一遍標準配置里已有字段你會發(fā)現(xiàn)很多你的業(yè)務場景根本不需要寫增強標準功能已經(jīng)想得很周到了。真正好的配置往往不是搞得多復雜而是把系統(tǒng)的標準功能用到位。