EPCIS 和 CBV 实施指南

EPCIS标准规定：

■ 可视性事件数据的数据模型和伴随的使用可扩展标记语言（XML）的可视化数据具体语法；以及

■ 开放、标准化的接口，其允许在公司间以及公司内部无缝集成规定明确的服务。EPCIS标准中规定了两种接口：

□ 采集接口，通过此接口，符合EPCIS数据模型的可视性事件数据可以从采集应用传送到接收器（通常为EPCIS数据的持续存储库）；以及

□ 查询接口，通过此接口，商业应用或贸易伙伴可以请求并获取EPCIS事件数据。

EPCIS标准中规定了标准接口，使得能够使用规定的一组服务操作和相关数据标准来采集和查询可视性事件数据，所有操作和标准均将结合适当的安全机制，以满足用户公司的需求。在多数或大多数情况下，这需要使用一个或多个可视性事件数据持续数据库，但是也可以直接连接采集和查询接口来实现应用间的直接共享，而无需使用持久数据库。

EPCIS旨在与GS1核心业务词汇（CBV）标准[CBV1.2]结合使用。CBV标准提供了可用于填充EPCIS标准中规定的数据结构的数据值定义。使用CBV标准提供的标准化词汇对于互操作性至关重要，并可减少不同企业表达共同意图的方式差异，从而方便进行数据查询。因此，采集应用应尽可能多地使用CBV标准来构建EPCIS数据。

EPCIS数据旨在增强信息系统的可视性，使用户了解对事物进行处理的业务过程中的事物当前（以及先前）位置。下图将给出简单的业务过程，显示了EPCIS数据的生成位置。

图2-1显示EPCIS数据生成的简单业务过程

上图给出了简单的业务过程，在该过程中，制造贸易项目，并将其运送到配送中心，随后该配送中心接收后运送到零售店，零售店接收后转移到销售区域。可将整个业务过程视为一系列独立的业务步骤：产品包装、装入货运包装箱、装运、接收等等。EPCIS数据可以提供所有这些步骤的详细记录。描述一个业务步骤完成的EPCIS数据单元称为EPCIS事件，EPCIS事件集合提供了业务过程随时间和地点变化的详细信息。

例如，单个EPCIS事件记录配送中心收到一批货物。此事件的信息内容分为四个维度：

■ 内容 有关收到何种贸易项目和／或货运包装箱的信息

■ 时间 接收日期和时间，以及有效的当地时区

■ 地点 收到货物的地点，以及事件发生后，项目预期所在地点

■ 原因 有关业务环境的信息，包括：

□ 业务步骤属于接收操作（而不是装运或其他业务步骤）。

□ 货物通过供应链获得正常进展（而不是被退回）。

□ 有关装运方和接收方以及先前和当前所有方（若不同于装运方和接收方）的信息

□ 相关业务事务文件的链接，例如采购订单、发票、发运通知（又名提前装运通知）等

图中所示过程中的每个业务步骤都可能是EPCIS事件的来源每个事件的内容详情取决于业务步骤，但均具有相同的四维结构。

EPCIS可以集合在不同时间，以及贯穿整个业务过程和／或供应链中记录的个别事件。其范例包括：

■ 查找给定对象的最新EPCIS事件，了解其当前位置以及其所处状态（“跟踪”）

■ 组合给定对象的事件历史，了解其通过整个业务过程或供应链的路径（“追踪”）

■ 分析在特定位置，于不同时间或在特定业务过程中收集的事件集合（“分析”）

■ 比较基于当前EPCIS事件确定的实际对象状态与基于先前业务事务或先前EPCIS事件预期发生的事件状况（“检查”）

■ 基于新进采集的EPCIS事件确定业务步骤完成情况，实时触发其他业务过程（“自动化”）

以下是可受益于EPCIS数据的商业应用示例，以及所涉范例。但应注意，此类范例较为宽泛，事实上，商业应用可以以多种方式组合或开发范例，以便使用EPCIS数据。

表2-1商业应用及其使用EPCIS数据的示例

所有此类应用均可以以下三种模式中的一种进行部署：

■ 内部：业务过程在机构内进行，受单个组织控制。

■ 外部，封闭链：业务过程涉及多个组织，但所涉及的所有组织均事先知晓。

■ 外部，开放链：业务过程涉及多个组织，所涉及的组织事先并不知晓，而且随着时间推移而变化。这种模式通常是涉及相互贸易的大型供应链。

在所有三种模式中，解决方案设计的一个关键要素是确定合理的EPCIS事件数据内容，以满足商业应用需求。在外部模式中，还需考虑在多个相关组织之间传递EPCIS事件的方式设计（通常称为“流程设计”，与“内容”相反）。

在外部开放链模式中，可以清楚认识到EPCIS和CBV作为开放标准的价值：如各方均遵守标准，即使各方并未事先就解决方案设计进行合作，也可能实现数据的互操作性和相互理解。但是，这在封闭链或甚至在严格的内部应用中也同样重要——主要是因为随着时间推移，内部应用往往成为外部应用，封闭应用往往会成为开放应用。因此，即使在设计封闭或纯粹的内部应用时，也要遵循外部公开应用的最佳规范。

可视性增强可在所有行业供应链的各个环节提供多种收益。记录从生产地或制造地经各分销点、至最终销售点、然后到达消费者手中的过程可能提供以下收益：

■ 优化接收效率

■ 改善库存管理

■ 提高捡拾率

■ 减少缺纬和短缺

■ 提高订单准确性并减少帐单错误

■ 通过跟踪和追踪过程改善产品和位置识别

■ 提高跨多种业务过程间的操作效率

■ 改善准备工作，进行快速和精确召回

■ 加强消费者保护

■ 优化提供给消费者的产品、过敏原和营养信息

EPCIS及其随附的核心业务词汇为采集和共享可视性数据提供了技术基础。其可帮助回答“某物现在的位置，以及其曾经停留过的位置”这一问题。与专有解决方案相比，以标准方式共享可视性数据具有显著优势。EPCIS允许数据在内部或贸易伙伴间的各种商业应用之间共享。EPCIS有助于实时处理和返回基于事件的数据，包括流（事件的流入和流出）和复杂事件处理（事件的匹配过滤）。基于EPCIS的系统支持消费者想要获取更多产品信息的增长需求，包括其购买的物品所过经的路径。

值得注意的是，EPCIS是一组接口标准，一个用于采集数据，一个用于查询数据。核心业务词汇为EPCIS中规定的数据模型提供业务环境。许多专注于可追溯性或其他可能受益于组织内部和组织间可视性数据的业务过程的软件应用都实施EPCIS作为基础。事实上，希望制定可视性策略的组织确实应基于该标准寻求解决方案。

GS1“共享”层级的标准涉及最终用户之间共享的三类数据：

表2-2 GS1“共享”标准中的数据类别

如表格所示，可视性数据（EPCIS事件数据）是一种新型数据，与主数据或事务数据的性质不同。

EPCIS数据的一个主要区别特征是其出现次数远远多于主数据或事务数据。与事务数据一样（但不同于主数据），在组织进行更多业务时，会不断生成新的可视性数据。但可视性数据的出现次数较多，因为：

■ 可视性数据通常指对象的单个实例，例如由全球贸易项目编号（GTIN）和序列号组合标识的贸易项目。

■ 即使在可视性数据指向类等级对象时，可视性数据也会在整个业务过程的多个步骤中生成。例如，从制造商流向零售商的贸易项目可能仅经受单次业务事务（制造商销售给零售商），但如果事务在制造商和零售商的机构中进行，可能会生成数十个可视性事件。

■ 可视性数据通常具有可追溯的历史价值，因此，相比业务事务数据可以保留更长时间。

可视性数据可以补充事务数据，因为一些可视性事件可能在未进行业务事务的情况下发生，以及相反地，一些业务事务可能没有具体对象。如果同一业务过程同时生成可视性数据和事务数据，则其提供的数据可以互补。

图2-2事务数据和可视性数据之间的重叠

所有三种可能性的示例：

■ 在一些情况下，可视性事件与业务事务一致，因此可能生成一段事务数据和一段可视性事件数据描述同一事件的不同方面。例如，当货物从装货码头发货时，可能会生成发运通知（确认发送方向接收方交付特定货物的一段事务数据）和附带业务步骤“装运”的EPCIS事件（确认货物离开装货码头的一段可视性数据）。即使在此类情况下，事务数据和可视性事件数据也不可能1：1对应；例如，如果分开处理货物的不同部分，则单个发货通知可以对应于若干可视性事件。

■ 发生可视性事件时，可能没有相应的业务事务。例如，贸易项目从零售店的“库房”移动到消费者可以进行购买的销售区域。在评估产品对消费者的可用性时，此事件高度相关，但其没有相关的业务事务。

■ 业务事务发生时，也可能没有相应的可视性事件。例如，购买者向供应商发送“订单”消息时，存在有效交互，但是在订购产品所在的物理世界中并未发生任何事件（事实上，发出订单时，订购产品甚至可能不存在）。

以下简图显示了EPCIS适应典型公司IT基础架构的方式。

为了便于讨论，这张图片将所有处理主数据和事务数据（定义见上述章节）的IT组件统称为“后端应用”。当然，各个公司所使用的具体遗留组件会有很大差异；

典型组件包括企业资源规划（ERP）系统、仓库管理系统（WMS）、主数据管理（MDM）系统等。

由于可视性数据是一种新型数据，且如前文所述，可视性数据的数量往往更多，所以新型IT组件通常专入口用于处理可视性数据。此类组件包括：

■ EPCIS存储库：可视性数据的持续存储器，包括组织内部生成的所有EPCIS事件以及从贸易伙伴处收到的任何EPCIS事件。

■ EPCIS采集应用：部署在企业“边缘”（工厂，仓库，商店等），在业务过程步骤完成后生成EPCIS事件的软件应用。

■ EPCIS访问应用：处理EPCIS事件以满足企业目标的企业级软件应用（例如，第2.3节所述目标）。EPCIS访问应用可能是后端应用的简单连接器，也可能是使用EPCIS数据执行一些新业务任务的复杂应用。

EPCIS标准规定了两种接口：

■ EPCIS采集接口，EPCIS采集应用通过此接口将EPCIS事件传送到EPCIS存储库（或者可能在实时处理时，直接传送到EPCIS访问应用）

■ EPCIS查询接口，EPCIS访问应用通过此接口检索先前存储的EPCIS事件数据。

此外，IT组件通常会进行以下交互：

■ 通常，EPCIS采集应用会接收来自自动识别和数据采集（AIDC）设备，例如条码扫描器和RFID读取器（包括相关RFID过滤和采集软件））的输入，特别是当读取条码或RFID标签可触发识别业务过程已经发生时。

■ EPCIS采集应用可以连接到一个或多个后端应用，获取相关业务环境信息，例如关于待接收货物的产品主数据或采购订单信息。

■ EPCIS访问应用可以连接到一个或多个后端应用，获取相关业务环境信息或传输根据EPCIS事件数据生成的新信息（或两者）。

■ EPCIS访问应用可以调解与贸易伙伴的EPCIS数据交换。

GS1标准体系包括用于识别、采集和共享供应链中对象信息的标准。如第2.5节所述，EPCIS属于“共享”标准之一，补充了有关主数据和事务数据的其他GS1数据共享标准。“标识”标准提供了现实世界对象的标识符，使得EPCIS事件可以引用此类对象。“采集”标准将物理世界与信息世界联系起来，且如第2.6节所述，其经常为EPCIS采集应用提供输入。

EPCIS事件的“内容”维度标识了事件所涉物理或数字对象。如GS1通用规格和GS1标签数据标准所述，交易项目应使用GTIN、GTIN加批次／批号或GTIN加序列号标识。托盘或物流单元使用SSCC标识。其他GS1对象标识符包括GDTI（用于文档），GIAI（用于个别资产），GRAI（用于可回收资产），GSRN（用于服务），GCN（用于优惠券）以及CPID（用于组件或部件）。

在示例的步骤V3中，贸易项目使用GTIN加序列号（也称为序列化SGTIN（SGTIN））标识，因此，步骤V3的EPCIS事件的“内容”维度包含待接收贸易项目的SGTIN。

EPCIS事件的“时间”维度表明事件发生的时间。此维度包含三个数据元素：

■ 事件时间：事件发生的日期和时间。

■ 事件时区偏移：事件在某一地点发生时的有效时区。在应用想要使用本地时间显示事件时间时，其非常有用；例如，如果将包裹从加利福尼亚州运到布鲁塞尔，可以使用事件时区偏移，以美国太平洋时间显示装运日期／时间，以中欧时间显示接收日期／时间。

■ 记录时间：将EPCIS事件录入EPCIS存储库的日期和时间。与EPCIS活动中的所有其他领域不同，如果事件未被采集到，则不会填充记录时间，且其不会描述在事件期间发生的业务步骤信息。记录时间是一种簿记机制，可在查询EPCIS存储库提供帮助；获得记录时间后，可以辨别自上次查询以来，本次查询返回的事件是否为新事件。

在示例的步骤V3中，事件时间是收到产品的日期和时间，事件时区偏移记录当时及当地有效的时区。

EPCIS事件的“地点”维度表示事件实际发生的地点和／或事件发生后，事物所在地点。

EPCIS事件允许输入两种位置类型：readPoint和businessLocation。readPoint是事件发生的位置。BusinessLocation是后续事件发生前，对象当前所在位置。可以使用GS1全球位置编号（GLN）、GLN加上扩展、GLN以外的行业标识符或使用地理坐标来标识位置。

例如，通过入口端口时，箱子可能需要接受扫描。其通过的端口可能就是采集事件的地点。可能有人站在端口处，通过入口读取事件，或者可能安装有入口端口读取器来采集事件。这就是readPoint。盒子通过端口后，其将位于特定位置。箱子当前所在的位置就是businessLocation。位置可以使用非常精细的粒度级别（仓库中特定位置的特定仓位）进行标识，在这种情况下，可能需要使用GLN加上扩展。如果以粗略级别描述位置（一栋建筑物），仅需使用GLN。必须了解位置识别方式以采集可视性数据。

请注意，内部系统或贸易伙伴之间必须同步有关位置的主数据，以便在EPCIS表示使用GLN或SGLN标识的位置时，确保所有相关人员均可了解位置的方式相同。

在示例的步骤V3中，读取点是产品接收位置，就示例而言，我们假定该位置为零售商DC的特定装载码头入口，由GLN加扩展标识。“业务地点”是接收产品之后产品所在位置，就示例而言，我们假定该位置为零售商DC，但未指定DC内的具体地点。在这种情况下，业务地点仅使用GLN标识，而无需使用扩展。

EPCIS事件的“原因”维度描述事件发生的业务环境。其可以包括以下数据元素的任意组合：

■ 业务步骤：标识事件发生时，从业务角度来看所发生的内容；也就是说，正在进行哪个业务过程步骤。示例包括“调试”、“创建类别实例”、“检查”、“打包”、“捡拾”，“装运”、“零售”。GS1核心业务词汇（CBV）标准将在第3.6节进一步讨论，其提供标准业务步骤值列表。

■ 处置：标识有关“内容”维度中物理或数字对象的事件发生后的业务条件。示例处置包括“激活”、“进行中”、“运输中”、“过期”、“召回”、“零售”和“被盗”。GS1 CBV提供标准处置值列表。

■ 业务事务列表：标识与事件相关的一个或多个特定业务事务。业务事务使用一对标识符进行标识：其中一个标识符表示引用了哪种业务事务类型，另一个标识符表示该类型的特定业务事务。业务事务类型示例包括采购订单（“po”）、提单（“bol”）、发运通知（“desadv”）。GS1 CBV包括标准业务交易类型值列表。

■ 来源清单和目的地清单：在EPCIS事件为所有权、责任或保管业务转让的一部分时，用于提供额外的业务环境。与业务事务一样，来源或目的地由一对标识符标识：来源或目的地的类型以及该类型的来源或目的地标识符。GS1 CBV（第7.4.2节）规定了三种标准来源／目标类型：“所有方”、“拥有方”、“位置”。

在示例的步骤V3中，以下值可用于填充EPCIS事件的“原因”维度：

■ 业务步骤：GS1核心业务词汇中定义的业务步骤“接收”。

■ 处置：GS1核心业务词汇表中定义的处置“进行中”，表明产品正常通过正向供应链。

■ 业务事务列表：可能有两种相关事务：零售商的采购订单和制造商的发票。

■ 来源和目的地：来源所有方是制造商，目的地所有方是零售商。

以下四种“EPCIS事件”均将采集描述物理或虚拟世界中对象身上所发生的内容的四个维度。下面是对EPCIS事件类型的高度总结。有关详细信息，请参见EPCIS 1.1标准第7.4节。

■ EPCISEvent：所有事件类型的通用基类。

□ ObjectEvent：表示发生在一个或多个物理或数字对象上的事件。例如，使用托盘SSCC运输或接收托盘。这种事件类型最简单，也最常用。

□ AggregationEvent：表示发生在一个或多个对象上的事件，其中，此类对象聚合一起或相互分离。例如，将箱子堆在托盘上，或者从托盘上卸下箱子。这是除ObjectEvent之外最常见的事件类型，这两种事件类型将覆盖典型业务过程中绝大多数事件。

□ TransformationEvent：表示一个事件，在该事件中，输入对象被完全或部分消耗，并产生输出对象，使得任一输入对象均与所有输出对象相关。例如，考虑将面糊和巧克力片混合到饼干面团中，然后将面团烘焙成一批饼干。成分被“转化”后，包装所得到的产品并用代表“巧克力碎饼干销售包装”，且可以在零售时扫描的EAN或UPC标记。

□ TransactionEvent：表示一个或多个对象与一个或多个已标识业务事务关联或解除关联的事件。例如，将托盘和巧克力碎饼干箱与商业发票关联。

每种事件类型（TransformationEvent除外）还由“操作”进一步限定；有关详细信息，请参见本指南的第4.5节。

核心业务词汇（CBV）规定了与EPCIS标准[EPCIS1.2]一起使用的各种词汇元素及相关值，EPCIS标准规定了组织内和组织间交换信息的机制。CBV规定词汇标识符和定义以确保使用核心业务词汇交换EPCIS数据的所有相关方对该数据的语言意义的理解一致。

CBV旨在满足上述目标。特别地，该标准旨在规定EPCIS抽象数据模型的核心词汇，并适用于许多想要或需要共享数据的行业所共有的广泛业务场景。其旨在提供一组有用的值和定义，使供应链中各方的理解一致。

可以通过扩充词汇元素，并针对特定行业或一组用户或单个用户规定附加词汇元素来解决最终用户的附加需求。

CBV提供标识符语法（URI结构）和具体词汇元素值以及此类标准词汇的定义：

■ 业务步骤标识符

■ 处置标识符

■ 业务事务类型

■ 来源／目的地类型

■ 错误原因标识符

CBV针对此类用户词汇表提供标识符语法选项：

■ 对象

■ 位置

■ 业务事务

■ 来源／目标标识符

■ 转化标识符

■ 事件标识符

CBV提供主数据属性和值，用于描述物理位置、相关方和贸易项目，其中包括GTIN级、批次级和实例级贸易项目主数据属性。

结合“内容、地点、时间和原因”这四个维度后，可以获得EPCIS事件的完整信息内容。下表将总结上述步骤V3的EPCIS事件信息内容

表3-1示例业务过程步骤V3的EPCIS事件信息内容

第4节将详细描述设计过程，显示其最终如何生成符合标准的EPCIS数据。

随着对组织跟踪和追踪货物在供应链中的移动的要求不断增加，强调部署可视性系统的总体目标和目的十分重要。“我们致力于解决哪些问题”？

目标可能是为了符合政府法规，或者为了提高运输效率，或者了解客户想要的物品的位置以及交付给客户的时间，以确保提供高水平的客户服务。

确定目标后明确记录满足目标的要求是开始思考如何部署EPCIS的第一步。例如，如果组织尝试满足跟踪和追踪法规，则需要了解需要哪些数据、过程进度、数据保存位置以及将数据发送给另一方人员和方式。

总体要求确定后，即可确定详细的过程流程和基于EPCIS和核心业务词汇的具体数据要求。

下面将介绍简化的正向物流业务流程。我们将在以下章节中使用该业务流程说明设计过程中的其他步骤。

在该业务过程中，制造商在其生产工厂制造货物。然后，将货物从制造商的工厂运送到负责接收和储存的零售商配送中心。然后，将货物从零售商配送中心运送到负责接收并出售给消费者的零售店。

图4-1业务过程流程示例

整个业务过程流程如下：

1. 制造货物，将产品装箱，然后装到托盘上。

2. 使用卡车将产品从制造商的工厂运送到零售商配送中心。

3. 产品到达零售商配送中心并收入库存。

4. 使用卡车将产品从零售商配送中心运送到零售店。

5. 产品到达零售店，并收入库房。

6. 将产品从库房移到销售楼层。

7. 在零售店中，将产品销售给消费者。

简化的正向物流示例的过程流程如下图所示。蓝色箭头表示流动方向，各白色矩形表示过程中的单个步骤。随着时间从左向右移动，横轴还将显示产品从一个位置移动到另一个位置所涉及的位置。

在该示例中，存在聚合层级结构，即先将项目装箱，将箱子装入托盘，然后将托盘装入卡车。在此类情况下，可以使用纵轴显示各步骤在哪个层级发生。如果某一过程流程仅在单个聚合水平生效，相应图表可能完全水平，或者可以使用纵轴突出显示流程的一些其他方面。在该阶段，必须要清楚了解流程的各个步骤。

此类流程图中的步骤并非都会生成EPCIS事件；下一节中将就此进行讨论。

图4-2正向物流过程流程，图1/2

图4-3正向物流过程流程，图1/2

并非业务过程中的每个业务步骤都需要可视性事件。决定给定业务步骤是否需要事件时，通常需要权衡哪些数据具有价值以及哪些数据可收集。

关于哪些数据具有收集价值的问题包括：

■ 详细了解关于该过程步骤的可视性事件信息是否可向一些商业应用提供有用输入？

■ 为了使应用理解有关另一步骤的信息，是否需要提供有关此步骤的信息？例如，如果“运输”步骤中发生的事件包含托盘ID，则可能还需要采集“包装”步骤中发生的较早事件，以便应用知晓装运托盘的内容物。

■ 贸易伙伴或政府法规是否要求提供关于该过程步骤的信息？

关于哪些数据可收集的问题包括：

■ 该过程步骤涉及的物理或数字对象是否有适当的标识符？如果没有，是否可以赋予其标识符？

■ 对于物理对象，是否可以使用数据载体（如RFID标签或条码）来粘贴标识符？如果不可以，是否有可能以其他方式采集标识符？

■ 是否可以通过修改操作过程来纳入可视性事件的数据采集？这里主要考虑必要基础架构（条码扫描器，RFID读取器，软件等）的成本以及对过程本身的影响（是否需要附加劳动力，过程是否放慢等）。

在该示例中，我们假设，从业务角度来看，必须知晓各位置所发出和收到的货物类型。在多数情况下，还需记录需“定期进行”的事项。即每次创建一个新标识符时采集一个事件。

但是我们还假设，仅可采集箱子和托盘级数据，而无法采集项目级数据。我们还假设，用于移动托盘的卡车未被标识，且无法知晓使用了哪些卡车。

综上所述，需要在该示例中制造商负责的以下步骤采集可视性事件：

■ V1：打印和粘贴箱子标签（调试——需要，使得后续步骤可以理解）

■ V2：打印托盘标签（调试——需要，使得后续步骤可以理解）

■ V3：将箱子装入托盘（需要，使得可以通过读取托盘标识符来推断货物内容）

■ V4：运送托盘

这些在图中使用红色圆圈编号V1、V2等表示。图中不带圆圈的其它步骤是不会采集可视性事件的步骤。

图4-4正向物流过程流程（可视性采集已标明）

现在，我们开始设计EPCIS数据，此类数据将采集选定业务过程步骤中发生的内容。首先决定第3.5节所述的事件类型列表中的哪种事件类型最适合当前情况。事件类型将决定事件“内容”维度中的信息结构。

选择事件类型时，请考虑事件中涉及的物理或数字对象以及其如何相互关联。大多数情况下，需在以下三种事件类型进行选择一种：

■ ObjectEvent：如果事件涉及一个或多个对象，且所有对象以相同方式参与事件，请使用此类型。这是当前最常见的事件类型。

■ AggregationEvent：如果事件是涉及“父”对象和一个或多个“子”对象的物理聚合，请使用此类型。聚合示例包括装入纸箱（“父”）的12个项目（“子”）。其他聚合示例包括托盘上的箱子、提袋中的项目、装入卡车的纸箱、装入远洋船的包装箱和装入总成的组件。在所有此类示例中，即使聚合到父对象中，各子对象仍保留其身份，且聚合具有可逆性（即可以“解开聚合”）。

■ TransformationEvent：如果事件涉及消耗一个或多个“输入”对象，并且产生一个或多个“输出”对象，请使用此类型。与聚合不同，子对象后续可以与父对象分离，而在转化中，输入对象在事件之后不再存在。转化示例包括混合原材料以创建成品配方；重新包装项目，使原包装不再存在，并使用新的GTIN标签标注新包装；以及烟熏三纹鱼（将生鱼转化为熏鱼）。

■ 如果事件是将一个或多个对象与一个或多个业务事务明确关联（或分离）的过程，则可以使用第四种事件类型TransactionEvent。但是，由于业务事务可以纳入所有其他事件类型的“原因”维度中，所以很少需要使用TransactionEvent类型。

ObjectEvent和AggregationEvent类型分别具有附加限定符，即操作，用于说明事件如何与对象的生命周期和聚合相关。具体来说：

■ 对于ObjectEvent，此类操作值为：

□ 如果事件标志着对象生命周期的开始，则为“添加”。对于相同对象，所有其他事件应在此事件之后。此事件常用于业务步骤“调试”。

□ 如果事件标志着对象生命周期的结束，则为“删除”。对于相同对象，所有其他事件应在此事件之前。当业务步骤是“退役”、“销毁”或涉及向消费者销售的业务步骤（如果无法在售后跟踪对象）时，通常使用此事件。

□ 在所有其他情况下为“观察”。

■ 对于AggregationEvent，操作值为：

□ 如果在事件期间将子对象添加到聚合中，则为“添加”；例如，将项目装箱时。

□ 如果在事件期间将子对象从聚合中取出，则为“删除”；例如，从箱子中取出项目时。

□ 如果在事件期间，父对象和子对象处于聚合状态，但未添加或删除子对象，则“观察”。

TransactionEvent也具有操作限定符；详情请参见EPCIS标准。TransformationEvent没有操作限定符。

以下将说明将事件类型分配给上述示例中事件V1到V4的方式：

表4-1将事件类型分配给示例业务过程中的业务过程步骤

在V4事件中，可以选择如何将托盘运送行为记录为EPCIS事件。其中一种方法是使用ObjectEvent（带操作“观察”），且仅将托盘的SSCC纳入“内容”维度。使用这种方法可以简化数据采集，并使事件更紧凑，但在需要推断运送托盘上的箱子类型时，接收数据的应用需要查询V3事件。另一种方法是使用AggregationEvent（带动作OBSERVE），并将托盘的SSCC（父对象）和所有箱子（对象）的SGTIN纳入“内容”维度。如果在运送托盘时，能够识别SGTIN，且制造商希望了解当时托盘上的具体箱子类型，可以使用上述方法。接收V4的应用无需使用V3进行推断来了解托盘上的箱子类型。

V4示例表明，在决定如何使用EPCIS为业务过程建模时，有时必须进行细心选择。在此类情况下，如果需要寻求帮助，可以查阅特定行业部入口指南，获得此类部入口常见业务过程的标准EPCIS模型。

定基本事件类型后，应决定将哪些数据纳入各事件的“内容、地点、时间和原因”维度。似乎可以先从采集应用可以采集哪些信息着手，例如RFID读取器或条码扫描器将生成哪些数据。但是，如果从相反方向着手，即从消耗数据的业务应用着手，EPCIS数据将更加有用。需要解决的问题是：“业务应用需要哪些信息才能了解在此事件期间发生的内容？”从业务角度来看，业务应用无需了解数据采集方式；其需要了解所发生的内容。

最好可以依次考虑四个数据维度。

4.6.1 设计“内容”维度

“内容”维度标识事件中涉及的物理或数字对象。“内容”维度中的信息结构取决于事件类型：

■ 对于ObjectEvent，“内容”维度包含对象列表。所有对象都以相同方式参与事件。

■ 对于AggregationEvent，“内容”维度将特定对象命名为“父对象”，并包含其他对象（“子对象”）列表。（但有两种例外情况。如果操作是“观察”，则可以省略父对象，表明在集合状态下观察子对象，但父对象的身份未知。如果操作为“删除”，则可以省略子对象，表示所有子对象均已与父对象分离。）

■ 对于TransformationEvent，“内容”维度包含作为转化输入的一个对象列表，以及作为转化输出的第二个（不同）对象列表。（如果TransformationEvent通过TransformationID连接到其他TransformationEvent，则可以省略输入或输出；请参见第5.5.2节）。

除考虑业务过程步骤中哪些对象与事件相关之外，还必须确定此类对象在事件中的命名方式。在EPCIS中，有两种不同方式可用于引用对象：

■ 实例级标识：如果某个对象具有唯一的标识符，则称为实例级标识。实例级标识的示例包括带序列号的全球贸易项目编号（GTIN）（统称为序列化GTIN或SGTIN）、系列货运包装箱代码（SSCC）、带序列号的全球可回收资产标识符（GRAI）等。

■ 类别级标识：如果对象的标识符与其他类似对象所携带的标识符相同，则称为类别级标识。类别级标识的示例包括GTIN加批次或批号（由属于同一批次或批号的所有交易项目共享）、GTIN本身、无序列号的GRAI等。

在应用如何使用EPCIS数据方面，实例级标识最为有效，因为其使得确定某一事件中引用的对象与先前或后续事件中引用的对象完全相同成为可能。另一方面，将实例级标识分配给对象通常比分配类别级标识更复杂。

使用类别级标识时，事件可能涉及多个同类别对象，因此，类别级标识符通常附有指定数量的信息。可以通过四种方法在EPCIS事件的“内容”维度中标识对象（包括实例级标识）：

表4-2类别和实例级对象标识

表中的最后一种情况，即无数量信息的类别级标识符，仅在无法确定数量或数量因隐私原因而有所保留时使用。

相同EPCIS事件可能会使用实例级标识来标识一些对象，而使用类别级标识来识别其他对象。例如，使用GTIN和批号（类别级）标识的箱子可以一起装入使用SSCC（实例级）标识的托盘，或者可能存在转化事件，在该事件中，一些输入是由类别和数量标识的原材料，其他输入由GTIN+序列号（实例级）标识，输出由GTIN +序列号标识。但是，在一个事件中，仅可使用一种方法标识一个给定对象。例如，如果一个对象事件具有5个SGTIN（GTIN相同，序列号不同），则对象事件应该包含这5个SGTIN，但不得将GTIN视为类别级标识符。

4.6.2 设计“时间”维度

“时间”维度是四个维度中最简单的维度。其存在于每个事件中，且总是包含两条信息：

■ EventTime：事件发生的日期和时间。其总是以包含时区说明符的格式表示，以便及时明确识别时刻。

■ EventTimeZoneOffset：事件发生地点有效的时区偏移（相对于UTC）。这可以将EventTime以事件发生的本地时间展示给用户（如果需要）。

用于这两个数据元素的正确值通常非常明确，因此，基本无需进行设计工作。

对于在一段较长时间内进行的业务步骤，可能需要确定EventTime是该步骤开始或结束的时间，还是两者之间的某个时刻。通常，最好使用业务步骤的结束时间。但是，与所有EPCIS数据设计问题一样，应该从消耗数据的业务应用着手考虑。如果业务应用必须知晓业务步骤的开始时间和结束时间，则应该考虑使用两个EPCIS事件对过程进行建模是否更为合适（一个用于过程开始，另一个用于过程结束）。

相反，从业务角度来看，有时会有若干不同事件同时进行，或者使得难以为每个事件分配不同的EventTime。例如，自动化生产机器可能会将SGTIN分配给12个产品（“调试”业务步骤），将另一个SGTIN分配给一个箱子（“调试”），并将此类项目一次性装入箱子中（“包装”业务步骤）。虽然可能无法一次完成，但机器内置的EPCIS采集应用可能无法区分时间。在此类情况下，可以将相同的事件时间分配给所生成的所有EPCIS事件，但是如果事件存在逻辑顺序，则对消耗应用来说，通常需要稍微改动事件时间，以便时间顺序符合逻辑。在项目装箱的示例中，“包装”的EPCIS事件（聚合事件）的时间应该比调试时间晚，即使人为设定其仅晚一毫秒。这允许消耗应用按照EventTime对事件进行排序，以便实现逻辑顺序。

4.6.3 设计“地点”维度

“地点”维度标识事件所涉对象的物理位置。“地点”维度中的两个数据元素均为可选，但大多数EPCIS事件会同时提供这两个数据元素。这两个数据元素是：

■ ReadPoint: ReadPoint标识事件发生时，“内容”维度中确定的对象位置；即事件发生地点。

■ BusinessLocation: BusinessLocation标识事件发生后，另一事件发生前，“内容”维度中确定的对象预期位置。

名称ReadPoint和BusinessLocation可能有些令人困惑。例如，从业务角度来看，ReadPoint的相关性可能等于或高于BusinessLocation（取决于具体情况）。无需解读名称ReadPoint和BusinessLocation的含义，仅需记住定义：ReadPoint是事件发生时对象的位置，BusinessLocation是事件发生后的位置。

可以想象一座设施中有几个房间，房间通过入口廊连接，来理解ReadPoint和BusinessLocation之间的区别，如下所示：

RFID读取器进行采集。想象对象通过大入口A从房间1移动到房间2。在这种情况下，ReadPoint（事件发生时的位置）为大入口A，BusinessLocation（事件发生后的位置）为房间2。请注意，该对象可能会在房间2内移动，此时，不会生成任何新的EPCIS事件，因此在其进入房间2后，对于其在事件发生后的位置，我们仅知道其在房间2内的某个位置。如果对象已通过大入口B从房间1移动到房间2，则BusinessLocation将仍然为房间2，但是，ReadPoint将为大入口B。另一方面，如果对象后来通过大入口A以相反方向移动，则ReadPoint将变为大入口A，但BusinessLocation将为房间1。

获取BusinessLocation的原因是其可帮助解答“对象当前位于哪里？”这个问题。如果在事件发生时恰好问到该问题，则可以查询ReadPoint，但在任何其他时间，最近事件的BusinessLocation将最接近对象当前位置。同时，ReadPoint也可提供很大帮助，因为其可显示有关过往事件的一些内容：“X发生时，对象位于哪里？”（其中X使用相应事件的“原因”维度确定）。

设计“地点”维度时，确定用于描述位置的粒度是关键问题。例如，如果对象在接收操作期间通过装货码头入口进入，有几种方法可用于描述事件的位置（ReadPoint），下面列出了最具体（精细粒度）到最不具体（粗糙粒度）的方式：

■ “XYZ公司芝加哥园区2号楼接收码头＃5”

■ “XYZ公司芝加哥园区2号楼接收区域”（未说明具体入口）

■ “XYZ公司芝加哥园区2号楼”（未说明2号楼内的具体区域）

■ “XYZ公司芝加哥园区”（未说明具体建筑）

■ “XYZ公司”（未说明具体位置）

决定EPCIS事件应使用何种粒度级别起着关键作用。与大多数EPCIS设计决策一样，需要权衡业务应用需要拥有哪些功能来使用数据以及采集到EPCIS事件时可以收集哪些数据。例如，与仅知晓对象已进入建筑物相比，区分建筑物中的不同装货码头入口可能需要更昂贵的基础架构。同时，业务应用可能并不需要知道所使用的具体入口。有时，由于EPCIS事件在内部采集，因此在进行设计时，粒度问题的解决方式与贸易伙伴共享此类事件的方式不同。例如，可能会以单个装货码头入口级别对ReadPoint进行内部采集，但在与贸易伙伴共享相同事件时，需要以“建筑物”级别进行采集。（另见第6.7节）

通常，BusinessLocation的粒度级别粗于ReadPoint，这是因为与事件发生时的位置相比，EPCIS采集应用无法确定事件发生后，某个对象可能所在的位置。此外，如果业务不需要以更精细的方式表示ReadPoint时，ReadPoint与BusinessLocation的粒度级别相同。

将对象从一个位置转移到另一个位置时（如接收后进行运送），BusinessLocation会出现特殊情况。运送对象时，事件发生后的对象位置显然不是发货方位置。但是其也不是接收方位置，因为仅在接收期间，采集到事件之后，对象才位于接收方所在位置。因此，装运时采集的EPCIS事件的正确BusinessLocation“未知”——装运后，在接收操作发生之前，可能无法知晓对象的具体位置。这在EPCIS中表现为运输事件完全省略BusinessLocation数据元素。

4.6.4 设计“原因”维度

“原因”维度解释事件的业务环境，对于业务应用理解EPCIS数据至关重要。“原因”维度中的所有数据元素均可选，但几乎所有的EPCIS事件都至少包含BusinessStep和BusinessLocation数据元素。“原因”维度中的其他数据元素仅在与业务步骤相关时才包括在内。

“原因”维度中数据元素的定义见第3.4节。以下是选择是否纳入各数据元素，以及如何选择适当值的设计考虑因素。

4.6.4.1 设计业务步骤

BusinessStep数据元素对于业务应用理解EPCIS数据含义的来说极其重要。BusinessStep值是一个标识符，用于表示事件发生时正在进行业务过程的哪个步骤。如果不知晓业务步骤，则应用仅能知晓对象目前在某个特定地方；了解业务步骤后，应用将了解该对象与整个业务的关系。实际上，所有EPCIS时间均应具有BusinessStep值。BusinessStep值通常对应于某种动作：运送、接收、包装等。

为使业务步骤值有用，进行查看的应用必须事先知晓其含义。因此，BusinessStep的值总是由某种标准规定——即将给定BusinessStep值与该值的含义解释以及解释携带该值的EPCIS事件的方式关联的文档。EPC核心业务词汇（CBV）就属于这种标准。其属于全球性标准，规定了几十个业务步骤值，此类值适用于许多行业部入口的供应链业务过程中常见的各种业务步骤。由于其是全球性跨部入口标准，使用CBV业务步骤值可使大部分应用能够理解EPCIS事件。在CBV业务步骤值适用时，应进行使用。

但是，有时可能会在某一业务流程中使用EPCIS，而该过程中有些步骤与CBV规定的任何业务步骤值都不相符。在此类情况下，必须使用不同的标识符，即针对特定应用创建的标识符。仍然会使用文档来定义标识符及其含义——在这种情况下，该文档是内部设计文档而不是全球标准。可由一组贸易伙伴商定，或者按照部入口特定标准规定特定业务步骤值。但是，此类值将所产生的EPCIS事件仅能被了解界定此类值的窄范围标准和设计文档的小部分组织理解。在决定是否使用CBV时，必须进行这种权衡。

第4.7节将介绍如何创建CBV中未定义的标识符以避免冲突。

4.6.4.2 设计处置

Disposition值是指示事件发生后，对象的业务状况的标识符。Disposition值通常对应于根据其与整个业务过程的关系描述对象的业务状态的形容词：进行中、被召回、已损坏等。

Disposition主要用于区分正常过程和异常情况。例如，核心业务词汇（CBV）Disposition值“进行中”表示对象正常通过供应链，“被召回”表示制造商已经召回对象。除BusinessStep外，注明Disposition有助于理解此类情况，具体表现在以下两个方面。第一，在产生异常结果的事件发生时，Disposition可以显示产生了哪种结果。例如，EPCIS事件的BusinessStep值可能为“检查”（来自CBV），其中，检查结果通常为Disposition“进行中”，或者如果检查发现对象被召回，则为“被召回”。第二，即使对象经受其他事件，Disposition可以继续指示异常状态。例如，进行“检查”步骤后，将对象退回制造商时，被召回对象可能拥有多个EPCIS事件，且相应的BusinessStep值为“运送”和“接收”。如果没有Disposition，此类EPCIS事件将难以区分正常和异常运输和接收步骤，但当Disposition值为“被召回”，而不是“进行中”时，此类事件显然是逆向物流过程的一部分。

与BusinessStep一样，Disposition的值仅在进行查看的应用事先知晓其含义时才有用。因此，第4.6.4节中的所有意见同样适用于Disposition值。

4.6.4.3 设计业务事务列表

BusinessTransactionList是对业务事务的引用列表——即可以从EPCIS以外的其他系统获得的数据。业务事务示例包括：对特定采购订单的引用、对特定发票的引用等等。这些信息将提供EPCIS事件的业务环境，并帮助将EPCIS数据与其他业务信息系统关联。

BusinessTransactionList中的每个业务事务由一对标识符组成。第一个是业务事务类型标识符，用于说明所引用的业务交易类型（采购订单、发票等）。第二个是引用指定类型的特定事务的业务事务标识符。

业务事务类型标识符类似于BusinessStep或Disposition值，因为其仅在进行查看的应用事先知晓其含义时才有用。因此，第4.6.4.1节中的所有备注同样适用于业务事务类型值。核心业务词汇表规定了常见业务事务类型（如采购订单、发票等）的标准业务事务类型标识符。

业务事务引用的第二部分（业务事务标识符）是指具体的业务事务。与业务步骤、处置或业务事务类型值不同，不存在固定的业务事务标识符列表——在创建新业务事务时会不断创建新标识符。通常，业务事务标识由EPCIS以外的一些信息系统生成；例如，发票号码可能由企业资源规划（ERP）系统创建。

业务事务标识符必须具有全球唯一性，以便用于EPCIS事件。这是因为在处理EPCIS数据时，应用可能会从整个供应链中收集EPCIS事件。在这种情况下，不能混淆来自供应链各方的两份采购订单。

有两种策略可用于创建适用于EPCIS业务事务列表的全球唯一业务事务标识符。第一，创建业务事务的系统可以使用全球唯一标识符作为引用事务的唯一方式。例如，ERP系统可以本地分配唯一标识符，如GS1全球文档类型标识符（GDTI）。如果分配正确，则一个系统产生的GDTI将不同于由任何其他方系统产生的GDTI。但是，许多遗留系统并不具备这种设计——典型ERP系统将简单地给每个事务赋予编号（如12345），此类编号在ERP系统中具有唯一性，但不能保证其与其他ERP系统生成的编号不同。

创建全球唯一业务事务标识符的第二个策略是将遗留系统创建的标识符与使其全球唯一的前缀相结合。EPC核心业务词汇表规定了可用于此目的的模板，该模板使用发行方的全球位置编号（GLN）。例如，如果公司X的GLN为0614141123452，且其ERP系统生成采购订单编号为12345，则使用CBV模板创建的相应全球唯一标识符是：

urn: epcglobal: cbv: bt: 0614141123452:12345

该标识符的第一部分（urn：epcglobal：cbv：bt）属于前缀，用于表示其使用CBV的业务事务标识符模板。其余两个部分分别是ERP系统分配的GLN和PO编号。由于任何其他ERP系统生成的PO编号12345将被赋予不同前缀，因此整个字符串（可视为单个标识符）具有全球唯一性。（如果一个公司拥有多个ERP系统，且其分配的事务编号可能发生冲突，则应该使用不同的GLN作为每个系统的前缀。）

在处理EPCIS数据时，应使用整个业务事务标识符（包括任何前缀）。例如，为测试两个EPCIS事件是否引用了相同的业务事务，应该比较整个标识符字符串（以及业务事务类型标识符）。但是，当将EPCIS数据与遗留系统数据相关联时，可能需要识别CBV前缀并解析标识符，以确定所引用的遗留系统以及该系统的本地事务ID。

4.6.4.4 设计来源和目的地列表

某些业务过程步骤是业务转让过程的一部分，在该过程中，所有权和／或实际拥有权从一方转移到另一方。运送和接收是两个常见示例，但也可能有其他示例，如托运、验收、退货、中间运输步骤等。在此类情况下，需要提供信息来标识转让的来源和目的地。例如，在运送事件中，不仅需要指明“运送”位置，而且还需指明“接收”位置。从所有权以及实际拥有权的角度来看，可能还需指明双方当事人（可以是也可以不是同一对双方）。EPCIS事件中的来源和目的地列表可能用于提供此类信息。来源和目的地信息是EPCIS事件中“原因”维度的一部分，因为其用于提供业务环境。

来源列表由一系列来源组成，每个均由来源类型和来源标识符组成。同样，目的地列表由一系列目的地组成，每个均由目的地类型和目的地标识符组成。核心业务词汇中规定了三种可能的来源或目的地类型；每种将说明解释其限定的来源或目标标识符的方式：

表4-3核心业务词汇中规定的来源／目的地类型

对于一方或物理位置（具体取决于来源／目的地类型），来源或目的地标识符本身具有全球唯一性。通常，其是以EPC URI格式呈现的GLN（带或不带扩展皆可），但CBV也指定了可以使用的其他标识符。

根据可用的业务环境，三种来源／目的地类型的任何组合可以用于来源列表或目的地列表中，或两者。通常，需要提供给定类型的来源和目的地。

完整的业务转让通常涉及多个EPCIS事件，且事件通常由多方产生。例如，简单转让将包括两个EPCIS事件，一个有关运送步骤，一个有关接收步骤。例如，复杂转让可能涉及单独的到达和验收步骤，或跟踪中间运输步骤，例如在通过时观察铁路承运人或海运承运人。属于同一转让的所有此类步骤可以提供来源／目的地信息。在这种情况下，所有事件的来源／目的地信息通常相同。

例如，甲方将拥有权转让给乙方时，运送和接收的EPCIS事件可以提供甲方的来源类型“拥有方”和乙方的目的地类型“拥有方”。这两个事件的来源／目的地信息的解释可能稍有不同。在运送事件中，来源表示转让开始时的已知拥有方，但目的地表示转让结束时的目标拥有方。在接收事件中，目的地表示转让结束时的已知拥有方，但来源表示转让开始时的先前拥有方。

“位置”型来源或目的地可能与某些事件的“地点”维度中的读取点信息一致。具体而言，运送（或类似）步骤中的读取点与“位置”型来源一致，并且接收（或类似）步骤中的读取点与“位置”型目的地一致。在这种情况下，来源／目的地中的信息应该与读取点中的信息一致。（例如，如果使用比来源或目的地更精细的位置标识符报告读取点，则可能不完全相同。）

不属于业务转移的EPCIS事件不应提供来源／目的地信息。

有关使用来源／目的地列表的示例场景，请参见第5.2节。

4.6.5 示例

综合本节中的所有内容，下面将举例说明我们如何针对第4.4节中示例事件V4设计EPCIS事件。在该事件下，将包含多个箱子的托盘从制造商运送到零售商配送中心。

如4.5节所述，该事件可以以托盘命名的ObjectEvent表示，或者以托盘和箱子命名的AggregationEvent表示。在本例中，我们假设使用ObjectEvent方法。

表4-4第4.4节中示例步骤V4的EPCIS事件信息内容

在上一步中，已确定各EPCIS事件的数据元素内容。下一步需要将各数据元素内容的非正式说明转换为计算机可以理解的特定标识符。请参见核心业务词汇第7节和第8节。

4.7.1 用于“内容”维度的词汇

在“内容”维度中，可以引用一个或多个物理或数字对象。大多数情况下，每个对象均由GS1 KEY标识。例如，贸易项目可能使用GTIN（例如：00614141123452）和序列号（例如：400）标识。在EPCIS中，根据EPC标签数据标准，将GTIN加序列号表示为统一资源标识符（URI）。其形式如下：

urn: epc: id: sgtin: 0614141.012345.400

该标识符的第一部分（urn：epc：id: ）表示该标识符符合EPC标签数据标准。下一部分（sgtin: ）表明其由GTIN加序列号（SGTIN）组成。接下来的三个部分是GS1公司前缀（0614141）、指示符数字和项目引用（012345）以及序列号（400）。请注意，在EPC URI中，GS1公司前缀与GTIN的其他数字分开写入，且没有校验位。

EPC标签数据标准第6节和第7节为所有可用于EPCIS事件“内容”维度的GS1 KEY提供EPC URI语法。有时，可能需要在“内容”维度中引用物理或数字对象，但使用EPC标记数据标准不支持的某些标识系统来标识对象。对于此类情况，核心业务词汇（第8.2节和第8.3节）提供可以使用的其（他非EPC）URI。但是，如果可能，应优先选择使用GS1 KEY。

4.7.2 用于“地点”维度的词汇

“地点”维度中的ReadPoint和BusinessLocation数据元素包含引用物理位置的标识符。选择适当的标识符时，必须先决定如何标识位置。

标识位置最常用的方法是为其赋予唯一的标识符，如全球位置号码（GLN）。GLN仅是位置所有方指定的，用于表示特定位置的任意编号。GLN可以按照任何粒度级别进行分配（见第4.6.3节），甚至可以将GLN分配给细粒度位置（例如建筑物中的房间），也可以将不同GLN分配给粗粒度位置（如建筑物本身）。分配完成后，GLN将具有层次结构。

当将标识符分配给细粒度位置（如单个装货码头入口或大仓库中的个别仓位）时，GLN本身的容量不足。在此类情况下，可将GLN加GLN扩展分配给每个位置。当将GLN+扩展分配给细粒度位置时，GLN部分通常是含有位置信息的粗粒度GLN（例如包含建筑物）。

与“内容”维度一样，在EPCIS中使用URI语法创建“地点”维度中的标识符。例如，假设位置由GLN 0614141111114和扩展987标识。在EPCIS中，根据EPC标签数据标准，将GLN+扩展表示为统一资源标识符（URI）。URI的具体类型被称为SGLN，能够表示GLN+扩展或者不带扩展的GLN。GLN 0614141111114和扩展987的SGLN如下所示：

urn: epc: id: sgln: 0614141.11111.978

为表示不带扩展的GLN，使用单个0位代替扩展，如下所示：

urn: epc: id: sgln: 0614141.11111.0

该标识符的第一部分（urn：epc：id: ）表示该标识符符合EPC标签数据标准。下一部分（sgln: ）表明其由GLN或GLN+扩展（取决于扩展部分是否为0）构成。接下来的三个部分是GS1公司前缀（0614141）、位置引用（11111）和扩展（或者用于普通GLN的0）。请注意，在EPC URI中，GS1公司前缀与GLN的其他数字分开写入，且没有校验位。

有时，可能需要在“地点”维度中引用物理位置，但使用EPC标记数据标准不支持的某些标识系统来标识位置。对于此类情况，核心业务词汇（第8.4节）提供可以使用的其他（非EPC）URI。但是，如果可能，应优先选择使用GS1 KEY。

另一方面，有时位置仅可使用地理坐标（纬度和经度）标识，而不能使用唯一标识符标识。最常见的情况是在运送中跟踪运载工具（例如，远洋船舶）时创建的ReadPoint，因为公海上没有可以使用GLN标识的预定位置，但可以使用全球定位系统接收机。在这种情况下，可以使用地理空间URI。其形式如下：

geo: 22.300,-118.44

此示例表示地理位置位于北纬22.300度，西经1032，118.44度。有关更多详细信息，请参见核心业务词汇第8.4.4节。

4.7.3 用于“原因”维度的词汇

EPCIS事件的“原因”维度包含许多需要各种标识符的数据元素。有两种方法可用于完成此操作，具体取决于数据元素。

4.7.3.1 “原因”维度的标准词汇元素

“原因”维度中的一些数据元素包含供应链各方必须事先理解的概念名称。示例包括BusinessStep数据元素，其包含一个代表“运送”、“接收”等概念的标识符。此类标识符通常在某种标准中定义，常用于定义的标准是核心业务词汇。

核心业务词汇表第7.1节定义了30多个不同的商业步骤值。在EPCIS事件中出现的完整值为URI，如下所示：

urn: epcglobal: cbv: bizstep: shipping

该标识符的第一部分（urn：epcglobal：cbv: ）表示核心业务词汇表中对其进行了定义。下一部分（bizstep: ）表示其来自业务步骤值列表。这两个部分对于CBV中定义的所有业务步骤标识符均相同。其余部分是具体的业务步骤。

要选择适当的业务步骤值，请查阅CBV中给出的定义。例如，CBV将urn：epcglobal：cbv：bizstep：packing定义为“业务过程内的特定活动，包括将对象放入更大包装箱中——通常用于运送。此时通常需将一个单元置于另一个单元上。”

在一些情况下，可能没有合适的CBV标识符。在这种情况下，可以创建自己的标识符，但其仍然应该使用URI语法，并使用可以控制的前缀。对于大多数用途而言，进行上述操作时需要使用使用您的Internet域名的HTTP URI。例如，如果贵公司为具有域名example.com的示例公司，并且需要进行新的业务步骤“调整”，则可以使用如下所示的URI：

http: //epcis.example.com/bizstep/fiddling

以http: //epcis.example.com／开头表明其不会与CBV标识符冲突，也不会与任何其他组织创建的私有标识符冲突。如果贸易组织为其建立的标准创建私有标识符，则可将组织的Internet域名用作根。如第4.6.4.1节所述，如果您创建了与上述类似的私有业务步骤，您必须通知贸易伙伴该步骤的含义，从而使其可操作性低于CBV中定义的步骤。

请注意，尽管上述标识符似乎可能输入Web浏览器，但就EPCIS而言，其只是业务步骤的标识符，并不一定存在可以通过该URI访问的网页。另一方面，拥有该URI的网页可用于向人类提供有关业务步骤含义的文件。

“原因”维度中其他几个数据元素的工作方式也相同。具体如下。

表4-5核心业务词汇中定义的标准词汇标识符示例

对于所有此类数据元素，最好使用CBV中定义的一种标识符，但如果无法使用此类标识符，可以按如上所述构建私有标识符。

4.7.3.2 “原因”维度的用户词汇元素

“原因”维度中一些数据元素用于标识业务对象，如业务事务、来源、目的地和转化标识符。对于此类数据元素，核心业务词汇提供可用于构建合适标识符的模板。

请注意，EPCIS事件的任何维度中的标识符应明确。当将整个供应链的EPCIS事件整合到一起时，这一点尤为重要。假设运送步骤EPCIS事件中的BusinessTransaction数据元素包含对采购订单的引用。EPCIS事件不能仅简单提供“PO编号1234”，因为供应链中的许多公司可能会发出具有相同编号的采购订单。在EPCIS事件中，对采购订单的引用必须具有全球唯一性。

核心商业词汇表通过提供用于构建全球唯一标识符的模板来解决这个问题。其形式如下：

4.7.3.3 urn: epcglobal: cbv: bt: 0614141111114:1234

第一部分（urn：epcglobal：cbv: ）表示其根据CBV中的规则构建。下一部分（bt: ）表示其为业务事务（BT）模板。接下来是定义PO编号的一方的GLN（0614141111114），最后一部分（1234）是该方定义的PO编号。在这种情况下，如果供应链中的其他方也拥有编号为1234的POE，则EPCIS标识符将会不同，因为标识符中1234之前GLN不同。

一些大公司拥有多个采购订单生成系统，例如用于公司各部入口的不同系统，所以同一个公司可能生成两个编号为1234的采购订单。但是，使用不同GLN作为两个系统的PO编号的前缀可以轻松解决这个问题；例如通过使用部门级GLN。

这是构建CBV（第8.5节）中定义的全球唯一业务事务标识符的几种方法之一。另一种方法是使用GSTI KEY，如GDTI（包括序列号）。如果生成业务事务的系统已经使用GS1 KEY作为编号系统，则可以使用该方法。CBV还说明了使用私有前缀创建业务事务标识符的方法，尽管此类方法很少使用。

EPCIS转化事件的高级使用有时需要使用“转化ID”来关联多个事件。CBV第8.7节介绍了转化ID的构建方法，包括类似于上述的基于GLN的方法。

来源和目的地标识符在CBV第8.6节中进行了描述。通常，此类标识符均使用GLN填充，因此，以与位置标识符相同的方式使用SGLN EPC URI格式（第4.7.2节）。

4.7.4 示例

综合本节的所有内容，下面将说明将第4.6 节中作出的设计选择最终转换成为EPCIS事件中的实际标识符的方法。

表4-6第4-6节中EPCIS事件标识符分配示例

对于您在第4步中确定的每个业务步骤，必须完成第5步到第7步。这听起来有点冗长乏味，但在通常情况下，其存在较多重复，所以在前三四次事件发生后，就会逐渐熟练。

完成所有工作后，将结果汇总在矩阵中，该矩阵的列用于记录可视性事件，行用于记录EPCIS数据模型中的数据元素。其与上一节列出的表格类似，但多了可用于记录事件的列。可使用电子表格创建这种矩阵。

以下将给出我们的示例中事件V1到V4的可能矩阵：

表4-7 可视性数据矩阵示例

此示例矩阵显示了用文字描述的事件内容，如上文第6步所述。可以适当举例说明步骤7中作出的特定标识符选择（为节省空间，此处省略）。

下节将提供一些关于如何针对特定情况设计EPCIS事件的更多示例。

许多业务过程涉及创建物理聚合，其中将子对象置于父对象中或父对象上。聚合具有以下特征：

■ 处于聚合状态时，可以假定父对象和子对象在同一时间会处于同一地点。

■ 父对象和子对象在聚合状态下保留其身份。可以反向进行聚合（解聚），以使原始父对象和／或子对象相互分离。其与转化不同，在转化中，输入会不可逆转地转化为具有不同特征的产出（请参见第5.5节）。

常见聚合示例如下：

表5-1常见聚合示例

上述示例均假定子对象使用实例级标识进行标识，但也可以使用类别级标识来标识子对象。但是，父对象必须始终使用实例级标识符进行标识。

跟踪聚合的一个常见原因是方便进行推断，其中，仅在观察到一个对象时，业务应用才会推断所有聚合对象都存在。例如，在第4节的示例中，运输步骤的EPCIS事件仅包含托盘的SSCC，但接收方也可以推断所有箱子也已装运。进行这种推断时，接收方需要了解（a）创建聚合的包装步骤的EPCIS事件；和（b）了解包装步骤和运输事件之间没有解聚事件。

5.1.1 聚合和解聚

EPCIS汇总事件的操作数据元素说明事件期间针对聚合进行的操作：

表5-2聚合事件的操作值

为便于说明，下面将给出含有五个步骤的业务过程：

1. 发货方将5个同质箱子（均由SGTIN标识）装入托盘（由SSCC标识）。

2. 发货方运送托盘，仅标注托盘标识符。

3. 接收方收到托盘并验证所有箱子标识符。

4. 接收方从托盘中取出两个箱子。

5. 接收方从托盘中取出剩余箱子。

下表将显示与此类步骤相对应的五个EPCIS事件的内容（为简洁起见，省略了“时间”和“地点”维度）：

表5-3 EPCIS聚合事件信息内容示例

5.1.2 多级聚合

一些业务过程可能涉及多级聚合；例如先将项目装箱，然后将箱子装入托盘。在此类情况下，内部聚合的父对象是外部聚合的子对象。

直接通过创建多级聚合在EPCIS中对其进行建模，每个事件对应于各级别上的父对象。例如，如果将五个项目装入一个箱子，并将三个这样的箱子装入一个托盘（总共15个项目），则总共将有四个聚合事件：将项目装入箱子的三个事件以及将箱子装入托盘的一个事件。假定同质箱子使用SGTIN标识，托盘使用SSCC标识（为简洁起见，省略了“时间”和“地点”维度），则事件结构如下：

表5-4两级层次结构的EPCIS聚合事件信息内容示例

EPCIS活动中的来源和目的地数据元素详细描述了作为业务转让一部分的过程步骤——将对象所有权和／或拥有权从一方转让给另一方。EPCIS事件中的每个来源或目的地均具有相关类型；CBV规定可以使用以下三种类型：

表5-5核心业务词汇中定义的来源／目的地类型

在最简单的业务转让情况下，来源和目的地的所有方和拥有方相同，且位置也与此类相关方一致。但是，也可能出现更为复杂的情况。

比如说“直接装运”情况。在这种情况下，药品制造商M将产品销售给批发商W，批发商W又将产品销售给医院H。批发商并未存储产品，而是安排M直接运送给H。但是在与H进行后续销售事务前，批发商仍拥有产品的所有权。

以下两个事件将说明如何在EPCIS中表示这种情况（为简洁起见，省略了“时间”维度）：

表5-6“直接装运”情况示例的EPCIS事件信息内容

如第4.6.1节所述，EPCIS允许以实例级别或类别级别标识对象。本指南中的大部分示例（包括本节前面的所有示例）都使用实例级标识。本节将介绍使用类别级标识时的一些特殊考虑因素。

5.3.1 使用类别级标识的可追溯性的固有限制

与实例级标识相比，类别级标识具有固有限制。实例级标识允许精确确定哪些EPCIS事件涉及特定对象，以及在不同时间发生的两个EPCIS事件是否涉及相同对象。相比之下，类别级标识是指一类不能相互区分的对象。对类别级追溯系统的影响是，其设计必须可以容纳模糊性内容。

例如，请考虑使用类别级标识的以下事件序列：

■ V1：制造商创建了20个新产品实例（均仅使用GTIN和批号标识）

■ V2：制造商将10个产品实例发送给接收方

■ V3：制造商将另外10个产品实例发送给相同接收方

■ V4：接收方收到10个产品实例

下表显示了此类EPCIS事件的内容：

表5-7使用类级别标识的EPCIS事件信息内容示例

在该示例中，不可能确定事件V4中，于7月25日收到的10个单元（GTIN X，批号12）是否为7月16日运送的10个单元（事件V2）或7月17日运送的10个单元（事件V3）。这并不是EPCIS造成的限制；这是使用类别级标识的根本限制。

因此，使用类级别数据后，常见跟踪和追踪任务可能会更复杂。假定需要召回产品，以确定给定批次中所有实例的当前位置，进而将此类实例从供应链中移除。如果使用实例级标识，则批次中每个实例都拥有唯一的序列号，且此类序列号可以在调试业务步骤中获得。召回应用仅需针对每个实例标识符找到近期EPCIS事件，且每个事件的业务位置指示当前位置（至少可根据EPCIS数据推断）。每个实例标识符可能出现在多个EPCIS事件中，但由于给定实例不能同时位于两个地方，所以每个实例的最新事件都会给出其当前位置。

现在考虑在同一批次中不同实例可能通过供应链中的不同路径的情况下，尝试使用批次级标识执行相同策略。仅找到该批次的最新EPCIS事件并不一定能确定所有对象的位置。在上述示例中，批次12的最新EPCIS事件是事件V4，但仅占20个单元中的10个。其他10个单元仍在运输中（对应于事件V2或V3）。需要进行复杂分析，尝试统计进入和退出每个站点的数量，以便确定批次目前所在的所有位置。

使用类别级标识的应用必须仔细考虑如何使用数据，以及必然出现哪些限制。

5.3.2 类别级标识的生命周期开始事件

使用实例级标识时，任何给定实例都只有一个含有该实例标识符的生命周期开始事件。这种事件可以是附带操作“添加”的对象事件，也可以是转化事件（其中实例标识符是产出）。业务步骤是调试（根据CBV），或一些更专业的业务步骤（根据另一个语义类似于调试的词汇）。

使用类别级标识时，可能会有多个具有相同类别标识符的生命周期开始事件，每个事件代表额外数量的类别的生命周期开始。例如，制造过程可以每小时生产一个托盘，并为每个托盘生成EPCIS事件，一天内生产的所有托盘构成一个批次。

每小时EPCIS事件代表在该小时内生产的实例的生命周期开始。

CBV规定了类别级标识符的调试，以说明将先前未使用的标识符与类别中一个或多个对象相关联的过程。也就是说，调试不仅代表了对象的生命周期开始，而且代表了标识符的生命周期开始。对于给定标识符，应仅存在一个业务步骤为调试的EPCIS事件。

为应对同一类具有多个生命周期开始事件的情况，CBV还将创建类别实例定义为附加业务步骤类型。与调试不同，创建类别实例只意味着对象的生命周期开始，与标识符的生命周期无关。

如果在首次使用类别级标识符时意识到业务过程（例如，当启动新产品批次被时），业务步骤“调试”可以用于创建新批次实例的收个EPCIS事件，步骤“创建类别实例”可以用于创建该批次的其他实例的后续事件。有时，可能无法确定哪个EPCIS事件首次使用类别级标识符；在此类情况下，创建类别实例可以用于创建该类实例的所有事件。

5.3.3 聚合中的类别级标识

聚合事件可能包含使用类别级标识标识的子对象。但是，父对象必须始终使用实例级标识进行标识。

例如，假设同质箱产品已被订购、装运和接收，但此类箱子仅使用GTIN和批号标记。事件可能如下所示（为简洁起见，省略了“时间”和“地点”维度）：

表5-8类别级标识子对象聚合的EPCIS事件信息内容

在该示例中，接收方可以使用先前聚合事件推断，其接收的托盘包含10个GTIN X单元（批次12）和20个GTIN Y单元（批次52）。后续事件可能将产品与托盘分离，再次确定分离后，属于该类别的具体数量。

不允许使用类别级标识符来标识聚合的父对象。这是因为仅在每个聚合具有不同身份（如由父标识符表示）时才可进行推断，如果无法进行推断，则尝试记录聚合不会提供任何帮助。

为便于说明，请考虑以下情况：两个不同的箱子（均带有相同的GTIN+批次标识符）装有不同的内容物，然后运送和接收其中一个箱子：

表5-9具有类别级父对象（不允许）的假定EPCIS聚合事件信息内容

接收方知道其收到的箱子由GTIN P，批次111标识，但无法推断出该箱子的内容物是10个GTIN X单元和20个GTIN Y单元，还是20个GTIN X单元和30个GTIN Z单元。

仅使用类别级别标识聚合父对象和子对象的最常见情况是，将使用GTIN或GTIN +批次标识的项目装入具有固定组成的箱子，而箱子也使用GTIN或GTIN +批次标识，例如，包装含有12个项目（含有项目级GTIN Y）的标准箱子（含有箱子级GTIN X）。在这种情况下，GTIN X专入口用于代表12个单元的箱子（GTIN Y）。两个GTIN之间的关系（包括项目计数）以主数据表示。

完成这一步后，无需创建聚合事件来显示将12个GTIN Y单元装入一个GTIN X单元中——根据定义，每个GTIN X单元包含12个GTIN Y单元。因此，尽管EPCIS中可能针对GTIN X和GTIN Y记录了调试业务步骤，不会有聚合事件。如果装运了10个GTIN X箱，则货物的EPCIS事件可以指出10个GTIN X单元（在这种情况下，可以根据主数据推断出120个GTIN Y单元），也可以指出120个GTIN Y单元（在这种情况下，EPCIS数据并不表明货物为散装还是打包装入12个单元的箱子中。

以上示例仅考虑使用GTIN标识的项目和箱子。如果项目和箱子使用GTIN +批次标识，则特定箱子中所有项目必须具有相同批号，且该相同批号也应是箱子的批号。事实上，在使用GTIN +批次标识标识项目和箱子时，通常进行这种操作。

（请注意，根据GTIN管理标准，不允许存在原本“错误”的示例：如果箱子没有固定组成，将其视为物流单元而不是贸易项目，因此将使用SSCC（实例级标识符）而不是GTIN标识。）

5.3.4 在同一事件中混合使用实例级和类别级标识

EPCIS事件可能混合使用实例级和类别级标识。例如，订购的托盘中可能有产品一个由SGTIN标识，另一个由GTIN+批次标识，另一个仅由GTIN标识。下面将提供示例（为简洁起见，省略了“时间”和“地点”维度）：

表5-10以实例级别和类别级别标识子对象时，EPCIS聚合事件信息内容

如前所述，聚合事件允许接收方推断托盘的内容物，在这种情况下，事件可能混合使用实例级和类别级标识。

混合使用实例级和类别级标识在制造期间出现的转化事件中特别常见，因为制造过程中的成分包括以实例级别标识的“主要”成分和仅以类别级别标识的“次要”成分。例如：

■ 输入：

□ 金枪鱼鱼柳（每份鱼柳单独标有序列号，由SGTIN——实例级标识）

□ 橄榄油（由GTIN +批次——类别级标识）

□ 空罐（由GTIN标识，以区分两种可能的罐供应商）

■ 输出：

□ 金枪鱼罐头（可以以实例级别（SGTIN）或类别级别（GTIN +批次）标识，具体取决于业务需求）

请注意，当实例级和类别级标识符在相同EPCIS事件中混合使用时，每个标识符应指代不同对象。以下示例不正确：

表5-11错误地将实例级和类别级标识用于相同对象的EPCIS事件信息内容

如示例所述，该事件表示已将六个GTIN X单元装入托盘：三个单元拥有序列号，另外三单元仅拥有批号。这可能不符合预期。

如果希望指出与使用GTIN +序列号标识的项目相关的批号，则事件中应仅提供SGTIN，且通过调试事件的实例／批次主数据针对此类序列号提供批号（请参见第5.4节）。

如EPCIS 1.1标准第7.3.6节所述，实例／批次主数据（ILMD）是描述物理或数字对象的特定实例或批量／批次生产的特定对象批量／批次的数据。其与普通主数据类似，包含一组描述性属性，提供对象相关信息。但是，尽管主数据属性的值对于大类对象相同（例如，对于具有给定GTIN的所有对象），但对于小型对象分组，ILMD属性的值可能不同（例如，单批或多批），且对于每个对象也可能不同（即对于每个实例不同）。

可以想象，实例和批次级主数据可以在EPCIS外部的贸易伙伴之间通信，就像GTIN级主数据可以使用全球数据同步网络（GDSN）在EPCIS外部通信一样。但是，目前尚未建立完善的实例或批次级主数据通信机制。因此，EPCIS提供一种方法，用于将实例和批次级别的主数据附加到标志新实例生命周期开始的EPCIS事件。

对于以实例级标识的对象，实例的主数据存储于该实例的调试事件中，或者如果所创建的实例为转化输出，则转化事件。例如，下表显示了三个EPCIS事件的内容，包括调试步骤产生的实例级主数据（为简洁起见，省略了“时间”维度）：

表5-12显示实例／批次主数据（ILMD）的EPCIS事件信息内容

请注意，当以实例级别标识对象时，其批号（如有）是该实例的主数据属性。

在上述示例中，如果接收方希望获取其接收的产品实例的主数据，则可以要求制造商提供“内容”维度中具有指定SGTIN，并具有业务步骤调试（来自CBV）的事件。

在EPCIS事件的XML表示中，使用EPCIS名称空间以外的XML名称空间中定义的元素来表示ILMD。CBV标准使用XML名称空间urn：epcglobal：cbv：mda来定义常用的主数据属性。

此类主数据属性的定义与其他GS1标准（包括GDSN和GS1 EDI）中使用的定义相匹配。其他主数据属性可以在其他标准中定义或者由贸易伙伴事先商定；除EPCIS或CBV名称空间以外，此类属性必须具有XML名称空间。

上述事件V1在XML中的可能形式如下（为简洁起见，部分省略）：

批次级主数据与实例级主数据的工作方式相同。与实例级标识相反，使用批次级标识时，同一批次可能会有许多生命周期开始事件（具有业务步骤“调试”或“创建类别实例”的对象事件或转化事件）。该批次的ILMD可以在所有此类生命周期开始事件中提供，但ILMD的内容对于同一批次的所有事件必须相同。

当同时使用调试和创建类别实例业务步骤时，可以仅在调试步骤中提供ILMD。

EPCIS转化事件用于表示一个业务过程步骤，在该步骤中，一个或多个对象完全或部分作为输入消耗，一个或多个对象作为输出生成。转化事件采集输入和输出之间的关系，即任何输入可能以某种方式对每个输出作出贡献。

与聚合相比，转化不可逆转。转化后，已消耗的输入不再存在，输出成为转化前不存在的全新对象。在这种情况下，转换事件可以作为输出的生命周期开始事件，并作为输入的生命周期终止事件（除非输入未完全消耗）。

常见转化示例如下：

表5-13转化业务过程示例

跟踪转化的一个常见原因是让业务过程了解什么样的输入会影响输出。例如，如果发现来自特定农场的精选肉受到细菌污染，则转化事件允许向前追踪以确定可能受到污染精选肉影响的所有成品肉类产品。相反，如果发现成品被污染，转化允许向后追踪，以确定所有成分，然后可以向前追溯，确定可能受到影响的成品。

5.5.1 转化事件示例

考虑以下制造过程：

■ 输入：

□ 金枪鱼鱼柳（每份鱼柳单独标有序列号，由GTIN X加序列号——实例级标识）

□ 橄榄油（由GTIN Y+批次——类别级标识）

□ 空罐（由GTIN Z标识，以区分两种可能的罐供应商）

■ 输出：

□ 金枪鱼罐头（由GTIN Q+批次——类别级标识）

过程运行一次生成的事件如下所示（为简洁起见，省略了“事件”和“地点”维度）：

表5-14 EPCIS转化事件信息内容示例

由于转化是产出的生命周期开始，所以使用生命周期开始业务步骤和处置。在这种情况下，转化会创建批次999的新实例，因此，将“创建类别实例”用作业务步骤。如果知道该事件是首次创建批次999，则可以使用调试。

5.5.2 长期转化

有时，转化会持续很长一段时间，其中定期添加输入，并定期提取输出。例如，混合过程可能会在产品运行过程中分几批消耗输入，即使添加更多输入，也将取出输出。

长期转化可以用单个EPCIS事件建模，该事件应列出整个时间间隔内涉及的所有输入和所有输出。但这引起了“如何确定事件时间”这一问题。大多数情况下，过程完成的时间是适当的事件时间。

但是，并不总是需要将长期转化建模为单个EPCIS事件。如果某些输出对象在转化完成之前还需要经受其他业务步骤，情况尤其如此。例如，假定过程将混合输入成分来生产油漆罐，且在这个过程中，涉及同一混合桶的生产过程将连续运行一周。该过程可能在周一生产油漆罐，在周二进行运送，但是在周三和周四会从同一混合桶中取出更多油漆罐，整个转化在周五结束。在这种情况下，可能需要有创建EPCIS事件来代表星期一的生产情况，使得星期二生成的运输事件可以使用新的油漆罐标识符。

为模拟此类情况，转化事件可能会被拆分成多个EPCIS事件。为保持所有输入和输出之间的关系，使用转化标识符来链接多个转化事件。其也是唯一标识符，对于属于相同转化（即在输入和输出之间存在关系的情况下）的所有EPCIS事件相同，但与其他无关事件中使用的转化换标识符不同。

以下系列事件相当于前述转化，但有一个附加事件，用于显示前几罐待生产金枪鱼的运送情况。

表5-15通过转化ID连接的EPCIS转换事件信息内容示例

核心业务词汇提供可用于构建转化ID的模板。

EPCIS不限于跟踪物理对象。EPCIS也可用于跟踪数字交易项目（音乐下载，电子书等）、数字文档（电子优惠券等）等数字对象。在大多数情况下，数字对象的业务过程与物理对象相似，可以使用相同的核心业务词汇业务步骤和配置。

本节将列出跟踪数字优惠券生命周期的两个过程，以说明应用于数字对象的EPCIS。数字优惠券由制造商或零售商发行，在消费者购买特定贸易项目时，向消费者提供有价值物品（现金折扣、折扣或附加贸易项目）。

制造商或零售商给出的特定报价可以使用全球优惠券编号（GCN）标识，且发行给消费者并由其兑换的特定报价实例可以使用带序列号（SGCN）的全球优惠券编号标识。与GCN相关的主数据可以提供关于报价的详细信息，例如所需购买的GTIN、现金折扣的数额等。数字代金券（例如通过瓶罐回收机发放给消费者，并由消费者在销售点兑换的代金券）以类似方式工作。

下面将举例说明两个过程：由制造商发行优惠券，并在销售点由零售商进行兑换的简单过程，以及涉及优惠券代理人的复杂过程。

这两个示例旨在说明将EPCIS用于数字对象的一般概念。有关如何对优惠券过程进行建模的具体细节，请参见GS1应用标准或当地建议。

5.6.1 简单优惠券过程

在最简单的优惠券过程中，仅有两个步骤需要EPCIS事件：

■ V1：优惠券发行者向消费者发行数字优惠券。通常，优惠券发行者是零售商，但也可以是制造商或第三方。优惠券通常通过消费者在其设备上使用的移动应用发给消费者。优惠券的SGCN存储于该应用中以用于下一步。生成EPCIS事件以指示优惠券是否已激活。

■ V2：消费者在零售店（无论是实体还是线上）结账时，都可以在销售点终端兑换优惠券。销售点应用将验证优惠券是否有效，以及报价条件是否已得到满足；如果是，则允许兑换优惠券，并生成EPCIS事件以表明优惠券不再有效。

分别使用调试和退役业务步骤在EPCIS中表示这两个事件。

表5-16简单数字优惠券业务过程的EPCIS事件信息内容示例

在调试步骤（V1）中，可以使用ILMD来记录优惠券的属性，例如相关GTIN、优惠券可兑换的日期范围、消费者的优惠卡编号等。

采集到EPCIS事件后，可以使用EPCIS查询确定给定时间范围内激活的优惠券总数、给定GCN（类别级）的优惠券总数、尚未兑换（但仍然有效）的所有SGCN、兑换次数和优惠券激活／兑换之间的时间段等。

5.6.2 存在优惠券代理人的优惠券示例

前述示例假设，仅有两个事件需要在EPCIS中进行跟踪：向消费者发行优惠券，以及在销售点兑换优惠券。但与任何业务过程一样，优惠券兑换过程在实践中可能会更加复杂，且其可用于在EPCIS中对更多过程步骤进行建模。例如，在更复杂的情况下，可能存在需使用EPCIS记录的四个步骤：

■ V1：优惠券发行者（零售商或制造商）向优惠券分发者（例如专门从事电子优惠券的互联网应用提供商）发放一批优惠券。

■ V2：优惠券分发者向消费者发行数字优惠券。

■ V3：消费者在零售店（无论是实体还是线上）结账时，都可以在销售点终端兑换优惠券。

■ V4：优惠券分发者和发行者之间进行最终结算。

与前述示例一样，此类业务步骤中的每一个都可以建模为EPCIS事件。在该示例中，将优惠券发给分发者时，而不是分发者向消费者发行优惠券（后者更类似于消费者的接收操作）时，在V1中进行调试。在最终结算步骤V4期间，而不是消费者兑换优惠券时进行退役。

由于核心业务词汇未涵盖对这四个事件建模所需要的所有业务步骤和处置值，因此本文不会进行详细说明。GS1将来可以制定优惠券追踪的具体标准或指南。

但需注意的时，“内容”是物理对象还是数字对象，以及相同分析和设计过程是否可用于使用EPCIS对业务过程进行建模。

本节将说明如何使用EPCIS采集可回收资产的跟踪事件，如聚合托盘或提袋。各可回收资产都使用包含唯一序列号的GRAI进行标识。

有两个相互联系的业务过程，一个由可回收资产管理方执行，另一个由资产用户执行。第一个过程如下所示。

表5-17可回收资产管理业务过程示例的流程图

该过程通常在从V2到V9，再到资产用户业务过程，然后返回V2这一循环内运行。在V3中检查用户收到的资产。如果损坏，则在V4中尝试修复，如果资产不可修复，则在V5中销毁该资产。否则，或者如果检查未发现损坏，在V6中清洁资产，并在V7中与其他类似资产一起入库。用户订购一个或多个空资产后，在V8中进行挑选，向用户开具发票后，在V9中将其运送给用户。然后进入资产用户业务过程。

管理可回收资产的一方可能想要追踪上述所有九个事件。下面将说明其在EPCIS中的建模方式。在所有情况下，“内容”维度应包括该步骤所涉资产的GRAI，而“地点”维度应包含资产管理者机构内的适当位置。下面，为简洁起见，将省略“内容”、“时间”和“地点”维度。

表5-18可回收资产管理业务过程（V1 - V4）的EPCIS事件信息内容

表5-19可回收资产管理业务过程（V5 – V9）的EPCIS事件信息内容示例

有关此类事件的备注：

■ 在V3中，配置和接下来将发生的内容取决于检查结果：

□ 如果资产状况可接受，则处置为“进行中”（来自CBV），且下一步是V6（清洁）。

□ 如果资产状况不可接受，则处置为“损坏”（来自CBV），且下一步是V4（修复）。

■ 在V3中，配置和接下来将发生的内容取决于修复尝试的结果：

□ 如果资产被成功修复，则处置为“进行中”（来自CBV），且下一步是V6（清洁）。

□ 如果资产不能修复，则处置为“损坏”（来自CBV），且下一步是V5（销毁）。

■ 在V6中，没有与“清洁”相对应的CBV业务步骤，所以可以使用私有词汇元素。

在V9后，资产用户使用空资产来使货物通过用户自己的供应链。可回收资产可能有两种使用方法：

■ 用户可能根本不知道或者不使用资产的GRAI。在这种情况下，资产仅为“无用”托盘或提袋，且其GRAI不会录入任何EPCIS事件。用户可以使用其GTIN跟踪资产上装载的产品，和／或将SSCC与资产所承载的完整物流负载相关联，但此类使用与资产管理者使用GRAI完全无关。

■ 用户可以使用资产的GRAI以及含有该GRAI的条码或RFID数据载体。

EPCIS数据模型应包括业务应用理解业务过程步骤中发生的内容所需的所有相关“内容、时间、地点和原因”信息。但是，业务应用有时需要的信息超出了EPCIS标准中定义的数据元素。为解决这种情况，EPCIS事件可以携带用户／供应商扩展数据元素。

用户／供应商扩展数据元素就是添加到EPCIS事件中的任何数据元素。大多数情况下，此类元素表示附加业务环境，因此可以视为事件“原因”维度的补充信息，但由于未对扩展内容进行限制，其也可以涉及任何其他维度。

在EPCIS事件的XML表示中，扩展数据元素表示为XML元素，其XML名称空间与EPCIS名称空间不同。EPCIS标准和CBV标准均未定义任何具体的扩展数据元素，所以必须在其他标准中进行定义（例如，部入口特定标准或贸易组织内颁布的标准），或者由贸易伙伴事先另行商定。

为便于说明，下面将给出EPCIS事件示例，其中，该事件拥有两个附加数据元素，以便在使用冷冻包装箱运输项目中进行观察时，记录对象的温度和湿度。

表5-20用于说明用户／供应商扩展的EPCIS事件信息内容

以下是上述事件的XML表示方法：

在该示例中，两个扩展元素位于示例公司规定的XML名称空间中。使用XML名称空间不仅可以与标准EPCIS数据元素扩展区分开来，还可确保示例公司的扩展不会与可能使用相同元素名的其他组织的扩展混淆。

在使用扩展元素时，应遵守以下准则：

■ 扩展元素必须事先由贸易伙伴商定，否则可能误读。

■ EPCIS标准数据元素应始终优先于扩展数据元素应用，因为其更具互操作性。

■ 用于扩展的XML名称空间URI应可由规定扩展的组织进行控制。建议使用基于定义组织Internet域名的HTTP URI。

■ 扩展元素应包括提供有关其所在事件的附加数据的信息。其不得用于传达与事件无关的数据。具体来说，可视为与实例级或批次级标识符有关的主数据的数据应录入事件的ILMD部分，而不是作为扩展元素。请参见第5.4节。

■ 扩展数据元素可以包含任何符合格式的XML内容（包括子元素和属性）。但是，EPCIS SimpleEventQuery仅可查询值为数字或字符串的扩展元素。

■ EPCIS XML方案中定义的XML元素<extension>不得用于携带用户或供应商扩展。<extension>元素仅供EPCIS标准本身使用，以便在EPCIS标准的后续版本中引入新的数据元素。

■ EPCIS数据接收应用不得仅因为数据包含应用无法识别的扩展而拒绝EPCIS事件。应忽略此类扩展，或者进行记录或保存，但不进行进一步解释。另一方面，如果其内容违反了贸易伙伴预先确定的确认标准，则可能基于该标准拒绝扩展。

如本指南所述，在EPCIS中，如需对业务过程进行建模，需将其分解为一系列步骤，并将每个步骤建模为EPCIS事件。最后，根据EPCIS和CBV标准，以及任何其他相关词汇标准中指定的语义解释事件时，与特定对象（“跟踪”）有关的所有事件集合应可正确指示该对象的历史和当前状态。

有时，先前记录的事件并不能准确反映现实世界中发生的事件。但是，EPCIS采集接口和EPCIS查询接口都不能提供可供应用删除或修改EPCIS事件的手段。“撤销”或“纠正”EPCIS事件的唯一方法是生成后续事件，使其具有撤销或修改先前事件效果的业务含义。最终，完整追踪（包括新事件和所有先前事件，包括错误事件）应可准确反映上述原则所述的历史和当前状态。

生成附加事件的首选方法是承认发现错误事件及其补救本身是一个业务过程，以便通过创建合适的EPCIS事件来进行建模。在大多数情况下，这可以使用第4节中讨论的相同方法完成。

示例1：X公司记录了一个EPCIS事件，表明一些产品（其序列号为101、102和103）被运送到Y公司。Y公司收到货物，发现除序列号为101、102、103的产品外，还有序列号为104的产品。与X公司商榷时，确定确实运送了序列号为104的产品，运输事件错误。补救：X公司记录一个新的EPCIS事件，表明其运送了序列号为104的产品，且其环境信息与原始事件类似。

示例2：X公司记录了一个EPCIS事件，表明已将一些产品（其序列号为101、102和103）运送到Y公司。Y公司收到货物，仅发现序列号为101、102的产品。与X公司商榷时，确定序列号为103的产品未被运送，仍留在X公司的库存中。其同意免除第三个产品的账单。

补救：X公司记录一个新的EPCIS事件，表明序列号为103的产品的运送无效。

在第一个示例中，附加事件使用与第一个相同的业务词汇。在第二个示例中，使用与宣布装运无效的过程特别相关的词汇，但其仍然具有“普通”EPCIS语义，因为其旨在模拟完善业务过程步骤的完成情况。这表明，补救行为就是一个业务过程，因此可以建模为EPCIS事件。

在某些情况下，无法（或者无需）通过创建具有普通语义的新EPCIS事件来补救对象历史。

示例3：X公司记录了一个EPCIS事件，声明序列号为101的产品X已被销毁。该事件属于对象事件，且其操作=删除。后来发现序列号为101的产品仍在存储中，尚未销毁。无法使用普通事件修改历史，因为对象事件动作“操作”的语义规定：“此类…对象不得出现在后续事件中”。

示例4：X公司记录了一个EPCIS事件，表明有多个产品已经装运，并在“原因”维度中将采购订单123指定为业务事务。Y公司收到产品并记录接收事件。然后发现运输事件中的采购订单引用错误：其显示PO 456，而不是123。这可以通过使用普通EPCIS事件来进行纠正，即由X公司记录“无效装运”事件，然后记录具有正确PO编号的“装运”事件。但是从整体追踪来看，不建议使用这种方法，尤其是已经存在接收事件。

为解决这种情况，EPCIS提供一种机制来构建一个事件，使其具有表明先前事件的声明错误的语义。这种事件被称为“错误声明事件”。

以下章节将详细说明纠正错误的各种方法。

5.9.1 示例1：使用普通事件进行纠正——简单添加

在该示例中，X公司记录了一个EPCIS事件，事件表明一些产品（其序列号为101、102和103）被运送到Y公司。Y公司收到货物，发现除序列号为101、102、103的产品外，还有序列号为104的产品。与X公司商榷时，确定确实运送了序列号为104的产品，运输事件错误。

为进行补救，X公司应记录一个新的EPCIS事件，表明运送了序列号为104的产品，且其环境信息与原始事件类似。

两个事件如下所示：

表5-21通过在纠正业务步骤添加普通事件来纠正错误的示例。

5.9.2 示例2：使用普通事件进行纠正——纠正业务步骤

在该示例中，X公司记录了一个EPCIS事件，表明已将一些产品（其序列号为101、102和103）运送到Y公司。Y公司收到货物，仅发现序列号为101、102的产品。与X公司商榷时，确定序列号为103的产品未被运送，仍留在X公司的库存中。其同意免除第三个产品的账单。

为进行补救，X公司应记录一个新的EPCIS事件，表明序列号为103的产品的装运无效。这使用专用于此目的的业务步骤“无效装运”。由于新事件仅涉及序列号103，因此不会影响其他序列号101和102的装运事件，所以即使在收到“无效装运”事件之前，也可以继续此类序列号。

两个事件如下所示：

表5-22通过添加普通事件来纠正错误的示例。