关于主数据发票信息库的思考
编辑导语:什么是开票资料?主数据的发票信息模块设计时应该注意些什么?税点信息要不要维护到主数据中?本文作者从这三点出发,为我们详细地介绍了他关于主数据发票信息库的一些思考,希望本文能够对大家有所启发。
我是负责公司中台的产品经理,最近接了一个关于财务提出的的需求:当我们集团下公司的开票资料发生变化时,我们公司中在使用公司开票资料的人可以收到一个开票资料变更通知信息,在未来使用时可以使用最新的开票资料。
因为现在我们公司的开票资料发生变更,会有沟通信息传达覆盖不全的情况出现,导致接收变更通知不及时而在推进业务中遇到障碍。
1. 开票资料
开票资料是指开发票时需要提供的对方信息:客户的公司是小规模还是一般人、客户公司名称、税号、注册地址、注册电话、开户行、账号、快递收件信息、票种需求(索要专票还是普票)。
一般财务对接到的开票资料是下面的内容:
实现这个需求的第一步是需要在主数据中台的公司信息库中,维护对应公司的财务信息,第二步是当主数据中的财务信息发生变更触发通知提示。
今天我们不对这个需求的完整流程展开讨论,仅讨论为什么财务信息要维护到主数据中,以及财务信息哪部分资料需要维护到主数据中。
其实传统维护财务信息的方式是公司的财务人员自己来维护的,财务人员会使用一个超大的excel表格,将各个对接的公司开票资料整理到不同的sheet中,字段一般为:公司名称、公司税号、公司注册地址、公司电话、公司开户行名称和公司开户的银行账号。
也有可能将部分财务信息放在公司的业务平台进行管理,以实现数据的调用。
1.1 普通发票和专用发票抬头必填信息是不同的
开增值税普通发票,对方单位的全称,纳税人识别号是必填项,其他可填可不填,但是如果填了就要填正确,否则发票无法使用。
开具增值税专用发票必须填对方单位的全称,纳税人识别号,单位地址及电话(电话是公司电话,是座机号,不是手机号)、银行基本户账号、开户行,少填或填错发票都会造成无法使用的情况。
为什么要将发票信息库维护在主数据中?
一般发票信息都是稳定的,不轻易发生变动的,但还是会出现财务信息发生变动的情况,传统财务人员更新了财务信息后,并不一定会通知到公司的所有人员。
就很容易有财务信息对接变更情况不及时发票开错的情况出现,造成财务环节的流程耗时长。
传统方式是公司的财务人员维护客户的财务资料,在财务信息对接和财务信息管理上会投入大量的时间成本,而对接财务信息和维护更新财务资料环节其实是重复的工作内容。
我们集团需要维护我们旗下的公司信息有很多,如果不同公司的信息放在不同的业务产品线中进行管理,当财务信息发生变化就需要工作人员去不同的业务产品系统中,修改财务信息,同样的触发通知逻辑需求我们就需要开发在不同的业务产品线都做一个同样的触发逻辑。
而如果是将稳定的财务开票信息放在主数据中台管理,当需要时提供接口支持其他业务调用使用,当企业的开票资料信息发生变化时,修改主数据中台的开票资料后,调用这部分资料的业务产品线也同步变更数据信息,同时触发通知提醒,这样会非常节省人力时间成本。
将开票资料维护到主数据,当业务产品线需要这些公司的财务数据时直接调用就可以了,可以解决数据集团化管理更加标准快捷的为业务提供数据的能力。
避免在财务资料的更新和对接上给财务人员造成额外的工作负担,减少了财务人员在这个环节时间成本的浪费。
将开票资料这类财务信息从人工线下维护管理转变成线上统一的、集中的、标准化的管理到主数据中台,解决了任何人使用的这部分财务信息都是标准一致的。
1.2 将这部分财务信息维护到主数据可以解决以下2个问题
- 标准化:将稳定的、且被重复调用的、非业务相关的信息资料实现集团的标准化、规范化管理,保证使用时任何人使用的这个字段信息都是一致的。
- 效率化:字段无法保证一定是准确的,如果当使用者发现这个字段信息记录有误,反馈这个情况,只要主数据中做了修改,其他人再使用这个接口信息就是正确的了。非常方便,避免了各业务线维护的字段不统一、不一致以及修改不同步、重复劳动成本的问题。
2. 主数据的发票信息模块设计时应该注意什么
2.1 开票资料中属于业务性质的数据与属于主数据性质的数据要剥离开来
2.1.1 业务性质的数据
与支付、售卖相关的信息就是业务数据,属于业务性质的数据无法被其他业务线使用,这个字段数据只是能够为提供某一业务的某一场景提供使用。
2.1.2 主数据性质的数据
中台数据的特点是数据具备基础性、核心性和稳定性。具有为多条业务的多个场景提供使用的底层能力。
- 基础性:数据的颗粒度最细,容易被业务系统调用,后期业务可以根据自身的需求针对性的对数据进行加工处理。比如公司地址归入主数据中台管理,业务未来可能做地区筛选, 调用的地址是主数据提供的,但是地区筛选功能是根据业务线自身需求去做的。
- 核心性:数据具备底层能力,稳定的数据但是如果不够核心,无法提供通用能力,也不会归入到主数据中台中。
- 稳定性:不轻易发生变化。比如公司名称、税号不会轻易发生变化。
判断一个数据是否维护到主数据中,我们就先观察这个数据是否与业务的支付、买卖相关,再观思考这个数据是否稳定,不易发生改变,如果与业务的支付、买卖无关,且稳定,那么就属于主数据中台要维护管理的数据。
不同产品不同时期在不同供应商的进价都不一样,不同产品在不同时期对外售卖的价格也不一样, 这里的进价、卖价、税点都是业务字段。
而对方公司营业执照上面的信息,比如公司、税号、电话、地址就是主数据性质的数据。
举个例子:
A业务线发生采购,他们的业务产品字段可能就会涵盖采购的税率字段,但是这个税率字段不会维护在主数据中,原因有两个:
- 其他的业务线不会使用,因为采购业务至发生在A业务线中
- 税率是根据发生不同的购销类型决定的税率,所以并不稳定
如果不剥离开来,业务性质的数据由于会会经常发生变化,主数据就需要经常维护修改,假如A业务甲字段发生变化了,但B业务中甲字段就没有变化,但是也在调用这个字段进行使用,这时这个字段就不能被很好的管理了。
2.2 主数据中的发票信息库设计的思考
我在主数据发票信息库做字段筛选的时候,主要参考了发票的字段,因为发票抬头上面体现的字段信息都是公司财务需要的重要信息,这些信息也不容易发生变动,根据发票上面的抬头,总结了以下四个字段:
- 企业名称:公司名称
- 统一社会信用代码:税号
- 地址、电话:公司注册地址:营业执照上的公司注册地址信息;公司注册电话号码(非个人手机号)
- 开户行及税号:开户行名称:公司的开户行的名称,比如招商银行;开户银行名称:公司开户银行名称所属的支行名称,比如招商银行股份有限公司最美丽路支行;银行账号:公司开户的银行账号
三、税点信息也是开票资料,要不要维护到主数据中?
税点信息虽然是一家企业的财务信息,但是我不建议维护到主数据中,主要的原因是因为税点信息并不稳定,容易发生变动。
一般人类型的公司和小规模类型的公司税点是不同的,但是公司会在两种类型之间根据业务和销售情况发生转变,我们并不能把控一家公司什么时候转换,所以税点的变化具有随机性。
税点信息如果纠其实质,属于的是业务数据,并不属于主数据,虽然是财务信息,但是是根据不同的经济业务会产生不同的税点,不是底层稳定的数据信息。
总结主数据发票信息库可以方便企业维护企业数据,数据量越来越多,未来维护也会更便捷。
还能对公司员工当公司信息发生变更,对业务线的同事来说可以及时获取变更的消息,整体节省业务时间。
主数据的发票信息库还是需要针对自家企业对主数据的定义进行发票信息库的设计,有不理解的地方多与公司财务进行沟通,将业务字段和主数据字段分析到位,进行剥离是我们需要仔细思考的。
作者:财务产品人;公众号:财务产品人,我们一起交流
本文由 @财务产品人 原创发布于人人都是产品经理,未经作者许可,禁止转载
题图来自 Unsplash,基于 CC0 协议
老师,我想问一下,我司也是做开票产品的(C端),逻辑就是商户填写商品信息,,用户扫码填写抬头即可开票,目前遇到问题就是在**外的内容怎么自定义商品名称(刚入行,不太了解),因为涉及到合并编码的问题,就是想商户在选择大类商品*以后,再自定义后面的商品名称,不知道该怎么去设计