【发票进阶】发票系统0-1闭环设计思路

10 评论 5551 浏览 59 收藏 11 分钟

编辑导语:发票是财务中必不可少的物品,那发票系统该如何设计呢?本篇文章中,作者从B端和C端两个层面,介绍了如何从0到1的设计发票系统。感兴趣的小伙伴不妨来看看。

之前也写过发票的设计思路,时隔一段时间重新做了发票的项目,对这部分又有了新的认知和思考,更是发觉之前写的甚浅。

当我带着新的理解进行分享时,我的思路和方法论已悄然发生变化,这篇文章讲一下发票系统0-1的闭环设计,希望能带给你帮助~

一、什么是发票

发票是指一切单位和个人在购销商品、提供或接受服务以及从事其他经营活动中,所开具和收取的业务凭证,是会计核算的原始依据,也是审计机关、税务机关执法检查的重要依据。

发票分为进项发票和销项发票,简单说可以理解为作为一个商家,进项发票就是供应商给我们开的票,销项发票是我们给购买了商品的客户开的票

此次文档范围主要是销项发票~

二、发票系统对接模型

在之前的文章中也提到,B端系统设计之初,需要对系统进行分层,明确系统边界。

这样做的好处是避免后期业务繁杂时各个系统之间功能冗余,逻辑耦合,从而不方便业务拓展。

1. 申请层

申请层主要是指申请开具发票的数据源,如toC:用户端,用户可以自主开具发票。

或者toB 在后台,由客服或者运营为用户申请开票,当发票开具完成后再将发票信息展示出来。

2. 接收层

这里的接收层我把它叫做发票中台,发票中台负责对接所有所有在申请层的系统, 承接所有申请开票的数据,统一由发票中台对接发票服务。

当发票开具完成后再将发票信息传给申请层的系统,有点承上启下的意思。

这样设计的好处有两点:

  1. 对于上游申请层来说,不需要单独对接一次外部的发票服务,对接发票中台远比对接外部的发票服务成本低;
  2. 对于发票中台来说,所有申请的数据都天然维护在这里,方便做前期的校验、后续统计等功能。

3. 服务层

这里的服务层是指外部的开票服务,发票中台将所需要的开票信息透传给开票服务。

由开票服务完成开票、红冲等操作,再将结果返回给发票中台。

三、对接层

1. 申请层

(1)C端

申请层主要的功能就是「申请开票」。

那么对于C端来说,它面向的对象就是用户,那么在C端的设计上就要站在用户的角度,这里简单列下主要功能点:

① 申请节点

前文我们说过,发票是指一切单位和个人在购销商品、提供或接受服务以及从事其他经营活动中,所开具和收取的业务凭证。

那么开票的前提是有了交易记录,开票可以根据流水开,也可以根据订单开,下面就按照普遍电商平台的做法,按照订单来说明。

申请开票的节点其实没有明确的要求,目前业内有的是支付后可以申请,有的是还是收货后才可以申请,区别主要是担心产生售后行为后,发票还需要红冲掉,浪费额外的票量。

但像京东现在已经很智能化了,每次支付完会自动开票。

② 申请类型

对于大多数市面的产品来说,一般在C端只允许用户开电子票,原因很简单,电子票和纸质票的法律效应是一致的。

但是电子票比纸质票成本低、效率高,开票所需要的信息也比纸质票简单许多。

当然如果用户有指定开专票或者纸质的普票的话,作为商家还是有义务为用户开票的,对于这种情况可以走线下联系客服等方式在后台申请开票。

③ 申请信息

不同类型的票需要的信息是不一样的,同样纸票和普票所需要的信息也不相同;

这里其实分为几部分,用户的个人申请信息和发票信息,其中个人申请信息是用户自己需要提供的信息,发票信息都是开发票需要。

但是由系统自主可以通过订单获取到的。

下图我简单列了下基本信息,有的字段对于不同的发票类型、发票种类都有不一样的输入要求。

  • 查看开票进度:用户申请开票后,发票的状态要讲对应展示文案告知用户开票进度,给用户有一个预期
  • 查看发票、下载发票、发送邮箱:开票后用户可以下载发票或者选择将发票发送到指定邮箱

(2)B端后台

  • 申请节点:同用户端,前后台保持一致
  • 申请类型:在后台申请的话,那么他可申请的范围包括普票、专票、包括电子票和纸质票。
  • 查看开票进度:后台也需要展示开票进度,这样用户咨询客服或者运营时,内部人员也可以给出反馈
  • 查看发票、下载发票、发送邮箱:根据使用的群体,来设计系统需要支持哪些权限范围的功能,比如用户是可以下载发票的,但是考虑到数据风险,客服是不可以下载的等等

2. 接收层

我们这里可以理解为一个发票中台台系统,用来存储所有申请开票的申请单。

从对接模型上说,这是一个接收层,当然从功能上来说,也可以在这个后台申请发票。

后台系统最基础的增删改查功能这里不多赘述,之前写的一篇已经写过了。

这里其实还想说一个更重要的点,是单据之间的关系以及单据的状态机。

下面用一个ER图可以看一下订单、发票、申请单映射关系

  1. 订单和申请单是1对N的,因为会存在部分退款后,用户需要对余额重新申请开票的场景,理论上用户申请开票只有金额限制,不应该有次数限制,只要可开票金额大于0且小于等于实付金额,就是可以开票的。
  2. 订单和发票的关系是1对N的,出现这种情况可能是因为一笔订单中包含不同的税目的商品,内部的额外需求,需要将这类发票拆开,或者是因为开票金额超过限额,会拆分开成几张票。目前限额最大值有1万、10万、100万,一般是由公司和税务局核定后,设置在系统里的。

从创建申请单,到这笔申请单的状态流转为终态,这其中不同状态机下对应的是不同的操作功能映射。

如常见的几个状态机:『待审核』『审核中』『待开票』『开票中』『已开票』『已红冲』。(目前绝大多数电子票都是不需要审核直接开票的,纸质票大多数还是需要审核的)

不同状态下C端的展示逻辑、后台的功能都不同,举个例子用户提交开票信息后,不管申请单数据状态是审核中还是开票中,对用户而言都包装成『开票中』;

例如『待审核』状态下可以『审核驳回』或『审核通过』『已开票』状态下可以下载、查看发票,这都是要基于状态机的变化来的。

3. 外部开票服务

外部开票服务其实就是目前做的很成熟一些税控服务,如某税,发票中台通过对接这样的服务来实现开票、红冲等需求,主要工作量在于两边的接口对接。

蓝票如上所述一般是用户/客服/运营主动申请的,但是红票最好是可以系统自动判断订单的状态,进行红冲。

四、其他

一般比较完善的发票中台,会将票仓管理、主体管理、税目信息管理、票额管理等信息都在线上维护起来。

线上化程度越高,对于业务来说效率就越高,但这个并不影响开票的主流程。

各家公司会根据自己的量级来评估线上化的程度,按自身业务实际情况选择。

 

本文由 @闫秀儿 原创发布于人人都是产品经理,未经作者许可,禁止转载。

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

给作者打赏,鼓励TA抓紧创作!
更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 大佬如何处理,在b端场景下,用户应开而未开发票的问题

    来自北京 回复
  2. 会有多个订单对应1张发票的情况吗?如果开在一张票上,后面全退了一个订单1,再开票会不会有订单1和发票详情对不上吧?

    回复
    1. 订单与发票存在1:N的场景,文中所描述的模型有缺失,订单可能会被拆成不同的商品(即货物)类型,商品与发票有对应的关系,不同平台的建设是不一样的。若不同商品开在不同的发票上,或者不同的商品运营主体不同,例如美团外卖,快递费是美团平台运营的、餐费是商家运营的,按照谁收费谁开票(真正的资金流向)的原则,必然是在不同的发票上。

      来自上海 回复
    2. 1、开票时需要记录订单与商品的关系、还需要记录商品与发票的关系,否则会出现基于某张发票冲红找不到对应的订单,也不知道需要冲减订单的哪一部分。
      2、实际运营中存在另一种订单部分开票场景,例1中,用户实付金额5W元,但是用户只想开具5W元的3W元;
      3.合并订单开票,高频低额的订单,需要将所有订单合并开具。

      订单实际与发票是多对多的关系,但订单与发票不应该是直接关系上的。

      目前互联网产品淘宝、京东、美团外卖基本是基于单订单开具;美团零售(自营)、饿了么餐饮和零售、滴滴出行是基于多订单合并开票的

      来自上海 回复
  3. 大佬,咨询个问题,我们做的是电商的产品,在商品中心上架的商品,与进货的商品如何做关联,进货商品的发票属性/规格/数量这些信息维护在哪块是进销存系统吗还是商品系统

    来自北京 回复
    1. 我也想知道

      来自湖南 回复
    2. 其实都可以,采购时其实对商品的属性已知,该批次比如商品的税率、货物品名、规格都是已知的。商品发布时,商品详情中也有对应的信息。不过开票是基于合同(订单、合同、账单)维度开具,而订单的商品详情必然有相关属性,维护在商品侧更好。

      来自上海 回复
  4. 你好,想请问一下:
    “对于上游申请层来说,不需要单独对接一次外部的发票服务,对接发票中台远比对接外部的发票服务成本低;”
    有个疑问:我自己的理解,对于上游申请层来说,即使对接了发票中台,发票中台最终也是要对接外部底层发票服务商的,那么上游申请层对接发票中台的优势为什么是比直接对接外部底层发票服务商更低呢?

    来自上海 回复
    1. 哦哦,突然理解了,因为会涉及到多个上游申请层对接,而发票中台只需要对接一次外部底层发票服务商,应该是这个答案吧哈哈😂

      来自上海 回复
    2. 是的!

      来自北京 回复