商品下架与删除：关联检查及回收站查询｜云上订货系统
云上订货 · 更新于 2026-10-01
商品暂时停卖、某个规格缺货与商品资料不再使用，是三种不同任务。下架用于调整后续经营状态，删除会影响商品及相关资料的有效性，回收站用于查找已删除的商品记录，不能把它当成能完整恢复所有设置的保险箱。完成这项操作，要能说明处理的是哪件商品、哪个规格，客户还能否订购，原库存和未完成业务怎样继续，以及误删后保留了哪些可追溯依据。
先按停卖范围选择动作，不用删除代替下架
如果只是暂时不接新订单，例如供应中断、价格待确认或季节停卖，应先处理上下架。商品还在管理资料中，后续可以核价、核规格再决定上架。若只停卖一个容量或颜色，应检查具体 SKU 的状态，不要把整件多规格商品都停掉。客户类型或某客户不能看见商品，是可见范围的问题，也不应该用全店下架来替代客户屏蔽。
删除适合已确认不再使用、且符合删除条件的商品资料。它不是去库存、取消订单、清欠款或结束促销的快捷办法。比如仓库还有十二箱实物，停止销售可以先下架；不能为了让商品列表整齐而把库存调零后删除。已接订单需要继续交货、取消或协商替换，应在原订单的允许流程中处理，不因商品停卖就认定原交易也自动停止。
进入 PC 商品列表前，先确认当前企业和自己的操作权限，再按商品编号寻找原记录。单件删除与批量删除的权限、企业版本和商品来源限制可能不同，看到某个入口不代表所有动作都能做。联营、集团来源商品有专门限制时，交给对应业务负责人核来源关系，不把它们复制成普通商品来绕过。尤其在同名商品很多时，要把名称、商品编号、规格编号及当前状态一起看清。
图1：临时停整件、仅停一个 SKU、限制客户可见和删除无用资料分别处理；原订单与实物另核。
商品整体和 SKU 分别检查，保存后回查原状态
下面 PC 原图是原味牛奶，商品编号 RYN20260913，页面有商品整体“上架”字段。它只说明整体状态所在位置，不证明其他商品已经下架，也不证明这件牛奶所有规格都能订购。选择目标记录后，在适用的普通上下架模式中调整状态，保存或确认操作，等成功反馈后返回原记录重新查看；只改下拉框还没保存，不能通知销售说已停卖。
图2：历史真实 PC 商品编辑局部保留原编号、单位和整体上架字段；此图是字段位置示例。
SKU 上架另看规格资料。原手机规格画面中的 200ml、DTSN200 和“SKU 上架”开关，说明具体规格有自己的经营状态。这个规格图与上一张牛奶 PC 图不是同一商品的连续操作，不能把它们拼成一次下架验收。实际核对时，应使用自己原商品中的目标规格；需要停一个规格，就检查该规格保存后的结果，并核其他仍销售的规格有没有被误改。
图3：历史真实手机规格资料显示 SKU 上架开关；整体商品与当前规格必须分别核对。
批量上架还有一个容易漏掉的条件：没有上架规格的商品会被跳过。不能看见整批“操作成功”，就认定每件商品都变成可售。对未生效项，应回到原商品核有效规格及其状态，而不是不断重复上架整批。若页面使用“上线、在售、暂停”等其他经营模式，先核企业商品设置及原提示，不把“在售”按普通模式的“下架”理解；操作失败时保留原结果，不任意切换全企业模式。
手机详情的“已下架”提示也不是单独证明整件商品已停卖。商品整体下架或当前选择的规格下架，都可能出现这一提示。下面低糖酸奶的原图保留商品编号与当前 200ml 规格身份，核对时还需要返回整体和规格资料分别查。管理员看到下架提示后，应再用实际客户身份进入手机商城核对应商品与规格的订购结果；缓存页、旧购物车或管理端能查看详情，不等于客户仍能成功提交新单。
图4：同一张历史真实手机详情的顶部状态与下方商品身份两个局部；移除中间空白，没有改动原字段。
删除被拦时，按原提示查有效关联
决定删除前，先查询原商品各规格、各仓库的库存与业务占用，再检查未完成盘点、入库、出库、采购、订货、销售退货和调拨单。一个列表中的库存合计为零，不能替代逐仓逐规格检查，也不能据此断定已经没有占用或未完成业务。系统提示库存问题时，应查实物、原单和单位口径，按真实业务纠正，不用人为造出零库存满足删除。
未完成单据要回到原单号处理。比如采购已到货但入库未完成，先确认实际收货及原采购、入库状态；销售退货实物还在路上，就继续跟进退货与入库。确属取消的业务按允许流程作废，已真实发生的收货、出货和资金记录不能为了删除商品而抹去。历史已完成单据与当前有效未完成关联不是同一条件，不能笼统承诺“有过历史订单永远不能删”，也不能反过来认为有历史资料就总能删。
库存和单据之外，还要查促销商品、商品促销赠品、订单促销赠品、商品套餐组成及商品组装组成。商品没有日常销量，仍可能是某个套餐或赠品的必需项。活动已到结束日期，不足以证明相关组成或引用已经解除；遇到对应提示，应核原活动与有效组成关系。有关联报价单、免费领活动、串号记录或行业应用默认商品时，也按原提示找准确来源，而不是删除其他规格来碰运气。
PC 和手机商城装修引用需要分别检查。商品已经不在销售清单里，仍可能放在旧模板的推荐区、图片链接或商品组件中；系统指出哪个端的装修引用，就到那个端核原模板。解除确实不再使用的引用后重新回查，不能把关掉整座商城作为清理商品的办法。联营来源也要先由对应负责人处理，不自行断开既有合作与转单关系。
图5：库存、未完成单据、活动组成、报价串号与装修引用各有来源；解除当前提示后仍须重查其他条件。
单件先确认结果，批量必须逐件回查
核完条件后，对原商品执行删除并读取完整反馈。成功后刷新有效商品列表，再到回收站按原编号查询；有明确拦截提示时记录该条件及对应业务编号。一次提示通常只指出当前先遇到的关联，处理完后仍可能出现下一项，这不代表系统随机改变规则。确认是自己查看期间被其他人修改的记录时，刷新原资料重新核，不凭旧页面继续提交。
批量删除不能按整批全成或全败来猜结果。联营和集团来源商品可能先被排除，页面会要求确认是否删除其他选中商品；后续也可能在某一件关联校验处停止。出现拦截后，应把选中编号逐件与有效列表、回收站对照，分清已处理、仍有效、被排除和待确认项，再决定是否操作剩余项。没有收到反馈时也先查原结果，不直接重复整批删除，更不把未查看的商品一并补删。
删除影响关联资料，回收站查询不是完整恢复
删除不是简单地从商品列表隐藏一行。商品和规格会不再作为有效资料使用，相关库存记录、购物车、收藏、首页推荐或广告引用也可能受影响；客户指定价、供应商价格和推荐关系同样需要注意。即便能在回收站查到原名称、编号和规格，也不能推断这些关联仍完整保留，更不能承诺恢复商品后客户价、采购价、收藏和装修会一起回到删除前。
进入商品回收站后，先按原商品编号查找，必要时补名称、规格编号或条形码，清除不适用的分类、品牌等筛选并检查分页。多规格商品可打开规格列表，核规格名称、规格编号、图片、销售价和销量。能找到正确记录是定位结果，不是恢复结果；回收站里的旧价格也不代表今天已经能用于新订单。找不到时先核企业、编号和查询条件，不立即新建同名商品解释为“恢复”。
图6：原商品、规格、商城关联和价格资料分别受影响；回收站保留可查信息，不证明所有关联可自动恢复。
误删先保留原身份，重新上架另走核对流程
发现误删，先停止继续清理这件商品，记录原商品编号、规格编号、操作时间、反馈和回收站查询结果，补齐受影响的客户价、供应商价、未完成单据与仓库信息，再交有权限的管理员或技术支持核可用处理路径。这里的回收站操作说明以查询为主；没有可用恢复入口时，不继续寻找“一键恢复全部设置”，也不自行改后台数据或用重新导入宣称原资料已经恢复。
重新建立一件同名商品，可能得到新的系统身份，原订单、库存、价格和历史销量不会只因名字相同就自动归属过去。确需补建时，应明确它是新资料，先确认编号、规格、单位换算、基础价、客户价与后续经营关系，再按实际业务处理遗留事项。尤其不能把旧单商品换成新商品，让历史记录表面看起来连贯，却失去真实对应关系。
对于仅下架、尚未删除的商品，恢复经营则回到原商品检查整体与 SKU 状态，核有效规格、单位价格、客户可见和实际库存后再上架。管理端保存成功，随后用客户身份核原规格能否订购，并检查此前未完成订单的状态。结束记录应分开写下“已停止新订购”“删除完成并查到原记录”或“误删待处理”的实际结果，而不是统称恢复成功；这样下一位处理人能沿原编号继续，不需要猜操作前后的身份。
图7：普通下架、删除及误删处理走不同回查路径；批量无反馈先核逐件原结果，恢复经营仍使用原商品身份。