惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

博客园 - 聂微东
MyScale Blog
MyScale Blog
The GitHub Blog
The GitHub Blog
C
Check Point Blog
M
MIT News - Artificial intelligence
U
Unit 42
freeCodeCamp Programming Tutorials: Python, JavaScript, Git & More
H
Help Net Security
OSCHINA 社区最新新闻
OSCHINA 社区最新新闻
D
DataBreaches.Net
大猫的无限游戏
大猫的无限游戏
D
Docker
Last Week in AI
Last Week in AI
IT之家
IT之家
F
Fortinet All Blogs
A
About on SuperTechFans
P
Proofpoint News Feed
The Cloudflare Blog
酷 壳 – CoolShell
酷 壳 – CoolShell
B
Blog RSS Feed
博客园_首页
月光博客
月光博客
博客园 - 司徒正美
Y
Y Combinator Blog

人人都是产品经理

为什么你的产品找不到差异化?90%的失败都卡在第一步上(下) – 人人都是产品经理, 3年从30万到1300万用户、获2200万美元融资,这个AI教育产品用“抽卡”破解了获客难题 – 人人都是产品经理, 园区招商系统怎么做才能真正帮到去化?我加了这一个功能,推广链接转发400次阅读过万 – 人人都是产品经理, AI大事件:OpenAI发完网络安全模型又搞药物研发,小鹏汽车要抓”DeepSeek时刻” – 人人都是产品经理, 电商不是卖货,是一场更残酷的产品经理实战 – 人人都是产品经理, 没想到,活动营销又回来了! – 人人都是产品经理, 为何All-in海外KOC:一场关于AI时代窗口期的豪赌 – 人人都是产品经理, 重新理解企业的内部协作 – 人人都是产品经理, 苹果的 AI 战略到底是什么? – 人人都是产品经理, 医疗智能体·第2讲——合规护城河:等保、PIPL与HIPAA的架构实战 – 人人都是产品经理, 向量知识库五步法:从“答非所问”到“精准回复” – 人人都是产品经理, 鸿蒙PC三方库构建总指挥HPKBUILD(sha)库为例 – 人人都是产品经理, 何时该用LLM?AI产品经理的LLM设计指南 – 人人都是产品经理, 医疗信息领域的需求方、决策方、准入方以及关注点(二) – 人人都是产品经理, 即梦涨价:一场被误读的「傲慢」 – 人人都是产品经理, 面试AI PM必答题:Hermes和OpenClaw的区别,如何讲清楚业务价值 – 人人都是产品经理, AI的下一张船票:世界模型——AI产品经理必须理解的技术拐点 – 人人都是产品经理, 小红书做GEO,怎么让AI信你?记住这 3 个重要信息 – 人人都是产品经理, 5 家印度 AI 初创公司,看看印度 AI 再做什么 – 人人都是产品经理, AI项目跨团队协作:产品技术业务如何不打架 – 人人都是产品经理, Agentic Workflow(智能体工作流):让AI从”答案生成器”变成”数字员工” – 人人都是产品经理, lycium_plusplus 项目全景解读:OpenHarmony 三方库构建的“大管家” – 人人都是产品经理, 从爆单救火到前置履约:两套预采策略,把生鲜大促履约效率拉满 – 人人都是产品经理, 什么时候该补货?我用一轮数据做了一个决定 – 人人都是产品经理, 从“机械兜底”到“动态分流”:AI客服重复进线治理的4大底层逻辑 – 人人都是产品经理, 抖音拼效率,红书拼洞察 – 人人都是产品经理, 全民狂欢与退潮——为什么龙虾这波热潮冷却得如此之快? – 人人都是产品经理, Stripe押注!MPP重塑全球支付 – 人人都是产品经理, 小红书GEO:AI引用你的内容,不是因为你对,而是因为你看起来可信 – 人人都是产品经理, 前百度副总裁押注办公Agent,日韩付费爆发,Manus迎来强劲对手 – 人人都是产品经理,
一张图,搞懂“发票系统”
陈天宇宙 · 2023-12-28 · via 人人都是产品经理

很多场景下,都需要开发票。日常的我们所接触都是作为需求方,那作为发票平台方,我们如何实现对用户的开票和发票提供呢?本文将会带您了解“发票系统”,一起看看吧!

很多场景下,我们会要求对方开发票,住酒店时,购买某种服务或者商品时,用于后续的报税或者报销。

这是我们作为发票需求方,而如果我们作为平台方,如何实现对用户的开票和发票提供呢?比如你是一家外卖公司,要给平台商家提供某项费用的增值税发票。

一、先认清要开的“票”

广义上去看,“票”的种类很多,不止是增值税专票或者普票,我们可以将一种“凭证”都可以认为是一种“票”,比如电子回单、消费小票等等。

他们实现的底层逻辑和方法是类似,可以共用一个抽象模型。

在要实现自主开票之前,我们要先确定这是一个什么“票”。

这张票的样子,也就是板式,票上需要展示的数据,这些数据来自哪里,是业务系统里还是从用户那采集得到。

如下图这张增值税普通发票,其中的纳税人识别号就需要从用户那里采集得到,在开通获得发票以后,又可以得到发票代码等数据。

因此,先分析你要实现的发票版式和数据参数,以及数据获取方式。

二、把握发票系统的框架

要实现一个开票系统,怎么做,要先“心中有框架”。

先把大的逻辑和结构搞清楚,再去分块去实现,从宏观到微观的过程,如下图框架。

首先就是“数据准备”。

要明确开的各个票种的源数据是什么,从哪里获取,是账务数据、账单数据、还是税单数据。

并且,该票种所需要的开票数据也不一定从一个地方就能完全获得,可能是一个字段来自一个地方,比如税号来自用户中心,从客户端采集的,而开票金额字段从账务中心获得。

因此,源数据是要“拼出来”。

然后就是开票的模式、发票的模版等基础配置,不同的开票模式流程不同,例如你要开“消费小票”那么就不需要发票服务商,完全可以自主闭环开出来,而要开正规的增值税发票,就需要依赖外部服务商。

所以,发票模式跟支付模式类似,对私和对公有区别,快捷支付和网关支付也有区别。

接下来就是开票主流程,所有票种的开具都可以通过这个流程实现,三大步:开票规则解析、开票数据封装、提交开票申请。

其中提交开票申请,类似提交支付申请,可能不同国家、不同票种要提交给不同的发票服务商。

三、数据、状态、能力、历史

发票系统要重点想明白和管理好4个核心。

发票的数据,就是最原始的发票单据,可能每个商家每个结算周期一条数据,这条数据记录了开什么票、开票金额是多少、商家的税号等信息。

开票的状态,每条数据的开票状态是什么,是待开、开票中、冲销了、还是已开票。

开票的能力,不同的票种或者接的不同服务商所需要的开票能力不同,首次开票、冲销能力、重开能力、下载发票能力、开票调整能力,这些能力的接入和实现依赖实际的需求。

最后就是开票历史,每一章开好的票以某种形式存储在数据库中,方便用户或者后台管理人员查看,pdf形式、xml形式或者是图片形式。

四、选服务商、接所需能力

如果某票种需要接入发票服务商,那么就需选择一个适合自己的服务商,不同国家、不同票种可能适合的服务商不同。

但是,无论什么服务商,其服务接入逻辑是类似的,提供的能力也是类似的。

这一点跟接入支付渠道商差不多。

无论是接入哪家开票服务商,其实现的逻辑都如下图类似,下图以Gosocket为例,而且这家服务商是全球性质的,比如你接入了墨西哥这个国家,那么在另一个国家也有可能不需要重复接入,只需要修改几个传参、语种即可。

整个逻辑流程图里要搞清楚这几个主要问题。

开票的能力,图中包含了“申请开票”“下载发票”“冲销发票”三个主要能力。

然后就是通过开票结果对发票源数据的“开票状态”的更新,开票成功则更新为已开票、开票失败则保持“待开票”的状态,冲销成功以后将“已开票”状态更新为“待开票”。

针对不同的开票状态,可以进行不同的操作,例如自动开票、冲销发票、手动开票等。

然后就是下载获得了发票以后,将发票进行存储,提供给后台和用户查看和下载,或者邮件自动发送给用户。

比如我们在滴滴App内选择“开票”,勾选对应订单以后申请开票,就需要填写一个收票“邮箱”。

该邮箱,就会存储到发票系统的“用户邮箱”中,用于向用户主动发送电子发票。

五、想好怎么给用户

好了,通过上面的努力,我们终于可以实现自动开票了。

最后一步就是想明白你要如何将发票提供给需要的用户。

比较常见的就是发送用户指定的邮箱。

同样,对于商家来说也可以在其后台提供发票自主下载的能力。

以上就是如何实现一个发票管理系统的方法论。

专栏作家

陈天宇宙,微信公众号:陈天宇宙,人人都是产品经理专栏作家。多平台支付领域专栏作者,十年资深产品;专注为10万支付产品经理和支付机构以及企业提供深度支付内容和服务!

本文原创发布于人人都是产品经理,未经许可,禁止转载。

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

该文观点仅代表作者本人,人人都是产品经理平台仅提供信息存储空间服务。