"闭环"这个词在方案里出现得太频繁，以至于失去了意义。放到价格任务上，它其实指一件很具体的事：任何一次价格变化，都能回答三个问题——谁改的、货架上有没有真的改成、改的结果留下记录了吗。三个都能回答，才叫闭环；只能回答前一个，那只是一套下发工具。
这篇文章把价格任务拆成六个组成部分，逐个说明它解决什么问题、缺失时会出现什么症状。适合在系统选型或内部流程梳理阶段作为核对清单使用。
一、六个组成部分，六类不同的问题
很多团队把"价格管理"当成一个功能，实际上它是六件事叠在一起。把它们分开看，就能发现自己的短板在哪一层。
价格、原价、单位价、产地、会员价、二维码放在哪、多大、什么字重。模板把品牌规范固定下来，避免每家门店自己发挥。缺失时的症状：同一个促销活动，十家店做出十种版式。
商品编码、名称、规格与货位的对应关系。这一层最容易出错，因为它依赖门店把标签绑到正确的货位上。缺失或混乱时的症状：价格是对的，但贴在了隔壁商品前面。
来自 ERP / POS 或商品中心，包含常规价、促销价、会员价与生效时间。关键不是取到价格，而是取到"此刻应该显示的那个价格"。缺失时的症状：促销结束了，货架上还挂着促销价。
总部能改全部，区域能改哪些品类，门店只能执行还是也能临时调整。权限不是限制，而是让责任可以归属。缺失时的症状：出现异常价格，但没人知道是谁操作的。
任务下发成功不等于货架刷新成功。执行状态要按终端粒度回传：成功、失败、离线、电量不足。缺失时的症状：系统显示改价完成，现场还有一批旧价格。
每次任务的发起人、时间、影响范围与最终结果。它平时没用，在价格争议、内部核查与合规检查时是唯一依据。缺失时的症状：客户投诉标价与结算价不一致，无法证明当时货架上显示的是什么。
二、闭环的关键在回传，不在下发
下发是单向的，做起来不难：把任务推给基站，基站广播给终端，结束。难的是回传——系统要知道每一片标签的实际结果，并把"没成功的那些"变成一份可以处理的清单。
这中间有一个容易被忽略的差别：任务级状态和终端级状态。任务级状态告诉你"这次改价 98% 完成"，终端级状态告诉你"剩下 2% 是哪 47 片、分别什么原因"。前者是给管理层看的数字，后者才是能派工的清单。只有后者存在，运维流程才能建立。
标签被移到了信号死角，或基站覆盖不足。处理方式是调整位置或补基站，不是换标签。
刷新需要电，低电量终端会拒绝执行。系统应提前按电量阈值告警，而不是等改价失败才发现。
刷新成功但内容不对。这是商品数据层的问题，需要重新绑定货位，回传状态是"成功"，反而更难发现。
上游价格没同步过来，平台根本没生成任务。这类问题要靠接口层面的对账发现，终端侧看不出来。
CASE C 是四种里最危险的：系统认为一切正常，实际货架上的价格是错的。防这一类只能靠定期抽检加上绑定流程规范，系统本身给不了答案——这也是为什么"闭环"不能完全等同于"系统自动化"。
三、批量改价：不要一次全刷
一键改全店听起来很好，实际执行时会带来两个问题。第一是耗时——电子纸整屏刷新需要时间，几千片终端同时排队，完成时间会明显拉长。第二是排查困难——如果失败率是 3%，你拿到的是一份分散在全店的清单，补漏刷要满场跑。
更实际的做法是按品类或区域分批。分批的好处是每一批完成后就能验收、就能补漏，问题被限制在一个可控范围内。促销日改价尤其应该提前分批排好，而不是开店前十分钟点一次全刷。
下面是一份促销日的分批示例。它不是标准答案，具体批次划分要按门店的品类结构和开店时间调整，但这个思路可以直接套用：把最容易出问题、最需要人工确认的品类排在最前面，把量大但风险低的品类放在后面，中间留出补漏时间。
这份排期真正的价值不在时间点，而在它把"改价"从一个动作变成了一条有验收节点的流程。每一批结束都有人确认，失败清单在开店前清空——这才是分批的意义。如果只是把全刷拆成几次全刷、中间没有人看结果，那么拆和不拆没有区别。
四、接口层：靠导表的系统最终会有两套价格
如果价格数据是靠人工导 Excel 进价签系统的，那么系统里的价格和 ERP 里的价格必然会在某个时刻不一致——不是因为谁不认真，而是因为人工同步一定有延迟和遗漏。
RESTful API 对接的意义在于消除这个中间环节：价格在 ERP 里改，平台自动拿到、自动生成任务。这时候需要确认的是几个具体细节：
字段口径是这四项里最容易被"以为对齐了"的一项。双方各自都清楚自己系统里的字段含义，但没人把两边放在一张表上逐行核对，结果往往在首店验收时才暴露。下面这张对照表建议在对接前填完，每一行都要有 ERP 侧和价签侧两个明确答案：
最后一行值得单独强调。促销上线所有人都会盯，促销下线常常没人管——如果失效逻辑没有做，货架上就会长期挂着已经结束的促销价，而这在合规上比改价晚了几分钟严重得多。对接时把"失效由谁触发"写进接口文档，比事后靠人巡店可靠。
闭环不是"系统自动做完所有事"，而是"每一次改价都能被追问到底"。判断标准很简单：随便挑一天、挑一片标签，你能不能查出它当天显示了什么价格、是谁改的、有没有改成功。
五、把闭环落到日常运维
系统能力只是一半，另一半是日常动作。下面这四条是我们在项目里反复确认的内容，建议在上线前写进运维文档，明确到岗位：
不是看完成率，是看清单。失败终端要在当班内补完，不能积压到第二天。
电量是可预测的，提前更换比等失败后补救便宜得多。
陈列调整后标签容易错位，抽检是唯一能发现 CASE C 类问题的手段。
按内部合规要求确定保存时长，并确认可以导出——需要用到它的时候通常很急。
把这六个组成部分与四条运维动作放在一起，价格任务才真正成为一个闭环：业务系统改价，平台生成任务，网络下发，终端执行，状态回传，异常有人处理，记录可以回溯。任何一环缺位，改价都会退回成"靠人盯"，而人盯的成本会随门店数量线性增长。