هر چند ماه یک بار همین اتفاق تکرار میشود: مرکز تنظیم مقررات نسخه تازهای از دستورالعمل صدور صورتحساب الکترونیکی منتشر میکند، تیم مالی سراغ تیم فنی میرود، و تیم فنی باید یک سند صدوچند صفحهای را با پیادهسازی فعلی تطبیق دهد.
مسئله واقعی، خواندن سند نیست. مسئله این است که نرمافزار شما چقدر سریع و چقدر بدون ریسک خودش را با نسخه جدید تطبیق میدهد. این مقاله هر دو طرف ماجرا را پوشش میدهد: چه ساختاری در نسخه ۷.۹ دنبال شده، و چه معماریای باعث میشود نسخه بعدی برایتان دردسر نداشته باشد.
این سند دقیقاً چیست؟
«دستورالعمل صدور صورتحساب الکترونیکی» سند مرجع مرکز تنظیم مقررات نظام پایانههای فروشگاهی و سامانه مؤدیان است. هدف اعلامشده آن ایجاد وحدت رویه در صورتحسابهای الکترونیکی صادره و کاهش موارد خطاست؛ یعنی همان چیزی که در عمل تعیین میکند صورتحساب شما پذیرفته شود یا با خطای اعتبارسنجی برگردد.
سند با یک شناسه نسخهبندیشده منتشر میشود:
RC_IITP.IS_V7.9
│ │ │ └── شماره ویرایش
│ │ └───── Invoice Specification
│ └────────── Iranian Integrated Tax Platform
└────────────── Regulation Centerمهم: همیشه شماره ویرایش را مبنا قرار دهید، نه ماه انتشار. نسخهها گاهی با فاصله یک ماه منتشر میشوند و ارجاع به «دستورالعمل مردادماه» در مکاتبات فنی ابهام ایجاد میکند.
تاریخچه نسخهها؛ ریتم واقعی تغییرات
| ویرایش | زمان انتشار | حجم سند |
|---|---|---|
| V6.3 | اردیبهشت ۱۴۰۲ | — |
| V6.4 | خرداد ۱۴۰۲ | ۸۱ صفحه |
| V7.4 | مرداد ۱۴۰۴ | — |
| V7.5 | شهریور ۱۴۰۴ | ۱۱۲ صفحه |
| V7.6 | مهر ۱۴۰۴ | ۱۱۳ صفحه |
| V7.9 | مرداد ۱۴۰۵ | — |
دو نکته که از این جدول بیرون میآید:
۱. سند در حال رشد است. از ۸۱ صفحه در خرداد ۱۴۰۲ به بیش از ۱۱۳ صفحه رسیده. این رشد عمدتاً از افزوده شدن الگوهای تخصصی جدید (بورس، ارز، طلا، فروش زنجیرهای) و جداول قواعد کنترلی میآید.
۲. فاصله نسخهها گاهی یک ماه است. بین V7.5 و V7.6 فقط یک ماه فاصله بود. هر معماریای که فرض کند «سالی یک بار بهروزرسانی میکنیم» از پایه اشتباه است.
تغییرات نسخه ۷.۹
هر ویرایش این سند، در صفحه دوم خود یک جدول رسمی با عنوان «آخرین تغییرات انجامشده در سند حاضر نسبت به ویرایش قبلی» دارد که تکتک تغییرات را همراه با شماره جدول و بخش مرتبطشان فهرست میکند. این جدول عملاً release note رسمی سند است.
بر اساس الگوی ویرایشهای اخیر (V7.4 تا V7.6)، این تغییرات معمولاً حول همان محورهایی میچرخند که در بخش بعدی توضیح داده شدهاند: اصلاح جدول الگوهای صورتحساب، تغییر جدول جایگاه اقلام، بهروزرسانی جداول قواعد کنترلی فیلدهای اختصاصی، و تدقیق قواعد صورتحسابهای ارجاعی (اصلاحی، ابطالی، برگشت از فروش).
توصیه عملی: پیش از هر تصمیم پیادهسازی، نسخه رسمی V7.9 را از وبسایت سازمان امور مالیاتی (intamedia.ir، بخش پایانههای فروشگاهی و سامانه مؤدیان، قسمت آییننامهها و دستورالعملها) دانلود کنید و جدول صفحه دوم را مرجع قرار دهید. آن جدول، دقیقترین و بهروزترین منبع برای تغییرات این نسخه است.
پنج ناحیهای که تقریباً در هر ویرایش تغییر میکند
اگر تاریخچه ویرایشهای اخیر را کنار هم بگذارید، یک الگوی روشن میبینید. تغییرات تقریباً همیشه در همین پنج ناحیه رخ میدهند:
۱. جدول شماره ۱ — الگوهای صورتحساب الکترونیکی
تقریباً در هر ویرایش دست میخورد. الگوی جدید اضافه میشود یا شرایط یک الگوی موجود تغییر میکند. اگر نرمافزار شما فهرست الگوها را بهصورت enum سختکد کرده، هر بار نیازمند انتشار نسخه جدید نرمافزار خواهید بود.
۲. جدول شماره ۲ — جایگاه اقلام صورتحساب
تعیین میکند هر فیلد در کدام الگو اجباری، اختیاری، در شرایط خاص اجباری یا ignore است. این جدول قلب اعتبارسنجی است و کوچکترین تغییر در آن مستقیماً به رد شدن صورتحساب منجر میشود.
۳. جداول قواعد کنترلی اختصاصی فیلدها
هر فیلد حساس، جدول قواعد کنترلی مخصوص خودش را دارد؛ از تاریخ و زمان صدور تا مبلغ پایه مالیات بر ارزش افزوده و شناسه کالا. ویرایشهای اخیر مکرراً همین جداول را اصلاح کردهاند.
۴. قواعد صورتحسابهای ارجاعی
صورتحساب اصلاحی، ابطالی و برگشت از فروش، پیچیدهترین بخش سند هستند. قواعدی مثل اینکه صورتحساب مرجع باید در چه وضعیتی باشد، یا اینکه هر صورتحساب فقط میتواند مرجع یک صورتحساب ابطالی قرار گیرد، در ویرایشهای مختلف تدقیق شدهاند.
۵. الگوهای تخصصی
اعلامیه فروش بورس، فروش ارز، طلا و جواهر، فروش زنجیرهای. اینها جدیدترین بخش سند و در نتیجه بیثباتترین بخش آن هستند.
چکلیست انتشار نسخه جدید برای تیم فنی
وقتی نسخه تازهای منتشر میشود، این هشت گام را طی کنید:
- صفحه ۲ را بخوانید. جدول رسمی تغییرات، نقشه راه شماست.
- دامنه تأثیر را مشخص کنید. هر ردیف جدول را به یک ماژول یا کلاس مشخص در کد خود نگاشت کنید.
- جدول جایگاه اقلام را diff بگیرید. تغییر وضعیت یک فیلد از «اختیاری» به «در شرایط خاص اجباری» بیسروصداترین و پرهزینهترین نوع تغییر است.
- الگوهای فعال مشتریان را استخراج کنید. اگر هیچ مشتریای از الگوی بورس استفاده نمیکند، تغییرات آن بخش اولویت شما نیست.
- تست رگرسیون روی صورتحسابهای واقعی. نمونههای تأییدشده دورههای قبل را دوباره از مسیر اعتبارسنجی جدید عبور دهید.
- سناریوهای ارجاعی را جداگانه تست کنید. اصلاحی روی اصلاحی، ابطالی، برگشت از فروش جزئی.
- پیامهای خطا را بهروز کنید. کاربر باید بفهمد «کد ملی خریدار برای این الگو الزامی شده»، نه فقط ببیند «خطای اعتبارسنجی».
- تاریخ اعمال را مستند کنید. بدانید کدام صورتحساب با کدام ویرایش سند صادر شده؛ در حسابرسی به کارتان میآید.
خطای معماری که بیشتر نرمافزارها مرتکب میشوند
بیایید صریح باشیم: بیشتر پیادهسازیهای داخلی، قواعد این سند را سختکد میکنند. ifهای تودرتو برای هر الگو، لیست فیلدهای اجباری داخل کد سرویس، و اعتبارسنجی پراکنده در چند لایه.
نتیجهاش قابل پیشبینی است: با هر ویرایش سند، یک چرخه کامل توسعه، تست و استقرار لازم میشود. و چون این چرخه هزینه دارد، به تعویق میافتد. و تا زمانی که به تعویق افتاده، صورتحسابهای مشتریان با خطا برمیگردند.
راهحل ساده است و نیازی به معماری پیچیده ندارد: قواعد اعتبارسنجی را از منطق برنامه جدا کنید و به داده تبدیلشان کنید. یک جدول پیکربندی که برای هر ترکیب «الگو × فیلد» وضعیت الزام را نگه دارد، بههمراه یک موتور اعتبارسنجی که آن جدول را میخواند. آنوقت انتشار نسخه جدید سند تبدیل میشود به یک بهروزرسانی داده، نه یک آزادسازی نرمافزاری.
این همان تفاوت میان نرمافزاری است که هر بار با شما میجنگد و نرمافزاری که فقط کار میکند.
گارنت چطور با تغییر نسخه کنار میآید
نرمافزار واسط سامانه مودیان گارنت دقیقاً بر همین اصل ساخته شده: قواعد الگوها، جایگاه اقلام و کنترلهای فیلدی بهصورت پیکربندی نگهداری میشوند، نه سختکد.
نتیجه برای شما:
- انطباق با ویرایش جدید سند بدون توقف عملیات و بدون انتظار برای نسخه بعدی نرمافزار
- اعتبارسنجی کامل پیش از ارسال — خطا در لحظه صدور به کاربر نمایش داده میشود، نه چند روز بعد
- پیام خطای فارسی و قابل فهم، با اشاره به فیلد و الگوی دقیق
- اتصال به نرمافزار حسابداری فعلی شما، بدون نیاز به تعویض سیستم
دیدگاهها (0)