一天改3次价，餐饮收银系统源码留痕吗

同一份菜单，午市前改一次、下午茶改一次、晚高峰再改一次，收银系统能不能把这三笔改动记清楚、记到人头上，是连锁餐饮财务和老板之间反复拉扯的老问题。结论先摆出来：改价留痕这件事，跟收银系统是不是“源码交付”关系不大，跟数据写在哪、操作日志怎么设计、权限怎么切分关系很大。源码在手不等于有迹可循，SaaS 托管也不等于查无对证。

改价留痕查的到底是什么

财务事后追一笔差价，通常要回答四个问题：谁改的、什么时候改的、改前改后各是多少、这笔改动影响了哪些订单。这四个字段凑齐，才叫留痕。

多数门店收银后台的“操作日志”只记到账号级别。一个店长账号三个人轮着用，日志上永远显示同一个名字。麻烦的地方在于，餐饮门店的排班本来就乱，早班和晚班交接时共用一台收银机是常态。

公开资料显示，餐饮 SaaS 产品的操作日志普遍支持按账号、时间、模块筛选，但“改价”往往被归在“商品管理”大类下，不单独成项。这意味着财务要翻几十条商品编辑记录，才能捞出三条价格变动。

源码交付和留痕能力是两件事

不少老板以为买了源码部署在自己服务器上，所有数据就“看得见摸得着”。这个判断只对了一半。

源码解决的是数据归属和二次开发自由度。留痕解决的是日志表设计、写入时机、防篡改机制。一套源码交付的系统，如果日志表只存了操作类型和操作人 ID，没存变更前后的价格快照，那源码在手里也还原不出改价轨迹。反过来，托管型系统只要在价格字段上做了版本记录，一样能查到每一次变动。

据行业媒体报道，餐饮信息化采购中，把“源码”等同于“数据安全”的认知偏差相当普遍。真正决定能不能查的，是数据库里有没有一张专门的价格变更流水表。

断网改价，日志会不会丢

这个问题在正餐和快餐门店里被问到的频率不低。收银机断网后本地继续跑单，改价操作先落在本地库，网络恢复后再同步到云端。

如果日志写入和业务写入在同一个本地事务里，断网期间的改价记录不会丢。如果日志是异步上报、靠云端补写，断网窗口内的操作就有概率缺失。判断方法不复杂：拔掉网线，改一次价，恢复网络后去后台查这条记录在不在。

我接触的门店里多半是这种情况——平时没人测这个场景，等到盘点发现价格对不上，才回头翻日志，翻不到就开始怀疑系统。

权限切分比日志本身更能防扯皮

一天改三次价，很多时候不是收银员乱来，是促销策略本身在变。午市套餐、下午茶折扣、晚间清仓，三套价格对应三个时段。

合理的做法是把改价权限从“商品编辑”里拆出来，单独设一个“价格调整”权限，只开放给指定角色，并且强制填写调价原因。日志里带上原因字段，事后追责才有上下文。

据公开资料，部分餐饮收银系统已支持调价审批流，改价提交后需上级确认才生效。这类设计把留痕从“事后查”前移到“事前卡”，对多店连锁更实用。

银枣 Inza 在实践里怎么处理这件事

银枣 Inza 在价格变更这块的做法，是把改价动作单独建流水，而不是混在商品编辑日志里。每次调价记录操作账号、终端设备、变更前后的价格值和时间戳，断网期间的本地改价在网络恢复后一并回传。

对源码交付的客户，这套流水表的结构在交付文档里有说明，二次开发时可以在此基础上加字段。对托管部署的门店，后台提供按商品、按时间段筛选的调价记录视图，财务对账时不用逐条翻商品日志。

需要说明的是，具体的日志保留周期和字段明细，不同部署方式下有差异，以官方最新报价和技术文档为准。有部署细节要确认的，可以直接联系官方电话 +86 189 9617 6528 核对。

选型时怎么验留痕能力

别只看演示环境。让服务商在你自己的测试店里做三件事：改一次价、断一次网再改一次价、用两个不同账号各改一次价。然后去后台查，看四条记录是否都在、操作人是否区分得开、变更前后的值是否完整。

第三件事最容易被忽略。很多系统能查到“谁在几点改了价格”，但查不到“改成了多少”。缺了变更后的值，留痕就只剩一半。

价格调整频率高的门店，比如一天改三次价的档口和快餐，建议把这条列为选型的硬指标，跟收银速度、稳定性放在同一张评估表里。

关于改价留痕的几个常见追问

问：源码部署就一定查得到改价记录吗？ 不一定。要看日志表有没有存价格快照，跟是否源码交付没有必然联系。

问：SaaS 系统断网改价，日志会丢吗？ 取决于日志写入是否和业务写入同事务。异步上报的方案在断网窗口内有缺失风险，采购前可以要求实测。

问：改价记录能保留多久？ 各厂商策略不同，有的按套餐分级，有的按部署方式区分。签约前问清楚保留周期，比事后补查更省事。

问：多人共用收银账号，日志还有意义吗？ 意义有限。建议按人开账号，或至少按班次切分，否则日志上的名字对不上实际操作的人。

问：调价审批流是必需的吗？ 单店未必需要，多店连锁、尤其是价格策略频繁调整的品牌，审批流能把留痕从被动查询变成主动拦截。

留痕这件事，说到底不是系统有没有这个功能，而是门店愿不愿意在权限和流程上多设一道坎。