摘要

  • 第一阶段要统一开放供应商的公开电价数据；它还不是把某个消费者的专属资费信息交给获授权第三方的后续服务。
  • 供应商专属的 Tariff ID 区分不同价格记录，差异可能来自付款方式、地区等条件。接口能列出记录，但家庭仍需要选中与自己合同对应的那一条。

价格目录可以做得整整齐齐，家庭看到的仍可能是别人的价格。

10 月 30 日，英国能源安全与净零部发布依据《2023 年能源法》第 245(1)(e) 条作出的决定。决定将《Tariff Interoperability API 技术规范》1.0 版纳入 Retail Energy Code，并修改 Energy Market Data Specification 和 Standards Definition Document；改动于 11 月 6 日生效。第一阶段公开 Tariff Pricing Data API 计划于 2027 年 2 月 18 日上线。

政府把第一阶段描述为对供应商公开资费数据的标准化访问，适用于消费者提供供应商和资费信息的场景。边界很清楚：价格目录更容易被机器读取，不等于系统已经连上家庭账户。计划于 2027 年 11 月推出的第二阶段，才是通过与 Consumer Consent Solution 对齐的安排，向获授权第三方提供消费者专属资费信息。

技术文件把匹配问题写进了接口。GET /tariffs/{supplier_mpid} 请求某供应商的资费清单；GET /tariff/{supplier_mpid}/{tariff_id} 请求一个选定资费的详情。Tariff ID 属于特定供应商，用来标识一组价格数据。付款方式或地区不同，可能对应不同 ID。同一个 Tariff Name 可以挂在多个 ID 上，名称也可能恰好等于 ID。看起来最像“名称”的字段，并不一定能证明匹配正确。

记录还带有最后修改时间、生效日期和可销售日期；付款方式、地理分组、电表类型、资费类型也可能影响结果。自动化若只抓到价格，却漏掉其中一项区分，界面可以很干净，合同却可能对错了。这里说的是设计风险：已查阅的官方材料说明了数据结构和计划时间，没有记录家庭已经因错配蒙受损失。

上线验收应要求一份可核对的匹配凭据：供应商 MPID、选用的 Tariff ID、匹配到的条件、生效日期，以及允许该选择的家庭信息。若仍有两条记录都说得通，服务就该追问缺失条件。用户可以质疑一项有解释的选择；一条藏起来的映射则很容易被当成事实。

第一阶段规范了价格如何公开。上线质量还要看系统怎样从这些价格中认出具体合同，以及付账的家庭能不能看懂这一步。

来源