رپورٹس کا DLR سے مطابقت رکھنا ضروری ہے، سبمٹ کی تعداد سے نہیں

سبمٹ شدہ کی تعداد تسلی بخش لگتی ہے: API نے پیغام قبول کر لیا، لہذا ہفتہ کام کر گیا۔ لیکن یہ تسلی انوائس کے ہفتے ٹوٹ جاتی ہے۔ وہ رپورٹ جو سبمٹس کو کامیا بی کے طور پر شمار کرتی ہے، DLR رسیدوں، ملٹی سیگمنٹ ٹریفک کے لیے والیٹ ڈیبٹ، اور ویب ہک آڈٹ کے ساتھ مختلف ہوگی۔

IOSOR اس اصول کو یقینی بناتا ہے: رپورٹ کے ایکسپورٹ ڈیلیوری کی رسیدوں کی پیروی کرتے ہیں۔ سبمٹ شدہ، قطار میں اور ارسال کے لیے قبول شدہ صرف آپریشنل ٹریکس رہتے ہیں۔ ڈیلیور شدہ، ناکام اور نامعلوم وہ کالم ہیں جن پر مالیات اور پروڈکٹ ٹیمیں بحث کرتی ہیں۔

سبمٹ شدہ ایک ٹریک ہے، حتمی میٹرک نہیں

ارسال کے لیے قبولیت صرف یہ ثابت کرتی ہے کہ سسٹم نے کام قبول کیا۔ یہ ثابت نہیں کرتا کہ ہینڈ سیٹ کو SMS موصول ہوا۔ اگر آپ کے رپورٹ پیک کا اہم KPI سبمٹس ہے، تو جب بھی نامعلوم یا ناکام کا تناسب بڑھے گا آپ کامیابی کو بڑھا چڑھا کر پیش کریں گے۔ اگر مفید ہو تو سبمٹ کو تھرو پٹ کالم کے طور پر رکھیں — لیکن اسے کبھی ڈیلیور شدہ کے متبادل کے طور پر استعمال نہ کریں۔

انوائس کی بندش کا طریقہ مقرر کریں: پہلے DLR کالم کھولیں — نامعلوم، ناکام، ڈیلیور شدہ — پھر حجم دیکھنے کے لیے سبمٹس پر ایک نظر ڈالیں۔ پروڈکٹ لانچ کا جائزہ بھی اسی ترتیب سے لیں تاکہ مارکیٹنگ سلائیڈز ہفتے کے وسط میں کامیابی کی تعریف تبدیل نہ کر سکیں۔

ایکسپورٹ کالم رسیدوں کی پیروی کرتے ہیں

ایکسپورٹ اسکیما رسید کی حالتوں کو واضح طور پر بیان کرتا ہے۔ ڈیلیور شدہ کے لیے DLR کی ضرورت ہوتی ہے۔ ناکام کے لیے ناکامی کے سگنل کی ضرورت ہوتی ہے۔ نامعلوم اس وقت تک نامعلوم رہتا ہے جب تک کہ رسید موصول نہ ہو جائے — یہ کوئی عارضی ڈیلیور شدہ نہیں ہے۔ انوائس کے ہفتے جو کامیابی کے اندر نامعلوم کو چھپاتے ہیں، وہ جھگڑے کا باعث بنتے ہیں۔

جب سیگمنٹ کا حساب اور بل آپس میں نہ ملیں، تو رسید سے تصدیق شدہ قطاروں اور ان کے سیگمنٹ کی تعداد سے شروعات کریں — نہ کہ سبمٹ کے کل اعداد و شمار کو اوسط اندازے سے ضرب دے کر۔ SMS انوائس ہفتہ کے سیگمنٹ کا طریقہ یکساں رہتا ہے؛ لیکن رپورٹ سبمٹ کو ڈیلیور شدہ ماننے سے انکار کرتی ہے۔

ویب ہکس اور لیجر کو انہی رسیدوں کے مطابق ملائیں

لیجر ایکسپورٹ کے مقابلے میں ویب ہک آڈٹ کی مفاہمت وہ طریقہ ہے جس سے آپ ثابت کرتے ہیں کہ رپورٹ محض فرض نہیں ہے۔ روزانہ کے ویب ہک لاگز، DLR سٹیٹس، اور پری پیڈ لیجر کی لائنز کو ایک ہی کہانی بیان کرنی چاہیے۔ اگر ویب ہکس ناکامی ظاہر کرتے ہیں جبکہ رپورٹ کامیابی دکھاتی ہے، تو رپورٹ غلط ہے — ایکسپورٹ کو درست کریں، والیٹ کو 'ایڈجسٹ' نہ کریں۔

آڈٹ کے عمل کو سادہ رکھیں: ایک دن، ویب ہک رسیدیں، لیجر ایکسپورٹ، رپورٹ پیک، اور میسج IDs کا موازنہ کریں۔ فرق آپریشنز ٹیم کو بھیجیں؛ جعلی کامیابی واپس اسکیما کے مالکان کو بھیجیں۔

سبمٹ پر مبنی انوائس کے ہفتوں کو مسترد کریں

ہر وہ کلوزنگ جو صرف سبمٹ کی تعداد پر بل بناتی ہے یا کامیابی کا جشن بناتی ہے، اسے روکا جائے۔ پیک کو دوبارہ ترتیب دیں تاکہ مالیات کی ٹیم ڈیلیور شدہ اور نامعلوم حصے کو الگ کر سکے۔ اگر کسی پارٹنر کے معاہدے میں ابھی بھی 'کامیاب API سبمٹس' لکھا ہے، تو اس کا DLR نوٹس میں ترجمہ کریں — غلط الفاظ سے میل کھانے کے لیے کالم نہ موڑیں۔

متعلقہ آپریشنل راستے

• DLR انوائس ہفتہ: نامعلوم حصہ ڈیلیور نہیں ہوا
• پری پیڈ بیلنس کے ساتھ روزانہ ویب ہک لاگز کی مفاہمت
• SMS انوائس ہفتہ: جب سیگمنٹ کا حساب اور بل آپس میں نہ ملیں

IOSOR کے ساتھ شروع کریں

IOSOR کنسول میں اس ہفتے کا رپورٹ پیک کھولیں اور یقینی بنائیں کہ ہر ہیڈ لائن KPI DLR رسیدوں — delivered، failed اور unknown — پر ہے، submit یا API accept پر نہیں۔ اگر چارٹ اب بھی submit کو کامیابی سمجھے تو فنانس بند سے پہلے نام بدلیں یا ہٹائیں۔ ایک بار ایکسپورٹ کریں اور پروڈکٹ و فنانس کو وہی رسید کالم دیں۔

IOSOR خلاصہ

رپورٹس DLR رسیدوں پر بند ہوتی ہیں: delivered، failed اور unknown — submit پر نہیں۔ submit صرف throughput ہے، ڈیلیوری سچ یا انوائس دلیل نہیں۔

کریں: رسید فیلڈز پر ایک ایکسپورٹ اسکیمہ لاک۔ نہ کریں: پروڈکٹ accept منائے اور فنانس failed DLR پر جھگڑے۔