漫谈业财税一体系化建设1 –整体架构
业财税一体化是一种将业务流程、财务会计与税务申报紧密结合的管理模式。通过高度的信息系统整合,实现数据共享和流程优化,从而提升企业的效率和合规性。本文将从业务的角度出发,让您认清整体系统的本质,以实际的业务诉求切入,一步步的构建出一套完整的B端系统框架。
本章介绍业财税一体化的本质,主要讲解业务,是理解业财税架构建设的前提,需要大家用心阅读理解。
一、业财税由何而来?
业财税最早是由我国的财政部在推动管理会计发展过程中提出。2016年6月,财政部发布了《管理会计基本指引》,明确提出管理会计应与单位相关领域、层次、环节相结合,实现财务和业务的有机融合。
这一文件为“业财融合”提供了政策支持,并逐渐成为学术界和实务界广泛接受的理念。随着实践的深入,从“业财融合”逐步演化为更加全面的“业财税一体化”模式,不仅涵盖业务和财务的整合,还将税务管理纳入其中,实现了企业三大流程——业务流程、财务流程和税务管理流程的有机结合。
这种模式利用智能化的管理软件或SAAS系统,确保企业的财税管理更加标准化和自动化,有助于降低运营成本并提高决策效率
二、业财税的核心是什么
业财税一体化的核心在于整合业务、财务和税务的数据与流程,以实现全面、实时的信息管理。这不仅提高了工作效率,还优化了资源配置,降低了经营风险。例如,在业财税一体化模式下,当业务发生时,相关的财务和税务数据能够即时更新,管理者可以快速获取关键信息,从而做出更准确的决策。
此外,业财税一体化的实施路径包括建立统一的信息系统、优化流程和标准化操作。通过这些措施,企业能够在一个平台上管理所有相关数据,避免重复操作和数据冗余,从而显著提高准确性和工作效率。
总的来说,业财税一体化不仅提升了企业的管理水平,还增强了企业在复杂市场环境中的竞争力。企业应积极探索和实践这一模式,不断优化管理体系,以应对市场的多变挑战。
三、系统的目标用户
业财税系统的主要目标用户包括中大型企业、高新技术企业、跨国企业、代账行业企业和对合规性要求高的企业。
- 中大型企业:这类企业通常具有复杂的业务交易和庞大的财务数据量,需要高度自动化和集成化的系统来提高管理效率。业财税系统可以自动从业务交易中生成财务凭证,确保数据的准确性和及时性,从而提升财务报告的速度和可靠性。
- 高新技术企业:这些企业常常涉及到研发费用加计扣除等复杂的税务优惠问题。业财税系统可以帮助高新技术企业更好地管理税务优惠申请流程,确保能够最大化地享受税收优惠政策。
- 跨国企业:跨国企业需要处理多币种、多税区的复杂税务和财务问题。业财税系统提供统一的平台,简化了跨国经营管理,支持智能配货和精准锁库功能,优化物流和仓库管理,提高供应链效率。
- 代账行业企业:随着业务的快速发展,这类企业需要灵活和高标准化的财务管理系统支撑其持续成长。且涉及行业多种行业类型,业财税系统可以提供可扩展的解决方案,能够满足企业在成长过程中不断变化的管理需求。
- 对合规性要求高的企业:金融、医药等行业对合规性的要求尤为严格。业财税系统自动化地保障数据准确性和合规性,确保税务和财务的严格合规,为企业带来安心。
四、搭建整体架构前
当我们理解了业财税的核心,以及目标用户后,便可以开始做搭建前的准备了。
- 选取目标用户,市场调研
- 掌握相关财务知识
- 组建好团队
- 遵从国家相关法律法规
其中第2、3、4点本文不做赘述,以下重点讲解第1点的市场调研
以代账行业企业为例:
我们可以通过用户访谈、问卷调查等方式可以和目标用户进行沟通,了解在没有系统的情况下,用户(会计们)的日常工作有哪些,涉及哪些第三方关联系统,工作节点的前后流转关系等。
可以看出月初的【汇总客户交易】工作是后续月中、月末工作的来源,故此在设计该模块的时候,需要注意的事项有:
- 针对于不同地区的客户,需要获取的发票及其他交易凭证需要全面、准确、真实。若有缺少则影响后面的记账和税务申报工作。若在税务申报环节错报,或漏报都会有巨大影响,严重时还会使客户企业信用降级,产生滞纳金等。
- 在设计此模块时,应充分调研这些发票和凭证的来源有哪些,直接从源头获取比从客户企业拿完整的多,例如开票软件,税局平台等,详细内容可见后续文章《漫谈业财税一体系化建设4 –票据与记账》。
其次,在整月的工作中,不可或缺且最重要的三个工作是【编制记账凭证】、【编制财务报表】、【纳税申报(含缴款)】,而这些工作的来源都取决于月初的工作【汇总客户交易】。所以在设计系统时,针对这几个重点模块的注意事项是:
- 关联性业务流程打通,让业务自上而下进行流转,同时考虑用户逆流程的情况,增加校验提示或禁止功能
- 编制记账凭证时,可以将业务进行拆解,将客户人工填写的字段抽离出来,设计系统的算法,自动生成凭证。再配套审核机制,大大减少用户的时间成本。
- 编制财务报表时,可以在报表内增加算法,自动从关联模块获取数据,减少用户手动填写的操作,但同时仍要支持用户可以手动填写数据并配置校验规则,这样当用户填写错误的情况,可予以报错提醒和制止。
- 在纳税申报(含缴款)环节,需要和税局进行交互,将系统内的税表数据报送至税局,获取报送结果回传至系统,并且在申报和缴款的最终环节都需进行金额的比对校验,防止错报和漏报。
上述每一项环节的功能点都可以细细拆解,在后续文章会详细介绍,此处暂不做赘述
五、搭建整体架构中
好了,接下来可以正式进入搭建整体架构的环节(依旧以代账行业企业为例)
首先,确认系统的几大层次,分别是
- 用户交互层
- 产品应用层
- 数据层
- 基础服务层
1. 用户交互层
我们需要考虑最终用户的操作场景,代账行业目标用户大部分都是账务会计,税务会计等,协同工具大多为电脑,其次为手机,再加上近年来兴起的AI。我们可以设定为3个用户交互场景
在系统初期,可以只考虑PC端,等系统稳健成熟后,再考虑另两个端。
2. 产品应用层
2.1 划分第一层级应用
1)按照用户实际的工作场景,有先后顺序关联的可以分为
- 先取票据(汇总客户交易凭证)
- 然后记账(编制记账凭证、登记会计账簿、账目核对)
- 接着制表(编制财务报表)
- 最后办税(纳税申报、客户报告)
2)按照用户实际的工作场景,没有先后顺序关联的可以分为
- 资产(资产管理、折旧与摊销、明细账表)
- 薪酬(员工档案、社保公积金、工资表、个税)
- 存货(存货管理、库存核算、明细账表)
- 风控(风险控制)
- 筹划(预算、税务筹划)
- 咨询(客户沟通、解答问题、税务咨询)
- 增值服务(工商注册机变更)
如此大致应用已经划分完成,还需要继续把每个应用进行拆分业务点。
2.2 划分第二层级业务点
1)举例1:【收票】这个应用,是为了从各个来源渠道获取销项发票、进项发票、费用发票、其他票据,从而给后续的应用提供全面数据的支撑。所以业务点就要思考用户对这些发票会有哪些处理呢?
- 用户需要拿到发票,获取里面的数据
- 用户需要拿到银行的对账单及其他单据
- 进项发票会有进项税额转出的场景
- 进项发票会有勾选抵扣的场景
- 用户需要有页面汇总查看某月所有的发票数据
- 用户需要对这些发票进行分析
- 用户需要根据发票制成记账凭证
- 用户需要……
综合一下,就可以得出下图
2)举例2:【记账】这个应用,是为了将各个会计业务记录成记账凭证,汇总到会计账簿里。所以业务点就要思考用户会从哪些业务模块生成记账凭证呢?记账凭证生成后如何汇总到会计账簿呢?
- 用户需要获取历史的账务数据
- 用户需要再各个业务模块里单独生成记账凭证
- 用户需要制作记账凭证,记账凭证包含数据有:日期、字号、摘要、会计科目、币种、借方金额、贷方金额、合计、制单人、制单时间、审核人、审核时间
- 用户需要记账凭证展示每个科目的余额
- 用户需要每期进行期末结转,每年进行年度结转
- 用户需要将会计凭证登记会计账簿
- 用户需要……
综合一下,就可以得出下图
3)举例3:【办税】这个应用,是为了每期的税表报送至税务局,有税款时可以进行缴款。所以业务点就要思考用户每一期需要申报哪些税表?如何申报?申报错误如何处理?
- 用户需要知道负责的企业每一期需要申报的税表是哪些
- 用户需要查看管理这些税表
- 用户需要在税局规定的时间内进行正确申报
- 如果税表申报错误需要立即通知到用户,并给用户改正的机制
- 用户在税表正确申报后,如有税额需要进行缴款
- 用户需要……
综合一下,就可以得出下图
4)举例4:【资产】这个应用,是为了让用户可以管理企业的各项固定资产和无形资产。所以业务点就要思考用户如何管理这些资产?这些资产涉及的账表会有哪些?
- 用户需要登记固定资产卡片
- 用户需要在规定周期内给固定资产进行折旧
- 用户需要再规定周期内给无形资产进行摊销
- 用户在购进/出售资产时进行记账凭证的记录
- 用户需要……
综合一下,就可以得出下图
5)各位读者可以思考一下其他的应用该如何划分?欢迎联系我一起探讨
3. 数据层
这一层次比较偏技术了,在整个系统的运作过程会产生大量的繁杂的数据,内部人员和外部人员对数据的处理也会有很多,所以在这一层次可以对数据进行大致的分类,针对同类型的数据进行相似的处理或分析
我们按照数据产生的来源可以分为
- 财务数据:来源于财务应用模块,例如发票、资产、存货等
- 税务数据:来源于税局,和税务应用模块,例如税源信息、申报表内数据、申报档案等
- 行业数据:来源于税局,例如企业基本信息、营业信息、行业分类等
- 工商数据:来源与工商信用管理公式系统,例如登记注册信息、联系人信息、社保信息等
- 舆情数据:来源与社会舆情,例如国家政策调控,灾情相关的减免税政策等
- 指标数据:来源于相关财政法规规定的各项费用指标、企业经营指标等
4. 基础服务层
最后一层是基础服务层,也就是系统最底层的且通用性的服务。我们需要把各个产品应用层里通用型的服务剥离出来,作为公用组件,如此就可以避免重复造轮子的情况。
例如用户操作所有模块都需要受到权限的限制,可以操作什么,不可以操作什么。可以看到什么数据,不可以看到什么数据。
例如会计科目,像前面提到的【收票】、【记账】、【报表】、【办税】等业务模块都需要用到会计科目,而会计科目又都是由国家有关部门规定好的准则来执行,所以属于通用性服务。
例如报表之间的算法,会计日常工作中涉及的账簿和报表,彼此之间都存在勾稽关系。因此,可以将这些内在的关系抽象成表间算法,作为底层服务给其他模块予以支撑。
- 《会计报表-资产负债表》的「库存现金」科目,可以同样在《会计报表-现金流量表》、《科目余额表》、《总账》、《明细账》中列示;
- 《企业所得税申报表》里的「收入」也可以在《会计报表-利润表》里列示等等
还有用户管理、消息管理等等,这些都可以作为通用型的组件,整理完成后就可以得到下图
如此我们就搭建完4个层次了,这是一套系统的基本构建。如果再考虑更长久一点,我们还可以再继续横向扩充,思考一下运营和生态合作的方向
- 思考系统完成后运营的几个大方向,目前可不用细致规划,毕竟离系统上线运行还有很长的时间
- 思考系统可以合作的机构,例如代账行业可以和财会类职业学校合作,好比以前财会类学校会让学生学习使用金蝶和用友的软件一样。目前也可不用细致规划,需要等系统稳健且在市场具备一定影响力后再开始启动,切勿操之过急。
如下图所示
最后的最后,我们就可以得出一张完整的B端业财税系统架构图!
六、搭建整体架构后
在整体架构搭建完成之后,作为产品经理还需要对系统的产品应用划分模块,划分产品优先级,确定产品目标及里程碑,确定相关负责人或负责团队等,所以在这一过程中,不可谓不艰辛!
本文由 @尺素 原创发布于人人都是产品经理。未经作者许可,禁止转载
题图来自Unsplash,基于CC0协议
该文观点仅代表作者本人,人人都是产品经理平台仅提供信息存储空间服务
- 目前还没评论,等你发挥!