结论：超卖通常是数量、时间与并发三个问题叠加

ERP 显示 100 件，不代表电商现在能卖 100 件。部分库存已被门店、订单或售后占用，部分处于质检、冻结或残次；在途可能晚于客户承诺日期。多个渠道同时读取旧快照，还可能在同一秒把同一件商品卖两次。

ATP 不是一张库存表，而是按商品、地点、渠道和承诺日期计算可分配数量，并在下单时建立预留。系统还需处理取消释放、支付超时、调拨、退货和盘点差异，保证数量守恒。

先统一库存状态与位置主数据

为每个库存位置定义仓、店、前置仓、在途、供应商寄售及虚拟节点，并映射到履约区域。数量状态至少区分 on_hand、allocated、reserved、blocked、quality_hold、damaged、in_transit 和 available，禁止不同系统用同名字段表达不同含义。

商品也要统一 SKU、包装、单位和替代关系。平台商品一套装可能消耗两个基础 SKU，若只按平台 SKU 扣减就会虚增可售量。主数据变更保留生效期，避免历史订单对账时找不到原映射。

一个简化公式是 ATP(t) = 可售现有 - 已分配 - 已预留 - 安全缓冲 + 在 t 前可靠到货 - 已承诺未来需求。实际还要考虑包装倍数、调拨时间、生产计划和渠道配额。每一项都标记来源、更新时间和置信状态。

按客户承诺日期分时间桶，而非把所有未来供给加到今天。下周到货不能支持今天发货，供应延误时必须重算。若数据只支持日级，不能承诺小时级精度；页面应展示可交付日期而不是笼统“有货”。

安全缓冲用于应对盘点差异、延迟和需求波动，不能长期写死一个百分比。按商品价值、缺货影响、库存准确率和补货交期分层。缓冲过高会制造假缺货，过低则增加取消。

渠道配额可以保护门店、重点客户或活动，但会降低整体池化效率。规则应有负责人、生效期和释放条件；临时大促结束后自动归还公共库存。不要把商业优先级伪装成系统库存错误。

查询库存后到支付完成之间存在时间窗口。下单时创建带 reservation_id、数量、订单、渠道、过期时间和版本的预留，使用原子扣减或乐观锁保证并发。支付成功转为分配，取消或超时幂等释放。

重复消息、重试和乱序不能多扣或多释放。每个预留事件有唯一 ID 和状态机，重放结果一致。仅靠每五分钟同步库存，即使数据最终一致，也无法阻止高峰期同一库存被多渠道承诺。

采购单、已发货、到港、质检和上架具有不同可靠度。只有预计在承诺日前可用的数量进入 ATP，并根据供应商历史、运输状态和质检时长设置缓冲。延期或部分到货触发重算与受影响订单清单。

生产型企业还要区分计划产量与可用成品。良率、排产和物料缺口会改变可承诺数量。未经确认的计划可展示为潜在供给，不应与现货使用同一确定标签。

取消订单释放预留，但已拣货、已发货和拒收状态处理不同。退货只有在收货、质检并重新上架后才恢复可售。调拨同时减少源地点、增加在途，目标地点入库后再变可用。

反例是订单取消立即把已发出的商品加回库存；另一个反例是调拨单在两地都计入现货。用事件账本和库存守恒方程抽样重建，才能发现重复和遗漏。

每个渠道连接记录源水位、最后成功时间、待处理事件和同步延迟。渠道展示库存前检查版本；延迟超过阈值时降低可售量、暂停高风险 SKU 或切换到更保守承诺，而不是继续使用旧数字。

库存缓存键包含 SKU、地点、时间桶、规则版本和水位。更新事件主动失效，命中缓存后仍通过预留原子校验。看板显示的是可观测状态，不能把绿色同步图标等同于数量一定正确。

测试两个渠道同时抢最后一件、支付超时、重复取消、部分到货、退货质检、调拨、盘亏、连接延迟和服务重启。检查成功承诺不超过可用、预留不泄漏、释放不重复、负库存和取消率在内部阈值内。

做故障注入：消息丢失、乱序、数据库锁冲突和渠道 API 限流。系统应告警、补偿并可重放，且每个差异能追到订单与事件。只在正常流量下对比一张库存表不足以验收。

先选高销量且状态清晰的少量 SKU，统一主数据和状态，接入一个仓与两个渠道，建立 ATP、预留和对账，再扩在途、门店与复杂套装。监控库存准确率、超卖、取消、假缺货、预留泄漏、同步延迟和订单满足率。

BI0 可作为全渠道库存整合与经营分析候选，但原子预留、交易写回、渠道接口和订单状态机是否属于当前范围需 POC 核验。若只能做分析，应清楚区分“发现 ATP 风险”与“实时阻止超卖”，不能把报表能力描述成库存交易系统。

预约一次业务场景交流，看看组织化的 AI BI 如何进入你的团队。