20201017-应收应付系统

2020年10月份开始，支付产品技术分享活动又重新启动了，每周安排2-3次分享活动， 采用文档+音视频的方式，让分享嘉宾和听众的互动更有效率。 目前支付产品技术群（微信群和飞书群）有名额可以加入。 入群条件为在群里做一次分享。 在本文下留言 可以分享的主题以及预计分享时间，群主将邀请入群。 名额有限，先到先得。

需求背景

所在公司是内容行业，之前公司是在本司app端售卖内容（站内售卖），公司的收入及分成计算较为简单，售卖即收款，上游内容供应商分成就可以根据合同设置的分成比例计算处理；

后期公司引入多渠道售卖的业务，有些业务是渠道收款，再给我司分成，存在回款周期过长的情况，因公司要求渠道售卖回款后才给供应商分成，因此在未搭建应收应付系统时，公司要3-6个月才给上游供应商结算，且暂估分成也没办法给上游供应商展示，对公司与供应商的合作关系造成了很大影响；基于此搭建了应收应付系统，管理应收应付款项，并确保上游分成计算的准确和及时性；

需求目标

1. 业务最终目标为保持供应商商家管理后台数据展示透明化，暂估分成及应付实际分成计算的准确性；

2. 针对业财数据实现贯通，保证数据信息流的清晰可追溯；

整体思路

以订单id为唯一标识，串联全链路数据，以订单明细-应收单-形式发票-收款单作为应收管理系统的主线，订单主要管理外部系统对接的订单，根据渠道合同的分成模式，系统自动由订单生成应收单，展示交易金额、应收金额、手续费等数据，业务人员根据应收单下推生成形式发票（该形式发票不是真正意义上的发票，起的主要作用为业务选择应收单生成一个周期一个客户的结算单），然后财务根据收款情况，将形式发票生成收款单；

应付单也是以交易id为主键，可以计算每一笔订单的应收金额、手续费、应付金额、根据采购合同关联到每一个供应商，根据收款情况，可以记载每一笔订单的实收金额，同时可以计算出实付金额；这张单据相当于一个应收应付汇总总表；

流程图

应收应付流程图

相关概念及字段介绍

1. 订单明细：订单明细作为后续单据的源数据基础。

1. 订单明细支持运营进行操作配置处理，月初由运营统一操作订单明细（如有禁用、作废等），然后结算系统每天集中跑数据；

2. 禁用为不需要生成后面的财务数据的，作废为隔月做红冲数据用。

3. 包含字段：交易id、客户id 、平台来源、订单时间、系统时间（实际操作时间、第三方订单号、商品名称、商品ID、成交价格 、支付渠道、支付渠道费用、分成费用 、我司分成 。

2. 应收单：

1. 包含字段：交易id、销售客户id、商品id、商品名称、交易金额、应收金额、实收金额（核销金额）、未核销金额、创建人、导入人 ；

2. 应收单暂估根据订单明细实时生成；

3. 应收金额：以交易明细表为基础，系统根据交易金额及分成比例计算出的结果；

3. 形式发票：非实际开票样式，为录入系统单据。

1. 用于核对某一客户某一月份结算金额的结算单根据应收单生成形式发票（勾选开票）；

2. 字段：发票号码，发票日期，结算日期（根据所勾选的日期），销售客户，发票金额，实收金额、未收金额、创建人：新建人；

4. 收款单：

1. 包含字段：收款日期、客户名称、结算实收金额，发票号码、 创建人：导入人；