EBS集中采購簡介-Intercompany.doc

集中采購簡介Intercompany 1文檔作者：林業(yè)東創(chuàng)建日期：2009-6-10更新日期：2009-6-10文檔編碼：當前版本：1.0文檔控制變更記錄3日期作者版本變更參考20090610林業(yè)東1.0原始文檔分發(fā)姓名職位分發(fā)拷貝編號姓名位置/崗位1234 目錄文檔控制ii前言4目的4方案設計原則4適用范圍4集中采購詳細解決方案5組織結構5業(yè)務模式5細節(jié)討論8注意問題10設置和操作截圖10已解決/未解決的問題17未解決的問題17已解決的問題17HYT and HAND Confidential - For Internal use only 17前言集中采購，公司間事務處理流之一。主要用于集團式采購業(yè)務中：各子公司向某一子公司（簡稱A）傳達采購需求；A向供應商下達采購訂單，供應商將貨物直接送至需求分公司。然后，A與供應商結算，A與其他子公司用公司間應收應付結算。本文用HK和SZ作為兩個子公司的簡稱，企圖隱藏企業(yè)的真實信息，但百密一疏，上了截圖后就起不到隱藏的目的了。目的本文檔主要是與大伙探討集中采購的方案與應用，拋磚引玉。方案設計原則適用范圍集中采購詳細解決方案組織結構組織結構某企業(yè)有一香港子公司（以下簡稱HK），一深圳子公司（以下簡稱SZ）。反映在系統(tǒng)內的組織架構如下：業(yè)務模式業(yè)務模式SZ子公司有采購、庫存、生產、銷售等業(yè)務；而其中的采購業(yè)務一分為二，部分是向海外供應商采購的。海外采購如果能集中報關，則能省時省力，提高效率。于是設立HK子公司，專門負責SZ子公司的海外采購。而事實上，HK子公司并無實際的倉庫，實物是直接發(fā)到SZ，但帳上需要經過HK的庫存。業(yè)務鏈：SZ子公司傳達采購需求HK子公司接收需求，并向供應商下訂單貨到，HK暫收并報關SZ接收、檢驗、入庫；財務上：公司間應收、應付，HK子公司對供應商的應付。（為簡化討論，這里僅以兩個子公司為例。更多的子公司，也只是擴展一下以上業(yè)務鏈而已（例如在HK子公司和SZ子公司之間再增加廣州子公司，上海子公司），對方案整體不會構成大的影響。）方案匹配如果讓系統(tǒng)一步一步來實現(xiàn)業(yè)務，則有以下步驟（方案1）：1、 SZ向HK下PO；2、 HK接到SZ的PO，錄入為SO；3、 HK根據(jù)SO及庫存量，以決定需向供應商下的PO；4、 HK接收貨物并入庫；5、 HK應付；6、 HK銷售出庫；7、 SZ接收、檢驗、入庫。8、 HK與SZ公司間應收應付。為簡化討論，可以先忽略財務上的步驟5、8。接下來，我們會覺得也許內部銷售能派上用場（方案2）：1、 SZ下Internal PR2、 HK導入SZ的PR并創(chuàng)建Internal SO3、 HK創(chuàng)建PO4、 HK接收入庫5、 HK銷售發(fā)運6、 SZ接收檢驗入庫這里，第6步是必需的，因為SZ檢驗這一步需要在系統(tǒng)內反映，所以無法將發(fā)運網(wǎng)絡的轉移類型設置為“直接”。比起方案1，簡化了錄入SO的操作。但是，如果業(yè)務量大，則各訂單行和價格的反復錄入、同一物料的入庫和出庫等操作難免出錯，多次審批既耽誤時間也影響心情。綜上所述，操作繁雜；接下來的目標是把重復的操作簡化掉。當我們重新審視這一業(yè)務現(xiàn)狀，會發(fā)現(xiàn)其實集中采購剛好能滿足需求（方案3）：1、 SZ創(chuàng)建PR2、 HK引用SZ的PR創(chuàng)建PO3、 SZ接收、檢驗、入庫（系統(tǒng)同時自動生成HK的接收、入庫和銷售出庫事務處理記錄）通過對比，方案3挺好。當然，若干細節(jié)有待后面討論。流程圖采用R12的集中采購流程詳解：1、 HK_OU內創(chuàng)建全局一攬子協(xié)議2、 SZ創(chuàng)建PR3、 SZ引用HK的BPA創(chuàng)建標準訂單（全局一攬子協(xié)議只能被創(chuàng)建成標準訂單；該訂單是HK向供應商下的單。訂單所在的OU=HK_OU，SHIP_TO_ORGANIZATION_CODE=SZ_INV）4、 HK根據(jù)該標準訂單，對抵港的貨物作接收5、 HK應付6、 HK將貨物轉移至SZ，SZ在系統(tǒng)內作轉移操作7、 SZ錄入檢驗結果8、 SZ入庫9、 創(chuàng)建公司間應收發(fā)票、公司間應付發(fā)票細節(jié)討論逆向物流集中采購操作起來挺簡單，但是是否支持退貨呢？以前曾看過某個同事的文章，說這種公司間事務在11I里不支持退貨。經過測試，集中采購在R12里支持退貨的，所有操作跟一般的采購退貨無異；而且也會在HK內生成逆向的邏輯事務處理。價格控制價格問題比較敏感。HK以什么價格銷售給SZ？業(yè)務上有兩種選擇：1、 HK以采購價格銷售給SZ；2、 HK以不同于采購的價格銷售給SZ。系統(tǒng)內，公司間事務處理流設置時可以選擇以上任一種價格模式；而且可為資產物料和費用物料分別選擇不同的模式。計劃在SZ_INV運行的MRP，是否會把集中采購所創(chuàng)建的HK的標準訂單考慮為供應呢？集中采購模式下，SZ只有一張普通的PR，并沒有SZ直接下給HK的PO；而PR一旦經過自動創(chuàng)建，則成為了HK向供應商下達的標準訂單。所以，我們很想知道，該標準訂單對SZ的MRP會有怎樣的影響。實際上，SZ跑的MRP會把該標準訂單考慮為供應，而該訂單的變更對計劃的影響跟SZ本身的訂單是無異的。（這一點是項目上的同事幫忙測的）事務處理及分錄當從接收到檢驗、入庫整個過程完成后，會生成以下事務處理及分錄。這里，HK的邏輯銷售并沒有產生R12所特有的遞延銷貨成本的分錄，而是直接生成銷貨成本了。退貨流程會沿著以上路徑從下往上生成相反的分錄。財務首先是HK對供應商的應付，這個跟一般的采購無異。然后是公司間的應收和應付發(fā)票，其產生有嚴格的先后順序。1、 創(chuàng)建公司間應收發(fā)票2、 HK AR職責下“自動開票主程序”3、 創(chuàng)建公司間應付發(fā)票4、 SZ AP職責下“應付款管理系統(tǒng)開放接口導入”這些票據(jù)之間，有何聯(lián)系？HK的AR發(fā)票，參考一欄里正是標準訂單的編號；（假設發(fā)票編號為10000）SZ的AP發(fā)票編號，為 HK的AR發(fā)票編號+HK所在的OU id，例如“10000-82”注意問題注意問題1、 兩個OU的本位幣是否相同？一般來說，HK跟SZ兩個子公司對應的幣種應該是不同的，則做集中采購的時候，要注意幣種間的折換率。2、分錄是否完整產生？需要耐心的檢查和測試了。3、生成的標準訂單如何控制價格？該標準訂單是引用一攬子協(xié)議生成的，如果協(xié)議上沒允許修改價格，則標準訂單像一攬子發(fā)放一樣也是不能隨意更改價格的。4、HK銷售給SZ的價格如何控制？前面提到，有兩種方式可以選擇。如果設置銷售價格贊同于PO，則一切不用費心。如果設置銷售價格來自內部價目表，則需要在客戶地點收貨方處關聯(lián)內部價目表。5、外部供應商是否需要在兩個OU下都建立地點？其實不必，只需要在HK所在OU下建立地點即可。設置和操作截圖設置截圖1、 幣種折換率2、 內部價目表（可選）3、 外部供應商，（內部）客戶、（內部）供應商4、 公司間事務處理流4.1設置業(yè)務的起點和終點4.2 設置HK銷售價格的來源4.2 設置公司間AR，AP發(fā)票信息操作截圖1、 HK創(chuàng)建全局一攬子協(xié)議2、 SZ創(chuàng)建PR3、 PR引用全局一攬子協(xié)議創(chuàng)建成HK的標準PO4、 接收至入庫5、 HK應付6、 公司間應收7、 公司間應付1.1 一攬子協(xié)議選擇“全局”。必須在建立協(xié)議時就勾選，否則就改不了了。注意：該協(xié)議，是在HK的OU下建立的。1.2 工具啟用組織里，加上紅框所示的記錄，表示從SZ請求，HK采購。3.1 創(chuàng)建標準訂單對于集中采購，這里只能選標準PO；因為全局一攬子協(xié)議是無法創(chuàng)建為一攬子發(fā)放的。4.1 接收、檢驗和入庫時，要選擇SZ_INV，HK所在OU至于為什么要這樣，我是給客戶這樣解釋的：訂單是HK子公司直接下給供應商，因而OU要選HK_OU；而貨物最