سامانه انطباق با قوانین مالیاتی
نرمافزاری که با قانون سروکار دارد، یک ویژگی دارد که بقیهٔ نرمافزارها ندارند: منطق کسبوکارش را کس دیگری تعیین میکند و بدون هماهنگی با شما عوض میکند.
بخشنامهای صادر میشود، نرخی تغییر میکند، آستانهای جابهجا میشود — و سامانهٔ شما از فردا غلط محاسبه میکند.
این تنها ویژگی، معماری چنین سامانهای را از پایه متفاوت میکند.
اشتباه پایه: قانون در کد
کاری که در بیشتر سامانهها انجام میشود این است: نرخها و آستانهها و شرطها مستقیم در کد نوشته میشوند.
نتیجهاش دو مشکل است. اول اینکه هر تغییر قانون، یک انتشار نسخهٔ نرمافزاری لازم دارد — با همهٔ زمان و ریسکش، در حالی که مهلت قانونی اغلب کوتاه است.
دوم و بدتر: سامانه نمیتواند گذشته را درست حساب کند. اگر نرخ را در کد عوض کنید، محاسبهٔ مجدد فاکتور پارسال هم با نرخ امسال انجام میشود. در حسابرسی، این خطای جدی است.
قواعد باید داده باشند
اصل اصلی این حوزه: قواعد را در پایگاه داده نگه دارید، نه در کد.
هر قاعده دستکم اینها را دارد:
- شناسه و شرح.
- بازهٔ اعتبار: از چه تاریخی تا چه تاریخی.
- شرط اعمال: چه نوع مؤدی، چه نوع کالا، چه محدودهای.
- محاسبه: نرخ، آستانه، فرمول.
- مرجع: شمارهٔ بخشنامه یا مادهٔ قانونی.
بند بازهٔ اعتبار، مهمترین است. با آن، محاسبهٔ هر سند بر اساس قواعدی انجام میشود که در تاریخ همان سند معتبر بودهاند — نه قواعد امروز. این تفاوت بین سامانهای که در حسابرسی قابل دفاع است و سامانهای که نیست.
و بند مرجع را جدی بگیرید. وقتی کسی میپرسد «چرا این عدد؟»، جواب باید شمارهٔ بخشنامه باشد، نه «سامانه اینطور حساب کرده».
هر محاسبه باید قابل توضیح باشد
در نرمافزار مالیاتی، خروجی درست کافی نیست. باید بتوانید نشان دهید چطور به آن رسیدهاید.
یعنی سامانه علاوه بر عدد نهایی، باید مسیر محاسبه را ذخیره کند: کدام قواعد اعمال شدند، با چه مقادیری، به چه ترتیبی، و نتیجهٔ هر مرحله چه بود.
سه کاربرد دارد و هر سه ضروریاند:
در حسابرسی. مؤدی یا ممیز میپرسد این عدد از کجا آمد.
در پشتیبانی. کاربر میگوید عدد اشتباه است. بدون مسیر محاسبه، بررسی یعنی اجرای دستی همان محاسبه و مقایسه — ساعتها کار.
در خود توسعه. وقتی قانون عوض میشود و میخواهید بدانید کدام اسناد تحت تأثیرند.
این را از ابتدا در طراحی بگذارید. افزودنش بعداً یعنی بازنویسی موتور محاسبه.
اتصال به سامانههای حاکمیتی
بخشی که در ایران بیشترین زمان و کمترین قابلیت پیشبینی را دارد.
چند واقعیت که بهتر است از ابتدا در برنامه باشند:
مستندات ناقصاند و نمونهٔ واقعی نایاب. بخش زیادی از کار، کشف رفتار واقعی سرویس است، نه پیادهسازی مستندات.
فرایند اداری دریافت دسترسی، هفتهها طول میکشد و در دست شما نیست. این را بهعنوان قلم زمانی مستقل و موازی با توسعه برنامهریزی کنید.
در روزهای پایان مهلت، سرویس کند یا در دسترس نیست. پس ارسال باید کار پسزمینه با تلاش مجدد باشد، نه چیزی که کاربر منتظرش بماند.
قالبها بدون اطلاع قبلی تغییر میکنند. سامانه باید خطای قالب را تشخیص دهد و هشدار بدهد، نه اینکه بیصدا رد شود.
و هر ارسال باید idempotent باشد. ارسال دوبارهٔ یک سند در شرایط تایماوت، نباید سند تکراری بسازد. جزئیاتش در کارهای پسزمینه و الگوهای اتصال در یکپارچهسازی حسابداری و مالیات آمده.
دستیار قوانین، جایی که هوش مصنوعی کمک میکند
کاربرد واقعی و آزمودهای در این حوزه هست: پیدا کردن پاسخ در انبوه قوانین و بخشنامهها.
حجم مقررات مالیاتی زیاد است، لایهلایه، و بخشنامهها همدیگر را اصلاح و نقض میکنند. کارشناسی که میخواهد بداند در وضعیت مشخصی کدام قاعده حاکم است، ساعتها میگردد.
سامانهٔ پرسش و پاسخ مبتنی بر بازیابی — همان الگویی که در RAG چیست نوشتهایم — این را به دقیقهها میرساند. ساهوما دقیقاً همین کار را برای یک مؤسسهٔ حسابرسی انجام میدهد.
اما یک مرز مهم: چنین دستیاری باید منبع بدهد و تصمیم نگیرد. پاسخ بدون ارجاع به متن اصلی، در حوزهٔ حقوقی بیارزش و خطرناک است. کارشناس باید بتواند متن را ببیند و خودش قضاوت کند. سامانهای که جواب قطعی میدهد و منبع نمیدهد، مسئولیتی میآفریند که هیچکس نمیخواهد بپذیرد.
آنچه در برآورد جا میماند
- تقویم مهلتها و یادآوری. اغلب ارزشمندترین بخش از دید کاربر.
- بایگانی اسناد ارسالی با رسید. اثبات ارسال، بهاندازهٔ خود ارسال مهم است.
- اصلاحیه. سندی که ارسال شده و باید تصحیح شود، فرایند خودش را دارد.
- گزارش مغایرت بین آنچه شما ثبت کردهاید و آنچه سامانهٔ حاکمیتی نشان میدهد.
- چند شرکتی. حسابدار معمولاً چند شرکت را اداره میکند و باید بین آنها جابهجا شود — که همان مسئلهٔ چندمستأجری است.
- آموزش کاربر، که در این حوزه بخش قابل توجهی از هزینهٔ راهاندازی است.
نگهداری، که هزینهٔ اصلی است
نکتهای که در مذاکرهٔ قرارداد باید روشن باشد: در نرمافزار انطباق، نگهداری از ساخت گرانتر است.
هر سال قوانین عوض میشوند، هر سال قالبها تغییر میکنند، هر سال بخشنامههای جدید میآیند. سامانهای که دو سال بهروز نشود، بیفایده است.
پس اگر چنین پروژهای را برونسپاری میکنید، قرارداد پشتیبانی و بهروزرسانی قواعد را از ابتدا ببندید و زمان پاسخ به تغییر قانون را در آن بیاورید — نه فقط زمان پاسخ به باگ. تفاوتش را در SLA توضیح دادهایم.
اگر معماری را درست بسته باشید — قواعد بهعنوان داده با بازهٔ اعتبار — بیشتر این بهروزرسانیها ورود دادهاند، نه توسعه. و این تنها راهی است که هزینهٔ نگهداری چنین سامانهای قابل کنترل بماند.