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