核算口徑就是指核算的標準尺碼和規範要求。GDP核算口徑 GDP、國內生產總值以及地區生產總值屬於同一概念指標，但在具體使用上有不同之處。?>GDP是國內生產總值Gross Domestic Product的英文縮寫，我國習慣上將國家和地區的GDP統稱為國內生產總值。考慮到Domestic一詞有“國內、地區、當地、家裡”等多種涵義，故國內外一些專家和學者認為，將全國和地區的GDP一律稱為國內生產總值不恰當。為了解決這個問題，國家統計局印發了“國統字[2004]4號文《關於改進和規範地區GDP核算的通知》”，對GDP中文名稱的表述作了進一步規範，全國的GDP 稱為“國內生產總值”，地區GDP改稱為“地區生產總值”，特定地區的GDP用行政區的名字作定語，如“XX省生產總值”，簡稱為“XX省GDP”。按照這一規定，常州市的GDP應稱為“常州市生產總值”，如果在套用數據時不帶“常州市”，則稱為地區生產總值。
基本介紹
- 中文名：核算口徑
- 外文名：Accounting caliber
- 規格：規範要求
- 特點：國內生產總值以及地區生產總值
GDP核算口徑,統一核算口徑,核算口徑固化,
GDP核算口徑
ERP與CRM集成從統一核算口徑開始 ERP與CRM系統現在已經是企業信息化管理不可或缺的兩大管理工具。不過大部分企業存在一個嚴重的問題，就是這兩個系統相互獨立，無法協同工作。這就好象兩個部門之間存在一條難以跨越的鴻溝一樣，給日常工作帶來了很大的不便。那么該如何做好他們之間的集成工作呢，讓ERP系統與CRM系統之間的信息流能夠暢通無阻的流動?對此筆者認為，如果要做好兩者的集成，那么要從統一核算口徑開始。
統一核算口徑
一、統一計稅口徑。
眾所周知，銷售價格中其實包括兩個部分，一是銷售商品的實際價格，二是銷售商品的增值稅。雖然銷售報價的時候，可以將兩部分的價格合在一起報。但是在ERP系統中進行最後核算的時候，如開發票或者核算銷售利潤的時候，是要將兩者分開來考慮的。為此如果要將兩個系統進行集成，那么在這個計稅的口徑上就要統一。在實際工作中，這個統一主要有兩個方法。
一是直接統一。如果CRM系統中給客戶報價採用的是含稅價(即將兩部分價格合併起來報給客戶)，那么在ERP系統相關核算中最好也能夠採用這個含稅價。如在應收帳款核算中，也設定為含稅價。然後讓系統在開發票的時候，能夠自動根據稅收比例來實現價稅分離。這是一個比較理想的方法，可以避免過多轉換而帶來的誤差問題。
二是間接的方法。間接的方法就是指在兩個系統數據進行同步的時候，讓系統採用公式進行轉換。如在CRM系統中採用的是含稅價格，而在ERP系統中採用的是不含稅價格。那么可以在數據同步的時候，在原有價格的基礎上處以17%來實現價稅分離。不過這個方法並不是很好的處理方法。因為在現實中，基本上除以17%都是除不通的，會有小數的產生。此時就需要考慮要保留幾位小數為好。為了儘量的減少誤差，這個小數位數比較有講究。如果採用直接統一的方式，那么系統就會自動採用ERP系統中定義的精度。故採用這個間接的方式時，一般需要先考慮一下ERP系統設定的精度，或者說將小數位數後面留的多一點。然後讓系統在根據實際情況來自動截取需要的精度。
在統一計稅口徑的時候，還需要注意一個問題。即在計算稅額的時候，是以整張訂單的銷售額為基礎，還是按單項來計稅。如現在有一張銷售訂單其銷售金額為500萬，一共有30個產品，每個產品的價格都不一樣。此時計算增值稅的時候，有兩個方法。一是以整個銷售訂單的金額來計算增值稅，即直接以500萬乘以稅率。二是單項計稅，即將每個產品的銷售價格乘以稅率，然後進行累加。由於兩種計稅方法不同，在實際工作中兩者的結果往往是不同的。為了減少CRM系統與ERP系統之間誤差，最好能夠統一這個計稅的口徑。
這個計稅的口徑對於CRM系統與ERP系統中的財務模組集成非常的關鍵。有時候只差一分錢對於銷售金額等統計可能不怎么重要。但是對於財務模組的報表、發票等等就非常的關鍵。即使只相差一分錢，就可能需要通過成本調整等作業來調整。這明顯就會增加工作量。所以計稅口徑的統一對於兩個系統能夠實現無縫的連線，非常的關鍵。
二、統一客戶信用額度的管理方式。
客戶信用額度管控不僅僅在CRM系統中有所體現，在ERP系統中也會有所控制。如對於CRM系統來說，如果客戶的信用額度不夠，那么就可能不能夠接受客戶的訂單。而對於ERP系統來說，如果客戶信用額度餘額不足，那么可能允許接受用戶的訂單，但是不允許將用戶的訂單轉為生產或者採購，或者說最終不能夠出貨。直到客戶付款保證有足夠多的信用額度餘額後才能夠安排採購生產或者出貨等等。為此這個信用額度的統一也非常的重要。這主要體現在如下幾個方面。
一是金額要統一，這也是最基本的。在實際工作中，往往會為不同的客戶設定不同的信用額度。如果客戶比較多的話，要保證這個金額的統一也比較困難。筆者這裡建立企業可以採用如下兩個方式。一是更改應用程式的後台代碼，讓他們同時調用相同的表格。二是通過資料庫觸發器等代碼，實現在某個系統下更改信用額度後自動更改另外一個系統的數據，從而實現數據的同步更新。
二是控制的方法要統一。當客戶的信用額度不夠時，該如何處理呢?在現實工作中有很多種處理方式。如是否允許超過一定的信用額度;如當信用額度不足的時候，是否可以接受客戶的訂單，而只是不做後續的處理;或者說可以安排進行正常的採購生產而只是出貨的時候不允許而已，等等。採取的控制方法不同，往往會導致截然不同的後果。針對這種情況，就有必要讓兩個系統之間的控制方法保證統一。否則的話，就很容易出現兩個系統相互打架的情況。
除了信用額度之外，付款條件也是類似的道理。在CRM系統中下客戶訂單或者建立客戶信息的時候，需要同時指定客戶的付款條件。而在ERP系統中根據出貨單來統計應付帳款等內容的時候，也有這方面的要求。如果想讓兩個系統中推算出來的應收帳款日期與金額一直，那么必須確保兩套系統之間有相同的付款條件。
三、統一兩套系統核算的日期。
正常情況下企業是按自然月來進行核算。但是也有企業有特殊的要求。如有些企業業務比較多，如果按每月的30日作為結帳日期，那么企業發票驗證等等都會比較趕。為此有不少的企業，他們會將結帳日期提前，如將結帳日期設定為25日等等。有時候客戶也會有類似的要求。如他們要求如果25日以後出的貨，都要算下個月等等。這主要是為了核算方便的需要。但是這在系統核算上會遇到不少的麻煩。如有些用戶會不小心的將11月26日的出貨錄入到11月份。而本來應該統計到12月份中去。
為此企業如果在業務核算上不是按自然月來的，那么在兩套系統集成的時候，要確保他們的核算日期是一致的。如CRM系統中設定的結帳日期是28日(往往是客戶要求的)。那么在ERP系統中關於這筆業務的相關核算口徑，其結帳日期也要設定在28日。不然的話，兩套系統在出報表等統計數據的時候，會出現差錯。
四、用戶信息要保持一致。
無論是在ERP系統還是在CRM系統中，很多時候需要根據用戶信息來統計相關的信息。如需要統計某個業務員的接單情況，如需要統計某個業務員的應收帳款情況等等。這些信息可以在CRM系統中統計，也可以在ERP系統中統計。不過筆者建議是在ERP系統中統計。因為ERP系統中可能會有人事考勤等模組。而這些模組中也需要用到這個結果。所以在ERP中進行統計分析可以免去不少的後續工作。
不過無論是在哪個系統中統計，有一個前提就是用戶信息要保持一致。如當某個業務員走了，那么需要在兩個系統中都及時更新相關的數據。而且同一個業務員其代碼大小寫等等都要完全相同。因為默認情況下系統在統計數據的時候都是區分大小寫的。當然最理想的情況就是在系統集成的時候，能夠讓兩個系統共用一張用戶信息表。如此就不會存在用戶信息不一致而導致的報表結果出現誤差的情況。
總之在系統集成的時候，關鍵就是要保證核算口徑的統一。否則的話，可能在兩個系統中出的結果會有相互打架的情況。雖然這只是誤差，而不是錯誤。但是在實際工作中，這仍然是不允許的。
核算口徑固化 核算口徑是指核算時所遵循的核算標準，主要體現在科目設定方面。這是因為會計核算是在設定的賬戶中進行的，而賬戶又是按會計科目開設的，因而科目設定口逕自然也就決定了會計核算口徑。傳統核算模式的核算口徑固化主要表現在兩個方面。
核算口徑固化
1. 會計核算科目固化。手工方法下，傳統核算模式的所有會計科目和級別都是固定的，不能隨意改變科目名稱和打亂科目級別。例如，管理費用的二級明細科目通常按費用發生地點設定，三級明細科目再按費用種類設定，這種科目設定口徑只能對管理費用按發生地點進行二級核算，而不能按費用種類進行二級核算。反之，若二級明細科目按費用種類設定，三級明細科目再按費用發生地點設定，則又無法按費用發生地點進行二級核算。科目固化必然導致提供的核算指標固化，不能滿足管理的需求。
2. 會計報表指標固化。手工方法下，傳統核算模式的會計報表格式是固定的，所能提供的核算指標也是固化的，無法滿足不同類型會計信息使用者的要求。為了解決會計信息的供需矛盾，不得不在會計報表後面附註大量說明，造成會計信息相關度低、冗餘度大。據美國會計專家預測，至2010年會計報表附註的平均長度將達到200頁。可以想像，報表使用者從如此龐雜的資料中發現自己所需的信息是何等困難。另外，傳統核算模式中的資產負債表雖能提供有一定綜合程度的核算指標體系，但也不過是一種固化的指標體系而已，實務工作中不可能改變這種固化的指標體系。
