团队到园前四十分钟，领队的消息追到窗口：车上多了三个人，餐要加一桌，车也要换一台大一点的。窗口这边最纠结的并不是这三个人怎么补，而是补出来的东西挂在哪——挂在门票那一张单上，还是另开一张。团队餐和用车这一票之外的两项附加需求，在票务系统里长期就是这么个位置：所有人都知道要加，只有一直没定归谁管。

按位控还是按车控。判据是这项资源有没有离散容量。用餐按位控，“桌”只是打包单位，库存落在位上，加一桌等于加若干位，剩位为零就停止接新单；用车按车控，车型是容量单位，五人座和十九座是两条独立库存线，加人不一定加车，但换车一定占掉一台。景区票务系统里如果把用车也按位控，就会出现“位够、车不够”的尴尬场面，出团当天只能现场换车；反过来把餐按车控，厨房的备餐量就被锁死，来一桌做一桌。票务系统的附加项库存设计，本质上是一条：别把两种容量混成同一个数字，混了之后每天中午都要人工重算一遍。

同单还是子单，倾向子单。门票是主单，团队餐和用车各挂一张子单，共享同一个团队编号和同一个到园日期。原因是三者的核销点完全不同：门票在闸机，餐在餐厅出餐口，车在停车场出口。同单会出现“整单已核销但餐还没吃”这种状态混乱，出餐口无法凭一张已核销的票判断该不该上菜。子单的另一个好处是退款边界清楚，取消用车只退那张子单，不动门票，也不影响已经出票的人数。景区票务系统里做过团队业务的都会遇到同一条：同单看着少录一次，实际每次部分取消都要人工拆开，拆还得靠领队那条消息的记忆。

结算按人头还是按车，分两条线。团队餐按人头，按实际到园人数结算，出餐口的计数是依据，预订人数只用来备餐；用车按车，一辆一价，按占用台数结算，坐几个人不管。把两项都按人头，会出现同一台车被三个团队分摊时算不清谁该担多少；都按车，餐的临时加位又没法进结算。票务系统里这两条结算线最好汇在同一张日结核对表上，团队编号是唯一连接键，缺了这个键，月底对账就会出现“餐费对不上团”的扯皮。

临时加一桌在系统里怎么补。给一个动作序列，别让现场自由发挥。第一步查当日剩余位，第二步在主单下追加一张餐的子单并写明“到园后追加”，第三步同步给餐厅一份带团队编号的追加条，第四步在离园结算时把这张子单并入应收。补录一定要留时间点，因为“到园前加”和“到园后加”在厨房备餐上是两回事，前者能并进当日备量，后者只能走余量。常见错法是领队口头说一声、售票员凭记忆加，最后按人头结算时那半桌不知挂在哪个团队，只能两边各让一步。

附加需求不进单，就等于没发生。留在口头交代和消息记录里的追加，事后无法复盘，也无法解释为什么那天餐厅出餐慢了。景区票务系统里把团队餐和用车当成一等凭证做，收益有三处：出餐口和车场有凭据可刷，结算有两条独立线可对，领队改需求有时间点可查。票务系统在团队场景里最吃亏的做法，是把附加项当成备注字段——备注不参与库存、不参与核销、也不参与结算，只在打印单上占一行，看着有，实际没有。这一条比多加两个字段更值得先改。