Teklif Talebi Açma Rehberi

Müşteri yolculuğu basit tutulur:

Müşteri misafir veya kayıtlı olarak teklif talebi açar → matbaa teklif verir → müşteri teklifi seçer → aynı e-posta ile kayıt/giriş yapılır → sipariş oluşur → ödeme onaylanır → dosya/preflight ve üretim bilgisi kapıları tamamlanır → matbaa üretime alır → sipariş teslim edilir → müşteri siparişi kapatır.

AI destekli teklif talebi sayfası: /tr/teklif

Bu adrese ürün seçmeden girdiğinizde ürün kataloğu gösterilir; Teklif talebi oluştur düğmesi aynı sayfaya tekrar bağlanmak yerine ürün kartlarına götürür. Bir ürün kartından devam edildiğinde kanonik ürün kimliği ve ürün etiketi forma taşınır. Kategori sonradan elle değiştirilirse üst özet de yeni seçimi gösterir; eski Özel özeti korunmaz.

Manuel teklif talebi kısa adresi: /tr/new-quote. Bu adres, teknik manuel pilot yüzeyi olan /tr/marketplace/new-quote sayfasına yönlenir.

Giriş yaptıysanız AI destekli ve manuel teklif formları bilinen adınız ve e-posta adresinizi mümkün olduğunca otomatik doldurur. Telefon, şirket veya teslimat gibi eksik ya da güncel olmayan bilgileri formda düzeltebilirsiniz; sistem elle yazdığınız ad/e-posta değerlerini tekrar oturum bilgisiyle ezmez.

Müşteri takip ekranı ile matbaa akış/detay kartları yalnız müşterinin yazdığı açıklamayı gösterir; eski kayıtlardaki iç AI iz metni her sunum sınırında ayıklanır. Bilinen kategori kodları yerelleştirilir, bilinmeyen eski kodlar eksik çeviri hatası üretmeden okunabilir biçimde gösterilir ve 24 saatten kısa son tarihler tam güne yuvarlanmak yerine saat olarak yazılır.

Aynı e-posta ile kayıt olduğunuzda sistem sizi önce onboarding'e götürür. Onboarding'i tamamladığınızda, bu e-posta ile açılmış misafir teklif talepleriniz hesabınıza bağlanır ve özel takip linkinize geri dönerek teklifi siparişe çevirebilirsiniz. Özel takip linkiniz yine çalışmaya devam eder.

AI hazırlık durumu, güven skoru ve çözümlenen alanlar denetim için yapılandırılmış RFQ kanıtında saklanır. Bu iç teknik kanıt müşteri açıklamasına veya özel takip sayfasındaki müşteri notuna eklenmez. Tahmini maliyet yalnız pozitif, geçerli bir referans fiyat üretildiyse gösterilir; fiyat hesaplanamadığında sıfır tutar hazır tahmin gibi sunulmaz.

Kesin manuel veya AutoBid teklifi geldiğinde maildeki teklifi incele bağlantısı, yalnızca o teklif ve RFQ revision'ına bağlı opak bir guest capability taşır. Link teklif özetini oturum açmadan gösterir; komisyon, fason maliyeti ve özel maliyet defteri hiçbir zaman müşteri yüzeyine çıkmaz. Kabul et adımında kayıt/giriş gerekir. Misafir RFQ sahipliği yalnız linkteki kanıt ve talep açılırken kullanılan aynı e-posta ile doğrulanır; farklı e-posta ile giriş kabul edilmez. Capability'nin ham değeri Firestore'a yazılmaz, yalnız SHA-256 hash'i RFQ üzerinde tutulur ve linkin süresi dolduğunda kabul kapısı açılmaz.

E-posta ile teklif talebi

Teklif talebinizi teklif@nowtoprint.com adresine e-posta göndererek de başlatabilirsiniz. Sistem konu, mesaj metni ve desteklenen eklerden baskı özelliklerini çıkarır. Ne bastırılacağı, ürün türü ve müşterinin açıkça verdiği pozitif adet olmadan RFQ açılmaz; sistem aynı e-posta zincirinde bu kritik bilgileri ister ve henüz takip bağlantısı vermez. Roman/kitap/şiir/hikâye niyeti ile gerçek adet tamamlandığında sayfa, ebat, kâğıt, renk ve cilt gibi kritik olmayan eksikler Bulut pilot profiliyle tamamlanabilir; kullanılan alanlar yanıt ve RFQ içinde assumptionFields olarak gösterilir. Bu, bağlayıcı olmayan varsayımlı başlangıçtır; kesin müşteri beyanı veya kesin fiyat değildir. Tarifesi olmayan finishing örnek fiyata dahil edilmez ve açıkça belirtilir. PDF eklemek zorunlu değildir.

Ebat 19,5x27,5 cm, 19,5-27,5 veya 195x275 mm biçiminde yazılabilir; santimetre beyanı costing'e gitmeden milimetreye çevrilir. Tek renk iç baskı ifadesi açık 1/1 beyanıdır ve sistem varsayımı olarak gösterilmez. AI çıkarımı kullanılamazsa deterministik fallback yalnız konu/gövdede gerçekten bulunan alanları ve açık kitap niyetini korur. Boş/genel mesajı kitap saymaz, adet üretmez ve kritik bilgi eksikse netleştirme ister.

E-posta ve MCP kanalları belirli bir kanonik müşteri baskı ürünüyle eşleşir. Katalogdaki yalnız kategori/grup sayfası (book, catalog veya packaging gibi) belirli ürün sayılmaz; sistem uygun L2 ürün seçimini ister. Eski yaprak alias'ları yalnız denetimli migration kaydıyla kanonik ürüne taşınır. Adet pozitif tam sayı olmalıdır; şehir verilmediyse İstanbul, ülke veya bölge varsayılmaz.

Marketplace sunum grubu ile L2 ürün yaprağı ayrı kalır. Sunucu grubu doğrulayıp public başlık, keşif ve filtreleme için categoryGroupId olarak saklar; fiyatlama ve yönlendirme yalnız kanonik L2 productSlug değerini kullanır. magazine ve yearbook gibi çakışmalarda kanallar çıplak string'den tahmin etmek yerine açık category_group veya product_leaf provenance'ı taşır. packaging, label ve large_format gibi geniş gruplar ürün seçmez; ayrı bir kanonik ürün yaprağı verildiğinde sunucu yalnız yaprağın ilgili L2 kategori veya grup hiyerarşisine ait olduğunu doğrular.

Otomatik yanıtlar sabit bir teslimat kimliği taşır. Gmail mesajı kabul ettikten sonra işlem kesilirse NowToPrint tekrar göndermeden önce gönderilmiş kopyayı bulup teslimatı tamamlar; aynı talep ikinci bir ajan yanıtı üretmemelidir. Makul bir süre sonra yanıt gelmezse yeni talep açmak yerine mevcut e-posta zincirini yanıtlayın.

Her otomatik yanıtın altında işlenen son müşteri mesajı; gönderen, tarih ve konu bilgisiyle alıntılanır. Böylece yanıtın hangi metne verildiği açıktır. Sistem bu alıntıyı ve daha eski Gmail geçmişini yeni talep sanmaz; takip yanıtının yalnız en üstteki yeni kısmından alan çıkarır.

Geçici bir kayıt/altyapı sorunu olursa sistem RFQ oluşmuş gibi takip kodu göndermez. Talebin alındığını ve otomatik yeniden deneneceğini bir kez bildirir; aynı bilgileri tekrar yazmanız gerekmez.

Her e-posta göndericisi doğrulanmış adresinden türeyen opak bir kişisel sahiplik kimliğiyle ayrılır; farklı müşteriler ortak bir anonymous RFQ sahibi değildir. Her mesajın create/amend sonucu kendi hash anahtarlı makbuzuyla korunur; araya başka bir müşteri yanıtı girse bile eski retry ikinci revizyon yazmaz. Geçici hata sayacı Gmail indirmesinden önce başlar, beş başarısız denemeden sonra talep teknik inceleme kuyruğuna alınır.

Aynı zincirde verdiğiniz takip yanıtları tek bir konuşma olarak değerlendirilir. İlk e-postadaki PDF ve baskı bilgileri korunur; örneğin ikinci yanıtta yalnızca adet yazmanız yeterlidir. RFQ oluşmuşsa takip yanıtı yeni bir RFQ açmaz, aynı talebin revizyonunu ilerletir. Fiyatı etkileyen bir değişiklik mevcut teklifleri güncelliğini yitirmiş duruma getirir; aynı RFQ'nun yeni revision'ı Bulut'un üç gerçek fason tedarikçisine yeniden fiyatlatılır. Manuel veya AutoBid ile kesin teklif oluştuğunda müşteriye güvenli teklif özeti, PDF ve imzalı inceleme bağlantısı yeni bir bağımsız mail yerine aynı Gmail zincirinde gönderilir. Teslimat, teklif outbox olayı ve sabit olay kimliğiyle tekilleştirilir. Thread, RFQ revision'ı veya doğrulanmış requester e-postası eksikse olay başarılı sayılmaz; yeniden denenir ve bounded denemeler sonunda teknik incelemeye alınır. Manuel teklifin fiyatladığı RFQ revision'ı sunucu tarafından kanonik RFQ kaydından alınır; form/API girdisi bunu değiştiremez. Mail gönderilmeden önce event quote/RFQ kimlikleri, teklifin RFQ bağı, güncel ve thread revision'ları ile requester ve thread alıcı e-postası birebir doğrulanır. Çapraz veya bozuk bağ notification, link ya da mail üretmez.

PDF, düz metin ve CSV ekleri desteklenir. Bir e-postada en fazla 5 ek, dosya başına en fazla 25 MB ve toplam 40 MB işlenir. Dosya türü, gerçek dosya içeriğiyle uyuşmuyorsa veya sınırlar aşılmışsa e-postada dosya adıyla birlikte açık uyarı görürsünüz. Otomatik doküman analizi için ek başına 10 MB, toplam 12 MB sınırı vardır. Daha büyük ancak geçerli dosya RFQ kaydına özel olarak eklenebilir; içeriği AI tarafından okunmadıysa bu durum onay e-postasında açıkça belirtilir.

Ekler RFQ kaydında kalıcı indirme bağlantısı olarak tutulmaz. SHA-256 ile doğrulanan özel dosya referansı kullanılır. Temiz taramadan sonra PDF, kanonik Runtime V2 preflight kuyruğuna alınır. İlk processing (işleniyor)/job makbuzu ölçülmüş sayfa, ebat, skor, verdict, rapor veya üretim kanıtı değildir. Bunlar ancak aynı kaynak, request, job, profil ve artifact bağına sahip terminal evidence doğrulandıktan sonra gösterilebilir. PDF preflight zararlı yazılım taramasının yerine geçmez. Bağımsız tarama temiz sonucu verene kadar dosya karantinadadır ve matbaaya ya da public yüzeye dağıtılamaz. E-posta ve MCP PDF girişleri aynı hash doğrulamalı, fail-closed tarayıcı sınırını kullanır; kitap içi ve kapak dosyaları interior ve cover rolleriyle ayrılır.

Bağımsız tarayıcı geçici olarak kullanılamıyorsa metin üzerinden RFQ ve teklif akışı devam eder; ekler temiz kabul edilmez, özel karantinada kalır ve tarama makbuzu oluşmadan AI, matbaa dağıtımı veya üretim handoff'una girmez. Karantinadaki PDF'nin dosya adında 56 SAYFA gibi tek ve açık bir sayfa beyanı varsa bu sayı yalnız müşteri beyanı olarak RFQ'ya taşınır; PDF ölçüldü kanıtı sayılmaz. Ebat ve diğer PDF gerçekleri temiz tarama ile Runtime V2 terminal preflight kanıtı tamamlanana kadar ölçülmüş kabul edilmez; fiyat-kritik bir varsayım kalıyorsa AutoBid fail-closed kalır.

Birden fazla PDF gönderildiğinde her dosyanın SHA-256 tarama makbuzu ve preflight kanıtı ayrı tutulur. Taraması reddedilen veya makbuzu eksik olan bileşen AI, teklif kanıtı ya da üretim handoff'una girmez; metin RFQ'su açık karantina notuyla ilerleyebilir. Teklif kabulünde iç blok, kapak veya ek gibi çok bileşenli işler tek bir PDF revision'ı gibi yükseltilmez. Her bileşenin kendi kabul edilmiş revision ve üretim handoff'u tamamlanana kadar sipariş component_handoffs_required durumunda kalır.

AI yalnızca serbest metin ve eklerden alan çıkarmaya yardımcı olur. RFQ'nun güvenle kalıcılaştırılmasına, hangi bilgilerin eksik olduğuna ve müşteriye gönderilen şablon metnine kanonik kurallar karar verir. Normal bilgi eksikliği RFQ'yu durdurmaz; AI emin olmadığı teknik bilgiyi veya fiyatı uyduramaz.

Müşteri ne yapar?

1. /tr/teklif sayfasına girer.
2. Ne bastıracağını, ürün türünü ve gerçek adedi yazar; dosya varsa yükler.
3. Ad ve e-posta bilgisini girer; şehir, teslim beklentisi ve diğer teknik ayrıntıları varsa ekler.
4. Teklif talebini gönderir.
5. Mailde gelen özel takip linkinden teklifleri izler.
6. Bir teklifi seçer.
7. Aynı e-posta ile kayıt olur veya giriş yapar.
8. Sipariş oluşur ve sipariş ekranından takip edilir.

Kitap ve yayın talepleri

Roman, dergi, yıllık rapor, yıllık, foto kitap ve ürün kataloğu gibi kitap/yayın talepleri tedarikçi RFQ akışına geçmeden önce Master Data yayın modeliyle kontrol edilir. Platform bu talepler için güvenilir katalog kanıtı ve değişmez Master Data kanıt kaydı tutar.

Kitap/yayın talebi güvenilir Master Data kanıtı olmadan gelirse yine geçerli bir talep olarak yayında kalır; ilk yayın için admin veya steward onayı beklemez. Bu durumda sistem otomatik teklif, tek tık teklif ve üretim aktarımı gibi riskli otomasyonları kapatır; talep operasyon kontrolüne düşer.

Bu tür talepler müşteri ve public yayın tarafında açık kalır; matbaa tarafında ise açık teklif fırsatı olarak ilerlemesi kapsam ve üretim uygunluğu kontrolüne bağlıdır. Müşteri teklifi siparişe çevirirken aynı kontrol kanıtı korunur. Admin yalnız spam/fraud, reddedilmiş/iptal edilmiş veya sonradan duraklatılmış taleplerde görünürlüğü kapatır.

Her baskı talebinde ne bastırılacağı, sunucuda çözümlenmiş kanonik L2 ürün yaprağı, ürün kategorisi ve müşterinin açıkça verdiği pozitif adet asgari yayın bilgisidir. Bunlardan biri eksikse ya da adet yalnız bir sistem varsayımıysa RFQ henüz oluşturulmaz ve matbaalara gönderilmez. Sistem müşteriden aynı konuşmada eksik kritik bilgiyi ister; bilgi tamamlanınca RFQ oluşturulur ve gerçek takip bağlantısı paylaşılır.

Flyer, etiket, ambalaj ve büyük ebat gibi taleplerde ebat, kağıt, cilt, şehir, termin, dosya veya başka kritik olmayan teknik bilgi eksikse RFQ yayınlanabilir. Bu eksikler operasyon sinyali olarak izlenir; sistem gerekirse Auto-Bid ve benzeri riskli otomasyonları kapatır, fakat asgari yayın kapısı geçilmiş talebi sırf bu ayrıntılar yüzünden matbaa fırsat akışından çıkarmaz.

Public liste ve detay sayfaları eski bir kayıttaki isPublic bayrağına tek başına güvenmez. Kritik completeness, pozitif tam sayı adet ve kanonik L2 ürün makbuzu ile doğrulanmış Marketplace grup makbuzu okuma sırasında da doğrulanır; eski veya bozuk kayıtlar matbaa akışında görünmez. Anasayfanın sunucu başlangıç listesi de aynı kontrolden geçer ve limit yalnız geçerli satırlar seçildikten sonra uygulanır. Eksik kategori, adet, şehir veya termin için görünür veri uydurulmaz.

Güncel RFQ snapshot policy kind'leri family-scoped tutulur: book_publication_required, p0_non_publication_snapshot_advisory ve generic_soft_link. Book benzeri product-catalogs ve catalogs talepleri tedarikçi otomasyonuna geçmeden güvenilir publication evidence ister; publication dışı family'ler RFQ intake için advisory kalır ve riskli otomasyon öncesi incelenir.

Kayıtsız müşteri nasıl devam eder?

Kayıtsız müşteri teklif talebi açabilir. Bu durumda sistem talebi e-posta adresine bağlar.

Önemli kural: Talebi hangi e-posta ile açtıysa, kayıt olurken de aynı e-postayı kullanmalıdır. Kayıt sonrası onboarding tamamlanmadan teklif siparişe çevrilmez; onboarding tamamlanınca aynı özel takip linkine geri dönülür.

Farklı e-posta ile giriş yapılırsa sistem talebi otomatik bağlamaz ve self-servis olarak sahiplenmeye izin vermez. Devam etmek için talebi açtığınız e-posta ile giriş yapmanız gerekir.

Matbaa tarafında ne olur?

Sadece onaylı üretici olan matbaalar teklif verebilir.

Matbaa kayıt oldu diye hemen teklif veremez. Admin tarafından organizasyonu kontrol edilir, rolü açılır ve onaylı üretici yapılır. Bu onay tamamlanmadan matbaa aktif talepleri göremez ve teklif veremez.

Matbaa kendi baskı ihtiyacı için teklif talebi açabilir. Ancak aynı organizasyon kendi talebine matbaa olarak teklif veremez.

Matbaa başka matbaaların tekliflerini, fiyatlarını, matbaa adlarını veya toplam teklif/görüntülenme sayılarını göremez. Bu bilgi yalnızca alıcıya ve gerekli admin/operasyon rollerine açıktır.

Bazı talepler manuel inceleme sürerken yayında kalır. Matbaa bu talebe koşullu fiyat verebilir; bu teklif henüz siparişe dönüştürülebilir bir onay değildir. Müşteri ekranı talebi hem Açık hem İncelemede olarak gösterir, kilidin nedenini açıklar ve Bu Teklifi Seç eylemini steward onayı tamamlanana kadar kapalı tutar. Onaydan sonra güncel talep yeniden okunur; Master Data/preflight ve üretim kanıtı kapıları ayrıca korunur.

Matbaa ekranı: /tr/dashboard/print-shop/incoming-rfq RFQ ve teklif değişiklikleri append-only revision olarak saklanır. Güncel belge bir okuma projeksiyonudur; kabul edilen her değişiklik revision'ı ilerletir ve aynı transaction içinde immutable sourcing veya ticari snapshot yazar. Stale tarayıcı daha yeni çalışmanın üstüne yazmak yerine revision conflict alır.

Ağ veya kanal tekrar denemesi, ilk kayıt başarıyla tamamlandıysa aynı RFQ'yu döndürür; ikinci talep ve ikinci bildirim oluşturmaz. Otomatik teklif hesaplanırken RFQ değişirse eski hesap teklif olarak kaydedilmez. Sistem yeni revizyonu yeniden fiyatlar; eski teklif hangi revizyonu fiyatladığını ve hangi yeni revizyonda güncelliğini yitirdiğini korur.

Teklif geçerliliği ve revizyon

Matbaa teklif verirken teslim gününü ve teklif geçerlilik süresini belirler. Sistem teklif geçerliliği için varsayılan 7 gün kullanır; matbaa API/form yüzeyinde izin verilen aralıkta bunu değiştirebilir. Teklif kabul edilmeden önce müşteri revizyon isteyebilir; matbaa revize fiyat ve teslim günüyle cevap verirse teklif tekrar müşterinin kararına döner.

Matbaa, yeni verdiği bekleyen teklifi oluşturma anından itibaren ilk 15 dakika içinde aynı teklif üzerinden düzeltebilir. Sürenin bitiş anı dahil değildir: tam 15. dakikada hızlı düzenleme kapanır. Daha sonraki fiyat veya teslimat değişikliği için müşteri aynı teklif bağlamında revizyon istemelidir. Kabul edilmiş, siparişe bağlanmış, reddedilmiş, geri çekilmiş veya süresi dolmuş teklif tek taraflı düzenlenemez. Düzenleme ekranı mevcut fiyat, teslim günü, nakliye, vergi beyanı, notlar ve varyantları yeniden yükler; daha eski bir tarayıcı revision uyuşmazlığında yeni kaydın üzerine yazamaz.

Tutarların otoritesi para birimine göre kanonik minor-unit kaydıdır. Ekran bu kaydı ilgili para biriminin ondalık kuralıyla gösterir; bozuk bir kanonik tutarı eski alanla veya sıfırla örtmez. Farklı para birimlerindeki kabul edilmiş teklifler tek bir TRY toplamına çevrilmeden, çoklu para birimi olarak gösterilir.

AutoBid tekliflerinde tutar, komisyon ve matbaa neti aynı kanonik minor-unit ticari kayıttan üretilir; teklif kaydında commissionMinor, netAmountMinor, tier/politika kanıtı ve expiresAt bulunur. Kesin generic costing teklifleri immutable maliyet/fiyat snapshot'larıyla, Bulut fason teklifleri ise tarife otoritesi pricing evidence'ıyla sipariş kabulüne hazırlanır. Varsayımlı AutoBid ön fiyatı müşteriye bağlayıcı teklif olarak gönderilmez.

Teklif, ekranda gösterilen geçerlilik anında kapanır; o anda veya sonrasında seçilemez. Kayıtlı geçerlilik değeri ya da teklif toplamına dahil olmayan zorunlu nakliye bedeli doğrulanamıyorsa sistem sınırsız süre veya sıfır nakliye varsaymaz; sipariş oluşumunu durdurur ve düzeltilmiş teklif ister.

RFQ ve teklif detayları hesaba bağlı özel kaynaklardır. Kopyalanmış bir dashboard/işlem bağlantısını açmak yine oturum ve ilgili alıcı, tedarikçi veya organizasyon sahipliğini gerektirir; RFQ id, takip kodu veya teklif id'sini bilmek tek başına yetki vermez.

Kişisel RFQ sahibi, hesabında aktif bir organizasyon seçili olsa da yalnız RFQ kaydında kendi hesap kimliğiyle eşleşen teklifleri görebilir. RFQ kaydında bir alıcı organizasyonu yoksa aktif organizasyon bu talebe sonradan otorite olarak eklenmez. Bu kişisel sahiplik, bir organizasyonun ortak teklif gelen kutusunu görme yetkisinden ayrıdır ve başka bir müşterinin talebine erişim vermez. RFQ kaydında alıcı organizasyonu varsa ortak gelen kutusu yalnız o organizasyonun güncel üyelik ve paket yetkisiyle açılır; talebi oluşturan hesap kimliği kişisel bir erişim kestirmesi değildir. Teklif listesi için kalıcı bir erişim reddi alınırsa ekran aynı isteği arka planda sürekli tekrarlamaz; yerelleştirilmiş bir uyarı ve açık Yeniden dene eylemi gösterir. Kişisel gelen kutusu, aynı hesap kimliğini denetim alanı olarak taşıyan ortak organizasyon kayıtlarını sonuç limiti uygulanmadan önce sayfalayarak ayırır. Güvenli tarama bütçesinde tamamlanamayan bir liste de sessizce “0 teklif” olarak sunulmaz. API bu durumda otomatik tekrar önerisi taşımayan bir kullanılabilirlik hatası döndürür. Kişisel dashboard ve Tekliflerim ekranı sıfır sayaç veya boş-gelen-kutusu görünümü yerine görünür uyarı gösterir; otomatik yenilemeyi durdurur ve yalnız kullanıcının Yeniden dene eylemiyle tekrar okur.

Teklif kabul edilip siparişe dönüştükten sonra fiyat artık tek taraflı değiştirilemez. Aynı iş kapsamında fiyat değişikliği gerekiyorsa bu, müşteri talebi ve matbaa/operasyon onayıyla yeni bir süreç olarak ele alınır.

Müşteriye uygun inceleme ve karşılaştırma

Herkese açık RFQ akışı, müşteriye talebi kontrol etmek için gereken normalize baskı özelliklerini gösterir. İç kaynak referansları, Master Data kökeni ve standart izlenebilirliği operasyon kanıtıdır; herkese açık müşteri sayfasında gösterilmez.

Tek bir kesin teklif seçilebilir bir tekliftir; karşılaştırma kazananı değildir. En iyi değer, en düşük fiyat, en hızlı teslimat, sıralama ve öneri dili yalnız gerçekten karşılaştırılabilen en az iki ödüllendirilebilir kesin teklif olduğunda açılır. En iyi değer puanları eşitse arayüz keyfî bir kazanan seçmez; müşteri ticari şartları değerlendirip karar verir.

Teklif seçilince ne olur?

Müşteri bir teklifi seçtiğinde:

• seçilen teklif siparişe dönüşür,
• diğer teklifler kapanır,
• sipariş müşteri ekranına düşer,
• matbaa siparişi üretim ekranında görür.

Teklifte kullanılan doğrulanmış tekil PDF varsa kabul anında hash'iyle siparişe sabitlenir. PDF yoksa, birden çok üretim bileşeni varsa veya preflight kanıtı yetersizse sipariş oluşabilir fakat üretim dosyası hazır sayılmaz. Sistem eksik dosyayı veya kanıtı ayrıca ister.

PDF Tools/Organize ile üretilen çıktı ya da sonradan yüklenen yeni PDF mevcut dosyanın üzerine sessizce yazılmaz. Müşteri yeni dosyayı açıkça onayladığında yeni bir revizyon oluşur; eski preflight, yerleşim ve dosyaya bağlı maliyet kanıtları geçersiz olur ve yeniden hesaplanır. Matbaa ancak güncel revizyona bağlı kesin yerleşim, postflight ve gerekiyorsa proof kanıtı tamamlandığında baskıya başlayabilir.

Siparişe çevirmeden önce sistem, müşterinin gördüğü teklif özetinin ve üretim bilgi paketinin değişmediğini doğrular. Bu kanıt eksikse veya bilgi değiştiyse müşteriden teklif karşılaştırmasını yenilemesi istenir; RFQ yayında kalır ama sipariş/üretim kapısı ilerlemez.

Müşteri sipariş ekranı: /tr/dashboard/my-orders

Matbaa sipariş ekranı: /tr/dashboard/print-shop/orders

Ödeme pilotta nasıl ilerler?

Canlı pilotta ödeme platform içinde kartla alınmaz. Kartla ödeme canlı pilot kapsamında yoktur. Ödemeyi platform tahsil eder; iş teslim edildikten sonra komisyonu keserek matbaaya öder.

Odeme onayi; havale/EFT, acik hesap, kurumsal odeme veya operasyon ekibinin manuel onayi ile ilerler. Odeme onayi uretime alma kapilarindan biridir; musteri dosyasi gerekiyorsa dosya da anlasilan inceleme kapisindan gecmeli ve onaylanmalidir. Uretim bilgi paketi veya dosya kapisi eksikse siparis ve kesin termin bu kanitlar hazir olana kadar bekler.

Sipariş ne zaman kapanır?

Matbaa siparişi teslim eder. Müşteri teslimatı kontrol eder ve siparişi kapatır. Sorun varsa destek ekibi sürece dahil olur.

İlgili sayfalar