1.  EDI 报文组成部分的设计
    ======================

由于 EDI 报文是由段组成，段又是由复合数据元和数据元组成，其中的代码型数据元又需要有相应的代码支撑，所以在设计报文时，这些组成报文的成分必须能够满足报文设计的需要。在设计 EDl 报文时，应首先查看

《EDIFACT 段目录》、《EDIFACT 复合数据元目录》、《EDIFACT 数据元目录》和《EDIFACT 代码表》，查找一下在这些标准中的段、复合数据元、数据元和相应的代码是否能够完全满足报文设计的需要，如果能够满足需要，即可开始报文的设计。如果不能满足需要，则要看是在哪一级标准缺少所需内容。当查看段目录中的所有段后，认为均不能满足需要时，则可提出设计一个新的段；当查看段目录后，发现有与所设计的报文意思接近的段，但在该段中缺少所需的复合数据元，则可提出设计一个新的复合数据元；当发现某个段中的复合数据元中的数据元缺少时，则可提出设计一个数据元；如果是段中数据元的代码不能满足需要，则可提出追加新的代码。以下对 EDI 报文各组成部分的设计规则作一简要介绍：

1. 段的设计规则

规则 1：一个新段应具有单一功能（如果必要可加限定以标识其使用方法）。一个段应含有足够的简单数据元和／或复合数据元，以实现其功能定义，且其内容必须与段的功能有直接关系。

规则 2：新段不应包括一个已有段的全部内容，也不应重复已有段的功能。

规则 3：应定义一个段中复合数据元和／或数据元的状态（即：必备型或条件型）。

规则 4：应将所有必备型简单数据元和／或复合数据元置于段的开始， 所有条件型简单数据元和／或复合数据元随其后。

规则 5：以字母“U”开始的三字母段代码（即 U..）保留供 IS09735 使用，并规定不能用于数据段中。

规则 6：给限定型段以特定含义的限定符，应以必备型数据元形式作为段的第一个数据元直接置于段代码之后。

例

规则 7：简单数据元或复合数据元在一个段中不应重复，当需要多次重复时，应将段在报文级重复。

规则 8：只有在“新段请求”中能够充分说明业务理由时，相同的简单数据元或复合数据元才能在同一段中重复——最多 5 次，这是由报文设计组议定的。

规则 9：两个或多个不同的复合数据元的组合不应在一个段中重复。例：下述结构不允许

规则 10：在段中增加一个简单数据元或复合数据元时，应将其置于段尾，下述情况除外：

——经批准一个必备型简单数据元或复合数据元批准在段中插入；

——如果标有三年后删除标记的数据元被其替代数据元替代。

如果上述二种之一的修订被批准，将指定一个新的段代码，原来的段将被标注删除标记，三年后删除。

规则 11：所有新的报文都应使用新段。

1. 复合数据元设计规则

规则 1：复合数据元应具有单一功能，其每个成分数据元都与该复合数据元的功能有直接关系。

规则 2：一个复合数据元应包括两个或多个成分数据元，两个或三个一组的成分数据元不能在一个复合数据元中重复出现。

规则 3：应使用已有的 UN／EDIFACT 复合数据元工作目录中包含的复合数据元，否则应证明通过下述两种方法之一仍不能获得所需功能。

——对已有限定型复合数据元增加新的限定符值，或增加新的复合数据元限定符；

——在已有复合数据元的尾部增加成分数据元（规则 16 中定义的除外）。

规则 4：新的复合数据元不应包含一个已有复合数据元的全部内容，也不应重复已有复合数据元的功能。

规则 5：新设计的复合数据元应尽可能支持最广泛的应用。

规则 6：给通用简单数据元以特定含义的限定符应紧跟在该数据元之后，这两个数据元便成为一个复合数据无中的成分数据元。

下例表示了一个复合数据元中这种限定符的位置和使用方法：

例：

规则 7：如果某个单一成分数据元被限定为含有多个成分数据元的复合数据元的一部分，限定符应置于被限定的数据元之后。

例：

规则 8：如果要限定复合数据元（即限定在一个复合数据元中所包含的一组完整的成分数据元），限定符应置于该组成分数据元的开始。

下例表示这种情况限定符的使用方法：

规则 9：复合数据元中的所有必备型成分数据元应置于该复合数据元的开始，条件型成分数据元随后。

规则 10：成分数据元在复合数据元中的重复次数不应多于 5 次，除非指出正当的业理由并经报文设计组同意。

规则 11：

1. 当一对代码型／叙述型数据元中的叙述型成分孜据元的格式定义为 a.. 35

   时，该对数据元叙述型成分在复合数据元中最多可重复二次。

2. 当一对代码型／叙述型数据元的叙述型成分数据元格式定义为an.. 70 时，

   该叙述型成分数据元不应重复使用。

3. 当需要字符多于 70 个时，应在段组中使用 FTX 段代替所涉及的复合

数据元的叙述型成分数据元。

规则 12：在一个复合数据元中增加成分数据元时，应将其置于复合数据元的尾部，下述情况除外：

1. 经批准在一个复合数据元中插入一个必备型成分数据元；

2. 需要在一个已有复合数据元中的一对代码型／叙述型成分数据元之间插入成分数据元

   1131 和 3055。

如果上述二种之一的修订被批准，将指定一个新的复合数据元标记。原来的复合数据元将被标注删除标记，三年之后在下一版工作目录中将删除原复合数据元。

规则 13：所有新报文中应使用新复合数据元。

规则 14：三年期满后，在所有段和与此相关的报文中有删除标记的复合数据元将被新的复合数据元替代。

1. 数据元设计规则

规则 1：使用现有的限定型数据元总是优先于设计新数据元。

规则 2：在 UN／EDIFACT 数据元目录中应遵循下列命名和格式约定：

a）限定通用简单数据元、复合数据元或段的数据元的名称应以“限定符” 结尾（如“货币限定符”）。

限定符的格式为：an..3

限 定 符 代 码 表 只 在 EDCL 中 规 定 。b）非限定符的代码型数据元名称应以，“代码型”结尾（如“货币，代

码型”）。非限定符代码型数据元的格式为：an..3c）其他代码型数据元名称以“标识”结尾（如“危险品代码标识”），

其他代码型数据元的格式应为：an..x（其中 x＞3）

1. 已在 UNTDED 中规定的叙述型的（自然语言）数据元，其名称和格式应与

   UNTDID 中的相同。

2. UNTDED 中没有规定的新的叙述型数据元的格式，可为 an..17，an..

35，成为 an.. 70，与其名称依业务需求而定。 f）其他类型数据元的格式和名称应以满足业务需求而定。

规则 3：作为限定符的代码型数据元不能与数据元 1131／3055 联用。规则 4：其它代码型简单数据元在复合数据元中应与条件型数据元 1131

／3055 结合使用。

EDI 报文的设计

在 EDl 实施应用的过程中对报文的应用将会出现以下三种情况：

1. 已有与应用实际相符的现成的 EDIFACT 报文；

2. 没有与应用实际同名称的 EDIFACT 报文，但 EDIFACT

   的某一报文可以满足应用需要；

3. 在 EDIFACT 报文中既没有与应用实际同名称的报文，也找不到能满

足需要的近似报文。

对第一种情况，只需将此 EDIFACT 报文制定为相应的报文子集即可。对第二种情况，将可满足实际需要的 EDIFACT 报文设计为于集标准，但

需与报文的接收方有协议，说明所传输实际单证的名称。

对第三种情况，只有通过自己设计一个报文，才能满足需要。以下就如何设计报文作一简要介绍。

1．报文设计总体指南

——报文设计应以简单实用为目标；

——报文与段应能供多方使用，而不是局限单一的用途；

——应使用最新的 UN／EDIFACT 目录查阅检索现有的报文和段，以此为起点制定新报文。

——设计报文必须熟练掌握以下标准： EDIFACT 应用级语法规则

EDIFACT 报文设计指南2．设计新报文的前期工作

在设计一个新报文之前应按照如下步骤开展相应工作： 1）分析与业务伙伴有关的往来业务需求；

1. 为业务环境的关键环节建立模型；

2. 确定满足所需业务功能的 EDI

   报文。查证报文是否已在当前使用的或修订过的 UN／EDIFACT 工作目录中存在；

3. 优先制订急需的报文，并为该报文定义“业务功能”，如果在此阶段决定需要一个新的

   UNSM，就必须准备一份“UNSM 请求”，并立即提交给有关的 RT 秘书处进行处理；

4. 确定详细的业务数据需求；

5. 从当前的 UN／EDIFACT 工作目录中选择段并检查在其他 UNSM

   中已使用的段组，以满足每个已标识的项目的需求；

6. 开始设计报文

1. 确定没有包括在现有 UN／EDIFACT 段中的数据项。

2. 确定这些数据项的需求是否可通过对现行使用的段中请求补充限定符的值来满足。若不满足，则检查他们是否在现有的

   UN／EDIFACT 数据元目录或在贸易数据元目录（UNTDED）中已定义。否则，可提出新数据元的更改请求。

3. 确定这些数据项的需求是否可通过把它们加到现有的 UN／EDIFACT

   段或复合数据元的尾部使其具有当前工作目录正确功能而得以满足。

4. 把剩下的数据项分成概念相关的集，为产生新段的每个集提供功能描述，以满足每个功能的要求。

5. 确定每个数据元、复合数据元、段、段组的必备型或条件型状态和允许重复的次数。

1. 报文设计规则

规则 1：报文是以报文头 UNH 段开始，以报文尾 UNT 段结束的一组有序的段和／或段组。报文头段与报文尾段之间至少有一个另外的段或段组出现。

规则 2：现有 UN／EDIFACT 工作目录的内容将作为报文设计的起点。规则 3：提交的新报文不应重复现有报文的功能。

规则 4：报文应根据国际范围使用的要求设计。

规则 5：对已有报文结构所作的任何变更应符合该报文的功能，否则应修改报文的功能使之符合报文结构的变更。

规则 6：报文结构不能有段冲突。

规则 7：每个报文类型都配有唯一的六字母标识符（例 IN-VOIC 代表商业发票）。设计者可自己选定代码，当与现有代码重复时由 RT 技术评审组负责协调。

规则 8：服务段 UNS 将仅用于避免报文的标头节、细目节和汇总节里所包括的段之间的段冲突。

规则 9：一个报文中 UNS 段的设置不得多于 2 次。UNS 段最多重复次数为1 次，其状态为必备型，必要时应置于细目节和／或汇总节的开始。

1. 报文中段冲突的说明

在报文设计时应特别要注意避免段冲突情况的出现。所谓段冲突是指：

1. 在报文中，如果两个或多个具有相同段代码的段之间，没有与之不同的必备型段在同一级或更高级上出现时，将出现段冲突。

2. 在报文中，如果两个或多个具有相同段代码的段之间，没有一个与之不同的段代码作为必备型段组的触发段出现时，也会出现段冲突。

段冲突的示例如图 2．4．1：

图 2．4．1

在上例中，由于单独段 FFF 是条件型的，因此可被省略，单独段 DDD（FFF

段之后的）与段组 5 的触发段 DDD 之间存在段冲突。

段冲突也会发生在紧接在段组 7 之前的独立型段EEE 与段组5 里的段EEE 之间，因为它们之间的段都是条件型的。

如果将单独段 FFF、 DDD、III 和 EEE 移到段组 4 之前，段冲突就可避免。

段冲突会使接收翻译器路径错误地把它们合并为相同的段，而造成数据的丢失。因此设计报文时，一定要避免出现段冲突。