Çoğu kişi Google Sheets'i geçici bir çözüm sanır; "düzgün sistem kurulunca bırakırım" der ve üç yıl sonra hâlâ aynı tabloyu kullanıyordur. Sebep basit: tablo, sektördeki en yaygın ortak dildir. Tedarikçin sana tablo gönderir, muhasebecin tablo ister, bayin tabloyla teklif verir. Bu gerçeği yok saymak yerine, tabloyu sistemin düşmanı olmaktan çıkarıp kontrollü bir giriş kapısına dönüştürmek çok daha akıllıca.
Ama burada sinsi bir tuzak var. Tablo ile panelin arasına kurulan gevşek bir bağ, iki tarafın da doğruyu bildiğini sandığı bir kaos yaratır: sen panelden stok düşersin, tedarikçi tablodan satır siler, senkronizasyon ikisini birleştirir ve aynı kodu iki müşteriye satarsın. Senkronizasyonun kuralı tektir: her veri parçasının tek bir sahibi olmalı. Bu yazı, o sahipliği nasıl kuracağını anlatıyor.
Tek Yön mü Çift Yön mü? Yanlış Cevap Seni Çift Satışa Götürür
Çift yönlü senkronizasyon kulağa gelişmiş gelir, pratikte ise sürekli çakışma üretir. Doğru yaklaşım, alan bazında yön belirlemektir. Örneğin ürün fiyatı ve stok kodu tedarikçi tablosundan panele akabilir; ama satış adedi, teslim edilmiş kod ve bakiye yalnızca panelden tabloya gider. Bu ayrımı yaptığın an çakışma kavramı ortadan kalkar, çünkü hiçbir alan iki yerden birden değişmez. Bir dijital ürün satış scripti kurulumunda ilk oturumda çizilmesi gereken şema tam olarak budur: hangi sütun kimin sözü.
Google Sheets'e Bağlanmanın Kaç Yolu Var?
Üç pratik yol var ve üçü farklı işletme ölçeğine uyuyor. En basiti, tabloyu bağlantıyla yayımlayıp CSV çıktısını okumaktır; kurulumu beş dakikadır ama sadece okuma yapar ve tabloyu herkese açık hale getirir. İkincisi, Google tarafında bir servis hesabı oluşturup tabloyu o hesapla paylaşmaktır; hem okuma hem yazma yapar, tablo gizli kalır ve profesyonel kurulumun standardı budur. Üçüncüsü ise tablo tarafına küçük bir betik yazıp değişiklik olduğunda panele haber vermektir; en hızlısıdır ama bakımı en zor olanıdır.
| Yöntem | Yön | Gecikme | Güvenlik | Kime Uygun |
|---|---|---|---|---|
| Yayımlanmış CSV bağlantısı | Sadece okuma | 5-15 dk | Zayıf (herkese açık) | Tek tedarikçi, düşük hacim |
| Servis hesabı + API | Çift (alan bazlı) | 1-5 dk | Güçlü | Standart kurulum |
| Tablo betiği ile bildirim | Tablodan panele | Anlık | Orta | Anlık stok değişimi olanlar |
| Zamanlanmış dışa aktarma | Panelden tabloya | Saatlik | Güçlü | Raporlama amaçlı |
| Manuel içe aktarma | Tek seferlik | - | Yüksek risk | İlk kurulum göçü |
Tedarikçi Tablosunu Neden Doğrudan Stok Yapmamalısın?
Çünkü o tablo senin değil. Tedarikçi bir sütun ekler, başlığı Türkçe karakterle değiştirir, satır sırasını bozar; senin e-pin satış scripti tarafındaki eşleştirme bir anda yanlış ürüne yazmaya başlar. Doğru yöntem, tedarikçi tablosunu doğrudan stok kaynağı yapmak değil, ara bir doğrulama katmanından geçirmektir: gelen satır beklenen sütun yapısına uyuyor mu, ürün kodu sistemde tanımlı mı, fiyat makul aralıkta mı? Uymayan satır içe alınmaz, panelde "onay bekleyen" listesine düşer. Bu tek katman, en sık yaşanan felaketi, yani yanlış fiyatla toplu satışı önler. Pinova'da bu mantık içe aktarma öncesi doğrulama adımı olarak kurgulanır.
Senkronizasyon Arızalarının Kaynakları
- Tablo yapısının elle değiştirilmesi 45%
- Yetki ve paylaşım hataları 25%
- API kota aşımı 20%
- Sayı ve tarih biçimi uyuşmazlığı 10%
Kota Duvarına Çarpmadan Nasıl Çalışırsın?
Google tarafında istek sayısı sınırsız değildir. Her ürün için ayrı satır okuyan bir kurgu, 900 ürünlük bir katalogda dakikalar içinde sınıra dayanır ve senkronizasyon susar. Çözüm, tek tek okumak yerine toplu aralık okuması yapmaktır: tüm sayfayı tek istekte al, karşılaştırmayı kendi tarafında yap, sadece değişen satırları geri yaz. Aynı şekilde yazma tarafında da satır satır değil, toplu güncelleme kullan. Bu iki değişiklik, istek sayısını yüzde doksanın üzerinde düşürür ve senkronizasyonu gerçekten dayanıklı hale getirir. Doğru kurgulanmış bir e-pin yazılımı bu optimizasyonu sen istemeden yapar; kurulum öncesi mutlaka sor.
Tabloyu Rapor Ekranı Gibi Kullanmak Mantıklı mı?
Kesinlikle. En değerli kullanım senaryolarından biri bu. Panelden tabloya tek yönlü akan bir satış özeti sayfası, muhasebecinin, iş ortağının ve hatta bayinin sana hiç sormadan veriye ulaşmasını sağlar. Günlük ciro, ürün bazlı satış adedi, kritik stok seviyesine düşen ürünler; hepsi her sabah otomatik olarak tabloya yazılır. Kimse panele girmek zorunda kalmaz, kimse senden ekran görüntüsü istemez. Bu, dijital ürün satış yazılımının en az konuşulan ama en çok zaman kazandıran kullanım biçimidir. Nasıl yapılandırıldığını özellikler bölümünde, paketlere göre farklarını fiyat sayfasında görebilirsin.
Kuruluma Başlamadan Önce Ne Hazırlaman Gerekiyor?
Senkronizasyonun başarısı büyük ölçüde kurulum öncesi disipline bağlı. Aşağıdaki listeyi tamamlamadan bağlantıyı açma; açarsan ilk hafta içinde manuel düzeltmeye geri dönersin.
| Hazırlık Adımı | Amaç | Durum |
|---|---|---|
| Her sütun için sahip tarafı belirlendi mi | Çakışmayı kökten önlemek | Zorunlu |
| Sütun başlıkları sabitlendi ve kilitlendi mi | Yapı bozulmasını engellemek | Zorunlu |
| Servis hesabı oluşturulup tablo paylaşıldı mı | Güvenli erişim | Zorunlu |
| Ürün kodları panel ile birebir eşleşiyor mu | Yanlış ürüne yazmayı önlemek | Zorunlu |
| Fiyat için makul aralık sınırı tanımlandı mı | Hatalı toplu fiyat koruması | Yüksek |
| İçe aktarma öncesi onay adımı açık mı | Şüpheli satırı karantinaya almak | Yüksek |
| Senkronizasyon sıklığı belirlendi mi | Kota yönetimi | Orta |
| Hata durumunda bildirim tanımlı mı | Sessiz duruşu fark etmek | Orta |
Tedarikçinin yazacağı alanı ayrı bir sayfada tut ve senkronizasyonun okuduğu sayfayı formüllerle beslenen salt okunur bir ayna yap. Tedarikçi ne yaparsa yapsın, aynanın sütun düzeni bozulmaz; hatalı satır aynaya boş düşer ve sistem onu içe almaz.
Kopyala-yapıştır dönemini bugün kapat
Pinova, tedarikçi tablonu doğrulama katmanından geçirip stoğa bağlayan, satış özetini her sabah tabloya yazan bir e-pin satış yazılımıdır.
Tablodaki stok bittiğinde panelde satış otomatik kapanır mı?
Stok alanının sahibi tablo olarak tanımlandıysa evet; senkronizasyon adedi sıfıra çektiğinde ürün satışa kapatılır. Bu davranışın kurulumda açıkça seçilmesi gerekir.
Aynı tabloyu birden fazla kişi düzenlerse sorun olur mu?
Sütun sahipliği net tanımlıysa olmaz. Sorun, aynı sütunu hem panelin hem insanın değiştirdiği durumlarda çıkar; bu yüzden yazma yetkisi olan alanlar ayrı sayfada tutulmalıdır.
Senkronizasyon ne sıklıkla çalışmalı?
Çoğu işletme için beş dakika ideal aralıktır. Anlık stok değişimi kritikse tablo tarafından bildirim gönderen bir kurgu eklenebilir, ama tek başına dakikalık tarama gereksiz yük yaratır.
Bağlantı koparsa satışlarım etkilenir mi?
Hayır. Panel kendi stok kaydıyla çalışmaya devam eder; senkronizasyon geri geldiğinde son durum karşılaştırılır ve fark varsa onay bekleyen listesine düşer.
Tablo senin işini yavaşlatan bir alışkanlık olmak zorunda değil; doğru kurulduğunda sistemin en esnek uzantısı olur. Sahiplik şemasının, doğrulama katmanının ve otomatik rapor sayfasının gerçekte nasıl çalıştığını görmek istersen canlı demo içinde örnek bir tedarikçi tablosu bağlayıp stok akışını baştan sona izleyebilirsin.

