ANSI X12

ANSI X12是由美国国家标准委员会在1979年创立的认可标准委员会（ASC）X12制定的EDI报文标准，是为了满足商务文档之间的电子数据交换。

EDI X12(电子数据交换)是基于ASC X12标准的数据格式。它主要用于两个或多个交易伙伴之间进行数据交换。术语“trading partner(交易伙伴)”一般表示组织，群体组织或一些其他群体。很多情况 下，它仅表示某个组织或公司。而且，你会发现，很多计算机程序也用到了“trading partner”这个术语，该程序是执行双方数据的通信。

EDI X12是由ASC X12(The Accredited Standards Committee)发布的标准。每次发布包括一系列的信息类型，比如invoice、purchase order等。每一个信息类型都有特定的数字代替它的名称。比如，an invoice是810，purchase order是850。

每次新版本发布，都会有对应的版本号，比如版本号：4010,4020,5010等。大版本的发布的版本号是从起始数字开始的，比如4010是大版本的版本号，5010亦是。而4020便是对应的小版本的版本号。小版本的发布是基于大版本作了小的变动或更新。

结论：若想翻译EDI X12数据，你需要知道交易号和发布的版本号。以上数字都会出现在EDI文件中。

标准EDI X12格式数据类似文本文件，被segment、element和sub-element分隔符分开。可以用文本编辑器(如Notepad)打开EDI X12文件。在EDI X12标准中，是不需要回车和换行字符的。如果它们不存在文件中，在每个segment分隔符之后你会看到一连串的数据出现在文件中。该种情况下是很难读取数据的。换个说法，如果我们查看包含回车字符和换行字符的文件，那每个segment都会在单独的一行。

观察上例，每个segment都显示在单独一行。该例每行都是以~（波浪字符）结尾，这就是所谓的segment分隔符或segment边界符。每个segment都是2~3个字母开始，比如：ISA、GS、ST、BHT都是segment标识。每个segment都包含着由元素分隔符分隔的元素。如上例中的*（星号）。

然而在上述的例子中所出现的分隔符都是可打印字符，如波浪号和星号，尽管它们不需要被打印出来。它们也可是其他的字符，如<,>（大于号或小于号字符），亦不需要被打印。从接收的EDI X12文件中中，大多数翻译工具是可以检测出分隔符的。

一些segement形成了EDI X12包络。对于所有的EDI X12文件和信息类型来说，都是普遍易见的。那些segements分别是ISA、GS、ST、SE、GE、IEA.这些包含了关于交易伙伴重要的信息（如Sender Id,Receiver Id等等）。也包含了交换和交易控制数，计数，传输日期和时间，甚至更多信息。

在文件的开始，有传统的EDI X12包络段。

在文件的结尾，也有传统的EDI X12包络段。

包络段都是成对出现的。ISA-IEA代表一次交换。GS-GE是一组内部交换和ST-SE是组内的交易。

以上有三个包络层。每一次层可重复多次。

segment标识符。基于segment标识符，我们基本可以了解到文件中都包含了什么数据。

有些segments可能会重复多次。很多情况下，他们都有不同的限定符，便于识别。举个例子：文件中有多个NM1。某些可能位于同一水平线上（同一循环）。但是每个NM1都有它自己的限定符，即第一个元素。所以NM1*41和NM1*40包含着不同的信息。

控制码

包络的每一次都包含具体的控制号码。处理软件能够根据控制号码来判断交换、交易的成功与失败。Acknowledgements(997)使用控制码来反馈处理结果。

对于交换、组和交易，文件中有控制号码。

控制码有特定的格式和长度要求。它们必须是唯一的。它们不需要依据EDI X12的标准排列顺序 ，但是一些交易伙伴可能会提出更严格的规则，以便追踪数据交换。

交易码

交易码或信息数字名称，总是作为ST segment的第一个元素出现。有时，一个EDI X12文件可能包含多种交易码，并且那些交易码是不同的。比如，它可能包含invoices(810)或者purchase orders(850),以及ackonwledgements(997)。

ST segment的第一个元素便是交易码（信息数字名称），即837。

规则和缺陷

EDI X12旨在两个系统的相互通信。虽然很多软件厂商遵循EDI X12的规则，但是仍有钻空子的。我们称这种情况为“缺陷”，因为大多数问题都不是不可解决的。下面列出一些典型的实施缺陷。有些列出的案件可能不属于规则明确的缺陷，但你会发现它们很惹人厌。

• 例1：来自于大型机或旧系统的EDI X12数据，在80个字符那里截断。在数据被翻译之前，通过消除回车和换行字符便可解决。
• 例2：文件没有预定义的大小限制。典型的文件范围是5 Kbt到5 Mbt。发送1Gbt文件不算打破规则，但是有多个较小的文件就不可以加快处理。基于接收文件的大小，很多软件包可以分配内存。在同一台机器上，超大文件会使处理系统内存溢出或让其运行很慢，减少其他服务或程序的内存。
• 例3：EDI文件应该有包络段的ISA，GS，ST，SE，GE，IEA。你可能会碰到一些来自交易伙伴的文件，但那些文件并没有被提及到那些包络段。这是因为交易伙伴之间认为，你知道那些段，所以没有提到。只有组织内部使用的EDI文件可能不包含ISA，GS，ST，SE，GE，IEA段。因为VAN或者第三方网关执行所有文件，预处理和路由，并可能被其关闭。这不算一个错误，但是很多压缩的EDI软件包将不能处理丢失包络的文件。它们会认为EDI数据是无效的。

什么是无效的EDI X12文件？

使用编辑器（如Notepad）打开EDI文件后，感觉看似神秘。但是所有有效的EDI文件都有着相同的特点：

1. 它们都是以“ISA”三个字母开始的；
2. 106个字符之后就会出现“GS”。有时“GS”会出现在文件的第二行。如果“GS”出现在第二行，那么在“ISA”和“GS”之间可能是108个字符（有两个非打印的回车和换行符）。
3. ISA段有106个字符，有时会更长。在段结尾处（波浪符之后），如果使用~波浪符、回车符和换行符作为分隔符，甚至会有108个字符。

根据以上信息，很多翻译工具可以阅读和解析EDI文件。最常见的问题是：为什么翻译工具不能处理文件？

1. 不是EDI X12文件。或许，它是平面文件，XML或扫描件或其他的，但不是EDI文件。
2. 在很多情况下，如果你能从互联网浏览器窗口复制和粘贴EDI文件，那这个EDI文件将不再有效。这是因为空格是无法显示在互联网浏览器上的。那么在ISA和GS之间，而不是103个字符，可能会更少。
3. 通常EDI文件发送时，会使用加密/解密通信的安全连接。有时候会直接在EDI文件进行加密。加密留下的ISA/GS部分有效，但在该文件中的所有段将会不可读。只有EDI文件将正确解密，才可以正确的读取。
4. 一些EDI文件来自大型机系统。有时它们会被格式化为80个字符。另外的回车和换行符，会把EDI分解成多个，导致文件无效。

5. 少有的EDI软件通信包结合各种类型的EDI信息，写入到一个文件中。有两种不同的组合方法：

   • 例1：在文件中，810 invoices 和997 acknowledgement在同一分隔符内。这种EDI文件是有效的，但是翻译工具的输出可能是不对的。比如：把EDI文件翻译成平面文件，将会分解EDI循环以至于彼此之间独立（依据上面的例子，810 invoice需要单独重复，跳出997循环）。
   • 例2：在文件中，810 invoices 和997 acknowledgement 在不同分隔符内。这是不可能通过翻译工具处理的。通常，在文件的开头翻译工具检测出分隔符。在文件中，如果分隔符作了位置变动，而翻译工具则继续处理文件，依旧使用文件开始处检测的旧分隔符。当不同的EDI信息混合出现在一个文件中，该文件会使用不同的分隔符，此种情况比较罕见。但我们可以列出那些不能被处理的文件。

HIPAA

1996年，美国国会颁布了The Health Insurance Portability and Accountability Act(HIPAA),尚没有确切的正式中文名称，国内文献一般直接称为HIPAA案，有的称：健康保险携带和责任法案，也有取其意的：医疗电子交换法案。其目的是：Administrative Simplification(简化管理)，以降低日益增长的医疗费用开支。

主要的EDI报文是：

837：医疗索赔 820：薪资扣除，另一组保险费用缴纳的保险产品 834：福利登记和维护 835：电子汇款 270/271：资格查询和响应 276/277：索赔状态的查询和响应 278：医疗服务审查请求和应答

X12协议都支持上述的报文格式。

从本质上讲，它们是EDI X12 4010或5010版本的报文。标准的EDI X12规则适用于HIPAA以及HIPAA的EDI X12报文。

偏差是标准吗？

虽然EDI X12格式是基于标准的，但标准也是有偏差的。有些偏差是很常见的，但它们已被视为标准。最好的例子就是EDI X12 837医疗索赔。按说只有一个EDI X12 837。但是由于制度和专业的医疗索赔等不同的要求，就出现了837的子集，如：837I,837D及837P。你可能需要接触到的很多交易伙伴，都会给你提供他们自己的文档，即“Companion Guide”。这些额外的文件，列出了具体的要求以及他们的业务需求。

为了解决这些偏差，很多独立的软件供应商发布他们的产品与编辑器、映射器、映射工具等。对于您的要求，工具支持灵活的定制、翻译的映射和验证规则。其他一些偏差是EDI X12的835,834,810,850,855。由于复杂的信息结构规则，将有可能出现更多的偏差。

实施是什么意思呢？这些偏差有什么联系呢？让我们以837为例。着重了解到，对于贸易伙伴来说，EDI X12 837的每一个都是独特的。是的，它们都是基于837标准。是的，它们主要是针对特定的行业：837P，837I，837D或者更多。所以，你在逻辑上假设它们都是相同的。如果您从两个不同的交易伙伴取得EDI X12 837S，你会发现彼此之间有多个不同的段。这意味着在大多数情况下，你需要去实施，包括每一个细节。

注：文案部分图片及内容来源于网络，版权归原创作者所有，如有侵犯到您的权益，请您联系我们进行删除，给您带来困扰，我们深感抱歉。

本文由知行软件原创。

版权声明：请尊重原创内容，如需转载本文章，请注明文章原始地址。