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

推荐订阅源

S
Schneier on Security
C
Cyber Attacks, Cyber Crime and Cyber Security
D
Darknet – Hacking Tools, Hacker News & Cyber Security
Project Zero
Project Zero
T
The Exploit Database - CXSecurity.com
G
GRAHAM CLULEY
T
Threatpost
A
Arctic Wolf
cs.CL updates on arXiv.org
cs.CL updates on arXiv.org
Scott Helme
Scott Helme
Simon Willison's Weblog
Simon Willison's Weblog
P
Proofpoint News Feed
C
Cisco Blogs
Threat Intelligence Blog | Flashpoint
Threat Intelligence Blog | Flashpoint
K
Kaspersky official blog
P
Palo Alto Networks Blog
C
CXSECURITY Database RSS Feed - CXSecurity.com
T
Threat Research - Cisco Blogs
The Hacker News
The Hacker News
T
Tor Project blog
NISL@THU
NISL@THU
The GitHub Blog
The GitHub Blog
Security Latest
Security Latest
aimingoo的专栏
aimingoo的专栏
C
CERT Recently Published Vulnerability Notes
Recorded Future
Recorded Future
CTFtime.org: upcoming CTF events
CTFtime.org: upcoming CTF events
Google DeepMind News
Google DeepMind News
Martin Fowler
Martin Fowler
N
News | PayPal Newsroom
P
Privacy & Cybersecurity Law Blog
MyScale Blog
MyScale Blog
G
Google Developers Blog
V
V2EX
V
Visual Studio Blog
P
Privacy International News Feed
Google Online Security Blog
Google Online Security Blog
Microsoft Azure Blog
Microsoft Azure Blog
宝玉的分享
宝玉的分享
博客园 - 【当耐特】
L
LINUX DO - 热门话题
MongoDB | Blog
MongoDB | Blog
腾讯CDC
J
Java Code Geeks
The Last Watchdog
The Last Watchdog
L
Lohrmann on Cybersecurity
Cyberwarzone
Cyberwarzone
博客园 - 聂微东
Webroot Blog
Webroot Blog
S
Secure Thoughts

人人都是产品经理

为什么你的产品找不到差异化?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迎来强劲对手 – 人人都是产品经理, 企事业单位数字化的业务供需本质 – 人人都是产品经理, 医疗智能体·第1讲——医疗信息化重构:从“辅助软件”到“自主智能体”的范式转移 – 人人都是产品经理, 粉丝量就是空气!!! – 人人都是产品经理, 用户说“薯片碎了”,机器回“要买吗?”:意图识别的翻车与破局 – 人人都是产品经理, RAG召回准确率从75到90 我做对了这三件事 – 人人都是产品经理, AI大事件:Anthropic改收费、OpenAI发安全版、手术机器人纳入医保、阿里发布”秒悟” – 人人都是产品经理, Chrome 推出 Skills 新功能,Agent 重塑上网方式 – 人人都是产品经理, GitHub前创始人拿了a16z的1700万美元,做Agent时代的Git – 人人都是产品经理 拷贝或克隆其他 Flutter OH 项目到本地后无法运行 – 人人都是产品经理, 优惠券设计:优惠券创建 – 人人都是产品经理, 不用死磕文档!AI 助手 1 小时搞定飞书 CLI 安装 + 配置 + 知识库 – 人人都是产品经理, 用小龙虾做竞品分析报告:从2天到20分钟,我是怎么做到的 – 人人都是产品经理 用小龙虾做市场分析报告:搞懂这3个公式,市场规模不再靠猜 – 人人都是产品经理, 你早就在做 Harness 工程,只是不知道它叫这个名字 – 人人都是产品经理, Think Long就够?你可能想多了! – 人人都是产品经理, 货代SRM实战:供应商准入怎么做,才能让资源池不是通讯录而是可交付网络? – 人人都是产品经理, 如何做好用户调研?详解基本技巧 – 人人都是产品经理, 木鸟、途家、美团对打,平台春天行动开“卷” – 人人都是产品经理, 入职才发现公司不靠谱?小红书从业者求职避坑指南 – 人人都是产品经理, 美国 AI 三巨头联手封堵,中国 AI 突围之路在何方 – 人人都是产品经理, 小红书,放在需求对面的镜子 – 人人都是产品经理, AI 会带来大规模失业吗? – 人人都是产品经理, 从出单到补货前,我第一次犹豫:该不该放大? – 人人都是产品经理, Flutter 三方库鸿蒙化适配:5 种高效检查方式,快速判断是否需要适配 – 人人都是产品经理, 从做产品进阶拿结果:医美机构产品经理转岗科室运营经理 – 人人都是产品经理, 阿里HappyHorse,一场关于“Token经济”的阳谋 – 人人都是产品经理, To B AI:客户留存落地的观察与思考 – 人人都是产品经理, AI产品的“生命线”——数据采集、标注、清洗的产品化设计 – 人人都是产品经理, 谈谈AI Agent(二):当“孩子”能自己“体验世界”时,你该学什么? – 人人都是产品经理, UI/UX设计师的3层能力进阶,前两层让你活下来,第三层…才是真正的分水岭 – 人人都是产品经理, 2分钟 → 30秒,效率提升75%:B端产品经理如何用「规则枷锁」驯服AI幻觉? – 人人都是产品经理, 还没来得及学OpenClaw,来了个更猛的:Hermes Agent – 人人都是产品经理, AI日报:宇树机器人跑出10m/s刷新世界纪录 – 人人都是产品经理, 一文说透基金互金如何用情绪价值引导用户决策做转化 – 人人都是产品经理, 当浏览器开始替你”看”网页:AI 浏览器正在亲手拆掉它脚下的那张网 – 人人都是产品经理, 0代码,一天时间我Vibe Coding了个网站 – 人人都是产品经理, Hermes 和 OpenClaw 之争,Agent 的能力应该“装上去”还是“长出来”? – 人人都是产品经理 视频生成的“桌子”,字节Seedance 2掀完,阿里快乐马掀 – 人人都是产品经理, 从听不懂到完全信任:我的 Codex 深度产品体验 – 人人都是产品经理, 当虚拟偶像有了北京户口,与真人偶像还有什么区别? – 人人都是产品经理, 会说,远远比会做更重要 —— 对 SBTI 爆火现象的五层观察 – 人人都是产品经理, AI产品经理必看:当“搭环境”比“选模型”更重要,你的认知还在2024年吗? – 人人都是产品经理, 2026年AI产品商业化核心逻辑:从功能demo到规模化营收的3个必破卡点 – 人人都是产品经理, 京东围绕供应链,卷起裤腿下场的那些事儿 – 人人都是产品经理, SBTI一夜刷屏:它赢在了“太会说人话” – 人人都是产品经理, 折扣零售的真相:不是便宜,而是价值感! – 人人都是产品经理, 和甲方吵了一架,最后加钱做了——我学到的ToB产品经理生存法则 – 人人都是产品经理, 和几位小红书操盘手聊了8小时,干货全在这 – 人人都是产品经理, 智谱GLM-5.1登场,开源模型首超Opus4.6!!! – 人人都是产品经理 Anthropic收入凭什么反超OpenAI,终于有人把这事说清楚了 – 人人都是产品经理, 史上最有故事感的技术报告——Claude最强模型Mythos 7个极其精彩的细节 – 人人都是产品经理, 模型不是壁垒,Harness 也不是 – 人人都是产品经理, 抖音本地生活业务思考21 – 人人都是产品经理, Superpowers:145k Star的AI编码框架,到底是什么来头? Superpowers:145k Star的AI编码框架,到底是什么来头? – 人人都是产品经理, OpenAI 的路走错了,Anthropic Harness 解法启示:模型需要实践专科生 – 人人都是产品经理, 画原型图的前一步:设计站点地图 – 人人都是产品经理, 给 DeepSeek 的最后一封催更信 – 人人都是产品经理, 手把手教你用 Claude Code 搭建 AI 营销团队:5 个 Agent、12 项技能,独立完成研究、写作、设计全流程 – 人人都是产品经理, 你以为大模型在学语言?不,它在重新发明语言学 – 人人都是产品经理 所谓Skill,不过是AI时代的工业垃圾 – 人人都是产品经理, 聊一聊内容传播的几个方法 – 人人都是产品经理, 当平台开始吃掉生态:从 OpenClaw 被封杀,读懂 Anthropic 的这盘棋 – 人人都是产品经理, 你装了 10 个 AI 插件,Obsidian 还是一个文件夹 – 人人都是产品经理 关于AI智能体架构演进的系统性思考:从单体试水到多体协同的重构 – 人人都是产品经理, 当“人”变成Skill,我们又该何去何从? – 人人都是产品经理 Mythos 事件:前沿 AI 治理的意外实验 – 人人都是产品经理, 货代CRM:信用与风险管理怎么做,才能把坏账风险拦在放货之前? – 人人都是产品经理, 从HR收集自拍照到员工自助录入——我见证了园区人脸识别从”不可用”到”真好用”的全过程 – 人人都是产品经理 千问闯关AI混沌期:阿里画靶,吴嘉张弓,马云射箭? – 人人都是产品经理,
不同商家的多商品订单,如何进行拆单和费用处理?
Emma · 2022-11-05 · via 人人都是产品经理

处理电商订单时,经常会遇到客户同时购买了不同商家的多种商品,此时,电商平台应该如何进行结算?作者展示了此情况下的不同拆单方式及优点,同时也说明了拆单时不同的费用处理方式。一起来看看吧~

在平台型电商业务中,⽤户会有同时购买多样商品的场景出现,因为可以⼀次性完成支付,⽅便快捷。

以双⼗⼀为例,存在⼤量的跨店优惠商品、限时秒杀、限量销售等各种类型的活动,我们通过购物⻋(购物⻋只是⼀个概念,拼多多⽤【我的收藏】完成这⼀功能)完成同时购买多个商品,⼀次完成结算⽀付,既⽅便快捷,⼜能满⾜快速购买多样商品的需求。

支付完成了,接下来就是订单处理的问题了,如果按照上述情况,假设客户在大促期间同时购买了不同商家的商品,要怎么办呢?

比如说目前有A、B,2个商家,他们分别有a、b、c商品(A商家有a商品,单价50元;B商家有b、c商品,单价均为100元)现在客户购买同时购买3种商品各1件。如果按照同订单处理的话,此时订单上同时存在a、b、c商品,分别归属于A、B商家,订单总金额为250元(50+100+100=250元)。

那么在财务层面,对商家进行结算时,有可能会出现过多冻结影响商家现金流的情况。

电商平台对不同的商家通常是进行独立结算的,一般来说在订单确认收货后便可以进行结算,而在这种场景下,因为不同商家的物流不同,确认收货时间可能不一致,此外不同商品是否会发起退款退货的售后流程可能也不一致,如果进入售后,一般会做冻结,不能进行结算工作。

因此,按照一般规则,2个商家的可结算时间会出现不一致的情况(如果遇到售后流程,则时间差距更长,影响更大),这种情况下如果以订单纬度对2个商家进行统一处理,必然导致某一商家被过多冻结,因为非己原因导致的结算延迟情况,可能造成商家对平台不满的情况,影响商家经营,导致商家投诉量上升。

而平台难以给出合理解释,一来很难向商家解释为什么自己的商品结算时间会受到其他商家的影响。二来,冻结金额增多,会影响商家现金流,对部分商家不公平。

此时,唯⼀能够解决问题的⽅法就是对于多商品订单,且商品分别归属于不同商家的订单进行拆单!

一、拆单方式

依照商家归属不同,对商品进⾏分类,同⼀商家的产品为⼀个订单,保证一个订单上只有一个商家的商品,满⾜独⽴结算场景,解决订单归属问题,如此便能够解决上述在财务结算层面遇到的问题。同时注意需要对因拆单行为引起的订单金额的变化(包括商品金额调整、优惠分摊等)做处理。

(一)拆单节点与表现

按照上述的例子,在商品归属于不同商家的场景下,业内的主流处理方式为将拆单节点放在支付成功之后(比如京东、网易严选等),进入【待发货】状态之前。‍

下单时的表现:同一订单

电商订单拆单场景与拆单⽅式

取消支付后的订单展现:还是保持一个订单的状态

电商订单拆单场景与拆单⽅式

支付后,待发货时:订单已经拆分成多个

电商订单拆单场景与拆单⽅式

这样的做法,好处在于:

  1. 如果客户在【待支付】状态下取消了支付,后续再支付客户也只需要对一个订单进行操作,在这种状态下的客户体验更好,更加符合用户心智。
  2. 同时,在【待支付】状态下,客户天然的会比较关心款项问题,一个订单,便于客户在实际支付前进行核算(特别是在有平台红包等跨店优惠的情况下)。
  3. 主订单可以保留下客户的行为轨迹,既满足了客户的操作习惯(一次性支付),也能满足商家发货的拆单需求(不同商家分开发货)。

支付后的订单表现:拆单完成有2个订单,发货或者售后缓解均可开处理

如果不在这个节点拆单,又会怎么样呢?

如果节点往后移,支付成功后将进入待发货的物流环节,如果在该节点及之后进行拆单,那么就会出现同一订单进入不同商家的物流环节的情况,物流环节开始多为商家各自自主进行,因此可能导致订单上不同商品实际的物流情况进展不一,售后情况也极有可能不同步。

若不及时拆单,会导致系统处理逻辑上的复杂、订单展现上的复杂,可能导致商家混淆订单,发货工作、售后退款退货工作出错。

在进入物流环节前完成拆单工作,可以规避一个订单关联多个商家物流情况,多商家之间完全独立,售后也可以完全独立,不需要做数据上的关联,简洁高效,也降低了复杂度,降低了商家出错的概率。

如果节点往前移,在支付成功之前进行拆单可以吗?答案是可以,例如拼多多,将拆单节点放在了下单之后,支付之前,C端表现形式是若中途取消支付,订单列表内可以看到2个订单,但是重新发起支付时,订单会以【合并支付订单】的形式存在,需要一起支付。

下单时的表现:同一订单(一起支付)

电商订单拆单场景与拆单⽅式

电商订单拆单场景与拆单⽅式

取消支付后的订单展现:订单拆分

电商订单拆单场景与拆单⽅式

重新发起支付:拆分后的订单仍然需要合并支付

电商订单拆单场景与拆单⽅式

而拼多多之所以采取这样的方式,原因可能在于:

  1. 相比于支付之后拆单的逻辑,在下单后支付前拆单,订单的逻辑更加清晰、独立,不与其他商户订单产生关联,商家端订单的数据处理上,更加容易。
  2. 如果支持单独支付,那么客户不仅需要支付多次,客户体验较差,而且有些跨店使用的优惠等可能存在逻辑漏洞(因为存在跨店优惠,因此一起支付是比较好的方式,防止出现一个支付了,另一个没有支付的情况,不满足优惠条件而享受优惠,容易让人钻漏洞给平台造成损失),因此在重新发起支付时,拼多多用了合并支付的方式,以主订单的维度进行支付。

因此对接拆单节点的问题,答案是,在物流环节开始前必须完成拆单工作(即完成支付之后),但是可以按照各自的需要,考虑将订单拆单节点放到支付之前。

(二)拆单时的费用处理

拆单时还有⼀件⾮常重要的事情是需要对订单⾦额进⾏分摊处理,特别是在遇到双⼗⼀等⼤型促销活动的情况下,叠加使⽤了不同的优惠券、、红包、折扣、积分等,造成⾦额计算逻辑⽐较复杂的情况,明确分摊逻辑以及优惠使用次序、使用范围尤为重要。

优惠、运费分摊后不仅仅能满足拆单需求,后续如果发生售后情况,需要进行部分商品的退款退货处理,拆单的做法可以令子订单的退款与结算工作都会变得相对容易,因为前期相关费用数据均已准备妥当,售后订单可以直接使用,不需要额外对于交易单的数据做计算,减少出错可能性。‍

在进行具体分摊计算前,我们需要思考不同的影响因素对分摊这件事情产生的影响,主要需要考虑的因素是否同类型优惠?

优惠是否可以叠加,有不同情况,可以组合出4种主要场景,即:

  1. 同类型优惠,可叠加
  2. 同类型优惠,不可叠加
  3. 不同类型优惠,可叠加
  4. 不同类型优惠,不可叠加

同类型优惠,可叠加:比如新人满减优惠券和店铺满减优惠券,是同类型优惠,大多数情况会设置为可叠加使用,用于促进新用户的交易。这种情况下因为优惠券类型是相同的,因此分摊计算方式也是类似的(比如说上述的新人满减优惠券和店铺满减优惠券,本质上都是满减优惠,满多少优惠多少,分摊优惠的计算公式统一为:

单一优惠下商品分摊优惠=该商品金额/所有商品金额之和(即该商品金额占比)· 享受优惠金额。

但是因为优惠券可叠加,因此每件商品的分摊优惠,要把多张优惠券考虑进去,不要遗漏。

假设现在有不同店铺商品a,单价100元,商品b,单价200元,新人优惠券X满100-10,平台优惠券Y满300-60,优惠券商品a、b均可用,2张优惠券可以叠加。

则使用优惠券X的分摊计算公式为:

优惠券X分摊到商品a优惠=商品a金额/所有商品金额之和(商品a金额+商品b金额)·享受优惠金额X= 100/(100+200)· 10 =3.33元

优惠券X分摊到商品b优惠=商品a金额/所有商品金额之和(商品a金额+商品b金额)·享受优惠金额X= 200/(100+200)· 10 =6.67元

使用优惠券Y的分摊计算公式为:

优惠券Y分摊到商品a优惠=商品a金额/所有商品金额之和(商品a金额+商品b金额)·享受优惠金额Y = 100/(100+200)· 60=20元

优惠券Y分摊到商品b的优惠=商品b金额/所有商品金额之和(商品a金额+商品b金额)·享受优惠金额Y = 200/(100+200)· 60=40元

从上述例子可以发现,同类型的优惠,计算公式往往是类似的。

同时因为优惠可叠加,因此计算商品a的分摊优惠时,需要同时考虑优惠券X、优惠券Y分别产生的影响。因此:

商品a优惠分摊总金额=优惠券X分摊到商品a的优惠+优惠券Y分摊到商品a优惠=3.33+20=23.33元;

商品b优惠分摊总金额=优惠券X分摊到商品b的优惠+优惠券Y分摊到商品b优惠=6.67+40=46.67元。

除此之外,另外几种场景分别为:

  • 同类型优惠,不可叠加:比如同一店铺的不同的满减优惠券(满100-10,满200-30)通常来说是同类型优惠券,但是不可叠加使用,只能选择其中一种优惠力度大的使用。这种情况下,相对于上面的同类型优惠可叠加的情况,分摊方式比较简单,因为优惠不可叠加,每样商品涉及到的优惠就只有一样,计算某件商品分摊优惠的时候不需要考虑多种优惠。
  • 不同类型优惠,可叠加:比如包邮优惠和店铺满减优惠券是不同类型的优惠,但是通常来说可以叠加使用。这种情况下除了可叠加优惠啊,计算分摊的时候需要计算多样优惠对于商品的影响外,在具体计算的时候,因为优惠的类型不同,因此具体的计算公式也是不同的(比如满减优惠的分摊优惠计算公式为:该商品金额/所有商品金额之和(该商品金额占比)·享受优惠金额,而包邮优惠怎是邮费统一为0,不同类型的优惠,计算公式很可能是不同的)。
  • 不同类型优惠,不可叠加:这部分就比较多了,比如说秒杀活动和限时折扣,是不同类型的优惠,但是通常来说不可叠加(这种一般来说优惠力度比较很大,叠加没有必要)。这种情况下,因为优惠的类型不同,因此具体的计算公式也是不同的。同时优惠券不用叠加,因此计算某件商品分摊优惠的时候不需要考虑多种优惠。

概括来说,是否同类型优惠,影响的是分摊优惠的具体计算公式,而是否可叠加决定了在计算某件商品分摊优惠的时候是否需要考虑多种优惠的叠加影响,不要遗漏。

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

题图来自Unsplash,基于CC0协议

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