WooCommerce 10.9.4 Blok Odemedeki KDV Muafiyet Hatasini Cozuyor

🇬🇧 English: Read this in English →

Tek cümlelik sürüm notlarına zaafım vardır. WooCommerce 10.9.4 sürümü 7 Temmuz’da tek satırlık bir düzeltmeyle yayınlandı — “Blok ödeme sayfasında oturum açmış müşteriler için is_vat_exempt bayrağının doğru uygulanmasını sağlar” — ve kurumsal müşteriye satış yapıyorsan bu, dışarıdan çok sessiz görünen ama içeride epeyce gürültülü bir hikâye barındırıyor.

Çünkü Avrupa Birliği’nde, Birleşik Krallık’ta veya Türkiye’de KDV muafiyeti olan işletme müşterilerine satış yapıyorsan ve mağazan Blok Ödeme kullanıyorsa, yaklaşık altı hafta boyunca bu müşterilerinden sessizce fazla vergi almış olabilirsin. Yalnızca Blok Ödeme’de. Yalnızca müşteri oturum açmışken. Bu tür bir hata anında destek talebi yaratmaz — müşteri ya yutar, ya iade talep eder, ya da hiçbir şey söylemeden başka bir mağazaya geçer. En sevmediğim hata sınıfı da tam olarak bu: kimse bağırmıyor ama para yanlış yerde.

Bu aynı zamanda WooCommerce’in on beş gün içinde çıkardığı dördüncü nokta sürüm — 10.9.2, 10.9.3, 10.9.4 — ve dördünde de kök neden 10.9.0 ile gelen niyeti iyi ama üretimle karşılaşınca kırılan bir iyileştirmeydi. Bu örüntü tek başına konuşmayı hak ediyor.

Gerçekten yeni olan ne

WooCommerce 10.9.4 sürümü 7 Temmuz 2026’da Brian Coords tarafından WooCommerce Developer Blog üzerinde duyuruldu. Güvenlik güncellemesi değil, veritabanı güncellemesi de gerektirmiyor. Değişiklik günlüğünde tek bir satır var: Blok Ödeme’de oturum açmış müşteriler için KDV muafiyeti düzeltmesi.

Düzeltme PR #66342 olarak kalessil tarafından hazırlandı ve 7 Temmuz’da ana dala birleştirildi. Yama, aynı geliştiricinin Nisan 2026’da yazdığı ve WooCommerce 10.9.0 sürümüyle 23 Haziran’da yayına giren bir Store API başarım iyileştirmesinin — PR #64392 — bir parçasını geri alıyor. O iyileştirme gerçek bir iş yapıyordu: POST /checkout ortanca yanıt süresi yaklaşık yüzde 20 iyileşti, P90 gecikmesi yüzde 27 düştü. Bunu yapabilmek için WC_Customer::save() içine erken çıkış eklendi; müşteri nesnesinde değişiklik yoksa veritabanı yazımı atlanıyordu.

Sorun şuradaydı: müşteri nesnesinde değişen her şey set_prop() üzerinden geçmiyor. Üç özellik bu yolun dışında kalıyor: password, calculated_shipping ve is_vat_exempt. Blok Ödeme isteği, oturum açmış bir müşterinin KDV muafiyet bayrağını değiştirdiğinde, değişiklik kontrolü bunu göremiyor, erken çıkış tetikleniyor ve sipariş vergi hesabı yapmadan önce bayrak sessizce yok oluyordu. Klasik (kısa kod) ödeme sayfası etkilenmedi. Misafir ödemesi etkilenmedi. Yalnızca kesişim — Blok Ödeme artı oturum açmış müşteri — etkilendi.

10.9.4 iki şey yapıyor. Birincisi, WC_Customer::save() içindeki erken çıkış kısa devresini kaldırıyor, böylece kayıt her koşulda veritabanına yazılıyor. İkincisi, WC_Customer için birim testler ekliyor ve tutarlılık için is_paying_customer değerini boole türüne dönüştürüyor. Değişen dosya plugins/woocommerce/includes/class-wc-customer.php, buna eşlik eden bir test dosyası da eklenmiş. Sürümün tamamı bu kadar.

Tempoyu görmek için: bu, on beş gündeki dördüncü 10.9.x nokta sürümü. 10.9.2 (3 Temmuz) güncelleme sırasında ayarlar SDK’sında yaşanan bir ölümcül hatayı düzeltip anlık bildirim özellik bayrağını emekliye ayırdı. 10.9.3 (yine 3 Temmuz) WC_Email::send_notification() içinde filtre kancasının boole olmayan değer döndürmesinden kaynaklı ölümcül hatayı düzeltti. 10.9.4 (7 Temmuz) bu KDV düzeltmesi. WooCommerce 11.0 sürümü 28 Temmuz’da bekleniyor.

En tehlikeli değişiklik türü: “hiçbir şey yapma”yı hızlandırmak

Bir dakika bu hatanın türü üzerinde durmak istiyorum, çünkü kariyerimde defalarca aynı tuzağa düşen ekipler gördüm. En sinsi performans iyileştirmesi, “gereksiz işi atla” diyen iyileştirmedir. Kulağa masum gelir: değişen bir şey yoksa neden veritabanına yazalım ki? Ama bu mantık, “değişen bir şey var mı” sorusunun cevabını doğru bildiğini varsayar. 10.9.0’ın tökezlediği yer tam olarak burası — üç özellik değişiklik kontrolünün göremediği bir yoldan giriyordu, dolayısıyla “değişiklik yok” cevabı yanlıştı ve iyileştirme yanlış bir gerçeğin üstüne kuruldu.

Açık konuşayım: bir işi tamamen kaldıran optimizasyonlar, o işi daha hızlı yapan optimizasyonlardan çok daha risklidir. Çünkü ikincisi bozulduğunda yavaşlarsın ve fark edersin; birincisi bozulduğunda hiçbir şey olmaz ve haftalar sonra vergi raporunda fark edersin. Ben olsam bir kayıt yolunu “koşullu atla” ile hızlandıran her PR’a iki kat dikkatle bakardım — özellikle o kaydın parayla, vergiyle ya da izinle ilgili bir bayrak taşıdığı yerlerde. Doğruluk, birkaç milisaniyeden her zaman daha pahalıdır.

WordPress ve WooCommerce ile çalışanlar için neden önemli

Blok Sepet ve Blok Ödeme üzerinden çalışan bir kurumsal mağazan varsa — ki bu WooCommerce 10.9’dan bu yana yeni kurulumların varsayılanı — bu bir arayüz hatası değil, veri bütünlüğü hatasıdır. 23 Haziran ile 7 Temmuz arasında, KDV muafiyeti Blok Ödeme sırasında belirlenen veya güncellenen her oturum açmış müşteriden, faturada yasal olarak olmaması gereken vergi tahsil edilmiş olabilir. Sipariş kaydı yanlış toplamı gösteriyor. Vergi raporu, aslında kazanmadığın bir geliri gösteriyor. AB’de üç aylık KDV beyannamesi veriyorsan, en az bir hafta için yanlış beyan vermiş olma ihtimalin çok yüksek.

Daha dar soru şu: mağazanda muafiyeti neyin tetiklediği. wp-admin üzerindeki müşteri profilinde bulunan yerleşik “Vergi muafiyetini etkinleştir” seçeneğini kullanıyorsan, o yol normal yönetici kaydından geçtiği için etkilenmedi. Kırılan yol, set_is_vat_exempt() çağrısının doğrudan ödeme isteği sırasında yapıldığı yol — en sık da AB KDV numarası doğrulama eklentisi, ödeme alanından KDV numarasını okuyup bayrağı çeviren bir B2B müşteri eklentisi ya da kendi woocommerce_store_api_checkout_update_customer_from_request kancan üzerinden. Kurulumun buysa, etkilendin demektir.

Daha geniş örüntü ise açıkça adlandırmayı hak ediyor. On beş günde dört nokta sürüm, her birinde 10.9.0 ile gelen iyi bir mühendisliğin bir parçası geri alındı veya sağlamlaştırıldı: ayarlar SDK yükleyicisi, e-posta filtre sözleşmesi ve şimdi de müşteri kayıt kısa devresi. Her biri PR incelemesinde makul görünüyordu. Her biri üretim verisinin gerçek şekliyle karşılaşınca çöktü. Ana sürüm gerçekten iddialı olduğunda — 10.9.0 duyurusuna göre 65 katılımcıdan 464 PR — böyle olur. Bu da neden yalnızca üretim kodunu değil, üretim müşteri profillerini de yansıtan bir hazırlık ortamına ihtiyacın olduğunun kanıtıdır.

Ne yapardım (veya yapmazdım)

Bugün 10.9.4 sürümüne geç. Beklemek için bir sebep yok. Tek satırlık işlevsel değişiklik ve testler, veritabanı göçü yok, şema değişikliği yok, ertelemenin tek riski KDV muafiyetli müşterilere yanlış fatura kesmeye devam etmek. 10.9.0, 10.9.1, 10.9.2 veya 10.9.3 üzerindeysen 10.9.4 hepsinin yerine geçiyor.

Üretimde güncellemeden önce denetimi yap. 23 Haziran ile 7 Temmuz arasında verilen ve müşterisi şu anda KDV muafiyetli olan ya da e-posta alan adı bir işletme KDV kaydıyla eşleşen siparişleri çıkar. Blok Ödeme üzerinden verilen siparişlere filtrele. Alınan vergiyi, vergi kurallarının söylediği vergiyle karşılaştır. Aralarında fark olan her sipariş, kısmi iade ve düzeltilmiş fatura adayıdır — ve evet, AB üye devletlerinin çoğunda yasal olarak yükümlülüğün sessizce farkı iade etmek değil, düzeltilmiş faturayı kesmektir. Türkiye’de de KDV mevzuatı aynı ilkeyi işletir.

Kod tarafında, set_is_vat_exempt(), set_password() veya set_calculated_shipping() çağıran bir eklenti ya da özel kod yönetiyorsan, savunma amaçlı bir save() çağrısı ekle ve “önce setter, sonra bir yerlerde save” davranışının değeri kaydedeceğini varsayma. Doğru örüntü zaten bu yöndeydi; 10.9.0 kısa süreliğine kestirmeyi ödüllendirdi. Bundan sonrası için bu davranış üzerine kod yazma — düzeltme bilinçli olarak save() metodunun değişiklik olsun olmasın her seferinde yazmasını sağlıyor.

Sürüm yönetimi tarafında ise şu üst üste dördüncü haftadır Woo 10.9 üzerindeki bir müşteriye söyleyeceğim şey aynı: üretimi ana dalın bir nokta sürüm gerisinde tut ve dalgalanmayı hazırlık ortamının emmesine izin ver. WooCommerce 11.0 sürümü 28 Temmuz’da varsayılan olarak ürün nesne önbelleklemesi ve Action Scheduler 4.0.0 ile geliyor — ikisi de anlamlı değişiklikler. Hazırlık denemesini 11.0 yayınlandıktan sonra değil, aday sürümü üzerinde yap.

İyi haber şu ki bu iş çözüldü, test edildi ve küçük. Daha az iyi haber ise, son iki haftada Blok Ödeme üzerinden çalışan bir kurumsal mağazan varsa, bakman gereken bazı faturalar var demektir.