H7.12.1e-invoice vs receipt设计研究
电子发票与普通购买凭证承担不同的法律与报销用途
别名: 电子发票 · 购物小票 · fapiao
概念解释
支付成功页上的订单确认证明「你买了、钱走了」。电子发票是给税务与报销的法定单据，抬头、税号、发票代码与普通购买凭证不是同一份东西。混成一个「凭证」下载，人拿去财务会被退回，或把没有法律效力的成功页截图当发票。这条管两种文书的分工，不管多渠道如何归集，也不管确认页当下有没有取消按钮。
机制
购买凭证服务核对与售后：订单号、SKU、实付。发票服务合规：购方名称、税号、税率、开票方章。人在下单时常还不知道报销抬头，或个人买却要公司票，所以发票往往后开。若界面只用「下载凭证」一个动作，两种需求打架：财务要 PDF 发票，客服要对订单号。状态也不同：订单已付不等于已开票，已开票不等于能作废重开。不把状态拆开，人会在未开票时反复点下载，或把订单详情打印当发票寄出。
怎么研究
给需要报销的人完成一单，比较：只有成功页、成功页+订单 PDF、独立的开票入口与状态。看他们交给「财务」的那份是什么。
自变量：发票入口是否与订单确认分开、是否收集抬头、开票状态是否可见。 因变量：提交给报销的文件类型、因票据不符被拒、开票前的重复申请。
实验室里没有真财务，要用角色扮演或真实报销规则清单做验收。不同司法辖区的发票制度差很大，测的是「界面是否让人拿对文书」，不是某一国税制。
边界
不开发票的市场（只出卡账单）不要做出发票流程，避免假承诺。数字内容、跨境小额可能无法开当地发票，要在买前说清。一张订单开多张发票、或多单合并开一张，是开票规则，界面要按规则选，不能默认「一单一票」却在提交后失败。
怎么落地
- 订单详情同时列出「购买凭证」与「发票」两个对象，各自状态（未开 / 开票中 / 已开）。
- 开票收集抬头与税号，预览将开的票面，再提交；下载的文件名与票面类型一致。
- 未开票时不要把订单 PDF 标成发票。
- 验证：让人走完一单并「交给财务报销」，看交出的是发票还是成功页截图。再问订单号在哪查售后。两份需求抢同一按钮，分工失败。