调价这件事，为什么总是"发了但没落地"
总部定好新价格，通知发进微信群，Excel 价目表改一版发下去，然后打电话一家家确认。看上去流程走完了，实际执行里常出现四种情况：
- 门店没换价签，收银台还是老价，顾客拿着价签来理论；
- 换了价签，但另一家门店漏了，等到盘点才发现两家卖的价格不一样；
- 促销活动到期没人记得恢复原价，活动价被一路沿用到下个月；
- 月末看毛利，某几个品类掉了，但说不清是哪次变价、哪几家门店造成的。
这些问题的共同点是：改价这个动作没有留痕，执行这件事没有证据。通知是口头和群消息，执行是口头汇报，最后只剩一张不知道哪一版为准的 Excel。
用 Inkwell AI 构建器搭一个"调价与促销执行"模块，要解决的正是这三件事：改什么（价目与调价单）、什么时候生效（生效时间与流水）、谁执行了（门店确认与照片），以及由此自动得出的变价前后毛利差异。下面按"底表怎么建 → 页面怎么分 → 自动化怎么配 → 手机端怎么用 → 上线前查什么"的顺序讲清楚。
底表怎么建：四张表管住"改什么、何时生效、谁执行的"
不要一上来就想页面。先把表拆对，后面的页面、审批、自动生效都是从这几张表里长出来的。
第一张：商品价目表（主表）
一条商品一条记录，至少包含：商品编码（唯一）、品名、规格、单位、常规售价、成本价、是否价格管控品、当前状态。商品编码必须是外部可对齐的主键——后面要和门店收银编码、库存编码对上，编码不统一是这类项目最常见的返工原因。
第二张：调价单（主表 + 明细子表）
一张调价单代表一次变价动作，可携带多个商品。主表放：调价原因、适用范围（全部门店 / 指定区域 / 指定门店）、期望生效日期、审批状态。明细子表放每个商品的"原价 → 新价"。
这里有一个必须坚持的设计决定：原价由系统从价目表带出，不允许经办人手工填。手填原价看起来方便，但后面算毛利差异时你无法判断这个"原价"是真是假，整张报表的信任度就没了。做法是把明细里的商品字段设为对价目表的跨表引用，选中商品后原价自动带出、只读。
第三张：价格变更流水（只增不改）
调价单审批通过的那一刻，把每个商品的价格改动写进流水：商品、原价、新价、生效起始时间、生效结束时间、关联调价单号。
这张表是整个模块的地基。它只增不改，好处是任何时点问"这个商品那天卖多少钱"，都能查到当时的真实价格值，而不是去猜历史版本。审批是谁点的、什么时候改过数据，平台的操作审计日志会一并留痕。
第四张：促销活动（主表 + 门店执行子表）
活动主表放：活动名称、活动类型（特价 / 满减 / 组合价等，按企业自有口径定）、商品范围、活动价、起止日期、适用门店范围。子表按门店逐条生成执行行，状态走"待执行 / 已执行 / 已确认 / 已作废"。
三个关键设计决定，值得在动手前先定下来：
- 状态字典集中放在数据字典里，不要在各个页面里散落"待生效""未生效""生效中"这类同义字符串。字典一旦统一，看板筛选、自动流转、报表分组全部复用同一套值，改口径只改一处。
- 主表与明细拆开，流水与主记录分离。调价单是"一次动作"，流水是"一条条事实"。混在一张表里，后期做活动变更、部分商品撤回时会互相锁死。
- 门店范围用引用而不是手写文字。适用门店、区域都从组织架构里引用，门店改名、新店加盟进来时不用回来改历史单据。
如果是第一次上线，商品价目表通常已经存在企业的 Excel 里——可以直接用平台的 Excel 导入能力把底表一步建成模块，再把上述字段补齐，比从空白页面手敲几十上百个商品快得多。## 页面怎么分：谁看什么，看一处就够
同一个模块，四类角色看到的应该是四套不同的页面，而不是一个大而全的表格让所有人自己筛。
总部定价员：申请与维护
- 调价申请页：新建调价单、加明细、填生效日期、提交审批。列表按状态分组（我提交的 / 待审批 / 待生效 / 已生效）。
- 价目表维护页：日常查价改字段；批量场景用导入而不是逐条点。
- 活动管理页：建活动、配商品范围与门店范围、看活动期内的执行进度。
区域经理：执行进度
一张"我负责区域的执行清单"，按门店排出待执行条数、超期天数，点进去能看门店回传的价签照片。这是区域经理最常用的一个页面，不需要别的权限。
店长 / 店员：我的待执行
只显示"我这家店要做什么"：改哪些商品、改成多少、什么时候前完成、确认方式。列表项少而明确，避免店员在一堆筛选条件里找活。
财务 / 商控：变价对账
按活动、按门店、按商品三个维度汇总变价前后的价格差与销量，得出毛利影响；可导出对账明细。这里有一句必须讲明的边界：毛利差异只按系统内记录的售价与成本价计算事实，销量数据需要从门店进销存模块取数或按日销表导入。系统不会替你判断这次调价"成功了"还是"失败了"——那是经营判断，不是系统结论。
自动化四类：让流程自己往前走
页面解决"人要看什么"，自动化解决"人不看的时候系统做什么"。这个模块里值得配的自动化有四类：
一、审批流
调价单提交后走审批。建议按"价差幅度"或"商品品类"分流：常规小幅度变价走一层审批，涉及管控品或大幅调价的走二层。阈值和审批人按企业自有标准定，工具只是把规则固化下来。促销活动同样可以先审批再生效，避免活动价被随手改。
二、定时任务
这是"生效日期"真正生效的地方。设定好生效时间后，由定时任务到点执行三件事：把价目表当前售价切成新价、在价格变更流水里写入生效起始时间、把调价单状态从"待生效"翻成"已生效"。活动到期时同样自动翻转：写入新的变更流水、恢复常规价、把门店执行行置为待复核。
用定时任务而不是"人工点一下生效"的原因很实在：到期恢复原价这件事，最容易被忘掉。
三、数据流规则
条件触发的数据变换，用在这个模块里有三个高频场景：
- 调价单审批通过 → 自动按适用范围生成门店执行行，不用人去勾选门店；
- 活动结束 → 自动把未确认的执行行标成待复核，进入下一轮检查；
- 门店全部确认完成 → 回写活动主表的执行进度字段，看板据此显示进度。
四、通知提醒
- 每天把"待执行清单"推给未完成的门店负责人；
- 超期未执行时，把清单推给区域经理，而不是继续打扰店员；
- 管控品发生调价时，给财务发一条知会消息；
- 活动开始前一天提醒门店准备价签与陈列。
四条自动化都配齐，这个模块才算从"登记表"变成"有推力的流程"。整体结构可以参考平台的工作流与定时任务能力说明，思路是通用的：审批管权限、定时管时点、数据流管联动、通知管提醒。## 移动端怎么配合：执行确认在现场完成
调价执行的现场在门店，不在办公室。所以这个模块的重心其实在手机端：
- 店长打开移动端工作台，直接看到"我的待执行"清单，逐条打勾确认；
- 换完价签后拍照上传，照片作为执行凭据留存（走平台的文件上传能力，按门店与日期归档）；
- 网络不稳的门店允许先提交文字确认、照片事后补传，状态标记为"已执行待补图"，总部看板单独列出来催；
- 巡店人员到店时可以直接在手机上调出该店当天的执行记录核对，不用回办公室翻表。
PC 端与移动端是同一套数据、不同的页面组织：总部在电脑上做审批和汇总，门店在手机上做确认和上传，两边看到的是同一张单子的不同侧面。移动端的具体用法可参考平台移动端使用指南。
上线前请查这六项
- 商品编码唯一且与收银编码对齐。这是最容易在上线第一周翻车的地方，先做一次全量比对。
- 价目表与门店实际售价抽样核对。系统里的"原价"要和门店真实在卖的价格一致，差异先修正再上线，否则第一批毛利报表就是错的。
- 状态字典先定好。待审批 / 审批中 / 待生效 / 已生效 / 已作废 / 已终止，改口径之前在数据字典里统一，后面所有筛选与看板都依赖它。
- 审批阈值与审批人书面确认。谁的价差要谁签，落在流程配置里，不要留在口头。
- 试点跑完整一圈。先挑两三家门店，走一遍"申请 → 审批 → 到点生效 → 门店确认回传 → 毛利汇总"，确认每个环节的字段都够用，再全量铺开。
- 权限核对一遍。门店只能看自己门店的单据，区域经理看本区域，总部看全部；权限按角色配，具体做法见角色与权限配置。
之后可以怎么延伸
这个模块立起来之后，往下接成本很低，因为主数据（商品、门店、价格）是现成的：
- 接门店进销存：活动期间的销量、库存、断货情况一起看，毛利测算才完整，可参考零售门店进销存的做法；
- 接会员体系：让活动只对指定会员等级生效，把价格执行与会员权益打通；
- 接巡店检查：把"价签与系统价一致性"做成一项巡店检查项，扫码核对，形成周期性抽查记录；
- 接供应商：促销涉及供货价调整时，反向生成对供应商的调价知会，避免卖得越多亏得越多。
这个模块不做什么
讲清楚边界，比夸大能力更有用：
- 不改写收银机 / POS 里的实价。POS 侧的价格下发要按各收银厂商的接口单独对接，属于另一项工作；这个模块管的是价格决策、生效时间与门店执行留痕，POS 对接需另行评估。
- 不做竞品比价抓取，也不做自动定价算法。
- 不做促销效果归因建模（比如价格弹性、促销增量拆解）。毛利差异是按系统内记录的售价与成本价算出来的事实差值，怎么解读、下一步怎么定价，仍然是人的判断。
- 不替代财务的毛利核算体系。它是给财务提供一份口径一致、可追溯的变价数据源，而不是第二套账。
一句话总结：把"总部改价"这件事，从群消息变成一张有审批、有生效时间、有执行证据、有差异汇总的单据链。先从一家门店、一个品类试起来，比一次性铺满全部门店更容易成功。## 相关阅读