I直接答案
在订货宝里，「删除商品」其实是两步：先从商品列表里删，商品进入回收站；再到回收站里做一次彻底删除，它才从系统里消失。但第二步能不能走通，不由你点按钮的手速决定，而由这个商品身上挂着多少关联数据决定。没有关联数据的商品，回收站会放行彻底删除；已经产生过订单、被库存或价格策略引用过的商品，回收站只接收，不放手。
所以遇到「删不掉」的时候，先别怀疑权限或浏览器，八成是这个商品已经被业务数据引用过了。系统的判断逻辑很直白：只要有单据或配置指向它，就必须留痕，允许你把它从销售端下架、藏起来，但不允许把它从数据库里挖走。
II操作问答
先分清「删除」和「彻底删除」不是一回事
在商品列表里点删除，只是把商品从日常可见的列表移走，它会被放进商品回收站。这一步相当于「先收起来」，商品名还可能出现在历史单据里，只是不再对外展示。回收站里的商品不会自动过期清空，它会一直待着，等你决定下一步。
只有回收站里的「彻底删除」动作，才会让商品记录真正消失。但这一步是有门槛的：系统会检查它有没有被别的地方引用。没有引用，允许执行；有引用，按钮即使点了也不会真正生效，或者直接被拦下。
一个容易被忽略的点：所谓「没有关联数据」，不只看有没有订单。商品如果被库存记录、价格策略、促销活动、会员可见范围之类的配置挂上，同样算有关联。判断的标准不是「我印象里没人买过」，而是系统里那些配置项里还有没有它的影子。
III操作问答
回收站里彻底删除的具体操作路径
第一步，在商品管理里找到目标商品，执行删除操作，把它送进商品回收站。如果这一步就提示不能删，说明它在列表层面已经被业务数据锁定，需要先处理引用关系，而不是反复点按钮。
第二步，打开商品回收站，找到刚删的那条记录。回收站通常支持单条操作和批量操作两种方式：单条适合确认某一个商品的关联情况，批量适合清理一批从未被使用过的测试商品或录错的商品。
第三步，对确认无关联的商品执行彻底删除。如果系统提示存在关联数据，就说明它不能走彻底删除，只能继续留在回收站。这时候正确的做法不是硬试，而是回到业务侧确认：是哪个订单、哪条库存或哪个价格策略还在用这个商品。
IV操作问答
两种最常见的配错情形，现象完全不同
第一种，把「移入回收站」当成「已经删干净」。现象是：商品列表里看不到了，员工下单时也选不到，但过一段时间整理老订单、导出历史报表，这个商品名又冒出来。原因就是它只是被收起来，底层记录还在，历史单据仍然能引用到它。
第二种，想彻底删除一个「看着没人用」的商品，却被系统拒绝。现象是回收站里那个按钮点了没反应，或提示有关联数据。常见的隐藏关联有三个：曾经被加入过库存记录，被某个价格策略圈定过，或者被某次促销活动的范围包含过。这些引用不像订单那么显眼，但一样会拦住彻底删除。
这两种情形指向同一个取舍：系统宁可留下冗余记录，也不愿意让历史单据出现「指向一个不存在的商品」的断链。所以你越想彻底清理，就越要先把引用关系拆干净，而不是在回收站里反复尝试。
V操作问答
它跟价格、库存、账期、权限、报表的联动关系
价格侧：商品如果被某个价格策略或客户专属价引用过，删除动作会被关联检查拦住。想彻底删，得先把该商品从对应策略里摘出来。
库存侧：只要产生过出入库或库存快照记录，商品就无法被彻底抹掉。即便当前库存为零，历史流水仍然构成关联。
权限与报表侧：商品可能出现在某些角色可见的商品范围里，也可能已经进入销售统计、毛利分析等报表口径。彻底删除会改变这些口径的追溯基础，系统因此保留限制。账期方面同理，赊销或结算记录一旦引用过该商品，它就得留在系统里。
实际处理建议是：不再销售的商品，优先用下架或移入回收站的方式处理，保留可追溯性；只有确认是录错、从未被任何单据和配置引用的商品，才走彻底删除。这样既满足清理需求，也不会破坏历史数据的完整性。
VII常见问题
被问得最多的几个问题
说明这个商品在系统里还有关联数据。常见的有历史订单、出入库记录、价格策略引用、促销活动范围等。回收站允许它停留，但彻底删除会被关联检查拦住。你需要先找到并解除这些引用关系，再回到回收站操作。如果引用来自已完结的历史单据，通常就无法解除，这个商品会长期留在回收站，属于正常现象。
能彻底删除的商品，本身就没有被历史订单引用过，所以不存在「删完后订单里还看得到」的情况。反过来说，一个商品如果在历史订单里出现过，它就不可能被彻底删除，只会留在回收站。这也是系统保护历史单据可追溯性的设计，避免老订单出现指向空商品的断链。
没有。关联检查是系统层面的判断，不是权限或开关能绕过的。可行的做法只有两条：要么按顺序解除引用关系再删，要么接受它留在回收站。对于录错且从未被任何业务数据引用的商品，直接彻底删除即可；对于已经进入过业务流程的商品，更稳妥的方式是下架停用，而不是追求物理删除。
VII继续查
企业微信 · 专属顾问