大家好，关于来说一下对账系统的设计方案很多朋友都还不太明白，今天小编就来为大家分享关于的知识，希望对各位有所帮助！
对账系统作为支付系统的基石系统，处于整个支付流程的最后一层，主要用于保证我们的支付数据与第三方支付渠道或银行的一致性。
在没有对账系统之前，财务会在第二天人工核对前一天的应收账款和实际收款。如果不一致，则需要逐一检查数据，找出不一致的数据。对账系统出现后，可以减少这种繁琐的手工操作。财务只需每天关注系统的对账记录，释放生产力。
系统整体设计
对账系统设计主要分为以下四个模块：
通道数据处理模块、数据处理模块、数据校验模块、差分数据处理模块，模块调用顺序层次结构图如下。
首先介绍一下通道数据处理模块。
渠道数据处理模块
该模块主要负责通道对账文件的下载、分析和数据记录。
目前，市场上的第三方支付渠道对账文件下载方式主要分为以下几类：
第三方渠道定期推送到SFTP/FTP。这种模式比较简单。我们定期从SFTP/FTP 检索对帐文件。调用第三方渠道对账文件下载接口。该模式需要连接通道下载对账文件接口，定期调用下载。支付宝、微信就是这种模式。从支付渠道网站手动下载对帐文件。这种模式是最不友好的，需要我们花费人力下载文件。除了下载方式不同之外，对帐文件的格式也存在一些差异。例如支付宝的对账文件格式是csv，微信的对账文件格式是txt，还有一些渠道是xml和xls。
第三方渠道对账文件中的字段数量和字段名称也不同。
一般来说，连接到这一层的每个通道都需要根据这个通道的特点进行专门的开发。这一层可以对接口进行抽象，将下载和解析接口暴露给外界。每次访问频道时，只需实现该接口对应的方法即可。
这一层的开发并不难，只要按照对账文件格式解析文件即可。一般情况下，对账文件中需要提取的信息如下：
商户号商户订单号渠道序号交易日期交易金额手续费退款原始订单号下面说一下开发这一层需要注意的一些细节。
1、如果您通过同一渠道申请多个商户账户。在这种情况下，如果每个商户账户前一天都有交易，第三方渠道将为每个商户账户生成一份对账单。因此，这里设计系统时需要考虑到多个对账单据的处理。 2、对账文件需要考虑重复下载。一般情况下，通道调节文件一旦生成就不会改变。但第三方渠道也可能出现异常，导致我们收到的对账文件数据不完整。在这种情况下，需要有一种机制来重新下载数据并解析到数据库中。 3、各个第三方渠道的下载时间不同。
数据处理模块
说完了对账文件处理模块，我们再来看看数据处理模块。
该模块主要是提取我们前一天所有成功支付的交易数据以及上一个模块中存储的前一天的报表的交易数据。为了减轻数据库的压力，提取的数据只需要包含必要的字段，不需要提取整行数据信息。一般来说，您只需提取交易时间、金额、交易订单号、渠道返回流水号即可。
这一层主要是数据库的查询行为。最好使用备用数据库进行数据查询。因为这里我们需要提取前一天的全量成功支付数据。如果数据量较大，可能会导致主数据库变慢，影响在线支付交易。
核对模块
在这个模块中，我们使用上一个模块中提取的数据来检查订单号和金额是否完全一致。验证模块伪代码如下。
该过程可以产生三种类型的差异数据。
第一种情况是本地数据存在，但相反的数据不存在。这称为本地多帐户。
第二种情况是对端数据存在而本地数据不存在。这称为对等多个帐户。
第三种情况是金额不一致。
三者如图所示。
这里生成的差异数据存储在差异表中，供下一步模块使用。
差异数据处理模块
该模块主要用于处理上一个模块生成的差分数据。
上述三类差异数据中，金额不一致的情况比较少见，这种情况需要人工判断。
我们先来讨论一下本地方面的超记情况。
本地多账户是对账系统中最常见的情况。这种情况下，可能是由于交易时的日期问题，导致双方的会计日期不一致，导致账目不均。
我们先来解释一下日尻的概念。
日切，通俗地说，就是系统记账发生变化的时间，系统从当前工作日切换到下一个工作日。在这个过程中，如果我们的交易订单恰好发生在T日23:59:59，那么我们的记账时间就是T日。第三方渠道收到订单的时间为T+1天00:00:01，因此通过第三方渠道交易的对账日期为T+1天。
第三方渠道的T日对账文件会缺少此项，但我们的T日数据确实存在。这会导致在对帐过程中本地帐户和多个帐户之间出现差异。
对于此类差异数据，我们可以选择T+1工作日过账等待对账。 T+1对账时，报表中会包含相应的附加数据，这样在对账过程中就会产生交易对方多个账户的差异数据。
然后，T+1天的差异处理模块提取前几天的所有差异数据，并逐一检查本端的多账户数据和对端的多账户数据。如果验证一致，则两个差异的状态将更新为已完成。最后，如果没有剩余的不符数据，当天就可以结算账单。
伪代码如下：
可能会出现对端多个账户的两种情况。
第一种情况，测试环境和生产环境共享相同的第三方通道参数，导致测试环境交易订单也会出现在报表中。如果是这样的话，当我们确认测试环境中存在这批数据后，就可以忽略这批差异数据了。
第二种情况，本地交易订单存在，但状态不成功。此时，您需要调用第三方渠道提供的查询接口来查询订单的最终状态。如果查询成功，则更新订单状态，然后将差异数据状态更改为处理成功。
如果第三方渠道无法查询订单状态。如果我们与渠道确认订单最终支付成功，则需要将支付订单更改为支付成功，并修改差额账户的状态。
最后，我们再次对账了。由于对端多个账户中的数据都会有对应的本地数据，因此不会产生差异数据。这次对账完成，账目算清了。
用户评论
虚伪了的真心
对账系统设计太重要了，搞不好资金就混乱不堪，而且能自动识别错误真是太棒了，省得我们那么多人费力排查！希望能尽快上线使用！
有16位网友表示赞同！
龙吟凤
我也是做财务的，对账系统简直是利器啊！这个方案考虑很周全，自动化、准确性和便捷性都兼顾到。希望可以实现多平台同步，这样更完美了！
有17位网友表示赞同！
秒淘你心窝
对于一个快速迭代的公司来说，对账系统的弹性设计尤其重要。这个方案考虑到了未来的发展方向，很有远见！
有18位网友表示赞同！
冷风谷离殇
这个方案看起来很专业，但是能不能简单一点解释一下？毕竟很多没接触过系统设计的同事也不明白啊。
有14位网友表示赞同！
淡抹丶悲伤
我对账系统一直以来都觉得很麻烦，希望这个方案能真的解决这个问题，让我们可以更快更轻松地完成对账工作！
有5位网友表示赞同！
惯例
这只是设计方案吗？什么时候才能看到实际的效果呢？希望不是停留在纸面上…
有10位网友表示赞同！
泪湿青衫
从设计方案来看，数据安全方面做得很好，这是我最关心的点。毕竟数据的敏感性非常高！
有14位网友表示赞同！
一生只盼一人
这个自动化对账的功能太棒了！那是不是意味着我们财务人员的工作就快消失了？😅
有13位网友表示赞同！
疲倦了
对账系统这么复杂的设计，希望团队成员真的能够协同好完成。关键是开发能不能按时交付啊…
有9位网友表示赞同！
烟花巷陌
这个方案看起来比较完善，但具体实施的话，会不会遇到一些实际问题呢？毕竟软件设计与实际应用之间还是有一些差异的.
有8位网友表示赞同！
旧爱剩女
感觉这个对账系统功能强大，可以提升效率不少！ 但是成本方面怎么样呢？ 公司能够承受得起吗？
有8位网友表示赞同！
失心疯i
我倒是觉得对账系统的功能应该更全面一些，比如可以进行预警分析等等，这样才能起到更大的作用。
有18位网友表示赞同！
一样剩余
对账系统一直是我的痛点，希望能早日实现这一方案，让我们不用再去费心手工排查错误了！
有13位网友表示赞同！
风中摇曳着长发
这个方案是不是只针对公司内部使用？ 如果可以对外提供服务的话，那岂不是可以拓展新的业务领域？
有16位网友表示赞同！
摩天轮的依恋
希望这个方案能够真正地解决对账环节的痛点，提高工作效率和准确性。我们都期待着它的早日上线！
有20位网友表示赞同！
铁树不曾开花
我对账系统的设计真的非常复杂，我理解开发团队一定付出了很多努力才有了如今的成果。
有8位网友表示赞同！
|赤;焰﹏゛
这个方案提出的数据安全保障措施让我感到放心！ 对于一个涉及资金的系统来说，数据安全实在太重要了！
有7位网友表示赞同！
暖瞳
感觉这个对账系统未来发展潜力很大，如果可以继续优化和完善，也许会成为一家独大的解决方案！
有15位网友表示赞同！