这是什么
前台是一次住宿被创建、被调整、被计费、被关闭的地方。它按物业的营业日运行而不是墙上的钟，因此到店列表、离店列表和当晚的过账都对「属于哪一天」有一致的答案。前台人员的每一个动作——入住、退房、过账、收款、开团队主账单——都是 API 所暴露的同一个操作。
01
房态时间轴
每间房一行，每晚一列，每次占用该房的住宿是一根条。房型把行分了组，因此一排空着的豪华房是你一眼看到的，而不是需要算出来的。把房间停售同样在这张网格上完成。
02
到店与离店，按营业日
两份列表都按物业的营业日走，而不是读者所在时区的钟——这正是它们能跨夜间稽核、跨时区保持稳定的原因。Walk-in 用的是同一块界面：它一步创建预订并生成已在住的住宿。
03
就绪门槛
这是同一个入住对话框，出现两次。房间干净时直接打开押金字段，Check in 按钮可用。房间未清洁时弹出横幅点明问题，并把按钮拦在一次明确的跳过之后。这是前台可以有意识地越过的策略——不是死墙，也从不悄悄放行。
04
账单、收款与团队结算
费用逐行过入敞开的账单，每行都带自己的费用类型，且余额未清时账单无法结算并开票。团队会有一个主账单，可按每次住宿设定分摊方式，并有一行合计把主账单与各位客人对上。
05
入住时段策略，三层深度
入住与退房时间先设为酒店默认值，再按房型覆盖，然后按房价计划再覆盖一次——范围最窄的生效。含延迟退房的不可退房价，因此是一行策略，而不是备注栏里的一句话。
这对代理意味着什么
代理通过同样的操作和同样的权限模型在前台工作：读取某个营业日的到店列表、为一条预订办理入住、向敞开的账单过一笔费用、对其收款。它会撞上前台人员会撞上的那道就绪门槛，也无法结掉仍有余额的账单。退款与调整在二次验证之后，因此真正要紧的操作里始终有人。