在建立和解系统之前，必须掌握一定的财务知识。和解系统很难做到，互联网上基本上没有教授如何制作调解系统的手。本文作者结合自己经历的调整系统项目进行自我梳理集成输出，希望对你有帮助。

指南

本文根据我自己经历的和解系统项目进行自我梳理综合输出。

虽然我尽可能用共性编写，但它可能不适合所有系统和形式，我自己也在不断学习自我发展。可能是文章内容有些错误或描述不严格的地方。有知识的老师努力指出来的话，我会修改优化。

所以，这句话，我只提供参考。

在建立调整系统之前，有必要学习系统的财务基础。否则，在需要沟通的时候，可能连需求者(财务负责人)的话都听不懂。

财务人员，有一套专业的财务语言！很有趣，我们能理解！

一、前言

互联网的迅猛发展带动了各行各业的数字化转型，数字化转型需要朝着2C、2B两个大方向努力。

过去几年，人们忙于建立自己的业务和管理系统，通过重大集群或SaaS或PaaS模式进入互联网时代的轨道，到今天为止，无论走到哪里，都可以通过小程序、APP、三方平台预订购物订单等。

朝着消费者的方向，2C事业到处开花。后方，2B力量也在不断提高，2C和2B的融合给各行业品牌带来了巨大的痛苦。

很难和解。

为什么很难和好？

数据种类、来源、风格、完整性参差不齐，准确度参差不齐。每个系统或三方在数据时间节点一致性较弱，在前端感觉不到调节功能。

协调系统介于业务和财务系统之间，市场上没有具有共同能力的协调系统。

这个位置如下图所示。

从上图可以看出，他的上游有订单和付款(账单)，下游有金融(朋友、蝴蝶等)，还有各种财务能力工具(如发票管理等)。

写这篇文章之前，我在互联网、书籍中了解学习行业的和解系统的方法，从总体上来说，由于行业问题和专业问题，我各有优劣，同时我自己也多次主导过调解系统。有比较简单复杂的东西，其中涉及的难点很多。

更复杂的是，当时系统审查会连续举行了10天以上，平均每天有6个小时以上的会议时间。另外，调整系统介于业务和金融系统之间，单纯理解业务是不可能的，必须踩坑，所以同步需要了解财务相关知识，具体后文会说明一部分。

近几年来，在建立调整系统的过程中，从10多名财务从业者、财务专家那里学到了很多财务调整相关知识。

有些知识在调整系统中运用是非常重要的，但在之前学的学习相关文章或教程中没有见过，本人也认为这部分知识在调整系统中起着很大的作用，后续篇幅也会涉及到。

和解系统很难做到。互联网上基本没有手把手，不教调解系统。很多内容都是那样的，前后翻一翻就能把人看得糊涂。

既然要写这篇文章，不如写得再细一点。

因为写的比较细，所以和解相关的文章不是短时间就能写完的。毕竟不是一两篇的篇幅，可以说清楚。

分为多个更新，更新频率“内线”划分，但必须更新。

第一篇将普及财政知识，使所有人都能快速进入有效的基于财务的理解阶段。

同时，第一篇首先预设了协调系统建设的需求方案，列出了需求，作为后续详细拆除的来源。

二、财政基础

2.1 对账的基本概念

调整是指检查帐簿，是指在会计中检查和检查帐簿的相关数据，以确保帐簿记录准确可靠。

没错。就是支票，账簿就是账簿。

在互联网产品中，检查是指对需要调整的数据进行检查，以确保数据的完整性和准确性，一般不会改变数据，而是有效地收集、验证、标准化(统一格式)相应的数据部分。

确认是指订单与发票的比较，订单是电子或纸质合同，发票是指资金记录(支付宝账单、银行账单等)。

调整是需要比较的数据，验证和标准化后进行一对一对比，确保数据记录的可靠性，找出双方的差异，支持差异数据的跟踪处理。

2.2 本方与对方的概念

调整是指一对一比较需要确认的数据(通常是订单和发票)，在比较之前需要预设

本方指的是可靠性较高（主观判断）的一方数据，或需主要对比的一方数据。

对方指的是被对比的一方数据。

在订单和账单两种数据类型上，理论上任何一方都可以被定义为本方，一类数据仅能被定义为某一方，不可同时将某数据既定义为本方又定义为对方。

2.3 原始凭证

会计凭证按照编制的程序和用途不同，分为原始凭证和记账凭证。

原始凭证是在经济业务发生时取得或填制的，用以记录和证明经济业务发生或完成情况的凭证。

我们在购买商品或服务时，所获得的原始票据，即为原始凭证，如：

去餐厅点餐时，点餐完成服务员提供的点餐单（有的有价格有的没有价格），付款时手机付款记录；

去超市购买商品时，付款完成，超市所提供的交易清单及付款记录；

通过互联网购物，产生的订单，订单对应的支付记录（支付宝、微信等）均属于原始凭证。

因此，原始凭证的种类很多，如发货单、收货单、领料单、银行结算凭证、各种报销单据等在业务发生过程中产生的依据都算作原始凭证。

从对账业务来说，涉及的凭证偏向于订单、账单、支付单等原始凭证。

2.4 记账凭证

记账凭证，会计专业术语，是财会部门根据原始凭证填制，记载经济业务简要内容，确定会计分录，作为记账依据的会计凭证。记账凭证亦称分录凭证，又称记账凭单，按照登记账簿的要求、确定账户名称、记账方向（借贷方向）和金额的一种记录，是登记明细分类账和总分类账的依据。

那会计分录又是什么？

我们日常如果有记账的习惯的话，一般会这么记：

• 购买商品：电脑，单价8000元，数量1台
• 支付总额：8000元
• 支付方式：支付宝（招商银行卡）

而，财务侧在对原始凭证确认后，记账的方法叫做复式记账法（借贷记账法），其所记录的内容，叫做会计分录，会计分录基于复式记账法有标准的格式。如：

• 借：库存商品-电脑 8000元
• 贷：银行存款-招行 8000元

基于借贷逻辑（参考资产负债表），我们可看出，库存商品-电脑属于资产类科目，在本分录中属于借方，代表资产增加，银行存款-招行属于资产类科目，在本分录中属于贷方，代表资产减少。

即，在我所有的资产中，库存商品增加了一台电脑，但银行存款减少了8000元。

如果购买商品时，商户开具了发票，在借方的分录应该是库存商品-电脑不含税价与税金两条记录，这里就不细写了。

因此，记账凭证其实就是会计分录，会计分录就是财务人员的标准记账方法。

记账凭证是由会计人员对审核无误的原始凭证或汇总原始凭证，按其经济业务的内容加以归类整理，作为登记账簿依据的会计凭证。会计人员填制记账凭证要严格按照规定的格式和内容进行。

专用记账凭证，是指分类反映经济业务的记账凭证。这种记账凭证按其反映经济业务的内容不同，又可以分为收款凭证、付款凭证和转账凭证。

在对账系统中，对账的整体动作，其实相当于财务人员对原始凭证的对比与审查，审查完成的记录成会计分录，最终生成明细账（有多少订单就有多少条明细）及汇总账（无论多少条，只要在我计算的归属范围内的，统一汇总成一条）。

因此，对账系统完成对账后，会根据用户实际诉求，生成明细账及总分类账，即记账凭证。

2.5 单边

在一对一对账完成之后，发现某一条数据对应的另一方无数据，一般称为单边。

比如有订单信息，但无与订单对应的账单数据，那么本次对账差异称为订单单边。

比如有账单信息，但无与账单对应的订单数据，那么本次对账差异称为账单单边。

举例以订单为本方，某订单金额为300元，但对账时未找到账单，则对账差异为300元，差异类型为订单单边。

其公式为：本方金额-对方金额（双方均可以是合并金额）

公式金额等于0为平账，金额等于本方金额为本方单边，金额等于对方金额为对方单边，金额大于零且小于本方金额或金额为负责默认为金额不一致，属于长短款，需溯源查询差异原因。

2.6 长短款

财务侧的现金长短款是指在盘点和核对库存现金时，发现除挪用现金、白条顶库、超限额留存现金等情况以外原因的现金日记账余额与库存现金数额不符。在对账系统中，一般代表应收与实收不符（非单边）。

对账时，除了会发生2.5项所述单边现象，也会存在长短款现象。

• 长款：应收100元，实收120元，计算后，出现了20元的额外收益，这部分即为长款。
• 短款：应收120元，实收100元，计算后，少收20元，这部分即为短款。

2.7 轧（gá）差

轧差是指利用抵销、合同更新等法律制度，最终取得一方对另一方的一个数额的净债权或 净债务，如市场交易者之间，可能互有内容相同，方向相反的多笔交易，在结算或结束交易时，可以将各方债权在相等数额内抵销，仅支付余额。

上述为财务侧轧差的概念，或许难以理解，但举个例子就明白了：

预设A和B都很讲信用，A欠B10万元，B欠A4万元，没有轧差的情况下，B需要向A支付4万元，而A需向B支付10万元；轧差后，则A对B的净欠额为6万元，A只需向B直接支付6万元。

在对账系统中，轧差一般指的是两两之间金额汇总之后的总差额。

2.8 平账与差异（差错）

这里的平账是指对账系统的对账结果：对账对平，而不是财务管理所说的让各个分类账户的金额与其汇总账户的金额互相核算相等，达成会计中的所说的“账账相符”。

差异（差错）指的是未对平的数据。一般差异包括单边、长短款等。

差异的原因一般包括：

• 单边，即本方或对方无数据；
• 长短款，即本方与对方有数据，但对账金额不一致。

单边及长短款可以依靠系统进行初始预判断，再人工复核；但长短款的原因一般需要人工判断及确认。

2.9 财年财月

财年指财务年度，财月指财务月。

一般来说，我国的财年指的是自然年，财月指的是自然月。

国外的财年和财月有遵循自然年自然月的，也有跳出自然年与自然月单独设定的，比如美国部分州，会将企业成立当年的10月份定义为下一年的财年初始，10月份为下一财年第一个财月，且其财月并非自然月，而是以445标准执行，即第一季度第一个财月是从10月1日起的四周，第二个财月为后续四周，第三个财月为再后续五周，所以每个财月都跨自然月。

一般我国国内系统对应的财年财月以自然年自然月为准。

2.10 其他

只要涉及与财务相关的系统，绝对不允许对源数据（原始凭证）进行任何修改。

除了最终汇总金额小数位控制，其他任何阶段，在计算过程中，不可进行四舍五入、小数位限制等操作。

本章2.3-2.8仅作基于对账系统的简单描述，其在财务中所代表的含义相对较为复杂，个人建议应该从财务的角度去丰富相关的知识。

同时，没有财务基础想走对账或需要走对账发展路线的，建议先恶补复式记账法、资产负债表等；若有财务基础的，忽略本篇财务基础部分，当然，若发现我有描述不当的，还请不吝指出，我将请教确认后进行修改更新。

三、需求场景

某零售品牌2C业务扩展迅速，对账系统老旧，且人工干涉较多，原对账中心已经跟不上业务发展，需建设最新对账中心。

3.1 现状

• 法人A：负责自有渠道，包括APP、微信小程序、支付宝小程序；
• 法人B：负责三方渠道，包括京东、天猫、美团、抖音；
• 支付方式：APP对接微信、支付宝、云闪付，以直连模式接入；
• 储值卡：APP支持储值卡支付，支持储值卡+三方组合支付；
• 储值卡账户：合规的单用途预付费卡，消费者储值统一存入法人A管理账户，消费者使用储值消费时，从法人A管理账户支付至门店/渠道账户；

3.2 建设目标

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

• 当业务渠道新增时，支持灵活配置化补充渠道信息，迅速接入对账系统；
• 当支付渠道新增时，支持灵活配置化补充渠道信息，迅速接入对账系统；
• 支持订单以文件形式导入；
• 支持账单以文件形式导入；
• 支持账务审核流程；
• 支持用户权限管理及数据权限管理；
• 支持人工平账。

3.3 数据关系

APP、微信小程序、支付宝小程序、京东、天猫、美团、抖音各渠道统一通过订单中心向对账中心输出订单，其周期为D+1，即每日0点获取前一日全部订单，以接口形式获取；

各支付渠道支付账单需从各渠道下载导入对账系统，其可支持下载周期为T+1。

3.4 其他说明

以上为基础需求描述，在后续讲解中若发现有遗漏的，在实际设计篇幅中进行补充，同时会对本篇进行优化更新。

四、需求梳理

学习做产品时，总有人在你耳边说，要想把产品做好，需要有自己的产品方法论。

什么是产品方法论？以需求梳理阶段举例，其实就是你去获取、拆解、梳理、规整需求的方法、使用的工具或者步骤等。

我所常用的方法是从上往下看，通过总-分模式，先从大框架上了解整体业务目标，再基于组成大框架的一个个小模块，去分别拆解、梳理细节内容。

这也就是人们常说的，框架思维。

以当前需求为例，首先确认清楚，我们要做什么？

做什么：做一套财务人员所需要的基于业务订单与支付账单的对账系统，对账完成后输出财务人员所需的凭证及报表。

使用者、输入、输出、核心能力已经很明确了。

• 使用者：财务人员；
• 输入：业务订单与支付账单；
• 输出：凭证及报表；
• 核心能力：基于订单与账单的对账。

框架方向了解后，我们应该怎么去梳理细节内容呢？

从整个产品的维度思考，我们的用户是财务人员，系统的属性也是偏向于财务的，那么整体来说，我们系统中将包含很多的财务底层规则。

因此，如果在看同学没有财务基础的，或财务基础很薄弱的，建议先阅读第一篇。而财务知识很丰富的同学可以接着往下看。

我们已经对框架熟悉了，也知道需要考虑财务规范，那么我们在需求的拆解与梳理过程中，每一个步骤应该把模块功能和财务规范做有效的结合。

4.1 业务输入

从第一篇模拟的业务需求来看，我们可以对获得的信息进行拆解：

法人： 是具有民事权利能力和民事行为能力，依法独立享有民事权利和承担民事义务的组织，是企业、公司的另一种称呼。在本需求中，某集团下有两个分公司（法人），分别负责自有渠道（自行建设）和三方平台渠道（外部合作渠道）的业务管理。

补充阅读：一个公司就是一个法人，我们看到公司营业执照中有法人代表，一般该法人代表就是公司老板，法人代表的含义是，他代表这个公司，是该公司（法人）的代言人。

所以在上游原始数据可能存在多个归属时，应着重考虑输入的原始数据归类问题。同时，在我们拿到这部分信息时，应该意识到我们所设计的表结构中，一定要有数据归属字段，如所属法人、所属渠道等。

从上表，我们已知需要从哪些法人及渠道获取订单数据，同时我们还应该从需求方获取相关的信息，包括但不限于：数据提供方式、提供周期、是否有统一订单中心进行处理等。

如果需求方当前系统比较简单，没有统一的订单中心负责接入全部订单信息，我们需要直接从三方拉取订单，那么需要额外准备与三方支持沟通的方式（钉钉群、微信群、企微群等），以便在需求梳理、数据传输确认过程中及时沟通了解一些不清楚的地方。

一般来说，三方平台都会有指定的支付方式，比如京东自有的京东支付、天猫的支付宝支付、抖音自有的抖音支付或微信/支付宝支付等；所以法人B负责的三方渠道部分我们不考虑支付功能接入。

而法人A所负责的自有渠道，可能会对接多种支付方式，以上需求描述也明确的给出了对接的三方支付。

同时，明确了接入模式为直连。

直连指的是APP直接与三方支付（如微信）对接，不通过聚合支付统一处理。而通过三方聚合支付（如随心付、扫呗等）对接的一般属于间连。

直连与间连各有优劣，本文不涉及支付具体细节就不细讲了，有想了解的朋友可以自行去了解一下支付相关的知识。

回归需求拆解，我们还需要明确：对接的支付渠道通过何种方式提供账单数据、提供账单的周期等；三方平台如何提供账单数据、提供账单的周期等。

储值第一要素是合规，除了企业自身需要去申请单用途预付费卡资质之外，同步需要与银行签订监管协议，储值金额统一存入企业在该银行的监管账户中。

单用途预付费卡主要分两种，记名卡与不记名卡。两者可储值额度不同、有效期限制也不同，可以单独去了解一下。

要点：所有人都应该重视的是，消费者储值资金虽然在监管银行所设立的企业账户中，但这笔钱的所有权仍是消费者，对于企业来说，这不是收入，而是负债，在资产负债表中属于右侧，在凭证中所体现的科目主要是预付费或递延收益。

这部分资金，只有消费者在使用储值消费后，才能基于订单支付信息从监管账户划入收入账户。

在本示例需求中，用户使用储值卡金额支付时，其订单来源是法人A所属业务渠道APP，账单来源是法人A监管银行。

我们在进入4.1之前有讲，必须考虑财务属性，因此，除以上信息外，我们还需要补充财务相关信息，包括但不限于：

财年财月、税金管理、会计科目等。

同时，输入给系统的全部数据，需要区分主数据与业务数据。

主数据指的是能够辅助系统功能的数据类型，包括法人、渠道门店、支付渠道、商品类型、活动营销、财年财月、税率管理、会计科目等，后续在产品设计过程中，配置的各种属性如对账规则、凭证规则等都算主数据范畴。

业务数据指的是需基于系统规则进行对账处理的数据，在本系统中，业务数据为订单数据及账单数据。

对账完成输出的会计凭证及报表数据，也属于业务数据。

• 主数据的来源一般分为两种，从上游系统同步或在自有系统创建。
• 业务数据来源一般也分两种，从上游系统推送或通过文档导入。

本小节拆解梳理完成后，可以形成如下导图：

注：是否有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 数据获取

数据获取模块分别对接外部业务数据系统、主数据系统，获得外部系统推送的相关数据，同时为了提高对账系统的数据获取的灵活性，增加文档导入功能。

5.1.1.2 数据准备

数据准备阶段，需要对业务数据进行归类、校验，补充主要字段，如财月信息等，订单数据需筛选出可用来对账的状态。

无论是订单或账单数据，无论其来源属性，最终字段格式会在本流程模块中进行最终统一，以便于对账引擎面对的永远是“标准”且统一的数据格式。

5.1.1.3 对账引擎

对账引擎作为对账系统最核心的模块能力，其在设计时需要考虑数据拉取、规则匹配、对账取值、批次分配、差异对账、结果输出等正向流程之外，同时需要考虑特殊场景产生的逆向流程，如任务撤销引起的对账回退，已对账数据的历史版本恢复等。

5.1.1.4 差异处理

对账结果一般分别对平与差异（差错）两种，简单的差异可以通过系统预设逻辑进行预判断（如单边），人工二次验证确认即可，该做法可有效减少财务人员工作量，提高效率，而特殊差异，如金额不一致的，无法预判断的，则需要人工判断差异并确认。

人工判断处理流程中，应包含人工平账规则。

5.1.1.5 凭证处理

基于指定周期的对平数据、处理完成的差异数据（最新），拉取凭证生成规则生成所需的财务凭证。

凭证生成完毕应由财务人员基于审核流程进行审核。

5.1.1.6 报表输出

报表与凭证的设计逻辑相对一致，均是从对账结果获取数据后依据模块规则生成结果。

报表在系统中有两个流程位置的可能，第一种与凭证平行，双方取值来源一致，分别生成凭证与报表，且可基于勾稽关系互相可以验证数据的准确性；第二种则是基于对账结果先生成报表，再直接从报表中取值生成凭证。

此两种做法应以实际业务需求为准。

5.1.1.7 系统配置

本次系统设计中，法人、业务渠道、支付渠道、财务主数据、对账规则等都归属于系统配置模块，但因其在整个系统主线流程中各有交叉，在前几项中也有所展示，故本项图片中仅展示非业务配置项。

5.1.2 系统框架

在实际设计产品时，总有人会说，什么总-分模式都是扯淡，当没有能力将需求转换为功能的时，很难去规划出产品的【总】。

说的对。

所以，5.1.1其实就是在将需求转换为功能模块，在补充规划【总】之前的积累。

题外话：为什么说方法论是学不到，而是需要自我的经验、学习、踩坑等各种经历积累梳理后的成果？

你没有从微小到大框架循序渐进思考、成长的过程，又如何能够迅速形成自我思维模式，再反向从框架到细节去剖析？

那么，方法论的成熟到底怎么来？

积累、学习、提升，从细小功能到子模块到主模块到系统到产品战略，当你在摸爬滚打N久后，自我梳理后，你面对新的需求、新的挑战时，你的脑子里瞬间闪过了无数的画面及可能，思考1秒或者2秒，你大方向的解决方案其实就出来了，再仔细思考一番后，核心流程也能梳理出来，这个时候，你会一点点去跟对方（需求方）确认这是否就是对方所要达成的目标。

在5.1.2，我们将进入真正的【总】，这需要你对前文充分阅读。

5.1.2.1 系统总框图

总框图体现的是业务结构，包含了需要设计的系统组件结构与外部输入或输出的关联关系。

在整个系统设计中，总框图是划定主线、刻画核心能力、体现模块依赖关系的重要蓝图。所以，总框图的绘制要点是模块独立、相互依赖、全而不细、路径准确、组成清晰。

总框图从下往上，灰色部分为外部系统，灰色箭头代表对账系统与外部其他系统的交互，支持接收外部数据（业务数据及部分主数据），支持推送成果至外部系统，如审核通过后的凭证推送至用友、金蝶或SAP等系统。

橙色框线内，除系统设置外，主要区分了量大模块组合，分别为数据处理相关与对账处理相关。数据处理业务流程基于橙色箭头所示，从获取到处理属于单向业务流；对账处理中，对账引擎为处理主模块，基于结果分别输出凭证与报表。

红色箭头的定义：对账中心可以拆分为两个系统，分别为对账处理系统（红色箭头上方部分）与数据处理系统（红色箭头下方部分），部分公司因业务因素，需要独立处理大量数据，包括订单、账单、活动、营销等，其已有或计划或正在实施数据中台，对账处理系统所需的可对账数据，将由该数据中台统一处理（处理后的数据除了推送对账，也会推送至BI或成本核算等系统）。

也有部分公司，处于财务独立性的考虑，会将数据处理与对账处理合并为一套整系统进行规划。

在实际产品规划过程中，应着重考虑以上因素。

5.1.2.2 对账主流程

流程图中，体现了几个重要的节点或数据：橙色部分标明，每次对账应将对账数据进行冻结；浅红色部分差异处理逻辑比较重要；中红色部分特殊标明冻结本财月，指的是从本节点往后生成财月报表及财月凭证逻的辑，其成果输出一般每财月处理一次（月结、季结、年度总结等）。

5.1.3 依赖关系

5.1.3.1 系统间依赖

我们从总框图中已经可以看到，从系统关联维度考虑，包括上游输入系统、对账系统、下游输出系统，三个系统组成整体的业务流程，这三个系统之间存在着强依赖关系：

对账系统依赖上游输入系统提供的数据源；

下游输出系统依赖对账系统提供的对账结果数据。

其所形成的业务链如下，且不可逆、不可空缺。

5.1.3.2 功能组件依赖

在总框图及主流程图中，我们不难看出，对账系统核心组件主要包括数据获取、数据准备、对账引擎、结果处理、业务输出；其业务关系如展示顺序，业务不可逆不可缺。

其中，设计的规则部分虽然独属于系统设置模块，但其目的亦是为以上业务组件服务，可以拆解到五大核心中。

从图中也可以看出，整个对账系统组件关系也可以基于业务有效区分事前、事中、事后。与我们前面所讲的产品阶段思考维度又有重叠。

因此，在做产品设计阶段，我们应该从多维度去剖析，互相验证，以保证设计成果的准确性、可行性。

注：以上部分图片来自互联网，如有侵权请私聊告知删除，谢谢！

本文由@PM陈镜安 原创发布于人人都是产品经理。未经许可，禁止转载。

题图来自Unsplash，基于CC0协议。

该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。