7.1 KiB
ARR 原生 XML 交付：候选路线与一次验证
状态更新：停止推进，仅保留历史研究。 用户明确要求从操作要素映射平台接口，不转为页面操作/计划报表/SFTP。 下文验证草案未执行，也不再是需要用户配合完成的下一步。当前方向见 接口研究范围纠正。
2026-09-16。研究结论和验证草案，尚未选择或部署 SFTP 路线，也未创建 Opera 计划报表。 用户曾确认可以看到 Schedule Report / Manage Scheduled Reports 入口；XML、SFTP选项及接收位置未核实， 此分支停止后不再要求用户查看或配合配置。
这次确认了什么
当前 Edge catalog 和 OpenAPI 又作了完整回读：仍为0.6.0，两个文档的 data 与上次快照完全相同。 目录111个业务操作，完整OpenAPI152个操作（包含其他服务路由，两个数量不是新增差异），仍无原生报表入口。
Oracle 官方演示直接选择 Arrivals: Detailed 建立计划报表，说明这个报表支持调度；演示实际用的是PDF邮件。 另一本26.2用户手册明确列出标准计划报表的XML格式和SFTP交付，因此“原报表XML投递”是有依据的候选， 但还没有证明本酒店该报告的XML/SFTP组合已启用并成功交付。 来源：Arrivals: Detailed调度演示、 标准计划报表。
候选链路是：Opera按原参数生成XML → 投递至受控SFTP目录 → 取回完整原件 → ARR现有处理/校验/Finance/月报。 若继续保持“通过平台接口取文件”的接入方式，可由平台接收SFTP文件，再向ARR提供带鉴权的原文件读取接口。 这部分是待讨论的实现建议，当前没有对应Operation ID，也没有在ARR中增加SFTP客户端或假造下载URL。
当前只需查看的两项
打开ARR对应的计划报表向导，查看Destination步骤，先不点击Save：
- File Format是否可以选择XML。
- Mode是否有SFTP；其下是否已有可选的服务器/目标文件夹。
没有入口可能是功能或角色权限问题；现在用户确认入口可见，但这不证明有创建/配置权限。 Oracle列出的前置条件包括General下Scheduled Reports功能及Reports下Manage Scheduled Reports任务。 来源：计划报表前置条件。
接收位置明确后的单次验证草案
以下是待用户选择这条候选路线、接收位置与运行时点明确后才执行的步骤；本轮没有保存或运行计划。
| 项目 | 单次验证设置 |
|---|---|
| 报表 | 用户正在使用的Arrivals: Detailed；确认酒店与手工原件来源一致 |
| From / To Date | 首次可固定为2026-09-15，匹配已收到样本；直接使用明确日期，不用营业日偏移 |
| 原有筛选和显示 | 保持源报表契约中的ALL选项、00:00–23:59、房号、Resv. - GEN和内部备注；排序/Trace与手工基准一致 |
| Recurrence | Once Only；运行时点在实际执行前确定，不先建立长期重复任务 |
| File Format | XML |
| Destination | 经确认的SFTP服务器和ARR专用文件夹；已有位置也须确认用途/接收方，不能盲选 |
| 文件名 | 使用便于关联这次验证的唯一名字，例如ARR_20260915_trial01；不假定日期占位符、扩展名或覆盖规则 |
| 执行证据 | 保存实际参数、酒店/环境、计划与执行标识、生成/交付时间及成功状态 |
文件到达后先保留原始字节和hash，再通过比对工具检查完整源记录和顺序。 已收到的57106样本不能直接与OHIPSB02测试数据逐笔比较。两次导出间业务事实可能变化，差异需结合时点解释； 必要时针对同环境同日期补一份相邻时点手工导出，不能为了通过比对修改XML或删除差异。 之后用现有固定处理器和独立校验验证候选结果；本次试验先保留本地结果，不将生成成功等同于Finance提交。
平台需要提供的接收条件
- 明确接收方和环境、SFTP主机/端口、服务器Host Key、认证方式、专用目录及文件保留/覆盖策略；凭据单独安全交付。
- Opera中配置相应SFTP目的地并验证目录；主机需先加入Outbound Domain Allowlist。 已有可用目的地可以核实后复用，缺少时由具备相应权限的酒店/平台管理员配置。 来源：SFTP目的地配置。
- 出站域名放行由有Approve Outbound Domain Allowlisting权限的人员审批；配置需达到Ready。 这是Opera产品自身的前置条件，不是ARR应用的reservations.read权限能够替代的能力。 来源：出站域名放行。
- 若平台再提供HTTP下载：明确文件标识与酒店/到店日/执行记录的关联、完整性与交付完成信号、鉴权范围及重取语义。 路径/请求体/能力组等待真实平台契约；当前不扩权、不编写依赖虚构接口的客户端。
- 接收程序必须区分完整交付和上传中/失败文件。大小暂时稳定或能解析XML不独立证明报告业务集合完整。 文件名不承担唯一身份或完整性证明，未知执行结果也不能通过重复创建计划来恢复。
每天自动化前仍须解决的日期口径
用户要求的是日历昨天；Oracle文档中的计算日期以营业日为基准，并提供Validate Date。 例如日历已到9月16日而营业日仍是9月15日，营业日减一会得到9月14日，和用户要的9月15日不同。 单次固定日期验证可绕开这个歧义，但不能证明每天自动选择昨天正确。
后续应核实实际可选Date Option、酒店时区及夜审行为；若只能依赖营业日偏移，必须在生成/接收时核对 文件日期确实等于目标日，错误日期进入失败处理而不是照常入库。错日报/缺日报的恢复方式须能取得正确日文件。 用户没有确认定时执行时点、空日或补跑策略，这些仍未实施。
本轮取证
- 只读回读时间：2026-09-16T06:42:23.186360Z（上海14:42）。两次CLI均退出0、ok=true、HTTP200。
- catalog request ID：
fe792857-380e-49d4-9170-b366d8bdbd90。 - OpenAPI request ID：
e75e4a03-7a92-4f62-9ed4-281dead699aa。 - 快照及摘要：
/Users/chillishark/Downloads/arr-native-download-followup-dxgl2kqe/，目录0700、JSON0600。 - 用户明确回复“能看到入口”；随后已询问XML/SFTP/接收位置，尚未收到这些信息。
- 可操作浏览器清单中没有Opera页面，因此未操作用户Opera会话。没有业务调用、计划创建、文件外发、权限变更或部署。