集团后台导出的那张表里，同一个票种并排出现了三个名字。三个名字来自三个园各自的售票系统，说的却是同一种一日联票。票务系统在这一步要做的不是把名字改成一样，而是先承认上下两套各有用处。先弄清哪一层的哪个人在用哪一套，再谈对齐。

集团票种目录在上，票务系统把本地名挂上去

三层结构从上往下是固定的。集团票种目录在最上层，一条记录一个 code，code 是这一层的主键，改名不改键。中间那张是映射表，本地名通过 group_code 挂到对应的 code 上，一个本地名只许挂一个 code。最下层才是各园的本地名，它只在本园的窗口、检票口和线上购票页里认。对外的那一套只有一套名字，导出与对账单一律只出集团名。

为什么要留两套名字。本园的售票系统里，员工喊的是“亲子两人大小票”这一类口语，游客搜的也是这几个字；统一后台要的是把三个园的同类票并到一行来统计。硬把本地名抹平成 code，窗口念不出来，游客在页面上也搜不到，最后是每个园偷偷再自建一套。票种目录管口径，本地名管说法，两边都不必替对方干活。

映射表谁能改，同不同看 code 不看字

名称映射只存在中间那一张表里，其余报表全是读它，改一处就全集团生效。维护权限收在集团票种管理员手上，园区侧的售票系统管理员只能提交申请，改不动那一栏。同义不同名好判，两边能挂上同一个 group_code，就是票种目录里的同一条。同名不同义难判，三个园都写“亲子票”，有的含二次入园有的不含，判的时候看 code 上挂的权益字段，不看名字这几个字。

本地名改了，老订单显示的还是下单那天快照下来的叫法，不跟着新名走。这一条要写死，否则上月卖出的票在本月退款单上换了名字，客人手上两张单子对不上，窗口就得一张张解释。集团名改了才算真改了，它在导出和对账单里只有一个来源，不会出现一份文件一个说法。

票务系统拦下的两类配法

映射漏配最先露馅的地方是对账单，那一行的集团名根本取不出来。配票种目录的时候当场能做的检查是：拿导出表最左列的 code 去映射表里查它名下有几行 group_code，再和这个园本园票种表里的本地名行数比，两边一比就看出少没少。校验卡在票务系统的上架那一步，映射未配齐的本地票种不许上架。事后补一行也补得回来，但补上之前的那一天，对账单已经少了一行。

只有在同一个本地名被挂到两个集团 code 上的时候，才让票务系统直接把保存拦下来。提示写的是“映射一对多”，要集团票种管理员人工把两个 code 并成一个再上。两种做法摆在一起比就清楚：让系统自动挑一个 code，导出表当天是平的，错的那一半藏在某个园的对账单里，月底才翻得出来；拦下来人工合并，多花十分钟，映射从第一天起就是一对一。