在业财一体_第1部分里我们举了一个简单的例子，如果由业务信息生成简单的核算分录

经营行为：

公司采购部门购买了一批材料，花了100万；

系统中的业务信息：

程序逻辑：

如果这个表单里新增了一行记录，那么生成凭证：

现在稍微复杂一点，公司的经营活动不仅采购原材料，也要采购机器设备，假设公司又花了200万采购了一台机器，因为机器设备不属于原材料，所以用财务的语言描述这个经营行为：

借：固定资产 200万

贷：银行存款 200万

相对于购买原材料的分录，这个变化就是借方的科目变了，从原材料改为固定资产；换句话说，借方是什么科目是不固定的，取决于我们购买的东西是哪一种

按照这个思路，我们把程序的逻辑改一下，借方科目由采购的材料来决定

if 购买的材料是原材料1， then 借方科目为 原材料

if 购买的材料是机器设备1， then 借方科目为 固定资产

但是如果每次买个材料，都要技术去改一下代码，然后等着更新程序，肯定很麻烦，所以另外建立一个表格，建立起物料和科目的映射关系

此时，系统生成凭证的逻辑有所变化

这样每当有新的材料要采购时，在系统中先维护物料的基础资料，把物料对应的成本科目编码维护进系统，程序上不用做任何变化。

这时候有个新的问题，这个物料基础资料的工作谁来做？需要买什么材料，业务部门先知道的，财务后面才知晓。作为业务上的主数据，物料基础资料一般是由业务部门来维护的，那么业务部门的人员怎么知道应该维护什么科目呢？

第一种是培训一下，反正就这几个科目，让业务人员记住；不过我们在进行系统设计时，尽量把业务信息和财务信息隔离开，不要让业务人员再去维护财务相关的信息，会带来额外的培训成本，在人员交接时更加明显。

第二种是分开来，业务维护物料编码、名称等信息，然后流程流转到财务，由财务维护科目的相关信息，但是会导致基础资料维护流程变长，效率降低；一般在一些非常关键，维护频率相对低一些的主数据维护中会采用这个方案；

第三种是增加一层抽象逻辑——物料类别，将所有的物料先分为几大类，每一大类定义好相应的成本科目，物料类别变化的频率很低，作为公司的基础数据，可以由财务或业务来共同维护；后续经营活动中日常的材料新增，只需要让业务人员选择物料类别就可以了。

事实上，物料作为企业的重要基础资料，其包含的信息远远不止一个成本科目这么简单；在系统高度集成的前提下，采购、销售、技术、生产、财务等各个部门需要的信息都会在物料维护时有所体现。