WooCommerce'te Stok Güncellemesi Nasıl Geri Alınır (Geri Alma Yoksa Ne Yapmalı)

Düğmeye basmanızla bu cümleyi okumanız arasında bir yerde bir stok yazımı ters gitti. Yanlış miktarlarla uygulanmış bir sayım. 900 satırın üzerine yazan bir CSV içe aktarımı. İstediğinizden fazla ürünü yakalayan bir toplu düzenleme. Ve mağaza hâlâ açık, hâlâ sipariş alıyor, üzerine akıl yürütmeye çalıştığınız rakamları hâlâ hareket ettiriyor.

Bu sayfa bir açıklama değil bir müdahale kılavuzudur. Ne kadarını geri aldığınıza ve size ne kadara mal olduğuna göre sıralanmıştır; böylece aşağı doğru ilerleyip rakamlarınızı geri getiren ilk kademede durabilirsiniz. En kötü seçenek sonda, çünkü gerçekten en kötüsü — bir veritabanı geri yüklemesi yalnızca stoğu geri almaz.

Başlamadan bir sınır. Rakamlarınız tek bir tıkla bozulmak yerine haftalardır kayıyorsa burası yanlış sayfa: WooCommerce stok seviyelerini sessizce bozan sekiz şey istediğiniz sayfa. Burası, gerçekleşen ve gerçekleşmemesi gereken tek bir yazım içindir.

İlk beş dakika: ne yapmamalı#

Kötü biten neredeyse her kurtarma ilk beş dakikada kötü biter ve neredeyse her zaman aynı şekilde — biri, “o şeyin” ne olduğunu kaydetmeden düzeltmeye kalkışır.

Verdikleri zarara göre sıralı, yapılmaması gereken üç şey:

• Aynı şeyi tekrar çalıştırmayın. Dosyayı yeniden içe aktarmak, oturumu yeniden uygulamak, ikinci kez Güncelle‘ye basmak: her biri, birazdan yeniden kurmaya çalışacağınız durumun üzerine bir katman daha yazar ve her katman yeniden kurmayı zorlaştırır.
• Saymaya başlamayın. Saymak doğru uzun vadeli cevap, yanlış anlık cevaptır. Bir sayım sizde olmayan saatleri alır ve hâlâ açık bir kurtarma yolu varsa beş dakikalık bir çözümü iki günlük bir çözümle takas etmiş olursunuz.
• Gözünüze çarpan ürünleri elle düzeltmeyin. Dokuz yüz ürünü düzgünce düzeltecek bir yol dururken on bir ürünü elle düzeltmek, o yolu izlediğinizde on bir düzeltmenizin de üzerine yazılması demektir — ve o noktada hangi on bir olduğunu artık bilmiyorsunuzdur.

Bunun yerine yapılacak iki şey ve ikisi de bir dakikadan kısa sürüyor:

• Hâlâ yazan neyse durdurun. İçe aktarımı devre dışı bırakın, oturumu kapatın, senkronizasyonu duraklatın. Buna zamanlanmış bir görev ya da bir ERP bağlayıcısı yol açtıysa kendi başına tekrar çalışacaktır.
• Mevcut, bozuk durumu CSV’ye aktarın. Anlamsız geliyor — yanlış rakamların kaydı sonuçta. Aynı zamanda tam olarak neyin yanlış olduğuna dair sahip olacağınız tek kayıttır ve bu sayfadaki sonraki her doğrulama adımı ona karşı yapılan bir karşılaştırmadır. WooCommerce’in kendi ürün dışa aktarıcısı, kimlik, SKU ve stokla sınırlandırıldığında yeterlidir.

Saati de not edin. Düzen olsun diye değil: aşağıdaki birkaç yol, bir yedeğin, bir dışa aktarımın ya da bir geri dönüş noktasının olaydan önce olup olmadığını bilmeye dayanıyor ve “bu sabah bir ara” bunu cevaplayacak kadar kesin değil.

Bu dört şeyden hangisi başınıza geldi?#

Dönüş yolu, rakamların ne kadar kötü göründüğünden çok onları neyin yazdığına bağlıdır. Dört neden neredeyse her şeyi kapsıyor:

• Bir sayım yanlış rakamlarla uygulandı — yanlış miktarlar girildi ya da doğru miktarlar yanlış modda uygulandı. Kısmi bir sayımı tam ya da sıfır tabanlı olarak uygulamak klasik hâlidir: saymadığınız her şey sıfıra yazılır; bu, eksiksiz bir tarama için doğru davranış, bir nokta kontrolü için felakettir.
• Bir CSV içe aktarımı stoğun üzerine yazdı. Genellikle bambaşka bir amaç için hazırlanmış — bir fiyat güncellemesi, bir tedarikçi beslemesi — ve kimsenin fark etmediği bir stok sütunu taşıyan bir dosya.
• Bir toplu ya da hızlı düzenleme amaçlanandan fazla ürüne dokundu. Göründüğünden geniş bir filtre ya da ekrandaki 40 yerine sessizce 1,200’ün tamamını kasteden Tümünü seç.
• Onu başka bir şey yazdı. Bir senkronizasyon eklentisi, bir ERP bağlayıcısı, bir REST entegrasyonu, bir pazaryeri listeleme aracı. Bunlar en zorudur, çünkü elle ne düzeltirseniz düzeltin bir sonraki çalışmalarında aynısını yapacaklardır.

Hiçbir şeye dokunmadan önce nedeni yola eşleyin:

Kademe 1 — uygulamayı geri alın#

Kötü yazım bir sayım oturumunun uygulanmasından geldiyse dönüş yolu zaten var ve onu oluşturmak için hiçbir şey yapmanız gerekmedi. Her uygulamadan hemen önce otomatik olarak bir geri dönüş noktası yazılır — sonra değil önce yazılmasının bütün nedeni de budur.

Basmadan önce kontrol edilecek iki şey, çünkü geri yükleme de bir yazımdır:

• Uygulama ne kadar önceydi? Geri yükleme, kaydedilen rakamları olduğu gibi geri yazar. Arada stoğu hareket ettiren her şey — satışlar, iadeler, ikinci bir uygulama — hatayla birlikte üzerine yazılır. On dakikalık satış hiçbir şeydir. Bir buçuk günlük satış, yaratmayı seçtiğiniz ikinci bir sorundur.
• O zamandan beri başka bir şey uygulandı mı? Üstüne başka bir oturum uygulandıysa öncekini geri yüklemek beklediğiniz sonucu vermez. Geriye doğru, en yenisinden başlayarak çalışın.

Ücretsiz sürümde elinizin altındaki şey en son uygulamayı geri almaktır ve neredeyse her zaman isteyeceğiniz şey odur. Geri dönüş noktalarının tam geçmişi — sonraki uygulamaların gerisine, daha eski birine uzanmak — bir Pro özelliğidir. Bu ayrım tam da kötü uygulamanın sonuncusu olmadığını fark ettiğiniz anda önem kazanır; bu da bir şey satın almak için değil, uygulamadan önce fark raporunu okumak için bir gerekçedir.

Bir geri dönüş noktası neyi tutar — ve neyi tutmaz#

En yaygın ikinci hata, geri dönüş noktasını bir yedek sanmaktır. Değildir ve tuttuğu şeyle insanların tuttuğunu sandığı şey arasındaki boşluk, sonraki saatin kaybolduğu yerdir.

Karenin içinde: o uygulamanın dokunduğu her satırın stok miktarı, dokunulmadan hemen önceki hâliyle ve bunu hangi oturumun yaptığının kaydı. Bu, uygulamayı tamamen geri almaya tam olarak yeter; var olma amacı da budur.

Karenin dışında: diğer her şey. O oturumun hiç dokunmadığı ürünler başlarına ne geldiyse onu korur. Fiyatlar, maliyet alanları ve ürün verisi el değmemiş kalır — bir geri yükleme, aynı öğleden sonra yaptığınız bir fiyat değişikliğini geri almaz. Siparişler, iadeler ve ödemeler el değmemiş kalır; bu doğrudur ve açıkça söylenmeye değer, çünkü Kademe 4’ün tam tersidir. Ve uygulamadan sonra stoğu hareket ettiren her şey korunmaz, üzerine yazılır.

Bu son nokta, teknik bir ayrıntının içinde saklanan operasyonel bir kuraldır: erken geri yükleyin. Bir geri yüklemenin bedeli, uygulamayla geri yükleme arasında ne satış olduysa odur; yani 10:05’te bir geri yükleme size hiçbir şeye mal olmaz, perşembe günü yapılan bir geri yükleme size çarşambayı kaybettirir.

Kademe 2 — zaten elinizde olan bir dışa aktarımdan yeniden kurun#

Yazım bir sayımdan gelmediyse — bir içe aktarım, bir toplu düzenleme, bir senkronizasyon — geri dönüş noktası yoktur ve soru şuna dönüşür: herhangi bir yerde, olaydan önceki stok rakamlarını tutan bir dosya var mı?

Çoğu mağazada vardır ve onu bir yedek olarak düşünmezler. Şunlara bakın:

• Önceki bir sayım oturumundan aktarılmış bir CSV. Sayımı dışa aktarmak ücretsiz bir özelliktir ve çoğu kişi bunu bir kez yapıp yaptığını unutur.
• Ürünler → Dışa Aktar üzerinden, herhangi bir nedenle alınmış bir WooCommerce ürün dışa aktarımı.
• Mali müşavirinizin yıl sonunda istediği dosya. Hesaplarla birlikte beyan edilen bir kapanış stoğu rakamının arkasında genellikle birinin hâlâ sakladığı bir tablo vardır.
• Kendi kataloğunuzdan üretilmiş bir tedarikçi ya da pazaryeri beslemesi.
• Birinin bir kampanyayı planlamak için hazırladığı tablo.

Bunlardan herhangi biri, olaydan önceyse ve SKU ile stok taşıyorsa bir kurtarma dosyasıdır. Yaşı neyi kaybedeceğinizi belirler: dışa aktarımla olay arasındaki hareketler gitmiştir, yani pazartesiden kalma bir dosyayı cuma günü kullanmak size dört günlük düzeltmeye mal olur. Bu genellikle düzelttiğiniz hatadan çok daha küçük bir hatadır ama hiç değildir ve gelecek ay bir muammaya dönüşmesin diye not edilmeye değer.

İçe aktarmadan önce dosyayı kırpın#

Bu, insanların atladığı ve sonra pişman olduğu adımdır. WooCommerce içe aktarıcısı dosyada bulunan her sütunu günceller — yani stoğu düzeltmek için yeniden içe aktarılan tam bir ürün dışa aktarımı, açıklamaları, fiyatları, kategorileri ve görsel atamalarını da dışa aktarım günündeki hâllerine geri yazar.

Tanımlayıcı ile stok miktarı dışındaki her sütunu silin. Varsa kimlik, yoksa SKU. İki sütun, başka bir şey yok. Sonra içe aktarma ekranında Mevcut ürünleri güncelle kutusunu işaretleyin — o olmadan içe aktarıcı satırlarınızı yeni ürün sayar ve elinizde bir stok sorununun üstüne binmiş bir kopya katalog kalır.

Önce beş satır aktarın. Formalite olsun diye değil: beş satırlık bir test, tanımlayıcı sütununuzun hiç eşleşip eşleşmediğini söyler ve yanlış sütuna karşı eşleşmek, siz bir ürünü açıp bakana kadar tıpatıp başarı gibi görünen bir hatadır.

Kademe 3 — siparişten gelen değişiklikleri sipariş notlarından yeniden kurun#

Geri dönüş noktası da dışa aktarım da yokken WooCommerce yine de kimsenin öyle düşünmediği bir denetim izi tutar: sipariş notları.

WooCommerce bir sipariş için stoğu her düşürdüğünde, o siparişe hareketi ve iki yanındaki rakamları kaydeden bir not yazar — ürün, miktar ve öncesi ile sonrası. İptal ve iadelerden gelen stok geri eklemeleri de aynı şekilde not edilir. Bu, tek bir ekranda toplanmak yerine siparişlerinize dağılmış ama siparişlerin yaptığı her şey için eksiksiz olan, ürün bazında bir hareket günlüğüdür.

Tek bir ürün için yöntem:

• Rakamın doğru olduğunu bildiğiniz bir an bulun — son sayım, son dışa aktarım, onu ayarladığınız gün.
• O tarihle bugün arasında o ürünü içeren siparişleri listeleyin.
• Her birindeki stok notunu okuyun ve hareketleri toplayın.
• Toplamı, doğru olduğunu bildiğiniz rakama uygulayın. Siparişlerin yol açmadığı bir şey yoksa rakamın olması gereken değer budur.

İki sınır var ve ikisi de büyük. Birincisi, sipariş notları yalnızca siparişlerin yaptığını kapsar. Elle bir düzenleme, bir içe aktarım, bir sayım uygulaması ve bir senkronizasyon arkalarında hiçbir şey bırakmaz — yani kurtarmaya çalıştığınız olay bunlardan biriyse bu yöntem deliği doldurmak yerine deliğin etrafındaki rafın şeklini yeniden kurar. İkincisi, ölçeklenmez: bu, bir katalog için değil önemli olan yirmi ürün için bir yöntemdir.

Notların eksiksiz olduğuna güvenmeden önce bilinmesi gereken bir tuzak: yönetim ekranında elle oluşturulmuş bir sipariş her zaman stoğu düşürmez ve düşürmediğinde okunacak bir not da olmaz. Stoğa hiç dokunmamış manuel siparişler bu boşluğun tamamlayıcısıdır.

Kademe 4 — veritabanı geri yükleme ve ödediğiniz bedel#

Hosting sağlayıcınızın gecelik yedekleri var ve geri yükleme düğmesi tam orada; bu kademeyi tehlikeli yapan da tam olarak bu. Basılması en kolay olan ve size doğruluk yerine para kaybettirebilecek tek kademe budur.

Bir veritabanı geri yüklemesi stoğu geri yüklemez. Veritabanını geri yükler. O yedekten beri verilen her sipariş, kaydolan her müşteri, kaydedilen her ödeme, kullanılan her kupon, bırakılan her değerlendirme — hepsi eski hâline döner. Ödemelerin kendisi alınmış kalır, çünkü veritabanınızda değil ödeme kuruluşunda gerçekleştiler. Elinizde alınmış para ve onu eşleştirecek sipariş olmadan kalırsınız; bu da yanlış stok rakamlarından epeyce daha kötü bir pazartesidir.

Yani dürüst tavsiye şu: stoğu düzeltmek için bunu neredeyse hiç yapmayın. Hasar gerçekten veritabanı çapındaysa yapın ve o zaman bile çoğu kişinin aklına hiç gelmeyen varyantı tercih edin.

Yedeği başka bir yere geri yükleyin ve okuyun#

Yedeğin sizin siteniz olmasına ihtiyacınız yok. İçindeki rakamlara ihtiyacınız var.

Onu bir hazırlık (staging) sitesine ya da yerel bir kopyaya geri yükleyin, ürünleri oradan dışa aktarın, o dışa aktarımı tanımlayıcı ve stoğa kırpın ve sonucu canlı mağazanıza içe aktarın. Kademe 4’ü Kademe 2’ye çevirmiş olursunuz: olaydan önceki stok rakamlarını alırsınız ve o zamandan beri alınan her sipariş tam olduğu yerde kalır.

Bu beş dakika değil bir saat sürer ve her seferinde o saate değer. Hosting sağlayıcınız tek tıkla hazırlık ortamı sunuyorsa, ters gidecek çok daha az şeyle aynı saattir.

WooCommerce çekirdeğinin size vermediği şeyler#

Bu boşluk hakkında açık olmak gerekir, çünkü bu sayfanın dört kademeye ihtiyaç duymasının nedeni platformun bunların hiçbirini sağlamamasıdır.

• Stok alanında geçmiş yok. WordPress revizyonları yazı içeriğini kapsar, stoğun yaşadığı meta alanlarını değil. Geri dönülecek bir şey yoktur.
• Stok denetim günlüğü yok. Sipariş notları siparişlerin ne yaptığını kaydeder. İnsanların ne yaptığını hiçbir şey kaydetmez.
• Toplu düzenleyicide geri alma yok, içe aktarıcıda da yok. İkisi de anında yazar ve ikisi de yerine koyduğu şeyi saklamaz.
• Hasarla orantılı bir uyarı yok. Aynı anda 1,200 stok rakamı yazmak, tek bir tane yazmakla tıpatıp aynı görünür.

Asıl boşluk sonuncusudur. Platformda hiçbir şey sıradan bir düzenlemeyi katalog çapında bir üzerine yazmadan ayırmaz; korumanın, yazan şeyin kendisinden gelmek zorunda olmasının nedeni de budur — yazımdan önce bir inceleme ekranı ve değişmek üzere olanın kaydedilmiş bir kopyası. Bu kategorideki çok az araç bunlardan birini yapıyor ve birini seçmeden önce bunu bilmek gerekir.

CSV yolu: yeniden içe aktarmak ne zaman yardım eder, ne zaman işi büyütür#

Yeniden içe aktarmak en yaygın kurtarma denemesi ve bir sorunu ikiye çevirmenin en yaygın yoludur. Fark tamamen hangi dosyayı kullandığınızda ve ondan ne kadarını sakladığınızdadır.

Dosya olaydan önceyse, yalnızca tanımlayıcı ile stok sütununu içeriyorsa ve Mevcut ürünleri güncelle işaretli olarak aktarılıyorsa yardım eder.

Dört belirgin şekilde işi büyütür ve hepsi önlenebilir:

• Olaydan sonra dışa aktardığınız bir dosyayı içe aktarmak. Bozuk rakamları içerir. Bu kulağa geldiğinden daha sık olur, çünkü beş saniyede bulabildiğiniz dışa aktarım her zaman az önce oluşturduğunuzdur.
• Her sütunu içe aktarmak. Stok düzelir; açıklamalar, fiyatlar ve kategoriler sessizce dışa aktarım gününe döner. Stok sorunu çözülür ve bir içerik sorunu yaratılır; ikincisi haftalar sonra, ortada belirgin bir neden yokken yüzeye çıkar.
• Boş hücreler. Boş bir stok hücresi güvenilir biçimde “buna dokunma” diye okunmaz — dosyanın nasıl üretildiğine bağlı olarak alanı temizleyebilir. Yok sayılacaklarına güvenmek yerine boşları ayıklayın.
• Yanlış sütuna göre eşleştirmek. Tanımlayıcı eşleşmezse içe aktarıcı ürünleri güncellemek yerine yenilerini oluşturur. Beş satırlık test tam da bunu yakalamak için vardır.

Bu sayfaya bir daha hiç ihtiyaç duymamanın yolu#

Yukarıdaki her yol tek bir kararın sonucudur: bir şeyin, yerine koyduğunun kopyasını saklamadan aynı anda çok sayıda stok rakamı yazmasına izin verildi. Dört alışkanlık bunun neredeyse tamamını ortadan kaldırıyor.

• Her toplu yazımdan önce dışa aktarın. Kimlik, SKU, stok. Otuz saniye ve gelecekteki her olayı Kademe 2’ye çevirir.
• Tek seferde değil bölge bölge sayın. 60 satıra dokunan bir uygulamanın etki alanı 60 satırdır. Bir döngüsel sayım takvimi her yazımı, kurtarmanın hiç dramatik olmayacağı kadar küçük tutar.
• Gerçekten her yeri taramadıysanız kısmi modu seçin. Mod, oturum başına bir karardır; çünkü elinizdeki en yıkıcı denetimdir ve tam ya da sıfır tabanlı mod yalnızca eksiksiz bir taramadan sonra doğrudur.
• Uygulamadan önce fark raporunu okuyun. Toplamı değil — satır sayısını ve en büyük birkaç satırı. Tek bir göz saydığınız hâlde 900 satırın değiştiğini söyleyen bir rapor, size hiçbir şeye mal olmadan önce bir şey anlatıyordur.

Ve tam da bunun korkusu hiç sayım yapmamış olmanızın nedeniyse, bu sayfanın iki yanındaki sayfalar zamana değer: yöntem için WooCommerce’te stok sayımı nasıl yapılır ve herkesin ilk sorduğu soru için sayım ortasında gelen siparişlere ne olur. Ve kötü yazımın gerçekleştiğinden bile emin değilseniz, reddedilmiş bir stok güncellemesini sessiz olandan ayırmak yukarıdaki bütün kademelerden önce gelir.