n8n多门店订单库存自动分配流程

原文要点

原模板为免费n8n工作流：POST webhook接收含订单ID、客户ID、行项目和可选候选门店的新订单；按订单生成幂等键在Postgres查重以忽略重复投递；OpenAI代理（gpt-4.1）通过HTTP工具逐店查库存、关注限流、幂等预留，跨店方案失败时释放预留回滚；分配方案、判定与缺口写入Postgres；可履约则调OMS确认接口，需复核则推Slack并等待运营通过resume webhook回传opsApproved=true/false后确认或取消。搭建方需自备库存中间件API与OMS接口。

这次做成什么

在自有n8n上搭好这条多门店订单分配流：重复订单不重复扣库存，跨店分配失败自动回滚，缺货订单转人工审批后再确认或取消。配套练习用一条合成双商品订单跑通确认与缺货两条分支。

准备什么

• 可登录的n8n实例（Cloud或自托管）并已能导入模板
• Postgres数据库及n8n凭据，有建表权限
• OpenAI API凭据且账号可用gpt-4.1模型
• 自建库存中间件API：查库存、预留、释放、限流状态四类端点及认证
• OMS订单管理系统的确认/取消接口base URL与认证
• Slack凭据与目标频道（如#inventory-ops-review）
• 能向webhook发POST的订单来源系统（练习时可用curl代替）

具体怎么做

1. 建库表并配Postgres凭据

   在Postgres执行材料一的两张表SQL（表名按你的库改）。在n8n凭据页新建Postgres凭据，填主机、库名、账号密码并测试连通。

2. 导入模板并接订单入口

   打开原模板页点免费使用导入本实例。打开Webhook节点复制Production URL，到你的订单系统（练习用curl）配置POST该地址，请求体用材料二的合成订单。

3. 配置OpenAI代理与库存HTTP工具

   添加OpenAI凭据，确认所选gpt-4.1在账号内可用。逐个打开代理挂载的HTTP工具节点，填入库存中间件的查库存/预留/释放/限流端点与认证头；材料三的代理系统提示词可作为你对照修改指令的独立参考。

4. 配置OMS、Slack与人工审批回路

   在两个OMS HTTP节点填base URL与认证；Slack节点选目标频道；把等待节点的resume webhook URL交给运营工具，约定回传JSON体opsApproved=true继续确认、false取消。

5. 用合成订单跑三类场景

   ①同一orderId连发两次，第二次应被幂等查重忽略；②候选门店库存充足的订单应直接写方案并调OMS确认；③构造两家店合计缺货的订单，应触发预留回滚并推Slack等待审批。

可直接复制的材料

CREATE TABLE IF NOT EXISTS inventory_orders (
  order_id TEXT PRIMARY KEY,
  customer_id TEXT NOT NULL,
  idempotency_key TEXT UNIQUE NOT NULL,
  status TEXT NOT NULL DEFAULT 'received',
  verdict TEXT,
  allocation_plan JSONB,
  shortfalls JSONB,
  created_at TIMESTAMPTZ NOT NULL DEFAULT now(),
  updated_at TIMESTAMPTZ NOT NULL DEFAULT now()
);

CREATE TABLE IF NOT EXISTS inventory_reservations (
  reservation_key TEXT PRIMARY KEY,
  order_id TEXT NOT NULL REFERENCES inventory_orders(order_id),
  store_id TEXT NOT NULL,
  sku TEXT NOT NULL,
  qty INTEGER NOT NULL CHECK (qty > 0),
  state TEXT NOT NULL DEFAULT 'reserved',
  created_at TIMESTAMPTZ NOT NULL DEFAULT now()
);

CREATE INDEX IF NOT EXISTS idx_reservations_order ON inventory_reservations(order_id);

{
  "orderId": "ORD-TEST-9001",
  "customerId": "CUST-DEMO-118",
  "lineItems": [
    {"sku": "MUG-BLUE-01", "qty": 2},
    {"sku": "PLATE-WHT-02", "qty": 4}
  ],
  "candidateStores": ["STORE-A", "STORE-B"]
}

你是多门店库存分配代理。输入是一个订单：orderId、lineItems(sku, qty)、candidateStores。你只能使用提供的HTTP工具：check_stock(storeId, sku)、reserve_stock(storeId, sku, qty, reservationKey)、release_reservation(reservationKey)、get_rate_limit()。
规则：
1. 每次调用前先查get_rate_limit，剩余额度不足时等待下一轮而不是重试刷接口。
2. reservationKey固定为 orderId + "-" + storeId + "-" + sku，重复调用必须幂等，不得重复扣减。
3. 优先用单店满足全部行项目；单店不足时才拆单跨店，且门店数尽量少。
4. 跨店方案中任一预留失败，立即用release_reservation释放本订单已产生的全部预留，再报告结果。
5. 只输出JSON，不要多余文字：{"verdict":"confirm"或"review","allocations":[{"storeId","sku","qty","reservationKey"}],"shortfalls":[{"sku","needed","available"}],"reason":"一句话说明"}。可全量履约时verdict=confirm且shortfalls为空数组；存在缺口或需人工判断时verdict=review。

输入与输出示例

本站虚构演示，代理输出格式与流程走向为示意，非作者运行结果。

输入

{"orderId":"ORD-TEST-9001","customerId":"CUST-DEMO-118","lineItems":[{"sku":"MUG-BLUE-01","qty":2},{"sku":"PLATE-WHT-02","qty":4}],"candidateStores":["STORE-A","STORE-B"]}，查得STORE-A马克杯库存2、盘子4，STORE-B均缺货。

对应输出

{"verdict":"confirm","allocations":[{"storeId":"STORE-A","sku":"MUG-BLUE-01","qty":2,"reservationKey":"ORD-TEST-9001-STORE-A-MUG-BLUE-01"},{"storeId":"STORE-A","sku":"PLATE-WHT-02","qty":4,"reservationKey":"ORD-TEST-9001-STORE-A-PLATE-WHT-02"}],"shortfalls":[],"reason":"STORE-A单店可满足全部行项目"}，随后工作流将该方案写入inventory_orders并调用OMS确认接口。

做完检查这些

• 同一orderId的第二次POST在Postgres查重后被忽略，不产生新预留记录
• 跨店方案中途预留失败时，代理调用release_reservation释放本订单已产生的全部预留，且缺口信息被记录到Postgres
• 库存充足的合成订单触发OMS确认调用且allocation_plan写入数据库
• 缺货订单在Slack频道出现缺口摘要，回传opsApproved=false后订单被取消

容易卡住的地方

• 原文明确需自备库存中间件API与OMS接口，模板本身不含这两套系统，缺它们流程跑不通
• gpt-4.1需你的OpenAI账号实际可用，否则代理节点报错，可换等价模型但需自行验证
• 幂等键与预留键设计是防重复扣库存的关键，改表结构时不要破坏UNIQUE约束
• resume webhook URL外发给运营工具时注意鉴权，任何拿到URL的人都能回传审批结果