在SAP系統(tǒng)中有標(biāo)準(zhǔn)的服務(wù)性訂單，可以詳細(xì)的規(guī)劃每個階段的付款情況。如以SAP項目為例，可以分為需求調(diào)研、流程優(yōu)化等幾個階段。每個階段開始后都要付階段性的款。通過SAP標(biāo)準(zhǔn)的服務(wù)性訂單可以實現(xiàn)付款的跟蹤。但是這個服務(wù)性訂單配置和操作工作量比較大。在實際項目中，真正利用這個功能來操作服務(wù)性項目的案例并不多。在這里，筆者要給各位介紹的是一個替代方案。

　　一、業(yè)務(wù)介紹。

　　現(xiàn)在某個客戶有這么一個需求。他們要求了一家咨詢機(jī)構(gòu)對企業(yè)的流程進(jìn)行優(yōu)化。這項工作大致可以分為需求調(diào)研、流程重組、業(yè)務(wù)培訓(xùn)、項目上線等四個階段。這項業(yè)務(wù)總的金額為100萬，其中合同簽訂后付30萬、流程重組確認(rèn)后付30萬、業(yè)務(wù)培訓(xùn)后付20萬、項目上線后付10萬、上線三個月后付10萬。

　　一開始筆者建議客戶通過“服務(wù)性訂單”來實現(xiàn)這個業(yè)務(wù)。不過客戶反應(yīng)說沒有必要控制的這么嚴(yán)格。他們要求只需要控制總的費(fèi)用即可。即花在這個項目上的總的金額不超過100萬。了解用戶的需求后，筆者最后建議用戶通過框架性訂單來實現(xiàn)這個需求。

　　二、采購訂單管理。

　　在SAP系統(tǒng)的標(biāo)準(zhǔn)功能中，有一個采購訂單類型叫做“框架型訂單”，其是消耗性采購的一個衍生。不過這個功能一直被顧問或者用戶所忽視。不過筆者在實際項目中，一般都會推薦用戶采用這個功能。因為通過這個功能，可以在一定程度上實現(xiàn)費(fèi)用預(yù)算的功能。而不用去啟動SAP的費(fèi)用預(yù)算流程或者服務(wù)性訂單。

　　這主要跟國內(nèi)客戶的現(xiàn)狀有關(guān)。國內(nèi)企業(yè)的預(yù)算管理或者服務(wù)性供應(yīng)商那個管理的現(xiàn)狀，往往是只管粗，不管細(xì)。簡單的說，就是只管最終的結(jié)果，對于中間過程控制的比較少。如果要用SAP的標(biāo)準(zhǔn)管理流程來管理這些業(yè)務(wù)，可能會適得其反。在這種情況下，采用框架采購訂單來管理，相對來說可能更加合適。對于框架采購訂單，主要要關(guān)注如下幾個參數(shù)。

　　1、 有效期。

　　服務(wù)性項目一般都要有個有效期。如在一年內(nèi)完成這個項目，總共金額是多少。如果是超期的話，則付款就會有問題。為此在采購訂單上，需要輸入一個有效期。在事務(wù)中需要注意的是，這個有效期往往不是項目結(jié)束的日期，而是最后一筆付款的日期。這中間會有一個類似質(zhì)保期的時間段在里面。

　　2、 沒有物料編碼。

　　對于類似的服務(wù)，或者費(fèi)用預(yù)算，往往沒有物料編碼。為此其從本質(zhì)上來講，是為某個成本中心采購。所以其走的是消耗性采購流程。在采購訂單的科目分配類別中就要選擇為成本中心采購。同時，又需要限制其總金額，就需要在賬戶分配中選擇B限制這個參數(shù)。這兩個參數(shù)結(jié)合起來，就表示為某個成本中心總共花費(fèi)不超過多少的金額。

　　3、 期望值和限制值。

　　最后在采購訂單上要維護(hù)一個金額。在標(biāo)準(zhǔn)功能中，框架型訂單可以維護(hù)兩個金額，分別是期望值和限制值。往往是期望值大于等于限制值。這兩個金額有不同的作用。期望值一般是用來做審批用。其主要包含總的項目費(fèi)用和可能會意外支付的費(fèi)用，如項目做的好的話給項目實施方的獎勵。而限制值就是實實在在需要支付的費(fèi)用。在做采購訂單的審批策略時，需要以期望值作為對象。

　　三、采購收貨管理。

　　在標(biāo)準(zhǔn)功能中，框架性采購訂單是不用收貨的。在后臺配置中，根據(jù)項目類別和賬戶類別對收貨功能是禁用的。不過在實際項目中，可能需要對這個進(jìn)行適當(dāng)?shù)恼{(diào)整。如以這個咨詢項目為例，需要對項目的各個階段進(jìn)行驗收。只有驗收完畢后，才可以進(jìn)行付款申請環(huán)節(jié)(發(fā)票驗證流程)。

　　為了實現(xiàn)這個控制目的，就需要調(diào)整后臺配置，啟用框架性訂單的收貨功能。一般建議是復(fù)制相關(guān)參數(shù)，重新配置一個功能出來，而不建議對標(biāo)準(zhǔn)參數(shù)進(jìn)行調(diào)整。啟用收貨功能后，每個項目環(huán)節(jié)完畢需要驗收時，就在系統(tǒng)中做一個虛擬收貨的動作。由于是費(fèi)用性采購，為此收貨后并不會形成庫存，而是直接消耗到成本中心。這里需要注意的是，項目環(huán)節(jié)的驗收工作需要在體外做，系統(tǒng)內(nèi)只是記錄驗收成功這樣一個記錄。簡單的說，就是用戶憑驗收合格的單據(jù)在系統(tǒng)里做一個收貨的動作。如果驗收不合格，就不做收貨單據(jù)。如此的話，系統(tǒng)就不能夠走后續(xù)的流程。

　　這里另外要強(qiáng)調(diào)一點。在框架性采購訂單中，其默認(rèn)的采購數(shù)量是1。為此在收貨時，要根據(jù)付款的百分比，來輸入收貨的數(shù)量。簡單的說，就是將采購數(shù)量當(dāng)作是100%。然后根據(jù)各個階段付款的百分比，來輸入收貨的數(shù)量。

　　當(dāng)然，如果要啟用框架性訂單的收貨功能，會涉及到后臺配置或者簡單的增強(qiáng)。在通過框架性訂單來實現(xiàn)服務(wù)性采購或者費(fèi)用預(yù)算的管理，這是一個非標(biāo)準(zhǔn)的功能。不過比起啟用整個費(fèi)用預(yù)算模塊或者服務(wù)性訂單來說，這點工作量并不是很大。

　　四、發(fā)票驗證管理。

　　發(fā)票驗證需要分兩種情況，即需要區(qū)分是否收貨。如果收貨的話，則發(fā)票的金額會根據(jù)收貨帶過來。而不收貨的話，其金額不會自動帶出。筆者這里以標(biāo)準(zhǔn)功能為例，說明一下框架性訂單的發(fā)票驗證過程。

　　根據(jù)普通的消耗型采購不一樣，如果沒有收貨，框架性采購訂單在發(fā)票驗證時是帶不出金額的。普通的消耗型采購訂單，如果沒有收貨，會帶出采購訂單的數(shù)量和金額。這個區(qū)別，在業(yè)務(wù)推進(jìn)過程中，要跟用戶重點強(qiáng)調(diào)一下。

　　在發(fā)票驗證時，用戶需要根據(jù)實際發(fā)票的金額或者管理層同意支付的金額為準(zhǔn)，通過“科目分配”功能來輸入金額。這里還有一個好處，就是可以更改成本中心。如果項目一開始不能夠確認(rèn)成本中心，直接記錄的是公司的成本中心。后來確定需要對成本中心進(jìn)行細(xì)分，就可以在這里更改。不過大部分情況下，不會對成本中心進(jìn)行調(diào)整。

　　五、框架性訂單的缺陷。

　　利用框架性訂單來實現(xiàn)項目或者費(fèi)用預(yù)算控制，其優(yōu)勢是非常明顯的。其管理靈活、而且工作量明顯降低很多。但是其缺陷也是顯而易見的。即這個費(fèi)用控制是粗放的。簡單的說，其沒有細(xì)化到項目或者費(fèi)用的每個階段，而是做一個整體的預(yù)算管理。

　　在實際項目中，是否要啟用這個功能，主要還是看企業(yè)對預(yù)算管理的要求。如果只是一些粗放型的管理，即只是對結(jié)果的記錄和控制，則使用框架性采購訂單完全可以滿足要求。如果要實現(xiàn)更加細(xì)致的管理(要中間各個環(huán)節(jié)的控制)，就需要考慮啟用服務(wù)性采購訂單或者費(fèi)用預(yù)算來實現(xiàn)。當(dāng)然，要啟用這些功能，用戶需要花費(fèi)更多的時間和精力。畢竟天下沒有白吃的午餐。

總結(jié)

以上是生活随笔為你收集整理的SAP中服务性订单的替代解决方案的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。