资金对账系统的设计思考

资金对账系统的设计思考

参考文章:

资金安全是公司业务稳定运行的核心方面之一,风险容忍度极低,实施上任何公司都希望全年资金运营风险事件为零。一个稳定可靠的清结算系统是资金安全的前提,一个严谨、健全、灵活的对账系统是保障。本文主要对资金对账系统进行总结探讨。

对账系统处理步骤:数据准备 => 数据核对 => 差错处理

数据准备

该模块主要实现两个目标:

  • 第一是为不同的外部系统提供多元化的接入机制
  • 第二是通过数据适配的手段把外部数据以统一的格式进行转换和存储

数据核对

资金流数据对账逻辑

问题梳理:

  • 漏结:发起方有数据,接收方无数据。
  • 重复结:发起方有一笔数据,接收方有两笔数据。
  • 错结:发起方和接收方数据不一致,一般发生在金额和状态两个字段。

对账方式:

  • 单向对账:以一方数据为准,进行对账。

    -- SQL实现:TABLE_A和TABLE_B对账,以TABLE_A为准
    SELECT A.KEY, A.VALUE AS VALUE_A, B.VALUE AS VALUE_B, A.VALUE-COALESCE(B.VALUE,0) AS DIFF
    FROM TABLE_A A
    LEFT JOIN TABLE_B B ON A.KEY =B.KEY  -- LEFT JION
    
  • 双向对账:双方数据互为基准对账。 发现问题更为全面,优先选择。

    -- SQL实现:TABLE_A和TABLE_B对账,TABLE_A和TABLE_B互为基准
    -- 方式1:FULL JOIN 
    SELECT COALESCE(A.KEY, B.KEY) KEY
      , COALESCE(A.VALUE,0) AS VALUE_A
      , COALESCE(B.VALUE,0) AS VALUE_B
      , COALESCE(A.VALUE,0)-COALESCE(B.VALUE,0)  AS DIFF
    FROM TABLE_A A
    FULL JOIN TABLE_B B ON A.KEY=B.KEY
    
    -- 方式2:UNION ALL + GROUP BY  -- 推荐,因为代码更精简
    SELECT T.KEY
      , SUM(VALUE_A) VALUE_A
      , SUM(VALUE_B) VALUE_B
      , SUM(VALUE_A)-SUM(VALUE_B) AS DIFF
    FROM (
        SELECT A.KEY, A.VALUE AS VALUE_A, 0 AS VALUE_B
        FROM TABLE_A A 
        UNION ALL
        SELECT B.KEY, 0 AS VALUE_A, B.VALUE AS VALUE_B
        FROM TABLE_B B
    ) T
    GROUP BY T.KEY
    

对账粒度:

  • 明细对账:明细数据比对
    • 优点:可以准确定位问题数据。
    • 缺点:
      • 对账口径设计比较复杂,因为我们需要同时针对漏、重、错三种错误类别设计不同的对账口径,同时还要考虑到业务的边缘场景。稍有不慎,就会影响对账的准确性。
      • 处理的数据量大,对账处理过程长。
  • 汇总对账:按一个维度汇总后比对
    • 优点:对账口径设计简单,可快速实现,不易出错。处理数据量较小,对账过程快。
    • 缺点:无法定位数据底层问题,一旦发现问题,还需进一步寻找问题数据。
  • 因此,推荐的做法应该是以明细对账为主,定位具体问题。以总数对账为辅,对明细对账的结果进行复核兜底。

对账口径:

image-20210619231920769

对账时机

image-20210619232048387

差错处理

image-20210619232113281

会计科目对账逻辑

在资金流数据对账的基础上,对每个资金业务配置记账模板(例如:借 科目1 + 贷 科目2),将单一资金流数据转换为会计复式记账分录数据,进一步体现为会计科目的流水,并计算科目余额,然后与外部渠道实际余额进行账实核对;同时还可以利用内部会计科目之间勾稽关系,进行账账核对(不同科目发生额/余额之间的核对)

TODO: 实现思路举例

©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 206,723评论 6 481
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 88,485评论 2 382
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 152,998评论 0 344
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 55,323评论 1 279
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 64,355评论 5 374
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 49,079评论 1 285
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 38,389评论 3 400
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 37,019评论 0 259
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 43,519评论 1 300
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,971评论 2 325
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 38,100评论 1 333
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 33,738评论 4 324
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 39,293评论 3 307
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 30,289评论 0 19
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,517评论 1 262
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 45,547评论 2 354
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 42,834评论 2 345

推荐阅读更多精彩内容

  • 1 hive表关联查询,如何解决数据倾斜的问题? 倾斜原因: map输出数据按key Hash的分配到reduce...
    Alukar阅读 3,272评论 0 15
  • 一、单例模式 二、数组操作 三、字符串操作 四、集合操作 List Set Mep 四、IO操作 四、SQL题 1...
    joshul阅读 412评论 0 2
  • Hive 是基于Hadoop 构建的一套数据仓库分析系统,它提供了丰富的SQL查询方式来分析存储在Hadoop 分...
    三万_chenbing阅读 12,123评论 0 10
  • Hive优化 今天的主要内容——Hive优化 Fetch抓取Hive 中对某些情况的查询可以不必使用 MapRed...
    须臾之北阅读 1,228评论 0 3
  • 测试数据 course.txt1,数据库2,数学3,信息系统4,操作系统5,数据结构6,数据处理 sc.txt95...
    大数据技术进阶阅读 4,162评论 0 1