ERP'de ZPL ile etiket baskısı

Yayın tarihi: 2026-08-27

ERP sistemleri etikette ne yazması gerektiğini bilmekte iyidir, etiketin fiziksel olarak basılıp basılmayacağını bilmekte zayıf. Boşluk her seferinde aynı yerde görünür: salı günü düzenlenen bir şablon, çarşamba başlayan bir vardiya ve ERP ile yazıcı arasında çıktıya hiç bakılmadığı için yanlış çıkmış bir palet etiket.

Hat ve gerçekte nerede kırıldığı

Sistem hangisi olursa olsun — Odoo, NetSuite, kendi yazdığınız WMS — şekil aynıdır: iş verisi bir etiket şablonuna birleştirilir, sonuç ZPL olarak üretilir ve ZPL yazıcıya, genelde TCP 9100'e ham olarak iletilir. Bu zincirde üç kırılma noktası vardır ve hiçbiri yazıcının suçu değildir:

1. Birleştirme, düzenin taşıyamayacağı içerik üretir. Test kaydının iki katı uzunlukta bir ürün adı, dördüncü satırı olan bir adres, beklenenden çok haneli bir parti kodu. Şablon, tasarlandığı veri için hiç yanlış değildi.
2. Şablon başka bir yazıcı için çizilmiştir. ZPL'de koordinatlar noktadır; 203 dpi cihaza göre kurulmuş bir düzen 300 dpi kafada yaklaşık üçte iki ölçekte basar. Depolar yazıcıları yıllara yayarak alır, hepsini birden değil.
3. Göndermeden önce hiçbir şey doğrulamaz. 9100 portunun geri alması yoktur: baytlar ulaştığı anda yazıcı medyayı hareket ettirir, yani bozuk bir birleştirmenin ilk belirtisi fiziksel bir bozuk etiket yığınıdır.

Doğrulama kapısı

Çözüm bir ürün değil bir adımdır: "ERP ZPL üretti" ile "yazıcıya gönder" arasına yapısal bir denetim koyun ve geçemeyeni kuyruğa almayı reddedin. Pratikte bu, baskıyı zaten yapan serviste tek bir HTTP çağrısıdır.

curl -X POST "https://api.labelixa.com/v1/diagnostics?dpmm=8&w=4&h=6"      --data-binary @birlesmis-etiket.zpl

Yanıt, bulguları şiddet ve konumla listeler. error'ı sert duruş sayın — etiket istendiği gibi render edilmeyecektir — warning'i devam etseniz bile kaydedin; çünkü "geçen ayki etiketler neden daha kötü okunuyordu" sorularına dönüşen şey uyarılardır. Aynı kapı cron ya da CI işi için komut satırı adımı olarak da var (npx labelixa validate birlesmis-etiket.zpl hatada sıfırdan farklı kodla çıkar); bir şablonu sürüm öncesi gerçek kayıt yığınına karşı denemenin en kolay yolu budur.

İkinci yarısı render'dır. Kapı yapısal sorunları yakalar; render ise etiketin nasıl görüneceğini insana gösterir — bir şablon değiştiğinde ve birinin onaylaması gerektiğinde istediğiniz şey tam olarak budur.

Odoo

Odoo'nun etiket çıktısı şablon tabanlıdır ve ağ yazıcısına ZPL olarak üretilebilir. Pratik tavsiye sürümden bağımsızdır: ZPL şablonunu yalnız veritabanında değil sürüm kontrolünde tutun, demo veriyle değil en uzun gerçek değerlerinizle test edin ve doğrulama kapısını yazıcıya gönderen kod yoluna koyun. Odoo kurulumları sürümler ve modüller arasında çok değiştiği için yapılandırma ekranlarını başka bir sürümün ekran görüntüsünden değil kendi sürümünüzün dokümanından doğrulayın.

NetSuite

NetSuite etiket çıktısını kayıtlı aramalar ve betiklerle üretir; yani etiket, iş mantığının yaşadığı yerde kurulur. Bu, ZPL'i üreten betiğe doğrulama adımı eklemeyi kolaylaştırır ve "en uzun gerçek değer" testini özellikle önemli kılar: bugünkü veride çalışan bir kayıtlı arama, daha uzun bir kalem adı ilk göründüğünde taşan bir etiket üretebilir. Odoo'da olduğu gibi kayıt ve betik kurulumunu sürüme özgü kabul edin ve güncel dokümandan doğrulayın.

Sürüm öncesi neyi test etmeli

• Her değişken alanda ortalama değeri değil EN UZUN gerçek değeri.
• Şablonu filodaki her yazıcı modelinin yoğunluğunda — boyut ve DPI analizi dosyanın neyi varsaydığını söyler, DPI dönüştürücü filo karışıkken koordinatları yeniden ölçekler.
• Şablon başına bir etiketi görüntüleyiciden geçirin ve süreci sahiplenen kişi baksın — yalnız değişikliği yapan geliştirici değil.

Üçünden sonra etiket hâlâ yanlış basıyorsa belirti triyajı nedeni tahminlerle medya harcamadan daraltır.

İlgili yazılar

Kendi ZPL kodunuzu deneyin →