Visits: 7
The Risk of Unauthorized Code Addition to Standardized Tables
Nobuyuki SAMBUICHI
ISO/TC295 Audit data services/SG1 Semantic model Convener
The United Nations Code List is revised twice a year. The designated contact point for this process is the United Nations Centre for Trade Facilitation and Electronic Business (UN/CEFACT) Japan Committee, represented by the Supply Chain Information Platform Study Group (SIPS). If additional codes are required for JP PINT compliance, it is advisable to follow the official procedure by submitting an application through this contact point for registration.
While Singapore has independently added codes for their own requirements, there are certain issues associated with it. Therefore, the proper approach for JP PINT is to register the codes through the official procedure and utilize them within the JP PINT framework, as this aligns with the intended process.
Generally, it’s not recommended to unilaterally add codes to a code table defined by another standardization organization. Doing so could potentially lead to several problems, such as:
Consistency Issues: Making unauthorized changes to an existing code table could potentially disrupt its consistency with the same table used in other systems or processes. This could result in errors or discrepancies, which may interfere with communication between systems.
Confusion: Freely adding to a code table set by a standardization organization can potentially cause confusion for other entities that use this table. Issues can arise if the added codes are not official and other entities cannot interpret them.
Update and Maintenance Issues: Codes added arbitrarily may not be subject to future updates or revisions by the standardization organization. As a result, this could potentially lead to consistency and compatibility issues.
Loss of Trust: The act of changing the code table without permission could potentially damage trust from the standardization organization and other stakeholders. A decrease in trustworthiness could potentially damage partnerships and result in lost future business opportunities.
Therefore, if there’s a need to add codes, it is recommended to contact the relevant standardization organization and propose changes through the appropriate processes.
In the process of creating standard specifications, it’s common to reference existing standards and make individual modifications or extensions based on requirements. Normally, documents explaining what these modifications or extensions aim to achieve and what they include are made public. However, in the case of PINT, no such standard specification documents exist. Therefore, there is no objective criterion to judge whether newly published specifications comply with PINT.
In the absence of PINT regulations, the standard for OpenPeppol’s eInvoice is defined by CEN/TS 16931-3-2, which also specifies the syntax binding to UBL. For more details, please refer to the linked article.
In this current situation, specifications are simply made public after undergoing an internal approval process within the organization, and there’s no guarantee of consistency with other standards or in terms of future extensibility.
UNTDID 4461 – Payment means
Question:
What potential conflicts or issues might arise with OpenPeppol PINT using their own extension to UNTDID 4461 – Payment means, especially considering CEN/TS 16931-3-2’s process of requesting registration for adding codes from UN/ECE?
Furthermore, what could be the implications if there is a misunderstanding that PINT is independent from the EN 16931 series?
ChatGPT Answer:
Potential issues might arise from the misalignment of the UN/ECE codes, which could lead to inconsistent interpretations and usage. Additionally, the assumption that PINT is independent of the EN 16931 series could potentially lead to overlooking necessary synchronizations between the two standards.
As for resolving these issues, one approach might be to clarify the relationship between PINT and the EN 16931 series, ensuring all relevant stakeholders have an accurate understanding of their interdependencies. This clarification can also address the potential conflicts in the usage of the UNTDID 4461 extension.
Further, it might be beneficial to develop a protocol for integrating the UN/ECE code updates within the PINT extension, taking into account the requirements outlined in CEN/TS 16931-3-2. This could help ensure a consistent and coordinated approach towards using these standards and reduce potential inconsistencies. Finally, improved communication and collaboration between the relevant groups could further mitigate these issues.
CEN/TS 16931-3-2’s process of requesting registration for adding codes from UN/ECE
The Annex A (normative) Code list, A.4 UN/ECE: new code request / code change request in the CEN/TS 16931-3-2 standard might refer to the process for submitting a new code request or code change request to UN/ECE (United Nations Centre for Trade Facilitation and Electronic Business). This typically involves the following steps:
Identify the need for a new code or a change to an existing code.
Prepare a Data Maintenance Request (DMR) detailing the proposed changes.
Submit the DMR via the online submission form available on the UN/ECE’s website.
The request is reviewed and processed by the UN/ECE.
Please note that you should refer to the actual form and procedure on the UN/ECE website for more specific and detailed steps.
