/目錄TOC\o"1-5"\h\z\uSAP跨公司銷售（ICS）業務——測試與原理3Part1.測試環境、測試劇本與測試數據31.1測試劇本31.2術語規X41.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.8EDI接收發票的總賬科目的數據要求613.6尾聲–計量單位的定制和EDI憑證價值分析633.6.1計量單位的特殊定制要點633.6.2EDI自動產生會計憑證的價值分析653.7余韻–IDOC訊息監控與背景作業673.7.1IDOC訊息監控673.7.2背景作業70Part4.附加說明72SAP跨公司銷售（ICS）業務——測試與原理測試環境、測試劇本與測試數據本公司自己的IDES系統，客戶端800。登錄語言最好選擇英文（EN），漢語環境無法保證有關的表單格式已具備。測試劇本劇本描述：賣方與客人簽約提供某個產品，然而賣方是“銷售型公司”，沒有生產的資質，只能找一個第三方購買。第三方安排供貨，把交易標的物品直接交給客人，然后根據客人簽收的憑證向賣方主X權利（即收款）。賣方驗證簽收憑證與事實無誤之后，向第三方承認債務（即支付貨款），自己也向客人出票主X權利。這個“三角交易業務”項下，第三方的角色非常關鍵。以下是分析——上述劇本的分析：上述劇本的分析，首先需要劃分兩個維度（Dimension）：第一、交易的當事人“第三方”與“賣方”之間是否存在資本上的關聯關系？第二、發生在“第三方”與“賣方”之間的標的物品，其物流是否存在“入賣方倉庫”的事實？如下圖，以這兩個維度為坐標，業務被劃分為四個象限——（圖：三角銷售交易四象限圖）以下用SAP的系統業務，對這四個象限分別分析：第1象限：賣方找與自己存在資本關聯的第三方購買產品，收貨入庫后再交給客人。這個流程其實是兩段業務：首先是賣方與第三方之間的STO（庫存調撥訂單）業務，然后是賣方與客人之間的正常銷售業務。本案中無論是貨物流向還是債權債務關系，第三方與客人之間并沒有直接的業務關系；第2象限：賣方找與自己沒有資本關聯的第三方購買產品，收貨入庫后再交給客人。這個業務其實也是兩段業務：首先是賣方與第三方之間的常規采購業務，然后是賣方與客人之間的正常銷售業務。這是一個典型的“左手買進、右手賣出”的貿易業務。同樣，本案中無論是貨物流向還是債權債務關系，第三方與客人之間并沒有直接的業務關系；第3象限：賣方找到與自己沒有資本關聯的第三方購買產品，但貨品自始至終并未進入賣方的倉庫，而是由第三方直接交給客人。這個業務就是SAP稱為“第三方銷售訂單”（3rdpartysalesorder）的三角交易業務，第三方是“外部供應商”，三方在業務中形成一個整體，彼此之間存在著業務關聯關系；第4象限：賣方與第三方存在資本關聯，貨品始終沒有進入賣方倉庫，第三方直接交付給客人。由于賣方對第三方存在應付賬款（AP），第三方對賣方存在應收賬款（A/R），顯然不能把第三方當成簡單的外部供應商來對待。這個業務在SAP系統里被稱為“跨公司銷售”（Inter-panySales，ICS），在ICS中，賣方叫做“接單方”（SellingParty）或者“訂單方”（OrderParty），第三方叫做“供貨方”（SupplyParty），它們與客人一道組成一個三角業務關聯整體。本文后續章節所描述的，就是這個象限的內容。追問：賣方與第三方雖然事實上存在資本關聯關系，但第三方尚未進入SAP系統（即尚未上線），那業務怎么處理？回答：問得好。第三方只要沒有體現為SAP系統內的組織單元（如公司代碼、工廠代碼等），就一律“視作外部供應商予以管理”。只有概念明確，測試才有依據，因此，請認真領會本段落所述的業務場景。術語規X為避免概念混淆，本文行文中，將把測試劇本中的“賣方”稱為“接單方”或者“接單公司”（Orderingparty），而“實際供貨方”稱為“供貨方”或者“供貨公司”（Supplyingparty）。測試數據數據種類代碼本業務中的作用數據要求物料主數據M-01交易的標的物1.對工廠2200和1000同時維護；2.對銷售組織2200和1000同時維護?？蛻糁鲾祿?500與接單方簽約的客人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，數量自定（別太大，太大了存貨不夠，補進又會生出其他的操作），敲回車?？梢钥吹剑到y默認的交貨工廠是2200。菜單“Edit→inpletionlog”，確保沒有缺失的內容。選擇行項目（摁癟），點擊圖標，觀察行項目的價格。記住了，可以修改的價格條件只有主價格PR00，其余都是來自價格主數據或者付款條件的價格數字；存盤，記錄下。需求計劃的落實傳遞下達銷售訂單成功，那么訂單需求通過系統關于需求傳遞的有關定制，自動落實需求計劃。本步驟不存在寫操作，只顯示，步驟如下：啟動事務代碼MD04，輸入物料號M-01（這是銷售訂單交易的標的物品），再輸入工廠2200（即銷售訂單默認的交貨工廠），敲回車進去。結果如下——接單方（2200）本身是個銷售型公司，之所以設置工廠代碼，是因為銷售交貨單是在工廠層面發生，而不是由于其事實上存在庫存。事實上，如上圖所示，工廠2200的存貨是一X白皮。問題是：這一步驟下，需求計劃到底是傳遞給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→inpletionlog”，確保訂單沒有缺失的內容，存盤。重新落實需求計劃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公司）履行了交貨義務，它的權利還沒有得到交代。因此，供給方需要對接單方出票，主X自己的應收賬款。怎么主X？答案很簡單：VF01，對交貨單“二次出票”！操作步驟如下描述——VF01進去。在下方的單據中，再次輸入交貨單號！插話：等等，先別急著敲回車。就這樣，你就能創建第二X發票嗎？回答：是的，就這么簡單。追問：在字段BillingType中，你難道就不想輸入一點內容嗎？回答：嘿，我還真就不想輸入任何內容，我現在就敲回車給你看——回車一敲，系統真的創建一X新的發票，而且選擇的billingtype不是F2，而是IV。在標準的SAP定制中，IV就是“公司間結算的發票類型”！存盤，先產生發票號和會計憑證，接下來再分析。問題：為什么兩X發票，產生的會計憑證號一樣？回答：請帶著你的問題看下面的分析。看完分析，自然就知道原因了。內部結算發票的單價VF03顯示內部結算發票（IV發票），觀察其ZIV1的單價和價值。ZIV1的單價作為計算基礎，數量5PC，凈單價=183x5=915.00；沒有銷項稅。我們不必糾結于“這個是否符合中國的稅務實踐”，只看算法是否正確即可。那么供給方公司1000向接單方公司2200的應收賬款，就應該是915.00。挑戰：“這不過是你的猜測，會計上也這么認為嗎？”應戰：看看會計分錄怎么說——會計憑證的價值分析上帝，會計分錄還真應驗了我的推測，上圖的會計分錄用白話文來表達如下——借：客戶應收賬款915.00貸：關聯銷售收入915.00瞧瞧，aff.是“affiliate”的縮寫，affiliate的含義就是“關聯公司交易”，多么貼切的總賬科目。瞧仔細了，這X會計憑證是公司代碼1000出具的，與上一X對客人銷售發票的會計憑證主體有所不同。在SAP系統中，不同公司代碼項下的某一類會計憑證，其X圍是可以分開定義的，因此1000公司和2200公司的第一X銷售發票會計憑證的一樣就不難理解。這個命題，財務顧問會告訴你在哪里定制，本文就不再掠美。接單方承認對供給方的應付賬款提問：三角交易中，接單方（2200）對客人的發票出具了，供給方（1200）對接單方的內部結算發票也出具了，流程是不是就該結束？回答：還沒有，因為接單方還沒有承認對供給方的應付賬款義務。這就是“同一企業集團項下不同會計法人主體之間的關聯交易”必須考慮的要素：一方對另一方主X權利，不等于另一方同時承認義務。提問：那么接單方又該怎么“承認”呢？應付賬款的產生，只可能來源于兩個渠道，要么從采購模塊的發票校驗產生，要么是在FI模塊中手工做賬，是不是？回答：說的很到位，的確如此。追問：可是本文行文至此，根本就沒有出現采購訂單，更沒有收貨。這不是STO業務，接單方與供給方之間沒有采購訂單和收貨記錄，怎么做發票校驗？難道是直接在FI模塊中用事務代碼FB01直接手工創建會計憑證這種“流氓方式”嗎？回答：您還真說對了，的確是FB01，但操作者不是接單方（2200）的會計人員，而是系統的IDOC功能！因此，不能說是“手工創建應付賬款憑證”，而是“系統驅動IDOC自動創建”。具體的機制后面再闡述，我們先只看結果，步驟如下——事務代碼FBL1N。供應商代碼輸入10000，公司代碼輸入2200，“openatkeydate”維持系統默認的當前日期，其余不問。點擊圖標進入。系統顯示如下。很明顯，畫紅框的才是本案的記錄。點擊上圖憑證前面的小方框，再點擊圖標，進入下圖不必領會其他內容，直接點擊上圖的圖標。圖窮匕首現。流程至此才算全部結束。很顯然，人工FB01與本文所述的系統IDOC觸發FB01操作，哪個“更具有技術含量”，不言自明。技術原理剖析有一個SAPNOTE叫做31126，闡述的就是如何在“跨公司出票”（Inter-panyBilling，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？答：這個字段是什么意思？“我們在客戶方的賬號”?！拔覀儭笔钦l？對于接單公司2200而言，我們是不是它的供應商？既然是供應商，總得有個標識，我們的供應商標識，3.2.1段落說的還不夠清楚嗎？根據SAPNOTE31126的說明，如果要啟動IDOC完成供應商賬戶的自動過賬，字段“Acctatcust.”必須輸入正確的值！頁簽“Billingdocuments”項下，字段“Acctassgmtgroup.”，與外部客戶不同。IDES中是03，文字“Affiliat.p.reven.”，已經把“關聯公司收入”的含義表達得很清楚了。同樣頁簽“Billingdocuments”項下，字段“Taxcl.”。IDES中是0，這也是本文2.9段落中描述的“內部結算發票”的稅率為0的根本原因。至于這個設置“是否符合中國國情”，不在本文討論X圍，自辨。物料主數據的組織單元覆蓋物料既然可以被接單公司（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。Keybination只有一個選擇。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。其中的原理，請自己用上述方式去找尋，不再贅述?？绻句N售訂單或發票的定價過程細節事務代碼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?？纯矗琑D04的傳輸介質是什么？不怕不識貨，就怕貨比貨。標準發票對應的輸出類型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只讀?；匦C公司間發票的系統配置本段落的配置根目錄：IMG→Salesanddistribution→Billing→Interpanybilling，如下圖。這是本段落項下的“總配置目錄”。銷售訂單類型配備公司間發票類型配置路徑：配置根目錄→Defineordertypesforinterpanybilling。定位于標準訂單類型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）的立場來命名。panyCode當然就是接單公司本身，即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,allpanycodesareavailable。理解為“如果最右邊的字段COCD維持空格，系統就默認為供應商10000可以對任何它存在數據記錄的公司代碼都觸發EDI動作創建會計憑證”。請自己驗證。為EDI接收發票分配總賬科目事務代碼：OBCB。如下圖，在系統跳出的小框中，依次輸入LI（供應商）、10000（供貨公司體現的內部供應商）和2200（接單公司的公司代碼）。上圖敲回車進去后，按財務要求輸入總賬科目，文本字段是可選擇項目。IDES系統內是空白，維持不變。當然，這個總賬科目必須是事先在公司代碼中創建好的科目主數據。需要注意的是：總賬科目不可以與CO模塊的任何對象掛鉤，即它不能是成本要素（costelement）。具體詳情，請咨詢FI/CO的顧問。為EDI接收發票分配稅碼事務代碼：OBCD。本定制的作用，在于把來源于銷售訂單中的銷項稅（outputtax）與供應商發票中的進項稅（inputtax）關聯起來。定位到LI·10000的行，確保你交易中可能出現的銷項稅碼能夠關聯到進項稅碼。字段“Taxtype”，用來記錄銷項稅稅碼（Outputtaxcode）；字段“Tx”，用來記錄進項稅稅碼（Inputtaxcode）。馬上產生了問題：我怎么知道供貨方內部結算發票的銷項稅稅碼是哪個？回答：找到那X內部結算發票的，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接受發票的程序參數，最下方有個單位。這個計量單位的定制，有點“小小的講究”。用事務代碼CUNI進入PC的配置。維度什么是