控制数字背后的概念非常简单，但要在实践中使用它们，您需要了解很多细节。例如，交换控制号是交换的唯一标识符，您可以使用它来确认您收到了交换。在实践中，它仅在一定范围内是唯一的，无论标准如何，贸易伙伴都可能对他们有自己的期望，并且在致谢中使用它们并不常见。所有这些都是假设您知道什么是数据交换。
X12 EDI 标准指定了有关控制编号的许多内容，但它可能不像您期望的其他标准那样具体。即使有，也不是每个人都完全遵守该标准。不要与之抗争;你只会感到沮丧。相反，让自己专注于控制数字带来的所有扭结、怪癖和怪异。保持理智的最好方法，就是拥抱疯狂。
三种不同的控制编号
EDI 消息具有三个不同的控制编号：交换控制编号interchange control number、组控制编号group control number和事务集控制编号transaction set control number。每个控制编号出现两次：一次在开始段中，一次在结束段中。
交换Interchange、功能组functional group和事务集transaction set
交换会告诉您消息在组织级别发送给谁。如果您正在为 Exactity 工作，并且收到来自 Claritude 的消息，则 ISA 段会将 Claritude 标识为发送方，将 Exactity 标识为接收方。
功能组告诉您消息在部门级别是针对谁的。如果来自 Claritude 的消息同时包含发票和发货通知，则一个 GS 段将标识您的财务部门为发票的接收方，另一个 GS 段将标识为仓库部门为发货通知的接收方。在实践中，功能组并不总是这样使用的，我们稍后会看到。
事务集表示单个文档。如果财务部门一次收到三张发票，则 ST 段中的交易集控制号将很容易将它们分开。这似乎是多余的，因为发票已经包含发票编号，但这两个编号的用途不同。控制编号是一个技术标识符，仅供 EDI 系统使用。发票编号是企业使用的标识符。
为什么我们需要不同的控制编号
当您收到来自贸易合作伙伴的消息时，您可以通过发送确认来告知他们。一种选择是确认您收到的每个交换。您发回一条包含 TA1 分段的消息，并将交换控制编号放入其中。TA1 段还包括一个代码，可以让您的贸易伙伴知道是否有任何问题，但您不能那么具体地说明出了什么问题。例如， TA1-segment 无法指示其中一个事务集无效。
另一种选择是确认您收到的每个功能组，这为您提供了更多的粒度。您为每个功能组发送 997 功能确认，并包含组控制编号。然后，添加有关每个事务集的信息，引用事务集控制号并包含相关的错误信息。
但是，如果你在确认一个功能组时可以包含所有这些，那么确认一个交换似乎是多余的。在大多数情况下，这是正确的，但有两个例外。
首先，您收到的 ISA 段可能包含错误。ISA 段提供解析 EDI 消息的其余部分所需的信息。如果该细分出现问题，您将永远无法访问功能组。报告该情况的唯一方法是使用 TA1 分段并包含交换控制编号。
其次，您不能在同一个系统中处理整个消息。如前所述，功能组允许您将消息的各个部分路由到不同的部门。如果每个部门使用不同的软件，则可能有一个设置，其中所有 EDI 消息都进入一个中央系统，该系统只将消息路由到正确的部门。中央系统根本不查看事务集;这是由每个部门的软件单独完成的。
在此设置中，每个部门都会为他们负责的事务集发送 997。中央系统无法执行此操作，因为 997 必须包含有关事务集的信息，而中央系统不处理这些信息。如果遇到错误，唯一的选择是发送带有 TA1-segment 的回复。
当然，您的情况可能不需要路由到单独的系统，如果您可以对所有事情都使用组控制编号，而忘记所有交换控制编号，您会更开心。但是，您不能这样做，因为您的某个贸易伙伴可能需要额外的抽象层。即使您确定情况并非如此，这仍然是 EDI 的工作原理，您必须处理它。
技术上正确
X12 EDI 的标准对控制编号有相当多的评价。其中一些规范清晰而精确，有些精确但难以理解，还有一些（故意）含糊不清。结果是，您总是会遇到不符合标准的控制编号，但在我们讨论之前，最好先了解一下标准的内容。
数据类型Data type
当涉及到控制数字的数据类型时，该标准是明确的。
控制 number数据类型Length，interchange integer 正好 9， group integer 最多 9，transaction set string至少 4 , 最多 9,尽管这可能毫不含糊，但它仍然值得一些研究。
交换控制编号的长度必须正好为 9 个字符。这样做的原因是 EDI 解析器依赖于 ISA 段具有固定长度这一事实。不满足最小长度的数字必须用零填充，因此交换控制数字如下所示。000000014
组控制编号没有最小长度。仅当数字需要满足最小长度时，才适合用零填充数字，因此组控制数字不应包含任何数字。
事务集控制编号在两个方面是特殊的。首先，它的最小长度为 4，没有明显的原因。其次，它是一个字符串，而不是一个数字。空格是字符串的有效字符，零也是，因此从技术上讲，以下示例都是有效的事务集控制编号：0001, 0 1, 1, yolo 。
唯一性Uniqueness
控制编号必须是唯一的，但只能在特定范围内。该标准对此有具体规定，但很容易被细节所迷惑。
控制编号在交换方面唯一ISA05 和 ISA06（发送方）
ISA07 和 ISA08（接收方）
GS01（功能标识符代码）
GS02（发送方）
GS03（接收方）事务集包含功能组
交换Interchange
Exactity 发送给 Claritude 的每个交换都必须具有唯一的交换控制编号。当然，Claritude 发送给 Exactity 的每个交换也必须具有唯一的交换控制编号，但 Claritude 不必考虑从 Exactity 收到的交换控制编号。换句话说，如果 Exactity 发送带有控制编号的交换，而 Claritude 发回带有控制编号的交换，则这是完全有效的。000000001000000001
ISA 段包含发送方 （ISA06） 和接收方 （ISA08） 的标识符。问题是：谁分配了这些 ID？ISA 段使用 ID 限定符回答这个问题：一个用于发送方 （ISA05），一个用于接收方 （ISA07）。限定符告诉您正在处理的 ID 类型。例如，如果限定符是 01，则 ID 是 DUNS 编号，但如果限定符是20 ，则 ID 是健康行业编号。因此，ISA05 和 ISA06 的组合标识发送方，ISA07 和 ISA08 的组合标识接收方。
功能组Functional group
组控制编号在发送方和接收方的上下文中也必须是唯一的，但功能组的发送方和接收方的定义与交换的定义略有不同。GS 段不包含限定符，让您知道您处理的是 DUNS 编号、健康行业编号还是任何其他类型的 ID，这是有道理的。
回想一下，功能组的用途是在组织内路由事务集的集合，例如，将发票发送到财务部门，将通知发货到仓库部门。Element GS03 标识接收器，但在本例中，接收器不是 Exactity，而是 Exactity 中的一个部门。这没有行业标准，所以 Exactity 和 Claritude 只需要达成协议。但是，就标准而言，Exactity 和 Claritude 决定识别功能组中的发送方 （GS02） 和接收方 （GS03） 是可以的。
组控制编号的唯一性还有另一个元素：GS01。此元素包含功能标识符代码，它告诉您功能组包含什么类型的事务集。例如，该代码用于发票或发货通知。因此，如果 Claritude 向 Exactity 发送一个包含发票的功能组IN和一个包含发货通知的功能组SH，则允许它们具有相同的组控制编号。
事务集Transaction set
事务集控制编号在其功能组中必须是唯一的。如果 Claritude 发送两张发票，则每张发票必须具有唯一的控制编号。如果 Claritude 稍后发送另一张发票，则可以重复使用以前的控制编号;该标准不要求事务集控制编号在消息中是唯一的。
回收控制编号
由于控制编号具有最大长度，因此您有可能用完它们。在 Claritude 向 Exactity 发送了 10 亿个交换后，他们无法再为下一个交换选择唯一的控制编号，同样的情况也适用于组控制编号。您可能有兴趣知道，如果您每秒发送一个交换，则需要 30 年以上的时间才能用完交换控制编号。尽管如此，该标准还是为这种可能性提供了解决方案。
嗯，差不多。它告诉您控制编号需要在合理的时间范围内保证唯一性。它继续说，该时间范围的边界应由贸易伙伴协议定义。这是一种花哨的说法，您和您的贸易伙伴需要自己解决这个问题。
现实
了解标准只是理解控制编号过程的一部分;您必须了解它们在现实中的使用方式。
顺序控制编号
EDI 系统通常按顺序和连续生成控制编号。虽然标准没有要求，但许多贸易伙伴会认为您遵循这种做法。他们会期望在交换控制号码000000001出现后发送000000002。如果您发送了他们000000009，他们可能会就缺失的 7 个交换。
组控制编号和事务集控制编号也是如此：它们不必是连续的，但它们通常是连续的，并且一些贸易合作伙伴希望它们是连续的。
当您的贸易合作伙伴将每个职能组路由到单独的部门时，情况会变得更加复杂。如果 Finance 部门检查缺口，而 Warehouse 部门检查缺口，则所有功能组的单个计数器是不够的。您需要考虑功能组标识符，并向每个部门发送连续的组控制编号。
当然，也会有一些贸易伙伴不以这种方式工作。当您向他们发送发票的组控制编号 1、 2、 3以及发货通知的 1、 2、 3时，他们会抱怨您向他们发送了重复的控制编号。
简而言之，您必须与您的贸易伙伴讨论这个问题并了解他们的期望。
数字和前导零
仅当 0 对于满足最小长度要求是必需的时，才应用 0 填充数字。尽管如此，您还是会看到许多包含前导零的组控制数字。
通常，发生这种情况是因为贸易合作伙伴复制了交换控制编号并将其用作组控制编号。如果他们从不在交换中放置多个功能组，这是有道理的。如果您已经有一个适合所有约束的控制编号，为什么还要生成一个单独的组控制编号呢？嗯，除了前导 0 之外，所有都关心这些，但只有学究才关心这些。
事务集控制编号的最小长度为 4，因此一般预期是它们包含前导零。从技术上讲，它们不必这样做，因为它们不是数字;它们是字符串，并且字符串可以有空格。实际上，大多数人假装事务集控制编号不是字符串而是数字，因为无论标准怎么说，这都更有意义。
您最安全的选择是接受您收到的控制编号中的前导零，并且仅在您发送的控制编号需要时才包含它们。
唯一组控制编号
如果您记得，组控制编号只需要在功能标识符代码的上下文中是唯一的，即发票组可以与船舶通知组具有相同的控制编号。但是，并非所有 EDI 系统都以这种方式实施，而那些不是这样实施的 EDI 系统需要发票组和船舶通知组具有不同的控制编号。
这与我们之前讨论的序列控制编号问题密切相关，结论是相同的：您必须与您的贸易伙伴讨论这个问题。
回收控制编号
理论上可能有 10 亿个唯一的控制数字，但这并不意味着您的交易伙伴会使用所有这些控制数字。有时，他们的 EDI 系统的更改会提示他们重置控制编号生成器。忘记三十年来一秒钟收到一条消息;你现在得到的是重复的。
如果您可以容忍接收重复的控制编号，请容忍。如果您可以严格要求在回收之前发送所有 10 亿个控制编号，那么请严格要求。在实践中，你的宽容程度是有限的，你的严格程度也是有限的。正如标准所说，您和您的交易伙伴需要一起弄清楚什么是合理的时间框架。
接受
控制号码可能会令人困惑。有很多讨厌的细节和很多不一致的地方。您能做的最好的事情就是严格控制您发送的控制号码，并宽容您接受的控制号码。如果这还不够，请与您的贸易伙伴交谈，但不要费心指出从技术上讲他们是错误的。他们的业务有需求，就像您的一样，他们的系统也有怪癖，就像您的一样。现实是混乱的。随它而去。
评论 (0)