-
核算口徑
鎖定
核算口徑就是指核算的標準尺碼和規範要求。GDP核算口徑 GDP、國內生產總值以及地區生產總值屬於同一概念指標，但在具體使用上有不同之處。GDP是國內生產總值Gross Domestic Product的英文縮寫，我國習慣上將國家和地區的GDP統稱為國內生產總值。考慮到Domestic一詞有“國內、地區、當地、家裏”等多種涵義，故國內外一些專家和學者認為，將全國和地區的GDP一律稱為國內生產總值不恰當。為了解決這個問題，國家統計局印發了“國統字[2004]4號文《關於改進和規範地區GDP核算的通知》”，對GDP中文名稱的表述作了進一步規範，全國的GDP 稱為“國內生產總值”，地區GDP改稱為“地區生產總值”，特定地區的GDP用行政區的名字作定語，如“XX省生產總值”，簡稱為“XX省GDP”。按照這一規定，常州市的GDP應稱為“常州市生產總值”，如果在應用數據時不帶“常州市”，則稱為地區生產總值。
- 中文名
- 核算口徑
- 外文名
- Accounting caliber
- 規 格
- 規範要求
- 特 點
- 國內生產總值以及地區生產總值
核算口徑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. 會計核算科目固化。手工方法下，傳統核算模式的所有會計科目和級別都是固定的，不能隨意改變科目名稱和打亂科目級別。例如，管理費用的二級明細科目通常按費用發生地點設置，三級明細科目再按費用種類設置，這種科目設置口徑只能對管理費用按發生地點進行二級核算，而不能按費用種類進行二級核算。反之，若二級明細科目按費用種類設置，三級明細科目再按費用發生地點設置，則又無法按費用發生地點進行二級核算。科目固化必然導致提供的核算指標固化，不能滿足管理的需求。
- 詞條統計
-
- 瀏覽次數：次
- 編輯次數：8次歷史版本
- 最近更新： 盛开的希望之花