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