Bốn loại sự kiện EPCIS trong chuẩn GS1: khi nào dùng Object, Aggregation, Transaction hay Transformation Event

Buổi chiều một kỹ sư IT hỏi tôi: "Đóng gói xong thì log event nào?"

Cách đây không lâu, tôi ngồi cùng đội kỹ thuật của một nhà máy chế biến cà phê xuất khẩu đang triển khai truy xuất nguồn gốc theo chuẩn GS1. Mọi thứ suôn sẻ cho đến khi tới bước đóng bao 60kg lên pallet để xuất hàng. Bạn kỹ sư hỏi thẳng: "Vậy giờ em log ObjectEvent hay AggregationEvent? Còn cái invoice gửi khách thì tính sao?"

Câu hỏi tưởng đơn giản nhưng lại là nơi phần lớn các đội kỹ thuật bị vấp khi đọc tài liệu GS1. Tài liệu chính thức của GS1 rất đầy đủ về mặt định nghĩa nhưng lại thiếu phần quan trọng nhất: khi nào dùng loại sự kiện nào trong một quy trình sản xuất - xuất khẩu thực tế, và nếu chọn sai thì hậu quả gì xảy ra với dữ liệu truy xuất. Bài này tôi viết dựa trên kinh nghiệm triển khai EPCIS cho vài chuỗi cung ứng nông sản, thủy sản và hàng tiêu dùng ở Việt Nam, đi thẳng vào phần mà hầu hết bài viết khác bỏ sót.

EPCIS ghi lại điều gì trước khi nói đến từng loại sự kiện

EPCIS (Electronic Product Code Information Services) là chuẩn của GS1 dùng để ghi lại "chuyện gì đã xảy ra" với một sản phẩm hoặc lô hàng trong chuỗi cung ứng, theo bốn chiều dữ liệu bắt buộc:

What - vật thể nào (mã EPC, GTIN, số lô), When - thời điểm nào (eventTime, có kèm timezone offset), Where - vị trí nào (readPoint là nơi thiết bị quét đứng, bizLocation là nơi hàng thực sự đang ở - hai khái niệm này khác nhau và rất hay bị nhầm), và Why - vì lý do kinh doanh gì (bizStep là bước quy trình, disposition là trạng thái sản phẩm sau sự kiện).

Bốn chiều này áp dụng cho mọi loại sự kiện. Cái khác nhau giữa bốn loại sự kiện kỹ thuật của EPCIS là chúng trả lời câu hỏi "chuyện gì xảy ra" theo bốn cách khác nhau: một vật thể đơn lẻ đổi trạng thái, nhiều vật thể gộp/tách thành một đơn vị, vật thể gắn với một giao dịch thương mại, hay vật thể biến đổi thành một vật thể khác hẳn.

Object Event - lớp nền của mọi hệ thống truy xuất

ObjectEvent là loại sự kiện cơ bản nhất, ghi nhận sự hiện diện hoặc thay đổi trạng thái của một hoặc nhiều vật thể tại một thời điểm, một vị trí cụ thể. Đây là loại sự kiện bạn sẽ dùng nhiều nhất: quét nhận hàng, quét xuất kho, quét tại từng trạm kiểm soát chất lượng.

Điểm nhiều người bỏ qua: trường action trong ObjectEvent không chỉ có ý nghĩa kỹ thuật mà mang ý nghĩa vòng đời sản phẩm. ADD nghĩa là vật thể này vừa được "sinh ra" trong hệ thống (ví dụ: in mã QR và gán cho một thùng hàng mới - commissioning). OBSERVE nghĩa là vật thể đã tồn tại từ trước, hệ thống chỉ đang quan sát nó đi qua một điểm (quét tại trạm kiểm tra). DELETE nghĩa là vật thể chính thức bị loại khỏi hệ thống (hủy, tiêu hủy do lỗi). Nhiều đội kỹ thuật dùng OBSERVE cho tất cả mọi trường hợp, kể cả lúc khởi tạo mã - hậu quả là hệ thống truy xuất không bao giờ biết chính xác một mã QR "ra đời" từ đâu, gây khó khi phải trả lời cơ quan hải quan hoặc khách hàng châu Âu về nguồn gốc.

Ví dụ thực tế, một lô cà phê rang được đóng gói và gắn QR tại trạm đóng gói:

{
  "type": "ObjectEvent",
  "eventTime": "2026-07-15T03:20:00.000Z",
  "eventTimeZoneOffset": "+07:00",
  "epcList": ["urn:epc:id:sgtin:0893456.012345.10023"],
  "action": "ADD",
  "bizStep": "urn:epcglobal:cbv:bizstep:commissioning",
  "disposition": "urn:epcglobal:cbv:disp:active",
  "readPoint": { "id": "urn:epc:id:sgln:0893456.00011.0" },
  "bizLocation": { "id": "urn:epc:id:sgln:0893456.00011.0" }
}

Aggregation Event - khi hàng gộp thành pallet, tách khỏi container

AggregationEvent dùng khi có quan hệ vật lý cha - con thật sự: nhiều đơn vị nhỏ được gộp vào một đơn vị lớn hơn (đóng thùng vào case, xếp case lên pallet), hoặc tách ra khỏi nhau (dỡ hàng khỏi container, tách pallet). Khác với ObjectEvent, AggregationEvent bắt buộc có trường parentID - chính cái ID cha này tạo ra "cây phả hệ" giúp sau này chỉ cần quét mã pallet là truy ngược được toàn bộ các thùng bên trong.

Action ở đây mang nghĩa khác hẳn ObjectEvent: ADD nghĩa là các con vừa được gộp vào cha trong chính sự kiện này, DELETE nghĩa là con vừa bị tách khỏi cha, OBSERVE nghĩa là tại thời điểm quét, cha và con đang ở trạng thái gộp nhưng không có gì thay đổi (ví dụ quét kiểm kho một pallet đã đóng từ trước).

Lỗi tôi hay gặp nhất khi audit hệ thống của khách hàng: đội kỹ thuật dùng ObjectEvent để log việc đóng thùng, coi mỗi thùng là "một vật thể mới" thay vì dùng AggregationEvent để nối nó với các đơn vị bên trong. Kết quả là khi khách hàng cuối quét QR trên thùng, hệ thống trả về đúng thông tin thùng nhưng không biết bên trong có những lô nguyên liệu nào - mất hoàn toàn khả năng truy xuất ngược đến từng mẻ nguyên liệu, điều mà FSMA 204 của Mỹ hay quy định EUDR của châu Âu đòi hỏi rất rõ.

{
  "type": "AggregationEvent",
  "eventTime": "2026-07-15T05:00:00.000Z",
  "eventTimeZoneOffset": "+07:00",
  "parentID": "urn:epc:id:sscc:0893456.1023456789",
  "childEPCs": [
    "urn:epc:id:sgtin:0893456.012345.10023",
    "urn:epc:id:sgtin:0893456.012345.10024",
    "urn:epc:id:sgtin:0893456.012345.10025"
  ],
  "action": "ADD",
  "bizStep": "urn:epcglobal:cbv:bizstep:packing",
  "readPoint": { "id": "urn:epc:id:sgln:0893456.00011.0" }
}

Transaction Event - khi hàng hóa gắn với một chứng từ thương mại

TransactionEvent ghi nhận việc một hoặc nhiều vật thể được gắn hoặc gỡ khỏi một giao dịch kinh doanh cụ thể - hóa đơn, đơn đặt hàng, phiếu xuất kho. Đây là loại sự kiện bị hiểu nhầm nhiều nhất vì trông có vẻ "không cần thiết" - nhiều đội bỏ qua nó vì nghĩ ObjectEvent với bizStep là shipping đã đủ.

Vấn đề là: ObjectEvent trả lời "hàng này đã rời kho lúc mấy giờ", còn TransactionEvent trả lời "hàng này thuộc về hóa đơn/PO nào". Khi cơ quan hải quan hoặc đối tác nhập khẩu đối chiếu chứng từ với lô hàng thực tế, họ cần chính cái liên kết này. Một nhà xuất khẩu thủy sản tôi từng làm việc cùng, khi bị yêu cầu chứng minh một container hàng khớp với invoice số bao nhiêu cho khách Nhật, chỉ mất vài giây tra cứu nhờ có TransactionEvent - trong khi trước đó họ phải lục hồ sơ giấy vì hệ thống chỉ ghi ObjectEvent.

{
  "type": "TransactionEvent",
  "eventTime": "2026-07-16T02:00:00.000Z",
  "eventTimeZoneOffset": "+07:00",
  "bizTransactionList": [
    {
      "type": "urn:epcglobal:cbv:btt:inv",
      "bizTransaction": "urn:epc:id:gdti:0893456.00089.2026001"
    }
  ],
  "parentID": "urn:epc:id:sscc:0893456.1023456789",
  "action": "ADD",
  "bizStep": "urn:epcglobal:cbv:bizstep:shipping",
  "disposition": "urn:epcglobal:cbv:disp:in_transit"
}

Transformation Event - khi nguyên liệu biến mất và sản phẩm mới ra đời

TransformationEvent dùng cho trường hợp khác hẳn ba loại trên: một hoặc nhiều vật thể đầu vào bị tiêu thụ hoàn toàn hoặc một phần, và sinh ra vật thể đầu ra hoàn toàn khác. Sữa tươi biến thành phô mai, cà phê nhân biến thành cà phê rang, cá nguyên con biến thành phi lê đông lạnh - đây đều là transformation, không phải aggregation.

Khác biệt cốt lõi cần nhớ: sau AggregationEvent, các mã con vẫn tồn tại nguyên vẹn bên trong mã cha, quét vào vẫn thấy đúng từng đơn vị gốc. Sau TransformationEvent, các mã đầu vào coi như "kết thúc vòng đời" - EPC gốc không còn xuất hiện lại, thay vào đó là EPC hoàn toàn mới cho sản phẩm đầu ra, và mối liên kết duy nhất giữa cũ và mới nằm trong chính sự kiện transformation đó (inputEPCList và outputEPCList). Nếu hệ thống của bạn không lưu đúng sự kiện này, chuỗi truy xuất sẽ đứt gãy ngay tại điểm chế biến - đúng chỗ nhạy cảm nhất khi cơ quan quản lý hoặc khách hàng muốn biết nguyên liệu đầu vào đến từ nông trại/vùng nuôi nào.

TransformationEvent còn có một trường ít được nhắc tới nhưng quan trọng với ngành thực phẩm: ILMD (Instance/Lot Master Data) - nơi lưu các thuộc tính riêng của lô sản phẩm đầu ra như hạn sử dụng, số lô sản xuất, tỷ lệ phối trộn. Rất nhiều bài viết tôi đọc khi tìm hiểu chủ đề này chỉ nhắc ILMD một câu cho có mà không giải thích nó khác gì với dữ liệu ở ObjectEvent.

{
  "type": "TransformationEvent",
  "eventTime": "2026-07-14T01:00:00.000Z",
  "eventTimeZoneOffset": "+07:00",
  "inputEPCList": [
    "urn:epc:id:sgtin:0893456.055512.90001",
    "urn:epc:id:sgtin:0893456.055512.90002"
  ],
  "outputEPCList": [
    "urn:epc:id:sgtin:0893456.012345.10023"
  ],
  "bizStep": "urn:epcglobal:cbv:bizstep:transforming",
  "ilmd": {
    "lotNumber": "RST-2026-0714",
    "bestBeforeDate": "2027-07-14"
  }
}

Association Event - đứa con mới của EPCIS 2.0, ít ai cần ngay nhưng nên biết

EPCIS 2.0 bổ sung AssociationEvent để ghi nhận mối liên kết dài hạn giữa một vật thể và các thành phần gắn thêm vào nó - ví dụ gắn cảm biến nhiệt độ vào một container, gắn một linh kiện vào máy móc để theo dõi bảo hành. Khác với Aggregation (nhóm rồi tách), Association mô tả quan hệ "gắn liền" kéo dài, không nhất thiết cùng đóng gói vật lý. Với phần lớn doanh nghiệp sản xuất - xuất khẩu ở Việt Nam hiện tại, loại này chưa cấp thiết bằng bốn loại trên, nhưng nếu bạn có kế hoạch gắn thiết bị IoT giám sát chuỗi lạnh thì nên biết nó tồn tại để không phải dùng tạm ObjectEvent rồi sau này phải làm lại.

Cách chọn đúng loại sự kiện trong một giây

Cách tôi hay hướng dẫn đội kỹ thuật khi họ phân vân: trước tiên tự hỏi có sự thay đổi về nhóm vật lý không - nhiều vật thể gộp lại hoặc tách ra mà bản thân từng vật thể vẫn giữ nguyên hình hài, thì đó là Aggregation. Nếu vật thể đầu vào biến mất hoàn toàn và sinh ra vật thể mới có bản chất khác, đó là Transformation. Nếu điều xảy ra chỉ là gắn hoặc gỡ một chứng từ thương mại khỏi lô hàng mà không có gì thay đổi vật lý, đó là Transaction. Còn lại - tức là chỉ đơn thuần ghi nhận một vật thể đơn lẻ đang ở đâu, trạng thái gì - dùng Object Event. Association chỉ dùng khi bạn cần mô tả quan hệ gắn kèm lâu dài, không phải đóng gói tạm thời.

Những lỗi triển khai thực tế mà tài liệu GS1 không cảnh báo đủ rõ

Ba lỗi tôi gặp lặp đi lặp lại khi rà soát hệ thống EPCIS của khách hàng, ngoài hai lỗi đã nói ở trên về action và nhầm Aggregation với Object:

Nhầm readPoint với bizLocation. readPoint là vị trí vật lý của thiết bị quét (cổng quét ở cửa kho), bizLocation là nơi hàng hóa thực sự đang được lưu trữ về mặt kinh doanh (chính kho đó, hoặc có thể là một khu vực khác nếu thiết bị quét đặt ở ngoài cổng nhưng hàng vào sâu trong kho). Khi hai giá trị này bị gán giống hệt nhau một cách máy móc, dữ liệu vị trí trong báo cáo truy xuất sẽ sai lệch với thực tế kho vận, nhất là ở các nhà máy có nhiều khu vực lưu trữ.

Bỏ qua disposition hoặc dùng tùy tiện. disposition mô tả trạng thái thương mại của sản phẩm sau sự kiện: active, in_transit, sold, recalled, non_sellable_other. Nhiều hệ thống chỉ set một giá trị mặc định cho mọi sự kiện, khiến việc dựng lại trạng thái sản phẩm tại một thời điểm bất kỳ trở nên vô nghĩa - đây chính là dữ liệu mà một hệ thống thu hồi sản phẩm (recall) cần đọc chính xác để biết lô nào đang ở đâu và có bán ra thị trường hay chưa.

Quên eventTimeZoneOffset hoặc dùng giờ UTC không nhất quán giữa các trạm. Với chuỗi cung ứng có nhiều điểm quét ở nhiều múi giờ (nhà máy Việt Nam, cảng trung chuyển, kho ở châu Âu), lệch timezone khiến thứ tự sự kiện bị đảo lộn khi truy vấn, dẫn đến những báo cáo truy xuất tưởng đúng nhưng sai trình tự thời gian thực tế.

Vì sao chủ doanh nghiệp cần quan tâm đến bốn loại sự kiện này ngay bây giờ, không phải để đội IT tự quyết

Đây không đơn thuần là vấn đề kỹ thuật của đội phát triển. Quy định chống phá rừng của châu Âu (EUDR) và luật hiện đại hóa an toàn thực phẩm FSMA 204 của Mỹ đều yêu cầu khả năng truy xuất theo từng lô nguyên liệu (Key Data Elements gắn với Critical Tracking Events) - mà bản chất chính là việc ghi đúng loại sự kiện EPCIS tại đúng bước quy trình. Nếu doanh nghiệp chọn sai loại sự kiện ngay từ đầu, ví dụ dùng Object Event cho việc đóng gói thay vì Aggregation, thì khi cần trả lời khách hàng nhập khẩu hoặc cơ quan kiểm định "container này gồm những lô nguyên liệu nào từ vùng trồng nào", hệ thống sẽ không trả lời được - không phải vì thiếu dữ liệu, mà vì dữ liệu bị ghi sai cấu trúc ngay từ lúc phát sinh.

Đây cũng là lý do khi VNCX xây dựng lớp thu thập sự kiện cho khách hàng, chúng tôi không để đội vận hành tự chọn loại sự kiện thủ công tại từng trạm quét - hệ thống ánh xạ sẵn từng hành động nghiệp vụ (đóng gói, xuất kho, chế biến, xuất hóa đơn) sang đúng loại sự kiện EPCIS tương ứng, để người vận hành ở nhà máy chỉ cần quét mã, còn việc chọn ObjectEvent hay AggregationEvent hay Transformation là do cấu hình quy trình quyết định từ trước. Cách này tránh được gần như toàn bộ các lỗi kể trên, vì con người không phải nhớ định nghĩa GS1 giữa ca sản xuất bận rộn.

Bắt đầu từ đâu nếu doanh nghiệp chưa có gì

Với các doanh nghiệp mới bắt đầu, tôi thường khuyên đi theo trình tự: trước tiên lập bản đồ đúng các bước nghiệp vụ thực tế của chuỗi cung ứng (nhận nguyên liệu, chế biến, đóng gói, xuất kho, xuất hóa đơn), sau đó gán mỗi bước với đúng một trong bốn loại sự kiện theo nguyên tắc đã nêu ở trên, rồi mới nghĩ đến việc chọn nền tảng công nghệ hay tự viết EPCIS repository. Phần khó nhất không phải là công nghệ - JSON hay XML đều có thư viện hỗ trợ sẵn - mà là buộc từng bộ phận trong nhà máy thống nhất cách hiểu bizStep và disposition, để dữ liệu từ khâu chế biến và khâu xuất kho "nói cùng một ngôn ngữ" khi ráp lại thành một chuỗi truy xuất hoàn chỉnh.