WooCommerce satış raporu kasayla neden tutmuyor

Saat altı, kepenkler yarıya inmiş ve iki sayı birbirine bakıyor. Biri ekranda. Diğeri elinizdeki nakit, artı kart terminalinin kapattığını söylediği tutar. Birbirlerine yakınlar. Ama aynı değiller. Üstelik aradaki fark hiçbir zaman iki kez aynı büyüklükte olmuyor.

Bu, WooCommerce üzerinden yüz yüze satış yapılan ilk ayın ardından bir dükkân sahibinin en sık sorduğu sorulardan biridir. Her şeyden önce elenmeye değer bir cevap var, çünkü gerçekten yaşanıyor: WooCommerce Analytics siparişlerinizi doğrudan okumaz, kendi arama tablolarını okur ve o tablolar arka plan işleriyle doldurulur. Bu kuyruk takıldıysa ya da hâlâ birikeni kapatıyorsa, Analytics gerçekten geride kalır. Kuyruğu WooCommerce → Status → Scheduled Actions altında görebilirsiniz; Analytics → Settings ekranında da tabloları yeniden kuran bir Import historical data denetimi vardır. Ne var ki imzası ayırt edicidir: Analytics her şeyde geridedir, sipariş listenizde apaçık duran siparişler dahil.

Bu ihtimal elendikten sonra, bir WooCommerce satış rakamı ile tezgâhtaki hasılat arasındaki uyuşmazlık beş nedenden birinden gelir ve bunların hiçbiri genellikle bir hata değildir; iki ekran, iki farklı soruyu dürüstçe cevaplıyordur.

Bu yazı beşini de, kontrol edilmeye değer sırayla geziyor. Tezgâhın ardından yazıldığı için satışlarınızın bir kısmının yüz yüze kesildiğini varsayıyor. Sorununuz elle girilen bir siparişin en baştan stoku hiç hareket ettirmemiş olmasıysa, o başka bir arıza ve başka bir çözüm; WooCommerce’te elle açılan siparişler stoku neden düşürmez yazısında ele alınıyor. WooCommerce üzerinden yüz yüze satış yapıp yapmayacağınıza hâlâ karar veriyorsanız, WooCommerce’in yerleşik bir satış noktası var mı yazısından başlayın.

İki ekran, iki sayı ve önce hangisine güvenmeli#

Ava çıkmadan önce neyle mutabakat yaptığınıza karar verin. Küçük bir dükkânda üç aday gerçek vardır ve birbirlerinin yerine geçmezler:

• Çekmece ve terminal. Sayılan fiziksel nakit, artı kart makinesinin kendi kapanış raporu. Bu, para hakkındaki gerçektir.
• Sipariş kayıtları. WooCommerce’in neyin, hangi fiyattan, hangi tarihte, hangi durumda satıldığına dair inancı. Bu, işlemler hakkındaki gerçektir.
• Bir rapor ekranı. Sipariş kayıtlarından bir zaman aralığı için hesaplanan, hangi durumların sayılacağına ve iadelerin nasıl işleneceğine dair kuralları olan bir özet. Bu, işlemlere sorulmuş bir sorudur ve soru değiştikçe cevap da değişir.

Uyuşmazlıkların çoğu ikinciyle üçüncü arasındaki bir anlaşmazlıktır ve güvenilmesi gereken ikincisidir. Sipariş kayıtları tek tek durur, tarihlidir ve incelenebilir. Rapor ise varsayımları içine gömülmüş bir toplamdır. Dolayısıyla ilk hamle asla “hangi ekran bozuk” değildir; “bu ekran hangi siparişleri, hangi tarihler arasında sayıyor” olmalıdır.

Birinci neden: toplam satışları sayıyor ama geri çıkan parayı saymıyor#

Gözden kaçırması en kolay neden budur, çünkü bir iade rakamı doğası gereği görünmezdir. Kimse bir çıkarma işleminin yokluğunu fark etmez.

Satıştan sonra paranın çekmeceden çıkmasının iki ayrı yolu vardır ve bir raporun ikisini de yakalaması gerekir:

• Asıl siparişe karşı kısmi ya da tam iade. WooCommerce bunu siparişe bağlı bir iade kaydı olarak tutar. Kritik nokta şu: siparişin kendi toplamı değişmez; £10’unu iade ettiğiniz £40’lık bir sipariş yine £40 toplam bildirir. £10’u yalnızca ayrıca okunan iade tutarı gösterir.
• Asıl siparişin hiç işin içinde olmadığı bir iade. Biri elinde ürünle ve sipariş numarası olmadan içeri girer, siz de geri alırsınız. İadeyi bağlayacak bir şey olmadığı için iadenin kendi belgesi olmak zorundadır. Bunun nasıl alındığının ayrıntıları fişsiz iade nasıl alınır yazısında; bu yazıyı ilgilendiren tek şey toplamlarınıza ne yaptığı.

Tezgâh eklentimizde kör iade, kendi başına bir WooCommerce siparişi olarak, pozitif toplamla, Refunded durumunda ve onu bir iade olarak tanımlayan bir işaretle saklanır. Kontrol paneli bu işareti okur ve tutarı dönemden düşer. Sıradan satışlara karşı yapılan iadeler ise ayrıca netleştirilir: siparişin durumuna güvenmek yerine her siparişin iade edilmiş tutarı okunur. İkisi de önemlidir; biri olmadan diğeri yine size yanlış bir sayı verir.

O işaret göründüğünden fazla iş yapıyor. Durum tek başına hiçbir şeyin kanıtı değildir: sonradan WooCommerce’in kendi Refund düğmesiyle tamamen iade ettiğiniz sıradan bir tezgâh satışı da Refunded durumunda biter; kısmi iade ise durumu olduğu yerde bırakır. “Durum refunded’a eşit” ifadesini “bu, dışarı çıkan paradır” diye okuyan bir rapor, zaten sıfıra inmiş bir netin üstüne o satışın tüm değerini de düşer; böylece £37.80’lik bir satış günü hiç oynatmak yerine eksi £37.80 oynatır. Kendi mutabakat sorgunuzu yazıyorsanız kaçınmanız gereken tuzak budur.

Bu yapının kendi ekranlarımızın dışında da bir sonucu var. WooCommerce’in kendi raporlaması açısından bir tezgâh iadesi, Refunded durumunda pozitif toplam taşıyan ve hiçbir iade kaydı ekli olmayan sıradan bir siparişten ibarettir; çünkü para bir ödeme geçidinden geri değil, tezgâhın üzerinden gitmiştir. O rakamlarda hiç görünüp görünmeyeceği ve hangi işaretle görüneceği, o ekranın hangi durumları saydığına bağlıdır. Netleştirilmiş bir tezgâh rakamı için tezgâhın kendi kontrol panelini okuyun.

WooCommerce’in kendi Analytics ekranlarında, brüt satış mı yoksa net satış mı okuduğunuza bakın. Bunlar farklı sütunlardır: net satış, brüt satıştan iadeler ve kuponlar düşülmüş halidir, yani aradaki fark yalnızca iadelerden ibaret değildir. Brüt satış ayrıca vergiyi ve kargoyu da dışarıda bırakır; sayılmış bir çekmeceyle asla tutmayacak olmasının ikinci sebebi budur.

İkinci neden: “bu ay” ile “son 30 gün” farklı sorulardır#

İnsanlar bunları eşanlamlı sanıyor, değiller. Ayın 20’sinde “bu ay” 20 günü, “son 30 gün” ise önceki aydan on gün dahil olmak üzere 30 günü kapsar. Ayın 3’ünde ise neredeyse her şeyde ayrışırlar. İki rakam geniş bir farkla çelişebilir ve ikisi de tastamam doğru olabilir.

Kayan pencere, “işler yolunda mı” sorusunun doğru halidir; her zaman aynı uzunlukta bir süreyi kapsar ve ayın 1’inde sıçramaz. Takvim ayı ise “ne borçluyum, ne beyan edeceğim” sorusunun doğru halidir; muhasebeciniz, KDV beyannameniz ve kiranız kayan pencerelerle çalışmaz. İkisi de meşru olduğu için kontrol panelimiz birini seçmek yerine ikisini birden gösterir: kayan bir Son 30 gün kartı ve ayın başından bugüne takvim ayı için ayrı bir Bu ay kartı. Birini, diğer yöntemle hesaplanmış bir rakamla karşılaştırırsanız var olmayan bir farkın peşine düşersiniz.

Hesabı kendiniz kontrol ediyorsanız bilmeye değer bir uygulama ayrıntısı: Son 7 gün, bugün artı önceki altı gün demektir; Son 30 gün ise bugün artı önceki 29 gün. Yani içinde durduğunuz gün dahil yedi ve otuz takvim günü, her biri 7 × 24 saat öncesindeki aynı saat başı yerine gece yarısında başlar. 30 gün öncesinin öğleden sonrasında başlayan bir pencere, gece yarısında başlayan bir pencereyle tutmaz ve tek başına bu, küçük uyuşmazlıkların çoğunu açıklar.

Üçüncü neden: gün sınırı sunucunuza değil, dükkânınıza aittir#

En çıldırtıcı belirtiyi bu üretir: neredeyse doğru olan, bir iki işlem sapan ve yalnızca geç saatte birine hizmet ettiğiniz günlerde bozulan toplamlar.

“Gün”, iki gece yarısı arasındaki aralıktır ve gece yarısı yerel bir kavramdır. Bir rapor sınırlarını UTC’ye göre hesaplarken dükkânınız İstanbul’da, Lizbon’da ya da Chicago’daysa, sizin yerel gece yarınızla sunucununki arasında kesilen her satış yanlış güne düşer. Hiçbir şey kaybolmaz; para aylık rakamın içinde durur. Ama salı eksik, çarşamba fazla çıkar ve bunu günlük mutabakat yapan personel sizden önce bulur.

Kendi mağazanızda kontrol edilecek üç şey:

• WordPress Settings → General → Timezone. Ham bir UTC farkı değil, bir şehir seçin. Şehir yaz saatini bilir, sabit fark bilmez. “UTC+1” olarak ayarlanmış bir mağaza, yerel saatler kayarken olduğu yerde kalır; yani yılın ikisinin ayrıştığı bölümünde her gün sınırı, personelinizin çalıştığı sınırdan bir saat uzaktadır.
• Raporun hangi tarih alanına göre grupladığı. Bir siparişin oluşturulma tarihi vardır; ödenme ve tamamlanma tarihi de olabilir. İki ekran farklı alanlara göre gruplarsa, 23:50’de oluşturulup 00:10’da tamamlanan bir sipariş her birinde ayrı bir güne düşer. Tezgâhta bunlar genellikle aynı andır, dolayısıyla bu en çok siparişler sonradan düzenlendiğinde ısırır.
• Kendi alışkanlığınız. Kasayı akşam 6’da kapatıyor ama dükkânı 8’e kadar açık tutuyorsanız, sizin “gün”ünüzle raporun günü basitçe farklı pencerelerdir. Bu bir yazılım sorunu değildir, ama bir mutabakat sorunudur.

Tezgâh kontrol paneli her sınırı WordPress site saat dilimine göre hesaplar ve “bugün”ü siparişin kendi yerel tarihine karşı ikinci kez doğrular; böylece bir yaz saati kayması bir satışı sessizce günün içine çekemez ya da dışına atamaz. Bu, saat dilimi ayarı yanlış olan bir mağazayı düzeltmez — hiçbir şey düzeltemez — ama doğru yapmanız gereken tek şeyin o ayar olduğu anlamına gelir.

Dördüncü neden: hangi sipariş durumları para sayılır#

Her rapor durumlar konusunda bir karar verir ve farklı raporlar farklı kararlar verir. Bizim kontrol panelimizde kural açıktır: Completed, Processing ve On hold bir POS satışı sayılır. Pending, Cancelled ve Failed asla sayılmaz. Refunded siparişler yüklenir — yüklenmek zorundadır, yoksa iadeler görünmez olurdu — ama durumlarına göre değil, yukarıda anlatılan iade işaretine göre sınıflandırılır.

İki pratik sonucu var:

• Bir tezgâh satışının hangi durumla kaydedileceği bir ayardır ve seçenekler yine aynı üçüdür: Completed, Processing ya da On hold. Çoğu dükkân Completed ister, çünkü müşteri ödemiş ve ürünü alıp çıkmıştır. Sizinki başka bir şeye ayarlıysa, mutabakat yaptığınız diğer şey neyse onun da o durumu saydığından emin olun.
• WooCommerce’in kendi Analytics ekranının bir dışlanan durumlar ayarı vardır; varsayılan olarak Pending payment, Cancelled ve Failed durumlarını dışlar. Etkin olarak kullandığınız bir durum o dışlama listesindeyse, o siparişlerin tamamı sipariş listenizde apaçık dururken Analytics’te eksik olur. Siparişlerin kaybolduğu sonucuna varmadan önce bunu kontrol edin.

Adını koymaya değer ilgili bir durum daha: en baştan rakamlara düzgün girmemiş siparişler, çünkü elle oluşturulmuş ve bir şey atlanmıştır. Bunlar aynı anda her raporda bir eksiklik olarak görünür ki bu işe yarar bir imzadır: bütün ekranlarda beliren bir açık genellikle bir raporlama değil, bir sipariş sorunudur. Bu arıza biçimi elle açılan siparişler yazısında ele alınıyor.

Beşinci neden: tezgâh hasılatı ile web sitesi siparişleri aynı kovada#

Hem çevrimiçi hem yüz yüze satıyorsanız, tek bir “bugünkü satış” rakamı kasa kapanışı için neredeyse işe yaramaz. Fiziksel olarak tezgâhınızdan geçen parayla bir ödeme geçidi üzerinden kapanan parayı karıştırır ve ikinci yarıyı eşleştirebileceğiniz hiçbir şey çekmecede yoktur.

Eklentimiz üzerinden yapılan tezgâh satışlarının hepsi aynı ödeme yöntemi tanımlayıcısıyla ve kendilerine ait bir işaretle yazılır; ayrılabilir olmalarını sağlayan budur. Kontrol paneli yalnızca tezgâh siparişleriyle sınırlıdır; web sitesi siparişleri içinde yer almaz. POS sipariş listesi de aynı şekilde sınırlıdır, yani web sitenizden hiçbir şey orada görünmez; üstüne tür, durum ve tarih aralığı filtreleri ekler, böylece bir haftanın yalnızca iadelerini ya da bir günün yalnızca satışlarını çekebilirsiniz.

Simetri iki yönlü çalışır: kontrol paneli yalnızca tezgâh hasılatını gösterdiği için bütün işletmenin raporu değildir. “Kasa ne aldı” sorusunu cevaplar; “işletme ne aldı” sorusu için hâlâ her iki kanalı kapsayan WooCommerce Analytics’e ihtiyacınız var.

Tezgâh kontrol panelini okumak: bilerek seçilmiş dört pencere#

Bir raporun gerçek değil bir soru olduğunu kabul ettiğinizde, dört farklı pencereli bir kontrol paneli kafa karıştırıcı olmaktan çıkıp işe yarar hale gelir. Bizimkindeki her kartın gerçekte neyi ölçtüğü şöyle.

Her rakam ne anlama geliyor#

• Bugün — yerel gece yarısından bu yana yapılan tezgâh satışları; iadelerden ve o satışlara karşı kesilen iadelerden arındırılmış. Alt etiket yalnızca satışları sayar, yani üç satış ve bir iadenin olduğu bir gün üç olarak okunur.
• Son 7 gün ve Son 30 gün — bugünü de içeren kayan pencereler, aynı şekilde netleştirilmiş. Eğilim için işe yarar, muhasebe için değil.
• Bu ay — ayın başından bugüne takvim ayı. Muhasebecinize verilecek olan budur.
• Ortalama sepet — son 30 gündeki satış değerinin satış sayısına bölümü. Kendi başına duran kör iadeler her iki taraftan da bilerek dışarıda bırakılır, çünkü onları hesaba katmak gerçek hiçbir müşterinin harcamadığı kadar düşük bir rakam üretir; bir satışa karşı kesilen iade ise değer tarafından yine düşülür.
• Günlük ciro, ödeme dağılımı ve en çok satanlar — günlük grafik gün başına net hasılatı çizer. Ödeme halkası hasılatı ödeme türüne göre böler; nakit iade, nakit dilimine eklenmek yerine onu küçültür. En çok satanlar yalnızca satış siparişlerindeki adetleri sayar, yani bir kör iade hiç satmamış bir ürünü listenin tepesine asla itemez — ama bir satışa karşı iade edilen adetler sıralamadan düşülmez.

Bilerek göstermedikleri#

Sınırlar konusunda açık olmak size sonuçsuz bir aramayı kazandırır:

• Dört pencere sabittir. Kontrol panelinde hiç tarih seçici yoktur. Serbest bir aralık için POS sipariş listesindeki başlangıç-bitiş filtrelerini kullanın; ama dikkat, o listenin alt satırındaki toplam tüm filtrelenmiş kümeyi değil, baktığınız sayfadaki satırları toplar.
• Kontrol panelinde dışa aktarma ya da indirme yoktur.
• Ücretsiz sürümün hiçbir yerinde kâr ya da marj rakamı yoktur. Satış ekranındaki hızlı düzenleme kutusundan bir ürüne birim maliyet kaydedilebilir, ama ücretsiz sürümde hiçbir şey bunu marja çevirmez. Kâr raporları bir Pro özelliğidir.
• Ücretsiz sürümde kasa çekmecesi sayımı, beklenen-sayılan karşılaştırması ve X ya da Z kapanışı yoktur. O da Pro.

Dokümantasyon her ekranın neyi kapsadığını daha ayrıntılı listeler; ürün sayfası da her özelliğin çizginin hangi tarafında durduğu konusunda açıktır.

Personel hâlâ oradayken hatayı yakalayan gün sonu alışkanlığı#

Mutabakat, ayın sonunda değil aynı gün yapıldığında çok daha ucuzdur; hiç de göz alıcı olmayan tek bir sebeple: hatayı yapan kişi hâlâ binadadır ve müşteriyi hâlâ hatırlıyordur.

Gerçekten işe yarayan beş dakikalık bir kapanış:

• Önce nakdi sayın, hiçbir ekrana bakmadan. Beklenen rakamı önce okursanız, ona doğru sayarsınız. Bu bir karakter zaafı değil, saymanın işleyişi böyledir.
• Kart terminalinin kendi kapanış toplamını okuyun. Eklentininkini değil, WooCommerce’inkini de değil; terminalinkini.
• POS sipariş listesini açın, bugüne filtreleyin ve satırları okuyun. Yirmi otuz satır bir denetim değil, bir göz gezdirmedir. Yanlış bir adet, mükerrer bir satış ya da satış olarak kaydedilmiş bir iade, kalemlerin ve toplamların olduğu bir listede bir bakışta görünür.
• Bugün rakamıyla karşılaştırın, sonra sipariş listesinde ödeme türüne göre ayırın. Bugün kartı tek bir net sayıdır ve kontrol panelindeki ödeme dağılımı tek bir günü değil tüm kayan pencereyi kapsar; dolayısıyla bugünün ödeme türü kırılımı, bugünkü satırlardaki Ödeme sütunundan gelir. Nakit sapıyor ama kart tutuyorsa sorun çekmecededir. İkisi de aynı tutarda sapıyorsa sorun bir siparişte.
• Farkı küçük olsa bile yazın. Tekrar eden 20 penilik bir fark yuvarlamadır. Tekrar eden £5 birinin edindiği bir alışkanlıktır. Bir haftalık not olmadan hangisi olduğunu ayırt edemezsiniz. Küçük farklar istikrarlı biçimde birkaç peni düzeyindeyse ve hep indirimli sepetlerde çıkıyorsa, sebep tezgâhtaki herhangi bir şey değil indirimin nasıl hesaplandığı olabilir; bkz. vergi dahil fiyatlarda indirimler neden yanlış çıkar.

Kapanışta yüzeye çıkan bir şey daha: satışın hangi yöntemle kapatıldığı. Müşteri bir kısmını nakit, bir kısmını kartla ödediyse bunun bir yere kaydedilmesi gerekir, yoksa iki ödeme türü toplamınız asla birlikte doğru olmaz. Ücretsiz sürümde bir satış tam olarak tek bir ödeme yöntemiyle kapatılır, dolayısıyla karma ödemenin başka bir yolla ele alınması gerekir; seçenekler ve her birinin mutabakat sırasında size neye mal olduğu tek satışta nakit ve kart nasıl alınır yazısında anlatılıyor.

Bir kontrol panelinin söyleyemedikleri ve çekmeceyi saymanın hâlâ ne işe yaradığı#

Bir rapor ekranı neyin kaydedildiğini bilir. Ne olduğunu bilemez. Yukarıdaki beş neden elendikten sonra kalan farkın çoğunu bu ayrım açıklar.

Bir kontrol paneli, kahve parası için çekmeceden beşlik alan bir çalışanı, kaydedilmeden verilen bir ürünü, yanlış banknottan verilen para üstünü ya da terminalden geçirilip hiç sipariş olarak kaydedilmemiş bir kart ödemesini göremez. Bunların hiçbiri sipariş kayıtlarınızda iz bırakmaz; fiziksel sayımın gereksiz olmamasının sebebi tam olarak budur. Sayım, elinizdeki tek bağımsız ölçümdür. Geri kalan her şey aynı verinin farklı toplanmış halidir.

Bizimki dahil tarayıcı tabanlı her kasanın sınırları konusunda da açık olmakta fayda var: çevrimdışı kip yoktur. Bağlantı vardiyanın ortasında koparsa satışlar kaydedilemez ve bu arada kâğıt üzerinde aldığınız hasılatın sonradan girilmesi gerekir; yani siz girene kadar o günün toplamları çekmecenizle çelişir. Tarayıcı tabanlı bir tezgâhın yapamadıklarının tam listesi, kimse yoğun bir cumartesi günü keşfetmek zorunda kalmasın diye bilerek WooCommerce ve satış noktası üzerine ana yazıda ortaya konuyor.

Kısa bir mutabakat kontrol listesi#

Sıkça sorulan sorular#

WooCommerce satış toplamlarım gerçek hasılatımla neden tutmuyor?#

Kabaca şu olasılık sırasıyla: okuduğunuz rakamdan iadeler ve kısmi iadeler netleştirilmiyordur; iki rakam farklı tarih pencerelerini kapsıyordur; gün sınırı yanlış saat diliminde hesaplanıyordur; kullandığınız bir durum rapordan dışlanmıştır; ya da web sitesi siparişleri tezgâh hasılatının yanında sayılıyordur. Bir şeyin bozuk olduğunu varsaymadan önce bu beşini eleyin; çoğu zaman iki ekran, iki farklı soruyu doğru cevaplıyordur. Önce kontrol edilmeye değer, gerçekten mekanik olan tek neden Analytics içe aktarma kuyruğudur; çünkü Analytics siparişlerinizi değil kendi arama tablolarını okur.

İadeler WooCommerce raporlarında görünen toplamları düşürür mü?#

Tamamen hangi rakamı okuduğunuza bağlı. WooCommerce Analytics brüt satışı ve net satışı ayrı sütunlar olarak raporlar; net satış, brüt satıştan iadeler ve kuponlar düşülmüş halidir, yani iadeler farkın yalnızca bir kısmıdır ve üstüne brüt satış vergiyi ve kargoyu da dışarıda bırakır. Brüt satışı sayılmış bir çekmeceyle mutabık kılmaya çalışmak tutmaz. Bizim tezgâh kontrol panelimiz tek bir rakam gösterir ve o rakam her zaman nettir: bir satışa karşı kesilen iadeler de bütün iadeler de düşülür. Sinsi olan kısmi iadedir, çünkü kestiğinizde asıl siparişin toplamı değişmez.

“Son 30 gün” ile “bu ay” aynı şey mi?#

Hayır ve nadiren birbirlerine yakın olurlar. “Son 30 gün”, her zaman aynı uzunlukta bir süreyi kapsayan ve genellikle önceki aya uzanan kayan bir penceredir. “Bu ay” ise ayın başından bugüne takvim ayıdır; yani ayın 3’ünde üç günü kapsar. Ticaretin yolunda gidip gitmediğine karar vermek için kayan rakamı, beyan etmek zorunda olduğunuz her şey için takvim rakamını kullanın. Kontrol panelimiz hangisinin hangisi olduğunu kimse hatırlamak zorunda kalmasın diye ikisini yan yana gösteriyor.

Günlük toplamlarım neden birkaç saat kayıyor?#

Çünkü gün, iki yerel gece yarısı arasındaki aralıktır ve zincirdeki bir şey farklı bir gece yarısı kullanıyordur. WordPress’i sabit bir UTC farkı yerine adlandırılmış bir şehre ayarlayın — şehir yaz saatini bilir, fark bilmez — ve karşılaştırdığınız ekranların siparişleri aynı tarih alanına göre gruplayıp gruplamadığını kontrol edin. Yeri değişenler, akşam geç saatte kesilen satışlardır.

Hangi sipariş durumları satış sayılır?#

Bizim tezgâh kontrol panelimizde Completed, Processing ve On hold. Pending, Cancelled ve Failed asla sayılmaz. Refunded siparişler iadelerin görülebilmesi için yüklenir, ama iade olduklarını durumları değil kendi işaretleri belirler; bu önemlidir, çünkü sonradan tamamen iade ettiğiniz sıradan bir satış da Refunded durumunda biter ve durumu iade kanıtı saymak o satışı iki kez düşerdi. WooCommerce’in kendi Analytics ekranının da kendi dışlanan durumlar ayarı vardır; durumları gerçekte nasıl kullandığınızla örtüştüğünü kontrol edin.

Mağaza içi satışları web sitesi satışlarından ayrı nasıl görürüm?#

Eklenti üzerinden yapılan tezgâh satışlarının hepsi aynı ödeme yöntemi tanımlayıcısıyla yazılır; onları ödeme sayfası siparişlerinden ayrılabilir kılan budur. POS sipariş listesi yalnızca tezgâh siparişlerini gösterir; tür, durum ve tarih aralığı filtreleri vardır ve kontrol paneli de aynı şekilde sınırlıdır, yani hasılat rakamı yalnızca tezgâh parasıdır. Bunun bedeli, kontrol panelinin bütün işletmenin raporu olmamasıdır; iki kanalı birleştiren rakamlar için hâlâ WooCommerce Analytics’e ihtiyacınız var. Hiçbir şeye bağlanmadan önce tezgâh tarafının nasıl çalıştığını görmek isterseniz, Retail POS WordPress.org üzerinde ücretsizdir; dokümantasyon da kontrol paneli, sipariş listesi ve iade terminalini ayrıntılı olarak anlatır — ücretsiz sürüm bir deneme değil, eksiksiz tek kasalı bir tezgâhtır.