/目錄TOC\o"1-5"\h\z\uSAP跨公司銷售（ICS）業務——測試與原理 3Part1. 測試環境、測試劇本與測試數據 31.1 測試劇本 31.2 術語標準 41.3 測試數據 5Part2. 業務流程 62.1 接單方簽署并下達銷售訂單 62.2 需求方案的落實傳遞 72.3 修改銷售訂單，變更交貨工廠 102.4 重新落實需求方案 122.5 供給工廠創立交貨單 132.6 供給工廠揀配 152.7 供給工廠過賬出貨 182.8 接單方出票，向客人收款 202.8.1 對外銷售發票的單價 202.8.2 會計憑證的價值分析 212.9 供給方出票，向接單方收款 212.9.1 內部結算發票的單價 232.9.2 會計憑證的價值分析 242.10 接單方成認對供給方的應付賬款 24Part3. 技術原理剖析 273.1 序曲–組織單元的設計 273.1.1 公司代碼 273.1.2 工廠代碼 273.1.3 公司代碼與工廠代碼之間的分配關系 283.1.4 接單方與供貨方的銷售組織 283.1.5 接單方與供貨方的銷售區域組合 293.1.6 接單方與供貨方的銷售組織和渠道對各自工廠的匹配關系 303.1.7 接單方的銷售組織和渠道對供貨工廠的匹配關系 303.1.8 接單方和供貨方各自裝運點與工廠的匹配關系 313.1.9 接單方的采購組織設置 323.2 慢板–主數據的準備和局部關鍵定制 323.2.1 以接單公司的立場，創立供貨公司的供給商主數據 323.2.2 以供貨公司的立場，創立接單公司的客戶主數據 343.2.3 物料主數據的組織單元覆蓋 353.2.4 物料對外銷售價格主數據 363.2.5 物料對內結算價格主數據 373.2.6 內部結算發票價格條件的特殊定制細節 383.2.7 跨公司銷售訂單和發票的定價過程確定 393.2.8 跨公司銷售訂單或發票的定價過程細節 403.3 協奏–發票類型的輸出的配置和數據準備 423.3.1 為公司間交易發票類型分配輸出確定程序 423.3.2 定義輸出確定程序 423.3.3 輸出類型RD04的定制 433.3.4 為接單方的客戶號維護RD04輸出條件的主數據 443.4 盤旋–公司間發票的系統配置 453.4.1 銷售訂單類型配備公司間發票類型 463.4.2 把接單公司之銷售組織的內部客戶號確定下來 473.4.3 指定EDI傳輸的供給商邏輯地址 483.5 高潮–IDOC內核與財務端的設置 493.5.1 維護IDOC處理的端口 493.5.2 定義客戶的伙伴參數文件 493.5.3 定義供給商的伙伴參數文件 533.5.4 為EDI接收發票定義程序參數 553.5.5 為EDI接收發票分配公司代碼 573.5.6 為EDI接收發票分配總賬科目 573.5.7 為EDI接收發票分配稅碼 583.5.8 EDI接收發票的總賬科目的數據要求 613.6 尾聲–計量單位的定制和EDI憑證價值分析 633.6.1 計量單位的特殊定制要點 633.6.2 EDI自動產生會計憑證的價值分析 653.7 余韻–IDOC訊息監控與背景作業 673.7.1 IDOC訊息監控 673.7.2 背景作業 70Part4. 附加說明 72

SAP跨公司銷售（ICS）業務——測試與原理測試環境、測試劇本與測試數據本公司自己的IDES系統，客戶端800。登錄語言最好選擇英文（EN），漢語環境無法保證有關的表單格式已具備。測試劇本劇本描述：賣方與客人簽約提供某個產品，然而賣方是“銷售型公司〞，沒有生產的資質，只能找一個第三方購置。第三方安排供貨，把交易標的物品直接交給客人，然后根據客人簽收的憑證向賣方主張權利（即收款）。賣方驗證簽收憑證與事實無誤之后，向第三方成認債務（即支付貨款），自己也向客人出票主張權利。這個“三角交易業務〞項下，第三方的角色非常關鍵。以下是分析——上述劇本的分析：上述劇本的分析，首先需要劃分兩個維度（Dimension）：第一、交易的當事人“第三方〞與“賣方〞之間是否存在資本上的關聯關系？第二、發生在“第三方〞與“賣方〞之間的標的物品，其物流是否存在“入賣方倉庫〞的事實？如以下圖，以這兩個維度為坐標，業務被劃分為四個象限——（圖：三角銷售交易四象限圖）以下用SAP的系統業務，對這四個象限分別分析：第1象限：賣方找與自己存在資本關聯的第三方購置產品，收貨入庫后再交給客人。這個流程其實是兩段業務：首先是賣方與第三方之間的STO（庫存調撥訂單）業務，然后是賣方與客人之間的正常銷售業務。本案中無論是貨物流向還是債權債務關系，第三方與客人之間并沒有直接的業務關系；第2象限：賣方找與自己沒有資本關聯的第三方購置產品，收貨入庫后再交給客人。這個業務其實也是兩段業務：首先是賣方與第三方之間的常規采購業務，然后是賣方與客人之間的正常銷售業務。這是一個典型的“左手買進、右手賣出〞的貿易業務。同樣，本案中無論是貨物流向還是債權債務關系，第三方與客人之間并沒有直接的業務關系；第3象限：賣方找到與自己沒有資本關聯的第三方購置產品，但貨品自始至終并未進入賣方的倉庫，而是由第三方直接交給客人。這個業務就是SAP稱為“第三方銷售訂單〞（3rdpartysalesorder）的三角交易業務，第三方是“外部供給商〞，三方在業務中形成一個整體，彼此之間存在著業務關聯關系；第4象限：賣方與第三方存在資本關聯，貨品始終沒有進入賣方倉庫，第三方直接交付給客人。由于賣方對第三方存在應付賬款（AP），第三方對賣方存在應收賬款（A/R），顯然不能把第三方當成簡單的外部供給商來對待。這個業務在SAP系統里被稱為“跨公司銷售〞（Inter-CompanySales，ICS），在ICS中，賣方叫做“接單方〞（SellingParty）或者“訂單方〞（OrderParty），第三方叫做“供貨方〞（SupplyParty），它們與客人一道組成一個三角業務關聯整體。本文后續章節所描述的，就是這個象限的內容。追問：賣方與第三方雖然事實上存在資本關聯關系，但第三方尚未進入SAP系統（即尚未上線），那業務怎么處理？答復：問得好。第三方只要沒有表達為SAP系統內的組織單元（如公司代碼、工廠代碼等），就一律“視作外部供給商予以管理〞。只有概念明確，測試才有依據，因此，請認真領會本段落所述的業務場景。術語標準為防止概念混淆，本文行文中，將把測試劇本中的“賣方〞稱為“接單方〞或者“接單公司〞（Orderingparty），而“實際供貨方〞稱為“供貨方〞或者“供貨公司〞（Supplyingparty）。測試數據數據種類代碼本業務中的作用數據要求物料主數據M-01交易的標的物1.對工廠2200和1000同時維護；2.對銷售組織2200和1000同時維護。客戶主數據2500與接單方簽約的客人1.對銷售組織2200和1000同時維護；2.至少要對公司代碼2200維護。接單方的公司代碼2200與客人簽署銷售訂單的我方當事人組織單元，非前臺維護數據。有關要求，見本文《技術原理剖析》局部接單方的工廠代碼2200履行銷售訂單交貨業務的默認工廠接單方的銷售組織2200簽署銷售訂單的組織單位供貨方的公司代碼1000實際履行交貨義務的會計發生主體供貨方的工廠代碼1200實際履行交貨義務的實體工廠供貨方的銷售組織1000內部應收賬款結算的銷售組織

業務流程接單方簽署并下達銷售訂單步驟：事務代碼VA01。初始屏幕中，Ordertype=OR，Salesorganization=2200，distributionchannel=10，Division=00。敲回車；Sold-toparty=2500，Req.deliv.Date服從系統自動默認結果。敲回車，呼出其他默認內容，把表頭固定下來；行工程中，輸入物料號M-01，數量自定（別太大，太大了存貨不夠，補進又會生出其他的操作），敲回車。可以看到，系統默認的交貨工廠是2200。菜單“Edit→incompletionlog〞，確保沒有缺失的內容。選擇行工程（摁癟），點擊圖標，觀察行工程的價格。記住了，可以修改的價格條件只有主價格PR00，其余都是來自價格主數據或者付款條件的價格數字；存盤，記錄下號碼。需求方案的落實傳遞下達銷售訂單成功，那么訂單需求通過系統關于需求傳遞的有關定制，自動落實需求方案。本步驟不存在寫操作，只顯示，步驟如下：啟動事務代碼MD04，輸入物料號M-01（這是銷售訂單交易的標的物品），再輸入工廠2200（即銷售訂單默認的交貨工廠），敲回車進去。結果如下——接單方（2200）本身是個銷售型公司，之所以設置工廠代碼，是因為銷售交貨單是在工廠層面發生，而不是由于其事實上存在庫存。事實上，如上圖所示，工廠2200的存貨是一張白皮。問題是：這一步驟下，需求方案到底是傳遞給2200還是1200？答案很明確：在這個步驟，需求方案還只是傳遞到2200即接單方層面，還沒有傳遞到1200即事實上的供給工廠層面。你用MD04可以迅速獲得驗證——事實上，如果我們用VL01N創立交貨單，如以下圖所示的界面把供貨方裝運點輸入后，您看看系統會有什么反應——（圖：用供貨方裝運點去創立交貨單的初始屏幕）敲回車后，系統反應如以下圖所示。很顯然，這絕對不是“可以創立外向交貨單〞的界面。（圖：供貨方裝運點不能創立交貨單）怎么辦？供貨方（即1200）不能創立交貨單，我用接單方（即2200）可以創立交貨單嗎？試試不就知道了嗎？結果如以下圖，顯然，這是“可以創立外向交貨單〞的界面。雖然2200工廠項下M-01沒有任何存貨，但由于ATP檢查的配置，我們還是可以“創立交貨單〞，只不過不能“揀配〞、更不能“過賬發貨〞而已。（圖：接單方裝運點可以創立交貨單）不過不要太快樂地說“接單方裝運點可以創立交貨單，那么問題就解決了〞這句話。請問：我們的業務是什么？是直接由接單方向客人交貨嗎？如果是這樣，那本文敘述這么多不就全成為廢話嗎？還有什么存在的價值？從業務本身而言，貨并沒有進入接單方2200的庫存，而是直接由供貨方1200發給客人，那么請問2200有什么理由創立交貨單？（憤怒地）詢問：供貨方1200不能創立交貨單，接單方2200可以創立交貨單卻不符合業務，那到底該怎么辦？（沉著地）問答：這就是我們的下一步操作——修改銷售訂單，變更交貨工廠根據接單方（2200）與客人的銷售契約，允許從接單方的兄弟公司（即供貨方1200）供貨。既然實際交易的契約允許，那么我們當然可以把銷售訂單的交貨工廠，從默認的2200變更為事實上的1200。變更操作很簡單，步驟如下——事務代碼VA02，輸入記錄下的銷售訂單號碼，敲回車進去；在行工程級別，把工廠從默認的2200，變更為1200！敲回車確認；就這么簡單嗎？不，沒那么簡單。請選擇行工程（摁癟），點擊上圖下方的圖標，進入行工程的“價格〞。請問：價格有什么變化？是不是如以下圖所顯示的那樣，多出了一條可以修改的價格條件PI01？我們先記住這兩個命題：①、價格PR00是接單方與客人之間的結算根本單價；②、價格PI01則作為接單方（2200）與供貨方（1200）之間的內部結算單價的基礎。隨著后續測試的進行和結果分析，我們將驗證這兩個命題的正確性。切換到行工程的卡片夾shipping，我們可以看到，不僅工廠成為1200，裝運點也成為1200了。把storagelocation的賦值輸入為0001。菜單“edit→incompletionlog〞，確保訂單沒有缺失的內容，存盤。重新落實需求方案MD04，觀察接單方（2200）項下，大地白茫茫真干凈：MD04，觀察供貨方（1200）項下，這回，需求元素可是實實在在的了。供貨工廠（1200）的方案人員只要看到MD04中1200工廠項下的需求和存貨，自然就了解供需對照狀況。本例中，存貨（Stock）量已足夠覆蓋需求（requirement）量，因此系統不會產生方案單（如果是內部獲取）或者采購申請（如果是外部獲取，物料類型HAWA是tradinggoods，外購商品，即所謂“左手買進右手賣出的東西〞，一般就是外部獲取）。供給工廠創立交貨單供貨工廠1200的存貨已經到位，那么當然就可以向客人交付了。系統內的操作步驟如下——事務代碼VL01N，輸入裝運點1200，輸入銷售訂單號。日期必須可以覆蓋銷售訂單中的要求交貨日期。如以下圖——敲回車后，這回系統準許交貨工廠創立交貨單了。存盤，記錄下交貨單號碼。刷新M-01在工廠1200項下的MD04顯示。可以看到需求元素變更為交貨單。供給工廠揀配在絕大多數客戶化SAP實施工程中，交貨單創立完畢，打印出來就可以過賬發貨了。然而這是IDES系統，為了不影響其他同事全面學習和測試SAP的功能，我們沒有修改交貨單與交貨行工程的定制，因此我們的交貨單行工程中，有兩個醒目的狀態，如以下圖——這兩個狀態的賦值，要么空白（即“無關〞），要么就必須是C（即“已完全處理〞），其余狀態如A或者B都無法過賬出貨。那么，怎么做呢？以下是步驟——事務代碼VL03N，輸入交貨單號。進入行工程的卡片夾“picking〞項下，把倉庫號（Warehousenumber）抄下來。退出交貨單。事務代碼LT03，輸入倉庫號、工廠代碼和交貨單號，其余不問，如以下圖——上圖敲回車后，進入處理界面。滑鼠放在交貨單行工程任何一個位置，再點擊上方的大圖標系統馬上在卡片夾“processeditems〞下，把交貨單及其行工程轉移過去了。存盤。系統告知。熟悉WMS的參謀應該知道，轉儲訂單（transferorder，TO）創立之后需要確認（confirmation）。不過在IDES系統中，根據WMS的有關定制，交貨單環節的TO創立成功后即自動確認。用LT21驗證，以下圖的狀態圖標及其文本說明，相信已經把意思表達得很充分了。VL03N，重新顯示交貨單，看看狀態如何——退出交貨單的讀操作界面，本步驟結束。供給工廠過賬出貨揀配完成，可以出貨了。開兩個會話（session），一個MD04觀察M-01的存貨/需求對照，另一個VL02N執行過賬發貨操作。事務代碼VL02N，輸入交貨單號，點擊那個大大的圖標“Postgoodsissue〞。點擊圖標的操作非常簡單，敘述從略。點擊過賬后，MD04的結果顯示如下，存貨減少，需求元素姿消。VA03顯示銷售訂單的憑證流（documentflow），可以清楚地追溯到交貨單、揀配單和物料憑證的信息。發的是工廠1200的貨，而工廠1200又附屬于公司代碼1000，這筆貨不能不明不白，因此公司代碼1000項下，當然將產生一筆會計分錄。接單方出票，向客人收款事務代碼VF01，參照已過賬出貨的交貨單創立標準發票（F2）。過程從略，結果如下——我們需要驗證兩個問題：1.出具銷售發票依據的單價是哪個？2.會計憑證中的價值是怎么計算來的？對外銷售發票的單價VF03顯示銷售發票，觀察其PR00的單價和價值。凈單價811，數量5，凈合價=811x5=4,055；稅率20.6%，稅額=4055x20.6%=835.33；價稅合計=凈合價+稅額=4,890.33。SAPIDES系統可不像咱們在中國國內做的以含稅價定價的工程，它是不含稅價。不含稅價的算法當然如上述方式去計算。也就是說，本筆交易對客人收取的總應收款項，就應該以4,890.33為基礎。問題在于：會計上也是這么認為的嗎？請看下一節——會計憑證的價值分析嘿，會計還真是這么認為的！整個會計分錄是——借：客戶應收賬款4,890.33貸：銷售收入4,055.00應付銷項稅金835.33瞧仔細了：對客戶的外部發票是接單方（2200）出具的，公司代碼當然就是2200。供給方出票，向接單方收款如果是常規的銷售業務，2.8段落執行完畢后，物流模塊（Logistics）的流程就全部結束了，因為后面的收款和清賬純屬財務上的操作，與物流無關。然而本案所述的流程中，事情并沒有結束，因為供給方（工廠1200/公司1000）作為一個會計核算主體代替另一個會計核算主體（接單方2200公司）履行了交貨義務，它的權利還沒有得到交代。因此，供給方需要對接單方出票，主張自己的應收賬款。怎么主張？答案很簡單：VF01，對交貨單“二次出票〞！操作步驟如下描述——VF01進去。在下方的單據中，再次輸入交貨單號！插話：等等，先別急著敲回車。就這樣，你就能創立第二張發票嗎？答復：是的，就這么簡單。追問：在字段BillingType中，你難道就不想輸入一點內容嗎？答復：嘿，我還真就不想輸入任何內容，我現在就敲回車給你看——回車一敲，系統真的創立一張新的發票，而且選擇的billingtype不是F2，而是IV。在標準的SAP定制中，IV就是“公司間結算的發票類型〞！存盤，先產生發票號和會計憑證，接下來再分析。問題：為什么兩張發票號碼，產生的會計憑證號相同？答復：請帶著你的問題看下面的分析。看完分析，自然就知道原因了。內部結算發票的單價VF03顯示內部結算發票（IV發票），觀察其ZIV1的單價和價值。ZIV1的單價作為計算基礎，數量5PC，凈單價=183x5=915.00；沒有銷項稅。我們不必糾結于“這個是否符合中國的稅務實踐〞，只看算法是否正確即可。那么供給方公司1000向接單方公司2200的應收賬款，就應該是915.00。挑戰：“這不過是你的猜想，會計上也這么認為嗎？〞應戰：看看會計分錄怎么說——會計憑證的價值分析上帝，會計分錄還真應驗了我的推測，上圖的會計分錄用白話文來表達如下——借：客戶應收賬款915.00貸：關聯銷售收入915.00瞧瞧，aff.是“affiliate〞的縮寫，affiliate的含義就是“關聯公司交易〞，多么貼切的總賬科目。瞧仔細了，這張會計憑證是公司代碼1000出具的，與上一張對客人銷售發票的會計憑證主體有所不同。在SAP系統中，不同公司代碼項下的某一類會計憑證，其號碼范圍是可以分開定義的，因此1000公司和2200公司的第一張銷售發票會計憑證的號碼相同就不難理解。這個命題，財務參謀會告訴你在哪里定制，本文就不再掠美。接單方成認對供給方的應付賬款提問：三角交易中，接單方（2200）對客人的發票出具了，供給方（1200）對接單方的內部結算發票也出具了，流程是不是就該結束？答復：還沒有，因為接單方還沒有成認對供給方的應付賬款義務。這就是“同一企業集團項下不同會計法人主體之間的關聯交易〞必須考慮的要素：一方對另一方主張權利，不等于另一方同時成認義務。提問：那么接單方又該怎么“成認〞呢？應付賬款的產生，只可能來源于兩個渠道，要么從采購模塊的發票校驗產生，要么是在FI模塊中手工做賬，是不是？答復：說的很到位，確實如此。追問：可是本文行文至此，根本就沒有出現采購訂單，更沒有收貨。這不是STO業務，接單方與供給方之間沒有采購訂單和收貨記錄，怎么做發票校驗？難道是直接在FI模塊中用事務代碼FB01直接手工創立會計憑證這種“流氓方式〞嗎？答復：您還真說對了，確實是FB01，但操作者不是接單方（2200）的會計人員，而是系統的IDOC功能！因此，不能說是“手工創立應付賬款憑證〞，而是“系統驅動IDOC自動創立〞。具體的機制后面再闡述，我們先只看結果，步驟如下——事務代碼FBL1N。供給商代碼輸入10000，公司代碼輸入2200，“openatkeydate〞維持系統默認的當前日期，其余不問。點擊圖標進入。系統顯示如下。很明顯，畫紅框的才是本案的記錄。點擊上圖憑證前面的小方框，再點擊圖標，進入以下圖不必領會其他內容，直接點擊上圖的圖標。圖窮匕首現。流程至此才算全部結束。很顯然，人工FB01與本文所述的系統IDOC觸發FB01操作，哪個“更具有技術含量〞，不言自明。

技術原理剖析有一個SAPNOTE叫做31126，闡述的就是如何在“跨公司出票〞（Inter-CompanyBilling，ICB）場景下使用SAPEDI技術（ElectronicDataInterchange，電子數據互換）直接在FI模塊中過賬到供給商庫存而執行正確的系統設置。本局部內容就以這個NOTE為參考線索，結合作者個人體會而敘述。序曲–組織單元的設計首先必須搭建這個業務中所涉及的有關接單方（SellingParty）與供貨方（SupplyingParty）的組織結構，包括公司代碼、工廠代碼、采購組織、銷售組織、銷售區域組合（即銷售組織·分銷渠道·產品組的組合）等組織單元，以及此類組織單元之間的分配關系。公司代碼作為SAP參謀，公司代碼的配置路徑再熟悉不過了，不再贅述。在IDES系統中，供貨公司1000和接單公司2200已存在，且地址數據完備。自定義的公司代碼，地址數據必須完備。所謂“完備〞的標準，是“不要讓SAP系統報錯存在缺失‘必須輸入’的數據〞即可。工廠代碼同樣的理由，工廠代碼的配置路徑不再贅述。在IDES系統中，本案有關的供貨工廠1200和銷售工廠2200也已存在，且地址數據完備。自定義的工廠代碼，地址數據仍然必須完備，標準同上。公司代碼與工廠代碼之間的分配關系事務代碼OX18，完本錢案公司代碼與工廠之間的分配關系。很顯然，IDES中已經完成。作為一個常識，應該知道：公司代碼項下可以有多個工廠，但工廠只能效勞于一個公司代碼。接單方與供貨方的銷售組織配置路徑或事務代碼從略。IDES里已存在接單方和供貨方的銷售組織。接單方與供貨方的銷售區域組合與本案有關的銷售區域組合，在IDES項下已經存在。自己尋找配置路徑或事務代碼。接單方與供貨方的銷售組織和渠道對各自工廠的匹配關系IDES中，無論是接單方還是供貨方，銷售組織與分銷渠道對各自工廠的匹配關系已經定義。自己尋找配置路徑或事務代碼。接單方的銷售組織和渠道對供貨工廠的匹配關系在接單公司的自有工廠無法供貨的情況下，它當然要尋求供貨公司的工廠。因此，必須完成接單方的銷售組織（2200）和有關渠道與供貨工廠（1200）之間的分配關系。這個配置可以說是ICS業務得以實現的基石，切記、切記！接單方和供貨方各自裝運點與工廠的匹配關系事務代碼OVXC，為工廠分配裝運點。IDES系統早已分配完畢。作為常識應該知道：一個工廠項下可以有多個裝運點，但一個裝運點不能效勞于多家工廠。接單方的采購組織設置在本案所述的三角交易關系中，接單方（2200）相當于是從供貨方（1200）購置商品。雖然在整個流程中沒有出現任何采購訂單，但這不等于采購組織沒有定義的必要。SAPIDES中，接單方2200的采購組織就是它自己的部門或者團隊，即2200。以下圖顯示的是工廠代碼2200項下所有的采購組織配置狀況。配置路徑，請自己尋找。慢板–主數據的準備和局部關鍵定制以接單公司的立場，創立供貨公司的供給商主數據很明顯，本案中，接單公司是2200，供貨公司是1200創立供給商主數據的事務代碼是XK01，這個事務代碼意味著組織結構的選擇不僅要選擇公司，還要選擇采購組織。公司代碼當然是2200，采購組織按3.1.9段落的描述，也是2200。創立主數據的過程從略，作者只想強調的是：供給商號碼與工廠之間必須關聯！供給商與工廠關聯的含義，在于以下步驟——對創立完畢的供給商，啟動事務代碼XK02（MK02也行），輸入供給商號、公司代碼、采購組織后，只點擊“Purchasedata〞。如以下圖：敲回車進去后，菜單“extra→additionalpurchasedata〞。系統跳出一個對話框。在對話框里，輸入工廠代碼1200。這就是所謂的“將集團內供給商與工廠組織給關聯起來〞，MM模塊主導的STO業務也有這個操作！存盤退出。以供貨公司的立場，創立接單公司的客戶主數據創立客戶主數據的事務代碼是XD01，這個事務代碼意味著組織結構的選擇不僅要選擇公司，還要選擇銷售區域。公司代碼當然是2200，銷售區域組合按我們在前面章節的描述，銷售組織=1000、分銷渠道=12、產品組=00。創立過程從略，IDES系統里已有現成數據，但作為ICS業務的關鍵實現要素，下面幾個要點必須強調——頁簽“Sales〞項下，字段CustomerPriceProcedure。不同工程對客戶定價程序的設置詳略程度不一樣，像咱們公司的工程中，公司間交易是I，標準銷售是1。不過在IDES系統里，內部客戶的客戶定價程序與常規銷售相同，也是1；同樣的頁簽“Sales〞，字段“Acctatcust.〞，非常重要。只能是10000。問：為什么要輸入10000？答：這個字段是什么意思？“我們在客戶方的賬號〞。“我們〞是誰？對于接單公司2200而言，我們是不是它的供給商？既然是供給商，總得有個號碼標識，我們的供給商號碼標識，3.2.1段落說的還不夠清楚嗎？根據SAPNOTE31126的說明，如果要啟動IDOC完成供給商賬戶的自動過賬，字段“Acctatcust.〞必須輸入正確的值！頁簽“Billingdocuments〞項下，字段“Acctassgmtgroup.〞，與外部客戶不同。IDES中是03，文字“Ap.reven.〞，已經把“關聯公司收入〞的含義表達得很清楚了。同樣頁簽“Billingdocuments〞項下，字段“Taxcl.〞。IDES中是0，這也是本文2.9段落中描述的“內部結算發票〞的稅率為0的根本原因。至于這個設置“是否符合中國國情〞，不在本文討論范圍，自辨。物料主數據的組織單元覆蓋物料既然可以被接單公司（2200）下銷售訂單，它就必須維護2200工廠項下的數據、以及維護銷售組織2200·分銷渠道10·產品組00項下的數據。物料既然可以被供給工廠（1200）交付，它就必須維護1200工廠項下的數據。物料既然可以被供給公司（1000）開內部結算銷售發票，而銷售發票離不開銷售區域，因此還必須維護銷售組織1000·分銷渠道12·產品組00項下的數據。具體過程不再贅述，只看以下圖所表達的結果——物料對外銷售價格主數據事務代碼VK11，條件類型PR00，選擇最下方的“materialwithreleasestatus〞。物料=M-01，銷售渠道=2200，分銷渠道=10，有效期自己定。結果如下——可以回想一下：在2.1段落下訂單時，PR00單價是不是默認自動帶出來的（盡管是“白色可修改〞）？在已經存在物料銷售價格主數據的前提下，用VK12修正或者VK13只讀即可。物料對內結算價格主數據事務代碼VK11，條件類型PI01。Keycombination只有一個選擇。Salesorganizationfororder，當然填寫2200，因為與客人簽署銷售訂單的銷售組織是2200；Plant，則必須填寫1200，因為這是出貨的工廠。下方物料號當然填寫M-01，價格據實錄入，有效期自定。作為IDES系統，已經定義了，請用VK12或者VK13觀察。追問：不對，請等一等！你維護的是PI01，可是2.9.1段落中內部結算發票的截圖很清楚，生效的是ZIV1的價格。這是怎么一回事？答復：你確實看得很仔細。下面的定制馬上答復你的疑問——內部結算發票價格條件的特殊定制細節事務代碼V/06，定位到ZIV1，也就是你看到的內部結算發票的價格條件。進入其詳情——答案揭曉：ZIV1在執行銷售業務中，將從PI01的現有記錄中參考取值。關于“referenceconditiontype〞的用途，請自己參閱SAP在線幫助文檔并自己測試，本文不再贅述。進一步講，你可以啟動事務代碼VK11直接創立ZIV1的價格主數據，來看看系統會告訴你什么信息——跨公司銷售訂單和發票的定價過程確定事務代碼OVKK。這個事務代碼答復“系統如何抓取不同的定價過程和主條件類型〞。按以下變量挑選——Salesorganization=1000（供貨方出具IV發票）Distributionchannel=12Division=00Customerpricingprocedure=1Documentpricingprocedure=I結果如以下圖——不明白為什么“documentpricingprocedure〞要選I，是不是？事務代碼VOFA，自己觀察F2和IV，看看它們的字段“documentpricingprocedure〞各自是什么？作為接單方2200，它與客人簽署的OR標準銷售訂單，定價過程則是RVAA01。它對客人出票的定價過程，也是RVAA01。其中的原理，請自己用上述方式去找尋，不再贅述。跨公司銷售訂單或發票的定價過程細節事務代碼V/08。這個事務代碼答復“定價過程是怎么樣的構成結構〞。銷售訂單與外部發票的RVAA01定價過程，PR00是主價格，而PI01也是其中的一個條件類型，而且也對應到銷售收入的賬碼（ERL）。然而更值得關注之處，在于它的requirement賦值22。無論是采購訂單的定價還是銷售訂單的定價，requirement都表示“只有在滿足例程所規定的算法條件下這個價格才有效〞。例程22的詳情，請自己用事務代碼VOFM去閱讀其代碼程式，本文不再贅述。內部結算發票所采用的ZIV001的定價過程，其配置詳情，同樣用V/08去觀察。相對應的核心條件類型是ZIV1。自己看去，不再贅述。協奏–發票類型的輸出的配置和數據準備為公司間交易發票類型分配輸出確定程序事務代碼：V/25作為比照，標準發票的輸出類型是RD00。定義輸出確定程序事務代碼V/42。公司間發票的輸出確定程序V40000的具體詳情如以下圖所示——作為比照，不妨看看常規發票的輸出確定程序V10000的詳情：輸出類型RD04的定制事務代碼V/40。看看，RD04的傳輸介質是什么？不怕不識貨，就怕貨比貨。標準發票對應的輸出類型RD00，它的介質又是什么？所有的SAP輸出類型，都有程式（program）、表單例程（routine）和表單（form），當然表單是可以自定義的。標準IDES中的EDI傳輸介質并沒有定義表單（Form）。熟悉SAP“條件技術〞（Conditiontechnique）的參謀都知道，條件類型（conditiontype）是定制概念，條件類型要想讀取前臺作業人員創立的主數據，就必須為它定義一個存取順序（accesssequence）。輸出（output）應用的，也是“條件技術〞的一種形式，因此輸出類型也有存取順序，這個存取順序就是以下圖所示的0004。為接單方的客戶號維護RD04輸出條件的主數據事務代碼VV31。輸入RD04，敲回車。點擊圖標keyconbination，跳出的組合只有一個，如以下圖。這是因為RD04的存取順序0004所確定的表格只有一個，如以下圖：回到VV31維護輸出主數據，結果如下。顯然，IV發票的發送者（sender）是供貨公司，上方的銷售組織當然是供貨方的銷售組織1000。創立完畢后，存盤退出。已經存在記錄的，用VV32修改或者VV33只讀。盤旋–公司間發票的系統配置本段落的配置根目錄：IMG→Salesanddistribution→Billing→Intercompanybilling，如以下圖。這是本段落項下的“總配置目錄〞。銷售訂單類型配備公司間發票類型配置路徑：配置根目錄→Defineordertypesforintercompanybilling。定位于標準訂單類型OR，如以下圖把發票類型IV填寫進去。這個配置意味著當接單方（2200）向外部客人簽署的標準銷售訂單變更供貨工廠（即變更為1200）時，系統可以允許已經過賬發貨的交貨單被“二次開票〞，且“二次開票〞的默認發票類型就是IV。經測試可以證明：本段落的定制，與VOV8定義銷售單據類型是完全等價的。如以下圖所示：把接單公司之銷售組織的內部客戶號確定下來配置路徑：配置根目錄→Defineinternalcustomernumberbysaleorganization在接單公司的銷售組織（即2200）一行，填寫3.2.2段落所創立的客戶主數據號碼填進去。提問：為什么供貨方（1000）的銷售組織也被維護了客戶號碼呢？答復：就本文所描述的場景而言，您確實可以不維護。維護了就表示1000銷售組織同樣可以作為“跨公司銷售的簽約方而被其他的兄弟公司出具公司間結算發票〞。不過這是IDES系統，咱維持不變。指定EDI傳輸的供給商邏輯地址配置路徑：配置根目錄→Automaticpostingtovendoraccount(SAPEDI)→AssignVendor事務代碼：WEL1結果如以下圖所示：維護說明如下：邏輯地址（Log.addr.）：以供貨公司（即本案的1000）的立場來命名，結構是“供貨的公司代碼+接單公司表達為供貨公司的內部客戶號〞。這里需要強調：如果客戶號碼是內部編號（即全部是數字），那么邏輯地址必須湊足14位數，缺乏的局部，按下表所示的結構進行填充——性質供貨公司用0填充客戶號位數1234567891011121314賦值10000000022000目的端（Destination）：以接單公司（即本案的2200）的立場來命名。CompanyCode當然就是接單公司本身，即2200；Vendor就應該填入供方公司在接單公司項下的供給商號碼，即10000。追問：本文的例子，無論供給商還是客人，號碼都是內部編號（即全部是數字），然而在我們的XX工程中，公司代碼固然都是數字，內部客戶號和內部供給商號卻是類似于C3430、C2000之類的編號。如果我們的場景是：公司代碼2000（內部客戶號C2000）對客人簽單，公司代碼3430（內部供給商號C3430）履行交貨職責，那么邏輯地址又該怎么定？答復：邏輯地址如下表，即不需要湊足14位數。性質供貨公司客戶號位數123456789賦值3430C2000而目的端，公司代碼則是2000，供給商當然是C3430了。注意：這個定制非常關鍵，它是被發送的EDI信息找到“接收方〞（recipient）的根本定制。高潮–IDOC內核與財務端的設置維護IDOC處理的端口事務代碼：WE21在IDES中，已經有許多端口（port）了，我們只需要關注A000000009是否存在于文件夾“TransactionalRFC〞即可。定義客戶的伙伴參數文件事務代碼：WE20點開文件夾“PartnerTypeKU〞，創立客戶22000。詳細內容如下——頁簽“Postprocessing:permittedagent〞項下，Ty.默認為US（SAP用戶）、Agent默認為當前操作人的用戶ID、Language默認為當前系統的登錄語言。這些信息維持默認值即可關鍵在于Outboundparameters（出埠參數），必須輸入兩行，如下表所示：PartnerRoleMessageTypeMessageVariantBPINVOICFIBPINVOICFI點擊放大鏡圖標，信息變式（messagevariant）FI的詳情如下：頁簽“outboundoption〞項下，以下圖標注局部是關鍵要素；頁簽“Processcontrol〞項下，應用只能是V3，訊息類型是RD04，處理代碼是SD08；其余頁簽維持默認值。點擊放大鏡圖標，信息變式（messagevariant）MM的詳情如下：頁簽“outboundoption〞項下，以下圖標注局部是關鍵要素；頁簽“Messagecontrol〞項下，以下圖標注局部是關鍵要素；其余頁簽維持默認值。在Partnerprofile的表頭層面，第二個頁簽classification，Partnerstatus必須賦值為A。其余不問。新建的伙伴參數文件必須存盤才能生效。定義供給商的伙伴參數文件事務代碼：WE20點開文件夾“PartnerTypeLI〞，創立供給商10000。詳細內容如下——表頭的要求，與客戶伙伴參數一致，不再贅述；下方的細節，維護的是inboundparameter（入埠參數）。不需要partnerrole（因為inbound是被動接受），messagetype都是INVOIC，分別維護FI和MM的變式。變式FI的細節簡述如下——頁簽“inboundoption〞，關鍵如下：其余頁簽無特別要求。變式MM的細節簡述如下——頁簽“inboundoption〞，關鍵如下：其余頁簽不做特別要求。為EDI接收發票定義程序參數事務代碼：OBCE。配置路徑自己找，以下圖是例如——選中以下圖紅框與本案有關的那一行，再點擊圖標——配置詳情如下所述——請回憶本文2.10段落中的截圖，系統自動產生的會計憑證的類型是RE，是不是？這個RE，就是由上圖的定制確定的。為EDI接收發票分配公司代碼事務代碼：OBCA。定位于Partnertype=LI、Partnernumber=10000，即本案有關的供貨公司，它們是接單公司的供給商。最右邊的Cocd字段中，輸入本案有關的接單公司的公司代碼，即2200。根據SAP的文獻原文描述——ByleavingthefieldCOCDblank,allcompanycodesareavailable。理解為“如果最右邊的字段COCD維持空格，系統就默認為供給商10000可以對任何它存在數據記錄的公司代碼都觸發EDI動作創立會計憑證〞。請自己驗證。為EDI接收發票分配總賬科目事務代碼：OBCB。如以下圖，在系統跳出的小框中，依次輸入LI（供給商）、10000（供貨公司表達的內部供給商）和2200（接單公司的公司代碼）。上圖敲回車進去后，按財務要求輸入總賬科目，文本字段是可選擇工程。IDES系統內是空白，維持不變。當然，這個總賬科目必須是事先在公司代碼中創立好的科目主數據。需要注意的是：總賬科目不可以與CO模塊的任何對象掛鉤，即它不能是本錢要素（costelement）。具體詳情，請咨詢FI/CO的參謀。為EDI接收發票分配稅碼事務代碼：OBCD。本定制的作用，在于把來源于銷售訂單中的銷項稅（outputtax）與供給商發票中的進項稅（inputtax）關聯起來。定位到LI·10000的行，確保你交易中可能出現的銷項稅碼能夠關聯到進項稅碼。字段“Taxtype〞，用來記錄銷項稅稅碼（Outputtaxcode）；字段“Tx〞，用來記錄進項稅稅碼（Inputtaxcode）。馬上產生了問題：我怎么知道供貨方內部結算發票的銷項稅稅碼是哪個？答復：找到那張內部結算發票的號碼，VF03顯示。進入行工程的“Condition〞頁簽，如以下圖：點擊上圖的圖標后，定位到MWST“銷項稅〞那一行，點開，找到有值的那個訪問順序，如以下圖：按上圖的箭頭所指，滑鼠點擊，系統馬上把你導引至條件價格主數據的界面如以下圖——選中MWST那一行（摁癟），再點擊圖標。如以下圖所示，找到銷項稅稅碼。作為SD參謀，你真不應該提這個問題，因為這是SD參謀的根本功。EDI接收發票的總賬科目的數據要求3.5.6段落所描述的總賬科目（607010）的主數據，存在一定的要求。FS00，進入總賬科目在公司代碼2200項下的數據，如以下圖所示強調兩個要點：頁簽“controldata〞項下，taxcategory必須“允許輸入進項稅〞。這句話的意思是：“既允許輸入銷項稅，也允許輸入進項稅〞。IDES如以下圖的選項是“只能允許進項稅〞，顯然更加嚴格，當然滿足這個條件——頁簽“Create/bank/interest〞項下，舊版本（4.7以下，含4.7）是“允許手工過賬〞，新版本（4.7以上，即ECCX.0）則是“Postautomaticallyonly〞（只能允許自動過賬）。那么在舊版本下，標志就得點上；新版本下，標志恰恰相反就不能點上。其余數據要求，按自己的需要自行處理，與IDOC無關。尾聲–計量單位的定制和EDI憑證價值分析計量單位的特殊定制要點請回憶3.5.4段落中關于EDI接受發票的程序參數，最下方有個單位。這個計量單位的定制，有點“小小的講究〞。用事務代碼C