跟一群支付小伙伴做业财一体化的过程(三)
导读:上一篇讲解了会计科目、记账场景、分录的设计,在产生会计流水后,如何进行日切处理、试算平衡和输出财务报表呢?本篇主要讲解的就是这三部分。
一、日切
日切,简单说就是系统从当前工作日切换到下一工作日,更换系统记账的时间。在传统的银行业务中,每日作业需要有一个结束的时间,在这个时间之后,需要对当日尚未完成的业务进行集中处理,并盘清当日的账目,做好受理下一日业务的所有准备,将记账日期更新为下一日,这一过程就是日切。
早期的银行只能通过柜面办理业务,受理业务的时间跟随网点的营业时间,网点当天下班后不再受理当日的业务,所有网点当天下班后,银行日终批量处理完成,就可以日切。这个时期的日期工作是比较容易的。
现在接入了网上银行、手机银行、支付系统等多种渠道,都可以进行银行业务的处理,此时就对账务系统提出了24小时支持的要求。在7*24小时下实现日切,较早期的柜面处理会相对复杂。一般会采用双余额法,在分户账中设置当前余额、最近一次更新日期、上日余额。发生交易时和日终批处理时,用交易日期和最近一次更新日期比较,具体方法如下:
日切的时间选择:一般来说,日切时间会选择为每日业务发生的低谷。也可以结合产品的实际情况,我们考虑到外部客户看自己的账户流水和余额时,通常会将0点先入为主作为每日的起始和结束,会更容易理解0点的概念,所以选择以0点作为日切。
二、试算平衡
试算平衡是根据会计恒等式,通过对所有账户的发生额和余额的汇总计算和比较,来检查账户记录是否正确的一种方法。
会计恒等式可以在“资产=负债+所有者权益”的基础上,根据公司实际用到的会计要素灵活变动。例如我们出于业务需要,增加了共同类的科目,等式就变成了“资产+共同类=负债+所有者权益+收入-费用”
试算平衡的公式:
- 全部账户的借方期初余额合计=全部账户的贷方期初余额合计
- 全部账户的借方发生额合计=全部账户的贷方发生额合计
- 全部账户的借方期末余额合计=全部账户的贷方期末余额合计
在手工做账的时代,试算平衡需要通过编制试算平衡表来检查结果,试算平衡表的格式如下,会包含所有科目的期初余额、本期发生额、期末余额。试算后,如果表格的2/3列、4/5列、6/7列的合计金额相等,说明试算是平衡的。
系统自动进行试算平衡的检查,需要在每日日终批量处理完后,对上一日的余额和发生额按照上述的公式进行检查。
如果实际业务需要,也可以增加检查的规则。例如:
- 账户日终余额是否为零,对于一些中间账户,日终余额如果要求为零,系统可以增加这个校验;
- 账户是否允许透支,对于标记了不允许透支的账户,也可增加这个校验。这些账户属性,在上一篇的科目中已经讲解过,参考:http://www.woshipm.com/pd/5298864.html
三、业财报表
我们在第一篇中讲解过,每个公司的财务在期末都会对本期业务形成三大表:资产负债表、利润表、现金流量表。但是业财系统最后输出的报表,并不是这三大表,三大表是专业的财务系统要做的事情,业财系统的定位是将业务语言转化为财务语言,消除业务和财务之间的鸿沟,并不是要做一个专业的财务系统。
我们回到第一篇中业财一体化的目标,根据他的目标来输出对应的报表。
1. 发生额报表
这个报表是统计每一会计期间内每一项记账场景的发生额,目的是协助会计核算,为了让财务能清楚知道每一项业务的发生情况。第二篇中讲解了记账场景和会计分录,根据分录记账完成,就有了会计流水,在日终批处理完成后,汇总上一日的会计流水,产生记账场景发生额报表。一般报表格式如下:
2. 总账报表
总账报表可以看做是会计上的总账,总账科目也就是总分类科目或者一级科目,用来对全部经济业务进行总分类核算,是编制会计报表的主要依据,目的也是协助会计核算。因为是系统自动计算,可以同时统计一级科目和叶子科目,一级科目的发生额和余额,是其下面所有末级科目的汇总。
3. 分户账
分户账是明细分类账,主要用于明细的核算,也是客户账户的记录,是用来与客户对账的依据。分户账包含分户账明细和分户账历史余额,这两个内容通常会结合起来产生客户的账单。一般格式如下,如果担心账单以借贷的方式表示客户会看不懂,也可以直接展示收入/支出。其中期末余额=期初余额-本期借方发生额+本期贷方发生额(因为余额在贷方),记账场景1/2/3的发生额,是按照记账场景将本期借贷发生额进行了拆分,让客户和公司内部的对账同学能清楚看到这个分户账下面每一项业务的发生情况,一个记账场景发生额只对应一个余额变动方向,不会存在一个场景中,在分户账既发生在贷方,又发生在借方,如果有这个情况,说明记账场景拆分有问题,需要重新按照第二篇讲的记账场景再次拆分。
四、写在最后
1、整个项目中,记账场景的确定是非常重要的事情。以我自己的产品为例,订单的处理都是支付、分账、清分、结算这个流程,每个节点的分录也完全一致,所以最开始就将整个订单业务分为了支付、分账、清分、结算这四个场景。但上线后发现并不能完全满足财务的需求,因为虽然都是订单业务,但是业务类型不同,有些订单是按照下单后记账的,有些是发货后记账的,还有些可能是要单独剔除的。由于我们最开始并没有分业务类型,所以后面又面临着一轮改造。这个血的教训,希望大家不要踩坑,一定要根据财务做账的方式确认好记账场景。
2、会计流水或记账场景发生额报表,是不是就是所谓的会计凭证呢?答案是不一定。如果财务做账的分录和业财系统中设置的分录完全一致,那么可以直接用会计流水作为记账凭证,如果业务量太大,没办法单笔单笔做账,那么记账场景发生额报表也可以作为每日的记账凭证。但如果业财系统还在迭代中,或者天然没办法做到与财务的分录一致,那么建议直接通过会计流水推送会计凭证到财务系统。财务最终需要的是数据的准确,在推送过程中进行处理,会比花费大量精力改造业财的分录更合理。
以上就是在业财系统设计的过程中,对关键点的总结和产品整体设计的思路。欢迎大家交流~
本文由 @安妮 原创发布于人人都是产品经理,未经许可,禁止转载
题图来自 Unsplash,基于 CC0 协议
怎么才能联系到您呢,学习一下
支付订单和财务记账,理论和实施都应该是分别独立的系统,通过分别的业务ID关联,要是从逻辑上就强关联,业务设计就很多问题了
和大佬观点一致,能加个好友沟通下不,财务小产品一枚微信号shalen1103