核算口径就是指核算的标准尺码和规范要求。GDP核算口径 GDP、国内生产总值以及地区生产总值属于同一概念指标，但在具体使用上有不同之处。GDP是国内生产总值Gross Domestic Product的英文缩写，我国习惯上将国家和地区的GDP统称为国内生产总值。考虑到Domestic一词有“国内、地区、当地、家里”等多种涵义，故国内外一些专家和学者认为，将全国和地区的GDP一律称为国内生产总值不恰当。为了解决这个问题，国家统计局印发了“国统字[2004]4号文《关于改进和规范地区GDP核算的通知》”，对GDP中文名称的表述作了进一步规范，全国的GDP 称为“国内生产总值”，地区GDP改称为“地区生产总值”，特定地区的GDP用行政区的名字作定语，如“XX省生产总值”，简称为“XX省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页。可以想象，报表使用者从如此庞杂的资料中发现自己所需的信息是何等困难。另外，传统核算模式中的资产负债表虽能提供有一定综合程度的核算指标体系，但也不过是一种固化的指标体系而已，实务工作中不可能改变这种固化的指标体系。