如何搭建企业级账务系统?看这篇给你思路

简介: 如何搭建企业级账务系统?看这篇给你思路

一、项目背景介绍

1. 业务背景

笔者公司的业务模式具有一定的独特性,不同于我们常见的市面上供应链类公司的进销存模式。公司主要为各大银行和金融机构提供信贷领域的风控服务,客户主要通过请求公司的数据产品接口产生费用,可以简单地理解为请求一次接口收费0.5元,一个月若是有1w人请求同一个接口则公司需要收费5000元。

2. 业务核心痛点

如何将请求的不同的产品的计费量与单价进行匹配出具账单?

出具账单后如何与客户进行对账?并且能够有留存?

与客户对账无误后,如何通过系统为客户开具服务发票?

客户收到发票后进行了打款,如何将账单、发票、回款进行一一关联和匹配呢?

有了账单、发票、回款信息后,如何通过这三类基础要素统计各种维度的财务分析汇总报表呢?

3. 系统定位

根据上面提到的业务背景和业务痛点,我们基本就能够明确系统的基本定位,以及需要支持的业务功能和流程,概括来讲的话,系统定位为:集合了账单、开票、回款、财务报表的全流程一体化管理系统。

二、系统业务流程说明

上图为笔者绘制的一份简版的账务系统的核心业务流程图,通过这张图我们来拆解每个业务模块。

1. 创建计费单

计费单顾名思义为用来计费的单子,在这个单子里将包含的需要计费的信息,从流程图中我们可以看出计费单的上游业务是CRM的合同,也就是说其实计费单的计费信息最初来源于客户与我司签署的合同,则计费单是将合同中有关计费的信息进行了提炼和转换,通过计费单去作为后续出具账单的依据和凭证。

在计费单中包含产品信息、单价信息、计费方式、账号信息等等。

2. 生成账单

账单的上游业务是计费单,通过计费单我们就能知道账单中需要包含的每个产品的计费方式和单价等基础信息,则只要再有了每个产品数量(调用量),就可以为客户出具完整的账单,那么调用量则是来源于BI系统的调用日志,在触发重跑账单时,将计费信息和调用量进行匹配和组合,最终生成账单。

通过上述两个步骤,来解决我们刚才提到的业务核心痛点1。

3. 账单确认核账

当有了账单之后,就需要考虑如何与客户进行对账,那就到了解决业务痛点2的时候了。在之前线下业务模式中,我们调研到销售同事是跟客户通过公司邮箱发送账单的方式来展开对账工作,这样的方式放在系统上来进行也是非常方便的,同时也符合他们之前的工作习惯,于是我们决定在账务系统上支持每个客户的账单通过系统来发送到客户邮箱中。

系统在发送时会附带好账单,通过在系统中维护好收件人即可,邮件发送后若客户回复邮件,系统可以抓取到回复邮件自动带回到账单中,便于销售同事进行确认核账。

4. 申请开票

当账单确认核账后,一般客户就会要求我司为其开具相关服务发票,客户见票回款。开具发票是账务系统中使用最为频繁的功能模块之一,也有着比较复杂的逻辑处理。目前我们账务系统在开票时包含多种类型,将会在下面展开来讲。

5. 拆分回款

为客户开具发票后,客户一般会在约定的几个工作日后进行回款,账务系统与主流的各大银行做到了银企直连,客户进行银行打款后当日也会回传到账务系统,则销售同事通过操作账务系统将回款进行拆分,同样在拆分回款时也包含多种类型,将会在下面展开来讲。

6. 账户

每个客户在我们的账务系统都拥有自己的账户,在账户中管理着每个客户的余额及对应的每笔收入和支出的流水,当然有的账户中可能还会产生坏账或人工调整金额等,总之所有会影响的客户余额的操作都会在账户中体现出来。

在确立账户时,需要明确账户的维度,是客户维度还是客户+业务线维度,亦或是客户+业务线+产品维度等等。

这里的主要提下账单产生的负向支出和回款的正向收入。当账单核账后,系统会生成对应的支出扣减的流水,客户的账户余额减少;当客户回款后拆分完成,系统会生成对应的一笔收入的流水,账户余额增加。

7. 账单开票回款关联表

这部分在流程图中即是笔者用浅蓝色的长框框住的部分,是将账单、开票、回款三个表进行了关联汇总,此表在后续的财务数据的统计中经常会作为中间表用到,比如计算哪些账单是已开票已回款或者已开票未回款,哪些预付回款已开票,哪些预付开票是否回款等等,通过这张表可以得知各类的信息,为财务报表统计提供基础数据。

8. 财务报表统计

财务报表的统计是根据实际业务场景产生的,就笔者公司而言,目前在账务系统中已上线的财务报表包含:封账统计报表、包年权责报表、客户账龄表、客户逾期表、逾期汇总表、财务账龄表、财务收入大表、项目类收入表等等。

每个报表的处理逻辑和方法都是不一样的,在接到财务报表相关需求时,需要捋清楚报表内的每个字段的计算逻辑,更重要的是财务报表是依据财务维度出具的,在理解每个字段背后的含义时,需要结合一定的“财务原则”,不然很容易出现“我以为你说的这个意思啊”这样的场景。

三、系统核心元素关系

简单来说,账务系统核心元素主要就是三个:账单、开票、回款,在这三个元素中最核心基础的当然是账单,其他的功能或者报表都是基于这些基础元素进行的延伸和拓展,所以我们需要先搞清楚这三者之间的会产生的哪些复杂的关联关系。

1. 账单

账单是开票和回款中间的桥梁,桥梁的作用体现在,开票时需要关联账单,回款时也需要账单。

2. 开票

我们根据业务需要,支持针对产生的账单进行开具发票,在开具发票时必须选择账单,可开票的金额需要小于等于当前的账单的金额;

另外一种开票的业务场景为,客户还未在我司产生账单,也没有预付款,但是需要我司提前进行开票,则如果只支持客户对账单进行开票,显然无法适配当前的业务场景,那么系统需要支持无账单下开票,确定好需要开票的业务线即可;

但同时也会有客户预付款的业务,同样还未产生账单,则此时需要支持按照预付款进行开票,在开票时必须要选择客户的某笔回款进行开票。

3. 回款

当客户进行回款后,需要将回款拆分到对应的账单或者开票,如此来让账单、开票、回款三三者之间关联起来,最理想的数据情况则为,此账单已开票已回款。

1)回款拆分到账单

将回款关联拆分到对应的账单,给每个账单分配回款金额,直到该笔款的回款金额分配完。

2)回款拆分到开票

如果先对账单进行了开票,客户的回款对应某张开票,则此时通过将回款关联拆分到开票是最方便的,直接为开票分配回款金额即可;但是这里需要注意到回款虽然是表面上拆分给了开票,如果该张票当时是开到了账单上时,则在回款拆分到开票时,系统需要同时将回款金额分配该张票底层的账单上,这样才能保证账、票、款一致。

3)回款拆分到预付

针对客户先打款后产生账单的业务类型,系统支持提前将回款的拆分到预付回款下,在拆分时不需要关联账单和开票,只需要确认好每条业务线需要分配的回款金额。

四、账务系统架构

上图为笔者绘制的一份简单的功能架构图,基本包含了目前账务系统核心的业务功能,可以将该图与流程图结合起来理解。

五、一些踩过的“坑”吧

1)账务系统中的必然会出现大量的数字,是实打实跟数字打交道的系统,在最初设计时一定要考虑清楚数值的类型,是采用double类型、float类型还是别的类型,最终的目的是保证系统在数值的精确度上是始终保持一致的,在这件事上我和我的团队是吃过亏的。

2)账务系统的各个模块的数据和功能的串联型与关联度是非常高的,举个例子来说,当你发现某个财务报表的某个字段统计计算有误,很可能是因为最初在账单已经出错,进而导致开票有误、回款有误、关联表有误,最终导致报表有误,因此需要考虑在设计各个模块时耦合度的问题。

3)一般新系统的在上线时,都会需要处理历史数据,账务系统也不例外,尤其是针对各种期初数据的导入和处理是比较多的,而且相关人员在给到我们数据时,往往是无法一次到位的,少不了在后续多次的修改和调整,然后再由我们的研发人员执行sql。

因此针对这类问题,可以考虑增加一些修改期初数据的功能,虽然我之前一直认为这样地低频的导入期初数据的操作不需要做成系统功能,但从实际来看并非完全如此

原文出自:人人都是产品经理




文章下方有交流学习区!一起学习进步!也可以前往官网,加入官方微信交流群

创作不易,如果觉得文章不错,可以点赞 收藏 评论

你的支持和鼓励是我创作的动力❗❗❗

官网:Doker 多克; 官方旗舰店首页-Doker 多克 多克创新科技企业店-淘宝网 全品优惠

目录
相关文章
|
6月前
|
安全
dapp公排矩阵互助模式系统开发指南步骤/详细需求/功能设计/源码案例
The development of a public matrix mutual aid crowdfunding model system for DApp (decentralized application) involves the application of blockchain technology and smart contracts. The following are the main steps and requirements for development:
|
6月前
|
新零售 供应链 数据挖掘
推三返一系统开发|成熟案例|源码部署
“新零售”的商业生态构建将涵盖网上页面
|
6月前
|
前端开发 JavaScript Android开发
打算一个卡片记忆软件,全平台架构如何选型?
打算一个卡片记忆软件,全平台架构如何选型?
|
4月前
|
缓存 前端开发 NoSQL
设计与实现个人博客系统的技术架构与最佳实践
设计与实现个人博客系统的技术架构与最佳实践
|
消息中间件 缓存 数据库
好家伙!阿里最新版高并发系统设计涵盖了“三高”所有骚操作
为啥都爱面高并发? 首先为啥面试官喜欢问高并发、性能调优相关的问题,我想有两点原因: 第一,本身互联网区别于传统软件行业的特点之一就是海量请求。传统软件公司每秒用户几个、几十个的请求很常见,但是互联网公司哪怕一个二线的 App,后端接口请求一天几个亿也很正常。业务特点导致对候选人在海量请求相关的技术上考察的会比较多。 第二、高并发性能调优等方面的问题相当于高考试卷里的难题部分。CRUD 谁都会,xx 培训机构培训上三个月,出来都能写。但是对于高性能、高并发这没几把刷子真会玩不起来的。通过这个来区分候选人水平的高低(招人肯定选水平高的)。
98 1
|
敏捷开发 存储 测试技术
链动2+1系统开发项目案例丨指南教程丨需求方案丨功能设计丨成熟技术丨步骤逻辑丨源码程序
用户需求导向:系统开发应以用户需求为中心,从用户的角度思考,了解用户的真实需求和期望,以提供优质的用户体验。
|
消息中间件 缓存 分布式计算
真牛!阿里最新发布这份《亿级高并发系统设计手册》涵盖所有操作
前言 我们知道,高并发代表着大流量,高并发系统设计的魅力就在于我们能够凭借自己的聪明才智设计巧妙的方案,从而抵抗巨大流量的冲击,带给用户更好的使用体验。这些方案好似能操纵流量,让流量更加平稳得被系统中的服务和组件处理。 那我们改如何应对大流量的三种方式? 第一种方法:Scale-out。 第二种方法:使用缓存提升性能 第三种方法:异步处理 面试京东,阿里这些大厂遇到这些问题改怎么办? 秒杀时如何处理每秒上万次的下单请求? 如何保证消息仅仅被消费一次? 如何降低消息队列系统中消息的延迟?
|
消息中间件 SQL 关系型数据库
「要点解析」分布式高级商城业务:分布式事务,满足你的好奇心
数据库事务的几个特性:原子性(Atomicity)、一致性(Consistency)、隔离性或者独立性(Lsolation)和持久性(Durabilily),简称就是ACID原子性:一系列的操作整体不可拆分,要么同时成功,要么同时失败一致性:数据在事务的前后,业务整体一致转账:A:1000;B:1000;转 200;事务成功:A:800;B:1200隔离性:事务之间互相隔离持久性:一旦事务成功,数据一定会落盘在数据库
137 0
|
开发框架 负载均衡 安全
闲话SAAS系统设计-概述
闲话SAAS系统设计-概述
293 0
闲话SAAS系统设计-概述
DAPP公排互助拆分系统开发详情原理丨DAPP拆分互助公排系统开发玩法功能/方案设计/案例分析/成熟技术/源码版
The lifecycle of smart contracts can be summarized into six stages based on their operational mechanisms: negotiation, development, deployment, operation and maintenance, learning, and self destruction. The development stage includes contract testing before contract chaining, while the learning sta
下一篇
无影云桌面