电子产品代码信息服务

电子产品代码信息服务（EPCIS，Electronic Product Code Information Services）是GS1制定的供应链可视性数据标准，用于让彼此独立的应用系统创建和共享事件数据，既可用于组织内部，也可用于供应链参与方之间。事件记录某个业务流程步骤对一个或多个对象发生了什么，为不同参与方理解产品、资产或其他对象的状态变化提供共同数据结构。

EPCIS中的“对象”可以是商品、物流单元、可循环资产、固定资产、物理文件，也可以是参与业务流程的数字对象。对象可按单件实例识别，也可按某个类别或数量表达。每条可视性事件记录的是某个业务流程步骤对一个或多个对象发生了什么；把不同参与方在各个时点产生的事件按对象、时间和业务情境关联起来，系统可形成可查询的流程视图，用于追踪、追溯和供应链可视性分析。

“EPC”是Electronic Product Code（电子产品代码）的缩写。虽然EPCIS最初与电子产品代码及射频识别的发展相关，但GS1标准明确说明，EPCIS不要求使用电子产品代码，不要求射频识别标签，也不要求所有对象都具有单件级标识。因此，EPCIS不是某一种条码或射频识别技术，也不等同于产品编码规则；它规范的是事件数据如何建模、捕获、交换与查询。

EPCIS 2.0将事件信息概括为“什么、何时、何地、为什么、如何”五个维度。“什么”标识事件涉及的对象，可为单件标识，也可为类别与数量；“何时”记录事件发生时间及相关时间信息；“何地”描述事件发生的读取点和业务地点；“为什么”描述业务步骤、处置状态以及相关交易或流程背景；“如何”指事件主体对象的状况，并根据采集到的传感器数据填充。EPCIS 2.0还设有独立的可选认证详情字段，不应与“如何”维度混为一谈。

五个维度是组织事件信息的视角，不要求每条事件都包含所有类型的附加资料。理解时间字段时要区分三种时间信息：事件时间是捕获应用断言事件发生的日期和时间；记录时间是EPCIS Repository记录该事件的时间，属于系统记账信息；每条EPCIS事件还须提供时区偏移字段，用于表示事件发生地点和时点有效的当地UTC偏移，该偏移未必与事件时间所用的时区标记相同。若事件稍后才上传，发生时间与记录时间有助于区分业务顺序和入库顺序，但不能单凭记录时间推断业务环节实际先后。

对象标识的粒度也决定事件能够回答什么问题。实例级标识可指向某一件具体对象；类别与数量则表达某一类对象的总量，并不指出每件对象各自的身份。后者可用于按类别记录的场景，但不能把数量记录解读为已逐件识别或追踪。选择何种粒度，应与业务所需的追溯深度和现场可采集的信息相匹配。

事件类型也影响“什么”所表示的关系。对象事件记录与一个或多个物理或数字对象相关的事件；大多数对象事件表示实际观察，也可记录捕获应用希望就对象作出的其他断言。对象事件的动作字段涉及对象及其标识的生命周期。聚合事件表达容器与所含对象之间的物理组合关系；交易事件可将对象与特定业务交易关联；转换事件用于描述输入对象被消耗并产生输出对象；关联事件则描述对象与父对象或特定物理地点之间的关联或解除关联，适用于超出装载、卸载等临时物流组合的关系。EPCIS 2.0定义这五种核心具体事件类型，并允许通过标准机制扩展。两个托盘即使属于同一运输批次，也不必然构成“一个装有另一个”的聚合关系；选择事件类型时需看记录的是哪一种业务联系。

EPCIS将事件类型与数据字段结构标准化，并定义捕获和查询接口。适配后的业务应用或数据采集系统可将事件提交给捕获接口；授权的查询应用再按对象、时间、地点、业务步骤等条件查找事件。GS1标准架构中的EPCIS Repository是记录事件、供后续查询的逻辑角色。标准定义数据共享接口，但不规定Repository、服务操作或数据库内部如何实现；实现可选择内部存储和查询技术，只要客户端可见结果符合规范。

事件数据与主数据承担不同工作。事件数据记录带有时间背景的业务活动，主数据和词汇信息则可为事件中的对象、地点或业务步骤标识提供解释。例如，事件里出现一个地点标识，并不等于事件本身已经写明该地点的完整地址；查询方可能需要关联相应主数据。主数据可以随事件一同提供，也可以通过其他途径管理，EPCIS标准不要求所有事件必须附带主数据，因此跨组织交换时需要考虑接收方是否能够解释所用标识。

事件可以存入持久化Repository，之后由查询应用访问；也可以在无需持久数据库时由应用系统直接共享。标准架构还显示可用于实时推送或回调的旁路，但这不是所有部署都必须具备的功能。因此，EPCIS不要求使用单一中央Repository或统一的持久化事件库。

假设配送中心接收一箱商品，扫描后装到托盘，再将箱件拆分发往不同目的地。收货事件可描述对象、时间、读取点、业务步骤和当时状态；装载时的聚合事件则可关联托盘这一“父项”与箱件这一组“子项”，拆分时再记录关系变化。若系统只记录托盘出库而没有记录装箱或拆分，查询者未必能由已有事件还原托盘内每件商品的路径。此为虚构流程示意，不对应真实企业或普遍适用的业务规则。

为了减少各方对相同业务状态的不同表达，EPCIS通常与GS1核心业务词汇标准（CBV）配合使用。EPCIS定义数据结构，CBV为其中的业务步骤、地点、处置状态等字段提供共同词汇和值。标准也允许用户或行业按需要扩展；如果扩展方式和含义没有事先对齐，跨系统查询及自动解释能力可能下降。

GS1于2022年6月批准发布EPCIS 2.0。该版本增加“如何”维度和传感器数据能力，并将认证详情作为独立字段；同时支持XML和JSON/JSON-LD表达，以及REST接口，并提供相应服务接口。GS1标准档案显示，EPCIS 2.0.1于2025年7月1日发布，是截至2026年10月2日档案所列的最新版本。ISO/IEC 19987:2024则定义EPCIS 2.0，并于2024年3月出版。引用规范时应注明版本：GS1现行勘误版和ISO出版版本的标记并不完全相同。

标准允许在核心结构上增加行业或应用所需的扩展字段与词汇，但扩展应与标准字段区分，并清楚约定其标识、取值和含义。接收方若未共享对应定义，即使能够读取结构，也可能无法自动解释扩展内容。采用扩展时还应注明所依据的EPCIS和词汇版本，避免把某一实施中的自定义字段误认为所有系统都通用的标准字段。

EPCIS事件的可交换性不仅取决于消息语法是否符合规范，也取决于对象标识、代码表、业务词汇、时间格式和地点标识是否可理解。实际部署常需要同步相关标识标准、CBV、主数据、接口安全与权限策略，并让数据采集环节生成准确事件。标准包括认证与授权相关接口要求，但某个组织是否配置这些机制、如何验证信息来源，仍取决于具体系统与治理安排。

EPCIS是一种可视性事件数据标准，追溯系统或供应链平台则是利用识别、数据采集、事件存储、查询和权限管理等组件建成的信息系统。平台可以采用EPCIS，但实施EPCIS标准不等于自动建成覆盖全链条的追溯平台；每个必要环节仍须产生、准确记录并按权限分享事件数据。

产品标识回答“这是哪个对象或哪一类对象”，条码、二维码或射频识别是承载或读取标识的技术；EPCIS事件回答“对象在业务流程中发生了什么”。两类技术可以协作，但不能互相替代。EPCIS也不是数字产品护照本身：产品护照侧重按特定制度或业务要求汇集、展示产品属性和相关信息；EPCIS可以为系统提供过程事件数据，但不规定某种护照必须披露哪些字段，也不自动判定产品是否满足法规要求。

EPCIS标准定义了如何共享可视性数据，并非强制所有企业建设同一套系统或开放全部供应链数据。共享范围、访问权限、数据准确性和跨组织治理由参与方的业务安排、适用规则和技术配置决定。若事件缺失、对象标识不一致、代码语义不同或参与方未提供查询权限，系统只能呈现不完整或不可解释的信息。对实时位置、安全合规或产品真伪的判断也不能仅靠某一条事件记录完成，仍需结合数据来源、采集过程及其他适用证据。

事件记录的陈述也有边界：它可以描述某个时点观察到什么；若要据此理解对象后续仍处于何种状态，则依赖业务流程按需记录后续事件，并确保查询方能访问相关记录。采集环节若未覆盖某个步骤、识别结果不完整，或后续事件缺失，系统生成的“当前视图”就可能只是基于已有资料的推断，不等于对现实状态的持续直接观察。

若事后发现历史事件记录有误，通常优先把纠正过程建模为新的普通事件，保留原事件并补充能够表达真实业务过程的后续记录。只有在无法以普通事件语义修复历史，或这样做会使完整事件轨迹高度不理想时，才使用ErrorDeclaration（错误声明）指出先前事件所作断言有误。原事件不会被删除或修改，查询结果会同时保留原事件和错误声明；如有相关纠正事件，也可与声明关联。解释完整轨迹时应把原记录与后续更正一并考虑。

• GS1：EPCIS Standard 2.0
• GS1：EPCIS Standard 2.0.1
• GS1：EPCIS standard archive
• GS1：Core Business Vocabulary 2.0
• GS1：EPCIS / CBV standards
• ISO：ISO/IEC 19987:2024