[原]关于会计对账的一点总结和思考

标签: | 发表时间:2017-01-22 20:21 | 作者:tenfyguo
出处:http://blog.csdn.net/tenfyguo

会计学有一个很重要和很出名的公式,相信很多人都见过:

资产 = 负债 + 所有者权益 + 收入 – 费用

 

        但会计学上还有另外一个比较隐蔽的公式,虽然不像上面的公式那么出名,但也经常能见到它(或者变种运用)的身影

那就是,即期末值=期初值+期间变化值,也就是期末值=期初值+期间入-期间出。该公式非常简单,也很容易理解,并且大量的用于计算和核对两个前后时间点的会计值的关系,它明确的指出,期末这个点的值是由一系列变化而来的,变化来自两个方面:1,存量—即期初值;2,增量—期间变化值。任何期末值的多少必须由这两部分变化而已,不能凭空捏造。

在账户中,我们也能够经常看到:资产账户的借方余额=期初借方余额+借方发生额-贷方发生额。

 

        那么对一个账户来说,必须记录两个维度:余额和流水,余额记录的是一个时间点的值,而流水则是反映一段时间内余额变化的过程,两者应该是一致的,即余额的增减一定对应的流水入和流水出,流水入和流水出一定会引起对应余额的增减,那么,在实际的实现中,如何确保这两者是一个事务呢?我们一般会使用db的单机事务去保障。

问题来了?既然我们已经通过事务去保障两者的一致了,为啥还需要额外的会计对账呢?必要性在哪里?

 

          从会计核算的角度看,虽然在具体的账户实现中,余额和流水会在一个db事务的方式进行实现,但还是有必要在会计方面对余额和流水进行二次对账核对,目的是提供一个独立的第三方核算机制,用于发现和核对资金的安全,如余额被人为修改了,如人为增加100元,虽通过db签名也能发现,但如果对应的流水没修改,则可以通过会计核对后发现该问题。那么如果对应的流水也被更改呢?那么单独对该账户的流水和余额进行会计核对(我们称为分账户核对)是无法发现问题的,会计恒等式还是成立的,那么通过进一步的总账户核算也能发现问题(即每个用户单独的余额和流水都是符合恒等式的,但加起来跟外部总账是对不上的,如对应的银行收款单,对应的商户入账账户等),会计核算系统正是需要从独立第三方核算视角,建立一整套合规的,高效和健壮的系统,从分账户,总账户等进行多个级别的核算,确保整个第三方支付系统的资金安全。

 

那么如何对账呢?按照及时性的要求,我们分为T+1和准实时的对账,下面分别介绍:

一, T+1对账

      即今天对昨天的账,是按天增量对账的一种,在日切点后,把落入日切点之前的当作昨天的账目进行汇总核算,得到昨天的一个余额,即昨日余额。

在多系统中,一个难点是日切点的统一,在传统银行IT系统中,都有一套成熟的日切系统来负责协调各个系统的日切,而对没有专门搭建日切服务的系统来说,也有一些简单的处理办法:如在业务入口点分配业务时间作为贯穿后续各个系统记账的业务基准,这样各个系统的流水均会以该业务时间为准,确保同一个时间点的流水在各个系统一定是在同一天内。另外一种方式是跨多一天核对流水,即虽然对账的是昨天的流水,但会看前天和今天的,通过业务系统进行调整,然后按照其中一个为基准,重新记账。

 

二,分钟级的准实时对账

        一种好的方法是余额字段记录一个事务流水号(流水号自增,通过流水号可以找到对应的流水),余额和流水增量对账根据流水里面的事务流水号进行核对。

        前面两种办法都存在一个困难:即由于系统余额总处于交易中,因此余额的值时刻在变化,很难捕捉某个时刻的余额,然后和流水进行核对,那为了进行从会计核算层面获得一个期初的余额值,有什么办法吗?

        方法一:帐户自动具备按天轮换的机制,这样的机制本质是以空间换时间,通过两个定时轮换的账户按天轮换来获得期初的值,该办法具有一定的操作性,但也带有较多的风险,特别是个人的账户一般只能有一个账户,是不能进行随意切换的,该办法可以用在一些中转类的账户。


        方法二:时间片倒推,比如我们在00:30 拉取00:30的流水和余额,然后把流水反向推到23:59(即流水一条条扣除直到时间点在00:00之前的流水),那么23:59对应的余额就作为期末余额。

 

        有了前面的办法,那么每天的核对其实就是在昨天的期初余额基础上,找到变动的部分,相加后得到期末余额进行核对即可(新的一天,当前的期末余额变成第二天的期初余额),类似数学归纳法一样,只要期初余额是对的,那么期末余额的准确性就是判断一天内的变动部分是否准确即可,而一天内的变动和核对是相对比较简单的。

作者:tenfyguo 发表于2017/1/22 14:50:50 原文链接
阅读:8 评论:0 查看评论

相关 [会计 思考] 推荐:

[原]关于会计对账的一点总结和思考

- - tenfyguo的技术专栏
会计学有一个很重要和很出名的公式,相信很多人都见过:. 资产 = 负债 + 所有者权益 + 收入 – 费用.         但会计学上还有另外一个比较隐蔽的公式,虽然不像上面的公式那么出名,但也经常能见到它(或者变种运用)的身影. 那就是,即期末值=期初值+期间变化值,也就是期末值=期初值+期间入-期间出.

终极思考

- wei - 牛博国际
我的海淀剧院演讲门票放出后,八小时卖了四百多张,同事们说,日. 我淡淡地说,别这样,也许正是因为便宜才这么好卖嘛. 一转身我马上就打电话给老婆,操. 早知道就他妈把票价定高一点啦,真倒霉......干. 很大程度上,这可以解释两件事:1.为什么已婚事业男性的健康状况会相对好一些. 2.为什么在社会上受到尊重和认可的事业男性在老婆的眼里都是傻逼.

动车追尾的思考

- David Ruan - 扬韬
1、两列运行的动车追尾,绝对属于重特大责任事故. 雷电导致前车失灵,已经是责任事故了. 前车失灵,信号没有外发,又是责任事故. 调度体系没有发觉列车失灵,也是责任事故. 后车没有察知前车失灵,还是责任事故. 最后,后车发现问题,紧急制动系统有没有用也值得怀疑,因为后车司机据说是人工制动并殉职于岗位的.

重新思考电子书

- Alex - 爱范儿 · Beats of Bits
Hart,“古登堡计划”发起人,2011 年 9 月 6 日去世,享年 64 岁. 从 1971 年 Hart 制作第一本电子书,启动“古登堡计划”开始到 2011 年,Kindle、Nook 流行,正好经过 40 年. 如今电子书阅读器、电子书变得越来越流行,在北京的地铁上,你会经常看见低头拿着 Kindle、Nook、iPad、汉王的人们.

《系统思考》读后感

- 章明 - 所有文章 - UCD大社区
经别人推荐(都忘了是谁推荐的了~),买了这本《系统思考》,看完前几章,发现这是一本非常好的书. 全书的精华也都在前面几章,后面都是一些具体的案例分析. 为什么必须从整体研究系统. 将系统分块通畅破坏了你所试图研究的系统. 如果你破坏了系统内的连接,你就破坏了系统本身. 更奇妙的是,很多系统表现出他们的任何组成部分都不具备的特征.

Memcache架构新思考

- - ITeye博客
2011年初Marc Kwiatkowski通过Memecache@Facebook介绍了Facebook的Memcache架构,现在重新审视这个架构,仍有很多方面在业界保持先进性. 作为weibo内部数据处理量最大,对数据延迟最敏感的部门,基于本厂2年多来对mc的使用心得,我在本文总结对MC架构的一些新思考.

Google Reade关闭的思考

- - 猫星石 ~CafeNeko
关于google reader所引起的口诛笔伐已经看的足够多了,所以这里我并不想再去谈Google的这个决定正确与否. 我想说的是关于”后GR时代”的一些思考. 关于GR的好我已经听的太多,曾几何时我也是重度的GR脑残粉. 但是早在GR宣布准备关闭时,我一边看着GR里面永远也不会清空的条目,我就在想,我真的还是GR的脑残粉吗.

表单设计的思考

- - 腾讯ISUX - 社交用户体验设计 - Better Experience Through Design
我们几乎每天都会接触形形色色的表单,登录账号、填写信息以获取服务、发布内容等. 然而填写表单的过程往往不是特别愉悦的,我们需要消耗时间输入信息,点击提交,可能还需要等待审核;尤其是碰到较为复杂、流程长的表单,如果用户体验较差,很容易让人产生挫败感,在中途选择放弃. 那么,如何提高用户填写表单的效率,防止他们出错或中途流失,提升愉悦度及转化率呢.

谈CIO思考之重点

- - 人月神话的BLOG
在这里主要针对中大型企业有专门的IT部门和独立开发运维团队的情况,对于这种企业的CIO,核心的一些思考点在哪里,和常规软件企业又有哪些差异. 对于企业IT部门是成本中心,在开源节流上,利润中心的重要性和关注度还是远远高于成本中心,这也是很多企业IT部门往往不受重视的原因,CIO本身也没有太多的决策权,在本身没有太多独立开发能力时候更多仅仅是一个运维中心的角色.

推行TDD的思考

- - 简单文本
目前来看,推行TDD的障碍大约有如下几点:. 分析需求并进行任务分解的能力; 3. 将测试作为开发起点的开发习惯; 4. 开发人员的重构能力,包括如何识别坏味道和如何运用重构手法; 5. 单元测试的基础设施,尤其是测试数据准备;. 开发人员对于软件质量,常常偏重于软件的外部质量,体现在他们的工作效益上,就是被测试人员发现的缺陷数.