রিপোর্ট অবশ্যই DLR-এর সাথে মিলতে হবে, সাবমিট সংখ্যার সাথে নয়

সাবমিট গণনা একটি মিথ্যা সান্ত্বনা দেয়: API বার্তাটি গ্রহণ করেছে, তাই সপ্তাহটি সফল বলে মনে হয়। কিন্তু ইনভয়েসের সপ্তাহে সেই সান্ত্বনা ভেঙে পড়ে। যে রিপোর্ট সাবমিটকে সাফল্য হিসাবে গণনা করে, তা DLR রসিদ, মাল্টি-সেগমেন্ট ট্রাফিকের জন্য ওয়ালেট ডেবিট এবং ওয়েবহুক অডিটের সাথে মিলবে না।

IOSOR এই নিয়মটি নিশ্চিত করে: রিপোর্ট এক্সপোর্ট ডেলিভারি রসিদ অনুসরণ করবে। সাবমিট করা, সারিবদ্ধ করা এবং সেন্ডের জন্য গ্রহণ করা কেবল অপারেশনের ট্র্যাকিং সংকেত। ডেলিভারড, ফেলড এবং আননোন হলো সেই কলাম যা নিয়ে ফাইন্যান্স এবং প্রোডাক্ট টিম আলোচনা করে।

সাবমিট করা একটি ট্র্যাকিং সংকেত, ক্লোজিং মেট্রিক নয়

সেন্ডের জন্য গ্রহণ করা প্রমাণ করে যে সিস্টেম কাজটি নিয়েছে। এটি প্রমাণ করে না যে হ্যান্ডসেটটি SMS পেয়েছে। যদি আপনার রিপোর্ট প্যাকেজের প্রধান KPI হয় সাবমিট সংখ্যা, তবে অজানা বা ব্যর্থতার হার বাড়লেই আপনি সাফল্যকে বাড়িয়ে দেখাবেন। প্রয়োজন হলে সাবমিটকে থ্রুপুট কলাম হিসাবে রাখুন — তবে কখনই ডেলিভারড এর বিকল্প হিসেবে নয়।

ক্লোজিং নিয়মটি তৈরি করুন: প্রথমে DLR কলামগুলি খুলুন — অজানা, ব্যর্থ, ডেলিভারড — এবং তারপর পরিমাণের জন্য সাবমিট সংখ্যা দেখুন। প্রোডাক্ট লঞ্চ রিভিউতেও একই ক্রম ব্যবহার করুন যাতে মার্কেটিং স্লাইডগুলি সপ্তাহের মাঝে সাফল্যের সংজ্ঞাকে পরিবর্তন করতে না পারে।

এক্সপোর্ট কলাম রসিদ অনুসরণ করে

স্কিমা স্পষ্টভাভ রসিদ স্টেটগুলো নির্ধারণ করে। ডেলিভারড হওয়ার জন্য একটি DLR প্রয়োজন। ব্যর্থ হওয়ার জন্য একটি টার্মিনাল ব্যর্থতার সংকেত প্রয়োজন। রসিদ না আসা পর্যন্ত অজানা অংশটি অজানাই থাকে — এটি কোনো নরম ডেলিভারড নয়। ইনভয়েস সপ্তাহে সফলতার ভেতরে অজানা অংশ লুকিয়ে রাখলে ডেলিভারি সংক্রান্ত বিতর্ক তৈরি হয়।

যখন সেগমেন্ট গণিত এবং বিলের হিসাব মেলে না, তখন রসিদ-সমর্থিত সারি এবং তাদের সেগমেন্ট সংখ্যা থেকে শুরু করুন — অনুমান করা গড় সেগমেন্ট দিয়ে সাবমিট মোট গুণ করে নয়। SMS ইনভয়েস সপ্তাহের সেগমেন্ট পথটি একই থাকে; রিপোর্টটি এখনও সাবমিটকে ডেলিভারড হিসাবে মানতে অস্বীকৃতি জানায়।

একই রসিদের বিরুদ্ধে ওয়েবহুক এবং লেজার মিলিয়ে নিন

লেজার এক্সপোর্টের বিরুদ্ধে ওয়েবহুক অডিট পুনর্মিলন হলো কীভাবে প্রমাণ করবেন যে রিপোর্টটি সঠিক। দৈনিক ওয়েবহুক লগ, DLR স্টেট এবং প্রিপেইড লেজার লাইন অবশ্যই একটি একই গল্প বলবে। যদি ওয়েবহুক ব্যর্থ দেখায় কিন্তু রিপোর্ট সাফল্য দেখায়, তবে রিপোর্টটি ভুল — এক্সপোর্ট ঠিক করুন, ওয়ালেট সমন্বয় করবেন না।

অডিট প্রক্রিয়া সহজ রাখুন: একদিনের জন্য ওয়েবহুক রসিদ, লেজার এক্সপোর্ট, রিপোর্ট প্যাক এবং বার্তা ID মিলিয়ে নিন। কোনো পার্থক্য থাকলে অপারেশনে পাঠান; ভুল তথ্য স্কিমা মালিকদের কাছে ফেরত পাঠান।

সাবমিট-ভিত্তিক ইনভয়েস সপ্তাহ প্রত্যাখ্যান করুন

যেকোনো বিলিং বা সাফল্য যা কেবল সাবমিট সংখ্যার ওপর ভিত্তি করে তৈরি, তা বন্ধ করতে হবে। প্যাকটি পুনরায় লিখুন যাতে ফাইন্যান্স টিম ডেলিভারড এবং অজানা অংশ আলাদা করতে পারে। যদি কোনো পার্টনার চুক্তিতে এখনও 'সফল API সাবমিট' লেখা থাকে, তবে সেই কথাটিকে DLR নোটে অনুবাদ করুন — ভুল শব্দগুচ্ছের সাথে মেলাতে কলাম পরিবর্তন করবেন না।

সম্পর্কিত অপারেশন পথ

• ডিএলআর ইনভয়েস সপ্তাহ: অজানা অংশ বিতরণ করা হয়নি
• প্রিপেইড ব্যালেন্সের সাথে দৈনিক ওয়েবহুক লগ পুনর্মিলন
• SMS ইনভয়েস সপ্তাহ: যখন সেগমেন্ট গণনা এবং বিল মিলে না

IOSOR দিয়ে শুরু করুন

IOSOR কনসোলে এই সপ্তাহের রিপোর্ট প্যাক খুলুন এবং নিশ্চিত করুন প্রতিটি হেডলাইন KPI DLR রসিদ — delivered, failed ও unknown — ভিত্তিক, submit বা API accept নয়। যদি চার্ট এখনও submit-কে সফলতা বলে, অর্থ বন্ধের আগে নাম বদলান বা সরান। একবার এক্সপোর্ট করুন এবং পণ্য ও ফাইন্যান্সকে একই রসিদ কলাম দিন।

IOSOR সারাংশ

রিপোর্ট DLR রসিদে বন্ধ হয়: delivered, failed ও unknown — submit-এ নয়। submit শুধু throughput; ডেলিভারি সত্য বা ইনভয়েস যুক্তি নয়।

করুন: রসিদ ক্ষেত্রে এক এক্সপোর্ট স্কিমা লক। করবেন না: পণ্য accept উদযাপন করুক আর ফাইন্যান্স failed DLR নিয়ে তর্ক করুক।