"我们先把票种建起来"——景区上线票务系统的第一次会议上，这句话几乎一定会出现。听起来简单，实际决定了这套景区票务系统未来三年的报表能不能看、改价要不要停机、检票口会不会出现"这张票系统里没有"。问题的根源是绝大多数人把票种、价格、优惠这三件事挤在同一层里做，结果三件事互相卡住。正确的做法是分成三层：主数据层定"这是什么票"，价格层定"它按什么价卖"，优惠层定"谁能少付"。

第一层主数据：只放不随季节和渠道变的东西。一个票种的主数据字段应当只有这几项：名称、类别、适用人群、是否需要实名、有效期起算方式、可入园次数、是否允许退。判断一项该不该进主数据，就问一句"它变了这张票还是不是同一张票"。旺季和淡季价格不同，票还是那张成人票，所以价格不进主数据；年卡当年有效、次年续费有效，卡还是那张年卡，所以有效期起算方式进主数据而具体日期不进。主数据层最怕的操作是新建一个"成人票（旺季）"，这一建，报表里的销量就被切成两段，同比环比全都失真。

第二层价格档：一个票种挂多条价，改价必须带生效时间。景区票务系统的价格档通常有四种来源：门市价、季节价、场次价、渠道价。四者不是并列关系，而是有优先级的：渠道价覆盖季节价、场次价按入园日期命中。落地上有两个硬要求。一是改价不能立即全网生效，已售出的票按下单时的价格结算，否则游客拿着付款截图来窗口，你说票价变了，这就是一起投诉；二是每次覆盖都要记录操作人、原因和原值，尤其是团队价这种需要审批的档位，没有记录就查不清谁给某家旅行社放了这个价。

第三层优惠规则：把政策从票种里拿出来。免票人群、儿童身高线、老人优待、军人优待，这些是政策，不是票种。把它们做成独立票种会带来两个麻烦：政策调整时要改票种、检票口的核验规则要跟着改；报表里免票人数被记成"销量"，看起来像卖了钱。可用的做法是票种上只保留"适用人群"标签，优惠规则单独一层去命中：满足条件的免票、需要凭证的减半、限时活动打折扣。优惠层还要处理叠加关系——券和渠道价能不能同用、满减和团队价哪个先生效，不写清就会在收银环节出现两种算法。

分三层还有一个隐性好处：检票端只认票种，不认价格。售检票系统的闸机、手持检票机、人工核验终端要判的是"这张票能不能进、能进几次、是谁的"，价格信息对它毫无意义。当票种是干净的主数据时，检票规则就只有一条判断链；当价格被写进票种名，检票规则要变成"任何包含'成人票'的票种都放行"，这类模糊匹配是误放的源头。景区票务系统的票种表建好之后，最理想的状态是三个月不动它，动的是价格和优惠。