0

该UNB段包含作为最后一个元素的交换控制引用。文档说它必须是唯一的（例如，参见UN/EDIFACT 语法规则）：

 ___________________________________________________________________

 0020   an..14  M  INTERCHANGE CONTROL        Unique reference
                   REFERENCE                  assigned by sender
 ___________________________________________________________________

还包含发件人 ID 、UNB收件人 ID、日期和时间。

现在......在什么情况下交换控制引用必须是唯一的？它由发件人分配。那么，对于相同的发件人 ID 还是对于发件人和收件人 ID 的组合而言，它是唯一的吗？

比如说，如果发件人使用更多系统来发送消息，那是否应该反映在发件人 ID 中？比如说，如果发生了一些严重的硬件故障，新硬件是否应该使用不同的发送者 ID 来确保交换控制参考的唯一性？

4

2 回答 2

1

参考号、发送者 ID 和接收者 ID 的组合必须是唯一的。参考编号通常是为发送者 ID\接收者 ID 对按顺序生成的。

许多应用程序内部使用一个简单的表，以发送者 id\接收者 id 作为主键，以及一个递增或设置为 0 的参考编号列。

通常的重置时间是 30 天，之后您可以开始重新使用相同的参考编号，但这会因应用程序和贸易伙伴而异。

有时将目标系统配置为通过这三个值检测重复项，因此如果您多次发送同一个交换，则所有后续交换都将被拒绝。

于 2019-10-09T20:17:21.133 回答
1

交换控制编号在特定的发送方/接收方对之间必须是唯一的。

通常，这被处理为一个计数器，每次交换都会递增。有时，发件人维护一个用于所有发件人 ID 和所有收件人的单个计数器，有时为每个发件人 ID/收件人 ID 对设置一个单独的计数器。有时，他们可能会为每对间隔 500000 左右保留两个柜台（例如，当多个系统生成不同的交换时 - 例如外包仓库，或者如果保留每个收件人的柜台不可行，则在升级到新系统后）。

当发件人确信在一秒钟内编码的每个收件人（或一毫秒内的任何收件人）永远不会有超过一次交换时，我还看到了用作交换控制号的日期和时间编码。

在实践中，如果控制编号相隔 3 个月或更长时间，重复控制编号会导致问题是非常不寻常的，而且我见过的大多数方案都会在计数器翻转之前持续一年多。例如。取 POSIX 时间戳的最后 9 位数字（到 100 秒）将保证大约 4 个月内不会重复（只要在前 100 秒内与同一收件人不会有超过一次的交换）和可能会使重复的机会在很多年内都消失得无影无踪。如果您将其改为 10 分之一秒，则可以保证 3 年以上没有重复。

您是否正在解决您的顽固客户拒绝您发送的交换，或者他们发送您标记为重复的控制号码的情况？我处理这些情况的方式完全不同（并且还取决于您的组织的僵化程度）。

我曾经（幸运的是）看到一位客户坚持认为特定发送方/接收方对之间的所有交换控制号不仅是唯一的，而且是连续的，并且这些交换中的消息控制号也必须是连续的，并且格式为带有前导的四位数字零，并且在每次交换中始终从 0001 开始。EDIFACT 标准不支持这些附加要求，但这是在该客户的消息实施指南中，并且它们足够大，可以坚持要求其供应商遵守。

于 2020-05-01T02:45:05.933 回答