⚠️ 2.4.3 Step 2 – e-Invoice Validation
The change in section 2.4.3 between versions 2.2 and 2.3 is related to how the details of the API response after successful e-invoice validation are presented.
Version 2.2:
"Once validated by the MyInvois System (which is done in near real-time), the Supplier or technology provider (if the Supplier utilises a technology provider) will receive an API response with the following information:
(a) the IRBM Unique Identifier Number from IRBM;
(b) date and time of validation, and
(c) validation link,
via API."
Version 2.3:
"Once validated (which is done in near real-time), the Supplier or technology provider (if the Supplier utilises a technology provider) will receive an API response which contains the following:
(a) the IRBM Unique Identifier Number from IRBM;
(b) date and time of validation, and
(c) information to form validation link (please refer to Get Recent Documents / Get Document / Get Documents Details in the SDK for guidance),
via API."
The changes are:
1. Removed "with the following information" after "API response".
2. Changed "validation link" to "information to form validation link (please refer to Get Recent Documents / Get Document / Get Documents Details in the SDK for guidance)".
The rationale for these changes could be:
1. Removing "with the following information" makes the sentence more concise.
2. Changing "validation link" to "information to form validation link" clarifies that the API response does not directly provide the complete validation link, but rather the necessary information to construct the validation link.
3. The addition "(please refer to Get Recent Documents / Get Document / Get Documents Details in the SDK for guidance)" provides users with a reference to the specific SDK sections that will guide them on how to use the information provided in the API response to properly form the validation link.
This change aims to provide more precise information about the API response content and direct users to the relevant SDK documentation for guidance on constructing the validation link using the information received.
Overall, it clarifies that the API response gives the necessary pieces of information, but users need to refer to the SDK for specific instructions on how to utilise that information to build the complete validation link URL or endpoint.
第 2.4.3 节中 2.2 版和 2.3 版之间的改动涉及如何显示电子发票验证成功后的 API 响应详情。
版本 2.2：
"一旦通过 MyInvois 系统验证（几乎实时完成），供应商或技术提供商（如果供应商使用技术提供商）将收到包含以下信息的 API 响应：
(a) 来自IRBM的IRBM唯一识别码；
(b) 验证日期和时间，以及
(c) 验证链接;
通过应用程序接口（API）"。
2.3 版：
"一旦验证（近乎实时验证），供应商或技术提供商（如果供应商使用技术提供商）将收到包含以下内容的 API 响应：
(a) 来自 IRBM 的 IRBM 唯一标识符编号；
(c) 形成验证链接的信息（请参阅 SDK 中的获取最新文件/获取文件/获取文件详细信息以获得指导）、
通过应用程序接口（API）"。
更改内容如下
1. 删除了 "API 响应 "后的 "以及以下信息"。
2. 将 "验证链接 "改为 "表单验证链接的信息（请参阅 SDK 中的获取最新文档/获取文档/获取文档详细信息以获得指导）"。
这些更改的理由可能是
1. 删除 "以及以下信息 "使句子更简洁。
2. 将 "验证链接 "改为 "形成验证链接的信息"，说明 API 响应并不直接提供完整的验证链接，而是提供构建验证链接的必要信息。
3. 增加"（请参阅 SDK 中的 "获取最新文档"/"获取文档"/"获取文档详细信息"，以获得指导）"，为用户提供 SDK 具体章节的参考，指导他们如何使用 API 响应中提供的信息来正确形成验证链接。
这一改动旨在提供有关 API 响应内容的更精确信息，并引导用户查看相关 SDK 文档，以获得使用收到的信息构建验证链接的指导。
总的来说，它说明了 API 响应提供了必要的信息，但用户需要参考 SDK 以获取具体说明，了解如何利用这些信息来构建完整的验证链接 URL 或端点。
⚠️ 2.4.4 Step 3 – Notification
The removal of the full paragraph explaining the Notification API details in section 2.4.4 could be due to a few potential reasons:
1. Simplification:
The paragraph provided quite detailed information about how the Notification API works, automatically triggering notifications to suppliers and buyers upon e-Invoice validation, and facilitating communication.
Removing this level of technical detail may have been done to simplify the guideline and make it more concise, especially if these specifics are already covered in the separate API documentation (SDK).
2. Avoiding redundancy:
If the Notification API functionality and workflow are already comprehensively documented in the Software Development Kit (SDK) or other technical resources provided to API users, the guideline may have aimed to avoid redundancy by simply referring API users to those dedicated resources.
3. Keeping the guideline focused:
The e-invoice Guideline is intended to provide an overview of the e-invoicing process, requirements, and timelines for taxpayers.
Removing granular API details could be a way to keep the guideline focused on the broader e-Invoicing aspects, rather than delving too deeply into API-specific technicalities.
Overall, the removal of this paragraph could be aimed at streamlining the guideline, avoiding redundancy with dedicated API documentation, maintaining a broader focus on e-Invoicing essentials, and allowing for potential future changes or updates to the Notification API without creating inconsistencies within the guideline itself.
删除第 2.4.4 节中解释通知 API 详情的完整段落可能有几个原因：
1. 简化：
该段提供了相当详细的信息，说明通知应用程序接口如何工作，如何在电子发票验证后自动触发通知供应商和买方，以及如何促进沟通。
删除这一级别的技术细节可能是为了简化指南，使其更加简洁，尤其是如果这些具体内容已在单独的 API 文档（SDK）中涵盖。
2. 避免冗余：
如果向 API 用户提供的软件开发工具包 (SDK) 或其他技术资源中已经全面记录了通知 API 的功能和工作流程，则该指南的目的可能是避免冗余，只需将 API 用户引向这些专用资源即可。
3. 使指南重点突出：
电子发票指南旨在为纳税人提供有关电子发票流程、要求和时限的概述。
删除细粒度的 API 细节可使指南侧重于更广泛的电子发票方面，而不是过于深入地探讨 API 的具体技术问题。
总体而言，删除该段的目的可能是简化指南，避免专用 API 文档的冗余，保持对电子发票基本要素的更广泛关注，并允许未来对通知 API 进行可能的更改或更新，而不会造成指南本身的不一致。
🌻🌻🌻🌻🌻🌻🌻🌻🌻🌻🌻🌻