本文作者所在的公司提供全链路的风控信贷服务，主要通过售卖数据产品和提供本地化系统部署服务获得盈利，这篇文章总结了他负责账务系统的工作经验和心得，希望能帮你对业财领域的产品设计提供些思路和借鉴。
笔者目前就职于一家中型的互联网金服企业，公司提供全链路的风控信贷服务，主要通过售卖数据产品和提供本地化系统部署服务获得盈利。公司内部自研的系统超过100多个，包括支持性业务系统及职能系统等等，本文将以笔者负责了2年多的账务系统来分享一些工作经验心得，希望可以帮助大家对业财领域的产品设计提供些思路和借鉴。
笔者公司的业务模式具有一定的独特性，不同于我们常见的市面上供应链类公司的进销存模式。公司主要为各大银行和金融机构提供信贷领域的风控服务，客户主要通过请求公司的数据产品接口产生费用，可以简单地理解为请求一次接口收费0.5元，一个月若是有1w人请求同一个接口则公司需要收费5000元。
根据上面提到的业务背景和业务痛点，我们基本就能够明确系统的基本定位，以及需要支持的业务功能和流程，概括来讲的话，系统定位为：集合了账单、开票、回款、财务报表的全流程一体化管理系统。
上图为笔者绘制的一份简版的账务系统的核心业务流程图，通过这张图我们来拆解每个业务模块。
计费单顾名思义为用来计费的单子，在这个单子里将包含的需要计费的信息，从流程图中我们可以看出计费单的上游业务是CRM的合同，也就是说其实计费单的计费信息最初来源于客户与我司签署的合同，则计费单是将合同中有关计费的信息进行了提炼和转换，通过计费单去作为后续出具账单的依据和凭证。
在计费单中包含产品信息、单价信息、计费方式、账号信息等等。
账单的上游业务是计费单，通过计费单我们就能知道账单中需要包含的每个产品的计费方式和单价等基础信息，则只要再有了每个产品数量（调用量），就可以为客户出具完整的账单，那么调用量则是来源于BI系统的调用日志，在触发重跑账单时，将计费信息和调用量进行匹配和组合，最终生成账单。
通过上述两个步骤，来解决我们刚才提到的业务核心痛点1。
当有了账单之后，就需要考虑如何与客户进行对账，那就到了解决业务痛点2的时候了。在之前线下业务模式中，我们调研到销售同事是跟客户通过公司邮箱发送账单的方式来展开对账工作，这样的方式放在系统上来进行也是非常方便的，同时也符合他们之前的工作习惯，于是我们决定在账务系统上支持每个客户的账单通过系统来发送到客户邮箱中。
系统在发送时会附带好账单，通过在系统中维护好收件人即可，邮件发送后若客户回复邮件，系统可以抓取到回复邮件自动带回到账单中，便于销售同事进行确认核账。
当账单确认核账后，一般客户就会要求我司为其开具相关服务发票，客户见票回款。开具发票是账务系统中使用最为频繁的功能模块之一，也有着比较复杂的逻辑处理。目前我们账务系统在开票时包含多种类型，将会在下面展开来讲。
为客户开具发票后，客户一般会在约定的几个工作日后进行回款，账务系统与主流的各大银行做到了银企直连，客户进行银行打款后当日也会回传到账务系统，则销售同事通过操作账务系统将回款进行拆分，同样在拆分回款时也包含多种类型，将会在下面展开来讲。
每个客户在我们的账务系统都拥有自己的账户，在账户中管理着每个客户的余额及对应的每笔收入和支出的流水，当然有的账户中可能还会产生坏账或人工调整金额等，总之所有会影响的客户余额的操作都会在账户中体现出来。
在确立账户时，需要明确账户的维度，是客户维度还是客户+业务线维度，亦或是客户+业务线+产品维度等等。
这里的主要提下账单产生的负向支出和回款的正向收入。当账单核账后，系统会生成对应的支出扣减的流水，客户的账户余额减少；当客户回款后拆分完成，系统会生成对应的一笔收入的流水，账户余额增加。
这部分在流程图中即是笔者用浅蓝色的长框框住的部分，是将账单、开票、回款三个表进行了关联汇总，此表在后续的财务数据的统计中经常会作为中间表用到，比如计算哪些账单是已开票已回款或者已开票未回款，哪些预付回款已开票，哪些预付开票是否回款等等，通过这张表可以得知各类的信息，为财务报表统计提供基础数据。
财务报表的统计是根据实际业务场景产生的，就笔者公司而言，目前在账务系统中已上线的财务报表包含：封账统计报表、包年权责报表、客户账龄表、客户逾期表、逾期汇总表、财务账龄表、财务收入大表、项目类收入表等等。
每个报表的处理逻辑和方法都是不一样的，在接到财务报表相关需求时，需要捋清楚报表内的每个字段的计算逻辑，更重要的是财务报表是依据财务维度出具的，在理解每个字段背后的含义时，需要结合一定的“财务原则”，不然很容易出现“我以为你说的这个意思啊”这样的场景。
简单来说，账务系统核心元素主要就是三个：账单、开票、回款，在这三个元素中最核心基础的当然是账单，其他的功能或者报表都是基于这些基础元素进行的延伸和拓展，所以我们需要先搞清楚这三者之间的会产生的哪些复杂的关联关系。
账单是开票和回款中间的桥梁，桥梁的作用体现在，开票时需要关联账单，回款时也需要账单。
我们根据业务需要，支持针对产生的账单进行开具发票，在开具发票时必须选择账单，可开票的金额需要小于等于当前的账单的金额；
另外一种开票的业务场景为，客户还未在我司产生账单，也没有预付款，但是需要我司提前进行开票，则如果只支持客户对账单进行开票，显然无法适配当前的业务场景，那么系统需要支持无账单下开票，确定好需要开票的业务线即可；
但同时也会有客户预付款的业务，同样还未产生账单，则此时需要支持按照预付款进行开票，在开票时必须要选择客户的某笔回款进行开票。
当客户进行回款后，需要将回款拆分到对应的账单或者开票，如此来让账单、开票、回款三三者之间关联起来，最理想的数据情况则为，此账单已开票已回款。
1）回款拆分到账单
将回款关联拆分到对应的账单，给每个账单分配回款金额，直到该笔款的回款金额分配完。
2）回款拆分到开票
如果先对账单进行了开票，客户的回款对应某张开票，则此时通过将回款关联拆分到开票是最方便的，直接为开票分配回款金额即可；但是这里需要注意到回款虽然是表面上拆分给了开票，如果该张票当时是开到了账单上时，则在回款拆分到开票时，系统需要同时将回款金额分配该张票底层的账单上，这样才能保证账、票、款一致。
3）回款拆分到预付
针对客户先打款后产生账单的业务类型，系统支持提前将回款的拆分到预付回款下，在拆分时不需要关联账单和开票，只需要确认好每条业务线需要分配的回款金额。
上图为笔者绘制的一份简单的功能架构图，基本包含了目前账务系统核心的业务功能，可以将该图与流程图结合起来理解。
1）账务系统中的必然会出现大量的数字，是实打实跟数字打交道的系统，在最初设计时一定要考虑清楚数值的类型，是采用double类型、float类型还是别的类型，最终的目的是保证系统在数值的精确度上是始终保持一致的，在这件事上我和我的团队是吃过亏的。
2）账务系统的各个模块的数据和功能的串联型与关联度是非常高的，举个例子来说，当你发现某个财务报表的某个字段统计计算有误，很可能是因为最初在账单已经出错，进而导致开票有误、回款有误、关联表有误，最终导致报表有误，因此需要考虑在设计各个模块时耦合度的问题。
3）一般新系统的在上线时，都会需要处理历史数据，账务系统也不例外，尤其是针对各种期初数据的导入和处理是比较多的，而且相关人员在给到我们数据时，往往是无法一次到位的，少不了在后续多次的修改和调整，然后再由我们的研发人员执行sql。
因此针对这类问题，可以考虑增加一些修改期初数据的功能，虽然我之前一直认为这样地低频的导入期初数据的操作不需要做成系统功能，但从实际来看并非完全如此。
本文由@Joysaver🏁 原创发布于人人都是产品经理，未经许可，禁止转载
题图来自 Unsplash, 基于 CC0 协议
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。