Network Marketing
Network Marketing Raporlama ve Entegrasyonlar
Rapor ve entegrasyon iki ayrı başlık değil, tek veri akışının iki yüzüdür. Bu sayfa verinin nereden geldiğini, hangi kararı desteklediğini, dışarı nasıl çıktığını ve hata olduğunda nasıl izlenebilir kaldığını anlatır.
Raporlama merkezi — genel bakis
Rapor ailelerinin, donem seciminin ve rol bazli kapsamin tek ekranda listelenmesi
Gerçek ürün ekranı bekleniyor — yayın izni onaylanınca bu alana yerleşecek.
Gerçek ürün ekranı bekleniyor.
Veriden karara iz
Bir aşama seçin: aynı kayıt kaynaktan başlayıp rapora, dış sisteme ve denetim izine kadar aynı hat üzerinde ilerler. Her aşamada kimin gördüğü ve hata durumunda ne olduğu ayrı tanımlanır.
Seçili aşama
01 · Kaynak olay
Sipariş, üyelik, statü, iade
Akış örnek çerçevedir. Hangi adımların kullanılacağı, hangi verinin dışarı çıkacağı ve hata davranışı proje kurgusunda tanımlanır.
Kaynak sistem / veri
Sipariş/e-ticaret akışı, üye kaydı, ağaç değişikliği, ödeme veya iade olayı.
Kim görür
Olayı yaratan kişi ve ilgili operasyon alanı görür.
Hangi karar için
Henüz karar yok; ham olay ilerideki tüm raporların girdisidir.
Veri yönü
Genelde içeri: dış kanaldan gelen olaylar da bu adımda sisteme girer.
Hata / istisna olursa
Olay hiç oluşmazsa rapor da oluşmaz. Bu yüzden kaynak sistemler tekil kayıt üzerinden bağlanır.
Rapor aileleri
Aşağıdakiler sabit ürün özelliği değil, kurguda tanımlanabilen görünüm aileleridir. Her ailenin ölçüsü hangi soruya cevap verdiğidir.
Üye ve rol
Kimler sistemde, hangi durumda ve hangi kapsamla?
Kayıt, durum değişimi ve yetki kapsamı görünümleri. Kurguda tanımlanan durumlara göre şekillenir.
Ağ ve kariyer
Ekip nasıl büyüdü, hangi koşullar karşılandı?
Sponsor/yerleşim yapısı ve kariyer koşullarının dönem içindeki durumu. Plan kurgusuna bağlıdır.
Sipariş ve hacim
Hangi sipariş hangi hacme, hangi bağlamda yazıldı?
Sipariş kayıtlarının hacme dönüşme yolu; dahil olmayan kayıtların sebebiyle listelenmesi.
Hakediş ve bonus
Bir satır hangi kuraldan ve hangi kaynaktan oluştu?
Bonus kalemlerinin kaynağa geri izlenmesi. Tutar örneği bu sayfada verilmez.
Dönem kapanışı
Dönem hangi adımda, neyi bekliyor?
Önizleme, onay ve arşiv aşamalarının durumu; kapanmış dönemde düzeltmenin ayrı kayıt olarak ele alınması.
Operasyon ve istisna
Hangi kayıt manuel incelemeyi bekliyor?
İade, mükerrer kayıt, eksik veri ve kural istisnası gibi başlıkların kuyruğu.
Entegrasyon sağlığı
Hangi aktarım başarısız, hangisi tekrar denendi?
Dış sistem olaylarının durumu, hata sebebi ve yeniden deneme geçmişi.
Aynı veri, farklı görünüm
Rapor çoğaltmak yerine kapsamı ayırıyoruz. Aynı kayıt, rolün veri kapsamına göre farklı yoğunlukta okunur.
Bayi
Sade ve onaylı sonuç: kendi dönem özeti, yetkili olduğu ekip görünümü. Yeniden hesap yapılmaz, ham veri açılmaz.
Operasyon
Durum ve istisna odaklı: bekleyen kayıt, hatalı aktarım, eksik eşleşme. Amaç raporu okumak değil, işi kapatmak.
Yönetim
Toplu görünüm, dönem karşılaştırması ve denetim izi. En geniş kapsam, aynı zamanda en çok iz bırakan erişim.
Gerçek ürün ekranı bekleniyor.
Bayi tarafında sade sonuç
Onaylanmış dönem sonucu ve ekip özeti; yeniden hesap yapılmadan okunur.
Gerçek ürün ekranı bekleniyor.
Operasyon tarafında bildirim
Bekleyen veya hatalı aktarım bildirimi, incelemeye giden yolla birlikte gösterilir.
Hangi kaydın sahibi kim?
Raporun tutarlılığı, her kaydın tek bir sahibinin olmasına bağlıdır. Aynı veri iki modülde ayrı ayrı güncelleniyorsa rapor değil, veri tanımı sorunludur.
Üye kaydı
Sahibi: üye yönetimi. Diğer modüller okur, kendi kopyasını ayrı güncellemez.
Sponsor / yerleşim
Sahibi: ağaç modülü. Değişiklik gerekçesiyle kaydedilir; raporlar bu kaydı referans alır.
Sipariş
Sahibi: sipariş/e-ticaret akışı. İptal ve iade de aynı kaydın devamıdır.
Hacim
Sahibi: hacim/atıf katmanı. Siparişten türetilir; siparişten bağımsız elle yazılmaz.
Kariyer / uygunluk
Sahibi: plan motoru. Dönem verisinden üretilir, ayrı bir gerçek değildir.
Hakediş
Sahibi: prim/bonus motoru. Onaylandıktan sonra kaynağı değişmeden okunur.
Dönem
Sahibi: dönem kapanış süreci. Rapor tarihleri bu tanıma bağlanır.
Entegrasyon logu
Sahibi: entegrasyon katmanı. İş verisi değil, akışın kendisinin kaydıdır.
Entegrasyon desenleri
Tek bir doğru yöntem yoktur. Aynı projede farklı akışlar farklı desenlerle çalışabilir; seçim veri hacmine, gecikme toleransına ve karşı tarafın yeteneğine bağlıdır.
API (istek/yanıt)
Uygun olabilir: Karşı sistem anlık ve kesin sonuç bekliyorsa; kayıt tekil ve sorgulanabilirse.
Riskli olabilir: Hedef yavaş veya erişilemezse kullanıcı akışını bekletir. Yoğun toplu veri için uygun değildir.
Webhook / olay bildirimi
Uygun olabilir: Bir şey olduğunda karşı tarafın haberdar olması yeterliyse; gecikmeye toleranslı akışlarda.
Riskli olabilir: Aynı olay iki kez ulaşabilir. Karşı tarafın tekrarlı bildirimi güvenle işleyebilmesi gerekir.
Zamanlanmış senkronizasyon
Uygun olabilir: Toplu ve düzenli aktarımlarda; gün sonu veya dönem sonu mutabakatında.
Riskli olabilir: İki çalışma arasında veri eskir. Kapanış anıyla çakışırsa yanlış dönem verisi taşınabilir.
Dosya / CSV dışa aktarım
Uygun olabilir: Tek seferlik analiz, mutabakat veya karşı tarafın arayüzü olmadığı durumlarda.
Riskli olabilir: Dosya sistem dışına çıkar; kapsam ve alan hassasiyeti ayrıca kontrol edilmelidir.
Hata ve yeniden deneme
Entegrasyonun kalitesi hata olmamasıyla değil, hata olduğunda ne yapıldığıyla ölçülür. Her istisnanın durumu, sebebi ve sonraki adımı görünür kalır.
Başarısız aktarım
Kayıt kaybolmaz. Durum, sebep ve deneme sayısıyla kuyrukta kalır; tanımlı sayıda otomatik tekrar sonrası manuel incelemeye düşer.
Mükerrer olay
Aynı olayın iki kez gelmesi beklenebilir bir durumdur. Tekil kimlik üzerinden ikinci kayıt yeni kayıt sayılmaz.
Geç gelen veri
Dönem kapandıktan sonra ulaşan kayıt sessizce geçmişe yazılmaz; hangi döneme yazılacağı kurguda karara bağlanır.
Yetkisiz erişim
Tanımsız kaynaktan gelen çağrı reddedilir ve kaydı tutulur. Reddedilen istek de bir olaydır.
Şema değişikliği
Karşı tarafın alan yapısı değiştiğinde akış hata verir. Beklenen davranış durmak ve bildirmektir, tahmin etmek değil.
Entegrasyon sagligi ve olay kuyrugu
Dis sistem aktarimlarinin durumu, hatali olaylar ve yeniden deneme akisinin izlenmesi
Gerçek ürün ekranı bekleniyor — yayın izni onaylanınca bu alana yerleşecek.
Entegrasyon sağlığı
Durum, sebep ve tekrar denemeyi tek yerde görmek
İstisna kuyruğunun operasyon tarafındaki karşılığı için yönetim paneli sayfasına da bakabilirsiniz.
Dış sistem sınırı
Aşağıdakiler bağlanabilir hedef sınıflarıdır; hazır ya da aktif bağlantı iddiası değildir. Hangi sistemin, hangi yönde ve hangi alanlarla bağlanacağı proje kapsamına göre belirlenir.
ERP
Stok, ürün ve cari tarafıyla eşleşme.
Muhasebe
Fatura ve finansal kayıt aktarımı.
Kargo / lojistik
Gönderi oluşturma ve durum dönüşü.
E-ticaret
Sipariş ve ürün verisinin ortak kayıtla hizalanması.
BI / veri ambarı
Analiz için düzenli veri aktarımı.
Ödeme
Tahsilat ve ödeme durumlarının izlenmesi.
Rapor erişimi ve dışa aktarma
Raporlama bir güvenlik başlığıdır. Kapsam, alan hassasiyeti ve dışa aktarma izni ayrı ayrı tanımlanır; rol tarafındaki ayrıntı için üye ve rol yönetimi sayfasına bakabilirsiniz.
Ekran erişimi ≠ export izni
Bir raporu ekranda görebilmek, aynı veriyi toplu olarak dışarı çıkarabilmek anlamına gelmez. İkisi ayrı tanımlanır.
Alan bazlı hassasiyet
Kişisel bilgi veya ödeme alanı gibi başlıklar rapor içinde ayrı ele alınabilir; kapsamı olan role bile kapalı olabilir.
Kapsam kuralı
Aynı rapor farklı rollerde farklı satır kümesi döndürür. Kapsam raporun değil, kullanıcının özelliğidir.
Dışa aktarım izi
Kimin hangi raporu hangi filtreyle dışarı aldığı kayıt altına alınabilir.
Export ve iz
Kim, hangi raporu, hangi kapsamla aldı
Dışa aktarım kaydı, veri sistemden çıktıktan sonra da soruya cevap verebilmeyi sağlar.
Disa aktarim ve erisim izi
Kim hangi raporu hangi kapsamla disa aktardi kaydinin izlenmesi
Gerçek ürün ekranı bekleniyor — yayın izni onaylanınca bu alana yerleşecek.
Ag ve donem raporu
Uye, hacim ve kariyer verisinin donem bazinda karsilastirmali okunmasi
Gerçek ürün ekranı bekleniyor — yayın izni onaylanınca bu alana yerleşecek.
Dönem görünümü
Ağ ve dönem verisinin birlikte okunması
Üye, hacim ve kariyer verisi ayrı raporlar olsa da aynı dönem tanımına bağlanır.
Denetim
Değişiklik izi raporun bir parçasıdır
Bir sonucun neden değiştiği, kaydın kendisi kadar önemlidir.
Denetim izi ve raporlama
Degisiklik gecmisi, kim/ne zaman/onceki-yeni deger ve rapor filtrelerinin izlenmesi
Gerçek ürün ekranı bekleniyor — yayın izni onaylanınca bu alana yerleşecek.
Bayi backoffice — donem raporu ve gecmis
Donem raporlarinin, gecmis kayitlarin ve ekip agacinin masaustunde incelenmesi
Gerçek ürün ekranı bekleniyor — yayın izni onaylanınca bu alana yerleşecek.
Bayi masaüstü
Saha tarafında daha geniş, ama yine kapsamlı
Masaüstünde geçmiş ve ekip görünümü açılır; kapsam yine kullanıcının yetkisiyle sınırlıdır.
Hangi soruya hangi rapor?
Rapor listesiyle değil, soruyla başlıyoruz. Aşağıdaki eşleşmeler kurgu için başlangıç çerçevesidir.
- Hangi sipariş hacme dahil olmadı?
- Sipariş ve hacim ailesi — dışlanan kayıtları sebebiyle listeleyen görünüm.
- Hangi üyelerin statü değişikliği bekliyor?
- Üye ve rol ailesi — durum geçişi bekleyen kayıtlar.
- Hangi bonus satırı hangi kaynaktan oluştu?
- Hakediş ve bonus ailesi — satırdan kaynağa geri iz.
- Hangi entegrasyon olayları hata verdi?
- Entegrasyon sağlığı — durum, sebep ve yeniden deneme geçmişi.
- Dönem neden kapanmıyor?
- Dönem kapanışı — bekleyen adım ve engelleyen istisna listesi.
- Bir bayi neden beklediği sonucu görmüyor?
- Ağ ve kariyer + hakediş — uygunluk koşulu ve atıf yolunun birlikte okunması.
- Aynı kayıt neden iki kez göründü?
- Operasyon ve istisna — mükerrer kayıt kuyruğu ve tekil kimlik kontrolü.
- Bu raporu dışarı kim aldı?
- Audit — dışa aktarım ve erişim izi.
Bu yaklaşım ne zaman işe yarar, ne zaman zorlaşır?
İşe yarayabilir
- Rapor ile dış sistem aktarımının aynı veri tanımından beslenmesi isteniyorsa.
- Bir sonucun kaynağına kadar izlenebilir olması bekleniyorsa.
- Entegrasyon hatalarının görünür bir kuyruğa düşmesi gerekiyorsa.
- Rapor erişimi ile dışa aktarma izninin ayrı yönetilmesi gerekiyorsa.
Zorlaşabilir
- Her modül kendi verisini ayrı tutarsa aynı soruya iki farklı cevap çıkar.
- Hangi kaydın sahibi hangi modül belirlenmezse düzeltmeler birbirini bozar.
- Entegrasyon yalnız 'çalışıyor/çalışmıyor' olarak izlenirse sebep kaybolur.
- Export izni ekran yetkisiyle birlikte verilirse veri kapsamı kontrolden çıkar.
Sık sorulanlar
Kısa yanıtlar
- Bu sayfada sabit bir rapor listesi vaat etmiyoruz. Rapor aileleri bir çerçevedir; hangi görünümlerin kurulacağı, hangi filtre ve kapsamla çalışacağı proje kurgusunda tanımlanır.
- Hayır. Sayfadaki ERP, muhasebe, kargo, BI gibi başlıklar bağlanabilir hedef sınıflarıdır; aktif ve hazır bir bağlantı iddiası değildir. Hangi sistemle hangi yönde çalışılacağı proje kapsamında belirlenir.
- Beklenen davranış kaybetmemektir. Başarısız kayıt durumu ve sebebiyle birlikte kuyrukta kalır, tanımlı sayıda yeniden denenir ve gerekirse manuel incelemeye düşer. Sessiz başarısızlık kabul edilmez.
- Tekil kimlik üzerinden kontrol edilir. İkinci bildirim yeni bir kayıt olarak işlenmez; bu, olay tabanlı entegrasyonlarda normal bir durumdur ve baştan hesaba katılır.
- Bayi tarafı sade ve onaylı sonuç görünümüdür: kendi dönem özeti ve yetkili olduğu ekip bağlamı. Ham veri, sistem geneli toplamlar ve dışa aktarım yönetim tarafında kalır.
- Hayır; bunu ayrı bir yetki başlığı olarak ele alıyoruz. Kapsam, alan hassasiyeti ve dışa aktarma izni ayrı tanımlanır. Rol tarafındaki ayrıntı için üye ve rol yönetimi sayfasına bakabilirsiniz.
Rapor ve entegrasyon kapsamını birlikte tanımlayalım
Hangi verinin nereden geleceğini, hangi raporun hangi kararı destekleyeceğini ve dış sistemlere hangi yönde akacağını proje kurgusunda netleştirelim.