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

推荐订阅源

WordPress大学
WordPress大学
A
About on SuperTechFans
小众软件
小众软件
Hugging Face - Blog
Hugging Face - Blog
奇客Solidot–传递最新科技情报
奇客Solidot–传递最新科技情报
博客园 - 叶小钗
博客园 - 聂微东
博客园 - Franky
Apple Machine Learning Research
Apple Machine Learning Research
罗磊的独立博客
量子位
博客园 - 三生石上(FineUI控件)
Recent Announcements
Recent Announcements
The GitHub Blog
The GitHub Blog
B
Blog RSS Feed
T
The Blog of Author Tim Ferriss
GbyAI
GbyAI
云风的 BLOG
云风的 BLOG
Last Week in AI
Last Week in AI
宝玉的分享
宝玉的分享
B
Blog
钛媒体:引领未来商业与生活新知
钛媒体:引领未来商业与生活新知
Stack Overflow Blog
Stack Overflow Blog
Cyber Security Advisories - MS-ISAC
Cyber Security Advisories - MS-ISAC

人人都是产品经理

为什么你的产品找不到差异化?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-27 · via 人人都是产品经理

在平台向商家结算的业务中,有三个重要的产出物,本文主要说明的就是他们合并的原因、合并方法,以及合并关系的逻辑实现,希望对你有所启发。

在平台向商家结算的业务中,最终会有三个非常重要的产出物——账单、付款、发票。

商家需要知道一个结算周期内,自己的账单、付款、发票,三者有着紧密的联系,商家对账也是要核对清楚“账、款、票”的一致性。

账单、付款与发票

一、账单、付款、发票

账单就是提供给商家的本结算周期的交易记录,买了多少货、收了多少钱、退了多少款,以及平台抽了多少佣金,代扣代缴了多少税,本期应结多少钱等等。

账单、付款与发票

付款就是根据账单结算的最终资金,把钱打到商家签约的结算银行账户中,商家就会拿着自己的账单来核对自己的收款,账单里告知商家要结算20万,那就应该收到20万的付款。

账单、付款与发票

然后就是发票,这里的发票可以是广义的票据,比如消费的小票、增值税发票等,所以不同的款项可能要开不同的发票,不同的对象可能要开的发票也不同,而不同的国家需要的发票种类也不同,这要看这个国家此类活动需要什么税种。

税种也不是一成不变的,如下图就是在某国根据其法律要求进行的按期税改,从图中可以看出开票跟账是分不开的,同时开票跟付款也分不开。


开票就需要接外部的开票渠道,这个在不同国家也有不同的服务商,按其标准去接入即可,如智利、墨西哥等可以接入gosoket、vender等发票服务商。

账单、付款与发票

其中有一个特别的税,就是增值税,平台收了商家的佣金,佣金是平台的收入,所以这部分是需要平台缴纳增值税vat,但是这部分平台可以转嫁给商家,这时候就需要帮助商家代扣代缴,并且帮助其开vat增值税发票。

账单、付款与发票

二、有拆有合,需求多样化

上面介绍的是一条结算产出物的主线“账单、付款、发票。

那么拆开看,账单、付款、发票还有更精细的属性,比如一个独立的小店铺和一个全国数千家连锁的麦当劳对“账单、付款、发票”的模式诉求大为不同。

也就是普通商家和连锁商家有不同的需求,所以我们将商家分成三个等级“KA、CKA、普通商家”。

KA就是大型连锁商家,无论是连锁酒店、连锁超市、还是连锁餐饮,普通商家就是一个独立的小商家,就一个门店;而cka就是介于二者之间,例如有十几个门店,但并非大型连锁。

还有品牌一说,一个KA下可能有多个品牌,一个品牌也可可能有多个连锁业务等等,有很复杂的关系。

同样,还有法人主体一说,有的多门店共用一个法人主体,有的每个门店是一个单独的法人主体,那么这样的话,就有了更复杂的组织关系,也会造成结算关系的复杂,对平台来说,账单生成、付款处理、发票开具的模式就复杂了。

比如,对于大型连锁来说,就存在总部和门店的关系,比如有的KA要合并付款到总部,总部统一收款,那么账单、发票要进行合并,但是每个门店又要统计自己的经营,所以每个门店又要单独的账单信息;而有的KA可能需要单独付款给每个实际经营的门店,但是要给总部合并账单。

账单、付款与发票

三、简历关系,灵活合并

上述的账单生成,结算付款,发票开具都有独立完整的主模块。

而如何生成账单、如何进行付款、如何开具发票,就需要考虑是不是需要合并,合并那一块业务。

此时就需要一套规则的配置,来促成这一“是合是分”的实现。

其实在合并上有很多合并逻辑,主要是要抽象出“合并维度”,我能实现以谁为合并维度,或者按照法律法规我必须以谁为维度,或者按照法律法规我不能突破什么维度而合并,例如我能不能突破法人主体而合并付款给总集团?这些都需要财税法团队的支持以满足当地的法律法规和商户的诉求。

假如,我们合并的上限是法人主体,只能针对同一法人主体下的门店合并其付款和发票,也就是多个门店的营收可以一笔付款,和开一张票;但是账单我可以任意合并出具;当然其他按照品牌合并或者更多维度也可以实现,方式类似。

这样的假设之下就需要构建一个门店合并关系。

我们通过配置化实现这层合并关系,在账单生成、付款单生成、发票数据处理时,调用这个关系,去判断该门店是否在一个合并关系中,该业务是否需要与其他门店进行合并。

账单、付款与发票

这里的合并关系,是建立一个主体下的多个门店之间在“账单、付款、发票”三个业务之间“是否合并”的关系,如下图中的合并关系,仅仅是合并了3家门店的付款,而发票和账单并没有合并关系所以还是按单门店执行。

账单、付款与发票

那么为什么会存在一个法人主体下仅部分门店合并了付款呢?这里的合并诉求要看商家具体经营情况,可能是这3家门店是同一个运营团队在运作,而该企业是以运营团队为单位进行核算的。

如下图的配置关系规则,明确了哪些门店进行了合并,在什么场景上合并了,这里的场景主要是3个,就是“账单场景、付款场景、开票场景”。

账单、付款与发票

在新增合并关系时,必须选择一个法人主体,该法人主体下的门店可以自由组合。

账单、付款与发票

这时,一个法人主体下就可以配置多条合并规则,一条合并规则可以约定了这些门店是合并了什么场景。

账单、付款、发票都是独立的业务,他们未来都会有独立的文章单独介绍,各自的详细业务介绍本文就不过多说明了。

本文主要说明的就是他们合并的原因,合并方法,以及合并关系的逻辑实现。

专栏作家

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

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

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

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