多渠道 ERP 的核心不是聚合，而是建立经营事实层

“把数据拉到一起”只是第一步

渠道 API 可以把订单下载到一个系统，但不同平台对取消、退款、预售、组合品、税费和履约的定义不同。直接拼表会制造一张看似统一、实则语义冲突的看板。

ERP 的关键工作是定义企业自己的业务对象和状态机，并保留渠道原始状态。统一层用于经营协同，来源层用于对账和追溯，两者不能互相替代。

先治理商品，再谈库存统一

同一实物可能在不同渠道使用不同 SKU、标题、套装和计量单位。商品主档需要建立 SPU、销售 SKU、库存 SKU 和渠道 Listing 的关系，并对拆套、组合和替代品设置规则。

库存可售量不是简单的仓库现存。它还受预留、在途、质检、渠道安全库存、履约时效和超卖策略影响。每次库存发布都应知道来源、计算版本和目标渠道。

• 商品映射：SPU、销售 SKU、库存 SKU、渠道 Listing
• 库存状态：现存、预留、在途、质检、不可售
• 发布策略：安全库存、渠道优先级、更新频率
• 异常策略：映射失败、负库存、接口限流和人工锁定

订单同步必须按分布式系统设计

渠道通知可能延迟、重复、乱序或遗漏，API 也有速率限制和时间窗口。同步任务需要幂等键、游标、重放、补拉和死信队列，不能假设每个订单只来一次且顺序正确。

状态变更还要考虑双向冲突：渠道已取消但仓库已出库，客服修改地址但物流已揽收。系统应基于业务时间和责任系统决定谁是权威，并把无法自动解决的冲突进入异常队列。

履约编排要解释“为什么从这里发”

仓库选择需要综合库存、市场限制、时效承诺、物流能力、成本、拆单和税务规则。规则引擎应输出决策理由，并允许运营在受控范围内覆盖，避免黑盒调拨。

履约后的轨迹继续回流：实际时效、费用、拒收和退货更新路线表现。没有闭环，路由规则只能依赖静态经验，无法随渠道和市场变化。

财务能力必须从交易发生时进入

订单创建时就应保留币种、税费、折扣和支付信息；发货后关联物流与成本；平台结算再补齐佣金、退款和其他费用。财务不是月末把渠道汇总导入总账，而是贯穿事件生命周期。

多币种场景需要区分交易币种、结算币种和本位币，并保存使用的汇率类型与日期。否则同一利润指标会因取数时间不同而无法复算。

控制塔的价值在异常处理，不在大屏

真正影响经营的往往是少量异常：高价值订单卡住、热销品映射失败、库存长时间未同步、退款没有原单、结算金额不平。控制塔应按金额、客户影响和时效排序，并明确责任。

帆途（OmniTrek）把渠道覆盖、财务、数据分析和私有化部署组合在同一事实层上。看板只是结果，稳定同步、可解释规则和闭环异常才是竞争力。