小型电商的 WMS 集成
小型电商往往比预想更早面临是否值得集成仓库管理系统的问题。电子表格在一段时间内足以胜任，但总有难以应付的时候；转折点通常不是订单量，而是订单复杂性：多个 SKU 的变体追踪、组合商品、跨多个履约地点的缺货待交订单，或结账时需要准确的可承诺库存量。本文介绍我们将 GreaterWMS 接入小型电商业务的经验，包括有效的做法、比预期更需要精心设计的环节，以及电子表格仍是正确选择的场景。
为何选择 GreaterWMS
GreaterWMS 是开源仓库管理系统，提供 REST API，使用 Django 后端和 Vue 前端。它支持多仓库库存、货批与批次追踪、入库单和出库单管理，以及基础报表。代码库持续维护，API 文档虽不详尽，但涵盖核心操作。
我们选择它而非托管方案，主要有两个原因。首先，我们已有自托管基础设施，不希望再引入一种规模扩大后按订单收费的 SaaS 依赖。其次，开源意味着可以自行扩展数据模型，无需等待供应商处理功能请求。对于需要追踪批次到期日期的小型业务，这种灵活性很重要。
我们的部署使用包含 Django 应用、PostgreSQL 和 Redis 的 Docker Compose 技术栈；上游项目的 Compose 文件仅包含前端和后端容器，默认设置使用 SQLite。配置不高的 VPS 就能让它与其他服务一同稳定运行。初始设置只需几小时，集成工作则明显更久。
API 集成模式
GreaterWMS 采用基于令牌的身份验证。每名用户都有一个令牌（即 openid 值），通过自定义的 token 请求头传入，而非通过 Authorization 请求头以 Bearer 令牌传入。系统未内置 OAuth 流程或 API 密钥轮换机制，因此应创建最小权限的专用服务用户，而非使用管理员账户。
API 大体遵循 REST 风格，使用 JSON 数据载荷。电商集成主要涉及的资源包括 goods（WMS 中的产品目录）、inventory（各仓库各商品的当前库存）、入库单（采购单与退货）和出库单（待履约的客户订单）。
我们很早就确定了一条原则：绝不在结账路径中同步调用 WMS API。WMS 不应处于关键交易路径上；它响应缓慢或暂时不可用时，不应影响客户完成购买。所有 WMS 交互都经过异步队列。结账流程先在主数据库记录订单并发布事件，后台工作进程接收事件后，在 GreaterWMS 中创建出库单。工作进程失败时以指数退避重试，持续失败则触发告警。这种解耦是必须的。
订单同步
创建出库单的调用需要商品 ID、数量和目的地地址信息。电商订单项与 WMS 商品 ID 之间的映射必须明确维护。我们在目录数据库的每个产品变体上增加字段，存储 WMS 商品 ID。新建产品时手动设置映射，同步工作进程在发送出库单创建请求前检查映射。
状态同步反向进行：仓库处理订单时，GreaterWMS 更新出库单状态，电商系统也需要反映这些变化。GreaterWMS 不主动推送状态变更，因此需要轮询。我们每隔几分钟运行一次轮询任务，查询“处理中”的出库单，检查状态是否变为“已发货”或“已取消”。如有变化，就更新电商数据库中对应的订单，并触发客户通知邮件、运单号更新等后续动作。
创建出库单时，幂等性很重要。后台工作进程在暂时性故障后重试时，不能在 GreaterWMS 中创建重复出库单。创建调用成功后，我们立即将 WMS 出库单 ID 存入内部订单记录。重试时，工作进程先检查是否已有 WMS ID，再决定是否调用创建接口。如果已存在，就跳过创建，继续执行原本要处理的后续动作。这项检查无法覆盖创建调用在 GreaterWMS 中成功、但响应在 ID 存储前丢失的情况；这些情况仍需在重试前与 WMS 进行核对。
库存更新
保持电商库存与 WMS 同步，是最需要持续关注的部分。同步涉及两个方向：电商平台需要准确库存以防超卖，WMS 也需要反映在其系统之外产生的购买和退货。
读取库存时，我们定期从 GreaterWMS 库存 API 获取快照，将数量写入供网店前端读取的 Redis 缓存。轮询间隔取决于销售速度。慢动销商品每小时一次即可；集中爆发销售的商品需要更短间隔，或使用预留模型，让客户放入购物车的商品暂时预留库存，不受 WMS 同步周期影响。
退货是最复杂的情况。退回的商品可能重新入库、进入隔离区待检，或核销报废。GreaterWMS 提供退货入库流程，但电商退货状态与 WMS 入库单状态之间的映射需要明确设计。我们创建状态机，将电商系统的退货原因代码转换为 WMS 处置代码，每新增一种退货原因，都与仓库团队复核映射。缺少映射时，退回的库存可能悄然无法恢复为可用库存。
竞态条件与缓冲库存
即使通过轮询同步库存，仍可能出现竞态条件。如果两个订单同时到达，在 WMS 尚未反映其中任何一个订单前，都读取相同的缓存库存，就可能超卖相当于一个轮询周期内售出数量的商品。对于不能接受超卖的商品，例如限量商品或批次约束严格的易腐商品，正确做法是增加预留层：结账时扣减本地可用数量，再异步与 WMS 对账。
更简单的缓解方式是缓冲库存：将电商数据库中的可用数量设为 WMS 库存减去少量预留。订单消耗这部分可售余量；余量归零时，即使 WMS 仍显示有库存，商品也显示为缺货。这会带来少量库存无法供客户下单的风险，但能降低超卖风险，且不需要预留逻辑。对多数小型业务，缓冲库存是合适的权衡。
何时需要 WMS，何时用电子表格
仓库管理系统会增加集成复杂性、运营开销，以及一个需要维护的新系统。决定集成之前，应坦诚评估要解决的问题是否确实需要 WMS。
以下情况下，电子表格已经足够：SKU 数量少且稳定，只有一个仓库或履约地点，订单量低且手工处理，结账时不需要实时可承诺库存量。在这种情况下，构建和维护 WMS 集成的成本，会超过它所解决问题的价值。
以下情况下，WMS 开始体现价值：有多个仓库或拣货地点；合规或质量要求需要货批或批次追踪；退货率高到需要系统化处理退货处置；或订单处理已自动化，需要准确的库存预留来防止超卖。这些运营问题，电子表格确实无法以合理的严谨程度解决。
本文所述的集成工作，包括测试，耗费了数周工程时间。同样的投入也足以支持大量人工仓库协调工作。开始前，应明确要解决哪些问题，以及软件是否是合适的工具。