«نرم‌افزار حسابداری مورد تأیید دارایی»؛ ادعا را چگونه راستی‌آزمایی کنیم؟

چرا عبارت «مورد تأیید دارایی» مبهم است؟

«دارایی» در گفتار بازار می‌تواند وزارت امور اقتصادی و دارایی، سازمان امور مالیاتی، کارگروه راهبری سامانه مؤدیان یا حتی یک شرکت معتمد را منظور کند. این نهادها نقش یکسان ندارند. هر ادعای تأیید باید نام دقیق صادرکننده، شماره و لینک سند، موضوع، نسخه محصول، تاریخ، مدت و محدودیت را نشان دهد. لوگو، حضور در نمایشگاه، نامه همکاری یا امکان ارسال صورتحساب، جای گواهی عمومی نیست. ^{[۱] [۲] [۳]}

در مقررات سامانه مؤدیان، مفاهیمی مانند شرکت معتمد دارای پروانه، پایانه فروشگاهی، حافظه مالیاتی، مشخصات فنی صورتحساب و در یک دستورالعمل «نرم‌افزار حسابداری مورد تأیید کارگروه» در زمینه خاص آمده‌اند. این عناوین باید در همان متن و کاربرد خوانده شوند. تأیید یک جزء یا خدمت را نباید به صحت همه محاسبات، امنیت، استاندارد حسابداری یا پذیرش بی‌قید دفاتر توسعه داد. ^{[۲] [۳] [۱]}

سازمان مالیاتی می‌تواند قالب، شماره منحصر، شیوه تبادل و شرکت‌های معتمد را تنظیم کند، اما رسیدگی مالیاتی همچنان بر واقعیت معامله، اسناد و قانون استوار است. نرم‌افزار نمی‌تواند هزینه فاقد مدرک را قابل قبول یا فروش پنهان را قانونی کند. حتی محصول منطبق نیز با تنظیم غلط، دسترسی مشترک یا نگاشت نادرست کالا خروجی نادرست می‌دهد. انطباق فنی جای کنترل حسابداری را نمی‌گیرد. ^{[۷] [۱] [۱۹]}

پنج سؤال برای اثبات ادعای تأیید

یک: صادرکننده کیست و سند در کدام دامنه رسمی منتشر شده است؟ نامه روی سربرگ فروشنده یا تصویر بی‌پیوند کافی نیست. دو: دقیقاً چه چیزی تأیید شده—شخص حقوقی، خدمت ارسال، نرم‌افزار، نسخه، ماژول یا تجهیزات؟ نام تجاری شرکت می‌تواند چند محصول داشته باشد. جست‌وجو باید به فهرست رسمی و سند قابل دانلود برسد و نام و شناسه شرکت با روزنامه رسمی تطبیق شود. ^{[۶] [۵] [۸]}

سه: دامنه و محدودیت چیست؟ ممکن است گواهی فقط نوع خاص صورتحساب، محیط آزمون، خدمت شرکت معتمد یا دوره مشخص را پوشش دهد. چهار: نسخه و تاریخ چیست؟ تغییر نسخه نرم‌افزار، قانون یا مشخصات فنی می‌تواند دامنه را متاثر کند. پنج: وضعیت جاری چگونه است—فعال، تعلیق، منقضی یا لغو؟ فروشنده باید امکان راستی‌آزمایی مستقل و نه فقط مشاهده اسکرین‌شات را فراهم کند. ^{[۳] [۵] [۲۰]}

اگر ادعا به شرکت معتمد مربوط است، شماره پروانه، نوع خدمت و وضعیت آن شرکت را از فهرست سازمان بررسی کنید. قرارداد شما با فروشنده دیگری یا استفاده از واسط، خودکار زیر همان پروانه قرار نمی‌گیرد. مسئولیت ارسال، خطا، پشتیبانی، محرمانگی و جریمه در قرارداد با ارجاع به قانون روشن شود. از عبارت مبهم «تمام مسئولیت با نرم‌افزار» پرهیز کنید؛ انتقال قانونی مسئولیت فقط در شرایط صریح رخ می‌دهد. ^{[۱] [۳] [۶]}

انطباق مالیاتی را با آزمون انتها‌به‌انتها بسنجید

فروشنده باید نشان دهد داده فروش چگونه به الگوی جاری صورتحساب تبدیل، شناسه کالا و خدمت نگاشت، شماره مالیاتی تولید یا دریافت، ارسال، پذیرش یا رد، اصلاح، ابطال و برگشت مدیریت می‌شود. نام فیلدها و نسخه مشخصات فنی می‌تواند تغییر کند؛ سند روز سازمان مرجع است. آزمون باید با داده ساختگی و چند سناریوی خطا انجام شود، نه فقط یک فاکتور ساده موفق. ^{[۱] [۵] [۱۰]}

رسید و وضعیت کارپوشه باید با سند داخلی تطبیق و عدم ارسال قابل گزارش باشد. صف آفلاین، تکرار، زمان سیستم، کلید و گواهی، قطع شبکه و بازیابی بررسی شوند. فروشنده توضیح دهد در خرابی چه داده‌ای حفظ و چه کسی رخداد را پیگیری می‌کند. دستورالعمل سازمان برای حادثه یا نقص فنی نیز باید در برنامه تداوم دیده شود؛ چاپ فاکتور عادی جای مسیر قانونی را نمی‌گیرد. ^{[۱] [۴] [۱۷]}

تطبیق دوره‌ای باید جمع فروش و مالیات دفتر کل، صورتحساب‌های صادرشده، وضعیت کارپوشه، ابطال و واکنش خریدار را مقایسه کند. امکان خروجی قابل خواندن و شاهد شماره نسخه مهم است. اگر محصول فقط ارسال می‌کند اما برگشت و اصلاح را به حسابداری برنمی‌گرداند، کنترل ناقص است. اختلاف باید صاحب، علت، موعد و سند اصلاح داشته باشد و با ثبت دستی بی‌ردپا بسته نشود. ^{[۱۹] [۱] [۲۰]}

صحت حسابداری را جدا از اتصال مالیاتی ارزیابی کنید

هسته حسابداری باید ثبت دوطرفه، دوره، کنترل سند، دفتر کل و معین، ابعاد تفصیلی، بستن، برگشت، شماره‌گذاری و گزارش قابل بازسازی را پشتیبانی کند. سطح نیاز با اندازه و صنعت فرق دارد. گزارش زیبا بدون مسیر از رقم تا سند کافی نیست. سیاست حسابداری، سال مالی، چندارزی، چندشرکتی، انبار، تولید یا پیمان باید با سناریوی واقعی مشتری آزمایش شوند، نه با فهرست امکانات فروشنده. ^{[۱۳] [۱۲] [۲۰]}

کنترل دسترسی باید تهیه، تأیید، ارسال، پرداخت و مدیریت کاربر را تفکیک کند. تاریخچه تغییر، قفل دوره، حذف منطقی، گزارش دسترسی و جانشین لازم‌اند. مدیر سیستم نباید بتواند همه رویدادهای خود را بی‌ردپا پاک کند. پشتیبان، بازیابی، رمزنگاری، خروج کارمند و محیط آزمون با داده ناشناس بررسی شوند. گواهی امنیتی محدود نیز جای آزمون پیکربندی و قرارداد حادثه را نمی‌گیرد. ^{[۱۶] [۱۵] [۱۴]}

قابلیت خروج داده و مهاجرت را پیش از خرید بسنجید: دفتر، اسناد، پیوست، اشخاص و تاریخچه در قالب مستند و قابل خواندن تحویل شود. مالکیت داده، زمان خروج، هزینه، حذف پس از قرارداد و پشتیبان در توافق بیاید. قفل‌شدن مشتری در سامانه‌ای که فقط PDF می‌دهد، ریسک تداوم و رسیدگی می‌سازد. یک بازیابی و یک خروج کامل در ارزیابی اولیه اجرا کنید. ^{[۱۷] [۲۰] [۱۴]}

فروشنده و قرارداد را به اندازه محصول بررسی کنید

شناسه ملی، صاحبان امضا، سابقه، تیم پشتیبانی، زیرپردازنده‌ها، محل میزبانی، برنامه تداوم و بیمه یا تعهدات فروشنده بررسی شوند. تعداد مشتری یا قدمت برند تضمین خدمت آینده نیست. SLA باید شدت رخداد، زمان پاسخ و بازیابی، کانال، خروجی و جبران را روشن کند. وابستگی به یک برنامه‌نویس یا یک کلید اختصاصی بدون جانشین، ریسک عملیاتی مهم است. ^{[۹] [۱۷] [۱۱]}

قرارداد باید قابلیت‌های اثبات‌شده، نسخه، محیط، کاربران، یکپارچه‌سازی، مسئولیت داده، امنیت، آموزش، مهاجرت، تغییر قانون و پایان همکاری را مشخص کند. عبارت «مطابق قوانین کشور» بدون معیار پذیرش کافی نیست. برای سامانه مؤدیان، سناریو و خروجی پذیرش بنویسید. ویژگی نقشه راه با موعد و شرط پرداخت جدا شود؛ تصویر ارائه یا وعده شفاهی تعهد قابل آزمون نیست. ^{[۱۹] [۱۶] [۱]}

قیمت را با هزینه کل مالکیت بسنجید: پیاده‌سازی، پاک‌سازی داده، آموزش، زیرساخت، شرکت معتمد یا ارسال، پشتیبانی، تغییر، خروج و توقف. محصول ارزان با مغایرت ماهانه یا صادرات داده ضعیف می‌تواند گران‌تر باشد. ماتریس امتیاز باید وزن انطباق، کنترل، امنیت، عملیات، پشتیبانی و قیمت را قبل از دمو تعیین کند تا عبارت «مورد تأیید» کل تصمیم را تسخیر نکند. ^{[۱۶] [۱۳] [۱۸]}

ادعای درست ژرف‌بان باید چه شکلی باشد؟

ژرف‌بان نباید خود را «مورد تأیید دارایی» بنامد مگر سند رسمی جاری، دامنه و نسخه مشخص وجود داشته باشد. معرفی صادقانه بر قابلیت‌های فعال مالی، اسناد، خزانه، خرید، فروش، اشخاص، نقش، تأیید، تاریخچه و چندشرکتی تکیه می‌کند. ارسال مستقیم سامانه مؤدیان، شرکت معتمد، گواهی امنیتی یا هر اتصال دولتی فقط اگر در دمو و قرارداد همان مشتری اثبات شود قابل ادعاست. ^{[۱] [۳]}

در دمو یک فروش، برگشت، قطع ارتباط، اصلاح و تطبیق دوره را با داده ساختگی اجرا کنید. از گزارش دفتر کل تا رسید مالیاتی حرکت کنید و نقش‌ها، تاریخچه و خروج داده را ببینید. سپس فروشنده سند هر ادعای تأیید را در دامنه رسمی نشان دهد. اگر قابلیت فقط در نقشه راه است، زمان و وابستگی آن باید صریح باشد؛ یک لوگو یا نام سازمان روی اسلاید، مدرک نیست. ^{[۱۹] [۱۷]}

مسئولیت نهایی انتخاب با خریدار و تکلیف مالیاتی با مؤدی در حدود قانون است. نرم‌افزار ابزار کنترل است و مشاور مالیاتی یا حسابرس را جایگزین نمی‌کند. معیار پذیرش را به خروجی واقعی و قانون جاری وصل کنید و هر تغییر مشخصات فنی را در تقویم بازآزمون قرار دهید. مرز محصول و خدمت شرکت معتمد نیز باید در قرارداد و جریان پشتیبانی روشن بماند. ^{[۷] [۱] [۱۲]}

پرونده اثبات محصول را زنده نگه دارید: فهرست ادعاها، سند رسمی، نسخه، تاریخ بررسی، نتیجه سناریو، محدودیت و مالک بازآزمون. با هر انتشار نرم‌افزار یا تغییر فنی مالیات، موارد متاثر دوباره آزموده شوند. این پرونده هم برای خریداری که می‌خواهد ادعا را بسنجد مفید است و هم برای فروشنده‌ای که می‌خواهد تیم فروش از عبارت گسترده‌تر از سند استفاده نکند. ^{[۵] [۲۰] [۱۷]}

ماتریس نهایی انتخاب باید حداقل انطباق مالیاتی، صحت حسابداری، امنیت، تداوم، خروج داده، پشتیبانی و هزینه کل را وزن دهد. امتیاز «تأیید» فقط در دامنه سند محاسبه شود. دو محصول می‌توانند هر دو صورتحساب بفرستند اما در بستن دوره یا بازیابی تفاوت جدی داشته باشند. وزن‌ها پیش از دمو قفل شوند تا ارائه جذاب فروشنده معیارها را پس از مشاهده تغییر ندهد. ^{[۱۳] [۱۶] [۱۸]}