预售期写的明明是十号24点结束，十一号上午页面上还能下单，运营到中午才发现。不是没人记得定规矩，是停售开关设错了层。有人把它设在价格方案上，方案停了售，票种还挂着在售，同一票底下的另一个方案接上，接着卖。票务系统的自动停售要设在票种这一层，在售状态挂在票记录上，价格方案只管这张票按哪档卖。这一层理不清，后面四个开关全白配。

四个开关，各自是谁的手

第一个，预售到期。触发人是建票种的人，他在后台填结束时刻，剩下交给系统。硬数一条：预售到期到停售生效，不超过1分钟。票务系统里这个时限写死在配置里，不靠谁手快。超过1分钟，页面和接口都还停在旧状态，客人点了付款，付进去一张过了期的预售，后面全是退单的活。

第二个，库存归零。没人按开关，配额扣到零它自己落。回滚方式是补库存，补回来就重新开卖。这条线连着预售配额，夜里随手补库存等于半夜突破放票量，所以补库存这个动作在售票系统里单独给权限，谁补的、补多少，当日必须有人审批。

第三个，场次关闭。触发人是场次管理员，关的只是这一场的票，同一票种别的场次照卖。关闭指令生效到场次开始之前都能回滚重开，开演以后不许回滚，闸机那边已经按关闭场次在清点还没出来的人，你一回滚，清场名单就乱了。

第四个，渠道收回。触发人是渠道对接人，关的只是这一个渠道的入口，票的在售状态不动。常犯的错误是想收一个渠道，结果把整个票种停了售，所有渠道的页面一起黑掉，第二天三个渠道轮流来问为什么下架。

停售那一刻，没付完的单怎么办

付过的单一律不动，入园核销照原规矩走。没付的分两种：停售前一个多小时下单的，本来就快被超时作废；停售前1小时内下的，客人很可能正停在付款页上。硬数：停售前1小时内已下单未支付的单，保留支付入口30分钟，30分钟到点自动作废，占掉的配额回补。这条不落地，售票系统里就会出现另一种怪事，前一分钟付的还是正常的，后一单直接被取消退款，投诉全砸在窗口，窗口还说不清系统干了什么。

停售日志只留四行

谁触发的，系统还是哪个工号的员工；哪一分钟生效；停售时段里拒了多少笔下单请求；有没有回滚，谁回的，理由写的什么。四行记全，交班就不用口头传，月底复盘有账可查。回滚预售到期这类开关要管理权限，普通运营只能提申请，理由进日志。票务系统的日志只记不删，数错了走补录，别去动日志本身。

有一个例外：故障误停。系统自己抽风，把没到期的预售停了售，这种不算正常停售流程。恢复在售之后不能当没事发生，售票系统要把停售时段被拒的下单请求从日志第三行里导成清单，交给现场窗口，一条条找人补，人家当时是铁了心要买的，错过这村没这店。清单导不出来，这个例外就没法办，所以日志那四行一行都不能省。