B端采购发票产品复盘

我们构建了一个线上门店采购平台，支持我们下属的修车厂（简称门店）在平台采购汽修用品。
按照规定，我们公司有责任为门店开具进项税发票。
在本项目未上线前，我们开拓票的模式是线上申请发票+线下人工开具，人工开具的事情是由我们请的开票外包卖力，他们是按照开票张数进行收费。

加之现在国家在大力推进全面数字化的电子发票（简称数电发票），数电发票在安全性上较之前的发票有显著提升。
因此，我们决定对发票系统进行升级，在线上申请的根本上支持线上开票，方便门店即时提交，即时开具，减少门店等待发票韶光，同时也减少了我们外包用度。

一、总体流程1. 开票前的数据准备

1）商品的税务信息：由总部的业务同学掩护好sku的类目或详细sku 的税收分类编码、税率。
开票时，系统根据商品的skuid读取对应的税务信息。

2）门店的发票举头：发票举头不支持门店随意修正，而是根据门店与我司签署的【采购条约】的签约主体，由总部业务掩护在系统上，在申请开票时，门店可以看到该信息，但是不支持修正。

3）订单购方信息和销方信息固化：由于门店如果变了老板，换了公司名称，是须要变更采购业务执照，他须要与我们重新签署采购条约。
因此这家门店的购方信息是哪个，是存在由于韶光段的不同而变革的情形，因此须要订单下单时，将此部分数据固化下来。

2. 门店开票申请

1）勾选多个订单进行开票：与C端消费不同，B端消费一样平常是月尾批量申请发票，一次性报税，且报税的时候须要录入每张发票信息。
因此如果仅支持单个单个订单申请发票，那会增加门店的申请发票的操作本钱，也会增加门店财务进行报税时登记发票信息的操作本钱。
因此，本项目是支持门店勾选多个订单，一次提交开具一张发票。

3. 开票后续处理

C端消费常常会涌现冲动消费，买后再退的场景。
但是，B端采购一样平常都是有操持性有目的性，纵然售后也一样平常是换货为主，因此涉及到退货要开红冲发票的场景较少。
因此，本期暂时不支持线上调接口红冲，等后续评估红冲场景多少，再决定是否支持该功能。
由于本期，我们在售后的时候会提示门店和总部职员，必须要开具好对应的红冲发票后，才支持线上申请售后。

门店开拓票的业务流程

二、功能先容1. 商品税务信息配置

税务信息配置时，我们是支持按照类目配置和按照sku配置。
他们的利用场景如下：

其余，运费的税率一样平常比较固定，因此我们不支持前台配置的，是直接写到后台代码里面。

1）按照类目配置

紧张功能点：

如果要删除某个类目的税务信息，那一定要担保目前【该类目在系统处于作废状态】（类目作废的条件校验：没有sku是归属该类目）

2）按照sku配置

紧张功能点

前台没有供应页面，也是直接写在后台里面，包括公司名称、公司地址、开户行、对应银行账号、统一社会信用代码、开票人、收款人、复核人

3. 购方发票举头掩护

1）发票举头应取实际采购人信息

为确保交易的合法性和合规性，任何情形购方的发票举头都应与实际的采购方保持同等。
因此，本期涉及时，不支持购方自主填写发票举头，而是系统取值，然后购方核对信息精确性，如无误，则申请开票。

那谁是B端采购的实际人？一样平常可以从如下几方面判断：

（1）基于交易关系的判断

（2）结合其他信息综合判断

如果发生了实际支付和采购条约不一致的情形，虽然支付货款的公司可能与甲方不同，但货款支付行为本身也是判断实际采购方的一个主要依据。
如果支付货款的公司是根据甲方的指示或委托进行支付，那么甲方仍旧是实际采购方。

2) 本项目以订单存储的采购条约签约主体作为实际采购人

因此，本项目我们的做法是每笔订单下单成功后，自动存储采购主体信息，此信息取系统下单时候每家门店与我司签署的采购条约的签约主体。

之以是，要订单不才单时候存储条约的签约主体，而不是申请发票的时候去读取。
是由于，采购条约可能会发生变更，因此申请发票时候去读取就无法担保此刻的信息是那笔订单交易发生时实际的采购人。

其余，这也对业务提出了一定的哀求，如果采购条约发生变更，要及时更新系统的信息。
比较空想的方案，是运营教练提交申请变更采购条约流程，干系审批结束之后，在线签署条约，条约签署之后自动更新系统数据。

3）功能上线前的订单别忘了刷【采购主体】数据

上线之后，订单下单成功实时读取系统数据，但是上线前的订单也须要记录该数据，空想的情形是业务奉告每家门店在哪段韶光对应哪个采购主体，然后按照韶光段不同期间的订单取不同期间的采购主体。
但是业务反馈，这个数据之前他们都没有记录，系统的采购业务执照变更流程里面也没有记录准确的韶光点，他们比较难供应这份数据。
其余，如果采购条约变更，大概率也不会再申请老主体的发票，而且门店也不是针对每笔订单都申请发票。
末了运用的方案是，减少业务的事情+赌门店不去申请老主体的订单，业务供应最新的采购条约的签约主体信息和该条约的开始生效韶光，则此韶光之后的订单刷最新数据，此韶光之前的订单不支持线下开票。

4. 门店申请发票

1）B端申请发票的操作习气

C端消费者申请发票，一样平常都是在订单详情页针对某个订单进行申请，但是B端申请发票的操作习气与之大不同。
由于B端申请发票紧张有如下操作习气：

2）功能先容

2.1 勾选多个订单申请开票

对付可以申请发票的订单，我们支持勾选，会在订单上展示可开票金额，即可开票金额=实付金额-售后完成的金额，对付售后中的订单我们是不支持申请发票，因此售后中的金额未参与可开票金额校验。

但是，部分订单我们是不支持开票的如：

a.未完成订单；

b.“订单完成”超365天；

c.额度付款未全额支付的订单；

d.退货退款中的订单；

e.已全部退款的订单；

f.订单实付金额=0；

g.已成功提交发票申请的订单;

针对【额度付款未全额支付的订单】这条，我先容一下，这是由于我们商城支持门店用额度支付，即我方财务评估门店的交易流水，付与门店每个月可以利用的额度，门店就可以不该用现款而是利用额度进行付款，等下一个月再用现款偿还额度。
由于，如果这笔订单你利用了额度但是没有进行还款，那这个货的货权还不算真正到门店，由于门店无法申请开票。

2.2 点击【去申请】提交发票申请

点击【去申请】按钮，进入发票申请页面。
但是部分场景会提示缺点

2.3 填写发票申请信息，点击【提交】申请开票

一样平常情形下多个订单会合并成一张发票申请单。
但是知足如下任一条件，会拆分为多张申请单：1）成品油和非成品油；2）不同的销方主体；3）不同的购方主体。

申请单页面支持用户选择开票类型、填写收票邮箱，其他内容为系统自动带出。

点击【提交】按钮，部分场景会进行报错

哪些场景会自动开票失落败

2.4 符合开票条件的申请单，系统会将多个商品明细行合并成一行，目前的合并规则如下

发票明细行合并规则

5. 发票详情查看

提交成功的发票，门店可在开票历史中查看开票进度、预览和下载发票。

总部可以在后台查看申请单，对付非常的开票申请，可改动问题后点击【重试】按钮，重新调三方接口开票。

6. 订单详情里面可以查看对应的发票

门店侧和总部侧，可以基于订单详情页展示实际开出的发票信息

7. 成功提交发票申请的订单，要先红冲，才能支持售后

由于本期我们没有做红冲流程，因此我们是在门店侧和总部侧申请售后的按钮处，判断该订单是否已成功提交发票申请，如提交则进行提示。

tips：如果实际已经开出发票，一定要透出发票号码，由于后续的红冲处理须要拿着原发票号进行操作

门店侧申请售后按钮交互流程

8. 线下发票回传系统

虽然本期实现了线上直接开具发票的功能，但是为了应对非常场景，如系统非常无法开票但是门店焦急要票、门店的发票举头非系统指定举头且有干系材料佐证但系统无法及时调度数据，因此都须要支持线下开拓票功能。
但是为了防止多开拓票，须要线下开过发票的订单线上就不支持申请发票，因此系统须要支持将线下开过的发票回传系统。

在之前的总部侧的发票申请单列表透出【线下发票上传】按钮，点击该按钮，支持将线下发票的信息回填系统。
并支持查看导入记录。

1）导入模板

线下开拓票的时候，一样平常也是多个订单开在一张发票上。
我们之前纠结过线下的发票是否要支持线上红冲，如果要支持线上红冲的话，由于如果要支持部分红冲，就要支持某个订单的某个商品对应蓝字发票的某一行，但是这对付业务哀求过于严格。
因此，后来与业务协商，线上发票导入系统之后，不支持后续的红冲操作，因此我们的业务是与门店协商，在售后结束之后才给门店进行线下发票开具。

财务会关注每个订单开了多少发票，因此我们在线下发票上传时也会哀求填写每个订单对该当发票的开票金额，方便后期财务统计。

2）导入之后，系统支持查看导入记录

3）线下发票回传系统后，系统的相应处理

本文由@lemonsoso 原创发布于大家都是产品经理，未经容许，禁止转载。

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

该文不雅观点仅代表作者本人，大家都是产品经理平台仅供应信息存储空间做事。