Kişiselleştirilmiş ürünler, baskılı tekstil ve markalama: geliştirilmesi gerekenler
Promosyon ürünü, baskılı tekstil veya çevrimiçi matbaa satan bir mağazada katalog fiyat içermez; fiyatı hesaplamaya yarayan öğeleri içerir. Sektörü zorlu kılan bu kaymadır ve kişiselleştirme ile konfigüratörlerin, satıcıların en sık dile getirdiği geliştirme talepleri arasında yer almasının nedeni de budur.
Fiyat okunmaz, hesaplanır
Tutar; kademeli indirimlerle miktara, seçilen markalama tekniğine — serigrafi, nakış, gravür, dijital baskı —, renk sayısına, markalanan konum sayısına ve sipariş miktarına yayılan sabit hazırlık veya klişe masraflarına bağlıdır. Tek bir referans böylece yüzlerce farklı fiyat üretebilir; bu da onları tek tek saklamayı olanaksız kılar.
Bu hesaplama sunucu tarafında yaşamalıdır. Yalnızca tarayıcıda kurulan bir fiyat üzerinde oynanabilir: gönderilen değerleri değiştirmek, tarifede hiç var olmamış bir tutarı elde etmeye yeter. İstemci tarafındaki betiğin rolü bir tahmin göstermekle sınırlıdır; sepete giren tutar, ödemeye giden tutar ve faturada yer alan tutar aynı kurallardan, aynı yerde yeniden hesaplanmalıdır.
Bir CMS'in sağlamadıkları
- Ürün sayfasından dosya yükleme; format (vektörel veya görsel), çözünürlük, renk modu ve taşma payı denetimleriyle birlikte.
- Dosyanın müşteri hesabına değil sipariş satırına bağlanması ve sepetten siparişe geçişte kaybolmaması — dosyaların en sık kaybolduğu yer tam olarak bu geçiştir.
- Baskı onayı: üretim yalnızca onaydan sonra başlar. Bu, mutabakat bekleyen bir durum, bir bildirim, otomatik hatırlatma ve onayın zaman damgalı kaydını gerektirir.
- Tüketicinin talimatlarına göre üretilen veya açıkça kişiselleştirilmiş mallar için, Fransız tüketici kanununun L221-28 maddesi uyarınca cayma hakkının dışında kalma; uyarı, müşterinin onayladığı anda gösterilmelidir.
- Bildirilen süre: ürüne değil tekniğe ve miktara bağlıdır. Atölyenin iş yüküne ve iş günlerine göre hesaplanır ve bir tarih olarak gösterilir.
- Üretim dosyası: ekran önizlemesi yetmez; üretimde gerçekten kullanılan dosyanın doğru ölçülerde ve doğru işaretlerle sunucu tarafında üretilmesi ve iş emrine eklenmesi gerekir.
Sunucunun ilk çöktüğü yer
Müşterilerin gönderdiği dosyalar büyüktür: yazı tipleri vektöre çevrilmiş bir çizim, geniş format baskı için yüksek çözünürlüklü bir görsel, kimi zaman sipariş başına birkaç tane. PHP sınırlarına çok çabuk ulaşılır ve müşteri tarafındaki belirti hep aynıdır: tamamlanmış gibi görünen bir yükleme, ardından boş bir sayfa ya da dosyası olmadan kaydedilmiş bir sipariş.
Bu nedenle sınırlar ayarlanmalı, ama var oldukları da kabul edilmelidir: gönderimden önce boyutu denetlemek, dosya ağır olduğunda yüklemeyi parçalara bölmek ve sessizce başarısız olmak yerine açıkça reddetmek. Dosyanın nesi olduğunu söyleyen bir mesaj, e-posta yoluyla bir gidiş gelişi ve iki gün bekleyen bir siparişi önler.
upload_max_filesize = 64M
post_max_size = 72M
max_file_uploads = 20
max_execution_time = 300
memory_limit = 256M
Aynı alan
-
Ürün kişiselleştirme stüdyosu
Fiyat hesabına ve üretim dosyası üretimine bağlanmış bir konfigüratörün somut örneği.
-
Özel sipariş durumları
Baskı onayı, varsayılan durumların temsil edemediği bir mutabakat bekleme hâli gerektirir.
-
Özel PrestaShop modülü
Fiyat ve dosya mantığının güncellemelerden sağ çıkması gerekiyorsa, tema düzenlemesi olarak değil modül olarak geliştirilir.
-
Özel geliştirme
Piyasadaki hiçbir eklenti atölyenin kurallarını kapsamadığında geçerli olan genel çerçeve.
Sıkça sorulan sorular
Piyasadaki bir konfigüratör yeterli olur mu?
Müşterinin gönderdiği dosya nerede saklanmalı?
Baskı onayı dış bir yazılım olmadan nasıl yönetilir?
Kişiselleştirilmiş bir ürün iade edilebilir mi?
Büyük dosyalarda yükleme neden başarısız olur?
Müşteriye gösterilen önizleme üretim için yeterli mi?
İhtiyacınızı bir dakikada anlatın
Size bir anket daha değil, doğrudan bir tahmin sunabilmem için birkaç hedefli soru.