一 序
发票一直以来是都是跟以票控税相关的，没有严格的去搜下书面的定义，从百度百科上摘一段：
发票在我国社会经济活动中具有极其重要的意义和作用。
1.发票具有合法性、真实性、统一性、及时性等特征，是最基本的会计原始凭证之一；
2.发票是记录经济活动内容的载体，是财务管理的重要工具；
3.发票是税务机关控制税源，征收税款的重要依据；
4.发票是国家监督经济活动，维护经济秩序，保护国家财产安全的重要手段。
其实跟企业相关的就是发票主要是公司做账的依据，同时也是缴税的费用凭证；而对于员工来讲，发票主要是用来报销的。
这里补充一个点：普通发票或者增值税电子普通发票，目前的增值税专用发票不可以开电子发票。
主要涉及的业务方：
通常平台型公司介入的方式是税控服务器（开票速度快单台每分钟W级），需要对接三方平台（国内基本上就是航天信息股份有限公司、百望云等也算是个半垄断性质的吧），有他们负责跟国家税务系统对接。当然开票数据很少的可以用税控盘的方式开具。
业务类型：
正数发票（俗称蓝票）、退款的负数发票（俗称红票），过程称为冲红。
二 需求分析
1 、税务同学按照规定，去联系三方平台提交资料，去税务局申请对应的税控盘，买发票等。
2. 技术对接三方，收集接口文档，确定对外的调用流程及参数。考虑内部系统的实现。
纳税人提前在税务同学完成上述操作后，在三方税控服务器插入税控盘，完成身份认证及识别。按照约定参数提交电子发票申请，电子发票元数据传递给第三方电子发票服务平台，平台接收到数据后进行发票的开具操作，开具完成后，将数据传送到税务局，平台按照电子发票试点现有机制和要求生成带纳税人签章的电子发票及其图像文件pdf，并返给纳税人.。
注意实际开发中上述过程是异步的。这里不去考虑安全信息，默认三方的加密复合要求。
三 系统设计
为了梳理清楚系统的边界，为以后的升级扩容打好基础。这里简单划分为两个系统：订单子系统开票管理（负责业务订单管理，包含但不限于开票金额、开票订单状态等）、开票原子系统（提供底层的原子服务，负责与三方系统交互，不参与具体订单逻辑）。
开票子系统：
关键点：
1 抽象出公共能力，作为底层的原子服务，可以对接上层各个不同的业务线的开票需求.
2 。 自身服务的稳定性，调用三方可能失败。具体的一次申请有分为两步，生成发票号码跟电子发票文件pdf的生成。可能需要重试机制如补偿job.
3. 接口的幂等性。
4. 冲红逻辑相对复杂，先冲红重开，再计算新金额的开新蓝票。考虑到不同的case：
- a\金额不变发票信息有误，有买方名称或者买方纳税人识别号错误原金额重开.
- b\ 金额变化一次。
- c\有多笔原始订单汇总在一笔开票，其中多笔订单发送退款（即一笔开票记录需要支持反复多次冲红重开）。
参数还是挺多的，几十个，没有标准的SDK向芝麻信用那种开放出来。所以调试过程挺麻烦的。而且这种跨公司的联调效率不高，出问题了响应慢。
最后附一张滴滴的电子发票，税点真低啊，滴滴抽成那么高25%，税点这么低3个点，即是现在调整税率了：中国 4 月 1 日开始适用新增值税税率。其中制造业等行业增值税税率将从 16% 降至 13%，交通运输和建筑等行业增值税税率将由 10% 降至 9%，传媒、商贸、休闲服务继续适用 6% 税率，但增加抵扣税额额项目，目标使所有行业税负只减不增。
