erp系統(tǒng)免費下載與CRM集成從統(tǒng)一核算口徑開始

erp系統(tǒng)免費下載與CRM系統(tǒng)現(xiàn)在已經(jīng)是企業(yè)信息化管理不可或缺的兩大管理工具。不過大部分企業(yè)存在一個嚴重的問題，就是這兩個系統(tǒng)相互獨立，無法協(xié)同工作。這就好象兩個部門之間存在一條難以跨越的鴻溝一樣，給日常工作帶來了很大的不便。那么該如何做好他們之間的集成工作呢，讓erp系統(tǒng)下載與CRM系統(tǒng)之間的信息流能夠暢通無阻的流動?對此筆者認為，如果要做好兩者的集成，那么要從統(tǒng)一核算口徑開始。

一、統(tǒng)一計稅口徑。

眾所周知，銷售價格中其實包括兩個部分，一是銷售商品的實際價格，二是銷售商品的增值稅。雖然銷售報價的時候，可以將兩部分的價格合在一起報。但是在erp系統(tǒng)下載中進行最后核算的時候，如開發(fā)票或者核算銷售利潤的時候，是要將兩者分開來考慮的。為此如果要將兩個系統(tǒng)進行集成，那么在這個計稅的口徑上就要統(tǒng)一。在實際工作中，這個統(tǒng)一主要有兩個方法。

一是直接統(tǒng)一。如果CRM系統(tǒng)中給客戶報價采用的是含稅價(即將兩部分價格合并起來報給客戶)，那么在erp系統(tǒng)下載相關核算中最好也能夠采用這個含稅價。如在應收帳款核算中，也設置為含稅價。然后讓系統(tǒng)在開發(fā)票的時候，能夠自動根據(jù)稅收比例來實現(xiàn)價稅分離。這是一個比較理想的方法，可以避免過多轉換而帶來的誤差問題。

二是間接的方法。間接的方法就是指在兩個系統(tǒng)數(shù)據(jù)進行同步的時候，讓系統(tǒng)采用公式進行轉換。如在CRM系統(tǒng)中采用的是含稅價格，而在erp系統(tǒng)下載中采用的是不含稅價格。那么可以在數(shù)據(jù)同步的時候，在原有價格的基礎上處以17%來實現(xiàn)價稅分離。不過這個方法并不是很好的處理方法。因為在現(xiàn)實中，基本上除以17%都是除不通的，會有小數(shù)的產(chǎn)生。此時就需要考慮要保留幾位小數(shù)為好。為了盡量的減少誤差，這個小數(shù)位數(shù)比較有講究。如果采用直接統(tǒng)一的方式，那么系統(tǒng)就會自動采用erp系統(tǒng)下載中定義的精度。故采用這個間接的方式時，一般需要先考慮一下erp系統(tǒng)下載設置的精度，或者說將小數(shù)位數(shù)后面留的多一點。然后讓系統(tǒng)在根據(jù)實際情況來自動截取需要的精度。

在統(tǒng)一計稅口徑的時候，還需要注意一個問題。即在計算稅額的時候，是以整張訂單的銷售額為基礎，還是按單項來計稅。如現(xiàn)在有一張銷售訂單其銷售金額為500萬，一共有30個產(chǎn)品，每個產(chǎn)品的價格都不一樣。此時計算增值稅的時候，有兩個方法。一是以整個銷售訂單的金額來計算增值稅，即直接以500 萬乘以稅率。二是單項計稅，即將每個產(chǎn)品的銷售價格乘以稅率，然后進行累加。由于兩種計稅方法不同，在實際工作中兩者的結果往往是不同的。為了減少CRM 系統(tǒng)與erp系統(tǒng)下載之間誤差，最好能夠統(tǒng)一這個計稅的口徑。

這個計稅的口徑對于CRM系統(tǒng)與erp系統(tǒng)下載中的財務模塊集成非常的關鍵。有時候只差一分錢對于銷售金額等統(tǒng)計可能不怎么重要。但是對于財務模塊的報表、發(fā)票等等就非常的關鍵。即使只相差一分錢，就可能需要通過成本調整等作業(yè)來調整。這明顯就會增加工作量。所以計稅口徑的統(tǒng)一對于兩個系統(tǒng)能夠實現(xiàn)無縫的連接，非常的關鍵。

二、統(tǒng)一客戶信用額度的管理方式。

客戶信用額度管控不僅僅在CRM系統(tǒng)中有所體現(xiàn)，在erp系統(tǒng)下載中也會有所控制。如對于CRM系統(tǒng)來說，如果客戶的信用額度不夠，那么就可能不能夠接受客戶的訂單。而對于erp系統(tǒng)下載來說，如果客戶信用額度余額不足，那么可能允許接受用戶的訂單，但是不允許將用戶的訂單轉為生產(chǎn)或者采購，或者說最終不能夠出貨。直到客戶付款保證有足夠多的信用額度余額后才能夠安排采購生產(chǎn)或者出貨等等。為此這個信用額度的統(tǒng)一也非常的重要。這主要體現(xiàn)在如下幾個方面。

一是金額要統(tǒng)一，這也是最基本的。在實際工作中，往往會為不同的客戶設置不同的信用額度。如果客戶比較多的話，要保證這個金額的統(tǒng)一也比較困難。筆者這里建立企業(yè)可以采用如下兩個方式。一是更改應用程序的后臺代碼，讓他們同時調用相同的表格。二是通過數(shù)據(jù)庫觸發(fā)器等代碼，實現(xiàn)在某個系統(tǒng)下更改信用額度后自動更改另外一個系統(tǒng)的數(shù)據(jù)，從而實現(xiàn)數(shù)據(jù)的同步更新。

二是控制的方法要統(tǒng)一。當客戶的信用額度不夠時，該如何處理呢?在現(xiàn)實工作中有很多種處理方式。如是否允許超過一定的信用額度;如當信用額度不足的時候，是否可以接受客戶的訂單，而只是不做后續(xù)的處理;或者說可以安排進行正常的采購生產(chǎn)而只是出貨的時候不允許而已，等等。采取的控制方法不同，往往會導致截然不同的后果。針對這種情況，就有必要讓兩個系統(tǒng)之間的控制方法保證統(tǒng)一。否則的話，就很容易出現(xiàn)兩個系統(tǒng)相互打架的情況。

除了信用額度之外，付款條件也是類似的道理。在CRM系統(tǒng)中下客戶訂單或者建立客戶信息的時候，需要同時指定客戶的付款條件。而在erp系統(tǒng)下載中根據(jù)出貨單來統(tǒng)計應付帳款等內(nèi)容的時候，也有這方面的要求。如果想讓兩個系統(tǒng)中推算出來的應收帳款日期與金額一直，那么必須確保兩套系統(tǒng)之間有相同的付款條件。

三、統(tǒng)一兩套系統(tǒng)核算的日期。

正常情況下企業(yè)是按自然月來進行核算。但是也有企業(yè)有特殊的要求。如有些企業(yè)業(yè)務比較多，如果按每月的30日作為結帳日期，那么企業(yè)發(fā)票驗證等等都會比較趕。為此有不少的企業(yè)，他們會將結帳日期提前，如將結帳日期設置為25日等等。有時候客戶也會有類似的要求。如他們要求如果25日以后出的貨，都要算下個月等等。這主要是為了核算方便的需要。但是這在系統(tǒng)核算上會遇到不少的麻煩。如有些用戶會不小心的將11月26日的出貨錄入到11月份。而本來應該統(tǒng)計到12月份中去。

為此企業(yè)如果在業(yè)務核算上不是按自然月來的，那么在兩套系統(tǒng)集成的時候，要確保他們的核算日期是一致的。如CRM系統(tǒng)中設置的結帳日期是28日 (往往是客戶要求的)。那么在erp系統(tǒng)下載中關于這筆業(yè)務的相關核算口徑，其結帳日期也要設置在28日。不然的話，兩套系統(tǒng)在出報表等統(tǒng)計數(shù)據(jù)的時候，會出現(xiàn)差錯。

四、用戶信息要保持一致。

無論是在erp系統(tǒng)下載還是在CRM系統(tǒng)中，很多時候需要根據(jù)用戶信息來統(tǒng)計相關的信息。如需要統(tǒng)計某個業(yè)務員的接單情況，如需要統(tǒng)計某個業(yè)務員的應收帳款情況等等。這些信息可以在CRM系統(tǒng)中統(tǒng)計，也可以在erp系統(tǒng)下載中統(tǒng)計。不過筆者建議是在erp系統(tǒng)下載中統(tǒng)計。因為erp系統(tǒng)下載中可能會有人事考勤等模塊。而這些模塊中也需要用到這個結果。所以在erp系統(tǒng)免費下載中進行統(tǒng)計分析可以免去不少的后續(xù)工作。

不過無論是在哪個系統(tǒng)中統(tǒng)計，有一個前提就是用戶信息要保持一致。如當某個業(yè)務員走了，那么需要在兩個系統(tǒng)中都及時更新相關的數(shù)據(jù)。而且同一個業(yè)務員其代碼大小寫等等都要完全相同。因為默認情況下系統(tǒng)在統(tǒng)計數(shù)據(jù)的時候都是區(qū)分大小寫的。當然最理想的情況就是在系統(tǒng)集成的時候，能夠讓兩個系統(tǒng)共用一張用戶信息表。如此就不會存在用戶信息不一致而導致的報表結果出現(xiàn)誤差的情況。

總之在系統(tǒng)集成的時候，關鍵就是要保證核算口徑的統(tǒng)一。否則的話，可能在兩個系統(tǒng)中出的結果會有相互打架的情況。雖然這只是誤差，而不是錯誤。但是在實際工作中，這仍然是不允許的。