12 KiB
ARR 接口数据的报表验收清单
2026-09-17最新：getRoomCalendar已在0.9.0目录发布，发布等待项关闭；但3次实际200均无room集合， 新增searchReservationsSummary对原2笔零晚退房仍无roomId。原失败主客复验仍503，6次请求全部审计匹配。 最新验收证据；未重采全日或签发报表等价。
2026-09-17后续：已把严格取值器串成逐笔候选准备，16列分别记录取值或缺口；139笔全保留， 73笔房号/134笔日价/115笔费率代码可取，显示与报表口径仍未验收。按钮后台已有显式v3与姓名上限支持， 237项范围测试通过，未启用正式接线。完成记录。
2026-09-17更新：v3姓名候选已接入字段证据、独立Profile身份关联和同源XML原文/去空格观察； 19新用例/198范围测试通过。旧139笔证据不变，真实失败批次仍拒绝完整导出；未关闭业务验收项。 用户已将503诊断转给平台，本轮未新增接口调用，后续全部独立完成、不创建子智能体。 本轮证据。
2026-09-16。日价发布后的v2整日验证已完成：明确三个日期均为2026-09-15，OHIPSB02的139笔详情/日价齐全， 134笔通过价格币种检查，3笔隐藏价、2笔详情币种缺失。见整日证据， 其余来源语义及同源报告验收仍待完成。 本清单定义需要证明的对应关系，不新增酒店业务规则，也不要求创建测试预订或操作报表页面。
已具备：搜索/详情/日价三个接口的v2独立采集工具、私有原件及清单摘要、档案完整性回放、16来源字段候选统计， 以及本机批次互斥、失败/中断整日重采和已完成档案复用。批次管理不等于Finance端避免重复提交。 新增具备：指定日有效价的整批采集集成、三个系统日期校验、v2本地批次复用与缺价诊断。缺少：同环境同酒店同日期的 API与原报告配对验收、最终来源适配与自动入库。 v3再加入受限主客姓名摘要、逐预订组成核对、原件复用和严格重放；217项范围测试及原3份真实响应离线验证通过。 139笔实际对应112个不同Profile。本地证据。 随后获准的一轮全日实测遇503而停止：6个档案中5个姓名成功，最后一个3次503；139只完成搜索候选，详情/日价到6笔。 23次请求全部对应平台审计，72私有原件完整保存，未形成完整日候选。实测结果。 测试API是OHIPSB02，现有手工XML是酒店57106，二者不能按行或金额作等价比较。 用户最新确认暂时不能访问测试酒店Opera。新增离线来源对照工具及32项测试， 以固定摘要、同酒店日期、唯一内部ID为前提输出独立观察；不自动签发来源等价标记。 真实异酒店输入已正确拒绝比较，详见验证证据。 后续扩充为42项观察/40工具测试，增加公司前缀及费率日人数层级；87项相关测试通过。 XML单独画像发现65条T-、6条C-公司显示值及房号升序，但未证明角色优先或配置的排序； 更新证据。
新增基础层：逐笔字段证据与独立验证 已覆盖完整139笔候选和16列来源，保留所有层级/多值/缺失状态及成功请求出处。16新测试、140相关测试通过， 851原件未变。此处通过的是字段证据完整性，不是下表业务规则；未提供最终XML适配或Web业务验证器。
当前样本覆盖与通过条件
后续新证据：原XML10笔CKOT均有DISP_ROOM_NO且等于LAST_ROOM；API2笔CheckedOut均为零晚/非pseudo， 未返回已知房号字段。异酒店不能配对，但需要核验按预订绑定的历史房号读取；建议平台支持getRoomCalendar 或等价来源，且仍需确定报表选段规则。最小平台清单。 用户再次要求复验后，北京时间22:21原3人POST均200，身份及姓名组成一致、fullName非空，审计一致； nameType未返回，GET未重测。见早期成功回执。 之后全日实测出现间歇性503，当前排查重新打开，见新请求编号。
用户最新确认“Trace不需要”：本次接口输出的Trace明确留空，Trace筛选/部门/日期/顺序不再是交付阻碍。 旧v2档案/原生XML/既有比较测试保留原样；不把历史包含Trace的观察误当成当前输出要求。 排序仍未确认，但原生样本没有房号+到店日重复组；暂不要求用户继续查选项，出现实际业务冲突时再针对性确认。
输出格式的独立基础已完成：明确行值→XML序列化/逐字段验证，13新测试；原生72行经处理得到与基准相同的61行。 这不关闭下表映射项，也不满足完整API ARR可联调里程碑。 新证据另记录：Cloud公司关联列可显示Source； 排序依赖报表配置；旧版共享非主行/组合房存在不同房数语义，当前Cloud必须另外核实，不删除或改写行以绕过校验。
| 验收项 | 已有样本 | 仍需证明什么 |
|---|---|---|
| 到店日有效价 | v2的139响应中134笔价格币种通过（59笔显式0），3笔InHouse隐藏价、2笔NoShow缺详情币种 | searchRateInfo按内部预订ID和系统指定日取detail已实现；仍须核对税/包价、隐藏/缺价在原报告中的表现，逐笔对照有效价。不能用base/total替代，不能把OHIP价格直接变成财务REAL PRICE |
| 日期段选择 | 396个费率段全为start=end；闭区间诊断下139笔各1个到店日段 | 多日段、相邻段、重叠段、无匹配段和换价日。当前样本不足以确定一般区间边界；半开区间会使本样本全部失配 |
| 记录纳入范围 | 139笔覆盖5种状态，含空ETA、仅日期ETA、完整时间 | 同源报告对取消/NoShow、时间范围和空ETA的真实纳入规则；不能把所有请求状态枚举或搜索默认值等同ALL |
| 完整姓名 | 原139详情均唯一主客/Primary，共112个不同档案；v3批量采集/缓存/重放已实现。获准实测触及6个档案，5个姓名成功，最后1个3次503后停批 | 平台间歇性503修复后的完整v3实测及同源报表显示对照；不自行拼接或伪造nameType，不把已取5个姓名当作整日完整 |
| 当前/历史房号 | 74笔当前房号；73笔与到店段相同，1笔仅当前房号，65笔未返回房号（不等于显式空白） | 换房、两个非空候选冲突、历史日报房号和未分房报告行；不能为了通过必填检查预先删除未分房候选 |
| 公司列 | API26个Group关联，24笔有名称；无其他角色。原XML65条T-、6条C-、1空；不同酒店 | Company、TravelAgent、Source、Group并存、缺名与跨日期角色变化时，报告选择/组合及前缀规则。名称和带前缀显示分别比较，不默认Company优先 |
| GEN与内部备注 | API GEN30条分布29笔，1笔2条、3条内部GEN；用户确认准确XML页面Resv.-GEN，对应本文件内部CAS/GENERAL58条 | 页面与正确文件确认已完成，不再询问；同源API数据、内外部GEN/多条次序/空白首条仍待比对。不能将API筛选改CAS或把描述当通用代码；第一条非空全文影响Group Code |
| Trace | 历史API样本7笔12条，4笔多条，存在跨日和同时间并列；12条resolveInfo均为空对象；手工XML15笔31条 | 用户已明确不需要Trace，本次API来源适配将traces设为空元组。历史观察保留；部门、日期、解决状态及顺序不再是当前待验收项 |
| 房号+到店日冲突 | 74笔非空当前房号组成66组；8组各2笔，其中7组费率不同、5组离店日不同、4组备注集合不同 | 报表真实行粒度、物理顺序及保留首条的结果。手工XML没有重复房号，不能证明赢家。统计仅为原始候选碰撞，不是处理器已认定的重复/删除数 |
| 多房、共享、零晚与人数 | 每笔房数1；5笔零晚；7笔儿童>0；139笔入住/到店日人数两层相同；未见明确共享 | 两层相同不能证明一般映射。多房和共享的源行粒度/人数/房数层级仍待验证，不能把多日费率段房数相加。0晚合法，负晚数非法 |
| 可空的展示字段 | 包价代码22笔/30项；房型代码139笔三层相同并已接取值；26笔typed BlockCode与Block ID两层一致，已接选择器 | PRODUCTS多值显示、Block对象缺失113笔及完整同源报告仍需证据；房型冲突不自选。当前房型及26笔Block无需额外字典/getBlock，可空不等于缺失可补空 |
| 采集完整性 | 139详情、前后搜索一致，档案逐字节保留并有SHA-256 | 原始请求参数和全部分页/详情完整；警告/缺页/漂移/空源/部分失败均不能提交整日。重查一致不是原子快照证明 |
必须沿用的处理顺序
- 保留全部源行及物理顺序。缺RATE_CODE无法判断白名单，属于失败，不能被视为非白名单。
- 已知非白名单行记录为排除。每一个白名单候选先校验必填文本、非负整数人数、正整数房数、有限非负有效价、到店/离店日期。
- 候选验证后才按trim后的房号文本+到店日去重；保留首个有效候选。前导零有意义，
0101不等于101。 后续重复候选缺价或缺公司仍会造成整批失败，不能先删重复再校验。 - 对保留行执行固定价格表/已批准归零例外；归零例外也不能豁免源有效价必填。仅纯PRICE_UNMATCHED进入人工复核。
- 完整验证成功后才允许Finance与outbox原子提交；自动重试须复用同一采集批次身份，不能反复创建日版本。
本地字段审计只输出候选统计，不执行上述分类或定价，也不生成处理器outcome。
现有 validate_daily.py 在独立进程中重放，但复用 process_daily.py 的源提取/分类/定价逻辑。
因此将来即使派生XML通过重放，仍须另行核验API→来源字段的映射，不能仅靠后段成功证明适配正确。
当前恢复步骤
- 已完成：真实catalog0.7、推荐POST及请求/响应契约核实，仍属已有reservations.read；本地manifest plan/validate通过，无apply。
- 已完成：本地协议/错误/重试测试、5笔代表样本与139笔整日实测；原件私有归档，851文件验证通过。
- 已完成：按酒店、内部预订ID、系统指定日期关联、v2回放及稳定批次复用；5笔价格诊断保留，不猜价/默认币种。
- 在同源报告条件具备时逐项核对记录集合、字段和顺序，再验证处理结果；金额总计相同不能代替逐项对账。
- 语义明确后确定版本化来源适配、独立映射验证和自动提交/重试方案，再接入运行环境。