簡(jiǎn)介SAP 后勤模塊顧問(wèn)經(jīng)常面臨 STO 跨公司轉(zhuǎn)儲(chǔ)場(chǎng)景中手工操作多、易遺漏的問(wèn)題。這份配置文檔圍繞采購(gòu)訂單下達(dá)后的自動(dòng)化鏈路展開(kāi)依次講解自動(dòng)創(chuàng)建交貨單、VL02N 發(fā)貨過(guò)賬、MIGO 收貨、VF01 銷售開(kāi)票及 MIRO 采購(gòu)發(fā)票的完整配置方法并補(bǔ)充 BRF 消息輸出等 S/4 專用設(shè)置。全篇以配置路徑和事務(wù)碼為主線配有大量操作截圖同時(shí)給出易錯(cuò)點(diǎn)提示例如自動(dòng)發(fā)貨前需確認(rèn)庫(kù)存地點(diǎn)并取消手工揀配以及運(yùn)行 WS_MONITOR_OUTB_DEL_GDSI 檢查選擇參數(shù)是否正確。文檔為單一 doc 文件整體 17.76MB正文約六十頁(yè)結(jié)構(gòu)按業(yè)務(wù)場(chǎng)景逐步拆解從企業(yè)間客戶與供應(yīng)商綁定、交貨類型與可用性檢查、內(nèi)向交貨單自動(dòng)創(chuàng)建到開(kāi)票復(fù)制控制和 IDOC 參數(shù)設(shè)置均有覆蓋便于按目錄定位查閱。已有 1299 人學(xué)習(xí)下載適合 SAP 項(xiàng)目顧問(wèn)和實(shí)施人員在配置階段直接參考。1. STO 自動(dòng)觸發(fā)交貨單一套配置讓公司間轉(zhuǎn)儲(chǔ)從下單到發(fā)票全自動(dòng)SAP 里做 STOStock Transport Order庫(kù)存轉(zhuǎn)儲(chǔ)訂單最煩的不是建訂單而是訂單之后那一串動(dòng)作交貨單要手動(dòng) VL10B 生成、發(fā)運(yùn)要手動(dòng) VL02N 過(guò)賬、收貨要手動(dòng) MIGO、開(kāi)票還得 VF01 和 MIRO 各來(lái)一遍。這套「STO 自動(dòng)觸發(fā)交貨單、發(fā)貨、收貨、銷售/采購(gòu)發(fā)票」配置文檔就是把這幾步全部按事件驅(qū)動(dòng)串起來(lái)——采購(gòu)訂單保存的瞬間系統(tǒng)自動(dòng)創(chuàng)建交貨單交貨單過(guò)賬后自動(dòng)觸發(fā)收貨和公司間發(fā)票。它解決的是多工廠、跨公司轉(zhuǎn)儲(chǔ)場(chǎng)景下的重復(fù)手工操作問(wèn)題適合正在做 S/4 或 ECC 公司間業(yè)務(wù)、被 VL10B/VL02N/MIGO 輪番轟炸的 SD、MM 顧問(wèn)和后勤運(yùn)維。配置路徑、截圖、參數(shù)文件都在這份 60 頁(yè)的文檔里照著做能從下單到發(fā)票零手工干預(yù)。2. 自動(dòng)交貨單的觸發(fā)鏈路裝運(yùn)工廠綁定、BP 設(shè)置與 VL10CUC 參數(shù)要理解這套自動(dòng)觸發(fā)機(jī)制先得把 STO 的業(yè)務(wù)模型拆清楚。文檔里描述的場(chǎng)景是1600 公司下的 1600 工廠向 1310 公司下的 1310 工廠采購(gòu)而 1310 工廠在 1600 公司眼里是「內(nèi)部供應(yīng)商」1600 工廠在 1310 公司眼里是「內(nèi)部客戶」。這個(gè)雙向身份關(guān)系是整個(gè)自動(dòng)化配置的地基。很多項(xiàng)目翻車不是后面的交貨類型沒(méi)配好而是這個(gè)雙邊綁定一開(kāi)始就漏了。2.1 先搞清主數(shù)據(jù)內(nèi)部供應(yīng)商、內(nèi)部客戶、裝運(yùn)工廠三張表采購(gòu)訂單一下系統(tǒng)要自動(dòng)判斷「誰(shuí)來(lái)發(fā)貨」和「發(fā)給誰(shuí)」靠的不是訂單抬頭里的文本而是三個(gè)后臺(tái)設(shè)置裝運(yùn)工廠信息、供應(yīng)商綁定、客戶綁定。文檔第 3-7 頁(yè)給的配置路徑非常明確定義裝運(yùn)工廠信息把工廠與客戶綁定再在 BP業(yè)務(wù)伙伴里維護(hù) 1310 這個(gè)供應(yīng)商把供應(yīng)商與工廠綁定。這句話翻譯成實(shí)施動(dòng)作就是兩件事。第一件事在后臺(tái)找「定義裝運(yùn)工廠信息」把 1310 工廠維護(hù)成裝運(yùn)工廠同時(shí)指定它對(duì)應(yīng)的內(nèi)部客戶是 1600。這樣 1310 工廠做銷售交貨時(shí)系統(tǒng)才知道收貨方是誰(shuí)。第二件事在 BP 事務(wù)代碼里打開(kāi) 1310 供應(yīng)商主數(shù)據(jù)把采購(gòu)組織 1310 的數(shù)據(jù)補(bǔ)全并將其綁定到 1600 工廠的采購(gòu)視圖下。實(shí)際操作中我一般會(huì)優(yōu)先檢查 BP 的「客戶/供應(yīng)商」角色是否同時(shí)存在因?yàn)?STO 里同一個(gè)工廠代碼在兩邊公司下扮演的角色不同——在 1310 下它是供應(yīng)商在 1600 下它是客戶。很多配置看起來(lái)都做了但角色漏了自動(dòng)交貨單就是出不來(lái)。2.2 按工廠配置交貨類型和可用性檢查過(guò)程主數(shù)據(jù)綁定只是基礎(chǔ)接下來(lái)是關(guān)鍵的后臺(tái)配置按工廠配置交貨類型和可用性檢查過(guò)程。這里的邏輯是——不同工廠可能用不同的交貨類型比如普通 STO 用 NLCC退貨用 NLCR而交貨類型又決定了可用性檢查ATP怎么做。文檔里給出的配置路徑在第 8 頁(yè)核心是把交貨類型和工廠維度綁定并指定可用性檢查規(guī)則。注意一點(diǎn)配置更改后只會(huì)對(duì)新建的 STO 采購(gòu)訂單產(chǎn)生影響已經(jīng)存在的采購(gòu)訂單不會(huì)自動(dòng)創(chuàng)建必須手工執(zhí)行 VL10B。這是文檔開(kāi)頭就標(biāo)注的注意點(diǎn)也是最容易踩的坑——改完配置拿舊訂單測(cè)試發(fā)現(xiàn)問(wèn)題「沒(méi)生效」其實(shí)是訂單創(chuàng)建時(shí)間早于配置激活時(shí)間。可用性檢查過(guò)程這里建議按「公司間轉(zhuǎn)儲(chǔ)」的需求單獨(dú)建一個(gè)過(guò)程不要直接復(fù)制標(biāo)準(zhǔn)交貨的檢查規(guī)則。因?yàn)楣鹃g轉(zhuǎn)儲(chǔ)不涉及外部客戶的需求沖減檢查范圍、檢查規(guī)則都要按內(nèi)部轉(zhuǎn)儲(chǔ)來(lái)定否則容易出現(xiàn)明明有庫(kù)存卻不允許交貨的假性缺貨。2.3 VL10CUC 參數(shù)文件與 STOA 的設(shè)置細(xì)節(jié)自動(dòng)創(chuàng)建交貨單的執(zhí)行動(dòng)作在事務(wù)碼 VL10CUC。這個(gè)事務(wù)碼的特點(diǎn)是它不像 VL10B 那樣每次手工跑選擇屏幕而是可以掛一個(gè)后臺(tái)參數(shù)文件按需調(diào)度?！窩UC」的含義就是 Customer/Supplier 的庫(kù)存轉(zhuǎn)儲(chǔ)單創(chuàng)建它專門為 STO 場(chǎng)景準(zhǔn)備的。文檔第 10 頁(yè)特別提醒對(duì) STOA 參數(shù)文件設(shè)置時(shí)請(qǐng)勿勾選「地理路線」和「批量 ATP 檢查處于活動(dòng)狀態(tài)」這兩個(gè)選項(xiàng)。這是個(gè)非常具體的避坑點(diǎn)。地理路線勾選后系統(tǒng)會(huì)嘗試按運(yùn)輸路線確定發(fā)貨工廠但公司間轉(zhuǎn)儲(chǔ)的場(chǎng)景里路線往往沒(méi)維護(hù)反而導(dǎo)致交貨單創(chuàng)建被卡住批量 ATP 檢查勾選后創(chuàng)建交貨單時(shí)要做批量可用性檢查數(shù)據(jù)量大時(shí)性能會(huì)明顯惡化而且 STO 場(chǎng)景下收貨工廠的庫(kù)存本來(lái)就不該參與沖減邏輯。我這里補(bǔ)一下常規(guī)做法參數(shù)文件的「處理類型」一般選「后臺(tái)」這樣才能掛到 Job 里定時(shí)跑「創(chuàng)建交貨單」的選擇標(biāo)準(zhǔn)里一定要把采購(gòu)憑證類型比如 Z016和工廠1310寫進(jìn)去防止誤創(chuàng)建其他采購(gòu)訂單的交貨單。如果運(yùn)行后提示沒(méi)有選擇的交貨單可以直接運(yùn)行程序 WS_MONITOR_OUTB_DEL_GDSI 檢查選擇參數(shù)是否有誤——這是文檔給出的排查路徑實(shí)際中這個(gè)程序非常有用它能直接看到系統(tǒng)按當(dāng)前選擇參數(shù)到底會(huì)不會(huì)挑出交貨單。2.4 設(shè)置完成后的驗(yàn)證順序配置做完驗(yàn)證順序要按「創(chuàng)建訂單 → 查 VL10CUC 日志 → 查交貨單 → 查可用性檢查」來(lái)走。驗(yàn)證步驟事務(wù)碼/程序預(yù)期結(jié)果創(chuàng)建 STO 采購(gòu)訂單ME21N保存成功無(wú)報(bào)錯(cuò)后臺(tái)調(diào)度 VL10CUCSM36 / VL10CUC 參數(shù)文件日志顯示交貨單已創(chuàng)建查看外向交貨單VL03N交貨單存在行項(xiàng)目齊全檢查可用性檢查結(jié)果VL03N → 可用性概覽無(wú)假性缺貨這里有個(gè)血淚經(jīng)驗(yàn)不要一上來(lái)就用 ME21N 建訂單然后等后臺(tái) Job。第一次驗(yàn)證時(shí)前臺(tái)上手跑一次 VL10CUC選擇參數(shù)、執(zhí)行、看日志確認(rèn)沒(méi)問(wèn)題再掛 Job。否則 Job 跑錯(cuò)了日志又不直觀排查時(shí)間翻倍。3. 發(fā)貨與收貨自動(dòng)化VL23 變式調(diào)度與 MIGO 自動(dòng)收貨配置交貨單自動(dòng)創(chuàng)建只是第一步。如果交貨單創(chuàng)建完還得人工 VL02N 過(guò)賬那自動(dòng)化只做了一半。文檔第 12 頁(yè)開(kāi)始講的就是這個(gè)環(huán)節(jié)用 VL23 創(chuàng)建及修改變式按需定期執(zhí)行實(shí)現(xiàn)自動(dòng)發(fā)貨過(guò)賬發(fā)貨過(guò)賬后再讓 1600 工廠自動(dòng) MIGO 收貨。3.1 自動(dòng)發(fā)貨過(guò)賬的前提自動(dòng)確認(rèn)發(fā)運(yùn)的庫(kù)存地點(diǎn)與取消手工揀配文檔里有一句非常關(guān)鍵的備注自動(dòng)過(guò)賬需要交貨單中能自動(dòng)確認(rèn)發(fā)運(yùn)的庫(kù)存地點(diǎn)并取消手工揀配設(shè)置。這句話信息量很大。「自動(dòng)確認(rèn)發(fā)運(yùn)的庫(kù)存地點(diǎn)」意味著交貨單里的行項(xiàng)目必須能在后臺(tái)自動(dòng)確定發(fā)貨庫(kù)存地點(diǎn)的庫(kù)存。如果 1310 工廠發(fā)運(yùn)庫(kù)存地沒(méi)有維護(hù)在后臺(tái)的庫(kù)存地點(diǎn)確定規(guī)則里VL23 跑到最后會(huì)卡在「無(wú)庫(kù)存地點(diǎn)確定」這一步過(guò)賬失敗?！溉∠止湓O(shè)置」更重要。如果交貨單行項(xiàng)目還掛著揀配需求Pick/Pack 環(huán)節(jié)沒(méi)有設(shè)為自動(dòng)VL23 過(guò)賬時(shí)會(huì)提示揀配未完成直接中斷。對(duì)于 STO 這種不涉及實(shí)際揀貨的自動(dòng)化場(chǎng)景我一般會(huì)在交貨類型的「揀配/包裝」控制里直接跳過(guò)揀配步驟或者把揀配類型設(shè)為空。這一步漏了VL23 的 Job 看起來(lái)在跑第二天一看日志全是錯(cuò)誤。3.2 VL23 創(chuàng)建變式與后臺(tái)調(diào)度執(zhí)行 T-codeVL23創(chuàng)建及修改變式。這里說(shuō)的變式Variant就是選擇屏幕參數(shù)的快照。需要設(shè)置的參數(shù)包括銷售組織為 1310、交貨單類型為 NLCC、以及你要過(guò)賬的交貨單范圍。VL23 變式參數(shù)推薦值說(shuō)明銷售組織1310必須是發(fā)貨工廠所屬的銷售組織交貨類型NLCC與第 2 章配置的交貨類型一致交貨單范圍按需建議按日期防止歷史交貨單被重復(fù)過(guò)賬過(guò)賬日期當(dāng)天批量過(guò)賬時(shí)統(tǒng)一記賬日期變式保存后用 SM36 建后臺(tái) Job把 VL23 掛在里面定時(shí)跑。調(diào)度頻率一般按業(yè)務(wù)節(jié)奏來(lái)如果每天有多批采購(gòu)訂單生成建議每小時(shí)跑一次如果業(yè)務(wù)集中在下班后處理那就晚上跑一次。跑完之后一定去看 Job 的 Joblog確認(rèn)過(guò)賬數(shù)和失敗數(shù)。這里還有一個(gè)細(xì)節(jié)VL23 不是「一次跑完就不管了」它會(huì)反復(fù)處理所有符合條件的交貨單。如果一張交貨單過(guò)賬失敗下次 Job 還會(huì)再嘗試處理它所以失敗原因必須及時(shí)排掉否則這張單會(huì)被反復(fù)「翻車」并刷屏日志。3.3 發(fā)貨后自動(dòng) MIGO 收貨憑證類型、一步過(guò)程、交貨不足限度文檔第 15 頁(yè)的配置路徑是分配憑證類型、一步過(guò)程、交貨不足限度。這一節(jié)很短但三個(gè)詞每個(gè)都是坑?！阜峙鋺{證類型」指的是收貨的憑證類型Movement Type 對(duì)應(yīng)的憑證類型。STO 收貨一般用 101 移動(dòng)類型對(duì)應(yīng)的憑證類型要匹配公司間轉(zhuǎn)儲(chǔ)的業(yè)務(wù)——不能把普通的收貨憑證類型直接套在這里否則后續(xù)的自動(dòng)發(fā)票會(huì)找不到對(duì)應(yīng)的收貨記錄?！敢徊竭^(guò)程」指的是收貨采用一步法GR 一步過(guò)賬不拆分到不同的庫(kù)存狀態(tài)。對(duì) STO 來(lái)說(shuō)一步過(guò)程最直接——收貨即入庫(kù)可用庫(kù)存直接增加。如果用兩步法收貨后還有質(zhì)檢庫(kù)存等狀態(tài)轉(zhuǎn)換自動(dòng)發(fā)票的憑證流會(huì)斷掉?！附回洸蛔阆薅取故莻€(gè)容易被忽略的容差設(shè)置。交貨單過(guò)賬數(shù)量如果小于采購(gòu)訂單數(shù)量系統(tǒng)允許的差異范圍是多少。自動(dòng) MIGO 收貨時(shí)如果數(shù)量差異超過(guò)這個(gè)限度收貨會(huì)被系統(tǒng)攔下。常見(jiàn)做法是設(shè)一個(gè)寬松的容差如 10% 或按金額避免因?yàn)闇愓町悓?dǎo)致收貨中斷。但注意采購(gòu)訂單里如果勾選了「完全交貨」指示收貨會(huì)在最后一次交貨時(shí)校驗(yàn)總量是否等于訂單量代收容差管不了這個(gè)。4. 公司間發(fā)票自動(dòng)化VF01 復(fù)制控制、定價(jià)來(lái)源與 MIRO交貨單過(guò)賬、收貨完成接下來(lái)是財(cái)務(wù)最關(guān)心的環(huán)節(jié)發(fā)票。STO 的業(yè)務(wù)里有兩張發(fā)票——1310 工廠開(kāi)給 1600 工廠的銷售發(fā)票VF01以及 1600 工廠收到的采購(gòu)發(fā)票MIRO。文檔第 16 頁(yè)開(kāi)始講的就是這兩張發(fā)票的自動(dòng)觸發(fā)。4.1 公司間開(kāi)票類型定義輸出過(guò)程和輸出類型是重災(zāi)區(qū)文檔原文強(qiáng)調(diào)定義公司間開(kāi)票類型時(shí)標(biāo)注紅色的參數(shù)都很重要特別是輸出過(guò)程和輸出類型。這句話里的「輸出過(guò)程」和「輸出類型」直接決定了 VF01 之后系統(tǒng)怎么把發(fā)票送給對(duì)方——是用 IDOC 發(fā)給采購(gòu)方公司還是只生成一張本地票據(jù)。配置路徑上公司間開(kāi)票有專門的開(kāi)票類型如 IV 開(kāi)頭的公司間發(fā)票。這里要特別注意開(kāi)票類型的「輸出確定」——必須配置對(duì)應(yīng)的輸出類型如 RD00、RD01 之類否則 VF01 生成發(fā)票后系統(tǒng)不會(huì)觸發(fā)后續(xù)的 IDOCMIRO 那邊就永遠(yuǎn)收不到采購(gòu)發(fā)票。實(shí)際配置時(shí)我一般會(huì)先確認(rèn)輸出類型是「按公司間」的輸出過(guò)程的條件記錄要覆蓋「銷售組織 1310 開(kāi)票類型 收貨方 1600」。條件記錄沒(méi)建輸出確定就是黑匣子看起來(lái)配了實(shí)際一張發(fā)票都沒(méi)有輸出。4.2 維護(hù)開(kāi)票憑證的復(fù)制控制開(kāi)票憑證復(fù)制控制解決的是「發(fā)票從哪來(lái)」的問(wèn)題——VF01 開(kāi)票時(shí)要復(fù)制交貨單的數(shù)據(jù)復(fù)制控制決定了哪些數(shù)據(jù)能復(fù)制過(guò)去、條件類型怎么映射。文檔第 18 頁(yè)的配置就在這里。復(fù)制控制維度配置要點(diǎn)來(lái)源憑證類型交貨單 NLCC目標(biāo)憑證類型公司間開(kāi)票類型數(shù)據(jù)復(fù)制規(guī)則復(fù)制數(shù)量、單位、批次、定價(jià)定價(jià)過(guò)程決定條件類型來(lái)源復(fù)制控制配不好最常見(jiàn)的癥狀是發(fā)票數(shù)量對(duì)但金額是零或者條件類型完全空白。這是因?yàn)閺?fù)制控制里的定價(jià)過(guò)程沒(méi)有把交貨單的條件類型傳遞過(guò)來(lái)。4.3 補(bǔ)充開(kāi)票的價(jià)格來(lái)源兩選一文檔第 20 頁(yè)的「補(bǔ)充」部分講的是公司間開(kāi)票的價(jià)格來(lái)源這是項(xiàng)目里最容易引發(fā)爭(zhēng)論的地方。兩種方式第一種手工維護(hù)公司間的銷售價(jià)格。這在 SD 價(jià)格維護(hù)里做最簡(jiǎn)單但問(wèn)題也很明顯——銷售方和采購(gòu)方兩邊都要維護(hù)價(jià)格價(jià)格不一致就產(chǎn)生差異。第二種銷售發(fā)票的定價(jià)類型直接復(fù)制采購(gòu)訂單的價(jià)格。復(fù)制來(lái)源于采購(gòu)訂單的價(jià)格需注意的是復(fù)制采購(gòu)訂單的條件類型與銷售發(fā)票的條件類型需要一致。如果采購(gòu)訂單使用了含稅價(jià)條件類型或者自定義了很復(fù)雜的定價(jià)則銷售發(fā)票的條件類型的例程中也需要進(jìn)行相同的定價(jià)條件或例程。這句話是文檔里給出的最實(shí)在的提示。很多項(xiàng)目翻車是因?yàn)椴少?gòu)訂單用的是 ZXXX 自定義條件類型比如含稅價(jià)而銷售發(fā)票的定價(jià)過(guò)程里沒(méi)有這個(gè)條件類型或者例程編號(hào)不一致。復(fù)制控制里定義了「從采購(gòu)訂單復(fù)制價(jià)格」但兩邊條件類型對(duì)不上最終發(fā)票金額就是亂的。文檔里還放了一個(gè)額外的判斷依據(jù)只要公司間銷售定價(jià)過(guò)程中的定價(jià)類型和采購(gòu)定價(jià)類型名稱一致就可以從采購(gòu)訂單中復(fù)制價(jià)格為開(kāi)票的價(jià)格。這個(gè)原則我在項(xiàng)目實(shí)施時(shí)用過(guò)多次省了很多扯皮。建議在配置前先拉一張采購(gòu)定價(jià)過(guò)程與銷售定價(jià)過(guò)程的對(duì)照表把每個(gè)條件類型的名稱、例程、計(jì)算順序統(tǒng)一再去做復(fù)制控制。4.4 自動(dòng) MIRO 采購(gòu)發(fā)票文檔第 28 頁(yè)之前一直在講銷售端自動(dòng)開(kāi)票采購(gòu)端的 MIRO 自動(dòng)發(fā)票核心其實(shí)不是 MIRO 本身的配置而是 IDOC 的常規(guī)配置——公司間的銷售發(fā)票開(kāi)出后系統(tǒng)通過(guò) IDOC 把發(fā)票信息傳給采購(gòu)方公司采購(gòu)方收到 IDOC 后自動(dòng)創(chuàng)建采購(gòu)發(fā)票。所以這一步的配置重心放在IDOC 端口、伙伴檔案、消息類型和流程代碼。文檔里明確提到「常規(guī) IDOC 配置」和「BRF 消息輸出設(shè)置S/4 系統(tǒng)專用」兩個(gè)部分前者是 ECC 和 S/4 通用后者是 S/4 的新輸出控制。IDOC 配置項(xiàng)說(shuō)明端口定義 SAP 系統(tǒng)之間的 RFC 目標(biāo)伙伴檔案定義 1600 公司作為接收方、1310 公司作為發(fā)送方消息類型如 INVOIC 等適用于公司間發(fā)票的類型流程代碼定義 IDOC 的發(fā)送/接收處理邏輯IDOC 配置完成后MIRO 側(cè)的自動(dòng)過(guò)賬不是 MR 配置問(wèn)題而是 IDOC 處理邏輯問(wèn)題——收到 IDOC 后調(diào)用哪個(gè) BAPI 或 Function Module 過(guò)賬。如果對(duì)接的是對(duì)方公司自開(kāi)發(fā)的邏輯還要確認(rèn)這段增強(qiáng)在 S/4 里是否激活。這也是很多項(xiàng)目在 S/4 遷移后發(fā)現(xiàn) MIRO 不自動(dòng)的原因ECC 里的自制增強(qiáng)沒(méi)做 S/4 兼容性測(cè)試。5. 常見(jiàn)問(wèn)題與排錯(cuò)自動(dòng)配置估計(jì)不生效先查這五處STO 自動(dòng)化排錯(cuò)難的不是某一個(gè)配置項(xiàng)有多深而是鏈路太長(zhǎng)出錯(cuò)點(diǎn)太多。以下五類問(wèn)題是我在實(shí)施和運(yùn)維中反復(fù)遇到的按「現(xiàn)象 → 原因 → 解決」寫清楚可以直接當(dāng)排查手冊(cè)用。5.1 改完配置舊采購(gòu)訂單不自動(dòng)創(chuàng)建交貨單現(xiàn)象ME21N 里把配置改了回到已經(jīng)存在的 STO 采購(gòu)訂單上測(cè)試VL10CUC 跑完提示「沒(méi)有符合條件的憑證」交貨單沒(méi)建出來(lái)。原因文檔開(kāi)頭就說(shuō)了配置更改后只對(duì)新建的 STO 采購(gòu)訂單產(chǎn)生影響已創(chuàng)建的采購(gòu)訂單不會(huì)再自動(dòng)創(chuàng)建。解決用新訂單測(cè)試不要在舊訂單上反復(fù)折騰。歷史訂單需要自動(dòng)創(chuàng)建的話手工跑 VL10B或者在參數(shù)文件里勾選「包括已存在訂單」并重新調(diào)度。5.2 VL23 自動(dòng)過(guò)賬 Job 一直報(bào)「庫(kù)存地點(diǎn)無(wú)法自動(dòng)確定」現(xiàn)象VL23 后臺(tái) Job 每跑必報(bào)錯(cuò)看日志是行項(xiàng)目「無(wú)法確定庫(kù)存地點(diǎn)」交貨單過(guò)不了賬。原因發(fā)貨工廠的行項(xiàng)目缺少庫(kù)存地點(diǎn)自動(dòng)確定規(guī)則系統(tǒng)不知道從哪個(gè)庫(kù)存地點(diǎn)發(fā)貨。解決回顧一下第 3.1 節(jié)的內(nèi)容——在后臺(tái)「庫(kù)存地點(diǎn)確定」里配置發(fā)貨工廠對(duì)應(yīng)的庫(kù)存地點(diǎn)或者直接在交貨單行項(xiàng)目上手工補(bǔ)庫(kù)存地點(diǎn)后重新過(guò)賬。但補(bǔ)單不是長(zhǎng)久之計(jì)根因還是庫(kù)存地點(diǎn)確定規(guī)則沒(méi)配。5.3 VF01 發(fā)票金額為零交貨單數(shù)量正常現(xiàn)象自動(dòng)生成的銷售發(fā)票數(shù)量正確但金額顯示 0.00財(cái)務(wù)拒絕這張票。原因開(kāi)票憑證復(fù)制控制里定價(jià)過(guò)程沒(méi)有從交貨單復(fù)制有效的條件類型或者定價(jià)類型名稱與采購(gòu)訂單的條件類型不一致。解決對(duì)照第 4.3 節(jié)的價(jià)格來(lái)源說(shuō)明檢查公司間銷售發(fā)票的定價(jià)過(guò)程是否包含采購(gòu)訂單里的所有條件類型尤其是含稅價(jià)或自定義條件類型名稱與例程必須一致。5.4 銷售發(fā)票已開(kāi)出但 MIRO 一直收不到采購(gòu)發(fā)票現(xiàn)象VF01 成功開(kāi)票憑證已過(guò)賬但 1600 公司的 MIRO 里沒(méi)有任何待處理的采購(gòu)發(fā)票。原因銷售發(fā)票生成后輸出確定沒(méi)有觸發(fā) IDOC或者 IDOC 發(fā)出后接收端的伙伴檔案/流程代碼配置不對(duì)。解決先在 VF03 里看發(fā)票的輸出記錄確認(rèn)輸出類型是否寫出來(lái)了再到 WE02/WE05 里查 IDOC 狀態(tài)——如果 IDOC 是 03 錯(cuò)誤狀態(tài)就看錯(cuò)誤文本多半是伙伴檔案里流程代碼沒(méi)配或端口不對(duì)。這條鏈路很長(zhǎng)IDOC 日志是最直接的破案線索。5.5 BRF 輸出配置與 IDOC 輸出控制重復(fù)導(dǎo)致發(fā)票重復(fù)發(fā)送現(xiàn)象S/4 系統(tǒng)里同時(shí)配置了傳統(tǒng) IDOC 輸出和 BRF 輸出銷售發(fā)票開(kāi)出后采購(gòu)方收到兩張重復(fù)的采購(gòu)發(fā)票。原因BRF 是 S/4 的輸出控制方式但如果傳統(tǒng) IDOC 的配置沒(méi)有停用兩邊同時(shí)觸發(fā)輸出。解決決定用哪一套。S/4 建議走 BRF 輸出同時(shí)把傳統(tǒng)輸出類型的「處理程序」停用或者將條件記錄設(shè)為無(wú)效。切忌兩套共存除非你有明確的并行測(cè)試計(jì)劃。6. 用 IDOC 監(jiān)控與 BRF 輸出把整條自動(dòng)化鏈路驗(yàn)收起來(lái)配置全部做完不代表自動(dòng)化就交付了。真正能驗(yàn)收的標(biāo)準(zhǔn)是一條采購(gòu)訂單從創(chuàng)建到 MIRO 過(guò)賬全程無(wú)人干預(yù)、狀態(tài)全綠、財(cái)務(wù)數(shù)據(jù)一致。要達(dá)到這個(gè)目標(biāo)最后一步往往不是再調(diào)配置而是把監(jiān)控和輸出控制串起來(lái)。S/4 系統(tǒng)里BRF 消息輸出設(shè)置是公司間發(fā)票自動(dòng)化的新控制中心。DDIC 里配置 BRF 的目的是替代傳統(tǒng) Condition Technique 的輸出確定更靈活地控制何時(shí)發(fā)送、發(fā)什么內(nèi)容、走什么通道。對(duì)于公司間發(fā)票BRF 的決定是「要不要輸出 IDOC」而不再是簡(jiǎn)單條件記錄。所以 S/4 項(xiàng)目里必須單獨(dú)走一遍配置路徑否則即使所有后臺(tái)配置都對(duì)輸出也可能靜默失敗。另外我習(xí)慣在每個(gè)項(xiàng)目里保留一份「IDOC 狀態(tài)碼速查表」遇到發(fā)票傳輸問(wèn)題可以直接照表排查IDOC 狀態(tài) 30已發(fā)出代表發(fā)送成功狀態(tài) 64已傳遞給應(yīng)用代表接收端處理成功如果停在 03錯(cuò)誤或 12調(diào)度失敗去 SM37 看后臺(tái)作業(yè)日志八成是接收端程序崩了或數(shù)據(jù)不完整。這個(gè)習(xí)慣幫我在好幾個(gè)項(xiàng)目里半小時(shí)定位問(wèn)題而不用翻一堆雜亂的開(kāi)發(fā)日志。有一次生產(chǎn)環(huán)境反饋 MIRO 收不到發(fā)票我按鏈路一段一段查VF03 確認(rèn)發(fā)票已開(kāi)WE02 查到 IDOC 狀態(tài)是 03點(diǎn)開(kāi)錯(cuò)誤文本發(fā)現(xiàn)接收端找不到采購(gòu)訂單原因是采購(gòu)訂單號(hào)跨公司傳輸時(shí)被系統(tǒng)截?cái)嗔?。后?lái)我把伙伴檔案里的「消息類型增強(qiáng)」字段里的客戶化版本號(hào)補(bǔ)上重新觸發(fā)輸出IDOC 狀態(tài)變成 64MIRO 那邊自動(dòng)生成了采購(gòu)發(fā)票。從那以后我每次做 STO 自動(dòng)化驗(yàn)收都強(qiáng)制走一遍「訂單 → 交貨單 → 發(fā)貨過(guò)賬 → 收貨 → 銷售發(fā)票 → IDOC → 采購(gòu)發(fā)票」的全鏈路日志檢查哪個(gè)環(huán)節(jié)的狀態(tài)碼不是預(yù)期值就當(dāng)場(chǎng)定位絕不留到上線后再補(bǔ)。這套方法不一定能幫你完全避免踩坑但至少能把踩坑的時(shí)間從一天縮短到半小時(shí)。希望幫到你。本文還有配套的精品資源點(diǎn)擊獲取