IOSOR

IOSOR Rehber

Raporlar gönderim sayılarına değil DLR teslimatlarına uymalıdır

Gönderilen mesaj teslim edilmiş demek değildir. Finans ve ürün rapor dışa aktarımları DLR alındılarını izlemelidir — faturalandırmayı asla yalnızca kabul toplamlarına dayandırmayın.

Gönderim sayıları yanıltıcı bir rahatlık sağlar: API mesajı kabul etmiştir ve haftalık işlem başarılı görünür. Ancak bu rahatlık fatura haftalarında son bulur. Gönderimleri başarı olarak sayan bir rapor; DLR alındıları, çoklu segment trafiğine ait bakiye düşüşleri ve webhook denetimleriyle çelişir.

IOSOR net bir kural uygular: Rapor dışa aktarımları teslimat alındılarını takip eder. Gönderildi, sırada ve gönderim için kabul edildi durumları yalnızca operasyonel süreç göstergeleridir. Teslim edildi, başarısız ve bilinmeyen sütunları ise finans ve ürün ekiplerinin üzerinde durması gereken temel alanlardır.

Gönderim sayısı bir süreç izidir, kapanış metriği değildir

Gönderim kabulü, sistemin işi devraldığını kanıtlar; ancak mesajın cihaza ulaştığını garanti etmez. Rapor paketinizin ana KPI değeri gönderim sayıları üzerine kuruluysa, başarısız veya bilinmeyen oranları arttığında başarıyı hatalı şekilde yüksek gösterirsiniz. Gönderim sayısını hacim takibi için bir sütun olarak tutun, ancak asla teslimat göstergesi olarak kullanmayın. Haftalık kapanış disiplinini oturtun: Önce DLR sütunlarını (bilinmeyen, başarısız, teslim edildi) inceleyin, ardından genel hacmi anlamak için gönderim sayılarına bakın.

Dışa aktarım sütunları alındı durumlarını izler

Dışa aktarım şeması alındı durumlarını açıkça tanımlar. Teslim edildi durumu bir DLR gerektirir. Başarısız durumu kesin bir başarısızlık sinyali gerektirir. Bilinmeyen durumu bir alındı ulaşana kadar bilinmeyen olarak kalır; örtülü bir teslimat sayılmaz. Bilinmeyen durumları başarı altında gizleyen fatura haftaları, teslim edilmeyen paylar konusunda tartışmalara yol açar. Segment hesaplaması ile fatura uyuşmadığında, ortalama tahminlerle çarpılan gönderim toplamlarından değil, alındı belgesiyle doğrulanan satırlardan ve segment sayılarından incelemeye başlayın.

Webhook ve defteri aynı alındılarla mutabakat edin

Webhook denetimlerinin ön ödemeli defter dışa aktarımlarıyla mutabakatı, raporun gerçekliğini kanıtlamanın yoludur. Günlük webhook günlükleri, DLR durumları ve ön ödemeli defter satırları aynı veriyi doğrulamalıdır. Webhook başarısız gösterirken rapor başarı gösteriyorsa rapor hatalıdır — bakiyeyi düzeltmeye çalışmayın, rapor dışa aktarımını düzeltin. Denetim sürecini rutin hale getirin: Bir günlük webhook alındılarını, defter dışa aktarımını ve rapor paketini alıp mesaj kimlikleriyle eşleştirin.

Gönderim bazlı fatura haftalarını reddedin

Yalnızca gönderim sayılarına dayanarak fatura kesen veya başarı kutlayan tüm kapanışlar engellenmelidir. Rapor paketini, finansın teslim edilen ve bilinmeyen payları analiz edeceği şekilde yeniden yapılandırın. Ortak sözleşmelerinde halen 'başarılı API gönderimi' ifadesi yer alıyorsa, bunu DLR notlarına dönüştürün ancak sütun yapılarını bozmayın.

İlgili operasyon yolları

IOSOR ile başlayın

IOSOR konsolunda bu haftanın rapor paketini açın ve her başlık KPI’sinin submit veya API accept değil, DLR makbuzlarına — delivered, failed ve unknown — dayandığını doğrulayın. Bir grafik hâlâ submit’i başarı sayıyorsa, finans kapanışından önce yeniden adlandırın veya kaldırın. Bir kez dışa aktarın; ürün ve finans aynı makbuz sütunlarını paylaşsın.

IOSOR özeti

Raporlar DLR makbuzlarıyla kapanır: delivered, failed ve unknown — submit ile değil. Submit yalnızca throughput içindir; teslimat gerçeği veya fatura argümanı değildir.

Yapın: makbuz alanlarına kilitli tek bir dışa aktarma şeması. Yapmayın: ürün accept kutlarken finans failed DLR tartışır.

Bu rehber yardımcı oldu mu?

İlgili rehberler