يجب أن تطابق التقارير تقارير التسليم DLR وليس أعداد الإرسال

تعطي أعداد الإرسال شعوراً زائفاً بالارتياح: لقد قبلت واجهة البرمجة الرسالة، لذا فإن الأسبوع 'نجح'. يتلاشى هذا الارتياح عند حلول أسابيع الفوترة. التقرير الذي يحسب عمليات الإرسال كنجاح سيتعارض حتماً مع إيصالات DLR، وسحوبات المحفظة لحركة المرور متعددة الأجزاء، ومراجعات الويب هوك.

تفرض IOSOR القاعدة بصرامة: صادرات التقارير تتبع إيصالات التسليم. تظل حالات تم الإرسال، قيد الانتظار، وتم القبول للإرسال مجرد مؤشرات تشغيلية أولية. بينما تشكل حالات تم التسليم، فشل، وغير معروف الأعمدة الحقيقية التي يناقشها فريقا المالية والمنتجات.

الإرسال مجرد مؤشر أولي وليس مقياساً للإغلاق

يثبت قبول الإرسال أن المسار استلم المهمة فقط، لكنه لا يثبت وصول الرسالة إلى جهاز المستخدم. إذا كان مؤشر الأداء الرئيسي لتقاريرك ينظر إلى عمليات الإرسال، فسوف تبالغ في تقدير النجاح كلما ارتفعت نسبة الحالات الفاشلة أو غير المعرفة. احتفظ بعمود الإرسال لمتابعة الأحجام إذا كان مفيداً — ولكن ليس كبديل للتسليم الفعلي.

قم بتدريب الفريق على طقوس الإغلاق: افتح أعمدة DLR أولاً — غير معروف، فشل، تم التسليم — ثم ألقِ نظرة على الإرسال لتقييم الحجم الكلي. تستخدم مراجعات إطلاق المنتجات نفس الترتيب حتى لا تعيد العروض التقديمية تعريف النجاح في منتصف الأسبوع.

أعمدة التصدير تتبع الإيصالات الرسمية

يحدد مخطط التصدير حالات الإيصالات بشكل صريح. يتطلب 'تم التسليم' وجود إيصال DLR مؤكد. يتطلب 'فشل' إشارة إخفاق نهائية. ويبقى 'غير معروف' كما هو حتى يصل الإيصال النهائي — ولا يعامل كتسليم ضمني. أسابيع الفوترة التي تخفي الحالات غير المعرفة داخل النجاح تتسبب في الخلافات الكلاسيكية حول الحصص غير المسلمة.

عندما تتعارض حسابات الأجزاء مع الفاتورة الفعلية، ابدأ من الصفوف المدعومة بالإيصالات وأعداد أجزائها — وليس من إجمالي الإرسال مضروباً في تقدير متوسط الأجزاء. يظل مسار أجزاء الرسائل متسقاً؛ بينما يرفض التقرير قاطعاً واعتبار الإرسال بمثابة تسليم.

مطابقة الويب هوك والسجل مقابل نفس الإيصالات

تعتبر مطابقة تدقيق الويب هوك مقابل تصدير السجل هي الطريقة الوحيدة لإثبات أن التقرير ليس مجرد افتراضات. يجب أن تسرد سجلات الويب هوك اليومية وحالات DLR وخطوط سجل الدفع المسبق نفس القصة. إذا أظهرت الويب هوك فشلاً بينما يظهر التقرير نجاحاً، فالتقرير خاطئ — قم بتعديل التصدير ولا تعبث بالمحفظة.

حافظ على جدول تدقيق منتظم: يوم واحد، إيصالات الويب هوك، تصدير السجل، حزمة التقارير، ومطابقة معرفات الرسائل. تُحال الفجوات إلى العمليات؛ وتُعاد النجاحات المبتكرة إلى مسؤولي المخطط.

رفض أسابيع الفوترة القائمة على أعداد الإرسال

يجب حظر أي إغلاق مالي يعتمد في فواتيره أو تقييماته على أعداد الإرسال فقط. أعد كتابة الحزمة بحيث تعتمد المالية على حصص التسليم والحالات غير المعرفة. إذا كان عقد الشريك ينص على 'إرسال ناجح عبر API'، فقم بترجمة ذلك إلى ملاحظات DLR — ولا تقم بتطويع الأعمدة لتناسب صياغات خاطئة.

مسارات العمليات ذات الصلة

• أسبوع الفوترة لـ DLR: حصة غير معروفة لم يتم تسليمها
• مطابقة سجلات الويب هوك اليومية مقابل الأرصدة المدفوعة مسبقاً
• أسبوع فاتورة الرسائل القصيرة: عندما تتعارض حسابات الأجزاء مع الفاتورة

ابدأ مع IOSOR

افتح حزمة تقارير هذا الأسبوع في وحدة تحكم IOSOR وتأكد أن كل مؤشر رئيسي يعتمد على إيصالات DLR — delivered وfailed وunknown — وليس على submit أو قبول API. إذا كان مخطط ما يزال يعدّ submit نجاحاً، أعد تسميته أو احذفه قبل إغلاق المالية. صدّر مرة واحدة وشارك أعمدة الإيصال نفسها بين المنتج والمالية.

خلاصة IOSOR

تُغلق التقارير على إيصالات DLR: delivered وfailed وunknown — لا على submit. الـsubmit لقياس الإنتاجية فقط، لا لحقيقة التسليم ولا لحجة الفاتورة.

افعل: مخطط تصدير واحد مربوط بحقول الإيصال. لا تفعل: المنتج يحتفل بالـaccept بينما المالية تناقش failed DLR.