支付宝对账管理在哪,支付宝商家对账中心

注：是否有OC或OMS提供订单数据统一功能，应根据实际项目情况进行确认。本文案例默认有订单中心统一管理两个法人下全部渠道订单数据。

从系统关系来思考，可以形成如下框图：

在实际项目中，如果甲方（需求方）已有订单与账单中心可以统一管理并提供业务数据，那么直接与其对接获取即可，若数据不能满足对账中心需求（缺核心字段、缺状态等），则应向对账中心上游（订单与账单中心）提出需求即可。

特殊情况下，可能需要配合上游与上上游进行少量沟通（以实际情况为准）。

4.2 成果输出

输出的要求：以三方账单为本方，实现最小周期T 1的对账，每财月月结输出明细账、汇总账，汇总账支持按法人、渠道维度进行查询，支持输出汇总凭证，输出月结报表。

前文有讲本方与对方的关系，在本示例需求里，要求本方为三方账单，三方账单即微信、支付宝、银联、京东、抖音等提供的支付记录明细。从此需求也可以看出，用户对市场上较大平台的信任度较高（或许是目前自研系统财务诉求的一个常态）。

本条不算输出需求，但属于输出成果时，重要的规则依据。

在很多的术语中，我们常见的有T 1、D 1、W 1、M 1，或者不仅仅是 1，而是 N。

1指在当天基础上加一天，隔日的意思； N指延长的天数不确定，一般来说有这种需求的项目，N是支持可配置的，比如T 1、T 3等。

• T是Time，业务中表示工作日；
• D是Day，业务中表示自然日；
• W是Week，业务中表示一周；
• M是Month，业务中表示一个月，财务上用来表示财务月；

如需求所述，最小对账周期颗粒度支持到T 1，也就是工作日对账，比如：

本周一的数据，本周二对账；本周五的数据下周一对账；本周六和本周日的数据也是下周一对账。

本条不算输出需求，而是属于对账周期，也是输出成果的周期。

与上两项不同，该3条输出要求均属于成果类输出要求。

需要按指定维度输出明细结果、月结总账以及会计凭证。

需要按照法人、渠道两个层级维度查询阶段明细数据，并支持基于该两层维度生成月结总报表及会计凭证。

如，渠道维度：

• 明细账：法人A所属APP渠道，2022年9月1日明细记录共计1000条，其中对平980条，差异20条；该两类数据分别在平账明细与差异明细中查询。
• 汇总账：法人A所属APP渠道对平明细980条，合计收入总额3万元；差异中包含应收未收、应付未付，汇总轧差后，应收未收200元。
• 月结汇总报表：法人A所属APP渠道，2022年9月份对平共30000条，差异1200条。合计收入总额9万元，应收未收3800元，应付未付1000元（其中商品退款500元，用户补偿500元）。

凭证信息（例）：

会计凭证1：

• 借：银行存款-招行 90000元
• 贷：主营业务收入-APP 79646.08元
• 贷：应交税费-应交增值税-销项税 10353.92元

会计凭证2：

• 借：应收账款-APP 3800元
• 贷：主营业务收入-APP 3362.93元
• 贷：应交税费-应交增值税-销项税 437.17元

会计凭证4：（退款500元）

• 借：商品库存-APP 500元
• 贷：银行存款-招行 500元

会计凭证5：（用户补偿500元）

• 借：营业外支出-APP 500元
• 贷：银行存款-APP 500元

示例中同步体现了税金与不含税金额的分录，默认以商品销售税率13%为基准进行演示计算。

4.3 系统功能

输入清晰、输出明了。

那么，在功能设计上，也应该着重从这三点考虑，分别对应输入、对账、输出。

4.3.1 输入相关

与上游系统对接，包括主数据、业务数据系统，在对账系统规划导入数据规范、数据处理逻辑。

接收上游系统提供的主数据，包括渠道门店、商品分类、营销活动等，支持渠道门店在系统中自行创建。

接收上游订单中心推送的订单、接收上游账单中心推送的账单、接收手动导入的订单及账单。

对主数据日常/更新推送至系统的进行完整性校验，考虑主数据的变更、重复、缺失字段等处理手段。

对订单进行完整性校验，包括去重、非空、状态筛选、数据归属判断及补充。

对账单进行完整性校验，包括去重、非空、数据归属判断及补充。

对通过校验的订单及账单进行字段结构的格式统一，以便于后续对账阶段有效拉取相应对账数据。

对未通过校验的订单、账单、主数据进行独立展示、标签，建立处理规则。

4.3.2 对账相关

在需求梳理过程中，很多的功能需求方是无法提出来的，如本示例需求，输入和输出说的很清晰明了，但功能其实基本略过，只有核心的对账及基于对账结果的处理。

那么，我们可以从事务处理的维度去思考功能的规划设计，事前、事中、事后。

事前：事前主要分两部分，第一部分为输入对接，第二部分为输入处理，这两点在4.3.1已梳理。

在对账模块中，事前还包括从规范后的数据表中拉取对账数据；

事中：指的是对账过程中对账的功能及逻辑，这里是整个对账模块最复杂的部分，会涉及到对账任务、对账组别、对账批次、对账类型、多次对账、差异对账，甚至是对账回退等；

事后：指对账完成后的处理，包括差异分析、差异处理，输出最终结果等。

在事后阶段输出最终报表成果时，表中展示含税总价、未税总价、税金总额，其中税金相关计算公式如下：

含税单价＝未税单价＊税率（1 13%）

未税单价＝含税单价／税率（1 13%）

税金=未税单价＊税率（13%）

4.3.3 输出相关

对账完成后，依据财务侧需求，需要输出对账结果，包括明细表单、汇总表单、会计凭证。

4.2部分示例描述了输出成果内容，本节主要讲述通过何种逻辑规则输出所需成果内容。

从需求描述来说，可分两个阶段的输出，分别是日常对账阶段与月结阶段。

日常对账阶段，需要输出对账结果、差异分析。

对账结果逻辑在对账规则中体现，差异分析逻辑在差异分析规则中体现。同时，差异分析因为涉及到系统与人工处理的双重逻辑，所以需要有独立的差异处理逻辑。以上两点，均需要支持将成果导出文档，一般是Excel格式，这部分需要预设表格字段规则。

月结阶段成果包含月结明细报表、汇总报表、会计凭证。

明细报表来源于日常对账明细一致，其取值逻辑与导出表格规则一致即可；

汇总报表应基于财务需求，预设多报表字段及计算规则，如基于法人的汇总、基于渠道的汇总、基于商品类型的汇总等；

会计凭证需要根据财务侧需求，支持可配置凭证格式，配置凭证内容取值，需要有借贷平衡相关的财务校验逻辑等。

无论什么行业，尝试总分模式/先框架后细节的结构化做事方法其实是很多人形成自我方法论雏形的过程。除了需求阶段我们使用总-分模式进行梳理之外，在方案设计阶段，这种方法依旧好用。

1. 总：考虑清楚整体的业务结构（或功能结构），理清楚需要哪些大模块来组成目标系统。
2. 分：在各个模块中填入子模块及关键能力。

最终的结果需要达到：大能统察全局、合规合法、业务正确、冗余有度，小能功能具象、细节合理、流程清晰、落地可行。

这样输出的内容，在项目团队中，即可向上战略，又可平行沟通，还可向下赋能。

因此，在本次的第五大部分，我们从两个维度进行阐述：

5.1 系统框架

5.1.1 系统主要组成部分

系统的框架不是凭空而来，而是基于对需求的透彻理解，对所设计出来的各个功能组件的有效融合，整个系统中，各功能组件都有各自不可或缺的作用，且尽可能保持功能的独立性（涉及解耦的不在这里讲）。

就如一张桌子，至少需要有桌面、桌腿两个大模块组成，其都有各自的作用，各自作用由独立不重合。

基于此，我们从业务维度考虑，可以进行如下设计参考（包括但不限于）：

• 对接外部输入，以有效接收主数据与业务数据，暂定为数据获取模块；
• 数据获取后，进行有效的归类、验证、格式统一，以支持对账处理，暂定为数据准备模块；
• 数据准备完毕后，基于各种规则进行对账，需要独立的对账引擎模块；
• 对账完成后，结果输出，除了对平部分结果，差异需要分析及人工判断，需要差异处理模块；
• 差异处理后汇总对账结果，需要输出凭证及报表，需要凭证规则模块、报表逻辑模块；
• 凭证与报表需要审核验证流程，需要业务审核模块；
• 凭证与报表展示需要凭证管理与报表管理模块；
• 系统需要进行用户管理、主数据管理、规则管理、权限管理等系统配置模块。

5.1.1.1 数据获取