一次改两百个票价要不要审批，不看改动条数，看两件事：这两百条里有多少已经卖出去、有多少已经同步到对外渠道。两百个空档位和两百个已售档位的风险不是同一件事，审批线应该按这两条来划。

一、范围怎么框。按票种、日期段、渠道三层选，不允许跨层混选，混选的批次连回滚都框不住。预览页必须显示两个数：影响条数、其中使用日期已过的条数。第二个数不为零，这一步就不该被点确认——已售日期的数值一动，退差和对账全压到人身上，系统里还一切正常。预览还要列出涉及的票种和日期段起止，让人看清自己改的是哪一段，只给一个条数的预览等于没预览。

二、生效时间三种。立即生效、定时生效、按使用日期生效，三种都要有，只给"立即"的后台一定出事故。已下的单不受批量改动影响，取订单上那一列价格快照，这列在下单瞬间写入，改价逻辑绝不回头查实时表。正在支付中的订单给一个缓冲窗口，一到两分钟内仍按旧值成交，超出就直接拒绝让前端重建，避免出现"页面一个数、扣款另一个数"。按使用日期生效的那一类，改完当天页面还是旧值，页面上要标一行生效说明，不然窗口当天会被反复问。

三、审批线怎么定。三条走双签：影响条数超过一个事先约定的值、涉及节假日档、改动需要同步到对外渠道。双签是票种负责人加当日值班经理，两个具体名字写进改价记录，不写部门名。记录固定五栏：操作人、审批人、影响条数、生效方式、可回滚时限。那个约定值放在配置里，谁改过这个值也要留痕，否则半年后没人知道为什么是两百。双签在系统里做，不靠纸单，纸单事后查不到，谁批的只剩一张照片。

四、回滚要留整批。每次批量改价生成一份改前快照，一个时限内能整批退回，比如十分钟。退回动作只影响未成交的档位，不覆盖已成交订单。回滚同样进变更记录，标"回滚"并带上原批次号，两个批次号要在同一页面能查到，分开在两张表里等于是没有回滚记录。超过时限还想退，走单独申请，由当日值班经理批，批完留痕，不许直接改数据。回滚时限在批次提交时就显示在页面上，倒计时结束前谁都能整批退回，结束后只剩逐条改；退回时如果已有新订单落在改后的价上，那几条不参与回滚，单独列一张清单交当日值班经理处理。

五、同步与确认。改完要推给渠道，推送带版本号，渠道按版本号比对而不是按时间猜谁新。确认回来的渠道列表要在一个页面上看，未确认的超过几分钟就重推一次并报警。这一步最容易走形：后台显示"已推送"，渠道那边还是旧值，游客看到的和窗口执行的不一致，投诉最后落在现场人员身上。版本号对不上的渠道当天要列清单，清不完不下班。

先做哪一件：先把预览页那两个数做实——影响条数和已售日期条数。这两个数不出现在页面上，任何审批线都只是形式，签了字也不知道自己在批什么。