Kaynak: https://oguzerol.com/google-sheets-cift-yonlu-senkronizasyon/ [ Görseli büyüt](https://oguzerol.com/gorseller/hizmet-kapaklari/google-sheets-cift-yonlu-senkronizasyon-webapp-v1-tr.webp) # Google Sheets Çift Yönlü Senkronizasyon: Çakışma, Silinen Satır ve Gecikme Kuralları [Oğuz Erol](https://oguzerol.com/hakkimda/) | 17 dk okuma Google E-Tablolar ile bir uygulama ya da ERP arasındaki çift yönlü eşitleme, iki koşulda güvenle çalışır: her alanın tek bir sahibi vardır ve kayıtlar satır numarasıyla değil, değişmeyen bir kayıt anahtarıyla eşleşir. Bu ikisi yoksa “son yazan kazanır” kuralı sessizce veri kaybettirir, silinen satırı silme talimatı sayan eşitleme açık siparişi kapatabilir. Bu bağlantıyı şirketinize özel bir web uygulamasının parçası olarak kuruyorum. Kurgusal bir dağıtım şirketinin örnek ayında 6 satış temsilcisi açık siparişleri E-Tablolar’da, sevkiyat planlama ekibi aynı siparişleri uygulamada takip ediyor. 14. iş günü bir temsilci “kapanmışları temizlemek” için 23 satırı siliyor, 6’sı henüz bitmemiş kısmi sevk. Önceki ayın betiği bu silmeyi uygulamaya iptal diye taşırdı. Yeni eşitleme hiçbir şeyi silmiyor, durup satış müdürüne soruyor. Birden çok kişinin aynı tabloya aynı anda yazmasını [eşzamanlı veri girişi sayfasında](https://oguzerol.com/eszamanli-veri-giris-uygulamasi/) ayrıca anlattım. Bu sayfa iki sistemin aynı kaydı tutmasını anlatıyor. ## Çift yönlü eşitleme nasıl çalışır? Çift yönlü eşitleme, iki sistemdeki aynı kaydın değişikliklerini belirli aralıklarla karşılaştırıp her alanı yalnız sahibinin değerine göre güncelleyen bir döngüdür. Sayfada altı kavramı hep aynı adla kullanıyorum: - **Kayıt anahtarı:** bir kaydı iki tarafta tanımlayan, hiç değişmeyen değer, örnekte sipariş numarası. Satır numarası ya da müşteri adı anahtar olmaz, sıralama ve ad değişikliğiyle kayar. - **Alan sahibi:** bir alanın doğru değerinin hangi sistemde durduğu. Sahibi uygulama olan alan E-Tablolar’dan değiştirilemez, tersi de geçerli. - **Son eşitlenen değer:** uygulamanın her alan için sakladığı, iki tarafın en son uzlaştığı değer. Değişikliğin hangi tarafta olduğunu bununla anlarım. - **Çakışma:** son eşitlenen değerden sonra aynı alanın iki tarafta da farklı değiştirilmesi. - **Hata kuyruğu:** işlenemeyen değişikliklerin listesi (okunamayan tarih, sahibi olmayan sütun, tanınmayan başlık). Kuyruktaki değişiklik ne uygulanır ne silinir, bekler. - **Kontrol sayısı:** iki tarafta saatte bir sayılan açık kayıt adedi ve açık miktar toplamı. İkisi tutmuyorsa bir yerde kayıp var demektir. Her döngüde uygulama sekmeyi tek istekle okur, hücreleri son eşitlenen değerle karşılaştırır, E-Tablolar’a ait değişiklikleri alır, kendine ait değişiklikleri tek toplu yazmayla gönderir. Çakışma ve hatalar kuyruğa, döngü özeti iz kaydına düşer. ## Örnek ay: 418 açık sipariş, 6 temsilci, iki sistem *Örnek veri, kurgusaldır.* Endüstriyel bağlantı elemanı ve hidrolik yedek parça satan bir dağıtım şirketi düşünün. Altı satış temsilcisi ve bir satış asistanı “Açık siparişler” sekmesinde termin, öncelik ve not giriyor. Siparişler sevkiyat uygulamasında açılıyor, iki planlamacı sevk tarihini, depo durumu orada güncelliyor. Ay 20 iş günü. Ay başında 418 açık sipariş var, ay içinde 655 yeni sipariş açılıyor, 690’ı sevk edilip “Kapananlar” sekmesine taşınıyor. Ay sonunda 383 açık satır kalıyor. **Önceki ay** iki taraf, bir çalışanın yazdığı betikle bağlıydı. Betik her 10 dakikada sekmenin tamamını iki yöne kopyalıyor, satırları satır numarasıyla eşleştiriyor ve hangi kopya sonra işlenirse onu doğru sayıyordu. Ay sonunda satış operasyon uzmanının bulduğu sorunlar: | bulunan sorun | adet | | --- | --- | | Sekme müşteriye göre sıralandıktan sonra başka siparişin satırına yazılan sevk tarihi | 14 | | Uygulamadan gelen eski kopyayla ezilen temsilci termini ya da notu | 9 | | Baştaki sıfırı düşen ürün kodu (0815 → 815), sonra uygulamaya geri yazılan | 31 | | E-Tablolar’da silinen satır yüzünden uygulamada kapanan açık sipariş (müşteri arayınca fark edildi) | 2 | **Bu ay** eşitleme uygulamanın içinde çalıştı: kayıt anahtarı sipariş numarası, her sütunun bir sahibi var, döngü iş günlerinde 07.00 ile 19.00 arasında 5 dakikada bir. | ölçüm | adet | | --- | --- | | E-Tablolar’dan uygulamaya işlenen alan değişikliği | 1.962 | | Uygulamadan E-Tablolar’a işlenen alan değişikliği | 4.215 | | Sahibi uygulama olan sütuna yazıldığı için reddedilen değişiklik | 12 | | Öncelik alanında çakışma | 7 | | Tarih olarak okunamayan müşteri termini (hata kuyruğu) | 19 | | Başlık değiştiği için duran döngü | 26 | Ayın akışında olanlar: - **Reddedilen 12 değişiklik.** Sevk tarihi sütunu “uyarı göster” kipinde korumalıydı. Bu kip düzenlemeyi engellemiyor, yalnız onay istiyor ([Google E-Tablolar Yardım](https://support.google.com/docs/answer/1218656), 16 Ekim 2026). 12 kez biri uyarıyı onaylayıp müşteriden duyduğu tarihi oraya yazdı. Eşitleme planlamacının tarihini geri yazdı, değişikliği hata kuyruğuna koydu. - **7 çakışma.** Öncelik iki yönlü tek alandı. Yedi kez aynı döngüde hem temsilci hem planlamacı değiştirdi. Hiçbiri diğerini ezmedi, planlama şefi altısını aynı gün, birini ertesi sabah çözdü. - **19 okunamayan termin.** Temsilciler tarih yerine “ay sonu”, “haftaya salı” yazmıştı. Bu hücreler uygulamaya hiç geçmedi. - **9. iş günü başlık değişti.** Satış asistanı “Müşteri termini” başlığını “Termin (müşteri)” yaptı. Eşitleme beklediği başlığı bulamayınca döngüyü tamamen durdurdu, 2 saat 10 dakika (26 döngü) hiçbir şey yazılmadı. Başlık düzeltilince ilk döngü aradaki değişiklikleri son eşitlenen değerle karşılaştırıp aldı, kayıp olmadı. Sütunları sırasıyla eşleyen önceki betik böyle bir günde değerleri yanlış sütuna yazıyordu. Kural bu yüzden şöyle: beklenen başlıklardan biri yoksa döngü tamamen durur, hiçbir zaman kısmen çalışmaz. ### Ay sonunda çıkan karar 1. iş günü tek döngüde 23 satır kayboldu. Saat başı kontrol sayısı da aynı farkı gösterdi: uygulamada 401 açık sipariş, sekmede 378 satır. Temsilci durum sütununu “sevk” içerenlere göre süzmüş, “Kısmi sevk” satırları da listeye girmişti. 17’si tamamen sevk edilmişti, birkaç gün içinde zaten Kapananlar’a taşınacaktı. 6’sının kalan miktarları henüz gönderilmemişti. Toplu kayıp eşiği aşıldığı için eşitleme hiçbir siparişi kapatmadı, satırları da geri yazmadı, satış müdürüne uyarı gönderdi. Eşik o gün 5 satırdı (aşağıda nasıl hesaplandığı var). Örnek ayda eşik yalnız bu kez tetiklendi. Müdürün kararıyla 6 kısmi sevkin satırları geri yazıldı, 17 sipariş doğrudan Kapananlar’a alındı. Asıl karar temsilcinin neden sildiğine bakınca çıktı: sekme kalabalıktı. Önerdiğim kural: tamamen sevk edilen sipariş 2 iş günü sonra Kapananlar’a taşınır (önceden 7), kısmi sevk ayrı renkle görünür ve son kalem gidene kadar açık kalır. E-Tablolar’dan satır silmek uygulamada hiçbir şeyi silmez. ## Hangi alan kimin? Alan sahipliği tablosu Alan sahipliği tablosu, her sütunun doğru değerinin hangi sistemde durduğunu ve öbür tarafta değiştirilirse ne olacağını yazar. Örneğin tablosu: | sütun | sahibi | E-Tablolar’da değiştirilirse | | --- | --- | --- | | Sipariş no (kayıt anahtarı) | Uygulama | Korumalı. Değişirse reddedilir, eski değer geri yazılır | | Müşteri, ürün kodu, miktar | Uygulama | Korumalı. Reddedilir | | Müşteri termini | E-Tablolar | Uygulamaya geçer. Tarih değilse hata kuyruğuna düşer | | Planlanan sevk tarihi, sevk durumu | Uygulama | Korumalı. Reddedilir | | Öncelik | İki yönlü | Çakışma kuralı uygulanır | | Temsilci notu | E-Tablolar | Uygulamaya geçer | | Son eşitleme zamanı | Uygulama | Korumalı. Her döngüde yazılır | Yeni sipariş yalnız uygulamada açılır. Sekmeye elle eklenen, kayıt anahtarı olmayan satır uygulamada kayıt açmaz, hata kuyruğuna düşer. İki yönlü alanı olabildiğince az tutmanızı öneririm. Örnekte yalnız öncelik iki yönlü, çünkü onu hem müşteriyi duyan temsilci hem hattı gören planlamacı değiştirmek zorunda. Her iki yönlü alan, bir çakışma kuralı ve onu çözecek bir kişi demektir. Google, korumalı aralığın güvenlik önlemi olarak kullanılmaması gerektiğini de yazıyor ([Google E-Tablolar Yardım](https://support.google.com/docs/answer/1218656)). Koruma yanlışlıkla yazmayı azaltır, asıl güvence eşitlemenin sahibi olmayan taraftan gelen değeri hiç almamasıdır. ## Çakışmada hangi taraf kazanır? Çakışmada hiçbir taraf otomatik kazanmaz: iki yönlü alanda iki değer de saklanır, çözülene kadar yalnız o alan beklemede kalır ve kararı bir kişi verir. Diğer bütün alanlarda çakışma zaten oluşmaz, çünkü sahibi olmayan tarafın değişikliği reddedilir. “Son yazan kazanır” kuralı E-Tablolar’da düşündüğünüzden az şey bilir. Sheets API’nin değer okumasında hücrenin ne zaman ve kim tarafından değiştirildiği gelmiyor, belgelerde böyle bir alan görmedim. Bu benim okumam: pratikte “son yazan” diye uygulanan şey, insanların değiştirdiği sıra değil, eşitlemenin değişikliği gördüğü sıradır. Önceki ayın 9 ezilen notu buradan geldi: temsilci notu yazdı, betik aynı turda uygulamadaki eski kopyayı sonra işledi. Örnekte öncelik üç kademeli: Normal, Yüksek, Acil. Önerdiğim kural: - İki taraf da son eşitlenen değerden sonra değiştirdiyse ve değerler aynıysa çakışma sayılmaz. - Farklıysa yalnız öncelik alanı iki tarafta “beklemede” işaretlenir, kaydın diğer alanları eşitlenmeye devam eder. Öncelik, çakışma çözülene kadar son eşitlenen değerde kalır, iki yeni değer yanında görünür. - “Acil” içeren çakışma planlama şefinin ekranında en üstte durur. Başlangıç önerim 2 saat, aşılırsa satış müdürünün listesine düşer. - Planlama şefi karar verir. Çakışan değişikliklerden biri kendisininse kararı satış müdürü verir. - Kuyrukta 1 iş gününden eski çakışma satış müdürünün listesine düşer. Örnek aydan bir satır: 11. iş günü “Yüksek” bir siparişi temsilci müşterinin hattı duracağı için “Acil” yaptı, aynı döngüde planlamacı malzeme bir gün geç geleceği için “Normal”e çekti. “Uygulama kazanır” kuralı olsaydı sipariş sessizce Normal’e düşerdi. Öncelik beklemede, Yüksek’te kaldı. Planlama şefi bir saat içinde “Acil”i seçip kısmi sevk planladı. Eşitleme bunu bilemezdi. ## Silinen satır ne olur? E-Tablolar’dan silinen satır uygulamada hiçbir kaydı silmez. Bir satırın görünmemesi, kaydın bittiği anlamına gelmez: biri süzüp silmiş, sekmeyi yeniden kurmuş ya da yanlış bir kopyayı yapıştırmış olabilir. Önerdiğim kurallar: - **Kaydı kapatmak sahibinin işidir.** Örnekte sipariş uygulamada “sevk edildi” ya da “iptal” olur, satır sonra eşitlemeyle Kapananlar’a taşınır. - **Tek tük kaybolan satır geri yazılır.** Uygulamada açık olan bir kaydın satırı kaybolursa bir sonraki döngüde geri yazılır, kim sildiğine bakılabilsin diye kayıp listesine girer. - **Toplu kayıpta durulur.** Tek döngüde eşikten fazla satır kaybolursa eşitleme geri yazmayı da durdurur ve uyarı verir. Sebep çoğu zaman yapının kendisidir: silinen sekme, bozulan filtre, üstüne yapıştırılan eski dosya. Başlangıç önerim tek ölçüt: eşik, açık satır sayısının yüzde 1,2’si, yukarı yuvarlanır, en az 5 satır. Örnekte 401 açık satırda 5 eder. Eşitlemenin kendi Kapananlar’a taşıdığı satırlar (örnekte günde yaklaşık 35) kayıp sayılmaz, çünkü taşımayı eşitleme kendisi yapar ve kaydını tutar. Kendi sekmeniz için açık satır sayınızı 0,012 ile çarpıp yukarı yuvarlayın, 5’ten azsa 5 alın: 2.000 satırlık sekmede eşik 24 olur. Oran ilk ayın verisiyle ayarlanır. Kimin sildiğini bulmak beklediğinizden zor. Google’a göre hücre düzenleme geçmişi eklenen ya da silinen satırları ve sütunları, biçim değişikliklerini ve formülle yapılan değişiklikleri göstermeyebilir ([Google Dokümanlar Yardım](https://support.google.com/docs/answer/190843), 16 Ekim 2026). Sürüm geçmişi ise dosyanın eski sürümlerini gösterir. Örnekte satış müdürü iki sürümü karşılaştırıp silmenin hangi sürümde yapıldığını buldu. ## Eşitleme ne sıklıkla çalışır, gecikme ne kadar olur? Örnekteki eşitleme 5 dakikada bir çalışıyor. Değişiklik öbür tarafa en geç 5 dakika artı döngü süresinde, ortalama 2,5 dakikada geçer. İş günlerinde 07.00–19.00 arası günde 144, ayda 2.880 döngü eder. Sevk planı için 5 dakika yeterli. Saniyesinde stok rezervasyonu gerekiyorsa E-Tablolar zaten yanlış yerdir. Neden “değişince hemen” değil de düzenli aralıkla? Üç resmî bilgi bu seçimi belirliyor: - **API değişikliği tetikleyiciyi çalıştırmaz.** Apps Script belgesine göre betik çalıştırmaları ve API istekleri tetikleyicileri çalıştırmaz ([Apps Script, tetikleyiciler](https://developers.google.com/apps-script/guides/triggers)). Yalnız tetikleyiciye güvenen eşitleme, başka bir betiğin ya da sistemin yazdığı değişikliği hiç görmez. - **Drive bildirimi hangi hücrenin değiştiğini söylemez.** Drive’ın anlık bildirimi içerik taşımıyor, dosya için kanal en çok bir gün açık kalıyor ve kendiliğinden yenilenmiyor ([Drive API, anlık bildirimler](https://developers.google.com/workspace/drive/api/guides/push), 16 Ekim 2026’da okudum). Bildirim gelse de sekmeyi okuyup karşılaştırmak gerekir. - **Zamanlı tetikleyici aralıkları sabittir.** Apps Script’te dakika bazlı aralık 1, 5, 10, 15 ya da 30 dakika olabilir ([Apps Script, ClockTriggerBuilder](https://developers.google.com/apps-script/reference/script/clock-trigger-builder), 16 Ekim 2026’da okudum). Eşitleme sizin sunucunuzda çalışıyorsa aralığı siz seçersiniz. **Kotalar sorun mu?** Google’ın Sheets API sınırları sayfası, okuma ve yazma için ayrı ayrı proje başına dakikada 300, proje içinde kullanıcı başına dakikada 60 istek veriyor. Günlük sınır yok. Aşılırsa “429: Too many requests” dönüyor, Google artan aralıklarla yeniden denemeyi öneriyor. Önerilen en büyük istek gövdesi 2 MB, 180 saniyeyi aşan istek zaman aşımına düşüyor ([Sheets API kullanım sınırları](https://developers.google.com/workspace/sheets/api/limits), 16 Ekim 2026’da okudum, sayfa 3 Eylül 2026’da güncellenmiş). Benim okumam: buradaki kullanıcı, eşitlemenin bağlandığı Google hesabıdır, eşitleme tek hesapla çalıştığı için 60 sınırı o hesaba uygulanır. Örneğe uygulayınca: döngü başına bir okuma ve bir toplu yazma ayda en çok 5.760 istek eder, dakikada 0,2 okuma isteği, kota 60. 418 satırlık sekme, satır başına yaklaşık 350 bayt varsayımıyla 0,15 MB. Kota, hücre hücre yazınca dolar: planlamacıların sabah güncellediği 180 sevk tarihi ayrı ayrı ve aynı dakikada yazılsaydı kullanıcı kotasının 3 katı olurdu, 120 istek 429 alırdı. Toplu yazmayla tek istek. ## Tarih, ondalık ve baştaki sıfır: hücre biçimi sorunları Hücre biçimi sorunlarının çoğu, değeri ekranda görünen hâliyle okuyup yazmaktan çıkar. Önerdiğim kural: biçimsiz değer okumak, metni metin olarak yazmak. - **Tarih aslında sayıdır.** Google’a göre E-Tablolar tarih ve saati ondalık sayı olarak tutar, tam kısım 30 Aralık 1899’dan bu yana geçen günü sayar ([Sheets API, tarih ve sayı biçimleri](https://developers.google.com/workspace/sheets/api/guides/formats)). Değeri biçimlenmiş metin olarak okursanız “04.03” gibi bir metin alırsınız, bunun 4 Mart mı 3 Nisan mı olduğu dosyanın yerel ayarına bağlıdır (bu örnek benim). Ben tarihi seri numara olarak okurum (API’de `UNFORMATTED_VALUE` ve `SERIAL_NUMBER`). - **Yerel ayar biçimi değiştirir.** Dosya > Ayarlar’daki yerel ayar, dosyanın varsayılan para birimi, tarih ve sayı biçimini değiştirir ([Google Dokümanlar Yardım](https://support.google.com/docs/answer/58515)). Eşitleme bu yüzden ekranda görüneni değil, değerin kendisini karşılaştırır. - **Yazarken metin dönüşebilir.** API’de “kullanıcı girmiş gibi” yazma seçeneğinde metinler sayıya ya da tarihe çevrilebiliyor, “olduğu gibi” seçeneğinde değer ayrıştırılmadan saklanıyor ([Sheets API, ValueInputOption](https://developers.google.com/workspace/sheets/api/reference/rest/v4/ValueInputOption)). Önceki ayın 31 ürün kodu bu yüzden 0815’ten 815’e döndü: betik kullanıcı girmiş gibi yazıyordu. Ürün kodu, sipariş numarası gibi alanlar her zaman metin olarak ve “olduğu gibi” yazılır. - **Temsilcinin girdiği tarih doğrulanır.** Termin sütununa tarih doğrulaması konur. Miktar gibi sayılar da biçimsiz okunur, “1.250”nin bin iki yüz elli mi bir virgül yirmi beş mi olduğu tahmin edilmez. ## Eşitlemenin sessizce bozulduğunu nasıl fark edersiniz? Eşitlemenin bozulduğunu, ekip eksikliği fark etmeden önce üç sayı söyler: son başarılı döngünün zamanı, kontrol sayısı ve hata kuyruğunun boyu. Üçü de iki tarafta görünür olmalı. - **Son başarılı döngü.** Sekmede “Son eşitleme” sütunu ve uygulamada bir gösterge. Üç döngü (15 dakika) boyunca başarılı döngü yoksa satış müdürüne ve planlama şefine uyarı gider. 9. iş günündeki başlık değişikliği böyle yakalandı. - **Kontrol sayısı.** Saatte bir iki tarafta açık sipariş adedi ve açık miktar toplamı. Adet tutup toplam tutmuyorsa bir miktar değişikliği geçmemiştir, adet tutmuyorsa satır kaybolmuştur. 14. iş günündeki 23 satırlık farkı da gösterdi. - **Hata kuyruğu.** Kayıt sayısı ve en eski kaydın yaşı, çünkü kuyruktaki değişiklik uygulanmamıştır. Önerim, 1 iş gününden eski kaydın satış müdürünün listesine düşmesi. Eşitleme bir kişinin hesabına bağlıysa bir sinyal daha kaybolur. Google’a göre kurulabilir tetikleyiciler her zaman onları oluşturan kişinin hesabıyla çalışır, hata özetleri de e-postayla gönderilir ([Apps Script, kurulabilir tetikleyiciler](https://developers.google.com/apps-script/guides/triggers/installable)). Bu benim çıkarımım: önceki ayın betiği gibi bir çalışanın hesabında duran eşitlemenin hata e-postası o kişinin kutusuna gider. O kişi izindeyse ya da işten ayrıldıysa kimse görmez. Önerim, eşitlemenin kişiye bağlı olmayan bir hesapla çalışması ve uyarının bir role gitmesi. ## E-Tablolar’ın kendisi ya da tek yönlü aktarım yetiyorsa En güvenli çift yönlü eşitleme, hiç kurulmayandır. Şu durumlarda ayrı bir eşitleme yaptırmanızı önermem: - **Bir taraf yalnız okuyor.** Temsilciler sevk durumunu görmek istiyor ama sekmede hiçbir şeyi değiştirmiyorsa tek yönlü aktarım yeter. Her gün ya da her saat veriyi kaynaktan alıp tabloya yazan zamanlı aktarımı [API’den düzenli veri çeken uygulama sayfasında](https://oguzerol.com/gunluk-api-veri-aktarma-uygulamasi/) anlattım. - **Veri zaten tek yerde durabilir.** Ekip küçükse ve ikinci bir sistem yoksa tarih doğrulamalı, korumalı tek bir sekme yeterlidir. Tablonun ne zamana kadar veritabanı gibi kullanılabileceğini [Google Sheets’i veritabanı olarak kullanma sayfasında](https://oguzerol.com/google-sheets-veritabani-olarak-kullanmak/) ele aldım. - **Herkes uygulamaya geçebilir.** Temsilcilerin sekmedeki işi uygulamada bir ekranla yapılabiliyorsa eşitleme yerine onu öneririm. - **ERP’nizin ya da CRM’inizin kendi E-Tablolar bağlantısı var** ve kayıt anahtarı, çakışma ve silme davranışı belgelenmiş. Önce onu sonuna kadar kullanmanızı öneririm. - **Hazır bir entegrasyon servisi işinizi görebilir.** Seçmeden önce üç konuyu, alan sahipliğini, çakışma kuralını ve toplu kayıp eşiğini nasıl ele aldığını sorun. - **Değişiklik seyrek.** Haftada bir güncellenen bir fiyat listesi için dosyayı dışa aktarıp kontrollü içe almak eşitlemeden ucuzdur. Çift yönlü eşitleme, iki ekip de kendi yerinde çalışmak zorundaysa ve aynı kaydın farklı alanlarını değiştiriyorsa değer. ## Kim neyi değiştirir, iz kaydı nasıl tutulur? Önerdiğim temel kural: kimse kendi çakışmasını çözmez. Roller şöyle: - **Satış temsilcisi:** sekmede kendi siparişlerinin termin, öncelik ve notunu değiştirir, sevk durumunu görür. - **Satış asistanı:** temsilcilerin alanlarını düzenler, okunamayan tarihleri düzeltir. - **Sevkiyat planlamacısı:** uygulamada sevk tarihini, durumu ve önceliği değiştirir. - **Planlama şefi:** öncelik çakışmalarını çözer. Kendi değişikliğinin taraf olduğu çakışmayı satış müdürü çözer. - **Satış müdürü (kural sahibi):** alan sahipliği tablosunu, eşikleri ve taşıma kuralını değiştirir, toplu kayıp uyarısında karar verir. - **Yönetim ve denetçi:** iki tarafı ve iz kaydını görür, hiçbir şeyi değiştiremez. E-Tablolar’da sekmeye erişen herkes bütün satırları görür, koruma yalnız düzenlemeyi kısıtlar. Temsilcinin yalnız kendi müşterilerini görmesi gerekiyorsa her temsilciye yalnız kendi satırlarını içeren ayrı bir dosya eşitlenebilir, kapsamı ilk adımda yazılı belirlenir. **İz kaydı**, eşitlemenin yaptığı her değişikliğin silinemeyen satırıdır: zaman, döngü, kayıt anahtarı, alan, eski ve yeni değer, geldiği taraf, reddedildiyse sebebi, çakışmayı kimin hangi gerekçeyle çözdüğü. Uygulama tarafındaki değişiklikte kişi bellidir. E-Tablolar tarafında değeri kimin yazdığı API okumasıyla gelmez, bu yüzden iz kaydı satırın temsilcisini ve değişikliğin görüldüğü döngüyü yazar. 14. iş günündeki 23 satır iz kaydında “toplu kayıp” diye, geri yazma ve taşıma kararı satış müdürünün adıyla duruyor. ## Yapay zekâ ne yapar, nerede durur? Yapay zekâ bu eşitlemede öneri yapar, karar vermez. Kayıt anahtarı, alan sahipliği, çakışma ve silme kuralları eşitlemenin kendi kuralıdır. İki yerde işe yarayabilir: 1. **Okunamayan tarihten öneri.** “Haftaya salı” ya da “ay sonu” yazan hücre için model, değişikliğin görüldüğü günü referans alıp bir tarih önerir. Kurgusal örnek ayın 19 hücresinin 15’inde öneri yaptı, 4’ünde (“müşteri dönecek” gibi) yapmadı. Satış asistanı 13 öneriyi kabul etti, 2’sini düzeltti. Kabul edilene kadar hiçbir değer uygulamaya geçmedi. 2. **Değişen başlık için eşleme önerisi.** “Termin (müşteri)” başlığını görünce model bunun “Müşteri termini” olabileceğini söyler. Eşlemeyi kural sahibi onaylar, model sütunu kendiliğinden yeniden bağlamaz. Model çakışmayı çözmez, satır silmez ya da geri yazmaz. Modele hiçbir satır yetki filtresinden geçmeden gitmez: tarih önerisi için yalnız o hücrenin metni ve referans tarih gider, müşteri adı gitmez. **Temsilci notu kişisel veri taşıyabilir.** Notlarda müşterideki ilgili kişinin adı ve telefonu sık geçer. KVKK, kişisel verinin işlendiği amaçla bağlantılı, sınırlı ve ölçülü işlenmesini istiyor ([6698 sayılı Kanun, md. 4/2-ç](https://www.mevzuat.gov.tr/mevzuatmetin/1.5.6698.pdf)). Not alanı modele hiç gitmez. Kişisel veri taşıyan bir alanı yurt dışında çalışan bir yapay zekâ servisine göndermek KVKK’nın 9. maddesine girebilir. Madde [7499 sayılı Kanun’un 34. maddesiyle](https://www.resmigazete.gov.tr/eskiler/2024/03/20240312-1.htm) değiştirildi (RG 12.03.2024/32487, yürürlük 1.6.2024), güncel metni 16 Ekim 2026’da mevzuat.gov.tr’den okudum. Hukuki görüş vermiyorum. Hangi alanın modele gittiğini ilk adımın çıktısında yazılı veririm, değerlendirmeyi hukuk danışmanınız yapar. ## Nasıl başlanır, veri ve kod kimin? İlk adımda bugünkü sekmenize, uygulamanızın ya da ERP’nizin hangi alanları dışarı verebildiğine ve son haftalarda iki tarafta nelerin değiştiğine bakarız. Çıktısında alan sahipliği tablosunu, kayıt anahtarını, çakışma ve silme kurallarını, eşitleme sıklığını, rol listesini ve ilk sürümün kapsamını yazılı veririm. Otomasyon projelerinde en sık gördüğüm hata, ilk otomasyonu en karmaşık süreçten seçmek. Bu yüzden ilk sürüm tek yönle başlar: uygulamadan sekmeye. Kontrol sayısı birkaç hafta tutarlı çıkınca E-Tablolar’a ait alanlar açılır, iki yönlü alan en son eklenir. Uygulama şirketiniz adına açılabilen bir sanal sunucuda (VPS) çalışır. Veri sizindir, istediğiniz zaman Excel ya da CSV olarak alırsınız. Küçük ve orta ölçekli ekipte kullanıcı başına lisans yok, maliyet sunucu ve bakım. Kaynak kod erişiminizdeki bir depoda, çalıştırma talimatı, bağımlılık listesi ve bilinen sınırlarla durur. Eşitlemenin hangi Google hesabıyla çalışacağı ilk adımda yazılı belirlenir, notlardaki kişisel veri yüzünden erişim ve güvenlik ayrıca değerlendirilir. **ERP’niz ya da sekmenin yapısı değişirse ne olur?** İz kaydı ve uygulamadaki kayıtlar olduğu gibi kalır. Yeni sütun önce alan sahipliği tablosuna yazılır. ERP’den okuma ve yazma için olası yollar API, zamanlı dışa ya da içe aktarma dosyası ve salt okunur bir veritabanı görünümüdür. Hangisinin kullanılacağı ERP’nizin sunduğuna bağlıdır, ilk adımda yazılı belirlenir. Bugünkü sekmenizin bir kopyasını, müşteri adlarını ve notları maskeleyerek, iki tarafta hangi alanları değiştirdiğinizle birlikte [iletişim sayfasından](https://oguzerol.com/iletisim/) gönderin. İlk görüşmede hangi alanın gerçekten iki yönlü olması gerektiğine ve bugün nerede kayıp yaşadığınıza bakarız. ## Sıkça Sorulan Sorular ### Biri satırı kopyalayıp yapıştırırsa ya da sekmeyi çoğaltırsa ne olur? Kopyalanan satır aynı kayıt anahtarını taşır. Aynı anahtar iki satırda görülünce ikisi de işlenmez, hata kuyruğuna düşer, böylece iki satır birbirini ezmez. Çoğaltılan sekme ya da dosyanın kopyası eşitlenmez, eşitleme belirli bir dosyanın belirli bir sekmesine bağlıdır. ### Mevcut tabloyu ilk kez bağlarken ne yapılır? Önce bir kez eşleştirme yapılır: sekmedeki her satır anahtarıyla uygulamadaki kayda bağlanır. Anahtarsız ya da karşılığı olmayan satırlar liste olarak çıkar, otomatik kayıt açılmaz. Liste kapanmadan iki yönlü eşitleme başlamaz. ### Kaç kişiye kadar E-Tablolar’da kalınabilir? Bunu ölçmedim, sayı vermiyorum. Sinyaller: aynı satıra iki kişinin yazdığı günler artıyorsa, “kim değiştirdi” sorusu haftada birkaç kez soruluyorsa ya da biri her ay tabloyu temizliyorsa iş tablodan büyümüştür. [Başa dön ↑](https://oguzerol.com/google-sheets-cift-yonlu-senkronizasyon/#icerik) ## Bunları da okumak ister misiniz? [Google Sheets ve Takvim SenkronizasyonuTablodaki tarih değişince aynı takvim etkinliği güncellensin. Sheets bağlantısında kayıt kimliği, saat dilimi ve çakışma kurallarını birlikte planlayalım.](https://oguzerol.com/google-sheets-takvim-senkronizasyonu/)[Google Sheets IMPORTRANGE: Bağlantı ve Merkezi Veri PaneliGoogle Sheets IMPORTRANGE izinlerini, güncelleme gecikmesini ve kaynak zincirini değerlendirin. Gerektiğinde güncelliği görünen merkezi veri paneli kuruyorum.](https://oguzerol.com/importrange-yerine-merkezi-veri-paneli/)[Google Sheets Webden Veri Çekme: IMPORTHTML ile BaşlangıçGoogle Sheets webden veri çekme için IMPORTHTML örneğini deneyin. Tablo kaynağı, yenileme ve eski verinin görünürlüğünü kontrol ederek uygun yöntemi seçin.](https://oguzerol.com/google-sheets-webden-veri-cekme/) [Tüm yazılara göz atın →](https://oguzerol.com/yazilarim/) NE İSTEYEBİLİRSİNİZ ## Nasıl çalışıyorum? Çalışma saati paketleri WhatsApp’tan ya da telefonda işinizden ve ihtiyacınızdan bahsedin; **5 ile 40 saat arasında bir çalışma paketinde** anlaşalım, ben gerekenleri yapmaya başlayayım. Aldığınız şey bir takvim aralığı değil, doğrudan sizin işinize harcanacak net mesai. 40 saati üç gün aralıksız çalışarak da kullanabiliriz, bilerek zamana yayıp bir yılda da bitirebiliriz — işin gerektirdiği neyse o. İşin ne kadar süreceğini tahmin etmeye değil, işi yapmaya vakit harcarım; harcadığım her saatin işinizde kalıcı bir karşılığı olur. Faydalı olduğunu düşündüğünüz sürece bu şekilde devam ederiz. ÇALIŞMA BLOKLARI ## Neden aylık değil? 40 saat 1 hafta mı oluyor? Aylık sabit ücrette iki taraf da yanlış yere bakar: siz sabit gidere, karşı taraf kaç tane daha böyle sözleşme bağlayabileceğine. Saat üzerinden çalışınca ikimizin de baktığı yer aynı olur — yapılan işin gerçek değeri. "Toplamda ne kadar tutar?" sorusunun peşinen net bir cevabı olmaması bu modelin doğal maliyeti, farkındayım. Ama sonuç üretmeyen bir yapıya aylarca sabit ücret ödemek yerine yalnızca işinize ayrılan nitelikli zamanı ödersiniz, o zamanın nereye gittiğini de baştan sona görürsünüz. Müşterilerimin benimle tekrar tekrar çalışmasının sebebi bu. 5saat10.000₺ + KDVsaat başı 2.000₺[Bu bloğu seç](https://wa.me/905496546489?text=Merhaba%2C%205%20saatlik%20%C3%A7al%C4%B1%C5%9Fma%20blo%C4%9Fu%20hakk%C4%B1nda%20bilgi%20almak%20istiyorum.) 10saat15.000₺ + KDVsaat başı 1.500₺[Bu bloğu seç](https://wa.me/905496546489?text=Merhaba%2C%2010%20saatlik%20%C3%A7al%C4%B1%C5%9Fma%20blo%C4%9Fu%20hakk%C4%B1nda%20bilgi%20almak%20istiyorum.) 20saat24.000₺ + KDVsaat başı 1.200₺[Bu bloğu seç](https://wa.me/905496546489?text=Merhaba%2C%2020%20saatlik%20%C3%A7al%C4%B1%C5%9Fma%20blo%C4%9Fu%20hakk%C4%B1nda%20bilgi%20almak%20istiyorum.) 40saat40.000₺ + KDVsaat başı 1.000₺[Bu bloğu seç](https://wa.me/905496546489?text=Merhaba%2C%2040%20saatlik%20%C3%A7al%C4%B1%C5%9Fma%20blo%C4%9Fu%20hakk%C4%B1nda%20bilgi%20almak%20istiyorum.)