Günlük API Veri Aktarımı: Pazaryeri ve Kargo Verisini Merkezde Toplamak

Her sabah iki pazaryeri panelinden ve kargo panelinden Excel indirip birleştiriyorsanız bu işi, belli saatte API’ye bağlanıp veriyi çeken ve ne geldiğini, neyin gelmediğini gösteren bir uygulamaya devredebilirsiniz. Asıl tehlike hata veren çekim değil, “başarılı” görünüp eksik ya da iki kez gelen çekimdir. Aşağıdaki kurgusal ayda, aynı pencereyi kullanan ama kayıt anahtarı ve satır sayımı olmayan basit bir betik ayı 6.261 sipariş satırıyla kapatırdı. Doğrusu 5.428. Fark +833: 918 fazla satır, hiç gelmemiş 85 satırı örtüyordu.

Günlük API veri aktarma uygulaması, bir ya da birkaç dış sistemden (pazaryeri siparişi ve stoku, kargo durumu, döviz kuru, ödeme sağlayıcısı raporu) her gün planlı saatte veri çeken, her kaydı bir anahtarla tanıyıp mükerrer yazmayan, her çekimi kaydeden ve eksik günü tamamlatan bir web uygulamasıdır. API, iki sistemin tanımlı bir yolla veri alışverişi yapmasını sağlayan arayüzdür, kaynağın buna izin vermesi gerekir. Bu uygulamayı şirketinize özel geliştiriyorum.

Önce üç soru: Dünkü çekimin kaç satır getirdiğini ve kaçının zaten elinizde olduğunu biliyor musunuz? Bir gün eksik gelse kim fark eder? Aynı rapor iki kez yapıştırılırsa bunu yakalayan bir şey var mı? Veriye ayda bir bakıyorsanız ya da tek kaynak ve tek kullanıcı varsa aşağıdaki “yetiyorsa” bölümüne geçin. Bu sayfa tek yönlü, zamanlanmış çekmeyi anlatıyor. Sheets tablosu ile uygulamanın birbirini güncellemesi başka bir tasarımdır, Google Sheets çift yönlü senkronizasyon sayfasında anlattım.

Uygulama nasıl çalışır?

Uygulama planlanan saatte kaynağa bağlanır, bir zaman aralığının verisini sayfa sayfa alır, her satırı anahtarıyla kontrol ederek yazar ve sonucu çekim kaydına düşer. Beş kavramı hep aynı adla kullanıyorum:

• Çekim işi: bir kaynaktan belirli veriyi belirli saatte çeken tanım. Örnek: “08.00, Pazaryeri A, sipariş satırları.”
• Çekme penceresi: işin bir çalışmada istediği zaman aralığı. Örnek: önceki gün 00.00–24.00, iki saat geriye örtüşmeyle.
• Kayıt anahtarı: bir satırı tek başına tanıyan alanlar. Bu örnekte kaynak + sipariş numarası + sipariş satır numarası.
• Çekim kaydı: her denemenin silinemeyen satırı: başlangıç, gelen, yazılan, atlanan, hata nedeni.
• Gün durumu: her kaynak ve her veri günü için tek etiket: tamam, eksik, incelemede, çekilemedi ya da yayın yok.

Gelen her satır dört sınıftan birine düşer. Yeni (anahtar yok, eklenir), güncellenen (anahtar var, değer değişmiş, örneğin sipariş iptal edilmiş), atlanan (anahtar var, değer aynı) ve incelemede (yazılamıyor, örneğin ürün kodu katalogda yok). “Yazılan” yeni ve güncellenenlerin toplamıdır. Bir çekim kendi kendini sınar: dört sınıfın toplamı gelen satır sayısına eşit değilse çekim başarılı sayılmaz.

Örnek ay: üç kaynak, 30 gün

Örnek veri, kurgusaldır. Ev ve mutfak ürünleri dağıtan bir şirket düşünün. İki pazaryerinde mağazası var, gönderileri tek bir kargo firmasıyla yapıyor. Önceki aylarda finans uzmanı her sabah üç panelden rapor indirip tek bir Excel dosyasında alt alta yapıştırıyordu. Uygulama bu ay devreye girdi. Üç çekim işi var:

Sipariş işleri önceki günü (“veri günü”) çeker. Veri 09.30’da hazır olmalı, operasyon ekibi o saatte günlük raporu açıyor.

Ayın akışında olanlar:

• 3. veri günü, görseldeki sabah. Pazaryeri A çekimi 08.00’de başladı, 08.03’te bitti. 126 satır geldi: 113 yeni, 5 güncellenen, 6 atlanan, 2 incelemede. Yani 124 satır uygun (yazıldı ya da zaten vardı), 2 satırın ürün kodu katalogda yoktu. “Son başarılı çalışma 08.03” bu iki satırın yazıldığı anlamına gelmiyor, inceleme sayısı aynı ekranda duruyor.
• 9. veri günü, Pazaryeri B’de kampanya. 412 sipariş satırı vardı, kaynak 50’şer satırlık 9 sayfa verdi. İlk deneme 7. sayfada bağlantı kopunca durdu, 6 sayfanın 300 satırı yazılmıştı. İkinci deneme iki dakika sonra “çok fazla istek” yanıtı aldı, kaynak 120 saniye beklenmesini istedi. Üçüncü deneme, ikisinden uzun olan dört dakikalık sıradaki beklemeden sonra pencereyi baştan çekti: 412 satır geldi, 300’ünün anahtarı zaten vardı ve atlandı, 112 satır yazıldı.
• 16. ve 17. veri günü, Pazaryeri A. Kaynak yeni API sürümünde “bekleyen” durumundaki siparişleri varsayılan filtreden çıkarmıştı. Çekimler hata vermedi, 128 yerine 84, 121 yerine 80 satır getirdi. Her günün önceki 14 veri günü ortalamasına (127,9 ve 124,5 satır) göre bu yüzde 66 ve yüzde 64 demekti. Sayı kuralı tetiklenmedi. Bu kural, gelen satır önceki 14 veri gününün ortalamasının yarısının altına düşerse günü “incelemede”ye alır. Yüzde 50 başlangıç değerim, kaynağa göre ayarlanır. 17’si ve 18’i sabahki yapay zekâ özetlerinde ise not vardı: önceki 14 günde günde ortalama 45 “bekleyen” satır gelirken o gün hiç gelmemişti.
• 24. gün, kargo. 08.20’deki çekim yetki hatası aldı, API anahtarının süresi dolmuştu. Geçici hata olmadığı için tekrar denenmedi, 08.21’de bildirim gitti. Kargo hesabını yöneten kişi anahtarı 10.05’te yeniledi, teknik yönetici işi 10.12’de elle çalıştırdı. Gün 10.12’ye kadar “çekilemedi”, sonra “tamam” oldu. 09.30’da günlük rapor sipariş verisiyle açıldı, kargo bölümünde “çekilemedi, son güncelleme: dün 08.20” uyarısı duruyordu.

Ay sonunda çekim kaydı şöyle:

Ay sonu sipariş satırı, yeni satırlarla incelemeden çözülüp yazılanların toplamıdır (A’da 3.391 + 16). Güncellenen ve atlanan satırlar yeni satır açmaz. Kargo işi 31 kez çalıştı. Üç işte planlı 90 çekime 4 ek deneme eklendi.

Ay sonunda çıkan karar

Finans müdürü ayı kapatmadan önce sayıları iki pazaryerinin panelindeki aylık sipariş raporlarıyla karşılaştırdı: A 3.407, B 2.021 satır. Fark sıfır, ay kapandı. Karşılaştırma raporla aynı ölçütle yapılır: siparişin oluşturma tarihi, iptaller dahil. Uygulama son değişiklik zamanına göre çekse de her satır oluşturma ayına sayılır. Ay sonunda oluşup ertesi ay iptal edilen sipariş bu yüzden ay değiştirmez. Devreye almadan önce oluşmuş bir sipariş ilk çekimlerde değişikliğiyle gelirse kendi oluşturma ayına yazılır, bu ayın sayımına girmez. Kaynağın raporu satır sayısı veriyor mu, ilk adımda bakarım.

Aynı ay, aynı pencereyi kullanan ama kayıt anahtarı olmayan bir betikle (gelen her satırı yeni satır yazan, yarım kalan çekimi baştan tekrarlayan) çekilseydi:

Fark +833, yüzde 15,3. Fazlayı arayan kişi ise, toplam zaten yüksekken çoğu zaman “eksik gün var mı” diye bakmaz. 16 ve 17’nin 85 satırı fazlanın içinde kaybolurdu. Kampanya gününün kendisi de basit betikte 412 yerine 712 satır görünürdü, gerçeğin yüzde 72,8 fazlası.

Önerdiğim kapanış kuralı üç şart: her kaynağın her veri günü “tamam” olur, inceleme kuyruğu boşalır, kaynağın kendi raporuyla fark sıfır olur. Fark sıfır değilse ay kapanmaz ve fark toplamda değil, gün gün aranır. Bu ayın ardından iki kural daha eklendi. “Bekleyen” durumunda satır gelmeyen gün eksik sayılır. Kaynağın sürüm notları kural sahibinin takvimine girer.

Çekme penceresi ve yeniden deneme nasıl kurulur?

Çekme penceresi yanlış kurulursa çekim hatasız biter ama veri eksik kalır. Başlangıç önerim, siparişleri oluşturma zamanına göre değil son değişiklik zamanına göre çekmek. Bir sipariş bugün oluşup üç gün sonra iptal edilebilir. Oluşturma zamanına göre çeken iş o iptali hiç görmez. Pencere önceki günün tamamını, iki saat geriye örtüşmeyle ister. Örtüşme, kaynağın birkaç dakika geç kaydettiği değişikliklerin pencere sınırında kaçmaması içindir. Örtüşmeden gelen tekrarları anahtar atlar, örnek ayda A’da 179, B’de 168 satır böyle atlandı.

Pencere kaynağın saat dilimiyle (çoğu zaman UTC) yazılır.

Hataları ikiye ayırırım, çünkü ikisine verilecek cevap zıttır:

Kaynak yanıtında bir bekleme süresi bildirmişse, bu süre ile sıradaki bekleyişten uzun olanı beklenir.

Yarım kalan çekimde kaldığı sayfadan devam etmek cazip görünür. Ama sayfalar sıra numarasıyla veriliyorsa araya giren yeni siparişler satırları kaydırır, bir satır iki sayfada görünür ya da hiç görünmez. Benim tercihim pencereyi baştan çekip zaten var olan satırı anahtarla atlamak. Kaynak bir devam imleci (bir sonraki sayfayı istemek için verdiği kod) veriyor ve süresi dolmamışsa ondan devam edilir.

Aynı kayıt iki kez gelirse ne olur?

Aynı kayıt iki kez gelirse ikinci geliş yeni satır açmaz: anahtarı zaten varsa ya atlanır ya da değişen alanlar güncellenir. Teknik adı idempotent yükleme: bir kez de on kez de çalışsa sonuç aynıdır. Örnek aydaki kampanya gününün 300 satırı bu yüzden iki kez yazılmadı.

Anahtarın seçimi işin en önemli kararıdır. Önerdiğim kurallar:

• Anahtar kaynağın kalıcı kimliğinden kurulur: sipariş numarası ve sipariş satır numarası. Dosya adı, çekim saati ya da satırın sırası anahtar olmaz.
• Kaynak adı anahtarın başında durur. İki pazaryeri birbirinden habersiz numara verir. A’nın 10045 numaralı siparişi ile B’nin 10045 numaralı siparişi ayrı satırlardır.
• Aynı anahtar, farklı değer gelirse üzerine yazılır ama eski değer kaybolmaz. Satırın önceki hâli ve onu değiştiren çekimin numarası saklanır.
• Kaynakta silinen kayıt merkezde silinmez. “Kaynakta yok” diye işaretlenir. Silmenin anlamı ilk adımda kaynağın belgesine bakılarak kararlaştırılır.
• İptal ya da iade edilen satır silinmez, durumu güncellenir. Sayımda satır olarak kalır, raporun “iptaller dahil” sayımıyla bu yüzden eşleşir.

Veri tablosu ile çekim kaydı ayrı tutulur. Veri satırı hangi çekimle geldiğini ve son hangi çekimle güncellendiğini taşır. Kaynak yanıtında toplam kayıt sayısı bildiriyorsa o da çekim kaydına yazılır ve gelen sayıyla karşılaştırılır.

Kaynağın hız sınırı ve sayfalama neden önemli?

Hemen her API kabul ettiği istek sayısını sınırlar ve büyük sonucu sayfalara böler, okunmayan sayfa çekimi eksik bırakır. “Çok fazla istek” yanıtının standart kodu 429’dur. Yanıt, ne kadar beklenmesi gerektiğini Retry-After satırıyla bildirebilir (RFC 6585, md. 4). Bu süre saniye ya da tarih olarak gelir (RFC 9110, md. 10.2.3). İki belgeyi 16 Ekim 2026’da okudum.

API ile çalışmayı kendi işimden tanıyorum: Google Ads raporlarını kendi Python betiğimle Google Ads API’sinden çekiyorum. Belirli bir pazaryerinin ya da kargo firmasının sınırlarını ise yazmıyorum, her API’de farklılar ve değişiyorlar. İlk adımda kaynağın belgesinden okurum (dakikada kaç istek, sayfa boyu, geçmişe dönük kaç gün, sürüm değişikliğinin nasıl duyurulduğu) ve tarihiyle kapsam belgesine yazarım. Önerdiğim kurallar:

• İstekler kaynağın sınırının altında aralıklandırılır. Aynı kaynağa bağlanan iki iş varsa, örneğin aynı pazaryerinden hem sipariş hem stok çekiliyorsa, sınırı paylaşırlar ve aynı anda değil art arda çalışırlar.
• Son sayfa tam dolu geldiyse ve devam imleci yoksa çekim “şüpheli” işaretlenir. 50 satırlık sayfa boyunda tam 50 satırla biten bir çekim, devam imlecini okuyamamış olabilir.

Çekim başarısız olursa kim, nasıl haberdar olur?

Çekim başarısız olursa işin sahibi ve yedeği, kalıcı hatada ayrıca teknik yönetici haberdar olur. Bildirim, hatanın sade dille nedenini ve son başarılı çekimin zamanını taşır. Kanalı ilk adımda birlikte seçeriz. Önerdiğim zamanlama:

• Kalıcı hata: hemen. Örnek aydaki kargo bildirimi 08.21’de gitti.
• Geçici hata: her denemede değil, son deneme de başarısız olunca ya da 09.30’a kadar gün “tamam” olmazsa.
• Şüpheli sonuç: sayı kuralı, tam dolu son sayfa ya da onaylanmış bir anormallik notu. Çekim başarılı ama gün “incelemede” kalır.
• Hiç çalışmama: en sinsi durum. Zamanlayıcı durmuşsa hata mesajı da üretilmez. Bu yüzden zamanlayıcıdan ayrı bir denetim, örneğin 08.40’ta, her işin o sabah çekim kaydında satırı var mı diye bakar. Yoksa bildirim gider.

Eksik bir gün nasıl tamamlanır?

Eksik gün, aynı çekim işinin geçmiş bir pencereyle yeniden çalıştırılmasıyla tamamlanır. Anahtar sayesinde bu güvenlidir: zaten var olan satırlar atlanır, yalnız eksikler yazılır. Örnek ayda 16 ve 17. veri günleri için yapılan yeniden çekim 249 satır getirdi. 164’ü zaten vardı, 85’i yazıldı.

Gün durumu tablosu hangi günün tamamlanacağını gösterir: tamam, eksik (çekildi ama eksik bulundu), incelemede (kuyrukta satır var ya da sonuç şüpheli), çekilemedi ve yayın yok. Sonuncusu önemli: hafta sonu kur yayınlamayan bir kaynakta cumartesi “eksik” değil “yayın yok” olmalı, yoksa her pazartesi sahte alarm gelir.

Önerdiğim kurallar:

• Açık ayın bir gününü operasyon uzmanı yeniden çekebilir. Kapanmış bir ayın gününü yeniden çekmek finans uzmanının onayını ister. Değişen satırlar “kapanış sonrası değişiklik” listesine düşer, kapanmış rakam sessizce değişmez.
• Yeniden çekim, kaynağın geçmişe dönük verdiği sürenin içinde yapılabilir. Bu süre API’ye göre değişir. Dışına düşen gün için panelden alınan dosya kontrollü bir aktarımla alınır.

Anahtarlar ve şifreler nerede durur?

API anahtarları ve kaynak hesapları şirketinizin adına açılır, uygulama bunları kodun dışında, sunucudaki ayrı bir yapılandırmada tutar. Benim hesabımdan geçen kurulum yapmam, o zaman bağlantı gerçekten sizin olmaz. Önerdiğim düzen:

• Anahtar kodun içine, Excel dosyasına ya da ekrana yazılmaz. Kayıtlı anahtarı uygulamada kimse açıp okuyamaz. Teknik yönetici yenisini girebilir, eskisini göremez.
• Her kaynak için mümkünse yalnız okuma yetkili anahtar kullanılır. Sipariş çeken işin sipariş değiştirme yetkisi olmamalı.
• Anahtar değişikliği iz kaydına yazılır, değeri yazılmaz: kim, ne zaman, hangi kaynak için.
• Süresi dolan anahtarın tarihi biliniyorsa önceden hatırlatılır. Kargo gecikmesi böyle önlenebilirdi.

Sipariş verisi müşterinin adını, adresini ve telefonunu taşır. KVKK, veri sorumlusunun hukuka aykırı erişimi önleyecek teknik ve idari tedbirleri almasını istiyor (6698 sayılı Kanun, md. 12/1), anahtarın korunması bunun parçası.

Kim ne yapar? Roller ve iz kaydı

Önerdiğim temel kural: kimse kendi açtığı kapanmış gün yeniden çekim talebini onaylamaz. Roller:

• Operasyon uzmanı (işin sahibi): sabah çekim kaydını kontrol eder, incelemedeki satırları ve gönderi sorunlarını çözer, açık ayın günlerini yeniden çeker, anormallik önerisini onaylar ya da reddeder.
• Finans uzmanı: ayı kapatır, kaynağın raporuyla karşılaştırmayı onaylar, kapanmış güne yeniden çekimi onaylar.
• Kural sahibi (operasyon müdürü): çekim saatlerini, pencereyi, eşikleri ve 09.30 son saatini değiştirir. Her değişiklik yeni bir kural sürümü olarak kaydedilir.
• Teknik yönetici (şirketinizin bilgi işlemi ya da bakımı üstlenen kişi, kim olduğu ilk adımda yazılır): anahtarı yeniler, işi duraklatır ya da elle çalıştırır, kaynaktaki değişikliğe uyarlamayı yapar.
• Rapor kullanan, yönetim ve denetçi: veriyi, çekim kaydını ve gün durumunu görür, hiçbir şeyi değiştiremez.

Müşteri adı, adresi ve telefonu yalnız operasyon uzmanının ekranında görünür, aylık raporu okuyanın bunlara ihtiyacı yok.

İz kaydı, her çekimin ve elle yapılan her işlemin silinemeyen satırıdır: kim, ne zaman, hangi kural sürümüyle, hangi gerekçeyle. Örnekte 16–17 yeniden çekimi, operasyon uzmanının onayladığı anormallik notuna bağlı duruyor.

Yapay zekâ ne yapar, nerede durur?

Yapay zekâ bu uygulamada öneri yapar, karar vermez. Çekim, anahtar kontrolü, sayı kuralı ve yeniden deneme uygulamanın kendi kurallarıdır, yapay zekâ gerektirmez. Üç yerde işe yarayabilir:

1. Anormallik önerisi. Model her sabah çekim kaydını ve satırların dağılımını (durum, ürün grubu) önceki günlerle karşılaştırıp kısa not yazar. Örnek ayın 17’si sabahı, 16. veri günü çekilince not ilk kez geldi: “bekleyen” durumunda satır yok. Operasyon uzmanı bunu tek günlük bir durum sandı ve “izle” dedi. 18’i sabahı not ikinci kez gelince öneriyi onayladı. 16 ve 17. veri günleri “eksik” oldu, yeniden çekim aynı gün 14.00’te tamamlandı. Model hiçbir günü kendisi “eksik” yapmaz, yeniden çekim başlatmaz.
2. Hata metnini sade dile çevirme. Kaynağın teknik hata mesajından “anahtarın süresi dolmuş olabilir, hesabı yöneten kişinin yenilemesi gerekir” gibi bir öneri çıkarır. Mesajın içindeki anahtar ve hesap bilgisi modele gitmeden maskelenir.
3. İncelemedeki satır için katalog eşleşmesi önerisi. 3. veri günündeki iki yeni ürün kodu için katalogdan aday ürün önerir. Operasyon uzmanı onaylarsa eşleşme sözlüğe yazılır, aynı kod bir daha geldiğinde model çağrılmaz.

Dürüst olayım: “bekleyen durumu sıfır” kontrolü bir kural olarak da yazılabilirdi, önceden kimse düşünmemişti. Olaydan sonra kural oldu, o kontrol için artık yapay zekâ gerekmiyor. Değeri, henüz kimsenin kural yazmadığı yerde not düşmesinde.

Modele hiçbir satır yetki filtresinden geçmeden gitmez. Anormallik notu için yalnız sayılar ve dağılımlar gider, sipariş satırları gitmez. Katalog önerisi için ürün kodu ve ürün adı gider. Müşteri adı, adresi ve telefonu hiçbir durumda modele gönderilmez. KVKK, kişisel verinin işlendiği amaçla bağlantılı, sınırlı ve ölçülü işlenmesini istiyor (md. 4/2-ç). Kişisel veriyi yurt dışındaki bir yapay zekâ servisine göndermek KVKK md. 9’a girer (7499 sayılı Kanun md. 34 ile değişik), bu tasarım göndermiyor. Maddeleri 15 Ekim 2026’da mevzuat.gov.tr’deki güncel metinden okudum. Hukuki görüş vermiyorum, hangi alanın modele gittiğini ilk adımın çıktısında yazılı veririm.

Excel Power Query ya da tek seferlik indirme yetiyorsa

Excel’in Power Query aracı bir API’ye bağlanıp belirli aralıklarla yenilenebilir. Aşağıdakileri 16 Ekim 2026’da Microsoft’un ve Google’ın resmî belgelerinden okudum.

Yettiği yerler:

• Power Query’nin Web bağlayıcısı Excel’de bulunur, API anahtarıyla çalışan kaynaklar için “Web API” kimlik türünü sunar, istek başlığı eklemeye de izin verir (Microsoft Learn).
• Bağlantı özelliklerinden “her n dakikada yenile” ve “dosya açılırken yenile” seçilebilir (Microsoft Destek).
• Google Sheets tarafında Apps Script saat tetikleyicisi bir betiği her gün çalıştırır. Başarısız çalışmada ekranda uyarı çıkmaz, sahibine e-posta gider (Google).

Durduğu yerler:

• Sayfalama çoğu zaman elle yazılır. Microsoft’un bağlayıcı geliştirme eğitimi, sayfalama biçiminin API’den API’ye değiştiğini ve çoğu bağlayıcının kendine özel mantık gerektirdiğini yazıyor. Sayfalamayı Power Query’nin kendisinin yaptığı yer, OData.Feed tabanlı bağlayıcılar (Microsoft Learn, TripPin 5 - Paging).
• Yenileme Excel’in içinde çalışır. Bu benim çıkarımım, Microsoft sayfası ayrıca yazmıyor: dosya sabah kimsenin bilgisayarında açık değilse 08.00’de çalışacak bir şey yoktur.
• Kayıt tutmaz. Bu da benim değerlendirmem: sorgu her yenilemede tabloyu kaynaktan yeniden kurar. “Dün kaç satır geldi, kaçı zaten vardı, hangi gün eksik” sorusunun sorguda karşılığı yok.
• Apps Script’in saati ve süresi sınırlı. 09.00’a kurulan tetikleyici için Google 09.00 ile 10.00 arasında bir saat seçer, sonra onu sabit tutar. Bir çalışma en çok 6 dakika sürer, Google kotaların haber vermeden değişebileceğini yazıyor (Google).

Veriye ayda bir bakıyorsanız ya da tek kaynağınız ve onu her sabah kendisi kontrol eden tek kullanıcınız varsa bu uygulamayı yaptırmanızı önermem. Panelden indirme, Power Query ya da Apps Script yeter.

Nasıl başlanır, veri ve kod kimin?

İlk adımda bugün indirdiğiniz raporlara, birleştirdiğiniz Excel dosyasına ve kaynakların API belgelerine bakarız. Çıktısında çekim işlerini, pencereleri, kayıt anahtarlarını, hata ve bildirim kurallarını, rol listesini, ilk sürümün kapsamını ve tahmini süresini yazılı veririm. İlk otomasyonu en karmaşık süreçten seçmem, bu yüzden ilk sürümü tek kaynakla, çoğu zaman en çok sipariş gelen pazaryeriyle sınırlarım. İkinci kaynağın ve anormallik notunun sırası ve takvimi ilk adımda yazılı belirlenir. Önceki ayların birleştirilmiş Excel’i bir kez geçmiş veri olarak alınabilir ya da kaynak izin veriyorsa yeniden çekimle doldurulabilir, kapsamı ilk adımda yazılı belirlenir.

Uygulama şirketiniz adına açılabilen bir sunucuda (VPS) çalışır. Veri sizindir, istediğiniz zaman Excel ya da CSV olarak alırsınız. Küçük ve orta ölçekli bir ekipte kullanıcı başına lisans yok, maliyet sunucunun aylık ücreti ve bakımdan oluşur. Kaynak kodun tamamı sizin erişiminizdeki bir depoda, çalıştırma talimatı, bağımlılık listesi ve bilinen sınırlar listesiyle durur. Anahtarlar ve kaynak hesapları sizin adınıza açılır. Sipariş verisi kişisel veri taşıdığı için erişim, güvenlik, barındırma ve bakım gereksinimlerini başlangıçta ayrıca değerlendiririm.

Kaynak API’sini değiştirirse ne olur? Çekim kaydı ve gün durumu değişikliği aynı sabah görünür kılar, geçmiş veri olduğu gibi kalır. Uyarlamanın kimin tarafından ve hangi sürede yapılacağı ilk adımda yazılı belirlenir.

Son iki haftada indirdiğiniz birkaç raporu, müşteri adlarını maskeleyerek iletişim sayfasından gönderin. İlk görüşmede hangi kaynağın API’si olduğuna, aynı satırın bugün iki kez sayılıp sayılmadığına ve eksik bir günü nasıl fark ettiğinize bakarız.

Sıkça Sorulan Sorular

Kaynağın API’si yoksa ne yapılabilir?

Önce kaynağın yetkili dosya dışa aktarımına bakarım. Dosya düzenli geliyorsa satır kontrolü, mükerrer koruma ve geri almayla kontrollü Excel aktarım ekranından alınır. Bilgi yalnız bir web sayfasında duruyorsa web sitesinden Excel’e veri çekme sayfasında anlattığım yol değerlendirilir. Erişim yöntemi doğrulanmadan otomatik çekim sözü vermem.

Kaynak değişikliği anında bildirebiliyorsa yine her sabah çekmek gerekir mi?

Anlık bildirim (webhook) hızlıdır ama bildirim kaçabilir: alıcı o an kapalıysa ya da kaynak tekrar göndermiyorsa satır hiç gelmez. Anlık bildirim kullanılsa bile her sabahki kontrol çekimi kaçanı gün durumunda görünür kılar. Hangisinin kullanılacağı kaynağın imkânına göre ilk adımda belirlenir.

Zaten pazaryeri entegratör yazılımım var, neden ayrı uygulama?

Entegratörünüz siparişi ve stoku yönetiyor, ihtiyacınız olan raporu da veriyorsa ayrı uygulama gerekmez. Ayrım iki yerde başlar: entegratörün dışında kalan bir kaynağın (kargo firması, kur, ödeme raporu) aynı tabloya girmesi gerektiğinde ve “dün kaç satır geldi, hangi gün eksik, aynı satır iki kez sayıldı mı” sorusuna kayıtla cevap istendiğinde. Entegratörün API sunup sunmadığına ilk adımda bakarım.