پایش بدهی خطوط سازمانی همراه اول با API

پایش بدهی خطوط سازمانی را با یک حلقهٔ ساده شروع کنید: هر خط، یک استعلام، یک ردیف ذخیره‌شده. پیچیدگی واقعی بعد از آن شروع می‌شود، یعنی اینکه چند وقت یک‌بار بپرسید و با پاسخ چه کنید.

این مقاله برای تیمی است که شرکتش چند ده خط دائمی همراه اول به کارکنان داده و می‌خواهد بدون ورود دستی به پنل، بدهی را ببیند. فرض کنید یک شرکت ۴۰ خطی دارد و مالی می‌خواهد قبل از رسیدن صورتحساب ماهانه بداند کدام خط بالا می‌رود.

یک جدول، نه یک فایل اکسل

قدم اول فهرست خطوط است، با ستون‌هایی که بعداً کار می‌کنند: شمارهٔ خط، نام مسئول، مرکز هزینه، و تاریخ آخرین استعلام. شماره را در یک شکل نگه دارید. ورودی API استعلام قبض همراه اول شمارهٔ موبایل یازده‌رقمی با صفر ابتدایی است و در API ما ارقام فارسی و پیش‌شمارهٔ بین‌المللی پیش از ارسال یکدست می‌شوند؛ ولی اگر جدول خودتان هم از ابتدا یکدست باشد، شمارهٔ تکراری با دو شکل مختلف نمی‌سازید.

برای هر استعلام، دو ردیف تاریخچه بنویسید، نه یک ردیف که دائم بازنویسی شود:

بدون تاریخچه نمی‌توانید بگویید «این خط در دو هفته چقدر بالا رفت». فقط آخرین عدد را دارید.

هر بخش با تناوب خودش

میان‌دوره هر روز عوض می‌شود. پایان‌دوره در طول ماه تقریباً ثابت می‌ماند و فقط بعد از بسته‌شدن دوره جدید تغییر می‌کند.

به همین دلیل خواندن هر دو با یک تناوب پول را هدر می‌دهد. پیشنهاد من:

• میان‌دوره: هفته‌ای یک بار برای همهٔ خطوط، و روزانه برای خطوطی که از آستانه‌ای عبور کرده‌اند.
• پایان‌دوره: چند روز یک بار، یا فقط وقتی عدد میان‌دوره افتاد (علامتی که دوره عوض شده است).

اما چون هر فراخوان هر دو بخش را با هم برمی‌گرداند، عملاً نمی‌توانید فقط یکی را بخرید. پس تناوب را روی «چه وقت نیاز دارم عدد تازه ببینم» تنظیم کنید و تصمیم دیگری لازم نیست. نرخ هر فراخوان را در صفحهٔ تعرفه ببینید.

افت میان‌دوره یعنی دورهٔ تازه

الگویی که بهتر از هر آستانهٔ ثابتی کار می‌کند: اگر میان‌دورهٔ امروز از میان‌دورهٔ پریروز کمتر بود، احتمال بسیار زیاد دوره بسته شده و مبلغ قبلی به پایان‌دوره منتقل شده است. در این لحظه یک استعلام تازه از پایان‌دوره بگیرید و ذخیره کنید.

این یک قاعدهٔ تجربی منطقی است، نه تضمین رفتار اپراتور. من آن را به‌عنوان محرک «یک نگاه دوباره» به کار می‌برم، نه به‌عنوان حقیقت. تصمیم مالی را بر پایهٔ عدد خود پایان‌دوره بگیرید.

هشدار بدهید، ولی نه برای هر تغییر

وقتی خطوط زیاد می‌شوند، هشدار زیاد هم بی‌ارزش می‌شود. سه نوع هشدار کافی است:

1. مبلغ پایان‌دوره بالاتر از سقف تعریف‌شدهٔ شرکت برای آن نقش.
2. مبلغ میان‌دوره در هفتهٔ جاری بیش از دو برابر هفتهٔ قبل.
3. استعلام یک خط در چند نوبت پیاپی جواب معنادار نداده.

مورد سوم را جدی بگیرید. خطی که پاسخ نمی‌دهد ممکن است اعتباری باشد، اپراتورش عوض شده باشد، یا شماره را اشتباه ثبت کرده باشید. جلوی این سه حالت را با ستون «نوع خط» و «اپراتور بررسی‌شده» در جدول بگیرید.

تسویه با کارمند هنگام پایان همکاری

یکی از کاربردهای ملموس همین پایش، لحظهٔ تحویل خط است. اگر قبل از تحویل هر دو بخش را بخوانید، بدهی تا آن لحظه روشن است و بعداً با یک صورتحساب سنگین به حساب شرکت نمی‌نشیند.

اما یک احتیاط: میان‌دوره بعد از خواندن هم بالا می‌رود. اگر خط هنوز در دست کارمند است، عددی که امروز می‌خوانید تا فردا قدیمی است. تسویه را همان روز، با فاصلهٔ کوتاه از استعلام انجام دهید.

حریم خصوصی داده‌های ناوگان

شمارهٔ خط یک داده شخصی است، حتی وقتی خط سازمانی است، چون به یک آدم وصل است. چند قاعدهٔ ساده:

• در لاگ شماره را کامل ننویسید. بخش میانی را بپوشانید، مثل 0912***4567.
• تاریخچهٔ مبلغ را فقط برای مالی و مسئول مستقیم قابل‌دیدن کنید.
• وقتی کارمند می‌رود و خط بسته می‌شود، ردیف را ببندید، نه اینکه ماه‌ها استعلامش ادامه پیدا کند.

آنچه این روش نمی‌کند

پیش از هر چیز، سقف این روش را بدانید: استعلام قبض همراه اول فقط مبلغ و شناسه می‌دهد.

• مصرف و ریز مکالمات را نمی‌دهد. اگر می‌خواهید بفهمید چرا خطی بالا رفته، باید از پنل سازمانی اپراتور ریز را ببینید.
• خط اعتباری را پوشش نمی‌دهد. فقط خط دائمی صورتحساب دوره‌ای دارد.
• پرداخت انجام نمی‌دهد. شناسه‌های پرداخت را می‌گیرید و درگاه شما کار را تمام می‌کند.
• برای ایرانسل و رایتل این فراخوان کار نمی‌کند؛ هر کدام مسیر جدا دارند، مثل استعلام قبض ایرانسل.

نمونهٔ پیکربندی هشدار

برای شروع، سه مقدار را در یک فایل پیکربندی بگذارید تا بعداً بدون تغییر کد عوض شوند:

json { "finalTermCeiling": "مقدار سقف شرکت", "midTermWeeklyGrowthFactor": 2, "failedPollsBeforeAlert": 3 }

سقف را خود شرکت بر اساس نقش تعیین می‌کند. من عدد پیشنهادی نمی‌دهم چون به سیاست مالی هر سازمان بستگی دارد. ضریب رشد و تعداد دفعات ناموفق هم نقطهٔ شروع‌اند و بعد از یک دو ماه با دادهٔ خودتان تنظیم می‌شوند.

وقتی خطی جواب نمی‌دهد

سه دلیل رایج دارد و هر کدام راه جدا:

• خط اعتباری است. در جدول علامت بزنید و از پایش حذفش کنید.
• شماره اشتباه ثبت شده. ورودی نامعتبر پیش از فراخوان رد می‌شود و هزینه ندارد؛ فهرست را اصلاح کنید.
• اپراتور خط عوض شده. این خط باید برای سرویس اپراتور جدید ثبت شود، نه همین سرویس.

هر سه را با یک ستون «وضعیت پایش» نشان بدهید: فعال، متوقف‌شده یا نیازمند بررسی. به این ترتیب مالی نمی‌پرسد چرا خطی در گزارش نیست.

یک ماه اول را چطور اجرا کنید

از همهٔ خطوط شروع نکنید. ده خط را انتخاب کنید که مسئول‌شان را می‌شناسید و دو هفته فقط داده جمع کنید، بدون هشدار. بعد از دو هفته به جدول نگاه کنید: چه خطوطی نتیجه نمی‌دهند، میان‌دوره چقدر نوسان دارد و آستانه‌ها کجا معنا پیدا می‌کنند. بعد هشدار را روشن کنید و دسته‌دسته خطوط را اضافه کنید.

این روش آهسته‌تر به نظر می‌رسد ولی از ماه دوم سریع‌تر می‌شود، چون نصف مشکلات (شمارهٔ غلط، خط اعتباری، اپراتور اشتباه) در همان ده خط اول معلوم می‌شوند و فهرست اصلی تمیز وارد می‌شود. فرض کنید ناگهان ۴۰ خط را وارد کنید و ده تایش خطا بدهد؛ حالا باید در میان هشدارها دنبال ریشه بگردید.

پیشنهاد من

یک جدول تاریخچه، تناوب مستقل برای هر بخش، سه هشدار ساده و پوشاندن شماره در لاگ. با همین چهار تصمیم، پایش ناوگان ۴۰ خطی از یک کار دستی ماهانه به یک گزارش خودکار تبدیل می‌شود. جزئیات فراخوان و خروجی را در مستندات API ببینید.