一件代发供应商怎么整合？库存同步加幂等下单核利润

接多个代发供应商，麻烦从对接那天就开始

店铺一旦接入多个代发供应商，问题接踵而至：有的供应商给 API，有的只给 CSV 或邮件，接入方式各不相同；库存同步稍有延迟就会超卖；同款多个供应商供货时该路由给谁说不清；扣掉运费和广告后每单到底赚多少，更是一笔糊涂账。这些都属于"系统怎么设计"的问题，光靠手工对单撑不住。

这个技能能帮你设计什么

它帮你把代发系统的骨架搭起来。接入上，它评估 API、CSV、SFTP、邮件、Webhook 等不同对接方式各自适合什么场景；数据上，它设计供应商商品、库存、成本和履单的数据结构与订单路由逻辑；同步上，它提供库存同步、库存缓冲、幂等下单和物流追踪的模板，防止延迟导致超卖和重复下单；核算上，它用净贡献瀑布把商品成本、运费、手续费和获客成本一层层扣清，算出每单真实利润。

利润这块它用瀑布逐项扣减，让"看着有单、实际不赚"无所遁形：

怎么用它

用法是把你的代发场景和约束用自然语言描述出来即可。例如可以这样对它说：

它适合这些场景：店铺新增代发品类、要把订单自动路由到外部供应商；多个供应商同时供货、按价格库存和位置选最优履单方；供应商库存通过 CSV 或 API 同步、必须防止延迟超卖；想核算每笔代发订单扣除运费和广告后的真实利润。

大家常问

对接一件代发供应商，API、CSV/SFTP、邮件、Webhook 这几种方式有什么区别，怎么选？

区别在于数据是推还是拉、实时性和自动化程度。API 双向、秒级实时、全自动，但要求供应商有接口、开发门槛高，适合高频订单和库存波动大的品类；CSV/SFTP 是按周期拉取文件、单向、有 4—24 小时延迟，几乎所有供应商都能给，适合库存稳定的批量更新；邮件门槛最低但可靠性最差，多用于初期或异常兜底；Webhook 是事件触发的实时推送，适合物流状态通知，但通常要搭配 API。选型先看供应商支持什么，再按日订单量和库存波动决定，常见是库存走 CSV/API、订单走 API、物流走 Webhook 的组合。

多个代发供应商供同一款货时，订单路由按什么逻辑选履单方比较合理？

核心目标是在满足服务水平的前提下最小化综合成本，按优先级逐层筛：先按实时库存可用性过滤掉缺货的；再按客户承诺时效匹配，区域内"最近仓优先"；然后在候选里按总成本（商品成本+运费+附加费，而非单纯单价）排序；最后用供应商评分卡（缺货率、准时率、退货差评率、客服、包装）加权，价格相近（±5%内）时优先选评分高的。新供应商先灰度小流量观察，并设兜底重路由，VIP 客户可优先稳定而非最低价。

代发库存同步为什么容易导致超卖，库存缓冲和幂等下单分别解决什么问题？

超卖的根源是你看到的永远是"过去的数据"：定时同步有时间窗口差、并发下单存在竞争条件、且供应商的同款货同时供给几十上百个分销商共享。库存缓冲是不上架全部库存、预留一段安全区（如显示 80/100），用牺牲一点可售量换取同步延迟和抢购突刺的容错，防的是"跟别人抢"。幂等下单是每个采购请求带唯一幂等键，供应商对重复键直接返回已处理，防的是网络超时重试或用户重复点击导致"同一单下两次"。两者针对不同问题，配合使用才稳。

代发订单看着有毛利却不赚钱，净贡献瀑布是怎么把利润一层层算清楚的？

净贡献瀑布把利润从毛收入开始逐层扣减：先扣退款退货，再扣拿货成本（到此是毛利，往往看着很高），接着扣物流履约、扣营销（推广费+平台扣点+达人佣金，常是最大的隐形支出）、扣运营固定成本，最后才是净贡献——真利润。一个售价 99、毛利率看似 52% 的耳机单，扣完各层可能反而亏几元，这就是"有毛利没净利"的真相。所以要画自己的瀑布图找利润黑洞、用倒推法选品、看净贡献率而非毛利率。