WooCommerce Teslimat Tarihi Alanı Nasıl Doğrulanır?

Teslimat tarihi alanı neyi çözer?

WooCommerce Checkout bloğunda müşterinin tercih ettiği teslimat gününü toplamak için ek ödeme alanlarının date türü kullanılabilir. Bu alan bir tercih kaydeder; seçilen günün taşıyıcı, depo veya kurye tarafından kesin olarak karşılanacağını tek başına garanti etmez. İşletme önce teslimat vaadini tanımlamalı, ardından tarih sınırını, kapasite denetimini ve müşteriye gösterilen açıklamayı aynı kurala bağlamalıdır. WooCommerce’in 11.2 sürüm notu tarih alanının Checkout bloğu için desteklendiğini duyurur.

Müşteri yalnızca bir tarih seçtiğinde sipariş yönetiminde iki ayrı soru doğar: “Hangi günü istedi?” ve “Hangi gün teslim edebiliyoruz?” Bu ikisini tek alan gibi göstermek yanlış beklenti yaratır. Bu rehber, alanı açmadan önce verilmesi gereken iş kararlarını ve geliştirici ile doğrulanacak teknik kontrolleri sıralar. Kargo teslim tarihi, mağazadan teslim, randevulu kurye ve taze ürün dağıtımı aynı kurallara sahip değildir; örnekleri kendi operasyonunuza uyarlayın.

Önce teslimat sözünü yazın

Tarih seçici tasarlanmadan önce sipariş kabulü ile teslimat onayının farkı satış ve operasyon ekibince belirlenmelidir. Müşteriye “tercih edilen gün” deniyorsa bu sözcük sipariş özetinde ve bildirimde de korunmalı. İşletme kesin gün garantisi verebiliyorsa o günün kapasite, rota, ürün hazırlığı ve ödeme durumu birlikte denetlenmelidir. Sadece takvimde gün seçtirip arka tarafta bu kontrolleri yapmamak, arayüzün ima ettiği sözü işletmenin yerine getirememesine yol açabilir.

Basit bir karar tablosu hazırlayın: Hangi ürünler aynı gün hazırlanabilir? Hafta sonu, resmî tatil veya yoğun günlerde dağıtım var mı? Hangi posta kodları veya adres bölgeleri dışarıda? Sipariş kapanış saati nedir? Birden fazla ürün farklı depolardan geliyorsa ortak tarih nasıl seçilir? İade veya adres değişikliğinde tercih edilen gün yeniden sorulacak mı? Bu soruların yanıtı olmadan teknik min ve max değerini seçmek erken olur.

Checkout bloğunda alan nereye yerleşir?

WooCommerce’in ek ödeme alanları belgesi contact, address ve order konumlarını ayırır. Teslimat tercihi belirli siparişe aitse order konumu çoğu senaryoda daha anlaşılırdır. Müşterinin kalıcı adres özelliği gibi ele alınması, sonraki alışverişte eski tarihin yanlışlıkla taşınması riskini doğurur. Alan etiketini “Tercih ettiğiniz teslimat günü” gibi açık yazın; zorunlu tutulacaksa gerçekten gerekli olduğunu doğrulayın.

Bu tercih tüm sepet için mi, her ürün için mi geçerli? Çok ürünlü siparişte tek alanın anlamı belirsizse müşteriye tek sipariş için ortak gün seçildiğini söyleyin. Ürün bazında farklı teslimat gerekiyorsa tek bir ödeme alanı problemi çözmez; sipariş parçalama veya ayrı teslimat akışı gündeme gelir. Tasarım incelemesinde masaüstü kadar mobil takvimi ve ekran okuyucuya sunulan etiketi de deneyin.

Tarih aralığı ve geçerlilik nasıl kurulur?

WooCommerce belgelerine göre tarih alanı değeri YYYY-MM-DD biçiminde saklanır. min ve max sabit gün veya bugüne göre göreli süre kabul eder; resmî örnek P1D ile yarından başlayıp P30D ile otuz gün sonrasına uzanır. Bu sınırlar işletmenin gerçek teslimat aralığına göre belirlenmelidir. Tarayıcıda görünen tarih biçimi ile saklanan değerin farklı olabileceğini özellikle Türkçe ve farklı dil ayarlarında test edin. 11.2 ön sürüm açıklaması yerel görüntüleme ile site tarih biçimini ayırır.

Gün aralığı, tatil ve kapasite kuralının yerine geçmez. Örneğin “yarından itibaren otuz gün” pazar gününü de kapsayabilir; pazar teslimatı yoksa ek iş kuralı gerekir. Bir gün sipariş alındığı anda doluysa açık takvimde görünse bile ödeme gönderilirken yeniden kontrol edilmelidir. Kullanıcıya “Bu gün doldu, başka gün seçin” gibi uygulanabilir hata gösterin. Seçilen tarihin saat bileşeni olmadığını unutmayın; sabah ve akşam teslimat penceresi ayrıca modellenmelidir.

Geliştirici tarafında yalnızca takvimde günleri gizlemek yeterli kabul ölçütü değildir. Alanın gönderilen değerini sunucu tarafında doğrulayın; WooCommerce belgeleri validation ve validate_callback seçeneklerini açıklar. Sipariş gönderimindeki kural, ön yüzde gösterilen kuralın gerisinde kalmamalı. Hatalı biçim, geçmiş gün, teslimat bölgesi dışı adres ve son anda dolan kapasite senaryolarını ayrı deneyin. Sunucu saat dilimi ile müşterinin cihaz saat dilimi farklıysa “bugün” sınırının hangi saate göre hesaplandığını ürün sahibiyle netleştirin.

Sipariş ve bildirim akışını birlikte deneyin

Kontrol listesi yalnızca alanın ekranda görünmesini ölçmemeli. Müşteri gün seçip ödemeyi tamamladığında tercih sipariş ayrıntısında okunabilir mi? İptal edilen veya başarısız ödemede hatalı rezervasyon kalıyor mu? İşletmenin operasyon panelinde tarih filtrelenebiliyor mu? Müşteriye giden onay metni kesin teslimat sözü veriyor mu, yoksa tercih olarak mı anlatıyor? Kargo veya kurye sistemi bu alanı kullanacaksa eşleme ve hata durumu açıkça belgelenmeli.

Ödeme yöntemleri ve Checkout bloğu çevresindeki eklentiler farklı davranabildiği için temel kart ödeme akışının yanında hızlı ödeme seçeneğini de gerçek mağaza yapılandırmasında test edin. WooCommerce hızlı ödemede özel alanlar yazısı, alanın ödeme kısayollarında görünmesi ve siparişe geçmesi için ayrı test senaryolarını ele alır. Buradaki konu ise teslimat tarihinin operasyon kuralıyla uyumudur; iki kontrol birlikte gereklidir.

Sürüm yükseltmesi öncesi test ortamında aynı alanı kullanın. Takvimde gün seçildiğinde sipariş tamamlanmalı, tarih siparişe doğru biçimde geçmeli ve hata mesajları anlaşılır kalmalı. WooCommerce 11.2 desteği yeni olduğundan mevcut tema, ödeme eklentisi ve özelleştirmelerin uyumunu canlıya almadan önce kendi kurulumunuzda ölçün. Bir eklentinin tarih alanını desteklediğini belgede görmemek, desteklediği veya desteklemediği sonucunu tek başına vermez.

Hangi durumda ayrı teslimat yazılımı gerekir?

Gün başına sınırlı kapasite, adres bazlı rota, birden fazla depo, kurye ataması veya canlı slot güncellemesi gerekiyorsa form alanı yalnızca veri toplama katmanıdır. Kapasiteyi tutan bir servis, sipariş durumuyla uyumlu rezervasyon ve değişiklik akışı ayrıca tasarlanmalıdır. Böyle bir çözümde öncelik, müşterinin gördüğü seçenekle operasyonun onaylayabildiği seçeneği aynı veri kaynağına bağlamaktır. Bunu yapmadan teslimat tarihi alanını “randevu sistemi” diye sunmak doğru olmaz.

Başlangıç için küçük bir pilot seçin: tek teslimat bölgesi, tek ürün grubu, açıkça yazılmış gün kuralları. Başarısız ödeme, iade, adres güncelleme ve tarih değiştirme olaylarını kayıt altına alın. Hangi senaryonun otomatik, hangisinin ekip onayıyla çözüleceği belli olsun. Sonuçları sipariş bazında değerlendirirken müşteri talebi ile gerçekten yerine getirilen teslimatı ayrı sayın; yalnızca alanın doldurulmasını başarı olarak yorumlamayın.

Webinle’nin web yazılım hizmeti kapsamında mağazanızın Checkout bloğu, ödeme akışı ve teslimat operasyonu birlikte değerlendirilebilir. Görüşmeye mevcut ödeme sayfasını, kullanılan teslimat yöntemlerini, açık günleri ve müşteriye verdiğiniz teslimat sözünü getirmeniz yeterli; böylece alan mı yoksa kapasiteyle bağlantılı bir akış mı gerektiği somut biçimde belirlenir.