EPCIS (Electronic Product Code Information Services), bir ürünün tedarik zincirinde yaşadığı olayları ortak bir biçimde kaydetmek ve firmalar arasında paylaşmak için kullanılan GS1 standardıdır. Haziran 2022'de onaylanan 2.0 sürümü, XML'in yanına JSON ile JSON-LD'yi, SOAP'ın yanına REST arayüzünü ekledi. Standart ayrıca ISO/IEC 19987:2024 olarak yayımlandı.
EPCIS hangi ihtiyacı karşılar?
Üretici, depo ve distribütör aynı sevkiyatı kendi sistemlerinde farklı alan adlarıyla ve farklı kodlarla tutar. Birbirine veri aktarmak istediklerinde her ilişki için ayrı bir eşleştirme yapılır. EPCIS bu aktarımın dilini ortak hâle getirir: bir olayın hangi alanlarla anlatılacağını ve bu olayların hangi arayüzle kaydedilip sorgulanacağını tanımlar.
Kapsamını doğru okumak gerekir. EPCIS bir yazılım ürünü değildir, etiket standardı da değildir. Ürünün nasıl numaralandırılacağını ve barkoda nasıl yazılacağını diğer GS1 standartları belirler. GS1'in anlatımında EPCIS, verinin yakalandığı katman ile paylaşıldığı katman arasında köprü görevi görür. Ürün tanımı gibi sabit bilgiler de ana veri olarak ayrı yönetilir; EPCIS ağırlıklı olarak "ne oldu" sorusuyla ilgilenir.
Bir EPCIS olayı neyi kaydeder?
Her olay beş boyutta anlatılır. Standart bunları kısaca ne, ne zaman, nerede, neden ve nasıl diye özetler.
| Boyut | Soru | Örnek |
|---|---|---|
| Ne (what) | Hangi nesne? | Seri numaralı birim, parti, SSCC'li palet |
| Ne zaman (when) | Hangi tarih ve saat, hangi saat diliminde? | eventTime ve eventTimeZoneOffset |
| Nerede (where) | Okuma noktası ve sonrasında bulunduğu yer | readPoint, bizLocation |
| Neden (why) | Hangi iş adımı, nesnenin durumu ne? | bizStep, disposition |
| Nasıl (how) | Nesnenin koşulu neydi? | Sensör verisi (sensorElementList) |
"Nasıl" boyutu 2.0 ile geldi ve sensörden alınan ölçümlerle doldurulur. Soğuk zincirdeki bir sevkiyatın sıcaklık ölçümü bu alana yazılabilir. İş adımı ve durum değerleri ise standardın eşlik eden belgesi Core Business Vocabulary'den (CBV) gelir. Ortak sözlük sayesinde "shipping" değeri alıcının sisteminde de aynı anlama gelir.
EPCIS'te hangi olay türleri var?
| Olay türü | Ne zaman kullanılır | Örnek |
|---|---|---|
| ObjectEvent | Bir ya da daha fazla nesnenin başına gelen olay | Hat çıkışı okutması, sevk, kabul |
| AggregationEvent | Nesnelerin fiziksel olarak bir araya getirilmesi | Kolilerin palete konması |
| TransactionEvent | Nesnelerin bir ticari işlemle ilişkilendirilmesi | Paletin bir siparişe bağlanması |
| TransformationEvent | Girdilerin tüketilip çıktının üretilmesi | Hammadde partisinden mamul parti üretimi |
| AssociationEvent | Kalıcı ebeveyn ve çocuk ilişkileri | Bir parçanın ana ekipmana ya da bir nesnenin sabit konuma bağlanması |
Bir olayda action alanı nesnenin kayıtla ilişkisini söyler: ADD oluşturulduğunu ya da eklendiğini, OBSERVE değişmeden görüldüğünü, DELETE kaldırıldığını belirtir.
Üretim, sevk ve kabul olayları nasıl görünür?
Tek bir kutunun hattan alıcıya gidişi dört olayla anlatılabilir. CBV'deki iş adımı değerleri aşağıdaki gibidir.
| Adım | Olay türü | action | bizStep | disposition |
|---|---|---|---|---|
| Hat çıkışı, numaranın ürünle eşleşmesi | ObjectEvent | ADD | commissioning | active |
| Kolilerin palete konması | AggregationEvent | ADD | packing | genellikle boş |
| Paletin sevk edilmesi | ObjectEvent | OBSERVE | shipping | in_transit |
| Alıcının kabulü | ObjectEvent | OBSERVE | receiving | genellikle boş |
CBV, in_progress değerinin kayda fazla bir şey katmadığını, boş bırakılmasının genellikle tercih edildiğini belirtir. Paketleme olayının pratik karşılığı da burada görülür: palet bir kez kolilerle bağlandığında sonraki adımlarda yalnızca palet numarası okutulur ve içindeki birimler kayıttan bulunur.
2.0 sürümünde neler değişti?
- JSON ve JSON-LD: Olaylar XML'in yanında JSON olarak da yazılabilir. CBV değerleri için
"bizStep": "shipping"gibi kısa bir yazım kullanılır. - REST arayüzü: Olay kaydı ve sorgu için SOAP'ın yanına REST bağlantıları eklendi. Standart, her API çağrısında istemcinin kimliğini doğrulamasını şart koşar.
- AssociationEvent: Kalıcı ilişkiler için yeni olay türü.
- Nasıl boyutu ve sensör verisi:
SensorElementyapısıyla ölçümler olayın parçası oldu. - Kalıcı durum (persistent disposition): Nesnenin geçici olmayan iş durumu ayrı tutulabilir.
- GS1 Digital Link adresleri: Nesneler karekoddaki web adresi yapısıyla da gösterilebilir.
Eski sürümlerle kurulan XML akışları için 2.0 kapıyı kapatmaz; XML ve SOAP standartta yer almaya devam eder.
EPCIS her firmaya gerekir mi?
Standart tek başına kimseye yükümlülük getirmez. Talep genellikle bir müşteri şartnamesinden ya da sektörel bir düzenlemeden gelir. Tek bir alıcıya düzenli dosya aktaran bir üretici için ERP entegrasyonu çoğu zaman yeterlidir. EPCIS'in değeri, birden fazla taraf aynı ürün geçmişini okumak zorunda kaldığında artar.
Standart üç konuyu da çözmez:
- Veri kalitesi: Hat çıkışında yapılmayan bir okutmanın olayı da olmaz. Boş kaydı EPCIS'e taşımak boşluğu kapatmaz.
- Paylaşım kararı: Hangi firmanın hangi olayı göreceği taraflar arasında kararlaştırılır.
- Ortak kimlikler: GTIN, seri numarası, SSCC ve lokasyon numaraları tutarlı değilse olaylar birbirine bağlanmaz.
Projeye başlamadan önce şu soruların cevabı netleşmiş olmalıdır:
- Olayları kim, hangi amaçla okuyacak?
- Numara düzeyi ne: parti mi, birim mi?
- Hangi noktalar okutulacak, hangisi bugün hiç kayıt üretmiyor?
- Koli ve palet ilişkisi kaydediliyor mu?
- Lokasyonlar nasıl numaralandırılıyor?
- Yanlış girilen olay nasıl düzeltilecek? Standart, hatalı olayları bildirmek için ayrı bir mekanizma sunar.
Okutma noktalarının nasıl seçildiğini ürün takip sistemi kurulumu yazısında, palet numarasını SSCC yazısında ele aldık.
Tagvex kaydı bu resimde nerede durur?
Tagvex hat çıkışı, depo, distribütör ve bayi noktalarındaki el değişimlerini tek kayıt altyapısında toplar; kayıtlar API ile ERP, depo ve diğer kurumsal sistemlere bağlanır. Bir alıcı ya da düzenleme verinin EPCIS biçiminde paylaşılmasını istiyorsa bu gereksinim ihtiyaç analizinde ayrıca ele alınmalıdır.
