数据链路为 集团 API → 酒店中间表 → PMS 入库。迪联不同版本中间表的字段长度、枚举值、必填项不一致：集团传 rate_code，A 版认 ratePlanCode、B 版认 rate_plan_id，映射未统一 → 部分订单落「未知价格计划」兜底丢字段 → 财务对账补的正是丢掉的字段。
查 room_status 带 渠道×日期×房型 联合过滤，老版本仅主键索引，未对 channel_id + business_date 建联合索引；部分版本还锁行，关房等锁超时→关房失败链式回滚。
OTA 直连走白名单，携程/美团固定迪联出口 IP。迪联更新防火墙后出口 IP/端口变了未同步平台 → 白名单未更新→请求被拒。
携程/美团直连文档明确支持「PMS 系统商直连」：PMS 厂商以自身开发者账号提交接口→酒店 EBK 授权→订单直推 PMS 接口→厂商分发本地 PMS。
迪联现走「集团 OMS 中转」，是当初选集团集中对接而非 PMS 独立对接的结果。
| 对象 | 高风险点 | 控制方案 |
|---|---|---|
| 未来预订 | 订单号为平台生成，新 PMS 识别不了旧格式→预订掉 | 旧系统只读访问，上线后前 7 天历史订单查询走旧系统 |
| 客史档案 | 会员卡号、入住偏好映射不清 | 迁移前导出 CSV 两轮人工抽验，字段映射先对清 |
| 财务期初余额 | 无法自动迁移 | 新系统手动录入截止日应收应付余额，人工复核 |
| 支出项 | 迪联 | 雅阁 |
|---|---|---|
| PMS 年费 | 10,000 元 | 18,000 元 |
| 当年现金支出 | 10,000 | 18,000 |
| 账面差异 | 基准 | 多花 8,000 元 |
| 年度运营支出 | 迪联（1万/年） | 雅阁（1.8万/年） | 备注 |
|---|---|---|---|
| PMS 年费 | 10,000 | 18,000 | 已知 |
| 财务对账人工 | 12,000–18,000 | ≈ 0 | 日均 0.5–1 小时人工补录 |
| 报表定制 | 2,000–8,000（按需） | 0 | 迪联改一表收一费 |
| 超售/拒单赔付 | 发生过，不确定 | 0 | 关门失败→超售 |
| 平台处罚 | 发生过携程处罚 | 0 | 迪联有前科 |
| 年度总成本 | 2.4万–3.6万＋风险 | 1.8万 | — |
选雅阁不是「多花 8000 买安心」，而是把不确定的风险变成确定的成本。
迪联 1 万买「使用权」；雅阁 1.8 万买「稳定运营」—交付物不一样。
| 场景 | 推荐 | 判断依据 |
|---|---|---|
| 明年预算实在砍不下，账面必须省 | 迪联 | 年费便宜 8,000，接受隐性成本继续 |
| 追求运营稳定，不想天天救火 | 雅阁 | 多花 8,000 但问题闭环 |
| OTA 占比 60% 以上，断不起 | 雅阁 | 断一次直连损失 > 几年差价 |
| 财务人手本已紧张 | 雅阁 | 迪联对账消耗是持续的 |
| 合同快到期，横竖要动 | 雅阁 | 被动续约迪联=放弃选择权 |