B端采购发票产品复盘（汽车后市场）

做汽车后市场的B端产品，比其他类型的B端产品要复杂得多。一是流程比较长，涉及到供应商、用户等，二是管理难度大，SKU多，发票等处理还需要考虑合规等问题。这篇文章，我们来看看作者总结复盘的发票产品的设计复盘，供大家参考。

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

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

一、总体流程

1. 开票前的数据准备

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

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

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

2. 门店开票申请

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

3. 开票后续处理

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

门店开发票的业务流程

二、功能介绍

1. 商品税务信息配置

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

1. 按类目配置：如果一家企业设置类目和将sku放置在合适的类目下，这个操作比较规范的话，一般同一个类目下的商品的税务信息相同，那业务就按照类目配置税务信息即可；
2. 按照sku配置：如果同一个类目下，个别商品的税务信息与其他商品的税务信息不同，那业务可以单独为该sku设置税务信息，那系统如果发现该sku存在“sku维度的税务信息”，那优先取该sku该维度的税务信息。

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

1）按照类目配置

主要功能点：

• 类目税务信息搜索
• 批量配置类目税率（excel导入）
• 单个类目税率、税收分类编码配置
• 单个类目税务信息删除

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

• 税率信息导出

2）按照sku配置

主要功能点

• sku税务信息搜索
• 批量配置sku税率（excel导入）
• 单个sku税率配置、删除
• 税率信息导出

2. 公司税务信息维护

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

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）线下发票回传系统后，系统的相应处理

• 对应订单不允许线上申请发票
• 对应订单不允许线上申请售后
• 门店侧、总部侧均无法看到对应的申请单和发票信息
• 上述发票不支持线上红冲