商品上架

上架记录怎么看?哪些失败需要重试,哪些不用

更新于 2026-08-22阅读约 3 分钟熊掌ERP · BearERP

点了上架按钮、看到「已提交」的提示,这时候商品其实还没上架。请求只是送到了 Ozon,平台那边还要建卡、走审核、分配商品 ID,整个过程可能几分钟也可能更久。

上架记录页记的就是这段过程里每一步的结果。会用这个页面,能省掉大量「为什么商品没出现」的排查时间——因为失败的原因就写在里面,只是需要知道怎么读。

这篇讲清各种状态的含义、两类失败为什么要用完全不同的处理方式、一个商品为什么会出现多条记录,以及卡在「处理中」该怎么办。

一次上架经历哪几步

理解状态含义之前,先看清楚上架请求实际走了什么流程——记录页里的每一条,对应的就是其中一步。

  1. 1本地预检 —— 提交前先检查必填项、图片是否就绪。这一步失败不会消耗 Ozon 的请求配额。
  2. 2提交给 Ozon —— 请求发出,平台返回一个任务号。到这里只代表「收到了」,不代表成功。
  3. 3Ozon 建卡与审核 —— 平台异步处理:校验类目属性、审核图片和文案、分配商品 ID。这一步最慢,也是绝大多数失败发生的地方。
  4. 4回查结果 —— 拿着任务号问 Ozon 最终结果,写回记录。

「已提交」不等于成功

这是最常见的误解。第 2 步成功只说明请求被接收,商品能不能上架取决于第 3 步。所以提交完要回来看最终状态。

两类失败,处理方式完全相反

这是这个页面最有价值的一条判断。分错类会浪费大量时间——把资料错误当瞬时错误反复重试,能重试一整天也不会成功。

  • 瞬时类(429 限流 / 超时 / 5xx 服务端错误)—— 商品资料本身没问题,是这一刻的网络或平台状态不对。等一会儿重试就好,改资料完全没用
  • 资料类(尺寸缺失 / 属性不合法 / 类目不可用 / 品牌问题)—— 平台明确告诉你哪里不对。重试多少次结果都一样,必须回编辑页改。

连续三次同样的资料错误

说明改的方向不对,不是改得不够。回到编辑页,对着报错里点名的那个字段逐一核对——报错通常会指名具体是哪个属性,顺着它查比凭感觉改快得多。

为什么一个商品有多条记录

这是正常的,不是重复提交。一次上架尝试本身就会在流程的不同节点留下痕迹:预检一条、提交一条、回查结果一条;如果触发了自动重试,重试也各留一条。

看最新的那一条。中间过程的记录是留给排查用的——当结果不符合预期时,顺着这条链往回看,能定位到具体是哪一步断的。

失败不会丢草稿

上架失败不会删掉采集箱里的商品资料。改完重新提交即可,不需要重新采集。这一点可以放心——很多人失败一次就去重采,纯属白做。

卡在「处理中」怎么办

「处理中」意味着请求已经在 Ozon 那边排队,平台还没给最终结果。这个状态会自己收敛成成功或失败,通常不需要干预。

但如果长时间不动,要先分清是平台在审核还是回查没跟上。前者只能等——Ozon 的审核队列在忙时会明显变慢;后者可以手动触发一次回查。

不要重复提交

看到卡住就再点一次上架,最可能的结果是同一个商品被建了两张卡,后面还要花时间去删。先看记录、确认上一次的最终状态,再决定要不要重提。

用熊掌ERP 试试这个功能

一个工作台完成 Ozon 采集、采购、发货,支持最多 20 个店铺,提供 ¥0 免费体验版。

其他常见问题

正文没有覆盖到的零碎疑问,集中放在这里。

「处理中」是什么意思?

请求已经提交给 Ozon,平台正在建卡。这个状态会自动收敛成成功或失败,不需要你做什么。如果长时间停在处理中,说明 Ozon 侧还没给结果。

哪些失败重试有意义?

网络类和限流类(429、超时、5xx)——这些是瞬时问题,过一会儿重试可能就成了。资料类失败(尺寸错、属性缺、类目不可用)重试多少次都一样,必须先改资料。

同一个商品出现多条记录正常吗?

正常。一次上架尝试会留多条痕迹:预检、提交、以及自动重试。以最新一条的状态为准。

失败的商品资料还在吗?

在。上架失败不会删除采集箱里的草稿,改完资料可以重新提交,不用重新采集。

相关阅读