درس ۵ — گزارش وضعیت فاکتور الکترونیکی، و ستونی که نباید ادغام شود
این همان صفحهای است که واقعاً در آن زندگی خواهید کرد، و دلیل ساختهشدنش به این شکل، تیزترین تصمیم طراحی این ماژول است.
آن را از حسابداری ← گزارشها ← وضعیت فاکتور الکترونیکی (Accounting → Reporting → E-Invoicing Status) باز کنید. سه پرسش را در یک صفحه پاسخ میدهد: هر ماه چطور گذشت، چه چیزی گیر کرده، و چرا اسناد رد میشوند. به همین ترتیب سراغشان بروید.
ماهبهماه، چهار عدد: در دامنه، گزارششده، در حال ارسال و گزارشنشده. تعریفی که تمام وزن را بر دوش میکشد دومی است. «گزارششده» یعنی FTA آن را تسویه کرده است — نه اینکه شما فرستادهاید، نه اینکه ارائهدهندهتان تحویل گرفته است. اسنادی که به ASP سپرده شدهاند و هنوز نتیجهای ندارند در حال ارسال شمرده میشوند، در ستونی از آنِ خودشان، چون این ماژول گوشهٔ ۱ از مدل پنجگوشه است و تا ASP نگوید از نتیجه بیخبر است.
یک درصدِ واحد که ستون «در حال ارسال» را در خود ببلعد، هنگام قطعی ASP بالا میرود — دقیقاً وقتی که باید پایین بیاید. این جمله عدد میخواهد، پس ماهی با 400 سند در دامنه را ببینید، اول در یک ماه عادی و بعد در ماهی که ارائهدهندهتان دو روز قطعی داشته، آن هم درست روی اجرای صدور فاکتور پایان ماه که بیشتر فاکتورهای ماه در آن صادر میشود.
| عدد | یک ماه عادی | ماه قطعی دوروزهٔ ASP |
|---|---|---|
| در دامنه | 400 | 400 |
| گزارششده — FTA تسویه کرده | 384 | 260 |
| در حال ارسال — تحویلشده، بدون نتیجه | 8 | 136 |
| گزارشنشده | 8 | 4 |
| درصد صادقانه: گزارششده ÷ در دامنه | 96% | 65% |
| اگر «در حال ارسال» گزارششده حساب شود | 98% | 99% |
دو سطر آخر را کنار هم ببینید. عدد صادقانه از 96% به 65% میافتد و این حقیقت است: در ماه قطعی، برای 260 سند از 400 سند میتوانید تسویهٔ FTA را مستند کنید. عدد ادغامشده اما بالا میرود، از 98% به 99%، و دلیل بالارفتنش ناخوشایندتر از یک خطای گردکردن است. قطعی، خبر بد را همراه خبر خوب خفه میکند. هیچ نتیجهای اصلاً نمیرسد، پس رد شدنهایی که معمولاً در گزارشنشده فرود میآمدند آنها هم در در حال ارسال نشستهاند — و به همین دلیل «گزارشنشده» از 8 به 4 میافتد. پس معیاری که اسناد در حال ارسال را جذب کند دقیقاً وقتی بهترین چهرهاش را نشان میدهد که کمترین دانش را دارد، و در بدترین ماه سالتان 99% سبز اعلام میکرد.
پنل دوم صف تلاش مجدد است: چه چیزی در انتظار است، چه مدت انتظار کشیده، و با رنگ قرمز، چه چیزی دیگر متوقف شده است. آن رنگ کار واقعی میکند. سندی که دیگر هیچکس آن را تلاش نمیکند، تا چیزی این را نگوید، دقیقاً شبیه سندی است که هنوز در صف است — همان وضعیت، همان سن، همان ردیف — و تفاوتشان این است که سامانه رویش کار میکند یا منتظر شماست.
پنل سوم دلایل رد شدن است، بر پایهٔ علت گروهبندیشده و بر پایهٔ فراوانی مرتبشده. همین ترتیب، بینش ماجراست: چهل رد شدن با یک علت، مشکلی پیکربندی است که همین بعدازظهر حل میشود، اما چهل رد شدن با سیونه علت، یک برنامهٔ کیفیت داده است. این پنل پیش از آنکه حتی یک سند را باز کنید میگوید کدامش را دارید. کل گزارش را با دکمهٔ مربوطه به XLSX خروجی بگیرید؛ برگه از تاریخهای روی صفحه پیروی میکند، پس اول بازه را تنظیم کنید و بعد خروجی بگیرید.
حالا برویم سراغ حادثه، چون همهٔ اینها فقط زیر فشار زمان معنا پیدا میکند. سهشنبه 8 دسامبر، 09:00. یک اجرای صدور فاکتور پروژه 96 فاکتور ثبت میکند؛ هر 96 سند تولید و اعتبارسنجی و صف میشوند و توزیعکننده برشان میدارد. تا 09:20 صف تلاش مجدد 96 سند در انتظار و 0 متوقف نشان میدهد. پرسشی که کل صبح شما را تعیین میکند این است که مشکل از ارسال است یا از اسناد — و از همین یک صفحه میتوانید پاسخش را بدهید.
| نشانه | خرابی ارسال — ASP | مشکل داده — اسناد |
|---|---|---|
| کدام اسناد | هرچه در آن بازه صف شده، بیتوجه به مشتری | زیرمجموعهای با یک وجه مشترک: یک مشتری، یک کالا، یک رفتار مالیاتی |
| کجا نشستهاند | صف تلاش مجدد، در انتظار، با سنی که با هم بالا میرود | Rejected / Failed، هرکدام با یک دلیل |
| پنل دلایل رد شدن | خالی یا بدون تغییر — چون هیچ نتیجهای نمیرسد | یک علت در صدر، با شمار بالارونده |
| ستون در حال ارسال | بهشدت بالا میرود | تقریباً عادی |
| ستون گزارششده | از آغاز حادثه ثابت | همچنان بالا میرود |
| چه چیزی حلش میکند | هیچچیز درون Odoone؛ ارائهدهنده سرویس را برمیگرداند و نردبان صف را خالی میکند | یک تغییر پیکربندی یا داده، بعد تلاش مجدد |
| اشتباهی که نباید کرد | زدن تلاش مجدد، که شمارندهها را بازنشانی میکند و چیزی را عوض نمیکند | زدن تلاش مجدد پیش از برطرفکردن علت |
آن سهشنبه در عمل اینطور تمام میشود. هر 96 سند در صفاند، هیچ دلیل رد شدنی نمیرسد و ستون «گزارششده» از 09:00 ثابت مانده است — این یعنی ارسال، و درون Odoone کاری نیست جز اینکه به کسبوکار بگویید فاکتورها دیر شدهاند نه گم. روی نردبان درس ۳ این دسته تلاشهایش را در 16:45 تمام میکند و بهعنوان متوقف قرمز میشود. ارائهدهنده در 18:10 بازگشت سرویس را تأیید میکند. تلاش مجدد را میزنید، شمارندهها بازنشانی میشوند و 84 سند ظرف یک ساعت از صف بیرون میروند. آن 12 سند باقیمانده در Rejected / Failed زیر یک علت واحد فرود میآیند — نشانی مشتری که نقطهٔ دسترسی نپذیرفته، روی فاکتورهایی که از بررسیهای خودتان گذشته بودند چون کسی آن قاعدهٔ فیلد الزامی را بایگانی کرده بود — که از اول یک مشکل داده بود پنهانشده پشت یک مشکل ارسال. قاعده را برمیگردانید، 12 مخاطب را اصلاح میکنید، روی همان 12 سند تلاش مجدد میزنید و ماه با 96 از 96 بسته میشود.
یک محدودیت عملی را هم در برنامهتان بگنجانید: راهنما تلاش مجدد (Retry) را بهعنوان دکمهای در زبانهٔ UAE E-Invoicing روی فاکتور و روی سند مستند کرده و از تلاش مجدد گروهی چیزی نگفته است. پاسخ به حادثه را طوری طراحی نکنید که وجود چنین چیزی را فرض بگیرد — و این دلیل خوبی است برای اینکه اجراهای صدور فاکتور را در اندازهای نگه دارید که یک نفر بتواند از پسش برآید، و دلیل بهتری برای اینکه بهجای دوبارهزدن دکمهها علتها را برطرف کنید.
گزارش سالم در چهار سطر: در حال ارسال کوچک است و سنش با ساعت اندازه گرفته میشود نه با روز؛ شمار قرمزِ متوقف صفر است؛ دلایل رد شدن دنبالهای بلند است بدون یک علت غالب؛ و مجموع گزارششده و در حال ارسال و گزارشنشده با در دامنه میخواند، و گزارششده تنها عددی است که برای کسی میخوانید. بررسی روزانه همین چهار سطر است و پنج دقیقه طول میکشد.
شکل شکست اینجا اصلاً فنی نیست — جملهٔ «ما 99% منطبق هستیم» در بستهٔ هیئتمدیره است که کسی با جمعکردن دو ستون حسابش کرده چون منطقیتر به نظر میرسیده. اگر از شما یک عدد خواستند، درصد صادقانه را بدهید و شمار «در حال ارسال» را کنارش بگذارید. دو عدد که یکیشان اعتراف به ندانستن است، از یک عدد که هنگام خرابشدن اوضاع نمیتواند پایین بیاید بهتر است.
ایدهٔ ماندگار این درس: «در حال ارسال» خطای گردکردن نیست. فاصلهٔ میان دانستن و امیدواربودن است، و تنها ستونی است که هنگام قطعی راست میگوید.